From nobody Tue Jul 1 00:37:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB881A017D for ; Tue, 1 Jul 2014 00:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ukpXP818gl9 for ; Tue, 1 Jul 2014 00:37:31 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131651A0185 for ; Tue, 1 Jul 2014 00:37:31 -0700 (PDT) From: =?utf-8?B?Vml0a292c2vDvSBBZGFt?= To: Shyam Sethuram Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//+xkgIAAOCmwgAHzEgCABv+DcIAFaTsAgACVn8A= Date: Tue, 1 Jul 2014 07:37:25 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B019C9149@EX01.swan.local> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> In-Reply-To: Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.40.93] Content-Type: multipart/alternative; boundary="_000_61DC6BC4ABA10E4489D4A73EBABAC18B019C9149EX01swanlocal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/lDst7hUeCawTclc1GFHMe10YV14 Cc: Robert Raszuk , "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 07:37:35 -0000 --_000_61DC6BC4ABA10E4489D4A73EBABAC18B019C9149EX01swanlocal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm93IHRoYXQgeW91IG1lbnRpb25lZCBpdCB5ZXMgdGhhdOKAmXMgZXhhY3RseSB0aGUgZGVzaXJl ZCBiZWhhdmlvci4NCg0KSSBzZWUgbm8gcG9pbnQgaW4gZm9yY2luZyBhIEJHUCBzcGVha2VyIHRv IGFjY2VwdCBpdHMgb3duIFJUIG1lbWJlcnNoaXAgTlJMSSBpbiBvcmRlciB0byBzdGFydCBhZHZl cnRpc2luZyBOUkxJcyB3aXRoIHRoaXMgUlQuDQpJIG1lYW4gaWYgdGhlcmXigJlzIG5vIG90aGVy IFJUIG1lbWJlcnNoaXAgTlJMSSBmb3IgYSBwYXJ0aWN1bGFyIFJULCB0aGFuIG5vIG9uZSByZWFs bHkgd2FudHMgdG8ga25vdyB0aGUgTlJMSXMgd2l0aCB0aGlzIHBhcnRpY3VsYXIgUlQuDQoNCmFk YW0NCg0KRnJvbTogU2h5YW0gU2V0aHVyYW0gW21haWx0bzpzaHlhbS5pb21sQGdtYWlsLmNvbV0N ClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDEsIDIwMTQgMjoyOSBBTQ0KVG86IFZpdGtvdnNrw70gQWRh bQ0KQ2M6IERvbmdqaWUgKEppbW15KTsgUm9iZXJ0IFJhc3p1azsgaWRyQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW0lkcl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kb25nLWlk ci1ydGMtaGllcmFyY2hpY2FsLXJyLTAwLnR4dA0KDQoNCj4gSW4gb3JkZXIgdG8gc3RhcnQgbGVh cm5pbmcgdGhlIE5STElzIFJSIGhhcyB0byBhZHZlcnRpc2UgYSBkZXNpcmUgdG8gcmVjZWl2ZSB0 aGVtIGFuZCB0byBkbyB0aGF0IHdlIGNhbiB1c2UgbW9kaWZpZWQgcnVsZSAzLjIuaWkuDQo+DQo+ ICAgICAgICBXaGVuIGFkdmVydGlzaW5nIGFuIFJUIG1lbWJlcnNoaXAgTkxSSSB0byBhIGNsaWVu dCBwZWVyLCBpZg0KPiAgICAgICAgdGhlIGJlc3QgcGF0aCBhcyBzZWxlY3RlZCBieSB0aGUgcGF0 aCBzZWxlY3Rpb24gcHJvY2VkdXJlDQo+ICAgICAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiA5LjEg b2YgdGhlIGJhc2UgQkdQIHNwZWNpZmljYXRpb24gWzRdIGlzIGENCj4gICAgICAgIHJvdXRlIHJl Y2VpdmVkIGZyb20gdGhhdCBjbGllbnQgcGVlciBpbiBwYXJ0aWN1bGFyLCBhbmQgaWYgdGhlcmUg aXMgYW4NCj4gICAgICAgIGFsdGVybmF0aXZlIHBhdGggdG8gdGhlIHNhbWUgZGVzdGluYXRpb24g ZnJvbSBhbm90aGVyIGNsaWVudCBvciBhIG5vbi1jbGllbnQsIHRoZQ0KPiAgICAgICAgYXR0cmli dXRlcyBvZiB0aGUgb3RoZXIgcGF0aCBhcmUgYWR2ZXJ0aXNlZCB0byB0aGUgcGVlci4NCj4NCj4g Tm93IHRoaW5raW5nIGFib3V0IGl0IG9ubHkgb25lIHJ1bGUgZm9yIHJlZmxlY3Rpb24gb2YgUlQg bWVtYmVyc2hpcCBOTFJJIGlzIGVub3VnaCBJIGd1ZXNzLg0KPiBJZiB5b3UgcmVjZWl2ZWQgUlQg bWVtYmVyc2hpcCBOTFJJIGZyb20gb25seSBvbmUgcGVlciBkb24ndCBhZHZlcnRpc2UgaXQgdW50 aWwgeW91IGhhdmUgcmVjZWl2ZWQgdGhlIFJUIG1lbWJlcnNoaXAgTkxSSSB3aXRoIHRoZSBzYW1l IFJUIGZyb20gYW5vdGhlciBwZWVyLg0KPiBUaGVuIHlvdSBjYW4gYWR2ZXJ0aXNlIHRoZSBhbHRl cm5hdGUgKG5vdCB0aGUgb25lIHRoYXQgdGhlIHBlZXIgc2VudCB5b3UpIFJUIG1lbWJlcnNoaXAg TkxSSSB0byBhIGdpdmVuIHBlZXIgKHNpbXBsZSBzcGxpdCBob3Jpem9uKS4NCg0KVGhpcyBzb3Vu ZHMgbGlrZSBiZXN0LWV4dGVybmFsIGFkdmVydGlzZW1lbnQgPw0KKFNlY3Rpb24gNSwgZHJhZnQt aWV0Zi1pZHItYmVzdC1leHRlcm5hbC0wNSkNCg0Kc2h5YW0NCg0KT24gRnJpLCBKdW4gMjcsIDIw MTQgYXQgNDo1MiBBTSwgVml0a292c2vDvSBBZGFtIDxhZGFtLnZpdGtvdnNreUBzd2FuLnNrPG1h aWx0bzphZGFtLnZpdGtvdnNreUBzd2FuLnNrPj4gd3JvdGU6DQpIaSBmb2xrcywNCg0KUmVnYXJk aW5nIHRoZSBydWxlIDMuMi5pIG9mIFJGQzQ2ODQuDQoNCkZpcnN0IGNvbnNpZGVyIHNjZW5hcmlv IGEpOg0KYSkNClJSLS0tLVBFMQ0KDQpXaHkgd291bGQgSSB3YW50IHRoZSBSUiB0byBsZWFybiB0 aGUgUEUncyBwcmVmaXhlcyBpZiB0aGVyZSdzIG5vIG9uZSBpbnRlcmVzdGVkIGluIHRoZW0gKG5v IG90aGVyIGNsaWVudHMgaW50ZXJlc3RlZCB0byByZWNlaXZlIE5STEkgZm9yIGdpdmVuIFJUcykg YXMgUEUxIGlzIHRoZSBvbmx5IG9uZSB0aGF0IGFkdmVydGlzZWQgdGhlIFJvdXRlIFRhcmdldCBt ZW1iZXJzaGlwIGluZm9ybWF0aW9uIHRvIFJSLg0KDQpOb3cgbGV0J3MgY29uc2lkZXIgc2NlbmFy aW8gYik6DQpiKQ0KUEUyLS0tLVJSLS0tLVBFMQ0KDQpOb3cgdGhlcmUgaXMgYW5vdGhlciBjbGll bnQgKFBFMikgY29ubmVjdGVkIHRvIHRoZSBSUiBhbmQgaXQgaGFwcGVucyB0byBiZSBpbnRlcmVz dGVkIGluIHJlY2VpdmluZyBOUkxJIGZvciBhIGdpdmVuIFJUIGFzIGRlc2lnbmF0ZWQgYnkgdGhl IGFkdmVydGlzZWQgUm91dGUgVGFyZ2V0IG1lbWJlcnNoaXAgaW5mb3JtYXRpb24gZm9yIHRoZSBn aXZlbiBSVC4NCk9rIG5vdyB0aGF0IHRoZXJlIGFyZSBpbnRlcmVzdGVkIHJlY2VpdmVycyBmb3Ig YSBnaXZlbiBOUkxJIG9uIGJvdGggc2Vzc2lvbnMgLSBSUiBzaG91bGQgc3RhcnQgbGVhcm5pbmcg dGhlIE5STElzIGZyb20gY2xpZW50cyBzbyB0aGF0IGl0IGNhbiBkaXNzZW1pbmF0ZSB0aGUgaW5m b3JtYXRpb24gYWNjb3JkaW5nbHkuDQoNCkluIG9yZGVyIHRvIHN0YXJ0IGxlYXJuaW5nIHRoZSBO UkxJcyBSUiBoYXMgdG8gYWR2ZXJ0aXNlIGEgZGVzaXJlIHRvIHJlY2VpdmUgdGhlbSBhbmQgdG8g ZG8gdGhhdCB3ZSBjYW4gdXNlIG1vZGlmaWVkIHJ1bGUgMy4yLmlpLg0KDQogICAgICAgIFdoZW4g YWR2ZXJ0aXNpbmcgYW4gUlQgbWVtYmVyc2hpcCBOTFJJIHRvIGEgY2xpZW50IHBlZXIsIGlmDQog ICAgICAgIHRoZSBiZXN0IHBhdGggYXMgc2VsZWN0ZWQgYnkgdGhlIHBhdGggc2VsZWN0aW9uIHBy b2NlZHVyZQ0KICAgICAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiA5LjEgb2YgdGhlIGJhc2UgQkdQ IHNwZWNpZmljYXRpb24gWzRdIGlzIGENCiAgICAgICAgcm91dGUgcmVjZWl2ZWQgZnJvbSB0aGF0 IGNsaWVudCBwZWVyIGluIHBhcnRpY3VsYXIsIGFuZCBpZiB0aGVyZSBpcyBhbg0KICAgICAgICBh bHRlcm5hdGl2ZSBwYXRoIHRvIHRoZSBzYW1lIGRlc3RpbmF0aW9uIGZyb20gYW5vdGhlciBjbGll bnQgb3IgYSBub24tY2xpZW50LCB0aGUNCiAgICAgICAgYXR0cmlidXRlcyBvZiB0aGUgb3RoZXIg cGF0aCBhcmUgYWR2ZXJ0aXNlZCB0byB0aGUgcGVlci4NCg0KTm93IHRoaW5raW5nIGFib3V0IGl0 IG9ubHkgb25lIHJ1bGUgZm9yIHJlZmxlY3Rpb24gb2YgUlQgbWVtYmVyc2hpcCBOTFJJIGlzIGVu b3VnaCBJIGd1ZXNzLg0KSWYgeW91IHJlY2VpdmVkIFJUIG1lbWJlcnNoaXAgTkxSSSBmcm9tIG9u bHkgb25lIHBlZXIgZG9uJ3QgYWR2ZXJ0aXNlIGl0IHVudGlsIHlvdSBoYXZlIHJlY2VpdmVkIHRo ZSBSVCBtZW1iZXJzaGlwIE5MUkkgd2l0aCB0aGUgc2FtZSBSVCBmcm9tIGFub3RoZXIgcGVlci4N ClRoZW4geW91IGNhbiBhZHZlcnRpc2UgdGhlIGFsdGVybmF0ZSAobm90IHRoZSBvbmUgdGhhdCB0 aGUgcGVlciBzZW50IHlvdSkgUlQgbWVtYmVyc2hpcCBOTFJJIHRvIGEgZ2l2ZW4gcGVlciAoc2lt cGxlIHNwbGl0IGhvcml6b24pLg0KDQpUaGVuIHRoZXJlJ3Mgbm8gbmVlZCB0byBtb2RpZnkgdGhl IHVwZGF0ZSBzbyB0aGF0IGl0IGNhbiBiZSBhY2NlcHRlZCBieSB0aGUgb3JpZ2luYXRvciAoYXMg aW4gMy4yLmkuKS4NCkFuZCB0aGlzIGFsc28gc29sdmVzIHRoZSBoaWVyYXJjaGljYWwgUlIgcHJv YmxlbSBhcyB3ZWxsLg0KDQoNCkknZCBsaWtlIHRoZSB0aGluayBvZiBpdCBhcyB3aXRoIG11bHRp Y2FzdCBmbG93IHdoZXJlIFJSIGlzIGxpa2UgUlAgYW5kIFBFcyBhcmUgbGlrZSBTb3VyY2VzICsg UmVjZWl2ZXJzLg0KVGhlcmUncyBubyBuZWVkIGZvciB0aGUgUlAgKFJSKSB0byByZWNlaXZlIHRo ZSBtY2FzdCBzdHJlYW0gKGUuZy4gVlBOIFByZWZpeGVzKSB3aGVuIHRoZXJlJ3MganVzdCBvbmUg U291cmNlL1JlY2VpdmVyIChQRSkgY29ubmVjdGVkIHRvIGl0Lg0KQSBzaW1wbGUgc3RhdGUgb24g dGhlIFJQIHNheWluZyB0aGVyZSBpcyBhIHBhcnRpY3VsYXIgc3RyZWFtIGF2YWlsYWJsZSBhdCB0 aGlzIHBhcnRpY3VsYXIgc291cmNlIGlzIGVub3VnaCAoaS5lLiBSVCBtZW1iZXJzaGlwIE5MUkkg b24gUlIpLg0KT25jZSBvdGhlciBzb3VyY2UvcmVjZWl2ZXJzIChQRXMpIGFyZSBjb25uZWN0ZWQg dG8gdGhlIFJQKFJSKSBhbmQgc2lnbmFsIHRoZWlyIGRlc2lyZSB0byByZWNlaXZlIHRoZSBzdHJl YW0gKHZpYSBSVCBtZW1iZXJzaGlwIE5MUkkpLg0KVGhlbiBSUCAoUlIpIGRlY2lkZXMgdGhlIGRl c2lyZSByZWNlaXZlIHRoZSBzdHJlYW0gKFJUIG1lbWJlcnNoaXAgTkxSSSkgaXMgd29ydGggc3By ZWFkaW5nIGFuZCBkaXNzZW1pbmF0ZXMgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBpbnRlcmVzdGVk IHNvdXJjZXMvcmVjZWl2ZXJzIChQRXMpLg0KT25jZSB0aGF0IGhhcHBlbnMgc291cmNlcy9yZWNl aXZlcnMgKFBFcykgd2lsbCBzdGFydCBzZW5kaW5nIHRoZSBtY2FzdCBzdHJlYW0gKGUuZy4gVlBO IFByZWZpeGVzKSB0b3dhcmRzIHRoZSBSUCAoUlIpIHdoaWNoIHRoYW4gcmVmbGVjdHMgdGhpcyBt Y2FzZSBzdHJlYW1zIHRvIGFsbCBpbnRlcmVzdGVkIHNvdXJjZXMvcmVjZWl2ZXJzIChQRXMpLg0K DQoNCkkgYmVsaWV2ZSB0aGUgY29uY2VybnMgcHJlc2VudGVkIGluIGRyYWZ0LWRvbmctaWRyLXJ0 Yy1oaWVyYXJjaGljYWwtcnItMDAgY291bGQgYmUgcmVzb2x2ZWQgYnkgYWRkLXBhdGggd2hlcmUg YXQgbGVhc3Qgb25lIGFkZGl0aW9uYWwgcGF0aCBpcyBhZHZlcnRpc2VkIGFsb25nIHdpdGggdGhl IGJlc3QtcGF0aC4NCkJ1dCBzdGlsbCBydWxlIDMuMi5pLiBpbiBSRkM0Njg0IGlzIHZlcnkgaGFy bWZ1bCBpbiBzY2VuYXJpb3Mgd2hlcmUgUlJzIGFyZSBjbGllbnRzIG9mIG90aGVyIFJScyAoc2Ft ZSBsZXZlbCBvciBkaWZmZXJlbnQgbGV2ZWwpLg0KDQoNCg0KIGFkYW0NCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERvbmdqaWUgKEppbW15KSBbbWFpbHRvOmppZS5k b25nQGh1YXdlaS5jb208bWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb20+XQ0KPiBTZW50OiBNb25k YXksIEp1bmUgMjMsIDIwMTQgNDo1OSBBTQ0KPiBUbzogVml0a292c2vDvSBBZGFtOyBSb2JlcnQg UmFzenVrDQo+IENjOiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4NCj4gU3ViamVj dDogUkU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZG9uZy1pZHIt cnRjLWhpZXJhcmNoaWNhbC0NCj4gcnItMDAudHh0DQo+DQo+IEhpIEFkYW0sDQo+DQo+IElmIFJE IGlzIHBhcnQgb2YgdGhlIFJUQyByb3V0ZXMsIHRoaXMgcHJvYmxlbSB3aWxsIG5vdCBvY2N1cjop IFdoaWxlIGFzIGFuYWx5emVkDQo+IGluIHJmYyA0Njg0LCB0aGlzIHJlcXVpcmVzIG1vcmUgUlRD IHJvdXRlcyBiZWluZyBleGNoYW5nZWQgYW5kIGtlcHQgaW4gdGhlDQo+IGxvY2FsIEFTLg0KPg0K PiBJIGFncmVlIHRoYXQgYWRkLXBhdGggaXMgYSBjYW5kaWRhdGUgc29sdXRpb24gdG8gdGhpcyBw cm9ibGVtLCB3aGlsZSB3aGVuDQo+IGVuYWJsaW5nIGFkZC1wYXRoIG9uIFJUQyBBRkkvU0FGSSwg d2Ugc3RpbGwgbmVlZCB0byBzcGVjaWZ5IHRoZSBydWxlcyBvZiB3aGljaA0KPiBSVEMgcm91dGVz IHNob3VsZCBiZSBhZHZlcnRpc2VkIHRvIHNvbHZlIHRoaXMgcHJvYmxlbS4gT3Igd2UganVzdCB1 cGRhdGUgdGhlDQo+IHJ1bGVzIG9mIFJUQyBhZHZlcnRpc2VtZW50IGFzIHRoZSBvdGhlciBSVEMg cmVsYXRlZCBuZXcgZHJhZnRzPw0KPg0KPiBNYW55IHRoYW5rcywNCj4gSmllDQo+DQo+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBWaXRrb3Zza8O9IEFkYW0gW21haWx0 bzphZGFtLnZpdGtvdnNreUBzd2FuLnNrPG1haWx0bzphZGFtLnZpdGtvdnNreUBzd2FuLnNrPl0N Cj4gPiBTZW50OiBTdW5kYXksIEp1bmUgMjIsIDIwMTQgMzoyMCBBTQ0KPiA+IFRvOiBSb2JlcnQg UmFzenVrDQo+ID4gQ2M6IERvbmdqaWUgKEppbW15KTsgaWRyQGlldGYub3JnPG1haWx0bzppZHJA aWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUkU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3INCj4gPiBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTAwLnR4dA0KPiA+ DQo+ID4gQWFoIEkgc2VlIDopDQo+ID4gV2VsbCB3ZSBjb3VsZCBoYXZlIHRoYXQgb25lIHNvbHZl ZCBpZiBSRCB3b3VsZCBiZSBwYXJ0IG9mIHRoZSBSVEMNCj4gPiByb3V0ZXMgOikgKHRob3VnaCBJ IHVuZGVyc3RhbmQgb25lIGNvdWxkIHVzZSBSVEMgZm9yIG5vbiBWUE4gcm91dGVzIGFzDQo+ID4g d2VsbCBzby4uLikgQW55d2F5cyBzbyB0aGFuIGFzIHlvdSBtZW50aW9uZWQgYWRkLXBhdGggb24g dGhlIFJUQyBBRg0KPiA+IHNlZW1zIGFzIHRoZSBiZXN0IG9wdGlvbiB0aGVuLg0KPiA+DQo+ID4g YWRhbQ0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IHJyYXN6 dWtAZ21haWwuY29tPG1haWx0bzpycmFzenVrQGdtYWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdt YWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+XSBPbiBCZWhhbGYgT2YNCj4gPiA+IFJv YmVydCBSYXN6dWsNCj4gPiA+IFNlbnQ6IFNhdHVyZGF5LCBKdW5lIDIxLCAyMDE0IDc6NTIgUE0N Cj4gPiA+IFRvOiBWaXRrb3Zza8O9IEFkYW0NCj4gPiA+IENjOiBEb25namllIChKaW1teSk7IGlk ckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0KPiA+ID4gU3ViamVjdDogUmU6IFtJZHJd IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiA+IGRyYWZ0LWRvbmctaWRyLXJ0Yy1o aWVyYXJjaGljYWwtIHJyLTAwLnR4dA0KPiA+ID4NCj4gPiA+IEhpIEFkYW0sDQo+ID4gPg0KPiA+ ID4gSmllIGlzIGRlc2NyaWJpbmcgUlQgcm91dGVzIG5vdCBWUE4gcm91dGVzLiBZb3VyIHN0b3J5 IGRvZXMgbm90DQo+ID4gPiBhcHBseSB0byBSVCByb3V0ZXMgYXMgZm9ybWF0IG9mIFJUIE5MUkkg aXMgd2VsbCBkZWZpbmVkIGJ5IFJGQyA7KQ0KPiA+ID4NCj4gPiA+IEJlc2lkZXMgTVBMUyBuZXR3 b3JrIG9yIG5vdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIGl0IC4uLi4NCj4gPiA+DQo+ID4gPiBC ZXN0LA0KPiA+ID4gUi4NCj4gPiA+DQo+ID4gPiBPbiBTYXQsIEp1biAyMSwgMjAxNCBhdCA3OjE5 IFBNLCBWaXRrb3Zza8O9IEFkYW0NCj4gPiA+IDxhZGFtLnZpdGtvdnNreUBzd2FuLnNrPG1haWx0 bzphZGFtLnZpdGtvdnNreUBzd2FuLnNrPj4NCj4gPiA+IHdyb3RlOg0KPiA+ID4gPiBIaSBKaWUs DQo+ID4gPiA+IFdlbGwgdGhlIGNvcnJlY3RseSBkZXNpZ25lZCBNUExTIG5ldHdvcmtzIHVzZSB1 bmlxdWUgcGVyIFBFIHBlcg0KPiA+ID4gPiBWUkYgUkRzDQo+ID4gPiBpbiBmb3JtIG9mIFJJRDp4 eHh4eC4NCj4gPiA+ID4gVW5pcXVlIHBlciBQRSBSRHMgbWFrZXMgYWxsIGNvcGllcyBvZiB0aGUg c2FtZSBWUE4gcHJlZml4IHJlY2VpdmVkDQo+ID4gPiA+IGZyb20NCj4gPiA+IGRpZmZlcmVudCBQ RXMgdW5pcXVlIHNvIFJScyB3aWxsIHNlbGVjdCBhbGwgYXMgYmVzdCBwYXRoIGFuZA0KPiA+ID4g ZGlzdHJpYnV0ZSB0aGVtIGFjY29yZGluZ2x5LCB3aGljaCBzb2x2ZXMgdGhpcyBhbmQgbWFueSBv dGhlciBpc3N1ZXMuDQo+ID4gPiA+DQo+ID4gPiA+IEluIG90aGVyIHdvcmRzIGlmIHNvbWVvbmUg dHJpZXMgdG8gc2hvb3QgaGltc2VsZiBpbiB0aGUgZm9vdCBJDQo+ID4gPiA+IHdvdWxkbid0DQo+ ID4gPiBkZXZlbG9wIGJ1bGxldHByb29mIGJvb3RzIGZvciBoaW0uDQo+ID4gPiA+DQo+ID4gPiA+ IGFkYW0NCj4gPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+PiBGcm9t OiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRG9uZ2ppZQ0KPiA+ID4gPj4gKEppbW15KQ0KPiA+ID4gPj4g U2VudDogRnJpZGF5LCBKdW5lIDIwLCAyMDE0IDQ6NTUgQU0NCj4gPiA+ID4+IFRvOiBpZHJAaWV0 Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4NCj4gPiA+ID4+IFN1YmplY3Q6IFtJZHJdIEZXOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gPiA+PiBkcmFmdC1kb25nLWlkci1ydGMt IGhpZXJhcmNoaWNhbC1yci0wMC50eHQNCj4gPiA+ID4+DQo+ID4gPiA+PiBIaSBhbGwsDQo+ID4g PiA+Pg0KPiA+ID4gPj4gVGhpcyBpcyBhIHNob3J0IGRyYWZ0IHRvIG1ha2UgUlRDIGFwcGxpY2Fi bGUgaW4gaGllcmFyY2hpY2FsIFJSIHNjZW5hcmlvLg0KPiA+ID4gPj4NCj4gPiA+ID4+IENvbW1l bnRzIGFyZSB3ZWxjb21lLg0KPiA+ID4gPj4NCj4gPiA+ID4+IEJlc3QgcmVnYXJkcywNCj4gPiA+ ID4+IEppZQ0KPiA+ID4gPj4NCj4gPiA+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRvbmct aWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAudHh0DQo+ID4gPiA+PiA+IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgSmllIERvbmcgYW5kIHBvc3RlZCB0byB0aGUNCj4gPiA+ID4+ ID4gSUVURg0KPiA+ID4gPj4gcmVwb3NpdG9yeS4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4gTmFt ZTogICAgICAgICAgICAgICBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyDQo+ID4g PiA+PiA+IFJldmlzaW9uOiAgIDAwDQo+ID4gPiA+PiA+IFRpdGxlOiAgICAgICAgICAgICAgRXh0 ZW5zaW9ucyB0byBSVC1Db25zdHJhaW4gaW4gSGllcmFyY2hpY2FsIFJvdXRlDQo+ID4gUmVmbGVj dGlvbg0KPiA+ID4gPj4gPiBTY2VuYXJpb3MNCj4gPiA+ID4+ID4gRG9jdW1lbnQgZGF0ZTogICAg ICAyMDE0LTA2LTE5DQo+ID4gPiA+PiA+IEdyb3VwOiAgICAgICAgICAgICAgSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQo+ID4gPiA+PiA+IFBhZ2VzOiAgICAgICAgICAgICAgNQ0KPiA+ID4gPj4gPiBV Ukw6DQo+ID4gPiA+PiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaA0KPiA+ID4gPj4gPiBpYw0KPiA+ID4gPj4gPiBhbA0KPiA+ ID4gPj4gPiAtcnINCj4gPiA+ID4+ID4gLTAwLnR4dA0KPiA+ID4gPj4gPiBTdGF0dXM6DQo+ID4g PiA+PiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRvbmctaWRyLXJ0 Yy1oaWVyYXJjaGljYQ0KPiA+ID4gPj4gPiBsLQ0KPiA+ID4gPj4gPiBycg0KPiA+ID4gPj4gPiAv DQo+ID4gPiA+PiA+IEh0bWxpemVkOg0KPiA+ID4gPj4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTANCj4gPiA+ID4+ID4gMA0K PiA+ID4gPj4gPg0KPiA+ID4gPj4gPg0KPiA+ID4gPj4gPiBBYnN0cmFjdDoNCj4gPiA+ID4+ID4g ICAgVGhlIFJvdXRlIFRhcmdldCAoUlQpIENvbnN0cmFpbiBtZWNoYW5pc20gc3BlY2lmaWVkIGlu IFJGQyA0Njg0IGlzDQo+ID4gPiA+PiA+ICAgIHVzZWQgdG8gYnVpbGQgYSByb3V0ZSBkaXN0cmli dXRpb24gZ3JhcGggaW4gb3JkZXIgdG8gcmVzdHJpY3QgdGhlDQo+ID4gPiA+PiA+ICAgIHByb3Bh Z2F0aW9uIG9mIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrIChWUE4pIHJvdXRlcy4gIEluIG5ldHdv cmsNCj4gPiA+ID4+ID4gICAgc2NlbmFyaW9zIHdoZXJlIGhpZXJhcmNoaWNhbCByb3V0ZSByZWZs ZWN0aW9uIChSUikgaXMgdXNlZCwgdGhlDQo+ID4gPiA+PiA+ICAgIGV4aXN0aW5nIFJULUNvbnN0 cmFpbiBtZWNoYW5pc20gY2Fubm90IGJ1aWxkIGEgY29ycmVjdCByb3V0ZQ0KPiA+ID4gPj4gPiAg ICBkaXN0cmlidXRpb24gZ3JhcGguICBUaGlzIGRvY3VtZW50IHJlZmluZXMgdGhlIHJvdXRlIGRp c3RyaWJ1dGlvbg0KPiA+ID4gPj4gPiAgICBydWxlcyBvZiBSVC1Db25zdHJhaW4gdG8gYWRkcmVz cyB0aGUgaGllcmFyY2hpY2FsIFJSIHNjZW5hcmlvcy4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4N Cj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4gUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUNCj4g PiA+ID4+ID4gb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlDQo+ID4gPiA+PiA+IGF0DQo+ID4gPiB0b29scy5pZXRmLm9yZzxodHRw Oi8vdG9vbHMuaWV0Zi5vcmc+Lg0KPiA+ID4gPj4gPg0KPiA+ID4gPj4gPiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KPiA+ID4gPj4NCj4gPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPiA+PiBJZHIgbWFpbGluZyBsaXN0DQo+ID4gPiA+PiBJ ZHJAaWV0Zi5vcmc8bWFpbHRvOklkckBpZXRmLm9yZz4NCj4gPiA+ID4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+ID4gPiA+DQo+ID4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IElkciBtYWlsaW5n IGxpc3QNCj4gPiA+ID4gSWRyQGlldGYub3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+DQo+ID4gPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRy QGlldGYub3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcg0KDQo= --_000_61DC6BC4ABA10E4489D4A73EBABAC18B019C9149EX01swanlocal_ 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 LXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj5Ob3cg dGhhdCB5b3UgbWVudGlvbmVkIGl0IHllcyB0aGF04oCZcyBleGFjdGx5IHRoZSBkZXNpcmVkIGJl aGF2aW9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwMjA2MCI+SSBzZWUgbm8gcG9pbnQgaW4gZm9yY2luZyBhIEJHUCBzcGVha2Vy IHRvIGFjY2VwdCBpdHMgb3duIFJUIG1lbWJlcnNoaXAgTlJMSSBpbiBvcmRlciB0byBzdGFydCBh ZHZlcnRpc2luZyBOUkxJcyB3aXRoIHRoaXMgUlQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIw NjAiPkkgbWVhbiBpZiB0aGVyZeKAmXMgbm8gb3RoZXIgUlQgbWVtYmVyc2hpcCBOUkxJIGZvciBh IHBhcnRpY3VsYXIgUlQsIHRoYW4gbm8gb25lIHJlYWxseSB3YW50cyB0byBrbm93IHRoZSBOUkxJ cyB3aXRoIHRoaXMgcGFydGljdWxhciBSVC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPmFkYW08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2h5YW0gU2V0aHVyYW0gW21haWx0bzpzaHlh bS5pb21sQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDAxLCAy MDE0IDI6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IFZpdGtvdnNrw70gQWRhbTxicj4NCjxiPkNjOjwv Yj4gRG9uZ2ppZSAoSmltbXkpOyBSb2JlcnQgUmFzenVrOyBpZHJAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt ZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJbiBvcmRlciB0 byBzdGFydCBsZWFybmluZyB0aGUgTlJMSXMgUlIgaGFzIHRvIGFkdmVydGlzZSBhIGRlc2lyZSB0 byByZWNlaXZlIHRoZW0gYW5kIHRvIGRvIHRoYXQgd2UgY2FuIHVzZSBtb2RpZmllZCBydWxlIDMu Mi5paS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7V2hlbiBhZHZlcnRpc2luZyBh biBSVCBtZW1iZXJzaGlwIE5MUkkgdG8gYSBjbGllbnQgcGVlciwgaWY8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7dGhlIGJlc3QgcGF0aCBhcyBzZWxlY3RlZCBieSB0aGUgcGF0aCBzZWxlY3Rp b24gcHJvY2VkdXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Rlc2NyaWJlZCBpbiBTZWN0 aW9uIDkuMSBvZiB0aGUgYmFzZSBCR1Agc3BlY2lmaWNhdGlvbiBbNF0gaXMgYTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtyb3V0ZSByZWNlaXZlZCBmcm9tIHRoYXQgY2xpZW50IHBlZXIgaW4g cGFydGljdWxhciwgYW5kIGlmIHRoZXJlIGlzIGFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2FsdGVybmF0aXZlIHBhdGggdG8gdGhlIHNhbWUgZGVzdGluYXRpb24gZnJvbSBhbm90aGVyIGNs aWVudCBvciBhIG5vbi1jbGllbnQsIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthdHRy aWJ1dGVzIG9mIHRoZSBvdGhlciBwYXRoIGFyZSBhZHZlcnRpc2VkIHRvIHRoZSBwZWVyLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyBOb3cgdGhpbmtpbmcgYWJvdXQgaXQgb25seSBvbmUgcnVsZSBmb3IgcmVmbGVjdGlvbiBvZiBS VCBtZW1iZXJzaGlwIE5MUkkgaXMgZW5vdWdoIEkgZ3Vlc3MuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IElmIHlvdSByZWNlaXZlZCBSVCBt ZW1iZXJzaGlwIE5MUkkgZnJvbSBvbmx5IG9uZSBwZWVyIGRvbid0IGFkdmVydGlzZSBpdCB1bnRp bCB5b3UgaGF2ZSByZWNlaXZlZCB0aGUgUlQgbWVtYmVyc2hpcCBOTFJJIHdpdGggdGhlIHNhbWUg UlQgZnJvbSBhbm90aGVyIHBlZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFRoZW4geW91IGNhbiBhZHZlcnRpc2UgdGhlIGFsdGVybmF0 ZSAobm90IHRoZSBvbmUgdGhhdCB0aGUgcGVlciBzZW50IHlvdSkgUlQgbWVtYmVyc2hpcCBOTFJJ IHRvIGEgZ2l2ZW4gcGVlciAoc2ltcGxlIHNwbGl0IGhvcml6b24pLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNvdW5kcyBsaWtlIGJl c3QtZXh0ZXJuYWwgYWR2ZXJ0aXNlbWVudCA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oU2VjdGlvbiA1LCZuYnNwO2RyYWZ0LWlldGYtaWRyLWJl c3QtZXh0ZXJuYWwtMDUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnNoeWFtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVuIDI3LCAyMDE0 IGF0IDQ6NTIgQU0sIFZpdGtvdnNrw70gQWRhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW0udml0 a292c2t5QHN3YW4uc2siIHRhcmdldD0iX2JsYW5rIj5hZGFtLnZpdGtvdnNreUBzd2FuLnNrPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBmb2xr cyw8YnI+DQo8YnI+DQpSZWdhcmRpbmcgdGhlIHJ1bGUgMy4yLmkgb2YgUkZDNDY4NC48YnI+DQo8 YnI+DQpGaXJzdCBjb25zaWRlciBzY2VuYXJpbyBhKTo8YnI+DQphKTxicj4NClJSLS0tLVBFMTxi cj4NCjxicj4NCldoeSB3b3VsZCBJIHdhbnQgdGhlIFJSIHRvIGxlYXJuIHRoZSBQRSdzIHByZWZp eGVzIGlmIHRoZXJlJ3Mgbm8gb25lIGludGVyZXN0ZWQgaW4gdGhlbSAobm8gb3RoZXIgY2xpZW50 cyBpbnRlcmVzdGVkIHRvIHJlY2VpdmUgTlJMSSBmb3IgZ2l2ZW4gUlRzKSBhcyBQRTEgaXMgdGhl IG9ubHkgb25lIHRoYXQgYWR2ZXJ0aXNlZCB0aGUgUm91dGUgVGFyZ2V0IG1lbWJlcnNoaXAgaW5m b3JtYXRpb24gdG8gUlIuPGJyPg0KPGJyPg0KTm93IGxldCdzIGNvbnNpZGVyIHNjZW5hcmlvIGIp Ojxicj4NCmIpPGJyPg0KUEUyLS0tLVJSLS0tLVBFMTxicj4NCjxicj4NCk5vdyB0aGVyZSBpcyBh bm90aGVyIGNsaWVudCAoUEUyKSBjb25uZWN0ZWQgdG8gdGhlIFJSIGFuZCBpdCBoYXBwZW5zIHRv IGJlIGludGVyZXN0ZWQgaW4gcmVjZWl2aW5nIE5STEkgZm9yIGEgZ2l2ZW4gUlQgYXMgZGVzaWdu YXRlZCBieSB0aGUgYWR2ZXJ0aXNlZCBSb3V0ZSBUYXJnZXQgbWVtYmVyc2hpcCBpbmZvcm1hdGlv biBmb3IgdGhlIGdpdmVuIFJULjxicj4NCk9rIG5vdyB0aGF0IHRoZXJlIGFyZSBpbnRlcmVzdGVk IHJlY2VpdmVycyBmb3IgYSBnaXZlbiBOUkxJIG9uIGJvdGggc2Vzc2lvbnMgLSBSUiBzaG91bGQg c3RhcnQgbGVhcm5pbmcgdGhlIE5STElzIGZyb20gY2xpZW50cyBzbyB0aGF0IGl0IGNhbiBkaXNz ZW1pbmF0ZSB0aGUgaW5mb3JtYXRpb24gYWNjb3JkaW5nbHkuPGJyPg0KPGJyPg0KSW4gb3JkZXIg dG8gc3RhcnQgbGVhcm5pbmcgdGhlIE5STElzIFJSIGhhcyB0byBhZHZlcnRpc2UgYSBkZXNpcmUg dG8gcmVjZWl2ZSB0aGVtIGFuZCB0byBkbyB0aGF0IHdlIGNhbiB1c2UgbW9kaWZpZWQgcnVsZSAz LjIuaWkuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFdoZW4gYWR2ZXJ0 aXNpbmcgYW4gUlQgbWVtYmVyc2hpcCBOTFJJIHRvIGEgY2xpZW50IHBlZXIsIGlmPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBiZXN0IHBhdGggYXMgc2VsZWN0ZWQgYnkgdGhl IHBhdGggc2VsZWN0aW9uIHByb2NlZHVyZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBkZXNjcmliZWQgaW4gU2VjdGlvbiA5LjEgb2YgdGhlIGJhc2UgQkdQIHNwZWNpZmljYXRpb24g WzRdIGlzIGE8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcm91dGUgcmVjZWl2ZWQg ZnJvbSB0aGF0IGNsaWVudCBwZWVyIGluIHBhcnRpY3VsYXIsIGFuZCBpZiB0aGVyZSBpcyBhbjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhbHRlcm5hdGl2ZSBwYXRoIHRvIHRoZSBz YW1lIGRlc3RpbmF0aW9uIGZyb20gYW5vdGhlciBjbGllbnQgb3IgYSBub24tY2xpZW50LCB0aGU8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYXR0cmlidXRlcyBvZiB0aGUgb3RoZXIg cGF0aCBhcmUgYWR2ZXJ0aXNlZCB0byB0aGUgcGVlci48YnI+DQo8YnI+DQpOb3cgdGhpbmtpbmcg YWJvdXQgaXQgb25seSBvbmUgcnVsZSBmb3IgcmVmbGVjdGlvbiBvZiBSVCBtZW1iZXJzaGlwIE5M UkkgaXMgZW5vdWdoIEkgZ3Vlc3MuPGJyPg0KSWYgeW91IHJlY2VpdmVkIFJUIG1lbWJlcnNoaXAg TkxSSSBmcm9tIG9ubHkgb25lIHBlZXIgZG9uJ3QgYWR2ZXJ0aXNlIGl0IHVudGlsIHlvdSBoYXZl IHJlY2VpdmVkIHRoZSBSVCBtZW1iZXJzaGlwIE5MUkkgd2l0aCB0aGUgc2FtZSBSVCBmcm9tIGFu b3RoZXIgcGVlci48YnI+DQpUaGVuIHlvdSBjYW4gYWR2ZXJ0aXNlIHRoZSBhbHRlcm5hdGUgKG5v dCB0aGUgb25lIHRoYXQgdGhlIHBlZXIgc2VudCB5b3UpIFJUIG1lbWJlcnNoaXAgTkxSSSB0byBh IGdpdmVuIHBlZXIgKHNpbXBsZSBzcGxpdCBob3Jpem9uKS48YnI+DQo8YnI+DQpUaGVuIHRoZXJl J3Mgbm8gbmVlZCB0byBtb2RpZnkgdGhlIHVwZGF0ZSBzbyB0aGF0IGl0IGNhbiBiZSBhY2NlcHRl ZCBieSB0aGUgb3JpZ2luYXRvciAoYXMgaW4gMy4yLmkuKS48YnI+DQpBbmQgdGhpcyBhbHNvIHNv bHZlcyB0aGUgaGllcmFyY2hpY2FsIFJSIHByb2JsZW0gYXMgd2VsbC48YnI+DQo8YnI+DQo8YnI+ DQpJJ2QgbGlrZSB0aGUgdGhpbmsgb2YgaXQgYXMgd2l0aCBtdWx0aWNhc3QgZmxvdyB3aGVyZSBS UiBpcyBsaWtlIFJQIGFuZCBQRXMgYXJlIGxpa2UgU291cmNlcyAmIzQzOyBSZWNlaXZlcnMuPGJy Pg0KVGhlcmUncyBubyBuZWVkIGZvciB0aGUgUlAgKFJSKSB0byByZWNlaXZlIHRoZSBtY2FzdCBz dHJlYW0gKGUuZy4gVlBOIFByZWZpeGVzKSB3aGVuIHRoZXJlJ3MganVzdCBvbmUgU291cmNlL1Jl Y2VpdmVyIChQRSkgY29ubmVjdGVkIHRvIGl0Ljxicj4NCkEgc2ltcGxlIHN0YXRlIG9uIHRoZSBS UCBzYXlpbmcgdGhlcmUgaXMgYSBwYXJ0aWN1bGFyIHN0cmVhbSBhdmFpbGFibGUgYXQgdGhpcyBw YXJ0aWN1bGFyIHNvdXJjZSBpcyBlbm91Z2ggKGkuZS4gUlQgbWVtYmVyc2hpcCBOTFJJIG9uIFJS KS48YnI+DQpPbmNlIG90aGVyIHNvdXJjZS9yZWNlaXZlcnMgKFBFcykgYXJlIGNvbm5lY3RlZCB0 byB0aGUgUlAoUlIpIGFuZCBzaWduYWwgdGhlaXIgZGVzaXJlIHRvIHJlY2VpdmUgdGhlIHN0cmVh bSAodmlhIFJUIG1lbWJlcnNoaXAgTkxSSSkuPGJyPg0KVGhlbiBSUCAoUlIpIGRlY2lkZXMgdGhl IGRlc2lyZSByZWNlaXZlIHRoZSBzdHJlYW0gKFJUIG1lbWJlcnNoaXAgTkxSSSkgaXMgd29ydGgg c3ByZWFkaW5nIGFuZCBkaXNzZW1pbmF0ZXMgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBpbnRlcmVz dGVkIHNvdXJjZXMvcmVjZWl2ZXJzIChQRXMpLjxicj4NCk9uY2UgdGhhdCBoYXBwZW5zIHNvdXJj ZXMvcmVjZWl2ZXJzIChQRXMpIHdpbGwgc3RhcnQgc2VuZGluZyB0aGUgbWNhc3Qgc3RyZWFtIChl LmcuIFZQTiBQcmVmaXhlcykgdG93YXJkcyB0aGUgUlAgKFJSKSB3aGljaCB0aGFuIHJlZmxlY3Rz IHRoaXMgbWNhc2Ugc3RyZWFtcyB0byBhbGwgaW50ZXJlc3RlZCBzb3VyY2VzL3JlY2VpdmVycyAo UEVzKS48YnI+DQo8YnI+DQo8YnI+DQpJIGJlbGlldmUgdGhlIGNvbmNlcm5zIHByZXNlbnRlZCBp biBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTAwIGNvdWxkIGJlIHJlc29sdmVk IGJ5IGFkZC1wYXRoIHdoZXJlIGF0IGxlYXN0IG9uZSBhZGRpdGlvbmFsIHBhdGggaXMgYWR2ZXJ0 aXNlZCBhbG9uZyB3aXRoIHRoZSBiZXN0LXBhdGguPGJyPg0KQnV0IHN0aWxsIHJ1bGUgMy4yLmku IGluIFJGQzQ2ODQgaXMgdmVyeSBoYXJtZnVsIGluIHNjZW5hcmlvcyB3aGVyZSBSUnMgYXJlIGNs aWVudHMgb2Ygb3RoZXIgUlJzIChzYW1lIGxldmVsIG9yIGRpZmZlcmVudCBsZXZlbCkuPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7YWRhbTxicj4NCjxicj4NCjxicj4NCiZndDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IERvbmdqaWUgKEppbW15KSBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzpqaWUuZG9uZ0BodWF3ZWkuY29tIj5qaWUuZG9uZ0BodWF3ZWku Y29tPC9hPl08YnI+DQomZ3Q7IFNlbnQ6IE1vbmRheSwgSnVuZSAyMywgMjAxNCA0OjU5IEFNPGJy Pg0KJmd0OyBUbzogVml0a292c2vDvSBBZGFtOyBSb2JlcnQgUmFzenVrPGJyPg0KJmd0OyBDYzog PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPjxicj4NCiZndDsg U3ViamVjdDogUkU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZG9u Zy1pZHItcnRjLWhpZXJhcmNoaWNhbC08YnI+DQomZ3Q7IHJyLTAwLnR4dDxicj4NCiZndDs8YnI+ DQomZ3Q7IEhpIEFkYW0sPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgUkQgaXMgcGFydCBvZiB0aGUg UlRDIHJvdXRlcywgdGhpcyBwcm9ibGVtIHdpbGwgbm90IG9jY3VyOikgV2hpbGUgYXMgYW5hbHl6 ZWQ8YnI+DQomZ3Q7IGluIHJmYyA0Njg0LCB0aGlzIHJlcXVpcmVzIG1vcmUgUlRDIHJvdXRlcyBi ZWluZyBleGNoYW5nZWQgYW5kIGtlcHQgaW4gdGhlPGJyPg0KJmd0OyBsb2NhbCBBUy48YnI+DQom Z3Q7PGJyPg0KJmd0OyBJIGFncmVlIHRoYXQgYWRkLXBhdGggaXMgYSBjYW5kaWRhdGUgc29sdXRp b24gdG8gdGhpcyBwcm9ibGVtLCB3aGlsZSB3aGVuPGJyPg0KJmd0OyBlbmFibGluZyBhZGQtcGF0 aCBvbiBSVEMgQUZJL1NBRkksIHdlIHN0aWxsIG5lZWQgdG8gc3BlY2lmeSB0aGUgcnVsZXMgb2Yg d2hpY2g8YnI+DQomZ3Q7IFJUQyByb3V0ZXMgc2hvdWxkIGJlIGFkdmVydGlzZWQgdG8gc29sdmUg dGhpcyBwcm9ibGVtLiBPciB3ZSBqdXN0IHVwZGF0ZSB0aGU8YnI+DQomZ3Q7IHJ1bGVzIG9mIFJU QyBhZHZlcnRpc2VtZW50IGFzIHRoZSBvdGhlciBSVEMgcmVsYXRlZCBuZXcgZHJhZnRzPzxicj4N CiZndDs8YnI+DQomZ3Q7IE1hbnkgdGhhbmtzLDxicj4NCiZndDsgSmllPGJyPg0KJmd0Ozxicj4N CiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9t OiBWaXRrb3Zza8O9IEFkYW0gW21haWx0bzo8YSBocmVmPSJtYWlsdG86YWRhbS52aXRrb3Zza3lA c3dhbi5zayI+YWRhbS52aXRrb3Zza3lAc3dhbi5zazwvYT5dPGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6 IFN1bmRheSwgSnVuZSAyMiwgMjAxNCAzOjIwIEFNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBSb2JlcnQg UmFzenVrPGJyPg0KJmd0OyAmZ3Q7IENjOiBEb25namllIChKaW1teSk7IDxhIGhyZWY9Im1haWx0 bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgU3ViamVjdDog UkU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I8YnI+DQomZ3Q7ICZndDsgZHJh ZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQ8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgQWFoIEkgc2VlIDopPGJyPg0KJmd0OyAmZ3Q7IFdlbGwgd2UgY291bGQgaGF2 ZSB0aGF0IG9uZSBzb2x2ZWQgaWYgUkQgd291bGQgYmUgcGFydCBvZiB0aGUgUlRDPGJyPg0KJmd0 OyAmZ3Q7IHJvdXRlcyA6KSAodGhvdWdoIEkgdW5kZXJzdGFuZCBvbmUgY291bGQgdXNlIFJUQyBm b3Igbm9uIFZQTiByb3V0ZXMgYXM8YnI+DQomZ3Q7ICZndDsgd2VsbCBzby4uLikgQW55d2F5cyBz byB0aGFuIGFzIHlvdSBtZW50aW9uZWQgYWRkLXBhdGggb24gdGhlIFJUQyBBRjxicj4NCiZndDsg Jmd0OyBzZWVtcyBhcyB0aGUgYmVzdCBvcHRpb24gdGhlbi48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgYWRhbTxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOnJyYXN6dWtAZ21h aWwuY29tIj5ycmFzenVrQGdtYWlsLmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnJh c3p1a0BnbWFpbC5jb20iPnJyYXN6dWtAZ21haWwuY29tPC9hPl0gT24gQmVoYWxmIE9mPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgUm9iZXJ0IFJhc3p1azxicj4NCiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFNh dHVyZGF5LCBKdW5lIDIxLCAyMDE0IDc6NTIgUE08YnI+DQomZ3Q7ICZndDsgJmd0OyBUbzogVml0 a292c2vDvSBBZGFtPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ2M6IERvbmdqaWUgKEppbW15KTsgPGEg aHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0 OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbSWRyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC0gcnItMDAu dHh0PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBIaSBBZGFtLDxicj4N CiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSmllIGlzIGRlc2NyaWJpbmcgUlQg cm91dGVzIG5vdCBWUE4gcm91dGVzLiBZb3VyIHN0b3J5IGRvZXMgbm90PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgYXBwbHkgdG8gUlQgcm91dGVzIGFzIGZvcm1hdCBvZiBSVCBOTFJJIGlzIHdlbGwgZGVm aW5lZCBieSBSRkMgOyk8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEJl c2lkZXMgTVBMUyBuZXR3b3JrIG9yIG5vdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIGl0IC4uLi48 YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEJlc3QsPGJyPg0KJmd0OyAm Z3Q7ICZndDsgUi48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIFNh dCwgSnVuIDIxLCAyMDE0IGF0IDc6MTkgUE0sIFZpdGtvdnNrw70gQWRhbTxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbS52aXRrb3Zza3lAc3dhbi5zayI+YWRhbS52 aXRrb3Zza3lAc3dhbi5zazwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgd3JvdGU6PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBIaSBKaWUsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBXZWxs IHRoZSBjb3JyZWN0bHkgZGVzaWduZWQgTVBMUyBuZXR3b3JrcyB1c2UgdW5pcXVlIHBlciBQRSBw ZXI8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFZSRiBSRHM8YnI+DQomZ3Q7ICZndDsgJmd0OyBp biBmb3JtIG9mIFJJRDp4eHh4eC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFVuaXF1ZSBwZXIg UEUgUkRzIG1ha2VzIGFsbCBjb3BpZXMgb2YgdGhlIHNhbWUgVlBOIHByZWZpeCByZWNlaXZlZDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZnJvbTxicj4NCiZndDsgJmd0OyAmZ3Q7IGRpZmZlcmVu dCBQRXMgdW5pcXVlIHNvIFJScyB3aWxsIHNlbGVjdCBhbGwgYXMgYmVzdCBwYXRoIGFuZDxicj4N CiZndDsgJmd0OyAmZ3Q7IGRpc3RyaWJ1dGUgdGhlbSBhY2NvcmRpbmdseSwgd2hpY2ggc29sdmVz IHRoaXMgYW5kIG1hbnkgb3RoZXIgaXNzdWVzLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEluIG90aGVyIHdvcmRzIGlmIHNvbWVvbmUgdHJpZXMgdG8g c2hvb3QgaGltc2VsZiBpbiB0aGUgZm9vdCBJPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB3b3Vs ZG4ndDxicj4NCiZndDsgJmd0OyAmZ3Q7IGRldmVsb3AgYnVsbGV0cHJvb2YgYm9vdHMgZm9yIGhp bS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhZGFt PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBGcm9tOiBJZHIgW21haWx0bzo8YSBocmVmPSJt YWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmciPmlkci1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24g QmVoYWxmIE9mIERvbmdqaWU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAoSmltbXkpPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgU2VudDogRnJpZGF5LCBKdW5lIDIwLCAyMDE0IDQ6 NTUgQU08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOmlk ckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7 IFN1YmplY3Q6IFtJZHJdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyZndDsgZHJhZnQtZG9uZy1pZHItcnRjLSBoaWVyYXJjaGljYWwtcnIt MDAudHh0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7Jmd0OyBIaSBhbGwsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7Jmd0OyBUaGlzIGlzIGEgc2hvcnQgZHJhZnQgdG8gbWFrZSBSVEMgYXBwbGlj YWJsZSBpbiBoaWVyYXJjaGljYWwgUlIgc2NlbmFyaW8uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBDb21tZW50cyBhcmUgd2VsY29tZS48 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7 IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBKaWU8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQ8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmll IERvbmcgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 IElFVEY8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyByZXBvc2l0b3J5Ljxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 IE5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBk cmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyZndDsgJmd0OyBSZXZpc2lvbjogJm5ic3A7IDAwPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZn dDsgJmd0OyBUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7RXh0ZW5zaW9ucyB0byBSVC1Db25zdHJhaW4gaW4gSGllcmFyY2hpY2FsIFJvdXRlPGJy Pg0KJmd0OyAmZ3Q7IFJlZmxlY3Rpb248YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 IFNjZW5hcmlvczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgRG9jdW1lbnQgZGF0 ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsyMDE0LTA2LTE5PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyZndDsgJmd0OyBHcm91cDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZn dDsgJmd0OyBQYWdlczogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7NTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgVVJMOjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kb25nLWlkci1ydGMt aGllcmFyY2g8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBpYzxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgYWw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7IC1ycjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgLTAwLnR4dDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgU3RhdHVzOjxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2E8 L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBsLTxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsmZ3Q7ICZndDsgcnI8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IC88 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEh0bWxpemVkOjxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2Fs LXJyLTA8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAwPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RoZSBSb3V0ZSBUYXJnZXQgKFJUKSBD b25zdHJhaW4gbWVjaGFuaXNtIHNwZWNpZmllZCBpbiBSRkMgNDY4NCBpczxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3VzZWQgdG8gYnVpbGQgYSByb3V0ZSBk aXN0cmlidXRpb24gZ3JhcGggaW4gb3JkZXIgdG8gcmVzdHJpY3QgdGhlPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7cHJvcGFnYXRpb24gb2YgVmlydHVhbCBQ cml2YXRlIE5ldHdvcmsgKFZQTikgcm91dGVzLiAmbmJzcDtJbiBuZXR3b3JrPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7c2NlbmFyaW9zIHdoZXJlIGhpZXJh cmNoaWNhbCByb3V0ZSByZWZsZWN0aW9uIChSUikgaXMgdXNlZCwgdGhlPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ZXhpc3RpbmcgUlQtQ29uc3RyYWluIG1l Y2hhbmlzbSBjYW5ub3QgYnVpbGQgYSBjb3JyZWN0IHJvdXRlPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ZGlzdHJpYnV0aW9uIGdyYXBoLiAmbmJzcDtUaGlz IGRvY3VtZW50IHJlZmluZXMgdGhlIHJvdXRlIGRpc3RyaWJ1dGlvbjxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3J1bGVzIG9mIFJULUNvbnN0cmFpbiB0byBh ZGRyZXNzIHRoZSBoaWVyYXJjaGljYWwgUlIgc2NlbmFyaW9zLjxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyZndDsgJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgb2Yg c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBhdDxicj4NCiZndDsgJmd0OyAm Z3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRvb2xz LmlldGYub3JnPC9hPi48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jmd0OyBJZHIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsg PGEgaHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyI+SWRyQGlldGYub3JnPC9hPjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWRyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZHI8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IElkciBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpJZHJAaWV0Zi5vcmciPklkckBpZXRmLm9yZzwv YT48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWRyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZHI8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZHIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOklkckBpZXRmLm9yZyI+SWRyQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHI8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_61DC6BC4ABA10E4489D4A73EBABAC18B019C9149EX01swanlocal_-- From nobody Tue Jul 1 01:03:42 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7654A1B27D7 for ; Tue, 1 Jul 2014 01:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzm2Ym8mFImq for ; Tue, 1 Jul 2014 01:03:38 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ABDE1A0199 for ; Tue, 1 Jul 2014 01:03:38 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: Jeffrey Haas Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//+xkgIAAOCmwgAHzEgCABv+DcIAFCRwAgAD7KsA= Date: Tue, 1 Jul 2014 08:03:36 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B019C918D@EX01.swan.local> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> <20140630184522.GC11842@pfrc> In-Reply-To: <20140630184522.GC11842@pfrc> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.40.93] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/17sS5SIY-pwrc2Oyg5tgm3MPTGE Cc: Robert Raszuk , "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 08:03:39 -0000 Jeff, >=20 > Adam, >=20 > On Fri, Jun 27, 2014 at 11:52:33AM +0000, Vitkovsk?? Adam wrote: > > Hi folks, > > > > Regarding the rule 3.2.i of RFC4684. > > > > First consider scenario a): > > a) > > RR----PE1 > > > > Why would I want the RR to learn the PE's prefixes if there's no one > interested in them (no other clients interested to receive NRLI for given= RTs) > as PE1 is the only one that advertised the Route Target membership > information to RR. > > > > Now let's consider scenario b): > > b) > > PE2----RR----PE1 >=20 > PE1 and PE2 advertise RT-C route R to RR. > RR selects one of R(PE1) or R(PE2). > It then would go to reflect that route back to the originator. >=20 > Using standard rules, even with modification, loop suppression occurs eit= her > by the originator or via proxy at the reflector. >=20 And I think it's a good think.=20 > The rule accommodates this case. The fact that it also incidentally serv= es as > an attractor to the RR can be perceived as a bug or as a feature. Mostly= it > tends to be viewed as a feature. >=20 As I have mentioned already if there's no other RT membership NRLI for a pa= rticular RT, than no one really wants to know the NRLIs with this particula= r RT.=20 > > I believe the concerns presented in draft-dong-idr-rtc-hierarchical-rr-= 00 > could be resolved by add-path where at least one additional path is > advertised along with the best-path. > > But still rule 3.2.i. in RFC4684 is very harmful in scenarios where RRs= are > clients of other RRs (same level or different level). >=20 > My current thinking is that add-path - within the RR hierarchy only - is > perhaps a sufficient solution to this problem. This would avoid the need= to > implement RT-C add-path at the PEs, an important detail for faster > deployment of a fix for this issue. (I have my doubts about the number o= f > providers currently experiencing this issue.) >=20 Yes please certainly add-path only between RRs, there's absolutely no need = for add-path between PEs and RRs.=20 >=20 > A rough version of a proposal using add-path only among reflectors would > look like the following: >=20 > Reflector clients are tagged as being route-reflectors or not via configu= ration. > Among RR clients that are also RRs: > - Do not use 4684 3.2.i/ii > - RT-C paths are advertised using add-path with the ORIGINATOR attribute > preserved as it would otherwise be attached by a RR not doing 3.2.i >=20 I believe the above could be used with any type of route-reflection RR-to-R= R or RR-to-PE.=20 > The above procedure would permit routes received by the edge of a > hierarchy of RRs to pass along RT-C routes within the hierarchy and build= a > loop-free graph following standard BGP distribution rules. >=20 > At a RR that has as candidates RT-C routes either non-hierarchy routes or > hierarchy routes, active route selection is performed as normal. When > advertising to non-RR client routers, 3.2.i is performed. This ensures t= hat an > active path selected using best-path originating from that router may be > advertised back as per above. >=20 > (Similarly follow 3.2.ii, if necessary.) >=20 > I have that nagging feeling that I've missed an important detail, so the = above > may not survive scrutiny. (But that's how engineering and science is > supposed to work.) >=20 > -- Jeff adam From nobody Tue Jul 1 10:35:50 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95D41A03B0 for ; Tue, 1 Jul 2014 10:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dksCWopkvCoS for ; Tue, 1 Jul 2014 10:35:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B571A03A4 for ; Tue, 1 Jul 2014 10:35:44 -0700 (PDT) Received: from jfarrell-sslvpn-nc.jnpr.net (66.129.241.14) by CO2PR05MB729.namprd05.prod.outlook.com (10.141.228.12) with Microsoft SMTP Server (TLS) id 15.0.980.8; Tue, 1 Jul 2014 17:35:43 +0000 From: John Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jul 2014 13:35:36 -0400 Message-ID: To: "idr@ietf.org List" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BLUPR06CA008.namprd06.prod.outlook.com (10.255.223.146) To CO2PR05MB729.namprd05.prod.outlook.com (10.141.228.12) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02596AB7DA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(164054003)(189002)(199002)(54014002)(92726001)(83322001)(50226001)(4396001)(69596002)(53416004)(77096002)(36756003)(95666004)(79102001)(105586002)(104166001)(33656002)(85306003)(47776003)(46406003)(62966002)(20776003)(102836001)(64706001)(80022001)(101416001)(66066001)(46102001)(81342001)(81542001)(77156001)(74662001)(42186005)(93916002)(82746002)(86362001)(57306001)(76482001)(23726002)(97756001)(50466002)(74502001)(21056001)(99396002)(88136002)(87976001)(106356001)(89996001)(83072002)(85852003)(77982001)(229853001)(50986999)(107046002)(87286001)(83716003)(81156004)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB729; H:jfarrell-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/lo8mFotusnqwqZXRvCWIsDh5EHY Cc: Hares Susan Subject: [Idr] IETF-90 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 17:35:47 -0000 Folks, We're planning to meet at IETF-90 on Tuesday, July 22, from 9:00 to = 11:30. Please forward any IDR agenda items you might have to Sue and = myself. The deadline is July 7 (this coming Monday) by 10:00 U.S. = Eastern Time. Priority will be given to those who get their requests in = by the deadline, though in light of the lateness of this announcement, = if agenda space permits it we will consider requests gotten in before = July 14 at 10:00 U.S. Eastern Time. If you have previously presented on your topic at an IDR meeting, please = explain in your request what you hope to achieve with your presentation = this time. If you have requested to present the same work at multiple = WGs, please note this so that we can coordinate as needed. If you plan to make a presentation, please keep in mind the IDR = tradition, "no Internet Draft - no time slot". You should also plan to = send your slides to Sue and me no later than 24 hours prior to the = meeting, though again, earlier is better. Finally, if you request an agenda slot, please do so by replying to this = message, making sure to include both Sue and me in the To: or Cc: and = don't change the subject line. Thanks, --John & Sue From nobody Tue Jul 1 11:04:30 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E521A03BD for ; Tue, 1 Jul 2014 11:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI9JjSLHef1p for ; Tue, 1 Jul 2014 11:04:27 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 123261A0395 for ; Tue, 1 Jul 2014 11:04:27 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 924B7C17F; Tue, 1 Jul 2014 14:04:26 -0400 (EDT) Date: Tue, 1 Jul 2014 14:04:26 -0400 From: Jeffrey Haas To: John Scudder Message-ID: <20140701180426.GD16649@pfrc> References: 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: http://mailarchive.ietf.org/arch/msg/idr/VdlSrKPZGgrvx3QKVaG4GsfbwA4 Cc: "idr@ietf.org List" , Hares Susan Subject: Re: [Idr] IETF-90 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 18:04:28 -0000 John and Sue, On Tue, Jul 01, 2014 at 01:35:36PM -0400, John Scudder wrote: > We're planning to meet at IETF-90 on Tuesday, July 22, from 9:00 to 11:30. Please forward any IDR agenda items you might have to Sue and myself. The deadline is July 7 (this coming Monday) by 10:00 U.S. Eastern Time. Priority will be given to those who get their requests in by the deadline, though in light of the lateness of this announcement, if agenda space permits it we will consider requests gotten in before July 14 at 10:00 U.S. Eastern Time. I'd like to recommend at the very least a "RT-Constrain errata track". The following documents all have popped up in list discussion to deal with various issues: draft-rosen-idr-rtc-no-rt-00 draft-litkowski-idr-rtc-interas-00 draft-dong-idr-rtc-hierarchical-rr -- Jeff From nobody Wed Jul 2 06:06:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C4A1A00AB for ; Wed, 2 Jul 2014 06:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3XbLGFtjRBO for ; Wed, 2 Jul 2014 06:06:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 05F281A009E for ; Wed, 2 Jul 2014 06:06:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9096CC20F; Wed, 2 Jul 2014 09:06:33 -0400 (EDT) Date: Wed, 2 Jul 2014 09:06:33 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20140702130633.GF16649@pfrc> References: <00ea01cf9188$96f0d8a0$c4d289e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ea01cf9188$96f0d8a0$c4d289e0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/0gjXB_N4M8L2E4CaxSOeFPwHKJQ Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 13:06:37 -0000 On Thu, Jun 26, 2014 at 05:50:04PM -0400, Susan Hares wrote: > This is to begin a 2 week WG LC staring 6/26/14, and ending on 6/11/14 for > the draft: > > draft-ietf-idr-flowspec-redirect-rt-bis. > > http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ > > Please indicate in your comments: Support yes/no. On the off-hand chance that people have exercised treat-as-withdraw behavior on this message due to the date range error, this is a reminder that this is a simple janitorial draft intended to document deployed behavior. It's a short draft. Please provide WG blessing for this so we can send it off to the RFC editor's queue and provide to our Area Directors that we can get things done expeditiously. :-) -- Jeff From nobody Thu Jul 3 07:21:13 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D2B1B2A71 for ; Thu, 3 Jul 2014 07:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F15oNJADGKVq for ; Thu, 3 Jul 2014 07:21:09 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EBB1B2A6D for ; Thu, 3 Jul 2014 07:21:09 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:54213 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X2hsq-0003tk-9k for idr@ietf.org; Thu, 03 Jul 2014 14:21:08 +0000 From: "Russ White" To: Date: Thu, 3 Jul 2014 10:21:03 -0400 Message-ID: <021e01cf96ca$06339e00$129ada00$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+WydxSZNHBfR79Q52Sx0xMSiTI5w== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/BwTgpo5uhNmxScBli9xdVV3-baQ Subject: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:21:11 -0000 Y'all: The intent for draft-white-bgpbgp-00.txt is to provide an alternative to the various stuff we've been doing with address families to carry odds and ends and bits of data in BGP... If anyone has comments, please push them to the list. :-) Russ From nobody Fri Jul 4 00:05:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE25C1B2C24; Fri, 4 Jul 2014 00:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG4OW1Ak_WaN; Fri, 4 Jul 2014 00:05:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 519E71B2C27; Fri, 4 Jul 2014 00:05:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704070535.16163.90030.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 00:05:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/qkkTgJTK-t9nbi4qQ4RtSIOfopY Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 07:05:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Distribution of MPLS Traffic Engineering (TE) LSP State using BGP Authors : Jie Dong Mach(Guoyi) Chen Hannes Gredler Stefano Previdi Jeff Tantsura Filename : draft-ietf-idr-te-lsp-distribution-01.txt Pages : 10 Date : 2014-07-04 Abstract: This document describes a mechanism to collect the Traffic Engineering (TE) LSP information using BGP. Such information can be used by external components for path reoptimization, service placement and network visualization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distribution/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-lsp-distribution-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 01:39:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91E31B2C83; Fri, 4 Jul 2014 01:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB21dya1jzkR; Fri, 4 Jul 2014 01:39:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 591691B2C87; Fri, 4 Jul 2014 01:38:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704083859.19428.7177.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 01:38:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/eQg9lwHPeoSYns6Jgho7oTEb4i4 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-te-pm-bgp-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 08:39: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 Working Group of the IETF. Title : BGP attribute for North-Bound Distribution of Traffic Engineering (TE) performance Metrics Authors : Qin Wu Stefano Previdi Hannes Gredler Saikat Ray Jeff Tantsura Filename : draft-ietf-idr-te-pm-bgp-01.txt Pages : 9 Date : 2014-07-04 Abstract: In order to populate network performance information like link latency, latency variation, packet loss and bandwidth into Traffic Engineering Database(TED) and ALTO server, this document describes extensions to BGP protocol, that can be used to distribute network performance information (such as link delay, delay variation, packet loss, residual bandwidth, available bandwidth and utilized bandwidth ). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-pm-bgp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-te-pm-bgp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-pm-bgp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 13:36:34 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7DD1B2A12 for ; Fri, 4 Jul 2014 13:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKZeKt3c-CCa for ; Fri, 4 Jul 2014 13:36:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8191B2F81 for ; Fri, 4 Jul 2014 13:36:31 -0700 (PDT) Received: from [172.29.67.77] (193.110.55.15) by DM2PR05MB446.namprd05.prod.outlook.com (10.141.104.142) with Microsoft SMTP Server (TLS) id 15.0.980.8; Fri, 4 Jul 2014 20:36:29 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: <02a401cf4443$0171b340$045519c0$@ndzh.com> Date: Fri, 4 Jul 2014 22:36:17 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <68850C31-983D-4D1A-A098-9BE531C57371@juniper.net> References: <02a401cf4443$0171b340$045519c0$@ndzh.com> To: Susan Hares , John Scudder X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.55.15] X-ClientProxiedBy: DB3PR01CA0076.eurprd01.prod.exchangelabs.com (10.242.133.179) To DM2PR05MB446.namprd05.prod.outlook.com (10.141.104.142) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02622CEF0A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6049001)(6009001)(51704005)(199002)(189002)(377454003)(24454002)(77156001)(106356001)(31966008)(50226001)(86362001)(23726002)(76176999)(42186005)(33656002)(92726001)(36756003)(83716003)(97756001)(92566001)(101416001)(79102001)(83072002)(50986999)(99396002)(93916002)(1941001)(74502001)(46406003)(85852003)(77096002)(19580395003)(4396001)(21056001)(74662001)(19580405001)(62966002)(104166001)(95666004)(82746002)(88136002)(102836001)(87976001)(87286001)(50466002)(105586002)(85306003)(77982001)(89996001)(57306001)(46102001)(64706001)(20776003)(80022001)(81342001)(83322001)(47776003)(15975445006)(107046002)(66066001)(81542001)(104396001)(579124002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB446; H:[172.29.67.77]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Io_sFIRSUDj8KLQUDRiScbDi2s8 Cc: idr wg Subject: Re: [Idr] WG adoption of the draft-gredler-idr-ls-distribution-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 20:36:33 -0000 hi sue, we have added the OpenDaylight interop results and posted as=20 draft-gredler-idr-ls-distribution-impl-01 have taken draft-gredler-idr-ls-distribution-impl-01 and submitted as draft-ietf-idr-ls-distribution-impl-01 where its pending your approval. tx, /hannes On Mar 20, 2014, at 2:47 PM, Susan Hares wrote: > idr-WG > =20 > The IDR Working group has adopted the following draft: > BGP Link-State Information Distribution Implementation Report > draft-gredler-idr-ls-distribution-impl-00 > =20 > Will the co-authors please submit this draft (with suggested = corrections to): > =20 > Draft-ietf-idr-ls-distribution-impl-00.txt > =20 > Sue Hares =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jul 4 16:21:21 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259171A013B; Fri, 4 Jul 2014 16:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgmccJrD0zvP; Fri, 4 Jul 2014 16:21:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1336B1A010F; Fri, 4 Jul 2014 16:21:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704232118.6270.69220.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 16:21:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/O_x-D0ana8E2bF4H2RBGdXP76Fs Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as4octet-extcomm-generic-subtype-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 23:21:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Generic Subtype for BGP Four-octet AS specific extended community Authors : Dhananjaya Rao Pradosh Mohapatra Jeffrey Haas Filename : draft-ietf-idr-as4octet-extcomm-generic-subtype-07.txt Pages : 6 Date : 2014-07-04 Abstract: Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific BGP extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as4octet-extcomm-generic-subtype/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-as4octet-extcomm-generic-subtype-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 Sat Jul 5 15:41:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372391A001D; Sat, 5 Jul 2014 15:40:57 -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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGj9spQvtITT; Sat, 5 Jul 2014 15:40:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42421A0010; Sat, 5 Jul 2014 15:40:53 -0700 (PDT) Received: from CY1PR09MB0283.namprd09.prod.outlook.com (25.160.159.11) by CY1PR09MB0281.namprd09.prod.outlook.com (25.160.140.27) with Microsoft SMTP Server (TLS) id 15.0.974.11; Sat, 5 Jul 2014 22:40:51 +0000 Received: from CY1PR09MB0283.namprd09.prod.outlook.com ([25.160.159.11]) by CY1PR09MB0283.namprd09.prod.outlook.com ([25.160.159.11]) with mapi id 15.00.0974.002; Sat, 5 Jul 2014 22:40:52 +0000 From: "Sriram, Kotikalapudi" To: "grow@ietf.org" , "sidr wg list (sidr@ietf.org)" , "idr@ietf.org" Thread-Topic: New Version Notification for draft-sriram-route-leak-protection-00 Thread-Index: Ac+YoG1v4r/E8oBITwO9qOVMW2v8hg== Date: Sat, 5 Jul 2014 22:40:49 +0000 Message-ID: <881700c1df264d11a9c74c0fca20c64f@CY1PR09MB0283.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.223.116] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(377454003)(377424004)(13464003)(20776003)(64706001)(81342001)(33646001)(81542001)(4396001)(66066001)(80022001)(79102001)(76482001)(31966008)(74662001)(74502001)(77982001)(46102001)(107886001)(107046002)(95666004)(105586002)(99286002)(106356001)(15202345003)(83322001)(19580405001)(19580395003)(54356999)(50986999)(101416001)(15975445006)(99396002)(85852003)(83072002)(87936001)(2656002)(92566001)(86362001)(76576001)(85306003)(77096002)(74316001)(21056001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CY1PR09MB0281; H:CY1PR09MB0283.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ipYaOVPzuDzgK1papRldaknvzWA Subject: [Idr] FW: New Version Notification for draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 22:40:57 -0000 VGhpcyBpcyBhIC0wMCBpbmRpdmlkdWFsIGRyYWZ0IGNvbnRyaWJ1dGlvbi4gDQpJIHdpbGwgY29u c3VsdCB3aXRoIEdST1cgYW5kIFNJRFIgY2hhaXJzIHJlZ2FyZGluZyBhIA0KcG9zc2libGUgcHJl c2VudGF0aW9uIG9mIHRoaXMgd29yayBpbiBUb3JvbnRvLg0KWW91ciBjb21tZW50cywgc3VnZ2Vz dGlvbnMgcmVxdWVzdGVkLiANCg0KU3JpcmFtDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBKdWx5IDA0LCAyMDE0IDc6MTcgUE0NClRvOiBTcmly YW0sIEtvdGlrYWxhcHVkaTsgTW9udGdvbWVyeSwgRG91Z2xhczsgTW9udGdvbWVyeSwgRG91Z2xh czsgU3JpcmFtLCBLb3Rpa2FsYXB1ZGkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtc3JpcmFtLXJvdXRlLWxlYWstcHJvdGVjdGlvbi0wMC50eHQNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc3JpcmFtLXJvdXRlLWxlYWstcHJvdGVjdGlvbi0wMC50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS290aWthbGFwdWRpIFNyaXJh bSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1zcmly YW0tcm91dGUtbGVhay1wcm90ZWN0aW9uDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJRW5oYW5jZW1l bnQgdG8gQkdQU0VDIGZvciBQcm90ZWN0aW9uIGFnYWluc3QgUm91dGUgTGVha3MNCkRvY3VtZW50 IGRhdGU6CTIwMTQtMDctMDQNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJ CTExDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtc3JpcmFtLXJvdXRlLWxlYWstcHJvdGVjdGlvbi0wMC50eHQNClN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcmlyYW0tcm91dGUtbGVh ay1wcm90ZWN0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNyaXJhbS1yb3V0ZS1sZWFrLXByb3RlY3Rpb24tMDANCg0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgZW51bWVyYXRlcyBkaWZmZXJlbnQgdHlwZXMgb2Ygcm91dGUgbGVha3Mg YmFzZWQgb24NCiAgIG9ic2VydmVkIGV2ZW50cyBvbiB0aGUgSW50ZXJuZXQuICBJdCBpbGx1c3Ry YXRlcyBob3cgQkdQU0VDIGluIGl0cw0KICAgY3VycmVudCBmb3JtIChhcyBkZXNjcmliZWQgaW4g ZHJhZnQtaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbC0wOSkNCiAgIGFscmVhZHkgcHJvdmlkZXMg cHJvdGVjdGlvbiBhZ2FpbnN0IGFsbCBidXQgb25lIG9mIHRoZXNlIHJvdXRlLWxlYWtzDQogICBz Y2VuYXJpb3MuICBUaGUgZG9jdW1lbnQgZnVydGhlciBkaXNjdXNzZXMgYSBkZXNpZ24gZW5oYW5j ZW1lbnQgdG8NCiAgIHRoZSBCR1BTRUMgcHJvdG9jb2wgdGhhdCB3aWxsIGV4dGVuZCBwcm90ZWN0 aW9uIGFnYWluc3QgdGhpcyBvbmUNCiAgIHJlbWFpbmluZyB0eXBlIG9mIHJvdXRlLWxlYWsgYXR0 YWNrIGFzIHdlbGwuICBXaXRoIHRoZSBpbmNsdXNpb24gb2YNCiAgIHRoaXMgZW5oYW5jZW1lbnQs IEJHUFNFQyBpcyBleHBlY3RlZCB0byBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdA0KICAgYWxs IHR5cGVzIG9mIHJvdXRlLWxlYWtzLiAgVGhlIGRvY3VtZW50IGFsc28gaW5jbHVkZXMgYSBzdG9w Z2FwDQogICBtZXRob2QgZm9yIGRldGVjdGlvbiBhbmQgbWl0aWdhdGlvbiBvZiByb3V0ZSBsZWFr cyBmb3IgdGhlIHBoYXNlIHdoZW4NCiAgIEJHUFNFQyAocGF0aCB2YWxpZGF0aW9uKSBpcyBub3Qg eWV0IGRlcGxveWVkIGJ1dCBvbmx5IG9yaWdpbg0KICAgdmFsaWRhdGlvbiBpcyBkZXBsb3llZC4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Jul 7 09:02:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452D21A033D for ; Mon, 7 Jul 2014 09:02:55 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzmuopaCoMFY for ; Mon, 7 Jul 2014 09:02:52 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD961A0336 for ; Mon, 7 Jul 2014 09:02:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.187.217; From: "Susan Hares" To: "idr wg" Date: Mon, 7 Jul 2014 12:02:45 -0400 Message-ID: <007701cf99fc$e4664670$ad32d350$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01CF99DB.5D5828E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+Z/KaSQo27j8yPTDScsdfaucxHQA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/A26kdY24Smn2DzOFNOUIi-6u1C0 Cc: "'John G. Scudder'" Subject: [Idr] IETF Agenda - tentative X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:02:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0078_01CF99DB.5D5828E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: I've posted the IDR agenda below. If I missed someone who requested a time slot, please let me know so I can add you to agenda. Sue Hares --------- IETF 90 IDR meeting Date: Tuesday 7/22/14 9:00 - 11:30 0. Agenda Bashing [9:00 - 9:05] 1. Status of BGP Documents [9:05 - 9:15] 2. BGP error-handling draft [9:15 - 9:25] draft- 3. BGP Based Generic TransPort draft-white-bgpbgp-00 [9:25 - 9:35] Russ White 4. Next Hop issues 9:30 - 9:50 BGP Remote Next Hop draft-vandevelde-idr-remote-next-hop-06.txt [9:35 - 9:45] NextHop_Path_Record Attribute draft-zhuang-idr-nexthop-path-record.txt [9:45 - 9:55] Robin Zhuang 2. RT-Constraint errata track [10:00 - 10:30] Route Target Constrained Distribution of Routes with no Route Targets draft-rosen-idr-rtc-no-rt-00 [10:00 - 10:10] Eric Rosen Extensions to RT-Constrain in Hierarchical [10:10 - 10:20] Route Reflection Scenario draft-dong-idr-rt-hierarchical-rt Jie Dong Inter Domain considerations for Constrained [10:20 - 10:30] Route distribution draft-litkowski-idr-rtc-interas-00 Stephane Litkowski 4. BGP-LS/ BGP-SFC links [10:30 - 10:50] Segment Routing Egress Peer Engineering BGPLS Extensions draft-previdi-idr-bgpls-segment-routing-epe-00 [10:30-10:40] S. Previdi BGP Extensions for Inter-AS Traffic Engineering (TE) Link Distribution draft-dong-idr-inter-as-te-link-distribution Jie Dong [10:40 - 10:50 ] 6. MPLS path draft-li-idr-mpls-path-programming-00 [10:50 - 11:00] 7. Timestamp support for BGP paths [11:00 - 11:10] draft-litkowski-idr-bgp-timestamp Stephane Litkowski 8. Applying BGP flowspec rules on a specific interface [11:10 - 11:20] Draft-litkowski-idr-flowspec-interfaceset Stephane Litkowski 11:20 Adjourn ------=_NextPart_000_0078_01CF99DB.5D5828E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all:

 

I’ve posted = the IDR agenda below.

 

If I missed someone = who requested a time slot, please let me know so I can add you to = agenda.

 

Sue = Hares

 

 

---------

IETF 90 IDR = meeting

 

Date: Tuesday = 7/22/14  9:00 - 11:30

 

 

0. Agenda Bashing =             [9:00 = - 9:05]

1. Status of BGP = Documents    [9:05 - 9:15]

 

 

2. BGP = error-handling draft   [9:15 - 9:25]

      draft-

 

3. BGP Based = Generic TransPort

      draft-white-bgpbgp-00   = [9:25 - 9:35]

        Russ White =

 

4. Next Hop = issues  9:30 - 9:50

     BGP Remote Next Hop =

     draft-vandevelde-idr-remote-next-hop-= 06.txt [9:35 - 9:45]

 

     

     NextHop_Path_Record Attribute =

     draft-zhuang-idr-nexthop-path-record.= txt    [9:45 - 9:55]

     Robin Zhuang =

 

 

2. RT-Constraint = errata track   [10:00 - 10:30]

 

    = Route Target Constrained Distribution of Routes with no Route = Targets

    = draft-rosen-idr-rtc-no-rt-00       &nb= sp;          [10:00 - 10:10] =

    Eric Rosen

 

 

    = Extensions to RT-Constrain in Hierarchical   [10:10 - = 10:20] 

        Route Reflection = Scenario

    = draft-dong-idr-rt-hierarchical-rt

    Jie Dong

 

    = Inter Domain considerations for Constrained    [10:20 - = 10:30]   

       Route = distribution

    = draft-litkowski-idr-rtc-interas-00

    Stephane Litkowski =

 

 

4. BGP-LS/ BGP-SFC = links =             &= nbsp;      [10:30 - 10:50] =

 

   = Segment Routing Egress Peer Engineering BGPLS = Extensions

   = draft-previdi-idr-bgpls-segment-routing-epe-00  [10:30-10:40] =

   S. Previdi

  

    BGP Extensions for Inter-AS Traffic = Engineering (TE) Link Distribution

    = draft-dong-idr-inter-as-te-link-distribution

    Jie = Dong           &nb= sp;           &nbs= p;            = ;    [10:40 - 10:50 ]

 

6. MPLS path =

   draft-li-idr-mpls-path-programming-00  = [10:50 - 11:00]

 

7.  Timestamp = support for BGP paths          =    [11:00 - 11:10]

    = draft-litkowski-idr-bgp-timestamp

    Stephane Litkowski

 

 

8.  Applying = BGP flowspec rules on a specific interface [11:10 - 11:20] =

    Draft-litkowski-idr-flowspec-interfaceset

    = Stephane Litkowski

 

11:20 Adjourn  =

------=_NextPart_000_0078_01CF99DB.5D5828E0-- From nobody Mon Jul 7 09:49:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882A71A036C for ; Mon, 7 Jul 2014 09:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to4Xr1VwJZ_2 for ; Mon, 7 Jul 2014 09:49:37 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 12EDC1A0362 for ; Mon, 7 Jul 2014 09:49:36 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,619,1400040000"; d="scan'208";a="392735755" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 07 Jul 2014 12:49:35 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 7 Jul 2014 12:49:36 -0400 From: "George, Wes" To: John Scudder , "idr@ietf.org List" Date: Mon, 7 Jul 2014 12:49:29 -0400 Thread-Topic: [Idr] IETF-90 agenda topics Thread-Index: Ac+aA267P+uxWn1oSpKi7C2i4cRoqQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/0EML3l7VfdDHH8u12qj72DV2ucQ Cc: Hares Susan Subject: Re: [Idr] IETF-90 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:49:38 -0000 SGkNCg0KSSBiZWxpZXZlIHRoYXQgSURSLUFTLW1pZ3JhdGlvbiBpcyByZWFkeSBmb3IgV0dMQy4g SSBkb24ndCBrbm93IHdoZXRoZXIgYQ0KZmV3IG1pbnV0ZXMgdG8gZGlzY3VzcyB0aGVzZSBvdXRz dGFuZGluZyBxdWVzdGlvbnMgZnJvbSBteSBtZXNzYWdlIG9uIDEzDQpKdW5lIHdvdWxkIGJlIGhl bHBmdWwgb3Igd2hldGhlciBpdCBjYW4ganVzdCBiZSByb2xsZWQgaW50byB0aGUgV0dMQyBhbmQN CmRpc2N1c3NlZCBvbi1saXN0IHRvIHByZXNlcnZlIGFnZW5kYSB0aW1lIGZvciBtb3JlIHByZXNz aW5nIG1hdHRlcnM6DQoNCkRvZXMgdGhpcyBuZWVkIHRvIGZvcm1hbGx5IHVwZGF0ZSB0aGUgQkdQ IFNwZWMsIGFuZCBpcw0KaW5mb3JtYXRpb25hbCBzdGlsbCB0aGUgYXBwcm9wcmlhdGUgc3RhdHVz IGZvciB0aGUgZG9jIG5vdyB0aGF0IGl04oCZcw0KYWN0dWFsbHkgZGVmaW5pbmcgdGhlIGJlaGF2 aW9yIGluIG5vcm1hdGl2ZSBsYW5ndWFnZT8NCg0KDQpUaGFua3MsDQoNCldlcw0KDQoNCg0KDQoN Ck9uIDcvMS8xNCwgMTozNSBQTSwgIkpvaG4gU2N1ZGRlciIgPGpnc0BqdW5pcGVyLm5ldD4gd3Jv dGU6DQoNCj5Gb2xrcywNCj4NCj5XZSdyZSBwbGFubmluZyB0byBtZWV0IGF0IElFVEYtOTAgb24g VHVlc2RheSwgSnVseSAyMiwgZnJvbSA5OjAwIHRvDQo+MTE6MzAuICBQbGVhc2UgZm9yd2FyZCBh bnkgSURSIGFnZW5kYSBpdGVtcyB5b3UgbWlnaHQgaGF2ZSB0byBTdWUgYW5kDQo+bXlzZWxmLiAg VGhlIGRlYWRsaW5lIGlzIEp1bHkgNyAodGhpcyBjb21pbmcgTW9uZGF5KSBieSAxMDowMCBVLlMu DQo+RWFzdGVybiBUaW1lLiAgUHJpb3JpdHkgd2lsbCBiZSBnaXZlbiB0byB0aG9zZSB3aG8gZ2V0 IHRoZWlyIHJlcXVlc3RzIGluDQo+YnkgdGhlIGRlYWRsaW5lLCB0aG91Z2ggaW4gbGlnaHQgb2Yg dGhlIGxhdGVuZXNzIG9mIHRoaXMgYW5ub3VuY2VtZW50LCBpZg0KPmFnZW5kYSBzcGFjZSBwZXJt aXRzIGl0IHdlIHdpbGwgY29uc2lkZXIgcmVxdWVzdHMgZ290dGVuIGluIGJlZm9yZSBKdWx5DQo+ MTQgYXQgMTA6MDAgVS5TLiBFYXN0ZXJuIFRpbWUuDQo+DQo+SWYgeW91IGhhdmUgcHJldmlvdXNs eSBwcmVzZW50ZWQgb24geW91ciB0b3BpYyBhdCBhbiBJRFIgbWVldGluZywgcGxlYXNlDQo+ZXhw bGFpbiBpbiB5b3VyIHJlcXVlc3Qgd2hhdCB5b3UgaG9wZSB0byBhY2hpZXZlIHdpdGggeW91ciBw cmVzZW50YXRpb24NCj50aGlzIHRpbWUuIElmIHlvdSBoYXZlIHJlcXVlc3RlZCB0byBwcmVzZW50 IHRoZSBzYW1lIHdvcmsgYXQgbXVsdGlwbGUNCj5XR3MsIHBsZWFzZSBub3RlIHRoaXMgc28gdGhh dCB3ZSBjYW4gY29vcmRpbmF0ZSBhcyBuZWVkZWQuDQo+DQo+SWYgeW91IHBsYW4gdG8gbWFrZSBh IHByZXNlbnRhdGlvbiwgcGxlYXNlIGtlZXAgaW4gbWluZCB0aGUgSURSDQo+dHJhZGl0aW9uLCAi bm8gSW50ZXJuZXQgRHJhZnQgLSBubyB0aW1lIHNsb3QiLiAgWW91IHNob3VsZCBhbHNvIHBsYW4g dG8NCj5zZW5kIHlvdXIgc2xpZGVzIHRvIFN1ZSBhbmQgbWUgbm8gbGF0ZXIgdGhhbiAyNCBob3Vy cyBwcmlvciB0byB0aGUNCj5tZWV0aW5nLCB0aG91Z2ggYWdhaW4sIGVhcmxpZXIgaXMgYmV0dGVy Lg0KPg0KPkZpbmFsbHksIGlmIHlvdSByZXF1ZXN0IGFuIGFnZW5kYSBzbG90LCBwbGVhc2UgZG8g c28gYnkgcmVwbHlpbmcgdG8gdGhpcw0KPm1lc3NhZ2UsIG1ha2luZyBzdXJlIHRvIGluY2x1ZGUg Ym90aCBTdWUgYW5kIG1lIGluIHRoZSBUbzogb3IgQ2M6IGFuZA0KPmRvbid0IGNoYW5nZSB0aGUg c3ViamVjdCBsaW5lLg0KPg0KPlRoYW5rcywNCj4NCj4tLUpvaG4gJiBTdWUNCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPklkciBtYWlsaW5nIGxp c3QNCj5JZHJAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkcg0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBw cml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2lu ZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRy ZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1h aWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3Ry aWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250 ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJt YW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBh bmQgYW55IHByaW50b3V0Lg0K From nobody Mon Jul 7 12:46:32 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20891B28A5; Mon, 7 Jul 2014 12:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu0SEVx1Hbra; Mon, 7 Jul 2014 12:46:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 601D11B28A1; Mon, 7 Jul 2014 12:46:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7BC35180015; Mon, 7 Jul 2014 12:46:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140707194602.7BC35180015@rfc-editor.org> Date: Mon, 7 Jul 2014 12:46:02 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/2k4_1pzx-LjUSDPRpRSqk-TTqHg Cc: drafts-update-ref@iana.org, idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] BCP 6, RFC 7300 on Reservation of Last Autonomous System (AS) Numbers X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:46:28 -0000 A new Request for Comments is now available in online RFC libraries. BCP 6 RFC 7300 Title: Reservation of Last Autonomous System (AS) Numbers Author: J. Haas, J. Mitchell Status: Best Current Practice Stream: IETF Date: July 2014 Mailbox: jhaas@juniper.net, jon.mitchell@microsoft.com Pages: 5 Characters: 7952 Updates: RFC 1930 See Also: BCP 6 I-D Tag: draft-ietf-idr-last-as-reservation-07.txt URL: http://www.rfc-editor.org/rfc/rfc7300.txt This document reserves two Autonomous System Numbers (ASNs) at the end of the 16-bit and 32-bit ranges, described in this document as "Last ASNs", and provides guidance to implementers and operators on their use. This document updates Section 10 of RFC 1930. This document is a product of the Inter-Domain Routing Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Jul 7 12:52:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439D51B28CA for ; Mon, 7 Jul 2014 12:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu3HXH08H3O4 for ; Mon, 7 Jul 2014 12:52:37 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8679A1B28C6 for ; Mon, 7 Jul 2014 12:52:36 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id h18so11194304igc.16 for ; Mon, 07 Jul 2014 12:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=wrqV1QQPjH9dVD9gepfpUUDLR4QhGXf6O26CkME9HSA=; b=zal7Uo9YwWLifVyZB4SHnC8+/q9sw9wDyRvPYYF798GU+4c1+KR/tdEAkmVZPk1nFb rVPIjbKIjOz9cwa66RfjwMKEB/QL194kVkGfquCF8xZV54laOctunIC0MgzTelS8b55z doQV1TqpzjBwLT92DsrdGrTbGeoWyezcw20poOaXb2yNDpQ5IBgka+a69JcXUjlS45i2 ZHubpPKYM/yJwGwSoVcmcvx+74MRf5+zq9KdSEGqLvQFPJZot05Km13Op12BLIf6o6f0 jY5biITcM49Mv9boxHkDceOiXLH7/SWbfgkpPu16wb1hpCksVs9oMck7MW52KvMCJg5E oxmA== MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr19255122igt.29.1404762755822; Mon, 07 Jul 2014 12:52:35 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Mon, 7 Jul 2014 12:52:35 -0700 (PDT) Date: Mon, 7 Jul 2014 21:52:35 +0200 X-Google-Sender-Auth: -b3n_PKAYo3NdRGKJkWY9Zj-Ipc Message-ID: From: Robert Raszuk To: "Alvaro Retana (aretana)" , Russ White Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/kd09HWRL9RwM6VkjsRackpTWmYg Cc: idr wg Subject: [Idr] Discussion on draft-white-bgpbgp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:52:38 -0000 Hi, Carrying opaque information in networks today is a good problem to address. /* In fact to go there I guess we should really step back and define what is today's _network_ as by many it is no longer bunch of routers running proprietary code. */ Historically I have been attempting to at least make a very simple session level separation by proposing Transport Instance BGP: http://tools.ietf.org/html/draft-raszuk-ti-bgp-01 You are proposing a new BGP message to be used for carrying "opaque information" within routing information !!! That is IMHO big/huge mistake. * First - behavior of any given AFI/SAFI is highly defined by it's UPDATE message semantics. Carrying opaque stuff around which is unrelated to routing is just not fitting there. /* It's like attaching pretty heavy backpack to a ski jumper without even recalculation of the trajectory or adjusting ramp exit speed :-) */ * Error handling of already fragile routing SAFIs are becoming even more fragile due to additional likehood for errors in the new message * Additional information is likely to be not congruent with routing information. Per message type separation on say route reflector requires much more intelligence then say SAFI based filtering and SAFI based split to peers. * New message may require standard BGP attributes for filtering, for policy etc ... so now we will be forced to duplicate attributes between UPDATE message and Generic Transport Message. * Attempts to define a generic attribute (to carry various opaque information) aka "garbage can" have failed in the past as it was clearly stated that SAFI space is sufficiently large then for those information which make sense there is always a room to define a new SAFI. Now you are with GTM defining not a "garbage can", but "garbage truck" ! How is this more efficient then having generic attribute ? * Last but not least recent industry progress have pretty much proved it that some overlays require subset of BGP information as well as various other types of information to be distributed to non traditional routers. It seems that perhaps using other transports (for example: XMPP) while inheriting a lot of good peoperities of BGP for loop free distribution may fit much broader range of requirements and applications yet provide as simple as few lines of xml to define messages as it seems fit. The list is much much longer, but let's just start from here ... Thx, R. From nobody Mon Jul 7 13:10:36 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990E71B28BA; Mon, 7 Jul 2014 13:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wDO6oazkG8Q; Mon, 7 Jul 2014 13:10:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4BF1A0515; Mon, 7 Jul 2014 13:09:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140707200942.2227.21747.idtracker@ietfa.amsl.com> Date: Mon, 07 Jul 2014 13:09:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vGqJ_O7ASa1dpzyuA5IyUXU-yiI Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-impl-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 20:10: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 Working Group of the IETF. Title : BGP Link-State Information Distribution Implementation Report Authors : Hannes Gredler Balaji Rajagopalan Saikat Ray Manish Bhardwaj Filename : draft-ietf-idr-ls-distribution-impl-00.txt Pages : 13 Date : 2014-07-04 Abstract: This document is an implementation report for the BGP Link-State Information Distribution protocol as defined in [I-D.ietf-idr-ls-distribution]. The editors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-impl-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 7 13:12:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAFA1B28BD for ; Mon, 7 Jul 2014 13:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQlFmVLJzcg2 for ; Mon, 7 Jul 2014 13:12:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF811B28EC for ; Mon, 7 Jul 2014 13:11:07 -0700 (PDT) Received: from [172.29.33.9] (66.129.241.18) by DM2PR05MB734.namprd05.prod.outlook.com (10.141.178.22) with Microsoft SMTP Server (TLS) id 15.0.980.8; Mon, 7 Jul 2014 20:10:59 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <68850C31-983D-4D1A-A098-9BE531C57371@juniper.net> Date: Mon, 7 Jul 2014 16:10:49 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7174BE51-ECCC-4C65-A37E-7E5DE3AE3533@juniper.net> References: <02a401cf4443$0171b340$045519c0$@ndzh.com> <68850C31-983D-4D1A-A098-9BE531C57371@juniper.net> To: Hannes Gredler X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.18] X-ClientProxiedBy: BY2PR02CA019.namprd02.prod.outlook.com (10.242.234.147) To DM2PR05MB734.namprd05.prod.outlook.com (10.141.178.22) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02652BD10A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(51704005)(377454003)(199002)(189002)(24454002)(83716003)(46406003)(81342001)(92566001)(19580405001)(74502001)(74662001)(107046002)(83072002)(19580395003)(87976001)(15975445006)(88136002)(95666004)(46102001)(92726001)(50986999)(36756003)(33656002)(105586002)(110136001)(85306003)(31966008)(77982001)(79102001)(106356001)(82746002)(23726002)(102836001)(76482001)(97756001)(104166001)(89996001)(101416001)(87286001)(50466002)(20776003)(81542001)(47776003)(64706001)(93916002)(77156001)(57306001)(62966002)(99396002)(85852003)(76176999)(4396001)(86362001)(50226001)(21056001)(66066001)(83322001)(77096002)(42186005)(80022001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB734; H:[172.29.33.9]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/bneghGHsp8RDiUeskTDDFfHsjEE Cc: idr wg , Susan Hares Subject: Re: [Idr] WG adoption of the draft-gredler-idr-ls-distribution-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 20:12:36 -0000 Done.=20 --John On Jul 4, 2014, at 4:36 PM, Hannes Gredler wrote: > hi sue, >=20 > we have added the OpenDaylight interop results and posted as=20 > draft-gredler-idr-ls-distribution-impl-01 >=20 > have taken draft-gredler-idr-ls-distribution-impl-01 > and submitted as draft-ietf-idr-ls-distribution-impl-01 >=20 > where its pending your approval. >=20 > tx, >=20 > /hannes >=20 > On Mar 20, 2014, at 2:47 PM, Susan Hares wrote: >=20 >> idr-WG >>=20 >> The IDR Working group has adopted the following draft: >> BGP Link-State Information Distribution Implementation Report >> draft-gredler-idr-ls-distribution-impl-00 >>=20 >> Will the co-authors please submit this draft (with suggested = corrections to): >>=20 >> Draft-ietf-idr-ls-distribution-impl-00.txt >>=20 >> Sue Hares =20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 From nobody Mon Jul 7 15:01:19 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B531D1B2963 for ; Mon, 7 Jul 2014 15:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7Tn2r06am54 for ; Mon, 7 Jul 2014 15:01:16 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DA41B295A for ; Mon, 7 Jul 2014 15:01:16 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:61105 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X4GyG-0002Oy-CE; Mon, 07 Jul 2014 22:01:12 +0000 From: "Russ White" To: "'Robert Raszuk'" , "'Alvaro Retana \(aretana\)'" References: In-Reply-To: Date: Mon, 7 Jul 2014 18:01:04 -0400 Message-ID: <007201cf9a2e$f3dace50$db906af0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEVvtDbaCGT2VvkfZT5BYMmJduFCZ0I34cQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/wE3UJPRGqEemQ9V4p4M9JFJs9x8 Cc: 'idr wg' Subject: Re: [Idr] Discussion on draft-white-bgpbgp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:01:17 -0000 > * First - behavior of any given AFI/SAFI is highly defined by it's = UPDATE > message semantics. Carrying opaque stuff around which is unrelated to > routing is just not fitting there. /* It's like attaching pretty heavy = backpack to > a ski jumper without even recalculation of the trajectory or adjusting = ramp > exit speed :-) */ > * Error handling of already fragile routing SAFIs are becoming even = more > fragile due to additional likehood for errors in the new message That's why this isn't attached to any AFI/SAFI, but rather just a new = message type altogether. There's no routing information defined in this = new message type. > * Additional information is likely to be not congruent with routing > information. Per message type separation on say route reflector = requires > much more intelligence then say SAFI based filtering and SAFI based = split to > peers. Since it's not an AFI/SAFI, and this isn't designed to carry routing = information per se, it doesn't matter... :-) > * New message may require standard BGP attributes for filtering, for = policy > etc ... so now we will be forced to duplicate attributes between = UPDATE > message and Generic Transport Message. That's why the communities are included as is -- they may not all apply = to the generic message type, but it's easier to reuse code rather than = build new. > * Attempts to define a generic attribute (to carry various opaque > information) aka "garbage can" have failed in the past as it was = clearly stated > that SAFI space is sufficiently large then for those information which = make > sense there is always a room to define a new SAFI. Now you are with = GTM > defining not a "garbage can", but "garbage truck" ! How is this more = efficient > then having generic attribute ? Wait -- you're arguing that we shouldn't carry this stuff in an AFI/SAFI = (which the generic transport message doesn't), but then saying there's = no demand for not carrying stuff in an AFI/SAFI. Huh? :-) :-) Russ From nobody Mon Jul 7 15:12:35 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9269B1B2971 for ; Mon, 7 Jul 2014 15:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11I6N_COPgrY for ; Mon, 7 Jul 2014 15:12:31 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B291B2963 for ; Mon, 7 Jul 2014 15:12:31 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id y20so4196606ier.40 for ; Mon, 07 Jul 2014 15:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=86C7faV7bTbZyQytm1ull1HX2aLUBWeA+PA555A3Upw=; b=UixADv4GkydpYhnePARDg5o3wa3KQa46+Ik0cb75PfQ+XlFUYvuTcNQunIuHh3b3b1 GwuY1wKotXOKtursA8mksR8Xc0kaUulYLAx10sx+GWFkoQTqU1kaH+Ziv1SIfpBBwq49 Cw0mwT0cs77EpQAVx8Q1Riqune5sFczdtgLv1uEFIqziSy+thDt9YiJtqlSqWlIMKp5b HIKKLHdBrV5ndlW8mauJH834fhbE6tQqfhWulw5HpeOYH+7U32zpbY8wespcP4GVQg1j lg/TirkwnDCfvq6MMwHejWwOdE7Ptmuj5K4MFmeI5/1kRbxkgOU0Y3CYBcoP9KLZyvm1 rTVQ== MIME-Version: 1.0 X-Received: by 10.50.36.106 with SMTP id p10mr87610691igj.9.1404771151011; Mon, 07 Jul 2014 15:12:31 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Mon, 7 Jul 2014 15:12:30 -0700 (PDT) In-Reply-To: <007201cf9a2e$f3dace50$db906af0$@riw.us> References: <007201cf9a2e$f3dace50$db906af0$@riw.us> Date: Tue, 8 Jul 2014 00:12:30 +0200 X-Google-Sender-Auth: sE_1PP6ZWyL1EKgCW_PBzau4Vyg Message-ID: From: Robert Raszuk To: Russ White Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/49v2SAYzzt6MuD0dNBOrwwGnD0o Cc: idr wg Subject: Re: [Idr] Discussion on draft-white-bgpbgp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:12:32 -0000 Hi Russ ... New message travels on an existing session. I used AFI/SAFI as indicator of a session. If so new malformed message may bring down the session with precious routing information encoded along. Please tell me how are you by proposing a new message making a session more robust ? Also are you going to define new advertisement rules say on RRs for this new message ? r. On Tue, Jul 8, 2014 at 12:01 AM, Russ White wrote: > >> * First - behavior of any given AFI/SAFI is highly defined by it's UPDATE >> message semantics. Carrying opaque stuff around which is unrelated to >> routing is just not fitting there. /* It's like attaching pretty heavy backpack to >> a ski jumper without even recalculation of the trajectory or adjusting ramp >> exit speed :-) */ > >> * Error handling of already fragile routing SAFIs are becoming even more >> fragile due to additional likehood for errors in the new message > > That's why this isn't attached to any AFI/SAFI, but rather just a new message type altogether. There's no routing information defined in this new message type. > >> * Additional information is likely to be not congruent with routing >> information. Per message type separation on say route reflector requires >> much more intelligence then say SAFI based filtering and SAFI based split to >> peers. > > Since it's not an AFI/SAFI, and this isn't designed to carry routing information per se, it doesn't matter... :-) > >> * New message may require standard BGP attributes for filtering, for policy >> etc ... so now we will be forced to duplicate attributes between UPDATE >> message and Generic Transport Message. > > That's why the communities are included as is -- they may not all apply to the generic message type, but it's easier to reuse code rather than build new. > >> * Attempts to define a generic attribute (to carry various opaque >> information) aka "garbage can" have failed in the past as it was clearly stated >> that SAFI space is sufficiently large then for those information which make >> sense there is always a room to define a new SAFI. Now you are with GTM >> defining not a "garbage can", but "garbage truck" ! How is this more efficient >> then having generic attribute ? > > Wait -- you're arguing that we shouldn't carry this stuff in an AFI/SAFI (which the generic transport message doesn't), but then saying there's no demand for not carrying stuff in an AFI/SAFI. Huh? :-) > > :-) > > Russ > From nobody Mon Jul 7 15:21:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF001B2977 for ; Mon, 7 Jul 2014 15:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26A-XsdDyDiR for ; Mon, 7 Jul 2014 15:21:22 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB41A1B2976 for ; Mon, 7 Jul 2014 15:21:22 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:61329 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X4HHk-0002an-Q3; Mon, 07 Jul 2014 22:21:21 +0000 From: "Russ White" To: "'Robert Raszuk'" References: <007201cf9a2e$f3dace50$db906af0$@riw.us> In-Reply-To: Date: Mon, 7 Jul 2014 18:21:13 -0400 Message-ID: <00ad01cf9a31$c4209b60$4c61d220$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEVvtDbaCGT2VvkfZT5BYMmJduFCQGNdorwAZcfrZuc78CHEA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/aRXBQZtrAz5_B-ZTyFFuCZKeHwM Cc: 'idr wg' Subject: Re: [Idr] Discussion on draft-white-bgpbgp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:21:24 -0000 > New message travels on an existing session. I used AFI/SAFI as = indicator of a > session. >=20 > If so new malformed message may bring down the session with precious > routing information encoded along. >=20 > Please tell me how are you by proposing a new message making a session > more robust ? You can negotiate sending all messages, just standard AFI/SAFI messages, = or just this new message type -- so the generic transport allows the = implementer (both at the coding level and at the network design level) = to decide what information should be carried where, trading that off = against the various risks. Using a new session forces the designer to = always use two different sessions, which might not be desirable. > Also are you going to define new advertisement rules say on RRs for = this new > message ? I assume it would be reflected like any other messages, but we've not = spent a lot of time looking at reflection rules specifically. Since it's = a new message type, it could easily be offloaded to a new set of = reflectors. :-) Russ From nobody Mon Jul 7 15:31:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9391B2979 for ; Mon, 7 Jul 2014 15:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se20xf2_6812 for ; Mon, 7 Jul 2014 15:31:02 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E65E1B28A5 for ; Mon, 7 Jul 2014 15:31:02 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id lx4so3295529iec.38 for ; Mon, 07 Jul 2014 15:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EDCvgBbdBHPDOKuVYndig3NFpyW28AGg3GHmwUN6HHQ=; b=a1Z0wJWfmy2/Nu9ayIHaGEFD21JJxZJ76EVOx8tuVxChBHH0inCzB4dYAE/FXNM5x7 Xc6aitmIw+7qwGIHI5iX/YEqZK+pebA+kLuwPvLHeCYrqRODF5UjaTv6lKmHYULmTEUh KF0L574sePyAXr04G7KWpPhP/h6aZTMYSnbFxZig+ExNKTC0t6hzLhCNMZVtt/J2UEji Pz5jIpItX+mpA45sq1FYstnHyFdj8cn2Vi0Y8XL614gDvoiC5G5D92QGQSnkcR2QtoMh pEwGUZEg/JgvkXd+Fx9nkZmptc2zhj+jr/LevmryGXgqQQr6c0dmJR2d/afKQu+whzMy tWHA== MIME-Version: 1.0 X-Received: by 10.43.179.73 with SMTP id oz9mr35370775icc.18.1404772261944; Mon, 07 Jul 2014 15:31:01 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Mon, 7 Jul 2014 15:31:01 -0700 (PDT) In-Reply-To: <00ad01cf9a31$c4209b60$4c61d220$@riw.us> References: <007201cf9a2e$f3dace50$db906af0$@riw.us> <00ad01cf9a31$c4209b60$4c61d220$@riw.us> Date: Tue, 8 Jul 2014 00:31:01 +0200 X-Google-Sender-Auth: v0ajYfSbDAHGdq7m3P3QbXe-lUE Message-ID: From: Robert Raszuk To: Russ White Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/3dUkgUqF-sTgRrjeaTGdlLb5a2o Cc: idr wg Subject: Re: [Idr] Discussion on draft-white-bgpbgp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:31:03 -0000 > You can negotiate sending all messages, just standard AFI/SAFI > messages, or just this new message type -- so the generic transport > allows the implementer (both at the coding level and at the network > design level) to decide what information should be carried where, > trading that off against the various risks. Using a new session > forces the designer to always use two different sessions, which > might not be desirable. But this is precisely what definition of new AF can also do today. Why not define a new AF and new attribute to carry the new opaque information along with AF specific handling rules. Note that new AF may mean either new AFI or new SAFI - pick your preference. What is the advantage of defining a new message for your application ? New message make sense when you are to exchange associated types of information over given session (example: KEEPALIVE Message or BGP Diagnostic Message etc ...) So at the very minimum I would be interested to see a discussion in this draft (maybe as new section) to compare pros and cons of new message vs new AF with new attribute. Thx, R. From nobody Mon Jul 7 19:00:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249BF1B299E for ; Mon, 7 Jul 2014 19:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v-bQ1QyL0v0 for ; Mon, 7 Jul 2014 19:00:18 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC671B2996 for ; Mon, 7 Jul 2014 19:00:17 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:63332 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X4KhZ-0005fY-52; Tue, 08 Jul 2014 02:00:13 +0000 From: "Russ White" To: "'Robert Raszuk'" References: <007201cf9a2e$f3dace50$db906af0$@riw.us> <00ad01cf9a31$c4209b60$4c61d220$@riw.us> In-Reply-To: Date: Mon, 7 Jul 2014 22:00:03 -0400 Message-ID: <006301cf9a50$57651fe0$062f5fa0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEVvtDbaCGT2VvkfZT5BYMmJduFCQGNdorwAZcfrZsBzFgePQI6aYsknM/HtGA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/tSq1s-4LTYUG4Eswfye1nl0TwX8 Cc: 'idr wg' Subject: Re: [Idr] Discussion on draft-white-bgpbgp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 02:00:20 -0000 > > You can negotiate sending all messages, just standard AFI/SAFI > > messages, or just this new message type -- so the generic transport > > allows the implementer (both at the coding level and at the network > > design level) to decide what information should be carried where, > > trading that off against the various risks. Using a new session = forces > > the designer to always use two different sessions, which might not = be > > desirable. >=20 > But this is precisely what definition of new AF can also do today. Why = not > define a new AF and new attribute to carry the new opaque information > along with AF specific handling rules. Except that using an address family to carry information that isn't an = actual address (as in reachability information) is a little odd, to say = the least -- and can be rather convoluted. It's simpler to have a = message type that is specifically designed not for reachability = information, or rather for information not designed for direct = consumption in the BGP process itself, but is rather being carried = opaquely through the protocol because it's a convenient and handy = transport. A couple of instances are noted in the draft. :-) Russ From nobody Tue Jul 8 07:26:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA831B2AEC for ; Tue, 8 Jul 2014 07:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em4ZPsOxOFBA for ; Tue, 8 Jul 2014 07:26:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DD8B61B2AED for ; Tue, 8 Jul 2014 07:26:04 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8F22AC203; Tue, 8 Jul 2014 10:26:04 -0400 (EDT) Date: Tue, 8 Jul 2014 10:26:04 -0400 From: Jeffrey Haas To: Russ White Message-ID: <20140708142604.GD19932@pfrc> References: <021e01cf96ca$06339e00$129ada00$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <021e01cf96ca$06339e00$129ada00$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/NG40oF7-F20BxyzVsSjXXxYLwF8 Cc: idr@ietf.org Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:26:07 -0000 On Thu, Jul 03, 2014 at 10:21:03AM -0400, Russ White wrote: > The intent for draft-white-bgpbgp-00.txt is to provide an alternative to the > various stuff we've been doing with address families to carry odds and ends > and bits of data in BGP... If anyone has comments, please push them to the > list. I'm replying here rather than hijacking Robert's thread. He's covering somewhat different discussion points than I had. :-) These proposals keep coming to haunt us and I've done what I can to try to keep them from IDR. I suspect at some point I may have to declare defeat and support one. So, using your draft as a starting point, here's some general issues I think that are unaddressed: This sort of "BLOB over BGP" (as we'd called it internally) has an issue in the sense that at some point you'll want to distribute something bigger than a BGP PDU. In your draft, you're providing for 64k messages, which will at least handle the extension for bigger PDUs. Eventually something will push the BLOB case beyond that. Please consider design (and the implications) of fragments up front. I think you may be considering sequence in this case, but I'm also unclear if that's the use case in mind. To give a specific use case, consider the distribution of BSR state in BGP MVPN. BSR messages may exceed a 4k PDU. (Credit to Pavan Kurapati for the discussion.) The primary pain-point of fragments is consistency and slow-traveling BGP messages. When you transmit something that may be a fragment that's part of new information, it's tricky to know that you have all fragments. That tends to lead to sequence / generation numbers along with fragment ID. (Along with rollover issues in seq no, but we know from IGPs how we'd expect that to work.) A 2 octet type is probably too small. Consider a bigger numbering space. At some point, it may even be pressed to OID + vendor ID. Your extended community header is probably intended to be a TLV, but it looks like it's saying "there's one entry". That's probably not what you mean. In your thread with Robert, you're basically saying "this isn't NLRI". Part of Robert's point that is not addressed in this draft is that a significant part of the reason why people keep trying to throw stuff in BGP is that it handles (arguably, not in the best way) inter-domain distribution - including loop detection. AS_PATHs, reflector cluster behavior, etc. Those things have been one of the motivators to simply overload Update. You'll need them in something like this. Another general issue is in-line/side-band signaling. BGP-LS handwaves the issue away by strongly suggesting "don't use the same peering infrastructure for BGP-LS and real routing". This does the same hand waving, but has significantly more likelihood for information that isn't useful in side-band signaling to gum up the works. Contrarily, your ROA use case (I knew that would happen at some point) is something that in-line makes some sense. This isn't an issue of protocol - I think we all know how that should work. You're placing an operational stake in the ground saying "use Route-Targets and RT-C to steer this". I suspect we should do the same with BGP-LS. -- Jeff From nobody Tue Jul 8 07:34:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B771B27B8 for ; Tue, 8 Jul 2014 07:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghRO2rGKsrfO for ; Tue, 8 Jul 2014 07:34:42 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (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 E5B9E1B2A74 for ; Tue, 8 Jul 2014 07:34:41 -0700 (PDT) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.8/8.14.5) with ESMTP id s68EYSKO011481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Jul 2014 10:34:29 -0400 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <20140708142604.GD19932@pfrc> Date: Tue, 8 Jul 2014 10:34:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <793E5708-D067-4003-98A3-57DE959927A8@puck.nether.net> References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [204.42.254.5]); Tue, 08 Jul 2014 10:34:29 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ZiM86WMeNh9QH4sNpxdnx3AYLQo Cc: idr@ietf.org Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:34:43 -0000 On Jul 8, 2014, at 10:26 AM, Jeffrey Haas wrote: > This isn't an issue of protocol - I think we all know how that should = work. > You're placing an operational stake in the ground saying "use = Route-Targets > and RT-C to steer this". I suspect we should do the same with BGP-LS. I certainly share the concern that Jeff has enumerated in his email. = There are a number of communicaitnns that people may want inter and intra-domain = and BGP is certainly seen as a means to communicate fully within that functional = domain. With larger integers and numbering space broadly available for each part = of a TLV set, perhaps it's time for something that takes into account these = larger spaces. Router TCP stacks tend to be broken and the chances of this = breaking something that operators (such as myself) care about is increasing = significantly. While I continue to push on my vendors to fix their TCP bugs in 2014 = (and beyond) moving past 16-bit to 32-bit or similar messaging sizes likely is the = right path forward. - Jared= From nobody Tue Jul 8 09:39:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730D91A0343 for ; Tue, 8 Jul 2014 09:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYZs_44IuHtw for ; Tue, 8 Jul 2014 09:39:35 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA061A0314 for ; Tue, 8 Jul 2014 09:39:35 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:53550 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X4YQX-0007AZ-B2; Tue, 08 Jul 2014 16:39:33 +0000 From: "Russ White" To: "'Jeffrey Haas'" References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> In-Reply-To: <20140708142604.GD19932@pfrc> Date: Tue, 8 Jul 2014 12:39:25 -0400 Message-ID: <001a01cf9acb$2e809110$8b81b330$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGDRdgwSsh0eenlA7toFnS+amNNdgGDuvBnnCLqvqA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/K54_dc0WRfTBOlTBerE5UAzHvxc Cc: idr@ietf.org Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 16:39:37 -0000 > These proposals keep coming to haunt us and I've done what I can to try to > keep them from IDR. I suspect at some point I may have to declare defeat > and support one. So, using your draft as a starting point, here's some general > issues I think that are unaddressed: Well, my goal is to stop the madness of adding ever more stuff that has nothing to do with routing directly into the AFI/SAFI construction. It's become just a dumping ground of all sorts of information. > This sort of "BLOB over BGP" (as we'd called it internally) has an issue in the > sense that at some point you'll want to distribute something bigger than a > BGP PDU. In your draft, you're providing for 64k messages, which will at least > handle the extension for bigger PDUs. Eventually something will push the > BLOB case beyond that. Please consider design (and the implications) of > fragments up front. I think you may be considering sequence in this case, > but I'm also unclear if that's the use case in mind. Fragments are an issue -- but, in general, if the originator uses the sequence and identifier fields correctly, and keeps their tlv's under the max size for BGP, this shouldn't be an issue. I'd rather not get into fragmentation, but rather leave it to the originator of the information if possible. > A 2 octet type is probably too small. Consider a bigger numbering space. > At some point, it may even be pressed to OID + vendor ID. A larger space is fine with me... It can easily be made larger, if there's consensus around this point. > Your extended community header is probably intended to be a TLV, but it > looks like it's saying "there's one entry". That's probably not what you mean. Hmm... I don't know what would need to be changed here -- suggestions? > In your thread with Robert, you're basically saying "this isn't NLRI". Part of > Robert's point that is not addressed in this draft is that a significant part of > the reason why people keep trying to throw stuff in BGP is that it handles > (arguably, not in the best way) inter-domain distribution - including loop > detection. AS_PATHs, reflector cluster behavior, etc. Those things have > been one of the motivators to simply overload Update. You'll need them in > something like this. We discussed the AS_PATH attribute, and decided that if we use the sequence and identifier we don't need the AS_PATH to deduplicate/etc. The way the forwarding rules are written, you should forward if you receive something new, and discard if you receive something with the same id/seq as what you already have. > Another general issue is in-line/side-band signaling. BGP-LS handwaves the > issue away by strongly suggesting "don't use the same peering infrastructure > for BGP-LS and real routing". This does the same hand waving, but has > significantly more likelihood for information that isn't useful in side-band > signaling to gum up the works. Contrarily, your ROA use case (I knew that > would happen at some point) is something that in-line makes some sense. I think it's most useful to let the operator and vendor decide... The way this is put together, you can carry the information in the same BGP session or a separate one -- just depends on what you're carrying. The one thing we didn't do is allow you to choose which type of TLVs should be carried in which session -- something that might be a useful addition. There's actually no on the wire changes to do this, just the ability to filter, I think (?). > This isn't an issue of protocol - I think we all know how that should work. > You're placing an operational stake in the ground saying "use Route-Targets > and RT-C to steer this". I suspect we should do the same with BGP-LS. I would agree... :-) Russ From nobody Tue Jul 8 09:54:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731471B27EA for ; Tue, 8 Jul 2014 09:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-OoIUKeXAw6 for ; Tue, 8 Jul 2014 09:54:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF461A0336 for ; Tue, 8 Jul 2014 09:54:36 -0700 (PDT) Received: from DM2PR05CA002.namprd05.prod.outlook.com (10.141.96.22) by BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) with Microsoft SMTP Server (TLS) id 15.0.980.8; Tue, 8 Jul 2014 16:54:34 +0000 Received: from BN1BFFO11FD020.protection.gbl (2a01:111:f400:7c10::1:149) by DM2PR05CA002.outlook.office365.com (2a01:111:e400:2428::22) with Microsoft SMTP Server (TLS) id 15.0.985.8 via Frontend Transport; Tue, 8 Jul 2014 16:54:34 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD020.mail.protection.outlook.com (10.58.144.83) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Tue, 8 Jul 2014 16:54:34 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Jul 2014 09:54:33 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s68GsUn34693; Tue, 8 Jul 2014 09:54:30 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201407081654.s68GsUn34693@magenta.juniper.net> To: Russ White In-Reply-To: <001a01cf9acb$2e809110$8b81b330$@riw.us> References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> <001a01cf9acb$2e809110$8b81b330$@riw.us> X-MH-In-Reply-To: Russ White message dated "Tue, 08 Jul 2014 12:39:25 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31245.1404838468.1@juniper.net> Date: Tue, 8 Jul 2014 09:54:28 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(199002)(189002)(51704005)(83072002)(83322001)(69596002)(92726001)(68736004)(102836001)(99396002)(107046002)(23726002)(4396001)(85306003)(80022001)(64706001)(44976005)(77982001)(81342001)(97756001)(110136001)(81542001)(79102001)(50986999)(85852003)(97736001)(31966008)(6806004)(46406003)(76482001)(106466001)(84676001)(81156004)(46102001)(87936001)(47776003)(95666004)(54356999)(76176999)(21056001)(92566001)(16796002)(74502001)(74662001)(20776003)(50466002)(86362001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB725; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0266491E90 Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/G3NfFzLOnwFgqUIscc6VMSrbdE0 Cc: idr@ietf.org Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 16:54:38 -0000 Russ, > > These proposals keep coming to haunt us and I've done what I can to try to > > keep them from IDR. I suspect at some point I may have to declare defeat > > and support one. So, using your draft as a starting point, here's some > general > > issues I think that are unaddressed: > > Well, my goal is to stop the madness of adding ever more stuff that has > nothing to do with routing directly into the AFI/SAFI construction. It's > become just a dumping ground of all sorts of information. Whether this is "madness" or not is a matter of *opinion* (and each of us is entitled to have one). What is a *fact*, is that as of today the BGP AFI/SAFI construction is used for quite a few things that one may consider as "nothing to do with routing" (e.g., Route Target Constraints, BGP VPLS, BGP flow spec). Which provides an existence proof (means deployment and operators) that the BGP AFI/SAFI construction is Good Enough (tm) for what one may consider as "nothing to do with routing". Yakov. From nobody Tue Jul 8 09:58:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321F91B2BA3 for ; Tue, 8 Jul 2014 09:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJcgv09Y472n for ; Tue, 8 Jul 2014 09:58:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0135C1B27EA for ; Tue, 8 Jul 2014 09:58:41 -0700 (PDT) Received: from [172.29.33.9] (66.129.241.13) by BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) with Microsoft SMTP Server (TLS) id 15.0.980.8; Tue, 8 Jul 2014 16:58:40 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <001a01cf9acb$2e809110$8b81b330$@riw.us> Date: Tue, 8 Jul 2014 12:58:28 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <13B474F8-1624-4518-9F8C-6458E2631611@juniper.net> References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> <001a01cf9acb$2e809110$8b81b330$@riw.us> To: Russ White X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BLUPR01CA009.prod.exchangelabs.com (10.255.223.167) To BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0266491E90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(24454002)(199002)(377454003)(189002)(79102001)(92566001)(46102001)(110136001)(23726002)(87976001)(77982001)(85852003)(31966008)(92726001)(81342001)(83072002)(50466002)(81542001)(89996001)(4396001)(50226001)(74502001)(93916002)(86362001)(87286001)(74662001)(77156001)(36756003)(76482001)(85306003)(105586002)(62966002)(99396002)(97756001)(104166001)(19580405001)(77096002)(95666004)(21056001)(80022001)(47776003)(64706001)(101416001)(107046002)(20776003)(106356001)(76176999)(83322001)(102836001)(42186005)(19580395003)(33656002)(46406003)(50986999)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB724; H:[172.29.33.9]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/UhqBuVW1QD2YVxuqLQokHLqTHds Cc: idr@ietf.org Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 16:58:45 -0000 On Jul 8, 2014, at 12:39 PM, Russ White wrote: > The one thing we > didn't do is allow you to choose which type of TLVs should be carried = in > which session -- something that might be a useful addition. I think it would be a necessary addition. If this (or something like it) = were to take off, an inevitable consequence would be for it to be used = to transport multiple data sets -- indeed, that's the whole point. = Different data sets will have different characteristics and requirements = in terms of their volume and requirements for timely delivery, and at = some point somebody is going to be upset if data type foo, with payload = size 10 bytes and message frequency 1/week but very low latency = requirements, gets hung up waiting for data type bar, with payload size = 1000 bytes and message frequency 1/second but very high latency = tolerance. (My hat is that of a WG participant. And I'm not necessarily endorsing = the idea, just commenting on it.) --John= From nobody Tue Jul 8 10:39:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B9D1A0390 for ; Tue, 8 Jul 2014 10:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3KYKHXZZVMl for ; Tue, 8 Jul 2014 10:39:10 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 95D4D1A0362 for ; Tue, 8 Jul 2014 10:39:10 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D6681C203; Tue, 8 Jul 2014 13:39:09 -0400 (EDT) Date: Tue, 8 Jul 2014 13:39:09 -0400 From: Jeffrey Haas To: Russ White Message-ID: <20140708173909.GE19932@pfrc> References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> <001a01cf9acb$2e809110$8b81b330$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001a01cf9acb$2e809110$8b81b330$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Qa6v-v9EKL0KaUOYQ31MAIztx6s Cc: idr@ietf.org Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:39:12 -0000 Russ, On Tue, Jul 08, 2014 at 12:39:25PM -0400, Russ White wrote: > Fragments are an issue -- but, in general, if the originator uses the > sequence and identifier fields correctly, and keeps their tlv's under the > max size for BGP, this shouldn't be an issue. I'd rather not get into > fragmentation, but rather leave it to the originator of the information if > possible. My concern was from having worked through some of the headaches of what it would take to use BLOB over BGP for BSR. It does matter and I strongly suggest that it be considered up front if you'd like this to be viable. If the answer is "we're never handling fragments", some things that otherwise fit the solution become non-viable and we're back to additional hacks. > > Your extended community header is probably intended to be a TLV, but it > > looks like it's saying "there's one entry". That's probably not what you > mean. > > Hmm... I don't know what would need to be changed here -- suggestions? Minimally: Length field: 2 octets value divisible by 8. Value: 0-N BGP extended communities. Better: TLVs for community like functions, because we also have ipv6 specific communities. Perhaps even wide communities. :-) The intention of the field is obviously to allow coloring of the data. If you *only* ever intend to allow RTs in there, best to state that. And also allow for more than one RT. > We discussed the AS_PATH attribute, and decided that if we use the sequence > and identifier we don't need the AS_PATH to deduplicate/etc. The way the > forwarding rules are written, you should forward if you receive something > new, and discard if you receive something with the same id/seq as what you > already have. That covers the potential of "flooding scope" and is good for loop prevention/dups. What's missing is the opportunity for policy outside of that covered by communities. > > Another general issue is in-line/side-band signaling. BGP-LS handwaves > the > > issue away by strongly suggesting "don't use the same peering > infrastructure > > for BGP-LS and real routing". This does the same hand waving, but has > > significantly more likelihood for information that isn't useful in > side-band > > signaling to gum up the works. Contrarily, your ROA use case (I knew that > > would happen at some point) is something that in-line makes some sense. > > I think it's most useful to let the operator and vendor decide... The way > this is put together, you can carry the information in the same BGP session > or a separate one -- just depends on what you're carrying. The one thing we > didn't do is allow you to choose which type of TLVs should be carried in > which session -- something that might be a useful addition. There's actually > no on the wire changes to do this, just the ability to filter, I think (?). We agree. My point is that we've reached enough data that we should be responsible and start recommending some operational practices. (Everything and the kitchen sink, as the saying goes.) -- Jeff From nobody Tue Jul 8 12:07:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8E41A0250 for ; Tue, 8 Jul 2014 12:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqBwEvRWf8Gx for ; Tue, 8 Jul 2014 12:07:47 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5C81A0400 for ; Tue, 8 Jul 2014 12:07:46 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:54052 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X4ajw-0000KB-T6; Tue, 08 Jul 2014 19:07:45 +0000 From: "Russ White" To: "'Yakov Rekhter'" References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> <001a01cf9acb$2e809110$8b81b330$@riw.us> <201407081654.s68GsUn34693@magenta.juniper.net> In-Reply-To: <201407081654.s68GsUn34693@magenta.juniper.net> Date: Tue, 8 Jul 2014 15:07:35 -0400 Message-ID: <01b201cf9adf$e2718a30$a7549e90$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGDRdgwSsh0eenlA7toFnS+amNNdgGDuvBnAk2Y6s8CY/00zZv9iP0g Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hNqJfmMgmjkJlgb77MTkYtsjF9U Cc: idr@ietf.org Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:07:48 -0000 > Whether this is "madness" or not is a matter of *opinion* (and each of us is > entitled to have one). Of course... I didn't mean to offend, just to say that we keep piling things into the AFI/SAFI that have no specific relation to destination based routing. "Stop the madness," is a saying, not a term of condemnation. :-) > existence proof (means deployment and operators) that the BGP AFI/SAFI > construction is Good Enough > (tm) for what one may consider as "nothing to do with routing". Sure -- but I also see the protocol becoming more complex over time because of this additional information. If there's a simpler way to carry this information, one that allows us to either stream the information out of band or in band, etc., then we should consider it, IMHO. :-) Russ From nobody Tue Jul 8 12:12:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2D91A0255 for ; Tue, 8 Jul 2014 12:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNnSmby-0GOB for ; Tue, 8 Jul 2014 12:12:31 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2AF31A04F8 for ; Tue, 8 Jul 2014 12:12:31 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:54095 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X4aoY-0000Ot-I5; Tue, 08 Jul 2014 19:12:30 +0000 From: "Russ White" To: "'Jeffrey Haas'" References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> <001a01cf9acb$2e809110$8b81b330$@riw.us> <20140708173909.GE19932@pfrc> In-Reply-To: <20140708173909.GE19932@pfrc> Date: Tue, 8 Jul 2014 15:12:22 -0400 Message-ID: <01d301cf9ae0$8cb8d930$a62a8b90$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGDRdgwSsh0eenlA7toFnS+amNNdgGDuvBnAk2Y6s8CHWvoYJv/vskQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hA35Ev0cy7wUAX_tynvb3kYPCbA Cc: idr@ietf.org Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:12:32 -0000 > My concern was from having worked through some of the headaches of > what it would take to use BLOB over BGP for BSR. It does matter and I > strongly suggest that it be considered up front if you'd like this to be viable. Okay, will talk to Alvaro and Jakob about this. > Minimally: > Length field: 2 octets value divisible by 8. > Value: 0-N BGP extended communities. > > Better: > TLVs for community like functions, because we also have ipv6 specific > communities. Perhaps even wide communities. :-) I think it's best to treat communities like functions, or like any other TLV -- the main point is we don't want anyone to be forced to rewrite the community code to support the policies around coloring the data and other sorts of policies. > > We discussed the AS_PATH attribute, and decided that if we use the > > sequence and identifier we don't need the AS_PATH to deduplicate/etc. > > The way the forwarding rules are written, you should forward if you > > receive something new, and discard if you receive something with the > > same id/seq as what you already have. > > That covers the potential of "flooding scope" and is good for loop > prevention/dups. What's missing is the opportunity for policy outside of that > covered by communities. We could add an optional AS_PATH -- I don't know if we should force "blobs" to always use an AS_PATH, though (?). > We agree. My point is that we've reached enough data that we should be > responsible and start recommending some operational practices. > (Everything and the kitchen sink, as the saying goes.) Okay, we can add some operational points to the next version -- I'll add it to the list. :-) Russ From nobody Tue Jul 8 12:13:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C335F1A04C5 for ; Tue, 8 Jul 2014 12:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPo6QGX0EKlw for ; Tue, 8 Jul 2014 12:13:04 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A73A1A04F8 for ; Tue, 8 Jul 2014 12:13:04 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:54099 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X4ap4-0000Pk-WE; Tue, 08 Jul 2014 19:13:03 +0000 From: "Russ White" To: "'John G. Scudder'" References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> <001a01cf9acb$2e809110$8b81b330$@riw.us> <13B474F8-1624-4518-9F8C-6458E2631611@juniper.net> In-Reply-To: <13B474F8-1624-4518-9F8C-6458E2631611@juniper.net> Date: Tue, 8 Jul 2014 15:12:54 -0400 Message-ID: <01d601cf9ae0$a0122810$e0367830$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGDRdgwSsh0eenlA7toFnS+amNNdgGDuvBnAk2Y6s8B3GFu8JwBx8yg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/JMYquAaN-jl9zFBJ7SNHNrUkLn4 Cc: idr@ietf.org Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:13:07 -0000 > > The one thing we > > didn't do is allow you to choose which type of TLVs should be carried > > in which session -- something that might be a useful addition. > > I think it would be a necessary addition. If this (or something like it) were to > take off, an inevitable consequence would be for it to be used to transport > multiple data sets -- indeed, that's the whole point. Different data sets will > have different characteristics and requirements in terms of their volume and > requirements for timely delivery, and at some point somebody is going to be > upset if data type foo, with payload size 10 bytes and message frequency > 1/week but very low latency requirements, gets hung up waiting for data > type bar, with payload size 1000 bytes and message frequency 1/second but > very high latency tolerance. Okay -- will add this to the list of things to add to the draft, as well. :-) Russ From nobody Tue Jul 8 12:24:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7C21A02D8 for ; Tue, 8 Jul 2014 12:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0y04CLp_Mth for ; Tue, 8 Jul 2014 12:24:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EF2661A0255 for ; Tue, 8 Jul 2014 12:24:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7C52DC203; Tue, 8 Jul 2014 15:24:18 -0400 (EDT) Date: Tue, 8 Jul 2014 15:24:18 -0400 From: Jeffrey Haas To: Russ White Message-ID: <20140708192418.GJ19932@pfrc> References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> <001a01cf9acb$2e809110$8b81b330$@riw.us> <20140708173909.GE19932@pfrc> <01d301cf9ae0$8cb8d930$a62a8b90$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01d301cf9ae0$8cb8d930$a62a8b90$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/GKl1ucvFBGziGPUmX3KqC0zYXMU Cc: idr@ietf.org Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:24:20 -0000 On Tue, Jul 08, 2014 at 03:12:22PM -0400, Russ White wrote: [fragments] > Okay, will talk to Alvaro and Jakob about this. Thanks. If you eventually say "too messy, not going to do it", that's at least consideration. > I think it's best to treat communities like functions, or like any other TLV > -- the main point is we don't want anyone to be forced to rewrite the > community code to support the policies around coloring the data and other > sorts of policies. Agreed. It's just that as listed in the draft, you get exactly one extended community, no 1997 communities and no extension for other coloring. > We could add an optional AS_PATH -- I don't know if we should force "blobs" > to always use an AS_PATH, though (?). I totally agree with you - for many applications it's noise. But in an inter-as context, policy will happen. The scoping AS in wide communities was added partially for that reason. -- Jeff From nobody Tue Jul 8 12:57:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEE31A000B for ; Tue, 8 Jul 2014 12:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCEJtnTLu8Hd for ; Tue, 8 Jul 2014 12:57:16 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1DC1A0008 for ; Tue, 8 Jul 2014 12:57:16 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id h3so1082558igd.14 for ; Tue, 08 Jul 2014 12:57: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:date:message-id:subject :from:to:cc:content-type; bh=kG3ZKyyvdCvuzs/q9ZBZClp4RQSf1sBAoMCe0MVazXA=; b=Y7OAO/XODpNecQC0HBInASKNmh33QMVODT0G2yxmGG9eYo+y3R80UQKbUGTuNhbGn/ 1Ra+N9c6h6IDINGz3c+S1k1gTtI0wo0LfeVTFvXF+K175R79GNEFUwMH1SzzzG8HC2Da /cuXUOfjH7v11yXG+olTpGAxcDICzqR5WowVE3gM0wuiOZ4m853k9ZBPFtHZ4eApY7jE XthopCDp6sR8AQz63RWBt1J2YhqhCNcPGRYvu37YTMp5CSd4noVzCgCr9d2Z7647MZ8I P5fnzHt+m+zljIAcx7FNc7o6wH7fQNiX3tcuwpK3KjjamEyCt8G2KhB9HF2KEZRcd4I3 yBAQ== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr6576083igb.21.1404849435851; Tue, 08 Jul 2014 12:57:15 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Tue, 8 Jul 2014 12:57:15 -0700 (PDT) In-Reply-To: <01b201cf9adf$e2718a30$a7549e90$@riw.us> References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> <001a01cf9acb$2e809110$8b81b330$@riw.us> <201407081654.s68GsUn34693@magenta.juniper.net> <01b201cf9adf$e2718a30$a7549e90$@riw.us> Date: Tue, 8 Jul 2014 21:57:15 +0200 X-Google-Sender-Auth: PwTdDQm-Z663ZKGXEmpHVtebWqA Message-ID: From: Robert Raszuk To: Russ White Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/2MrmCS5pEQKxl3BmE7j25HrUr2U Cc: Yakov Rekhter , idr wg Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:57:18 -0000 Hi Russ, I think exploring new ideas is always great providing they bring real value at right price. So far you keep complaining that things which we carry in BGP have nothing to do with destination based routing. Then perhaps a better option is to issue a short one page draft renaming Network Layer Reachability Information "NLRI" field to "Database Key" field - the advantages are that your concern will get addressed yet multiple implementations, deployments and operational practices will remain unchanged. - - - Meanwhile if we are at concerns regarding BGP I think we have two serious problems in BGP today: * dynamic capabilites * multisessions Both are either not supported even partially in most implementations (dynamic capabilites) or supported in a way that they could be improved (recall my discussion with John in Stockholm IETF regarding use of TI vs multisession for improving BGP session robustness). Thx R. On Tue, Jul 8, 2014 at 9:07 PM, Russ White wrote: > >> Whether this is "madness" or not is a matter of *opinion* (and each of us > is >> entitled to have one). > > Of course... I didn't mean to offend, just to say that we keep piling things > into the AFI/SAFI that have no specific relation to destination based > routing. "Stop the madness," is a saying, not a term of condemnation. :-) > >> existence proof (means deployment and operators) that the BGP AFI/SAFI >> construction is Good Enough >> (tm) for what one may consider as "nothing to do with routing". > > Sure -- but I also see the protocol becoming more complex over time because > of this additional information. If there's a simpler way to carry this > information, one that allows us to either stream the information out of band > or in band, etc., then we should consider it, IMHO. > > :-) > > Russ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jul 9 01:08:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7515F1A03A1 for ; Wed, 9 Jul 2014 01:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tzg67xKtnn5C for ; Wed, 9 Jul 2014 01:08:45 -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 725EA1A0339 for ; Wed, 9 Jul 2014 01:08:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGY08795; Wed, 09 Jul 2014 08:08:43 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 09:08:42 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 16:08:35 +0800 From: "Dongjie (Jimmy)" To: "John G. Scudder" , Russ White Thread-Topic: [Idr] draft-white-bgpbgp-00.txt Thread-Index: Ac+WydxSZNHBfR79Q52Sx0xMSiTI5wDq6IYAAASoPoAAAKpSAAAwXm2Q Date: Wed, 9 Jul 2014 08:08:35 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927336BE6DC@nkgeml512-mbx.china.huawei.com> References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> <001a01cf9acb$2e809110$8b81b330$@riw.us> <13B474F8-1624-4518-9F8C-6458E2631611@juniper.net> In-Reply-To: <13B474F8-1624-4518-9F8C-6458E2631611@juniper.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/b2zoyK_Hbt6qET03lxd9QDle7pc Cc: "idr@ietf.org" Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 08:08:46 -0000 As different kinds of information will be carried in BGP, it seems that som= e QoS mechanism may be needed on BGP sessions:) Regards, Jie > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Wednesday, July 09, 2014 12:58 AM > To: Russ White > Cc: idr@ietf.org > Subject: Re: [Idr] draft-white-bgpbgp-00.txt >=20 > On Jul 8, 2014, at 12:39 PM, Russ White wrote: >=20 > > The one thing we > > didn't do is allow you to choose which type of TLVs should be carried > > in which session -- something that might be a useful addition. >=20 > I think it would be a necessary addition. If this (or something like it) = were to take > off, an inevitable consequence would be for it to be used to transport mu= ltiple > data sets -- indeed, that's the whole point. Different data sets will hav= e > different characteristics and requirements in terms of their volume and > requirements for timely delivery, and at some point somebody is going to = be > upset if data type foo, with payload size 10 bytes and message frequency > 1/week but very low latency requirements, gets hung up waiting for data t= ype > bar, with payload size 1000 bytes and message frequency 1/second but very > high latency tolerance. >=20 > (My hat is that of a WG participant. And I'm not necessarily endorsing th= e idea, > just commenting on it.) >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jul 9 02:11:17 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D7A1A01DD for ; Wed, 9 Jul 2014 02:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l0Xi-ic4GdI for ; Wed, 9 Jul 2014 02:11:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E7A1A0012 for ; Wed, 9 Jul 2014 02:11:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1X4nuA-0003zD-3a; Wed, 09 Jul 2014 09:11:10 +0000 Date: Wed, 09 Jul 2014 18:11:09 +0900 Message-ID: From: Randy Bush To: "Dongjie (Jimmy)" In-Reply-To: <76CD132C3ADEF848BD84D028D243C927336BE6DC@nkgeml512-mbx.china.huawei.com> References: <021e01cf96ca$06339e00$129ada00$@riw.us> <20140708142604.GD19932@pfrc> <001a01cf9acb$2e809110$8b81b330$@riw.us> <13B474F8-1624-4518-9F8C-6458E2631611@juniper.net> <76CD132C3ADEF848BD84D028D243C927336BE6DC@nkgeml512-mbx.china.huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hj27VKvnfqRl9NpEOhiTpVH28_s Cc: idr wg Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 09:11:15 -0000 > As different kinds of information will be carried in BGP, it seems > that some QoS mechanism may be needed on BGP sessions:) possibly more important would be encryption, where you might take a look at draft-dukhovni-opportunistic-security-01.txt randy From nobody Wed Jul 9 08:09:51 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4DA1A0AED for ; Wed, 9 Jul 2014 08:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QhcKPuKcQWb for ; Wed, 9 Jul 2014 08:09:40 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4751D1A0AEB for ; Wed, 9 Jul 2014 08:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2981; q=dns/txt; s=iport; t=1404918570; x=1406128170; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=k8cBZzr0xZjG94iSQkGPSJWZnxO2SbLdoCOrTgDwkl8=; b=d9NoSijpE4xZClDuXKNTkHoKhILLa/A4756N95IyYxStUhFG7QZ8eMIh M2lauZohNU6F+BeZTgVArKlOHTdRYKGIpFG1oqKvgFLEW98YmW1WXvwZh E/3vt/IbOBwpa86savBHlZfdASbDi65rSXDF7bJMTxdDyfz+qU/k0zqmp o=; X-IronPort-AV: E=Sophos;i="5.01,631,1400025600"; d="scan'208";a="59469742" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 09 Jul 2014 15:09:30 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s69F9dDx015542; Wed, 9 Jul 2014 15:09:39 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id 2FF434A0; Wed, 9 Jul 2014 11:09:39 -0400 (EDT) From: Eric Rosen To: Robert Raszuk In-reply-to: Your message of Tue, 08 Jul 2014 21:57:15 +0200. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22787.1404918579.1@erosen-lnx> Date: Wed, 09 Jul 2014 11:09:39 -0400 Message-ID: <22788.1404918579@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/SFx5kHcDrGO2giEIoQ4CBWWY2Ho Cc: Yakov Rekhter , idr wg Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 15:09:48 -0000 Robert> Then perhaps a better option is to issue a short one page draft Robert> renaming Network Layer Reachability Information "NLRI" field to Robert> "Database Key" field - the advantages are that your concern will get Robert> addressed yet multiple implementations, deployments and operational Robert> practices will remain unchanged. Actually, a much better idea would be the following: - Define a new AFI. - Store the "bgpbgp" type value in the SAFI. - Store the "bgpbgp" identifier value in the NLRI. - Invent a new attribute to hold the "bgpbgp" data (as you have suggested) Now just use "ordinary" BGP (no new message types needed), and presto, problem solved. Err, wait, what was the problem again? The real question is: why is the proposal in the bgpbgp draft any better than the proposal above? The draft states several times that its proposal is better, but neglects to offer any justification for that claim. (I don't regard "stop the madness!" as much of a justification.) There are of course some real differences between the above and the "bgpbgp" proposal. For instance the "bgpbgp" proposal only allows filtering and distribution control to be based on 8-octet extended communities, whereas ordinary BGP allows filtering and distribution control to be based on arbitrary sets of attributes (including IPv6-address-specific RTs, which the "bgpbgp" proposal doesn't accommodate). No need to mess with stuff like LOCAL_PREF, MED, etc. I guess it's supposed to be obvious that the general policy mechanisms of BGP are not needed for generic transport. Perhaps I'm the only one to whom that is not obvious. The draft does allow the "cost community" (an extended community) to be carried, but I guess it will have no real effect, because the BGP decision process is not used. If you get two different messages with the same type, identifier, and sequence number, there is no complicated decision process to run through, you just install the first one you get. Well, what could possibly go wrong? I guess it's supposed to be obvious that if two messages have the same type/identifier/sequence, they couldn't possibly have different data, and there couldn't possibly be any reason to prefer one over the other, or to force all the routers to make a consistent choice. Bottom line: if there is one thing worse than using BGP to carry arbitrary data, it's inventing a new BGP message type for which the updating rules are completely different. If your information distribution requirements cannot be adapted to utilize the BGP mechanisms, you really should use something else. On the other hand, if the BGP mechanisms are well-suited to your information distribution requirements, why would you want to use a completely different mechanism inside BGP? BTW, if the SAFI isn't big enough to hold the type, the type can be put into the NLRI field. That's how we got the notion of "typed NLRI" ;-) From nobody Wed Jul 9 08:15:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28021A0AC7 for ; Wed, 9 Jul 2014 08:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDblLaBgq1sR for ; Wed, 9 Jul 2014 08:14:58 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6541A0AE3 for ; Wed, 9 Jul 2014 08:14:58 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id h18so802651igc.0 for ; Wed, 09 Jul 2014 08:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1411RiDDN2JqbL7vA93MzKZcz9IFhBCjcHUeE0WP7kI=; b=pSllbO1adJEnSGDAikcGYLrMVG4lNwBLOYom9XmRwCcxXik7dKfQHaX6ipBoFD1U3G PYAFfKtvaq1ggoAufw2+vyqsvOOEQci/6XjS9PBftZKfmzACICmjLsQ8Rng+zs82ELZi uskhrIodiDWpowjo6mKYYo0M72b0fivp2QY5+J6NcK730y0/1Z6Kr1JNP8N/BxfB/4vw 464t9Dn72byEtj7c1xZUHqt/vbhoi9nk8cXQGUqUYuMfsWJaynKDd0MF8fGIH8qIJqH9 m+5x4slbw7fuFhNSNHfzRtkbAfEv5HsZ6/w/kceRT6d4JMmLMPfuWJQk4hvmPQ2VlDSF 1f1A== MIME-Version: 1.0 X-Received: by 10.42.240.20 with SMTP id ky20mr3987001icb.97.1404918897965; Wed, 09 Jul 2014 08:14:57 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Wed, 9 Jul 2014 08:14:57 -0700 (PDT) Received: by 10.64.89.38 with HTTP; Wed, 9 Jul 2014 08:14:57 -0700 (PDT) In-Reply-To: <22788.1404918579@erosen-lnx> References: <22788.1404918579@erosen-lnx> Date: Wed, 9 Jul 2014 17:14:57 +0200 X-Google-Sender-Auth: C1HWUVWlS6J6OL35CYU1OgAtwVk Message-ID: From: Robert Raszuk To: erosen@cisco.com Content-Type: multipart/alternative; boundary=001a113328f2da073404fdc42b3c Archived-At: http://mailarchive.ietf.org/arch/msg/idr/dQ1WNss8Mk4Ds-RZIWIn2xIc4rQ Cc: idr wg , Yakov Rekhter Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 15:15:00 -0000 --001a113328f2da073404fdc42b3c Content-Type: text/plain; charset=UTF-8 Excellent summary Eric ! And you are right that perhaps it would be helpfull to first see a problem statement ... then worry how to solve it ;)) R. On Jul 9, 2014 5:09 PM, "Eric Rosen" wrote: > Robert> Then perhaps a better option is to issue a short one page draft > Robert> renaming Network Layer Reachability Information "NLRI" field to > Robert> "Database Key" field - the advantages are that your concern will > get > Robert> addressed yet multiple implementations, deployments and operational > Robert> practices will remain unchanged. > > Actually, a much better idea would be the following: > > - Define a new AFI. > > - Store the "bgpbgp" type value in the SAFI. > > - Store the "bgpbgp" identifier value in the NLRI. > > - Invent a new attribute to hold the "bgpbgp" data (as you have suggested) > > Now just use "ordinary" BGP (no new message types needed), and presto, > problem solved. Err, wait, what was the problem again? > > The real question is: why is the proposal in the bgpbgp draft any better > than the proposal above? The draft states several times that its proposal > is better, but neglects to offer any justification for that claim. (I > don't > regard "stop the madness!" as much of a justification.) > > There are of course some real differences between the above and the > "bgpbgp" > proposal. > > For instance the "bgpbgp" proposal only allows filtering and distribution > control to be based on 8-octet extended communities, whereas ordinary BGP > allows filtering and distribution control to be based on arbitrary sets of > attributes (including IPv6-address-specific RTs, which the "bgpbgp" > proposal > doesn't accommodate). No need to mess with stuff like LOCAL_PREF, MED, > etc. I guess it's supposed to be obvious that the general policy > mechanisms > of BGP are not needed for generic transport. Perhaps I'm the only one to > whom that is not obvious. > > The draft does allow the "cost community" (an extended community) to be > carried, but I guess it will have no real effect, because the BGP decision > process is not used. If you get two different messages with the same type, > identifier, and sequence number, there is no complicated decision process > to > run through, you just install the first one you get. Well, what could > possibly go wrong? I guess it's supposed to be obvious that if two > messages > have the same type/identifier/sequence, they couldn't possibly have > different data, and there couldn't possibly be any reason to prefer one > over > the other, or to force all the routers to make a consistent choice. > > Bottom line: if there is one thing worse than using BGP to carry arbitrary > data, it's inventing a new BGP message type for which the updating rules > are > completely different. If your information distribution requirements cannot > be adapted to utilize the BGP mechanisms, you really should use something > else. On the other hand, if the BGP mechanisms are well-suited to your > information distribution requirements, why would you want to use a > completely different mechanism inside BGP? > > BTW, if the SAFI isn't big enough to hold the type, the type can be put > into > the NLRI field. That's how we got the notion of "typed NLRI" ;-) > > > --001a113328f2da073404fdc42b3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Excellent summary Eric !

And you are right that perhaps it would be helpfull to first= see a problem statement ... then worry how to solve it ;))

R.

On Jul 9, 2014 5:09 PM, "Eric Rosen" &= lt;erosen@cisco.com> wrote:
Robert> Then perhaps a better option is to issue a short one page draft<= br> Robert> renaming Network Layer Reachability Information "NLRI"= field to
Robert> "Database Key" field - the advantages are that your co= ncern will get
Robert> addressed yet multiple implementations, deployments and operatio= nal
Robert> practices will remain unchanged.

Actually, a much better idea would be the following:

- Define a new AFI.

- Store the "bgpbgp" type value in the SAFI.

- Store the "bgpbgp" identifier value in the NLRI.

- Invent a new attribute to hold the "bgpbgp" data (as you have s= uggested)

Now just use "ordinary" BGP (no new message types needed), and pr= esto,
problem solved. =C2=A0Err, wait, what was the problem again?

The real question is: why is the proposal in the bgpbgp draft any better than the proposal above? =C2=A0The draft states several times that its prop= osal
is better, but neglects to offer any justification for that claim. =C2=A0(I= don't
regard "stop the madness!" as much of a justification.)

There are of course some real differences between the above and the "b= gpbgp"
proposal.

For instance the "bgpbgp" proposal only allows filtering and dist= ribution
control to be based on 8-octet extended communities, whereas ordinary BGP allows filtering and distribution control to be based on arbitrary sets of<= br> attributes (including IPv6-address-specific RTs, which the "bgpbgp&quo= t; proposal
doesn't accommodate). =C2=A0No need to mess with stuff like LOCAL_PREF,= MED,
etc. =C2=A0I guess it's supposed to be obvious that the general policy = mechanisms
of BGP are not needed for generic transport. =C2=A0Perhaps I'm the only= one to
whom that is not obvious.

The draft does allow the "cost community" (an extended community)= to be
carried, but I guess it will have no real effect, because the BGP decision<= br> process is not used. =C2=A0If you get two different messages with the same = type,
identifier, and sequence number, there is no complicated decision process t= o
run through, you just install the first one you get. Well, what could
possibly go wrong? =C2=A0I guess it's supposed to be obvious that if tw= o messages
have the same type/identifier/sequence, they couldn't possibly have
different data, and there couldn't possibly be any reason to prefer one= over
the other, or to force all the routers to make a consistent choice.

Bottom line: if there is one thing worse than using BGP to carry arbitrary<= br> data, it's inventing a new BGP message type for which the updating rule= s are
completely different. =C2=A0If your information distribution requirements c= annot
be adapted to utilize the BGP mechanisms, you really should use something else. =C2=A0On the other hand, if the BGP mechanisms are well-suited to you= r
information distribution requirements, why would you want to use a
completely different mechanism inside BGP?

BTW, if the SAFI isn't big enough to hold the type, the type can be put= into
the NLRI field. =C2=A0That's how we got the notion of "typed NLRI&= quot; ;-)


--001a113328f2da073404fdc42b3c-- From nobody Thu Jul 10 02:48:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C9C1B280A for ; Thu, 10 Jul 2014 02:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3TY7fOtcHyp for ; Thu, 10 Jul 2014 02:48:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B701B27E6 for ; Thu, 10 Jul 2014 02:48:36 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 09BF53B452E for ; Thu, 10 Jul 2014 11:48:35 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E5E674C056 for ; Thu, 10 Jul 2014 11:48:34 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 11:48:34 +0200 From: To: idr wg Thread-Topic: draft-litkowski-idr-flowspec-interfaceset Thread-Index: Ac+cIsw+lgYikyvKQGyocLFGhGsPuA== Date: Thu, 10 Jul 2014 09:48:34 +0000 Message-ID: <8982_1404985714_53BE6172_8982_9424_1_53C29892C857584299CBF5D05346208A07181096@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.10.80319 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/O2xw2RHBllT9eOsDh0D3Eidzv9k Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 09:48:40 -0000 Hi all, I've read the draft and IMO it is useful and address a real use case (enfor= cing infrastructure security ACL). First issue with existing infrastructure ACL is to make sure that all ACL o= n all routers are up to date. On this point, the draft does the job. A second issue with existing ACL is to make sure that the ACL are applied t= o all the right interfaces. Especially as new interfaces gets deployed, it = gets harder to have a hard guaranty that all interfaces have the right type= of ACL (someone could deploy a new external interface but forgot to config= ure it's interface-set type). On this point, IMO the draft could be improve= d. To cover this, I would propose to add a range for IANA allocation, and to d= efine a few well know values, such as interfaces running the IGP (which are= known to be internal/trusted), interfaces running eBGP (which are known to= be external/untrusted). Such well known types are automatically affected to interfaces by the imple= mentation and hence are not subject to service provider misconfiguration. This would translate into the proposed following additional text: 6. IANA Considerations=20 The IANA is requested to create and maintain a registry entitled "Assigned Flow spec interface-set" with the following registration procedure: Registry Name: Assigned Flow spec interface-set Range Registration Procedures ----------- ------------------------- 0x0000-3EFF Reserved for private use. 0x3F00-3FFF Standards Action/Early IANA Allocation. =09=20=20=20 The IANA is requested to update the registry "Assigned Flow spec interface-= set" as follows: 0x3F00: IGP interface 0x3F01: non IGP interface 0x3F02: eBGP interface 0x3F03: non eBGP interface 0x3F04: VRF interface 0x3F05: non VRF interface =09=20=20=20 --------- Please find below some more minor comments: 1) "An interface-set extended community with both flags set to zero MUST be treated as an error and as consequence, the FlowSpec update MUST be discarded." - What's the reason to discard it? A priori looks to me not the right thing= , from a security standpoint, to allow dropping a whole ACL/security rule, = by adding a community. (however, I agree that if you can add a community, y= ou can probably alter/drop the rule, hence I can't really provide an exampl= e where this would matter).=20=20 Plus IMO, I don't see this as an error. It's just a "NOP" instruction. - "MUST be discarded": please use the draft-ietf-idr-error-handling termino= logy (I guess "Treat-as-withdraw" while your term is close to "attribute di= scard"). 2) According to your text in section 4, I would move [I-D.uttaro-idr-bgp-pe= rsistence] to Informative reference. Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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 Jul 10 05:48:55 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A0A1B28D8 for ; Thu, 10 Jul 2014 05:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXb5m5v5Fcfz for ; Thu, 10 Jul 2014 05:48:50 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75401B28D6 for ; Thu, 10 Jul 2014 05:48:50 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:53574 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X5DmJ-0001A3-LY; Thu, 10 Jul 2014 12:48:47 +0000 From: "Russ White" To: , "'Robert Raszuk'" References: Your message of Tue, 08 Jul 2014 21:57:15 +0200. <22788.1404918579@erosen-lnx> In-Reply-To: <22788.1404918579@erosen-lnx> Date: Thu, 10 Jul 2014 08:48:38 -0400 Message-ID: <022901cf9c3d$46293ec0$d27bbc40$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIQdZ5Ala/lyCm9AE7nmtiy1POex5sXjl2w Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rFmcHHkhqDPqg_eLbBqUBZRpTDo Cc: 'Yakov Rekhter' , 'idr wg' Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 12:48:52 -0000 > - Define a new AFI. > - Store the "bgpbgp" type value in the SAFI. > - Store the "bgpbgp" identifier value in the NLRI. > - Invent a new attribute to hold the "bgpbgp" data (as you have suggested) I'm perfectly fine with this, actually. > Now just use "ordinary" BGP (no new message types needed), and presto, > problem solved. Err, wait, what was the problem again? The problem is that BGP is starting to be used to transport everything, whether we like it or not. IMHO, it's better to define a solid way to do this, rather than simply assuming one exists, and then creating 15 different ways to do it, all slightly different, because we just assume everyone is going to do it the same way. I guess, given the sarcasm on the list, that everyone would prefer to have 15 different ways to do something, each of them slightly different, because that's a much simpler solution than creating one way and sticking to it across the board. Russ From nobody Thu Jul 10 06:05:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFF41B28E3 for ; Thu, 10 Jul 2014 06:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed4MIBZTNIRY for ; Thu, 10 Jul 2014 06:05:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637841A0444 for ; Thu, 10 Jul 2014 06:05:16 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 9002EC0B1A for ; Thu, 10 Jul 2014 15:05:14 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 6D5A2158052 for ; Thu, 10 Jul 2014 15:05:14 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 15:05:09 +0200 From: To: DECRAENE Bruno IMT/OLN , idr wg Thread-Topic: draft-litkowski-idr-flowspec-interfaceset Thread-Index: Ac+cIsw+lgYikyvKQGyocLFGhGsPuAAHBIZQ Date: Thu, 10 Jul 2014 13:05:08 +0000 Message-ID: <32216_1404997514_53BE8F8A_32216_3071_1_f24e5175-cd47-4d06-b30f-2f554626dc59@OPEXCLILH02.corporate.adroot.infra.ftgroup> References: <8982_1404985714_53BE6172_8982_9424_1_53C29892C857584299CBF5D05346208A07181096@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <8982_1404985714_53BE6172_8982_9424_1_53C29892C857584299CBF5D05346208A07181096@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US 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.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.10.80319 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/IpHBVvWqRhWVnYVGVnLLDmVwHl0 Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:05:25 -0000 Hi Bruno, Thanks for the comment, Pls find inline comments. Thanks, Stephane -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.= com Sent: Thursday, July 10, 2014 11:49 To: idr wg Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset Hi all, I've read the draft and IMO it is useful and address a real use case (enfor= cing infrastructure security ACL). First issue with existing infrastructure ACL is to make sure that all ACL o= n all routers are up to date. On this point, the draft does the job. [SLI] Good to hear :) A second issue with existing ACL is to make sure that the ACL are applied t= o all the right interfaces. Especially as new interfaces gets deployed, it = gets harder to have a hard guaranty that all interfaces have the right type= of ACL (someone could deploy a new external interface but forgot to config= ure it's interface-set type). On this point, IMO the draft could be improve= d. To cover this, I would propose to add a range for IANA allocation, and to d= efine a few well know values, such as interfaces running the IGP (which are= known to be internal/trusted), interfaces running eBGP (which are known to= be external/untrusted). Such well known types are automatically affected to interfaces by the imple= mentation and hence are not subject to service provider misconfiguration. This would translate into the proposed following additional text: 6. IANA Considerations=20 The IANA is requested to create and maintain a registry entitled "Assigned Flow spec interface-set" with the following registration procedure: Registry Name: Assigned Flow spec interface-set Range Registration Procedures ----------- ------------------------- 0x0000-3EFF Reserved for private use. 0x3F00-3FFF Standards Action/Early IANA Allocation. =09=20=20=20 The IANA is requested to update the registry "Assigned Flow spec interface-= set" as follows: 0x3F00: IGP interface 0x3F01: non IGP interface 0x3F02: eBGP interface 0x3F03: non eBGP interface 0x3F04: VRF interface 0x3F05: non VRF interface [SLI] This may be a good idea, I would be interested by other feedbacks als= o. But I would support this sort of default inherited interface groups. =09=20=20=20 --------- Please find below some more minor comments: 1) "An interface-set extended community with both flags set to zero MUST be treated as an error and as consequence, the FlowSpec update MUST be discarded." - What's the reason to discard it? A priori looks to me not the right thing= , from a security standpoint, to allow dropping a whole ACL/security rule, = by adding a community. (however, I agree that if you can add a community, y= ou can probably alter/drop the rule, hence I can't really provide an exampl= e where this would matter).=20=20 Plus IMO, I don't see this as an error. It's just a "NOP" instruction. - "MUST be discarded": please use the draft-ietf-idr-error-handling termino= logy (I guess "Treat-as-withdraw" while your term is close to "attribute di= scard"). [SLI] This was an already identified action ... will be updated in next ver= sion. 2) According to your text in section 4, I would move [I-D.uttaro-idr-bgp-pe= rsistence] to Informative reference. [SLI] Ack Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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 ___________________________________________________________________________= ______________________________________________ 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 Jul 10 06:26:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAB61B28F2; Thu, 10 Jul 2014 06:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPrNiybQk6XE; Thu, 10 Jul 2014 06:26:36 -0700 (PDT) Received: from out-13.mail.exa.net.uk (out-13.mail.exa.net.uk [82.219.4.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C361B28F0; Thu, 10 Jul 2014 06:26:35 -0700 (PDT) Received: from smtp-2.mail.exa.net.uk (smtp-2.mail.exa.net.uk [82.219.5.2]) by out-13.mail.exa.net.uk (ExaSMTPD) with ESMTP id 0C0AF1C0073; Thu, 10 Jul 2014 14:26:33 +0100 (BST) Received: from [192.0.2.96] (office.exa-networks.co.uk [82.219.212.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id B1B6040263; Thu, 10 Jul 2014 14:26:32 +0100 (BST) Content-Type: multipart/signed; boundary="Apple-Mail=_55CFEB6A-8A9D-4508-8D76-6E9CFDD6E6F4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Mangin In-Reply-To: <022901cf9c3d$46293ec0$d27bbc40$@riw.us> Date: Thu, 10 Jul 2014 14:26:30 +0100 X-Mao-Original-Outgoing-Id: 426691589.983622-824f9b33662f71ee68b6213235bb5f53 Message-Id: References: Your message of Tue, 08 Jul 2014 21:57:15 +0200. <22788.1404918579@erosen-lnx> <022901cf9c3d$46293ec0$d27bbc40$@riw.us> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/idr/WZ5o8ky84FqX4X2xLJSHm7sl-K0 Cc: Yakov Rekhter , erosen@cisco.com, Robert Raszuk , idr wg Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:26:39 -0000 --Apple-Mail=_55CFEB6A-8A9D-4508-8D76-6E9CFDD6E6F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Russ, I have sympathy for your proposal. I just refactored ExaBGP code recently and UPDATE parsing is really a = Russian doll work, where each new RFC sub-define a new NLRI with = different semantic (and sub-semantic). At least = http://tools.ietf.org/html/draft-frs-bgp-operational-message-00 is = proposing to use new message type as they need to pass more than NLRI = information. So I believe trying to provide a framework for it to not have multiple = different format would make sense. Thomas On 10 Jul 2014, at 13:48, Russ White wrote: >=20 >> - Define a new AFI. >> - Store the "bgpbgp" type value in the SAFI. >> - Store the "bgpbgp" identifier value in the NLRI. >> - Invent a new attribute to hold the "bgpbgp" data (as you have = suggested) >=20 > I'm perfectly fine with this, actually.=20 >=20 >> Now just use "ordinary" BGP (no new message types needed), and = presto, >> problem solved. Err, wait, what was the problem again? >=20 > The problem is that BGP is starting to be used to transport = everything, > whether we like it or not. IMHO, it's better to define a solid way to = do > this, rather than simply assuming one exists, and then creating 15 = different > ways to do it, all slightly different, because we just assume everyone = is > going to do it the same way. I guess, given the sarcasm on the list, = that > everyone would prefer to have 15 different ways to do something, each = of > them slightly different, because that's a much simpler solution than > creating one way and sticking to it across the board. >=20 > Russ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 --Apple-Mail=_55CFEB6A-8A9D-4508-8D76-6E9CFDD6E6F4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlO+lIYACgkQA/52wvuLgaFN1wCfRxXHNqcMs7DivY6bbu3RuVxC C70AoIn/es7AiT+gsjx4WNL+AcSDkgxy =ae5W -----END PGP SIGNATURE----- --Apple-Mail=_55CFEB6A-8A9D-4508-8D76-6E9CFDD6E6F4-- From nobody Thu Jul 10 07:04:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492181B2911 for ; Thu, 10 Jul 2014 07:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GijtIgyUtLP for ; Thu, 10 Jul 2014 07:04:27 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7081B2910 for ; Thu, 10 Jul 2014 07:04:24 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 869C0C422; Thu, 10 Jul 2014 10:04:23 -0400 (EDT) Date: Thu, 10 Jul 2014 10:04:23 -0400 From: Jeffrey Haas To: Russ White Message-ID: <20140710140423.GS19932@pfrc> References: <22788.1404918579@erosen-lnx> <022901cf9c3d$46293ec0$d27bbc40$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <022901cf9c3d$46293ec0$d27bbc40$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/l5HMa5yJvYhFC6IEFz5EHKrQRO4 Cc: 'Yakov Rekhter' , erosen@cisco.com, 'Robert Raszuk' , 'idr wg' Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:04:36 -0000 Russ, On Thu, Jul 10, 2014 at 08:48:38AM -0400, Russ White wrote: > The problem is that BGP is starting to be used to transport everything, > whether we like it or not. IMHO, it's better to define a solid way to do > this, rather than simply assuming one exists, and then creating 15 different > ways to do it, all slightly different, because we just assume everyone is > going to do it the same way. I guess, given the sarcasm on the list, that > everyone would prefer to have 15 different ways to do something, each of > them slightly different, because that's a much simpler solution than > creating one way and sticking to it across the board. I think part of what Eric's exercise showed is that we pretty much already have plumbing to do this. If we were to extend this one step further, the type of BLOB you're transporting implies format. If that format happens to be a list of prefix-like things we're back to NLRI. Where this proposal really differs is the idea that we may be transporting more general data that isn't an NLRI. In that case, a new message type may help. If you expect this stuff to be flooded without understanding using RR and other BGP plumbing, then not requiring capability advertisement also helps. While I'm sympathetic to Thomas's issue, regardless of format, if it's data to be understood there will always be that marshalling/demarshalling layer. The only thing that's really changed over the years has been the conventions permitting automation. (XDR, ASN, JSON, protobufs, etc.) -- Jeff From nobody Thu Jul 10 07:22:11 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406981B2916 for ; Thu, 10 Jul 2014 07:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqGF3hCvI3jw for ; Thu, 10 Jul 2014 07:22:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D87FD1B2910 for ; Thu, 10 Jul 2014 07:22:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8B135C422; Thu, 10 Jul 2014 10:22:05 -0400 (EDT) Date: Thu, 10 Jul 2014 10:22:05 -0400 From: Jeffrey Haas To: bruno.decraene@orange.com Message-ID: <20140710142205.GT19932@pfrc> References: <8982_1404985714_53BE6172_8982_9424_1_53C29892C857584299CBF5D05346208A07181096@PEXCVZYM11.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8982_1404985714_53BE6172_8982_9424_1_53C29892C857584299CBF5D05346208A07181096@PEXCVZYM11.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/l10j3eGKdemCl3zNye1SJpI2Kx4 Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:22:08 -0000 Bruno, On Thu, Jul 10, 2014 at 09:48:34AM +0000, bruno.decraene@orange.com wrote: > This would translate into the proposed following additional text: > > 6. IANA Considerations > > The IANA is requested to create and maintain a registry entitled > "Assigned Flow spec interface-set" with the following > registration procedure: > > Registry Name: Assigned Flow spec interface-set > > Range Registration Procedures > ----------- ------------------------- > 0x0000-3EFF Reserved for private use. > 0x3F00-3FFF Standards Action/Early IANA Allocation. > > > The IANA is requested to update the registry "Assigned Flow spec interface-set" as follows: > > 0x3F00: IGP interface > 0x3F01: non IGP interface > 0x3F02: eBGP interface > 0x3F03: non eBGP interface > 0x3F04: VRF interface > 0x3F05: non VRF interface As Robert Raszuk had already pointed out off-list, "Why aren't we using wide communities for this". :-) I had intended to let the idea for these constraints circulate a bit for people to get comfortable with it before bringing up wide comms as the policy mechanism for it. -- Jeff From nobody Thu Jul 10 07:28:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8CD1B2912 for ; Thu, 10 Jul 2014 07:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6drubWrG1jvV for ; Thu, 10 Jul 2014 07:28:05 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945571A0648 for ; Thu, 10 Jul 2014 07:28:05 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:57394 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X5FKO-0002RG-6E; Thu, 10 Jul 2014 14:28:04 +0000 From: "Russ White" To: "'Jeffrey Haas'" References: <22788.1404918579@erosen-lnx> <022901cf9c3d$46293ec0$d27bbc40$@riw.us> <20140710140423.GS19932@pfrc> In-Reply-To: <20140710140423.GS19932@pfrc> Date: Thu, 10 Jul 2014 10:27:55 -0400 Message-ID: <001501cf9c4b$24815650$6d8402f0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJL8Qb7KwPE6svD1Y+kKlz+qksBTQIQdZ5AAPUk02YDGDejF5pvxTUg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Jq6lmkTLzXBvWdRSSNJXsO9lTAM Cc: 'Yakov Rekhter' , erosen@cisco.com, 'Robert Raszuk' , 'idr wg' Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:28:08 -0000 > I think part of what Eric's exercise showed is that we pretty much already > have plumbing to do this. If we were to extend this one step further, the > type of BLOB you're transporting implies format. If that format happens to > be a list of prefix-like things we're back to NLRI. > Where this proposal really differs is the idea that we may be transporting > more general data that isn't an NLRI. In that case, a new message type may > help. If you expect this stuff to be flooded without understanding using RR > and other BGP plumbing, then not requiring capability advertisement also > helps. Sure -- but given the sense of the WG, there's no interest in doing anything more or less than what we're doing today -- inventing new semantics for everything that comes along, no matter whether or not it fits. So, I'm inclined, at this point, to let the draft die, and forget presenting it in Toronto. It was an effort at making things simpler. The WG isn't interested in simpler. So be it. Russ From nobody Thu Jul 10 07:35:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B0E1A05D1 for ; Thu, 10 Jul 2014 07:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnUeDTX9VnXT for ; Thu, 10 Jul 2014 07:35:12 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFE31A01F4 for ; Thu, 10 Jul 2014 07:35:12 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id hn18so3130377igb.11 for ; Thu, 10 Jul 2014 07:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PHhAlHzfL6iNQWTkXfzeaqAHpEtmHRLsuPpRB8OcAsU=; b=FcDX7AvsfBLVVfKmRZ70ufvKBMLXLcaH7G5iQuncPXbtvyVxIm0j1rNsL6i0yx+AA/ 7KNnh7zzBrkBiVEykpbkc7eck4B4ZE+qmqdaMAhbXzJo8+WKT9YR5daFfFJBYm+cnXlD 95RYaLR1CSw+Q9YcIA9lPNl8DFf2hlMytAiOf3kqvH27htnSoK+OaEbXfy9IY+sOwynr hD6gWRfjSxDC9PTls1cn9dp3cSjjama/sTNKmQ3LoZnWMHsoEzosABVStI5xmOjrqbBH r0T7EiEJOjicnQtH7YsbT/ifWZ+mSGoSdDb20ZNhKemE956dZ69cs9ZJwezHNmTDkREB VRog== MIME-Version: 1.0 X-Received: by 10.42.240.20 with SMTP id ky20mr2519625icb.97.1405002912021; Thu, 10 Jul 2014 07:35:12 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Thu, 10 Jul 2014 07:35:11 -0700 (PDT) Received: by 10.64.89.38 with HTTP; Thu, 10 Jul 2014 07:35:11 -0700 (PDT) In-Reply-To: <001501cf9c4b$24815650$6d8402f0$@riw.us> References: <22788.1404918579@erosen-lnx> <022901cf9c3d$46293ec0$d27bbc40$@riw.us> <20140710140423.GS19932@pfrc> <001501cf9c4b$24815650$6d8402f0$@riw.us> Date: Thu, 10 Jul 2014 16:35:11 +0200 X-Google-Sender-Auth: U1sgYM0Ar40uwv76J51pH9gMfp4 Message-ID: From: Robert Raszuk To: Russ White Content-Type: multipart/alternative; boundary=001a113328f27ac38e04fdd7bb7e Archived-At: http://mailarchive.ietf.org/arch/msg/idr/5S3oG-8drO5RlXcCFEPX7PTJRMU Cc: idr wg , erosen@cisco.com, Yakov Rekhter Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:35:13 -0000 --001a113328f27ac38e04fdd7bb7e Content-Type: text/plain; charset=UTF-8 Russ, If you are claiming that the draft is simplifying something it would be useful to compare it against current "complex way" side by side. Perhaps then those of us who just either do not see what is so complex today or do not see how your proposal makes it simpler could learn. Rgs, R. On Jul 10, 2014 4:28 PM, "Russ White" wrote: > > > I think part of what Eric's exercise showed is that we pretty much > already > > have plumbing to do this. If we were to extend this one step further, > the > > type of BLOB you're transporting implies format. If that format happens > to > > be a list of prefix-like things we're back to NLRI. > > > Where this proposal really differs is the idea that we may be > transporting > > more general data that isn't an NLRI. In that case, a new message type > may > > help. If you expect this stuff to be flooded without understanding using > RR > > and other BGP plumbing, then not requiring capability advertisement also > > helps. > > Sure -- but given the sense of the WG, there's no interest in doing > anything > more or less than what we're doing today -- inventing new semantics for > everything that comes along, no matter whether or not it fits. So, I'm > inclined, at this point, to let the draft die, and forget presenting it in > Toronto. > > It was an effort at making things simpler. The WG isn't interested in > simpler. So be it. > > Russ > > > --001a113328f27ac38e04fdd7bb7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Russ,

If you are claiming that the draft is simplifying something = it would be useful to compare it against current "complex way" si= de by side.

Perhaps then those of us who just either do not see what is = so complex today or do not see how your proposal makes it simpler could lea= rn.

Rgs,
R.

On Jul 10, 2014 4:28 PM, "Russ White" = <russw@riw.us> wrote:

> I think part of what Eric's exercise showed is that we pretty much= already
> have plumbing to do this. =C2=A0If we were to extend this one step fur= ther, the
> type of BLOB you're transporting implies format. =C2=A0If that for= mat happens
to
> be a list of prefix-like things we're back to NLRI.

> Where this proposal really differs is the idea that we may be transpor= ting
> more general data that isn't an NLRI. =C2=A0In that case, a new me= ssage type
may
> help. =C2=A0If you expect this stuff to be flooded without understandi= ng using
RR
> and other BGP plumbing, then not requiring capability advertisement al= so
> helps.

Sure -- but given the sense of the WG, there's no interest in doing any= thing
more or less than what we're doing today -- inventing new semantics for=
everything that comes along, no matter whether or not it fits. So, I'm<= br> inclined, at this point, to let the draft die, and forget presenting it in<= br> Toronto.

It was an effort at making things simpler. The WG isn't interested in simpler. So be it.

Russ


--001a113328f27ac38e04fdd7bb7e-- From nobody Thu Jul 10 07:40:08 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57511A0233 for ; Thu, 10 Jul 2014 07:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5CGOWKVOFpf for ; Thu, 10 Jul 2014 07:40:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CCA9C1A01F4 for ; Thu, 10 Jul 2014 07:40:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8DF19C422; Thu, 10 Jul 2014 10:40:06 -0400 (EDT) Date: Thu, 10 Jul 2014 10:40:06 -0400 From: Jeffrey Haas To: Russ White Message-ID: <20140710144006.GV19932@pfrc> References: <22788.1404918579@erosen-lnx> <022901cf9c3d$46293ec0$d27bbc40$@riw.us> <20140710140423.GS19932@pfrc> <001501cf9c4b$24815650$6d8402f0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001501cf9c4b$24815650$6d8402f0$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/zDmnAeWJSA-0Uy-B91CJ5gMrPTs Cc: 'Yakov Rekhter' , erosen@cisco.com, 'Robert Raszuk' , 'idr wg' Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:40:07 -0000 On Thu, Jul 10, 2014 at 10:27:55AM -0400, Russ White wrote: > Sure -- but given the sense of the WG, there's no interest in doing anything > more or less than what we're doing today -- inventing new semantics for > everything that comes along, no matter whether or not it fits. So, I'm > inclined, at this point, to let the draft die, and forget presenting it in > Toronto. > > It was an effort at making things simpler. The WG isn't interested in > simpler. So be it. Much of my own harassment is coming from a slightly different perspective: I don't think we want it now. I suspect we'll want it later. Here's the issues we need to solve for that time. But for the time being, it's a bit academic. -- Jeff From nobody Thu Jul 10 07:40:50 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45C61A07A1 for ; Thu, 10 Jul 2014 07:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lohYeKKqpqkY for ; Thu, 10 Jul 2014 07:40:47 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDFB1A01F4 for ; Thu, 10 Jul 2014 07:40:47 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:57662 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X5FWe-0002Y3-2c; Thu, 10 Jul 2014 14:40:44 +0000 From: "Russ White" To: "'Robert Raszuk'" References: <22788.1404918579@erosen-lnx> <022901cf9c3d$46293ec0$d27bbc40$@riw.us> <20140710140423.GS19932@pfrc> <001501cf9c4b$24815650$6d8402f0$@riw.us> In-Reply-To: Date: Thu, 10 Jul 2014 10:40:35 -0400 Message-ID: <004401cf9c4c$e96dd2d0$bc497870$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJL8Qb7KwPE6svD1Y+kKlz+qksBTQIQdZ5AAPUk02YDGDejFwHSCLxiAc9XL/+aUrzuEA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/29lkOZLhb7TjokrO0NiEG4whryw Cc: 'idr wg' , erosen@cisco.com, 'Yakov Rekhter' Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:40:48 -0000 > If you are claiming that the draft is simplifying something it would = be useful > to compare it against current "complex way" side by side. Complexity =3D=3D a different afi/safi for each type of blob encoding, = each with their own formatting, rules, pieces of the packet header to = ignore, etc. Simple =3D=3D one format, based on TLVs, that has the flexibility to = encode whatever is needed, without being forced to include pieces of the = packet header that won't be used, etc. But again, if your definition of "simple," is "we'll define a new = AFI/SAFI type for any sort of blob of information that comes along, no = matter whether the AS_PATH or any other attribute makes sense in the = context of this blob, and we'll just stick it in BGP because that's a = convenient way to carry random information throughout the Internet," = then have at it. What I see is a lot of stuff accruing that we're = eventually going to pay for in terms of implementation and deployment -- = we're building huge buildings on foundations designed for something much = smaller and different, and just expecting it all to work. So, again, I'm going to drop this draft, and ask that the slot be = removed in VanCouver. No point in even attempting to try and make a case = for this sort of thing if there's no perception that BGP is becoming an = overused kitchen sink. =20 Russ From nobody Thu Jul 10 07:45:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7D41A050E for ; Thu, 10 Jul 2014 07:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUx-u-yIqx26 for ; Thu, 10 Jul 2014 07:45:43 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6A91A064A for ; Thu, 10 Jul 2014 07:45:43 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:57770 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X5FbO-0002ap-N2; Thu, 10 Jul 2014 14:45:39 +0000 From: "Russ White" To: "'Jeffrey Haas'" References: <22788.1404918579@erosen-lnx> <022901cf9c3d$46293ec0$d27bbc40$@riw.us> <20140710140423.GS19932@pfrc> <001501cf9c4b$24815650$6d8402f0$@riw.us> <20140710144006.GV19932@pfrc> In-Reply-To: <20140710144006.GV19932@pfrc> Date: Thu, 10 Jul 2014 10:45:29 -0400 Message-ID: <004d01cf9c4d$990b8e80$cb22ab80$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJL8Qb7KwPE6svD1Y+kKlz+qksBTQIQdZ5AAPUk02YDGDejFwHSCLxiAhqZmT+aUGQrcA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_mBQuKWRu4dY2vJRm6ASkV_6hpU Cc: 'Yakov Rekhter' , erosen@cisco.com, 'Robert Raszuk' , 'idr wg' Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:45:44 -0000 > Much of my own harassment is coming from a slightly different perspective: > I don't think we want it now. I suspect we'll want it later. Here's the issues > we need to solve for that time. Then we'll just wait until all sorts of stuff is already stuffed into BGP, and worry about sorting it out then, rather than seeing the trend now and making a way (whether this is the right way or not) to provide transport for things that don't fit. Each time we run into adding something new into BGP, we always say, "well, we have these requirements now, and we don't have time to deploy a new transport mechanism, or wait for IDR to design and build a new transport mechanism within the BGP framework." So each time we add something new, and then go back to, "we might need this later, but for now we don't." And hence we never do anything but keep adding more and more stuff in, because we always find a way to release the pressure without solving the root problem. At least that's the picture I see developing (perhaps wrongly). So, again, I'm dropping the draft, and won't present in Toronto. We can raise the issue again in a few months/years when someone suggests adding some other new custom coding in the AFI/SAFI, and end up in the same place yet again (we can stuff into this little corner over here, whether or not it fits, we need the extension now, etc.). :-) Russ From nobody Thu Jul 10 07:57:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429EB1A0A85 for ; Thu, 10 Jul 2014 07:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0inlsZfLC1G for ; Thu, 10 Jul 2014 07:57:35 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F5D1A050E for ; Thu, 10 Jul 2014 07:57:34 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id r10so3113690igi.4 for ; Thu, 10 Jul 2014 07:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PNzlffoZGJhhBTYz8twY2pAx0WeMOnUHkLPfKovAQ1E=; b=EfjXi+UsZH0LJZZdILcUe07wn8bd5Ys49o+2vcKyDDVIRCt5CKBtEj4iUkHGwBzX5r dAdzVZI522Hc7vUV4DLRYOUlHQaRYpPosetVHK71VmJX/r0ic7bW3Fzv5mTH9+iVaMpE 37WntrudchXZCrgCKrsZdwEEW6zFZBPsUD5ysigKhsBDq9pUMEgFjrPNlxMtZ2cJPtup G6CpjWxhRbp1nZTtdVqxElRiVkRLoCDJSWfanEjzAbN5ug3MugSq+Eo+l2vo1xmhgAxG TAPJ4wuZ/yZA4UDpKUCKCJWa2EFRgZcW/UNViksWPP+W96ZUNWacL0pxmIhdzXib+EoB lLjg== MIME-Version: 1.0 X-Received: by 10.50.12.38 with SMTP id v6mr22020970igb.29.1405004254296; Thu, 10 Jul 2014 07:57:34 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Thu, 10 Jul 2014 07:57:34 -0700 (PDT) In-Reply-To: <004401cf9c4c$e96dd2d0$bc497870$@riw.us> References: <22788.1404918579@erosen-lnx> <022901cf9c3d$46293ec0$d27bbc40$@riw.us> <20140710140423.GS19932@pfrc> <001501cf9c4b$24815650$6d8402f0$@riw.us> <004401cf9c4c$e96dd2d0$bc497870$@riw.us> Date: Thu, 10 Jul 2014 16:57:34 +0200 X-Google-Sender-Auth: mnFnd_uvfH5N7SxZlJ-9iOwHO08 Message-ID: From: Robert Raszuk To: Russ White Content-Type: multipart/alternative; boundary=089e0112c39c7c419f04fdd80bad Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_KiaTLZCLCVBYWCNOZpyQbglbNk Cc: idr wg , "erosen@cisco.com" , Yakov Rekhter Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:57:37 -0000 --089e0112c39c7c419f04fdd80bad Content-Type: text/plain; charset=UTF-8 Russ, I don't follow your bashing of adding new stuff to BGP as last time I read your proposal it is also adding new stuff to BGP. The fact that this is new message vs new AFI seems completely irrelevant. As to what BGP was designed to do I will let Yakov answer it :) All you are doing is just shifting the demux point from AFI/SAFI to message type. Is this such an advantage ? Moreover more and more information to be carried in networks should be sent p2mp - what BGP transport really does. Putting on top of then a new layer of RT based information scoping via use of RTC is very ugly patch. We do need a new protocol which can be optimal in registering for information needed via query/reply form. IF-MAP comes to mind as example. Your proposal in no way solves this issue. In fact BGP-LS fits query/reply model as example rather then sending entire LSDB all over the separate BGP layer out of which depending on the application only a tiny subset of data may be used. That is IMHO a direction we should persue maybe in RTGWG maybe in OPS ... Best, R. On Thu, Jul 10, 2014 at 4:40 PM, Russ White wrote: > > > If you are claiming that the draft is simplifying something it would be > useful > > to compare it against current "complex way" side by side. > > Complexity == a different afi/safi for each type of blob encoding, each > with their own formatting, rules, pieces of the packet header to ignore, > etc. > > Simple == one format, based on TLVs, that has the flexibility to encode > whatever is needed, without being forced to include pieces of the packet > header that won't be used, etc. > > But again, if your definition of "simple," is "we'll define a new AFI/SAFI > type for any sort of blob of information that comes along, no matter > whether the AS_PATH or any other attribute makes sense in the context of > this blob, and we'll just stick it in BGP because that's a convenient way > to carry random information throughout the Internet," then have at it. What > I see is a lot of stuff accruing that we're eventually going to pay for in > terms of implementation and deployment -- we're building huge buildings on > foundations designed for something much smaller and different, and just > expecting it all to work. > > So, again, I'm going to drop this draft, and ask that the slot be removed > in VanCouver. No point in even attempting to try and make a case for this > sort of thing if there's no perception that BGP is becoming an overused > kitchen sink. > > Russ > > > --089e0112c39c7c419f04fdd80bad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Russ,

I don't follow your bashing of adding new stuff to BGP as last time I r= ead your proposal it is also adding new stuff to BGP. The fact that this is= new message vs new AFI seems completely irrelevant.=C2=A0

As to what BGP was designed to do I will let Yakov = answer it :)

All you are doing is just shifting the demux point = from AFI/SAFI to message type. Is this such an advantage ?=C2=A0

Moreover more and more information to be carried in= networks should be sent p2mp - what BGP transport really does. Putting on = top of then a new layer of RT based information scoping via use of RTC is v= ery ugly patch.

We do need a new protocol which can b= e optimal in registering for information needed via query/reply form. IF-MA= P comes to mind as example. Your proposal in no way solves this issue. In f= act BGP-LS fits query/reply model as example rather then sending entire LSD= B all over the separate BGP layer out of which depending on the application= only a tiny subset of data may be used.=C2=A0

That is IMHO a direction we should pe= rsue maybe in RTGWG maybe in OPS ...=C2=A0

Best,
R.








On Thu, Jul 10, 2014 at 4:40 PM, Russ Wh= ite <russw@riw.us> wrote:

> If you are claiming that the draft is simplifying something it would b= e useful
> to compare it against current "complex way" side by side.
Complexity =3D=3D a different afi/safi for each type of blob encoding= , each with their own formatting, rules, pieces of the packet header to ign= ore, etc.

Simple =3D=3D one format, based on TLVs, that has the flexibility to encode= whatever is needed, without being forced to include pieces of the packet h= eader that won't be used, etc.

But again, if your definition of "simple," is "we'll def= ine a new AFI/SAFI type for any sort of blob of information that comes alon= g, no matter whether the AS_PATH or any other attribute makes sense in the = context of this blob, and we'll just stick it in BGP because that's= a convenient way to carry random information throughout the Internet,"= ; then have at it. What I see is a lot of stuff accruing that we're eve= ntually going to pay for in terms of implementation and deployment -- we= 9;re building huge buildings on foundations designed for something much sma= ller and different, and just expecting it all to work.

So, again, I'm going to drop this draft, and ask that the slot be remov= ed in VanCouver. No point in even attempting to try and make a case for thi= s sort of thing if there's no perception that BGP is becoming an overus= ed kitchen sink.

Russ



--089e0112c39c7c419f04fdd80bad-- From nobody Thu Jul 10 07:58:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA0F1A0A9A for ; Thu, 10 Jul 2014 07:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30plhQ85MOWL for ; Thu, 10 Jul 2014 07:58:43 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3761A0659 for ; Thu, 10 Jul 2014 07:58:42 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id r10so3158563igi.16 for ; Thu, 10 Jul 2014 07:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ypLbytzjlvQq3eGBkPmpIwo78rcvtkzWMFgLwvyhA9w=; b=sRKKd/1Ea/aYJSHg5jOBSZ8QcjCoEOnn0PuyWQJiG7nkQK6SIWHY5HoCnuOlIBfy7n saK9Wes30a9qQqnMRM9PJ6KKDjDm3niHou6o2vuwCEqdBJnnDxxYc3tKDjgD1ag+P8b2 vy5+d9SESETlgjgNhSUUVlYYQjfhQmOdlEnUGh82YS6Wsb0TVXEIVnjvdlE/9saZUQI/ sL4Zv3D28+mDTwkviRU/8+sghRhR4NmnP6CEd3uAN2nSDKvP6ujXEgP/UZfz1B5Gmdb3 X+WShf7llJVjRYHxawEHvQn/GTToRU5hfuMt0VcjIpffHGs5ClSCLo/Re6nD8pn+Fe3C xvhw== MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr22035912igt.29.1405004322206; Thu, 10 Jul 2014 07:58:42 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Thu, 10 Jul 2014 07:58:42 -0700 (PDT) In-Reply-To: References: <22788.1404918579@erosen-lnx> <022901cf9c3d$46293ec0$d27bbc40$@riw.us> <20140710140423.GS19932@pfrc> <001501cf9c4b$24815650$6d8402f0$@riw.us> <004401cf9c4c$e96dd2d0$bc497870$@riw.us> Date: Thu, 10 Jul 2014 16:58:42 +0200 X-Google-Sender-Auth: _3oCnmvQwKnsh8RgHSYYC-C9PLY Message-ID: From: Robert Raszuk To: Russ White Content-Type: multipart/alternative; boundary=047d7bdc15b28879ed04fdd80f26 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/fMtIE4GNEeDI7rT9ck9gF34o4YI Cc: idr wg , "erosen@cisco.com" , Yakov Rekhter Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:58:45 -0000 --047d7bdc15b28879ed04fdd80f26 Content-Type: text/plain; charset=UTF-8 sorry one typo .. s/should be sent p2mp/should NOT be sent p2mp/ r. On Thu, Jul 10, 2014 at 4:57 PM, Robert Raszuk wrote: > Russ, > > I don't follow your bashing of adding new stuff to BGP as last time I read > your proposal it is also adding new stuff to BGP. The fact that this is new > message vs new AFI seems completely irrelevant. > > As to what BGP was designed to do I will let Yakov answer it :) > > All you are doing is just shifting the demux point from AFI/SAFI to > message type. Is this such an advantage ? > > Moreover more and more information to be carried in networks should be > sent p2mp - what BGP transport really does. Putting on top of then a new > layer of RT based information scoping via use of RTC is very ugly patch. > > We do need a new protocol which can be optimal in registering for > information needed via query/reply form. IF-MAP comes to mind as example. > Your proposal in no way solves this issue. In fact BGP-LS fits query/reply > model as example rather then sending entire LSDB all over the separate BGP > layer out of which depending on the application only a tiny subset of data > may be used. > > That is IMHO a direction we should persue maybe in RTGWG maybe in OPS ... > > Best, > R. > > > > > > > > > On Thu, Jul 10, 2014 at 4:40 PM, Russ White wrote: > >> >> > If you are claiming that the draft is simplifying something it would be >> useful >> > to compare it against current "complex way" side by side. >> >> Complexity == a different afi/safi for each type of blob encoding, each >> with their own formatting, rules, pieces of the packet header to ignore, >> etc. >> >> Simple == one format, based on TLVs, that has the flexibility to encode >> whatever is needed, without being forced to include pieces of the packet >> header that won't be used, etc. >> >> But again, if your definition of "simple," is "we'll define a new >> AFI/SAFI type for any sort of blob of information that comes along, no >> matter whether the AS_PATH or any other attribute makes sense in the >> context of this blob, and we'll just stick it in BGP because that's a >> convenient way to carry random information throughout the Internet," then >> have at it. What I see is a lot of stuff accruing that we're eventually >> going to pay for in terms of implementation and deployment -- we're >> building huge buildings on foundations designed for something much smaller >> and different, and just expecting it all to work. >> >> So, again, I'm going to drop this draft, and ask that the slot be removed >> in VanCouver. No point in even attempting to try and make a case for this >> sort of thing if there's no perception that BGP is becoming an overused >> kitchen sink. >> >> Russ >> >> >> > --047d7bdc15b28879ed04fdd80f26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
sorry one typo ..

s/should be sent p2mp/should NOT be sent = p2mp/

r.
=

On Thu, Jul 10, 2014 at 4:57 PM, Robert = Raszuk <robert@raszuk.net> wrote:
Russ,

I don't follow your bashing of adding new stuff to BGP as last time I r= ead your proposal it is also adding new stuff to BGP. The fact that this is= new message vs new AFI seems completely irrelevant.=C2=A0

As to what BGP was designed to do I will let Yakov = answer it :)

All you are doing is just shifting the demux point = from AFI/SAFI to message type. Is this such an advantage ?=C2=A0

Moreover more and more information to be carried in= networks should be sent p2mp - what BGP transport really does. Putting on = top of then a new layer of RT based information scoping via use of RTC is v= ery ugly patch.

We do need a new protocol which can b= e optimal in registering for information needed via query/reply form. IF-MA= P comes to mind as example. Your proposal in no way solves this issue. In f= act BGP-LS fits query/reply model as example rather then sending entire LSD= B all over the separate BGP layer out of which depending on the application= only a tiny subset of data may be used.=C2=A0

That is IMHO a direction we should pe= rsue maybe in RTGWG maybe in OPS ...=C2=A0

Best,
R.








On Thu, Jul 10, 2014 at 4:40 PM, Russ Wh= ite <russw@riw.us> wrote:

> If you are claiming that the draft is simplifying something it would b= e useful
> to compare it against current "complex way" side by side.
Complexity =3D=3D a different afi/safi for each type of blob encoding= , each with their own formatting, rules, pieces of the packet header to ign= ore, etc.

Simple =3D=3D one format, based on TLVs, that has the flexibility to encode= whatever is needed, without being forced to include pieces of the packet h= eader that won't be used, etc.

But again, if your definition of "simple," is "we'll def= ine a new AFI/SAFI type for any sort of blob of information that comes alon= g, no matter whether the AS_PATH or any other attribute makes sense in the = context of this blob, and we'll just stick it in BGP because that's= a convenient way to carry random information throughout the Internet,"= ; then have at it. What I see is a lot of stuff accruing that we're eve= ntually going to pay for in terms of implementation and deployment -- we= 9;re building huge buildings on foundations designed for something much sma= ller and different, and just expecting it all to work.

So, again, I'm going to drop this draft, and ask that the slot be remov= ed in VanCouver. No point in even attempting to try and make a case for thi= s sort of thing if there's no perception that BGP is becoming an overus= ed kitchen sink.

Russ




--047d7bdc15b28879ed04fdd80f26-- From nobody Thu Jul 10 08:00:59 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0A81A0A9B for ; Thu, 10 Jul 2014 08:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxfPJKlG-Exn for ; Thu, 10 Jul 2014 08:00:50 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F541A0659 for ; Thu, 10 Jul 2014 08:00:50 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:58169 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X5Fq4-0002hv-9r; Thu, 10 Jul 2014 15:00:48 +0000 From: "Russ White" To: "'Robert Raszuk'" References: <22788.1404918579@erosen-lnx> <022901cf9c3d$46293ec0$d27bbc40$@riw.us> <20140710140423.GS19932@pfrc> <001501cf9c4b$24815650$6d8402f0$@riw.us> <004401cf9c4c$e96dd2d0$bc497870$@riw.us> In-Reply-To: Date: Thu, 10 Jul 2014 11:00:39 -0400 Message-ID: <007401cf9c4f$b732e870$2598b950$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJL8Qb7KwPE6svD1Y+kKlz+qksBTQIQdZ5AAPUk02YDGDejFwHSCLxiAc9XL/8CfvjlFQFVLvIemjQh9aA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/idr/wfZ2mIL0n750OvrfQ6h2EB-2LYo Cc: 'idr wg' , erosen@cisco.com, 'Yakov Rekhter' Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:00:56 -0000 > All you are doing is just shifting the demux point from AFI/SAFI to = message > type. Is this such an advantage ? Not really, but I'm not going to belabor the point, because it should be = clear from the draft that's not all that's involved. When we get to the = point that BGP falls over, we can all talk about what BGP was "meant to = do," and then propose some real solution to the problem at hand.=20 Sue -- please take this draft off the presentation list for Toronto. Russ From nobody Thu Jul 10 08:18:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B84F1A0AAA for ; Thu, 10 Jul 2014 08:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od6uwTxJcpFl for ; Thu, 10 Jul 2014 08:18:16 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3531A0A9E for ; Thu, 10 Jul 2014 08:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3848; q=dns/txt; s=iport; t=1405005445; x=1406215045; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=dvBFHYdAd6geNEjG5GNMpE2MQVxnFVfgTA8mZmB0pS8=; b=ScO+Yfy6RJTLxyBUMBF7anCewmYD35rkHjQ+UBgMuTrF0XLYws0FYFz0 dxh23d1I5xzx3eH127qOIs79BXBS6RXa/PoF3205g9fjR0M1MdO56n22X 0DlcgS7/lbwxw5I7p2gzescz6km6Bod1tEi1UiLL5JgS1PHsK+rrrK76E U=; X-IronPort-AV: E=Sophos;i="5.01,638,1400025600"; d="scan'208";a="339095328" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jul 2014 15:17:24 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6AFHOZB022316; Thu, 10 Jul 2014 15:17:24 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id EB4D13F9; Thu, 10 Jul 2014 11:17:23 -0400 (EDT) From: Eric Rosen To: Jeffrey Haas In-reply-to: Your message of Thu, 10 Jul 2014 10:04:23 -0400. <20140710140423.GS19932@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14404.1405005443.1@erosen-lnx> Date: Thu, 10 Jul 2014 11:17:23 -0400 Message-ID: <14405.1405005443@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Fn_ImMqnReNNMmjKLYtFYgd73fg Cc: IDR WG Subject: Re: [Idr] draft-white-bgpbgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:18:21 -0000 Jeff> Where this proposal really differs is the idea that we may be Jeff> transporting more general data that isn't an NLRI. I think the bgpbgp proposal is not really about the syntax or the semantics of the data, it's about the updating procedures. In standard BGP updating, the AFI/SAFI/NLRI determines whether two routes are comparable. The decision process then chooses among comparable routes using a set of procedures that is well-defined, policy-driven, and guaranteed to converge. The bgpbgp proposal introduces a new decision process, based on sequence numbers, that is completely different than the old one. This is not so simple. In the link state IGPs, updating is based on sequence numbers, but there are elaborate mechanisms for synchronizing and resynchronizing the sequence numbers. These mechanisms seem to have been omitted from the bgpbgp proposal. > The sequence field can be used by the application to indicate the > "freshness" of the information carried in the data field. The most > obvious use of this field would be a monotonically increasing number > indicating a newer version of some information advertised previously. I see quite a few problems embedded in this approach: - There is no requirement that two messages with the same type/identifier originate from the same router. So what sense does it even make to compare the sequence numbers? - There is no statement about whether the sequence space wraps around, or clamps at the maximum value. Each method has problems that would need to be addressed, but are not addressed in the draft. - The draft first suggests that the use of the sequence numbers is left to the application, and then bases the entire application-independent updating procedure upon them. - Even if two messages with the same type/id originated at the same router, I don't see anything that ensures that the "newer" message has the "larger" sequence number. The originating router may have rebooted between those messages, and there is no procedure to ensure that all the pre-reboot messages are eradicated before any of the post-reboot messages are received. Sequence number zero has the special meaning "flush", but it seems to me that the flush messages could easily be seen at some router out of sequence with respect to the non-zero messages. This would result in inconsistencies around the network. To me, adding a sequence-number-based updating procedure to BGP is not a simplification. Anyone who's worked on the sequencing mechanisms of link state routing will know how complicated it is to ensure convergence based on sequence numbers. Sure, someone could claim, "once we add a completely new decision process to BGP, we'll have the ultimate one-size-fits-all solution, and that will greatly simplify our lives in the future". Well, I'm sure we've all heard that one before. Thomas> At least http://tools.ietf.org/html/draft-frs-operational- Thomas> message-00 is proposing to use new message type as they need to pass Thomas> more than NLRI information. If I understand correctly, the messages in that draft are just passed from one end of a session to the other. The UPDATE message, on the other hand, is a mechanism for distributing information around the entire network, in a P2MP signaling paradigm. The distribution requirements for Advisory message, e.g., are very different than the distribution requirements for the UPDATE message. So it makes sense to have a different message type. But I think the bgpbgp proposal is focused on information that does need to be distributed around the network, so it makes a lot less sense to have a different message type. Of course, it's also worth noting that the operational-message draft is long expired. From nobody Fri Jul 11 00:47:26 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3870A1B2AA1 for ; Fri, 11 Jul 2014 00:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paY89ZQs47nJ for ; Fri, 11 Jul 2014 00:47:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1018A1B2923 for ; Fri, 11 Jul 2014 00:47:22 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4A9022ACDB9; Fri, 11 Jul 2014 09:47:19 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 2F381C8075; Fri, 11 Jul 2014 09:47:19 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Fri, 11 Jul 2014 09:47:15 +0200 From: To: Jeffrey Haas , DECRAENE Bruno IMT/OLN Thread-Topic: [Idr] draft-litkowski-idr-flowspec-interfaceset Thread-Index: Ac+cIsw+lgYikyvKQGyocLFGhGsPuAAFsMqAACh+vdA= Date: Fri, 11 Jul 2014 07:47:15 +0000 Message-ID: <28945_1405064839_53BF9687_28945_3786_1_2e54846c-569e-4629-a85d-819fed65b274@OPEXCLILH02.corporate.adroot.infra.ftgroup> References: <8982_1404985714_53BE6172_8982_9424_1_53C29892C857584299CBF5D05346208A07181096@PEXCVZYM11.corporate.adroot.infra.ftgroup> <20140710142205.GT19932@pfrc> In-Reply-To: <20140710142205.GT19932@pfrc> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.10.80319 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/wSON5URH2BrTasE11owVSoAeZUE Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 07:47:24 -0000 Hi Jeff, As I said to Robert offline, the main issue I see with wide comm would be t= he introduced delay of availability of this important use case (I'm talking= about multiple years ... while use case is now ...).=20 Wide comm is not yet a WG doc ... encoding may still change ... I also agree that we are quite short in bit and bytes using an extcomm but = it sounds usable. May be a two step approach can be done : - first standardize using extcomm as for other flowspec actions (we can dis= cuss for sure bits and bytes to optimize the encoding proposal) Then : - review all flowspec actions and see how we can use wide comm to enhance u= sability of them. Thoughts ? Best Regards, Stephane -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Thursday, July 10, 2014 16:22 To: DECRAENE Bruno IMT/OLN Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset Bruno, On Thu, Jul 10, 2014 at 09:48:34AM +0000, bruno.decraene@orange.com wrote: > This would translate into the proposed following additional text: >=20 > 6. IANA Considerations >=20 > The IANA is requested to create and maintain a registry entitled > "Assigned Flow spec interface-set" with the following > registration procedure: >=20 > Registry Name: Assigned Flow spec interface-set >=20 > Range Registration Procedures > ----------- ------------------------- > 0x0000-3EFF Reserved for private use. > 0x3F00-3FFF Standards Action/Early IANA Allocation. >=20 >=20=09=20=20=20 > The IANA is requested to update the registry "Assigned Flow spec interfac= e-set" as follows: >=20 > 0x3F00: IGP interface > 0x3F01: non IGP interface > 0x3F02: eBGP interface > 0x3F03: non eBGP interface > 0x3F04: VRF interface > 0x3F05: non VRF interface As Robert Raszuk had already pointed out off-list, "Why aren't we using wid= e communities for this". :-) I had intended to let the idea for these constraints circulate a bit for pe= ople to get comfortable with it before bringing up wide comms as the policy= mechanism for it. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Jul 11 01:05:21 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7F31B2AA6 for ; Fri, 11 Jul 2014 01:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2A93MUkVL8g for ; Fri, 11 Jul 2014 01:05:15 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473C51B2AA9 for ; Fri, 11 Jul 2014 01:05:15 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id lx4so620098iec.10 for ; Fri, 11 Jul 2014 01:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yumY6ihkVs/ZwbAMRf2M7Cx1kGtcbQSzSz/fTfj4XCU=; b=e45mqUuiQCTQDDGmE//hurnURMgfpxNxwuXVFg+MCw4657S6RRqOSNpCalu3u2sgdR Yd7UCOuzWgxk5IbWtDiyDKaekHZysECJBS9pfBEbK4PEzG/pBKKN7u87Y6wRMxG1KaA4 DLMML465/ulyRbPYvFaCmdjyi56tROyzHTmYQsut5AMTtzVPBg8YvLhgLjbam/HoOcuI WFF2gRz+fwF+XMtLsXUejf3ZH7slHE6UZVSvrI+d7aevBmrslrHQdN9AtM+zH/DmPOVu CzSh3dGnwn85IINP0aOid9lLM1pprCb8bnFDnGV2bIzNjePuNyZa/Hd+rdyCUiXmY8W2 memA== MIME-Version: 1.0 X-Received: by 10.50.136.135 with SMTP id qa7mr2277738igb.21.1405065914611; Fri, 11 Jul 2014 01:05:14 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Fri, 11 Jul 2014 01:05:14 -0700 (PDT) In-Reply-To: <28945_1405064839_53BF9687_28945_3786_1_2e54846c-569e-4629-a85d-819fed65b274@OPEXCLILH02.corporate.adroot.infra.ftgroup> References: <8982_1404985714_53BE6172_8982_9424_1_53C29892C857584299CBF5D05346208A07181096@PEXCVZYM11.corporate.adroot.infra.ftgroup> <20140710142205.GT19932@pfrc> <28945_1405064839_53BF9687_28945_3786_1_2e54846c-569e-4629-a85d-819fed65b274@OPEXCLILH02.corporate.adroot.infra.ftgroup> Date: Fri, 11 Jul 2014 10:05:14 +0200 X-Google-Sender-Auth: ZbXRVe_SBOfrVd20xr9vx0dyRZM Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=089e0149c10cb9fd6304fde66639 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/7kALHDfKoCcbfx4EUHxNiftsD_w Cc: DECRAENE Bruno IMT/OLN , idr wg Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 08:05:17 -0000 --089e0149c10cb9fd6304fde66639 Content-Type: text/plain; charset=UTF-8 Stephane, I am not sure why you would not be fine for now with use of regular community for such group coloring ? Do you really need to define new extended community which results in need for implementations in various code bases ? RFC 5575 already addresses this today by paragraph: Implementations should provide mechanisms that map an arbitraryBGP community value (normal or extended) to filtering actions that require different mappings in different systems in the network. - - - As to the draft I think you really meant "AND" not "OR" :) Multiple instances of the community in a BGP update MUST be interpreted as a "OR" operation : if a BGP update contains two interface-set communities with group ID 1 and group ID 2, the filter would need to be installed on interfaces belonging to Group ID 1 or Group ID 2. Otherwise if you meant "OR" you need to elaborate which one out of the two. Best, R. On Fri, Jul 11, 2014 at 9:47 AM, wrote: > Hi Jeff, > > As I said to Robert offline, the main issue I see with wide comm would be > the introduced delay of availability of this important use case (I'm > talking about multiple years ... while use case is now ...). > Wide comm is not yet a WG doc ... encoding may still change ... > > I also agree that we are quite short in bit and bytes using an extcomm but > it sounds usable. > > May be a two step approach can be done : > - first standardize using extcomm as for other flowspec actions (we can > discuss for sure bits and bytes to optimize the encoding proposal) > > Then : > - review all flowspec actions and see how we can use wide comm to enhance > usability of them. > > Thoughts ? > > Best Regards, > > Stephane > > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Thursday, July 10, 2014 16:22 > To: DECRAENE Bruno IMT/OLN > Cc: idr wg > Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset > > Bruno, > > On Thu, Jul 10, 2014 at 09:48:34AM +0000, bruno.decraene@orange.com wrote: > > This would translate into the proposed following additional text: > > > > 6. IANA Considerations > > > > The IANA is requested to create and maintain a registry entitled > > "Assigned Flow spec interface-set" with the following > > registration procedure: > > > > Registry Name: Assigned Flow spec interface-set > > > > Range Registration Procedures > > ----------- ------------------------- > > 0x0000-3EFF Reserved for private use. > > 0x3F00-3FFF Standards Action/Early IANA Allocation. > > > > > > The IANA is requested to update the registry "Assigned Flow spec > interface-set" as follows: > > > > 0x3F00: IGP interface > > 0x3F01: non IGP interface > > 0x3F02: eBGP interface > > 0x3F03: non eBGP interface > > 0x3F04: VRF interface > > 0x3F05: non VRF interface > > As Robert Raszuk had already pointed out off-list, "Why aren't we using > wide communities for this". :-) > > I had intended to let the idea for these constraints circulate a bit for > people to get comfortable with it before bringing up wide comms as the > policy mechanism for it. > > > -- Jeff > > _______________________________________________ > 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 > --089e0149c10cb9fd6304fde66639 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephane,

I am not sure why you would not be fine for n= ow with use of regular community for such group coloring ?=C2=A0

Do you really need to define new extended= community which results in need for implementations in various code bases = ?=C2=A0

RFC 5575 already = addresses this today by paragraph:

Implementations should provide mechanisms that map an arbitraryBGP communit=
y value (normal or extended) to filtering actions that require different ma=
ppings in different systems in the network.

- - -=C2=A0
=
As to the draft I think you really meant "AND&= quot; not "OR" :)

Multiple instances of the =
community in a BGP update MUST be
interpreted as a "OR" operation : if a BGP update contains two
interface-set communities with group ID 1 and group ID 2, the filter would =
need to be installed on interfaces belonging to Group ID 1 or Group ID 2.


Otherwise if you meant "OR" you need to elaborate =
which one out of the two.

Best,
R.



On Fri, Jul 11, 2014 at 9:47 AM, <stephane.litkowski@orang= e.com> wrote:
Hi Jeff,

As I said to Robert offline, the main issue I see with wide comm would be t= he introduced delay of availability of this important use case (I'm tal= king about multiple years ... while use case is now ...).
Wide comm is not yet a WG doc ... encoding may still change ...

I also agree that we are quite short in bit and bytes using an extcomm but = it sounds usable.

May be a two step approach can be done :
- first standardize using extcomm as for other flowspec actions (we can dis= cuss for sure bits and bytes to optimize the encoding proposal)

Then :
- review all flowspec actions and see how we can use wide comm to enhance u= sability of them.

Thoughts ?

Best Regards,

Stephane


-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.= org] On Behalf Of Jeffrey Haas
Sent: Thursday, July 10, 2014 16:22
To: DECRAENE Bruno IMT/OLN
Cc: idr wg
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset

Bruno,

On Thu, Jul 10, 2014 at 09:48:34AM +0000, bruno.decraene@orange.com wrote:
> This would translate into the proposed following additional text:
>
> 6. IANA Considerations
>
> The IANA is requested to create and maintain a registry entitled
> =C2=A0 =C2=A0"Assigned Flow spec interface-set" with the fol= lowing
> =C2=A0 =C2=A0registration procedure:
>
> =C2=A0 =C2=A0 Registry Name: Assigned Flow spec interface-set
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Range =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Registration Procedures
> =C2=A0 =C2=A0 =C2=A0 =C2=A0----------- =C2=A0 =C2=A0 =C2=A0 =C2=A0----= ---------------------
> =C2=A0 =C2=A0 =C2=A0 =C2=A00x0000-3EFF =C2=A0 =C2=A0 =C2=A0 =C2=A0Rese= rved for private use.
> =C2=A0 =C2=A0 =C2=A0 =C2=A00x3F00-3FFF =C2=A0 =C2=A0 =C2=A0 =C2=A0Stan= dards Action/Early IANA Allocation.
>
>
> The IANA is requested to update the registry "Assigned Flow spec = interface-set" as follows:
>
> 0x3F00: IGP interface
> 0x3F01: non IGP interface
> 0x3F02: eBGP interface
> 0x3F03: non eBGP interface
> 0x3F04: VRF interface
> 0x3F05: non VRF interface

As Robert Raszuk had already pointed out off-list, "Why aren't we = using wide communities for this". =C2=A0:-)

I had intended to let the idea for these constraints circulate a bit for pe= ople to get comfortable with it before bringing up wide comms as the policy= mechanism for it.


-- Jeff

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

______________________________________= ___________________________________________________________________________= ________

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

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

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

--089e0149c10cb9fd6304fde66639-- From nobody Fri Jul 11 02:02:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957CE1B2ABD for ; Fri, 11 Jul 2014 02:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HrFsIFi9VWx for ; Fri, 11 Jul 2014 02:01:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0457B1A0B17 for ; Fri, 11 Jul 2014 02:01:50 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 4579A264106; Fri, 11 Jul 2014 11:01:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1FD0E238056; Fri, 11 Jul 2014 11:01:48 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Fri, 11 Jul 2014 11:01:46 +0200 From: To: Robert Raszuk Thread-Topic: [Idr] draft-litkowski-idr-flowspec-interfaceset Thread-Index: Ac+cIsw+lgYikyvKQGyocLFGhGsPuAAFsMqAACh+vdD//+UUAP//0VSg Date: Fri, 11 Jul 2014 09:01:46 +0000 Message-ID: <22117_1405069308_53BFA7FC_22117_2979_13_ccb3e888-1639-42a5-bfa5-30e5bf83edc9@OPEXCLILH02.corporate.adroot.infra.ftgroup> References: <8982_1404985714_53BE6172_8982_9424_1_53C29892C857584299CBF5D05346208A07181096@PEXCVZYM11.corporate.adroot.infra.ftgroup> <20140710142205.GT19932@pfrc> <28945_1405064839_53BF9687_28945_3786_1_2e54846c-569e-4629-a85d-819fed65b274@OPEXCLILH02.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_ccb3e888163942a5bfa530e5bf83edc9OPEXCLILH02corporateadr_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.11.70019 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/nf3yifl_1RSugQZqlHMuM_bcDxA Cc: DECRAENE Bruno IMT/OLN , idr wg Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 09:01:59 -0000 --_000_ccb3e888163942a5bfa530e5bf83edc9OPEXCLILH02corporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpXZSBuZWVkIHRvIGhhdmUgYSB3YXkgdG8gZW5jb2RlIHRoZSBkaXJlY3Rp b24gb2YgdGhlIGZpbHRlciwgc28gdGhpcyBwYXJ0IHNob3VsZCBiZSByZWdpc3RlcmVkIGFuZCBz dGFuZGFyZGl6ZWQgZm9yIGludGVyb3BlcmFiaWxpdHkgcHVycG9zZS4gTW9yZW92ZXIgd2Ugd2Fu dCBzb21ldGhpbmcgY29tcGxldGVseSBhdXRvbWF0ZWQgd2l0aG91dCBoYXZpbmcgdG8gY29uZmln dXJlIHBvbGljaWVzIG9uIGVhY2ggbm9kZSBkZXNjcmliaW5nIG1hcHBpbmcgYmV0d2VlbiBjb21t dW5pdHkgdmFsdWVzIGFuZCBmaWx0ZXIgcGFyYW1ldGVycyAoZGlyZWN0aW9uKS4NCg0KUmVnYXJk aW5nIOKAnEFOROKAnS/igJ1PUuKAnSwgdGhlIGlkZWEgaXMgdGhhdCBpZiBOTFJJIGhhcyBHcm91 cElEMSBhbmQgR3JvdXBJRDIgYXR0YWNoZWQuIEl0IG5lZWQgdG8gYmUgY29uc2lkZXJlZCBhcyBh IOKAnG1hdGNoLWFueeKAnSwgc28gaXQgd2lsbCBiZSBhcHBsaWVkIHRvIGludGVyZmFjZXMgYmVs b25naW5nIHRvIEdyb3VwSUQxIGFuZCBpbnRlcmZhY2VzIGJlbG9uZ2luZyB0byBHcm91cElEMi4N CkZvciBtZSDigJxBTkTigJ0gd291bGQgYmUgbW9yZSBhIOKAnG1hdGNoIGFsbOKAnSwgc2F5aW5n IHRoYXQgdGhlIGZpbHRlciB3b3VsZCBiZSBhcHBsaWVkIG9uIGludGVyZmFjZXMgdGhhdCBhcmUg YmVsb25naW5nIG9ubHkgdG8gYm90aCBncm91cHMgYXQgdGhlIHNhbWUgdGltZS4NCldlIGNhbiBy ZXBocmFzZSBpbiBuZXh0IHZlcnNpb24uDQoNCg0KVGhhbmtzLA0KDQpTdGVwaGFuZQ0KDQoNCkZy b206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFs ZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTA6MDUNClRv OiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYNCkNjOiBKZWZmcmV5IEhhYXM7IERFQ1JBRU5F IEJydW5vIElNVC9PTE47IGlkciB3Zw0KU3ViamVjdDogUmU6IFtJZHJdIGRyYWZ0LWxpdGtvd3Nr aS1pZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0DQoNClN0ZXBoYW5lLA0KDQpJIGFtIG5vdCBzdXJl IHdoeSB5b3Ugd291bGQgbm90IGJlIGZpbmUgZm9yIG5vdyB3aXRoIHVzZSBvZiByZWd1bGFyIGNv bW11bml0eSBmb3Igc3VjaCBncm91cCBjb2xvcmluZyA/DQoNCkRvIHlvdSByZWFsbHkgbmVlZCB0 byBkZWZpbmUgbmV3IGV4dGVuZGVkIGNvbW11bml0eSB3aGljaCByZXN1bHRzIGluIG5lZWQgZm9y IGltcGxlbWVudGF0aW9ucyBpbiB2YXJpb3VzIGNvZGUgYmFzZXMgPw0KDQpSRkMgNTU3NSBhbHJl YWR5IGFkZHJlc3NlcyB0aGlzIHRvZGF5IGJ5IHBhcmFncmFwaDoNCg0KDQoNCg0KSW1wbGVtZW50 YXRpb25zIHNob3VsZCBwcm92aWRlIG1lY2hhbmlzbXMgdGhhdCBtYXAgYW4gYXJiaXRyYXJ5QkdQ IGNvbW11bml0eSB2YWx1ZSAobm9ybWFsIG9yIGV4dGVuZGVkKSB0byBmaWx0ZXJpbmcgYWN0aW9u cyB0aGF0IHJlcXVpcmUgZGlmZmVyZW50IG1hcHBpbmdzIGluIGRpZmZlcmVudCBzeXN0ZW1zIGlu IHRoZSBuZXR3b3JrLg0KDQotIC0gLQ0KDQpBcyB0byB0aGUgZHJhZnQgSSB0aGluayB5b3UgcmVh bGx5IG1lYW50ICJBTkQiIG5vdCAiT1IiIDopDQoNCg0KTXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRo ZSBjb21tdW5pdHkgaW4gYSBCR1AgdXBkYXRlIE1VU1QgYmUNCg0KaW50ZXJwcmV0ZWQgYXMgYSAi T1IiIG9wZXJhdGlvbiA6IGlmIGEgQkdQIHVwZGF0ZSBjb250YWlucyB0d28NCg0KaW50ZXJmYWNl LXNldCBjb21tdW5pdGllcyB3aXRoIGdyb3VwIElEIDEgYW5kIGdyb3VwIElEIDIsIHRoZSBmaWx0 ZXIgd291bGQgbmVlZCB0byBiZSBpbnN0YWxsZWQgb24gaW50ZXJmYWNlcyBiZWxvbmdpbmcgdG8g R3JvdXAgSUQgMSBvciBHcm91cCBJRCAyLg0KDQoNCg0KDQoNCg0KDQpPdGhlcndpc2UgaWYgeW91 IG1lYW50ICJPUiIgeW91IG5lZWQgdG8gZWxhYm9yYXRlIHdoaWNoIG9uZSBvdXQgb2YgdGhlIHR3 by4NCg0KDQoNCkJlc3QsDQpSLg0KDQoNCk9uIEZyaSwgSnVsIDExLCAyMDE0IGF0IDk6NDcgQU0s IDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tp QG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIEplZmYsDQoNCkFzIEkgc2FpZCB0byBSb2JlcnQgb2Zm bGluZSwgdGhlIG1haW4gaXNzdWUgSSBzZWUgd2l0aCB3aWRlIGNvbW0gd291bGQgYmUgdGhlIGlu dHJvZHVjZWQgZGVsYXkgb2YgYXZhaWxhYmlsaXR5IG9mIHRoaXMgaW1wb3J0YW50IHVzZSBjYXNl IChJJ20gdGFsa2luZyBhYm91dCBtdWx0aXBsZSB5ZWFycyAuLi4gd2hpbGUgdXNlIGNhc2UgaXMg bm93IC4uLikuDQpXaWRlIGNvbW0gaXMgbm90IHlldCBhIFdHIGRvYyAuLi4gZW5jb2RpbmcgbWF5 IHN0aWxsIGNoYW5nZSAuLi4NCg0KSSBhbHNvIGFncmVlIHRoYXQgd2UgYXJlIHF1aXRlIHNob3J0 IGluIGJpdCBhbmQgYnl0ZXMgdXNpbmcgYW4gZXh0Y29tbSBidXQgaXQgc291bmRzIHVzYWJsZS4N Cg0KTWF5IGJlIGEgdHdvIHN0ZXAgYXBwcm9hY2ggY2FuIGJlIGRvbmUgOg0KLSBmaXJzdCBzdGFu ZGFyZGl6ZSB1c2luZyBleHRjb21tIGFzIGZvciBvdGhlciBmbG93c3BlYyBhY3Rpb25zICh3ZSBj YW4gZGlzY3VzcyBmb3Igc3VyZSBiaXRzIGFuZCBieXRlcyB0byBvcHRpbWl6ZSB0aGUgZW5jb2Rp bmcgcHJvcG9zYWwpDQoNClRoZW4gOg0KLSByZXZpZXcgYWxsIGZsb3dzcGVjIGFjdGlvbnMgYW5k IHNlZSBob3cgd2UgY2FuIHVzZSB3aWRlIGNvbW0gdG8gZW5oYW5jZSB1c2FiaWxpdHkgb2YgdGhl bS4NCg0KVGhvdWdodHMgPw0KDQpCZXN0IFJlZ2FyZHMsDQoNClN0ZXBoYW5lDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKZWZmcmV5IEhh YXMNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDE2OjIyDQpUbzogREVDUkFFTkUgQnJ1 bm8gSU1UL09MTg0KQ2M6IGlkciB3Zw0KU3ViamVjdDogUmU6IFtJZHJdIGRyYWZ0LWxpdGtvd3Nr aS1pZHItZmxvd3NwZWMtaW50ZXJmYWNlc2V0DQoNCkJydW5vLA0KDQpPbiBUaHUsIEp1bCAxMCwg MjAxNCBhdCAwOTo0ODozNEFNICswMDAwLCBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0 bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPiB3cm90ZToNCj4gVGhpcyB3b3VsZCB0cmFuc2xh dGUgaW50byB0aGUgcHJvcG9zZWQgZm9sbG93aW5nIGFkZGl0aW9uYWwgdGV4dDoNCj4NCj4gNi4g SUFOQSBDb25zaWRlcmF0aW9ucw0KPg0KPiBUaGUgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gY3JlYXRl IGFuZCBtYWludGFpbiBhIHJlZ2lzdHJ5IGVudGl0bGVkDQo+ICAgICJBc3NpZ25lZCBGbG93IHNw ZWMgaW50ZXJmYWNlLXNldCIgd2l0aCB0aGUgZm9sbG93aW5nDQo+ICAgIHJlZ2lzdHJhdGlvbiBw cm9jZWR1cmU6DQo+DQo+ICAgICBSZWdpc3RyeSBOYW1lOiBBc3NpZ25lZCBGbG93IHNwZWMgaW50 ZXJmYWNlLXNldA0KPg0KPiAgICAgICAgUmFuZ2UgICAgICAgICAgICAgIFJlZ2lzdHJhdGlvbiBQ cm9jZWR1cmVzDQo+ICAgICAgICAtLS0tLS0tLS0tLSAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAgICAgICAgMHgwMDAwLTNFRkYgICAgICAgIFJlc2VydmVkIGZvciBwcml2YXRl IHVzZS4NCj4gICAgICAgIDB4M0YwMC0zRkZGICAgICAgICBTdGFuZGFyZHMgQWN0aW9uL0Vhcmx5 IElBTkEgQWxsb2NhdGlvbi4NCj4NCj4NCj4gVGhlIElBTkEgaXMgcmVxdWVzdGVkIHRvIHVwZGF0 ZSB0aGUgcmVnaXN0cnkgIkFzc2lnbmVkIEZsb3cgc3BlYyBpbnRlcmZhY2Utc2V0IiBhcyBmb2xs b3dzOg0KPg0KPiAweDNGMDA6IElHUCBpbnRlcmZhY2UNCj4gMHgzRjAxOiBub24gSUdQIGludGVy ZmFjZQ0KPiAweDNGMDI6IGVCR1AgaW50ZXJmYWNlDQo+IDB4M0YwMzogbm9uIGVCR1AgaW50ZXJm YWNlDQo+IDB4M0YwNDogVlJGIGludGVyZmFjZQ0KPiAweDNGMDU6IG5vbiBWUkYgaW50ZXJmYWNl DQoNCkFzIFJvYmVydCBSYXN6dWsgaGFkIGFscmVhZHkgcG9pbnRlZCBvdXQgb2ZmLWxpc3QsICJX aHkgYXJlbid0IHdlIHVzaW5nIHdpZGUgY29tbXVuaXRpZXMgZm9yIHRoaXMiLiAgOi0pDQoNCkkg aGFkIGludGVuZGVkIHRvIGxldCB0aGUgaWRlYSBmb3IgdGhlc2UgY29uc3RyYWludHMgY2lyY3Vs YXRlIGEgYml0IGZvciBwZW9wbGUgdG8gZ2V0IGNvbWZvcnRhYmxlIHdpdGggaXQgYmVmb3JlIGJy aW5naW5nIHVwIHdpZGUgY29tbXMgYXMgdGhlIHBvbGljeSBtZWNoYW5pc20gZm9yIGl0Lg0KDQoN Ci0tIEplZmYNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j DQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv bi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz aWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuDQpUaGFuayB5b3UuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnPG1haWx0bzpJZHJAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk LgpUaGFuayB5b3UuCgo= --_000_ccb3e888163942a5bfa530e5bf83edc9OPEXCLILH02corporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I aSBSb2JlcnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5XZSBuZWVkIHRvIGhhdmUgYSB3YXkgdG8gZW5jb2RlIHRoZSBk aXJlY3Rpb24gb2YgdGhlIGZpbHRlciwgc28gdGhpcyBwYXJ0IHNob3VsZCBiZSByZWdpc3RlcmVk IGFuZCBzdGFuZGFyZGl6ZWQgZm9yIGludGVyb3BlcmFiaWxpdHkgcHVycG9zZS4gTW9yZW92ZXIg d2Ugd2FudA0KIHNvbWV0aGluZyBjb21wbGV0ZWx5IGF1dG9tYXRlZCB3aXRob3V0IGhhdmluZyB0 byBjb25maWd1cmUgcG9saWNpZXMgb24gZWFjaCBub2RlIGRlc2NyaWJpbmcgbWFwcGluZyBiZXR3 ZWVuIGNvbW11bml0eSB2YWx1ZXMgYW5kIGZpbHRlciBwYXJhbWV0ZXJzIChkaXJlY3Rpb24pLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+UmVnYXJkaW5nIOKAnEFOROKAnS/igJ1PUuKAnSwgdGhlIGlkZWEgaXMgdGhhdCBp ZiBOTFJJIGhhcyBHcm91cElEMSBhbmQgR3JvdXBJRDIgYXR0YWNoZWQuIEl0IG5lZWQgdG8gYmUg Y29uc2lkZXJlZCBhcyBhIOKAnG1hdGNoLWFueeKAnSwgc28gaXQgd2lsbCBiZSBhcHBsaWVkIHRv IGludGVyZmFjZXMNCiBiZWxvbmdpbmcgdG8gR3JvdXBJRDEgYW5kIGludGVyZmFjZXMgYmVsb25n aW5nIHRvIEdyb3VwSUQyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgbWUg4oCc QU5E4oCdIHdvdWxkIGJlIG1vcmUgYSDigJxtYXRjaCBhbGzigJ0sIHNheWluZyB0aGF0IHRoZSBm aWx0ZXIgd291bGQgYmUgYXBwbGllZCBvbiBpbnRlcmZhY2VzIHRoYXQgYXJlIGJlbG9uZ2luZyBv bmx5IHRvIGJvdGggZ3JvdXBzIGF0IHRoZSBzYW1lIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPldlIGNhbiByZXBocmFzZSBpbiBuZXh0IHZlcnNpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3RlcGhh bmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6 dWtAZ21haWwuY29tXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMDowNTxicj4NCjxiPlRvOjwvYj4gTElU S09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GPGJyPg0KPGI+Q2M6PC9iPiBKZWZmcmV5IEhhYXM7IERF Q1JBRU5FIEJydW5vIElNVC9PTE47IGlkciB3Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lk cl0gZHJhZnQtbGl0a293c2tpLWlkci1mbG93c3BlYy1pbnRlcmZhY2VzZXQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdGVwaGFuZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBhbSBub3Qgc3VyZSB3aHkgeW91IHdv dWxkIG5vdCBiZSBmaW5lIGZvciBub3cgd2l0aCB1c2Ugb2YgcmVndWxhciBjb21tdW5pdHkgZm9y IHN1Y2ggZ3JvdXAgY29sb3JpbmcgPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EbyB5b3UgcmVhbGx5IG5lZWQgdG8gZGVmaW5lIG5l dyBleHRlbmRlZCBjb21tdW5pdHkgd2hpY2ggcmVzdWx0cyBpbiBuZWVkIGZvciBpbXBsZW1lbnRh dGlvbnMgaW4gdmFyaW91cyBjb2RlIGJhc2VzID8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UkZDIDU1NzUgYWxyZWFkeSBhZGRyZXNz ZXMgdGhpcyB0b2RheSBieSBwYXJhZ3JhcGg6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkltcGxlbWVudGF0aW9ucyBzaG91bGQgcHJvdmlkZSBt ZWNoYW5pc21zIHRoYXQgbWFwIGFuIGFyYml0cmFyeUJHUCBjb21tdW5pdHkgdmFsdWUgKG5vcm1h bCBvciBleHRlbmRlZCkgdG8gZmlsdGVyaW5nIGFjdGlvbnMgdGhhdCByZXF1aXJlIGRpZmZlcmVu dCBtYXBwaW5ncyBpbiBkaWZmZXJlbnQgc3lzdGVtcyBpbiB0aGUgbmV0d29yay48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIC0gLSZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5B cyB0byB0aGUgZHJhZnQgSSB0aGluayB5b3UgcmVhbGx5IG1lYW50ICZxdW90O0FORCZxdW90OyBu b3QgJnF1b3Q7T1ImcXVvdDsgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk11bHRp cGxlIGluc3RhbmNlcyBvZiB0aGUgY29tbXVuaXR5IGluIGEgQkdQIHVwZGF0ZSBNVVNUIGJlPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5pbnRlcnByZXRlZCBhcyBhICZxdW90O09SJnF1b3Q7IG9wZXJhdGlvbiA6 IGlmIGEgQkdQIHVwZGF0ZSBjb250YWlucyB0d288bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPmludGVyZmFjZS1z ZXQgY29tbXVuaXRpZXMgd2l0aCBncm91cCBJRCAxIGFuZCBncm91cCBJRCAyLCB0aGUgZmlsdGVy IHdvdWxkIG5lZWQgdG8gYmUgaW5zdGFsbGVkIG9uIGludGVyZmFjZXMgYmVsb25naW5nIHRvIEdy b3VwIElEIDEgb3IgR3JvdXAgSUQgMi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzIyMjIyMiI+T3Ro ZXJ3aXNlIGlmIHlvdSBtZWFudCAmcXVvdDtPUiZxdW90OyB5b3UgbmVlZCB0byBlbGFib3JhdGUg d2hpY2ggb25lIG91dCBvZiB0aGUgdHdvLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CZXN0LDxicj4N ClIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdWwgMTEsIDIw MTQgYXQgOTo0NyBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3Jh bmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBKZWZm LDxicj4NCjxicj4NCkFzIEkgc2FpZCB0byBSb2JlcnQgb2ZmbGluZSwgdGhlIG1haW4gaXNzdWUg SSBzZWUgd2l0aCB3aWRlIGNvbW0gd291bGQgYmUgdGhlIGludHJvZHVjZWQgZGVsYXkgb2YgYXZh aWxhYmlsaXR5IG9mIHRoaXMgaW1wb3J0YW50IHVzZSBjYXNlIChJJ20gdGFsa2luZyBhYm91dCBt dWx0aXBsZSB5ZWFycyAuLi4gd2hpbGUgdXNlIGNhc2UgaXMgbm93IC4uLikuPGJyPg0KV2lkZSBj b21tIGlzIG5vdCB5ZXQgYSBXRyBkb2MgLi4uIGVuY29kaW5nIG1heSBzdGlsbCBjaGFuZ2UgLi4u PGJyPg0KPGJyPg0KSSBhbHNvIGFncmVlIHRoYXQgd2UgYXJlIHF1aXRlIHNob3J0IGluIGJpdCBh bmQgYnl0ZXMgdXNpbmcgYW4gZXh0Y29tbSBidXQgaXQgc291bmRzIHVzYWJsZS48YnI+DQo8YnI+ DQpNYXkgYmUgYSB0d28gc3RlcCBhcHByb2FjaCBjYW4gYmUgZG9uZSA6PGJyPg0KLSBmaXJzdCBz dGFuZGFyZGl6ZSB1c2luZyBleHRjb21tIGFzIGZvciBvdGhlciBmbG93c3BlYyBhY3Rpb25zICh3 ZSBjYW4gZGlzY3VzcyBmb3Igc3VyZSBiaXRzIGFuZCBieXRlcyB0byBvcHRpbWl6ZSB0aGUgZW5j b2RpbmcgcHJvcG9zYWwpPGJyPg0KPGJyPg0KVGhlbiA6PGJyPg0KLSByZXZpZXcgYWxsIGZsb3dz cGVjIGFjdGlvbnMgYW5kIHNlZSBob3cgd2UgY2FuIHVzZSB3aWRlIGNvbW0gdG8gZW5oYW5jZSB1 c2FiaWxpdHkgb2YgdGhlbS48YnI+DQo8YnI+DQpUaG91Z2h0cyA/PGJyPg0KPGJyPg0KQmVzdCBS ZWdhcmRzLDxicj4NCjxicj4NClN0ZXBoYW5lPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBJZHIgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmciPmlkci1ib3VuY2VzQGlldGYub3Jn PC9hPl0gT24gQmVoYWxmIE9mIEplZmZyZXkgSGFhczxicj4NClNlbnQ6IFRodXJzZGF5LCBKdWx5 IDEwLCAyMDE0IDE2OjIyPGJyPg0KVG86IERFQ1JBRU5FIEJydW5vIElNVC9PTE48YnI+DQpDYzog aWRyIHdnPGJyPg0KU3ViamVjdDogUmU6IFtJZHJdIGRyYWZ0LWxpdGtvd3NraS1pZHItZmxvd3Nw ZWMtaW50ZXJmYWNlc2V0PGJyPg0KPGJyPg0KQnJ1bm8sPGJyPg0KPGJyPg0KT24gVGh1LCBKdWwg MTAsIDIwMTQgYXQgMDk6NDg6MzRBTSAmIzQzOzAwMDAsIDxhIGhyZWY9Im1haWx0bzpicnVuby5k ZWNyYWVuZUBvcmFuZ2UuY29tIj4NCmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+IHdyb3Rl Ojxicj4NCiZndDsgVGhpcyB3b3VsZCB0cmFuc2xhdGUgaW50byB0aGUgcHJvcG9zZWQgZm9sbG93 aW5nIGFkZGl0aW9uYWwgdGV4dDo8YnI+DQomZ3Q7PGJyPg0KJmd0OyA2LiBJQU5BIENvbnNpZGVy YXRpb25zPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIElBTkEgaXMgcmVxdWVzdGVkIHRvIGNyZWF0 ZSBhbmQgbWFpbnRhaW4gYSByZWdpc3RyeSBlbnRpdGxlZDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyZxdW90O0Fzc2lnbmVkIEZsb3cgc3BlYyBpbnRlcmZhY2Utc2V0JnF1b3Q7IHdpdGggdGhlIGZv bGxvd2luZzxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3JlZ2lzdHJhdGlvbiBwcm9jZWR1cmU6PGJy Pg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBSZWdpc3RyeSBOYW1lOiBBc3NpZ25lZCBG bG93IHNwZWMgaW50ZXJmYWNlLXNldDxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1JhbmdlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1JlZ2lzdHJhdGlvbiBQcm9jZWR1cmVzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDstLS0tLS0tLS0tLSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsweDAwMDAtM0VGRiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSZXNlcnZlZCBmb3IgcHJp dmF0ZSB1c2UuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsweDNGMDAtM0ZG RiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTdGFuZGFyZHMgQWN0aW9uL0Vhcmx5IElBTkEg QWxsb2NhdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIElBTkEgaXMgcmVx dWVzdGVkIHRvIHVwZGF0ZSB0aGUgcmVnaXN0cnkgJnF1b3Q7QXNzaWduZWQgRmxvdyBzcGVjIGlu dGVyZmFjZS1zZXQmcXVvdDsgYXMgZm9sbG93czo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAweDNGMDA6 IElHUCBpbnRlcmZhY2U8YnI+DQomZ3Q7IDB4M0YwMTogbm9uIElHUCBpbnRlcmZhY2U8YnI+DQom Z3Q7IDB4M0YwMjogZUJHUCBpbnRlcmZhY2U8YnI+DQomZ3Q7IDB4M0YwMzogbm9uIGVCR1AgaW50 ZXJmYWNlPGJyPg0KJmd0OyAweDNGMDQ6IFZSRiBpbnRlcmZhY2U8YnI+DQomZ3Q7IDB4M0YwNTog bm9uIFZSRiBpbnRlcmZhY2U8YnI+DQo8YnI+DQpBcyBSb2JlcnQgUmFzenVrIGhhZCBhbHJlYWR5 IHBvaW50ZWQgb3V0IG9mZi1saXN0LCAmcXVvdDtXaHkgYXJlbid0IHdlIHVzaW5nIHdpZGUgY29t bXVuaXRpZXMgZm9yIHRoaXMmcXVvdDsuICZuYnNwOzotKTxicj4NCjxicj4NCkkgaGFkIGludGVu ZGVkIHRvIGxldCB0aGUgaWRlYSBmb3IgdGhlc2UgY29uc3RyYWludHMgY2lyY3VsYXRlIGEgYml0 IGZvciBwZW9wbGUgdG8gZ2V0IGNvbWZvcnRhYmxlIHdpdGggaXQgYmVmb3JlIGJyaW5naW5nIHVw IHdpZGUgY29tbXMgYXMgdGhlIHBvbGljeSBtZWNoYW5pc20gZm9yIGl0Ljxicj4NCjxicj4NCjxi cj4NCi0tIEplZmY8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCklkciBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 SWRyQGlldGYub3JnIj5JZHJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPGJyPg0KcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8YnI+DQphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxi cj4NCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48YnI+DQo8YnI+DQpUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ozxicj4NCnRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLjxicj4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC48YnI+DQpUaGFuayB5b3UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpJZHIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOklkckBpZXRmLm9yZyI+SWRyQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHI8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BS RT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_ccb3e888163942a5bfa530e5bf83edc9OPEXCLILH02corporateadr_-- From nobody Fri Jul 11 02:34:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B211B2AE2 for ; Fri, 11 Jul 2014 02:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vt-km4aKK08 for ; Fri, 11 Jul 2014 02:34:19 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481731B2ADE for ; Fri, 11 Jul 2014 02:34:19 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id x19so683396ier.34 for ; Fri, 11 Jul 2014 02:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jjByv+56s3EcET1Owu1DE3eynxAW/fHL+tkJiFXu+DE=; b=KdUs9x3qoK3xV2POQTZABWWk/aLnSLoAJ1m9pPd4YI/ESDMXLPZN5Dp3yyWReCQTfG E/25o5HbsTzVJvfgpKKrgmIwk8jd4DquP+0nBRBslRKTI6IQrCLGziXZZJMGDPIOKKXv pVERsXBT+/0kcG3Yq3oEavanlMXUg4Ax49VRPP+aHErlCYub96ic8UMqQnSVy5kqc/1E UCvBF0M1oJVXfDGhGbSBk3nnFaX0y+dKdXbc4eVPoMCHt3i1DWKqNZo2IQPsKQjZk89o VNJTiTIdslSnmApSSlxKOUv/l4G/tCqBJ5tB8VXx8p1M9CQ4iidBkybiAVKMFljuQlHk Jiew== MIME-Version: 1.0 X-Received: by 10.50.12.38 with SMTP id v6mr2774184igb.29.1405071258549; Fri, 11 Jul 2014 02:34:18 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Fri, 11 Jul 2014 02:34:18 -0700 (PDT) Received: by 10.64.89.38 with HTTP; Fri, 11 Jul 2014 02:34:18 -0700 (PDT) In-Reply-To: <22117_1405069308_53BFA7FC_22117_2979_13_ccb3e888-1639-42a5-bfa5-30e5bf83edc9@OPEXCLILH02.corporate.adroot.infra.ftgroup> References: <8982_1404985714_53BE6172_8982_9424_1_53C29892C857584299CBF5D05346208A07181096@PEXCVZYM11.corporate.adroot.infra.ftgroup> <20140710142205.GT19932@pfrc> <28945_1405064839_53BF9687_28945_3786_1_2e54846c-569e-4629-a85d-819fed65b274@OPEXCLILH02.corporate.adroot.infra.ftgroup> <22117_1405069308_53BFA7FC_22117_2979_13_ccb3e888-1639-42a5-bfa5-30e5bf83edc9@OPEXCLILH02.corporate.adroot.infra.ftgroup> Date: Fri, 11 Jul 2014 11:34:18 +0200 X-Google-Sender-Auth: RiKqHSzC-fMlOeFGtsDXt4aNjTI Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=089e0112c39c40047704fde7a50f Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_UAfhkX0XktejoPWRZALdV-yr-w Cc: idr wg , bruno.decraene@orange.com Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 09:34:22 -0000 --089e0112c39c40047704fde7a50f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Well ... direction can also be specified using regular communities ;) You just need x2.... Cheers, R. On Jul 11, 2014 11:02 AM, wrote: > Hi Robert, > > > > We need to have a way to encode the direction of the filter, so this part > should be registered and standardized for interoperability purpose. > Moreover we want something completely automated without having to configu= re > policies on each node describing mapping between community values and > filter parameters (direction). > > > > Regarding =E2=80=9CAND=E2=80=9D/=E2=80=9DOR=E2=80=9D, the idea is that if= NLRI has GroupID1 and GroupID2 > attached. It need to be considered as a =E2=80=9Cmatch-any=E2=80=9D, so i= t will be applied > to interfaces belonging to GroupID1 and interfaces belonging to GroupID2. > > For me =E2=80=9CAND=E2=80=9D would be more a =E2=80=9Cmatch all=E2=80=9D,= saying that the filter would be > applied on interfaces that are belonging only to both groups at the same > time. > > We can rephrase in next version. > > > > > > Thanks, > > > > Stephane > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Friday, July 11, 2014 10:05 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* Jeffrey Haas; DECRAENE Bruno IMT/OLN; idr wg > *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset > > > > Stephane, > > > > I am not sure why you would not be fine for now with use of regular > community for such group coloring ? > > > > Do you really need to define new extended community which results in need > for implementations in various code bases ? > > > > RFC 5575 already addresses this today by paragraph: > > > > > > Implementations should provide mechanisms that map an arbitraryBGP commun= ity value (normal or extended) to filtering actions that require different = mappings in different systems in the network. > > > > - - - > > > > As to the draft I think you really meant "AND" not "OR" :) > > > > Multiple instances of the community in a BGP update MUST be > > interpreted as a "OR" operation : if a BGP update contains two > > interface-set communities with group ID 1 and group ID 2, the filter woul= d need to be installed on interfaces belonging to Group ID 1 or Group ID 2. > > > > > > > > Otherwise if you meant "OR" you need to elaborate which one out of the tw= o. > > > > Best, > R. > > > > > > On Fri, Jul 11, 2014 at 9:47 AM, wrote: > > Hi Jeff, > > As I said to Robert offline, the main issue I see with wide comm would be > the introduced delay of availability of this important use case (I'm > talking about multiple years ... while use case is now ...). > Wide comm is not yet a WG doc ... encoding may still change ... > > I also agree that we are quite short in bit and bytes using an extcomm bu= t > it sounds usable. > > May be a two step approach can be done : > - first standardize using extcomm as for other flowspec actions (we can > discuss for sure bits and bytes to optimize the encoding proposal) > > Then : > - review all flowspec actions and see how we can use wide comm to enhance > usability of them. > > Thoughts ? > > Best Regards, > > Stephane > > > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Thursday, July 10, 2014 16:22 > To: DECRAENE Bruno IMT/OLN > Cc: idr wg > Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset > > Bruno, > > On Thu, Jul 10, 2014 at 09:48:34AM +0000, bruno.decraene@orange.com wrote= : > > This would translate into the proposed following additional text: > > > > 6. IANA Considerations > > > > The IANA is requested to create and maintain a registry entitled > > "Assigned Flow spec interface-set" with the following > > registration procedure: > > > > Registry Name: Assigned Flow spec interface-set > > > > Range Registration Procedures > > ----------- ------------------------- > > 0x0000-3EFF Reserved for private use. > > 0x3F00-3FFF Standards Action/Early IANA Allocation. > > > > > > The IANA is requested to update the registry "Assigned Flow spec > interface-set" as follows: > > > > 0x3F00: IGP interface > > 0x3F01: non IGP interface > > 0x3F02: eBGP interface > > 0x3F03: non eBGP interface > > 0x3F04: VRF interface > > 0x3F05: non VRF interface > > As Robert Raszuk had already pointed out off-list, "Why aren't we using > wide communities for this". :-) > > I had intended to let the idea for these constraints circulate a bit for > people to get comfortable with it before bringing up wide comms as the > policy mechanism for it. > > > -- Jeff > > _______________________________________________ > 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 o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > _________________________________________________________________________= ________________________________________________ > > 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. > > 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. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --089e0112c39c40047704fde7a50f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

Well ... direction can also be specified using regular commu= nities ;)

You just need x2....

Cheers,
R.

On Jul 11, 2014 11:02 AM, <stephane.litkowski@orange.com> wrote= :

Hi Robert,<= /span>

=C2=A0

We need to have a way to = encode the direction of the filter, so this part should be registered and s= tandardized for interoperability purpose. Moreover we want something completely automated without having to configure policies on eac= h node describing mapping between community values and filter parameters (d= irection).

=C2=A0

Regarding =E2=80=9CAND=E2= =80=9D/=E2=80=9DOR=E2=80=9D, the idea is that if NLRI has GroupID1 and Grou= pID2 attached. It need to be considered as a =E2=80=9Cmatch-any=E2=80=9D, s= o it will be applied to interfaces belonging to GroupID1 and interfaces belonging to GroupID2.<= /span>

For me =E2=80=9CAND=E2=80= =9D would be more a =E2=80=9Cmatch all=E2=80=9D, saying that the filter wou= ld be applied on interfaces that are belonging only to both groups at the s= ame time.

We can rephrase in next v= ersion.

=C2=A0

=C2=A0

Thanks,

=C2=A0

Stephane

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Friday, July 11, 2014 10:05
To: LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas; DECRAENE Bruno IMT/OLN; idr wg
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset<= u>

=C2=A0

= Stephane,

= =C2=A0

= I am not sure why you would not be fine for now with use of regular communi= ty for such group coloring ?=C2=A0

= =C2=A0

= Do you really need to define new extended community which results in need f= or implementations in various code bases ?=C2=A0

= =C2=A0

= RFC 5575 already addresses this today by paragraph:

= =C2=A0

=C2=A0
Implementations should pr=
ovide mechanisms that map an arbitraryBGP community value (normal or extend=
ed) to filtering actions that require different mappings in different syste=
ms in the network.

= =C2=A0

= - - -=C2=A0

= =C2=A0

= As to the draft I think you really meant "AND" not "OR"= :)

= =C2=A0

Multiple instances of the=
 community in a BGP update MUST be
interpreted as a "OR=
" operation : if a BGP update contains two
interface-set communities=
 with group ID 1 and group ID 2, the filter would need to be installed on i=
nterfaces belonging to Group ID 1 or Group ID 2.
=C2=A0
=C2=A0
=C2=A0
Otherwise if you meant =
"OR" you need to elaborate which one out of the two.

=C2=A0

= Best,
R.

= =C2=A0

=C2=A0<= /p>

On Fri, Jul 11, 2014 at 9:47 AM, <stephane.litkowski@oran= ge.com> wrote:

Hi Jeff,

As I said to Robert offline, the main issue I see with wide comm would be t= he introduced delay of availability of this important use case (I'm tal= king about multiple years ... while use case is now ...).
Wide comm is not yet a WG doc ... encoding may still change ...

I also agree that we are quite short in bit and bytes using an extcomm but = it sounds usable.

May be a two step approach can be done :
- first standardize using extcomm as for other flowspec actions (we can dis= cuss for sure bits and bytes to optimize the encoding proposal)

Then :
- review all flowspec actions and see how we can use wide comm to enhance u= sability of them.

Thoughts ?

Best Regards,

Stephane



-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: Thursday, July 10, 2014 16:22
To: DECRAENE Bruno IMT/OLN
Cc: idr wg
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset

Bruno,

On Thu, Jul 10, 2014 at 09:48:34AM +0000, bruno.decraene@orange.com wrote:
> This would translate into the proposed following additional text:
>
> 6. IANA Considerations
>
> The IANA is requested to create and maintain a registry entitled
> =C2=A0 =C2=A0"Assigned Flow spec interface-set" with the fol= lowing
> =C2=A0 =C2=A0registration procedure:
>
> =C2=A0 =C2=A0 Registry Name: Assigned Flow spec interface-set
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Range =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Registration Procedures
> =C2=A0 =C2=A0 =C2=A0 =C2=A0----------- =C2=A0 =C2=A0 =C2=A0 =C2=A0----= ---------------------
> =C2=A0 =C2=A0 =C2=A0 =C2=A00x0000-3EFF =C2=A0 =C2=A0 =C2=A0 =C2=A0Rese= rved for private use.
> =C2=A0 =C2=A0 =C2=A0 =C2=A00x3F00-3FFF =C2=A0 =C2=A0 =C2=A0 =C2=A0Stan= dards Action/Early IANA Allocation.
>
>
> The IANA is requested to update the registry "Assigned Flow spec = interface-set" as follows:
>
> 0x3F00: IGP interface
> 0x3F01: non IGP interface
> 0x3F02: eBGP interface
> 0x3F03: non eBGP interface
> 0x3F04: VRF interface
> 0x3F05: non VRF interface

As Robert Raszuk had already pointed out off-list, "Why aren't we = using wide communities for this". =C2=A0:-)

I had intended to let the idea for these constraints circulate a bit for pe= ople to get comfortable with it before bringing up wide comms as the policy= mechanism for it.


-- Jeff

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

_____________________= ___________________________________________________________________________= _________________________

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

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

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

=C2=A0

______________________________________________________________________=
___________________________________________________

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

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

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

--089e0112c39c40047704fde7a50f-- From nobody Mon Jul 21 00:21:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4571B2D9A; Mon, 21 Jul 2014 00:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3b_1LCFLh9x; Mon, 21 Jul 2014 00:20:58 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F331B2D76; Mon, 21 Jul 2014 00:20:57 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id rl12so6317485iec.24 for ; Mon, 21 Jul 2014 00:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qjROYu9fN+RhJfHIVvn/i3r7ew4GaEVtmKe6/fyUjes=; b=Ui28P0sWKUj0Yrf2fAhN+AERAzcA7EiyJIN1eKFizzxE975h6XaCgXsK4sGmCcUszr iscIOxFmauaTFoKENSx9ZxUvi98/2k0RKMJVB6BOnl//Q5bp6Jys+RoRfAsTfOF7f6O2 mYyXYtpt6u/+Hy2KLxhZxIfPsOxCQ1UzhiLDpofcFBrsQLZdD3MrWUPJMKZeCGpANgSs PHRyM49l8AOWE87AbXO/pRNR6nr6HN99ezHx5o3+l6dFo837rEfR5cmcZ5Gylo4S2PX6 AWtF9Ms3m7wkf7PQI24WbM889iFnUEdHkJYGReZXWmJHXqrCPzYNKQL7GNMqhCfIcNeX 2Rrw== MIME-Version: 1.0 X-Received: by 10.50.62.80 with SMTP id w16mr1893593igr.21.1405927256750; Mon, 21 Jul 2014 00:20:56 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Mon, 21 Jul 2014 00:20:56 -0700 (PDT) In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07@nkgeml506-mbx.china.huawei.com> Date: Mon, 21 Jul 2014 09:20:56 +0200 X-Google-Sender-Auth: Fg2tmQKkvpPE_NIL7F-24a_km-E Message-ID: From: Robert Raszuk To: Lizhenbin Content-Type: multipart/alternative; boundary=047d7bdc0aeab8020204feaef2bb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/7-vd7FbLeV5Ke9UJ6_jBvy0HWiA Cc: "idr@ietf.org" , "spring@ietf.org" Subject: Re: [Idr] [spring] Comments on draft-filsfils-spring-segment-routing-central-epe-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 07:20:58 -0000 --047d7bdc0aeab8020204feaef2bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi Robin,=E2=80=8B +---------+ +------+ > | | | | > | H B------D G > | | +---/| AS 2 |\ +------+ > | |/ +------+ \ | |---L/8 > A AS1 C---+ \| | > | |\\ \ +------+ /| AS 4 |---M/8 > | | \\ +-E |/ +------+ > | X | \\ | K > | | +=3D=3D=3DF AS 3 | > +---------+ +------+ > > > The router F in AS 3 will change itself as the Next-hop and allocate a ne= w > BGP label for the destination prefix L/8, then send it to the router C, > eg., using a new label: 5002 > =E2=80=8BNot quite right. Router F is not a MPLS router. It just uses plain IPv4/IPv6 forwarding. Please read this in the draft: "o The solution MUST apply to the Internet use-case where the Internet routes are assumed to use IPv4 unlabeled or IPv6 unlabeled.=E2=80=8B" =E2=80=8BThe entire EPE solution as described in the draft is contained to = AS1. AS 2..4 are for illustration of the bigger picture only. - - - =3D=3D=3DComments Begin=3D=3D=3D > Deploying Inter-AS L3VPN Option B Services with reference to the > =E2=80=8BLet me clarify that the EPE draft does not talk about VPN service. It only uses L3VPN VPN mechanism within AS1 to distribute EPE =E2=80=8Binstrumentation data perhaps "VPN policy route" is a bit misleadin= g term. It really means that SAFI 128 is used for EPE steering labels distribution. It is still only IPv4/IPv6 Internet service. Said this your suggestion of using EPE within VPN service and specifically at EPE enhanced option B peering is valid. However if you would like to focus on using EPE for VPN service it seems that new separate proposal may be required. There is few issues associated with this unique to such use case. It can very well serve as parallel draft to Internet EPE use case. Thx, R. --047d7bdc0aeab8020204feaef2bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi Robin,=E2=80=8B

=C2=A0 =C2=A0+---------+=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 +------+
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 H=C2=A0=C2=A0=C2=A0 B------D=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 G
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | +---/| AS = 2 |\=C2=A0 +------+
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |/=C2=A0=C2= =A0=C2=A0=C2=A0 +------+ \ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---L/8
=C2=A0=C2=A0 A=C2=A0=C2=A0 AS1=C2=A0=C2=A0 C---+=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<= br> =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |\\=C2=A0 \= =C2=A0 +------+ /| AS 4 |---M/8
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | \\=C2=A0 += -E=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |/ +------+
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 X=C2=A0=C2=A0=C2=A0 |=C2=A0 \\=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 K
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0 +=3D=3D=3DF AS 3 |
=C2=A0=C2=A0 +---------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +------+


The router F in AS 3 will chan= ge itself as the Next-hop and allocate a new BGP label for the destination = prefix L/8, then send it to the router C, eg., using a new label: 5002


=E2=80=8BNot quite right. Router F is not a MPLS router. It just uses = plain IPv4/IPv6 forwarding. Please read this in the draft:

"o =C2=A0The solution MUST a= pply to the Internet use-case where the Internet routes are assumed to use = IPv4 unlabeled or IPv6 unlabeled.=E2=80=8B"

=E2=80=8BThe entire EPE solution as = described in the draft is contained to AS1. AS 2..4 are for illustration of= the bigger picture only.=C2=A0

- - -=C2= =A0

=3D=3D=3DComments Begin=3D=3D=3DDeploying Inter-AS L3VPN Option B Services with reference to the


=E2=80=8BLet me clarify that the EPE draft does not talk about VPN service.= =C2=A0

It only uses L3VPN VPN mechanism within AS1 to distribute EPE =E2=80=8Binst= rumentation data perhaps "VPN policy route" is a bit misleading t= erm. It really means that SAFI 128 is used for EPE steering labels distribu= tion. It is still only IPv4/IPv6 Internet service.=C2=A0

Said this your su= ggestion of using EPE within VPN service and specifically at EPE enhanced o= ption B peering is valid.=C2=A0

However if= you would like to focus on using EPE for VPN service it seems that new sep= arate proposal may be required. There is few issues associated with this un= ique to such use case.=C2=A0

It can very well = serve as parallel draft to Internet EPE use case.

Thx,
R.=

--047d7bdc0aeab8020204feaef2bb-- From nobody Mon Jul 21 06:41:11 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F6E1B2C00; Mon, 21 Jul 2014 06:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ-_qFdOg4IZ; Mon, 21 Jul 2014 06:40:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58B81B2C02; Mon, 21 Jul 2014 06:37:20 -0700 (PDT) Received: from juniper.net (66.129.239.11) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 13:37:17 +0000 Date: Mon, 21 Jul 2014 15:37:10 +0200 From: Hannes Gredler To: Robert Raszuk Message-ID: <20140721133709.GA19995@juniper.net> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [66.129.239.11] X-ClientProxiedBy: BY2PR03CA043.namprd03.prod.outlook.com (10.141.249.16) To CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0279B3DD0D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(189002)(199002)(23726002)(80022001)(92566001)(81156004)(83506001)(15975445006)(74502001)(97756001)(4396001)(77982001)(76482001)(79102001)(81342001)(83072002)(107046002)(74662001)(86362001)(33656002)(47776003)(46406003)(66066001)(102836001)(85852003)(31966008)(106356001)(92726001)(64706001)(20776003)(105586002)(69596002)(42186005)(36756003)(87976001)(77096002)(33026002)(19580395003)(99396002)(81542001)(76176999)(110136001)(21056001)(50986999)(46102001)(50466002)(19580405001)(83322001)(95666004)(85306003)(54356999)(101416001)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:juniper.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/CdDpXJWI6lrsxhyWBntfMGoLsqY Cc: "idr@ietf.org" , "spring@ietf.org" , Lizhenbin Subject: Re: [Idr] [spring] Comments on draft-filsfils-spring-segment-routing-central-epe-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:41:06 -0000 hi robert, why does it matter wether router 'F' is MPLS enabled or not ? IMO all that is required is that router 'C' 'generates' a labeled route for router 'F' (NH: router C) as soon as the BGP session between C and F comes up. - i.e. just local router C implementation - no new protocol extensions required for making this work at all. tx, /hannes On Mon, Jul 21, 2014 at 09:20:56AM +0200, Robert Raszuk wrote: | *Hi Robin,* | | +---------+ +------+ | | | | | | | H B------D G | | | +---/| AS 2 |\ +------+ | | |/ +------+ \ | |---L/8 | A AS1 C---+ \| | | | |\\ \ +------+ /| AS 4 |---M/8 | | | \\ +-E |/ +------+ | | X | \\ | K | | | +===F AS 3 | | +---------+ +------+ | | The router F in AS 3 will change itself as the Next-hop and allocate a | new BGP label for the destination prefix L/8, then send it to the router | C, eg., using a new label: 5002 | | *Not quite right. Router F is not a MPLS router. It just uses plain | IPv4/IPv6 forwarding. Please read this in the draft: | "o The solution MUST apply to the Internet use-case where the Internet | routes are assumed to use IPv4 unlabeled or IPv6 unlabeled.*" | *The entire EPE solution as described in the draft is contained to AS1. AS | 2..4 are for illustration of the bigger picture only. | - - - | | ===Comments Begin=== | Deploying Inter-AS L3VPN Option B Services with reference to the | | *Let me clarify that the EPE draft does not talk about VPN service. | It only uses L3VPN VPN mechanism within AS1 to distribute EPE | *instrumentation data perhaps "VPN policy route" is a bit misleading term. | It really means that SAFI 128 is used for EPE steering labels | distribution. It is still only IPv4/IPv6 Internet service. | Said this your suggestion of using EPE within VPN service and specifically | at EPE enhanced option B peering is valid. | However if you would like to focus on using EPE for VPN service it seems | that new separate proposal may be required. There is few issues associated | with this unique to such use case. | It can very well serve as parallel draft to Internet EPE use case. | Thx, | R. | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 21 08:05:08 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A721B2AAB; Sun, 20 Jul 2014 18:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsOTH_QVZJUx; Sun, 20 Jul 2014 18:10:41 -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 4FA3E1B2A85; Sun, 20 Jul 2014 18:10:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKH74618; Mon, 21 Jul 2014 01:10:38 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Jul 2014 02:10:37 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 21 Jul 2014 09:10:31 +0800 From: Lizhenbin To: "spring@ietf.org" , "idr@ietf.org" Thread-Topic: Comments on draft-filsfils-spring-segment-routing-central-epe-02 Thread-Index: Ac+kfIRNjOwQX0bwRNmv2wgtR0D8ZQ== Date: Mon, 21 Jul 2014 01:10:31 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.163.73] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/-YZNJXnDbLQ6dsxRn_Miaxe_Swc X-Mailman-Approved-At: Mon, 21 Jul 2014 08:05:03 -0700 Subject: [Idr] Comments on draft-filsfils-spring-segment-routing-central-epe-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 01:10:44 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYXV0aG9ycywNCg0KVGhlIHVzZWNhc2UgcHJvcG9zZWQgYnkgdGhlIGRyYWZ0IGlzIHVzZWZ1 bCBhbmQgd29ydGggcmVzZWFyY2guIFdlIHJldmlldyB0aGUgZHJhZnQgYW5kIGZpbmQgdGhlcmUg bWF5IGJlIHNvbWUgZXJyb3JzIGFib3V0IHRoZSBwcm9jZXNzIGRlc2NyaXB0aW9uIGluIFNlYyA1 LjMgYW5kIDUuNC4gUGxlYXNlIHJlZmVyIHRvIG91ciBhdHRjaGVkIGRldGFpbGVkIGNvbW1lbnRz IGlsbHVzdHJhdGVkIChpZGVudGlmaWVkIGJ5ICJDb21tZW50cyBCZWdpbiIgYW5kICJDb21tZW50 cyBFbmQiKS4gVGhlIHN1bW1hcnkgb2YgdGhlIGNvbW1lbnRzIGlzIGFzIGZvbGxvd3M6DQoNCi0t IFJlZ2FyZGluZyBJbnRlci1BUyBPcHRpb24tQyB1c2luZyBSRkMgMzEwNywgaXQgc2hvdWxkIGFk dmVydGlzZSB0aGUgbGFiZWwgc3RhY2sgaW4gdGhlIGluZ3Jlc3MgUEUgdGhyb3VnaCBCR1AgZXh0 ZW5zaW9ucyBpbnN0ZWFkIG9mIG9ubHkgdGhlIHN0ZWVyaW5nIGxhYmVsIGZvciBFUEU7DQoNCi0t IFJlZ2FyZGluZyBJbnRlci1BUyBPcHRpb24tQiwgaWYgIm5leHQgaG9wIHNlbGYiIGlzIG5vdCBl bmFibGVkIGluIHRoZSBBU0JSIGluIHRoZSBsb2NhbCBBUywgaXQgc2hvdWxkIGFsc28gYWR2ZXJ0 aXNlIHRoZSBsYWJlbCBzdGFjayBpbiB0aGUgaW5ncmVzcyBQRSB0aHJvdWdoIEJHUCBleHRlbnNp b25zIGluc3RlYWQgb2Ygb25seSB0aGUgc3RlZXJpbmcgbGFiZWwgZm9yIEVQRTsNCg0KV2UgcHJv cG9zZWQgbW9yZSB1c2UgY2FzZXMgd2hpY2ggbmVlZHMgdG8gYWR2ZXJ0aXNlIHRoZSBsYWJlbCBz dGFjayB0aHJvdWdoIEJHUCBleHRlbnNpb25zIGluIHRoZSBjZW50cmFsIGNvbnRyb2wgZW52aXJv bm1lbnQgaW4gZHJhZnQtbGktc3ByaW5nLW1wbHMtcGF0aC1wcm9ncmFtbWluZy0wMCBhbmQgdGhl IGNvcnJlc3BvbmRpbmcgQkdQIGV4dGVuc2lvbnMgYXJlIHByb3Bvc2VkIGluIHRoZSBkcmFmdC1s aS1pZHItbXBscy1wYXRoLXByb2dyYW1taW5nLTAwIHRvIGFkdmVydGlzZSB0aGUgbGFiZWwgc3Rh Y2sgYWxvbmcgd2l0aCB0aGUgYWR2ZXJ0aXNlZCBwcmVmaXguIEl0IGlzIGZvciB5b3VyIHJlZmVy ZW5jZS4NCg0KQmVzaWRlcyBhYm92ZSwgUmVnYXJkaW5nICI1LjIuICBBdCBhIHJvdXRlciAtIFNS IFRyYWZmaWMgRW5naW5lZXJpbmcgdHVubmVsIiwgd2UgdGhpbmsgaXQgaXMgYmV0dGVyIHRoYXQg dGhlIHN0ZWVyaW5nIGxhYmVsIGZvciBFUEUgKGUuZy4gMTA0Mikgc2hvdWxkIGJlIGFkdmVydGlz ZWQgdGhyb3VnaCBCR1AgZXh0ZW5zaW9ucyBSRkMgMzEwNyBpbnN0ZWFkIG9mIFBDUEUgc2luY2Ug dGhlIHN0ZWVyaW5nIHNlcnZpY2UgaXMgcGVyIHNlcnZpY2UgaW5zdGVhZCBvZiBwZXIgdHVubmVs IGFuZCB0aGUgcHJvY2VzcyBjYW4gYmUgdW5pZmllZCB3aXRoIG90aGVyIHByb2Nlc3MgaW4gU2Vj IDUuMyBhbmQgNS40LiBUaGF0IGlzLCBhbGwgb2YgdGhlbSBhcmUgYmFzZWQgb24gQkdQIGV4dGVu c2lvbnMgdG8gYWR2ZXJ0aXNlIHRoZSBzdGVlcmluZyBsYWJlbCB3aXRoIHRoZSBwcmVmaXguDQoN Cg0KDQoNCg0KUmVnYXJkcywNCg0KWmhlbmJpbihSb2JpbikNCg0KDQoNCkF0dGFjaGVkIGNvbW1l bnRzOg0KDQoNCg0KNS4zLiAgQXQgYSBSb3V0ZXIgLSBCR1AzMTA3IHBvbGljeSByb3V0ZQ0KDQog ICBUaGUgRVBFIENvbnRyb2xsZXIgY291bGQgYnVpbGQgYSBCR1AzMTA3IChbUkZDMzEwN10pIHJv dXRlIChmcm9tDQogICBzY3JhdGNoKSBhbmQgc2VuZCBpdCB0byB0aGUgaW5ncmVzcyByb3V0ZXI6 DQoNCiAgIG8gIE5MUkk6IHRoZSBkZXN0aW5hdGlvbiBwcmVmaXggdG8gZW5naW5lZXI6IGUuZy4g IEwvOC4NCg0KICAgbyAgTmV4dC1Ib3A6IHRoZSBzZWxlY3RlZCBlZ3Jlc3MgYm9yZGVyIHJvdXRl cjogQy4NCg0KICAgbyAgTGFiZWw6IHRoZSBzZWxlY3RlZCBlZ3Jlc3MgcGVlcjogMTA0Mi4NCg0K ICAgbyAgQVMgcGF0aDogcmVmbGVjdGluZyB0aGUgdmFsaWQgQVMgcGF0aCBvZiB0aGUgc2VsZWN0 ZWQuDQoNCiAgIG8gIFNvbWUgQkdQIHBvbGljeSB0byBlbnN1cmUgaXQgYmUgc2VsZWN0ZWQgYXMg YmVzdCBieSB0aGUgaW5ncmVzcw0KICAgICAgcm91dGVyLg0KDQogICBUaGlzIEJHUDMxMDcgcG9s aWN5IHJvdXRlICJvdmVyd3JpdGVzIiBhbiBlcXVpdmFsZW50IG9yIGxlc3Mtc3BlY2lmaWMNCiAg ICJiZXN0IHBhdGgiLiAgQXMgdGhlIGJlc3QtcGF0aCBpcyBjaGFuZ2VkLCB0aGlzIEVQRSBpbnB1 dCBwb2xpY3kNCiAgIG9wdGlvbiBpbmZsdWVuY2VzIHRoZSBwYXRoIHByb3BhZ2F0ZWQgdG8gdGhl IHVwc3RyZWFtIHBlZXIvY3VzdG9tZXJzLg0KDQogICA9PT1Db21tZW50cyBCZWdpbj09PQ0KICAg QnVpbGRpbmcgQkdQIExTUHMgd2l0aCByZWZlcmVuY2UgdG8gdGhlICJSZWZlcmVuY2UgRGlhZ3Jh bSIgc2hvd24gaW4NCiAgIFtJLUQuZmlsc2ZpbHMtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1jZW50 cmFsLWVwZV0uIFRoZSBkZXN0aW5hdGlvbg0KICAgcHJlZml4IGlzIEwvOCwgdGhlIGluZ3Jlc3Mg cm91dGVyIGlzIEEuDQoNCiAgICstLS0tLS0tLS0rICAgICAgKy0tLS0tLSsNCiAgIHwgICAgICAg ICB8ICAgICAgfCAgICAgIHwNCiAgIHwgICAgSCAgICBCLS0tLS0tRCAgICAgIEcNCiAgIHwgICAg ICAgICB8ICstLS0vfCBBUyAyIHxcICArLS0tLS0tKw0KICAgfCAgICAgICAgIHwvICAgICArLS0t LS0tKyBcIHwgICAgICB8LS0tTC84DQogICBBICAgQVMxICAgQy0tLSsgICAgICAgICAgICBcfCAg ICAgIHwNCiAgIHwgICAgICAgICB8XFwgIFwgICstLS0tLS0rIC98IEFTIDQgfC0tLU0vOA0KICAg fCAgICAgICAgIHwgXFwgICstRSAgICAgIHwvICstLS0tLS0rDQogICB8ICAgIFggICAgfCAgXFwg ICB8ICAgICAgSw0KICAgfCAgICAgICAgIHwgICArPT09RiBBUyAzIHwNCiAgICstLS0tLS0tLS0r ICAgICAgICstLS0tLS0rDQoNCiAgIEZvciBJbnRlci1BUyBkZXBsb3lpbmcgc2NlbmFyaW8sIHRo ZSByb3V0ZXIgSywgRiBhbmQgQyB3aWxsIHVzZSB0aGUNCiAgIG5leHQtaG9wLXNlbGYgbWV0aG9k IHRvIGNoYW5nZSBpdHNlbGYgYXMgdGhlIE5leHQtaG9wIGZvciB0aGUNCiAgIGRlc3RpbmF0aW9u IHByZWZpeCBMLzguDQoNCiAgIFRoZSByb3V0ZXIgSyBpbiBBUyAzIHdpbGwgY2hhbmdlIGl0c2Vs ZiBhcyB0aGUgTmV4dC1ob3AgYW5kIGFsbG9jYXRlDQogICBhIG5ldyBCR1AgbGFiZWwgZm9yIHRo ZSBkZXN0aW5hdGlvbiBwcmVmaXggTC84LCB0aGVuIHNlbmQgaXQgdG8gdGhlDQogICByb3V0ZXIg RiwgZWcuLCB1c2luZyBhIG5ldyBsYWJlbDogNTAwMQ0KDQogICBUaGUgcm91dGVyIEYgaW4gQVMg MyB3aWxsIGNoYW5nZSBpdHNlbGYgYXMgdGhlIE5leHQtaG9wIGFuZCBhbGxvY2F0ZQ0KICAgYSBu ZXcgQkdQIGxhYmVsIGZvciB0aGUgZGVzdGluYXRpb24gcHJlZml4IEwvOCwgdGhlbiBzZW5kIGl0 IHRvIHRoZQ0KICAgcm91dGVyIEMsIGVnLiwgdXNpbmcgYSBuZXcgbGFiZWw6IDUwMDINCg0KICAg VGhlIEVQRSBDb250cm9sbGVyIGNvdWxkIGJ1aWxkIGEgQkdQMzEwNyAoW1JGQzMxMDddKSByb3V0 ZSAoZnJvbQ0KICAgc2NyYXRjaCkgYW5kIHNlbmQgaXQgdG8gdGhlIGluZ3Jlc3Mgcm91dGVyOg0K DQogICBvICBOTFJJOiB0aGUgZGVzdGluYXRpb24gcHJlZml4IHRvIGVuZ2luZWVyOiBlLmcuICBM LzguDQoNCiAgIG8gIE5leHQtSG9wOiB0aGUgc2VsZWN0ZWQgZWdyZXNzIGJvcmRlciByb3V0ZXI6 IEMuDQoNCiAgIG8gIExhYmVscyhTSE9VTEQgYmUgYSBsYWJlbCBzdGFjayk6DQogICAgICBUaGUg Zmlyc3QgTGFiZWw6IHRoZSBzZWxlY3RlZCBlZ3Jlc3MgcGVlcjogMTA0Mi4NCiAgICAgIFRoZSBz ZWNvbmQgTGFiZWw6IHRoZSBMYWJlbCB0aGF0IHRoZSByb3V0ZXIgRiBzZW5kcyB0byB0aGUgcm91 dGVyDQogICAgICBDOiA1MDAyDQoNCiAgICAgIChBIHBhY2tldCBjb21lcyBpbnRvIHRoZSBpbmdy ZXNzIHJvdXRlciBBLCB3aWxsIHB1c2ggMyBsYWJlbHM6DQogICAgICBMYWJlbCBvZiBOb2RlIEMn cyBTZWdtZW50LCAxMDQyLCA1MDAyOyApDQoNCiAgIG8gIEFTIHBhdGg6IHJlZmxlY3RpbmcgdGhl IHZhbGlkIEFTIHBhdGggb2YgdGhlIHNlbGVjdGVkLg0KDQogICBvICBTb21lIEJHUCBwb2xpY3kg dG8gZW5zdXJlIGl0IGJlIHNlbGVjdGVkIGFzIGJlc3QgYnkgdGhlIGluZ3Jlc3MNCiAgICAgIHJv dXRlci4NCg0KICAgUGFja2V0IFdhbGt0aHJvdWdoOg0KICAgMSkgQSBwYWNrZXQgZGVzdGluYXRp bmcgdG8gTC84IGNvbWVzIGludG8gdGhlIGluZ3Jlc3Mgcm91dGVyIEE7DQogICAyKSBUaGUgcm91 dGVyIEEgd2lsbCBQVVNIIDMgbGFiZWxzIGluIHR1cm46IDUwMDIsIDEwNDIsIHRoZSBsYWJlbCBv Zg0KICAgICAgdGhlIE5vZGUgU2VnbWVudCBvZiBDLCB0aGVuIHNlbmQgdGhlIHBhY2tldCB0byB0 aGUgcm91dGVyIEM7DQogICAzKSBXaGVuIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgcm91dGVyIEMs IHRoZSBhY3Rpb25zIGFyZSBjYXJyaWVkIG91dA0KICAgICAgYnkgdGhlIHJvdXRlciBDOiBmaXJz dGx5LCBQT1BzIHRoZSBsYWJlbCBvZiB0aGUgTm9kZSBTZWdtZW50IG9mIEM7DQogICAgICBzZWNv bmRseSwgUE9QcyB0aGUgbGFiZWwgMTA0MiBhbmQgZmluZHMgb3V0IHRoZSBvdXRnb2luZyBpbnRl cmZhY2UNCiAgICAgIHRvIHRoZSByb3V0ZXIgRiBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGxhYmVs IDEwNDI7DQogICA0KSBXaGVuIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgcm91dGVyIEYsIHRoZSBy b3V0ZXIgRiB3aWxsIHNlZSB0aGUgYmdwDQogICAgICBsYWJlbCA1MDAyIGFuZCBjYW4gU1dBUCB0 aGUgYmdwIGxhYmVsIDUwMDIgdG8gdGhlIGJncCBsYWJlbCA1MDAxLA0KICAgICAgdGhlbiBzZW5k IHRoZSBwYWNrZXQgdG8gdGhlIHJvdXRlciBLLg0KICAgPT09Q29tbWVudHMgRW5kPT09DQoNCjUu NC4gIEF0IGEgUm91dGVyIC0gVlBOIHBvbGljeSByb3V0ZQ0KDQogICBUaGUgRVBFIENvbnRyb2xs ZXIgY291bGQgYnVpbGQgYSBWUE52NCByb3V0ZSAoZnJvbSBzY3JhdGNoKSBhbmQgc2VuZA0KICAg aXQgdG8gdGhlIGluZ3Jlc3Mgcm91dGVyOg0KDQogICBvICBOTFJJOiB0aGUgZGVzdGluYXRpb24g cHJlZml4IHRvIGVuZ2luZWVyOiBlLmcuICBMLzguDQoNCiAgIG8gIE5leHQtSG9wOiB0aGUgc2Vs ZWN0ZWQgZWdyZXNzIGJvcmRlciByb3V0ZXI6IEMuDQoNCiAgIG8gIExhYmVsOiB0aGUgc2VsZWN0 ZWQgZWdyZXNzIHBlZXI6IDEwNDIuDQoNCiAgIG8gIFJvdXRlLVRhcmdldDogc2VsZWN0aW5nIHRo ZSBhcHByb3ByaWF0ZSBWUkYgYXQgdGhlIGluZ3Jlc3Mgcm91dGVyLg0KDQogICBvICBBUyBwYXRo OiByZWZsZWN0aW5nIHRoZSB2YWxpZCBBUyBwYXRoIG9mIHRoZSBzZWxlY3RlZC4NCg0KICAgbyAg U29tZSBCR1AgcG9saWN5IHRvIGVuc3VyZSBpdCBiZSBzZWxlY3RlZCBhcyBiZXN0IGJ5IHRoZSBp bmdyZXNzDQogICAgICByb3V0ZXIgaW4gdGhlIHJlbGF0ZWQgVlJGLg0KDQogICBUaGUgcmVsYXRl ZCBWUkYgbXVzdCBiZSBwcmUtY29uZmlndXJlZC4gIEEgVlJGIGZhbGwtYmFjayBpbnRvIG1haW4N CiAgIEZJQiBtaWdodCBiZSBiZW5lZmljaWFsIHRvIGF2b2lkIHJlcGxpY2F0aW5nIGFsbCB0aGUg Im5vcm1hbCINCiAgIGludGVybmV0IHBhdGhzIGluIGVhY2ggVlJGLg0KDQogICA9PT1Db21tZW50 cyBCZWdpbj09PQ0KICAgRGVwbG95aW5nIEludGVyLUFTIEwzVlBOIE9wdGlvbiBCIFNlcnZpY2Vz IHdpdGggcmVmZXJlbmNlIHRvIHRoZQ0KICAgIlJlZmVyZW5jZSBEaWFncmFtIiBzaG93biBpbiBb SS1ELmZpbHNmaWxzLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGVdLg0KDQogICBQ RTEoQSkgQVNCUjEoQikgQVNCUjMoRCkNCiAgICstLS0tLS0tLS0rICAgICAgKy0tLS0tLSsNCiAg IHwgICAgICAgICB8ICAgICAgfCAgICAgIHwNCiAgIHwgICAgSCAgICBCLS0tLS0tRCAgICAgIEcg KFBFMikNCiAgIHwgICAgICAgICB8ICstLS0vfCBBUyAyIHxcICArLS0tLS0tKw0KICAgfCAgICAg ICAgIHwvICAgICArLS0tLS0tKyBcIHwgICAgICB8LS0tTC84DQogICBBICAgQVMxICAgQy0tLSsg ICAgICAgICAgICBcfCAgICAgIHwNCiAgIHwgICAgICAgICB8XFwgIFwgICstLS0tLS0rIC98IEFT IDQgfC0tLU0vOA0KICAgfCAgICAgICAgIHwgXFwgICstRSAgICAgIHwvICstLS0tLS0rDQogICB8 ICAgIFggICAgfCAgXFwgICB8ICAgICAgSyAoUEUzKQ0KICAgfCAgICAgICAgIHwgICArPT09RiBB UyAzIHwNCiAgICstLS0tLS0tLS0rICAgICAgICstLS0tLS0rDQogICAgICAgICAgQVNCUjIoQykg IEFTQlI0KEUpDQogICAgICAgICAgICAgICAgICAgIEFTQlI1KEYpDQoNCiAgIEZvciBJbnRlci1B UyBMM1ZQTiBPcHRpb24gQjoNCiAgIFBFMyhLKSB3aWxsIGFsbG9jYXRlIGEgVlBOIGxhYmVsIChl ZywgNjAwMSkgZm9yIHRoZSBkZXN0aW5hdGlvbiBwcmVmaXggTC84LA0KICAgYW5kIHNlbmQgaXQg dG8gdGhlIHJvdXRlciBGIHZpYSBhIFZQTnY0IHJvdXRlOw0KDQogICBBU0JSNShGKSBhbmQgQVNC UjIoQykgd2lsbCBlc3RhYmxpc2ggYW4gRUJHUCBzZXNzaW9uIGFuZCBleGNoYW5nZQ0KICAgVlBO djQgcm91dGVzLCBlZy4gQVNCUjUoRikgd2lsbCBhbGxvY2F0ZSBhIG5ldyBWUE4gTGFiZWwgKGVn LiA2MDAyKSBmb3IgdGhlDQogICBkZXN0aW5hdGlvbiBwcmVmaXggTC84IGFuZCBzZW5kIGl0IHRv IEFTQlIyKEMpOw0KDQogICBUaGUgRVBFIENvbnRyb2xsZXIgY291bGQgYnVpbGQgYSBWUE52NCBy b3V0ZSAoZnJvbSBzY3JhdGNoKSBhbmQgc2VuZA0KICAgaXQgdG8gdGhlIGluZ3Jlc3Mgcm91dGVy Og0KDQogICBvICBOTFJJOiB0aGUgZGVzdGluYXRpb24gcHJlZml4IHRvIGVuZ2luZWVyOiBlLmcu ICBMLzguDQoNCiAgIG8gIE5leHQtSG9wOiB0aGUgc2VsZWN0ZWQgZWdyZXNzIGJvcmRlciByb3V0 ZXI6IEMuDQoNCiAgIG8gIExhYmVscyhTSE9VTEQgYmUgYSBsYWJlbCBzdGFjayk6DQogICAgICBU aGUgZmlyc3QgTGFiZWw6IHRoZSBzZWxlY3RlZCBlZ3Jlc3MgcGVlcjogMTA0Mi4NCiAgICAgIFRo ZSBzZWNvbmQgTGFiZWw6IHRoZSBWUE4gTGFiZWwgdGhhdCB0aGUgcm91dGVyIEYgc2VuZHMgdG8g dGhlIHJvdXRlcg0KICAgICAgQzogNjAwMg0KDQogICBvICBSb3V0ZS1UYXJnZXQ6IHNlbGVjdGlu ZyB0aGUgYXBwcm9wcmlhdGUgVlJGIGF0IHRoZSBpbmdyZXNzIHJvdXRlci4NCg0KICAgbyAgQVMg cGF0aDogcmVmbGVjdGluZyB0aGUgdmFsaWQgQVMgcGF0aCBvZiB0aGUgc2VsZWN0ZWQuDQoNCiAg IG8gIFNvbWUgQkdQIHBvbGljeSB0byBlbnN1cmUgaXQgYmUgc2VsZWN0ZWQgYXMgYmVzdCBieSB0 aGUgaW5ncmVzcw0KICAgICAgcm91dGVyIGluIHRoZSByZWxhdGVkIFZSRi4NCg0KICAgUGFja2V0 IFdhbGt0aHJvdWdoOg0KICAgMSkgQSBwYWNrZXQgZGVzdGluYXRpbmcgdG8gTC84IGNvbWVzIGlu dG8gdGhlIGluZ3Jlc3Mgcm91dGVyIEE7DQogICAyKSBUaGUgcm91dGVyIEEgd2lsbCBQVVNIIDMg bGFiZWxzIGluIHR1cm46IDYwMDIsIDEwNDIsIHRoZSBsYWJlbCBvZg0KICAgICAgdGhlIE5vZGUg U2VnbWVudCBvZiBDLCB0aGVuIHNlbmQgdGhlIHBhY2tldCB0byB0aGUgcm91dGVyIEM7DQogICAz KSBXaGVuIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgcm91dGVyIEMsIHRoZSBhY3Rpb25zIGFyZSBj YXJyaWVkIG91dA0KICAgICAgYnkgdGhlIHJvdXRlciBDOiBmaXJzdGx5LCBQT1BzIHRoZSBsYWJl bCBvZiB0aGUgTm9kZSBTZWdtZW50IG9mIEM7DQogICAgICBzZWNvbmRseSwgUE9QcyB0aGUgbGFi ZWwgMTA0MiBhbmQgZmluZHMgb3V0IHRoZSBvdXRnb2luZyBpbnRlcmZhY2UNCiAgICAgIHRvIHRo ZSByb3V0ZXIgRiBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGxhYmVsIDEwNDI7DQogICA0KSBXaGVu IHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgcm91dGVyIEYsIHRoZSByb3V0ZXIgRiB3aWxsIHNlZSB0 aGUgdnBuDQogICAgICBsYWJlbCA2MDAyIGFuZCBjYW4gU1dBUCB0aGUgdnBuIGxhYmVsIDYwMDIg dG8gdGhlIHZwbiBsYWJlbCA2MDAxLA0KICAgICAgdGhlbiBzZW5kIHRoZSBwYWNrZXQgdG8gdGhl IHJvdXRlciBLLg0KICAgPT09Q29tbWVudHMgRW5kPT09DQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi authors,

The usecase proposed by the draft is useful and worth research. We revie= w the draft and find there may be some errors about the process description= in Sec 5.3 and 5.4. Please refer to our attched detailed comments illustra= ted (identified by "Comments Begin" and "Comments End"). The summary of the comments is as follows:<= /p>

-- Regarding Inter-AS Option-C using RFC 3107, it should advertise the l= abel stack in the ingress PE through BGP extensions instead of only the ste= ering label for EPE;

-- Regarding Inter-AS Option-B, if "next hop self" is not enab= led in the ASBR in the local AS, it should also advertise the label st= ack in the ingress PE through BGP extensions instead of only the steering l= abel for EPE;

We proposed more use cases which needs to advertise the label stack thro= ugh BGP extensions in the central control environment in draft-li-spring-mp= ls-path-programming-00 and the corresponding BGP extensions are proposed in= the draft-li-idr-mpls-path-programming-00 to advertise the label stack along with the advertised prefix. It is = for your reference.

Besides above, Regarding "5.2.  At a router - SR Traffic Engin= eering tunnel", we think it is better that the steering label for= EPE (e.g. 1042) should be advertised through BGP extensions RFC 3107 = instead of PCPE since the steering service is per service instead of per tunnel and the process can be unified with other process in= Sec 5.3 and 5.4. That is, all of them are based on BGP extensions to adver= tise the steering label with the prefix.

 

 

Regards,

Zhenbin(Robin)


 

Attached comments:

 

5.3.  At a Router - BGP3107 policy route

   The EPE Controller could build a BGP3107 ([RFC3107]) route = (from
   scratch) and send it to the ingress router:

   o  NLRI: the destination prefix to engineer: e.g. = ; L/8.

   o  Next-Hop: the selected egress border router: C.

   o  Label: the selected egress peer: 1042.

   o  AS path: reflecting the valid AS path of the select= ed.

   o  Some BGP policy to ensure it be selected as best by= the ingress
      router.

   This BGP3107 policy route "overwrites" an equival= ent or less-specific
   "best path".  As the best-path is changed, this= EPE input policy
   option influences the path propagated to the upstream peer/cus= tomers.

   =3D=3D=3DComments Begin=3D=3D=3D
   Building BGP LSPs with reference to the "Reference Diagra= m" shown in
   [I-D.filsfils-spring-segment-routing-central-epe]. The destina= tion
   prefix is L/8, the ingress router is A.
   
   +---------+      +------&= #43;
   |         |  = ;    |      |
   |    H    B------D  &n= bsp;   G
   |         | +---/|= AS 2 |\  +------+
   |         |/ &nbs= p;   +------+ \ |      |---L/8    A   AS1   C---+    = ;        \|     = ; |
   |         |\\  \&= nbsp; +------+ /| AS 4 |---M/8
   |         | \\  &= #43;-E      |/ +------+
   |    X    |  \\  = |      K
   |         |  = ; +=3D=3D=3DF AS 3 |
   +---------+       +-= -----+

   For Inter-AS deploying scenario, the router K, F and C will= use the
   next-hop-self method to change itself as the Next-hop for the =
   destination prefix L/8.
    
   The router K in AS 3 will change itself as the Next-hop and al= locate
   a new BGP label for the destination prefix L/8, then send it t= o the
   router F, eg., using a new label: 5001
  
   The router F in AS 3 will change itself as the Next-hop and al= locate
   a new BGP label for the destination prefix L/8, then send it t= o the
   router C, eg., using a new label: 5002
  
   The EPE Controller could build a BGP3107 ([RFC3107]) route (fr= om
   scratch) and send it to the ingress router:

   o  NLRI: the destination prefix to engineer: e.g. = ; L/8.

   o  Next-Hop: the selected egress border router: C.

   o  Labels(SHOULD be a label stack):
      The first Label: the selected egress peer: 1= 042.
      The second Label: the Label that the router = F sends to the router
      C: 5002 
     
      (A packet comes into the ingress router A, w= ill push 3 labels:
      Label of Node C's Segment, 1042, 5002; )
     
   o  AS path: reflecting the valid AS path of the selected.=

   o  Some BGP policy to ensure it be selected as best by= the ingress
      router.
     
   Packet Walkthrough:
   1) A packet destinating to L/8 comes into the ingress router A= ;
   2) The router A will PUSH 3 labels in turn: 5002, 1042, the la= bel of
      the Node Segment of C, then send the packet = to the router C;
   3) When the packet reaches the router C, the actions are carri= ed out
      by the router C: firstly, POPs the label of = the Node Segment of C;
      secondly, POPs the label 1042 and finds out = the outgoing interface
      to the router F in accordance with the label= 1042;
   4) When the packet reaches the router F, the router F will see= the bgp
      label 5002 and can SWAP the bgp label 5002 t= o the bgp label 5001,
      then send the packet to the router K. &= nbsp;           &nbs= p;            &= nbsp; 
   =3D=3D=3DComments End=3D=3D=3D     &n= bsp;            = ;   

5.4.  At a Router - VPN policy route

   The EPE Controller could build a VPNv4 route (from scratch)= and send
   it to the ingress router:

   o  NLRI: the destination prefix to engineer: e.g. = ; L/8.

   o  Next-Hop: the selected egress border router: C.

   o  Label: the selected egress peer: 1042.

   o  Route-Target: selecting the appropriate VRF at the = ingress router.

   o  AS path: reflecting the valid AS path of the select= ed.

   o  Some BGP policy to ensure it be selected as best by= the ingress
      router in the related VRF.

   The related VRF must be pre-configured.  A VRF fall-ba= ck into main
   FIB might be beneficial to avoid replicating all the "nor= mal"
   internet paths in each VRF.
  
   =3D=3D=3DComments Begin=3D=3D=3D
   Deploying Inter-AS L3VPN Option B Services with reference to t= he
   "Reference Diagram" shown in [I-D.filsfils-spring-se= gment-routing-central-epe].
  
   PE1(A) ASBR1(B) ASBR3(D)     
   +---------+      +------&= #43;
   |         |  = ;    |      |
   |    H    B------D  &n= bsp;   G (PE2)
   |         | +---/|= AS 2 |\  +------+
   |         |/ &nbs= p;   +------+ \ |      |---L/8    A   AS1   C---+    = ;        \|     = ; |
   |         |\\  \&= nbsp; +------+ /| AS 4 |---M/8
   |         | \\  &= #43;-E      |/ +------+
   |    X    |  \\  = |      K (PE3)
   |         |  = ; +=3D=3D=3DF AS 3 |
   +---------+       +-= -----+
          ASBR2(C)  ASBR4= (E)
            &nb= sp;       ASBR5(F)    &nb= sp;            =   
  
   For Inter-AS L3VPN Option B:
   PE3(K) will allocate a VPN label (eg, 6001) for the destinatio= n prefix L/8,
   and send it to the router F via a VPNv4 route;
  
   ASBR5(F) and ASBR2(C) will establish an EBGP session and excha= nge
   VPNv4 routes, eg. ASBR5(F) will allocate a new VPN Label (eg. = 6002) for the
   destination prefix L/8 and send it to ASBR2(C);
  
   The EPE Controller could build a VPNv4 route (from scratch) an= d send
   it to the ingress router:

   o  NLRI: the destination prefix to engineer: e.g. = ; L/8.

   o  Next-Hop: the selected egress border router: C.

   o  Labels(SHOULD be a label stack):
      The first Label: the selected egress peer: 1= 042.
      The second Label: the VPN Label that the rou= ter F sends to the router
      C: 6002 

   o  Route-Target: selecting the appropriate VRF at the = ingress router.

   o  AS path: reflecting the valid AS path of the select= ed.

   o  Some BGP policy to ensure it be selected as best by= the ingress
      router in the related VRF.
     
   Packet Walkthrough:
   1) A packet destinating to L/8 comes into the ingress router A= ;
   2) The router A will PUSH 3 labels in turn: 6002, 1042, the la= bel of
      the Node Segment of C, then send the packet = to the router C;
   3) When the packet reaches the router C, the actions are carri= ed out
      by the router C: firstly, POPs the label of = the Node Segment of C;
      secondly, POPs the label 1042 and finds out = the outgoing interface
      to the router F in accordance with the label= 1042;
   4) When the packet reaches the router F, the router F will see= the vpn
      label 6002 and can SWAP the vpn label 6002 t= o the vpn label 6001,
      then send the packet to the router K. &= nbsp;           &nbs= p;      
   =3D=3D=3DComments End=3D=3D=3D

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07nkgeml506mbxchi_-- From nobody Mon Jul 21 08:17:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E11A02CF; Mon, 21 Jul 2014 08:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e14XMMfQFSx4; Mon, 21 Jul 2014 08:17:28 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3D51A0178; Mon, 21 Jul 2014 08:17:11 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id tr6so6688817ieb.7 for ; Mon, 21 Jul 2014 08:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yRiifvRrsC53ElcugIR7GHZr4Z6pIfm72vgygIDnvAQ=; b=cepGerXCuTVUgAzfsGG2hRoBoEaTIcxM2Naxr5+mHV6GHG0pkkMM1ELWOUr32pss8t TivqdW2jSfdH/pZwI6eIgKvXXRZekOSRuQiKRsDDegbliUy7zn0w2RBN8yunGfKFUDE/ Qj7khVXOYuMUFiEDQ2SyqiOCdQw6gcJEGXE/aF8BlU5whuw0GKJAoYpWjmpTzot3zkw+ uUdj3cv8LkthHqRrsqRjbsHNg0VbCkGHLfqylflvH6KRno3WNicyMs1il4mNbrJk8qex CVsPGRxkDOkZDWAu64rFKEHN4EbnLqU+lcWiTasv8PQyXedj9CBD+RtXurFjqjHIWswg L1xw== MIME-Version: 1.0 X-Received: by 10.43.139.203 with SMTP id ix11mr13813391icc.72.1405955830918; Mon, 21 Jul 2014 08:17:10 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Mon, 21 Jul 2014 08:17:10 -0700 (PDT) In-Reply-To: <20140721133709.GA19995@juniper.net> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07@nkgeml506-mbx.china.huawei.com> <20140721133709.GA19995@juniper.net> Date: Mon, 21 Jul 2014 17:17:10 +0200 X-Google-Sender-Auth: 5Js-wy0-SKtjeiJ06qBC48HvFIk Message-ID: From: Robert Raszuk To: Hannes Gredler Content-Type: multipart/alternative; boundary=001a11c2e654df34df04feb5990b Archived-At: http://mailarchive.ietf.org/arch/msg/idr/z2TpkcWAjlmv9sgxLclsXnbR8w4 Cc: "idr@ietf.org" , "spring@ietf.org" , Lizhenbin Subject: Re: [Idr] [spring] Comments on draft-filsfils-spring-segment-routing-central-epe-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:17:33 -0000 --001a11c2e654df34df04feb5990b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Hannes, On Mon, Jul 21, 2014 at 3:37 PM, Hannes Gredler wrote: > hi robert, > > why does it matter wether router 'F' is MPLS enabled or not ? > =E2=80=8BIt does not. Where did I say it matters for EPE ? However it matters for what Robin is suggesting as his entire suggestion is to carry F's label =E2=80=8Bfrom AS1 controller to ingress points. > IMO all that is required is that router 'C' 'generates' > a labeled route for router 'F' (NH: router C) as soon as the > BGP session between C and F comes up. - > =E2=80=8BThat's true. =E2=80=8BModulo the option B case Robin has suggested= in his second part. While that may also not need protocol extension how you signal this around depends on your choice of signalling channel between controller and ingress points. Best, r. > i.e. just local router C implementation - > no new protocol extensions required for making this work at all. > > tx, > > /hannes > > On Mon, Jul 21, 2014 at 09:20:56AM +0200, Robert Raszuk wrote: > | *Hi Robin,* > | > | +---------+ +------+ > | | | | | > | | H B------D G > | | | +---/| AS 2 |\ +------+ > | | |/ +------+ \ | |---L/8 > | A AS1 C---+ \| | > | | |\\ \ +------+ /| AS 4 |---M/8 > | | | \\ +-E |/ +------+ > | | X | \\ | K > | | | +=3D=3D=3DF AS 3 | > | +---------+ +------+ > | > | The router F in AS 3 will change itself as the Next-hop and > allocate a > | new BGP label for the destination prefix L/8, then send it to the > router > | C, eg., using a new label: 5002 > | > | *Not quite right. Router F is not a MPLS router. It just uses plain > | IPv4/IPv6 forwarding. Please read this in the draft: > | "o The solution MUST apply to the Internet use-case where the > Internet > | routes are assumed to use IPv4 unlabeled or IPv6 unlabeled.*" > | *The entire EPE solution as described in the draft is contained to > AS1. AS > | 2..4 are for illustration of the bigger picture only. > | - - - > | > | =3D=3D=3DComments Begin=3D=3D=3D > | Deploying Inter-AS L3VPN Option B Services with reference to the > | > | *Let me clarify that the EPE draft does not talk about VPN service. > | It only uses L3VPN VPN mechanism within AS1 to distribute EPE > | *instrumentation data perhaps "VPN policy route" is a bit misleading > term. > | It really means that SAFI 128 is used for EPE steering labels > | distribution. It is still only IPv4/IPv6 Internet service. > | Said this your suggestion of using EPE within VPN service and > specifically > | at EPE enhanced option B peering is valid. > | However if you would like to focus on using EPE for VPN service it > seems > | that new separate proposal may be required. There is few issues > associated > | with this unique to such use case. > | It can very well serve as parallel draft to Internet EPE use case. > | Thx, > | R. > > | _______________________________________________ > | Idr mailing list > | Idr@ietf.org > | https://www.ietf.org/mailman/listinfo/idr > > --001a11c2e654df34df04feb5990b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Hannes,
<= br>
On Mon, Jul 21, 2014 at 3:37 PM, Hannes G= redler <hannes@juniper.net> wrote:
hi robert,

why does it matter wether router 'F' is MPLS enabled or not ?

=E2=80=8BIt does not= . Where did I say it matters for EPE ?=C2=A0

However it matter= s for what Robin is suggesting as his entire suggestion is to carry F's= label =E2=80=8Bfrom AS1 controller to ingress points.=C2=A0
=C2=A0
IMO all that is required is that router 'C' 'generates'
a labeled route for router 'F' (NH: router C) as soon as the
BGP session between C and F comes up. -

=E2=80=8BThat's true. =E2=80=8BModulo the opti= on B case Robin has suggested in his second part. While that may also not n= eed protocol extension how you signal this around depends on your choice of= signalling channel between controller and ingress points.

Best,
r.




i.e. just local router C implementation -
no new protocol extensions required for making this work at all.

tx,

/hannes

On Mon, Jul 21, 2014 at 09:20:56AM +0200, Robert Raszuk wrote:
| =C2=A0 =C2=A0*Hi Robin,*
|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------+ =C2=A0 =C2=A0 =C2=A0+------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0H =C2=A0 =C2=A0B------D =C2=A0= =C2=A0 =C2=A0G
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | +---/| AS 2 |= \ =C2=A0+------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |/ =C2=A0 =C2= =A0 +------+ \ | =C2=A0 =C2=A0 =C2=A0|---L/8
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 A =C2=A0 AS1 =C2=A0 C---+ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\| =C2=A0 =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |\\ =C2=A0\ =C2= =A0+------+ /| AS 4 |---M/8
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | \\ =C2=A0+-E = =C2=A0 =C2=A0 =C2=A0|/ +------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0X =C2=A0 =C2=A0| =C2=A0\\ =C2= =A0 | =C2=A0 =C2=A0 =C2=A0K
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 +=3D= =3D=3DF AS 3 |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------+ =C2=A0 =C2=A0 =C2=A0 +------+
|
| =C2=A0 =C2=A0 =C2=A0The router F in AS 3 will chang= e itself as the Next-hop and allocate a
| =C2=A0 =C2=A0 =C2=A0new BGP label for the destination prefix L/8, then se= nd it to the router
| =C2=A0 =C2=A0 =C2=A0C, eg., using a new label: 5002
|
| =C2=A0 =C2=A0*Not quite right. Router F is not a MPLS router. It ju= st uses plain
| =C2=A0 =C2=A0IPv4/IPv6 forwarding. Please read this in the draft:
| =C2=A0 =C2=A0"o =C2=A0The solution MUST apply to the Internet use-ca= se where the Internet
| =C2=A0 =C2=A0routes are assumed to use IPv4 unlabeled or IPv6 unlabeled.*= "
| =C2=A0 =C2=A0*The entire EPE solution as described in the draft is contai= ned to AS1. AS
| =C2=A0 =C2=A02..4 are for illustration of the bigger picture only.
| =C2=A0 =C2=A0- - -
|
| =C2=A0 =C2=A0 =C2=A0=3D=3D=3DComments Begin=3D=3D=3D
| =C2=A0 =C2=A0 =C2=A0Deploying Inter-AS L3VPN Option B Services with refer= ence to the
|
| =C2=A0 =C2=A0*Let me clarify that the EPE draft does not talk about= VPN service.
| =C2=A0 =C2=A0It only uses L3VPN VPN mechanism within AS1 to distribute EP= E
| =C2=A0 =C2=A0*instrumentation data perhaps "VPN policy route" i= s a bit misleading term.
| =C2=A0 =C2=A0It really means that SAFI 128 is used for EPE steering label= s
| =C2=A0 =C2=A0distribution. It is still only IPv4/IPv6 Internet service. | =C2=A0 =C2=A0Said this your suggestion of using EPE within VPN service an= d specifically
| =C2=A0 =C2=A0at EPE enhanced option B peering is valid.
| =C2=A0 =C2=A0However if you would like to focus on using EPE for VPN serv= ice it seems
| =C2=A0 =C2=A0that new separate proposal may be required. There is few iss= ues associated
| =C2=A0 =C2=A0with this unique to such use case.
| =C2=A0 =C2=A0It can very well serve as parallel draft to Internet EPE use= case.
| =C2=A0 =C2=A0Thx,
| =C2=A0 =C2=A0R.

| _______________________________________________
| Idr mailing list
| Idr@ietf.org
| h= ttps://www.ietf.org/mailman/listinfo/idr


--001a11c2e654df34df04feb5990b-- From nobody Mon Jul 21 09:28:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDDD1A02DD; Mon, 21 Jul 2014 09:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHi_9gisACpU; Mon, 21 Jul 2014 09:28:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1991A02FB; Mon, 21 Jul 2014 09:28:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721162835.10020.34701.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 09:28:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/FGHGwd89apT9kJcFbqIBGwkEjVo Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:28:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Extended Message support for BGP Authors : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-08.txt Pages : 4 Date : 2014-07-21 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates [RFC4271] by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-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 Jul 21 10:22:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD3B1A005C for ; Mon, 21 Jul 2014 10:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9PbdaKF_WNt for ; Mon, 21 Jul 2014 10:22:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4531A0084 for ; Mon, 21 Jul 2014 10:22:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1X9HI4-0006Wg-Ej for idr@ietf.org; Mon, 21 Jul 2014 17:22:20 +0000 Date: Mon, 21 Jul 2014 13:22:20 -0400 Message-ID: From: Randy Bush To: idr@ietf.org In-Reply-To: <20140721162835.10020.34701.idtracker@ietfa.amsl.com> References: <20140721162835.10020.34701.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/MfJp4tVg-fGSqArCCW1Bz0KxC70 Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:22:23 -0000 > Title : Extended Message support for BGP just a refresh From nobody Mon Jul 21 11:47:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5178F1A0076 for ; Mon, 21 Jul 2014 11:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVKUBGoMUxuE for ; Mon, 21 Jul 2014 11:47:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A1B1A0047 for ; Mon, 21 Jul 2014 11:47:12 -0700 (PDT) Received: from dgibson-sslvpn-nc.jnpr.net (66.129.241.13) by DM2PR05MB735.namprd05.prod.outlook.com (10.141.178.24) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 18:47:10 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <41D3B4D7-4DD8-4ADC-AE43-3839F44262FD@juniper.net> Date: Mon, 21 Jul 2014 14:47:01 -0400 To: idr wg MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: CO2PR11CA0012.namprd11.prod.outlook.com (10.141.242.150) To DM2PR05MB735.namprd05.prod.outlook.com (10.141.178.24) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0279B3DD0D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(979002)(6009001)(199002)(189002)(52604005)(229853001)(23726002)(93916002)(86362001)(31966008)(107046002)(107886001)(74662001)(106356001)(76482001)(110136001)(85852003)(83072002)(53416004)(21056001)(88136002)(89996001)(92566001)(50986999)(92726001)(46102001)(83716003)(99396002)(33656002)(77156001)(74502001)(36756003)(81156004)(57306001)(95666004)(104166001)(46406003)(77096002)(105586002)(62966002)(85306003)(81542001)(81342001)(97756001)(79102001)(83322001)(87286001)(42186005)(87976001)(50466002)(101416001)(20776003)(50226001)(4396001)(80022001)(47776003)(69596002)(82746002)(66066001)(102836001)(64706001)(77982001)(104396001)(42262001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB735; H:dgibson-sslvpn-nc.jnpr.net; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Ukrm2dey8LcEmRY733YrLGRmslQ Subject: [Idr] Jabber scribe, note-taker for tomorrow? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:47:14 -0000 Folks, We have a very full agenda for tomorrow. As usual, it would be very = helpful if we had volunteers ahead of time for notes and Jabber. As a = reminder, the requirements for Jabber scribe are fairly minimal -- keep = the Jabber room appraised of where we are in the agenda, and relay any = comments to the mic. Thanks for considering volunteering! --John= From nobody Tue Jul 22 06:50:35 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53401B285E for ; Tue, 22 Jul 2014 06:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOiIJDqYCrgD for ; Tue, 22 Jul 2014 06:50:20 -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 D836C1B285B for ; Tue, 22 Jul 2014 06:50:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKK33338; Tue, 22 Jul 2014 13:50:18 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 14:50:17 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 22 Jul 2014 21:50:12 +0800 From: Xuxiaohu To: "idr@ietf.org" Thread-Topic: Comments on draft-vandevelde-idr-remote-next-hop Thread-Index: AQHPpbPbzHcXCG/Jbk2nVvGr5ol2Zg== Date: Tue, 22 Jul 2014 13:50:12 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295F3B@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/DNt7BPvAiKbWdXIapNbUpZH5xiA Subject: [Idr] Comments on draft-vandevelde-idr-remote-next-hop X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 13:50:25 -0000 Hi all co-authors, It seems that this draft is intended to address two issues: one is tunnel e= ncapsulation information advertisment, the other is tunnel endpoint address= information advertisment. For this first issue, it seems that RFC5512 has addressed that issue and th= erefore it seems reasonable to build on that RFC to advertise any new encap= sulation formats. For this second issue, the following draft (http://tools.= ietf.org/id/draft-xu-idr-tunnel-address-prefix-01.txt) has already proposed= an approach to address that issue. Best regards, Xiaohu= From nobody Tue Jul 22 07:21:08 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4FD1B28D0 for ; Tue, 22 Jul 2014 07:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFTWlKzldDCT for ; Tue, 22 Jul 2014 07:21:06 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6D81B28C1 for ; Tue, 22 Jul 2014 07:21:05 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id rl12so8143672iec.38 for ; Tue, 22 Jul 2014 07:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=73BMn/KHdUMG1v/bOQFAHgCB56WCLWtda5W6Kw95I40=; b=cv04m/1gvtJR9N3yH5ENB4eiE/74cs1ftzff3XP/GVbOqb3dppCY0qjiXs0ICxx5ah oDLEa7bbMu8XOvs46n+u65qUcMty7gfQ2K65ekROom/gnxu7Ma7Mfxg1hEbPVWbPsghO hxXwy6m0fVc6ZsY2skS6qxtWJo88ThveHzSUrfbUIjfkjp4vAmRB+8qL7eEUEKPLOXdH pu+I/0zwqHvrufNWWNDMt3Zb84q0Z80XqWbPo3ZkJeE5LmCowma8ORisN4FY1DVS2kU3 cOXdL2YJfwPNqYzTvrr+orUp39ckGT9gsLFmiB4but9KDZvpObxjQiGO4kNO8WueJ8sU eO2w== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr16891861igb.21.1406038865349; Tue, 22 Jul 2014 07:21:05 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 22 Jul 2014 07:21:05 -0700 (PDT) Date: Tue, 22 Jul 2014 16:21:05 +0200 X-Google-Sender-Auth: aqKLyENT41U_DQMXcAe8T4J0oU0 Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=089e013a0c681c115004fec8ef28 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/CxCgaBo3y6Av8NyQ9YCzVe6SMa4 Cc: idr wg Subject: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:21:07 -0000 --089e013a0c681c115004fec8ef28 Content-Type: text/plain; charset=UTF-8 Hi Stephane, So how about we fix this issue by enabling orignator rewrite by RRs for all paths not only those which are local ? You mentioned the need to be per AS selective ... sure this also can be knobbed on the RR if required. What do you think ? Thx, R. --089e013a0c681c115004fec8ef28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephane,

So how about we fix this issue by enabling orignator rewrite by RRs for all= paths not only those which are local ?=C2=A0

=
You mentioned the need to be per AS selective ... sure this also can be kno= bbed on the RR if required.=C2=A0

What do you think ?=C2=A0

Thx,
R.


--089e013a0c681c115004fec8ef28-- From nobody Tue Jul 22 07:32:55 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780C31B2907 for ; Tue, 22 Jul 2014 07:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhWf_j4uCosx for ; Tue, 22 Jul 2014 07:32:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48AC1B291E for ; Tue, 22 Jul 2014 07:32:44 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5CBAD325B84; Tue, 22 Jul 2014 16:32:43 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3BF6127C0C0; Tue, 22 Jul 2014 16:32:43 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 16:32:43 +0200 From: To: Robert Raszuk Thread-Topic: draft-litkowski-idr-rtc-interas-00 Thread-Index: AQHPpbgtWORGqB9K7kSBfWvCYKN7yZusJ50Q Date: Tue, 22 Jul 2014 14:32:43 +0000 Message-ID: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: 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_9E32478DFA9976438E7A22F69B08FF92044190OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.65720 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/QLi0DNn5YEAoEwTHcX13vwz5VIw Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:32:53 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92044190OPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJIGRvbuKAmXQgcmVhbGx5IHNlZSBob3cgb3JpZ2luYXRvciByZXdyaXRl IGNhbiBoZWxwIGluIHRoaXMg4oCmDQpUaGUgaXNzdWUgaXMgdGhhdCBSUiB0YWtlcyBvbmx5IGJl c3QgcGF0aCBpbnRvIGFjY291bnQgd2hlbiBOTFJJIG9yaWdpbi1BUyBpcyBkaWZmZXJlbnQgZnJv bSBsb2NhbCBBUyB0byBlc3RhYmxpc2ggdGhlIGRpc3RyaWJ1dGlvbiB0cmVlLg0KDQpDb3VsZCB5 b3UgaWxsdXN0cmF0ZSB5b3VyIHByb3Bvc2FsID8NCg0KVGhhbmtzLA0KDQpTdGVwaGFuZQ0KDQoN CkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJl aGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDEwOjIx DQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GDQpDYzogaWRyIHdnDQpTdWJqZWN0OiBk cmFmdC1saXRrb3dza2ktaWRyLXJ0Yy1pbnRlcmFzLTAwDQoNCkhpIFN0ZXBoYW5lLA0KDQpTbyBo b3cgYWJvdXQgd2UgZml4IHRoaXMgaXNzdWUgYnkgZW5hYmxpbmcgb3JpZ25hdG9yIHJld3JpdGUg YnkgUlJzIGZvciBhbGwgcGF0aHMgbm90IG9ubHkgdGhvc2Ugd2hpY2ggYXJlIGxvY2FsID8NCg0K WW91IG1lbnRpb25lZCB0aGUgbmVlZCB0byBiZSBwZXIgQVMgc2VsZWN0aXZlIC4uLiBzdXJlIHRo aXMgYWxzbyBjYW4gYmUga25vYmJlZCBvbiB0aGUgUlIgaWYgcmVxdWlyZWQuDQoNCldoYXQgZG8g eW91IHRoaW5rID8NCg0KVGh4LA0KUi4NCg0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_9E32478DFA9976438E7A22F69B08FF92044190OPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUm9iZXJ0LDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBkb27igJl0IHJlYWxseSBzZWUgaG93IG9yaWdpbmF0b3IgcmV3cml0ZSBjYW4gaGVs cCBpbiB0aGlzIOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgaXNzdWUgaXMg dGhhdCBSUiB0YWtlcyBvbmx5IGJlc3QgcGF0aCBpbnRvIGFjY291bnQgd2hlbiBOTFJJIG9yaWdp bi1BUyBpcyBkaWZmZXJlbnQgZnJvbSBsb2NhbCBBUyB0byBlc3RhYmxpc2ggdGhlIGRpc3RyaWJ1 dGlvbiB0cmVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q291bGQgeW91IGlsbHVzdHJhdGUgeW91ciBwcm9wb3NhbCA/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdGVwaGFuZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVs eSAyMiwgMjAxNCAxMDoyMTxicj4NCjxiPlRvOjwvYj4gTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9J Qk5GPGJyPg0KPGI+Q2M6PC9iPiBpZHIgd2c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gZHJhZnQtbGl0 a293c2tpLWlkci1ydGMtaW50ZXJhcy0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPkhpIFN0ZXBoYW5lLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5TbyBob3cgYWJvdXQgd2UgZml4IHRoaXMgaXNzdWUgYnkgZW5hYmxp bmcgb3JpZ25hdG9yIHJld3JpdGUgYnkgUlJzIGZvciBhbGwgcGF0aHMgbm90IG9ubHkgdGhvc2Ug d2hpY2ggYXJlIGxvY2FsID8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+WW91IG1lbnRpb25lZCB0aGUgbmVlZCB0byBiZSBwZXIgQVMg c2VsZWN0aXZlIC4uLiBzdXJlIHRoaXMgYWxzbyBjYW4gYmUga25vYmJlZCBvbiB0aGUgUlIgaWYg cmVxdWlyZWQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPldoYXQgZG8geW91IHRoaW5rID8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGh4LDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Ui48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K PC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_9E32478DFA9976438E7A22F69B08FF92044190OPEXCLILM34corpor_-- From nobody Tue Jul 22 07:50:34 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EB11B2954 for ; Tue, 22 Jul 2014 07:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1a6rz66h1-v for ; Tue, 22 Jul 2014 07:50:29 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B7F71B293D for ; Tue, 22 Jul 2014 07:50:29 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id tr6so7881173ieb.7 for ; Tue, 22 Jul 2014 07:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tkCKO6zSVeo4NbFUn3FbU4ZH64BbZ6fL8dJvPQv6IuM=; b=u1OL7DbLXUcNb6tTdF6FqHRKiHNDYoxizlAyBoVpqB0qqATCpYAP8U9P3IM8Af7cLG bhi2ft+9JpNP2YgSGWboX+eykte3Q4uGrPbjfWz5wpBs55xbej2agy155fyS0PBRxruE OOxE7bw9tlcUyOCRO/9S7etsgro/CoCQ3+Bi5P4RI1L/oxeXOY4QaLMBC0k4sFnB/6hb Yh7w0H7hI4tI0GbQMf9bXxCLulgfxLlV0QMCOsozLBpBL7lZIR4k7vv91jTDeFpTO3Mt XEwINE5pZhJEXXV5yK7W9IQzZh4clBDGQeJhQwrfgRGqlxOOVQiMzdO1iUDaBiy1uEoe ipLw== MIME-Version: 1.0 X-Received: by 10.42.240.20 with SMTP id ky20mr14957302icb.97.1406040628835; Tue, 22 Jul 2014 07:50:28 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 22 Jul 2014 07:50:28 -0700 (PDT) In-Reply-To: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Tue, 22 Jul 2014 16:50:28 +0200 X-Google-Sender-Auth: f0cbFqLOshGegDxYdymPMkhzBr4 Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=001a113328f238b87b04fec958ae Archived-At: http://mailarchive.ietf.org/arch/msg/idr/7wrlWjxViYOgyotwu49nayT2abc Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:50:30 -0000 --001a113328f238b87b04fec958ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My point is that if RR will reorignate the RTC route it will not be filtered by any of the PEs hence should be propagated between adjucent ASes as sort of "third" path .. resulting in all RTC filters to be propagated and installed properly across. In fact that is the only different I see between two implementations you were referring two :) Best, R. On Tue, Jul 22, 2014 at 4:32 PM, wrote: > Hi Robert, > > > > I don=E2=80=99t really see how originator rewrite can help in this =E2=80= =A6 > > The issue is that RR takes only best path into account when NLRI origin-A= S > is different from local AS to establish the distribution tree. > > > > Could you illustrate your proposal ? > > > > Thanks, > > > > Stephane > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 10:21 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* idr wg > *Subject:* draft-litkowski-idr-rtc-interas-00 > > > > Hi Stephane, > > > > So how about we fix this issue by enabling orignator rewrite by RRs for > all paths not only those which are local ? > > > > You mentioned the need to be per AS selective ... sure this also can be > knobbed on the RR if required. > > > > What do you think ? > > > > Thx, > > R. > > > > > > _________________________________________________________________________= ________________________________________________ > > 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. > > 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. > > --001a113328f238b87b04fec958ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

My point is that if = RR will reorignate the RTC route it will not be filtered by any of the PEs = hence should be propagated between adjucent ASes as sort of "third&quo= t; path .. resulting in all RTC filters to be propagated and installed prop= erly across.=C2=A0

In fact that is the only different I = see between two implementations you were referring two :)

Best,
R.



On Tue, Jul 22, 2014 at 4:32 PM, <stephane.litkowski@orang= e.com> wrote:

Hi Robert,<= /span>

=C2=A0

I don=E2=80=99t really se= e how originator rewrite can help in this =E2=80=A6

The issue is that RR take= s only best path into account when NLRI origin-AS is different from local A= S to establish the distribution tree.

=C2=A0

Could you illustrate your= proposal ?

=C2=A0

Thanks,

=C2=A0

Stephane

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 10:21
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: draft-litkowski-idr-rtc-interas-00

=

=C2=A0

= Hi Stephane,

= =C2=A0

= So how about we fix this issue by enabling orignator rewrite by RRs for all= paths not only those which are local ?=C2=A0

= =C2=A0

= You mentioned the need to be per AS selective ... sure this also can be kno= bbed on the RR if required.=C2=A0

= =C2=A0

= What do you think ?=C2=A0

= =C2=A0

= Thx,

= R.

= =C2=A0

= =C2=A0

______________________________________________________________________=
___________________________________________________

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.

--001a113328f238b87b04fec958ae-- From nobody Tue Jul 22 07:54:28 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBDA1B295C for ; Tue, 22 Jul 2014 07:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Xj3XtwWQwJy for ; Tue, 22 Jul 2014 07:54:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D500B1B2959 for ; Tue, 22 Jul 2014 07:54:18 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 8F3B12DCBEF; Tue, 22 Jul 2014 16:54:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6CBEA35C0D4; Tue, 22 Jul 2014 16:54:17 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 16:54:17 +0200 From: To: Robert Raszuk Thread-Topic: draft-litkowski-idr-rtc-interas-00 Thread-Index: AQHPpbgtWORGqB9K7kSBfWvCYKN7yZusJ50Q///j+QCAACJIIA== Date: Tue, 22 Jul 2014 14:54:16 +0000 Message-ID: <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF920441F7OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.141219 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/2sKF0JoWUGO3VSlICK9GJboFCpo Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:54:21 -0000 --_000_9E32478DFA9976438E7A22F69B08FF920441F7OPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG1tIOKApiB0aGUgaXNzdWUgaXMgbm90IGluIFJUQyBmaWx0ZXIgcHJvcGFnYXRpb24sIGJ1dCBp dCBpcyBvbiBSVEMgZmlsdGVyIHNldHVwIG9uIHRoZSBSUi4gUlIgYXV0aG9yaXplIHJvdXRlIHNl bmRpbmcgVlBOIHJvdXRlcyBvbmx5IHRvIGEgc2luZ2xlIFBFLg0KDQpGcm9tOiBycmFzenVrQGdt YWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJh c3p1aw0KU2VudDogVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMDo1MA0KVG86IExJVEtPV1NLSSBT dGVwaGFuZSBTQ0UvSUJORg0KQ2M6IGlkciB3Zw0KU3ViamVjdDogUmU6IGRyYWZ0LWxpdGtvd3Nr aS1pZHItcnRjLWludGVyYXMtMDANCg0KDQpNeSBwb2ludCBpcyB0aGF0IGlmIFJSIHdpbGwgcmVv cmlnbmF0ZSB0aGUgUlRDIHJvdXRlIGl0IHdpbGwgbm90IGJlIGZpbHRlcmVkIGJ5IGFueSBvZiB0 aGUgUEVzIGhlbmNlIHNob3VsZCBiZSBwcm9wYWdhdGVkIGJldHdlZW4gYWRqdWNlbnQgQVNlcyBh cyBzb3J0IG9mICJ0aGlyZCIgcGF0aCAuLiByZXN1bHRpbmcgaW4gYWxsIFJUQyBmaWx0ZXJzIHRv IGJlIHByb3BhZ2F0ZWQgYW5kIGluc3RhbGxlZCBwcm9wZXJseSBhY3Jvc3MuDQoNCkluIGZhY3Qg dGhhdCBpcyB0aGUgb25seSBkaWZmZXJlbnQgSSBzZWUgYmV0d2VlbiB0d28gaW1wbGVtZW50YXRp b25zIHlvdSB3ZXJlIHJlZmVycmluZyB0d28gOikNCg0KQmVzdCwNClIuDQoNCg0KT24gVHVlLCBK dWwgMjIsIDIwMTQgYXQgNDozMiBQTSwgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1h aWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSGkgUm9iZXJ0LA0K DQpJIGRvbuKAmXQgcmVhbGx5IHNlZSBob3cgb3JpZ2luYXRvciByZXdyaXRlIGNhbiBoZWxwIGlu IHRoaXMg4oCmDQpUaGUgaXNzdWUgaXMgdGhhdCBSUiB0YWtlcyBvbmx5IGJlc3QgcGF0aCBpbnRv IGFjY291bnQgd2hlbiBOTFJJIG9yaWdpbi1BUyBpcyBkaWZmZXJlbnQgZnJvbSBsb2NhbCBBUyB0 byBlc3RhYmxpc2ggdGhlIGRpc3RyaWJ1dGlvbiB0cmVlLg0KDQpDb3VsZCB5b3UgaWxsdXN0cmF0 ZSB5b3VyIHByb3Bvc2FsID8NCg0KVGhhbmtzLA0KDQpTdGVwaGFuZQ0KDQoNCkZyb206IHJyYXN6 dWtAZ21haWwuY29tPG1haWx0bzpycmFzenVrQGdtYWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdt YWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJh c3p1aw0KU2VudDogVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMDoyMQ0KVG86IExJVEtPV1NLSSBT dGVwaGFuZSBTQ0UvSUJORg0KQ2M6IGlkciB3Zw0KU3ViamVjdDogZHJhZnQtbGl0a293c2tpLWlk ci1ydGMtaW50ZXJhcy0wMA0KDQpIaSBTdGVwaGFuZSwNCg0KU28gaG93IGFib3V0IHdlIGZpeCB0 aGlzIGlzc3VlIGJ5IGVuYWJsaW5nIG9yaWduYXRvciByZXdyaXRlIGJ5IFJScyBmb3IgYWxsIHBh dGhzIG5vdCBvbmx5IHRob3NlIHdoaWNoIGFyZSBsb2NhbCA/DQoNCllvdSBtZW50aW9uZWQgdGhl IG5lZWQgdG8gYmUgcGVyIEFTIHNlbGVjdGl2ZSAuLi4gc3VyZSB0aGlzIGFsc28gY2FuIGJlIGtu b2JiZWQgb24gdGhlIFJSIGlmIHJlcXVpcmVkLg0KDQpXaGF0IGRvIHlvdSB0aGluayA/DQoNClRo eCwNClIuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoN CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRo YW5rIHlvdS4NCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_9E32478DFA9976438E7A22F69B08FF920441F7OPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I bW0g4oCmIHRoZSBpc3N1ZSBpcyBub3QgaW4gUlRDIGZpbHRlciBwcm9wYWdhdGlvbiwgYnV0IGl0 IGlzIG9uIFJUQyBmaWx0ZXIgc2V0dXAgb24gdGhlIFJSLiBSUiBhdXRob3JpemUgcm91dGUgc2Vu ZGluZyBWUE4gcm91dGVzIG9ubHkgdG8gYSBzaW5nbGUgUEUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnJh c3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDIyLCAy MDE0IDEwOjUwPGJyPg0KPGI+VG86PC9iPiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY8YnI+ DQo8Yj5DYzo8L2I+IGlkciB3Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogZHJhZnQtbGl0a293 c2tpLWlkci1ydGMtaW50ZXJhcy0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+TXkgcG9pbnQgaXMgdGhhdCBpZiBSUiB3aWxsIHJlb3JpZ25hdGUgdGhlIFJUQyByb3V0 ZSBpdCB3aWxsIG5vdCBiZSBmaWx0ZXJlZCBieSBhbnkgb2YgdGhlIFBFcyBoZW5jZSBzaG91bGQg YmUgcHJvcGFnYXRlZCBiZXR3ZWVuIGFkanVjZW50IEFTZXMgYXMgc29ydCBvZiAmcXVvdDt0aGly ZCZxdW90OyBwYXRoIC4uIHJlc3VsdGluZyBpbiBhbGwgUlRDIGZpbHRlcnMNCiB0byBiZSBwcm9w YWdhdGVkIGFuZCBpbnN0YWxsZWQgcHJvcGVybHkgYWNyb3NzLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JbiBmYWN0IHRoYXQgaXMg dGhlIG9ubHkgZGlmZmVyZW50IEkgc2VlIGJldHdlZW4gdHdvIGltcGxlbWVudGF0aW9ucyB5b3Ug d2VyZSByZWZlcnJpbmcgdHdvIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPkJlc3QsPGJyPg0KUi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBUdWUsIEp1bCAyMiwgMjAxNCBhdCA0OjMyIFBNLCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3Rl cGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUm9iZXJ0LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZ dCByZWFsbHkgc2VlIGhvdyBvcmlnaW5hdG9yIHJld3JpdGUgY2FuIGhlbHAgaW4gdGhpcyDigKY8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgaXNzdWUgaXMgdGhhdCBSUiB0YWtl cyBvbmx5IGJlc3QgcGF0aCBpbnRvIGFjY291bnQgd2hlbiBOTFJJIG9yaWdpbi1BUyBpcyBkaWZm ZXJlbnQgZnJvbSBsb2NhbA0KIEFTIHRvIGVzdGFibGlzaCB0aGUgZGlzdHJpYnV0aW9uIHRyZWUu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Q291bGQgeW91IGlsbHVzdHJhdGUgeW91ciBwcm9wb3NhbCA/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN0ZXBoYW5lPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnJyYXN6dWtAZ21haWwuY29tPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpycmFz enVrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29tPC9hPl0NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5 LCBKdWx5IDIyLCAyMDE0IDEwOjIxPGJyPg0KPGI+VG86PC9iPiBMSVRLT1dTS0kgU3RlcGhhbmUg U0NFL0lCTkY8YnI+DQo8Yj5DYzo8L2I+IGlkciB3Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBkcmFm dC1saXRrb3dza2ktaWRyLXJ0Yy1pbnRlcmFzLTAwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGkgU3RlcGhhbmUsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TbyBob3cgYWJvdXQg d2UgZml4IHRoaXMgaXNzdWUgYnkgZW5hYmxpbmcgb3JpZ25hdG9yIHJld3JpdGUgYnkgUlJzIGZv ciBhbGwgcGF0aHMgbm90IG9ubHkgdGhvc2Ugd2hpY2ggYXJlIGxvY2FsID8mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPllvdSBt ZW50aW9uZWQgdGhlIG5lZWQgdG8gYmUgcGVyIEFTIHNlbGVjdGl2ZSAuLi4gc3VyZSB0aGlzIGFs c28gY2FuIGJlIGtub2JiZWQgb24gdGhlIFJSIGlmIHJlcXVpcmVkLiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2hhdCBkbyB5 b3UgdGhpbmsgPyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+VGh4LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmU+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5 Pg0KPC9odG1sPg0K --_000_9E32478DFA9976438E7A22F69B08FF920441F7OPEXCLILM34corpor_-- From nobody Tue Jul 22 08:01:11 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AB31B288C for ; Tue, 22 Jul 2014 08:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXszJyE3H-N9 for ; Tue, 22 Jul 2014 08:01:06 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C221A0AE5 for ; Tue, 22 Jul 2014 08:01:06 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rl12so8242158iec.15 for ; Tue, 22 Jul 2014 08:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BcSIQGvSJ2/xaeFEMkbpr6mxnI+RP30jzEtsp0TNkCk=; b=y5oksQPiCjlaTKqbvo4Xx8oG8XgTGXhwOMxMtcDoO4X8icuusTTpm9sdYk6WodBGyC Y5DT+zlEuXIHLnoQguhAgv3+x0ql9F0tOoYZkl+V6GbHFkgbFtjFlEor9fbMWjo6TVOH 5B8gItWywpn6D1MSLwOL6hAYjATa7oKtYTYgyKvt0B351Fk6xJPqPkPGeqnyW6cPLZSM 5NNZBjR8+n0stlYiUacFwpwWXWI/RqRLbbn3jeVBml6ZIaee9PEOfUKbVky9ZDrCbcxq F0FpQ2K0VL9GoG/Xgq8J+E9M6pcvoEKz2piX+q4iKId9zZQ91K1GtkGd7NTPJ1at/GMJ BK/Q== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr17257461igb.21.1406041265621; Tue, 22 Jul 2014 08:01:05 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 22 Jul 2014 08:01:05 -0700 (PDT) In-Reply-To: <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Tue, 22 Jul 2014 17:01:05 +0200 X-Google-Sender-Auth: 2OEkH3hl68d-FC_RXJGaXXX6qD0 Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=089e013a0c682d50c904fec97eb1 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ICKuxAWkz_R1J2dmvcl0WqLVqfw Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:01:08 -0000 --089e013a0c682d50c904fec97eb1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well RT filter should be installed on all peers it has been received from regardless what type of RTC route it is. Removing the filter from the peer only based on particular best path chosen seems a bit wrong implementation to me :) The below section: 2. [RFC4684] Section 3.2 : "As indicated above, the inter-AS VPN route distribution graph, for a given route-target, is constructed by creating a directed arc on the inverse direction of received Route Target membership UPDATEs containing an NLRI of the form {origin-as#, route-target}. refers to inter-as behaviour not local RT installation on any BGP speaker within the AS. So if this is your main issue then perhaps we have a bug .... rgs, r. On Tue, Jul 22, 2014 at 4:54 PM, wrote: > Hmm =E2=80=A6 the issue is not in RTC filter propagation, but it is on R= TC > filter setup on the RR. RR authorize route sending VPN routes only to a > single PE. > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 10:50 > > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* idr wg > *Subject:* Re: draft-litkowski-idr-rtc-interas-00 > > > > > > My point is that if RR will reorignate the RTC route it will not be > filtered by any of the PEs hence should be propagated between adjucent AS= es > as sort of "third" path .. resulting in all RTC filters to be propagated > and installed properly across. > > > > In fact that is the only different I see between two implementations you > were referring two :) > > > > Best, > R. > > > > > > On Tue, Jul 22, 2014 at 4:32 PM, wrote: > > Hi Robert, > > > > I don=E2=80=99t really see how originator rewrite can help in this =E2=80= =A6 > > The issue is that RR takes only best path into account when NLRI origin-A= S > is different from local AS to establish the distribution tree. > > > > Could you illustrate your proposal ? > > > > Thanks, > > > > Stephane > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 10:21 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* idr wg > *Subject:* draft-litkowski-idr-rtc-interas-00 > > > > Hi Stephane, > > > > So how about we fix this issue by enabling orignator rewrite by RRs for > all paths not only those which are local ? > > > > You mentioned the need to be per AS selective ... sure this also can be > knobbed on the RR if required. > > > > What do you think ? > > > > Thx, > > R. > > > > > > _________________________________________________________________________= ________________________________________________ > > > > 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. > > > > 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. > > > > _________________________________________________________________________= ________________________________________________ > > 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. > > 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. > > --089e013a0c682d50c904fec97eb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= Well RT filter should be installed on all peers it has been received from r= egardless what type of RTC route it is. Removing the filter from the peer o= nly based on particular best path chosen seems a bit wrong implementation t= o me :)=C2=A0

The below section= :=C2=A0

2. =C2=A0[RF= C4684] Section 3.2 :
=C2=A0 =C2=A0 "As indicated above, the inter-AS VPN route= distribution graph, for a
= =C2=A0 =C2=A0given route-target, is constructed by creating a directed arc = on the
=C2=A0 =C2=A0inverse direction of received Route Target me= mbership UPDATEs
= =C2=A0 =C2=A0containing an NLRI of the form {origin-as#, route-target}.

refers to inter-as beha= viour not local RT installation on any BGP speaker within the AS.=C2=A0
So if this is your main issue then perhaps we have a bug ....= =C2=A0

rgs,
r.=C2=A0



On Tue, Jul 22, 2014 = at 4:54 PM, <stephane.litkowski@orange.com> wro= te:

Hmm =E2=80=A6 the issue i= s not in RTC filter propagation, but it is on RTC filter setup on the RR. R= R authorize route sending VPN routes only to a single PE.

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 10:50


To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: Re: draft-litkowski-idr-rtc-interas-00<= p>

=C2=A0

= =C2=A0

= My point is that if RR will reorignate the RTC route it will not be filtere= d by any of the PEs hence should be propagated between adjucent ASes as sor= t of "third" path .. resulting in all RTC filters to be propagated and installed properly across.=C2=A0=

= =C2=A0

= In fact that is the only different I see between two implementations you we= re referring two :)

= =C2=A0

= Best,
R.

= =C2=A0

=C2=A0<= /p>

On Tue, Jul 22, 2014 at 4:32 PM, <stephane.litkowski@oran= ge.com> wrote:

Hi Robert,<= u>

=C2=A0

I don=E2=80=99t really se= e how originator rewrite can help in this =E2=80=A6

The issue is that RR take= s only best path into account when NLRI origin-AS is different from local AS to establish the distribution tree.

=C2=A0

Could you illustrate your= proposal ?

=C2=A0

Thanks,<= /u>

=C2=A0

Stephane=

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 10:21
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: draft-litkowski-idr-rtc-interas-00

=C2=A0

= Hi Stephane,

= =C2=A0

= So how about we fix this issue by enabling orignator rewrite by RRs for all= paths not only those which are local ?=C2=A0

= =C2=A0

= You mentioned the need to be per AS selective ... sure this also can be kno= bbed on the RR if required.=C2=A0

= =C2=A0

= What do you think ?=C2=A0

= =C2=A0

= Thx,

= R.

= =C2=A0

= =C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


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.

=C2=A0

______________________________________________________________________=
___________________________________________________

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.

--089e013a0c682d50c904fec97eb1-- From nobody Tue Jul 22 08:13:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB44A1B28F9 for ; Tue, 22 Jul 2014 08:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVZV3A-IDsF7 for ; Tue, 22 Jul 2014 08:13:43 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 58A8D1B2947 for ; Tue, 22 Jul 2014 08:13:16 -0700 (PDT) Received: (qmail 22739 invoked by uid 0); 22 Jul 2014 15:13:15 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy3.mail.unifiedlayer.com with SMTP; 22 Jul 2014 15:13:15 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id VZD21o00A2SSUrH01ZD5tC; Tue, 22 Jul 2014 15:13:13 -0600 X-Authority-Analysis: v=2.1 cv=fudPOjIf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=WrhVjQHxoPwA:10 a=kf37zU_6G9oA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7vxqMSo7eprhtSn_gi4A:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=PAuchj7jOgCiagMaHEcK2VoJ1irFWmUazXi8cMUL3KM=; b=O4LAzcqWjnpZJJVdKLmOsPBZa4iHxG7BQ9XGkLI47TlcGPqOoHG7cDdGObYsuBtuSgCXNNFRgp2It+BL+vNozx7Kdg6ht6vNNPrARJEX8W5i/Q9YKI0B7Y6RFVosihr5; Received: from box313.bluehost.com ([69.89.31.113]:40084 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X9bkV-0005HT-GY; Tue, 22 Jul 2014 09:13:03 -0600 Message-ID: <53CE7F8A.1090700@labn.net> Date: Tue, 22 Jul 2014 11:13:14 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: draft-li-idr-mpls-path-programming@tools.ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/idr/QEQQuR2gPLfzeW4fRvdFXnPeFD0 Cc: idr@ietf.org Subject: [Idr] Question from session on draft-xli-idr-mpls-path-programming X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:13:44 -0000 Hi, Since we weren't able to close this in the session, I thought I'd ask my question here. The question was simply what is supposed to happen (from a service model perspective) when requested tunnel setup, or for that matter, any other type of 'path programming' fails? The text in the draft that caught my eye is: This document defines the following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | reserved |S| +-+-+-+-+-+-+-+-+ + Unicast Tunnel Setup Required (S) If the S flag is not set, the client node is just to map the service path to the corresponding tunnel. If the S flag is set, the client node MUST set up the tunnel according to the tunnel identifier and the tunnel specific attribute firstly. Then it maps the service path to the corresponding tunnel. Thanks, Lou From nobody Tue Jul 22 08:14:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911C21B28E0 for ; Tue, 22 Jul 2014 08:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwgtszpnI1IG for ; Tue, 22 Jul 2014 08:14:34 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5791B2960 for ; Tue, 22 Jul 2014 08:14:33 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id rp18so8198155iec.12 for ; Tue, 22 Jul 2014 08:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=Mf9d57PfkrpvgcSyjnfARoj+xHqEv8XTqTU6hWYKatU=; b=cJl2ux50uCsRDrUHo7QGSEUnImeyB2WlfVRZVQuA+OZMBdHoyAtGJK83NevEO2xHax R6YIcPRGHZgB+zxOsEZwdLNZ42E5uXoy61abdFwg+fJIHaK13tjZrLenATcPUnv0ISBJ n4nTYRpGWINQHj6X15vYyVq+pCoIeQFkFvo/mVT3GlfAAfLwNrDPVUmzj7mavi2EytFR 7ptbH6JTmDcWX5DpGWFXBsBswis8AeZk3aEU86sh+hTw69wTunx6NCvu55u1i+Z7nszs WCXkP0OISurZczlzKYV3SnDJo/BRATBegMMNP5mo0PKx4VKUHV9WAWbqR3O7YIuyP1F7 tirQ== MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr17848909igx.9.1406042072947; Tue, 22 Jul 2014 08:14:32 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 22 Jul 2014 08:14:32 -0700 (PDT) Date: Tue, 22 Jul 2014 17:14:32 +0200 X-Google-Sender-Auth: 9ZSol9no71QPgJh6kxCwgoUeJfE Message-ID: From: Robert Raszuk To: "" , Jeffrey Haas Content-Type: multipart/alternative; boundary=089e0122a7544c238804fec9ae37 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/TUAjkUVQQafUV3AtVLEhUuchLD8 Cc: idr wg Subject: [Idr] draft-litkowski-idr-rtc-interas X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:14:35 -0000 --089e0122a7544c238804fec9ae37 Content-Type: text/plain; charset=UTF-8 Stephane, I have one fundamental question on this ... You have focused on making sure that BGP control plane works fast and solid etc. That is great and timestamp idea at each BGP hop would help. However let's observe that BGP control plane is NOT congruent with data plane. In other words you may have a case where someone may have slow and overloaded RR but uses 40 GB pipes for data plane while other AS installed super-hyper x86 RRs and has 1 GB links for data plane. Your results may actually in the above case casue more problems then gains unfortunately. The possible simple fix is to mandate that timestamp is ONLY added when your change next hop to self or that you can have a new flag "N" - Next Hop Set which will help a lot to make more use cases for this proposal. Best, R. --089e0122a7544c238804fec9ae37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephane,

I have one fundamental question on this ...

You have focused on making sure that BGP control plane works fast and solid= etc. That is great and timestamp idea at each BGP hop would help.=C2=A0

However let's observe that BGP control plane is= NOT congruent with data plane. In other words you may have a case where so= meone may have slow and overloaded RR but uses 40 GB pipes for data plane w= hile other AS installed super-hyper x86 RRs and has 1 GB links for data pla= ne.=C2=A0

Your results may actually in the abov= e case casue more problems then gains unfortunately.=C2=A0

The possible simple fix is to mandate= that timestamp is ONLY added when your change next hop to self or that you= can have a new flag "N" - Next Hop Set which will help a lot to = make more use cases for this proposal.=C2=A0

Best,
R.



--089e0122a7544c238804fec9ae37-- From nobody Tue Jul 22 11:55:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103001B2BCF for ; Tue, 22 Jul 2014 11:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0Cw7X-B3_f1 for ; Tue, 22 Jul 2014 11:55:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CEC1B2BBC for ; Tue, 22 Jul 2014 11:55:44 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2AEA022E1D9; Tue, 22 Jul 2014 20:55:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0ED2C238055; Tue, 22 Jul 2014 20:55:42 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 20:55:42 +0200 From: To: Robert Raszuk Thread-Topic: draft-litkowski-idr-rtc-interas-00 Thread-Index: AQHPpbgtWORGqB9K7kSBfWvCYKN7yZusJ50Q///j+QCAACJIIP//4K+AgABhvnA= Date: Tue, 22 Jul 2014 18:55:41 +0000 Message-ID: <5637_1406055342_53CEB3AE_5637_4357_1_9E32478DFA9976438E7A22F69B08FF92044393@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92044393OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.141219 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/c41p1XpCJyBP6yc81vVxEiooDhw Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:55:47 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92044393OPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGVyZSBpcyBubyBjb25zZW5zdXMgb24gdGhpcyByZWFkaW5nIG9mIHRoZSBSRkMu DQoNCkVzcGVjaWFsbHkgSmVmZiBhbmQgSm9obiBhbHJlYWR5IHJlcGxpZWQgb24gdGhlIGxpc3Qg dGhhdCBSVCBmaWx0ZXIgaXMgb25seSBpbnN0YWxsZWQgdG8gYmVzdCBwYXRoIHBlZXIuIEkgd291 bGQgdGVuZCB0byBhZ3JlZSB3aXRoIHRoZWlyIHJlYWRpbmcgb2YgdGhlIFJGQy4NCg0KDQpGcm9t OiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYg T2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMTowMQ0KVG86 IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORg0KQ2M6IGlkciB3Zw0KU3ViamVjdDogUmU6IGRy YWZ0LWxpdGtvd3NraS1pZHItcnRjLWludGVyYXMtMDANCg0KDQpXZWxsIFJUIGZpbHRlciBzaG91 bGQgYmUgaW5zdGFsbGVkIG9uIGFsbCBwZWVycyBpdCBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIHJl Z2FyZGxlc3Mgd2hhdCB0eXBlIG9mIFJUQyByb3V0ZSBpdCBpcy4gUmVtb3ZpbmcgdGhlIGZpbHRl ciBmcm9tIHRoZSBwZWVyIG9ubHkgYmFzZWQgb24gcGFydGljdWxhciBiZXN0IHBhdGggY2hvc2Vu IHNlZW1zIGEgYml0IHdyb25nIGltcGxlbWVudGF0aW9uIHRvIG1lIDopDQoNClRoZSBiZWxvdyBz ZWN0aW9uOg0KDQoyLiAgW1JGQzQ2ODRdIFNlY3Rpb24gMy4yIDoNCg0KICAgICJBcyBpbmRpY2F0 ZWQgYWJvdmUsIHRoZSBpbnRlci1BUyBWUE4gcm91dGUgZGlzdHJpYnV0aW9uIGdyYXBoLCBmb3Ig YQ0KICAgZ2l2ZW4gcm91dGUtdGFyZ2V0LCBpcyBjb25zdHJ1Y3RlZCBieSBjcmVhdGluZyBhIGRp cmVjdGVkIGFyYyBvbiB0aGUNCiAgIGludmVyc2UgZGlyZWN0aW9uIG9mIHJlY2VpdmVkIFJvdXRl IFRhcmdldCBtZW1iZXJzaGlwIFVQREFURXMNCiAgIGNvbnRhaW5pbmcgYW4gTkxSSSBvZiB0aGUg Zm9ybSB7b3JpZ2luLWFzIywgcm91dGUtdGFyZ2V0fS4NCg0KcmVmZXJzIHRvIGludGVyLWFzIGJl aGF2aW91ciBub3QgbG9jYWwgUlQgaW5zdGFsbGF0aW9uIG9uIGFueSBCR1Agc3BlYWtlciB3aXRo aW4gdGhlIEFTLg0KDQpTbyBpZiB0aGlzIGlzIHlvdXIgbWFpbiBpc3N1ZSB0aGVuIHBlcmhhcHMg d2UgaGF2ZSBhIGJ1ZyAuLi4uDQoNCnJncywNCnIuDQoNCg0KT24gVHVlLCBKdWwgMjIsIDIwMTQg YXQgNDo1NCBQTSwgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFu ZS5saXRrb3dza2lAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSG1tIOKApiB0aGUgaXNzdWUgaXMgbm90 IGluIFJUQyBmaWx0ZXIgcHJvcGFnYXRpb24sIGJ1dCBpdCBpcyBvbiBSVEMgZmlsdGVyIHNldHVw IG9uIHRoZSBSUi4gUlIgYXV0aG9yaXplIHJvdXRlIHNlbmRpbmcgVlBOIHJvdXRlcyBvbmx5IHRv IGEgc2luZ2xlIFBFLg0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0Bn bWFpbC5jb20+IFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwu Y29tPl0gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjIs IDIwMTQgMTA6NTANCg0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORg0KQ2M6IGlkciB3 Zw0KU3ViamVjdDogUmU6IGRyYWZ0LWxpdGtvd3NraS1pZHItcnRjLWludGVyYXMtMDANCg0KDQpN eSBwb2ludCBpcyB0aGF0IGlmIFJSIHdpbGwgcmVvcmlnbmF0ZSB0aGUgUlRDIHJvdXRlIGl0IHdp bGwgbm90IGJlIGZpbHRlcmVkIGJ5IGFueSBvZiB0aGUgUEVzIGhlbmNlIHNob3VsZCBiZSBwcm9w YWdhdGVkIGJldHdlZW4gYWRqdWNlbnQgQVNlcyBhcyBzb3J0IG9mICJ0aGlyZCIgcGF0aCAuLiBy ZXN1bHRpbmcgaW4gYWxsIFJUQyBmaWx0ZXJzIHRvIGJlIHByb3BhZ2F0ZWQgYW5kIGluc3RhbGxl ZCBwcm9wZXJseSBhY3Jvc3MuDQoNCkluIGZhY3QgdGhhdCBpcyB0aGUgb25seSBkaWZmZXJlbnQg SSBzZWUgYmV0d2VlbiB0d28gaW1wbGVtZW50YXRpb25zIHlvdSB3ZXJlIHJlZmVycmluZyB0d28g OikNCg0KQmVzdCwNClIuDQoNCg0KT24gVHVlLCBKdWwgMjIsIDIwMTQgYXQgNDozMiBQTSwgPHN0 ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3Jh bmdlLmNvbT4+IHdyb3RlOg0KSGkgUm9iZXJ0LA0KDQpJIGRvbuKAmXQgcmVhbGx5IHNlZSBob3cg b3JpZ2luYXRvciByZXdyaXRlIGNhbiBoZWxwIGluIHRoaXMg4oCmDQpUaGUgaXNzdWUgaXMgdGhh dCBSUiB0YWtlcyBvbmx5IGJlc3QgcGF0aCBpbnRvIGFjY291bnQgd2hlbiBOTFJJIG9yaWdpbi1B UyBpcyBkaWZmZXJlbnQgZnJvbSBsb2NhbCBBUyB0byBlc3RhYmxpc2ggdGhlIGRpc3RyaWJ1dGlv biB0cmVlLg0KDQpDb3VsZCB5b3UgaWxsdXN0cmF0ZSB5b3VyIHByb3Bvc2FsID8NCg0KVGhhbmtz LA0KDQpTdGVwaGFuZQ0KDQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tPG1haWx0bzpycmFzenVr QGdtYWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFp bC5jb20+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogVHVlc2RheSwgSnVseSAy MiwgMjAxNCAxMDoyMQ0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORg0KQ2M6IGlkciB3 Zw0KU3ViamVjdDogZHJhZnQtbGl0a293c2tpLWlkci1ydGMtaW50ZXJhcy0wMA0KDQpIaSBTdGVw aGFuZSwNCg0KU28gaG93IGFib3V0IHdlIGZpeCB0aGlzIGlzc3VlIGJ5IGVuYWJsaW5nIG9yaWdu YXRvciByZXdyaXRlIGJ5IFJScyBmb3IgYWxsIHBhdGhzIG5vdCBvbmx5IHRob3NlIHdoaWNoIGFy ZSBsb2NhbCA/DQoNCllvdSBtZW50aW9uZWQgdGhlIG5lZWQgdG8gYmUgcGVyIEFTIHNlbGVjdGl2 ZSAuLi4gc3VyZSB0aGlzIGFsc28gY2FuIGJlIGtub2JiZWQgb24gdGhlIFJSIGlmIHJlcXVpcmVk Lg0KDQpXaGF0IGRvIHlvdSB0aGluayA/DQoNClRoeCwNClIuDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0K DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0K DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91LgoK --_000_9E32478DFA9976438E7A22F69B08FF92044393OPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhlcmUgaXMgbm8gY29uc2Vuc3VzIG9u IHRoaXMgcmVhZGluZyBvZiB0aGUgUkZDLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Fc3BlY2lhbGx5IEplZmYgYW5k IEpvaG4gYWxyZWFkeSByZXBsaWVkIG9uIHRoZSBsaXN0IHRoYXQgUlQgZmlsdGVyIGlzIG9ubHkg aW5zdGFsbGVkIHRvIGJlc3QgcGF0aCBwZWVyLiBJIHdvdWxkIHRlbmQgdG8gYWdyZWUgd2l0aCB0 aGVpciByZWFkaW5nIG9mIHRoZSBSRkMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJh c3p1a0BnbWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMTowMTxicj4NCjxiPlRvOjwvYj4g TElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GPGJyPg0KPGI+Q2M6PC9iPiBpZHIgd2c8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IGRyYWZ0LWxpdGtvd3NraS1pZHItcnRjLWludGVyYXMtMDA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldlbGwgUlQgZmlsdGVyIHNob3Vs ZCBiZSBpbnN0YWxsZWQgb24gYWxsIHBlZXJzIGl0IGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gcmVn YXJkbGVzcyB3aGF0IHR5cGUgb2YgUlRDIHJvdXRlIGl0IGlzLiBSZW1vdmluZyB0aGUgZmlsdGVy IGZyb20gdGhlIHBlZXIgb25seSBiYXNlZCBvbiBwYXJ0aWN1bGFyIGJlc3QgcGF0aCBjaG9zZW4g c2VlbXMNCiBhIGJpdCB3cm9uZyBpbXBsZW1lbnRhdGlvbiB0byBtZSA6KSZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgYmVsb3cg c2VjdGlvbjombmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjIuICZuYnNwO1tSRkM0Njg0XSBTZWN0aW9uIDMuMiA6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAm bmJzcDsgJnF1b3Q7QXMgaW5kaWNhdGVkIGFib3ZlLCB0aGUgaW50ZXItQVMgVlBOIHJvdXRlIGRp c3RyaWJ1dGlvbiBncmFwaCwgZm9yIGE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDtnaXZlbiByb3V0ZS10YXJnZXQsIGlzIGNv bnN0cnVjdGVkIGJ5IGNyZWF0aW5nIGEgZGlyZWN0ZWQgYXJjIG9uIHRoZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO2ludmVy c2UgZGlyZWN0aW9uIG9mIHJlY2VpdmVkIFJvdXRlIFRhcmdldCBtZW1iZXJzaGlwIFVQREFURXM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyAmbmJzcDtjb250YWluaW5nIGFuIE5MUkkgb2YgdGhlIGZvcm0ge29yaWdpbi1hcyMsIHJvdXRl LXRhcmdldH0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPnJlZmVycyB0byBpbnRlci1hcyBiZWhhdmlvdXIgbm90IGxvY2FsIFJUIGluc3RhbGxh dGlvbiBvbiBhbnkgQkdQIHNwZWFrZXIgd2l0aGluIHRoZSBBUy4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U28gaWYgdGhpcyBpcyB5 b3VyIG1haW4gaXNzdWUgdGhlbiBwZXJoYXBzIHdlIGhhdmUgYSBidWcgLi4uLiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5yZ3MsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5yLiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwg MjIsIDIwMTQgYXQgNDo1NCBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRrb3dz a2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2Uu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkhtbSDigKYgdGhlIGlzc3VlIGlzIG5vdCBpbiBSVEMgZmlsdGVyIHByb3BhZ2F0aW9uLCBidXQg aXQgaXMgb24gUlRDIGZpbHRlciBzZXR1cCBvbiB0aGUgUlIuIFJSIGF1dGhvcml6ZQ0KIHJvdXRl IHNlbmRpbmcgVlBOIHJvdXRlcyBvbmx5IHRvIGEgc2luZ2xlIFBFLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0Bn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT4gW21haWx0bzo8 YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVr QGdtYWlsLmNvbTwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMDo1MDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5Ubzo8L2I+IExJVEtP V1NLSSBTdGVwaGFuZSBTQ0UvSUJORjxicj4NCjxiPkNjOjwvYj4gaWRyIHdnPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPlN1YmplY3Q6PC9iPiBSZTogZHJh ZnQtbGl0a293c2tpLWlkci1ydGMtaW50ZXJhcy0wMDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk15IHBvaW50IGlzIHRoYXQgaWYgUlIgd2lsbCBy ZW9yaWduYXRlIHRoZSBSVEMgcm91dGUgaXQgd2lsbCBub3QgYmUgZmlsdGVyZWQgYnkgYW55IG9m IHRoZSBQRXMgaGVuY2Ugc2hvdWxkIGJlIHByb3BhZ2F0ZWQgYmV0d2VlbiBhZGp1Y2VudA0KIEFT ZXMgYXMgc29ydCBvZiAmcXVvdDt0aGlyZCZxdW90OyBwYXRoIC4uIHJlc3VsdGluZyBpbiBhbGwg UlRDIGZpbHRlcnMgdG8gYmUgcHJvcGFnYXRlZCBhbmQgaW5zdGFsbGVkIHByb3Blcmx5IGFjcm9z cy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPkluIGZhY3QgdGhhdCBpcyB0aGUgb25seSBkaWZmZXJlbnQgSSBzZWUgYmV0d2Vl biB0d28gaW1wbGVtZW50YXRpb25zIHlvdSB3ZXJlIHJlZmVycmluZyB0d28gOik8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3QsPGJy Pg0KUi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gVHVlLCBKdWwgMjIsIDIwMTQgYXQgNDozMiBQTSwgJmx0OzxhIGhyZWY9 Im1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0 ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJvYmVydCw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKA mXQgcmVhbGx5IHNlZSBob3cgb3JpZ2luYXRvciByZXdyaXRlIGNhbiBoZWxwIGluIHRoaXMg4oCm PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGlzc3VlIGlzIHRoYXQgUlIgdGFr ZXMgb25seSBiZXN0IHBhdGggaW50byBhY2NvdW50IHdoZW4gTkxSSSBvcmlnaW4tQVMgaXMgZGlm ZmVyZW50IGZyb20gbG9jYWwNCiBBUyB0byBlc3RhYmxpc2ggdGhlIGRpc3RyaWJ1dGlvbiB0cmVl Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkNvdWxkIHlvdSBpbGx1c3RyYXRlIHlvdXIgcHJvcG9zYWwgPzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdGVwaGFuZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnJh c3p1a0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh eSwgSnVseSAyMiwgMjAxNCAxMDoyMTxicj4NCjxiPlRvOjwvYj4gTElUS09XU0tJIFN0ZXBoYW5l IFNDRS9JQk5GPGJyPg0KPGI+Q2M6PC9iPiBpZHIgd2c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gZHJh ZnQtbGl0a293c2tpLWlkci1ydGMtaW50ZXJhcy0wMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhpIFN0ZXBoYW5lLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U28gaG93IGFib3V0 IHdlIGZpeCB0aGlzIGlzc3VlIGJ5IGVuYWJsaW5nIG9yaWduYXRvciByZXdyaXRlIGJ5IFJScyBm b3IgYWxsIHBhdGhzIG5vdCBvbmx5IHRob3NlIHdoaWNoIGFyZSBsb2NhbCA/Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Zb3Ug bWVudGlvbmVkIHRoZSBuZWVkIHRvIGJlIHBlciBBUyBzZWxlY3RpdmUgLi4uIHN1cmUgdGhpcyBh bHNvIGNhbiBiZSBrbm9iYmVkIG9uIHRoZSBSUiBpZiByZXF1aXJlZC4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldoYXQgZG8g eW91IHRoaW5rID8mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPlRoeCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Ui48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cHJlPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48 L286cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286 cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286 cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJl Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHBy ZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmU+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jPG86cD48L286cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFuayB5b3Uu PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBS RT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_9E32478DFA9976438E7A22F69B08FF92044393OPEXCLILM34corpor_-- From nobody Tue Jul 22 12:03:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0791A00DB for ; Tue, 22 Jul 2014 12:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2qphy7dXDKv for ; Tue, 22 Jul 2014 12:03:53 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0981A004A for ; Tue, 22 Jul 2014 12:03:52 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id at20so76551iec.8 for ; Tue, 22 Jul 2014 12:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vsaRONCFfoWDgkgbolhdPxD8RqKlfOgffGxx0YG1yFY=; b=rGvgsmKCJDPPlpfzzg9xUqzeAGTFQtLskRfT6dFpBoIlPS6DTW9y/uSyMHxtPGs2RH 4qnWS8nxcVAllstXKsQahhQx3MuleC9YVKjzKwK2rXnamBnCelEdYC+x0mhppTJRUJMj GUOEFyTJoKLMxJirQ0zmG/I4YqgEhy2a0oNZ6t+5x4a0RoAGcaMJPRlJMQe/G3cbwdRN CYvLWTis0shlDU+3o1w1QLuCnhIlHJiaO61mnyRK0TAeJ3sfVsl9MVrX9T2zOcx//YkI gXBCLEFhGR1dNWHAXfvMXxXNhv14x5SdaZNkfyNrdqLE1oGIrqSyYeA7Az6noISpPuqZ Cj5w== MIME-Version: 1.0 X-Received: by 10.42.240.20 with SMTP id ky20mr16871538icb.97.1406055832114; Tue, 22 Jul 2014 12:03:52 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 22 Jul 2014 12:03:52 -0700 (PDT) In-Reply-To: <5637_1406055342_53CEB3AE_5637_4357_1_9E32478DFA9976438E7A22F69B08FF92044393@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> <5637_1406055342_53CEB3AE_5637_4357_1_9E32478DFA9976438E7A22F69B08FF92044393@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Tue, 22 Jul 2014 21:03:52 +0200 X-Google-Sender-Auth: 3scCfUQ3EW0Mf2cRtSjPnZaXe3A Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=001a113328f2685a9204fecce259 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/YeyRb9p8AtjMuHbROxH0883NtRs Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:03:54 -0000 --001a113328f2685a9204fecce259 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Well I would tend to disagree. The reasons are that fast connectivity restoration requires presence of multiple VPN paths. And that is both intra and inter-as. If peer asks for routes with given RT it should get those routes. Regardless of what RTC best path is I am going to send further. Otherwise many things will break really bad. Best, r. On Tue, Jul 22, 2014 at 8:55 PM, wrote: > I think there is no consensus on this reading of the RFC. > > > > Especially Jeff and John already replied on the list that RT filter is > only installed to best path peer. I would tend to agree with their readin= g > of the RFC. > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 11:01 > > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* idr wg > *Subject:* Re: draft-litkowski-idr-rtc-interas-00 > > > > > > Well RT filter should be installed on all peers it has been received from > regardless what type of RTC route it is. Removing the filter from the pee= r > only based on particular best path chosen seems a bit wrong implementatio= n > to me :) > > > > The below section: > > > > 2. [RFC4684] Section 3.2 : > > > > "As indicated above, the inter-AS VPN route distribution graph, for a > > given route-target, is constructed by creating a directed arc on the > > inverse direction of received Route Target membership UPDATEs > > containing an NLRI of the form {origin-as#, route-target}. > > > > refers to inter-as behaviour not local RT installation on any BGP speaker > within the AS. > > > > So if this is your main issue then perhaps we have a bug .... > > > > rgs, > > r. > > > > > > On Tue, Jul 22, 2014 at 4:54 PM, wrote: > > Hmm =E2=80=A6 the issue is not in RTC filter propagation, but it is on RT= C filter > setup on the RR. RR authorize route sending VPN routes only to a single P= E. > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 10:50 > > > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* idr wg > > *Subject:* Re: draft-litkowski-idr-rtc-interas-00 > > > > > > My point is that if RR will reorignate the RTC route it will not be > filtered by any of the PEs hence should be propagated between adjucent AS= es > as sort of "third" path .. resulting in all RTC filters to be propagated > and installed properly across. > > > > In fact that is the only different I see between two implementations you > were referring two :) > > > > Best, > R. > > > > > > On Tue, Jul 22, 2014 at 4:32 PM, wrote: > > Hi Robert, > > > > I don=E2=80=99t really see how originator rewrite can help in this =E2=80= =A6 > > The issue is that RR takes only best path into account when NLRI origin-A= S > is different from local AS to establish the distribution tree. > > > > Could you illustrate your proposal ? > > > > Thanks, > > > > Stephane > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 10:21 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* idr wg > *Subject:* draft-litkowski-idr-rtc-interas-00 > > > > Hi Stephane, > > > > So how about we fix this issue by enabling orignator rewrite by RRs for > all paths not only those which are local ? > > > > You mentioned the need to be per AS selective ... sure this also can be > knobbed on the RR if required. > > > > What do you think ? > > > > Thx, > > R. > > > > > > _________________________________________________________________________= ________________________________________________ > > > > 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. > > > > 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. > > > > _________________________________________________________________________= ________________________________________________ > > > > 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. > > > > 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. > > > > _________________________________________________________________________= ________________________________________________ > > 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. > > 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. > > --001a113328f2685a9204fecce259 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Well I would tend to disagree.=C2=A0

The reasons are that fast connectivity restoration requires presence o= f multiple VPN paths.=C2=A0

And that is both intra and inter-as.= =C2=A0

If peer asks for routes with given RT= it should get those routes. Regardless of what RTC best path is I am going= to send further.=C2=A0

Otherwise many things will break real= ly bad.

Best,
r.




On Tue, Jul 22, 2014 at 8:55 PM, <stephane.litkowski@orange.com> wrote:

I think there is no conse= nsus on this reading of the RFC.

=C2=A0

Especially Jeff and John = already replied on the list that RT filter is only installed to best path p= eer. I would tend to agree with their reading of the RFC.<= /u>

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 11:01

=
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: Re: draft-litkowski-idr-rtc-interas-00
<= /div>

=C2=A0

= =C2=A0

= Well RT filter should be installed on all peers it has been received from r= egardless what type of RTC route it is. Removing the filter from the peer o= nly based on particular best path chosen seems a bit wrong implementation to me :)=C2=A0

= =C2=A0

= The below section:=C2=A0

= =C2=A0

= 2. =C2=A0[RFC4684] Section 3.2 :

=C2=A0

= =C2=A0 =C2=A0 "As indicated above, the inter-AS VPN route distribution= graph, for a

= =C2=A0 =C2=A0given route-target, is constructed by creating a directed arc = on the

= =C2=A0 =C2=A0inverse direction of received Route Target membership UPDATEs<= /span>

= =C2=A0 =C2=A0containing an NLRI of the form {origin-as#, route-target}.

=C2=A0

= refers to inter-as behaviour not local RT installation on any BGP speaker w= ithin the AS.=C2=A0

=C2=A0

= So if this is your main issue then perhaps we have a bug ....=C2=A0<= u>

=C2=A0

= rgs,

= r.=C2=A0

=C2=A0

=C2=A0<= /p>

On Tue, Jul 22, 2014 at 4:54 PM, <stephane.litkowski@oran= ge.com> wrote:

Hmm =E2=80=A6 the issue i= s not in RTC filter propagation, but it is on RTC filter setup on the RR. R= R authorize route sending VPN routes only to a single PE.

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 10:50


To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg

Subject: Re: draft-litkowski-idr-rtc-interas-= 00

=C2=A0

= =C2=A0

= My point is that if RR will reorignate the RTC route it will not be filtere= d by any of the PEs hence should be propagated between adjucent ASes as sort of "third" path .. resulting in all RTC filters to = be propagated and installed properly across.=C2=A0

= =C2=A0

= In fact that is the only different I see between two implementations you we= re referring two :)

= =C2=A0

= Best,
R.

= =C2=A0

=C2=A0<= /p>

On Tue, Jul 22, 2014 at 4:32 PM, <stephane.litkowski@oran= ge.com> wrote:

Hi Robert,<= u>

=C2=A0

I don=E2=80=99t really se= e how originator rewrite can help in this =E2=80=A6

The issue is that RR take= s only best path into account when NLRI origin-AS is different from local AS to establish the distribution tree.

=C2=A0

Could you illustrate your= proposal ?

=C2=A0

Thanks,<= /u>

=C2=A0

Stephane=

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 10:21
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: draft-litkowski-idr-rtc-interas-00

=C2=A0

= Hi Stephane,

= =C2=A0

= So how about we fix this issue by enabling orignator rewrite by RRs for all= paths not only those which are local ?=C2=A0

= =C2=A0

= You mentioned the need to be per AS selective ... sure this also can be kno= bbed on the RR if required.=C2=A0

= =C2=A0

= What do you think ?=C2=A0

= =C2=A0

= Thx,

= R.

= =C2=A0

= =C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


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.

=C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


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.

=C2=A0

______________________________________________________________________=
___________________________________________________

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.

--001a113328f2685a9204fecce259-- From nobody Tue Jul 22 12:11:19 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C871A0127 for ; Tue, 22 Jul 2014 12:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Gkhji7qmRXS for ; Tue, 22 Jul 2014 12:11:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B7B1A034F for ; Tue, 22 Jul 2014 12:11:13 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 05FC11B95A0; Tue, 22 Jul 2014 21:11:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id DA649384049; Tue, 22 Jul 2014 21:11:11 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 21:11:12 +0200 From: To: Robert Raszuk Thread-Topic: draft-litkowski-idr-rtc-interas-00 Thread-Index: AQHPpbgtWORGqB9K7kSBfWvCYKN7yZusJ50Q///j+QCAACJIIP//4K+AgABhvnD//+IYAAAEOa2Q Date: Tue, 22 Jul 2014 19:11:10 +0000 Message-ID: <11537_1406056272_53CEB74F_11537_4854_1_9E32478DFA9976438E7A22F69B08FF920443EE@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> <5637_1406055342_53CEB3AE_5637_4357_1_9E32478DFA9976438E7A22F69B08FF92044393@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF920443EEOPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.180021 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/zky-TameTR6_nF5plNk1dEnZfKM Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:11:18 -0000 --_000_9E32478DFA9976438E7A22F69B08FF920443EEOPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhIHBvc2l0aW9uIHRoYXQgSSBjYW5ub3QgZ28gYWdhaW5zdCDimLoNCkJ1dCBhbnl3 YXkgYXMgZXZlcnl0aW1lIHdpdGggQkdQICwgdGhlcmUgaXMgdHdvIHdheSA6DQoNCi0gICAgICAg ICAgTGltaXRpbmcgbnVtYmVyIG9mIHBhdGhzIHN0YXRlcyBhbmQgc28gZGVsYXlpbmcgY29udmVy Z2VuY2UNCg0KLSAgICAgICAgICBBdWdtZW50aW5nIG51bWJlciBvZiBwYXRocyBzdGF0ZXMgKEFE RCBQQVRILCBiZXN0IGV4dGVybmFsIOKApiksIHRvIHNwZWVkIHVwIGNvbnZlcmdlbmNlLg0KDQpG cm9tIGEgZGVzaWduIHBvaW50IG9mIHZpZXcsIChpdOKAmXMgbXkgcGVyc29uYWwgcG9zaXRpb24s IEkgd2FzIG5vdCBpbnZvbHZlZCBpbiBSVEMgaW5pdGlhbCBkaXNjdXNzaW9uKSwgSSB3b3VsZCB0 ZW5kIHRvIHNheSB0aGF0IFJUQyBtdXN0IGJ5IGRlZmF1bHQgcHJvdmlkZSB0aGUgbW9yZSBlZmZp Y2llbnQgcm91dGUgZGlzdHJpYnV0aW9uIChsaW1pdGluZyBhcyBtdWNoIGFzIHBvc3NpYmxlIHN0 YXRlcykuIEJ1dCB5ZXMsIEkgYWdyZWUgdGhhdCBpZiB0aGVyZSBpcyBhIG5lZWQgb2YgZmFzdGNv bnZlcmdlbmNlIHlvdSBtYXkgd2FudCB0byBkaXNhYmxlIHBhdGggcHJ1bmluZy4NCg0KSSBrbm93 IGZyb20gcHJpdmF0ZSBkaXNjdXNzaW9uIHdpdGggS2V5dXIgdGhhdCBoZSBzaGFyZXMgYWxzbyB5 b3VyIHBvaW50IG9mIHZpZXcuDQoNCk1heWJlIHRoZSBmaXJzdCBzdGVwIGJlZm9yZSBkaXNjdXNz aW5nIGFib3V0IGEgc29sdXRpb24gd291bGQgYmUgdG8gYWdyZWUgb24gd2hhdCBpcyB0aGUgZXhw ZWN0ZWQgYmVoYXZpb3Igb2YgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbi4gSXQgc2VlbXMgdGhh dCB0aGVyZSBpcyBubyBjb25zZW5zdXMgb24gdGhlIHJlYWRpbmcgb2YgdGhlIFJGQzQ2ODQuDQoN Cg0KRnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24g QmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQgMTU6 MDQNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYNCkNjOiBpZHIgd2cNClN1YmplY3Q6 IFJlOiBkcmFmdC1saXRrb3dza2ktaWRyLXJ0Yy1pbnRlcmFzLTAwDQoNCkhpLA0KDQpXZWxsIEkg d291bGQgdGVuZCB0byBkaXNhZ3JlZS4NCg0KVGhlIHJlYXNvbnMgYXJlIHRoYXQgZmFzdCBjb25u ZWN0aXZpdHkgcmVzdG9yYXRpb24gcmVxdWlyZXMgcHJlc2VuY2Ugb2YgbXVsdGlwbGUgVlBOIHBh dGhzLg0KDQpBbmQgdGhhdCBpcyBib3RoIGludHJhIGFuZCBpbnRlci1hcy4NCg0KSWYgcGVlciBh c2tzIGZvciByb3V0ZXMgd2l0aCBnaXZlbiBSVCBpdCBzaG91bGQgZ2V0IHRob3NlIHJvdXRlcy4g UmVnYXJkbGVzcyBvZiB3aGF0IFJUQyBiZXN0IHBhdGggaXMgSSBhbSBnb2luZyB0byBzZW5kIGZ1 cnRoZXIuDQoNCk90aGVyd2lzZSBtYW55IHRoaW5ncyB3aWxsIGJyZWFrIHJlYWxseSBiYWQuDQoN CkJlc3QsDQpyLg0KDQoNCg0KT24gVHVlLCBKdWwgMjIsIDIwMTQgYXQgODo1NSBQTSwgPHN0ZXBo YW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3Jhbmdl LmNvbT4+IHdyb3RlOg0KSSB0aGluayB0aGVyZSBpcyBubyBjb25zZW5zdXMgb24gdGhpcyByZWFk aW5nIG9mIHRoZSBSRkMuDQoNCkVzcGVjaWFsbHkgSmVmZiBhbmQgSm9obiBhbHJlYWR5IHJlcGxp ZWQgb24gdGhlIGxpc3QgdGhhdCBSVCBmaWx0ZXIgaXMgb25seSBpbnN0YWxsZWQgdG8gYmVzdCBw YXRoIHBlZXIuIEkgd291bGQgdGVuZCB0byBhZ3JlZSB3aXRoIHRoZWlyIHJlYWRpbmcgb2YgdGhl IFJGQy4NCg0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5j b20+IFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPl0g T24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQg MTE6MDENCg0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORg0KQ2M6IGlkciB3Zw0KU3Vi amVjdDogUmU6IGRyYWZ0LWxpdGtvd3NraS1pZHItcnRjLWludGVyYXMtMDANCg0KDQpXZWxsIFJU IGZpbHRlciBzaG91bGQgYmUgaW5zdGFsbGVkIG9uIGFsbCBwZWVycyBpdCBoYXMgYmVlbiByZWNl aXZlZCBmcm9tIHJlZ2FyZGxlc3Mgd2hhdCB0eXBlIG9mIFJUQyByb3V0ZSBpdCBpcy4gUmVtb3Zp bmcgdGhlIGZpbHRlciBmcm9tIHRoZSBwZWVyIG9ubHkgYmFzZWQgb24gcGFydGljdWxhciBiZXN0 IHBhdGggY2hvc2VuIHNlZW1zIGEgYml0IHdyb25nIGltcGxlbWVudGF0aW9uIHRvIG1lIDopDQoN ClRoZSBiZWxvdyBzZWN0aW9uOg0KDQoyLiAgW1JGQzQ2ODRdIFNlY3Rpb24gMy4yIDoNCg0KICAg ICJBcyBpbmRpY2F0ZWQgYWJvdmUsIHRoZSBpbnRlci1BUyBWUE4gcm91dGUgZGlzdHJpYnV0aW9u IGdyYXBoLCBmb3IgYQ0KICAgZ2l2ZW4gcm91dGUtdGFyZ2V0LCBpcyBjb25zdHJ1Y3RlZCBieSBj cmVhdGluZyBhIGRpcmVjdGVkIGFyYyBvbiB0aGUNCiAgIGludmVyc2UgZGlyZWN0aW9uIG9mIHJl Y2VpdmVkIFJvdXRlIFRhcmdldCBtZW1iZXJzaGlwIFVQREFURXMNCiAgIGNvbnRhaW5pbmcgYW4g TkxSSSBvZiB0aGUgZm9ybSB7b3JpZ2luLWFzIywgcm91dGUtdGFyZ2V0fS4NCg0KcmVmZXJzIHRv IGludGVyLWFzIGJlaGF2aW91ciBub3QgbG9jYWwgUlQgaW5zdGFsbGF0aW9uIG9uIGFueSBCR1Ag c3BlYWtlciB3aXRoaW4gdGhlIEFTLg0KDQpTbyBpZiB0aGlzIGlzIHlvdXIgbWFpbiBpc3N1ZSB0 aGVuIHBlcmhhcHMgd2UgaGF2ZSBhIGJ1ZyAuLi4uDQoNCnJncywNCnIuDQoNCg0KT24gVHVlLCBK dWwgMjIsIDIwMTQgYXQgNDo1NCBQTSwgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1h aWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSG1tIOKApiB0aGUg aXNzdWUgaXMgbm90IGluIFJUQyBmaWx0ZXIgcHJvcGFnYXRpb24sIGJ1dCBpdCBpcyBvbiBSVEMg ZmlsdGVyIHNldHVwIG9uIHRoZSBSUi4gUlIgYXV0aG9yaXplIHJvdXRlIHNlbmRpbmcgVlBOIHJv dXRlcyBvbmx5IHRvIGEgc2luZ2xlIFBFLg0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbTxtYWls dG86cnJhc3p1a0BnbWFpbC5jb20+IFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJy YXN6dWtAZ21haWwuY29tPl0gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFR1ZXNk YXksIEp1bHkgMjIsIDIwMTQgMTA6NTANCg0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJO Rg0KQ2M6IGlkciB3Zw0KU3ViamVjdDogUmU6IGRyYWZ0LWxpdGtvd3NraS1pZHItcnRjLWludGVy YXMtMDANCg0KDQpNeSBwb2ludCBpcyB0aGF0IGlmIFJSIHdpbGwgcmVvcmlnbmF0ZSB0aGUgUlRD IHJvdXRlIGl0IHdpbGwgbm90IGJlIGZpbHRlcmVkIGJ5IGFueSBvZiB0aGUgUEVzIGhlbmNlIHNo b3VsZCBiZSBwcm9wYWdhdGVkIGJldHdlZW4gYWRqdWNlbnQgQVNlcyBhcyBzb3J0IG9mICJ0aGly ZCIgcGF0aCAuLiByZXN1bHRpbmcgaW4gYWxsIFJUQyBmaWx0ZXJzIHRvIGJlIHByb3BhZ2F0ZWQg YW5kIGluc3RhbGxlZCBwcm9wZXJseSBhY3Jvc3MuDQoNCkluIGZhY3QgdGhhdCBpcyB0aGUgb25s eSBkaWZmZXJlbnQgSSBzZWUgYmV0d2VlbiB0d28gaW1wbGVtZW50YXRpb25zIHlvdSB3ZXJlIHJl ZmVycmluZyB0d28gOikNCg0KQmVzdCwNClIuDQoNCg0KT24gVHVlLCBKdWwgMjIsIDIwMTQgYXQg NDozMiBQTSwgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSGkgUm9iZXJ0LA0KDQpJIGRvbuKAmXQgcmVh bGx5IHNlZSBob3cgb3JpZ2luYXRvciByZXdyaXRlIGNhbiBoZWxwIGluIHRoaXMg4oCmDQpUaGUg aXNzdWUgaXMgdGhhdCBSUiB0YWtlcyBvbmx5IGJlc3QgcGF0aCBpbnRvIGFjY291bnQgd2hlbiBO TFJJIG9yaWdpbi1BUyBpcyBkaWZmZXJlbnQgZnJvbSBsb2NhbCBBUyB0byBlc3RhYmxpc2ggdGhl IGRpc3RyaWJ1dGlvbiB0cmVlLg0KDQpDb3VsZCB5b3UgaWxsdXN0cmF0ZSB5b3VyIHByb3Bvc2Fs ID8NCg0KVGhhbmtzLA0KDQpTdGVwaGFuZQ0KDQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tPG1h aWx0bzpycmFzenVrQGdtYWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86 cnJhc3p1a0BnbWFpbC5jb20+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogVHVl c2RheSwgSnVseSAyMiwgMjAxNCAxMDoyMQ0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJO Rg0KQ2M6IGlkciB3Zw0KU3ViamVjdDogZHJhZnQtbGl0a293c2tpLWlkci1ydGMtaW50ZXJhcy0w MA0KDQpIaSBTdGVwaGFuZSwNCg0KU28gaG93IGFib3V0IHdlIGZpeCB0aGlzIGlzc3VlIGJ5IGVu YWJsaW5nIG9yaWduYXRvciByZXdyaXRlIGJ5IFJScyBmb3IgYWxsIHBhdGhzIG5vdCBvbmx5IHRo b3NlIHdoaWNoIGFyZSBsb2NhbCA/DQoNCllvdSBtZW50aW9uZWQgdGhlIG5lZWQgdG8gYmUgcGVy IEFTIHNlbGVjdGl2ZSAuLi4gc3VyZSB0aGlzIGFsc28gY2FuIGJlIGtub2JiZWQgb24gdGhlIFJS IGlmIHJlcXVpcmVkLg0KDQpXaGF0IGRvIHlvdSB0aGluayA/DQoNClRoeCwNClIuDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4KVGhhbmsgeW91LgoK --_000_9E32478DFA9976438E7A22F69B08FF920443EEOPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBh cmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDo4NDc4MzkyODA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0NzQwMzk5NDggLTU2NzQ5MzM3NiA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJbXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGlzIGEgcG9zaXRpb24gdGhh dCBJIGNhbm5vdCBnbyBhZ2FpbnN0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5CdXQgYW55d2F5IGFzIGV2ZXJ5dGltZSB3aXRoIEJHUCAsIHRoZXJlIGlzIHR3byB3 YXkgOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpbWl0aW5nIG51bWJl ciBvZiBwYXRocyBzdGF0ZXMgYW5kIHNvIGRlbGF5aW5nIGNvbnZlcmdlbmNlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXVnbWVudGluZyBudW1iZXIgb2YgcGF0aHMgc3Rh dGVzIChBREQgUEFUSCwgYmVzdCBleHRlcm5hbCDigKYpLCB0byBzcGVlZCB1cCBjb252ZXJnZW5j ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkZyb20gYSBkZXNpZ24gcG9pbnQgb2YgdmlldywgKGl04oCZcyBteSBwZXJz b25hbCBwb3NpdGlvbiwgSSB3YXMgbm90IGludm9sdmVkIGluIFJUQyBpbml0aWFsIGRpc2N1c3Np b24pLCBJIHdvdWxkIHRlbmQgdG8gc2F5IHRoYXQgUlRDIG11c3QgYnkgZGVmYXVsdCBwcm92aWRl DQogdGhlIG1vcmUgZWZmaWNpZW50IHJvdXRlIGRpc3RyaWJ1dGlvbiAobGltaXRpbmcgYXMgbXVj aCBhcyBwb3NzaWJsZSBzdGF0ZXMpLiBCdXQgeWVzLCBJIGFncmVlIHRoYXQgaWYgdGhlcmUgaXMg YSBuZWVkIG9mIGZhc3Rjb252ZXJnZW5jZSB5b3UgbWF5IHdhbnQgdG8gZGlzYWJsZSBwYXRoIHBy dW5pbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JIGtub3cgZnJvbSBwcml2YXRlIGRpc2N1c3Npb24gd2l0aCBLZXl1 ciB0aGF0IGhlIHNoYXJlcyBhbHNvIHlvdXIgcG9pbnQgb2Ygdmlldy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1heWJl IHRoZSBmaXJzdCBzdGVwIGJlZm9yZSBkaXNjdXNzaW5nIGFib3V0IGEgc29sdXRpb24gd291bGQg YmUgdG8gYWdyZWUgb24gd2hhdCBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3Igb2YgdGhlIGN1cnJl bnQgc3BlY2lmaWNhdGlvbi4gSXQgc2VlbXMgdGhhdCB0aGVyZQ0KIGlzIG5vIGNvbnNlbnN1cyBv biB0aGUgcmVhZGluZyBvZiB0aGUgUkZDNDY4NC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBycmFz enVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMjIsIDIw MTQgMTU6MDQ8YnI+DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjxicj4N CjxiPkNjOjwvYj4gaWRyIHdnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBkcmFmdC1saXRrb3dz a2ktaWRyLXJ0Yy1pbnRlcmFzLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPldlbGwgSSB3b3VsZCB0ZW5kIHRvIGRpc2FncmVlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgcmVhc29ucyBhcmUgdGhh dCBmYXN0IGNvbm5lY3Rpdml0eSByZXN0b3JhdGlvbiByZXF1aXJlcyBwcmVzZW5jZSBvZiBtdWx0 aXBsZSBWUE4gcGF0aHMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPkFuZCB0aGF0IGlzIGJvdGggaW50cmEgYW5kIGludGVyLWFzLiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5JZiBwZWVyIGFza3MgZm9yIHJvdXRlcyB3aXRoIGdpdmVuIFJUIGl0IHNob3VsZCBnZXQgdGhv c2Ugcm91dGVzLiBSZWdhcmRsZXNzIG9mIHdoYXQgUlRDIGJlc3QgcGF0aCBpcyBJIGFtIGdvaW5n IHRvIHNlbmQgZnVydGhlci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+T3RoZXJ3aXNlIG1hbnkgdGhpbmdzIHdpbGwgYnJlYWsgcmVh bGx5IGJhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+QmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPnIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1 bCAyMiwgMjAxNCBhdCA4OjU1IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtv d3NraUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSB0aGluayB0aGVyZSBpcyBubyBjb25zZW5zdXMgb24gdGhpcyByZWFkaW5nIG9mIHRoZSBS RkMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Fc3BlY2lhbGx5IEplZmYgYW5kIEpvaG4gYWxyZWFkeSByZXBs aWVkIG9uIHRoZSBsaXN0IHRoYXQgUlQgZmlsdGVyIGlzIG9ubHkgaW5zdGFsbGVkIHRvIGJlc3Qg cGF0aA0KIHBlZXIuIEkgd291bGQgdGVuZCB0byBhZ3JlZSB3aXRoIHRoZWlyIHJlYWRpbmcgb2Yg dGhlIFJGQy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29tPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpy cmFzenVrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29tPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBKdWx5IDIyLCAyMDE0IDExOjAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBTdGVw aGFuZSBTQ0UvSUJORjxicj4NCjxiPkNjOjwvYj4gaWRyIHdnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBkcmFmdC1saXRrb3dza2ktaWRyLXJ0Yy1pbnRlcmFzLTAwPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldlbGwg UlQgZmlsdGVyIHNob3VsZCBiZSBpbnN0YWxsZWQgb24gYWxsIHBlZXJzIGl0IGhhcyBiZWVuIHJl Y2VpdmVkIGZyb20gcmVnYXJkbGVzcyB3aGF0IHR5cGUgb2YgUlRDIHJvdXRlIGl0IGlzLiBSZW1v dmluZyB0aGUgZmlsdGVyIGZyb20NCiB0aGUgcGVlciBvbmx5IGJhc2VkIG9uIHBhcnRpY3VsYXIg YmVzdCBwYXRoIGNob3NlbiBzZWVtcyBhIGJpdCB3cm9uZyBpbXBsZW1lbnRhdGlvbiB0byBtZSA6 KSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+VGhlIGJlbG93IHNlY3Rpb246Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Mi4gJm5ic3A7W1JGQzQ2 ODRdIFNlY3Rpb24gMy4yIDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7QXMgaW5kaWNhdGVkIGFib3Zl LCB0aGUgaW50ZXItQVMgVlBOIHJvdXRlIGRpc3RyaWJ1dGlvbiBncmFwaCwgZm9yIGE8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZu YnNwO2dpdmVuIHJvdXRlLXRhcmdldCwgaXMgY29uc3RydWN0ZWQgYnkgY3JlYXRpbmcgYSBkaXJl Y3RlZCBhcmMgb24gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDtpbnZlcnNlIGRpcmVjdGlvbiBvZiByZWNlaXZlZCBS b3V0ZSBUYXJnZXQgbWVtYmVyc2hpcCBVUERBVEVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDtjb250YWluaW5nIGFuIE5M Ukkgb2YgdGhlIGZvcm0ge29yaWdpbi1hcyMsIHJvdXRlLXRhcmdldH0uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5yZWZlcnMgdG8gaW50 ZXItYXMgYmVoYXZpb3VyIG5vdCBsb2NhbCBSVCBpbnN0YWxsYXRpb24gb24gYW55IEJHUCBzcGVh a2VyIHdpdGhpbiB0aGUgQVMuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TbyBpZiB0aGlzIGlzIHlvdXIgbWFpbiBpc3N1ZSB0 aGVuIHBlcmhhcHMgd2UgaGF2ZSBhIGJ1ZyAuLi4uJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5yZ3MsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnIuJm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gVHVlLCBKdWwgMjIsIDIwMTQgYXQgNDo1NCBQTSwgJmx0OzxhIGhyZWY9Im1haWx0 bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhtbSDigKYgdGhlIGlzc3VlIGlzIG5vdCBpbiBSVEMgZmlsdGVy IHByb3BhZ2F0aW9uLCBidXQgaXQgaXMgb24gUlRDIGZpbHRlciBzZXR1cCBvbiB0aGUgUlIuIFJS IGF1dGhvcml6ZQ0KIHJvdXRlIHNlbmRpbmcgVlBOIHJvdXRlcyBvbmx5IHRvIGEgc2luZ2xlIFBF Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVm PSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWls LmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJv YmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMDo1 MDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi cj4NCjxiPlRvOjwvYj4gTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GPGJyPg0KPGI+Q2M6PC9i PiBpZHIgd2c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj5TdWJqZWN0OjwvYj4gUmU6IGRyYWZ0LWxpdGtvd3NraS1pZHItcnRjLWludGVyYXMtMDA8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NeSBwb2lu dCBpcyB0aGF0IGlmIFJSIHdpbGwgcmVvcmlnbmF0ZSB0aGUgUlRDIHJvdXRlIGl0IHdpbGwgbm90 IGJlIGZpbHRlcmVkIGJ5IGFueSBvZiB0aGUgUEVzIGhlbmNlIHNob3VsZCBiZSBwcm9wYWdhdGVk IGJldHdlZW4gYWRqdWNlbnQNCiBBU2VzIGFzIHNvcnQgb2YgJnF1b3Q7dGhpcmQmcXVvdDsgcGF0 aCAuLiByZXN1bHRpbmcgaW4gYWxsIFJUQyBmaWx0ZXJzIHRvIGJlIHByb3BhZ2F0ZWQgYW5kIGlu c3RhbGxlZCBwcm9wZXJseSBhY3Jvc3MuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JbiBmYWN0IHRoYXQgaXMgdGhlIG9ubHkg ZGlmZmVyZW50IEkgc2VlIGJldHdlZW4gdHdvIGltcGxlbWVudGF0aW9ucyB5b3Ugd2VyZSByZWZl cnJpbmcgdHdvIDopPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5CZXN0LDxicj4NClIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0 IDQ6MzIgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5j b20iIHRhcmdldD0iX2JsYW5rIj5zdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb2JlcnQs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHJlYWxseSBzZWUgaG93IG9yaWdpbmF0b3IgcmV3cml0 ZSBjYW4gaGVscCBpbiB0aGlzIOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo ZSBpc3N1ZSBpcyB0aGF0IFJSIHRha2VzIG9ubHkgYmVzdCBwYXRoIGludG8gYWNjb3VudCB3aGVu IE5MUkkgb3JpZ2luLUFTIGlzIGRpZmZlcmVudCBmcm9tIGxvY2FsDQogQVMgdG8gZXN0YWJsaXNo IHRoZSBkaXN0cmlidXRpb24gdHJlZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db3VsZCB5b3UgaWxsdXN0cmF0 ZSB5b3VyIHByb3Bvc2FsID88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3Rl cGhhbmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOnJyYXN6 dWtAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cnJhc3p1a0BnbWFpbC5jb208L2E+IFttYWls dG86PGEgaHJlZj0ibWFpbHRvOnJyYXN6dWtAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cnJh c3p1a0BnbWFpbC5jb208L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQgMTA6MjE8YnI+DQo8Yj5Ubzo8 L2I+IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjxicj4NCjxiPkNjOjwvYj4gaWRyIHdnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IGRyYWZ0LWxpdGtvd3NraS1pZHItcnRjLWludGVyYXMtMDA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5IaSBT dGVwaGFuZSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPlNvIGhvdyBhYm91dCB3ZSBmaXggdGhpcyBpc3N1ZSBieSBlbmFibGluZyBvcmln bmF0b3IgcmV3cml0ZSBieSBSUnMgZm9yIGFsbCBwYXRocyBub3Qgb25seSB0aG9zZSB3aGljaCBh cmUgbG9jYWwgPyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+WW91IG1lbnRpb25lZCB0aGUgbmVlZCB0byBiZSBwZXIgQVMgc2Vs ZWN0aXZlIC4uLiBzdXJlIHRoaXMgYWxzbyBjYW4gYmUga25vYmJlZCBvbiB0aGUgUlIgaWYgcmVx dWlyZWQuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5XaGF0IGRvIHlvdSB0aGluayA/Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaHgsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlIuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFu ayB5b3UuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5P cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48 L3ByZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHByZT5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jPG86cD48L286cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFuayB5b3UuPG86 cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_9E32478DFA9976438E7A22F69B08FF920443EEOPEXCLILM34corpor_-- From nobody Tue Jul 22 12:17:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFDE1A02EC for ; Tue, 22 Jul 2014 12:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf1Om32j4BEv for ; Tue, 22 Jul 2014 12:17:43 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C798C1A0035 for ; Tue, 22 Jul 2014 12:17:42 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id hn18so596376igb.4 for ; Tue, 22 Jul 2014 12:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tBjv/LYFrjeAbNSjILnCa5i1eXL7TB/WlY+rpQ4G50g=; b=AtNL0XA8G+tGglX13/uT7SqHobcwEgAFZG8EPUZSzNPIX5lhs74L/8D9cVSb76KOn/ JBWOozxYWrob4eGRmXzldlXuza7dbcKOhiQIEaBQ1sutMQDycNoznpjmpzGZ2a4hWMP+ 6/sQW+EZn+j5cMXQ7nW0uIOJD2yUCXo/BW1iS22bMrArEnCyenJqm1RJrZmXDcYM4UH4 cJOzH76rGipm0fojZSaw2l/cwPCRxykaBImXoXppJTCOvw5nZFlCxPX8DQK+rzNW3A0Q dXt9Oy9Of8EM9JJolwHKpKLYDM9uZ1QOHa/+YEyidKBCyFsABZFya553W8qYiA8gqcwq IA3A== MIME-Version: 1.0 X-Received: by 10.42.154.132 with SMTP id q4mr25320236icw.4.1406056662103; Tue, 22 Jul 2014 12:17:42 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 22 Jul 2014 12:17:42 -0700 (PDT) In-Reply-To: <11537_1406056272_53CEB74F_11537_4854_1_9E32478DFA9976438E7A22F69B08FF920443EE@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> <5637_1406055342_53CEB3AE_5637_4357_1_9E32478DFA9976438E7A22F69B08FF92044393@OPEXCLILM34.corporate.adroot.infra.ftgroup> <11537_1406056272_53CEB74F_11537_4854_1_9E32478DFA9976438E7A22F69B08FF920443EE@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Tue, 22 Jul 2014 21:17:42 +0200 X-Google-Sender-Auth: IMEWh6vqfnox6Z81XLqEy8Fs3VY Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=90e6ba6e87a6e0fbec04fecd1383 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/KLdpZR0XobWbthHiO_-zgogrgsc Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:17:45 -0000 --90e6ba6e87a6e0fbec04fecd1383 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, >From a design point of view, (it=E2=80=99s my personal position, I was not = involved in RTC initial discussion), I would tend to say that RTC must by default provide the more efficient route distribution (limiting as much as possible states). Well as I was involved from day one with Pedro on the RTC design the main goal was not to limit states "as much as possible". The main goal was not to send information where there is no use for it. As a side effect yes you limit the state but no more then you should. RTC can't be used to kill redundancy and that should not really be negotiable. If you would follow that model for intra-as and only install locally originated RT routes on RR for one PE of multihomed site one PE would not get VPN routes it is asking for. Same for ASBRs of dual connected AS. In fact during my last project one vendor added ebgp multipath for RTC as it was not implemented day one :) Best, R. On Tue, Jul 22, 2014 at 9:11 PM, wrote: > This is a position that I cannot go against J > > But anyway as everytime with BGP , there is two way : > > - Limiting number of paths states and so delaying convergence > > - Augmenting number of paths states (ADD PATH, best external =E2= =80=A6), > to speed up convergence. > > > > From a design point of view, (it=E2=80=99s my personal position, I was no= t > involved in RTC initial discussion), I would tend to say that RTC must by > default provide the more efficient route distribution (limiting as much a= s > possible states). But yes, I agree that if there is a need of > fastconvergence you may want to disable path pruning. > > > > I know from private discussion with Keyur that he shares also your point > of view. > > > > Maybe the first step before discussing about a solution would be to agree > on what is the expected behavior of the current specification. It seems > that there is no consensus on the reading of the RFC4684. > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 15:04 > > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* idr wg > *Subject:* Re: draft-litkowski-idr-rtc-interas-00 > > > > Hi, > > > > Well I would tend to disagree. > > > > The reasons are that fast connectivity restoration requires presence of > multiple VPN paths. > > > > And that is both intra and inter-as. > > > > If peer asks for routes with given RT it should get those routes. > Regardless of what RTC best path is I am going to send further. > > > > Otherwise many things will break really bad. > > > > Best, > > r. > > > > > > > > On Tue, Jul 22, 2014 at 8:55 PM, wrote: > > I think there is no consensus on this reading of the RFC. > > > > Especially Jeff and John already replied on the list that RT filter is > only installed to best path peer. I would tend to agree with their readin= g > of the RFC. > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 11:01 > > > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* idr wg > *Subject:* Re: draft-litkowski-idr-rtc-interas-00 > > > > > > Well RT filter should be installed on all peers it has been received from > regardless what type of RTC route it is. Removing the filter from the pee= r > only based on particular best path chosen seems a bit wrong implementatio= n > to me :) > > > > The below section: > > > > 2. [RFC4684] Section 3.2 : > > > > "As indicated above, the inter-AS VPN route distribution graph, for a > > given route-target, is constructed by creating a directed arc on the > > inverse direction of received Route Target membership UPDATEs > > containing an NLRI of the form {origin-as#, route-target}. > > > > refers to inter-as behaviour not local RT installation on any BGP speaker > within the AS. > > > > So if this is your main issue then perhaps we have a bug .... > > > > rgs, > > r. > > > > > > On Tue, Jul 22, 2014 at 4:54 PM, wrote: > > Hmm =E2=80=A6 the issue is not in RTC filter propagation, but it is on RT= C filter > setup on the RR. RR authorize route sending VPN routes only to a single P= E. > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 10:50 > > > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* idr wg > > *Subject:* Re: draft-litkowski-idr-rtc-interas-00 > > > > > > My point is that if RR will reorignate the RTC route it will not be > filtered by any of the PEs hence should be propagated between adjucent AS= es > as sort of "third" path .. resulting in all RTC filters to be propagated > and installed properly across. > > > > In fact that is the only different I see between two implementations you > were referring two :) > > > > Best, > R. > > > > > > On Tue, Jul 22, 2014 at 4:32 PM, wrote: > > Hi Robert, > > > > I don=E2=80=99t really see how originator rewrite can help in this =E2=80= =A6 > > The issue is that RR takes only best path into account when NLRI origin-A= S > is different from local AS to establish the distribution tree. > > > > Could you illustrate your proposal ? > > > > Thanks, > > > > Stephane > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 10:21 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* idr wg > *Subject:* draft-litkowski-idr-rtc-interas-00 > > > > Hi Stephane, > > > > So how about we fix this issue by enabling orignator rewrite by RRs for > all paths not only those which are local ? > > > > You mentioned the need to be per AS selective ... sure this also can be > knobbed on the RR if required. > > > > What do you think ? > > > > Thx, > > R. > > > > > > _________________________________________________________________________= ________________________________________________ > > > > 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. > > > > 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. > > > > _________________________________________________________________________= ________________________________________________ > > > > 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. > > > > 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. > > > > _________________________________________________________________________= ________________________________________________ > > > > 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. > > > > 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. > > > > _________________________________________________________________________= ________________________________________________ > > 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. > > 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. > > --90e6ba6e87a6e0fbec04fecd1383 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
<= br>
From a design point of view, (it=E2=80=99s = my personal position, I was not involved in RTC initial discussion), I woul= d tend to say that RTC must by default provide the more efficient route dis= tribution (limiting as much as possible states).

Well as I = was involved from day one with Pedro on the RTC design the main goal was no= t to limit states "as much as possible".=C2=A0

The main goal was= not to send information where there is no use for it. As a side effect yes= you limit the state but no more then you should.=C2=A0

RTC can't be = used to kill redundancy and that should not really be negotiable.=C2=A0

If you would foll= ow that model for intra-as and only install locally originated RT routes on= RR for one PE of multihomed site one PE would not get VPN routes it is ask= ing for. Same for ASBRs of dual connected AS.=C2=A0

In fact during my= last project one vendor added ebgp multipath for RTC as it was not impleme= nted day one :)

Best,
R.

















=
On Tue, Jul 22, 2014 at 9:11 PM, <stephane.litkowski@orange.com> wrote:

This is a position that I cannot go against J

But anyway as everytime with BGP , there is = two way :

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Limiting number of paths states and so = delaying convergence

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Augmenting number of paths states (ADD = PATH, best external =E2=80=A6), to speed up convergence.

=C2=A0

From a design point of view, (it=E2=80=99s m= y personal position, I was not involved in RTC initial discussion), I would= tend to say that RTC must by default provide the more efficient route distribution (limiting as much as possible states= ). But yes, I agree that if there is a need of fastconvergence you may want= to disable path pruning.

=C2=A0

I know from private discussion with Keyur th= at he shares also your point of view.

=C2=A0

Maybe the first step before discussing about= a solution would be to agree on what is the expected behavior of the curre= nt specification. It seems that there is no consensus on the reading of the RFC4684.

=C2=A0

=C2=A0

From: rrasz= uk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 15:04

=
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: Re: draft-litkowski-idr-rtc-interas-00
<= /div>

=C2=A0

Hi= ,

=C2=A0

We= ll I would tend to disagree.=C2=A0

=C2=A0

Th= e reasons are that fast connectivity restoration requires presence of multi= ple VPN paths.=C2=A0

=C2=A0

An= d that is both intra and inter-as.=C2=A0

=C2=A0

If= peer asks for routes with given RT it should get those routes. Regardless = of what RTC best path is I am going to send further.=C2=A0

=C2=A0

Ot= herwise many things will break really bad.

=C2=A0

Be= st,

r.=

=C2=A0

=C2=A0

=C2=A0

On Tue, Jul 22, 2014 at 8:55 PM, <stephane.litkowski@oran= ge.com> wrote:

I think there is no consensus on this readin= g of the RFC.

=C2=A0

Especially Jeff and John already replied on = the list that RT filter is only installed to best path peer. I would tend to agree with their reading of the RFC.

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 11:01


To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: Re: draft-litkowski-idr-rtc-interas-00

=C2=A0

= =C2=A0

We= ll RT filter should be installed on all peers it has been received from reg= ardless what type of RTC route it is. Removing the filter from the peer only based on particular best path chosen seems a bit wrong imple= mentation to me :)=C2=A0

= =C2=A0

Th= e below section:=C2=A0

= =C2=A0

2.= =C2=A0[RFC4684] Section 3.2 :

=C2=A0

= =C2=A0 =C2=A0 "As indicated above, the inter-AS VPN route distribution= graph, for a

= =C2=A0 =C2=A0given route-target, is constructed by creating a directed arc = on the

= =C2=A0 =C2=A0inverse direction of received Route Target membership UPDATEs<= /span>

= =C2=A0 =C2=A0containing an NLRI of the form {origin-as#, route-target}.

=C2=A0

re= fers to inter-as behaviour not local RT installation on any BGP speaker wit= hin the AS.=C2=A0

=C2=A0

So= if this is your main issue then perhaps we have a bug ....=C2=A0=

=C2=A0

rg= s,

r.= =C2=A0

=C2=A0

=C2=A0

On Tue, Jul 22, 2014 at 4:54 PM, <stephane.litkowski@oran= ge.com> wrote:

Hmm =E2=80=A6 the issue is not in RTC filter= propagation, but it is on RTC filter setup on the RR. RR authorize route sending VPN routes only to a single PE.

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 10:50


To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg

Subject: Re: draft-litkowski-idr-rtc-interas-= 00

=C2=A0

= =C2=A0

My= point is that if RR will reorignate the RTC route it will not be filtered = by any of the PEs hence should be propagated between adjucent ASes as sort of "third" path .. resulting in all RTC filters to = be propagated and installed properly across.=C2=A0

= =C2=A0

In= fact that is the only different I see between two implementations you were= referring two :)

= =C2=A0

Be= st,
R.

= =C2=A0

=C2=A0

On Tue, Jul 22, 2014 at 4:32 PM, <stephane.litkowski@oran= ge.com> wrote:

Hi Robert,

=C2=A0

I don=E2=80=99t really see how originator re= write can help in this =E2=80=A6

The issue is that RR takes only best path in= to account when NLRI origin-AS is different from local AS to establish the distribution tree.

=C2=A0

Could you illustrate your proposal ?<= u>

=C2=A0

Thanks,

=C2=A0

Stephane

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 10:21
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: draft-litkowski-idr-rtc-interas-00

=C2=A0

Hi= Stephane,

= =C2=A0

So= how about we fix this issue by enabling orignator rewrite by RRs for all p= aths not only those which are local ?=C2=A0

= =C2=A0

Yo= u mentioned the need to be per AS selective ... sure this also can be knobb= ed on the RR if required.=C2=A0

= =C2=A0

Wh= at do you think ?=C2=A0

= =C2=A0

Th= x,

R.=

= =C2=A0

= =C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


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.

=C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


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.

=C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


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.

=C2=A0

______________________________________________________________________=
___________________________________________________

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.

--90e6ba6e87a6e0fbec04fecd1383-- From nobody Tue Jul 22 12:20:04 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798091B27EC for ; Tue, 22 Jul 2014 12:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vE3BqLe4JNU for ; Tue, 22 Jul 2014 12:20:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74F51A0364 for ; Tue, 22 Jul 2014 12:19:59 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 43276325D2E; Tue, 22 Jul 2014 21:19:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 20D33238055; Tue, 22 Jul 2014 21:19:58 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 21:19:58 +0200 From: To: Robert Raszuk , Jeffrey Haas Thread-Topic: draft-litkowski-idr-bgp-timestamp Thread-Index: Ac+l4ODPJH0/NfV4QnGw7fCPCrH3Lg== Date: Tue, 22 Jul 2014 19:19:57 +0000 Message-ID: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92044435OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.141219 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/glUAIzlp6Z-PU63Es9pri1sMvtg Cc: idr wg Subject: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:20:01 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92044435OPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W1JlbmFtZWQgdG9waWNdDQoNCkhpIFJvYmVydCwNCg0KPiBZb3VyIHJlc3VsdHMgbWF5IGFjdHVh bGx5IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlIG1vcmUgcHJvYmxlbXMgdGhlbiBnYWlucyB1bmZv cnR1bmF0ZWx5Lg0KDQpJIGRvbuKAmXQgcmVhbGx5IHVuZGVyc3RhbmQgd2h5IOKApiBldmVuIGlm IFJSIGFyZSBub3QgaW4gdGhlIGRhdGFwbGFuZSAod2hpY2ggd291bGQgYmUgdGhlIGNhc2UgZm9y IFZQTiBlbnZpcm9ubWVudCksIFJSIGJlaGF2aW9yIGlzIHJlYWxseSBpbXBvcnRhbnQgdG8gdHJh Y2suDQoNCkNvbnNpZGVyIGEgTVBMUyBWUE4gc2NlbmFyaW8sIHNvbWUgUEVzIGNvbm5lY3RlZCB0 byBSUiBjbHVzdGVycyBhbmQgbWVzaGluZyBiZXR3ZWVuIGNsdXN0ZXJzLg0KQ29uc2lkZXIgdGhh dCBvbmUgb2YgdGhlIFJSIGlzIGdldHRpbmcgc3R1Y2sgYmVjYXVzZSBvZiBSb3V0ZS1yZWZyZXNo IHByb2Nlc3Npbmcgb2YgMk0gb2Ygcm91dGVzIG9yIGp1c3QgYnVzeSB0byBkbyBzb21ldGhpbmcg ZWxzZSBkdWUgdG8gYmFkIHNjaGVkdWxpbmcgaW4gdGhlIGltcGxlbWVudGlvbiDigKYgaWYgYSBQ RSBsb3NlIGEgY3VzdG9tZXIgY29ubmVjdGlvbiwgYW5kIGN1c3RvbWVyIGhhcyBhIGJhY2t1cCBj b25uZWN0aW9uIGFuZCBiYWNrdXAgUEUgaGFzIHRvIHNlbmQgYSBuZXcgQkdQIHVwZGF0ZSB0byBw cm9wYWdhdGUgdGhlIG5ldyBwYXRoLiBUaGUgdGltZSBmb3IgUlIgdG8gcHJvcGFnYXRlIHRoZSBC R1AgdXBkYXRlIGlzIGNyaXRpY2FsIHRvIHRyYWNrIGJlY2F1c2UgdGhpcyB3aWxsIGNvbmRpdGlv biBjb252ZXJnZW5jZSB0aW1lIGZvciB0aGUgY3VzdG9tZXIg4oCmDQoNClRob3VnaHRzID8NCg0K DQpTdGVwaGFuZQ0KDQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0Bn bWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBUdWVzZGF5LCBKdWx5 IDIyLCAyMDE0IDExOjE1DQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBKZWZmcmV5 IEhhYXMNCkNjOiBpZHIgd2cNClN1YmplY3Q6IGRyYWZ0LWxpdGtvd3NraS1pZHItcnRjLWludGVy YXMNCg0KU3RlcGhhbmUsDQoNCkkgaGF2ZSBvbmUgZnVuZGFtZW50YWwgcXVlc3Rpb24gb24gdGhp cyAuLi4NCg0KWW91IGhhdmUgZm9jdXNlZCBvbiBtYWtpbmcgc3VyZSB0aGF0IEJHUCBjb250cm9s IHBsYW5lIHdvcmtzIGZhc3QgYW5kIHNvbGlkIGV0Yy4gVGhhdCBpcyBncmVhdCBhbmQgdGltZXN0 YW1wIGlkZWEgYXQgZWFjaCBCR1AgaG9wIHdvdWxkIGhlbHAuDQoNCkhvd2V2ZXIgbGV0J3Mgb2Jz ZXJ2ZSB0aGF0IEJHUCBjb250cm9sIHBsYW5lIGlzIE5PVCBjb25ncnVlbnQgd2l0aCBkYXRhIHBs YW5lLiBJbiBvdGhlciB3b3JkcyB5b3UgbWF5IGhhdmUgYSBjYXNlIHdoZXJlIHNvbWVvbmUgbWF5 IGhhdmUgc2xvdyBhbmQgb3ZlcmxvYWRlZCBSUiBidXQgdXNlcyA0MCBHQiBwaXBlcyBmb3IgZGF0 YSBwbGFuZSB3aGlsZSBvdGhlciBBUyBpbnN0YWxsZWQgc3VwZXItaHlwZXIgeDg2IFJScyBhbmQg aGFzIDEgR0IgbGlua3MgZm9yIGRhdGEgcGxhbmUuDQoNCllvdXIgcmVzdWx0cyBtYXkgYWN0dWFs bHkgaW4gdGhlIGFib3ZlIGNhc2UgY2FzdWUgbW9yZSBwcm9ibGVtcyB0aGVuIGdhaW5zIHVuZm9y dHVuYXRlbHkuDQoNClRoZSBwb3NzaWJsZSBzaW1wbGUgZml4IGlzIHRvIG1hbmRhdGUgdGhhdCB0 aW1lc3RhbXAgaXMgT05MWSBhZGRlZCB3aGVuIHlvdXIgY2hhbmdlIG5leHQgaG9wIHRvIHNlbGYg b3IgdGhhdCB5b3UgY2FuIGhhdmUgYSBuZXcgZmxhZyAiTiIgLSBOZXh0IEhvcCBTZXQgd2hpY2gg d2lsbCBoZWxwIGEgbG90IHRvIG1ha2UgbW9yZSB1c2UgY2FzZXMgZm9yIHRoaXMgcHJvcG9zYWwu DQoNCkJlc3QsDQpSLg0KDQoNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_9E32478DFA9976438E7A22F69B08FF92044435OPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1JlbmFtZWQgdG9waWNd PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5IaSBSb2JlcnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IFlvdXIgcmVzdWx0cyBtYXkgYWN0 dWFsbHkgaW4gdGhlIGFib3ZlIGNhc2UgY2FzdWUgbW9yZSBwcm9ibGVtcyB0aGVuIGdhaW5zIHVu Zm9ydHVuYXRlbHkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgcmVhbGx5IHVuZGVyc3RhbmQg d2h5IOKApiBldmVuIGlmIFJSIGFyZSBub3QgaW4gdGhlIGRhdGFwbGFuZSAod2hpY2ggd291bGQg YmUgdGhlIGNhc2UgZm9yIFZQTiBlbnZpcm9ubWVudCksIFJSIGJlaGF2aW9yIGlzIHJlYWxseSBp bXBvcnRhbnQgdG8gdHJhY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db25zaWRlciBhIE1QTFMgVlBOIHNjZW5hcmlv LCBzb21lIFBFcyBjb25uZWN0ZWQgdG8gUlIgY2x1c3RlcnMgYW5kIG1lc2hpbmcgYmV0d2VlbiBj bHVzdGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgdGhhdCBvbmUg b2YgdGhlIFJSIGlzIGdldHRpbmcgc3R1Y2sgYmVjYXVzZSBvZiBSb3V0ZS1yZWZyZXNoIHByb2Nl c3Npbmcgb2YgMk0gb2Ygcm91dGVzIG9yIGp1c3QgYnVzeSB0byBkbyBzb21ldGhpbmcgZWxzZSBk dWUgdG8gYmFkIHNjaGVkdWxpbmcgaW4NCiB0aGUgaW1wbGVtZW50aW9uIOKApiBpZiBhIFBFIGxv c2UgYSBjdXN0b21lciBjb25uZWN0aW9uLCBhbmQgY3VzdG9tZXIgaGFzIGEgYmFja3VwIGNvbm5l Y3Rpb24gYW5kIGJhY2t1cCBQRSBoYXMgdG8gc2VuZCBhIG5ldyBCR1AgdXBkYXRlIHRvIHByb3Bh Z2F0ZSB0aGUgbmV3IHBhdGguIFRoZSB0aW1lIGZvciBSUiB0byBwcm9wYWdhdGUgdGhlIEJHUCB1 cGRhdGUgaXMgY3JpdGljYWwgdG8gdHJhY2sgYmVjYXVzZSB0aGlzIHdpbGwgY29uZGl0aW9uIGNv bnZlcmdlbmNlDQogdGltZSBmb3IgdGhlIGN1c3RvbWVyIOKApjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhvdWdodHMg PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN0ZXBoYW5l PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVr QGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDExOjE1PGJyPg0KPGI+VG86PC9iPiBMSVRL T1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7IEplZmZyZXkgSGFhczxicj4NCjxiPkNjOjwvYj4gaWRy IHdnPGJyPg0KPGI+U3ViamVjdDo8L2I+IGRyYWZ0LWxpdGtvd3NraS1pZHItcnRjLWludGVyYXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdGVwaGFuZSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBoYXZlIG9uZSBm dW5kYW1lbnRhbCBxdWVzdGlvbiBvbiB0aGlzIC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Zb3UgaGF2ZSBmb2N1c2VkIG9uIG1ha2luZyBz dXJlIHRoYXQgQkdQIGNvbnRyb2wgcGxhbmUgd29ya3MgZmFzdCBhbmQgc29saWQgZXRjLiBUaGF0 IGlzIGdyZWF0IGFuZCB0aW1lc3RhbXAgaWRlYSBhdCBlYWNoIEJHUCBob3Agd291bGQgaGVscC4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+SG93ZXZlciBsZXQncyBvYnNlcnZlIHRoYXQgQkdQIGNvbnRyb2wgcGxhbmUgaXMgTk9UIGNv bmdydWVudCB3aXRoIGRhdGEgcGxhbmUuIEluIG90aGVyIHdvcmRzIHlvdSBtYXkgaGF2ZSBhIGNh c2Ugd2hlcmUgc29tZW9uZSBtYXkgaGF2ZSBzbG93IGFuZCBvdmVybG9hZGVkIFJSIGJ1dCB1c2Vz IDQwIEdCIHBpcGVzIGZvciBkYXRhIHBsYW5lDQogd2hpbGUgb3RoZXIgQVMgaW5zdGFsbGVkIHN1 cGVyLWh5cGVyIHg4NiBSUnMgYW5kIGhhcyAxIEdCIGxpbmtzIGZvciBkYXRhIHBsYW5lLiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Z b3VyIHJlc3VsdHMgbWF5IGFjdHVhbGx5IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlIG1vcmUgcHJv YmxlbXMgdGhlbiBnYWlucyB1bmZvcnR1bmF0ZWx5LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgcG9zc2libGUgc2ltcGxlIGZp eCBpcyB0byBtYW5kYXRlIHRoYXQgdGltZXN0YW1wIGlzIE9OTFkgYWRkZWQgd2hlbiB5b3VyIGNo YW5nZSBuZXh0IGhvcCB0byBzZWxmIG9yIHRoYXQgeW91IGNhbiBoYXZlIGEgbmV3IGZsYWcgJnF1 b3Q7TiZxdW90OyAtIE5leHQgSG9wIFNldCB3aGljaCB3aWxsIGhlbHAgYSBsb3QgdG8gbWFrZSBt b3JlIHVzZSBjYXNlcw0KIGZvciB0aGlzIHByb3Bvc2FsLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CZXN0LDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Ui48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_9E32478DFA9976438E7A22F69B08FF92044435OPEXCLILM34corpor_-- From nobody Tue Jul 22 12:23:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE181A00E6 for ; Tue, 22 Jul 2014 12:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb2Cz30rJMPR for ; Tue, 22 Jul 2014 12:23:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0761A0B00 for ; Tue, 22 Jul 2014 12:23:12 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id F0C941904D5; Tue, 22 Jul 2014 21:23:09 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id D2988C804B; Tue, 22 Jul 2014 21:23:09 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 21:23:09 +0200 From: To: Robert Raszuk Thread-Topic: draft-litkowski-idr-rtc-interas-00 Thread-Index: AQHPpbgtWORGqB9K7kSBfWvCYKN7yZusJ50Q///j+QCAACJIIP//4K+AgABhvnD//+IYAAAEOa2Q///iEAD//928IA== Date: Tue, 22 Jul 2014 19:23:09 +0000 Message-ID: <12265_1406056989_53CEBA1D_12265_8806_1_9E32478DFA9976438E7A22F69B08FF92044455@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> <5637_1406055342_53CEB3AE_5637_4357_1_9E32478DFA9976438E7A22F69B08FF92044393@OPEXCLILM34.corporate.adroot.infra.ftgroup> <11537_1406056272_53CEB74F_11537_4854_1_9E32478DFA9976438E7A22F69B08FF920443EE@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92044455OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.180021 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/EUrR0hutghkcJ15myhNZTzRZY9c Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:23:15 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92044455OPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBSVEMgY2FuJ3QgYmUgdXNlZCB0byBraWxsIHJlZHVuZGFuY3kgYW5kIHRoYXQgc2hvdWxkIG5v dCByZWFsbHkgYmUgbmVnb3RpYWJsZS4NCg0KSSBkb27igJl0IHRoaW5rIHRoYXQgeW91IGFyZSBr aWxsaW5nIHJlZHVuZGFuY3kg4oCmIHdoZW4gdGhlIHByaW1hcnkgUlRDIHBhdGggd2lsbCBnbyBk b3duLCB0aGUgZGlzdHJpYnV0aW9uIHRyZWUgd2lsbCBiZSBlc3RhYmxpc2hlZCBvbiB0aGUgYmFj a3VwIHBhdGgsIGFuZCB0aGUgcm91dGVzIHdpbGwgYmUgc2VudCB0byBiYWNrdXAgQVNCUnMuIEJ1 dCBJIGNvbXBsZXRlbHkgYWdyZWUgdGhhdCB0aGlzIGlzIGEgc2xvdyBjb252ZXJnZW5jZSBwcm9j ZXNzIOKApiAoc29ydCBvZiBCR1AgcGF0aCBoaWRpbmcpLg0KDQpJIHdvdWxkIGJlIGludGVyZXN0 ZWQgYnkgcG9pbnQgb2YgdmlldyBvZiBtb3JlIHBlb3BsZSAoaW5jbHVkaW5nIG90aGVyIGNvLWF1 dGhvcnMpIG9uIHRoZSBiYXNpYyBzcGVjLg0KDQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tIFtt YWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50 OiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDE1OjE4DQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFND RS9JQk5GDQpDYzogaWRyIHdnDQpTdWJqZWN0OiBSZTogZHJhZnQtbGl0a293c2tpLWlkci1ydGMt aW50ZXJhcy0wMA0KDQpIaSwNCg0KRnJvbSBhIGRlc2lnbiBwb2ludCBvZiB2aWV3LCAoaXTigJlz IG15IHBlcnNvbmFsIHBvc2l0aW9uLCBJIHdhcyBub3QgaW52b2x2ZWQgaW4gUlRDIGluaXRpYWwg ZGlzY3Vzc2lvbiksIEkgd291bGQgdGVuZCB0byBzYXkgdGhhdCBSVEMgbXVzdCBieSBkZWZhdWx0 IHByb3ZpZGUgdGhlIG1vcmUgZWZmaWNpZW50IHJvdXRlIGRpc3RyaWJ1dGlvbiAobGltaXRpbmcg YXMgbXVjaCBhcyBwb3NzaWJsZSBzdGF0ZXMpLg0KDQpXZWxsIGFzIEkgd2FzIGludm9sdmVkIGZy b20gZGF5IG9uZSB3aXRoIFBlZHJvIG9uIHRoZSBSVEMgZGVzaWduIHRoZSBtYWluIGdvYWwgd2Fz IG5vdCB0byBsaW1pdCBzdGF0ZXMgImFzIG11Y2ggYXMgcG9zc2libGUiLg0KDQpUaGUgbWFpbiBn b2FsIHdhcyBub3QgdG8gc2VuZCBpbmZvcm1hdGlvbiB3aGVyZSB0aGVyZSBpcyBubyB1c2UgZm9y IGl0LiBBcyBhIHNpZGUgZWZmZWN0IHllcyB5b3UgbGltaXQgdGhlIHN0YXRlIGJ1dCBubyBtb3Jl IHRoZW4geW91IHNob3VsZC4NCg0KUlRDIGNhbid0IGJlIHVzZWQgdG8ga2lsbCByZWR1bmRhbmN5 IGFuZCB0aGF0IHNob3VsZCBub3QgcmVhbGx5IGJlIG5lZ290aWFibGUuDQoNCklmIHlvdSB3b3Vs ZCBmb2xsb3cgdGhhdCBtb2RlbCBmb3IgaW50cmEtYXMgYW5kIG9ubHkgaW5zdGFsbCBsb2NhbGx5 IG9yaWdpbmF0ZWQgUlQgcm91dGVzIG9uIFJSIGZvciBvbmUgUEUgb2YgbXVsdGlob21lZCBzaXRl IG9uZSBQRSB3b3VsZCBub3QgZ2V0IFZQTiByb3V0ZXMgaXQgaXMgYXNraW5nIGZvci4gU2FtZSBm b3IgQVNCUnMgb2YgZHVhbCBjb25uZWN0ZWQgQVMuDQoNCkluIGZhY3QgZHVyaW5nIG15IGxhc3Qg cHJvamVjdCBvbmUgdmVuZG9yIGFkZGVkIGViZ3AgbXVsdGlwYXRoIGZvciBSVEMgYXMgaXQgd2Fz IG5vdCBpbXBsZW1lbnRlZCBkYXkgb25lIDopDQoNCkJlc3QsDQpSLg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDk6MTEgUE0sIDxzdGVw aGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb20+PiB3cm90ZToNClRoaXMgaXMgYSBwb3NpdGlvbiB0aGF0IEkgY2Fubm90IGdvIGFnYWlu c3Qg4pi6DQpCdXQgYW55d2F5IGFzIGV2ZXJ5dGltZSB3aXRoIEJHUCAsIHRoZXJlIGlzIHR3byB3 YXkgOg0KDQotICAgICAgICAgIExpbWl0aW5nIG51bWJlciBvZiBwYXRocyBzdGF0ZXMgYW5kIHNv IGRlbGF5aW5nIGNvbnZlcmdlbmNlDQoNCi0gICAgICAgICAgQXVnbWVudGluZyBudW1iZXIgb2Yg cGF0aHMgc3RhdGVzIChBREQgUEFUSCwgYmVzdCBleHRlcm5hbCDigKYpLCB0byBzcGVlZCB1cCBj b252ZXJnZW5jZS4NCg0KRnJvbSBhIGRlc2lnbiBwb2ludCBvZiB2aWV3LCAoaXTigJlzIG15IHBl cnNvbmFsIHBvc2l0aW9uLCBJIHdhcyBub3QgaW52b2x2ZWQgaW4gUlRDIGluaXRpYWwgZGlzY3Vz c2lvbiksIEkgd291bGQgdGVuZCB0byBzYXkgdGhhdCBSVEMgbXVzdCBieSBkZWZhdWx0IHByb3Zp ZGUgdGhlIG1vcmUgZWZmaWNpZW50IHJvdXRlIGRpc3RyaWJ1dGlvbiAobGltaXRpbmcgYXMgbXVj aCBhcyBwb3NzaWJsZSBzdGF0ZXMpLiBCdXQgeWVzLCBJIGFncmVlIHRoYXQgaWYgdGhlcmUgaXMg YSBuZWVkIG9mIGZhc3Rjb252ZXJnZW5jZSB5b3UgbWF5IHdhbnQgdG8gZGlzYWJsZSBwYXRoIHBy dW5pbmcuDQoNCkkga25vdyBmcm9tIHByaXZhdGUgZGlzY3Vzc2lvbiB3aXRoIEtleXVyIHRoYXQg aGUgc2hhcmVzIGFsc28geW91ciBwb2ludCBvZiB2aWV3Lg0KDQpNYXliZSB0aGUgZmlyc3Qgc3Rl cCBiZWZvcmUgZGlzY3Vzc2luZyBhYm91dCBhIHNvbHV0aW9uIHdvdWxkIGJlIHRvIGFncmVlIG9u IHdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIG9mIHRoZSBjdXJyZW50IHNwZWNpZmljYXRp b24uIEl0IHNlZW1zIHRoYXQgdGhlcmUgaXMgbm8gY29uc2Vuc3VzIG9uIHRoZSByZWFkaW5nIG9m IHRoZSBSRkM0Njg0Lg0KDQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tPG1haWx0bzpycmFzenVr QGdtYWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFp bC5jb20+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogVHVlc2RheSwgSnVseSAy MiwgMjAxNCAxNTowNA0KDQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GDQpDYzogaWRy IHdnDQpTdWJqZWN0OiBSZTogZHJhZnQtbGl0a293c2tpLWlkci1ydGMtaW50ZXJhcy0wMA0KDQpI aSwNCg0KV2VsbCBJIHdvdWxkIHRlbmQgdG8gZGlzYWdyZWUuDQoNClRoZSByZWFzb25zIGFyZSB0 aGF0IGZhc3QgY29ubmVjdGl2aXR5IHJlc3RvcmF0aW9uIHJlcXVpcmVzIHByZXNlbmNlIG9mIG11 bHRpcGxlIFZQTiBwYXRocy4NCg0KQW5kIHRoYXQgaXMgYm90aCBpbnRyYSBhbmQgaW50ZXItYXMu DQoNCklmIHBlZXIgYXNrcyBmb3Igcm91dGVzIHdpdGggZ2l2ZW4gUlQgaXQgc2hvdWxkIGdldCB0 aG9zZSByb3V0ZXMuIFJlZ2FyZGxlc3Mgb2Ygd2hhdCBSVEMgYmVzdCBwYXRoIGlzIEkgYW0gZ29p bmcgdG8gc2VuZCBmdXJ0aGVyLg0KDQpPdGhlcndpc2UgbWFueSB0aGluZ3Mgd2lsbCBicmVhayBy ZWFsbHkgYmFkLg0KDQpCZXN0LA0Kci4NCg0KDQoNCk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDg6 NTUgUE0sIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0 a293c2tpQG9yYW5nZS5jb20+PiB3cm90ZToNCkkgdGhpbmsgdGhlcmUgaXMgbm8gY29uc2Vuc3Vz IG9uIHRoaXMgcmVhZGluZyBvZiB0aGUgUkZDLg0KDQpFc3BlY2lhbGx5IEplZmYgYW5kIEpvaG4g YWxyZWFkeSByZXBsaWVkIG9uIHRoZSBsaXN0IHRoYXQgUlQgZmlsdGVyIGlzIG9ubHkgaW5zdGFs bGVkIHRvIGJlc3QgcGF0aCBwZWVyLiBJIHdvdWxkIHRlbmQgdG8gYWdyZWUgd2l0aCB0aGVpciBy ZWFkaW5nIG9mIHRoZSBSRkMuDQoNCg0KRnJvbTogcnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJy YXN6dWtAZ21haWwuY29tPiBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPG1haWx0bzpycmFzenVr QGdtYWlsLmNvbT5dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBUdWVzZGF5LCBK dWx5IDIyLCAyMDE0IDExOjAxDQoNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYNCkNj OiBpZHIgd2cNClN1YmplY3Q6IFJlOiBkcmFmdC1saXRrb3dza2ktaWRyLXJ0Yy1pbnRlcmFzLTAw DQoNCg0KV2VsbCBSVCBmaWx0ZXIgc2hvdWxkIGJlIGluc3RhbGxlZCBvbiBhbGwgcGVlcnMgaXQg aGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSByZWdhcmRsZXNzIHdoYXQgdHlwZSBvZiBSVEMgcm91dGUg aXQgaXMuIFJlbW92aW5nIHRoZSBmaWx0ZXIgZnJvbSB0aGUgcGVlciBvbmx5IGJhc2VkIG9uIHBh cnRpY3VsYXIgYmVzdCBwYXRoIGNob3NlbiBzZWVtcyBhIGJpdCB3cm9uZyBpbXBsZW1lbnRhdGlv biB0byBtZSA6KQ0KDQpUaGUgYmVsb3cgc2VjdGlvbjoNCg0KMi4gIFtSRkM0Njg0XSBTZWN0aW9u IDMuMiA6DQoNCiAgICAiQXMgaW5kaWNhdGVkIGFib3ZlLCB0aGUgaW50ZXItQVMgVlBOIHJvdXRl IGRpc3RyaWJ1dGlvbiBncmFwaCwgZm9yIGENCiAgIGdpdmVuIHJvdXRlLXRhcmdldCwgaXMgY29u c3RydWN0ZWQgYnkgY3JlYXRpbmcgYSBkaXJlY3RlZCBhcmMgb24gdGhlDQogICBpbnZlcnNlIGRp cmVjdGlvbiBvZiByZWNlaXZlZCBSb3V0ZSBUYXJnZXQgbWVtYmVyc2hpcCBVUERBVEVzDQogICBj b250YWluaW5nIGFuIE5MUkkgb2YgdGhlIGZvcm0ge29yaWdpbi1hcyMsIHJvdXRlLXRhcmdldH0u DQoNCnJlZmVycyB0byBpbnRlci1hcyBiZWhhdmlvdXIgbm90IGxvY2FsIFJUIGluc3RhbGxhdGlv biBvbiBhbnkgQkdQIHNwZWFrZXIgd2l0aGluIHRoZSBBUy4NCg0KU28gaWYgdGhpcyBpcyB5b3Vy IG1haW4gaXNzdWUgdGhlbiBwZXJoYXBzIHdlIGhhdmUgYSBidWcgLi4uLg0KDQpyZ3MsDQpyLg0K DQoNCk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDQ6NTQgUE0sIDxzdGVwaGFuZS5saXRrb3dza2lA b3JhbmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+PiB3cm90ZToN CkhtbSDigKYgdGhlIGlzc3VlIGlzIG5vdCBpbiBSVEMgZmlsdGVyIHByb3BhZ2F0aW9uLCBidXQg aXQgaXMgb24gUlRDIGZpbHRlciBzZXR1cCBvbiB0aGUgUlIuIFJSIGF1dGhvcml6ZSByb3V0ZSBz ZW5kaW5nIFZQTiByb3V0ZXMgb25seSB0byBhIHNpbmdsZSBQRS4NCg0KRnJvbTogcnJhc3p1a0Bn bWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPiBbbWFpbHRvOnJyYXN6dWtAZ21haWwu Y29tPG1haWx0bzpycmFzenVrQGdtYWlsLmNvbT5dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVr DQpTZW50OiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDEwOjUwDQoNClRvOiBMSVRLT1dTS0kgU3Rl cGhhbmUgU0NFL0lCTkYNCkNjOiBpZHIgd2cNClN1YmplY3Q6IFJlOiBkcmFmdC1saXRrb3dza2kt aWRyLXJ0Yy1pbnRlcmFzLTAwDQoNCg0KTXkgcG9pbnQgaXMgdGhhdCBpZiBSUiB3aWxsIHJlb3Jp Z25hdGUgdGhlIFJUQyByb3V0ZSBpdCB3aWxsIG5vdCBiZSBmaWx0ZXJlZCBieSBhbnkgb2YgdGhl IFBFcyBoZW5jZSBzaG91bGQgYmUgcHJvcGFnYXRlZCBiZXR3ZWVuIGFkanVjZW50IEFTZXMgYXMg c29ydCBvZiAidGhpcmQiIHBhdGggLi4gcmVzdWx0aW5nIGluIGFsbCBSVEMgZmlsdGVycyB0byBi ZSBwcm9wYWdhdGVkIGFuZCBpbnN0YWxsZWQgcHJvcGVybHkgYWNyb3NzLg0KDQpJbiBmYWN0IHRo YXQgaXMgdGhlIG9ubHkgZGlmZmVyZW50IEkgc2VlIGJldHdlZW4gdHdvIGltcGxlbWVudGF0aW9u cyB5b3Ugd2VyZSByZWZlcnJpbmcgdHdvIDopDQoNCkJlc3QsDQpSLg0KDQoNCk9uIFR1ZSwgSnVs IDIyLCAyMDE0IGF0IDQ6MzIgUE0sIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWls dG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIFJvYmVydCwNCg0K SSBkb27igJl0IHJlYWxseSBzZWUgaG93IG9yaWdpbmF0b3IgcmV3cml0ZSBjYW4gaGVscCBpbiB0 aGlzIOKApg0KVGhlIGlzc3VlIGlzIHRoYXQgUlIgdGFrZXMgb25seSBiZXN0IHBhdGggaW50byBh Y2NvdW50IHdoZW4gTkxSSSBvcmlnaW4tQVMgaXMgZGlmZmVyZW50IGZyb20gbG9jYWwgQVMgdG8g ZXN0YWJsaXNoIHRoZSBkaXN0cmlidXRpb24gdHJlZS4NCg0KQ291bGQgeW91IGlsbHVzdHJhdGUg eW91ciBwcm9wb3NhbCA/DQoNClRoYW5rcywNCg0KU3RlcGhhbmUNCg0KDQpGcm9tOiBycmFzenVr QGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+IFttYWlsdG86cnJhc3p1a0BnbWFp bC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPl0gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6 dWsNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQgMTA6MjENClRvOiBMSVRLT1dTS0kgU3Rl cGhhbmUgU0NFL0lCTkYNCkNjOiBpZHIgd2cNClN1YmplY3Q6IGRyYWZ0LWxpdGtvd3NraS1pZHIt cnRjLWludGVyYXMtMDANCg0KSGkgU3RlcGhhbmUsDQoNClNvIGhvdyBhYm91dCB3ZSBmaXggdGhp cyBpc3N1ZSBieSBlbmFibGluZyBvcmlnbmF0b3IgcmV3cml0ZSBieSBSUnMgZm9yIGFsbCBwYXRo cyBub3Qgb25seSB0aG9zZSB3aGljaCBhcmUgbG9jYWwgPw0KDQpZb3UgbWVudGlvbmVkIHRoZSBu ZWVkIHRvIGJlIHBlciBBUyBzZWxlY3RpdmUgLi4uIHN1cmUgdGhpcyBhbHNvIGNhbiBiZSBrbm9i YmVkIG9uIHRoZSBSUiBpZiByZXF1aXJlZC4NCg0KV2hhdCBkbyB5b3UgdGhpbmsgPw0KDQpUaHgs DQpSLg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFu ayB5b3UuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFu ayB5b3UuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFu ayB5b3UuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFu ayB5b3UuDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_9E32478DFA9976438E7A22F69B08FF92044455OPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRl eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gUlRDIGNhbid0 IGJlIHVzZWQgdG8ga2lsbCByZWR1bmRhbmN5IGFuZCB0aGF0IHNob3VsZCBub3QgcmVhbGx5IGJl IG5lZ290aWFibGUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgdGhpbmsgdGhhdCB5b3UgYXJl IGtpbGxpbmcgcmVkdW5kYW5jeSDigKYgd2hlbiB0aGUgcHJpbWFyeSBSVEMgcGF0aCB3aWxsIGdv IGRvd24sIHRoZSBkaXN0cmlidXRpb24gdHJlZSB3aWxsIGJlIGVzdGFibGlzaGVkIG9uIHRoZSBi YWNrdXAgcGF0aCwgYW5kIHRoZQ0KIHJvdXRlcyB3aWxsIGJlIHNlbnQgdG8gYmFja3VwIEFTQlJz LiBCdXQgSSBjb21wbGV0ZWx5IGFncmVlIHRoYXQgdGhpcyBpcyBhIHNsb3cgY29udmVyZ2VuY2Ug cHJvY2VzcyDigKYgKHNvcnQgb2YgQkdQIHBhdGggaGlkaW5nKS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQg YmUgaW50ZXJlc3RlZCBieSBwb2ludCBvZiB2aWV3IG9mIG1vcmUgcGVvcGxlIChpbmNsdWRpbmcg b3RoZXIgY28tYXV0aG9ycykgb24gdGhlIGJhc2ljIHNwZWMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0NCjxiPk9uIEJl aGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5 IDIyLCAyMDE0IDE1OjE4PGJyPg0KPGI+VG86PC9iPiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lC TkY8YnI+DQo8Yj5DYzo8L2I+IGlkciB3Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogZHJhZnQt bGl0a293c2tpLWlkci1ydGMtaW50ZXJhcy0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkZyb20gYSBkZXNpZ24gcG9pbnQgb2YgdmlldywgKGl04oCZcyBteSBwZXJzb25hbCBwb3Np dGlvbiwgSSB3YXMgbm90IGludm9sdmVkIGluIFJUQyBpbml0aWFsIGRpc2N1c3Npb24pLCBJIHdv dWxkIHRlbmQgdG8gc2F5IHRoYXQgUlRDIG11c3QgYnkgZGVmYXVsdCBwcm92aWRlDQogdGhlIG1v cmUgZWZmaWNpZW50IHJvdXRlIGRpc3RyaWJ1dGlvbiAobGltaXRpbmcgYXMgbXVjaCBhcyBwb3Nz aWJsZSBzdGF0ZXMpLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5XZWxsIGFzIEkgd2FzIGludm9sdmVkIGZyb20gZGF5IG9uZSB3aXRoIFBlZHJv IG9uIHRoZSBSVEMgZGVzaWduIHRoZSBtYWluIGdvYWwgd2FzIG5vdCB0byBsaW1pdCBzdGF0ZXMg JnF1b3Q7YXMgbXVjaCBhcyBwb3NzaWJsZSZxdW90Oy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIG1haW4gZ29hbCB3YXMgbm90 IHRvIHNlbmQgaW5mb3JtYXRpb24gd2hlcmUgdGhlcmUgaXMgbm8gdXNlIGZvciBpdC4gQXMgYSBz aWRlIGVmZmVjdCB5ZXMgeW91IGxpbWl0IHRoZSBzdGF0ZSBidXQgbm8gbW9yZSB0aGVuIHlvdSBz aG91bGQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPlJUQyBjYW4ndCBiZSB1c2VkIHRvIGtpbGwgcmVkdW5kYW5jeSBhbmQgdGhhdCBz aG91bGQgbm90IHJlYWxseSBiZSBuZWdvdGlhYmxlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB5b3Ugd291bGQgZm9sbG93IHRo YXQgbW9kZWwgZm9yIGludHJhLWFzIGFuZCBvbmx5IGluc3RhbGwgbG9jYWxseSBvcmlnaW5hdGVk IFJUIHJvdXRlcyBvbiBSUiBmb3Igb25lIFBFIG9mIG11bHRpaG9tZWQgc2l0ZSBvbmUgUEUgd291 bGQgbm90IGdldCBWUE4gcm91dGVzIGl0IGlzIGFza2luZyBmb3IuIFNhbWUgZm9yIEFTQlJzIG9m IGR1YWwNCiBjb25uZWN0ZWQgQVMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkluIGZhY3QgZHVyaW5nIG15IGxhc3QgcHJvamVjdCBv bmUgdmVuZG9yIGFkZGVkIGViZ3AgbXVsdGlwYXRoIGZvciBSVEMgYXMgaXQgd2FzIG5vdCBpbXBs ZW1lbnRlZCBkYXkgb25lIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPkJlc3QsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5SLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1bCAyMiwgMjAxNCBhdCA5OjExIFBNLCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9i bGFuayI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBhIHBvc2l0aW9uIHRoYXQg SSBjYW5ub3QgZ28gYWdhaW5zdA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QnV0IGFueXdheSBhcyBldmVyeXRpbWUgd2l0aCBCR1AgLCB0aGVyZSBp cyB0d28gd2F5IDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5MaW1pdGluZyBudW1iZXIgb2YgcGF0aHMgc3RhdGVzIGFuZCBzbyBkZWxheWlu ZyBjb252ZXJnZW5jZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkF1Z21lbnRpbmcgbnVtYmVyIG9mIHBhdGhzIHN0YXRlcyAoQUREIFBBVEgs IGJlc3QgZXh0ZXJuYWwg4oCmKSwgdG8gc3BlZWQgdXAgY29udmVyZ2VuY2UuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+RnJvbSBhIGRlc2lnbiBwb2ludCBvZiB2aWV3LCAoaXTigJlzIG15IHBlcnNvbmFsIHBvc2l0 aW9uLCBJIHdhcyBub3QgaW52b2x2ZWQgaW4gUlRDIGluaXRpYWwgZGlzY3Vzc2lvbiksDQogSSB3 b3VsZCB0ZW5kIHRvIHNheSB0aGF0IFJUQyBtdXN0IGJ5IGRlZmF1bHQgcHJvdmlkZSB0aGUgbW9y ZSBlZmZpY2llbnQgcm91dGUgZGlzdHJpYnV0aW9uIChsaW1pdGluZyBhcyBtdWNoIGFzIHBvc3Np YmxlIHN0YXRlcykuIEJ1dCB5ZXMsIEkgYWdyZWUgdGhhdCBpZiB0aGVyZSBpcyBhIG5lZWQgb2Yg ZmFzdGNvbnZlcmdlbmNlIHlvdSBtYXkgd2FudCB0byBkaXNhYmxlIHBhdGggcHJ1bmluZy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JIGtub3cgZnJvbSBwcml2YXRlIGRpc2N1c3Npb24gd2l0aCBLZXl1ciB0aGF0 IGhlIHNoYXJlcyBhbHNvIHlvdXIgcG9pbnQgb2Ygdmlldy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXliZSB0 aGUgZmlyc3Qgc3RlcCBiZWZvcmUgZGlzY3Vzc2luZyBhYm91dCBhIHNvbHV0aW9uIHdvdWxkIGJl IHRvIGFncmVlIG9uIHdoYXQgaXMgdGhlIGV4cGVjdGVkDQogYmVoYXZpb3Igb2YgdGhlIGN1cnJl bnQgc3BlY2lmaWNhdGlvbi4gSXQgc2VlbXMgdGhhdCB0aGVyZSBpcyBubyBjb25zZW5zdXMgb24g dGhlIHJlYWRpbmcgb2YgdGhlIFJGQzQ2ODQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4N CjxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJyYXN6 dWtAZ21haWwuY29tPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29tPC9hPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDIyLCAy MDE0IDE1OjA0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjxi cj4NCjxiPkNjOjwvYj4gaWRyIHdnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBkcmFmdC1saXRr b3dza2ktaWRyLXJ0Yy1pbnRlcmFzLTAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XZWxsIEkgd291bGQgdGVuZCB0 byBkaXNhZ3JlZS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPlRoZSByZWFzb25zIGFyZSB0aGF0IGZhc3QgY29ubmVjdGl2aXR5 IHJlc3RvcmF0aW9uIHJlcXVpcmVzIHByZXNlbmNlIG9mIG11bHRpcGxlIFZQTiBwYXRocy4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPkFuZCB0aGF0IGlzIGJvdGggaW50cmEgYW5kIGludGVyLWFzLiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SWYgcGVlciBh c2tzIGZvciByb3V0ZXMgd2l0aCBnaXZlbiBSVCBpdCBzaG91bGQgZ2V0IHRob3NlIHJvdXRlcy4g UmVnYXJkbGVzcyBvZiB3aGF0IFJUQyBiZXN0IHBhdGggaXMgSSBhbSBnb2luZyB0byBzZW5kIGZ1 cnRoZXIuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5PdGhlcndpc2UgbWFueSB0aGluZ3Mgd2lsbCBicmVhayByZWFsbHkgYmFk Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+QmVzdCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+ci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDg6NTUgUE0sICZsdDs8 YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iIHRhcmdldD0iX2Js YW5rIj5zdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZXJlIGlzIG5vIGNvbnNl bnN1cyBvbiB0aGlzIHJlYWRpbmcgb2YgdGhlIFJGQy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVzcGVjaWFs bHkgSmVmZiBhbmQgSm9obiBhbHJlYWR5IHJlcGxpZWQgb24gdGhlIGxpc3QgdGhhdCBSVCBmaWx0 ZXIgaXMgb25seSBpbnN0YWxsZWQgdG8gYmVzdCBwYXRoDQogcGVlci4gSSB3b3VsZCB0ZW5kIHRv IGFncmVlIHdpdGggdGhlaXIgcmVhZGluZyBvZiB0aGUgUkZDLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFp bHRvOnJyYXN6dWtAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cnJhc3p1a0BnbWFpbC5jb208 L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJyYXN6dWtAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+cnJhc3p1a0BnbWFpbC5jb208L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQg UmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQgMTE6MDE8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGJyPg0KPGI+VG86PC9iPiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY8YnI+DQo8Yj5DYzo8 L2I+IGlkciB3Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogZHJhZnQtbGl0a293c2tpLWlkci1y dGMtaW50ZXJhcy0wMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XZWxsIFJUIGZpbHRlciBzaG91bGQgYmUgaW5zdGFs bGVkIG9uIGFsbCBwZWVycyBpdCBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIHJlZ2FyZGxlc3Mgd2hh dCB0eXBlIG9mIFJUQyByb3V0ZSBpdCBpcy4gUmVtb3ZpbmcgdGhlIGZpbHRlciBmcm9tDQogdGhl IHBlZXIgb25seSBiYXNlZCBvbiBwYXJ0aWN1bGFyIGJlc3QgcGF0aCBjaG9zZW4gc2VlbXMgYSBi aXQgd3JvbmcgaW1wbGVtZW50YXRpb24gdG8gbWUgOikmbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBiZWxvdyBzZWN0aW9u OiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjIuICZuYnNwO1tSRkM0Njg0XSBTZWN0aW9uIDMuMiA6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsg Jm5ic3A7ICZxdW90O0FzIGluZGljYXRlZCBhYm92ZSwgdGhlIGludGVyLUFTIFZQTiByb3V0ZSBk aXN0cmlidXRpb24gZ3JhcGgsIGZvciBhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDtnaXZlbiByb3V0ZS10YXJnZXQsIGlz IGNvbnN0cnVjdGVkIGJ5IGNyZWF0aW5nIGEgZGlyZWN0ZWQgYXJjIG9uIHRoZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7 aW52ZXJzZSBkaXJlY3Rpb24gb2YgcmVjZWl2ZWQgUm91dGUgVGFyZ2V0IG1lbWJlcnNoaXAgVVBE QVRFczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsgJm5ic3A7Y29udGFpbmluZyBhbiBOTFJJIG9mIHRoZSBmb3JtIHtvcmlnaW4tYXMj LCByb3V0ZS10YXJnZXR9Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+cmVmZXJzIHRvIGludGVyLWFzIGJlaGF2aW91ciBub3QgbG9jYWwg UlQgaW5zdGFsbGF0aW9uIG9uIGFueSBCR1Agc3BlYWtlciB3aXRoaW4gdGhlIEFTLiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ U28gaWYgdGhpcyBpcyB5b3VyIG1haW4gaXNzdWUgdGhlbiBwZXJoYXBzIHdlIGhhdmUgYSBidWcg Li4uLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+cmdzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5yLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgSnVsIDIyLCAyMDE0 IGF0IDQ6NTQgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IbW0g4oCm IHRoZSBpc3N1ZSBpcyBub3QgaW4gUlRDIGZpbHRlciBwcm9wYWdhdGlvbiwgYnV0IGl0IGlzIG9u IFJUQyBmaWx0ZXIgc2V0dXAgb24gdGhlIFJSLiBSUiBhdXRob3JpemUNCiByb3V0ZSBzZW5kaW5n IFZQTiByb3V0ZXMgb25seSB0byBhIHNpbmdsZSBQRS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOnJyYXN6dWtAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+cnJhc3p1a0BnbWFpbC5jb208L2E+IFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cnJhc3p1a0BnbWFpbC5j b208L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQgMTA6NTA8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBT dGVwaGFuZSBTQ0UvSUJORjxicj4NCjxiPkNjOjwvYj4gaWRyIHdnPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+U3ViamVjdDo8L2I+IFJlOiBkcmFmdC1s aXRrb3dza2ktaWRyLXJ0Yy1pbnRlcmFzLTAwPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TXkgcG9pbnQgaXMgdGhhdCBpZiBSUiB3aWxsIHJlb3Jp Z25hdGUgdGhlIFJUQyByb3V0ZSBpdCB3aWxsIG5vdCBiZSBmaWx0ZXJlZCBieSBhbnkgb2YgdGhl IFBFcyBoZW5jZSBzaG91bGQgYmUgcHJvcGFnYXRlZCBiZXR3ZWVuIGFkanVjZW50DQogQVNlcyBh cyBzb3J0IG9mICZxdW90O3RoaXJkJnF1b3Q7IHBhdGggLi4gcmVzdWx0aW5nIGluIGFsbCBSVEMg ZmlsdGVycyB0byBiZSBwcm9wYWdhdGVkIGFuZCBpbnN0YWxsZWQgcHJvcGVybHkgYWNyb3NzLiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+SW4gZmFjdCB0aGF0IGlzIHRoZSBvbmx5IGRpZmZlcmVudCBJIHNlZSBiZXR3ZWVuIHR3 byBpbXBsZW1lbnRhdGlvbnMgeW91IHdlcmUgcmVmZXJyaW5nIHR3byA6KTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QmVzdCw8YnI+DQpS Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBUdWUsIEp1bCAyMiwgMjAxNCBhdCA0OjMyIFBNLCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUm9iZXJ0LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCBy ZWFsbHkgc2VlIGhvdyBvcmlnaW5hdG9yIHJld3JpdGUgY2FuIGhlbHAgaW4gdGhpcyDigKY8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgaXNzdWUgaXMgdGhhdCBSUiB0YWtlcyBv bmx5IGJlc3QgcGF0aCBpbnRvIGFjY291bnQgd2hlbiBOTFJJIG9yaWdpbi1BUyBpcyBkaWZmZXJl bnQgZnJvbSBsb2NhbA0KIEFTIHRvIGVzdGFibGlzaCB0aGUgZGlzdHJpYnV0aW9uIHRyZWUuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Q291bGQgeW91IGlsbHVzdHJhdGUgeW91ciBwcm9wb3NhbCA/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN0ZXBoYW5lPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnJyYXN6dWtAZ21haWwuY29tPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpycmFzenVr QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29tPC9hPl0NCjxiPk9u IEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBK dWx5IDIyLCAyMDE0IDEwOjIxPGJyPg0KPGI+VG86PC9iPiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NF L0lCTkY8YnI+DQo8Yj5DYzo8L2I+IGlkciB3Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBkcmFmdC1s aXRrb3dza2ktaWRyLXJ0Yy1pbnRlcmFzLTAwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGkgU3RlcGhhbmUsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TbyBob3cgYWJvdXQgd2Ug Zml4IHRoaXMgaXNzdWUgYnkgZW5hYmxpbmcgb3JpZ25hdG9yIHJld3JpdGUgYnkgUlJzIGZvciBh bGwgcGF0aHMgbm90IG9ubHkgdGhvc2Ugd2hpY2ggYXJlIGxvY2FsID8mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPllvdSBtZW50 aW9uZWQgdGhlIG5lZWQgdG8gYmUgcGVyIEFTIHNlbGVjdGl2ZSAuLi4gc3VyZSB0aGlzIGFsc28g Y2FuIGJlIGtub2JiZWQgb24gdGhlIFJSIGlmIHJlcXVpcmVkLiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2hhdCBkbyB5b3Ug dGhpbmsgPyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+VGh4LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5SLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmU+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cHJlPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sPG86cD48L286cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7PG86cD48L286cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4N CjxwcmU+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpw PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48 L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jPG86cD48L286cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFuayB5 b3UuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_9E32478DFA9976438E7A22F69B08FF92044455OPEXCLILM34corpor_-- From nobody Tue Jul 22 12:29:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70E31A0309 for ; Tue, 22 Jul 2014 12:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r14uFY2QDc5u for ; Tue, 22 Jul 2014 12:29:43 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3941A02FE for ; Tue, 22 Jul 2014 12:29:43 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id at20so101793iec.25 for ; Tue, 22 Jul 2014 12:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yZwbLCoiYCb9AGAQ3F7/7ErRV4tMlONmOygvnSuixjo=; b=dCNW2PDSbIBeSAuw6lYxj4eejTvPzNd39fHQTCA6swnRXIPToslXdyrU///s4411i0 ZXwQJEq/aZx48BuUqxOW7tfBLftbdOK51GpIM5FvbXOwAqgTqKt9Fqz7PyAR/sspC0nQ 6efe1V+FhGXWyCh/AIn6XB+jY04fzxYoLs7zKarQnIf99dqaaDOFc5ukhaXSMUDAn1cG yvcRCIGh17ZXbMttZNHE/2M1R4r9paNC8lXKY5leIuaFRJsSBPe4hV6oQGYwQAk0lRMN jcAi03OuO0U5dpLC+bZea9OW6063oIszjEaeBVqW5LFJI5oG897BYAJqS/Vgli/iLMxm MlYA== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr19664071igb.21.1406057382731; Tue, 22 Jul 2014 12:29:42 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 22 Jul 2014 12:29:42 -0700 (PDT) In-Reply-To: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Tue, 22 Jul 2014 21:29:42 +0200 X-Google-Sender-Auth: fc9-BB-OswyaHFd5t6_queiBxqw Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=089e013a0c68d4e47704fecd3e95 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/QwraOeLALAbicQd-65vpbS2osfY Cc: Jeffrey Haas , idr wg Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:29:45 -0000 --089e013a0c68d4e47704fecd3e95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stephane, If you build your service counting on control plane convergence I think you are doing bad thing :) Sorry. If this draft is to further help with such designs I would clearly switch to "no support" immediately. I had other use cases in mind which did not sound negative. Specifically in your case if one PE of multihomed site looses PE-CE you locally protect the site (10s ms max) and take all time it needs for BGP to converge regardless how long it takes. Of course I am assuming basic rules like unique RD per VRF in place. The most important is to maintain data plane connectivity. Besides I am not sure how timestamp will help you in this case. Leave alone that timestamp may never catch the refresh max CPU load peak so you may incorrectly consider RR as sound when it is really not. Cheers, R. On Tue, Jul 22, 2014 at 9:19 PM, wrote: > [Renamed topic] > > > > Hi Robert, > > > > > Your results may actually in the above case casue more problems then > gains unfortunately. > > > > I don=E2=80=99t really understand why =E2=80=A6 even if RR are not in the= dataplane (which > would be the case for VPN environment), RR behavior is really important t= o > track. > > > > Consider a MPLS VPN scenario, some PEs connected to RR clusters and > meshing between clusters. > > Consider that one of the RR is getting stuck because of Route-refresh > processing of 2M of routes or just busy to do something else due to bad > scheduling in the implemention =E2=80=A6 if a PE lose a customer connecti= on, and > customer has a backup connection and backup PE has to send a new BGP upda= te > to propagate the new path. The time for RR to propagate the BGP update is > critical to track because this will condition convergence time for the > customer =E2=80=A6 > > > > Thoughts ? > > > > > > Stephane > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 11:15 > *To:* LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas > *Cc:* idr wg > *Subject:* draft-litkowski-idr-rtc-interas > > > > Stephane, > > > > I have one fundamental question on this ... > > > > You have focused on making sure that BGP control plane works fast and > solid etc. That is great and timestamp idea at each BGP hop would help. > > > > However let's observe that BGP control plane is NOT congruent with data > plane. In other words you may have a case where someone may have slow and > overloaded RR but uses 40 GB pipes for data plane while other AS installe= d > super-hyper x86 RRs and has 1 GB links for data plane. > > > > Your results may actually in the above case casue more problems then gain= s > unfortunately. > > > > The possible simple fix is to mandate that timestamp is ONLY added when > your change next hop to self or that you can have a new flag "N" - Next H= op > Set which will help a lot to make more use cases for this proposal. > > > > Best, > > R. > > > > > > > > _________________________________________________________________________= ________________________________________________ > > 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. > > 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. > > --089e013a0c68d4e47704fecd3e95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephane,

If you build your service counting on control plane convergence I think you= are doing bad thing :) Sorry.=C2=A0

If this draft is to further help with such designs I would clearly switch t= o "no support" immediately. I had other use cases in mind which d= id not sound negative.

Specifically in your case if one PE of multihomed s= ite looses PE-CE you locally protect the site (10s ms max) and take all tim= e it needs for BGP to converge regardless how long it takes. Of course I am= assuming basic rules like unique RD per VRF in place.

The most important is to maintain dat= a plane connectivity.=C2=A0

Besides I am not sure how timestamp w= ill help you in this case. Leave alone that timestamp may never catch the r= efresh max CPU load peak so you may incorrectly consider RR as sound when i= t is really not.=C2=A0

Cheers,
R.



On = Tue, Jul 22, 2014 at 9:19 PM, <stephane.litkowski@orange.com<= /a>> wrote:

[Renamed topic]=

=C2=A0

Hi Robert,<= /span>

=C2=A0

> Your results may actually in the abo= ve case casue more problems then gains unfortunately.=C2=A0

=C2=A0

I don=E2=80=99t really un= derstand why =E2=80=A6 even if RR are not in the dataplane (which would be = the case for VPN environment), RR behavior is really important to track.=

=C2=A0

Consider a MPLS VPN scena= rio, some PEs connected to RR clusters and meshing between clusters.=

Consider that one of the = RR is getting stuck because of Route-refresh processing of 2M of routes or = just busy to do something else due to bad scheduling in the implemention =E2=80=A6 if a PE lose a customer connection, and custome= r has a backup connection and backup PE has to send a new BGP update to pro= pagate the new path. The time for RR to propagate the BGP update is critica= l to track because this will condition convergence time for the customer =E2=80=A6

=C2=A0

Thoughts ?<= /span>

=C2=A0

=C2=A0

Stephane

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 11:15
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas
Cc: idr wg
Subject: draft-litkowski-idr-rtc-interas

=C2=A0

= Stephane,

= =C2=A0

= I have one fundamental question on this ...

= =C2=A0

= You have focused on making sure that BGP control plane works fast and solid= etc. That is great and timestamp idea at each BGP hop would help.=C2=A0=

= =C2=A0

= However let's observe that BGP control plane is NOT congruent with data= plane. In other words you may have a case where someone may have slow and = overloaded RR but uses 40 GB pipes for data plane while other AS installed super-hyper x86 RRs and has 1 GB links for data p= lane.=C2=A0

= =C2=A0

= Your results may actually in the above case casue more problems then gains = unfortunately.=C2=A0

= =C2=A0

= The possible simple fix is to mandate that timestamp is ONLY added when you= r change next hop to self or that you can have a new flag "N" - N= ext Hop Set which will help a lot to make more use cases for this proposal.=C2=A0

= =C2=A0

= Best,

= R.

= =C2=A0

= =C2=A0

= =C2=A0

______________________________________________________________________=
___________________________________________________

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.

--089e013a0c68d4e47704fecd3e95-- From nobody Tue Jul 22 12:38:36 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B98B1A01BD for ; Tue, 22 Jul 2014 12:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp5og7y_9k5o for ; Tue, 22 Jul 2014 12:38:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4C91A00CD for ; Tue, 22 Jul 2014 12:38:32 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id A0907375024; Tue, 22 Jul 2014 21:38:31 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 86795180042; Tue, 22 Jul 2014 21:38:31 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 21:38:31 +0200 From: To: Robert Raszuk Thread-Topic: draft-litkowski-idr-bgp-timestamp Thread-Index: Ac+l4ODPJH0/NfV4QnGw7fCPCrH3Lv//40kA///eIlA= Date: Tue, 22 Jul 2014 19:38:30 +0000 Message-ID: <16559_1406057911_53CEBDB7_16559_6108_1_9E32478DFA9976438E7A22F69B08FF920444B7@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF920444B7OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.170018 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/G4WpkVS0pRLPTL-Y_SBVuSyUOBY Cc: Jeffrey Haas , idr wg Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:38:35 -0000 --_000_9E32478DFA9976438E7A22F69B08FF920444B7OPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB3ZSBhcmUgaW5saW5lIOKApg0KQnV0IG5vdCBhbGwgb2YgdGhlIGN1c3RvbWVycyBy ZXF1aXJlcyA1MG1zZWMgb3IgPCAxc2VjIGNvbnZlcmdlbmNlIHRpbWUuIEZvciBtb3N0IG9mIHRo ZSB0cmFmZmljLCBzb21lIHNlY29uZHMgaXMgYWNjZXB0YWJsZSBhbmQgdGhlcmUgaXMgbm8gbmVl ZCB0byBkZXBsb3kgZGF0YXBsYW5lIHByb3RlY3Rpb24gZm9yIHN1Y2ggcHVycG9zZS4gQnV0IGFu eXdheSwgd2UgaGF2ZSB0byB0cmFjayBhYm5vcm1hbCBiZWhhdmlvcnMgb2YgdGhlIGNvbnRyb2xw bGFuZSAocmFjZSBjb25kaXRpb25zLCBjb3JuZXIgY2FzZXMg4oCmKSB3aGVyZSBpdCBkb2VzIG5v dCBkbyBpdHMgam9iIGNvcnJlY3RseSDigKYNCg0KSSB3YXMgYWxzbyB0aGlua2luZyBhYm91dCBw cm9wYWdhdGlvbiB0aW1lIG9mIEMtbXVsdGljYXN0IHJvdXRlIChhdCBsZWFzdCB0eXBlIDUvNi83 KSB3aGljaCBpcyBjcml0aWNhbCDigKYgYW5kIGN1c3RvbWVyIGNhbm5vdCB3YWl0IDMwLzUwIHNl Y29uZHMgKG9yIHNvbWUgaG91cnMg4oCmIGRvbuKAmXQgbGF1Z2gsIGl04oCZcyBub3QgYSBqb2tl IOKApikgdG8gcmVjZWl2ZSB0aGUgZ3JvdXAgbWVtYmVyc2hpcCDigKYNCg0KT3VyIHByb3Bvc2Fs IGRvZXMgbm90IHByb25lIGluIGFueXdheSB0byB1c2UgY29udHJvbHBsYW5lIG9yIGRhdGFwbGFu ZSB0byBtYW5hZ2UgYW55IHJlZHVuZGFuY3kg4oCmDQoNClRoZXJlIGlzIGEgbmVlZCB0byBtb25p dG9yIEJHUCBjb250cm9scGxhbmUgYmVoYXZpb3IgYW5kIGVzcGVjaWFsbHkgdXBkYXRlIHByb3Bh Z2F0aW9uIHRpbWUgOiB0aGUgYmFzaWMgdXNlIGNhc2UgaXMgcmVhbGx5IHRvIGVuc3VyZSB0aGF0 IGV2ZXJ5dGhpbmcgZ29lcyB3ZWxsIOKApiBjb21wYXJlZCB0byB0aGUgYmFzZSBsaW5lIHdlIGV2 YWx1YXRlZCBpbiBsYWJzIG9yIHRoZW9yeS4NCg0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBb bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2Vu dDogVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxNTozMA0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBT Q0UvSUJORg0KQ2M6IEplZmZyZXkgSGFhczsgaWRyIHdnDQpTdWJqZWN0OiBSZTogZHJhZnQtbGl0 a293c2tpLWlkci1iZ3AtdGltZXN0YW1wDQoNClN0ZXBoYW5lLA0KDQpJZiB5b3UgYnVpbGQgeW91 ciBzZXJ2aWNlIGNvdW50aW5nIG9uIGNvbnRyb2wgcGxhbmUgY29udmVyZ2VuY2UgSSB0aGluayB5 b3UgYXJlIGRvaW5nIGJhZCB0aGluZyA6KSBTb3JyeS4NCg0KSWYgdGhpcyBkcmFmdCBpcyB0byBm dXJ0aGVyIGhlbHAgd2l0aCBzdWNoIGRlc2lnbnMgSSB3b3VsZCBjbGVhcmx5IHN3aXRjaCB0byAi bm8gc3VwcG9ydCIgaW1tZWRpYXRlbHkuIEkgaGFkIG90aGVyIHVzZSBjYXNlcyBpbiBtaW5kIHdo aWNoIGRpZCBub3Qgc291bmQgbmVnYXRpdmUuDQoNClNwZWNpZmljYWxseSBpbiB5b3VyIGNhc2Ug aWYgb25lIFBFIG9mIG11bHRpaG9tZWQgc2l0ZSBsb29zZXMgUEUtQ0UgeW91IGxvY2FsbHkgcHJv dGVjdCB0aGUgc2l0ZSAoMTBzIG1zIG1heCkgYW5kIHRha2UgYWxsIHRpbWUgaXQgbmVlZHMgZm9y IEJHUCB0byBjb252ZXJnZSByZWdhcmRsZXNzIGhvdyBsb25nIGl0IHRha2VzLiBPZiBjb3Vyc2Ug SSBhbSBhc3N1bWluZyBiYXNpYyBydWxlcyBsaWtlIHVuaXF1ZSBSRCBwZXIgVlJGIGluIHBsYWNl Lg0KDQpUaGUgbW9zdCBpbXBvcnRhbnQgaXMgdG8gbWFpbnRhaW4gZGF0YSBwbGFuZSBjb25uZWN0 aXZpdHkuDQoNCkJlc2lkZXMgSSBhbSBub3Qgc3VyZSBob3cgdGltZXN0YW1wIHdpbGwgaGVscCB5 b3UgaW4gdGhpcyBjYXNlLiBMZWF2ZSBhbG9uZSB0aGF0IHRpbWVzdGFtcCBtYXkgbmV2ZXIgY2F0 Y2ggdGhlIHJlZnJlc2ggbWF4IENQVSBsb2FkIHBlYWsgc28geW91IG1heSBpbmNvcnJlY3RseSBj b25zaWRlciBSUiBhcyBzb3VuZCB3aGVuIGl0IGlzIHJlYWxseSBub3QuDQoNCkNoZWVycywNClIu DQoNCg0KT24gVHVlLCBKdWwgMjIsIDIwMTQgYXQgOToxOSBQTSwgPHN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4+IHdyb3Rl Og0KW1JlbmFtZWQgdG9waWNdDQoNCkhpIFJvYmVydCwNCg0KPiBZb3VyIHJlc3VsdHMgbWF5IGFj dHVhbGx5IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlIG1vcmUgcHJvYmxlbXMgdGhlbiBnYWlucyB1 bmZvcnR1bmF0ZWx5Lg0KDQpJIGRvbuKAmXQgcmVhbGx5IHVuZGVyc3RhbmQgd2h5IOKApiBldmVu IGlmIFJSIGFyZSBub3QgaW4gdGhlIGRhdGFwbGFuZSAod2hpY2ggd291bGQgYmUgdGhlIGNhc2Ug Zm9yIFZQTiBlbnZpcm9ubWVudCksIFJSIGJlaGF2aW9yIGlzIHJlYWxseSBpbXBvcnRhbnQgdG8g dHJhY2suDQoNCkNvbnNpZGVyIGEgTVBMUyBWUE4gc2NlbmFyaW8sIHNvbWUgUEVzIGNvbm5lY3Rl ZCB0byBSUiBjbHVzdGVycyBhbmQgbWVzaGluZyBiZXR3ZWVuIGNsdXN0ZXJzLg0KQ29uc2lkZXIg dGhhdCBvbmUgb2YgdGhlIFJSIGlzIGdldHRpbmcgc3R1Y2sgYmVjYXVzZSBvZiBSb3V0ZS1yZWZy ZXNoIHByb2Nlc3Npbmcgb2YgMk0gb2Ygcm91dGVzIG9yIGp1c3QgYnVzeSB0byBkbyBzb21ldGhp bmcgZWxzZSBkdWUgdG8gYmFkIHNjaGVkdWxpbmcgaW4gdGhlIGltcGxlbWVudGlvbiDigKYgaWYg YSBQRSBsb3NlIGEgY3VzdG9tZXIgY29ubmVjdGlvbiwgYW5kIGN1c3RvbWVyIGhhcyBhIGJhY2t1 cCBjb25uZWN0aW9uIGFuZCBiYWNrdXAgUEUgaGFzIHRvIHNlbmQgYSBuZXcgQkdQIHVwZGF0ZSB0 byBwcm9wYWdhdGUgdGhlIG5ldyBwYXRoLiBUaGUgdGltZSBmb3IgUlIgdG8gcHJvcGFnYXRlIHRo ZSBCR1AgdXBkYXRlIGlzIGNyaXRpY2FsIHRvIHRyYWNrIGJlY2F1c2UgdGhpcyB3aWxsIGNvbmRp dGlvbiBjb252ZXJnZW5jZSB0aW1lIGZvciB0aGUgY3VzdG9tZXIg4oCmDQoNClRob3VnaHRzID8N Cg0KDQpTdGVwaGFuZQ0KDQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tPG1haWx0bzpycmFzenVr QGdtYWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFp bC5jb20+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogVHVlc2RheSwgSnVseSAy MiwgMjAxNCAxMToxNQ0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjsgSmVmZnJleSBI YWFzDQpDYzogaWRyIHdnDQpTdWJqZWN0OiBkcmFmdC1saXRrb3dza2ktaWRyLXJ0Yy1pbnRlcmFz DQoNClN0ZXBoYW5lLA0KDQpJIGhhdmUgb25lIGZ1bmRhbWVudGFsIHF1ZXN0aW9uIG9uIHRoaXMg Li4uDQoNCllvdSBoYXZlIGZvY3VzZWQgb24gbWFraW5nIHN1cmUgdGhhdCBCR1AgY29udHJvbCBw bGFuZSB3b3JrcyBmYXN0IGFuZCBzb2xpZCBldGMuIFRoYXQgaXMgZ3JlYXQgYW5kIHRpbWVzdGFt cCBpZGVhIGF0IGVhY2ggQkdQIGhvcCB3b3VsZCBoZWxwLg0KDQpIb3dldmVyIGxldCdzIG9ic2Vy dmUgdGhhdCBCR1AgY29udHJvbCBwbGFuZSBpcyBOT1QgY29uZ3J1ZW50IHdpdGggZGF0YSBwbGFu ZS4gSW4gb3RoZXIgd29yZHMgeW91IG1heSBoYXZlIGEgY2FzZSB3aGVyZSBzb21lb25lIG1heSBo YXZlIHNsb3cgYW5kIG92ZXJsb2FkZWQgUlIgYnV0IHVzZXMgNDAgR0IgcGlwZXMgZm9yIGRhdGEg cGxhbmUgd2hpbGUgb3RoZXIgQVMgaW5zdGFsbGVkIHN1cGVyLWh5cGVyIHg4NiBSUnMgYW5kIGhh cyAxIEdCIGxpbmtzIGZvciBkYXRhIHBsYW5lLg0KDQpZb3VyIHJlc3VsdHMgbWF5IGFjdHVhbGx5 IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlIG1vcmUgcHJvYmxlbXMgdGhlbiBnYWlucyB1bmZvcnR1 bmF0ZWx5Lg0KDQpUaGUgcG9zc2libGUgc2ltcGxlIGZpeCBpcyB0byBtYW5kYXRlIHRoYXQgdGlt ZXN0YW1wIGlzIE9OTFkgYWRkZWQgd2hlbiB5b3VyIGNoYW5nZSBuZXh0IGhvcCB0byBzZWxmIG9y IHRoYXQgeW91IGNhbiBoYXZlIGEgbmV3IGZsYWcgIk4iIC0gTmV4dCBIb3AgU2V0IHdoaWNoIHdp bGwgaGVscCBhIGxvdCB0byBtYWtlIG1vcmUgdXNlIGNhc2VzIGZvciB0aGlzIHByb3Bvc2FsLg0K DQpCZXN0LA0KUi4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s DQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KDQpUaGFuayB5b3UuDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_9E32478DFA9976438E7A22F69B08FF920444B7OPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IHRoaW5rIHdlIGFyZSBpbmxpbmUg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1 dCBub3QgYWxsIG9mIHRoZSBjdXN0b21lcnMgcmVxdWlyZXMgNTBtc2VjIG9yICZsdDsgMXNlYyBj b252ZXJnZW5jZSB0aW1lLiBGb3IgbW9zdCBvZiB0aGUgdHJhZmZpYywgc29tZSBzZWNvbmRzIGlz IGFjY2VwdGFibGUgYW5kIHRoZXJlIGlzIG5vIG5lZWQgdG8gZGVwbG95DQogZGF0YXBsYW5lIHBy b3RlY3Rpb24gZm9yIHN1Y2ggcHVycG9zZS4gQnV0IGFueXdheSwgd2UgaGF2ZSB0byB0cmFjayBh Ym5vcm1hbCBiZWhhdmlvcnMgb2YgdGhlIGNvbnRyb2xwbGFuZSAocmFjZSBjb25kaXRpb25zLCBj b3JuZXIgY2FzZXMg4oCmKSB3aGVyZSBpdCBkb2VzIG5vdCBkbyBpdHMgam9iIGNvcnJlY3RseSDi gKYNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSB3YXMgYWxzbyB0aGlua2luZyBhYm91dCBwcm9wYWdhdGlvbiB0aW1l IG9mIEMtbXVsdGljYXN0IHJvdXRlIChhdCBsZWFzdCB0eXBlIDUvNi83KSB3aGljaCBpcyBjcml0 aWNhbCDigKYgYW5kIGN1c3RvbWVyIGNhbm5vdCB3YWl0IDMwLzUwIHNlY29uZHMgKG9yIHNvbWUg aG91cnMNCiDigKYgZG9u4oCZdCBsYXVnaCwgaXTigJlzIG5vdCBhIGpva2Ug4oCmKSB0byByZWNl aXZlIHRoZSBncm91cCBtZW1iZXJzaGlwIOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3VyIHByb3Bvc2FsIGRvZXMg bm90IHByb25lIGluIGFueXdheSB0byB1c2UgY29udHJvbHBsYW5lIG9yIGRhdGFwbGFuZSB0byBt YW5hZ2UgYW55IHJlZHVuZGFuY3kg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBpcyBhIG5lZWQgdG8gbW9u aXRvciBCR1AgY29udHJvbHBsYW5lIGJlaGF2aW9yIGFuZCBlc3BlY2lhbGx5IHVwZGF0ZSBwcm9w YWdhdGlvbiB0aW1lIDogdGhlIGJhc2ljIHVzZSBjYXNlIGlzIHJlYWxseSB0byBlbnN1cmUgdGhh dCBldmVyeXRoaW5nIGdvZXMgd2VsbA0KIOKApiBjb21wYXJlZCB0byB0aGUgYmFzZSBsaW5lIHdl IGV2YWx1YXRlZCBpbiBsYWJzIG9yIHRoZW9yeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBycmFz enVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMjIsIDIw MTQgMTU6MzA8YnI+DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjxicj4N CjxiPkNjOjwvYj4gSmVmZnJleSBIYWFzOyBpZHIgd2c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IGRyYWZ0LWxpdGtvd3NraS1pZHItYmdwLXRpbWVzdGFtcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPlN0ZXBoYW5lLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB5b3UgYnVpbGQgeW91ciBzZXJ2aWNlIGNvdW50aW5n IG9uIGNvbnRyb2wgcGxhbmUgY29udmVyZ2VuY2UgSSB0aGluayB5b3UgYXJlIGRvaW5nIGJhZCB0 aGluZyA6KSBTb3JyeS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+SWYgdGhpcyBkcmFmdCBpcyB0byBmdXJ0aGVyIGhlbHAgd2l0aCBz dWNoIGRlc2lnbnMgSSB3b3VsZCBjbGVhcmx5IHN3aXRjaCB0byAmcXVvdDtubyBzdXBwb3J0JnF1 b3Q7IGltbWVkaWF0ZWx5LiBJIGhhZCBvdGhlciB1c2UgY2FzZXMgaW4gbWluZCB3aGljaCBkaWQg bm90IHNvdW5kIG5lZ2F0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5TcGVjaWZpY2FsbHkgaW4geW91ciBjYXNlIGlmIG9uZSBQRSBvZiBt dWx0aWhvbWVkIHNpdGUgbG9vc2VzIFBFLUNFIHlvdSBsb2NhbGx5IHByb3RlY3QgdGhlIHNpdGUg KDEwcyBtcyBtYXgpIGFuZCB0YWtlIGFsbCB0aW1lIGl0IG5lZWRzIGZvciBCR1AgdG8gY29udmVy Z2UgcmVnYXJkbGVzcyBob3cgbG9uZyBpdCB0YWtlcy4gT2YgY291cnNlDQogSSBhbSBhc3N1bWlu ZyBiYXNpYyBydWxlcyBsaWtlIHVuaXF1ZSBSRCBwZXIgVlJGIGluIHBsYWNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgbW9zdCBpbXBv cnRhbnQgaXMgdG8gbWFpbnRhaW4gZGF0YSBwbGFuZSBjb25uZWN0aXZpdHkuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc2lkZXMg SSBhbSBub3Qgc3VyZSBob3cgdGltZXN0YW1wIHdpbGwgaGVscCB5b3UgaW4gdGhpcyBjYXNlLiBM ZWF2ZSBhbG9uZSB0aGF0IHRpbWVzdGFtcCBtYXkgbmV2ZXIgY2F0Y2ggdGhlIHJlZnJlc2ggbWF4 IENQVSBsb2FkIHBlYWsgc28geW91IG1heSBpbmNvcnJlY3RseSBjb25zaWRlciBSUiBhcyBzb3Vu ZCB3aGVuIGl0IGlzIHJlYWxseQ0KIG5vdC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2hlZXJzLDxicj4NClIuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDk6MTkgUE0sICZsdDs8YSBo cmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5zdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bUmVuYW1lZCB0b3BpY108L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IaSBSb2JlcnQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBZb3VyIHJlc3VsdHMgbWF5IGFjdHVhbGx5 IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlDQogbW9yZSBwcm9ibGVtcyB0aGVuIGdhaW5zIHVuZm9y dHVuYXRlbHkuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHJlYWxseSB1bmRlcnN0YW5k IHdoeSDigKYgZXZlbiBpZiBSUiBhcmUgbm90IGluIHRoZSBkYXRhcGxhbmUgKHdoaWNoIHdvdWxk IGJlIHRoZSBjYXNlIGZvcg0KIFZQTiBlbnZpcm9ubWVudCksIFJSIGJlaGF2aW9yIGlzIHJlYWxs eSBpbXBvcnRhbnQgdG8gdHJhY2suPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgYSBNUExTIFZQTiBz Y2VuYXJpbywgc29tZSBQRXMgY29ubmVjdGVkIHRvIFJSIGNsdXN0ZXJzIGFuZCBtZXNoaW5nIGJl dHdlZW4gY2x1c3RlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXIg dGhhdCBvbmUgb2YgdGhlIFJSIGlzIGdldHRpbmcgc3R1Y2sgYmVjYXVzZSBvZiBSb3V0ZS1yZWZy ZXNoIHByb2Nlc3Npbmcgb2YgMk0gb2Ygcm91dGVzDQogb3IganVzdCBidXN5IHRvIGRvIHNvbWV0 aGluZyBlbHNlIGR1ZSB0byBiYWQgc2NoZWR1bGluZyBpbiB0aGUgaW1wbGVtZW50aW9uIOKApiBp ZiBhIFBFIGxvc2UgYSBjdXN0b21lciBjb25uZWN0aW9uLCBhbmQgY3VzdG9tZXIgaGFzIGEgYmFj a3VwIGNvbm5lY3Rpb24gYW5kIGJhY2t1cCBQRSBoYXMgdG8gc2VuZCBhIG5ldyBCR1AgdXBkYXRl IHRvIHByb3BhZ2F0ZSB0aGUgbmV3IHBhdGguIFRoZSB0aW1lIGZvciBSUiB0byBwcm9wYWdhdGUg dGhlIEJHUA0KIHVwZGF0ZSBpcyBjcml0aWNhbCB0byB0cmFjayBiZWNhdXNlIHRoaXMgd2lsbCBj b25kaXRpb24gY29udmVyZ2VuY2UgdGltZSBmb3IgdGhlIGN1c3RvbWVyIOKApjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRob3VnaHRzID88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TdGVwaGFuZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVm PSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWls LmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJv YmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMTox NTxicj4NCjxiPlRvOjwvYj4gTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBKZWZmcmV5IEhh YXM8YnI+DQo8Yj5DYzo8L2I+IGlkciB3Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBkcmFmdC1saXRr b3dza2ktaWRyLXJ0Yy1pbnRlcmFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPlN0ZXBoYW5lLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+SSBoYXZlIG9uZSBmdW5kYW1lbnRhbCBxdWVzdGlvbiBvbiB0aGlz IC4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+WW91IGhhdmUgZm9jdXNlZCBvbiBtYWtpbmcgc3VyZSB0aGF0IEJHUCBjb250cm9sIHBs YW5lIHdvcmtzIGZhc3QgYW5kIHNvbGlkIGV0Yy4gVGhhdCBpcyBncmVhdCBhbmQgdGltZXN0YW1w IGlkZWEgYXQgZWFjaCBCR1AgaG9wIHdvdWxkIGhlbHAuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Ib3dldmVyIGxldCdzIG9i c2VydmUgdGhhdCBCR1AgY29udHJvbCBwbGFuZSBpcyBOT1QgY29uZ3J1ZW50IHdpdGggZGF0YSBw bGFuZS4gSW4gb3RoZXIgd29yZHMgeW91IG1heSBoYXZlIGEgY2FzZSB3aGVyZSBzb21lb25lIG1h eSBoYXZlDQogc2xvdyBhbmQgb3ZlcmxvYWRlZCBSUiBidXQgdXNlcyA0MCBHQiBwaXBlcyBmb3Ig ZGF0YSBwbGFuZSB3aGlsZSBvdGhlciBBUyBpbnN0YWxsZWQgc3VwZXItaHlwZXIgeDg2IFJScyBh bmQgaGFzIDEgR0IgbGlua3MgZm9yIGRhdGEgcGxhbmUuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Zb3VyIHJlc3VsdHMgbWF5 IGFjdHVhbGx5IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlIG1vcmUgcHJvYmxlbXMgdGhlbiBnYWlu cyB1bmZvcnR1bmF0ZWx5LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIHBvc3NpYmxlIHNpbXBsZSBmaXggaXMgdG8gbWFu ZGF0ZSB0aGF0IHRpbWVzdGFtcCBpcyBPTkxZIGFkZGVkIHdoZW4geW91ciBjaGFuZ2UgbmV4dCBo b3AgdG8gc2VsZiBvciB0aGF0IHlvdSBjYW4gaGF2ZSBhIG5ldyBmbGFnICZxdW90O04mcXVvdDsN CiAtIE5leHQgSG9wIFNldCB3aGljaCB3aWxsIGhlbHAgYSBsb3QgdG8gbWFrZSBtb3JlIHVzZSBj YXNlcyBmb3IgdGhpcyBwcm9wb3NhbC4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3QsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlIuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Q2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48 L286cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFuayB5b3UuPG86cD48L286cD48L3By ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwv UFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9E32478DFA9976438E7A22F69B08FF920444B7OPEXCLILM34corpor_-- From nobody Tue Jul 22 12:43:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547D21A01BD for ; Tue, 22 Jul 2014 12:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6yJi4ZV5OYl for ; Tue, 22 Jul 2014 12:43:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F9D1A0061 for ; Tue, 22 Jul 2014 12:43:20 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 33C1522E221; Tue, 22 Jul 2014 21:43:19 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1515B238055; Tue, 22 Jul 2014 21:43:19 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 21:43:18 +0200 From: To: LITKOWSKI Stephane SCE/IBNF , Robert Raszuk Thread-Topic: draft-litkowski-idr-bgp-timestamp Thread-Index: Ac+l4ODPJH0/NfV4QnGw7fCPCrH3Lv//40kA///eIlD//7mfkA== Date: Tue, 22 Jul 2014 19:43:18 +0000 Message-ID: <5637_1406058199_53CEBED7_5637_5507_1_7086b517-975e-4f75-9c52-cc354bccddcc@OPEXCLILH05.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <16559_1406057911_53CEBDB7_16559_6108_1_9E32478DFA9976438E7A22F69B08FF920444B7@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <16559_1406057911_53CEBDB7_16559_6108_1_9E32478DFA9976438E7A22F69B08FF920444B7@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_7086b517975e4f759c52cc354bccddccOPEXCLILH05corporateadr_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.141219 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Zs0bk-vcP7Kxk1ZC4yA5C--2dyI Cc: Jeffrey Haas , idr wg Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:43:23 -0000 --_000_7086b517975e4f759c52cc354bccddccOPEXCLILH05corporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIGp1c3QgdG8gYWRkIHNvbWV0aGluZyBlbHNlIGxpbmtlZCB0byBkYXRhcGxhbmUgcHJvdGVj dGlvbiDigKYNCkV2ZW4gaWYgd2UgaW1wbGVtZW50IGEgZGF0YXBsYW5lIHByb3RlY3Rpb24gKFBF LUNFLCBvciBldmVuIENPUkUpLCB3ZSBhcmUgdXNpbmcgT0FNcyB0byB2ZXJpZnkgdGhhdCBpdCB3 b3JrcyBmaW5lIGFuZCBkb2VzIGl0cyBqb2IgY29ycmVjdGx5IOKApiBiZWNhdXNlIG1heWJlIGlu IDk1JSBvZiB0aGUgY2FzZXMgaXQgd291bGQgd29yayBhbmQgeW91IHdpbGwgaGF2ZSA1MG1zZWMg b2YgdHJhZmZpYyBsb3NzLCBidXQgaW4gc29tZSBjb25kaXRpb25zIHlvdSBtYXkgZmFsbCBpbnRv IGEgYnVnIG9yIGNvcm5lciBjYXNlIHRoYXQgd2lsbCBwdXQgeW91IGF0IHNvbWUgc2Vjb25kcyBv ciBtb3JlLg0KDQpIZXJlIGl04oCZcyB0aGUgc2FtZSwgd2UgaGF2ZSBzb21lIG1lY2hhbmljIGlu IHBsYWNlIChCR1ApLCB3ZSB3YW50IGFuIE9BTSAoc2ltcGxlIHByb2JpbmcpIHRvIGVuc3VyZSB0 aGF0IGl0IGRvZXMgaXTigJlzIGpvYiBjb3JyZWN0bHkg4oCmDQoNCkhvcGUgdGhlIGNvbXBhcmlz b24gY2xhcmlmaWVzIG15IHBvc2l0aW9uLg0KDQoNCkZyb206IElkciBbbWFpbHRvOmlkci1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20N ClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQgMTU6MzkNClRvOiBSb2JlcnQgUmFzenVrDQpD YzogSmVmZnJleSBIYWFzOyBpZHIgd2cNClN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1saXRrb3dz a2ktaWRyLWJncC10aW1lc3RhbXANCg0KSSB0aGluayB3ZSBhcmUgaW5saW5lIOKApg0KQnV0IG5v dCBhbGwgb2YgdGhlIGN1c3RvbWVycyByZXF1aXJlcyA1MG1zZWMgb3IgPCAxc2VjIGNvbnZlcmdl bmNlIHRpbWUuIEZvciBtb3N0IG9mIHRoZSB0cmFmZmljLCBzb21lIHNlY29uZHMgaXMgYWNjZXB0 YWJsZSBhbmQgdGhlcmUgaXMgbm8gbmVlZCB0byBkZXBsb3kgZGF0YXBsYW5lIHByb3RlY3Rpb24g Zm9yIHN1Y2ggcHVycG9zZS4gQnV0IGFueXdheSwgd2UgaGF2ZSB0byB0cmFjayBhYm5vcm1hbCBi ZWhhdmlvcnMgb2YgdGhlIGNvbnRyb2xwbGFuZSAocmFjZSBjb25kaXRpb25zLCBjb3JuZXIgY2Fz ZXMg4oCmKSB3aGVyZSBpdCBkb2VzIG5vdCBkbyBpdHMgam9iIGNvcnJlY3RseSDigKYNCg0KSSB3 YXMgYWxzbyB0aGlua2luZyBhYm91dCBwcm9wYWdhdGlvbiB0aW1lIG9mIEMtbXVsdGljYXN0IHJv dXRlIChhdCBsZWFzdCB0eXBlIDUvNi83KSB3aGljaCBpcyBjcml0aWNhbCDigKYgYW5kIGN1c3Rv bWVyIGNhbm5vdCB3YWl0IDMwLzUwIHNlY29uZHMgKG9yIHNvbWUgaG91cnMg4oCmIGRvbuKAmXQg bGF1Z2gsIGl04oCZcyBub3QgYSBqb2tlIOKApikgdG8gcmVjZWl2ZSB0aGUgZ3JvdXAgbWVtYmVy c2hpcCDigKYNCg0KT3VyIHByb3Bvc2FsIGRvZXMgbm90IHByb25lIGluIGFueXdheSB0byB1c2Ug Y29udHJvbHBsYW5lIG9yIGRhdGFwbGFuZSB0byBtYW5hZ2UgYW55IHJlZHVuZGFuY3kg4oCmDQoN ClRoZXJlIGlzIGEgbmVlZCB0byBtb25pdG9yIEJHUCBjb250cm9scGxhbmUgYmVoYXZpb3IgYW5k IGVzcGVjaWFsbHkgdXBkYXRlIHByb3BhZ2F0aW9uIHRpbWUgOiB0aGUgYmFzaWMgdXNlIGNhc2Ug aXMgcmVhbGx5IHRvIGVuc3VyZSB0aGF0IGV2ZXJ5dGhpbmcgZ29lcyB3ZWxsIOKApiBjb21wYXJl ZCB0byB0aGUgYmFzZSBsaW5lIHdlIGV2YWx1YXRlZCBpbiBsYWJzIG9yIHRoZW9yeS4NCg0KDQpG cm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhh bGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxNTozMA0K VG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORg0KQ2M6IEplZmZyZXkgSGFhczsgaWRyIHdn DQpTdWJqZWN0OiBSZTogZHJhZnQtbGl0a293c2tpLWlkci1iZ3AtdGltZXN0YW1wDQoNClN0ZXBo YW5lLA0KDQpJZiB5b3UgYnVpbGQgeW91ciBzZXJ2aWNlIGNvdW50aW5nIG9uIGNvbnRyb2wgcGxh bmUgY29udmVyZ2VuY2UgSSB0aGluayB5b3UgYXJlIGRvaW5nIGJhZCB0aGluZyA6KSBTb3JyeS4N Cg0KSWYgdGhpcyBkcmFmdCBpcyB0byBmdXJ0aGVyIGhlbHAgd2l0aCBzdWNoIGRlc2lnbnMgSSB3 b3VsZCBjbGVhcmx5IHN3aXRjaCB0byAibm8gc3VwcG9ydCIgaW1tZWRpYXRlbHkuIEkgaGFkIG90 aGVyIHVzZSBjYXNlcyBpbiBtaW5kIHdoaWNoIGRpZCBub3Qgc291bmQgbmVnYXRpdmUuDQoNClNw ZWNpZmljYWxseSBpbiB5b3VyIGNhc2UgaWYgb25lIFBFIG9mIG11bHRpaG9tZWQgc2l0ZSBsb29z ZXMgUEUtQ0UgeW91IGxvY2FsbHkgcHJvdGVjdCB0aGUgc2l0ZSAoMTBzIG1zIG1heCkgYW5kIHRh a2UgYWxsIHRpbWUgaXQgbmVlZHMgZm9yIEJHUCB0byBjb252ZXJnZSByZWdhcmRsZXNzIGhvdyBs b25nIGl0IHRha2VzLiBPZiBjb3Vyc2UgSSBhbSBhc3N1bWluZyBiYXNpYyBydWxlcyBsaWtlIHVu aXF1ZSBSRCBwZXIgVlJGIGluIHBsYWNlLg0KDQpUaGUgbW9zdCBpbXBvcnRhbnQgaXMgdG8gbWFp bnRhaW4gZGF0YSBwbGFuZSBjb25uZWN0aXZpdHkuDQoNCkJlc2lkZXMgSSBhbSBub3Qgc3VyZSBo b3cgdGltZXN0YW1wIHdpbGwgaGVscCB5b3UgaW4gdGhpcyBjYXNlLiBMZWF2ZSBhbG9uZSB0aGF0 IHRpbWVzdGFtcCBtYXkgbmV2ZXIgY2F0Y2ggdGhlIHJlZnJlc2ggbWF4IENQVSBsb2FkIHBlYWsg c28geW91IG1heSBpbmNvcnJlY3RseSBjb25zaWRlciBSUiBhcyBzb3VuZCB3aGVuIGl0IGlzIHJl YWxseSBub3QuDQoNCkNoZWVycywNClIuDQoNCg0KT24gVHVlLCBKdWwgMjIsIDIwMTQgYXQgOTox OSBQTSwgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRr b3dza2lAb3JhbmdlLmNvbT4+IHdyb3RlOg0KW1JlbmFtZWQgdG9waWNdDQoNCkhpIFJvYmVydCwN Cg0KPiBZb3VyIHJlc3VsdHMgbWF5IGFjdHVhbGx5IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlIG1v cmUgcHJvYmxlbXMgdGhlbiBnYWlucyB1bmZvcnR1bmF0ZWx5Lg0KDQpJIGRvbuKAmXQgcmVhbGx5 IHVuZGVyc3RhbmQgd2h5IOKApiBldmVuIGlmIFJSIGFyZSBub3QgaW4gdGhlIGRhdGFwbGFuZSAo d2hpY2ggd291bGQgYmUgdGhlIGNhc2UgZm9yIFZQTiBlbnZpcm9ubWVudCksIFJSIGJlaGF2aW9y IGlzIHJlYWxseSBpbXBvcnRhbnQgdG8gdHJhY2suDQoNCkNvbnNpZGVyIGEgTVBMUyBWUE4gc2Nl bmFyaW8sIHNvbWUgUEVzIGNvbm5lY3RlZCB0byBSUiBjbHVzdGVycyBhbmQgbWVzaGluZyBiZXR3 ZWVuIGNsdXN0ZXJzLg0KQ29uc2lkZXIgdGhhdCBvbmUgb2YgdGhlIFJSIGlzIGdldHRpbmcgc3R1 Y2sgYmVjYXVzZSBvZiBSb3V0ZS1yZWZyZXNoIHByb2Nlc3Npbmcgb2YgMk0gb2Ygcm91dGVzIG9y IGp1c3QgYnVzeSB0byBkbyBzb21ldGhpbmcgZWxzZSBkdWUgdG8gYmFkIHNjaGVkdWxpbmcgaW4g dGhlIGltcGxlbWVudGlvbiDigKYgaWYgYSBQRSBsb3NlIGEgY3VzdG9tZXIgY29ubmVjdGlvbiwg YW5kIGN1c3RvbWVyIGhhcyBhIGJhY2t1cCBjb25uZWN0aW9uIGFuZCBiYWNrdXAgUEUgaGFzIHRv IHNlbmQgYSBuZXcgQkdQIHVwZGF0ZSB0byBwcm9wYWdhdGUgdGhlIG5ldyBwYXRoLiBUaGUgdGlt ZSBmb3IgUlIgdG8gcHJvcGFnYXRlIHRoZSBCR1AgdXBkYXRlIGlzIGNyaXRpY2FsIHRvIHRyYWNr IGJlY2F1c2UgdGhpcyB3aWxsIGNvbmRpdGlvbiBjb252ZXJnZW5jZSB0aW1lIGZvciB0aGUgY3Vz dG9tZXIg4oCmDQoNClRob3VnaHRzID8NCg0KDQpTdGVwaGFuZQ0KDQoNCkZyb206IHJyYXN6dWtA Z21haWwuY29tPG1haWx0bzpycmFzenVrQGdtYWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdtYWls LmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1 aw0KU2VudDogVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMToxNQ0KVG86IExJVEtPV1NLSSBTdGVw aGFuZSBTQ0UvSUJORjsgSmVmZnJleSBIYWFzDQpDYzogaWRyIHdnDQpTdWJqZWN0OiBkcmFmdC1s aXRrb3dza2ktaWRyLXJ0Yy1pbnRlcmFzDQoNClN0ZXBoYW5lLA0KDQpJIGhhdmUgb25lIGZ1bmRh bWVudGFsIHF1ZXN0aW9uIG9uIHRoaXMgLi4uDQoNCllvdSBoYXZlIGZvY3VzZWQgb24gbWFraW5n IHN1cmUgdGhhdCBCR1AgY29udHJvbCBwbGFuZSB3b3JrcyBmYXN0IGFuZCBzb2xpZCBldGMuIFRo YXQgaXMgZ3JlYXQgYW5kIHRpbWVzdGFtcCBpZGVhIGF0IGVhY2ggQkdQIGhvcCB3b3VsZCBoZWxw Lg0KDQpIb3dldmVyIGxldCdzIG9ic2VydmUgdGhhdCBCR1AgY29udHJvbCBwbGFuZSBpcyBOT1Qg Y29uZ3J1ZW50IHdpdGggZGF0YSBwbGFuZS4gSW4gb3RoZXIgd29yZHMgeW91IG1heSBoYXZlIGEg Y2FzZSB3aGVyZSBzb21lb25lIG1heSBoYXZlIHNsb3cgYW5kIG92ZXJsb2FkZWQgUlIgYnV0IHVz ZXMgNDAgR0IgcGlwZXMgZm9yIGRhdGEgcGxhbmUgd2hpbGUgb3RoZXIgQVMgaW5zdGFsbGVkIHN1 cGVyLWh5cGVyIHg4NiBSUnMgYW5kIGhhcyAxIEdCIGxpbmtzIGZvciBkYXRhIHBsYW5lLg0KDQpZ b3VyIHJlc3VsdHMgbWF5IGFjdHVhbGx5IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlIG1vcmUgcHJv YmxlbXMgdGhlbiBnYWlucyB1bmZvcnR1bmF0ZWx5Lg0KDQpUaGUgcG9zc2libGUgc2ltcGxlIGZp eCBpcyB0byBtYW5kYXRlIHRoYXQgdGltZXN0YW1wIGlzIE9OTFkgYWRkZWQgd2hlbiB5b3VyIGNo YW5nZSBuZXh0IGhvcCB0byBzZWxmIG9yIHRoYXQgeW91IGNhbiBoYXZlIGEgbmV3IGZsYWcgIk4i IC0gTmV4dCBIb3AgU2V0IHdoaWNoIHdpbGwgaGVscCBhIGxvdCB0byBtYWtlIG1vcmUgdXNlIGNh c2VzIGZvciB0aGlzIHByb3Bvc2FsLg0KDQpCZXN0LA0KUi4NCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoN Cg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoN Cg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u LgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5 b3UuCgo= --_000_7086b517975e4f759c52cc354bccddccOPEXCLILH05corporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kIGp1c3QgdG8gYWRkIHNvbWV0aGluZyBlbHNl IGxpbmtlZCB0byBkYXRhcGxhbmUgcHJvdGVjdGlvbiDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+RXZlbiBpZiB3ZSBpbXBsZW1lbnQgYSBkYXRhcGxhbmUgcHJvdGVjdGlvbiAoUEUt Q0UsIG9yIGV2ZW4gQ09SRSksIHdlIGFyZSB1c2luZyBPQU1zIHRvIHZlcmlmeSB0aGF0IGl0IHdv cmtzIGZpbmUgYW5kIGRvZXMgaXRzIGpvYiBjb3JyZWN0bHkg4oCmIGJlY2F1c2UgbWF5YmUNCiBp biA5NSUgb2YgdGhlIGNhc2VzIGl0IHdvdWxkIHdvcmsgYW5kIHlvdSB3aWxsIGhhdmUgNTBtc2Vj IG9mIHRyYWZmaWMgbG9zcywgYnV0IGluIHNvbWUgY29uZGl0aW9ucyB5b3UgbWF5IGZhbGwgaW50 byBhIGJ1ZyBvciBjb3JuZXIgY2FzZSB0aGF0IHdpbGwgcHV0IHlvdSBhdCBzb21lIHNlY29uZHMg b3IgbW9yZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlcmUgaXTigJlzIHRoZSBzYW1lLCB3ZSBoYXZlIHNvbWUgbWVj aGFuaWMgaW4gcGxhY2UgKEJHUCksIHdlIHdhbnQgYW4gT0FNIChzaW1wbGUgcHJvYmluZykgdG8g ZW5zdXJlIHRoYXQgaXQgZG9lcyBpdOKAmXMgam9iIGNvcnJlY3RseSDigKY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhv cGUgdGhlIGNvbXBhcmlzb24gY2xhcmlmaWVzIG15IHBvc2l0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJZHIgW21haWx0bzppZHIt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+c3RlcGhhbmUubGl0a293c2tp QG9yYW5nZS5jb208YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxNToz OTxicj4NCjxiPlRvOjwvYj4gUm9iZXJ0IFJhc3p1azxicj4NCjxiPkNjOjwvYj4gSmVmZnJleSBI YWFzOyBpZHIgd2c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIGRyYWZ0LWxpdGtvd3Nr aS1pZHItYmdwLXRpbWVzdGFtcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRo aW5rIHdlIGFyZSBpbmxpbmUg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBu b3QgYWxsIG9mIHRoZSBjdXN0b21lcnMgcmVxdWlyZXMgNTBtc2VjIG9yICZsdDsgMXNlYyBjb252 ZXJnZW5jZSB0aW1lLiBGb3IgbW9zdCBvZiB0aGUgdHJhZmZpYywgc29tZSBzZWNvbmRzIGlzIGFj Y2VwdGFibGUgYW5kIHRoZXJlIGlzIG5vIG5lZWQgdG8gZGVwbG95DQogZGF0YXBsYW5lIHByb3Rl Y3Rpb24gZm9yIHN1Y2ggcHVycG9zZS4gQnV0IGFueXdheSwgd2UgaGF2ZSB0byB0cmFjayBhYm5v cm1hbCBiZWhhdmlvcnMgb2YgdGhlIGNvbnRyb2xwbGFuZSAocmFjZSBjb25kaXRpb25zLCBjb3Ju ZXIgY2FzZXMg4oCmKSB3aGVyZSBpdCBkb2VzIG5vdCBkbyBpdHMgam9iIGNvcnJlY3RseSDigKYN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSB3YXMgYWxzbyB0aGlua2luZyBhYm91dCBwcm9wYWdhdGlvbiB0aW1lIG9m IEMtbXVsdGljYXN0IHJvdXRlIChhdCBsZWFzdCB0eXBlIDUvNi83KSB3aGljaCBpcyBjcml0aWNh bCDigKYgYW5kIGN1c3RvbWVyIGNhbm5vdCB3YWl0IDMwLzUwIHNlY29uZHMgKG9yIHNvbWUgaG91 cnMNCiDigKYgZG9u4oCZdCBsYXVnaCwgaXTigJlzIG5vdCBhIGpva2Ug4oCmKSB0byByZWNlaXZl IHRoZSBncm91cCBtZW1iZXJzaGlwIOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3VyIHByb3Bvc2FsIGRvZXMgbm90 IHByb25lIGluIGFueXdheSB0byB1c2UgY29udHJvbHBsYW5lIG9yIGRhdGFwbGFuZSB0byBtYW5h Z2UgYW55IHJlZHVuZGFuY3kg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBpcyBhIG5lZWQgdG8gbW9uaXRv ciBCR1AgY29udHJvbHBsYW5lIGJlaGF2aW9yIGFuZCBlc3BlY2lhbGx5IHVwZGF0ZSBwcm9wYWdh dGlvbiB0aW1lIDogdGhlIGJhc2ljIHVzZSBjYXNlIGlzIHJlYWxseSB0byBlbnN1cmUgdGhhdCBl dmVyeXRoaW5nIGdvZXMgd2VsbA0KIOKApiBjb21wYXJlZCB0byB0aGUgYmFzZSBsaW5lIHdlIGV2 YWx1YXRlZCBpbiBsYWJzIG9yIHRoZW9yeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBycmFzenVr QGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQg MTU6MzA8YnI+DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjxicj4NCjxi PkNjOjwvYj4gSmVmZnJleSBIYWFzOyBpZHIgd2c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IGRy YWZ0LWxpdGtvd3NraS1pZHItYmdwLXRpbWVzdGFtcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPlN0ZXBoYW5lLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB5b3UgYnVpbGQgeW91ciBzZXJ2aWNlIGNvdW50aW5nIG9u IGNvbnRyb2wgcGxhbmUgY29udmVyZ2VuY2UgSSB0aGluayB5b3UgYXJlIGRvaW5nIGJhZCB0aGlu ZyA6KSBTb3JyeS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+SWYgdGhpcyBkcmFmdCBpcyB0byBmdXJ0aGVyIGhlbHAgd2l0aCBzdWNo IGRlc2lnbnMgSSB3b3VsZCBjbGVhcmx5IHN3aXRjaCB0byAmcXVvdDtubyBzdXBwb3J0JnF1b3Q7 IGltbWVkaWF0ZWx5LiBJIGhhZCBvdGhlciB1c2UgY2FzZXMgaW4gbWluZCB3aGljaCBkaWQgbm90 IHNvdW5kIG5lZ2F0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5TcGVjaWZpY2FsbHkgaW4geW91ciBjYXNlIGlmIG9uZSBQRSBvZiBtdWx0 aWhvbWVkIHNpdGUgbG9vc2VzIFBFLUNFIHlvdSBsb2NhbGx5IHByb3RlY3QgdGhlIHNpdGUgKDEw cyBtcyBtYXgpIGFuZCB0YWtlIGFsbCB0aW1lIGl0IG5lZWRzIGZvciBCR1AgdG8gY29udmVyZ2Ug cmVnYXJkbGVzcyBob3cgbG9uZyBpdCB0YWtlcy4gT2YgY291cnNlDQogSSBhbSBhc3N1bWluZyBi YXNpYyBydWxlcyBsaWtlIHVuaXF1ZSBSRCBwZXIgVlJGIGluIHBsYWNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgbW9zdCBpbXBvcnRh bnQgaXMgdG8gbWFpbnRhaW4gZGF0YSBwbGFuZSBjb25uZWN0aXZpdHkuJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc2lkZXMgSSBh bSBub3Qgc3VyZSBob3cgdGltZXN0YW1wIHdpbGwgaGVscCB5b3UgaW4gdGhpcyBjYXNlLiBMZWF2 ZSBhbG9uZSB0aGF0IHRpbWVzdGFtcCBtYXkgbmV2ZXIgY2F0Y2ggdGhlIHJlZnJlc2ggbWF4IENQ VSBsb2FkIHBlYWsgc28geW91IG1heSBpbmNvcnJlY3RseSBjb25zaWRlciBSUiBhcyBzb3VuZCB3 aGVuIGl0IGlzIHJlYWxseQ0KIG5vdC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2hlZXJzLDxicj4NClIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDk6MTkgUE0sICZsdDs8YSBocmVm PSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5z dGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bUmVuYW1lZCB0b3BpY108L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I aSBSb2JlcnQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBZb3VyIHJlc3VsdHMgbWF5IGFjdHVhbGx5IGlu IHRoZSBhYm92ZSBjYXNlIGNhc3VlDQogbW9yZSBwcm9ibGVtcyB0aGVuIGdhaW5zIHVuZm9ydHVu YXRlbHkuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHJlYWxseSB1bmRlcnN0YW5kIHdo eSDigKYgZXZlbiBpZiBSUiBhcmUgbm90IGluIHRoZSBkYXRhcGxhbmUgKHdoaWNoIHdvdWxkIGJl IHRoZSBjYXNlIGZvcg0KIFZQTiBlbnZpcm9ubWVudCksIFJSIGJlaGF2aW9yIGlzIHJlYWxseSBp bXBvcnRhbnQgdG8gdHJhY2suPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgYSBNUExTIFZQTiBzY2Vu YXJpbywgc29tZSBQRXMgY29ubmVjdGVkIHRvIFJSIGNsdXN0ZXJzIGFuZCBtZXNoaW5nIGJldHdl ZW4gY2x1c3RlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgdGhh dCBvbmUgb2YgdGhlIFJSIGlzIGdldHRpbmcgc3R1Y2sgYmVjYXVzZSBvZiBSb3V0ZS1yZWZyZXNo IHByb2Nlc3Npbmcgb2YgMk0gb2Ygcm91dGVzDQogb3IganVzdCBidXN5IHRvIGRvIHNvbWV0aGlu ZyBlbHNlIGR1ZSB0byBiYWQgc2NoZWR1bGluZyBpbiB0aGUgaW1wbGVtZW50aW9uIOKApiBpZiBh IFBFIGxvc2UgYSBjdXN0b21lciBjb25uZWN0aW9uLCBhbmQgY3VzdG9tZXIgaGFzIGEgYmFja3Vw IGNvbm5lY3Rpb24gYW5kIGJhY2t1cCBQRSBoYXMgdG8gc2VuZCBhIG5ldyBCR1AgdXBkYXRlIHRv IHByb3BhZ2F0ZSB0aGUgbmV3IHBhdGguIFRoZSB0aW1lIGZvciBSUiB0byBwcm9wYWdhdGUgdGhl IEJHUA0KIHVwZGF0ZSBpcyBjcml0aWNhbCB0byB0cmFjayBiZWNhdXNlIHRoaXMgd2lsbCBjb25k aXRpb24gY29udmVyZ2VuY2UgdGltZSBmb3IgdGhlIGN1c3RvbWVyIOKApjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRob3VnaHRzID88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5TdGVwaGFuZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJt YWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNv bTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVy dCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMToxNTxi cj4NCjxiPlRvOjwvYj4gTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBKZWZmcmV5IEhhYXM8 YnI+DQo8Yj5DYzo8L2I+IGlkciB3Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBkcmFmdC1saXRrb3dz a2ktaWRyLXJ0Yy1pbnRlcmFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPlN0ZXBoYW5lLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+SSBoYXZlIG9uZSBmdW5kYW1lbnRhbCBxdWVzdGlvbiBvbiB0aGlzIC4u Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+WW91IGhhdmUgZm9jdXNlZCBvbiBtYWtpbmcgc3VyZSB0aGF0IEJHUCBjb250cm9sIHBsYW5l IHdvcmtzIGZhc3QgYW5kIHNvbGlkIGV0Yy4gVGhhdCBpcyBncmVhdCBhbmQgdGltZXN0YW1wIGlk ZWEgYXQgZWFjaCBCR1AgaG9wIHdvdWxkIGhlbHAuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Ib3dldmVyIGxldCdzIG9ic2Vy dmUgdGhhdCBCR1AgY29udHJvbCBwbGFuZSBpcyBOT1QgY29uZ3J1ZW50IHdpdGggZGF0YSBwbGFu ZS4gSW4gb3RoZXIgd29yZHMgeW91IG1heSBoYXZlIGEgY2FzZSB3aGVyZSBzb21lb25lIG1heSBo YXZlDQogc2xvdyBhbmQgb3ZlcmxvYWRlZCBSUiBidXQgdXNlcyA0MCBHQiBwaXBlcyBmb3IgZGF0 YSBwbGFuZSB3aGlsZSBvdGhlciBBUyBpbnN0YWxsZWQgc3VwZXItaHlwZXIgeDg2IFJScyBhbmQg aGFzIDEgR0IgbGlua3MgZm9yIGRhdGEgcGxhbmUuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Zb3VyIHJlc3VsdHMgbWF5IGFj dHVhbGx5IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlIG1vcmUgcHJvYmxlbXMgdGhlbiBnYWlucyB1 bmZvcnR1bmF0ZWx5LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIHBvc3NpYmxlIHNpbXBsZSBmaXggaXMgdG8gbWFuZGF0 ZSB0aGF0IHRpbWVzdGFtcCBpcyBPTkxZIGFkZGVkIHdoZW4geW91ciBjaGFuZ2UgbmV4dCBob3Ag dG8gc2VsZiBvciB0aGF0IHlvdSBjYW4gaGF2ZSBhIG5ldyBmbGFnICZxdW90O04mcXVvdDsNCiAt IE5leHQgSG9wIFNldCB3aGljaCB3aWxsIGhlbHAgYSBsb3QgdG8gbWFrZSBtb3JlIHVzZSBjYXNl cyBmb3IgdGhpcyBwcm9wb3NhbC4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3QsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Q2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286 cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFuayB5b3UuPG86cD48L286cD48L3ByZT4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5w YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3ByZT4NCjxwcmU+ T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3ByZT4NCjxwcmU+dGhl eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv cmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+QXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8UFJFPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_7086b517975e4f759c52cc354bccddccOPEXCLILH05corporateadr_-- From nobody Tue Jul 22 12:43:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F97E1A03BB for ; Tue, 22 Jul 2014 12:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEftI7D8uIbw for ; Tue, 22 Jul 2014 12:43:43 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35891B2BE2 for ; Tue, 22 Jul 2014 12:43:42 -0700 (PDT) Received: from cfrink-sslvpn-nc.jnpr.net (66.129.241.12) by BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 22 Jul 2014 19:43:38 +0000 From: John Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Date: Tue, 22 Jul 2014 15:43:28 -0400 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BY1PR0201CA0025.namprd02.prod.outlook.com (25.160.191.163) To BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02801ACE41 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(199002)(189002)(164054003)(42186005)(85306003)(53416004)(77096002)(46102001)(110136001)(93916002)(19580395003)(229853001)(50986999)(92726001)(92566001)(97756001)(107886001)(107046002)(36756003)(81156004)(105586002)(106356001)(95666004)(76482001)(23726002)(33656002)(77982001)(50466002)(66066001)(102836001)(80022001)(87286001)(46406003)(74662001)(4396001)(50226001)(47776003)(81342001)(20776003)(64706001)(79102001)(74502001)(81542001)(57306001)(83716003)(15202345003)(99396002)(62966002)(86362001)(85852003)(83072002)(77156001)(87976001)(31966008)(83322001)(88136002)(101416001)(104166001)(21056001)(69596002)(89996001)(82746002)(15975445006)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB728; H:cfrink-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/B37bh1hV-oiCFP8V4schHWE8TcQ Subject: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:43:45 -0000 Folks, The authors have requested IDR adopt = draft-vandevelde-idr-remote-next-hop-06 as a working group document.=20 http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ Please send any comments to the list by August 8.=20 In addition to commenting on adoption of the work, you may want to = comment on whether the draft is mature enough for us to consider early = allocation of the path attribute code point. As a reminder, RFC 7120 = requires that for early allocation, "the specifications of these code = points must be stable". (Section 2.c.) The chairs and ADs also have to = "judge that there is sufficient interest in the community for early = (pre-RFC) implementation and deployment". (Section 2.d.) It's fine to be in favor of WG adoption but opposed to early allocation = at this time, or in favor of both, or against both. Being against = adoption but in favor of allocation would be a bit weird. :-)=20 Thanks, --John From nobody Tue Jul 22 12:53:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D231B28A5 for ; Tue, 22 Jul 2014 12:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIfu4xD-Boon for ; Tue, 22 Jul 2014 12:52:57 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0A41A01BD for ; Tue, 22 Jul 2014 12:52:57 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id h3so4586658igd.3 for ; Tue, 22 Jul 2014 12:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fWxlkUbEdm1rFY8mZdc/PoODHfn0NvRPRJjN75JEsb8=; b=FAIrYKHNYPzQqcVUnRc91WHYXINCS6H7am9qVi+3ZTLp8/xpxgJSztEFnzKinuYiNR i2Hz/9Y0f2crcHU+7G19nG31N2uWVA8BO+8oY11mRXd9mNud4elOqh0lgfKm04gLvA4K nAG6lNHUbMP7qcD7nOTy22x7ZAVJZhpO/NAFUHPwUQ0Gkgh8ga6L8Dk4srinBteu7zux F6hQHn5ot6Ua6WjxRDey2wcbRdD0IZDk35YxJfAu2xbeOAZgLVFdwVaqtfTgEZy6rnR3 IEjddwj1Vetj6uWqvtn6h8FYTGIzIG6qpL8LikmR7uAbfe9mBDO90k1db2TDiMOvyYYN Qstw== MIME-Version: 1.0 X-Received: by 10.50.88.37 with SMTP id bd5mr42875175igb.1.1406058776822; Tue, 22 Jul 2014 12:52:56 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 22 Jul 2014 12:52:56 -0700 (PDT) In-Reply-To: <16559_1406057911_53CEBDB7_16559_6108_1_9E32478DFA9976438E7A22F69B08FF920444B7@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <16559_1406057911_53CEBDB7_16559_6108_1_9E32478DFA9976438E7A22F69B08FF920444B7@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Tue, 22 Jul 2014 21:52:56 +0200 X-Google-Sender-Auth: jZdqaM91qlc84rsNP5Pl1LwFyIc Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=089e011777ffed097004fecd9103 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/JTpQtWqg9Om91dFqlgzBKkmQAlI Cc: Jeffrey Haas , idr wg Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:52:59 -0000 --089e011777ffed097004fecd9103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ahh ok .. then we are slowly getting more on the same page. Well at least we are on the same bookshelf now :) If this is your application why not use BGP Diagnostic Message for it now part of BGP Operational Message draft which is an IDR WG doc ? http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 - - Someone at the IDR I think asked in the room that this should be at least a separate SAFI. But till we go there let's see if you see problems with adding this functionality to Operational Message. Thx, R. On Tue, Jul 22, 2014 at 9:38 PM, wrote: > I think we are inline =E2=80=A6 > > But not all of the customers requires 50msec or < 1sec convergence time. > For most of the traffic, some seconds is acceptable and there is no need = to > deploy dataplane protection for such purpose. But anyway, we have to trac= k > abnormal behaviors of the controlplane (race conditions, corner cases =E2= =80=A6) > where it does not do its job correctly =E2=80=A6 > > > > I was also thinking about propagation time of C-multicast route (at least > type 5/6/7) which is critical =E2=80=A6 and customer cannot wait 30/50 se= conds (or > some hours =E2=80=A6 don=E2=80=99t laugh, it=E2=80=99s not a joke =E2=80= =A6) to receive the group > membership =E2=80=A6 > > > > Our proposal does not prone in anyway to use controlplane or dataplane to > manage any redundancy =E2=80=A6 > > > > There is a need to monitor BGP controlplane behavior and especially updat= e > propagation time : the basic use case is really to ensure that everything > goes well =E2=80=A6 compared to the base line we evaluated in labs or the= ory. > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 15:30 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* Jeffrey Haas; idr wg > *Subject:* Re: draft-litkowski-idr-bgp-timestamp > > > > Stephane, > > > > If you build your service counting on control plane convergence I think > you are doing bad thing :) Sorry. > > > > If this draft is to further help with such designs I would clearly switch > to "no support" immediately. I had other use cases in mind which did not > sound negative. > > > > Specifically in your case if one PE of multihomed site looses PE-CE you > locally protect the site (10s ms max) and take all time it needs for BGP = to > converge regardless how long it takes. Of course I am assuming basic rule= s > like unique RD per VRF in place. > > > > The most important is to maintain data plane connectivity. > > > > Besides I am not sure how timestamp will help you in this case. Leave > alone that timestamp may never catch the refresh max CPU load peak so you > may incorrectly consider RR as sound when it is really not. > > > > Cheers, > R. > > > > > > On Tue, Jul 22, 2014 at 9:19 PM, wrote: > > [Renamed topic] > > > > Hi Robert, > > > > > Your results may actually in the above case casue more problems then > gains unfortunately. > > > > I don=E2=80=99t really understand why =E2=80=A6 even if RR are not in the= dataplane (which > would be the case for VPN environment), RR behavior is really important t= o > track. > > > > Consider a MPLS VPN scenario, some PEs connected to RR clusters and > meshing between clusters. > > Consider that one of the RR is getting stuck because of Route-refresh > processing of 2M of routes or just busy to do something else due to bad > scheduling in the implemention =E2=80=A6 if a PE lose a customer connecti= on, and > customer has a backup connection and backup PE has to send a new BGP upda= te > to propagate the new path. The time for RR to propagate the BGP update is > critical to track because this will condition convergence time for the > customer =E2=80=A6 > > > > Thoughts ? > > > > > > Stephane > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 11:15 > *To:* LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas > *Cc:* idr wg > *Subject:* draft-litkowski-idr-rtc-interas > > > > Stephane, > > > > I have one fundamental question on this ... > > > > You have focused on making sure that BGP control plane works fast and > solid etc. That is great and timestamp idea at each BGP hop would help. > > > > However let's observe that BGP control plane is NOT congruent with data > plane. In other words you may have a case where someone may have slow and > overloaded RR but uses 40 GB pipes for data plane while other AS installe= d > super-hyper x86 RRs and has 1 GB links for data plane. > > > > Your results may actually in the above case casue more problems then gain= s > unfortunately. > > > > The possible simple fix is to mandate that timestamp is ONLY added when > your change next hop to self or that you can have a new flag "N" - Next H= op > Set which will help a lot to make more use cases for this proposal. > > > > Best, > > R. > > > > > > > > _________________________________________________________________________= ________________________________________________ > > > > 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. > > > > 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. > > > > _________________________________________________________________________= ________________________________________________ > > 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. > > 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. > > --089e011777ffed097004fecd9103 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= Ahh ok .. then we are slowly getting more on the same page. Well at least w= e are on the same bookshelf now :)

If this is your a= pplication why not use BGP Diagnostic Message for it now part of BGP Operat= ional Message draft which is an IDR WG doc ?=C2=A0

http://tools.ietf.org/html/draft-ietf-idr= -operational-message-00

- -=C2=A0

Someone at the IDR I think asked in the room that this should be= at least a separate SAFI. But till we go there let's see if you see pr= oblems with adding this functionality to Operational Message.
Thx,
R.



On Tue, Jul 22, 2014 a= t 9:38 PM, <stephane.litkowski@orange.com> wrot= e:

I think we are inline =E2= =80=A6

But not all of the custom= ers requires 50msec or < 1sec convergence time. For most of the traffic,= some seconds is acceptable and there is no need to deploy dataplane protection for such purpose. But anyway, we have to track abnorm= al behaviors of the controlplane (race conditions, corner cases =E2=80=A6) = where it does not do its job correctly =E2=80=A6

=C2=A0

I was also thinking about= propagation time of C-multicast route (at least type 5/6/7) which is criti= cal =E2=80=A6 and customer cannot wait 30/50 seconds (or some hours =E2=80=A6 don=E2=80=99t laugh, it=E2=80=99s not a joke =E2=80=A6) to recei= ve the group membership =E2=80=A6

=C2=A0

Our proposal does not pro= ne in anyway to use controlplane or dataplane to manage any redundancy =E2= =80=A6

=C2=A0

There is a need to monito= r BGP controlplane behavior and especially update propagation time : the ba= sic use case is really to ensure that everything goes well =E2=80=A6 compared to the base line we evaluated in labs or theory.=

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 15:30
To: LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas; idr wg
Subject: Re: draft-litkowski-idr-bgp-timestamp<= /p>

=C2=A0

= Stephane,

= =C2=A0

= If you build your service counting on control plane convergence I think you= are doing bad thing :) Sorry.=C2=A0

= =C2=A0

= If this draft is to further help with such designs I would clearly switch t= o "no support" immediately. I had other use cases in mind which d= id not sound negative.

= =C2=A0

= Specifically in your case if one PE of multihomed site looses PE-CE you loc= ally protect the site (10s ms max) and take all time it needs for BGP to co= nverge regardless how long it takes. Of course I am assuming basic rules like unique RD per VRF in place.

= =C2=A0

= The most important is to maintain data plane connectivity.=C2=A0<= /u>

= =C2=A0

= Besides I am not sure how timestamp will help you in this case. Leave alone= that timestamp may never catch the refresh max CPU load peak so you may in= correctly consider RR as sound when it is really not.=C2=A0

= =C2=A0

= Cheers,
R.

= =C2=A0

=C2=A0<= /p>

On Tue, Jul 22, 2014 at 9:19 PM, <stephane.litkowski@oran= ge.com> wrote:

[Renamed topic]=

=C2=A0

Hi Robert,<= u>

=C2=A0

> Your results may actually in the abo= ve case casue more problems then gains unfortunately.=C2=A0

=C2=A0

I don=E2=80=99t really un= derstand why =E2=80=A6 even if RR are not in the dataplane (which would be = the case for VPN environment), RR behavior is really important to track.<= u>

=C2=A0

Consider a MPLS VPN scena= rio, some PEs connected to RR clusters and meshing between clusters.=

Consider that one of the = RR is getting stuck because of Route-refresh processing of 2M of routes or just busy to do something else due to bad scheduling in the implementio= n =E2=80=A6 if a PE lose a customer connection, and customer has a backup c= onnection and backup PE has to send a new BGP update to propagate the new p= ath. The time for RR to propagate the BGP update is critical to track because this will condition convergence time f= or the customer =E2=80=A6

=C2=A0

Thoughts ?<= u>

=C2=A0

=C2=A0

Stephane=

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 11:15
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas
Cc: idr wg
Subject: draft-litkowski-idr-rtc-interas

=C2=A0

= Stephane,

= =C2=A0

= I have one fundamental question on this ...

= =C2=A0

= You have focused on making sure that BGP control plane works fast and solid= etc. That is great and timestamp idea at each BGP hop would help.=C2=A0

= =C2=A0

= However let's observe that BGP control plane is NOT congruent with data= plane. In other words you may have a case where someone may have slow and overloaded RR but uses 40 GB pipes for data plane while other AS = installed super-hyper x86 RRs and has 1 GB links for data plane.=C2=A0

= =C2=A0

= Your results may actually in the above case casue more problems then gains = unfortunately.=C2=A0

= =C2=A0

= The possible simple fix is to mandate that timestamp is ONLY added when you= r change next hop to self or that you can have a new flag "N" - Next Hop Set which will help a lot to make more use cases for this propo= sal.=C2=A0

= =C2=A0

= Best,

= R.

= =C2=A0

= =C2=A0

= =C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


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.

=C2=A0

______________________________________________________________________=
___________________________________________________

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.

--089e011777ffed097004fecd9103-- From nobody Tue Jul 22 12:59:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF641A0185 for ; Tue, 22 Jul 2014 12:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pbrxv0gIWhjC for ; Tue, 22 Jul 2014 12:59:12 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3F31A0255 for ; Tue, 22 Jul 2014 12:59:12 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id at20so132331iec.8 for ; Tue, 22 Jul 2014 12:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7Vurv/8pjRSGXSduKkr0yXkmZkaUP5sIF2FH3x+jnZo=; b=fIsOB3symtbg3lXVZIWTGsR7R1jEy9zt4KVNIhXpiSQadpwx83xI1M91hC143ATL6K nfxTsflaKZ501RMljbN7U2ShQ+7btH+I3SrTS71B6iTDWOZCNYR5dFOwsbwk8UewM9Lj nU1xEXxgWNogOrE5w1TGlhXRToVrTEmfT3ebODzXK4sb6hDTYc8FhCbpe4lKU3IgE2nU WDxUEFjb0z2j3LWdAVJN14l+tTJNlZcQsbWlv2xn4WJKTeznx5+lvFav7WcDhtH0UPwI p9M8YjqgC0iUm9bjBmzb8OdUTbLtDzTZ6K5BihlAc8j/jh3sGVJf9AEfGgp2PKiDMCsC SFcg== MIME-Version: 1.0 X-Received: by 10.42.240.20 with SMTP id ky20mr17284664icb.97.1406059150465; Tue, 22 Jul 2014 12:59:10 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 22 Jul 2014 12:59:10 -0700 (PDT) In-Reply-To: <5637_1406058199_53CEBED7_5637_5507_1_7086b517-975e-4f75-9c52-cc354bccddcc@OPEXCLILH05.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <16559_1406057911_53CEBDB7_16559_6108_1_9E32478DFA9976438E7A22F69B08FF920444B7@OPEXCLILM34.corporate.adroot.infra.ftgroup> <5637_1406058199_53CEBED7_5637_5507_1_7086b517-975e-4f75-9c52-cc354bccddcc@OPEXCLILH05.corporate.adroot.infra.ftgroup> Date: Tue, 22 Jul 2014 21:59:10 +0200 X-Google-Sender-Auth: 5xzm3qbz6aY8uxlvNofiJVzlIC0 Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=001a113328f2325eec04fecda826 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/IV8Oam5cK0F26glzl6LJAsG8cbI Cc: Jeffrey Haas , idr wg Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:59:15 -0000 --001a113328f2325eec04fecda826 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I do see very crisp what you are trying to accomplish. I am concerned that you are proposing wrong tool for it. At least even if there is some merit to timestamp as an indicator (which I am not that convinced) I think just new attribute to be added when operator seems fit to current UPDATEs seems not perfect. To make the decision of which paths to choose I would consider other information like CPU usage of RR ? Or free RAM to be able to easily tell that one RR may have some memory leak etc ... and those information are (I hope) already being collected by your monitoring stations. How timestamps are going to ignore all of those and replace to hit best path selection ? =E2=80=8Br.=E2=80=8B On Tue, Jul 22, 2014 at 9:43 PM, wrote: > And just to add something else linked to dataplane protection =E2=80=A6 > > Even if we implement a dataplane protection (PE-CE, or even CORE), we are > using OAMs to verify that it works fine and does its job correctly =E2=80= =A6 > because maybe in 95% of the cases it would work and you will have 50msec = of > traffic loss, but in some conditions you may fall into a bug or corner ca= se > that will put you at some seconds or more. > > > > Here it=E2=80=99s the same, we have some mechanic in place (BGP), we want= an OAM > (simple probing) to ensure that it does it=E2=80=99s job correctly =E2=80= =A6 > > > > Hope the comparison clarifies my position. > > > > > > *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of * > stephane.litkowski@orange.com > *Sent:* Tuesday, July 22, 2014 15:39 > *To:* Robert Raszuk > > *Cc:* Jeffrey Haas; idr wg > *Subject:* Re: [Idr] draft-litkowski-idr-bgp-timestamp > > > > I think we are inline =E2=80=A6 > > But not all of the customers requires 50msec or < 1sec convergence time. > For most of the traffic, some seconds is acceptable and there is no need = to > deploy dataplane protection for such purpose. But anyway, we have to trac= k > abnormal behaviors of the controlplane (race conditions, corner cases =E2= =80=A6) > where it does not do its job correctly =E2=80=A6 > > > > I was also thinking about propagation time of C-multicast route (at least > type 5/6/7) which is critical =E2=80=A6 and customer cannot wait 30/50 se= conds (or > some hours =E2=80=A6 don=E2=80=99t laugh, it=E2=80=99s not a joke =E2=80= =A6) to receive the group > membership =E2=80=A6 > > > > Our proposal does not prone in anyway to use controlplane or dataplane to > manage any redundancy =E2=80=A6 > > > > There is a need to monitor BGP controlplane behavior and especially updat= e > propagation time : the basic use case is really to ensure that everything > goes well =E2=80=A6 compared to the base line we evaluated in labs or the= ory. > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 15:30 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* Jeffrey Haas; idr wg > *Subject:* Re: draft-litkowski-idr-bgp-timestamp > > > > Stephane, > > > > If you build your service counting on control plane convergence I think > you are doing bad thing :) Sorry. > > > > If this draft is to further help with such designs I would clearly switch > to "no support" immediately. I had other use cases in mind which did not > sound negative. > > > > Specifically in your case if one PE of multihomed site looses PE-CE you > locally protect the site (10s ms max) and take all time it needs for BGP = to > converge regardless how long it takes. Of course I am assuming basic rule= s > like unique RD per VRF in place. > > > > The most important is to maintain data plane connectivity. > > > > Besides I am not sure how timestamp will help you in this case. Leave > alone that timestamp may never catch the refresh max CPU load peak so you > may incorrectly consider RR as sound when it is really not. > > > > Cheers, > R. > > > > > > On Tue, Jul 22, 2014 at 9:19 PM, wrote: > > [Renamed topic] > > > > Hi Robert, > > > > > Your results may actually in the above case casue more problems then > gains unfortunately. > > > > I don=E2=80=99t really understand why =E2=80=A6 even if RR are not in the= dataplane (which > would be the case for VPN environment), RR behavior is really important t= o > track. > > > > Consider a MPLS VPN scenario, some PEs connected to RR clusters and > meshing between clusters. > > Consider that one of the RR is getting stuck because of Route-refresh > processing of 2M of routes or just busy to do something else due to bad > scheduling in the implemention =E2=80=A6 if a PE lose a customer connecti= on, and > customer has a backup connection and backup PE has to send a new BGP upda= te > to propagate the new path. The time for RR to propagate the BGP update is > critical to track because this will condition convergence time for the > customer =E2=80=A6 > > > > Thoughts ? > > > > > > Stephane > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 11:15 > *To:* LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas > *Cc:* idr wg > *Subject:* draft-litkowski-idr-rtc-interas > > > > Stephane, > > > > I have one fundamental question on this ... > > > > You have focused on making sure that BGP control plane works fast and > solid etc. That is great and timestamp idea at each BGP hop would help. > > > > However let's observe that BGP control plane is NOT congruent with data > plane. In other words you may have a case where someone may have slow and > overloaded RR but uses 40 GB pipes for data plane while other AS installe= d > super-hyper x86 RRs and has 1 GB links for data plane. > > > > Your results may actually in the above case casue more problems then gain= s > unfortunately. > > > > The possible simple fix is to mandate that timestamp is ONLY added when > your change next hop to self or that you can have a new flag "N" - Next H= op > Set which will help a lot to make more use cases for this proposal. > > > > Best, > > R. > > > > > > > > _________________________________________________________________________= ________________________________________________ > > > > 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. > > > > 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. > > > > _________________________________________________________________________= ________________________________________________ > > > > 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. > > > > 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. > > ________________________________________________________________________= _________________________________________________ > > 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. > > 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. > > --001a113328f2325eec04fecda826 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I do see very crisp = what you are trying to accomplish.=C2=A0

I am concerned that you are proposing= wrong tool for it. At least even if there is some merit to timestamp as an= indicator (which I am not that convinced) I think just new attribute to be= added when operator seems fit to current UPDATEs seems not perfect.=C2=A0<= /div>

To make the decision of which paths t= o choose I would consider other information like CPU usage of RR ? Or free = RAM to be able to easily tell that one RR may have some memory leak etc ...= and those information are (I hope) already being collected by your monitor= ing stations.=C2=A0

How timestamps are going to ignore al= l of those and replace to hit best path selection ?=C2=A0

= =E2=80=8Br.=E2=80=8B


On Tue, Jul 22, 2014 at 9:43 PM, <stephane.litkowski@orange.com> wrote:

And just to add something= else linked to dataplane protection =E2=80=A6

Even if we implement a da= taplane protection (PE-CE, or even CORE), we are using OAMs to verify that = it works fine and does its job correctly =E2=80=A6 because maybe in 95% of the cases it would work and you will have 50msec of traffic loss= , but in some conditions you may fall into a bug or corner case that will p= ut you at some seconds or more.

=C2=A0

Here it=E2=80=99s the sam= e, we have some mechanic in place (BGP), we want an OAM (simple probing) to= ensure that it does it=E2=80=99s job correctly =E2=80=A6

=C2=A0

Hope the comparison clari= fies my position.

=C2=A0

=C2=A0

From: Idr [mai= lto:idr-bounces@i= etf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Tuesday, July 22, 2014 15:39
To: Robert Raszuk


Cc: Jeffrey Haas; idr wg
Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp=

=C2=A0

I think we are inline =E2= =80=A6

But not all of the custom= ers requires 50msec or < 1sec convergence time. For most of the traffic,= some seconds is acceptable and there is no need to deploy dataplane protection for such purpose. But anyway, we have to track abnorm= al behaviors of the controlplane (race conditions, corner cases =E2=80=A6) = where it does not do its job correctly =E2=80=A6

=C2=A0

I was also thinking about= propagation time of C-multicast route (at least type 5/6/7) which is criti= cal =E2=80=A6 and customer cannot wait 30/50 seconds (or some hours =E2=80=A6 don=E2=80=99t laugh, it=E2=80=99s not a joke =E2=80=A6) to recei= ve the group membership =E2=80=A6

=C2=A0

Our proposal does not pro= ne in anyway to use controlplane or dataplane to manage any redundancy =E2= =80=A6

=C2=A0

There is a need to monito= r BGP controlplane behavior and especially update propagation time : the ba= sic use case is really to ensure that everything goes well =E2=80=A6 compared to the base line we evaluated in labs or theory.=

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 15:30
To: LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas; idr wg
Subject: Re: draft-litkowski-idr-bgp-timestamp<= /p>

=C2=A0

= Stephane,

= =C2=A0

= If you build your service counting on control plane convergence I think you= are doing bad thing :) Sorry.=C2=A0

= =C2=A0

= If this draft is to further help with such designs I would clearly switch t= o "no support" immediately. I had other use cases in mind which d= id not sound negative.

= =C2=A0

= Specifically in your case if one PE of multihomed site looses PE-CE you loc= ally protect the site (10s ms max) and take all time it needs for BGP to co= nverge regardless how long it takes. Of course I am assuming basic rules like unique RD per VRF in place.

= =C2=A0

= The most important is to maintain data plane connectivity.=C2=A0<= /u>

= =C2=A0

= Besides I am not sure how timestamp will help you in this case. Leave alone= that timestamp may never catch the refresh max CPU load peak so you may in= correctly consider RR as sound when it is really not.=C2=A0

= =C2=A0

= Cheers,
R.

= =C2=A0

=C2=A0<= /p>

On Tue, Jul 22, 2014 at 9:19 PM, <stephane.litkowski@oran= ge.com> wrote:

[Renamed topic]=

=C2=A0

Hi Robert,<= u>

=C2=A0

> Your results may actually in the abo= ve case casue more problems then gains unfortunately.=C2=A0

=C2=A0

I don=E2=80=99t really un= derstand why =E2=80=A6 even if RR are not in the dataplane (which would be = the case for VPN environment), RR behavior is really important to track.<= u>

=C2=A0

Consider a MPLS VPN scena= rio, some PEs connected to RR clusters and meshing between clusters.=

Consider that one of the = RR is getting stuck because of Route-refresh processing of 2M of routes or just busy to do something else due to bad scheduling in the implementio= n =E2=80=A6 if a PE lose a customer connection, and customer has a backup c= onnection and backup PE has to send a new BGP update to propagate the new p= ath. The time for RR to propagate the BGP update is critical to track because this will condition convergence time f= or the customer =E2=80=A6

=C2=A0

Thoughts ?<= u>

=C2=A0

=C2=A0

Stephane=

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 11:15
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas
Cc: idr wg
Subject: draft-litkowski-idr-rtc-interas

=C2=A0

= Stephane,

= =C2=A0

= I have one fundamental question on this ...

= =C2=A0

= You have focused on making sure that BGP control plane works fast and solid= etc. That is great and timestamp idea at each BGP hop would help.=C2=A0

= =C2=A0

= However let's observe that BGP control plane is NOT congruent with data= plane. In other words you may have a case where someone may have slow and overloaded RR but uses 40 GB pipes for data plane while other AS = installed super-hyper x86 RRs and has 1 GB links for data plane.=C2=A0

= =C2=A0

= Your results may actually in the above case casue more problems then gains = unfortunately.=C2=A0

= =C2=A0

= The possible simple fix is to mandate that timestamp is ONLY added when you= r change next hop to self or that you can have a new flag "N" - Next Hop Set which will help a lot to make more use cases for this propo= sal.=C2=A0

= =C2=A0

= Best,

= R.

= =C2=A0

= =C2=A0

= =C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


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.

=C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les 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.

--001a113328f2325eec04fecda826-- From nobody Tue Jul 22 13:02:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7990C1A00E6 for ; Tue, 22 Jul 2014 13:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.283 X-Spam-Level: **** X-Spam-Status: No, score=4.283 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcVC-PWmUC2T for ; Tue, 22 Jul 2014 13:02:49 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 98BC91A023E for ; Tue, 22 Jul 2014 13:02:49 -0700 (PDT) Received: (qmail 4018 invoked by uid 0); 22 Jul 2014 20:02:48 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 22 Jul 2014 20:02:48 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Ve2d1o01E2SSUrH01e2gQC; Tue, 22 Jul 2014 20:02:46 -0600 X-Authority-Analysis: v=2.1 cv=fudPOjIf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=WrhVjQHxoPwA:10 a=V6OyFcxcOfIA:10 a=HFCU6gKsb0MA:10 a=jPJDawAOAc8A:10 a=_l4uJm6h9gAA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=o2uywJa2AofgBqZ8sk8A:9 a=mFyHDrcPJccA:10 a=33rK67OTR_gA:10 a=lZB815dzVvQA:10 a=Z1xvONjoiUYA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=XaM/ggkS7Hv5/NjeXNC7Kl9sVi6mjJJxLqd6Qdj+0Zk=; b=nu6CWBjIMXdV/hSP5XXAuueq7EB0Rvk0588WkOBVQMEjUCTQCBr6UQsI9PXmaTqRWwxoFlvxOM5FYN3TFXk0LoeGHVKUoODu8d1uJyQ+n550RbKjneGJJ2zC03PL2CJe; Received: from box313.bluehost.com ([69.89.31.113]:43165 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X9gGl-0005Hj-5I; Tue, 22 Jul 2014 14:02:39 -0600 Message-ID: <53CEC369.3010907@labn.net> Date: Tue, 22 Jul 2014 16:02:49 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lizhenbin , "draft-li-idr-mpls-path-programming@tools.ietf.org" References: <53CE7F8A.1090700@labn.net> <5A5B4DE12C0DAC44AF501CD9A2B01A8D08232400@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08232400@nkgeml506-mbx.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jC0LINZlwhhP9D0yOhSS2M-wkr0 Cc: "idr@ietf.org" Subject: Re: [Idr] =?gb2312?b?tPC4tDogUXVlc3Rpb24gZnJvbSBzZXNzaW9uIG9uIGRyYWZ0?= =?gb2312?b?LXhsaS1pZHItbXBscy1wYXRoLXByb2dyYW1taW5n?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:02:51 -0000 I think it would be better to have the S bit out of scope of the document. There are other mechanisms that cover tunnel initiation and I'm not sure we need another... Lou On 7/22/2014 11:26 AM, Lizhenbin wrote: > Hi Lou, > You are right. Sorry for my missing the point. The S flag is designed to be able to trigger transport tunnel setup. The tunnel setup maybe fails. If so, there can be two possible process depending on local policy: > -- The BGP route will not be active since the specified tunel is UP. > -- The BGP route can be active using alternative best-effort LSP tunnel existing in the ingress PE. > There exists similiar policy implementation by multiple vendor. I think it is policy which is out of scope of the document. > > Thanks & Regards, > Robin > > > > > > ________________________________________ > ·¢¼þÈË: Lou Berger [lberger@labn.net] > ·¢ËÍʱ¼ä: 2014Äê7ÔÂ22ÈÕ 23:13 > ÊÕ¼þÈË: draft-li-idr-mpls-path-programming@tools.ietf.org > ³­ËÍ: idr@ietf.org > Ö÷Ìâ: Question from session on draft-xli-idr-mpls-path-programming > > Hi, > Since we weren't able to close this in the session, I thought I'd > ask my question here. The question was simply what is supposed to > happen (from a service model perspective) when requested tunnel setup, > or for that matter, any other type of 'path programming' fails? > > The text in the draft that caught my eye is: > > This document defines the following flags: > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | reserved |S| > +-+-+-+-+-+-+-+-+ > > + Unicast Tunnel Setup Required (S) > > > If the S flag is not set, the client node is just to map the service > path to the corresponding tunnel. If the S flag is set, the client > node MUST set up the tunnel according to the tunnel identifier and > the tunnel specific attribute firstly. Then it maps the service path > to the corresponding tunnel. > > > Thanks, > Lou From nobody Tue Jul 22 13:06:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D631A01E4 for ; Tue, 22 Jul 2014 13:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGxWCI7SsuIv for ; Tue, 22 Jul 2014 13:06:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1321A0119 for ; Tue, 22 Jul 2014 13:06:35 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 29C8F3B57B3; Tue, 22 Jul 2014 22:06:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id F222F15805A; Tue, 22 Jul 2014 22:06:33 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 22:06:34 +0200 From: To: Robert Raszuk Thread-Topic: draft-litkowski-idr-bgp-timestamp Thread-Index: AQHPpedmJH0/NfV4QnGw7fCPCrH3LpushMeQ Date: Tue, 22 Jul 2014 20:06:32 +0000 Message-ID: <23971_1406059594_53CEC44A_23971_10374_1_9E32478DFA9976438E7A22F69B08FF92044520@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <16559_1406057911_53CEBDB7_16559_6108_1_9E32478DFA9976438E7A22F69B08FF920444B7@OPEXCLILM34.corporate.adroot.infra.ftgroup> <5637_1406058199_53CEBED7_5637_5507_1_7086b517-975e-4f75-9c52-cc354bccddcc@OPEXCLILH05.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.5] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92044520OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.180021 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/IUU6rD-mZ7iMUvki5zvyPqrKBuM Cc: Jeffrey Haas , idr wg Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:06:38 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92044520OPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8gbm8g4oCmIHRoaXMgaGF2ZSBub3RoaW5nIHRvIGRlYWwgd2l0aCBiZXN0IHBhdGggc2VsZWN0 aW9uIOKApiB0aW1lc3RhbXAgYXJlIGp1c3QgaW5mb3JtYXRpb25zIHRvIGJlIHVzZWQgYnkgZXh0 ZXJuYWwgdG9vbC4NClRTIGF0dHJpYnV0ZSBpcyBub3QgcGFydCBvZiBwYXRoIGNvbXBhcmlzb24u DQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9u IEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDE1 OjU5DQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GDQpDYzogSmVmZnJleSBIYWFzOyBp ZHIgd2cNClN1YmplY3Q6IFJlOiBkcmFmdC1saXRrb3dza2ktaWRyLWJncC10aW1lc3RhbXANCg0K DQpJIGRvIHNlZSB2ZXJ5IGNyaXNwIHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gYWNjb21wbGlzaC4N Cg0KSSBhbSBjb25jZXJuZWQgdGhhdCB5b3UgYXJlIHByb3Bvc2luZyB3cm9uZyB0b29sIGZvciBp dC4gQXQgbGVhc3QgZXZlbiBpZiB0aGVyZSBpcyBzb21lIG1lcml0IHRvIHRpbWVzdGFtcCBhcyBh biBpbmRpY2F0b3IgKHdoaWNoIEkgYW0gbm90IHRoYXQgY29udmluY2VkKSBJIHRoaW5rIGp1c3Qg bmV3IGF0dHJpYnV0ZSB0byBiZSBhZGRlZCB3aGVuIG9wZXJhdG9yIHNlZW1zIGZpdCB0byBjdXJy ZW50IFVQREFURXMgc2VlbXMgbm90IHBlcmZlY3QuDQoNClRvIG1ha2UgdGhlIGRlY2lzaW9uIG9m IHdoaWNoIHBhdGhzIHRvIGNob29zZSBJIHdvdWxkIGNvbnNpZGVyIG90aGVyIGluZm9ybWF0aW9u IGxpa2UgQ1BVIHVzYWdlIG9mIFJSID8gT3IgZnJlZSBSQU0gdG8gYmUgYWJsZSB0byBlYXNpbHkg dGVsbCB0aGF0IG9uZSBSUiBtYXkgaGF2ZSBzb21lIG1lbW9yeSBsZWFrIGV0YyAuLi4gYW5kIHRo b3NlIGluZm9ybWF0aW9uIGFyZSAoSSBob3BlKSBhbHJlYWR5IGJlaW5nIGNvbGxlY3RlZCBieSB5 b3VyIG1vbml0b3Jpbmcgc3RhdGlvbnMuDQoNCkhvdyB0aW1lc3RhbXBzIGFyZSBnb2luZyB0byBp Z25vcmUgYWxsIG9mIHRob3NlIGFuZCByZXBsYWNlIHRvIGhpdCBiZXN0IHBhdGggc2VsZWN0aW9u ID8NCg0K4oCLci7igIsNCg0KT24gVHVlLCBKdWwgMjIsIDIwMTQgYXQgOTo0MyBQTSwgPHN0ZXBo YW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3Jhbmdl LmNvbT4+IHdyb3RlOg0KQW5kIGp1c3QgdG8gYWRkIHNvbWV0aGluZyBlbHNlIGxpbmtlZCB0byBk YXRhcGxhbmUgcHJvdGVjdGlvbiDigKYNCkV2ZW4gaWYgd2UgaW1wbGVtZW50IGEgZGF0YXBsYW5l IHByb3RlY3Rpb24gKFBFLUNFLCBvciBldmVuIENPUkUpLCB3ZSBhcmUgdXNpbmcgT0FNcyB0byB2 ZXJpZnkgdGhhdCBpdCB3b3JrcyBmaW5lIGFuZCBkb2VzIGl0cyBqb2IgY29ycmVjdGx5IOKApiBi ZWNhdXNlIG1heWJlIGluIDk1JSBvZiB0aGUgY2FzZXMgaXQgd291bGQgd29yayBhbmQgeW91IHdp bGwgaGF2ZSA1MG1zZWMgb2YgdHJhZmZpYyBsb3NzLCBidXQgaW4gc29tZSBjb25kaXRpb25zIHlv dSBtYXkgZmFsbCBpbnRvIGEgYnVnIG9yIGNvcm5lciBjYXNlIHRoYXQgd2lsbCBwdXQgeW91IGF0 IHNvbWUgc2Vjb25kcyBvciBtb3JlLg0KDQpIZXJlIGl04oCZcyB0aGUgc2FtZSwgd2UgaGF2ZSBz b21lIG1lY2hhbmljIGluIHBsYWNlIChCR1ApLCB3ZSB3YW50IGFuIE9BTSAoc2ltcGxlIHByb2Jp bmcpIHRvIGVuc3VyZSB0aGF0IGl0IGRvZXMgaXTigJlzIGpvYiBjb3JyZWN0bHkg4oCmDQoNCkhv cGUgdGhlIGNvbXBhcmlzb24gY2xhcmlmaWVzIG15IHBvc2l0aW9uLg0KDQoNCkZyb206IElkciBb bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb20+DQpTZW50OiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDE1 OjM5DQpUbzogUm9iZXJ0IFJhc3p1aw0KDQpDYzogSmVmZnJleSBIYWFzOyBpZHIgd2cNClN1Ympl Y3Q6IFJlOiBbSWRyXSBkcmFmdC1saXRrb3dza2ktaWRyLWJncC10aW1lc3RhbXANCg0KSSB0aGlu ayB3ZSBhcmUgaW5saW5lIOKApg0KQnV0IG5vdCBhbGwgb2YgdGhlIGN1c3RvbWVycyByZXF1aXJl cyA1MG1zZWMgb3IgPCAxc2VjIGNvbnZlcmdlbmNlIHRpbWUuIEZvciBtb3N0IG9mIHRoZSB0cmFm ZmljLCBzb21lIHNlY29uZHMgaXMgYWNjZXB0YWJsZSBhbmQgdGhlcmUgaXMgbm8gbmVlZCB0byBk ZXBsb3kgZGF0YXBsYW5lIHByb3RlY3Rpb24gZm9yIHN1Y2ggcHVycG9zZS4gQnV0IGFueXdheSwg d2UgaGF2ZSB0byB0cmFjayBhYm5vcm1hbCBiZWhhdmlvcnMgb2YgdGhlIGNvbnRyb2xwbGFuZSAo cmFjZSBjb25kaXRpb25zLCBjb3JuZXIgY2FzZXMg4oCmKSB3aGVyZSBpdCBkb2VzIG5vdCBkbyBp dHMgam9iIGNvcnJlY3RseSDigKYNCg0KSSB3YXMgYWxzbyB0aGlua2luZyBhYm91dCBwcm9wYWdh dGlvbiB0aW1lIG9mIEMtbXVsdGljYXN0IHJvdXRlIChhdCBsZWFzdCB0eXBlIDUvNi83KSB3aGlj aCBpcyBjcml0aWNhbCDigKYgYW5kIGN1c3RvbWVyIGNhbm5vdCB3YWl0IDMwLzUwIHNlY29uZHMg KG9yIHNvbWUgaG91cnMg4oCmIGRvbuKAmXQgbGF1Z2gsIGl04oCZcyBub3QgYSBqb2tlIOKApikg dG8gcmVjZWl2ZSB0aGUgZ3JvdXAgbWVtYmVyc2hpcCDigKYNCg0KT3VyIHByb3Bvc2FsIGRvZXMg bm90IHByb25lIGluIGFueXdheSB0byB1c2UgY29udHJvbHBsYW5lIG9yIGRhdGFwbGFuZSB0byBt YW5hZ2UgYW55IHJlZHVuZGFuY3kg4oCmDQoNClRoZXJlIGlzIGEgbmVlZCB0byBtb25pdG9yIEJH UCBjb250cm9scGxhbmUgYmVoYXZpb3IgYW5kIGVzcGVjaWFsbHkgdXBkYXRlIHByb3BhZ2F0aW9u IHRpbWUgOiB0aGUgYmFzaWMgdXNlIGNhc2UgaXMgcmVhbGx5IHRvIGVuc3VyZSB0aGF0IGV2ZXJ5 dGhpbmcgZ29lcyB3ZWxsIOKApiBjb21wYXJlZCB0byB0aGUgYmFzZSBsaW5lIHdlIGV2YWx1YXRl ZCBpbiBsYWJzIG9yIHRoZW9yeS4NCg0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86 cnJhc3p1a0BnbWFpbC5jb20+IFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6 dWtAZ21haWwuY29tPl0gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFR1ZXNkYXks IEp1bHkgMjIsIDIwMTQgMTU6MzANClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYNCkNj OiBKZWZmcmV5IEhhYXM7IGlkciB3Zw0KU3ViamVjdDogUmU6IGRyYWZ0LWxpdGtvd3NraS1pZHIt YmdwLXRpbWVzdGFtcA0KDQpTdGVwaGFuZSwNCg0KSWYgeW91IGJ1aWxkIHlvdXIgc2VydmljZSBj b3VudGluZyBvbiBjb250cm9sIHBsYW5lIGNvbnZlcmdlbmNlIEkgdGhpbmsgeW91IGFyZSBkb2lu ZyBiYWQgdGhpbmcgOikgU29ycnkuDQoNCklmIHRoaXMgZHJhZnQgaXMgdG8gZnVydGhlciBoZWxw IHdpdGggc3VjaCBkZXNpZ25zIEkgd291bGQgY2xlYXJseSBzd2l0Y2ggdG8gIm5vIHN1cHBvcnQi IGltbWVkaWF0ZWx5LiBJIGhhZCBvdGhlciB1c2UgY2FzZXMgaW4gbWluZCB3aGljaCBkaWQgbm90 IHNvdW5kIG5lZ2F0aXZlLg0KDQpTcGVjaWZpY2FsbHkgaW4geW91ciBjYXNlIGlmIG9uZSBQRSBv ZiBtdWx0aWhvbWVkIHNpdGUgbG9vc2VzIFBFLUNFIHlvdSBsb2NhbGx5IHByb3RlY3QgdGhlIHNp dGUgKDEwcyBtcyBtYXgpIGFuZCB0YWtlIGFsbCB0aW1lIGl0IG5lZWRzIGZvciBCR1AgdG8gY29u dmVyZ2UgcmVnYXJkbGVzcyBob3cgbG9uZyBpdCB0YWtlcy4gT2YgY291cnNlIEkgYW0gYXNzdW1p bmcgYmFzaWMgcnVsZXMgbGlrZSB1bmlxdWUgUkQgcGVyIFZSRiBpbiBwbGFjZS4NCg0KVGhlIG1v c3QgaW1wb3J0YW50IGlzIHRvIG1haW50YWluIGRhdGEgcGxhbmUgY29ubmVjdGl2aXR5Lg0KDQpC ZXNpZGVzIEkgYW0gbm90IHN1cmUgaG93IHRpbWVzdGFtcCB3aWxsIGhlbHAgeW91IGluIHRoaXMg Y2FzZS4gTGVhdmUgYWxvbmUgdGhhdCB0aW1lc3RhbXAgbWF5IG5ldmVyIGNhdGNoIHRoZSByZWZy ZXNoIG1heCBDUFUgbG9hZCBwZWFrIHNvIHlvdSBtYXkgaW5jb3JyZWN0bHkgY29uc2lkZXIgUlIg YXMgc291bmQgd2hlbiBpdCBpcyByZWFsbHkgbm90Lg0KDQpDaGVlcnMsDQpSLg0KDQoNCk9uIFR1 ZSwgSnVsIDIyLCAyMDE0IGF0IDk6MTkgUE0sIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNv bTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+PiB3cm90ZToNCltSZW5hbWVk IHRvcGljXQ0KDQpIaSBSb2JlcnQsDQoNCj4gWW91ciByZXN1bHRzIG1heSBhY3R1YWxseSBpbiB0 aGUgYWJvdmUgY2FzZSBjYXN1ZSBtb3JlIHByb2JsZW1zIHRoZW4gZ2FpbnMgdW5mb3J0dW5hdGVs eS4NCg0KSSBkb27igJl0IHJlYWxseSB1bmRlcnN0YW5kIHdoeSDigKYgZXZlbiBpZiBSUiBhcmUg bm90IGluIHRoZSBkYXRhcGxhbmUgKHdoaWNoIHdvdWxkIGJlIHRoZSBjYXNlIGZvciBWUE4gZW52 aXJvbm1lbnQpLCBSUiBiZWhhdmlvciBpcyByZWFsbHkgaW1wb3J0YW50IHRvIHRyYWNrLg0KDQpD b25zaWRlciBhIE1QTFMgVlBOIHNjZW5hcmlvLCBzb21lIFBFcyBjb25uZWN0ZWQgdG8gUlIgY2x1 c3RlcnMgYW5kIG1lc2hpbmcgYmV0d2VlbiBjbHVzdGVycy4NCkNvbnNpZGVyIHRoYXQgb25lIG9m IHRoZSBSUiBpcyBnZXR0aW5nIHN0dWNrIGJlY2F1c2Ugb2YgUm91dGUtcmVmcmVzaCBwcm9jZXNz aW5nIG9mIDJNIG9mIHJvdXRlcyBvciBqdXN0IGJ1c3kgdG8gZG8gc29tZXRoaW5nIGVsc2UgZHVl IHRvIGJhZCBzY2hlZHVsaW5nIGluIHRoZSBpbXBsZW1lbnRpb24g4oCmIGlmIGEgUEUgbG9zZSBh IGN1c3RvbWVyIGNvbm5lY3Rpb24sIGFuZCBjdXN0b21lciBoYXMgYSBiYWNrdXAgY29ubmVjdGlv biBhbmQgYmFja3VwIFBFIGhhcyB0byBzZW5kIGEgbmV3IEJHUCB1cGRhdGUgdG8gcHJvcGFnYXRl IHRoZSBuZXcgcGF0aC4gVGhlIHRpbWUgZm9yIFJSIHRvIHByb3BhZ2F0ZSB0aGUgQkdQIHVwZGF0 ZSBpcyBjcml0aWNhbCB0byB0cmFjayBiZWNhdXNlIHRoaXMgd2lsbCBjb25kaXRpb24gY29udmVy Z2VuY2UgdGltZSBmb3IgdGhlIGN1c3RvbWVyIOKApg0KDQpUaG91Z2h0cyA/DQoNCg0KU3RlcGhh bmUNCg0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+ IFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPl0gT24g QmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQgMTE6 MTUNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7IEplZmZyZXkgSGFhcw0KQ2M6IGlk ciB3Zw0KU3ViamVjdDogZHJhZnQtbGl0a293c2tpLWlkci1ydGMtaW50ZXJhcw0KDQpTdGVwaGFu ZSwNCg0KSSBoYXZlIG9uZSBmdW5kYW1lbnRhbCBxdWVzdGlvbiBvbiB0aGlzIC4uLg0KDQpZb3Ug aGF2ZSBmb2N1c2VkIG9uIG1ha2luZyBzdXJlIHRoYXQgQkdQIGNvbnRyb2wgcGxhbmUgd29ya3Mg ZmFzdCBhbmQgc29saWQgZXRjLiBUaGF0IGlzIGdyZWF0IGFuZCB0aW1lc3RhbXAgaWRlYSBhdCBl YWNoIEJHUCBob3Agd291bGQgaGVscC4NCg0KSG93ZXZlciBsZXQncyBvYnNlcnZlIHRoYXQgQkdQ IGNvbnRyb2wgcGxhbmUgaXMgTk9UIGNvbmdydWVudCB3aXRoIGRhdGEgcGxhbmUuIEluIG90aGVy IHdvcmRzIHlvdSBtYXkgaGF2ZSBhIGNhc2Ugd2hlcmUgc29tZW9uZSBtYXkgaGF2ZSBzbG93IGFu ZCBvdmVybG9hZGVkIFJSIGJ1dCB1c2VzIDQwIEdCIHBpcGVzIGZvciBkYXRhIHBsYW5lIHdoaWxl IG90aGVyIEFTIGluc3RhbGxlZCBzdXBlci1oeXBlciB4ODYgUlJzIGFuZCBoYXMgMSBHQiBsaW5r cyBmb3IgZGF0YSBwbGFuZS4NCg0KWW91ciByZXN1bHRzIG1heSBhY3R1YWxseSBpbiB0aGUgYWJv dmUgY2FzZSBjYXN1ZSBtb3JlIHByb2JsZW1zIHRoZW4gZ2FpbnMgdW5mb3J0dW5hdGVseS4NCg0K VGhlIHBvc3NpYmxlIHNpbXBsZSBmaXggaXMgdG8gbWFuZGF0ZSB0aGF0IHRpbWVzdGFtcCBpcyBP TkxZIGFkZGVkIHdoZW4geW91ciBjaGFuZ2UgbmV4dCBob3AgdG8gc2VsZiBvciB0aGF0IHlvdSBj YW4gaGF2ZSBhIG5ldyBmbGFnICJOIiAtIE5leHQgSG9wIFNldCB3aGljaCB3aWxsIGhlbHAgYSBs b3QgdG8gbWFrZSBtb3JlIHVzZSBjYXNlcyBmb3IgdGhpcyBwcm9wb3NhbC4NCg0KQmVzdCwNClIu DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsg eW91Lg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsg eW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlv dS4NCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_9E32478DFA9976438E7A22F69B08FF92044520OPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vIG5vIOKApiB0aGlzIGhhdmUgbm90 aGluZyB0byBkZWFsIHdpdGggYmVzdCBwYXRoIHNlbGVjdGlvbiDigKYgdGltZXN0YW1wIGFyZSBq dXN0IGluZm9ybWF0aW9ucyB0byBiZSB1c2VkIGJ5IGV4dGVybmFsIHRvb2wuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRTIGF0dHJpYnV0ZSBpcyBub3QgcGFydCBvZiBwYXRoIGNvbXBh cmlzb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBycmFzenVr QGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQg MTU6NTk8YnI+DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjxicj4NCjxi PkNjOjwvYj4gSmVmZnJleSBIYWFzOyBpZHIgd2c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IGRy YWZ0LWxpdGtvd3NraS1pZHItYmdwLXRpbWVzdGFtcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+SSBkbyBzZWUgdmVyeSBjcmlzcCB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRv IGFjY29tcGxpc2guJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPkkgYW0gY29uY2VybmVkIHRoYXQgeW91IGFyZSBwcm9wb3Npbmcgd3Jv bmcgdG9vbCBmb3IgaXQuIEF0IGxlYXN0IGV2ZW4gaWYgdGhlcmUgaXMgc29tZSBtZXJpdCB0byB0 aW1lc3RhbXAgYXMgYW4gaW5kaWNhdG9yICh3aGljaCBJIGFtIG5vdCB0aGF0IGNvbnZpbmNlZCkg SSB0aGluayBqdXN0IG5ldyBhdHRyaWJ1dGUgdG8gYmUgYWRkZWQgd2hlbg0KIG9wZXJhdG9yIHNl ZW1zIGZpdCB0byBjdXJyZW50IFVQREFURXMgc2VlbXMgbm90IHBlcmZlY3QuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRvIG1ha2Ug dGhlIGRlY2lzaW9uIG9mIHdoaWNoIHBhdGhzIHRvIGNob29zZSBJIHdvdWxkIGNvbnNpZGVyIG90 aGVyIGluZm9ybWF0aW9uIGxpa2UgQ1BVIHVzYWdlIG9mIFJSID8gT3IgZnJlZSBSQU0gdG8gYmUg YWJsZSB0byBlYXNpbHkgdGVsbCB0aGF0IG9uZSBSUiBtYXkgaGF2ZSBzb21lIG1lbW9yeSBsZWFr IGV0YyAuLi4gYW5kIHRob3NlDQogaW5mb3JtYXRpb24gYXJlIChJIGhvcGUpIGFscmVhZHkgYmVp bmcgY29sbGVjdGVkIGJ5IHlvdXIgbW9uaXRvcmluZyBzdGF0aW9ucy4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SG93IHRpbWVzdGFt cHMgYXJlIGdvaW5nIHRvIGlnbm9yZSBhbGwgb2YgdGhvc2UgYW5kIHJlcGxhY2UgdG8gaGl0IGJl c3QgcGF0aCBzZWxlY3Rpb24gPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPuKAizwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnIuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1bCAyMiwgMjAx NCBhdCA5OjQzIFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFu Z2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kIGp1 c3QgdG8gYWRkIHNvbWV0aGluZyBlbHNlIGxpbmtlZCB0byBkYXRhcGxhbmUgcHJvdGVjdGlvbiDi gKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FdmVuIGlmIHdlIGltcGxlbWVudCBh IGRhdGFwbGFuZSBwcm90ZWN0aW9uIChQRS1DRSwgb3IgZXZlbiBDT1JFKSwgd2UgYXJlIHVzaW5n IE9BTXMgdG8gdmVyaWZ5IHRoYXQNCiBpdCB3b3JrcyBmaW5lIGFuZCBkb2VzIGl0cyBqb2IgY29y cmVjdGx5IOKApiBiZWNhdXNlIG1heWJlIGluIDk1JSBvZiB0aGUgY2FzZXMgaXQgd291bGQgd29y ayBhbmQgeW91IHdpbGwgaGF2ZSA1MG1zZWMgb2YgdHJhZmZpYyBsb3NzLCBidXQgaW4gc29tZSBj b25kaXRpb25zIHlvdSBtYXkgZmFsbCBpbnRvIGEgYnVnIG9yIGNvcm5lciBjYXNlIHRoYXQgd2ls bCBwdXQgeW91IGF0IHNvbWUgc2Vjb25kcyBvciBtb3JlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlcmUgaXTi gJlzIHRoZSBzYW1lLCB3ZSBoYXZlIHNvbWUgbWVjaGFuaWMgaW4gcGxhY2UgKEJHUCksIHdlIHdh bnQgYW4gT0FNIChzaW1wbGUgcHJvYmluZykgdG8gZW5zdXJlDQogdGhhdCBpdCBkb2VzIGl04oCZ cyBqb2IgY29ycmVjdGx5IOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvcGUgdGhlIGNvbXBhcmlzb24gY2xh cmlmaWVzIG15IHBvc2l0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJZHIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWRy LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZHItYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRrb3dz a2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2Uu Y29tPC9hPjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDE1OjM5PGJy Pg0KPGI+VG86PC9iPiBSb2JlcnQgUmFzenVrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPkNjOjwvYj4gSmVmZnJleSBIYWFzOyBpZHIg d2c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+U3ViamVj dDo8L2I+IFJlOiBbSWRyXSBkcmFmdC1saXRrb3dza2ktaWRyLWJncC10aW1lc3RhbXA8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHdlIGFyZSBpbmxp bmUg4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IG5vdCBhbGwgb2YgdGhl IGN1c3RvbWVycyByZXF1aXJlcyA1MG1zZWMgb3IgJmx0OyAxc2VjIGNvbnZlcmdlbmNlIHRpbWUu IEZvciBtb3N0IG9mIHRoZSB0cmFmZmljLA0KIHNvbWUgc2Vjb25kcyBpcyBhY2NlcHRhYmxlIGFu ZCB0aGVyZSBpcyBubyBuZWVkIHRvIGRlcGxveSBkYXRhcGxhbmUgcHJvdGVjdGlvbiBmb3Igc3Vj aCBwdXJwb3NlLiBCdXQgYW55d2F5LCB3ZSBoYXZlIHRvIHRyYWNrIGFibm9ybWFsIGJlaGF2aW9y cyBvZiB0aGUgY29udHJvbHBsYW5lIChyYWNlIGNvbmRpdGlvbnMsIGNvcm5lciBjYXNlcyDigKYp IHdoZXJlIGl0IGRvZXMgbm90IGRvIGl0cyBqb2IgY29ycmVjdGx5IOKApg0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSB3YXMgYWxzbyB0aGlua2luZyBhYm91dCBwcm9wYWdhdGlvbiB0aW1lIG9mIEMtbXVsdGlj YXN0IHJvdXRlIChhdCBsZWFzdCB0eXBlIDUvNi83KSB3aGljaCBpcyBjcml0aWNhbA0KIOKApiBh bmQgY3VzdG9tZXIgY2Fubm90IHdhaXQgMzAvNTAgc2Vjb25kcyAob3Igc29tZSBob3VycyDigKYg ZG9u4oCZdCBsYXVnaCwgaXTigJlzIG5vdCBhIGpva2Ug4oCmKSB0byByZWNlaXZlIHRoZSBncm91 cCBtZW1iZXJzaGlwIOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk91ciBwcm9wb3NhbCBkb2VzIG5vdCBwcm9u ZSBpbiBhbnl3YXkgdG8gdXNlIGNvbnRyb2xwbGFuZSBvciBkYXRhcGxhbmUgdG8gbWFuYWdlIGFu eSByZWR1bmRhbmN5IOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIGEgbmVlZCB0byBtb25pdG9y IEJHUCBjb250cm9scGxhbmUgYmVoYXZpb3IgYW5kIGVzcGVjaWFsbHkgdXBkYXRlIHByb3BhZ2F0 aW9uIHRpbWUgOiB0aGUNCiBiYXNpYyB1c2UgY2FzZSBpcyByZWFsbHkgdG8gZW5zdXJlIHRoYXQg ZXZlcnl0aGluZyBnb2VzIHdlbGwg4oCmIGNvbXBhcmVkIHRvIHRoZSBiYXNlIGxpbmUgd2UgZXZh bHVhdGVkIGluIGxhYnMgb3IgdGhlb3J5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8 YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVr QGdtYWlsLmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyMiwgMjAx NCAxNTozMDxicj4NCjxiPlRvOjwvYj4gTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GPGJyPg0K PGI+Q2M6PC9iPiBKZWZmcmV5IEhhYXM7IGlkciB3Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog ZHJhZnQtbGl0a293c2tpLWlkci1iZ3AtdGltZXN0YW1wPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPlN0ZXBoYW5lLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SWYgeW91IGJ1aWxkIHlvdXIgc2VydmljZSBj b3VudGluZyBvbiBjb250cm9sIHBsYW5lIGNvbnZlcmdlbmNlIEkgdGhpbmsgeW91IGFyZSBkb2lu ZyBiYWQgdGhpbmcgOikgU29ycnkuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB0aGlzIGRyYWZ0IGlzIHRvIGZ1cnRoZXIg aGVscCB3aXRoIHN1Y2ggZGVzaWducyBJIHdvdWxkIGNsZWFybHkgc3dpdGNoIHRvICZxdW90O25v IHN1cHBvcnQmcXVvdDsgaW1tZWRpYXRlbHkuIEkgaGFkIG90aGVyIHVzZSBjYXNlcyBpbiBtaW5k IHdoaWNoDQogZGlkIG5vdCBzb3VuZCBuZWdhdGl2ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNwZWNpZmljYWxseSBpbiB5b3VyIGNh c2UgaWYgb25lIFBFIG9mIG11bHRpaG9tZWQgc2l0ZSBsb29zZXMgUEUtQ0UgeW91IGxvY2FsbHkg cHJvdGVjdCB0aGUgc2l0ZSAoMTBzIG1zIG1heCkgYW5kIHRha2UgYWxsIHRpbWUgaXQgbmVlZHMN CiBmb3IgQkdQIHRvIGNvbnZlcmdlIHJlZ2FyZGxlc3MgaG93IGxvbmcgaXQgdGFrZXMuIE9mIGNv dXJzZSBJIGFtIGFzc3VtaW5nIGJhc2ljIHJ1bGVzIGxpa2UgdW5pcXVlIFJEIHBlciBWUkYgaW4g cGxhY2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5UaGUgbW9zdCBpbXBvcnRhbnQgaXMgdG8gbWFpbnRhaW4gZGF0YSBwbGFuZSBjb25u ZWN0aXZpdHkuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5CZXNpZGVzIEkgYW0gbm90IHN1cmUgaG93IHRpbWVzdGFtcCB3aWxs IGhlbHAgeW91IGluIHRoaXMgY2FzZS4gTGVhdmUgYWxvbmUgdGhhdCB0aW1lc3RhbXAgbWF5IG5l dmVyIGNhdGNoIHRoZSByZWZyZXNoIG1heCBDUFUgbG9hZCBwZWFrDQogc28geW91IG1heSBpbmNv cnJlY3RseSBjb25zaWRlciBSUiBhcyBzb3VuZCB3aGVuIGl0IGlzIHJlYWxseSBub3QuJm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5DaGVlcnMsPGJyPg0KUi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDk6MTkgUE0sICZsdDs8YSBo cmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5zdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bUmVuYW1lZCB0b3BpY108L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IaSBSb2JlcnQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiBZb3VyIHJlc3VsdHMgbWF5IGFjdHVhbGx5 IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlDQogbW9yZSBwcm9ibGVtcyB0aGVuIGdhaW5zIHVuZm9y dHVuYXRlbHkuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHJlYWxseSB1bmRlcnN0YW5k IHdoeSDigKYgZXZlbiBpZiBSUiBhcmUgbm90IGluIHRoZSBkYXRhcGxhbmUgKHdoaWNoIHdvdWxk IGJlIHRoZSBjYXNlIGZvcg0KIFZQTiBlbnZpcm9ubWVudCksIFJSIGJlaGF2aW9yIGlzIHJlYWxs eSBpbXBvcnRhbnQgdG8gdHJhY2suPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgYSBNUExTIFZQTiBz Y2VuYXJpbywgc29tZSBQRXMgY29ubmVjdGVkIHRvIFJSIGNsdXN0ZXJzIGFuZCBtZXNoaW5nIGJl dHdlZW4gY2x1c3RlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXIg dGhhdCBvbmUgb2YgdGhlIFJSIGlzIGdldHRpbmcgc3R1Y2sgYmVjYXVzZSBvZiBSb3V0ZS1yZWZy ZXNoIHByb2Nlc3Npbmcgb2YgMk0gb2Ygcm91dGVzDQogb3IganVzdCBidXN5IHRvIGRvIHNvbWV0 aGluZyBlbHNlIGR1ZSB0byBiYWQgc2NoZWR1bGluZyBpbiB0aGUgaW1wbGVtZW50aW9uIOKApiBp ZiBhIFBFIGxvc2UgYSBjdXN0b21lciBjb25uZWN0aW9uLCBhbmQgY3VzdG9tZXIgaGFzIGEgYmFj a3VwIGNvbm5lY3Rpb24gYW5kIGJhY2t1cCBQRSBoYXMgdG8gc2VuZCBhIG5ldyBCR1AgdXBkYXRl IHRvIHByb3BhZ2F0ZSB0aGUgbmV3IHBhdGguIFRoZSB0aW1lIGZvciBSUiB0byBwcm9wYWdhdGUg dGhlIEJHUA0KIHVwZGF0ZSBpcyBjcml0aWNhbCB0byB0cmFjayBiZWNhdXNlIHRoaXMgd2lsbCBj b25kaXRpb24gY29udmVyZ2VuY2UgdGltZSBmb3IgdGhlIGN1c3RvbWVyIOKApjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRob3VnaHRzID88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TdGVwaGFuZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVm PSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWls LmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJv YmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMTox NTxicj4NCjxiPlRvOjwvYj4gTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBKZWZmcmV5IEhh YXM8YnI+DQo8Yj5DYzo8L2I+IGlkciB3Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBkcmFmdC1saXRr b3dza2ktaWRyLXJ0Yy1pbnRlcmFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPlN0ZXBoYW5lLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+SSBoYXZlIG9uZSBmdW5kYW1lbnRhbCBxdWVzdGlvbiBvbiB0aGlz IC4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+WW91IGhhdmUgZm9jdXNlZCBvbiBtYWtpbmcgc3VyZSB0aGF0IEJHUCBjb250cm9sIHBs YW5lIHdvcmtzIGZhc3QgYW5kIHNvbGlkIGV0Yy4gVGhhdCBpcyBncmVhdCBhbmQgdGltZXN0YW1w IGlkZWEgYXQgZWFjaCBCR1AgaG9wIHdvdWxkIGhlbHAuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Ib3dldmVyIGxldCdzIG9i c2VydmUgdGhhdCBCR1AgY29udHJvbCBwbGFuZSBpcyBOT1QgY29uZ3J1ZW50IHdpdGggZGF0YSBw bGFuZS4gSW4gb3RoZXIgd29yZHMgeW91IG1heSBoYXZlIGEgY2FzZSB3aGVyZSBzb21lb25lIG1h eSBoYXZlDQogc2xvdyBhbmQgb3ZlcmxvYWRlZCBSUiBidXQgdXNlcyA0MCBHQiBwaXBlcyBmb3Ig ZGF0YSBwbGFuZSB3aGlsZSBvdGhlciBBUyBpbnN0YWxsZWQgc3VwZXItaHlwZXIgeDg2IFJScyBh bmQgaGFzIDEgR0IgbGlua3MgZm9yIGRhdGEgcGxhbmUuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Zb3VyIHJlc3VsdHMgbWF5 IGFjdHVhbGx5IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlIG1vcmUgcHJvYmxlbXMgdGhlbiBnYWlu cyB1bmZvcnR1bmF0ZWx5LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIHBvc3NpYmxlIHNpbXBsZSBmaXggaXMgdG8gbWFu ZGF0ZSB0aGF0IHRpbWVzdGFtcCBpcyBPTkxZIGFkZGVkIHdoZW4geW91ciBjaGFuZ2UgbmV4dCBo b3AgdG8gc2VsZiBvciB0aGF0IHlvdSBjYW4gaGF2ZSBhIG5ldyBmbGFnICZxdW90O04mcXVvdDsN CiAtIE5leHQgSG9wIFNldCB3aGljaCB3aWxsIGhlbHAgYSBsb3QgdG8gbWFrZSBtb3JlIHVzZSBj YXNlcyBmb3IgdGhpcyBwcm9wb3NhbC4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3QsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlIuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48 L286cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFuayB5b3UuPG86cD48L286cD48L3By ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48 L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86 cD48L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_9E32478DFA9976438E7A22F69B08FF92044520OPEXCLILM34corpor_-- From nobody Tue Jul 22 13:09:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816D61A035B for ; Tue, 22 Jul 2014 13:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beK3yZcqcQ3d for ; Tue, 22 Jul 2014 13:09:52 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0CEC1A01E4 for ; Tue, 22 Jul 2014 13:09:52 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id h15so4437752igd.5 for ; Tue, 22 Jul 2014 13:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zhnsXKgaR8nWcBv5GDN25OGn2eeLJc2GN35HyNtD+tQ=; b=TAF/i/xjB+NRdetwEYJxGiLIQPgknqTPvbDoRMt4T+HgTR73TMFlY2M0c5bjjStGn+ 8Cmi5F/Cw/C4ANl3eWZXuEEM/OEtUvX7LDY35tF9U6necbslV17nbRKP5KPa1R42ezAh hnzTYnZ2jJ73M9mrDum2yVAEmAf6gft3VNSgGCXGdU4axKu8dW7qv/HB11pGxBJwR+WH cmVmahE1Ad6y+bhqVKnZeSn1jMY8m7I1rg0l6OaIg/76froPvq+9JYFsHOdXXo6iEQUf pWzBbe4crVoWkTFyQuTS3laPXJEY8BmBcoXjeCkC4LYM/gfRugxJMpth/bRBQcJONWE/ UGuQ== MIME-Version: 1.0 X-Received: by 10.50.36.106 with SMTP id p10mr20544409igj.9.1406059791924; Tue, 22 Jul 2014 13:09:51 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 22 Jul 2014 13:09:51 -0700 (PDT) In-Reply-To: <23971_1406059594_53CEC44A_23971_10374_1_9E32478DFA9976438E7A22F69B08FF92044520@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <16559_1406057911_53CEBDB7_16559_6108_1_9E32478DFA9976438E7A22F69B08FF920444B7@OPEXCLILM34.corporate.adroot.infra.ftgroup> <5637_1406058199_53CEBED7_5637_5507_1_7086b517-975e-4f75-9c52-cc354bccddcc@OPEXCLILH05.corporate.adroot.infra.ftgroup> <23971_1406059594_53CEC44A_23971_10374_1_9E32478DFA9976438E7A22F69B08FF92044520@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Tue, 22 Jul 2014 22:09:51 +0200 X-Google-Sender-Auth: Avxu3fhC2WOftf79wPJNbEontWU Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=089e0115ebd06e45e704fecdcea5 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/QE3xU656Kn2kT8iS4CchjM3Uk-c Cc: Jeffrey Haas , idr wg Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:09:55 -0000 --089e0115ebd06e45e704fecdcea5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Then why not use BGP Operational Message then ? Seems like perfect fit to me if this is just a BGP control plane network propagation speedometer. Cheers, R. On Tue, Jul 22, 2014 at 10:06 PM, wrote: > No no =E2=80=A6 this have nothing to deal with best path selection =E2= =80=A6 timestamp > are just informations to be used by external tool. > > TS attribute is not part of path comparison. > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 15:59 > > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* Jeffrey Haas; idr wg > *Subject:* Re: draft-litkowski-idr-bgp-timestamp > > > > > > I do see very crisp what you are trying to accomplish. > > > > I am concerned that you are proposing wrong tool for it. At least even if > there is some merit to timestamp as an indicator (which I am not that > convinced) I think just new attribute to be added when operator seems fit > to current UPDATEs seems not perfect. > > > > To make the decision of which paths to choose I would consider other > information like CPU usage of RR ? Or free RAM to be able to easily tell > that one RR may have some memory leak etc ... and those information are (= I > hope) already being collected by your monitoring stations. > > > > How timestamps are going to ignore all of those and replace to hit best > path selection ? > > > > =E2=80=8Br.=E2=80=8B > > > > On Tue, Jul 22, 2014 at 9:43 PM, wrote: > > And just to add something else linked to dataplane protection =E2=80=A6 > > Even if we implement a dataplane protection (PE-CE, or even CORE), we are > using OAMs to verify that it works fine and does its job correctly =E2=80= =A6 > because maybe in 95% of the cases it would work and you will have 50msec = of > traffic loss, but in some conditions you may fall into a bug or corner ca= se > that will put you at some seconds or more. > > > > Here it=E2=80=99s the same, we have some mechanic in place (BGP), we want= an OAM > (simple probing) to ensure that it does it=E2=80=99s job correctly =E2=80= =A6 > > > > Hope the comparison clarifies my position. > > > > > > *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of * > stephane.litkowski@orange.com > *Sent:* Tuesday, July 22, 2014 15:39 > *To:* Robert Raszuk > > > *Cc:* Jeffrey Haas; idr wg > > *Subject:* Re: [Idr] draft-litkowski-idr-bgp-timestamp > > > > I think we are inline =E2=80=A6 > > But not all of the customers requires 50msec or < 1sec convergence time. > For most of the traffic, some seconds is acceptable and there is no need = to > deploy dataplane protection for such purpose. But anyway, we have to trac= k > abnormal behaviors of the controlplane (race conditions, corner cases =E2= =80=A6) > where it does not do its job correctly =E2=80=A6 > > > > I was also thinking about propagation time of C-multicast route (at least > type 5/6/7) which is critical =E2=80=A6 and customer cannot wait 30/50 se= conds (or > some hours =E2=80=A6 don=E2=80=99t laugh, it=E2=80=99s not a joke =E2=80= =A6) to receive the group > membership =E2=80=A6 > > > > Our proposal does not prone in anyway to use controlplane or dataplane to > manage any redundancy =E2=80=A6 > > > > There is a need to monitor BGP controlplane behavior and especially updat= e > propagation time : the basic use case is really to ensure that everything > goes well =E2=80=A6 compared to the base line we evaluated in labs or the= ory. > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 15:30 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* Jeffrey Haas; idr wg > *Subject:* Re: draft-litkowski-idr-bgp-timestamp > > > > Stephane, > > > > If you build your service counting on control plane convergence I think > you are doing bad thing :) Sorry. > > > > If this draft is to further help with such designs I would clearly switch > to "no support" immediately. I had other use cases in mind which did not > sound negative. > > > > Specifically in your case if one PE of multihomed site looses PE-CE you > locally protect the site (10s ms max) and take all time it needs for BGP = to > converge regardless how long it takes. Of course I am assuming basic rule= s > like unique RD per VRF in place. > > > > The most important is to maintain data plane connectivity. > > > > Besides I am not sure how timestamp will help you in this case. Leave > alone that timestamp may never catch the refresh max CPU load peak so you > may incorrectly consider RR as sound when it is really not. > > > > Cheers, > R. > > > > > > On Tue, Jul 22, 2014 at 9:19 PM, wrote: > > [Renamed topic] > > > > Hi Robert, > > > > > Your results may actually in the above case casue more problems then > gains unfortunately. > > > > I don=E2=80=99t really understand why =E2=80=A6 even if RR are not in the= dataplane (which > would be the case for VPN environment), RR behavior is really important t= o > track. > > > > Consider a MPLS VPN scenario, some PEs connected to RR clusters and > meshing between clusters. > > Consider that one of the RR is getting stuck because of Route-refresh > processing of 2M of routes or just busy to do something else due to bad > scheduling in the implemention =E2=80=A6 if a PE lose a customer connecti= on, and > customer has a backup connection and backup PE has to send a new BGP upda= te > to propagate the new path. The time for RR to propagate the BGP update is > critical to track because this will condition convergence time for the > customer =E2=80=A6 > > > > Thoughts ? > > > > > > Stephane > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Tuesday, July 22, 2014 11:15 > *To:* LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas > *Cc:* idr wg > *Subject:* draft-litkowski-idr-rtc-interas > > > > Stephane, > > > > I have one fundamental question on this ... > > > > You have focused on making sure that BGP control plane works fast and > solid etc. That is great and timestamp idea at each BGP hop would help. > > > > However let's observe that BGP control plane is NOT congruent with data > plane. In other words you may have a case where someone may have slow and > overloaded RR but uses 40 GB pipes for data plane while other AS installe= d > super-hyper x86 RRs and has 1 GB links for data plane. > > > > Your results may actually in the above case casue more problems then gain= s > unfortunately. > > > > The possible simple fix is to mandate that timestamp is ONLY added when > your change next hop to self or that you can have a new flag "N" - Next H= op > Set which will help a lot to make more use cases for this proposal. > > > > Best, > > R. > > > > > > > > _________________________________________________________________________= ________________________________________________ > > > > 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. > > > > 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. > > > > _________________________________________________________________________= ________________________________________________ > > > > 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. > > > > 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. > > ______________________________________________________________________= ___________________________________________________ > > > > 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. > > > > 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. > > > > _________________________________________________________________________= ________________________________________________ > > 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. > > 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. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --089e0115ebd06e45e704fecdcea5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Then why not use BGP= Operational Message then ?=C2=A0

Seems like perfect fit to me if this = is just a BGP control plane network propagation speedometer.=C2=A0

Cheers,
R.


On Tue, Jul 22, 2014 at 10:06 PM, <stephane.litkowski@orange.com> wrote:

No no =E2=80=A6 this have= nothing to deal with best path selection =E2=80=A6 timestamp are just info= rmations to be used by external tool.

TS attribute is not part = of path comparison.

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 15:59


To: LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas; idr wg
Subject: Re: draft-litkowski-idr-bgp-timestamp

=C2=A0

= =C2=A0

= I do see very crisp what you are trying to accomplish.=C2=A0<= /span>

= =C2=A0

= I am concerned that you are proposing wrong tool for it. At least even if t= here is some merit to timestamp as an indicator (which I am not that convin= ced) I think just new attribute to be added when operator seems fit to current UPDATEs seems not perfect.=C2=A0

= =C2=A0

= To make the decision of which paths to choose I would consider other inform= ation like CPU usage of RR ? Or free RAM to be able to easily tell that one= RR may have some memory leak etc ... and those information are (I hope) already being collected by your monitoring statio= ns.=C2=A0

= =C2=A0

= How timestamps are going to ignore all of those and replace to hit best pat= h selection ?=C2=A0

= =C2=A0

=E2=80=8Br.=E2=80=8B

=C2=A0<= /p>

On Tue, Jul 22, 2014 at 9:43 PM, <stephane.litkowski@oran= ge.com> wrote:

And just to add something= else linked to dataplane protection =E2=80=A6

Even if we implement a da= taplane protection (PE-CE, or even CORE), we are using OAMs to verify that it works fine and does its job correctly =E2=80=A6 because maybe in 95% of= the cases it would work and you will have 50msec of traffic loss, but in s= ome conditions you may fall into a bug or corner case that will put you at = some seconds or more.

=C2=A0

Here it=E2=80=99s the sam= e, we have some mechanic in place (BGP), we want an OAM (simple probing) to= ensure that it does it=E2=80=99s job correctly =E2=80=A6

=C2=A0

Hope the comparison clari= fies my position.

=C2=A0

=C2=A0

From: Idr [mai= lto:idr-bounces@i= etf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Tuesday, July 22, 2014 15:39
To: Robert Raszuk


Cc: Jeffrey Haas; idr wg

Subject: Re: [Idr] draft-litkowski-idr-bgp-ti= mestamp

=C2=A0

I think we are inline =E2= =80=A6

But not all of the custom= ers requires 50msec or < 1sec convergence time. For most of the traffic, some seconds is acceptable and there is no need to deploy dataplane protec= tion for such purpose. But anyway, we have to track abnormal behaviors of t= he controlplane (race conditions, corner cases =E2=80=A6) where it does not= do its job correctly =E2=80=A6

=C2=A0

I was also thinking about= propagation time of C-multicast route (at least type 5/6/7) which is criti= cal =E2=80=A6 and customer cannot wait 30/50 seconds (or some hours =E2=80=A6 = don=E2=80=99t laugh, it=E2=80=99s not a joke =E2=80=A6) to receive the grou= p membership =E2=80=A6

=C2=A0

Our proposal does not pro= ne in anyway to use controlplane or dataplane to manage any redundancy =E2= =80=A6

=C2=A0

There is a need to monito= r BGP controlplane behavior and especially update propagation time : the basic use case is really to ensure that everything goes well =E2=80=A6 com= pared to the base line we evaluated in labs or theory.=

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 15:30
To: LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas; idr wg
Subject: Re: draft-litkowski-idr-bgp-timestamp<= /p>

=C2=A0

= Stephane,

= =C2=A0

= If you build your service counting on control plane convergence I think you= are doing bad thing :) Sorry.=C2=A0

= =C2=A0

= If this draft is to further help with such designs I would clearly switch t= o "no support" immediately. I had other use cases in mind which did not sound negative.

= =C2=A0

= Specifically in your case if one PE of multihomed site looses PE-CE you loc= ally protect the site (10s ms max) and take all time it needs for BGP to converge regardless how long it takes. Of course I am assuming = basic rules like unique RD per VRF in place.

= =C2=A0

= The most important is to maintain data plane connectivity.=C2=A0<= /u>

= =C2=A0

= Besides I am not sure how timestamp will help you in this case. Leave alone= that timestamp may never catch the refresh max CPU load peak so you may incorrectly consider RR as sound when it is really not.=C2=A0

= =C2=A0

= Cheers,
R.

= =C2=A0

=C2=A0<= /p>

On Tue, Jul 22, 2014 at 9:19 PM, <stephane.litkowski@oran= ge.com> wrote:

[Renamed topic]=

=C2=A0

Hi Robert,<= u>

=C2=A0

> Your results may actually in the abo= ve case casue more problems then gains unfortunately.=C2=A0

=C2=A0

I don=E2=80=99t really un= derstand why =E2=80=A6 even if RR are not in the dataplane (which would be = the case for VPN environment), RR behavior is really important to track.<= u>

=C2=A0

Consider a MPLS VPN scena= rio, some PEs connected to RR clusters and meshing between clusters.=

Consider that one of the = RR is getting stuck because of Route-refresh processing of 2M of routes or just busy to do something else due to bad scheduling in the implementio= n =E2=80=A6 if a PE lose a customer connection, and customer has a backup c= onnection and backup PE has to send a new BGP update to propagate the new p= ath. The time for RR to propagate the BGP update is critical to track because this will condition convergence time f= or the customer =E2=80=A6

=C2=A0

Thoughts ?<= u>

=C2=A0

=C2=A0

Stephane=

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 11:15
To: LITKOWSKI Stephane SCE/IBNF; Jeffrey Haas
Cc: idr wg
Subject: draft-litkowski-idr-rtc-interas

=C2=A0

= Stephane,

= =C2=A0

= I have one fundamental question on this ...

= =C2=A0

= You have focused on making sure that BGP control plane works fast and solid= etc. That is great and timestamp idea at each BGP hop would help.=C2=A0

= =C2=A0

= However let's observe that BGP control plane is NOT congruent with data= plane. In other words you may have a case where someone may have slow and overloaded RR but uses 40 GB pipes for data plane while other AS = installed super-hyper x86 RRs and has 1 GB links for data plane.=C2=A0

= =C2=A0

= Your results may actually in the above case casue more problems then gains = unfortunately.=C2=A0

= =C2=A0

= The possible simple fix is to mandate that timestamp is ONLY added when you= r change next hop to self or that you can have a new flag "N" - Next Hop Set which will help a lot to make more use cases for this propo= sal.=C2=A0

= =C2=A0

= Best,

= R.

= =C2=A0

= =C2=A0

= =C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


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.

=C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


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.


______________________________________________________________________=
___________________________________________________
=C2=A0
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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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.<=
u>


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.

=C2=A0

______________________________________________________________________=
___________________________________________________

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

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

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


--089e0115ebd06e45e704fecdcea5-- From nobody Tue Jul 22 13:10:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E381A0AF6 for ; Tue, 22 Jul 2014 13:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yNbx7CGea4x for ; Tue, 22 Jul 2014 13:10:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1551B28B2 for ; Tue, 22 Jul 2014 13:10:03 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C261522D7F5; Tue, 22 Jul 2014 22:10:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9480935C045; Tue, 22 Jul 2014 22:10:01 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 22:10:01 +0200 From: To: Robert Raszuk Thread-Topic: draft-litkowski-idr-bgp-timestamp Thread-Index: Ac+l4ODPJH0/NfV4QnGw7fCPCrH3Lv//40kA///eIlCAAChcAP//2ifA Date: Tue, 22 Jul 2014 20:10:00 +0000 Message-ID: <30262_1406059801_53CEC519_30262_394_1_9E32478DFA9976438E7A22F69B08FF92044536@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <16559_1406057911_53CEBDB7_16559_6108_1_9E32478DFA9976438E7A22F69B08FF920444B7@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92044536OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/h_deFTCHP1c-p_pnN7-l4mj3Mxg Cc: Jeffrey Haas , idr wg Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:10:16 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92044536OPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHJlYWxseSBzZWUgaG93IGJncCBvcHMgbWVzc2FnZSBjYW4gYmUgdXNlZCBmb3Ig dGhhdCBwdXJwb3NlIOKApg0KSSBtYXkgc2VlIEJHUCBvcHMgbWVzc2FnZSB1c2FibGUgYXMgYW4g aW5mb3JtYXRpb24gY29sbGVjdG9yIGJldHdlZW4gdGhlIHRvb2wgYW5kIGEgQkdQIFNwZWFrZXIs IGJ1dCBJIGRvbuKAmXQgc2VlIGhvdyBpdCBjb3VsZCBoZWxwIHRvIHJldHJpZXZlIHRpbWVzdGFt cHMgZnJvbSBhbGwgaG9wcyBvbiB0aGUgcGF0aCB2ZWN0b3IgZm9yIGEgc3BlY2lmaWMgTkxSSS4N Cg0KRnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24g QmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQgMTU6 NTMNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYNCkNjOiBKZWZmcmV5IEhhYXM7IGlk ciB3Zw0KU3ViamVjdDogUmU6IGRyYWZ0LWxpdGtvd3NraS1pZHItYmdwLXRpbWVzdGFtcA0KDQoN CkFoaCBvayAuLiB0aGVuIHdlIGFyZSBzbG93bHkgZ2V0dGluZyBtb3JlIG9uIHRoZSBzYW1lIHBh Z2UuIFdlbGwgYXQgbGVhc3Qgd2UgYXJlIG9uIHRoZSBzYW1lIGJvb2tzaGVsZiBub3cgOikNCg0K SWYgdGhpcyBpcyB5b3VyIGFwcGxpY2F0aW9uIHdoeSBub3QgdXNlIEJHUCBEaWFnbm9zdGljIE1l c3NhZ2UgZm9yIGl0IG5vdyBwYXJ0IG9mIEJHUCBPcGVyYXRpb25hbCBNZXNzYWdlIGRyYWZ0IHdo aWNoIGlzIGFuIElEUiBXRyBkb2MgPw0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWlkci1vcGVyYXRpb25hbC1tZXNzYWdlLTAwDQoNCi0gLQ0KDQpTb21lb25lIGF0IHRo ZSBJRFIgSSB0aGluayBhc2tlZCBpbiB0aGUgcm9vbSB0aGF0IHRoaXMgc2hvdWxkIGJlIGF0IGxl YXN0IGEgc2VwYXJhdGUgU0FGSS4gQnV0IHRpbGwgd2UgZ28gdGhlcmUgbGV0J3Mgc2VlIGlmIHlv dSBzZWUgcHJvYmxlbXMgd2l0aCBhZGRpbmcgdGhpcyBmdW5jdGlvbmFsaXR5IHRvIE9wZXJhdGlv bmFsIE1lc3NhZ2UuDQoNClRoeCwNClIuDQoNCg0KDQpPbiBUdWUsIEp1bCAyMiwgMjAxNCBhdCA5 OjM4IFBNLCA8c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tPj4gd3JvdGU6DQpJIHRoaW5rIHdlIGFyZSBpbmxpbmUg4oCmDQpC dXQgbm90IGFsbCBvZiB0aGUgY3VzdG9tZXJzIHJlcXVpcmVzIDUwbXNlYyBvciA8IDFzZWMgY29u dmVyZ2VuY2UgdGltZS4gRm9yIG1vc3Qgb2YgdGhlIHRyYWZmaWMsIHNvbWUgc2Vjb25kcyBpcyBh Y2NlcHRhYmxlIGFuZCB0aGVyZSBpcyBubyBuZWVkIHRvIGRlcGxveSBkYXRhcGxhbmUgcHJvdGVj dGlvbiBmb3Igc3VjaCBwdXJwb3NlLiBCdXQgYW55d2F5LCB3ZSBoYXZlIHRvIHRyYWNrIGFibm9y bWFsIGJlaGF2aW9ycyBvZiB0aGUgY29udHJvbHBsYW5lIChyYWNlIGNvbmRpdGlvbnMsIGNvcm5l ciBjYXNlcyDigKYpIHdoZXJlIGl0IGRvZXMgbm90IGRvIGl0cyBqb2IgY29ycmVjdGx5IOKApg0K DQpJIHdhcyBhbHNvIHRoaW5raW5nIGFib3V0IHByb3BhZ2F0aW9uIHRpbWUgb2YgQy1tdWx0aWNh c3Qgcm91dGUgKGF0IGxlYXN0IHR5cGUgNS82LzcpIHdoaWNoIGlzIGNyaXRpY2FsIOKApiBhbmQg Y3VzdG9tZXIgY2Fubm90IHdhaXQgMzAvNTAgc2Vjb25kcyAob3Igc29tZSBob3VycyDigKYgZG9u 4oCZdCBsYXVnaCwgaXTigJlzIG5vdCBhIGpva2Ug4oCmKSB0byByZWNlaXZlIHRoZSBncm91cCBt ZW1iZXJzaGlwIOKApg0KDQpPdXIgcHJvcG9zYWwgZG9lcyBub3QgcHJvbmUgaW4gYW55d2F5IHRv IHVzZSBjb250cm9scGxhbmUgb3IgZGF0YXBsYW5lIHRvIG1hbmFnZSBhbnkgcmVkdW5kYW5jeSDi gKYNCg0KVGhlcmUgaXMgYSBuZWVkIHRvIG1vbml0b3IgQkdQIGNvbnRyb2xwbGFuZSBiZWhhdmlv ciBhbmQgZXNwZWNpYWxseSB1cGRhdGUgcHJvcGFnYXRpb24gdGltZSA6IHRoZSBiYXNpYyB1c2Ug Y2FzZSBpcyByZWFsbHkgdG8gZW5zdXJlIHRoYXQgZXZlcnl0aGluZyBnb2VzIHdlbGwg4oCmIGNv bXBhcmVkIHRvIHRoZSBiYXNlIGxpbmUgd2UgZXZhbHVhdGVkIGluIGxhYnMgb3IgdGhlb3J5Lg0K DQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tPG1haWx0bzpycmFzenVrQGdtYWlsLmNvbT4gW21h aWx0bzpycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+XSBPbiBCZWhh bGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxNTozMA0K VG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORg0KQ2M6IEplZmZyZXkgSGFhczsgaWRyIHdn DQpTdWJqZWN0OiBSZTogZHJhZnQtbGl0a293c2tpLWlkci1iZ3AtdGltZXN0YW1wDQoNClN0ZXBo YW5lLA0KDQpJZiB5b3UgYnVpbGQgeW91ciBzZXJ2aWNlIGNvdW50aW5nIG9uIGNvbnRyb2wgcGxh bmUgY29udmVyZ2VuY2UgSSB0aGluayB5b3UgYXJlIGRvaW5nIGJhZCB0aGluZyA6KSBTb3JyeS4N Cg0KSWYgdGhpcyBkcmFmdCBpcyB0byBmdXJ0aGVyIGhlbHAgd2l0aCBzdWNoIGRlc2lnbnMgSSB3 b3VsZCBjbGVhcmx5IHN3aXRjaCB0byAibm8gc3VwcG9ydCIgaW1tZWRpYXRlbHkuIEkgaGFkIG90 aGVyIHVzZSBjYXNlcyBpbiBtaW5kIHdoaWNoIGRpZCBub3Qgc291bmQgbmVnYXRpdmUuDQoNClNw ZWNpZmljYWxseSBpbiB5b3VyIGNhc2UgaWYgb25lIFBFIG9mIG11bHRpaG9tZWQgc2l0ZSBsb29z ZXMgUEUtQ0UgeW91IGxvY2FsbHkgcHJvdGVjdCB0aGUgc2l0ZSAoMTBzIG1zIG1heCkgYW5kIHRh a2UgYWxsIHRpbWUgaXQgbmVlZHMgZm9yIEJHUCB0byBjb252ZXJnZSByZWdhcmRsZXNzIGhvdyBs b25nIGl0IHRha2VzLiBPZiBjb3Vyc2UgSSBhbSBhc3N1bWluZyBiYXNpYyBydWxlcyBsaWtlIHVu aXF1ZSBSRCBwZXIgVlJGIGluIHBsYWNlLg0KDQpUaGUgbW9zdCBpbXBvcnRhbnQgaXMgdG8gbWFp bnRhaW4gZGF0YSBwbGFuZSBjb25uZWN0aXZpdHkuDQoNCkJlc2lkZXMgSSBhbSBub3Qgc3VyZSBo b3cgdGltZXN0YW1wIHdpbGwgaGVscCB5b3UgaW4gdGhpcyBjYXNlLiBMZWF2ZSBhbG9uZSB0aGF0 IHRpbWVzdGFtcCBtYXkgbmV2ZXIgY2F0Y2ggdGhlIHJlZnJlc2ggbWF4IENQVSBsb2FkIHBlYWsg c28geW91IG1heSBpbmNvcnJlY3RseSBjb25zaWRlciBSUiBhcyBzb3VuZCB3aGVuIGl0IGlzIHJl YWxseSBub3QuDQoNCkNoZWVycywNClIuDQoNCg0KT24gVHVlLCBKdWwgMjIsIDIwMTQgYXQgOTox OSBQTSwgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRr b3dza2lAb3JhbmdlLmNvbT4+IHdyb3RlOg0KW1JlbmFtZWQgdG9waWNdDQoNCkhpIFJvYmVydCwN Cg0KPiBZb3VyIHJlc3VsdHMgbWF5IGFjdHVhbGx5IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlIG1v cmUgcHJvYmxlbXMgdGhlbiBnYWlucyB1bmZvcnR1bmF0ZWx5Lg0KDQpJIGRvbuKAmXQgcmVhbGx5 IHVuZGVyc3RhbmQgd2h5IOKApiBldmVuIGlmIFJSIGFyZSBub3QgaW4gdGhlIGRhdGFwbGFuZSAo d2hpY2ggd291bGQgYmUgdGhlIGNhc2UgZm9yIFZQTiBlbnZpcm9ubWVudCksIFJSIGJlaGF2aW9y IGlzIHJlYWxseSBpbXBvcnRhbnQgdG8gdHJhY2suDQoNCkNvbnNpZGVyIGEgTVBMUyBWUE4gc2Nl bmFyaW8sIHNvbWUgUEVzIGNvbm5lY3RlZCB0byBSUiBjbHVzdGVycyBhbmQgbWVzaGluZyBiZXR3 ZWVuIGNsdXN0ZXJzLg0KQ29uc2lkZXIgdGhhdCBvbmUgb2YgdGhlIFJSIGlzIGdldHRpbmcgc3R1 Y2sgYmVjYXVzZSBvZiBSb3V0ZS1yZWZyZXNoIHByb2Nlc3Npbmcgb2YgMk0gb2Ygcm91dGVzIG9y IGp1c3QgYnVzeSB0byBkbyBzb21ldGhpbmcgZWxzZSBkdWUgdG8gYmFkIHNjaGVkdWxpbmcgaW4g dGhlIGltcGxlbWVudGlvbiDigKYgaWYgYSBQRSBsb3NlIGEgY3VzdG9tZXIgY29ubmVjdGlvbiwg YW5kIGN1c3RvbWVyIGhhcyBhIGJhY2t1cCBjb25uZWN0aW9uIGFuZCBiYWNrdXAgUEUgaGFzIHRv IHNlbmQgYSBuZXcgQkdQIHVwZGF0ZSB0byBwcm9wYWdhdGUgdGhlIG5ldyBwYXRoLiBUaGUgdGlt ZSBmb3IgUlIgdG8gcHJvcGFnYXRlIHRoZSBCR1AgdXBkYXRlIGlzIGNyaXRpY2FsIHRvIHRyYWNr IGJlY2F1c2UgdGhpcyB3aWxsIGNvbmRpdGlvbiBjb252ZXJnZW5jZSB0aW1lIGZvciB0aGUgY3Vz dG9tZXIg4oCmDQoNClRob3VnaHRzID8NCg0KDQpTdGVwaGFuZQ0KDQoNCkZyb206IHJyYXN6dWtA Z21haWwuY29tPG1haWx0bzpycmFzenVrQGdtYWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdtYWls LmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1 aw0KU2VudDogVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMToxNQ0KVG86IExJVEtPV1NLSSBTdGVw aGFuZSBTQ0UvSUJORjsgSmVmZnJleSBIYWFzDQpDYzogaWRyIHdnDQpTdWJqZWN0OiBkcmFmdC1s aXRrb3dza2ktaWRyLXJ0Yy1pbnRlcmFzDQoNClN0ZXBoYW5lLA0KDQpJIGhhdmUgb25lIGZ1bmRh bWVudGFsIHF1ZXN0aW9uIG9uIHRoaXMgLi4uDQoNCllvdSBoYXZlIGZvY3VzZWQgb24gbWFraW5n IHN1cmUgdGhhdCBCR1AgY29udHJvbCBwbGFuZSB3b3JrcyBmYXN0IGFuZCBzb2xpZCBldGMuIFRo YXQgaXMgZ3JlYXQgYW5kIHRpbWVzdGFtcCBpZGVhIGF0IGVhY2ggQkdQIGhvcCB3b3VsZCBoZWxw Lg0KDQpIb3dldmVyIGxldCdzIG9ic2VydmUgdGhhdCBCR1AgY29udHJvbCBwbGFuZSBpcyBOT1Qg Y29uZ3J1ZW50IHdpdGggZGF0YSBwbGFuZS4gSW4gb3RoZXIgd29yZHMgeW91IG1heSBoYXZlIGEg Y2FzZSB3aGVyZSBzb21lb25lIG1heSBoYXZlIHNsb3cgYW5kIG92ZXJsb2FkZWQgUlIgYnV0IHVz ZXMgNDAgR0IgcGlwZXMgZm9yIGRhdGEgcGxhbmUgd2hpbGUgb3RoZXIgQVMgaW5zdGFsbGVkIHN1 cGVyLWh5cGVyIHg4NiBSUnMgYW5kIGhhcyAxIEdCIGxpbmtzIGZvciBkYXRhIHBsYW5lLg0KDQpZ b3VyIHJlc3VsdHMgbWF5IGFjdHVhbGx5IGluIHRoZSBhYm92ZSBjYXNlIGNhc3VlIG1vcmUgcHJv YmxlbXMgdGhlbiBnYWlucyB1bmZvcnR1bmF0ZWx5Lg0KDQpUaGUgcG9zc2libGUgc2ltcGxlIGZp eCBpcyB0byBtYW5kYXRlIHRoYXQgdGltZXN0YW1wIGlzIE9OTFkgYWRkZWQgd2hlbiB5b3VyIGNo YW5nZSBuZXh0IGhvcCB0byBzZWxmIG9yIHRoYXQgeW91IGNhbiBoYXZlIGEgbmV3IGZsYWcgIk4i IC0gTmV4dCBIb3AgU2V0IHdoaWNoIHdpbGwgaGVscCBhIGxvdCB0byBtYWtlIG1vcmUgdXNlIGNh c2VzIGZvciB0aGlzIHByb3Bvc2FsLg0KDQpCZXN0LA0KUi4NCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoN Cg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoN Cg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMK cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQn YWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91 bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz LgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5r IHlvdS4KCg== --_000_9E32478DFA9976438E7A22F69B08FF92044536OPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IGRvbuKAmXQgcmVhbGx5IHNlZSBob3cgYmdwIG9wcyBtZXNzYWdlIGNhbiBiZSB1c2VkIGZvciB0 aGF0IHB1cnBvc2Ug4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgbWF5IHNlZSBC R1Agb3BzIG1lc3NhZ2UgdXNhYmxlIGFzIGFuIGluZm9ybWF0aW9uIGNvbGxlY3RvciBiZXR3ZWVu IHRoZSB0b29sIGFuZCBhIEJHUCBTcGVha2VyLCBidXQgSSBkb27igJl0IHNlZSBob3cgaXQgY291 bGQgaGVscCB0byByZXRyaWV2ZSB0aW1lc3RhbXBzIGZyb20NCiBhbGwgaG9wcyBvbiB0aGUgcGF0 aCB2ZWN0b3IgZm9yIGEgc3BlY2lmaWMgTkxSSS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5j b21dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4g VHVlc2RheSwgSnVseSAyMiwgMjAxNCAxNTo1Mzxicj4NCjxiPlRvOjwvYj4gTElUS09XU0tJIFN0 ZXBoYW5lIFNDRS9JQk5GPGJyPg0KPGI+Q2M6PC9iPiBKZWZmcmV5IEhhYXM7IGlkciB3Zzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogZHJhZnQtbGl0a293c2tpLWlkci1iZ3AtdGltZXN0YW1wPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BaGggb2sgLi4gdGhlbiB3ZSBh cmUgc2xvd2x5IGdldHRpbmcgbW9yZSBvbiB0aGUgc2FtZSBwYWdlLiBXZWxsIGF0IGxlYXN0IHdl IGFyZSBvbiB0aGUgc2FtZSBib29rc2hlbGYgbm93IDopPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHRoaXMgaXMgeW91ciBhcHBsaWNhdGlv biB3aHkgbm90IHVzZSBCR1AgRGlhZ25vc3RpYyBNZXNzYWdlIGZvciBpdCBub3cgcGFydCBvZiBC R1AgT3BlcmF0aW9uYWwgTWVzc2FnZSBkcmFmdCB3aGljaCBpcyBhbiBJRFIgV0cgZG9jID8mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZHItb3BlcmF0 aW9uYWwtbWVzc2FnZS0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1p ZHItb3BlcmF0aW9uYWwtbWVzc2FnZS0wMDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSAtJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNvbWVvbmUgYXQgdGhlIElEUiBJIHRo aW5rIGFza2VkIGluIHRoZSByb29tIHRoYXQgdGhpcyBzaG91bGQgYmUgYXQgbGVhc3QgYSBzZXBh cmF0ZSBTQUZJLiBCdXQgdGlsbCB3ZSBnbyB0aGVyZSBsZXQncyBzZWUgaWYgeW91IHNlZSBwcm9i bGVtcyB3aXRoIGFkZGluZyB0aGlzIGZ1bmN0aW9uYWxpdHkgdG8gT3BlcmF0aW9uYWwgTWVzc2Fn ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ VGh4LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Ui48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVsIDIyLCAy MDE0IGF0IDk6MzggUE0sICZsdDs8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRo aW5rIHdlIGFyZSBpbmxpbmUg4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0 IG5vdCBhbGwgb2YgdGhlIGN1c3RvbWVycyByZXF1aXJlcyA1MG1zZWMgb3IgJmx0OyAxc2VjIGNv bnZlcmdlbmNlIHRpbWUuIEZvciBtb3N0IG9mIHRoZSB0cmFmZmljLA0KIHNvbWUgc2Vjb25kcyBp cyBhY2NlcHRhYmxlIGFuZCB0aGVyZSBpcyBubyBuZWVkIHRvIGRlcGxveSBkYXRhcGxhbmUgcHJv dGVjdGlvbiBmb3Igc3VjaCBwdXJwb3NlLiBCdXQgYW55d2F5LCB3ZSBoYXZlIHRvIHRyYWNrIGFi bm9ybWFsIGJlaGF2aW9ycyBvZiB0aGUgY29udHJvbHBsYW5lIChyYWNlIGNvbmRpdGlvbnMsIGNv cm5lciBjYXNlcyDigKYpIHdoZXJlIGl0IGRvZXMgbm90IGRvIGl0cyBqb2IgY29ycmVjdGx5IOKA pg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSB3YXMgYWxzbyB0aGlua2luZyBhYm91dCBwcm9wYWdhdGlvbiB0 aW1lIG9mIEMtbXVsdGljYXN0IHJvdXRlIChhdCBsZWFzdCB0eXBlIDUvNi83KSB3aGljaCBpcyBj cml0aWNhbA0KIOKApiBhbmQgY3VzdG9tZXIgY2Fubm90IHdhaXQgMzAvNTAgc2Vjb25kcyAob3Ig c29tZSBob3VycyDigKYgZG9u4oCZdCBsYXVnaCwgaXTigJlzIG5vdCBhIGpva2Ug4oCmKSB0byBy ZWNlaXZlIHRoZSBncm91cCBtZW1iZXJzaGlwIOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk91ciBwcm9wb3Nh bCBkb2VzIG5vdCBwcm9uZSBpbiBhbnl3YXkgdG8gdXNlIGNvbnRyb2xwbGFuZSBvciBkYXRhcGxh bmUgdG8gbWFuYWdlIGFueSByZWR1bmRhbmN5IOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIGEg bmVlZCB0byBtb25pdG9yIEJHUCBjb250cm9scGxhbmUgYmVoYXZpb3IgYW5kIGVzcGVjaWFsbHkg dXBkYXRlIHByb3BhZ2F0aW9uIHRpbWUgOiB0aGUNCiBiYXNpYyB1c2UgY2FzZSBpcyByZWFsbHkg dG8gZW5zdXJlIHRoYXQgZXZlcnl0aGluZyBnb2VzIHdlbGwg4oCmIGNvbXBhcmVkIHRvIHRoZSBi YXNlIGxpbmUgd2UgZXZhbHVhdGVkIGluIGxhYnMgb3IgdGhlb3J5Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnJh c3p1a0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh eSwgSnVseSAyMiwgMjAxNCAxNTozMDxicj4NCjxiPlRvOjwvYj4gTElUS09XU0tJIFN0ZXBoYW5l IFNDRS9JQk5GPGJyPg0KPGI+Q2M6PC9iPiBKZWZmcmV5IEhhYXM7IGlkciB3Zzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogZHJhZnQtbGl0a293c2tpLWlkci1iZ3AtdGltZXN0YW1wPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3RlcGhhbmUs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5JZiB5b3UgYnVpbGQgeW91ciBzZXJ2aWNlIGNvdW50aW5nIG9uIGNvbnRyb2wgcGxhbmUgY29u dmVyZ2VuY2UgSSB0aGluayB5b3UgYXJlIGRvaW5nIGJhZCB0aGluZyA6KSBTb3JyeS4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PklmIHRoaXMgZHJhZnQgaXMgdG8gZnVydGhlciBoZWxwIHdpdGggc3VjaCBkZXNpZ25zIEkgd291 bGQgY2xlYXJseSBzd2l0Y2ggdG8gJnF1b3Q7bm8gc3VwcG9ydCZxdW90OyBpbW1lZGlhdGVseS4g SSBoYWQgb3RoZXIgdXNlIGNhc2VzIGluIG1pbmQgd2hpY2gNCiBkaWQgbm90IHNvdW5kIG5lZ2F0 aXZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+U3BlY2lmaWNhbGx5IGluIHlvdXIgY2FzZSBpZiBvbmUgUEUgb2YgbXVsdGlob21lZCBz aXRlIGxvb3NlcyBQRS1DRSB5b3UgbG9jYWxseSBwcm90ZWN0IHRoZSBzaXRlICgxMHMgbXMgbWF4 KSBhbmQgdGFrZSBhbGwgdGltZSBpdCBuZWVkcw0KIGZvciBCR1AgdG8gY29udmVyZ2UgcmVnYXJk bGVzcyBob3cgbG9uZyBpdCB0YWtlcy4gT2YgY291cnNlIEkgYW0gYXNzdW1pbmcgYmFzaWMgcnVs ZXMgbGlrZSB1bmlxdWUgUkQgcGVyIFZSRiBpbiBwbGFjZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBtb3N0IGltcG9ydGFudCBp cyB0byBtYWludGFpbiBkYXRhIHBsYW5lIGNvbm5lY3Rpdml0eS4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc2lkZXMgSSBh bSBub3Qgc3VyZSBob3cgdGltZXN0YW1wIHdpbGwgaGVscCB5b3UgaW4gdGhpcyBjYXNlLiBMZWF2 ZSBhbG9uZSB0aGF0IHRpbWVzdGFtcCBtYXkgbmV2ZXIgY2F0Y2ggdGhlIHJlZnJlc2ggbWF4IENQ VSBsb2FkIHBlYWsNCiBzbyB5b3UgbWF5IGluY29ycmVjdGx5IGNvbnNpZGVyIFJSIGFzIHNvdW5k IHdoZW4gaXQgaXMgcmVhbGx5IG5vdC4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoZWVycyw8YnI+DQpSLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBKdWwg MjIsIDIwMTQgYXQgOToxOSBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRrb3dz a2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2Uu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PltSZW5hbWVkIHRvcGljXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJvYmVydCw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m Z3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+IFlvdXIgcmVzdWx0cyBtYXkgYWN0dWFsbHkgaW4gdGhlIGFib3ZlIGNhc2UgY2FzdWUNCiBt b3JlIHByb2JsZW1zIHRoZW4gZ2FpbnMgdW5mb3J0dW5hdGVseS4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JIGRvbuKAmXQgcmVhbGx5IHVuZGVyc3RhbmQgd2h5IOKApiBldmVuIGlmIFJSIGFyZSBub3Qg aW4gdGhlIGRhdGFwbGFuZSAod2hpY2ggd291bGQgYmUgdGhlIGNhc2UgZm9yDQogVlBOIGVudmly b25tZW50KSwgUlIgYmVoYXZpb3IgaXMgcmVhbGx5IGltcG9ydGFudCB0byB0cmFjay48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Db25zaWRlciBhIE1QTFMgVlBOIHNjZW5hcmlvLCBzb21lIFBFcyBjb25uZWN0ZWQg dG8gUlIgY2x1c3RlcnMgYW5kIG1lc2hpbmcgYmV0d2VlbiBjbHVzdGVycy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Db25zaWRlciB0aGF0IG9uZSBvZiB0aGUgUlIgaXMgZ2V0dGlu ZyBzdHVjayBiZWNhdXNlIG9mIFJvdXRlLXJlZnJlc2ggcHJvY2Vzc2luZyBvZiAyTSBvZiByb3V0 ZXMNCiBvciBqdXN0IGJ1c3kgdG8gZG8gc29tZXRoaW5nIGVsc2UgZHVlIHRvIGJhZCBzY2hlZHVs aW5nIGluIHRoZSBpbXBsZW1lbnRpb24g4oCmIGlmIGEgUEUgbG9zZSBhIGN1c3RvbWVyIGNvbm5l Y3Rpb24sIGFuZCBjdXN0b21lciBoYXMgYSBiYWNrdXAgY29ubmVjdGlvbiBhbmQgYmFja3VwIFBF IGhhcyB0byBzZW5kIGEgbmV3IEJHUCB1cGRhdGUgdG8gcHJvcGFnYXRlIHRoZSBuZXcgcGF0aC4g VGhlIHRpbWUgZm9yIFJSIHRvIHByb3BhZ2F0ZSB0aGUgQkdQDQogdXBkYXRlIGlzIGNyaXRpY2Fs IHRvIHRyYWNrIGJlY2F1c2UgdGhpcyB3aWxsIGNvbmRpdGlvbiBjb252ZXJnZW5jZSB0aW1lIGZv ciB0aGUgY3VzdG9tZXIg4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhvdWdodHMgPzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN0ZXBoYW5lPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29tPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpycmFzenVrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29t PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDExOjE1PGJyPg0KPGI+VG86PC9iPiBMSVRLT1dTS0kg U3RlcGhhbmUgU0NFL0lCTkY7IEplZmZyZXkgSGFhczxicj4NCjxiPkNjOjwvYj4gaWRyIHdnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IGRyYWZ0LWxpdGtvd3NraS1pZHItcnRjLWludGVyYXM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3RlcGhhbmUsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGhhdmUgb25l IGZ1bmRhbWVudGFsIHF1ZXN0aW9uIG9uIHRoaXMgLi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Zb3UgaGF2ZSBmb2N1c2VkIG9uIG1h a2luZyBzdXJlIHRoYXQgQkdQIGNvbnRyb2wgcGxhbmUgd29ya3MgZmFzdCBhbmQgc29saWQgZXRj LiBUaGF0IGlzIGdyZWF0IGFuZCB0aW1lc3RhbXAgaWRlYSBhdCBlYWNoIEJHUCBob3Agd291bGQg aGVscC4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPkhvd2V2ZXIgbGV0J3Mgb2JzZXJ2ZSB0aGF0IEJHUCBjb250cm9sIHBsYW5l IGlzIE5PVCBjb25ncnVlbnQgd2l0aCBkYXRhIHBsYW5lLiBJbiBvdGhlciB3b3JkcyB5b3UgbWF5 IGhhdmUgYSBjYXNlIHdoZXJlIHNvbWVvbmUgbWF5IGhhdmUNCiBzbG93IGFuZCBvdmVybG9hZGVk IFJSIGJ1dCB1c2VzIDQwIEdCIHBpcGVzIGZvciBkYXRhIHBsYW5lIHdoaWxlIG90aGVyIEFTIGlu c3RhbGxlZCBzdXBlci1oeXBlciB4ODYgUlJzIGFuZCBoYXMgMSBHQiBsaW5rcyBmb3IgZGF0YSBw bGFuZS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPllvdXIgcmVzdWx0cyBtYXkgYWN0dWFsbHkgaW4gdGhlIGFib3ZlIGNhc2Ug Y2FzdWUgbW9yZSBwcm9ibGVtcyB0aGVuIGdhaW5zIHVuZm9ydHVuYXRlbHkuJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUg cG9zc2libGUgc2ltcGxlIGZpeCBpcyB0byBtYW5kYXRlIHRoYXQgdGltZXN0YW1wIGlzIE9OTFkg YWRkZWQgd2hlbiB5b3VyIGNoYW5nZSBuZXh0IGhvcCB0byBzZWxmIG9yIHRoYXQgeW91IGNhbiBo YXZlIGEgbmV3IGZsYWcgJnF1b3Q7TiZxdW90Ow0KIC0gTmV4dCBIb3AgU2V0IHdoaWNoIHdpbGwg aGVscCBhIGxvdCB0byBtYWtlIG1vcmUgdXNlIGNhc2VzIGZvciB0aGlzIHByb3Bvc2FsLiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+QmVzdCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Ui48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u PG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cHJlPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286 cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48 L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48 L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91 Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_9E32478DFA9976438E7A22F69B08FF92044536OPEXCLILM34corpor_-- From nobody Tue Jul 22 13:28:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228761A03BB for ; Tue, 22 Jul 2014 13:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-T9hEDFRdgl for ; Tue, 22 Jul 2014 13:28:06 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0DF1A0023 for ; Tue, 22 Jul 2014 13:28:06 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id hz20so159820lab.36 for ; Tue, 22 Jul 2014 13:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HfZWVKr2bNr3oO3mTOD6oSSphIbJHj4+rYfIwNv5f/A=; b=p04oh/UXsOscdxRJcvjD8BVz2QYf7opbaKuZuQKkKk5REh7ixfLk1RrqFRHOeeaDSR KxeCJSqBEAlyaJC/TrjFOsqe9NYPSi8NExa8KFPq32dpr5ktayI0xQswhLRIW9palwnm q7b9PHNY5hSwM52rPGmMh9yIDEaxnziis4ssBFfh02RYk2cq5XUDQbr18huNfksQgFA2 WtyfZUsm/GJPW+LgD2758ejNr2yWGX+eDXrdtcsApz93kAH5yMqLnjnb625v9DARsPTE E0qCVPljbj6mJvirTmHVhYc+U1HVNVkdsnjYHogcnXQZdMHO1Bg+42nwk+vIXW9/eoZt aPjA== MIME-Version: 1.0 X-Received: by 10.112.33.74 with SMTP id p10mr36771913lbi.0.1406060884490; Tue, 22 Jul 2014 13:28:04 -0700 (PDT) Received: by 10.112.18.166 with HTTP; Tue, 22 Jul 2014 13:28:04 -0700 (PDT) In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Date: Tue, 22 Jul 2014 13:28:04 -0700 Message-ID: From: Sachin K To: John Scudder Content-Type: multipart/alternative; boundary=14dae94734a38d83c904fece0f18 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/fKqf9rbixz2aOqV6V82sP3FKPjg Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:28:08 -0000 --14dae94734a38d83c904fece0f18 Content-Type: text/plain; charset=UTF-8 Support. -Sachin Karisiddappa On Tue, Jul 22, 2014 at 12:43 PM, John Scudder wrote: > Folks, > > The authors have requested IDR adopt > draft-vandevelde-idr-remote-next-hop-06 as a working group document. > > http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > > Please send any comments to the list by August 8. > > In addition to commenting on adoption of the work, you may want to comment > on whether the draft is mature enough for us to consider early allocation > of the path attribute code point. As a reminder, RFC 7120 requires that for > early allocation, "the specifications of these code points must be stable". > (Section 2.c.) The chairs and ADs also have to "judge that there is > sufficient interest in the community for early (pre-RFC) implementation and > deployment". (Section 2.d.) > > It's fine to be in favor of WG adoption but opposed to early allocation at > this time, or in favor of both, or against both. Being against adoption but > in favor of allocation would be a bit weird. :-) > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --14dae94734a38d83c904fece0f18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support.

-Sachin Karisiddappa

On Tue, Jul 22, 2014 at 12:43 PM, John Scudder= <jgs@juniper.net> wrote:
Folks,

The authors have requested IDR adopt draft-vandevelde-idr-remote-next-hop-0= 6 as a working group document.

http://datatracker.ietf.org/doc/draft-vandevelde-i= dr-remote-next-hop/

Please send any comments to the list by August 8.

In addition to commenting on adoption of the work, you may want to comment = on whether the draft is mature enough for us to consider early allocation o= f the path attribute code point. As a reminder, RFC 7120 requires that for = early allocation, "the specifications of these code points must be sta= ble". (Section 2.c.) The chairs and ADs also have to "judge that = there is sufficient interest in the community for early (pre-RFC) implement= ation and deployment". (Section 2.d.)

It's fine to be in favor of WG adoption but opposed to early allocation= at this time, or in favor of both, or against both. Being against adoption= but in favor of allocation would be a bit weird. :-)

Thanks,

--John

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

--14dae94734a38d83c904fece0f18-- From nobody Tue Jul 22 13:33:02 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3271A0169 for ; Tue, 22 Jul 2014 13:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G59M9LARfBu for ; Tue, 22 Jul 2014 13:32:59 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C221A0118 for ; Tue, 22 Jul 2014 13:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1182; q=dns/txt; s=iport; t=1406061179; x=1407270779; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vA94/9L7CuoMzVFelIDJuHwLAEdQAoePHr2YWONc2Xw=; b=ZJeZmr9LmF4DbW919aP6cJWLucCcsKTEsB5r0PywDNQaZ+obJnicm7ha edDQ4boWA40h2eYzzlZS2htcK7e9NYQDyh2LDN1ltkyin/gEJwtmBSdnt FdNrVUqDMH8TBFCegH2+9n7reC5ycuTyQkAu1YA096ywxrWIpNrOeShzh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYFAFzJzlOtJV2d/2dsb2JhbABYgw5SVwTHFAqHRQGBExZ2hAQBAQQBAQE3NBsCAQgOKBAnCyUCBAESFIguDb9vF49ShEYFmyeBTZJmg0ZsgUU X-IronPort-AV: E=Sophos;i="5.01,712,1400025600"; d="scan'208";a="63131288" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 22 Jul 2014 20:32:58 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6MKWwrS023105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 20:32:58 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.235]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 15:32:58 -0500 From: "Anoop Kapoor (ankapoor)" To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 Thread-Index: AQHPpewfuOJzq3mte0KYqLdgycev6Q== Date: Tue, 22 Jul 2014 20:32:57 +0000 Message-ID: References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.154.209.244] Content-Type: text/plain; charset="us-ascii" Content-ID: <7B331EF44D7EB14B959C4820C5B068A7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/fcBVij9j9Oer-mOYtRaLLDbZA_A Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:33:01 -0000 support On 7/22/14 12:43 PM, "John Scudder" wrote: >Folks, > >The authors have requested IDR adopt >draft-vandevelde-idr-remote-next-hop-06 as a working group document. > >http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > >Please send any comments to the list by August 8. > >In addition to commenting on adoption of the work, you may want to >comment on whether the draft is mature enough for us to consider early >allocation of the path attribute code point. As a reminder, RFC 7120 >requires that for early allocation, "the specifications of these code >points must be stable". (Section 2.c.) The chairs and ADs also have to >"judge that there is sufficient interest in the community for early >(pre-RFC) implementation and deployment". (Section 2.d.) > >It's fine to be in favor of WG adoption but opposed to early allocation >at this time, or in favor of both, or against both. Being against >adoption but in favor of allocation would be a bit weird. :-) > >Thanks, > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jul 22 13:48:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BA71A02F2 for ; Tue, 22 Jul 2014 13:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFxBsoP4pwPd for ; Tue, 22 Jul 2014 13:48:12 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E551A02EF for ; Tue, 22 Jul 2014 13:48:12 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s6MKmAh9016184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jul 2014 15:48:11 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6MKm9cP016149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 22:48:09 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 22 Jul 2014 22:48:09 +0200 From: "Henderickx, Wim (Wim)" To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 Thread-Index: AQHPpe4+KF6bg8LfUEOpQlKkqVNU6w== Date: Tue, 22 Jul 2014 20:48:09 +0000 Message-ID: References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/owLNdC4iLIid05ZJjZc4tCmtScg Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:48:14 -0000 Support On 22/07/14 15:43, "John Scudder" wrote: >Folks, > >The authors have requested IDR adopt >draft-vandevelde-idr-remote-next-hop-06 as a working group document. > >http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > >Please send any comments to the list by August 8. > >In addition to commenting on adoption of the work, you may want to >comment on whether the draft is mature enough for us to consider early >allocation of the path attribute code point. As a reminder, RFC 7120 >requires that for early allocation, "the specifications of these code >points must be stable". (Section 2.c.) The chairs and ADs also have to >"judge that there is sufficient interest in the community for early >(pre-RFC) implementation and deployment". (Section 2.d.) > >It's fine to be in favor of WG adoption but opposed to early allocation >at this time, or in favor of both, or against both. Being against >adoption but in favor of allocation would be a bit weird. :-) > >Thanks, > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jul 22 13:56:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81711B2BFC for ; Tue, 22 Jul 2014 13:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUZiCfk2sQQo for ; Tue, 22 Jul 2014 13:56:24 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233381A0365 for ; Tue, 22 Jul 2014 13:56:24 -0700 (PDT) Received: from cfrink-sslvpn-nc.jnpr.net (66.129.241.12) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 20:56:21 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "John G. Scudder" In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Date: Tue, 22 Jul 2014 16:56:13 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> To: "idr@ietf. org" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CO2PR11CA0017.namprd11.prod.outlook.com (10.141.242.155) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02801ACE41 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(377454003)(51704005)(199002)(164054003)(24454002)(189002)(83716003)(92726001)(83072002)(92566001)(33656002)(46406003)(86362001)(102836001)(15202345003)(85852003)(93916002)(87286001)(89996001)(23726002)(31966008)(87976001)(88136002)(101416001)(77156001)(36756003)(50466002)(81542001)(66066001)(47776003)(81342001)(64706001)(20776003)(110136001)(80022001)(46102001)(15975445006)(82746002)(69596002)(83322001)(19580395003)(19580405001)(77982001)(57306001)(105586002)(85306003)(95666004)(77096002)(106356001)(104166001)(74502001)(74662001)(107886001)(62966002)(42186005)(79102001)(76482001)(76176999)(99396002)(53416004)(50986999)(81156004)(107046002)(4396001)(50226001)(97756001)(21056001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:cfrink-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/TLC22IMX_5Is5D1TIqBZJ1Qx6Lw Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:56:26 -0000 Let me add that a simple "support" will be deemed to mean "support WG = adoption". --John On Jul 22, 2014, at 3:43 PM, John Scudder wrote: > Folks, >=20 > The authors have requested IDR adopt = draft-vandevelde-idr-remote-next-hop-06 as a working group document.=20 >=20 > http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ >=20 > Please send any comments to the list by August 8.=20 >=20 > In addition to commenting on adoption of the work, you may want to = comment on whether the draft is mature enough for us to consider early = allocation of the path attribute code point. As a reminder, RFC 7120 = requires that for early allocation, "the specifications of these code = points must be stable". (Section 2.c.) The chairs and ADs also have to = "judge that there is sufficient interest in the community for early = (pre-RFC) implementation and deployment". (Section 2.d.) >=20 > It's fine to be in favor of WG adoption but opposed to early = allocation at this time, or in favor of both, or against both. Being = against adoption but in favor of allocation would be a bit weird. :-)=20 >=20 > Thanks, >=20 > --John >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jul 22 14:07:43 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE51E1B29B8 for ; Tue, 22 Jul 2014 14:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7rtCKnwk_NC for ; Tue, 22 Jul 2014 14:07:37 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58E91A0183 for ; Tue, 22 Jul 2014 14:07:36 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn18so4494384igb.3 for ; Tue, 22 Jul 2014 14:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=q9HTm4h9fiYX1GlTbjlXeOICdBUaVPcNfJ3pVjmxNlQ=; b=crFEQGCqcN/Q1q3gxw2T9jWgJ0qOeagN4tKNs8qgyfPFAYdi83ZhiZp++kdCspgM+f kAb+lGAq5ys5ndgB/9qCXZNAIu4qKWJRMu0hT6HwhCHokHyfChVa3r80bmJmhOavAtrg X9n5fRfYxAyD7szJHvaMNsVmiZtNLF8zxFrFUWJaJjB1h2/J+ygG/rNn7rX6kPVRpHoy FJKHGzZvi5a3HRqJPuRHfn7xH8/5Q6XwqYiklk+Q2zwn7rKqKHnNkkIbK3mdHXaOxXoR 8RsiZB9VTibNRGALN072w+ed2pbPO8y5mJSqeCJE+L6UYCT7XBeskDqRhqorhCY6Qi+V fW5w== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr20515200igb.21.1406063256029; Tue, 22 Jul 2014 14:07:36 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 22 Jul 2014 14:07:35 -0700 (PDT) In-Reply-To: References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Date: Tue, 22 Jul 2014 23:07:35 +0200 X-Google-Sender-Auth: XvRqareFw6T5LM_lh1fj0cO-fmA Message-ID: From: Robert Raszuk To: "John G. Scudder" Content-Type: multipart/alternative; boundary=089e013a0c68e8c60c04fece9c5c Archived-At: http://mailarchive.ietf.org/arch/msg/idr/CJ582Q3Ga0xJpuZrhu5Soa8lACw Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:07:42 -0000 --089e013a0c68e8c60c04fece9c5c Content-Type: text/plain; charset=UTF-8 Support (as co-author) On Tue, Jul 22, 2014 at 10:56 PM, John G. Scudder wrote: > Let me add that a simple "support" will be deemed to mean "support WG > adoption". > > --John > > On Jul 22, 2014, at 3:43 PM, John Scudder wrote: > > > Folks, > > > > The authors have requested IDR adopt > draft-vandevelde-idr-remote-next-hop-06 as a working group document. > > > > http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > > > > Please send any comments to the list by August 8. > > > > In addition to commenting on adoption of the work, you may want to > comment on whether the draft is mature enough for us to consider early > allocation of the path attribute code point. As a reminder, RFC 7120 > requires that for early allocation, "the specifications of these code > points must be stable". (Section 2.c.) The chairs and ADs also have to > "judge that there is sufficient interest in the community for early > (pre-RFC) implementation and deployment". (Section 2.d.) > > > > It's fine to be in favor of WG adoption but opposed to early allocation > at this time, or in favor of both, or against both. Being against adoption > but in favor of allocation would be a bit weird. :-) > > > > 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 > --089e013a0c68e8c60c04fece9c5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support (as co-author)


On Tue, Jul 22, 2014 at= 10:56 PM, John G. Scudder <jgs@juniper.net> wrote:
Let me add that a simple "support"= will be deemed to mean "support WG adoption".

--John

On Jul 22, 2014, at 3:43 PM, John Scudder <jgs@juniper.net> wrote:

> Folks,
>
> The authors have requested IDR adopt draft-vandevelde-idr-remote-next-= hop-06 as a working group document.
>
> http://datatracker.ietf.org/doc/draft-vandeve= lde-idr-remote-next-hop/
>
> Please send any comments to the list by August 8.
>
> In addition to commenting on adoption of the work, you may want to com= ment on whether the draft is mature enough for us to consider early allocat= ion of the path attribute code point. As a reminder, RFC 7120 requires that= for early allocation, "the specifications of these code points must b= e stable". (Section 2.c.) The chairs and ADs also have to "judge = that there is sufficient interest in the community for early (pre-RFC) impl= ementation and deployment". (Section 2.d.)
>
> It's fine to be in favor of WG adoption but opposed to early alloc= ation at this time, or in favor of both, or against both. Being against ado= ption but in favor of allocation would be a bit weird. :-)
>
> Thanks,
>
> --John
>
> _______________________________________________
> 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

--089e013a0c68e8c60c04fece9c5c-- From nobody Tue Jul 22 14:14:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8037D1A03A5 for ; Tue, 22 Jul 2014 14:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENmnEBU199Li for ; Tue, 22 Jul 2014 14:14:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E809C1A0149 for ; Tue, 22 Jul 2014 14:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1364; q=dns/txt; s=iport; t=1406063657; x=1407273257; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1TAJ2isylII6h6vvE1kSD8yQItKBbgk+bivH9Bka0B4=; b=lbmtUfdKAxBguGsjET6tNP1defu7UyXxQ+eijo97Q57uAoVxh+ApB7wW EwXyMk29dGKn4jx5pzRLs+VSL7JmhR5scS36JciBPVqJs1DtXDhLSDTTf JbJMKT4okI/Lf/y3Yi2/Bx4wZnsrL6RtCLV0tz/Whu2Nx1zBG/X+1TcE9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAH7TzlOtJV2d/2dsb2JhbABZgw5SVwTHFgqHRQGBExZ2hAMBAQEEAQEBNzQXBAIBCA4DBAEBCxQJBycLFAkIAgQBEggMiC4Nv3cXjxo4BoMogRgFnHSSZoNGbIFF X-IronPort-AV: E=Sophos;i="5.01,712,1400025600"; d="scan'208";a="341859092" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 22 Jul 2014 21:14:17 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6MLEFQo018590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 21:14:15 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.10]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 16:14:15 -0500 From: "Gunter Van de Velde (gvandeve)" To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 Thread-Index: AQHPpeVE/xV/L+/6OkWStWLoIYp9s5usl+vA Date: Tue, 22 Jul 2014 21:12:56 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B24114270B5@xmb-aln-x12.cisco.com> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.219.178] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/wLfsLs2pycyL-G9kSMmxBvDM3U0 Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:14:18 -0000 Support (as co-author) G/ -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder Sent: 22 July 2014 15:43 To: idr@ietf. org Subject: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-h= op-06 Folks, The authors have requested IDR adopt draft-vandevelde-idr-remote-next-hop-0= 6 as a working group document.=20 http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ Please send any comments to the list by August 8.=20 In addition to commenting on adoption of the work, you may want to comment = on whether the draft is mature enough for us to consider early allocation o= f the path attribute code point. As a reminder, RFC 7120 requires that for = early allocation, "the specifications of these code points must be stable".= (Section 2.c.) The chairs and ADs also have to "judge that there is suffic= ient interest in the community for early (pre-RFC) implementation and deplo= yment". (Section 2.d.) It's fine to be in favor of WG adoption but opposed to early allocation at = this time, or in favor of both, or against both. Being against adoption but= in favor of allocation would be a bit weird. :-)=20 Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jul 22 14:28:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DDA1B2C36 for ; Tue, 22 Jul 2014 14:28: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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0_DJaPPkiHR for ; Tue, 22 Jul 2014 14:28:11 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (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 6D48D1B2C35 for ; Tue, 22 Jul 2014 14:28:11 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.8/8.14.5) with ESMTP id s6MLRZl1009365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Jul 2014 17:27:35 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.8/8.14.8/Submit) id s6MLRZQw009364; Tue, 22 Jul 2014 17:27:35 -0400 Date: Tue, 22 Jul 2014 17:27:35 -0400 From: Jon Mitchell To: stephane.litkowski@orange.com Message-ID: <20140722212735.GA11770@puck.nether.net> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.7 (puck.nether.net [127.0.0.1]); Tue, 22 Jul 2014 17:27:36 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/6-onFxCob-1f6eggQK_KUSLnoTU Cc: Jeffrey Haas , idr wg , Robert Raszuk Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:28:12 -0000 On 22/07/14 19:19 +0000, stephane.litkowski@orange.com wrote: > [Renamed topic] >=20 > Hi Robert, >=20 > > Your results may actually in the above case casue more problems then ga= ins unfortunately. >=20 > I don=E2=80=99t really understand why =E2=80=A6 even if RR are not in the= dataplane (which would be the case for VPN environment), RR behavior is re= ally important to track. >=20 > Consider a MPLS VPN scenario, some PEs connected to RR clusters and meshi= ng between clusters. > Consider that one of the RR is getting stuck because of Route-refresh pro= cessing of 2M of routes or just busy to do something else due to bad schedu= ling in the implemention =E2=80=A6 if a PE lose a customer connection, and = customer has a backup connection and backup PE has to send a new BGP update= to propagate the new path. The time for RR to propagate the BGP update is = critical to track because this will condition convergence time for the cust= omer =E2=80=A6 >=20 > Thoughts ? Stephane - I'm supportive of your goal, however after the presentation I'm still a bit= unclear on the need for the BGP extension to propogate the timestamp infor= mation. As was brought up by Saikat today in the WG meeting, if update pac= king is different for this prefix due to the timestamp attribute then it lo= ses some of it's value for providing an accurate view of your end to end BG= P propogation time. Someone suggested BMP, it appears it already supports = this option in paragraph 3 of Section 5 of that draft. The justification g= iven that instrumenting sessions (BMP/BGP/or other export mechanism for the= data) to all routers versus getting the information from egress PE only do= es not seem to be a large concern if monitoring this route propogation is o= f importance to the operator. After all presumably there are a much larger= number of PE's in most networks than RR's so instrumenting monitoring all = devices is not much more work than just the PE's. Specifying or identifyin= g which prefixes are monitored (the timestamp is collected and exported for= ) seems also like something that can be handled by the local implementation= based on a community or other attributes. Jon From nobody Tue Jul 22 14:31:11 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136641B2C38 for ; Tue, 22 Jul 2014 14:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBDftE_x3llR for ; Tue, 22 Jul 2014 14:31:09 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (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 E03F31B2C5E for ; Tue, 22 Jul 2014 14:31:08 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.8/8.14.5) with ESMTP id s6MLV5Zb011076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Jul 2014 17:31:05 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.8/8.14.8/Submit) id s6MLV5Va011075; Tue, 22 Jul 2014 17:31:05 -0400 Date: Tue, 22 Jul 2014 17:31:05 -0400 From: Jon Mitchell To: John Scudder Message-ID: <20140722213105.GB11770@puck.nether.net> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.7 (puck.nether.net [127.0.0.1]); Tue, 22 Jul 2014 17:31:06 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/TeAZAY_FDkwHMredNKTi1pCe4yA Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:31:10 -0000 On 22/07/14 15:43 -0400, John Scudder wrote: > Folks, > > The authors have requested IDR adopt draft-vandevelde-idr-remote-next-hop-06 as a working group document. > > http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > > Please send any comments to the list by August 8. > > In addition to commenting on adoption of the work, you may want to comment on whether the draft is mature enough for us to consider early allocation of the path attribute code point. As a reminder, RFC 7120 requires that for early allocation, "the specifications of these code points must be stable". (Section 2.c.) The chairs and ADs also have to "judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment". (Section 2.d.) > > It's fine to be in favor of WG adoption but opposed to early allocation at this time, or in favor of both, or against both. Being against adoption but in favor of allocation would be a bit weird. :-) Support for adoption. -Jon From nobody Tue Jul 22 15:00:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DB01B2CCC for ; Tue, 22 Jul 2014 15:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5fv9oKvhppR for ; Tue, 22 Jul 2014 15:00:43 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FF11A03EA for ; Tue, 22 Jul 2014 15:00:42 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 131so225806ykp.14 for ; Tue, 22 Jul 2014 15:00:42 -0700 (PDT) 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:content-type; bh=cjLA/tN9Gqx2cY36D+fNWn78/yXdcX3CWMJwjaXuuak=; b=B3zaPQj748K39R+6hyeQX4HubGCCkjHIU3XnYfQiURbb2VjvNgz/shLMS644e9WB48 xJBd3yy/VP9jQic6ivNtH3WZOA20ksvpF3ZvkHrXJwp4Pt/QDozobAVAFuAe/YrRAvEY 2sj7w40FFSuqqw0fc5P5TCVd6FDh4rmpoVWUI2kUKqkiyUApzpMZlXs/upqKnEHwxOYC uFfxlUaH8qbbr8U34NrPRdRKtDv7kS+BPWHELt71tzSycj2imPVkHZSWaYiLwYNDrVs1 RPjY85CgyuLdFdACx3XhMTkHHfTJmw9yUSWiIErQTt+3z0yMbtXXn7InKQxkTNChx2G5 Ggzw== X-Received: by 10.236.143.229 with SMTP id l65mr54514082yhj.95.1406066442248; Tue, 22 Jul 2014 15:00:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.118.85 with HTTP; Tue, 22 Jul 2014 15:00:22 -0700 (PDT) In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> From: KK Chittimaneni Date: Tue, 22 Jul 2014 15:00:22 -0700 Message-ID: To: John Scudder Content-Type: multipart/alternative; boundary=20cf3036391dd228fd04fecf5ae8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/4ecIExtZB5Lghdk1UTEIdJDU2JA Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:00:44 -0000 --20cf3036391dd228fd04fecf5ae8 Content-Type: text/plain; charset=UTF-8 Support for adoption. On Tue, Jul 22, 2014 at 12:43 PM, John Scudder wrote: > Folks, > > The authors have requested IDR adopt > draft-vandevelde-idr-remote-next-hop-06 as a working group document. > > http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > > Please send any comments to the list by August 8. > > In addition to commenting on adoption of the work, you may want to comment > on whether the draft is mature enough for us to consider early allocation > of the path attribute code point. As a reminder, RFC 7120 requires that for > early allocation, "the specifications of these code points must be stable". > (Section 2.c.) The chairs and ADs also have to "judge that there is > sufficient interest in the community for early (pre-RFC) implementation and > deployment". (Section 2.d.) > > It's fine to be in favor of WG adoption but opposed to early allocation at > this time, or in favor of both, or against both. Being against adoption but > in favor of allocation would be a bit weird. :-) > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --20cf3036391dd228fd04fecf5ae8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support for adoption.
=

On Tue, Jul 22, 2014 at 12:43 PM, John S= cudder <jgs@juniper.net> wrote:
Folks,

The authors have requested IDR adopt draft-vandevelde-idr-remote-next-hop-0= 6 as a working group document.

http://datatracker.ietf.org/doc/draft-vandevelde-i= dr-remote-next-hop/

Please send any comments to the list by August 8.

In addition to commenting on adoption of the work, you may want to comment = on whether the draft is mature enough for us to consider early allocation o= f the path attribute code point. As a reminder, RFC 7120 requires that for = early allocation, "the specifications of these code points must be sta= ble". (Section 2.c.) The chairs and ADs also have to "judge that = there is sufficient interest in the community for early (pre-RFC) implement= ation and deployment". (Section 2.d.)

It's fine to be in favor of WG adoption but opposed to early allocation= at this time, or in favor of both, or against both. Being against adoption= but in favor of allocation would be a bit weird. :-)

Thanks,

--John

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

--20cf3036391dd228fd04fecf5ae8-- From nobody Tue Jul 22 15:01:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432431B2CD8 for ; Tue, 22 Jul 2014 15:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BliCYARD8DsH for ; Tue, 22 Jul 2014 15:00:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA791B2CD7 for ; Tue, 22 Jul 2014 15:00:56 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id ED417325E03; Wed, 23 Jul 2014 00:00:54 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CB419238055; Wed, 23 Jul 2014 00:00:54 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 23 Jul 2014 00:00:54 +0200 From: To: Jon Mitchell Thread-Topic: [Idr] draft-litkowski-idr-bgp-timestamp Thread-Index: Ac+l4ODPJH0/NfV4QnGw7fCPCrH3LgAAhyeAAATe6BA= Date: Tue, 22 Jul 2014 22:00:53 +0000 Message-ID: <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722212735.GA11770@puck.nether.net> In-Reply-To: <20140722212735.GA11770@puck.nether.net> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/cR271VCcNMMBAhuvyn8avgx3VvU Cc: Jeffrey Haas , idr wg , Robert Raszuk Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:01:01 -0000 SGkgSm9uLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudC4NClJlZ2FyZGluZyBwYWNraW5nLCBk ZXBlbmRpbmcgb2YgdGhlIGFkZHJlc3MgZmFtaWx5IHlvdSBhcmUgdHJ5aW5nIHRvIG1vbml0b3Is IGN1cnJlbnQgcGFja2luZyBtYXkgYmUgbG93IG9yIGhpZ2guIEluIGNhc2Ugd2hlcmUgZXhpc3Rp bmcgcGFja2luZyBpcyBsb3csIGl0IGRvZXMgbm90IGNoYW5nZSBhbnl0aGluZy4gSW4gY2FzZSBw YWNraW5nIGlzIGhpZ2gsIHllcyBJIGFncmVlIHRoYXQgdGhlIHByb2Nlc3Npbmcgb2YgdGhlIHVw ZGF0ZSBpcyBhIGJpdCBjaGFuZ2VkIGFuZCBteSBiZWFjb24gd291bGQgYmUgc2VudCBtYXkgYmUg ZmFzdGVyLiBQYWNraW5nIGlzIGludHJvZHVjaW5nIHNsaWdodCBkZWxheSBidXQgSSBkb24ndCB0 aGluayBkZWxheSBpbnRyb2R1Y2VkIGJ5IHBhY2tpbmcgaXMgYSBtYWpvciBjb21wb25lbnQgZXhw ZWN0IGlmIGFuIGltcGxlbWVudGF0aW9uIGdldCBzdHVja3MgaW4gcGFja2luZyAoaXQgbWF5IGhh cHBlbiBidXQgSSBuZXZlciBzZWVuIGl0KS4gSU1ITywgSSBkb24ndCB0aGluayB0aGlzIGlzIGEg Y3JpdGljYWwgcG9pbnQgYnV0IEknbSBvcGVuIHRvIG90aGVyIG9waW5pb25zLg0KDQpOb3cgZm9y IEJNUCwgd2UgYXJlIG5vdCB0YXJnZXRpbmcgdG8gbW9uaXRvciBvdXIgYmVhY29ucyBvbiBhbGwg UEVzLCBqdXN0IGEgc3Vic2V0IG9mIHJlcHJlc2VudGF0aXZlLg0KTW9yZW92ZXIgaXQncyBub3Qg b25seSBhIHF1ZXN0aW9uIGFib3V0IG51bWJlciBvZiBzZXNzaW9ucywgaXQncyBhIHF1ZXN0aW9u IG9mIG9yZGVyaW5nIHRoZSBpbmZvcm1hdGlvbiByZXRyaWV2ZWQuIElmIHlvdSBjb25zaWRlciB1 c2luZyBCTVAgLCB0aGUgdG9vbCB3aWxsIHBlZXIgd2l0aCBzZWxlY3RlZCBQRXMsIGJ1dCBhbHNv ICJ0cmFuc2l0IEJHUCBTcGVha2VycyIgKEFTQlJzLCBSUnMgLi4uKS4gV2hlbiB0aGUgdG9vbCB3 aWxsIHJlY2VpdmUgdGhlIHRpbWVzdGFtcCBpbmZvcm1hdGlvbiAoaWYgaW1wbGVtZW50YXRpb24g b2YgQk1QIHN1cHBvcnRzIHRpbWVzdGFtcCksIGl0IHJlcXVpcmVzIHRvIHNvcnQgYW5kIHJlb3Jn YW5pemUgdGhlIHJlY2VpdmVkIGluZm9ybWF0aW9uIGJhc2VkIG9uIHRoZSBrbm93bGVkZ2Ugb2Yg dGhlIHRvcG9sb2d5IDogeW91IGNhbm5vdCBqdXN0IHNvcnQgYnkgdGltZXN0YW1wLCB5b3UgaGF2 ZSB0byBmaW5kIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIEJHUCBTcGVha2VycyAoaW5mb3JtYXRpb24g ZnJvbSBCTVAgYW5kIHRvcG9sb2d5KSBhbmQgY29tYmluZSB0aGVtIHRvIHJlY3JlYXRlIG91ciB0 aW1lc3RhbXAgdmVjdG9yLiBCR1AgdHJhbnNwb3J0IHBlcm1pdHMgdG8gY3JlYXRlIGF1dG9tYXRp Y2FsbHkgdGhpcyB0aW1lc3RhbXAgdmVjdG9yIHdpdGhvdXQgaGF2aW5nIHRvIGltcGxlbWVudCBh IGNvbXBsZXggbWFjaGluZXJ5IGluIHRoZSB0b29sLiBCdXQgQk1QIGNhbiBiZSB1c2VkIGF0IHRo ZSBzZWxlY3RlZCBQRSB0byB0aGUgdG9vbCB0byByZXRyaWV2ZSB0aW1lc3RhbXAgdmVjdG9ycy4N Cg0KSG9wZSBpdCBjbGFyaWZpZXMuDQoNClN0ZXBoYW5lDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IEpvbiBNaXRjaGVsbCBbbWFpbHRvOmpybWl0Y2hlQHB1Y2submV0aGVy Lm5ldF0gDQpTZW50OiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDE3OjI4DQpUbzogTElUS09XU0tJ IFN0ZXBoYW5lIFNDRS9JQk5GDQpDYzogUm9iZXJ0IFJhc3p1azsgSmVmZnJleSBIYWFzOyBpZHIg d2cNClN1YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1saXRrb3dza2ktaWRyLWJncC10aW1lc3RhbXAN Cg0KT24gMjIvMDcvMTQgMTk6MTkgKzAwMDAsIHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29t IHdyb3RlOg0KPiBbUmVuYW1lZCB0b3BpY10NCj4gDQo+IEhpIFJvYmVydCwNCj4gDQo+ID4gWW91 ciByZXN1bHRzIG1heSBhY3R1YWxseSBpbiB0aGUgYWJvdmUgY2FzZSBjYXN1ZSBtb3JlIHByb2Js ZW1zIHRoZW4gZ2FpbnMgdW5mb3J0dW5hdGVseS4NCj4gDQo+IEkgZG9u4oCZdCByZWFsbHkgdW5k ZXJzdGFuZCB3aHkg4oCmIGV2ZW4gaWYgUlIgYXJlIG5vdCBpbiB0aGUgZGF0YXBsYW5lICh3aGlj aCB3b3VsZCBiZSB0aGUgY2FzZSBmb3IgVlBOIGVudmlyb25tZW50KSwgUlIgYmVoYXZpb3IgaXMg cmVhbGx5IGltcG9ydGFudCB0byB0cmFjay4NCj4gDQo+IENvbnNpZGVyIGEgTVBMUyBWUE4gc2Nl bmFyaW8sIHNvbWUgUEVzIGNvbm5lY3RlZCB0byBSUiBjbHVzdGVycyBhbmQgbWVzaGluZyBiZXR3 ZWVuIGNsdXN0ZXJzLg0KPiBDb25zaWRlciB0aGF0IG9uZSBvZiB0aGUgUlIgaXMgZ2V0dGluZyBz dHVjayBiZWNhdXNlIG9mIFJvdXRlLXJlZnJlc2ggcHJvY2Vzc2luZyBvZiAyTSBvZiByb3V0ZXMg b3IganVzdCBidXN5IHRvIGRvIHNvbWV0aGluZyBlbHNlIGR1ZSB0byBiYWQgc2NoZWR1bGluZyBp biB0aGUgaW1wbGVtZW50aW9uIOKApiBpZiBhIFBFIGxvc2UgYSBjdXN0b21lciBjb25uZWN0aW9u LCBhbmQgY3VzdG9tZXIgaGFzIGEgYmFja3VwIGNvbm5lY3Rpb24gYW5kIGJhY2t1cCBQRSBoYXMg dG8gc2VuZCBhIG5ldyBCR1AgdXBkYXRlIHRvIHByb3BhZ2F0ZSB0aGUgbmV3IHBhdGguIFRoZSB0 aW1lIGZvciBSUiB0byBwcm9wYWdhdGUgdGhlIEJHUCB1cGRhdGUgaXMgY3JpdGljYWwgdG8gdHJh Y2sgYmVjYXVzZSB0aGlzIHdpbGwgY29uZGl0aW9uIGNvbnZlcmdlbmNlIHRpbWUgZm9yIHRoZSBj dXN0b21lciDigKYNCj4gDQo+IFRob3VnaHRzID8NCg0KU3RlcGhhbmUgLQ0KDQpJJ20gc3VwcG9y dGl2ZSBvZiB5b3VyIGdvYWwsIGhvd2V2ZXIgYWZ0ZXIgdGhlIHByZXNlbnRhdGlvbiBJJ20gc3Rp bGwgYSBiaXQgdW5jbGVhciBvbiB0aGUgbmVlZCBmb3IgdGhlIEJHUCBleHRlbnNpb24gdG8gcHJv cG9nYXRlIHRoZSB0aW1lc3RhbXAgaW5mb3JtYXRpb24uICBBcyB3YXMgYnJvdWdodCB1cCBieSBT YWlrYXQgdG9kYXkgaW4gdGhlIFdHIG1lZXRpbmcsIGlmIHVwZGF0ZSBwYWNraW5nIGlzIGRpZmZl cmVudCBmb3IgdGhpcyBwcmVmaXggZHVlIHRvIHRoZSB0aW1lc3RhbXAgYXR0cmlidXRlIHRoZW4g aXQgbG9zZXMgc29tZSBvZiBpdCdzIHZhbHVlIGZvciBwcm92aWRpbmcgYW4gYWNjdXJhdGUgdmll dyBvZiB5b3VyIGVuZCB0byBlbmQgQkdQIHByb3BvZ2F0aW9uIHRpbWUuICBTb21lb25lIHN1Z2dl c3RlZCBCTVAsIGl0IGFwcGVhcnMgaXQgYWxyZWFkeSBzdXBwb3J0cyB0aGlzIG9wdGlvbiBpbiBw YXJhZ3JhcGggMyBvZiBTZWN0aW9uIDUgb2YgdGhhdCBkcmFmdC4gIFRoZSBqdXN0aWZpY2F0aW9u IGdpdmVuIHRoYXQgaW5zdHJ1bWVudGluZyBzZXNzaW9ucyAoQk1QL0JHUC9vciBvdGhlciBleHBv cnQgbWVjaGFuaXNtIGZvciB0aGUgZGF0YSkgdG8gYWxsIHJvdXRlcnMgdmVyc3VzIGdldHRpbmcg dGhlIGluZm9ybWF0aW9uIGZyb20gZWdyZXNzIFBFIG9ubHkgZG9lcyBub3Qgc2VlbSB0byBiZSBh IGxhcmdlIGNvbmNlcm4gaWYgbW9uaXRvcmluZyB0aGlzIHJvdXRlIHByb3BvZ2F0aW9uIGlzIG9m IGltcG9ydGFuY2UgdG8gdGhlIG9wZXJhdG9yLiAgQWZ0ZXIgYWxsIHByZXN1bWFibHkgdGhlcmUg YXJlIGEgbXVjaCBsYXJnZXIgbnVtYmVyIG9mIFBFJ3MgaW4gbW9zdCBuZXR3b3JrcyB0aGFuIFJS J3Mgc28gaW5zdHJ1bWVudGluZyBtb25pdG9yaW5nIGFsbCBkZXZpY2VzIGlzIG5vdCBtdWNoIG1v cmUgd29yayB0aGFuIGp1c3QgdGhlIFBFJ3MuICBTcGVjaWZ5aW5nIG9yIGlkZW50aWZ5aW5nIHdo aWNoIHByZWZpeGVzIGFyZSBtb25pdG9yZWQgKHRoZSB0aW1lc3RhbXAgaXMgY29sbGVjdGVkIGFu ZCBleHBvcnRlZCBmb3IpIHNlZW1zIGFsc28gbGlrZSBzb21ldGhpbmcgdGhhdCBjYW4gYmUgaGFu ZGxlZCBieSB0aGUgbG9jYWwgaW1wbGVtZW50YXRpb24gYmFzZWQgb24gYSBjb21tdW5pdHkgb3Ig b3RoZXIgYXR0cmlidXRlcy4NCg0KSm9uDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Tue Jul 22 15:01:43 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A824C1B2CD6 for ; Tue, 22 Jul 2014 15:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tW7pNwRsogW for ; Tue, 22 Jul 2014 15:01:37 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C558C1B2CD2 for ; Tue, 22 Jul 2014 15:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1662; q=dns/txt; s=iport; t=1406066496; x=1407276096; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=tFuSqh4UKqeYRmQ84Bmw+wPjdePVKW9J9hK2bmtt6rQ=; b=L4tiutKuFHqToHpAaiwvWB7GMgPb6jiZPECKa795VLqNPIXPTFtrMJ02 BX7alIKtD88Zou/u9DS+IE6eDEkhrJYlqAu6ZYkUuyMDo0/tm6eKNrMX9 /khmmsQlB/VgOUjf50+cKTILkgqvCv19sqCJCpOcCAhDRAwZdsq+nSQzn s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAHHezlOtJA2L/2dsb2JhbABZgw5SVwTHGQqHRQGBEhZ2hAMBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCAyILg2/bxePGjgGgyiBGAWcdJJmg0ZsgUU X-IronPort-AV: E=Sophos;i="5.01,712,1400025600"; d="scan'208";a="63154176" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP; 22 Jul 2014 22:01:35 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6MM1aZG000821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 22:01:36 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.244]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 17:01:35 -0500 From: "Bertrand Duvivier (bduvivie)" To: "Henderickx, Wim (Wim)" , John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 Thread-Index: AQHPpe5IrU+t10AR1UOXEZ/FOwtt75uspQdg Date: Tue, 22 Jul 2014 22:01:34 +0000 Message-ID: <5F1FD493E541C642ABBC18EDC327C82F1F67909B@xmb-aln-x11.cisco.com> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/7O9d8iu2Wjui6B4tp_YKlKaYKbo Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:01:40 -0000 Support Best Regards Bertrand Duvivier NOSTG Product Manager -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: mardi 22 juillet 2014 22:48 To: John Scudder; idr@ietf. org Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-ne= xt-hop-06 Support On 22/07/14 15:43, "John Scudder" wrote: >Folks, > >The authors have requested IDR adopt >draft-vandevelde-idr-remote-next-hop-06 as a working group document. > >http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > >Please send any comments to the list by August 8. > >In addition to commenting on adoption of the work, you may want to=20 >comment on whether the draft is mature enough for us to consider early=20 >allocation of the path attribute code point. As a reminder, RFC 7120=20 >requires that for early allocation, "the specifications of these code=20 >points must be stable". (Section 2.c.) The chairs and ADs also have to=20 >"judge that there is sufficient interest in the community for early >(pre-RFC) implementation and deployment". (Section 2.d.) > >It's fine to be in favor of WG adoption but opposed to early allocation=20 >at this time, or in favor of both, or against both. Being against=20 >adoption but in favor of allocation would be a bit weird. :-) > >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 From nobody Tue Jul 22 15:09:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6921A02EF for ; Tue, 22 Jul 2014 15:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8E0TQYrSShZ for ; Tue, 22 Jul 2014 15:09:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4E31A00CD for ; Tue, 22 Jul 2014 15:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1795; q=dns/txt; s=iport; t=1406066958; x=1407276558; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FTD89H5d4wYnStXFd2gcb9Npmo8d2EyZcvD2q0W4F6M=; b=hW7h7hvWB+3XrSwEkNzbNyovP1RcFLWuP0+BU06g2MCBdt9H/BTkHqml SVY1rmpKZ3qzvoXxn32p1j5/L9cW5tvPVl38JGAZHX8J+bh2LzCyJ9oaZ 4Qrkebg5W3GUZzouchraMv0gB/xQ3O2vWEFvY6NNLOpWpZ74JiN4osdVb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFALHfzlOtJV2c/2dsb2JhbABZgw5SVwTHGQqHRQGBEhZ2hAMBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCAyILg2/bxePGjgGgyiBGAWcdJJmg0ZsgUU X-IronPort-AV: E=Sophos;i="5.01,712,1400025600"; d="scan'208";a="342040862" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jul 2014 22:09:17 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6MM9H6Q016982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 22:09:17 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.244]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 17:09:17 -0500 From: "Bertrand Duvivier (bduvivie)" To: "Henderickx, Wim (Wim)" , John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 Thread-Index: AQHPpe5IrU+t10AR1UOXEZ/FOwtt75uspQdggAAB06A= Date: Tue, 22 Jul 2014 22:09:16 +0000 Message-ID: <5F1FD493E541C642ABBC18EDC327C82F1F679111@xmb-aln-x11.cisco.com> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> <5F1FD493E541C642ABBC18EDC327C82F1F67909B@xmb-aln-x11.cisco.com> In-Reply-To: <5F1FD493E541C642ABBC18EDC327C82F1F67909B@xmb-aln-x11.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HSVR7BgFIkHkuJKXetcMyKAq6BY Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:09:19 -0000 Support for adoption Best Regards Bertrand Duvivier NOSTG Product Manager -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: mardi 22 juillet 2014 22:48 To: John Scudder; idr@ietf. org Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-ne= xt-hop-06 Support On 22/07/14 15:43, "John Scudder" wrote: >Folks, > >The authors have requested IDR adopt >draft-vandevelde-idr-remote-next-hop-06 as a working group document. > >http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > >Please send any comments to the list by August 8. > >In addition to commenting on adoption of the work, you may want to=20 >comment on whether the draft is mature enough for us to consider early=20 >allocation of the path attribute code point. As a reminder, RFC 7120=20 >requires that for early allocation, "the specifications of these code=20 >points must be stable". (Section 2.c.) The chairs and ADs also have to=20 >"judge that there is sufficient interest in the community for early >(pre-RFC) implementation and deployment". (Section 2.d.) > >It's fine to be in favor of WG adoption but opposed to early allocation=20 >at this time, or in favor of both, or against both. Being against=20 >adoption but in favor of allocation would be a bit weird. :-) > >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 Jul 22 15:16:53 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565301A02E5 for ; Tue, 22 Jul 2014 15:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTNN5LqNLNSf for ; Tue, 22 Jul 2014 15:16:47 -0700 (PDT) Received: from COL004-OMC4S2.hotmail.com (col004-omc4s2.hotmail.com [65.55.34.204]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E24C1A0414 for ; Tue, 22 Jul 2014 15:16:47 -0700 (PDT) Received: from COL127-W28 ([65.55.34.199]) by COL004-OMC4S2.hotmail.com with Microsoft SMTPSVC(7.5.7601.22701); Tue, 22 Jul 2014 15:16:46 -0700 X-TMN: [WqXCG3ThpncHRuY1MYF6MNztKVsJKl3F] X-Originating-Email: [balaji_pv@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_5bf7adf3-8161-424a-aee7-878c5ef6a43b_" From: Balaji Pitta venkatachalapathy To: "Bertrand Duvivier (bduvivie)" , "Henderickx, Wim (Wim)" , John Scudder , "idr@ietf. org" Date: Tue, 22 Jul 2014 15:16:46 -0700 Importance: Normal In-Reply-To: <5F1FD493E541C642ABBC18EDC327C82F1F679111@xmb-aln-x11.cisco.com> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net>, , <5F1FD493E541C642ABBC18EDC327C82F1F67909B@xmb-aln-x11.cisco.com>, <5F1FD493E541C642ABBC18EDC327C82F1F679111@xmb-aln-x11.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jul 2014 22:16:46.0742 (UTC) FILETIME=[A055D360:01CFA5FA] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Vml7StCdfGQ9-og1-_W6e8jIors Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:16:49 -0000 --_5bf7adf3-8161-424a-aee7-878c5ef6a43b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support for adoption. Balaji > From: bduvivie@cisco.com > To: wim.henderickx@alcatel-lucent.com=3B jgs@juniper.net=3B idr@ietf.org > Date: Tue=2C 22 Jul 2014 22:09:16 +0000 > Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-= next-hop-06 >=20 > Support for adoption >=20 > Best Regards Bertrand Duvivier > NOSTG Product Manager > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Henderickx=2C Wim (W= im) > Sent: mardi 22 juillet 2014 22:48 > To: John Scudder=3B idr@ietf. org > Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-= next-hop-06 >=20 > Support >=20 > On 22/07/14 15:43=2C "John Scudder" wrote: >=20 > >Folks=2C > > > >The authors have requested IDR adopt > >draft-vandevelde-idr-remote-next-hop-06 as a working group document. > > > >http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > > > >Please send any comments to the list by August 8. > > > >In addition to commenting on adoption of the work=2C you may want to=20 > >comment on whether the draft is mature enough for us to consider early=20 > >allocation of the path attribute code point. As a reminder=2C RFC 7120=20 > >requires that for early allocation=2C "the specifications of these code= =20 > >points must be stable". (Section 2.c.) The chairs and ADs also have to=20 > >"judge that there is sufficient interest in the community for early > >(pre-RFC) implementation and deployment". (Section 2.d.) > > > >It's fine to be in favor of WG adoption but opposed to early allocation= =20 > >at this time=2C or in favor of both=2C or against both. Being against=20 > >adoption but in favor of allocation would be a bit weird. :-) > > > >Thanks=2C > > > >--John > > > >_______________________________________________ > >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 > _______________________________________________ > 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 = --_5bf7adf3-8161-424a-aee7-878c5ef6a43b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Support for adoption.

Bal= aji

>=3B From: bduvivie@cisco.com
>=3B To: wim.henderick= x@alcatel-lucent.com=3B jgs@juniper.net=3B idr@ietf.org
>=3B Date: Tue= =2C 22 Jul 2014 22:09:16 +0000
>=3B Subject: Re: [Idr] WG adoption req= uested for draft-vandevelde-idr-remote-next-hop-06
>=3B
>=3B Sup= port for adoption
>=3B
>=3B Best Regards Bertrand Duvivier
&g= t=3B NOSTG Product Manager
>=3B -----Original Message-----
>=3B F= rom: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Henderickx=2C Wim (Wim)=
>=3B Sent: mardi 22 juillet 2014 22:48
>=3B To: John Scudder=3B = idr@ietf. org
>=3B Subject: Re: [Idr] WG adoption requested for draft-= vandevelde-idr-remote-next-hop-06
>=3B
>=3B Support
>=3B >=3B On 22/07/14 15:43=2C "John Scudder" <=3Bjgs@juniper.net>=3B wr= ote:
>=3B
>=3B >=3BFolks=2C
>=3B >=3B
>=3B >=3BT= he authors have requested IDR adopt
>=3B >=3Bdraft-vandevelde-idr-re= mote-next-hop-06 as a working group document.
>=3B >=3B
>=3B &g= t=3Bhttp://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/>=3B >=3B
>=3B >=3BPlease send any comments to the list by Aug= ust 8.
>=3B >=3B
>=3B >=3BIn addition to commenting on adopti= on of the work=2C you may want to
>=3B >=3Bcomment on whether the d= raft is mature enough for us to consider early
>=3B >=3Ballocation = of the path attribute code point. As a reminder=2C RFC 7120
>=3B >= =3Brequires that for early allocation=2C "the specifications of these code =
>=3B >=3Bpoints must be stable". (Section 2.c.) The chairs and ADs = also have to
>=3B >=3B"judge that there is sufficient interest in t= he community for early
>=3B >=3B(pre-RFC) implementation and deploym= ent". (Section 2.d.)
>=3B >=3B
>=3B >=3BIt's fine to be in fa= vor of WG adoption but opposed to early allocation
>=3B >=3Bat this= time=2C or in favor of both=2C or against both. Being against
>=3B &= gt=3Badoption but in favor of allocation would be a bit weird. :-)
>= =3B >=3B
>=3B >=3BThanks=2C
>=3B >=3B
>=3B >=3B--Joh= n
>=3B >=3B
>=3B >=3B________________________________________= _______
>=3B >=3BIdr mailing list
>=3B >=3BIdr@ietf.org
&g= t=3B >=3Bhttps://www.ietf.org/mailman/listinfo/idr
>=3B
>=3B _= ______________________________________________
>=3B Idr mailing list>=3B Idr@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/idr>=3B
>=3B _______________________________________________
>= =3B Idr mailing list
>=3B Idr@ietf.org
>=3B https://www.ietf.org/= mailman/listinfo/idr
>=3B
>=3B _________________________________= ______________
>=3B Idr mailing list
>=3B Idr@ietf.org
>=3B = https://www.ietf.org/mailman/listinfo/idr
= --_5bf7adf3-8161-424a-aee7-878c5ef6a43b_-- From nobody Tue Jul 22 15:22:34 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD771A0648 for ; Tue, 22 Jul 2014 15:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF1VMObD_Ph6 for ; Tue, 22 Jul 2014 15:22:31 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (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 BCEC71A035E for ; Tue, 22 Jul 2014 15:22:30 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.8/8.14.5) with ESMTP id s6MMMkbu005284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Jul 2014 18:22:46 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.8/8.14.8/Submit) id s6MMMk0O005283; Tue, 22 Jul 2014 18:22:46 -0400 Date: Tue, 22 Jul 2014 18:22:46 -0400 From: Jon Mitchell To: stephane.litkowski@orange.com Message-ID: <20140722222246.GB19654@puck.nether.net> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722212735.GA11770@puck.nether.net> <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.7 (puck.nether.net [127.0.0.1]); Tue, 22 Jul 2014 18:22:47 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/1xxVeEtn8CpYA98jD3Nny7XzpqU Cc: Jeffrey Haas , idr wg , Robert Raszuk Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:22:32 -0000 On 22/07/14 22:00 +0000, stephane.litkowski@orange.com wrote: > Hi Jon, > > Thanks for your comment. > Regarding packing, depending of the address family you are trying to monitor, current packing may be low or high. In case where existing packing is low, it does not change anything. In case packing is high, yes I agree that the processing of the update is a bit changed and my beacon would be sent may be faster. Packing is introducing slight delay but I don't think delay introduced by packing is a major component expect if an implementation get stucks in packing (it may happen but I never seen it). IMHO, I don't think this is a critical point but I'm open to other opinions. > > Now for BMP, we are not targeting to monitor our beacons on all PEs, just a subset of representative. > Moreover it's not only a question about number of sessions, it's a question of ordering the information retrieved. If you consider using BMP , the tool will peer with selected PEs, but also "transit BGP Speakers" (ASBRs, RRs ...). When the tool will receive the timestamp information (if implementation of BMP supports timestamp), it requires to sort and reorganize the received information based on the knowledge of the topology : you cannot just sort by timestamp, you have to find relationship between BGP Speakers (information from BMP and topology) and combine them to recreate our timestamp vector. BGP transport permits to create automatically this timestamp vector without having to implement a complex machinery in the tool. But BMP can be used at the selected PE to the tool to retrieve timestamp vectors. > Stephane - yes, I think this second point is the real object of the draft (correct me if I'm wrong). Offline correlation engines are complicated to implement and/or expensive, although commercially available. Getting the timestamp data seems not to be the real issue here at all (via BMP or other mechanisms a local implementation can provide). Maybe this point should be more clear in the intro and text. Jon From nobody Tue Jul 22 18:31:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3142B1A0195 for ; Tue, 22 Jul 2014 18:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.608 X-Spam-Level: X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJSnJakbnWJm for ; Tue, 22 Jul 2014 18:31:22 -0700 (PDT) Received: from ms.fnsc.co.jp (fnsc.co.jp [114.179.9.192]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C1D1A0123 for ; Tue, 22 Jul 2014 18:31:21 -0700 (PDT) Received: from eagle.inf.fnsc.co.jp (unknown [158.202.238.138]) by ms.fnsc.co.jp with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 3e58_0e0e_c664e36e_cd6b_42fc_9599_af42f92e4c80; Wed, 23 Jul 2014 10:32:26 +0900 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=utf-8 From: Hideaki HAYASHI In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Date: Wed, 23 Jul 2014 10:31:08 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/pK3ExX-kPWJjPyysC_nhqC5ZIBM Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 01:31:26 -0000 support. -- hideaki 2014/07/23 4:43=E3=80=81John Scudder =E3=81=AE=E3=83=A1=E3= =83=BC=E3=83=AB=EF=BC=9A > Folks, >=20 > The authors have requested IDR adopt = draft-vandevelde-idr-remote-next-hop-06 as a working group document.=20 >=20 > http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ >=20 > Please send any comments to the list by August 8.=20 >=20 > In addition to commenting on adoption of the work, you may want to = comment on whether the draft is mature enough for us to consider early = allocation of the path attribute code point. As a reminder, RFC 7120 = requires that for early allocation, "the specifications of these code = points must be stable". (Section 2.c.) The chairs and ADs also have to = "judge that there is sufficient interest in the community for early = (pre-RFC) implementation and deployment". (Section 2.d.) >=20 > It's fine to be in favor of WG adoption but opposed to early = allocation at this time, or in favor of both, or against both. Being = against adoption but in favor of allocation would be a bit weird. :-)=20 >=20 > Thanks, >=20 > --John >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jul 22 18:33:55 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6808A1A0350 for ; Tue, 22 Jul 2014 18:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBiELoQY99vm for ; Tue, 22 Jul 2014 18:33:52 -0700 (PDT) Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623211A02EC for ; Tue, 22 Jul 2014 18:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1176; q=dns/txt; s=iport; t=1406079232; x=1407288832; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UtU3WdY69UKXOYxtKCLQiMQ6U3/d0yiWtY8ZDm5NRug=; b=KxuFFjLdQSqPv4AM84jKW76XByrKKFzBnXbq0AYW6mRl9dnAqV2tKbz2 zBBFpjwSkPEd8o2QOuJganaYkz+6LoK+QgzkBh/qYO1gRdXn8ZDfa0EMU Gt03+KT7qz9q9yiF4o4Ovj1SVmN6OjkqOGESR+Lh+w68kahBvdShcAAC9 8=; X-IronPort-AV: E=Sophos;i="5.01,714,1400025600"; d="scan'208";a="8567872" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP; 23 Jul 2014 01:33:49 +0000 Received: from [10.141.41.84] (dhcp-10-141-41-84.cisco.com [10.141.41.84]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6N1XlgI001387; Wed, 23 Jul 2014 01:33:48 GMT Message-ID: <53CF10FC.90805@cisco.com> Date: Wed, 23 Jul 2014 10:33:48 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: jgs@juniper.net, idr@ietf.org References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/MqJChEXWdm5luOLl-YAg_kGR1No Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 01:33:53 -0000 Support as adoption (2014/07/23 4:43), John Scudder wrote: > Folks, > > The authors have requested IDR adopt draft-vandevelde-idr-remote-next-hop-06 as a working group document. > > http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > > Please send any comments to the list by August 8. > > In addition to commenting on adoption of the work, you may want to comment on whether the draft is mature enough for us to consider early allocation of the path attribute code point. As a reminder, RFC 7120 requires that for early allocation, "the specifications of these code points must be stable". (Section 2.c.) The chairs and ADs also have to "judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment". (Section 2.d.) > > It's fine to be in favor of WG adoption but opposed to early allocation at this time, or in favor of both, or against both. Being against adoption but in favor of allocation would be a bit weird. :-) > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Wed Jul 23 00:43:08 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3AD1A0110; Wed, 23 Jul 2014 00:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap4DdAp8rbor; Wed, 23 Jul 2014 00:43:03 -0700 (PDT) Received: from out-13.mail.exa.net.uk (out-13.mail.exa.net.uk [82.219.4.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254E71A00C9; Wed, 23 Jul 2014 00:43:02 -0700 (PDT) Received: from smtp-1.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-13.mail.exa.net.uk (ExaSMTPD) with ESMTP id EE93A1C0041; Wed, 23 Jul 2014 08:42:59 +0100 (BST) Received: from pc6.home (ABayonne-652-1-615-12.w82-125.abo.wanadoo.fr [82.125.28.12]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 861C722115F; Wed, 23 Jul 2014 08:42:58 +0100 (BST) Content-Type: multipart/signed; boundary="Apple-Mail=_3F21F2BC-F47F-489A-A6E5-765480E6B515"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Mangin In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Date: Wed, 23 Jul 2014 08:42:53 +0100 Cc: "idr@ietf. org" X-Mao-Original-Outgoing-Id: 427794173.33216-4ea578af0be0c944a5e34efd79d26023 Message-Id: <9C0D1E75-FD59-4CC5-B059-A87D8C496D83@exa-networks.co.uk> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ql3rqbEnDMcv_JK_n1sPqWmzq7o Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 07:43:07 -0000 --Apple-Mail=_3F21F2BC-F47F-489A-A6E5-765480E6B515 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii support. Thomas On 22 Jul 2014, at 20:43, John Scudder wrote: > Folks, >=20 > The authors have requested IDR adopt = draft-vandevelde-idr-remote-next-hop-06 as a working group document.=20 >=20 > http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ >=20 > Please send any comments to the list by August 8.=20 >=20 > In addition to commenting on adoption of the work, you may want to = comment on whether the draft is mature enough for us to consider early = allocation of the path attribute code point. As a reminder, RFC 7120 = requires that for early allocation, "the specifications of these code = points must be stable". (Section 2.c.) The chairs and ADs also have to = "judge that there is sufficient interest in the community for early = (pre-RFC) implementation and deployment". (Section 2.d.) >=20 > It's fine to be in favor of WG adoption but opposed to early = allocation at this time, or in favor of both, or against both. Being = against adoption but in favor of allocation would be a bit weird. :-)=20 >=20 > Thanks, >=20 > --John >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 --Apple-Mail=_3F21F2BC-F47F-489A-A6E5-765480E6B515 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPPZ30ACgkQA/52wvuLgaG4/wCfUcnVU059dnbG96eU/7nGRzkb Cc0AniKwDQ4bZ0AYT8Pj1cXF7LBSVxeV =oMeA -----END PGP SIGNATURE----- --Apple-Mail=_3F21F2BC-F47F-489A-A6E5-765480E6B515-- From nobody Wed Jul 23 00:56:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AD61A0142; Wed, 23 Jul 2014 00:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Y2lPjAdnwXy; Wed, 23 Jul 2014 00:56:28 -0700 (PDT) Received: from out-13.mail.exa.net.uk (out-13.mail.exa.net.uk [82.219.4.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3617E1A01F1; Wed, 23 Jul 2014 00:56:28 -0700 (PDT) Received: from smtp-1.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-13.mail.exa.net.uk (ExaSMTPD) with ESMTP id BE9AA1C006B; Wed, 23 Jul 2014 08:56:26 +0100 (BST) Received: from pc6.home (ABayonne-652-1-615-12.w82-125.abo.wanadoo.fr [82.125.28.12]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id D6D4D22115E; Wed, 23 Jul 2014 08:56:25 +0100 (BST) Content-Type: multipart/signed; boundary="Apple-Mail=_5FF6720D-591C-475A-9F64-1331952ADCDA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Mangin In-Reply-To: <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Wed, 23 Jul 2014 08:56:24 +0100 X-Mao-Original-Outgoing-Id: 427794983.662129-ff1a44c5df615a463a3b79f63d1b1332 Message-Id: <46AF758B-7D81-476F-9F2F-4963262FD181@exa-networks.co.uk> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722212735.GA11770@puck.nether.net> <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rmfd5XElzh3WF-3d3zvs_cDUBrU Cc: Jeffrey Haas , idr wg , Robert Raszuk Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 07:56:32 -0000 --Apple-Mail=_5FF6720D-591C-475A-9F64-1331952ADCDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Bonjour Stephane, I am not at the meeting, so could only work from your draft ... Your = proposal seems sensitive and useful to me and I believe it would be a = useful addition to the protocol. IMHO, adding some extra message processing would take some CPU time, = taking this CPU from the propagation of UPDATE, so the format should be = as simple as possible and require as little parsing as possible. It is = not clear to me that a speaker can ignore the validity of the data = before appending its TS. Forcing the TS to be validated at every hop = would seems to be self-defeating. The format is as well quite complex to = parse and I would be in favour of a much more simple one with less flags = and/or options. Regarding format proposed : Type 1 and Type 2 and later in peer : 16 bits ASN can be coded using 32 = bits - why make a distinction - we do not need to know if the speaker = considered itself or was configured as a ASN4 speaker. Why not include = ASN and IPs ( prepended with AFI/SAFI so it is possible to include other = Family later ) Why not always include all possible information ASN, IP, IPv6 ( knowing = that only some may be present ). At debugging time, it is not clear what = would be most useful therefore having both the AS and IP should be = better. Receiving timestamp from January 1900, I am under the impression that = most system have built-in Epoch function from 1970 and with 64 bits = would not suffer from any issue with 2038, I wonder why you picked 1990 = (which I realise is another option). Regarding the Peer Flags,I would rather see all the information being = included (ASN and IP). Debugging information should try to provide as = much information as possible. 4.2, I assume this apply for prefixes which match the selection in 4.1 4.4, I would rather see TS being transmitted by default on IBGP sessions = and explicit on EBGP ( easier to configure ) 4.5.2 does not say how the new TS should be set. It is not clear if the = summary option must be implemented or can be left out ( IMHO, this = should be left out the draft and be left to be done by the external tool = displaying the information ) 4.6 does not indicate what must be done if two TS entries are in the = both synchronised but inconsistent, like a time sequence of 1, 3, 2, 5 = where a router found a way to go back in time :-) .... Should it be = ignored or should this TS sequence be seen as invalid and discarded ( = assuming each router is performing some validation of the attribute ). Only skimmed over 5+=20 Thomas On 22 Jul 2014, at 23:00, = wrote: > Hi Jon, >=20 > Thanks for your comment. > Regarding packing, depending of the address family you are trying to = monitor, current packing may be low or high. In case where existing = packing is low, it does not change anything. In case packing is high, = yes I agree that the processing of the update is a bit changed and my = beacon would be sent may be faster. Packing is introducing slight delay = but I don't think delay introduced by packing is a major component = expect if an implementation get stucks in packing (it may happen but I = never seen it). IMHO, I don't think this is a critical point but I'm = open to other opinions. >=20 > Now for BMP, we are not targeting to monitor our beacons on all PEs, = just a subset of representative. > Moreover it's not only a question about number of sessions, it's a = question of ordering the information retrieved. If you consider using = BMP , the tool will peer with selected PEs, but also "transit BGP = Speakers" (ASBRs, RRs ...). When the tool will receive the timestamp = information (if implementation of BMP supports timestamp), it requires = to sort and reorganize the received information based on the knowledge = of the topology : you cannot just sort by timestamp, you have to find = relationship between BGP Speakers (information from BMP and topology) = and combine them to recreate our timestamp vector. BGP transport permits = to create automatically this timestamp vector without having to = implement a complex machinery in the tool. But BMP can be used at the = selected PE to the tool to retrieve timestamp vectors. >=20 > Hope it clarifies. >=20 > Stephane >=20 >=20 > -----Original Message----- > From: Jon Mitchell [mailto:jrmitche@puck.nether.net]=20 > Sent: Tuesday, July 22, 2014 17:28 > To: LITKOWSKI Stephane SCE/IBNF > Cc: Robert Raszuk; Jeffrey Haas; idr wg > Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp >=20 > On 22/07/14 19:19 +0000, stephane.litkowski@orange.com wrote: >> [Renamed topic] >>=20 >> Hi Robert, >>=20 >>> Your results may actually in the above case casue more problems then = gains unfortunately. >>=20 >> I don=92t really understand why =85 even if RR are not in the = dataplane (which would be the case for VPN environment), RR behavior is = really important to track. >>=20 >> Consider a MPLS VPN scenario, some PEs connected to RR clusters and = meshing between clusters. >> Consider that one of the RR is getting stuck because of Route-refresh = processing of 2M of routes or just busy to do something else due to bad = scheduling in the implemention =85 if a PE lose a customer connection, = and customer has a backup connection and backup PE has to send a new BGP = update to propagate the new path. The time for RR to propagate the BGP = update is critical to track because this will condition convergence time = for the customer =85 >>=20 >> Thoughts ? >=20 > Stephane - >=20 > I'm supportive of your goal, however after the presentation I'm still = a bit unclear on the need for the BGP extension to propogate the = timestamp information. As was brought up by Saikat today in the WG = meeting, if update packing is different for this prefix due to the = timestamp attribute then it loses some of it's value for providing an = accurate view of your end to end BGP propogation time. Someone = suggested BMP, it appears it already supports this option in paragraph 3 = of Section 5 of that draft. The justification given that instrumenting = sessions (BMP/BGP/or other export mechanism for the data) to all routers = versus getting the information from egress PE only does not seem to be a = large concern if monitoring this route propogation is of importance to = the operator. After all presumably there are a much larger number of = PE's in most networks than RR's so instrumenting monitoring all devices = is not much more work than just the PE's. Specifying or identifying = which prefixes are monitored (the timestamp is collected and exported = for) seems also like something that can be handled by the local = implementation based on a community or other attributes. >=20 > Jon >=20 >=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 --Apple-Mail=_5FF6720D-591C-475A-9F64-1331952ADCDA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPPaqcACgkQA/52wvuLgaFmOgCg5SimX/EWPvzBfR81IYE/w40b V/wAn0/ZXv3oS3nxyBl/5AR24g6F9Xtr =mO+6 -----END PGP SIGNATURE----- --Apple-Mail=_5FF6720D-591C-475A-9F64-1331952ADCDA-- From nobody Wed Jul 23 05:32:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70191B2849; Wed, 23 Jul 2014 05:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm5hZ0sr0zmc; Wed, 23 Jul 2014 05:32:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33D41B282F; Wed, 23 Jul 2014 05:32:48 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 99A763B56B5; Wed, 23 Jul 2014 14:32:47 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 73FAD35C045; Wed, 23 Jul 2014 14:32:47 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Wed, 23 Jul 2014 14:32:47 +0200 From: To: Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] draft-litkowski-idr-bgp-timestamp Thread-Index: Ac+l4ODPJH0/NfV4QnGw7fCPCrH3LgAAhyeAAATe6BAAERcnAAANi68g Date: Wed, 23 Jul 2014 12:32:46 +0000 Message-ID: <20345_1406118767_53CFAB6F_20345_11970_1_9E32478DFA9976438E7A22F69B08FF920448F4@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722212735.GA11770@puck.nether.net> <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <46AF758B-7D81-476F-9F2F-4963262FD181@exa-networks.co.uk> In-Reply-To: <46AF758B-7D81-476F-9F2F-4963262FD181@exa-networks.co.uk> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.23.113023 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Ii8RyF8TsAqbOyeWBgwsuVzHHZY Cc: Jeffrey Haas , idr wg , Robert Raszuk Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 12:32:52 -0000 Hi Thomas, Thanks for your interest on our proposal. Your comments are valuable and for sure, there is some work to do on the en= coding which is not optimal for parsing today. Pls find inline comments. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Thomas Mangin Sent: Wednesday, July 23, 2014 03:56 To: idr-bounces@ietf.org Cc: Jeffrey Haas; idr wg; Robert Raszuk Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp Bonjour Stephane, I am not at the meeting, so could only work from your draft ... Your propos= al seems sensitive and useful to me and I believe it would be a useful addi= tion to the protocol. IMHO, adding some extra message processing would take some CPU time, taking= this CPU from the propagation of UPDATE, so the format should be as simple= as possible and require as little parsing as possible. It is not clear to = me that a speaker can ignore the validity of the data before appending its = TS. Forcing the TS to be validated at every hop would seems to be self-defe= ating. The format is as well quite complex to parse and I would be in favou= r of a much more simple one with less flags and/or options. Regarding format proposed : Type 1 and Type 2 and later in peer : 16 bits ASN can be coded using 32 bit= s - why make a distinction - we do not need to know if the speaker consider= ed itself or was configured as a ASN4 speaker. Why not include ASN and IPs = ( prepended with AFI/SAFI so it is possible to include other Family later )= Why not always include all possible information ASN, IP, IPv6 ( knowing th= at only some may be present ). At debugging time, it is not clear what woul= d be most useful therefore having both the AS and IP should be better. [SLI] Regarding 2B/4B ASN, I would agree ... regarding parsing facility , I= was more thinking about a typed timestamp entry for the next version with = fixed size format (AS type, IPv4 type, IPv6 type). Receiving timestamp from January 1900, I am under the impression that most = system have built-in Epoch function from 1970 and with 64 bits would not su= ffer from any issue with 2038, I wonder why you picked 1990 (which I realis= e is another option). [SLI] Agree, in fact, as I'm not an expert at all on timing, I just copied/= pasted NTPv4 timestamp format :)=20 Regarding the Peer Flags,I would rather see all the information being inclu= ded (ASN and IP). Debugging information should try to provide as much infor= mation as possible. 4.2, I assume this apply for prefixes which match the selection in 4.1 4.4, I would rather see TS being transmitted by default on IBGP sessions an= d explicit on EBGP ( easier to configure ) [SLI] That makes sense to me 4.5.2 does not say how the new TS should be set. It is not clear if the sum= mary option must be implemented or can be left out ( IMHO, this should be l= eft out the draft and be left to be done by the external tool displaying th= e information ) [SLI] Agree that this is not clear, will fix it ...=20 4.6 does not indicate what must be done if two TS entries are in the both s= ynchronised but inconsistent, like a time sequence of 1, 3, 2, 5 where a ro= uter found a way to go back in time :-) .... Should it be ignored or should= this TS sequence be seen as invalid and discarded ( assuming each router i= s performing some validation of the attribute ). [SLI] No this must not be considered as a format error, because this may ha= ppen if router becomes unsynchronized. It would be the job of the tool to u= nderstand that there is an issue in timestamp informations in the vector. I= can add some words on this. Only skimmed over 5+=20 Thomas On 22 Jul 2014, at 23:00, wrote: > Hi Jon, >=20 > Thanks for your comment. > Regarding packing, depending of the address family you are trying to moni= tor, current packing may be low or high. In case where existing packing is = low, it does not change anything. In case packing is high, yes I agree that= the processing of the update is a bit changed and my beacon would be sent = may be faster. Packing is introducing slight delay but I don't think delay = introduced by packing is a major component expect if an implementation get = stucks in packing (it may happen but I never seen it). IMHO, I don't think = this is a critical point but I'm open to other opinions. >=20 > Now for BMP, we are not targeting to monitor our beacons on all PEs, just= a subset of representative. > Moreover it's not only a question about number of sessions, it's a questi= on of ordering the information retrieved. If you consider using BMP , the t= ool will peer with selected PEs, but also "transit BGP Speakers" (ASBRs, RR= s ...). When the tool will receive the timestamp information (if implementa= tion of BMP supports timestamp), it requires to sort and reorganize the rec= eived information based on the knowledge of the topology : you cannot just = sort by timestamp, you have to find relationship between BGP Speakers (info= rmation from BMP and topology) and combine them to recreate our timestamp v= ector. BGP transport permits to create automatically this timestamp vector = without having to implement a complex machinery in the tool. But BMP can be= used at the selected PE to the tool to retrieve timestamp vectors. >=20 > Hope it clarifies. >=20 > Stephane >=20 >=20 > -----Original Message----- > From: Jon Mitchell [mailto:jrmitche@puck.nether.net] > Sent: Tuesday, July 22, 2014 17:28 > To: LITKOWSKI Stephane SCE/IBNF > Cc: Robert Raszuk; Jeffrey Haas; idr wg > Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp >=20 > On 22/07/14 19:19 +0000, stephane.litkowski@orange.com wrote: >> [Renamed topic] >>=20 >> Hi Robert, >>=20 >>> Your results may actually in the above case casue more problems then ga= ins unfortunately. >>=20 >> I don't really understand why ... even if RR are not in the dataplane (w= hich would be the case for VPN environment), RR behavior is really importan= t to track. >>=20 >> Consider a MPLS VPN scenario, some PEs connected to RR clusters and mesh= ing between clusters. >> Consider that one of the RR is getting stuck because of Route-refresh=20 >> processing of 2M of routes or just busy to do something else due to=20 >> bad scheduling in the implemention ... if a PE lose a customer=20 >> connection, and customer has a backup connection and backup PE has to=20 >> send a new BGP update to propagate the new path. The time for RR to=20 >> propagate the BGP update is critical to track because this will=20 >> condition convergence time for the customer ... >>=20 >> Thoughts ? >=20 > Stephane - >=20 > I'm supportive of your goal, however after the presentation I'm still a b= it unclear on the need for the BGP extension to propogate the timestamp inf= ormation. As was brought up by Saikat today in the WG meeting, if update p= acking is different for this prefix due to the timestamp attribute then it = loses some of it's value for providing an accurate view of your end to end = BGP propogation time. Someone suggested BMP, it appears it already support= s this option in paragraph 3 of Section 5 of that draft. The justification= given that instrumenting sessions (BMP/BGP/or other export mechanism for t= he data) to all routers versus getting the information from egress PE only = does not seem to be a large concern if monitoring this route propogation is= of importance to the operator. After all presumably there are a much larg= er number of PE's in most networks than RR's so instrumenting monitoring al= l devices is not much more work than just the PE's. Specifying or identifyi= ng which prefixes are monitored (the timestamp is collected and exported fo= r) seems also like something that can be handled by the local implementatio= n based on a community or other attributes. >=20 > Jon >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, 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 ___________________________________________________________________________= ______________________________________________ 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 Wed Jul 23 07:41:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48E71B2A88 for ; Wed, 23 Jul 2014 07:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2joVD2qwtPpc for ; Wed, 23 Jul 2014 07:40:48 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6300C1B2A4B for ; Wed, 23 Jul 2014 07:40:45 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id v1so842450yhn.23 for ; Wed, 23 Jul 2014 07:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=DJdIH/vwm6NIgB988TQ8qEcchoovGSnQ+9D6eKsKXxc=; b=CP86RoF0zNXSPbrmjEygZUoTd30ut7DflfG0JyU/kRanTbXQ9CC6bgtuSTJE8VOKlD kQK3iuh4Ao3+c2BLSBfSNtaC/NCL8GiFtlwNWFro5f6bzUa9f1itfYtnP+xDQ+thzy3t AnWJW1XAB01yc7fIRpPkZgT0cZhxXWdvUJ9IfoWPtXqecLKmyJYO1xRvrI/moMaMP6ER hv3bjbPvgSHJMJr/H+wVlaBEFW+RmwaqI2bEIyVKTVe3Wt2LLT0LO6lUTXud/obfyvYl CVHn0oPegx8vPA4jZjstCd9IiaX+5H4cht+kBPGdUf1/LW+NAtzv4K8Ryufq1S7oYmY/ +BTg== MIME-Version: 1.0 X-Received: by 10.236.227.230 with SMTP id d96mr2451264yhq.100.1406126444650; Wed, 23 Jul 2014 07:40:44 -0700 (PDT) Received: by 10.170.216.138 with HTTP; Wed, 23 Jul 2014 07:40:44 -0700 (PDT) In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Date: Wed, 23 Jul 2014 10:40:44 -0400 Message-ID: From: Satoru Matsushima To: John Scudder , "idr@ietf. org" Content-Type: multipart/alternative; boundary=001a11c2bc1c3e26c904fedd53c4 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ArfiT_sw7m4gthw2o9Y0Id3VKRM Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:40:52 -0000 --001a11c2bc1c3e26c904fedd53c4 Content-Type: text/plain; charset=UTF-8 Support. cheers, --satoru On Tue, Jul 22, 2014 at 3:43 PM, John Scudder wrote: > Folks, > > The authors have requested IDR adopt > draft-vandevelde-idr-remote-next-hop-06 as a working group document. > > http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > > Please send any comments to the list by August 8. > > In addition to commenting on adoption of the work, you may want to comment > on whether the draft is mature enough for us to consider early allocation > of the path attribute code point. As a reminder, RFC 7120 requires that for > early allocation, "the specifications of these code points must be stable". > (Section 2.c.) The chairs and ADs also have to "judge that there is > sufficient interest in the community for early (pre-RFC) implementation and > deployment". (Section 2.d.) > > It's fine to be in favor of WG adoption but opposed to early allocation at > this time, or in favor of both, or against both. Being against adoption but > in favor of allocation would be a bit weird. :-) > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a11c2bc1c3e26c904fedd53c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support.

cheers,
--satoru


On Tu= e, Jul 22, 2014 at 3:43 PM, John Scudder <jgs@juniper.net> wro= te:
Folks,

The authors have requested IDR adopt draft-vandevelde-idr-remote-next-hop-0= 6 as a working group document.

http://datatracker.ietf.org/doc/draft-vandevelde-i= dr-remote-next-hop/

Please send any comments to the list by August 8.

In addition to commenting on adoption of the work, you may want to comment = on whether the draft is mature enough for us to consider early allocation o= f the path attribute code point. As a reminder, RFC 7120 requires that for = early allocation, "the specifications of these code points must be sta= ble". (Section 2.c.) The chairs and ADs also have to "judge that = there is sufficient interest in the community for early (pre-RFC) implement= ation and deployment". (Section 2.d.)

It's fine to be in favor of WG adoption but opposed to early allocation= at this time, or in favor of both, or against both. Being against adoption= but in favor of allocation would be a bit weird. :-)

Thanks,

--John

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

--001a11c2bc1c3e26c904fedd53c4-- From nobody Wed Jul 23 08:07:26 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C67F1B29A1 for ; Tue, 22 Jul 2014 08:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfFURmhdr9J2 for ; Tue, 22 Jul 2014 08:27:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E58C1B29A4 for ; Tue, 22 Jul 2014 08:26:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKK41360; Tue, 22 Jul 2014 15:26:58 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 16:26:57 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 22 Jul 2014 23:26:51 +0800 From: Lizhenbin To: Lou Berger , "draft-li-idr-mpls-path-programming@tools.ietf.org" Thread-Topic: Question from session on draft-xli-idr-mpls-path-programming Thread-Index: AQHPpcA2DvqptTjOiU6X92RsUyrhnZusNUN3 Date: Tue, 22 Jul 2014 15:26:50 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08232400@nkgeml506-mbx.china.huawei.com> References: <53CE7F8A.1090700@labn.net> In-Reply-To: <53CE7F8A.1090700@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.173.198] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/bUnF-wWDkAJ_FPoeuChC1svcGYk X-Mailman-Approved-At: Wed, 23 Jul 2014 08:07:24 -0700 Cc: "idr@ietf.org" Subject: [Idr] =?gb2312?b?tPC4tDogUXVlc3Rpb24gZnJvbSBzZXNzaW9uIG9uIGRyYWZ0?= =?gb2312?b?LXhsaS1pZHItbXBscy1wYXRoLXByb2dyYW1taW5n?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:27:01 -0000 SGkgTG91LA0KWW91IGFyZSByaWdodC4gU29ycnkgZm9yIG15IG1pc3NpbmcgdGhlIHBvaW50LiBU aGUgUyBmbGFnIGlzIGRlc2lnbmVkIHRvIGJlIGFibGUgdG8gdHJpZ2dlciB0cmFuc3BvcnQgdHVu bmVsIHNldHVwLiBUaGUgdHVubmVsIHNldHVwIG1heWJlIGZhaWxzLiBJZiBzbywgdGhlcmUgY2Fu IGJlIHR3byBwb3NzaWJsZSBwcm9jZXNzIGRlcGVuZGluZyBvbiBsb2NhbCBwb2xpY3k6DQotLSBU aGUgQkdQIHJvdXRlIHdpbGwgbm90IGJlIGFjdGl2ZSBzaW5jZSB0aGUgc3BlY2lmaWVkIHR1bmVs IGlzIFVQLg0KLS0gVGhlIEJHUCByb3V0ZSBjYW4gYmUgYWN0aXZlIHVzaW5nIGFsdGVybmF0aXZl IGJlc3QtZWZmb3J0IExTUCB0dW5uZWwgZXhpc3RpbmcgaW4gdGhlIGluZ3Jlc3MgUEUuDQpUaGVy ZSBleGlzdHMgc2ltaWxpYXIgcG9saWN5IGltcGxlbWVudGF0aW9uIGJ5IG11bHRpcGxlIHZlbmRv ci4gSSB0aGluayBpdCBpcyBwb2xpY3kgd2hpY2ggaXMgb3V0IG9mIHNjb3BlIG9mIHRoZSBkb2N1 bWVudC4NCg0KVGhhbmtzICYgUmVnYXJkcywNClJvYmluDQoNCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBMb3UgQmVyZ2VyIFtsYmVyZ2Vy QGxhYm4ubmV0XQ0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjIyyNUgMjM6MTMNCsrVvP7IyzogZHJhZnQt bGktaWRyLW1wbHMtcGF0aC1wcm9ncmFtbWluZ0B0b29scy5pZXRmLm9yZw0Ks63LzTogaWRyQGll dGYub3JnDQrW98ziOiBRdWVzdGlvbiBmcm9tIHNlc3Npb24gb24gZHJhZnQteGxpLWlkci1tcGxz LXBhdGgtcHJvZ3JhbW1pbmcNCg0KSGksDQogICAgU2luY2Ugd2Ugd2VyZW4ndCBhYmxlIHRvIGNs b3NlIHRoaXMgaW4gdGhlIHNlc3Npb24sIEkgdGhvdWdodCBJJ2QNCmFzayBteSBxdWVzdGlvbiBo ZXJlLiAgVGhlIHF1ZXN0aW9uIHdhcyBzaW1wbHkgd2hhdCBpcyBzdXBwb3NlZCB0bw0KaGFwcGVu IChmcm9tIGEgc2VydmljZSBtb2RlbCBwZXJzcGVjdGl2ZSkgd2hlbiByZXF1ZXN0ZWQgdHVubmVs IHNldHVwLA0Kb3IgZm9yIHRoYXQgbWF0dGVyLCBhbnkgb3RoZXIgdHlwZSBvZiAncGF0aCBwcm9n cmFtbWluZycgZmFpbHM/DQoNClRoZSAgdGV4dCBpbiB0aGUgZHJhZnQgdGhhdCBjYXVnaHQgbXkg ZXllIGlzOg0KDQogICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGZvbGxvd2luZyBmbGFn czoNCiAgICAgICAgICAwIDEgMiAzIDQgNSA2IDcNCiAgICAgICAgICstKy0rLSstKy0rLSstKy0r DQogICAgICAgICB8ICByZXNlcnZlZCAgIHxTfA0KICAgICAgICAgKy0rLSstKy0rLSstKy0rLSsN Cg0KICAgICAgICArIFVuaWNhc3QgVHVubmVsIFNldHVwIFJlcXVpcmVkIChTKQ0KDQoNCiAgIElm IHRoZSBTIGZsYWcgaXMgbm90IHNldCwgdGhlIGNsaWVudCBub2RlIGlzIGp1c3QgdG8gbWFwIHRo ZSBzZXJ2aWNlDQogICBwYXRoIHRvIHRoZSBjb3JyZXNwb25kaW5nIHR1bm5lbC4gIElmIHRoZSBT IGZsYWcgaXMgc2V0LCB0aGUgY2xpZW50DQogICBub2RlIE1VU1Qgc2V0IHVwIHRoZSB0dW5uZWwg YWNjb3JkaW5nIHRvIHRoZSB0dW5uZWwgaWRlbnRpZmllciBhbmQNCiAgIHRoZSB0dW5uZWwgc3Bl Y2lmaWMgYXR0cmlidXRlIGZpcnN0bHkuICBUaGVuIGl0IG1hcHMgdGhlIHNlcnZpY2UgcGF0aA0K ICAgdG8gdGhlIGNvcnJlc3BvbmRpbmcgdHVubmVsLg0KDQoNClRoYW5rcywNCkxvdQ== From nobody Wed Jul 23 09:40:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42981B29B1 for ; Wed, 23 Jul 2014 09:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rpcxqa0cyUzo for ; Wed, 23 Jul 2014 09:40:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE01C1A0022 for ; Wed, 23 Jul 2014 09:40:48 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id F0AC218DA67; Wed, 23 Jul 2014 18:40:46 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C71D4238079; Wed, 23 Jul 2014 18:40:46 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.91]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Wed, 23 Jul 2014 18:40:46 +0200 From: To: Jon Mitchell Thread-Topic: [Idr] draft-litkowski-idr-bgp-timestamp Thread-Index: Ac+l4ODPJH0/NfV4QnGw7fCPCrH3LgAAhyeAAATe6BD//+hzAP/+q/Gw Date: Wed, 23 Jul 2014 16:40:46 +0000 Message-ID: <4365_1406133646_53CFE58E_4365_920_1_9E32478DFA9976438E7A22F69B08FF9204FC47@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722212735.GA11770@puck.nether.net> <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722222246.GB19654@puck.nether.net> In-Reply-To: <20140722222246.GB19654@puck.nether.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/eEYe9exe_1pL1KoUAgyMF-4zs8o Cc: Jeffrey Haas , idr wg , Robert Raszuk Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:40:50 -0000 Sure we can update the text. Thanks, Stephane -----Original Message----- From: Jon Mitchell [mailto:jrmitche@puck.nether.net]=20 Sent: Tuesday, July 22, 2014 18:23 To: LITKOWSKI Stephane SCE/IBNF Cc: Robert Raszuk; Jeffrey Haas; idr wg Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp On 22/07/14 22:00 +0000, stephane.litkowski@orange.com wrote: > Hi Jon, >=20 > Thanks for your comment. > Regarding packing, depending of the address family you are trying to moni= tor, current packing may be low or high. In case where existing packing is = low, it does not change anything. In case packing is high, yes I agree that= the processing of the update is a bit changed and my beacon would be sent = may be faster. Packing is introducing slight delay but I don't think delay = introduced by packing is a major component expect if an implementation get = stucks in packing (it may happen but I never seen it). IMHO, I don't think = this is a critical point but I'm open to other opinions. >=20 > Now for BMP, we are not targeting to monitor our beacons on all PEs, just= a subset of representative. > Moreover it's not only a question about number of sessions, it's a questi= on of ordering the information retrieved. If you consider using BMP , the t= ool will peer with selected PEs, but also "transit BGP Speakers" (ASBRs, RR= s ...). When the tool will receive the timestamp information (if implementa= tion of BMP supports timestamp), it requires to sort and reorganize the rec= eived information based on the knowledge of the topology : you cannot just = sort by timestamp, you have to find relationship between BGP Speakers (info= rmation from BMP and topology) and combine them to recreate our timestamp v= ector. BGP transport permits to create automatically this timestamp vector = without having to implement a complex machinery in the tool. But BMP can be= used at the selected PE to the tool to retrieve timestamp vectors. >=20 Stephane - yes, I think this second point is the real object of the draft (= correct me if I'm wrong). Offline correlation engines are complicated to i= mplement and/or expensive, although commercially available. Getting the ti= mestamp data seems not to be the real issue here at all (via BMP or other m= echanisms a local implementation can provide). Maybe this point should be = more clear in the intro and text. Jon ___________________________________________________________________________= ______________________________________________ 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 Wed Jul 23 15:17:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEDE1B281A for ; Wed, 23 Jul 2014 15:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgElrehFN4qA for ; Wed, 23 Jul 2014 15:17:19 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD1E1A0324 for ; Wed, 23 Jul 2014 15:17:19 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rl12so1581173iec.15 for ; Wed, 23 Jul 2014 15:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=7S8sr5Qo803t0YvBqOwPfcy+l8RtWdgRLwPeTgDOxUI=; b=HJ3XQnr14E5w7SjSKX3Eipx8T3HOynmncMCLLKCQj0KnfHug3/K1br5tPjGkDx8I0P SItFRu9S7s8AxwK/8Y0K/S7sUqUjln3SdYypE6lxMMSjlSPtbggmwZ4IA6btc+k0FRoS HJS9ozRvwuvBA26wOGc55Z+2k05nNqL5tDG6ZK1/62l3QgcvwuS4olfYkYZvhF1WGoem tj7B5/TkLBffNb1wvcPnq0SBcUgGho/DDW655REiFssP13DUNMtjOsm0hbH5mg0QosyY +J8bQ90/hWCBlhUeDuuEYE2bYtJoAGGni7dvTQhcXIarat5MY0Wy5eEpceLQmQZWZXbV XJNw== MIME-Version: 1.0 X-Received: by 10.50.88.37 with SMTP id bd5mr55128697igb.1.1406153838255; Wed, 23 Jul 2014 15:17:18 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Wed, 23 Jul 2014 15:17:18 -0700 (PDT) Date: Thu, 24 Jul 2014 00:17:18 +0200 X-Google-Sender-Auth: nh5MWwl0yV2sfuoAiOfEZBEAa0Y Message-ID: From: Robert Raszuk To: idr wg Content-Type: multipart/alternative; boundary=089e011777ff07676f04fee3b407 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/BOXNNHa5cOrtVnfsOrdPlvSY0WQ Subject: [Idr] New Version Notification for draft-raszuk-idr-bgp-pr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:17:20 -0000 --089e011777ff07676f04fee3b407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Based on the Monday's IDR WG meeting and in particular two presentations recommending collection of two different data sets from transit BGP speakers I took a moment today to write up a short proposal for more general encoding format to accommodate such collection and propagation. In fact as there is more useful operational information to be collected from BGP speakers instead of defining new BGP attribute for each such data type I propose a single structured attribute of BGP Path Record. Another benefit is to help any future proposals to focus on their specific application needs and definition of data to be carried without worry about the envelope it will be placed within. Suggested sub-TLVs in the document are optional and it is to the WG input if those proposed get WG consensus or that perhaps more sub-TLVs of BGP Hop TLV will be suggested for inclusion. Comments and feedback is very welcome ;) Best regards, Robert Raszuk. - - - A new version of I-D, draft-raszuk-idr-bgp-pr-00.txt has been successfully submitted by Robert Raszuk and posted to the IETF repository. Name: draft-raszuk-idr-bgp-pr Revision: 00 Title: BGP Path Record Attribute Document date: 2014-07-23 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-raszuk-idr-bgp-pr-00.txt Status: https://datatracker.ietf.org/doc/draft-raszuk-idr-bgp-pr/ Htmlized: http://tools.ietf.org/html/draft-raszuk-idr-bgp-pr-00 Abstract: BGP protocol today contains number of build in mechanisms which record critical for its loop free operation data along the path of BGP message propagation. Those are encoded in AS_PATH, =E2=80=8B =E2=80=8B CLUSTER_LIST or ORIGINATOR_ID attributes. However in the =E2=80=8B same time there is no provisioning to record other useful information =E2=80=8B =E2=80=8B along the path which can be helpful to the operator in order to enhance =E2=80=8B =E2=80=8B end to end visibility of BGP control plane. In order to solve this problem this document proposes a new single BGP attribute designed as an generic and extensible container to carry number of new optional information corresponding to the BGP speakers given BGP advertisement (or withdraw) message traverses. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --089e011777ff07676f04fee3b407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Based on the Monday's IDR WG meeting and in particular two presentation= s recommending collection of two different data sets from transit BGP speak= ers I took a moment today to write up a short proposal for more general enc= oding format to accommodate such collection and propagation.=C2=A0

In fact as there is more useful opera= tional information to be collected from BGP speakers instead of defining ne= w BGP attribute for each such data type I propose a single structured attri= bute of BGP Path Record.=C2=A0

Another benefit is to help any future= proposals to focus on their specific application needs and definition of d= ata to be carried without worry about the envelope it will be placed within= .=C2=A0

Suggested sub-TLVs in the document ar= e optional and it is to the WG input if those proposed get WG consensus or = that perhaps more sub-TLVs of BGP Hop TLV will be suggested for inclusion.<= /div>

Comments and feedback is very welcome= ;)

Best regards,
Robert Raszuk.

- - -=C2=A0
=

A new version of I-D, draft-raszuk-idr-bgp-pr-00.txt
has been successfully submitted by Robert Raszuk and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-raszuk-idr-bgp-pr
Revision: =C2=A0 =C2=A0 =C2=A0 00
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BGP Path Record Attribute
Document date: =C2=A02014-07-23
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://= www.ietf.org/internet-drafts/draft-raszuk-idr-bgp-pr-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.o= rg/doc/draft-raszuk-idr-bgp-pr/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/draft-ra= szuk-idr-bgp-pr-00

Abstract:
=C2=A0 =C2=A0BGP protocol today contains number of build in mechanisms whic= h
=C2=A0 =C2=A0record critical for its loop free operation data along the pat= h of
=C2=A0 =C2=A0BGP message propagation. =C2=A0Those are encoded in AS_PATH, <= div class=3D"gmail_default" style=3D"font-family:'courier new',mono= space;font-size:small;display:inline">=E2=80=8B=C2=A0
=C2=A0=E2=80=8B
CLUSTER_LIST=C2=A0 or ORIGINATOR_ID attributes. =C2=A0= However in the=C2=A0
=E2=80=8B
same time there is no =C2=A0provisioning t= o record other useful information=C2=A0
=E2=80=8B= =E2=80=8B
along the path which =C2=A0can be helpful to the operator i= n order to enhance=C2=A0
=E2=80=8B= =E2=80=8B
end to end =C2=A0visibility of BGP control plane.

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

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

The IETF Secretariat


--089e011777ff07676f04fee3b407-- From nobody Thu Jul 24 06:00:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D129E1A02DB for ; Thu, 24 Jul 2014 06:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxZ75kZ3bxIV for ; Thu, 24 Jul 2014 06:00:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7AD1A023E for ; Thu, 24 Jul 2014 06:00:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1XAIdG-000537-MV; Thu, 24 Jul 2014 13:00:26 +0000 Date: Thu, 24 Jul 2014 09:00:26 -0400 Message-ID: From: Randy Bush To: John Scudder In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/PEU0OP7GSj2KkGKmSLgP9sOWhwA Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 13:00:30 -0000 i am an author, so it would be inappropriate for me to support. but, as i have been known to occasionally oppose drafts for which i am an author, i should say i do not oppose adoption od this draft. :) randy From nobody Thu Jul 24 10:28:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDE61B2A61 for ; Wed, 23 Jul 2014 10:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pZMTjbSEvnl for ; Wed, 23 Jul 2014 10:12:50 -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 5871E1B2A5C for ; Wed, 23 Jul 2014 10:12:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKL48601; Wed, 23 Jul 2014 17:12:48 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 18:12:47 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 01:12:44 +0800 From: Lizhenbin To: Lou Berger , "draft-li-idr-mpls-path-programming@tools.ietf.org" Thread-Topic: =?gb2312?B?tPC4tDogUXVlc3Rpb24gZnJvbSBzZXNzaW9uIG9uIGRyYWZ0LXhsaS1pZHIt?= =?gb2312?Q?mpls-path-programming?= Thread-Index: AQHPpcA2DvqptTjOiU6X92RsUyrhnZusNUN3///I84CAAeh+hw== Date: Wed, 23 Jul 2014 17:12:43 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08232A81@nkgeml506-mbx.china.huawei.com> References: <53CE7F8A.1090700@labn.net> <5A5B4DE12C0DAC44AF501CD9A2B01A8D08232400@nkgeml506-mbx.china.huawei.com>, <53CEC369.3010907@labn.net> In-Reply-To: <53CEC369.3010907@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.216.44.158] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/DdB4C5IS7OSHhpA7IA287aV8Uws X-Mailman-Approved-At: Thu, 24 Jul 2014 10:28:50 -0700 Cc: "idr@ietf.org" Subject: [Idr] =?gb2312?b?tPC4tDogtPC4tDogUXVlc3Rpb24gZnJvbSBzZXNzaW9uIG9u?= =?gb2312?b?IGRyYWZ0LXhsaS1pZHItbXBscy1wYXRoLXByb2dyYW1taW5n?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 17:12:51 -0000 DQpIaSBMb3UsDQpXZSB3aWxsIHJlLWNoZWNrIHRoZSBTIGJpdCBkZXNpZ24gY2FyZWZ1bGx5IGFj Y29yZGluZyB0byB5b3VyIHN1Z2dlc3Rpb24uDQoNClRoYW5rcywNClJvYmluDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBMb3UgQmVyZ2VyIFts YmVyZ2VyQGxhYm4ubmV0XQ0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjIzyNUgNDowMg0KytW8/sjLOiBM aXpoZW5iaW47IGRyYWZ0LWxpLWlkci1tcGxzLXBhdGgtcHJvZ3JhbW1pbmdAdG9vbHMuaWV0Zi5v cmcNCrOty806IGlkckBpZXRmLm9yZw0K1vfM4jogUmU6ILTwuLQ6IFF1ZXN0aW9uIGZyb20gc2Vz c2lvbiBvbiBkcmFmdC14bGktaWRyLW1wbHMtcGF0aC1wcm9ncmFtbWluZw0KDQpJIHRoaW5rIGl0 IHdvdWxkIGJlIGJldHRlciB0byBoYXZlIHRoZSBTIGJpdCBvdXQgb2Ygc2NvcGUgb2YgdGhlDQpk b2N1bWVudC4gVGhlcmUgYXJlIG90aGVyIG1lY2hhbmlzbXMgdGhhdCBjb3ZlciB0dW5uZWwgaW5p dGlhdGlvbiBhbmQNCkknbSBub3Qgc3VyZSB3ZSBuZWVkIGFub3RoZXIuLi4NCg0KTG91DQoNCg0K T24gNy8yMi8yMDE0IDExOjI2IEFNLCBMaXpoZW5iaW4gd3JvdGU6DQo+IEhpIExvdSwNCj4gWW91 IGFyZSByaWdodC4gU29ycnkgZm9yIG15IG1pc3NpbmcgdGhlIHBvaW50LiBUaGUgUyBmbGFnIGlz IGRlc2lnbmVkIHRvIGJlIGFibGUgdG8gdHJpZ2dlciB0cmFuc3BvcnQgdHVubmVsIHNldHVwLiBU aGUgdHVubmVsIHNldHVwIG1heWJlIGZhaWxzLiBJZiBzbywgdGhlcmUgY2FuIGJlIHR3byBwb3Nz aWJsZSBwcm9jZXNzIGRlcGVuZGluZyBvbiBsb2NhbCBwb2xpY3k6DQo+IC0tIFRoZSBCR1Agcm91 dGUgd2lsbCBub3QgYmUgYWN0aXZlIHNpbmNlIHRoZSBzcGVjaWZpZWQgdHVuZWwgaXMgVVAuDQo+ IC0tIFRoZSBCR1Agcm91dGUgY2FuIGJlIGFjdGl2ZSB1c2luZyBhbHRlcm5hdGl2ZSBiZXN0LWVm Zm9ydCBMU1AgdHVubmVsIGV4aXN0aW5nIGluIHRoZSBpbmdyZXNzIFBFLg0KPiBUaGVyZSBleGlz dHMgc2ltaWxpYXIgcG9saWN5IGltcGxlbWVudGF0aW9uIGJ5IG11bHRpcGxlIHZlbmRvci4gSSB0 aGluayBpdCBpcyBwb2xpY3kgd2hpY2ggaXMgb3V0IG9mIHNjb3BlIG9mIHRoZSBkb2N1bWVudC4N Cj4NCj4gVGhhbmtzICYgUmVnYXJkcywNCj4gUm9iaW4NCj4NCj4NCj4NCj4NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiC3orz+yMs6IExvdSBCZXJnZXIg W2xiZXJnZXJAbGFibi5uZXRdDQo+ILeiy83KsbzkOiAyMDE0xOo31MIyMsjVIDIzOjEzDQo+IMrV vP7IyzogZHJhZnQtbGktaWRyLW1wbHMtcGF0aC1wcm9ncmFtbWluZ0B0b29scy5pZXRmLm9yZw0K PiCzrcvNOiBpZHJAaWV0Zi5vcmcNCj4g1vfM4jogUXVlc3Rpb24gZnJvbSBzZXNzaW9uIG9uIGRy YWZ0LXhsaS1pZHItbXBscy1wYXRoLXByb2dyYW1taW5nDQo+DQo+IEhpLA0KPiAgICAgU2luY2Ug d2Ugd2VyZW4ndCBhYmxlIHRvIGNsb3NlIHRoaXMgaW4gdGhlIHNlc3Npb24sIEkgdGhvdWdodCBJ J2QNCj4gYXNrIG15IHF1ZXN0aW9uIGhlcmUuICBUaGUgcXVlc3Rpb24gd2FzIHNpbXBseSB3aGF0 IGlzIHN1cHBvc2VkIHRvDQo+IGhhcHBlbiAoZnJvbSBhIHNlcnZpY2UgbW9kZWwgcGVyc3BlY3Rp dmUpIHdoZW4gcmVxdWVzdGVkIHR1bm5lbCBzZXR1cCwNCj4gb3IgZm9yIHRoYXQgbWF0dGVyLCBh bnkgb3RoZXIgdHlwZSBvZiAncGF0aCBwcm9ncmFtbWluZycgZmFpbHM/DQo+DQo+IFRoZSAgdGV4 dCBpbiB0aGUgZHJhZnQgdGhhdCBjYXVnaHQgbXkgZXllIGlzOg0KPg0KPiAgICAgICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgdGhlIGZvbGxvd2luZyBmbGFnczoNCj4gICAgICAgICAgIDAgMSAyIDMg NCA1IDYgNw0KPiAgICAgICAgICArLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAgICB8ICByZXNl cnZlZCAgIHxTfA0KPiAgICAgICAgICArLSstKy0rLSstKy0rLSstKw0KPg0KPiAgICAgICAgICsg VW5pY2FzdCBUdW5uZWwgU2V0dXAgUmVxdWlyZWQgKFMpDQo+DQo+DQo+ICAgIElmIHRoZSBTIGZs YWcgaXMgbm90IHNldCwgdGhlIGNsaWVudCBub2RlIGlzIGp1c3QgdG8gbWFwIHRoZSBzZXJ2aWNl DQo+ICAgIHBhdGggdG8gdGhlIGNvcnJlc3BvbmRpbmcgdHVubmVsLiAgSWYgdGhlIFMgZmxhZyBp cyBzZXQsIHRoZSBjbGllbnQNCj4gICAgbm9kZSBNVVNUIHNldCB1cCB0aGUgdHVubmVsIGFjY29y ZGluZyB0byB0aGUgdHVubmVsIGlkZW50aWZpZXIgYW5kDQo+ICAgIHRoZSB0dW5uZWwgc3BlY2lm aWMgYXR0cmlidXRlIGZpcnN0bHkuICBUaGVuIGl0IG1hcHMgdGhlIHNlcnZpY2UgcGF0aA0KPiAg ICB0byB0aGUgY29ycmVzcG9uZGluZyB0dW5uZWwuDQo+DQo+DQo+IFRoYW5rcywNCj4gTG91 From nobody Thu Jul 24 11:50:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A71F1A0AF9 for ; Thu, 24 Jul 2014 11:50:17 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DXy2j4M5pWB for ; Thu, 24 Jul 2014 11:50:16 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id DBF7E1A0194 for ; Thu, 24 Jul 2014 11:50:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.162.238; From: "Susan Hares" To: "'Jon Mitchell'" , References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722212735.GA11770@puck.nether.net> <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722222246.GB19654@puck.nether.net> In-Reply-To: <20140722222246.GB19654@puck.nether.net> Date: Thu, 24 Jul 2014 14:50:06 -0400 Message-ID: <006a01cfa770$165cccf0$431666d0$@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: AQF7cNhsKZhrfXZn4jdnN6RtIb/8AQHzVLjSAbWg4sQCToKL9pwoQUrg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/dDLWE-eQj5_oLBuQqO_ig0utwl8 Cc: 'Jeffrey Haas' , 'idr wg' , 'Robert Raszuk' Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:50:18 -0000 Jon and Stephan: Based on work with vendor boxes for the BMWG BGP work - I would recommend you timestamp the BGP trace NLRI as you leave the BGP Peer and as you receive it. Otherwise, you run into the data flow patterns the trace NLRI is included in causing variation in your flows. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jon Mitchell Sent: Tuesday, July 22, 2014 6:23 PM To: stephane.litkowski@orange.com Cc: Jeffrey Haas; idr wg; Robert Raszuk Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp On 22/07/14 22:00 +0000, stephane.litkowski@orange.com wrote: > Hi Jon, > > Thanks for your comment. > Regarding packing, depending of the address family you are trying to monitor, current packing may be low or high. In case where existing packing is low, it does not change anything. In case packing is high, yes I agree that the processing of the update is a bit changed and my beacon would be sent may be faster. Packing is introducing slight delay but I don't think delay introduced by packing is a major component expect if an implementation get stucks in packing (it may happen but I never seen it). IMHO, I don't think this is a critical point but I'm open to other opinions. > > Now for BMP, we are not targeting to monitor our beacons on all PEs, just a subset of representative. > Moreover it's not only a question about number of sessions, it's a question of ordering the information retrieved. If you consider using BMP , the tool will peer with selected PEs, but also "transit BGP Speakers" (ASBRs, RRs ...). When the tool will receive the timestamp information (if implementation of BMP supports timestamp), it requires to sort and reorganize the received information based on the knowledge of the topology : you cannot just sort by timestamp, you have to find relationship between BGP Speakers (information from BMP and topology) and combine them to recreate our timestamp vector. BGP transport permits to create automatically this timestamp vector without having to implement a complex machinery in the tool. But BMP can be used at the selected PE to the tool to retrieve timestamp vectors. > Stephane - yes, I think this second point is the real object of the draft (correct me if I'm wrong). Offline correlation engines are complicated to implement and/or expensive, although commercially available. Getting the timestamp data seems not to be the real issue here at all (via BMP or other mechanisms a local implementation can provide). Maybe this point should be more clear in the intro and text. Jon _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Jul 24 13:27:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76FD1ABB2E for ; Thu, 24 Jul 2014 13:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dsf3ALr2yJHS for ; Thu, 24 Jul 2014 13:27:03 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C94B1B2897 for ; Thu, 24 Jul 2014 13:26:56 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so3138344igc.0 for ; Thu, 24 Jul 2014 13:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OknX/i84bRclEdFYIPK9ZdMPlrYYcZQFdUJuy1KuVeA=; b=gN3RdlCrj3UnAP7ROxdwRyzXYqUsKNII5QXe6lkYwHP4nP/dcpxjxBc9LGuuVQNeKf n6Fi33BQgAedbywb7hp0+L3/MR6iD6PIs/beK2r3+yHGJDcPHDO4vUsPX3OIN51e+CJ6 erpKj5rmag5GYDvzRTzDp0HNc0P0ROvWwxWljTT2087W6aNkyg6B6tWeveIE55OfvgB8 HPVx55B1fDtJeQMLkLtx1/gFVgtw/En2U+PL22g3h0BGKKi1hIOxG60+fNmbyvV5knPh Rwb23Q9chB1hcGdq5aNtK+I/uJ5m+/fk/LNsfjh1Cp1ZLI4aRqlOTN/3LEB49H4xmJ9F 2zCQ== MIME-Version: 1.0 X-Received: by 10.42.154.132 with SMTP id q4mr15591504icw.4.1406233615833; Thu, 24 Jul 2014 13:26:55 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Thu, 24 Jul 2014 13:26:55 -0700 (PDT) In-Reply-To: <006a01cfa770$165cccf0$431666d0$@ndzh.com> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722212735.GA11770@puck.nether.net> <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722222246.GB19654@puck.nether.net> <006a01cfa770$165cccf0$431666d0$@ndzh.com> Date: Thu, 24 Jul 2014 22:26:55 +0200 X-Google-Sender-Auth: Eihw_nYyAcNmSv6aRi1sn8B2iyU Message-ID: From: Robert Raszuk To: Susan Hares Content-Type: multipart/alternative; boundary=90e6ba6e87a624a02b04fef64747 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/U9BYNoS6bD8GrzJLi7ju4vTI9Bw Cc: Jeffrey Haas , idr wg Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:27:05 -0000 --90e6ba6e87a624a02b04fef64747 Content-Type: text/plain; charset=UTF-8 Sue your observation is valid however I have two comments to it: *A* it does not apply to specifically crafted beacons as by such "special crafting" you eliminate by design the expected variations. *B* in general case you are right, but the general case is still broken if timestamp is a property of the BGP path. Path may sit idle in BGP speaker for minutes or hours and longer before at some event it is promoted as best and send with say 30 min in/out delta falsely indicating potential problems with given BGP speaker. And the way to eliminate that is *A* hence perhaps just sticking to A is sufficient. best regards, R. On Thu, Jul 24, 2014 at 8:50 PM, Susan Hares wrote: > Jon and Stephan: > > Based on work with vendor boxes for the BMWG BGP work - I would recommend > you timestamp the BGP trace NLRI as you leave the BGP Peer and as you > receive it. Otherwise, you run into the data flow patterns the trace NLRI > is > included in causing variation in your flows. > > Sue > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jon Mitchell > Sent: Tuesday, July 22, 2014 6:23 PM > To: stephane.litkowski@orange.com > Cc: Jeffrey Haas; idr wg; Robert Raszuk > Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp > > On 22/07/14 22:00 +0000, stephane.litkowski@orange.com wrote: > > Hi Jon, > > > > Thanks for your comment. > > Regarding packing, depending of the address family you are trying to > monitor, current packing may be low or high. In case where existing packing > is low, it does not change anything. In case packing is high, yes I agree > that the processing of the update is a bit changed and my beacon would be > sent may be faster. Packing is introducing slight delay but I don't think > delay introduced by packing is a major component expect if an > implementation > get stucks in packing (it may happen but I never seen it). IMHO, I don't > think this is a critical point but I'm open to other opinions. > > > > Now for BMP, we are not targeting to monitor our beacons on all PEs, just > a subset of representative. > > Moreover it's not only a question about number of sessions, it's a > question of ordering the information retrieved. If you consider using BMP , > the tool will peer with selected PEs, but also "transit BGP Speakers" > (ASBRs, RRs ...). When the tool will receive the timestamp information (if > implementation of BMP supports timestamp), it requires to sort and > reorganize the received information based on the knowledge of the topology > : > you cannot just sort by timestamp, you have to find relationship between > BGP > Speakers (information from BMP and topology) and combine them to recreate > our timestamp vector. BGP transport permits to create automatically this > timestamp vector without having to implement a complex machinery in the > tool. But BMP can be used at the selected PE to the tool to retrieve > timestamp vectors. > > > > Stephane - yes, I think this second point is the real object of the draft > (correct me if I'm wrong). Offline correlation engines are complicated to > implement and/or expensive, although commercially available. Getting the > timestamp data seems not to be the real issue here at all (via BMP or other > mechanisms a local implementation can provide). Maybe this point should be > more clear in the intro and text. > > Jon > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --90e6ba6e87a624a02b04fef64747 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sue your observation is valid however I have= two comments to it:

*A* it does not apply to specifically crafted beaco= ns as by such "special crafting" you eliminate by design the expe= cted variations.

*B* in general case you are right, bu= t the general case is still broken if timestamp is a property of the BGP pa= th. Path may sit idle in BGP speaker for minutes or hours and longer before= at some event it is promoted as best and send with say 30 min in/out delta= falsely indicating potential problems with given BGP speaker. And the way = to eliminate that is *A* hence perhaps just sticking to A is sufficient.

best regards,
R.


On Thu, Jul 24, 2014 at 8:50 PM, Susan Hares <shares@ndzh.com> wrote:
Jon and Stephan:

Based on work with vendor boxes for the BMWG BGP work - I would recommend you timestamp the BGP trace NLRI as you leave the BGP Peer and as you
receive it. Otherwise, you run into the data flow patterns the trace NLRI i= s
included in causing variation in your flows.

Sue

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.= org] On Behalf Of Jon Mitchell
Sent: Tuesday, July 22, 2014 6:23 PM
To: stephane.litkowski@ora= nge.com
Cc: Jeffrey Haas; idr wg; Robert Raszuk
Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp

On 22/07/14 22:00 +0000, stephane.litkowski@orange.com<= /a> wrote:
> Hi Jon,
>
> Thanks for your comment.
> Regarding packing, depending of the address family you are trying to monitor, current packing may be low or high. In case where existing packing=
is low, it does not change anything. In case packing is high, yes I agree that the processing of the update is a bit changed and my beacon would be sent may be faster. Packing is introducing slight delay but I don't thi= nk
delay introduced by packing is a major component expect if an implementatio= n
get stucks in packing (it may happen but I never seen it). IMHO, I don'= t
think this is a critical point but I'm open to other opinions.
>
> Now for BMP, we are not targeting to monitor our beacons on all PEs, j= ust
a subset of representative.
> Moreover it's not only a question about number of sessions, it'= ;s a
question of ordering the information retrieved. If you consider using BMP ,=
the tool will peer with selected PEs, but also "transit BGP Speakers&q= uot;
(ASBRs, RRs ...). When the tool will receive the timestamp information (if<= br> implementation of BMP supports timestamp), it requires to sort and
reorganize the received information based on the knowledge of the topology = :
you cannot just sort by timestamp, you have to find relationship between BG= P
Speakers (information from BMP and topology) and combine them to recreate our timestamp vector. BGP transport permits to create automatically this timestamp vector without having to implement a complex machinery in the
tool. But BMP can be used at the selected PE to the tool to retrieve
timestamp vectors.
>

Stephane - yes, I think this second point is the real object of the draft (correct me if I'm wrong). =C2=A0Offline correlation engines are compli= cated to
implement and/or expensive, although commercially available. =C2=A0Getting = the
timestamp data seems not to be the real issue here at all (via BMP or other=
mechanisms a local implementation can provide). =C2=A0Maybe this point shou= ld be
more clear in the intro and text.

Jon

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


--90e6ba6e87a624a02b04fef64747-- From nobody Thu Jul 24 13:47:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481991B27B2 for ; Thu, 24 Jul 2014 13:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaIGjJ7xBRGg for ; Thu, 24 Jul 2014 13:47:45 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87D41A06B5 for ; Thu, 24 Jul 2014 13:47:45 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rd18so2793416iec.37 for ; Thu, 24 Jul 2014 13:47:44 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=137Z17oqVhKU6V3xk4oCeIsuDVKFMpwoXXzqgCqwfCA=; b=ziBKRnsGhCx3QGWv3RppSEnTFxBAgE9Fbdh0IrlPQH60VtGzqM4XUUS1HRsBUrPvgK m24PTIhdBdBWvHnAMC4dXN+zlUZj6tSZoCvDDDSG9wsI77GcnYoWgb6fm1+Egi/k1bwt 5fgzeelN8nIfLabYqr7QBwu0sNa8d6yCSt59vBNqHOyMT4RLFhz6bVk5e9E7PcbP6d1w e64D88nYCTtSNV5bh3CJHFfHwHpN5MJ5JxupScmiscGnGdQr+5QeD3ZY4/I5VGY8OonS 9Z24IWBrhKCMOQvURHS3q3bATrxB2CcUxi5H0cnUQIoROlBFhl9IgqEA9lT/2tayQqBi KoxA== X-Received: by 10.42.114.130 with SMTP id g2mr16022200icq.46.1406234864906; Thu, 24 Jul 2014 13:47:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.60.233 with HTTP; Thu, 24 Jul 2014 13:47:04 -0700 (PDT) In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> From: Satoshi Usui Date: Thu, 24 Jul 2014 16:47:04 -0400 Message-ID: To: John Scudder Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/wplCZCuyExqmMbFXRpf0JFMVKDk Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:47:47 -0000 I'm in favor of both, WG adoption and early allocation of the the code poin= t. Satoshi On Tue, Jul 22, 2014 at 3:43 PM, John Scudder wrote: > Folks, > > The authors have requested IDR adopt draft-vandevelde-idr-remote-next-hop= -06 as a working group document. > > http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ > > Please send any comments to the list by August 8. > > In addition to commenting on adoption of the work, you may want to commen= t on whether the draft is mature enough for us to consider early allocation= of the path attribute code point. As a reminder, RFC 7120 requires that fo= r early allocation, "the specifications of these code points must be stable= ". (Section 2.c.) The chairs and ADs also have to "judge that there is suff= icient interest in the community for early (pre-RFC) implementation and dep= loyment". (Section 2.d.) > > It's fine to be in favor of WG adoption but opposed to early allocation a= t this time, or in favor of both, or against both. Being against adoption b= ut in favor of allocation would be a bit weird. :-) > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jul 25 05:06:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B99B1B2801 for ; Fri, 25 Jul 2014 05:06:21 -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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIDtHBu-l5nP for ; Fri, 25 Jul 2014 05:06:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F8B1B2820 for ; Fri, 25 Jul 2014 05:06:18 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0273.namprd09.prod.outlook.com (25.160.80.22) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 25 Jul 2014 12:06:16 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.0990.007; Fri, 25 Jul 2014 12:06:16 +0000 From: "Sriram, Kotikalapudi" To: "idr@ietf.org" Thread-Topic: [Idr] FW: New Version Notification for draft-sriram-route-leak-protection-00 Thread-Index: AQHPqAAG/131OyqJ+0aKKwIZL/OlhQ== Date: Fri, 25 Jul 2014 12:06:15 +0000 Message-ID: <1406289979244.58090@nist.gov> References: , <24D54F13-C8C8-48AC-A687-F543FF8F2712@tislabs.com> In-Reply-To: <24D54F13-C8C8-48AC-A687-F543FF8F2712@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:136:3d39:5656:c8fa:476a] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(377454003)(51704005)(107886001)(36756003)(85306003)(107046002)(74662001)(77096002)(99286002)(64706001)(105586002)(110136001)(46102001)(81542001)(2351001)(21056001)(79102001)(54356999)(85852003)(76176999)(19580395003)(50986999)(74502001)(15202345003)(77982001)(80022001)(99396002)(2656002)(81342001)(76482001)(19273905006)(106356001)(20776003)(15975445006)(106116001)(95666004)(4396001)(86362001)(83072002)(99936001)(101416001)(87936001)(19580405001)(92726001)(92566001)(83322001)(31966008)(563064011); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB0273; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/mixed; boundary="_003_140628997924458090nistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/idr/xV_a_3Ep5sMmQWYCxIZBXigxfSM Subject: Re: [Idr] FW: New Version Notification for draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 12:06:21 -0000 --_003_140628997924458090nistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For IDR WG folks who might be interested,=0A= please see Chris's message below.=0A= This work will be presented in GROW today.=0A= =0A= Sriram=0A= =0A= Begin forwarded message:=0A= =0A= > From: Christopher Morrow =0A= > Subject: [GROW] Meeting information IETF90=0A= > Date: July 24, 2014 10:47:07 PM EDT=0A= > To: "grow@ietf.org grow@ietf.org" =0A= >=0A= > since we're almost through IETF90, it must mean it's time for a grow meet= ing...=0A= >=0A= > http://tools.ietf.org/wg/grow/agenda=0A= >=0A= > has the agenda, note that:=0A= > draft-sriram-route-leak-protection=0A= >=0A= > is a new individual (for now) submission looking for some=0A= > consideration/reading/review/home. Sriram will be presenting the=0A= > content and I believe he's already worked out some arrangement with=0A= > the route-leaks-bgpsec-no-help authors for combining efforts in this=0A= > area.=0A= >=0A= > See you folk tomorrow before plane/trains/automobiles commence.=0A= >=0A= > -chris=0A= >=0A= > _______________________________________________=0A= > GROW mailing list=0A= > GROW@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/grow=0A= =0A= --_003_140628997924458090nistgov_ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail.asc Content-Disposition: attachment; filename="signature.asc"; size=859; creation-date="Fri, 25 Jul 2014 09:18:37 GMT"; modification-date="Fri, 25 Jul 2014 09:18:37 GMT" Content-ID: Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCkNvbW1lbnQ6IEdQR1Rvb2xzIC0gaHR0cHM6 Ly9ncGd0b29scy5vcmcNCg0KaVFJY0JBRUJDZ0FHQlFKVDBpRGVBQW9KRUhwbHBRZWV0MElaV3JZ UC8wT1c1VmJMMDNXMFkxakRhRVIycjJJSA0KQnprOVplRXI0S3B6MVdjdkcyNjc5aU5Yd2JZakpa b2RzQnBSUEd3TEtHVHRnblIyMERKWDZmOUUxbnZDc3prZw0KV0dyeDNvSjJ0Rkl0R2xoaWVPenBD N2w5QzREckFocXVtcHBHT2JTMm5TQzN2T0prY1dnS0ZHMGMxYlJBM2o4WQ0KOWZuZU9MZmZ1OGtI VEEyU0VNY1MzOEdpLzZIVXJZellyU25neXprZFBCdWVBZGVtS2ZROGRDaTVuYmpWNWRLYg0KMHh0 SEFlUDRYMG5jenBrdjBERjZ0RE1WcGc5TEcxa3J3bHRyWXJvYi9zeXhPeDBxNWV0Kzh5c2p3OFEr Y24wbw0KdmU2R0xzdGJUUzBUc0t3WTRGbzVyUlA3VnlBUE1lckZ6TERtdWhlZ0cwNGRQUTN6UVhz UkVLaWlMM2lkUmtSeA0KQmhiVlpON1prRlAwVHpTY0oyUC9xTzlZMTdKcmVWRk9yZHN5S0R5V1hJ MUJGUldTaVB4TSs4c0FENi9lSXRGcA0KMUNzY29peklEazcrcWphREJxazJvdk5Yb3JmVmNkekhx Qi92THlKazJ0VUtNMDhVS0FMblU4TThrZjFMZklYdA0KL29xZkJoOGJMVlRRdFRaM3hxMXM5WE90 TTdyQWVLU2xZalg1enZNRng2aktkQWEzc29kaE1pZ3owbkNiOEFnNQ0KRE53SHFPbSthNVdmTXlt MDViajBIQkZUa1pVVlBseWkySm1vQUZHTFFUVEs4Si9LNjV2VjJKRzhpNCtoSGdFRg0KUENsdndj TE9qSHppREwrb04xbUlFa1hnVnRrNVl4aFo3MlE0SEM4SnE5dHdEblJCRnFXVURtcEpFR05odUhl QQ0KT1Q3UjFPNS9oazJMQUdKSVFNRmoNCj10TmM5DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0t LS0NCg== --_003_140628997924458090nistgov_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Fri, 25 Jul 2014 09:18:37 GMT"; modification-date="Fri, 25 Jul 2014 09:18:37 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpZHIgbWFp bGluZyBsaXN0DQpzaWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpZHINCg== --_003_140628997924458090nistgov_-- From nobody Fri Jul 25 09:48:17 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9811E1A0385 for ; Fri, 25 Jul 2014 09:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05HAi3WQC3cZ for ; Fri, 25 Jul 2014 09:48:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72ECA1A030C for ; Fri, 25 Jul 2014 09:48:12 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 190BD3B5290; Fri, 25 Jul 2014 18:48:11 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E818727C06E; Fri, 25 Jul 2014 18:48:10 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.91]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Fri, 25 Jul 2014 18:48:10 +0200 From: To: Susan Hares , 'Jon Mitchell' Thread-Topic: [Idr] draft-litkowski-idr-bgp-timestamp Thread-Index: Ac+l4ODPJH0/NfV4QnGw7fCPCrH3LgAAhyeAAATe6BD//+hzAIAC6T8A//5u0dA= Date: Fri, 25 Jul 2014 16:48:10 +0000 Message-ID: <4395_1406306891_53D28A4A_4395_13255_1_9E32478DFA9976438E7A22F69B08FF9205DB3B@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722212735.GA11770@puck.nether.net> <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722222246.GB19654@puck.nether.net> <006a01cfa770$165cccf0$431666d0$@ndzh.com> In-Reply-To: <006a01cfa770$165cccf0$431666d0$@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.25.113919 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/6mv10rKNLrC3tf6Ehu7VFQzqfr0 Cc: 'Jeffrey Haas' , 'idr wg' , 'Robert Raszuk' Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:48:14 -0000 Susan, Thanks for pointing this. We will investigate the possibility to do it from= an implementation point of view. Putting timestamp at receive side is easy= , at transmit side it may be more complex and really implementation dependa= nt as we would need to try to have a consensus at which part of the sending= process, we would need to put the timestamp (Update formatting, Route Queu= eing for the peer group ...) Best Regards, Stephane -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Thursday, July 24, 2014 14:50 To: 'Jon Mitchell'; LITKOWSKI Stephane SCE/IBNF Cc: 'Jeffrey Haas'; 'idr wg'; 'Robert Raszuk' Subject: RE: [Idr] draft-litkowski-idr-bgp-timestamp Jon and Stephan:=20 Based on work with vendor boxes for the BMWG BGP work - I would recommend y= ou timestamp the BGP trace NLRI as you leave the BGP Peer and as you receiv= e it. Otherwise, you run into the data flow patterns the trace NLRI is incl= uded in causing variation in your flows. Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jon Mitchell Sent: Tuesday, July 22, 2014 6:23 PM To: stephane.litkowski@orange.com Cc: Jeffrey Haas; idr wg; Robert Raszuk Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp On 22/07/14 22:00 +0000, stephane.litkowski@orange.com wrote: > Hi Jon, >=20 > Thanks for your comment. > Regarding packing, depending of the address family you are trying to monitor, current packing may be low or high. In case where existing packing= is low, it does not change anything. In case packing is high, yes I agree = that the processing of the update is a bit changed and my beacon would be s= ent may be faster. Packing is introducing slight delay but I don't think de= lay introduced by packing is a major component expect if an implementation = get stucks in packing (it may happen but I never seen it). IMHO, I don't th= ink this is a critical point but I'm open to other opinions. >=20 > Now for BMP, we are not targeting to monitor our beacons on all PEs,=20 > just a subset of representative. > Moreover it's not only a question about number of sessions, it's a question of ordering the information retrieved. If you consider using BMP ,= the tool will peer with selected PEs, but also "transit BGP Speakers" (ASBRs, RRs ...). When the tool will receive the timestamp information (if = implementation of BMP supports timestamp), it requires to sort and reorgani= ze the received information based on the knowledge of the topology : you cannot just sort by timestamp, you have to find relationship between BG= P Speakers (information from BMP and topology) and combine them to recreate= our timestamp vector. BGP transport permits to create automatically this t= imestamp vector without having to implement a complex machinery in the tool= . But BMP can be used at the selected PE to the tool to retrieve timestamp = vectors. >=20 Stephane - yes, I think this second point is the real object of the draft (= correct me if I'm wrong). Offline correlation engines are complicated to i= mplement and/or expensive, although commercially available. Getting the ti= mestamp data seems not to be the real issue here at all (via BMP or other m= echanisms a local implementation can provide). Maybe this point should be = more clear in the intro and text. Jon _______________________________________________ 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 Sat Jul 26 01:20:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1361A00DF for ; Sat, 26 Jul 2014 01:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nibSiXEfQWUU for ; Sat, 26 Jul 2014 01:20:15 -0700 (PDT) Received: from out-13.mail.exa.net.uk (out-13.mail.exa.net.uk [82.219.4.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD821A03A9 for ; Sat, 26 Jul 2014 01:20:14 -0700 (PDT) Received: from smtp-2.mail.exa.net.uk (smtp-2.mail.exa.net.uk [82.219.5.2]) by out-13.mail.exa.net.uk (ExaSMTPD) with ESMTP id 180D71C003E for ; Sat, 26 Jul 2014 09:20:12 +0100 (BST) Received: from [10.59.1.160] (90.Red-80-38-79.staticIP.rima-tde.net [80.38.79.90]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 1287440260 for ; Sat, 26 Jul 2014 09:20:10 +0100 (BST) From: Thomas Mangin Content-Type: multipart/signed; boundary="Apple-Mail=_BB0F0591-E8AD-4D28-B7C7-A5CFEFB583D9"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Mao-Original-Outgoing-Id: 428055607.019891-b0f7d001b252527a7227c1c5553d8a53 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Message-Id: <1182CAE9-EFC9-4283-8A84-7A84FB7C25ED@exa-networks.co.uk> Date: Sat, 26 Jul 2014 09:20:07 +0100 To: idr wg X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AWPV1q4q27SlBBAgJ07uDGWTXK4 Subject: [Idr] partial bit set for AS4_PATH X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 08:20:21 -0000 --Apple-Mail=_BB0F0591-E8AD-4D28-B7C7-A5CFEFB583D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I have found recently that an implementation of BGP is encoding the = AS4_PATH attribute, setting the PARTIAL flag [1] I do not see anything in RFC 4893 about setting this flag. How an implementation should handle this case .. Is it an error or not ? Perhaps idr-draft-error-handling should have some wording about AS4_PATH = ? Thank you, Thomas [1] https://github.com/Exa-Networks/exabgp/issues/150 --Apple-Mail=_BB0F0591-E8AD-4D28-B7C7-A5CFEFB583D9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPTZLcACgkQA/52wvuLgaGGtACfcH+LqWt4N3NRkzwXhrvLTecj HwIAn24kuSEpWlbR/nFvEbofDII8Of0O =3s+h -----END PGP SIGNATURE----- --Apple-Mail=_BB0F0591-E8AD-4D28-B7C7-A5CFEFB583D9-- From nobody Sat Jul 26 03:58:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92E11A014D for ; Sat, 26 Jul 2014 03:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmRof1tasThf for ; Sat, 26 Jul 2014 03:58:41 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2691A0AC3 for ; Sat, 26 Jul 2014 03:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1359; q=dns/txt; s=iport; t=1406372321; x=1407581921; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ROuNMqhWNvT+AQD04hHiphFkp8dVWhyD4KZkkG9LjB8=; b=U35/cdvRUkzwf8uD76z8/ea64BVcpwUWa74rbkvvJ2e7SDLhfQs8ojSm GcY5PQysp8sFAf0AnaHLK0Tz/ZN37dg9pweLaxAvJnYM0z1j5BLy/8lqa vuDdrh7rjp9/wbion5mIv6LsoPUd07UwC1bRrkx6ZAdoBEAx3qJqTBCeF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAOmI01OtJV2U/2dsb2JhbABYgw5SVwTLV4dFAYEJFneEBAEBBDpPAgEINhAyJQIEARKIQg2+BxMEj1KESQWbSYtyiFmDSWyBRQ X-IronPort-AV: E=Sophos;i="5.01,735,1400025600"; d="scan'208";a="343039083" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP; 26 Jul 2014 10:58:39 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6QAwdot015678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Jul 2014 10:58:39 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Sat, 26 Jul 2014 05:58:39 -0500 From: "Saikat Ray (sairay)" To: Thomas Mangin , idr wg Thread-Topic: [Idr] partial bit set for AS4_PATH Thread-Index: AQHPqKp7Q3jdU3Hc502QJfOaYEygeJuyDkWA Date: Sat, 26 Jul 2014 10:58:39 +0000 Message-ID: References: <1182CAE9-EFC9-4283-8A84-7A84FB7C25ED@exa-networks.co.uk> In-Reply-To: <1182CAE9-EFC9-4283-8A84-7A84FB7C25ED@exa-networks.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.21.78.245] Content-Type: text/plain; charset="us-ascii" Content-ID: <22CAED3036A06040861ADF93E4ED4A33@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AZ0vUybB1A_6Lyti6X2y4IrYlsQ Subject: Re: [Idr] partial bit set for AS4_PATH X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 10:58:44 -0000 If there is a BGP speaker in the middle that doesn't understand AS4_PATH, you would get the attribute with the Partial bit set to 1. >From 4271: " If a path with an unrecognized transitive optional attribute is accepted and passed to other BGP peers, then the unrecognized transitive optional attribute of that path MUST be passed, along with the path, to other BGP peers with the Partial bit in the Attribute Flags octet set to 1. If a path with a recognized, transitive optional attribute is accepted and passed along to other BGP peers and the Partial bit in the Attribute Flags octet is set to 1 by some previous AS, it MUST NOT be set back to 0 by the current AS. Unrecognized non-transitive optional attributes MUST be quietly ignored and not passed along to other BGP peers. " On 7/26/14, 1:20 AM, "Thomas Mangin" wrote: >Hello, > >I have found recently that an implementation of BGP is encoding the >AS4_PATH attribute, setting the PARTIAL flag [1] >I do not see anything in RFC 4893 about setting this flag. > >How an implementation should handle this case .. Is it an error or not ? >Perhaps idr-draft-error-handling should have some wording about AS4_PATH ? > >Thank you, > >Thomas > >[1] https://github.com/Exa-Networks/exabgp/issues/150 > From nobody Sat Jul 26 05:22:32 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCF41B278D for ; Sat, 26 Jul 2014 05:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.345 X-Spam-Level: ** X-Spam-Status: No, score=2.345 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrF6J_z3ekpt for ; Sat, 26 Jul 2014 05:22:27 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD321B2793 for ; Sat, 26 Jul 2014 05:22:27 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: , "'Jon Mitchell'" References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722212735.GA11770@puck.nether.net> <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722222246.GB19654@puck.nether.net> <006a01cfa770$165cccf0$431666d0$@ndzh.com> <4395_1406306891_53D28A4A_4395_13255_1_9E32478DFA9976438E7A22F69B08FF9205DB3B@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <4395_1406306891_53D28A4A_4395_13255_1_9E32478DFA9976438E7A22F69B08FF9205DB3B@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Sat, 26 Jul 2014 08:22:12 -0400 Message-ID: <002301cfa8cc$3b16d2e0$b14478a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF7cNhsKZhrfXZn4jdnN6RtIb/8AQHzVLjSAbWg4sQCToKL9gGlL5UUAoJSJbacCb3ccA== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/8zqvPtQNcyyiDbzID-NXizBKcS8 Cc: 'Jeffrey Haas' , 'idr wg' , 'Robert Raszuk' Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 12:22:29 -0000 Stephane: Try looking into time-stamp when BGP packet gets put on the transmit queue. The purpose is that you avoid the costly inbound policy and outbound policy cycles. Let me know if it is just as complex. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com Sent: Friday, July 25, 2014 12:48 PM To: Susan Hares; 'Jon Mitchell' Cc: 'Jeffrey Haas'; 'idr wg'; 'Robert Raszuk' Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp Susan, Thanks for pointing this. We will investigate the possibility to do it from an implementation point of view. Putting timestamp at receive side is easy, at transmit side it may be more complex and really implementation dependant as we would need to try to have a consensus at which part of the sending process, we would need to put the timestamp (Update formatting, Route Queueing for the peer group ...) Best Regards, Stephane -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, July 24, 2014 14:50 To: 'Jon Mitchell'; LITKOWSKI Stephane SCE/IBNF Cc: 'Jeffrey Haas'; 'idr wg'; 'Robert Raszuk' Subject: RE: [Idr] draft-litkowski-idr-bgp-timestamp Jon and Stephan: Based on work with vendor boxes for the BMWG BGP work - I would recommend you timestamp the BGP trace NLRI as you leave the BGP Peer and as you receive it. Otherwise, you run into the data flow patterns the trace NLRI is included in causing variation in your flows. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jon Mitchell Sent: Tuesday, July 22, 2014 6:23 PM To: stephane.litkowski@orange.com Cc: Jeffrey Haas; idr wg; Robert Raszuk Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp On 22/07/14 22:00 +0000, stephane.litkowski@orange.com wrote: > Hi Jon, > > Thanks for your comment. > Regarding packing, depending of the address family you are trying to monitor, current packing may be low or high. In case where existing packing is low, it does not change anything. In case packing is high, yes I agree that the processing of the update is a bit changed and my beacon would be sent may be faster. Packing is introducing slight delay but I don't think delay introduced by packing is a major component expect if an implementation get stucks in packing (it may happen but I never seen it). IMHO, I don't think this is a critical point but I'm open to other opinions. > > Now for BMP, we are not targeting to monitor our beacons on all PEs, > just a subset of representative. > Moreover it's not only a question about number of sessions, it's a question of ordering the information retrieved. If you consider using BMP , the tool will peer with selected PEs, but also "transit BGP Speakers" (ASBRs, RRs ...). When the tool will receive the timestamp information (if implementation of BMP supports timestamp), it requires to sort and reorganize the received information based on the knowledge of the topology : you cannot just sort by timestamp, you have to find relationship between BGP Speakers (information from BMP and topology) and combine them to recreate our timestamp vector. BGP transport permits to create automatically this timestamp vector without having to implement a complex machinery in the tool. But BMP can be used at the selected PE to the tool to retrieve timestamp vectors. > Stephane - yes, I think this second point is the real object of the draft (correct me if I'm wrong). Offline correlation engines are complicated to implement and/or expensive, although commercially available. Getting the timestamp data seems not to be the real issue here at all (via BMP or other mechanisms a local implementation can provide). Maybe this point should be more clear in the intro and text. Jon _______________________________________________ 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 From nobody Sat Jul 26 07:22:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE471A02DD for ; Sat, 26 Jul 2014 07:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3iodIMZtsmv for ; Sat, 26 Jul 2014 07:22:46 -0700 (PDT) Received: from out-13.mail.exa.net.uk (out-13.mail.exa.net.uk [82.219.4.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0AF81A0278 for ; Sat, 26 Jul 2014 07:22:45 -0700 (PDT) Received: from smtp-1.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-13.mail.exa.net.uk (ExaSMTPD) with ESMTP id 02C0B1C003E; Sat, 26 Jul 2014 15:22:43 +0100 (BST) Received: from [192.168.1.33] (88.Red-83-32-114.dynamicIP.rima-tde.net [83.32.114.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id D4CB722115E; Sat, 26 Jul 2014 15:22:40 +0100 (BST) Content-Type: multipart/signed; boundary="Apple-Mail=_86DEF740-A183-4778-AE13-4E613E51B484"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas Mangin In-Reply-To: Date: Sat, 26 Jul 2014 15:22:35 +0100 X-Mao-Original-Outgoing-Id: 428077354.757445-82adb2fd1d89c60552bdf493bd025371 Message-Id: References: <1182CAE9-EFC9-4283-8A84-7A84FB7C25ED@exa-networks.co.uk> To: sairay@cisco.com X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/idr/MuhFgxU1Q2Yo-bkhrVKjexdM57o Cc: idr wg Subject: Re: [Idr] partial bit set for AS4_PATH X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 14:22:48 -0000 --Apple-Mail=_86DEF740-A183-4778-AE13-4E613E51B484 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Saikat, Thank you - I should have seen this - sorry for the noise on-list. Thomas On 26 Jul 2014, at 11:58, Saikat Ray (sairay) wrote: > If there is a BGP speaker in the middle that doesn't understand AS4_PATH, > you would get the attribute with the Partial bit set to 1. > > From 4271: > > " If a > path with an unrecognized transitive optional attribute is accepted > and passed to other BGP peers, then the unrecognized transitive > optional attribute of that path MUST be passed, along with the path, > to other BGP peers with the Partial bit in the Attribute Flags octet > set to 1. If a path with a recognized, transitive optional attribute > is accepted and passed along to other BGP peers and the Partial bit > in the Attribute Flags octet is set to 1 by some previous AS, it MUST > NOT be set back to 0 by the current AS. Unrecognized non-transitive > optional attributes MUST be quietly ignored and not passed along to > other BGP peers. > " > > On 7/26/14, 1:20 AM, "Thomas Mangin" > wrote: > >> Hello, >> >> I have found recently that an implementation of BGP is encoding the >> AS4_PATH attribute, setting the PARTIAL flag [1] >> I do not see anything in RFC 4893 about setting this flag. >> >> How an implementation should handle this case .. Is it an error or not ? >> Perhaps idr-draft-error-handling should have some wording about AS4_PATH ? >> >> Thank you, >> >> Thomas >> >> [1] https://github.com/Exa-Networks/exabgp/issues/150 >> > > --Apple-Mail=_86DEF740-A183-4778-AE13-4E613E51B484 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPTuaoACgkQA/52wvuLgaFUuACgg7UBmx/oEpxOJl5ySo7Mk8TE oRIAoKwPbjNbRnaxANyJnZcpGRquxERW =pgZ3 -----END PGP SIGNATURE----- --Apple-Mail=_86DEF740-A183-4778-AE13-4E613E51B484-- From nobody Sun Jul 27 18:16:11 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E691B27D5; Sun, 27 Jul 2014 18:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5lu69aqbWwS; Sun, 27 Jul 2014 18:16:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2D61B27D3; Sun, 27 Jul 2014 18:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6517; q=dns/txt; s=iport; t=1406510168; x=1407719768; h=from:to:subject:date:message-id:mime-version; bh=gQCMnGHIXMkSQwdcEEEej+KlQ5KHY8BfLlaeSVhfVFg=; b=iQyoypvE2TyFhMqQu7D7VZqww5TLhcrWAEsth1megNB0tpFp9FnIhpbg jOs4VOG/Gu5s58PulVRetmkeEWNLF+3MftR881S0IDE5EeDu1BFCZmiNo Fr8nZCjOllh0xvrO9POjlmFSFxrvZOIhyH1IhdoLCSPg1K72K78sYwbH0 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAP2j1VOtJV2Y/2dsb2JhbABZgkdHUlvTIwGBERZ3hAUBBC1FGQEqViYBBAEaE4gnvRUXjxuDZ4EbBbAYg0mCMQ X-IronPort-AV: E=Sophos;i="5.01,745,1400025600"; d="scan'208,217";a="343238857" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jul 2014 01:16:07 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6S1G671017656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 01:16:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Sun, 27 Jul 2014 20:16:06 -0500 From: "Jakob Heitz (jheitz)" To: IETF SIDR , "Sriram, Kotikalapudi" , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQ== Date: Mon, 28 Jul 2014 01:16:06 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.66.206] Content-Type: multipart/alternative; boundary="_000_075DE01702BBC249BE1357EFD20DCFE50CF04B96xmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/RhkwkAK0es550-UOpHY0jD4I6Wg Subject: [Idr] draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 01:16:09 -0000 --_000_075DE01702BBC249BE1357EFD20DCFE50CF04B96xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In GROW, at the mike, I proposed another solution: Add a new attribute that means "this route may be advertised up". This attribute must be signed by the originator of the route. Add a second attribute that means "The first attribute was added" This attribute must be included in the BGPSEC signature. If an AS asserts that the route can no longer be advertised up, it simply removes the first attribute along with its signature. Since the first attribute must be signed by the originator, no one else can= add it back. Now, an AS that considers itself a provider of the advertised route to the = peer from which it received the advertisement can filter on the presence of= the second attribute and the lack of the first to prevent the leak. The advantage of this solution is that it will not expose the customer-prov= ider relationship to any customers. --Jakob --_000_075DE01702BBC249BE1357EFD20DCFE50CF04B96xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In GROW, at the mike, I proposed another s= olution:

 

Add a new attribute that means “this= route may be advertised up”.

This attribute must be signed by the origi= nator of the route.

 

Add a second attribute that means “T= he first attribute was added”

This attribute must be included in the BGP= SEC signature.

 

If an AS asserts that the route can no lon= ger be advertised up,

it simply removes the first attribute alon= g with its signature.

 

Since the first attribute must be signed b= y the originator, no one else can add it back.

 

Now, an AS that considers itself a provide= r of the advertised route to the peer from which it received the advertisem= ent can filter on the presence of the second attribute and the lack of the first to prevent the leak.

 

The advantage of this solution is that it = will not expose the customer-provider relationship to any customers.

 

--Jakob

 

--_000_075DE01702BBC249BE1357EFD20DCFE50CF04B96xmbalnx02ciscoc_-- From nobody Mon Jul 28 02:55:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC9A1A0380 for ; Mon, 28 Jul 2014 02:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPacQZqayH0z for ; Mon, 28 Jul 2014 02:55:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A7C1A0377 for ; Mon, 28 Jul 2014 02:55:28 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id E422F264F94; Mon, 28 Jul 2014 11:55:26 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id BD98935C07E; Mon, 28 Jul 2014 11:55:26 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 28 Jul 2014 11:55:26 +0200 From: To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 Thread-Index: AQHPpeVFSc+l4GGiykePxh3Y07AM+5uxkjgg Date: Mon, 28 Jul 2014 09:55:25 +0000 Message-ID: <10494_1406541326_53D61E0E_10494_65_2_53C29892C857584299CBF5D05346208A0719229E@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> In-Reply-To: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ksLaUciOkWjHiyY2mYL0Fv9Uc1s Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 09:55:32 -0000 Hi all, > The authors have requested IDR adopt draft-vandevelde-idr-remote-next- > hop-06 as a working group document. I'm afraid that, as per my current understanding of the draft, I do not thi= nk that this version of the draft is ready for WG adoption. I don't think that the document is mature enough for early allocation. Please find below some more detailed comments. Regards, Bruno 1) Major My understanding is that this attribute can be attached to any NLRI of AFI/= SAFI, including ones used in the Internet and VPN. I think that this docume= nt should document what are the potential (negative) impacts of attaching t= his attribute to such route, either by an originator or by someone in trans= it. In particular in term of security and routing consistency. (Yes, I've r= ead the security section, more on this latter). In particular for Internet routing, it looks like this open the possibility= for the forwarding path to be (arbitrary?) different from the control plan= e path (AS PATH). - If so, how do you detect loops? (as the AS PATH won't help). In some part= of the document, you are referring to checking PATH. Do you mean the PATH = of the NLRI having this attribute, or the PATH of the NLRI used to route to= ward the remote_next-hop, or both? Do you check that both originator ASes a= re the same, or it does not matter? - what about routing policy violation? e.g. peer A advertise a route to pee= r B and so pretend that it will route the traffic toward that destination. = While it could attach a remote NH pointing to a transit provider of B. Henc= e B believes the NRLI routes to a peer while in fact it route to a transit. For VPN/labelled routes, the "attached" label is local to the BGP NH. Now i= f someone attaches a remote NH attribute, what happen exactly? The label tr= affic is sent to the remote NH? Seems to open the ability for VPN breach (e= specially for AS using 6PE as Internet routes are labeled and could possibl= y redirect to an IPv6 VPN). 1.2) security consideration "This technology could be used as technology as man in the middle attack, = however with existing RPKI validation for BGP that risk is reduced." What do you mean by "existing"? Do you mean that a full deployement of RPKI= validation must be performed before deploying remote NH? Or if partial dep= loyment is enough, how partial? Do you mean origin validation or as path va= lidation or route leaking detection...? " The distribution of Tunnel end-point address information can result in potential DoS attacks if the information is sent by malicious organisations. Therefore is it strongly recommended to install traffic filters, IDSs and IPSs at the perimeter of the tunneled network infrastructure." Could you please elaborate on what you mean with "perimeter of the tunneled= network infrastructure"? In particular in the case where such RNH attribut= e is attached to an Internet or VPN route? "It is possible to inject a rogue BGP Remote-Next-Hop attribute to an NLRI resulting in Monkey-In-The-Middle attack (MITM). To avoid this type of MITM attack, it is strongly recommended to use a technology a mechanism to verify that for NLRI it is the expected BGP Remote-Next- Hop. We anticipate that this can be done with an expansion of RPKI- Based origin validation, see [I-D.ietf-sidr-pfx-validate]." I read that Remote NH MUST NOT be used unless the expansion of RPKI is spec= ified, implemented and deployed. The draft is more than 2 years old and I d= on't see a pointer toward this extension. What is the status? How am I supp= ose to have an opinion of how effective is the security couter measure? "This does not avoid the fact that rogue AS numbers may be inserted or injected into the AS-Path. To achieve protection against that threat BGP Path Validation should be used, see [I-D.ietf-sidr-bgpsec-overview]." Do you mean that a full deployement of BGP sec must be performed before dep= loying remote NH? Or if partial deployment is enough, how partial? Do you m= ean as path validation or route leaking detection...? "This proposal may introduce privacy issues, however with BGP security mechanisms in place they should be prevented." Can you elaborate on those privacy issues, what BGP security mechanism you = are referring to, and how do the address the privacy issues. Bottom line: I think the security section needs more work and discussion on= the mailing list. I'm not convinced that remote NH is deployable (unless i= n private closed controlled environment. In which case, I would call for a = non transitive attribute, attribute filtering by default (inband & outband)) 2) Medium 2.1) IPv6 dual homing - The description of the solution lacks details. Could you possibly add a n= etwork topology, with the involved routes? In particular how does the provi= der learn the backup/alternate route. (advertising it in the Internet is th= e most simple but would require de-aggregating the prefix which contradicts= the goal; alternatively advertising directly between ASBR remove the need = for Remote Next Hop). - Many IETF solutions have been proposed for IPv6 multi-homing. It would be= interesting to cite them and state why this proposition is better. (I gues= s that LISP may be applicable if so it may be interesting to present your c= omparison with LISP in the LISP WG). - "[In the Internet] Each AS prefers to only announce a superset of all its= assigned IPv6 prefixes, unlike IPv4 where the AS announced the end-users a= ssigned prefix" - On my side, I don't see much difference between IPv4 and IPv6.=20 - "prefers" is a debatable choice of word (as some/most ASes don't care t= hat much; and what would be their incentive for this preference?). 2.2 & 2.3) I'm not familiar with the use case but its scope seems to be within a Servi= ce Provider. In such context, wouldn't be possible to use the normal BGP Ne= xt Hop? 2.2) section 6 This section proposes a BGP extension, but does not specify it. How is the = WG supposed to have an opinion on it? Seems a kind of blank check. Seems re= lated to security so looks important to me. 2.3) inter WG coordination "The BGP Remote-Next-Hop extension allows signaling tunnel encapsulations needed to build and dynamically create an overlay tunneled network with traffic isolation and virtual private networks" In short: Remote Next-Hop is a BGP based IP VPN solution. Shouldn't the L3 VPN be involved in WG adoption? Has it been presented in L= 3 VPN? (haven't seen it in the agenda of the 4 latest meeting.) What has be= en their feedback? Shouldn't we delay adoption until the new BESS WG is formed? " BGP Enabled = ServiceS (L3VPN, L2VPN, NVO3)"=20 2.4) transitive attribute "This document defines a new BGP transitive attribute" Does it really have to be transitive? At this point, it's not clear from th= e use cases. A non transitive attribute would be easier to deal with from a= security standpoint. 3) Low 3.1) could you please add a section about error handling? (what is an error= , how it must be handled) Indeed, this is not a simple attribute hence the = case of error may not be simple either. 3.2) MPLSoUDP What about adding the tunnel type MPLS over UDP? > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder > Sent:= Tuesday, July 22, 2014 3:43 PM >=20 > Folks, >=20 > The authors have requested IDR adopt draft-vandevelde-idr-remote-next- > hop-06 as a working group document. >=20 > http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ >=20 > Please send any comments to the list by August 8. >=20 > In addition to commenting on adoption of the work, you may want to > comment on whether the draft is mature enough for us to consider early > allocation of the path attribute code point. As a reminder, RFC 7120 requ= ires > that for early allocation, "the specifications of these code points must = be > stable". (Section 2.c.) The chairs and ADs also have to "judge that there= is > sufficient interest in the community for early (pre-RFC) implementation a= nd > deployment". (Section 2.d.) >=20 > It's fine to be in favor of WG adoption but opposed to early allocation a= t this > time, or in favor of both, or against both. Being against adoption but in= favor > of allocation would be a bit weird. :-) >=20 > Thanks, >=20 > --John >=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 Mon Jul 28 06:45:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE131ABB2B for ; Mon, 28 Jul 2014 06:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4TbuDv769lV for ; Mon, 28 Jul 2014 06:45:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47B61A01CB for ; Mon, 28 Jul 2014 06:45:02 -0700 (PDT) Received: from BY2PR05CA009.namprd05.prod.outlook.com (10.242.32.39) by BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 13:45:00 +0000 Received: from BL2FFO11FD053.protection.gbl (2a01:111:f400:7c09::162) by BY2PR05CA009.outlook.office365.com (2a01:111:e400:2c2a::39) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Mon, 28 Jul 2014 13:44:59 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD053.mail.protection.outlook.com (10.173.161.181) with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Mon, 28 Jul 2014 13:44:59 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 28 Jul 2014 06:44:54 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s6SDiqn32062; Mon, 28 Jul 2014 06:44:52 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201407281344.s6SDiqn32062@magenta.juniper.net> To: "idr@ietf. org" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42219.1406555092.1@juniper.net> Date: Mon, 28 Jul 2014 06:44:52 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(189002)(199002)(106466001)(81156004)(85306003)(79102001)(21056001)(74662001)(74502001)(31966008)(16796002)(102836001)(105596002)(95666004)(23726002)(77982001)(81542001)(97736001)(68736004)(97756001)(80022001)(50986999)(54356999)(46406003)(99396002)(64706001)(47776003)(20776003)(76482001)(84676001)(46102001)(69596002)(92726001)(6806004)(83072002)(110136001)(4396001)(107046002)(92566001)(81342001)(85852003)(87936001)(83322001)(44976005)(50466002)(86362001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB721; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0286D7B531 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/xWio352uvjARkWNiwDNRvmrRCdU Cc: yakov@juniper.net Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:45:04 -0000 Hi, > The authors have requested IDR adopt draft-vandevelde-idr-remote-next- > hop-06 as a working group document. >From section 5.3 of the draft: With usage of the BGP-remote-Next-Hop attribute the service provider can tunnel that packet towards an alternate BGP Remote-Next-Hop at the end-users alternate provider and restore the network connectivity even though the local link towards the end-user is broken. Consider the following example: S--CE1---PE1---ISP1-----PE2---CE2----| | | | | ISP2-----PE3---CE3----D where site D is multihomed to ISP1 and ISP2. Would PE2 attach the Remote Next Hop indicating PE3 as an alternative next hop, and PE3 attach the Remote Next Hop indicating PE2 as an alternative next hop ? If yes, then how does PE2 know that PE3 is an alternative next hop ? Ditto for PE2. Furthermore, I am not sure why in the multi-homing scenario described above there is a need for the Remote Next Hop attribute. E.g., take a look at rfc2260 or at draft-bonica-v6-multihome-03 - both can be used to provide multi-homing, and neither of these use the Remote Next Hop attribute. Yakov. From nobody Mon Jul 28 12:18:55 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E251A8BB1 for ; Mon, 28 Jul 2014 12:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9i_n7Qc5Gwe for ; Mon, 28 Jul 2014 12:18:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CBAA61A0AF3 for ; Mon, 28 Jul 2014 12:18:52 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 357DEC3DF; Mon, 28 Jul 2014 15:18:52 -0400 (EDT) Date: Mon, 28 Jul 2014 15:18:52 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140728191852.GC31282@pfrc> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.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: http://mailarchive.ietf.org/arch/msg/idr/b6XNsR8NFJdIjzPkg6_85BhXgvc Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:18:54 -0000 [choosing this one message since I think it hits the core of the discussion] Robert, On Tue, Jul 22, 2014 at 05:01:05PM +0200, Robert Raszuk wrote: > Well RT filter should be installed on all peers it has been received from > regardless what type of RTC route it is. Removing the filter from the peer > only based on particular best path chosen seems a bit wrong implementation > to me :) > > The below section: > > 2. [RFC4684] Section 3.2 : > > "As indicated above, the inter-AS VPN route distribution graph, for a > given route-target, is constructed by creating a directed arc on the > inverse direction of received Route Target membership UPDATEs > containing an NLRI of the form {origin-as#, route-target}. > > refers to inter-as behaviour not local RT installation on any BGP speaker > within the AS. > > So if this is your main issue then perhaps we have a bug .... The issue is not that we're limiting the distribution of the RT-C routes on any BGP speaker. They're being installed everywhere that you'd expect. We're running into another related pieces. Also from RFC 4684: [Section 3.1] : Using RT membership information that includes both route-target and : originator AS number allows BGP speakers to use standard path : selection rules concerning as-path length (and other policy : mechanisms) to prune duplicate paths in the RT membership information : flooding graph, while maintaining the information required to reach : all autonomous systems advertising the Route Target. So, standard route selection is occuring. The question can be framed by where the pruning is done: Only at e-bgp edges or in the i-bgp mesh. In JUNOS, this is currently happening everywhere, including i-bgp. This provides some consistency with the idea that the number of paths that a given VPN RT is distributed along is AS-wide. (Default path count is 1, but can be adjusted via knob.) In the case where the pruning is enforced only at e-bgp edges, then it is much more difficult to enforce AS-wide path pruning. A simplified example: +---+ | |--- A | | / \ | Z |--B---C---D | | / | |/ +---+ Z is in an external AS. A..F are our AS. Presume each internal link has an identical IGP cost and that the BGP and forwarding topologies are congruent. A is single-homed to Z. B is dual-homed to Z. The top link to Z is best. C is a route reflector for our AS. The AS-wide path count is set to 1. For some RT-C distributed by Z to our AS: At A, routes that are local to A will obviously be distributed. At B, routes that are local to B will obviously be distributed to the top link. At C, we have two paths to Z. Since the paths are otherwise equal, we tie-break on router-id and choose A as active. For VPN route distribution purposes, we may either: 1. Always distribute along the i-bgp mesh and not prune. 2. Limit our paths, perhaps only choosing the best path (A). The implications of this are: 1 - We realize no savings in our i-bgp with regard to the path state we're keeping. Routes go everywhere. 2 - We limit our paths and don't use memory for what are otherwise duplicate routes from Z's perspective. Observe also that B can make a similar choice with regard to it's internal link with A. The implications of the above at B are: 1 - A will have a consistent view of the VPN routes and thus Z at A will have all routes present. -or- 2 - VPN routes that may be local to B will only be distributed to Z at B. While this consistency issue is quirky, the presumption is that Z is able to be internally consistent due to its own iBGP rules being followed. ------ The implications of this behavioral difference aren't catastrophic, but are worth clarifying. If you have both behaviors present, I'm not able to come up with a scenario where this is a problem. The clarification would come simply as to where the pruning occurs. I'm personally a fan of consering internal resources. Some amount of redundancy for fast failover can happen simply by tuning the number of paths that you prune to. But for Stephane's original scenario, the desire is to stop treating the named ASes for pruning purposes at all. And I think that applies even for the case where pruning happens even at ebgp. For example, an even terser form of Stephane's issue: +---+ | |\ | | \ | Z |--A---B | | / | |/ +---+ When A is a PE and Z is a single AS, pruning to the single path is not a problem. But if Z is really: +---+ |Z1 |\ +---+ \ |Z2 |--A---B +---+ / |Z3 |/ +---+ Then we still have the issue. -- Jeff From nobody Mon Jul 28 12:44:19 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203721A04E7 for ; Mon, 28 Jul 2014 12:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWKKYrcOW5_T for ; Mon, 28 Jul 2014 12:44:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 73AE41A03F0 for ; Mon, 28 Jul 2014 12:44:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 298BEC3DF; Mon, 28 Jul 2014 15:44:16 -0400 (EDT) Date: Mon, 28 Jul 2014 15:44:16 -0400 From: Jeffrey Haas To: Jon Mitchell Message-ID: <20140728194416.GD31282@pfrc> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722212735.GA11770@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140722212735.GA11770@puck.nether.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/DEHE3Q_bt47WOYULNcev47E509o Cc: Jeffrey Haas , Robert Raszuk , idr wg Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:44:17 -0000 Jon, On Tue, Jul 22, 2014 at 05:27:35PM -0400, Jon Mitchell wrote: > I'm supportive of your goal, however after the presentation I'm still a > bit unclear on the need for the BGP extension to propogate the timestamp > information. As was brought up by Saikat today in the WG meeting, if > update packing is different for this prefix due to the timestamp attribute > then it loses some of it's value for providing an accurate view of your > end to end BGP propogation time. This is definitely true. However, this would also be true of any other in-bgp mechanism. This then asks the question of why not use an outside of BGP mechanism. > Someone suggested BMP, it appears it > already supports this option in paragraph 3 of Section 5 of that draft. > The justification given that instrumenting sessions (BMP/BGP/or other > export mechanism for the data) to all routers versus getting the > information from egress PE only does not seem to be a large concern if > monitoring this route propogation is of importance to the operator. And yet, it's a large amount of data. The requests we've had in terms of tuning what BMP supplies has been mostly with respect to limiting the amount of data that is available in the stream. Being able to watch for the probe prefix only at the end station accomplishes the main goal. Certainly, an alternative could be to have a specific BMP session only for the purposes of watching for the probe routes but this still would involve catching the routes at each collector along the path. Another observation that had been made during the discussion of the initial draft version was simply the amount of transient noise at the intermediate nodes in your reflector mesh. The "ping pong" of convergence adds noise that you have to ignore. And honestly, we don't care about the multiple hits we'd get at a given device - it's not helpful data unless you were trying to measure reflector convergence artifacts. > Specifying or identifying which prefixes are > monitored (the timestamp is collected and exported for) seems also like > something that can be handled by the local implementation based on a > community or other attributes. With exactly the same property you note above about breaking the route packing. :-) -- Jeff From nobody Mon Jul 28 12:45:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D151B2820 for ; Mon, 28 Jul 2014 12:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1QqQAmkRuOC for ; Mon, 28 Jul 2014 12:45:20 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A2D1A034F for ; Mon, 28 Jul 2014 12:45:20 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id h15so4216479igd.5 for ; Mon, 28 Jul 2014 12:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rRU98DwcW4wYcKic0E0Vd3RT1RrYchQgClDyIMQqibg=; b=l4s/vAC54co7jCUeGzFBHygDW5iKxUQtQ6zzvKZk3U3X7rPsikTbN69sCDEFLyWpvN uP2Qsr68tnBWJg1ijusm+RIRq6hyrj3w5W/GZ52ASuMs0VrgWL3WZHwRkMhsvDjKiu+D 3wFxrVWuNrbRhnOu94QC5XoV3q0tLvSQaHAK0z/dt1tCc2CvIxp7+wR2RbavlroayoxB 57I51KsvvKN3ASCP/ICSgTKXeCPVj3kv3NB7hGtkwFfOxwSF55jaWSOi4WYGZfTwDXyF /pmTZTxfkOf6+U5UZcLNkhqEO+Ulol15Jh/oXMyZ5qJZWexD0chsZujFetO4ZGrzANEV bvEA== MIME-Version: 1.0 X-Received: by 10.42.64.77 with SMTP id f13mr14127904ici.72.1406576720097; Mon, 28 Jul 2014 12:45:20 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Mon, 28 Jul 2014 12:45:19 -0700 (PDT) In-Reply-To: <20140728191852.GC31282@pfrc> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140728191852.GC31282@pfrc> Date: Mon, 28 Jul 2014 21:45:19 +0200 X-Google-Sender-Auth: e6G33XgqbHGivL-xDgCktwu3ycA Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: multipart/alternative; boundary=90e6ba614c64c0365c04ff4629c5 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/lb-bTeXnxmtRxo1g_erlOrlQsis Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:45:22 -0000 --90e6ba614c64c0365c04ff4629c5 Content-Type: text/plain; charset=UTF-8 Jeff, To me path prooning means you select best from N and advertise single path out. However path prooning does not mean you do not install received routes/filters from either IBGP or EBGP peers. Those should be IMO always installed even if they are not best paths. You seems to be equating those two which IMHO is not rigth with filters like RTC (or flow spec for that matter). Best, R. On Mon, Jul 28, 2014 at 9:18 PM, Jeffrey Haas wrote: > [choosing this one message since I think it hits the core of the > discussion] > > Robert, > > On Tue, Jul 22, 2014 at 05:01:05PM +0200, Robert Raszuk wrote: > > Well RT filter should be installed on all peers it has been received from > > regardless what type of RTC route it is. Removing the filter from the > peer > > only based on particular best path chosen seems a bit wrong > implementation > > to me :) > > > > The below section: > > > > 2. [RFC4684] Section 3.2 : > > > > "As indicated above, the inter-AS VPN route distribution graph, for a > > given route-target, is constructed by creating a directed arc on the > > inverse direction of received Route Target membership UPDATEs > > containing an NLRI of the form {origin-as#, route-target}. > > > > refers to inter-as behaviour not local RT installation on any BGP speaker > > within the AS. > > > > So if this is your main issue then perhaps we have a bug .... > > The issue is not that we're limiting the distribution of the RT-C routes on > any BGP speaker. They're being installed everywhere that you'd expect. > We're running into another related pieces. Also from RFC 4684: > > [Section 3.1] > : Using RT membership information that includes both route-target and > : originator AS number allows BGP speakers to use standard path > : selection rules concerning as-path length (and other policy > : mechanisms) to prune duplicate paths in the RT membership information > : flooding graph, while maintaining the information required to reach > : all autonomous systems advertising the Route Target. > > So, standard route selection is occuring. The question can be framed by > where the pruning is done: Only at e-bgp edges or in the i-bgp mesh. In > JUNOS, this is currently happening everywhere, including i-bgp. This > provides some consistency with the idea that the number of paths that a > given VPN RT is distributed along is AS-wide. (Default path count is 1, > but > can be adjusted via knob.) > > In the case where the pruning is enforced only at e-bgp edges, then it is > much more difficult to enforce AS-wide path pruning. A simplified example: > > +---+ > | |--- A > | | / \ > | Z |--B---C---D > | | / > | |/ > +---+ > > Z is in an external AS. A..F are our AS. > Presume each internal link has an identical IGP cost and that the BGP and > forwarding topologies are congruent. > > A is single-homed to Z. > B is dual-homed to Z. The top link to Z is best. > C is a route reflector for our AS. > > The AS-wide path count is set to 1. > > > For some RT-C distributed by Z to our AS: > At A, routes that are local to A will obviously be distributed. > At B, routes that are local to B will obviously be distributed to the top > link. > > At C, we have two paths to Z. Since the paths are otherwise equal, we > tie-break on router-id and choose A as active. For VPN route distribution > purposes, we may either: > 1. Always distribute along the i-bgp mesh and not prune. > 2. Limit our paths, perhaps only choosing the best path (A). > > The implications of this are: > 1 - We realize no savings in our i-bgp with regard to the path state we're > keeping. Routes go everywhere. > 2 - We limit our paths and don't use memory for what are otherwise > duplicate routes from Z's perspective. > > Observe also that B can make a similar choice with regard to it's internal > link with A. The implications of the above at B are: > 1 - A will have a consistent view of the VPN routes and thus Z at A will > have all routes present. > -or- > 2 - VPN routes that may be local to B will only be distributed to Z at B. > > While this consistency issue is quirky, the presumption is that Z is able > to > be internally consistent due to its own iBGP rules being followed. > > ------ > > The implications of this behavioral difference aren't catastrophic, but are > worth clarifying. If you have both behaviors present, I'm not able to come > up with a scenario where this is a problem. The clarification would come > simply as to where the pruning occurs. > > I'm personally a fan of consering internal resources. Some amount of > redundancy for fast failover can happen simply by tuning the number of > paths > that you prune to. But for Stephane's original scenario, the desire is to > stop treating the named ASes for pruning purposes at all. And I think that > applies even for the case where pruning happens even at ebgp. For example, > an even terser form of Stephane's issue: > > +---+ > | |\ > | | \ > | Z |--A---B > | | / > | |/ > +---+ > > When A is a PE and Z is a single AS, pruning to the single path is not a > problem. But if Z is really: > > +---+ > |Z1 |\ > +---+ \ > |Z2 |--A---B > +---+ / > |Z3 |/ > +---+ > > Then we still have the issue. > > -- Jeff > --90e6ba614c64c0365c04ff4629c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff,

To me path prooning means you select best from N and advertise single path = out.=C2=A0

However path prooning does not mean you do not install received routes/filt= ers from either IBGP or EBGP peers. Those should be IMO always installed ev= en if they are not best paths.=C2=A0

You seems to be equating those two which IMHO is no= t rigth with filters like RTC (or flow spec for that matter).=C2=A0

Best,
R.




=
On Mon, Jul 28, 2014 at 9:18 PM, Jeffrey Haas <jha= as@pfrc.org> wrote:
[choosing this one message since I think it = hits the core of the discussion]

Robert,

On Tue, Jul 22, 2014 at 05:01:05PM +0200, Robert Raszuk wrote:
> Well RT filter should be installed on all peers it has been received f= rom
> regardless what type of RTC route it is. Removing the filter from the = peer
> only based on particular best path chosen seems a bit wrong implementa= tion
> to me :)
>
> The below section:
>
> 2. =C2=A0[RFC4684] Section 3.2 :
>
> =C2=A0 =C2=A0 "As indicated above, the inter-AS VPN route distrib= ution graph, for a
> =C2=A0 =C2=A0given route-target, is constructed by creating a directed= arc on the
> =C2=A0 =C2=A0inverse direction of received Route Target membership UPD= ATEs
> =C2=A0 =C2=A0containing an NLRI of the form {origin-as#, route-target}= .
>
> refers to inter-as behaviour not local RT installation on any BGP spea= ker
> within the AS.
>
> So if this is your main issue then perhaps we have a bug ....

The issue is not that we're limiting the distribution of the RT-C= routes on
any BGP speaker. =C2=A0They're being installed everywhere that you'= d expect.
We're running into another related pieces. =C2=A0Also from RFC 4684:
[Section 3.1]
: =C2=A0Using RT membership information that includes both route-target and=
: =C2=A0originator AS number allows BGP speakers to use standard path
: =C2=A0selection rules concerning as-path length (and other policy
: =C2=A0mechanisms) to prune duplicate paths in the RT membership informati= on
: =C2=A0flooding graph, while maintaining the information required to reach=
: =C2=A0all autonomous systems advertising the Route Target.

So, standard route selection is occuring. =C2=A0The question can be framed = by
where the pruning is done: Only at e-bgp edges or in the i-bgp mesh. =C2=A0= In
JUNOS, this is currently happening everywhere, including i-bgp. =C2=A0This<= br> provides some consistency with the idea that the number of paths that a
given VPN RT is distributed along is AS-wide. =C2=A0(Default path count is = 1, but
can be adjusted via knob.)

In the case where the pruning is enforced only at e-bgp edges, then it is much more difficult to enforce AS-wide path pruning. =C2=A0A simplified exa= mple:

+---+
| =C2=A0 |--- A
| =C2=A0 | =C2=A0 / \
| Z |--B---C---D
| =C2=A0 | /
| =C2=A0 |/
+---+

Z is in an external AS. =C2=A0A..F are our AS.
Presume each internal link has an identical IGP cost and that the BGP and forwarding topologies are congruent.

A is single-homed to Z.
B is dual-homed to Z. The top link to Z is best.
C is a route reflector for our AS.

The AS-wide path count is set to 1.


For some RT-C distributed by Z to our AS:
At A, routes that are local to A will obviously be distributed.
At B, routes that are local to B will obviously be distributed to the top l= ink.

At C, we have two paths to Z. =C2=A0Since the paths are otherwise equal, we=
tie-break on router-id and choose A as active. =C2=A0For VPN route distribu= tion
purposes, we may either:
1. Always distribute along the i-bgp mesh and not prune.
2. Limit our paths, perhaps only choosing the best path (A).

The implications of this are:
1 - We realize no savings in our i-bgp with regard to the path state we'= ;re
=C2=A0 =C2=A0 keeping. =C2=A0Routes go everywhere.
2 - We limit our paths and don't use memory for what are otherwise
=C2=A0 =C2=A0 duplicate routes from Z's perspective.

Observe also that B can make a similar choice with regard to it's inter= nal
link with A. =C2=A0The implications of the above at B are:
1 - A will have a consistent view of the VPN routes and thus Z at A will =C2=A0 =C2=A0 have all routes present.
-or-
2 - VPN routes that may be local to B will only be distributed to Z at B.
While this consistency issue is quirky, the presumption is that Z is able t= o
be internally consistent due to its own iBGP rules being followed.

------

The implications of this behavioral difference aren't catastrophic, but= are
worth clarifying. =C2=A0If you have both behaviors present, I'm not abl= e to come
up with a scenario where this is a problem. =C2=A0The clarification would c= ome
simply as to where the pruning occurs.

I'm personally a fan of consering internal resources. =C2=A0Some amount= of
redundancy for fast failover can happen simply by tuning the number of path= s
that you prune to. =C2=A0But for Stephane's original scenario, the desi= re is to
stop treating the named ASes for pruning purposes at all. =C2=A0And I think= that
applies even for the case where pruning happens even at ebgp. =C2=A0For exa= mple,
an even terser form of Stephane's issue:

+---+
| =C2=A0 |\
| =C2=A0 | \
| Z |--A---B
| =C2=A0 | /
| =C2=A0 |/
+---+

When A is a PE and Z is a single AS, pruning to the single path is not a problem. =C2=A0But if Z is really:

+---+
|Z1 |\
+---+ \
|Z2 |--A---B
+---+ /
|Z3 |/
+---+

Then we still have the issue.

-- Jeff

--90e6ba614c64c0365c04ff4629c5-- From nobody Mon Jul 28 12:48:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF941A0AE0 for ; Mon, 28 Jul 2014 12:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrXygPKUf9sV for ; Mon, 28 Jul 2014 12:48:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CF6F61A0080 for ; Mon, 28 Jul 2014 12:48:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8A4E5C5D0; Mon, 28 Jul 2014 15:48:55 -0400 (EDT) Date: Mon, 28 Jul 2014 15:48:55 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140728194855.GE31282@pfrc> References: <5637_1406056798_53CEB95E_5637_4963_1_9E32478DFA9976438E7A22F69B08FF92044435@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722212735.GA11770@puck.nether.net> <25601_1406066454_53CEDF16_25601_752_1_9E32478DFA9976438E7A22F69B08FF9204461C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140722222246.GB19654@puck.nether.net> <006a01cfa770$165cccf0$431666d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006a01cfa770$165cccf0$431666d0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/UJaNAW3VcxjcVdC05-99MHsZ-lg Cc: 'Jeffrey Haas' , 'Robert Raszuk' , 'idr wg' Subject: Re: [Idr] draft-litkowski-idr-bgp-timestamp X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:48:56 -0000 Sue, On Thu, Jul 24, 2014 at 02:50:06PM -0400, Susan Hares wrote: > Based on work with vendor boxes for the BMWG BGP work - I would recommend > you timestamp the BGP trace NLRI as you leave the BGP Peer and as you > receive it. Otherwise, you run into the data flow patterns the trace NLRI is > included in causing variation in your flows. We chatted further about this in terms of potential implementation impact with this point in mind. Here's some interesting observations: If you have an update group (consistent export policy) where this is applied, you would need to insert the timestamp on a per-peer basis. In order to avoid BGP path churn once you've generated an outbound timestamp, you'd want it to stay the same to avoid churning path attributes. You'd thus timestamp once per outbound peer. You'd need to store that timestamp rather than generating it dynamically each time you send that update. And interestingly, the best many implementations can do is simply add the timestamp at the time things are received or sent on the TCP session. There is no guarantee how closely that aligns to where it may be in TCP buffers. Thus, tightly bound timestamps aren't very helpful here. For the BMWG work, if you recall, we suggested external measurement to bypass some of these artifacts. -- Jeff From nobody Mon Jul 28 12:51:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30171B27F9 for ; Mon, 28 Jul 2014 12:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux_86jakCBa8 for ; Mon, 28 Jul 2014 12:51:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 37F541A8BB2 for ; Mon, 28 Jul 2014 12:51:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 076A4C5DE; Mon, 28 Jul 2014 15:51:05 -0400 (EDT) Date: Mon, 28 Jul 2014 15:51:05 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140728195104.GF31282@pfrc> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140728191852.GC31282@pfrc> 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: http://mailarchive.ietf.org/arch/msg/idr/Bu19hgTQYDs7gdLrO9ifxRFvzwM Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:51:06 -0000 Robert, On Mon, Jul 28, 2014 at 09:45:19PM +0200, Robert Raszuk wrote: > To me path prooning means you select best from N and advertise single path > out. This doesn't make any sense to me. If we were discussing an add-path enabled version of RT-C, it might make some sense. But that's not what I'm talking about. > However path prooning does not mean you do not install received > routes/filters from either IBGP or EBGP peers. Those should be IMO always > installed even if they are not best paths. The RT-C routes are always accepted and installed. The filter state that is generated from the received routes is where the pruning is happening. -- Jeff From nobody Mon Jul 28 12:56:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FBA1A0515 for ; Mon, 28 Jul 2014 12:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t5K4TFQ73JK for ; Mon, 28 Jul 2014 12:56:46 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662351A03E8 for ; Mon, 28 Jul 2014 12:56:46 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id hn18so4206462igb.4 for ; Mon, 28 Jul 2014 12:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+hJFpZEAT4qwbckKWJitCUXmkJLuDn0198fCXvYqUuQ=; b=dL8DcwoozHSJv1h+/Afn3UFHf++FClDZwGi7Yaj/Zkbybp2xy+fWqMJ4r1giCfwH5/ h+fAPak27Ar3G/lV0OhjA9qw7208ypIVV/esnmATh7ouD3EVZC14sxFVaZOWX8hrA2X/ o3bGFOLIyYCaaoarC9DqVb4qAakmkq1wnkxcgmZZSKVGBrWdeY2chk4ov56VU1QsCr63 7oEbHQ21wZMBpO5/IdCM05kyc/2UdXZ7S6QWC2ddOu8M3yWC/hfdWkTCYINItaKJJLi8 8WuoKJKHfDuvUxE6GWD2NmLVmTfx332dd8dS7IoXD/pfo72PfzPHrbEUmAYk0EcUpsNm ZWmw== MIME-Version: 1.0 X-Received: by 10.50.6.77 with SMTP id y13mr8134149igy.21.1406577405799; Mon, 28 Jul 2014 12:56:45 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Mon, 28 Jul 2014 12:56:45 -0700 (PDT) In-Reply-To: <20140728195104.GF31282@pfrc> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140728191852.GC31282@pfrc> <20140728195104.GF31282@pfrc> Date: Mon, 28 Jul 2014 21:56:45 +0200 X-Google-Sender-Auth: rR8xqi-T8C9_abo1XLrdwSoC2AU Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: multipart/alternative; boundary=047d7bdca0c69f33d304ff46527a Archived-At: http://mailarchive.ietf.org/arch/msg/idr/GKz3F5HMeUBoKYIyTrxDJzpAFH8 Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:56:48 -0000 --047d7bdca0c69f33d304ff46527a Content-Type: text/plain; charset=UTF-8 > The RT-C routes are always accepted and installed. That is not what Stephane is observing and I do not have setup running with Junos to try it out myself. He said this: "The issue is that RR takes only best path into account when NLRI origin-AS is different from local AS to establish the distribution tree." "it is on RTC filter setup on the RR. RR authorize route sending VPN routes only to a single PE." "Especially Jeff and John already replied on the list that RT filter is only installed to best path peer." And the last sentence is clearly in odds to what I consider proper behaviour regarding filter handling. Best, R. On Mon, Jul 28, 2014 at 9:51 PM, Jeffrey Haas wrote: > Robert, > > On Mon, Jul 28, 2014 at 09:45:19PM +0200, Robert Raszuk wrote: > > To me path prooning means you select best from N and advertise single > path > > out. > > This doesn't make any sense to me. If we were discussing an add-path > enabled version of RT-C, it might make some sense. But that's not what I'm > talking about. > > > However path prooning does not mean you do not install received > > routes/filters from either IBGP or EBGP peers. Those should be IMO always > > installed even if they are not best paths. > > The RT-C routes are always accepted and installed. > > The filter state that is generated from the received routes is where the > pruning is happening. > > -- Jeff > --047d7bdca0c69f33d304ff46527a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> The RT-C r= outes are always accepted and installed.

That is not what Stephane is observing and I do not have setup r= unning with Junos to try it out myself.=C2=A0

He said this:

"The issue is that RR tak= es only best path into account when NLRI origin-AS is different from local = AS to establish the distribution tree."

"it is on RTC filter setup on the RR. RR author= ize route sending VPN routes only to a single PE."

"Especially Jeff and John already replied on the list that RT = filter is only installed to best path peer."


And the last sente= nce is clearly in odds to what I consider proper behaviour regarding filter= handling.

Best,
R.



On Mon, Jul 28, 2014 at 9:51 PM, Jeffrey Haas <jha= as@pfrc.org> wrote:
Robert,

On Mon, Jul 28, 2014 at 09:45:19PM +0200, Robert Raszuk wrote:
> To me path prooning means you select best from N and advertise single = path
> out.

This doesn't make any sense to me. =C2=A0If we were discussing an= add-path
enabled version of RT-C, it might make some sense. =C2=A0But that's not= what I'm
talking about.

> However path prooning does not mean you do not install received
> routes/filters from either IBGP or EBGP peers. Those should be IMO alw= ays
> installed even if they are not best paths.

The RT-C routes are always accepted and installed.

The filter state that is generated from the received routes is where the pruning is happening.

-- Jeff

--047d7bdca0c69f33d304ff46527a-- From nobody Mon Jul 28 13:04:17 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0E81A00CD for ; Mon, 28 Jul 2014 13:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19woGwUKZ8aq for ; Mon, 28 Jul 2014 13:04:13 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DDC5F1A008E for ; Mon, 28 Jul 2014 13:04:13 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8CBB2C5DE; Mon, 28 Jul 2014 16:04:13 -0400 (EDT) Date: Mon, 28 Jul 2014 16:04:13 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140728200413.GH31282@pfrc> References: <21364_1406039563_53CE760B_21364_11973_1_9E32478DFA9976438E7A22F69B08FF92044190@OPEXCLILM34.corporate.adroot.infra.ftgroup> <26290_1406040857_53CE7B19_26290_12427_1_9E32478DFA9976438E7A22F69B08FF920441F7@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140728191852.GC31282@pfrc> <20140728195104.GF31282@pfrc> 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: http://mailarchive.ietf.org/arch/msg/idr/lhUcVGUaM8OisQHDNpqZwZODk4U Cc: idr wg Subject: Re: [Idr] draft-litkowski-idr-rtc-interas-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:04:15 -0000 On Mon, Jul 28, 2014 at 09:56:45PM +0200, Robert Raszuk wrote: > > The RT-C routes are always accepted and installed. > > That is not what Stephane is observing and I do not have setup running with > Junos to try it out myself. > > He said this: > > "The issue is that RR takes only best path into account when NLRI origin-AS > is different from local AS to establish the distribution tree." > > "it is on RTC filter setup on the RR. RR authorize route sending VPN routes > only to a single PE." > > "Especially Jeff and John already replied on the list that RT filter is > only installed to best path peer." > > > And the last sentence is clearly in odds to what I consider proper > behaviour regarding filter handling. In the JUNOS implementation, the "filtering state" is built from the received RT-C routes. We accept all of the routes. We build filtering state for the external paths (different from the local AS) based on a path count for the external paths traversed in internal route order. To offer a very coarse analogy, when an interface in multicast is subscribed to a group, it doesn't mean that the upstream will necessarily send traffic to it. Other mechanisms may impact that. And thus, for our VPN route distribution filtering state, just because we have an eligible path to use, it doesn't mean that we'll distribute to that path; we prune externals that exceed the path count. I'm starting to think this issue has gone a bit too far "into the weeds". If it weren't for the fact that similar implementations may run into this problem based on a reading of 4684, it'd be easier to just fix this locally (as we're going to do) to cover our interpretation of the RFC. -- Jeff From nobody Mon Jul 28 13:08:26 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFCA1A0126 for ; Mon, 28 Jul 2014 13:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpUeRc6jT9p4 for ; Mon, 28 Jul 2014 13:08:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EC55B1A00FE for ; Mon, 28 Jul 2014 13:08:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B75A9C5DE; Mon, 28 Jul 2014 16:08:18 -0400 (EDT) Date: Mon, 28 Jul 2014 16:08:18 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20140728200818.GI31282@pfrc> 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: http://mailarchive.ietf.org/arch/msg/idr/ZV9ZyuUUTnxWcdrBV-_SxJ3tGNg Subject: [Idr] Request for WG adoption of draft-rosen-idr-rtc-no-rt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:08:20 -0000 IETF-90 was a fun time for RFC 4684 since it had three different drafts presented to cover various errata we've seen in the field. A question I asked at the microphone was whether we should try to centralize these in order to do a 4684-bis. That question didn't receive much of a favorable response. Eric also points out that we probably want to allow these issues to progress separably in order to allow them to be published as we work out the issues, rather than gating them all together. Thus, I'd like to request the Working Group to adop draft-rosen-idr-rtc-no-rtc. I think this document already has good consenus among several implementors and covers a very simple problem with a simple solution. -- Jeff From nobody Mon Jul 28 13:11:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D151B28AE for ; Mon, 28 Jul 2014 13:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6xntbsnXXC2 for ; Mon, 28 Jul 2014 13:11:15 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFC01A016C for ; Mon, 28 Jul 2014 13:11:15 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so7287107ieb.32 for ; Mon, 28 Jul 2014 13:11: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:date:message-id:subject :from:to:cc:content-type; bh=/KQ5rk5sNpMUMCUVQJtT4HkF5Dnyiu/iKHq0QsrY2h8=; b=dMcbeGVfRPUzulpj809Anre2gT+Yjr6YECWXmtoyS1eKrR4btu36XVIoJ5uxGpL42z H7Sr0AUuMbvD8E+8pX3DUj7bQpCycKuyxB2y0K6MFm7+PZTbGgb11C30lQoLjYU5v8X+ EoP5MyszGGu7NkINJi+HgpFkj/fISVuL90zwxFuwSJfJ8gQPdf03WmNOrrT5Zra4F8WQ bR0uqcglXTWDKwfePBxGRAu76VKKvcfvtE4EpQGFDdmYvdwEC09WqEJaAqZow/pRQnAi zep1BJ64OxvPAqpUKgVHIRsjsjcoHsf8E9P/XsFtKJooIJoD5/Pw+dy2jCOmaaAdSmPo R/+Q== MIME-Version: 1.0 X-Received: by 10.43.63.134 with SMTP id xe6mr1274010icb.97.1406578275268; Mon, 28 Jul 2014 13:11:15 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Mon, 28 Jul 2014 13:11:15 -0700 (PDT) In-Reply-To: <20140728200818.GI31282@pfrc> References: <20140728200818.GI31282@pfrc> Date: Mon, 28 Jul 2014 22:11:15 +0200 X-Google-Sender-Auth: -zdvxKyRAf0wK5AD_5Wfwbp31XQ Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: multipart/alternative; boundary=bcaec517aefe723f9d04ff4686de Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_f6QOCXInjLrHvdibdeFEwNkUWU Cc: idr wg Subject: Re: [Idr] Request for WG adoption of draft-rosen-idr-rtc-no-rt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:11:21 -0000 --bcaec517aefe723f9d04ff4686de Content-Type: text/plain; charset=UTF-8 As co-author and in fact someone who in fact proposed this solution as a way out of the issue of lack of default action for those prefixes where RTC is enabled and there is no RT attached I support its adoption and perhaps very soon last call. best, r. On Mon, Jul 28, 2014 at 10:08 PM, Jeffrey Haas wrote: > IETF-90 was a fun time for RFC 4684 since it had three different drafts > presented to cover various errata we've seen in the field. A question I > asked at the microphone was whether we should try to centralize these in > order to do a 4684-bis. That question didn't receive much of a favorable > response. > > Eric also points out that we probably want to allow these issues to > progress > separably in order to allow them to be published as we work out the issues, > rather than gating them all together. > > Thus, I'd like to request the Working Group to adop > draft-rosen-idr-rtc-no-rtc. I think this document already has good > consenus > among several implementors and covers a very simple problem with a simple > solution. > > -- Jeff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --bcaec517aefe723f9d04ff4686de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As co= -author and in fact someone who in fact proposed this solution as a way out= of the issue of lack of default action for those prefixes where RTC is ena= bled and there is no RT attached I support its adoption and perhaps very so= on last call.

best,
r.


On Mon, Jul 28, 2014 at 10:08 PM, J= effrey Haas <jhaas@pfrc.org> wrote:
IETF-90 was a fun time for RFC 4684 since it= had three different drafts
presented to cover various errata we've seen in the field. =C2=A0A ques= tion I
asked at the microphone was whether we should try to centralize these in order to do a 4684-bis. =C2=A0That question didn't receive much of a fa= vorable
response.

Eric also points out that we probably want to allow these issues to progres= s
separably in order to allow them to be published as we work out the issues,=
rather than gating them all together.

Thus, I'd like to request the Working Group to adop
draft-rosen-idr-rtc-no-rtc. =C2=A0I think this document already has good co= nsenus
among several implementors and covers a very simple problem with a simple solution.

-- Jeff

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

--bcaec517aefe723f9d04ff4686de-- From nobody Mon Jul 28 13:13:34 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50A61A00EB for ; Mon, 28 Jul 2014 13:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGFcGat5rbfH for ; Mon, 28 Jul 2014 13:13:29 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98C11A0092 for ; Mon, 28 Jul 2014 13:13:29 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so7222500ieb.4 for ; Mon, 28 Jul 2014 13:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=96qqvDau63yZBT0r0NnZXnU6lFK/w3WamzJMNO2RIqI=; b=aU7aK77yKIJpMluLz3SpHa1STDVdJZD0CQnaP2bU0F9YpeoNuxtJpceuS/pEwdun0r Wn1ISW2TUPPugAuLsCWXvJbdih2sZT2gvrE3EMGeVCC3I4feHR/VWQchV+av1mbyZfs6 4f9oZ0Rao/HeCqGpAQTpkuZ335ZCZMtDv8G+7RLxJyxLDkAZnkGWCgeLQ5ki07MkuaTL eMP4OO3ZHQVDFxBcoT0VpnMOR7ek+g85pz/zTg8zX0FVZb11GGvSecA5gt3CAZPHQqKh BsIKcnHgqYSvOR5j6GAZF/PErLE1Bp5+2Vp5o+GWdk+1R5jHpwD94+HWcGAA4N9sVmgw uJ2Q== MIME-Version: 1.0 X-Received: by 10.42.47.140 with SMTP id o12mr24894702icf.4.1406578409180; Mon, 28 Jul 2014 13:13:29 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Mon, 28 Jul 2014 13:13:29 -0700 (PDT) In-Reply-To: <20140508195029.GB3935@pfrc> References: <20140508195029.GB3935@pfrc> Date: Mon, 28 Jul 2014 22:13:29 +0200 X-Google-Sender-Auth: VvDIfCq7I3_XwgduaY5aoDsWxc0 Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: multipart/alternative; boundary=90e6ba6149aa6d93ac04ff468e83 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/VfIpuUKhjsfPaoSxm68khpBxbr8 Cc: idr wg Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:13:32 -0000 --90e6ba6149aa6d93ac04ff468e83 Content-Type: text/plain; charset=UTF-8 I support this draft for WG doc and I guess soon LC. r. On Thu, May 8, 2014 at 9:50 PM, Jeffrey Haas wrote: > On Mon, Apr 21, 2014 at 04:01:19PM -0400, John G. Scudder wrote: > > We have received a request for a working group last call on > draft-ietf-idr-flowspec-redirect-rt-bis-00. A URL for the draft is > http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-00 > > > > Please send comments to the list by May 6. > > Were I the chairs, I'd say the document doesn't have group consensus. > > Come on folk, give this a fast read. It's short, promise. :-) > > -- Jeff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --90e6ba6149aa6d93ac04ff468e83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support this draft for WG doc and I guess = soon LC.

r.


On Thu, May 8, 2014 at 9:50 PM, Jeffrey Haas <jhaas@= pfrc.org> wrote:
On Mon, Apr 21, 2014 at 04:0= 1:19PM -0400, John G. Scudder wrote:
> We have received a request for a working group l= ast call on draft-ietf-idr-flowspec-redirect-rt-bis-00. A URL for the draft= is http://tools.ietf.org/html/draft-ietf-idr-flow= spec-redirect-rt-bis-00
>
> Please send comments to the list by May 6.

Were I the chairs, I'd say the document doesn't have group co= nsensus.

Come on folk, give this a fast read. =C2=A0It's short, promise. :-)

-- Jeff

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

--90e6ba6149aa6d93ac04ff468e83-- From nobody Mon Jul 28 13:43:02 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979841A0142 for ; Mon, 28 Jul 2014 13:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRsDfsJmxkPZ for ; Mon, 28 Jul 2014 13:42:58 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 974201A0080 for ; Mon, 28 Jul 2014 13:42:58 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0333DC09E; Mon, 28 Jul 2014 16:42:57 -0400 (EDT) Date: Mon, 28 Jul 2014 16:42:57 -0400 From: Jeffrey Haas To: bruno.decraene@orange.com Message-ID: <20140728204257.GL31282@pfrc> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> <10494_1406541326_53D61E0E_10494_65_2_53C29892C857584299CBF5D05346208A0719229E@PEXCVZYM11.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10494_1406541326_53D61E0E_10494_65_2_53C29892C857584299CBF5D05346208A0719229E@PEXCVZYM11.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/-FfCbNVvT_XspyTkWEUpdWt_3es Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:43:00 -0000 On Mon, Jul 28, 2014 at 09:55:25AM +0000, bruno.decraene@orange.com wrote: > I'm afraid that, as per my current understanding of the draft, I do not think that this version of the draft is ready for WG adoption. > I don't think that the document is mature enough for early allocation. > > Please find below some more detailed comments. [Many fine points elided.] I share similar reservations with Bruno. I don't think the draft is clear enough for me to feel comfortable with adopting this draft yet. I am even less comfortable requesting early code point assignment. I'd like to see the following general points addressed prior to adding my support: - Cover the use cases of how the remote NHs are used by BGP - What is the interaction with the actual nexthop attribute? - This is optional-transitive. What procedure is used to avoid leaking this information further than desired? - How does this interact with the encaps safi draft? - Third-party nexthops are already painful with respect to reachability blackholes. What mechanisms are intended, if any, to mitigate that? - Similarly, what sort of IGP distance validation is expected for this in BGP tie-breaking? None and leave it to the regular nexthop? Does that even make sense? - And please don't leave a big TBD in the community section when it seems very likely you have a Nifty Idea about what to do here. :-) I'm exceedingly sensitive to early assignment without some plan for how to handle versioning as the draft is developed and deployed in early stages. Please also give a plan on how to handle such versioning issues. For what it's worth, this does appear it will be useful. I'm looking forward to seeing the next version. -- Jeff From nobody Mon Jul 28 23:43:50 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEFF1A00BA for ; Mon, 28 Jul 2014 23:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwro4GzNpeXf for ; Mon, 28 Jul 2014 23:43:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0281A009C for ; Mon, 28 Jul 2014 23:43:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHR72141; Tue, 29 Jul 2014 06:43:45 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Jul 2014 07:43:44 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 14:43:38 +0800 From: Xuxiaohu To: Jeffrey Haas , "bruno.decraene@orange.com" Thread-Topic: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 Thread-Index: AQHPpeVFSc+l4GGiykePxh3Y07AM+5uxkjgggAPk54CAASprcA== Date: Tue, 29 Jul 2014 06:43:37 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08298331@NKGEML512-MBS.china.huawei.com> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> <10494_1406541326_53D61E0E_10494_65_2_53C29892C857584299CBF5D05346208A0719229E@PEXCVZYM11.corporate.adroot.infra.ftgroup> <20140728204257.GL31282@pfrc> In-Reply-To: <20140728204257.GL31282@pfrc> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/tNXZLbeEtYDdeKHm1zREi6ZT0R0 Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 06:43:49 -0000 I have the same reservation as Bruno, Yakov and Jeff. Besides the comments made by Bruno, Yakov and Jeff, I hope the authors coul= d consider the following comments (http://www.ietf.org/mail-archive/web/idr= /current/msg13444.html) as well. Best regards, Xiaohu > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Tuesday, July 29, 2014 4:43 AM > To: bruno.decraene@orange.com > Cc: idr@ietf. org > Subject: Re: [Idr] WG adoption requested for > draft-vandevelde-idr-remote-next-hop-06 >=20 > On Mon, Jul 28, 2014 at 09:55:25AM +0000, bruno.decraene@orange.com > wrote: > > I'm afraid that, as per my current understanding of the draft, I do not= think > that this version of the draft is ready for WG adoption. > > I don't think that the document is mature enough for early allocation. > > > > Please find below some more detailed comments. >=20 > [Many fine points elided.] >=20 > I share similar reservations with Bruno. I don't think the draft is clea= r enough > for me to feel comfortable with adopting this draft yet. I am even less > comfortable requesting early code point assignment. >=20 > I'd like to see the following general points addressed prior to adding my > support: >=20 > - Cover the use cases of how the remote NHs are used by BGP > - What is the interaction with the actual nexthop attribute? > - This is optional-transitive. What procedure is used to avoid leaking t= his > information further than desired? > - How does this interact with the encaps safi draft? > - Third-party nexthops are already painful with respect to reachability > blackholes. What mechanisms are intended, if any, to mitigate that? > - Similarly, what sort of IGP distance validation is expected for this in > BGP tie-breaking? None and leave it to the regular nexthop? Does that > even make sense? >=20 > - And please don't leave a big TBD in the community section when it seems > very likely you have a Nifty Idea about what to do here. :-) >=20 > I'm exceedingly sensitive to early assignment without some plan for how t= o > handle versioning as the draft is developed and deployed in early stages. > Please also give a plan on how to handle such versioning issues. >=20 > For what it's worth, this does appear it will be useful. I'm looking for= ward to > seeing the next version. >=20 > -- Jeff >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jul 29 10:09:59 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9601B29F5; Tue, 29 Jul 2014 10:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuZBBe0zUIs4; Tue, 29 Jul 2014 10:09:53 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69D61B2997; Tue, 29 Jul 2014 10:09:52 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0275.namprd09.prod.outlook.com (25.160.80.24) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 17:09:51 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.0995.014; Tue, 29 Jul 2014 17:09:51 +0000 From: "Sriram, Kotikalapudi" To: "Jakob Heitz (jheitz)" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQ Date: Tue, 29 Jul 2014 17:09:50 +0000 Message-ID: <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(105586002)(99396002)(92566001)(2656002)(561944003)(87936001)(101416001)(107046002)(77096002)(50986999)(85306003)(54356999)(106356001)(99286002)(66066001)(33646002)(2201001)(21056001)(74316001)(107886001)(76176999)(95666004)(76482001)(46102001)(77982001)(4396001)(74502001)(81342001)(86362001)(83072002)(81542001)(31966008)(76576001)(85852003)(80022001)(83322001)(64706001)(74662001)(20776003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB0275; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/idr/6m-GM6fpjk1TAeNrNBUUEl_3Sdk Subject: Re: [Idr] draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 17:09:58 -0000 Jacob, Please see comment inline below. Sriram =20 >Add a new attribute that means "this route may be advertised up". >This attribute must be signed by the originator of the route. >Add a second attribute that means "The first attribute was added". >This attribute must be included in the BGPSEC signature. >If an AS asserts that the route can no longer be advertised up,=20 > It simply removes the first attribute along with its signature. >Since the first attribute must be signed by the originator, no one else ca= n add it back. The assertion "no one else can add it back" is not true. In your proposal, as I understand it,=20 only the origin AS is signing the first attribute to its neighbor (i.e. sec= ond AS). Therefore, after an AS along the path removes the first attribute=20 along with the origin's signature, a subsequent adversary AS can always=20 cut and paste that thing back.=20 Please let me know if I misunderstood something. (Note: We carefully avoided this kind of cut and paste problem in Path Signing in BGPSEC by requiring each AS to sign to the next AS in the A= S path.) Sriram >Now, an AS that considers itself a provider of the advertised route to the= peer from which it received the advertisement can filter on the presence o= f the second attribute and the lack of the first to prevent the leak. >The advantage of this solution is that it will not expose the customer-pro= vider relationship to any customers. >--Jakob From nobody Tue Jul 29 10:46:36 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1201B29EA; Tue, 29 Jul 2014 10:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIbr-xr64YiK; Tue, 29 Jul 2014 10:46:32 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA2D1B295D; Tue, 29 Jul 2014 10:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2007; q=dns/txt; s=iport; t=1406655992; x=1407865592; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=exztzFjF0ZMvazLLbwO+8EHb3n+gmhoPFOfe32jt57o=; b=hmJPBpDiozPsqyl7KbQjcT4ooRDoMeMZFtrCdKxwpA4rdJjn50EwUs6m RwyVdaRdCHrSDRJ05IcBD4p1EyzRKtaHU3dcZ94mwTcIImlha6fOY1YDm y1Kt3cmIuf0r9UYd3lF3TatjqnD5MaAd4s9SrRR1IrE0KR6rNAQuymAQa o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFALrc11OtJV2Z/2dsb2JhbABZgw6BKQTTOAGBEBZ3hAMBAQEEOjgTBAIBCBEEAQELFAkHMhQJCAEBBAESCBOIJ78tF48bOAaDKYEbAQSwHYNJbIFF X-IronPort-AV: E=Sophos;i="5.01,758,1400025600"; d="scan'208";a="64924286" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 29 Jul 2014 17:46:29 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6THkT9q025010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 17:46:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 12:45:44 -0500 From: "Jakob Heitz (jheitz)" To: "Sriram, Kotikalapudi" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrA= Date: Tue, 29 Jul 2014 17:45:43 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> In-Reply-To: <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.165.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/kPy9J9LXQyK2mSf_0ypALT5legk Subject: Re: [Idr] draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 17:46:34 -0000 ok. How about: Each AS signs it as having passed it along, just like the BGPSEC. Then after one AS removes it, a subsequent AS cannot add it back. --Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > Sent: Tuesday, July 29, 2014 10:10 AM > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 >=20 > Jacob, >=20 > Please see comment inline below. >=20 > Sriram >=20 > >Add a new attribute that means "this route may be advertised up". > >This attribute must be signed by the originator of the route. >=20 > >Add a second attribute that means "The first attribute was added". > >This attribute must be included in the BGPSEC signature. >=20 > >If an AS asserts that the route can no longer be advertised up, It > >simply removes the first attribute along with its signature. >=20 > >Since the first attribute must be signed by the originator, no one > else can add it back. >=20 > The assertion "no one else can add it back" is not true. > In your proposal, as I understand it, > only the origin AS is signing the first attribute to its neighbor > (i.e. second AS). > Therefore, after an AS along the path removes the first attribute > along with the origin's signature, a subsequent adversary AS can > always cut and paste that thing back. > Please let me know if I misunderstood something. > (Note: We carefully avoided this kind of cut and paste problem in > Path Signing in BGPSEC by requiring each AS to sign to the next AS > in the AS path.) >=20 > Sriram >=20 > >Now, an AS that considers itself a provider of the advertised route > to the peer from which it received the advertisement can filter on > the presence of the second attribute and the lack of the first to > prevent the leak. >=20 > >The advantage of this solution is that it will not expose the > customer-provider relationship to any customers. >=20 > >--Jakob From nobody Tue Jul 29 11:18:47 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFC51A026E for ; Tue, 29 Jul 2014 11:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LshNGfJlRcP for ; Tue, 29 Jul 2014 11:18:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCF21A0091 for ; Tue, 29 Jul 2014 11:18:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CA959C47F; Tue, 29 Jul 2014 14:18:44 -0400 (EDT) Date: Tue, 29 Jul 2014 14:18:44 -0400 From: Jeffrey Haas To: Jeffrey Haas Message-ID: <20140729181844.GI31282@pfrc> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> <10494_1406541326_53D61E0E_10494_65_2_53C29892C857584299CBF5D05346208A0719229E@PEXCVZYM11.corporate.adroot.infra.ftgroup> <20140728204257.GL31282@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140728204257.GL31282@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hHZwLDCsgiVBIP6YN02y3jbFd0M Cc: bruno.decraene@orange.com, "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 18:18:46 -0000 On Mon, Jul 28, 2014 at 04:42:57PM -0400, Jeffrey Haas wrote: > On Mon, Jul 28, 2014 at 09:55:25AM +0000, bruno.decraene@orange.com wrote: > > I'm afraid that, as per my current understanding of the draft, I do not think that this version of the draft is ready for WG adoption. > > I don't think that the document is mature enough for early allocation. > > > > Please find below some more detailed comments. > > [Many fine points elided.] > > I share similar reservations with Bruno. I don't think the draft is clear > enough for me to feel comfortable with adopting this draft yet. I am even > less comfortable requesting early code point assignment. > > I'd like to see the following general points addressed prior to adding my > support: > > - Cover the use cases of how the remote NHs are used by BGP > - What is the interaction with the actual nexthop attribute? > - This is optional-transitive. What procedure is used to avoid leaking this > information further than desired? > - How does this interact with the encaps safi draft? > - Third-party nexthops are already painful with respect to reachability > blackholes. What mechanisms are intended, if any, to mitigate that? As a clarification, this was about how a remote nexthop has similar reachability issues to third party nexthops. > - Similarly, what sort of IGP distance validation is expected for this in > BGP tie-breaking? None and leave it to the regular nexthop? Does that > even make sense? > > - And please don't leave a big TBD in the community section when it seems > very likely you have a Nifty Idea about what to do here. :-) I had a long conversation with Keyur about the above concerns. While after that conversation I'm a lot more comfortable knowing what the feature is going to be *for*, that's not how the draft is currently written. As we discussed, I'd like to see the next rev before addming my support for the draft. The security issues are still spooky but in the expected use cases probably managable. -- Jeff From nobody Tue Jul 29 12:31:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7501A066C; Tue, 29 Jul 2014 12:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SmBHsU_AQfg; Tue, 29 Jul 2014 12:31:00 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713171A0657; Tue, 29 Jul 2014 12:31:00 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0275.namprd09.prod.outlook.com (25.160.80.24) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 19:30:54 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.0995.014; Tue, 29 Jul 2014 19:30:54 +0000 From: "Sriram, Kotikalapudi" To: "Jakob Heitz (jheitz)" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4A== Date: Tue, 29 Jul 2014 19:30:53 +0000 Message-ID: <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(74502001)(4396001)(81342001)(86362001)(77982001)(74662001)(20776003)(85852003)(76576001)(83072002)(81542001)(31966008)(64706001)(83322001)(80022001)(99396002)(87936001)(92566001)(2656002)(107046002)(101416001)(105586002)(2201001)(74316001)(66066001)(33646002)(21056001)(76176999)(95666004)(46102001)(76482001)(107886001)(79102001)(85306003)(50986999)(77096002)(106356001)(54356999)(99286002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB0275; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/idr/kRhxH0XJSi3_41DpA3l_EIelFcc Subject: Re: [Idr] draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 19:31:02 -0000 >ok. How about: >Each AS signs it as having passed it along, just like the BGPSEC. >Then after one AS removes it, a subsequent AS cannot add it back. Jacob, Sorry, but that still doesn't work. The signature validation would break.=20 Say, the update received at AS3 is P [AS2 AS1], where AS1 is the origin. Let us say, AS2 removed the signed attribute (that you proposed), and sent the update to AS3. Then AS3 will not be able to validate AS1's signature,=20 because AS1's sig covered the removed attribute. Sriram >--Jakob From nobody Tue Jul 29 12:38:55 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A911A0ABD; Tue, 29 Jul 2014 12:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVtO-jiy04fr; Tue, 29 Jul 2014 12:38:49 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D72A1A0AA1; Tue, 29 Jul 2014 12:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1246; q=dns/txt; s=iport; t=1406662730; x=1407872330; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=98J3lnhYg27fxpvMnbW/8uB6srRIQhIW/c1OGJv63n8=; b=fThQmtNPzNBzFzdks8uLCHozJNXAhOvELDRtZbH9Nmf2icBbgbx8LQzC TWOhljNTmzCHhbqnXxn7UsSrSeCFP6qImSq6ZGrqkoISwsyOEAWxEhhyf 3dz5gBDKR7/kEOa09UgacFxv7XJPgknbq13pHbxhsSQlHH11u622XPY3U o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAHP311OtJV2Q/2dsb2JhbABagw6BKQTTOgGBERZ3hAMBAQEEOksEAgEIEQQBAQsUCQcyFAkIAQEEARIIiDq/RBePGzgGgymBGwEEsB2DSWyBBSQc X-IronPort-AV: E=Sophos;i="5.01,759,1400025600"; d="scan'208";a="64957931" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 29 Jul 2014 19:38:49 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6TJcmuh027897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 19:38:48 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 14:38:48 -0500 From: "Jakob Heitz (jheitz)" To: "Sriram, Kotikalapudi" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4AAAxGpg Date: Tue, 29 Jul 2014 19:38:47 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> In-Reply-To: <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.165.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/xs2R9zA9niCfhGxJE18PC440Ouw Subject: Re: [Idr] draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 19:38:50 -0000 Sriram, I'm not proposing to include it in the BGPSEC signature, It would be a separate signature. Once AS2 removes it, it removes the attribute and its signature chain. The BGPSEC attribute and its signature chain is a different signature chain= and not removed. The second attribute I proposed will be covered by the BGPSEC signature cha= in and not removed. --Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > Sent: Tuesday, July 29, 2014 12:31 PM > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 >=20 > >ok. How about: > >Each AS signs it as having passed it along, just like the BGPSEC. > >Then after one AS removes it, a subsequent AS cannot add it back. >=20 > Jacob, >=20 > Sorry, but that still doesn't work. The signature validation would > break. > Say, the update received at AS3 is P [AS2 AS1], where AS1 is the > origin. > Let us say, AS2 removed the signed attribute (that you proposed), > and sent the update to AS3. > Then AS3 will not be able to validate AS1's signature, because AS1's > sig covered the removed attribute. >=20 > Sriram >=20 > >--Jakob >=20 From nobody Tue Jul 29 12:58:19 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E9B1A0AFF; Tue, 29 Jul 2014 12:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS1ybSNkH5C1; Tue, 29 Jul 2014 12:58:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4841B285C; Tue, 29 Jul 2014 12:58:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140729195815.2156.98677.idtracker@ietfa.amsl.com> Date: Tue, 29 Jul 2014 12:58:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Gy0G-VbsGiwM4sWvQGI2VgDAKwo Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-migration-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 19:58:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute Authors : Wesley George Shane Amante Filename : draft-ietf-idr-as-migration-02.txt Pages : 17 Date : 2014-07-29 Abstract: This draft discusses common methods of managing an ASN migration using some BGP feaures that while commonly-used are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work such as BGPSec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as-migration-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-as-migration-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 Tue Jul 29 13:51:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59CD1A0B02; Tue, 29 Jul 2014 13:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9iKlL7IZ25n; Tue, 29 Jul 2014 13:51:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A111A0AE0; Tue, 29 Jul 2014 13:51:47 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0273.namprd09.prod.outlook.com (25.160.80.22) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 20:51:46 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.0995.014; Tue, 29 Jul 2014 20:51:46 +0000 From: "Sriram, Kotikalapudi" To: "Jakob Heitz (jheitz)" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4AAAxGpgAAEXotA= Date: Tue, 29 Jul 2014 20:51:45 +0000 Message-ID: <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(51704005)(189002)(4396001)(79102001)(76576001)(74662001)(107046002)(107886001)(31966008)(21056001)(77982001)(86362001)(87936001)(93886003)(101416001)(2656002)(74502001)(74316001)(95666004)(85306003)(99396002)(77096002)(80022001)(92566001)(83072002)(2201001)(76176999)(54356999)(85852003)(33646002)(81542001)(81342001)(76482001)(105586002)(46102001)(64706001)(99286002)(50986999)(20776003)(66066001)(106356001)(83322001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB0273; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/idr/QanZGaVvLlat_3SOHA7B-7bw474 Subject: Re: [Idr] draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:51:50 -0000 >I'm not proposing to include it in the BGPSEC signature, It would be a sep= arate signature. >Once AS2 removes it, it removes the attribute and its signature chain. >The BGPSEC attribute and its signature chain is a different signature chai= n and not removed. > >The second attribute I proposed will be covered by the BGPSEC signature ch= ain and not removed. > Jakob, OK, you are proposing a separate signature chain besides the BGPSEC sig cha= in. But any signature chain must continue end-to-end across the whole AS path. Because, if a signature chain is allowed to be removed at any point in the = path, then it becomes vulnerable to cut and paste attack. Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1], where AS1= is origin. Let us say, AS2 removed your proposed first attribute and the associated si= gnature, and forwarded the update to its customer AS3.=20 Now AS3 forwards the update to its customer AS4. AS4 can somehow learn that AS1 sent the first attribute to AS2 and signed i= t, and it can somehow get that whole 'goop' (i.e. the attribute and the sig of= AS1). Then AS4 can add back the 'goop', and forward the update to its *upstream = provider* AS5, and AS5 would be fooled and oblivious of the leak. (Note: Again think of the reason why partial path signatures are disallowed= in BGPSEC. The same principles should apply here too with any other proposed sig chain= .) Sriram >--Jakob From nobody Tue Jul 29 14:07:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09771A00EB; Tue, 29 Jul 2014 14:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAOLZbkBSVgx; Tue, 29 Jul 2014 14:07:01 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D111B28F7; Tue, 29 Jul 2014 14:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2034; q=dns/txt; s=iport; t=1406668016; x=1407877616; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sH7BxNedUUQajFnsxAhw0irGL+IHeegsb72UP6aOwr4=; b=VUCgXDK+80ReqHsLCfIlXMWnWvFdGu4PjyFwkmWUCeY/ClBeUEzik5Ad zwyOXv2FdrzQ8cVWBzmFbee+6I0WKFcZwsBgwhV1tYvpETxuKQjKdejrj a5thYDmN6zTWjHpeumpW4SCxW7HFCdGDcmwsDV9ZLZVf868Pn+5A0O9u2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFANQL2FOtJV2d/2dsb2JhbABagw6BKQTTQgGBEhZ3hAMBAQEEOksEAgEIEQQBAQsUCQcyFAkIAgQBEgiIOr9OF48bOAaDKYEbAQSwHYNJbIFF X-IronPort-AV: E=Sophos;i="5.01,759,1400025600"; d="scan'208";a="343707437" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 29 Jul 2014 21:06:56 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6TL6tVZ030189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 21:06:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 16:06:55 -0500 From: "Jakob Heitz (jheitz)" To: "Sriram, Kotikalapudi" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4AAAxGpgAAEXotAAAfYogA== Date: Tue, 29 Jul 2014 21:06:55 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE50CF061BE@xmb-aln-x02.cisco.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> In-Reply-To: <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.22.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/fnbK0-E-Sktoetg4-fG1h7Yv7V8 Subject: Re: [Idr] draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:07:02 -0000 No it wouldn't. For AS4 to put the goop back in, it needs to add the signatures of AS2 and = 3 to the goop chain. The chain of ASNs in the new signature chain needs to be= the same AS chain as in the BGPSEC. --Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > Sent: Tuesday, July 29, 2014 1:52 PM > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 >=20 > >I'm not proposing to include it in the BGPSEC signature, It would > be a separate signature. > >Once AS2 removes it, it removes the attribute and its signature > chain. > >The BGPSEC attribute and its signature chain is a different > signature chain and not removed. > > > >The second attribute I proposed will be covered by the BGPSEC > signature chain and not removed. > > >=20 > Jakob, >=20 > OK, you are proposing a separate signature chain besides the BGPSEC > sig chain. > But any signature chain must continue end-to-end across the whole AS > path. > Because, if a signature chain is allowed to be removed at any point > in the path, then it becomes vulnerable to cut and paste attack. > Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1], > where AS1 is origin. > Let us say, AS2 removed your proposed first attribute and the > associated signature, and forwarded the update to its customer AS3. > Now AS3 forwards the update to its customer AS4. > AS4 can somehow learn that AS1 sent the first attribute to AS2 and > signed it, and it can somehow get that whole 'goop' (i.e. the > attribute and the sig of AS1). > Then AS4 can add back the 'goop', and forward the update to its > *upstream provider* AS5, and AS5 would be fooled and oblivious of > the leak. >=20 > (Note: Again think of the reason why partial path signatures are > disallowed in BGPSEC. > The same principles should apply here too with any other proposed > sig chain.) >=20 > Sriram >=20 > >--Jakob >=20 From nobody Tue Jul 29 16:05:51 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7C71B2A1C; Tue, 29 Jul 2014 16:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcTTThtoQUsv; Tue, 29 Jul 2014 16:05:25 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FD51B2985; Tue, 29 Jul 2014 16:05:24 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0276.namprd09.prod.outlook.com (25.160.80.25) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 23:05:23 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.0995.014; Tue, 29 Jul 2014 23:05:23 +0000 From: "Sriram, Kotikalapudi" To: "Jakob Heitz (jheitz)" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4AAAxGpgAAEXotAAAfYogAACw6FA Date: Tue, 29 Jul 2014 23:05:22 +0000 Message-ID: <04c0c88dc1b541abba698499921e417a@BN1PR09MB0274.namprd09.prod.outlook.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF061BE@xmb-aln-x02.cisco.com> In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE50CF061BE@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(13464003)(189002)(51704005)(377454003)(243025005)(81542001)(46102001)(19580395003)(4396001)(31966008)(74502001)(50986999)(99396002)(76176999)(86362001)(54356999)(101416001)(15202345003)(93886003)(19580405001)(81342001)(87936001)(92566001)(2656002)(64706001)(20776003)(74316001)(2201001)(76576001)(85852003)(83322001)(77982001)(80022001)(66066001)(85306003)(33646002)(107886001)(106356001)(105586002)(99286002)(95666004)(107046002)(83072002)(21056001)(79102001)(15975445006)(77096002)(76482001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR09MB0276; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/idr/l0FYaaS9QCR1jp2Gmas4dOf5MTE Subject: Re: [Idr] draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 23:05:29 -0000 Jakob, OK, understood. But I still have these additional concerns/questions about your proposed me= thod: 1. People think having one signature chain in updates is bad enough.=20 You are proposing two signature chains. 2. How do you address the issue when an AS that is not the originator Wants to signal to a peer that the update should not be propagated=20 Laterally to another peer or to an upstream provider=20 (I.e., update can only be forwarded to customers). What tagging or attribute can you use to enable this if you were to ext= end your method? Please see what Method 2 does ('10' tag), slide 8 in my presentation:=20 http://www.ietf.org/proceedings/90/slides/slides-90-grow-2.pdf=20 3. The reason for your proposed method is that you wanted=20 ASes not to have to disclose peering relationships. My method (the draft we are discussing) does not require that explicitl= y. Sure, you can infer something from the tagging.=20 But even in your approach, if there were Routeviews/RIPE-RIS like colle= ctors, That collected the signed updates, then it is easy to tell who stripped= the First attribute and towards which neighbor.=20 So there is an implicit discernable peering disclosure there too. Sriram =20 -----Original Message----- From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz) Sent: Tuesday, July 29, 2014 5:07 PM To: Sriram, Kotikalapudi; IETF SIDR; idr@ietf.org; grow@ietf.org Subject: Re: [sidr] draft-sriram-route-leak-protection-00 No it wouldn't. For AS4 to put the goop back in, it needs to add the signatures of AS2 and = 3 to the goop chain. The chain of ASNs in the new signature chain needs to = be the same AS chain as in the BGPSEC. --Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > Sent: Tuesday, July 29, 2014 1:52 PM > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 >=20 > >I'm not proposing to include it in the BGPSEC signature, It would > be a separate signature. > >Once AS2 removes it, it removes the attribute and its signature > chain. > >The BGPSEC attribute and its signature chain is a different > signature chain and not removed. > > > >The second attribute I proposed will be covered by the BGPSEC > signature chain and not removed. > > >=20 > Jakob, >=20 > OK, you are proposing a separate signature chain besides the BGPSEC=20 > sig chain. > But any signature chain must continue end-to-end across the whole AS=20 > path. > Because, if a signature chain is allowed to be removed at any point in=20 > the path, then it becomes vulnerable to cut and paste attack. > Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1],=20 > where AS1 is origin. > Let us say, AS2 removed your proposed first attribute and the=20 > associated signature, and forwarded the update to its customer AS3. > Now AS3 forwards the update to its customer AS4. > AS4 can somehow learn that AS1 sent the first attribute to AS2 and=20 > signed it, and it can somehow get that whole 'goop' (i.e. the=20 > attribute and the sig of AS1). > Then AS4 can add back the 'goop', and forward the update to its=20 > *upstream provider* AS5, and AS5 would be fooled and oblivious of the=20 > leak. >=20 > (Note: Again think of the reason why partial path signatures are=20 > disallowed in BGPSEC. > The same principles should apply here too with any other proposed sig=20 > chain.) >=20 > Sriram >=20 From nobody Tue Jul 29 16:13:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF73C1B2985; Tue, 29 Jul 2014 16:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm-56dwOPMOJ; Tue, 29 Jul 2014 16:12:57 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EDA1B29F5; Tue, 29 Jul 2014 16:12:56 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id l13so1856717iga.1 for ; Tue, 29 Jul 2014 16:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ssf/X600AK8AVBO7W7HEjZrNz6mJr7TKKApJy9GJG8g=; b=Bh6vT9Upj9VPY1QAqPiMXMBYOUMu0U7EVB2aDFPQy6m6JYuXR26kC6Lc9O38OSACci 3LWLMhppmuhad5sZ5iJBuDN0uspRsYX+k21aMmpT6bx76Mt8SsWQhNWUZsJX6IyWyWn2 rbBCVXK4bBb2D4V8bG7EAEowmBnw3TghL+HJhS6AIlWTDl+Z43fHVkSiRO0CsxFDXYtN rnAdpPc3gzpJveb7yGJSdYiqiZEfTR/iXA1HZnNfq9SEkD0PzIb26DuF91wtGSzjCp0I er3lOfy1K2HxaEmxueiE0+BCu60326jiDPTri5qcVlQud13C35AezBgHugWrNZ/BnBjH fbLA== MIME-Version: 1.0 X-Received: by 10.50.36.106 with SMTP id p10mr48635885igj.9.1406675575539; Tue, 29 Jul 2014 16:12:55 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Tue, 29 Jul 2014 16:12:55 -0700 (PDT) In-Reply-To: <04c0c88dc1b541abba698499921e417a@BN1PR09MB0274.namprd09.prod.outlook.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF061BE@xmb-aln-x02.cisco.com> <04c0c88dc1b541abba698499921e417a@BN1PR09MB0274.namprd09.prod.outlook.com> Date: Wed, 30 Jul 2014 01:12:55 +0200 X-Google-Sender-Auth: Q909SrXu0NkpgHNZdpMRd7Wm-Us Message-ID: From: Robert Raszuk To: "Sriram, Kotikalapudi" Content-Type: multipart/alternative; boundary=089e0115ebd0fe8e7f04ff5d2d8c Archived-At: http://mailarchive.ietf.org/arch/msg/idr/nO6CO34n_bE3Cf5-i17zMYTqvOQ Cc: "idr@ietf.org" , "grow@ietf.org" , IETF SIDR Subject: Re: [Idr] [sidr] draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 23:12:59 -0000 --089e0115ebd0fe8e7f04ff5d2d8c Content-Type: text/plain; charset=UTF-8 > 1. People think having one signature chain in updates is bad enough. > You are proposing two signature chains. That to me has zero practical/real deployment relevance. Cheers, R. On Wed, Jul 30, 2014 at 1:05 AM, Sriram, Kotikalapudi < kotikalapudi.sriram@nist.gov> wrote: > Jakob, > > OK, understood. > But I still have these additional concerns/questions about your proposed > method: > 1. People think having one signature chain in updates is bad enough. > You are proposing two signature chains. > 2. How do you address the issue when an AS that is not the originator > Wants to signal to a peer that the update should not be propagated > Laterally to another peer or to an upstream provider > (I.e., update can only be forwarded to customers). > What tagging or attribute can you use to enable this if you were to > extend your method? > Please see what Method 2 does ('10' tag), slide 8 in my presentation: > http://www.ietf.org/proceedings/90/slides/slides-90-grow-2.pdf > 3. The reason for your proposed method is that you wanted > ASes not to have to disclose peering relationships. > My method (the draft we are discussing) does not require that > explicitly. > Sure, you can infer something from the tagging. > But even in your approach, if there were Routeviews/RIPE-RIS like > collectors, > That collected the signed updates, then it is easy to tell who > stripped the > First attribute and towards which neighbor. > So there is an implicit discernable peering disclosure there too. > > Sriram > > -----Original Message----- > From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Jakob Heitz > (jheitz) > Sent: Tuesday, July 29, 2014 5:07 PM > To: Sriram, Kotikalapudi; IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: Re: [sidr] draft-sriram-route-leak-protection-00 > > No it wouldn't. > For AS4 to put the goop back in, it needs to add the signatures of AS2 and > 3 to the goop chain. The chain of ASNs in the new signature chain needs to > be the same AS chain as in the BGPSEC. > > --Jakob > > > > -----Original Message----- > > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > > Sent: Tuesday, July 29, 2014 1:52 PM > > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > > Subject: RE: draft-sriram-route-leak-protection-00 > > > > >I'm not proposing to include it in the BGPSEC signature, It would > > be a separate signature. > > >Once AS2 removes it, it removes the attribute and its signature > > chain. > > >The BGPSEC attribute and its signature chain is a different > > signature chain and not removed. > > > > > >The second attribute I proposed will be covered by the BGPSEC > > signature chain and not removed. > > > > > > > Jakob, > > > > OK, you are proposing a separate signature chain besides the BGPSEC > > sig chain. > > But any signature chain must continue end-to-end across the whole AS > > path. > > Because, if a signature chain is allowed to be removed at any point in > > the path, then it becomes vulnerable to cut and paste attack. > > Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1], > > where AS1 is origin. > > Let us say, AS2 removed your proposed first attribute and the > > associated signature, and forwarded the update to its customer AS3. > > Now AS3 forwards the update to its customer AS4. > > AS4 can somehow learn that AS1 sent the first attribute to AS2 and > > signed it, and it can somehow get that whole 'goop' (i.e. the > > attribute and the sig of AS1). > > Then AS4 can add back the 'goop', and forward the update to its > > *upstream provider* AS5, and AS5 would be fooled and oblivious of the > > leak. > > > > (Note: Again think of the reason why partial path signatures are > > disallowed in BGPSEC. > > The same principles should apply here too with any other proposed sig > > chain.) > > > > Sriram > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --089e0115ebd0fe8e7f04ff5d2d8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> 1. People = think having one signature chain in updates is bad enough.
> =C2=A0 =C2=A0 You are proposing two = signature chains.

That to me has = zero practical/real deployment relevance.=C2=A0

Cheers,
= R.


On Wed, Jul 30, 2014 at 1:05 AM, Sriram, Kotikalapudi <ko= tikalapudi.sriram@nist.gov> wrote:
Jakob,

OK, understood.
But I still have these additional concerns/questions about your proposed me= thod:
1. People think having one signature chain in updates is bad enough.
=C2=A0 =C2=A0 You are proposing two signature chains.
2. How do you address the issue when an AS that is not the originator
=C2=A0 =C2=A0 Wants to signal to a peer that the update should not be propa= gated
=C2=A0 =C2=A0 Laterally to another peer or to an upstream provider
=C2=A0 =C2=A0 (I.e., update can only be forwarded to customers).
=C2=A0 =C2=A0 What tagging or attribute can you use to enable this if you w= ere to extend your method?
=C2=A0 =C2=A0 Please see what Method 2 does ('10' tag), slide 8 in = my presentation:
=C2=A0 =C2=A0 =C2=A0http://www.ietf.org/proceedings/90/sl= ides/slides-90-grow-2.pdf
3. The reason for your proposed method is that you wanted
=C2=A0 =C2=A0 ASes not to have to disclose peering relationships.
=C2=A0 =C2=A0 My method (the draft we are discussing) does not require that= explicitly.
=C2=A0 =C2=A0 Sure, you can infer something from the tagging.
=C2=A0 =C2=A0 But even in your approach, if there were Routeviews/RIPE-RIS = like collectors,
=C2=A0 =C2=A0 That collected the signed updates, then it is easy to tell wh= o stripped the
=C2=A0 =C2=A0 First attribute and towards which neighbor.
=C2=A0 =C2=A0 So there is an implicit discernable peering disclosure there = too.

Sriram

-----Original Message-----
From: sidr [mailto:sidr-bounces@ie= tf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, July 29, 2014 5:07 PM
To: Sriram, Kotikalapudi; IETF SIDR; idr@ie= tf.org; grow@ietf.org
Subject: Re: [sidr] draft-sriram-route-leak-protection-00

No it wouldn't.
For AS4 to put the goop back in, it needs to add the signatures of AS2 and = 3 to the goop chain. The chain of ASNs in the new signature chain needs to = be the same AS chain as in the BGPSEC.

--Jakob


> -----Original Message-----
> From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov]
> Sent: Tuesday, July 29, 2014 1:52 PM
> To: Jakob Heitz (jheitz); IETF SIDR; i= dr@ietf.org; grow@ietf.org
> Subject: RE: draft-sriram-route-leak-protection-00
>
> >I'm not proposing to include it in the BGPSEC signature, It wo= uld
> be a separate signature.
> >Once AS2 removes it, it removes the attribute and its signature > chain.
> >The BGPSEC attribute and its signature chain is a different
> signature chain and not removed.
> >
> >The second attribute I proposed will be covered by the BGPSEC
> signature chain and not removed.
> >
>
> Jakob,
>
> OK, you are proposing a separate signature chain besides the BGPSEC > sig chain.
> But any signature chain must continue end-to-end across the whole AS > path.
> Because, if a signature chain is allowed to be removed at any point in=
> the path, then it becomes vulnerable to cut and paste attack.
> Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1],
> where AS1 is origin.
> Let us say, AS2 removed your proposed first attribute and the
> associated signature, and forwarded the update to its customer AS3. > Now AS3 forwards the update to its customer AS4.
> AS4 can somehow learn that AS1 sent the first attribute to AS2 and
> signed it, and it can somehow get that whole 'goop' (i.e. the<= br> > attribute and the sig of AS1).
> Then AS4 can add =C2=A0back the 'goop', and forward the update= to its
> *upstream provider* AS5, and AS5 would be fooled and oblivious of the<= br> > leak.
>
> (Note: Again think of the reason why partial path signatures are
> disallowed in BGPSEC.
> The same principles should apply here too with any other proposed sig<= br> > chain.)
>
> Sriram
>

_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--089e0115ebd0fe8e7f04ff5d2d8c-- From nobody Tue Jul 29 17:02:04 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568D21A03E5; Tue, 29 Jul 2014 17:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.002 X-Spam-Level: X-Spam-Status: No, score=-14.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7NEMXRbz4Oj; Tue, 29 Jul 2014 17:01:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850671A038D; Tue, 29 Jul 2014 17:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4683; q=dns/txt; s=iport; t=1406678518; x=1407888118; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=k8CL3rc9FONxI9edMf8PfU3osBKePdCCDSlgL7LWpF4=; b=OxmuZ3MOOVxXgcYFXHHTnp/sVe3e6rXdcEc5buB+b8/iwVEYn71/3a8H 2B7JXDMnj2dVRC03YYWvD3unDEl2KkrLGsgAl2whFOLOjNJaSB2CuxPFZ qZWsetny6u1kTn++/XPQqSaqU4FMlWOqaeFBGyjxhO/UK1DLEf95encJS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAN802FOtJA2K/2dsb2JhbABagw5SVwTLfIdLAYEPFneEAwEBAQICOjgTBAIBCBEEAQELFAkHMhQJCAIEARIIAYg5Db9WF48bOAaDKYEbBbAdg0lsAYECBzs X-IronPort-AV: E=Sophos;i="5.01,760,1400025600"; d="scan'208";a="343738140" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2014 00:01:57 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6U01vNj003049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 00:01:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 19:01:57 -0500 From: "Jakob Heitz (jheitz)" To: "Sriram, Kotikalapudi" , IETF SIDR , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: draft-sriram-route-leak-protection-00 Thread-Index: Ac+p/vnHoWsppmC3R8uDlV6ghI7lHQBSoyTQAALDSrAAAxfY4AAAxGpgAAEXotAAAfYogAACw6FAAAJGnhA= Date: Wed, 30 Jul 2014 00:01:56 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE50CF063C1@xmb-aln-x02.cisco.com> References: <075DE01702BBC249BE1357EFD20DCFE50CF04B96@xmb-aln-x02.cisco.com> <671badb13318451098ddea1430afbc2f@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF05FC4@xmb-aln-x02.cisco.com> <9d9616c29f694286b9e0673f5959e715@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF060CA@xmb-aln-x02.cisco.com> <0608667c14f1402caa404e73f940e416@BN1PR09MB0274.namprd09.prod.outlook.com> <075DE01702BBC249BE1357EFD20DCFE50CF061BE@xmb-aln-x02.cisco.com> <04c0c88dc1b541abba698499921e417a@BN1PR09MB0274.namprd09.prod.outlook.com> In-Reply-To: <04c0c88dc1b541abba698499921e417a@BN1PR09MB0274.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Wn5-SulvIn7cy9MBdLxAb1_Rui4 Subject: Re: [Idr] draft-sriram-route-leak-protection-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 00:02:00 -0000 There is no need to send this attribute to a collector. If a provider respects his customer's wishes to privacy, he will strip the attribute before sending it to a collector. The worst thing is sending only one prefix per update and having to sign it differently for each AS you send it to. Compared with that, another signature chain is a drop in the bucket. Maybe we can combine ideas. Take your RLP attribute and sign it in another signature chain. Each AS adds its bits and signs it again. First AS to remove it means "propagate to customers only" You still need the "The RLP was added" bit in the BGPSEC signature. Something like that? --Jakob > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > Sent: Tuesday, July 29, 2014 4:05 PM > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: RE: draft-sriram-route-leak-protection-00 >=20 > Jakob, >=20 > OK, understood. > But I still have these additional concerns/questions about your > proposed method: > 1. People think having one signature chain in updates is bad enough. > You are proposing two signature chains. > 2. How do you address the issue when an AS that is not the > originator > Wants to signal to a peer that the update should not be > propagated > Laterally to another peer or to an upstream provider > (I.e., update can only be forwarded to customers). > What tagging or attribute can you use to enable this if you were > to extend your method? > Please see what Method 2 does ('10' tag), slide 8 in my > presentation: > http://www.ietf.org/proceedings/90/slides/slides-90-grow-2.pdf > 3. The reason for your proposed method is that you wanted > ASes not to have to disclose peering relationships. > My method (the draft we are discussing) does not require that > explicitly. > Sure, you can infer something from the tagging. > But even in your approach, if there were Routeviews/RIPE-RIS > like collectors, > That collected the signed updates, then it is easy to tell who > stripped the > First attribute and towards which neighbor. > So there is an implicit discernable peering disclosure there too. >=20 > Sriram >=20 > -----Original Message----- > From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Jakob Heitz > (jheitz) > Sent: Tuesday, July 29, 2014 5:07 PM > To: Sriram, Kotikalapudi; IETF SIDR; idr@ietf.org; grow@ietf.org > Subject: Re: [sidr] draft-sriram-route-leak-protection-00 >=20 > No it wouldn't. > For AS4 to put the goop back in, it needs to add the signatures of > AS2 and 3 to the goop chain. The chain of ASNs in the new signature > chain needs to be the same AS chain as in the BGPSEC. >=20 > --Jakob >=20 >=20 > > -----Original Message----- > > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > > Sent: Tuesday, July 29, 2014 1:52 PM > > To: Jakob Heitz (jheitz); IETF SIDR; idr@ietf.org; grow@ietf.org > > Subject: RE: draft-sriram-route-leak-protection-00 > > > > >I'm not proposing to include it in the BGPSEC signature, It would > > be a separate signature. > > >Once AS2 removes it, it removes the attribute and its signature > > chain. > > >The BGPSEC attribute and its signature chain is a different > > signature chain and not removed. > > > > > >The second attribute I proposed will be covered by the BGPSEC > > signature chain and not removed. > > > > > > > Jakob, > > > > OK, you are proposing a separate signature chain besides the > BGPSEC > > sig chain. > > But any signature chain must continue end-to-end across the whole > AS > > path. > > Because, if a signature chain is allowed to be removed at any > point in > > the path, then it becomes vulnerable to cut and paste attack. > > Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1], > > where AS1 is origin. > > Let us say, AS2 removed your proposed first attribute and the > > associated signature, and forwarded the update to its customer AS3. > > Now AS3 forwards the update to its customer AS4. > > AS4 can somehow learn that AS1 sent the first attribute to AS2 and > > signed it, and it can somehow get that whole 'goop' (i.e. the > > attribute and the sig of AS1). > > Then AS4 can add back the 'goop', and forward the update to its > > *upstream provider* AS5, and AS5 would be fooled and oblivious of > the > > leak. > > > > (Note: Again think of the reason why partial path signatures are > > disallowed in BGPSEC. > > The same principles should apply here too with any other proposed > sig > > chain.) > > > > Sriram > > From nobody Thu Jul 31 11:32:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43991A011D for ; Thu, 31 Jul 2014 11:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_MbQWmORh-V for ; Thu, 31 Jul 2014 11:32:15 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F306D1A014F for ; Thu, 31 Jul 2014 11:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5903; q=dns/txt; s=iport; t=1406831535; x=1408041135; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=RDeGmyHCKl59W6XgaPKG40MQW1ZwTHdMGJVLrP6RRyc=; b=lu63jgSfj+KhB4Ggo/7btSTwMR7dlI+MJph+w4vLt0ARl6JI5n2UecEO ck/HHWXb8+d/LMPPZRodeNF9/cpvDNTbaHDl3yoAfS/LE6sIxtT2nLT/y mEVESmLL6E0KGkJo04mZSX2Suy06BE23MuaDK1fQEuM07ze8rH/NmVSw5 8=; X-IronPort-AV: E=Sophos;i="5.01,773,1400025600"; d="scan'208";a="65551977" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 31 Jul 2014 18:32:14 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6VIWDpI026631; Thu, 31 Jul 2014 18:32:14 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id 82980423; Thu, 31 Jul 2014 14:32:13 -0400 (EDT) From: Eric Rosen To: John Scudder In-reply-to: Your message of Tue, 22 Jul 2014 15:43:28 -0400. <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3542.1406831533.1@erosen-lnx> Date: Thu, 31 Jul 2014 14:32:13 -0400 Message-ID: <3543.1406831533@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/PrzzjL-v86IFS2lz2q03DDiTXzk Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 18:32:23 -0000 I do not support adoption of this draft in its current form. My comments fall roughly into three categories: (a) the comparison with RFC 5512 is based on a number of apparent misunderstandings of that RFC, (b) the description of the use cases is inadequate, and (c) the proposed mechanisms themselves are questionable in some respects and severely underspecified in others. The draft states: The Tunnel Encapsulation attribute [RFC5512] is based on the principle that the tunnel end-point is the BGP speaker originating the update While that is the use case that was envisioned when RFC 5512 was written, I don't see anything in that document that prevents a BGP speaker from originating an Encapsulation-SAFI update whose NLRI identifies a different endpoint. The draft further states: It is also assumed [by RFC 5512] that there is only a single tunnel between endpoints. That is certainly not the case. RFC 5512 defines a Tunnel Encapsulation attribute consisting of a set of TLVs. Each TLV identifies a tunnel type. If there are multiple tunnels, the attribute contains multiple TLVs. There is nothing to prevent the attribute from contains multiple TLVs identifying the same tunnel type, but specifying different encapsulation information for each tunnel. Thus not only are multiple tunnels allowed between a pair of endpoints, but it is even allowable to have multiple tunnels of the same type between a pair of endpoints. Further, each tunnel can be assigned a "color", and an individual prefix can be matched to a particular tunnel by means of the color extended community. This method was chosen in order to avoid the need to send the encaps information with each and every prefix that is to travel through the tunnel. Rather, it is sent only once per endpoint. Also, with the RFC 5512 mechanisms, there is no need to modify any of the existing BGP procedures in which the "next hop" is used, as each prefix still has just one next hop. With regard to the "IPv6 multi-homing use case", I just can't figure out how the remote-next-hop attribute is supposed to be used to handle this case. (I believe Bruno and Yakov have made the same point.) With regard to the other use cases, all the draft really says is "maybe this attribute would be useful in these cases". It does not provide anything like enough detail to convince anyone that the attribute is a good solution for those use cases, or that it is better than various alternatives. When you read a section on use cases, you should at least be able to come away with an idea of how the proposed mechanism is intended to be used in those cases ;-) and why it is better than some obvious alternatives. Sections 5.6 and 5.7 appear in the "use cases" section, but do not seem to be about use cases at all. One can also ask many questions about the proposed attribute itself, and about the related procedures. (See, e.g., Bruno's and Jeff's messages in this thread.) Actually, the draft doesn't say much about procedures at all. The overall problem is that each update now specifies not one, but two next hops for each prefix, and this gives rise to a number of questions that are not addressed in the draft. Here are a few questions that come to mind immediately: - Why exactly is it necessary to have both a "next hop" and a "remote next hop"? - BGP will not install a route if the next hop is not resolvable. But there is nothing in the draft that says not to install a route if the remote next hop is not resolvable. I don't really get this; do we really want to select a particular route if its next hop is resolvable but its remote next hop isn't? (Especially since the data is supposed to go to the remote next hop.) - Can we get into a situation where two routes have the same next hop but different remote next hops? If we reach the decision process tie-breaker step that chooses the route with the closest next hop, we might end up choosing the route that does not have the closest remote next hop. Since the remote next hop is where we want to send the data, does this make sense? - Suppose a given route does not have a remote next hop, but when we do recursive resolution of the next hop we encounter a route that does have a remote next hop. Are we supposed to use that remote next hop? - When a remote next hop attribute is attached to a labeled address, do we assume that the label has been assigned by the remote next hop, or by the next hop? If a BGP speaker changes the next hop but not the remote next hop, does it have to assign a new label? - Is it even valid to change the next hop without changing or removing the remote next hop attribute? - Since the remote next hop attribute is a transitive attribute, it can easily be leaked outside of the administrative domain to which it applies. This could result in all kinds of strange effects on the routing upstream. (One might point out that in the RFC 5512 model, it is less likely that information leaks out, since the encapsulation-SAFI would have to be explicitly enabled.) - Applicability of the remote next hop attribute is not restricted to any particular set of address families, but it is not obvious what if anything it might mean to attach the attribute to address families other than the unicast routing address families. - The attribute as defined contains an AS number, but there are no procedures specified that make use of the AS number. - The address family of the tunnel endpoint needs to be inferred from its length; it might be better to explicitly encode the address family. I think this draft needs both additional justification and additional detail before it can be adopted. From nobody Thu Jul 31 12:00:11 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10071A00C2 for ; Thu, 31 Jul 2014 12:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w65FiFlwaf5g for ; Thu, 31 Jul 2014 12:00:05 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD551A003A for ; Thu, 31 Jul 2014 12:00:05 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id tr6so4305170ieb.21 for ; Thu, 31 Jul 2014 12:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=16iXLgkmqtd6ypOBf+wf7Q9yzrUFf0zTRLp9y98Z4UE=; b=PybcpLGselTj0cPpA7pGBaWQIxT6wUE8KsxuQPtqn9aUjAboT73wKpmMcldGKnGm2m 8ZSWA0DpiOTJxqCHnwnNb4tmLZf75YerLO8uu4uNfXjpGALo22es7o8pCx3MnOrgFCXO 4eSLmGyCm0UaWSI+zlQfBQ2FX8ivnG6Trd5MCLTtjiT/TVm+3cSMhOaX8/erIgw7JFH4 NeQDB6crVtuyJP6HiV1tO69P9pZDadUTcxTCn0gXsCfCyzP5DElRUN+s6e6iL+725Frv H04DLCi2MhPkG16GRKPxpvTv8KeSPiHJ/DXQCN6d4RaG0q0stCuDJCnc7v+BwALpl6cD I7LQ== MIME-Version: 1.0 X-Received: by 10.50.61.195 with SMTP id s3mr212053igr.29.1406833204872; Thu, 31 Jul 2014 12:00:04 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Thu, 31 Jul 2014 12:00:04 -0700 (PDT) In-Reply-To: <3543.1406831533@erosen-lnx> References: <0A3ECC2D-56CB-4A9E-B6FA-AF6FBE77DFB7@juniper.net> <3543.1406831533@erosen-lnx> Date: Thu, 31 Jul 2014 21:00:04 +0200 X-Google-Sender-Auth: qw5Pbg5LTkzK-RSawhNUfq4nudo Message-ID: From: Robert Raszuk To: "erosen@cisco.com" Content-Type: multipart/alternative; boundary=047d7bdc05f26f4db304ff81e16f Archived-At: http://mailarchive.ietf.org/arch/msg/idr/eUzx4EKy8inCJ7PnGcQUz7e00VU Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 19:00:09 -0000 --047d7bdc05f26f4db304ff81e16f Content-Type: text/plain; charset=UTF-8 Hi Eric, Let me make one point which in fact was the reason why my former work on remote next hop ended up merged here. RFC5512 is fine as it is for number of applications and I do agree with most of your observations made. However RFC5512 the way it is written today unfortunately does not provide a mechanism to encode the remote next hop (tunnel termination dst) without new SAFI. That as you must very well be aware has huge deployment problem if your information should cross N domains - which btw may have no interest what so ever to support such SAFI. Therefor I would like to highlight that while there are other forms such information can be exchanged (maybe even more preferable then sending it within BGP) spawning a new SAFI for that is unfortunately not one of them :( Historically BGPv4 Tunnel Encapsulation Attribute draft-kapoor-nalawade-idr-bgp-ssa-02.txt written by Ruchi & Gargi got replaced by RFC5512 since exactly instead of using attribute within current address families we have all decided that for applications at hand at that time having independent SAFI is a better choice. To conclude I would not object if we would respin RFC5512 and state that the attribute can be used standalone as well as we add few more encapsulations to it :) Cheers, R. On Thu, Jul 31, 2014 at 8:32 PM, Eric Rosen wrote: > I do not support adoption of this draft in its current form. > > My comments fall roughly into three categories: (a) the comparison with RFC > 5512 is based on a number of apparent misunderstandings of that RFC, (b) > the > description of the use cases is inadequate, and (c) the proposed mechanisms > themselves are questionable in some respects and severely underspecified in > others. > > The draft states: > > The Tunnel Encapsulation attribute [RFC5512] is based on the > principle that the tunnel end-point is the BGP speaker > originating the update > > While that is the use case that was envisioned when RFC 5512 was written, I > don't see anything in that document that prevents a BGP speaker from > originating an Encapsulation-SAFI update whose NLRI identifies a different > endpoint. > > The draft further states: > > It is also assumed [by RFC 5512] that there is only a single > tunnel between endpoints. > > That is certainly not the case. > > RFC 5512 defines a Tunnel Encapsulation attribute consisting of a set of > TLVs. Each TLV identifies a tunnel type. If there are multiple tunnels, > the attribute contains multiple TLVs. There is nothing to prevent the > attribute from contains multiple TLVs identifying the same tunnel type, but > specifying different encapsulation information for each tunnel. Thus not > only are multiple tunnels allowed between a pair of endpoints, but it is > even allowable to have multiple tunnels of the same type between a pair of > endpoints. Further, each tunnel can be assigned a "color", and an > individual > prefix can be matched to a particular tunnel by means of the color extended > community. > > This method was chosen in order to avoid the need to send the encaps > information with each and every prefix that is to travel through the > tunnel. Rather, it is sent only once per endpoint. Also, with the RFC > 5512 > mechanisms, there is no need to modify any of the existing BGP procedures > in > which the "next hop" is used, as each prefix still has just one next hop. > > With regard to the "IPv6 multi-homing use case", I just can't figure out > how > the remote-next-hop attribute is supposed to be used to handle this case. > (I believe Bruno and Yakov have made the same point.) With regard to the > other use cases, all the draft really says is "maybe this attribute would > be > useful in these cases". It does not provide anything like enough detail to > convince anyone that the attribute is a good solution for those use cases, > or that it is better than various alternatives. When you read a section on > use cases, you should at least be able to come away with an idea of how the > proposed mechanism is intended to be used in those cases ;-) and why it is > better than some obvious alternatives. > > Sections 5.6 and 5.7 appear in the "use cases" section, but do not seem to > be about use cases at all. > > One can also ask many questions about the proposed attribute itself, and > about the related procedures. (See, e.g., Bruno's and Jeff's messages in > this thread.) Actually, the draft doesn't say much about procedures at > all. The overall problem is that each update now specifies not one, but two > next hops for each prefix, and this gives rise to a number of questions > that > are not addressed in the draft. Here are a few questions that come to mind > immediately: > > - Why exactly is it necessary to have both a "next hop" and a "remote next > hop"? > > - BGP will not install a route if the next hop is not resolvable. But > there > is nothing in the draft that says not to install a route if the remote > next hop is not resolvable. I don't really get this; do we really want > to > select a particular route if its next hop is resolvable but its remote > next hop isn't? (Especially since the data is supposed to go to the > remote next hop.) > > - Can we get into a situation where two routes have the same next hop but > different remote next hops? If we reach the decision process tie-breaker > step that chooses the route with the closest next hop, we might end up > choosing the route that does not have the closest remote next hop. Since > the remote next hop is where we want to send the data, does this make > sense? > > - Suppose a given route does not have a remote next hop, but when we do > recursive resolution of the next hop we encounter a route that does have > a > remote next hop. Are we supposed to use that remote next hop? > > - When a remote next hop attribute is attached to a labeled address, do we > assume that the label has been assigned by the remote next hop, or by the > next hop? If a BGP speaker changes the next hop but not the remote next > hop, does it have to assign a new label? > > - Is it even valid to change the next hop without changing or removing the > remote next hop attribute? > > - Since the remote next hop attribute is a transitive attribute, it can > easily be leaked outside of the administrative domain to which it > applies. This could result in all kinds of strange effects on the > routing > upstream. (One might point out that in the RFC 5512 model, it is less > likely that information leaks out, since the encapsulation-SAFI would > have > to be explicitly enabled.) > > - Applicability of the remote next hop attribute is not restricted to any > particular set of address families, but it is not obvious what if > anything > it might mean to attach the attribute to address families other than the > unicast routing address families. > > - The attribute as defined contains an AS number, but there are no > procedures specified that make use of the AS number. > > - The address family of the tunnel endpoint needs to be inferred from its > length; it might be better to explicitly encode the address family. > > I think this draft needs both additional justification and additional > detail > before it can be adopted. > > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7bdc05f26f4db304ff81e16f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Eric,

Let me make one point which in fact was the r= eason why my former work on remote next hop ended up merged here.=C2=A0

RFC5512 is fine as it is for number of ap= plications and I do agree with most of your observations made.=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:'courier new',mono= space;font-size:small">
However RFC5512 the way it is written tod= ay unfortunately does not provide a mechanism to encode the remote next hop= (tunnel termination dst) without new SAFI. That as you must very well be a= ware has huge deployment problem if your information should cross N domains= - which btw may have no interest what so ever to support such SAFI.=C2=A0<= /div>

Therefor I would = like to highlight that while there are other forms such information can be = exchanged (maybe even more preferable then sending it within BGP) spawning = a new SAFI for that is unfortunately not one of them :(

Histo= rically BGPv4 Tunnel Encapsula= tion Attribute=C2=A0draft-kapoor-nalawade-idr-bgp-ssa-02.txt=C2=A0written by Ruchi & Ga= rgi got replaced by RFC5512 since exactly instead of using attribute within= current address families we have all decided that for applications at hand= at that time having independent SAFI is a better choice.=C2=A0

To conclude I woul= d not object if we would respin RFC5512 and state that the attribute can be= used standalone as well as we add few more encapsulations to it :)<= /div>

Cheers,
R.
=


<= br>
On Thu, Jul 31, 2014 at 8:32 PM, Eric Rosen <erosen@cisco.com> wrote:
I do not support adoption of this draft in its current form.

My comments fall roughly into three categories: (a) the comparison with RFC=
5512 is based on a number of apparent misunderstandings of that RFC, (b) th= e
description of the use cases is inadequate, and (c) the proposed mechanisms=
themselves are questionable in some respects and severely underspecified in=
others.

The draft states:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The Tunnel Encapsulation attribute [RFC5512] is= based on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 principle that the tunnel end-point is the BGP = speaker
=C2=A0 =C2=A0 =C2=A0 =C2=A0 originating the update

While that is the use case that was envisioned when RFC 5512 was written, I=
don't see anything in that document that prevents a BGP speaker from originating an Encapsulation-SAFI update whose NLRI identifies a different<= br> endpoint.

The draft further states:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 It is also assumed [by RFC 5512] that there is = only a single
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tunnel between endpoints.

That is certainly not the case.

RFC 5512 defines a Tunnel Encapsulation attribute consisting of a set of TLVs. =C2=A0Each TLV identifies a tunnel type. =C2=A0If there are multiple = tunnels,
the attribute contains multiple TLVs. =C2=A0There is nothing to prevent the=
attribute from contains multiple TLVs identifying the same tunnel type, but=
specifying different encapsulation information for each tunnel. =C2=A0Thus = not
only are multiple tunnels allowed between a pair of endpoints, but it is even allowable to have multiple tunnels of the same type between a pair of<= br> endpoints. =C2=A0Further, each tunnel can be assigned a "color", = and an individual
prefix can be matched to a particular tunnel by means of the color extended=
community.

This method was chosen in order to avoid the need to send the encaps
information with each and every prefix that is to travel through the
tunnel. =C2=A0Rather, it is sent only once per endpoint. =C2=A0Also, with t= he RFC 5512
mechanisms, there is no need to modify any of the existing BGP procedures i= n
which the "next hop" is used, as each prefix still has just one n= ext hop.

With regard to the "IPv6 multi-homing use case", I just can't= figure out how
the remote-next-hop attribute is supposed to be used to handle this case. (I believe Bruno and Yakov have made the same point.) =C2=A0With regard to = the
other use cases, all the draft really says is "maybe this attribute wo= uld be
useful in these cases". =C2=A0It does not provide anything like enough= detail to
convince anyone that the attribute is a good solution for those use cases,<= br> or that it is better than various alternatives. =C2=A0When you read a secti= on on
use cases, you should at least be able to come away with an idea of how the=
proposed mechanism is intended to be used in those cases ;-) and why it is<= br> better than some obvious alternatives.

Sections 5.6 and 5.7 appear in the "use cases" section, but do no= t seem to
be about use cases at all.

One can also ask many questions about the proposed attribute itself, and about the related procedures. =C2=A0(See, e.g., Bruno's and Jeff's = messages in
this thread.) =C2=A0Actually, the draft doesn't say much about procedur= es at
all. The overall problem is that each update now specifies not one, but two=
next hops for each prefix, and this gives rise to a number of questions tha= t
are not addressed in the draft. =C2=A0Here are a few questions that come to= mind
immediately:

- Why exactly is it necessary to have both a "next hop" and a &qu= ot;remote next
=C2=A0 hop"?

- BGP will not install a route if the next hop is not resolvable. =C2=A0But= there
=C2=A0 is nothing in the draft that says not to install a route if the remo= te
=C2=A0 next hop is not resolvable. =C2=A0I don't really get this; do we= really want to
=C2=A0 select a particular route if its next hop is resolvable but its remo= te
=C2=A0 next hop isn't? =C2=A0(Especially since the data is supposed to = go to the
=C2=A0 remote next hop.)

- Can we get into a situation where two routes have the same next hop but =C2=A0 different remote next hops? =C2=A0If we reach the decision process t= ie-breaker
=C2=A0 step that chooses the route with the closest next hop, we might end = up
=C2=A0 choosing the route that does not have the closest remote next hop. = =C2=A0Since
=C2=A0 the remote next hop is where we want to send the data, does this mak= e
=C2=A0 sense?

- Suppose a given route does not have a remote next hop, but when we do
=C2=A0 recursive resolution of the next hop we encounter a route that does = have a
=C2=A0 remote next hop. =C2=A0Are we supposed to use that remote next hop?<= br>
- When a remote next hop attribute is attached to a labeled address, do we<= br> =C2=A0 assume that the label has been assigned by the remote next hop, or b= y the
=C2=A0 next hop? =C2=A0If a BGP speaker changes the next hop but not the re= mote next
=C2=A0 hop, does it have to assign a new label?

- Is it even valid to change the next hop without changing or removing the<= br> =C2=A0 remote next hop attribute?

- Since the remote next hop attribute is a transitive attribute, it can
=C2=A0 easily be leaked outside of the administrative domain to which it =C2=A0 applies. =C2=A0This could result in all kinds of strange effects on = the routing
=C2=A0 upstream. =C2=A0(One might point out that in the RFC 5512 model, it = is less
=C2=A0 likely that information leaks out, since the encapsulation-SAFI woul= d have
=C2=A0 to be explicitly enabled.)

- Applicability of the remote next hop attribute is not restricted to any =C2=A0 particular set of address families, but it is not obvious what if an= ything
=C2=A0 it might mean to attach the attribute to address families other than= the
=C2=A0 unicast routing address families.

- The attribute as defined contains an AS number, but there are no
=C2=A0 procedures specified that make use of the AS number.

- The address family of the tunnel endpoint needs to be inferred from its =C2=A0 length; it might be better to explicitly encode the address family.<= br>
I think this draft needs both additional justification and additional detai= l
before it can be adopted.








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

--047d7bdc05f26f4db304ff81e16f-- From nobody Thu Jul 31 16:00:03 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8911A01D6; Thu, 31 Jul 2014 15:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX7yfZI_cjNX; Thu, 31 Jul 2014 15:59:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D01981A01FF; Thu, 31 Jul 2014 15:59:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140731225951.12381.64162.idtracker@ietfa.amsl.com> Date: Thu, 31 Jul 2014 15:59:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/w-0mPU3j6ofSiLcS2LWgI-EyVDA Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-optimal-route-reflection-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 22:59:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Optimal Route Reflection (BGP-ORR) Authors : Robert Raszuk Christian Cassar Erik Aman Bruno Decraene Stephane Litkowski Filename : draft-ietf-idr-bgp-optimal-route-reflection-07.txt Pages : 22 Date : 2014-07-31 Abstract: [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." One practical implication of this assertion is that the deployment of route reflection may thwart the ability to achieve hot potato routing. Hot potato routing attempts to direct traffic to the closest AS egress point in cases where no higher priority policy dictates otherwise. As a consequence of the route reflection method, the choice of exit point for a route reflector and its clients will be the egress point closest to the route reflector - and not necessarily closest to the RR clients. Section 11 of [RFC4456] describes a deployment approach and a set of constraints which, if satsified, would result in the deployment of route reflection yielding the same results as the iBGP full mesh approach. Such a deployment approach would make route reflection compatible with the application of hot potato routing policy. As networks evolved to accommodate architectural requirements of new services, tunneled (LSP/IP tunneling) networks with centralized route reflectors became commonplace. This is one type of common deployment where it would be impractical to satisfy the constraints described in Section 11 of [RFC4456]. Yet, in such an environment, hot potato routing policy remains desirable. This document proposes two new solutions which can be deployed to facilitate the application of closest exit point policy centralized route reflection deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-optimal-route-reflection-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/