From daniele.ceccarelli@ericsson.com Mon Oct 1 00:55:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF62021F85F7 for ; Mon, 1 Oct 2012 00:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[AWL=-2.271, BAYES_00=-2.599, CN_BODY_35=0.339, HELO_EQ_SE=0.35, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swPqKr29Ij3y for ; Mon, 1 Oct 2012 00:55:31 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 825BE21F85B6 for ; Mon, 1 Oct 2012 00:55:30 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-26-50694c71a3c1 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D8.B4.11467.17C49605; Mon, 1 Oct 2012 09:55:29 +0200 (CEST) Received: from ESESSHC024.ericsson.se (153.88.183.90) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 1 Oct 2012 09:55:28 +0200 Received: from ESESSMB301.ericsson.se ([169.254.1.169]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.001; Mon, 1 Oct 2012 09:55:28 +0200 From: Daniele Ceccarelli To: Hejia , Loa Andersson Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2WVF0044Z6H4YJS2qLtfNpzxzcsQHy4PQAAGKFy2A= Date: Mon, 1 Oct 2012 07:55:28 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48CF36@ESESSMB301.ericsson.se> References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> In-Reply-To: <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM+JvrW6hT2aAwZknQhafjq1ltzizt9ai Zco7Zot/c+cwW3y/tITF4tbSlawObB4tR96yeixZ8pPJ49etSawes6a3sXl8ufyZLYA1issm JTUnsyy1SN8ugStj4fJlzAX7xCouPrBvYPwi2sXIySEhYCLxcMVGZghbTOLCvfVsXYxcHEIC pxglnh0+wAjh7GCUOLGqjwnCWcwoceV5L5DDwcEmYCXx5JAPSLeIgLnE/gU/WUBqmAX+MEpc mLCLCSQhLBAs0dq4jwWiKERix69WKNtKouncV1YQm0VAReLh9gtsIDavgKfEj48XwU4SEiiQ aLrYxghicwqEScy58JQdxGYUkJWYsHsRWJxZQFzi1pP5TBAvCEgs2XMe6h1RiZeP/7GC3Ckh oCixvF8OolxLYl7DbyYIW1FiSvdDdoi1ghInZz5hgVirI3HsTwPzBEaJWUg2zELSPgtJ+ywk 7QsYWVYxCucmZuaklxvqpRZlJhcX5+fpFaduYgTG68Etv3V3MJ46J3KIUZqDRUmclytpv7+Q QHpiSWp2ampBalF8UWlOavEhRiYOTqkGxlC/2ua6yudcK+IiNNZHc6+oOPLFOSBpG/fNX/KG n0VSn+QkzLxZvMBkoViuInt6H89d+ybNkDub/y/Z8HSjAkvL7Zo+Ru3uYxLN2fez/8n9u3TS UP2vztcTgVXnJ9xVmjn/sd9GOc0jP179nmB0X8DKw+/eA83+8jNyc15+Oxdvv8/8z9KW2Uos xRmJhlrMRcWJABYGEm+lAgAA Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 07:55:31 -0000 SGkgSmlhLA0KDQpDb3VsZCB5b3UgcGxlYXNlIGVsYWJvcmF0ZSB5b3VyIGNvbW1uZW50PyBXaGlj aCBkZWZpY2llbmNpZXMgYXJlIHlvdSB0YWxraW5nIGFib3V0Pw0KDQpCUg0KRGFuaWVsZSANCg0K Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiANCj5CZWhhbGYgT2YgSGVqaWENCj5T ZW50OiBzYWJhdG8gMjkgc2V0dGVtYnJlIDIwMTIgMTIuNTMNCj5UbzogTG9hIEFuZGVyc3Nvbg0K PkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTVBMUy1UUCBh ZCBob2MgDQo+dGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5p ZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24g DQo+ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KPg0KPkRvIG5vdCBzdXBwb3J0 Lg0KPg0KPkJhc2VkIG9uIHRoZSBhbmFseXNpcyBpbiBTZWN0aW9uIDIuNCBvZiANCj5kcmFmdC1p ZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAyLCB0aGUgcmluZyBwcm90ZWN0aW9uIA0KPnNj aGVtZSB1c2luZyBTUE1FIGFzIGRlc2NyaWJlZCwgZWl0aGVyIHdyYXBwaW5nIG9yIHN0ZWVyaW5n LCANCj5kb2VzIGhhdmUgZGVmaWNpZW5jaWVzLCB3aGljaCBJTUhPIHNob3VsZCBiZSBiZXR0ZXIg DQo+cmVjb25zaWRlcmVkIGFuZCBzb2x2ZWQgaWYgcG9zc2libGUuDQo+DQo+DQo+Qi5SLg0KPkpp YQ0KPg0KPi0tLS0t08q8/tStvP4tLS0tLQ0KPreivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIA0KPkxvYSBBbmRlcnNzb24NCj63 osvNyrG85DogMjAxMsTqOdTCMTnI1SAxODo0OQ0KPrOty806IG1wbHNAaWV0Zi5vcmc7IE1QTFMt VFAgYWQgaG9jIHRlYW07IA0KPmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9v bHMuaWV0Zi5vcmc7IA0KPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+1vfM4jogW21wbHNd IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIA0KPmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXBy b3RlY3Rpb24NCj4NCj5Xb3JraW5nIEdyb3VwLA0KPg0KPnRoaXMgaXMgdG8gc3RhcnQgYSB0d28g d2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiANCj5kcmFmdC1pZXRmLW1wbHMtdHAtcmlu Zy1wcm90ZWN0aW9uLTAyLXR4dC4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IHRoZXJlIGFyZSB0d28g SVBSIGRpc2Nsb3N1cmVzICMgMTQ2MiBhbmQgICMgDQo+MTg3MiByZWxhdGVkIHRvIHRoaXMgZG9j dW1lbnQuDQo+DQo+UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBscyB3b3JraW5n IGdyb3VwIG1haWxpbmcgDQo+bGlzdHMgKG1wbHNAaWV0Zi5vcmcpLg0KPg0KPlRoZSB3b3JraW5n IGdyb3VwIGxhc3QgY2FsbCBlbmRzIE9jdG9iZXIgMywgMjAxMi4NCj4NCj4vTG9hDQo+Zm9yIHRo ZSBtcGxzIHdnIGNvLWNoYWlycw0KPg0KPg0KPi0tIA0KPg0KPg0KPkxvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQo+ U3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51DQo+ RXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1 MiAxMw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYg NzY3IDcyIDkyIDEzIA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+bXBscyBtYWlsaW5nIGxpc3QNCj5tcGxzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5tcGxzIG1haWxpbmcgbGlzdA0KPm1wbHNAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4= From alessandro.dalessandro@telecomitalia.it Mon Oct 1 05:27:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6CF1F0C7E for ; Mon, 1 Oct 2012 05:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8XyPWCnMtxc for ; Mon, 1 Oct 2012 05:27:09 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id F04D41F0C72 for ; Mon, 1 Oct 2012 05:27:08 -0700 (PDT) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 1 Oct 2012 14:27:05 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by grfhub702rm001.griffon.local ([10.19.9.235]) with mapi; Mon, 1 Oct 2012 14:27:03 +0200 From: D'Alessandro Alessandro Gerardo To: Loa Andersson Date: Mon, 1 Oct 2012 14:27:01 +0200 Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: AQHNllRf82qjNdoiA0OJzsZi6RX7kJehLihwgANBJaA= Message-ID: References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> In-Reply-To: <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 12:27:10 -0000 RG8gbm90IHN1cHBvcnQNCg0KQWNjb3JkaW5nIHRvIHRoZSBvcHRpbWl6YXRpb24gY3JpdGVyaWEg Zm9yIHJpbmcgcHJvdGVjdGlvbiBzcGVjaWZpZWQgaW4gU2VjdGlvbiAyLjUuNi4xIGluIFJGQzU2 NTQsIHRoZSBNUExTLVRQIHJpbmcgcHJvdGVjdGlvbiBzaG91bGQgYmUgb3B0aW1pemVkIGZvciBz aW1wbGlmaWNhdGlvbiBvZiB0aGUgcmluZyBvcGVyYXRpb24gYW5kIHRoZSByZXNvdXJjZXMgY29u c3VtcHRpb24gYXJvdW5kIHRoZSByaW5nLiBJdCBpcyBub3QgdGhlIGNhc2Ugb2YgdGhlIHByb3Bv c2VkIHNvbHV0aW9uLg0KSXQgaXMgYWN0dWFsbHkgc2ltcGx5IGFuIGFwcGxpY2FiaWxpdHkgc3Rh dGVtZW50IG9mIGEgbGluZWFyIHByb3RlY3Rpb24gbWVjaGFuaXNtIGJ1dCBpdCBjYW5ub3QgYmUg Y29uc2lkZXIgYSBzb2x1dGlvbiB0aGF0IGFkZHJlc3NlcyB0aGUgcmVxdWlyZW1lbnRzIGZvciBw cm90ZWN0aW9uIG9mIHJpbmcgdG9wb2xvZ2llcyBmb3IgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dp dGNoaW5nIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBhcyBzcGVjaWZpZWQgaW4gUkZDNTY1 NC4NCg0KQmVzdCByZWdhcmRzLA0KQWxlc3NhbmRybw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRlbGVjb20gSXRh bGlhDQpBbGVzc2FuZHJvIEdlcmFyZG8gRCdBbGVzc2FuZHJvDQpUcmFuc3BvcnQgSW5ub3ZhdGlv bg0KVmlhIFJlaXNzIFJvbW9saSwgMjc0IC0gMTAxNDggVG9yaW5vDQpwaG9uZTogICszOSAwMTEg MjI4IDU4ODcNCm1vYmlsZTogKzM5IDMzNSA3NjYgOTYwNw0KZmF4OiArMzkgMDYgNDE4IDYzOSAw Nw0KDQoNCi0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0tDQpEYTogbXBscy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBQZXIgY29udG8gZGkgSGVqaWEN CkludmlhdG86IHNhYmF0byAyOSBzZXR0ZW1icmUgMjAxMiAxMjo1Mw0KQTogTG9hIEFuZGVyc3Nv bg0KQ2M6IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBNUExTLVRQ IGFkIGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmll dGYub3JnDQpPZ2dldHRvOiBSZTogW21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRy YWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0KRG8gbm90IHN1cHBvcnQuDQoNCkJh c2VkIG9uIHRoZSBhbmFseXNpcyBpbiBTZWN0aW9uIDIuNCBvZiBkcmFmdC1pZXRmLW1wbHMtdHAt cmluZy1wcm90ZWN0aW9uLTAyLCB0aGUgcmluZyBwcm90ZWN0aW9uIHNjaGVtZSB1c2luZyBTUE1F IGFzIGRlc2NyaWJlZCwgZWl0aGVyIHdyYXBwaW5nIG9yIHN0ZWVyaW5nLCBkb2VzIGhhdmUgZGVm aWNpZW5jaWVzLCB3aGljaCBJTUhPIHNob3VsZCBiZSBiZXR0ZXIgcmVjb25zaWRlcmVkIGFuZCBz b2x2ZWQgaWYgcG9zc2libGUuDQoNCg0KQi5SLg0KSmlhDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCuWPkeS7tuS6ujogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnXSDku6PooaggTG9hIEFuZGVyc3Nvbg0K5Y+R6YCB5pe26Ze0OiAyMDEy5bm0Oeac iDE55pelIDE4OjQ5DQrmioTpgIE6IG1wbHNAaWV0Zi5vcmc7IE1QTFMtVFAgYWQgaG9jIHRlYW07 IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc7IG1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnDQrkuLvpopg6IFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoNCldvcmtpbmcgR3Jv dXAsDQoNCnRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBvbg0KZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMi10eHQuDQoNClBsZWFz ZSBub3RlIHRoYXQgdGhlcmUgYXJlIHR3byBJUFIgZGlzY2xvc3VyZXMgIyAxNDYyIGFuZCAgIyAx ODcyDQpyZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQuDQoNClBsZWFzZSBzZW5kIHlvdXIgY29tbWVu dHMgdG8gdGhlIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3RzDQoobXBsc0BpZXRmLm9y ZykuDQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIE9jdG9iZXIgMywgMjAxMi4N Cg0KL0xvYQ0KZm9yIHRoZSBtcGxzIHdnIGNvLWNoYWlycw0KDQoNCi0tDQoNCg0KTG9hIEFuZGVy c3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nv bi5jb20NClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBw aS5udQ0KRXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEw IDcxNyA1MiAxMw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICs0NiA3NjcgNzIgOTIgMTMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQpRdWVzdG8gbWVz c2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUg YWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBh bHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6 aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRv IHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBk aSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRl cmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlv biwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlz ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5 IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0K From gregory.mirsky@ericsson.com Mon Oct 1 08:53:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB9F1F0CCD for ; Mon, 1 Oct 2012 08:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.56 X-Spam-Level: X-Spam-Status: No, score=-5.56 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx7jwA8mIrcl for ; Mon, 1 Oct 2012 08:53:32 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1221F0C7E for ; Mon, 1 Oct 2012 08:53:32 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q91G0WEm001448; Mon, 1 Oct 2012 11:00:34 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.138]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 1 Oct 2012 11:53:26 -0400 From: Gregory Mirsky To: "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" , "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-chairs@tools.ietf.org" Date: Mon, 1 Oct 2012 11:53:25 -0400 Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2WVF/P8cniMzqKQNCrZ/7Id6/cNAFzVtSw Message-ID: References: <5059A308.3050307@pi.nu> In-Reply-To: <5059A308.3050307@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF139284003C4EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:53:36 -0000 --_000_FE60A4E52763E84B935532D7D9294FF139284003C4EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, Editors, WG Chairs, et al., Please find my comments to the document below: * Section 2.1 * Verbal explanation of the wrapping in the first paragraph might ben= efit if LSRs be referenced as in Figure 1. * As described, wrapping can provide local protection of bi-direction= al co-routed LSP only in case of link failure. If node protection requested= , as mentioned in the third sentence of the first para, MP is not the downs= tream LSR but next down to downstream. If we expect that PLR in forward dir= ection is MP in reverse direction of given bi-directional LSP, then we have= case of segment, not local protection. (Same, I believe, applies to FRR of= bi-directional co-routed p2p LSP). * s/arounf/around/ * Figure 1 I think that this figure illustrates wrapping of a single = direction in case of local link protection. If that is the intention, then = caption might explicitly state that. If a case of a bi-directional LSP to b= e illustrated for local link protection, then another wrapped data path F-E= -D-C-B-A might be added. * "If protecting both the links and the nodes of a LSP, then, for a r= ing with N nodes, there is a need for O(2N) alternate paths." I assume that= this estimate is for bi-directional co-routed p2p LSP. But co-routed LSP i= mplies coordinated protection which, as mentined before, can not be achieve= d for node protection with local protection. Coordinated node protection, i= f not end-to-end, can be in form of segment protection. * Section 2.2 * "The process of notifying the ingress node adds to the latency of t= he protection switching process, after the detection of the fault condition= ." I think that that is not necessarily true as ingress notification doesn'= t have to be explicit but can be implicit if e2e CC/CV monitors working and= protecting paths. * Very last para "... there is the necessity for the ring to maintain= enough capacity for all of the data in both directions around the ring" se= ems as too strong requirement considering cases of 1:N linear and shared me= sh protection, where bandwidth of a protection path shared. * Section 2.3 * "... since we will perform all of the OAM functionality on the SPME= configured for the traffic, we can minimize the number of OAM sessions nee= ded to monitor the data traffic of the ring - rather than monitoring each i= ndividual LSP." Such improvement in OAM scale doesn't come for free as SPME= OAM might introduce or hide connectivity and/or continuity defects of encl= osed LSPs. * "In all of the following subsections, we use 1:1 linear protection = [SurvivFwk] [LinProtect] to perform protection switching and coordination w= hen a signal fault is detected." For 1:1 linear protection scope of the RFC= 6378 is limited to bi-directional p2p MPLS-TP constructs. "Applicability o= f the protocol for 1:1 unidirectional protection and for 1:n protection sch= emes may be documented in a future document and is out of scope for this do= cument", stated in section 1.2. Thus use of PSC for unidirectional p2p and = p2mp MPLS-TP constructs is undefined. Perhaps this has to be mentioned and = reflected in change of the scope of the document. * Section 2.3.1 * First para "... each one acts as the ingress and egress in one dire= ction of the bidirectional SPME". I think that terminology "ingress/egress = MEP" is not the best and perhaps view of nodal MEP per LSP is sufficient, s= o that no need to split MEP on given LSP per direction. * Section 2.3.2 * I think that title of the section needs to say explicitly that link= protection by wrapping is discussed in the section (node protection in the= 2.3.3) * Section 2.3.3 * As mentioned, in case of bi-directional co-routed LSP to which node= protection required (Figure 4) SPME approach is, effectively, segment, not= local protection. SPME level OAM between LSR A and LSR E monitors not only= link between LSR A and LSR F and LSR F but link between LSR F and LSR E as= well (from LSP POV). The primary SPME, effectively, changes ring topology = by excluding LSR F from topology as LSR F would not be processing LSP's out= er label but process only SPME's outer label. * Section 2.3.4 * Local node protection monitors immediate link for link as well as n= ode protection. The difference between these protection modes in selection = of a MP, whether immediate neighbor can (link protection) or can not (node = protection) be used as MP. The section seems based on misunderstanding of d= ifference between local link and node protection and might be removed. * Section 2.4 * s/steeing/steering/ * What are three OAM sessions that each ring node will have if wrappi= ng used to protect the ring? I see two OAM sessions: immediate link to down= stream LSR; around ring to the same LSR. Where the third OAM session? * "Special consideration" seems as unfounded: * Not clear why CC/CV OAM in case of SPME steering viewed as insuffic= ient for fast defect detection. * Local node and link protection are not mutualy exclusive. Local nod= e protection provides link protection as part of node protection. The probl= em, from my POV, is that bi-directional co-routed LSP can not have local no= de protection but only segment protection. * Section 3 * As noted earlier, applicability of RFC 6378 and PSC for 1:1 linear = protection of unidirectional MPLS-TP constructs, including unidirectional p= 2mp LSP, not yet been defined. Neither CC/CV OAM on these constructs. What = mechanism(s) could be used to perform defect detection, coordination and pr= otections switchover? * Section 4 * As as stated in RFC 6378 "Applicability of the protocol [PSC, my no= te] for 1:1 unidirectional protection and for 1:n protection schemes may be= documented in a future document and is out of scope for this document". A note on textual conventions: * References are both direct RFC, e.g. [RFC4090], and content-based, = i.e. [TPReqs]. May consider choosing single style of referencing. Thank you for your kind consideration. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Wednesday, September 19, 2012 3:49 AM Cc: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@= tools.ietf.org; mpls-chairs@tools.ietf.org Subject: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protecti= on Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-r= ing-protection-02-txt. Please note that there are two IPR disclosures # 1462 and # 1872 related t= o this document. Please send your comments to the mpls working group mailing lists (mpls@iet= f.org). The working group last call ends October 3, 2012. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ____________= ___________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_FE60A4E52763E84B935532D7D9294FF139284003C4EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, Editors, WG Chairs, et al.,
Please find my comments to the document below:
  • Section 2.1
  • Verbal explanation of the wrapping in the first paragraph might benefit= if LSRs be referenced as in Figure 1.
  • As described, wrapping can p= rovide local protection of bi-directional co-routed LSP only in case of lin= k failure. If node protection requested, as mentioned in the third sentence= of the first para, MP is not the downstream LSR but next down to downstrea= m. If we expect that PLR in forward direction is MP in reverse direction of gi= ven bi-directional LSP, then we have case of segment, not local protection.= (Same, I believe, applies to FRR of bi-directional co-routed p2p LSP).
  • s/arounf/around/
  • Figure 1 I think that this figure illustrates= wrapping of a single direction in case of local link protection. If that i= s the intention, then caption might explicitly state that. If a case of a b= i-directional LSP to be illustrated for local link protection, then another wrapped data path F-E-D-C-B-A might be added.
  • "If protecting both the links and the nodes o= f a LSP, then, for a ring with N no= des, there is a need for O(2N) alte= rnate paths." I assume that this estimate is for bi-directional co-routed p2p LSP. But co-routed LSP im= plies coordinated protection which, as mentined before, can not be achieved= for node protection with local protection. Coordinated node protection, if= not end-to-end, can be in form of segment protection.
  • Section 2.2
  • "The process of notifying the ingress node adds to the latency of = the protection switching process, after the detection of the fault conditio= n." I think that that is not necessarily true as ingress notification = doesn't have to be explicit but can be implicit if e2e CC/CV monitors working and protecting paths.
  • Very last para = "… there is the necessity for the ring to maintain enough capaci= ty for all of the data in both directions around the ring" seems as to= o strong requirement considering cases of 1:N linear and shared mesh protec= tion, where bandwidth of a protection path shared.
  • Section 2.3
  • "… since we will perform all of the OAM functionality on the= SPME configured for the traffic, we can minimize the number of OAM session= s needed to monitor the data traffic of the ring - rather than monitoring e= ach individual LSP." Such improvement in OAM scale doesn't come for free as SPME OAM might introduce or hide connectivit= y and/or continuity defects of enclosed LSPs.
  • "In all of the f= ollowing subsections, we use 1:1 linear protection [SurvivFwk] [LinProtect]= to perform protection switching and coordination when a signal fault is de= tected." For 1:1 linear protection scope of the RFC 6378 is limited to= bi-directional p2p MPLS-TP constructs. "Applicability of the protocol for 1:1 unidirectio= nal protection and for 1:n protection schemes may be documented in a future= document and is out of scope for this document", stated in section 1.= 2. Thus use of PSC for unidirectional p2p and p2mp MPLS-TP constructs is undefined. Perhaps this has to be mentioned = and reflected in change of the scope of the document.
  • Section 2.3.1
  • First para "… each one acts as the ingress and egress in one= direction of the bidirectional SPME". I think that terminology "= ingress/egress MEP" is not the best and perhaps view of nodal MEP per = LSP is sufficient, so that no need to split MEP on given LSP per direction.
  • Section 2.3.2
  • I think that title of the section needs to say explicitly that link pro= tection by wrapping is discussed in the section (node protection in the 2.3= .3)
  • Section 2.3.3
  • As mentioned, in case of bi-directional co-routed LSP to which node pro= tection required (Figure 4) SPME approach is, effectively, segment, not loc= al protection. SPME level OAM between LSR A and LSR E monitors not only lin= k between LSR A and LSR F and LSR F but link between LSR F and LSR E as well (from LSP POV). The primary SPME= , effectively, changes ring topology by excluding LSR F from topology as LS= R F would not be processing LSP's outer label but process only SPME's outer= label.
  • Section 2.3.4
  • Local node protection monitors immediate link for link as well as node = protection. The difference between these protection modes in selection of a= MP, whether immediate neighbor can (link protection) or can not (node prot= ection) be used as MP. The section seems based on misunderstanding of difference between local link and node p= rotection and might be removed.
  • Section 2.4
  • s/steeing/steering/
  • What are three OAM sessions that each ring = node will have if wrapping used to protect the ring? I see two OAM sessions= : immediate link to downstream LSR; around ring to the same LSR. Where the = third OAM session?
  • "Special consideration" seems as unfou= nded:
  • Not clear why CC/CV OAM in case of SPME steering viewed as insufficient= for fast defect detection.
  • Local node and link protection are not = mutualy exclusive. Local node protection provides link protection as part o= f node protection. The problem, from my POV, is that bi-directional co-rout= ed LSP can not have local node protection but only segment protection.
    • =
  • Section 3
  • As noted earlier, applicability of RFC 6378 and PSC for 1:1 linear prot= ection of unidirectional MPLS-TP constructs, including unidirectional p2mp = LSP, not yet been defined. Neither CC/CV OAM on these constructs. What mech= anism(s) could be used to perform defect detection, coordination and protections switchover?
  • Section 4
  • As as stated in RFC 6378 "Applicability of the protocol [PSC, my n= ote] for 1:1 unidirectional protection and for 1:n protection schemes may b= e documented in a future document and is out of scope for this document&quo= t;.
A note on textual conventions:
  • References are both direct RFC, e.g. [RFC4090], and content-based, i.e.= [TPReqs]. May consider choosing single style of referencing.
 
Thank you for your kind consideration.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bo= unces@ietf.org] On Behalf Of Loa Andersson
Sent: Wednesday, September 19, 2012 3= :49 AM
Cc: mpls@ietf.org; MPLS-TP ad hoc tea= m; draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.iet= f.org
Subject: [mpls] Working group last ca= ll on draft-ietf-mpls-tp-ring-protection
 
Working Group,
 
this is to start a two week working g= roup last call on draft-ietf-mpls-tp-ring-protection-02-txt.
 
Please note that there are two IPR di= sclosures # 1462 and  # 1872 related to this document.
 
Please send your comments to the mpls= working group mailing lists (mpls@ietf.org).
 
The working group last call ends Octo= ber 3, 2012.
 
/Loa
for the mpls wg co-chairs
 
 
--
 
 
Loa Andersson    =             &nb= sp;        email: loa.andersson@ericsson= .com
Sr Strategy and Standards Manager&nbs= p;           loa@pi.nu
Ericsson Inc    &= nbsp;           &nbs= p;         phone: +46 10 717 52= 13
      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  +46 767 72 92 13 _____________________________________________= __
mpls mailing list
mpls@ietf.org
 
 --_000_FE60A4E52763E84B935532D7D9294FF139284003C4EUSAACMS0715e_-- From ryoo@etri.re.kr Tue Oct 2 01:39:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF5621F8AC6 for ; Tue, 2 Oct 2012 01:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdqEn1nzRO4B for ; Tue, 2 Oct 2012 01:39:28 -0700 (PDT) Received: from mailx.etri.re.kr (mailx.etri.re.kr [129.254.38.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5B65921F8AC4 for ; Tue, 2 Oct 2012 01:39:28 -0700 (PDT) Received: from SMTPEG1.etri.info (ssbmailx [127.0.0.1]) by mailx.etri.re.kr (8.13.8/8.13.8) with ESMTP id q928dKeU008705; Tue, 2 Oct 2012 17:39:21 +0900 Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 2 Oct 2012 17:39:16 +0900 Received: from SMTP2.etri.info ([169.254.2.205]) by SMTP4.etri.info ([169.254.3.84]) with mapi id 14.01.0355.002; Tue, 2 Oct 2012 17:39:19 +0900 From: "Ryoo, Jeong-dong" To: "D'Alessandro Alessandro Gerardo" , Loa Andersson Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: AQHNllRiBcIu+gpFLkupfht3YctCaJegncAAgAM+1ICAAelnNw== Date: Tue, 2 Oct 2012 08:39:19 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A0DEE0BD7@SMTP2.etri.info> References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com>, In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A0DEE0BD7SMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: [mpls] =?utf-8?b?7ZqM7IugOiAgV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24g?= =?utf-8?q?draft-ietf-mpls-tp-ring-protection?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 08:39:31 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A0DEE0BD7SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQorMQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCuuztOuCuCDsgqzr nowgOiAiRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbyIgPGFsZXNzYW5kcm8uZGFsZXNz YW5kcm9AdGVsZWNvbWl0YWxpYS5pdD4NCuuztOuCuCDrgqDsp5wgOiAyMDEyLTEwLTAxIDIxOjM4 OjU4ICggKzA5OjAwICkNCuuwm+uKlCDsgqzrnowgOiBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+ DQrssLjsobAgOiBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPiwgbXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmcgPG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPiwgTVBMUy1UUCBhZCBob2Mg dGVhbSA8YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQ+LCBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1w cm90ZWN0aW9uQHRvb2xzLmlldGYub3JnIDxkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0 aW9uQHRvb2xzLmlldGYub3JnPg0K7KCc66qpIDogW0FITVBMUy1UUF0gUjogW21wbHNdIFdvcmtp bmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24N Cg0KDQpEbyBub3Qgc3VwcG9ydA0KDQpBY2NvcmRpbmcgdG8gdGhlIG9wdGltaXphdGlvbiBjcml0 ZXJpYSBmb3IgcmluZyBwcm90ZWN0aW9uIHNwZWNpZmllZCBpbiBTZWN0aW9uIDIuNS42LjEgaW4g UkZDNTY1NCwgdGhlIE1QTFMtVFAgcmluZyBwcm90ZWN0aW9uIHNob3VsZCBiZSBvcHRpbWl6ZWQg Zm9yIHNpbXBsaWZpY2F0aW9uIG9mIHRoZSByaW5nIG9wZXJhdGlvbiBhbmQgdGhlIHJlc291cmNl cyBjb25zdW1wdGlvbiBhcm91bmQgdGhlIHJpbmcuIEl0IGlzIG5vdCB0aGUgY2FzZSBvZiB0aGUg cHJvcG9zZWQgc29sdXRpb24uDQpJdCBpcyBhY3R1YWxseSBzaW1wbHkgYW4gYXBwbGljYWJpbGl0 eSBzdGF0ZW1lbnQgb2YgYSBsaW5lYXIgcHJvdGVjdGlvbiBtZWNoYW5pc20gYnV0IGl0IGNhbm5v dCBiZSBjb25zaWRlciBhIHNvbHV0aW9uIHRoYXQgYWRkcmVzc2VzIHRoZSByZXF1aXJlbWVudHMg Zm9yIHByb3RlY3Rpb24gb2YgcmluZyB0b3BvbG9naWVzIGZvciBNdWx0aS1Qcm90b2NvbCBMYWJl bCBTd2l0Y2hpbmcgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFApIGFzIHNwZWNpZmllZCBpbiBS RkM1NjU0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpBbGVzc2FuZHJvDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGVsZWNv bSBJdGFsaWENCkFsZXNzYW5kcm8gR2VyYXJkbyBEJ0FsZXNzYW5kcm8NClRyYW5zcG9ydCBJbm5v dmF0aW9uDQpWaWEgUmVpc3MgUm9tb2xpLCAyNzQgLSAxMDE0OCBUb3Jpbm8NCnBob25lOiArMzkg MDExIDIyOCA1ODg3DQptb2JpbGU6ICszOSAzMzUgNzY2IDk2MDcNCmZheDogKzM5IDA2IDQxOCA2 MzkgMDcNCg0KDQotLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KRGE6IG1wbHMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEhl amlhDQpJbnZpYXRvOiBzYWJhdG8gMjkgc2V0dGVtYnJlIDIwMTIgMTI6NTMNCkE6IExvYSBBbmRl cnNzb24NCkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTVBM Uy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29s cy5pZXRmLm9yZw0KT2dnZXR0bzogUmU6IFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBv biBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoNCkRvIG5vdCBzdXBwb3J0Lg0K DQpCYXNlZCBvbiB0aGUgYW5hbHlzaXMgaW4gU2VjdGlvbiAyLjQgb2YgZHJhZnQtaWV0Zi1tcGxz LXRwLXJpbmctcHJvdGVjdGlvbi0wMiwgdGhlIHJpbmcgcHJvdGVjdGlvbiBzY2hlbWUgdXNpbmcg U1BNRSBhcyBkZXNjcmliZWQsIGVpdGhlciB3cmFwcGluZyBvciBzdGVlcmluZywgZG9lcyBoYXZl IGRlZmljaWVuY2llcywgd2hpY2ggSU1ITyBzaG91bGQgYmUgYmV0dGVyIHJlY29uc2lkZXJlZCBh bmQgc29sdmVkIGlmIHBvc3NpYmxlLg0KDQoNCkIuUi4NCkppYQ0KDQotLS0tLemCruS7tuWOn+S7 ti0tLS0tDQrlj5Hku7bkuro6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10g5Luj6KGoIExvYSBBbmRlcnNzb24NCuWPkemAgeaXtumXtDogMjAxMuW5 tDnmnIgxOeaXpSAxODo0OQ0K5oqE6YCBOiBtcGxzQGlldGYub3JnOyBNUExTLVRQIGFkIGhvYyB0 ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnOyBt cGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0K5Li76aKYOiBbbXBsc10gV29ya2luZyBncm91cCBs YXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQpXb3JraW5n IEdyb3VwLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgb24NCmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24tMDItdHh0Lg0KDQpQ bGVhc2Ugbm90ZSB0aGF0IHRoZXJlIGFyZSB0d28gSVBSIGRpc2Nsb3N1cmVzICMgMTQ2MiBhbmQg IyAxODcyDQpyZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQuDQoNClBsZWFzZSBzZW5kIHlvdXIgY29t bWVudHMgdG8gdGhlIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3RzDQoobXBsc0BpZXRm Lm9yZykuDQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIE9jdG9iZXIgMywgMjAx Mi4NCg0KL0xvYQ0KZm9yIHRoZSBtcGxzIHdnIGNvLWNoYWlycw0KDQoNCi0tDQoNCg0KTG9hIEFu ZGVyc3NvbiBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NClNyIFN0cmF0ZWd5IGFu ZCBTdGFuZGFyZHMgTWFuYWdlciBsb2FAcGkubnUNCkVyaWNzc29uIEluYyBwaG9uZTogKzQ2IDEw IDcxNyA1MiAxMw0KKzQ2IDc2NyA3MiA5MiAxMw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBs c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoN ClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2Ns dXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8g cXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVz dGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlh dGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50 ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUg ZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBE aXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlz IHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRo ZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQoNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A0DEE0BD7SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTog6rW066a8OyBGT05ULVNJWkU6IDEwcHQiIGlkPSJlekZvcm1Qcm9jX2RpdiI+ DQo8ZGl2IGlkPSJtc2dib2R5Ij4NCjxkaXY+DQo8ZGl2Pjxicj4NCiYjNDM7MTwvZGl2Pg0KPGRp dj48YnI+DQombmJzcDs8L2Rpdj4NCjxkaXYgaWQ9Ik1haWxTaWduU2VudCI+PGJyPg0KPC9kaXY+ DQo8ZGl2Pg0KPGhyIHRhYmluZGV4PSItMSI+DQo8L2Rpdj4NCjxkaXY+PGI+67O064K4IOyCrOue jCA6IDwvYj4mcXVvdDtEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvJnF1b3Q7ICZsdDth bGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXQmZ3Q7PGJyPg0KPGI+67O064K4 IOuCoOynnCA6IDwvYj4yMDEyLTEwLTAxIDIxOjM4OjU4ICggJiM0MzswOTowMCApPGJyPg0KPGI+ 67Cb64qUIOyCrOuejCA6IDwvYj5Mb2EgQW5kZXJzc29uICZsdDtsb2FAcGkubnUmZ3Q7PGJyPg0K PGI+7LC47KGwIDogPC9iPm1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7LCBtcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7 LCBNUExTLVRQIGFkIGhvYyB0ZWFtICZsdDthaG1wbHMtdHBAbGlzdHMuaXR1LmludCZndDssIGRy YWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcgJmx0O2RyYWZ0 LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ 7KCc66qpIDogPC9iPltBSE1QTFMtVFBdIFI6IFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uPGJyPg0KPGJyPg0KPGJyPg0K RG8gbm90IHN1cHBvcnQ8YnI+DQo8YnI+DQpBY2NvcmRpbmcgdG8gdGhlIG9wdGltaXphdGlvbiBj cml0ZXJpYSBmb3IgcmluZyBwcm90ZWN0aW9uIHNwZWNpZmllZCBpbiBTZWN0aW9uIDIuNS42LjEg aW4gUkZDNTY1NCwgdGhlIE1QTFMtVFAgcmluZyBwcm90ZWN0aW9uIHNob3VsZCBiZSBvcHRpbWl6 ZWQgZm9yIHNpbXBsaWZpY2F0aW9uIG9mIHRoZSByaW5nIG9wZXJhdGlvbiBhbmQgdGhlIHJlc291 cmNlcyBjb25zdW1wdGlvbiBhcm91bmQgdGhlIHJpbmcuIEl0IGlzIG5vdCB0aGUgY2FzZSBvZg0K IHRoZSBwcm9wb3NlZCBzb2x1dGlvbi48YnI+DQpJdCBpcyBhY3R1YWxseSBzaW1wbHkgYW4gYXBw bGljYWJpbGl0eSBzdGF0ZW1lbnQgb2YgYSBsaW5lYXIgcHJvdGVjdGlvbiBtZWNoYW5pc20gYnV0 IGl0IGNhbm5vdCBiZSBjb25zaWRlciBhIHNvbHV0aW9uIHRoYXQgYWRkcmVzc2VzIHRoZSByZXF1 aXJlbWVudHMgZm9yIHByb3RlY3Rpb24gb2YgcmluZyB0b3BvbG9naWVzIGZvciBNdWx0aS1Qcm90 b2NvbCBMYWJlbCBTd2l0Y2hpbmcgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFApIGFzIHNwZWNp ZmllZA0KIGluIFJGQzU2NTQuPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCkFsZXNzYW5k cm88YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpUZWxlY29tIEl0YWxpYTxicj4NCkFsZXNzYW5k cm8gR2VyYXJkbyBEJ0FsZXNzYW5kcm88YnI+DQpUcmFuc3BvcnQgSW5ub3ZhdGlvbjxicj4NClZp YSBSZWlzcyBSb21vbGksIDI3NCAtIDEwMTQ4IFRvcmlubzxicj4NCnBob25lOiAmIzQzOzM5IDAx MSAyMjggNTg4Nzxicj4NCm1vYmlsZTogJiM0MzszOSAzMzUgNzY2IDk2MDc8YnI+DQpmYXg6ICYj NDM7MzkgMDYgNDE4IDYzOSAwNzxicj4NCjxicj4NCjxicj4NCi0tLS0tTWVzc2FnZ2lvIG9yaWdp bmFsZS0tLS0tPGJyPg0KRGE6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEhlamlhPGJyPg0KSW52aWF0bzogc2FiYXRvIDI5 IHNldHRlbWJyZSAyMDEyIDEyOjUzPGJyPg0KQTogTG9hIEFuZGVyc3Nvbjxicj4NCkNjOiBtcGxz QGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVh bTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZzxicj4N Ck9nZ2V0dG86IFJlOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0 Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbjxicj4NCjxicj4NCkRvIG5vdCBzdXBwb3J0Ljxicj4N Cjxicj4NCkJhc2VkIG9uIHRoZSBhbmFseXNpcyBpbiBTZWN0aW9uIDIuNCBvZiBkcmFmdC1pZXRm LW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAyLCB0aGUgcmluZyBwcm90ZWN0aW9uIHNjaGVtZSB1 c2luZyBTUE1FIGFzIGRlc2NyaWJlZCwgZWl0aGVyIHdyYXBwaW5nIG9yIHN0ZWVyaW5nLCBkb2Vz IGhhdmUgZGVmaWNpZW5jaWVzLCB3aGljaCBJTUhPIHNob3VsZCBiZSBiZXR0ZXIgcmVjb25zaWRl cmVkIGFuZCBzb2x2ZWQgaWYgcG9zc2libGUuPGJyPg0KPGJyPg0KPGJyPg0KQi5SLjxicj4NCkpp YTxicj4NCjxicj4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS08YnI+DQrlj5Hku7bkuro6IG1wbHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIExv YSBBbmRlcnNzb248YnI+DQrlj5HpgIHml7bpl7Q6IDIwMTLlubQ55pyIMTnml6UgMTg6NDk8YnI+ DQrmioTpgIE6IG1wbHNAaWV0Zi5vcmc7IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRyYWZ0LWlldGYt bXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnPGJyPg0K5Li76aKYOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24g ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbjxicj4NCjxicj4NCldvcmtpbmcgR3Jv dXAsPGJyPg0KPGJyPg0KdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIG9uPGJyPg0KZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMi10 eHQuPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCB0aGVyZSBhcmUgdHdvIElQUiBkaXNjbG9z dXJlcyAjIDE0NjIgYW5kICMgMTg3Mjxicj4NCnJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudC48YnI+ DQo8YnI+DQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3Jv dXAgbWFpbGluZyBsaXN0czxicj4NCihtcGxzQGlldGYub3JnKS48YnI+DQo8YnI+DQpUaGUgd29y a2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBPY3RvYmVyIDMsIDIwMTIuPGJyPg0KPGJyPg0KL0xv YTxicj4NCmZvciB0aGUgbXBscyB3ZyBjby1jaGFpcnM8YnI+DQo8YnI+DQo8YnI+DQotLTxicj4N Cjxicj4NCjxicj4NCkxvYSBBbmRlcnNzb24gZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24u Y29tPGJyPg0KU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyIGxvYUBwaS5udTxicj4N CkVyaWNzc29uIEluYyBwaG9uZTogJiM0Mzs0NiAxMCA3MTcgNTIgMTM8YnI+DQomIzQzOzQ2IDc2 NyA3MiA5MiAxMzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzQGlldGYub3JnPGJyPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlz dDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHM8YnI+DQo8YnI+DQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRp IHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBM YSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRh bGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUg dmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyDQog ZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211 bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9u ZSwgR3JhemllLjxicj4NCjxicj4NClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMg Y29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVu ZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHBy aW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZQ0K IGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwsIFRoYW5rcy48YnI+DQo8YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A0DEE0BD7SMTP2etriinfo_-- From carlo.cavazzoni@telecomitalia.it Tue Oct 2 01:57:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2A021F8B1E for ; Tue, 2 Oct 2012 01:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HajBf6EJjA52 for ; Tue, 2 Oct 2012 01:57:49 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3DC21F8B20 for ; Tue, 2 Oct 2012 01:57:47 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 2 Oct 2012 10:57:43 +0200 Received: from GRFMBX703BA020.griffon.local ([10.188.101.13]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Tue, 2 Oct 2012 10:57:43 +0200 From: Cavazzoni Carlo To: D'Alessandro Alessandro Gerardo , Loa Andersson Date: Tue, 2 Oct 2012 10:57:41 +0200 Thread-Topic: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: AQHNllRf82qjNdoiA0OJzsZi6RX7kJehLihwgANBJaCAAVu4IA== Message-ID: <05540BD841BBD643BB51404C4C917152151386C118@GRFMBX703BA020.griffon.local> References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 08:57:49 -0000 KzENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEQnQWxlc3Nh bmRybyBBbGVzc2FuZHJvIEdlcmFyZG8NClNlbnQ6IGx1bmVkw6wgMSBvdHRvYnJlIDIwMTIgMTQ6 MjcNClRvOiBMb2EgQW5kZXJzc29uDQpDYzogbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc7IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRyYWZ0LWlldGYtbXBscy10cC1yaW5n LXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzXSBSOiBXb3JraW5nIGdy b3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoNCkRv IG5vdCBzdXBwb3J0DQoNCkFjY29yZGluZyB0byB0aGUgb3B0aW1pemF0aW9uIGNyaXRlcmlhIGZv ciByaW5nIHByb3RlY3Rpb24gc3BlY2lmaWVkIGluIFNlY3Rpb24gMi41LjYuMSBpbiBSRkM1NjU0 LCB0aGUgTVBMUy1UUCByaW5nIHByb3RlY3Rpb24gc2hvdWxkIGJlIG9wdGltaXplZCBmb3Igc2lt cGxpZmljYXRpb24gb2YgdGhlIHJpbmcgb3BlcmF0aW9uIGFuZCB0aGUgcmVzb3VyY2VzIGNvbnN1 bXB0aW9uIGFyb3VuZCB0aGUgcmluZy4gSXQgaXMgbm90IHRoZSBjYXNlIG9mIHRoZSBwcm9wb3Nl ZCBzb2x1dGlvbi4NCkl0IGlzIGFjdHVhbGx5IHNpbXBseSBhbiBhcHBsaWNhYmlsaXR5IHN0YXRl bWVudCBvZiBhIGxpbmVhciBwcm90ZWN0aW9uIG1lY2hhbmlzbSBidXQgaXQgY2Fubm90IGJlIGNv bnNpZGVyIGEgc29sdXRpb24gdGhhdCBhZGRyZXNzZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgcHJv dGVjdGlvbiBvZiByaW5nIHRvcG9sb2dpZXMgZm9yIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRj aGluZyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgYXMgc3BlY2lmaWVkIGluIFJGQzU2NTQu DQoNCkJlc3QgcmVnYXJkcywNCkFsZXNzYW5kcm8NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUZWxlY29tIEl0YWxp YQ0KQWxlc3NhbmRybyBHZXJhcmRvIEQnQWxlc3NhbmRybw0KVHJhbnNwb3J0IElubm92YXRpb24N ClZpYSBSZWlzcyBSb21vbGksIDI3NCAtIDEwMTQ4IFRvcmlubw0KcGhvbmU6ICArMzkgMDExIDIy OCA1ODg3DQptb2JpbGU6ICszOSAzMzUgNzY2IDk2MDcNCmZheDogKzM5IDA2IDQxOCA2MzkgMDcN Cg0KDQotLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KRGE6IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEhlamlhDQpJ bnZpYXRvOiBzYWJhdG8gMjkgc2V0dGVtYnJlIDIwMTIgMTI6NTMNCkE6IExvYSBBbmRlcnNzb24N CkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTVBMUy1UUCBh ZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRm Lm9yZw0KT2dnZXR0bzogUmU6IFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFm dC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoNCkRvIG5vdCBzdXBwb3J0Lg0KDQpCYXNl ZCBvbiB0aGUgYW5hbHlzaXMgaW4gU2VjdGlvbiAyLjQgb2YgZHJhZnQtaWV0Zi1tcGxzLXRwLXJp bmctcHJvdGVjdGlvbi0wMiwgdGhlIHJpbmcgcHJvdGVjdGlvbiBzY2hlbWUgdXNpbmcgU1BNRSBh cyBkZXNjcmliZWQsIGVpdGhlciB3cmFwcGluZyBvciBzdGVlcmluZywgZG9lcyBoYXZlIGRlZmlj aWVuY2llcywgd2hpY2ggSU1ITyBzaG91bGQgYmUgYmV0dGVyIHJlY29uc2lkZXJlZCBhbmQgc29s dmVkIGlmIHBvc3NpYmxlLg0KDQoNCkIuUi4NCkppYQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0t DQrlj5Hku7bkuro6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZ10g5Luj6KGoIExvYSBBbmRlcnNzb24NCuWPkemAgeaXtumXtDogMjAxMuW5tDnmnIgx OeaXpSAxODo0OQ0K5oqE6YCBOiBtcGxzQGlldGYub3JnOyBNUExTLVRQIGFkIGhvYyB0ZWFtOyBk cmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnOyBtcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZw0K5Li76aKYOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNh bGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQpXb3JraW5nIEdyb3Vw LA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwg b24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMi10eHQuDQoNClBsZWFzZSBu b3RlIHRoYXQgdGhlcmUgYXJlIHR3byBJUFIgZGlzY2xvc3VyZXMgIyAxNDYyIGFuZCAgIyAxODcy IHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudC4NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0 byB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdHMgKG1wbHNAaWV0Zi5vcmcpLg0K DQpUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBPY3RvYmVyIDMsIDIwMTIuDQoNCi9M b2ENCmZvciB0aGUgbXBscyB3ZyBjby1jaGFpcnMNCg0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24g ICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29t DQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnUN CkVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcg NTIgMTMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYg NzY3IDcyIDkyIDEzIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQpRdWVzdG8gbWVzc2FnZ2lv IGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBw ZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBh emlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBz b25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0 byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJu ZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxs YSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29w eWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVy biBlLW1haWwsIFRoYW5rcy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From huubatwork@gmail.com Tue Oct 2 02:03:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1650321F8A08 for ; Tue, 2 Oct 2012 02:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B9kmfDFj2vY for ; Tue, 2 Oct 2012 02:03:04 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE4D21F8A07 for ; Tue, 2 Oct 2012 02:03:03 -0700 (PDT) Received: by weyu46 with SMTP id u46so3802972wey.31 for ; Tue, 02 Oct 2012 02:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mmPm162oXwGXD87LwZ0Kni7EczaC1TKX6X7Ixctu7AY=; b=AJxCN8UaUda1kCwrzWcB7N2Cy1a5SIU7hofhfK43uPdcrUUlr3yqQ+v+tAXXZifGZB 9OCt00DgWfE0muvOriC2dmGoBjx9afEu1/iSi9Pm5IexrmQpFlxqLKCrPCwTMKB45Hzm 5kOmnlMaMaOxI3Odi3hPrqz9K9eTLkY1zBW0hOg77Ni9svLeS4mjiu+o9jGJpCqvVhZY h9VOBm7h2sA7wT0z/bHTgG55g6pqpj9KIUTIOi6oSvEDLOl36oeYta4m/UBLNhVFVbXP PwTLdJJ4k20Jj9P3pwNu9DN33NHI7IvDKBPKswMeov87ka3ZP09/CtKfDzW7aNIVsS+U uE4g== Received: by 10.180.90.201 with SMTP id by9mr20422807wib.5.1349168578368; Tue, 02 Oct 2012 02:02:58 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl. [77.250.51.60]) by mx.google.com with ESMTPS id k2sm1360189wiz.7.2012.10.02.02.02.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Oct 2012 02:02:57 -0700 (PDT) Message-ID: <506AADC0.2090802@gmail.com> Date: Tue, 02 Oct 2012 11:02:56 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: D'Alessandro Alessandro Gerardo References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] [AHMPLS-TP] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 09:03:05 -0000 Do not support. Same reasons as mentioned below. Regards, Huub. On 01-10-12 14:27, D'Alessandro Alessandro Gerardo wrote: > Do not support > > According to the optimization criteria for ring protection specified in Section 2.5.6.1 in RFC5654, the MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption around the ring. It is not the case of the proposed solution. > It is actually simply an applicability statement of a linear protection mechanism but it cannot be consider a solution that addresses the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) as specified in RFC5654. > > Best regards, > Alessandro > > ------------------------------------------------------------------ > Telecom Italia > Alessandro Gerardo D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 > > > -----Messaggio originale----- > Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Hejia > Inviato: sabato 29 settembre 2012 12:53 > A: Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Do not support. > > Based on the analysis in Section 2.4 of draft-ietf-mpls-tp-ring-protection-02, the ring protection scheme using SPME as described, either wrapping or steering, does have deficiencies, which IMHO should be better reconsidered and solved if possible. > > > B.R. > Jia > > -----邮件原件----- > å‘件人: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] 代表 Loa Andersson > å‘é€æ—¶é—´: 2012å¹´9月19æ—¥ 18:49 > 抄é€: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.ietf.org > 主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 > related to this document. > > Please send your comments to the mpls working group mailing lists > (mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From andrea.digiglio@telecomitalia.it Tue Oct 2 02:51:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15EE21F8B0E for ; Tue, 2 Oct 2012 02:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0Usx-sps+5B for ; Tue, 2 Oct 2012 02:51:18 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id A052E21F8B09 for ; Tue, 2 Oct 2012 02:51:17 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 2 Oct 2012 11:51:14 +0200 Received: from GRFMBX702BA020.griffon.local ([10.188.101.11]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Tue, 2 Oct 2012 11:51:12 +0200 From: Di Giglio Andrea To: Cavazzoni Carlo , "D'Alessandro Alessandro Gerardo" , Loa Andersson Date: Tue, 2 Oct 2012 11:51:11 +0200 Thread-Topic: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: AQHNllRf82qjNdoiA0OJzsZi6RX7kJehLihwgANBJaCAAVu4IIAADzFw Message-ID: References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> <05540BD841BBD643BB51404C4C917152151386C118@GRFMBX703BA020.griffon.local> In-Reply-To: <05540BD841BBD643BB51404C4C917152151386C118@GRFMBX703BA020.griffon.local> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: [mpls] R: R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 09:51:18 -0000 KzENCg0KLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCkRhOiBtcGxzLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBDYXZhenpv bmkgQ2FybG8NCkludmlhdG86IG1hcnRlZMOsIDIgb3R0b2JyZSAyMDEyIDEwOjU4DQpBOiBEJ0Fs ZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvOyBMb2EgQW5kZXJzc29uDQpDYzogbXBsc0BpZXRm Lm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRy YWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcNCk9nZ2V0dG86 IFJlOiBbbXBsc10gUjogV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxz LXRwLXJpbmctcHJvdGVjdGlvbg0KDQorMQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbw0KU2VudDogbHVu ZWTDrCAxIG90dG9icmUgMjAxMiAxNDoyNw0KVG86IExvYSBBbmRlcnNzb24NCkNjOiBtcGxzQGll dGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsg ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZw0KU3ViamVj dDogW21wbHNdIFI6IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10 cC1yaW5nLXByb3RlY3Rpb24NCg0KRG8gbm90IHN1cHBvcnQNCg0KQWNjb3JkaW5nIHRvIHRoZSBv cHRpbWl6YXRpb24gY3JpdGVyaWEgZm9yIHJpbmcgcHJvdGVjdGlvbiBzcGVjaWZpZWQgaW4gU2Vj dGlvbiAyLjUuNi4xIGluIFJGQzU2NTQsIHRoZSBNUExTLVRQIHJpbmcgcHJvdGVjdGlvbiBzaG91 bGQgYmUgb3B0aW1pemVkIGZvciBzaW1wbGlmaWNhdGlvbiBvZiB0aGUgcmluZyBvcGVyYXRpb24g YW5kIHRoZSByZXNvdXJjZXMgY29uc3VtcHRpb24gYXJvdW5kIHRoZSByaW5nLiBJdCBpcyBub3Qg dGhlIGNhc2Ugb2YgdGhlIHByb3Bvc2VkIHNvbHV0aW9uLg0KSXQgaXMgYWN0dWFsbHkgc2ltcGx5 IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IG9mIGEgbGluZWFyIHByb3RlY3Rpb24gbWVjaGFu aXNtIGJ1dCBpdCBjYW5ub3QgYmUgY29uc2lkZXIgYSBzb2x1dGlvbiB0aGF0IGFkZHJlc3NlcyB0 aGUgcmVxdWlyZW1lbnRzIGZvciBwcm90ZWN0aW9uIG9mIHJpbmcgdG9wb2xvZ2llcyBmb3IgTXVs dGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBh cyBzcGVjaWZpZWQgaW4gUkZDNTY1NC4NCg0KQmVzdCByZWdhcmRzLA0KQWxlc3NhbmRybw0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClRlbGVjb20gSXRhbGlhDQpBbGVzc2FuZHJvIEdlcmFyZG8gRCdBbGVzc2FuZHJv DQpUcmFuc3BvcnQgSW5ub3ZhdGlvbg0KVmlhIFJlaXNzIFJvbW9saSwgMjc0IC0gMTAxNDggVG9y aW5vDQpwaG9uZTogICszOSAwMTEgMjI4IDU4ODcNCm1vYmlsZTogKzM5IDMzNSA3NjYgOTYwNw0K ZmF4OiArMzkgMDYgNDE4IDYzOSAwNw0KDQoNCi0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0t DQpEYTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3Jn XSBQZXIgY29udG8gZGkgSGVqaWENCkludmlhdG86IHNhYmF0byAyOSBzZXR0ZW1icmUgMjAxMiAx Mjo1Mw0KQTogTG9hIEFuZGVyc3Nvbg0KQ2M6IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnOyBNUExTLVRQIGFkIGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmlu Zy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnDQpPZ2dldHRvOiBSZTogW21wbHNdIFdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0K RG8gbm90IHN1cHBvcnQuDQoNCkJhc2VkIG9uIHRoZSBhbmFseXNpcyBpbiBTZWN0aW9uIDIuNCBv ZiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAyLCB0aGUgcmluZyBwcm90ZWN0 aW9uIHNjaGVtZSB1c2luZyBTUE1FIGFzIGRlc2NyaWJlZCwgZWl0aGVyIHdyYXBwaW5nIG9yIHN0 ZWVyaW5nLCBkb2VzIGhhdmUgZGVmaWNpZW5jaWVzLCB3aGljaCBJTUhPIHNob3VsZCBiZSBiZXR0 ZXIgcmVjb25zaWRlcmVkIGFuZCBzb2x2ZWQgaWYgcG9zc2libGUuDQoNCg0KQi5SLg0KSmlhDQoN Ci0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggTG9hIEFuZGVyc3Nvbg0K5Y+R 6YCB5pe26Ze0OiAyMDEy5bm0OeaciDE55pelIDE4OjQ5DQrmioTpgIE6IG1wbHNAaWV0Zi5vcmc7 IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25A dG9vbHMuaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQrkuLvpopg6IFttcGxz XSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90 ZWN0aW9uDQoNCldvcmtpbmcgR3JvdXAsDQoNCnRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0 aW9uLTAyLXR4dC4NCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGVyZSBhcmUgdHdvIElQUiBkaXNjbG9z dXJlcyAjIDE0NjIgYW5kICAjIDE4NzIgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50Lg0KDQpQbGVh c2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBs aXN0cyAobXBsc0BpZXRmLm9yZykuDQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRz IE9jdG9iZXIgMywgMjAxMi4NCg0KL0xvYQ0KZm9yIHRoZSBtcGxzIHdnIGNvLWNoYWlycw0KDQoN Ci0tDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9h LmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdl ciAgICAgICAgICAgIGxvYUBwaS5udQ0KRXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAg ICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlz dA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0 aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNv cGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBk aSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3Jh IGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRl c2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRl bnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlz IGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRh aW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBv bmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBl bHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2 aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1w bHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFp bGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCg== From stbryant@cisco.com Tue Oct 2 03:05:03 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C1521F8B16 for ; Tue, 2 Oct 2012 03:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.617 X-Spam-Level: X-Spam-Status: No, score=-110.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EON6Aq9kXarE for ; Tue, 2 Oct 2012 03:05:02 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id F05DD21F8B12 for ; Tue, 2 Oct 2012 03:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5058; q=dns/txt; s=iport; t=1349172302; x=1350381902; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iaflAw7M64Uycj4NJF+IiyE7nZRfIXeA277lBeYLvc8=; b=d/rRpRHrl34HSpTT4HIrqAnUCiQHFrox49xIOU7mnOC+uogKiCveOhMg 19HqgrWarMGrpXRmUypvYo1x7vwk9Y5oKKsmzObTz5UpqWTxPc0YoMhUq BP7lvMs6wKkbtZR/FxqvN8ePjTCPSADAPptvSdi+UqlGbLon5ZbviHnib Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAKy7alCQ/khL/2dsb2JhbABCA4YLuE6BCIIgAQEBBAEBAQ8BAg4PAQU2CgEMAgIJAhEEAQEBAgIFFggDAgIJAwIBAgEJDB8JCAYNAQUCAQEXB4djC5lhg0oQiUGCO5BvBIEdiXkagwyCE4ESA5VpjkKBBmOCaIFi X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="8460736" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 02 Oct 2012 10:04:58 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q92A4vBj017426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 10:04:58 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q92A4rh2019187; Tue, 2 Oct 2012 11:04:55 +0100 (BST) Message-ID: <506ABC45.5050202@cisco.com> Date: Tue, 02 Oct 2012 11:04:53 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Di Giglio Andrea References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> <05540BD841BBD643BB51404C4C917152151386C118@GRFMBX703BA020.griffon.local> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] R: R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 10:05:03 -0000 Alessandro, Di Giglio, Huub, Please could you be more precise by specifying the optimizations that you believe are achievable. Stewart On 02/10/2012 10:51, Di Giglio Andrea wrote: > +1 > > -----Messaggio originale----- > Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Cavazzoni Carlo > Inviato: martedì 2 ottobre 2012 10:58 > A: D'Alessandro Alessandro Gerardo; Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Oggetto: Re: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection > > +1 > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of D'Alessandro Alessandro Gerardo > Sent: lunedì 1 ottobre 2012 14:27 > To: Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection > > Do not support > > According to the optimization criteria for ring protection specified in Section 2.5.6.1 in RFC5654, the MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption around the ring. It is not the case of the proposed solution. > It is actually simply an applicability statement of a linear protection mechanism but it cannot be consider a solution that addresses the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) as specified in RFC5654. > > Best regards, > Alessandro > > ------------------------------------------------------------------ > Telecom Italia > Alessandro Gerardo D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 > > > -----Messaggio originale----- > Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Hejia > Inviato: sabato 29 settembre 2012 12:53 > A: Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Do not support. > > Based on the analysis in Section 2.4 of draft-ietf-mpls-tp-ring-protection-02, the ring protection scheme using SPME as described, either wrapping or steering, does have deficiencies, which IMHO should be better reconsidered and solved if possible. > > > B.R. > Jia > > -----邮件原件----- > å‘件人: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] 代表 Loa Andersson > å‘é€æ—¶é—´: 2012å¹´9月19æ—¥ 18:49 > 抄é€: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.ietf.org > 主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Working Group, > > this is to start a two week working group last call on draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 related to this document. > > Please send your comments to the mpls working group mailing lists (mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From larryli888@yahoo.com.cn Tue Oct 2 03:41:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A843121F8B21 for ; Tue, 2 Oct 2012 03:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp28fxWvLtrP for ; Tue, 2 Oct 2012 03:41:35 -0700 (PDT) Received: from nm39-vm8.bullet.mail.sg3.yahoo.com (nm39-vm8.bullet.mail.sg3.yahoo.com [106.10.151.191]) by ietfa.amsl.com (Postfix) with SMTP id 12AA821F8B1E for ; Tue, 2 Oct 2012 03:41:34 -0700 (PDT) Received: from [106.10.166.122] by nm39.bullet.mail.sg3.yahoo.com with NNFMP; 02 Oct 2012 10:41:31 -0000 Received: from [106.10.151.155] by tm11.bullet.mail.sg3.yahoo.com with NNFMP; 02 Oct 2012 10:41:31 -0000 Received: from [127.0.0.1] by omp1009.mail.sg3.yahoo.com with NNFMP; 02 Oct 2012 10:41:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 274876.54632.bm@omp1009.mail.sg3.yahoo.com Received: (qmail 12626 invoked by uid 60001); 2 Oct 2012 10:41:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1349174489; bh=9122syBJX854ESeus1A008VmoDe8F5iahRKJpbvfyXs=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gVpqsoBtC7ixfyp73yQZbvJqtTYa5wVeg5H0pOScvqvU67spQkgobutsGbbRlvW6ATJrLZr/juznC6BtYrQUU2jzT+j3CQQUzMHRqBzpP3F5dtdFFFAHjg6F3A/hATEvjHK+QF+6JwUXpZ+a4n4Zr5BYPlCc86r7dAnDRlOERQc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cML8LwbghnjUS8qmTpiGyCGo743qzK4Y7ZF7ZHAURpZDL2PwbCxG8lI5guNNIOvodpLmgQbfqSlthjLAZWVQcDK0hK9lOOuktrS1JznAw+ru15KSUpK8JCWnpxYXr1O4BRTe/vtFjeLzDh4IpcbQZkPPbUknipKX7LhhkSoGC2o=; X-YMail-OSG: 6IR8DikVM1nSfHmfee6xtX6T0OOiMy1qJHYGDOePRVuvBRv svrXutrCtpIGK6enOrGvSlG5rLXXGWM_4mY8oD.S5YK_t5hGnbyW.EKEBH1m FZrJgPG42aeVss1R0t557L4kak04NWZDV8fS0DF3ix85SeYMK8h0ykVSmcaG Yv1v.QX8XBVXo9I2qkdcwcJNhwP_YZ_vKbuTLkhBjiJKOg8FCLNibVPggeUZ 6hsBl3GSwYR0OY2txLEjQwOKDD.e_3neQacnJTNKk_aiiPyKGmEdFyQ_XFlP HbFZ2AYLlLB.NePBcOH26DegpeQrtNcwmnifhg5nMmtxb0ncs.tuAhoKvD7Y JR5QIc599mnaNUg6oDm4v1bzkgrswJHdD.R1NiJ01yToLbaiHR5lYzyWNKTy CyAGXUr4PpJwwQSIrDYfC3uQKopprW2j2ikyv4MhevNCTakSuo1U- Received: from [221.130.253.135] by web15602.mail.cnb.yahoo.com via HTTP; Tue, 02 Oct 2012 18:41:28 CST X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.434 Message-ID: <1349174488.11140.YahooMailClassic@web15602.mail.cnb.yahoo.com> Date: Tue, 2 Oct 2012 18:41:28 +0800 (CST) From: Larry To: D'Alessandro Alessandro Gerardo , huubatwork@gmail.com In-Reply-To: <506AADC0.2090802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] [AHMPLS-TP] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 10:41:36 -0000 not support!=0AIt doesn't satisfy some requirements of the operators. The c= onfiguration is too complex and needs too many labels and OAM sessions. The= re are risks that protection switch time exceed 50ms.=0A=0A****************= *********************************************************=0AHan Li, Ph.D = =0AChina Mobile Research Institute=0A32 Xuanwumen West Street, Xicheng Dist= rict, Beijing 100053, China =0AFax: +86 10 63135159 =0AMOBILE: 13501093385 = =0A************************************************************************= *=0A=0A=0A--- 12=E5=B9=B410=E6=9C=882=E6=97=A5=EF=BC=8C=E5=91=A8=E4=BA=8C, = Huub van Helvoort =E5=86=99=E9=81=93=EF=BC=9A=0A=0A>= =E5=8F=91=E4=BB=B6=E4=BA=BA: Huub van Helvoort =0A> = =E4=B8=BB=E9=A2=98: Re: [mpls] [AHMPLS-TP] R: Working group last call on dr= aft-ietf-mpls-tp-ring-protection=0A> =E6=94=B6=E4=BB=B6=E4=BA=BA: "D'Alessa= ndro Alessandro Gerardo" =0A> =E6= =8A=84=E9=80=81: "mpls@ietf.org" , "mpls-chairs@tools.ietf.o= rg" , "MPLS-TP ad hoc team" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" =0A> =E6=97=A5=E6=9C=9F: 2012=E5=B9=B41= 0=E6=9C=882=E6=97=A5,=E5=91=A8=E4=BA=8C,=E4=B8=8B=E5=8D=885:02=0A> Do not s= upport.=0A> =0A> Same reasons as mentioned below.=0A> =0A> Regards, Huub.= =0A> =0A> On 01-10-12 14:27, D'Alessandro Alessandro Gerardo wrote:=0A> > D= o not support=0A> >=0A> > According to the optimization criteria for ring= =0A> protection specified in Section 2.5.6.1 in RFC5654, the=0A> MPLS-TP ri= ng protection should be optimized for=0A> simplification of the ring operat= ion and the resources=0A> consumption around the ring. It is not the case o= f the=0A> proposed solution.=0A> > It is actually simply an applicability s= tatement of a=0A> linear protection mechanism but it cannot be consider a= =0A> solution that addresses the requirements for protection of=0A> ring to= pologies for Multi-Protocol Label Switching Transport=0A> Profile (MPLS-TP)= as specified in RFC5654.=0A> >=0A> > Best regards,=0A> > Alessandro=0A> >= =0A> >=0A> ----------------------------------------------------------------= --=0A> > Telecom Italia=0A> > Alessandro Gerardo D'Alessandro=0A> > Transpo= rt Innovation=0A> > Via Reiss Romoli, 274 - 10148 Torino=0A> > phone:=C2=A0= +39 011 228 5887=0A> > mobile: +39 335 766 9607=0A> > fax: +39 06 418 639 = 07=0A> >=0A> >=0A> > -----Messaggio originale-----=0A> > Da: mpls-bounces@i= etf.org=0A> [mailto:mpls-bounces@ietf.org]=0A> Per conto di Hejia=0A> > Inv= iato: sabato 29 settembre 2012 12:53=0A> > A: Loa Andersson=0A> > Cc: mpls@= ietf.org; mpls-chairs@tools.ietf.org;=0A> MPLS-TP ad hoc team; draft-ietf-m= pls-tp-ring-protection@tools.ietf.org=0A> > Oggetto: Re: [mpls] Working gro= up last call on=0A> draft-ietf-mpls-tp-ring-protection=0A> >=0A> > Do not s= upport.=0A> >=0A> > Based on the analysis in Section 2.4 of=0A> draft-ietf-= mpls-tp-ring-protection-02, the ring protection=0A> scheme using SPME as de= scribed, either wrapping or steering,=0A> does have deficiencies, which IMH= O should be better=0A> reconsidered and solved if possible.=0A> >=0A> >=0A>= > B.R.=0A> > Jia=0A> >=0A> > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----= -=0A> > =E5=8F=91=E4=BB=B6=E4=BA=BA: mpls-bounces@ietf.org=0A> [mailto:mpls= -bounces@ietf.org]=0A> =E4=BB=A3=E8=A1=A8 Loa Andersson=0A> > =E5=8F=91=E9= =80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B49=E6=9C=8819=E6=97=A5 18:49=0A> > = =E6=8A=84=E9=80=81: mpls@ietf.org;=0A> MPLS-TP ad hoc team; draft-ietf-mpls= -tp-ring-protection@tools.ietf.org;=0A> mpls-chairs@tools.ietf.org=0A> > = =E4=B8=BB=E9=A2=98: [mpls] Working group last call on=0A> draft-ietf-mpls-t= p-ring-protection=0A> >=0A> > Working Group,=0A> >=0A> > this is to start a= two week working group last call on=0A> > draft-ietf-mpls-tp-ring-protecti= on-02-txt.=0A> >=0A> > Please note that there are two IPR disclosures # 146= 2=0A> and=C2=A0 # 1872=0A> > related to this document.=0A> >=0A> > Please s= end your comments to the mpls working group=0A> mailing lists=0A> > (mpls@i= etf.org).=0A> >=0A> > The working group last call ends October 3, 2012.=0A>= >=0A> > /Loa=0A> > for the mpls wg co-chairs=0A> >=0A> >=0A> > --=0A> >=0A= > >=0A> > Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=0A> =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0email:=0A> loa.andersson@eri= csson.com=0A> > Sr Strategy and Standards Manager=C2=A0 =C2=A0 =C2=A0=0A> = =C2=A0 =C2=A0 =C2=A0 loa@pi.nu=0A> > Ericsson Inc=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 phon= e: +46=0A> 10 717 52 13=0A> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=0A> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +46=0A> 767 72 92 1= 3=0A> > _______________________________________________=0A> > mpls mailing = list=0A> > mpls@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/mpls= =0A> > _______________________________________________=0A> > mpls mailing l= ist=0A> > mpls@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/mpls=0A= > =0A> -- =0A> ************************************************************= *****=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=0A> =C2=A0=C2=A0=C2=A0= =E8=AF=B7=E8=AE=B0=E4=BD=8F=EF=BC=8C=E4=BD=A0=E6=98=AF=E7=8B=AC=E4=B8=80=E6= =97=A0=E4=BA=8C=E7=9A=84=EF=BC=8C=E5=B0=B1=E5=83=8F=E5=85=B6=E4=BB=96=E6=AF= =8F=E4=B8=80=E4=B8=AA=E4=BA=BA=E4=B8=80=E6=A0=B7=0A> ______________________= _________________________=0A> mpls mailing list=0A> mpls@ietf.org=0A> https= ://www.ietf.org/mailman/listinfo/mpls=0A> From chengwq@gmail.com Tue Oct 2 06:01:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9409421F88DB; Tue, 2 Oct 2012 06:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK+2PHOn9882; Tue, 2 Oct 2012 06:01:43 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC12A21F88D5; Tue, 2 Oct 2012 06:01:42 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so7627687vcb.31 for ; Tue, 02 Oct 2012 06:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Kdi2UeD4JHXr75foV32nBXEMXtkIzyaY7hyWL0tfztk=; b=bJ5XNAxj362IF49+9JXL1W4lraS/i5omrnoVElIS5Ktp4HpcyxdfNDtoeue8UXCKFm j2nuAyt1m7gkVaD90z7QJp9TsfxPCxzsLAl3jLN2bQJJXyOIM+mfFnpXnoLyjdT/lxOy 0KcyT6V1OK/w8+rlYM8k+3MACm4dT2R0/s3hZfDEnOeiSAA2gvJbIidY+dN1bt7XmUxS /nSzbpQnvbz9zN0QFyY+XKTRZkh8vMT6MWMgIa7ASw+mnbEzUPFWSV+QA+pCjmqofoPR 7oz9sBywUWlfJEBIv/etJ2yo+ZpoXuLPhUvnnrLvQV08kM6Rpl7fNWOF9Vj46YUx9Gg9 R6KA== MIME-Version: 1.0 Received: by 10.52.69.132 with SMTP id e4mr8263180vdu.2.1349182902046; Tue, 02 Oct 2012 06:01:42 -0700 (PDT) Received: by 10.58.28.210 with HTTP; Tue, 2 Oct 2012 06:01:41 -0700 (PDT) Date: Tue, 2 Oct 2012 21:01:41 +0800 Message-ID: From: cheng weiqiang To: mpls-bounces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 13:01:43 -0000 Do not support. In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption around the ring. This draft cannot meet the requirement. Best Regards, Cheng Weiqiang Research Institute of China Mobile Department of Network Technology From eric.gray@ericsson.com Tue Oct 2 07:04:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BF121F8466 for ; Tue, 2 Oct 2012 07:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.63 X-Spam-Level: X-Spam-Status: No, score=-6.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crBlnyvzMYxW for ; Tue, 2 Oct 2012 07:04:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC5C21F8458 for ; Tue, 2 Oct 2012 07:04:05 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q92EB2Mm020598 for ; Tue, 2 Oct 2012 09:11:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 2 Oct 2012 10:04:02 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 2 Oct 2012 10:04:00 -0400 Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2gnhyW0qyCN8KrSN6hhvqD9AMyTwACJebw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:04:06 -0000 Forwarded... -----Original Message----- From: cheng weiqiang [mailto:chengwq@gmail.com]=20 Sent: Tuesday, October 02, 2012 9:02 AM To: mpls-bounces@ietf.org Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring-prot= ection@tools.ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-prot= ection Do not support. In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should be optimi= zed for simplification of the ring operation and the resources consumption = around the ring. This draft cannot meet the requirement. Best Regards, Cheng Weiqiang Research Institute of China Mobile Department of Network Technology From nurit.sprecher@nsn.com Tue Oct 2 07:04:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D37721F84E4 for ; Tue, 2 Oct 2012 07:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3OPtHxf+NwY for ; Tue, 2 Oct 2012 07:04:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D394521F8458 for ; Tue, 2 Oct 2012 07:04:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q92E4h1g009986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 16:04:43 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q92E4Zee003883; Tue, 2 Oct 2012 16:04:41 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Oct 2012 16:04:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 2 Oct 2012 16:04:21 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: AQHNllRf82qjNdoiA0OJzsZi6RX7kJehLihwgANBJaCAAa+bgA== References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext D'Alessandro Alessandro Gerardo" , "Loa Andersson" X-OriginalArrivalTime: 02 Oct 2012 14:04:32.0174 (UTC) FILETIME=[D88CE4E0:01CDA0A6] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5856 X-purgate-ID: 151667::1349186684-00003184-AD9F99D4/0-0/0-0 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, MPLS-TP ad hoc team , draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:04:52 -0000 QWxlc3NhbmRybyBhbmQgb3RoZXJzIHRoYXQgc3VwcG9ydGVkIHRoZSBiZWxvdywNCllvdXIgc3Rh dGVtZW50IGJlbG93IGRvZXMgbm90IHByb3ZpZGUgYW55IGluZGljYXRpb24gbm9yIHRlY2huaWNh bCBqdXN0aWZpY2F0aW9uIHdoaWNoIHJlcXVpcmVtZW50cyBhcmUgbm90IGFkZHJlc3NlZCBhbmQg d2h5IGRvIHlvdSB0aGluayB0aGV5IGFyZSBub3QgYWRkcmVzc2VkLi4uLi4NCkhlbmNlIGl0IGlz IGltcG9zc2libGUgdG8gcmVmZXIgdG8gb3IgY29uc2lkZXIgc3VjaCBMQyBjb21tZW50IGFzIHN1 Y2gsIHVubGVzcyB5b3UgcHJvdmlkZSB0ZWNobmljYWwgYXJndW1lbnRzIHRoYXQgd2UgY2FuIGRp c2N1c3MgYW5kIGNvbnNpZGVyLiANCkJlc3QgcmVnYXJkcywNCk51cml0DQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJh cmRvIFttYWlsdG86YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0XSANClNl bnQ6IE1vbmRheSwgT2N0b2JlciAwMSwgMjAxMiAyOjI3IFBNDQpUbzogTG9hIEFuZGVyc3Nvbg0K Q2M6IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBNUExTLVRQIGFk IGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYu b3JnDQpTdWJqZWN0OiBSOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQt aWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQpEbyBub3Qgc3VwcG9ydA0KDQpBY2NvcmRp bmcgdG8gdGhlIG9wdGltaXphdGlvbiBjcml0ZXJpYSBmb3IgcmluZyBwcm90ZWN0aW9uIHNwZWNp ZmllZCBpbiBTZWN0aW9uIDIuNS42LjEgaW4gUkZDNTY1NCwgdGhlIE1QTFMtVFAgcmluZyBwcm90 ZWN0aW9uIHNob3VsZCBiZSBvcHRpbWl6ZWQgZm9yIHNpbXBsaWZpY2F0aW9uIG9mIHRoZSByaW5n IG9wZXJhdGlvbiBhbmQgdGhlIHJlc291cmNlcyBjb25zdW1wdGlvbiBhcm91bmQgdGhlIHJpbmcu IEl0IGlzIG5vdCB0aGUgY2FzZSBvZiB0aGUgcHJvcG9zZWQgc29sdXRpb24uDQpJdCBpcyBhY3R1 YWxseSBzaW1wbHkgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgb2YgYSBsaW5lYXIgcHJvdGVj dGlvbiBtZWNoYW5pc20gYnV0IGl0IGNhbm5vdCBiZSBjb25zaWRlciBhIHNvbHV0aW9uIHRoYXQg YWRkcmVzc2VzIHRoZSByZXF1aXJlbWVudHMgZm9yIHByb3RlY3Rpb24gb2YgcmluZyB0b3BvbG9n aWVzIGZvciBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgVHJhbnNwb3J0IFByb2ZpbGUg KE1QTFMtVFApIGFzIHNwZWNpZmllZCBpbiBSRkM1NjU0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpBbGVz c2FuZHJvDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGVsZWNvbSBJdGFsaWENCkFsZXNzYW5kcm8gR2VyYXJkbyBE J0FsZXNzYW5kcm8NClRyYW5zcG9ydCBJbm5vdmF0aW9uDQpWaWEgUmVpc3MgUm9tb2xpLCAyNzQg LSAxMDE0OCBUb3Jpbm8NCnBob25lOiAgKzM5IDAxMSAyMjggNTg4Nw0KbW9iaWxlOiArMzkgMzM1 IDc2NiA5NjA3DQpmYXg6ICszOSAwNiA0MTggNjM5IDA3DQoNCg0KLS0tLS1NZXNzYWdnaW8gb3Jp Z2luYWxlLS0tLS0NCkRhOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBIZWppYQ0KSW52aWF0bzogc2FiYXRvIDI5IHNldHRl bWJyZSAyMDEyIDEyOjUzDQpBOiBMb2EgQW5kZXJzc29uDQpDYzogbXBsc0BpZXRmLm9yZzsgbXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRyYWZ0LWlldGYt bXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcNCk9nZ2V0dG86IFJlOiBbbXBs c10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJv dGVjdGlvbg0KDQpEbyBub3Qgc3VwcG9ydC4NCg0KQmFzZWQgb24gdGhlIGFuYWx5c2lzIGluIFNl Y3Rpb24gMi40IG9mIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24tMDIsIHRoZSBy aW5nIHByb3RlY3Rpb24gc2NoZW1lIHVzaW5nIFNQTUUgYXMgZGVzY3JpYmVkLCBlaXRoZXIgd3Jh cHBpbmcgb3Igc3RlZXJpbmcsIGRvZXMgaGF2ZSBkZWZpY2llbmNpZXMsIHdoaWNoIElNSE8gc2hv dWxkIGJlIGJldHRlciByZWNvbnNpZGVyZWQgYW5kIHNvbHZlZCBpZiBwb3NzaWJsZS4NCg0KDQpC LlIuDQpKaWENCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBMb2EgQW5k ZXJzc29uDQrlj5HpgIHml7bpl7Q6IDIwMTLlubQ55pyIMTnml6UgMTg6NDkNCuaKhOmAgTogbXBs c0BpZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmct cHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCuS4 u+mimDogW21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10 cC1yaW5nLXByb3RlY3Rpb24NCg0KV29ya2luZyBHcm91cCwNCg0KdGhpcyBpcyB0byBzdGFydCBh IHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQpkcmFmdC1pZXRmLW1wbHMtdHAt cmluZy1wcm90ZWN0aW9uLTAyLXR4dC4NCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGVyZSBhcmUgdHdv IElQUiBkaXNjbG9zdXJlcyAjIDE0NjIgYW5kICAjIDE4NzINCnJlbGF0ZWQgdG8gdGhpcyBkb2N1 bWVudC4NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBscyB3b3JraW5nIGdy b3VwIG1haWxpbmcgbGlzdHMNCihtcGxzQGlldGYub3JnKS4NCg0KVGhlIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIGVuZHMgT2N0b2JlciAzLCAyMDEyLg0KDQovTG9hDQpmb3IgdGhlIG1wbHMgd2cg Y28tY2hhaXJzDQoNCg0KLS0NCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAg ICAgIGVtYWlsOiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KU3IgU3RyYXRlZ3kgYW5kIFN0 YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51DQpFcmljc3NvbiBJbmMgICAgICAg ICAgICAgICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEzDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5MiAxMw0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBs aXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt cGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkg c29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExh IGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFs bGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2 aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJy b3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmlj YXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwg R3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlh bCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhl IGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1 c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRh Y2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0K DQo= From adrian@olddog.co.uk Tue Oct 2 07:09:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25B321F850D; Tue, 2 Oct 2012 07:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QgzMN6VABhR; Tue, 2 Oct 2012 07:09:45 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id CC83521F84F6; Tue, 2 Oct 2012 07:09:44 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q92E9eHj013619; Tue, 2 Oct 2012 15:09:41 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q92E9boV013601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Oct 2012 15:09:38 +0100 From: "Adrian Farrel" To: "'cheng weiqiang'" , References: In-Reply-To: Date: Tue, 2 Oct 2012 15:09:36 +0100 Message-ID: <0c4c01cda0a7$8f112320$ad336960$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEIPRV8K0zlqiHYHRBod+dmkpb4WJkw0lpw Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:09:46 -0000 Hi, Let me pitch in here as an individual contributor who sourced a lot of the text in 2.5.6.1 of RFC 5654 basing it on the explicit requirements liaised from the ITU-T. I have read and reread that section trying to find the text that is claimed below. It does not exist. Could you please point to the specific requirement you believe is not met? Or maybe you are confused by the preamble text in the section that describes the circumstances under which an optimized protection mechanism (rather than one built from the mechanisms that operate outside a ring) might be developed. Maybe, also, you could explain in what way you consider the current proposal does not make good use of the resources on the ring (i.e. what features don't work) so that the authors can look at improving their solution. Cheers, Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > cheng weiqiang > Sent: 02 October 2012 14:02 > To: mpls-bounces@ietf.org > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring- > protection@tools.ietf.org > Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Do not support. > > In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should be > optimized for simplification of the ring operation and the resources > consumption around the ring. This draft cannot meet the requirement. > > Best Regards, > > Cheng Weiqiang > Research Institute of China Mobile > Department of Network Technology > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Tue Oct 2 07:09:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F055F21F8527 for ; Tue, 2 Oct 2012 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.526 X-Spam-Level: X-Spam-Status: No, score=-4.526 tagged_above=-999 required=5 tests=[AWL=-2.130, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3IFKh9rNidI for ; Tue, 2 Oct 2012 07:09:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id ACE9021F84F6 for ; Tue, 2 Oct 2012 07:09:46 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q92EGlGW022022 for ; Tue, 2 Oct 2012 09:16:57 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 2 Oct 2012 10:09:45 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 2 Oct 2012 10:09:43 -0400 Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2eIxWqKYiVMkDMQWuZ/SaK5jPuoQChHU6g Message-ID: References: <5059A308.3050307@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:09:48 -0000 Rm9yd2FyZGVkLi4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB5YW5nLmpp YW45MEB6dGUuY29tLmNuIFttYWlsdG86eWFuZy5qaWFuOTBAenRlLmNvbS5jbl0gDQpTZW50OiBT YXR1cmRheSwgU2VwdGVtYmVyIDI5LCAyMDEyIDU6MTUgQU0NClRvOiBMb2EgQW5kZXJzc29uDQpD YzogTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlv bkB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgbXBscy1ib3VuY2VzQGlldGYub3JnOyBt cGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogtPC4tDogW21wbHNdIFdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0K SGkgQWxsLA0KDQpJIHRoaW5rIHdlIHNob3VsZCBhZGRyZXNzIGFsbCB0aGUgaXNzdWVzIHRoYXQg SVRVIGxpYWlzb24gbWVudGlvbmVkLg0KDQpCUiwNCkppYW4NCg0KDQoNCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQogICAgICAgICAgICAgTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICA8bG9hQHBpLm51PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgILeivP7IyzogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICDK1bz+yMsgDQogICAgICAgICAgICAgbXBscy1ib3VuY2VzQGkgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICBldGYub3JnICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICCzrcvNIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYu b3JnPiwgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNUExTLVRQ IGFkIGhvYyB0ZWFtICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAyMDEyLTA5LTE5 ICAgICAgICAgICAgIDxhaG1wbHMtdHBAbGlzdHMuaXR1LmludD4sICAgICAgICAgICAgIA0KICAg ICAgICAgICAgIDE4OjQ4ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmct cHJvdGVjdGlvbkB0b28gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBscy5p ZXRmLm9yZywgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICJtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgICAgICAgICAgIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnPiAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg1vfM4iANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiAgICAg IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1tcGxzLXRw LXJpbmctcHJvdGVjdGlvbiAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KDQoNCldvcmtpbmcgR3JvdXAsDQoNCnRo aXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFm dC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAyLXR4dC4NCg0KUGxlYXNlIG5vdGUgdGhh dCB0aGVyZSBhcmUgdHdvIElQUiBkaXNjbG9zdXJlcyAjIDE0NjIgYW5kICAjIDE4NzIgcmVsYXRl ZCB0byB0aGlzIGRvY3VtZW50Lg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBt cGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0cyAobXBsc0BpZXRmLm9yZykuDQoNClRoZSB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIE9jdG9iZXIgMywgMjAxMi4NCg0KL0xvYQ0KZm9y IHRoZSBtcGxzIHdnIGNvLWNoYWlycw0KDQoNCi0tDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAg ICAgICAgICAgICAgICAgICBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NClNyIFN0 cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KRXJpY3Nz b24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIg OTIgMTMgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1w bHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCg0K From eric.gray@ericsson.com Tue Oct 2 07:12:44 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CB021F8575 for ; Tue, 2 Oct 2012 07:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-wi3nm-WFEI for ; Tue, 2 Oct 2012 07:12:43 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 207D721F855F for ; Tue, 2 Oct 2012 07:12:43 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q92EJrAR022710 for ; Tue, 2 Oct 2012 09:19:54 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 2 Oct 2012 10:12:36 -0400 From: Eric Gray To: "mpls@ietf.org" Date: Tue, 2 Oct 2012 10:12:34 -0400 Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: AQEIPRV8K0zlqiHYHRBod+dmkpb4WJkw0lpwgAAC8DA= Message-ID: References: <0c4c01cda0a7$8f112320$ad336960$@olddog.co.uk> In-Reply-To: <0c4c01cda0a7$8f112320$ad336960$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:12:44 -0000 Forwarded... Please do not include the E-Mail address "mpls-bounces@ietf.org" as an addr= essee in=20 your mail... -- Eric -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Tuesday, October 02, 2012 10:10 AM To: 'cheng weiqiang'; mpls-bounces@ietf.org Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring-prot= ection@tools.ietf.org Subject: RE: [mpls] Working group last call on draft-ietf-mpls-tp-ring-prot= ection Hi,=20 Let me pitch in here as an individual contributor who sourced a lot of the = text in 2.5.6.1 of RFC 5654 basing it on the explicit requirements liaised = from the ITU-T. I have read and reread that section trying to find the text that is claimed= below. It does not exist. Could you please point to the specific requirement you believe is not met? = Or maybe you are confused by the preamble text in the section that describe= s the circumstances under which an optimized protection mechanism (rather t= han one built from the mechanisms that operate outside a ring) might be dev= eloped. Maybe, also, you could explain in what way you consider the current proposa= l does not make good use of the resources on the ring (i.e. what features d= on't work) so that the authors can look at improving their solution. Cheers, Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of cheng weiqiang > Sent: 02 October 2012 14:02 > To: mpls-bounces@ietf.org > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org;=20 > draft-ietf-mpls-tp-ring- protection@tools.ietf.org > Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection >=20 > Do not support. >=20 > In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should be=20 > optimized for simplification of the ring operation and the resources=20 > consumption around the ring. This draft cannot meet the requirement. >=20 > Best Regards, >=20 > Cheng Weiqiang > Research Institute of China Mobile > Department of Network Technology > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nurit.sprecher@nsn.com Tue Oct 2 07:50:56 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA4E21F844F for ; Tue, 2 Oct 2012 07:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPI0Fax6b-+A for ; Tue, 2 Oct 2012 07:50:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3E30421F84FF for ; Tue, 2 Oct 2012 07:50:24 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q92EoJYO002588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 16:50:19 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q92EoImE029399; Tue, 2 Oct 2012 16:50:19 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Oct 2012 16:50:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA0AD.3D8439F4" Date: Tue, 2 Oct 2012 16:50:17 +0200 Message-ID: In-Reply-To: <1349174488.11140.YahooMailClassic@web15602.mail.cnb.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [AHMPLS-TP] R: Working group last call ondraft-ietf-mpls-tp-ring-protection Thread-Index: Ac2gioV6N4xSKVO0TLymJnGaGxJxhgAIbTdA References: <506AADC0.2090802@gmail.com> <1349174488.11140.YahooMailClassic@web15602.mail.cnb.yahoo.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Larry" , "D'Alessandro Alessandro Gerardo" , X-OriginalArrivalTime: 02 Oct 2012 14:50:18.0111 (UTC) FILETIME=[3D41A0F0:01CDA0AD] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 68194 X-purgate-ID: 151667::1349189422-00003184-51392D6D/0-0/0-0 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, MPLS-TP ad hoc team , draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] [AHMPLS-TP] R: Working group last call ondraft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:50:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDA0AD.3D8439F4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBIYW4gTGksDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudC4gDQrCtyAgICAgICAgIENhbiB5 b3UgcGxlYXNlIGV4cGxhaW4gd2h5IGRvIHlvdSB0aGluayB0aGVyZSBhcmUgcmlza3MgdGhhdCBw cm90ZWN0aW9uIHN3aXRjaCB0aW1lIGV4Y2VlZHMgNTBtcyAoImZyb20gdGhlIG1vbWVudCBvZiBm YXVsdCBkZXRlY3Rpb24gaW4gYSAgICAgICAgIG5ldHdvcmsgd2l0aCBhIDE2LW5vZGUgcmluZyB3 aXRoIGxlc3MgdGhhbiAxMjAwIGttIG9mIGZpYmVyIiBhcyByZXF1aXJlZCBpbiBSRkMgNTY1NCk/ IFdoYXQgaW4gdGhlIHByb3Bvc2VkIHNvbHV0aW9uIG1ha2UgeW91IHRoaW5rIHRoZXJlIGFyZSBy aXNrcz8gDQrCtyAgICAgICAgIENhbiB5b3UgcGxlYXNlIGluZGljYXRlIHdoeSBkbyB5b3UgdGhp bmsgdGhlIGNvbmZpZ3VyYXRpb24gaXMgdG9vIGNvbXBsZXggYW5kIHdoeSBpdCByZXF1aXJlcyB0 b28gbWFueSBsYWJlbHMgYW5kIE9BTSBzZXNzaW9ucy4uLmFuZCBob3cgZG8geW91IHRoaW5rIHRo aXMgY291bGQgYmUgYmV0dGVyIG9wdGltaXplZD8gDQpJbiBvcmRlciB0byByZWZlciB0byB0aGlz IGFzIGEgTEMgY29tbWVudCwgdGhlIHRlY2huaWNhbCBhcmd1bWVudHMgc2hvdWxkIGJlIHByZXNl bnRlZCBhbmQgZWxhYm9yYXRlZC4gDQpUaGFua3MgYW5kIGJlc3QgcmVnYXJkcywNCk51cml0DQog DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IExhcnJ5DQpT ZW50OiBUdWVzZGF5LCBPY3RvYmVyIDAyLCAyMDEyIDEyOjQxIFBNDQpUbzogRCdBbGVzc2FuZHJv IEFsZXNzYW5kcm8gR2VyYXJkbzsgaHV1YmF0d29ya0BnbWFpbC5jb20NCkNjOiBtcGxzQGlldGYu b3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJh ZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZw0KU3ViamVjdDog UmU6IFttcGxzXSBbQUhNUExTLVRQXSBSOiBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbmRyYWZ0 LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCiANCm5vdCBzdXBwb3J0IQ0KSXQgZG9lc24n dCBzYXRpc2Z5IHNvbWUgcmVxdWlyZW1lbnRzIG9mIHRoZSBvcGVyYXRvcnMuIFRoZSBjb25maWd1 cmF0aW9uIGlzIHRvbyBjb21wbGV4IGFuZCBuZWVkcyB0b28gbWFueSBsYWJlbHMgYW5kIE9BTSBz ZXNzaW9ucy4gVGhlcmUgYXJlIHJpc2tzIHRoYXQgcHJvdGVjdGlvbiBzd2l0Y2ggdGltZSBleGNl ZWQgNTBtcy4NCiANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCkhhbiBMaSwgUGguRCANCkNoaW5hIE1vYmls ZSBSZXNlYXJjaCBJbnN0aXR1dGUNCjMyIFh1YW53dW1lbiBXZXN0IFN0cmVldCwgWGljaGVuZyBE aXN0cmljdCwgQmVpamluZyAxMDAwNTMsIENoaW5hIA0KRmF4OiArODYgMTAgNjMxMzUxNTkgDQpN T0JJTEU6IDEzNTAxMDkzMzg1IA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KIA0KIA0KLS0tIDEy5bm0MTDm nIgy5pel77yM5ZGo5LqMLCBIdXViIHZhbiBIZWx2b29ydCA8aHV1YmF0d29ya0BnbWFpbC5jb20g PG1haWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbT4gPiDlhpnpgZPvvJoNCiANCj4g5Y+R5Lu25Lq6 OiBIdXViIHZhbiBIZWx2b29ydCA8aHV1YmF0d29ya0BnbWFpbC5jb20gPG1haWx0bzpodXViYXR3 b3JrQGdtYWlsLmNvbT4gPg0KPiDkuLvpopg6IFJlOiBbbXBsc10gW0FITVBMUy1UUF0gUjogV29y a2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlv bg0KPiDmlLbku7bkuro6ICJEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvIiA8YWxlc3Nh bmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0IDxtYWlsdG86YWxlc3NhbmRyby5kYWxl c3NhbmRyb0B0ZWxlY29taXRhbGlhLml0PiA+DQo+IOaKhOmAgTogIm1wbHNAaWV0Zi5vcmcgPG1h aWx0bzptcGxzQGlldGYub3JnPiAiIDxtcGxzQGlldGYub3JnIDxtYWlsdG86bXBsc0BpZXRmLm9y Zz4gPiwgIm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIDxtYWlsdG86bXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc+ICIgPG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIDxtYWlsdG86bXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc+ID4sICJNUExTLVRQIGFkIGhvYyB0ZWFtIiA8YWhtcGxzLXRw QGxpc3RzLml0dS5pbnQgPG1haWx0bzphaG1wbHMtdHBAbGlzdHMuaXR1LmludD4gPiwgImRyYWZ0 LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcgPG1haWx0bzpkcmFm dC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPiAiIDxkcmFmdC1p ZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnIDxtYWlsdG86ZHJhZnQt aWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZz4gPg0KPiDml6XmnJ86 IDIwMTLlubQxMOaciDLml6Us5ZGo5LqMLOS4i+WNiDU6MDINCj4gRG8gbm90IHN1cHBvcnQuDQo+ IA0KPiBTYW1lIHJlYXNvbnMgYXMgbWVudGlvbmVkIGJlbG93Lg0KPiANCj4gUmVnYXJkcywgSHV1 Yi4NCj4gDQo+IE9uIDAxLTEwLTEyIDE0OjI3LCBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJh cmRvIHdyb3RlOg0KPiA+IERvIG5vdCBzdXBwb3J0DQo+ID4NCj4gPiBBY2NvcmRpbmcgdG8gdGhl IG9wdGltaXphdGlvbiBjcml0ZXJpYSBmb3IgcmluZw0KPiBwcm90ZWN0aW9uIHNwZWNpZmllZCBp biBTZWN0aW9uIDIuNS42LjEgaW4gUkZDNTY1NCwgdGhlDQo+IE1QTFMtVFAgcmluZyBwcm90ZWN0 aW9uIHNob3VsZCBiZSBvcHRpbWl6ZWQgZm9yDQo+IHNpbXBsaWZpY2F0aW9uIG9mIHRoZSByaW5n IG9wZXJhdGlvbiBhbmQgdGhlIHJlc291cmNlcw0KPiBjb25zdW1wdGlvbiBhcm91bmQgdGhlIHJp bmcuIEl0IGlzIG5vdCB0aGUgY2FzZSBvZiB0aGUNCj4gcHJvcG9zZWQgc29sdXRpb24uDQo+ID4g SXQgaXMgYWN0dWFsbHkgc2ltcGx5IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IG9mIGENCj4g bGluZWFyIHByb3RlY3Rpb24gbWVjaGFuaXNtIGJ1dCBpdCBjYW5ub3QgYmUgY29uc2lkZXIgYQ0K PiBzb2x1dGlvbiB0aGF0IGFkZHJlc3NlcyB0aGUgcmVxdWlyZW1lbnRzIGZvciBwcm90ZWN0aW9u IG9mDQo+IHJpbmcgdG9wb2xvZ2llcyBmb3IgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5n IFRyYW5zcG9ydA0KPiBQcm9maWxlIChNUExTLVRQKSBhcyBzcGVjaWZpZWQgaW4gUkZDNTY1NC4N Cj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBBbGVzc2FuZHJvDQo+ID4NCj4gPg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPiBUZWxlY29tIEl0YWxpYQ0KPiA+IEFsZXNzYW5kcm8gR2VyYXJkbyBEJ0FsZXNz YW5kcm8NCj4gPiBUcmFuc3BvcnQgSW5ub3ZhdGlvbg0KPiA+IFZpYSBSZWlzcyBSb21vbGksIDI3 NCAtIDEwMTQ4IFRvcmlubw0KPiA+IHBob25lOiAgKzM5IDAxMSAyMjggNTg4Nw0KPiA+IG1vYmls ZTogKzM5IDMzNSA3NjYgOTYwNw0KPiA+IGZheDogKzM5IDA2IDQxOCA2MzkgMDcNCj4gPg0KPiA+ DQo+ID4gLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCj4gPiBEYTogbXBscy1ib3VuY2Vz QGlldGYub3JnIDxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPiANCj4gW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IF0NCj4gUGVy IGNvbnRvIGRpIEhlamlhDQo+ID4gSW52aWF0bzogc2FiYXRvIDI5IHNldHRlbWJyZSAyMDEyIDEy OjUzDQo+ID4gQTogTG9hIEFuZGVyc3Nvbg0KPiA+IENjOiBtcGxzQGlldGYub3JnIDxtYWlsdG86 bXBsc0BpZXRmLm9yZz4gOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyA8bWFpbHRvOm1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnPiA7DQo+IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRyYWZ0LWll dGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcgPG1haWx0bzpkcmFmdC1p ZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPiANCj4gPiBPZ2dldHRv OiBSZTogW21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQo+IGRyYWZ0LWlldGYtbXBs cy10cC1yaW5nLXByb3RlY3Rpb24NCj4gPg0KPiA+IERvIG5vdCBzdXBwb3J0Lg0KPiA+DQo+ID4g QmFzZWQgb24gdGhlIGFuYWx5c2lzIGluIFNlY3Rpb24gMi40IG9mDQo+IGRyYWZ0LWlldGYtbXBs cy10cC1yaW5nLXByb3RlY3Rpb24tMDIsIHRoZSByaW5nIHByb3RlY3Rpb24NCj4gc2NoZW1lIHVz aW5nIFNQTUUgYXMgZGVzY3JpYmVkLCBlaXRoZXIgd3JhcHBpbmcgb3Igc3RlZXJpbmcsDQo+IGRv ZXMgaGF2ZSBkZWZpY2llbmNpZXMsIHdoaWNoIElNSE8gc2hvdWxkIGJlIGJldHRlcg0KPiByZWNv bnNpZGVyZWQgYW5kIHNvbHZlZCBpZiBwb3NzaWJsZS4NCj4gPg0KPiA+DQo+ID4gQi5SLg0KPiA+ IEppYQ0KPiA+DQo+ID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+IOWPkeS7tuS6ujogbXBs cy1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPiANCj4gW21h aWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+ IF0NCj4g5Luj6KGoIExvYSBBbmRlcnNzb24NCj4gPiDlj5HpgIHml7bpl7Q6IDIwMTLlubQ55pyI MTnml6UgMTg6NDkNCj4gPiDmioTpgIE6IG1wbHNAaWV0Zi5vcmcgPG1haWx0bzptcGxzQGlldGYu b3JnPiA7DQo+IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXBy b3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcgPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1w cm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPiA7DQo+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn IDxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+IA0KPiA+IOS4u+mimDogW21wbHNd IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQo+IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXBy b3RlY3Rpb24NCj4gPg0KPiA+IFdvcmtpbmcgR3JvdXAsDQo+ID4NCj4gPiB0aGlzIGlzIHRvIHN0 YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj4gPiBkcmFmdC1pZXRm LW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAyLXR4dC4NCj4gPg0KPiA+IFBsZWFzZSBub3RlIHRo YXQgdGhlcmUgYXJlIHR3byBJUFIgZGlzY2xvc3VyZXMgIyAxNDYyDQo+IGFuZCAgIyAxODcyDQo+ ID4gcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50Lg0KPiA+DQo+ID4gUGxlYXNlIHNlbmQgeW91ciBj b21tZW50cyB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwDQo+IG1haWxpbmcgbGlzdHMNCj4gPiAo bXBsc0BpZXRmLm9yZyA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+ICkuDQo+ID4NCj4gPiBUaGUgd29y a2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBPY3RvYmVyIDMsIDIwMTIuDQo+ID4NCj4gPiAvTG9h DQo+ID4gZm9yIHRoZSBtcGxzIHdnIGNvLWNoYWlycw0KPiA+DQo+ID4NCj4gPiAtLQ0KPiA+DQo+ ID4NCj4gPiBMb2EgQW5kZXJzc29uICAgICAgICAgICANCj4gICAgICAgICAgICAgIGVtYWlsOg0K PiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbSA8bWFpbHRvOmxvYS5hbmRlcnNzb25AZXJpY3Nz b24uY29tPiANCj4gPiBTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgIA0KPiAg ICAgICBsb2FAcGkubnUgPG1haWx0bzpsb2FAcGkubnU+IA0KPiA+IEVyaWNzc29uIEluYyAgICAg ICAgICAgDQo+ICAgICAgICAgICAgICAgcGhvbmU6ICs0Ng0KPiAxMCA3MTcgNTIgMTMNCj4gPiAg ICAgICAgICAgICAgIA0KPiAgICAgICAgICAgICAgICANCj4gICAgICAgICAgICAgICAgICs0Ng0K PiA3NjcgNzIgOTIgMTMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9yZyA8bWFp bHRvOm1wbHNAaWV0Zi5vcmc+IA0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscyA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPiAN Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9yZyA8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+IA0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyA8aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPiANCj4gDQo+IC0tIA0KPiAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KPiAgICAgICAgICAgIA0KPiAgICDor7forrDkvY/vvIzkvaDmmK/ni6zkuIDml6Dk uoznmoTvvIzlsLHlg4/lhbbku5bmr4/kuIDkuKrkurrkuIDmoLcNCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4g bXBsc0BpZXRmLm9yZyA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+IA0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscz4gDQo+IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnIDxtYWlsdG86bXBs c0BpZXRmLm9yZz4gDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMg PGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscz4gDQo= ------_=_NextPart_001_01CDA0AD.3D8439F4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPVByb2dJZCBjb250ZW50PVdv cmQuRG9jdW1lbnQ+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQg MTIiPjxtZXRhIG5hbWU9T3JpZ2luYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiI+PGxp bmsgcmVsPUZpbGUtTGlzdCBocmVmPSJjaWQ6ZmlsZWxpc3QueG1sQDAxQ0RBMEJFLjAwNUVEREUw Ij48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8 bzpBbGxvd1BORy8+DQo8bzpUYXJnZXRTY3JlZW5TaXplPjEwMjR4NzY4PC9vOlRhcmdldFNjcmVl blNpemU+DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6Wm9vbT4xMjA8L3c6 Wm9vbT4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNr TW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlB1bmN0 dWF0aW9uS2VybmluZy8+DQo8dzpWYWxpZGF0ZUFnYWluc3RTY2hlbWFzLz4NCjx3OlNhdmVJZlhN TEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4NCjx3Oklnbm9yZU1peGVkQ29udGVu dD5mYWxzZTwvdzpJZ25vcmVNaXhlZENvbnRlbnQ+DQo8dzpBbHdheXNTaG93UGxhY2Vob2xkZXJU ZXh0PmZhbHNlPC93OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+DQo8dzpEb05vdFByb21vdGVR Ri8+DQo8dzpMaWRUaGVtZU90aGVyPkVOLVVTPC93OkxpZFRoZW1lT3RoZXI+DQo8dzpMaWRUaGVt ZUFzaWFuPlgtTk9ORTwvdzpMaWRUaGVtZUFzaWFuPg0KPHc6TGlkVGhlbWVDb21wbGV4U2NyaXB0 PkhFPC93OkxpZFRoZW1lQ29tcGxleFNjcmlwdD4NCjx3OkNvbXBhdGliaWxpdHk+DQo8dzpCcmVh a1dyYXBwZWRUYWJsZXMvPg0KPHc6U25hcFRvR3JpZEluQ2VsbC8+DQo8dzpXcmFwVGV4dFdpdGhQ dW5jdC8+DQo8dzpVc2VBc2lhbkJyZWFrUnVsZXMvPg0KPHc6RG9udEdyb3dBdXRvZml0Lz4NCjx3 OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkRvbnRWZXJ0QWxpZ25DZWxsV2l0aFNwLz4N Cjx3OkRvbnRCcmVha0NvbnN0cmFpbmVkRm9yY2VkVGFibGVzLz4NCjx3OkRvbnRWZXJ0QWxpZ25J blR4YngvPg0KPHc6V29yZDExS2VybmluZ1BhaXJzLz4NCjx3OkNhY2hlZENvbEJhbGFuY2UvPg0K PC93OkNvbXBhdGliaWxpdHk+DQo8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBs b3JlcjQ8L3c6QnJvd3NlckxldmVsPg0KPG06bWF0aFByPg0KPG06bWF0aEZvbnQgbTp2YWw9IkNh bWJyaWEgTWF0aCIvPg0KPG06YnJrQmluIG06dmFsPSJiZWZvcmUiLz4NCjxtOmJya0JpblN1YiBt OnZhbD0iJiM0NTstIi8+DQo8bTpzbWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0KPG06ZGlzcERlZi8+ DQo8bTpsTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpyTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpkZWZK YyBtOnZhbD0iY2VudGVyR3JvdXAiLz4NCjxtOndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCjxt OmludExpbSBtOnZhbD0ic3ViU3VwIi8+DQo8bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCjwv bTptYXRoUHI+PC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVm VW5oaWRlV2hlblVzZWQ9InRydWUiIERlZlNlbWlIaWRkZW49InRydWUiIERlZlFGb3JtYXQ9ImZh bHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjI2NyI+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFk aW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcg OSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0i dG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5h bWU9InRvYyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBOYW1lPSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzOSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzkiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlv biIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i VGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgTmFt ZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIxMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iRW1waGFzaXMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTkiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlRhYmxlIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlBsYWNlaG9sZGVy IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iTm8gU3BhY2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg TGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFk aW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3Jp ZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg U2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFy ayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAy IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRp bmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0 IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ikxp Z2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlz dCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3Qg MSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJT dWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9 InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJl bmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM3IiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8L3c6 TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVm aW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9z ZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtY2hhcnNldDoyOw0KCW1zby1nZW5l cmljLWZvbnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZv bnQtc2lnbmF0dXJlOjAgMjY4NDM1NDU2IDAgMCAtMjE0NzQ4MzY0OCAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAy IDQ7DQoJbXNvLWZvbnQtYWx0OiLvvK3vvLMg44K044K344OD44KvIjsNCgltc28tZm9udC1jaGFy c2V0OjEyODsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0 Y2g6Zml4ZWQ7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTc5MTQ5MTU3OSAxOCAw IDEzMTIzMSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWluZ0xpVTsNCglwYW5vc2Ut MToyIDIgNSA5IDAgMCAwIDAgMCAwOw0KCW1zby1mb250LWFsdDrntLDmmI7pq5Q7DQoJbXNvLWZv bnQtY2hhcnNldDoxMzY7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6bW9kZXJuOw0KCW1zby1m b250LXBpdGNoOmZpeGVkOw0KCW1zby1mb250LXNpZ25hdHVyZTotMTYxMDYxMTk2OSA2ODQ3MTkz NTQgMjIgMCAxMDQ4NTc3IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0Ow0KCW1zby1mb250LWFsdDoiQ2Fs aXN0byBNVCI7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5 OnJvbWFuOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTot NTM2ODcwMTQ1IDExMDczMDU3MjcgMCAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1h bHQ6QXJpYWw7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5 OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTot NTIwMDkyOTI5IDEwNzM3ODYxMTEgOSAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0Ow0KCW1zby1mb250LWFs dDpWZXJkYW5hOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWls eTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6 LTUyMDA4MTY2NSAtMTA3MzcxNzE1NyA0MSAwIDY2MDQ3IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDsNCgltc28t Zm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6bW9kZXJuOw0KCW1zby1m b250LXBpdGNoOmZpeGVkOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTIwMDkyOTI5IDEwNzM4MDY1 OTEgOSAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWluZ0xpVSI7DQoJ cGFub3NlLTE6MiAyIDUgOSAwIDAgMCAwIDAgMDsNCgltc28tZm9udC1jaGFyc2V0OjEzNjsNCglt c28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6Zml4ZWQ7DQoJ bXNvLWZvbnQtc2lnbmF0dXJlOi0xNjEwNjExOTY5IDY4NDcxOTM1NCAyMiAwIDEwNDg1NzcgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDoxMjg7DQoJbXNvLWdlbmVyaWMt Zm9udC1mYW1pbHk6bW9kZXJuOw0KCW1zby1mb250LXBpdGNoOmZpeGVkOw0KCW1zby1mb250LXNp Z25hdHVyZTotNTM2ODcwMTQ1IDE3OTE0OTE1NzkgMTggMCAxMzEyMzEgMDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5 bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1z by1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNCgltc28tYmlkaS1s YW5ndWFnZTpBUi1TQTt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJ dGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxp bmU6c2luZ2xlO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFp blRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1w YWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJpZGktbGFuZ3VhZ2U6QVItU0E7fQ0KcC5Nc29BY2V0 YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtbm9zaG93Onll czsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFn aW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1iaWRpLWxhbmd1YWdlOkFSLVNBO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtbG9ja2VkOnllczsNCgltc28tc3R5bGUtbGlu azoiUGxhaW4gVGV4dCI7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjVwdDsNCgltc28tYmlkaS1m b250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1hc2NpaS1mb250 LWZhbWlseTpDb25zb2xhczsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bh bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtbG9ja2VkOnllczsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCgltc28tYW5zaS1mb250LXNpemU6OC4wcHQ7DQoJbXNvLWJpZGktZm9u dC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28t YXNjaWktZm9udC1mYW1pbHk6VGFob21hOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpUYWhvbWE7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6VGFob21hO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCgltc28tYXNj aWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OkFyaWFsOw0KCW1zby1iaWRpLWxhbmd1YWdlOkFSLVNBO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47DQoJ bXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCgltc28tZm9vdGVyLW1hcmdpbjouNWluOw0KCW1zby1w YXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjk5NzYxNDA4 OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2MDg0 ODA4NjQgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gMTBdPjxzdHlsZT4vKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9y bWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6IlRhYmxlIE5vcm1hbCI7DQoJbXNvLXRzdHlsZS1y b3diYW5kLXNpemU6MDsNCgltc28tdHN0eWxlLWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHlsZS1u b3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtcWZvcm1hdDp5 ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBp biA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1iaWRpLWxhbmd1YWdlOkFSLVNBO30NCjwvc3R5 bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlIHN0eWxl PSd0YWItaW50ZXJ2YWw6LjVpbic+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PkRlYXIgSGFuIExpLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dCBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0aWZ5Jz5UaGFua3MgZm9yIHlvdXIgY29tbWVudC4gPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSdtYXJnaW4tbGVmdDouNWlu O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OlN5bWJvbDttc28tZmFyZWFzdC1mb250 LWZhbWlseTpTeW1ib2w7bXNvLWJpZGktZm9udC1mYW1pbHk6U3ltYm9sJz48c3BhbiBzdHlsZT0n bXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj1MVFI+PC9zcGFuPkNhbiB5b3Ug cGxlYXNlIGV4cGxhaW4gd2h5IGRvIHlvdSB0aGluayB0aGVyZSBhcmUgcmlza3MgdGhhdCBwcm90 ZWN0aW9uIHN3aXRjaCB0aW1lIGV4Y2VlZHMgNTBtcyAoJnF1b3Q7ZnJvbSB0aGUgbW9tZW50IG9m IGZhdWx0IGRldGVjdGlvbiBpbiBhIDxzcGFuIHN0eWxlPSdtc28tc3BhY2VydW46eWVzJz7CoMKg wqDCoMKgwqDCoMKgPC9zcGFuPm5ldHdvcmsgd2l0aCBhIDE2LW5vZGUgcmluZyB3aXRoIGxlc3Mg dGhhbiAxMjAwIGttIG9mIGZpYmVyJnF1b3Q7IGFzIHJlcXVpcmVkIGluIFJGQyA1NjU0KT8gV2hh dCBpbiB0aGUgcHJvcG9zZWQgc29sdXRpb24gbWFrZSB5b3UgdGhpbmsgdGhlcmUgYXJlIHJpc2tz PyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9J21hcmdpbi1sZWZ0 Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6U3ltYm9sO21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OlN5bWJvbDttc28tYmlkaS1mb250LWZhbWlseTpTeW1ib2wnPjxzcGFuIHN0 eWxlPSdtc28tbGlzdDpJZ25vcmUnPsK3PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5l dyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPUxUUj48L3NwYW4+Q2Fu IHlvdSBwbGVhc2UgaW5kaWNhdGUgd2h5IGRvIHlvdSB0aGluayB0aGUgY29uZmlndXJhdGlvbiBp cyB0b28gY29tcGxleCBhbmQgd2h5IGl0IHJlcXVpcmVzIHRvbyBtYW55IGxhYmVscyBhbmQgT0FN IHNlc3Npb25zLi4uYW5kIGhvdyBkbyB5b3UgdGhpbmsgdGhpcyBjb3VsZCBiZSBiZXR0ZXIgb3B0 aW1pemVkPyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+SW4gb3JkZXIgdG8g cmVmZXIgdG8gdGhpcyBhcyBhIExDIGNvbW1lbnQsIHRoZSB0ZWNobmljYWwgYXJndW1lbnRzIHNo b3VsZCBiZSBwcmVzZW50ZWQgYW5kIGVsYWJvcmF0ZWQuIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD5UaGFua3MgYW5kIGJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+TnVyaXQ8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxl PSdtc28tYmlkaS1sYW5ndWFnZTpIRSc+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+RnJv bTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgZXh0IExhcnJ5PGJyPlNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDIsIDIwMTIg MTI6NDEgUE08YnI+VG86IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG87IGh1dWJhdHdv cmtAZ21haWwuY29tPGJyPkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRm Lm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVj dGlvbkB0b29scy5pZXRmLm9yZzxicj5TdWJqZWN0OiBSZTogW21wbHNdIFtBSE1QTFMtVFBdIFI6 IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVj dGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJz cDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pm5vdCBzdXBwb3J0ITxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5JdCBkb2Vzbid0IHNhdGlzZnkgc29tZSByZXF1aXJl bWVudHMgb2YgdGhlIG9wZXJhdG9ycy4gVGhlIGNvbmZpZ3VyYXRpb24gaXMgdG9vIGNvbXBsZXgg YW5kIG5lZWRzIHRvbyBtYW55IGxhYmVscyBhbmQgT0FNIHNlc3Npb25zLiBUaGVyZSBhcmUgcmlz a3MgdGhhdCBwcm90ZWN0aW9uIHN3aXRjaCB0aW1lIGV4Y2VlZCA1MG1zLjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD5IYW4gTGksIFBoLkQgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkNo aW5hIE1vYmlsZSBSZXNlYXJjaCBJbnN0aXR1dGU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+MzIgWHVhbnd1bWVuIFdlc3QgU3RyZWV0LCBYaWNoZW5nIERpc3RyaWN0LCBCZWlq aW5nIDEwMDA1MywgQ2hpbmEgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkZh eDogKzg2IDEwIDYzMTM1MTU5IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5N T0JJTEU6IDEzNTAxMDkzMzg1IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4q KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+LS0tIDEyPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJN UyBHb3RoaWMiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7lubQ8L3NwYW4+MTA8 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7bXNvLWJpZGktZm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyInPuaciDwvc3Bhbj4yPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJNUyBHb3Ro aWMiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7ml6XvvIzlkajkuow8L3NwYW4+ LCBIdXViIHZhbiBIZWx2b29ydCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1dWJhdHdvcmtAZ21haWwu Y29tIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0 ZXh0LXVuZGVybGluZTpub25lJz5odXViYXR3b3JrQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0OyA8 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7bXNvLWJpZGktZm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyInPuWGmemBk++8mjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5Ok1pbmdMaVU7bXNvLWJpZGktZm9udC1mYW1pbHk6TWlu Z0xpVSc+5Y+R5Lu25Lq6PC9zcGFuPjogSHV1YiB2YW4gSGVsdm9vcnQgJmx0OzxhIGhyZWY9Im1h aWx0bzpodXViYXR3b3JrQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+aHV1YmF0d29ya0BnbWFp bC5jb208L3NwYW4+PC9hPiZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7bXNvLWJpZGktZm9udC1m YW1pbHk6Ik1TIEdvdGhpYyInPuS4uzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6TWlu Z0xpVTttc28tYmlkaS1mb250LWZhbWlseTpNaW5nTGlVJz7popg8L3NwYW4+OiBSZTogW21wbHNd IFtBSE1QTFMtVFBdIFI6IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBs cy10cC1yaW5nLXByb3RlY3Rpb248bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7bXNvLWJpZGktZm9udC1m YW1pbHk6Ik1TIEdvdGhpYyInPuaUtuS7tuS6ujwvc3Bhbj46ICZxdW90O0QnQWxlc3NhbmRybyBB bGVzc2FuZHJvIEdlcmFyZG8mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphbGVzc2FuZHJvLmRh bGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXQiPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0 O3RleHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5lOm5vbmUnPmFsZXNzYW5kcm8uZGFs ZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdDwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290 aGljIjttc28tYmlkaS1mb250LWZhbWlseToiTVMgR290aGljIic+5oqE6YCBPC9zcGFuPjogJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5lOm5vbmUnPm1wbHNAaWV0 Zi5vcmc8L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lO3RleHQt dW5kZXJsaW5lOm5vbmUnPm1wbHNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDssICZxdW90OzxhIGhy ZWY9Im1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2NvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5tcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OywgJnF1b3Q7TVBMUy1UUCBhZCBob2MgdGVh bSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFobXBscy10cEBsaXN0cy5pdHUuaW50Ij48c3Bh biBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVy bGluZTpub25lJz5haG1wbHMtdHBAbGlzdHMuaXR1LmludDwvc3Bhbj48L2E+Jmd0OywgJnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMu aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lO3RleHQtdW5kZXJsaW5lOm5vbmUnPmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rp b25AdG9vbHMuaWV0Zi5vcmc8L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRy YWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5l Om5vbmUnPmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8 L3NwYW4+PC9hPiZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7bXNvLWJpZGktZm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyInPuaXpeacnzwvc3Bhbj46IDIwMTI8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7bXNvLWJpZGktZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuW5tDwvc3Bhbj4x MDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290aGljIjttc28tYmlkaS1mb250LWZhbWls eToiTVMgR290aGljIic+5pyIPC9zcGFuPjI8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdv dGhpYyI7bXNvLWJpZGktZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuaXpTwvc3Bhbj4sPHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJNUyBH b3RoaWMiJz7lkajkuow8L3NwYW4+LDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290aGlj Ijttc28tYmlkaS1mb250LWZhbWlseToiTVMgR290aGljIic+5LiL5Y2IPC9zcGFuPjU6MDI8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBEbyBub3Qgc3VwcG9ydC48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBTYW1lIHJlYXNvbnMgYXMgbWVudGlvbmVkIGJlbG93Ljxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IFJlZ2FyZHMsIEh1dWIuPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgT24gMDEtMTAtMTIgMTQ6MjcsIEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFy ZG8gd3JvdGU6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBE byBub3Qgc3VwcG9ydDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZn dDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IEFjY29yZGlu ZyB0byB0aGUgb3B0aW1pemF0aW9uIGNyaXRlcmlhIGZvciByaW5nPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgcHJvdGVjdGlvbiBzcGVjaWZpZWQgaW4gU2VjdGlvbiAy LjUuNi4xIGluIFJGQzU2NTQsIHRoZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7IE1QTFMtVFAgcmluZyBwcm90ZWN0aW9uIHNob3VsZCBiZSBvcHRpbWl6ZWQgZm9yPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgc2ltcGxpZmljYXRpb24gb2Yg dGhlIHJpbmcgb3BlcmF0aW9uIGFuZCB0aGUgcmVzb3VyY2VzPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsgY29uc3VtcHRpb24gYXJvdW5kIHRoZSByaW5nLiBJdCBpcyBu b3QgdGhlIGNhc2Ugb2YgdGhlPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgcHJvcG9zZWQgc29sdXRpb24uPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsgJmd0OyBJdCBpcyBhY3R1YWxseSBzaW1wbHkgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1l bnQgb2YgYTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IGxpbmVhciBw cm90ZWN0aW9uIG1lY2hhbmlzbSBidXQgaXQgY2Fubm90IGJlIGNvbnNpZGVyIGE8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBzb2x1dGlvbiB0aGF0IGFkZHJlc3NlcyB0 aGUgcmVxdWlyZW1lbnRzIGZvciBwcm90ZWN0aW9uIG9mPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsgcmluZyB0b3BvbG9naWVzIGZvciBNdWx0aS1Qcm90b2NvbCBMYWJl bCBTd2l0Y2hpbmcgVHJhbnNwb3J0PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsgUHJvZmlsZSAoTVBMUy1UUCkgYXMgc3BlY2lmaWVkIGluIFJGQzU2NTQuPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgQmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgQWxlc3NhbmRybzxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0 OyBUZWxlY29tIEl0YWxpYTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 ICZndDsgQWxlc3NhbmRybyBHZXJhcmRvIEQnQWxlc3NhbmRybzxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgVHJhbnNwb3J0IElubm92YXRpb248bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IFZpYSBSZWlzcyBSb21vbGksIDI3 NCAtIDEwMTQ4IFRvcmlubzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 ICZndDsgcGhvbmU6Jm5ic3A7ICszOSAwMTEgMjI4IDU4ODc8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IG1vYmlsZTogKzM5IDMzNSA3NjYgOTYwNzxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgZmF4OiArMzkgMDYgNDE4IDYz OSAwNzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDs8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyAtLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0t LTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgRGE6IDxhIGhy ZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5lOm5vbmUnPm1wbHMtYm91 bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgWzxhIGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5l Om5vbmUnPm1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBQZXIgY29udG8gZGkgSGVqaWE8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IEludmlhdG86IHNhYmF0byAy OSBzZXR0ZW1icmUgMjAxMiAxMjo1MzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7ICZndDsgQTogTG9hIEFuZGVyc3NvbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7ICZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj48c3Bh biBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVy bGluZTpub25lJz5tcGxzQGlldGYub3JnPC9zcGFuPjwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bXBscy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc8L3NwYW4+PC9hPjs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyBNUExTLVRQIGFkIGhvYyB0ZWFtOyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxz LXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2NvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+ZHJhZnQt aWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZzwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBPZ2dldHRvOiBSZTog W21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IERvIG5vdCBzdXBwb3J0LjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IEJhc2VkIG9uIHRoZSBhbmFseXNpcyBpbiBTZWN0aW9u IDIuNCBvZjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IGRyYWZ0LWll dGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24tMDIsIHRoZSByaW5nIHByb3RlY3Rpb248bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBzY2hlbWUgdXNpbmcgU1BNRSBhcyBk ZXNjcmliZWQsIGVpdGhlciB3cmFwcGluZyBvciBzdGVlcmluZyw8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBkb2VzIGhhdmUgZGVmaWNpZW5jaWVzLCB3aGljaCBJTUhP IHNob3VsZCBiZSBiZXR0ZXI8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyByZWNvbnNpZGVyZWQgYW5kIHNvbHZlZCBpZiBwb3NzaWJsZS48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 ICZndDsgQi5SLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsg SmlhPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OzxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgLS0tLS08c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6TWluZ0xpVTttc28tYmlkaS1mb250LWZhbWlseTpNaW5nTGlVJz7pgq7ku7bl jp/ku7Y8L3NwYW4+LS0tLS08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyAmZ3Q7IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpNaW5nTGlVO21zby1iaWRpLWZvbnQtZmFt aWx5Ok1pbmdMaVUnPuWPkeS7tuS6ujwvc3Bhbj46IDxhIGhyZWY9Im1haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lO3RleHQtdW5kZXJsaW5lOm5vbmUnPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgWzxhIGhyZWY9Im1h aWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0 O3RleHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5lOm5vbmUnPm1haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7bXNvLWJpZGkt Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuS7o+ihqDwvc3Bhbj4gTG9hIEFuZGVyc3NvbjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5Ok1pbmdMaVU7bXNvLWJpZGktZm9udC1mYW1pbHk6TWluZ0xpVSc+5Y+R6YCB5pe2 6Ze0PC9zcGFuPjogMjAxMjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290aGljIjttc28t YmlkaS1mb250LWZhbWlseToiTVMgR290aGljIic+5bm0PC9zcGFuPjk8c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6Ik1TIEdvdGhpYyI7bXNvLWJpZGktZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuac iDwvc3Bhbj4xOTxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290aGljIjttc28tYmlkaS1m b250LWZhbWlseToiTVMgR290aGljIic+5pelPC9zcGFuPiAxODo0OTxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJN UyBHb3RoaWMiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7mioTpgIE8L3NwYW4+ OiA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRv d3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bXBsc0BpZXRm Lm9yZzwvc3Bhbj48L2E+OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 IE1QTFMtVFAgYWQgaG9jIHRlYW07IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAt cmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5kcmFmdC1pZXRm LW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT47PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPGEgaHJlZj0ibWFpbHRvOm1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5tcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgJmd0OyA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7bXNvLWJpZGktZm9u dC1mYW1pbHk6Ik1TIEdvdGhpYyInPuS4uzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 TWluZ0xpVTttc28tYmlkaS1mb250LWZhbWlseTpNaW5nTGlVJz7popg8L3NwYW4+OiBbbXBsc10g V29ya2luZyBncm91cCBsYXN0IGNhbGwgb248bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgV29ya2luZyBHcm91cCw8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgJmd0OyB0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91 cCBsYXN0IGNhbGwgb248bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAm Z3Q7IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24tMDItdHh0LjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgdGhlcmUgYXJlIHR3byBJ UFIgZGlzY2xvc3VyZXMgIyAxNDYyPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsgYW5kJm5ic3A7ICMgMTg3MjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7ICZndDsgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyAmZ3Q7IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHMgd29y a2luZyBncm91cDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IG1haWxp bmcgbGlzdHM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7ICg8 YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bXBsc0BpZXRmLm9y Zzwvc3Bhbj48L2E+KS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAm Z3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBUaGUgd29y a2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBPY3RvYmVyIDMsIDIwMTIuPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7ICZndDsgL0xvYTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7ICZndDsgZm9yIHRoZSBtcGxzIHdnIGNvLWNoYWlyczxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgJmd0OyAtLTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDs8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBMb2EgQW5kZXJzc29uJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwO2VtYWlsOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7IDxhIGhyZWY9Im1haWx0bzpsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5 bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6 bm9uZSc+bG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJk cyBNYW5hZ2VyJm5ic3A7ICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86bG9hQHBp Lm51Ij48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0 ZXh0LXVuZGVybGluZTpub25lJz5sb2FAcGkubnU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgRXJpY3Nzb24gSW5jJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgcGhvbmU6ICs0NjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDEw IDcxNyA1MiAxMzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgKzQ2PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgNzY3IDcyIDkyIDEzPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgbXBscyBtYWls aW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IDxh IGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5tcGxzQGlldGYub3Jn PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyI+PHNw YW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRl cmxpbmU6bm9uZSc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBtcGxzIG1haWxpbmcgbGlzdDxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRv Om1wbHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lO3RleHQtdW5kZXJsaW5lOm5vbmUnPm1wbHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIj48c3BhbiBzdHlsZT0nY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7IC0tIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6TWluZ0xpVTttc28tYmlkaS1mb250LWZhbWlseTpNaW5nTGlVJz7or7fo rrDkvY/vvIzkvaDmmK/ni6zkuIDml6DkuoznmoTvvIzlsLHlg4/lhbbku5bmr4/kuIDkuKrkurrk uIDmoLc8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBtcGxzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYu b3JnIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0 ZXh0LXVuZGVybGluZTpub25lJz5tcGxzQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5lOm5vbmUnPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pm1wbHMgbWFpbGluZyBsaXN0PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj48 c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVu ZGVybGluZTpub25lJz5tcGxzQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYm9keT48L2h0 bWw+ ------_=_NextPart_001_01CDA0AD.3D8439F4-- From nurit.sprecher@nsn.com Tue Oct 2 07:51:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A8321F852C for ; Tue, 2 Oct 2012 07:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIVVs+KONSSt for ; Tue, 2 Oct 2012 07:51:28 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2543E21F8527 for ; Tue, 2 Oct 2012 07:51:27 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q92EpP2Q008458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 16:51:25 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q92EpOhF000856; Tue, 2 Oct 2012 16:51:24 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Oct 2012 16:51:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2012 16:51:23 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2eIxWqKYiVMkDMQWuZ/SaK5jPuoQChHU6gAAFxWNA= References: <5059A308.3050307@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 02 Oct 2012 14:51:24.0181 (UTC) FILETIME=[64A31C50:01CDA0AD] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3623 X-purgate-ID: 151667::1349189486-00006F5F-EF3D5DBF/0-0/0-0 Subject: Re: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:51:29 -0000 Did I miss any liaison on this? To what issue do you refer? -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Eric Gray Sent: Tuesday, October 02, 2012 4:10 PM To: mpls@ietf.org Subject: [mpls] FW: Working group last call on = draft-ietf-mpls-tp-ring-protection Forwarded... -----Original Message----- From: yang.jian90@zte.com.cn [mailto:yang.jian90@zte.com.cn]=20 Sent: Saturday, September 29, 2012 5:15 AM To: Loa Andersson Cc: MPLS-TP ad hoc team; = draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls@ietf.org; = mpls-bounces@ietf.org; mpls-chairs@tools.ietf.org Subject: =B4=F0=B8=B4: [mpls] Working group last call on = draft-ietf-mpls-tp-ring-protection Hi All, I think we should address all the issues that ITU liaison mentioned. BR, Jian = =20 Loa Andersson = =20 = =20 =B7=A2=BC=FE=C8=CB: = =CA=D5=BC=FE=C8=CB=20 mpls-bounces@i = =20 etf.org = =B3=AD=CB=CD=20 "mpls@ietf.org" , = =20 MPLS-TP ad hoc team = =20 2012-09-19 , = =20 18:48 = draft-ietf-mpls-tp-ring-protection@too=20 ls.ietf.org, = =20 "mpls-chairs@tools.ietf.org" = =20 = =20 = =D6=F7=CC=E2=20 [mpls] Working group last call on = =20 draft-ietf-mpls-tp-ring-protection = =20 = =20 = =20 = =20 = =20 = =20 = =20 Working Group, this is to start a two week working group last call on = draft-ietf-mpls-tp-ring-protection-02-txt. Please note that there are two IPR disclosures # 1462 and # 1872 = related to this document. Please send your comments to the mpls working group mailing lists = (mpls@ietf.org). The working group last call ends October 3, 2012. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 = _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From huanglu@chinamobile.com Tue Oct 2 07:52:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D154021F844F for ; Tue, 2 Oct 2012 07:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.113 X-Spam-Level: * X-Spam-Status: No, score=1.113 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpXq0POgtH7p for ; Tue, 2 Oct 2012 07:52:32 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 994A821F852B for ; Tue, 2 Oct 2012 07:52:31 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3CEABE3EC for ; Tue, 2 Oct 2012 22:52:32 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 18F6CE3CF for ; Tue, 2 Oct 2012 22:52:32 +0800 (CST) Received: from OEM20120604HPR ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012100222522991-3475 ; Tue, 2 Oct 2012 22:52:29 +0800 From: "Lu Huang" To: Date: Tue, 2 Oct 2012 22:52:28 +0800 Message-ID: <003e01cda0ad$8ac8e360$a05aaa20$@chinamobile.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2grQ+l+OEdC2XtThirH5OTwhR5qg== X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-10-02 22:52:29, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-10-02 22:52:31, Serialize complete at 2012-10-02 22:52:31 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01CDA0F0.98ED0DC0" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19230.003 X-TM-AS-Result: No--11.648-7.0-31-10 X-imss-scan-details: No--11.648-7.0-31-10;No--11.648-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:52:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003F_01CDA0F0.98ED0DC0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Do not support. Same reason as Cheng Weiqiang mentioned. -------------------------------- Best Regards! Lu Huang China Mobile Research Institute No.32 Xuanwumen West Street, Xicheng District Beijing, China, 100053 Mobile: +86 13810820540 Phone: +86 10 15801696688 Ext. 33287 Email: huanglu@chinamobile.com ------=_NextPart_000_003F_01CDA0F0.98ED0DC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

Do not = support.

 

Same reason as Cheng Weiqiang = mentioned.

 

-----------= ---------------------

Best = Regards!

Lu Huang
China Mobile Research Institute
No.32 = Xuanwumen West Street, Xicheng District
Beijing, China, = 100053
Mobile: +86 13810820540
Phone: +86 10 15801696688 Ext. = 33287
Email: huanglu@chinamobile.com=

 

------=_NextPart_000_003F_01CDA0F0.98ED0DC0-- From alessandro.dalessandro@telecomitalia.it Tue Oct 2 07:57:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C98C21F84D1 for ; Tue, 2 Oct 2012 07:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa6asDPmJWOW for ; Tue, 2 Oct 2012 07:57:38 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4185621F84A1 for ; Tue, 2 Oct 2012 07:57:38 -0700 (PDT) Received: from grfhub701rm001.griffon.local (10.19.3.8) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 2 Oct 2012 16:57:33 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by grfhub701rm001.griffon.local ([10.19.9.234]) with mapi; Tue, 2 Oct 2012 16:57:33 +0200 From: D'Alessandro Alessandro Gerardo To: "stbryant@cisco.com" Date: Tue, 2 Oct 2012 16:57:31 +0200 Thread-Topic: R: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2ghYb191i1QpV5SZKJ7B6/1n1Z9wAAD/xQ Message-ID: References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> <05540BD841BBD643BB51404C4C917152151386C118@GRFMBX703BA020.griffon.local> <506ABC45.5050202@cisco.com> In-Reply-To: <506ABC45.5050202@cisco.com> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: [mpls] R: R: R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:57:39 -0000 VGhlIG9wdGltaXphdGlvbnMgSSByZWZlciBhcmUgZGVzY3JpYmVkIGluIFJGQzU2NTQsIFNlY3Rp b24gMi41LjYuMSwgYW1vbmcgdGhlIG90aGVyIGluIHRoZSBwYXJhZ3JhcGggdGhhdCBzdGFydCBh cyAiIFdpdGhpbiB0aGUgY29udGV4dCBvZiByZWNvdmVyeSBpbiBNUExTLVRQIG5ldHdvcmtzLCB0 aGUgb3B0aW1pemF0aW9uIGNyaXRlcmlhIGNvbnNpZGVyZWQgaW4gcmluZyB0b3BvbG9naWVzIGFy ZSBhcyBmb2xsb3dzIC4uLi4iDQoNCkJlc3QgcmVnYXJkcywNCkFsZXNzYW5kcm8NCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpUZWxlY29tIEl0YWxpYQ0KQWxlc3NhbmRybyBHZXJhcmRvIEQnQWxlc3NhbmRybw0KVHJh bnNwb3J0IElubm92YXRpb24NClZpYSBSZWlzcyBSb21vbGksIDI3NCAtIDEwMTQ4IFRvcmlubw0K cGhvbmU6wqAgKzM5IDAxMSAyMjggNTg4Nw0KbW9iaWxlOiArMzkgMzM1IDc2NiA5NjA3DQpmYXg6 ICszOSAwNiA0MTggNjM5IDA3DQoNCi0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0tDQpEYTog U3Rld2FydCBCcnlhbnQgW21haWx0bzpzdGJyeWFudEBjaXNjby5jb21dIA0KSW52aWF0bzogbWFy dGVkw6wgMiBvdHRvYnJlIDIwMTIgMTI6MDUNCkE6IERpIEdpZ2xpbyBBbmRyZWENCkNjOiBDYXZh enpvbmkgQ2FybG87IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG87IExvYSBBbmRlcnNz b247IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBNUExTLVRQIGFk IGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYu b3JnDQpPZ2dldHRvOiBSZTogUjogW21wbHNdIFI6IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0KQWxlc3NhbmRybywgIERpIEdp Z2xpbywgSHV1YiwNCg0KUGxlYXNlIGNvdWxkIHlvdSBiZSBtb3JlIHByZWNpc2UgYnkgc3BlY2lm eWluZyB0aGUgb3B0aW1pemF0aW9ucw0KdGhhdCB5b3UgYmVsaWV2ZSBhcmUgYWNoaWV2YWJsZS4N Cg0KU3Rld2FydA0KDQoNCg0KT24gMDIvMTAvMjAxMiAxMDo1MSwgRGkgR2lnbGlvIEFuZHJlYSB3 cm90ZToNCj4gKzENCj4NCj4gLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCj4gRGE6IG1w bHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNv bnRvIGRpIENhdmF6em9uaSBDYXJsbw0KPiBJbnZpYXRvOiBtYXJ0ZWTDrCAyIG90dG9icmUgMjAx MiAxMDo1OA0KPiBBOiBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvOyBMb2EgQW5kZXJz c29uDQo+IENjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTVBM Uy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29s cy5pZXRmLm9yZw0KPiBPZ2dldHRvOiBSZTogW21wbHNdIFI6IFdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCj4NCj4gKzENCj4NCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRCdBbGVzc2FuZHJv IEFsZXNzYW5kcm8gR2VyYXJkbw0KPiBTZW50OiBsdW5lZMOsIDEgb3R0b2JyZSAyMDEyIDE0OjI3 DQo+IFRvOiBMb2EgQW5kZXJzc29uDQo+IENjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJp bmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBbbXBsc10gUjogV29ya2lu ZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0K Pg0KPiBEbyBub3Qgc3VwcG9ydA0KPg0KPiBBY2NvcmRpbmcgdG8gdGhlIG9wdGltaXphdGlvbiBj cml0ZXJpYSBmb3IgcmluZyBwcm90ZWN0aW9uIHNwZWNpZmllZCBpbiBTZWN0aW9uIDIuNS42LjEg aW4gUkZDNTY1NCwgdGhlIE1QTFMtVFAgcmluZyBwcm90ZWN0aW9uIHNob3VsZCBiZSBvcHRpbWl6 ZWQgZm9yIHNpbXBsaWZpY2F0aW9uIG9mIHRoZSByaW5nIG9wZXJhdGlvbiBhbmQgdGhlIHJlc291 cmNlcyBjb25zdW1wdGlvbiBhcm91bmQgdGhlIHJpbmcuIEl0IGlzIG5vdCB0aGUgY2FzZSBvZiB0 aGUgcHJvcG9zZWQgc29sdXRpb24uDQo+IEl0IGlzIGFjdHVhbGx5IHNpbXBseSBhbiBhcHBsaWNh YmlsaXR5IHN0YXRlbWVudCBvZiBhIGxpbmVhciBwcm90ZWN0aW9uIG1lY2hhbmlzbSBidXQgaXQg Y2Fubm90IGJlIGNvbnNpZGVyIGEgc29sdXRpb24gdGhhdCBhZGRyZXNzZXMgdGhlIHJlcXVpcmVt ZW50cyBmb3IgcHJvdGVjdGlvbiBvZiByaW5nIHRvcG9sb2dpZXMgZm9yIE11bHRpLVByb3RvY29s IExhYmVsIFN3aXRjaGluZyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgYXMgc3BlY2lmaWVk IGluIFJGQzU2NTQuDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gQWxlc3NhbmRybw0KPg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gVGVsZWNvbSBJdGFsaWENCj4gQWxlc3NhbmRybyBHZXJhcmRvIEQnQWxlc3NhbmRy bw0KPiBUcmFuc3BvcnQgSW5ub3ZhdGlvbg0KPiBWaWEgUmVpc3MgUm9tb2xpLCAyNzQgLSAxMDE0 OCBUb3Jpbm8NCj4gcGhvbmU6ICArMzkgMDExIDIyOCA1ODg3DQo+IG1vYmlsZTogKzM5IDMzNSA3 NjYgOTYwNw0KPiBmYXg6ICszOSAwNiA0MTggNjM5IDA3DQo+DQo+DQo+IC0tLS0tTWVzc2FnZ2lv IG9yaWdpbmFsZS0tLS0tDQo+IERhOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBIZWppYQ0KPiBJbnZpYXRvOiBzYWJhdG8g Mjkgc2V0dGVtYnJlIDIwMTIgMTI6NTMNCj4gQTogTG9hIEFuZGVyc3Nvbg0KPiBDYzogbXBsc0Bp ZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IE1QTFMtVFAgYWQgaG9jIHRlYW07 IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcNCj4gT2dn ZXR0bzogUmU6IFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1w bHMtdHAtcmluZy1wcm90ZWN0aW9uDQo+DQo+IERvIG5vdCBzdXBwb3J0Lg0KPg0KPiBCYXNlZCBv biB0aGUgYW5hbHlzaXMgaW4gU2VjdGlvbiAyLjQgb2YgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmct cHJvdGVjdGlvbi0wMiwgdGhlIHJpbmcgcHJvdGVjdGlvbiBzY2hlbWUgdXNpbmcgU1BNRSBhcyBk ZXNjcmliZWQsIGVpdGhlciB3cmFwcGluZyBvciBzdGVlcmluZywgZG9lcyBoYXZlIGRlZmljaWVu Y2llcywgd2hpY2ggSU1ITyBzaG91bGQgYmUgYmV0dGVyIHJlY29uc2lkZXJlZCBhbmQgc29sdmVk IGlmIHBvc3NpYmxlLg0KPg0KPg0KPiBCLlIuDQo+IEppYQ0KPg0KPiAtLS0tLemCruS7tuWOn+S7 ti0tLS0tDQo+IOWPkeS7tuS6ujogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnXSDku6PooaggTG9hIEFuZGVyc3Nvbg0KPiDlj5HpgIHml7bpl7Q6IDIw MTLlubQ55pyIMTnml6UgMTg6NDkNCj4g5oqE6YCBOiBtcGxzQGlldGYub3JnOyBNUExTLVRQIGFk IGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYu b3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiDkuLvpopg6IFttcGxzXSBXb3JraW5n IGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQo+ DQo+IFdvcmtpbmcgR3JvdXAsDQo+DQo+IHRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9u LTAyLXR4dC4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCB0aGVyZSBhcmUgdHdvIElQUiBkaXNjbG9z dXJlcyAjIDE0NjIgYW5kICAjIDE4NzIgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50Lg0KPg0KPiBQ bGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGlu ZyBsaXN0cyAobXBsc0BpZXRmLm9yZykuDQo+DQo+IFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBlbmRzIE9jdG9iZXIgMywgMjAxMi4NCj4NCj4gL0xvYQ0KPiBmb3IgdGhlIG1wbHMgd2cgY28t Y2hhaXJzDQo+DQo+DQo+IC0tDQo+DQo+DQo+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAg ICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQo+IFNyIFN0cmF0ZWd5 IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KPiBFcmljc3NvbiBJ bmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEzDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5 MiAxMyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBt cGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPg0KPiBRdWVzdG8g bWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVu dGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFz aSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9y bWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2 dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0 aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2 ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCj4NCj4gVGhpcyBlLW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2Vt aW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1 dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2Vu ZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0Bp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBt YWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCg0KDQotLSANCkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRp b24gZ28gdG86DQoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVz cy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KDQo= From nurit.sprecher@nsn.com Tue Oct 2 07:58:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2403821F8466 for ; Tue, 2 Oct 2012 07:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g5SdNi05o9L for ; Tue, 2 Oct 2012 07:58:47 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A7A5621F846C for ; Tue, 2 Oct 2012 07:58:46 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q92EwhkX017622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 16:58:43 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q92Ewh8j026773; Tue, 2 Oct 2012 16:58:43 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Oct 2012 16:58:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2012 16:58:42 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2gnhyW0qyCN8KrSN6hhvqD9AMyTwACJebwAAHPtQA= References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Eric Gray" , X-OriginalArrivalTime: 02 Oct 2012 14:58:43.0552 (UTC) FILETIME=[6A85CE00:01CDA0AE] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1306 X-purgate-ID: 151667::1349189923-00003184-442F0872/0-0/0-0 Subject: Re: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:58:48 -0000 Dear Ceng Weiquiang, In order to be able to refer to your comment, can you please indicate which specific requirements in section 2.5.6.1. of RFC 5654 cannot be met and (technically) why do you think so... Best regards, Nurit -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Eric Gray Sent: Tuesday, October 02, 2012 4:04 PM To: mpls@ietf.org Subject: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection Forwarded... -----Original Message----- From: cheng weiqiang [mailto:chengwq@gmail.com]=20 Sent: Tuesday, October 02, 2012 9:02 AM To: mpls-bounces@ietf.org Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Do not support. In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption around the ring. This draft cannot meet the requirement. Best Regards, Cheng Weiqiang Research Institute of China Mobile Department of Network Technology _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From alessandro.dalessandro@telecomitalia.it Tue Oct 2 08:10:32 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D99F21F8570 for ; Tue, 2 Oct 2012 08:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb1JVH2ozjlQ for ; Tue, 2 Oct 2012 08:10:31 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id EB52921F847D for ; Tue, 2 Oct 2012 08:10:30 -0700 (PDT) Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 2 Oct 2012 17:10:27 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by grfhub703rm001.griffon.local ([10.19.9.236]) with mapi; Tue, 2 Oct 2012 17:10:25 +0200 From: D'Alessandro Alessandro Gerardo To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Date: Tue, 2 Oct 2012 17:10:23 +0200 Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: AQHNllRf82qjNdoiA0OJzsZi6RX7kJehLihwgANBJaCAAa+bgIAADqpQ Message-ID: References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:10:32 -0000 RGVhciBOdXJpdCwgDQpUaGVyZSBhcmUgbWFueSBwb2ludHMgd2UgY2FuIGRpc2N1c3MgYWJvdXQg dGhlIHByb3Bvc2VkIGRyYWZ0IGJ1dCBsZXQgbWUgcG9pbnQgb3V0IGluaXRpYWxseSBqdXN0IFIx MDAsIFJGQzU2NTQuDQoNCkJlc3QgcmVnYXJkcywNCkFsZXNzYW5kcm8NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGVs ZWNvbSBJdGFsaWENCkFsZXNzYW5kcm8gR2VyYXJkbyBEJ0FsZXNzYW5kcm8NClRyYW5zcG9ydCBJ bm5vdmF0aW9uDQpWaWEgUmVpc3MgUm9tb2xpLCAyNzQgLSAxMDE0OCBUb3Jpbm8NCnBob25lOsKg ICszOSAwMTEgMjI4IDU4ODcNCm1vYmlsZTogKzM5IDMzNSA3NjYgOTYwNw0KZmF4OiArMzkgMDYg NDE4IDYzOSAwNw0KDQoNCi0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0tDQpEYTogU3ByZWNo ZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pIFttYWlsdG86bnVyaXQuc3ByZWNoZXJA bnNuLmNvbV0gDQpJbnZpYXRvOiBtYXJ0ZWTDrCAyIG90dG9icmUgMjAxMiAxNjowNA0KQTogRCdB bGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbzsgTG9hIEFuZGVyc3Nvbg0KQ2M6IG1wbHNAaWV0 Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBNUExTLVRQIGFkIGhvYyB0ZWFtOyBk cmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnDQpPZ2dldHRv OiBSRTogW21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10 cC1yaW5nLXByb3RlY3Rpb24NCg0KQWxlc3NhbmRybyBhbmQgb3RoZXJzIHRoYXQgc3VwcG9ydGVk IHRoZSBiZWxvdywNCllvdXIgc3RhdGVtZW50IGJlbG93IGRvZXMgbm90IHByb3ZpZGUgYW55IGlu ZGljYXRpb24gbm9yIHRlY2huaWNhbCBqdXN0aWZpY2F0aW9uIHdoaWNoIHJlcXVpcmVtZW50cyBh cmUgbm90IGFkZHJlc3NlZCBhbmQgd2h5IGRvIHlvdSB0aGluayB0aGV5IGFyZSBub3QgYWRkcmVz c2VkLi4uLi4NCkhlbmNlIGl0IGlzIGltcG9zc2libGUgdG8gcmVmZXIgdG8gb3IgY29uc2lkZXIg c3VjaCBMQyBjb21tZW50IGFzIHN1Y2gsIHVubGVzcyB5b3UgcHJvdmlkZSB0ZWNobmljYWwgYXJn dW1lbnRzIHRoYXQgd2UgY2FuIGRpc2N1c3MgYW5kIGNvbnNpZGVyLiANCkJlc3QgcmVnYXJkcywN Ck51cml0DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBEJ0FsZXNz YW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvIFttYWlsdG86YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0 ZWxlY29taXRhbGlhLml0XSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAwMSwgMjAxMiAyOjI3IFBN DQpUbzogTG9hIEFuZGVyc3Nvbg0KQ2M6IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnOyBNUExTLVRQIGFkIGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1w cm90ZWN0aW9uQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSOiBbbXBsc10gV29ya2luZyBncm91 cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQpEbyBu b3Qgc3VwcG9ydA0KDQpBY2NvcmRpbmcgdG8gdGhlIG9wdGltaXphdGlvbiBjcml0ZXJpYSBmb3Ig cmluZyBwcm90ZWN0aW9uIHNwZWNpZmllZCBpbiBTZWN0aW9uIDIuNS42LjEgaW4gUkZDNTY1NCwg dGhlIE1QTFMtVFAgcmluZyBwcm90ZWN0aW9uIHNob3VsZCBiZSBvcHRpbWl6ZWQgZm9yIHNpbXBs aWZpY2F0aW9uIG9mIHRoZSByaW5nIG9wZXJhdGlvbiBhbmQgdGhlIHJlc291cmNlcyBjb25zdW1w dGlvbiBhcm91bmQgdGhlIHJpbmcuIEl0IGlzIG5vdCB0aGUgY2FzZSBvZiB0aGUgcHJvcG9zZWQg c29sdXRpb24uDQpJdCBpcyBhY3R1YWxseSBzaW1wbHkgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1l bnQgb2YgYSBsaW5lYXIgcHJvdGVjdGlvbiBtZWNoYW5pc20gYnV0IGl0IGNhbm5vdCBiZSBjb25z aWRlciBhIHNvbHV0aW9uIHRoYXQgYWRkcmVzc2VzIHRoZSByZXF1aXJlbWVudHMgZm9yIHByb3Rl Y3Rpb24gb2YgcmluZyB0b3BvbG9naWVzIGZvciBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hp bmcgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFApIGFzIHNwZWNpZmllZCBpbiBSRkM1NjU0Lg0K DQpCZXN0IHJlZ2FyZHMsDQpBbGVzc2FuZHJvDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGVsZWNvbSBJdGFsaWEN CkFsZXNzYW5kcm8gR2VyYXJkbyBEJ0FsZXNzYW5kcm8NClRyYW5zcG9ydCBJbm5vdmF0aW9uDQpW aWEgUmVpc3MgUm9tb2xpLCAyNzQgLSAxMDE0OCBUb3Jpbm8NCnBob25lOiAgKzM5IDAxMSAyMjgg NTg4Nw0KbW9iaWxlOiArMzkgMzM1IDc2NiA5NjA3DQpmYXg6ICszOSAwNiA0MTggNjM5IDA3DQoN Cg0KLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCkRhOiBtcGxzLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBIZWppYQ0KSW52 aWF0bzogc2FiYXRvIDI5IHNldHRlbWJyZSAyMDEyIDEyOjUzDQpBOiBMb2EgQW5kZXJzc29uDQpD YzogbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IE1QTFMtVFAgYWQg aG9jIHRlYW07IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5v cmcNCk9nZ2V0dG86IFJlOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQt aWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQpEbyBub3Qgc3VwcG9ydC4NCg0KQmFzZWQg b24gdGhlIGFuYWx5c2lzIGluIFNlY3Rpb24gMi40IG9mIGRyYWZ0LWlldGYtbXBscy10cC1yaW5n LXByb3RlY3Rpb24tMDIsIHRoZSByaW5nIHByb3RlY3Rpb24gc2NoZW1lIHVzaW5nIFNQTUUgYXMg ZGVzY3JpYmVkLCBlaXRoZXIgd3JhcHBpbmcgb3Igc3RlZXJpbmcsIGRvZXMgaGF2ZSBkZWZpY2ll bmNpZXMsIHdoaWNoIElNSE8gc2hvdWxkIGJlIGJldHRlciByZWNvbnNpZGVyZWQgYW5kIHNvbHZl ZCBpZiBwb3NzaWJsZS4NCg0KDQpCLlIuDQpKaWENCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K 5Y+R5Lu25Lq6OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmddIOS7o+ihqCBMb2EgQW5kZXJzc29uDQrlj5HpgIHml7bpl7Q6IDIwMTLlubQ55pyIMTnm l6UgMTg6NDkNCuaKhOmAgTogbXBsc0BpZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJh ZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZzsgbXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmcNCuS4u+mimDogW21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs IG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0KV29ya2luZyBHcm91cCwN Cg0KdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u DQpkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAyLXR4dC4NCg0KUGxlYXNlIG5v dGUgdGhhdCB0aGVyZSBhcmUgdHdvIElQUiBkaXNjbG9zdXJlcyAjIDE0NjIgYW5kICAjIDE4NzIN CnJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudC4NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0 byB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdHMNCihtcGxzQGlldGYub3JnKS4N Cg0KVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgT2N0b2JlciAzLCAyMDEyLg0KDQov TG9hDQpmb3IgdGhlIG1wbHMgd2cgY28tY2hhaXJzDQoNCg0KLS0NCg0KDQpMb2EgQW5kZXJzc29u ICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNv bQ0KU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51 DQpFcmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3 IDUyIDEzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2 IDc2NyA3MiA5MiAxMw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNClF1ZXN0byBtZXNzYWdn aW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxl IHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJh IGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25p IHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVl c3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRh cm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBh bGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBj b3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0 dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQo= From Malcolm.BETTS@zte.com.cn Tue Oct 2 09:47:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B1421F852E; Tue, 2 Oct 2012 09:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.395 X-Spam-Level: X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV9UKjGO9EJ4; Tue, 2 Oct 2012 09:47:01 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC0E21F8533; Tue, 2 Oct 2012 09:47:00 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id B5125125D533; Wed, 3 Oct 2012 00:39:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q92GklLd082507; Wed, 3 Oct 2012 00:46:47 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: References: <5059A308.3050307@pi.nu> To: mpls@ietf.org, mpls-bounces@ietf.org MIME-Version: 1.0 X-KeepSent: 9160CF62:100EA662-85257A8B:005BF2F5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Tue, 2 Oct 2012 12:46:44 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-03 00:46:46, Serialize complete at 2012-10-03 00:46:46 Content-Type: multipart/alternative; boundary="=_alternative 005C2C6B85257A8B_=" X-MAIL: mse01.zte.com.cn q92GklLd082507 Subject: Re: [mpls] FW: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:47:02 -0000 This is a multipart message in MIME format. --=_alternative 005C2C6B85257A8B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBleHBlY3QgdGhhdCB0aGlzIGxpYWlzb24gd2lsbCBiZSBwb3N0ZWQgaW4gdGhlIG5leHQgZmV3 IGRheXMuDQoNCklUVSBtZW1iZXJzIGNhbiBmaW5kIHRoZSBsaWFpc29uIGFzIEFubmV4IEkgb2Yg VEQ3NDQvUExFTi4NCg0KUmVnYXJkcywNCg0KTWFsY29sbQ0KDQoNCg0KDQoiU3ByZWNoZXIsIE51 cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pIiA8bnVyaXQuc3ByZWNoZXJAbnNuLmNvbT4gDQpT ZW50IGJ5OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCjAyLzEwLzIwMTIgMTA6NTEgQU0NCg0KVG8N CjxtcGxzQGlldGYub3JnPg0KY2MNCg0KU3ViamVjdA0KUmU6IFttcGxzXSBGVzogV29ya2luZyBn cm91cCBsYXN0IGNhbGwgb24gDQpkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoN Cg0KDQoNCg0KDQpEaWQgSSBtaXNzIGFueSBsaWFpc29uIG9uIHRoaXM/DQpUbyB3aGF0IGlzc3Vl IGRvIHlvdSByZWZlcj8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIA0KZXh0IEVyaWMgR3JheQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAwMiwgMjAxMiA0OjEw IFBNDQpUbzogbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogW21wbHNdIEZXOiBXb3JraW5nIGdyb3Vw IGxhc3QgY2FsbCBvbiANCmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0KRm9y d2FyZGVkLi4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB5YW5nLmppYW45 MEB6dGUuY29tLmNuIFttYWlsdG86eWFuZy5qaWFuOTBAenRlLmNvbS5jbl0gDQpTZW50OiBTYXR1 cmRheSwgU2VwdGVtYmVyIDI5LCAyMDEyIDU6MTUgQU0NClRvOiBMb2EgQW5kZXJzc29uDQpDYzog TVBMUy1UUCBhZCBob2MgdGVhbTsgDQpkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9u QHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyANCm1wbHMtYm91bmNlc0BpZXRmLm9yZzsg bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6ILTwuLQ6IFttcGxzXSBXb3JraW5n IGdyb3VwIGxhc3QgY2FsbCBvbiANCmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24N Cg0KSGkgQWxsLA0KDQpJIHRoaW5rIHdlIHNob3VsZCBhZGRyZXNzIGFsbCB0aGUgaXNzdWVzIHRo YXQgSVRVIGxpYWlzb24gbWVudGlvbmVkLg0KDQpCUiwNCkppYW4NCg0KDQoNCg0KIA0KICAgICAg ICAgICAgIExvYSBBbmRlcnNzb24gDQogICAgICAgICAgICAgPGxvYUBwaS5udT4gDQogICAgICAg ICAgICAgt6K8/sjLOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIMrVvP7IyyANCg0KICAgICAgICAgICAgIG1wbHMtYm91bmNlc0BpIA0KICAgICAgICAgICAg IGV0Zi5vcmcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ILOty80gDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJtcGxzQGlldGYu b3JnIiA8bXBsc0BpZXRmLm9yZz4sIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTVBMUy1UUCBhZCBob2MgdGVhbSANCiAgICAgICAgICAgICAyMDEyLTA5LTE5ICAgICAgICAg ICAgIDxhaG1wbHMtdHBAbGlzdHMuaXR1LmludD4sIA0KICAgICAgICAgICAgIDE4OjQ4ICAgICAg ICAgICAgICAgICAgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b28gDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxzLmlldGYub3JnLCANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICJtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bXBscy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc+IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgINb3zOIgDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3Rl Y3Rpb24gDQogDQogDQogDQogDQogDQogDQoNCg0KDQoNCldvcmtpbmcgR3JvdXAsDQoNCnRoaXMg aXMgdG8gc3RhcnQgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiANCmRyYWZ0 LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24tMDItdHh0Lg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IHRoZXJlIGFyZSB0d28gSVBSIGRpc2Nsb3N1cmVzICMgMTQ2MiBhbmQgICMgMTg3MiByZWxhdGVk IA0KdG8gdGhpcyBkb2N1bWVudC4NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUg bXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdHMgDQoobXBsc0BpZXRmLm9yZykuDQoNClRo ZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIE9jdG9iZXIgMywgMjAxMi4NCg0KL0xvYQ0K Zm9yIHRoZSBtcGxzIHdnIGNvLWNoYWlycw0KDQoNCi0tDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAg ICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NClNy IFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KRXJp Y3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAx Mw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3Njcg NzIgOTIgMTMgDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQo= --=_alternative 005C2C6B85257A8B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgZXhwZWN0IHRoYXQgdGhpcyBsaWFpc29u IHdpbGwgYmUgcG9zdGVkDQppbiB0aGUgbmV4dCBmZXcgZGF5cy48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklUVSBtZW1iZXJzIGNhbiBmaW5kIHRoZSBs aWFpc29uIGFzDQpBbm5leCBJIG9mIFRENzQ0L1BMRU4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzLDwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TWFsY29sbTwvZm9udD4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtTcHJlY2hlciwgTnVy aXQgKE5TTg0KLSBJTC9Ib2QgSGFTaGFyb24pJnF1b3Q7ICZsdDtudXJpdC5zcHJlY2hlckBuc24u Y29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5T ZW50IGJ5OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MDIvMTAvMjAxMiAxMDo1MSBBTTwvZm9udD4NCjx0ZCB3aWR0aD02MyU+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDttcGxzQGlldGYub3JnJmd0OzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+Y2M8L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN1 YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJl OiBbbXBsc10gRlc6IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsDQpvbiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uPC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5EaWQgSSBtaXNz IGFueSBsaWFpc29uIG9uIHRoaXM/PGJyPg0KVG8gd2hhdCBpc3N1ZSBkbyB5b3UgcmVmZXI/PGJy Pg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcgWzwvZm9udD48L3R0PjxhIGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmciPjx0dD48Zm9udCBzaXplPTI+bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9u dD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPl0NCk9uIEJlaGFsZiBPZiBleHQgRXJpYyBHcmF5 PGJyPg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAwMiwgMjAxMiA0OjEwIFBNPGJyPg0KVG86IG1w bHNAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBbbXBsc10gRlc6IFdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb248YnI+DQo8YnI+DQpGb3J3 YXJkZWQuLi48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IHlhbmcuamlhbjkwQHp0ZS5jb20uY24gWzwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOnlhbmcu amlhbjkwQHp0ZS5jb20uY24+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86eWFuZy5qaWFuOTBAenRl LmNvbS5jbjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPl0NCjxicj4NClNlbnQ6IFNh dHVyZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTIgNToxNSBBTTxicj4NClRvOiBMb2EgQW5kZXJzc29u PGJyPg0KQ2M6IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXBy b3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc7DQptcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0 Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPGJyPg0KU3ViamVjdDogtPC4tDogW21w bHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXBy b3RlY3Rpb248YnI+DQo8YnI+DQpIaSBBbGwsPGJyPg0KPGJyPg0KSSB0aGluayB3ZSBzaG91bGQg YWRkcmVzcyBhbGwgdGhlIGlzc3VlcyB0aGF0IElUVSBsaWFpc29uIG1lbnRpb25lZC48YnI+DQo8 YnI+DQpCUiw8YnI+DQpKaWFuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgTG9hIEFuZGVyc3NvbiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2xvYUBwaS5udSZndDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IDxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyC3orz+yMs6ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDvK1bz+yMsNCjxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBtcGxzLWJvdW5j ZXNAaSAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGV0Zi5v cmcgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDuzrcvNDQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90 Ow0KJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7LCAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+DQogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7TVBMUy1UUCBhZCBob2MgdGVhbQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIwMTItMDktMTkgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDthaG1wbHMtdHBAbGlzdHMuaXR1Lmlu dCZndDssICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMTg6NDggJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJh ZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b28NCjxicj4NCiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDts cy5pZXRmLm9yZywgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgPGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZxdW90O21wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnJnF1b3Q7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A71vfM4iA8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W21w bHNdIFdvcmtpbmcgZ3JvdXANCmxhc3QgY2FsbCBvbiAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQombmJzcDsg Jm5ic3A7IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCldv cmtpbmcgR3JvdXAsPGJyPg0KPGJyPg0KdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtp bmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24t MDItdHh0Ljxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgdGhlcmUgYXJlIHR3byBJUFIgZGlz Y2xvc3VyZXMgIyAxNDYyIGFuZCAmbmJzcDsjIDE4NzINCnJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVu dC48YnI+DQo8YnI+DQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtp bmcgZ3JvdXAgbWFpbGluZyBsaXN0cyAobXBsc0BpZXRmLm9yZykuPGJyPg0KPGJyPg0KVGhlIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgT2N0b2JlciAzLCAyMDEyLjxicj4NCjxicj4NCi9M b2E8YnI+DQpmb3IgdGhlIG1wbHMgd2cgY28tY2hhaXJzPGJyPg0KPGJyPg0KPGJyPg0KLS08YnI+ DQo8YnI+DQo8YnI+DQpMb2EgQW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyBl bWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb208YnI+DQpTciBTdHJhdGVneSBhbmQgU3Rh bmRhcmRzIE1hbmFnZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDts b2FAcGkubnU8YnI+DQpFcmljc3NvbiBJbmMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3Bob25lOiArNDYgMTAgNzE3IDUyIDEzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOys0NiA3NjcgNzIgOTIgMTMgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxi cj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscz48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg c2l6ZT0yPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzQGlldGYub3JnPGJyPg0K PC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHM+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHM8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBs aXN0PGJyPg0KbXBsc0BpZXRmLm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9mb250PjwvdHQ+PC9hPjx0dD48 Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 005C2C6B85257A8B_=-- From Malcolm.BETTS@zte.com.cn Tue Oct 2 09:51:58 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C59921F853B for ; Tue, 2 Oct 2012 09:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.496 X-Spam-Level: X-Spam-Status: No, score=-100.496 tagged_above=-999 required=5 tests=[AWL=2.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3cVjX2pht3Y for ; Tue, 2 Oct 2012 09:51:57 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2427721F84FE for ; Tue, 2 Oct 2012 09:51:57 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 34629125D5CA for ; Wed, 3 Oct 2012 00:44:42 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id C407F5F78F1 for ; Wed, 3 Oct 2012 00:48:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q92GpdaI001831 for ; Wed, 3 Oct 2012 00:51:39 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <5059A308.3050307@pi.nu> References: <5059A308.3050307@pi.nu> To: "mpls@ietf.org" MIME-Version: 1.0 X-KeepSent: 574FF3AC:EB6D4499-85257A8B:005C7F8D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Tue, 2 Oct 2012 12:51:38 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-03 00:51:40, Serialize complete at 2012-10-03 00:51:40 Content-Type: multipart/alternative; boundary="=_alternative 005C9F4985257A8B_=" X-MAIL: mse02.zte.com.cn q92GpdaI001831 Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:51:58 -0000 This is a multipart message in MIME format. --=_alternative 005C9F4985257A8B_= Content-Type: text/plain; charset="US-ASCII" Do not support. All of the issues identified in the liaison statement from the September 2012 meeting of SG15 must be addressed. Regards, Malcolm Loa Andersson Sent by: mpls-bounces@ietf.org 19/09/2012 06:48 AM To cc "mpls@ietf.org" , MPLS-TP ad hoc team , draft-ietf-mpls-tp-ring-protection@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-ring-protection-02-txt. Please note that there are two IPR disclosures # 1462 and # 1872 related to this document. Please send your comments to the mpls working group mailing lists (mpls@ietf.org). The working group last call ends October 3, 2012. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=_alternative 005C9F4985257A8B_= Content-Type: text/html; charset="US-ASCII" Do not support.

All of the issues identified in the liaison statement from the September 2012 meeting of SG15 must be addressed.

Regards,

Malcolm



Loa Andersson <loa@pi.nu>
Sent by: mpls-bounces@ietf.org

19/09/2012 06:48 AM

To
cc
"mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-ring-protection@tools.ietf.org, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject
[mpls] Working group last call on draft-ietf-mpls-tp-ring-protection





Working Group,

this is to start a two week working group last call on
draft-ietf-mpls-tp-ring-protection-02-txt.

Please note that there are two IPR disclosures # 1462 and  # 1872
related to this document.

Please send your comments to the mpls working group mailing lists
(mpls@ietf.org).

The working group last call ends October 3, 2012.

/Loa
for the mpls wg co-chairs


--


Loa Andersson                         email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                             +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--=_alternative 005C9F4985257A8B_=-- From stbryant@cisco.com Tue Oct 2 10:11:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD8E21F8543 for ; Tue, 2 Oct 2012 10:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.616 X-Spam-Level: X-Spam-Status: No, score=-110.616 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0HDQgc+IHYy for ; Tue, 2 Oct 2012 10:11:25 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 66BA421F853B for ; Tue, 2 Oct 2012 10:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15633; q=dns/txt; s=iport; t=1349197884; x=1350407484; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=iYhYE8MsM1ICE5pXFKKuVNgKhkN/eXrCC4Z+5/sv8Po=; b=hMN2BfZxRt/dm01ImIUIh0o85tauOltYgd2ODe+RqkUEl/+37ZsYmfGD DgcnQyA1MxdbRyLgX1c2wdWJmucyuqw+Qo7cQC5zdtZF0FWYUiGG7KuBt PrxdK0l8RPbr8huVFhO5upNCcGgemvz7FrR/OnCr/qMbxv3dwOXwNG3Ej s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAOgea1CQ/khL/2dsb2JhbABCA4YLhV+yb4EIgiABAQEEAQEBDwECDksKAQwCAgkCEQQBAQEJFggDAgIJAwIBAgEJDB8JCAYNAQUCAQEXB4djC5h9g0oQiUGCO5BdBIsfGoJ7ghOBEgOVaY5CgQZjgmiBYg X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208,217";a="77134289" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 02 Oct 2012 17:11:22 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q92HBMEA004436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 17:11:22 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q92HBItC018639; Tue, 2 Oct 2012 18:11:19 +0100 (BST) Message-ID: <506B2036.3040508@cisco.com> Date: Tue, 02 Oct 2012 18:11:18 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "D'Alessandro Alessandro Gerardo" References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070301010709000001030209" Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] [AHMPLS-TP] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:11:26 -0000 This is a multi-part message in MIME format. --------------070301010709000001030209 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit The text in 100 says: "100 Recovery techniques in a ring SHOULD be identical (or as similar as possible) to those in general transport networks to simplify implementation and operations. However, this MUST NOT override any other requirement." The MUST is that all other requirements MUST be met, and the SHOULD is that the solution SHOULD be those in general transport networks, which is actually is not a ring specific statement. Indeed by reusing the mesh approach (RFC6378) we comply with that requirement since the mesh solution are by definition "identical to those in general transport networks". A more productive review approach might be to point to an IETF draft that proposes an alternative solution and provide a point by point evaluation of how well each solution addresses the numbered requirements 92..109. Stewart (as an individual contributor) On 02/10/2012 16:10, D'Alessandro Alessandro Gerardo wrote: > Dear Nurit, > There are many points we can discuss about the proposed draft but let me point out initially just R100, RFC5654. > > Best regards, > Alessandro > ------------------------------------------------------------------ > Telecom Italia > Alessandro Gerardo D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 > > > -----Messaggio originale----- > Da: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com] > Inviato: martedì 2 ottobre 2012 16:04 > A: D'Alessandro Alessandro Gerardo; Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Oggetto: RE: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Alessandro and others that supported the below, > Your statement below does not provide any indication nor technical justification which requirements are not addressed and why do you think they are not addressed..... > Hence it is impossible to refer to or consider such LC comment as such, unless you provide technical arguments that we can discuss and consider. > Best regards, > Nurit > > > -----Original Message----- > From: ext D'Alessandro Alessandro Gerardo [mailto:alessandro.dalessandro@telecomitalia.it] > Sent: Monday, October 01, 2012 2:27 PM > To: Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Subject: R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Do not support > > According to the optimization criteria for ring protection specified in Section 2.5.6.1 in RFC5654, the MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption around the ring. It is not the case of the proposed solution. > It is actually simply an applicability statement of a linear protection mechanism but it cannot be consider a solution that addresses the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) as specified in RFC5654. > > Best regards, > Alessandro > > ------------------------------------------------------------------ > Telecom Italia > Alessandro Gerardo D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 > > > -----Messaggio originale----- > Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Hejia > Inviato: sabato 29 settembre 2012 12:53 > A: Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Do not support. > > Based on the analysis in Section 2.4 of draft-ietf-mpls-tp-ring-protection-02, the ring protection scheme using SPME as described, either wrapping or steering, does have deficiencies, which IMHO should be better reconsidered and solved if possible. > > > B.R. > Jia > > -----邮件原件----- > å‘件人: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] 代表 Loa Andersson > å‘é€æ—¶é—´: 2012å¹´9月19æ—¥ 18:49 > 抄é€: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.ietf.org > 主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 > related to this document. > > Please send your comments to the mpls working group mailing lists > (mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------070301010709000001030209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
The text in 100 says:

"100  Recovery techniques in a ring SHOULD be identical (or as similar
      as possible) to those in general transport networks to simplify
      implementation and operations.  However, this MUST NOT override
      any other requirement."

The MUST is that all other requirements MUST be met, and the SHOULD
is that the solution SHOULD be those in general transport networks, 
which is actually is not a ring specific statement. Indeed by 
reusing the mesh approach (RFC6378) we comply with that requirement 
since the mesh solution are by definition "identical to those in 
general transport networks".

A more productive review approach might be to point to an IETF 
draft that proposes an alternative solution and provide a point
by point evaluation of how well each solution addresses the numbered
requirements 92..109.

Stewart (as an individual contributor)


On 02/10/2012 16:10, D'Alessandro Alessandro Gerardo wrote:
Dear Nurit, 
There are many points we can discuss about the proposed draft but let me point out initially just R100, RFC5654.

Best regards,
Alessandro
------------------------------------------------------------------
Telecom Italia
Alessandro Gerardo D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07


-----Messaggio originale-----
Da: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com] 
Inviato: martedì 2 ottobre 2012 16:04
A: D'Alessandro Alessandro Gerardo; Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org
Oggetto: RE: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Alessandro and others that supported the below,
Your statement below does not provide any indication nor technical justification which requirements are not addressed and why do you think they are not addressed.....
Hence it is impossible to refer to or consider such LC comment as such, unless you provide technical arguments that we can discuss and consider. 
Best regards,
Nurit


-----Original Message-----
From: ext D'Alessandro Alessandro Gerardo [mailto:alessandro.dalessandro@telecomitalia.it] 
Sent: Monday, October 01, 2012 2:27 PM
To: Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org
Subject: R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support

According to the optimization criteria for ring protection specified in Section 2.5.6.1 in RFC5654, the MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption around the ring. It is not the case of the proposed solution.
It is actually simply an applicability statement of a linear protection mechanism but it cannot be consider a solution that addresses the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) as specified in RFC5654.

Best regards,
Alessandro

------------------------------------------------------------------
Telecom Italia
Alessandro Gerardo D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07


-----Messaggio originale-----
Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org
Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Do not support.

Based on the analysis in Section 2.4 of draft-ietf-mpls-tp-ring-protection-02, the ring protection scheme using SPME as described, either wrapping or steering, does have deficiencies, which IMHO should be better reconsidered and solved if possible.


B.R.
Jia

-----邮件原件-----
å‘件人: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] 代表 Loa Andersson
å‘é€æ—¶é—´: 2012å¹´9月19æ—¥ 18:49
抄é€: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.ietf.org
主题: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

this is to start a two week working group last call on
draft-ietf-mpls-tp-ring-protection-02-txt.

Please note that there are two IPR disclosures # 1462 and  # 1872
related to this document.

Please send your comments to the mpls working group mailing lists
(mpls@ietf.org).

The working group last call ends October 3, 2012.

/Loa
for the mpls wg co-chairs


--


Loa Andersson                         email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.


.




-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------070301010709000001030209-- From nurit.sprecher@nsn.com Tue Oct 2 10:12:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800B521F8543 for ; Tue, 2 Oct 2012 10:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTi95uVO14S6 for ; Tue, 2 Oct 2012 10:12:23 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5621F853B for ; Tue, 2 Oct 2012 10:12:22 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q92HCJDt023762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 19:12:19 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q92HCJDM027062; Tue, 2 Oct 2012 19:12:19 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Oct 2012 19:12:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 2 Oct 2012 19:12:17 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: AQHNllRf82qjNdoiA0OJzsZi6RX7kJehLihwgANBJaCAAa+bgIAADqpQgAAl8oA= References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext D'Alessandro Alessandro Gerardo" X-OriginalArrivalTime: 02 Oct 2012 17:12:19.0101 (UTC) FILETIME=[142984D0:01CDA0C1] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8450 X-purgate-ID: 151667::1349197939-00003184-E26DEE00/0-0/0-0 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, MPLS-TP ad hoc team , draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:12:24 -0000 RGVhciBBbGVzYW5kcm8sDQpUaGFuayB5b3UgZm9yIHBvaW50aW5nIHRvIFIuMTAwICgiUmVjb3Zl cnkgdGVjaG5pcXVlcyBpbiBhIHJpbmcgU0hPVUxEIGJlIGlkZW50aWNhbCAob3IgYXMgc2ltaWxh cg0KICAgICAgICBhcyBwb3NzaWJsZSkgdG8gdGhvc2UgaW4gZ2VuZXJhbCB0cmFuc3BvcnQgbmV0 d29ya3MgdG8gc2ltcGxpZnkNCiAgICAgICAgaW1wbGVtZW50YXRpb24gYW5kIG9wZXJhdGlvbnMu ICBIb3dldmVyLCB0aGlzIE1VU1QgTk9UIG92ZXJyaWRlDQogICAgICAgIGFueSBvdGhlciByZXF1 aXJlbWVudC4iKS4gDQpkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uIHN1cHBvcnRz IHRoZSB0d28gcHJvdGVjdGlvbiBhcmNoaXRlY3R1cmUgbWVjaGFuaXNtcyBmb3IgcmluZyB0b3Bv bG9naWVzLCBiYXNlZCBvbiBTREggc3BlY2lmaWNhdGlvbnMgW0cuODQxXSwgdGhhdCBoYXZlIGJl ZW4gcHJvcG9zZWQgaW4gdmFyaW91cyBmb3J1bXMgdG8gcGVyZm9ybSByZWNvdmVyeSBvZiBhIHRv cG9sb2dpY2FsIHJpbmcgbmV0d29yayAtICJ3cmFwcGluZyIgYW5kICJzdGVlcmluZyIuIA0KU28g aXQgd2lsbCBiZSBnb29kIHRvIHVuZGVyc3RhbmQgYmV0dGVyIHlvdXIgdGVjaG5pY2FsIGNvbmNl cm4gb24gUjEwMC4gDQpCZXN0IHJlZ2FyZHMsDQpOdXJpdA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBleHQgRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbyBbbWFp bHRvOmFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdF0gDQpTZW50OiBUdWVz ZGF5LCBPY3RvYmVyIDAyLCAyMDEyIDU6MTAgUE0NClRvOiBTcHJlY2hlciwgTnVyaXQgKE5TTiAt IElML0hvZCBIYVNoYXJvbikNCkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJv dGVjdGlvbkB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUjogW21wbHNdIFdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0KRGVhciBO dXJpdCwgDQpUaGVyZSBhcmUgbWFueSBwb2ludHMgd2UgY2FuIGRpc2N1c3MgYWJvdXQgdGhlIHBy b3Bvc2VkIGRyYWZ0IGJ1dCBsZXQgbWUgcG9pbnQgb3V0IGluaXRpYWxseSBqdXN0IFIxMDAsIFJG QzU2NTQuDQoNCkJlc3QgcmVnYXJkcywNCkFsZXNzYW5kcm8NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGVsZWNvbSBJ dGFsaWENCkFsZXNzYW5kcm8gR2VyYXJkbyBEJ0FsZXNzYW5kcm8NClRyYW5zcG9ydCBJbm5vdmF0 aW9uDQpWaWEgUmVpc3MgUm9tb2xpLCAyNzQgLSAxMDE0OCBUb3Jpbm8NCnBob25lOsKgICszOSAw MTEgMjI4IDU4ODcNCm1vYmlsZTogKzM5IDMzNSA3NjYgOTYwNw0KZmF4OiArMzkgMDYgNDE4IDYz OSAwNw0KDQoNCi0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0tDQpEYTogU3ByZWNoZXIsIE51 cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pIFttYWlsdG86bnVyaXQuc3ByZWNoZXJAbnNuLmNv bV0gDQpJbnZpYXRvOiBtYXJ0ZWTDrCAyIG90dG9icmUgMjAxMiAxNjowNA0KQTogRCdBbGVzc2Fu ZHJvIEFsZXNzYW5kcm8gR2VyYXJkbzsgTG9hIEFuZGVyc3Nvbg0KQ2M6IG1wbHNAaWV0Zi5vcmc7 IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBNUExTLVRQIGFkIGhvYyB0ZWFtOyBkcmFmdC1p ZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnDQpPZ2dldHRvOiBSRTog W21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5n LXByb3RlY3Rpb24NCg0KQWxlc3NhbmRybyBhbmQgb3RoZXJzIHRoYXQgc3VwcG9ydGVkIHRoZSBi ZWxvdywNCllvdXIgc3RhdGVtZW50IGJlbG93IGRvZXMgbm90IHByb3ZpZGUgYW55IGluZGljYXRp b24gbm9yIHRlY2huaWNhbCBqdXN0aWZpY2F0aW9uIHdoaWNoIHJlcXVpcmVtZW50cyBhcmUgbm90 IGFkZHJlc3NlZCBhbmQgd2h5IGRvIHlvdSB0aGluayB0aGV5IGFyZSBub3QgYWRkcmVzc2VkLi4u Li4NCkhlbmNlIGl0IGlzIGltcG9zc2libGUgdG8gcmVmZXIgdG8gb3IgY29uc2lkZXIgc3VjaCBM QyBjb21tZW50IGFzIHN1Y2gsIHVubGVzcyB5b3UgcHJvdmlkZSB0ZWNobmljYWwgYXJndW1lbnRz IHRoYXQgd2UgY2FuIGRpc2N1c3MgYW5kIGNvbnNpZGVyLiANCkJlc3QgcmVnYXJkcywNCk51cml0 DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBEJ0FsZXNzYW5kcm8g QWxlc3NhbmRybyBHZXJhcmRvIFttYWlsdG86YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29t aXRhbGlhLml0XSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAwMSwgMjAxMiAyOjI3IFBNDQpUbzog TG9hIEFuZGVyc3Nvbg0KQ2M6IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnOyBNUExTLVRQIGFkIGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0 aW9uQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0 IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQpEbyBub3Qgc3Vw cG9ydA0KDQpBY2NvcmRpbmcgdG8gdGhlIG9wdGltaXphdGlvbiBjcml0ZXJpYSBmb3IgcmluZyBw cm90ZWN0aW9uIHNwZWNpZmllZCBpbiBTZWN0aW9uIDIuNS42LjEgaW4gUkZDNTY1NCwgdGhlIE1Q TFMtVFAgcmluZyBwcm90ZWN0aW9uIHNob3VsZCBiZSBvcHRpbWl6ZWQgZm9yIHNpbXBsaWZpY2F0 aW9uIG9mIHRoZSByaW5nIG9wZXJhdGlvbiBhbmQgdGhlIHJlc291cmNlcyBjb25zdW1wdGlvbiBh cm91bmQgdGhlIHJpbmcuIEl0IGlzIG5vdCB0aGUgY2FzZSBvZiB0aGUgcHJvcG9zZWQgc29sdXRp b24uDQpJdCBpcyBhY3R1YWxseSBzaW1wbHkgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgb2Yg YSBsaW5lYXIgcHJvdGVjdGlvbiBtZWNoYW5pc20gYnV0IGl0IGNhbm5vdCBiZSBjb25zaWRlciBh IHNvbHV0aW9uIHRoYXQgYWRkcmVzc2VzIHRoZSByZXF1aXJlbWVudHMgZm9yIHByb3RlY3Rpb24g b2YgcmluZyB0b3BvbG9naWVzIGZvciBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgVHJh bnNwb3J0IFByb2ZpbGUgKE1QTFMtVFApIGFzIHNwZWNpZmllZCBpbiBSRkM1NjU0Lg0KDQpCZXN0 IHJlZ2FyZHMsDQpBbGVzc2FuZHJvDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGVsZWNvbSBJdGFsaWENCkFsZXNz YW5kcm8gR2VyYXJkbyBEJ0FsZXNzYW5kcm8NClRyYW5zcG9ydCBJbm5vdmF0aW9uDQpWaWEgUmVp c3MgUm9tb2xpLCAyNzQgLSAxMDE0OCBUb3Jpbm8NCnBob25lOiAgKzM5IDAxMSAyMjggNTg4Nw0K bW9iaWxlOiArMzkgMzM1IDc2NiA5NjA3DQpmYXg6ICszOSAwNiA0MTggNjM5IDA3DQoNCg0KLS0t LS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCkRhOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBIZWppYQ0KSW52aWF0bzog c2FiYXRvIDI5IHNldHRlbWJyZSAyMDEyIDEyOjUzDQpBOiBMb2EgQW5kZXJzc29uDQpDYzogbXBs c0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IE1QTFMtVFAgYWQgaG9jIHRl YW07IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcNCk9n Z2V0dG86IFJlOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1t cGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQpEbyBub3Qgc3VwcG9ydC4NCg0KQmFzZWQgb24gdGhl IGFuYWx5c2lzIGluIFNlY3Rpb24gMi40IG9mIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3Rl Y3Rpb24tMDIsIHRoZSByaW5nIHByb3RlY3Rpb24gc2NoZW1lIHVzaW5nIFNQTUUgYXMgZGVzY3Jp YmVkLCBlaXRoZXIgd3JhcHBpbmcgb3Igc3RlZXJpbmcsIGRvZXMgaGF2ZSBkZWZpY2llbmNpZXMs IHdoaWNoIElNSE8gc2hvdWxkIGJlIGJldHRlciByZWNvbnNpZGVyZWQgYW5kIHNvbHZlZCBpZiBw b3NzaWJsZS4NCg0KDQpCLlIuDQpKaWENCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu2 5Lq6OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmdd IOS7o+ihqCBMb2EgQW5kZXJzc29uDQrlj5HpgIHml7bpl7Q6IDIwMTLlubQ55pyIMTnml6UgMTg6 NDkNCuaKhOmAgTogbXBsc0BpZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0 Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmcNCuS4u+mimDogW21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRy YWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0KV29ya2luZyBHcm91cCwNCg0KdGhp cyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQpkcmFm dC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAyLXR4dC4NCg0KUGxlYXNlIG5vdGUgdGhh dCB0aGVyZSBhcmUgdHdvIElQUiBkaXNjbG9zdXJlcyAjIDE0NjIgYW5kICAjIDE4NzINCnJlbGF0 ZWQgdG8gdGhpcyBkb2N1bWVudC4NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUg bXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdHMNCihtcGxzQGlldGYub3JnKS4NCg0KVGhl IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgT2N0b2JlciAzLCAyMDEyLg0KDQovTG9hDQpm b3IgdGhlIG1wbHMgd2cgY28tY2hhaXJzDQoNCg0KLS0NCg0KDQpMb2EgQW5kZXJzc29uICAgICAg ICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KU3Ig U3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51DQpFcmlj c3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEz DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3 MiA5MiAxMw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBp IHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNv bmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9u ZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8g cmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRv Y3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGlt bWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1 YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBp bnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5n LCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUt bWFpbCwgVGhhbmtzLg0KDQo= From nurit.sprecher@nsn.com Tue Oct 2 10:13:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0256221F8480; Tue, 2 Oct 2012 10:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.169 X-Spam-Level: X-Spam-Status: No, score=-5.169 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjLX3LzSNsk5; Tue, 2 Oct 2012 10:13:46 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 31BB221F8466; Tue, 2 Oct 2012 10:13:45 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q92HDhnb025671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 19:13:43 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q92HDhDJ005842; Tue, 2 Oct 2012 19:13:43 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Oct 2012 19:13:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA0C1.464C75F1" Date: Tue, 2 Oct 2012 19:13:42 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] FW: Working group last callon draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2gvZYjtV8yD3jlStGX4+AodnfPQwAA5iPg References: <5059A308.3050307@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , , X-OriginalArrivalTime: 02 Oct 2012 17:13:43.0428 (UTC) FILETIME=[466CCC40:01CDA0C1] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 49099 X-purgate-ID: 151667::1349198023-00003184-6977A9FB/0-0/0-0 Subject: Re: [mpls] FW: Working group last callon draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:13:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDA0C1.464C75F1 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Thank you Malcolm! Obviously it is impossible to consider something that was not posted.=20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Malcolm.BETTS@zte.com.cn Sent: Tuesday, October 02, 2012 6:47 PM To: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] FW: Working group last callon = draft-ietf-mpls-tp-ring-protection =20 I expect that this liaison will be posted in the next few days.=20 ITU members can find the liaison as Annex I of TD744/PLEN.=20 Regards,=20 Malcolm=20 "Sprecher, Nurit (NSN - IL/Hod HaSharon)" =20 Sent by: mpls-bounces@ietf.org=20 02/10/2012 10:51 AM=20 To =20 cc =09 Subject Re: [mpls] FW: Working group last call on = draft-ietf-mpls-tp-ring-protection =20 =09 Did I miss any liaison on this? To what issue do you refer? -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org = ] On Behalf Of ext Eric Gray Sent: Tuesday, October 02, 2012 4:10 PM To: mpls@ietf.org Subject: [mpls] FW: Working group last call on = draft-ietf-mpls-tp-ring-protection Forwarded... -----Original Message----- From: yang.jian90@zte.com.cn [mailto:yang.jian90@zte.com.cn = ]=20 Sent: Saturday, September 29, 2012 5:15 AM To: Loa Andersson Cc: MPLS-TP ad hoc team; = draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls@ietf.org; = mpls-bounces@ietf.org; mpls-chairs@tools.ietf.org Subject: =B4=F0=B8=B4: [mpls] Working group last call on = draft-ietf-mpls-tp-ring-protection Hi All, I think we should address all the issues that ITU liaison mentioned. BR, Jian = =20 Loa Andersson = =20 = =20 =B7=A2=BC=FE=C8=CB: = =CA=D5=BC=FE=C8=CB=20 mpls-bounces@i = =20 etf.org = =B3=AD=CB=CD=20 "mpls@ietf.org" , = =20 MPLS-TP ad hoc team = =20 2012-09-19 , = =20 18:48 = draft-ietf-mpls-tp-ring-protection@too=20 ls.ietf.org, = =20 "mpls-chairs@tools.ietf.org" = =20 = =20 = =D6=F7=CC=E2=20 [mpls] Working group last call on = =20 draft-ietf-mpls-tp-ring-protection = =20 = =20 = =20 = =20 = =20 = =20 = =20 Working Group, this is to start a two week working group last call on = draft-ietf-mpls-tp-ring-protection-02-txt. Please note that there are two IPR disclosures # 1462 and # 1872 = related to this document. Please send your comments to the mpls working group mailing lists = (mpls@ietf.org). The working group last call ends October 3, 2012. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 = _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls = =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls = =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls = =20 ------_=_NextPart_001_01CDA0C1.464C75F1 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thank you = Malcolm!

Obviously = it is impossible to consider something that was not posted. =

 =

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Malcolm.BETTS@zte.com.cn
Sent: Tuesday, October 02, = 2012 6:47 PM
To: mpls@ietf.org; = mpls-bounces@ietf.org
Subject: Re: [mpls] FW: Working group = last callon = draft-ietf-mpls-tp-ring-protection

 

I expect = that this liaison will be posted in the next few days. =

ITU members = can find the liaison as Annex I of TD744/PLEN.

Regards,

Malcolm


"Sprecher= , Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com> =
Sent by: mpls-bounces@ietf.org =

02/10/2012 = 10:51 AM

<= /table>

 

To=

<mpls@ietf.org> =

cc=

Subject=

Re: [mpls] = FW: Working group last call on       =  draft-ietf-mpls-tp-ring-protection




Did I miss any liaison on = this?
To what = issue do you refer?

-----Origin= al Message-----
From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On Behalf Of ext Eric = Gray
Sent: = Tuesday, October 02, 2012 4:10 PM
To: mpls@ietf.org
Subject: = [mpls] FW: Working group last call on = draft-ietf-mpls-tp-ring-protection

Forwarded..= .

-----Origin= al Message-----
From: yang.jian90@zte.com.cn = [mailto:yang.jian90@zte.com.cn<= tt>]
Sent: = Saturday, September 29, 2012 5:15 AM
To: Loa = Andersson
Cc: = MPLS-TP ad hoc team; draft-i= etf-mpls-tp-ring-protection@tools.ietf.org; mpls@ietf.org; mpls-bounces@ietf.org; mpls-chairs@tools.ietf.org=
Subject: = =B4=F0=B8=B4: [mpls] Working group last call = on draft-ietf-mpls-tp-ring-protection

Hi = All,

I think we = should address all the issues that ITU liaison = mentioned.

BR,<= /tt>
Jian=




  =                     =                     =                     =            
  =           Loa Andersson       =                     =                     =  
  =           <loa@pi.nu>         =                     =                     =  
  =           =B7=A2=BC=FE=C8=CB:         =                     =                   =  =CA=D5=BC=FE=C8=CB =
  =           mpls-bounces@i       =                     =                     =  
  =           etf.org         =                     =                     =  =B3=AD=CB=CD
  =                     =              "mpls@ietf.org" <mpls@ietf.org>,     =  
  =                     =              MPLS-TP ad hoc team =                   =  
  =           2012-09-19       =       <ahmpls-tp@lists.itu.int>, =            
  =           18:48         =          draft-ietf-mpls-tp-ring-protection@too =
  =                     =              ls.ietf.org,   =                     =    
  =                     =              "mpls-chairs@tools.ietf.org= "          
  =                     =              <mpls-chairs@tools.ietf.org= >          
  =                     =                     =                     =        =D6=F7=CC=E2 =
  =                     =              [mpls] Working group = last call on      
  =                     =             =  draft-ietf-mpls-tp-ring-protection     =
  =                     =                     =                     =            
  =                     =                     =                     =            
  =                     =                     =                     =            
  =                     =                     =                     =            
  =                     =                     =                     =            
  =                     =                     =                     =             =




Working = Group,

this is to = start a two week working group last call on = draft-ietf-mpls-tp-ring-protection-02-txt.

Please = note that there are two IPR disclosures # 1462 and  # 1872 related = to this document.

Please = send your comments to the mpls working group mailing lists (mpls@ietf.org).

= The = working group last call ends October 3, = 2012.

/Loa=
for the = mpls wg co-chairs


--


Loa = Andersson                   =       email: loa.andersson@ericsson.com=
Sr = Strategy and Standards Manager           =  loa@pi.nu
Ericsson = Inc                   =        phone: +46 10 717 52 = 13
  =                     =                     =    +46 767 72 92 13 = _______________________________________________
mpls = mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

___________= ____________________________________
mpls = mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
___________= ____________________________________
mpls = mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

------_=_NextPart_001_01CDA0C1.464C75F1-- From stbryant@cisco.com Tue Oct 2 10:18:09 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDD321F8498 for ; Tue, 2 Oct 2012 10:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.615 X-Spam-Level: X-Spam-Status: No, score=-110.615 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KG58kojMZyUZ for ; Tue, 2 Oct 2012 10:18:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6019721F8480 for ; Tue, 2 Oct 2012 10:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9440; q=dns/txt; s=iport; t=1349198288; x=1350407888; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=isp9jnSRN4QKKvwAZKmy1Wpbtop+Y8x87KiWzyPVv/g=; b=CzTuwuc/s9DUzggxh8efGRHRn9Z8lhg7dgH2e1o0ADwpVk3igZK06FLp znu1GiwfrM5CSfHK5cuZBCZWJ3CThHeL1h1Sxuu5UNok6bJKnlOCO2jII 8fBMHekzrd9HBs4mMDq9XGgZzHw9vul9U0pQNZjpqkNlbKemlsjBYKe0Z c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAEYha1CQ/khN/2dsb2JhbABFi2qyb4EIgiABAQEEAQEBDwECWQoPAgsYCRYPCQMCAQIBCQwBLxMGAgEBHodjC5kDg0oQi3yQXASLH4Y6A5M8gi2OQoEGY4JogWI X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208,217";a="77134513" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 02 Oct 2012 17:18:07 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q92HI7ON008910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Oct 2012 17:18:07 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q92HI56k019001; Tue, 2 Oct 2012 18:18:05 +0100 (BST) Message-ID: <506B21CC.9000403@cisco.com> Date: Tue, 02 Oct 2012 18:18:04 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mpls@ietf.org References: <5059A308.3050307@pi.nu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050405070401040204020907" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:18:09 -0000 This is a multi-part message in MIME format. --------------050405070401040204020907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Malcolm There is no liaison statement posted, so that we can have a productive discussion, please can you cut and paste the substantive text and send it as an email to this list. Stewart (as an individual contributor) On 02/10/2012 17:51, Malcolm.BETTS@zte.com.cn wrote: > Do not support. > > All of the issues identified in the liaison statement from the > September 2012 meeting of SG15 must be addressed. > > Regards, > > Malcolm > > > > *Loa Andersson * > Sent by: mpls-bounces@ietf.org > > 19/09/2012 06:48 AM > > > To > > cc > "mpls@ietf.org" , MPLS-TP ad hoc team > , > draft-ietf-mpls-tp-ring-protection@tools.ietf.org, > "mpls-chairs@tools.ietf.org" > Subject > [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > > > > > > > > > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 > related to this document. > > Please send your comments to the mpls working group mailing lists > (mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------050405070401040204020907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Malcolm

There is no liaison statement posted, so that we can have a productive discussion, please can you cut and paste the substantive text and send it as an email to this list.

Stewart (as an individual contributor)


On 02/10/2012 17:51, Malcolm.BETTS@zte.com.cn wrote:
Do not support.

All of the issues identified in the liaison statement from the September 2012 meeting of SG15 must be addressed.

Regards,

Malcolm



Loa Andersson <loa@pi.nu>
Sent by: mpls-bounces@ietf.org

19/09/2012 06:48 AM

To
cc
 "mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-ring-protection@tools.ietf.org, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject
 [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection







Working Group,

this is to start a two week working group last call on
draft-ietf-mpls-tp-ring-protection-02-txt.

Please note that there are two IPR disclosures # 1462 and  # 1872
related to this document.

Please send your comments to the mpls working group mailing lists
(mpls@ietf.org).

The working group last call ends October 3, 2012.

/Loa
for the mpls wg co-chairs


--


Loa Andersson                         email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                             +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

 


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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------050405070401040204020907-- From rcallon@juniper.net Tue Oct 2 10:52:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB7A21F855A for ; Tue, 2 Oct 2012 10:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.446 X-Spam-Level: X-Spam-Status: No, score=-106.446 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+6jBfYFuVu1 for ; Tue, 2 Oct 2012 10:52:37 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFFA21F8559 for ; Tue, 2 Oct 2012 10:52:33 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUGsp3Fyqji5yyIXZ1Q4hcXDMYJbQGRg6@postini.com; Tue, 02 Oct 2012 10:52:37 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Oct 2012 10:51:40 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 2 Oct 2012 10:51:40 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 2 Oct 2012 13:51:38 -0400 From: Ross Callon To: Markus Jork , "lizhong.jin@zte.com.cn" , "Thomas.Beckhaus@telekom.de" , "mpls@ietf.org" , "Eric (erosen) Rosen" Date: Tue, 2 Oct 2012 13:51:36 -0400 Thread-Topic: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03 Thread-Index: Ac1kZhp9XIdWunBHSdKPU4kWq0pFlg8SLf4w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C7EC7BDF1BEMBX01WFjnprn_" MIME-Version: 1.0 Cc: Giles Heron , Ross Callon Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:52:39 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C7EC7BDF1BEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For the three MPLS-RT reviewers of draft-pdutta-mpls-tldp-hello-reduce, and= for anyone on the MPLS email list who has commented on this draft, can you= check the update and see whether the recent update of the draft (draft-pdu= tta-mpls-tldp-hello-reduce-04, posted September 1) addresses your issues? Thanks, Ross _____________________________________________ From: Ross Callon Sent: Tuesday, July 17, 2012 5:50 PM To: Markus Jork; lizhong.jin@zte.com.cn; Thomas.Beckhaus@telekom.de Cc: loa@pi.nu; swallow@cisco.com; Ross Callon; Martin Vigoureux; Dutta, Pra= njal K (Pranjal); Giles Heron; Thomas Nadeau Subject: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03 Markus, Lizhong, Thomas; You have been selected as an MPLS Review team reviewers for draft-pdutta-mpls-tldp-hello-reduce-03 Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. Are you able to review this draft by August 3, 2012 (ie, the end of the IET= F meeting in Vancouver)? We understand that this is somewhat short notice and that you might have something else to do the week of the IETF, so let us know if you need slightly more time. Thanks, Ross (as MPLS WG chair) PS: I noticed that Tom Nadeau's email address listed in the draft is out of= date. This email is being CC'd to his updated address. --_000_DF7F294AF4153D498141CBEFADB17704C7EC7BDF1BEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
For the three MPLS-RT reviewers of draft-pdutt= a-mpls-tldp-hello-reduce, and for anyone on the MPLS email list who has com= mented on this draft, can you check the update and see whether the recent u= pdate of the draft (draft-pdutta-mpls-tldp-hello-re= duce-04, posted September 1) addresses your issues?
 
Thanks, Ross
_________________________= ____________________
From: Ross Callon
Sent: Tuesday, July 17, 2012 5:50 PM
To: Markus Jork; lizhong.jin@zte.com.cn; Thomas.Beckhaus@telekom.de<= br> Cc: loa@pi.nu; swallow@cisco.com; Ross Callon; Martin Vigoureux; Dut= ta, Pranjal K (Pranjal); Giles Heron; Thomas Nadeau
Subject: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03
 
 
Markus, Lizhong, Thomas;=
 
You have been selected a= s an MPLS Review team reviewers for
draft-pdutta-mpls-tldp-h= ello-reduce-03
 
Note to authors: You hav= e been CC’d on this email so that you can know that
this review is going on.= However, please do not review your own document.
 
Reviews should comment o= n whether the document is coherent, is it useful
(ie, is it likely to be = actually useful in operational networks), and is
the document technically= sound?  We are interested in knowing whether the
document is ready to be = considered for WG adoption (ie, it doesn’t have to
be perfect at this point= , but should be a good start).
 
Reviews should be sent t= o the document authors, WG co-chairs and secretary,
and CC’d to the MP= LS WG email list. If necessary, comments may be sent
privately to only the WG= chairs.
 
Are you able to review t= his draft by August 3, 2012 (ie, the end of the IETF
meeting in Vancouver)? W= e understand that this is somewhat short notice and 
that you might have some= thing else to do the week of the IETF, so let us
know if you need slightl= y more time.
 
Thanks, Ross
(as MPLS WG chair)
 
PS: I noticed that Tom Nadeau’= ;s email address listed in the draft is out of date. This email is being CC= ’d to his updated address.
 
 --_000_DF7F294AF4153D498141CBEFADB17704C7EC7BDF1BEMBX01WFjnprn_-- From swallow@cisco.com Tue Oct 2 14:19:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE0221F85B1 for ; Tue, 2 Oct 2012 14:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FubvNRE2tfXH for ; Tue, 2 Oct 2012 14:19:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACF721F8433 for ; Tue, 2 Oct 2012 14:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21198; q=dns/txt; s=iport; t=1349212747; x=1350422347; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=5H+qdebqG9F11eVwJHVHVqUHs/OQNkbUuYI4PWLquog=; b=af9MCieSTYz3zfaMYY7UqwrOG/T16oGM+cQ0fYPgni/EgDbyEfKX2BUm BvOfE98rw9gc+BRA2/rIXhe7kQ4H/4oLP8HgsLJkImaw/zmA7jppjVn4t XxSjZFSdY9K/FnAvA1hSDpI/hmpZLlYYSIlKcDE8gBAIV80ZI6n7KorW7 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPtZa1CtJXHA/2dsb2JhbABCA4JLg0C3VYECgQiCIAEBAQQBAQEPAQoGSwsOBAEGAhEDAQILHQMCBBkMAQoUBgMIAgQBDQUIEweHYwuYCo0bgjuQRAQEix8agnuCEzJgA5M8kG+BaYJngWM0 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208,217";a="127666714" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 02 Oct 2012 21:19:06 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q92LJ6l2027283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Oct 2012 21:19:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.241]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Tue, 2 Oct 2012 16:19:06 -0500 From: "George Swallow (swallow)" To: "Ryoo, Jeong-dong" , "D'Alessandro Alessandro Gerardo" , Loa Andersson Thread-Topic: =?utf-8?B?W21wbHNdIO2ajOyLoDogIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRy?= =?utf-8?Q?aft-ietf-mpls-tp-ring-protection?= Thread-Index: AQHNoHl3T+n9uV0il0a2u0IwD3P2gJemluQA Date: Tue, 2 Oct 2012 21:19:05 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0F577ECA@xmb-rcd-x10.cisco.com> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A0DEE0BD7@SMTP2.etri.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.32.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19230.001 x-tm-as-result: No--42.424400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_2FE467D3673DCE409A84D67EC2F607BB0F577ECAxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] =?utf-8?b?7ZqM7IugOiAgV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24g?= =?utf-8?q?draft-ietf-mpls-tp-ring-protection?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 21:19:08 -0000 --_000_2FE467D3673DCE409A84D67EC2F607BB0F577ECAxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aCBjaGFpciBoYXQgb24hDQoNCkEgV0cgbGFzdCBjYWxsIGlzIG5vdCBhdCBhbGwgbGlrZSBh IGNhbGwgZm9yIHdvcmtncm91cCBhZG9wdGlvbi4gIEl0IGlzIGEgdGltZSB0byBwb2ludCBvdXQg YW5kIGRpc2N1c3Mgc3BlY2lmaWMgaXNzdWVzIHdpdGggYSBkcmFmdC4gIFRoZSBvYmplY3QgaXMg dG8gZml4IHRoZSBkcmFmdCBzbyB0aGF0IFdHIGNvbnNlbnN1cyBjYW4gYmUgYWNoaWV2ZWQgdG8g bW92ZSBpdCBmb3J3YXJkLg0KDQpJZiB0aGVyZSBhcmUgdmFsaWQgZGVmaWNpZW5jaWVzLCB0aGVz ZSBuZWVkIHRvIGJlIG9wZW5seSBkaXNjdXNzZWQgYW5kIHRoZW4gYWRkcmVzc2VkIGJ5IHRoZSBh dXRob3JzLiAgSWYgdGhlIFdHIGNvbnNlbnN1cyBpcyB0aGF0IHRoZXJlIGFyZSBkZWZpY2llbmNp ZXMgYW5kIHRoYXQgdGhlIGF1dGhvcnMgaGF2ZSBmYWlsZWQgdG8gYWRkcmVzcyB0aGVtIHRoZW4g d2Ugd291bGQgbm90IGhhdmUgY29uc2Vuc3VzLg0KDQpBICsxLCBzdGF0ZW1lbnQgb2YgIlN1cHBv cnQiIG9yICJEbyBub3Qgc3VwcG9ydCIgaXMgbmVpdGhlciBhcHByb3ByaWF0ZSBub3IgaGVscGZ1 bCBpbiBhIFdHIGxhc3QgY2FsbC4gIE5laXRoZXIgYXJlIGdlbmVyYWwgcG9zaXRpdmUgb3IgbmVn YXRpdmUgY29tbWVudHMuDQoNClBsZWFzZSBiZSB2ZXJ5IHNwZWNpZmljIGluIGRlc2NyaWJpbmcg YW55IGlzc3VlcyB0aGF0IHlvdSBoYXZlIHdpdGggdGhlIGRyYWZ0Lg0KDQovLy9HZW9yZ2UNCg0K RnJvbTogPFJ5b28+LCBKZW9uZy1kb25nIDxyeW9vQGV0cmkucmUua3I8bWFpbHRvOnJ5b29AZXRy aS5yZS5rcj4+DQpEYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDIsIDIwMTIgNDozOSBBTQ0KVG86IEQn QWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8gPGFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVs ZWNvbWl0YWxpYS5pdDxtYWlsdG86YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlh Lml0Pj4sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4NCkNjOiAi bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYub3JnPG1haWx0 bzptcGxzQGlldGYub3JnPj4sICJtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+IiA8bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFp bHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPj4sIE1QTFMtVFAgYWQgaG9jIHRlYW0gPGFo bXBscy10cEBsaXN0cy5pdHUuaW50PG1haWx0bzphaG1wbHMtdHBAbGlzdHMuaXR1LmludD4+LCAi ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZzxtYWlsdG86 ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZz4iIDxkcmFm dC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFm dC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPj4NClN1YmplY3Q6 IFttcGxzXSDtmozsi6A6IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBs cy10cC1yaW5nLXByb3RlY3Rpb24NCg0KDQorMQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCuuztOuCuCDsgqzrnowgOiAiRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2Vy YXJkbyIgPGFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdDxtYWlsdG86YWxl c3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0Pj4NCuuztOuCuCDrgqDsp5wgOiAy MDEyLTEwLTAxIDIxOjM4OjU4ICggKzA5OjAwICkNCuuwm+uKlCDsgqzrnowgOiBMb2EgQW5kZXJz c29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+DQrssLjsobAgOiBtcGxzQGlldGYub3Jn PG1haWx0bzptcGxzQGlldGYub3JnPiA8bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9y Zz4+LCBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc+IDxtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc+PiwgTVBMUy1UUCBhZCBob2MgdGVhbSA8YWhtcGxzLXRwQGxpc3RzLml0 dS5pbnQ8bWFpbHRvOmFobXBscy10cEBsaXN0cy5pdHUuaW50Pj4sIGRyYWZ0LWlldGYtbXBscy10 cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy10 cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc+IDxkcmFmdC1pZXRmLW1wbHMtdHAtcmlu Zy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcmlu Zy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPj4NCuygnOuqqSA6IFtBSE1QTFMtVFBdIFI6IFtt cGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1w cm90ZWN0aW9uDQoNCg0KRG8gbm90IHN1cHBvcnQNCg0KQWNjb3JkaW5nIHRvIHRoZSBvcHRpbWl6 YXRpb24gY3JpdGVyaWEgZm9yIHJpbmcgcHJvdGVjdGlvbiBzcGVjaWZpZWQgaW4gU2VjdGlvbiAy LjUuNi4xIGluIFJGQzU2NTQsIHRoZSBNUExTLVRQIHJpbmcgcHJvdGVjdGlvbiBzaG91bGQgYmUg b3B0aW1pemVkIGZvciBzaW1wbGlmaWNhdGlvbiBvZiB0aGUgcmluZyBvcGVyYXRpb24gYW5kIHRo ZSByZXNvdXJjZXMgY29uc3VtcHRpb24gYXJvdW5kIHRoZSByaW5nLiBJdCBpcyBub3QgdGhlIGNh c2Ugb2YgdGhlIHByb3Bvc2VkIHNvbHV0aW9uLg0KSXQgaXMgYWN0dWFsbHkgc2ltcGx5IGFuIGFw cGxpY2FiaWxpdHkgc3RhdGVtZW50IG9mIGEgbGluZWFyIHByb3RlY3Rpb24gbWVjaGFuaXNtIGJ1 dCBpdCBjYW5ub3QgYmUgY29uc2lkZXIgYSBzb2x1dGlvbiB0aGF0IGFkZHJlc3NlcyB0aGUgcmVx dWlyZW1lbnRzIGZvciBwcm90ZWN0aW9uIG9mIHJpbmcgdG9wb2xvZ2llcyBmb3IgTXVsdGktUHJv dG9jb2wgTGFiZWwgU3dpdGNoaW5nIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBhcyBzcGVj aWZpZWQgaW4gUkZDNTY1NC4NCg0KQmVzdCByZWdhcmRzLA0KQWxlc3NhbmRybw0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClRlbGVjb20gSXRhbGlhDQpBbGVzc2FuZHJvIEdlcmFyZG8gRCdBbGVzc2FuZHJvDQpUcmFu c3BvcnQgSW5ub3ZhdGlvbg0KVmlhIFJlaXNzIFJvbW9saSwgMjc0IC0gMTAxNDggVG9yaW5vDQpw aG9uZTogKzM5IDAxMSAyMjggNTg4Nw0KbW9iaWxlOiArMzkgMzM1IDc2NiA5NjA3DQpmYXg6ICsz OSAwNiA0MTggNjM5IDA3DQoNCg0KLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCkRhOiBt cGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBIZWppYQ0KSW52aWF0bzogc2Fi YXRvIDI5IHNldHRlbWJyZSAyMDEyIDEyOjUzDQpBOiBMb2EgQW5kZXJzc29uDQpDYzogbXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn PG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IE1QTFMtVFAgYWQgaG9jIHRlYW07 IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc+DQpPZ2dl dHRvOiBSZTogW21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBs cy10cC1yaW5nLXByb3RlY3Rpb24NCg0KRG8gbm90IHN1cHBvcnQuDQoNCkJhc2VkIG9uIHRoZSBh bmFseXNpcyBpbiBTZWN0aW9uIDIuNCBvZiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0 aW9uLTAyLCB0aGUgcmluZyBwcm90ZWN0aW9uIHNjaGVtZSB1c2luZyBTUE1FIGFzIGRlc2NyaWJl ZCwgZWl0aGVyIHdyYXBwaW5nIG9yIHN0ZWVyaW5nLCBkb2VzIGhhdmUgZGVmaWNpZW5jaWVzLCB3 aGljaCBJTUhPIHNob3VsZCBiZSBiZXR0ZXIgcmVjb25zaWRlcmVkIGFuZCBzb2x2ZWQgaWYgcG9z c2libGUuDQoNCg0KQi5SLg0KSmlhDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6 ujogbXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IFtt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggTG9hIEFuZGVyc3Nvbg0K5Y+R6YCB 5pe26Ze0OiAyMDEy5bm0OeaciDE55pelIDE4OjQ5DQrmioTpgIE6IG1wbHNAaWV0Zi5vcmc8bWFp bHRvOm1wbHNAaWV0Zi5vcmc+OyBNUExTLVRQIGFkIGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMt dHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMt dHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPjsgbXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0K5Li76aKYOiBbbXBsc10g V29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVj dGlvbg0KDQpXb3JraW5nIEdyb3VwLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29y a2luZyBncm91cCBsYXN0IGNhbGwgb24NCmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rp b24tMDItdHh0Lg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZXJlIGFyZSB0d28gSVBSIGRpc2Nsb3N1 cmVzICMgMTQ2MiBhbmQgIyAxODcyDQpyZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQuDQoNClBsZWFz ZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3RzDQoobXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pLg0KDQpUaGUgd29ya2lu ZyBncm91cCBsYXN0IGNhbGwgZW5kcyBPY3RvYmVyIDMsIDIwMTIuDQoNCi9Mb2ENCmZvciB0aGUg bXBscyB3ZyBjby1jaGFpcnMNCg0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gZW1haWw6IGxvYS5h bmRlcnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzpsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbT4N ClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciBsb2FAcGkubnU8bWFpbHRvOmxvYUBw aS5udT4NCkVyaWNzc29uIEluYyBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KKzQ2IDc2NyA3MiA5 MiAxMw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1w bHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCg0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBz b25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEg ZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxs YSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZp ZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJv cmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNh emlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBH cmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFs IGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUg YWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVz ZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFj aG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQoN Cg0K --_000_2FE467D3673DCE409A84D67EC2F607BB0F577ECAxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+V2l0aCBjaGFp ciBoYXQgb24hPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BIFdHIGxhc3QgY2FsbCBp cyBub3QgYXQgYWxsIGxpa2UgYSBjYWxsIGZvciB3b3JrZ3JvdXAgYWRvcHRpb24uICZuYnNwO0l0 IGlzIGEgdGltZSB0byBwb2ludCBvdXQgYW5kIGRpc2N1c3Mgc3BlY2lmaWMgaXNzdWVzIHdpdGgg YSBkcmFmdC4gJm5ic3A7VGhlIG9iamVjdCBpcyB0byBmaXggdGhlIGRyYWZ0IHNvIHRoYXQgV0cg Y29uc2Vuc3VzIGNhbiBiZSBhY2hpZXZlZCB0byBtb3ZlIGl0IGZvcndhcmQuPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiB0aGVyZSBhcmUgdmFsaWQgZGVmaWNpZW5jaWVzLCB0aGVz ZSBuZWVkIHRvIGJlIG9wZW5seSBkaXNjdXNzZWQgYW5kIHRoZW4gYWRkcmVzc2VkIGJ5IHRoZSBh dXRob3JzLiAmbmJzcDtJZiB0aGUgV0cgY29uc2Vuc3VzIGlzIHRoYXQgdGhlcmUgYXJlIGRlZmlj aWVuY2llcyBhbmQgdGhhdCB0aGUgYXV0aG9ycyBoYXZlIGZhaWxlZCB0byBhZGRyZXNzIHRoZW0g dGhlbiB3ZSB3b3VsZCBub3QgaGF2ZSBjb25zZW5zdXMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+QSAmIzQzOzEsIHN0YXRlbWVudCBvZiAmcXVvdDtTdXBwb3J0JnF1b3Q7 IG9yICZxdW90O0RvIG5vdCBzdXBwb3J0JnF1b3Q7IGlzIG5laXRoZXIgYXBwcm9wcmlhdGUgbm9y IGhlbHBmdWwgaW4gYSBXRyBsYXN0IGNhbGwuICZuYnNwO05laXRoZXIgYXJlIGdlbmVyYWwgcG9z aXRpdmUgb3IgbmVnYXRpdmUgY29tbWVudHMuICZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5QbGVhc2UgYmUgdmVyeSBzcGVjaWZpYyBpbiBkZXNjcmliaW5nIGFu eSBpc3N1ZXMgdGhhdCB5b3UgaGF2ZSB3aXRoIHRoZSBkcmFmdC48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pi8vL0dlb3JnZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp OyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJP VFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RU T006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRP UDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkct VE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4m bHQ7UnlvbyZndDssIEplb25nLWRvbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpyeW9vQGV0cmkucmUu a3IiPnJ5b29AZXRyaS5yZS5rcjwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBPY3RvYmVyIDIsIDIwMTIgNDozOSBBTTxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkQnQWxlc3NhbmRybyBB bGVzc2FuZHJvIEdlcmFyZG8gJmx0OzxhIGhyZWY9Im1haWx0bzphbGVzc2FuZHJvLmRhbGVzc2Fu ZHJvQHRlbGVjb21pdGFsaWEuaXQiPmFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxp YS5pdDwvYT4mZ3Q7LCBMb2EgQW5kZXJzc29uICZsdDs8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51 Ij5sb2FAcGkubnU8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5D YzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0 Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnIj5tcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+bXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc8L2E+Jmd0OywNCiBNUExTLVRQIGFkIGhvYyB0ZWFtICZsdDs8YSBocmVmPSJtYWlsdG86 YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQiPmFobXBscy10cEBsaXN0cy5pdHUuaW50PC9hPiZndDss ICZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9u QHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xz LmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbXBscy10 cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtbXBscy10cC1yaW5n LXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W21wbHNdIO2ajOyLoDogV29ya2luZyBncm91 cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PHN0eWxlPlAge01BUkdJTi1UT1A6IDBtbTsg TUFSR0lOLUJPVFRPTTogMG1tfTwvc3R5bGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1J TFk6IOq1tOumvDsgRk9OVC1TSVpFOiAxMHB0IiBpZD0iZXpGb3JtUHJvY19kaXYiPg0KPGRpdiBp ZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdj48YnI+DQomIzQzOzE8L2Rpdj4NCjxkaXY+PGJyPg0K Jm5ic3A7PC9kaXY+DQo8ZGl2IGlkPSJNYWlsU2lnblNlbnQiPjxicj4NCjwvZGl2Pg0KPGRpdj4N CjxociB0YWJpbmRleD0iLTEiPg0KPC9kaXY+DQo8ZGl2PjxiPuuztOuCuCDsgqzrnowgOiA8L2I+ JnF1b3Q7RCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbyZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdCI+YWxlc3NhbmRy by5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0PC9hPiZndDs8YnI+DQo8Yj7rs7Trgrgg64Kg 7KecIDogPC9iPjIwMTItMTAtMDEgMjE6Mzg6NTggKCAmIzQzOzA5OjAwICk8YnI+DQo8Yj7rsJvr ipQg7IKs656MIDogPC9iPkxvYSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGku bnUiPmxvYUBwaS5udTwvYT4mZ3Q7PGJyPg0KPGI+7LC47KGwIDogPC9iPjxhIGhyZWY9Im1haWx0 bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1w bHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+Jmd0OywNCjxhIGhyZWY9Im1haWx0bzptcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZyI+bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+ICZs dDs8YSBocmVmPSJtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPm1wbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnPC9hPiZndDssIE1QTFMtVFAgYWQgaG9jIHRlYW0gJmx0OzxhIGhyZWY9 Im1haWx0bzphaG1wbHMtdHBAbGlzdHMuaXR1LmludCI+YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQ8 L2E+Jmd0OywNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0 aW9uQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRv b2xzLmlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbXBscy10cC1y aW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXBy b3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPuygnOuqqSA6IDwvYj5bQUhN UExTLVRQXSBSOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1t cGxzLXRwLXJpbmctcHJvdGVjdGlvbjxicj4NCjxicj4NCjxicj4NCkRvIG5vdCBzdXBwb3J0PGJy Pg0KPGJyPg0KQWNjb3JkaW5nIHRvIHRoZSBvcHRpbWl6YXRpb24gY3JpdGVyaWEgZm9yIHJpbmcg cHJvdGVjdGlvbiBzcGVjaWZpZWQgaW4gU2VjdGlvbiAyLjUuNi4xIGluIFJGQzU2NTQsIHRoZSBN UExTLVRQIHJpbmcgcHJvdGVjdGlvbiBzaG91bGQgYmUgb3B0aW1pemVkIGZvciBzaW1wbGlmaWNh dGlvbiBvZiB0aGUgcmluZyBvcGVyYXRpb24gYW5kIHRoZSByZXNvdXJjZXMgY29uc3VtcHRpb24g YXJvdW5kIHRoZSByaW5nLiBJdCBpcyBub3QgdGhlIGNhc2Ugb2YNCiB0aGUgcHJvcG9zZWQgc29s dXRpb24uPGJyPg0KSXQgaXMgYWN0dWFsbHkgc2ltcGx5IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVt ZW50IG9mIGEgbGluZWFyIHByb3RlY3Rpb24gbWVjaGFuaXNtIGJ1dCBpdCBjYW5ub3QgYmUgY29u c2lkZXIgYSBzb2x1dGlvbiB0aGF0IGFkZHJlc3NlcyB0aGUgcmVxdWlyZW1lbnRzIGZvciBwcm90 ZWN0aW9uIG9mIHJpbmcgdG9wb2xvZ2llcyBmb3IgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNo aW5nIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBhcyBzcGVjaWZpZWQNCiBpbiBSRkM1NjU0 Ljxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQpBbGVzc2FuZHJvPGJyPg0KPGJyPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KVGVsZWNvbSBJdGFsaWE8YnI+DQpBbGVzc2FuZHJvIEdlcmFyZG8gRCdBbGVz c2FuZHJvPGJyPg0KVHJhbnNwb3J0IElubm92YXRpb248YnI+DQpWaWEgUmVpc3MgUm9tb2xpLCAy NzQgLSAxMDE0OCBUb3Jpbm88YnI+DQpwaG9uZTogJiM0MzszOSAwMTEgMjI4IDU4ODc8YnI+DQpt b2JpbGU6ICYjNDM7MzkgMzM1IDc2NiA5NjA3PGJyPg0KZmF4OiAmIzQzOzM5IDA2IDQxOCA2Mzkg MDc8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLTxicj4NCkRh OiA8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnIj5tcGxzLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPl0gUGVyIGNvbnRvIGRpIEhlamlhPGJyPg0KSW52aWF0 bzogc2FiYXRvIDI5IHNldHRlbWJyZSAyMDEyIDEyOjUzPGJyPg0KQTogTG9hIEFuZGVyc3Nvbjxi cj4NCkNjOiA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT47 IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+DQptcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZzwvYT47IE1QTFMtVFAgYWQgaG9jIHRlYW07IDxhIGhyZWY9Im1haWx0 bzpkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnIj4NCmRy YWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0K T2dnZXR0bzogUmU6IFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRm LW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uPGJyPg0KPGJyPg0KRG8gbm90IHN1cHBvcnQuPGJyPg0K PGJyPg0KQmFzZWQgb24gdGhlIGFuYWx5c2lzIGluIFNlY3Rpb24gMi40IG9mIGRyYWZ0LWlldGYt bXBscy10cC1yaW5nLXByb3RlY3Rpb24tMDIsIHRoZSByaW5nIHByb3RlY3Rpb24gc2NoZW1lIHVz aW5nIFNQTUUgYXMgZGVzY3JpYmVkLCBlaXRoZXIgd3JhcHBpbmcgb3Igc3RlZXJpbmcsIGRvZXMg aGF2ZSBkZWZpY2llbmNpZXMsIHdoaWNoIElNSE8gc2hvdWxkIGJlIGJldHRlciByZWNvbnNpZGVy ZWQgYW5kIHNvbHZlZCBpZiBwb3NzaWJsZS48YnI+DQo8YnI+DQo8YnI+DQpCLlIuPGJyPg0KSmlh PGJyPg0KPGJyPg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLTxicj4NCuWPkeS7tuS6ujogPGEgaHJl Zj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9h PiBbPGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZzwvYT5dIOS7o+ihqCBMb2EgQW5kZXJzc29uPGJyPg0K5Y+R6YCB5pe26Ze0 OiAyMDEy5bm0OeaciDE55pelIDE4OjQ5PGJyPg0K5oqE6YCBOiA8YSBocmVmPSJtYWlsdG86bXBs c0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT47IE1QTFMtVFAgYWQgaG9jIHRlYW07IDxhIGhy ZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYu b3JnIj4NCmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8 L2E+OyA8YSBocmVmPSJtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPg0KbXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0K5Li76aKYOiBbbXBsc10gV29ya2luZyBncm91 cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbjxicj4NCjxi cj4NCldvcmtpbmcgR3JvdXAsPGJyPg0KPGJyPg0KdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVr IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPGJyPg0KZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmct cHJvdGVjdGlvbi0wMi10eHQuPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCB0aGVyZSBhcmUg dHdvIElQUiBkaXNjbG9zdXJlcyAjIDE0NjIgYW5kICMgMTg3Mjxicj4NCnJlbGF0ZWQgdG8gdGhp cyBkb2N1bWVudC48YnI+DQo8YnI+DQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBt cGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0czxicj4NCig8YSBocmVmPSJtYWlsdG86bXBs c0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4pLjxicj4NCjxicj4NClRoZSB3b3JraW5nIGdy b3VwIGxhc3QgY2FsbCBlbmRzIE9jdG9iZXIgMywgMjAxMi48YnI+DQo8YnI+DQovTG9hPGJyPg0K Zm9yIHRoZSBtcGxzIHdnIGNvLWNoYWlyczxicj4NCjxicj4NCjxicj4NCi0tPGJyPg0KPGJyPg0K PGJyPg0KTG9hIEFuZGVyc3NvbiBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYS5hbmRlcnNzb25A ZXJpY3Nzb24uY29tIj5sb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbTwvYT48YnI+DQpTciBTdHJh dGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgPGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSI+bG9h QHBpLm51PC9hPjxicj4NCkVyaWNzc29uIEluYyBwaG9uZTogJiM0Mzs0NiAxMCA3MTcgNTIgMTM8 YnI+DQomIzQzOzQ2IDc2NyA3MiA5MiAxMzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+PGJyPg0KPGJyPg0KUXVlc3Rv IG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1l bnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lh c2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZv cm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNl dnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlcg0KIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJl Z2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHBy b3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS48YnI+DQo8YnI+DQpUaGlzIGUt bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4g cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5 LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNl IGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UNCiBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZp c2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuPGJyPg0KPGJyPg0KPGJyPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_2FE467D3673DCE409A84D67EC2F607BB0F577ECAxmbrcdx10ciscoc_-- From larryli888@yahoo.com.cn Tue Oct 2 17:58:50 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DF321F851C for ; Tue, 2 Oct 2012 17:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxJqtVITy5BF for ; Tue, 2 Oct 2012 17:58:48 -0700 (PDT) Received: from nm18-vm2.bullet.mail.sg3.yahoo.com (nm18-vm2.bullet.mail.sg3.yahoo.com [106.10.149.97]) by ietfa.amsl.com (Postfix) with SMTP id DCD9521F850C for ; Tue, 2 Oct 2012 17:58:47 -0700 (PDT) Received: from [106.10.166.126] by nm18.bullet.mail.sg3.yahoo.com with NNFMP; 03 Oct 2012 00:58:43 -0000 Received: from [106.10.151.202] by tm15.bullet.mail.sg3.yahoo.com with NNFMP; 03 Oct 2012 00:58:43 -0000 Received: from [127.0.0.1] by omp1014.mail.sg3.yahoo.com with NNFMP; 03 Oct 2012 00:58:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 308691.19603.bm@omp1014.mail.sg3.yahoo.com Received: (qmail 40446 invoked by uid 60001); 3 Oct 2012 00:58:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1349225919; bh=slGVNnaysRoCLcJtUZaM+434aLigu46q4ewoQk92jnk=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0JFg3QBvqfM86jtE1w1/L34HN67IwfYl53WSE7K3Ddu8VtVEm+Fv7/XZMYufqTSiBNTjeYeS0bn10OBZfpX558Vf3T7jvESP+4N5KaF7DZ+u4J3NajPB4Z/cCSKBZME5XXXL1HxT8c2aw/sfeG17z0DcKKWZ9xEM9ijVHg5Oetc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Nnen74PGFi8xay3lajeB8ALFYwbgBsB8o55PeGfQhNDZC5EVZq7FN48aBDnhPzfie+gW4DNiKtn5zgofmG8Pn//5T2R1hjC7Z8Lss93tVCQAFwiCT+0PAkNgfcKfywbtIhB0RhfoFY+NHGdDfEuGaokuCsktmPPybdr6rMLfR5o=; X-YMail-OSG: MR2usSsVM1mwAQ_9n58Z8CuJVbY8gpk9pLViJVU98JRJCUg T71dg8Se20vGH6p_71QMzdglZZEKvcsU6Lcn6EX8hqyiDOKHukP2vYTQYdny JPTh8PYGxE3X3P74ec.bY4OLlOLwx.n1sUNzdhIb6RJ6h1CjeGrljDW9ubDk DFVWwe2QH7.r9BFLrFYc7aM2tBj3nrsi3.F43vlwCq4QXOZ2_h2pIpUZ9IN_ ldyPQh1C2.dTUELhWThlMYkDGPLsqjkQHjZrsWUNeSbTbyVQP_IuHgfzidTb iTPJwZBCC9sShl4Zg7rdy8ZVWSWtSUfTQLKbuiSbFVrC9yH26rgzBj.SRflv 52mtXD1.rq0F03IiFRSGg8udoBGoA_oNthEbwjCsz.RgVTZ.A9ssLPX2AkCP 7KoJRCEb5WYcGbMSS4Nn2uBFdmjzk4ILlmF0- Received: from [221.130.253.135] by web15608.mail.cnb.yahoo.com via HTTP; Wed, 03 Oct 2012 08:58:39 CST X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.434 Message-ID: <1349225919.39819.YahooMailClassic@web15608.mail.cnb.yahoo.com> Date: Wed, 3 Oct 2012 08:58:39 +0800 (CST) From: Larry To: D'Alessandro Alessandro Gerardo , huubatwork@gmail.com, " Nurit \(NSN - IL/Hod HaSharon\)Sprecher" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1134129794-1174354047-1349225919=:39819" Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, MPLS-TP ad hoc team , draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] [AHMPLS-TP] R: Working group last call ondraft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 00:58:50 -0000 ---1134129794-1174354047-1349225919=:39819 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear Nurit: =C2=A0 =C2=A0 =C2=A0 =C2=A0China Mobile presented several contributions abo= ut ring protection in last ITU-T SG15 plenary meeting. We compared the comp= lexity and resources requirement (labels and OAM sessions) of different sch= emes. After discussion, we summerized the requirements in the liason to IET= F. Thank you! Best regards, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Han Li ************************************************************************* =0AHan Li, Ph.D=20 =0AChina Mobile Research Institute =0A32 Xuanwumen West Street, Xicheng District, Beijing 100053, China=20 =0AFax: +86 10 63135159=20 =0AMOBILE: 13501093385=20 =0A************************************************************************= * --- 12=E5=B9=B410=E6=9C=882=E6=97=A5=EF=BC=8C=E5=91=A8=E4=BA=8C, Sprecher, = Nurit (NSN - IL/Hod HaSharon) =E5=86=99=E9=81=93= =EF=BC=9A =E5=8F=91=E4=BB=B6=E4=BA=BA: Sprecher, Nurit (NSN - IL/Hod HaSharon) =E4=B8=BB=E9=A2=98: RE: [mpls] [AHMPLS-TP] R: Working group last call ondra= ft-ietf-mpls-tp-ring-protection =E6=94=B6=E4=BB=B6=E4=BA=BA: "ext Larry" , "D'Ales= sandro Alessandro Gerardo" , huuba= twork@gmail.com =E6=8A=84=E9=80=81: mpls@ietf.org, mpls-chairs@tools.ietf.org, "MPLS-TP ad = hoc team" , draft-ietf-mpls-tp-ring-protection@too= ls.ietf.org =E6=97=A5=E6=9C=9F: 2012=E5=B9=B410=E6=9C=882=E6=97=A5,=E5=91=A8=E4=BA=8C,= =E4=B8=8B=E5=8D=8810:50 Dear Han Li,Thanks for your comment. =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Can you please explain why do you think there are risks = that protection switch time exceeds 50ms ("from the moment of fault detecti= on in a =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0network with a 16-n= ode ring with less than 1200 km of fiber" as required in RFC 5654)? What in= the proposed solution make you think there are risks? =C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Can you please indicate why do you thi= nk the configuration is too complex and why it requires too many labels and= OAM sessions...and how do you think this could be better optimized? In ord= er to refer to this as a LC comment, the technical arguments should be pres= ented and elaborated. Thanks and best regards,Nurit =C2=A0-----Original Mes= sage----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext= Larry Sent: Tuesday, October 02, 2012 12:41 PM To: D'Alessandro Alessandro Gerardo; huubatwork@gmail.com Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-i= etf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] [AHMPLS-TP] R: Working group last call ondraft-ietf-mpl= s-tp-ring-protection =C2=A0not support!It doesn't satisfy some requirements= of the operators. The configuration is too complex and needs too many labe= ls and OAM sessions. There are risks that protection switch time exceed 50m= s. =C2=A0******************************************************************= *******Han Li, Ph.D China Mobile Research Institute32 Xuanwumen West Street= , Xicheng District, Beijing 100053, China Fax: +86 10 63135159 MOBILE: 1350= 1093385 *******************************************************************= ****** =C2=A0 =C2=A0--- 12=E5=B9=B410=E6=9C=882=E6=97=A5=EF=BC=8C=E5=91=A8= =E4=BA=8C, Huub van Helvoort =E5=86=99=E9=81=93=EF= =BC=9A =C2=A0> =E5=8F=91=E4=BB=B6=E4=BA=BA: Huub van Helvoort > =E4=B8=BB=E9=A2=98: Re: [mpls] [AHMPLS-TP] R: Working group last= call on draft-ietf-mpls-tp-ring-protection> =E6=94=B6=E4=BB=B6=E4=BA=BA: "= D'Alessandro Alessandro Gerardo" >= =E6=8A=84=E9=80=81: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "MPLS-TP ad hoc= team" , "draft-ietf-mpls-tp-ring-protection@tools= .ietf.org" > =E6=97=A5= =E6=9C=9F: 2012=E5=B9=B410=E6=9C=882=E6=97=A5,=E5=91=A8=E4=BA=8C,=E4=B8=8B= =E5=8D=885:02> Do not support.> > Same reasons as mentioned below.> > Regar= ds, Huub.> > On 01-10-12 14:27, D'Alessandro Alessandro Gerardo wrote:> > D= o not support> >> > According to the optimization criteria for ring> protec= tion specified in Section 2.5.6.1 in RFC5654, the> MPLS-TP ring protection = should be optimized for> simplification of the ring operation and the resou= rces> consumption around the ring. It is not the case of the> proposed solu= tion.> > It is actually simply an applicability statement of a> linear prot= ection mechanism but it cannot be consider a> solution that addresses the r= equirements for protection of> ring topologies for Multi-Protocol Label Swi= tching Transport> Profile (MPLS-TP) as specified in RFC5654.> >> > Best regards,> > Alessandro> >> >> ---------------------= ---------------------------------------------> > Telecom Italia> > Alessand= ro Gerardo D'Alessandro> > Transport Innovation> > Via Reiss Romoli, 274 - = 10148 Torino> > phone:=C2=A0 +39 011 228 5887> > mobile: +39 335 766 9607> = > fax: +39 06 418 639 07> >> >> > -----Messaggio originale-----> > Da: mpls= -bounces@ietf.org> [mailto:mpls-bounces@ietf.org]> Per conto di Hejia> > In= viato: sabato 29 settembre 2012 12:53> > A: Loa Andersson> > Cc: mpls@ietf.= org; mpls-chairs@tools.ietf.org;> MPLS-TP ad hoc team; draft-ietf-mpls-tp-r= ing-protection@tools.ietf.org> > Oggetto: Re: [mpls] Working group last cal= l on> draft-ietf-mpls-tp-ring-protection> >> > Do not support.> >> > Based = on the analysis in Section 2.4 of> draft-ietf-mpls-tp-ring-protection-02, t= he ring protection> scheme using SPME as described, either wrapping or stee= ring,> does have deficiencies, which IMHO should be better> reconsidered and solved if possible.> >> >> > B.R.> > Jia> >> > -----=E9=82=AE=E4=BB=B6= =E5=8E=9F=E4=BB=B6-----> > =E5=8F=91=E4=BB=B6=E4=BA=BA: mpls-bounces@ietf.o= rg> [mailto:mpls-bounces@ietf.org]> =E4=BB=A3=E8=A1=A8 Loa Andersson> > =E5= =8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B49=E6=9C=8819=E6=97=A5 18:49= > > =E6=8A=84=E9=80=81: mpls@ietf.org;> MPLS-TP ad hoc team; draft-ietf-mpl= s-tp-ring-protection@tools.ietf.org;> mpls-chairs@tools.ietf.org> > =E4=B8= =BB=E9=A2=98: [mpls] Working group last call on> draft-ietf-mpls-tp-ring-pr= otection> >> > Working Group,> >> > this is to start a two week working gro= up last call on> > draft-ietf-mpls-tp-ring-protection-02-txt.> >> > Please = note that there are two IPR disclosures # 1462> and=C2=A0 # 1872> > related= to this document.> >> > Please send your comments to the mpls working grou= p> mailing lists> > (mpls@ietf.org).> >> > The working group last call ends= October 3, 2012.> >> > /Loa> > for the mpls wg co-chairs> >> >> > --> >> >= > > Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0email:> loa.andersson@ericsson.com> = > Sr Strategy and Standards Manager=C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 loa@pi.nu> > E= ricsson Inc=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 phone: +46> 10 717 52 13> >=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = +46> 767 72 92 13> > _______________________________________________> > mpl= s mailing list> > mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mp= ls> > _______________________________________________> > mpls mailing list>= > mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mpls> > -- > ****= *************************************************************> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0=C2=A0=C2=A0=E8=AF=B7=E8=AE=B0=E4=BD= =8F=EF=BC=8C=E4=BD=A0=E6=98=AF=E7=8B=AC=E4=B8=80=E6=97=A0=E4=BA=8C=E7=9A=84= =EF=BC=8C=E5=B0=B1=E5=83=8F=E5=85=B6=E4=BB=96=E6=AF=8F=E4=B8=80=E4=B8=AA=E4= =BA=BA=E4=B8=80=E6=A0=B7> _______________________________________________> = mpls mailing list> mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpl= s> _______________________________________________mpls mailing listmpls@iet= f.orghttps://www.ietf.org/mailman/listinfo/mpls ---1134129794-1174354047-1349225919=:39819 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear Nurit:

    =    China Mobile presented several contributions about ring protec= tion in last ITU-T SG15 plenary meeting. We compared the complexity and res= ources requirement (labels and OAM sessions) of different schemes. After di= scussion, we summerized the requirements in the liason to IETF. Thank you!<= /div>

Best regards,

  &nbs= p;                     &n= bsp;    Han Li

*******************************************= ******************************
=0AHan Li, Ph.D
=0AChina Mobile Resea= rch Institute
=0A32 Xuanwumen West Street, Xicheng District, Beijing 100= 053, China
=0AFax: +86 10 63135159
=0AMOBILE: 13501093385
=0A**= ***********************************************************************
=
--- 12=E5=B9=B410=E6=9C=882=E6=97=A5=EF=BC=8C=E5=91=A8=E4=BA=8C, Spr= echer, Nurit (NSN - IL/Hod HaSharon) <nurit.sprecher@nsn.com><= /b> =E5=86=99=E9=81=93=EF=BC=9A

=E5=8F=91= =E4=BB=B6=E4=BA=BA: Sprecher, Nurit (NSN - IL/Hod HaSharon) <nurit.sprec= her@nsn.com>
=E4=B8=BB=E9=A2=98: RE: [mpls] [AHMPLS-TP] R: Working gr= oup last call ondraft-ietf-mpls-tp-ring-protection
=E6=94=B6=E4=BB=B6=E4= =BA=BA: "ext Larry" <larryli888@yahoo.com.cn>, "D'Alessandro Alessand= ro Gerardo" <alessandro.dalessandro@telecomitalia.it>, huubatwork@gma= il.com
=E6=8A=84=E9=80=81: mpls@ietf.org, mpls-chairs@tools.ietf.org, "M= PLS-TP ad hoc team" <ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-rin= g-protection@tools.ietf.org
=E6=97=A5=E6=9C=9F: 2012=E5=B9=B410=E6=9C=88= 2=E6=97=A5,=E5=91=A8=E4=BA=8C,=E4=B8=8B=E5=8D=8810:50

Dea= r Han Li,

Thanks for your comment.

=C2=B7 &= nbsp;       Can you please explain why do you think there are risks that p= rotection switch time exceeds 50ms ("from the moment of fault detection in = a         n= etwork with a 16-node ring with less than 1200 km of fiber" as required in = RFC 5654)? What in the proposed solution make you think there are risks?

=C2=B7       &n= bsp; Can you please indicate = why do you think the configuration is too complex and why it requires too m= any labels and OAM sessions...and how do you think this could be better opt= imized?

In order to refer to this= as a LC comment, the technical arguments should be presented and elaborate= d.

Thanks and best regards,

Nurit

 

-= ----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounc= es@ietf.org] On Behalf Of ext Larry
Sent: Tuesday, October 02, 2012 12:4= 1 PM
To: D'Alessandro Alessandro Gerardo; huubatwork@gmail.com
Cc: mp= ls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org
Subject: Re: [mpls] [= AHMPLS-TP] R: Working group last call ondraft-ietf-mpls-tp-ring-protection<= /span>

 

not support!

It doesn't satisfy some requirements of the operators. The configuration i= s too complex and needs too many labels and OAM sessions. There are risks t= hat protection switch time exceed 50ms.

 

********************= *****************************************************

Han Li, Ph.D

= China Mobile Research Institute

32= Xuanwumen West Street, Xicheng District, Beijing 100053, China

Fax: +86 10 63135159

MOBILE: 13501093385

****************************************************= *********************

 

<= p class=3D"yiv934067078MsoPlainText">  

--- 12=E5=B9= =B410=E6=9C=882=E6=97=A5=EF=BC=8C= =E5=91=A8=E4=BA=8C, Huub van Helvoort <huubatwork@gmail.com> =E5=86=99=E9=81=93=EF=BC=9A

 

> =E5=8F=91=E4=BB=B6=E4=BA=BA: Huub = van Helvoort <huubatwork@gmail.com>

> =E4=B8=BB=E9=A2=98: Re: [mpls] [AHMPLS-TP] R: Working group last call on draft-ietf-mpls= -tp-ring-protection

> =E6=94=B6=E4=BB=B6=E4=BA=BA: "D'Alessandro Alessandro Gerardo" <alessandro.dalessandro@telecomitalia.it>

> =E6=8A=84=E9=80=81: "mpls@ietf.org" <mpls@ietf.o= rg>, "mpls-chairs@t= ools.ietf.org" <mpl= s-chairs@tools.ietf.org>, "MPLS-TP ad hoc team" <ahmpls-tp@lists.itu.int>, "draft-ietf-mpls-tp-ring-protection@tools.ietf.= org" <draft-ietf-mpls-tp-ring-protection@tools.= ietf.org>

> =E6=97=A5=E6=9C=9F: 20= 12=E5=B9=B410=E6=9C=882=E6=97=A5,=E5=91=A8=E4=BA=8C,=E4=B8=8B=E5=8D=885:02

> Do not support.

> <= /p>

> Same reasons as mentioned bel= ow.

>

> Regards, Huub.

>

> On 01-10-12 14:27, D= 'Alessandro Alessandro Gerardo wrote:

> > Do not support

> = >

> > According to the op= timization criteria for ring

> = protection specified in Section 2.5.6.1 in RFC5654, the

> MPLS-TP ring protection should be optimized for

> simp= lification of the ring operation and the resources

> consumption around the ring. It is not the case of th= e

> proposed solution.

> > It is actually simply an applica= bility statement of a

> linear = protection mechanism but it cannot be consider a

> solution that addresses the requirements for protection= of

> ring topologies for Multi= -Protocol Label Switching Transport

> Profile (MPLS-TP) as specified in RFC5654.

> >

> >= ; Best regards,

> > Alessand= ro

> >

> >

> -------= -----------------------------------------------------------

> > Telecom Italia

> > Alessandro Gerardo D'Alessandro

> > Transport Innovation

> > Via Reiss Romoli, 274 - 10148 Torino

> > phone:  +39 011 228 5887<= /p>

> > mobile: +39 335 766 9607=

> > fax: +39 06 418 639 07<= /p>

> >

> >

> &g= t; -----Messaggio originale-----

&= gt; > Da: mpls-bounces@ietf.org

> [mailto:= mpls-bounces@ietf.org]

= > Per conto di Hejia

> > = Inviato: sabato 29 settembre 2012 12:53

> > A: Loa Andersson

&= gt; > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org;

> MPLS-TP ad hoc team; draft-= ietf-mpls-tp-ring-protection@tools.ietf.org

> > Oggetto: Re: [mpls] Working group last call = on

> draft-ietf-mpls-tp-ring-pr= otection

> >

> > Do not support.

> >

> &= gt; Based on the analysis in Section 2.4 of

> draft-ietf-mp= ls-tp-ring-protection-02, the ring protection

> scheme using SPME as described, either wrapping or steerin= g,

> does have deficiencies, wh= ich IMHO should be better

> rec= onsidered and solved if possible.

= > >

> >

> > B.R.

> > Jia

> >

> > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----

> > =E5=8F=91=E4=BB=B6=E4=BA=BA: mpls-bounces@ietf.org

> [mailto:= mpls-bounces@ietf.org]

= > =E4=BB=A3=E8=A1=A8<= /span> Loa Andersson

> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B4= 9=E6=9C=8819=E6=97=A5 18:49

> > =E6=8A=84=E9=80=81: mpls@ietf.org;

> MPLS-TP ad hoc team; draft= -ietf-mpls-tp-ring-protection@tools.ietf.org;

> mpls-= chairs@tools.ietf.org

&= gt; > =E4=B8=BB=E9=A2=98: [mpls] Working grou= p last call on

> draft-ietf-mpls-tp-ring-protection=

> >

> > Working Group,

> >

> > this = is to start a two week working group last call on

> > draft-ietf-mpls-tp-ring-protection-02-txt.

> >

> > Please note that there are two IPR disclosures # 1462<= /p>

> and  # 1872

> > related to this document.

> >

> > Please send your comments to the mpls working group

> mailing lists

> > (mpls@ietf.o= rg).

> >

> > The working group last call ends= October 3, 2012.

> >

> > /Loa

> > for the mpls wg co-chairs

> >

> &= gt;

> > --

> >

= > >

> > Loa Andersson&= nbsp;          

>              email:

> loa.andersson@ericsson= .com

> > Sr Strat= egy and Standards Manager     

>       loa@pi.nu

> > Ericsson Inc     =      

>   =             phone: +46

> 10 717 52 13

> >               

>                

>          =       +46

> 767= 72 92 13

> > ______________= _________________________________

= > > mpls mailing list

> &= gt; mpls@ietf.org

> > https://www.ietf.org/mailman/listinfo/mpls

> > _____________________________= __________________

> > mpls = mailing list

> > mpls@ietf.org

>= > https://www.ietf.org/mailman/listinfo/mpls

>

> --=

> ***************************= **************************************

>            

>    =E8=AF=B7=E8=AE=B0= =E4=BD=8F=EF=BC=8C=E4=BD=A0=E6=98=AF=E7=8B=AC=E4=B8=80=E6=97=A0=E4=BA=8C=E7= =9A=84=EF=BC=8C=E5=B0=B1=E5=83=8F=E5=85=B6=E4=BB=96=E6=AF=8F=E4=B8=80=E4=B8= =AA=E4=BA=BA=E4=B8=80=E6=A0=B7

> _______________________________________________

> mpls mailing list

> mpls@ietf.org

> https://www.ietf.org/mailman/listinfo/mpls

>

_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo= /mpls

---1134129794-1174354047-1349225919=:39819-- From yi.yu@zte.com.cn Tue Oct 2 20:04:12 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B823821F85C3; Tue, 2 Oct 2012 20:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlRn-iiIYoyG; Tue, 2 Oct 2012 20:04:12 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3D021F859A; Tue, 2 Oct 2012 20:04:11 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id BCE301260CDD; Wed, 3 Oct 2012 10:56:57 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 75355DF569D; Wed, 3 Oct 2012 11:00:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q9333uLC024097; Wed, 3 Oct 2012 11:03:56 +0800 (GMT-8) (envelope-from yi.yu@zte.com.cn) In-Reply-To: To: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-ring-protection@tools.ietf.org, mpls-bounces@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: yi.yu@zte.com.cn Date: Wed, 3 Oct 2012 11:03:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-03 11:03:53, Serialize complete at 2012-10-03 11:03:53 Content-Type: multipart/alternative; boundary="=_alternative 0010D7E148257A8C_=" X-MAIL: mse01.zte.com.cn q9333uLC024097 Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 03:04:12 -0000 This is a multipart message in MIME format. --=_alternative 0010D7E148257A8C_= Content-Type: text/plain; charset="US-ASCII" Do not support. The MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption. Best Regards Yu -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Wednesday, September 19, 2012 3:49 AM Cc: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-ring-protection-02-txt. Please note that there are two IPR disclosures # 1462 and # 1872 related to this document. Please send your comments to the mpls working group mailing lists (mpls@ietf.org). The working group last call ends October 3, 2012. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://www.ietf.org/mail-archive/web/mpls/attachments/20121001/6d21ce23/attachment.htm > ------------------------------ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls End of mpls Digest, Vol 102, Issue 1 ************************************ -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 0010D7E148257A8C_= Content-Type: text/html; charset="US-ASCII"
Do not support.

The MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption.

Best Regards
Yu


-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Wednesday, September 19, 2012 3:49 AM
Cc: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

Working Group,

this is to start a two week working group last call on draft-ietf-mpls-tp-ring-protection-02-txt.

Please note that there are two IPR disclosures # 1462 and  # 1872 related to this document.

Please send your comments to the mpls working group mailing lists (mpls@ietf.org).

The working group last call ends October 3, 2012.

/Loa
for the mpls wg co-chairs


--


Loa Andersson                         email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                             +46 767 72 92 13 _______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/mpls/attachments/20121001/6d21ce23/attachment.htm>

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

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


End of mpls Digest, Vol 102, Issue 1
************************************
  

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 0010D7E148257A8C_=-- From nurit.sprecher@nsn.com Tue Oct 2 23:30:32 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8833E21F869F for ; Tue, 2 Oct 2012 23:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4BbFz1nITlU for ; Tue, 2 Oct 2012 23:30:31 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7E021F8615 for ; Tue, 2 Oct 2012 23:30:29 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q936ULFb031222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 08:30:21 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q936UL69004423; Wed, 3 Oct 2012 08:30:21 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Oct 2012 08:30:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA130.8FCCBC35" Date: Wed, 3 Oct 2012 08:30:19 +0200 Message-ID: In-Reply-To: <1349225919.39819.YahooMailClassic@web15608.mail.cnb.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [AHMPLS-TP] R: Working group last call ondraft-ietf-mpls-tp-ring-protection Thread-Index: Ac2hAkbge0dW9T5PSISWYwwD4QzovAALgwKQ References: <1349225919.39819.YahooMailClassic@web15608.mail.cnb.yahoo.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Larry" , "D'Alessandro Alessandro Gerardo" , X-OriginalArrivalTime: 03 Oct 2012 06:30:21.0138 (UTC) FILETIME=[90148B20:01CDA130] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 81904 X-purgate-ID: 151667::1349245827-00003184-5938DD89/0-0/0-0 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, MPLS-TP ad hoc team , draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] [AHMPLS-TP] R: Working group last call ondraft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 06:30:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDA130.8FCCBC35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBIYW4gTGksDQpUaGFua3MgZm9yIHlvdXIgaW50cm9kdWN0aW9uLiANCk9idmlvdXNseSBp dCBpcyBub3QgcG9zc2libGUgdG8gcmVmZXIgb3IgZGlzY3VzcyBzb21ldGhpbmcgdGhhdCBoYXMg bm90IGJlZW4gcG9zdGVkIG9yIHByZXNlbnRlZOKApi4NCkJlc3QgcmVnYXJkcywNCk51cml0DQog DQpGcm9tOiBleHQgTGFycnkgW21haWx0bzpsYXJyeWxpODg4QHlhaG9vLmNvbS5jbl0gDQpTZW50 OiBXZWRuZXNkYXksIE9jdG9iZXIgMDMsIDIwMTIgMjo1OSBBTQ0KVG86IEQnQWxlc3NhbmRybyBB bGVzc2FuZHJvIEdlcmFyZG87IGh1dWJhdHdvcmtAZ21haWwuY29tOyBTcHJlY2hlciwgTnVyaXQg KE5TTiAtIElML0hvZCBIYVNoYXJvbikNCkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJp bmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFttcGxzXSBbQUhNUExT LVRQXSBSOiBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbmRyYWZ0LWlldGYtbXBscy10cC1yaW5n LXByb3RlY3Rpb24NCiANCkRlYXIgTnVyaXQ6DQogDQogICAgICAgQ2hpbmEgTW9iaWxlIHByZXNl bnRlZCBzZXZlcmFsIGNvbnRyaWJ1dGlvbnMgYWJvdXQgcmluZyBwcm90ZWN0aW9uIGluIGxhc3Qg SVRVLVQgU0cxNSBwbGVuYXJ5IG1lZXRpbmcuIFdlIGNvbXBhcmVkIHRoZSBjb21wbGV4aXR5IGFu ZCByZXNvdXJjZXMgcmVxdWlyZW1lbnQgKGxhYmVscyBhbmQgT0FNIHNlc3Npb25zKSBvZiBkaWZm ZXJlbnQgc2NoZW1lcy4gQWZ0ZXIgZGlzY3Vzc2lvbiwgd2Ugc3VtbWVyaXplZCB0aGUgcmVxdWly ZW1lbnRzIGluIHRoZSBsaWFzb24gdG8gSUVURi4gVGhhbmsgeW91IQ0KIA0KQmVzdCByZWdhcmRz LA0KIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIYW4gTGkNCg0KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKg0KSGFuIExpLCBQaC5EIA0KQ2hpbmEgTW9iaWxlIFJlc2VhcmNoIEluc3RpdHV0ZQ0KMzIg WHVhbnd1bWVuIFdlc3QgU3RyZWV0LCBYaWNoZW5nIERpc3RyaWN0LCBCZWlqaW5nIDEwMDA1Mywg Q2hpbmEgDQpGYXg6ICs4NiAxMCA2MzEzNTE1OSANCk1PQklMRTogMTM1MDEwOTMzODUgDQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQoNCi0tLSAxMuW5tDEw5pyIMuaXpe+8jOWRqOS6jCwgU3ByZWNoZXIsIE51 cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pIDxudXJpdC5zcHJlY2hlckBuc24uY29tPiDlhpnp gZPvvJoNCg0K5Y+R5Lu25Lq6OiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJv bikgPG51cml0LnNwcmVjaGVyQG5zbi5jb20+DQrkuLvpopg6IFJFOiBbbXBsc10gW0FITVBMUy1U UF0gUjogV29ya2luZyBncm91cCBsYXN0IGNhbGwgb25kcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1w cm90ZWN0aW9uDQrmlLbku7bkuro6ICJleHQgTGFycnkiIDxsYXJyeWxpODg4QHlhaG9vLmNvbS5j bj4sICJEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvIiA8YWxlc3NhbmRyby5kYWxlc3Nh bmRyb0B0ZWxlY29taXRhbGlhLml0PiwgaHV1YmF0d29ya0BnbWFpbC5jb20NCuaKhOmAgTogbXBs c0BpZXRmLm9yZywgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcsICJNUExTLVRQIGFkIGhvYyB0 ZWFtIiA8YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQ+LCBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1w cm90ZWN0aW9uQHRvb2xzLmlldGYub3JnDQrml6XmnJ86IDIwMTLlubQxMOaciDLml6Us5ZGo5LqM LOS4i+WNiDEwOjUwDQpEZWFyIEhhbiBMaSwNClRoYW5rcyBmb3IgeW91ciBjb21tZW50LiANCsK3 ICAgICAgICAgQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbiB3aHkgZG8geW91IHRoaW5rIHRoZXJlIGFy ZSByaXNrcyB0aGF0IHByb3RlY3Rpb24gc3dpdGNoIHRpbWUgZXhjZWVkcyA1MG1zICgiZnJvbSB0 aGUgbW9tZW50IG9mIGZhdWx0IGRldGVjdGlvbiBpbiBhICAgICAgICAgbmV0d29yayB3aXRoIGEg MTYtbm9kZSByaW5nIHdpdGggbGVzcyB0aGFuIDEyMDAga20gb2YgZmliZXIiIGFzIHJlcXVpcmVk IGluIFJGQyA1NjU0KT8gV2hhdCBpbiB0aGUgcHJvcG9zZWQgc29sdXRpb24gbWFrZSB5b3UgdGhp bmsgdGhlcmUgYXJlIHJpc2tzPyANCsK3ICAgICAgICAgQ2FuIHlvdSBwbGVhc2UgaW5kaWNhdGUg d2h5IGRvIHlvdSB0aGluayB0aGUgY29uZmlndXJhdGlvbiBpcyB0b28gY29tcGxleCBhbmQgd2h5 IGl0IHJlcXVpcmVzIHRvbyBtYW55IGxhYmVscyBhbmQgT0FNIHNlc3Npb25zLi4uYW5kIGhvdyBk byB5b3UgdGhpbmsgdGhpcyBjb3VsZCBiZSBiZXR0ZXIgb3B0aW1pemVkPyANCkluIG9yZGVyIHRv IHJlZmVyIHRvIHRoaXMgYXMgYSBMQyBjb21tZW50LCB0aGUgdGVjaG5pY2FsIGFyZ3VtZW50cyBz aG91bGQgYmUgcHJlc2VudGVkIGFuZCBlbGFib3JhdGVkLiANClRoYW5rcyBhbmQgYmVzdCByZWdh cmRzLA0KTnVyaXQNCiANCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBleHQgTGFycnkNClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDIsIDIwMTIgMTI6NDEgUE0NClRv OiBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvOyBodXViYXR3b3JrQGdtYWlsLmNvbQ0K Q2M6IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBNUExTLVRQIGFk IGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYu b3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIFtBSE1QTFMtVFBdIFI6IFdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KIA0Kbm90IHN1cHBv cnQhDQpJdCBkb2Vzbid0IHNhdGlzZnkgc29tZSByZXF1aXJlbWVudHMgb2YgdGhlIG9wZXJhdG9y cy4gVGhlIGNvbmZpZ3VyYXRpb24gaXMgdG9vIGNvbXBsZXggYW5kIG5lZWRzIHRvbyBtYW55IGxh YmVscyBhbmQgT0FNIHNlc3Npb25zLiBUaGVyZSBhcmUgcmlza3MgdGhhdCBwcm90ZWN0aW9uIHN3 aXRjaCB0aW1lIGV4Y2VlZCA1MG1zLg0KIA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KSGFuIExpLCBQaC5E IA0KQ2hpbmEgTW9iaWxlIFJlc2VhcmNoIEluc3RpdHV0ZQ0KMzIgWHVhbnd1bWVuIFdlc3QgU3Ry ZWV0LCBYaWNoZW5nIERpc3RyaWN0LCBCZWlqaW5nIDEwMDA1MywgQ2hpbmEgDQpGYXg6ICs4NiAx MCA2MzEzNTE1OSANCk1PQklMRTogMTM1MDEwOTMzODUgDQoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogDQog DQotLS0gMTLlubQxMOaciDLml6XvvIzlkajkuowsIEh1dWIgdmFuIEhlbHZvb3J0IDxodXViYXR3 b3JrQGdtYWlsLmNvbT4g5YaZ6YGT77yaDQogDQo+IOWPkeS7tuS6ujogSHV1YiB2YW4gSGVsdm9v cnQgPGh1dWJhdHdvcmtAZ21haWwuY29tPg0KPiDkuLvpopg6IFJlOiBbbXBsc10gW0FITVBMUy1U UF0gUjogV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmct cHJvdGVjdGlvbg0KPiDmlLbku7bkuro6ICJEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRv IiA8YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0Pg0KPiDmioTpgIE6ICJt cGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4sICJtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y ZyIgPG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPiwgIk1QTFMtVFAgYWQgaG9jIHRlYW0iIDxh aG1wbHMtdHBAbGlzdHMuaXR1LmludD4sICJkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0 aW9uQHRvb2xzLmlldGYub3JnIiA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0 b29scy5pZXRmLm9yZz4NCj4g5pel5pyfOiAyMDEy5bm0MTDmnIgy5pelLOWRqOS6jCzkuIvljYg1 OjAyDQo+IERvIG5vdCBzdXBwb3J0Lg0KPiANCj4gU2FtZSByZWFzb25zIGFzIG1lbnRpb25lZCBi ZWxvdy4NCj4gDQo+IFJlZ2FyZHMsIEh1dWIuDQo+IA0KPiBPbiAwMS0xMC0xMiAxNDoyNywgRCdB bGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbyB3cm90ZToNCj4gPiBEbyBub3Qgc3VwcG9ydA0K PiA+DQo+ID4gQWNjb3JkaW5nIHRvIHRoZSBvcHRpbWl6YXRpb24gY3JpdGVyaWEgZm9yIHJpbmcN Cj4gcHJvdGVjdGlvbiBzcGVjaWZpZWQgaW4gU2VjdGlvbiAyLjUuNi4xIGluIFJGQzU2NTQsIHRo ZQ0KPiBNUExTLVRQIHJpbmcgcHJvdGVjdGlvbiBzaG91bGQgYmUgb3B0aW1pemVkIGZvcg0KPiBz aW1wbGlmaWNhdGlvbiBvZiB0aGUgcmluZyBvcGVyYXRpb24gYW5kIHRoZSByZXNvdXJjZXMNCj4g Y29uc3VtcHRpb24gYXJvdW5kIHRoZSByaW5nLiBJdCBpcyBub3QgdGhlIGNhc2Ugb2YgdGhlDQo+ IHByb3Bvc2VkIHNvbHV0aW9uLg0KPiA+IEl0IGlzIGFjdHVhbGx5IHNpbXBseSBhbiBhcHBsaWNh YmlsaXR5IHN0YXRlbWVudCBvZiBhDQo+IGxpbmVhciBwcm90ZWN0aW9uIG1lY2hhbmlzbSBidXQg aXQgY2Fubm90IGJlIGNvbnNpZGVyIGENCj4gc29sdXRpb24gdGhhdCBhZGRyZXNzZXMgdGhlIHJl cXVpcmVtZW50cyBmb3IgcHJvdGVjdGlvbiBvZg0KPiByaW5nIHRvcG9sb2dpZXMgZm9yIE11bHRp LVByb3RvY29sIExhYmVsIFN3aXRjaGluZyBUcmFuc3BvcnQNCj4gUHJvZmlsZSAoTVBMUy1UUCkg YXMgc3BlY2lmaWVkIGluIFJGQzU2NTQuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gQWxl c3NhbmRybw0KPiA+DQo+ID4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gVGVsZWNvbSBJdGFsaWENCj4gPiBB bGVzc2FuZHJvIEdlcmFyZG8gRCdBbGVzc2FuZHJvDQo+ID4gVHJhbnNwb3J0IElubm92YXRpb24N Cj4gPiBWaWEgUmVpc3MgUm9tb2xpLCAyNzQgLSAxMDE0OCBUb3Jpbm8NCj4gPiBwaG9uZTogICsz OSAwMTEgMjI4IDU4ODcNCj4gPiBtb2JpbGU6ICszOSAzMzUgNzY2IDk2MDcNCj4gPiBmYXg6ICsz OSAwNiA0MTggNjM5IDA3DQo+ID4NCj4gPg0KPiA+IC0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0t LS0tDQo+ID4gRGE6IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KPiBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ10NCj4gUGVyIGNvbnRvIGRpIEhlamlhDQo+ID4gSW52aWF0bzogc2FiYXRvIDI5 IHNldHRlbWJyZSAyMDEyIDEyOjUzDQo+ID4gQTogTG9hIEFuZGVyc3Nvbg0KPiA+IENjOiBtcGxz QGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsNCj4gTVBMUy1UUCBhZCBob2Mg dGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZw0K PiA+IE9nZ2V0dG86IFJlOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj4gZHJh ZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KPiA+DQo+ID4gRG8gbm90IHN1cHBvcnQu DQo+ID4NCj4gPiBCYXNlZCBvbiB0aGUgYW5hbHlzaXMgaW4gU2VjdGlvbiAyLjQgb2YNCj4gZHJh ZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMiwgdGhlIHJpbmcgcHJvdGVjdGlvbg0K PiBzY2hlbWUgdXNpbmcgU1BNRSBhcyBkZXNjcmliZWQsIGVpdGhlciB3cmFwcGluZyBvciBzdGVl cmluZywNCj4gZG9lcyBoYXZlIGRlZmljaWVuY2llcywgd2hpY2ggSU1ITyBzaG91bGQgYmUgYmV0 dGVyDQo+IHJlY29uc2lkZXJlZCBhbmQgc29sdmVkIGlmIHBvc3NpYmxlLg0KPiA+DQo+ID4NCj4g PiBCLlIuDQo+ID4gSmlhDQo+ID4NCj4gPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4g5Y+R 5Lu25Lq6OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCj4gW21haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmddDQo+IOS7o+ihqCBMb2EgQW5kZXJzc29uDQo+ID4g5Y+R6YCB5pe26Ze0OiAyMDEy5bm0 OeaciDE55pelIDE4OjQ5DQo+ID4g5oqE6YCBOiBtcGxzQGlldGYub3JnOw0KPiBNUExTLVRQIGFk IGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYu b3JnOw0KPiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiA+IOS4u+mimDogW21wbHNdIFdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQo+IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3Rl Y3Rpb24NCj4gPg0KPiA+IFdvcmtpbmcgR3JvdXAsDQo+ID4NCj4gPiB0aGlzIGlzIHRvIHN0YXJ0 IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj4gPiBkcmFmdC1pZXRmLW1w bHMtdHAtcmluZy1wcm90ZWN0aW9uLTAyLXR4dC4NCj4gPg0KPiA+IFBsZWFzZSBub3RlIHRoYXQg dGhlcmUgYXJlIHR3byBJUFIgZGlzY2xvc3VyZXMgIyAxNDYyDQo+IGFuZCAgIyAxODcyDQo+ID4g cmVsYXRlZCB0byB0aGlzIGRvY3VtZW50Lg0KPiA+DQo+ID4gUGxlYXNlIHNlbmQgeW91ciBjb21t ZW50cyB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwDQo+IG1haWxpbmcgbGlzdHMNCj4gPiAobXBs c0BpZXRmLm9yZykuDQo+ID4NCj4gPiBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBP Y3RvYmVyIDMsIDIwMTIuDQo+ID4NCj4gPiAvTG9hDQo+ID4gZm9yIHRoZSBtcGxzIHdnIGNvLWNo YWlycw0KPiA+DQo+ID4NCj4gPiAtLQ0KPiA+DQo+ID4NCj4gPiBMb2EgQW5kZXJzc29uICAgICAg ICAgICANCj4gICAgICAgICAgICAgIGVtYWlsOg0KPiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNv bQ0KPiA+IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgDQo+ICAgICAgIGxv YUBwaS5udQ0KPiA+IEVyaWNzc29uIEluYyAgICAgICAgICAgDQo+ICAgICAgICAgICAgICAgcGhv bmU6ICs0Ng0KPiAxMCA3MTcgNTIgMTMNCj4gPiAgICAgICAgICAgICAgIA0KPiAgICAgICAgICAg ICAgICANCj4gICAgICAgICAgICAgICAgICs0Ng0KPiA3NjcgNzIgOTIgMTMNCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG1wbHMgbWFpbGlu ZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscyA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzPiANCj4gDQo+IC0tIA0KPiAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiAgICAgICAg ICAgIA0KPiAgICDor7forrDkvY/vvIzkvaDmmK/ni6zkuIDml6DkuoznmoTvvIzlsLHlg4/lhbbk u5bmr4/kuIDkuKrkurrkuIDmoLcNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMgPGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscz4gDQo+IA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMgPGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscz4gDQogDQo= ------_=_NextPart_001_01CDA130.8FCCBC35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPVByb2dJZCBjb250ZW50PVdv cmQuRG9jdW1lbnQ+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQg MTIiPjxtZXRhIG5hbWU9T3JpZ2luYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiI+PGxp bmsgcmVsPUZpbGUtTGlzdCBocmVmPSJjaWQ6ZmlsZWxpc3QueG1sQDAxQ0RBMTQxLjUyQTUxODcw Ij48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8 bzpBbGxvd1BORy8+DQo8bzpUYXJnZXRTY3JlZW5TaXplPjEwMjR4NzY4PC9vOlRhcmdldFNjcmVl blNpemU+DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6Wm9vbT4xMjA8L3c6 Wm9vbT4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNr TW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlk YXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZY TUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29u dGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1Bs YWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4t VVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WC1OT05FPC93OkxpZFRoZW1l QXNpYW4+DQo8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+SEU8L3c6TGlkVGhlbWVDb21wbGV4U2Ny aXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6 QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkRv bnRWZXJ0QWxpZ25DZWxsV2l0aFNwLz4NCjx3OkRvbnRCcmVha0NvbnN0cmFpbmVkRm9yY2VkVGFi bGVzLz4NCjx3OkRvbnRWZXJ0QWxpZ25JblR4YngvPg0KPHc6V29yZDExS2VybmluZ1BhaXJzLz4N Cjx3OkNhY2hlZENvbEJhbGFuY2UvPg0KPC93OkNvbXBhdGliaWxpdHk+DQo8dzpCcm93c2VyTGV2 ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8L3c6QnJvd3NlckxldmVsPg0KPG06bWF0aFBy Pg0KPG06bWF0aEZvbnQgbTp2YWw9IkNhbWJyaWEgTWF0aCIvPg0KPG06YnJrQmluIG06dmFsPSJi ZWZvcmUiLz4NCjxtOmJya0JpblN1YiBtOnZhbD0iJiM0NTstIi8+DQo8bTpzbWFsbEZyYWMgbTp2 YWw9Im9mZiIvPg0KPG06ZGlzcERlZi8+DQo8bTpsTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpyTWFy Z2luIG06dmFsPSIwIi8+DQo8bTpkZWZKYyBtOnZhbD0iY2VudGVyR3JvdXAiLz4NCjxtOndyYXBJ bmRlbnQgbTp2YWw9IjE0NDAiLz4NCjxtOmludExpbSBtOnZhbD0ic3ViU3VwIi8+DQo8bTpuYXJ5 TGltIG06dmFsPSJ1bmRPdnIiLz4NCjwvbTptYXRoUHI+PC93OldvcmREb2N1bWVudD4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6TGF0ZW50U3R5bGVzIERl ZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVmVW5oaWRlV2hlblVzZWQ9InRydWUiIERlZlNlbWlIaWRk ZW49InRydWUiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxl Q291bnQ9IjI2NyI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUi IE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3Jt YXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0 b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIxMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjIiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0 cm9uZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NTkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlRhYmxl IEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2Vu dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3Jh cGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9 IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNo YWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ikxp Z2h0IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlk IDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsg TGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExp c3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5n IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBM aXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdo dCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFj Y2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3Qg QWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVs IFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBM aXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBB Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3Jp ZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2Vu dCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFk aW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xv cmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjE5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRs ZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFFGb3JtYXQ9InRydWUiIE5h bWU9IlRPQyBIZWFkaW5nIi8+DQo8L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+ PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7DQoJbXNv LWZvbnQtYWx0OiLvvK3vvLMg44K044K344OD44KvIjsNCgltc28tZm9udC1jaGFyc2V0OjEyODsN Cgltc28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6Zml4ZWQ7 DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTc5MTQ5MTU3OSAxOCAwIDEzMTIzMSAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWluZ0xpVTsNCglwYW5vc2UtMToyIDIgNSA5 IDAgMCAwIDAgMCAwOw0KCW1zby1mb250LWFsdDrntLDmmI7pq5Q7DQoJbXNvLWZvbnQtY2hhcnNl dDoxMzY7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6bW9kZXJuOw0KCW1zby1mb250LXBpdGNo OmZpeGVkOw0KCW1zby1mb250LXNpZ25hdHVyZTotMTYxMDYxMTk2OSA2ODQ3MTkzNTQgMjIgMCAx MDQ4NTc3IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0Ow0KCW1zby1mb250LWFsdDoiQ2FsaXN0byBNVCI7 DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJvbWFuOw0K CW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODcwMTQ1 IDExMDczMDU3MjcgMCAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1hbHQ6Q2FsaWJy aTsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7 DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwOTI5 MjkgMTA3Mzc4NjExMSA5IDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhv bWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQtYWx0OlZlcmRh bmE7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNz Ow0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTIwMDgx NjY1IC0xMDczNzE3MTU3IDQxIDAgNjYwNDcgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWNo YXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0 Y2g6Zml4ZWQ7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwOTI5MjkgMTA3MzgwNjU5MSA5IDAg NDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNaW5nTGlVIjsNCglwYW5vc2Ut MToyIDIgNSA5IDAgMCAwIDAgMCAwOw0KCW1zby1mb250LWNoYXJzZXQ6MTM2Ow0KCW1zby1nZW5l cmljLWZvbnQtZmFtaWx5Om1vZGVybjsNCgltc28tZm9udC1waXRjaDpmaXhlZDsNCgltc28tZm9u dC1zaWduYXR1cmU6LTE2MTA2MTE5NjkgNjg0NzE5MzU0IDIyIDAgMTA0ODU3NyAwO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3 IDIgNSA4IDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjEyODsNCgltc28tZ2VuZXJpYy1mb250LWZh bWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6Zml4ZWQ7DQoJbXNvLWZvbnQtc2lnbmF0dXJl Oi01MzY4NzAxNDUgMTc5MTQ5MTU3OSAxOCAwIDEzMTIzMSAwO30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1z dHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJl bnQ6IiI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2lu YXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGlu ZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0K cC55aXY5MzQwNjcwNzhtc29wbGFpbnRleHQsIGxpLnlpdjkzNDA2NzA3OG1zb3BsYWludGV4dCwg ZGl2LnlpdjkzNDA2NzA3OG1zb3BsYWludGV4dA0KCXttc28tc3R5bGUtbmFtZTp5aXY5MzQwNjcw Nzhtc29wbGFpbnRleHQ7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KcC55aXY5MzQwNjcwNzhtc29hY2V0 YXRlLCBsaS55aXY5MzQwNjcwNzhtc29hY2V0YXRlLCBkaXYueWl2OTM0MDY3MDc4bXNvYWNldGF0 ZQ0KCXttc28tc3R5bGUtbmFtZTp5aXY5MzQwNjcwNzhtc29hY2V0YXRlOw0KCW1zby1zdHlsZS11 bmhpZGU6bm87DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJbXNvLXBh Z2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpO30NCnAueWl2OTM0MDY3MDc4bXNvbm9ybWFsLCBsaS55aXY5MzQwNjcwNzhtc29ub3JtYWws IGRpdi55aXY5MzQwNjcwNzhtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6eWl2OTM0MDY3MDc4 bXNvbm9ybWFsOw0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCnNwYW4ueWl2OTM0MDY3MDc4bXNvaHlwZXJs aW5rDQoJe21zby1zdHlsZS1uYW1lOnlpdjkzNDA2NzA3OG1zb2h5cGVybGluazsNCgltc28tc3R5 bGUtdW5oaWRlOm5vO30NCnNwYW4ueWl2OTM0MDY3MDc4bXNvaHlwZXJsaW5rZm9sbG93ZWQNCgl7 bXNvLXN0eWxlLW5hbWU6eWl2OTM0MDY3MDc4bXNvaHlwZXJsaW5rZm9sbG93ZWQ7DQoJbXNvLXN0 eWxlLXVuaGlkZTpubzt9DQpzcGFuLnlpdjkzNDA2NzA3OHBsYWludGV4dGNoYXINCgl7bXNvLXN0 eWxlLW5hbWU6eWl2OTM0MDY3MDc4cGxhaW50ZXh0Y2hhcjsNCgltc28tc3R5bGUtdW5oaWRlOm5v O30NCnNwYW4ueWl2OTM0MDY3MDc4YmFsbG9vbnRleHRjaGFyDQoJe21zby1zdHlsZS1uYW1lOnlp djkzNDA2NzA3OGJhbGxvb250ZXh0Y2hhcjsNCgltc28tc3R5bGUtdW5oaWRlOm5vO30NCnAueWl2 OTM0MDY3MDc4bXNvbm9ybWFsMSwgbGkueWl2OTM0MDY3MDc4bXNvbm9ybWFsMSwgZGl2Lnlpdjkz NDA2NzA3OG1zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2OTM0MDY3MDc4bXNvbm9ybWFs MTsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLnlpdjkzNDA2NzA3OG1zb2h5cGVybGluazENCgl7bXNv LXN0eWxlLW5hbWU6eWl2OTM0MDY3MDc4bXNvaHlwZXJsaW5rMTsNCgltc28tc3R5bGUtdW5oaWRl Om5vOw0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVu ZGVybGluZTpzaW5nbGU7fQ0Kc3Bhbi55aXY5MzQwNjcwNzhtc29oeXBlcmxpbmtmb2xsb3dlZDEN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2OTM0MDY3MDc4bXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0KCW1z by1zdHlsZS11bmhpZGU6bm87DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnAueWl2OTM0MDY3MDc4bXNvcGxhaW50 ZXh0MSwgbGkueWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0MSwgZGl2LnlpdjkzNDA2NzA3OG1zb3Bs YWludGV4dDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0MTsNCglt c28tc3R5bGUtdW5oaWRlOm5vOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0K cC55aXY5MzQwNjcwNzhtc29hY2V0YXRlMSwgbGkueWl2OTM0MDY3MDc4bXNvYWNldGF0ZTEsIGRp di55aXY5MzQwNjcwNzhtc29hY2V0YXRlMQ0KCXttc28tc3R5bGUtbmFtZTp5aXY5MzQwNjcwNzht c29hY2V0YXRlMTsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNp emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi55aXY5MzQwNjcwNzhwbGFpbnRleHRjaGFy MQ0KCXttc28tc3R5bGUtbmFtZTp5aXY5MzQwNjcwNzhwbGFpbnRleHRjaGFyMTsNCgltc28tc3R5 bGUtdW5oaWRlOm5vOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1hc2NpaS1mb250LWZh bWlseTpDb25zb2xhczsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi55aXY5MzQwNjcwNzhiYWxsb29udGV4dGNo YXIxDQoJe21zby1zdHlsZS1uYW1lOnlpdjkzNDA2NzA3OGJhbGxvb250ZXh0Y2hhcjE7DQoJbXNv LXN0eWxlLXVuaGlkZTpubzsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWFzY2lpLWZvbnQtZmFtaWx5OlRhaG9tYTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6VGFo b21hOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OlRhaG9tYTt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28tc3R5bGUtbm9zaG93OnllczsN Cgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJbXNv LWJpZGktZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlNwZWxsRQ0KCXtt c28tc3R5bGUtbmFtZToiIjsNCgltc28tc3BsLWU6eWVzO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCgltc28t YXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OkFyaWFsOw0KCW1zby1iaWRpLWxhbmd1YWdlOkFSLVNBO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 DQoJbXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCgltc28tZm9vdGVyLW1hcmdpbjouNWluOw0KCW1z by1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBO b3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5k LXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbXNvLXBh ZGRpbmctYWx0OjBpbiA1LjRwdCAwaW4gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBpbjsNCglt c28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3Jw aGFuOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNCgltc28tYmlkaS1s YW5ndWFnZTpBUi1TQTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1i bHVlIHZsaW5rPXB1cnBsZSBzdHlsZT0ndGFiLWludGVydmFsOi41aW4nPjxkaXYgY2xhc3M9V29y ZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOiMxRjQ5N0QnPkRlYXIgSGFuIExpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDtjb2xv cjojMUY0OTdEJz5UaGFua3MgZm9yIHlvdXIgaW50cm9kdWN0aW9uLiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6IzFGNDk3RCc+T2J2aW91c2x5IGl0IGlzIG5vdCBwb3NzaWJsZSB0byByZWZlciBv ciBkaXNjdXNzIHNvbWV0aGluZyB0aGF0IGhhcyBub3QgYmVlbiBwb3N0ZWQgb3IgcHJlc2VudGVk 4oCmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28t YmlkaS1mb250LWZhbWlseTpBcmlhbDtjb2xvcjojMUY0OTdEJz5CZXN0IHJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOiMxRjQ5N0QnPk51cml0PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjttc28tZmFyZWFzdC1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjttc28tZmFyZWFzdC1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+IGV4dCBMYXJyeSBbbWFpbHRvOmxhcnJ5bGk4 ODhAeWFob28uY29tLmNuXSA8YnI+PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgT2N0b2JlciAwMywg MjAxMiAyOjU5IEFNPGJyPjxiPlRvOjwvYj4gRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJk bzsgaHV1YmF0d29ya0BnbWFpbC5jb207IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhh U2hhcm9uKTxicj48Yj5DYzo8L2I+IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnOyBNUExTLVRQIGFkIGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90 ZWN0aW9uQHRvb2xzLmlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogW21wbHNdIFtBSE1Q TFMtVFBdIFI6IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLXJp bmctcHJvdGVjdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRl cj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCBzdHlsZT0nbXNvLWNlbGxzcGFjaW5nOjBp bjttc28teWZ0aS10Ymxsb29rOjExODQ7bXNvLXBhZGRpbmctYWx0OjBpbiAwaW4gMGluIDBpbic+ PHRyIHN0eWxlPSdtc28teWZ0aS1pcm93OjA7bXNvLXlmdGktZmlyc3Ryb3c6eWVzO21zby15ZnRp LWxhc3Ryb3c6eWVzJz48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAw aW4nPjxwIGNsYXNzPU1zb05vcm1hbD5EZWFyIE51cml0OjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NoaW5hIE1vYmlsZSBwcmVzZW50 ZWQgc2V2ZXJhbCBjb250cmlidXRpb25zIGFib3V0IHJpbmcgcHJvdGVjdGlvbiBpbiBsYXN0IElU VS1UIFNHMTUgcGxlbmFyeSBtZWV0aW5nLiBXZSBjb21wYXJlZCB0aGUgY29tcGxleGl0eSBhbmQg cmVzb3VyY2VzIHJlcXVpcmVtZW50IChsYWJlbHMgYW5kIE9BTSBzZXNzaW9ucykgb2YgZGlmZmVy ZW50IHNjaGVtZXMuIEFmdGVyIGRpc2N1c3Npb24sIHdlIHN1bW1lcml6ZWQgdGhlIHJlcXVpcmVt ZW50cyBpbiB0aGUgbGlhc29uIHRvIElFVEYuIFRoYW5rIHlvdSE8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtIYW4gTGk8YnI+PGJyPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+SGFuIExpLCBQaC5EIDxicj5D aGluYSBNb2JpbGUgUmVzZWFyY2ggSW5zdGl0dXRlPGJyPjMyIFh1YW53dW1lbiBXZXN0IFN0cmVl dCwgWGljaGVuZyBEaXN0cmljdCwgQmVpamluZyAxMDAwNTMsIENoaW5hIDxicj5GYXg6ICs4NiAx MCA2MzEzNTE1OSA8YnI+TU9CSUxFOiAxMzUwMTA5MzM4NSA8YnI+KioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxi cj48YnI+LS0tIDxiPjEyPC9iPjxiPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290aGlj Ijttc28tYmlkaS1mb250LWZhbWlseToiTVMgR290aGljIic+5bm0PC9zcGFuPjEwPC9iPjxiPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290aGljIjttc28tYmlkaS1mb250LWZhbWlseToi TVMgR290aGljIic+5pyIPC9zcGFuPjI8L2I+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJN UyBHb3RoaWMiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7ml6XvvIzlkajkuow8 L3NwYW4+LCBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbikgPGk+Jmx0Ozxh IGhyZWY9Im1haWx0bzpudXJpdC5zcHJlY2hlckBuc24uY29tIj5udXJpdC5zcHJlY2hlckBuc24u Y29tPC9hPiZndDs8L2k+PC9iPiA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7 bXNvLWJpZGktZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuWGmemBk++8mjwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48 YnI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5Ok1pbmdMaVU7bXNvLWJpZGktZm9udC1mYW1pbHk6 TWluZ0xpVSc+5Y+R5Lu25Lq6PC9zcGFuPjogU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2Qg SGFTaGFyb24pICZsdDs8YSBocmVmPSJtYWlsdG86bnVyaXQuc3ByZWNoZXJAbnNuLmNvbSI+bnVy aXQuc3ByZWNoZXJAbnNuLmNvbTwvYT4mZ3Q7PGJyPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi TVMgR290aGljIjttc28tYmlkaS1mb250LWZhbWlseToiTVMgR290aGljIic+5Li7PC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseTpNaW5nTGlVO21zby1iaWRpLWZvbnQtZmFtaWx5Ok1pbmdM aVUnPumimDwvc3Bhbj46IFJFOiBbbXBsc10gW0FITVBMUy1UUF0gUjogV29ya2luZyBncm91cCBs YXN0IGNhbGwgb25kcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uPGJyPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiTVMgR290aGljIjttc28tYmlkaS1mb250LWZhbWlseToiTVMgR290 aGljIic+5pS25Lu25Lq6PC9zcGFuPjogJnF1b3Q7ZXh0IExhcnJ5JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bGFycnlsaTg4OEB5YWhvby5jb20uY24iPmxhcnJ5bGk4ODhAeWFob28uY29tLmNu PC9hPiZndDssICZxdW90O0QnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzphbGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXQi PmFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdDwvYT4mZ3Q7LCA8YSBocmVm PSJtYWlsdG86aHV1YmF0d29ya0BnbWFpbC5jb20iPmh1dWJhdHdvcmtAZ21haWwuY29tPC9hPjxi cj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7bXNvLWJpZGktZm9udC1mYW1p bHk6Ik1TIEdvdGhpYyInPuaKhOmAgTwvc3Bhbj46IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYu b3JnIj5tcGxzQGlldGYub3JnPC9hPiwgPGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnIj5tcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT4sICZxdW90O01QTFMtVFAg YWQgaG9jIHRlYW0mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphaG1wbHMtdHBAbGlzdHMuaXR1 LmludCI+YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQ8L2E+Jmd0OywgPGEgaHJlZj0ibWFpbHRvOmRy YWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWll dGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiTVMgR290aGljIjttc28tYmlkaS1mb250LWZhbWlseToiTVMgR290 aGljIic+5pel5pyfPC9zcGFuPjogMjAxMjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290 aGljIjttc28tYmlkaS1mb250LWZhbWlseToiTVMgR290aGljIic+5bm0PC9zcGFuPjEwPHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJNUyBH b3RoaWMiJz7mnIg8L3NwYW4+MjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290aGljIjtt c28tYmlkaS1mb250LWZhbWlseToiTVMgR290aGljIic+5pelPC9zcGFuPiw8c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7bXNvLWJpZGktZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyIn PuWRqOS6jDwvc3Bhbj4sPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiO21zby1i aWRpLWZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7kuIvljYg8L3NwYW4+MTA6NTA8bzpwPjwvbzpw PjwvcD48ZGl2IGlkPXlpdjkzNDA2NzA3OD48ZGl2PjxkaXY+PHAgY2xhc3M9eWl2OTM0MDY3MDc4 bXNvcGxhaW50ZXh0PkRlYXIgSGFuIExpLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2 NzA3OG1zb3BsYWludGV4dCBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0aWZ5Jz5UaGFua3MgZm9yIHlv dXIgY29tbWVudC4gPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50 ZXh0IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6U3lt Ym9sJz7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0Jz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPkNhbiB5b3UgcGxlYXNl IGV4cGxhaW4gd2h5IGRvIHlvdSB0aGluayB0aGVyZSBhcmUgcmlza3MgdGhhdCBwcm90ZWN0aW9u IHN3aXRjaCB0aW1lIGV4Y2VlZHMgNTBtcyAoJnF1b3Q7ZnJvbSB0aGUgbW9tZW50IG9mIGZhdWx0 IGRldGVjdGlvbiBpbiBhICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO25ldHdvcmsgd2l0aCBhIDE2LW5vZGUgcmluZyB3aXRoIGxlc3MgdGhhbiAxMjAwIGtt IG9mIGZpYmVyJnF1b3Q7IGFzIHJlcXVpcmVkIGluIFJGQyA1NjU0KT8gV2hhdCBpbiB0aGUgcHJv cG9zZWQgc29sdXRpb24gbWFrZSB5b3UgdGhpbmsgdGhlcmUgYXJlIHJpc2tzPyA8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQgc3R5bGU9J21hcmdpbi1sZWZ0 Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpTeW1ib2wnPsK3PC9zcGFuPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+Q2FuIHlvdSBwbGVhc2UgaW5kaWNhdGUgd2h5IGRvIHlvdSB0 aGluayB0aGUgY29uZmlndXJhdGlvbiBpcyB0b28gY29tcGxleCBhbmQgd2h5IGl0IHJlcXVpcmVz IHRvbyBtYW55IGxhYmVscyBhbmQgT0FNIHNlc3Npb25zLi4uYW5kIGhvdyBkbyB5b3UgdGhpbmsg dGhpcyBjb3VsZCBiZSBiZXR0ZXIgb3B0aW1pemVkPyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15 aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+SW4gb3JkZXIgdG8gcmVmZXIgdG8gdGhpcyBhcyBhIExD IGNvbW1lbnQsIHRoZSB0ZWNobmljYWwgYXJndW1lbnRzIHNob3VsZCBiZSBwcmVzZW50ZWQgYW5k IGVsYWJvcmF0ZWQuIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWlu dGV4dD5UaGFua3MgYW5kIGJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5 MzQwNjcwNzhtc29wbGFpbnRleHQ+TnVyaXQ8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQw NjcwNzhtc29wbGFpbnRleHQ+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3 MDc4bXNvcGxhaW50ZXh0IHN0eWxlPSdtc28tb3V0bGluZS1sZXZlbDoxJz4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj5Gcm9tOiA8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnIj5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxm IE9mIGV4dCBMYXJyeTxicj5TZW50OiBUdWVzZGF5LCBPY3RvYmVyIDAyLCAyMDEyIDEyOjQxIFBN PGJyPlRvOiBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvOyA8YSBocmVmPSJtYWlsdG86 aHV1YmF0d29ya0BnbWFpbC5jb20iPmh1dWJhdHdvcmtAZ21haWwuY29tPC9hPjxicj5DYzogPGEg aHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt YWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnPC9hPjsgTVBMUy1UUCBhZCBob2MgdGVhbTsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYt bXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtbXBscy10 cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPlN1YmplY3Q6IFJlOiBbbXBs c10gW0FITVBMUy1UUF0gUjogV29ya2luZyBncm91cCBsYXN0IGNhbGwgb25kcmFmdC1pZXRmLW1w bHMtdHAtcmluZy1wcm90ZWN0aW9uPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4 bXNvcGxhaW50ZXh0PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1z b3BsYWludGV4dD5ub3Qgc3VwcG9ydCE8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcw Nzhtc29wbGFpbnRleHQ+SXQgZG9lc24ndCBzYXRpc2Z5IHNvbWUgcmVxdWlyZW1lbnRzIG9mIHRo ZSBvcGVyYXRvcnMuIFRoZSBjb25maWd1cmF0aW9uIGlzIHRvbyBjb21wbGV4IGFuZCBuZWVkcyB0 b28gbWFueSBsYWJlbHMgYW5kIE9BTSBzZXNzaW9ucy4gVGhlcmUgYXJlIHJpc2tzIHRoYXQgcHJv dGVjdGlvbiBzd2l0Y2ggdGltZSBleGNlZWQgNTBtcy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15 aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2 OTM0MDY3MDc4bXNvcGxhaW50ZXh0PioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+SGFuIExpLCBQaC5EIDxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD5DaGluYSBNb2JpbGUgUmVzZWFyY2gg SW5zdGl0dXRlPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0 PjMyIFh1YW53dW1lbiBXZXN0IFN0cmVldCwgWGljaGVuZyBEaXN0cmljdCwgQmVpamluZyAxMDAw NTMsIENoaW5hIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4 dD5GYXg6ICs4NiAxMCA2MzEzNTE1OSA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcw Nzhtc29wbGFpbnRleHQ+TU9CSUxFOiAxMzUwMTA5MzM4NSA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jm5ic3A7PG86cD48L286cD48L3A+PHAg Y2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0Pi0tLSAxMjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiTVMgR290aGljIic+5bm0PC9zcGFuPjEwPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJN UyBHb3RoaWMiJz7mnIg8L3NwYW4+MjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290aGlj Iic+5pel77yM5ZGo5LqMPC9zcGFuPiwgSHV1YiB2YW4gSGVsdm9vcnQgJmx0OzxhIGhyZWY9Ii9t Yy9jb21wb3NlP3RvPWh1dWJhdHdvcmtAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxp bmU6bm9uZSc+aHV1YmF0d29ya0BnbWFpbC5jb208L3NwYW4+PC9hPiZndDsgPHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7lhpnpgZPvvJo8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dCBzdHlsZT0nbXNvLW91dGxpbmUtbGV2ZWw6 MSc+Jmd0OyA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6TWluZ0xpVSc+5Y+R5Lu25Lq6PC9zcGFu PjogSHV1YiB2YW4gSGVsdm9vcnQgJmx0OzxhIGhyZWY9Ii9tYy9jb21wb3NlP3RvPWh1dWJhdHdv cmtAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+aHV1YmF0d29ya0Bn bWFpbC5jb208L3NwYW4+PC9hPiZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcw Nzhtc29wbGFpbnRleHQ+Jmd0OyA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyIn PuS4uzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6TWluZ0xpVSc+6aKYPC9zcGFuPjog UmU6IFttcGxzXSBbQUhNUExTLVRQXSBSOiBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFm dC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2 OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJNUyBH b3RoaWMiJz7mlLbku7bkuro8L3NwYW4+OiAmcXVvdDtEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBH ZXJhcmRvJnF1b3Q7ICZsdDs8YSBocmVmPSIvbWMvY29tcG9zZT90bz1hbGVzc2FuZHJvLmRhbGVz c2FuZHJvQHRlbGVjb21pdGFsaWEuaXQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5h bGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXQ8L3NwYW4+PC9hPiZndDs8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyA8c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuaKhOmAgTwvc3Bhbj46ICZxdW90OzxhIGhy ZWY9Ii9tYy9jb21wb3NlP3RvPW1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGlu ZTpub25lJz5tcGxzQGlldGYub3JnPC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Ii9tYy9j b21wb3NlP3RvPW1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5t cGxzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSIvbWMvY29tcG9zZT90 bz1tcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5lOm5v bmUnPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Ii9tYy9jb21wb3NlP3RvPW1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7 dGV4dC11bmRlcmxpbmU6bm9uZSc+bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L3NwYW4+PC9h PiZndDssICZxdW90O01QTFMtVFAgYWQgaG9jIHRlYW0mcXVvdDsgJmx0OzxhIGhyZWY9Ii9tYy9j b21wb3NlP3RvPWFobXBscy10cEBsaXN0cy5pdHUuaW50IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxp bmU6bm9uZSc+YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQ8L3NwYW4+PC9hPiZndDssICZxdW90Ozxh IGhyZWY9Ii9tYy9jb21wb3NlP3RvPWRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25A dG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5kcmFmdC1pZXRm LW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Ii9tYy9jb21wb3NlP3RvPWRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3Rl Y3Rpb25AdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5kcmFm dC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT4m Z3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsg PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7ml6XmnJ88L3NwYW4+OiAyMDEy PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7lubQ8L3NwYW4+MTA8c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuaciDwvc3Bhbj4yPHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJNUyBHb3RoaWMiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7m l6U8L3NwYW4+LDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290aGljIic+5ZGo5LqMPC9z cGFuPiw8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuS4i+WNiDwvc3Bhbj41 OjAyPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsg RG8gbm90IHN1cHBvcnQuPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxh aW50ZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50 ZXh0PiZndDsgU2FtZSByZWFzb25zIGFzIG1lbnRpb25lZCBiZWxvdy48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyBSZWdhcmRzLCBIdXViLjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IE9uIDAxLTEwLTEyIDE0 OjI3LCBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvIHdyb3RlOjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7ICZndDsgRG8gbm90IHN1cHBv cnQ8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAm Z3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsg Jmd0OyBBY2NvcmRpbmcgdG8gdGhlIG9wdGltaXphdGlvbiBjcml0ZXJpYSBmb3IgcmluZzxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IHByb3RlY3Rp b24gc3BlY2lmaWVkIGluIFNlY3Rpb24gMi41LjYuMSBpbiBSRkM1NjU0LCB0aGU8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyBNUExTLVRQIHJpbmcg cHJvdGVjdGlvbiBzaG91bGQgYmUgb3B0aW1pemVkIGZvcjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IHNpbXBsaWZpY2F0aW9uIG9mIHRoZSByaW5n IG9wZXJhdGlvbiBhbmQgdGhlIHJlc291cmNlczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkz NDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IGNvbnN1bXB0aW9uIGFyb3VuZCB0aGUgcmluZy4gSXQg aXMgbm90IHRoZSBjYXNlIG9mIHRoZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3 OG1zb3BsYWludGV4dD4mZ3Q7IHByb3Bvc2VkIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7ICZndDsgSXQgaXMgYWN0dWFsbHkgc2lt cGx5IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IG9mIGE8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyBsaW5lYXIgcHJvdGVjdGlvbiBtZWNoYW5p c20gYnV0IGl0IGNhbm5vdCBiZSBjb25zaWRlciBhPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2 OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgc29sdXRpb24gdGhhdCBhZGRyZXNzZXMgdGhlIHJl cXVpcmVtZW50cyBmb3IgcHJvdGVjdGlvbiBvZjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkz NDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IHJpbmcgdG9wb2xvZ2llcyBmb3IgTXVsdGktUHJvdG9j b2wgTGFiZWwgU3dpdGNoaW5nIFRyYW5zcG9ydDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkz NDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IFByb2ZpbGUgKE1QTFMtVFApIGFzIHNwZWNpZmllZCBp biBSRkM1NjU0LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4 dD4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRl eHQ+Jmd0OyAmZ3Q7IEJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQw NjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7IEFsZXNzYW5kcm88bzpwPjwvbzpwPjwvcD48cCBj bGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+PHAg Y2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7ICZndDsgVGVsZWNvbSBJ dGFsaWE8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0 OyAmZ3Q7IEFsZXNzYW5kcm8gR2VyYXJkbyBEJ0FsZXNzYW5kcm88bzpwPjwvbzpwPjwvcD48cCBj bGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7IFRyYW5zcG9ydCBJbm5vdmF0 aW9uPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsg Jmd0OyBWaWEgUmVpc3MgUm9tb2xpLCAyNzQgLSAxMDE0OCBUb3Jpbm88bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7IHBob25lOiZuYnNwOyAr MzkgMDExIDIyOCA1ODg3PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxh aW50ZXh0PiZndDsgJmd0OyBtb2JpbGU6ICszOSAzMzUgNzY2IDk2MDc8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7IGZheDogKzM5IDA2IDQx OCA2MzkgMDc8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+ Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0 PiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4 dD4mZ3Q7ICZndDsgLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS08bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQgc3R5bGU9J21zby1vdXRsaW5lLWxldmVs OjEnPiZndDsgJmd0OyBEYTogPGEgaHJlZj0iL21jL2NvbXBvc2U/dG89bXBscy1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bXBscy1ib3VuY2VzQGlldGYu b3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFp bnRleHQ+Jmd0OyBbPGEgaHJlZj0iL21jL2NvbXBvc2U/dG89bXBscy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZzwvc3Bhbj48L2E+XTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3Bs YWludGV4dD4mZ3Q7IFBlciBjb250byBkaSBIZWppYTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlp djkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7ICZndDsgSW52aWF0bzogc2FiYXRvIDI5IHNldHRl bWJyZSAyMDEyIDEyOjUzPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxh aW50ZXh0PiZndDsgJmd0OyBBOiBMb2EgQW5kZXJzc29uPG86cD48L286cD48L3A+PHAgY2xhc3M9 eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0OyBDYzogPGEgaHJlZj0iL21jL2NvbXBv c2U/dG89bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSdjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5lOm5vbmUnPm1wbHNA aWV0Zi5vcmc8L3NwYW4+PC9hPjsgPGEgaHJlZj0iL21jL2NvbXBvc2U/dG89bXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5tcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZzwvc3Bhbj48L2E+OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkz NDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IE1QTFMtVFAgYWQgaG9jIHRlYW07IDxhIGhyZWY9Ii9t Yy9jb21wb3NlP3RvPWRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5kcmFmdC1pZXRmLW1wbHMtdHAt cmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7IE9nZ2V0dG86IFJlOiBb bXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb248bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15 aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90 ZWN0aW9uPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZn dDsgJmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4m Z3Q7ICZndDsgRG8gbm90IHN1cHBvcnQuPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3 MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2 NzA3OG1zb3BsYWludGV4dD4mZ3Q7ICZndDsgQmFzZWQgb24gdGhlIGFuYWx5c2lzIGluIFNlY3Rp b24gMi40IG9mPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0 PiZndDsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMiwgdGhlIHJpbmcgcHJv dGVjdGlvbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4m Z3Q7IHNjaGVtZSB1c2luZyBTUE1FIGFzIGRlc2NyaWJlZCwgZWl0aGVyIHdyYXBwaW5nIG9yIHN0 ZWVyaW5nLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4m Z3Q7IGRvZXMgaGF2ZSBkZWZpY2llbmNpZXMsIHdoaWNoIElNSE8gc2hvdWxkIGJlIGJldHRlcjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IHJlY29u c2lkZXJlZCBhbmQgc29sdmVkIGlmIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlp djkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15 aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9 eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0OyBCLlIuPG86cD48L286cD48L3A+PHAg Y2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0OyBKaWE8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7PG86cD48L286cD48 L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0OyAtLS0tLTxzcGFu IHN0eWxlPSdmb250LWZhbWlseTpNaW5nTGlVJz7pgq7ku7bljp/ku7Y8L3NwYW4+LS0tLS08bzpw PjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQgc3R5bGU9J21zby1v dXRsaW5lLWxldmVsOjEnPiZndDsgJmd0OyA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6TWluZ0xp VSc+5Y+R5Lu25Lq6PC9zcGFuPjogPGEgaHJlZj0iL21jL2NvbXBvc2U/dG89bXBscy1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bXBscy1ib3VuY2VzQGll dGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29w bGFpbnRleHQ+Jmd0OyBbPGEgaHJlZj0iL21jL2NvbXBvc2U/dG89bXBscy1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZzwvc3Bhbj48L2E+XTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1z b3BsYWludGV4dD4mZ3Q7IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290aGljIic+5Luj 6KGoPC9zcGFuPiBMb2EgQW5kZXJzc29uPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3 MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0OyA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6TWluZ0xp VSc+5Y+R6YCB5pe26Ze0PC9zcGFuPjogMjAxMjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMg R290aGljIic+5bm0PC9zcGFuPjk8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyIn PuaciDwvc3Bhbj4xOTxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290aGljIic+5pelPC9z cGFuPiAxODo0OTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4 dD4mZ3Q7ICZndDsgPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7mioTpgIE8 L3NwYW4+OiA8YSBocmVmPSIvbWMvY29tcG9zZT90bz1tcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7 dGV4dC11bmRlcmxpbmU6bm9uZSc+bXBsc0BpZXRmLm9yZzwvc3Bhbj48L2E+OzxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IE1QTFMtVFAgYWQgaG9j IHRlYW07IDxhIGhyZWY9Ii9tYy9jb21wb3NlP3RvPWRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXBy b3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5k cmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPC9zcGFuPjwv YT47PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsg PGEgaHJlZj0iL21jL2NvbXBvc2U/dG89bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5tcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvc3Bh bj48L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZn dDsgJmd0OyA8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuS4uzwvc3Bhbj48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6TWluZ0xpVSc+6aKYPC9zcGFuPjogW21wbHNdIFdvcmtp bmcgZ3JvdXAgbGFzdCBjYWxsIG9uPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4 bXNvcGxhaW50ZXh0PiZndDsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7ICZndDs8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7IFdv cmtpbmcgR3JvdXAsPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50 ZXh0PiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWlu dGV4dD4mZ3Q7ICZndDsgdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIG9uPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50 ZXh0PiZndDsgJmd0OyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAyLXR4dC48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7 PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0 OyBQbGVhc2Ugbm90ZSB0aGF0IHRoZXJlIGFyZSB0d28gSVBSIGRpc2Nsb3N1cmVzICMgMTQ2Mjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IGFuZCZu YnNwOyAjIDE4NzI8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRl eHQ+Jmd0OyAmZ3Q7IHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+PHAg Y2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0OyBQbGVhc2Ugc2VuZCB5b3Vy IGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyBtYWlsaW5nIGxpc3RzPG86cD48L286cD48 L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0OyAoPGEgaHJlZj0i L21jL2NvbXBvc2U/dG89bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5lOm5v bmUnPm1wbHNAaWV0Zi5vcmc8L3NwYW4+PC9hPikuPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2 OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlp djkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7ICZndDsgVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIGVuZHMgT2N0b2JlciAzLCAyMDEyLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2 NzA3OG1zb3BsYWludGV4dD4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQw NjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7IC9Mb2E8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15 aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7IGZvciB0aGUgbXBscyB3ZyBjby1jaGFp cnM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAm Z3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsg Jmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7 ICZndDsgLS08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+ Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0 PiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4 dD4mZ3Q7ICZndDsgTG9hIEFuZGVyc3NvbiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0 PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDtlbWFpbDo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+ Jmd0OyA8YSBocmVmPSIvbWMvY29tcG9zZT90bz1sb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lO3RleHQtdW5kZXJsaW5lOm5vbmUnPmxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29t PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRl eHQ+Jmd0OyAmZ3Q7IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciZuYnNwOyAmbmJz cDsgJm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0 PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iL21jL2NvbXBvc2U/dG89bG9hQHBp Lm51IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bG9hQHBpLm51PC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7 IEVyaWNzc29uIEluYyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PG86 cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBob25lOiArNDY8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAxMCA3MTcg NTIgMTM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICs0Njxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IDc2NyA3 MiA5MiAxMzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4m Z3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmZ3Q7 IG1wbHMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNv cGxhaW50ZXh0PiZndDsgJmd0OyA8YSBocmVmPSIvbWMvY29tcG9zZT90bz1tcGxzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bXBsc0BpZXRmLm9yZzwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2 NzA3OG1zb3BsYWludGV4dD4mZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29w bGFpbnRleHQ+Jmd0OyAmZ3Q7IG1wbHMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+PHAgY2xh c3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJmd0OyA8YSBocmVmPSIvbWMvY29tcG9z ZT90bz1tcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bXBsc0Bp ZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNv cGxhaW50ZXh0PiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVybGluZTpub25lJz5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IC0tIDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7ICoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPG86cD48L286cD48 L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50ZXh0PiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQw NjcwNzhtc29wbGFpbnRleHQ+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6TWluZ0xpVSc+6K+36K6w5L2P77yM5L2g5piv54us5LiA5peg5LqM55qE77yM5bCx 5YOP5YW25LuW5q+P5LiA5Liq5Lq65LiA5qC3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4 bXNvcGxhaW50ZXh0PiZndDsgbXBscyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz15aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyA8YSBocmVmPSIvbWMvY29tcG9zZT90bz1t cGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+bXBsc0BpZXRmLm9y Zzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9eWl2OTM0MDY3MDc4bXNvcGxhaW50 ZXh0PiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15 aXY5MzQwNjcwNzhtc29wbGFpbnRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5 MzQwNjcwNzhtc29wbGFpbnRleHQ+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzhtc29wbGFpbnRl eHQ+bXBscyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXY5MzQwNjcwNzht c29wbGFpbnRleHQ+PGEgaHJlZj0iL21jL2NvbXBvc2U/dG89bXBsc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lO3RleHQtdW5kZXJsaW5lOm5vbmUnPm1wbHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPXlpdjkzNDA2NzA3OG1zb3BsYWludGV4dD48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZTt0ZXh0LXVuZGVy bGluZTpub25lJz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvdGQ+PC90cj48 L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQtZmFtaWx5OkFy aWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_001_01CDA130.8FCCBC35-- From chengwq@gmail.com Wed Oct 3 02:40:14 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E3921F86BB for ; Wed, 3 Oct 2012 02:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG2Knw4jj6sY for ; Wed, 3 Oct 2012 02:40:13 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 073D921F8658 for ; Wed, 3 Oct 2012 02:40:12 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so8636824vbb.31 for ; Wed, 03 Oct 2012 02:40:12 -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:content-transfer-encoding; bh=nNJ14xwyDH/zuT2WoY44F1cNUhsiQp/Rs6drQIFPcIk=; b=RBdNJx7H3TG+691vqZBb/cT/AtT3Em6TpVZ51+ieku6XwxS1fM/hCvuKRutRsl/evo Fv0ylQmvJuHJ5KNRud5OymL75pa2UYqdQEuauYHs/4KkKfmfU0aZXrxuedJMauZgR5YR hfeq/YKxTpr3b8kMdmVxKroMH0SEZccSZEMVaWbaNvTEIyGHBiCjOFYXhwL2ZMYVa5KB hDlQy3rxwfOEm0Gr3+z6x/sQbjwnrdLrPVByNoXBfdveuyI/EyDF4fGZV5/EMjN0urwx BuR7X09pGtfPnhmguEZFW/Wp7bH4O3DUtiUcjS4bl6J9d8CQ1kb5xjeZI+5BU9TEjpLE PEaA== MIME-Version: 1.0 Received: by 10.52.69.132 with SMTP id e4mr689672vdu.2.1349257212168; Wed, 03 Oct 2012 02:40:12 -0700 (PDT) Received: by 10.58.28.210 with HTTP; Wed, 3 Oct 2012 02:40:12 -0700 (PDT) In-Reply-To: <0c4c01cda0a7$8f112320$ad336960$@olddog.co.uk> References: <0c4c01cda0a7$8f112320$ad336960$@olddog.co.uk> Date: Wed, 3 Oct 2012 17:40:12 +0800 Message-ID: From: cheng weiqiang To: adrian@olddog.co.uk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 09:40:14 -0000 Dear adrian, Here I would like to try to describe some issues on the ring protection solution from my point view. 1. The Wrapping solution doesn=92t work when Multi-links faults happen For each link in the ring, current wrapping solution defines two SPME - the first is a SPME between the two LSRs that are connected by the link,and the second SPME between these same two LSRs but traversing the entire ring (except the link that connects the LSRs). ___ ___ x ___ =3D=3D=3D=3D=3D=3D>/LSR\********/LSR\********/LSR\ \_B_/ \_A_/ \_F_/ * = * * = * * = *x _* ___ *= _ /LSR\********/LSR\********/LSR\=3D=3D=3D=3D=3D=3D> \_C_/ \_D_/ \_E_/ =3D=3D=3D> connected LSP *** physical link x link fault Above figure shows that One LSP enter the ring from LSR B and Exit from LSR E. And at the same time the link A-F and link F-E are both broken.According to current solution, both the protection SPME for A-F and the protection SPME for Link F-E should be activated synchronously. Obviously, it does not work. At the same situation, the ring protection for SDH, G.8132(T-MPLS) and the MSRP solution (C-2098 =93MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology", ITU-T SG15 meeting, Sep. 2012) can work well. 2.Steering function is totally the same with 1:1 linear protection As the draft mentioned "we use 1:1 linear protection [SurvivFwk] [LinProtect] to perform protection switching and coordination when a signal fault is detected." It is the basic 1:1 linear protection(we can see it as a SNC protection,in another words 1:1 linear protection is using in sub-network). It does not provide any more simplicity and optimism than 1:1 linear protection. That is why we say this draft cannot meet R100 of RFC5654 the requirement. So I don't think we need defined it in the ring draft redundantly again. Best Regards, Cheng Weiqiang Research Institute of China Mobile e-mail:chengweiqiang@chinamobile.com mobile: +86 138 1001 9089 2012/10/2 Adrian Farrel : > Hi, > > Let me pitch in here as an individual contributor who sourced a lot of th= e text > in 2.5.6.1 of RFC 5654 basing it on the explicit requirements liaised fro= m the > ITU-T. > > I have read and reread that section trying to find the text that is claim= ed > below. It does not exist. > > Could you please point to the specific requirement you believe is not met= ? Or > maybe you are confused by the preamble text in the section that describes= the > circumstances under which an optimized protection mechanism (rather than = one > built from the mechanisms that operate outside a ring) might be developed= . > > Maybe, also, you could explain in what way you consider the current propo= sal > does not make good use of the resources on the ring (i.e. what features d= on't > work) so that the authors can look at improving their solution. > > Cheers, > Adrian > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> cheng weiqiang >> Sent: 02 October 2012 14:02 >> To: mpls-bounces@ietf.org >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring- >> protection@tools.ietf.org >> Subject: Re: [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection >> >> Do not support. >> >> In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should be >> optimized for simplification of the ring operation and the resources >> consumption around the ring. This draft cannot meet the requirement. >> >> Best Regards, >> >> Cheng Weiqiang >> Research Institute of China Mobile >> Department of Network Technology >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From paul.doolan@nsn.com Wed Oct 3 03:16:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF96121F86A1 for ; Wed, 3 Oct 2012 03:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ7771GRAc0M for ; Wed, 3 Oct 2012 03:16:26 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 37F3621F8460 for ; Wed, 3 Oct 2012 03:16:26 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q93AGNXF009052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 12:16:23 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q93AGH7j018936; Wed, 3 Oct 2012 12:16:23 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Oct 2012 12:16:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA150.1EB2D4CA" Date: Wed, 3 Oct 2012 18:16:14 +0800 Message-ID: <44A5364BC1FA1E42B1F133529EC2C72902C22E8C@CNBEEXC007.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: R: Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2hUB44ydMUR5TIRzC4UYIaiI7Kbg== From: "Doolan, Paul (NSN - US/Irving)" To: X-OriginalArrivalTime: 03 Oct 2012 10:16:18.0017 (UTC) FILETIME=[209C1D10:01CDA150] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4715 X-purgate-ID: 151667::1349259384-00006F5F-5DF46E86/0-0/0-0 Cc: mpls@ietf.org, draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 10:16:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDA150.1EB2D4CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Alessandro, Apologies if you got his twice: Loa had to get me fix an email problem this morning. Nurit claimed that you (and others) did not "provide any indication nor technical justification which requirements are not addressed and why do you think they are not addressed....." 'Pointing out R100 of RFC5654' I guess counts as an 'indication' but certainly does not provide justification or indicate how the requirement is not addressed. So to be productive here you need to be more specific. Since you provide the example please indicate precisely how you think this proposed draft violates R100 of RFC5654 (inline below for those unfamiliar). Recovery techniques in a ring SHOULD be identical (or as similar as possible) to those in general transport networks to simplify implementation and operations. However, this MUST NOT override any other requirement. You might also want to look at RFC2119. best regards, pd Paul Doolan ------_=_NextPart_001_01CDA150.1EB2D4CA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable R: Working group last call on = draft-ietf-mpls-tp-ring-protection

Hello = Alessandro,

Apologies if you got his twice: Loa had to get me fix = an email problem this morning.

Nurit claimed = that you (and others) did not “provide any indication nor technical justification which requirements are not = addressed and why do you think they are not = addressed…..”

‘Pointing out R100 = of RFC5654’ I guess counts as an ‘indication’ but certainly = does not provide justification or indicate how the requirement = is not addressed. So to be productive here = you  need to be more specific.

Since you = provide the example please indicate precisely how you think this = proposed draft violates R100 of RFC5654 (inline below for those = unfamiliar).

Recovery = techniques in a ring SHOULD be identical = (or as similar

as possible) to = those in general transport networks to simplify

implementation = and operations.  However, this MUST NOT override

 any other = requirement.

You might also = want to look at RFC2119.

best = regards,

pd

Paul Doolan

------_=_NextPart_001_01CDA150.1EB2D4CA-- From paul.doolan@nsn.com Wed Oct 3 05:10:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404A121F86BD for ; Wed, 3 Oct 2012 05:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnbGLjV3LmOV for ; Wed, 3 Oct 2012 05:10:22 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A16F121F86B8 for ; Wed, 3 Oct 2012 05:10:17 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q93CABxD008383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 14:10:11 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q93CA9AX001325; Wed, 3 Oct 2012 14:10:09 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Oct 2012 14:10:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA160.04A721C0" Date: Wed, 3 Oct 2012 20:10:01 +0800 Message-ID: <44A5364BC1FA1E42B1F133529EC2C72902C22E96@CNBEEXC007.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Concensus ? Thread-Index: Ac2hYANzh3Uvp/5fTiSnykUr6HfuQA== From: "Doolan, Paul (NSN - US/Irving)" To: , X-OriginalArrivalTime: 03 Oct 2012 12:10:06.0361 (UTC) FILETIME=[069EB890:01CDA160] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6536 X-purgate-ID: 151667::1349266211-00003184-4001DC58/0-0/0-0 Subject: [mpls] Concensus ? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 12:10:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDA160.04A721C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi George, Yesterday, with your chair hat on, you wrote: > The object is to fix the draft so that WG consensus can be achieved to move it forward. > If the WG consensus is that there are deficiencies and that the authors have failed to address them then we would not have consensus. The last sentence is interesting, in an Alice in Wonderland or Bertrand Russell kind of way, but my question is about your use of the word 'concensus' itself. The Tao document (www.ietf.org/tao.html) still references Dave Clark's formulation "rough concensus and running code". Does this WG operate on that rough standard or the smoother one you suggest?=20 cheers, pd ------_=_NextPart_001_01CDA160.04A721C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Concensus ?

Hi George,

Yesterday, with your chair hat on, you = wrote:

> The object is to fix the draft so that WG consensus can be = achieved to move it forward.

> If the WG consensus is that there are deficiencies and that = the authors have failed to address them then we would not have = consensus.

The last sentence is = interesting, in an Alice in Wonderland or Bertrand Russell kind of way, but my question is about your use of the word ‘concensus’ itself.

The Tao = document = (www.ietf.org/tao.html) still references Dave Clark’s = formulation “rough concensus and = running code”. Does this WG operate on that rough standard or = the smoother one you suggest? =

cheers,

pd

------_=_NextPart_001_01CDA160.04A721C0-- From adrian@olddog.co.uk Wed Oct 3 06:29:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1516C21F8510 for ; Wed, 3 Oct 2012 06:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJqMYcjtAIIb for ; Wed, 3 Oct 2012 06:29:02 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9675721F84E4 for ; Wed, 3 Oct 2012 06:29:01 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q93DSw4V026954; Wed, 3 Oct 2012 14:28:58 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q93DSu7Z026943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Oct 2012 14:28:57 +0100 From: "Adrian Farrel" To: "cheng weiqiang" Date: Wed, 3 Oct 2012 14:28:55 +0100 Message-ID: <0e2901cda16b$09f5d1d0$1de17570$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E2A_01CDA173.6BD93380" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2hauhDpvA13ShdSFuSnjr8X2pVhQ== Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:29:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E2A_01CDA173.6BD93380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Thanks for taking the time to set out your concerns. I hope this now gives the WG something to work with. With regard the first point, I hope to hear from the authors whether you have identified a scenario where linear protection will not work (in which case they should probably flag this short-coming in the I-D) or if they can see how linear protection can handle the double failure case you have illustrated. Obviously, we don't have access to C-2098 and can't take it as input to the IETF discussions, so if its authors (was that you?) want to take that material as contribution to the MPLS WG's work, you need to submit it either as an Internet-Draft or as email. The second of your discussion points is related to Section 2.5.6.1 of RFC 5654, and specifically R100. I reproduce it here for our readers: 100 Recovery techniques in a ring SHOULD be identical (or as similar as possible) to those in general transport networks to simplify implementation and operations. However, this MUST NOT override any other requirement. I think the authors need to address this point, but my understanding is that the whole section is intended to describe the requirements that have to be satisfied by topology-specific solutions. Thus, if we were inventing a new protection solution applicable in rings then we would need to address these requirements directly. However, I believe that the I-D that is in last call is called "Applicability of MPLS-TP Linear Protection for Ring Topologies". That is, it does not define a new mechanism, but specifically shows how the general mechanism can be applied. Obviously, I can't speak for the WG, but it would seem to me that nothing in this I-D precludes the development of a topology-specific solution for rings that meets the optimization criteria in Section 2.5.6.1 of RFC 5654 and also addresses the specific requirements in that section. It also seems to me that the I-D in question is not a protocol specification at all (note that it is an Informational draft) and actually does not even describe anything other than how linear protection might apply in a ring topology. So I am not quite sure why you believe that the failure of the generic solution to address a requirement intended to describe optimizations is a reason to not publish this document. Rather, in your shoes, I would see it as an encouragement to do topology-specific work to follow on from this current I-D. Cheers, Adrian > -----Original Message----- > From: cheng weiqiang [mailto:chengwq@gmail.com] > Sent: 03 October 2012 10:40 > To: adrian@olddog.co.uk > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring- > protection@tools.ietf.org; larryli888@yahoo.com.cn > Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Dear adrian, > > Here I would like to try to describe some issues on the ring > protection solution from my point view. > > 1. The Wrapping solution doesn't work when Multi-links faults happen > > For each link in the ring, current wrapping solution defines two SPME > - the first is a SPME between the two LSRs that are connected by the > link,and the second SPME > > between these same two LSRs but traversing the entire ring (except the > link that connects the LSRs). > > ___ ___ x ___ > ======>/LSR\********/LSR\********/LSR\ > \_B_/ \_A_/ \_F_/ > * * > * * > * *x _* ___ *_ > /LSR\********/LSR\********/LSR\======> > \_C_/ \_D_/ \_E_/ > > ===> connected LSP *** physical link > x link fault > > > Above figure shows that One LSP enter the ring from LSR B and Exit > from LSR E. And at the same time the link A-F and link F-E are both > broken. According to current solution, both the protection SPME for > A-F and the protection SPME for Link F-E should be activated > synchronously. Obviously, it does not work. > > At the same situation, the ring protection for SDH, G.8132(T-MPLS) and > the MSRP solution (C-2098 "MPLS-TP Shared-Ring protection (MSRP) > mechanism for ring topology", ITU-T SG15 meeting, Sep. 2012) can > work well. > > 2.Steering function is totally the same with 1:1 linear protection > > As the draft mentioned "we use 1:1 linear protection [SurvivFwk] > [LinProtect] to perform protection switching and coordination when a > signal fault is detected." It is the basic 1:1 linear protection(we > can see it as a SNC protection, in another words 1:1 linear > protection is using in sub-network). > > It does not provide any more simplicity and optimism than 1:1 linear > protection. That is why we say this draft cannot meet R100 of RFC5654 > the requirement. > > So I don't think we need defined it in the ring draft redundantly again. > > Best Regards, > > Cheng Weiqiang > Research Institute of China Mobile > e-mail:chengweiqiang@chinamobile.com > mobile: +86 138 1001 9089 > > > > > 2012/10/2 Adrian Farrel : > > Hi, > > > > Let me pitch in here as an individual contributor who sourced a lot of the text > > in 2.5.6.1 of RFC 5654 basing it on the explicit requirements liaised from the > > ITU-T. > > > > I have read and reread that section trying to find the text that is claimed > > below. It does not exist. > > > > Could you please point to the specific requirement you believe is not met? Or > > maybe you are confused by the preamble text in the section that describes the > > circumstances under which an optimized protection mechanism (rather than > > one built from the mechanisms that operate outside a ring) might be developed. > > > > Maybe, also, you could explain in what way you consider the current proposal > > does not make good use of the resources on the ring (i.e. what features don't > > work) so that the authors can look at improving their solution. > > > > Cheers, > > Adrian > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > >> cheng weiqiang > >> Sent: 02 October 2012 14:02 > >> To: mpls-bounces@ietf.org > >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring- > >> protection@tools.ietf.org > >> Subject: Re: [mpls] Working group last call on > > draft-ietf-mpls-tp-ring-protection > >> > >> Do not support. > >> > >> In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should be > >> optimized for simplification of the ring operation and the resources > >> consumption around the ring. This draft cannot meet the requirement. > >> > >> Best Regards, > >> > >> Cheng Weiqiang > >> Research Institute of China Mobile > >> Department of Network Technology > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > ------=_NextPart_000_0E2A_01CDA173.6BD93380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Thanks for taking the time to set = out your concerns.

 

I hope = this now gives the WG something to work with.

 

With regard the first point, I hope = to hear from the authors whether you have identified a scenario where = linear protection will not work (in which case they should probably flag = this short-coming in the I-D) or if they can see how linear protection = can handle the double failure case you have = illustrated.

 

Obviously, we don't have access to C-2098 and can't take it as = input to the IETF discussions, so if its authors (was that you?) want to = take that material as contribution to the MPLS WG's work, you need to = submit it either as an Internet-Draft or as = email.

 

The = second of your discussion points is related to Section 2.5.6.1 of RFC = 5654, and specifically R100. I reproduce it here for our = readers:

 

   100  Recovery techniques in a ring = SHOULD be identical (or as similar

        = as possible) to those in general transport networks to = simplify

        = implementation and operations.  However, this MUST NOT = override

        = any other requirement.

 

I think the authors need to address = this point, but my understanding is that the whole section is intended = to describe the requirements that have to be satisfied by = topology-specific solutions. Thus, if we were inventing a new protection = solution applicable in rings then we would need to address these = requirements directly. However, I believe that the I-D that is in last = call is called "Applicability of MPLS-TP Linear Protection for Ring = Topologies". That is, it does not define a new mechanism, but = specifically shows how the general mechanism can be applied. =

 

Obviously, I can't speak for the WG, but it would seem to me that = nothing in this I-D precludes the development of a topology-specific = solution for rings that meets the optimization criteria in Section = 2.5.6.1 of RFC 5654 and also addresses the specific requirements in that = section. It also seems to me that the I-D in question is not a protocol = specification at all (note that it is an Informational draft) and = actually does not even describe anything other than how linear = protection might apply in a ring topology.

 

So I am not quite sure why you = believe that the failure of the generic solution to address a = requirement intended to describe optimizations is a reason to not = publish this document. Rather, in your shoes, I would see it as an = encouragement to do topology-specific work to follow on from this = current I-D.

 

Cheers,

Adrian

 

> -----Original = Message-----

> From: cheng = weiqiang [mailto:chengwq@gmail.com]

> = Sent: 03 = October 2012 10:40

> To: = adrian@olddog.co.uk

> Cc: = mpls@ietf.org; mpls-chairs@tools.ietf.org; = draft-ietf-mpls-tp-ring-

> protection@tools= .ietf.org; larryli888@yahoo.com.cn

> = Subject: Re: = [mpls] Working group last call on = draft-ietf-mpls-tp-ring-protection

> =

> Dear = adrian,

>

> Here = I would like to try to describe some issues on the = ring

> protection solution from my = point view.

>

> 1. = The Wrapping solution doesn’t work when Multi-links faults = happen

>

> For = each link in the ring, current wrapping solution defines two = SPME

> - the first is a SPME between = the two LSRs that are connected by the

> = link,and the second SPME

> =

> between these same two LSRs but = traversing the entire ring (except the

> link = that connects the LSRs).

> =

>        &nbs= p;      ___          ___    x     ___<= /span>

>       = =3D=3D=3D=3D=3D=3D>/LSR\********/LSR\********/LSR\

>        &nbs= p;     \_B_/        \_A_/        \_F= _/

>               &nbs= p;*         &nbs= p;            = ;   *

> =               &nbs= p;*     =        &nbs= p;            = ;*

>        &nbs= p;       *                   &nbs= p;     *x

       &nbs= p;        _*           ___           *_<= o:p>

>        &nbs= p;     /LSR\********/LSR\********/LSR\=3D= =3D=3D=3D=3D=3D>

>              \_C_/        \_D= _/        \_E_/

>

> =        &nbs= p;    =3D=3D=3D> connected LSP    *** physical = link

>        &nbs= p;         x   link = fault

>

> =

> Above figure shows that One LSP = enter the ring from LSR B and Exit

> from = LSR E. And at the same time the link A-F and link F-E are = both

> broken. According to current = solution, both the protection SPME for

> A-F = and the protection SPME for Link F-E should be = activated

> synchronously. Obviously, it = does not work.

>

> At = the same situation, the ring protection for SDH, G.8132(T-MPLS) = and

> the MSRP solution (C-2098 = “MPLS-TP Shared-Ring protection (MSRP)

> = mechanism for ring topology", ITU-T SG15 meeting, Sep. 2012) = can

> work = well.

>

> = 2.Steering function is totally the same with 1:1 linear = protection

>

> As = the draft mentioned "we use 1:1 linear protection = [SurvivFwk]

> [LinProtect] to perform = protection switching and coordination when a

> = signal fault is detected." It is the basic 1:1 linear = protection(we

> can see it as a SNC protection, = in another words 1:1 linear

> = protection is using in sub-network).

> =

> It does not provide any more = simplicity and optimism than 1:1 linear

> = protection. That is why we say this draft cannot meet R100 of = RFC5654

> the = requirement.

>  

> So I = don't think we need defined it in the ring draft redundantly = again.

>

> Best = Regards,

>

> = Cheng Weiqiang

> Research Institute of China = Mobile

> = e-mail:chengweiqiang@chinamobile.com

> = mobile: +86 138 1001 9089

> =

>

> =

>

> = 2012/10/2 Adrian Farrel = <adrian@olddog.co.uk>:

> > = Hi,

> >

> > = Let me pitch in here as an individual contributor who sourced a lot of = the text

> > in 2.5.6.1 of RFC 5654 = basing it on the explicit requirements liaised from = the

> > = ITU-T.

> >

> > = I have read and reread that section trying to find the text that is = claimed

> > below. It does not = exist.

> >

> > = Could you please point to the specific requirement you believe is not = met? Or

> > maybe you are confused by = the preamble text in the section that describes = the

> > circumstances under which = an optimized protection mechanism (rather than

> > = one built from the mechanisms that operate outside a ring) might be = developed.

> >

> > = Maybe, also, you could explain in what way you consider the current = proposal

> > does not make good use of = the resources on the ring (i.e. what features = don't

> > work) so that the authors = can look at improving their solution.

> = >

> > = Cheers,

> > = Adrian

> >

> = >> -----Original Message-----

> = >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On = Behalf Of

> >> cheng = weiqiang

> >> Sent: 02 October 2012 = 14:02

> >> To: = mpls-bounces@ietf.org

> >> Cc: mpls@ietf.org; = mpls-chairs@tools.ietf.org; = draft-ietf-mpls-tp-ring-

> = >> protection@tools.ietf.org

> = >> Subject: Re: [mpls] Working group last call = on

> > = draft-ietf-mpls-tp-ring-protection

> = >>

> >> Do not = support.

> = >>

> >> In Section 2.5.6.1 of = RFC5654, the MPLS-TP ring protection should be

> = >> optimized for simplification of the ring operation and the = resources

> >> consumption around the = ring. This draft cannot meet the requirement.

> = >>

> >> Best = Regards,

> = >>

> >> Cheng = Weiqiang

> >> Research Institute of = China Mobile

> >> Department of Network = Technology

> >> = _______________________________________________

> = >> mpls mailing list

> = >> mpls@ietf.org

> = >> = https://www.ietf.org/mailman/listinfo/mpls

> = >

------=_NextPart_000_0E2A_01CDA173.6BD93380-- From alessandro.dalessandro@telecomitalia.it Wed Oct 3 06:55:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191E121F85C3 for ; Wed, 3 Oct 2012 06:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[AWL=-2.272, BAYES_00=-2.599, CN_BODY_35=0.339, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-M2x4PzKkFW for ; Wed, 3 Oct 2012 06:55:45 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 270D921F84F6 for ; Wed, 3 Oct 2012 06:55:44 -0700 (PDT) Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 3 Oct 2012 15:55:42 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by grfhub703rm001.griffon.local ([10.19.9.236]) with mapi; Wed, 3 Oct 2012 15:55:41 +0200 From: D'Alessandro Alessandro Gerardo To: "stbryant@cisco.com" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Date: Wed, 3 Oct 2012 15:55:39 +0200 Thread-Topic: [AHMPLS-TP] R: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2gwPTjpbBFIaOzSc2imrCIZIQ/fgAkykaA Message-ID: References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> <506B2036.3040508@cisco.com> In-Reply-To: <506B2036.3040508@cisco.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_A1F769BC58A8B146B2EEA818EAE052A2098C94193DGRFMBX702RM00_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: [mpls] R: [AHMPLS-TP] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:55:47 -0000 --_000_A1F769BC58A8B146B2EEA818EAE052A2098C94193DGRFMBX702RM00_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBTdGV3YXJ0LCBkZWFyIE51cml0LA0KDQoNCkNpdGluZyBTdGV3YXJ0oa9zIGFuc3dlcg0K DQoNCg0KIKGwVGhlIE1VU1QgaXMgdGhhdCBhbGwgb3RoZXIgcmVxdWlyZW1lbnRzIE1VU1QgYmUg bWV0LCBhbmQgdGhlIFNIT1VMRA0KDQppcyB0aGF0IHRoZSBzb2x1dGlvbiBTSE9VTEQgYmUgdGhv c2UgaW4gZ2VuZXJhbCB0cmFuc3BvcnQgbmV0d29ya3MsDQoNCndoaWNoIGlzIGFjdHVhbGx5IGlz IG5vdCBhIHJpbmcgc3BlY2lmaWMgc3RhdGVtZW50LiBJbmRlZWQgYnkNCg0KcmV1c2luZyB0aGUg bWVzaCBhcHByb2FjaCAoUkZDNjM3OCkgd2UgY29tcGx5IHdpdGggdGhhdCByZXF1aXJlbWVudA0K DQpzaW5jZSB0aGUgbWVzaCBzb2x1dGlvbiBhcmUgYnkgZGVmaW5pdGlvbiAiaWRlbnRpY2FsIHRv IHRob3NlIGluDQoNCmdlbmVyYWwgdHJhbnNwb3J0IG5ldHdvcmtzIqGxDQoNCmluZGVlZCBJIGRv IG5vdCBiZWxpZXZlIHRoYXQgd2UgY29tcGx5IHdpdGggdGhlIHJlcXVpcmVtZW50cyChsE1VU1Sh sSByZWZlcnMgdG8uDQoNCk1vcmUgc3BlY2lmaWNhbGx5LCBhcyBhbiBleGFtcGxlLA0KUkZDIDU2 NTQsIFJlcS4gMTA2QjogIKGwTVBMUy1UUCByZWNvdmVyeSBtZWNoYW5pc21zIGluIGEgcmluZyBT SE9VTEQgcHJvdGVjdCBhZ2FpbnN0IG11bHRpcGxlIGZhaWx1cmVzobENCkRvIHdlIGNvbXBseSB3 aXRoIHRoYXQgcmVxdWlyZW1lbnQ/ICBXaGF0IGlzIHRoZSBzb2x1dGlvbiAoYW5kIHJlbGV2YW50 IG9wZXJhdGlvbi9jb25maWd1cmF0aW9uIGNvc3QpIGluIHRoZSBwcm9wb3NlZCBkcmFmdCB3aGVu IHR3byBhZGphY2VudCBub2RlcyBmYWlsPyBEaWQgd2UgaW52ZXN0aWdhdGUgZnVydGhlciBhcHBy b2FjaGVzIGJlZm9yZSBjb25zaWRlcmluZyBjdXJyZW50IGRyYWZ0IGFzIHRoZSBwcm90ZWN0aW9u IHNvbHV0aW9uIGZvciByaW5nIHRvcG9sb2dpZXM/DQoNCkFub3RoZXIgZXhhbXBsZToNClJGQyA1 NjU0LCBSZXEuIDEwNTogIKGwSXQgTVVTVCBiZSBwb3NzaWJsZSB0byBsb2Nrb3V0IChkaXNhYmxl KSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgb24gc2VsZWN0ZWQgbGlua3MgKHNwYW5zKSBpbiBhIHJp bmehsQ0KRG8gd2UgY29tcGx5IHdpdGggdGhhdCByZXF1aXJlbWVudD8gIFdoYXQgaXMgdGhlIHBy b3Bvc2VkIHNvbHV0aW9uIChhbmQgcmVsZXZhbnQgb3BlcmF0aW9uL2NvbmZpZ3VyYXRpb24gY29z dCkgdG8gc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnQ/DQoNCg0KSWYgd2UgbG9vayBpbnRvIHRoZSBk cmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLCBlLmcuIGZvciB0aGUgd3JhcHBpbmcg c29sdXRpb24sIHdlIGZpbmQgdGhlIGZvbGxvd2luZzoNCg0KU2VjdGlvbiAxLiAgSW50cm9kdWN0 aW9uDQqhsFdlIHNob3cgdGhhdCB0aGlzIG1lY2hhbmlzbSBwcm92aWRlcyB0aGUgYWJpbGl0eSB0 byAgICBwcm90ZWN0IGFsbCBvZiB0aGUgYmFzaWMgY29uZGl0aW9ucyB3aXRoaW4gYSByZWFzb25h YmxlIHRpbWUgZnJhbWUgICAgYW5kIGRvZXMgb3B0aW1pemUgdGhlIGNyaXRlcmlhIHNldCBvdXQg aW4gW1RQUmVxc10gYXMgc3VtbWFyaXplZCAgICBhYm92ZS6hsQ0KRG9lcyB0aGUgcHJvcG9zZWQg c29sdXRpb24gb3B0aW1pemUgdGhlIGNyaXRlcmlhIGFzIHNwZWNpZmllZCBpbiAgW1RQUmVxc10/ IEkgcm9zZSB0aGUgcG9pbnQgaW4gYSBwcmV2aW91cyBlbWFpbCBvbiBPY3RvYmVyIDJuZCB0byBT dGV3YXJ0IEJyeWFudC4NCldhcyB0aGUgcHJvcG9zZWQgc29sdXRpb24gY29tcGFyZWQgd2l0aCBv dGhlciBhcHByb2FjaGVzIHRvIGJldHRlciB1bmRlcnN0YW5kIHBybyBhbmQgY29ucyAoZS5nLiBy ZXNwZWN0IHRvIHRoZSBjcml0ZXJpYSBhYm92ZSBtZW50aW9uZWQgYW5kIHJlc3BlY3QgdG8gdGhl IG92ZXJhbGwgYmVoYXZpb3IgYW5kIGNvbXBsZXhpdHkpPw0KDQpTZWN0aW9uIDEuMS4gIFByb2Js ZW0gc3RhdGVtZW50DQqhsEluIGVpdGhlciBvZiB0aGVzZSB0d28gc2l0dWF0aW9ucywgdGhlcmUg aXMgYSBuZWVkIHRvIGFkZHJlc3MgdGhlICAgZm9sbG93aW5nIGRpZmZlcmVudCBjYXNlcyAgLQ0K My4gIEFuIG9wZXJhdG9yIGNvbW1hbmQgaXMgaXNzdWVkIHRvIGEgc3BlY2lmaWMgcmluZyBub2Rl LiAgQSAgZGVzY3JpcHRpb24gb2YgdGhlIGRpZmZlcmVudCBvcGVyYXRvciBjb21tYW5kcyBpcyBm b3VuZCBpbiBTZWN0aW9uIDQuMTIgb2YgW1JGQzQ0MjddLiAgRXhhbXBsZXMgb2YgdGhlc2UgY29t bWFuZHMgaW5jbHVkZSAgTWFudWFsIFN3aXRjaCwgRm9yY2VkIFN3aXRjaCwgb3IgQ2xlYXIgb3Bl cmF0aW9ucy6hsQ0KSSBkaWQgbm90IGZpbmQgdGhlIEZyZWV6ZSBjb21tYW5kIGFzIHNwZWNpZmll ZCBpbiBzZWN0aW9uIDQuMTMgb2YgUkZDIDQ0MjcgaW4gdGhlIHByb3Bvc2VkIHNvbHV0aW9uLiBX aGF0IGFyZSB0aGUgY29tbWFuZHMgdGhhdCBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0 aW9uIHN1cHBvcnQ/DQpPYnM6ICByZWZlcmVuY2Ugc2hvdWxkIGJlIHRvIHNlY3Rpb24gNC4xMyBv ZiBSRkM0NDI3IGFuZCBub3QgdG8gc2VjdGlvbiA0LjEyDQoNClNlY3Rpb24gMi4xLiAgV3JhcHBp bmcNCqGwQ29uZmlndXJhdGlvbiBvZiB0aGUgcHJvdGVjdGlvbiBiZWluZyBwZXJmb3JtZWQgKGku ZS4gICBsaW5rIHByb3RlY3Rpb24gb3Igbm9kZSBwcm90ZWN0aW9uKSBuZWVkcyB0byBiZSBwZXJm b3JtZWQgICAgYS1wcmlvcmksIHNpbmNlIHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZSBwcm9wZXIg cHJvdGVjdGlvbiBwYXRoIGlzICAgZGVwZW5kZW50IHVwb24gdGhpcyBkZWNpc2lvbi6hsQ0KSSBi ZWxpZXZlIHRoaXMgaXMgYSBjb25zZXF1ZW5jZSBvZiB0aGUgcHJvcG9zZWQgc29sdXRpb24gYW5k IG5vdCB0aGUgZ2VuZXJhbCBiZWhhdmlvciB0aGF0IG9wZXJhdG9yIHNob3VsZCBleHBlY3QgZm9y IHJpbmcgYmFzZWQgcHJvdGVjdGlvbi4gVGhhdCBjbGVhcmx5ICBzaG93cyAgZHJhZnQtaWV0Zi1t cGxzLXRwLXJpbmctcHJvdGVjdGlvbiBsaW1pdGF0aW9ucyBpbiB0ZXJtcyBvZiBvcHRpbWl6YXRp b24gZm9yIHJpbmcgYmFzZWQgIHRvcG9sb2d5IGl0IGlzIGludGVuZGVkIGZvcg0KDQoNClNlY3Rp b24gMi4zLjQuICBXcmFwcGluZyBmb3IgbGluayBhbmQgbm9kZSBwcm90ZWN0aW9uDQogIKGwIElu IGFkZGl0aW9uLCB0aGUgbmVpZ2hib3JpbmcgTFNSLCB0aGF0IGRldGVjdHMgdGhlIGZhdWx0LCAg ICBjYW5ub3QgcmVhZGlseSBkaWZmZXJlbnRpYXRlIGJldHdlZW4gYSBsaW5rIGZhaWx1cmUgb3Ig YSBub2RlICAgIGZhaWx1cmUuDQogICBJdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBjb25maWd1cmUg ZXh0cmEgU1BNRSB0byBwcm90ZWN0IGJvdGggZm9yIGxpbmsgICAgYW5kIG5vZGUgZmFpbHVyZXMs IGFycml2aW5nIGF0IGEgY29uZmlndXJhdGlvbiBvZiB0aGUgcmluZyB0aGF0IGlzICAgIHNob3du IGluIEZpZ3VyZSA1LiAgQ2hvb3NpbmcgdGhlIFNQTUUgdG8gdXNlIGZvciB0aGUgd3JhcHBpbmcg d291bGQsICBob3dldmVyLCB0aGVuIGludm9sdmUgY29uc2lkZXJhYmxlIGVmZm9ydCBhbmQgY291 bGQgcmVzdWx0IGluIHRoZSAgICBwcm90ZWN0ZWQgdHJhZmZpYyBub3Qgc2hhcmluZyB0aGUgc2Ft ZSBwcm90ZWN0aW9uIHBhdGggaW4gYm90aCAgICBkaXJlY3Rpb25zLqGxDQpTZWxmLWV4cGxhaW5p bmehrSBhbnl3YXkgSSBiZWxpZXZlIHRoaXMgaXMgYSBjb25zZXF1ZW5jZSBvZiB0aGUgcHJvcG9z ZWQgc29sdXRpb24gYW5kIG5vdCB0aGUgZ2VuZXJhbCBiZWhhdmlvciB0aGF0IG9wZXJhdG9yIHNo b3VsZCBleHBlY3QgZm9yIHJpbmcgYmFzZWQgcHJvdGVjdGlvbi4gVGhhdCBjbGVhcmx5IHNob3dz ICBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uIGxpbWl0YXRpb25zIGluIHRlcm1z IG9mIG9wdGltaXphdGlvbiBmb3IgcmluZyB0b3BvbG9neSBpdCBpcyBpbnRlbmRlZCBmb3INCg0K DQpTbywgdGhlcmUgYXJlIHR3byBtYWluIHBvaW50cyBJIHJvc2U6DQoNCjEuICAgICAgIENvbXBs aWFuY2UgdG8gcmVxdWlyZW1lbnRzDQoNCjIuICAgICAgIExpbWl0YXRpb25zIGFuZCBjb21wbGV4 aXR5IHRoYXQgYXJlIGNsZWFybHkgc3RhdGVkIGluIHRoZSBkb2N1bWVudCBpdHNlbGYNCg0KDQpU aG9zZSBwb2ludHMgYnJpbmcgbWUgdG8gY29uc2lkZXIgdGhlIGRyYWZ0IG5vdCBzdGlsbCBtYXR1 cmUuDQoNCkJlc3QgcmVnYXJkcywNCkFsZXNzYW5kcm8NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGVsZWNvbSBJdGFs aWENCkFsZXNzYW5kcm8gR2VyYXJkbyBEJ0FsZXNzYW5kcm8NClRyYW5zcG9ydCBJbm5vdmF0aW9u DQpWaWEgUmVpc3MgUm9tb2xpLCAyNzQgLSAxMDE0OCBUb3Jpbm8NCnBob25lOiAgKzM5IDAxMSAy MjggNTg4Nw0KbW9iaWxlOiArMzkgMzM1IDc2NiA5NjA3DQpmYXg6ICszOSAwNiA0MTggNjM5IDA3 DQoNCkRhOiBTdGV3YXJ0IEJyeWFudCBbbWFpbHRvOnN0YnJ5YW50QGNpc2NvLmNvbV0NCkludmlh dG86IG1hcnRlZKisIDIgb3R0b2JyZSAyMDEyIDE5OjExDQpBOiBEJ0FsZXNzYW5kcm8gQWxlc3Nh bmRybyBHZXJhcmRvDQpDYzogU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24p OyBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTVBMUy1UUCBhZCBo b2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9y Zw0KT2dnZXR0bzogUmU6IFtBSE1QTFMtVFBdIFI6IFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoNClRoZSB0ZXh0IGlu IDEwMCBzYXlzOg0KDQoiMTAwICBSZWNvdmVyeSB0ZWNobmlxdWVzIGluIGEgcmluZyBTSE9VTEQg YmUgaWRlbnRpY2FsIChvciBhcyBzaW1pbGFyDQoNCiAgICAgIGFzIHBvc3NpYmxlKSB0byB0aG9z ZSBpbiBnZW5lcmFsIHRyYW5zcG9ydCBuZXR3b3JrcyB0byBzaW1wbGlmeQ0KDQogICAgICBpbXBs ZW1lbnRhdGlvbiBhbmQgb3BlcmF0aW9ucy4gIEhvd2V2ZXIsIHRoaXMgTVVTVCBOT1Qgb3ZlcnJp ZGUNCg0KICAgICAgYW55IG90aGVyIHJlcXVpcmVtZW50LiINCg0KDQoNClRoZSBNVVNUIGlzIHRo YXQgYWxsIG90aGVyIHJlcXVpcmVtZW50cyBNVVNUIGJlIG1ldCwgYW5kIHRoZSBTSE9VTEQNCg0K aXMgdGhhdCB0aGUgc29sdXRpb24gU0hPVUxEIGJlIHRob3NlIGluIGdlbmVyYWwgdHJhbnNwb3J0 IG5ldHdvcmtzLA0KDQp3aGljaCBpcyBhY3R1YWxseSBpcyBub3QgYSByaW5nIHNwZWNpZmljIHN0 YXRlbWVudC4gSW5kZWVkIGJ5DQoNCnJldXNpbmcgdGhlIG1lc2ggYXBwcm9hY2ggKFJGQzYzNzgp IHdlIGNvbXBseSB3aXRoIHRoYXQgcmVxdWlyZW1lbnQNCg0Kc2luY2UgdGhlIG1lc2ggc29sdXRp b24gYXJlIGJ5IGRlZmluaXRpb24gImlkZW50aWNhbCB0byB0aG9zZSBpbg0KDQpnZW5lcmFsIHRy YW5zcG9ydCBuZXR3b3JrcyIuDQoNCg0KDQpBIG1vcmUgcHJvZHVjdGl2ZSByZXZpZXcgYXBwcm9h Y2ggbWlnaHQgYmUgdG8gcG9pbnQgdG8gYW4gSUVURg0KDQpkcmFmdCB0aGF0IHByb3Bvc2VzIGFu IGFsdGVybmF0aXZlIHNvbHV0aW9uIGFuZCBwcm92aWRlIGEgcG9pbnQNCg0KYnkgcG9pbnQgZXZh bHVhdGlvbiBvZiBob3cgd2VsbCBlYWNoIHNvbHV0aW9uIGFkZHJlc3NlcyB0aGUgbnVtYmVyZWQN Cg0KcmVxdWlyZW1lbnRzIDkyLi4xMDkuDQoNCg0KDQpTdGV3YXJ0IChhcyBhbiBpbmRpdmlkdWFs IGNvbnRyaWJ1dG9yKQ0KDQoNCk9uIDAyLzEwLzIwMTIgMTY6MTAsIEQnQWxlc3NhbmRybyBBbGVz c2FuZHJvIEdlcmFyZG8gd3JvdGU6DQoNCkRlYXIgTnVyaXQsDQoNClRoZXJlIGFyZSBtYW55IHBv aW50cyB3ZSBjYW4gZGlzY3VzcyBhYm91dCB0aGUgcHJvcG9zZWQgZHJhZnQgYnV0IGxldCBtZSBw b2ludCBvdXQgaW5pdGlhbGx5IGp1c3QgUjEwMCwgUkZDNTY1NC4NCg0KDQoNCkJlc3QgcmVnYXJk cywNCg0KQWxlc3NhbmRybw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGVsZWNvbSBJdGFsaWENCg0KQWxlc3Nh bmRybyBHZXJhcmRvIEQnQWxlc3NhbmRybw0KDQpUcmFuc3BvcnQgSW5ub3ZhdGlvbg0KDQpWaWEg UmVpc3MgUm9tb2xpLCAyNzQgLSAxMDE0OCBUb3Jpbm8NCg0KcGhvbmU6ICArMzkgMDExIDIyOCA1 ODg3DQoNCm1vYmlsZTogKzM5IDMzNSA3NjYgOTYwNw0KDQpmYXg6ICszOSAwNiA0MTggNjM5IDA3 DQoNCg0KDQoNCg0KLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCg0KRGE6IFNwcmVjaGVy LCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKSBbbWFpbHRvOm51cml0LnNwcmVjaGVyQG5z bi5jb21dDQoNCkludmlhdG86IG1hcnRlZKisIDIgb3R0b2JyZSAyMDEyIDE2OjA0DQoNCkE6IEQn QWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG87IExvYSBBbmRlcnNzb24NCg0KQ2M6IG1wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y ZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBNUExTLVRQIGFkIGhvYyB0ZWFt OyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPg0KDQpP Z2dldHRvOiBSRTogW21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYt bXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0KDQoNCkFsZXNzYW5kcm8gYW5kIG90aGVycyB0aGF0 IHN1cHBvcnRlZCB0aGUgYmVsb3csDQoNCllvdXIgc3RhdGVtZW50IGJlbG93IGRvZXMgbm90IHBy b3ZpZGUgYW55IGluZGljYXRpb24gbm9yIHRlY2huaWNhbCBqdXN0aWZpY2F0aW9uIHdoaWNoIHJl cXVpcmVtZW50cyBhcmUgbm90IGFkZHJlc3NlZCBhbmQgd2h5IGRvIHlvdSB0aGluayB0aGV5IGFy ZSBub3QgYWRkcmVzc2VkLi4uLi4NCg0KSGVuY2UgaXQgaXMgaW1wb3NzaWJsZSB0byByZWZlciB0 byBvciBjb25zaWRlciBzdWNoIExDIGNvbW1lbnQgYXMgc3VjaCwgdW5sZXNzIHlvdSBwcm92aWRl IHRlY2huaWNhbCBhcmd1bWVudHMgdGhhdCB3ZSBjYW4gZGlzY3VzcyBhbmQgY29uc2lkZXIuDQoN CkJlc3QgcmVnYXJkcywNCg0KTnVyaXQNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KDQpGcm9tOiBleHQgRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbyBbbWFpbHRv OmFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdF0NCg0KU2VudDogTW9uZGF5 LCBPY3RvYmVyIDAxLCAyMDEyIDI6MjcgUE0NCg0KVG86IExvYSBBbmRlcnNzb24NCg0KQ2M6IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRm Lm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBNUExTLVRQIGFkIGhvYyB0 ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPG1h aWx0bzpkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPg0K DQpTdWJqZWN0OiBSOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0 Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQoNCg0KRG8gbm90IHN1cHBvcnQNCg0KDQoNCkFj Y29yZGluZyB0byB0aGUgb3B0aW1pemF0aW9uIGNyaXRlcmlhIGZvciByaW5nIHByb3RlY3Rpb24g c3BlY2lmaWVkIGluIFNlY3Rpb24gMi41LjYuMSBpbiBSRkM1NjU0LCB0aGUgTVBMUy1UUCByaW5n IHByb3RlY3Rpb24gc2hvdWxkIGJlIG9wdGltaXplZCBmb3Igc2ltcGxpZmljYXRpb24gb2YgdGhl IHJpbmcgb3BlcmF0aW9uIGFuZCB0aGUgcmVzb3VyY2VzIGNvbnN1bXB0aW9uIGFyb3VuZCB0aGUg cmluZy4gSXQgaXMgbm90IHRoZSBjYXNlIG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbi4NCg0KSXQg aXMgYWN0dWFsbHkgc2ltcGx5IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IG9mIGEgbGluZWFy IHByb3RlY3Rpb24gbWVjaGFuaXNtIGJ1dCBpdCBjYW5ub3QgYmUgY29uc2lkZXIgYSBzb2x1dGlv biB0aGF0IGFkZHJlc3NlcyB0aGUgcmVxdWlyZW1lbnRzIGZvciBwcm90ZWN0aW9uIG9mIHJpbmcg dG9wb2xvZ2llcyBmb3IgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIFRyYW5zcG9ydCBQ cm9maWxlIChNUExTLVRQKSBhcyBzcGVjaWZpZWQgaW4gUkZDNTY1NC4NCg0KDQoNCkJlc3QgcmVn YXJkcywNCg0KQWxlc3NhbmRybw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRlbGVjb20gSXRhbGlhDQoN CkFsZXNzYW5kcm8gR2VyYXJkbyBEJ0FsZXNzYW5kcm8NCg0KVHJhbnNwb3J0IElubm92YXRpb24N Cg0KVmlhIFJlaXNzIFJvbW9saSwgMjc0IC0gMTAxNDggVG9yaW5vDQoNCnBob25lOiAgKzM5IDAx MSAyMjggNTg4Nw0KDQptb2JpbGU6ICszOSAzMzUgNzY2IDk2MDcNCg0KZmF4OiArMzkgMDYgNDE4 IDYzOSAwNw0KDQoNCg0KDQoNCi0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0tDQoNCkRhOiBt cGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBIZWppYQ0KDQpJbnZpYXRvOiBz YWJhdG8gMjkgc2V0dGVtYnJlIDIwMTIgMTI6NTMNCg0KQTogTG9hIEFuZGVyc3Nvbg0KDQpDYzog bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IE1QTFMtVFAgYWQgaG9j IHRlYW07IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc+ DQoNCk9nZ2V0dG86IFJlOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQt aWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQoNCg0KRG8gbm90IHN1cHBvcnQuDQoNCg0K DQpCYXNlZCBvbiB0aGUgYW5hbHlzaXMgaW4gU2VjdGlvbiAyLjQgb2YgZHJhZnQtaWV0Zi1tcGxz LXRwLXJpbmctcHJvdGVjdGlvbi0wMiwgdGhlIHJpbmcgcHJvdGVjdGlvbiBzY2hlbWUgdXNpbmcg U1BNRSBhcyBkZXNjcmliZWQsIGVpdGhlciB3cmFwcGluZyBvciBzdGVlcmluZywgZG9lcyBoYXZl IGRlZmljaWVuY2llcywgd2hpY2ggSU1ITyBzaG91bGQgYmUgYmV0dGVyIHJlY29uc2lkZXJlZCBh bmQgc29sdmVkIGlmIHBvc3NpYmxlLg0KDQoNCg0KDQoNCkIuUi4NCg0KSmlhDQoNCg0KDQotLS0t LdPKvP7Urbz+LS0tLS0NCg0Kt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g TG9hIEFuZGVyc3Nvbg0KDQq3osvNyrG85DogMjAxMsTqOdTCMTnI1SAxODo0OQ0KDQqzrcvNOiBt cGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgTVBMUy1UUCBhZCBob2MgdGVhbTsg ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZzxtYWlsdG86 ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZz47IG1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4N Cg0K1vfM4jogW21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBs cy10cC1yaW5nLXByb3RlY3Rpb24NCg0KDQoNCldvcmtpbmcgR3JvdXAsDQoNCg0KDQp0aGlzIGlz IHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCg0KZHJhZnQt aWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMi10eHQuDQoNCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IHRoZXJlIGFyZSB0d28gSVBSIGRpc2Nsb3N1cmVzICMgMTQ2MiBhbmQgICMgMTg3Mg0KDQpy ZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRz IHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0cw0KDQoobXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pLg0KDQoNCg0KVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIGVuZHMgT2N0b2JlciAzLCAyMDEyLg0KDQoNCg0KL0xvYQ0KDQpmb3IgdGhlIG1wbHMgd2cg Y28tY2hhaXJzDQoNCg0KDQoNCg0KLS0NCg0KDQoNCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAg ICAgICAgICAgICAgICAgIGVtYWlsOiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbTxtYWlsdG86 bG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20+DQoNClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMg TWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KDQpFcmljc3Nv biBJbmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEzDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzY3IDcy IDkyIDEzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCm1wbHMgbWFpbGluZyBsaXN0DQoNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQptcGxzIG1haWxp bmcgbGlzdA0KDQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQoNClF1ZXN0byBtZXNzYWdn aW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxl IHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJh IGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25p IHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVl c3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRh cm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBh bGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQoNCg0KVGhpcyBlLW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlv biwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlz ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5 IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0KDQoNCg0KDQouDQoNCg0KDQoNCg0KDQotLQ0KDQpG b3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOg0KDQoNCg0KaHR0cDovL3d3dy5j aXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sDQoN Cg0K --_000_A1F769BC58A8B146B2EEA818EAE052A2098C94193DGRFMBX702RM00_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear Stewart, dear Nurit,

&n= bsp;

Cit=
ing Stewart=A1=AFs answer
 
 =A1=B0The MUST is that all other req=
uirements MUST be met, and the SHOULD
is that the solution SHOULD be those in general transport networ=
ks, 
which is actually is n=
ot a ring specific statement. Indeed by 
reusing the mesh approach (RFC6378) we comply with that req=
uirement 
since the mesh so=
lution are by definition "identical to those in 
=
general transport networks"=A1=B1  =
;

 

indeed I do not believe th= at we comply with the requirements =A1=B0MUST=A1=B1 refers to.

 

More specifically, as an example,

RFC 5654, Req. 106B:  =A1=B0MPLS-TP recovery mechanisms in a ring SHOULD protect against = multiple failures=A1=B1

=  = ; What is the solution (and relevant operation/configuration cost) i= n the proposed draft when two adjacent nodes fail? Did we investigate furth= er approaches before considering current draft as the protection solution f= or ring topologies?

 =

Another example:<= /p>

RFC 5654, Req. 105:  =A1=B0It MUST be possible to lockout (disable) protection mechanism= s on selected links (spans) in a ring=A1=B1

<= p class=3DMsoNormal>Do we comply with that requirement?  What is the proposed solution (and relevant op= eration/configuration cost) to satisfy the requirement?

 

&= nbsp;

If we look into the draft-ietf-mpls-tp-ring-protecti= on, e.g. for the wrapping solution, we find the following:

 

Section 1.  Introduction

=A1=B0We show that this mechanism provide= s the ability to    = protect all of the basic conditions within a reasonable time frame    and does optimize the cri= teria set out in [TPReqs] as summarized    above.=A1=B1=

Does the proposed solution optimize the cr= iteria as specified in=   [TPReqs]? I rose the point= in a previous email on October 2nd to Stewart Bryant.

Was the proposed solution compared with other appr= oaches to better understand pro and cons (e.g. respect to the criteria abov= e mentioned and respect to the overall behavior and complexity)?=

 = ;

Section 1.1.  Problem statement

=A1=B0In either of these two situations, there is a need to add= ress the   following diff= erent cases  -

3.  An operator command is issued to a= specific ring node.  A  description of the different operator commands is found in Section 4.12 of [RFC4427= ].  Examples of these commands= include  = Manual Switch, Forced Switch, or Clear operations.=A1=B1<= /span>

I did not find the Freeze command as speci= fied in section 4.13 of RFC 4427 in the proposed solution. What are the com= mands that draft-ietf-mpls= -tp-ring-protection support?<= /span>

Obs= :  reference should be to sect= ion 4.13 of RFC4427 and not to section 4.12

 

<= p class=3DMsoNormal>Section 2.1.  Wrapping

= =A1=B0Configurat= ion of the protection being performed (i.e.   link protection or node pro= tection) needs to be performed  =   a-priori, since the configuration of the proper protection pa= th is   dependent upon th= is decision.=A1=B1

I believe th= is is a consequence of the proposed solution and not the general behavior t= hat operator should expect for ring based protection. That clearly  shows  draft-ietf-mpls-tp-ring-= protection limitations in terms of optimization for ring based  topology it is intended for <= /span>

 =

 

Section 2.3.4.  Wrapping for link and node protection

  =A1=B0 = In= addition, the neighboring LSR, that detects the fault,    cannot readily differentiate between= a link failure or a node   = ; failure.

   It would be possible to configure extra SPME to prote= ct both for link    = and node failures, arriving at a configuration of the ring that is    shown in Figure 5.  Choosing the SPME to use for the wr= apping would,  however, then involve considerable effort and could result in t= he    protected traf= fic not sharing the same protection path in both    directions.=A1=B1

Self-explaining=A1=AD anyway I believe this is a consequ= ence of the proposed solution and not the general behavior that operator sh= ould expect for ring based protection. That clearly sho= ws  draft-ietf-mpls-tp-ring-protection limitations in terms of optimization for ring to= pology it is intended for

 

 

=

So, there are two main points I rose:

1.Com= pliance to requirements

2.      = ; Limitations and complexity that are clea= rly stated in the document itself

 

Those points b= ring me to consider the draft not still mature.

 

Best regards,

Alessandro

-------------------------------------------------------= -----------
Telecom Italia
Alessandro Gerardo D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  += 39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

<= p class=3DMsoNormal> 

Da: Stewart Bryant [= mailto:stbryant@cisco.com]
= Inviato: marted=A8=AC = 2 ottobre 2012 19:11
A: D'Alessandro = Alessandro Gerardo
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; mpls-chairs@tools.ietf.o= rg; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org<= br>Oggetto: Re: [AHMPLS-TP] R: [<= span class=3DSpellE>mpls] Working group last call on draft-ietf-mpls-tp-ring-protection

 

The te= xt in 100 says:

"100  Recovery techniques in a ring SHOULD be identical (o=
r as similar
 &n=
bsp;    as possible) to those in general transport ne=
tworks to simplify
&n=
bsp;     implementation and operations.  However, this MUST NOT override<=
/o:p>
    &n=
bsp; any other requirement."
 
The MUST is that all other requirements MUST be met, and the=
 SHOULD
is that the solution SHOULD be those in genera=
l transport networks, 
which is actually is not a ring=
 specific statement. Indeed by 
reusing the mesh appro=
ach (RFC6378) we comply with that requirement 
since t=
he mesh solution are by definition "identical to those in <=
/pre>
general transport networks".
 =
;
A more productive review approach might be to point to an=
 IETF 
draft that proposes an alternative solution and=
 provide a point
by point evaluation of how well each =
solution addresses the numbered
requirements 92..109.<=
o:p>
 
Stewart (as an individual =
contributor)


On 02/10/2012 16:10, D'Alessandro Alessa=
ndro Gerardo wrote:
= 
Dear Nurit, 
There are many points we=
 can discuss about the proposed draft but let me point out initially just R=
100, RFC5654.
 
Best regards,
Alessandro
------------------------------------------------------------=
------
Telecom Italia
Alessandro Gerardo D'Alessandro
=
Transport Innovation
Via Reiss =
Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607<=
o:p>
fax: +39 06 418 639 07
 
 
-----Messag=
gio originale-=
----
Da: Sprecher, =
Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com] 
Inviato: marted=A8=
=AC 2 ottobre 2012 16:04
A: D'Alessandro Alessandro Gerardo; Loa Andersson=

Cc: mpls@ietf=
.org; mpls-chairs@tools.i=
etf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.o=
rg
Oggetto: RE: [mpls] Working group last call on =
draft-ietf-mpls-tp-ring-protection
 
Alessandro and others that supported the below,
Your statement below does not provide any indication nor technical justi=
fication which requirements are not addressed and why do you think they are=
 not addressed.....
Hence it is impossible to refer to=
 or consider such LC comment as such, unless you provide technical argument=
s that we can discuss and consider. 
Best regards,
Nurit
 
 
-----Original Message-----
<=
span lang=3DIT style=3D'mso-ansi-language:IT'>From: ex=
t D'Alessandro Alessandro Gerardo [mailto:alessandro.dalessandro@telecomitalia.it] 
Sent: Mond=
ay, October 01, 2012 2:27 PM
To: Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MP=
LS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org
Subject: R: [mpls] Working group last call on draft-ietf-mpls-=
tp-ring-protection
 
Do not =
support
 
According to the o=
ptimization criteria for ring protection specified in Section 2.5.6.1 in RF=
C5654, the MPLS-TP ring protection should be optimized for simplification o=
f the ring operation and the resources consumption around the ring. It is n=
ot the case of the proposed solution.
It is actually s=
imply an applicability statement of a linear protection mechanism but it ca=
nnot be consider a solution that addresses the requirements for protection =
of ring topologies for Multi-Protocol Label Switching Transport Profile (MP=
LS-TP) as specified in RFC5654.
 
Best regards,
Alessandro
 
-------------------------------------=
-----------------------------
Telecom Italia
Alessandro Gerardo D'Alessandr=
o
Transport Innovation=

Via Reiss Romoli, 274 - 10148 Tori=
no
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +=
39 06 418 639 07
 
 
-----Messaggio<=
/span> originale-----
Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Hejia
Inviato: sabato 29 settembre 2012 12:53
A: Loa=
 Andersson
Cc: mpls@ietf.org; mpls-chai=
rs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@to=
ols.ietf.org
Oggetto: Re: [mpls] Working group las=
t call on draft-ietf-mpls-tp-ring-protection
&nbs=
p;
Do not support.
 
Based on the analysis in Section 2.4 of draft-ietf-mpls-tp-ring-pr=
otection-02, the ring protection scheme using SPME as described, either wra=
pping or steering, does have deficiencies, which IMHO should be better reco=
nsidered and solved if possible.
 
 
B.R.
Jia=

 
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=
=ED Loa Andersson
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA9=D4=C219=
=C8=D5 18:49
=B3=AD=CB=CD: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf=
-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: [mpls] Working group last call on draft-=
ietf-mpls-tp-ring-protection
 
Working Group,
 
this is =
to start a two week working group last call on
draft-i=
etf-mpls-tp-ring-protection-02-txt.
 <=
/pre>
Please note that there are two IPR disclosures # 1462 and  # 1872
related =
to this document.
 
Please s=
end your comments to the mpls working group mailing lists
<=
pre>(mpls@ietf.org).
<=
pre> 
The working group last call ends October 3,=
 2012.
 
/Loa
for the mpls wg co-chairs
 
 
--
 
 
Loa Andersson          &nbs=
p;            &=
nbsp; email: loa.ander=
sson@ericsson.com
Sr Strategy and Standards Manage=
r       =
;     loa@pi.nu=

Ericsson Inc &n=
bsp;            =
;            =
phone: +46 10 717 52 13
            =
            &nb=
sp;            =
         +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls=

_______________________________________________<=
/o:p>
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls<=
/a>
 
Questo messaggio e i suoi allegati sono indirizza=
ti esclusivamente alle persone indicate. La diffusione, copia o qualsiasi a=
ltra azione derivante dalla conoscenza di queste informazioni sono rigorosa=
mente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicaz=
ione al mittente e di provvedere alla sua distruzione, Grazie.
 <=
/o:p>
This e-mail and any attachments =
is confidential and may contain privileged information intended for =
the addressee(s) only. Dissemination, copying, printing or use by anybody e=
lse is unauthorised. If you are not the intended recipient, please delete t=
his message and any attachments and advise the sender by return e-mail, Tha=
nks.
 
 
.
 


= 

-- 
For corporate legal information go to=
:
 
http://www.cisco.com=
/web/about/doing_business/legal/cri/index.html
 
= --_000_A1F769BC58A8B146B2EEA818EAE052A2098C94193DGRFMBX702RM00_-- From chengwq@gmail.com Wed Oct 3 07:53:00 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B7621F8667 for ; Wed, 3 Oct 2012 07:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgxoFEkJypL5 for ; Wed, 3 Oct 2012 07:52:59 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C15421F864D for ; Wed, 3 Oct 2012 07:52:59 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so9328423vcb.31 for ; Wed, 03 Oct 2012 07:52:58 -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:content-transfer-encoding; bh=5tsMQoqyyACiR7UwFYi+ScJACut+6rjeUihhSN2KJTw=; b=n9kS2PAPrwigX10EMxXpWUdZhttGGRsg3g8GdXtTYz+3mXyqbdY/nVthhYOaSovUp4 BbXgbNXvKENdz1nsgfwiDgicq+jFFgbge/u3FQfKPNGX2PjLaVS6MVms+ycWJr9Te1oz pVP1JuQk9REwb4NCC2WetP/LY+yHuIOMFqhueqXaivfVxIqUhuECxrgpB+Ue/F8voMEv 3dQTaPh5g1573p1Ma1XJNMAvFkSEG977xWzq6l7UTXkvLf1NzFw6iQVK8pWvLVJmrEo5 F8bHWLQaRnYDyQjdMRfbMYEP4yM5J4tlmp4jXH7oTQHcUvj67ZQtuRNlI7/xbwf8yZfw efRw== MIME-Version: 1.0 Received: by 10.59.0.41 with SMTP id av9mr1326713ved.32.1349275978406; Wed, 03 Oct 2012 07:52:58 -0700 (PDT) Received: by 10.58.28.210 with HTTP; Wed, 3 Oct 2012 07:52:58 -0700 (PDT) In-Reply-To: <0e2901cda16b$09f5d1d0$1de17570$@olddog.co.uk> References: <0e2901cda16b$09f5d1d0$1de17570$@olddog.co.uk> Date: Wed, 3 Oct 2012 22:52:58 +0800 Message-ID: From: cheng weiqiang To: adrian@olddog.co.uk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 14:53:00 -0000 Adrian, Thank you very much for your prompt and detailed reply. I need more time to digest it. However, the current draft is really not mature to get WG consensus. Do you agree? B.R. Cheng Weiqiang 2012/10/3 Adrian Farrel : > Hi, > > > > Thanks for taking the time to set out your concerns. > > > > I hope this now gives the WG something to work with. > > > > With regard the first point, I hope to hear from the authors whether you > have identified a scenario where linear protection will not work (in whic= h > case they should probably flag this short-coming in the I-D) or if they c= an > see how linear protection can handle the double failure case you have > illustrated. > > > > Obviously, we don't have access to C-2098 and can't take it as input to t= he > IETF discussions, so if its authors (was that you?) want to take that > material as contribution to the MPLS WG's work, you need to submit it eit= her > as an Internet-Draft or as email. > > > > The second of your discussion points is related to Section 2.5.6.1 of RFC > 5654, and specifically R100. I reproduce it here for our readers: > > > > 100 Recovery techniques in a ring SHOULD be identical (or as similar > > as possible) to those in general transport networks to simplify > > implementation and operations. However, this MUST NOT override > > any other requirement. > > > > I think the authors need to address this point, but my understanding is t= hat > the whole section is intended to describe the requirements that have to b= e > satisfied by topology-specific solutions. Thus, if we were inventing a ne= w > protection solution applicable in rings then we would need to address the= se > requirements directly. However, I believe that the I-D that is in last ca= ll > is called "Applicability of MPLS-TP Linear Protection for Ring Topologies= ". > That is, it does not define a new mechanism, but specifically shows how t= he > general mechanism can be applied. > > > > Obviously, I can't speak for the WG, but it would seem to me that nothing= in > this I-D precludes the development of a topology-specific solution for ri= ngs > that meets the optimization criteria in Section 2.5.6.1 of RFC 5654 and a= lso > addresses the specific requirements in that section. It also seems to me > that the I-D in question is not a protocol specification at all (note tha= t > it is an Informational draft) and actually does not even describe anythin= g > other than how linear protection might apply in a ring topology. > > > > So I am not quite sure why you believe that the failure of the generic > solution to address a requirement intended to describe optimizations is a > reason to not publish this document. Rather, in your shoes, I would see i= t > as an encouragement to do topology-specific work to follow on from this > current I-D. > > > > Cheers, > > Adrian > > > >> -----Original Message----- > >> From: cheng weiqiang [mailto:chengwq@gmail.com] > >> Sent: 03 October 2012 10:40 > >> To: adrian@olddog.co.uk > >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring- > >> protection@tools.ietf.org; larryli888@yahoo.com.cn > >> Subject: Re: [mpls] Working group last call on >> draft-ietf-mpls-tp-ring-protection > >> > >> Dear adrian, > >> > >> Here I would like to try to describe some issues on the ring > >> protection solution from my point view. > >> > >> 1. The Wrapping solution doesn=92t work when Multi-links faults happen > >> > >> For each link in the ring, current wrapping solution defines two SPME > >> - the first is a SPME between the two LSRs that are connected by the > >> link,and the second SPME > >> > >> between these same two LSRs but traversing the entire ring (except the > >> link that connects the LSRs). > >> > >> ___ ___ x ___ > >> =3D=3D=3D=3D=3D=3D>/LSR\********/LSR\********/LSR\ > >> \_B_/ \_A_/ \_F_/ > >> * * > >> * * > >> * *x > > _* ___ *_ > >> /LSR\********/LSR\********/LSR\=3D=3D=3D=3D=3D=3D> > >> \_C_/ \_D_/ \_E_/ > >> > >> =3D=3D=3D> connected LSP *** physical link > >> x link fault > >> > >> > >> Above figure shows that One LSP enter the ring from LSR B and Exit > >> from LSR E. And at the same time the link A-F and link F-E are both > >> broken. According to current solution, both the protection SPME for > >> A-F and the protection SPME for Link F-E should be activated > >> synchronously. Obviously, it does not work. > >> > >> At the same situation, the ring protection for SDH, G.8132(T-MPLS) and > >> the MSRP solution (C-2098 =93MPLS-TP Shared-Ring protection (MSRP) > >> mechanism for ring topology", ITU-T SG15 meeting, Sep. 2012) can > >> work well. > >> > >> 2.Steering function is totally the same with 1:1 linear protection > >> > >> As the draft mentioned "we use 1:1 linear protection [SurvivFwk] > >> [LinProtect] to perform protection switching and coordination when a > >> signal fault is detected." It is the basic 1:1 linear protection(we > >> can see it as a SNC protection, in another words 1:1 linear > >> protection is using in sub-network). > >> > >> It does not provide any more simplicity and optimism than 1:1 linear > >> protection. That is why we say this draft cannot meet R100 of RFC5654 > >> the requirement. > >> > >> So I don't think we need defined it in the ring draft redundantly again. > >> > >> Best Regards, > >> > >> Cheng Weiqiang > >> Research Institute of China Mobile > >> e-mail:chengweiqiang@chinamobile.com > >> mobile: +86 138 1001 9089 > >> > >> > >> > >> > >> 2012/10/2 Adrian Farrel : > >> > Hi, > >> > > >> > Let me pitch in here as an individual contributor who sourced a lot of >> > the text > >> > in 2.5.6.1 of RFC 5654 basing it on the explicit requirements liaised >> > from the > >> > ITU-T. > >> > > >> > I have read and reread that section trying to find the text that is >> > claimed > >> > below. It does not exist. > >> > > >> > Could you please point to the specific requirement you believe is not >> > met? Or > >> > maybe you are confused by the preamble text in the section that >> > describes the > >> > circumstances under which an optimized protection mechanism (rather th= an > >> > one built from the mechanisms that operate outside a ring) might be >> > developed. > >> > > >> > Maybe, also, you could explain in what way you consider the current >> > proposal > >> > does not make good use of the resources on the ring (i.e. what feature= s >> > don't > >> > work) so that the authors can look at improving their solution. > >> > > >> > Cheers, > >> > Adrian > >> > > >> >> -----Original Message----- > >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of > >> >> cheng weiqiang > >> >> Sent: 02 October 2012 14:02 > >> >> To: mpls-bounces@ietf.org > >> >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-rin= g- > >> >> protection@tools.ietf.org > >> >> Subject: Re: [mpls] Working group last call on > >> > draft-ietf-mpls-tp-ring-protection > >> >> > >> >> Do not support. > >> >> > >> >> In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should be > >> >> optimized for simplification of the ring operation and the resources > >> >> consumption around the ring. This draft cannot meet the requirement. > >> >> > >> >> Best Regards, > >> >> > >> >> Cheng Weiqiang > >> >> Research Institute of China Mobile > >> >> Department of Network Technology > >> >> _______________________________________________ > >> >> mpls mailing list > >> >> mpls@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/mpls > >> > From alessandro.dalessandro@telecomitalia.it Wed Oct 3 08:03:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24AB21F8437 for ; Wed, 3 Oct 2012 08:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHkSp08CmV5p for ; Wed, 3 Oct 2012 08:03:23 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4A321F8673 for ; Wed, 3 Oct 2012 08:03:22 -0700 (PDT) Content-Type: multipart/mixed; boundary="_470a21cd-bca1-4795-8c93-182cc1b97c7b_" Received: from grfhub701rm001.griffon.local (10.19.3.8) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 3 Oct 2012 17:03:18 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by grfhub701rm001.griffon.local ([10.19.9.234]) with mapi; Wed, 3 Oct 2012 17:03:18 +0200 From: D'Alessandro Alessandro Gerardo To: "mpls@ietf.org" Date: Wed, 3 Oct 2012 17:03:18 +0200 Thread-Topic: R: Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2hYg5aMcZnMPgITOyycStN+P6juA== Message-ID: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:03:24 -0000 --_470a21cd-bca1-4795-8c93-182cc1b97c7b_ Content-Type: multipart/alternative; boundary="_000_A1F769BC58A8B146B2EEA818EAE052A2098C941A04GRFMBX702RM00_" --_000_A1F769BC58A8B146B2EEA818EAE052A2098C941A04GRFMBX702RM00_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors of draft-ietf-mpls-tp-ring-protection-02, Could you please clarify the following points 2.1. Wrapping In this figure we have a ring with a LSP that enters the ring at LSR-= B and exits at LSR-E. The normal working path follows through B-A-F-E. = If a fault is detected on the link A<-->F, then the wrapping mechanism de= cides that LSR-A would wrap the traffic around the ring, on a wrapped da= ta path A-B-C-D-E-F, to arrive at LSR-F (on the far side of the failed l= ink). LSR-F would then wrap the data packets back onto the working path= F-->E to the egress node. In this protection scheme, the traffic will = follow the path B-A-B-C-D-E-F-E. Figure 1 and the text above seems not to be aligned. What is the intended b= ehavior? 2.1. Wrapping If a double-fault situation occurs in the ring, then wrapping will not = be able to deliver any packets except between the ingress and the first f= ault location. How is defined first/second fault location in a ring? is "first" time or l= ocation related? Can you please elaborate a little bit this concept? Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro Gerardo D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non ? necessario. --_000_A1F769BC58A8B146B2EEA818EAE052A2098C941A04GRFMBX702RM00_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear authors of draft-ietf-mpls-tp-ring-protection-0= 2,

Could you please clarify the following points

 

2.1.  Wrapping

   In this figure we have a ring with a LSP that enters the ring at    LSR-B and exits at LSR-E.  The normal working path follows through   B-A-F-E.  If a fault is= detected on the link A<-->F, then the   wrapping mechanism decides that LSR-A would wrap the traffic around<= span style=3D"mso-spacerun:yes">    the ring, on a wrapped data path A-B-C-D-E-F, to arrive at LSR-F (on=     the far side of the failed link).&n= bsp; LSR-F would then wrap the data=     packets back onto the working path F-->E to the egress node.  In this    pr= otection scheme, the traffic will follow the path    B-A-B-C-D-E-F-E.

Figure 1 and the text abov= e seems not to be aligned. What is the intended behavior? <= /span>

 

 

2.1.  Wrapping

If a double-fault situation occurs in the ring, then= wrapping will     not be able to deliver any packets except between the ingress and   the first fault location.

How is defined first/second  fault location in a ring? is = 220;first” time or location related? Can you please elaborate a littl= e bit this concept?

 

Best regards,

Alessandro

--------------------------------------------------------------= ----
Telecom Italia<= br> Alessandro Ger= ardo D'Alessandro
Transport Innovation
Via Reiss Romoli, = 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_A1F769BC58A8B146B2EEA818EAE052A2098C941A04GRFMBX702RM00_-- --_470a21cd-bca1-4795-8c93-182cc1b97c7b_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_470a21cd-bca1-4795-8c93-182cc1b97c7b_-- From chengwq@gmail.com Wed Oct 3 08:24:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BAE21F8496 for ; Wed, 3 Oct 2012 08:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dP8tlpWHv5v2 for ; Wed, 3 Oct 2012 08:24:04 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2343E21F841E for ; Wed, 3 Oct 2012 08:23:30 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so9099222vbb.31 for ; Wed, 03 Oct 2012 08:23:29 -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=m83SClvZfQ3zvctAn404K52x8OQk/RaBlD2hKFX5B5U=; b=qRmYCUbRlC7TAcoobbHTUY0QcOo6OywCW+NiV+eC+iZ1u82c9Iljjks9IO0yVXs5Lz Doiu95SwXW6nCt1mnYhAdzHFD0SyxAF2d8uJlekr9B40tM66+SLGAATI4oG/ZXeaRUHw 8CoYS6htQgtzaa1vLQjTkOuzJIdKNbXiz8Dk3fjYotr3qp7QxmeyCcxItWxEQ6TGjCro Atfe0o1hrBHh6gIkY/y6dp372SDpvtxdiTRti1HcO3rt2wazxwfh9I4RVrHqYsf3AtNQ C+4mDM0yQIAFGVEdanrx9oI8dZvocQXSPlAh4a0qBENOGlYpUG6vKOb1txVerXIniVxF kakQ== MIME-Version: 1.0 Received: by 10.220.150.145 with SMTP id y17mr1343618vcv.11.1349277809280; Wed, 03 Oct 2012 08:23:29 -0700 (PDT) Received: by 10.58.28.210 with HTTP; Wed, 3 Oct 2012 08:23:29 -0700 (PDT) In-Reply-To: References: <0e2901cda16b$09f5d1d0$1de17570$@olddog.co.uk> Date: Wed, 3 Oct 2012 23:23:29 +0800 Message-ID: From: cheng weiqiang To: alessandro.dalessandro@telecomitalia.it Content-Type: text/plain; charset=ISO-8859-1 Cc: mpls@ietf.org, ahmpls-tp@lists.itu.int, draft-ietf-mpls-tp-ring-protection@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] [AHMPLS-TP] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:24:04 -0000 Support. And additional question to authors: R27 of RFC 5654 requires " B. It MUST be possible to deploy MPLS-TP in arbitrarily interconnected rings with one or two points of interconnection. " Arccording the draft solution, It seems very hard to implement it. Could you give more information on "How the solution in draft to implement it" ? Best Regards, Cheng Weiqiang Research Institute of China Mobile e-mail:chengweiqiang@chinamobile.com mobile: +86 138 1001 9089 From adrian@olddog.co.uk Wed Oct 3 08:28:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9240121F84D5 for ; Wed, 3 Oct 2012 08:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, J_CHICKENPOX_102=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3gy3NdoZiMa for ; Wed, 3 Oct 2012 08:28:29 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA5321F8491 for ; Wed, 3 Oct 2012 08:28:29 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q93FSR7A018484; Wed, 3 Oct 2012 16:28:27 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q93FSPL1018424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Oct 2012 16:28:26 +0100 From: "Adrian Farrel" To: "'cheng weiqiang'" References: <0e2901cda16b$09f5d1d0$1de17570$@olddog.co.uk> In-Reply-To: Date: Wed, 3 Oct 2012 16:28:24 +0100 Message-ID: <0e7901cda17b$bafe9bf0$30fbd3d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGidtSCY+yDVD9VrzQnns44snOHVgCqtSqzl/iyBPA= Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:28:30 -0000 I'm not going to make any comment about consensus on the document - That is the job of the WG chairs and I am on the appeals path for any such assessment. It seems to me that there are certainly some questions to be answered (that might result in explanations, or might result in caveats being added to the document). It also seems to me that this document is not trying to say "here is the only solution that can ever work in MPLS-TP rings" but is actually saying that here is how you might get protection on a ring using linear protection techniques without the need for specification of new constructs or protocols. as such, I don't believe that corner cases (and frankly, second order failures on a ring should not be regarded as primary design features, should they?) prevent publication, but should be highlighted as potential draw-backs. Thanks, Adrian > -----Original Message----- > From: cheng weiqiang [mailto:chengwq@gmail.com] > Sent: 03 October 2012 15:53 > To: adrian@olddog.co.uk > Cc: mpls@ietf.org > Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Adrian, > > Thank you very much for your prompt and detailed reply. I need more > time to digest it. However, the current draft is really not mature to > get WG consensus. Do you agree? > > B.R. > Cheng Weiqiang > > > 2012/10/3 Adrian Farrel : > > Hi, > > > > Thanks for taking the time to set out your concerns. > > > > I hope this now gives the WG something to work with. > > > > With regard the first point, I hope to hear from the authors whether you > > have identified a scenario where linear protection will not work (in which > > case they should probably flag this short-coming in the I-D) or if they can > > see how linear protection can handle the double failure case you have > > illustrated. > > > > Obviously, we don't have access to C-2098 and can't take it as input to the > > IETF discussions, so if its authors (was that you?) want to take that > > material as contribution to the MPLS WG's work, you need to submit it either > > as an Internet-Draft or as email. > > > > The second of your discussion points is related to Section 2.5.6.1 of RFC > > 5654, and specifically R100. I reproduce it here for our readers: > > > > 100 Recovery techniques in a ring SHOULD be identical (or as similar > > as possible) to those in general transport networks to simplify > > implementation and operations. However, this MUST NOT override > > any other requirement. > > > > I think the authors need to address this point, but my understanding is that > > the whole section is intended to describe the requirements that have to be > > satisfied by topology-specific solutions. Thus, if we were inventing a new > > protection solution applicable in rings then we would need to address these > > requirements directly. However, I believe that the I-D that is in last call > > is called "Applicability of MPLS-TP Linear Protection for Ring Topologies". > > That is, it does not define a new mechanism, but specifically shows how the > > general mechanism can be applied. > > > > Obviously, I can't speak for the WG, but it would seem to me that nothing in > > this I-D precludes the development of a topology-specific solution for rings > > that meets the optimization criteria in Section 2.5.6.1 of RFC 5654 and also > > addresses the specific requirements in that section. It also seems to me > > that the I-D in question is not a protocol specification at all (note that > > it is an Informational draft) and actually does not even describe anything > > other than how linear protection might apply in a ring topology. > > > > So I am not quite sure why you believe that the failure of the generic > > solution to address a requirement intended to describe optimizations is a > > reason to not publish this document. Rather, in your shoes, I would see it > > as an encouragement to do topology-specific work to follow on from this > > current I-D. > > > > Cheers, > > > > Adrian > > > >> -----Original Message----- > > > >> From: cheng weiqiang [mailto:chengwq@gmail.com] > >> Sent: 03 October 2012 10:40 > >> To: adrian@olddog.co.uk > >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring- > >> protection@tools.ietf.org; larryli888@yahoo.com.cn > >> Subject: Re: [mpls] Working group last call on > >> draft-ietf-mpls-tp-ring-protection > > > >> Dear adrian, > > > >> Here I would like to try to describe some issues on the ring > >> protection solution from my point view. > >> > >> 1. The Wrapping solution doesn't work when Multi-links faults happen > >> > >> For each link in the ring, current wrapping solution defines two SPME > >> - the first is a SPME between the two LSRs that are connected by the > >> link, and the second SPME > >> between these same two LSRs but traversing the entire ring (except the > >> link that connects the LSRs). > > > >> ___ ___ x ___ > >> ======>/LSR\********/LSR\********/LSR\ > >> \_B_/ \_A_/ \_F_/ > >> * * > >> * * > >> * *x > > _* ___ *_ > >> /LSR\********/LSR\********/LSR\======> > >> \_C_/ \_D_/ \_E_/ > >> > >> ===> connected LSP *** physical link > >> x link fault > >> > >> Above figure shows that One LSP enter the ring from LSR B and Exit > >> from LSR E. And at the same time the link A-F and link F-E are both > >> broken. According to current solution, both the protection SPME for > >> A-F and the protection SPME for Link F-E should be activated > >> synchronously. Obviously, it does not work. > >> > >> At the same situation, the ring protection for SDH, G.8132(T-MPLS) and > >> the MSRP solution (C-2098 "MPLS-TP Shared-Ring protection (MSRP) > >> mechanism for ring topology", ITU-T SG15 meeting, Sep. 2012) can > >> work well. > >> > >> 2.Steering function is totally the same with 1:1 linear protection > >> > >> As the draft mentioned "we use 1:1 linear protection [SurvivFwk] > >> [LinProtect] to perform protection switching and coordination when a > >> signal fault is detected." It is the basic 1:1 linear protection(we > >> can see it as a SNC protection, in another words 1:1 linear > >> protection is using in sub-network). > >> > >> It does not provide any more simplicity and optimism than 1:1 linear > >> protection. That is why we say this draft cannot meet R100 of RFC5654 > >> the requirement. > >> > >> So I don't think we need defined it in the ring draft redundantly again. > >> > >> Best Regards, > >> > >> Cheng Weiqiang > >> Research Institute of China Mobile From RCosta@ptinovacao.pt Wed Oct 3 09:09:15 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203A821F8526 for ; Wed, 3 Oct 2012 09:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdGpJz5A7Dgs for ; Wed, 3 Oct 2012 09:09:14 -0700 (PDT) Received: from owa.ptinovacao.pt (owa.ptinovacao.pt [194.65.138.99]) by ietfa.amsl.com (Postfix) with ESMTP id C302021F84C5 for ; Wed, 3 Oct 2012 09:09:13 -0700 (PDT) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.122]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Wed, 3 Oct 2012 17:09:12 +0100 From: Rui Costa To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , ext D'Alessandro Alessandro Gerardo Date: Wed, 3 Oct 2012 17:09:11 +0100 Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: AQHNllRf82qjNdoiA0OJzsZi6RX7kJehLihwgANBJaCAAa+bgIAADqpQgAAl8oCAAWvD0A== Message-ID: <52981DB05D3C5247A12D0AEE309F3CC20277022C56B4@INOAVREX11.ptin.corpPT.com> References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> In-Reply-To: Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:09:15 -0000 SGVsbG8sCQ0KDQoxLiBSRkMxOTU4IHN0YXRlcyAiSWYgYSBwcmV2aW91cyBkZXNpZ24sIGluIHRo ZSBJbnRlcm5ldCBjb250ZXh0IG9yIGVsc2V3aGVyZSwgaGFzIHN1Y2Nlc3NmdWxseSBzb2x2ZWQg dGhlIHNhbWUgcHJvYmxlbSBbLi4uXSIuCQ0KDQoyLiBUaGlzIGRyYWZ0IGxvb2tzIHF1aXRlIGRp ZmZlcmVudCBmcm9tIEcuODQxJ3Mgc2VjdGlvbnMgYWJvdXQgcmluZ3MgKG9yIEcuODEzMi4xIGRy YWZ0KSwgSU1ITy4gSWYgdGhlcmUncyBhIHByb2JsZW0gd2l0aCB0aGUgbGlhaXNvbiBhY2Nlc3Np YmlsaXR5LCBwZXJoYXBzIHRoZSBleHBpcmVkIGNvbXBhcmlzb24gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQteWFuZy1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi1hbmFseXNpcyBoZWxw cy4JDQoNCjMuIENvdWxkIHRoZSBhdXRob3JzIGV4cGxhaW4sIHJlbWVtYmVyaW5nIHRoZSBSRkMx OTU4IHF1b3RlIGFib3ZlICgiSW50ZXJuZXQgY29udGV4dCBvciBFTFNFV0hFUkUiKSwgd2hhdCdz IHRoZSBiZW5lZml0IG9mIHRoaXMgZHJhZnQgdmVyc3VzIGV4aXN0aW5nIEcuODQxIChKdWwvMTk5 NSkvRy44MTMyLjEgZHJhZnQvZHJhZnQtaGVsdm9vcnQtbXBscy10cC1yaW5nLXByb3RlY3Rpb24t c3dpdGNoaW5nPwkNCg0KNC4gV2hhdCBpcyB0aGUgYmVuZWZpdCBvZiBSRkM2Mzc4IChGZWIyMDEy KSB2ZXJzdXMgZXhpc3RpbmcgRy44NDEoSnVsLzE5OTUpL0cuODEzMS4xIGRyYWZ0IChhZ2Fpbiwg cmVtZW1iZXJpbmcgUkZDMTk1OC4uLik/IFdoYXQgbmV3IGJyaW5ncyBQU0MgdmVyc3VzIEFQUz8J DQoNCjUuIFdoeSBkaWQgd2UgYXBwcm92ZSBSRkM2NjcwLCBlc3NlbnRpYWxseSBzYXlpbmcgIjEg c3RhbmRhcmQncyBiZXR0ZXIgdGhhbiAyIiwgYnV0IGNyZWF0ZSAyIGNvbXBsZXRlbHkgbmV3IHBy b3RlY3Rpb24gc3RhbmRhcmRzLCBhbHRlcm5hdGUgdG8gb3B0aW9ucyBhcmNoaXRlY3R1cmFsbHkg c2ltaWxhciB0byB0aG9zZSB3ZSBoYXZlIGluIHRoZSBmaWVsZCBmb3IgYWxtb3N0IDIweWVhcnM/ CQ0KDQo2LiBXaHkgaXNuJ3QgdGhlIGludGVyc2VjdGlvbiBvZiB0aGUgYXV0aG9ycyBvZiB0aGlz IGRyYWZ0LCBSRkNzIDYzNzggYW5kIDY2NzAsIHRoZSBlbXB0eSBzZXQ/CQ0KDQpSZWdhcmRzLAkN ClJ1aQkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3By ZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pDQpTZW50OiB0ZXLDp2EtZmVpcmEs IDIgZGUgT3V0dWJybyBkZSAyMDEyIDE4OjEyDQpUbzogZXh0IEQnQWxlc3NhbmRybyBBbGVzc2Fu ZHJvIEdlcmFyZG8NCkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y ZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlv bkB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoNCkRlYXIgQWxlc2Fu ZHJvLA0KVGhhbmsgeW91IGZvciBwb2ludGluZyB0byBSLjEwMCAoIlJlY292ZXJ5IHRlY2huaXF1 ZXMgaW4gYSByaW5nIFNIT1VMRCBiZSBpZGVudGljYWwgKG9yIGFzIHNpbWlsYXINCiAgICAgICAg YXMgcG9zc2libGUpIHRvIHRob3NlIGluIGdlbmVyYWwgdHJhbnNwb3J0IG5ldHdvcmtzIHRvIHNp bXBsaWZ5DQogICAgICAgIGltcGxlbWVudGF0aW9uIGFuZCBvcGVyYXRpb25zLiAgSG93ZXZlciwg dGhpcyBNVVNUIE5PVCBvdmVycmlkZQ0KICAgICAgICBhbnkgb3RoZXIgcmVxdWlyZW1lbnQuIiku IA0KZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbiBzdXBwb3J0cyB0aGUgdHdvIHBy b3RlY3Rpb24gYXJjaGl0ZWN0dXJlIG1lY2hhbmlzbXMgZm9yIHJpbmcgdG9wb2xvZ2llcywgYmFz ZWQgb24gU0RIIHNwZWNpZmljYXRpb25zIFtHLjg0MV0sIHRoYXQgaGF2ZSBiZWVuIHByb3Bvc2Vk IGluIHZhcmlvdXMgZm9ydW1zIHRvIHBlcmZvcm0gcmVjb3Zlcnkgb2YgYSB0b3BvbG9naWNhbCBy aW5nIG5ldHdvcmsgLSAid3JhcHBpbmciIGFuZCAic3RlZXJpbmciLiANClNvIGl0IHdpbGwgYmUg Z29vZCB0byB1bmRlcnN0YW5kIGJldHRlciB5b3VyIHRlY2huaWNhbCBjb25jZXJuIG9uIFIxMDAu IA0KQmVzdCByZWdhcmRzLA0KTnVyaXQNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogZXh0IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8gW21haWx0bzphbGVzc2Fu ZHJvLmRhbGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXRdDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVy IDAyLCAyMDEyIDU6MTAgUE0NClRvOiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNo YXJvbikNCkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTVBM Uy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29s cy5pZXRmLm9yZw0KU3ViamVjdDogUjogW21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0KRGVhciBOdXJpdCwNClRoZXJl IGFyZSBtYW55IHBvaW50cyB3ZSBjYW4gZGlzY3VzcyBhYm91dCB0aGUgcHJvcG9zZWQgZHJhZnQg YnV0IGxldCBtZSBwb2ludCBvdXQgaW5pdGlhbGx5IGp1c3QgUjEwMCwgUkZDNTY1NC4NCg0KQmVz dCByZWdhcmRzLA0KQWxlc3NhbmRybw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUZWxlY29tIEl0YWxpYQ0KQWxlc3Nh bmRybyBHZXJhcmRvIEQnQWxlc3NhbmRybw0KVHJhbnNwb3J0IElubm92YXRpb24NClZpYSBSZWlz cyBSb21vbGksIDI3NCAtIDEwMTQ4IFRvcmlubw0KcGhvbmU6wqAgKzM5IDAxMSAyMjggNTg4Nw0K bW9iaWxlOiArMzkgMzM1IDc2NiA5NjA3DQpmYXg6ICszOSAwNiA0MTggNjM5IDA3DQoNCg0KLS0t LS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCkRhOiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElM L0hvZCBIYVNoYXJvbikgW21haWx0bzpudXJpdC5zcHJlY2hlckBuc24uY29tXQ0KSW52aWF0bzog bWFydGVkw6wgMiBvdHRvYnJlIDIwMTIgMTY6MDQNCkE6IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJv IEdlcmFyZG87IExvYSBBbmRlcnNzb24NCkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJp bmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZw0KT2dnZXR0bzogUkU6IFttcGxzXSBXb3JraW5n IGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoN CkFsZXNzYW5kcm8gYW5kIG90aGVycyB0aGF0IHN1cHBvcnRlZCB0aGUgYmVsb3csIFlvdXIgc3Rh dGVtZW50IGJlbG93IGRvZXMgbm90IHByb3ZpZGUgYW55IGluZGljYXRpb24gbm9yIHRlY2huaWNh bCBqdXN0aWZpY2F0aW9uIHdoaWNoIHJlcXVpcmVtZW50cyBhcmUgbm90IGFkZHJlc3NlZCBhbmQg d2h5IGRvIHlvdSB0aGluayB0aGV5IGFyZSBub3QgYWRkcmVzc2VkLi4uLi4NCkhlbmNlIGl0IGlz IGltcG9zc2libGUgdG8gcmVmZXIgdG8gb3IgY29uc2lkZXIgc3VjaCBMQyBjb21tZW50IGFzIHN1 Y2gsIHVubGVzcyB5b3UgcHJvdmlkZSB0ZWNobmljYWwgYXJndW1lbnRzIHRoYXQgd2UgY2FuIGRp c2N1c3MgYW5kIGNvbnNpZGVyLiANCkJlc3QgcmVnYXJkcywNCk51cml0DQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJh cmRvIFttYWlsdG86YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0XQ0KU2Vu dDogTW9uZGF5LCBPY3RvYmVyIDAxLCAyMDEyIDI6MjcgUE0NClRvOiBMb2EgQW5kZXJzc29uDQpD YzogbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IE1QTFMtVFAgYWQg aG9jIHRlYW07IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5v cmcNClN1YmplY3Q6IFI6IFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1p ZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoNCkRvIG5vdCBzdXBwb3J0DQoNCkFjY29yZGlu ZyB0byB0aGUgb3B0aW1pemF0aW9uIGNyaXRlcmlhIGZvciByaW5nIHByb3RlY3Rpb24gc3BlY2lm aWVkIGluIFNlY3Rpb24gMi41LjYuMSBpbiBSRkM1NjU0LCB0aGUgTVBMUy1UUCByaW5nIHByb3Rl Y3Rpb24gc2hvdWxkIGJlIG9wdGltaXplZCBmb3Igc2ltcGxpZmljYXRpb24gb2YgdGhlIHJpbmcg b3BlcmF0aW9uIGFuZCB0aGUgcmVzb3VyY2VzIGNvbnN1bXB0aW9uIGFyb3VuZCB0aGUgcmluZy4g SXQgaXMgbm90IHRoZSBjYXNlIG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbi4NCkl0IGlzIGFjdHVh bGx5IHNpbXBseSBhbiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBvZiBhIGxpbmVhciBwcm90ZWN0 aW9uIG1lY2hhbmlzbSBidXQgaXQgY2Fubm90IGJlIGNvbnNpZGVyIGEgc29sdXRpb24gdGhhdCBh ZGRyZXNzZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgcHJvdGVjdGlvbiBvZiByaW5nIHRvcG9sb2dp ZXMgZm9yIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZyBUcmFuc3BvcnQgUHJvZmlsZSAo TVBMUy1UUCkgYXMgc3BlY2lmaWVkIGluIFJGQzU2NTQuDQoNCkJlc3QgcmVnYXJkcywNCkFsZXNz YW5kcm8NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpUZWxlY29tIEl0YWxpYQ0KQWxlc3NhbmRybyBHZXJhcmRvIEQn QWxlc3NhbmRybw0KVHJhbnNwb3J0IElubm92YXRpb24NClZpYSBSZWlzcyBSb21vbGksIDI3NCAt IDEwMTQ4IFRvcmlubw0KcGhvbmU6ICArMzkgMDExIDIyOCA1ODg3DQptb2JpbGU6ICszOSAzMzUg NzY2IDk2MDcNCmZheDogKzM5IDA2IDQxOCA2MzkgMDcNCg0KDQotLS0tLU1lc3NhZ2dpbyBvcmln aW5hbGUtLS0tLQ0KRGE6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEhlamlhDQpJbnZpYXRvOiBzYWJhdG8gMjkgc2V0dGVt YnJlIDIwMTIgMTI6NTMNCkE6IExvYSBBbmRlcnNzb24NCkNjOiBtcGxzQGlldGYub3JnOyBtcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1t cGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZw0KT2dnZXR0bzogUmU6IFttcGxz XSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90 ZWN0aW9uDQoNCkRvIG5vdCBzdXBwb3J0Lg0KDQpCYXNlZCBvbiB0aGUgYW5hbHlzaXMgaW4gU2Vj dGlvbiAyLjQgb2YgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMiwgdGhlIHJp bmcgcHJvdGVjdGlvbiBzY2hlbWUgdXNpbmcgU1BNRSBhcyBkZXNjcmliZWQsIGVpdGhlciB3cmFw cGluZyBvciBzdGVlcmluZywgZG9lcyBoYXZlIGRlZmljaWVuY2llcywgd2hpY2ggSU1ITyBzaG91 bGQgYmUgYmV0dGVyIHJlY29uc2lkZXJlZCBhbmQgc29sdmVkIGlmIHBvc3NpYmxlLg0KDQoNCkIu Ui4NCkppYQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IG1wbHMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIExvYSBBbmRl cnNzb24NCuWPkemAgeaXtumXtDogMjAxMuW5tDnmnIgxOeaXpSAxODo0OQ0K5oqE6YCBOiBtcGxz QGlldGYub3JnOyBNUExTLVRQIGFkIGhvYyB0ZWFtOyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1w cm90ZWN0aW9uQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0K5Li7 6aKYOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRw LXJpbmctcHJvdGVjdGlvbg0KDQpXb3JraW5nIEdyb3VwLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEg dHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJp bmctcHJvdGVjdGlvbi0wMi10eHQuDQoNClBsZWFzZSBub3RlIHRoYXQgdGhlcmUgYXJlIHR3byBJ UFIgZGlzY2xvc3VyZXMgIyAxNDYyIGFuZCAgIyAxODcyIHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVu dC4NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBscyB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdHMgKG1wbHNAaWV0Zi5vcmcpLg0KDQpUaGUgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgZW5kcyBPY3RvYmVyIDMsIDIwMTIuDQoNCi9Mb2ENCmZvciB0aGUgbXBscyB3ZyBjby1j aGFpcnMNCg0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICAg ZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQpTciBTdHJhdGVneSBhbmQgU3RhbmRh cmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnUNCkVyaWNzc29uIEluYyAgICAgICAgICAg ICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTMNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzY3IDcyIDkyIDEzIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0K bXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBt YWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8g aW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZm dXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNv bm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0 ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBz aWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9u ZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXpp ZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5k IG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRy ZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5 IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVu dHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGlu ZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCg== From RCosta@ptinovacao.pt Wed Oct 3 09:10:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CC721F8522; Wed, 3 Oct 2012 09:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avBNQ3ezP5NJ; Wed, 3 Oct 2012 09:10:50 -0700 (PDT) Received: from owa.ptinovacao.pt (owa.ptinovacao.pt [194.65.138.99]) by ietfa.amsl.com (Postfix) with ESMTP id 71C7E21F846E; Wed, 3 Oct 2012 09:10:49 -0700 (PDT) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.122]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Wed, 3 Oct 2012 17:10:48 +0100 From: Rui Costa To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "Malcolm.BETTS@zte.com.cn" , "mpls@ietf.org" , "mpls-bounces@ietf.org" Date: Wed, 3 Oct 2012 17:10:47 +0100 Thread-Topic: [mpls] FW: Working group last callon draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2gvZYjtV8yD3jlStGX4+AodnfPQwAA5iPgACZMJeA= Message-ID: <52981DB05D3C5247A12D0AEE309F3CC20277022C56B6@INOAVREX11.ptin.corpPT.com> References: <5059A308.3050307@pi.nu> In-Reply-To: Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: multipart/alternative; boundary="_000_52981DB05D3C5247A12D0AEE309F3CC20277022C56B6INOAVREX11p_" MIME-Version: 1.0 Subject: Re: [mpls] FW: Working group last callon draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:10:51 -0000 --_000_52981DB05D3C5247A12D0AEE309F3CC20277022C56B6INOAVREX11p_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VW5kZXJzdG9vZCwgb25jZSB3ZeKAmXJlIHF1b3RpbmcgYW5vdGhlciBTRE/igJlzIGRvY3VtZW50 LCBidXQgbW9yZSBpbXBvcnRhbnQgaXMgYmVpbmcgY29oZXJlbnQgd2l0aCBvdXJzZWx2ZXM6IHdl IGNhbuKAmXQgY3JpdGljaXplIHRvZGF5IGNvbW1lbnRpbmcgYW5vdGhlciBTRE/igJlzIGRvY3Vt ZW50cy9ldmVudHMgd2hlbiB3ZSBkaWQgdGhhdCBzYW1lIHRoaW5nIHllc3RlcmRheSAoaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lldGYvY3VycmVudC9tc2c3MTE3NC5odG1s KSwgaW5jb2hlcmVudGx5IHdpdGggd2hhdCB3ZSBoYWQgd3JpdHRlbiB0aGUgZGF5IGJlZm9yZSAo aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cwNjc1 NS5odG1sKS4NCg0KQSBzdWJqZWN0aXZlIHBvc2l0aW9uIGJyaW5ncyBjb250cmFkaWN0aW9uIGFu ZCBsb3NzIG9mIGxvZ2ljLCBhbmQgaGVuY2Ugb3VyIHJlZmVyZW5jZXMgdG8gdGhlIHdvcmQg4oCc dGVjaG5pY2Fs4oCdIGxvc2UgdGhlaXIgc2VtYW50aWNzLg0KDQpSZWdhcmRzLA0KUnVpDQoNCg0K RnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pDQpT ZW50OiB0ZXLDp2EtZmVpcmEsIDIgZGUgT3V0dWJybyBkZSAyMDEyIDE4OjE0DQpUbzogTWFsY29s bS5CRVRUU0B6dGUuY29tLmNuOyBtcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbbXBsc10gRlc6IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsb24gZHJhZnQt aWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQpUaGFuayB5b3UgTWFsY29sbSENCk9idmlv dXNseSBpdCBpcyBpbXBvc3NpYmxlIHRvIGNvbnNpZGVyIHNvbWV0aGluZyB0aGF0IHdhcyBub3Qg cG9zdGVkLg0KDQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZz4gW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBl eHQgTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuPG1haWx0bzpNYWxjb2xtLkJFVFRTQHp0ZS5jb20u Y24+DQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDAyLCAyMDEyIDY6NDcgUE0NClRvOiBtcGxzQGll dGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgbXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIEZXOiBXb3JraW5n IGdyb3VwIGxhc3QgY2FsbG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0K SSBleHBlY3QgdGhhdCB0aGlzIGxpYWlzb24gd2lsbCBiZSBwb3N0ZWQgaW4gdGhlIG5leHQgZmV3 IGRheXMuDQoNCklUVSBtZW1iZXJzIGNhbiBmaW5kIHRoZSBsaWFpc29uIGFzIEFubmV4IEkgb2Yg VEQ3NDQvUExFTi4NCg0KUmVnYXJkcywNCg0KTWFsY29sbQ0KDQoNCiJTcHJlY2hlciwgTnVyaXQg KE5TTiAtIElML0hvZCBIYVNoYXJvbikiIDxudXJpdC5zcHJlY2hlckBuc24uY29tPG1haWx0bzpu dXJpdC5zcHJlY2hlckBuc24uY29tPj4NClNlbnQgYnk6IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPg0KDQowMi8xMC8yMDEyIDEwOjUxIEFNDQoNClRv DQoNCjxtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4NCg0KY2MNCg0KU3ViamVj dA0KDQpSZTogW21wbHNdIEZXOiBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiAgICAgICAgZHJh ZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQoNCg0KDQoNCg0KDQpEaWQgSSBtaXNz IGFueSBsaWFpc29uIG9uIHRoaXM/DQpUbyB3aGF0IGlzc3VlIGRvIHlvdSByZWZlcj8NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86bXBscy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIGV4dCBFcmljIEdyYXkNClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDIsIDIw MTIgNDoxMCBQTQ0KVG86IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbbXBsc10gRlc6IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBs cy10cC1yaW5nLXByb3RlY3Rpb24NCg0KRm9yd2FyZGVkLi4uDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiB5YW5nLmppYW45MEB6dGUuY29tLmNuPG1haWx0bzp5YW5nLmppYW45 MEB6dGUuY29tLmNuPiBbbWFpbHRvOnlhbmcuamlhbjkwQHp0ZS5jb20uY25dDQpTZW50OiBTYXR1 cmRheSwgU2VwdGVtYmVyIDI5LCAyMDEyIDU6MTUgQU0NClRvOiBMb2EgQW5kZXJzc29uDQpDYzog TVBMUy1UUCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0 b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0 b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxz LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz47IG1wbHMtY2hh aXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NClN1 YmplY3Q6IOetlOWkjTogW21wbHNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWll dGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0KSGkgQWxsLA0KDQpJIHRoaW5rIHdlIHNob3Vs ZCBhZGRyZXNzIGFsbCB0aGUgaXNzdWVzIHRoYXQgSVRVIGxpYWlzb24gbWVudGlvbmVkLg0KDQpC UiwNCkppYW4NCg0KDQoNCg0KDQogICAgICAgICAgICBMb2EgQW5kZXJzc29uDQogICAgICAgICAg ICA8bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+Pg0KICAgICAgICAgICAg5Y+R5Lu25Lq6OiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIOaUtuS7tuS6ug0K ICAgICAgICAgICAgbXBscy1ib3VuY2VzQGkNCiAgICAgICAgICAgIGV0Zi5vcmcgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIOaKhOmAgQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAibXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRm Lm9yZz4iIDxtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4sDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE1QTFMtVFAgYWQgaG9jIHRlYW0NCiAgICAgICAgICAg IDIwMTItMDktMTkgICAgICAgICAgICAgPGFobXBscy10cEBsaXN0cy5pdHUuaW50PG1haWx0bzph aG1wbHMtdHBAbGlzdHMuaXR1LmludD4+LA0KICAgICAgICAgICAgMTg6NDggICAgICAgICAgICAg ICAgICBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvbw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBscy5pZXRmLm9yZywNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZz4iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc+Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAg5Li76aKYDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCldvcmtpbmcgR3JvdXAsDQoNCnRoaXMgaXMgdG8gc3RhcnQgYSB0 d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmlu Zy1wcm90ZWN0aW9uLTAyLXR4dC4NCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGVyZSBhcmUgdHdvIElQ UiBkaXNjbG9zdXJlcyAjIDE0NjIgYW5kICAjIDE4NzIgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50 Lg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXAg bWFpbGluZyBsaXN0cyAobXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pLg0KDQpU aGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBPY3RvYmVyIDMsIDIwMTIuDQoNCi9Mb2EN CmZvciB0aGUgbXBscyB3ZyBjby1jaGFpcnMNCg0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tPG1h aWx0bzpsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbT4NClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFy ZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KRXJpY3Nz b24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5 MiAxMyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBs cyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== --_000_52981DB05D3C5247A12D0AEE309F3CC20277022C56B6INOAVREX11p_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBh bm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi Q2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYg NCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OlNpbVN1bjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQp0dA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPVBUIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRp diBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5VbmRlcnN0b29kLCBvbmNlIHdl4oCZcmUgcXVvdGluZyBhbm90aGVy IFNET+KAmXMgZG9jdW1lbnQsIGJ1dCBtb3JlIGltcG9ydGFudCBpcyBiZWluZyBjb2hlcmVudCB3 aXRoIG91cnNlbHZlczogd2UgY2Fu4oCZdCBjcml0aWNpemUgdG9kYXkgY29tbWVudGluZyBhbm90 aGVyIFNET+KAmXMgZG9jdW1lbnRzL2V2ZW50cyB3aGVuIHdlIGRpZCB0aGF0IHNhbWUgdGhpbmcg eWVzdGVyZGF5ICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv aWV0Zi9jdXJyZW50L21zZzcxMTc0Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9pZXRmL2N1cnJlbnQvbXNnNzExNzQuaHRtbDwvYT4pLCBpbmNvaGVyZW50bHkgd2l0 aCB3aGF0IHdlIGhhZCB3cml0dGVuIHRoZSBkYXkgYmVmb3JlICg8L3NwYW4+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMDY3NTUuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cwNjc1NS5odG1sPC9hPjwvc3Bhbj48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+KS7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QSBzdWJq ZWN0aXZlIHBvc2l0aW9uIGJyaW5ncyBjb250cmFkaWN0aW9uIGFuZCBsb3NzIG9mIGxvZ2ljLCBh bmQgaGVuY2Ugb3VyIHJlZmVyZW5jZXMgdG8gdGhlIHdvcmQg4oCcdGVjaG5pY2Fs4oCdIGxvc2Ug dGhlaXIgc2VtYW50aWNzLsKgwqDCoMKgwqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5SZWdhcmRzLMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlJ1acKgwqDCoMKgwqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBtcGxzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8 L2I+U3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pPGJyPjxiPlNlbnQ6PC9i PiB0ZXLDp2EtZmVpcmEsIDIgZGUgT3V0dWJybyBkZSAyMDEyIDE4OjE0PGJyPjxiPlRvOjwvYj4g TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuOyBtcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0 Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gRlc6IFdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFuayB5b3UgTWFsY29sbSE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5PYnZpb3VzbHkgaXQgaXMgaW1wb3NzaWJsZSB0byBjb25zaWRlciBzb21ldGhpbmcgdGhhdCB3 YXMgbm90IHBvc3RlZC4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IDxhIGhyZWY9 Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT4g WzxhIGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPmV4dCA8YSBocmVmPSJtYWlsdG86 TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuIj5NYWxjb2xtLkJFVFRTQHp0ZS5jb20uY248L2E+PGJy PjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDAyLCAyMDEyIDY6NDcgUE08YnI+PGI+VG86 PC9iPiA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT47IDxh IGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPm1wbHMtYm91bmNlc0BpZXRmLm9y ZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gRlc6IFdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90 dG9tOjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+SSBleHBlY3QgdGhhdCB0aGlzIGxpYWlzb24g d2lsbCBiZSBwb3N0ZWQgaW4gdGhlIG5leHQgZmV3IGRheXMuPC9zcGFuPjxzcGFuIGxhbmc9RU4t VVM+IDxicj48YnI+PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPklUVSBtZW1iZXJzIGNhbiBmaW5k IHRoZSBsaWFpc29uIGFzIEFubmV4IEkgb2YgVEQ3NDQvUExFTi48L3NwYW4+PHNwYW4gbGFuZz1F Ti1VUz4gPGJyPjxicj48L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+UmVnYXJkcyw8L3NwYW4+PHNw YW4gbGFuZz1FTi1VUz4gPGJyPjxicj48L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+TWFsY29sbTwv c3Bhbj48c3BhbiBsYW5nPUVOLVVTPiA8YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9 IjEwMCUiIHN0eWxlPSd3aWR0aDoxMDAuMCUnPjx0cj48dGQgd2lkdGg9IjM2JSIgdmFsaWduPXRv cCBzdHlsZT0nd2lkdGg6MzYuMCU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PHAg Y2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZxdW90O1NwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwv SG9kIEhhU2hhcm9uKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm51cml0LnNwcmVjaGVyQG5z bi5jb20iPm51cml0LnNwcmVjaGVyQG5zbi5jb208L2E+Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+IDwv c3Bhbj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+U2VudCBieTogPGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZyI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPjwvc3Bhbj4gPG86cD48L286cD48L3A+PHA+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+MDIvMTAvMjAxMiAxMDo1MSBBTTwvc3Bhbj4gPG86cD48L286cD48L3A+PC90ZD48dGQg d2lkdGg9IjYzJSIgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6NjMuMCU7cGFkZGluZzouNzVwdCAu NzVwdCAuNzVwdCAuNzVwdCc+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNl bGxwYWRkaW5nPTAgd2lkdGg9IjEwMCUiIHN0eWxlPSd3aWR0aDoxMDAuMCUnPjx0cj48dGQgdmFs aWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PHAgY2xhc3M9 TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5Ubzwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L3RkPjx0ZCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jmx0OzxhIGhy ZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPiZndDs8L3NwYW4+IDxv OnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48dHI+PHRkIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6 Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBz dHlsZT0ndGV4dC1hbGlnbjpyaWdodCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Y2M8L3NwYW4+PG86cD48L286cD48L3A+PC90 ZD48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+ PC90ZD48L3RyPjx0cj48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAu NzVwdCAuNzVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFs aWduOnJpZ2h0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz5TdWJqZWN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvdGQ+PHRkIHZh bGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz5SZTogW21wbHNdIEZXOiBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBv biAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90 ZWN0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUg Ym9yZGVyPTAgY2VsbHBhZGRpbmc9MD48dHI+PHRkIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6 Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPjwvdGQ+PHRkIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRp bmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48L3RyPjwvdGFibGU+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gbGFu Zz1FTi1VUz48YnI+PGJyPjxicj48L3NwYW4+PHR0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQnPkRpZCBJIG1pc3MgYW55IGxpYWlzb24gb24gdGhpcz88L3NwYW4+PC90 dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YnI+PHR0PlRvIHdo YXQgaXNzdWUgZG8geW91IHJlZmVyPzwvdHQ+PGJyPjxicj48dHQ+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08L3R0Pjxicj48dHQ+RnJvbTogPGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZyI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPiBbPC90dD48L3NwYW4+PHNwYW4gbGFu Zz1FTi1VUz48YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnIj48dHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPm1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L3Nw YW4+PC90dD48L2E+PC9zcGFuPjx0dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz5dIE9uIEJlaGFsZiBPZiBleHQgRXJpYyBHcmF5PC9zcGFuPjwvdHQ+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjx0dD5TZW50OiBUdWVzZGF5LCBP Y3RvYmVyIDAyLCAyMDEyIDQ6MTAgUE08L3R0Pjxicj48dHQ+VG86IDxhIGhyZWY9Im1haWx0bzpt cGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjwvdHQ+PGJyPjx0dD5TdWJqZWN0OiBbbXBs c10gRlc6IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5n LXByb3RlY3Rpb248L3R0Pjxicj48YnI+PHR0PkZvcndhcmRlZC4uLjwvdHQ+PGJyPjxicj48dHQ+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L3R0Pjxicj48dHQ+RnJvbTogPGEgaHJlZj0ibWFp bHRvOnlhbmcuamlhbjkwQHp0ZS5jb20uY24iPnlhbmcuamlhbjkwQHp0ZS5jb20uY248L2E+IFs8 L3R0Pjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxhIGhyZWY9Im1haWx0bzp5YW5nLmppYW45MEB6 dGUuY29tLmNuIj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPm1haWx0bzp5YW5n LmppYW45MEB6dGUuY29tLmNuPC9zcGFuPjwvdHQ+PC9hPjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+XSA8L3NwYW4+PC90dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YnI+PHR0PlNlbnQ6IFNhdHVyZGF5LCBTZXB0 ZW1iZXIgMjksIDIwMTIgNToxNSBBTTwvdHQ+PGJyPjx0dD5UbzogTG9hIEFuZGVyc3NvbjwvdHQ+ PGJyPjx0dD5DYzogTVBMUy1UUCBhZCBob2MgdGVhbTsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWll dGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtbXBs cy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmciPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0 bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8 L2E+PC90dD48YnI+PHR0PlN1YmplY3Q6IDwvdHQ+PC9zcGFuPjx0dD48c3BhbiBsYW5nPVpILUNO IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7nrZTlpI08L3NwYW4+PC90dD48dHQ+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+OiBbbXBsc10gV29ya2luZyBncm91cCBs YXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbjwvc3Bhbj48L3R0 PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48YnI+PHR0Pkhp IEFsbCw8L3R0Pjxicj48YnI+PHR0PkkgdGhpbmsgd2Ugc2hvdWxkIGFkZHJlc3MgYWxsIHRoZSBp c3N1ZXMgdGhhdCBJVFUgbGlhaXNvbiBtZW50aW9uZWQuPC90dD48YnI+PGJyPjx0dD5CUiw8L3R0 Pjxicj48dHQ+SmlhbjwvdHQ+PGJyPjxicj48YnI+PGJyPjxicj48dHQ+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDwvdHQ+PGJyPjx0dD4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBMb2EgQW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvdHQ+PGJyPjx0dD4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSI+bG9h QHBpLm51PC9hPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDwvdHQ+PGJyPjx0dD4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA8L3R0Pjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+5Y+R5Lu25Lq6PC9zcGFuPjwvdHQ+PHR0PjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PC90dD48dHQ+PHNwYW4gbGFuZz1aSC1D TiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+5pS25Lu25Lq6IDwvc3Bhbj48L3R0PjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48dHQ+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbXBscy1ib3VuY2VzQGkgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3R0Pjxicj48dHQ+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZXRmLm9yZyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3R0Pjwvc3Bh bj48dHQ+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+5oqE6YCBIDwv c3Bhbj48L3R0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48 dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmcXVvdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0Bp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxz QGlldGYub3JnPC9hPiZndDssICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvdHQ+PGJyPjx0dD4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO01QTFMtVFAgYWQgaG9jIHRlYW0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC90dD48YnI+PHR0PiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIwMTItMDktMTkgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzphaG1w bHMtdHBAbGlzdHMuaXR1LmludCI+YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQ8L2E+Jmd0OywgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC90dD48YnI+PHR0PiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDE4OjQ4ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtaWV0 Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b28gPC90dD48YnI+PHR0PiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bHMu aWV0Zi5vcmcsICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3R0Pjxicj48dHQ+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmcXVvdDs8YSBocmVmPSJtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmciPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPiZxdW90OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDwvdHQ+PGJyPjx0dD4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJt YWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnPC9hPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3R0Pjxicj48 dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzwvdHQ+PC9zcGFuPjx0dD48c3BhbiBsYW5nPVpILUNOIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Jz7kuLvpopggPC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjx0dD4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1ttcGxzXSBXb3JraW5n IGdyb3VwIGxhc3QgY2FsbCBvbiAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvdHQ+PGJyPjx0dD4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2RyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24gJm5ic3A7ICZuYnNwOyA8 L3R0Pjxicj48dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvdHQ+PGJyPjx0dD4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC90dD48YnI+PHR0PiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA8L3R0Pjxicj48dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDwvdHQ+PGJyPjx0dD4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC90dD48YnI+ PHR0PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3R0Pjxicj48YnI+PGJyPjxicj48 YnI+PHR0PldvcmtpbmcgR3JvdXAsPC90dD48YnI+PGJyPjx0dD50aGlzIGlzIHRvIHN0YXJ0IGEg dHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJp bmctcHJvdGVjdGlvbi0wMi10eHQuPC90dD48YnI+PGJyPjx0dD5QbGVhc2Ugbm90ZSB0aGF0IHRo ZXJlIGFyZSB0d28gSVBSIGRpc2Nsb3N1cmVzICMgMTQ2MiBhbmQgJm5ic3A7IyAxODcyIHJlbGF0 ZWQgdG8gdGhpcyBkb2N1bWVudC48L3R0Pjxicj48YnI+PHR0PlBsZWFzZSBzZW5kIHlvdXIgY29t bWVudHMgdG8gdGhlIG1wbHMgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3RzICg8YSBocmVmPSJt YWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4pLjwvdHQ+PGJyPjxicj48dHQ+ VGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgT2N0b2JlciAzLCAyMDEyLjwvdHQ+PGJy Pjxicj48dHQ+L0xvYTwvdHQ+PGJyPjx0dD5mb3IgdGhlIG1wbHMgd2cgY28tY2hhaXJzPC90dD48 YnI+PGJyPjxicj48dHQ+LS08L3R0Pjxicj48YnI+PGJyPjx0dD5Mb2EgQW5kZXJzc29uICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVtYWlsOiA8YSBocmVmPSJtYWlsdG86bG9hLmFuZGVyc3Nv bkBlcmljc3Nvbi5jb20iPmxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tPC9hPjwvdHQ+PGJyPjx0 dD5TciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51Ij5sb2FAcGkubnU8 L2E+PC90dD48YnI+PHR0PkVyaWNzc29uIEluYyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMzwvdHQ+PGJyPjx0dD4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KzQ2IDc2NyA3MiA5MiAxMyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvdHQ+PGJyPjx0dD5tcGxzIG1h aWxpbmcgbGlzdDwvdHQ+PGJyPjx0dD48YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBs c0BpZXRmLm9yZzwvYT48L3R0Pjxicj48L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiPjx0dD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzPC9zcGFuPjwvdHQ+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz48YnI+PGJyPjx0dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvdHQ+PGJyPjx0dD5tcGxzIG1haWxpbmcgbGlzdDwvdHQ+PGJyPjx0 dD48YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48L3R0Pjxi cj48L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMiPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9zcGFuPjwvdHQ+PC9h Pjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YnI+PHR0 Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC90dD48YnI+ PHR0Pm1wbHMgbWFpbGluZyBsaXN0PC90dD48YnI+PHR0PjxhIGhyZWY9Im1haWx0bzptcGxzQGll dGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjwvdHQ+PGJyPjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVT PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyI+PHR0 PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHM8L3NwYW4+PC90dD48L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvYm9keT48L2h0bWw+ --_000_52981DB05D3C5247A12D0AEE309F3CC20277022C56B6INOAVREX11p_-- From scott.mansfield@ericsson.com Wed Oct 3 12:12:12 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C8121F8460 for ; Wed, 3 Oct 2012 12:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1ItjKxfugIo for ; Wed, 3 Oct 2012 12:12:11 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C8D3721F8458 for ; Wed, 3 Oct 2012 12:12:09 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q93JJPlG021074; Wed, 3 Oct 2012 14:19:27 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 3 Oct 2012 15:12:00 -0400 From: Scott Mansfield To: "mpls@ietf.org" Date: Wed, 3 Oct 2012 15:11:59 -0400 Thread-Topic: Liaison Statement on Ring Protection Thread-Index: Ac2hmvOGGRe7gM09RsC622cBRXyYLQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FDC72027C316A44F82F425284E1C4C322D923B85B0EUSAACMS0701e_" MIME-Version: 1.0 Cc: Ross Callon Subject: [mpls] Liaison Statement on Ring Protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:12:12 -0000 --_000_FDC72027C316A44F82F425284E1C4C322D923B85B0EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Ring Protection liaison has been received from the ITU-T. Please see https://datatracker.ietf.org/liaison/1199/ Regards, -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 --_000_FDC72027C316A44F82F425284E1C4C322D923B85B0EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Ring Protect= ion liaison has been received from the ITU-T.

 

Please see https://datatracker.ietf.org/liaison= /1199/

 

Regards,

-scott.=

 

Scott Ma= nsfield

Ericsson Inc.

+1 724 931 9316

&n= bsp;

= --_000_FDC72027C316A44F82F425284E1C4C322D923B85B0EUSAACMS0701e_-- From gregory.mirsky@ericsson.com Wed Oct 3 12:16:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8EC21F84F2 for ; Wed, 3 Oct 2012 12:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YepGuTVt5ebH for ; Wed, 3 Oct 2012 12:16:30 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4F92B21F8458 for ; Wed, 3 Oct 2012 12:16:30 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q93JNjBo022091; Wed, 3 Oct 2012 14:23:51 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.138]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 3 Oct 2012 15:16:17 -0400 From: Gregory Mirsky To: "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" , "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-chairs@tools.ietf.org" Date: Wed, 3 Oct 2012 15:16:16 -0400 Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2WVF/P8cniMzqKQNCrZ/7Id6/cNAFzVtSwAVwiMzA= Message-ID: References: <5059A308.3050307@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1392845AC44EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:16:37 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1392845AC44EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, I wanted to add a proposal to my comments: * As the document essentially describes application of MPLS-TP Linear= Protection to ring toplogies, it might be reasonable to have scope of this= document match scope of the RFC 6378: * 1:1 protection of bi-directional p2p LSP * 1+1 protection of unidirectional p2p LSP Unidirectional p2mp LSP, both 1+1 and 1:1, as well as 1:1 protection of uni= directional p2p can be set for further study. Regards, Greg _____________________________________________ From: Gregory Mirsky Sent: Monday, October 01, 2012 8:53 AM To: draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls@ietf.org; M= PLS-TP ad hoc team; mpls-chairs@tools.ietf.org Subject: RE: [mpls] Working group last call on draft-ietf-mpls-tp-ri= ng-protection Dear Authors, Editors, WG Chairs, et al., Please find my comments to the document below: * Section 2.1 * Verbal explanation of the wrapping in the first paragraph might ben= efit if LSRs be referenced as in Figure 1. * As described, wrapping can provide local protection of bi-direction= al co-routed LSP only in case of link failure. If node protection requested= , as mentioned in the third sentence of the first para, MP is not the downs= tream LSR but next down to downstream. If we expect that PLR in forward dir= ection is MP in reverse direction of given bi-directional LSP, then we have= case of segment, not local protection. (Same, I believe, applies to FRR of= bi-directional co-routed p2p LSP). * s/arounf/around/ * Figure 1 I think that this figure illustrates wrapping of a single = direction in case of local link protection. If that is the intention, then = caption might explicitly state that. If a case of a bi-directional LSP to b= e illustrated for local link protection, then another wrapped data path F-E= -D-C-B-A might be added. * "If protecting both the links and the nodes of a LSP, then, for a r= ing with N nodes, there is a need for O(2N) alternate paths." I assume that= this estimate is for bi-directional co-routed p2p LSP. But co-routed LSP i= mplies coordinated protection which, as mentined before, can not be achieve= d for node protection with local protection. Coordinated node protection, i= f not end-to-end, can be in form of segment protection. * Section 2.2 * "The process of notifying the ingress node adds to the latency of t= he protection switching process, after the detection of the fault condition= ." I think that that is not necessarily true as ingress notification doesn'= t have to be explicit but can be implicit if e2e CC/CV monitors working and= protecting paths. * Very last para "... there is the necessity for the ring to maintain= enough capacity for all of the data in both directions around the ring" se= ems as too strong requirement considering cases of 1:N linear and shared me= sh protection, where bandwidth of a protection path shared. * Section 2.3 * "... since we will perform all of the OAM functionality on the SPME= configured for the traffic, we can minimize the number of OAM sessions nee= ded to monitor the data traffic of the ring - rather than monitoring each i= ndividual LSP." Such improvement in OAM scale doesn't come for free as SPME= OAM might introduce or hide connectivity and/or continuity defects of encl= osed LSPs. * "In all of the following subsections, we use 1:1 linear protection = [SurvivFwk] [LinProtect] to perform protection switching and coordination w= hen a signal fault is detected." For 1:1 linear protection scope of the RFC= 6378 is limited to bi-directional p2p MPLS-TP constructs. "Applicability o= f the protocol for 1:1 unidirectional protection and for 1:n protection sch= emes may be documented in a future document and is out of scope for this do= cument", stated in section 1.2. Thus use of PSC for unidirectional p2p and = p2mp MPLS-TP constructs is undefined. Perhaps this has to be mentioned and = reflected in change of the scope of the document. * Section 2.3.1 * First para "... each one acts as the ingress and egress in one dire= ction of the bidirectional SPME". I think that terminology "ingress/egress = MEP" is not the best and perhaps view of nodal MEP per LSP is sufficient, s= o that no need to split MEP on given LSP per direction. * Section 2.3.2 * I think that title of the section needs to say explicitly that link= protection by wrapping is discussed in the section (node protection in the= 2.3.3) * Section 2.3.3 * As mentioned, in case of bi-directional co-routed LSP to which node= protection required (Figure 4) SPME approach is, effectively, segment, not= local protection. SPME level OAM between LSR A and LSR E monitors not only= link between LSR A and LSR F and LSR F but link between LSR F and LSR E as= well (from LSP POV). The primary SPME, effectively, changes ring topology = by excluding LSR F from topology as LSR F would not be processing LSP's out= er label but process only SPME's outer label. * Section 2.3.4 * Local node protection monitors immediate link for link as well as n= ode protection. The difference between these protection modes in selection = of a MP, whether immediate neighbor can (link protection) or can not (node = protection) be used as MP. The section seems based on misunderstanding of d= ifference between local link and node protection and might be removed. * Section 2.4 * s/steeing/steering/ * What are three OAM sessions that each ring node will have if wrappi= ng used to protect the ring? I see two OAM sessions: immediate link to down= stream LSR; around ring to the same LSR. Where the third OAM session? * "Special consideration" seems as unfounded: * Not clear why CC/CV OAM in case of SPME steering viewed as insuffic= ient for fast defect detection. * Local node and link protection are not mutualy exclusive. Local nod= e protection provides link protection as part of node protection. The probl= em, from my POV, is that bi-directional co-routed LSP can not have local no= de protection but only segment protection. * Section 3 * As noted earlier, applicability of RFC 6378 and PSC for 1:1 linear = protection of unidirectional MPLS-TP constructs, including unidirectional p= 2mp LSP, not yet been defined. Neither CC/CV OAM on these constructs. What = mechanism(s) could be used to perform defect detection, coordination and pr= otections switchover? * Section 4 * As as stated in RFC 6378 "Applicability of the protocol [PSC, my no= te] for 1:1 unidirectional protection and for 1:n protection schemes may be= documented in a future document and is out of scope for this document". A note on textual conventions: * References are both direct RFC, e.g. [RFC4090], and content-based, = i.e. [TPReqs]. May consider choosing single style of referencing. Thank you for your kind consideration. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Wednesday, September 19, 2012 3:49 AM Cc: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@= tools.ietf.org; mpls-chairs@tools.ietf.org Subject: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protecti= on Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-r= ing-protection-02-txt. Please note that there are two IPR disclosures # 1462 and # 1872 related t= o this document. Please send your comments to the mpls working group mailing lists (mpls@iet= f.org). The working group last call ends October 3, 2012. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ____________= ___________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_FE60A4E52763E84B935532D7D9294FF1392845AC44EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear All,
I wanted to add a proposal to my comments:
  • As the document essentially describes application of MPLS-TP Linear Pro= tection to ring toplogies, it might be reasonable to have scope of this doc= ument match scope of the RFC 6378:
    •
  • 1:1 protection of bi-directional p2p LSP
  • 1+1 protection of = unidirectional p2p LSP
    •
Unidirectional = p2mp LSP, both 1+1 and 1:1, as well as 1:1 protection of unidirectional= p2p can be set for further study.
 
        Reg= ards,
       &nbs= p;        Greg
_________________________= ____________________
From:    Gregory Mirsky&nbs= p;
Sent:   Monday, October 01, 2012= 8:53 AM
To:     draft-ietf-mpl= s-tp-ring-protection@tools.ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; mp= ls-chairs@tools.ietf.org
Subject:      &n= bsp; RE: [mpls] Working group last call on draft-ietf-mpls-tp-ring-prot= ection
 
Dear Authors, Editors, WG Chairs, et al.,
Please find my comments to the document below:
  • Section 2.1
  • Verbal explanation of the wrapping in the first paragraph might benefit= if LSRs be referenced as in Figure 1.
  • As described, wrapping can p= rovide local protection of bi-directional co-routed LSP only in case of lin= k failure. If node protection requested, as mentioned in the third sentence= of the first para, MP is not the downstream LSR but next down to downstrea= m. If we expect that PLR in forward direction is MP in reverse direction of gi= ven bi-directional LSP, then we have case of segment, not local protection.= (Same, I believe, applies to FRR of bi-directional co-routed p2p LSP).
  • s/arounf/around/
  • Figure 1 I think that this figure illustrates= wrapping of a single direction in case of local link protection. If that i= s the intention, then caption might explicitly state that. If a case of a b= i-directional LSP to be illustrated for local link protection, then another wrapped data path F-E-D-C-B-A might be added.
  • "If protecting both the links and the nodes o= f a LSP, then, for a ring with N no= des, there is a need for O(2N) alte= rnate paths." I assume that this estimate is for bi-directional co-routed p2p LSP. But co-routed LSP im= plies coordinated protection which, as mentined before, can not be achieved= for node protection with local protection. Coordinated node protection, if= not end-to-end, can be in form of segment protection.
  • Section 2.2
  • "The process of notifying the ingress node adds to the latency of = the protection switching process, after the detection of the fault conditio= n." I think that that is not necessarily true as ingress notification = doesn't have to be explicit but can be implicit if e2e CC/CV monitors working and protecting paths.
  • Very last para = "… there is the necessity for the ring to maintain enough capaci= ty for all of the data in both directions around the ring" seems as to= o strong requirement considering cases of 1:N linear and shared mesh protec= tion, where bandwidth of a protection path shared.
  • Section 2.3
  • "… since we will perform all of the OAM functionality on the= SPME configured for the traffic, we can minimize the number of OAM session= s needed to monitor the data traffic of the ring - rather than monitoring e= ach individual LSP." Such improvement in OAM scale doesn't come for free as SPME OAM might introduce or hide connectivit= y and/or continuity defects of enclosed LSPs.
  • "In all of the f= ollowing subsections, we use 1:1 linear protection [SurvivFwk] [LinProtect]= to perform protection switching and coordination when a signal fault is de= tected." For 1:1 linear protection scope of the RFC 6378 is limited to= bi-directional p2p MPLS-TP constructs. "Applicability of the protocol for 1:1 unidirectio= nal protection and for 1:n protection schemes may be documented in a future= document and is out of scope for this document", stated in section 1.= 2. Thus use of PSC for unidirectional p2p and p2mp MPLS-TP constructs is undefined. Perhaps this has to be mentioned = and reflected in change of the scope of the document.
  • Section 2.3.1
  • First para "… each one acts as the ingress and egress in one= direction of the bidirectional SPME". I think that terminology "= ingress/egress MEP" is not the best and perhaps view of nodal MEP per = LSP is sufficient, so that no need to split MEP on given LSP per direction.
  • Section 2.3.2
  • I think that title of the section needs to say explicitly that link pro= tection by wrapping is discussed in the section (node protection in the 2.3= .3)
  • Section 2.3.3
  • As mentioned, in case of bi-directional co-routed LSP to which node pro= tection required (Figure 4) SPME approach is, effectively, segment, not loc= al protection. SPME level OAM between LSR A and LSR E monitors not only lin= k between LSR A and LSR F and LSR F but link between LSR F and LSR E as well (from LSP POV). The primary SPME= , effectively, changes ring topology by excluding LSR F from topology as LS= R F would not be processing LSP's outer label but process only SPME's outer= label.
  • Section 2.3.4
  • Local node protection monitors immediate link for link as well as node = protection. The difference between these protection modes in selection of a= MP, whether immediate neighbor can (link protection) or can not (node prot= ection) be used as MP. The section seems based on misunderstanding of difference between local link and node p= rotection and might be removed.
  • Section 2.4
  • s/steeing/steering/
  • What are three OAM sessions that each ring = node will have if wrapping used to protect the ring? I see two OAM sessions= : immediate link to downstream LSR; around ring to the same LSR. Where the = third OAM session?
  • "Special consideration" seems as unfou= nded:
  • Not clear why CC/CV OAM in case of SPME steering viewed as insufficient= for fast defect detection.
  • Local node and link protection are not = mutualy exclusive. Local node protection provides link protection as part o= f node protection. The problem, from my POV, is that bi-directional co-rout= ed LSP can not have local node protection but only segment protection.
    • =
  • Section 3
  • As noted earlier, applicability of RFC 6378 and PSC for 1:1 linear prot= ection of unidirectional MPLS-TP constructs, including unidirectional p2mp = LSP, not yet been defined. Neither CC/CV OAM on these constructs. What mech= anism(s) could be used to perform defect detection, coordination and protections switchover?
  • Section 4
  • As as stated in RFC 6378 "Applicability of the protocol [PSC, my n= ote] for 1:1 unidirectional protection and for 1:n protection schemes may b= e documented in a future document and is out of scope for this document&quo= t;.
A note on textual conventions:
  • References are both direct RFC, e.g. [RFC4090], and content-based, i.e.= [TPReqs]. May consider choosing single style of referencing.
 
Thank you for your kind consideration.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bo= unces@ietf.org] On Behalf Of Loa Andersson
Sent: Wednesday, September 19, 2012 3= :49 AM
Cc: mpls@ietf.org; MPLS-TP ad hoc tea= m; draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.iet= f.org
Subject: [mpls] Working group last ca= ll on draft-ietf-mpls-tp-ring-protection
 
Working Group,
 
this is to start a two week working g= roup last call on draft-ietf-mpls-tp-ring-protection-02-txt.
 
Please note that there are two IPR di= sclosures # 1462 and  # 1872 related to this document.
 
Please send your comments to the mpls= working group mailing lists (mpls@ietf.org).
 
The working group last call ends Octo= ber 3, 2012.
 
/Loa
for the mpls wg co-chairs
 
 
--
 
 
Loa Andersson    =             &nb= sp;        email: loa.andersson@ericsson= .com
Sr Strategy and Standards Manager&nbs= p;           loa@pi.nu
Ericsson Inc    &= nbsp;           &nbs= p;         phone: +46 10 717 52= 13
      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  +46 767 72 92 13 _____________________________________________= __
mpls mailing list
mpls@ietf.org
 
 --_000_FE60A4E52763E84B935532D7D9294FF1392845AC44EUSAACMS0715e_-- From koike.yoshinori@lab.ntt.co.jp Wed Oct 3 14:58:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FD621F84A1 for ; Wed, 3 Oct 2012 14:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZqF5sFGGiGc for ; Wed, 3 Oct 2012 14:58:22 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 65C9921F84A0 for ; Wed, 3 Oct 2012 14:58:22 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q93LwLue005416 for ; Thu, 4 Oct 2012 06:58:21 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id EB10AE0108 for ; Thu, 4 Oct 2012 06:58:20 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id DF76FE0105 for ; Thu, 4 Oct 2012 06:58:20 +0900 (JST) Received: from [129.60.11.43] (koike-pc.nslab.ecl.ntt.co.jp [129.60.11.43]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q93LwK3p010532; Thu, 4 Oct 2012 06:58:20 +0900 Message-ID: <506CB54F.2050706@lab.ntt.co.jp> Date: Thu, 04 Oct 2012 06:59:43 +0900 From: Yoshinori Koike User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mpls@ietf.org References: <5059A308.3050307@pi.nu> In-Reply-To: <5059A308.3050307@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 21:58:23 -0000 Hello, Followings are my comments and questions. 1)It seems necessary to develop a ring protection mechanism to meet requirements of ring protection in RFC5654. This document doesn’t seem to specify a ring protection. 2)It seems that this document intends to address only parts of requirements for protection of ring topologies; therefore I would suggest that the term “ring protection” (total 12 in this document) should be modified to an appropriate expression such as “a protection for a ring topology”. Title and the first sentence in abstract seem to be appropriate. 3)In the second paragraph of clause 1, this document refers to RFC5654. However, 5 requirements are not consistent with RFC5654. When they are intentionally changed, it seems necessary to clearly explain them and the reason. Otherwise, they are confusing. The followings are differences. a.“minimize” is missing b.“minimize” is missing c.“minimize” is missing d.“recovery operation” is used instead of “maintenance operation” e.“during protection” is missing, 4)In 1st paragraph of section 2.1, what is the objective/intention of including the sentence “Wrapping behavior is similar to MPLS-TE FRR as defined in [RFC4090] using either bypass or detour tunnels.”? Is it a caution in terms of operation? Could you be more specific on the draft, please? 5)In 3rd paragraph of section 2.1, the following sentence is not clear. “Coordination would only be needed (where?) to maintain co-routed bidirectional traffic (why and when?) even in cases(why plural?) of a unidirectional fault condition.” Could you be more specific on this point, please? 6)In the 5th bullet in section 2.1, it is not clear what is problematic. Probably, it is meant that in-efficiency of resource allocation is problematic. If it is correct, it seems better to clearly describe that point. [Editorial] -In the item 3 in section 1.1 on page 4, section 4.12 of RFC 4427 is referred. However, external commands are defined in section 4.13, correctly. -In the example 2 on page 5, a description of index “1” is missing in the explanation of [PB1(G)|LE]. -In the first paragraph of section 2.1, in the third line from the bottom, “arounf” should be “around”. -In figure 1, wrapped data path”@@@” is not described between LSR E & LSR F. -In figure 8, branches at C, F, G, J, K and A should be removed for aligning with the example shown in 3.2.2. -In the first sentence of section 5, “prevelant” should be “prevalent”. Best regards, Yoshinori (2012/09/19 19:48), Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 > related to this document. > > Please send your comments to the mpls working group mailing lists > (mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > -- Yoshinori Koike koike.yoshinori@lab.ntt.co.jp From paul.doolan@nsn.com Wed Oct 3 16:37:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1A1F0C7E for ; Wed, 3 Oct 2012 16:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyxPkihbJHnD for ; Wed, 3 Oct 2012 16:37:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C71171F0C73 for ; Wed, 3 Oct 2012 16:37:51 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q93NblKG019551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 01:37:47 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q93NbfoG003804; Thu, 4 Oct 2012 01:37:45 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Oct 2012 01:37:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA1BF.FA0620E9" Date: Thu, 4 Oct 2012 07:36:54 +0800 Message-ID: <44A5364BC1FA1E42B1F133529EC2C72902C22EC4@CNBEEXC007.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [mpls] Working group last call ondraft-ietf-mpls-tp-ring-protection Thread-Index: Ac2hv/iueyEeFTmiQ+G/M2Kz199nAg== From: "Doolan, Paul (NSN - US/Irving)" To: , X-OriginalArrivalTime: 03 Oct 2012 23:37:01.0020 (UTC) FILETIME=[FC7899C0:01CDA1BF] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5475 X-purgate-ID: 151667::1349307467-00006F5F-75CDC852/0-0/0-0 Subject: Re: [mpls] Working group last call ondraft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 23:37:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDA1BF.FA0620E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Loa, I have re-read the draft in question. Please note also that I am a colleague of one of the authors but made no contribution to it nor was my input solicited by them. This should be a no-brainer: the first sentence of the document says "this is an applicability statement". =20 If your question is "how do I protect MPLS-TP traffic in ring topologies" this document says "you _could_ do it with the linear protection mechanisms already defined in RFC6378 in the following way". As such it clearly explains an extant problem and demonstrates a solution to it using available tools already defined by this WG and - presumably - available in implementations today. It may not be perfect, it may have some limitations and there may be, at some later date, another solution, but, even then, there will still be applications for which this is a perfectly adequate and viable solution. I have fielded questions and had discussions with operators which clearly indicate to me that an RFC explaining this application of MPLS-TP linear protection would be valuable to the community.=20 Words, or more correctly their meanings, are important things. I do not know whether the incorrectly spelt 'aleviates' in one of the last sentences of the draft was a very deliberate choice or a happy accident, but in that sentence - "This thereby aleviates the necessity to create a new mechanism or protocol to support the protection of ring topologies" - the authors are not excluding development of other solutions. They are, to use one definition of the word, simply making the wait ('suffering' in Websters) more bearable. I hope that clarification assuages at least one of the concerns expressed in other responses to your call. I support progressing this document. best regards, pd =20 Paul Doolan NSN ON ------_=_NextPart_001_01CDA1BF.FA0620E9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [mpls] Working group last call = ondraft-ietf-mpls-tp-ring-protection

Hi Loa,

I have re-read the draft in question. = Please note also that I am a colleague of one of the authors but made no = contribution to it nor was my input solicited by them.

This should be a no-brainer: the first = sentence of the document says "this is an applicability = statement".  

If your question is "how do I = protect MPLS-TP traffic in ring topologies" this document says = "you _could_  do it with the linear protection mechanisms = already defined in RFC6378 in the following way". As such it = clearly explains an extant problem and demonstrates a solution to it = using available tools already defined by this WG and - presumably - = available in implementations today. It may not be perfect, it may have = some limitations and there may be, at some later date, another solution, = but, even then, there will still be applications for which this is a = perfectly adequate and viable solution.

I have fielded questions and had = discussions with operators which clearly indicate to me that an RFC = explaining this application of MPLS-TP linear protection would be = valuable to the community. 

Words, or more correctly their = meanings, are important things. I do not know whether the incorrectly = spelt 'aleviates'  in one of the last sentences of the draft was a = very deliberate choice or a happy accident, but in  that sentence = - "This thereby aleviates the necessity to create a = new mechanism or protocol to support the protection of ring = topologies"  - the authors are not excluding development of = other solutions. They are, to use one definition of the word, simply = making the wait ('suffering' in Websters) more bearable. I hope = that clarification assuages at least one of the concerns expressed in = other responses to your call.

I support progressing this = document.

best regards,

pd

 

Paul Doolan

NSN = ON

------_=_NextPart_001_01CDA1BF.FA0620E9-- From loa@pi.nu Thu Oct 4 00:01:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CC221F8623 for ; Thu, 4 Oct 2012 00:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwV94lFHgwHJ for ; Thu, 4 Oct 2012 00:01:48 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id ED74C21F8622 for ; Thu, 4 Oct 2012 00:01:47 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id B408851419D; Thu, 4 Oct 2012 09:01:43 +0200 (CEST) Message-ID: <506D3458.6030300@pi.nu> Date: Thu, 04 Oct 2012 09:01:44 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" , MPLS-TP ad hoc team , draft-ietf-mpls-tp-ring-protection@tools.ietf.org, "mpls-chairs@tools.ietf.org" References: <5059A308.3050307@pi.nu> In-Reply-To: <5059A308.3050307@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 07:01:49 -0000 Folks, I've three comments that is not really "technical" but has more to do with ID format and guidelines. 1. There are too many authors listed on the first page is too high, the guideline from the RFC Editor is a maximum of 5 2. The security section says "To be added in future version" 3. The acknowledgment section includes incorrectly named and non-existing groups. /Loa On 2012-09-19 12:48, Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 > related to this document. > > Please send your comments to the mpls working group mailing lists > (mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From nurit.sprecher@nsn.com Thu Oct 4 02:25:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF60B21F866D; Thu, 4 Oct 2012 02:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I62r05++kWhU; Thu, 4 Oct 2012 02:25:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 53AF421F866C; Thu, 4 Oct 2012 02:25:10 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q949P2uQ020859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 11:25:02 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q949OwAF005843; Thu, 4 Oct 2012 11:25:02 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Oct 2012 11:24:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA212.1AF8BB9F" Date: Thu, 4 Oct 2012 11:24:49 +0200 Message-ID: In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC20277022C56B6@INOAVREX11.ptin.corpPT.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] FW: Working group last callondraft-ietf-mpls-tp-ring-protection Thread-Index: Ac2gvZYjtV8yD3jlStGX4+AodnfPQwAA5iPgACZMJeAALbfW8A== References: <5059A308.3050307@pi.nu> <52981DB05D3C5247A12D0AEE309F3CC20277022C56B6@INOAVREX11.ptin.corpPT.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Rui Costa" , , , X-OriginalArrivalTime: 04 Oct 2012 09:24:51.0564 (UTC) FILETIME=[1B5A82C0:01CDA212] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 73268 X-purgate-ID: 151667::1349342704-00006DFC-D2B0F971/0-0/0-0 Subject: Re: [mpls] FW: Working group last callondraft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 09:25:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDA212.1AF8BB9F Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBSdWksDQpJIGhhdmUgdG8gYWRtaXQgdGhhdCBJIGFtIGEgYml0IGxvc3QgaGVyZeKApuKA pi5hbmQgSSBkbyBub3QgZ2V0IHdoYXQgeW91ciBwb2ludCBpc+KApi4uYW5kIGhvdyBhbGwgdGhp cyByZWxhdGVz4oCmLi4NCkkgYW0gbG9va2luZyBmb3IgcHVyZSB0ZWNobmljYWwgZGlzY3Vzc2lv biBhbmQgY2Fubm90IHNlZSBob3cgdGhlIGJlbG93IGNvbnRyaWJ1dGVzIHRvIHRoYXTigKYuLg0K SSB3YXJtbHkgZW5jb3VyYWdlIHlvdSB0byBwcm92aWRlIHRlY2huaWNhbCBpbnB1dCBmb3IgdGhl IGRpc2N1c3Npb24gaW4gb3JkZXIgdG8gYWxsb3cgdXMgdG8gZnJ1aXRmdWxseSBjb25zaWRlciBh bmQgZGlzY3VzcyB0aGF04oCmDQpCZXN0IHJlZ2FyZHMsDQpOdXJpdA0KIA0KIA0KRnJvbTogZXh0 IFJ1aSBDb3N0YSBbbWFpbHRvOlJDb3N0YUBwdGlub3ZhY2FvLnB0XSANClNlbnQ6IFdlZG5lc2Rh eSwgT2N0b2JlciAwMywgMjAxMiA2OjExIFBNDQpUbzogU3ByZWNoZXIsIE51cml0IChOU04gLSBJ TC9Ib2QgSGFTaGFyb24pOyBNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY247IG1wbHNAaWV0Zi5vcmc7 IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFttcGxzXSBGVzogV29ya2luZyBn cm91cCBsYXN0IGNhbGxvbmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCiANClVu ZGVyc3Rvb2QsIG9uY2Ugd2XigJlyZSBxdW90aW5nIGFub3RoZXIgU0RP4oCZcyBkb2N1bWVudCwg YnV0IG1vcmUgaW1wb3J0YW50IGlzIGJlaW5nIGNvaGVyZW50IHdpdGggb3Vyc2VsdmVzOiB3ZSBj YW7igJl0IGNyaXRpY2l6ZSB0b2RheSBjb21tZW50aW5nIGFub3RoZXIgU0RP4oCZcyBkb2N1bWVu dHMvZXZlbnRzIHdoZW4gd2UgZGlkIHRoYXQgc2FtZSB0aGluZyB5ZXN0ZXJkYXkgKGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZXRmL2N1cnJlbnQvbXNnNzExNzQuaHRtbCks IGluY29oZXJlbnRseSB3aXRoIHdoYXQgd2UgaGFkIHdyaXR0ZW4gdGhlIGRheSBiZWZvcmUgKGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMDY3NTUu aHRtbCkuICAgICAgICAgICAgICAgIA0KIA0KQSBzdWJqZWN0aXZlIHBvc2l0aW9uIGJyaW5ncyBj b250cmFkaWN0aW9uIGFuZCBsb3NzIG9mIGxvZ2ljLCBhbmQgaGVuY2Ugb3VyIHJlZmVyZW5jZXMg dG8gdGhlIHdvcmQg4oCcdGVjaG5pY2Fs4oCdIGxvc2UgdGhlaXIgc2VtYW50aWNzLiAgICAgICAg ICANCiANClJlZ2FyZHMsICAgICAgICAgICAgICANClJ1aSAgICAgICAgICANCiANCiANCkZyb206 IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKQ0KU2VudDog dGVyw6dhLWZlaXJhLCAyIGRlIE91dHVicm8gZGUgMjAxMiAxODoxNA0KVG86IE1hbGNvbG0uQkVU VFNAenRlLmNvbS5jbjsgbXBsc0BpZXRmLm9yZzsgbXBscy1ib3VuY2VzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW21wbHNdIEZXOiBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbG9uIGRyYWZ0LWlldGYt bXBscy10cC1yaW5nLXByb3RlY3Rpb24NCiANClRoYW5rIHlvdSBNYWxjb2xtIQ0KT2J2aW91c2x5 IGl0IGlzIGltcG9zc2libGUgdG8gY29uc2lkZXIgc29tZXRoaW5nIHRoYXQgd2FzIG5vdCBwb3N0 ZWQuIA0KIA0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbg0KU2Vu dDogVHVlc2RheSwgT2N0b2JlciAwMiwgMjAxMiA2OjQ3IFBNDQpUbzogbXBsc0BpZXRmLm9yZzsg bXBscy1ib3VuY2VzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIEZXOiBXb3JraW5nIGdy b3VwIGxhc3QgY2FsbG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCiANCkkg ZXhwZWN0IHRoYXQgdGhpcyBsaWFpc29uIHdpbGwgYmUgcG9zdGVkIGluIHRoZSBuZXh0IGZldyBk YXlzLiANCg0KSVRVIG1lbWJlcnMgY2FuIGZpbmQgdGhlIGxpYWlzb24gYXMgQW5uZXggSSBvZiBU RDc0NC9QTEVOLiANCg0KUmVnYXJkcywgDQoNCk1hbGNvbG0gDQoNCg0KIlNwcmVjaGVyLCBOdXJp dCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKSIgPG51cml0LnNwcmVjaGVyQG5zbi5jb20+IA0KU2Vu dCBieTogbXBscy1ib3VuY2VzQGlldGYub3JnIA0KMDIvMTAvMjAxMiAxMDo1MSBBTSANClRvDQo8 bXBsc0BpZXRmLm9yZz4gDQpjYw0KCQ0KU3ViamVjdA0KUmU6IFttcGxzXSBGVzogV29ya2luZyBn cm91cCBsYXN0IGNhbGwgb24gICAgICAgIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rp b24NCiANCgkJDQoNCg0KDQpEaWQgSSBtaXNzIGFueSBsaWFpc29uIG9uIHRoaXM/DQpUbyB3aGF0 IGlzc3VlIGRvIHlvdSByZWZlcj8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyA8bWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4gXSBPbiBCZWhhbGYgT2YgZXh0IEVyaWMgR3JheQ0K U2VudDogVHVlc2RheSwgT2N0b2JlciAwMiwgMjAxMiA0OjEwIFBNDQpUbzogbXBsc0BpZXRmLm9y Zw0KU3ViamVjdDogW21wbHNdIEZXOiBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1p ZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoNCkZvcndhcmRlZC4uLg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogeWFuZy5qaWFuOTBAenRlLmNvbS5jbiBbbWFpbHRvOnlh bmcuamlhbjkwQHp0ZS5jb20uY24gPG1haWx0bzp5YW5nLmppYW45MEB6dGUuY29tLmNuPiBdIA0K U2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAyOSwgMjAxMiA1OjE1IEFNDQpUbzogTG9hIEFuZGVy c3Nvbg0KQ2M6IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXBy b3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IG1wbHMtYm91bmNlc0BpZXRm Lm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IOetlOWkjTogW21wbHNd IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3Rl Y3Rpb24NCg0KSGkgQWxsLA0KDQpJIHRoaW5rIHdlIHNob3VsZCBhZGRyZXNzIGFsbCB0aGUgaXNz dWVzIHRoYXQgSVRVIGxpYWlzb24gbWVudGlvbmVkLg0KDQpCUiwNCkppYW4NCg0KDQoNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgIExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICA8bG9hQHBpLm51 PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAg ICAgICAgICAg5Y+R5Lu25Lq6OiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIOaUtuS7tuS6uiANCiAgICAgICAgICAgIG1wbHMtYm91bmNlc0BpICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICBldGYu b3JnICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDmioTp gIEgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJtcGxzQGlldGYub3JnIiA8 bXBsc0BpZXRmLm9yZz4sICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBNUExTLVRQIGFkIGhvYyB0ZWFtICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgIDIw MTItMDktMTkgICAgICAgICAgICAgPGFobXBscy10cEBsaXN0cy5pdHUuaW50PiwgICAgICAgICAg ICAgDQogICAgICAgICAgICAxODo0OCAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtbXBscy10 cC1yaW5nLXByb3RlY3Rpb25AdG9vIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBscy5pZXRmLm9yZywgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiAgICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZz4gICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg5Li76aKYIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbbXBsc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24g ICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1tcGxz LXRwLXJpbmctcHJvdGVjdGlvbiAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KDQoNCldvcmtpbmcgR3JvdXAsDQoNCnRoaXMg aXMgdG8gc3RhcnQgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1p ZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAyLXR4dC4NCg0KUGxlYXNlIG5vdGUgdGhhdCB0 aGVyZSBhcmUgdHdvIElQUiBkaXNjbG9zdXJlcyAjIDE0NjIgYW5kICAjIDE4NzIgcmVsYXRlZCB0 byB0aGlzIGRvY3VtZW50Lg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxz IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0cyAobXBsc0BpZXRmLm9yZykuDQoNClRoZSB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIE9jdG9iZXIgMywgMjAxMi4NCg0KL0xvYQ0KZm9yIHRo ZSBtcGxzIHdnIGNvLWNoYWlycw0KDQoNCi0tDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAg ICAgICAgICAgICAgICBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NClNyIFN0cmF0 ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KRXJpY3Nzb24g SW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5MiAx MyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBt YWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscyA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz PiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1w bHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscz4gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscyA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzPiANCg== ------_=_NextPart_001_01CDA212.1AF8BB9F Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPVByb2dJZCBjb250ZW50PVdv cmQuRG9jdW1lbnQ+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQg MTIiPjxtZXRhIG5hbWU9T3JpZ2luYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiI+PGxp bmsgcmVsPUZpbGUtTGlzdCBocmVmPSJjaWQ6ZmlsZWxpc3QueG1sQDAxQ0RBMjIyLkREQUVDQTYw Ij48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8 bzpBbGxvd1BORy8+DQo8bzpUYXJnZXRTY3JlZW5TaXplPjEwMjR4NzY4PC9vOlRhcmdldFNjcmVl blNpemU+DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6Wm9vbT4xMjA8L3c6 Wm9vbT4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNr TW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlk YXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZY TUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29u dGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1Bs YWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4t VVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WC1OT05FPC93OkxpZFRoZW1l QXNpYW4+DQo8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+SEU8L3c6TGlkVGhlbWVDb21wbGV4U2Ny aXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6 QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkRv bnRWZXJ0QWxpZ25DZWxsV2l0aFNwLz4NCjx3OkRvbnRCcmVha0NvbnN0cmFpbmVkRm9yY2VkVGFi bGVzLz4NCjx3OkRvbnRWZXJ0QWxpZ25JblR4YngvPg0KPHc6V29yZDExS2VybmluZ1BhaXJzLz4N Cjx3OkNhY2hlZENvbEJhbGFuY2UvPg0KPC93OkNvbXBhdGliaWxpdHk+DQo8dzpCcm93c2VyTGV2 ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8L3c6QnJvd3NlckxldmVsPg0KPG06bWF0aFBy Pg0KPG06bWF0aEZvbnQgbTp2YWw9IkNhbWJyaWEgTWF0aCIvPg0KPG06YnJrQmluIG06dmFsPSJi ZWZvcmUiLz4NCjxtOmJya0JpblN1YiBtOnZhbD0iJiM0NTstIi8+DQo8bTpzbWFsbEZyYWMgbTp2 YWw9Im9mZiIvPg0KPG06ZGlzcERlZi8+DQo8bTpsTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpyTWFy Z2luIG06dmFsPSIwIi8+DQo8bTpkZWZKYyBtOnZhbD0iY2VudGVyR3JvdXAiLz4NCjxtOndyYXBJ bmRlbnQgbTp2YWw9IjE0NDAiLz4NCjxtOmludExpbSBtOnZhbD0ic3ViU3VwIi8+DQo8bTpuYXJ5 TGltIG06dmFsPSJ1bmRPdnIiLz4NCjwvbTptYXRoUHI+PC93OldvcmREb2N1bWVudD4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6TGF0ZW50U3R5bGVzIERl ZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVmVW5oaWRlV2hlblVzZWQ9InRydWUiIERlZlNlbWlIaWRk ZW49InRydWUiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxl Q291bnQ9IjI2NyI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUi IE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3Jt YXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0 b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIxMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjIiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0 cm9uZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NTkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlRhYmxl IEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2Vu dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3Jh cGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9 IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNo YWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ikxp Z2h0IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlk IDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsg TGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExp c3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5n IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBM aXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdo dCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFj Y2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3Qg QWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVs IFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBM aXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBB Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3Jp ZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2Vu dCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFk aW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xv cmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjE5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRs ZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFFGb3JtYXQ9InRydWUiIE5h bWU9IlRPQyBIZWFkaW5nIi8+DQo8L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+ PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJbXNvLWZvbnQt YWx0Oj8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz87DQoJbXNvLWZvbnQtY2hhcnNldDox MzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9udC1waXRjaDp2YXJp YWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MyA2ODA0NjAyODggMjIgMCAyNjIxNDUgMDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7DQoJbXNvLWZvbnQtYWx0OiJIaWdoIFRvd2VyIFRleHQiOw0KCW1zby1m b250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28tZm9u dC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMTA3MzA1 NzI3IDAgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtYWx0OiJNViBCb2xpIjsNCglt c28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNv LWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwOTI5MjkgMTA3 Mzc4NjExMSA5IDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQtYWx0OkFyaWFsOw0KCW1z by1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28t Zm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUyMDA4MTY2NSAtMTA3 MzcxNzE1NyA0MSAwIDY2MDQ3IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1T dW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJbXNvLWZvbnQtYWx0OiJcQEFy aWFsIFVuaWNvZGUgTVMiOw0KCW1zby1mb250LWNoYXJzZXQ6MTM0Ow0KCW1zby1nZW5lcmljLWZv bnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2ln bmF0dXJlOjMgNjgwNDYwMjg4IDIyIDAgMjYyMTQ1IDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0eWxl LXVuaGlkZTpubzsNCgltc28tc3R5bGUtcWZvcm1hdDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoi IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlv bjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpwDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCgltc28t cGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpTaW1TdW47DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KdHQN Cgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQt ZmFtaWx5OlNpbVN1bjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OlNpbVN1bjsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6U2ltU3VuOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3 aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpTaW1TdW47fQ0Kc3Bhbi5CYWxs b29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXVu aGlkZTpubzsNCgltc28tc3R5bGUtbG9ja2VkOnllczsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lp LWZvbnQtZmFtaWx5OlRhaG9tYTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6VGFob21hOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OlRhaG9tYTt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtdW5o aWRlOm5vOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lp LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCW1zby1zdHlsZS1ub3Nob3c6 eWVzOw0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCglt c28tYW5zaS1mb250LXNpemU6MTEuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5z aS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNv bG9yOiM5OTMzNjY7fQ0Kc3Bhbi5TcGVsbEUNCgl7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLXNw bC1lOnllczt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cgltc28tZGVmYXVsdC1wcm9wczp5ZXM7DQoJZm9udC1zaXplOjEwLjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjsNCgltc28taGVhZGVyLW1hcmdpbjouNWluOw0KCW1zby1mb290ZXItbWFyZ2luOi41 aW47DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gMTBdPjxzdHlsZT4vKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9ybWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6 IlRhYmxlIE5vcm1hbCI7DQoJbXNvLXRzdHlsZS1yb3diYW5kLXNpemU6MDsNCgltc28tdHN0eWxl LWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtcWZvcm1hdDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsN Cgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46 MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3 aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5r PWJsdWUgdmxpbms9cHVycGxlIHN0eWxlPSd0YWItaW50ZXJ2YWw6LjVpbic+PGRpdiBjbGFzcz1X b3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDtjb2xvcjojOTkzMzY2Jz5E ZWFyIFJ1aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTpBcmlh bDtjb2xvcjojOTkzMzY2Jz5JIGhhdmUgdG8gYWRtaXQgdGhhdCBJIGFtIGEgYml0IGxvc3QgaGVy ZeKApuKApi5hbmQgSSBkbyBub3QgZ2V0IHdoYXQgeW91ciBwb2ludCBpc+KApi4uYW5kIGhvdyBh bGwgdGhpcyByZWxhdGVz4oCmLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250 LWZhbWlseTpBcmlhbDtjb2xvcjojOTkzMzY2Jz5JIGFtIGxvb2tpbmcgZm9yIHB1cmUgdGVjaG5p Y2FsIGRpc2N1c3Npb24gYW5kIGNhbm5vdCBzZWUgaG93IHRoZSBiZWxvdyBjb250cmlidXRlcyB0 byB0aGF04oCmLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTpB cmlhbDtjb2xvcjojOTkzMzY2Jz5JIHdhcm1seSBlbmNvdXJhZ2UgeW91IHRvIHByb3ZpZGUgdGVj aG5pY2FsIGlucHV0IGZvciB0aGUgZGlzY3Vzc2lvbiBpbiBvcmRlciB0byBhbGxvdyB1cyB0byBm cnVpdGZ1bGx5IGNvbnNpZGVyIGFuZCBkaXNjdXNzIHRoYXTigKY8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDtjb2xvcjojOTkzMzY2Jz5CZXN0IHJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7Y29s b3I6Izk5MzM2Nic+TnVyaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZh bWlseTpBcmlhbDtjb2xvcjojOTkzMzY2Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTtt c28tYmlkaS1mb250LWZhbWlseTpBcmlhbDtjb2xvcjojOTkzMzY2Jz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9y bWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjttc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjttc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIic+IGV4dCBSdWkgQ29zdGEgW21haWx0bzpSQ29zdGFAcHRpbm92YWNhby5wdF0gPGJy PjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMDMsIDIwMTIgNjoxMSBQTTxicj48Yj5U bzo8L2I+IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTsgTWFsY29sbS5C RVRUU0B6dGUuY29tLmNuOyBtcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8YnI+ PGI+U3ViamVjdDo8L2I+IFJFOiBbbXBsc10gRlc6IFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsb25k cmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5VbmRlcnN0b29kLCBvbmNlIHdl4oCZ cmUgcXVvdGluZyBhbm90aGVyIFNET+KAmXMgZG9jdW1lbnQsIGJ1dCBtb3JlIGltcG9ydGFudCBp cyBiZWluZyBjb2hlcmVudCB3aXRoIG91cnNlbHZlczogd2UgY2Fu4oCZdCBjcml0aWNpemUgdG9k YXkgY29tbWVudGluZyBhbm90aGVyIFNET+KAmXMgZG9jdW1lbnRzL2V2ZW50cyB3aGVuIHdlIGRp ZCB0aGF0IHNhbWUgdGhpbmcgeWVzdGVyZGF5ICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvaWV0Zi9jdXJyZW50L21zZzcxMTc0Lmh0bWwiPmh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZXRmL2N1cnJlbnQvbXNnNzExNzQuaHRtbDwvYT4p LCBpbmNvaGVyZW50bHkgd2l0aCB3aGF0IHdlIGhhZCB3cml0dGVuIHRoZSBkYXkgYmVmb3JlICg8 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50 L21zZzA2NzU1Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxz L2N1cnJlbnQvbXNnMDY3NTUuaHRtbDwvYT4pLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkEgc3ViamVjdGl2ZSBwb3NpdGlvbiBicmluZ3MgY29u dHJhZGljdGlvbiBhbmQgbG9zcyBvZiBsb2dpYywgYW5kIGhlbmNlIG91ciByZWZlcmVuY2VzIHRv IHRoZSB3b3JkIOKAnHRlY2huaWNhbOKAnSBsb3NlIHRoZWlyIHNlbWFudGljcy4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5SZWdhcmRzLCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UnVpJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW91dGxpbmUtbGV2ZWw6MSc+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZyI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZzwv YT5dIDxiPk9uIEJlaGFsZiBPZiA8L2I+U3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFT aGFyb24pPGJyPjxiPlNlbnQ6PC9iPiB0ZXLDp2EtZmVpcmEsIDIgZGUgT3V0dWJybyBkZSAyMDEy IDE4OjE0PGJyPjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOk1hbGNvbG0uQkVUVFNAenRlLmNv bS5jbiI+TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1wbHNA aWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnIj5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBS ZTogW21wbHNdIEZXOiBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbG9uIGRyYWZ0LWlldGYtbXBscy10 cC1yaW5nLXByb3RlY3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rIHlvdSBNYWxjb2xtITxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5PYnZpb3VzbHkgaXQg aXMgaW1wb3NzaWJsZSB0byBjb25zaWRlciBzb21ldGhpbmcgdGhhdCB3YXMgbm90IHBvc3RlZC4g PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp bic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tb3V0bGluZS1sZXZlbDoxJz48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnIj5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86bXBs cy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+ T24gQmVoYWxmIE9mIDwvYj5leHQgPGEgaHJlZj0ibWFpbHRvOk1hbGNvbG0uQkVUVFNAenRlLmNv bS5jbiI+TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuPC9hPjxicj48Yj5TZW50OjwvYj4gVHVlc2Rh eSwgT2N0b2JlciAwMiwgMjAxMiA2OjQ3IFBNPGJyPjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRv Om1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnIj5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6 PC9iPiBSZTogW21wbHNdIEZXOiBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbG9uIGRyYWZ0LWlldGYt bXBscy10cC1yaW5nLXByb3RlY3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5JIGV4cGVjdCB0aGF0IHRoaXMgbGlhaXNv biB3aWxsIGJlIHBvc3RlZCBpbiB0aGUgbmV4dCBmZXcgZGF5cy48L3NwYW4+IDxicj48YnI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPklUVSBtZW1iZXJzIGNhbiBmaW5kIHRoZSBsaWFpc29uIGFzIEFubmV4IEkgb2YgVEQ3NDQv UExFTi48L3NwYW4+IDxicj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlJlZ2FyZHMsPC9zcGFuPiA8YnI+PGJyPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz5NYWxjb2xtPC9zcGFuPiA8YnIgc3R5bGU9J21zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJy ZWFrJz48IVtpZiAhc3VwcG9ydExpbmVCcmVha05ld0xpbmVdPjxiciBzdHlsZT0nbXNvLXNwZWNp YWwtY2hhcmFjdGVyOmxpbmUtYnJlYWsnPjwhW2VuZGlmXT48bzpwPjwvbzpwPjwvcD48dGFibGUg Y2xhc3M9TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD0iMTAwJSIg c3R5bGU9J3dpZHRoOjEwMC4wJTttc28tY2VsbHNwYWNpbmc6MS41cHQ7bXNvLXlmdGktdGJsbG9v azoxMTg0O21zby1wYWRkaW5nLWFsdDowaW4gMGluIDBpbiAwaW4nPjx0ciBzdHlsZT0nbXNvLXlm dGktaXJvdzowO21zby15ZnRpLWZpcnN0cm93Onllczttc28teWZ0aS1sYXN0cm93Onllcyc+PHRk IHdpZHRoPSIzNiUiIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjM2LjAlO3BhZGRpbmc6Ljc1cHQg Ljc1cHQgLjc1cHQgLjc1cHQnPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mcXVvdDtTcHJl Y2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbikmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpudXJpdC5zcHJlY2hlckBuc24uY29tIj5udXJpdC5zcHJlY2hlckBuc24uY29tPC9hPiZn dDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiInPiA8L3NwYW4+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlNlbnQgYnk6IDxhIGhyZWY9Im1h aWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT48L3Nw YW4+IDxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjAyLzEwLzIwMTIgMTA6NTEgQU08L3NwYW4+IDxv OnA+PC9vOnA+PC9wPjwvdGQ+PHRkIHdpZHRoPSI2MyUiIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRo OjYzLjAlO3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPjx0YWJsZSBjbGFzcz1Nc29O b3JtYWxUYWJsZSBib3JkZXI9MCBjZWxscGFkZGluZz0wIHdpZHRoPSIxMDAlIiBzdHlsZT0nd2lk dGg6MTAwLjAlO21zby1jZWxsc3BhY2luZzoxLjVwdDttc28teWZ0aS10Ymxsb29rOjExODQ7bXNv LXBhZGRpbmctYWx0OjBpbiAwaW4gMGluIDBpbic+PHRyIHN0eWxlPSdtc28teWZ0aS1pcm93OjA7 bXNvLXlmdGktZmlyc3Ryb3c6eWVzJz48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVw dCAuNzVwdCAuNzVwdCAuNzVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxl PSd0ZXh0LWFsaWduOnJpZ2h0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5Ubzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L3RkPjx0 ZCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Jz48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+Jmx0OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5t cGxzQGlldGYub3JnPC9hPiZndDs8L3NwYW4+IDxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48dHIg c3R5bGU9J21zby15ZnRpLWlyb3c6MSc+PHRkIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6Ljc1 cHQgLjc1cHQgLjc1cHQgLjc1cHQnPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHls ZT0ndGV4dC1hbGlnbjpyaWdodCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Y2M8L3NwYW4+PG86cD48L286cD48L3A+PC90ZD48 dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PC90 ZD48L3RyPjx0ciBzdHlsZT0nbXNvLXlmdGktaXJvdzoyO21zby15ZnRpLWxhc3Ryb3c6eWVzJz48 dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PHAg Y2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz5TdWJqZWN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvdGQ+PHRkIHZhbGlnbj10b3Agc3R5bGU9 J3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz5SZTogW21wbHNdIEZXOiBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAgY2VsbHBh ZGRpbmc9MCBzdHlsZT0nbXNvLWNlbGxzcGFjaW5nOjEuNXB0O21zby15ZnRpLXRibGxvb2s6MTE4 NDttc28tcGFkZGluZy1hbHQ6MGluIDBpbiAwaW4gMGluJz48dHIgc3R5bGU9J21zby15ZnRpLWly b3c6MDttc28teWZ0aS1maXJzdHJvdzp5ZXM7bXNvLXlmdGktbGFzdHJvdzp5ZXMnPjx0ZCB2YWxp Z249dG9wIHN0eWxlPSdwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Jz48L3RkPjx0ZCB2 YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Jz48L3RkPjwv dHI+PC90YWJsZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+ PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQ7bXNvLW91dGxpbmUtbGV2ZWw6MSc+PGJyPjxicj48YnI+PHR0PjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Jz5EaWQgSSBtaXNzIGFueSBsaWFpc29uIG9uIHRoaXM/PC9z cGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0Pjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5UbyB3aGF0IGlzc3VlIGRvIHlvdSByZWZlcj88 L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjxicj48L3NwYW4+ PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YnI+PC9zcGFu Pjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+RnJvbTogPGEgaHJlZj0ibWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZyI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPiBbPC9zcGFu PjwvdHQ+PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyI+PHR0PjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Jz5tYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPC9zcGFu PjwvdHQ+PC9hPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+XSBPbiBCZWhhbGYg T2YgZXh0IEVyaWMgR3JheTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz48YnI+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+U2VudDogVHVl c2RheSwgT2N0b2JlciAwMiwgMjAxMiA0OjEwIFBNPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz5UbzogPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+ PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0 PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5TdWJqZWN0OiBbbXBsc10gRlc6IFdvcmtp bmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb248 L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjxicj48L3NwYW4+ PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5Gb3J3YXJkZWQuLi48L3NwYW4+PC90 dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjxicj48L3NwYW4+PHR0PjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bh bj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YnI+PC9zcGFuPjx0dD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+RnJvbTogPGEgaHJlZj0ibWFpbHRvOnlhbmcuamlh bjkwQHp0ZS5jb20uY24iPnlhbmcuamlhbjkwQHp0ZS5jb20uY248L2E+IFs8L3NwYW4+PC90dD48 YSBocmVmPSJtYWlsdG86eWFuZy5qaWFuOTBAenRlLmNvbS5jbiI+PHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz5tYWlsdG86eWFuZy5qaWFuOTBAenRlLmNvbS5jbjwvc3Bhbj48L3R0 PjwvYT48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPl0gPC9zcGFuPjwvdHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz5TZW50OiBTYXR1cmRheSwgU2VwdGVtYmVyIDI5LCAyMDEyIDU6MTUg QU08L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjwvc3Bhbj48 dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPlRvOiBMb2EgQW5kZXJzc29uPC9zcGFu PjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5DYzogTVBMUy1UUCBhZCBob2MgdGVhbTsgPGEgaHJl Zj0ibWFpbHRvOmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5v cmciPmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8L2E+ OyA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT47IDxhIGhy ZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwv YT47IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+bXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc8L2E+PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5TdWJq ZWN0OiA8L3NwYW4+PC90dD48dHQ+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDttc28tYW5zaS1sYW5ndWFnZTpQVDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+562U 5aSNPC9zcGFuPjwvdHQ+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz46IFttcGxz XSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90 ZWN0aW9uPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48YnI+ PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+SGkgQWxsLDwvc3Bhbj48 L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YnI+PGJyPjwvc3Bhbj48dHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkkgdGhpbmsgd2Ugc2hvdWxkIGFkZHJlc3MgYWxs IHRoZSBpc3N1ZXMgdGhhdCBJVFUgbGlhaXNvbiBtZW50aW9uZWQuPC9zcGFuPjwvdHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48YnI+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+QlIsPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5KaWFu PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48YnI+PGJyPjxi cj48YnI+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz48YnI+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTG9hIEFuZGVyc3NvbiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+ PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjwvc3Bhbj48dHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51Ij5sb2FAcGkubnU8L2E+Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3Nw YW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+PC90dD48dHQ+PHNwYW4gbGFuZz1aSC1DTiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDttc28tYW5zaS1sYW5ndWFnZTpQVDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTic+5Y+R5Lu25Lq6PC9zcGFuPjwvdHQ+PHR0PjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz46ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PC9zcGFuPjwvdHQ+PHR0PjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6UFQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04nPuaUtuS7tuS6uiA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ PGJyPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1wbHMtYm91bmNlc0BpICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjwvdHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBldGYub3JnICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzwvc3Bhbj48L3R0Pjx0dD48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O21zby1hbnNpLWxhbmd1YWdlOlBUO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOJz7mioTpgIEgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxi cj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZx dW90OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+Jmd0 OywgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO01QTFMtVFAgYWQgaG9jIHRlYW0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjwvdHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAyMDEyLTA5LTE5ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZs dDs8YSBocmVmPSJtYWlsdG86YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQiPmFobXBscy10cEBsaXN0 cy5pdHUuaW50PC9hPiZndDssICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YnI+PC9zcGFu Pjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgMTg6NDggJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1w cm90ZWN0aW9uQHRvbyA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ PGJyPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 bHMuaWV0Zi5vcmcsICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+PC90 dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjwvc3Bhbj48dHQ+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIj5tcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT4m cXVvdDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3NwYW4+PC90dD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQnPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZyI+bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz48YnI+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48L3R0Pjx0dD48c3BhbiBsYW5nPVpILUNOIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O21zby1hbnNpLWxhbmd1YWdlOlBUO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOJz7kuLvpopggPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1ttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiAmbmJzcDsgJm5ic3A7ICZu YnNwOzwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YnI+PC9zcGFu Pjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1pZXRm LW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uICZuYnNwOyAmbmJzcDsgPC9zcGFuPjwvdHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPjwvdHQ+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFu PjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PHR0 PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3Nw YW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxi cj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPjxicj48YnI+PGJyPjxicj48YnI+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+V29ya2luZyBHcm91cCw8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+PGJyPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz50aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24g ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMi10eHQuPC9zcGFuPjwvdHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48YnI+PC9zcGFuPjx0dD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+UGxlYXNlIG5vdGUgdGhhdCB0aGVyZSBhcmUgdHdvIElQUiBk aXNjbG9zdXJlcyAjIDE0NjIgYW5kICZuYnNwOyMgMTg3MiByZWxhdGVkIHRvIHRoaXMgZG9jdW1l bnQuPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48YnI+PC9z cGFuPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+UGxlYXNlIHNlbmQgeW91ciBj b21tZW50cyB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdHMgKDxhIGhyZWY9 Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPikuPC9zcGFuPjwvdHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48YnI+PC9zcGFuPjx0dD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+VGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgT2N0 b2JlciAzLCAyMDEyLjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48 YnI+PGJyPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPi9Mb2E8L3Nw YW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjwvc3Bhbj48dHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPmZvciB0aGUgbXBscyB3ZyBjby1jaGFpcnM8L3Nw YW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjxicj48YnI+PC9zcGFu Pjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+LS08L3NwYW4+PC90dD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjxicj48YnI+PC9zcGFuPjx0dD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+TG9hIEFuZGVyc3NvbiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tIj5s b2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbTwvYT48L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdCc+PGJyPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPlNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiPmxvYUBwaS5u dTwvYT48L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjwvc3Bh bj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkVyaWNzc29uIEluYyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMzwvc3Bhbj48 L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YnI+PC9zcGFuPjx0dD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOys0NiA3NjcgNzIgOTIgMTMgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+PGJyPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPm1wbHMg bWFpbGluZyBsaXN0PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxi cj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YSBocmVmPSJtYWls dG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48L3NwYW4+PC90dD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9zcGFuPjwv dHQ+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YnI+PGJyPjwvc3Bhbj48dHQ+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5tcGxz IG1haWxpbmcgbGlzdDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48 YnI+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGEgaHJlZj0ibWFp bHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvc3Bhbj48 L3R0PjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGJyPjwvc3Bhbj48dHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPjxicj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5tcGxzIG1h aWxpbmcgbGlzdDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YnI+ PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGEgaHJlZj0ibWFpbHRv Om1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQnPjxicj48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvc3Bhbj48L3R0 PjwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CDA212.1AF8BB9F-- From adrian@olddog.co.uk Thu Oct 4 02:55:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C211D21F86E4 for ; Thu, 4 Oct 2012 02:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkgmI5Z3NpaF for ; Thu, 4 Oct 2012 02:55:13 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id AEE0F21F86B4 for ; Thu, 4 Oct 2012 02:55:12 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q949tB2w031499; Thu, 4 Oct 2012 10:55:11 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q949tAJs031477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Oct 2012 10:55:10 +0100 From: "Adrian Farrel" To: References: <5059A308.3050307@pi.nu> <506D3458.6030300@pi.nu> In-Reply-To: <506D3458.6030300@pi.nu> Date: Thu, 4 Oct 2012 10:55:09 +0100 Message-ID: <0f7601cda216$57643e60$062cbb20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHr208rUMCisCjWbEYgksVEhfEO6gMTizwel1PQIgA= Content-Language: en-gb Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 09:55:13 -0000 Hi, I've now had the opportunity to read through the most recent version of this document. While I support this work as a useful indication of how RFC 6378 can be used in a ring topology, and while I would like to see this document progress to be published as an Informational RFC in a timely manner, I think that the document needs more polish. Normally I hold off from polish-inducing reviews until the publication request reaches me as AD, but in this case I think that there are some significant wrinkles that the WG needs to address before even starting WG last call! I agree with Paul's analysis that this is a useful document because it explains how you run linear protection on a ring topology and shows what can be achieved in terms of offering protection on a ring without developing or using another mechanism. This seems to be valuable for operators (who have to choose between mechanisms) and does not appear to be in contradiction to RFC 5654 or RFC 6372. It should be noted that the ring protection section of 5654 is talking about the requirements that have to be met by a protection solution developed to provide ring protection (i.e. an topology-specific optimized solution) whereas this I-D is explaining what you get when you apply linear protection on a ring. Thus, I think it is an over-reaction to suggest that this I-D is defining a new mechanism (where others may exist) and I think it may demonstrate unwarranted paranoia (instead of the normal type) to imply that the progression of this document halts or bars any other work on ring-specific solutions. However, I feel that the current version of the draft is not clear enough about its objectives. In that context, the document filename is unfortunate: I would have chosen something different, but it is not so very important once the document has become an RFC. I think the Abstract could usefully be rewritten. Something like: OLD This document presents an applicability statement to address the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) on multiple layers. The MPLS-TP Requirements document specifies specific criteria for justification of dedicated protection mechanism for particular topologies, including optimizing the number of OAM entities needed, minimizing the number of labels for protection paths, minimizing the number of recovery elements in the network, and minimizing the number of control and management transactions necessary. The document proposes a methodology for ring protection based on existing MPLS-TP survivability mechanisms, specifically those defined in MPLS-TP Linear Protection, without the need for specification of new constructs or protocols. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. NEW This document presents an applicability of linear protection mechanisms for Multi-Protocol Label Switching Transport Profile (MPLS-TP) in ring topologies. Those topologies may be physical or logical rings. Protection on rings offers a number of opportunities for optimization as the protection choices are starkly limited (all traffic traveling one way around a ring can only be switched to travel the other way on the ring), but also suffers from some complications caused by the limitations of the topology. Requirements for MPLS-TP protection and specifically for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document shows how MPLS-TP linear protection as defined in RFC 6378 can be applied in ring topologies, discusses how the requirements are met, and describes scenarios in which the function provided by linear protection in a ring topology falls short of some of the requirements. END Of course, having made that change, we would need to reflect the change in the document. To some extent, that involves picking up the scenarios and issues raised in other emails on this thread (such as Cheng Weiqiang's concern about second-order failures) and either demonstrating how they can be addressed using linear protection, or calling them out as scenarios where LP is not a perfect solution. I think it would also be helpful if the I-D had a section listing the requirements and noting how they are met (or not). Loa's three points are valid, and I am particularly worried that there is a whole section marked TBD in a document that went to last call. Makes me wonder whether authors read their own document :-( I thought Yoshinori's email was particularly constructive. Using the words "protection in a ring topology" in place of "ring protection" seems like a great gain because it avoids the overloaded terminology and will avoid countless sensitivities. There are plenty of editorial nits that need work. I don't think I will list them at this time because many have been caught by others (Yoshinori has a great list, Alessandro spotted the bug in figure 1) and I hate duplicated work especially when the text may be going to change considerably to address other issues. Maybe we can come back and review a later version of the document for any remaining nits. = = = = = Summary. I support the idea of publishing such a document as an Informational RFC, but this version is not ready. Thanks, Adrian From chengwq@gmail.com Thu Oct 4 04:02:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB73A21F8606 for ; Thu, 4 Oct 2012 04:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_102=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mEFkfg8TOtc for ; Thu, 4 Oct 2012 04:02:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD6E421F85BB for ; Thu, 4 Oct 2012 04:02:18 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so446016vbb.31 for ; Thu, 04 Oct 2012 04:02:18 -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=n1w2YFRUViHv2+f2eY2xQhwG3SV1+/8YvCMm3VSbvQs=; b=cUXgf4D1Ug64EKTscMQdKsB51+I5eCG+4d+9DsJUCIkT6UXQ3LWhZOtGBmHS/QtnZZ FEzColWxxbcqbFsrbeVBhZbKF024/zvGrlZIXdNMpwwPOdre/vNlkEnuuZi9/K+T8jT3 yA4Gs+J7m5j9vWt1X9uSWe+cT6RiZCd+FvSQla5TQ48G64POVb+fZByRGRr4TokLW4yM xjPgc0dMtHs7Zi4kSPjNw9wlo5KdR6jEqtoRtJRXVuA9m/Obxt6eIbp2YLtS48AmJS9B kd4bMZ08PitHcZlYpTu0tnM/xK3adi4F4oGh/xR2eY/IfUeERnzPBiqSZSC7vtb8dpGL PFRg== MIME-Version: 1.0 Received: by 10.52.31.99 with SMTP id z3mr2428732vdh.44.1349348537950; Thu, 04 Oct 2012 04:02:17 -0700 (PDT) Received: by 10.58.28.210 with HTTP; Thu, 4 Oct 2012 04:02:17 -0700 (PDT) In-Reply-To: <0e7901cda17b$bafe9bf0$30fbd3d0$@olddog.co.uk> References: <0e2901cda16b$09f5d1d0$1de17570$@olddog.co.uk> <0e7901cda17b$bafe9bf0$30fbd3d0$@olddog.co.uk> Date: Thu, 4 Oct 2012 19:02:17 +0800 Message-ID: From: cheng weiqiang To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: mpls@ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 11:02:20 -0000 Hi, R106 of RFC 5654 mentioned "SHOULD protect against multiple failures". And well known, the multi-failures recovery is a basic function for ring protection. And the double failures scenario I mentioned is the most basic multiple failures condition. By the way, the wrapping solution of the draft cannot handle the adjacent nodes failures also. I don't think they are corner cases. I give you some examples for your reference. For the Micro-wave system, the adjacent hops often are impacted by whether or other facts at the same time. For the adjacent nodes, they often share the same power supply system. When issues happen on power system, they may shut down simultaneous. So for the carrier grade system, the multi-failures scenarios I mentioned should be the basic functionality. B.R. Cheng Weiqiang On Oct 3, 2012 11:28 PM, "Adrian Farrel" wrote: > > I'm not going to make any comment about consensus on the document - That is the > job of the WG chairs and I am on the appeals path for any such assessment. > > It seems to me that there are certainly some questions to be answered (that > might result in explanations, or might result in caveats being added to the > document). It also seems to me that this document is not trying to say "here is > the only solution that can ever work in MPLS-TP rings" but is actually saying > that here is how you might get protection on a ring using linear protection > techniques without the need for specification of new constructs or protocols. as > such, I don't believe that corner cases (and frankly, second order failures on a > ring should not be regarded as primary design features, should they?) prevent > publication, but should be highlighted as potential draw-backs. > > Thanks, > Adrian > > > -----Original Message----- > > From: cheng weiqiang [mailto:chengwq@gmail.com] > > Sent: 03 October 2012 15:53 > > To: adrian@olddog.co.uk > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection > > > > Adrian, > > > > Thank you very much for your prompt and detailed reply. I need more > > time to digest it. However, the current draft is really not mature to > > get WG consensus. Do you agree? > > > > B.R. > > Cheng Weiqiang > > > > > > 2012/10/3 Adrian Farrel : > > > Hi, > > > > > > Thanks for taking the time to set out your concerns. > > > > > > I hope this now gives the WG something to work with. > > > > > > With regard the first point, I hope to hear from the authors whether you > > > have identified a scenario where linear protection will not work (in which > > > case they should probably flag this short-coming in the I-D) or if they can > > > see how linear protection can handle the double failure case you have > > > illustrated. > > > > > > Obviously, we don't have access to C-2098 and can't take it as input to the > > > IETF discussions, so if its authors (was that you?) want to take that > > > material as contribution to the MPLS WG's work, you need to submit it either > > > as an Internet-Draft or as email. > > > > > > The second of your discussion points is related to Section 2.5.6.1 of RFC > > > 5654, and specifically R100. I reproduce it here for our readers: > > > > > > 100 Recovery techniques in a ring SHOULD be identical (or as similar > > > as possible) to those in general transport networks to simplify > > > implementation and operations. However, this MUST NOT override > > > any other requirement. > > > > > > I think the authors need to address this point, but my understanding is that > > > the whole section is intended to describe the requirements that have to be > > > satisfied by topology-specific solutions. Thus, if we were inventing a new > > > protection solution applicable in rings then we would need to address these > > > requirements directly. However, I believe that the I-D that is in last call > > > is called "Applicability of MPLS-TP Linear Protection for Ring Topologies". > > > That is, it does not define a new mechanism, but specifically shows how the > > > general mechanism can be applied. > > > > > > Obviously, I can't speak for the WG, but it would seem to me that nothing in > > > this I-D precludes the development of a topology-specific solution for rings > > > that meets the optimization criteria in Section 2.5.6.1 of RFC 5654 and also > > > addresses the specific requirements in that section. It also seems to me > > > that the I-D in question is not a protocol specification at all (note that > > > it is an Informational draft) and actually does not even describe anything > > > other than how linear protection might apply in a ring topology. > > > > > > So I am not quite sure why you believe that the failure of the generic > > > solution to address a requirement intended to describe optimizations is a > > > reason to not publish this document. Rather, in your shoes, I would see it > > > as an encouragement to do topology-specific work to follow on from this > > > current I-D. > > > > > > Cheers, > > > > > > Adrian > > > > > >> -----Original Message----- > > > > > >> From: cheng weiqiang [mailto:chengwq@gmail.com] > > >> Sent: 03 October 2012 10:40 > > >> To: adrian@olddog.co.uk > > >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring- > > >> protection@tools.ietf.org; larryli888@yahoo.com.cn > > >> Subject: Re: [mpls] Working group last call on > > >> draft-ietf-mpls-tp-ring-protection > > > > > >> Dear adrian, > > > > > >> Here I would like to try to describe some issues on the ring > > >> protection solution from my point view. > > >> > > >> 1. The Wrapping solution doesn't work when Multi-links faults happen > > >> > > >> For each link in the ring, current wrapping solution defines two SPME > > >> - the first is a SPME between the two LSRs that are connected by the > > >> link, and the second SPME > > >> between these same two LSRs but traversing the entire ring (except the > > >> link that connects the LSRs). > > > > > >> ___ ___ x ___ > > >> ======>/LSR\********/LSR\********/LSR\ > > >> \_B_/ \_A_/ \_F_/ > > >> * * > > >> * * > > >> * *x > > > _* ___ *_ > > >> /LSR\********/LSR\********/LSR\======> > > >> \_C_/ \_D_/ \_E_/ > > >> > > >> ===> connected LSP *** physical link > > >> x link fault > > >> > > >> Above figure shows that One LSP enter the ring from LSR B and Exit > > >> from LSR E. And at the same time the link A-F and link F-E are both > > >> broken. According to current solution, both the protection SPME for > > >> A-F and the protection SPME for Link F-E should be activated > > >> synchronously. Obviously, it does not work. > > >> > > >> At the same situation, the ring protection for SDH, G.8132(T-MPLS) and > > >> the MSRP solution (C-2098 "MPLS-TP Shared-Ring protection (MSRP) > > >> mechanism for ring topology", ITU-T SG15 meeting, Sep. 2012) can > > >> work well. > > >> > > >> 2.Steering function is totally the same with 1:1 linear protection > > >> > > >> As the draft mentioned "we use 1:1 linear protection [SurvivFwk] > > >> [LinProtect] to perform protection switching and coordination when a > > >> signal fault is detected." It is the basic 1:1 linear protection(we > > >> can see it as a SNC protection, in another words 1:1 linear > > >> protection is using in sub-network). > > >> > > >> It does not provide any more simplicity and optimism than 1:1 linear > > >> protection. That is why we say this draft cannot meet R100 of RFC5654 > > >> the requirement. > > >> > > >> So I don't think we need defined it in the ring draft redundantly again. > > >> > > >> Best Regards, > > >> > > >> Cheng Weiqiang > > >> Research Institute of China Mobile > From loa@pi.nu Thu Oct 4 06:34:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB0021F86BD for ; Thu, 4 Oct 2012 06:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81VLHzm1M+t7 for ; Thu, 4 Oct 2012 06:34:09 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD1921F86B9 for ; Thu, 4 Oct 2012 06:33:50 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id C399851419D; Thu, 4 Oct 2012 15:33:48 +0200 (CEST) Message-ID: <506D903E.10001@pi.nu> Date: Thu, 04 Oct 2012 15:33:50 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" , MPLS-TP ad hoc team , draft-ietf-mpls-tp-ring-protection@tools.ietf.org, "mpls-chairs@tools.ietf.org" References: <5059A308.3050307@pi.nu> In-Reply-To: <5059A308.3050307@pi.nu> Content-Type: multipart/mixed; boundary="------------050108080005080808020609" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 13:34:10 -0000 This is a multi-part message in MIME format. --------------050108080005080808020609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Working group, Please find included my comments as a working group chair on draft-ietf-mpls-tp-ring-protection, the comments were sent to the authors earlier, but since they were not addressed in the version we working group last called the authors need to address them as part of the working group last call comment resolution process. I would also state that I'm in favor of progressing this draft and publish an Informational RFC. Also I believe that there quite a bit work to to complete the document. /Loa On 2012-09-19 12:48, Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 > related to this document. > > Please send your comments to the mpls working group mailing lists > (mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 --------------050108080005080808020609 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-ietf-mpls-tp-ring-protection-02.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-mpls-tp-ring-protection-02.docx" UEsDBBQABgAIAAAAIQAe64zQgQEAACgGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lMtOwzAQRfdI/EPkLUrcskAIJemCxxKQ KB/gOpPWwi953NffM0nbCAFNRUs3kaJ4zr1zM558tDI6WUBA5WzBhtmAJWClq5SdFux9/JTe sgSjsJXQzkLB1oBsVF5e5OO1B0yo2mLBZjH6O85RzsAIzJwHS19qF4yI9Bqm3Av5IabArweD Gy6djWBjGhsGK/MXMhBUBcmrCPFZGNLhSxcqOmgMHcSMaCy535Q1ygUT3mslRSTffGGrb5qp q2sloXJy3gCyhuaDk4BInRmd7chXDZmX+QPUYq5j8rgiZ5swAmj8m+i2yYwqW2M4Ux57FPq7 2jrbG07XXD/miHA6shHK7vzv9WHnZgKBYv3/v9ShD5rAuNZwhjnZcPvkKazX4DxymsiTE4Bm /CqoUhpWDyEq6OZnb/4IMVL652h+S+5rv72nke498PY5PDmDFnNQsqZlMBYTDSfr/dgNHfqg iSVM3s6W/hd4n5Fu/qQLR4Sx21lN9S9Tx9s9X34CAAD//wMAUEsDBBQABgAIAAAAIQAekRq3 8wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9ab g5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Y y4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANa Xg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQBBQiNEGAEAADkE AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyTTU7DMBCF90jcwZo9cVKgIFSnG4TULYQD OMnkR8R2ZE+B3B4TKU0qqrDxxtI8y+99nrF3+2/VsU+0rjVaQBLFwFAXpmx1LeA9e7l5BOZI 6lJ2RqOAAR3s0+ur3St2kvwh17S9Y95FOwENUf/EuSsaVNJFpkftdypjlSRf2pr3sviQNfJN HG+5XXpAeubJDqUAeyhvgWVD75P/9zZV1Rb4bIqjQk0XIrhDIn8z5z2lrZEETErkOYFfRngI iUC+NTjnjyUf12SNYROSwdHQ+TnOTRjrtfgkZLw+qhytn8NMcJLWILYhISqjKZN5t5jFSVqD uA8JURj1+1QXo5iUNYS7kAhfmL/9+RULcQLhZx8+/QEAAP//AwBQSwMEFAAGAAgAAAAhACbZ U6Fu3QAARHQOABEAAAB3b3JkL2RvY3VtZW50LnhtbOx97XLbSJbl/43Yd8hgR2zZPaIs0vKX dswZWZZ6HGG7GJIqPNvVDkcSSJJogQAaH6LUMT/2HfbXvt4+yZ6bAEgkCJCwyyIAIV0VtkRJ VCYyz/2+5/7rv90tbHYr/MBynbe9weFRjwnHcE3Lmb3t/XZ90X/dY0HIHZPbriPe9u5F0Pu3 0X//b/+6PDFdI1oIJ2R4Cyc4ucVX52HonTx7FhhzseDBoesJB1+cuv6Ch/jUnz1bcP8m8vqG u/B4aE0s2wrvnw2Pjl72krdx3/Yi3zlJ3qK/sAzfDdxpSD9y4k6nliGSf9Kf8Kv83vgn3ydL lr/xmS9srMF1grnlBem7LX703bDFefomt9s2cbuw0+9belV+m+nzJc5jYcfLXrq+6fmuIYIA r76Pv7h6x8HRtt+dPEB6i9VPVFmC+jvTlSy45azehm5H7vxXh3eIw3sW/+5n9FbrjeBZjHCX Jq55T/96bHmCu2hevu0dHZ0dH1+cveulL41x0EdHL06PTgdnqxffiymP7HDz28eZb5bvPPbl P1fhvS3wlrfcftsb29jBtbgLe8/oi378Pf6F64QBvocHhmW97Z25kW8Jn30WS/q981Mn2HzV CNRvxBs+S94R/3r0zvSv3iQON3No786GR6+ep8f5Bw7NcujELBPHTu/Go3Du4sII2+WQXvSS yUNc0eHRYNg/et0fvrw+enNyPDg5OvprcvoPdOxY1Wptg+9fm7yYD3g7lyfh6C/CodsZxndW /o010y9dL334PUsfyse6j6WLnQuXt+v77sMeFk7q7iTwuIE76fkiEP6t6I18bjPISlKrJ+x6 LlgI4cSsgFkOmwlH0Nehre/ZzHXNAzaJQvaBzbnJOP72TRZaC8E8DhHqzFiIn59aswjvzpSn BLn0wBfq//3v/7Pf31j8OJnpqhd7Hzv/v/vd+ShkN467ZNaUDtwXdFu4cx/O5RVw2UTgKeBW 8ImL2xLOeXioLBC4l1gv1E6qeL7cpYLVb/8D0lyr4D9gZ+CSQ91JM0o5sIfFfDECP4sQBt8N +4K/6EL+xXcjj1X6o9zS5UkiFi+5MxNXIffDRN0fJ9q7hi2P/tch+yKwLawmp0HV9Z47Zslq peH6aji4eCnt4NQCVazUs1ghXIop4O0YothcOfUtDsdidW/izzNm6HpJ6Rtl1wT4f5eJenE6 HJ4d0++TFy1j0qlmewOEwPLExqXBSqXNL5z+b1cre/9sTvcpeRAvqpk4L64HL0+Oj9cmzs91 G9TlBrf9q3NaLh1Q4kXg33jdyqvSx8A3pUcSYz85pwfAvrrOLY8Vvn0Vg7yJj5Vs4g9OKHxH hH242tNQkUqFOlO9/5fKMaRn8yjg8qq950oHl6A2PRLlnOqECyJubYeLYwqTwoZhFJywD04c AESkDd7Lrj9Xh+ydf8+dHwVai+NDG7I72csDXMZUmZB8O7/zLLiIJ+xXI3QniHM9HxwwCpPs Oqr118+swHB/UDLqA1MDhwD/llgiDqzY0F4fxg989PmQXSEIgbC9r08xDTE/LOx+1il+dm8s zq4sgZhRgBC1dLcCfYrtOsUVZt8fsjNhGBy5Kdv6wVN8jK7Zm/YaRaW25l7U+8+SM6sbyjZi yY2zoAcVU0BN9ThJCPBba2ZbXIuAVXRmUDF51sRTLZUBDQjPDCpm9pr4XB/GHL44ZMgFm1oF K9HRQcVEahPvSaPxJ6PouxPUTXyuD4M/2BrnvmUEQS57S6dIXtmjrhLaiAI1QUW0ODPyYFdU Mc02Tq1G4/7TYd5ER7mgOz33fVjq4b2HipPAg3KTWdQas6dnLlKHuadYvFLkT5MUWAfxX+NN yjh9P/hhpeOt+yKe2qHP84VC+iY2Sab94PXL/tg7FGtEyn3spj3Rannyn4fsPVeVhj7Fn1t/ gucpC01+vuGkgG9DupxtlkH95Ips7Gj01+tzBsPDc33Z+6EsSd+kttwkdur5ls2Gb+JMdfdO sRNXtROb3JCDdevnU8+zLYPHvXnMnbJP449X/esx+2g5gvts7LuhMKhxjqGwh11SWe+167m2 O7OEzjyvWtQaUD+gyEXEzfJhgJnPF3U7X+huRHenJcJpf+HZQT/0+j6uVB+LTa5Z/2h4GN6p BWElm+lSoEBLxwezVkankwAhAUO9c5144J3YZMN07vUcPVurdnrZDUgNyNxhXNHFVFFLdV5o 43LzId6y9pjByxojvNw0UVmq2gTrNhTqvFh3xmwstAmtMfGigIm4YVKtdKnTUEOrn6LcNWwf TBmUVlApB1BikNRtXfniHxGqu0lo5GFYaA0mBlSjBCR5GWtrkDwSMhAhA1OfQ/ohn0ADYfXH sBpdw7WVs9Hg2D84PvKJsNnV0goN2Yl8jQxLgKhbSP7j1AIHx5PEr3zKst+LxpExmFTUy6oP cP8HqCComdKtWDI/+Xg1fsoQnViQRPBw03JbKTWVXtVoKtn8HixMW1aasZTy6yRLaXD2/PXF oL4m4oFcVJ2W0kjlNSi5sk1UcJLpI42yXWY09sopUO6FloZaGkoyqkxXOKW2UNRjWNN8DLZF OEg2YDDDt9Bzjb4mMv3+HgUhtmXIfB1Zf2gupc9gKaytQg2QmhuelAMouXN1O0MLdDhyxwoW VRbbREUhPSGQjVhGZCMTs/aADkAQZdgR0TYy1wMLlPVP6SKBAcqJFmjqVXasFYhWIEUKxJ0q 16QExU0Exq+nn8BbGlohtB9zhICKOGALy9kEAikQm3zTgJSLsl8NCw2LIliUWBktgge4dufB FkCg9d+VtILCjkOFxDeoQ8zkV9cZ5N9otcVNVOv4m5DABzUSUbwporSJ2BgdIKNmlmsFA6y/ vmvH38QdPpNQULalNYTWEEUagtoHApQLEJm4cmGaiIPiqCmsJmIU5/79IZPxqEw+GomWAHYV ZwsBVmWTKr3upWtOeRhlvxogGiBFAGm/CTXhAQJOyCqIOwvxKPjZacA2iPxb6zatl1zFGIID jQxtPe0i80qDtga37XvlwrRIdUApBGCZFlMUCJvkOqTQ2KgYPmBICM9jImpdwKK9i51kdyMK 5rQVFxSuTXMaq+yFI5ag+HdQXxoZKPJLaluoZiVQE5idsKU6sclGVVORdZ8tN6VxAZRIM3Ed KTjK2d9dCyWmKe0xO3dmkOtIx1GfBw9uwI3jG1p41y28n3w4v754yp4lByXlC/h1rxHCowKX yEkypgH7zaFenc0vKGJVA3H/nhvyoRis5pvWP2PtcIW2KuiDJx+uf+tfP2ViCgUia73j5B5m eMSmFVsV0+kjrNnFGCfFjGTWxjFzRriUFrCMJI6/nD9n3EcRJHUzyVk8KN4PIk/WQuoYu46x y6Fy2ymfRwb34gBDi6t7KPg+jRwZJeWY+0ipWmlvYAjWjYCcW1UIJxkFxtVgqlZR+1dRioIp CUnUXdaTBB6qLLWJtQuTezmpTSp97QE+ztGf9XiAIyATIzhIysI6CdgnsejglAatNvavNmSI IY0gxIOTaC5hEE0WVkiVu7CVp5FNwy7j6TAYayZDw7rqJDvluCYKiSqatG6lj4jVrUVTy1Ub scREaaLeh1R+dzZmr15LP1F++Ebr/8ep/zuhg6pvMqF6S9vp2zMNr2gaY/EguYdjs1PnLm6s qJS2bz2p9IDB3eY2Cn3ozy5pv4MruM6NprPLKm2hTAfUuYGSWqxK+ynXwHXuaJRMkau0hRYd CQ3F27Wn7dW4tZ5K0Ty/38eoca2ypxYd0+CrsiGtkjJjwGu8gJM19byHS5eQuX/XwOlk9Y/K ZoATo9bzN1fX2jwILwWG4vjCJLnxzhf8Bg3I1Hi8cvQV7JW4Yg1VW+83hjsXrF8eT4ukYWzg rf+murwqZ9TELY6IgvRyvN5M5qOEDRgza5XddVn6670Dv6mykFRyx8cXZ+9ojGRGJSbdXemL TXZEcaCSlp0ONgnopsuOR5fXqN7LZxIreKwpC7JST1LGo9zNR6wZHWtU0JZ2uSRJElFY9qZs ojqwHtPlqrcNcl12iOIoKntD6OIz6IGRLeAoWkQVjc9mvht5AVvwe4Q2ApeZaNPwrUkUqi6O Pr79Z4MU/BSYVdv95r1cvVEiEKostcw62stCSyJGaznGg5UMixNvQdLQZwMQlAo2It8nDtmV WFT2rPGh8VHUwZfoTqu16TYoinkYeifPnpkcZRFg974R/iHxzh+6/uyZSf5f8CwBxzOdiHuc ibh6TNASoc3WMjhjmsqbmDFMb1EsicpJFIajAZvfWYtoQWI8sO7YApQFmipVs3SQV7ujghjV t4qeLzHDmmjbkEk/ESzyILiJ18kXns0N+giY2LWpHRHVvdhsI3cSuLbA4iuttolngCLV2M3K GJrIITtqz7I2HrXxWGQ8gpBQ9cKbKH1G8JM+hFSmaDmYu+G7GDEHgUOzNiK0t6/cpVRVBxBE U6RDULqowFqDQIOgCAQLXCbcKHU0QROBUGKtQtkCCgb62KhIFzaoDLshAocxNQHrUQCFynoB nBkNfTnsdQ8VGvr7h35RqfnSQmm5uPMw+YQoe5KSJEY1PFQIo5177dzzwLCst70zN/ItZA8+ C9mGOT91gs1Xd7hWZ65371uzeUg5CauL1oCWe/uXe+tb98R4KsVa3Hl+7YMvX7YUQD8zD0NF 0CPBLJPokTEcwCRlja90Tzk3LPSnHECJGVheK7WfuEXq7FdZaxOjFjwC2ZhPCbBTGARSRpPX Fgj/VpjaCtBWwM+zAkqcpgK2JTRB/h1UIORMZfq/SFhL5hApv38J2Ecxy/mKWsvuX8uOV22G 7FLYoOlBzRAOTp7Ue9eINgcr6lPa/yk9STK74NQLQiHWWV0MshdOIPoWuoyfUnQCnEqEPTiF BDhKKCCXpqg3fX77Pz/lABpqC3nRBLdJEnVVWW4TzaGUByI162AXjW0BYmPYRLcWeCmBCSJy 1XLNMi/jotq92NmltkOVi1a3j2CgnJaoHNRMYAmIa0UFDYCQvu89uIoDzJhDUvke8Z/UMSCC KjgHqBqNmfxjQgq8grl6oXIUWkdoHVGU4glVep0mgqBE1kh+oFTwQy+cuabAXwvPdWh0OILp ISrmiLll6rsLKAqkSdNvx6DdQOOjbj5YRUCV3Ly6dUXCY1plqbVqihKQXFkLz46DqO+u3rOP sXPBQoCDNEuqVCS7EXG5Eu3u8aH2MDSlUZxd2pFHykflS0DcRGTESQcZsmKZkAlZVNRthZqA W2QgzNX0hyX3wfYZolVHrSfXhpU2rIoMq5VobavqSLihizWIzkQ8zkxEJ6SZ3iQSy0E+YJS2 Zrepo1yfpD5JMeWRHW7yJYxzPP0JBYF3Fd7b6KY/QZPS297Y5pZzDW+I+H3wLB/GlqFrSu+s r6u+rvq6ZhIUGpNa8PzhglYtXc8eGVGQ1pNaT2o9qfWkNtCRx1ye/KSST60ntZ5M9MrjjPE8 Rr5dYiHOxOpqZEzcQqdbnHzW7P1mElVqzBmWsV7uylHtoCSp8VaGmr2f+2kQoTn3bNQV9v6h Zu9P7UooqsZcQM3ej3wGDibHv4yqFs3ev0p81qq2JCdPJb1bVj1V5/KLLb4Mv338oWbvPzoq dDqTs0vlZZP9sR3Du1LpT/9SCnU3g32X957E9Npw7pvaI6feM/HJB8qb06SWaz5Buh59YGdg DqXCfkVmVr91LX7yndjkhvW4l+tVqscGRK3nhL5rRnFV/CH73v/YcfeuasNOkbHB4UA5hZIK 9brbTKiv1Xch6RZVVltmEdYJmQAM5YK4BVhloGiA1M4DTQBRJ1A1FyDXwl9Yjmu7s+Y37pbo FeouAeOabMmvABP2QpEG2g54mPLM0vnD0okdHD5XTqG5ACELWc4PAuVLlSU3UY2cxvxXFcBB 5hh7pexTA2T/ABmS6TLEnEPiGYINEyZdpBVPUJ9iI2g7GBu2xlD+4oPrvMUi7nv9SC3mGtCN TQBpi6F8BUIxv1sAeaPtgKM6vX+ylIetMZRhryj3pcSkb6J9TLgmcoLUzIoCeuFq/Ol8q8E1 OFI2rA3l/RvKCURaY2aNeThXLk2LUCLxQPPnUlW4FRxkkA3UMLEGSH0AaYuZ1XY/ZGmFcxaI mQzaT8CpaW7TIwP1WDRA6gNIW+KRbQeIQ4yCGVtru+M+UI9FA6Q+gKiJ9xK7pQEp37YDhCws 23Ju5OyWPFo2TK6BeiwaIHUAZHionkJzwXHqcPs+aO/0dpSseUOvuv6AD6IejQbI/gHyXGaz Po2zx7YhyHbYATppXzexMGPPWxNmeQw2gDdceOzj1bha6ddAA6R+gEiItAYkROvOfQtzAdsa kYQ1kCJdWsuXv37qr17IaZiBrmppCkDUoFdzjeVPoEC0PFudkVmy3CamtS64ZUeYWyIHOMRI z4Eia3QNdLq3foA81/UQNGbkp9HzlFehUphFmlgeUnJBFSNLA6QBlfVkYrWnqk62192FbbWv bD4RdrBFZ2T1xyGGTysb1aGW/YdaqB6CANIWE+sLt2/Cue9Gs9aWRcTFQgY10mL+z1bIDNVj 0QDZP0COEYs8c13ftJy4YYhSka7h2lUsgFjcDXVOsm5D+YU8RcewAT7XCWLnXxjuAmUXGOYr X9uhtoY6L1D3Kb7EKX44/XxKLASYnCH8aieXNTqGOuxZ9ym+wiliyl3kW5jj9WMnqU+xds/q NU7x1Lhx3KUtzJnsOa9u+Cd6UWOxbiy+IYmKGff+AqL0VrBLMRW+cAzEALNSc9vHGou1YzFp 1/2FnZomwrfBd5xeerLDl91zxTvhTulNgg1Hj1nTw7lOB2c9SY0XxxD0BLIHoosjgUOPWAse LXj0+JhMO7Aes5YypD9MFFcLnkKS2+QGtpHsVKsQrUK0CtEqRE8g+5klTlpPaj2Z6JUmM97j mu6amzHz+aLeBtIt47hGm5O3lBBri+qCqUiInd95FtUG/2qE7kT47PngAAVcg6H8Yuav38d8 JtjzH53I02JzFRc2tbLHeyNL0zN29Iwd8ba3XRTWOaRmpGfsnIT3XnJGZW0ftZ5Q/xrMseOM DF9/eOr5li3lvKK8qnvmXZ4z0+W9az3+tnfmosgJptJnsezBMjAC9aWM4qIZO/lhJz8IuBY/ +OpSpcWbrMVKLBs5y5jsWewTZbgsav5IHRzsCqxkxpw4La997gSe64fEKj61MATqCY2Tg8Z4 ypQLiustq2nDS+7MhPTKcOUt821v8LpwAG9yhJSSfaBMJIHKCthEbLLwZtcKlVy20rco7SnQ zFfhPR7E8uSWIzKFrmjibltVTiWbvUB9f6Yv7dS3uE1CYH6K0tW3vfhzRQKka0pLsJRFkTfc kZxqwwCSu+Uo/1eHd263vPdzyzH2B2Xs6FH4pzCrrLfMCt3LasumsgQM7AIhDZnj7O+uhRlG YorKxBAADpdCOCycC5oGJnxHqB1yWm88TEa1vBkW4SBnZjkxwzm75sENu3B9A9rhw/n1xVPZ X7E+Llmmz212LWzZcxE5liFfU+6qPsX9n6JyACURyXojrOHoNwftOeAQTkWcvDm4aNe/9a+f HlbZQRPFHbuei0CwwBOGNU3ggL4kX7CYBBZbBoCU3WmAaIBIX1IxG8ORL/4RITRPVmigXJgS QDcRDuGch2yJ3gM2Ew41doEHeeq7C4AAJnzWHFAR3wlMdGKTzTb7U+dsw7l9U59zW2xIQ6+w rERgRFyS+OzbXPaMG5zfE7nBL18dD45fyArq1F3frxssFwUkwA2u56qMfs8J17I7MTyK78SG qwhlb9t1m1PX40vxj7yeyG5lfRG2b2RTjdA9GZw9f30xqO+exGuu854Uw/LrNuzJO5HEe4aD +iTKyHJMskVFxfuRX2ojLoBcVPMuAKIaGbHMQleRJlrFa9u+yLYPIo+i78pdaZFZzxlidUvX v4EdDwN/we+ZRSwcGOkQRJN+8sUg/ioocYLQCqNQMK5sWINj/+BILUY56owHzBRTxPtMHB/F JbKiLEAPed7o1MdX8yBA5QBKBEbdlqjpGhEFLaqsddPY3F+JXVny1HRRDum4IQMVjRNa03uE ve+znPUZfR+sIn3Q/Fq81U6ZUOXO1Y2PNk+PDV3Ptd3ZPXTDf7hLcSv8gw29wYIQrkas+9M4 uHIuWu/vX+8rB9BQxYHASjJ5tcpqm6g6FsKYc8cKFkj5WAuYVTCOpaWV4MaCZiFjeSJgeN0K 2/XI9Joq29Xo0Ogochlhngdq4rAExk0EBrdtdyk1xcpxdJnrhdYCtS0n3bv/GuQa5EUgdxn7 HC3Qh6VAokVAR5nXr6efGDlOIWk71BKZ0HFwjkLfms1QNU1hhhJN3wlUdGKT9aTyilM06Hqp gqa63cLHAH0UAspyFar29FETCP/wPhEByhF0AgOd2KQGOqr+v68h6DEAPRlvkERC1eL0Ttz7 TmxSg7uT4KYZJj4mYaAyG9EqB7wPpNSZZ3MHYV3qHONGPFvBRCMkusl0Wrduwu+W2LipTagY g23ybr1kOIWygU7ogk5sUiu8H1F4HzA/2Ghtuh+uqoLmAnHUiALfwJo53N7seS4uR25kEgD2 BEa8hWQyWOl0CjREiTvKms2EeUBlSB7YqGhUhXIoWvrsP17eEpvCVdOnBfClVu4m4iG1s6Vh 3b3rrjG9f0xfU9tdWqCX13smKEJibo/hkDgteBTOXTDeoU6BwxeklzBUD4xXxA/YP3rdHx5f D16evHh9cnT017g1BN9SOpXjvQCtxtHRxdHLF+9OlU6SHKlGLpyWUGvkXt3KuoOdXNMUzruF fRLAOMGapVrxb0VvtLRsW249+S7Jv4H2I9xHvFJXG1LxWqHcPRf9xJwFQnIooIvYMvIHl23z kWmM9Bif19hzsq6FUUSbSigDsVy21iZ0pw3lA8TFwPVolG8gy+4NN7JN1BIpz1dL1f1LVeUA SgyQutOLUdBeDhlqdVXLBijBSK9AH3E2RW1R0muC6CRyjlJgJp0OytlocGhwFJXdtLgkO+nS Ua65qmMVi+C4CRbBlsVmDIL8UhthEMhFNdAgIEI8DhHPZDzFQsMdgiwkAmUWJ+366nLdVaPs t3aUJJWa8Bsxx9pDLCPIwS/oPp3LMmOU3UuCmdUGqOLwFv1cZCbAm5pYNk2p1s3aumGrAoNv IjVzWqt5GCgOITDU3pO5nFt+aczgRX0WQvEGCLE7wx4ZuyG/gUbYDXJRddoNI0SbTdRkoxmf gQYYLMCSuYIHrsMnoL1FK4YANRdf6HBC3cUcOaQWCpq6wwmIB1dZZhPTLrK/O+09kvaA4Vug n7WSIGuEzm+H5VmhNk6hEUnhQtan4qXWehSjrwxkE0G0WHB/g81YR2V0VKYoKsMnaCBovJQZ aeZK85JsrMc2fq9hAYNTdNTYkkAVzeTIAWodlR3EkMsO/0DOOCQdZZqoPgqSMEHa3QC9Jdm6 iHJTEUdacWnFVaS4MORA+PC3HGGA8Fi5MiXZwVqNs2K3WxJXxCRgCC6nMufWtW8Bj1uYcW4E i84QDn0Yp9+UnWpwaHAUgSORqspdaREqppGPgJQPkqPIJGYw1K9QPREYXVLlIcn0yJfE3BMi QkrLrQ6ULWt4aHgUwUNm8ZSb0iJwxNMtkGwBG6jl2VAUKPdGzTqxHBHBZKb4UHtN2mvigWFt Npz8kO0+OBxUAU3dYVNkKce+i3j7ospqm2gVBkTut0Hv2Qlt1olNNizqcUl1LGv2vAMKI2c4 i3WUHmX6P0+KfsXzxaweqhWVCjudEqoIKw0DbbkWWa4p67tyWVpkvJoRsuDgKZsLy8+UCDGB lgv7fhUEnLjhnHlDT/p+3nDhKfvV4NDgKAKHpM1o88gHj4dzigZ+mWNkKwrp0I1MqplnuPzY utyOKvYxGAXfodGhRwagHj1QWbJyow4TA+9euSxNVB0jSXcOEwmRDBqCElNbJpE/JlVDX9lE J/SB3iS8psAyL5XhFWkv7Hsx5ZEdbqbIx/RSZja3F6tOTxnAN7a55VAza1KW+TDqlU6Q3lmf pHKSZ6+Gg4uXVCIsj7fJJ7k8AT3XDCu95WizDm77V+d0Y3Cgcq5jesD4NN1NfFmTLcr+1p97 t3asiL4chJfCMTEe1hyDZeydL/gN1lw6n/yLgEGBYfLCOWBoh+Y27BH6o0jcArWxo1SvxkcQ js7vPAz5zQ/m+74Svjo3UJI8bvOR/GqEbgUKbnmrykK0DTyS54ODnUihPp7yGHmdmxoR6UQM 9/Xfv5PY2HXVtvUm1bmjEuQcf1U2VF0jJ3tJxbtWVngSlXNJO5XVhPRmeO8RlQguXapbv8dk eowHVKyoGilCtpgbow9UsYUApuq8FZgSDRaQ730+3cnC1zaltZb18UfUyazIx5IzaqJeHvWv x+xynN+S/PwUNRM2Ix2n7K7L0l/vHXc71eab0YP2Bxua5IuWcIUBmwoeN5acCd9IPxvf8NPZ zMLRAI7uKfNcFBb3Q7cvP4iZuCmlwCg2j7wVut7B0w36G4QmU8YHg3vU3qlsojqwkt2ll7DJ JiU2tT3QsZeTKrHpY5GvHEKJ3iq3nPay/tFGyqZknWX6dS+rLHnKuP8uGOod1xTxVFJEi6id I3mFanXFnYWuEeoop43SeEbNXa/EoB9OiJUcWnugEeDG5CRpi8Ah1lCAIgkCa4KaBmKgtZyI oDAR9yAIWEFDl+fq8tyfV1hWiv1hXFGAhOpKJhOTFcX54yo0lPtxNkEdmgHGillsAlEfHl5d mUOKXtXGzc/N4qR2VWlSJhbgeTN5Iy60PXCyF7NhtEAa1pLXRrkyLZLiqzIiafODL/9QHEro qF9I/QCAStmpBkc94Mh5Yyvjk4QexNrKSJU1hamNilEJs7m2T9UaCW2fYuQW2g8/i2Wagoiv dDhy2j44OGOiBgfaSFUOmCQ3HbSW4PuX4B8wogaMaUBdzDoNeulw6bLACiMuCdW2FgVqHZwr c6tBhCtGUIm5V3fkbera4DGHNVBlsU0Mv5nWdIpSLkyKNMBEHDA1l9oJwdWJTdaTAykNIVBu 5FeEfZOJADKui5bzmwDXEI1sFD+Q9bcU7IoJMPEDcg6Onp+RL1l+gCpQQCIR+OUpNgohVJF6 dYvo2AqostImymfOIscyUWwqh/dykAL7bKK8IHGCFlDEgUGkrYfLXCr1/BocW3t4TBG2mu5q Aj54hGN2oXtHLfl+ApmOsGbziVslWbu14Gsvqy3R3JSmDXSaSaeZ9pRmytuI8v5VsBETo1GR C9rO338Upi1GorWzl2dbQ0KdEtlyiNYR5WLgtSuyDNkTbmMiKGUlwOblE1NI7OnnRvBqdDQT HXnTpZk5WiuAoz61ZhHIEzGtQpG7BaE71b4p3FITnTHJhZcGIMCnENvOxG6Ud9OUB6Ch1Uxo NaG6QXrvym0pgEtDdc9TNeiwBkTilVG+ZdfW8uIt1+i8F806egyemQyhavcMgUvidOhE58Ve wFESCGDsObU3OMz1BHQ+opI0m4yCkCgFtIIgSkhWGABuWFOMPlhdUPo5RSxo/aj1Y1l9DMJN GPTkVTEqG6ol0xzXOtOahwwBBuWxEYFHNZ01MjQyypBxFaeE2PEhKBaQR/398gLDfIavvqrh 2faYk4yd3/FFTEAuB8WjZCdRKkCIY9iRqQtjdd8PFVGit3EHOd0n7kTIll5haqYxP2AXrm/A Ikk/hblyZguO2jBpvdB8ze9BTSfEcic22bCymGvkMhENo7gS7iSGkCzAI6fOKFHmMZDhYFsL DMJEE5hkwdWGdZacT1ctFhado+9kCpdMuSstshNk0zxuPrZxi8Z5ajGjIgByMKlKLN4cuooL emyULWsJt3/rWjmAkjtXd8WYh9lo6szAkoU2Mkch1UAcbVG6lKhwbN0unG3bYAt+j68pR6Ox obFR1K+UWCftHZCI3ETgLlB5DJXhr8nPVfO/E7e/E5usx8AH949KCVaiQOrWdGQuCX9hOa7t zppP5F6Si6Csw2cXI67ylQeduOGd2GQ9MC65bwAN3A1wdqXAWc9eyg5LJOdcDoZcuSLrn9C2 lnbTd8YwTTGlKZzKXSlRJE30ROTwULEitZuCpVosXf9mNVs3OFG21glB1olNNkxaK7esBEB1 W2Iuk0CpstRasS7pcC9SKLdlkuPF8mbXk1VLUmspQ/tRDvmkDqiNhJ9aHOowU1GYqVXi8NfT T6xlIhFL1jKRKkX1OC+oDTl9ar8zy7SJaKmN2btLWlolE68i/9a65RPLtsL7tknHePFaQGoB Gd7bQgtIdPFSxDMlxFzZOqtIDtOO4MnP64gffUUrFYX+qK/wKpr0xzQq4hNKwTBEEaTKOlNf dxXsORjYodaeXI0/nT8ljqog9CMjRMERhhMY3EE1RXKEJj4MlwLjt7kDrhJ0xH28ugyoXlvP MKj7FFN59vFqTIlQyt3QgSblMHSssqMZtZWyw9dw+2D3RamlEkrSEQwdwSiKYCgkXcqNKYlA 1xrWLcl00owiCQ0RIwMISZJSVG7MifsSaHEwWnFBFJJIxCs71djQ2CjCxsJ1LLSMtpg2lfQ3 9HkgZvLi06e50V6pRoEWMYQXsqVl27rIUrMKV2leAgOqKkhbpDLEHZyUwLoVICQK53IcAowm WYpvukYk4QLdEURePAVv3e0CEKEms3sKpBNaUm8SEW9ipojZSR/jVOlczrzGKe1bhkYXG7pf aHYV9yG5DpiAHWtDe1ehrtvBXlPjIwhH53ceaIN38tptrXuocwPFJ/VHCYXq3NHoVyN0J2Jn a1HbjuT54GDnsWzn2qr1VGh+dwz39d+/j+HTKqbId5pgde6oBDkvfrS+KNlLG+qLlic2Rzto ktIObvtX59mJS2SFJC55uhtFHz8AW/iOFS1PJqQ3w3tPvO15uHTpckd0+zxa0O5x4o/xgDZI IZura7eYG6MPNNvbEaE6V6VEmJQXodYpTkbv0VEd7hKGbVNaa1kff0TJgF173MYwVesJ9a/H 7HKc35L8/BTdzDYjHafsrsvCRe+9ilJpcVXxRnFZneAsscbaMTznMTCFJDQhspoiTflKrpAf FIgtBkZ1ydfiTW6gP9nLAxj3eJ4752RhECU34xlmB2xJdSHEaIkCEQS7qXE05Ye0+UTYLAi5 cUNM/cgbOTENVPeuacNOUDmA7zbd93L7RuC5m1dZZxOrDAgIvkiGnMF7RyLI5CHHtHTjRoRo oo6HPGWI0RbCmHPHChYdpO1oGDioMHQ1BZUF907I79Jkd9wXj2yfIvMg2RBox7l2NeHXsBOs IjbKIxP7EW9SOVZZaBPlm9Tputdds/L/vBLxUqeSBuuSSM5ak0npERPgUHZRWkLmZfCPiEZB TfxExz7p/f6191RBWCechU5ssmEKZ4g7es6NObMFyoToNpIFGHs+6V0NhMd9Try2ifX3y3/9 wmD04b4ioK7Nvrpr5ym2/CFcTxxmDliLQUJMDRB0mln5Q/SSZPQlXMYW8XRxu3uypmEwpCNU DqGhrq2UEjvrWLblZvZio5ao5Lm7hJTzZejHdVAU6aEoh4rlJUpIAILImFBD6ngGhjDuIDTk KgejldT+6+jbgg5cI+WulIC4iX6RDujIYhSN7v2jm4aXfZlTV6bn2ZaB8bniQErkq/7ECtmT wJo51vQeVaGJcGYzlLQ7iVlD3PM52OlD3P8htkVET9wwdBdtldJxlDZr0D9dxXdNEZv9iY+G LmhCzC//cvWLslsNDg2OsjFmlLjKTb1rkQmzcnWhTz5QE2Ds90JBABjkHS8dgAXsDYSJWJVs hrI1PDQ8yuCB2IkiSluEDQwcocgPASGpdogVYYqRTNjvMMYHYEMusrJhDQ4NjjJwSPmq3JYW wWNJ7gd8DVx6a0G9sJyCQi5Dn3gEQwqx72LXQ9mvRodGRxk6JFMHRgPmBGqLIBJbV0EIrSDS NFEmsdDBLJDG+/7xfqyk1BN3GJxRLEl1weVFSD9gnguCtmQMZzx/TXN+pP3udWZgKEzUjkxX Ek5RNHyLxLUaBep9/NAjRigKlSYmfwY7yQxPZatauO1fuLUFGuLOQzV8e2lxEl2RjN2MVcXU dxcSHTJqmla+qDFVDZCaB0W1BSBx7F25Li1SHb2P570DqS16H9GyHycYYiRk9EcqBFLLS9xZ al+y1iD1aBBw2kpK25gl8ok1TQIbpjWdCp+qXVayrlACKtdWH2I9h6gcQonsqLsPoBWckaOn OjKhi/33UOz/QolMTJFwAV88MVgX2JK70L2DXmUvDvxofGdVWmet1WyjJ/eogMD0cMHupMly T7Wbyrq1CqtHhZEdYsFsDK2pJXyMT0jCD3JyApWdU7YFOZZ1SIJAg5/q3+ma2/q5edviayE7 5wSLnO9RYjHVKqpKatKBALrz98xFZboEQ6w15ugOQ57FFHeEE0WiFeyuERqjDfpCW4PaGtyD NXgBVSbu+MLDyCqVbq4T5kgnNtmwFrJdKmI76+t+fAqMTYS5V2WlTVTVmXIH9vvHDzQZjEqu ZQNCtiYbBCqGQIsCZhXJ1jJlvxoatbgjyhkUGFBNQEdSvFBlqU2Eh+OaKwItyemWzPGiwtM5 vxUr6i1ux2iBTzhFA7myXw2PWuDx8QPI9g9nhwhajb8ksmzVLYumANRF4n/fF2gATmojyW83 rcCIggDOvD7E+nOjyhk0VMa50yqrbKJ4o/ue6ZINDMz/9C1XO5TaodyDQ1kFNXUnBGHd75w9 XDs1xGj8bvDkL0//6+P52n7nKeGNDLqFrtdftY4R6ikg1x/EWlE5B22s1GKsKGfQUD2HXEaV ZTZR0VE4+p3MzCShdRmVzrCA0tfom/4St+kHAoRCpoZHMk5sL5GUkmQCJW125goa4eq2lkOI FEKsHWTZ9NKNbJorHtOrJlXXSV0VMEJQIboty4kkybQiE7T60OoDqfGiqbwx3bJyW0oUXRM1 CHL7BBNMFZ5ZYJeDshhrN0m7SdpNwgSxcAQ36UNroyBUHI7JCai3IoSXkghIyzCWApmsiSLP tPbT2q9E+0mjSrksLVJ+sAVjrhkesN9XwYZ/ufqqVeDjVIGdEGR6kyj3WM8MT5z8dHDpezHl kR1S1ebZ8fHF2TvoSPnt41whZzLx1LsK71EZlIxGHdtgY74WdyHNG8XPPYxeoBOkd65+ko9x lCkNeM2cY43D6LZMKi2O7ujB6GYCkMacYVh8UjtDcDvKdWu8laEejM79VBA3556NujIY/aUe jJ4qaiiqxlxAPRgdphkORtpm6wPSg9EbYkyFejA6Qov3nnjb21ZhUathoQejL2P71eYg5k58 v+C2D46NAuHSZTet+t5b7IdvqPe9FA6MBofPq0RW664lQzf9GfLmGM4cIXk+q7LkJmZCT6Nw 7vpqsUMnbncnNlkPhEtiDoyd3lg+SCf4TeRziz35fH729IBduvaUfaGmez9+SYFSJ45JbxIX 9VHErusB3IiGZI6HY3ZJE1XGPnr+DCKw0Ei63Mx4qFWQaQCjTQmSei5ZqVRXbtnyxHAXC5Cq XMKHENJIwyO2zLe94cvC4Ph+jMozJDMCjO6yN/jNs8uFgVa2WLpH58PBy3fHvWwKTEmTnSU7 F5LGzhDJfi9gJgZ436S66NS3uE3pt/mpE1hve/HnGQdr/QjTN1IWBWWBJFmj7gAqbVBvQzMp w6Wb7UHivjEHqbwRRvjaQmAkr2MFi4ARkQ51YCpXpxNasFHn1o5SbLS7uLY7s4TqpTSx4mZ0 wCachqajwPTq/X8wpNEMsEsZnLQxqm3+cvj6ePCVas/QeC9bjidCdFBNaxRA8J+50WoaByS8 EagvKRohHCGS74FxyVREZhMxUGInYHD7LbWjRlL6R1AC6DzwhA9VsCA+CmKXAscUjUVLAQ91 rbXE2M9V6DxQ9Q2i8yUn1w4t4QjYHv5NW+HRZ72lj/myMIriQQi9IBSCbKRewts5dW3bXZKD F0STPnraYp2S27Ap7NRafEVGJpfxvbc9YbscBIf0EhrlkIWhfH3/6HV/+OJ68Obk+MXJ0dFf Y9MW31LqjL8XdoklnLNyc8ItsXVzr24VedgJlZyNiJ6UNpl+Th/HVWJ45XuqxXQoXlUwOOet B9BueUDkZpaTp3KyYIUl7ujrPwiPfeEgHKl2L64/dkEe4EZyf1tmdS9+dokGgX8IrkjyDdc+ 4KEiuDrh+3Vik/WY9oiADpQLVYKOBmQNvyRqvspyk4xhJy5OJzZZDzpKxDJj6V0k8iw5AZIo AXeT+ZKeqRtJmJ7twkH8DhQ16tlDdydJGsRN10FSaetbGwrfk+o+NczJ8lC7OHROYxVO/x4X o90W7sqWaisGIHQkhikSRM26uX1kMzNKIulNjYkkUGao6Fxnayjhlckg5VdJqH118fL1qxc1 ZpDkoqBpm5dBQkCcEki5O7Dh4uxoTNmLlzNyhDWbT/JlUwUmp1xtE8u+EsSZgpRQLqisDbGH 6W9se4RVdpDuwmftIYgRTKgvc+EgjyAXHJu28TVnT4RFuWp8zbacG/C/MMkJPOWWjQw1itHw VWWHGgvNw0JeBWzoiCa4J6mKyBc57FQShbtpogoh8jCDY0hSPELpPk5qkx0X4y4mHvN8cStH Orr+kvtm/nFofDUPX02AT7tZmCUVJbdd5OoIDwkzZTiPM3m+QM5bHGB2EhSQSTOVNAWfn8Y2 dLr7s1hSZmp7am5Ed0qxVAoUS+22WEnccY0Mj4dzaXTB80M0wBGIPwINMhWONLhtx9jBCLUp qqjgILqRo1bAaAWiFUgRP2XekG8RPKjo44AqCGFccRttMQ4KNtZK5IBFoGu1AQbfuqVykHiG DxEeSxNMkQoaHhoeRfDIpRhahI6UutVDNSRKyxnahlZDfaTjkfr/cigMgYLbgYvsFoUA1NCt BocGRxE4qDpbkaItggf0XmxLpeEvor635DTjBDngOobvERb77sq2NT40Porw0WbfI3UlZAcG XI6VFZWgY21wPUlT9M7s6dr60gCpeYyYcgAlgrnu2pT2WlfUho+R3qbs0KPYVW/iuzfC6UmK fJqXCPUSh6/4DKSgLOQ30gcpqMbR6kOrj0L1gZ64jYmMJUiuNfGBbj5KcCxRsLmO4064gcSh kyTQHXQvoUuJOk8IBhTPit1zRUxpJGgkFCGhxUGqZILQ1HcXEhsUtGKBmFHrP3ngSZFzO+p5 JgK9uNbugWiNLeeBIRtYC8vmlEzSoqdmE/XT+ONV//qcXVwi+LQurIa1pByNWjmYrXB8flRf hWNxzub3y4uz46M3R1+3bQHKOmmu2tgAFT++fP3i7HRQX/FjvCjo4oYVP0YByc6kMil3Qwqr Qep2byb3HthUqqy0VvOt+CZT0ReCwei9VzagTTRtohWaaJHjCLutlx2W2IcQ3kkyAhIpk8Ca YK4HvBfp1QhuzMmzz0t1dFanknxQtU12eHQyeP5dXeQFCuHBushl6YAcalbSRy67atNND//g pjPqDm+52U2fpZD66VsOR8V1EknXcINKbSjARLW3ugAd5tFeWhdKdGI7KD6oZrutkpjdWhxl 57HlwUKpVTCSN46dmtZUUsaFyeBeokdbiWZ8rH06jY8KNYGk0hWjtolB1RIJRLV+pA5gjAQr XMSORooW0NcAQQQZWDByaKfmkOj6wMKL0+Hw7JiwIY2sJrO4Yolj/wwMmDOaq0eMqM+fVzUz By9Pjo/XtvXPddWWJ7vmPawWLumW8FlMu5QsI334TSjdZtv+5GRjzhBOrtIDmOYFJy+vbCVu rsadPE2I/vbtG/tT8oflP1Eec/W4Sruh/OIRQnmviHjZ3ge4rbG3UB69lX/+xyz8n89QoPq3 Pyd/0k/+8z/xgvykk1CqzlvYONlI0q5QK+4VStWZ7Rr3AL8bSgm+/vbt3bdn/578+du302/P UuD97dvFt2edxNGb9krURuDo+Ki9D/BHccTYn/89RU7u3z/9uYsoOq6c/2iRj7ZPbXRcOZfS vAeoUZQlqK/M4bzp7x4/xkjHXlHU7oBBSdA3p2E2PtW6SIkXHusgA2KNf0QMdSnIkKLpWxZF FKtb/fnTn7910qTTAYY/CKMOBhjS2JwM1W1+so7odQFR2XyRcPq/XSXlyrn81vF3RSCO2pHf +kGr7/8LAAAA///sfQ1v28iS7V9pOMBdJ89KbOdj5vquhbEd622AZEawfRFgk8CgpJZEhCK5 JGXFD/vj36nupqSi2JYy4xFJqw1MRlKUpJvdp77r1N5FNE18mYjf5WxPzE766Sn76FX7P2cn STe5GHvhSOIL/uB07+0hfdWbZuMoOd2TQeR54YA+GniZPN07Pjw6bh3+2jp+e3P07uTNm5PD w//eM3+P+l8nCrOU/oa07/v838On47MwXf20dGEBFoU/cecFp3vpXev6cg/rfaUWnP9fLzx/ R/98Jn5MgpM09vpYa5zIVCZ3cq8tHv6hvzbTf43aA/7ZJPUHV108gcPDztnx8cWbv3+TMmz9 +5o2WXIoRz9zKId1O5T219uL21e/mZ+vt++X31zevmLPH2cR0zOI81OgM7h486ZzcU4PYfVg 8g/fy6E3DbLVr3fpo7dnh2dHF+oU426i/oHr7D6ga6+uWDfw/PBG/sjmJ6AO4m+5zg+d9HFz T5pOjh7t5idoDqUJJ4hNQVTqzen7k+TLro+YeN3cy/MzspvJC5wLP4glpKsTwxceCcX5HbCu 9fT09B+j7F+isMA4iaLhZULrzO5jaKZR4k2uMy/JhU0FG2j3ozCU/UwONlnsJWwArZkqWKpF p3+87grx4sULEY/vU7/vBSLww+9sN7spiSoEQImd9ewZOxLoiDqi4ZkQsyj57oejTVZbRzjE XjbG44eRJWaJF8dyIGCye4I+Z3vaCVDsxCbrpPqKyGdXDr5nNJnIMLsiT1NpPugR5W6+qU6v tDv+aJpIcfTAWoF020rJq3j369uLsyPlVeS2BvMqLsy25VAmMuxLs9mCPXKW+F5Apptxj/X7 JXd38fzyv4gtiuwS5a3g0yX/aCt6oH0iPpO4geQUkOwZTAo/CsUwSkR8HDvpow9k1Sm90l5D gz2gnRCxm2/y4pfjo847QrGCYHOiEWXBNRMiKXhWZotK1BgfuCDJChHHxwr3WR2uzxJyB36U DA+EzIQXvNR6qCDRV0zONJZBYPfAqtxo+/JH7CNyudEWbIZolRuwuGsb7aemR/JHP4t6Mtlo Cw06ktdHB38xVFHlPWtTLqJodn7peiO57pwo/NKgY/rlG9uQU0lLNm6FF7C3iOfFuHRk2mtD fLcPqEG6NvDS7EqGA/hmA5Ib54n0vqswZ9b+EGYyCWXWYtj76ehVhfcza79PvGG2bv3KFGqQ NCxK/E/dj9fr9lhXgd9u3XTFVbe4JfX+LE78QJCOY7vbZeHi9r5JWrzBIYWVgGaV4tPix4ii yVxwkrcTdfsQimzsp2KoQ5gzKcbenRSeSCgQN/ORC/AEZciysZcJRF5lkuK11L/vca2wOa6e 0t3aykFZL9HH66vWuUBtlZA/fFRM4ZToo0sEMG5wTGGUTJDRNDkpFUZFTDUIohkdYxJNRzuY 1FkRD9UeIdPLP20ZbmXt7fPWWauDW7XJWm1G4FZWagPKhyEEmSrsEhB3A0kJBqQ2kWIgaUYZ f3H2jyD7V6tFlRedA/pY/R7bsZNwjxuvxfM0+S57xSU7gJrCQ2XKG5z0n8g+inf9dAJk9P2B JOVgNMkZlMc0QPYS2TmFlQze4NDvCw/aI+RVPw4eDh6qSpzlnLM2ZOkmKK6j4iA7+IDUhLda DiPOWueti9b71mWLFEYESCQ+Wc/aBuuI/Shk+3b4cPh4YvgYeolAj4MU0VBph6HnB7CryKB6 Dh+EfJGO0SDKopqrESoqc+BY7ifIK38eKRf+VGwrNOF8l9naPPZDsdkqPY8elg/9Ae1Ajga7 8YtyrJVytrfVlbOVe1AsgtDRXtLlQ9uBMs+Ly4qboSqm12/evX/3a4UVb2pRhJHKKt7MlZAj VGmkiNQMJASmCcixe+LMBmc2lJkNizpJdl0sPnIdreu0P5YTqYItIvcrZ34QmBilEpmqIJ2n Tx0gHCDKAEFRyrlH9nPRyp24UjuxyZpF928ovbaQ1EKLPApCp/4kRuOwr0PQqQxTCYGH4AEM RbQT4BthJEJZ6KxzZ+hkX5nsQ6dEU62AfhQlAz/0VMdHT2YzqVMvYuAPVcOLiqflQFGZ6RZc quCekMI27cCxfXAgxGPSBTqrpow2nWmbTNNsJXGACnuUFYBOJHeK3Qm6KFApqwzQnGcH2yrD VlCFDXJ05i20Yl8reCh2L2nJcPBcoMVNBYlMPIBFWvBtBw8Hj7XwKCrCBkEDGQSFAwS/LpYN AZ12Vmq+h0Im2MHIKwAjExDsZPhP9CMXFWCERC6BoDnKCtln1Ck0mJ6k5w/Qxqe6oVHIlwfJ 5B1MZMKAl6JYA7k3T0xD9k1lgTnd4XTHWt0BBp+BT74Xuy111CBtXn+4E97eTmyydjE7aTIQ VAUPfFCFQ6LiEwjbjVU9HGySzPuupDCMEq/fRzUcnF1UjTIYuePbfkSCHYBFjtk7xLdSLEC0 aepSNbhodIp4NSwP5ZkTThZB7hN2AjsBgZ3YZM3ENLtlNcV5JMR71WzQBPuqvPSHQB5EadqK hi2IrcwPp352T2GrdQewhh5lO5J24q+tHXuwd3k7q6QnSzya/h2e7cHCyGCP2AmZ7RsTaKJm Z1BTORPLBBnASXMj5CYsrjqxAoQ3AmpqfEX0b0gVIcekTGsxTcnSoFq5lvoSOxoHDwePfE5B IQa4sE3ZjbGAudJSubYKhIeqI1unxE1p/WIPokd8ZYQMjXmx77+UOxgbqZk92hBVsUJvXUcU WEzRJQxANZAeWHI7n6ssEYoRIgBkgQ6GeKcjnI6w6AivBaqcKPHZfakjNtrwD3ywAKtKG/gN paqCzKYltKgq6oIn5LDgsGDBwkDGqE0B30vtwWBRFNNYUTsoroe+nyL6soP2kQP49gG+CWCq Tj4gKHlDNeabrLVSX8gCbqDaU7YemXoDOfRDoqyiGruW0nO6ij4Bk1VC5REojgKlM/EwYvYc 27MDyPYB0hAviS4Suyt1tAQt+NDULOreq2p5oMSEl+EYLcrrs1m0NrZZixB+KP3RuBclDQjk W05Eh3DYfXKyx8keq/Wt6cnYfWmQ/FG1h9TMPpy7oAhX9iKwSZIupgAUNDgIAugdBXF0CSPb roNHJfAA16fmvjtQs3eWiUB/10elflv3JxojjIb0sLOzXNWqzd4/9jdZZaUGb/v49+dskQ4G lcCAnUFNr3O5S2NZbKW32mIUkYmdurDM4OopjvWqWW6uCYBGWOZzsX64QXDOC0E1nYvqeESg Bh0rYTrxM8W2i4CMSKOJqhudW4LsaJy+c/rO4hVlM7/Pw3d1BAeScxHl5tCcJb3+GBwGpnsL /lAHhrL84RHtx0FOZ2CY971edMc355DgkGBDQoH2oo44sNh8eQNjQTOo2MC5phU8y0MDIQh2 FR37+YEIELpPhJ+BFsfpi4qbGhsSwV+yPNiVaRBaLs04AoWInHXzJZJ3gM9EwrBCBG2ZMMob 6E5OL2A7dqrEqRKLKukhDDvzB83NdRliCIpBqklGi5onF1lwkQUv7fv+6d6fnScNwZkzEFns mWZ0hyCy8GHIVEKDlCAqO6JpL5AtTSqW+tnU1MX3+1OMIzMEinpSA6IK4aIllbhk2badJnSa 0KIJw6ixxY6odvcAEF0NFWAESQKD8R7T3hRzPkIOfRlnrPQD7SOKdRza3+HDuVOzPXD191Ou KAstVJCs7Ko0SIMM/QRElFp9BFFfaQ+E45QbBU+qBxKl+Sg4sidV6jsPZ7NNO/3h9IdFf2QR uykNgkdZbeC6vbi6wKJT8bD4tLgPprWTi6YDEwB1oU4MitkK/YLldBDobIZ/V7gpDZI9sLpF DHIRn+xX48mlcjShUdMDNWXahXFcGMeFcf5zdpK1dd/OOtU8SrxJHcu94HBG0wSpcQ/zx7UR rgxtKgSZ17KpBp4U7Qo0c7bHPQ5nfDvj22J8I+oPBTKBZ9evPTzm7duTCF6ptgBBpTeHAOI2 qIsUag4WqUdEd0C1t4Nxmp3Au9skciygwrzqJqoM9pfjo847CkepD99L5RqtFsh26aMl3yDW ojG+zu5hSM5O7rzgdK8bgCf+Rv7IzDTNxxWfs5MAczvzfyu9a11f0r+DA1U5IzpY8w/mu2Fb VHMnt7oiWnCaXUk09idy0PVG8jyR3nesGcZFuQv0mYiGvCSTIca2ZJBRCJtt4hStCQ9c6FOu 4hFk7csfMWryeBlRicf0IClglRsoP6m1HTh1PpI/+lnUk2sHWDXtSF4fHaw9FrLW7Y1RVd6z 9vHh0bGG++LXLyQ2/oqJVeWOLMj59Rvb0OYa2ewlF+9OWeFJjM9AbM0TSfi0JDi6Rn3OTnoJ /mB2H8vTvRiXLtetSsPGpDri/MGvmgdP2JqAqxMNL5PFw6mvYH/A3Gh/QIAvCWXGZ/iU6OEa C8j3iTdcWzTQNKW1kPX61afux2smHy1nZAs5VSnw262brrjqFrek3p+B7S0QpOPY7nZZ+ru9 b6JUjNeZK586a30caG19UYvHqbHKIGkROHareSkuoLaPp9ABcT1iaiePl0loY37zNMi8UEbT NLjfZMU2Ebmd9cJ1/wNEWTrb5gfE4Z+H2alyzETlpfiPw/9gm9lcKjwlZGzlTCwOicIAO4Oa QiBP6awNptQ1J0UkNJrrEl2bio7m90/XDA2UnYLJTXSq5bt18HjcIGaus6wxyeZoCM3DtgmQ K9UMFilEN5+K6l0BhivAeDyzyXLZmlFnRQwdiRfHQEVTUe0FaYRCq7souAPtGroAVGN1YTf9 aEIVWFfIb0llZsNy9gene2/fmUxa7vzojNZWbKU2tYCH/aKhvbxUSFHbQilE+PrNu/fvft1b zjqxdOGF2bUcIj8GDgez14LrcJb4XkAJShPp1O+XEn+Idhb+IrYo0m9qCRU8Qwv4UHc3kKpv BBdbWUGmdeSA3Qtn6ThLx1J/4zXXAyCzHn68KsTRlNE5CCABkSjWNpDpFpk7zOix4pLIgcOB wwIOXLAs8Wm231/KnG5Fy1o0RAnFZ67kVmyEXyq1EZKV9PTyQpcshOIya2EhqEXV0EJgdsDC wFk5+18rPHvyVYtqyHL2xWWqs3/37vK8U6F1qBZV5dm3nafvPP3H8/Tbxy95arWmQWzkRa4z KUl8FMTcSqnFUhh7J+y9ndgk/PH6uOJqMo9IJXpyB0jPTSZIS6T9sQRnKtlgdEnnnPoRinJT c3NBuup9LxS1utPbvkuyiQSpOnHtDe68MPuLdZxVeiOma1qBIYviKIhG96J3r0dBKe8dk210 F80wiSYqooWP4Ydx+9ABxAFE/C5n5LTgLphakawdR35zJx/uo5YjT909p1Q2vZGa7kdtTIyw vRE1W0cxikH8TC5Iih0+WFfR31c9ZImzNCMN9kTy2gsGINDETRGjQ4JpQLjo+KMpAr/HB2JG YxKFPxQzNGim6XTCI3hOgTgFUqZAiJV3E0uwrmUfOUs3kWGBYzgSRMdBBKs6GyKUVaWmr58r rhr5A8zc2TiJpiM+NNEBxAGkDCB0d5oKkA7UgjSls/Phs2gmmHgJcS6qIXcKCWa03XnrrIU/ Q6WGXsg27dDh0FGGjjkVBLstlvBpHXUIQwFpDT3k8bx10Xrfumx1EHL9gLiWiV2RXmE7dbhw uCjDRTrzs/4Yziu7LQ3CBchGvWDm3acC9eSI507gbyBuRQgx8SmFFLFvbCvf6QvnjyM5UdI+ DRk5j1fl/upznsBtEDBoVLBnGHop9eFnPhIfgMtA6lHIMJ3utTNu+jRmUfK9KAmc3nB6o0xv kDnSVJWxr9yH53oos9IUuXM+Mxx5KGDUQ+a0Mjk3MV+2YYcMh4wyZDwNT2PffynhUrAbb1F+ Vede5y7QT+nqnYDvTmyydsUmsLEmsj/2Qj+dgGrSw0AdNLb7gZfABkOHEIK/gR/ic3F0crRU esLA5o7OqZcy9fKF3ZISkbyGu2grRSbt62ly5991Zt83Wm2l8bb2t+a6eDeIcmTzwhydQ1YG rarj8fqgl6R5lmDv1K4dRczZiTgp46RMmZRBmS4FCRAxYNelRNws1e/WShGrWjVYsIAIlRuk Qk0hguqlCtBp6IMtXU33KgYK2X4dPBw8yuCBS8PuSYNwkcNAB/5FRJPtTEXbAvQ650rpVexU w8fLAcQ27gDiAFIGkH4UJQM/hIxl16VBOCG9oDGiINKT2UxiDip9TBaXDActVfqZmnEDuR+3 i1MFaqX4mxG0GkQTEOnXHhyufxFjFKxcyMaXzludGk1buZW4gLVE+wZidRhhiNGM6uiRrsT4 ConiYTggCKahkJhGtlA7FjKYIcwVrw/aiDBDngajFKBoFMUKQ5OzTJxlUmaZ5BVS7LI0yC7x EpTrkG+OcvoTtomduPE7sUlnT2007gB3YV6vAxq5P9FxXqsHnYAvDNkhFONQ2Y4fAOCmVocK dyYyG0fkj3sZRbPMcPrdEwC1OrLGsApj6J0/5OxaDdJ55HSzYk4243le3KaivZR89e7xdUXH 6PCxPNGtgt5LIISdgeXWVV1DMvCHiqGysS1mf5x9EsNpqFI2niKiH8i0n/g93X7ZjKwxNtGQ lDFG970cQd5cyQkSZeyGOwt1+44npAyCL3CK0AMzoNQeLKYDcYaKmwlCBHGUZFAfPM2/E8e0 E5usmUXIhEFN1V2zp54jT9kH7wwlXrRda+J/3Eb0BrrPmoxHw3ONP8FOx8GjElHNzqCmCMGt 2WSZlVauWaLpS2n8eXcfZScJM+iZHua0A7oPiGILy+4U27UDiAOIhYF57nWzC2NBc6UwcTlM l8N8xCF1FqnbjDgHTVsZ+0FjdRvUsqnmjHQ9GjF4DqJpL5Cih3q1mT8AWQh9SGbfwMs8Vcrm hm5U3fPdkDigul+112gWEYTQN936UJKlR7MocxwYVk8ExlE8gf9QvUa0UqLvYSgNvsg27Gw+ Z/NZbD7cJ3ZV6mjtWbCBUay5m6O0AkDQi6AqdJu3KjMqtM+4cOHTrHzbCfnmNomoMGoIr9g0 vSYWarqT3L2TvPjl+KjzjgYiqjtc57ri2UmAiUVY6Z0XnO6ld63ry2Xqb7q9xpzKd6MRaba4 PDiyMBTyIpomuR2CP2tGQxY+LWFxWrMi+u00u0L/BjzJQReU/ecY2PkddOXW6cifJRIMXoJR mUj7oqU2QOKXftbZQms6sSt8BFn78keMQXycm7zEnFNbsEXvqtyAxcxr8pH80c+inlxrYTft SF4fHaxFCjUR20uAqrxn7ePDo2MN98WvX0hsrLtqDzVGV7kjC3L++Y1taHOzw+wlF+9OWT2q surRIKXsPpanezEuXa5b23RYMemsOH/w1i6lp3hASGdGw8tk8XDqq2sfMDfaH4gDPpRZi2Gv RA/XWEC+T5BSXrf+pimthazXrz51P16v22NdBX67ddMVV93iltT7M5CsB4J0HNvdLgsXt/dN lIprfT3dW++L4i7NO5SOX75mGPtpKb+VDt02fNvucXeTldrcwq2s02LFFoY5imlKtYHX3U+X hR356CuenfiD0723/6RAizdFe1VyuieDyEMemT5CngBWF8nG1uGvreO3N8evTw7fnhwe/ree aLxseL1enXT8SOGMpStk2TP3rvB97O1n7MMGQ3lzWd3gTUKG5FeNRbP/htjZBpeNCLUUoKhL vy/jTMzAMYe8chINpn3Nl9yMbpObbkOaTYifKZ1isGCSIYUfwg2cYHiU4/KDuK66rKWgVVbc 0of9tq1oyjbmHftZRJpxk9XWUat7aIlOej5Y2jEOKpUjdf1RtOwJfBSmBAyYLf8VzSTYzGgs lBZQPg9vO2Wx/cKWTW6cPfC7HXygWAri1EeFCC+EshjotQSIQPrNH4iP113NEEAt0GDMmaZQ yESXM8Kw2hExXlIdjPoWojZDv8/OxwHEAaSMMqfRozcTDzohJdZ12K3ptNdSg9QG4NoAAzsN pzXDoshHhBI5M7pDA8jBo2L6AHYAFoFctf4w9lWB+NGy2DpqDx0kIXwQi8B8dAFIZmhY1BKL AH2FIuEUUMZX2eE45bF95dFB2lwStTtaIPoYpA2nsBmud3OIHlwV8NOsAq5ZUO3zGMyWAzn0 Q4pXe3Mpq+c4QBLn9MLUrqu5Y9X4Mt0Mpbm5nTh2xsrauZZZxK5Jg6wUWCL+iLjxlvrb57aK 9nrN79BE2EDZ+/B0yfD3eH2CM1W2b6pscuuqNuT7SZTykGGD4LFsm5PWgC/bUW2w6AqMp0kc pfJAzBAAStOo76tQkNg3Y4Ges9Nx8HDwKAsDUYREYFz4WIdSFmF4unrzQLweHaJoSvHZUuxF XUp20R5Gl7uG27+GH6BfB3pStBIWSPEO/RER0VIKJqBiRZIc+7kKDkfPdarF6ViXjJQzqpop 6cgBkudVUHOZ8BOSoFa+Ggk75ZWhg5heR8jLo9keZBPop1H0m8hVYjaBGp2kvglNfFNgk3Ky bfuybZMLV7UFKn9gZuMmC61jGDmVgQGA4RMjgwGlQRREjiX67RCeRPRCWQtoaFDt+Hn6nu3Z ocOho8wApcwduygPG5C1Uhs0Sy+3mhQINI1/j1pLhT+JA1XThXQkfXHmI36B9D0Y+jAHAB8W JkU5gDiAlAEEorWp+FgMf6IcfaoVSeqyLy774qV9f3UczMZ0AEvOh61+Xpx7VCelxDKslaUJ S15AVc7KBVac4opRS1n/C1l+IHyayMKA5wS0E9BlAhquYuqDq5BdlgZZMSglDPwJ7jsZ8eF0 AroCMuMXkSE1dVsxMwJQ+LaBCX2f7dkBxAGkDCDEzcYuSpPAocPdZNATPEwShoVU0Y3Wl5SF URZ+LBMw6k1UttIx07tejk3CpwU52iB4UG0hn1BkgkEqr5SbWVAbOWspQsVUoq4TEV7IxILT H05/lOmPCQqoJv7/48ZGg0DC7SqCDErXU0VPGko50EaVKThWWmZFYTpkOGSUIcNIUyZFGwQM k1JQvndLYDI4iOABAKSlF+2NQnr9MWKlA//OH0zhu6P8y0WQXARpCxGkGxj8ixCmqZlIx9GM Snfzlgl1eVVlDNVkgVBS+c4YTpWMCrR/Tog7IV4mxPObBMowKt3jwq1B0lyRSCg49KNpgB48 06qKhiOqZVebmzd6u9oiV1u0UW0Rejabat4AAHlllOpIRWxVooooJRMmRQERokikMPz+FNpC dX6IZSXDtu2Uh1MeZcpjRY42SGFQTMhQF+iGDsrLYdANMhHRPNoqUFPx8fqqda6KKOQPk6cg PeMA4nqj1tamDpNowi5KgwBC975TqNmGGZVXZ0OXYN5TnpYQ+/Rq6Cdppr7ANu3Uh1Mfpeoj 7+Zgt6VBEPGCCKm589YZAYXK7AgEqDSK8FLlIHILLMWXLlrvW5etznPuYu0ENnZik7UqDi2l ZtYf3t7eLn63+IYh0R3b9uX24mjMq1P1849R9q9X0MhfX5if1TeLL7pDrNg0XTlE88HX2/Pb V8/Mz9fbs+U3ndtXf/LcnuI0hlrx09qOc2VeU2HVVc5kab9gt8liVNm7kypd+2+WJ/7bJnuy NTJVuiN+Gpsr1h3AdpXnYq3ftlxAfMxP0uHqsMrzK0g5h6ulCaVVnovDlRIgTl/JoTcNstVB Yt0C0boZ6RlfZ/cBapn17M9ugMnyN/JHRjPK5h3/ySONwVgz1ZNkiXH/+KyEZuHq9onoq9vG mn7L4ZbfXvB9OIXVVIW1Gn9hkRl2Wzc/5c7Z8fHFG6rab9iYZhm2/n09F9MXqKIckRinaUjv Dmk/m0xDOnp38uZwMQ3pcYNv68U9GGX0wtt0eopf5mkoAXYZV8LU5s797Rr2oSty1Nwrglmq 7a+3F7evfjM/X2/fL7+5/NNxvScpDI6be9K5MNhcnD+lEWF1EBOvm3t5ICbWOsUPy+mtjK4p XyNSS5SA4mMBfzr0tZUNtE0VV3NnJ9AsHYozvngh4vF96vfRdoLRIt/Z7dhNGbSVG1QOARXP 0b88e8aOoqY4eCZAleBPMN9sk9XakiZVPnFVQaMeOSwrU1ZD49roc7annQDDTmxyxTmp8v4t QZ697Gj+2uMTccYasdydvFoN9F6xAbNNCGwAaMz33wnguU3i1FN/YK6rifE34bquj2vVLo0R eGl2RfStiRx0MXv4PJHed5XisfhIn4nTEs1KMjwQEmOKA/Qv0Q+TuCV2WBrLIKhpjcvljxj0 zpzkzbYFm3VWw1RUk4/kj34WgX9soy006EheHx2sRcrDU6WrvGft48OjYw33+a9fSGqsOyba UoNO6ejwG9vR5hrZKau/QOa5Rn3OTnoJrIAM7OKnezFuHeW4yEJUv8aUNIlzK8Fq/D7FAwIN YzS8TBYPp7669gFzo/0hpAkkMmsx7JXo4RoLyPdgNVtL8a+Op0HicC7rzQviqdjkjOq4xTZN t73qFrek3p8hSBcI0nFsd7ss/d3eN1EqJjKWK5/3Na60I31JxRx0sM0pqWN4xA7yJ80CWn9D 1UT+tKiwgKheMbjBUJUt6KDAaJ8T2qsO7WkqxdHJEeWJpJfkHMkg+WOb2BxYT+lyVRtCbsb0 7OtpcuffdWY8yVhiBj1oRmzlSbe/NWQi+Uc/7CZRBkYRBsK6PlSiVjfs0YtJBCLFdMb+mAio 0d7O9uGEyePWJy6JfWsGmh1AyUV62EnZDjz7UZQMfAx1LGofy3ptBvtWVmt50jOane4Jmg6N 4gvVwqCHjhGa5UCP3xMYrAZKUHYmDhQOFGVMJzkXeaNRwWbwweIcCNDjib6u9V4M5JvGhoW9 P478Pg/TOnw4fJThozCrokGqYiKzcTSIgmh0bxiAwMRbMm1PUQMtOXC7O46sGlfaoumF+K9o JjFTHDO3ln1t+NNMZhNFoBQTSdLOTyfzE84ip/8rJlthB2CRHPYagK2YmW3wgIUpplxtstY6 GsR0+WkuBFHK0gSVfOquqTBVJZkIRI0xWlR4cRzck8eIWRNsv075O+VfpvzZCB92YyxoriNC IugQ0YsyTYmZ44JzAubFy8Qwi0G8xciQw4fDRxk+dBiiqcDQ0ROixPQpJJSS6pA+FArSFJi5 QkzkGPdYjLWw3TpgOGCUAUPL0OZ2epk4Sa4sqK9FEfGHBWdjINN+4vcQcHFT2yuf6diMhF7D kk/pmNLc+cwWmEfzLAL8CZOEaikTC0FIN6DOTW/ZaHqLcVaZLdEgl8LModB84rnv8JLtZics o53YZM2iomdpOsXkU5o7jREoFP5R3biIbfuTOJATibrZgaDhWqEY+zLxElQJUKc6utcPYNj3 v8uM97a4U3RGfJkR3+QZQl6S+HewUPIhQSiWGcNeCbyeDESaAQXiy8cP33S2YOzhq3Mkqe/s niyvmZhjB2AxDarOHcTTdNxcH3eOjTwUSvQmGiB5ljSdIWUAbZJPade/uyIXnAJxCqRMgfjc zrCguI45A/kjVvVkonevFIMcoSGYBjReiX3/pXypPtS2lFYhXN+cMenl4OHgUQYPsknYRWkQ QLgphdDPl+7Z0f758//9ePkNA7eY9dUBRGB9feleHu131Dd2cdJWzeyrm9xx5Bo/jpTCh9hT Qwbno9NWbAN2cZ2EcxKuTMJloA9BNILdlSYJuRj9FsgBYQ8Bagi1L9lRmIBFPPOSAUVa1KRB 8h5VgCWaZiCrcbW1h672bO0MWlyapkKD5iyrZgvEHdO+DL3Ej6gRI0umGDa7GOAMQxm48RKE YkawoUckDmBUs2077eG0R6n2GDfXgVyuHHCJocGTpB+sxqJvH798/fKICVCLSVV1eBT6oYs6 sk2WWscYkEqrkSq7zqQkfcc2shNKayc2WQ2MrV0vZyI+js2McpXhzUexI3ebZEQ44Qm6jWKM HC+7kjUVA9ksEp8wLgwckV7Yl+IyzPyMW4CWlRup4G7h9u3D/5tE0xhHNRDdCEeXiv1Pl930 OUg+vf4YhcKw5/v4FFeQPF9cRxUfp0ySCZW7esjK6yGbIBxwkzZZZh3tgwFIYvtUOJ+TAPX8 +UcotyHzARbQtU8yj0BiynTYdp1o275oYwdg0TxVm86oj0TXUlo0Oi2rrSM6jJEyQ7cuCtEy 7zs0xuDOCzMwdSojJkRHFjpN0LabQJXAwE4z6l4csuNx+HD4KAsNeeyWNAgWynJvkT5ASBTx Ui+YefeqVtMLiO8UNCSoRaP2K9TcZzMJthvSHcqGhgF2wPbt0OHQUYYOVKiwe1JHfLRRQzNX cuqOK2iA6oHuO7LQUepnaG3Pjaw82bAEE7ZHh4XtY0FZtKTe0R40kEMwXKrCczrAJaI6Jczy CsJZlHyn4IX60BUSunahjdqFmpsHyqlqNDLyCB4hhCpqKF6yBBxPO427J9ec8N6+8O4gs6GC ebHnJ+SRkTSncJ7J1+f3UmlkWKqwU8HElJHRCt2c+r2AGxnuDLd/hkxSWKy8ykMZnIfLsso6 hjAQgfGHuv4bYjykYN8dMhdKauODzA+n9Ba1knNiJRLsNA+Bxgo4kiUau7IVFi9rMq0JAHkS JEvoiJ5TLOU2Plk3S36ACYgTpww7Fqc4nOIoi2IM/HQhZdmNaZAOgZG1bulrxjNtRYC2J+td rBoMGGgxPQxLNOcZoqCRjhxRmlq1ZLHH7mSMkzFlMqYn+9GE+zENEi4eWhBUMi1DpSyx4moi N/RfQfP2o2kA/WsGR3jLmliPjnAAccbp2haFQj62SeAAbRVibIhoRCqlkCcOJEhQ9PAXKt1Q RunuIcHpw+3rwxsS0ktXb0FZjs/RMoaAAtH04LpSOAGv89qixfiw3buoNSvOZQdgEYZVB9wW V+ynCRHxR/no2IcmNW/HMXHzzxBphEdz4qV9/y9MU4bEV5MeaXZhwygojQJneQqUA/w7HBQm wjuttn2t1gSJGEbJpDAOzCK765iGmPt1KRw7bdTyiQ85WxPqadQoC2qx1QTG7HAcOhw6ymIg JlzP7kqD4LFIK1DybWXMrm5K90cjFFwODihZZyju8W22ZQeP7cMDKVL0Dg2Mr3Pw06HyUnu1 avsb9XCqtJ3drhJA8Xh66VbqqI7MzM35qaGMU6HrQBDrA/aOkKOXRQnbvgPX9sHFDqDk/tVj JO1kgmD1JkutFAvtpekP8wyTSGWAohAVXVw43brPi3yWssliDggOCGVGGAz72oPAUmVDhaxq Ap3hFnd0J0+T7mQnRNdObLKWxkDgpdmVpJieHHTRJHoO7sDvr9r/SQHLzxI9I2C/kCEICEAn FnAZY9lPpRaDRVgK+rn8EaOtKRV/9LOohx7Y10cH4vjw6Fj95uKXL/QYxNHRN6YZduSGJgh5 owF6cNXdWo9Mj/7N7D6Wp3sxnvweLh8edqJ+jekixvmaqLD14s2bzsX5Xv6RXubFL8dHnXfz D99L5S2tfr1bKI2NtVUUX2f3mNM6O7nzgtO9bgDWlBv5I6OVzMP3SedxEgKzk8BDI5b5t9K7 1vVlvmNaDF0zs6hiUmhNwZp5BttfMu3ILkM+gIAmCWXWYmiyiA57DKHC3WXt95jxu3ZSMY8r FHBU5fIfEokLqafq5zc5I5t4r3KLbSr8v+ou7Wbx8gycgIGS82x3m8tzs7Fc4jwB4eL2volS MYn2Jpw76UuuPZogfxgesYP8SW/P9MjaN7xpmrIaerKEqYEHB8QipKRCTss+t5iieohHEDbH 1lO6X1spSrEqssJFKo3p202Lray9Xcx7WSwgm3bdyiItDzjNPHSdCtBu0cDR+5x3qzDHmkpD YuS/C4eBQm+ajXcFo1eqMwDK/cHp3rs3xryuAvX5Vh5YKw7CtlJyIs46h+cXv+4tW9vMibgw 25ZDONagIjObLTgRZyC5D8htGZ+FKaqM9HvjAGk3IH9++V/EFkVyXy2hioeoYvPsCTrZp8/s sXzFXK3DPbZAUxThVkvZZ3gq2V1pkPyj8VO6rUN3cFCKaTgEa1qP5hmaMrm8+5IsCDTsD8lW YBt24HDgKEtBLVKY7Lo0CB+DaIKIGVX8wGge+qMpQslqGMW6Da2JaG3F5mknEkYN0b9ttNo6 2meFhQ8watXYWG/JtvCm2ThCNFcGkYekP30EHwbRVop9tw5/bR2/uzn858nh65PDw//WFk2p OWE+fC8RIy01gArGzUU0TTAIWd15/Flj4hQ+7aene8sfMdsHO6E4bLsnMSrW17Ut+We0aR0v xSdkA/khlWsr01JFgv/Ctpf2V/oklq2+R9/0fLvTlVoebLEya4+nfnZCme3EJquJu1jNWYrH UOgliYLcz1woSKHtL5iTyEdCefThPWFCGJHc9b0Umb1C26Q7QGdylZlcpbWSDTK4KCYATY7G hJnqNgcPpArNwOxCoTUcD9XvGPWBoQWdGLMSHDIcMsqQ8dOti5UE7ZvVSMctp4fFzE7gcic2 WY1dpaaUHTNRb7lwVedDkC74nKDjHsbcJsuto9+txmunckT5DcQCU6hfiv6x7ezEXd+JTVYD aKuj9IFRwlIUepouDbxZsFzgd3I2InNXW+qu7t41rdkJsgOoqZRe+N6brLZSIY3JBmJOrox+ 1O9ocVS+EA04gKeUc+WroR6qzkPNA2H7coLMuUVlbtHQT9K1BaCVk7ZYdAXyMprhfmW0DRKb S8zjCLsR2fIiiEAgcpNvHJcyciAPpmmydhN6SS3ooGhZisomlPsopbA0/gn2VOpN9BQoBZXe FF2nbHqO0x6OzHEtOohiLlmbXq6r+lDzofblj76Mdc+1sq3UvAqjMfQwWkLIc9hgH0LRUTUA 4jWMLgcQB5C1AEnH0YxdFIs3VKl/8YD+QIfJxENhrFIgHBlARetM/MObxP8CLepVqyOohhYG mfHF2bad++HcjzL3w8hZEOey61JHlICxA8ag8ru1VWXBBcyu3LzSphWfTO+Q4JBQhoSF9V17 JDygL9aM3GRb2wkkbL7Jp9eMWbOo9KJxdvkVu5IrK6609ff2trC4n2yBqHbxi4e80TZsFnC1 m7hd2kXhOByyl9g0qjwlizpanBx79QpG2dcX5mf1DUOcO+JGHvHX2/PbV+wgLf6EvVKkyvvc /s38bLKFWorNr7dnt6+emZ+vt53CaThYNRJWQrzY5EbWFVRMCyy92WhTtYTZb+w4HKocqh43 tLKG0It49H5bAhJ76VD1FJjaCjXwVVpFP2flO11F/H68xbPK02s7XUX62cjn+pzLT6LqdiOx Xn8L8IlEpF44VD0BVK0GoVh46k8a+Z2z4+OLN0SJoMzi5nA7yrD17+s5Qe3FmOi1sAtFf/AL 7Wc9/cHbm6N3J28OF6wPW7WLcSVBWagXrmhvG0hgyGz5/A27iSvmhblwfwODBPdDHrofvzb3 fpA39fX24vZVHv37evt++c3lnw6iPUlJ8M/mnnSusuj/hJb1JOBP8QR/OdylEzSET03Qxlp9 KcVV7q/UQND/ctTcy/MQ5WGuaZf//7DW3QqTWLmXCCu1ERyN8fg+pUHohQdZWkxhi/NX+Jhp AuV3tvbNFcdTEjtVHsECj8+esaP46cTyVnbRfibAk6MqtzdZbR0vvSo4V48d9rBpY8oLbtme dgIMO7HJFY9yK1gp120LwBdf5R1AJ+La8GPQVU3dnbwibsnSGUZOC3EmUHgBD3edWu/k+b0A sUxwj75/QaOOJ1HoYzIuvY0ULzMRZcwi3a6z72VCev0xdec8B3Ez0Wrs3jWtmVRhB1BT6yGO 0tTHXIRN1lpH2wG8MGAxp0G6npgZJibFG4iP0GkkFgwyxK9JbdKYOMo26/Tt40bM8TxVEPwh 35cdQE2RYejxN1lqLYExhkowjUbglKWbT7oDrc03CgRXAuiQPj5PBCYlSqNU2HYdNBw0yvrX yrp+LSiuIzQ03SzuPBgNhsQ0S0gBDiSR/3uiMBGIcELocaGZrc1SbfacmAbTyGDkBTg+yJgK AjKU5jNizHgY3gxtdEmZonSaw2mOMs2hRC+zMRqkN3Jram5M6cGJwksS/478cq1H1iZKajEw JpT+aNxT8YR15/HgTOAqA3f7iQy8laE3TvY42VMme7Jo3UWvK3kVmZ/G5n5OET4o3jMyWWGu xpEfZmqGIdPX+UQFtmMHDAeMMmDkVp8csOvSIM2MUTuYbwyUQJ+N/NBTxuuB+J+pn5Hj9l1i vo5irKLvrNtkk9Wzg7iDeBnEKW/pJniYyDSBhK6JA8v2wdKJgiCakbNEohh1WaNEIgOFGJtO aorA62HyY5qpobTjJJqOxtrSmU9NY/LbneH2z5AdgMVKsPeFbcVhbOvhaE3gGrQUAOxTvtLT Rj0FqBGslskij0OxBngC4lwRFcoffrb4PXY+OwEQt0moNmTxrrrLMfomVqBvfpKmxbkJm+RN Teld6/qSmt6w19q2iwVeml3JcICs2KDrjeR5Ir3vWLM1q/9ZQql7SSZDTDWlBAKCFPTDhFGJ sljjbVXayH75I0Y6hBdS2bZgS3RWuQGLamnykfzRz6Ke5DOln8CRvD46WIsUik7azaoq71mb ZrBruM9//UJSY91NeyjgWuWGLMA5Ov7GduSU1ZLRUeF59RJYAdl9LE/3Yty6XLf+jIdvVv+k rImVrqf66toHzI32B/J8Qpm1GPZKhH6NBeT7xBuuHb31YJ61QnjZy3Hm0l69+NT9eL3JGdXR VGq3brriqss3ZN6dob8qEKTj2O52Wfq7vUP+5MpiJ5phail/GB5/WiNsJxLprZX7D1nBW1mj xdyl+OLl8xP2kDcHvll5DpI6kxJhUywQsxObxJ7zs2FRw7+B1Cd/vtbgERTtkakmHXiZJ2Jk fyiIRIV1aF7QsW5MoFKzypczRF8+Hv2f629i338peXrTHeH280JkLjFhUVOJnEXxJsu0malV imR994dJNFH5UyrRpkFVvSjLokkrGrZ04tQPB2DBQLfoc7bRnQDFTmyyZsL7GMIbEzMppR9G yQT1V30P7cn77PahEzqaTJDHvCKaPxXJhAIirr9fjg0HYAUKqR1Gory0gK8X0sC2WrL/D399 d3hxsbesPK+z+4DYDO+8gHrC9dblEBmVsK9iVDjEDirXUnzHS/u+f7p3lvheQHRH47Mwnb9f ShUt1pT/RWxRpGjVEvDpUmhuKxKrjb5zWIzQ0shcz7xkoBPSRpWT5ma3wcHUKejER/Pp73KW B2z1E8naSsux22KxJOqoorUG/tI9O9rvPP/fj9eXcwMVcsaLlZA0anzRkY4Kbl6d7uDh4GGD R+8v5dW2ogwsEQWvT/O3PfBN4L4rJCjuJ6mKAPXM1XiaUsEfyrZVIaBhbWDCwGHDYcOGjadA habcO21KASX0ovN8B6MbDubbh/lrOHKfxzJcuETEieCHLalIdtZZ+FpoO2F9WKWS1VlLdggW 89leTbSV9beVqbzJQuto58PCP94/L1j4xgMmI0bq+fHOjKkgFmExPxuEDNmPwgFIUJuKDmXX lxgyMPKHKOdRrnCctwFpjERDtlmn/rev/huTwRk31gVG9xuufyDv0OWG9M1zlfaEjTXzQbnT g1+ceGE68bMM+sMLIt0o54DhLCqESaFJHyaTbc8JmtiNsZh/dbSqlN6YgpiN0HHVulwkE8Bp m3vDK3UAbLdOcVSjOL6wU7Dcuapdju7lcTEruVImXXk9VnueOHBhn4HjGte54YtoOg96QhGY DHHh04fVg9UtepOHfVRTfmnxVUexiisrJY50FkvJamW7HzDoOwFcjQBmh1BT+Qth2wfhwyZL raN5Qvigoit961Xtlal2UDkrU+xgcluh/JEZgi62X4cPh4+5KGfFPVnb8PE3Nu5DkU9Fhann UujIjq/mVQiFB8NjR2kFIuaa+Sl35R04HDis4EiiDOzEDeCpazvD3RnupqizYKL/GcO9ffzy 9cvXzIioqX1HjoQZw7LJcuto44URpmHATiVRUySQ2gnttBObrFkF/YdJHEgqjgeftSbDW9zA nFdcXUydOcj5fTG6ZeIHHiYbufLRw4pzBJvIu6rDn/BfN1lmHcXyYpLXQKb9xO8hQebrnpM4 kXd+NE1FOu21kAIhCKm8mhQDH4VLquOC7duJuO17GewAamq+NHo+BbLHBhAUmaX2GzTOehhr NE3lAHjooN+gYNwo5nh2MA4ZDhllPTlPobB6bjWhuGroj6bgNkTJRTaTKHilyC6NU0XWeQ4c BwxnUq0tucBdCpsRlLKk//JsBbm9SmUgNNsjNs/cCQZK9lMpdUQ3x4vqT3AAcQBZC5AGz8PT JUiZoaGndx0yscxc+DfoeCb2BVId88IrjZJc0ziAOICsBcjCGmHXxeIi1dE3z5UCkADah9Sb EA8E3PQDMcJ8KgzGwxwHAxQ1wJ7UCdur8zqc11HmdczFKrstDUKGqpFaVhkuMfg0E4NOgm1f gul+rsKvt7e3i0+Kb5gYcUdWjyN7BcP66wvzs/rmT57ZU2T0rhVj4wJli1fsrFZSrFVyyLa/ 3p7fviqsr7T0356jq3T9v5mfTbZg8xEq3cDX27PbV8/Mz9fbTuE0NpfGO4DsKg/KEiZcgJy/ erHJhawrpvhWFu822lQtUfaMHYcD1RINogMV+ob+YlHimlFmYHhu/7aAEX/lQCWH3jTIVucF dOmjJc4VNZ4WUQ5GIdoNPD+8QU+JIUt9XON9zcGSIDH/IOfzcKByoCrpOlxznUhOOE31BEB1 u5FQr7/5d8vMpp8MMFcpA9ss3PXCgar5oFoNgbHgGLupmxv4xrzItXeT5rHUKpD0U+4xO6uV bSxZfGr+DL5QIIR/jN6hr7cXt6/y6NHX2/fLby7/dBCmwddpNzGzlcv2E+CATGvEtJh4fJ9i mEpQgHJp6NgWEary2Qd++J2t3V3/x/Wc8TyN9F4/KPMZt88sdqbdXN7KRWo/Eyj99CdNp59U 0ScovkJx3u6BwSG+OsQvhUDzstET8TuK41pLDZ6qX8fdyydJ9bUT4Nt8kyZW0gQ3dE0Mk/Zc t5D4A3PUy03zz9To4SWZDA8ETdwM0CdIP0wYlZgp9R0ln7Uvf8R+ItONtmCz2KsM6ZWfVKOP 5I9+FvVk8tSO5PXRwdpjITZRu0Ff5T1r00h7Dff5r1+63oiX5peA/yGC1Co3ZAHO0etv7OI5 ZVWPoogelTNm97E83Ytx6/IpgG06rJjGWMa5lbCaMb/SM6ufojWxElmqr659wNxofwgx5yGU WYthzyJNaiog3yeYVrFu/ep4GmRHzGW9efGp+/F63R7rKvHbrZuuuOoWt6TenyGGFQjScWx3 uyxc3N43USoNTm2tpBhraI6tOJdVdDW0b9C0vRSBW7BL6dbtWZR8z8nVgnvREj0MNB8IULMd nRyBuTaUHvdmNofWU7peW8lHWMz6lXu0Yjg97HptZe3txR1jWshiB9nMiK2s1fKc1871WGOf bmXt7etpcuffdWY811nymB8017az1m+g3Ur80QjEdCAguhd/nH0Sw2moeOtSkjG9KBsrIgl0 0BfpM5yg2X4yZxPo2l2Y7VyqWcNpd4lFZeBlntBDFAgHhploTgKguVVAakffRdwaQd5UfLrs suNx+HD4KKOS2JcvR5x8oUQ5POTnbgXGFh2shqGd5fSOmrvuuYj0XAXFMUFERD1M7pnDxoFi uaPm76uvtJ3YX0wMbOW2tUE9lPnhVJFOswvTIGwYFNBYHqMa5FwzCIV6oeBzWYAP26/TGk5r lGmNwlDiBsGCbCTSDFzn7cQ934lNroT6tqMxaBLJGyY6LZio2h96ApNIMFqOQo3fFctkgbmb HcFOXPid2GQ1qLbasB80MXY+RQGeN9L1cM2HIg83IIgOzkfketU0hms9fEGQlDh2oauk0Ndf gRfy/9m71t62cSz6V4hssZhO45nm0c4guzE2TTNAgW1rJMUW2KIL0BYTE5UljSTHzfz6PZei FNMRLbdoLMpiPnTiNOiI4j33fc9dvpEjRfePhQBgeObQLFgzX6ybUbTP5DDcZ6tZVRHpn6Zx DITGBThqbWfzrLFRwtXkClKOqYxTyQIxkSBBX0wFsJAybJwHUEpIgMa2ssd6kYZxMd48+Qiy LoK85jLEpglDViwgdrD6By8aPgAPAklLlZT9aExsOVEPjIS8mY6B6uim6dW3XxG0+F/gxaQ3 jqxWIGgbIa30EUxxCPmN6wZhUguOVZNUkbVrOwae8CiKO2uXU8EDieabKvqQPBfVwh5yYBEa a/XKYJK5Ip037sUbZW+Uu2yU/R5puZt08Y6FmG9yVq6sYUmcZXIcYhlUzKrVJAy8gykvGjDw cx0UFY1KZVjkNa+vODcuu1ltZ+tOKFTsztT+BjXmpam8VdttMDdbIaXa30yuulp2o3eqeXR4 dDSiI5vGi8iQlA7h437NzQukDc6ncZwRPAgIqkUJdgObaFUWjX5WVRCU5fEBrQ9oMe5ZQyWL GE6H9/kQ8BC3zXPkrWeahypTFqHj6DYObwVZhwyp5ZSTXyWu4THBZqBjbxLPw4ChggZaaN2e ZKDfx68+fq2LX7X/LQJDWjpkKxBMXF/LCXyqnGVTrh0lvTuwLLlgEiLhmISAYaGJCOOsHhke GXXICED9UgzSGOLiIjR8cmdHkzteN21fN9VSADBGCwCf6S/1ofo9/I2hIfyluXJpnv9cRzwk kvpSSiacgvZmK62+lqJ0BaCVb9R+vXuacb/rbXB1UVIa0SV26jINzfigVtEmqcTwybMdWTli 4OfZyhtHCBRfX6T3DFnrUhqt3sfPT4xH39yM7iJ31wqVSZsX843q28PKLTXnYWW3mB5WaAVs c5Wjt1Yur0/qIG918+YMw1tisFb/MuP6Ksh/5jXnTmjOx8kCeKdTnu5971axBsUCMt9vdDrV ajIjfLDk6e2N1G36AsMy3bHJEWzDHa0e4Ietg/vj7PDw/HivTFN10DyqnNv5lEc3aE05kcHp 3m9HdB4+z6cxBjlFGHOU7OlHoKkCZzUxyw6e/z44fPHh4OXJ8fHJ8+f/3SPa6kcaRkBkjX+5 eEKVTlL/H2taqU25+kY1oGz7CoZWImktX4/wei1Kbelll+KgxNtxcaDFyk+Kr5UXWptRsutV F174iw7gT71wJcBmHsxiyGxWwIXX/bIrr7tGvjdPO+6kpfqtA1dXWqrNr0qXuaB/1cIKl50K HGq9OXYB4L93QEq+OYhYMXNpKS2tV0r9gtsfkaUsgWWXC7/g1gGamTI95xfcbkfo1UBF+dIZ M7fcElXY3w7U0IWhHftped1olnmyUXhgj8e2corhE3a/LNkQnW8MZ7bytJYsg5L+w2LkiGoE 9yfCdzczcJX1FBke/m13OOoN0C9O2JWWxL/zWfIPtQ+6nKkGzY6ST3N/aS/urheHRKDYQogy POwMa+tZxMO7TJry3yH7A3LM5DBZgrNhSHsh4704ZDtAtjg9jCnY/FUOXFfsnRm4w7JJKscF QSsNXvNxjJHUbD7GYhVidUMvESZUuTl37q9w+86CoSgsGq/tCCGJZZRv8qC2SkeboYFeKHQd h2G8IKjEwEB6qzg7MvZTteOPF8wdC4nh03eK9yPz/ASenwB+WwM/Ac+y+azDU9kx6PXUTPYs Bk00mGuw7/Ll0xMD772wDP6QuuhmlFHKwKVLlTh/k/27Sd/l+ZhdniHP8ksRgc5GBCN+I16B qPXLr9SaZen//Cjga/E0FyCQFiC+CUEPRV+GWanxdxuIpNvscBtefE3ANNGYpFjLLd3mASxx ZJev5P0kj8fN5FBdu5Kjg/1GpKwnm25TzobUJlvAvfrzE2mNJklzdeDVApyD48/GiTZ3O7yx ekxjNaZsO20tOt1LIHXlRH4xj082KymdWtrVc358/Mf5K2qTUh1nhfO7ixf0oBvYXVu7xt0Y vsHiqTQS+cDAXo0r4bCCfA0qtMaMWteMVqXr9TdvR/++2uSObFnDVk3Y4MOIXY5Wj6Q+n2F1 UMjIxhmn67P292ffxKjoNHhpabqUUXlQ+GoTnBZ3rDm4XG8RtlKlGMaMvZvPNohZ1jnDW3lU y2tGrbugdqYlRZFAjRElFqSQq70BARsowmdDO9bY5wb3YytnHGa5oEzFRs9qM1RbeVLLbdBV GA+/uSrWj70T6qjNK1BOgXEHNcLuguq559jd5GldlPafllebHjxlp+z9T4fv/nf4lH3KF3Gh l67TeMYEnxCH8A3SdWa+zsNj+z0OAAjW2pGZUNcCWmds2lS7rcHyTN0pRAX9eV8ZjUXKkwQf WVWY9xrOjVmPTXRG250qAt0bzdlgVz0rvtK4tazs1GZttBCr7i21a/tIa7+nxsV4/daKfvtk XIKj9r9bmzRYnGB5Ro4lj7RoulzUXC1uRst8ubQZhkW7NsYteCi0AgXjDhxFApaxbPKYLrrA yxtQM1qBqhypckUZQ0yunCzVs/m95akOR4Ye9NsH/SZQatsz3IW02/uztxhnxKZO6t8vga7g XyTcKJeltuoUYfFTFVEZl+PRsX10IPpV+dIqsj1lR/27FC9525c8Q8oc9cSgl1+BYm8hg5Vl X5bnddElS8WfczQG0ph5pmsfhPhBkcIqtfIJo9WY2AU4rj2vB8j2AQLV3AWM8MZWEVczWioU oYjFTO6esCCe01rMCgrkztDvZTSAgnbh1OwV9ODw4JAoGrwTi7Kbr3gh+XAs8oUQ5iBrh2yH rlGpzbCVh6h8etoVqw+n6Uzu1yfTLxiaywPEA8QCEMiRISodAodQ9dtfjMfvhaT34pAPesra beIwpMwCEgeyWFeJmEgebvK0LsZK1Vb0goWiSFyp/MhqtBSCcT2a3DH0myHxZZzXw8NbO4u1 C0Re1MgNgbHA2UWAQNyv+TzMqZ8ykIQSNr4rW5nY24sR+zSnRAI7C3k6G6QiidMcn43zeoB4 gFgAMonnYWcdwjjJ5Uz+JRjYjFJW4OD8fPAfFkfhne4gM5LtJ2WdxMPjebvuVUdybQ8i6w6Z jto+mbJJpmz+heVA94NKtpXdAx4bHhsLGoBtYDoqm0wMeXERH0OQTXyomsKUvI/RdVy0ylBe zWyiWTwwid5/8v6TxX+S0QTcJ5mZfnURBJaBIeq3n8SzJBRfZa6i6wAJhYAiisVUYmqiNBQI PBIO0KC7cp4Jz4XXNhdeRxwobs7bdAgZCxGGjGf77FbGSD4RIgqwNDINODHJmMbzXATR6sBT zQWsJRZoM0pA7oPeuNZANFkKnoRrOfEVgODSSlXS4WZdxyoAr2DWA6QSIIQSDZaak3xf5xnK Ph6oCJNfeXko58Dwjb0buX030riAGuVHrTJtl3EeBhyWB3UxQY1Rf1LSqYAXiZa3AJBZchkr EnIWzPGLMZPoicsk/E05gb/p3ci23cgu4EPcdrehB5uj5zeYPc/ZjFPd5jYOwbxPiEEURcVM HhRlHR4CQ1k8TycCPOTyF9FDL8cxB6AD2KiP6qnm8bQ7pCuzOJIY7FwpWtbYQGcjFcJzbXBS cwhXm3PZm5xl0FYh9RkyNTBI7u88h7ZCDy6OaODBO7Pema1rwI12gs1KG+oAFhuSj/BvyadV JXPCCMiv5xNgZHznkdFyycy4AIvSbTvMEyGaFSKVSdzkcV0M9orOvKLFHuUAmWLk/Lpg89Fz Gmp1CFzbgPIi2B2CtKknXXKAsWcTiWsbIJ1vTVeQ6GHc1gtfsBeHbCcCHx6hQ2N0+Ha05GYZ CqsX774Xh2xHwOrTJCihNxJ1OVHL/TC6FH82FtLbz44MPyMmUsPvenBX0Y8shU6qJRGfb2VQ 1XWppX2VgMlDwScX6pIL8witSSg10RxEd4eeVG5tkMeDGQY7pPqkeqsINGjbQLlAVdQQOsEs XuI//bOFjpkJ4wIcTS/kcRKH8Y1s3kjmaga6NAzYvSt4cMcStF3BMsxUJSObJ3q0CXur0ZcY 8Bzkj+hIzHoYcDkGjzOsu58lyAONKF+KrA/teqGVKcr+q/YGtRJgylM+wboejOxQ1pRxzYFj wMvbfm/762x/XSbRoopdTJ0S5TnNGhQ2H2Q3BZsBJU8zmk9ABfF+KXk2Hw+yws0x3X4PDg+O OnAsZNhZDoAEBQJwpbGZQLNMACc4pqYYqhooP3gpfNQNwWRVCjY1bzh83a1xTq1WkXbIchRS j24x+Fc99HW9yXs0k4e8u9mhbkFF24VB+Ecf9SIYQ+NbHtdF94+GrMsgyThDL8S7F4d0LCj/ OBUY2UxjRYCD4TVkSyhIVyF5lTzRwyyUb1zUIcxf3KMpX2tNylAPFhXXtkbm6WQqSbLmK9Ss ludtVSUP91UgAUYxOdFrZKjohK4+TKJI8CZRyEEQCEQ2SSVIZeLIuASPAo+Cuqj7RnZhMgXi j148km/dos6m+DwGS26h8ykXyydfMOmoYRAh545xlEWcfvHFJxq0bXMIuhuc5FSIMVSmi3bA YnHVhC+yrzwdZNSXoLNMBXUgwFHw71HulrJsRMQHMoBimnHcw5mIXhhDf0hEM0DD5Uj1Luv1 7l3YDb04CTmR15zc8vB0L7sdXF0sc8TTxWpnpjyNccThP3HwH+vtNDwR/XWWXwqMTmOgZMRv xCuUv7/8Sk+S16usj7SjnKcgxN1nAusRQiRI6KtJAzc0s+lbbuMV5MOLrwk6e8xqV40RWdvk 1uYB6m+q01fyfpLH4+b9uV27kqOD/cZroRYZe4zdppwND58fHBZwr/78RFqjCfzrun7aPJAF OAcvvnddpT5Mqd5fC+XAPSTMGa249touJFf5Hcrz2oCMQi6jD+JrTkZk26bBRWM1TvFq8rtE nO4lkLrStg5J/BJ6RUn54h++8R32JpBoja8v0vuX466tXeNuDN9EaM+KRN7IceawgnwNlrDG FVldM1qVrtffUIddVzX+kFoDL0erR1Kfz5JUhoxsnHG6PisXf/ZNjMou8d456I41B5frLcJW UqhDJLijjNrERWd3GlD3G7KMOgmpm0TVjEgfG9031327hP+tgMUSdzHiASLCkxibxWkpJwSy 2rNBRaREpDSUwaNJlSpf6NYBtHBOpjyS2ew7jbe/xNO9c3DAlWTjCKXWk/BbL9G4gJo8mgva GrsozDq75Tl/XPPA/wEAAP//7H39c9NItva/0pUf5uXDhiQwDJO5cU3iJLvchcWVsJO5C9yU bLdjFbKkleSY3OKPf5/T3ZLVshQLGKxW3K5asJ0M261znvP9ceTH7uFOP5hHLo/YP/lihy0O RrH+1dPefz1dHESDqPdfi4OEfZ55B3HojPjhThjxmEc3fKfHnDD0XD5mScDC/VnIXl8MYja8 Zfxz6AVu4vrXLJly/DgMvOD6lgUTFuFL+pcT+e+LP0P6/whxiCh2x+eHO7u7/efPz/rHdC7x 1SCiL38+2j3a62dfnvCJM/eS1V8f5H5Z/MvyEuFFcutx/JM3jne4M/Ac13/HPyc7uGl20egs 8JMYv+PEI3f1IU2/9tHhoqH8f49K7/ID/6+rqcaYRgAcMQqCyWlER0xuQ5D4OnJmF4kTpQ+n gbP3fJ4sguhTXOesp/5YkbGJkz7Rjkgkv/f8vBWXhFRogJ0qRC1j76ZuzNwZwHoDkTvjo6nj u/GswxZTdzRlC85GjucVsT0KZjPuJ+eOf80FpHEld3y488uvDSLmnDTD2zBxZ+7/4S5vIMbd kRMnGpCgk3JnB8SrTk7ifnf32cnLvZ28PNXEfV/9U3zCI+6PuLp8QdwfRa7jkYJRgl5+1lRh eqb0H9IOBVhAX1pwKJVXeLoFi+OrleldGu0ygi1CXPXg/O2bbvrpYYcN+dS54TGbzYERMkZi Z8aZE7OR58QxuM5jC/XfbqEcN07EAZ0MYi7wORu7EwVW1mWRA9pFIKDjs1HgT9xrWK/KvIRE TPgocQOfDFBNhlgobh6KGgEMNS6HMC459+sctVHbssIYIDnGoRD9YAzRBq/KYRPH9aBKPdf/ xB6IP5eweMiCCIJw9coWHhYeIgCgmThJD/zVVmjMwziJuDNjDvAxDha++khQ0ZAivngg/swh paPd2+LD4uOe4WPVgczsKagShy2xkIX02CQKZmQ7W2ykMci8n7lBL0cjgKGmVSqA65zVRNvq wcJNpgwx7hA+BUW2ydgi62oe8YfC4hKqhUIt/Bq/Fisr7MEkiLQ7W+Vhlcc9Ux4hUgLuaO45 EXnaD/P2VaojUqhsYTDFAn7zgD+nOKyMBAXsjKJCnL3oMDehKFIYIMI3RM4PUtwdIwruTm6F OFdGDh9bgd2wRfNAo4ChJg3lIYtp64qjNmrR9B6SWGYPjrrH3ff9j933Jx+7p933Zx8fCpOF gqoZJIbO6NM81J6+lV+bl1+t4P+lT6jxi4kQKA+YPixmRXEj8yoegF3damrPA1bZ6SWjCEG0 cOEkDTmbx7JGiBJtQv+OncTRWMmKns2LHo0AFazWdBEQaak652xU7ZbLHOZEwRwxaAofpAaq wgdzrlF8FicqbUM2K3KXImlz3O0/kWDSrm3xYfFRFktYClyNXSrQbCJKyGCFq+Z4cUDRZ1VF CtQ4woVLc/1QICIuJ0Nu2mUtNiw2SrERuKjl1VilRbh4AP6X6f2zDjvpsJ+cWfgb6z9EtmaG omuq6XMiRDNkfHoYBZ+4z5Sjyqx9lS8Yt8maZaV/IdEfoqzKeIT0dK9oK+T9VlzSsOpDVu/1 RQOMJdTmrY96dGKWUFnPVEMqsCah/mDslS9y6RZaDedjyih2dXVV+Prqj+I3DL9kiWce8Z6+ vjj/oFFPfPNIe4mvLPUMo95PXvLb779/uDq7evp7/vXh6qjwDX7p+OqpJaBhBCTY/c4eaeir +PDIEs8Sz/azf9sUgnJM1ULen3ixM1nc+Y0Q7P+yv3f2gppGxagCk6cSLA48tAHjpGICQnzT vTilPli4sGLOA7myyplLb6MNXjDIidBotRJGUCT5Aedd8wQrO1R//84ChCZv1PsGDXZ3oL1+ zGQLwNUkaSsy1xUCVXfwKkhcXTHQ5EVXeLjWXarypY3eZMUZh+v9reajhdd3zPj5Vl1Qjq5V t3z1m0ff46hbWhtD6w9XpwV3vV3CNB+N+L1gipVWVhopSD9cnazGUfoFwtQ3Vc6O9vf7z9vs Bwg3oI8JG9c0JY2GBL3cpfs482QaIKHOvcBBVzV9hQIDjAnb393b7+6+7O7//G7vxcHz5we7 u//WRvD8xa2R0lGRJ6zhtjSppr/KslrVCHVAVW1pKVbcnP9Twjl7LeAcuGu931cf/teItPry 4T5NLzSBwfbbwWB/rSCIGgjMrIfIdoJAAfoHSFmp5+gfrhq8uiq0yr9BZr34Wqda0PfuedW6 ZSO37v1R65TKrNwK9rOXhJFB44G1kHQqDk2OuqdoJgq2JLz+SA8ofbV3uhkhgbh0WzpzK6wA an4QL3jU+ck7+F4TgBb8FvyixQHy7i8dm1o0DsTndIzCARvsvxkwDFRl6UBVy5V2PP1fMxn/ Ltv2X7Ec7Yq+sNyYazRSyuGwDvO5bCjOusOodSybTbN9TArpmFpCmnnUkG+iEcBQ4+F+dE5i 5hjjDiZby/GWvug2TrvAaJ4AVVaLLxOHBuEMEcNd2BmXTdfF7/z5/2J2LCaw7FD3K/WIy4Es EGOYPudgmvUNQuxjWqYiSPsnjSx3aFRjzP8zpwn2GsisgXhfDERLSY2SNmv9I7PWWIGQnHN/ DMNqPHCu+TEmJ39CRWClcXbJYZnB0OJ+h3HMr/CgYOilCaMSjb8mqNhkpq53+jl0Mcez1hVM TGRXxBZq3ac6ztsoSd6OkmDI9XGqVVzVIpI82+usRcr1nau3GqUKpfsl3LM/35PUWMdpdKUW UWnvxUftRvU1slVWP1JZDcnHlfvpQnBdWrkuCkFqbly7jwRaKbgyV9feYW70XvkJj7Dzr6th r0ToGywgTyJnUtxhVk6eFonDTNarN28Gry/q0MjEK/a67xDPHhSvJD4fhZHrMdJx2u22Wfrb u0P+pIHV1T2z9zAV3aR9WeHHrHcu79YIm8lFBxNNalTorSqZuJEzVjxfuTqMZlA62LeHwCM6 BEXI8X/Yg+L+pOJqjD9ps5h28foiQ905hZet4PjGHdztwAcNN9UYpUUI+bP7Px0xQD3+z9wB ToYRIvc8ibFmQOZW1l1sjUW+EfT3KLHQcf0xVp4ma112cWITpVV+5Y4dCze21Qg/vhqh6C0M 5LpZJOeQYD1gR92frpPfjsWf7/vrRIEJtsrHWj52o+jv0TOl9RX096l8tmffGpZrsaVhzSkz pgt28WKvX/3zH0//+fbklA3O37477b979faf9AMN81tBsa24pGFFVTk1dJRVjxzkvsXbI50X K2zs6qTfZixRIds10FQctFkVdKZpH6WLsFZJO7lFQqMC+rgKCdIes3hw/jL7uGfxQGA3u4On X4WHfs5Lsaj4gaiw2sGcQY4nVWg4EWiwmEChX/QXz+hAiQY0hUWBOSg4rUKBjKtYLAAEP8yI 3UosWKfoh/FTRRIXbT4Ji6fB3EPLCEf+lnpHxA41dG92L7F3M6S8Li1a88VqzqFDOzkrmqAs /TZPP01jVsRDmg7cZM2YdQ7bbPAGCduYBSHWXRMQ5JK0i8GbU7RZ6Yy/7DClNixHL9+zQLBA KFstiCoA4yFQoSlCtLpgdyBQgeKFgHqqWUxVP2gsZMEEEICOGFMdKzp7LqcuekbFVzPnFr/H Z9q1LTwsPMrgkQQam1Ros0YVRAU6YDtht6ar4BGPgpB3AAC+1BKMkIBfu+HYvsknE3fkAk6M GrFnjn+rXdziw+KjDB+wxj0qwyKhqzFMi5AinAtRDScMKuwvF7ubx26cRO5wTndj8WjKZzzO NAn5Itp9LUA2D5DMGRzBFYQgE8wojWTIL4xWSWh+BGzmMPCC61sUOYpF3MvxKp4Vck3Pj9BA VCE0mnYWM91Y57Am2gKk0rFBnEcYuuHDRAZGIjGXSCLDhWDTrrYVwmwrLtlM5U/v2ZO9J3sa SxkKbSj0PrbQO5EbB36dA5sIbzi7mSrEVHsac5cFSrU7bQXLb8Ulm8F1haspQvYItiBEGbs0 mwtRypFAFYVcuM6c9MV2M6hhtNMkhKFiOgvXt9bJRIhy7KIrMaIQi4OmpBF1XZG0Rq5rweJg xpk7QxbrBn6mn1AEk355rFHHirbNO5kaAQyFx1D3YytOaaLpktcE1gexTXB/XTljpa1yOeU+ TZ+cuNdz6QXDIlmWD4iaAnKY2wD81Oyvc1YT4S8DcghJ8Dh2kIUopFusvrP6rizrkKK3talr ki8OIyvQRdqNTeTa7gNk7PxPeVmEXxMDLJbiaQuVpGH+0isqLdA0xoxjqyCqEOJMrcgkhKKa JKGiccyQUdLEtRVyVsiVCTkwmcYnLbLqMfR77nipWFPTeGjoN8k3qkIQUKEKT5TwzD1k5Xzx yzInod3aosOiowwdY+65KFzReKVFCElQl0aaX9VzkpLvsAV5JjCJl9XPuYjqFip+i/3NYz8f kGGITHKAjI0DHlMlPps6N6qKUtSWibqfDkovRs48FrH+CFFMPUZribh5ItaRik0XVfitrayk wjDXF4XGYP1kwSG1hZdG0fyCBycKxuAeAETiJ8fdvp0zSPNHNzKfozIG2A6AjFvrAPSFOS/H CnJXsP8IxZXCcY54FKCoEj1cC9fzmJMkfBYmZAlhZQf2P/W30NIxM8ShQhYU2EAJLAU9Uv8N lFQGrKAhai+VPS4DH327l8tKOIzDHcWHO/0AWRaov3/yRbrnQBpESW9BTTl1RLGRqQsZBsxh xEmkGdCXfRZFhEi5ZzP6VvnvrIfGKIgilIgUCtRbFOCY+wl2EAiz+ETWuaSaYugFmDk8huKX gcAwQGky7OS/S2fTqg6rOtbjw/G8tiqO/NxnNg+7KgSYKpIUJmLJKX6mDCsyv7Qb27iKjauU GVXK7NB4pUV6AznTkEfe7RY6gRbRm0f0EY0MCBC3kyW55OqSn+vPZ1jaSFMEpkGI0DeWtGcp fcGeViwjZBG7Y31xkF3SXunrtkUs92CJn3OUnqsGQQEH/tmZhejroFJ1ZCh9dka1k5y9EDlL vMk272hqxwq0zQs0jQAVer/p1E8hQ1hxShODPmOeyPZZxEPTfI6M9kwCzwsWooBFWO4ekkRS l8TYLg1FQq6wzYxa33a9bwtVgaQ7ZnvVwbKJKBmikBtG1NhJHFIW9H5ZwHqg3WorVIS9ZJmx CCAIC7JN6/IsJbePkvdx0zbtH8+5bw3uSr1jkXZ59cYlh5HlRAn3OwyWlePBYaGXplZKTMo1 mwsbfARJ7/Rz6KISutYVqhR+kxcop1SrSfJ2lAQIAd03kjzb66wly3XkzKpdxCb5rEc7zSXc sz/fD5xrPTNSAn66UouAs/fLt64dUNRJxbvJttXiwHOoCOzgxvEOd+Kb7sVpvkCETC0VPklv M4jE5vJf9vfOXuz8gFjjmhMtDoakN5PbkB/uhOC69Lg9khIhHWj9ivX7SCA4d8HkNFo+HHN1 7R3mRu8VTUjD0EB9sGOFNDFUQJ7QvOP7prQyWa/evBm8vlh3R1Mlfq/7bsDOB8Uric9HYYSa GdJx2u22WbjYu9dRKi1eCww/1Bj1nlT4MaVgTb/UoLpym420OfSOnRi9hOkwEBthtXN0NjBH 56h7nGIg9/dx96h71j3tnqDRSXth3WyX1qCfdt/bpWqN10Dv/CvEdHPuzHZQAHNNE+eIWENn 9GkestBJphrt2M4JEv+F/0ATfPX19H3SVRuR7pVKSSPAV7spGzl7b4HmrzrnrArObOSUFU8Y EVka05j26OuI0D7RLWmURe7XtUtbdNhCmLJaXVXzrfFKBZBNBIiGgeoP6663Jlq0ERHQq0kK cVZFi61A9VZcshm3rULtVAOJfoL5HNbR27aYyEZEYCU7ljp65OfBkSN3Dk4dnLuUbZ9sYeeG YfKj1LnL+XaaQrYC3tqmZbbp/fHcLLvbaTtrZ1HUtP9zacWtEJxbcUnD1LdaSIXaGKqcxw5D tJpQM0naRJLtMcyt28FCY/w2RiqIevtCg40lolXxZSp+uQhTU5EtikBlQ8UKDbujCNhAx+48 Fh1ZgFGM5TroYExzpNqFLT4sPsrwURCjLcJF7F77tFnA8TFCiE3daxpACf0gm7EqwCLbtiwy rLW81lpuSzd7RUxLDNrWJh1j7gMmGI/RS/I37vMI44WwLrpkEgQWd1iAWICsBciQKrI0TmmR 9kiNJJqG4ngL5zZOVQitrUmYx504Yfw/tONB7fkcU5acEKXd2RpW1rAqM6xSBtNTBS1CCHtH K0zIpcDudEw/GfEoceB6LwAMTo76ELPAF+4YZSGYFAFtIqZF6A1+FhwWHGXgoDCOJkVbhAsH s4BS3xtwGAYAwBitrWJYfqzDfSv4fysuaVz81MdkMp7t9hRv0Ne1CCJarsdv3GAewy1GzBQ9 5HIFZW7RDradaPCzJLRyukxO08pujVFaJKeX5gk2MXju/4lFPrS9UABHfIrhC79bTu5BMPX1 xYA8Asyz0q5t8WHxUYaPeaixSYvQMYmCGTsij/aMjWha+cLF7hLa7oMA6hv2ZoiRoEsEARIo /ebRDc009wL/Wru2RYdFRxk6EFvU+KRF8KD2ICiHI3i1FCFdjnYjDQFvGD4ArKwuvr9xYzfw C4PsLCLMQ0SxBH9logPVvVSPPNhIfWpvFGCpBI8yibwOP/lafRPh1cMAK1p4hXARcDRjM+cW CiQO5JbFTKcsNc2bLXSgDfMtYRHDFBByLp6SpCMJGDsznjcIEPFjF6fswQX9xphhupfnjtzk IXt/fvHH4FtH+yiQpd3yJo/2gYiPSMiRqFfCLj22nOGzEYFRkfxbPyrOBGEXJ7ct2I3V20KJ ZO2XzdsvELs5AZupxloWQLvNlsJ0lCYFJxxd2gFNdRJyVTl0n0YBi4zNI0MjQIWV2zQClIdY 8AMrDmtio7OKfOIecvkLZRKosJRCQvBKvDHSCKK0LohQNjTkEiO2Vsguel7swPBdswaVf0Y5 XR0cmwgNVQkI1+as//z5/i8fERlKNzlSbg0rY4APwgR0BxSHaFJ4v+62xXhEE1qw925wzv+j 12yUyCw9ytDIQa1HadeKrBcz42D9hHHyfE2UMmR3Rig4RCkJi+dhGERip048R/hMiM90H7n1 R+3suw3MviN/lBrzUNkUYFfP7XfOVN+IV9eb8RE6QNx4lkJpnRY2VRqM3QkW1NHMOuVZIMm0 DA9sY5mZYVHyV7LPSHTnIbtxGTlhCH9JdlQs8xkikoCowhvyngq1ghpv2sCCDSyUJdGDicYm Jda5qSJs5vi3KvEnS8PhNl1OXXSoAgopbvIdSh0UkqNmkdJNtHhQd0ssPiw+yvBBhUxtRQhx OnQGYv0Udh7D3goE94v3CMMhujZLm7udUUK9SAulZ7QrW2xYbJRhQxa+6gmMFimQN0uDt8R6 or3MpEyo8wg9GGj+FkqDlV3aAsQCpAQg5dUTebYTBonMe6z1f40I6H5fAVkTod1yIixbqvRw 193iaytwvhWXNMzb76u2EWGepb6Lw9RENVa2M5056COZYqcAdJe11uw8hbU50jP3eo7Y/4uv EXhmwYRCxpPA84KF8FqcIcwzOdeNPJ1cUCzXkBVYcNjM3vrMHlWRa1L0bkPAKFyQX8IewIqc +y5mHMqhInD13zzsAC6RrJDP0izLFAaV3tgCG1tgU6vApsX4yKYnsAf9y8Os96XD+vi4DvTW 6zqYHqGn+XCnH8wjF2GQf/I6DPNQNzO2wqmwl4ReRPv7udahkrattKnbxlJy+yh5H9eKFwJu 6opN7H2/Y2t4eYTuksPJc6KEBszwBGF4pHfp9Z0Ku8FHkPTQxojyOz3xXOJo3FkP2+QFyinV apK8HSXBkOsTSe8BSZ7tddaShQo7qvtamuSzHi1wl3DP/nw/cK6/K9XY5IUqgLP38lvrztVl 2mBbLQ48B40+i4MbxzvciW+6F6c7T3skxu9ucG6QXkPSm8ltyA93QnBdelxx6JC0Z5g+eIoe oGnjrH+8k34ljd/7SKCVkRZrnOMGKXiHudF7RSMwMMyuu86UMFhAnkTORJ8hdg+UVibr1Zs3 g9cXdWhU1W7RIP8lve67ATsfFK8kPh+Fkesx0nHa7eo7nfdPuNi7b6tSMcdFTSqstBUMP+5m r/K39OPHFttgaVUXVmobNRGGqE1jjXolutVg2+DLkmG/1LmGieqzAorrrmOuQZr0LstKq0s4 q23Rny9rAw0mUyXfIFKLu1qEFh3922xirdRrNOkaVMi2pdRW78pti9y332NmnB3t7/efZ0EL k5NzegCJ+91/XVBERsSP+mjHveYwL9zx4c7LZ3QfZ55Mg+hwh3uBgxIX+mrsJAjlkMPV3X3Z 3f/53d6Lg+e7B7u7/97ZvBEiA1/y4GaHwb7VWCqY9IrVfviTvoszBKe3kzMQiSyXGF/Ya6r8 Ouoer9XAd1urJhDo5/ZCFwTqwebuX66zH4gKVeaDCTR40W4aPEY9F2NfQAj5TqjRb7WB7tOo WBN465dW81a5AF6x2IpyuKAINzOjJFMLZ8ACXgIVBAtCR/qysGi6Kj6lhPpbUe2se1pkopWs 293KfFNM9p36bjPHzFSC5X09BLuRx19XaireP+2eWN6PR+5qrfU3VWBb3q9IP5jI+yfdvuV9 y/sHf9HgPYr1lqbejOL9XCiz/O33BDjVTVO1Z3KAU0YEZXUZUa1+pL7Fl1wJyW+ENXvPnuw9 0ctuSlJwJljYKHd/M/cSN2zBDpMKQ+/McT20nMesH8xCJ3LjbWzGtmDe/GygIzaZR2Jm0yjj PMxPTxZYV5yN0hSrB/LpXwwNxAxNjuXFvl5obkm4eRLWiaVXNy9sRpcs3KS1QwMglkPslFcj Ad2IOUNsMU4wHpNGMmMaIL2ZKQWUDqJRC4012lhwWHCUzD7rLWqWO92VFNsIjCuMl5KBGTT+ X+xvmjo3cm2hBhoxx5ytDAy1ALEAKQNIKlw1aVrhjFRljZsEiBpOFmOqMpZ1RjSSCU01tNcp HZ2pGVcYUi4GNiWBdmGLDouOMnQo8avxiongwAZises+DrDANoX00l7Szr8VvL4Vl2wmeFVh qSDFr8ZHqnlfn50ZokYdSOVxMJdD8lAnlg6TdLD5Y5SQuJYDjY+RekCd5PZxqmFE1AhQIeqa 9nj7SNGmQ0fZ/Rgoean8FLYcjKe2tCpzJd1QpNHHSjlrtpSZLSveXwWQTTToaYhqqiSGfORg txA77rB5CANfTiAWY1eXv9VhUwwh9q1B33QtmSaaKjiuadXheDR1wUncGz24XnFcEwESOsk0 TgOkU9Z/wmgi8WIaYA7xYP/NIN2gyKBAvCBOkMLDL2jEsXpj83pDC0NoWj7V8EhOJi4Wfdym ul76dDmB2LFUtCPW145YV1pT45UWyTfi96Ez+jQPpTijne3IAol1UWciXSrenpB8GwURQjQJ IBNjOt881O5spdzmpZxGgAqma9wGKIQZKo5pou4fBT5iJnMkgMbcgw0j4t1qc/sT7dlvBfNv xSWbCRChRK0tBWoXCRdA0Pi/RaCm7Qjh/ixkwrLXbrEVDL4Vl2wGxZWx+sspatDSpdsIwgv+ U4oE658cGFMxtIzDaPodDZETmgZxFo09K0DWtILH/pE6x1QK3rKfNRPLgqjDyPFHUwQbv4KX jEJ5GLh+0mHuE/6EuQnjNHAUgSO4VxLMGGfOptwZdzlW8Aifinbx8M9F+FiAWICUAQSc1FZo pADISiWI/WNUDHFRfs2RuQ5uAY9YmZa5tNzQiblNU9tcA1q6RrG+jyg3T5ymsRT6TCqMJRPD DHuP96gsgztwTKIgoUINZN/er0P7mgl7GykT7F3Moxv35mzxqdZpG336vY/IzVxKkYPIzkSu xkTxojDHtfNbHWx1cJkOxrLFbLGc42ks0yJ5czF4cyqTXbQBU9qiEDiZqSocUninCHiiGiD9 WrutBYgFSBlACmupWwSKYZBMlwviVdMT2F+AZeF6HnUJZmpjzKgPDOkxxq/RVYXQjb6YweLD 4qMMH21eOSy8OPLcYEa98lkQjbEYFKli4CKrqYiCkEfID0stKXQHEspWddg6irX+mwqHa7zS Iv0BIJClBAcOCEi1gogJin3cwqYSJUejuQdHD6gQ8Q+f2/AG1mltxFmtTM/U4bmmsyyFFroW IUOF96iYgn9O1qa0jAhreM4QFR/rkxHisI1GNSqYGrnDMZ8gqDRmLmJJ52f9n58926MIyDtI qRnHuPQxCSaN9a3Vaq3WMqt1HteAgqk9/dDKcOMEoGMqYuSfQyTeJC5iFWtF9Q1GRG0fFizg Nw/4M9QfcYTWbskGhM2I4o/SXPE1Cg59GZwjwzKtFqFQxPYxqlGZ/vX7yEkWNm0wDlubLo6B BwAjCubXUybicsGEnCsVjcNqeApbiwAciidYsPApMCeMSyHmLTysP7U23FDsfm+RQ0XqQDF8 lwZ6uRN3JA0cFWpAGIKam7JIg7L6ZajaosOiYy06RIGOxiktwgeGFcy9MXqUPJj3IiqXGk/C 2oIP4ESRe0ONzSrtSQOM6CMle7bQDTDMukJyYYSyL6JcxMllc7IWdYi9sUvlMR1BV5V8E9xK MyqWZNd417o5m3dzNAJUCI+mTWQwWJ1jmhjfSyWamEO1mLqjKfmUTBrKMmmtCTvqLiBZiD8I Lba12eYc1pdUopbdeHz0njBEJ0ccqhz/E34io5q+ByHqMuYzZKYx3hYGc17FP4TzKAo6tNtZ LWG1RFn0e+gFo0+FLG2FQjNRUwwl/6shP7J2I5nCqlo4txgXBxxoVpQDk0uVc1h0WE9xraeI gRC8xeN9SDVgU7STxteBj8upi9k+y9JYOQaLWrmEBSV9ku3DxlaoR3tJxAJid3w+wDL13d3+ L/t7Z2JDsPjS5H1K+sL4+KZ7cUoL40HQiMwaIqwyb9LtUNoVf/ii8pUT0YHj5JwjFx3x8cC5 5sfYwfBJLLmvWP59yRGkQmSXI/yBATyOB2lFL00YlZgma0pqFJWbeARJ7/Rz6MJSr3WFKvOq yQtU1N/Uuk91/KPJG/XejpJgyPXSoCquahFJnu111iLl7sRto1TZ393bl3DP/nxPUmMdp91V l9PkhSqAs/frR+1G9TWyukwq3q2ywpOovUR2jfpcHAxpr3lyG/LDnRBcl+pWqVlJdYTpgxeG w/PnZ/1jWv9+z62JlUXd5uraO8yN3iuaVoFNHl0NeyVC32ABeRI5E70Lq+T8dxbsGigOM1mv 3tCAoDo0MlEv92iy0fmgeCXx+SiMXI+RjtNut83S3969jlJRnSOppjFZ64OgxvqiFR4nsKnh sUSi3q0RNtLY00NZgE+l3DdYZljnvFXScSOnrTB8RSaXwpHw8UVLcTpQKhHFXnIOKbrMcmUt FLjUrltfZNwn2DRJtXbgg0LXGqNU4NhEXCBThYW+VJ2VISSfy6WE1gQVQrmKRypwwCypINSj ShYcNr9blt+VGSwwWFsRQkojrwHR3hfH8NHjcsRgRqEuDCwwLDDKgOGO0YiB4vL10fm7YoxN amdZApdgR2OcsBgdI+gboZaRAtKhX2a46rnjX3MRk4c34Y4Pd16+pDAXrPbUu5Apo43cqCft vEKHLtLxubNCXVedlIJwx/393V+e7eTzOhfJLXLbi4Mbx6NhevLafIIMFEqo1GXP0EuD6pAD Jx657uHOUYQtKRTJU7FE+TmXWlueKf2HtEOR19PUQ6wwtWFFI9U2FnVhIvkfYgEGL4wxtlLR SsUyqdj2bW+5EZNb2u5gkb15ZJcGfdWX/5v/of5BU9SWbkbR7erL1ZJwxQ+WcA3Xji5Js3zX pddP18lvT19fnH94pF6rHyzxDCSeJOOHq6Orp4fq9eHqOP+hf/XUUs5YyrHHj5ZIpHc/eclv j9PXoy9fLO3aQ7uMko8t4SjUsJGQSIU3n9Gi7E0RdNnvWMKJCm9LuGS1Xm1QYGlVOR5q0bOB 57j+O0w0VGGzH2Obk8+j/mVE1XLFdAYT7oqlWo1dXS0/WMQZjbhVN0BzEKx1YqyS+3B1dvWU rMnMLTjNuwUn1i0w2UJhXzKbBG/0DxZ0xoKOsT/ydNMoVVJds6YsfCPavPdHrVOaWASUe9S1 7lDdWWXgk96KuPZWXLKZUoG1frGK+hbLHlZ6Vwwq5W3vvA2a6iteMJ9ZOL2N3ZHj0X4/fUWe xcOPcZjRpLYWD4eH65SICUg4ZOnQojqnNVFri91ZEgyICOSXW9JPtFttBRy24pKG6kDJhss/ z+T6z18O2GD/zUBMzNvCcnHLkT9MC/XEUglNyJX4hSYoGrRQ9OX89DqnNVHRyO0e2um3grO3 4pKGKZRUcdC84QVNBcOgYsyb1FcDi5XSuTGsNFUPLRpy5/R4+xjVMBpqBDBUKre5zhjlZd0j uaFDDZcUzaxiBjFNnFRzWuXc7tzqaWiid4WZzFbE/TALpdJPbgM8RjSVdeHG3zX/aCPB4IrH LJzjBxixDKY/6h53+92T7mn37CENvF+qCoZFfqRi8i2vdnh30wVHbQBIm3u+xXhu5xpzEK6d BPOIoTKygfdYnxbuz0LanqZmsor1aQIlYkV1odXdKpDNKxCp/7FiSXZeYkO42OkVzJNU9StK Mce/ZfF8GGOcpTIK6CcaviwBN09AjQCGGsjCeqxzUAMjFtD5dU7edBobxjhskTkNh+tmBpd0 a4XlUucOBj59MrjOYGydwOg6Lhhc2pWs6LGip6wH2NFTBRUC0kTOJ1/CdgBbXG8e19kOerWY Xvq18HRHPBTGH94ud7jG5BWTH0xf6VNJLfE2TzxNK1aIu6aNFTWu5rboP1Qc10TpLPJYGT6c lP/VctcYY0poKyLWkCBGNI+xwz4JNMpYaFholNkrLlnwWIimz/1qETDIbEmVAUqpcyuPY/Zg Ag9lzMZYIzFKsO1tyL1gQeEgC42Gq+c1AlRwW9NaI+UqllMfUt4+FNu0HZbxWzLHlFlP3w9c cSsTlQul1qTvLtWMqzsxVndY3VGmO/QJwy3i92pkizQzTKgZd3yVQ4BNJTa+TYNQZBIouKiJ LwsPC48yeLQ5zaZ2N0pPXOSjpWaAaxFjTia8CybqNrAyOlnaV/hWlwkWGhYaZdCYBNHCicYt 9scT2oTbYUPkLYnr2etXxxSXQh2T2KKOKaJi+Sk++5plpftZFh8WH2X44J8dzLVv73RlN+lA K8Sj4IZHyoyC0oBdVQhcdaBFwhj5fbmdfTt7f2wFLGZJ94N55PJIgAHjbEax/pU2VDrpCWNE M8JN9D56WKKO8JMXBJ8QlFXeA5IWKmg7DhY+VroIpyJOMGc6/QBdot3NagmrJcq0hOuP0UGc tLchengrmF+54xIWehBtK1h/Ky5pmJajiKd0adOkgCyuFknllYAvdfTMvTESCDK5JhnXCmmb RVhrqrTf1Z3MfSzQQy9OrjeHnN4xkm1Yp0UJOEf8Aix95xP3RXIkmW5jEmErJLm9JHRZ7I7P 5c4fu1x81X3765aL37Gaurx76pIjquhECfc7DK0DjoewHL00ZV3iLa4Zw9bkAuje6ecQJQx6 UrbqClX55SYvUE6pVpPk7SgJhjyqxVUtIsmzvc5astw9mKJJPuvRlnAJ9+zP9wPsO1xHJrpS i6i0v/tRu1F9jWyV1Y9UVkNaB5jchvxwJwTX0fhvkAY77rabQCvTBM3VtXeYG71XVCrp80LN eYkeNlhAnkTORE9BlpxfkKdF4jCT9erNm8HrC00+ltzRVInf674bsPNB8Uri81EYuR4jHafd bpuFi707eDtd/7C6rkK5qGqYRfp7J3zizL2Wbrdo0r6s8GPWO5d3a4SNzBrpyU22muT4Srm4 mXPCX3/lM5LhJArFNIBcWyKijRiYRUOzaLRWmjlCxpTawt76uqVfXzrcJ4RshEythkIhNG0i DCqeLwXbc0yvQu36ECBRdEC/GBBYqOom919p+Lf42HxhAURVRrVBlyqeqG4QY2xyZI3Z1LmB lFsbilnjSG1EEvSGHKd1V9bRl3t9VW7FRo5aAaoxn6DYbpySxULEpnXXpnX5vm5qtEiH0BoC VfpA1ctQFBrHl9zEipmvKk+sEDNpIxE1ELGZQ+2oKJKdTGDQ+iiOFYWAGiWset68etYIUAIF Ezw5ZSnUOaqJ6hZlJKKhTtg+2iW2guG34pKGVfudYTQk9VSE1LMzj1EhIPSeCC6kUzNoaLeo x07HeHeYK9sS1ITV7WNVw6go+hBlmaYal05laMpVUkKxu1q7CXnTv2RK+1oiWuN+rXG/0uJd YQgYqV1lQ4mcooruE7Lvc/HTuzBksWGxsRYbJXJW45sWQUU6waQeBql6EM27CMiRwUDIgecr JwrBadauaa0465uV9WQtWhsWEpPVxzx2r32arJ7LGXQzFEjEiPlyajdHfvuABYjVH2v1R3sH 5F6+fvC5e/uQfA5E7ggfOThgGQdZjd3P9GPV8yNtLzT2og7djmPcsas51je2Cx661QSpiQZV DybShTtzPSfybjtp4ixNYRb0BeY7SJ9k6YZoF7Sm1OZNKeEGLtKe1kzrj9lACjnKSfsImYWe O8LkDhU7ow5AIfMs/aymX6vpbxxvvr5p6a5C3CaLApww5A6G16gBHT7N7cA6mm6MUbJohrVj CsbnW1Fv2iQPohJywhYoBApDTC8mi3Pv8R7zUKziYNVVFCSSF1k8mvIZ6r3mCf1szJwhBi8J rez4VlRbUb1WVNPaNI1RTDQ6K8oqqJxF5PDEsjdZ7Cij3wk2wZ1j2ygNYZrCQdMXjtIWVcKU dm9ri27eFtUIUMF4Tc8CJ4aqc04TM0LIfBIO+gIH9O40lwKnKnrhDKykvwkbvp3nasMWO+vD Fi3pLanQIEJ7OFHk3mC4sUKL2lHtqBifnM/3/vWrxxcfsb0a5dpDqzhsQG89MlQouL0z+kry PHJ9ewEaKLH5whAix8Lqhx8RPnpnLSurOu696lBzAYWphKRQhnbKAimji/QKFRwu3GSKlh6Z M3pPcNEMSut5WM+jrKAAIlXjkwoHqVHHo3fc7T/82GEL0ZyLE9PndGam68dJNB/JThMFEMJD NlbQpkatoqihKGT0xngsVPoYKMOUpQBCEbx/ffoAmBE+eVouQMPxQ8R5peo4kRrD5tvkmMVm 4/B12K7pGJXwUesctFFdUYEPYRCR/9DvnsB/0K6xFabRVlzSsIYSZNccJmbhUOnK2BVTjtFg MuaUWePjjoyBxgEl12QvEBXoxDICNOJObINANgi0PghUsHBNNOErxLJaY0U4UOZLzNLEGRt5 wejTwo05e6DKgB+KXIKM/uBreMDbJ8gNk3EaASo4r3HLRWxXqHNSE00XFfy5pkqhgMUw70dT AowbFQcrjILZDFnqc8e/5uKZQ3S448Odl7/SqFCTGCfmHjQgmmCGkTu+XpkQkb8ISFJ1DSoQ Ou7v7/7ybEdcT0V4LpJbDyOLDlAgRlue5DPhYg7CSAxNxZM4C/wEevbAiUcuRrYeRa7jkZOo JovLz9pWqPRM6T+kHQrWFcawmvSEwSoFhk8vUOSOX3eb446eMxrxsDgxNH/SJflXzmkC+eWh zCO/0KhjJ7H7Uq0BCUm1Zt+djBytXQBgai1tZjHmahap6ISqzGVcGAFhLDiI1VLhpbWpiUjr ItsUSVmKhOoxNEapMHNNNB6pkyzCrvmZmyDgQJ0yQ4xtFNoh31qZzXQsIki7twXI5gHSh6Hq +nPKaJHYyqbMyNkxEZdbbyeO683xQVVToEz7EyqIkgXntkC7aQNAL448ITL6qnJYVHql+ATx aPgqMjQqFkjmm23sJCu/2eQMEfBYZstEDoTJZIImGitUQtORj1Zk90VJl9BAGQJUjvJMf+p2 REbTUPhSDCrAXggmp1EEH0MupjFhgCGaTOuAs1F7rXfUPUsLGZeZexT+ykLhtE64vwyH5+01 7XrWLNu8WaYRwFDhj76kOsdsFAYVeSHVSpU59tQfA2+eNPGpzI6uZo4ypGiXtuCw4Chz6peO rsYuFVA2ESNyxgJV/aZW6QAl8tB9Z91TVflFHmM6UC3mfowKhBtbUtC0EVWH4Zp2HFbLAluE DIUBqShq1AczYANd7cL51ohjlYdVHmXKA5MQND5pETZUbEl0sItKYdkwgnLh04fCB3eABqpW k6EorVhYu7PFhsVGGTaEMaJxSovQ8R6jWoUNdSrKhMWquGSKks0F9mmIrQIKP/qsB+WMaLe2 +LD4KMMHbHKNT1qEDtVgknnlwgNJ9xs4N8hBOUNUXqHFXXwZBq6f2FJ7O8hKFdkVlhypUrvC t3dXqlSEi6gdHELaiUZTl0rrKRVKE3nI/3XGYxpZNb5x/ARL0+lLwaC05xP/jR8wn8vlbBos rfi24vueie+0CIp6TKiUOF1lImDCP7txwv1R1omioaFESRmxtG22ftWqOGej8bteF/6UD7GE Rv3ktqM9WCtmrJgpEzMtzt1A6a6oVgTXIg617CPViYB1ZkHqbhRkUtE6ro8Ptbgdiegodsfn Ji+hXxx4KMLHSUWHQnzTvTilEnzcNSI00J0VKtLbGNijTCl/8aTl2dTjz/dhFHosCoZebfNv zdNC4UFPabZv9TXuH+tsM2zs3SE/UnBWzlC2PE/tXvdFVWwzz4OKKSUbV0WeEyfnSCbCAhoP EG04jrjzSfReJuWhi0sO3eVE8Lw6DGtcHA9VLvTSnISv974a1cann0MX3Ta1rlDlmDV5gXJK tZokb9FsO+TRfSPJs73OWrLcXZDaJJ/19nf39iXcsz/fk9RYR6a7+vCavFAFcPb3Pmo3ssrK DL9puKzaDsF1qQsqHVBy5LbRimyVrr3D3Oi98hMe+TzpatgruZ7BAvIkciZrK23uDPAaKA4z Wa/evBm8vqhDIxNNpV733YCdD4pXEp+Pwsj1GOk47XbbLP3t3esoFdXtlzp1JkdyQVADQra9 Z0/2n+go+2o5v5EWS9rreOl4n5JpFMyvp5pcqDhxldTbyHkrDNp5DKc9LayXE7d1b7c+zlvM 61txyZXgUpN8J8oRgwjRJUrfo78fFh6GSc4CGoGdLtXG9uy0gVy1figOxaY3DXCWfjb1XJZ6 DhG7wxQ5jVdaJJwd1OpmGoaQ4NCiWWcWUmUiFh26I0fMYVWFvCur6SwsLCzKYZHuw2wrMhSw Uewols6i+DFdNsvYOY01FE0h0Cxn7vUcJRwvxXziyGoN2zAIX+zuwtze+kK8u6LWTVpVDiMd gN5ytecTptQNj2JRKcwZYQKpOQqmkdFPFcXijdrjdkw9U5pAsPrD6o8y/THEGDaUp7d3z2cw gS0ld32edOQoho7oGKSpDH8X78YBUOMHifCNMbWMw0m5RS+hBUjDI6w0AlQY8023nAs20kv4 Kk5qYkyInWGadTiPwoA0B5yL5YAJRktwhY6Z++4YpRGoBA98x5OLcR1rYDU+4a0N8EAwZyLs cl2atggiajilMJ/QJRxhriXWtNGadDFhD7Hht5iAqPxy6i0U/odGG2tcWeOqzLhSs9E0XmkR MiSzwyFfglxOPtT7I2B95XvQgRqmZ/ctPCw8yuDR7zCY7JCnZx32tw77e4f9d4f9o8OOWmtu vYMfruaUZJoib3KliNIkgoWHhUcZPJZSV2OXFikQMclnvbJgRwL2AD9EAATBmW1GbTq2C6EM 0dzXBfFWCKqtuKRh9QPFQr3/zX9R+SH/g//VRKSl4eY1ap5keH/15WptD4QRsxo+py+Ng0qU 7J0FvQ1mitr3pP/8cpU+9M9/tvWxt42/zX/OPXCydkorxpsT4xohqqRhLjdj5MYFIWVq3STL 3ZTeI/tpoaV3I1K/99N18ttTRNU+PFKvyg/5H4j32t0tnJqDk7SOPlwdXz09VK8PV/38h5Ps w4er09z7s6unlooN56kLti179Fj75icv+e1x+qKfqPfil9LvH3358tkS0mxCalQt+/DYUjFq fvNZkTIFOBZ/vPLZUtGEwV1Fslgq3lnNStabsl/SFkQDqXj1KNV3jx+zq6urVBU+fpz/gPfZ r32HRD072t/vP2/JwCQ0ZPantOQe1HPHhzu/7tHBnXkyDSBSuRc4KNmlr7Bfkx/uUINyd/dl d//nd3svDp4/P9jd/ffO5sfYgeuyg/fIfDGgr7Si/bEoTzRjayXgrXjnhzzR7ImlpN5vL6lp jmHerXxU+SH/g+9xPtuN6mftJXWlhtkoVoQ8b6dYBFZqyqYPV0dXT8ltzGIB/8hc/sMPV/+d ffhw9ffc+799cyyg3aD62YJqcfAVk2lXFNCL9j7A+qBi2JGTe1V++FKwDFZCvmvykhsVh7+0 mnK9P7NEX62HXhVo3+gjf9nqR16hgXSmJ1Vfb5SaSnHAkjV+KO1a72SjXPTrfeSinHhVbwuw jlJGaTw28Uf+rIVTfq3E30ye749ap6wSkRs5Y4VwyT3qWnfI5Y2bYJjefXjS9kG7hzvfurwh VRV1jMv796C3QvtvxSVXwppmaIF1kLl7tutG7tCDY1LnmCaq22wwyIM/xXwQ2WHxUGhhlAix cHobY56UxzzX/6Rd0oKiuRKgw0ONFCU1dSbA4pCxe9C1mjNI6S2SjcUuPI0WWwGLrbikoQqx wI/ZKLMDNth/MxATN+yoVruReAMbiWkejFgdnw6fXKBjeR7SfBh8L1cQy6FjGHI/cUdyxpjc WawmjG2f6DRMqoi5JHISAw1+w3pz7jGMLhl9Yu9//VUjj6FWxke9w7filCba3h7HGD4NDmJM zIkkhyCCRgCrdTdvcWsEqOCtpkOQ7/d+/fUjBtXJyXWnOfZh7/flj/yxYK2/az97hp/pXdkV F1Tg2Qr+24pLGqaELqcuRle7CcN8IFgPsTvEx4mwLni6hKCb7nKnkVpSTaW/QZNQNJxaGlpB WTYFZagPer5b2hmFkeX8FubEWDU+dieYZo2ZvQwLtjGENJ2bBXOukyEndj6pYXOF0cUWHxYf ZfhQfpwmS1sEErifC9eD+6J8UCcbNpftQ9jf3SUAkasDSCX8c2F5nEWGRUYZMnLGR1vRodtM KjCvBvSuTl0U+xN0dWmxYbFRhg0K5RkPip4c5P58Vf7noF3wK1DalchJ1tr1LA4sDspwQG5o 3hC3oRW4UMQqBJj073tfKbwV0sFeEqwdu+NzrTQ5rVdu0zpXS0lLST5x5l5Cszj6z5+f9Y+p 24C4e1AYz6FmBoQXyS3is4sDhJ4Odwae4/rv4EjvPP0BDdBgz+1TIRUhl2bTTJ4TJ+fcx2ZW Ph441/w44s4nQfKkd8nhAmDbBfexRyxhjvc1pg8onApOTZr+QG5aU6p9+jnECpuYvR0lwRD7 Z5/tdcSS90LlzXt6DGx//6P1DjYyimlIfJLchphoEeLJk7wh8SDty3tvVzYCk7tA/4oWBvo8 6Z6guicpYIOxN4PXF913A3Y+WPkRfXEURq4nULV96LE2F5j5XljPjYCyejCELMhDEV7IRy4V 3CHH4SOChX24tPsT+ZEsjyhSIJPA84IFJdRtMqTozDVkfmjS0EhDMOml7FXnrEbW3VGRYyzS 5GLZlGL+A+0+VkhbIS2ivDA6a49LSd3VuxyMx13xUn/JDyt/3v3T7uPtY1XDVO2XtRspTOjA 8oOxnsOt0CgmSukv7LKrJPMDlG3IlsTMl/jCBtlPkdQr/JTZESVNb32yYm51psAo1scMqAhG mhtTaVWTomE0+ErTNRUCpNnYZNI7wsCuOuc0UdC9+Pn/s3e1vW0jSfqvNPzhsIu1E9txJpMc QsBx7JnMZjKCrb1gEfgDRbYsnimSQ1JWvDv33++pJltSy6TIzcQi2yoDmXFsIWCz6+Wpqqeq xL/9NE5Egq4bmf/fwsbhmz/EEf266WgNU8a20wU/nqeNi5vVg/bxEubPv8CN/HH0+vBaX4Ap UDsRD/QOZNlhfc4stj6vD9m8vHn0ZlmYF2DYP35cWhcy7fTuay2/YfPZ+pTg6AKs7QwI6dFv rJgAalxCT7HPe4utz49sfbYgy6X1efXyWuhtQ7A+9O7Lhcr4APWQauSzLlBsfbqxPioA0Fdk gyl6/qXNU3aK/x1T0CnYMqY70w/ML44Dus4l2ZKFOF83nDWIoVMFqJm7+orTDNvzxD+Ynpjf /TYQvU7xIAjTMIhNex9MO9ztH4JhznfVAYcGvyzxPCGa5TtGMuLBb9fy5wz5u4H8bfBz18WW C4thDldTvquZqQGTZcLh5culCeJK1pYSlxrmINuj7T/DnD7AHBtM+08Wm/aXHMFuL4I9WVoX qmTxu9+SW1UkBaQP2LQ/aCDpiLFvS3LyZ4tN+wlMu04QPP9Cc0u1/FNYe0S/bvKuTJEK0Mr6 Sc6pu3sDEbGeuq6BJVA958/6ZH1UbocyPHVfy8xPk5b0gbRuQxHRNEHqvXOQxUFWK/Pq/GKx J2aysjnzpxPQqT3xShDG1oetTzvr8/ena32Yy8xZiG1NoupZqwS3231Tux2Xubdf5v48kRFW GBTdbsJN04C2IMWRGklCc0ryWC2reWcsq0HOZ58+YUSwfH3bvz7jAmoIjl0zFLAZZu6mvg2D qWsq6ONZ5OUBlMKXGLM1DSK1KAxrPootOZjqI7PMTe9JWcrTsnakawMr1ehIOOotNg3ZoB2F 5W3zpH0kKkPgR3E+Ud7C2GIwD/DTrFhdSM12aOUVLhafsdNgtWhR9XBqxv3XuLg+qoaaQL+q Brpa/EyIc9ebEKzSQKv8bBgadoABFQOqqt0GekmGISwWaQYtfMoxYkMtwdkXwTP5DMNHDwV2 DEJHEFjAqdDSYl4L9XAwZycpbjsGP2i1sDjQKNZCEU6aqbXdUkRIoZWbcIotUCWogo5kMsQ4 UUZUHGi04ZE49ofhbhGEj9N4qryDHn2qB+aK3MWuWnPc/U5gqJ04ZM9y/MMJli9Ap+Ri1/eZ Esoyk1pmUNdiYuzDLFKsKptq4De+Qwb7VWBf5VAMSbEI6as5SyupHwXz1VrYJA6wLxkoRgUD ZLdFiW+mge+HXFnomkHRRuS6rix4cTibRm2etI8JIncU3yHyFadjFBVEEicJDf8nfaBgmP6/ BP9llPwa0TGpj3Fk9hzsOSo9h4oPDVGxyHWQ/C9DFlFi/72m43BnwXfoLCinI+7pio2mByjP PWLfzL65sW1Fpxtk4xRi6nLoo3sGNkWF5uC9QXwpNQNe+wNRZIJMTF1s9UkVG6ZUE8NEsXNm 51zlnB+gOItcM4ozpWfGLis3jIFaFQmg2LntebEi++jgbrHlyrQErBj9U4x18IQifDw+T5er HvvQkTaSE/cuiFPDzFZojzrMwrFUHmXxWzphT2ptZRakXLZSpLQz+Juf47m8046mbL9VSZSM 1twTl+D9vvFKWMG2r2Dn++K/3Gny3+LnIk6HdQyplr20gQWacMviHSreozTwsbkWaCOOwntd 9+Ob3MoW2/rtjcYFVFiXPljCIEpmeZsH7aOdW1TxVkskhKvHiDrvRTymDBiK4Kap0zV+49Rs 6bZv6YwL6Kl+5BPXWvWA8KcoicC5k/OgvbHEPx+7szDXpMFVxVHxp2raMC6GNYM1oyr6LKhD zRi6r7mZEjSpfKTnaq4UgWDgqFS6imeOgiL8o9COhhWDIVXTsJ0nQjtnCpR/SW0WZycnF2fv aMbSw+Be//C9VE714ccHa40aSeFKkqv8HmSF+Zs7N3y7NwjdIBpuq82Z3fmjuXPnBLHHWaxS l67CWtSBEoNhsHt+g8Xs0cSspsFUiCHK3Vez9C64c0dBGOT34gJ1MUkYXzTu8VnP23aRznSK p7+Y3xoKUxEamonZTp71GtjQDzw31428y3DLeHrWhO1rgnEBFeLTh8xbJK2ua3vaz0mx7LMU GZoVvQlx0EYyn0vMhYBWCBn5B2WdATk517gdVg9Wj6r0QilU9urIKPCDtMi5uaHw4ylQPvAh OemF7lA+Dvm55fAH1MRZOzjH0JxjcNM88Gaha4pLjavrY+3GczOZgZIcoWXXB3cZSTfSkBx/ lM/w4oM0nuVgh0RuPkMeu6jm7J527ISD5EMa+aWzV8dHFz8skk59zi/N34Qu4F6Zy8ruDq7O 9547pKZqWA9dbAlwdLZsoJptyyM+Qi96wxPRr7P8EpgU1TF/4N7Id8j23+KZayelf5ZAtLC4 MtoXMgchA36cvgxjVGF7G2LqDl9B7px/TQBPslZHqPMfXR6gJgvS6jz1PUddnsj5zcvjkWz0 6BtzH10eoOZKXhztN2rK5oC8y0M5x4dHx4W6L/77haxGk6Rtqnt2eaCaWzp+cW2cqL1HLg+j zTs7K7yJyWmUtZpf2uisRpTczO8T+XYvgdRp36o8bEI+K9Ev/mH5qZxs/hQv6AEXt7++dgPc cD5E6NuMZH5g6F4FlOixgXyfuuNGjpRtTmth68tvfh18vGpzR32ESs7BcCAuB+tHUn8/TdIg RLPw0bFxul22/nz2Nk7l5enh6dGZFSEqLrS3sajd7HEjx20YkBoXVmceS2l6hGyAvvza4F7k qRtlSZzm6L3MJ2WKPlkkWIXKVIq5ItNSu6ZxzvbG4ikpTJfX1Zx22YyVtvLszkh68bQ5vbIp SNzKg9ZEg8uKVBB54cxHzYry9ZSEn0VGYaugk9NQ84JejsGDrCBcwWqsYIFwbciJRQ4DShAn MnVztN5By9G972dMl32adFlAR51fKeoWXVplId5Rd6ce8ZSB3Cem0pu4UZBNM2yWGGOthE81 VTvofh+DaACGLDxHkynYmD7YypU42FYDdoYI8YrXqu6MAZnCtIHCBJJPk3h3DgMdNTHdTRK0 j5OUp2RjVnh9c4mho/hDMxbB1Lghlgbz+HiGE3zj5tXjDjpPsyBD6bzRxneuBDWxUIYJkUXn LBRDzWsy+Hu1RFdD6dlHsI+o8hGgRxtyYlEYtOIeDHZrCemI2wqiRS7Nlij67W62RPUslGgj dvVEme1gbpunL4DXjajFC8YBh2SgKTzCzj7nmiDqHea5ZMjDYLAV+BEKvdLEpHXDyg6YHXCV A17Fcm1MYh8rWAsuPaXqKXLLZokqaFEo9yBVCQ7rs5sdzFey/23FSIOhLNes5s5FnHrSP7hS XX2myGwGqjthbfmQEJUs8EuaYQkJdbq8zzxQLeN0g5XdCduBty/VvAgqsGaIljCnC0vbLqlw PJWRryZI7CDZYCe0qme+6FKVlOIkDuObAGiacr1NYKiBcLsdDUpSDLRFA1JjcrH7AlJNdpHa HVPXDyjDiD7hJRkJrGCa3KGsgnEXrCAcyVRFMjaPg6dR1UE0U8WlkaQJxr6K5O/cNIhnGc3j y+Ah4S9XsouIblgxmGrUWIJa2FRDWjYHML1y0MRLzZDRwpB2nAWJLsw0dosaLS2Hp1qsoAYF DJJQPgNkvQgDWIzjstdgr1HlNcoMqknatEg3RvdC0RYIwULq8X0ao6eF6k5BlOVu5KnREQVt Z4XSgJWrOxhc9cqs2cHkLll1hjG1SD+sIQNaNftPdYmgwufH3gzJmlxMXJT7JvGchtfATVPi XbreZGen1rCh+Y+T7StpAFuNzTpt0E0xDJD4vRjgRAAWE1fUPgLlp0MankkskXhsnJeRKiPV KqRawby2yA8DluoWKeUhStydCTkeB15APkRzGPbFCM1Wvt7Rsd4pw/rB+lGlH2tm1CLdgGPA 4OrRwQB5DvErTQGUkQrczpEVxBjrv9BWyL/u29fgMhzYMsua2zbXVjWUHIhHoK3VFILsiIbt aCz77fRXSxTvPyHV9CumAjdIyK/YVBnKHVwayiCMQVglCBMiOU6MeNYiIHaVS6li+AM0bUTj 4GaGLvciRBeoLAnCYWiDTeNpUX1C0h2BPSL72DgxK8f2lQPTvIw7qJG6rjs6SLraPGcfadbF GlkUjkDTO3pzVLaCr9SUjIPthBLsxCH7hbusUPPYajf4OUUZmQrKVMZB2vF2RcfFRtcYR8y6 6Lor3hJPuM5eq3HYfXSElK8r89lIUysFIZ9IP85AX8e3yyE1YQw9Ups89Eqo3fOSPXMgligI xMkQFZsUBLFS07P3gj8fyeBmMorboPLeMuijGA3AG1C5mWLbCcS6E4fsmVVt0ncab9N19P2E YDlpvQYhlKFiWA6l3zzmeistWbXVLUtQRznOqY029xWaU6a26fl7hT5MInYFzust9iiWEmo7 hGBImSUzGDKugj0zp8YDrLv8JOd6lU/xQnKMDFcbkw1xqdCFvo7JQ7iGtiSyPQqQa/baMv5f h+jGQVkvWC9q9GLJnDQkpo+q4XCsyWPA3cwLHpL/W2+E0zC+fmGJHZVeFWtOk97rbE3AsqgB HYggp6aFJM6yoJx/HCd5MA3+BXdHmXCZIpePLQBFp+F62pI9G3u2Gs82L+uMtuoIem9R7VE0 IaqWKmVA9y3g7dJnq6VKNDO8YE/Qh4zjsnqwetSoB0ZgmTPm+wj5atwHjWooqqSkDiOsGEMn HHRExUaMEhklMkrEUODcsRwlrhBmlTOcjoKI1PzobxX0QCIOsu/reGCRJWUIjasU/doQGouc YJkdJ9b4sqUVJ8vl1/wgk1gMkgd3lkwaDN2RBNOpkbzc41KFIUaMuxl31+Du9RDNIouzFncy 0GagvQWg/aGY/zOSMlodAqR2RWUypyFAK4K5OhSFIWHKfdfzveY1ass1n4YXt8g000xpnTf3 l3CQsiReiiFBmNln44CHS/m7BfQV59oQGwZ/2wd/xgXU6G3X/FCLe1L+d5bl2LW1GCkGW5IF NyoZ4+pFXN6qG15Y1GJllHE9O6EffEgQZp/E+pL2N3n26vjo4gfCG+rkfd7RMn+DvQ43eNI7 N3y7l90dXJ2vMubozKUR16cpFrSXR3Ro59z3tfINT0S/zvJLrG7BmEN/gGV07zC2/vY5PUle XSb6LJFRclOMu8JSrly4IeaK0pdhjCp8RQN7t8NXkDvnX5MAQyFaHaGOQd3lAapvyuor+c3L 45E0lyXUSZVFV/LiaL/xWjZ33XQpZ87x4dFxoe6L/34hq9GkOZsIwF0eqEZxjk++NfYoD6PN OzsrvInWNMJGZzVK8c/l94l8u5dA6rRvdUj8EvJZiX7xlKE5Ozm5OHu3AA6Gq9WfexIXhERd PD5Ply+nv752A9xwPqDIlmIdyEEba1IfdnZpT5z3qTv+c4u9unz8GnO4sPXlN7S3pc0d9dEv OwfDgbgcrB9J/f0USzhCQT7OON0uGxc+exun8pTWiPbS/hj6WBEGbIbMW2kidtoMpNiEg7fy lDUWPi/2aN7rHSGocKQS7LCm994ANLZyJMcN5R0tT/pz8ftWnrXu9aOgFEkPYylpdDiI5x6y MNgG5eKnc+MO2tvj8jw2AF0cqs9TAIwL6KnxWVQG2jxsHS7rUgUwtY74BrEXY6FsLLJZksTp gpCu11CAlUBmFp/Qe3+ZLsN0mS3QZd7dU/lfiR5sdRbQCHGamlyI4wpTBmNd6IPeyrRVQyXZ gH/fAof2HbX1CkR2xgX01IAvRajN0/bRgivMqFZlCax7vV9ZEjR374lPppSGNs+RGukuBOO0 rBysHFVjRuxXDprKS7QxzBql4fQZ6YNLm5GjTOEcWpeMD6xsS1a751g7Om69MS6gp67DisSD g9SCtvlEOJ6FIFSWwwhSOZYp+AdiEcUofpNC+jWqz56CPUWVpwBE9/5UNbrLGBhDO6AFM+SB lK9Ax1nqIpqI/Hngwz2k8vcZaCq+mE9A2sfvaAsj1vnOMOHDzH2xdrB2VGlHPsFU85tJG6fW xwhjTrNHIP9Ln1DMZyNg5Y6CsEyelr8WoxhK495gN2NmlmRZPVg9qtSDtgLYqhs0v1MN8hy7 QTij1dXzIAfMohW9SFYpkjklTqEqY3cW5uCaL5KqJsuOtYO1o0o7IDq2Kkck4TWorFZOfpJi ChUIVA53ueOaYvAMYcrnSYDkruqExAy1PJ3t4rJIlOR06bAgznUJjO1I4VqsIE2K3Ys6fznN ECiv1eP2EcGmckpwdLXCKeGmMW5rmfqYK/Pjy0RGPjLlxlnZN7NvrvLNsySODEGpSVX2UScI kmL5tRjPIpUbd1Uc9wXQFXgcfjuIBG/wnr/5fkVu51qtA4VN99B9qt6wITtsZNjIVBmZOzcN 4pmZabTIzvixN6Pqc1aIP5kdL45T+NhiXzSljRT9aKkYVLUjI+RyhNz1hkzDQtVIXX1PyFaC F2eZl2zztH30xdb42o9BNCgi96ZXrUKXTt+1c80kxadJUmSk9GhIyfkBmbgPp59OxRnoMgHm EygvbaKPnXj/O3HInqUbhxNkfjVgFFP3FvWUKFYVeJmp4XgkmmzWn6ZZ75kwforRCoTqxeXF mTj3gzxO3xTViZJMCPkEO11COqfxHcJ5UNATcEL0XCk3Q7hvoCS2KI/mtmoavOwoYEDATJNW E2eVaHonxIgPCWv4JCaOdWPVnVdEfJXeDPNC7xnLwqK0m9NSZmx0DbrPc1pgIvrcvjqMCRy4 vl/UUsazHPQgatHJ0Ihg2ns2dk/F2O3ETXZk0X+ERT/1bqN4Hkr/Rqqawu7ha5aw7QcRQyI6 z0DrTEHvVC00YXCrYkO0jkW3GMYZgkgyxdxE1WBGJa5cutNM/IW+/SUOIiZCd13I+hynt9QA O8TF7Cs+Lo3TEmr4Ge2h1ET292oWtPoYUSA+nA8vVNkeN7l7xqYbS18bzA8P1J2d+uLn2BM/ oakiUXc0/MfB8K/47i4OKRGDayO98+UYG9ao7ZNXZ/DqDNlmdUZJQSgmwxvqvjkl0ys9QYuz UpPhossZJdsxuNUcdDzNvDlDwi1DwteIRNasA7p9KCC5xBx6qfgwyKAE/tu9o8NDGpfbjYHA aFe1bp5WJ254XuSVa5+WBvpenB4fn53sqVOUb/oqv0evRjlw/6w8O7WTS/QBlwe+wPZG4GXN oDzF1p6QpgKXc4mLv+PdQHzL6fv6Jep/yHwq+lxXb7IGklzqJ+X6+NM0rd3obY20CfEFpaKT w9eH10IMXCyCGDzbF1dzhJ/xfF/8hL9QO+LpM3GaY+Dzvti7wJYJcSkBlHPTALDL2LLLMAcf n3/FHg/KA6uWlMur/xkcDM/V8I2PVwMxnEWRDLO9fVV6pvveN6w3X16nl/cryv7HSGcwnGab //26Qzba/JcvXhzB5p/eYAMQzD0MA2y9YRMq4lPFwO2am30pbydYL9DqWbtlC++Lf5YO9PyZ uIyxcxwOVAXS/0iyHIOBp8Yh2Ah3aoQ/0o51cYrJzTcRBV4K+YCyqvbFXxUtVp4oPnWVuAhK vtWH7sBqma20adQauBVoZGjYA+zd5Yh8h1iAZIb3xenshvz/j9/q/5+eQLW3hXz2xV6kPlNr GjZC0X2T9ed7x4tAkkoR9WpXXz0lSlWHJnjDCqtq19JyY2YX81b05ktRrlsU5FfqlvyJ45ff uhbvKYneNkDKd1h0x6/87d5ZDNothqt8alF03aDWy81072m92wpOLL6l4Owx14pZfJXtPTMf cmVZ5YCc+IqhKddGJ0a5axBiltAQU2LLOtfjxMEaY83f6KrYw9LiUXelxWqXC720Y2bMcHAp fzeLdnUZtE6zUtWvGalAO7J/n1B4jtaCekxrqNia2ulbdg5+kRHYgSiZvUMO8JPrS3e2L4Zl PvDsmRggzeTmbhp/axbJYjP7IA+zYiDLwn26VutfAwCtNxHD6JX/Yl4t+SYG2IMS02huRQVX 5TPi/T3gPdHSB8IK35wCrLu8/xcAAAD//+xdb3PauBP+Khre3N0MoUDI3/mFKZDQtNfmGMj1 ru3cC9UoRFdjM7KB5j79b2XsxqIYnBBsCW9ftEnLpJJ29ezuo/1TrXYajW6nXSLzc+HxYe+i VK0etaqtWqfU/N/8fNITwR8D/8Fm8JkZtS9KPZty55Z990uv5D+KxWdE13V8Dz5DPYvzi1LH nQrOBLlhc/nT71uO9/PfWp76QfiBr8KfCH+G/7sIF9fviaXl7ei/np/75PvYPvcm1GIXpYlg HhMzVmoS5Ve/2yFHx0eNMmlNBLdJvVo9q8j1+4tdBL9P5BFZ7njMHL9PnRG7coawHz68KNWq tcUJTqINyu2pAlH3HH3ukt3Rqe3Lj9fPqmf1jt7yi2uJokmd8FzYHRPMsVioUEua1BKc2jEd WnwfU5XHA45+kHrCUqUehbHNaavC0fK2xHVt4FPh/ziLeni8kRbpcJ2+KPcFrrxw3bsrIa+8 /zCBy+dNmG0H+8hv9c3bXnf+LdVK4Xbnt87VoPWPBK22a1m8TD5UyqQtHqjjl8kAvu4K14Mv L+FLCrj0vkJS7TJvebxnM0GnqZaaq0CaZVL60Hs/OLjtKYuVti2wq9FVfAbwGwBFuhrurqBj NnfFt1KZBEb8rF6Du0EfwITXqk8z4SGobmNUqtXDy9MamvCFj/STCQ9OuFAmXKt7owDXo6cl XVnVvTjMz/A1zXAj/mh9MNyPWFIGPb21Gz5jTqqV5uocrPbWDt4x5xt3PPDTwClr2TZ1Hv2z t4b4Z+2px/UXQMw7I3A1lQWjh7YbVicltbLsoR0fnmz00LZxwbR3piN9jEf3cSYpNL7bnMFh 6+iscYhuaIIbGpzwwg0FOilt4BanvpZorW0J0nVX6fn+0KZIdLcbag6mYsZnz/eScl7+P2hE 4s8H+fLzAyDurXsmyuSmEtBbrQrpUiGY/UjLkIXC0a/c5v4DSk8f6a1wAepl8m7qsDUszTb2 zxgfYK83uY5haOTHMKwO1oBYf76lzfD5pfmeOz3h+szyFYhLem/JNS5uohFV3uD1MaLq29GM OuSa2TPXFfCEdA1sRXdq85Hj2vDQ1KqUFU2L4pc9x64fcUGGlzsRmmLJCoosVtz6EbyI5P2o Bw+QaZaZKzYlnPWnCvmLcWcEr+0M6LrozY8A7DIqSAi93HXCByegM07xfmiEcn9YvvsVkpWe nsIT+iTb4FqrW213TpF4SSBeghNeEC9oRbJnZb/0Bx97QQ4JZI7QocS3Ptj6z/fwAliGjJGy GSkjbSY814BXoeYiMeeaif9cOF+ZpCMzcwarsxK2gR3t490YzWqYO6VF0to7OuYGKPxqlwqc qD7zIIXYYmbgS58NmPhIfXDyNnmxgXbo6MZKP9W1XJv8KjH/N3IAEZ1jyS1RW9kU2uHs7XAs mhtMmMXvuBVomxfGFPV69QjsBZv4bCxd2drZ2UkBjQaqZvaq+QWSKBuN+gl4iQpMrCAatLCM H6jjcJZqqbnCNPiCV4uXq8sK6dEJHfIx9wV3p4F5tNwZEw/k10d6QbqKyrbwNmR/G2JADS6M 74oApn8jt0yAQ+ba7uiB3LmCvJGZ4SF4y9sjM5CFdS85iGME7mF/01N+lIIRK4bCkCYsuFOK o5KL2b68qZw2akFw//b2TwCVW6i58YKA07qnglo+E9zzueUR944MLq+Jw3yZOE8mi9ekZW8X 8SZXvFGwf4X11YLmB4zj8iVyCmWVaRacrwkGgIarcXBLgqtSJhFTDO71KaL0fqI0otjOUKzZ mvr3rvB+Ia3hEADAW8KAQhx9ITapGXv7iVKIl2LPtIrpQYns7Mav5nchSDpsmMEWXNMR1CSa y+oO/AL6KZqhjwI2KxxzLWix36lwmAF1WwmIYsQZD+7dsTDhiQi4R0IajdOjo2pVOVk0ldmb yreeoKyAT3Coa9nrWu/eddg5XvmcK2GuxpTb52T+EMQtr0fy2wpUfxZPMIUAgUJsUjOnfOCz ueyPtmiIVbyLpZk4OtyzXJRCznbnTwceZ4bkd6hmGKK14fv5wKHZzQ99Hc//GrQmfG1JJEBn Rzbk3cssiEI4O7hJQBmpwUruvolJO+kl2Tmp17rHUSVXX+fMpPk5dBYbgTiClt7e7GBwJavr Ya9BvbHcc8g9RCJbyDHc4g7awGxYkfxnz+8zZwi9ooc9eJRpC0a/wZoTG+HEazKZT6hdWeTm KU7m09n4HI/Ab159n/AUiTNrawzy3MBuyPs8d9QMU4JSaVVSMlOeG0gQySF0XNu0p/UJZXlu qgmtfOuxVFz55ReJGmm2ZJCU6sfPbZcRSieCdzRWcBKpp1RsNFZfZSuIRQv7CWhdZFsDC5uy 9/c+Cgjyhp/U3z9HCFnjbjTfOpAZDbnQB2nQJLmxRo6785uXgt5t1w4oz+UnGK0lxCeyxiKN jHRE/CaMDSD93vKWgu+jiTO1urK7IocquHcIZSJrXojiGS3xR7mP+RCtzRsYveWTqP+lsqL0 tyQcAxZplM7+IWxqPWsRG2kWfBA+n2E33hv3G6dkwBkMAfNgIFpQQqXWvqBYss90OdwY3mqR lnlNHQqdxZRbnERaJbkxeeo/5B+bcdA3bLaRHVjLq+V5yqnUIzkSyWTpzRv2CxtTc1Pp28op I2Znj9mKAJJQMG81v3bVLgxJ69QRrc04YOpBebo5afRH9UZNOViEjuyhA5PoIerZ15SSfALt RBIyzGhyZBxe8cI5FK8dz8Gspr1VQcT07DH9kkIjLxtG03eYZVGY7GKr9Ysok+xlciWgX9By r10URPaC+AikI4w8UhzPpFAk75Dpho3AnzeXfqm9ainnjPqevb4rAtBV0d8wx53RVEvVkB7Y nBGmBWU+gL6LQvUEkvRBw0M2A7F7ANeQBfMUTUZQzB4U3/rULuBcQ1S17FUtJD2GQUzGKtaP kOw1dBENQgJkP5D9iOpbMa8k7NULB2F5F6X4OOhYIU5icQukAV5yNnJJh874yOaqT4n4lwP+ IfGxVO23gyoxUOwwgyu5rTUSH9lltyHxIVNtM0mfSXxtShWD5c3wIfHRqnVKu0XEJhIfuz9j JD7YPCpnk06WdDVDZyvy6ZWS/92qfCIoIvGB2R4eKCT1LM7V8Ar+NnWhZxp/MyI+ZDhWscJw DEmPlGWuoe8UYYdJdSYYZWcfZXcFdSwGDaIIVPAMMeND5B9/bJnx0W3V652GyV1zAk6iIydi M4AxPrwo1apHckM0mHZyUWK2S2E2n/yrIfXZRUl2pzionh7Uj25rx+eNxnm1+nmXwcHCjC2W mKLLj1bxrOykEOskFarLDtzKhKYOq6QbNHnSXLqJ1PHL8GNayOHEgFsGcoDKp+3zm7Q48FMz DjwhLHw+W7mfRurMAGkm8gs63Ida1YATTDQE8Ia4oGW3zuvSQhY1M2TxEiytFuddN+O8E2zB lq8mWkjg0AwJNJEzT8mZa6FVQSxuanADNm3pZgs1fswktm3i8wM+P2T7/HAXEaOVu5AYxScI fILYiw7swMDlgOEJfiMhH6iA54clK/PUzqbZmKEOzNp+UiEMPmll/6RlhCa1bB8MTKqlhjVV qErZq9LLUPvZYNNLcOKZrDTBEDyfTA5XHdk0k1IeNDPFqfAIU1+h6ehcUkXPKTTZmhvO5I6+ BKmayUITwMQIRUYaLyWNl6cmEYLcE3JP2XJPlgwzK2MZF+OoasiHjzy7fWzDX4iwDjep5NwZ HLCgJFGS7I5Obf9nMO4t5U6HdUyTgf8APQXD2Zg9m3Lnln33ZdETnOVuSB2ppvInF0JdVzRj Wj9JMAt/et28r58niW6K1+R+dOwtFUyPCoeIknByJZGjHpPmJZL6yXMnDBpsNXKhuV5gZiAe +U+lfms5r3WX/seQv2BSXnBx4r/J0XK7nNBmsCgLYcQKsclccDC5s0vbJX9NFdOLUtiNP7ou Z/zz7RWBxIKJK6jPl6ZwoDyyl0ejq1wJLb1rv1nuX6ZZpo5Oc3vK7SF3RqRe/sz/hS/up5T0 XaqO+UHVz171b6gj5WHIG+WnKSiOT5+UkKWVBb7ksrGypY6NRr3PXu83IakWbbh7lX6lc88d tTXlCvMUn6pYCG0qxCa1Qi5Cwi4982nlq/v6Px8aFLvjiqVmNBZCLrhJ0EzMiw8Swl60D5YR RunvKbufGuyBLXmPhbjMmlkS5D/0qsdB/mPHLQ6R/5CmTccup8h/yJQM6AToZ5LwiPwH16PF vxGuJvIfQd1JbJpJhKLotWZPGUZdiimvfA9iICRBwHZgqna8gWyUt25SRWIhsAQ3uS+cHUoS JYn56LGEbky6x8oCZfohOCFPfpaQqCpdakRXRFdEV0RX+6KEdVsvNvwI0bXTaHQ7bdlCZT8y B9BOoiTRTqKdRDv5kg+HaCfRToZ2BRn0+FBs5HiQ40GOR6Row4gm5CVMyP8BAAD//+RVzW7b MAx+FUHnYrXdZA2COkCapTutNZICPQw7KDbjCFMkg2LqZE8/SnbaZtm1w4D6YPHf5CeSTqbp TE5u2nFTYDyWdDAg2vGzMrksjNL2EfYkL4MSOxu8c5Y82yhfap3LmduhBhT30EqWbqbWn0tL f2rIAS/7iHzGr4cz5sBB0OtqkcskmQ0Gd7PbEDeKCgzC4TTmfRR+gbXaGTo3L94Y/ydFco3o 3HqOyNnToYFc1qi2S1J4RPlY1kmt74h/OzbK0wJsBQhVoWq4RVA/45XT5Am0rTk5sBcCSCjz KVwcddcXQf1bPXNb9T3z76shsd+asW9UyeA2CB7wGeRExGe+bzSLxENJbsVNe5VeiCxJs077 8v4eYBDZ6MdJsR+kQ0Nrnk/bu3bg6nUcGkY+9A6DzSvpQ0B+LNJDScUL+uf7bHGyEvpbWrLT n3uuXv5ibZvLNMsGiWR6w/RwxHQc66b+piLirmH5IL0OJqjrDUdKh0kW2JUjcttXtYF1p01j PFC8LnJ5nYwCu3aO3rD1jiLbf650Jvwv+pEMLjGLypVfUVesMdpCoankLK8+RyeGpEMjtsDK VYdIsMtuC5YmvwEAAP//AwBQSwMEFAAGAAgAAAAhADXMdAAnEgAALG0AABEAAAB3b3JkL2Nv bW1lbnRzLnhtbORYzY7bNhC+F+g7MDo1wNqWlPXPqmsv0v1BFmhRY+1eeuNKI4tY/ggkZa9v eYecCmxfLk/SISU78XabSDkFLmBAlsgZznzzcTjD84tHwckatGFKToOoHwYEZKoyJlfT4I/l TW8SEGOpzChXEqbBFkxwMfvxh/NNkiohQFpDUIU0yRpHC2vLZDAwaQGCmr4qQeJgrrSgFl/1 aiCofqjKHsqW1LJ7xpndDuIwHAWNGjUNKi2TRkVPsFQro3LrRBKV5yyF5rGT0G3WrSWvVFo5 m/2KAw0cbVDSFKw0O23iW7Whi8VOyfpLTqwF383blG1WyzTdYDwEr83eKJ2VWqVgDH69qgf3 GqPwS2s3ADoVe4k2JhyuubNEUCb3ahw7nsV/H7w+Bm9Qrz1wqj45gljMPnGJbBKWTYPTAP/Q yhYKYwtcUeSf+5RRi4vEYRT3wkkvPl1GoyQ+S8LwTzfKJLOMcoMiXmeJ35DX2d00CMObt3F8 6fX6T1eQ04rbz0acFeVc+8fCbjmg9JryaXBZ03wJjzYYzM4H+2l+rq5F9Esid5CDxt0EjVwz l0qprCceTqg11qrc2tZtg8SUNEVPSw0G9BrdWRbMEPxZpYigcktqdAxRktgCiDPLeuNqD7RS +bXW6IPdlqjJlMD5wlLtfUBc/Foz3JnGtpK9xgigrTvJl60kJV1BnyzRoNo+stKqKokEyNB0 QlcawJlcqI17N4qvAe1Hxz6+/4COPZIhkVSA9ytnaFyt8sBEFwHvKpLKbWZnVfPXsQD5E2E2 aU2gN9FxEWh2izSpIX1CWEoOFjgSJsuQTebj+79PEOyn5pVQzvETURrDgrM+GzFKAA51hX7c Afrh+Eih/2nDbOE3Zga5z0tIeibJcDQ8fe1A5nSLZ26D/O4dN4kEi/nxwVx0hR2P6faMHx4b 7I7w8oFsMGlTaT3wdzeXPsVQT+qCGnIPIBHxfldoz1pDOz6602iGMDrSdsQsxjKyNR2H4ZHR cc6BGiBcqQdCazbuzifMAe641rvKgHBm7Kuu6Eb/Z3RvZcZSLATNBbk1uKH/cgj7CuKJyZRX Gbi8etE1g8ZvWoM6To6uZpjzSlPeGbP2hfoRYrbA7qviVHen2rAL1eIjy4678jRjuW+PLMEu xBeevhTtzMGWtf5wGZ0lp+0qn+s4Gv3yYrPYjLiW4/ttFt8JIRyg7qRJOcVrgpRyApq6ehMz pcTuKzqbhJg7fVN5cPygY8+bx5Wm4t+9I7PkMFb/Idmuc/z59YEVX+/x4pZl2XAZh0nUrsQY 34wmY785n18SNCPffdxP8CxU1aqwZKsqrIf1N18N4DGa6ntMcQdxeSHG/mqhXZAXV++IgLSg khlhXpHfNckUNvsGUncP9/wWQ2MNub/AGU2Gl2+jwEXAzuJ+RPBOiMT9mMAjFUxi5a9pWaK9 fsBYAO1fypIj/euLRtcQ/Db/ddFbzokbNSeE5XgLQQx2CUYd1mFfueo4gOWQrv8AAAD//9xX 0W7bNhT9lVs/bUDTyk6sekbjInUcLMCKBUmAAnujJdomLJECSUX1W36jwPZz+ZIdknJhOQoi F90Q9MWWJfLq+txzz7mUdvK+Gicqz7m0VI1Feto7jnq4YqVdKX3a45liTKbuVsosP+0Nov7g KBodDYa3g2jcPx5H0V/uqZDCCpYZbOm5oAXuaSPS69NeFMWj4fSs75b5W+d8wcrM7jzxO660 /7qxm4xj6R3LTnvTkNst/2J7byfv3yJwWObX6vq6bcs1X3DNZcLrffVaJqWyzAolsSBEDKHc u+3kklhiS5ZlGyq0i0BiQfhJ/ocLRyuWkl0JQ8Yl+srlBBjxiTguP/9ZY+qCNuEdnhwC7/An g/dcyYf7r5bWUlUOWWEJQBbKGDFH0a2iVBGTG+ArlzQvLZDmtBDLUnO3csU0wFdUypRrY8HM N4fiP+yGf3wbjcYn/U74zy4Gs9A2+/Q+PonP49GW+FeO8fXiF8D4bTvuZWXpS56NTcEStDua wHB9h56+Ua4WoQyMHu7/TlXpalZpVjzc//OGWgqxJwNNNK53ZKCJ4A/AyU4+r5gFX4qCS+Oo 5onkZIdUkpTa0JzbinNJFyBcSrNG+khcK7WYaQ2Q7KYAEkvN8hvLtNch3+yu7z/sbfNaMtc7 wtIaaAZJxZptmHbEPwvoTsB8zmnOkvVRWdAfN1eGFkp7VSqUhXJDd5voI+5ucWvcg8I1G2ab wcQrsmn+naBme0Vsluq/LeITuKgyS4OOQD/2CtAK9+O6VUqvCbTosrtTsTy/GjWySq1po0pK heaJhaNAuBwL+RJNZVDI6za4AfrT5hF3Ey9482A8jDuJ19NNuUOb2nSLNqP937z5d3bHnTko ia+tSycsS8oMo0ltyu5SJpsPTWhrmvvGRNu28+qSTGkKlApVgnYEb3qOINiQZY/5Jfkyc5bW aXsngr2iW3AnVwaZ5YXSMD9vnj7XTq95nKVd6R+YIVVOsCBVUhHcY80tpqYjpWHVcPOm7nQY lN4dwvXffjKue/fCwJMxveSvvWxI+JVTrUtSBdee8UL6aZSRA5gqb8+/wOuqYMsFT3+F+qSU rJhcYrwCgVJhwByMsQutcoqjiNa5E6b+IIrWeXiTFTknEBsEU9LvqiBhVDHk45QLlAu3U27R LpilvYW6SYDUHWZmF+DgevsxqdO5wx06utU7jmcfLxyPHg1m4ckLmMKCK0N7rOuetB6QM7EO 9Qqz7+tvs7DFSchNwkulDp59445nD8y+6KeTThCfXUQfp98m3N1xoH7yUiBu1/xtn7nWEDIV iT8akgrz4nfKKuzetcF3SesktOCfZ59okeGQFPoJ2RVa5Exv6Obq04ycEBhiSyZk0+ie19V3 g2666knQH3QiQTSKo+m0rc/qJy+FBBOcW54ravugL1WXfZ2cHKXE2B5001TCJu6wiyMUPVfK fwEAAP//7Fvdbts2FH4Vwhe7SlLJlh1ba1w4brJmaJzAdlFgd7RM20RkUaOouO5V32FXA7aX y5PsIyW1li3/BNiG/Cho0pg6pA7P+c53Do+UheuJ+ZwFiixcPj6rnLYq+I3GaibkWYX5gtJg rIfGVLGzStWyq8dW87jaGFott2a7lvWbvsoDrjj1I0yptN8u3BBjMuLj/lnFwlftfdPWYmbo PZvQ2FcrV8yMW2n+G6ilzyB6T/2zSjfRbci+qMqb9ts3WDgRM7Iy/b1oSp9NmGSBx9J5qSwN AqGo4iKAQLJispS+tyJf5r4bhdTDTkPJIibvsZ2rgMyXZCGkPyZqhlXJjEaE+gu6jMiIsYBQ MuaT9H4YUQs9eI09co9GisCCyadQ8EAdrVzhWIfo23CPHZHFjGPrZp6RJOay3rUye08MJIWY XEgJE6llCEWjkPn+QFFpTAQbm620JaPejI64z9XyoCUu4GdYJFug2BZEMW8W8N9jRh6+/UGu YJYYZvFEAGczCftAZyVghNV9aNH+zfXtu5wi2ptmXykC9b3zYGw2NWgOBKPjHATG827VOq0V gTG9otVIURYWIev/AmO7z6czZcw8ihVQ4jNPCZmAj4y4ImKCD3K8oIDkhDGfB1Ntew6IGT/A FYBAMDXjM0Y+Xp0DUsHDtz8VhE4e64zHMEO9+bKcURwNnSnliH78W0xi31/CWX9lHnn49jfx fBExEtA5/APPQRBEK5cEk0AkJOcAgG49sqeSzjcCu1gT7dpDlssHebScI74mIgAZfwZKxviO dGgANmD/S8vpZPT5gxjajwVOyzo0im3LtWovCzjtjCJn9J7B6yLWQa1mVP9gBD4Ho+p8RAa3 1xcpnSayhkUTXImQSZO1qI/E45upigNWQJKQhngFieIwFFKRm841UZJOJtw7IVcTLQyCABkE YvUaEfeGsDeVwISALEUMbRKyuAvEItEZrINEeBchV6UyY+aB+TXvhGCp9L4E+wHDkBuAHvfW aynq32kioiMBOTZFeo3Ix0E/epfPCsg/AOD32uGy3uh0WxUNvy3pWW8Raum8A4OuLKxZEEoa W0cwPPIU0tKcQlvPZ1RuCcOtt28rlCGPBb9tHYj++tBuuAfmsMtOtdp1dFStF1TplSeTw3oC qJNzYBfol1lNFuVdvr8QsC1TPu6vBBxtxfphHLJmxVswnmXZ3VrzsrBWzYvfrghvtfaH4fXH W+zaWEAxU1/9dzXsRv7YUhkOp+CDfcnCzM1ni23xh8iLxJyh5EB4H7TuRlJro6CUB009TCXN eC7pX3ZJvVF3NDcgM6+t/z3Oc47fQTQ9FPbgPvIZP/RWf5EiDsnOr/OTxxski+pNtdo9RFGw to1ir/8w047ljn9lAXYSHZGLcRGvoSTJZmu05wOgn9Mvk1s52+XFt8SLoqPImJyOsIQ58/ls ojS1hQKnyZbdSA4lECwUsJu16m6J6qnT3C1RazSc3RJOvWntlqg7rT2aNhx7j6anteoeTZtV Z4+mMNgeTZGRTveoalut1h5dbbtl7VHWrkLd3Vaza6fOPnWdRt2oq4/BKVqyg/8lKleUIi6N PM51tyCWHDVNjy00gGYdHEo3Rj2galXQHHmjrxm4qqk60deuXtkgMhvzcZbKxlhw/GmgNwe1 jDorvA4Zk5dzEaJR/hT11s2FPgP/olGhDylpyyVyE+rcSW/5i+fDHDVpg5jMmJmj5JA9UC85 RPf8cvxfcshqVfqEOaS4LdFF03gq5NIlKPmCMZpVERlK6t3lmWPj0/t/s256qqx7LuNgCpPk WLOgDbRWimd0+myyy2Z5iUz47KC8XsjL5+aH4gjdCL2NfT4/T23uaWVkLdqenRvbneFPdB7+ nC+2nnZEtY9yVi8rw3yRU54uN8q+8nT5ck6X1yfknClVtpnKNlOe98o2k/uq2kwfYrpgnAz1 KyTCF1POorIu0A82t/S2y7qgrAsW7kvtOhefR3uvofMzwMuFHp5R9sQdpzkKfHntn2I3kwFn eOs0wrMa81C1TAS6zVImAvPQt6wLX1ddODghn1ggckRY9ojyZ6WyFixrwZdbC7Z7w6F58yAO 8CcT+nXYsiAoCwL9Ek9ZECRvUL2qRtGAhYrNR3iVq2pZrUfXBU/7JcR/AAAA///sVt1u2jAY fRUv13RzfoAELUiUFmlSNyHobnbnwgexFuzUdkrbq73IXm5Pss9OUGlLCd0mjYveJMH5Yo7P OT6f2RVZ925Ynno5LIyHPwqpUy/sdCLvQ//jumdeqIjaMd1f0Y6Szv6KTuQH+yu6YRDvr4iD qAFp4ncakPqUdhug+jRJGrD6fkIbwPoBwt2/Hj/sRk1wo07bwf3g5NFWJjVW7jaSwmhUkekZ 56k3lKXioMgXWFtts4HQz0dnKPh2odNd32+MEdRw9P3QzuzMshnLmVhuxkCcfJ3axSEsBwfv RQ0La5Tm88lYpR6l/jCMR753rLiR1f4ErkuuYAWWTrkgTJDP44spuVRM6EIqQ8ZKLngOdrWm WrNbzzEv6tePn4/gWoEs3mIjjxVnNAiCYWTd8lyxzeAZLFiZm+fl4yfy1vpjiDiXvhQmuEUb dkUcNuy+oBs1bL63THsS8m+Z1vubTDvmnX6ZAZkzA5hbc8JKk0lFcq4N4RjhSorlu/8TBMXU 3OWAMeK6yFCubMBewq2ptr8u2Iy7jpJzAakX4RkDi+2PSZnjAC5FVqV1wzuoAVU5h9dZ9YdW ufoRZ+fz1PNpYP+oYir1IJcMmbNDlsXUC6gfnND4JOhc0qQXdnuUfrNvueCGsxwbKLh29ihJ KQ3PYt+WuSTdCs36jcveqkPuJcbirxvptul2cTmBBSgQM9huxLgwIaRhhkuBBXWLdlPZi+kP lowLYtA0gq1AE6bwSRqi+DIzLXIhS3IKaokHCfSP9RGgq7BMbLyFHXIyGpJ2EvjvdzhrP/Xh K6iP6EHUh4N2Erl5n1JfvzkW6sntKu9Z26PJCgUa1A06qdKj0kIAkm0kuQIyy2D2HeYt8ohi NIeScnGuFDrN3BU4ky4gz6eGqXpfubOh6aPA6qBPz9H77hRYfbgbpHOJWUsCc26k0n+K6pNh ufyXsDDyztgNEFlZGo3ZcjloMgVIIp6QFb8qjQ2aasNrMhBINlOctdDo6Gqc4lwofl3C6+3s zk4HJUncax+WJIMRPR3Gu5KkfnMsdu7bxrMhtQ4KNB20yFxirthMWTEzy8g6Y64ZPWi0qyNt 58bDs+7/BgAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQGwAAFQAAAHdvcmQvdGhlbWUv dGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rj gAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIh KU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErX l5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQav iZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2 tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2 cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn 8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1k WNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/ +On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/8 9uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc 9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG 7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1M K00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+ A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfC cVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxHal1CqnQoc 0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oyYftE+V2EO1l0u1wE9O2vuVt4kuwRCPP5 jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMeU8YGasrIDWmaZAn7RNCHQb3OnA5J cWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc7MxwJW2NhyZd2WNhUx8YbD2Q WO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb3YhmSp3DrVAZfDivGgwW 1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6clMeKuQmA2KnwkT7k nWK1EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56yMdp2xvDmRYe 4xS8LnXPh1kIF0O+EjbsT01mk+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0zFQWAizRnKz8 y00w60UpYCP9NaRYWYNg+NekADu6riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN2ETsY3C/DlXQ J6ASriZMRdAvcI+mrW2m3OKcJV359srg7DhmaYSzcqtTNM9kCzd5XMhg3krigW6Vshvlzq+K SfkLUqUcxv8zVfR+AjcFK4H2gA/XuAIjna9tjwsVcahCaUT9voDGwdQOiBa4i4VpCCq4TDb/ BTnU/23OWRomreHAp/ZpiASF/UhFgpA9KEsm+k4hVs/2LkuSZYRMRJXElakVe0QOCRvqGriq 93YPRRDqpppkZcDgTsaf+55l0CjUTU4535waUuy9Ngf+6c7HJjMo5dZh09Dk9i9ErNhV7Xqz PN97y4roiVmb1cizApiVtoJWlvavKcI5t1pbseY0Xm7mwoEX5zWGwaIhSuG+B+k/sP9R4TP7 ZUJvqEO+D7UVwYcGTQzCBqL6km08kC6QdnAEjZMdtMGkSVnTZq2Ttlq+WV9wp1vwPWFsLdlZ /H1OYxfNmcvOycWLNHZmYcfWdmyhqcGzJ1MUhsb5QcY4xnzSKn914qN74OgtuN+fMCVNMME3 JYGh9RyYPIDktxzN0o2/AAAA//8DAFBLAwQUAAYACAAAACEAzTdZ2XwDAACzCAAAEQAAAHdv cmQvc2V0dGluZ3MueG1snFbbkqM2EH1PVf6B4jkec8dD1rOFscmlZpLUsvsBAmSbGgmpJNmM 8/VpAVrGFWVrK08W53QfdbdaLX/4+EaJc8VCdqzfuv6D5zq4b1jb9aet++Vzudq4jlSobxFh Pd66Nyzdj08//vBhyCRWCsykAxK9zNjWvYg+k80ZUyRXtGsEk+yoVg2jGTseuwbPP+7sIbbu WSmerdez0wPjuAe1IxMUKfnAxGk9ee5Zc6G4V+vA85K1wAQpCFieOy6NGv2/arDV2Yhcv5XE lRJjN/jetyzndAcm2q8e3xOeduCCNVhKqCwlU7oUdb2RkeR7dKZ6Pne1QOL2TuQJju1vxqgz ZByLBgoKZ+557loTsDE7VgopDLTkmJCxCRqCEWw/ZCeBKEVwaBMy+iiBmtdP+Nrp/pEj1OIj uhD1GdWVYhz8rghiToN5l+aMwEdhUXHUwAYF65VgxNi17A+mCka5gBpMcUH/cKRGbWjTVupY 9eITY8q4eV4cRkkaTR6aXRjPC/cb38psEq8obIyf+mkaWJki3JRWteDRewysahDaPtnY1MIk OexKK5PHj1FoY/470zj3ct8aAZTGj2KbWrKJi9yaT1omm9Tqk6dhVB5sannp7QprprskKA92 pgi81JppEUVlsbPtU6SBXyY2Zh97O3ut93m6j60dcgj8ZGdnyuAQzp1731Wll8S73BZBGSd5 8Whl8iAoxn3WUwtDL9NMz5+/hFmVcB8cOl2aAtFadMh50RMKLgDNavG663rD1xgmJX7PVJfa kKvVREiKCCnhzhkChtPEtJ3ke3wchckLEqdFeUyZZsKKwg3//auaHiJY/CLYhU+qg0D8t74F 2GzoR9Gs1/XquaMGl5e6Ml49DKp31KVv/7wKLbheCjRkCt4WrCv0jPqTueG4X32ptOmQNURU +v3BL4hzGC5gUp/8rUu601n5eogp+GqReB0/6lMwc8HIwZfmxg/U6MzAel5og2kJVvNiwUKD hQsWGSxasNhg8YIlBks0dr7BZIbJ+wpz3iw1fmSEsAG3vxpw6/4Lmoogz4hjOFc9haHBWDYC 81iWzjXDbzD2cdspeNp511L0tnVDbxqeszVBN3ZRd7ZaSRvzO9RpkULwiIxHdecMRwfPyH0s Q9bipoOGrG60Xob+T1PgpJOqwhzeB8UEpDw+HD+Pysu/jad/AAAA//8DAFBLAwQUAAYACAAA ACEACRKOUToBAACkAgAAFAAAAHdvcmQvd2ViU2V0dGluZ3MueG1slFJNT8MwDL0j8R+q3FkK jIlVaydN006cYPyALHHXSEkcJVnL9uvx2gHj48BOcez3Xp7tzOZv1mQthKjRlex2lLMMnESl 3bZkr+vVzSPLYhJOCYMOSraHyObV9dWsKzrYvEBKhIwZqbhYhJI1KfmC8ygbsCKO0IOjWo3B ikTXsOVY11rCEuXOgkv8Ls8nPIARiRzERvvITmrdf9Q6DMoHlBAjGbFm0LNCO1aRR6XbeDqz rtCqZNPH8fj+YZpP+voG1X6pW6q1wlD/jB/RVoQnqNNHNv/MPutt80d6jf43doEpof2RJz8L FY5vpC+Oo8kyAsZDyWj+FHghadZ9LNEgzVXsEg42zJmzy5ibb44u44bzzi+h8n4JfdNDWM2G s98L+qStPsAKwyJgFyHQAqh+9reqdwAAAP//AwBQSwMEFAAGAAgAAAAhAATKPwLuEAAA8G4A AA8AAAB3b3JkL3N0eWxlcy54bWzcXVlz2zgSft+q/Q8sPc1UMWOToiQ7NZ4pR3HGrnUyGR+1 z5REWxxTpJakcsyv3+7GIfCACJi096iKeeBqoPvDB6AFMD//+m2TOF+ivIiz9Gzk/XQ8cqJ0 ma3i9PFsdH/34c3JyCnKMF2FSZZGZ6PvUTH69Ze//+3nr2+L8nsSFQ4UkBZv87PRuiy3b4+O iuU62oTFT9k2SiHuIcs3YQmv+eNR9vAQL6P32XK3idLyyD8+nh7lURKWILxYx9tixEv7alLa 1yxfbfNsGRUF1HaTsPI2YZyOfoHqrbLl++gh3CVlga/555y/8je6fcjSsnC+vg2LZRyfje7i DbToU/TVuck2YTqCmCgsyvMiDlsj1+dp0Z5tWTQzHKHI4i8o9EuYnI18f8RD5liFSlgSpo8i LErf3N9WqyKDFvEK5If5m9tzLOyI2inuSnu3svUsVU05YAIwyC0zKKguerjOlk/R6raEiLMR gIIC768+53GWx+X3s9HpKQ+8jTbxZbxaRYgfkTBdx6von+sovS+i1T78jw+EBl7iMtulJehh OiODJcXq4tsy2iIaQF4abkD0J8yQYLGFIocqtIv3tWEBNakU+C8h0mPabpWyjkJEvEP1bwrq Xa6PDbCqydg6R2CdY2KdY4o5VL0TCKwaNutfBFBS31pQvZ/XkDJbMpyo2cenB9CFOQgBVjkI AVY5CAFWOQgBVjkaCOhsecPgnTka9u3M0TDnwRzLkDjGGP13cZlEmHpAZuDc7HwO8/AxD7dr B4eiOrAPcdbtblHqK6Zwo0estns2id2WeZY+trdfEQPDGXbLZ4u52GzXYRHDHKBN0aqgnmR/ Fy6SyPktj1edoiYMWI020bjdOpJ8TsJltM6SVZQ7d9E3ZlGL/J8y53YbLmEw6qxcT7Nex4/r 0rld08jXKWyqUbpeE6z867ggHTS7jmLRqaYpXYUb2XCqwaW+8I/RKt5thGp0kwK1/oyrLcxc E0FVPKyiAE3U7F2drUADmDSBDQX2TaDyDerPBg778tHGJvVnw8wzyzeoPxuUnlk+4eOwfa2Z 5n2YPzlG3Wtm3XfnWZLlD7tE9IFOephZ92ApwqwJ1p1Ylm9EEjPrHlyhT+d8uYQFlAlOrW2x 51ELKdbmYFKos5m3xdooNdrzLFpkbaCaLN9CVj+utRBkTbo30ZcYXTW2gwGxtJxrtnfnBrfB gGO0tPtjl5Wa+bEySPoahjOVcpWCj6KIHDNpY00/M5XG0cNGNwuL9hvmLAT1G+8sBPUb+CwE afChn+HIEdBcSP+h0EKWNQnLMYtgZ8zDM2seloLsCH+gUdJgtqXpvXosNEdJAynWBmqOkgZS rK1TG7nkKGkga7BR0kDWMKOkgSDrUbKVvA0EDUPeBoKGIW8DQcOQt4Gg/uTdLWQ48jaQZc0N klNV8jYQRElsFvZSkEreBoKsuYGxHfcQiXGPSjm8lB2AvA2kWBuoSd4GUqytoyNvA1mUxAYJ NVlyiWMgaxjyNhA0DHkbCBqGvA0EDUPeBoKGIW8DQf3Ju1vIcORtIMuaGySnquRtIMiaHqQg lbwNBFESG25oJW/q9S9O3gZSrA3UJG8DKdbWqRGqnHkbyLI2UE2WJG8DWZTEBgxcFoHbplHD kLdBi4YhbwNBw5C3gaBhyNtAUH/y7hYyHHkbyLLmBsmpKnkbCLKmBylIJW8DQdbc0Ere1Blf nLwNpFgbqEneBlKsrVMjVMlzBrKsDVSTJcnbQBbhpTd5GwiiJM8VZNOiYcjboEXDkLeBoGHI 20BQf/LuFjIceRvIsuYGyakqeRsIsqYHKUglbwNB1tzQSt7UR16cvA2kWBuoSd4GUqytUyNU Sd4GsqwNVJMlqc5A1jDkbSCIgNmbvA0EUZJnCKJeZGOmYcjboEXDkLeBoP7k3S1kOPI2kGXN DZJTVfI2EGRND1KQSt4Ggqy5AXfVwu5Q482ongYEpvsMxK4GY4G+xkimAnkDb6KHKIeTPlH7 XhBl38a4p0DRQguJGniYNvFdlj05BzZtq43TAMRYVLxI4ow2cH+nPTlq2bMDZwLufp87l+zU SSMfQaq68wYO9qhndOggEZ7WgXqW37dwTmYr9pFjaXB+B8898XM3dE7rCk7h8LM0mBkP10BC OnPEg+m3dS6VnuFM2EqkOT72Zt4MNhqwmM952+mp8zxmR3X4sSj2TjmKv5QzTgHXS/WM02/v MFg5wUT17mipbBvXpUcnidTW7Y/2UEXCJA4LOOPF25547tpzLz33Bq+eexst6fgRL8698Nxw u3VkIe7l7stule8WefzkYiLHc36Yr+FAAez35ql+hCI9N4E/XQIU6kMKX5vChxRjSDHWpoAY zO+hGEzm0VuAD/g2wQd8m+IDvs3wYcpUvwAdrH7HU1YNBKSwab0tPInTJxGO7YId6h40PGcF 7s+QiDRwPowUboYoOJ+Gln6Kou0nqADlTHcbFgoPVxKJE44SGVuGCzrgB3chO4keSuwH2wxO 4XnjYwIcIEskLdgOe0ixiOB8InSf4OSYVTfbldDS6PpLIgqjCMjMqwjnCLGmC6riU5RLJfon rATlgB8PaR7mg8w9ge5rgc77aA3ol4AogJzvCrASP7q+ewMg8j33/tP7i5ub+3c3V/9wvDe+ C2croxxJxXMvfPc6+hIljk+MBckpC+DOB6T5iDsfkOYj7nxAmo+48wF3PuLOB9z5iEL/BB/w 7RQf6O0Yn/DVpycPr1AZCERY+2N6pICAHilgQo8UMKVHCEhwlztveQ3cAqzMOiq832Wr73RG g2zZAnB/cIBL1MbJHmF0ygfwICOb+BzD+QuqZROfIncVnwoKBfoJuSDmObw61sJtzOpVg9t6 7AIaxnsY+e59CohizOm7F0Bu8A+tBumQR8fuGqy7HgNOx/gcwN8E/qbwN4O/E/gDUEACvFBS gACkwQvgAFLh5RT+AJGQjArCS4CXCV6meJnhBZAGF5QDGIbiSCJeJniZ4mWGF4AyJMELVSig WuFlipcZXgDkkIRoCWihSqwcexyYVtgbvw72qGoq9poAE0m0ABMJ+gAs0AKMzxbqAAvcj+GW zfLcy8ANLt0kYIAK3M3aS9yP2WoHE6Q1G6tgnE7C/DFyfvBOnG0Ww7HvHxnwIK+7RighTgIw Oho5AKMGAL0AIRcg5AKEXEDpEHIBYDJAoAUItABhG1ABCLQAwBogugJEV4DoCqhkRFcAEA0Q VwHiKkBcBUwkPiGSQShegQTdC9a72mHFu54VrILXgRVV7TCsRJIqrOQYLobdPqCaaEHFu2sd VBM3AcNvXHZEMAkXUQJg8utYghEPKQtSI4FN3Il7dRt4Yj4PAZeTN7zrT1z6koCDKSH4kDk5 0K3MOXkdc4ohpGWECh9g6ns20o9PIm/NzvOCxrOY3ysLBJqlAno6bL+E6We4BPEH1jz8nK08 +kCnbHECp64RNIdxqYLNmS0/lLt35rJ0leMTEKQfaWEays4Ta9ZphL6DizWHkjAwNSsopt5d NZTHO6gB5SJhU1t4uEpxvg1f4aCtfGyFufoWMoEQP4+S5GOYox7LbKtPihNxFusdk1uuVtQi K8tso8+f0xlVqklbAaBitTLsFRuh1z0geBHl/HitRv+fsmvorQ3ugKO5FK6BhanW9XWr4Hm5 K0A1t7jIr6/jObWw5VcdyzwSxrs9NdRoLmFxsMSkNLAuZPcb+c4faqthluqCR1bWxbyg/eKY ByBNtqyQWeza40XBWvlweh4Nq2aWDpbOhzOw6Fa2bWUEsmnLCoD3dX0fG9JJsqBamK0pK3wp KLaDLys+Iuk5kaugOpIwgp1hp3rV5iCq10hVnChujz698roJSq9ePpzsl0p8IPJ8MXOgFP17 W6VBWh0RHHvgTUhhRRirTK8fwgIMobUvHL2Oj86Sydg6u65bwWRqX64x2SWngTW/J/wO4COP HDk5GFPwmBt+BxcDC685Pljg3vvB3i94LtUPwmLAXyEeJIn5YxkkIwMZJCMnMkhGTmWQjJxR UA9kcTXyNageWUNCyYjJ+Hz3OUz2HHw1XcNVgHGqb0cYrMeYKcHVJB6aIPNcEcdhRu4pMmDD w8ZDa0hDbxuPaWANCxOR6CHj6cBNJp/4sIgpGaaoAvt4hioK3Mcz0PHm11heP1jqgZTQp8No zPg/xhTzz+g4i6mc9doaotacAPjtkt8lEJiJK+4ysi/4zNg9EXfynrEwhLLDw8ElxQLBLSUe ZBSnGnB0iSjOOeDNEiEn4kEwGhQki9wXDite6AI5eL8m8mkqn2bsqT9xcS+HHm+vBbL6L1gw teiYcFnSFEFKT1PMhu00xUHluTwR+F7JOJ7igeUBqh+WB3FkAbeJXOTYEC8KuIAHOQDwSbAR eEd5SeBtlU+CbMBZKsMYxjAvAxmVx5BCBe4fFTEcaP/TDPXi4GGOPR0fMau08xGnBOlOJWOB T5Xdg0t2T/g7IYM/o5+VxXY7W3mpyFOiZBYE7k7xIOgqYHBCx6iIEnQVCLoCJ6mIk+QEPloR ti9UkNMFRfXnIz5teR0+al8MvjiYmFtRByZmi3YwcTslwl4bZhDFocoCwKvKHmrI4aFEOaIs crKy1Dyo6m5lUYrPlQXsHa8iAd37I4B7cV8HAYuao7QTEYbO03ZnwJx/GrFuevHJxC5PgOq8 Vj0Eel2Z7Q/gq9kFky99xuA5ZJ/N5b+ODvpLO9tBVNcEC7XRQ3Vpr/pKqCycQzFMNpXk8XaZ KanhEhG7G/yAlxOTXxe9spV9EVXXfNVlcAdfcwYP5Cb8M8sv8XPH6GwXH0VWIy/4h5IxnjYA qZEy57IolQLfweeLeX+sWLYd5MLaY76WVVeOLGy4KdneNK0A6MskCor0Vrec2Lbq+7/VUrif rfKJ637bv9AxL3/jaXjuMXb/pdXWAWBIsuLdSe1sM+aV/Pp2CV95hQ1OuzDhn/kE3ANqD/XA s9E83MCGs1D2rH0I9Zr6Xo+GbuHz4UxMx3qlfUyAT5rGKe2TqXcFirF3EcsCD1Gf+DmlujWd 2lvtF5Pz43NvzoyqcXrO4fPyWRIWqgJFUF2DfJWhcgtsuTVSn+lyr9p+vVL7koyUw5TTJBqh 4/+MQhswNaWAip7l7xjzbIP/q8B+m3FdsWGaZvA9e/y6fC53P5P5B3B62f6UMZ/53ge+G5Oj dt+NxTZNFYQsrHuAa+/DXDmtvVjRC1ITA0tNJSo9qjMYpdxBOvNBtQgOVdUif+3poLYKZg78 tlpvUB1EPJ5Ir2//VGTZ9dAWLVUnbWejg7/ziImUXqHP7psH4QdnD/6EDdaN8VlBYMGTtPXL hr7U1UYjsgWmXL4JUgfozwvWBlqsdPdbS4CqTdFhlKfRw1TR2V4ner11gbSms+qo0oJZOwW1 I+tdmCRZ1j494XH2ExSl0L1e9MNnrd2dM5YWVdS77124hv+ARpmv7APof5Zh0QSwYYYNU/jV VVPHnqpzPfD0Pyup6FNkDQ29F9b3wPR5effx+jPMWeg/zymjVYNAMYFTSdHGn7pBvF78S2De m49PPvC5NV/swDa4gwc3TsU0CBKKEat6suNEeAJ0KfxZwM9g6FKMp1Pu0NWlCCbibIguxSQ4 5TM5XYopbBVmENalmI3F+RFdihM/6KgpKIz7eXRleMfHs46qesenpx119bxT2M1HCNMK8qG6 HUlg+3xXdYPpRLgzQRKgpXupnO3yGM5iwf/hpbDnvBqKFKoG1XjUYlpkurI2pdfWrljn2EZv 70u0dam92Fbt6dr1+EsaqTnXghBaJha//FsAAAAA//8DAFBLAwQUAAYACAAAACEA1D/rVVcB AACBAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAjJJda8MgGIXvB/sPwftEk35QJEnZB71qYbCMjd2Jvm1l iYq6pv33M0mXtWwXu9RzfDzn1Xx5bOroANZJrQqUJgRFoLgWUu0K9FKt4gWKnGdKsForKNAJ HFqWtzc5N5RrC09WG7BegosCSTnKTYH23huKseN7aJhLgkMFcattw3xY2h02jH+wHeCMkDlu wDPBPMMdMDYjEZ2Rgo9I82nrHiA4hhoaUN7hNEnxj9eDbdyfB3rlwtlIfzKh0znuJVvwQRzd RydHY9u2STvpY4T8KX7brJ/7qrFU3aw4oDIXnHILzGtbrjWL7pQIQ3Za5fhC6aZYM+c3YeBb CeL+VEKtWRh3jn9LndvCQXZvVc56x7gM9/X1hktBRCEwHep9K6+Th8dqhcqMpFlMFnE2rdIp zWaUkPcu1dX5rsCw0Zyz/Yc4r8iCksk18RtQ9omvP035BQAA//8DAFBLAwQUAAYACAAAACEA elTVvLkCAADqDgAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbNxX247aMBB9r9R/iCzlkYTLcina sOpqi7rValW19ANMYsCqL5HthOXvO45zgW5LYQsPwAMhnjNnxsdje7i9e+HMy4nSVIoIdYI2 8oiIZULFMkI/ZtPWCHnaYJFgJgWJ0IZodDd5/+52PRYZnxMFQA84hB7nYF4Zk47DUMcrwrEO ZEoEGBdScWzgVS1DjtXPLG3FkqfY0Dll1GzCbrs9QCWNjFCmxLikaHEaK6nlwliXsVwsaEzK R+WhDonrPB9knHEiTBExVIRBDlLoFU11xcbfygZTXFUk+b5J5JxVuHV6SLRE4TXozJlLey1V kioZE61h9MEZa8ZOe1/sUkBLUXscksJuzCoTjqmoaWx5/Lb+9eIFsHihix1aqmYioMUEignP tVE4Ns8Z93beHpMItQuI0DQBW45ZhKbuc49C68wzZugTyQmbbVJSYYpRZkcdyvCUVbZPw/uP g0Fv5CwstwYKjyoWlLwyFbjjUFDvU14PJiSmHJfU6XezYXXgzwTb/VO6AeuMvNR+fjP8Ja4i MLIwLkj6VdkZGdCjfFYYCI/gdyq1TRLmHTYwKqwyliVC3X6/Y4ErLJaQBWzqXvumxJfsygVR UymMBmgMlDPKifaeydr7JjmGVQUGKoAvIQsM+rr0MhguFkDAaVCSFmyQDEzUprwtZqdYuFOI 2XXxX4kZ+I3l+vXsnkzP3t/1DPzGeP2S9k4mabHJivrf3e9QoiBp4Df261f15mSq9vcWKqga +A3kbMJ2d0/U7k1xc8Ch958nKjDsOT77b1HxT0ekqz9QKvAHtZ6nEuvcKgzOoULgDy9OiOGZ hAj8pg+6lKIYnU+LwP9wAaUBu26rZ7aNFzSI0J3Bt22ZXee1hXi0HWLRulXNIyBfubkG42g3 d4ke7eZuiaPd3LH4bzeQCObo/qNOfgEAAP//AwBQSwMEFAAGAAgAAAAhAMmO82hGAgAAOAkA ABIAAAB3b3JkL2ZvbnRUYWJsZS54bWy8VdFumzAUfZ+0f0B+XzGEpElUUqWsPO5hyrRnB0yw hG1kk9D+/a5tkq0JdCHTShQpOdiXy/E55z48vvDKO1ClmRQxCu4w8qjIZM7ELkY/NumXOfJ0 Q0ROKilojF6pRo+rz58e2mUhRaM92C/0UsWobJp66fs6Kykn+k7WVMC9QipOGvirdr4sCpbR rzLbcyoaP8R45itakQaerUtWa9RVa6+p1kqV10pmVGtolleuHidMoFXXndcuBeHQ9YZxqr1v tPW+S07cgpoIqWkAaw6kihEO4TPDEzzFEXxD+BUh31TKSqI0bU4LsYMLwln1ekSVrWvX16zJ yiN+IIqRbUXdHs12cGOvtzhGzxjjcJ2myCFBjBJA7udR0CEhNOWuRYdMTggcEzRm69glgasD CNTpdtk+fXdOF4ysoa3KEnXJwxPwEFk+DCfhKB50y7R2L/uvPEw+goeE8C1QMcCEUYJThFHG OCZuUwQO/1REZI4yOiG/FWHPH3T0jiIWVlnXKyIBE8qK6AEqjCgWTg6jqeAyp0r0qKJgLzTv sUYAr31BRJr0EHGFNcYSsSElmPkdGqJOE8YjYzLiBm8AEeHz6bW7jJjh6dO5N8K/ERHg0RmR yL1iVJncHGDjHphwojCJGY1iY7QojCb68vJDcuInzBgzFPvtMTU+fXs5VZ/PjtDBb2cH2Tey xxzDo+P4pE4EIAtjGHOdy+KE9AbF3G06DpMrR0dCKgaZOSCJ1A5POzZG58RtBrlMivX/Sopu murVLwAAAP//AwBQSwMEFAAGAAgAAAAhAPk/mufpAQAA4wMAABAACAFkb2NQcm9wcy9hcHAu eG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFPL btswELwX6D8IuseU7EhJjTWDwkGRQ9sYsJKcWWplE5VIgmSMuF/flRTLdNtTdZp9aDicXcLd W9cmB3ReGb1K81mWJqilqZXerdKn6svVbZr4IHQtWqNxlR7Rp3f84wfYOGPRBYU+IQrtV+k+ BLtkzMs9dsLPqKyp0hjXiUCh2zHTNErivZGvHerA5llWMnwLqGusr+xEmI6My0P4X9LayF6f f66OlgRzqLCzrQjIv/dyWmBTAioTRFupDnmR3VJhCmEjduh5cQNsRPBiXO35p5uyADZiWO+F EzKQgbwoyrIEFmXgs7WtkiKQufybks5404TkcbAh6RmAxS1A1mxRvjoVjjwDFofwVWlSc10u gI2Q9Dmxc8LuPc8X1B7FsJWixTV5wBvRegR2TsADin6+G6FINRzC8oAyGJd49YsmPE+TH8Jj 79wqPQinhA7kYN82BgNurQ+OVyq0xE21MR5g3BZjdc3zoYHAZWNPMGqgwqW64QT/2NDdwj/E 5rHYQcMoNZITwemMP1jXprNCH+nwCZHFP/2Trcx9vzXvHl4mo9m/qLDfWiFpQGWxyOia5y2I arClbcGaxnpiPCfggQx3bX8s/at3WJ96/i70e/U8vlmez2cZfcMinXK0CtNj4r8BAAD//wMA UEsBAi0AFAAGAAgAAAAhAB7rjNCBAQAAKAYAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50 X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MAAABOAgAACwAAAAAAAAAAAAAAAAC6 AwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAQUIjRBgBAAA5BAAAHAAAAAAAAAAAAAAA AADeBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQAm2VOh bt0AAER0DgARAAAAAAAAAAAAAAAAADgJAAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAI AAAAIQA1zHQAJxIAACxtAAARAAAAAAAAAAAAAAAAANXmAAB3b3JkL2NvbW1lbnRzLnhtbFBL AQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAAAAAAAAAAAAAACv5AAB3b3JkL3RoZW1l L3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAzTdZ2XwDAACzCAAAEQAAAAAAAAAAAAAAAAD0 /wAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEACRKOUToBAACkAgAAFAAAAAAA AAAAAAAAAACfAwEAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEABMo/Au4Q AADwbgAADwAAAAAAAAAAAAAAAAALBQEAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAh ANQ/61VXAQAAgQIAABEAAAAAAAAAAAAAAAAAJhYBAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0A FAAGAAgAAAAhAHpU1by5AgAA6g4AABIAAAAAAAAAAAAAAAAAtBgBAHdvcmQvbnVtYmVyaW5n LnhtbFBLAQItABQABgAIAAAAIQDJjvNoRgIAADgJAAASAAAAAAAAAAAAAAAAAJ0bAQB3b3Jk L2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEA+T+a5+kBAADjAwAAEAAAAAAAAAAAAAAA AAATHgEAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADQANAEADAAAyIQEAAAA= --------------050108080005080808020609-- From loa@pi.nu Thu Oct 4 08:08:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471B421F86E1 for ; Thu, 4 Oct 2012 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, GB_ABOUTYOU=0.5, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcriw2Af76YW for ; Thu, 4 Oct 2012 08:08:17 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id B801B21F8639 for ; Thu, 4 Oct 2012 08:08:17 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 96AEC51419D for ; Thu, 4 Oct 2012 17:08:16 +0200 (CEST) Message-ID: <506DA662.7020603@pi.nu> Date: Thu, 04 Oct 2012 17:08:18 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mpls@ietf.org References: <44A5364BC1FA1E42B1F133529EC2C72902C22E96@CNBEEXC007.nsn-intra.net> In-Reply-To: <44A5364BC1FA1E42B1F133529EC2C72902C22E96@CNBEEXC007.nsn-intra.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] Concensus ? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 15:08:18 -0000 Paul, I'm not sure this did go through the list, so I respond to it. As far as I understand when we in IETF talk about consensus we do it the way Dave Clark defined "rough consensus". /Loa On 2012-10-03 14:10, Doolan, Paul (NSN - US/Irving) wrote: > Hi George, > > Yesterday, with yourchairhat on, you wrote: > >> The object is to fix the draft so that WG consensus can be achieved to > move it forward. > >> If the WG consensus is that there are deficiencies and that the > authors have failed to address them then we would not have consensus. > > The last sentence is interesting,in an Alice in Wonderlandor Bertrand > Russell kind ofway,but my question is about your use ofthe > word‘concensus’itself. > > The Tao > document(_www.ietf.org/tao.html_)still > references Dave Clark’s formulation“rough concensus and running > code”.Does this WG operate on thatroughstandard or thesmoother one you > suggest? > > cheers, > > pd > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Thu Oct 4 08:36:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3691521F86EF for ; Thu, 4 Oct 2012 08:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-8ENLyGlAwp for ; Thu, 4 Oct 2012 08:36:29 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF3221F8694 for ; Thu, 4 Oct 2012 08:36:29 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id C7C9351419D; Thu, 4 Oct 2012 17:36:27 +0200 (CEST) Message-ID: <506DACFD.9010903@pi.nu> Date: Thu, 04 Oct 2012 17:36:29 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: [mpls] WG last call draft-ietf-mpls-tp-ring-protection - closed! X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 15:36:30 -0000 Working Group, The working group last call draft-ietf-mpls-tp-ring-protection has concluded. The working group chairs has chosen to close the wglc even if there is still an ongoing discussion. We believe that there are enough comments for the authors to improve the document significantly. Nevertheless we want the discussion, in particular on the technical issues, to continue. The authors should make a list of all the comments and how they have been addressed, and first as folks making the if the resolution is satisfactory, and once the positions are clear to make the resolution available on the working group mailing list. When all comments are resolved a new document should be published. The comment resolution cycle we start now is to resolve the comments received ut to now. We sincerely hope that the discussion will continue and fully understand that new comments might come in and these comments will be addressed as part of the normal WG process. Judging from what we see now it is likely that the changes to this document is large enough to motivate a 2nd working group last call- Please note that the working group through discussion when merging the different *ring-protection" drafts and then when accepting "draft-weingarten-..." as the working group document decided to create an applicability statement on how to use linear protection in ring topologies. That is the scope of this document and we are not going to change that as part of the wglc process. I see three kinds of comments First, comments that simply request abandoning a document that is reasonably close to completion. These comments are simply out of scope. Authors just need to classify these comments, but do not need to make any attempt to resolve them in the current document. Second, there are a set of comments that seems to be directed towards this document, but saying that "this is not good enough". For this group of comments it is necessary that we get the concrete information on what is behind the comment. Now within this first and second group of comments there might be comments that really concerns changes to the document to aligh it with the intended scope, since abandoning the document now these comments need to be addressed and resolved. Third, there is a set of "normal" wglc comments, asking questions, proposing a rout forward and even giving text. These comments need to be responded to; accepted, tweaked or rejected. Please remember that the mailing is is the master and everything needs to be done in a transparent fashion. This leaves us in a situation where a small part of the working group are asking for a different document. RFC 5654 explains the circumstances under which other topology-specific protection solutions will be considered. We will use normal working group process to examine any proposals for new ring-protection solutions. /Loa for the wg chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From gregory.mirsky@ericsson.com Thu Oct 4 09:46:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD0621F86CB for ; Thu, 4 Oct 2012 09:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.779 X-Spam-Level: X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8eht3sXMbtp for ; Thu, 4 Oct 2012 09:46:14 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D851221F86C6 for ; Thu, 4 Oct 2012 09:46:13 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q94Grd3g004984; Thu, 4 Oct 2012 11:53:42 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.138]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 4 Oct 2012 12:46:10 -0400 From: Gregory Mirsky To: cheng weiqiang , "adrian@olddog.co.uk" Date: Thu, 4 Oct 2012 12:46:07 -0400 Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2iH77tuhGU9xymR4+EtPTt4Er41gALWlBQ Message-ID: References: <0e2901cda16b$09f5d1d0$1de17570$@olddog.co.uk> <0e7901cda17b$bafe9bf0$30fbd3d0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1392845B112EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 16:46:18 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1392845B112EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Cheng, et al., I would note that "multiple failure" scenario, illustrated in Annex 1 of l= iaison-2012-10-03-itu-t-sg-15-mpls-requirements-and-analysis-of-ring-protec= tion-for-mpls-tp-networks, is, in my understanding, series of single failur= es in interconnected rings. I believe that protection architectures describ= ed in the document under discussion (wrapping, steering without and wit SPM= E) can be easily applied to interconnected ring topology as presented in th= e Annex 1. I've noticed that, referring to the Annex 1, that scenarios with= dual failure on the same ring are not considered, i.e. failure at point 1 = and 2 or 3 and 4. Should it be interpreted as "multiple failure" scenario i= mplies failures in multiple interconnected rings over which a protected pat= h spans but with only single failure in any given ring of the chain? Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of che= ng weiqiang Sent: Thursday, October 04, 2012 4:02 AM To: adrian@olddog.co.uk Cc: mpls@ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-prot= ection Hi, R106 of RFC 5654 mentioned "SHOULD protect against multiple failures". And well known, the multi-failures recovery is a basic function for ring pr= otection. And the double failures scenario I mentioned is the most basic mu= ltiple failures condition. By the way, the wrapping solution of the draft cannot handle the adjacent n= odes failures also. I don't think they are corner cases. I give you some examples for your refe= rence. For the Micro-wave system, the adjacent hops often are impacted by whether = or other facts at the same time. For the adjacent nodes, they often share the same power supply system. When issues happen on power system, they may shut down simultaneous. So for the carrier grade system, the multi-failures scenarios I mentioned s= hould be the basic functionality. B.R. Cheng Weiqiang On Oct 3, 2012 11:28 PM, "Adrian Farrel" wrote: > > I'm not going to make any comment about consensus on the document - > That is the job of the WG chairs and I am on the appeals path for any suc= h assessment. > > It seems to me that there are certainly some questions to be answered > (that might result in explanations, or might result in caveats being > added to the document). It also seems to me that this document is not > trying to say "here is the only solution that can ever work in MPLS-TP > rings" but is actually saying that here is how you might get > protection on a ring using linear protection techniques without the > need for specification of new constructs or protocols. as such, I > don't believe that corner cases (and frankly, second order failures on > a ring should not be regarded as primary design features, should they?) p= revent publication, but should be highlighted as potential draw-backs. > > Thanks, > Adrian > > > -----Original Message----- > > From: cheng weiqiang [mailto:chengwq@gmail.com] > > Sent: 03 October 2012 15:53 > > To: adrian@olddog.co.uk > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection > > > > Adrian, > > > > Thank you very much for your prompt and detailed reply. I need more > > time to digest it. However, the current draft is really not mature > > to get WG consensus. Do you agree? > > > > B.R. > > Cheng Weiqiang > > > > > > 2012/10/3 Adrian Farrel : > > > Hi, > > > > > > Thanks for taking the time to set out your concerns. > > > > > > I hope this now gives the WG something to work with. > > > > > > With regard the first point, I hope to hear from the authors > > > whether you have identified a scenario where linear protection > > > will not work (in which case they should probably flag this > > > short-coming in the I-D) or if they can see how linear protection > > > can handle the double failure case you have illustrated. > > > > > > Obviously, we don't have access to C-2098 and can't take it as > > > input to the IETF discussions, so if its authors (was that you?) > > > want to take that material as contribution to the MPLS WG's work, > > > you need to submit it either as an Internet-Draft or as email. > > > > > > The second of your discussion points is related to Section 2.5.6.1 > > > of RFC 5654, and specifically R100. I reproduce it here for our reade= rs: > > > > > > 100 Recovery techniques in a ring SHOULD be identical (or as simi= lar > > > as possible) to those in general transport networks to simpli= fy > > > implementation and operations. However, this MUST NOT overri= de > > > any other requirement. > > > > > > I think the authors need to address this point, but my > > > understanding is that the whole section is intended to describe > > > the requirements that have to be satisfied by topology-specific > > > solutions. Thus, if we were inventing a new protection solution > > > applicable in rings then we would need to address these > > > requirements directly. However, I believe that the I-D that is in las= t call is called "Applicability of MPLS-TP Linear Protection for Ring Topol= ogies". > > > That is, it does not define a new mechanism, but specifically > > > shows how the general mechanism can be applied. > > > > > > Obviously, I can't speak for the WG, but it would seem to me that > > > nothing in this I-D precludes the development of a > > > topology-specific solution for rings that meets the optimization > > > criteria in Section 2.5.6.1 of RFC 5654 and also addresses the > > > specific requirements in that section. It also seems to me that > > > the I-D in question is not a protocol specification at all (note > > > that it is an Informational draft) and actually does not even describ= e anything other than how linear protection might apply in a ring topology. > > > > > > So I am not quite sure why you believe that the failure of the > > > generic solution to address a requirement intended to describe > > > optimizations is a reason to not publish this document. Rather, in > > > your shoes, I would see it as an encouragement to do > > > topology-specific work to follow on from this current I-D. > > > > > > Cheers, > > > > > > Adrian > > > > > >> -----Original Message----- > > > > > >> From: cheng weiqiang [mailto:chengwq@gmail.com] > > >> Sent: 03 October 2012 10:40 > > >> To: adrian@olddog.co.uk > > >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; > > >> draft-ietf-mpls-tp-ring- protection@tools.ietf.org; > > >> larryli888@yahoo.com.cn > > >> Subject: Re: [mpls] Working group last call on > > >> draft-ietf-mpls-tp-ring-protection > > > > > >> Dear adrian, > > > > > >> Here I would like to try to describe some issues on the ring > > >> protection solution from my point view. > > >> > > >> 1. The Wrapping solution doesn't work when Multi-links faults > > >> happen > > >> > > >> For each link in the ring, current wrapping solution defines two > > >> SPME > > >> - the first is a SPME between the two LSRs that are connected by > > >> the link, and the second SPME between these same two LSRs but > > >> traversing the entire ring (except the link that connects the > > >> LSRs). > > > > > >> ___ ___ x ___ > > >> =3D=3D=3D=3D=3D=3D>/LSR\********/LSR\********/LSR\ > > >> \_B_/ \_A_/ \_F_/ > > >> * * > > >> * * > > >> * *x > > > _* ___ *_ > > >> /LSR\********/LSR\********/LSR\=3D=3D=3D=3D=3D=3D> > > >> \_C_/ \_D_/ \_E_/ > > >> > > >> =3D=3D=3D> connected LSP *** physical link > > >> x link fault > > >> > > >> Above figure shows that One LSP enter the ring from LSR B and > > >> Exit from LSR E. And at the same time the link A-F and link F-E > > >> are both broken. According to current solution, both the > > >> protection SPME for A-F and the protection SPME for Link F-E > > >> should be activated synchronously. Obviously, it does not work. > > >> > > >> At the same situation, the ring protection for SDH, > > >> G.8132(T-MPLS) and the MSRP solution (C-2098 "MPLS-TP Shared-Ring > > >> protection (MSRP) mechanism for ring topology", ITU-T SG15 > > >> meeting, Sep. 2012) can work well. > > >> > > >> 2.Steering function is totally the same with 1:1 linear > > >> protection > > >> > > >> As the draft mentioned "we use 1:1 linear protection [SurvivFwk] > > >> [LinProtect] to perform protection switching and coordination > > >> when a signal fault is detected." It is the basic 1:1 linear > > >> protection(we can see it as a SNC protection, in another words > > >> 1:1 linear protection is using in sub-network). > > >> > > >> It does not provide any more simplicity and optimism than 1:1 > > >> linear protection. That is why we say this draft cannot meet R100 > > >> of RFC5654 the requirement. > > >> > > >> So I don't think we need defined it in the ring draft redundantly ag= ain. > > >> > > >> Best Regards, > > >> > > >> Cheng Weiqiang > > >> Research Institute of China Mobile > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_FE60A4E52763E84B935532D7D9294FF1392845B112EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Cheng, et al.,
I would note that "multiple fail= ure" scenario, illustrated in Annex 1  of liaison-2012-10-03-itu-= t-sg-15-mpls-requirements-and-analysis-of-ring-protection-for-mpls-tp-netwo= rks, is, in my understanding, series of single failures in interconnected rings. I believe that protection architectures described = in the document under discussion (wrapping, steering without and wit SPME) = can be easily applied to interconnected ring topology as presented in the A= nnex 1. I've noticed that, referring to the Annex 1, that scenarios with dual failure on the same ring are not c= onsidered, i.e. failure at point 1 and 2 or 3 and 4. Should it be interpret= ed as "multiple failure" scenario implies failures in multiple in= terconnected rings over which a protected path spans but with only single failure in any given ring of the chain?
 
      &= nbsp; Regards,
      &= nbsp;         Greg
 
-----Original Message-----
From: mpls-bounces@ietf.org [= mailto:mpls-bounces@ietf.org] On = Behalf Of cheng weiqiang
Sent: Thursday, October 04, 2012 4:02 AM
To: adrian@olddog.co.uk
Cc: mpls@ietf.org
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring= -protection
 
Hi,
 
R106 of RFC 5654 mentioned "SHOULD protect against multiple failu= res".
And well known, the multi-failures recovery is a basic function for ri= ng protection. And the double failures scenario I mentioned is the most bas= ic multiple failures condition.
 
By the way, the wrapping solution of the draft cannot handle the adjac= ent nodes failures also.
 
I don't think they are corner cases. I give you some examples for your= reference.
 
For the Micro-wave system, the adjacent hops often are impacted by whe= ther or other facts at the same time.
 
For the adjacent nodes, they often share the same power supply system.=
When issues happen on power system, they may shut down simultaneous.
 
So for the carrier grade system, the multi-failures scenarios I mentio= ned should be the basic functionality.
 
B.R.
 
Cheng Weiqiang
 
 
 
 
 
On Oct 3, 2012 11:28 PM, "Adrian Farrel" <adrian@olddog.c= o.uk> wrote:
>
> I'm not going to make any comment about consensus on the document= -
> That is the job of the WG chairs and I am on the appeals path for= any such assessment.
>
> It seems to me that there are certainly some questions to be answ= ered
> (that might result in explanations, or might result in caveats be= ing
> added to the document). It also seems to me that this document is= not
> trying to say "here is the only solution that can ever work = in MPLS-TP
> rings" but is actually saying that here is how you might get=
> protection on a ring using linear protection techniques without t= he
> need for specification of new constructs or protocols. as such, I=
> don't believe that corner cases (and frankly, second order failur= es on
> a ring should not be regarded as primary design features, should = they?) prevent publication, but should be highlighted as potential draw-bac= ks.
>
> Thanks,
> Adrian
>
> > -----Original Message-----
> > Sent: 03 October 2012 15:53
> > To: adrian@olddog.co.uk
> > Cc: mpls@ietf.org
> > Subject: Re: [mpls] Working group last call on
> draft-ietf-mpls-tp-ring-protection
> >
> > Adrian,
> >
> > Thank you very much for your prompt and detailed reply. I ne= ed more
> > time to digest it. However, the current draft is really not = mature
> > to get WG consensus. Do you agree?
> >
> > B.R.
> > Cheng Weiqiang
> >
> >
> > 2012/10/3 Adrian Farrel <adrian@olddog.co.uk>:
> > > Hi,
> > >
> > > Thanks for taking the time to set out your concerns.
> > >
> > > I hope this now gives the WG something to work with.
> > >
> > > With regard the first point, I hope to hear from the au= thors
> > > whether you have identified a scenario where linear pro= tection
> > > will not work (in which case they should probably flag = this
> > > short-coming in the I-D) or if they can see how linear = protection
> > > can handle the double failure case you have illustrated= .
> > >
> > > Obviously, we don't have access to C-2098 and can't tak= e it as
> > > input to the IETF discussions, so if its authors (was t= hat you?)
> > > want to take that material as contribution to the MPLS = WG's work,
> > > you need to submit it either as an Internet-Draft or as= email.
> > >
> > > The second of your discussion points is related to Sect= ion 2.5.6.1
> > > of RFC 5654, and specifically R100. I reproduce it here= for our readers:
> > >
> > >    100  Recovery techniques in a ri= ng SHOULD be identical (or as similar
> > >         as poss= ible) to those in general transport networks to simplify
> > >         impleme= ntation and operations.  However, this MUST NOT override
> > >         any oth= er requirement.
> > >
> > > I think the authors need to address this point, but my =
> > > understanding is that the whole section is intended to = describe
> > > the requirements that have to be satisfied by topology-= specific
> > > solutions. Thus, if we were inventing a new protection = solution
> > > applicable in rings then we would need to address these=
> > > requirements directly. However, I believe that the I-D = that is in last call is called "Applicability of MPLS-TP Linear Protec= tion for Ring Topologies".
> > > That is, it does not define a new mechanism, but specif= ically
> > > shows how the general mechanism can be applied.
> > >
> > > Obviously, I can't speak for the WG, but it would seem = to me that
> > > nothing in this I-D precludes the development of a
> > > topology-specific solution for rings that meets the opt= imization
> > > criteria in Section 2.5.6.1 of RFC 5654 and also addres= ses the
> > > specific requirements in that section. It also seems to= me that
> > > the I-D in question is not a protocol specification at = all (note
> > > that it is an Informational draft) and actually does no= t even describe anything other than how linear protection might apply in a = ring topology.
> > >
> > > So I am not quite sure why you believe that the failure= of the
> > > generic solution to address a requirement intended to d= escribe
> > > optimizations is a reason to not publish this document.= Rather, in
> > > your shoes, I would see it as an encouragement to do
> > > topology-specific work to follow on from this current I= -D.
> > >
> > > Cheers,
> > >
> > > Adrian
> > >
> > >> -----Original Message-----
> > >
> > >> From: cheng weiqiang [mailto:chengwq@gmail.com]=
> > >> Sent: 03 October 2012 10:40
> > >> To: adrian@olddog.co.uk
> > >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org;
> > >> draft-ietf-mpls-tp-ring- protection@tools.ietf.org;=
> > >> larryli888@yahoo.com.cn
> > >> Subject: Re: [mpls] Working group last call on
> > >> draft-ietf-mpls-tp-ring-protection
> > >
> > >> Dear adrian,
> > >
> > >> Here I would like to try to describe some issues on= the ring
> > >> protection solution from my point view.
> > >>
> > >> 1. The Wrapping solution doesn't work when Multi-li= nks faults
> > >> happen
> > >>
> > >> For each link in the ring, current wrapping solutio= n defines two
> > >> SPME
> > >> - the first is a SPME between the two LSRs that are= connected by
> > >> the link, and the second SPME between these same tw= o LSRs but
> > >> traversing the entire ring (except the link that co= nnects the
> > >> LSRs).
> > >
> > >>        &nbs= p;      ___      &nb= sp;   ___    x     ___
> > >>       =3D=3D=3D=3D=3D= =3D>/LSR\********/LSR\********/LSR\
> > >>        &nbs= p;     \_B_/        = \_A_/        \_F_/
> > >>        &nbs= p;       *      = ;            &n= bsp;      *
> > >>        &nbs= p;       *      = ;            &n= bsp;      *
> > >>        &nbs= p;       *      = ;            &n= bsp;      *x
> > >         &n= bsp;       _*     &n= bsp;     ___       &= nbsp;   *_
> > >>        &nbs= p;     /LSR\********/LSR\********/LSR\=3D=3D=3D=3D=3D= =3D>
> > >>        &nbs= p;     \_C_/        = \_D_/        \_E_/
> > >>
> > >>        &nbs= p;    =3D=3D=3D> connected LSP    *** phys= ical link
> > >>        &nbs= p;         x   link fault=
> > >>
> > >> Above figure shows that One LSP enter the ring from= LSR B and
> > >> Exit from LSR E. And at the same time the link A-F = and link F-E
> > >> are both broken. According to current solution, bot= h the
> > >> protection SPME for A-F and the protection SPME for= Link F-E
> > >> should be activated synchronously. Obviously, it do= es not work.
> > >>
> > >> At the same situation, the ring protection for SDH,=
> > >> G.8132(T-MPLS) and the MSRP solution (C-2098 "= MPLS-TP Shared-Ring
> > >> protection (MSRP) mechanism for ring topology"= , ITU-T SG15
> > >> meeting, Sep. 2012) can work well.
> > >>
> > >> 2.Steering function is totally the same with 1:1 li= near
> > >> protection
> > >>
> > >> As the draft mentioned "we use 1:1 linear prot= ection [SurvivFwk]
> > >> [LinProtect] to perform protection switching and co= ordination
> > >> when a signal fault is detected." It is the ba= sic 1:1 linear
> > >> protection(we can see it as a SNC protection, in an= other words
> > >> 1:1 linear protection is using in sub-network).
> > >>
> > >> It does not provide any more simplicity and optimis= m than 1:1
> > >> linear protection. That is why we say this draft ca= nnot meet R100
> > >> of RFC5654 the requirement.
> > >>
> > >> So I don't think we need defined it in the ring dra= ft redundantly again.
> > >>
> > >> Best Regards,
> > >>
> > >> Cheng Weiqiang
> > >> Research Institute of China Mobile
>
_______________________________________________
mpls mailing list
mpls@ietf.org
 
--_000_FE60A4E52763E84B935532D7D9294FF1392845B112EUSAACMS0715e_-- From josh.rogers@twcable.com Thu Oct 4 10:13:17 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F1A21F8712 for ; Thu, 4 Oct 2012 10:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du83lZHnOWo9 for ; Thu, 4 Oct 2012 10:13:16 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9399C21F8694 for ; Thu, 4 Oct 2012 10:13:15 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,537,1344225600"; d="scan'208,217";a="430372322" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 04 Oct 2012 13:12:54 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 4 Oct 2012 13:13:14 -0400 From: "Rogers, Josh" To: Gregory Mirsky , cheng weiqiang , "adrian@olddog.co.uk" Date: Thu, 4 Oct 2012 13:13:21 -0400 Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2iU4oMIe52O0dwQfKwWZIEnQoczA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC932CCE16ADAjoshrogerstwcablecom_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 17:13:17 -0000 --_000_CC932CCE16ADAjoshrogerstwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, when I read ITU document, I suspected the concern about 'multiple fai= lures' was surrounding situations where a single event (fiber cut for insta= nce) may impact multiple rings (imagine two rings entering a facility at th= e same entry, possibly same sheath). The diagram showing failure points 1,= 2, 3, and 4 seemed to me to be relatively close, where a single event coul= d cause multiple impacts (break more than one ring). Of course, I'm guessing because it didn't appear all that clear that was th= e intent. From: Gregory Mirsky > Date: Thursday, October 4, 2012 11:46 AM To: cheng weiqiang >, "adrian@o= lddog.co.uk" > Cc: "mpls@ietf.org" > Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-prot= ection Dear Cheng, et al., I would note that "multiple failure" scenario, illustrated in Annex 1 of l= iaison-2012-10-03-itu-t-sg-15-mpls-requirements-and-analysis-of-ring-protec= tion-for-mpls-tp-networks, is, in my understanding, series of single failur= es in interconnected rings. I believe that protection architectures describ= ed in the document under discussion (wrapping, steering without and wit SPM= E) can be easily applied to interconnected ring topology as presented in th= e Annex 1. I've noticed that, referring to the Annex 1, that scenarios with= dual failure on the same ring are not considered, i.e. failure at point 1 = and 2 or 3 and 4. Should it be interpreted as "multiple failure" scenario i= mplies failures in multiple interconnected rings over which a protected pat= h spans but with only single failure in any given ring of the chain? Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of cheng weiqiang Sent: Thursday, October 04, 2012 4:02 AM To: adrian@olddog.co.uk Cc: mpls@ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-prot= ection Hi, R106 of RFC 5654 mentioned "SHOULD protect against multiple failures". And well known, the multi-failures recovery is a basic function for ring pr= otection. And the double failures scenario I mentioned is the most basic mu= ltiple failures condition. By the way, the wrapping solution of the draft cannot handle the adjacent n= odes failures also. I don't think they are corner cases. I give you some examples for your refe= rence. For the Micro-wave system, the adjacent hops often are impacted by whether = or other facts at the same time. For the adjacent nodes, they often share the same power supply system. When issues happen on power system, they may shut down simultaneous. So for the carrier grade system, the multi-failures scenarios I mentioned s= hould be the basic functionality. B.R. Cheng Weiqiang On Oct 3, 2012 11:28 PM, "Adrian Farrel" > wrote: > > I'm not going to make any comment about consensus on the document - > That is the job of the WG chairs and I am on the appeals path for any suc= h assessment. > > It seems to me that there are certainly some questions to be answered > (that might result in explanations, or might result in caveats being > added to the document). It also seems to me that this document is not > trying to say "here is the only solution that can ever work in MPLS-TP > rings" but is actually saying that here is how you might get > protection on a ring using linear protection techniques without the > need for specification of new constructs or protocols. as such, I > don't believe that corner cases (and frankly, second order failures on > a ring should not be regarded as primary design features, should they?) p= revent publication, but should be highlighted as potential draw-backs. > > Thanks, > Adrian > > > -----Original Message----- > > From: cheng weiqiang [mailto:chengwq@gmail.com] > > Sent: 03 October 2012 15:53 > > To: adrian@olddog.co.uk > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection > > > > Adrian, > > > > Thank you very much for your prompt and detailed reply. I need more > > time to digest it. However, the current draft is really not mature > > to get WG consensus. Do you agree? > > > > B.R. > > Cheng Weiqiang > > > > > > 2012/10/3 Adrian Farrel >: > > > Hi, > > > > > > Thanks for taking the time to set out your concerns. > > > > > > I hope this now gives the WG something to work with. > > > > > > With regard the first point, I hope to hear from the authors > > > whether you have identified a scenario where linear protection > > > will not work (in which case they should probably flag this > > > short-coming in the I-D) or if they can see how linear protection > > > can handle the double failure case you have illustrated. > > > > > > Obviously, we don't have access to C-2098 and can't take it as > > > input to the IETF discussions, so if its authors (was that you?) > > > want to take that material as contribution to the MPLS WG's work, > > > you need to submit it either as an Internet-Draft or as email. > > > > > > The second of your discussion points is related to Section 2.5.6.1 > > > of RFC 5654, and specifically R100. I reproduce it here for our reade= rs: > > > > > > 100 Recovery techniques in a ring SHOULD be identical (or as simi= lar > > > as possible) to those in general transport networks to simpli= fy > > > implementation and operations. However, this MUST NOT overri= de > > > any other requirement. > > > > > > I think the authors need to address this point, but my > > > understanding is that the whole section is intended to describe > > > the requirements that have to be satisfied by topology-specific > > > solutions. Thus, if we were inventing a new protection solution > > > applicable in rings then we would need to address these > > > requirements directly. However, I believe that the I-D that is in las= t call is called "Applicability of MPLS-TP Linear Protection for Ring Topol= ogies". > > > That is, it does not define a new mechanism, but specifically > > > shows how the general mechanism can be applied. > > > > > > Obviously, I can't speak for the WG, but it would seem to me that > > > nothing in this I-D precludes the development of a > > > topology-specific solution for rings that meets the optimization > > > criteria in Section 2.5.6.1 of RFC 5654 and also addresses the > > > specific requirements in that section. It also seems to me that > > > the I-D in question is not a protocol specification at all (note > > > that it is an Informational draft) and actually does not even describ= e anything other than how linear protection might apply in a ring topology. > > > > > > So I am not quite sure why you believe that the failure of the > > > generic solution to address a requirement intended to describe > > > optimizations is a reason to not publish this document. Rather, in > > > your shoes, I would see it as an encouragement to do > > > topology-specific work to follow on from this current I-D. > > > > > > Cheers, > > > > > > Adrian > > > > > >> -----Original Message----- > > > > > >> From: cheng weiqiang [mailto:chengwq@gmail.com] > > >> Sent: 03 October 2012 10:40 > > >> To: adrian@olddog.co.uk > > >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org<= mailto:mpls-chairs@tools.ietf.org>; > > >> draft-ietf-mpls-tp-ring- protection@tools.ietf.org; > > >> larryli888@yahoo.com.cn > > >> Subject: Re: [mpls] Working group last call on > > >> draft-ietf-mpls-tp-ring-protection > > > > > >> Dear adrian, > > > > > >> Here I would like to try to describe some issues on the ring > > >> protection solution from my point view. > > >> > > >> 1. The Wrapping solution doesn't work when Multi-links faults > > >> happen > > >> > > >> For each link in the ring, current wrapping solution defines two > > >> SPME > > >> - the first is a SPME between the two LSRs that are connected by > > >> the link, and the second SPME between these same two LSRs but > > >> traversing the entire ring (except the link that connects the > > >> LSRs). > > > > > >> ___ ___ x ___ > > >> =3D=3D=3D=3D=3D=3D>/LSR\********/LSR\********/LSR\ > > >> \_B_/ \_A_/ \_F_/ > > >> * * > > >> * * > > >> * *x > > > _* ___ *_ > > >> /LSR\********/LSR\********/LSR\=3D=3D=3D=3D=3D=3D> > > >> \_C_/ \_D_/ \_E_/ > > >> > > >> =3D=3D=3D> connected LSP *** physical link > > >> x link fault > > >> > > >> Above figure shows that One LSP enter the ring from LSR B and > > >> Exit from LSR E. And at the same time the link A-F and link F-E > > >> are both broken. According to current solution, both the > > >> protection SPME for A-F and the protection SPME for Link F-E > > >> should be activated synchronously. Obviously, it does not work. > > >> > > >> At the same situation, the ring protection for SDH, > > >> G.8132(T-MPLS) and the MSRP solution (C-2098 "MPLS-TP Shared-Ring > > >> protection (MSRP) mechanism for ring topology", ITU-T SG15 > > >> meeting, Sep. 2012) can work well. > > >> > > >> 2.Steering function is totally the same with 1:1 linear > > >> protection > > >> > > >> As the draft mentioned "we use 1:1 linear protection [SurvivFwk] > > >> [LinProtect] to perform protection switching and coordination > > >> when a signal fault is detected." It is the basic 1:1 linear > > >> protection(we can see it as a SNC protection, in another words > > >> 1:1 linear protection is using in sub-network). > > >> > > >> It does not provide any more simplicity and optimism than 1:1 > > >> linear protection. That is why we say this draft cannot meet R100 > > >> of RFC5654 the requirement. > > >> > > >> So I don't think we need defined it in the ring draft redundantly ag= ain. > > >> > > >> Best Regards, > > >> > > >> Cheng Weiqiang > > >> Research Institute of China Mobile > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_CC932CCE16ADAjoshrogerstwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greg, when I read ITU document, I suspected the concern about 'multipl= e failures' was surrounding situations where a single event (fiber cut for = instance) may impact multiple rings (imagine two rings entering a facility = at the same entry, possibly same sheath).  The diagram showing failure points 1, 2, 3, and 4 seemed to= me to be relatively close, where a single event could cause multiple impac= ts (break more than one ring).  

Of course, I'm guessing because it didn't appear all that clear that w= as the intent.

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Thursday, October 4, 2012 11:= 46 AM
To: cheng weiqiang <chengwq@gmail.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Cc: "mpls@ietf.org" <mpls@i= etf.org>
Subject: Re: [mpls] Working group l= ast call on draft-ietf-mpls-tp-ring-protection

Dear Cheng, et al.,
I would note that "multiple failu= re" scenario, illustrated in Annex 1  of liaison-2012-10-03-itu-t= -sg-15-mpls-requirements-and-analysis-of-ring-protection-for-mpls-tp-networ= ks, is, in my understanding, series of single failures in interconnected rings. I believe that protection architectures described= in the document under discussion (wrapping, steering without and wit SPME)= can be easily applied to interconnected ring topology as presented in the = Annex 1. I've noticed that, referring to the Annex 1, that scenarios with dual failure on the same ring are not = considered, i.e. failure at point 1 and 2 or 3 and 4. Should it be interpre= ted as "multiple failure" scenario implies failures in multiple i= nterconnected rings over which a protected path spans but with only single failure in any given ring of the chain?
 
      &n= bsp; Regards,
      &n= bsp;         Greg
 
-----Original Message-----
Sent: Thursday, October 04, 2012 4:02 AM
To: adrian@olddog.co.uk
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring= -protection
 
Hi,
 
R106 of RFC 5654 mentioned "SHOULD protect against multiple failu= res".
And well known, the multi-failures recovery is a basic function for ri= ng protection. And the double failures scenario I mentioned is the most bas= ic multiple failures condition.
 
By the way, the wrapping solution of the draft cannot handle the adjac= ent nodes failures also.
 
I don't think they are corner cases. I give you some examples for your= reference.
 
For the Micro-wave system, the adjacent hops often are impacted by whe= ther or other facts at the same time.
 
For the adjacent nodes, they often share the same power supply system.=
When issues happen on power system, they may shut down simultaneous.
 
So for the carrier grade system, the multi-failures scenarios I mentio= ned should be the basic functionality.
 
B.R.
 
Cheng Weiqiang
 
 
 
 
 
On Oct 3, 2012 11:28 PM, "Adrian Farrel" <adrian@olddog.co.uk> wrote:
>
> I'm not going to make any comment about consensus on the document= -
> That is the job of the WG chairs and I am on the appeals path for= any such assessment.
>
> It seems to me that there are certainly some questions to be answ= ered
> (that might result in explanations, or might result in caveats be= ing
> added to the document). It also seems to me that this document is= not
> trying to say "here is the only solution that can ever work = in MPLS-TP
> rings" but is actually saying that here is how you might get=
> protection on a ring using linear protection techniques without t= he
> need for specification of new constructs or protocols. as such, I=
> don't believe that corner cases (and frankly, second order failur= es on
> a ring should not be regarded as primary design features, should = they?) prevent publication, but should be highlighted as potential draw-bac= ks.
>
> Thanks,
> Adrian
>
> > -----Original Message-----
> > Sent: 03 October 2012 15:53
> > Subject: Re: [mpls] Working group last call on
> draft-ietf-mpls-tp-ring-protection
> >
> > Adrian,
> >
> > Thank you very much for your prompt and detailed reply. I ne= ed more
> > time to digest it. However, the current draft is really not = mature
> > to get WG consensus. Do you agree?
> >
> > B.R.
> > Cheng Weiqiang
> >
> >
> > 2012/10/3 Adrian Farrel <adrian@olddog.co.uk>:
> > > Hi,
> > >
> > > Thanks for taking the time to set out your concerns.
> > >
> > > I hope this now gives the WG something to work with.
> > >
> > > With regard the first point, I hope to hear from the au= thors
> > > whether you have identified a scenario where linear pro= tection
> > > will not work (in which case they should probably flag = this
> > > short-coming in the I-D) or if they can see how linear = protection
> > > can handle the double failure case you have illustrated= .
> > >
> > > Obviously, we don't have access to C-2098 and can't tak= e it as
> > > input to the IETF discussions, so if its authors (was t= hat you?)
> > > want to take that material as contribution to the MPLS = WG's work,
> > > you need to submit it either as an Internet-Draft or as= email.
> > >
> > > The second of your discussion points is related to Sect= ion 2.5.6.1
> > > of RFC 5654, and specifically R100. I reproduce it here= for our readers:
> > >
> > >    100  Recovery techniques in a ri= ng SHOULD be identical (or as similar
> > >         as poss= ible) to those in general transport networks to simplify
> > >         impleme= ntation and operations.  However, this MUST NOT override
> > >         any oth= er requirement.
> > >
> > > I think the authors need to address this point, but my =
> > > understanding is that the whole section is intended to = describe
> > > the requirements that have to be satisfied by topology-= specific
> > > solutions. Thus, if we were inventing a new protection = solution
> > > applicable in rings then we would need to address these=
> > > requirements directly. However, I believe that the I-D = that is in last call is called "Applicability of MPLS-TP Linear Protec= tion for Ring Topologies".
> > > That is, it does not define a new mechanism, but specif= ically
> > > shows how the general mechanism can be applied.
> > >
> > > Obviously, I can't speak for the WG, but it would seem = to me that
> > > nothing in this I-D precludes the development of a
> > > topology-specific solution for rings that meets the opt= imization
> > > criteria in Section 2.5.6.1 of RFC 5654 and also addres= ses the
> > > specific requirements in that section. It also seems to= me that
> > > the I-D in question is not a protocol specification at = all (note
> > > that it is an Informational draft) and actually does no= t even describe anything other than how linear protection might apply in a = ring topology.
> > >
> > > So I am not quite sure why you believe that the failure= of the
> > > generic solution to address a requirement intended to d= escribe
> > > optimizations is a reason to not publish this document.= Rather, in
> > > your shoes, I would see it as an encouragement to do
> > > topology-specific work to follow on from this current I= -D.
> > >
> > > Cheers,
> > >
> > > Adrian
> > >
> > >> -----Original Message-----
> > >
> > >> From: cheng weiqiang [mailto:chengwq@gmail.com]=
> > >> Sent: 03 October 2012 10:40
> > >> draft-ietf-mpls-tp-ring- protection@tools.ietf.org;
> > >> Subject: Re: [mpls] Working group last call on
> > >> draft-ietf-mpls-tp-ring-protection
> > >
> > >> Dear adrian,
> > >
> > >> Here I would like to try to describe some issues on= the ring
> > >> protection solution from my point view.
> > >>
> > >> 1. The Wrapping solution doesn't work when Multi-li= nks faults
> > >> happen
> > >>
> > >> For each link in the ring, current wrapping solutio= n defines two
> > >> SPME
> > >> - the first is a SPME between the two LSRs that are= connected by
> > >> the link, and the second SPME between these same tw= o LSRs but
> > >> traversing the entire ring (except the link that co= nnects the
> > >> LSRs).
> > >
> > >>        &nbs= p;      ___      &nb= sp;   ___    x     ___
> > >>       =3D=3D=3D=3D=3D= =3D>/LSR\********/LSR\********/LSR\
> > >>        &nbs= p;     \_B_/        = \_A_/        \_F_/
> > >>        &nbs= p;       *      = ;            &n= bsp;      *
> > >>        &nbs= p;       *      = ;            &n= bsp;      *
> > >>        &nbs= p;       *      = ;            &n= bsp;      *x
> > >         &n= bsp;       _*     &n= bsp;     ___       &= nbsp;   *_
> > >>        &nbs= p;     /LSR\********/LSR\********/LSR\=3D=3D=3D=3D=3D= =3D>
> > >>        &nbs= p;     \_C_/        = \_D_/        \_E_/
> > >>
> > >>        &nbs= p;    =3D=3D=3D> connected LSP    *** phys= ical link
> > >>        &nbs= p;         x   link fault=
> > >>
> > >> Above figure shows that One LSP enter the ring from= LSR B and
> > >> Exit from LSR E. And at the same time the link A-F = and link F-E
> > >> are both broken. According to current solution, bot= h the
> > >> protection SPME for A-F and the protection SPME for= Link F-E
> > >> should be activated synchronously. Obviously, it do= es not work.
> > >>
> > >> At the same situation, the ring protection for SDH,=
> > >> G.8132(T-MPLS) and the MSRP solution (C-2098 "= MPLS-TP Shared-Ring
> > >> protection (MSRP) mechanism for ring topology"= , ITU-T SG15
> > >> meeting, Sep. 2012) can work well.
> > >>
> > >> 2.Steering function is totally the same with 1:1 li= near
> > >> protection
> > >>
> > >> As the draft mentioned "we use 1:1 linear prot= ection [SurvivFwk]
> > >> [LinProtect] to perform protection switching and co= ordination
> > >> when a signal fault is detected." It is the ba= sic 1:1 linear
> > >> protection(we can see it as a SNC protection, in an= other words
> > >> 1:1 linear protection is using in sub-network).
> > >>
> > >> It does not provide any more simplicity and optimis= m than 1:1
> > >> linear protection. That is why we say this draft ca= nnot meet R100
> > >> of RFC5654 the requirement.
> > >>
> > >> So I don't think we need defined it in the ring dra= ft redundantly again.
> > >>
> > >> Best Regards,
> > >>
> > >> Cheng Weiqiang
> > >> Research Institute of China Mobile
>
_______________________________________________
mpls mailing list
 

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_CC932CCE16ADAjoshrogerstwcablecom_-- From scott.mansfield@ericsson.com Thu Oct 4 15:23:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E8621F8440 for ; Thu, 4 Oct 2012 15:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91TG3Lqn-Cf1 for ; Thu, 4 Oct 2012 15:23:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id F010721F843E for ; Thu, 4 Oct 2012 15:23:26 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q94MN53A016902 for ; Thu, 4 Oct 2012 17:23:28 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 4 Oct 2012 18:23:07 -0400 From: Scott Mansfield To: "mpls@ietf.org" Date: Thu, 4 Oct 2012 18:23:06 -0400 Thread-Topic: =?utf-8?B?TmV3IExpYWlzb24gU3RhdGVtZW50LCAiUmVjb21tZW5kYXRpb24gSVRVLVQ=?= =?utf-8?B?IEcuODEzMS9ZLjEzODIgcmV2aXNpb24g4oCTIExpbmVhciBwcm90ZWN0aW9u?= =?utf-8?B?IHN3aXRjaGluZyBmb3IgTVBMUy1UUCBuZXR3b3JrcyI=?= Thread-Index: Ac2id+822LPjsv6PSNO/pTIc36GO6wABsWyQ Message-ID: References: <20121004213256.2128.75003.idtracker@ietfa.amsl.com> In-Reply-To: <20121004213256.2128.75003.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [mpls] =?utf-8?q?FW=3A_New_Liaison_Statement=2C_=22Recommendation?= =?utf-8?q?_ITU-T_G=2E8131/Y=2E1382_revision_=E2=80=93_Linear_protection_s?= =?utf-8?q?witching_for_MPLS-TP_networks=22?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:23:27 -0000 QmVsb3csICBwbGVhc2UgZmluZCB0aGUgbGlhaXNvbiBvbiBMaW5lYXIgcHJvdGVjdGlvbiBmcm9t IHRoZSBJVFUtVC4NCg0KUmVnYXJkcywNCi1zY290dC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IExpYWlzb24gU3RhdGVtZW50IE1hbmFnZW1lbnQgVG9vbCBbbWFpbHRvOmxz bXRAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDQsIDIwMTIgNTozMyBQTQ0K VG86IExvYSBBbmRlcnNzb247IEdlb3JnZSBTd2FsbG93OyBSb3NzIENhbGxvbg0KQ2M6IFN0ZXdh cnQgQnJ5YW50OyBBZHJpYW4gRmFycmVsOyBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyBE aXNjdXNzaW9uIExpc3Q7IEpvaG4gRHJha2U7IFNjb3R0IE1hbnNmaWVsZDsgRWxpb3QgTGVhcjsg WW9pY2hpIE1BRURBOyBTdGV2ZSBUcm93YnJpZGdlOyBHaGFuaSBBYmJhczsgSVRVIFRTQlNHMTU7 IEhpcm9zaGkgT3RhOyBHaGFuaSBBYmJhcw0KU3ViamVjdDogTmV3IExpYWlzb24gU3RhdGVtZW50 LCAiUmVjb21tZW5kYXRpb24gSVRVLVQgRy44MTMxL1kuMTM4MiByZXZpc2lvbiDigJMgTGluZWFy IHByb3RlY3Rpb24gc3dpdGNoaW5nIGZvciBNUExTLVRQIG5ldHdvcmtzIg0KDQpUaXRsZTogUmVj b21tZW5kYXRpb24gSVRVLVQgRy44MTMxL1kuMTM4MiByZXZpc2lvbiDigJMgTGluZWFyIHByb3Rl Y3Rpb24gc3dpdGNoaW5nIGZvciBNUExTLVRQIG5ldHdvcmtzIFN1Ym1pc3Npb24gRGF0ZTogMjAx Mi0xMC0wMyBVUkwgb2YgdGhlIElFVEYgV2ViIHBhZ2U6IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9saWFpc29uLzEyMDUvDQpQbGVhc2UgcmVwbHkgYnkgMjAxMi0xMi0zMQ0KRnJvbTogSVRV LVQgU0cgMTUgIChHcmVnIEpvbmVzIDxncmVnLmpvbmVzQGl0dS5pbnQ+KQ0KVG86IE11bHRpcHJv dG9jb2wgTGFiZWwgU3dpdGNoaW5nIChMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+LCBHZW9yZ2Ug U3dhbGxvdyA8c3dhbGxvd0BjaXNjby5jb20+LCBSb3NzIENhbGxvbiA8cmNhbGxvbkBqdW5pcGVy Lm5ldD4pDQpDYzogU3Rld2FydCBCcnlhbnQgPHN0YnJ5YW50QGNpc2NvLmNvbT4sQWRyaWFuIEZh cnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4sTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcg RGlzY3Vzc2lvbiBMaXN0IDxtcGxzQGlldGYub3JnPixKb2huIERyYWtlIDxqZHJha2VAanVuaXBl ci5uZXQ+LFNjb3R0IE1hbnNmaWVsZCA8U2NvdHQuTWFuc2ZpZWxkQEVyaWNzc29uLmNvbT4sRWxp b3QgTGVhciA8bGVhckBjaXNjby5jb20+LFlvaWNoaSBNQUVEQSA8eW9pY2hpLm1hZWRhQHR0Yy5v ci5qcD4sU3RldmUgVHJvd2JyaWRnZSA8c3RldmUudHJvd2JyaWRnZUBhbGNhdGVsLWx1Y2VudC5j b20+LEdoYW5pIEFiYmFzIDxHaGFuaS5BYmJhc0Blcmljc3Nvbi5jb20+LElUVSBUU0JTRzE1IDx0 c2JzZzE1QGl0dS5pbnQ+LEhpcm9zaGkgT3RhIDxoaXJvc2hpLm90YUBpdHUuaW50PiBSZXBvbnNl IENvbnRhY3Q6IEdoYW5pIEFiYmFzIDxHaGFuaS5BYmJhc0Blcmljc3Nvbi5jb20+IFRlY2huaWNh bCBDb250YWN0OiANClB1cnBvc2U6IEZvciBhY3Rpb24NClJlZmVyZW5jZWQgbGlhaXNvbjogUmVw bHkgdG8gSVRVIExpYWlzb24gU3RhdGVtZW50IHJlZ2FyZGluZyBNUExTLVRQIExpbmVhciBQcm90 ZWN0aW9uIChodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMTc0LykNCkJvZHk6 IA0KQXR0YWNobWVudHM6DQoNCiAgICBSZWNvbW1lbmRhdGlvbiBJVFUtVCBHLjgxMzEvWS4xMzgy IHJldmlzaW9uIOKAkyBMaW5lYXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgZm9yIE1QTFMtVFAgbmV0 d29ya3MNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvY3VtZW50cy9MSUFJU09O L2xpYWlzb24tMjAxMi0xMC0wMy1pdHUtdC1zZy0xNS1tcGxzLXJlY29tbWVuZGF0aW9uLWl0dS10 LWc4MTMxeTEzODItcmV2aXNpb24tbGluZWFyLXByb3RlY3Rpb24tc3dpdGNoaW5nLWZvci1tcGxz LXRwLW5ldHdvcmtzLWF0dGFjaG1lbnQtMS5kb2N4IA0KDQo= From daniele.ceccarelli@ericsson.com Fri Oct 5 02:20:07 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7408321F85A4 for ; Fri, 5 Oct 2012 02:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10JegKCCYfke for ; Fri, 5 Oct 2012 02:20:05 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B19E021F85A2 for ; Fri, 5 Oct 2012 02:20:04 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-db-506ea64347a1 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DD.43.17130.346AE605; Fri, 5 Oct 2012 11:20:03 +0200 (CEST) Received: from ESESSHC022.ericsson.se (153.88.183.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 5 Oct 2012 11:20:03 +0200 Received: from ESESSMB301.ericsson.se ([169.254.1.169]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 11:20:02 +0200 From: Daniele Ceccarelli To: "Rogers, Josh" , Gregory Mirsky , cheng weiqiang , "adrian@olddog.co.uk" Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: AQHNolOP+s7vhvueUkq7P3MfaZpUqJeqcCSA Date: Fri, 5 Oct 2012 09:20:02 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48EF37@ESESSMB301.ericsson.se> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48EF37ESESSMB301ericssons_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM+Jvra7zsrwAgyNzVS1+9Nxgtmi5dIHV Yu7iPywWt5auZHVg8dg56y67x5IlP5k8Vmxeyeixes0rlgCWKC6blNSczLLUIn27BK6MdY3t zAUbepkq3s07xtzAePwhYxcjJ4eEgInEv+1z2CBsMYkL99YD2VwcQgKnGCUmPfzACpIQEtjB KLHtKStEYjGjxN6zq5m7GDk42ASsJJ4c8gGJiwisZ5Tou/QYLM4soCxx6q4MSK+wQLBEa+M+ FhBbRCBEYsevVijbSGLq4S4wm0VAReLyljtgR/AKeErM2fCLCWJXE6NE64VNYEWcAqYSa+dP BrMZBWQlJuxeBPYBs4C4xK0n85kgPhCQWLLnPDOELSrx8vE/VpB7JAQUJZb3y0GU50tc3Xic EWKXoMTJmU9YIH7UkTj2p4F5AqP4LCRTZyFpmYWkBSKuJ3Fj6hQ2CFtbYtnC18wQtq7EjH+H WJDFFzCyr2IUzk3MzEkvN9dLLcpMLi7Oz9MrTt3ECIzjg1t+G+xg3HRf7BCjNAeLkjivnup+ fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M2ZJXObublnYmT708+5+R6LrQH+LHb6bueRUm GfFCJll9j2F4hmGjs4erfJrYYwuLSftUf0QZ/j4Zm/nt3JvMhqV/Fn5it5zEsmDX+rxXqxOj o/vdDngufHR176rjitwTgp+o6djG+gWaLJ8ZtlTG7crb5KLgtqkM/FvMWxYedk8uVftZteqT EktxRqKhFnNRcSIAftvC/bECAAA= Cc: "mpls@ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 09:20:07 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48EF37ESESSMB301ericssons_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Josh, in addition to what already said by Greg, the protection of interconnected = rings is not in the scope of the ring protection applicability draft but in= the scope of this one: http://tools.ietf.org/id/draft-liu-mpls-tp-interconnected-ring-protection-0= 2.txt BR Daniele ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rog= ers, Josh Sent: gioved=EC 4 ottobre 2012 19.13 To: Gregory Mirsky; cheng weiqiang; adrian@olddog.co.uk Cc: mpls@ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-prot= ection Greg, when I read ITU document, I suspected the concern about 'multiple fai= lures' was surrounding situations where a single event (fiber cut for insta= nce) may impact multiple rings (imagine two rings entering a facility at th= e same entry, possibly same sheath). The diagram showing failure points 1,= 2, 3, and 4 seemed to me to be relatively close, where a single event coul= d cause multiple impacts (break more than one ring). Of course, I'm guessing because it didn't appear all that clear that was th= e intent. From: Gregory Mirsky > Date: Thursday, October 4, 2012 11:46 AM To: cheng weiqiang >, "adrian@o= lddog.co.uk" > Cc: "mpls@ietf.org" > Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-prot= ection Dear Cheng, et al., I would note that "multiple failure" scenario, illustrated in Annex 1 of l= iaison-2012-10-03-itu-t-sg-15-mpls-requirements-and-analysis-of-ring-protec= tion-for-mpls-tp-networks, is, in my understanding, series of single failur= es in interconnected rings. I believe that protection architectures describ= ed in the document under discussion (wrapping, steering without and wit SPM= E) can be easily applied to interconnected ring topology as presented in th= e Annex 1. I've noticed that, referring to the Annex 1, that scenarios with= dual failure on the same ring are not considered, i.e. failure at point 1 = and 2 or 3 and 4. Should it be interpreted as "multiple failure" scenario i= mplies failures in multiple interconnected rings over which a protected pat= h spans but with only single failure in any given ring of the chain? Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of cheng weiqiang Sent: Thursday, October 04, 2012 4:02 AM To: adrian@olddog.co.uk Cc: mpls@ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-prot= ection Hi, R106 of RFC 5654 mentioned "SHOULD protect against multiple failures". And well known, the multi-failures recovery is a basic function for ring pr= otection. And the double failures scenario I mentioned is the most basic mu= ltiple failures condition. By the way, the wrapping solution of the draft cannot handle the adjacent n= odes failures also. I don't think they are corner cases. I give you some examples for your refe= rence. For the Micro-wave system, the adjacent hops often are impacted by whether = or other facts at the same time. For the adjacent nodes, they often share the same power supply system. When issues happen on power system, they may shut down simultaneous. So for the carrier grade system, the multi-failures scenarios I mentioned s= hould be the basic functionality. B.R. Cheng Weiqiang On Oct 3, 2012 11:28 PM, "Adrian Farrel" > wrote: > > I'm not going to make any comment about consensus on the document - > That is the job of the WG chairs and I am on the appeals path for any suc= h assessment. > > It seems to me that there are certainly some questions to be answered > (that might result in explanations, or might result in caveats being > added to the document). It also seems to me that this document is not > trying to say "here is the only solution that can ever work in MPLS-TP > rings" but is actually saying that here is how you might get > protection on a ring using linear protection techniques without the > need for specification of new constructs or protocols. as such, I > don't believe that corner cases (and frankly, second order failures on > a ring should not be regarded as primary design features, should they?) p= revent publication, but should be highlighted as potential draw-backs. > > Thanks, > Adrian > > > -----Original Message----- > > From: cheng weiqiang [mailto:chengwq@gmail.com] > > Sent: 03 October 2012 15:53 > > To: adrian@olddog.co.uk > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection > > > > Adrian, > > > > Thank you very much for your prompt and detailed reply. I need more > > time to digest it. However, the current draft is really not mature > > to get WG consensus. Do you agree? > > > > B.R. > > Cheng Weiqiang > > > > > > 2012/10/3 Adrian Farrel >: > > > Hi, > > > > > > Thanks for taking the time to set out your concerns. > > > > > > I hope this now gives the WG something to work with. > > > > > > With regard the first point, I hope to hear from the authors > > > whether you have identified a scenario where linear protection > > > will not work (in which case they should probably flag this > > > short-coming in the I-D) or if they can see how linear protection > > > can handle the double failure case you have illustrated. > > > > > > Obviously, we don't have access to C-2098 and can't take it as > > > input to the IETF discussions, so if its authors (was that you?) > > > want to take that material as contribution to the MPLS WG's work, > > > you need to submit it either as an Internet-Draft or as email. > > > > > > The second of your discussion points is related to Section 2.5.6.1 > > > of RFC 5654, and specifically R100. I reproduce it here for our reade= rs: > > > > > > 100 Recovery techniques in a ring SHOULD be identical (or as simi= lar > > > as possible) to those in general transport networks to simpli= fy > > > implementation and operations. However, this MUST NOT overri= de > > > any other requirement. > > > > > > I think the authors need to address this point, but my > > > understanding is that the whole section is intended to describe > > > the requirements that have to be satisfied by topology-specific > > > solutions. Thus, if we were inventing a new protection solution > > > applicable in rings then we would need to address these > > > requirements directly. However, I believe that the I-D that is in las= t call is called "Applicability of MPLS-TP Linear Protection for Ring Topol= ogies". > > > That is, it does not define a new mechanism, but specifically > > > shows how the general mechanism can be applied. > > > > > > Obviously, I can't speak for the WG, but it would seem to me that > > > nothing in this I-D precludes the development of a > > > topology-specific solution for rings that meets the optimization > > > criteria in Section 2.5.6.1 of RFC 5654 and also addresses the > > > specific requirements in that section. It also seems to me that > > > the I-D in question is not a protocol specification at all (note > > > that it is an Informational draft) and actually does not even describ= e anything other than how linear protection might apply in a ring topology. > > > > > > So I am not quite sure why you believe that the failure of the > > > generic solution to address a requirement intended to describe > > > optimizations is a reason to not publish this document. Rather, in > > > your shoes, I would see it as an encouragement to do > > > topology-specific work to follow on from this current I-D. > > > > > > Cheers, > > > > > > Adrian > > > > > >> -----Original Message----- > > > > > >> From: cheng weiqiang [mailto:chengwq@gmail.com] > > >> Sent: 03 October 2012 10:40 > > >> To: adrian@olddog.co.uk > > >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org<= mailto:mpls-chairs@tools.ietf.org>; > > >> draft-ietf-mpls-tp-ring- protection@tools.ietf.org; > > >> larryli888@yahoo.com.cn > > >> Subject: Re: [mpls] Working group last call on > > >> draft-ietf-mpls-tp-ring-protection > > > > > >> Dear adrian, > > > > > >> Here I would like to try to describe some issues on the ring > > >> protection solution from my point view. > > >> > > >> 1. The Wrapping solution doesn't work when Multi-links faults > > >> happen > > >> > > >> For each link in the ring, current wrapping solution defines two > > >> SPME > > >> - the first is a SPME between the two LSRs that are connected by > > >> the link, and the second SPME between these same two LSRs but > > >> traversing the entire ring (except the link that connects the > > >> LSRs). > > > > > >> ___ ___ x ___ > > >> =3D=3D=3D=3D=3D=3D>/LSR\********/LSR\********/LSR\ > > >> \_B_/ \_A_/ \_F_/ > > >> * * > > >> * * > > >> * *x > > > _* ___ *_ > > >> /LSR\********/LSR\********/LSR\=3D=3D=3D=3D=3D=3D> > > >> \_C_/ \_D_/ \_E_/ > > >> > > >> =3D=3D=3D> connected LSP *** physical link > > >> x link fault > > >> > > >> Above figure shows that One LSP enter the ring from LSR B and > > >> Exit from LSR E. And at the same time the link A-F and link F-E > > >> are both broken. According to current solution, both the > > >> protection SPME for A-F and the protection SPME for Link F-E > > >> should be activated synchronously. Obviously, it does not work. > > >> > > >> At the same situation, the ring protection for SDH, > > >> G.8132(T-MPLS) and the MSRP solution (C-2098 "MPLS-TP Shared-Ring > > >> protection (MSRP) mechanism for ring topology", ITU-T SG15 > > >> meeting, Sep. 2012) can work well. > > >> > > >> 2.Steering function is totally the same with 1:1 linear > > >> protection > > >> > > >> As the draft mentioned "we use 1:1 linear protection [SurvivFwk] > > >> [LinProtect] to perform protection switching and coordination > > >> when a signal fault is detected." It is the basic 1:1 linear > > >> protection(we can see it as a SNC protection, in another words > > >> 1:1 linear protection is using in sub-network). > > >> > > >> It does not provide any more simplicity and optimism than 1:1 > > >> linear protection. That is why we say this draft cannot meet R100 > > >> of RFC5654 the requirement. > > >> > > >> So I don't think we need defined it in the ring draft redundantly ag= ain. > > >> > > >> Best Regards, > > >> > > >> Cheng Weiqiang > > >> Research Institute of China Mobile > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_4A1562797D64E44993C5CBF38CF1BE48EF37ESESSMB301ericssons_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Josh,
 
in addition to what already said by Greg, the protection of interc= onnected rings is not in the scope of the ring protection applicability dra= ft but in the scope of this one:
 
BR
Daniele

From: mpls-bounces@ietf.org [mailto= :mpls-bounces@ietf.org] On Behalf Of Rogers, Josh
Sent: gioved=EC 4 ottobre 2012 19.13
To: Gregory Mirsky; cheng weiqiang; adrian@olddog.co.uk
Cc: mpls@ietf.org
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ri= ng-protection

Greg, when I read ITU document, I suspected the concern about 'multipl= e failures' was surrounding situations where a single event (fiber cut for = instance) may impact multiple rings (imagine two rings entering a facility = at the same entry, possibly same sheath).  The diagram showing failure points 1, 2, 3, and 4 seemed to= me to be relatively close, where a single event could cause multiple impac= ts (break more than one ring).  

Of course, I'm guessing because it didn't appear all that clear that w= as the intent.

From: Gregory Mirsky <gregory.mirsky@ericsson.com>=
Date: Thursday, October 4, 2012 11= :46 AM
To: cheng weiqiang <chengwq@gmail.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Cc: "mpls@ietf.org" <mpls@= ietf.org>
Subject: Re: [mpls] Working group = last call on draft-ietf-mpls-tp-ring-protection

Dear Cheng, et al.,
I would note that "multiple failu= re" scenario, illustrated in Annex 1  of liaison-2012-10-03-itu-t= -sg-15-mpls-requirements-and-analysis-of-ring-protection-for-mpls-tp-networ= ks, is, in my understanding, series of single failures in interconnected rings. I believe that protection architectures described= in the document under discussion (wrapping, steering without and wit SPME)= can be easily applied to interconnected ring topology as presented in the = Annex 1. I've noticed that, referring to the Annex 1, that scenarios with dual failure on the same ring are not = considered, i.e. failure at point 1 and 2 or 3 and 4. Should it be interpre= ted as "multiple failure" scenario implies failures in multiple i= nterconnected rings over which a protected path spans but with only single failure in any given ring of the chain?
 
      &n= bsp; Regards,
      &n= bsp;         Greg
 
-----Original Message-----
Sent: Thursday, October 04, 2012 4:02 AM
To: adrian@olddog.co.uk
Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring= -protection
 
Hi,
 
R106 of RFC 5654 mentioned "SHOULD protect against multiple failu= res".
And well known, the multi-failures recovery is a basic function for ri= ng protection. And the double failures scenario I mentioned is the most bas= ic multiple failures condition.
 
By the way, the wrapping solution of the draft cannot handle the adjac= ent nodes failures also.
 
I don't think they are corner cases. I give you some examples for your= reference.
 
For the Micro-wave system, the adjacent hops often are impacted by whe= ther or other facts at the same time.
 
For the adjacent nodes, they often share the same power supply system.=
When issues happen on power system, they may shut down simultaneous.
 
So for the carrier grade system, the multi-failures scenarios I mentio= ned should be the basic functionality.
 
B.R.
 
Cheng Weiqiang
 
 
 
 
 
On Oct 3, 2012 11:28 PM, "Adrian Farrel" <adrian@olddog.co.uk> wrote:
>
> I'm not going to make any comment about consensus on the document= -
> That is the job of the WG chairs and I am on the appeals path for= any such assessment.
>
> It seems to me that there are certainly some questions to be answ= ered
> (that might result in explanations, or might result in caveats be= ing
> added to the document). It also seems to me that this document is= not
> trying to say "here is the only solution that can ever work = in MPLS-TP
> rings" but is actually saying that here is how you might get=
> protection on a ring using linear protection techniques without t= he
> need for specification of new constructs or protocols. as such, I=
> don't believe that corner cases (and frankly, second order failur= es on
> a ring should not be regarded as primary design features, should = they?) prevent publication, but should be highlighted as potential draw-bac= ks.
>
> Thanks,
> Adrian
>
> > -----Original Message-----
> > Sent: 03 October 2012 15:53
> > Subject: Re: [mpls] Working group last call on
> draft-ietf-mpls-tp-ring-protection
> >
> > Adrian,
> >
> > Thank you very much for your prompt and detailed reply. I ne= ed more
> > time to digest it. However, the current draft is really not = mature
> > to get WG consensus. Do you agree?
> >
> > B.R.
> > Cheng Weiqiang
> >
> >
> > 2012/10/3 Adrian Farrel <adrian@olddog.co.uk>:
> > > Hi,
> > >
> > > Thanks for taking the time to set out your concerns.
> > >
> > > I hope this now gives the WG something to work with.
> > >
> > > With regard the first point, I hope to hear from the au= thors
> > > whether you have identified a scenario where linear pro= tection
> > > will not work (in which case they should probably flag = this
> > > short-coming in the I-D) or if they can see how linear = protection
> > > can handle the double failure case you have illustrated= .
> > >
> > > Obviously, we don't have access to C-2098 and can't tak= e it as
> > > input to the IETF discussions, so if its authors (was t= hat you?)
> > > want to take that material as contribution to the MPLS = WG's work,
> > > you need to submit it either as an Internet-Draft or as= email.
> > >
> > > The second of your discussion points is related to Sect= ion 2.5.6.1
> > > of RFC 5654, and specifically R100. I reproduce it here= for our readers:
> > >
> > >    100  Recovery techniques in a ri= ng SHOULD be identical (or as similar
> > >         as poss= ible) to those in general transport networks to simplify
> > >         impleme= ntation and operations.  However, this MUST NOT override
> > >         any oth= er requirement.
> > >
> > > I think the authors need to address this point, but my =
> > > understanding is that the whole section is intended to = describe
> > > the requirements that have to be satisfied by topology-= specific
> > > solutions. Thus, if we were inventing a new protection = solution
> > > applicable in rings then we would need to address these=
> > > requirements directly. However, I believe that the I-D = that is in last call is called "Applicability of MPLS-TP Linear Protec= tion for Ring Topologies".
> > > That is, it does not define a new mechanism, but specif= ically
> > > shows how the general mechanism can be applied.
> > >
> > > Obviously, I can't speak for the WG, but it would seem = to me that
> > > nothing in this I-D precludes the development of a
> > > topology-specific solution for rings that meets the opt= imization
> > > criteria in Section 2.5.6.1 of RFC 5654 and also addres= ses the
> > > specific requirements in that section. It also seems to= me that
> > > the I-D in question is not a protocol specification at = all (note
> > > that it is an Informational draft) and actually does no= t even describe anything other than how linear protection might apply in a = ring topology.
> > >
> > > So I am not quite sure why you believe that the failure= of the
> > > generic solution to address a requirement intended to d= escribe
> > > optimizations is a reason to not publish this document.= Rather, in
> > > your shoes, I would see it as an encouragement to do
> > > topology-specific work to follow on from this current I= -D.
> > >
> > > Cheers,
> > >
> > > Adrian
> > >
> > >> -----Original Message-----
> > >
> > >> From: cheng weiqiang [mailto:chengwq@gmail.com]=
> > >> Sent: 03 October 2012 10:40
> > >> draft-ietf-mpls-tp-ring- protection@tools.ietf.org;
> > >> Subject: Re: [mpls] Working group last call on
> > >> draft-ietf-mpls-tp-ring-protection
> > >
> > >> Dear adrian,
> > >
> > >> Here I would like to try to describe some issues on= the ring
> > >> protection solution from my point view.
> > >>
> > >> 1. The Wrapping solution doesn't work when Multi-li= nks faults
> > >> happen
> > >>
> > >> For each link in the ring, current wrapping solutio= n defines two
> > >> SPME
> > >> - the first is a SPME between the two LSRs that are= connected by
> > >> the link, and the second SPME between these same tw= o LSRs but
> > >> traversing the entire ring (except the link that co= nnects the
> > >> LSRs).
> > >
> > >>        &nbs= p;      ___      &nb= sp;   ___    x     ___
> > >>       =3D=3D=3D=3D=3D= =3D>/LSR\********/LSR\********/LSR\
> > >>        &nbs= p;     \_B_/        = \_A_/        \_F_/
> > >>        &nbs= p;       *      = ;            &n= bsp;      *
> > >>        &nbs= p;       *      = ;            &n= bsp;      *
> > >>        &nbs= p;       *      = ;            &n= bsp;      *x
> > >         &n= bsp;       _*     &n= bsp;     ___       &= nbsp;   *_
> > >>        &nbs= p;     /LSR\********/LSR\********/LSR\=3D=3D=3D=3D=3D= =3D>
> > >>        &nbs= p;     \_C_/        = \_D_/        \_E_/
> > >>
> > >>        &nbs= p;    =3D=3D=3D> connected LSP    *** phys= ical link
> > >>        &nbs= p;         x   link fault=
> > >>
> > >> Above figure shows that One LSP enter the ring from= LSR B and
> > >> Exit from LSR E. And at the same time the link A-F = and link F-E
> > >> are both broken. According to current solution, bot= h the
> > >> protection SPME for A-F and the protection SPME for= Link F-E
> > >> should be activated synchronously. Obviously, it do= es not work.
> > >>
> > >> At the same situation, the ring protection for SDH,=
> > >> G.8132(T-MPLS) and the MSRP solution (C-2098 "= MPLS-TP Shared-Ring
> > >> protection (MSRP) mechanism for ring topology"= , ITU-T SG15
> > >> meeting, Sep. 2012) can work well.
> > >>
> > >> 2.Steering function is totally the same with 1:1 li= near
> > >> protection
> > >>
> > >> As the draft mentioned "we use 1:1 linear prot= ection [SurvivFwk]
> > >> [LinProtect] to perform protection switching and co= ordination
> > >> when a signal fault is detected." It is the ba= sic 1:1 linear
> > >> protection(we can see it as a SNC protection, in an= other words
> > >> 1:1 linear protection is using in sub-network).
> > >>
> > >> It does not provide any more simplicity and optimis= m than 1:1
> > >> linear protection. That is why we say this draft ca= nnot meet R100
> > >> of RFC5654 the requirement.
> > >>
> > >> So I don't think we need defined it in the ring dra= ft redundantly again.
> > >>
> > >> Best Regards,
> > >>
> > >> Cheng Weiqiang
> > >> Research Institute of China Mobile
>
_______________________________________________
mpls mailing list
 

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
--_000_4A1562797D64E44993C5CBF38CF1BE48EF37ESESSMB301ericssons_-- From martin.vigoureux@alcatel-lucent.com Fri Oct 5 04:32:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563E121F8665 for ; Fri, 5 Oct 2012 04:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbqrS7aLiN+i for ; Fri, 5 Oct 2012 04:32:58 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9509021F854C for ; Fri, 5 Oct 2012 04:32:58 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q95BVKd0018923 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 5 Oct 2012 13:32:54 +0200 Received: from [172.27.205.186] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 5 Oct 2012 13:32:53 +0200 Message-ID: <506EC565.6010602@alcatel-lucent.com> Date: Fri, 5 Oct 2012 13:32:53 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [mpls] Slots requests for IETF 85 - Atlanta X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:32:59 -0000 All, it is time we start building the MPLS WG agenda for Atlanta. The current IETF agenda, still subject to change, is available at: https://datatracker.ietf.org/meeting/85/agenda.txt The MPLS WG sessions are scheduled: Wednesday, Morning Session I, 09:00-11:30 and Thursday, Afternoon Session II, 15:10-17:10 Please send *me* (replying to this e-mail and copying the co-chairs) your request for a presentation slot, indicating: draft name, speaker and desired duration (presentation + Q&As). Please send the requests before October 24th. Thank you. Martin From chengwq@gmail.com Fri Oct 5 04:44:15 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F0C21F85C6 for ; Fri, 5 Oct 2012 04:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1TCcO7WhjO2 for ; Fri, 5 Oct 2012 04:44:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDA521F85C2 for ; Fri, 5 Oct 2012 04:44:08 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2020256vbb.31 for ; Fri, 05 Oct 2012 04:44:08 -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:content-transfer-encoding; bh=/eKBqCYhUMAGkTwSCYicQKe79vRz6t8773wM6hploM0=; b=CUvQBNvtFUuSInrpQRd0NmDsz8VTNBJJ9sD+VkxXOTSInWJ/ey7ClapgpHSb7yWBFG FnHUcfq2aBKCAD5v6VWeGFUgVC9pXtX7XJUR8JYYGoSP4rGmF4uxy/MhoUUb5VCPNLhN RK0ujpklpKNSLVZwxt+BL02Tv89WEfZG2UI87MXBFW2a8/Fl9cPrAk8HlDiOKSkyRNv4 V+k5azxshUDAKC3TSycIbAih9deM/pBnK7cUPfgHGaiY/LxfjmIFaXI+ssXlBxlBYGAc n9QZkI2rhDSuG6hdVrClRormuv/J5K6Ks8v0RnP91laINn1H4VMkexsEiGQslchafTNd m/wA== MIME-Version: 1.0 Received: by 10.52.31.99 with SMTP id z3mr4182552vdh.44.1349437447715; Fri, 05 Oct 2012 04:44:07 -0700 (PDT) Received: by 10.58.28.210 with HTTP; Fri, 5 Oct 2012 04:44:07 -0700 (PDT) In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48EF37@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48EF37@ESESSMB301.ericsson.se> Date: Fri, 5 Oct 2012 19:44:07 +0800 Message-ID: From: cheng weiqiang To: Daniele Ceccarelli Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:44:15 -0000 Dear Greg, et al., I would like to clarify the meaning of the 'multiple failures'. The Annex 1 of liaison-2012-10-03-itu-t-sg-15-mpls-requirements-and-analysis-of= -ring-protection-for-mpls-tp-networks is from the =93T09-SG15-C-2097 PTN requirements on Ring protection=94, and I am the author of the contribution and the figure was drawn by me. In that context, I intend to illustrate the ring protection have more capability on =91multiple failures=92. By default, the =91multiple failures= =92 include the adjacent links or nodes failure in single ring. Because both linear protections and all previous ring protection solutions can provide it already, I did not describe it at that time. As well known, the meaning of multiple failures is =93a single event may impact multiple failures including scenarios of both =93in single ring=94 and =93in multiple rings=94. Multiple failures in one ring should be the basic function. --=93fiber shared by multiple rings cut=94 in the ITU-T contribution gives the example of multiple failures in multiple rings -- "Micro-wave system impacted by whether and the nodes shared same power supply system " in the mail I wrote to Adrian as following link http://www.ietf.org/mail-archive/web/mpls/current/msg08804.html give the good examples of multiple failures in single ring. In one words, it is really essential function for MPLS-TP ring protection to support the multiple failures in single ring. B.R. Cheng Weiqiang 2012/10/5 Daniele Ceccarelli : > Hi Josh, > > in addition to what already said by Greg, the protection of interconnecte= d > rings is not in the scope of the ring protection applicability draft but = in > the scope of this one: > http://tools.ietf.org/id/draft-liu-mpls-tp-interconnected-ring-protection= -02.txt > > BR > Daniele > > ________________________________ > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rogers, Josh > Sent: gioved=EC 4 ottobre 2012 19.13 > To: Gregory Mirsky; cheng weiqiang; adrian@olddog.co.uk > > Cc: mpls@ietf.org > Subject: Re: [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection > > Greg, when I read ITU document, I suspected the concern about 'multiple > failures' was surrounding situations where a single event (fiber cut for > instance) may impact multiple rings (imagine two rings entering a facilit= y > at the same entry, possibly same sheath). The diagram showing failure > points 1, 2, 3, and 4 seemed to me to be relatively close, where a single > event could cause multiple impacts (break more than one ring). > > Of course, I'm guessing because it didn't appear all that clear that was = the > intent. > > From: Gregory Mirsky > Date: Thursday, October 4, 2012 11:46 AM > To: cheng weiqiang , "adrian@olddog.co.uk" > > Cc: "mpls@ietf.org" > Subject: Re: [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection > > Dear Cheng, et al., > I would note that "multiple failure" scenario, illustrated in Annex 1 of > liaison-2012-10-03-itu-t-sg-15-mpls-requirements-and-analysis-of-ring-pro= tection-for-mpls-tp-networks, > is, in my understanding, series of single failures in interconnected ring= s. > I believe that protection architectures described in the document under > discussion (wrapping, steering without and wit SPME) can be easily applie= d > to interconnected ring topology as presented in the Annex 1. I've noticed > that, referring to the Annex 1, that scenarios with dual failure on the s= ame > ring are not considered, i.e. failure at point 1 and 2 or 3 and 4. Should= it > be interpreted as "multiple failure" scenario implies failures in multipl= e > interconnected rings over which a protected path spans but with only sing= le > failure in any given ring of the chain? > > Regards, > Greg > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > cheng weiqiang > Sent: Thursday, October 04, 2012 4:02 AM > To: adrian@olddog.co.uk > Cc: mpls@ietf.org > Subject: Re: [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection > > Hi, > > R106 of RFC 5654 mentioned "SHOULD protect against multiple failures". > And well known, the multi-failures recovery is a basic function for ring > protection. And the double failures scenario I mentioned is the most basi= c > multiple failures condition. > > By the way, the wrapping solution of the draft cannot handle the adjacent > nodes failures also. > > I don't think they are corner cases. I give you some examples for your > reference. > > For the Micro-wave system, the adjacent hops often are impacted by whethe= r > or other facts at the same time. > > For the adjacent nodes, they often share the same power supply system. > When issues happen on power system, they may shut down simultaneous. > > So for the carrier grade system, the multi-failures scenarios I mentioned > should be the basic functionality. > > B.R. > > Cheng Weiqiang > From swallow@cisco.com Fri Oct 5 08:04:56 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788BF21F850D for ; Fri, 5 Oct 2012 08:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.348 X-Spam-Level: X-Spam-Status: No, score=-110.348 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHXvQjsMLc5D for ; Fri, 5 Oct 2012 08:04:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B649E21F84D8 for ; Fri, 5 Oct 2012 08:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9436; q=dns/txt; s=iport; t=1349449495; x=1350659095; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=PticM/XL01Suxb+ViXFRWkGydOcVIXKz4Ea6LaxcHuE=; b=d/noNdKbPoX0ydx4h2iFFcYkuexhT/H9iXicDDlriANtxX1/oMwcGpJu /xxFxBqoEiFuwJb5wOB67fNCFJflZT5/Y+c+YY1s5axSuURRszlcaRy0q TpHkOVhWidhyUUv41dLcLqCSQpqupZf4jtU6enNaEBAuQkeScJBYrFQFQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEX2blCtJV2Z/2dsb2JhbABFgku8VYEIgiABAQEDARIBGlENAQgRAwECCx05FAkIAQEEARIIAQsOh10GmC2gEos+hSlgA6ERgx+BaYJtghc X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208,217";a="125692439" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 05 Oct 2012 15:04:55 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q95F4te0028889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2012 15:04:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.77]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 10:04:54 -0500 From: "George Swallow (swallow)" To: "Doolan, Paul (NSN - US/Irving)" , "mpls@ietf.org" Thread-Topic: Concensus ? Thread-Index: Ac2hYANzh3Uvp/5fTiSnykUr6HfuQABsxQwA Date: Fri, 5 Oct 2012 15:04:54 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0F598ADD@xmb-rcd-x10.cisco.com> In-Reply-To: <44A5364BC1FA1E42B1F133529EC2C72902C22E96@CNBEEXC007.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.32.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--31.244800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_2FE467D3673DCE409A84D67EC2F607BB0F598ADDxmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [mpls] Concensus ? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 15:04:56 -0000 --_000_2FE467D3673DCE409A84D67EC2F607BB0F598ADDxmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Paul - To answer you question in general, note that the running code is conjoined= to rough consensus. Running code does a whole lot to dispel perceived def= iciencies. But short of running interoperable code, the consensus cannot b= e too rough. This is particularly true for a standards track document. For an Informational Document originating from the WG, the consensus needed= is more of the form, does the community believe that the document merits = publishing. As ever, it is up to the WG chairs to decide if there is WG consensus, and = the iESG whether there is IETF consensus. =85George From: , "Paul (NSN - US/Irving)" > Date: Wednesday, October 3, 2012 8:10 AM To: George Swallow >, "mpls@iet= f.org" > Subject: Concensus ? Hi George, Yesterday, with your chair hat on, you wrote: > The object is to fix the draft so that WG consensus can be achieved to mo= ve it forward. > If the WG consensus is that there are deficiencies and that the authors h= ave failed to address them then we would not have consensus. The last sentence is interesting, in an Alice in Wonderlandor Bertrand Russ= ell kind of way, but my question is about your use ofthe word=91concensus= =92 itself. The Tao document(www.ietf.org/tao.html)still = references Dave Clark=92s formulation=93rough concensus and running code=94= .Does this WG operate on thatroughstandard or thesmoother one you suggest? cheers, pd --_000_2FE467D3673DCE409A84D67EC2F607BB0F598ADDxmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <83AE3B8C6A0D89458B3CE73E905D74F0@cisco.com> Content-Transfer-Encoding: quoted-printable
Paul -

To answer you question in  general, note that the running code is= conjoined to rough consensus.  Running code does a whole lot to dispe= l perceived deficiencies.  But short of running interoperable code, th= e consensus cannot be too rough.
This is particularly true for a standards track document.
  
For an Informational Document originating from the WG, the consensus n= eeded is more of the form, does the community believe that the document mer= its  publishing.

As ever, it is up to the WG chairs to decide if there is WG consensus,= and the iESG whether there is IETF consensus.

=85George

From: <Doolan>, "Paul (N= SN - US/Irving)" <paul.doola= n@nsn.com>
Date: Wednesday, October 3, 2012 8:= 10 AM
To: George Swallow <swallow@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Concensus ?

Concensus ?

Hi George,

Yesterda= y, with your= chair hat on, you wrote:

> The object is to fix the = draft so that WG consensus can be achieved to move it forward.

> If the WG consensus is th= at there are deficiencies and that the authors have failed to address them then we would not have consensus.

The last sentence is interesting, in an Alice in Wonderlandor Bertrand Russell kind of way,= but my question is about your use ofthe word=91<= font face=3D"Times New Roman">concensus<= /span>=92= itself.

The Tao = document(www.ietf.org= /tao.html)still references Dave Clark=92s formulati= on=93rough concensus and running code=94.Does this WG operate on thatroughstandard= or thesmoother one you suggest?

cheers,

pd

 --_000_2FE467D3673DCE409A84D67EC2F607BB0F598ADDxmbrcdx10ciscoc_-- From internet-drafts@ietf.org Sun Oct 7 23:50:09 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C827421F874C; Sun, 7 Oct 2012 23:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKKgT2N+O5v4; Sun, 7 Oct 2012 23:50:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC05621F873D; Sun, 7 Oct 2012 23:49:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121008064942.20146.61168.idtracker@ietfa.amsl.com> Date: Sun, 07 Oct 2012 23:49:42 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 06:50:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Operations, Administration, and Management (OAM)= Identifiers Management Information Base (MIB) Author(s) : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Sami Boutros Ping Pan Filename : draft-ietf-mpls-tp-oam-id-mib-01.txt Pages : 26 Date : 2012-10-07 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes Operations, Administration, and Management (OAM) identifiers related managed objects for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-oam-id-mib-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Thomas.Beckhaus@telekom.de Mon Oct 8 00:42:45 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A79B21F8736 for ; Mon, 8 Oct 2012 00:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.248 X-Spam-Level: X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktWpG-KolFl8 for ; Mon, 8 Oct 2012 00:42:44 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F021F8712 for ; Mon, 8 Oct 2012 00:42:42 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 08 Oct 2012 09:42:40 +0200 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.13]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 8 Oct 2012 09:42:40 +0200 From: To: , Date: Mon, 8 Oct 2012 09:42:39 +0200 Thread-Topic: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03 Thread-Index: Ac1kZhp9XIdWunBHSdKPU4kWq0pFlg8SLf4wAR4knjA= Message-ID: References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_AAE428925197FE46A5F94ED6643478FEA9CE13D15EHE111644EMEA1_" MIME-Version: 1.0 Cc: mpls@ietf.org, giheron@cisco.com, lizhong.jin@zte.com.cn Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 07:42:45 -0000 --_000_AAE428925197FE46A5F94ED6643478FEA9CE13D15EHE111644EMEA1_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ross, Pranjal, the internet draft is easy to read. Good description about the motivation a= nd the protocol procedures in section 3. Yes, it addresses my issues. Some minor editorial topics: - 1st section, last sentence in 4th paragraph: LDP in lower letter - 4th section (IANA=85): The note to editors should be deleted - 5th section (security): the structure of this section could be better - 6th section, 1st paragraph: typo: "tunring" instead of "turning" - 6th section, last paragraph: I do not know the word "cloure", unless you = do not mean the catalan "cloure". Regards Thomas ________________________________ From: Ross Callon [mailto:rcallon@juniper.net] Sent: Tuesday, October 02, 2012 7:52 PM To: Markus Jork; lizhong.jin@zte.com.cn; Beckhaus, Thomas; mpls@ietf.org; E= ric (erosen) Rosen Cc: Dutta, Pranjal K (Pranjal); Giles Heron; Thomas Nadeau; loa@pi.nu; swal= low@cisco.com; Martin Vigoureux; Ross Callon Subject: RE: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03 For the three MPLS-RT reviewers of draft-pdutta-mpls-tldp-hello-reduce, and= for anyone on the MPLS email list who has commented on this draft, can you= check the update and see whether the recent update of the draft (draft-pdu= tta-mpls-tldp-hello-reduce-04, posted September 1) addresses your issues? Thanks, Ross _____________________________________________ From: Ross Callon Sent: Tuesday, July 17, 2012 5:50 PM To: Markus Jork; lizhong.jin@zte.com.cn; Thomas.Beckhaus@telekom.de Cc: loa@pi.nu; swallow@cisco.com; Ross Callon; Martin Vigoureux; Dutta, Pra= njal K (Pranjal); Giles Heron; Thomas Nadeau Subject: MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03 Markus, Lizhong, Thomas; You have been selected as an MPLS Review team reviewers for draft-pdutta-mpls-tldp-hello-reduce-03 Note to authors: You have been CC=92d on this email so that you can know th= at this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn=92t have t= o be perfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and secretary, and CC=92d to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. Are you able to review this draft by August 3, 2012 (ie, the end of the IET= F meeting in Vancouver)? We understand that this is somewhat short notice and that you might have something else to do the week of the IETF, so let us know if you need slightly more time. Thanks, Ross (as MPLS WG chair) PS: I noticed that Tom Nadeau=92s email address listed in the draft is out = of date. This email is being CC=92d to his updated address. --_000_AAE428925197FE46A5F94ED6643478FEA9CE13D15EHE111644EMEA1_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Ross, Pranjal,
 
the internet draft is easy to read. = Good=20 description about the motivation and the p= rotocol=20 procedures in section 3. Yes, it addresses my issues.<= /DIV>

Some minor editorial topics:

- 1st section, last sentence in 4th paragr= aph: LDP=20 in lower letter
- 4th section (IANA=85): The note to edito= rs should=20 be deleted
- 5th section (security): the structure of= this=20 section could be better
- 6th section, 1st paragraph: typo: "tunri= ng"=20 instead of "turning"
- 6th section, last paragraph: I do not kn= ow the=20 word "cloure", unless you do not mean the catalan=20 "cloure".
 
Regards

Thomas

From: Ross Callon [mailto:rcallon@jun= iper.net]=20
Sent: Tuesday, October 02, 2012 7:52 PM
To: Markus J= ork;=20 lizhong.jin@zte.com.cn; Beckhaus, Thomas; mpls@ietf.org; Eric (erosen)=20 Rosen
Cc: Dutta, Pranjal K (Pranjal); Giles Heron; Thomas Nadea= u;=20 loa@pi.nu; swallow@cisco.com; Martin Vigoureux; Ross Callon
Subject= :=20 RE: MPLS-RT review of=20 draft-pdutta-mpls-tldp-hello-reduce-03

For the three MPLS-RT reviewers of=20 draft-pdutta-mpls-tldp-hello-reduce, and for anyone on the MPLS email lis= t who=20 has commented on this draft, can you check the update and see whether the= =20 recent update of the draft (draft-pdutta-mpls-tldp-hello-reduce-04, posted September 1)= =20 addresses your issues?
 
Thanks, Ross
_____________________________________________=
From:=20 Ross Callon
Sent: Tuesday, July 17, 2012 5:50 PM
To:= =20 Markus Jork; lizhong.jin@zte.com.cn; Thomas.Beckhaus@telekom.de
Cc:= =20 loa@pi.nu; swallow@cisco.com; Ross Callon; Martin Vigoureux; Dutta, Pranj= al K=20 (Pranjal); Giles Heron; Thomas Nadeau
Subject: MPLS-RT review o= f=20 draft-pdutta-mpls-tldp-hello-reduce-03
 
 
Markus, Lizhong,=20 Thomas;
 
You have been selected a= s an MPLS=20 Review team reviewers for
draft-pdutta-mpls-tldp-hello-reduce-03
 
Note to authors: You hav= e been=20 CC=92d on this email so that you can know that
this review is going on.= However,=20 please do not review your own document.
 
Reviews should comment o= n whether=20 the document is coherent, is it useful
(ie, is it likely to be = actually=20 useful in operational networks), and is
the document technically= =20 sound?  We are interested in knowing whether the
document is ready to be= =20 considered for WG adoption (ie, it doesn=92t have to
be perfect at this point= , but=20 should be a good start).
 
Reviews should be sent t= o the=20 document authors, WG co-chairs and secretary,
and CC=92d to the MPLS W= G email=20 list. If necessary, comments may be sent
privately to only the WG= chairs.=20
 
Are you able to review t= his draft=20 by August 3, 2012 (ie, the end of the IETF
meeting in Vancouver)? W= e=20 understand that this is somewhat short notice and 
that you might have some= thing=20 else to do the week of the IETF, so let us
know if you need slightl= y more=20 time.
 
Thanks, Ross
(as MPLS WG chair)
 
PS: I noticed that Tom Nadeau=92s= email=20 address listed in the draft is out of date. This email is being CC=92d to= his=20 updated address.
 
= --_000_AAE428925197FE46A5F94ED6643478FEA9CE13D15EHE111644EMEA1_-- From lizhong.jin@zte.com.cn Mon Oct 8 00:43:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69B721F8620 for ; Mon, 8 Oct 2012 00:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.721 X-Spam-Level: X-Spam-Status: No, score=-101.721 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+xw4I9-w43q for ; Mon, 8 Oct 2012 00:43:52 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B733A21F8551 for ; Mon, 8 Oct 2012 00:43:51 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 614861935728; Mon, 8 Oct 2012 15:43:38 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 1B8704B09E0; Mon, 8 Oct 2012 15:40:23 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q987hOTP035410; Mon, 8 Oct 2012 15:43:24 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Ross Callon MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Mon, 8 Oct 2012 15:43:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-08 15:43:26, Serialize complete at 2012-10-08 15:43:26 Content-Type: multipart/alternative; boundary="=_alternative 002A6C7348257A91_=" X-MAIL: mse02.zte.com.cn q987hOTP035410 Cc: "mpls@ietf.org" , Giles Heron , Ross Callon Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 07:43:53 -0000 This is a multipart message in MIME format. --=_alternative 002A6C7348257A91_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUm9zcywNCkxvb2tzIGZpbmUgZm9yIG1lIG5vdy4NCg0KVGhhbmtzDQpMaXpob25nDQogDQoN ClJvc3MgQ2FsbG9uIDxyY2FsbG9uQGp1bmlwZXIubmV0PiB3cm90ZSAyMDEyLzEwLzAzIDAxOjUx OjM2Og0KDQo+IEZvciB0aGUgdGhyZWUgTVBMUy1SVCByZXZpZXdlcnMgb2YgZHJhZnQtcGR1dHRh LW1wbHMtdGxkcC1oZWxsby0NCj4gcmVkdWNlLCBhbmQgZm9yIGFueW9uZSBvbiB0aGUgTVBMUyBl bWFpbCBsaXN0IHdobyBoYXMgY29tbWVudGVkIG9uIA0KPiB0aGlzIGRyYWZ0LCBjYW4geW91IGNo ZWNrIHRoZSB1cGRhdGUgYW5kIHNlZSB3aGV0aGVyIHRoZSByZWNlbnQgDQo+IHVwZGF0ZSBvZiB0 aGUgZHJhZnQgKGRyYWZ0LXBkdXR0YS1tcGxzLXRsZHAtaGVsbG8tcmVkdWNlLTA0LCBwb3N0ZWQg DQo+IFNlcHRlbWJlciAxKSBhZGRyZXNzZXMgeW91ciBpc3N1ZXM/IA0KPiANCj4gVGhhbmtzLCBS b3NzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBG cm9tOiBSb3NzIENhbGxvbiANCj4gU2VudDogVHVlc2RheSwgSnVseSAxNywgMjAxMiA1OjUwIFBN DQo+IFRvOiBNYXJrdXMgSm9yazsgbGl6aG9uZy5qaW5AenRlLmNvbS5jbjsgVGhvbWFzLkJlY2to YXVzQHRlbGVrb20uZGUNCj4gQ2M6IGxvYUBwaS5udTsgc3dhbGxvd0BjaXNjby5jb207IFJvc3Mg Q2FsbG9uOyBNYXJ0aW4gVmlnb3VyZXV4OyANCj4gRHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCk7 IEdpbGVzIEhlcm9uOyBUaG9tYXMgTmFkZWF1DQo+IFN1YmplY3Q6IE1QTFMtUlQgcmV2aWV3IG9m IGRyYWZ0LXBkdXR0YS1tcGxzLXRsZHAtaGVsbG8tcmVkdWNlLTAzDQo+IA0KPiANCj4gTWFya3Vz LCBMaXpob25nLCBUaG9tYXM7DQo+IA0KPiBZb3UgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIGFuIE1Q TFMgUmV2aWV3IHRlYW0gcmV2aWV3ZXJzIGZvcg0KPiBkcmFmdC1wZHV0dGEtbXBscy10bGRwLWhl bGxvLXJlZHVjZS0wMw0KPiANCj4gTm90ZSB0byBhdXRob3JzOiBZb3UgaGF2ZSBiZWVuIENDoa9k IG9uIHRoaXMgZW1haWwgc28gdGhhdCB5b3UgY2FuIGtub3cgDQp0aGF0IA0KPiB0aGlzIHJldmll dyBpcyBnb2luZyBvbi4gSG93ZXZlciwgcGxlYXNlIGRvIG5vdCByZXZpZXcgeW91ciBvd24gDQpk b2N1bWVudC4gDQo+IA0KPiBSZXZpZXdzIHNob3VsZCBjb21tZW50IG9uIHdoZXRoZXIgdGhlIGRv Y3VtZW50IGlzIGNvaGVyZW50LCBpcyBpdCB1c2VmdWwNCj4gKGllLCBpcyBpdCBsaWtlbHkgdG8g YmUgYWN0dWFsbHkgdXNlZnVsIGluIG9wZXJhdGlvbmFsIG5ldHdvcmtzKSwgYW5kIGlzDQo+IHRo ZSBkb2N1bWVudCB0ZWNobmljYWxseSBzb3VuZD8gIFdlIGFyZSBpbnRlcmVzdGVkIGluIGtub3dp bmcgd2hldGhlciANCnRoZSANCj4gZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgY29uc2lkZXJlZCBm b3IgV0cgYWRvcHRpb24gKGllLCBpdCBkb2VzbqGvdCBoYXZlIA0KdG8NCj4gYmUgcGVyZmVjdCBh dCB0aGlzIHBvaW50LCBidXQgc2hvdWxkIGJlIGEgZ29vZCBzdGFydCkuIA0KPiANCj4gUmV2aWV3 cyBzaG91bGQgYmUgc2VudCB0byB0aGUgZG9jdW1lbnQgYXV0aG9ycywgV0cgY28tY2hhaXJzIGFu ZCANCnNlY3JldGFyeSwNCj4gYW5kIENDoa9kIHRvIHRoZSBNUExTIFdHIGVtYWlsIGxpc3QuIElm IG5lY2Vzc2FyeSwgY29tbWVudHMgbWF5IGJlIHNlbnQgDQo+IHByaXZhdGVseSB0byBvbmx5IHRo ZSBXRyBjaGFpcnMuIA0KPiANCj4gQXJlIHlvdSBhYmxlIHRvIHJldmlldyB0aGlzIGRyYWZ0IGJ5 IEF1Z3VzdCAzLCAyMDEyIChpZSwgdGhlIGVuZCBvZiB0aGUgDQpJRVRGIA0KPiBtZWV0aW5nIGlu IFZhbmNvdXZlcik/IFdlIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIHNvbWV3aGF0IHNob3J0IG5v dGljZSANCmFuZCANCj4gdGhhdCB5b3UgbWlnaHQgaGF2ZSBzb21ldGhpbmcgZWxzZSB0byBkbyB0 aGUgd2VlayBvZiB0aGUgSUVURiwgc28gbGV0IHVzIA0KDQo+IGtub3cgaWYgeW91IG5lZWQgc2xp Z2h0bHkgbW9yZSB0aW1lLiANCj4gDQo+IFRoYW5rcywgUm9zcw0KPiAoYXMgTVBMUyBXRyBjaGFp cikNCj4gDQo+IFBTOiBJIG5vdGljZWQgdGhhdCBUb20gTmFkZWF1oa9zIGVtYWlsIGFkZHJlc3Mg bGlzdGVkIGluIHRoZSBkcmFmdCBpcw0KPiBvdXQgb2YgZGF0ZS4gVGhpcyBlbWFpbCBpcyBiZWlu ZyBDQ6GvZCB0byBoaXMgdXBkYXRlZCBhZGRyZXNzLiANCj4gDQo= --=_alternative 002A6C7348257A91_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJvc3MsPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Mb29rcyBmaW5lIGZvciBtZSBub3cuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3M8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxpemhvbmc8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Um9zcyBDYWxsb24gJmx0O3JjYWxsb25A anVuaXBlci5uZXQmZ3Q7DQp3cm90ZSAyMDEyLzEwLzAzIDAxOjUxOjM2Ojxicj4NCjxicj4NCiZn dDsgRm9yIHRoZSB0aHJlZSBNUExTLVJUIHJldmlld2VycyBvZiBkcmFmdC1wZHV0dGEtbXBscy10 bGRwLWhlbGxvLTxicj4NCiZndDsgcmVkdWNlLCBhbmQgZm9yIGFueW9uZSBvbiB0aGUgTVBMUyBl bWFpbCBsaXN0IHdobyBoYXMgY29tbWVudGVkIG9uDQo8YnI+DQomZ3Q7IHRoaXMgZHJhZnQsIGNh biB5b3UgY2hlY2sgdGhlIHVwZGF0ZSBhbmQgc2VlIHdoZXRoZXIgdGhlIHJlY2VudCA8YnI+DQom Z3Q7IHVwZGF0ZSBvZiB0aGUgZHJhZnQgKGRyYWZ0LXBkdXR0YS1tcGxzLXRsZHAtaGVsbG8tcmVk dWNlLTA0LCBwb3N0ZWQNCjxicj4NCiZndDsgU2VwdGVtYmVyIDEpIGFkZHJlc3NlcyB5b3VyIGlz c3Vlcz8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBUaGFu a3MsIFJvc3M8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBG cm9tOiBSb3NzIENhbGxvbiA8YnI+DQomZ3Q7IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTcsIDIwMTIg NTo1MCBQTTxicj4NCiZndDsgVG86IE1hcmt1cyBKb3JrOyBsaXpob25nLmppbkB6dGUuY29tLmNu OyBUaG9tYXMuQmVja2hhdXNAdGVsZWtvbS5kZTxicj4NCiZndDsgQ2M6IGxvYUBwaS5udTsgc3dh bGxvd0BjaXNjby5jb207IFJvc3MgQ2FsbG9uOyBNYXJ0aW4gVmlnb3VyZXV4OyA8YnI+DQomZ3Q7 IER1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpOyBHaWxlcyBIZXJvbjsgVGhvbWFzIE5hZGVhdTxi cj4NCiZndDsgU3ViamVjdDogTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtcGR1dHRhLW1wbHMtdGxk cC1oZWxsby1yZWR1Y2UtMDM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZndDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jmd0OyBNYXJrdXMsIExpemhvbmcsIFRob21hczs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZndDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mZ3Q7IFlvdSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgYW4gTVBMUw0KUmV2 aWV3IHRlYW0gcmV2aWV3ZXJzIGZvcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jmd0OyBkcmFmdC1wZHV0dGEtbXBscy10bGRwLWhlbGxvLXJlZHVjZS0wMzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAmbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgTm90ZSB0byBhdXRob3Jz OiBZb3UgaGF2ZSBiZWVuDQpDQ6GvZCBvbiB0aGlzIGVtYWlsIHNvIHRoYXQgeW91IGNhbiBrbm93 IHRoYXQgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IHRo aXMgcmV2aWV3IGlzIGdvaW5nIG9uLiBIb3dldmVyLA0KcGxlYXNlIGRvIG5vdCByZXZpZXcgeW91 ciBvd24gZG9jdW1lbnQuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jmd0OyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZndDsgUmV2aWV3cyBzaG91bGQgY29tbWVudCBvbiB3aGV0aGVyDQp0aGUgZG9jdW1lbnQgaXMg Y29oZXJlbnQsIGlzIGl0IHVzZWZ1bDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jmd0OyAoaWUsIGlzIGl0IGxpa2VseSB0byBiZSBhY3R1YWxseQ0KdXNlZnVsIGlu IG9wZXJhdGlvbmFsIG5ldHdvcmtzKSwgYW5kIGlzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IHRoZSBkb2N1bWVudCB0ZWNobmljYWxseSBzb3VuZD8NCiZu YnNwO1dlIGFyZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgd2hldGhlciB0aGUgPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IGRvY3VtZW50IGlzIHJlYWR5IHRv IGJlIGNvbnNpZGVyZWQNCmZvciBXRyBhZG9wdGlvbiAoaWUsIGl0IGRvZXNuoa90IGhhdmUgdG88 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgYmUgcGVyZmVj dCBhdCB0aGlzIHBvaW50LCBidXQgc2hvdWxkDQpiZSBhIGdvb2Qgc3RhcnQpLiA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IFJldmlld3Mgc2hvdWxkIGJlIHNl bnQgdG8gdGhlIGRvY3VtZW50DQphdXRob3JzLCBXRyBjby1jaGFpcnMgYW5kIHNlY3JldGFyeSw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgYW5kIENDoa9k IHRvIHRoZSBNUExTIFdHIGVtYWlsDQpsaXN0LiBJZiBuZWNlc3NhcnksIGNvbW1lbnRzIG1heSBi ZSBzZW50IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBw cml2YXRlbHkgdG8gb25seSB0aGUgV0cgY2hhaXJzLg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBBcmUgeW91IGFibGUgdG8gcmV2aWV3IHRoaXMgZHJhZnQN CmJ5IEF1Z3VzdCAzLCAyMDEyIChpZSwgdGhlIGVuZCBvZiB0aGUgSUVURiA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgbWVldGluZyBpbiBWYW5jb3V2ZXIp PyBXZSB1bmRlcnN0YW5kDQp0aGF0IHRoaXMgaXMgc29tZXdoYXQgc2hvcnQgbm90aWNlIGFuZCAm bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgdGhh dCB5b3UgbWlnaHQgaGF2ZSBzb21ldGhpbmcgZWxzZQ0KdG8gZG8gdGhlIHdlZWsgb2YgdGhlIElF VEYsIHNvIGxldCB1cyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZndDsga25vdyBpZiB5b3UgbmVlZCBzbGlnaHRseSBtb3JlDQp0aW1lLiA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IFRoYW5rcywgUm9zczwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAoYXMgTVBMUyBXRyBjaGFpcik8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IFBTOiBJIG5vdGlj ZWQgdGhhdCBUb20gTmFkZWF1oa9zDQplbWFpbCBhZGRyZXNzIGxpc3RlZCBpbiB0aGUgZHJhZnQg aXM8YnI+DQomZ3Q7IG91dCBvZiBkYXRlLiBUaGlzIGVtYWlsIGlzIGJlaW5nIENDoa9kIHRvIGhp cyB1cGRhdGVkIGFkZHJlc3MuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jmd0OyAmbmJzcDs8L2ZvbnQ+DQo= --=_alternative 002A6C7348257A91_=-- From curtis@occnc.com Mon Oct 8 15:20:45 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A373D11E80FE for ; Mon, 8 Oct 2012 15:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zII2+K4xXLXE for ; Mon, 8 Oct 2012 15:20:44 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 9153411E80E3 for ; Mon, 8 Oct 2012 15:20:44 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q98MKZTK035537; Mon, 8 Oct 2012 18:20:36 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210082220.q98MKZTK035537@gateway1.orleans.occnc.com> To: mpls@ietf.org From: Curtis Villamizar Date: Mon, 08 Oct 2012 18:20:35 -0400 Subject: [mpls] Updates to draft-villamizar-mpls-tp-multipath drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 22:20:45 -0000 Please take a look at the draft-villamizar-mpls-tp-multipath drafts. There are two and they are both recently revised. The changes are substantial. Essentially, Entropy Label is downselected as the best way to support LSP with strict packet ordering requirements (which includes MPLS-TP LSP) over MPLS LSP that make use of multipath links. draft-villamizar-mpls-tp-multipath-03 shrunk from 25 pages to 9 pages for the following reasons: 1. It mainly makes a few simple points: a. MPLS-TP in MPLS and MPLS in MPLS-TP are called for as requirements in RFC 5654 requirement 33. b. Entropy Label provides a means of carrying MPLS-TP client LSP within a MPLS server layer LSP and offering a fully MPLS-TP compliant server layer. c. MPLS client LSP can be carried within MPLS-TP server layer LSP with limitations described in the draft. 2. Lengthy statement of multipath requirements are no longer necessary if we accept that Entropy Label does something useful and therefore needed to become and RFC. Large sections were removed from the draft. 3. Lengthy discussion of requirements tradeoffs and scalability considerations were removed from the draft. 4. Discussion of alternatives was removed from the draft. Only using Entropy Label to carry MPLS-TP client LSP within a MPLS server layer LSP is considered. Therefore draft-villamizar-mpls-tp-multipath-03 is now a short read and should be non-controversial (I hope). There is some mention in draft-villamizar-mpls-tp-multipath-03 of limitations in the absense of any protocol extensions. The update to draft-villamizar-mpls-tp-multipath-te-extn reflects the use of ELI and EL and the elimination of some alternatives and is simplified as a result. The purpose of the extensions is to determine at CSPF time where in the topology limitations exist (such as legacy multipath with no EL support - LAG for example) and figuring out when large microflows are going to be a problem. The Infinera IPR statement no longer applies since Entropy Label is being used rather than the forwarding change that I had proposed while at Infinera. There is no way to completely remove an IPR statement so I will rename the drafts after the IETF meeting. I would like the WG to be aware of the change and why the IPR no longer applies. I have made a request to make a presentation about the changes at the Atlanta IETF. I would like the work group, after the IETF meeting, to consider at least draft-villamizar-mpls-tp-multipath-03 as a WG document and preferabley both. Prior to the upcoming IETF meeting, discussion on the WG list (preferred) or private email would be greatly appreciated. Thanks, Curtis ------- Forwarded Messages From: internet-drafts@ietf.org To: curtis@occnc.com Subject: New Version Notification for draft-villamizar-mpls-tp-multipath-03.txt A new version of I-D, draft-villamizar-mpls-tp-multipath-03.txt has been successfully submitted by Curtis Villamizar and posted to the IETF repository. Filename: draft-villamizar-mpls-tp-multipath Revision: 03 Title: Use of Multipath with MPLS-TP and MPLS Creation date: 2012-10-02 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-villamizar-mpls-tp-multipath-03.txt Status: http://datatracker.ietf.org/doc/draft-villamizar-mpls-tp-multipath Htmlized: http://tools.ietf.org/html/draft-villamizar-mpls-tp-multipath-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-villamizar-mpls-tp-multipath-03 Abstract: Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over many types of multipath implementations. Using MPLS Entropy label, MPLS can LSP can be carried over multipath links while also providing a fully MPLS-TP compliant server layer for MPLS-TP LSP. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSP as a server layer for MPLS LSP is also discussed. The IETF Secretariat ------- Message 2 From: internet-drafts@ietf.org To: curtis@occnc.com Subject: New Version Notification for draft-villamizar-mpls-tp-multipath-te-extn-02.txt A new version of I-D, draft-villamizar-mpls-tp-multipath-te-extn-02.txt has been successfully submitted by Curtis Villamizar and posted to the IETF repository. Filename: draft-villamizar-mpls-tp-multipath-te-extn Revision: 02 Title: Multipath Extensions for MPLS Traffic Engineering Creation date: 2012-10-07 WG ID: Individual Submission Number of pages: 30 URL: http://www.ietf.org/internet-drafts/draft-villamizar-mpls-tp-multipath-te-extn-02.txt Status: http://datatracker.ietf.org/doc/draft-villamizar-mpls-tp-multipath-te-extn Htmlized: http://tools.ietf.org/html/draft-villamizar-mpls-tp-multipath-te-extn-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-villamizar-mpls-tp-multipath-te-extn-02 Abstract: Extensions to OSPF-TE, ISIS-TE, and RSVP-TE are defined in support of carrying LSP with strict packet ordering requirements over multipath and and carrying LSP with strict packet ordering requirements within LSP without violating requirements to maintain packet ordering. LSP with strict packet ordering requirements include MPLS-TP LSP. OSPF-TE and ISIS-TE extensions defined here indicate node and link capability regarding support for ordered aggregates of traffic, multipath traffic distribution, and abilities to support multipath load distribution differently per LSP. RSVP-TE extensions either identifies an LSP as requiring strict packet order, or identifies an LSP as carrying one or more LSP that requires strict packet order further down in the label stack, or identifies an LSP as having no restrictions on packet ordering except the restriction to avoid reordering microflows. In addition an extension indicates whether the first nibble of payload will reliably indicate whether payload is IPv4, IPv6, or other type of payload, most notably pseudowire using a pseudowire control word. The IETF Secretariat ------- End of Forwarded Messages From kireeti.kompella@gmail.com Mon Oct 8 17:30:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797BA11E80EA for ; Mon, 8 Oct 2012 17:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqzTbPp3uwgH for ; Mon, 8 Oct 2012 17:30:36 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id A78B011E80A3 for ; Mon, 8 Oct 2012 17:30:36 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so4528680pad.31 for ; Mon, 08 Oct 2012 17:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :cc:to:x-mailer; bh=UexRaae29Vd3W+xt8gXrOSClWHFrKcNie5oeeOOVhUs=; b=F1sy2L4sDJKEId8MFnjU7wuOamV+mWRDSCTnmpBLNoUoxY0XXqN21CJjYkmzU6LkcD CqtbAYCNtAminH8VOJAg5MF1UqLG2pbXCW/nvWqueYctUZnyiuYKiFIKvPAHwvVMrdgJ nrTPfIJ+c8HI2W2PUJ6dILu/KnC4/LmEXVBOd38gHMZTIWUbrpLCmcE1SZjeIbiv03j6 Nhg2QKgkZEpB7zsXIvuJMCCmQlVccBhWOZKwZwX0c/JluayyhkabkCybRacB2sQrvOAP JFgHX1FQF+vbqOxvBrBFRa89lI8O7NKHiGCvGlOgYaMK2xCS2yYD6KjnlMO6IxeREa6p 0YYA== Received: by 10.68.222.40 with SMTP id qj8mr57207684pbc.139.1349742636388; Mon, 08 Oct 2012 17:30:36 -0700 (PDT) Received: from [10.1.2.200] ([108.60.97.219]) by mx.google.com with ESMTPS id rw5sm11437856pbc.54.2012.10.08.17.30.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 17:30:34 -0700 (PDT) From: Kireeti Kompella Content-Type: multipart/alternative; boundary="Apple-Mail=_0A70DA65-E60C-4E8F-A30D-FD4817AFA12E" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Date: Mon, 8 Oct 2012 17:30:37 -0700 References: <20121008234908.29887.1630.idtracker@ietfa.amsl.com> To: "mpls@ietf.org" X-Mailer: Apple Mail (2.1498) Subject: [mpls] Fwd: New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 00:30:37 -0000 --Apple-Mail=_0A70DA65-E60C-4E8F-A30D-FD4817AFA12E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Folks, I'd spoken on the issue of deep label stacks at the last IETF, and there = was interest from chip suppliers, vendors and service providers. Curtis = just submitted the draft; it goes beyond just deep label stacks. There = are suggestions in the draft on aspects of implementing MPLS forwarding, = as well as questions to ask regarding an implementation, and things to = test. Please read and comment to the list. =20 If you (that includes MPLS WG chairs and ADs) could also formulate your = thoughts on what type of doc (Info, BCP, PS) this should be, that would = be very helpful in moving this discussion forward. Thanks, Kireeti. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-villamizar-mpls-forwarding-00.txt > Date: October 8, 2012 16:49:08PDT > To: curtis@occnc.com > Cc: kireeti.kompella@gmail.com >=20 >=20 > A new version of I-D, draft-villamizar-mpls-forwarding-00.txt > has been successfully submitted by Curtis Villamizar and posted to the > IETF repository. >=20 > Filename: draft-villamizar-mpls-forwarding > Revision: 00 > Title: MPLS Forwarding Compliance and Performance = Requirements > Creation date: 2012-10-08 > WG ID: Individual Submission > Number of pages: 17 > URL: = http://www.ietf.org/internet-drafts/draft-villamizar-mpls-forwarding-00.tx= t > Status: = http://datatracker.ietf.org/doc/draft-villamizar-mpls-forwarding > Htmlized: = http://tools.ietf.org/html/draft-villamizar-mpls-forwarding-00 >=20 >=20 > Abstract: > This document provides guidelines for implementors regarding MPLS > forwarding and a basis for evaluations of forwarding = implementations. > Guidelines cover basic MPLS forwarding, forwarding when a deep MPLS > label stack is encountered, MPLS UHP operations which require one or > more label POP plus a PUSH, guidelines for hashing an MPLS stack and > payload for multipath, and conformance and performance requirements > for recent pseudowire and MPLS standards. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --Apple-Mail=_0A70DA65-E60C-4E8F-A30D-FD4817AFA12E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Folks,

I'd spoken on the issue of deep label stacks = at the last IETF, and there was interest from chip suppliers, vendors = and service providers.  Curtis just submitted the draft; it goes = beyond just deep label stacks.  There are suggestions in the draft = on aspects of implementing MPLS forwarding, as well as questions to ask = regarding an implementation, and things to = test.

Please read and comment to the list. =  

If you (that includes MPLS WG chairs and = ADs) could also  formulate your thoughts on what type of doc (Info, = BCP, PS) this should be, that would be very helpful in moving this = discussion = forward.

Thanks,
Kireeti.

Begin forwarded message:

Subject: New Version Notification for = draft-villamizar-mpls-forwarding-00.txt
Date: October 8, 2012 = 16:49:08PDT
Cc: kireeti.kompella@gmail.com<= br>


A new version of I-D, = draft-villamizar-mpls-forwarding-00.txt
has been successfully = submitted by Curtis Villamizar and posted to the
IETF = repository.

Filename: = draft-villamizar-mpls-forwarding
Revision: = 00
Title: = = MPLS Forwarding Compliance and Performance = Requirements
Creation date: 2012-10-08
WG ID: = Individual Submission
Number of pages: 17
URL: =             http://www.ietf.org/internet-drafts/draft-villamizar-mpls-forwa= rding-00.txt
Status: =          = http://datatracker.ietf.org/doc/draft-villamizar-mpls-forwarding
Ht= mlized:        ht= tp://tools.ietf.org/html/draft-villamizar-mpls-forwarding-00

Abstract:
  This document provides guidelines for = implementors regarding MPLS
  forwarding and a basis for = evaluations of forwarding implementations.
  Guidelines = cover basic MPLS forwarding, forwarding when a deep MPLS
=   label stack is encountered, MPLS UHP operations which = require one or
  more label POP plus a PUSH, guidelines = for hashing an MPLS stack and
  payload for multipath, and = conformance and performance requirements
  for recent = pseudowire and MPLS standards.




The IETF = Secretariat


= --Apple-Mail=_0A70DA65-E60C-4E8F-A30D-FD4817AFA12E-- From xuxiaohu@huawei.com Tue Oct 9 02:51:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C6821F882F for ; Tue, 9 Oct 2012 02:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.355 X-Spam-Level: X-Spam-Status: No, score=-4.355 tagged_above=-999 required=5 tests=[AWL=1.644, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-TbAhA+Ao+P for ; Tue, 9 Oct 2012 02:51:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 172AB21F84FC for ; Tue, 9 Oct 2012 02:51:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALL62769; Tue, 09 Oct 2012 09:51:50 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 9 Oct 2012 10:51:18 +0100 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 9 Oct 2012 17:51:32 +0800 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.168]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Tue, 9 Oct 2012 17:50:38 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-xu-mpls-in-udp-03.txt Thread-Index: AQHNpRpzYHFvCj+hLk6DE5y11ucLmZevCcpA Date: Tue, 9 Oct 2012 09:50:38 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0755EA77@szxeml525-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.111.98.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] fwd: New Version Notification for draft-xu-mpls-in-udp-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 09:51:53 -0000 SGkgYWxsLA0KDQpBbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhpcyBkcmFmdCBoYXMgYmVlbiBzdWJt aXR0ZWQuIFRoaXMgcmV2aXNpb24gaW5jb3Jwb3JhdGVzIGFsbCB0aGUgY29tbWVudHMgdGhhdCBo YXZlIGJlZW4gcmVjZWl2ZWQgc2luY2UgdGhlIGZpcnN0IHByZXNlbnRhdGlvbiBvZiB0aGlzIGRy YWZ0IGF0IElFVEY4NC4NCg0KVGhhbmtzIGFnYWluIGZvciB0aG9zZSBmb2xrcyB3aG8gaGF2ZSBn aXZlbiB1cyB2YWx1YWJsZSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgb24gdGhpcyBkcmFmdC4g QW55IGZ1cnRoZXIgY29tbWVudHMgYXJlIG1vcmUgdGhhbiB3ZWxjb21lLg0KDQpCZXN0IHJlZ2Fy ZHMsDQpYaWFvaHUgKG9uIGJlaGFsZiBvZiBhbGwgY28tYXV0aG9ycykNCg0KPiAtLS0tLemCruS7 tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTLlubQxMOac iDjml6UgMTQ6MDINCj4g5pS25Lu25Lq6OiBYdXhpYW9odQ0KPiDmioTpgIE6IGZhbnliQGdzdGEu Y29tOyBuc2hldGhAanVuaXBlci5uZXQ7IEx1Y3kgeW9uZzsNCj4gbWFyc2hhbGwuZXViYW5rc0Bn bWFpbC5jb207IExpemhlbmJpbg0KPiDkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQteHUtbXBscy1pbi11ZHAtMDMudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTAzLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IFhpYW9odSBYdSBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9z aXRvcnkuDQo+IA0KPiBGaWxlbmFtZToJIGRyYWZ0LXh1LW1wbHMtaW4tdWRwDQo+IFJldmlzaW9u OgkgMDMNCj4gVGl0bGU6CQkgRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUA0KPiBDcmVhdGlvbiBk YXRlOgkgMjAxMi0xMC0wOA0KPiBXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gTnVt YmVyIG9mIHBhZ2VzOiA5DQo+IFVSTDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQteHUtbXBscy1pbi11ZHAtMDMudHh0DQo+IFN0YXR1czogICAgICAgICAgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS1tcGxzLWluLXVkcA0KPiBIdG1s aXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LW1wbHMtaW4t dWRwLTAzDQo+IERpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQteHUtbXBscy1pbi11ZHAtMDMNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRv Y3VtZW50IHNwZWNpZmllcyBvbmUgYWRkaXRpb25hbCBJUC1iYXNlZCBlbmNhcHN1bGF0aW9uDQo+ ICAgIHRlY2hub2xvZ3kgZm9yIE1QTFMgcGFja2V0cyByZWZlcnJlZCB0byBhcyBNUExTLWluLVVE UCwgd2hpY2ggaXMNCj4gICAgaW50ZW5kZWQgdG8gZmFjaWxpdGF0ZSBsb2FkLWJhbGFuY2luZyB0 aGUgdHJhZmZpYyBvZiB2YXJpb3VzIE1QTFMNCj4gICAgYXBwbGljYXRpb25zIHN1Y2ggYXMgTVBM Uy1iYXNlZCBMMlZQTiBhbmQgTDNWUE4gaW4gdGhlIGNvcmUgb2YgSVAtDQo+ICAgIGVuYWJsZWQg cGFja2V0IHN3aXRjaCBuZXR3b3Jrcy4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= From agmalis@gmail.com Tue Oct 9 10:50:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7171F0C9F for ; Tue, 9 Oct 2012 10:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udNwoYuk8KNk for ; Tue, 9 Oct 2012 10:50:55 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB0641F0C9B for ; Tue, 9 Oct 2012 10:50:54 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so4347968lbo.31 for ; Tue, 09 Oct 2012 10:50:53 -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=XekqXxm5/hyWlBL52b7AqSotd20pecFv0OeHosdhrZw=; b=Ml8yw07dFbvKVUqhsd1EbhOov+BUPj+Sj2IpJhLaFbWsHQ0DT8yjHgpwDIps2Fl4qm IUonrEay38kQnERyDB0XQKTdwVUkE+7yfX8JXwq+OAX+WyAqkdtQsSWllMuELr3JQ25k AadRnBVPk9Y297DaXogvMl9u6HuaJuNHMPchpTflHJwDBf+VmILlfuseVdzGNVp8Jj3X vlX15P37mHRSvaXJjm1qY2CKzfnzHS0eIV4kGPJ0kNgSl8eq22zwANkti9HL9ZNs19FO 5ndYrWdwUKsjlktMA11uacQ6ngRwFpjNU/iDUx+LYSyjQ+1jKpeO/vtUOaGyTNhePuDd 2GGg== Received: by 10.152.103.18 with SMTP id fs18mr17329430lab.32.1349805053490; Tue, 09 Oct 2012 10:50:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.61.5 with HTTP; Tue, 9 Oct 2012 10:50:33 -0700 (PDT) In-Reply-To: References: <20121008234908.29887.1630.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Tue, 9 Oct 2012 10:50:33 -0700 Message-ID: To: Kireeti Kompella , Curtis Villamizar Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" Subject: Re: [mpls] Fwd: New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 17:50:55 -0000 Kireeti and Curtis, Thanks for an interesting and useful draft. Just with my PWE3 chair hat on, while there's a good discussion of pseudowire labels with respect to multipath in section 2.3, it would be good to also have a short introduction to PW labels in section 2.1 as well, since they certainly fit the category of "Early Uses of Multiple Label Stack Entries". Taking off my PWE3 hat, regarding your question on document type, this certainly looks like a BCP to me, or if not that, then an MPLS WG Informational RFC. Cheers, Andy On Mon, Oct 8, 2012 at 5:30 PM, Kireeti Kompella wrote: > Hi Folks, > > I'd spoken on the issue of deep label stacks at the last IETF, and there was > interest from chip suppliers, vendors and service providers. Curtis just > submitted the draft; it goes beyond just deep label stacks. There are > suggestions in the draft on aspects of implementing MPLS forwarding, as well > as questions to ask regarding an implementation, and things to test. > > Please read and comment to the list. > > If you (that includes MPLS WG chairs and ADs) could also formulate your > thoughts on what type of doc (Info, BCP, PS) this should be, that would be > very helpful in moving this discussion forward. > > Thanks, > Kireeti. > > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for > draft-villamizar-mpls-forwarding-00.txt > Date: October 8, 2012 16:49:08PDT > To: curtis@occnc.com > Cc: kireeti.kompella@gmail.com > > > A new version of I-D, draft-villamizar-mpls-forwarding-00.txt > has been successfully submitted by Curtis Villamizar and posted to the > IETF repository. > > Filename: draft-villamizar-mpls-forwarding > Revision: 00 > Title: MPLS Forwarding Compliance and Performance Requirements > Creation date: 2012-10-08 > WG ID: Individual Submission > Number of pages: 17 > URL: > http://www.ietf.org/internet-drafts/draft-villamizar-mpls-forwarding-00.txt > Status: > http://datatracker.ietf.org/doc/draft-villamizar-mpls-forwarding > Htmlized: > http://tools.ietf.org/html/draft-villamizar-mpls-forwarding-00 > > > Abstract: > This document provides guidelines for implementors regarding MPLS > forwarding and a basis for evaluations of forwarding implementations. > Guidelines cover basic MPLS forwarding, forwarding when a deep MPLS > label stack is encountered, MPLS UHP operations which require one or > more label POP plus a PUSH, guidelines for hashing an MPLS stack and > payload for multipath, and conformance and performance requirements > for recent pseudowire and MPLS standards. > > > > > The IETF Secretariat > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From loa@pi.nu Tue Oct 9 11:10:57 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A5921F87FD for ; Tue, 9 Oct 2012 11:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBXAFVe7gX7C for ; Tue, 9 Oct 2012 11:10:56 -0700 (PDT) Received: from smtp-gw11.han.skanova.net (smtp-gw11.han.skanova.net [81.236.55.20]) by ietfa.amsl.com (Postfix) with ESMTP id C80C121F87FC for ; Tue, 9 Oct 2012 11:10:54 -0700 (PDT) Received: from [127.0.0.1] (81.236.221.144) by smtp-gw11.han.skanova.net (8.5.133) id 506BA90A002B4129; Tue, 9 Oct 2012 20:10:52 +0200 Message-ID: <507468A5.6020701@pi.nu> Date: Tue, 09 Oct 2012 20:10:45 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon Subject: [mpls] problem with my mail-server X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 18:10:57 -0000 Folks, I've had a HW problem with my mail server - I've now a temporary solution; loa@pi.nu is up and running again, but with two problems: 1. Any mail sent to me after late Saturday and until about 30 mins ago is lost somewhere in the cyberspace. If you sent anything that you think I need to act on please resend. 2. My mail-archives are also not available, this is a problem, since much of my draft processing is in that archive, again resend anything that you think I should act on. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From kireeti.kompella@gmail.com Wed Oct 10 06:52:25 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457DB21F8607 for ; Wed, 10 Oct 2012 06:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjUKWDmHQXcq for ; Wed, 10 Oct 2012 06:52:21 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0249321F8720 for ; Wed, 10 Oct 2012 06:52:17 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so1083003iec.31 for ; Wed, 10 Oct 2012 06:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=od2Mq7n6lLNv2p3QREXUCWD/ypyti5zTn5Hauuc0+5k=; b=wWHVHjig46AN+cRLhEdWu/NfNmRinoFI5wMl71kY0UEU5bFTazUlHh2Zoc6P6CejbQ mcWuns7/Uc7tANBJg452x6ITV1eqwWE0HBW51t1vDMykDib7aiSzX7K3c6Bk0LY/zkre nIw0/9F/vFE6YgTJMA7QIqtKl9tGQUKw+NN6lBTfWincspPEbl1hY60Ajcd2rLXyRJHx hFf8Y56aDCBvs1qd1N0ioG61sxXo6lnIxAJzjZvxEa63k5mSG7ZT8L2wBVqCSEJ09V8+ Rt+Ie3GRy68wJXonqgelwDCG8ck7xBK2O78qmds0niXPhXKPfR5hf77yMoXADhAtKTVk bZyA== Received: by 10.43.13.195 with SMTP id pn3mr18544299icb.47.1349877134996; Wed, 10 Oct 2012 06:52:14 -0700 (PDT) Received: from [192.168.1.72] (75-37-193-116.lightspeed.lsatca.sbcglobal.net. [75.37.193.116]) by mx.google.com with ESMTPS id uq6sm11720009igb.14.2012.10.10.06.52.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2012 06:52:14 -0700 (PDT) References: <20121008234908.29887.1630.idtracker@ietfa.amsl.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <76E11C3E-30EA-453F-A6F1-FF33263D77AA@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9A405) From: Kireeti Kompella Date: Wed, 10 Oct 2012 06:52:17 -0700 To: "Andrew G. Malis" Cc: "mpls@ietf.org" Subject: Re: [mpls] Fwd: New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 13:52:25 -0000 Hi Andy, On Oct 9, 2012, at 10:50, "Andrew G. Malis" wrote: > Kireeti and Curtis, >=20 > Thanks for an interesting and useful draft. Just with my PWE3 chair > hat on, while there's a good discussion of pseudowire labels with > respect to multipath in section 2.3, it would be good to also have a > short introduction to PW labels in section 2.1 as well, since they > certainly fit the category of "Early Uses of Multiple Label Stack > Entries". Thanks -- good suggestion. Will do. Also perhaps a quick note on the control= word.=20 > Taking off my PWE3 hat, regarding your question on document type, this > certainly looks like a BCP to me, or if not that, then an MPLS WG > Informational RFC. Our thinking as well, but let's see what others and the chairs say.=20 Regards, Kireeti > Cheers, > Andy >=20 > On Mon, Oct 8, 2012 at 5:30 PM, Kireeti Kompella > wrote: >> Hi Folks, >>=20 >> I'd spoken on the issue of deep label stacks at the last IETF, and there w= as >> interest from chip suppliers, vendors and service providers. Curtis just= >> submitted the draft; it goes beyond just deep label stacks. There are >> suggestions in the draft on aspects of implementing MPLS forwarding, as w= ell >> as questions to ask regarding an implementation, and things to test. >>=20 >> Please read and comment to the list. >>=20 >> If you (that includes MPLS WG chairs and ADs) could also formulate your >> thoughts on what type of doc (Info, BCP, PS) this should be, that would b= e >> very helpful in moving this discussion forward. >>=20 >> Thanks, >> Kireeti. >>=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for >> draft-villamizar-mpls-forwarding-00.txt >> Date: October 8, 2012 16:49:08PDT >> To: curtis@occnc.com >> Cc: kireeti.kompella@gmail.com >>=20 >>=20 >> A new version of I-D, draft-villamizar-mpls-forwarding-00.txt >> has been successfully submitted by Curtis Villamizar and posted to the >> IETF repository. >>=20 >> Filename: draft-villamizar-mpls-forwarding >> Revision: 00 >> Title: MPLS Forwarding Compliance and Performance Requirements >> Creation date: 2012-10-08 >> WG ID: Individual Submission >> Number of pages: 17 >> URL: >> http://www.ietf.org/internet-drafts/draft-villamizar-mpls-forwarding-00.t= xt >> Status: >> http://datatracker.ietf.org/doc/draft-villamizar-mpls-forwarding >> Htmlized: >> http://tools.ietf.org/html/draft-villamizar-mpls-forwarding-00 >>=20 >>=20 >> Abstract: >> This document provides guidelines for implementors regarding MPLS >> forwarding and a basis for evaluations of forwarding implementations. >> Guidelines cover basic MPLS forwarding, forwarding when a deep MPLS >> label stack is encountered, MPLS UHP operations which require one or >> more label POP plus a PUSH, guidelines for hashing an MPLS stack and >> payload for multipath, and conformance and performance requirements >> for recent pseudowire and MPLS standards. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 From loa@pi.nu Wed Oct 10 10:03:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5266021F8758 for ; Wed, 10 Oct 2012 10:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-XbZBNL9pMh for ; Wed, 10 Oct 2012 10:03:09 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id C155F21F8715 for ; Wed, 10 Oct 2012 10:03:08 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 0669682451; Wed, 10 Oct 2012 19:02:59 +0200 (CEST) Message-ID: <5075AA45.3040605@pi.nu> Date: Wed, 10 Oct 2012 19:03:01 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ipv6-pw-lsp-ping@tools.ietf.org" Subject: [mpls] Closed - Extended: working group last call on draft-ietf-mpls-ipv6-pw-lsp-ping-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 17:03:10 -0000 Working Group, This extended working group last call on draft-ietf-mpls-ipv6-pw-lsp-ping Has been closed. We have comments, can the authors please address the comments and publish a new version of the draft. /Loa for the wg chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From hffellow@hotmail.com Thu Oct 11 00:02:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B3221F8645 for ; Thu, 11 Oct 2012 00:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0JqhZFaEk3b for ; Thu, 11 Oct 2012 00:02:54 -0700 (PDT) Received: from snt0-omc1-s31.snt0.hotmail.com (snt0-omc1-s31.snt0.hotmail.com [65.55.90.42]) by ietfa.amsl.com (Postfix) with ESMTP id B6ACC21F865C for ; Thu, 11 Oct 2012 00:02:54 -0700 (PDT) Received: from SNT110-W47 ([65.55.90.9]) by snt0-omc1-s31.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 00:02:53 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3386366a-4619-4d0e-b459-64d9fbd396eb_" X-Originating-IP: [27.115.50.36] From: Elton huang To: , , "mpls@ietf.org" Date: Thu, 11 Oct 2012 07:02:53 +0000 Importance: Normal In-Reply-To: <2FE467D3673DCE409A84D67EC2F607BB0F598ADD@xmb-rcd-x10.cisco.com> References: <44A5364BC1FA1E42B1F133529EC2C72902C22E96@CNBEEXC007.nsn-intra.net>, <2FE467D3673DCE409A84D67EC2F607BB0F598ADD@xmb-rcd-x10.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 11 Oct 2012 07:02:53.0847 (UTC) FILETIME=[6F4A4A70:01CDA77E] Subject: Re: [mpls] Concensus ? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 07:02:55 -0000 --_3386366a-4619-4d0e-b459-64d9fbd396eb_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Dear George, >As ever, it is up to the WG chairs to decide if there is WG consensus, what's principle for WG chairs to decide on WG rough consensus? please make it is clear. thanks a lot. hffellow From: swallow@cisco.com To: paul.doolan@nsn.com; mpls@ietf.org Date: Fri, 5 Oct 2012 15:04:54 +0000 Subject: Re: [mpls] Concensus ? Paul - To answer you question in general, note that the running code is conjoined to rough consensus. Running code does a whole lot to dispel perceived deficiencies. But short of running interoperable code, the consensus cannot be too rough. This is particularly true for a standards track document. For an Informational Document originating from the WG, the consensus needed is more of the form, does the community believe that the document merits publishing. As ever, it is up to the WG chairs to decide if there is WG consensus, and the iESG whether there is IETF consensus. ¡­George From: , "Paul (NSN - US/Irving)" Date: Wednesday, October 3, 2012 8:10 AM To: George Swallow , "mpls@ietf.org" Subject: Concensus ? Hi George, Yesterday, with your chair hat on, you wrote: > The object is to fix the draft so that WG consensus can be achieved to move it forward. > If the WG consensus is that there are deficiencies and that the authors have failed to address them then we would not have consensus. The last sentence is interesting, in an Alice in Wonderlandor Bertrand Russell kind of way, but my question is about your use ofthe word¡®concensus¡¯ itself. The Tao document(www.ietf.org/tao.html)still references Dave Clark¡¯s formulation¡°rough concensus and running code¡±.Does this WG operate on thatroughstandard or thesmoother one you suggest? cheers, pd _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_3386366a-4619-4d0e-b459-64d9fbd396eb_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Dear George,
 
>As ever, it is up to the WG chairs to decide if there is WG consensus,
 
what's principle for WG chairs to decide on WG rough consensus? please make it is clear. thanks a lot.
 
hffellow
 
From: swallow@cisco.com
To: paul.doolan@nsn.com; mpls@ietf.org
Date: Fri, 5 Oct 2012 15:04:54 +0000
Subject: Re: [mpls] Concensus ?

Paul -

To answer you question in  general, note that the running code is conjoined to rough consensus.  Running code does a whole lot to dispel perceived deficiencies.  But short of running interoperable code, the consensus cannot be too rough.
This is particularly true for a standards track document.
  
For an Informational Document originating from the WG, the consensus needed is more of the form, does the community believe that the document merits  publishing.

As ever, it is up to the WG chairs to decide if there is WG consensus, and the iESG whether there is IETF consensus.

¡­George

From: <Doolan>, "Paul (NSN - US/Irving)" <paul.doolan@nsn.com>
Date: Wednesday, October 3, 2012 8:10 AM
To: George Swallow <swallow@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Concensus ?

Hi George,

Yesterday, with your chair hat on, you wrote:

> The object is to fix the draft so that WG consensus can be achieved to move it forward.

> If the WG consensus is that there are deficiencies and that the authors have failed to address them then we would not have consensus.

The last sentence is interesting, in an Alice in Wonderlandor Bertrand Russell kind of way, but my question is about your use ofthe word¡®concensus¡¯ itself.

The Tao document(www.ietf.org/tao.html)still references Dave Clark¡¯s formulation¡°rough concensus and running code¡±.Does this WG operate on thatroughstandard or thesmoother one you suggest?

cheers,

pd


_______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls
--_3386366a-4619-4d0e-b459-64d9fbd396eb_-- From internet-drafts@ietf.org Thu Oct 11 01:54:32 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C829221F866C; Thu, 11 Oct 2012 01:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVdEfXI0Ka25; Thu, 11 Oct 2012 01:54:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1146121F84E4; Thu, 11 Oct 2012 01:54:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011085432.22758.67897.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 01:54:32 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ipv6-pw-lsp-ping-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 08:54:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs Author(s) : Mach(Guoyi) Chen Ping Pan Carlos Pignataro Rajiv Asati Filename : draft-ietf-mpls-ipv6-pw-lsp-ping-02.txt Pages : 9 Date : 2012-10-11 Abstract: Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ipv6-pw-lsp-ping-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ipv6-pw-lsp-ping-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From loa@pi.nu Thu Oct 11 01:54:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE50C21F86E3 for ; Thu, 11 Oct 2012 01:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pN46VgGSAgO for ; Thu, 11 Oct 2012 01:54:47 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1BED921F84E4 for ; Thu, 11 Oct 2012 01:54:46 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 1A13A82475; Thu, 11 Oct 2012 10:54:41 +0200 (CEST) Message-ID: <50768953.5040105@pi.nu> Date: Thu, 11 Oct 2012 10:54:43 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Scott Mansfield , Martin Vigoureux Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Liaisons from ITU-T SG15 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 08:54:47 -0000 Working Group, ITU-T SG15, sent us 5 liaison from its meeting in September, two are for information and we just now don't plan to respond to them. However, it would be good if the working group members could review them and see if there are issues that we need to communicate to SG15. The liaisons for information are: --------------------------------- First, 2012-10-03 ITU-T SG 15 Multiprotocol Label Switching -- Approval, Determination and Consent of MPLS-TP Recommendations http://datatracker.ietf.org/liaison/1203/ Second, 2012-10-03 ITU-T SG 15 Multiprotocol Label Switching -- Response to Liaison concerning approval of MPLS-TP Documents http://datatracker.ietf.org/liaison/1201/ The liaison for action are: --------------------------- We also have three liaisons that we need to respond. Scott Mansfield, liaison manager for MPLS to the ITU-T has promised to help us coordinate the work to write the response liaisons. We are also looking for subject area experts volunteering to help us. If you are willing to work with us on this please take contact with Scott and the wg chairs. The response date is effectively to be sent before the Holiday Season in December and January ( 2012-12-31 and 2012-01-01). First, 2012-10-03 ITU-T SG 15 Multiprotocol Label Switching 2012-12-31 Recommendation ITU-T G.8131/Y.1382 revision - Linear protection switching for MPLS-TP networks http://datatracker.ietf.org/liaison/1205/ Second, 2012-10-03 ITU-T SG 15 Multiprotocol Label Switching 2012-12-31 Requirements and analysis of ring protection for MPLS-TP networks http://datatracker.ietf.org/liaison/1199/ Third, 2012-10-03 ITU-T SG 15 Multiprotocol Label Switching 2013-01-01 Progressing work on p2mp MPLS-TP connections http://datatracker.ietf.org/liaison/1202/ /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From cpignata@cisco.com Thu Oct 11 02:06:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A910B21F8714 for ; Thu, 11 Oct 2012 02:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nQLyoe6Ck+q for ; Thu, 11 Oct 2012 02:06:19 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB1521F8702 for ; Thu, 11 Oct 2012 02:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4277; q=dns/txt; s=iport; t=1349946379; x=1351155979; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EmkbAmi8o46zqq390OSf5LUe1Bq3tAnZgrd1YQ/WSUM=; b=kc+v01qPZ0FZurInoPvIO8ZPTMc8WI8Vej9NaPoDEh7U2ekTnzkZbliy CwZOjOl4o7rN6x89e+teI0Sq481Rzsxc6O5hxwq0ILyIBfQN7FsI4tP3Y dSPZ9ti5HSgLKWFBHK1u/XBQwaK90NeUGKdiKmjB4WruJ4DWqoH1KfOo8 g=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAHCKdlCtJXG9/2dsb2JhbABEtmkBiFqBCIIgAQEBAwEBAQEPAVsLBQkCAgEIBB4kGwwLJQIEDgUIBhSHXAYLmH+gHgSLQ4VAYAOOb4EghnONMIFrgm2BYzQ X-IronPort-AV: E=Sophos;i="4.80,570,1344211200"; d="asc'?scan'208,217";a="130259996" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 11 Oct 2012 09:06:18 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9B96Ing002353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Oct 2012 09:06:18 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 04:06:18 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] Closed - Extended: working group last call on draft-ietf-mpls-ipv6-pw-lsp-ping-01 Thread-Index: AQHNpwknIWKF3AaBL0OLgNjaFGZmnZe0JRYA Date: Thu, 11 Oct 2012 09:06:17 +0000 Message-ID: <95067C434CE250468B77282634C96ED320D0DC0B@xmb-aln-x02.cisco.com> References: <5075AA45.3040605@pi.nu> In-Reply-To: <5075AA45.3040605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.105.18] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19262.000 x-tm-as-result: No--33.615200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_487AA8FC-B3DA-44D4-A3D3-6D6C5CEF06A3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ipv6-pw-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Closed - Extended: working group last call on draft-ietf-mpls-ipv6-pw-lsp-ping-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 09:06:23 -0000 --Apple-Mail=_487AA8FC-B3DA-44D4-A3D3-6D6C5CEF06A3 Content-Type: multipart/alternative; boundary="Apple-Mail=_6AB0EEE1-DA32-4B55-BB09-204B95E923D0" --Apple-Mail=_6AB0EEE1-DA32-4B55-BB09-204B95E923D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you, Loa. New revision just published, changes at = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ipv6-pw-lsp-ping-02.t= xt. Kireeti, please do feel free to Ack/Nack the changes as addressing your = comments. Thanks, -- Carlos. On Oct 10, 2012, at 7:03 PM, Loa Andersson wrote: > Working Group, >=20 > This extended working group last call on >=20 > draft-ietf-mpls-ipv6-pw-lsp-ping >=20 > Has been closed. >=20 > We have comments, can the authors please address the comments and > publish a new version of the draft. >=20 > /Loa > for the wg chairs > --=20 >=20 >=20 > Loa Andersson email: = loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 --Apple-Mail=_6AB0EEE1-DA32-4B55-BB09-204B95E923D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thank = you, Loa.


Kireeti, please do feel = free to Ack/Nack the changes as addressing your = comments.

Thanks,

-- = Carlos.


On Oct 10, 2012, at 7:03 = PM, Loa Andersson wrote:

Working= Group,

This extended working group last call = on

draft-ietf-mpls-ipv6-pw-lsp-ping

Has been = closed.

We have comments, can the authors please address the = comments and
publish a new version of the draft.

/Loa
for = the wg chairs
--


Loa Andersson =             &n= bsp;           emai= l: loa.andersson@ericsson.com<= br>Sr Strategy and Standards Manager =            loa@pi.nu
Ericsson Inc =             &n= bsp;           &nbs= p;phone: +46 10 717 52 13
=             &n= bsp;           &nbs= p;            =        +46 767 72 92 = 13
_______________________________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mpls


= --Apple-Mail=_6AB0EEE1-DA32-4B55-BB09-204B95E923D0-- --Apple-Mail=_487AA8FC-B3DA-44D4-A3D3-6D6C5CEF06A3 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----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAlB2jAgACgkQtfDPGTp3USxSgACgoMDCkgC29Cj2Df6/ae5wFe8M +9cAoMISHwkBaQ25yWnKbZwppJtUPPvj =1cq8 -----END PGP SIGNATURE----- --Apple-Mail=_487AA8FC-B3DA-44D4-A3D3-6D6C5CEF06A3-- From adrian@olddog.co.uk Thu Oct 11 04:09:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D668521F86FC for ; Thu, 11 Oct 2012 04:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J73-37fJ3zVd for ; Thu, 11 Oct 2012 04:09:37 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id A435321F86F6 for ; Thu, 11 Oct 2012 04:09:32 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9BB9VBq021955; Thu, 11 Oct 2012 12:09:31 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9BB9P2B021936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Oct 2012 12:09:26 +0100 From: "Adrian Farrel" To: , , References: <0da001cd7ba1$41c9aea0$c55d0be0$@olddog.co.uk> <0DB8F45437AB844CBB5102F807A0AD930F4E4C38@xmb-rcd-x03.cisco.com> In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD930F4E4C38@xmb-rcd-x03.cisco.com> Date: Thu, 11 Oct 2012 12:09:27 +0100 Message-ID: <00cb01cda7a0$e1ee28e0$a5ca7aa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGCZaN6PMsbDafsLIDV55xWrPh8wgKH0cqTmDY3n3A= Content-Language: en-gb Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 11:09:39 -0000 Authors, Chairs, and Working Group, How should I interpret the progress (or lack thereof) with this draft? Thanks, Adrian > -----Original Message----- > From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] > Sent: 16 August 2012 16:18 > To: adrian@olddog.co.uk; draft-ietf-mpls-tp-use-cases-and- > design@tools.ietf.org > Cc: mpls@ietf.org > Subject: RE: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design > > Adrian, > > Thank you very much for your AD review and comments, appreciate your effort > to help identify the issues in details. > We'll revise the document to address all comments and work with chairs and > working group to resolve all issues. > > Thanks, > Luyuan > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Adrian Farrel > > Sent: Thursday, August 16, 2012 7:21 AM > > To: draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org > > Cc: mpls@ietf.org > > Subject: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design > > > > Hi, > > > > I have done my AD review of this document as usual before pushing it > > forward for IETF last call and IESG review. This has generated a long > > list of comments. Many are formatting and style issues that really > > should be fixed to make the document acceptable for publication. Others > > are technical questions that need to be resolved either in discussion > > or by updates to the document. > > > > The volume of changes will make for quite a bit of extra work, I'm > > afraid. But I think these changes are necessary before I can support > > this document for publication as an RFC. > > > > Please work with the chairs and the working group to resolve these > > issues. > > > > Thanks, > > Adrian > > > > === > > > > In reading the document I find the authors are confused about what they > > mean by MPLS-TP. Is MPLS-TP a profile of the MPLS toolset for use in > > transport networks? Is it a profile of the MPLS functions that are used > > in transport networks? Is it a delta to the base MPLS functions? Is it > > a project to enhance the base MPLS to add features needed for transport > > networks. > > > > This question results in significant ambiguity in the text. For > > example, > > you say "MPLS-TP disallowed ECMP", but I think you mean that "ECMP is > > not appropriate in a transport network, so the MPLS transport profile > > assumes that ECMP will not be present and the MPLS tools necessary for > > handling ECMP will not be used." > > > > --- > > > > Please fix the format nits shown by idnits (page and line lengths). > > > > --- > > > > Per the exchanges on the MPLS mailing list, you need to replace "PHP as > > optional" with "PHP must be disabled by default" > > > > --- > > > > It would significantly help the reviewers if you could manage to > > format the page headers and footers, align the section headings. > > > > --- > > > > The Table of Contents is a bit messed up. > > > > --- > > > > There are a number of random page throws that mess up the formatting. > > > > --- > > > > This document desperately needs review by a native speaker to tidy the > > English. While this might not seem critical, the large number of small > > errors make reading and reviewing hard. They may also obscure some > > technical issues. > > > > I strongly suggest that the chairs solicit a review from an interested > > working group member (in return for a mention in the Acknowledgements, > > or in exchange for beer). > > > > Here are a few examples from early in the document... > > > > - - - - > > > > Abstract > > > > OLD > > for Multiprotocol Label Switching Transport > > profile (MPLS-TP). > > NEW > > for the Multiprotocol Label Switching Transport > > Profile (MPLS-TP). > > > > - - - - > > > > Abstract > > > > OLD > > The > > design considerations discussed in this documents ranging from > > NEW > > The > > design considerations discussed in this document range from > > > > - - - - > > > > Section 1.1 > > > > OLD > > The end of live for many > > NEW > > The end of life for many > > > > - - - - > > > > Section 1.1 > > > > OLD > > MPLS-TP re-use a subset of > > MPLS base functions > > NEW > > MPLS-TP re-uses a subset of > > MPLS base functions > > > > - - - - > > > > Section 1.1 > > > > OLD > > MPLS-TP extended current MPLS OAM > > functions > > NEW > > MPLS-TP extended previous MPLS OAM > > functions > > > > --- > > > > Why do you consider use of RFC 2119 language to be appropriate in this > > Informational document? All I could find was an instance of "MUST" that > > you have inherited from RFC 5654. I think you could usefully tidy this > > up. > > > > --- > > > > There are too many acronyms used in Section 1 without expansion. > > > > --- > > > > Section 1.2 > > > > I think Henry Yu asked for you to change his affiliation. > > > > --- > > > > s/2. Terminologies/2. Terminology/ > > > > --- > > > > Please clean up Section 2 to remove those acronyms not actually used in > > the document. For example, APS, DM, SRLG. You'll need to do a search > > and > > destroy operation. On the other hand, please search the document for > > other acronyms such as MSTP. > > > > Please also decide whether G-ACH or G-ACh. > > > > --- > > > > Section 3 seems a bit of a muddle. Details below, but this discussion > > makes me wonder what the purpose of Section 3 is. The function of > > MPLS-TP is well-defined in other documents. By summarising it here you > > risk leaving out key pieces, and may give the wrong impression about > > the > > details. It may be better to cut out this section and leave the > > document > > to focus on the uses cases and network design. > > > > - - - - > > > > Section 3.2 > > > > MPLS-TP extended the LSP support from unidirectional to both bi- > > directional unidirectional support. > > > > The implication here is that there is something different in the MPLS > > data plane in MPLS-TP to support bidirectional LSPs. But I don't think > > there is. As far as the data plane is concerned, there is no difference > > between two unidirectional LSPs and one bidirectional LSP. > > > > - - - - > > > > Section 3.3 > > > > I don't think that the use of an NMS for static provisioning is a > > "control plane option". Maybe if you retitled the section as > > "Provisioning". But anyway, I don't see why the ACH is mentioned in > > this section. > > > > --- > > > > The whole of the substantial Section 5.7 amounts to "In MPLS-TP, it is > > best to provision LSPs with low or zero Relative Delay Time. But there > > is no discussion of what this means for an MPLS-TP deployment. > > > > Furthermore the section ends with... > > > > More discussion will be added on how to manage the Relative delay > > time. > > > > ...and this does not convince me that the document is complete. > > > > --- > > > > Section 6 > > > > I would expect this document to examine the security requirements of > > the > > different use cases. When is it necessary to use the security tools > > developed and discussed in the two referenced documents? > > > > --- > > > > Could you please split the Authors' Addresses into two sections. > > Authors' Addresses to match those on the front page, and > > Contributors' Addresses to capture all the others. > > > > Where does Section 1.2 sit with respect to the Authors and > > Contributors? Do you really need Section 1.2? > > > > --- > > > > s/10. Author's Addresses/10. Authors' Addresses/ > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Thu Oct 11 09:08:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0DF21F8435 for ; Thu, 11 Oct 2012 09:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.427 X-Spam-Level: X-Spam-Status: No, score=-10.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHooVofQmkJS for ; Thu, 11 Oct 2012 09:08:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3A86D21F8534 for ; Thu, 11 Oct 2012 09:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8807; q=dns/txt; s=iport; t=1349971705; x=1351181305; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=sCaUnq4NMNOZAWg0Y0S1IKrrbCzlmCctXs27vCucOAU=; b=Rm1oIkOgqbwyWJjNqEAa9qA58RudERE5ZFbkAMX/4qMNUc3WZvN9of07 xaWbJvncSd8lmAuS+aXYsKJl9cQQGTtsGYDLj1suvfDXcSN664cE/cxBV BPhhPe/D1rW3rsZGXiCu5VCnstI6WWAvjpPCpUYtMKi4LPgTeD8KfWBKn s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOPtdlCtJXG+/2dsb2JhbAA6Cr9KgQiCIAEBAQQBAQEPAVsXBgEIEQQBAQsdLgsUCQgBAQQBEggRCYdiC5ltoCQEi0cQhTBgA6QygWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,572,1344211200"; d="scan'208";a="130612431" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 11 Oct 2012 16:08:24 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9BG8OXi001995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Oct 2012 16:08:24 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.215]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 11:08:24 -0500 From: "Luyuan Fang (lufang)" To: "adrian@olddog.co.uk" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design Thread-Index: Ac17oRkEPObiKMg1T6m8FOX+hMPW4QAHkqjgCwLZeYD//94rAA== Date: Thu, 11 Oct 2012 16:08:23 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD930F52A63C@xmb-rcd-x03.cisco.com> In-Reply-To: <00cb01cda7a0$e1ee28e0$a5ca7aa0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.81.72] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19262.000 x-tm-as-result: No--55.904000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <8B037F5047D44242A0B50EF8E238CDC3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 16:08:26 -0000 Hi Adrian, Nabil and I have discussed this after reviewed your comments. Major re-write is certainly needed based on your comments. We are working it, but not gone far yet. Our plan is to complete the update by the cut-off date. Given the changes are quite major, we would like to discuss with you before finishing the update=8A and certainly work with the chairs on it. Thanks, Luyuan On 10/11/12 4:09 AM, "Adrian Farrel" wrote: >Authors, Chairs, and Working Group, > >How should I interpret the progress (or lack thereof) with this draft? > >Thanks, >Adrian > >> -----Original Message----- >> From: Luyuan Fang (lufang) [mailto:lufang@cisco.com] >> Sent: 16 August 2012 16:18 >> To: adrian@olddog.co.uk; draft-ietf-mpls-tp-use-cases-and- >> design@tools.ietf.org >> Cc: mpls@ietf.org >> Subject: RE: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design >>=20 >> Adrian, >>=20 >> Thank you very much for your AD review and comments, appreciate your >>effort >> to help identify the issues in details. >> We'll revise the document to address all comments and work with chairs >>and >> working group to resolve all issues. >>=20 >> Thanks, >> Luyuan >>=20 >> > -----Original Message----- >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>Of >> > Adrian Farrel >> > Sent: Thursday, August 16, 2012 7:21 AM >> > To: draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org >> > Cc: mpls@ietf.org >> > Subject: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design >> > >> > Hi, >> > >> > I have done my AD review of this document as usual before pushing it >> > forward for IETF last call and IESG review. This has generated a long >> > list of comments. Many are formatting and style issues that really >> > should be fixed to make the document acceptable for publication. >>Others >> > are technical questions that need to be resolved either in discussion >> > or by updates to the document. >> > >> > The volume of changes will make for quite a bit of extra work, I'm >> > afraid. But I think these changes are necessary before I can support >> > this document for publication as an RFC. >> > >> > Please work with the chairs and the working group to resolve these >> > issues. >> > >> > Thanks, >> > Adrian >> > >> > =3D=3D=3D >> > >> > In reading the document I find the authors are confused about what >>they >> > mean by MPLS-TP. Is MPLS-TP a profile of the MPLS toolset for use in >> > transport networks? Is it a profile of the MPLS functions that are >>used >> > in transport networks? Is it a delta to the base MPLS functions? Is it >> > a project to enhance the base MPLS to add features needed for >>transport >> > networks. >> > >> > This question results in significant ambiguity in the text. For >> > example, >> > you say "MPLS-TP disallowed ECMP", but I think you mean that "ECMP is >> > not appropriate in a transport network, so the MPLS transport profile >> > assumes that ECMP will not be present and the MPLS tools necessary for >> > handling ECMP will not be used." >> > >> > --- >> > >> > Please fix the format nits shown by idnits (page and line lengths). >> > >> > --- >> > >> > Per the exchanges on the MPLS mailing list, you need to replace "PHP >>as >> > optional" with "PHP must be disabled by default" >> > >> > --- >> > >> > It would significantly help the reviewers if you could manage to >> > format the page headers and footers, align the section headings. >> > >> > --- >> > >> > The Table of Contents is a bit messed up. >> > >> > --- >> > >> > There are a number of random page throws that mess up the formatting. >> > >> > --- >> > >> > This document desperately needs review by a native speaker to tidy the >> > English. While this might not seem critical, the large number of small >> > errors make reading and reviewing hard. They may also obscure some >> > technical issues. >> > >> > I strongly suggest that the chairs solicit a review from an interested >> > working group member (in return for a mention in the Acknowledgements, >> > or in exchange for beer). >> > >> > Here are a few examples from early in the document... >> > >> > - - - - >> > >> > Abstract >> > >> > OLD >> > for Multiprotocol Label Switching Transport >> > profile (MPLS-TP). >> > NEW >> > for the Multiprotocol Label Switching Transport >> > Profile (MPLS-TP). >> > >> > - - - - >> > >> > Abstract >> > >> > OLD >> > The >> > design considerations discussed in this documents ranging from >> > NEW >> > The >> > design considerations discussed in this document range from >> > >> > - - - - >> > >> > Section 1.1 >> > >> > OLD >> > The end of live for many >> > NEW >> > The end of life for many >> > >> > - - - - >> > >> > Section 1.1 >> > >> > OLD >> > MPLS-TP re-use a subset of >> > MPLS base functions >> > NEW >> > MPLS-TP re-uses a subset of >> > MPLS base functions >> > >> > - - - - >> > >> > Section 1.1 >> > >> > OLD >> > MPLS-TP extended current MPLS OAM >> > functions >> > NEW >> > MPLS-TP extended previous MPLS OAM >> > functions >> > >> > --- >> > >> > Why do you consider use of RFC 2119 language to be appropriate in this >> > Informational document? All I could find was an instance of "MUST" >>that >> > you have inherited from RFC 5654. I think you could usefully tidy this >> > up. >> > >> > --- >> > >> > There are too many acronyms used in Section 1 without expansion. >> > >> > --- >> > >> > Section 1.2 >> > >> > I think Henry Yu asked for you to change his affiliation. >> > >> > --- >> > >> > s/2. Terminologies/2. Terminology/ >> > >> > --- >> > >> > Please clean up Section 2 to remove those acronyms not actually used >>in >> > the document. For example, APS, DM, SRLG. You'll need to do a search >> > and >> > destroy operation. On the other hand, please search the document for >> > other acronyms such as MSTP. >> > >> > Please also decide whether G-ACH or G-ACh. >> > >> > --- >> > >> > Section 3 seems a bit of a muddle. Details below, but this discussion >> > makes me wonder what the purpose of Section 3 is. The function of >> > MPLS-TP is well-defined in other documents. By summarising it here you >> > risk leaving out key pieces, and may give the wrong impression about >> > the >> > details. It may be better to cut out this section and leave the >> > document >> > to focus on the uses cases and network design. >> > >> > - - - - >> > >> > Section 3.2 >> > >> > MPLS-TP extended the LSP support from unidirectional to both bi- >> > directional unidirectional support. >> > >> > The implication here is that there is something different in the MPLS >> > data plane in MPLS-TP to support bidirectional LSPs. But I don't think >> > there is. As far as the data plane is concerned, there is no >>difference >> > between two unidirectional LSPs and one bidirectional LSP. >> > >> > - - - - >> > >> > Section 3.3 >> > >> > I don't think that the use of an NMS for static provisioning is a >> > "control plane option". Maybe if you retitled the section as >> > "Provisioning". But anyway, I don't see why the ACH is mentioned in >> > this section. >> > >> > --- >> > >> > The whole of the substantial Section 5.7 amounts to "In MPLS-TP, it is >> > best to provision LSPs with low or zero Relative Delay Time. But there >> > is no discussion of what this means for an MPLS-TP deployment. >> > >> > Furthermore the section ends with... >> > >> > More discussion will be added on how to manage the Relative delay >> > time. >> > >> > ...and this does not convince me that the document is complete. >> > >> > --- >> > >> > Section 6 >> > >> > I would expect this document to examine the security requirements of >> > the >> > different use cases. When is it necessary to use the security tools >> > developed and discussed in the two referenced documents? >> > >> > --- >> > >> > Could you please split the Authors' Addresses into two sections. >> > Authors' Addresses to match those on the front page, and >> > Contributors' Addresses to capture all the others. >> > >> > Where does Section 1.2 sit with respect to the Authors and >> > Contributors? Do you really need Section 1.2? >> > >> > --- >> > >> > s/10. Author's Addresses/10. Authors' Addresses/ >> > >> > _______________________________________________ >> > mpls mailing list >> > mpls@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Fri Oct 12 06:52:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0C421F854F for ; Fri, 12 Oct 2012 06:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ssxvg-288TkX for ; Fri, 12 Oct 2012 06:52:23 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id BC66721F8530 for ; Fri, 12 Oct 2012 06:52:23 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id E38FD82451; Fri, 12 Oct 2012 15:52:18 +0200 (CEST) Message-ID: <50782094.5050104@pi.nu> Date: Fri, 12 Oct 2012 15:52:20 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MPLS-TP ad hoc team , draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org Subject: [mpls] mpls wg last call for draft-ietf-mpls-tp-oam-id-mib X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 13:52:24 -0000 Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-oam-id-mib-01. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and if you are happy with the document as is also indications of support. This working group last call will end on October 28. /Loa for the wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From curtis@occnc.com Sat Oct 13 12:49:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D655F21F8469 for ; Sat, 13 Oct 2012 12:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwVjUqM4smYM for ; Sat, 13 Oct 2012 12:49:04 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 1F96C21F8467 for ; Sat, 13 Oct 2012 12:49:03 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q9DJmpno047601; Sat, 13 Oct 2012 15:48:51 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210131948.q9DJmpno047601@gateway1.orleans.occnc.com> To: "Andrew G. Malis" From: Curtis Villamizar In-reply-to: Your message of "Tue, 09 Oct 2012 10:50:33 PDT." Date: Sat, 13 Oct 2012 15:48:51 -0400 Cc: "mpls@ietf.org" Subject: Re: [mpls] Fwd: New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 19:49:04 -0000 In message "Andrew G. Malis" writes: > Kireeti and Curtis, > > Thanks for an interesting and useful draft. Just with my PWE3 chair > hat on, while there's a good discussion of pseudowire labels with > respect to multipath in section 2.3, it would be good to also have a > short introduction to PW labels in section 2.1 as well, since they > certainly fit the category of "Early Uses of Multiple Label Stack > Entries". OK. Will look at adding something on PW there. > Taking off my PWE3 hat, regarding your question on document type, this > certainly looks like a BCP to me, or if not that, then an MPLS WG > Informational RFC. > > Cheers, > Andy Thanks. BCP or informational seems to make sense. BMWG might me interested in followup work. Curtis > On Mon, Oct 8, 2012 at 5:30 PM, Kireeti Kompella > wrote: > > Hi Folks, > > > > I'd spoken on the issue of deep label stacks at the last IETF, and there was > > interest from chip suppliers, vendors and service providers. Curtis just > > submitted the draft; it goes beyond just deep label stacks. There are > > suggestions in the draft on aspects of implementing MPLS forwarding, as well > > as questions to ask regarding an implementation, and things to test. > > > > Please read and comment to the list. > > > > If you (that includes MPLS WG chairs and ADs) could also formulate your > > thoughts on what type of doc (Info, BCP, PS) this should be, that would be > > very helpful in moving this discussion forward. > > > > Thanks, > > Kireeti. > > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > > draft-villamizar-mpls-forwarding-00.txt > > Date: October 8, 2012 16:49:08PDT > > To: curtis@occnc.com > > Cc: kireeti.kompella@gmail.com > > > > > > A new version of I-D, draft-villamizar-mpls-forwarding-00.txt > > has been successfully submitted by Curtis Villamizar and posted to the > > IETF repository. > > > > Filename: draft-villamizar-mpls-forwarding > > Revision: 00 > > Title: MPLS Forwarding Compliance and Performance Requirements > > Creation date: 2012-10-08 > > WG ID: Individual Submission > > Number of pages: 17 > > URL: > > http://www.ietf.org/internet-drafts/draft-villamizar-mpls-forwarding-00.txt > > Status: > > http://datatracker.ietf.org/doc/draft-villamizar-mpls-forwarding > > Htmlized: > > http://tools.ietf.org/html/draft-villamizar-mpls-forwarding-00 > > > > > > Abstract: > > This document provides guidelines for implementors regarding MPLS > > forwarding and a basis for evaluations of forwarding implementations. > > Guidelines cover basic MPLS forwarding, forwarding when a deep MPLS > > label stack is encountered, MPLS UHP operations which require one or > > more label POP plus a PUSH, guidelines for hashing an MPLS stack and > > payload for multipath, and conformance and performance requirements > > for recent pseudowire and MPLS standards. > > > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From muly_i@rad.com Sun Oct 14 08:01:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2949F21F8459 for ; Sun, 14 Oct 2012 08:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vXgdTBYVjn0 for ; Sun, 14 Oct 2012 08:01:09 -0700 (PDT) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id CB1E921F845E for ; Sun, 14 Oct 2012 08:01:06 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 14 Oct 2012 17:12:14 +0200 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Sun, 14 Oct 2012 17:01:00 +0200 From: Muly Ilan To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] mpls wg last call for draft-ietf-mpls-tp-oam-id-mib Thread-Index: AQHNqIDWXf9JwPrq80S7hqjdpoGJX5e45jbw Date: Sun, 14 Oct 2012 15:00:59 +0000 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC870432CB2B@EXRAD5.ad.rad.co.il> References: <50782094.5050104@pi.nu> In-Reply-To: <50782094.5050104@pi.nu> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090206.507AD3AE.0030,ss=1,fgs=0 Subject: Re: [mpls] mpls wg last call for draft-ietf-mpls-tp-oam-id-mib X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 15:01:10 -0000 Support. Muly -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Friday, October 12, 2012 3:52 PM To: mpls@ietf.org Cc: MPLS-TP ad hoc team; draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org Subject: [mpls] mpls wg last call for draft-ietf-mpls-tp-oam-id-mib Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-o= am-id-mib-01. Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and if you are happy with the document= as is also indications of support. This working group last call will end on October 28. /Loa for the wg co-chairs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ____________= ___________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From wim.henderickx@alcatel-lucent.com Sun Oct 14 10:04:07 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7109E21F84D1 for ; Sun, 14 Oct 2012 10:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.78 X-Spam-Level: X-Spam-Status: No, score=-8.78 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, HELO_EQ_FR=0.35, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiA4eZ3Er8is for ; Sun, 14 Oct 2012 10:04:06 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 56E5D21F846A for ; Sun, 14 Oct 2012 10:04:06 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q9EH44EJ031171 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 14 Oct 2012 19:04:04 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sun, 14 Oct 2012 19:04:04 +0200 From: "Henderickx, Wim (Wim)" To: "draft-zjns-mpls-lsp-ping-relay-reply@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Date: Sun, 14 Oct 2012 19:04:03 +0200 Thread-Topic: draft-zjns-mpls-lsp-ping-relay-reply Thread-Index: Ac2qLeltX1POOOjUR46vELi3+yY8uA== Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702E1D82C8D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "'mpls@ietf.org'" Subject: [mpls] draft-zjns-mpls-lsp-ping-relay-reply X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 17:04:07 -0000 I have been asked to review the above draft as one of the reviewers. The doc is useful in certain MPLS scenario's as described in the draft. It = could be considered to be adopted as a WG doc. Here are some comments which would make the draft more sound. 1. Describe the behavior for devices that did not implement the additional = TLVs. How would they behave. 2. Describe the behavior if the packet length would be exceeded by the Rela= y Node Address Stack TLV 3. Give an example in the text for the inter-AS and seamless MPLS scenario = how the different devices behave with a use case 4. Describe in which scenarios this is applicable: mainly transport MPLS, b= ut not in IP-VPN or L2-VPN scenarios From loa@pi.nu Sun Oct 14 13:51:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4823821F8489; Sun, 14 Oct 2012 13:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE0D+uiqrMo4; Sun, 14 Oct 2012 13:51:38 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id A776A21F8484; Sun, 14 Oct 2012 13:51:38 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id E99A882475; Sun, 14 Oct 2012 22:51:31 +0200 (CEST) Message-ID: <507B25D3.4000800@pi.nu> Date: Sun, 14 Oct 2012 22:51:31 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: The IESG , Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ipv6-pw-lsp-ping@tools.ietf.org" Subject: [mpls] publication request: draft-ietf-mpls-ipv6-pw-lsp-ping-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 20:51:39 -0000 IESG, The MPLS working group request that: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs draft-ietf-mpls-ipv6-pw-lsp-ping-02 is published as an RFC on the standards track. Please find the shepherd write up included. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Sun Oct 14 14:54:50 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA6121F84F1; Sun, 14 Oct 2012 14:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvUTjnqCHSa6; Sun, 14 Oct 2012 14:54:49 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5831D21F84EE; Sun, 14 Oct 2012 14:54:49 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 09BEC82475; Sun, 14 Oct 2012 23:54:43 +0200 (CEST) Message-ID: <507B34A4.2040605@pi.nu> Date: Sun, 14 Oct 2012 23:54:44 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: The IESG , Adrian Farrel References: <507B25D3.4000800@pi.nu> In-Reply-To: <507B25D3.4000800@pi.nu> Content-Type: multipart/mixed; boundary="------------030400040409040804070202" Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ipv6-pw-lsp-ping@tools.ietf.org" Subject: Re: [mpls] publication request: draft-ietf-mpls-ipv6-pw-lsp-ping-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 21:54:50 -0000 This is a multi-part message in MIME format. --------------030400040409040804070202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, I missed the attachment, it is now included. Carlos, thanks for pointing this out. /Loa On 2012-10-14 22:51, Loa Andersson wrote: > IESG, > > > The MPLS working group request that: > > Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs > draft-ietf-mpls-ipv6-pw-lsp-ping-02 > > is published as an RFC on the standards track. > > Please find the shepherd write up included. > > > /Loa > for the mpls wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 --------------030400040409040804070202 Content-Type: text/plain; charset=windows-1252; name="draft-ietf-mpls-ipv6-pw-lsp-ping.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-mpls-ipv6-pw-lsp-ping.txt" DQoNCigxKSBXaGF0IHR5cGUgb2YgUkZDIGlzIGJlaW5nIHJlcXVlc3RlZCAoQkNQLCBQcm9w b3NlZCBTdGFuZGFyZCwgDQogICAgSW50ZXJuZXQgU3RhbmRhcmQsIEluZm9ybWF0aW9uYWws IEV4cGVyaW1lbnRhbCwgb3IgSGlzdG9yaWMpPyANCiAgICBXaHkgaXMgdGhpcyB0aGUgcHJv cGVyIHR5cGUgb2YgUkZDPyBJcyB0aGlzIHR5cGUgb2YgUkZDIGluZGljYXRlZA0KICAgIGlu IHRoZSB0aXRsZSBwYWdlIGhlYWRlcj8NCg0KDQogICBUaGUgTVBMUyB3b3JraW5nIGdyb3Vw IHJlcXVlc3QgdGhhdDogDQoNCiAgICAgICAgIExhYmVsIFN3aXRjaGVkIFBhdGggKExTUCkg UGluZyBmb3IgSVB2NiBQc2V1ZG93aXJlIEZFQ3MNCg0KICAgICAgICAgICAgICAgIGRyYWZ0 LWlldGYtbXBscy1pcHY2LXB3LWxzcC1waW5nLTAyDQoNCiAgIGlzIHB1Ymxpc2hlZCBhcyBh biBSRkMgb24gdGhlIHN0YW5kYXJkcyB0cmFjay4NCg0KDQpUaGlzIGRyYWZ0IHNwZWNpZmlj IGEgcmF0aGVyIHNtYWxsIGV4dGVuc2lvbiB0byBSRkM0Mzc5IChEZXRlY3RpbmcNCk11bHRp LVByb3RvY29sIExhYmVsIFN3aXRjaGVkIChNUExTKSBEYXRhIFBsYW5lIEZhaWx1cmVzKSwg aXQgYWRkcw0KZWxlbWVudHMgbmVjZXNzYXJ5IHRvIHVzZSBMU1AgUGluZyBmb3IgSVB2NiBQ V3MuIFRoaXMgcHJvdG9jb2wgDQpzcGVjaWZpY2F0aW9uIGlzIGludGVuZGVkIGZvciBzZXJ2 aWNlICBwcm92aWRlciBuZXR3b3JrcyB0byBiZSB1c2VlZA0KdW5kZXIgb3BlcmF0aW9uYWwg Y29uZGl0aW9ucywgaXQgY2xlYXJseSBtZWV0cyB0aGUgY3JpdGVyaWEgdG8gYmVjb21lIA0K YSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQuDQoNCg0KKDIpIFRoZSBJRVNHIGFwcHJvdmFs IGFubm91bmNlbWVudCBpbmNsdWRlcyBhIERvY3VtZW50IEFubm91bmNlbWVudA0KICAgIFdy aXRlLVVwLiBQbGVhc2UgcHJvdmlkZSBzdWNoIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50IFdy aXRlLVVwLg0KICAgIFJlY2VudCBleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4gdGhlICJBY3Rp b24iIGFubm91bmNlbWVudHMgZm9yDQogICAgYXBwcm92ZWQgZG9jdW1lbnRzLiBUaGUgYXBw cm92YWwgYW5ub3VuY2VtZW50IGNvbnRhaW5zIHRoZSANCiAgICBmb2xsb3dpbmcgc2VjdGlv bnM6DQoNCiAgICBUZWNobmljYWwgU3VtbWFyeToNCg0KDQpNdWx0aS1Qcm90b2NvbCBMYWJl bCBTd2l0Y2hpbmcgKE1QTFMpIExhYmVsIFN3aXRjaGVkIFBhdGggKExTUCkgUGluZw0KYW5k IHRyYWNlcm91dGUgbWVjaGFuaXNtcyBhcmUgY29tbW9ubHkgdXNlZCB0byBkZXRlY3QgYW5k IGlzb2xhdGUNCmRhdGEgcGxhbmUgZmFpbHVyZXMgaW4gYWxsIE1QTFMgTFNQcyBpbmNsdWRp bmcgUHNldWRvd2lyZSAoUFcpIExTUHMuDQpUaGUgUFcgTFNQIFBpbmcgYW5kIHRyYWNlcm91 dGUgZWxlbWVudHMsIGhvd2V2ZXIsIGFyZSBub3Qgc3BlY2lmaWVkDQpmb3IgSVB2NiBhZGRy ZXNzIHVzYWdlLg0KDQpUaGlzIGRvY3VtZW50IGV4dGVuZHMgdGhlIFBXIExTUCBQaW5nIGFu ZCB0cmFjZXJvdXRlIG1lY2hhbmlzbXMgc28NCnRoZXkgY2FuIGJlIHVzZWQgd2l0aCBJUHY2 IFBXcywgYW5kIHVwZGF0ZXMgUkZDIDQzNzkuDQoNCg0KDQogICAgV29ya2luZyBHcm91cCBT dW1tYXJ5Og0KDQogICAgV2FzIHRoZXJlIGFueXRoaW5nIGluIFdHIHByb2Nlc3MgdGhhdCBp cyB3b3J0aCBub3Rpbmc/IEZvciANCiAgICBleGFtcGxlLCB3YXMgdGhlcmUgY29udHJvdmVy c3kgYWJvdXQgcGFydGljdWxhciBwb2ludHMgb3Igd2VyZQ0KICAgIHRoZXJlIGRlY2lzaW9u cyB3aGVyZSB0aGUgY29uc2Vuc3VzIHdhcyBwYXJ0aWN1bGFybHkgcm91Z2g/DQoNClRoZXJl IGlzIGEgZ2VuZXJhbCBhZ3JlZW1lbnQgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgdGhhdCBzb21l IG9mIG91cg0KcHJvdG9jb2xzIG5lZWQgdG8gYmUgZXh0ZW5kZWQgdG8gbWVldCByZXF1aXJl bWVudHMgcHJlc2VudCBpbiBJUHY2DQpuZXR3b3Jrcy4gVGhpcyBpcyBvbmUgb2Ygc3VjaCBl eHRlbnNpb24gdG8gTFNQIFBpbmcuDQoNClRoZXJlIGlzIGdvb2Qgc3VwcG9ydCBmb3IgdGhl IGRvY3VtZW50LiANCg0KICAgIERvY3VtZW50IFF1YWxpdHk6DQoNCiAgICBBcmUgdGhlcmUg ZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBwcm90b2NvbD8gSGF2ZSBhIA0KICAg IHNpZ25pZmljYW50IG51bWJlciBvZiB2ZW5kb3JzIGluZGljYXRlZCB0aGVpciBwbGFuIHRv IGltcGxlbWVudA0KICAgIHRoZSBzcGVjaWZpY2F0aW9uPyBBcmUgdGhlcmUgYW55IHJldmll d2VycyB0aGF0IG1lcml0IHNwZWNpYWwgDQogICAgbWVudGlvbiBhcyBoYXZpbmcgZG9uZSBh IHRob3JvdWdoIHJldmlldywgZS5nLiwgb25lIHRoYXQgcmVzdWx0ZWQNCiAgICBpbiBpbXBv cnRhbnQgY2hhbmdlcyBvciBhIGNvbmNsdXNpb24gdGhhdCB0aGUgZG9jdW1lbnQgaGFkIG5v IA0KICAgIHN1YnN0YW50aXZlIGlzc3Vlcz8gSWYgdGhlcmUgd2FzIGEgTUlCIERvY3Rvciwg TWVkaWEgVHlwZSBvcg0KICAgIG90aGVyIGV4cGVydCByZXZpZXcsIHdoYXQgd2FzIGl0cyBj b3Vyc2UgKGJyaWVmbHkpPyBJbiB0aGUgY2FzZQ0KICAgIG9mIGEgTWVkaWEgVHlwZSByZXZp ZXcsIG9uIHdoYXQgZGF0ZSB3YXMgdGhlIHJlcXVlc3QgcG9zdGVkPw0KDQpXZSBrbm93IG9m IHNldmVyYWwgaW1wbGVtZW50YXRpb25zIG9yIGludGVudHMgdG8gaW1wbGVtZW50IHRoaXMg DQpkcmFmdC4NCg0KICAgIFBlcnNvbm5lbDoNCg0KICAgIFdobyBpcyB0aGUgRG9jdW1lbnQg U2hlcGhlcmQ/DQoNCkxvYSBBbmRlcnNzb24gaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0K DQogICAgV2hvIGlzIHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yPw0KDQpBZHJpYW4g RmFycmVsIGlzIHRoZSByZXNwb25zaWJsZSBBRC4NCg0KICAgICgzKSBCcmllZmx5IGRlc2Ny aWJlIHRoZSByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCB0aGF0IHdhcyANCiAgICBwZXJmb3Jt ZWQgYnkgdGhlIERvY3VtZW50IFNoZXBoZXJkLiBJZiB0aGlzIHZlcnNpb24gb2YgdGhlDQog ICAgZG9jdW1lbnQgaXMgbm90IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgcGxlYXNlIGV4cGxh aW4gd2h5IHRoZSANCiAgICBkb2N1bWVudCBpcyBiZWluZyBmb3J3YXJkZWQgdG8gdGhlIElF U0cuDQoNClRoZSBkb2N1bWVudCBzaGVwaGVyZCByZXZpZXdlZCB0aGUgZG9jdW1lbnQgYXQg dGhlIHBvaW50IGluIHRpbWUNCndoZW4gaXQgd2FzIGJlaW5nIHBvbGxlZCB0byBiZWNvbWUg YSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IGFuZCBhcyANCmEgcGFydCBvZiB0aGUgcHJlcGFy YXRpb24gZm9yIHRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NClRoZSBJQU5BIHNlY3Rp b24gaGFzIGJlZW4gcmV2aWV3ZWQgc2V2ZXJhbCB0aW1lcy4NCg0KICAgICg0KSBEb2VzIHRo ZSBkb2N1bWVudCBTaGVwaGVyZCBoYXZlIGFueSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGgN CiAgICBvciBicmVhZHRoIG9mIHRoZSByZXZpZXdzIHRoYXQgaGF2ZSBiZWVuIHBlcmZvcm1l ZD8NCg0KTm8gc3VjaCBjb25jZXJucy4NCg0KICAgICg1KSBEbyBwb3J0aW9ucyBvZiB0aGUg ZG9jdW1lbnQgbmVlZCByZXZpZXcgZnJvbSBhIHBhcnRpY3VsYXIgb3INCiAgICBmcm9tIGJy b2FkZXIgcGVyc3BlY3RpdmUsIGUuZy4sIHNlY3VyaXR5LCBvcGVyYXRpb25hbCANCiAgICBj b21wbGV4aXR5LCBBQUEsIEROUywgREhDUCwgWE1MLCBvciBpbnRlcm5hdGlvbmFsaXphdGlv bj8gSWYgc28sDQogICAgZGVzY3JpYmUgdGhlIHJldmlldyB0aGF0IHRvb2sgcGxhY2UuDQoN ClRoZSBkb2N1bWVudCBzaGVwaGVyZCBiZWxpZXZlcyB0aGF0IHRoZSBjdXJyZW50IHJldmll dyBzaXR1YXRpb24gaXMNCnN1ZmZpY2llbnQuDQoNCiAgICAoNikgRGVzY3JpYmUgYW55IHNw ZWNpZmljIGNvbmNlcm5zIG9yIGlzc3VlcyB0aGF0IHRoZSBEb2N1bWVudCANCiAgICBTaGVw aGVyZCBoYXMgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEg DQogICAgRGlyZWN0b3IgYW5kL29yIHRoZSBJRVNHIHNob3VsZCBiZSBhd2FyZSBvZj8gRm9y IGV4YW1wbGUsIA0KICAgIHBlcmhhcHMgaGUgb3Igc2hlIGlzIHVuY29tZm9ydGFibGUgd2l0 aCBjZXJ0YWluIHBhcnRzIG9mIHRoZSANCiAgICBkb2N1bWVudCwgb3IgaGFzIGNvbmNlcm5z IHdoZXRoZXIgdGhlcmUgcmVhbGx5IGlzIGEgbmVlZCBmb3IgaXQuDQogICAgSW4gYW55IGV2 ZW50LCBpZiB0aGUgV0cgaGFzIGRpc2N1c3NlZCB0aG9zZSBpc3N1ZXMgYW5kIGhhcyANCiAg ICBpbmRpY2F0ZWQgdGhhdCBpdCBzdGlsbCB3aXNoZXMgdG8gYWR2YW5jZSB0aGUgZG9jdW1l bnQsIGRldGFpbA0KICAgIHRob3NlIGNvbmNlcm5zIGhlcmUuDQoNCk5vIHN1Y2ggY29uY2Vy bnMuDQoNCiAgICAoNykgSGFzIGVhY2ggYXV0aG9yIGNvbmZpcm1lZCB0aGF0IGFueSBhbmQg YWxsIGFwcHJvcHJpYXRlIElQUg0KICAgIGRpc2Nsb3N1cmVzIHJlcXVpcmVkIGZvciBmdWxs IGNvbmZvcm1hbmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YNCiAgICBCQ1AgNzggYW5kIEJD UCA3OSBoYXZlIGFscmVhZHkgYmVlbiBmaWxlZC4gSWYgbm90LCBleHBsYWluIHdoeT8NCg0K QSBwb2xsIGZvciBJUFJzIGhhcyBiZWVuIGRvbmUgYW1vbmcgdGhlIGF1dGhvcnMgYW5kIGlu IHRoZSB3b3JraW5nIA0KZ3JvdXAuDQpBbGwgdGhlIGF1dGhvcnMgaGFzIGNvbmZpcm1lZCB0 aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkgZXhpc3RpbmcNCklQUiBjbGFpbXMuDQoN CiAgICAoOCkgSGFzIGFuIElQUiBkaXNjbG9zdXJlIGJlZW4gZmlsZWQgdGhhdCByZWZlcmVu Y2VzIHRoaXMNCiAgICBkb2N1bWVudD8gSWYgc28sIHN1bW1hcml6ZSBhbnkgV0cgZGlzY3Vz c2lvbiBhbmQgY29uY2x1c2lvbiANCiAgICByZWdhcmRpbmcgdGhlIElQUiBkaXNjbG9zdXJl cy4NCg0KTm8gSVBSIGRpc2Nsb3N1cmVzIGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkg b24gZHJhZnQtaWV0Zi1tcGxzLQ0KaXB2Ni1wdy1sc3AtcGluZyBvciBpdHMgcHJlZGVjZXNz b3IgZHJhZnQtY2hlbi1tcGxzLWlwdjYtcHctbHNwLXBpbmcuDQoNCiAgICAoOSkgSG93IHNv bGlkIGlzIHRoZSBXRyBjb25zZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQ/IERvZXMgaXQN CiAgICByZXByZXNlbnQgdGhlIHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlk dWFscywgd2l0aCANCiAgICBvdGhlcnMgYmVpbmcgc2lsZW50LCBvciBkb2VzIHRoZSBXRyBh cyBhIHdob2xlIHVuZGVyc3RhbmQgYW5kIA0KICAgIGFncmVlIHdpdGggaXQ/DQoNClRoZXJl IGFyZSBnb29kIHN1cHBvcnQgZm9yIHRoaXMgZG9jdW1lbnQhDQoNCiAgICAoMTApIEhhcyBh bnlvbmUgdGhyZWF0ZW5lZCBhbiBhcHBlYWwgb3Igb3RoZXJ3aXNlIGluZGljYXRlZA0KICAg IGV4dHJlbWUgZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1tYXJpc2UgdGhlIGFyZWFz IG9mIA0KICAgIGNvbmZsaWN0IGluIHNlcGFyYXRlIGVtYWlsIG1lc3NhZ2VzIHRvIHRoZSBS ZXNwb25zaWJsZSBBcmVhIA0KICAgIERpcmVjdG9yLiAoSXQgc2hvdWxkIGJlIGluIGEgc2Vw YXJhdGUgZW1haWwgYmVjYXVzZSB0aGlzDQogICAgcXVlc3Rpb25uYWlyZSBpcyBwdWJsaWNs eSBhdmFpbGFibGUuKQ0KDQpObyBzdWNoIHRocmVhdHMhDQoNCiAgICAoMTEpIElkZW50aWZ5 IGFueSBJRCBuaXRzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXMgZm91bmQgaW4NCiAgICB0 aGlzIGRvY3VtZW50LiAoU2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvdG9vbHMvaWRuaXRzLyBh bmQgdGhlDQogICAgSW50ZXJuZXQtRHJhZnRzIENoZWNrbGlzdCkuIEJvaWxlcnBsYXRlIGNo ZWNrcyBhcmUgbm90IGVub3VnaDsgDQogICAgdGhpcyBjaGVjayBuZWVkcyB0byBiZSB0aG9y b3VnaC4NCg0KVGhpcyBkb2N1bWVudCBwYXNzZXMgdGhlIElELW5pdHMgdG9vbCBjbGVhbi4N Cg0KICAgICgxMikgRGVzY3JpYmUgaG93IHRoZSBkb2N1bWVudCBtZWV0cyBhbnkgcmVxdWly ZWQgZm9ybWFsIHJldmlldyANCiAgICBjcml0ZXJpYSwgc3VjaCBhcyB0aGUgTUlCIERvY3Rv ciwgbWVkaWEgdHlwZSwgYW5kIFVSSSB0eXBlIA0KICAgIHJldmlld3MuDQoNCk5vIHN1Y2gg Zm9ybWFsIHJldmlldyByZXF1aXJlbWVudHMhDQoNCiAgICAoMTMpIEhhdmUgYWxsIHJlZmVy ZW5jZXMgd2l0aGluIHRoaXMgZG9jdW1lbnQgYmVlbiBpZGVudGlmaWVkIGFzDQogICAgZWl0 aGVyIG5vcm1hdGl2ZSBvciBpbmZvcm1hdGl2ZT8NCg0KWWVzLg0KDQogICAgKDE0KSBBcmUg dGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQgYXJlIG5vdA0K ICAgIHJlYWR5IGZvciBhZHZhbmNlbWVudCBvciBhcmUgb3RoZXJ3aXNlIGluIGFuIHVuY2xl YXIgc3RhdGU/IElmIA0KICAgIHN1Y2ggbm9ybWF0aXZlIHJlZmVyZW5jZXMgZXhpc3QsIHdo YXQgaXMgdGhlIHBsYW4gZm9yIHRoZWlyIA0KICAgIGNvbXBsZXRpb24/DQoNCkFsbCBub3Jt YXRpdmUgcmVmZXJlbmNlcyBhcmUgUkZDcy4NCg0KICAgICgxNSkgQXJlIHRoZXJlIGRvd253 YXJkIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHJlZmVyZW5jZXMgDQogICAgKHNlZSBSRkMgMzk2 Nyk/IElmIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMgdG8gc3VwcG9ydA0K ICAgIHRoZSBBcmVhIERpcmVjdG9yIGluIHRoZSBMYXN0IENhbGwgcHJvY2VkdXJlLg0KDQpO byBkb3dud2FyZCByZWZlcmVuY2VzLg0KDQogICAgKDE2KSBXaWxsIHB1YmxpY2F0aW9uIG9m IHRoaXMgZG9jdW1lbnQgY2hhbmdlIHRoZSBzdGF0dXMgb2YgYW55IA0KICAgIGV4aXN0aW5n IFJGQ3M/IEFyZSB0aG9zZSBSRkNzIGxpc3RlZCBvbiB0aGUgdGl0bGUgcGFnZSBoZWFkZXIs IA0KICAgIGxpc3RlZCBpbiB0aGUgYWJzdHJhY3QsIGFuZCBkaXNjdXNzZWQgaW4gdGhlIGlu dHJvZHVjdGlvbj8gSWYgDQogICAgdGhlIFJGQ3MgYXJlIG5vdCBsaXN0ZWQgaW4gdGhlIEFi c3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24sIGV4cGxhaW4NCiAgICB3aHksIGFuZCBwb2ludCB0 byB0aGUgcGFydCBvZiB0aGUgZG9jdW1lbnQgd2hlcmUgdGhlIHJlbGF0aW9uc2hpcA0KICAg IG9mIHRoaXMgZG9jdW1lbnQgdG8gdGhlIG90aGVyIFJGQ3MgaXMgZGlzY3Vzc2VkLiBJZiB0 aGlzIA0KICAgIGluZm9ybWF0aW9uIGlzIG5vdCBpbiB0aGUgZG9jdW1lbnQsIGV4cGxhaW4g d2h5IHRoZSBXRyBjb25zaWRlcnMNCiAgICBpdCB1bm5lY2Vzc2FyeS4NCg0KVGhpcyBkb2N1 bWVudCBleHRlbmRzIGFuZCB1cGRhdGVzIFJGQzQzNzksIHRoaXMgaXMgZGlzY3Vzc2VkIGlu IHRoZSANCkFic3RyYWN0IGFuZCB0aGUgSW50cm9kdWN0aW9uDQoNCiAgICAoMTcpIERlc2Ny aWJlIHRoZSBEb2N1bWVudCBTaGVwaGVyZCdzIHJldmlldyBvZiB0aGUgSUFOQSANCiAgICBj b25zaWRlcmF0aW9ucyBzZWN0aW9uLCBlc3BlY2lhbGx5IHdpdGggcmVnYXJkIHRvIGl0cyAN CiAgICBjb25zaXN0ZW5jeSB3aXRoIHRoZSBib2R5IG9mIHRoZSBkb2N1bWVudC4gQ29uZmly bSB0aGF0IGFsbCANCiAgICBwcm90b2NvbCBleHRlbnNpb25zIHRoYXQgdGhlIGRvY3VtZW50 IG1ha2VzIGFyZSBhc3NvY2lhdGVkIHdpdGgNCiAgICB0aGUgYXBwcm9wcmlhdGUgcmVzZXJ2 YXRpb25zIGluIElBTkEgcmVnaXN0cmllcy4gQ29uZmlybSB0aGF0DQogICAgYW55IHJlZmVy ZW5jZWQgSUFOQSByZWdpc3RyaWVzIGhhdmUgYmVlbiBjbGVhcmx5IGlkZW50aWZpZWQuIA0K ICAgIENvbmZpcm0gdGhhdCBuZXdseSBjcmVhdGVkIElBTkEgcmVnaXN0cmllcyBpbmNsdWRl IGEgZGV0YWlsZWQNCiAgICBzcGVjaWZpY2F0aW9uIG9mIHRoZSBpbml0aWFsIGNvbnRlbnRz IGZvciB0aGUgcmVnaXN0cnksIHRoYXQgDQogICAgYWxsb2NhdGlvbnMgcHJvY2VkdXJlcyBm b3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnMgYXJlIGRlZmluZWQsIA0KICAgIGFuZCBhIHJlYXNv bmFibGUgbmFtZSBmb3IgdGhlIG5ldyByZWdpc3RyeSBoYXMgYmVlbiBzdWdnZXN0ZWQgDQog ICAgKHNlZSBSRkMgNTIyNikuDQoNClRoaXMgZG9jdW1lbnQgaGFzIGEgY2xlYXIgYW5kIHdl bGwtd3JpdHRlbiBJQU5BIHNlY3Rpb24uDQoNCg0KDQogICAgKDE4KSBMaXN0IGFueSBuZXcg SUFOQSByZWdpc3RyaWVzIHRoYXQgcmVxdWlyZSBFeHBlcnQgUmV2aWV3IGZvcg0KICAgIGZ1 dHVyZSBhbGxvY2F0aW9ucy4gUHJvdmlkZSBhbnkgcHVibGljIGd1aWRhbmNlIHRoYXQgdGhl IElFU0cgDQogICAgd291bGQgZmluZCB1c2VmdWwgaW4gc2VsZWN0aW5nIHRoZSBJQU5BIEV4 cGVydHMgZm9yIHRoZXNlIG5ldyANCiAgICByZWdpc3RyaWVzLg0KDQpObyBuZXcgSUFOQSBy ZWdpc3RyaWVzLg0KDQogICAgKDE5KSBEZXNjcmliZSByZXZpZXdzIGFuZCBhdXRvbWF0ZWQg Y2hlY2tzIHBlcmZvcm1lZCBieSB0aGUgDQogICAgRG9jdW1lbnQgU2hlcGhlcmQgdG8gdmFs aWRhdGUgc2VjdGlvbnMgb2YgdGhlIGRvY3VtZW50IHdyaXR0ZW4gDQogICAgaW4gYSBmb3Jt YWwgbGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MIGNvZGUsIEJORiBydWxlcywgTUlCIA0KICAgIGRl ZmluaXRpb25zLCBldGMuDQoNCk5vIHN1Y2ggcmV2aWV3IHJlcXVpcmVkLg== --------------030400040409040804070202-- From curtis@occnc.com Sun Oct 14 18:11:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C6621F853E for ; Sun, 14 Oct 2012 18:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzf0Lldvycig for ; Sun, 14 Oct 2012 18:11:30 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id A621921F846A for ; Sun, 14 Oct 2012 18:11:29 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q9F1BPRZ059585; Sun, 14 Oct 2012 21:11:25 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210150111.q9F1BPRZ059585@gateway1.orleans.occnc.com> To: MPLS WG mailing list From: Curtis Villamizar Date: Sun, 14 Oct 2012 21:11:25 -0400 Subject: [mpls] draft-villamizar-mpls-forwarding X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 01:11:31 -0000 Kireeti and I have received comments from Andy Malis and Paul Doolan (off list) regarding draft-villamizar-mpls-forwarding (MPLS Forwarding Compliance and Performance Requirements). The next draft iteration will reflect these comments. In addition it occurred to me that we need to mention in the draft that the labels which are POPed at an LSP egress SHOULD NOT be considered in the hash. The reason for this is that a different path could be taken if the prior hop changes, such as through reroute of a PSC LSP carrying the prior hop, or FRR in a prior hop, or MPLS-TP protection state change in a server layer carrying the prior hop. The downstream hop is only affected if UHP is in effect (generally affecting only MPLS-TP). The condition is "labels which are POPed at an LSP egress", intentionally excluding labels POPed at a LSP PHP hop from this rule. This rule is a NOOP unless a non-MPLS-TP LSP uses UHP for some reason. Curtis ------- Forwarded Message From: Kireeti Kompella Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Date: Mon, 8 Oct 2012 17:30:37 -0700 References: <20121008234908.29887.1630.idtracker@ietfa.amsl.com> To: "mpls@ietf.org" Subject: [mpls] Fwd: New Version Notification for draft-villamizar-mpls-forwarding-00.txt Hi Folks, I'd spoken on the issue of deep label stacks at the last IETF, and there was interest from chip suppliers, vendors and service providers. Curtis just submitted the draft; it goes beyond just deep label stacks. There are suggestions in the draft on aspects of implementing MPLS forwarding, as well as questions to ask regarding an implementation, and things to test. Please read and comment to the list. If you (that includes MPLS WG chairs and ADs) could also formulate your thoughts on what type of doc (Info, BCP, PS) this should be, that would be very helpful in moving this discussion forward. Thanks, Kireeti. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-villamizar-mpls-forwarding-00.txt > Date: October 8, 2012 16:49:08PDT > To: curtis@occnc.com > Cc: kireeti.kompella@gmail.com > > > A new version of I-D, draft-villamizar-mpls-forwarding-00.txt > has been successfully submitted by Curtis Villamizar and posted to the > IETF repository. > > Filename: draft-villamizar-mpls-forwarding > Revision: 00 > Title: MPLS Forwarding Compliance and Performance Requirements > Creation date: 2012-10-08 > WG ID: Individual Submission > Number of pages: 17 > URL: http://www.ietf.org/internet-drafts/draft-villamizar-mpls-forwarding-00.txt > Status: http://datatracker.ietf.org/doc/draft-villamizar-mpls-forwarding > Htmlized: http://tools.ietf.org/html/draft-villamizar-mpls-forwarding-00 > > > Abstract: > This document provides guidelines for implementors regarding MPLS > forwarding and a basis for evaluations of forwarding implementations. > Guidelines cover basic MPLS forwarding, forwarding when a deep MPLS > label stack is encountered, MPLS UHP operations which require one or > more label POP plus a PUSH, guidelines for hashing an MPLS stack and > payload for multipath, and conformance and performance requirements > for recent pseudowire and MPLS standards. > > > > > The IETF Secretariat > From loa@pi.nu Mon Oct 15 03:58:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C74421F86B5 for ; Mon, 15 Oct 2012 03:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxdKzN9pGnwp for ; Mon, 15 Oct 2012 03:58:18 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4212221F86AF for ; Mon, 15 Oct 2012 03:58:18 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 0683882451; Mon, 15 Oct 2012 12:58:10 +0200 (CEST) Message-ID: <507BEC44.5030102@pi.nu> Date: Mon, 15 Oct 2012 12:58:12 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-zjns-mpls-lsp-ping-relay-reply@tools.ietf.org Subject: [mpls] IPR poll on draft-zjns-mpls-lsp-ping-relay-reply X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 10:58:19 -0000 Working Group and authors; The authors of draft-zjns-mpls-lsp-ping-relay-reply has indicated that the draft is ready to be adopted as a working group document. Before starting the poll to make the draft become a working group document we will do an IPR poll to check whether there is IPR on the document that needs to be disclosed. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-zjns-mpls-lsp-ping-relay-reply? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Mon Oct 15 05:28:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFB721F86A7 for ; Mon, 15 Oct 2012 05:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJHTmZbYKpbs for ; Mon, 15 Oct 2012 05:28:40 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 531C021F86A3 for ; Mon, 15 Oct 2012 05:28:40 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id C520E82451; Mon, 15 Oct 2012 14:28:33 +0200 (CEST) Message-ID: <507C0172.1030309@pi.nu> Date: Mon, 15 Oct 2012 14:28:34 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 12:28:41 -0000 Working Group and authors; The authors of draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp has indicated that the draft is ready to be adopted as a working group document. Before starting the poll to make the draft become a working group document we will do an IPR poll to check whether there is IPR on the document that needs to be disclosed. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From rgandhi@cisco.com Mon Oct 15 05:40:58 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2E821F86AB for ; Mon, 15 Oct 2012 05:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.285 X-Spam-Level: X-Spam-Status: No, score=-9.285 tagged_above=-999 required=5 tests=[AWL=1.314, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgM-oZ7RB-Bc for ; Mon, 15 Oct 2012 05:40:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 18C5821F869E for ; Mon, 15 Oct 2012 05:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1892; q=dns/txt; s=iport; t=1350304858; x=1351514458; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LGPD9Vp6P/iACRzaTNWwBhhpaKySvYPk9wPf9aV0miE=; b=mrQHm2nsxvvVRJT88K+AVXW9qdcDije5G1sypKfwH3G4CRRWm7zYqqsi 9KodQ3wygnel8O1AZyZ4c7GmOaMIfHDmtl0d8CEu3wHzBY4QnVN/l8a24 +LlXt2dwO7+kEczZqXpA5JjPr1Yfey9XIPNuxeBbW0NZ8FNZ9siXRKCLC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABwDfFCtJV2d/2dsb2JhbABFv3iBCIIgAQEBBBIBJzQGBQwCAgIBCBEEAQELFAkHGxcUCQgCBAENBQgah2ILnWWfTQSLVRqFQ2ADlwGNMIFrgm2BYzQ X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="131420810" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2012 12:40:57 +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 q9FCevpa005544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 12:40:57 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.191]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 07:40:57 -0500 From: "Rakesh Gandhi (rgandhi)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp Thread-Index: AQHNqtCenjfwfTAC1UeLWLsxCO9a95e6TqvQ Date: Mon, 15 Oct 2012 12:40:56 +0000 Message-ID: References: <507C0172.1030309@pi.nu> In-Reply-To: <507C0172.1030309@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.208.63] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--29.942700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "robert.h.venator.civ@mail.mil" Subject: Re: [mpls] draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 12:40:59 -0000 Hi Loa, Yes, IPR has been disclosed. http://datatracker.ietf.org/ipr/1861/ thanks, Rakesh -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Monday, October 15, 2012 8:29 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ali-mpls-inter-domain-p2mp-rsvp-te-ls= p@tools.ietf.org; Martin Vigoureux Subject: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp Working Group and authors; The authors of draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp has indicated t= hat the draft is ready to be adopted as a working group document. Before starting the poll to make the draft become a working group document = we will do an IPR poll to check whether there is IPR on the document that n= eeds to be disclosed. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the MPLS wg mailing list. The documents will = not advance to the next stage until a response has been received from each = author and contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From tsaad@cisco.com Mon Oct 15 06:02:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F59B21F869D for ; Mon, 15 Oct 2012 06:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFgILiuzhLxP for ; Mon, 15 Oct 2012 06:02:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 58E9E21F869E for ; Mon, 15 Oct 2012 06:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1671; q=dns/txt; s=iport; t=1350306140; x=1351515740; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=c0BbOx5mRoCYjV12V8X0XFS2iQqu8+oFkA6j7uGxqYQ=; b=LUrOiOSJ62fKrmCmIOzV6Yq2nzSl7UigzBm6dIykT1njIA2mmPQuQayp C9GO7KuNrKSdhILleiQ4SBHABTZrtrZiBsFnf8BjW5bwhvLF74sMky4UU 18MMRucm4vFeCrMiFehKModnEtMAnYBJZ1u+ZKJ8utZMZv1Zq7Bw/PqRt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPQIfFCtJXG+/2dsb2JhbABFv3iBCIIiAQQSASc0BgUOBAEIIhQrFyUCBAENBQgah2ILnW+fTwSLb4VDYAOXAY0wgWuCbYFjNA X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="131628971" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 15 Oct 2012 13:02:19 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9FD2JZB024033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 13:02:19 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 08:02:19 -0500 From: "Tarek Saad (tsaad)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp Thread-Index: AQHNqtCe8NL4HxSd+0uBnh7lI9iKR5e6Zb+A Date: Mon, 15 Oct 2012 13:02:19 +0000 Message-ID: <2170E89B881FEA48B3A35413AB6FC4300F41E02E@xmb-aln-x08.cisco.com> In-Reply-To: <507C0172.1030309@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.66.68] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--33.269200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 13:02:23 -0000 Hi Loa, IPR for this has been disclosed. http://datatracker.ietf.org/ipr/1861/ Thanks, Tarek On 12-10-15 8:28 AM, "Loa Andersson" wrote: >Working Group and authors; > >The authors of draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp has >indicated that the draft is ready to be adopted as a working >group document. > >Before starting the poll to make the draft become a working group >document we will do an IPR poll to check whether there is IPR on >the document that needs to be disclosed. > >This mail starts that IPR poll. > >Are you aware of any IPR that applies to > draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. The response needs to be sent to the MPLS wg mailing list. The >documents will not advance to the next stage until a response >has been received from each author and contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > > >Thanks, Loa >(as MPLS WG co-chair) > >--=20 > > >Loa Andersson email: loa.andersson@ericsson.com >Sr Strategy and Standards Manager loa@pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From loa@pi.nu Mon Oct 15 06:16:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2AB21F8714 for ; Mon, 15 Oct 2012 06:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSHbQtQQMVPU for ; Mon, 15 Oct 2012 06:16:52 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id B79F321F870E for ; Mon, 15 Oct 2012 06:16:46 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 1817C82451; Mon, 15 Oct 2012 15:16:41 +0200 (CEST) Message-ID: <507C0CBA.9040804@pi.nu> Date: Mon, 15 Oct 2012 15:16:42 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" References: <507C0172.1030309@pi.nu> In-Reply-To: <507C0172.1030309@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] Update: IPR poll draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 13:16:53 -0000 WG, as Tarek and Rakesh correctly pointed out we have IPR claim disclosure on this document:' http://datatracker.ietf.org/ipr/1861/ /Loa On 2012-10-15 14:28, Loa Andersson wrote: > Working Group and authors; > > The authors of draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp has > indicated that the draft is ready to be adopted as a working > group document. > > Before starting the poll to make the draft become a working group > document we will do an IPR poll to check whether there is IPR on > the document that needs to be disclosed. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. The response needs to be sent to the MPLS wg mailing list. The > documents will not advance to the next stage until a response > has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > Thanks, Loa > (as MPLS WG co-chair) > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From dave.mcdysan@verizon.com Mon Oct 15 08:54:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6318811E80D7 for ; Mon, 15 Oct 2012 08:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeZ+LLj0ofeh for ; Mon, 15 Oct 2012 08:54:27 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id F0F6811E80A6 for ; Mon, 15 Oct 2012 08:54:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 15 Oct 2012 15:54:26 +0000 From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="347205280" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi02.verizon.com with ESMTP; 15 Oct 2012 15:54:26 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([166.68.59.148]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Mon, 15 Oct 2012 11:54:25 -0400 To: Mpls , Ccamp Date: Mon, 15 Oct 2012 11:54:22 -0400 Thread-Topic: New Version Notification for draft-fuxh-mpls-delay-loss-te-problem-statement-00.txt Thread-Index: Ac2q7VoBNCqJuN90TmOlydYHnDbWlw== Message-ID: In-Reply-To: <20121015155224.22468.74526.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: New Version Notification for draft-fuxh-mpls-delay-loss-te-problem-statement-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:54:29 -0000 Hi, This draft has been submitted in response to the comments from the MPLS-RT.=20 We have requested time to present it in the mpls wg in Atlanta. There was some discussion that some aspects may be of interest to cccamp, so I am cross posting to that list. Thanks, Dave On 10/15/12 11:52 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, >draft-fuxh-mpls-delay-loss-te-problem-statement-00.txt >has been successfully submitted by Dave McDysan and posted to the >IETF repository. > >Filename: draft-fuxh-mpls-delay-loss-te-problem-statement >Revision: 00 >Title: Delay and Loss Traffic Engineering Problem Statement for MPLS >Creation date: 2012-10-15 >WG ID: Individual Submission >Number of pages: 14 >URL: =20 >http://www.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te-problem- >statement-00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-fuxh-mpls-delay-loss-te-problem-stat >ement >Htmlized: =20 >http://tools.ietf.org/html/draft-fuxh-mpls-delay-loss-te-problem-statement >-00 > > >Abstract: > Deployment and usage of cloud based applications and services that use > an underlying MPLS network are expanding and an increasing number of > applications are extremely sensitive to delay and packet loss. > Furthermore, in cloud computing an additional decision problem arises >of > simultaneously choosing the data center to host applications along with > MPLS network connectivity such that the overall performance of the > application is met. Existing mechanisms exist to measure and monitor > MPLS path performance parameters for packet loss and delay, but only > after the path has been setup. These cloud-based and performance > sensitive applications would benefit from measurement of MPLS network > and potential path information that would be provided for use in the > computation and selection of LSPs. > > This document provides a statement of problems faced by these cloud > based and performance sensitive applications and describes requirements > to enable the efficient and accurate measurement of the MPLS network >and > allow new performance parameters to be reported and used in the > computation of MPLS services in support of these cloud based and > performance sensitive applications. > > =20 > =20 > > >The IETF Secretariat > From zali@cisco.com Mon Oct 15 11:17:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51D521F88C6 for ; Mon, 15 Oct 2012 11:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5k8jOi00PsdV for ; Mon, 15 Oct 2012 11:17:50 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AEC5F21F8868 for ; Mon, 15 Oct 2012 11:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2420; q=dns/txt; s=iport; t=1350325070; x=1351534670; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GzQKRx9RexGyPMe7qHsnX6KHQBVmc7W4iBPdPhiouCU=; b=cEto7RASYpj5bvs3kdqCQ3Xrv9s00BKl9TSmA89Sg4liSRSozv//ZiWL Daky0UNzR+zae+Nt+68wuITaZaIr38irYqDeK63es9eGUc6pH+rtVgu7x kRTCxT55XXBeErT5zE/nqfMpnCeInAMwk492xAuTeDsLkw7tDAFxg6Cf6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMhRfFCtJXHA/2dsb2JhbABFwAOBCIIgAQEBBAEBAQ8BJzQGBQwCAgIBCBEEAQEBChQJBxsMCxQJCAIEAQ0FCBqHYgudUKAQBItVGoVDYAOXAY0wgWuCbYFjNA X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="131568911" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2012 18:17:50 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9FIHogp029301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 18:17:50 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 13:17:49 -0500 From: "Zafar Ali (zali)" To: "Tarek Saad (tsaad)" , Loa Andersson , "mpls@ietf.org" Thread-Topic: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp Thread-Index: AQHNqtCeX7DnZVnVJ0KoZ6Pa8WH73pe6qM2AgAAELNA= Date: Mon, 15 Oct 2012 18:17:48 +0000 Message-ID: References: <507C0172.1030309@pi.nu> <2170E89B881FEA48B3A35413AB6FC4300F41E02E@xmb-aln-x08.cisco.com> In-Reply-To: <2170E89B881FEA48B3A35413AB6FC4300F41E02E@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.8] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--48.890200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 18:17:51 -0000 Hi Loa, et al: I am not aware of any IRP other than the one mentioned by Tarek.=20 Thanks Regards...Zafar > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of T= arek Saad (tsaad) > Sent: Monday, October 15, 2012 9:02 AM > To: Loa Andersson; mpls@ietf.org > Cc: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org; mpls-cha= irs@tools.ietf.org > Subject: Re: [mpls] draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp >=20 > Hi Loa, >=20 > IPR for this has been disclosed. > http://datatracker.ietf.org/ipr/1861/ >=20 > Thanks, > Tarek >=20 >=20 >=20 > On 12-10-15 8:28 AM, "Loa Andersson" wrote: >=20 > >Working Group and authors; > > > >The authors of draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp has > >indicated that the draft is ready to be adopted as a working group > >document. > > > >Before starting the poll to make the draft become a working group > >document we will do an IPR poll to check whether there is IPR on the > >document that needs to be disclosed. > > > >This mail starts that IPR poll. > > > >Are you aware of any IPR that applies to > > draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp? > > > >If so, has this IPR been disclosed in compliance with IETF IPR rules > >(see RFCs 3979, 4879, 3669 and 5378 for more details). > > > >If you are listed as a document author or contributor please respond to > >this email regardless of whether or not you are aware of any relevant > >IPR. The response needs to be sent to the MPLS wg mailing list. The > >documents will not advance to the next stage until a response has been > >received from each author and contributor. > > > >If you are on the MPLS WG email list but are not listed as an author or > >contributor, then please explicitly respond only if you are aware of > >any IPR that has not yet been disclosed in conformance with IETF rules. > > > > > >Thanks, Loa > >(as MPLS WG co-chair) > > > >-- > > > > > >Loa Andersson email: loa.andersson@ericsson.com > >Sr Strategy and Standards Manager loa@pi.nu > >Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From andrea.allasia@telecomitalia.it Mon Oct 1 08:14:40 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6168911E8112 for ; Mon, 1 Oct 2012 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VF4TDa63Q9fz for ; Mon, 1 Oct 2012 08:14:39 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id C59A011E80D5 for ; Mon, 1 Oct 2012 08:14:38 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 1 Oct 2012 17:14:35 +0200 Received: from GRFMBX707BA020.griffon.local ([10.188.101.22]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Mon, 1 Oct 2012 17:14:34 +0200 From: Allasia Andrea To: D'Alessandro Alessandro Gerardo , Loa Andersson Date: Mon, 1 Oct 2012 17:14:32 +0200 Thread-Topic: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: AQHNllRf82qjNdoiA0OJzsZi6RX7kJehLihwgANBJaCAADLjUA== Message-ID: <51508CA9C4AE774DAC3FC6B8F0E5A5384691AB0F4E@GRFMBX707BA020.griffon.local> References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 15 Oct 2012 12:00:37 -0700 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: [mpls] R: R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:14:40 -0000 KzENCg0KLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCkRhOiBtcGxzLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBEJ0FsZXNz YW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvDQpJbnZpYXRvOiBsdW5lZMOsIDEgb3R0b2JyZSAyMDEy IDE0OjI3DQpBOiBMb2EgQW5kZXJzc29uDQpDYzogbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc7IE1QTFMtVFAgYWQgaG9jIHRlYW07IGRyYWZ0LWlldGYtbXBscy10cC1y aW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcNCk9nZ2V0dG86IFttcGxzXSBSOiBXb3JraW5n IGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoN CkRvIG5vdCBzdXBwb3J0DQoNCkFjY29yZGluZyB0byB0aGUgb3B0aW1pemF0aW9uIGNyaXRlcmlh IGZvciByaW5nIHByb3RlY3Rpb24gc3BlY2lmaWVkIGluIFNlY3Rpb24gMi41LjYuMSBpbiBSRkM1 NjU0LCB0aGUgTVBMUy1UUCByaW5nIHByb3RlY3Rpb24gc2hvdWxkIGJlIG9wdGltaXplZCBmb3Ig c2ltcGxpZmljYXRpb24gb2YgdGhlIHJpbmcgb3BlcmF0aW9uIGFuZCB0aGUgcmVzb3VyY2VzIGNv bnN1bXB0aW9uIGFyb3VuZCB0aGUgcmluZy4gSXQgaXMgbm90IHRoZSBjYXNlIG9mIHRoZSBwcm9w b3NlZCBzb2x1dGlvbi4NCkl0IGlzIGFjdHVhbGx5IHNpbXBseSBhbiBhcHBsaWNhYmlsaXR5IHN0 YXRlbWVudCBvZiBhIGxpbmVhciBwcm90ZWN0aW9uIG1lY2hhbmlzbSBidXQgaXQgY2Fubm90IGJl IGNvbnNpZGVyIGEgc29sdXRpb24gdGhhdCBhZGRyZXNzZXMgdGhlIHJlcXVpcmVtZW50cyBmb3Ig cHJvdGVjdGlvbiBvZiByaW5nIHRvcG9sb2dpZXMgZm9yIE11bHRpLVByb3RvY29sIExhYmVsIFN3 aXRjaGluZyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgYXMgc3BlY2lmaWVkIGluIFJGQzU2 NTQuDQoNCkJlc3QgcmVnYXJkcywNCkFsZXNzYW5kcm8NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUZWxlY29tIEl0 YWxpYQ0KQWxlc3NhbmRybyBHZXJhcmRvIEQnQWxlc3NhbmRybw0KVHJhbnNwb3J0IElubm92YXRp b24NClZpYSBSZWlzcyBSb21vbGksIDI3NCAtIDEwMTQ4IFRvcmlubw0KcGhvbmU6ICArMzkgMDEx IDIyOCA1ODg3DQptb2JpbGU6ICszOSAzMzUgNzY2IDk2MDcNCmZheDogKzM5IDA2IDQxOCA2Mzkg MDcNCg0KDQotLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KRGE6IG1wbHMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEhlamlh DQpJbnZpYXRvOiBzYWJhdG8gMjkgc2V0dGVtYnJlIDIwMTIgMTI6NTMNCkE6IExvYSBBbmRlcnNz b24NCkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgTVBMUy1U UCBhZCBob2MgdGVhbTsgZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbkB0b29scy5p ZXRmLm9yZw0KT2dnZXR0bzogUmU6IFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBk cmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uDQoNCkRvIG5vdCBzdXBwb3J0Lg0KDQpC YXNlZCBvbiB0aGUgYW5hbHlzaXMgaW4gU2VjdGlvbiAyLjQgb2YgZHJhZnQtaWV0Zi1tcGxzLXRw LXJpbmctcHJvdGVjdGlvbi0wMiwgdGhlIHJpbmcgcHJvdGVjdGlvbiBzY2hlbWUgdXNpbmcgU1BN RSBhcyBkZXNjcmliZWQsIGVpdGhlciB3cmFwcGluZyBvciBzdGVlcmluZywgZG9lcyBoYXZlIGRl ZmljaWVuY2llcywgd2hpY2ggSU1ITyBzaG91bGQgYmUgYmV0dGVyIHJlY29uc2lkZXJlZCBhbmQg c29sdmVkIGlmIHBvc3NpYmxlLg0KDQoNCkIuUi4NCkppYQ0KDQotLS0tLemCruS7tuWOn+S7ti0t LS0tDQrlj5Hku7bkuro6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ10g5Luj6KGoIExvYSBBbmRlcnNzb24NCuWPkemAgeaXtumXtDogMjAxMuW5tDnm nIgxOeaXpSAxODo0OQ0K5oqE6YCBOiBtcGxzQGlldGYub3JnOyBNUExTLVRQIGFkIGhvYyB0ZWFt OyBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnOyBtcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZw0K5Li76aKYOiBbbXBsc10gV29ya2luZyBncm91cCBsYXN0 IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg0KDQpXb3JraW5nIEdy b3VwLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNh bGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMi10eHQuDQoNClBsZWFz ZSBub3RlIHRoYXQgdGhlcmUgYXJlIHR3byBJUFIgZGlzY2xvc3VyZXMgIyAxNDYyIGFuZCAgIyAx ODcyIHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudC4NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50 cyB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdHMgKG1wbHNAaWV0Zi5vcmcp Lg0KDQpUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBPY3RvYmVyIDMsIDIwMTIuDQoN Ci9Mb2ENCmZvciB0aGUgbXBscyB3ZyBjby1jaGFpcnMNCg0KDQotLQ0KDQoNCkxvYSBBbmRlcnNz b24gICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24u Y29tDQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGku bnUNCkVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3 MTcgNTIgMTMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr NDYgNzY3IDcyIDkyIDEzIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQpRdWVzdG8gbWVzc2Fn Z2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxs ZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRy YSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9u aSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1 ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBk YXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUg YWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwg Y29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJl dHVybiBlLW1haWwsIFRoYW5rcy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From paul.doolan@nsn.com Tue Oct 2 14:37:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7EE21F85EF for ; Tue, 2 Oct 2012 14:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNIjp1jt3zOZ for ; Tue, 2 Oct 2012 14:37:12 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB2C21F858F for ; Tue, 2 Oct 2012 14:37:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q92Lb70D022310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 23:37:07 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q92Lb2LL028803; Tue, 2 Oct 2012 23:37:05 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Oct 2012 23:37:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA0E6.0D3BD07B" Date: Wed, 3 Oct 2012 05:36:58 +0800 Message-ID: <44A5364BC1FA1E42B1F133529EC2C72902C22E32@CNBEEXC007.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection Thread-Index: Ac2g5g0gFRiD4+CJRqa3JRnvvWmRGw== From: "Doolan, Paul (NSN - US/Irving)" To: X-OriginalArrivalTime: 02 Oct 2012 21:37:02.0493 (UTC) FILETIME=[0F66CCD0:01CDA0E6] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6049 X-purgate-ID: 151667::1349213827-00006F5F-5F8E104F/0-0/0-0 X-Mailman-Approved-At: Mon, 15 Oct 2012 12:00:35 -0700 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 21:37:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDA0E6.0D3BD07B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Alessandro, Nurit claimed that you (and others) did not "provide any indication nor technical justification which requirements are not addressed and why do you think they are not addressed....." 'Pointing out R100 of RFC5654' I guess counts as an 'indication' but certainly does not provide justification or indicate how the requirement is not addressed. So to be productive here you need to be more specific. Since you provide the example please indicate precisely how you think this proposed draft violates R100 of RFC5654 (inline below for those unfamiliar). Recovery techniques in a ring SHOULD be identical (or as similar as possible) to those in general transport networks to simplify implementation and operations. However, this MUST NOT override any other requirement. You might also want to look at RFC2119. best regards, pd Paul Doolan ------_=_NextPart_001_01CDA0E6.0D3BD07B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [mpls] R: Working group last call on = draft-ietf-mpls-tp-ring-protection

Hello = Alessandro,

Nurit = claimed that you (and others) did not “provide any indication nor technical justification which requirements = are = not addressed and why do you think they are not = addressed…..”

‘Pointing out R100 of RFC5654’ I guess counts as = an ‘indication’ but certainly does not provide justification or = indicate how the requirement is not addressed. So to = be productive here you  need to be more = specific.

Since you = provide the example please indicate precisely how you think = this proposed draft violates R100 of RFC5654 (inline below for those unfamiliar).

Recovery = techniques in a ring SHOULD be identical (or as = similar

as possible) to = those in general transport networks to simplify

implementation = and operations.  However, this MUST NOT override

 any other = requirement.

You might also = want to look at RFC2119.

best regards,

pd

Paul Doolan

------_=_NextPart_001_01CDA0E6.0D3BD07B-- From robert.h.venator.civ@mail.mil Mon Oct 15 11:41:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E940B21F8892 for ; Mon, 15 Oct 2012 11:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1lavvfz+KEu for ; Mon, 15 Oct 2012 11:41:59 -0700 (PDT) Received: from edge-mech.mail.mil (edge-mech.mail.mil [214.21.82.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1084721F8891 for ; Mon, 15 Oct 2012 11:41:58 -0700 (PDT) Received: from umechpja.easf.csd.disa.mil (214.21.83.154) by umechpik.easf.csd.disa.mil (214.21.82.10) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 15 Oct 2012 18:43:51 +0000 Received: from UMECHPHF.easf.csd.disa.mil ([169.254.9.212]) by UMECHPJA.easf.csd.disa.mil ([214.21.83.154]) with mapi id 14.02.0309.003; Mon, 15 Oct 2012 18:43:51 +0000 From: "Venator, Robert H III CIV (US)" To: "Rakesh Gandhi (rgandhi)" , Loa Andersson , "mpls@ietf.org" Thread-Topic: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp Thread-Index: AQHNqtCenjfwfTAC1UeLWLsxCO9a95e6TqvQgABji7A= Date: Mon, 15 Oct 2012 18:43:51 +0000 Message-ID: References: <507C0172.1030309@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [214.21.83.188] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0252_01CDAAE2.F3CCD2B0" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 15 Oct 2012 12:01:10 -0700 Cc: "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 18:44:09 -0000 ------=_NextPart_000_0252_01CDAAE2.F3CCD2B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Loa, I am not aware of any additional IPRs. Thanks, Robert Venator -----Original Message----- From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Monday, October 15, 2012 8:41 AM To: Loa Andersson; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org; Martin Vigoureux; Venator, Robert H III CIV (US); y.kamite@ntt.com Subject: RE: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp Hi Loa, Yes, IPR has been disclosed. http://datatracker.ietf.org/ipr/1861/ thanks, Rakesh -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Monday, October 15, 2012 8:29 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org; Martin Vigoureux Subject: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp Working Group and authors; The authors of draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp has indicated that the draft is ready to be adopted as a working group document. Before starting the poll to make the draft become a working group document we will do an IPR poll to check whether there is IPR on the document that needs to be disclosed. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ------=_NextPart_000_0252_01CDAAE2.F3CCD2B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISjTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEuDCCA6CgAwIBAgIDFnwZMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzAwHhcNMTIwNzIzMDAwMDAwWhcN MTUwNzIyMjM1OTU5WjB8MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTENMAsGA1UECxMERElTQTEoMCYGA1UEAxMfVkVOQVRP Ui5ST0JFUlQuSC5JSUkuMTAyNDg2NTM5NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKyXqrymWWUwcEy0l1PcYZ3S5mXDwEFVz5ZicVKffLVnkGF/i+yp+OqqXlSK9f427YRac+ePWOn0 i+3vBtzGz7Z6ml9iSMIfld4/zF2pE/XYxRmS+YygJtibC7OT2tj55meYBH8qQOVGdrdUiYtam8tw mnPpmjv++6s3pa84RnQss0211ece6bcnil+m3WzeG75cWB/P1GUJCAJLpWvtBB0/F3nOPfEuLKER UhwDrrVXhTgmAY9OrpTHWKL04FrRe/OVM6WK495uxNpQJa3LtuYlQ4w2NLI6adfu53Gm20oN6afT zhaEkNn+bTcwsD2rU1gOORhnJBvCC7h81DN+XpECAwEAAaOCAWAwggFcMB8GA1UdIwQYMBaAFDVh ZigJvFYlW4vMv4FeYSwwOdMhMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwv Y3JsL0RPREVNQUlMQ0FfMzAuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFl AgELCTALBglghkgBZQIBCxMwHQYDVR0OBBYEFACpUwcDIOVumon8Wy9XYFg698ftMGgGCCsGAQUF BwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0Ff MzAuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAiBgNVHREEGzAZgRdyb2Jl cnQudmVuYXRvckBkaXNhLm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMA0GCSqGSIb3 DQEBBQUAA4IBAQAM2epFktEq3UYmbzsAD/qKK4v1QtY0bXfCIYE0cFv5YuOFbF0RBnN0BPRp34Es rksDYYWpZuE2UmNb7aS6SnkB07VU2qpMs1/1zijN1fpXWoTmXvFvPth073MUoP7Sdm+bgMaHGCBj DCAsamVV7f/CsOJUv57Osx7Yxgs/S95giqUG9bKpKt+PWgAQ72hdTGMTSOBNIPZ+5cNH9jx1f8E6 92wdfnIUkDJosfdWCPlyJhbSmWea1W+NcSLvVhiPvL18oYYWZzOgVXUfJQNJyNyaGwjFp1aidDMS SFBk8B0Ka8aJhBAMto5zMAoMFIw8azkl94xbOqK5C3USbyTp2fcoMIIFAzCCA+ugAwIBAgIDFnwT MA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQx DDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzAwHhcN MTIwNzIzMDAwMDAwWhcNMTUwNzIyMjM1OTU5WjB8MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5T LiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTENMAsGA1UECxMERElTQTEo MCYGA1UEAxMfVkVOQVRPUi5ST0JFUlQuSC5JSUkuMTAyNDg2NTM5NDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMzZdVGUWCd1rGsFgQ4X38dR1Qis6jkjFBlrkdogFEWPDa/gb5bTypv7 q9WLzFvDid97GBX9iegS/RhVPNMopGbKjLRGn/dY0nyJ36nM+7rQoX4KnNrd0uWmseinPiDoG97j Gs1Olvue6nMjjnmO14s9BxPYONGwxoypne+Gpckgh3GVD52EyJt9Jhu79r88LmJzB1Bzj8kTq7PF mF11RDhhLC1VO5sRE60QlytiEp6DtlQ2Jy1XXSudhPs5bm2Hb4nsbXPAQAYQ9cgwFeU4KElIUyui gIN8kWuehpq4b2va6G2f6WXC5TiVwlew9Ihlyp+JgDcPSTljEjwpoUfyDmsCAwEAAaOCAaswggGn MB8GA1UdIwQYMBaAFDVhZigJvFYlW4vMv4FeYSwwOdMhMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6 Ly9jcmwuZGlzYS5taWwvY3JsL0RPREVNQUlMQ0FfMzAuY3JsMA4GA1UdDwEB/wQEAwIGwDAjBgNV HSAEHDAaMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxMwHQYDVR0OBBYEFNW7AmZscjEkeh4inp2A w9iBJP5XMGgGCCsGAQUFBwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9z aWduL0RPREVNQUlMQ0FfMzAuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDBC BgNVHREEOzA5gRdyb2JlcnQudmVuYXRvckBkaXNhLm1pbKAeBgorBgEEAYI3FAIDoBAMDjEwMjQ4 NjUzOTRAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwKQYDVR0lBCIwIAYKKwYBBAGC NxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQBf9LesMnEO72H7p9wH ms+vjj2bREMjw6UVEf1L4BXLpors/fZfN+Ypc6cPPo3G5wpgusJQc3dLuLj4mJajmvF23BgvVJVc nc41A2skKszp6ip8L0sYmMkxFVXB1JCsGo/0Ln7AG6uvZFKP9GZPxGsPgAjAhGyn+V186+7G7XI2 +s9Dzwd5On8rIqbyW8W83U2hz8AX5BVBDgoqorl9A4rESy0s66i8DPrOVA1sIjUtsFK+DYY3kgbm tuMOjiiSu3vOqNkhM+g66qZVNhc9TSoJYVIs84hRETtfZAhnd26O9p7Y4O7OJ2/s9q8aHweN8Fbj PxjZBt91cwjeHlriplFeMIIFUjCCBDqgAwIBAgICAbkwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDURvRCBSb290IENBIDIwHhcNMTEwOTA4MTYwMzA4WhcNMTcwOTA4MTYwMzA4 WjBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0Qx DDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMwMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA5iki1BQm0ZgaUl7FhINzfsFgs7PQlL79HJRVv/aELJvJwHRz78zCmfKZ yW3KFNN0/74Q8vctv8u7BqPumFBBZQHhVyy2y+TKHKx+UjQOsY4HJj4yNa+jYQrF5Qi2EnmMVMF6 6fFQH12DOmcwsynbHTpMOSFQ2BgsjQZ17mNyeGitYpx1pJQG0zJrEq8GBym+E6DAp/AlT7f+H7dX 4BgSjSFqFblaVPt3ZdhMP/W6PMA34QZ+wr6eI4wo0ZrXxmc413PJvQcdhW/VlQqa3No6TijwpesJ 3+XbC81Hr4rNu2+UQONZnFCfyQ6pcQK53OlpgDqJO0UFIhgFhLUS8DzAgQIDAQABo4ICHDCCAhgw DgYDVR0PAQH/BAQDAgGGMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DGlcYJgHCWMB0GA1UdDgQW BBQ1YWYoCbxWJVuLzL+BXmEsMDnTITASBgNVHRMBAf8ECDAGAQH/AgEAMAwGA1UdJAQFMAOAAQAw ZgYDVR0gBF8wXTALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELETALBglghkgB ZQIBCxIwCwYJYIZIAWUCAQsTMAwGCmCGSAFlAwIBAxowDAYKYIZIAWUDAgEDGzA3BgNVHR8EMDAu MCygKqAohiZodHRwOi8vY3JsLmRpc2EubWlsL2NybC9ET0RST09UQ0EyLmNybDCCAQEGCCsGAQUF BwEBBIH0MIHxMDoGCCsGAQUFBzAChi5odHRwOi8vY3JsLmRpc2EubWlsL2lzc3VlZHRvL0RPRFJP T1RDQTJfSVQucDdjMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDCBkAYIKwYBBQUH MAKGgYNsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNv dSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2Nyb3Nz Q2VydGlmaWNhdGVQYWlyO2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEACohWHKVXJlpiy3XQ3YbF UuIv87wRZD+MLz4R/JhgQPKADSiCmmj+4EhLJ9M6CnuV9gMMgRSRQjpgbOIrUy3s3xGu9VQX8AH5 lwenm6sL26yXiQnG7/kHNBYAqH4RU558L6E4opl5OTRBbn24WDBWiJ7kqmRF2aBEYjq35THTkYDx GxCyZ3DVW6tZtFpIFkLEAkzabGjKUB0xvjeZx89TzEIpVsOdF8oD5xBa8Tk8HMz7G5cKJvMx3+Cr XCSdnt44fQJRZ0b5k3CF7QpVwvTBaFqfCMkde5t23FTvOYwY5QxE7vcGsh/1y+YOvdSh/9T5kQci Unm3wP3ssviF9ET7XDGCA0EwggM9AgEBMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0zMAIDFnwTMAkGBSsOAwIaBQCgggGyMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAxNTE4Mzk1OVowIwYJKoZIhvcNAQkEMRYEFCIqkPx2bZCiNXork5Hh dWIXaIpXMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHMG CSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0zMAIDFnwZ MHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5t ZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMw AgMWfBkwDQYJKoZIhvcNAQEBBQAEggEAG/yFXJAGWRE2yAS+GT+lSpGOGlJiBcpg7hN6XrlZYPTU RQremYM4hbnFdLDLIcUBSJzntJ/O57Qa/rNQbN3r8wLesJVn2omyRpyz/FpO9tQwumDzDn7cK6KX s4+6Zm63+5NMwOMIvgdi1tGpBhUr3RItftTFn5B2jT2otszD5+z/54/+N3iBu/JZc1jqLbXvtgoX SSHG6GBsGj86vzc0eDXZOtPCXpngoIJ7tyjZUXQdIMXRWnF2n92M9+DCEREgcyD6L5uScUCysHdA 0g8/haQxGeh2olZPCjcfQtRoX28Ys23xmbrF+7Tylc6Eo1sjLSGNkGjPuHIBN+qO74tX+wAAAAAA AA== ------=_NextPart_000_0252_01CDAAE2.F3CCD2B0-- From dave.mcdysan@verizon.com Mon Oct 15 13:03:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BB821F870A; Mon, 15 Oct 2012 13:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBkRo2h8fmi0; Mon, 15 Oct 2012 13:03:38 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3B321F84B8; Mon, 15 Oct 2012 13:03:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe03.verizon.com with ESMTP; 15 Oct 2012 20:03:26 +0000 From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.80,590,1344211200"; d="scan'208";a="350664171" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 15 Oct 2012 20:03:26 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([166.68.59.148]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Mon, 15 Oct 2012 16:03:26 -0400 To: Mpls , "ccamp@ietf.org" Date: Mon, 15 Oct 2012 16:03:19 -0400 Thread-Topic: New Version Notification for draft-fuxh-mpls-delay-loss-te-problem-statement-01.txt Thread-Index: Ac2rECJnceNkDFGRRoCdd9B9z6BUfA== Message-ID: In-Reply-To: <20121015192723.11031.60174.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] FW: New Version Notification for draft-fuxh-mpls-delay-loss-te-problem-statement-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 20:03:39 -0000 Version with some updated text in sections 1-3. Dave On 10/15/12 3:27 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, >draft-fuxh-mpls-delay-loss-te-problem-statement-01.txt >has been successfully submitted by Dave McDysan and posted to the >IETF repository. > >Filename: draft-fuxh-mpls-delay-loss-te-problem-statement >Revision: 01 >Title: Delay and Loss Traffic Engineering Problem Statement for MPLS >Creation date: 2012-10-15 >WG ID: Individual Submission >Number of pages: 14 >URL: =20 >http://www.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te-problem- >statement-01.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-fuxh-mpls-delay-loss-te-problem-stat >ement >Htmlized: =20 >http://tools.ietf.org/html/draft-fuxh-mpls-delay-loss-te-problem-statement >-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-fuxh-mpls-delay-loss-te-problem-s= ta >tement-01 > >Abstract: > Deployment and usage of cloud based applications and services that use > an underlying MPLS network are expanding and an increasing number of > applications are extremely sensitive to delay and packet loss. > Furthermore, in cloud computing an additional decision problem arises >of > simultaneously choosing the data center to host applications along with > MPLS network connectivity such that the overall performance of the > application is met. Mechanisms exist to measure and monitor MPLS path > performance parameters for packet loss and delay, but the mechanisms > work only after the path has been setup. The cloud-based and >performance > sensitive applications would benefit from measurement of MPLS network > and potential path information that would be provided for use in the > computation before LSP setup and then the selection of LSPs. > > This document provides a statement of problems faced by these cloud > based and performance sensitive applications and describes requirements > to enable the efficient and accurate measurement of the MPLS network. > This also allows new performance parameters to be reported and used in > the computation of MPLS services in support of these cloud based and > performance sensitive applications. > > =20 > =20 >Replacement for -00 version to include additional/revised material. > >The IETF Secretariat > From zheng.zhi@zte.com.cn Tue Oct 16 04:56:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE9321F88A5 for ; Tue, 16 Oct 2012 04:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.66 X-Spam-Level: X-Spam-Status: No, score=-101.66 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74eDOip6imk3 for ; Tue, 16 Oct 2012 04:56:36 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D797F21F88A0 for ; Tue, 16 Oct 2012 04:56:35 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 781A91282016 for ; Tue, 16 Oct 2012 19:57:20 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id AD2CE717DAB for ; Tue, 16 Oct 2012 19:53:31 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id q9GBuWLf057618 for ; Tue, 16 Oct 2012 19:56:32 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) Message-Id: <201210161156.q9GBuWLf057618@mse01.zte.com.cn> Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q9GBmdwB049314; Tue, 16 Oct 2012 19:48:39 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) In-Reply-To: <507BEC44.5030102@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: Ryan Zheng Date: Tue, 16 Oct 2012 19:48:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-16 19:48:25, Serialize complete at 2012-10-16 19:48:25 Content-Type: multipart/alternative; boundary="=_alternative 00410A5A48257A99_=" X-MAIL: mse01.zte.com.cn q9GBuWLf057618 X-MSS: AUDITRELEASE@mse01.zte.com.cn Cc: "mpls@ietf.org" , draft-zjns-mpls-lsp-ping-relay-reply@tools.ietf.org, lizhong.jin@zte.com.cn, "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-zjns-mpls-lsp-ping-relay-reply X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 11:56:37 -0000 This is a multipart message in MIME format. --=_alternative 00410A5A48257A99_= Content-Type: text/plain; charset="US-ASCII" Hi Loa, I am not aware of any IPR related to this draft. Thanks, Ryan Loa Andersson wrote on 2012-10-15 18:58:12: > Working Group and authors; > > The authors of draft-zjns-mpls-lsp-ping-relay-reply has indicated > that the draft is ready to be adopted as a working group document. > > Before starting the poll to make the draft become a working group > document we will do an IPR poll to check whether there is IPR on > the document that needs to be disclosed. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-zjns-mpls-lsp-ping-relay-reply? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. The response needs to be sent to the MPLS wg mailing list. The > documents will not advance to the next stage until a response > has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > Thanks, Loa > (as MPLS WG co-chair) > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 --=_alternative 00410A5A48257A99_= Content-Type: text/html; charset="US-ASCII"
Hi Loa,

I am not aware of any IPR related to this draft.

Thanks,
Ryan

Loa Andersson <loa@pi.nu> wrote on 2012-10-15 18:58:12:

> Working Group and authors;
>
> The authors of draft-zjns-mpls-lsp-ping-relay-reply has indicated
> that the draft is ready to be adopted as a working group document.
>
> Before starting the poll to make the draft become a working group
> document we will do an IPR poll to check whether there is IPR on
> the document that needs to be disclosed.
>
> This mail starts that IPR poll.
>
> Are you aware of any IPR that applies to
> draft-zjns-mpls-lsp-ping-relay-reply?
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as a document author or contributor please respond to
> this email regardless of whether or not you are aware of any relevant
> IPR. The response needs to be sent to the MPLS wg mailing list. The
> documents will not advance to the next stage until a response
> has been received from each author and contributor.
>
> If you are on the MPLS WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of any
> IPR that has not yet been disclosed in conformance with IETF rules.
>
>
> Thanks, Loa
> (as MPLS WG co-chair)
>
> --
>
>
> Loa Andersson                         email: loa.andersson@ericsson.com
> Sr Strategy and Standards Manager            loa@pi.nu
> Ericsson Inc                          phone: +46 10 717 52 13
>                                               +46 767 72 92 13
 --=_alternative 00410A5A48257A99_=-- From lizho.jin@gmail.com Tue Oct 16 09:31:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B9521F882C for ; Tue, 16 Oct 2012 09:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSZYskFaM1Wq for ; Tue, 16 Oct 2012 09:31:45 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71A5821F8829 for ; Tue, 16 Oct 2012 09:31:45 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so5445656iad.31 for ; Tue, 16 Oct 2012 09:31: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 :cc:content-type; bh=qQzyO9suZLGjUuqe/WjsGICkkzGRf/QeTa0gsllEU2U=; b=oCT+aBESKaoIWguzmU+vlrJ/H+FJEGpEb8yvHYoqblZrVQMXKb60QJhh/43w8j2glp UCess81PdqOUvavn8z2iHuqyczWs0CeAIyRqIjeASz0CaMhz4K19XUzaOL3b2Gy+C7a1 jxFZ1XoNMmErZ0pZgBsxIAm7ROhE4CDi4opzcdkg2GgX9rRmzh7/2jc0NPTsTu0AmN8H 62NPigJD5jR39YEPt+CJCNzrLXo5ru7V6m9eFXHaDIdnRBwaB36Jg5YdzmCm/XpVuMks z5RiO+eA4rlvSNkg6Tc+my0QvGt/zkq3aiTp7s2XzmQUj8g8mQQqkqGzccdZ0NUQXf/2 Vv0A== MIME-Version: 1.0 Received: by 10.43.13.195 with SMTP id pn3mr12102900icb.47.1350405104493; Tue, 16 Oct 2012 09:31:44 -0700 (PDT) Received: by 10.50.157.166 with HTTP; Tue, 16 Oct 2012 09:31:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Oct 2012 00:31:44 +0800 Message-ID: From: Lizhong Jin To: Loa Andersson Content-Type: multipart/alternative; boundary=bcaec5186d688e651104cc2fb078 Cc: mpls@ietf.org Subject: Re: [mpls] mpls Digest, Vol 102, Issue 29 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 16:31:46 -0000 --bcaec5186d688e651104cc2fb078 Content-Type: text/plain; charset=ISO-8859-1 Hi Loa, I am not aware of any IPR to this draft. Lizhong > ------------------------------ > > Message: 4 > Date: Mon, 15 Oct 2012 12:58:12 +0200 > From: Loa Andersson > To: "mpls@ietf.org" > Cc: "mpls-chairs@tools.ietf.org" , > draft-zjns-mpls-lsp-ping-relay-reply@tools.ietf.org > Subject: [mpls] IPR poll on draft-zjns-mpls-lsp-ping-relay-reply > Message-ID: <507BEC44.5030102@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Working Group and authors; > > The authors of draft-zjns-mpls-lsp-ping-relay-reply has indicated > that the draft is ready to be adopted as a working group document. > > Before starting the poll to make the draft become a working group > document we will do an IPR poll to check whether there is IPR on > the document that needs to be disclosed. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-zjns-mpls-lsp-ping-relay-reply? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. The response needs to be sent to the MPLS wg mailing list. The > documents will not advance to the next stage until a response > has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > Thanks, Loa > (as MPLS WG co-chair) > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > > > ------------------------------ > > --bcaec5186d688e651104cc2fb078 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Loa,
I am not aware of any IPR= to this draft.

Lizhong
=A0
------------------------------

Message: 4
Date: Mon, 15 Oct 2012 12:58:12 +0200
From: Loa Andersson <loa@pi.nu>
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "mpls-chairs@tools.i= etf.org" <mpls-ch= airs@tools.ietf.org>,
=A0 =A0 =A0 =A0 draft-zjns-mpls-lsp-ping-relay-reply@tools.ietf.org
Subject: [mpls] IPR poll on draft-zjns-mpls-lsp-ping-relay-reply
Message-ID: <507BEC44.5030102@= pi.nu>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

Working Group and authors;

The authors of draft-zjns-mpls-lsp-ping-relay-reply has indicated
that the draft is ready to be adopted as a working group document.

Before starting the poll to make the draft become a working group
document we will do an IPR poll to check whether there is IPR on
the document that needs to be disclosed.

This mail starts that IPR poll.

Are you aware of any IPR that applies to
draft-zjns-mpls-lsp-ping-relay-reply?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. The response needs to be sent to the MPLS wg mailing list. The
documents will not advance to the next stage until a response
has been received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.


Thanks, Loa
(as MPLS WG co-chair)

--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 10 717 52= 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 +46 767 72 92 13


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

--bcaec5186d688e651104cc2fb078-- From lizho.jin@gmail.com Tue Oct 16 09:33:33 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EDB21F8682 for ; Tue, 16 Oct 2012 09:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q30g-6P6o0sX for ; Tue, 16 Oct 2012 09:33:33 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2136521F861A for ; Tue, 16 Oct 2012 09:33:33 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so11667926iec.31 for ; Tue, 16 Oct 2012 09:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=kWKvL5FrGxAtmln/0FLUcUk9KzJ7G6aqiHFfrse489k=; b=VQALLalHWXa30VAQM6H/Ef3GtOJqIN4I0EWxv1ijWII/EEcSHvTTGQyY3YEypW9wth fKMGcmqVOogqrHTmy4Mtk3CcyftqZArCJR2DaCVRouJwhg7DY0NXU0FOfV2zv1uziTuG mWkkFYfkBOYcxuqdCZ62NNLMryxLbGwbU8Gz0ccLyCTaiA5DEyQy3pFrmjE/vK9ombzA rv4bVMzGixaJxkcPAA9DoSQ2NAhh1uOoUo7vPjWekmThJPiPxoLm4/LRFFw3e2nhBHoM 7M0zZ580eNGIk9sBP9rgnoi20vUMfRCtDI9fVwv+GCWUPgXCbqGdkb71Kotebq7JLony GhWw== MIME-Version: 1.0 Received: by 10.50.150.176 with SMTP id uj16mr12654118igb.38.1350405212748; Tue, 16 Oct 2012 09:33:32 -0700 (PDT) Received: by 10.50.157.166 with HTTP; Tue, 16 Oct 2012 09:33:32 -0700 (PDT) Date: Wed, 17 Oct 2012 00:33:32 +0800 Message-ID: From: Lizhong Jin To: Loa Andersson Content-Type: multipart/alternative; boundary=f46d04339d1a023d2304cc2fb777 Cc: mpls@ietf.org Subject: Re: [mpls] IPR poll on draft-zjns-mpls-lsp-ping-relay-reply X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 16:33:34 -0000 --f46d04339d1a023d2304cc2fb777 Content-Type: text/plain; charset=ISO-8859-1 Send again with correct subject. On Wed, Oct 17, 2012 at 12:31 AM, Lizhong Jin wrote: > Hi Loa, > I am not aware of any IPR to this draft. > > Lizhong > > >> ------------------------------ >> >> Message: 4 >> Date: Mon, 15 Oct 2012 12:58:12 +0200 >> From: Loa Andersson >> To: "mpls@ietf.org" >> Cc: "mpls-chairs@tools.ietf.org" , >> draft-zjns-mpls-lsp-ping-relay-reply@tools.ietf.org >> Subject: [mpls] IPR poll on draft-zjns-mpls-lsp-ping-relay-reply >> Message-ID: <507BEC44.5030102@pi.nu> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Working Group and authors; >> >> The authors of draft-zjns-mpls-lsp-ping-relay-reply has indicated >> that the draft is ready to be adopted as a working group document. >> >> Before starting the poll to make the draft become a working group >> document we will do an IPR poll to check whether there is IPR on >> the document that needs to be disclosed. >> >> This mail starts that IPR poll. >> >> Are you aware of any IPR that applies to >> draft-zjns-mpls-lsp-ping-relay-reply? >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. The response needs to be sent to the MPLS wg mailing list. The >> documents will not advance to the next stage until a response >> has been received from each author and contributor. >> >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of any >> IPR that has not yet been disclosed in conformance with IETF rules. >> >> >> Thanks, Loa >> (as MPLS WG co-chair) >> >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> >> >> ------------------------------ >> >> --f46d04339d1a023d2304cc2fb777 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Send again with correct subject.


On = Wed, Oct 17, 2012 at 12:31 AM, Lizhong Jin <lizho.jin@gmail.com><= /span> wrote:
Hi Loa,
I am not aware of any IPR to this draft.
=

Lizhong
=A0
------------------------------

Message: 4
Date: Mon, 15 Oct 2012 12:58:12 +0200
From: Loa Andersson <loa@= pi.nu>
To: "mpls@ietf.org<= /a>" <mpls@ietf.= org>
Cc: "m= pls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>,
=A0 =A0 =A0 =A0 draft-zjns-mpls-lsp-ping-relay-reply@tools.ie= tf.org
Subject: [mpls] IPR poll on draft-zjns-mpls-lsp-ping-relay-reply
Message-ID: <507BEC44.5030102@pi.nu>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

Working Group and authors;

The authors of draft-zjns-mpls-lsp-ping-relay-reply has indicated
that the draft is ready to be adopted as a working group document.

Before starting the poll to make the draft become a working group
document we will do an IPR poll to check whether there is IPR on
the document that needs to be disclosed.

This mail starts that IPR poll.

Are you aware of any IPR that applies to
draft-zjns-mpls-lsp-ping-relay-reply?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. The response needs to be sent to the MPLS wg mailing list. The
documents will not advance to the next stage until a response
has been received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.


Thanks, Loa
(as MPLS WG co-chair)

--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 +46 767 72 92 13


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


--f46d04339d1a023d2304cc2fb777-- From hffellow@hotmail.com Tue Oct 16 19:12:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA24411E80A6 for ; Tue, 16 Oct 2012 19:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.177 X-Spam-Level: X-Spam-Status: No, score=0.177 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5s-JMderzoM4 for ; Tue, 16 Oct 2012 19:12:01 -0700 (PDT) Received: from snt0-omc3-s11.snt0.hotmail.com (snt0-omc3-s11.snt0.hotmail.com [65.55.90.150]) by ietfa.amsl.com (Postfix) with ESMTP id 542A311E8097 for ; Tue, 16 Oct 2012 19:12:01 -0700 (PDT) Received: from SNT110-W7 ([65.55.90.137]) by snt0-omc3-s11.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Oct 2012 19:12:00 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_6754da75-7478-47ed-85b2-c11a1fabe532_" X-Originating-IP: [27.115.50.36] From: Elton huang To: paul doolan , "alessandro.dalessandro@telecomitalia.it" Date: Wed, 17 Oct 2012 02:11:59 +0000 Importance: Normal In-Reply-To: <44A5364BC1FA1E42B1F133529EC2C72902C22E32@CNBEEXC007.nsn-intra.net> References: <44A5364BC1FA1E42B1F133529EC2C72902C22E32@CNBEEXC007.nsn-intra.net> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Oct 2012 02:12:00.0347 (UTC) FILETIME=[CAAC0AB0:01CDAC0C] Cc: "mpls@ietf.org" , mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 02:12:02 -0000 --_6754da75-7478-47ed-85b2-c11a1fabe532_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Dear Paul, A lot of requirements indicated in ITU-T lianson, and inputs form TI and CMCC are not satisfied in this drafts, could you read past emails carefully? That's why the draft is not supported. B.R. hffellow Date: Wed, 3 Oct 2012 05:36:58 +0800 From: paul.doolan@nsn.com To: alessandro.dalessandro@telecomitalia.it CC: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection Hello Alessandro, Nurit claimed that you (and others) did not ¡°provide any indication nor technical justification which requirements are not addressed and why do you think they are not addressed¡­..¡± ¡®Pointing out R100 of RFC5654¡¯ I guess counts as an ¡®indication¡¯ but certainly does not provide justification or indicate how the requirement is not addressed. So to be productive here you need to be more specific. Since you provide the example please indicate precisely how you think this proposed draft violates R100 of RFC5654 (inline below for those unfamiliar). Recovery techniques in a ring SHOULD be identical (or as similar as possible) to those in general transport networks to simplify implementation and operations. However, this MUST NOT override any other requirement. You might also want to look at RFC2119. best regards, pd Paul Doolan _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_6754da75-7478-47ed-85b2-c11a1fabe532_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Dear Paul,
     A lot of requirements indicated in ITU-T lianson, and inputs form TI and CMCC are not satisfied in this drafts, could you read past emails carefully? That's why the draft is not supported.
B.R.
hffellow

 
Date: Wed, 3 Oct 2012 05:36:58 +0800
From: paul.doolan@nsn.com
To: alessandro.dalessandro@telecomitalia.it
CC: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring-protection@tools.ietf.org
Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection

Hello Alessandro,

Nurit claimed that you (and others) did not ¡°provide any indication nor technical justification which requirements are not addressed and why do you think they are not addressed¡­..¡±

¡®Pointing out R100 of RFC5654¡¯ I guess counts as an ¡®indication¡¯ but certainly does not provide justification or indicate how the requirement is not addressed. So to be productive here you  need to be mor e specific.

Since you provide the example please indicate precisely how you think this proposed draft violates R100 of RFC5654 (inline below for those unfamiliar).

Recovery techniques in a ring SHOULD be identical (or as similar

as possible) to those in general transport networks to simplify

implementation and operations.  However, this MUST NOT override

 any other requirement.

You might also want to look at RFC2119.

best regards,

pd

Paul Doolan


_______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls
--_6754da75-7478-47ed-85b2-c11a1fabe532_-- From hffellow@hotmail.com Tue Oct 16 19:13:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61A521F84D8 for ; Tue, 16 Oct 2012 19:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8iMyxXCCz3m for ; Tue, 16 Oct 2012 19:13:34 -0700 (PDT) Received: from snt0-omc2-s9.snt0.hotmail.com (snt0-omc2-s9.snt0.hotmail.com [65.55.90.84]) by ietfa.amsl.com (Postfix) with ESMTP id B192B21F84D2 for ; Tue, 16 Oct 2012 19:13:34 -0700 (PDT) Received: from SNT110-W56 ([65.55.90.73]) by snt0-omc2-s9.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Oct 2012 19:13:33 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_137f5991-f383-4334-80b5-35ce794dbb85_" X-Originating-IP: [27.115.50.36] From: Elton huang To: , "alessandro.dalessandro@telecomitalia.it" , Date: Wed, 17 Oct 2012 02:13:33 +0000 Importance: Normal In-Reply-To: <51508CA9C4AE774DAC3FC6B8F0E5A5384691AB0F4E@GRFMBX707BA020.griffon.local> References: <5059A308.3050307@pi.nu>, <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com>, , <51508CA9C4AE774DAC3FC6B8F0E5A5384691AB0F4E@GRFMBX707BA020.griffon.local> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Oct 2012 02:13:33.0273 (UTC) FILETIME=[020F6C90:01CDAC0D] Cc: "mpls@ietf.org" , mpls-chairs@tools.ietf.org, ahmpls-tp@lists.itu.int, draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] R: R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 02:13:35 -0000 --_137f5991-f383-4334-80b5-35ce794dbb85_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit +1 > From: andrea.allasia@telecomitalia.it > To: alessandro.dalessandro@telecomitalia.it; loa@pi.nu > Date: Mon, 1 Oct 2012 17:14:32 +0200 > CC: mpls@ietf.org; mpls-chairs@tools.ietf.org; ahmpls-tp@lists.itu.int; draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Subject: [mpls] R: R: Working group last call on draft-ietf-mpls-tp-ring-protection > > +1 > > -----Messaggio originale----- > Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di D'Alessandro Alessandro Gerardo > Inviato: luned¨¬ 1 ottobre 2012 14:27 > A: Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Oggetto: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection > > Do not support > > According to the optimization criteria for ring protection specified in Section 2.5.6.1 in RFC5654, the MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption around the ring. It is not the case of the proposed solution. > It is actually simply an applicability statement of a linear protection mechanism but it cannot be consider a solution that addresses the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) as specified in RFC5654. > > Best regards, > Alessandro > > ------------------------------------------------------------------ > Telecom Italia > Alessandro Gerardo D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 > > > -----Messaggio originale----- > Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Hejia > Inviato: sabato 29 settembre 2012 12:53 > A: Loa Andersson > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Do not support. > > Based on the analysis in Section 2.4 of draft-ietf-mpls-tp-ring-protection-02, the ring protection scheme using SPME as described, either wrapping or steering, does have deficiencies, which IMHO should be better reconsidered and solved if possible. > > > B.R. > Jia > > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] ´ú±í Loa Andersson > ·¢ËÍʱ¼ä: 2012Äê9ÔÂ19ÈÕ 18:49 > ³­ËÍ: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.ietf.org > Ö÷Ìâ: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection > > Working Group, > > this is to start a two week working group last call on draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 related to this document. > > Please send your comments to the mpls working group mailing lists (mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --_137f5991-f383-4334-80b5-35ce794dbb85_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
+1
 
> From: andrea.allasia@telecomitalia.it
> To: alessandro.dalessandro@telecomitalia.it; loa@pi.nu
> Date: Mon, 1 Oct 2012 17:14:32 +0200
> CC: mpls@ietf.org; mpls-chairs@tools.ietf.org; ahmpls-tp@lists.itu.int; draft-ietf-mpls-tp-ring-protection@tools.ietf.org
> Subject: [mpls] R: R: Working group last call on draft-ietf-mpls-tp-ring-protection
>
> +1
>
> -----Messaggio originale-----
> Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di D'Alessandro Alessandro Gerardo
> Inviato: luned¨¬ 1 ottobre 2012 14:27
> A: Loa Andersson
> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org
> Oggetto: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection
>
> Do not support
>
> According to the optimization criteria for ring protection specified in Section 2.5.6.1 in RFC5654, the MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption around the ring. It is not the case of the proposed solution.
> It is actually simply an applicability statement of a linear protection mechanism but it cannot be consider a solution that addresses the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) as specified in RFC5654.
>
> Best regards,
> Alessandro
>
> ------------------------------------------------------------------
> Telecom Italia
> Alessandro Gerardo D'Alessandro
> Transport Innovation
> Via Reiss Romoli, 274 - 10148 Torino
> phone: +39 011 228 5887
> mobile: +39 335 766 9607
> fax: +39 06 418 639 07
>
>
> -----Messaggio originale-----
> Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Hejia
> Inviato: sabato 29 settembre 2012 12:53
> A: Loa Andersson
> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org
> Oggetto: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection
>
> Do not support.
>
> Based on the analysis in Section 2.4 of draft-ietf-mpls-tp-ring-protection-02, the ring protection scheme using SPME as described, either wrapping or steering, does have deficiencies, which IMHO should be better reconsidered and solved if possible.
>
>
> B.R.
> Jia
>
> -----ÓʼþÔ­¼þ-----
> ·¢¼þÈË: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] ´ú±í Loa Andersson
> ·¢ËÍʱ¼ä: 2012Äê9ÔÂ19ÈÕ 18:49
> ³­ËÍ: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.ietf.org
> Ö÷Ìâ: [mpls] Working group last call on draft-ietf- mpls-tp-ring-protection
>
> Working Group,
>
> this is to start a two week working group last call on draft-ietf-mpls-tp-ring-protection-02-txt.
>
> Please note that there are two IPR disclosures # 1462 and # 1872 related to this document.
>
> Please send your comments to the mpls working group mailing lists (mpls@ietf.org).
>
> The working group last call ends October 3, 2012.
>
> /Loa
> for the mpls wg co-chairs
>
>
> --
>
>
> Loa Andersson email: loa.andersson@ericsson.com
> Sr Strategy and Standards Manager loa@pi.nu
> Ericsson Inc phone: +46 10 717 52 13
> +46 767 72 92 13 _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> htt ps://www.ietf.org/mailman/listinfo/mpls
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> ____________________________ ___________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
--_137f5991-f383-4334-80b5-35ce794dbb85_-- From wyaacov@gmail.com Tue Oct 16 23:42:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD9221F87AF for ; Tue, 16 Oct 2012 23:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7bf1L5F5HP3 for ; Tue, 16 Oct 2012 23:42:28 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E5A4F21F8735 for ; Tue, 16 Oct 2012 23:42:27 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so7753915vbb.31 for ; Tue, 16 Oct 2012 23:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uvy0LDf0n0iu42AX04+QzOc6XHv9PteG0Vj9UHYfIAM=; b=0a4qN1Sx2QiOup7Z6uEAngcuzr+8mogJSsLaaPjGjiIcFo04+uD5YrRkk0m3PCmexl SY4kFqD2bZ+gb0HzOYPjf7m6YWZkffQkFN0LYZCFaRjeugM+hn++1eqRI2qf+WbZeuoi JLZL8Ke7WLpZw3gmsdWa7MSBsceXFEpNKgg9getfA6pOMT9cXAvokwbh7v3pk8H+vsA+ cV6i1GE+uWTD3Ly6QEnTPp3y+uDDpRLzzuWChldAFuu5Iasi9yLpcUviJo8XFq3EVgEK knOpk1gh/d7mbXYzql5KlqdpDYNZf3oJ8XlGQraUg4l6KgsPOCgz1U8tyrklsSWhyCL4 uQaA== MIME-Version: 1.0 Received: by 10.52.155.199 with SMTP id vy7mr7906116vdb.54.1350456147224; Tue, 16 Oct 2012 23:42:27 -0700 (PDT) Received: by 10.58.254.194 with HTTP; Tue, 16 Oct 2012 23:42:26 -0700 (PDT) In-Reply-To: References: <44A5364BC1FA1E42B1F133529EC2C72902C22E32@CNBEEXC007.nsn-intra.net> Date: Wed, 17 Oct 2012 08:42:26 +0200 Message-ID: From: Yaacov Weingarten To: Elton huang Content-Type: multipart/alternative; boundary=bcaec53aef50f0a84804cc3b9210 Cc: "mpls@ietf.org" , mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: Re: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 06:42:29 -0000 --bcaec53aef50f0a84804cc3b9210 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, After careful reading of the LS received from the ITU-T, I did not see "a lot of requirements" - there were exactly three, two of which were new requirements, apparently put together in order to fit a particular solution, that define a new concept in ring protection - "shared ring protection switching". Aside from that the LS presents a "problem" with the draft for multiple faults that, IMHO, is based on a questionable interpretation or implementation of the protection mechanism and a "comparison" between three mechanisms one of which is not available to the working group and is laced with subjective scales of comparison (i.e. harder vs easier). Regarding the emails from TI and CMCC - the authors are analyzing them and will provide feedback in the near future. BR, yaacov Still looking for new opportunity On Wed, Oct 17, 2012 at 4:11 AM, Elton huang wrote: > Dear Paul, > A lot of requirements indicated in ITU-T lianson, and inputs form TI > and CMCC are not satisfied in this drafts, could you read past emails > carefully? That's why the draft is not supported. > B.R. > hffellow > > > ------------------------------ > Date: Wed, 3 Oct 2012 05:36:58 +0800 > From: paul.doolan@nsn.com > To: alessandro.dalessandro@telecomitalia.it > CC: mpls@ietf.org; mpls-chairs@tools.ietf.org; > draft-ietf-mpls-tp-ring-protection@tools.ietf.org > Subject: [mpls] R: Working group last call on > draft-ietf-mpls-tp-ring-protection > > > Hello Alessandro, > > Nurit claimed that you (and others) did not =93provide any indication nor > technical justification which requirements are not addressed and why do > you think they are not addressed=85..=94 > > =91Pointing out R100 of RFC5654=92 I guess counts as an =91indication=92 = but > certainly does not provide justification or indicate how the requirement > is not addressed. So to be productive here you need to be mor e specific= . > > Since you provide the example please indicate precisely how you think > this proposed draft violates R100 of RFC5654 (inline below for those > unfamiliar). > > Recovery techniques in a ring SHOULD be identical (or as similar > > as possible) to those in general transport networks to simplify > > implementation and operations. However, this MUST NOT override > > any other requirement. > > You might also want to look at RFC2119. > > best regards, > > pd > > Paul Doolan > > > _______________________________________________ mpls mailing list > mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --bcaec53aef50f0a84804cc3b9210 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

After careful reading of the LS rec= eived from the ITU-T, I did not see "a lot of requirements" - the= re were exactly three, two of which were new requirements, apparently put t= ogether in order to fit a particular solution, that define a new concept in= ring protection - "shared ring protection switching". =A0Aside f= rom that the LS presents a "problem" with the draft for multiple = faults that, IMHO, is based on a questionable interpretation or implementat= ion of the protection mechanism and a "comparison" between three = mechanisms one of which is not available to the working group and is laced = with subjective scales of comparison (i.e. harder vs easier).

Regarding the emails from TI and CMCC - the authors are= analyzing them and will provide feedback in the near future.
BR,
yaacov

Still looking for= new opportunity

On Wed, Oct 17, 2012 at 4:11 AM, Elton huang= <hffellow@hotmail.com> wrote:
Dear Paul,
=A0=A0=A0=A0=A0A lot of requirements indicated in ITU-T lianson,=A0and=A0in= puts form TI and CMCC are not=A0satisfied in this drafts, could you read pa= st emails carefully? That's why the draft is not supported.
B.R.
hffellow

=A0
Date: Wed, 3 Oct 2012 05:36:58 +0800
From: paul.doolan@nsn.com
To: alessandro.dal= essandro@telecomitalia.it
CC: mpls@ietf.org; <= a href=3D"mailto:mpls-chairs@tools.ietf.org" target=3D"_blank">mpls-chairs@= tools.ietf.org; draft-ietf-mpls-tp-ring-protection@tools.ie= tf.org
Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-prote= ction


Hello Alessandro= ,

Nurit claimed that you (and others) did not =93provide= any indication nor technical justification w= hich requirements are not addressed and why do you think they = are not addressed= =85..=94

=91= Pointing out R100 of RFC= 5654=92 I guess counts as an =91indication= =92= but certainly does not provide= justification or indicate how the= requirement is not addressed. S= o to be productive here you=A0 need to be mor e specific.

Since you provid= e the example please indicate precisely how you think this proposed draft violates R100 of RFC5654 (inline below for those unfamiliar).

Recovery techniq= ues in a ring SHOULD be identical (or as similar

as possible) to = those in general transport networks to simplify

implementation a= nd operations.=A0 However, this MUST NOT override

=A0any other requirement.<= /span>

You might also w= ant to look at RFC2119.

best regards,

pd=

Paul Doolan


= _______________________________________________ mpls mailing list mpls@ietf.org https://www.iet= f.org/mailman/listinfo/mpls

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


--bcaec53aef50f0a84804cc3b9210-- From zheng.zhi@zte.com.cn Wed Oct 17 02:18:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277FD21F882C for ; Wed, 17 Oct 2012 02:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.784 X-Spam-Level: X-Spam-Status: No, score=-100.784 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nre6aYRpOJM7 for ; Wed, 17 Oct 2012 02:18:26 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 05D4621F8826 for ; Wed, 17 Oct 2012 02:18:26 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 0D79F1287FDE for ; Wed, 17 Oct 2012 17:19:12 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id q9H9IM88073266 for ; Wed, 17 Oct 2012 17:18:22 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) Message-Id: <201210170918.q9H9IM88073266@mse02.zte.com.cn> Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q9H9ELYY067334; Wed, 17 Oct 2012 17:14:21 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702E1D82C8D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: "Henderickx, Wim (Wim)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: Ryan Zheng Date: Wed, 17 Oct 2012 17:14:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-17 17:14:06, Serialize complete at 2012-10-17 17:14:06 Content-Type: multipart/alternative; boundary="=_alternative 0032EADE48257A9A_=" X-MAIL: mse02.zte.com.cn q9H9IM88073266 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: "'mpls@ietf.org'" , lizhong.jin@zte.com.cn Subject: Re: [mpls] draft-zjns-mpls-lsp-ping-relay-reply X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 09:18:27 -0000 This is a multipart message in MIME format. --=_alternative 0032EADE48257A9A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgV2ltLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBkZXRhaWxlZCByZXZpZXcgYW5kIGluc2lnaHRm dWwgY29tbWVudHMuIFBsZWFzZSBzZWUgDQppbmxpbmUgYmVsb3cuDQoNCkJlc3QgUmVnYXJkcywN ClJ5YW4NCg0KDQoiSGVuZGVyaWNreCwgV2ltIChXaW0pIiA8d2ltLmhlbmRlcmlja3hAYWxjYXRl bC1sdWNlbnQuY29tPiB3cm90ZSBvbiANCjIwMTItMTAtMTUgMDE6MDQ6MDM6DQoNCj4gSSBoYXZl IGJlZW4gYXNrZWQgdG8gcmV2aWV3IHRoZSBhYm92ZSBkcmFmdCBhcyBvbmUgb2YgdGhlIHJldmll d2Vycy4NCj4gDQo+IFRoZSBkb2MgaXMgdXNlZnVsIGluIGNlcnRhaW4gTVBMUyBzY2VuYXJpbydz IGFzIGRlc2NyaWJlZCBpbiB0aGUgDQo+IGRyYWZ0LiBJdCBjb3VsZCBiZSBjb25zaWRlcmVkIHRv IGJlIGFkb3B0ZWQgYXMgYSBXRyBkb2MuDQo+IA0KPiBIZXJlIGFyZSBzb21lIGNvbW1lbnRzIHdo aWNoIHdvdWxkIG1ha2UgdGhlIGRyYWZ0IG1vcmUgc291bmQuDQo+IDEuIERlc2NyaWJlIHRoZSBi ZWhhdmlvciBmb3IgZGV2aWNlcyB0aGF0IGRpZCBub3QgaW1wbGVtZW50IHRoZSANCj4gYWRkaXRp b25hbCBUTFZzLiBIb3cgd291bGQgdGhleSBiZWhhdmUuDQo8Unlhbj5ZZXMsIHNvbWUgZGVzY3Jp cHRpb24gc2hvdWxkIGJlIGFkZGVkIHRvIG1ha2UgdGhlIGJlaGF2aW9yIG11Y2ggDQpjbGVhci4g VGhlIGRldmljZXMgdGhhdCBkaWQgbm90IGltcGxlbWVudCB0aGUgYWRkaXRpb25hbCBUTFZzIHNo b3VsZCBzZXQgDQp0aGUgcmV0dXJuIGNvZGUgb2YgMiAoIk9uZSBvciBtb3JlIG9mIHRoZSBUTFZz IHdhcyBub3QgdW5kZXJzdG9vZCIpIGluIHRoZSANCnJlc3BvbnNlIGFjY29yZGluZyB0byBzZWN0 aW9uIDMgb2YgUkZDIDQzNzkuIEEgc3VnZ2VzdGVkIHZhbHVlIHdpbGwgYmUgDQpnaXZlbiBpbiBJ QU5BIENvbnNpZGVyYXRpb24gc2VjdGlvbiBvZiBuZXh0IHZlcnNpb24uDQoNCj4gMi4gRGVzY3Jp YmUgdGhlIGJlaGF2aW9yIGlmIHRoZSBwYWNrZXQgbGVuZ3RoIHdvdWxkIGJlIGV4Y2VlZGVkIGJ5 IA0KPiB0aGUgUmVsYXkgTm9kZSBBZGRyZXNzIFN0YWNrIFRMVg0KPFJ5YW4+R29vZCBzdWdnZXN0 aW9uLiBJTU8sIGluIG1vc3QgY2FzZXMsIHRoZSBwYWNrZXQgbGVuZ3RoIHdvdWxkIG5vdCBiZSAN CmV4Y2VlZGVkIGJ5IHRoZSBSZWxheSBOb2RlIEFkZHJlc3MgU3RhY2sgVExWLCB0aGFua3MgdG8g dGhlIFRMViBwcm9jZWR1cmVzIA0KaW4gZWFjaCByZXBseWluZyBMU1IgZGVzY3JpYmVkIGluIHNl Y3Rpb24gNC4yLiBUaGF0IGlzIHRoZSByZXBseWluZyBMU1IgDQp3b3VsZCBjaGVjayB0aGUgYWRk cmVzc2VzIG9mIHRoZSBzdGFjayBpbiB0aGUgc2VxdWVuY2UgZnJvbSB0b3AgdG8gYm90dG9tLCAN CnRvIGZpbmQgb3V0IHRoZSBmaXJzdCByb3V0YWJsZSBJUCBhZGRyZXNzLiBUaGVuIHRob3NlIGFk ZHJlc3MgZW50cmllZCANCmJlaGluZCBvZiB0aGUgZmlyc3Qgcm91dGFibGUgSVAgYWRkcmVzcyBp biB0aGUgYWRkcmVzcyBsaXN0IHdpdGggSyBiaXQgc2V0IA0KdG8gMCB3b3VsZCBiZSBkZWxldGVk LCBhbmQgdGhlIGFkZHJlc3MgZW50cnkgb2YgcmVwbHlpbmcgTFNSIHdvdWxkIGJlIA0KYWRkZWQu IFRoYXQgbWVhbnMgdGhlIGFkZHJlc3NlcyBzdGFjayB3b3VsZCBiZSBrZXB0IG9wdGltaXplZCBi eSBldmVyeSANCnJlcGx5aW5nIExTUiBkdXJpbmcgdHJhY2Vyb3V0ZSBwcm9jZXNzLCBhbmQgb25s eSB0aG9zZSByb3V0YWJsZSByZWxheSBub2RlIA0KYWRkcmVzc2VzIHdvdWxkIGJlIGtlcHQgaW4g dGhlIFRMViwgbm90IGFsbCBub2RlIGFkZHJlc3Nlc6GjDQoNCklmIHRoZSBwYWNrZXQgbGVuZ3Ro IHdhcyBleGNlZWRlZCBieSB0aGUgUmVsYXkgTm9kZSBBZGRyZXNzIFN0YWNrIFRMViANCnVuZXhw ZWN0YWJsbHksIHRoZSBUTFYgd291bGQgYmUgZHJvcHBlZCBhbmQgYSBuZXcgcmV0dXJuIGNvZGUg d291bGQgaGVscCANCnRvIG5vdGlmeSB0aGUgaW5pdGlhdG9yIG9mIHRoZSBzaXR1YXRpb24uIFRo ZSBjYXNlIHdpbGwgYmUgYWRkcmVzc2VkIGluIA0KdGhlIG5leHQgdmVyc2lvbi4NCg0KPiAzLiBH aXZlIGFuIGV4YW1wbGUgaW4gdGhlIHRleHQgZm9yIHRoZSBpbnRlci1BUyBhbmQgc2VhbWxlc3Mg TVBMUyANCj4gc2NlbmFyaW8gaG93IHRoZSBkaWZmZXJlbnQgZGV2aWNlcyBiZWhhdmUgd2l0aCBh IHVzZSBjYXNlDQo8Unlhbj5PSy4gV2lsbCBkby4NCg0KPiA0LiBEZXNjcmliZSBpbiB3aGljaCBz Y2VuYXJpb3MgdGhpcyBpcyBhcHBsaWNhYmxlOiBtYWlubHkgdHJhbnNwb3J0IA0KPiBNUExTLCBi dXQgbm90IGluIElQLVZQTiBvciBMMi1WUE4gc2NlbmFyaW9zDQo8Unlhbj5ZZXMsIGNvcnJlY3Qu DQoNCkhvcGUgdGhlIHJlcGx5IGFib3ZlIGFkZHJlc3NlcyB5b3VyIGNvbmNlcm5zLiBUaGFuayB5 b3UuDQoNCg== --=_alternative 0032EADE48257A9A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5IaSBXaW0sPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yPjx0dD5UaGFuayB5b3UgZm9yIHRoZSBkZXRhaWxlZCByZXZpZXcgYW5kIGluc2ln aHRmdWwgY29tbWVudHMuDQpQbGVhc2Ugc2VlIGlubGluZSBiZWxvdy48L3R0PjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTI+PHR0PkJlc3QgUmVnYXJkcyw8L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+PHR0PlJ5YW48L3R0PjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTI+PHR0PiZxdW90O0hlbmRlcmlja3gsIFdpbSAoV2ltKSZxdW90OyAmbHQ7d2ltLmhlbmRl cmlja3hAYWxjYXRlbC1sdWNlbnQuY29tJmd0Ow0Kd3JvdGUgb24gMjAxMi0xMC0xNSAwMTowNDow Mzo8YnI+DQo8YnI+DQomZ3Q7IEkgaGF2ZSBiZWVuIGFza2VkIHRvIHJldmlldyB0aGUgYWJvdmUg ZHJhZnQgYXMgb25lIG9mIHRoZSByZXZpZXdlcnMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBk b2MgaXMgdXNlZnVsIGluIGNlcnRhaW4gTVBMUyBzY2VuYXJpbydzIGFzIGRlc2NyaWJlZCBpbiB0 aGUgPGJyPg0KJmd0OyBkcmFmdC4gSXQgY291bGQgYmUgY29uc2lkZXJlZCB0byBiZSBhZG9wdGVk IGFzIGEgV0cgZG9jLjxicj4NCiZndDsgPGJyPg0KJmd0OyBIZXJlIGFyZSBzb21lIGNvbW1lbnRz IHdoaWNoIHdvdWxkIG1ha2UgdGhlIGRyYWZ0IG1vcmUgc291bmQuPGJyPg0KJmd0OyAxLiBEZXNj cmliZSB0aGUgYmVoYXZpb3IgZm9yIGRldmljZXMgdGhhdCBkaWQgbm90IGltcGxlbWVudCB0aGUg PGJyPg0KJmd0OyBhZGRpdGlvbmFsIFRMVnMuIEhvdyB3b3VsZCB0aGV5IGJlaGF2ZS48L3R0Pjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZsdDtSeWFuJmd0O1llcywgc29tZSBkZXNjcmlw dGlvbiBzaG91bGQgYmUgYWRkZWQNCnRvIG1ha2UgdGhlIGJlaGF2aW9yIG11Y2ggY2xlYXIuIFRo ZSBkZXZpY2VzIHRoYXQgZGlkIG5vdCBpbXBsZW1lbnQgdGhlDQphZGRpdGlvbmFsIFRMVnMgc2hv dWxkIHNldCB0aGUgcmV0dXJuIGNvZGUgb2YgMiAoJnF1b3Q7T25lIG9yIG1vcmUgb2YgdGhlDQpU TFZzIHdhcyBub3QgdW5kZXJzdG9vZCZxdW90OykgaW4gdGhlIHJlc3BvbnNlIGFjY29yZGluZyB0 byBzZWN0aW9uIDMgb2YNClJGQyA0Mzc5LiBBIHN1Z2dlc3RlZCB2YWx1ZSB3aWxsIGJlIGdpdmVu IGluIElBTkEgQ29uc2lkZXJhdGlvbiBzZWN0aW9uDQpvZiBuZXh0IHZlcnNpb24uPC90dD48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQomZ3Q7IDIuIERlc2NyaWJlIHRoZSBiZWhh dmlvciBpZiB0aGUgcGFja2V0IGxlbmd0aCB3b3VsZCBiZSBleGNlZWRlZCBieQ0KPGJyPg0KJmd0 OyB0aGUgUmVsYXkgTm9kZSBBZGRyZXNzIFN0YWNrIFRMVjwvdHQ+PC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mj48dHQ+Jmx0O1J5YW4mZ3Q7R29vZCBzdWdnZXN0aW9uLiBJTU8sIGluIG1vc3QgY2Fz ZXMsIHRoZQ0KcGFja2V0IGxlbmd0aCB3b3VsZCBub3QgYmUgZXhjZWVkZWQgYnkgdGhlIFJlbGF5 IE5vZGUgQWRkcmVzcyBTdGFjayBUTFYsDQp0aGFua3MgdG8gdGhlIFRMViBwcm9jZWR1cmVzIGlu IGVhY2ggcmVwbHlpbmcgTFNSIGRlc2NyaWJlZCBpbiBzZWN0aW9uDQo0LjIuIFRoYXQgaXMgdGhl IHJlcGx5aW5nIExTUiB3b3VsZCBjaGVjayB0aGUgYWRkcmVzc2VzIG9mIHRoZSBzdGFjayBpbg0K dGhlIHNlcXVlbmNlIGZyb20gdG9wIHRvIGJvdHRvbSwgdG8gZmluZCBvdXQgdGhlIGZpcnN0IHJv dXRhYmxlIElQIGFkZHJlc3MuDQpUaGVuIHRob3NlIGFkZHJlc3MgZW50cmllZCBiZWhpbmQgb2Yg dGhlIGZpcnN0IHJvdXRhYmxlIElQIGFkZHJlc3MgaW4gdGhlDQphZGRyZXNzIGxpc3Qgd2l0aCBL IGJpdCBzZXQgdG8gMCB3b3VsZCBiZSBkZWxldGVkLCBhbmQgdGhlIGFkZHJlc3MgZW50cnkNCm9m IHJlcGx5aW5nIExTUiB3b3VsZCBiZSBhZGRlZC4gVGhhdCBtZWFucyB0aGUgYWRkcmVzc2VzIHN0 YWNrIHdvdWxkIGJlDQprZXB0IG9wdGltaXplZCBieSBldmVyeSByZXBseWluZyBMU1IgZHVyaW5n IHRyYWNlcm91dGUgcHJvY2VzcywgYW5kIG9ubHkNCnRob3NlIHJvdXRhYmxlIHJlbGF5IG5vZGUg YWRkcmVzc2VzIHdvdWxkIGJlIGtlcHQgaW4gdGhlIFRMViwgbm90IGFsbCBub2RlDQphZGRyZXNz ZXOhozwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+SWYgdGhlIHBhY2tl dCBsZW5ndGggd2FzIGV4Y2VlZGVkIGJ5IHRoZSBSZWxheSBOb2RlDQpBZGRyZXNzIFN0YWNrIFRM ViB1bmV4cGVjdGFibGx5LCB0aGUgVExWIHdvdWxkIGJlIGRyb3BwZWQgYW5kIGEgbmV3IHJldHVy bg0KY29kZSB3b3VsZCBoZWxwIHRvIG5vdGlmeSB0aGUgaW5pdGlhdG9yIG9mIHRoZSBzaXR1YXRp b24uIFRoZSBjYXNlIHdpbGwNCmJlIGFkZHJlc3NlZCBpbiB0aGUgbmV4dCB2ZXJzaW9uLjwvdHQ+ PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJyPg0KJmd0OyAzLiBHaXZlIGFuIGV4YW1w bGUgaW4gdGhlIHRleHQgZm9yIHRoZSBpbnRlci1BUyBhbmQgc2VhbWxlc3MgTVBMUw0KPGJyPg0K Jmd0OyBzY2VuYXJpbyBob3cgdGhlIGRpZmZlcmVudCBkZXZpY2VzIGJlaGF2ZSB3aXRoIGEgdXNl IGNhc2U8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZsdDtSeWFuJmd0O09LLiBX aWxsIGRvLjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJyPg0KJmd0OyA0LiBE ZXNjcmliZSBpbiB3aGljaCBzY2VuYXJpb3MgdGhpcyBpcyBhcHBsaWNhYmxlOiBtYWlubHkgdHJh bnNwb3J0DQo8YnI+DQomZ3Q7IE1QTFMsIGJ1dCBub3QgaW4gSVAtVlBOIG9yIEwyLVZQTiBzY2Vu YXJpb3M8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZsdDtSeWFuJmd0O1llcywg Y29ycmVjdC48L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PkhvcGUgdGhl IHJlcGx5IGFib3ZlIGFkZHJlc3NlcyB5b3VyIGNvbmNlcm5zLiBUaGFuaw0KeW91Ljxicj4NCjwv dHQ+PC9mb250Pg0K --=_alternative 0032EADE48257A9A_=-- From adrian@olddog.co.uk Wed Oct 17 13:34:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC1D21F867E for ; Wed, 17 Oct 2012 13:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDoOIZGEmO-p for ; Wed, 17 Oct 2012 13:34:45 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id B12F221F85B8 for ; Wed, 17 Oct 2012 13:34:36 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9HKYZHZ008796; Wed, 17 Oct 2012 21:34:35 +0100 Received: from 950129200 (westford-nat.juniper.net [66.129.232.2]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9HKYTUH008717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Oct 2012 21:34:33 +0100 From: "Adrian Farrel" To: Date: Wed, 17 Oct 2012 21:34:30 +0100 Message-ID: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2spr9U20RDhLSITuSsaaLzMUzfUw== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD review of draft-ietf-mpls-return-path-specified-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 20:34:47 -0000 Hi, I've done my usual AD review of your draft prior to issuing IETF last call and passing the I-D for IESG evaluation. The main purpose of the review is to catch issues that might come up in later reviews and to ensure that the document is ready for publication as and RFC. I found Section 4 very good. It completely explains to me what is going on in the protocol extension, and covered all the corner cases I could think of. On the other hand, Section 3 made me generate a really (really, really) long list of relatively minor issues. This list is so long that I think you need to provide a new revision before we issue the IETF last call. I will put the I-D into "Revised I-D Needed" state and wait for the revision. As always, all my comments are up for discussion and negotiation. Thanks for the work, Adrian === Consistency of references for bidirectional LSP. In Section 1 you have In this document, term bidirectional LSP includes the co-routed bidirectional LSP defined in [RFC3945] In Section 2 you have: The co-routed bidirectional LSP is defined in [RFC3471] and [RFC3473] --- Section 1 s/(BFD)[RFC5880], [RFC5884]session/(BFD) [RFC5880], [RFC5884] session/ s/In this document, term bidirectional LSP/In this document, the term bidirectional LSP/ --- Section 3.1 OLD The recommended value of the Reply via Specified Path mode is 5 (This is to be confirmed by the IANA). Value Meaning ----- ------- 5 Reply via Specified Path NEW The value of the Reply via Specified Path mode is 5 (This has been allocated by IANA using early allocation and is to be confirmed by IANA). Value Meaning ----- ------- 5 Reply via Specified Path END --- Section 3.2 OLD The Reply Path (RP) TLV is an optional TLV, if the Reply via Specified Path mode requested, the Reply Path (RP) TLV MUST be included in an echo request message. It carries the specified return paths that the echo reply message is required to follow. The format of Reply Path TLV is as follows: NEW The Reply Path (RP) TLV is an optional TLV within the LSP Ping protocol. However, if the Reply via Specified Path mode requested as described in Section 3.1, the Reply Path (RP) TLV MUST be included in an echo request message and its absence is treated as a malformed echo request as described in [RFC4379]. Furthermore, if a Reply Path (RP) TLV is included in an echo request message, a Reply Path (RP) TLV MUST be included in the corresponding echo reply message sent by an implementation that is conformant to this specification. The Reply Path (RP) TLV carries the specified return path that the echo reply message is required to follow. The format of Reply Path TLV is as follows: END --- Section 3.2 OLD Reply Path TLV Type field is 2 octets in length, and the type value is TBD by IANA. NEW Reply Path TLV Type field is 2 octets in length, and the type value is 21. (This has been allocated by IANA using early allocation and is to be confirmed by IANA). END --- Section 3.2 OLD Reply Path return code is 2 octets in length. It is defined for the egress LSR of the forward LSP to report the results of Reply Path TLV processing and return path selection. When sending echo request, these codes MUST be set to zero. Reply Path return code only used when sending echo reply, and it MUST be ignored when processing echo request message. This document defines the following Reply Path return codes: NEW The Reply Path return code field is 2 octets in length. It is defined for the egress LSR of the forward LSP to report the results of Reply Path TLV processing and return path selection. This field MUST be set to zero in a Reply Path TLV carried on an echo request message and MUST be ignored on receipt. This document defines the following Reply Path return codes for inclusion in a Reply Path TLV carried on an echo reply: END --- Section 3.2 Value Meaning ------ ---------------------- 0x0000 No return code What does "No return code" mean? I thought it might have been the value that you should return if the TLV has been successfully processed but you seem to have 0x0003 for this. So, how is 0x0000 used? --- Section 3.2 0x0006 The Reply mode in echo request was not set to 5 (Reply via Specified Path) although Reply Path TLV exists 0x0007 Reply Path TLV was missing in echo request Surely these are malformed echo requests and will be handled with normal echo replies with return code value 1. --- Section 3.2 The A bit and B bit set MUST NOT both be set, otherwise, an echo reply with the RP return code set to "Malformed RP TLV was received" SHOULD be returned. What other options are there? I.e. why "SHOULD" not "MUST"? --- Section 3.2 OLD The Reply Paths field is variable in length, not more than one sub- TLV MUST be carried, which describes the specified path that the echo reply message is required to follow. When the Reply Mode field is set to "Reply via Specified Path" in an LSP echo request message, the Reply Path TLV MUST be present. The Reply Path TLV SHALL only be used in the reply mode defined in this document (Reply via Specified Path). NEW The Reply Paths field is variable in length and MUST contain zero or one sub-TLV. The sub-TLV, if present, describes the specified path that the echo reply message is required to follow. END --- Section 3.2 When the Reply Mode field is set to "Reply via Specified Path" in an LSP echo request message, the Reply Path TLV MUST be present. I think this is a duplication of a previous statement and can be removed --- Section 3.2 The Reply Path TLV SHALL only be used in the reply mode defined in this document (Reply via Specified Path). Why do you need this? And can it be enforced? It is very unusual to restrict the use of information in this way. I understand that you do not have any other use in mind, but is there a need to make this constraint. --- Section 3.3 In [RFC4379], the range of 31744-32767 and 64512-65535 for sub-TLVs is specified for Vendor Private Use, and MUST NOT be allocated. This document changes that rule to make it not applicable to Reply Path TLV and redefines the rule as in Section 6.2 . If an implementation recognizes any specific Vendor Private types as defined in [RFC4379], and uses the sub-TLV type specified in this document, care must be taken to ensure that the implementation does not confuse the two usages. I don't think this draft changes the registry for 4379, does it? This needs a little more care to separate the two uses clearly. How about... OLD Each of the FEC sub-TLVs (include existing and future defined) for the Target FEC Stack TLV[RFC4379] is applicable to be a sub-TLV for inclusion in the Reply Path TLV for expressing a specific return path. For these shared sub-TLVs, they share the same registry with the Target FEC Stack TLV for the range of 0-31743 and 32768-64511. In addition, this document defines three new sub-TLVs: IPv4 RSVP Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV and Static Tunnel sub-TLV. These sub-TLVs are only designed for Reply Path TLV, hence this document calls them dedicated sub-TLVs to Reply Path TLV. For these dedicated sub-TLVs, this document will create a new registry (Section 6.1), the sub-TLV type MUST be allocated from the new registry. Detailed definition is in the following sections. In [RFC4379], the range of 31744-32767 and 64512-65535 for sub-TLVs is specified for Vendor Private Use, and MUST NOT be allocated. This document changes that rule to make it not applicable to Reply Path TLV and redefines the rule as in Section 6.2 . If an implementation recognizes any specific Vendor Private types as defined in [RFC4379], and uses the sub-TLV type specified in this document, care must be taken to ensure that the implementation does not confuse the two usages. NEW The FECs defined in [RFC4379] provide a good way to identify a specific return path. The FEC sub-TLVs (including existing and future sub-TLVs) of the Target FEC Stack TLV [RFC4379] have sub-TLV types assigned from a registry with ranges as follows: 0-16383 Standards Action mandatory TLV 16384-31743 Specification Required, Experimental RFC needed 31744-32767 Vendor Private Use, MUST NOT be allocated 32768-49161 Standards Action optional TLV 49162-64511 Specification Required, Experimental RFC needed 64512-65535 Vendor Private Use, MUST NOT be allocated The Reply Path TLV can carry and sub-TLV defined for use in the Target FEC Stack TLV that can be registered. Thus the ranges 0-31743 and 32768-64511 are shared by the registries, with the new Reply Path Sub-TLVs registry "borrowing" values from the Target FEC Stack TLV registry. Allocations from the ranges 31744-32767 and 64512-65535 are not recorded in the registry for Target FEC Stack TLVs, so these ranges are safely made available in the Reply Path Sub-TLVs registry (see Section 6.1) to record sub-TLVs that are specific to the Reply Path TLV. This document defines three sub-TLVs specific to the Reply Path TLV: IPv4 RSVP Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV. Note that an implementation that supports specific Vendor Private for sub-TLVs of the Target FEC Stack must take care to not confuse those values with the same values allocated from the Reply Path Sub- TLVs registry. END --- Section 3.3 2. Specify a more generic tunnel FEC as return path It is clear that 3.3.1 and 3.3.2 define a FEC that is more general than the FECs in 4379. What is not clear is the use case. I think you need some text in this document to say what you should do with one of these FECs since it possibly identifies a set of LSPs. --- Section 3.3.1 OLD The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and the recommended type value is TBD. NEW The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and the recommended type value is TBD1. END --- Section 3.3.1 It is slightly weird that the bit field in this section allocates the first two bits while the field in section 3.2 allocates the last two bits. This is not significantly important, but is odd. --- Section 3.3.2 OLD The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and the type value is TBD. NEW The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and the type value is TBD2. END --- Section 3.3.3 RFC 6370 seems to also include an "LSP_Num". So your 3.3.3 case is the MPLS-TP static equivalent of 3.3.1. But you are missing: - the MPLS-TP static equivalent of 3.3.2 (i.e. v6 identifiers) - the MPLS-TP equivalent of the 4379 RSVP LSP FECs Do you need them? --- Section 3.3.3 OLD The sub-TLV type value is TBD. NEW The sub-TLV type value is TBD3. END --- Section 3.4 OLD The Reply TC TLV Type field is 2 octets in length, and the type value is TBD. NEW The Reply TC TLV Type field is 2 octets in length, and the type value is TBD4. END --- Section 4 The procedures defined in this document currently only apply to "ping" mode. The "traceroute" mode is out of scope for this document. I think this should show up in the Introduction and possibly the Abstract. --- Section 6 Please consider whether you want registries for the bit fields you define in this document. --- Section 6.1 OLD TBD Reply TC TLV this document (sect 3.4) NEW TBD4 Reply TC TLV this document (sect 3.4) END --- Section 6.4 OLD TBD Reply TC TLV this document (sect 3.4) NEW TBD4 Reply TC TLV this document (sect 3.4) END --- Section 6.2.1 OLD Sub-type Value Field Reference ------- ----------- --------- TBD IPv4 RSVP Tunnel this document (sect 3.3.1) TBD IPv6 RSVP Tunnel this document (sect 3.3.2) TBD Static Tunnel this document (sect 3.3.3) NEW Sub-type Value Field Reference ------- ----------- --------- TBD1 IPv4 RSVP Tunnel this document (sect 3.3.1) TBD2 IPv6 RSVP Tunnel this document (sect 3.3.2) TBD3 Static Tunnel this document (sect 3.3.3) END --- Section 6.3 OLD IANA is now requested to assign the previously assigned a new reply mode code point (5 - Reply via specified path) from the "Multi- Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, the "Reply Mode" sub-registry on a permanent basis. NEW IANA has made an early allocation (5 - Reply via specified path) from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, the "Reply Mode" sub-registry. IANA is requested to make this allocation permanent. END From y.kamite@ntt.com Wed Oct 17 18:38:17 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D784711E808A for ; Wed, 17 Oct 2012 18:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8E4F7w0XlPi for ; Wed, 17 Oct 2012 18:38:17 -0700 (PDT) Received: from mgw010.noc.ntt.com (mgw010.noc.ntt.com [210.160.55.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171D41F0381 for ; Wed, 17 Oct 2012 18:38:17 -0700 (PDT) Received: from c0044i0.coe.ntt.com (unknown [10.18.161.13]) by mgw010.noc.ntt.com (NTT Com MailSV) with ESMTP id 01EA157A0640; Thu, 18 Oct 2012 10:38:16 +0900 (JST) Received: from C0037I0.coe.ntt.com (10.18.160.41) by c0044i0.coe.ntt.com (10.18.161.13) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 18 Oct 2012 10:38:12 +0900 Received: from C0007I0.coe.ntt.com ([169.254.1.46]) by C0037I0.coe.ntt.com ([10.18.160.41]) with mapi id 14.01.0355.002; Thu, 18 Oct 2012 10:38:15 +0900 From: Yuji Kamite To: "Venator, Robert H III CIV (US)" , "Rakesh Gandhi (rgandhi)" , Loa Andersson , "mpls@ietf.org" Thread-Topic: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp Thread-Index: AQHNqtJUyiWBUAOUH0GRVSkeJz5XTJe6HYWAgAQtLYA= Date: Thu, 18 Oct 2012 01:38:14 +0000 Message-ID: <1A095D7ECD89A64C9D3C77AE2DDE660B57DC9143@C0007I0.coe.ntt.com> References: <507C0172.1030309@pi.nu> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: robert.h.venator.civ@mail.mil, rgandhi@cisco.com, loa@pi.nu, mpls@ietf.org x-ccmail-original-cc: mpls-chairs@tools.ietf.org, draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org x-originating-ip: [10.50.137.96] Content-Type: text/plain; charset="iso-2022-jp" MIME-Version: 1.0 Cc: "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 01:38:18 -0000 Hi Loa, I'm not aware of any other IPRs related to this document. Regrads, Yuji Kamite > -----Original Message----- > From: Venator, Robert H III CIV (US) [mailto:robert.h.venator.civ@mail.mil] > Sent: Tuesday, October 16, 2012 3:44 AM > To: Rakesh Gandhi (rgandhi); Loa Andersson; mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org > Subject: RE: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp > > Loa, > > I am not aware of any additional IPRs. > > Thanks, Robert Venator > > -----Original Message----- > From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] > Sent: Monday, October 15, 2012 8:41 AM > To: Loa Andersson; mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org; Martin Vigoureux; Venator, > Robert H III CIV (US); y.kamite@ntt.com > Subject: RE: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp > > Hi Loa, > > Yes, IPR has been disclosed. > > http://datatracker.ietf.org/ipr/1861/ > > > thanks, > Rakesh > > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Monday, October 15, 2012 8:29 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org; Martin Vigoureux > Subject: draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp > > Working Group and authors; > > The authors of draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp has indicated that the draft is ready to be adopted as a working > group document. > > Before starting the poll to make the draft become a working group document we will do an IPR poll to check whether there > is IPR on the document that needs to be disclosed. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to > draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp? > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to this email regardless of whether or not you are > aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to > the next stage until a response has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only > if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. > > > Thanks, Loa > (as MPLS WG co-chair) > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From loa@pi.nu Thu Oct 18 00:26:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8200D21F853B for ; Thu, 18 Oct 2012 00:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb4RRjR22GeN for ; Thu, 18 Oct 2012 00:26:46 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEE321F852D for ; Thu, 18 Oct 2012 00:26:46 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 5D5BA82475; Thu, 18 Oct 2012 09:26:36 +0200 (CEST) Message-ID: <507FAF2D.5020907@pi.nu> Date: Thu, 18 Oct 2012 09:26:37 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" , Martin Vigoureux , "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 07:26:47 -0000 Working group, this is to start a two week poll on adopting draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-09 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). Please give an technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends November 07, 2012. There is one IPR claim against this document - http://datatracker.ietf.org/ipr/1861/ . All the co-authors has stated on the mailing list that they are not aware of any other IPR claims than those already disclosed. If there are IPR claims from any other party, please remember that the IPR is open. /Loa (mpls wg co-chair) -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From mach.chen@huawei.com Thu Oct 18 01:56:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3014A21F85A4 for ; Thu, 18 Oct 2012 01:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbJF4gWyId1K for ; Thu, 18 Oct 2012 01:56:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CBCDE21F859E for ; Thu, 18 Oct 2012 01:56:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALT12425; Thu, 18 Oct 2012 08:56:08 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 18 Oct 2012 09:55:01 +0100 Received: from SZXEML441-HUB.china.huawei.com (10.82.67.179) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 18 Oct 2012 09:55:53 +0100 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.129]) by szxeml441-hub.china.huawei.com ([10.82.67.179]) with mapi id 14.01.0323.003; Thu, 18 Oct 2012 16:55:47 +0800 From: Mach Chen To: "adrian@olddog.co.uk" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" Thread-Topic: [mpls] AD review of draft-ietf-mpls-return-path-specified-lsp-ping Thread-Index: Ac2spr9U20RDhLSITuSsaaLzMUzfUwAN1YYQ Date: Thu, 18 Oct 2012 08:55:46 +0000 Message-ID: References: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> In-Reply-To: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW1w?= =?gb2312?b?bHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5n?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 08:56:13 -0000 QWRyaWFuLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciBkZXRhaWwgcmV2aWV3IGFuZCBjb21tZW50 cyENCg0KUGxlYXNlIHNlZSBteSByZXNwb25zZSBpbmxpbmUuLi4NCg0KQmVzdCByZWdhcmRzLA0K TWFjaA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBBZHJpYW4NCj4gRmFycmVs DQo+ILeiy83KsbzkOiAyMDEyxOoxMNTCMTjI1SA0OjM1DQo+IMrVvP7IyzogZHJhZnQtaWV0Zi1t cGxzLXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZy5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4g s63LzTogbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4g1vfM4jog W21wbHNdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVk LWxzcC1waW5nDQo+IA0KPiBIaSwNCj4gDQo+IEkndmUgZG9uZSBteSB1c3VhbCBBRCByZXZpZXcg b2YgeW91ciBkcmFmdCBwcmlvciB0byBpc3N1aW5nIElFVEYgbGFzdA0KPiBjYWxsIGFuZCBwYXNz aW5nIHRoZSBJLUQgZm9yIElFU0cgZXZhbHVhdGlvbi4gVGhlIG1haW4gcHVycG9zZSBvZiB0aGUN Cj4gcmV2aWV3IGlzIHRvIGNhdGNoIGlzc3VlcyB0aGF0IG1pZ2h0IGNvbWUgdXAgaW4gbGF0ZXIg cmV2aWV3cyBhbmQgdG8NCj4gZW5zdXJlIHRoYXQgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBw dWJsaWNhdGlvbiBhcyBhbmQgUkZDLg0KPiANCj4gSSBmb3VuZCBTZWN0aW9uIDQgdmVyeSBnb29k LiBJdCBjb21wbGV0ZWx5IGV4cGxhaW5zIHRvIG1lIHdoYXQgaXMNCj4gZ29pbmcgb24gaW4gdGhl IHByb3RvY29sIGV4dGVuc2lvbiwgYW5kIGNvdmVyZWQgYWxsIHRoZSBjb3JuZXIgY2FzZXMNCj4g SSBjb3VsZCB0aGluayBvZi4gT24gdGhlIG90aGVyIGhhbmQsIFNlY3Rpb24gMyBtYWRlIG1lIGdl bmVyYXRlIGENCj4gcmVhbGx5IChyZWFsbHksIHJlYWxseSkgbG9uZyBsaXN0IG9mIHJlbGF0aXZl bHkgbWlub3IgaXNzdWVzLiBUaGlzDQo+IGxpc3QgaXMgc28gbG9uZyB0aGF0IEkgdGhpbmsgeW91 IG5lZWQgdG8gcHJvdmlkZSBhIG5ldyByZXZpc2lvbg0KPiBiZWZvcmUgd2UgaXNzdWUgdGhlIElF VEYgbGFzdCBjYWxsLiBJIHdpbGwgcHV0IHRoZSBJLUQgaW50byAiUmV2aXNlZA0KPiBJLUQgTmVl ZGVkIiBzdGF0ZSBhbmQgd2FpdCBmb3IgdGhlIHJldmlzaW9uLg0KPiANCj4gQXMgYWx3YXlzLCBh bGwgbXkgY29tbWVudHMgYXJlIHVwIGZvciBkaXNjdXNzaW9uIGFuZCBuZWdvdGlhdGlvbi4NCj4g DQo+IFRoYW5rcyBmb3IgdGhlIHdvcmssDQo+IEFkcmlhbg0KPiANCj4gPT09DQo+IA0KPiBDb25z aXN0ZW5jeSBvZiByZWZlcmVuY2VzIGZvciBiaWRpcmVjdGlvbmFsIExTUC4gSW4gU2VjdGlvbiAx IHlvdSBoYXZlDQo+ICAgIEluIHRoaXMgZG9jdW1lbnQsIHRlcm0gYmlkaXJlY3Rpb25hbCBMU1Ag aW5jbHVkZXMgdGhlIGNvLXJvdXRlZA0KPiAgICBiaWRpcmVjdGlvbmFsIExTUCBkZWZpbmVkIGlu IFtSRkMzOTQ1XQ0KPiBJbiBTZWN0aW9uIDIgeW91IGhhdmU6DQo+ICAgIFRoZSBjby1yb3V0ZWQg YmlkaXJlY3Rpb25hbCBMU1AgaXMgZGVmaW5lZCBpbiBbUkZDMzQ3MV0NCj4gICAgYW5kIFtSRkMz NDczXQ0KPiANCk9LLCB3aWxsIGNvbnNpc3RlbnRseSByZWZlciB0byBbUkZDMzk0NV0gaW5zdGVh ZC4NCg0KPiAtLS0NCj4gDQo+IFNlY3Rpb24gMQ0KPiBzLyhCRkQpW1JGQzU4ODBdLCBbUkZDNTg4 NF1zZXNzaW9uLyhCRkQpIFtSRkM1ODgwXSwgW1JGQzU4ODRdIHNlc3Npb24vDQo+IHMvSW4gdGhp cyBkb2N1bWVudCwgdGVybSBiaWRpcmVjdGlvbmFsIExTUC9JbiB0aGlzIGRvY3VtZW50LCB0aGUg dGVybQ0KPiBiaWRpcmVjdGlvbmFsIExTUC8NCg0KT0suDQoNCj4gDQo+IC0tLQ0KPiANCj4gU2Vj dGlvbiAzLjENCj4gDQo+IE9MRA0KPiAgICBUaGUgcmVjb21tZW5kZWQgdmFsdWUgb2YgdGhlIFJl cGx5IHZpYSBTcGVjaWZpZWQgUGF0aCBtb2RlIGlzIDUgKFRoaXMNCj4gICAgaXMgdG8gYmUgY29u ZmlybWVkIGJ5IHRoZSBJQU5BKS4NCj4gDQo+ICAgICAgICBWYWx1ZSAgICBNZWFuaW5nDQo+ICAg ICAgICAtLS0tLSAgICAtLS0tLS0tDQo+ICAgICAgICAgICAgNSAgICAgUmVwbHkgdmlhIFNwZWNp ZmllZCBQYXRoDQo+IE5FVw0KPiAgICBUaGUgdmFsdWUgb2YgdGhlIFJlcGx5IHZpYSBTcGVjaWZp ZWQgUGF0aCBtb2RlIGlzIDUgKFRoaXMgaGFzIGJlZW4NCj4gICAgYWxsb2NhdGVkIGJ5IElBTkEg dXNpbmcgZWFybHkgYWxsb2NhdGlvbiBhbmQgaXMgdG8gYmUgY29uZmlybWVkIGJ5DQo+ICAgIElB TkEpLg0KPiANCj4gICAgICAgIFZhbHVlICAgIE1lYW5pbmcNCj4gICAgICAgIC0tLS0tICAgIC0t LS0tLS0NCj4gICAgICAgICAgICA1ICAgICBSZXBseSB2aWEgU3BlY2lmaWVkIFBhdGgNCj4gRU5E DQoNCk9LLg0KDQo+IA0KPiAtLS0NCj4gDQo+IFNlY3Rpb24gMy4yDQo+IA0KPiBPTEQNCj4gICAg VGhlIFJlcGx5IFBhdGggKFJQKSBUTFYgaXMgYW4gb3B0aW9uYWwgVExWLCBpZiB0aGUgUmVwbHkg dmlhDQo+ICAgIFNwZWNpZmllZCBQYXRoIG1vZGUgcmVxdWVzdGVkLCB0aGUgUmVwbHkgUGF0aCAo UlApIFRMViBNVVNUIGJlDQo+ICAgIGluY2x1ZGVkIGluIGFuIGVjaG8gcmVxdWVzdCBtZXNzYWdl LiAgSXQgY2FycmllcyB0aGUgc3BlY2lmaWVkIHJldHVybg0KPiAgICBwYXRocyB0aGF0IHRoZSBl Y2hvIHJlcGx5IG1lc3NhZ2UgaXMgcmVxdWlyZWQgdG8gZm9sbG93LiAgVGhlIGZvcm1hdA0KPiAg ICBvZiBSZXBseSBQYXRoIFRMViBpcyBhcyBmb2xsb3dzOg0KPiANCj4gTkVXDQo+ICAgIFRoZSBS ZXBseSBQYXRoIChSUCkgVExWIGlzIGFuIG9wdGlvbmFsIFRMViB3aXRoaW4gdGhlIExTUCBQaW5n DQo+ICAgIHByb3RvY29sLiAgSG93ZXZlciwgaWYgdGhlIFJlcGx5IHZpYSBTcGVjaWZpZWQgUGF0 aCBtb2RlIHJlcXVlc3RlZCBhcw0KPiAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjEsIHRoZSBS ZXBseSBQYXRoIChSUCkgVExWIE1VU1QgYmUgaW5jbHVkZWQgaW4NCj4gICAgYW4gZWNobyByZXF1 ZXN0IG1lc3NhZ2UgYW5kIGl0cyBhYnNlbmNlIGlzIHRyZWF0ZWQgYXMgYSBtYWxmb3JtZWQNCj4g ICAgZWNobyByZXF1ZXN0IGFzIGRlc2NyaWJlZCBpbiBbUkZDNDM3OV0uICBGdXJ0aGVybW9yZSwg aWYgYSBSZXBseSBQYXRoDQo+ICAgIChSUCkgVExWIGlzIGluY2x1ZGVkIGluIGFuIGVjaG8gcmVx dWVzdCBtZXNzYWdlLCBhIFJlcGx5IFBhdGggKFJQKQ0KPiAgICBUTFYgTVVTVCBiZSBpbmNsdWRl ZCBpbiB0aGUgY29ycmVzcG9uZGluZyBlY2hvIHJlcGx5IG1lc3NhZ2Ugc2VudCBieQ0KPiAgICBh biBpbXBsZW1lbnRhdGlvbiB0aGF0IGlzIGNvbmZvcm1hbnQgdG8gdGhpcyBzcGVjaWZpY2F0aW9u Lg0KPiANCj4gICAgVGhlIFJlcGx5IFBhdGggKFJQKSBUTFYgY2FycmllcyB0aGUgc3BlY2lmaWVk IHJldHVybiBwYXRoIHRoYXQgdGhlDQo+ICAgIGVjaG8gcmVwbHkgbWVzc2FnZSBpcyByZXF1aXJl ZCB0byBmb2xsb3cuICBUaGUgZm9ybWF0IG9mIFJlcGx5IFBhdGgNCj4gICAgVExWIGlzIGFzIGZv bGxvd3M6DQo+IEVORA0KDQpPSy4NCg0KPiANCj4gLS0tDQo+IA0KPiBTZWN0aW9uIDMuMg0KPiAN Cj4gT0xEDQo+ICAgIFJlcGx5IFBhdGggVExWIFR5cGUgZmllbGQgaXMgMiBvY3RldHMgaW4gbGVu Z3RoLCBhbmQgdGhlIHR5cGUgdmFsdWUNCj4gICAgaXMgVEJEIGJ5IElBTkEuDQo+IE5FVw0KPiAg ICBSZXBseSBQYXRoIFRMViBUeXBlIGZpZWxkIGlzIDIgb2N0ZXRzIGluIGxlbmd0aCwgYW5kIHRo ZSB0eXBlIHZhbHVlDQo+ICAgIGlzIDIxLiAoVGhpcyBoYXMgYmVlbiBhbGxvY2F0ZWQgYnkgSUFO QSB1c2luZyBlYXJseSBhbGxvY2F0aW9uIGFuZCBpcw0KPiAgICB0byBiZSBjb25maXJtZWQgYnkg SUFOQSkuDQo+IEVORA0KDQpPSy4NCg0KPiANCj4gLS0tDQo+IA0KPiBTZWN0aW9uIDMuMg0KPiAN Cj4gT0xEDQo+ICAgIFJlcGx5IFBhdGggcmV0dXJuIGNvZGUgaXMgMiBvY3RldHMgaW4gbGVuZ3Ro LiAgSXQgaXMgZGVmaW5lZCBmb3IgdGhlDQo+ICAgIGVncmVzcyBMU1Igb2YgdGhlIGZvcndhcmQg TFNQIHRvIHJlcG9ydCB0aGUgcmVzdWx0cyBvZiBSZXBseSBQYXRoIFRMVg0KPiAgICBwcm9jZXNz aW5nIGFuZCByZXR1cm4gcGF0aCBzZWxlY3Rpb24uICBXaGVuIHNlbmRpbmcgZWNobyByZXF1ZXN0 LA0KPiAgICB0aGVzZSBjb2RlcyBNVVNUIGJlIHNldCB0byB6ZXJvLiAgUmVwbHkgUGF0aCByZXR1 cm4gY29kZSBvbmx5IHVzZWQNCj4gICAgd2hlbiBzZW5kaW5nIGVjaG8gcmVwbHksIGFuZCBpdCBN VVNUIGJlIGlnbm9yZWQgd2hlbiBwcm9jZXNzaW5nIGVjaG8NCj4gICAgcmVxdWVzdCBtZXNzYWdl LiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgUmVwbHkgUGF0aA0KPiAgICBy ZXR1cm4gY29kZXM6DQo+IE5FVw0KPiAgICBUaGUgUmVwbHkgUGF0aCByZXR1cm4gY29kZSBmaWVs ZCBpcyAyIG9jdGV0cyBpbiBsZW5ndGguICBJdCBpcw0KPiAgICBkZWZpbmVkIGZvciB0aGUgZWdy ZXNzIExTUiBvZiB0aGUgZm9yd2FyZCBMU1AgdG8gcmVwb3J0IHRoZSByZXN1bHRzDQo+ICAgIG9m IFJlcGx5IFBhdGggVExWIHByb2Nlc3NpbmcgYW5kIHJldHVybiBwYXRoIHNlbGVjdGlvbi4gIFRo aXMgZmllbGQNCj4gICAgTVVTVCBiZSBzZXQgdG8gemVybyBpbiBhIFJlcGx5IFBhdGggVExWIGNh cnJpZWQgb24gYW4gZWNobyByZXF1ZXN0DQo+ICAgIG1lc3NhZ2UgYW5kIE1VU1QgYmUgaWdub3Jl ZCBvbiByZWNlaXB0LiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZQ0KPiAgICBmb2xsb3dpbmcg UmVwbHkgUGF0aCByZXR1cm4gY29kZXMgZm9yIGluY2x1c2lvbiBpbiBhIFJlcGx5IFBhdGggVExW DQo+ICAgIGNhcnJpZWQgb24gYW4gZWNobyByZXBseToNCj4gRU5EDQoNCk9LLg0KDQo+IA0KPiAt LS0NCj4gDQo+IFNlY3Rpb24gMy4yDQo+IA0KPiAgICBWYWx1ZSAgICAgICAgIE1lYW5pbmcNCj4g ICAgLS0tLS0tICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgIDB4MDAwMCAgICAg ICAgTm8gcmV0dXJuIGNvZGUNCj4gDQo+IFdoYXQgZG9lcyAiTm8gcmV0dXJuIGNvZGUiIG1lYW4/ IEkgdGhvdWdodCBpdCBtaWdodCBoYXZlIGJlZW4gdGhlIHZhbHVlDQo+IHRoYXQgeW91IHNob3Vs ZCByZXR1cm4gaWYgdGhlIFRMViBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgcHJvY2Vzc2VkIGJ1dA0K PiB5b3Ugc2VlbSB0byBoYXZlIDB4MDAwMyBmb3IgdGhpcy4gU28sIGhvdyBpcyAweDAwMDAgdXNl ZD8NCg0KSXQgc2hvdWxkIGJlIG5hbWVkIGFzICJSZXNlcnZlZCIuDQoNCj4gDQo+IC0tLQ0KPiAN Cj4gU2VjdGlvbiAzLjINCj4gDQo+ICAgIDB4MDAwNiAgICAgICAgVGhlIFJlcGx5IG1vZGUgaW4g ZWNobyByZXF1ZXN0IHdhcyBub3Qgc2V0IHRvIDUgKFJlcGx5DQo+ICAgICAgICAgICAgICAgICAg dmlhIFNwZWNpZmllZCBQYXRoKSBhbHRob3VnaCBSZXBseSBQYXRoIFRMViBleGlzdHMNCg0KDQo+ ICAgIDB4MDAwNyAgICAgICAgUmVwbHkgUGF0aCBUTFYgd2FzIG1pc3NpbmcgaW4gZWNobyByZXF1 ZXN0DQo+IA0KPiBTdXJlbHkgdGhlc2UgYXJlIG1hbGZvcm1lZCBlY2hvIHJlcXVlc3RzIGFuZCB3 aWxsIGJlIGhhbmRsZWQgd2l0aA0KPiBub3JtYWwgZWNobyByZXBsaWVzIHdpdGggcmV0dXJuIGNv ZGUgdmFsdWUgMS4NCg0KWWVzLCBpbmRlZWQsIHdpbGwgcmVtb3ZlIHRoaXMgdHdvIGNvZGVzLg0K DQo+IA0KPiAtLS0NCj4gDQo+IFNlY3Rpb24gMy4yDQo+IA0KPiAgICBUaGUgQSBiaXQgYW5kIEIg Yml0IHNldCBNVVNUIE5PVCBib3RoIGJlIHNldCwgb3RoZXJ3aXNlLCBhbiBlY2hvDQo+ICAgIHJl cGx5IHdpdGggdGhlIFJQIHJldHVybiBjb2RlIHNldCB0byAiTWFsZm9ybWVkIFJQIFRMViB3YXMg cmVjZWl2ZWQiDQo+ICAgIFNIT1VMRCBiZSByZXR1cm5lZC4NCj4gDQo+IFdoYXQgb3RoZXIgb3B0 aW9ucyBhcmUgdGhlcmU/IEkuZS4gd2h5ICJTSE9VTEQiIG5vdCAiTVVTVCI/DQoNCkFjdHVhbGx5 LCB0aGVyZSBpcyBubyBvdGhlciBvcHRpb25zLCBNVVNUIHNob3VsZCBiZSBtb3JlIHByZWNpc2Uu DQoNCj4gDQo+IC0tLQ0KPiANCj4gU2VjdGlvbiAzLjINCj4gDQo+IE9MRA0KPiAgICBUaGUgUmVw bHkgUGF0aHMgZmllbGQgaXMgdmFyaWFibGUgaW4gbGVuZ3RoLCBub3QgbW9yZSB0aGFuIG9uZSBz dWItDQo+ICAgIFRMViBNVVNUIGJlIGNhcnJpZWQsIHdoaWNoIGRlc2NyaWJlcyB0aGUgc3BlY2lm aWVkIHBhdGggdGhhdCB0aGUgZWNobw0KPiAgICByZXBseSBtZXNzYWdlIGlzIHJlcXVpcmVkIHRv IGZvbGxvdy4gIFdoZW4gdGhlIFJlcGx5IE1vZGUgZmllbGQgaXMNCj4gICAgc2V0IHRvICJSZXBs eSB2aWEgU3BlY2lmaWVkIFBhdGgiIGluIGFuIExTUCBlY2hvIHJlcXVlc3QgbWVzc2FnZSwgdGhl DQo+ICAgIFJlcGx5IFBhdGggVExWIE1VU1QgYmUgcHJlc2VudC4gIFRoZSBSZXBseSBQYXRoIFRM ViBTSEFMTCBvbmx5IGJlDQo+ICAgIHVzZWQgaW4gdGhlIHJlcGx5IG1vZGUgZGVmaW5lZCBpbiB0 aGlzIGRvY3VtZW50IChSZXBseSB2aWEgU3BlY2lmaWVkDQo+ICAgIFBhdGgpLg0KPiBORVcNCj4g ICAgVGhlIFJlcGx5IFBhdGhzIGZpZWxkIGlzIHZhcmlhYmxlIGluIGxlbmd0aCBhbmQgTVVTVCBj b250YWluIHplcm8gb3INCj4gICAgb25lIHN1Yi1UTFYuICBUaGUgc3ViLVRMViwgaWYgcHJlc2Vu dCwgZGVzY3JpYmVzIHRoZSBzcGVjaWZpZWQgcGF0aA0KPiAgICB0aGF0IHRoZSBlY2hvIHJlcGx5 IG1lc3NhZ2UgaXMgcmVxdWlyZWQgdG8gZm9sbG93Lg0KPiBFTkQNCj4gDQo+IC0tLQ0KPiANCj4g U2VjdGlvbiAzLjINCj4gDQo+ICAgIFdoZW4gdGhlIFJlcGx5IE1vZGUgZmllbGQgaXMgc2V0IHRv ICJSZXBseSB2aWEgU3BlY2lmaWVkIFBhdGgiIGluIGFuDQo+ICAgIExTUCBlY2hvIHJlcXVlc3Qg bWVzc2FnZSwgdGhlIFJlcGx5IFBhdGggVExWIE1VU1QgYmUgcHJlc2VudC4NCj4gDQo+IEkgdGhp bmsgdGhpcyBpcyBhIGR1cGxpY2F0aW9uIG9mIGEgcHJldmlvdXMgc3RhdGVtZW50IGFuZCBjYW4g YmUgcmVtb3ZlZA0KDQpZZXMuDQoNCj4gDQo+IC0tLQ0KPiANCj4gU2VjdGlvbiAzLjINCj4gDQo+ ICAgIFRoZSBSZXBseSBQYXRoIFRMViBTSEFMTCBvbmx5IGJlDQo+ICAgIHVzZWQgaW4gdGhlIHJl cGx5IG1vZGUgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IChSZXBseSB2aWEgU3BlY2lmaWVkDQo+ ICAgIFBhdGgpLg0KPiANCj4gV2h5IGRvIHlvdSBuZWVkIHRoaXM/ICBBbmQgY2FuIGl0IGJlIGVu Zm9yY2VkPw0KPiBJdCBpcyB2ZXJ5IHVudXN1YWwgdG8gcmVzdHJpY3QgdGhlIHVzZSBvZiBpbmZv cm1hdGlvbiBpbiB0aGlzIHdheS4gSQ0KPiB1bmRlcnN0YW5kIHRoYXQgeW91IGRvIG5vdCBoYXZl IGFueSBvdGhlciB1c2UgaW4gbWluZCwgYnV0IGlzIHRoZXJlIGENCj4gbmVlZCB0byBtYWtlIHRo aXMgY29uc3RyYWludC4NCg0KVGhpcyBpcyBmb3IgcmVzb2x2aW5nIG9uZSBsYXN0IGNhbGwgY29t bWVudDogaG93IHRvIGhhbmRsZSB0aGUgc2l0dWF0aW9uIHRoYXQgYSBSZXBseSBQYXRoIFRMViBp cyBjYXJyaWVkIGJ1dCB0aGUgcmVwbHkgbW9kZSBpcyBub3Qgc2V0IHRvIDUsIHRoaXMgc2hvdWxk IG5vdCBiZSBhbGxvd2VkIChpbXBsaWNpdGx5KSBzbyBmYXIgYW5kIHRoZSBlY2hvIHJlcXVlc3Qg c2hvdWxkIGJlIGEgTWFsZm9ybWVkIG1lc3NhZ2UuIA0KDQpJIHBlcnNvbmFsbHkgZG8gbm90IHBy ZWZlciB0byBhZGQgdGhpcyBjb25zdHJhaW50LCBiZWNhdXNlIHdlIGNhbm5vdCBndWFyYW50ZWUg dGhhdCBpdCB3aWxsIG5ldmVyIGJlIHVzZWQgaW4gb3RoZXIgbW9kZXMgaW4gdGhlIGZ1dHVyZS4g SSBhbSBPSyB0byByZW1vdmUgaXQuIA0KDQo+IA0KPiAtLS0NCj4gDQo+IFNlY3Rpb24gMy4zDQo+ IA0KPiAgICBJbiBbUkZDNDM3OV0sIHRoZSByYW5nZSBvZiAzMTc0NC0zMjc2NyBhbmQgNjQ1MTIt NjU1MzUgZm9yIHN1Yi1UTFZzDQo+ICAgIGlzIHNwZWNpZmllZCBmb3IgVmVuZG9yIFByaXZhdGUg VXNlLCBhbmQgTVVTVCBOT1QgYmUgYWxsb2NhdGVkLiAgVGhpcw0KPiAgICBkb2N1bWVudCBjaGFu Z2VzIHRoYXQgcnVsZSB0byBtYWtlIGl0IG5vdCBhcHBsaWNhYmxlIHRvIFJlcGx5IFBhdGgNCj4g ICAgVExWIGFuZCByZWRlZmluZXMgdGhlIHJ1bGUgYXMgaW4gU2VjdGlvbiA2LjIgLiAgSWYgYW4g aW1wbGVtZW50YXRpb24NCj4gICAgcmVjb2duaXplcyBhbnkgc3BlY2lmaWMgVmVuZG9yIFByaXZh dGUgdHlwZXMgYXMgZGVmaW5lZCBpbiBbUkZDNDM3OV0sDQo+ICAgIGFuZCB1c2VzIHRoZSBzdWIt VExWIHR5cGUgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQsIGNhcmUgbXVzdCBiZQ0KPiAgICB0 YWtlbiB0byBlbnN1cmUgdGhhdCB0aGUgaW1wbGVtZW50YXRpb24gZG9lcyBub3QgY29uZnVzZSB0 aGUgdHdvDQo+ICAgIHVzYWdlcy4NCj4gDQo+IEkgZG9uJ3QgdGhpbmsgdGhpcyBkcmFmdCBjaGFu Z2VzIHRoZSByZWdpc3RyeSBmb3IgNDM3OSwgZG9lcyBpdD8NCj4gVGhpcyBuZWVkcyBhIGxpdHRs ZSBtb3JlIGNhcmUgdG8gc2VwYXJhdGUgdGhlIHR3byB1c2VzIGNsZWFybHkuIEhvdw0KPiBhYm91 dC4uLg0KDQpJIHRoaW5rIGl0IGRvZXMgbm90IGNoYW5nZSB0aGUgcmVnaXN0cnkgZm9yIDQzNzks IGJ1dCBpdCBkb2VzIGNoYW5nZXMgcnVsZSB0aGF0IFJGQzQzNzkgc3BlY2lmaWVzIHRvIFRMVnMg YW5kIHN1Yi1UTFZzLiBSRkM0Mzc5IHNwZWNpZmllcyB0aGF0IHRoZSByYW5nZSBvZiAzMTc0NC0z Mjc2NyBhbmQgNjQ1MTItNjU1MzUgZm9yIHN1Yi1UTFZzIGlzIHNwZWNpZmllZCBmb3IgVmVuZG9y IFByaXZhdGUgVXNlLCB0aGlzIGRyYWZ0IGNoYW5nZXMgdGhpcy4gDQoNCkJ1dCBJIGFncmVlIHdp dGggeW91ciBzdWdnZXN0aW9uIGJlbG93IDotKQ0KDQo+IA0KPiBPTEQNCj4gICAgRWFjaCBvZiB0 aGUgRkVDIHN1Yi1UTFZzIChpbmNsdWRlIGV4aXN0aW5nIGFuZCBmdXR1cmUgZGVmaW5lZCkgZm9y DQo+ICAgIHRoZSBUYXJnZXQgRkVDIFN0YWNrIFRMVltSRkM0Mzc5XSBpcyBhcHBsaWNhYmxlIHRv IGJlIGEgc3ViLVRMViBmb3INCj4gICAgaW5jbHVzaW9uIGluIHRoZSBSZXBseSBQYXRoIFRMViBm b3IgZXhwcmVzc2luZyBhIHNwZWNpZmljIHJldHVybg0KPiAgICBwYXRoLiAgRm9yIHRoZXNlIHNo YXJlZCBzdWItVExWcywgdGhleSBzaGFyZSB0aGUgc2FtZSByZWdpc3RyeSB3aXRoDQo+ICAgIHRo ZSBUYXJnZXQgRkVDIFN0YWNrIFRMViBmb3IgdGhlIHJhbmdlIG9mIDAtMzE3NDMgYW5kIDMyNzY4 LTY0NTExLg0KPiANCj4gICAgSW4gYWRkaXRpb24sIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aHJl ZSBuZXcgc3ViLVRMVnM6IElQdjQgUlNWUA0KPiAgICBUdW5uZWwgc3ViLVRMViwgSVB2NiBSU1ZQ IFR1bm5lbCBzdWItVExWIGFuZCBTdGF0aWMgVHVubmVsIHN1Yi1UTFYuDQo+ICAgIFRoZXNlIHN1 Yi1UTFZzIGFyZSBvbmx5IGRlc2lnbmVkIGZvciBSZXBseSBQYXRoIFRMViwgaGVuY2UgdGhpcw0K PiAgICBkb2N1bWVudCBjYWxscyB0aGVtIGRlZGljYXRlZCBzdWItVExWcyB0byBSZXBseSBQYXRo IFRMVi4gIEZvciB0aGVzZQ0KPiAgICBkZWRpY2F0ZWQgc3ViLVRMVnMsIHRoaXMgZG9jdW1lbnQg d2lsbCBjcmVhdGUgYSBuZXcgcmVnaXN0cnkgKFNlY3Rpb24NCj4gICAgNi4xKSwgdGhlIHN1Yi1U TFYgdHlwZSBNVVNUIGJlIGFsbG9jYXRlZCBmcm9tIHRoZSBuZXcgcmVnaXN0cnkuDQo+ICAgIERl dGFpbGVkIGRlZmluaXRpb24gaXMgaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucy4NCj4gDQo+ICAg IEluIFtSRkM0Mzc5XSwgdGhlIHJhbmdlIG9mIDMxNzQ0LTMyNzY3IGFuZCA2NDUxMi02NTUzNSBm b3Igc3ViLVRMVnMNCj4gICAgaXMgc3BlY2lmaWVkIGZvciBWZW5kb3IgUHJpdmF0ZSBVc2UsIGFu ZCBNVVNUIE5PVCBiZSBhbGxvY2F0ZWQuICBUaGlzDQo+ICAgIGRvY3VtZW50IGNoYW5nZXMgdGhh dCBydWxlIHRvIG1ha2UgaXQgbm90IGFwcGxpY2FibGUgdG8gUmVwbHkgUGF0aA0KPiAgICBUTFYg YW5kIHJlZGVmaW5lcyB0aGUgcnVsZSBhcyBpbiBTZWN0aW9uIDYuMiAuICBJZiBhbiBpbXBsZW1l bnRhdGlvbg0KPiAgICByZWNvZ25pemVzIGFueSBzcGVjaWZpYyBWZW5kb3IgUHJpdmF0ZSB0eXBl cyBhcyBkZWZpbmVkIGluIFtSRkM0Mzc5XSwNCj4gICAgYW5kIHVzZXMgdGhlIHN1Yi1UTFYgdHlw ZSBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCwgY2FyZSBtdXN0IGJlDQo+ICAgIHRha2VuIHRv IGVuc3VyZSB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBjb25mdXNlIHRoZSB0d28N Cj4gICAgdXNhZ2VzLg0KPiBORVcNCj4gICAgVGhlIEZFQ3MgZGVmaW5lZCBpbiBbUkZDNDM3OV0g cHJvdmlkZSBhIGdvb2Qgd2F5IHRvIGlkZW50aWZ5IGENCj4gICAgc3BlY2lmaWMgcmV0dXJuIHBh dGguICBUaGUgRkVDIHN1Yi1UTFZzIChpbmNsdWRpbmcgZXhpc3RpbmcgYW5kDQo+ICAgIGZ1dHVy ZSBzdWItVExWcykgb2YgdGhlIFRhcmdldCBGRUMgU3RhY2sgVExWIFtSRkM0Mzc5XSBoYXZlIHN1 Yi1UTFYNCj4gICAgdHlwZXMgYXNzaWduZWQgZnJvbSBhIHJlZ2lzdHJ5IHdpdGggcmFuZ2VzIGFz IGZvbGxvd3M6DQo+IA0KPiAgICAgICAwLTE2MzgzICAgICAgIFN0YW5kYXJkcyBBY3Rpb24gbWFu ZGF0b3J5IFRMVg0KPiAgICAgICAxNjM4NC0zMTc0MyAgIFNwZWNpZmljYXRpb24gUmVxdWlyZWQs IEV4cGVyaW1lbnRhbCBSRkMgbmVlZGVkDQo+ICAgICAgIDMxNzQ0LTMyNzY3ICAgVmVuZG9yIFBy aXZhdGUgVXNlLCBNVVNUIE5PVCBiZSBhbGxvY2F0ZWQNCj4gICAgICAgMzI3NjgtNDkxNjEgICBT dGFuZGFyZHMgQWN0aW9uIG9wdGlvbmFsIFRMVg0KPiAgICAgICA0OTE2Mi02NDUxMSAgIFNwZWNp ZmljYXRpb24gUmVxdWlyZWQsIEV4cGVyaW1lbnRhbCBSRkMgbmVlZGVkDQo+ICAgICAgIDY0NTEy LTY1NTM1ICAgVmVuZG9yIFByaXZhdGUgVXNlLCBNVVNUIE5PVCBiZSBhbGxvY2F0ZWQNCj4gDQo+ ICAgIFRoZSBSZXBseSBQYXRoIFRMViBjYW4gY2FycnkgYW5kIHN1Yi1UTFYgZGVmaW5lZCBmb3Ig dXNlIGluIHRoZQ0KDQoNClNob3VsZCB0aGUgImNhcnJ5IGFuZCBzdWItVExWIiBiZSAiY2Fycnkg dGhlIHN1Yi1UTFYiPw0KDQo+ICAgIFRhcmdldCBGRUMgU3RhY2sgVExWIHRoYXQgY2FuIGJlIHJl Z2lzdGVyZWQuICBUaHVzIHRoZSByYW5nZXMNCj4gICAgMC0zMTc0MyBhbmQgMzI3NjgtNjQ1MTEg YXJlIHNoYXJlZCBieSB0aGUgcmVnaXN0cmllcywgd2l0aCB0aGUgbmV3DQo+ICAgIFJlcGx5IFBh dGggU3ViLVRMVnMgcmVnaXN0cnkgImJvcnJvd2luZyIgdmFsdWVzIGZyb20gdGhlIFRhcmdldCBG RUMNCj4gICAgU3RhY2sgVExWIHJlZ2lzdHJ5Lg0KPiANCj4gICAgQWxsb2NhdGlvbnMgZnJvbSB0 aGUgcmFuZ2VzIDMxNzQ0LTMyNzY3IGFuZCA2NDUxMi02NTUzNSBhcmUgbm90DQo+ICAgIHJlY29y ZGVkIGluIHRoZSByZWdpc3RyeSBmb3IgVGFyZ2V0IEZFQyBTdGFjayBUTFZzLCBzbyB0aGVzZSBy YW5nZXMNCj4gICAgYXJlIHNhZmVseSBtYWRlIGF2YWlsYWJsZSBpbiB0aGUgUmVwbHkgUGF0aCBT dWItVExWcyByZWdpc3RyeSAoc2VlDQo+ICAgIFNlY3Rpb24gNi4xKSB0byByZWNvcmQgc3ViLVRM VnMgdGhhdCBhcmUgc3BlY2lmaWMgdG8gdGhlIFJlcGx5IFBhdGgNCj4gICAgVExWLiAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIHRocmVlIHN1Yi1UTFZzIHNwZWNpZmljIHRvIHRoZSBSZXBseSBQYXRo DQo+ICAgIFRMVjogSVB2NCBSU1ZQIFR1bm5lbCBzdWItVExWLCBJUHY2IFJTVlAgVHVubmVsIHN1 Yi1UTFYsIGFuZCBTdGF0aWMNCj4gICAgVHVubmVsIHN1Yi1UTFYuDQo+IA0KPiAgICBOb3RlIHRo YXQgYW4gaW1wbGVtZW50YXRpb24gdGhhdCBzdXBwb3J0cyBzcGVjaWZpYyBWZW5kb3IgUHJpdmF0 ZQ0KPiAgICBmb3Igc3ViLVRMVnMgb2YgdGhlIFRhcmdldCBGRUMgU3RhY2sgbXVzdCB0YWtlIGNh cmUgdG8gbm90IGNvbmZ1c2UNCj4gICAgdGhvc2UgdmFsdWVzIHdpdGggdGhlIHNhbWUgdmFsdWVz IGFsbG9jYXRlZCBmcm9tIHRoZSBSZXBseSBQYXRoIFN1Yi0NCj4gICAgVExWcyByZWdpc3RyeS4N Cj4gRU5EDQo+IA0KPiAtLS0NCj4gDQo+IFNlY3Rpb24gMy4zDQo+IA0KPiAgICAyLiAgU3BlY2lm eSBhIG1vcmUgZ2VuZXJpYyB0dW5uZWwgRkVDIGFzIHJldHVybiBwYXRoDQo+IA0KPiBJdCBpcyBj bGVhciB0aGF0IDMuMy4xIGFuZCAzLjMuMiBkZWZpbmUgYSBGRUMgdGhhdCBpcyBtb3JlIGdlbmVy YWwgdGhhbg0KPiB0aGUgRkVDcyBpbiA0Mzc5LiBXaGF0IGlzIG5vdCBjbGVhciBpcyB0aGUgdXNl IGNhc2UuIEkgdGhpbmsgeW91IG5lZWQNCj4gc29tZSB0ZXh0IGluIHRoaXMgZG9jdW1lbnQgdG8g c2F5IHdoYXQgeW91IHNob3VsZCBkbyB3aXRoIG9uZSBvZiB0aGVzZQ0KPiBGRUNzIHNpbmNlIGl0 IHBvc3NpYmx5IGlkZW50aWZpZXMgYSBzZXQgb2YgTFNQcy4NCg0KVGhlcmUgaXMgYW5vdGhlciBk cmFmdCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1tcGxzLWJmZC1lbmhh bmNlbWVudC0wMCNzZWN0aW9uLTQuMiApIGRpc2N1c3NlcyB0aGUgdXNhZ2Ugb2YgdGhlIGdlbmVy aWMgVHVubmVsIHN1Yi1UTFYuIEhvdyBhYm91dCBhZGQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQpP bmUgdXNhZ2Ugb2YgdGhpcyBnZW5lcmljIFJTVlAgVHVubmVsIHN1Yi1UTFYgaXMgZm9yIGJvb3Rz dHJhcHBpbmcgQkZEIHNlc3Npb24gb24gYW4gTVBMUyBUdW5uZWwgdGhhdCBoYXMgcHJpbWFyeSBh bmQgc2Vjb25kYXJ5IExTUHMsIGVzcGVjaWFsbHkgd2hlbiBNYWtlLUJlZm9yZS1CcmVhayAoTUJC KSBpcyBkZXBsb3llZC4gVGhlIHVzYWdlIGlzIGRpc2N1c3NlZCBpbiB0aGUgU2VjdGlvbiA0LjIg b2YgW0ktRC5jaGVuLW1wbHMtYmZkLWVuaGFuY2VtZW50XS4NCg0KPiANCj4gLS0tDQo+IA0KPiBT ZWN0aW9uIDMuMy4xDQo+IA0KPiBPTEQNCj4gICAgVGhlIElQdjQgUlNWUCBUdW5uZWwgc3ViLVRM ViBUeXBlIGZpZWxkIGlzIDIgb2N0ZXRzIGluIGxlbmd0aCwgYW5kDQo+ICAgIHRoZSByZWNvbW1l bmRlZCB0eXBlIHZhbHVlIGlzIFRCRC4NCj4gTkVXDQo+ICAgIFRoZSBJUHY0IFJTVlAgVHVubmVs IHN1Yi1UTFYgVHlwZSBmaWVsZCBpcyAyIG9jdGV0cyBpbiBsZW5ndGgsIGFuZA0KPiAgICB0aGUg cmVjb21tZW5kZWQgdHlwZSB2YWx1ZSBpcyBUQkQxLg0KPiBFTkQNCg0KT0suDQoNCj4gDQo+IC0t LQ0KPiANCj4gU2VjdGlvbiAzLjMuMQ0KPiANCj4gSXQgaXMgc2xpZ2h0bHkgd2VpcmQgdGhhdCB0 aGUgYml0IGZpZWxkIGluIHRoaXMgc2VjdGlvbiBhbGxvY2F0ZXMgdGhlDQo+IGZpcnN0IHR3byBi aXRzIHdoaWxlIHRoZSBmaWVsZCBpbiBzZWN0aW9uIDMuMiBhbGxvY2F0ZXMgdGhlIGxhc3QgdHdv DQo+IGJpdHMuICBUaGlzIGlzIG5vdCBzaWduaWZpY2FudGx5IGltcG9ydGFudCwgYnV0IGlzIG9k ZC4NCg0KV2lsbCBjaGFuZ2UgaXQgYW5kIG1ha2UgdGhlbSBjb25zaXN0ZW50LiANCj4gDQo+IC0t LQ0KPiANCj4gU2VjdGlvbiAzLjMuMg0KPiANCj4gT0xEDQo+ICAgIFRoZSBJUHY2IFJTVlAgVHVu bmVsIHN1Yi1UTFYgVHlwZSBmaWVsZCBpcyAyIG9jdGV0cyBpbiBsZW5ndGgsIGFuZA0KPiAgICB0 aGUgdHlwZSB2YWx1ZSBpcyBUQkQuDQo+IE5FVw0KPiAgICBUaGUgSVB2NiBSU1ZQIFR1bm5lbCBz dWItVExWIFR5cGUgZmllbGQgaXMgMiBvY3RldHMgaW4gbGVuZ3RoLCBhbmQNCj4gICAgdGhlIHR5 cGUgdmFsdWUgaXMgVEJEMi4NCj4gRU5EDQoNCk9LLg0KDQo+IA0KPiAtLS0NCj4gDQo+IFNlY3Rp b24gMy4zLjMNCj4gDQo+IFJGQyA2MzcwIHNlZW1zIHRvIGFsc28gaW5jbHVkZSBhbiAiTFNQX051 bSIuIFNvIHlvdXIgMy4zLjMgY2FzZSBpcyB0aGUNCj4gTVBMUy1UUCBzdGF0aWMgZXF1aXZhbGVu dCBvZiAzLjMuMS4gQnV0IHlvdSBhcmUgbWlzc2luZzoNCj4gDQo+IC0gdGhlIE1QTFMtVFAgc3Rh dGljIGVxdWl2YWxlbnQgb2YgMy4zLjIgKGkuZS4gdjYgaWRlbnRpZmllcnMpDQo+IC0gdGhlIE1Q TFMtVFAgZXF1aXZhbGVudCBvZiB0aGUgNDM3OSBSU1ZQIExTUCBGRUNzDQo+IA0KPiBEbyB5b3Ug bmVlZCB0aGVtPw0KDQpObywgd2UgZG8gbm90IG5lZWQgdGhlbSwgTVBMUy1UUCBoYXMgbm90IHY2 IGlkZW50aWZpZXJzLCBhbmQgdGhlIE1QTFMtVFAgZXF1aXZhbGVudCBvZiB0aGUgNDM3OSBSU1ZQ IExTUCBGRUNzIGJlbG9uZ3MgdG8gdGhlIGV4aXN0aW5nIHN1Yi1UTFZzIG9mIFRhcmdldCBGRUMg VExWIGFuZCBhcmUgYWxyZWFkeSBkZWZpbmVkIGluIFRQIHJlbGF0ZWQgUkZDLg0KDQo+IA0KPiAt LS0NCj4gDQo+IFNlY3Rpb24gMy4zLjMNCj4gDQo+IE9MRA0KPiAgICBUaGUgc3ViLVRMViB0eXBl IHZhbHVlIGlzIFRCRC4NCj4gTkVXDQo+ICAgIFRoZSBzdWItVExWIHR5cGUgdmFsdWUgaXMgVEJE My4NCj4gRU5EDQo+IA0KT0suDQoNCj4gLS0tDQo+IA0KPiBTZWN0aW9uIDMuNA0KPiANCj4gT0xE DQo+ICAgIFRoZSBSZXBseSBUQyBUTFYgVHlwZSBmaWVsZCBpcyAyIG9jdGV0cyBpbiBsZW5ndGgs IGFuZCB0aGUgdHlwZSB2YWx1ZQ0KPiAgICBpcyBUQkQuDQo+IE5FVw0KPiAgICBUaGUgUmVwbHkg VEMgVExWIFR5cGUgZmllbGQgaXMgMiBvY3RldHMgaW4gbGVuZ3RoLCBhbmQgdGhlIHR5cGUgdmFs dWUNCj4gICAgaXMgVEJENC4NCj4gRU5EDQo+IA0KDQpPSy4NCg0KPiAtLS0NCj4gDQo+IFNlY3Rp b24gNA0KPiANCj4gICAgVGhlIHByb2NlZHVyZXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGN1 cnJlbnRseSBvbmx5IGFwcGx5IHRvDQo+ICAgICJwaW5nIiBtb2RlLiAgVGhlICJ0cmFjZXJvdXRl IiBtb2RlIGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcw0KPiAgICBkb2N1bWVudC4NCj4gDQo+IEkg dGhpbmsgdGhpcyBzaG91bGQgc2hvdyB1cCBpbiB0aGUgSW50cm9kdWN0aW9uIGFuZCBwb3NzaWJs eSB0aGUNCj4gQWJzdHJhY3QuDQoNCk9LLg0KDQo+IA0KPiAtLS0NCj4gDQo+IFNlY3Rpb24gNg0K PiANCj4gUGxlYXNlIGNvbnNpZGVyIHdoZXRoZXIgeW91IHdhbnQgcmVnaXN0cmllcyBmb3IgdGhl IGJpdCBmaWVsZHMgeW91DQo+IGRlZmluZSBpbiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gLS0tDQo+ IA0KPiBTZWN0aW9uIDYuMQ0KPiANCj4gT0xEDQo+ICAgIFRCRCAgICAgUmVwbHkgVEMgVExWICAg ICAgICAgICAgICAgICAgICAgIHRoaXMgZG9jdW1lbnQgKHNlY3QgMy40KQ0KPiBORVcNCj4gICAg VEJENCAgICBSZXBseSBUQyBUTFYgICAgICAgICAgICAgICAgICAgICAgdGhpcyBkb2N1bWVudCAo c2VjdCAzLjQpDQo+IEVORA0KPiANCk9LDQoNCj4gLS0tDQo+IA0KPiBTZWN0aW9uIDYuNA0KPiAN Cj4gT0xEDQo+ICAgIFRCRCAgICAgUmVwbHkgVEMgVExWICAgICAgICAgICAgICAgICAgICAgIHRo aXMgZG9jdW1lbnQgKHNlY3QgMy40KQ0KPiBORVcNCj4gICAgVEJENCAgICBSZXBseSBUQyBUTFYg ICAgICAgICAgICAgICAgICAgICAgdGhpcyBkb2N1bWVudCAoc2VjdCAzLjQpDQo+IEVORA0KPiAN Ck9LLg0KDQo+IC0tLQ0KPiANCj4gU2VjdGlvbiA2LjIuMQ0KPiANCj4gT0xEDQo+ICAgIFN1Yi10 eXBlICAgICAgVmFsdWUgRmllbGQgICAgICAgICAgICAgUmVmZXJlbmNlDQo+ICAgIC0tLS0tLS0g ICAgICAgLS0tLS0tLS0tLS0gICAgICAgICAgICAgLS0tLS0tLS0tDQo+ICAgIFRCRCAgICAgICAg ICAgSVB2NCBSU1ZQIFR1bm5lbCAgICAgICAgdGhpcyBkb2N1bWVudCAoc2VjdCAzLjMuMSkNCj4g ICAgVEJEICAgICAgICAgICBJUHY2IFJTVlAgVHVubmVsICAgICAgICB0aGlzIGRvY3VtZW50IChz ZWN0IDMuMy4yKQ0KPiAgICBUQkQgICAgICAgICAgIFN0YXRpYyBUdW5uZWwgICAgICAgICAgIHRo aXMgZG9jdW1lbnQgKHNlY3QgMy4zLjMpDQo+IE5FVw0KPiAgICBTdWItdHlwZSAgICAgIFZhbHVl IEZpZWxkICAgICAgICAgICAgIFJlZmVyZW5jZQ0KPiAgICAtLS0tLS0tICAgICAgIC0tLS0tLS0t LS0tICAgICAgICAgICAgIC0tLS0tLS0tLQ0KPiAgICBUQkQxICAgICAgICAgIElQdjQgUlNWUCBU dW5uZWwgICAgICAgIHRoaXMgZG9jdW1lbnQgKHNlY3QgMy4zLjEpDQo+ICAgIFRCRDIgICAgICAg ICAgSVB2NiBSU1ZQIFR1bm5lbCAgICAgICAgdGhpcyBkb2N1bWVudCAoc2VjdCAzLjMuMikNCj4g ICAgVEJEMyAgICAgICAgICBTdGF0aWMgVHVubmVsICAgICAgICAgICB0aGlzIGRvY3VtZW50IChz ZWN0IDMuMy4zKQ0KPiBFTkQNCj4gDQo+IC0tLQ0KPiANCj4gU2VjdGlvbiA2LjMNCj4gDQo+IE9M RA0KPiAgICBJQU5BIGlzIG5vdyByZXF1ZXN0ZWQgdG8gYXNzaWduIHRoZSBwcmV2aW91c2x5IGFz c2lnbmVkIGEgbmV3IHJlcGx5DQo+ICAgIG1vZGUgY29kZSBwb2ludCAoNSAtIFJlcGx5IHZpYSBz cGVjaWZpZWQgcGF0aCkgZnJvbSB0aGUgIk11bHRpLQ0KPiAgICBQcm90b2NvbCBMYWJlbCBTd2l0 Y2hpbmcgKE1QTFMpIExhYmVsIFN3aXRjaGVkIFBhdGhzIChMU1BzKSBQaW5nDQo+ICAgIFBhcmFt ZXRlcnMiIHJlZ2lzdHJ5LCB0aGUgIlJlcGx5IE1vZGUiIHN1Yi1yZWdpc3RyeSBvbiBhIHBlcm1h bmVudA0KPiAgICBiYXNpcy4NCj4gTkVXDQo+ICAgIElBTkEgaGFzIG1hZGUgYW4gZWFybHkgYWxs b2NhdGlvbiAoNSAtIFJlcGx5IHZpYSBzcGVjaWZpZWQgcGF0aCkgZnJvbQ0KPiAgICB0aGUgIk11 bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykgTGFiZWwgU3dpdGNoZWQgUGF0aHMN Cj4gICAgKExTUHMpIFBpbmcgUGFyYW1ldGVycyIgcmVnaXN0cnksIHRoZSAiUmVwbHkgTW9kZSIg c3ViLXJlZ2lzdHJ5LiBJQU5BDQo+ICAgIGlzIHJlcXVlc3RlZCB0byBtYWtlIHRoaXMgYWxsb2Nh dGlvbiBwZXJtYW5lbnQuDQo+IEVORA0KDQpPSy4NCg0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBs c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cg== From wim.henderickx@alcatel-lucent.com Thu Oct 18 02:52:40 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5378C21F85C0 for ; Thu, 18 Oct 2012 02:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.768 X-Spam-Level: X-Spam-Status: No, score=-9.768 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XogAB7a8nrxe for ; Thu, 18 Oct 2012 02:52:39 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 48A2A21F85A8 for ; Thu, 18 Oct 2012 02:52:39 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q9I9n0NN026692 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Oct 2012 11:52:34 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 18 Oct 2012 11:51:58 +0200 From: "Henderickx, Wim (Wim)" To: Ryan Zheng Date: Thu, 18 Oct 2012 11:50:58 +0200 Thread-Topic: draft-zjns-mpls-lsp-ping-relay-reply Thread-Index: Ac2sSGFFUV9OsO4HTUmH3LEatCEfcQAzZ+CA Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702E1E2AB8A@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E1D82C8D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <201210170918.q9H9IBnM073031@mse02.zte.com.cn> In-Reply-To: <201210170918.q9H9IBnM073031@mse02.zte.com.cn> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D6702E1E2AB8AFRMRSSXCHMBSB_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "'mpls@ietf.org'" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] draft-zjns-mpls-lsp-ping-relay-reply X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 09:52:40 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D6702E1E2AB8AFRMRSSXCHMBSB_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Ryan, thx this indeed addresses the topics I highlighted. Please include th= em in the next revision From: Ryan Zheng [mailto:zheng.zhi@zte.com.cn] Sent: woensdag 17 oktober 2012 11:14 To: Henderickx, Wim (Wim) Cc: lizhong.jin@zte.com.cn; 'mpls@ietf.org'; swallow@cisco.com; tnadeau@jun= iper.net Subject: Re: draft-zjns-mpls-lsp-ping-relay-reply Hi Wim, Thank you for the detailed review and insightful comments. Please see inlin= e below. Best Regards, Ryan "Henderickx, Wim (Wim)" wrote on 2012-1= 0-15 01:04:03: > I have been asked to review the above draft as one of the reviewers. > > The doc is useful in certain MPLS scenario's as described in the > draft. It could be considered to be adopted as a WG doc. > > Here are some comments which would make the draft more sound. > 1. Describe the behavior for devices that did not implement the > additional TLVs. How would they behave. Yes, some description should be added to make the behavior much clear= . The devices that did not implement the additional TLVs should set the ret= urn code of 2 ("One or more of the TLVs was not understood") in the respons= e according to section 3 of RFC 4379. A suggested value will be given in IA= NA Consideration section of next version. > 2. Describe the behavior if the packet length would be exceeded by > the Relay Node Address Stack TLV Good suggestion. IMO, in most cases, the packet length would not be e= xceeded by the Relay Node Address Stack TLV, thanks to the TLV procedures i= n each replying LSR described in section 4.2. That is the replying LSR woul= d check the addresses of the stack in the sequence from top to bottom, to f= ind out the first routable IP address. Then those address entried behind of= the first routable IP address in the address list with K bit set to 0 woul= d be deleted, and the address entry of replying LSR would be added. That me= ans the addresses stack would be kept optimized by every replying LSR durin= g traceroute process, and only those routable relay node addresses would be= kept in the TLV, not all node addresses=1B$B!#=1B(B If the packet length was exceeded by the Relay Node Address Stack TLV unexp= ectablly, the TLV would be dropped and a new return code would help to noti= fy the initiator of the situation. The case will be addressed in the next v= ersion. > 3. Give an example in the text for the inter-AS and seamless MPLS > scenario how the different devices behave with a use case OK. Will do. > 4. Describe in which scenarios this is applicable: mainly transport > MPLS, but not in IP-VPN or L2-VPN scenarios Yes, correct. Hope the reply above addresses your concerns. Thank you. --_000_14C7F4F06DB5814AB0DE29716C4F6D6702E1E2AB8AFRMRSSXCHMBSB_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Ryan, thx= this indeed addresses the topics I highlighted. Please include them in the= next revision

 =

From: Ryan Zheng [mailto:zheng= .zhi@zte.com.cn]
Sent: woensdag 17 oktober 2012 11:14
To:<= /b> Henderickx, Wim (Wim)
Cc: lizhong.jin@zte.com.cn; 'mpls@ietf.= org'; swallow@cisco.com; tnadeau@juniper.net
Subject: Re: draft-z= jns-mpls-lsp-ping-relay-reply

 


Hi Wim,

<= tt>Thank you for the detailed review and insightful comments. Please see in= line below.

Best Regards,
Ryan

<= br>"Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.= com> wrote on 2012-10-15 01:04:03:

> I have been aske= d to review the above draft as one of the reviewers.
> =
> The doc is useful in certain MPLS scenario's as described in t= he
> draft. It could be considered to be adopted as a WG do= c.
>
> Here are some comments which would ma= ke the draft more sound.
> 1. Describe the behavior for devi= ces that did not implement the
> additional TLVs. How would= they behave.
<Ryan>Yes, some description should be adde= d to make the behavior much clear. The devices that did not implement the a= dditional TLVs should set the return code of 2 ("One or more of the TL= Vs was not understood") in the response according to section 3 of RFC = 4379. A suggested value will be given in IANA Consideration section of next= version.

> 2. Describe the behavior if the packet leng= th would be exceeded by
> the Relay Node Address Stack TLV<= /tt>
<Ryan>Good suggestion. IMO, in most cases, the packet le= ngth would not be exceeded by the Relay Node Address Stack TLV, thanks to t= he TLV procedures in each replying LSR described in section 4.2. That is th= e replying LSR would check the addresses of the stack in the sequence from = top to bottom, to find out the first routable IP address. Then those addres= s entried behind of the first routable IP address in the address list with = K bit set to 0 would be deleted, and the address entry of replying LSR woul= d be added. That means the addresses stack would be kept optimized by every= replying LSR during traceroute process, and only those routable relay node= addresses would be kept in the TLV, not all node addresses=1B$B!#=1B(J

If the packet length was exceeded b= y the Relay Node Address Stack TLV unexpectablly, the TLV would be dropped = and a new return code would help to notify the initiator of the situation. = The case will be addressed in the next version.

> 3. Gi= ve an example in the text for the inter-AS and seamless MPLS
&= gt; scenario how the different devices behave with a use case
= <Ryan>OK. Will do.

> 4. Describe in which scenari= os this is applicable: mainly transport
> MPLS, but not in = IP-VPN or L2-VPN scenarios
<Ryan>Yes, correct.
=
Hope the reply above addresses your concerns. Thank you.<= /o:p>

= --_000_14C7F4F06DB5814AB0DE29716C4F6D6702E1E2AB8AFRMRSSXCHMBSB_-- From skraza@cisco.com Thu Oct 18 09:26:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E82521F881E for ; Thu, 18 Oct 2012 09:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6zh9QIufhXq for ; Thu, 18 Oct 2012 09:26:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D5CF321F8741 for ; Thu, 18 Oct 2012 09:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1294; q=dns/txt; s=iport; t=1350577612; x=1351787212; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rhvRwKI4kbBsXTpt1M4gDmRz0i9rx+bXajApABEw3oA=; b=hHzjOGjUkdk7JEoVqxIEbKM+Jvj6BboEcaBYE2JPBGTxwmJnFi4hVoD8 ePoG9cYZoBWkt7yVa4yc9YkgVvFQJPnxaJmlO6wnr/FkkYVlZwB+p4+6V uK5+Ot0yu5FIGMUfSdH89GReftuqT5ibq3hW+eEa/vxNHC7Bt0Lmn7LHB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ0tgFCtJV2Z/2dsb2JhbABFwEqBCIIiAQQBAQEPASc0Cw4EAQgiFAUmDAslAgQBDQUIGodiC5xcoDoEi1SFYmADlwCNNIFrgm+BYzQ X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="130087419" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 18 Oct 2012 16:26:41 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9IGQeFA018818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 16:26:40 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 11:26:40 -0500 From: "Kamran Raza (skraza)" To: Loa Andersson , "mpls@ietf.org" , "Martin Vigoureux" , "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" Thread-Topic: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document Thread-Index: AQHNrQH8EcpFK08KlEqq/UotTzorspe/YikA Date: Thu, 18 Oct 2012 16:26:39 +0000 Message-ID: In-Reply-To: <507FAF2D.5020907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.245.134] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--31.172500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:26:53 -0000 Support. On 12-10-18 3:26 AM, "Loa Andersson" wrote: >Working group, > >this is to start a two week poll on adopting >draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-09 >as an MPLS working group document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls at ietf.org). Please give an technical >motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document. > >This poll ends November 07, 2012. > >There is one IPR claim against this document - >http://datatracker.ietf.org/ipr/1861/ . > >All the co-authors has stated on the mailing list that they are not >aware of any other IPR claims than those already disclosed. >If there are IPR claims from any other party, please remember that the >IPR is open. > >/Loa >(mpls wg co-chair) >--=20 > > >Loa Andersson email: loa.andersson@ericsson.com >Sr Strategy and Standards Manager loa@pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From ietfc@btconnect.com Thu Oct 18 09:37:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D41221F8724 for ; Thu, 18 Oct 2012 09:37:18 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char B4 hex): Subject: Re: [mpls] \264\360\270\264: AD review[...] X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-2.280, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SUBJECT_NEEDS_ENCODING=0.001, SUBJ_ILLEGAL_CHARS=1.586] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1RfrQHUppun for ; Thu, 18 Oct 2012 09:37:17 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id A902E21F8720 for ; Thu, 18 Oct 2012 09:37:16 -0700 (PDT) Received: from mail219-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.23; Thu, 18 Oct 2012 16:37:15 +0000 Received: from mail219-co1 (localhost [127.0.0.1]) by mail219-co1-R.bigfish.com (Postfix) with ESMTP id 23ADEB80205; Thu, 18 Oct 2012 16:37:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: PS-37(z5109hz9371Ic89bh1102I542Mec9Q1432I1418I1a09J1447Izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h941hd24hf0ah107ah1177h1179h1269h1288h12a5h12a9h12bdh12e1h137ah139eh13b6h1441h304l1155h) Received: from mail219-co1 (localhost.localdomain [127.0.0.1]) by mail219-co1 (MessageSwitch) id 1350578233404849_9759; Thu, 18 Oct 2012 16:37:13 +0000 (UTC) Received: from CO1EHSMHS018.bigfish.com (unknown [10.243.78.232]) by mail219-co1.bigfish.com (Postfix) with ESMTP id 603E4240044; Thu, 18 Oct 2012 16:37:13 +0000 (UTC) Received: from DB3PRD0710HT003.eurprd07.prod.outlook.com (157.56.253.85) by CO1EHSMHS018.bigfish.com (10.243.66.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 18 Oct 2012 16:37:10 +0000 Received: from AMXPRD0410HT002.eurprd04.prod.outlook.com (157.56.248.165) by pod51017.outlook.com (10.255.75.38) with Microsoft SMTP Server (TLS) id 14.16.224.5; Thu, 18 Oct 2012 16:37:06 +0000 Message-ID: <000401cdad4e$c7b080a0$4001a8c0@gateway.2wire.net> From: t.petch To: Mach Chen , , References: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> Subject: Re: [mpls] ´ð¸´: AD review of draft-ietf-mpls-return-path-specified-lsp-ping Date: Thu, 18 Oct 2012 16:05:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.165] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:37:18 -0000 Last November, I commented "In retrospect, RFC4379 should have split the sub-TLV range into common to all TLV, and TLV-unique, which, in effect, is what my idea on 1024 is, post factum. I would expect others to comment on this as and when they realise what it says, so I would leave it for a while and see what comes up." and I think that this has now come up. Adrian says below "> I think it does not change the registry for 4379, but it does changes rule that RFC4379 specifies to TLVs and sub-TLVs." and proposes that what in RFC4379 is "The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the range 0-16383 and 32768-49161 are made via Standards Action as defined in [IANA]; assignments in the range 16384-31743 and 49162-64511 are made via "Specification Required" as defined above; values in the range 31744-32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be allocated." becomes "> > 0-16383 Standards Action mandatory TLV > > 16384-31743 Specification Required, Experimental RFC needed > > 31744-32767 Vendor Private Use, MUST NOT be allocated > > 32768-49161 Standards Action optional TLV > > 49162-64511 Specification Required, Experimental RFC needed > > 64512-65535 Vendor Private Use, MUST NOT be allocated" which a) seems to me to be not quite the same ie updates RFC4379 b) does not seem to solve the problem (and there is no reference for RFC5226, but then that is usual for an MPLS-TP RFC:-( Tom Petch ----- Original Message ----- From: "Mach Chen" To: ; Cc: ; Sent: Thursday, October 18, 2012 9:55 AM > Adrian, > > Many thanks for your detail review and comments! > > Please see my response inline... > > Best regards, > Mach > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.o= rg] =B4=FA=B1=ED Adrian > > Farrel > > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA10=D4=C218=C8=D5 4:35 > > =CA=D5=BC=FE=C8=CB: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org > > =B3=AD=CB=CD: mpls@ietf.org; mpls-chairs@tools.ietf.org > > =D6=F7=CC=E2: [mpls] AD review of draft-ietf-mpls-return-path-specified-lsp-ping > > > > Hi, > > > > I've done my usual AD review of your draft prior to issuing IETF last > > call and passing the I-D for IESG evaluation. The main purpose of the > > review is to catch issues that might come up in later reviews and to > > ensure that the document is ready for publication as and RFC. > > > > I found Section 4 very good. It completely explains to me what is > > going on in the protocol extension, and covered all the corner cases > > I could think of. On the other hand, Section 3 made me generate a > > really (really, really) long list of relatively minor issues. This > > list is so long that I think you need to provide a new revision > > before we issue the IETF last call. I will put the I-D into "Revised > > I-D Needed" state and wait for the revision. > > > > As always, all my comments are up for discussion and negotiation. > > > > Thanks for the work, > > Adrian > > > > =3D=3D=3D > > > > Consistency of references for bidirectional LSP. In Section 1 you have > > In this document, term bidirectional LSP includes the co-routed > > bidirectional LSP defined in [RFC3945] > > In Section 2 you have: > > The co-routed bidirectional LSP is defined in [RFC3471] > > and [RFC3473] > > > OK, will consistently refer to [RFC3945] instead. > > > --- > > > > Section 1 > > s/(BFD)[RFC5880], [RFC5884]session/(BFD) [RFC5880], [RFC5884] session/ > > s/In this document, term bidirectional LSP/In this document, the term > > bidirectional LSP/ > > OK. > > > > > --- > > > > Section 3.1 > > > > OLD > > The recommended value of the Reply via Specified Path mode is 5 (This > > is to be confirmed by the IANA). > > > > Value Meaning > > ----- ------- > > 5 Reply via Specified Path > > NEW > > The value of the Reply via Specified Path mode is 5 (This has been > > allocated by IANA using early allocation and is to be confirmed by > > IANA). > > > > Value Meaning > > ----- ------- > > 5 Reply via Specified Path > > END > > OK. > > > > > --- > > > > Section 3.2 > > > > OLD > > The Reply Path (RP) TLV is an optional TLV, if the Reply via > > Specified Path mode requested, the Reply Path (RP) TLV MUST be > > included in an echo request message. It carries the specified return > > paths that the echo reply message is required to follow. The format > > of Reply Path TLV is as follows: > > > > NEW > > The Reply Path (RP) TLV is an optional TLV within the LSP Ping > > protocol. However, if the Reply via Specified Path mode requested as > > described in Section 3.1, the Reply Path (RP) TLV MUST be included in > > an echo request message and its absence is treated as a malformed > > echo request as described in [RFC4379]. Furthermore, if a Reply Path > > (RP) TLV is included in an echo request message, a Reply Path (RP) > > TLV MUST be included in the corresponding echo reply message sent by > > an implementation that is conformant to this specification. > > > > The Reply Path (RP) TLV carries the specified return path that the > > echo reply message is required to follow. The format of Reply Path > > TLV is as follows: > > END > > OK. > > > > > --- > > > > Section 3.2 > > > > OLD > > Reply Path TLV Type field is 2 octets in length, and the type value > > is TBD by IANA. > > NEW > > Reply Path TLV Type field is 2 octets in length, and the type value > > is 21. (This has been allocated by IANA using early allocation and is > > to be confirmed by IANA). > > END > > OK. > > > > > --- > > > > Section 3.2 > > > > OLD > > Reply Path return code is 2 octets in length. It is defined for the > > egress LSR of the forward LSP to report the results of Reply Path TLV > > processing and return path selection. When sending echo request, > > these codes MUST be set to zero. Reply Path return code only used > > when sending echo reply, and it MUST be ignored when processing echo > > request message. This document defines the following Reply Path > > return codes: > > NEW > > The Reply Path return code field is 2 octets in length. It is > > defined for the egress LSR of the forward LSP to report the results > > of Reply Path TLV processing and return path selection. This field > > MUST be set to zero in a Reply Path TLV carried on an echo request > > message and MUST be ignored on receipt. This document defines the > > following Reply Path return codes for inclusion in a Reply Path TLV > > carried on an echo reply: > > END > > OK. > > > > > --- > > > > Section 3.2 > > > > Value Meaning > > ------ ---------------------- > > 0x0000 No return code > > > > What does "No return code" mean? I thought it might have been the value > > that you should return if the TLV has been successfully processed but > > you seem to have 0x0003 for this. So, how is 0x0000 used? > > It should be named as "Reserved". > > > > > --- > > > > Section 3.2 > > > > 0x0006 The Reply mode in echo request was not set to 5 (Reply > > via Specified Path) although Reply Path TLV exists > > > > 0x0007 Reply Path TLV was missing in echo request > > > > Surely these are malformed echo requests and will be handled with > > normal echo replies with return code value 1. > > Yes, indeed, will remove this two codes. > > > > > --- > > > > Section 3.2 > > > > The A bit and B bit set MUST NOT both be set, otherwise, an echo > > reply with the RP return code set to "Malformed RP TLV was received" > > SHOULD be returned. > > > > What other options are there? I.e. why "SHOULD" not "MUST"? > > Actually, there is no other options, MUST should be more precise. > > > > > --- > > > > Section 3.2 > > > > OLD > > The Reply Paths field is variable in length, not more than one sub- > > TLV MUST be carried, which describes the specified path that the echo > > reply message is required to follow. When the Reply Mode field is > > set to "Reply via Specified Path" in an LSP echo request message, the > > Reply Path TLV MUST be present. The Reply Path TLV SHALL only be > > used in the reply mode defined in this document (Reply via Specified > > Path). > > NEW > > The Reply Paths field is variable in length and MUST contain zero or > > one sub-TLV. The sub-TLV, if present, describes the specified path > > that the echo reply message is required to follow. > > END > > > > --- > > > > Section 3.2 > > > > When the Reply Mode field is set to "Reply via Specified Path" in an > > LSP echo request message, the Reply Path TLV MUST be present. > > > > I think this is a duplication of a previous statement and can be removed > > Yes. > > > > > --- > > > > Section 3.2 > > > > The Reply Path TLV SHALL only be > > used in the reply mode defined in this document (Reply via Specified > > Path). > > > > Why do you need this? And can it be enforced? > > It is very unusual to restrict the use of information in this way. I > > understand that you do not have any other use in mind, but is there a > > need to make this constraint. > > This is for resolving one last call comment: how to handle the situation that a Reply Path TLV is carried but the reply mode is not set to 5, this should not be allowed (implicitly) so far and the echo request should be a Malformed message. > > I personally do not prefer to add this constraint, because we cannot guarantee that it will never be used in other modes in the future. I am OK to remove it. > > > > > --- > > > > Section 3.3 > > > > In [RFC4379], the range of 31744-32767 and 64512-65535 for sub-TLVs > > is specified for Vendor Private Use, and MUST NOT be allocated. This > > document changes that rule to make it not applicable to Reply Path > > TLV and redefines the rule as in Section 6.2 . If an implementation > > recognizes any specific Vendor Private types as defined in [RFC4379], > > and uses the sub-TLV type specified in this document, care must be > > taken to ensure that the implementation does not confuse the two > > usages. > > > > I don't think this draft changes the registry for 4379, does it? > > This needs a little more care to separate the two uses clearly. How > > about... > > I think it does not change the registry for 4379, but it does changes rule that RFC4379 specifies to TLVs and sub-TLVs. RFC4379 specifies that the range of 31744-32767 and 64512-65535 for sub-TLVs is specified for Vendor Private Use, this draft changes this. > > But I agree with your suggestion below :-) > > > > > OLD > > Each of the FEC sub-TLVs (include existing and future defined) for > > the Target FEC Stack TLV[RFC4379] is applicable to be a sub-TLV for > > inclusion in the Reply Path TLV for expressing a specific return > > path. For these shared sub-TLVs, they share the same registry with > > the Target FEC Stack TLV for the range of 0-31743 and 32768-64511. > > > > In addition, this document defines three new sub-TLVs: IPv4 RSVP > > Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV and Static Tunnel sub-TLV. > > These sub-TLVs are only designed for Reply Path TLV, hence this > > document calls them dedicated sub-TLVs to Reply Path TLV. For these > > dedicated sub-TLVs, this document will create a new registry (Section > > 6.1), the sub-TLV type MUST be allocated from the new registry. > > Detailed definition is in the following sections. > > > > In [RFC4379], the range of 31744-32767 and 64512-65535 for sub-TLVs > > is specified for Vendor Private Use, and MUST NOT be allocated. This > > document changes that rule to make it not applicable to Reply Path > > TLV and redefines the rule as in Section 6.2 . If an implementation > > recognizes any specific Vendor Private types as defined in [RFC4379], > > and uses the sub-TLV type specified in this document, care must be > > taken to ensure that the implementation does not confuse the two > > usages. > > NEW > > The FECs defined in [RFC4379] provide a good way to identify a > > specific return path. The FEC sub-TLVs (including existing and > > future sub-TLVs) of the Target FEC Stack TLV [RFC4379] have sub-TLV > > types assigned from a registry with ranges as follows: > > > > 0-16383 Standards Action mandatory TLV > > 16384-31743 Specification Required, Experimental RFC needed > > 31744-32767 Vendor Private Use, MUST NOT be allocated > > 32768-49161 Standards Action optional TLV > > 49162-64511 Specification Required, Experimental RFC needed > > 64512-65535 Vendor Private Use, MUST NOT be allocated > > > > The Reply Path TLV can carry and sub-TLV defined for use in the > > > Should the "carry and sub-TLV" be "carry the sub-TLV"? > > > Target FEC Stack TLV that can be registered. Thus the ranges > > 0-31743 and 32768-64511 are shared by the registries, with the new > > Reply Path Sub-TLVs registry "borrowing" values from the Target FEC > > Stack TLV registry. > > > > Allocations from the ranges 31744-32767 and 64512-65535 are not > > recorded in the registry for Target FEC Stack TLVs, so these ranges > > are safely made available in the Reply Path Sub-TLVs registry (see > > Section 6.1) to record sub-TLVs that are specific to the Reply Path > > TLV. This document defines three sub-TLVs specific to the Reply Path > > TLV: IPv4 RSVP Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static > > Tunnel sub-TLV. > > > > Note that an implementation that supports specific Vendor Private > > for sub-TLVs of the Target FEC Stack must take care to not confuse > > those values with the same values allocated from the Reply Path Sub- > > TLVs registry. > > END > > > > --- > > > > Section 3.3 > > > > 2. Specify a more generic tunnel FEC as return path > > > > It is clear that 3.3.1 and 3.3.2 define a FEC that is more general than > > the FECs in 4379. What is not clear is the use case. I think you need > > some text in this document to say what you should do with one of these > > FECs since it possibly identifies a set of LSPs. > > There is another draft (http://tools.ietf.org/html/draft-chen-mpls-bfd-enhancement-00#section-4 .2 ) discusses the usage of the generic Tunnel sub-TLV. How about add the following text: > > One usage of this generic RSVP Tunnel sub-TLV is for bootstrapping BFD session on an MPLS Tunnel that has primary and secondary LSPs, especially when Make-Before-Break (MBB) is deployed. The usage is discussed in the Section 4.2 of [I-D.chen-mpls-bfd-enhancement]. > > > > > --- > > > > Section 3.3.1 > > > > OLD > > The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and > > the recommended type value is TBD. > > NEW > > The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and > > the recommended type value is TBD1. > > END > > OK. > > > > > --- > > > > Section 3.3.1 > > > > It is slightly weird that the bit field in this section allocates the > > first two bits while the field in section 3.2 allocates the last two > > bits. This is not significantly important, but is odd. > > Will change it and make them consistent. > > > > --- > > > > Section 3.3.2 > > > > OLD > > The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and > > the type value is TBD. > > NEW > > The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and > > the type value is TBD2. > > END > > OK. > > > > > --- > > > > Section 3.3.3 > > > > RFC 6370 seems to also include an "LSP_Num". So your 3.3.3 case is the > > MPLS-TP static equivalent of 3.3.1. But you are missing: > > > > - the MPLS-TP static equivalent of 3.3.2 (i.e. v6 identifiers) > > - the MPLS-TP equivalent of the 4379 RSVP LSP FECs > > > > Do you need them? > > No, we do not need them, MPLS-TP has not v6 identifiers, and the MPLS-TP equivalent of the 4379 RSVP LSP FECs belongs to the existing sub-TLVs of Target FEC TLV and are already defined in TP related RFC. > > > > > --- > > > > Section 3.3.3 > > > > OLD > > The sub-TLV type value is TBD. > > NEW > > The sub-TLV type value is TBD3. > > END > > > OK. > > > --- > > > > Section 3.4 > > > > OLD > > The Reply TC TLV Type field is 2 octets in length, and the type value > > is TBD. > > NEW > > The Reply TC TLV Type field is 2 octets in length, and the type value > > is TBD4. > > END > > > > OK. > > > --- > > > > Section 4 > > > > The procedures defined in this document currently only apply to > > "ping" mode. The "traceroute" mode is out of scope for this > > document. > > > > I think this should show up in the Introduction and possibly the > > Abstract. > > OK. > > > > > --- > > > > Section 6 > > > > Please consider whether you want registries for the bit fields you > > define in this document. > > > > --- > > > > Section 6.1 > > > > OLD > > TBD Reply TC TLV this document (sect 3.4) > > NEW > > TBD4 Reply TC TLV this document (sect 3.4) > > END > > > OK > > > --- > > > > Section 6.4 > > > > OLD > > TBD Reply TC TLV this document (sect 3.4) > > NEW > > TBD4 Reply TC TLV this document (sect 3.4) > > END > > > OK. > > > --- > > > > Section 6.2.1 > > > > OLD > > Sub-type Value Field Reference > > ------- ----------- --------- > > TBD IPv4 RSVP Tunnel this document (sect 3.3.1) > > TBD IPv6 RSVP Tunnel this document (sect 3.3.2) > > TBD Static Tunnel this document (sect 3.3.3) > > NEW > > Sub-type Value Field Reference > > ------- ----------- --------- > > TBD1 IPv4 RSVP Tunnel this document (sect 3.3.1) > > TBD2 IPv6 RSVP Tunnel this document (sect 3.3.2) > > TBD3 Static Tunnel this document (sect 3.3.3) > > END > > > > --- > > > > Section 6.3 > > > > OLD > > IANA is now requested to assign the previously assigned a new reply > > mode code point (5 - Reply via specified path) from the "Multi- > > Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping > > Parameters" registry, the "Reply Mode" sub-registry on a permanent > > basis. > > NEW > > IANA has made an early allocation (5 - Reply via specified path) from > > the "Multi-Protocol Label Switching (MPLS) Label Switched Paths > > (LSPs) Ping Parameters" registry, the "Reply Mode" sub-registry. IANA > > is requested to make this allocation permanent. > > END > > OK. > From msiva@cisco.com Thu Oct 18 10:01:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E3721F876A for ; Thu, 18 Oct 2012 10:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moYNmZTi3vAT for ; Thu, 18 Oct 2012 10:01:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9704E21F875C for ; Thu, 18 Oct 2012 10:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1627; q=dns/txt; s=iport; t=1350579660; x=1351789260; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=q/3WEXv4n4gUDP3fc95DCzXwLNryeIPZuOUC2jili+E=; b=jj/Pz5vcOXs9/yT9ONr/508KxYlUPt6wBZ8hg70v/TYTPKv5D4ybAGEH hYa+LC8ZeO3RinK5Cs2khXKsAPaEkNP1M7Bg28p7gD3wOvwyDrMxE2p80 KQ1wsKTs207ohsfhU1U/mYda7zrFN5WqLiG7eCSbB3fIrNJxx7NmM8siB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAA1gFCtJXG8/2dsb2JhbABFwE6BCIIgAQEBBAEBAQ8BJzQLDAICAgEIEQQBAQsUBQQHGwwLFAkIAgQBDQUIGodiC5xloDcEi1SFYmADlwCNNIFrgm+BYzQ X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="133105149" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 18 Oct 2012 17:01:00 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9IH10Cq009038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 17:01:00 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.63]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 12:00:59 -0500 From: "Siva Sivabalan (msiva)" To: Loa Andersson , "mpls@ietf.org" , "Martin Vigoureux" , "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" Thread-Topic: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document Thread-Index: AQHNrQH5iQMMv/7t4UaaVUpqZMsgQZe/Sgzw Date: Thu, 18 Oct 2012 17:00:59 +0000 Message-ID: References: <507FAF2D.5020907@pi.nu> In-Reply-To: <507FAF2D.5020907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.193.163] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--26.992800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:01:01 -0000 Support. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, October 18, 2012 3:27 AM To: mpls@ietf.org; Martin Vigoureux; draft-ali-mpls-inter-domain-p2mp-rsvp-= te-lsp@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp= -rsvp-te-lsp a working group document Working group, this is to start a two week poll on adopting draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-09 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls at ietf.org). Please give an technical motivation for you= r support/not support, especially if you think that the document should not= be adopted as a working group document. This poll ends November 07, 2012. There is one IPR claim against this document - http://datatracker.ietf.org/= ipr/1861/ . All the co-authors has stated on the mailing list that they are not aware o= f any other IPR claims than those already disclosed. If there are IPR claims from any other party, please remember that the IPR = is open. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ____________= ___________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Thu Oct 18 12:13:16 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948BD21F849E; Thu, 18 Oct 2012 12:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+X7F289-wDJ; Thu, 18 Oct 2012 12:13:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73DF21F849B; Thu, 18 Oct 2012 12:13:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121018191315.31366.26317.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 12:13:15 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:13:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Identifiers Following ITU-T Conventions Author(s) : Rolf Winter Eric Gray Huub van Helvoort Malcolm Betts Filename : draft-ietf-mpls-tp-itu-t-identifiers-05.txt Pages : 12 Date : 2012-10-18 Abstract: This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-itu-t-identifiers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-itu-t-identifiers-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-itu-t-identifiers-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From huubatwork@gmail.com Thu Oct 18 12:30:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD00C21F84B7 for ; Thu, 18 Oct 2012 12:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpLJLEft9rQN for ; Thu, 18 Oct 2012 12:30:08 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D52D321F85B6 for ; Thu, 18 Oct 2012 12:30:07 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so5140843wgb.13 for ; Thu, 18 Oct 2012 12:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :x-forwarded-message-id:content-type:content-transfer-encoding; bh=KEkmE5kuGQuqexUrUHhUB1kDzflgX65nrkSSA5LLg5o=; b=JrGhj9TMmrkboUdUy6125liGraFiVTwL0AbxneOMKWxTeseHLl8W5fBB8Rn+9VRWrd ANOSA3oVygfJQXh0jt+stqBx8udUGlgrpSHuX085nbswBHNL3ZhCN7sT5p5PQKewqpfu F64Jj15EgWzWGhGFhtTXLoBwYg9vvHmirM0Jq5puphY1uHTrgS0Es61XfWhqWWWADyLR mPf2kGPlknm1agr1+YaJ8VscqtcWuTYVzw8XBytWQnzSUKIb/ECDPXLZiwXiVEKCcEnn v3CmJwX6jJMdk3nplE5vxCZA26gkLEi934JyZzB7TLBGlZsKFhd01sobRpZP/+q64a3Q +uYQ== Received: by 10.180.81.37 with SMTP id w5mr13417739wix.10.1350588606393; Thu, 18 Oct 2012 12:30:06 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl. [77.250.51.60]) by mx.google.com with ESMTPS id j8sm31023931wiy.9.2012.10.18.12.30.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 12:30:05 -0700 (PDT) Message-ID: <508058BC.9090609@gmail.com> Date: Thu, 18 Oct 2012 21:30:04 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" References: <20121018191315.31366.26317.idtracker@ietfa.amsl.com> In-Reply-To: <20121018191315.31366.26317.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121018191315.31366.26317.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Fwd: I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:30:08 -0000 FYI, The editors have resolved all comments received during the last call. Best regards, Huub. -------- Original Message -------- Subject: I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-05.txt Date: Thu, 18 Oct 2012 12:13:15 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Identifiers Following ITU-T Conventions Author(s) : Rolf Winter Eric Gray Huub van Helvoort Malcolm Betts Filename : draft-ietf-mpls-tp-itu-t-identifiers-05.txt Pages : 12 Date : 2012-10-18 Abstract: This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-itu-t-identifiers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-itu-t-identifiers-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-itu-t-identifiers-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From adrian@olddog.co.uk Thu Oct 18 16:12:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4CB21F85A9 for ; Thu, 18 Oct 2012 16:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9qbJ8taZfyB for ; Thu, 18 Oct 2012 16:12:45 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 23B7F21F859B for ; Thu, 18 Oct 2012 16:12:43 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9INCdra030080; Fri, 19 Oct 2012 00:12:39 +0100 Received: from 950129200 ([63.68.157.173]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9INBq69029993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Oct 2012 00:12:26 +0100 From: "Adrian Farrel" To: "'Mach Chen'" , References: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> In-Reply-To: Date: Fri, 19 Oct 2012 00:11:49 +0100 Message-ID: <092b01cdad86$0c9fe200$25dfa600$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE0HrKlK3xP7xIiiwKhHQUD8zKbegKbDkfUmN3HwLA= Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-return-path-specified-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 23:12:46 -0000 Hi Mach, This looks good. > Should the "carry and sub-TLV" be "carry the sub-TLV"? Yes. Too many fingers error. Otherwise I agree all your proposed changes and answers. I'll look for the revised I-D and advance when I see it. Don't forget = the cut-off date! Cheers, Adrian > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: 18 October 2012 09:56 > To: adrian@olddog.co.uk; draft-ietf-mpls-return-path-specified-lsp- > ping.all@tools.ietf.org > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: =B4=F0=B8=B4: [mpls] AD review of draft-ietf-mpls-return-path-specified-lsp-ping >=20 > Adrian, >=20 > Many thanks for your detail review and comments! >=20 > Please see my response inline... >=20 > Best regards, > Mach >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED Adrian > > Farrel > > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA10=D4=C218=C8=D5 4:35 > > =CA=D5=BC=FE=C8=CB: = draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org > > =B3=AD=CB=CD: mpls@ietf.org; mpls-chairs@tools.ietf.org > > =D6=F7=CC=E2: [mpls] AD review of = draft-ietf-mpls-return-path-specified-lsp-ping > > > > Hi, > > > > I've done my usual AD review of your draft prior to issuing IETF = last > > call and passing the I-D for IESG evaluation. The main purpose of = the > > review is to catch issues that might come up in later reviews and to > > ensure that the document is ready for publication as and RFC. > > > > I found Section 4 very good. It completely explains to me what is > > going on in the protocol extension, and covered all the corner cases > > I could think of. On the other hand, Section 3 made me generate a > > really (really, really) long list of relatively minor issues. This > > list is so long that I think you need to provide a new revision > > before we issue the IETF last call. I will put the I-D into "Revised > > I-D Needed" state and wait for the revision. > > > > As always, all my comments are up for discussion and negotiation. > > > > Thanks for the work, > > Adrian > > > > =3D=3D=3D > > > > Consistency of references for bidirectional LSP. In Section 1 you = have > > In this document, term bidirectional LSP includes the co-routed > > bidirectional LSP defined in [RFC3945] > > In Section 2 you have: > > The co-routed bidirectional LSP is defined in [RFC3471] > > and [RFC3473] > > > OK, will consistently refer to [RFC3945] instead. >=20 > > --- > > > > Section 1 > > s/(BFD)[RFC5880], [RFC5884]session/(BFD) [RFC5880], [RFC5884] = session/ > > s/In this document, term bidirectional LSP/In this document, the = term > > bidirectional LSP/ >=20 > OK. >=20 > > > > --- > > > > Section 3.1 > > > > OLD > > The recommended value of the Reply via Specified Path mode is 5 = (This > > is to be confirmed by the IANA). > > > > Value Meaning > > ----- ------- > > 5 Reply via Specified Path > > NEW > > The value of the Reply via Specified Path mode is 5 (This has = been > > allocated by IANA using early allocation and is to be confirmed = by > > IANA). > > > > Value Meaning > > ----- ------- > > 5 Reply via Specified Path > > END >=20 > OK. >=20 > > > > --- > > > > Section 3.2 > > > > OLD > > The Reply Path (RP) TLV is an optional TLV, if the Reply via > > Specified Path mode requested, the Reply Path (RP) TLV MUST be > > included in an echo request message. It carries the specified = return > > paths that the echo reply message is required to follow. The = format > > of Reply Path TLV is as follows: > > > > NEW > > The Reply Path (RP) TLV is an optional TLV within the LSP Ping > > protocol. However, if the Reply via Specified Path mode = requested as > > described in Section 3.1, the Reply Path (RP) TLV MUST be = included in > > an echo request message and its absence is treated as a malformed > > echo request as described in [RFC4379]. Furthermore, if a Reply = Path > > (RP) TLV is included in an echo request message, a Reply Path = (RP) > > TLV MUST be included in the corresponding echo reply message sent = by > > an implementation that is conformant to this specification. > > > > The Reply Path (RP) TLV carries the specified return path that = the > > echo reply message is required to follow. The format of Reply = Path > > TLV is as follows: > > END >=20 > OK. >=20 > > > > --- > > > > Section 3.2 > > > > OLD > > Reply Path TLV Type field is 2 octets in length, and the type = value > > is TBD by IANA. > > NEW > > Reply Path TLV Type field is 2 octets in length, and the type = value > > is 21. (This has been allocated by IANA using early allocation = and is > > to be confirmed by IANA). > > END >=20 > OK. >=20 > > > > --- > > > > Section 3.2 > > > > OLD > > Reply Path return code is 2 octets in length. It is defined for = the > > egress LSR of the forward LSP to report the results of Reply Path = TLV > > processing and return path selection. When sending echo request, > > these codes MUST be set to zero. Reply Path return code only = used > > when sending echo reply, and it MUST be ignored when processing = echo > > request message. This document defines the following Reply Path > > return codes: > > NEW > > The Reply Path return code field is 2 octets in length. It is > > defined for the egress LSR of the forward LSP to report the = results > > of Reply Path TLV processing and return path selection. This = field > > MUST be set to zero in a Reply Path TLV carried on an echo = request > > message and MUST be ignored on receipt. This document defines = the > > following Reply Path return codes for inclusion in a Reply Path = TLV > > carried on an echo reply: > > END >=20 > OK. >=20 > > > > --- > > > > Section 3.2 > > > > Value Meaning > > ------ ---------------------- > > 0x0000 No return code > > > > What does "No return code" mean? I thought it might have been the = value > > that you should return if the TLV has been successfully processed = but > > you seem to have 0x0003 for this. So, how is 0x0000 used? >=20 > It should be named as "Reserved". >=20 > > > > --- > > > > Section 3.2 > > > > 0x0006 The Reply mode in echo request was not set to 5 = (Reply > > via Specified Path) although Reply Path TLV exists >=20 >=20 > > 0x0007 Reply Path TLV was missing in echo request > > > > Surely these are malformed echo requests and will be handled with > > normal echo replies with return code value 1. >=20 > Yes, indeed, will remove this two codes. >=20 > > > > --- > > > > Section 3.2 > > > > The A bit and B bit set MUST NOT both be set, otherwise, an echo > > reply with the RP return code set to "Malformed RP TLV was = received" > > SHOULD be returned. > > > > What other options are there? I.e. why "SHOULD" not "MUST"? >=20 > Actually, there is no other options, MUST should be more precise. >=20 > > > > --- > > > > Section 3.2 > > > > OLD > > The Reply Paths field is variable in length, not more than one = sub- > > TLV MUST be carried, which describes the specified path that the = echo > > reply message is required to follow. When the Reply Mode field = is > > set to "Reply via Specified Path" in an LSP echo request message, = the > > Reply Path TLV MUST be present. The Reply Path TLV SHALL only be > > used in the reply mode defined in this document (Reply via = Specified > > Path). > > NEW > > The Reply Paths field is variable in length and MUST contain zero = or > > one sub-TLV. The sub-TLV, if present, describes the specified = path > > that the echo reply message is required to follow. > > END > > > > --- > > > > Section 3.2 > > > > When the Reply Mode field is set to "Reply via Specified Path" in = an > > LSP echo request message, the Reply Path TLV MUST be present. > > > > I think this is a duplication of a previous statement and can be = removed >=20 > Yes. >=20 > > > > --- > > > > Section 3.2 > > > > The Reply Path TLV SHALL only be > > used in the reply mode defined in this document (Reply via = Specified > > Path). > > > > Why do you need this? And can it be enforced? > > It is very unusual to restrict the use of information in this way. I > > understand that you do not have any other use in mind, but is there = a > > need to make this constraint. >=20 > This is for resolving one last call comment: how to handle the = situation that a > Reply Path TLV is carried but the reply mode is not set to 5, this = should not be > allowed (implicitly) so far and the echo request should be a Malformed message. >=20 > I personally do not prefer to add this constraint, because we cannot = guarantee > that it will never be used in other modes in the future. I am OK to = remove it. >=20 > > > > --- > > > > Section 3.3 > > > > In [RFC4379], the range of 31744-32767 and 64512-65535 for = sub-TLVs > > is specified for Vendor Private Use, and MUST NOT be allocated. = This > > document changes that rule to make it not applicable to Reply = Path > > TLV and redefines the rule as in Section 6.2 . If an = implementation > > recognizes any specific Vendor Private types as defined in = [RFC4379], > > and uses the sub-TLV type specified in this document, care must = be > > taken to ensure that the implementation does not confuse the two > > usages. > > > > I don't think this draft changes the registry for 4379, does it? > > This needs a little more care to separate the two uses clearly. How > > about... >=20 > I think it does not change the registry for 4379, but it does changes = rule that > RFC4379 specifies to TLVs and sub-TLVs. RFC4379 specifies that the = range of > 31744-32767 and 64512-65535 for sub-TLVs is specified for Vendor = Private Use, > this draft changes this. >=20 > But I agree with your suggestion below :-) >=20 > > > > OLD > > Each of the FEC sub-TLVs (include existing and future defined) = for > > the Target FEC Stack TLV[RFC4379] is applicable to be a sub-TLV = for > > inclusion in the Reply Path TLV for expressing a specific return > > path. For these shared sub-TLVs, they share the same registry = with > > the Target FEC Stack TLV for the range of 0-31743 and = 32768-64511. > > > > In addition, this document defines three new sub-TLVs: IPv4 RSVP > > Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV and Static Tunnel = sub-TLV. > > These sub-TLVs are only designed for Reply Path TLV, hence this > > document calls them dedicated sub-TLVs to Reply Path TLV. For = these > > dedicated sub-TLVs, this document will create a new registry = (Section > > 6.1), the sub-TLV type MUST be allocated from the new registry. > > Detailed definition is in the following sections. > > > > In [RFC4379], the range of 31744-32767 and 64512-65535 for = sub-TLVs > > is specified for Vendor Private Use, and MUST NOT be allocated. = This > > document changes that rule to make it not applicable to Reply = Path > > TLV and redefines the rule as in Section 6.2 . If an = implementation > > recognizes any specific Vendor Private types as defined in = [RFC4379], > > and uses the sub-TLV type specified in this document, care must = be > > taken to ensure that the implementation does not confuse the two > > usages. > > NEW > > The FECs defined in [RFC4379] provide a good way to identify a > > specific return path. The FEC sub-TLVs (including existing and > > future sub-TLVs) of the Target FEC Stack TLV [RFC4379] have = sub-TLV > > types assigned from a registry with ranges as follows: > > > > 0-16383 Standards Action mandatory TLV > > 16384-31743 Specification Required, Experimental RFC needed > > 31744-32767 Vendor Private Use, MUST NOT be allocated > > 32768-49161 Standards Action optional TLV > > 49162-64511 Specification Required, Experimental RFC needed > > 64512-65535 Vendor Private Use, MUST NOT be allocated > > > > The Reply Path TLV can carry and sub-TLV defined for use in the >=20 >=20 > Should the "carry and sub-TLV" be "carry the sub-TLV"? >=20 > > Target FEC Stack TLV that can be registered. Thus the ranges > > 0-31743 and 32768-64511 are shared by the registries, with the = new > > Reply Path Sub-TLVs registry "borrowing" values from the Target = FEC > > Stack TLV registry. > > > > Allocations from the ranges 31744-32767 and 64512-65535 are not > > recorded in the registry for Target FEC Stack TLVs, so these = ranges > > are safely made available in the Reply Path Sub-TLVs registry = (see > > Section 6.1) to record sub-TLVs that are specific to the Reply = Path > > TLV. This document defines three sub-TLVs specific to the Reply = Path > > TLV: IPv4 RSVP Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and = Static > > Tunnel sub-TLV. > > > > Note that an implementation that supports specific Vendor Private > > for sub-TLVs of the Target FEC Stack must take care to not = confuse > > those values with the same values allocated from the Reply Path = Sub- > > TLVs registry. > > END > > > > --- > > > > Section 3.3 > > > > 2. Specify a more generic tunnel FEC as return path > > > > It is clear that 3.3.1 and 3.3.2 define a FEC that is more general = than > > the FECs in 4379. What is not clear is the use case. I think you = need > > some text in this document to say what you should do with one of = these > > FECs since it possibly identifies a set of LSPs. >=20 > There is another draft = (http://tools.ietf.org/html/draft-chen-mpls-bfd- > enhancement-00#section-4.2 ) discusses the usage of the generic Tunnel = sub- > TLV. How about add the following text: >=20 > One usage of this generic RSVP Tunnel sub-TLV is for bootstrapping BFD = session > on an MPLS Tunnel that has primary and secondary LSPs, especially when = Make- > Before-Break (MBB) is deployed. The usage is discussed in the Section = 4.2 of [I- > D.chen-mpls-bfd-enhancement]. >=20 > > > > --- > > > > Section 3.3.1 > > > > OLD > > The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, = and > > the recommended type value is TBD. > > NEW > > The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, = and > > the recommended type value is TBD1. > > END >=20 > OK. >=20 > > > > --- > > > > Section 3.3.1 > > > > It is slightly weird that the bit field in this section allocates = the > > first two bits while the field in section 3.2 allocates the last two > > bits. This is not significantly important, but is odd. >=20 > Will change it and make them consistent. > > > > --- > > > > Section 3.3.2 > > > > OLD > > The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, = and > > the type value is TBD. > > NEW > > The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, = and > > the type value is TBD2. > > END >=20 > OK. >=20 > > > > --- > > > > Section 3.3.3 > > > > RFC 6370 seems to also include an "LSP_Num". So your 3.3.3 case is = the > > MPLS-TP static equivalent of 3.3.1. But you are missing: > > > > - the MPLS-TP static equivalent of 3.3.2 (i.e. v6 identifiers) > > - the MPLS-TP equivalent of the 4379 RSVP LSP FECs > > > > Do you need them? >=20 > No, we do not need them, MPLS-TP has not v6 identifiers, and the = MPLS-TP > equivalent of the 4379 RSVP LSP FECs belongs to the existing sub-TLVs = of Target > FEC TLV and are already defined in TP related RFC. >=20 > > > > --- > > > > Section 3.3.3 > > > > OLD > > The sub-TLV type value is TBD. > > NEW > > The sub-TLV type value is TBD3. > > END > > > OK. >=20 > > --- > > > > Section 3.4 > > > > OLD > > The Reply TC TLV Type field is 2 octets in length, and the type = value > > is TBD. > > NEW > > The Reply TC TLV Type field is 2 octets in length, and the type = value > > is TBD4. > > END > > >=20 > OK. >=20 > > --- > > > > Section 4 > > > > The procedures defined in this document currently only apply to > > "ping" mode. The "traceroute" mode is out of scope for this > > document. > > > > I think this should show up in the Introduction and possibly the > > Abstract. >=20 > OK. >=20 > > > > --- > > > > Section 6 > > > > Please consider whether you want registries for the bit fields you > > define in this document. > > > > --- > > > > Section 6.1 > > > > OLD > > TBD Reply TC TLV this document (sect = 3.4) > > NEW > > TBD4 Reply TC TLV this document (sect = 3.4) > > END > > > OK >=20 > > --- > > > > Section 6.4 > > > > OLD > > TBD Reply TC TLV this document (sect = 3.4) > > NEW > > TBD4 Reply TC TLV this document (sect = 3.4) > > END > > > OK. >=20 > > --- > > > > Section 6.2.1 > > > > OLD > > Sub-type Value Field Reference > > ------- ----------- --------- > > TBD IPv4 RSVP Tunnel this document (sect 3.3.1) > > TBD IPv6 RSVP Tunnel this document (sect 3.3.2) > > TBD Static Tunnel this document (sect 3.3.3) > > NEW > > Sub-type Value Field Reference > > ------- ----------- --------- > > TBD1 IPv4 RSVP Tunnel this document (sect 3.3.1) > > TBD2 IPv6 RSVP Tunnel this document (sect 3.3.2) > > TBD3 Static Tunnel this document (sect 3.3.3) > > END > > > > --- > > > > Section 6.3 > > > > OLD > > IANA is now requested to assign the previously assigned a new = reply > > mode code point (5 - Reply via specified path) from the "Multi- > > Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping > > Parameters" registry, the "Reply Mode" sub-registry on a = permanent > > basis. > > NEW > > IANA has made an early allocation (5 - Reply via specified path) = from > > the "Multi-Protocol Label Switching (MPLS) Label Switched Paths > > (LSPs) Ping Parameters" registry, the "Reply Mode" sub-registry. = IANA > > is requested to make this allocation permanent. > > END >=20 > OK. >=20 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From ke-kumaki@kddi.com Thu Oct 18 17:28:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF3221F8233 for ; Thu, 18 Oct 2012 17:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zznW88KQwIkP for ; Thu, 18 Oct 2012 17:28:40 -0700 (PDT) Received: from UTMC1104.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4161221F841E for ; Thu, 18 Oct 2012 17:28:39 -0700 (PDT) Received: from UTMC1133 (unknown [10.5.16.198]) by UTMC1104.kddi.com (Postfix) with SMTP id 8A3D028A6; Fri, 19 Oct 2012 09:28:38 +0900 (JST) Received: from UTMC1124.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id E52EA2606; Fri, 19 Oct 2012 09:28:35 +0900 (JST) Received: from LTMC1005.kddi.com (unknown [10.5.16.216]) by UTMC1124.kddi.com (Postfix) with ESMTP id D5A1A2604; Fri, 19 Oct 2012 09:28:35 +0900 (JST) Received: from LTMC1005.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id q9J0SZ1A015266; Fri, 19 Oct 2012 09:28:35 +0900 Received: from LTMC1005.kddi.com.mid_11460162 (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id q9J0QhjH012021; Fri, 19 Oct 2012 09:26:43 +0900 Received: from KDDI-1202PC0730 ([10.200.129.120] [10.200.129.120]) by post-zip.kddi.com with ESMTPA; Fri, 19 Oct 2012 09:26:43 +0900 To: loa@pi.nu From: Kenji Kumaki References: <507FAF2D.5020907@pi.nu> In-Reply-To: <507FAF2D.5020907@pi.nu> Message-Id: <201210190926.DIJ35490.tLFVBJNLL@kddi.com> X-Mailer: Winbiff [Version 2.51 PL4] X-Accept-Language: ja,en,zh Date: Fri, 19 Oct 2012 09:26:43 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-SA-MID: 11460162 X-WAuditID: 1210190928360000301760 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org Subject: Re: [mpls] poll for consensus to makedraft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 00:28:41 -0000 Support! Thanks, Kenji <507FAF2D.5020907@pi.nu> $B$N!"(B "[mpls] poll for consensus to makedraft-ali-mpls-inter-domain -p2mp-rsvp-te-lsp a working group document" $B$K$*$$$F!"(B "Loa Andersson "$B$5$s$O=q$-$^$7$?!'(B > Working group, > > this is to start a two week poll on adopting > draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-09 > as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give an technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > This poll ends November 07, 2012. > > There is one IPR claim against this document - > http://datatracker.ietf.org/ipr/1861/ . > > All the co-authors has stated on the mailing list that they are not > aware of any other IPR claims than those already disclosed. > If there are IPR claims from any other party, please remember that the > IPR is open. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From mach.chen@huawei.com Thu Oct 18 18:30:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F771F0424 for ; Thu, 18 Oct 2012 18:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.388 X-Spam-Level: *** X-Spam-Status: No, score=3.388 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_15=0.6, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf2EJAAyqDHC for ; Thu, 18 Oct 2012 18:30:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 192931F041F for ; Thu, 18 Oct 2012 18:30:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALU54937; Fri, 19 Oct 2012 01:30:16 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 19 Oct 2012 02:29:37 +0100 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 19 Oct 2012 02:30:16 +0100 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.129]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Fri, 19 Oct 2012 09:30:10 +0800 From: Mach Chen To: "t.petch" , "adrian@olddog.co.uk" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" Thread-Topic: [mpls] 4p84: AD review of draft-ietf-mpls-return-path-specified-lsp-ping Thread-Index: AQHNrU7a+BxJRqw4D0Gg5Y5DrX3trpe/zezA Date: Fri, 19 Oct 2012 01:30:09 +0000 Message-ID: References: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> <000401cdad4e$c7b080a0$4001a8c0@gateway.2wire.net> In-Reply-To: <000401cdad4e$c7b080a0$4001a8c0@gateway.2wire.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.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIDRwODQ6ICBBRCByZXZpZXcgb2YgZHJhZnQt?= =?gb2312?b?aWV0Zi1tcGxzLXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZw==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 01:30:20 -0000 SGkgVG9tLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMhDQoNClBsZWFzZSBzZWUgbXkgcmVw bHkgaW5saW5lLi4uDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCj4gLS0tLS3Tyrz+1K28/i0tLS0t DQo+ILeivP7IyzogdC5wZXRjaCBbbWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb21dDQo+ILeiy83K sbzkOiAyMDEyxOoxMNTCMTjI1SAyMzowNg0KPiDK1bz+yMs6IE1hY2ggQ2hlbjsgYWRyaWFuQG9s ZGRvZy5jby51azsNCj4gZHJhZnQtaWV0Zi1tcGxzLXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3At cGluZy5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4gs63LzTogbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFttcGxzXSA0cDg0OiBBRCByZXZpZXcgb2YN Cj4gZHJhZnQtaWV0Zi1tcGxzLXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZw0KPiANCj4g TGFzdCBOb3ZlbWJlciwgSSBjb21tZW50ZWQNCj4gDQo+ICJJbiByZXRyb3NwZWN0LCBSRkM0Mzc5 IHNob3VsZCBoYXZlIHNwbGl0IHRoZSBzdWItVExWIHJhbmdlIGludG8gY29tbW9uDQo+IHRvIGFs bA0KPiBUTFYsIGFuZCBUTFYtdW5pcXVlLCB3aGljaCwgaW4gZWZmZWN0LCBpcyB3aGF0IG15IGlk ZWEgb24gMTAyNCBpcywgcG9zdA0KPiBmYWN0dW0uDQo+IEkgd291bGQgZXhwZWN0IG90aGVycyB0 byBjb21tZW50IG9uIHRoaXMgYXMgYW5kIHdoZW4gdGhleSByZWFsaXNlIHdoYXQNCj4gaXQgc2F5 cywNCj4gc28gSSB3b3VsZCBsZWF2ZSBpdCBmb3IgYSB3aGlsZSBhbmQgc2VlIHdoYXQgY29tZXMg dXAuIg0KPiANCj4gYW5kIEkgdGhpbmsgdGhhdCB0aGlzIGhhcyBub3cgY29tZSB1cC4NCj4gDQo+ IEFkcmlhbiBzYXlzIGJlbG93DQo+ICI+IEkgdGhpbmsgaXQgZG9lcyBub3QgY2hhbmdlIHRoZSBy ZWdpc3RyeSBmb3IgNDM3OSwgYnV0IGl0IGRvZXMgY2hhbmdlcw0KPiBydWxlIHRoYXQgUkZDNDM3 OSBzcGVjaWZpZXMgdG8gVExWcyBhbmQgc3ViLVRMVnMuIg0KPiANCj4gYW5kIHByb3Bvc2VzIHRo YXQgd2hhdCBpbiBSRkM0Mzc5IGlzDQo+ICJUaGUgdmFsaWQgcmFuZ2UgZm9yIFRMVnMgYW5kIHN1 Yi1UTFZzIGlzIDAtNjU1MzUuICBBc3NpZ25tZW50cyBpbiB0aGUNCj4gICAgcmFuZ2UgMC0xNjM4 MyBhbmQgMzI3NjgtNDkxNjEgYXJlIG1hZGUgdmlhIFN0YW5kYXJkcyBBY3Rpb24gYXMNCj4gICAg ZGVmaW5lZCBpbiBbSUFOQV07IGFzc2lnbm1lbnRzIGluIHRoZSByYW5nZSAxNjM4NC0zMTc0MyBh bmQNCj4gICAgNDkxNjItNjQ1MTEgYXJlIG1hZGUgdmlhICJTcGVjaWZpY2F0aW9uIFJlcXVpcmVk IiBhcyBkZWZpbmVkIGFib3ZlOw0KPiAgICB2YWx1ZXMgaW4gdGhlIHJhbmdlIDMxNzQ0LTMyNzY3 IGFuZCA2NDUxMi02NTUzNSBhcmUgZm9yIFZlbmRvcg0KPiAgICBQcml2YXRlIFVzZSwgYW5kIE1V U1QgTk9UIGJlIGFsbG9jYXRlZC4iDQo+IA0KPiBiZWNvbWVzDQo+ICI+ID4gICAgICAgMC0xNjM4 MyAgICAgICBTdGFuZGFyZHMgQWN0aW9uIG1hbmRhdG9yeSBUTFYNCj4gPiA+ICAgICAgIDE2Mzg0 LTMxNzQzICAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCwgRXhwZXJpbWVudGFsIFJGQyBuZWVkZWQN Cj4gPiA+ICAgICAgIDMxNzQ0LTMyNzY3ICAgVmVuZG9yIFByaXZhdGUgVXNlLCBNVVNUIE5PVCBi ZSBhbGxvY2F0ZWQNCj4gPiA+ICAgICAgIDMyNzY4LTQ5MTYxICAgU3RhbmRhcmRzIEFjdGlvbiBv cHRpb25hbCBUTFYNCj4gPiA+ICAgICAgIDQ5MTYyLTY0NTExICAgU3BlY2lmaWNhdGlvbiBSZXF1 aXJlZCwgRXhwZXJpbWVudGFsIFJGQyBuZWVkZWQNCj4gPiA+ICAgICAgIDY0NTEyLTY1NTM1ICAg VmVuZG9yIFByaXZhdGUgVXNlLCBNVVNUIE5PVCBiZSBhbGxvY2F0ZWQiDQoNClRoaXMgYWJvdmUg aXMgYWN0dWFsbHkgcHJvcG9zZWQgaW4gUkZDNDM3OSwgdGhpcyBkcmFmdCBwcm9wb3NlcyB0byBj aGFuZ2VzIHRoZSBydWxlIGZvciBSZXBseSBQYXRoIFRMViBhcyBmb2xsb3dzOg0KICAgMC0zMTc0 MyAtIFJlc2VydmVkLCBhbmQgTVVTVCBOT1QgYmUgYWxsb2NhdGVkLg0KICAgMzE3NDQtMzI3Njcg LSBBbGxvY2F0ZWQgdmlhIFN0YW5kYXJkcyBBY3Rpb24uDQogICAzMjc2OC02NDUxMSAtIFJlc2Vy dmVkLCBhbmQgTVVTVCBOT1QgYmUgYWxsb2NhdGVkLg0KICAgNjQ1MTItNjU1MzEgLSBBbGxvY2F0 ZWQgdmlhIFN0YW5kYXJkcyBBY3Rpb24uDQogICA2NTUzMS02NTUzNSAtIEV4cGVyaW1lbnRhbCBV c2UsIGFuZCBNVVNUIE5PVCBiZSBhbGxvY2F0ZWQuDQoNClNvIHRoZSAiY29tbW9uIiByYW5nZSBh cmUgMC0zMTc0MyBhbmQgMzI3NjgtNjQ1MTEsIGFuZCB0aGUgZGVkaWNhdGVkIHJhbmdlcyBhcmUg MzE3NDQtMzI3NjcgYW5kIDY0NTEyLTY1NTMxICh0aGV5IGFyZSBvcmlnaW5hbGx5IGRlZmluZWQg YXMgIlZlbmRvciBQcml2YXRlIFVzZSIsIGFuZCBub3cgcmVkZWZpbmVkIGFzIGRlZGljYXRlZCBj b2RlIHJhbmdlcyBmb3IgYSBMU1AgUGluZyBUTFYgKS4gQW5kIGFjY29yZGluZyB0byB0aGUgZ3Vp ZGFuY2Ugb2YgUkZDNTIyNiwgdGhlcmUgYXJlIG9ubHkgNCBjb2RlIHBvaW50cyAoNjU1MzEtNjU1 MzUpIGxlZnQgZm9yIHRoZSBWZW5kb3IgUHJpdmF0ZSBVc2UoSXQncyBub3cgY2FsbGVkICJFeHBl cmltZW50YWwgVXNlIiBhY2NvcmRpbmcgc29tZSBleHBlcnQncyBzdWdnZXN0aW9uKS4NCg0KU28g SU1ITywgdGhlIGN1cnJlbnQgcnVsZSBpcyBhY3R1YWxseSB2ZXJ5IGNsb3NlIHRvIHlvdXIgc3Vn Z2VzdGlvbiwgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0aGF0IHRoZSBjb21tb24gcmFuZ2UgaXMg bm90IDEwMjQuDQoNCj4gd2hpY2gNCj4gYSkgc2VlbXMgdG8gbWUgdG8gYmUgbm90IHF1aXRlIHRo ZSBzYW1lIGllIHVwZGF0ZXMgUkZDNDM3OQ0KPiBiKSBkb2VzIG5vdCBzZWVtIHRvIHNvbHZlIHRo ZSBwcm9ibGVtDQo+IA0KPiAoYW5kIHRoZXJlIGlzIG5vIHJlZmVyZW5jZSBmb3IgUkZDNTIyNiwg YnV0IHRoZW4gdGhhdCBpcyB1c3VhbCBmb3IgYW4NCj4gTVBMUy1UUCBSRkM6LSgNCg0KV2UgYWN0 dWFsbHkgY29uc2lkZXIgdGhlIGd1aWRlbGluZXMgaW4gUkZDNTIyNiwgZXNwZWNpYWxseSBmb3Ig dGhlIGRlc2lnbiBvZiB0aGUgIkV4cGVyaW1lbnRhbCBVc2UiIHJhbmdlLiBEbyB5b3Ugc3VnZ2Vz dCB0byBhZGQgYW4gZXhwbGljaXQgcmVmZXJlbmNlIHRvIFJGQzUyMjY/IEkgYW0gZmluZSB0byBk byB0aGF0LiBIb3cgYWJvdXQgYWRkIHRoZSBmb2xsb3dpbmcgdGV4dCBhdCB0aGUgYmVnaW5uaW5n IG9mIFNlY3Rpb24gNi4yOg0KDQoiQWNjb3JkaW5nIHRvIHRoZSBndWlkZWxpbmVzIGRlZmluZWQg aW4gW1JGQzUyMjZdLCB0aGUgc3ViLVRMViByYW5nZSBvZiBSZXBseSBQYXRoIFRMViBhcmUgcGFy dGl0aW9uZWQgYXMgZm9sbG93aW5nOiINCg0KSG9wZSB0aGlzIHJlc29sdmVkIHlvdXIgY29tbWVu dHMhDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCj4NCj4gDQo+IFRvbSBQZXRjaA0KPiANCg0KU25p cGVkDQo= From adrian@olddog.co.uk Thu Oct 18 18:40:15 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDC11F041F for ; Thu, 18 Oct 2012 18:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhpgRAj39756 for ; Thu, 18 Oct 2012 18:40:14 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id A791221F84F6 for ; Thu, 18 Oct 2012 18:40:13 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9J1e55j019604; Fri, 19 Oct 2012 02:40:06 +0100 Received: from 950129200 ([63.68.157.173]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9J1e2N1019589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Oct 2012 02:40:04 +0100 From: "Adrian Farrel" To: "'t.petch'" , "'Mach Chen'" , References: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> <000401cdad4e$c7b080a0$4001a8c0@gateway.2wire.net> In-Reply-To: <000401cdad4e$c7b080a0$4001a8c0@gateway.2wire.net> Date: Fri, 19 Oct 2012 02:40:03 +0100 Message-ID: <098801cdad9a$aab59c50$0020d4f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE0HrKlK3xP7xIiiwKhHQUD8zKbegKbDkfUAkqPZFGYy8hiYA== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] 4p84: AD review of draft-ietf-mpls-return-path-specified-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 01:40:16 -0000 Whoa, no I don't propose a change to 4379 in this document. If the WG wants to make a change to the 4379 registry, that is fine by = me, but I really don't think it should be sneaked (is the American word "snuck"?) = through on this draft. > Last November, I commented >=20 >> "In retrospect, RFC4379 should have split the sub-TLV range into = common >> to all TLV, and TLV-unique, which, in effect, is what my idea on 1024 = is, post >> factum. >> I would expect others to comment on this as and when they realise = what >> it says, so I would leave it for a while and see what comes up." >=20 > and I think that this has now come up. Sort of. Yes. Certainly this I-D wants some TLV-specific sub-TLVs > Adrian says below > "> I think it does not change the registry for 4379, but it does = changes > rule that RFC4379 specifies to TLVs and sub-TLVs." That quote is from Mach, not me. I said:=20 > > > I don't think this draft changes the registry for 4379, does it? > and proposes that what in RFC4379 is > "The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the > range 0-16383 and 32768-49161 are made via Standards Action as > defined in [IANA]; assignments in the range 16384-31743 and > 49162-64511 are made via "Specification Required" as defined above; > values in the range 31744-32767 and 64512-65535 are for Vendor > Private Use, and MUST NOT be allocated." >=20 > becomes > "> > 0-16383 Standards Action mandatory TLV > > > 16384-31743 Specification Required, Experimental RFC = needed > > > 31744-32767 Vendor Private Use, MUST NOT be allocated > > > 32768-49161 Standards Action optional TLV > > > 49162-64511 Specification Required, Experimental RFC = needed > > > 64512-65535 Vendor Private Use, MUST NOT be allocated" > which > a) seems to me to be not quite the same ie updates RFC4379 > b) does not seem to solve the problem >=20 > (and there is no reference for RFC5226, but then that is usual for an > MPLS-TP RFC:-( Again, I was not proposing to change 4379 here, I was attempting to = report what I believed 4379 says using the shortcut of copying from the I-D I was = reviewing. I believe the only difference between the quoted text and my table is: - the statement of mandatory - the 2 statements of Experimental RFC required I just checked the registy at http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-pa= rameter s.xml#mpls-lsp-ping-parameters-7 and it seems to agree with me. Cheers, Adrian >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Mach Chen" > To: ; > > Cc: ; > Sent: Thursday, October 18, 2012 9:55 AM >=20 > > Adrian, > > > > Many thanks for your detail review and comments! > > > > Please see my response inline... > > > > Best regards, > > Mach > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED > Adrian > > > Farrel > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA10=D4=C218=C8=D5 4:35 > > > =CA=D5=BC=FE=C8=CB: > draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org > > > =B3=AD=CB=CD: mpls@ietf.org; mpls-chairs@tools.ietf.org > > > =D6=F7=CC=E2: [mpls] AD review of > draft-ietf-mpls-return-path-specified-lsp-ping > > > > > > Hi, > > > > > > I've done my usual AD review of your draft prior to issuing IETF > last > > > call and passing the I-D for IESG evaluation. The main purpose of > the > > > review is to catch issues that might come up in later reviews and = to > > > ensure that the document is ready for publication as and RFC. > > > > > > I found Section 4 very good. It completely explains to me what is > > > going on in the protocol extension, and covered all the corner = cases > > > I could think of. On the other hand, Section 3 made me generate a > > > really (really, really) long list of relatively minor issues. This > > > list is so long that I think you need to provide a new revision > > > before we issue the IETF last call. I will put the I-D into = "Revised > > > I-D Needed" state and wait for the revision. > > > > > > As always, all my comments are up for discussion and negotiation. > > > > > > Thanks for the work, > > > Adrian > > > > > > =3D=3D=3D > > > > > > Consistency of references for bidirectional LSP. In Section 1 you > have > > > In this document, term bidirectional LSP includes the co-routed > > > bidirectional LSP defined in [RFC3945] > > > In Section 2 you have: > > > The co-routed bidirectional LSP is defined in [RFC3471] > > > and [RFC3473] > > > > > OK, will consistently refer to [RFC3945] instead. > > > > > --- > > > > > > Section 1 > > > s/(BFD)[RFC5880], [RFC5884]session/(BFD) [RFC5880], [RFC5884] > session/ > > > s/In this document, term bidirectional LSP/In this document, the > term > > > bidirectional LSP/ > > > > OK. > > > > > > > > --- > > > > > > Section 3.1 > > > > > > OLD > > > The recommended value of the Reply via Specified Path mode is 5 > (This > > > is to be confirmed by the IANA). > > > > > > Value Meaning > > > ----- ------- > > > 5 Reply via Specified Path > > > NEW > > > The value of the Reply via Specified Path mode is 5 (This has > been > > > allocated by IANA using early allocation and is to be confirmed > by > > > IANA). > > > > > > Value Meaning > > > ----- ------- > > > 5 Reply via Specified Path > > > END > > > > OK. > > > > > > > > --- > > > > > > Section 3.2 > > > > > > OLD > > > The Reply Path (RP) TLV is an optional TLV, if the Reply via > > > Specified Path mode requested, the Reply Path (RP) TLV MUST be > > > included in an echo request message. It carries the specified > return > > > paths that the echo reply message is required to follow. The > format > > > of Reply Path TLV is as follows: > > > > > > NEW > > > The Reply Path (RP) TLV is an optional TLV within the LSP Ping > > > protocol. However, if the Reply via Specified Path mode > requested as > > > described in Section 3.1, the Reply Path (RP) TLV MUST be > included in > > > an echo request message and its absence is treated as a = malformed > > > echo request as described in [RFC4379]. Furthermore, if a = Reply > Path > > > (RP) TLV is included in an echo request message, a Reply Path > (RP) > > > TLV MUST be included in the corresponding echo reply message = sent > by > > > an implementation that is conformant to this specification. > > > > > > The Reply Path (RP) TLV carries the specified return path that > the > > > echo reply message is required to follow. The format of Reply > Path > > > TLV is as follows: > > > END > > > > OK. > > > > > > > > --- > > > > > > Section 3.2 > > > > > > OLD > > > Reply Path TLV Type field is 2 octets in length, and the type > value > > > is TBD by IANA. > > > NEW > > > Reply Path TLV Type field is 2 octets in length, and the type > value > > > is 21. (This has been allocated by IANA using early allocation > and is > > > to be confirmed by IANA). > > > END > > > > OK. > > > > > > > > --- > > > > > > Section 3.2 > > > > > > OLD > > > Reply Path return code is 2 octets in length. It is defined = for > the > > > egress LSR of the forward LSP to report the results of Reply = Path > TLV > > > processing and return path selection. When sending echo = request, > > > these codes MUST be set to zero. Reply Path return code only > used > > > when sending echo reply, and it MUST be ignored when processing > echo > > > request message. This document defines the following Reply = Path > > > return codes: > > > NEW > > > The Reply Path return code field is 2 octets in length. It is > > > defined for the egress LSR of the forward LSP to report the > results > > > of Reply Path TLV processing and return path selection. This > field > > > MUST be set to zero in a Reply Path TLV carried on an echo > request > > > message and MUST be ignored on receipt. This document defines > the > > > following Reply Path return codes for inclusion in a Reply Path > TLV > > > carried on an echo reply: > > > END > > > > OK. > > > > > > > > --- > > > > > > Section 3.2 > > > > > > Value Meaning > > > ------ ---------------------- > > > 0x0000 No return code > > > > > > What does "No return code" mean? I thought it might have been the > value > > > that you should return if the TLV has been successfully processed > but > > > you seem to have 0x0003 for this. So, how is 0x0000 used? > > > > It should be named as "Reserved". > > > > > > > > --- > > > > > > Section 3.2 > > > > > > 0x0006 The Reply mode in echo request was not set to 5 > (Reply > > > via Specified Path) although Reply Path TLV = exists > > > > > > > 0x0007 Reply Path TLV was missing in echo request > > > > > > Surely these are malformed echo requests and will be handled with > > > normal echo replies with return code value 1. > > > > Yes, indeed, will remove this two codes. > > > > > > > > --- > > > > > > Section 3.2 > > > > > > The A bit and B bit set MUST NOT both be set, otherwise, an = echo > > > reply with the RP return code set to "Malformed RP TLV was > received" > > > SHOULD be returned. > > > > > > What other options are there? I.e. why "SHOULD" not "MUST"? > > > > Actually, there is no other options, MUST should be more precise. > > > > > > > > --- > > > > > > Section 3.2 > > > > > > OLD > > > The Reply Paths field is variable in length, not more than one > sub- > > > TLV MUST be carried, which describes the specified path that = the > echo > > > reply message is required to follow. When the Reply Mode field > is > > > set to "Reply via Specified Path" in an LSP echo request = message, > the > > > Reply Path TLV MUST be present. The Reply Path TLV SHALL only = be > > > used in the reply mode defined in this document (Reply via > Specified > > > Path). > > > NEW > > > The Reply Paths field is variable in length and MUST contain = zero > or > > > one sub-TLV. The sub-TLV, if present, describes the specified > path > > > that the echo reply message is required to follow. > > > END > > > > > > --- > > > > > > Section 3.2 > > > > > > When the Reply Mode field is set to "Reply via Specified Path" = in > an > > > LSP echo request message, the Reply Path TLV MUST be present. > > > > > > I think this is a duplication of a previous statement and can be > removed > > > > Yes. > > > > > > > > --- > > > > > > Section 3.2 > > > > > > The Reply Path TLV SHALL only be > > > used in the reply mode defined in this document (Reply via > Specified > > > Path). > > > > > > Why do you need this? And can it be enforced? > > > It is very unusual to restrict the use of information in this way. = I > > > understand that you do not have any other use in mind, but is = there > a > > > need to make this constraint. > > > > This is for resolving one last call comment: how to handle the > situation that a Reply Path TLV is carried but the reply mode is not = set > to 5, this should not be allowed (implicitly) so far and the echo > request should be a Malformed message. > > > > I personally do not prefer to add this constraint, because we cannot > guarantee that it will never be used in other modes in the future. I = am > OK to remove it. > > > > > > > > --- > > > > > > Section 3.3 > > > > > > In [RFC4379], the range of 31744-32767 and 64512-65535 for > sub-TLVs > > > is specified for Vendor Private Use, and MUST NOT be allocated. > This > > > document changes that rule to make it not applicable to Reply > Path > > > TLV and redefines the rule as in Section 6.2 . If an > implementation > > > recognizes any specific Vendor Private types as defined in > [RFC4379], > > > and uses the sub-TLV type specified in this document, care must > be > > > taken to ensure that the implementation does not confuse the = two > > > usages. > > > > > > I don't think this draft changes the registry for 4379, does it? > > > This needs a little more care to separate the two uses clearly. = How > > > about... > > > > I think it does not change the registry for 4379, but it does = changes > rule that RFC4379 specifies to TLVs and sub-TLVs. RFC4379 specifies = that > the range of 31744-32767 and 64512-65535 for sub-TLVs is specified for > Vendor Private Use, this draft changes this. > > > > But I agree with your suggestion below :-) > > > > > > > > OLD > > > Each of the FEC sub-TLVs (include existing and future defined) > for > > > the Target FEC Stack TLV[RFC4379] is applicable to be a sub-TLV > for > > > inclusion in the Reply Path TLV for expressing a specific = return > > > path. For these shared sub-TLVs, they share the same registry > with > > > the Target FEC Stack TLV for the range of 0-31743 and > 32768-64511. > > > > > > In addition, this document defines three new sub-TLVs: IPv4 = RSVP > > > Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV and Static Tunnel > sub-TLV. > > > These sub-TLVs are only designed for Reply Path TLV, hence this > > > document calls them dedicated sub-TLVs to Reply Path TLV. For > these > > > dedicated sub-TLVs, this document will create a new registry > (Section > > > 6.1), the sub-TLV type MUST be allocated from the new registry. > > > Detailed definition is in the following sections. > > > > > > In [RFC4379], the range of 31744-32767 and 64512-65535 for > sub-TLVs > > > is specified for Vendor Private Use, and MUST NOT be allocated. > This > > > document changes that rule to make it not applicable to Reply > Path > > > TLV and redefines the rule as in Section 6.2 . If an > implementation > > > recognizes any specific Vendor Private types as defined in > [RFC4379], > > > and uses the sub-TLV type specified in this document, care must > be > > > taken to ensure that the implementation does not confuse the = two > > > usages. > > > NEW > > > The FECs defined in [RFC4379] provide a good way to identify a > > > specific return path. The FEC sub-TLVs (including existing and > > > future sub-TLVs) of the Target FEC Stack TLV [RFC4379] have > sub-TLV > > > types assigned from a registry with ranges as follows: > > > > > > 0-16383 Standards Action mandatory TLV > > > 16384-31743 Specification Required, Experimental RFC = needed > > > 31744-32767 Vendor Private Use, MUST NOT be allocated > > > 32768-49161 Standards Action optional TLV > > > 49162-64511 Specification Required, Experimental RFC = needed > > > 64512-65535 Vendor Private Use, MUST NOT be allocated > > > > > > The Reply Path TLV can carry and sub-TLV defined for use in the > > > > > > Should the "carry and sub-TLV" be "carry the sub-TLV"? > > > > > Target FEC Stack TLV that can be registered. Thus the ranges > > > 0-31743 and 32768-64511 are shared by the registries, with the > new > > > Reply Path Sub-TLVs registry "borrowing" values from the Target > FEC > > > Stack TLV registry. > > > > > > Allocations from the ranges 31744-32767 and 64512-65535 are not > > > recorded in the registry for Target FEC Stack TLVs, so these > ranges > > > are safely made available in the Reply Path Sub-TLVs registry > (see > > > Section 6.1) to record sub-TLVs that are specific to the Reply > Path > > > TLV. This document defines three sub-TLVs specific to the = Reply > Path > > > TLV: IPv4 RSVP Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and > Static > > > Tunnel sub-TLV. > > > > > > Note that an implementation that supports specific Vendor = Private > > > for sub-TLVs of the Target FEC Stack must take care to not > confuse > > > those values with the same values allocated from the Reply Path > Sub- > > > TLVs registry. > > > END > > > > > > --- > > > > > > Section 3.3 > > > > > > 2. Specify a more generic tunnel FEC as return path > > > > > > It is clear that 3.3.1 and 3.3.2 define a FEC that is more general > than > > > the FECs in 4379. What is not clear is the use case. I think you > need > > > some text in this document to say what you should do with one of > these > > > FECs since it possibly identifies a set of LSPs. > > > > There is another draft > = (http://tools.ietf.org/html/draft-chen-mpls-bfd-enhancement-00#section-4 > .2 ) discusses the usage of the generic Tunnel sub-TLV. How about add > the following text: > > > > One usage of this generic RSVP Tunnel sub-TLV is for bootstrapping = BFD > session on an MPLS Tunnel that has primary and secondary LSPs, > especially when Make-Before-Break (MBB) is deployed. The usage is > discussed in the Section 4.2 of [I-D.chen-mpls-bfd-enhancement]. > > > > > > > > --- > > > > > > Section 3.3.1 > > > > > > OLD > > > The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, > and > > > the recommended type value is TBD. > > > NEW > > > The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, > and > > > the recommended type value is TBD1. > > > END > > > > OK. > > > > > > > > --- > > > > > > Section 3.3.1 > > > > > > It is slightly weird that the bit field in this section allocates > the > > > first two bits while the field in section 3.2 allocates the last = two > > > bits. This is not significantly important, but is odd. > > > > Will change it and make them consistent. > > > > > > --- > > > > > > Section 3.3.2 > > > > > > OLD > > > The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, > and > > > the type value is TBD. > > > NEW > > > The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, > and > > > the type value is TBD2. > > > END > > > > OK. > > > > > > > > --- > > > > > > Section 3.3.3 > > > > > > RFC 6370 seems to also include an "LSP_Num". So your 3.3.3 case is > the > > > MPLS-TP static equivalent of 3.3.1. But you are missing: > > > > > > - the MPLS-TP static equivalent of 3.3.2 (i.e. v6 identifiers) > > > - the MPLS-TP equivalent of the 4379 RSVP LSP FECs > > > > > > Do you need them? > > > > No, we do not need them, MPLS-TP has not v6 identifiers, and the > MPLS-TP equivalent of the 4379 RSVP LSP FECs belongs to the existing > sub-TLVs of Target FEC TLV and are already defined in TP related RFC. > > > > > > > > --- > > > > > > Section 3.3.3 > > > > > > OLD > > > The sub-TLV type value is TBD. > > > NEW > > > The sub-TLV type value is TBD3. > > > END > > > > > OK. > > > > > --- > > > > > > Section 3.4 > > > > > > OLD > > > The Reply TC TLV Type field is 2 octets in length, and the type > value > > > is TBD. > > > NEW > > > The Reply TC TLV Type field is 2 octets in length, and the type > value > > > is TBD4. > > > END > > > > > > > OK. > > > > > --- > > > > > > Section 4 > > > > > > The procedures defined in this document currently only apply to > > > "ping" mode. The "traceroute" mode is out of scope for this > > > document. > > > > > > I think this should show up in the Introduction and possibly the > > > Abstract. > > > > OK. > > > > > > > > --- > > > > > > Section 6 > > > > > > Please consider whether you want registries for the bit fields you > > > define in this document. > > > > > > --- > > > > > > Section 6.1 > > > > > > OLD > > > TBD Reply TC TLV this document (sect > 3.4) > > > NEW > > > TBD4 Reply TC TLV this document (sect > 3.4) > > > END > > > > > OK > > > > > --- > > > > > > Section 6.4 > > > > > > OLD > > > TBD Reply TC TLV this document (sect > 3.4) > > > NEW > > > TBD4 Reply TC TLV this document (sect > 3.4) > > > END > > > > > OK. > > > > > --- > > > > > > Section 6.2.1 > > > > > > OLD > > > Sub-type Value Field Reference > > > ------- ----------- --------- > > > TBD IPv4 RSVP Tunnel this document (sect = 3.3.1) > > > TBD IPv6 RSVP Tunnel this document (sect = 3.3.2) > > > TBD Static Tunnel this document (sect = 3.3.3) > > > NEW > > > Sub-type Value Field Reference > > > ------- ----------- --------- > > > TBD1 IPv4 RSVP Tunnel this document (sect = 3.3.1) > > > TBD2 IPv6 RSVP Tunnel this document (sect = 3.3.2) > > > TBD3 Static Tunnel this document (sect = 3.3.3) > > > END > > > > > > --- > > > > > > Section 6.3 > > > > > > OLD > > > IANA is now requested to assign the previously assigned a new > reply > > > mode code point (5 - Reply via specified path) from the "Multi- > > > Protocol Label Switching (MPLS) Label Switched Paths (LSPs) = Ping > > > Parameters" registry, the "Reply Mode" sub-registry on a > permanent > > > basis. > > > NEW > > > IANA has made an early allocation (5 - Reply via specified = path) > from > > > the "Multi-Protocol Label Switching (MPLS) Label Switched Paths > > > (LSPs) Ping Parameters" registry, the "Reply Mode" = sub-registry. > IANA > > > is requested to make this allocation permanent. > > > END > > > > OK. > > From mach.chen@huawei.com Thu Oct 18 19:46:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E083A21F852C for ; Thu, 18 Oct 2012 19:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.938 X-Spam-Level: ** X-Spam-Status: No, score=2.938 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljuRQf3XHbCz for ; Thu, 18 Oct 2012 19:46:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC4521F8512 for ; Thu, 18 Oct 2012 19:46:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALU58836; Fri, 19 Oct 2012 02:46:08 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 19 Oct 2012 03:45:12 +0100 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 19 Oct 2012 03:46:06 +0100 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.129]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 19 Oct 2012 10:46:03 +0800 From: Mach Chen To: "adrian@olddog.co.uk" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" Thread-Topic: [mpls] AD review of draft-ietf-mpls-return-path-specified-lsp-ping Thread-Index: Ac2spr9U20RDhLSITuSsaaLzMUzfUwAN1YYQABkz94AAGDMfwA== Date: Fri, 19 Oct 2012 02:46:02 +0000 Message-ID: References: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> <092b01cdad86$0c9fe200$25dfa600$@olddog.co.uk> In-Reply-To: <092b01cdad86$0c9fe200$25dfa600$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW1w?= =?gb2312?b?bHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5n?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 02:46:12 -0000 QWRyaWFuLA0KDQpDb29sISBJIHdpbGwgdHJ5IHRvIHN1Ym1pdCB0aGUgdXBkYXRlIGJlZm9yZSB0 aGUgZGVhZGxpbmUhDQoNClRoYW5rcywNCk1hY2gNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4g t6K8/sjLOiBBZHJpYW4gRmFycmVsIFttYWlsdG86YWRyaWFuQG9sZGRvZy5jby51a10NCj4gt6LL zcqxvOQ6IDIwMTLE6jEw1MIxOcjVIDc6MTINCj4gytW8/sjLOiBNYWNoIENoZW47DQo+IGRyYWZ0 LWlldGYtbXBscy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmcuYWxsQHRvb2xzLmlldGYu b3JnDQo+ILOty806IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+ INb3zOI6IFJFOiBbbXBsc10gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbXBscy1yZXR1cm4tcGF0 aC1zcGVjaWZpZWQtbHNwLXBpbmcNCj4gDQo+IEhpIE1hY2gsDQo+IA0KPiBUaGlzIGxvb2tzIGdv b2QuDQo+IA0KPiA+IFNob3VsZCB0aGUgImNhcnJ5IGFuZCBzdWItVExWIiBiZSAiY2FycnkgdGhl IHN1Yi1UTFYiPw0KPiBZZXMuIFRvbyBtYW55IGZpbmdlcnMgZXJyb3IuDQo+IA0KPiBPdGhlcndp c2UgSSBhZ3JlZSBhbGwgeW91ciBwcm9wb3NlZCBjaGFuZ2VzIGFuZCBhbnN3ZXJzLg0KPiANCj4g SSdsbCBsb29rIGZvciB0aGUgcmV2aXNlZCBJLUQgYW5kIGFkdmFuY2Ugd2hlbiBJIHNlZSBpdC4g RG9uJ3QgZm9yZ2V0IHRoZQ0KPiBjdXQtb2ZmIGRhdGUhDQo+IA0KPiBDaGVlcnMsDQo+IEFkcmlh bg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1hY2ggQ2hl biBbbWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IDE4IE9jdG9iZXIgMjAx MiAwOTo1Ng0KPiA+IFRvOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBkcmFmdC1pZXRmLW1wbHMtcmV0 dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC0NCj4gPiBwaW5nLmFsbEB0b29scy5pZXRmLm9yZw0KPiA+ IENjOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiA+IFN1Ympl Y3Q6ILTwuLQ6IFttcGxzXSBBRCByZXZpZXcgb2YNCj4gZHJhZnQtaWV0Zi1tcGxzLXJldHVybi1w YXRoLXNwZWNpZmllZC1sc3AtcGluZw0KPiA+DQo+ID4gQWRyaWFuLA0KPiA+DQo+ID4gTWFueSB0 aGFua3MgZm9yIHlvdXIgZGV0YWlsIHJldmlldyBhbmQgY29tbWVudHMhDQo+ID4NCj4gPiBQbGVh c2Ugc2VlIG15IHJlc3BvbnNlIGlubGluZS4uLg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+ IE1hY2gNCj4gPg0KPiA+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gPiC3orz+yMs6IG1wbHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7Q0KPiBB ZHJpYW4NCj4gPiA+IEZhcnJlbA0KPiA+ID4gt6LLzcqxvOQ6IDIwMTLE6jEw1MIxOMjVIDQ6MzUN Cj4gPiA+IMrVvP7IyzogZHJhZnQtaWV0Zi1tcGxzLXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3At cGluZy5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4gPiA+ILOty806IG1wbHNAaWV0Zi5vcmc7IG1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnDQo+ID4gPiDW98ziOiBbbXBsc10gQUQgcmV2aWV3IG9mIGRy YWZ0LWlldGYtbXBscy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmcNCj4gPiA+DQo+ID4g PiBIaSwNCj4gPiA+DQo+ID4gPiBJJ3ZlIGRvbmUgbXkgdXN1YWwgQUQgcmV2aWV3IG9mIHlvdXIg ZHJhZnQgcHJpb3IgdG8gaXNzdWluZyBJRVRGIGxhc3QNCj4gPiA+IGNhbGwgYW5kIHBhc3Npbmcg dGhlIEktRCBmb3IgSUVTRyBldmFsdWF0aW9uLiBUaGUgbWFpbiBwdXJwb3NlIG9mIHRoZQ0KPiA+ ID4gcmV2aWV3IGlzIHRvIGNhdGNoIGlzc3VlcyB0aGF0IG1pZ2h0IGNvbWUgdXAgaW4gbGF0ZXIg cmV2aWV3cyBhbmQgdG8NCj4gPiA+IGVuc3VyZSB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSBm b3IgcHVibGljYXRpb24gYXMgYW5kIFJGQy4NCj4gPiA+DQo+ID4gPiBJIGZvdW5kIFNlY3Rpb24g NCB2ZXJ5IGdvb2QuIEl0IGNvbXBsZXRlbHkgZXhwbGFpbnMgdG8gbWUgd2hhdCBpcw0KPiA+ID4g Z29pbmcgb24gaW4gdGhlIHByb3RvY29sIGV4dGVuc2lvbiwgYW5kIGNvdmVyZWQgYWxsIHRoZSBj b3JuZXIgY2FzZXMNCj4gPiA+IEkgY291bGQgdGhpbmsgb2YuIE9uIHRoZSBvdGhlciBoYW5kLCBT ZWN0aW9uIDMgbWFkZSBtZSBnZW5lcmF0ZSBhDQo+ID4gPiByZWFsbHkgKHJlYWxseSwgcmVhbGx5 KSBsb25nIGxpc3Qgb2YgcmVsYXRpdmVseSBtaW5vciBpc3N1ZXMuIFRoaXMNCj4gPiA+IGxpc3Qg aXMgc28gbG9uZyB0aGF0IEkgdGhpbmsgeW91IG5lZWQgdG8gcHJvdmlkZSBhIG5ldyByZXZpc2lv bg0KPiA+ID4gYmVmb3JlIHdlIGlzc3VlIHRoZSBJRVRGIGxhc3QgY2FsbC4gSSB3aWxsIHB1dCB0 aGUgSS1EIGludG8gIlJldmlzZWQNCj4gPiA+IEktRCBOZWVkZWQiIHN0YXRlIGFuZCB3YWl0IGZv ciB0aGUgcmV2aXNpb24uDQo+ID4gPg0KPiA+ID4gQXMgYWx3YXlzLCBhbGwgbXkgY29tbWVudHMg YXJlIHVwIGZvciBkaXNjdXNzaW9uIGFuZCBuZWdvdGlhdGlvbi4NCj4gPiA+DQo+ID4gPiBUaGFu a3MgZm9yIHRoZSB3b3JrLA0KPiA+ID4gQWRyaWFuDQo+ID4gPg0KPiA+ID4gPT09DQo+ID4gPg0K PiA+ID4gQ29uc2lzdGVuY3kgb2YgcmVmZXJlbmNlcyBmb3IgYmlkaXJlY3Rpb25hbCBMU1AuIElu IFNlY3Rpb24gMSB5b3UgaGF2ZQ0KPiA+ID4gICAgSW4gdGhpcyBkb2N1bWVudCwgdGVybSBiaWRp cmVjdGlvbmFsIExTUCBpbmNsdWRlcyB0aGUgY28tcm91dGVkDQo+ID4gPiAgICBiaWRpcmVjdGlv bmFsIExTUCBkZWZpbmVkIGluIFtSRkMzOTQ1XQ0KPiA+ID4gSW4gU2VjdGlvbiAyIHlvdSBoYXZl Og0KPiA+ID4gICAgVGhlIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCBpcyBkZWZpbmVkIGlu IFtSRkMzNDcxXQ0KPiA+ID4gICAgYW5kIFtSRkMzNDczXQ0KPiA+ID4NCj4gPiBPSywgd2lsbCBj b25zaXN0ZW50bHkgcmVmZXIgdG8gW1JGQzM5NDVdIGluc3RlYWQuDQo+ID4NCj4gPiA+IC0tLQ0K PiA+ID4NCj4gPiA+IFNlY3Rpb24gMQ0KPiA+ID4gcy8oQkZEKVtSRkM1ODgwXSwgW1JGQzU4ODRd c2Vzc2lvbi8oQkZEKSBbUkZDNTg4MF0sIFtSRkM1ODg0XSBzZXNzaW9uLw0KPiA+ID4gcy9JbiB0 aGlzIGRvY3VtZW50LCB0ZXJtIGJpZGlyZWN0aW9uYWwgTFNQL0luIHRoaXMgZG9jdW1lbnQsIHRo ZSB0ZXJtDQo+ID4gPiBiaWRpcmVjdGlvbmFsIExTUC8NCj4gPg0KPiA+IE9LLg0KPiA+DQo+ID4g Pg0KPiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiAzLjENCj4gPiA+DQo+ID4gPiBPTEQN Cj4gPiA+ICAgIFRoZSByZWNvbW1lbmRlZCB2YWx1ZSBvZiB0aGUgUmVwbHkgdmlhIFNwZWNpZmll ZCBQYXRoIG1vZGUgaXMgNSAoVGhpcw0KPiA+ID4gICAgaXMgdG8gYmUgY29uZmlybWVkIGJ5IHRo ZSBJQU5BKS4NCj4gPiA+DQo+ID4gPiAgICAgICAgVmFsdWUgICAgTWVhbmluZw0KPiA+ID4gICAg ICAgIC0tLS0tICAgIC0tLS0tLS0NCj4gPiA+ICAgICAgICAgICAgNSAgICAgUmVwbHkgdmlhIFNw ZWNpZmllZCBQYXRoDQo+ID4gPiBORVcNCj4gPiA+ICAgIFRoZSB2YWx1ZSBvZiB0aGUgUmVwbHkg dmlhIFNwZWNpZmllZCBQYXRoIG1vZGUgaXMgNSAoVGhpcyBoYXMgYmVlbg0KPiA+ID4gICAgYWxs b2NhdGVkIGJ5IElBTkEgdXNpbmcgZWFybHkgYWxsb2NhdGlvbiBhbmQgaXMgdG8gYmUgY29uZmly bWVkIGJ5DQo+ID4gPiAgICBJQU5BKS4NCj4gPiA+DQo+ID4gPiAgICAgICAgVmFsdWUgICAgTWVh bmluZw0KPiA+ID4gICAgICAgIC0tLS0tICAgIC0tLS0tLS0NCj4gPiA+ICAgICAgICAgICAgNSAg ICAgUmVwbHkgdmlhIFNwZWNpZmllZCBQYXRoDQo+ID4gPiBFTkQNCj4gPg0KPiA+IE9LLg0KPiA+ DQo+ID4gPg0KPiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiAzLjINCj4gPiA+DQo+ID4g PiBPTEQNCj4gPiA+ICAgIFRoZSBSZXBseSBQYXRoIChSUCkgVExWIGlzIGFuIG9wdGlvbmFsIFRM ViwgaWYgdGhlIFJlcGx5IHZpYQ0KPiA+ID4gICAgU3BlY2lmaWVkIFBhdGggbW9kZSByZXF1ZXN0 ZWQsIHRoZSBSZXBseSBQYXRoIChSUCkgVExWIE1VU1QgYmUNCj4gPiA+ICAgIGluY2x1ZGVkIGlu IGFuIGVjaG8gcmVxdWVzdCBtZXNzYWdlLiAgSXQgY2FycmllcyB0aGUgc3BlY2lmaWVkIHJldHVy bg0KPiA+ID4gICAgcGF0aHMgdGhhdCB0aGUgZWNobyByZXBseSBtZXNzYWdlIGlzIHJlcXVpcmVk IHRvIGZvbGxvdy4gIFRoZSBmb3JtYXQNCj4gPiA+ICAgIG9mIFJlcGx5IFBhdGggVExWIGlzIGFz IGZvbGxvd3M6DQo+ID4gPg0KPiA+ID4gTkVXDQo+ID4gPiAgICBUaGUgUmVwbHkgUGF0aCAoUlAp IFRMViBpcyBhbiBvcHRpb25hbCBUTFYgd2l0aGluIHRoZSBMU1AgUGluZw0KPiA+ID4gICAgcHJv dG9jb2wuICBIb3dldmVyLCBpZiB0aGUgUmVwbHkgdmlhIFNwZWNpZmllZCBQYXRoIG1vZGUgcmVx dWVzdGVkIGFzDQo+ID4gPiAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjEsIHRoZSBSZXBseSBQ YXRoIChSUCkgVExWIE1VU1QgYmUgaW5jbHVkZWQgaW4NCj4gPiA+ICAgIGFuIGVjaG8gcmVxdWVz dCBtZXNzYWdlIGFuZCBpdHMgYWJzZW5jZSBpcyB0cmVhdGVkIGFzIGEgbWFsZm9ybWVkDQo+ID4g PiAgICBlY2hvIHJlcXVlc3QgYXMgZGVzY3JpYmVkIGluIFtSRkM0Mzc5XS4gIEZ1cnRoZXJtb3Jl LCBpZiBhIFJlcGx5IFBhdGgNCj4gPiA+ICAgIChSUCkgVExWIGlzIGluY2x1ZGVkIGluIGFuIGVj aG8gcmVxdWVzdCBtZXNzYWdlLCBhIFJlcGx5IFBhdGggKFJQKQ0KPiA+ID4gICAgVExWIE1VU1Qg YmUgaW5jbHVkZWQgaW4gdGhlIGNvcnJlc3BvbmRpbmcgZWNobyByZXBseSBtZXNzYWdlIHNlbnQg YnkNCj4gPiA+ICAgIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgaXMgY29uZm9ybWFudCB0byB0aGlz IHNwZWNpZmljYXRpb24uDQo+ID4gPg0KPiA+ID4gICAgVGhlIFJlcGx5IFBhdGggKFJQKSBUTFYg Y2FycmllcyB0aGUgc3BlY2lmaWVkIHJldHVybiBwYXRoIHRoYXQgdGhlDQo+ID4gPiAgICBlY2hv IHJlcGx5IG1lc3NhZ2UgaXMgcmVxdWlyZWQgdG8gZm9sbG93LiAgVGhlIGZvcm1hdCBvZiBSZXBs eSBQYXRoDQo+ID4gPiAgICBUTFYgaXMgYXMgZm9sbG93czoNCj4gPiA+IEVORA0KPiA+DQo+ID4g T0suDQo+ID4NCj4gPiA+DQo+ID4gPiAtLS0NCj4gPiA+DQo+ID4gPiBTZWN0aW9uIDMuMg0KPiA+ ID4NCj4gPiA+IE9MRA0KPiA+ID4gICAgUmVwbHkgUGF0aCBUTFYgVHlwZSBmaWVsZCBpcyAyIG9j dGV0cyBpbiBsZW5ndGgsIGFuZCB0aGUgdHlwZSB2YWx1ZQ0KPiA+ID4gICAgaXMgVEJEIGJ5IElB TkEuDQo+ID4gPiBORVcNCj4gPiA+ICAgIFJlcGx5IFBhdGggVExWIFR5cGUgZmllbGQgaXMgMiBv Y3RldHMgaW4gbGVuZ3RoLCBhbmQgdGhlIHR5cGUgdmFsdWUNCj4gPiA+ICAgIGlzIDIxLiAoVGhp cyBoYXMgYmVlbiBhbGxvY2F0ZWQgYnkgSUFOQSB1c2luZyBlYXJseSBhbGxvY2F0aW9uIGFuZCBp cw0KPiA+ID4gICAgdG8gYmUgY29uZmlybWVkIGJ5IElBTkEpLg0KPiA+ID4gRU5EDQo+ID4NCj4g PiBPSy4NCj4gPg0KPiA+ID4NCj4gPiA+IC0tLQ0KPiA+ID4NCj4gPiA+IFNlY3Rpb24gMy4yDQo+ ID4gPg0KPiA+ID4gT0xEDQo+ID4gPiAgICBSZXBseSBQYXRoIHJldHVybiBjb2RlIGlzIDIgb2N0 ZXRzIGluIGxlbmd0aC4gIEl0IGlzIGRlZmluZWQgZm9yIHRoZQ0KPiA+ID4gICAgZWdyZXNzIExT UiBvZiB0aGUgZm9yd2FyZCBMU1AgdG8gcmVwb3J0IHRoZSByZXN1bHRzIG9mIFJlcGx5IFBhdGgg VExWDQo+ID4gPiAgICBwcm9jZXNzaW5nIGFuZCByZXR1cm4gcGF0aCBzZWxlY3Rpb24uICBXaGVu IHNlbmRpbmcgZWNobyByZXF1ZXN0LA0KPiA+ID4gICAgdGhlc2UgY29kZXMgTVVTVCBiZSBzZXQg dG8gemVyby4gIFJlcGx5IFBhdGggcmV0dXJuIGNvZGUgb25seSB1c2VkDQo+ID4gPiAgICB3aGVu IHNlbmRpbmcgZWNobyByZXBseSwgYW5kIGl0IE1VU1QgYmUgaWdub3JlZCB3aGVuIHByb2Nlc3Np bmcNCj4gZWNobw0KPiA+ID4gICAgcmVxdWVzdCBtZXNzYWdlLiAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIHRoZSBmb2xsb3dpbmcgUmVwbHkgUGF0aA0KPiA+ID4gICAgcmV0dXJuIGNvZGVzOg0KPiA+ ID4gTkVXDQo+ID4gPiAgICBUaGUgUmVwbHkgUGF0aCByZXR1cm4gY29kZSBmaWVsZCBpcyAyIG9j dGV0cyBpbiBsZW5ndGguICBJdCBpcw0KPiA+ID4gICAgZGVmaW5lZCBmb3IgdGhlIGVncmVzcyBM U1Igb2YgdGhlIGZvcndhcmQgTFNQIHRvIHJlcG9ydCB0aGUgcmVzdWx0cw0KPiA+ID4gICAgb2Yg UmVwbHkgUGF0aCBUTFYgcHJvY2Vzc2luZyBhbmQgcmV0dXJuIHBhdGggc2VsZWN0aW9uLiAgVGhp cyBmaWVsZA0KPiA+ID4gICAgTVVTVCBiZSBzZXQgdG8gemVybyBpbiBhIFJlcGx5IFBhdGggVExW IGNhcnJpZWQgb24gYW4gZWNobyByZXF1ZXN0DQo+ID4gPiAgICBtZXNzYWdlIGFuZCBNVVNUIGJl IGlnbm9yZWQgb24gcmVjZWlwdC4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUNCj4gPiA+ICAg IGZvbGxvd2luZyBSZXBseSBQYXRoIHJldHVybiBjb2RlcyBmb3IgaW5jbHVzaW9uIGluIGEgUmVw bHkgUGF0aCBUTFYNCj4gPiA+ICAgIGNhcnJpZWQgb24gYW4gZWNobyByZXBseToNCj4gPiA+IEVO RA0KPiA+DQo+ID4gT0suDQo+ID4NCj4gPiA+DQo+ID4gPiAtLS0NCj4gPiA+DQo+ID4gPiBTZWN0 aW9uIDMuMg0KPiA+ID4NCj4gPiA+ICAgIFZhbHVlICAgICAgICAgTWVhbmluZw0KPiA+ID4gICAg LS0tLS0tICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiAgICAweDAwMDAgICAg ICAgIE5vIHJldHVybiBjb2RlDQo+ID4gPg0KPiA+ID4gV2hhdCBkb2VzICJObyByZXR1cm4gY29k ZSIgbWVhbj8gSSB0aG91Z2h0IGl0IG1pZ2h0IGhhdmUgYmVlbiB0aGUgdmFsdWUNCj4gPiA+IHRo YXQgeW91IHNob3VsZCByZXR1cm4gaWYgdGhlIFRMViBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgcHJv Y2Vzc2VkIGJ1dA0KPiA+ID4geW91IHNlZW0gdG8gaGF2ZSAweDAwMDMgZm9yIHRoaXMuIFNvLCBo b3cgaXMgMHgwMDAwIHVzZWQ/DQo+ID4NCj4gPiBJdCBzaG91bGQgYmUgbmFtZWQgYXMgIlJlc2Vy dmVkIi4NCj4gPg0KPiA+ID4NCj4gPiA+IC0tLQ0KPiA+ID4NCj4gPiA+IFNlY3Rpb24gMy4yDQo+ ID4gPg0KPiA+ID4gICAgMHgwMDA2ICAgICAgICBUaGUgUmVwbHkgbW9kZSBpbiBlY2hvIHJlcXVl c3Qgd2FzIG5vdCBzZXQgdG8gNQ0KPiAoUmVwbHkNCj4gPiA+ICAgICAgICAgICAgICAgICAgdmlh IFNwZWNpZmllZCBQYXRoKSBhbHRob3VnaCBSZXBseSBQYXRoIFRMViBleGlzdHMNCj4gPg0KPiA+ DQo+ID4gPiAgICAweDAwMDcgICAgICAgIFJlcGx5IFBhdGggVExWIHdhcyBtaXNzaW5nIGluIGVj aG8gcmVxdWVzdA0KPiA+ID4NCj4gPiA+IFN1cmVseSB0aGVzZSBhcmUgbWFsZm9ybWVkIGVjaG8g cmVxdWVzdHMgYW5kIHdpbGwgYmUgaGFuZGxlZCB3aXRoDQo+ID4gPiBub3JtYWwgZWNobyByZXBs aWVzIHdpdGggcmV0dXJuIGNvZGUgdmFsdWUgMS4NCj4gPg0KPiA+IFllcywgaW5kZWVkLCB3aWxs IHJlbW92ZSB0aGlzIHR3byBjb2Rlcy4NCj4gPg0KPiA+ID4NCj4gPiA+IC0tLQ0KPiA+ID4NCj4g PiA+IFNlY3Rpb24gMy4yDQo+ID4gPg0KPiA+ID4gICAgVGhlIEEgYml0IGFuZCBCIGJpdCBzZXQg TVVTVCBOT1QgYm90aCBiZSBzZXQsIG90aGVyd2lzZSwgYW4gZWNobw0KPiA+ID4gICAgcmVwbHkg d2l0aCB0aGUgUlAgcmV0dXJuIGNvZGUgc2V0IHRvICJNYWxmb3JtZWQgUlAgVExWIHdhcyByZWNl aXZlZCINCj4gPiA+ICAgIFNIT1VMRCBiZSByZXR1cm5lZC4NCj4gPiA+DQo+ID4gPiBXaGF0IG90 aGVyIG9wdGlvbnMgYXJlIHRoZXJlPyBJLmUuIHdoeSAiU0hPVUxEIiBub3QgIk1VU1QiPw0KPiA+ DQo+ID4gQWN0dWFsbHksIHRoZXJlIGlzIG5vIG90aGVyIG9wdGlvbnMsIE1VU1Qgc2hvdWxkIGJl IG1vcmUgcHJlY2lzZS4NCj4gPg0KPiA+ID4NCj4gPiA+IC0tLQ0KPiA+ID4NCj4gPiA+IFNlY3Rp b24gMy4yDQo+ID4gPg0KPiA+ID4gT0xEDQo+ID4gPiAgICBUaGUgUmVwbHkgUGF0aHMgZmllbGQg aXMgdmFyaWFibGUgaW4gbGVuZ3RoLCBub3QgbW9yZSB0aGFuIG9uZSBzdWItDQo+ID4gPiAgICBU TFYgTVVTVCBiZSBjYXJyaWVkLCB3aGljaCBkZXNjcmliZXMgdGhlIHNwZWNpZmllZCBwYXRoIHRo YXQgdGhlIGVjaG8NCj4gPiA+ICAgIHJlcGx5IG1lc3NhZ2UgaXMgcmVxdWlyZWQgdG8gZm9sbG93 LiAgV2hlbiB0aGUgUmVwbHkgTW9kZSBmaWVsZCBpcw0KPiA+ID4gICAgc2V0IHRvICJSZXBseSB2 aWEgU3BlY2lmaWVkIFBhdGgiIGluIGFuIExTUCBlY2hvIHJlcXVlc3QgbWVzc2FnZSwgdGhlDQo+ ID4gPiAgICBSZXBseSBQYXRoIFRMViBNVVNUIGJlIHByZXNlbnQuICBUaGUgUmVwbHkgUGF0aCBU TFYgU0hBTEwgb25seSBiZQ0KPiA+ID4gICAgdXNlZCBpbiB0aGUgcmVwbHkgbW9kZSBkZWZpbmVk IGluIHRoaXMgZG9jdW1lbnQgKFJlcGx5IHZpYSBTcGVjaWZpZWQNCj4gPiA+ICAgIFBhdGgpLg0K PiA+ID4gTkVXDQo+ID4gPiAgICBUaGUgUmVwbHkgUGF0aHMgZmllbGQgaXMgdmFyaWFibGUgaW4g bGVuZ3RoIGFuZCBNVVNUIGNvbnRhaW4gemVybyBvcg0KPiA+ID4gICAgb25lIHN1Yi1UTFYuICBU aGUgc3ViLVRMViwgaWYgcHJlc2VudCwgZGVzY3JpYmVzIHRoZSBzcGVjaWZpZWQgcGF0aA0KPiA+ ID4gICAgdGhhdCB0aGUgZWNobyByZXBseSBtZXNzYWdlIGlzIHJlcXVpcmVkIHRvIGZvbGxvdy4N Cj4gPiA+IEVORA0KPiA+ID4NCj4gPiA+IC0tLQ0KPiA+ID4NCj4gPiA+IFNlY3Rpb24gMy4yDQo+ ID4gPg0KPiA+ID4gICAgV2hlbiB0aGUgUmVwbHkgTW9kZSBmaWVsZCBpcyBzZXQgdG8gIlJlcGx5 IHZpYSBTcGVjaWZpZWQgUGF0aCIgaW4gYW4NCj4gPiA+ICAgIExTUCBlY2hvIHJlcXVlc3QgbWVz c2FnZSwgdGhlIFJlcGx5IFBhdGggVExWIE1VU1QgYmUgcHJlc2VudC4NCj4gPiA+DQo+ID4gPiBJ IHRoaW5rIHRoaXMgaXMgYSBkdXBsaWNhdGlvbiBvZiBhIHByZXZpb3VzIHN0YXRlbWVudCBhbmQg Y2FuIGJlIHJlbW92ZWQNCj4gPg0KPiA+IFllcy4NCj4gPg0KPiA+ID4NCj4gPiA+IC0tLQ0KPiA+ ID4NCj4gPiA+IFNlY3Rpb24gMy4yDQo+ID4gPg0KPiA+ID4gICAgVGhlIFJlcGx5IFBhdGggVExW IFNIQUxMIG9ubHkgYmUNCj4gPiA+ICAgIHVzZWQgaW4gdGhlIHJlcGx5IG1vZGUgZGVmaW5lZCBp biB0aGlzIGRvY3VtZW50IChSZXBseSB2aWEgU3BlY2lmaWVkDQo+ID4gPiAgICBQYXRoKS4NCj4g PiA+DQo+ID4gPiBXaHkgZG8geW91IG5lZWQgdGhpcz8gIEFuZCBjYW4gaXQgYmUgZW5mb3JjZWQ/ DQo+ID4gPiBJdCBpcyB2ZXJ5IHVudXN1YWwgdG8gcmVzdHJpY3QgdGhlIHVzZSBvZiBpbmZvcm1h dGlvbiBpbiB0aGlzIHdheS4gSQ0KPiA+ID4gdW5kZXJzdGFuZCB0aGF0IHlvdSBkbyBub3QgaGF2 ZSBhbnkgb3RoZXIgdXNlIGluIG1pbmQsIGJ1dCBpcyB0aGVyZSBhDQo+ID4gPiBuZWVkIHRvIG1h a2UgdGhpcyBjb25zdHJhaW50Lg0KPiA+DQo+ID4gVGhpcyBpcyBmb3IgcmVzb2x2aW5nIG9uZSBs YXN0IGNhbGwgY29tbWVudDogaG93IHRvIGhhbmRsZSB0aGUgc2l0dWF0aW9uIHRoYXQNCj4gYQ0K PiA+IFJlcGx5IFBhdGggVExWIGlzIGNhcnJpZWQgYnV0IHRoZSByZXBseSBtb2RlIGlzIG5vdCBz ZXQgdG8gNSwgdGhpcyBzaG91bGQgbm90DQo+IGJlDQo+ID4gYWxsb3dlZCAoaW1wbGljaXRseSkg c28gZmFyIGFuZCB0aGUgZWNobyByZXF1ZXN0IHNob3VsZCBiZSBhIE1hbGZvcm1lZA0KPiBtZXNz YWdlLg0KPiA+DQo+ID4gSSBwZXJzb25hbGx5IGRvIG5vdCBwcmVmZXIgdG8gYWRkIHRoaXMgY29u c3RyYWludCwgYmVjYXVzZSB3ZSBjYW5ub3QNCj4gZ3VhcmFudGVlDQo+ID4gdGhhdCBpdCB3aWxs IG5ldmVyIGJlIHVzZWQgaW4gb3RoZXIgbW9kZXMgaW4gdGhlIGZ1dHVyZS4gSSBhbSBPSyB0byBy ZW1vdmUgaXQuDQo+ID4NCj4gPiA+DQo+ID4gPiAtLS0NCj4gPiA+DQo+ID4gPiBTZWN0aW9uIDMu Mw0KPiA+ID4NCj4gPiA+ICAgIEluIFtSRkM0Mzc5XSwgdGhlIHJhbmdlIG9mIDMxNzQ0LTMyNzY3 IGFuZCA2NDUxMi02NTUzNSBmb3Igc3ViLVRMVnMNCj4gPiA+ICAgIGlzIHNwZWNpZmllZCBmb3Ig VmVuZG9yIFByaXZhdGUgVXNlLCBhbmQgTVVTVCBOT1QgYmUgYWxsb2NhdGVkLiAgVGhpcw0KPiA+ ID4gICAgZG9jdW1lbnQgY2hhbmdlcyB0aGF0IHJ1bGUgdG8gbWFrZSBpdCBub3QgYXBwbGljYWJs ZSB0byBSZXBseSBQYXRoDQo+ID4gPiAgICBUTFYgYW5kIHJlZGVmaW5lcyB0aGUgcnVsZSBhcyBp biBTZWN0aW9uIDYuMiAuICBJZiBhbiBpbXBsZW1lbnRhdGlvbg0KPiA+ID4gICAgcmVjb2duaXpl cyBhbnkgc3BlY2lmaWMgVmVuZG9yIFByaXZhdGUgdHlwZXMgYXMgZGVmaW5lZCBpbiBbUkZDNDM3 OV0sDQo+ID4gPiAgICBhbmQgdXNlcyB0aGUgc3ViLVRMViB0eXBlIHNwZWNpZmllZCBpbiB0aGlz IGRvY3VtZW50LCBjYXJlIG11c3QgYmUNCj4gPiA+ICAgIHRha2VuIHRvIGVuc3VyZSB0aGF0IHRo ZSBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBjb25mdXNlIHRoZSB0d28NCj4gPiA+ICAgIHVzYWdl cy4NCj4gPiA+DQo+ID4gPiBJIGRvbid0IHRoaW5rIHRoaXMgZHJhZnQgY2hhbmdlcyB0aGUgcmVn aXN0cnkgZm9yIDQzNzksIGRvZXMgaXQ/DQo+ID4gPiBUaGlzIG5lZWRzIGEgbGl0dGxlIG1vcmUg Y2FyZSB0byBzZXBhcmF0ZSB0aGUgdHdvIHVzZXMgY2xlYXJseS4gSG93DQo+ID4gPiBhYm91dC4u Lg0KPiA+DQo+ID4gSSB0aGluayBpdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHJlZ2lzdHJ5IGZvciA0 Mzc5LCBidXQgaXQgZG9lcyBjaGFuZ2VzIHJ1bGUNCj4gdGhhdA0KPiA+IFJGQzQzNzkgc3BlY2lm aWVzIHRvIFRMVnMgYW5kIHN1Yi1UTFZzLiBSRkM0Mzc5IHNwZWNpZmllcyB0aGF0IHRoZSByYW5n ZSBvZg0KPiA+IDMxNzQ0LTMyNzY3IGFuZCA2NDUxMi02NTUzNSBmb3Igc3ViLVRMVnMgaXMgc3Bl Y2lmaWVkIGZvciBWZW5kb3IgUHJpdmF0ZQ0KPiBVc2UsDQo+ID4gdGhpcyBkcmFmdCBjaGFuZ2Vz IHRoaXMuDQo+ID4NCj4gPiBCdXQgSSBhZ3JlZSB3aXRoIHlvdXIgc3VnZ2VzdGlvbiBiZWxvdyA6 LSkNCj4gPg0KPiA+ID4NCj4gPiA+IE9MRA0KPiA+ID4gICAgRWFjaCBvZiB0aGUgRkVDIHN1Yi1U TFZzIChpbmNsdWRlIGV4aXN0aW5nIGFuZCBmdXR1cmUgZGVmaW5lZCkgZm9yDQo+ID4gPiAgICB0 aGUgVGFyZ2V0IEZFQyBTdGFjayBUTFZbUkZDNDM3OV0gaXMgYXBwbGljYWJsZSB0byBiZSBhIHN1 Yi1UTFYgZm9yDQo+ID4gPiAgICBpbmNsdXNpb24gaW4gdGhlIFJlcGx5IFBhdGggVExWIGZvciBl eHByZXNzaW5nIGEgc3BlY2lmaWMgcmV0dXJuDQo+ID4gPiAgICBwYXRoLiAgRm9yIHRoZXNlIHNo YXJlZCBzdWItVExWcywgdGhleSBzaGFyZSB0aGUgc2FtZSByZWdpc3RyeSB3aXRoDQo+ID4gPiAg ICB0aGUgVGFyZ2V0IEZFQyBTdGFjayBUTFYgZm9yIHRoZSByYW5nZSBvZiAwLTMxNzQzIGFuZCAz Mjc2OC02NDUxMS4NCj4gPiA+DQo+ID4gPiAgICBJbiBhZGRpdGlvbiwgdGhpcyBkb2N1bWVudCBk ZWZpbmVzIHRocmVlIG5ldyBzdWItVExWczogSVB2NCBSU1ZQDQo+ID4gPiAgICBUdW5uZWwgc3Vi LVRMViwgSVB2NiBSU1ZQIFR1bm5lbCBzdWItVExWIGFuZCBTdGF0aWMgVHVubmVsIHN1Yi1UTFYu DQo+ID4gPiAgICBUaGVzZSBzdWItVExWcyBhcmUgb25seSBkZXNpZ25lZCBmb3IgUmVwbHkgUGF0 aCBUTFYsIGhlbmNlIHRoaXMNCj4gPiA+ICAgIGRvY3VtZW50IGNhbGxzIHRoZW0gZGVkaWNhdGVk IHN1Yi1UTFZzIHRvIFJlcGx5IFBhdGggVExWLiAgRm9yIHRoZXNlDQo+ID4gPiAgICBkZWRpY2F0 ZWQgc3ViLVRMVnMsIHRoaXMgZG9jdW1lbnQgd2lsbCBjcmVhdGUgYSBuZXcgcmVnaXN0cnkgKFNl Y3Rpb24NCj4gPiA+ICAgIDYuMSksIHRoZSBzdWItVExWIHR5cGUgTVVTVCBiZSBhbGxvY2F0ZWQg ZnJvbSB0aGUgbmV3IHJlZ2lzdHJ5Lg0KPiA+ID4gICAgRGV0YWlsZWQgZGVmaW5pdGlvbiBpcyBp biB0aGUgZm9sbG93aW5nIHNlY3Rpb25zLg0KPiA+ID4NCj4gPiA+ICAgIEluIFtSRkM0Mzc5XSwg dGhlIHJhbmdlIG9mIDMxNzQ0LTMyNzY3IGFuZCA2NDUxMi02NTUzNSBmb3Igc3ViLVRMVnMNCj4g PiA+ICAgIGlzIHNwZWNpZmllZCBmb3IgVmVuZG9yIFByaXZhdGUgVXNlLCBhbmQgTVVTVCBOT1Qg YmUgYWxsb2NhdGVkLiAgVGhpcw0KPiA+ID4gICAgZG9jdW1lbnQgY2hhbmdlcyB0aGF0IHJ1bGUg dG8gbWFrZSBpdCBub3QgYXBwbGljYWJsZSB0byBSZXBseSBQYXRoDQo+ID4gPiAgICBUTFYgYW5k IHJlZGVmaW5lcyB0aGUgcnVsZSBhcyBpbiBTZWN0aW9uIDYuMiAuICBJZiBhbiBpbXBsZW1lbnRh dGlvbg0KPiA+ID4gICAgcmVjb2duaXplcyBhbnkgc3BlY2lmaWMgVmVuZG9yIFByaXZhdGUgdHlw ZXMgYXMgZGVmaW5lZCBpbiBbUkZDNDM3OV0sDQo+ID4gPiAgICBhbmQgdXNlcyB0aGUgc3ViLVRM ViB0eXBlIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LCBjYXJlIG11c3QgYmUNCj4gPiA+ICAg IHRha2VuIHRvIGVuc3VyZSB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBjb25mdXNl IHRoZSB0d28NCj4gPiA+ICAgIHVzYWdlcy4NCj4gPiA+IE5FVw0KPiA+ID4gICAgVGhlIEZFQ3Mg ZGVmaW5lZCBpbiBbUkZDNDM3OV0gcHJvdmlkZSBhIGdvb2Qgd2F5IHRvIGlkZW50aWZ5IGENCj4g PiA+ICAgIHNwZWNpZmljIHJldHVybiBwYXRoLiAgVGhlIEZFQyBzdWItVExWcyAoaW5jbHVkaW5n IGV4aXN0aW5nIGFuZA0KPiA+ID4gICAgZnV0dXJlIHN1Yi1UTFZzKSBvZiB0aGUgVGFyZ2V0IEZF QyBTdGFjayBUTFYgW1JGQzQzNzldIGhhdmUgc3ViLVRMVg0KPiA+ID4gICAgdHlwZXMgYXNzaWdu ZWQgZnJvbSBhIHJlZ2lzdHJ5IHdpdGggcmFuZ2VzIGFzIGZvbGxvd3M6DQo+ID4gPg0KPiA+ID4g ICAgICAgMC0xNjM4MyAgICAgICBTdGFuZGFyZHMgQWN0aW9uIG1hbmRhdG9yeSBUTFYNCj4gPiA+ ICAgICAgIDE2Mzg0LTMxNzQzICAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCwgRXhwZXJpbWVudGFs IFJGQyBuZWVkZWQNCj4gPiA+ICAgICAgIDMxNzQ0LTMyNzY3ICAgVmVuZG9yIFByaXZhdGUgVXNl LCBNVVNUIE5PVCBiZSBhbGxvY2F0ZWQNCj4gPiA+ICAgICAgIDMyNzY4LTQ5MTYxICAgU3RhbmRh cmRzIEFjdGlvbiBvcHRpb25hbCBUTFYNCj4gPiA+ICAgICAgIDQ5MTYyLTY0NTExICAgU3BlY2lm aWNhdGlvbiBSZXF1aXJlZCwgRXhwZXJpbWVudGFsIFJGQyBuZWVkZWQNCj4gPiA+ICAgICAgIDY0 NTEyLTY1NTM1ICAgVmVuZG9yIFByaXZhdGUgVXNlLCBNVVNUIE5PVCBiZSBhbGxvY2F0ZWQNCj4g PiA+DQo+ID4gPiAgICBUaGUgUmVwbHkgUGF0aCBUTFYgY2FuIGNhcnJ5IGFuZCBzdWItVExWIGRl ZmluZWQgZm9yIHVzZSBpbiB0aGUNCj4gPg0KPiA+DQo+ID4gU2hvdWxkIHRoZSAiY2FycnkgYW5k IHN1Yi1UTFYiIGJlICJjYXJyeSB0aGUgc3ViLVRMViI/DQo+ID4NCj4gPiA+ICAgIFRhcmdldCBG RUMgU3RhY2sgVExWIHRoYXQgY2FuIGJlIHJlZ2lzdGVyZWQuICBUaHVzIHRoZSByYW5nZXMNCj4g PiA+ICAgIDAtMzE3NDMgYW5kIDMyNzY4LTY0NTExIGFyZSBzaGFyZWQgYnkgdGhlIHJlZ2lzdHJp ZXMsIHdpdGggdGhlIG5ldw0KPiA+ID4gICAgUmVwbHkgUGF0aCBTdWItVExWcyByZWdpc3RyeSAi Ym9ycm93aW5nIiB2YWx1ZXMgZnJvbSB0aGUgVGFyZ2V0IEZFQw0KPiA+ID4gICAgU3RhY2sgVExW IHJlZ2lzdHJ5Lg0KPiA+ID4NCj4gPiA+ICAgIEFsbG9jYXRpb25zIGZyb20gdGhlIHJhbmdlcyAz MTc0NC0zMjc2NyBhbmQgNjQ1MTItNjU1MzUgYXJlIG5vdA0KPiA+ID4gICAgcmVjb3JkZWQgaW4g dGhlIHJlZ2lzdHJ5IGZvciBUYXJnZXQgRkVDIFN0YWNrIFRMVnMsIHNvIHRoZXNlIHJhbmdlcw0K PiA+ID4gICAgYXJlIHNhZmVseSBtYWRlIGF2YWlsYWJsZSBpbiB0aGUgUmVwbHkgUGF0aCBTdWIt VExWcyByZWdpc3RyeSAoc2VlDQo+ID4gPiAgICBTZWN0aW9uIDYuMSkgdG8gcmVjb3JkIHN1Yi1U TFZzIHRoYXQgYXJlIHNwZWNpZmljIHRvIHRoZSBSZXBseSBQYXRoDQo+ID4gPiAgICBUTFYuICBU aGlzIGRvY3VtZW50IGRlZmluZXMgdGhyZWUgc3ViLVRMVnMgc3BlY2lmaWMgdG8gdGhlIFJlcGx5 IFBhdGgNCj4gPiA+ICAgIFRMVjogSVB2NCBSU1ZQIFR1bm5lbCBzdWItVExWLCBJUHY2IFJTVlAg VHVubmVsIHN1Yi1UTFYsIGFuZCBTdGF0aWMNCj4gPiA+ICAgIFR1bm5lbCBzdWItVExWLg0KPiA+ ID4NCj4gPiA+ICAgIE5vdGUgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRzIHNw ZWNpZmljIFZlbmRvciBQcml2YXRlDQo+ID4gPiAgICBmb3Igc3ViLVRMVnMgb2YgdGhlIFRhcmdl dCBGRUMgU3RhY2sgbXVzdCB0YWtlIGNhcmUgdG8gbm90IGNvbmZ1c2UNCj4gPiA+ICAgIHRob3Nl IHZhbHVlcyB3aXRoIHRoZSBzYW1lIHZhbHVlcyBhbGxvY2F0ZWQgZnJvbSB0aGUgUmVwbHkgUGF0 aCBTdWItDQo+ID4gPiAgICBUTFZzIHJlZ2lzdHJ5Lg0KPiA+ID4gRU5EDQo+ID4gPg0KPiA+ID4g LS0tDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiAzLjMNCj4gPiA+DQo+ID4gPiAgICAyLiAgU3BlY2lm eSBhIG1vcmUgZ2VuZXJpYyB0dW5uZWwgRkVDIGFzIHJldHVybiBwYXRoDQo+ID4gPg0KPiA+ID4g SXQgaXMgY2xlYXIgdGhhdCAzLjMuMSBhbmQgMy4zLjIgZGVmaW5lIGEgRkVDIHRoYXQgaXMgbW9y ZSBnZW5lcmFsIHRoYW4NCj4gPiA+IHRoZSBGRUNzIGluIDQzNzkuIFdoYXQgaXMgbm90IGNsZWFy IGlzIHRoZSB1c2UgY2FzZS4gSSB0aGluayB5b3UgbmVlZA0KPiA+ID4gc29tZSB0ZXh0IGluIHRo aXMgZG9jdW1lbnQgdG8gc2F5IHdoYXQgeW91IHNob3VsZCBkbyB3aXRoIG9uZSBvZiB0aGVzZQ0K PiA+ID4gRkVDcyBzaW5jZSBpdCBwb3NzaWJseSBpZGVudGlmaWVzIGEgc2V0IG9mIExTUHMuDQo+ ID4NCj4gPiBUaGVyZSBpcyBhbm90aGVyIGRyYWZ0IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1jaGVuLW1wbHMtYmZkLQ0KPiA+IGVuaGFuY2VtZW50LTAwI3NlY3Rpb24tNC4yICkg ZGlzY3Vzc2VzIHRoZSB1c2FnZSBvZiB0aGUgZ2VuZXJpYyBUdW5uZWwgc3ViLQ0KPiA+IFRMVi4g SG93IGFib3V0IGFkZCB0aGUgZm9sbG93aW5nIHRleHQ6DQo+ID4NCj4gPiBPbmUgdXNhZ2Ugb2Yg dGhpcyBnZW5lcmljIFJTVlAgVHVubmVsIHN1Yi1UTFYgaXMgZm9yIGJvb3RzdHJhcHBpbmcgQkZE DQo+IHNlc3Npb24NCj4gPiBvbiBhbiBNUExTIFR1bm5lbCB0aGF0IGhhcyBwcmltYXJ5IGFuZCBz ZWNvbmRhcnkgTFNQcywgZXNwZWNpYWxseSB3aGVuDQo+IE1ha2UtDQo+ID4gQmVmb3JlLUJyZWFr IChNQkIpIGlzIGRlcGxveWVkLiBUaGUgdXNhZ2UgaXMgZGlzY3Vzc2VkIGluIHRoZSBTZWN0aW9u IDQuMiBvZg0KPiBbSS0NCj4gPiBELmNoZW4tbXBscy1iZmQtZW5oYW5jZW1lbnRdLg0KPiA+DQo+ ID4gPg0KPiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiAzLjMuMQ0KPiA+ID4NCj4gPiA+ IE9MRA0KPiA+ID4gICAgVGhlIElQdjQgUlNWUCBUdW5uZWwgc3ViLVRMViBUeXBlIGZpZWxkIGlz IDIgb2N0ZXRzIGluIGxlbmd0aCwgYW5kDQo+ID4gPiAgICB0aGUgcmVjb21tZW5kZWQgdHlwZSB2 YWx1ZSBpcyBUQkQuDQo+ID4gPiBORVcNCj4gPiA+ICAgIFRoZSBJUHY0IFJTVlAgVHVubmVsIHN1 Yi1UTFYgVHlwZSBmaWVsZCBpcyAyIG9jdGV0cyBpbiBsZW5ndGgsIGFuZA0KPiA+ID4gICAgdGhl IHJlY29tbWVuZGVkIHR5cGUgdmFsdWUgaXMgVEJEMS4NCj4gPiA+IEVORA0KPiA+DQo+ID4gT0su DQo+ID4NCj4gPiA+DQo+ID4gPiAtLS0NCj4gPiA+DQo+ID4gPiBTZWN0aW9uIDMuMy4xDQo+ID4g Pg0KPiA+ID4gSXQgaXMgc2xpZ2h0bHkgd2VpcmQgdGhhdCB0aGUgYml0IGZpZWxkIGluIHRoaXMg c2VjdGlvbiBhbGxvY2F0ZXMgdGhlDQo+ID4gPiBmaXJzdCB0d28gYml0cyB3aGlsZSB0aGUgZmll bGQgaW4gc2VjdGlvbiAzLjIgYWxsb2NhdGVzIHRoZSBsYXN0IHR3bw0KPiA+ID4gYml0cy4gIFRo aXMgaXMgbm90IHNpZ25pZmljYW50bHkgaW1wb3J0YW50LCBidXQgaXMgb2RkLg0KPiA+DQo+ID4g V2lsbCBjaGFuZ2UgaXQgYW5kIG1ha2UgdGhlbSBjb25zaXN0ZW50Lg0KPiA+ID4NCj4gPiA+IC0t LQ0KPiA+ID4NCj4gPiA+IFNlY3Rpb24gMy4zLjINCj4gPiA+DQo+ID4gPiBPTEQNCj4gPiA+ICAg IFRoZSBJUHY2IFJTVlAgVHVubmVsIHN1Yi1UTFYgVHlwZSBmaWVsZCBpcyAyIG9jdGV0cyBpbiBs ZW5ndGgsIGFuZA0KPiA+ID4gICAgdGhlIHR5cGUgdmFsdWUgaXMgVEJELg0KPiA+ID4gTkVXDQo+ ID4gPiAgICBUaGUgSVB2NiBSU1ZQIFR1bm5lbCBzdWItVExWIFR5cGUgZmllbGQgaXMgMiBvY3Rl dHMgaW4gbGVuZ3RoLCBhbmQNCj4gPiA+ICAgIHRoZSB0eXBlIHZhbHVlIGlzIFRCRDIuDQo+ID4g PiBFTkQNCj4gPg0KPiA+IE9LLg0KPiA+DQo+ID4gPg0KPiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4g U2VjdGlvbiAzLjMuMw0KPiA+ID4NCj4gPiA+IFJGQyA2MzcwIHNlZW1zIHRvIGFsc28gaW5jbHVk ZSBhbiAiTFNQX051bSIuIFNvIHlvdXIgMy4zLjMgY2FzZSBpcyB0aGUNCj4gPiA+IE1QTFMtVFAg c3RhdGljIGVxdWl2YWxlbnQgb2YgMy4zLjEuIEJ1dCB5b3UgYXJlIG1pc3Npbmc6DQo+ID4gPg0K PiA+ID4gLSB0aGUgTVBMUy1UUCBzdGF0aWMgZXF1aXZhbGVudCBvZiAzLjMuMiAoaS5lLiB2NiBp ZGVudGlmaWVycykNCj4gPiA+IC0gdGhlIE1QTFMtVFAgZXF1aXZhbGVudCBvZiB0aGUgNDM3OSBS U1ZQIExTUCBGRUNzDQo+ID4gPg0KPiA+ID4gRG8geW91IG5lZWQgdGhlbT8NCj4gPg0KPiA+IE5v LCB3ZSBkbyBub3QgbmVlZCB0aGVtLCBNUExTLVRQIGhhcyBub3QgdjYgaWRlbnRpZmllcnMsIGFu ZCB0aGUgTVBMUy1UUA0KPiA+IGVxdWl2YWxlbnQgb2YgdGhlIDQzNzkgUlNWUCBMU1AgRkVDcyBi ZWxvbmdzIHRvIHRoZSBleGlzdGluZyBzdWItVExWcyBvZg0KPiBUYXJnZXQNCj4gPiBGRUMgVExW IGFuZCBhcmUgYWxyZWFkeSBkZWZpbmVkIGluIFRQIHJlbGF0ZWQgUkZDLg0KPiA+DQo+ID4gPg0K PiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiAzLjMuMw0KPiA+ID4NCj4gPiA+IE9MRA0K PiA+ID4gICAgVGhlIHN1Yi1UTFYgdHlwZSB2YWx1ZSBpcyBUQkQuDQo+ID4gPiBORVcNCj4gPiA+ ICAgIFRoZSBzdWItVExWIHR5cGUgdmFsdWUgaXMgVEJEMy4NCj4gPiA+IEVORA0KPiA+ID4NCj4g PiBPSy4NCj4gPg0KPiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiAzLjQNCj4gPiA+DQo+ ID4gPiBPTEQNCj4gPiA+ICAgIFRoZSBSZXBseSBUQyBUTFYgVHlwZSBmaWVsZCBpcyAyIG9jdGV0 cyBpbiBsZW5ndGgsIGFuZCB0aGUgdHlwZSB2YWx1ZQ0KPiA+ID4gICAgaXMgVEJELg0KPiA+ID4g TkVXDQo+ID4gPiAgICBUaGUgUmVwbHkgVEMgVExWIFR5cGUgZmllbGQgaXMgMiBvY3RldHMgaW4g bGVuZ3RoLCBhbmQgdGhlIHR5cGUgdmFsdWUNCj4gPiA+ICAgIGlzIFRCRDQuDQo+ID4gPiBFTkQN Cj4gPiA+DQo+ID4NCj4gPiBPSy4NCj4gPg0KPiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4gU2VjdGlv biA0DQo+ID4gPg0KPiA+ID4gICAgVGhlIHByb2NlZHVyZXMgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50IGN1cnJlbnRseSBvbmx5IGFwcGx5IHRvDQo+ID4gPiAgICAicGluZyIgbW9kZS4gIFRoZSAi dHJhY2Vyb3V0ZSIgbW9kZSBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMNCj4gPiA+ICAgIGRvY3Vt ZW50Lg0KPiA+ID4NCj4gPiA+IEkgdGhpbmsgdGhpcyBzaG91bGQgc2hvdyB1cCBpbiB0aGUgSW50 cm9kdWN0aW9uIGFuZCBwb3NzaWJseSB0aGUNCj4gPiA+IEFic3RyYWN0Lg0KPiA+DQo+ID4gT0su DQo+ID4NCj4gPiA+DQo+ID4gPiAtLS0NCj4gPiA+DQo+ID4gPiBTZWN0aW9uIDYNCj4gPiA+DQo+ ID4gPiBQbGVhc2UgY29uc2lkZXIgd2hldGhlciB5b3Ugd2FudCByZWdpc3RyaWVzIGZvciB0aGUg Yml0IGZpZWxkcyB5b3UNCj4gPiA+IGRlZmluZSBpbiB0aGlzIGRvY3VtZW50Lg0KPiA+ID4NCj4g PiA+IC0tLQ0KPiA+ID4NCj4gPiA+IFNlY3Rpb24gNi4xDQo+ID4gPg0KPiA+ID4gT0xEDQo+ID4g PiAgICBUQkQgICAgIFJlcGx5IFRDIFRMViAgICAgICAgICAgICAgICAgICAgICB0aGlzIGRvY3Vt ZW50IChzZWN0DQo+IDMuNCkNCj4gPiA+IE5FVw0KPiA+ID4gICAgVEJENCAgICBSZXBseSBUQyBU TFYgICAgICAgICAgICAgICAgICAgICAgdGhpcyBkb2N1bWVudCAoc2VjdA0KPiAzLjQpDQo+ID4g PiBFTkQNCj4gPiA+DQo+ID4gT0sNCj4gPg0KPiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4gU2VjdGlv biA2LjQNCj4gPiA+DQo+ID4gPiBPTEQNCj4gPiA+ICAgIFRCRCAgICAgUmVwbHkgVEMgVExWICAg ICAgICAgICAgICAgICAgICAgIHRoaXMgZG9jdW1lbnQgKHNlY3QNCj4gMy40KQ0KPiA+ID4gTkVX DQo+ID4gPiAgICBUQkQ0ICAgIFJlcGx5IFRDIFRMViAgICAgICAgICAgICAgICAgICAgICB0aGlz IGRvY3VtZW50IChzZWN0DQo+IDMuNCkNCj4gPiA+IEVORA0KPiA+ID4NCj4gPiBPSy4NCj4gPg0K PiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4gU2VjdGlvbiA2LjIuMQ0KPiA+ID4NCj4gPiA+IE9MRA0K PiA+ID4gICAgU3ViLXR5cGUgICAgICBWYWx1ZSBGaWVsZCAgICAgICAgICAgICBSZWZlcmVuY2UN Cj4gPiA+ICAgIC0tLS0tLS0gICAgICAgLS0tLS0tLS0tLS0gICAgICAgICAgICAgLS0tLS0tLS0t DQo+ID4gPiAgICBUQkQgICAgICAgICAgIElQdjQgUlNWUCBUdW5uZWwgICAgICAgIHRoaXMgZG9j dW1lbnQgKHNlY3QgMy4zLjEpDQo+ID4gPiAgICBUQkQgICAgICAgICAgIElQdjYgUlNWUCBUdW5u ZWwgICAgICAgIHRoaXMgZG9jdW1lbnQgKHNlY3QgMy4zLjIpDQo+ID4gPiAgICBUQkQgICAgICAg ICAgIFN0YXRpYyBUdW5uZWwgICAgICAgICAgIHRoaXMgZG9jdW1lbnQgKHNlY3QgMy4zLjMpDQo+ ID4gPiBORVcNCj4gPiA+ICAgIFN1Yi10eXBlICAgICAgVmFsdWUgRmllbGQgICAgICAgICAgICAg UmVmZXJlbmNlDQo+ID4gPiAgICAtLS0tLS0tICAgICAgIC0tLS0tLS0tLS0tICAgICAgICAgICAg IC0tLS0tLS0tLQ0KPiA+ID4gICAgVEJEMSAgICAgICAgICBJUHY0IFJTVlAgVHVubmVsICAgICAg ICB0aGlzIGRvY3VtZW50IChzZWN0IDMuMy4xKQ0KPiA+ID4gICAgVEJEMiAgICAgICAgICBJUHY2 IFJTVlAgVHVubmVsICAgICAgICB0aGlzIGRvY3VtZW50IChzZWN0IDMuMy4yKQ0KPiA+ID4gICAg VEJEMyAgICAgICAgICBTdGF0aWMgVHVubmVsICAgICAgICAgICB0aGlzIGRvY3VtZW50IChzZWN0 IDMuMy4zKQ0KPiA+ID4gRU5EDQo+ID4gPg0KPiA+ID4gLS0tDQo+ID4gPg0KPiA+ID4gU2VjdGlv biA2LjMNCj4gPiA+DQo+ID4gPiBPTEQNCj4gPiA+ICAgIElBTkEgaXMgbm93IHJlcXVlc3RlZCB0 byBhc3NpZ24gdGhlIHByZXZpb3VzbHkgYXNzaWduZWQgYSBuZXcgcmVwbHkNCj4gPiA+ICAgIG1v ZGUgY29kZSBwb2ludCAoNSAtIFJlcGx5IHZpYSBzcGVjaWZpZWQgcGF0aCkgZnJvbSB0aGUgIk11 bHRpLQ0KPiA+ID4gICAgUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKSBMYWJlbCBTd2l0 Y2hlZCBQYXRocyAoTFNQcykgUGluZw0KPiA+ID4gICAgUGFyYW1ldGVycyIgcmVnaXN0cnksIHRo ZSAiUmVwbHkgTW9kZSIgc3ViLXJlZ2lzdHJ5IG9uIGEgcGVybWFuZW50DQo+ID4gPiAgICBiYXNp cy4NCj4gPiA+IE5FVw0KPiA+ID4gICAgSUFOQSBoYXMgbWFkZSBhbiBlYXJseSBhbGxvY2F0aW9u ICg1IC0gUmVwbHkgdmlhIHNwZWNpZmllZCBwYXRoKSBmcm9tDQo+ID4gPiAgICB0aGUgIk11bHRp LVByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykgTGFiZWwgU3dpdGNoZWQgUGF0aHMNCj4g PiA+ICAgIChMU1BzKSBQaW5nIFBhcmFtZXRlcnMiIHJlZ2lzdHJ5LCB0aGUgIlJlcGx5IE1vZGUi IHN1Yi1yZWdpc3RyeS4gSUFOQQ0KPiA+ID4gICAgaXMgcmVxdWVzdGVkIHRvIG1ha2UgdGhpcyBh bGxvY2F0aW9uIHBlcm1hbmVudC4NCj4gPiA+IEVORA0KPiA+DQo+ID4gT0suDQo+ID4NCj4gPiA+ DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo= From ietfc@btconnect.com Fri Oct 19 04:01:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C06021F8532 for ; Fri, 19 Oct 2012 04:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.465 X-Spam-Level: X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[AWL=-1.855, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_15=0.6, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phq6QI+uFVcQ for ; Fri, 19 Oct 2012 04:01:18 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 302D721F866C for ; Fri, 19 Oct 2012 04:01:18 -0700 (PDT) Received: from mail44-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.23; Fri, 19 Oct 2012 11:01:17 +0000 Received: from mail44-ch1 (localhost [127.0.0.1]) by mail44-ch1-R.bigfish.com (Postfix) with ESMTP id 3691440082; Fri, 19 Oct 2012 11:01:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371Ic89bh542M1432I1418Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h941hd24hf0ah107ah1177h1179h1269h1288h12a5h12a9h12bdh12e1h137ah139eh13b6h1441h304l1155h) Received: from mail44-ch1 (localhost.localdomain [127.0.0.1]) by mail44-ch1 (MessageSwitch) id 1350644474885680_14689; Fri, 19 Oct 2012 11:01:14 +0000 (UTC) Received: from CH1EHSMHS026.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail44-ch1.bigfish.com (Postfix) with ESMTP id C9AED4000E9; Fri, 19 Oct 2012 11:01:14 +0000 (UTC) Received: from DB3PRD0710HT004.eurprd07.prod.outlook.com (157.56.253.85) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 19 Oct 2012 11:01:14 +0000 Received: from BL2PRD0410HT005.namprd04.prod.outlook.com (157.56.240.85) by pod51017.outlook.com (10.255.75.39) with Microsoft SMTP Server (TLS) id 14.16.224.5; Fri, 19 Oct 2012 11:01:13 +0000 Message-ID: <018f01cdade9$04ef76c0$4001a8c0@gateway.2wire.net> From: t.petch To: Mach Chen , , References: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> <000401cdad4e$c7b080a0$4001a8c0@gateway.2wire.net> Date: Fri, 19 Oct 2012 12:00:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.240.85] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] 4p84: AD review of draft-ietf-mpls-return-path-specified-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:01:19 -0000 ----- Original Message ----- From: "Mach Chen" To: "t.petch" ; ; Cc: ; Sent: Friday, October 19, 2012 2:30 AM > Hi Tom, > > Thanks for your comments! You are too kind! > Please see my reply inline... > > Best regards, > Mach > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: t.petch [mailto:ietfc@btconnect.com] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA10=D4=C218=C8=D5 23:06 > > =CA=D5=BC=FE=C8=CB: Mach Chen; adrian@olddog.co.uk; > > draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org > > =B3=AD=CB=CD: mpls@ietf.org; mpls-chairs@tools.ietf.org > > > Last November, I commented > > > > "In retrospect, RFC4379 should have split the sub-TLV range into common > > to all > > TLV, and TLV-unique, which, in effect, is what my idea on 1024 is, post > > factum. > > I would expect others to comment on this as and when they realise what > > it says, > > so I would leave it for a while and see what comes up." > > > > and I think that this has now come up. > > > > Adrian says below > > "> I think it does not change the registry for 4379, but it does changes > > rule that RFC4379 specifies to TLVs and sub-TLVs." > > > > and proposes that what in RFC4379 is > > "The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the > > range 0-16383 and 32768-49161 are made via Standards Action as > > defined in [IANA]; assignments in the range 16384-31743 and > > 49162-64511 are made via "Specification Required" as defined above; > > values in the range 31744-32767 and 64512-65535 are for Vendor > > Private Use, and MUST NOT be allocated." > > > > becomes > > "> > 0-16383 Standards Action mandatory TLV > > > > 16384-31743 Specification Required, Experimental RFC needed > > > > 31744-32767 Vendor Private Use, MUST NOT be allocated > > > > 32768-49161 Standards Action optional TLV > > > > 49162-64511 Specification Required, Experimental RFC needed > > > > 64512-65535 Vendor Private Use, MUST NOT be allocated" > > This above is actually proposed in RFC4379, Yes, my mistake; I had forgotten that RFC4379 redefined Specification Required from the usual RFC5226 usage > this draft proposes to changes the rule for Reply Path TLV as follows: > 0-31743 - Reserved, and MUST NOT be allocated. > 31744-32767 - Allocated via Standards Action. > 32768-64511 - Reserved, and MUST NOT be allocated. > 64512-65531 - Allocated via Standards Action. > 65531-65535 - Experimental Use, and MUST NOT be allocated. > > So the "common" range are 0-31743 and 32768-64511, and the dedicated ranges are 31744-32767 and 64512-65531 (they are originally defined as "Vendor Private Use", and now redefined as dedicated code ranges for a LSP Ping TLV ). And according to the guidance of RFC5226, there are only 4 code points (65531-65535) left for the Vendor Private Use(It's now called "Experimental Use" according some expert's suggestion). > > So IMHO, the current rule is actually very close to your suggestion, the only difference is that the common range is not 1024. I think I understand. But I do think that you are creating a new registry MPLS-LSP-Ping Parameters - sub-TLVs for Reply Path TLV (Type 21) (yuk - too cumbersome a name) The allocation rules are different for sub-TLVs for other TLVs and I do not see how IANA can fit that in without making it a distinct (sub-)registry. (I am not clear from the shepherd write-up whether or not this has been run past IANA yet; if it has been then no problem - else, obviously they will see it at IETF Last Call but it would be better to fix it before then). Arguably, this is an update to RFC4379 since that RFC did not countenance there being different rules for the sub-TLVs of different TLVs and as RFC4379 stands, would not allow what is now proposed, IMO. Since you are using, I assume, the terms as defined in RFC5226, as opposed to the variants defined in RFC4379, then I do think that you need a reference to RFC5226. And when you replied to Adrian > The Reply Path TLV can carry and sub-TLV defined for use in the and said Should the "carry and sub-TLV" be "carry the sub-TLV"? I would think it should be carry any sub-TLV, which is somewhat different. Tom Petch > > which > > a) seems to me to be not quite the same ie updates RFC4379 > > b) does not seem to solve the problem > > > > (and there is no reference for RFC5226, but then that is usual for an > > MPLS-TP RFC:-( > > We actually consider the guidelines in RFC5226, especially for the design of the "Experimental Use" range. Do you suggest to add an explicit reference to RFC5226? I am fine to do that. How about add the following text at the beginning of Section 6.2: > > "According to the guidelines defined in [RFC5226], the sub-TLV range of Reply Path TLV are partitioned as following:" > > Hope this resolved your comments! > > Best regards, > Mach > > > > > > Tom Petch > > > > Sniped > From robert.h.venator.civ@mail.mil Fri Oct 19 07:22:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A4521F85A4 for ; Fri, 19 Oct 2012 07:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OySzRWVdTZwY for ; Fri, 19 Oct 2012 07:22:17 -0700 (PDT) Received: from edge-mech.mail.mil (edge-mech.mail.mil [214.21.82.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3C21521F86E3 for ; Fri, 19 Oct 2012 07:22:10 -0700 (PDT) Received: from umechpji.easf.csd.disa.mil (214.21.83.159) by umechpid.easf.csd.disa.mil (214.21.82.9) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 19 Oct 2012 14:24:04 +0000 Received: from UMECHPHF.easf.csd.disa.mil ([169.254.9.23]) by UMECHPJI.easf.csd.disa.mil ([214.21.83.159]) with mapi id 14.02.0309.003; Fri, 19 Oct 2012 14:24:03 +0000 From: "Venator, Robert H III CIV (US)" To: Loa Andersson , "mpls@ietf.org" , "Martin Vigoureux" , "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" Thread-Topic: poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document Thread-Index: AQHNrQI6dryzY5RbK02j0eY6Y0f70pfAr53A Date: Fri, 19 Oct 2012 14:24:02 +0000 Message-ID: References: <507FAF2D.5020907@pi.nu> In-Reply-To: <507FAF2D.5020907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [214.21.83.188] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F2_01CDADE3.52C954C0" MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:22:18 -0000 ------=_NextPart_000_00F2_01CDADE3.52C954C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Support. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Thursday, October 18, 2012 3:27 AM To: mpls@ietf.org; Martin Vigoureux; draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document Working group, this is to start a two week poll on adopting draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-09 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). Please give an technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends November 07, 2012. There is one IPR claim against this document - http://datatracker.ietf.org/ipr/1861/ . All the co-authors has stated on the mailing list that they are not aware of any other IPR claims than those already disclosed. If there are IPR claims from any other party, please remember that the IPR is open. /Loa (mpls wg co-chair) -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ------=_NextPart_000_00F2_01CDADE3.52C954C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISjTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEuDCCA6CgAwIBAgIDFnwZMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzAwHhcNMTIwNzIzMDAwMDAwWhcN MTUwNzIyMjM1OTU5WjB8MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTENMAsGA1UECxMERElTQTEoMCYGA1UEAxMfVkVOQVRP Ui5ST0JFUlQuSC5JSUkuMTAyNDg2NTM5NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKyXqrymWWUwcEy0l1PcYZ3S5mXDwEFVz5ZicVKffLVnkGF/i+yp+OqqXlSK9f427YRac+ePWOn0 i+3vBtzGz7Z6ml9iSMIfld4/zF2pE/XYxRmS+YygJtibC7OT2tj55meYBH8qQOVGdrdUiYtam8tw mnPpmjv++6s3pa84RnQss0211ece6bcnil+m3WzeG75cWB/P1GUJCAJLpWvtBB0/F3nOPfEuLKER UhwDrrVXhTgmAY9OrpTHWKL04FrRe/OVM6WK495uxNpQJa3LtuYlQ4w2NLI6adfu53Gm20oN6afT zhaEkNn+bTcwsD2rU1gOORhnJBvCC7h81DN+XpECAwEAAaOCAWAwggFcMB8GA1UdIwQYMBaAFDVh ZigJvFYlW4vMv4FeYSwwOdMhMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwv Y3JsL0RPREVNQUlMQ0FfMzAuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFl AgELCTALBglghkgBZQIBCxMwHQYDVR0OBBYEFACpUwcDIOVumon8Wy9XYFg698ftMGgGCCsGAQUF BwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0Ff MzAuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAiBgNVHREEGzAZgRdyb2Jl cnQudmVuYXRvckBkaXNhLm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMA0GCSqGSIb3 DQEBBQUAA4IBAQAM2epFktEq3UYmbzsAD/qKK4v1QtY0bXfCIYE0cFv5YuOFbF0RBnN0BPRp34Es rksDYYWpZuE2UmNb7aS6SnkB07VU2qpMs1/1zijN1fpXWoTmXvFvPth073MUoP7Sdm+bgMaHGCBj DCAsamVV7f/CsOJUv57Osx7Yxgs/S95giqUG9bKpKt+PWgAQ72hdTGMTSOBNIPZ+5cNH9jx1f8E6 92wdfnIUkDJosfdWCPlyJhbSmWea1W+NcSLvVhiPvL18oYYWZzOgVXUfJQNJyNyaGwjFp1aidDMS SFBk8B0Ka8aJhBAMto5zMAoMFIw8azkl94xbOqK5C3USbyTp2fcoMIIFAzCCA+ugAwIBAgIDFnwT MA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQx DDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzAwHhcN MTIwNzIzMDAwMDAwWhcNMTUwNzIyMjM1OTU5WjB8MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5T LiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTENMAsGA1UECxMERElTQTEo MCYGA1UEAxMfVkVOQVRPUi5ST0JFUlQuSC5JSUkuMTAyNDg2NTM5NDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMzZdVGUWCd1rGsFgQ4X38dR1Qis6jkjFBlrkdogFEWPDa/gb5bTypv7 q9WLzFvDid97GBX9iegS/RhVPNMopGbKjLRGn/dY0nyJ36nM+7rQoX4KnNrd0uWmseinPiDoG97j Gs1Olvue6nMjjnmO14s9BxPYONGwxoypne+Gpckgh3GVD52EyJt9Jhu79r88LmJzB1Bzj8kTq7PF mF11RDhhLC1VO5sRE60QlytiEp6DtlQ2Jy1XXSudhPs5bm2Hb4nsbXPAQAYQ9cgwFeU4KElIUyui gIN8kWuehpq4b2va6G2f6WXC5TiVwlew9Ihlyp+JgDcPSTljEjwpoUfyDmsCAwEAAaOCAaswggGn MB8GA1UdIwQYMBaAFDVhZigJvFYlW4vMv4FeYSwwOdMhMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6 Ly9jcmwuZGlzYS5taWwvY3JsL0RPREVNQUlMQ0FfMzAuY3JsMA4GA1UdDwEB/wQEAwIGwDAjBgNV HSAEHDAaMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxMwHQYDVR0OBBYEFNW7AmZscjEkeh4inp2A w9iBJP5XMGgGCCsGAQUFBwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9z aWduL0RPREVNQUlMQ0FfMzAuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDBC BgNVHREEOzA5gRdyb2JlcnQudmVuYXRvckBkaXNhLm1pbKAeBgorBgEEAYI3FAIDoBAMDjEwMjQ4 NjUzOTRAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwKQYDVR0lBCIwIAYKKwYBBAGC NxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQBf9LesMnEO72H7p9wH ms+vjj2bREMjw6UVEf1L4BXLpors/fZfN+Ypc6cPPo3G5wpgusJQc3dLuLj4mJajmvF23BgvVJVc nc41A2skKszp6ip8L0sYmMkxFVXB1JCsGo/0Ln7AG6uvZFKP9GZPxGsPgAjAhGyn+V186+7G7XI2 +s9Dzwd5On8rIqbyW8W83U2hz8AX5BVBDgoqorl9A4rESy0s66i8DPrOVA1sIjUtsFK+DYY3kgbm tuMOjiiSu3vOqNkhM+g66qZVNhc9TSoJYVIs84hRETtfZAhnd26O9p7Y4O7OJ2/s9q8aHweN8Fbj PxjZBt91cwjeHlriplFeMIIFUjCCBDqgAwIBAgICAbkwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDURvRCBSb290IENBIDIwHhcNMTEwOTA4MTYwMzA4WhcNMTcwOTA4MTYwMzA4 WjBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0Qx DDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMwMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA5iki1BQm0ZgaUl7FhINzfsFgs7PQlL79HJRVv/aELJvJwHRz78zCmfKZ yW3KFNN0/74Q8vctv8u7BqPumFBBZQHhVyy2y+TKHKx+UjQOsY4HJj4yNa+jYQrF5Qi2EnmMVMF6 6fFQH12DOmcwsynbHTpMOSFQ2BgsjQZ17mNyeGitYpx1pJQG0zJrEq8GBym+E6DAp/AlT7f+H7dX 4BgSjSFqFblaVPt3ZdhMP/W6PMA34QZ+wr6eI4wo0ZrXxmc413PJvQcdhW/VlQqa3No6TijwpesJ 3+XbC81Hr4rNu2+UQONZnFCfyQ6pcQK53OlpgDqJO0UFIhgFhLUS8DzAgQIDAQABo4ICHDCCAhgw DgYDVR0PAQH/BAQDAgGGMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DGlcYJgHCWMB0GA1UdDgQW BBQ1YWYoCbxWJVuLzL+BXmEsMDnTITASBgNVHRMBAf8ECDAGAQH/AgEAMAwGA1UdJAQFMAOAAQAw ZgYDVR0gBF8wXTALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELETALBglghkgB ZQIBCxIwCwYJYIZIAWUCAQsTMAwGCmCGSAFlAwIBAxowDAYKYIZIAWUDAgEDGzA3BgNVHR8EMDAu MCygKqAohiZodHRwOi8vY3JsLmRpc2EubWlsL2NybC9ET0RST09UQ0EyLmNybDCCAQEGCCsGAQUF BwEBBIH0MIHxMDoGCCsGAQUFBzAChi5odHRwOi8vY3JsLmRpc2EubWlsL2lzc3VlZHRvL0RPRFJP T1RDQTJfSVQucDdjMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDCBkAYIKwYBBQUH MAKGgYNsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNv dSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2Nyb3Nz Q2VydGlmaWNhdGVQYWlyO2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEACohWHKVXJlpiy3XQ3YbF UuIv87wRZD+MLz4R/JhgQPKADSiCmmj+4EhLJ9M6CnuV9gMMgRSRQjpgbOIrUy3s3xGu9VQX8AH5 lwenm6sL26yXiQnG7/kHNBYAqH4RU558L6E4opl5OTRBbn24WDBWiJ7kqmRF2aBEYjq35THTkYDx GxCyZ3DVW6tZtFpIFkLEAkzabGjKUB0xvjeZx89TzEIpVsOdF8oD5xBa8Tk8HMz7G5cKJvMx3+Cr XCSdnt44fQJRZ0b5k3CF7QpVwvTBaFqfCMkde5t23FTvOYwY5QxE7vcGsh/1y+YOvdSh/9T5kQci Unm3wP3ssviF9ET7XDGCA0EwggM9AgEBMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0zMAIDFnwTMAkGBSsOAwIaBQCgggGyMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAxOTE0MjAxMlowIwYJKoZIhvcNAQkEMRYEFOdkyqXnZ2amM6nPBnbf zytemUFdMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHMG CSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0zMAIDFnwZ MHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5t ZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMw AgMWfBkwDQYJKoZIhvcNAQEBBQAEggEAMcivSdxzrnPNwMr3rMLdluTE22ug9O4CcBmNMauk4Mx7 irv7Y1j9kRcNkQjEwkO1ydLRGEsR0J958XpjPv+zAmp1XGJ3JmdrBkrxWCEwoj+PF2idTYG2mccY 7PpNLMBQoQQQGATi66fprhw8qqwukR4wAF5NzmJF+6kpFBOWKP0pFDqRl2M2/c6mcMM620L2FK9v j80hwv2Pp6EcT32ZwwZEjEHAYzRPjyncWTMpvr5to34U9Fp8Ps0n86g84+jqsIYDG6dA0t/pP2ly bDn3a/p/U3l3+PzDXx4fSovD7Yy0Qq9D7xUnr3KwnFvQn7KkuaGCq55b7V3oXjx2b8gXdQAAAAAA AA== ------=_NextPart_000_00F2_01CDADE3.52C954C0-- From loa@pi.nu Fri Oct 19 10:20:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3618121F8759 for ; Fri, 19 Oct 2012 10:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.967 X-Spam-Level: X-Spam-Status: No, score=-101.967 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3sevh3tre03 for ; Fri, 19 Oct 2012 10:20:28 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 607D621F878B for ; Fri, 19 Oct 2012 10:20:21 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 16F3382475; Fri, 19 Oct 2012 19:20:17 +0200 (CEST) Message-ID: <50818BD2.9000001@pi.nu> Date: Fri, 19 Oct 2012 19:20:18 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "t.petch" References: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> <000401cdad4e$c7b080a0$4001a8c0@gateway.2wire.net> <018f01cdade9$04ef76c0$4001a8c0@gateway.2wire.net> In-Reply-To: <018f01cdade9$04ef76c0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] 4p84: AD review of draft-ietf-mpls-return-path-specified-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:20:34 -0000 Tom, Speaking as the document shepherd for draft-ietf-mpls-return- path-specified-lsp-ping: The authors of draft-ietf-mpls-return-path-specified-lsp-ping have requested assignments of TLV's and sub-TLV's based on how the "TLV and sub-TLV" sub-registry of "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry has been set up, i.e they have done exactly what they should do. Thus, the comments on how this registry is structured should not have any effect on how we progress draft-ietf-mpls-return-path-specified-lsp-ping. Speaking as a MPLS working group co-chair: I find your comments useful, the structure of the IANA registry is not entirely intuitive. It was defined in RFC4379 and has been extended several times, including by this draft. It is not reasonable to require that draft-ietf-mpls-return-path-specified-lsp-ping is used to mend what is not really broken, and I think we can progress the draft (modulo Adrian's comments and comments we get in the IETF last call. Speaking as an individual contributor: If someone wants to write a draft to improve the set up and structure of the registry/sub-registry that would be a good thing, that should be discussed in the working group(s). I would be interested to contribute to such a draft/work. /Loa On 2012-10-19 13:00, t.petch wrote: > ----- Original Message ----- > From: "Mach Chen" > To: "t.petch" ; ; > > Cc: ; > Sent: Friday, October 19, 2012 2:30 AM > >> Hi Tom, >> >> Thanks for your comments! > > You are too kind! > >> Please see my reply inline... >> >> Best regards, >> Mach >>> -----邮件原件----- >>> å‘件人: t.petch [mailto:ietfc@btconnect.com] >>> å‘é€æ—¶é—´: 2012å¹´10月18æ—¥ 23:06 >>> 收件人: Mach Chen; adrian@olddog.co.uk; >>> draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org >>> 抄é€: mpls@ietf.org; mpls-chairs@tools.ietf.org > > >>> Last November, I commented >>> >>> "In retrospect, RFC4379 should have split the sub-TLV range into > common >>> to all >>> TLV, and TLV-unique, which, in effect, is what my idea on 1024 is, > post >>> factum. >>> I would expect others to comment on this as and when they realise > what >>> it says, >>> so I would leave it for a while and see what comes up." >>> >>> and I think that this has now come up. >>> >>> Adrian says below >>> "> I think it does not change the registry for 4379, but it does > changes >>> rule that RFC4379 specifies to TLVs and sub-TLVs." >>> >>> and proposes that what in RFC4379 is >>> "The valid range for TLVs and sub-TLVs is 0-65535. Assignments in > the >>> range 0-16383 and 32768-49161 are made via Standards Action as >>> defined in [IANA]; assignments in the range 16384-31743 and >>> 49162-64511 are made via "Specification Required" as defined > above; >>> values in the range 31744-32767 and 64512-65535 are for Vendor >>> Private Use, and MUST NOT be allocated." >>> >>> becomes >>> "> > 0-16383 Standards Action mandatory TLV >>>>> 16384-31743 Specification Required, Experimental RFC > needed >>>>> 31744-32767 Vendor Private Use, MUST NOT be allocated >>>>> 32768-49161 Standards Action optional TLV >>>>> 49162-64511 Specification Required, Experimental RFC > needed >>>>> 64512-65535 Vendor Private Use, MUST NOT be allocated" >> >> This above is actually proposed in RFC4379, > > Yes, my mistake; I had forgotten that RFC4379 redefined Specification > Required from the usual RFC5226 usage > >> this draft proposes to changes the rule for Reply Path TLV as > follows: >> 0-31743 - Reserved, and MUST NOT be allocated. >> 31744-32767 - Allocated via Standards Action. >> 32768-64511 - Reserved, and MUST NOT be allocated. >> 64512-65531 - Allocated via Standards Action. >> 65531-65535 - Experimental Use, and MUST NOT be allocated. >> >> So the "common" range are 0-31743 and 32768-64511, and the dedicated > ranges are 31744-32767 and 64512-65531 (they are originally defined as > "Vendor Private Use", and now redefined as dedicated code ranges for a > LSP Ping TLV ). And according to the guidance of RFC5226, there are only > 4 code points (65531-65535) left for the Vendor Private Use(It's now > called "Experimental Use" according some expert's suggestion). >> >> So IMHO, the current rule is actually very close to your suggestion, > the only difference is that the common range is not 1024. > > I think I understand. > > But I do think that you are creating a new registry > MPLS-LSP-Ping Parameters - sub-TLVs for Reply Path TLV (Type 21) > (yuk - too cumbersome a name) > > The allocation rules are different for sub-TLVs for other TLVs and I do > not see how IANA can fit that in without making it a distinct > (sub-)registry. (I am not clear from the shepherd write-up whether or > not this has been run past IANA yet; if it has been then no problem - > else, obviously they will see it at IETF Last Call but it would be > better to fix it before then). > > Arguably, this is an update to RFC4379 since that RFC did not > countenance there being different rules for the sub-TLVs of different > TLVs and as RFC4379 stands, would not allow what is now proposed, IMO. > > Since you are using, I assume, the terms as defined in RFC5226, as > opposed to the variants defined in RFC4379, then I do think that you > need a reference to RFC5226. > > And when you replied to Adrian >> The Reply Path TLV can carry and sub-TLV defined for use in the > and said > Should the "carry and sub-TLV" be "carry the sub-TLV"? > I would think it should be carry any sub-TLV, which is somewhat > different. > > Tom Petch > >>> which >>> a) seems to me to be not quite the same ie updates RFC4379 >>> b) does not seem to solve the problem >>> >>> (and there is no reference for RFC5226, but then that is usual for > an >>> MPLS-TP RFC:-( >> >> We actually consider the guidelines in RFC5226, especially for the > design of the "Experimental Use" range. Do you suggest to add an > explicit reference to RFC5226? I am fine to do that. How about add the > following text at the beginning of Section 6.2: >> >> "According to the guidelines defined in [RFC5226], the sub-TLV range > of Reply Path TLV are partitioned as following:" >> >> Hope this resolved your comments! >> >> Best regards, >> Mach >>> >>> >>> Tom Petch >>> >> >> Sniped >> > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From ietfc@btconnect.com Fri Oct 19 11:04:25 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBC021F878A for ; Fri, 19 Oct 2012 11:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di1CAntToy0D for ; Fri, 19 Oct 2012 11:04:24 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1767121F8589 for ; Fri, 19 Oct 2012 11:04:23 -0700 (PDT) Received: from mail138-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Fri, 19 Oct 2012 18:04:21 +0000 Received: from mail138-ch1 (localhost [127.0.0.1]) by mail138-ch1-R.bigfish.com (Postfix) with ESMTP id C96FE6024F; Fri, 19 Oct 2012 18:04:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zz98dI9371Ic89bh936eI542M1432I1418I62a3Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h93fhd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h304l1155h) Received: from mail138-ch1 (localhost.localdomain [127.0.0.1]) by mail138-ch1 (MessageSwitch) id 135066986028972_4447; Fri, 19 Oct 2012 18:04:20 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail138-ch1.bigfish.com (Postfix) with ESMTP id 02BEB420087; Fri, 19 Oct 2012 18:04:20 +0000 (UTC) Received: from AM2PRD0710HT001.eurprd07.prod.outlook.com (157.56.249.213) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 19 Oct 2012 18:04:19 +0000 Received: from BL2PRD0410HT002.namprd04.prod.outlook.com (157.56.240.85) by pod51017.outlook.com (10.255.165.36) with Microsoft SMTP Server (TLS) id 14.16.224.5; Fri, 19 Oct 2012 18:04:17 +0000 Message-ID: <02a601cdae24$1f654a80$4001a8c0@gateway.2wire.net> From: t.petch To: Loa Andersson References: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> <000401cdad4e$c7b080a0$4001a8c0@gateway.2wire.net> <018f01cdade9$04ef76c0$4001a8c0@gateway.2wire.net> <50818BD2.9000001@pi.nu> Date: Fri, 19 Oct 2012 19:02:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.240.85] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] 4p84: AD review of draft-ietf-mpls-return-path-specified-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:04:25 -0000 ----- Original Message ----- From: "Loa Andersson" To: "t.petch" Cc: "Mach Chen" ; ; ; ; Sent: Friday, October 19, 2012 6:20 PM Tom, Speaking as the document shepherd for draft-ietf-mpls-return- path-specified-lsp-ping: The authors of draft-ietf-mpls-return-path-specified-lsp-ping have requested assignments of TLV's and sub-TLV's based on how the "TLV and sub-TLV" sub-registry of "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry has been set up, i.e they have done exactly what they should do. Thus, the comments on how this registry is structured should not have any effect on how we progress draft-ietf-mpls-return-path-specified-lsp-ping. Loa I may be misunderstanding what is being proposed in this I-D (still:-( When I look at the current IANA page for MPLS - LSP - Ping Parameters - TLVs and sub-TLVs it sets out ranges and allocation procedures for TLVs and sub-TLVs and this currently applies to all TLVs and their sub-TLVs. If I have understood what this I-D proposes, then the ranges and allocation procedures for TLVs 1 to 20 remain unaltered, but a different set of ranges and allocation procedures come into play for the new, pre-allocated TLV, TLV 21. If so, then two thoughts. First, I would expect IANA to have to set up a new section on the website, for the sub-TLVs of TLV 21, simply because of this change to ranges and allocations. Second, this would seem to me to be an update to RFC4379 (if you say that it is not, then I will take your word for it). Tom Petch Speaking as a MPLS working group co-chair: I find your comments useful, the structure of the IANA registry is not entirely intuitive. It was defined in RFC4379 and has been extended several times, including by this draft. It is not reasonable to require that draft-ietf-mpls-return-path-specified-lsp-ping is used to mend what is not really broken, and I think we can progress the draft (modulo Adrian's comments and comments we get in the IETF last call. Speaking as an individual contributor: If someone wants to write a draft to improve the set up and structure of the registry/sub-registry that would be a good thing, that should be discussed in the working group(s). I would be interested to contribute to such a draft/work. /Loa On 2012-10-19 13:00, t.petch wrote: > ----- Original Message ----- > From: "Mach Chen" > To: "t.petch" ; ; > > Cc: ; > Sent: Friday, October 19, 2012 2:30 AM > >> Hi Tom, >> >> Thanks for your comments! > > You are too kind! > >> Please see my reply inline... >> >> Best regards, >> Mach >>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: t.petch [mailto:ietfc@btconnect.com] >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B410=E6=9C=8818=E6=97= =A5 23:06 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Mach Chen; adrian@olddog.co.uk; >>> draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org >>> =E6=8A=84=E9=80=81: mpls@ietf.org; mpls-chairs@tools.ietf.org > > >>> Last November, I commented >>> >>> "In retrospect, RFC4379 should have split the sub-TLV range into > common >>> to all >>> TLV, and TLV-unique, which, in effect, is what my idea on 1024 is, > post >>> factum. >>> I would expect others to comment on this as and when they realise > what >>> it says, >>> so I would leave it for a while and see what comes up." >>> >>> and I think that this has now come up. >>> >>> Adrian says below >>> "> I think it does not change the registry for 4379, but it does > changes >>> rule that RFC4379 specifies to TLVs and sub-TLVs." >>> >>> and proposes that what in RFC4379 is >>> "The valid range for TLVs and sub-TLVs is 0-65535. Assignments in > the >>> range 0-16383 and 32768-49161 are made via Standards Action as >>> defined in [IANA]; assignments in the range 16384-31743 and >>> 49162-64511 are made via "Specification Required" as defined > above; >>> values in the range 31744-32767 and 64512-65535 are for Vendor >>> Private Use, and MUST NOT be allocated." >>> >>> becomes >>> "> > 0-16383 Standards Action mandatory TLV >>>>> 16384-31743 Specification Required, Experimental RFC > needed >>>>> 31744-32767 Vendor Private Use, MUST NOT be allocated >>>>> 32768-49161 Standards Action optional TLV >>>>> 49162-64511 Specification Required, Experimental RFC > needed >>>>> 64512-65535 Vendor Private Use, MUST NOT be allocated" >> >> This above is actually proposed in RFC4379, > > Yes, my mistake; I had forgotten that RFC4379 redefined Specification > Required from the usual RFC5226 usage > >> this draft proposes to changes the rule for Reply Path TLV as > follows: >> 0-31743 - Reserved, and MUST NOT be allocated. >> 31744-32767 - Allocated via Standards Action. >> 32768-64511 - Reserved, and MUST NOT be allocated. >> 64512-65531 - Allocated via Standards Action. >> 65531-65535 - Experimental Use, and MUST NOT be allocated. >> >> So the "common" range are 0-31743 and 32768-64511, and the dedicated > ranges are 31744-32767 and 64512-65531 (they are originally defined as > "Vendor Private Use", and now redefined as dedicated code ranges for a > LSP Ping TLV ). And according to the guidance of RFC5226, there are only > 4 code points (65531-65535) left for the Vendor Private Use(It's now > called "Experimental Use" according some expert's suggestion). >> >> So IMHO, the current rule is actually very close to your suggestion, > the only difference is that the common range is not 1024. > > I think I understand. > > But I do think that you are creating a new registry > MPLS-LSP-Ping Parameters - sub-TLVs for Reply Path TLV (Type 21) > (yuk - too cumbersome a name) > > The allocation rules are different for sub-TLVs for other TLVs and I do > not see how IANA can fit that in without making it a distinct > (sub-)registry. (I am not clear from the shepherd write-up whether or > not this has been run past IANA yet; if it has been then no problem - > else, obviously they will see it at IETF Last Call but it would be > better to fix it before then). > > Arguably, this is an update to RFC4379 since that RFC did not > countenance there being different rules for the sub-TLVs of different > TLVs and as RFC4379 stands, would not allow what is now proposed, IMO. > > Since you are using, I assume, the terms as defined in RFC5226, as > opposed to the variants defined in RFC4379, then I do think that you > need a reference to RFC5226. > > And when you replied to Adrian >> The Reply Path TLV can carry and sub-TLV defined for use in the > and said > Should the "carry and sub-TLV" be "carry the sub-TLV"? > I would think it should be carry any sub-TLV, which is somewhat > different. > > Tom Petch > >>> which >>> a) seems to me to be not quite the same ie updates RFC4379 >>> b) does not seem to solve the problem >>> >>> (and there is no reference for RFC5226, but then that is usual for > an >>> MPLS-TP RFC:-( >> >> We actually consider the guidelines in RFC5226, especially for the > design of the "Experimental Use" range. Do you suggest to add an > explicit reference to RFC5226? I am fine to do that. How about add the > following text at the beginning of Section 6.2: >> >> "According to the guidelines defined in [RFC5226], the sub-TLV range > of Reply Path TLV are partitioned as following:" >> >> Hope this resolved your comments! >> >> Best regards, >> Mach >>> >>> >>> Tom Petch >>> >> >> Sniped >> > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From gregory.mirsky@ericsson.com Fri Oct 19 11:13:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B529A21F87B2 for ; Fri, 19 Oct 2012 11:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPR9-VlQk50s for ; Fri, 19 Oct 2012 11:13:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2A31821F8799 for ; Fri, 19 Oct 2012 11:13:26 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9JIFQCL001028; Fri, 19 Oct 2012 13:15:41 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.214]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 19 Oct 2012 14:13:13 -0400 From: Gregory Mirsky To: Loa Andersson , "mpls@ietf.org" , Martin Vigoureux , "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" Date: Fri, 19 Oct 2012 14:13:11 -0400 Thread-Topic: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document Thread-Index: Ac2tAfO0ZlEYsXV4TDCTNM/T+0ysQwBItZ+A Message-ID: References: <507FAF2D.5020907@pi.nu> In-Reply-To: <507FAF2D.5020907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:13:26 -0000 Support I've been MPLS-RT reviewer of this document. Authors addressed my comments.= Problem considered appears to be practical. Regards, Greg=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, October 18, 2012 12:27 AM To: mpls@ietf.org; Martin Vigoureux; draft-ali-mpls-inter-domain-p2mp-rsvp-= te-lsp@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp= -rsvp-te-lsp a working group document Working group, this is to start a two week poll on adopting draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-09 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls at ietf.org). Please give an technical motivation for you= r support/not support, especially if you think that the document should not= be adopted as a working group document. This poll ends November 07, 2012. There is one IPR claim against this document - http://datatracker.ietf.org/= ipr/1861/ . All the co-authors has stated on the mailing list that they are not aware o= f any other IPR claims than those already disclosed. If there are IPR claims from any other party, please remember that the IPR = is open. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ____________= ___________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Sat Oct 20 09:54:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8290221F87E0; Sat, 20 Oct 2012 09:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOSLaXBfLwcf; Sat, 20 Oct 2012 09:54:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E9121F87A0; Sat, 20 Oct 2012 09:54:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121020165459.20087.16567.idtracker@ietfa.amsl.com> Date: Sat, 20 Oct 2012 09:54:59 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-security-framework-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 16:54:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Security Framework Author(s) : Luyuan Fang Ben Niven-Jenkins Scott Mansfield Richard F. Graveman Filename : draft-ietf-mpls-tp-security-framework-05.txt Pages : 11 Date : 2012-10-20 Abstract: This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new OAM capabilities, a transport- oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats, security requirements for MPLS-TP, and mitigation procedures for MPLS-TP networks and MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC5920 "MPLS and GMPLS MPLS and GMPLS security framework" by providing additional security considerations which are applicable to the MPLS-TP extensions. All the security considerations from RFC5920 are assumed to apply. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionality of a packet transport network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-security-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-security-framework-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-security-framework-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Oct 20 11:14:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6822C21F848B; Sat, 20 Oct 2012 11:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz4hIg346H5o; Sat, 20 Oct 2012 11:14:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F5821F8886; Sat, 20 Oct 2012 11:14:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121020181433.8945.75740.idtracker@ietfa.amsl.com> Date: Sat, 20 Oct 2012 11:14:33 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-ttl-tlv-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 18:14:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Definition of Time-to-Live TLV for LSP-Ping Mechanisms Author(s) : Sami Boutros Siva Sivabalan George Swallow Shaleen Saxena Vishwas Manral Sam Aldrin Filename : draft-ietf-mpls-lsp-ping-ttl-tlv-04.txt Pages : 8 Date : 2012-10-20 Abstract: LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment PseudoWire (MS-PW) from any node on the path of the MS-PW. This document defines a TLV to address this shortcoming. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ttl-tlv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-ttl-tlv-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-ttl-tlv-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mach.chen@huawei.com Sun Oct 21 18:45:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD1D21F8A91 for ; Sun, 21 Oct 2012 18:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.508 X-Spam-Level: *** X-Spam-Status: No, score=3.508 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_15=0.6, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMHLOsFD02z4 for ; Sun, 21 Oct 2012 18:45:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 59B8A21F8A87 for ; Sun, 21 Oct 2012 18:45:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKU82288; Mon, 22 Oct 2012 01:45:23 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 02:45:20 +0100 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 02:45:22 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.192]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Mon, 22 Oct 2012 09:45:18 +0800 From: Mach Chen To: "t.petch" , "adrian@olddog.co.uk" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" Thread-Topic: [mpls] 4p84: AD review of draft-ietf-mpls-return-path-specified-lsp-ping Thread-Index: AQHNrU7a+BxJRqw4D0Gg5Y5DrX3trpe/zezAgACpoByABBfPEA== Date: Mon, 22 Oct 2012 01:45:18 +0000 Message-ID: References: <076301cdaca6$d25b7490$77125db0$@olddog.co.uk> <000401cdad4e$c7b080a0$4001a8c0@gateway.2wire.net> <018f01cdade9$04ef76c0$4001a8c0@gateway.2wire.net> In-Reply-To: <018f01cdade9$04ef76c0$4001a8c0@gateway.2wire.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.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIDRwODQ6ICBBRCByZXZpZXcgb2YgZHJhZnQt?= =?gb2312?b?aWV0Zi1tcGxzLXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZw==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 01:45:35 -0000 VG9tLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkhDQoNClBsZWFzZSBzZWUgbXkgcmVwbHkgaW5s aW5lLi4uDQoNCk1hbnkgdGhhbmtzLA0KTWFjaA0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8 /sjLOiB0LnBldGNoIFttYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbV0NCj4gt6LLzcqxvOQ6IDIw MTLE6jEw1MIxOcjVIDE5OjAxDQo+IMrVvP7IyzogTWFjaCBDaGVuOyBhZHJpYW5Ab2xkZG9nLmNv LnVrOw0KPiBkcmFmdC1pZXRmLW1wbHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nLmFs bEB0b29scy5pZXRmLm9yZw0KPiCzrcvNOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZw0KPiDW98ziOiBSZTogW21wbHNdIDRwODQ6IEFEIHJldmlldyBvZg0KPiBkcmFm dC1pZXRmLW1wbHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nDQo+IA0KPiAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJNYWNoIENoZW4iIDxtYWNoLmNoZW5AaHVh d2VpLmNvbT4NCj4gVG86ICJ0LnBldGNoIiA8aWV0ZmNAYnRjb25uZWN0LmNvbT47IDxhZHJpYW5A b2xkZG9nLmNvLnVrPjsNCj4gPGRyYWZ0LWlldGYtbXBscy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQt bHNwLXBpbmcuYWxsQHRvb2xzLmlldGYub3JnPg0KPiBDYzogPG1wbHNAaWV0Zi5vcmc+OyA8bXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxOSwgMjAx MiAyOjMwIEFNDQo+IA0KPiA+IEhpIFRvbSwNCj4gPg0KPiA+IFRoYW5rcyBmb3IgeW91ciBjb21t ZW50cyENCj4gDQo+IFlvdSBhcmUgdG9vIGtpbmQhDQo+IA0KPiA+IFBsZWFzZSBzZWUgbXkgcmVw bHkgaW5saW5lLi4uDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gTWFjaA0KPiA+ID4gLS0t LS3Tyrz+1K28/i0tLS0tDQo+ID4gPiC3orz+yMs6IHQucGV0Y2ggW21haWx0bzppZXRmY0BidGNv bm5lY3QuY29tXQ0KPiA+ID4gt6LLzcqxvOQ6IDIwMTLE6jEw1MIxOMjVIDIzOjA2DQo+ID4gPiDK 1bz+yMs6IE1hY2ggQ2hlbjsgYWRyaWFuQG9sZGRvZy5jby51azsNCj4gPiA+IGRyYWZ0LWlldGYt bXBscy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmcuYWxsQHRvb2xzLmlldGYub3JnDQo+ ID4gPiCzrcvNOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiAg Pg0KPiA+ID4gTGFzdCBOb3ZlbWJlciwgSSBjb21tZW50ZWQNCj4gPiA+DQo+ID4gPiAiSW4gcmV0 cm9zcGVjdCwgUkZDNDM3OSBzaG91bGQgaGF2ZSBzcGxpdCB0aGUgc3ViLVRMViByYW5nZSBpbnRv DQo+IGNvbW1vbg0KPiA+ID4gdG8gYWxsDQo+ID4gPiBUTFYsIGFuZCBUTFYtdW5pcXVlLCB3aGlj aCwgaW4gZWZmZWN0LCBpcyB3aGF0IG15IGlkZWEgb24gMTAyNCBpcywNCj4gcG9zdA0KPiA+ID4g ZmFjdHVtLg0KPiA+ID4gSSB3b3VsZCBleHBlY3Qgb3RoZXJzIHRvIGNvbW1lbnQgb24gdGhpcyBh cyBhbmQgd2hlbiB0aGV5IHJlYWxpc2UNCj4gd2hhdA0KPiA+ID4gaXQgc2F5cywNCj4gPiA+IHNv IEkgd291bGQgbGVhdmUgaXQgZm9yIGEgd2hpbGUgYW5kIHNlZSB3aGF0IGNvbWVzIHVwLiINCj4g PiA+DQo+ID4gPiBhbmQgSSB0aGluayB0aGF0IHRoaXMgaGFzIG5vdyBjb21lIHVwLg0KPiA+ID4N Cj4gPiA+IEFkcmlhbiBzYXlzIGJlbG93DQo+ID4gPiAiPiBJIHRoaW5rIGl0IGRvZXMgbm90IGNo YW5nZSB0aGUgcmVnaXN0cnkgZm9yIDQzNzksIGJ1dCBpdCBkb2VzDQo+IGNoYW5nZXMNCj4gPiA+ IHJ1bGUgdGhhdCBSRkM0Mzc5IHNwZWNpZmllcyB0byBUTFZzIGFuZCBzdWItVExWcy4iDQo+ID4g Pg0KPiA+ID4gYW5kIHByb3Bvc2VzIHRoYXQgd2hhdCBpbiBSRkM0Mzc5IGlzDQo+ID4gPiAiVGhl IHZhbGlkIHJhbmdlIGZvciBUTFZzIGFuZCBzdWItVExWcyBpcyAwLTY1NTM1LiAgQXNzaWdubWVu dHMgaW4NCj4gdGhlDQo+ID4gPiAgICByYW5nZSAwLTE2MzgzIGFuZCAzMjc2OC00OTE2MSBhcmUg bWFkZSB2aWEgU3RhbmRhcmRzIEFjdGlvbiBhcw0KPiA+ID4gICAgZGVmaW5lZCBpbiBbSUFOQV07 IGFzc2lnbm1lbnRzIGluIHRoZSByYW5nZSAxNjM4NC0zMTc0MyBhbmQNCj4gPiA+ICAgIDQ5MTYy LTY0NTExIGFyZSBtYWRlIHZpYSAiU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCIgYXMgZGVmaW5lZA0K PiBhYm92ZTsNCj4gPiA+ICAgIHZhbHVlcyBpbiB0aGUgcmFuZ2UgMzE3NDQtMzI3NjcgYW5kIDY0 NTEyLTY1NTM1IGFyZSBmb3IgVmVuZG9yDQo+ID4gPiAgICBQcml2YXRlIFVzZSwgYW5kIE1VU1Qg Tk9UIGJlIGFsbG9jYXRlZC4iDQo+ID4gPg0KPiA+ID4gYmVjb21lcw0KPiA+ID4gIj4gPiAgICAg ICAwLTE2MzgzICAgICAgIFN0YW5kYXJkcyBBY3Rpb24gbWFuZGF0b3J5IFRMVg0KPiA+ID4gPiA+ ICAgICAgIDE2Mzg0LTMxNzQzICAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCwgRXhwZXJpbWVudGFs IFJGQw0KPiBuZWVkZWQNCj4gPiA+ID4gPiAgICAgICAzMTc0NC0zMjc2NyAgIFZlbmRvciBQcml2 YXRlIFVzZSwgTVVTVCBOT1QgYmUgYWxsb2NhdGVkDQo+ID4gPiA+ID4gICAgICAgMzI3NjgtNDkx NjEgICBTdGFuZGFyZHMgQWN0aW9uIG9wdGlvbmFsIFRMVg0KPiA+ID4gPiA+ICAgICAgIDQ5MTYy LTY0NTExICAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCwgRXhwZXJpbWVudGFsIFJGQw0KPiBuZWVk ZWQNCj4gPiA+ID4gPiAgICAgICA2NDUxMi02NTUzNSAgIFZlbmRvciBQcml2YXRlIFVzZSwgTVVT VCBOT1QgYmUgYWxsb2NhdGVkIg0KPiA+DQo+ID4gVGhpcyBhYm92ZSBpcyBhY3R1YWxseSBwcm9w b3NlZCBpbiBSRkM0Mzc5LA0KPiANCj4gWWVzLCBteSBtaXN0YWtlOyBJIGhhZCBmb3Jnb3R0ZW4g dGhhdCBSRkM0Mzc5IHJlZGVmaW5lZCBTcGVjaWZpY2F0aW9uDQo+IFJlcXVpcmVkIGZyb20gdGhl IHVzdWFsIFJGQzUyMjYgdXNhZ2UNCj4gDQo+ID4gICAgIHRoaXMgZHJhZnQgcHJvcG9zZXMgdG8g Y2hhbmdlcyB0aGUgcnVsZSBmb3IgUmVwbHkgUGF0aCBUTFYgYXMNCj4gZm9sbG93czoNCj4gPiAg ICAwLTMxNzQzIC0gUmVzZXJ2ZWQsIGFuZCBNVVNUIE5PVCBiZSBhbGxvY2F0ZWQuDQo+ID4gICAg MzE3NDQtMzI3NjcgLSBBbGxvY2F0ZWQgdmlhIFN0YW5kYXJkcyBBY3Rpb24uDQo+ID4gICAgMzI3 NjgtNjQ1MTEgLSBSZXNlcnZlZCwgYW5kIE1VU1QgTk9UIGJlIGFsbG9jYXRlZC4NCj4gPiAgICA2 NDUxMi02NTUzMSAtIEFsbG9jYXRlZCB2aWEgU3RhbmRhcmRzIEFjdGlvbi4NCj4gPiAgICA2NTUz MS02NTUzNSAtIEV4cGVyaW1lbnRhbCBVc2UsIGFuZCBNVVNUIE5PVCBiZSBhbGxvY2F0ZWQuDQo+ ID4NCj4gPiBTbyB0aGUgImNvbW1vbiIgcmFuZ2UgYXJlIDAtMzE3NDMgYW5kIDMyNzY4LTY0NTEx LCBhbmQgdGhlIGRlZGljYXRlZA0KPiByYW5nZXMgYXJlIDMxNzQ0LTMyNzY3IGFuZCA2NDUxMi02 NTUzMSAodGhleSBhcmUgb3JpZ2luYWxseSBkZWZpbmVkIGFzDQo+ICJWZW5kb3IgUHJpdmF0ZSBV c2UiLCBhbmQgbm93IHJlZGVmaW5lZCBhcyBkZWRpY2F0ZWQgY29kZSByYW5nZXMgZm9yIGENCj4g TFNQIFBpbmcgVExWICkuIEFuZCBhY2NvcmRpbmcgdG8gdGhlIGd1aWRhbmNlIG9mIFJGQzUyMjYs IHRoZXJlIGFyZSBvbmx5DQo+IDQgY29kZSBwb2ludHMgKDY1NTMxLTY1NTM1KSBsZWZ0IGZvciB0 aGUgVmVuZG9yIFByaXZhdGUgVXNlKEl0J3Mgbm93DQo+IGNhbGxlZCAiRXhwZXJpbWVudGFsIFVz ZSIgYWNjb3JkaW5nIHNvbWUgZXhwZXJ0J3Mgc3VnZ2VzdGlvbikuDQo+ID4NCj4gPiBTbyBJTUhP LCB0aGUgY3VycmVudCBydWxlIGlzIGFjdHVhbGx5IHZlcnkgY2xvc2UgdG8geW91ciBzdWdnZXN0 aW9uLA0KPiB0aGUgb25seSBkaWZmZXJlbmNlIGlzIHRoYXQgdGhlIGNvbW1vbiByYW5nZSBpcyBu b3QgMTAyNC4NCj4gDQo+IEkgdGhpbmsgSSB1bmRlcnN0YW5kLg0KPiANCj4gQnV0IEkgZG8gdGhp bmsgdGhhdCB5b3UgYXJlIGNyZWF0aW5nIGEgbmV3IHJlZ2lzdHJ5DQo+IE1QTFMtTFNQLVBpbmcg UGFyYW1ldGVycyAtIHN1Yi1UTFZzIGZvciBSZXBseSBQYXRoIFRMViAoVHlwZSAyMSkNCj4gKHl1 ayAtIHRvbyBjdW1iZXJzb21lIGEgbmFtZSkNCj4gDQo+IFRoZSBhbGxvY2F0aW9uIHJ1bGVzIGFy ZSBkaWZmZXJlbnQgZm9yIHN1Yi1UTFZzIGZvciBvdGhlciBUTFZzIGFuZCBJIGRvDQo+IG5vdCBz ZWUgaG93IElBTkEgY2FuIGZpdCB0aGF0IGluIHdpdGhvdXQgbWFraW5nIGl0IGEgZGlzdGluY3QN Cj4gKHN1Yi0pcmVnaXN0cnkuICAoSSBhbSBub3QgY2xlYXIgZnJvbSB0aGUgc2hlcGhlcmQgd3Jp dGUtdXAgd2hldGhlciBvcg0KPiBub3QgdGhpcyBoYXMgYmVlbiBydW4gcGFzdCBJQU5BIHlldDsg aWYgaXQgaGFzIGJlZW4gdGhlbiBubyBwcm9ibGVtIC0NCj4gZWxzZSwgb2J2aW91c2x5IHRoZXkg d2lsbCBzZWUgaXQgYXQgSUVURiBMYXN0IENhbGwgYnV0IGl0IHdvdWxkIGJlDQo+IGJldHRlciB0 byBmaXggaXQgYmVmb3JlIHRoZW4pLg0KPiANCj4gQXJndWFibHksIHRoaXMgaXMgYW4gdXBkYXRl IHRvIFJGQzQzNzkgc2luY2UgdGhhdCBSRkMgZGlkIG5vdA0KPiBjb3VudGVuYW5jZSB0aGVyZSBi ZWluZyBkaWZmZXJlbnQgcnVsZXMgZm9yIHRoZSBzdWItVExWcyBvZiBkaWZmZXJlbnQNCj4gVExW cyBhbmQgYXMgUkZDNDM3OSBzdGFuZHMsIHdvdWxkIG5vdCBhbGxvdyB3aGF0IGlzIG5vdyBwcm9w b3NlZCwgSU1PLg0KDQpJIHBlcnNvbmFsbHkgYWdyZWUuDQoNCj4gDQo+IFNpbmNlIHlvdSBhcmUg dXNpbmcsIEkgYXNzdW1lLCB0aGUgdGVybXMgYXMgZGVmaW5lZCBpbiBSRkM1MjI2LCBhcw0KPiBv cHBvc2VkIHRvIHRoZSB2YXJpYW50cyBkZWZpbmVkIGluIFJGQzQzNzksIHRoZW4gSSBkbyB0aGlu ayB0aGF0IHlvdQ0KPiBuZWVkIGEgcmVmZXJlbmNlIHRvIFJGQzUyMjYuDQoNCk9LLg0KDQo+IA0K PiBBbmQgd2hlbiB5b3UgcmVwbGllZCB0byBBZHJpYW4NCj4gPiAgICBUaGUgUmVwbHkgUGF0aCBU TFYgY2FuIGNhcnJ5IGFuZCBzdWItVExWIGRlZmluZWQgZm9yIHVzZSBpbiB0aGUNCj4gYW5kIHNh aWQNCj4gU2hvdWxkIHRoZSAiY2FycnkgYW5kIHN1Yi1UTFYiIGJlICJjYXJyeSB0aGUgc3ViLVRM ViI/DQo+IEkgd291bGQgdGhpbmsgaXQgc2hvdWxkIGJlIGNhcnJ5IGFueSBzdWItVExWLCB3aGlj aCBpcyBzb21ld2hhdA0KPiBkaWZmZXJlbnQuDQoNCkFncmVlLg0KDQoNCk1hbnkgdGhhbmtzLA0K TWFjaA0KPiANCj4gVG9tIFBldGNoDQo+IA0KPiA+ID4gd2hpY2gNCj4gPiA+IGEpIHNlZW1zIHRv IG1lIHRvIGJlIG5vdCBxdWl0ZSB0aGUgc2FtZSBpZSB1cGRhdGVzIFJGQzQzNzkNCj4gPiA+IGIp IGRvZXMgbm90IHNlZW0gdG8gc29sdmUgdGhlIHByb2JsZW0NCj4gPiA+DQo+ID4gPiAoYW5kIHRo ZXJlIGlzIG5vIHJlZmVyZW5jZSBmb3IgUkZDNTIyNiwgYnV0IHRoZW4gdGhhdCBpcyB1c3VhbCBm b3INCj4gYW4NCj4gPiA+IE1QTFMtVFAgUkZDOi0oDQo+ID4NCj4gPiBXZSBhY3R1YWxseSBjb25z aWRlciB0aGUgZ3VpZGVsaW5lcyBpbiBSRkM1MjI2LCBlc3BlY2lhbGx5IGZvciB0aGUNCj4gZGVz aWduIG9mIHRoZSAiRXhwZXJpbWVudGFsIFVzZSIgcmFuZ2UuIERvIHlvdSBzdWdnZXN0IHRvIGFk ZCBhbg0KPiBleHBsaWNpdCByZWZlcmVuY2UgdG8gUkZDNTIyNj8gSSBhbSBmaW5lIHRvIGRvIHRo YXQuIEhvdyBhYm91dCBhZGQgdGhlDQo+IGZvbGxvd2luZyB0ZXh0IGF0IHRoZSBiZWdpbm5pbmcg b2YgU2VjdGlvbiA2LjI6DQo+ID4NCj4gPiAiQWNjb3JkaW5nIHRvIHRoZSBndWlkZWxpbmVzIGRl ZmluZWQgaW4gW1JGQzUyMjZdLCB0aGUgc3ViLVRMViByYW5nZQ0KPiBvZiBSZXBseSBQYXRoIFRM ViBhcmUgcGFydGl0aW9uZWQgYXMgZm9sbG93aW5nOiINCj4gPg0KPiA+IEhvcGUgdGhpcyByZXNv bHZlZCB5b3VyIGNvbW1lbnRzIQ0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IE1hY2gNCj4g PiA+DQo+ID4gPg0KPiA+ID4gVG9tIFBldGNoDQo+ID4gPg0KPiA+DQo+ID4gU25pcGVkDQo+ID4N Cj4gDQoNCg== From internet-drafts@ietf.org Sun Oct 21 18:51:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1D621F87B1; Sun, 21 Oct 2012 18:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2JxfkLiiech; Sun, 21 Oct 2012 18:51:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606B021F8A2C; Sun, 21 Oct 2012 18:51:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022015104.8423.17435.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 18:51:04 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 01:51:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Return Path Specified LSP Ping Author(s) : Mach(Guoyi) Chen Wei Cao So Ning Frederic Jounay Simon Delord Filename : draft-ietf-mpls-return-path-specified-lsp-ping-11.txt Pages : 21 Date : 2012-10-21 Abstract: This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more robust. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-= ping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-return-path-specified-lsp-ping-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-return-path-specified-ls= p-ping-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From chengwq@gmail.com Mon Oct 22 02:52:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F4221F8B45 for ; Mon, 22 Oct 2012 02:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8ShWRFnzlfw for ; Mon, 22 Oct 2012 02:52:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 405ED21F8B3E for ; Mon, 22 Oct 2012 02:52:18 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3015187vbb.31 for ; Mon, 22 Oct 2012 02:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=qobwW4AZBTCERl+WDD23zGG/Bxt8eu0jKoYliuACkmw=; b=a4Ph4WfIP/SjyG9iZ5pajR73dLAIMhA3Zc3WkmsJJ8cSM4IIePk8+lBf5mzUFV7HCM 5aHwUqE1elGNKSOKHbaO4DyUu5biqUhfvFNXsZgMiGoQP0rZ8OAYioazpuzP8dwjTT89 iGFNTmhWRSF/LMpXgVB8jKbf6ebsW210HqTUGDT+tdip3TqQHdPPqgsZ87hcBsj+rdQy 83ZbPmAX8MdwXoccFSanfOABFSmZmqMkqwdEe5CtXO+/KRtrPm2rfXYiGRA53ytni2sJ wwf+kFGqwpmmhakBxwJbBLpaEGUvm9BE/rvrg2zfJF/hLMxIU7m+C29VBH4rSmb00Hdm Ih8Q== MIME-Version: 1.0 Received: by 10.59.5.229 with SMTP id cp5mr14942318ved.32.1350899537663; Mon, 22 Oct 2012 02:52:17 -0700 (PDT) Received: by 10.58.28.210 with HTTP; Mon, 22 Oct 2012 02:52:17 -0700 (PDT) Date: Mon, 22 Oct 2012 17:52:17 +0800 Message-ID: From: cheng weiqiang To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org Subject: [mpls] Request for comments on 'draft-cheng-mpls-tp-shared-ring-protection' X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 09:52:18 -0000 Hello, Recently, the topics on ring topology-specific protection for MPLS-TP are discussed frequently. It will help operators to deploy a simple and effective protection as that in SDH/Sonet. In this case, we have written a draft on ring topology-specific optimized protection mechanism in following link. It can cover multiple adjacent nodes and links failures. The number of LSP on the Ring is O(2N) (N is Node number) for both P2P wrapping solution and steering solution. Hope you could kindly help to review and comment it. http://www.ietf.org/internet-drafts/draft-cheng-mpls-tp-shared-ring-protection-00.txt Thanks a lot for your kind review. Best regards, Weiqiang Cheng From stbryant@cisco.com Mon Oct 22 06:12:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0FF21F8B8C for ; Mon, 22 Oct 2012 06:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.579 X-Spam-Level: X-Spam-Status: No, score=-110.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPnnq1L-4d+Z for ; Mon, 22 Oct 2012 06:12:37 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3707721F8B9E for ; Mon, 22 Oct 2012 06:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4438; q=dns/txt; s=iport; t=1350911557; x=1352121157; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Xts93BPle24ncBvHBMeEhlyRaJO8sH0kC3hlGFO715E=; b=Nf1kEyIghn46qftIoHJtQa5R8anf2oUUwFtB+mHBfrQaoNNNteUyOjqW rSNbQYNtv0r+eG/58h6XRyamH8ESxoo3Imm9GLg8WQL4Wov7p7egs7y11 ngI7UBozrUlAUslrjmltwS3VP1TITEK10kPK0TPxzVx71mH61yBHjtpYZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFACVFhVCQ/khL/2dsb2JhbABFvU+DQYEIgiABAQEDARIBAiM1CwEQCxgJFg8JAwIBAgFFBg0BBwEBHodcBpt6g04Qm2yLX4ZvA5VxhWSIaoEGZYJw X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="9003245" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 22 Oct 2012 13:12:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9MDCZrA030493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 13:12:35 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9MDCVBE028644; Mon, 22 Oct 2012 14:12:32 +0100 (BST) Message-ID: <5085463F.6040506@cisco.com> Date: Mon, 22 Oct 2012 14:12:31 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Eric Gray References: <4FC58D13.6050803@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-gach-adv@tools.ietf.org" Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 13:12:38 -0000 Eric, Thank you for your review. To move the draft along I have addressed the points you make as shown in line. If my co-authors wish to amend this text, we will do so during IETF LC and copy you on these amendments. On 08/06/2012 21:28, Eric Gray wrote: > > My Last call review comments on draft-ietf-mpls-gach-adv-02: > > In general, this is a very well written draft that is nearly > ready to publish. There is one major issue that needs to be > addressed. > > Major Issue: > > There is an important point that does not appear to have been > made sufficiently clear in the IANA Considerations section. > > For the TLV types, I assume that the TLV type numbers (section > 9.4) are intended to be allocated within the context of an > application ID (allocated according to section 9.3). > > This is very much not clear. In fact, reading section 9.4 as > it now stands, it looks as if there is a single context for > TLV IDs, that there are a maximum number of TLV IDs available > of 255, and that five of these are used by the application in > this draft. > > This seems odd, given that the number space for application IDs > is from 0x000 to 0xFFFF. It would seem that we anticipate we > will have a lot of applications for this protocol, but not too > many will actually need to say anything. > > Hence my assumption about the intent of the TLV type number > space. > > Please clarify what you are really expecting from this TLV Type > Registry. In section 3 it says: The Type field identifies the TLV Object and is scoped to a specific application; each application creates an IANA registry to track its Type values. and in Section 4 it says: The GAP supports several TLV objects related to its own operation via the Application ID 0x0000. I have clarified that 9.4 refers to the GAP itself by amending the registry title to be "G-ACh Advertisement Protocol: GAP TLV Objects (Application ID 0)" > > Minor Issue: > > In the second pargraph on page 4, I believe one can also use > LLDP to discover the MAC address of an adjacent Ethernet peer. > The authors mention this proposed GAP protocol standard can > be used to exchange information similar to the use of LLDP, > and then follows this immediately with a special case to find > out an adjacent peer's MAC address in the case where IP isn't > supported - using GAP. > > Have the authors given any thought to the possibility that the > fact that IP is not supported may be attributable to the fact > that Ethernet _is_ supported for L2 peer-to-peer exchanges, > including LLDP? IMO, this makes the "special case" not so > much so. > > I think - given that there are a few things we know about this > case (e.g. - both Ethernet and MPLS are presumed to apply), it > would be useful to be clear about when it would be the case that: > > 1) IP is not present, > 2) Ethernet is present, > 3) Knowing the MAC address of an adjacent Ethernet entity is > needed, and > 4) LLDP is not already used. The GAP protocol can be used over a datalink other than Ethernet (see section 1.1), including over an MPLS-TP segment that is itself running over an MPLS-TP segment. Whilst one use is to learn the MAC address, it has a number of purposes including announcing the configuration of the adverting node. Using a single protocol to announce the MAC address along with other configuration information seems to be a simplification compared to implementing LLDP just for the MAC addresses. The paragraph now says: In networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921] that do not also support IP, the normal protocols used to determine the Ethernet address of an adjacent MPLS node, such as the Address Resolution Protocol [RFC0826] and IP version 6 Neighbor Discovery [RFC4861] are not available. The G-ACh advertisement protocol can be used to discover the Ethernet MAC addresses of MPLS-TP nodes lacking IP capability [I-D.ietf-mpls-tp-ethernet-addressing]. Where it is anticipated that the sole purpose of the GAP will be to provide Ethernet MAC address learning, the use of LLDP SHOULD be considered. > > NIT: > > I find the phrase "a primary purpose" somewhat jarring in the > Introduction. Is there more than one "primary" purpose? > Perhaps "One key" as opposed to "A primary"? s/A primary purpose/ An important use/ - Stewart From stbryant@cisco.com Mon Oct 22 07:43:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC6521F8BAD for ; Mon, 22 Oct 2012 07:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.959 X-Spam-Level: X-Spam-Status: No, score=-109.959 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwUJQ2sA8Itr for ; Mon, 22 Oct 2012 07:43:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0C80321F8B7E for ; Mon, 22 Oct 2012 07:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7272; q=dns/txt; s=iport; t=1350916971; x=1352126571; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JtLufZ8ZZ25MtpMZTlT58tC0pMkp+i/PypK439oE1cc=; b=AVLqPdDd+4iA6DgnMUUKUYQ56anpNzQpsFthYHhSHH6QDUiwXCFNiau/ cLp5h0A9WV4fwOU69/qTymXlHB3EHQWW6axKMvMyPf0/05r1ZpUJMDqSO spB0REpQ75noF1KpCx4oSNCDPsdqVwvblDUzlBRLS8LDoZmfQy5NqLk36 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAORahVCQ/khR/2dsb2JhbABFwRCBCIIgAQEBAwEBAQEPAQIjNgQGAQULCxIGCRYPCQMCAQIBFSIOBg0BBQIBAR6HXAYLnAmDThCbdYtfhm8Dkj+DMoVkiGqBBmWCcIFZBAEb X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="77657811" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 22 Oct 2012 14:42:26 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9MEgQKG013668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 14:42:26 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9MEgOPl004444; Mon, 22 Oct 2012 15:42:25 +0100 (BST) Message-ID: <50855B50.5010405@cisco.com> Date: Mon, 22 Oct 2012 15:42:24 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4FDCD78C.6000907@joelhalpern.com> In-Reply-To: <4FDCD78C.6000907@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Review of draft-ietf-mpls-gach-adv-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:43:05 -0000 On 16/06/2012 19:59, Joel M. Halpern wrote: > (Sorry this is a day light. Messy travel schedule.) > This document is clear, concise, and useful. > However, I do have some comments and questions. > > > The TLV structure is carefully laid out so that the Length is on a 16 > bit boundary, and the whole thing can be processed on 32 bit > boundaries. However, there is no requirement for padding or alignment > on TLVs. As such, implementations must allow for someone defining a > TLV that takes an odd number of bytes, thus apparently removing all > the advantage of the alignment care. > This is a good point. The IETF tends to align align fields and forgets that the most common datalink header is 14bytes. The existing TLVs do not need padding. Reserved fields have proved useful in protocols in the past, and thus it seems unwise to remove them. I propose leaving the text as is, but if other feel strongly that we need to make a change here we will do so during the next review period. > What is the point of the Message Identifier? It is set by the sender > as they please. It is never sent back to the sender. So the receiver > can not do anything with it, since they have no idea how it was set. > And the sender can not do anything with it, since they sender never > sees it again. This field either needs more explaantion, or needs to > be removed. Later in the section it says: In some cases additional reliability may be desired for the delivery of a GAP message. When this is the case, the RECOMMENDED procedure is to send three instances of the message in succession, separated by a delay appropriate to the application. This procedure SHOULD be used, if at all, only for messages that are in some sense exceptional; for example when sending a flush instruction following device reset. I have added the following sentence: "The MI may be used to detect and discard duplicate messages." > > Section 4 on the G-ACh Advertisement Protocol TLVs starts by saying > that the TLVS for the GAP protocol itself "represent metadata and > processing instructions rather than static data that is meant to be > retained." But information like Source Address distinctly appears to > be static data meant to be retained. yes, it should be included in > each GAP message. But it seems likely that the primary use of having > the information would be based on retention / reuse. Flush and Suppress are action messages that are not intended to be retained. Source and Authentication only have the scope of the message that they are sent in, although one could argue that that source is of use to the applications and should in any case be retained until the next message is received to note a change in sender. It is arguable as to whether this is retention or short term operation of the state machine. However the point here is that the TLVs used to operate the GAP itself are ephemeral and hence I think the preamble is correct. > > In section 3, 4th paragraph, the text says > The payload of a GAP message is an Application Data Block (ADB) > consisting of one or more block elements. > But, the payload consists of a fixed header followed by the ADB. Since > this fixed header is not inherited from some other document, and is > described here, the summary should mention it. It now says: A Gap message consits of a fixed header followed by a GAP payload. The payload of a GAP message is an Application Data Block (ADB) consisting of one or more block elements..... > > This one is probably obvious to folks who have been following the > G-ACh work more closely, so it may not be a real issue. The GAP > Request TLV (section 4.2) asks for a response. In an MPLS-TP network > where, for example, the LSPs and their usage are provisioned, is the > assumption that that the end-points know which LSP goes back to the > end-point from which the request was received? In P2P MPLS-TP the relationship between the LSP pair is known. This is discussed in the MPLS-TP architecture. P2MP is more complex, but we have not finished it's architecture and thus it is premature to comment on that. > Such knowledge is presumably NOT on the basis of the Source Address > field. Is more explanation of this useful? I think that if you are implementing this in an MPLS-TP case you know this, however if you are operating in a non-MPLS-TP environment, you may well use SA to construct the response, but again the implementer would know this. The key point here is that the implementer knows the context and can work out how to make this work without us enumerating the set context that we currently have in mind. > > For the GAP Suppress TLV (section 4.4) I presume a length of 2 and a > Duration of 0 would remove all previously specified suppressions? I have added A duration of zero cancels any existing suppress requests for the listed applications. > It would seem this should be stated. > On a related note, why does this TLV need a duration? Shouldn't the > lifetime specified at the application level be sufficient? The application lifetime is the sender saying how long the data is valid. The suppress duration the receiver saying don't remind me (perhaps because it currently does not care to receive information about that application). > Also, this is another example of Application 0 information that is > retained. It is still semi-ephemeral rather than permanent, and I think that is the distinction. > > If a receiver has data for application A, TLV A-X, and receives a new > message with application A, lifetime 0, TLV A-X, is that normally an > instruction to delete the stored information about A-X? Yes, this is an execute immediate protocol so the data would be overwritten on receipt of the the TLV and immediately marked timed out. The text now says: The Lifetime field specifies how long, in seconds, the receiver should retain the data in this message. If the lifetime is zero the data is immediately marked as expired. > > In order to avoid an argument about key management, would an exemplary > (non-normative) reference to the karp keytables draft as a way the > key-IDs and keys might be managed be useful? I have added Implementors SHOULD consider the use of [ID.draft-ietf-karp-crypto-key-table] for key management. the ref is informative > > In section 6.2, first paragraph, there should probably be a phrase > noting that the Authentication data is set as described in the > algorithm below. > It already says: The sender then computes a hash for the message as described below, and fills the Authentication Data field of the GAP Authentication TLV with the hash value. The message is then sent. but I will put in a refence to section 6.3 to make it clearer Thank you for your comments - Stewart > Yours, > Joel M. Halpern > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From adrian@olddog.co.uk Mon Oct 22 07:44:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A17A21F8B43 for ; Mon, 22 Oct 2012 07:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p32QXGI87j4e for ; Mon, 22 Oct 2012 07:44:37 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3D121F8A6E for ; Mon, 22 Oct 2012 07:44:36 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9MEiZpK015289; Mon, 22 Oct 2012 15:44:36 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9MEiYhW015271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Oct 2012 15:44:35 +0100 From: "Adrian Farrel" To: Date: Mon, 22 Oct 2012 15:44:33 +0100 Message-ID: <0da001cdb063$c0d75200$4285f600$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2wY5bU1kBGg+iDQ9ywvx/GF0lebA== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] One last problem with draft-ietf-mpls-return-path-specified-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:44:38 -0000 Thanks to the authors for a rapid turn-round on my review. We are almost there. But the remaining issue is with the codepoints for the sub-TLVs of the Reply Path TLV. There seems to be some *massive* disconnect! >From the discussion of the 4379-defined "TLVs and sub-TLVs" sub-registry of the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry in old versions of the I-D, I had assumed that you wanted to allow top-level TLVs from the registry to be used as sub-TLVs of the new Reply Path TLV. The reason I thought this is that the document discusses the allocation ranges for the top-level TLVs and says that new sub-TLVs of the Reply Path TLV that apply only to the Reply Path TLV must be allocated out of "safe" ranges - i.e. those ranges that cannot be allocated for top-level TLVs. But when I look at the early allocations done in the registry (and presumably agreed by the authors) I see something completely different. What I see there is that the Reply Path TLV can carry as its own sub-TLVs those sub-TLVs that can be carried as sub-TLVs of the Target FEC Stack top-level TLV. So, I *think* what you are asking for is: 1. A new top-level LSP Ping TLV called "Reply Path TLV" Early allocation has assigned this value 21 2. The ability to carry any sub-TLV of the Target FEC Stack top-level TLV as a sub-TLV of the Reply Path TLV 3. A way to "lock step" the two sub-TLV registries so that new sub-TLVs that can be carried in the Target FEC Stack TLV can also be carried in the Reply Path TLV 4. A way to create and register sub-TLVs that are only to be used in the Reply Path TLV and are not to be carried in the Target FEC Stack TLV All of this has nothing to do with 4379 allocation polices or ranges applied to the top-level TLV registry. If this is what we are trying to do, then: - we can delete the sections of text talking about TLV allocation policies - we can introduce some text instructing IANA to lock-step the registries of sub-TLVs - we can work out a policy that allows values used as sub-TLVs of the Target FEC Stack TLV to be reserved so that they do not conflict with allocations for sub-TLVs of the Reply Path TLV So, step 1: please confirm that I have now (finally) understood what it is you're trying to achieve. Sorry it has taken me so long to understand. Hopefully we can resolve this quickly from here on in. Regards, Adrian From stbryant@cisco.com Mon Oct 22 07:58:22 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5E921F8C1F for ; Mon, 22 Oct 2012 07:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.566 X-Spam-Level: X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjMGYehl+6Zz for ; Mon, 22 Oct 2012 07:58:21 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 59C6E21F8C21 for ; Mon, 22 Oct 2012 07:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2189; q=dns/txt; s=iport; t=1350917901; x=1352127501; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=f2zM1Z7TzAcAPiUoZIgVzS9X1uDIDxz1La/mPFP3qFM=; b=RooDVOIix9b5RaHDEqd0r0yfyg/ob21jQ1OpX7psttk5CtH9Sg+GdKyu 6qOJardUMDr/TeZnVyZE6yQ+JBhWB86YzvuL/tz7zZZcxBAj5NiPOdcUO mTEDjTHk1/Ra9RjpJD9rVEa3B2Uy2BQWDiRywfjFI4/vpJvOrHZ7xFRwI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKxdhVCQ/khR/2dsb2JhbABFhhS6fIEIgiABAQEDAQEBAQ8BAg4VNgsFCQILGAICBSECAg8CCgwwBg0BBQIBAR6HXAYLnBODThCJQ5I6BIEcij+FXYESA5VxhWSIaoEGZYJwgWI X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="145633845" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2012 14:58:19 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9MEwJmH017541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 14:58:19 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9MEwF7N005614; Mon, 22 Oct 2012 15:58:16 +0100 (BST) Message-ID: <50855F07.90708@cisco.com> Date: Mon, 22 Oct 2012 15:58:15 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Sriganesh Kini References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , mpls@ietf.org Subject: Re: [mpls] Comment on draft-fbb-mpls-gach-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:58:22 -0000 On 06/01/2012 00:15, Sriganesh Kini wrote: > Hi Dan and other authors, > > Some comments > 1. Is there an equivalent of 'Promiscous ARP' in GAP ? Yes, this runs on the m/c address, so an application request for the Ethernet address would have this functionality. > 2. The semantics of the 'Message Identifier' should be explained. Now in version -03 > 3. In sec 5.1, instead of "... Protocol message transmission SHALL > operate on a per-.." can we use "... Protocol instance SHOULD operate > on a per-...". I am not sure how this works other than over the channel? > 4. In sec 5.1, instead of per-data-channel it would be better to use > "per Interface (or section)". You could operate this over any LSP or PW including the null LSP, and channel seems to cover that. > 5. If IP is used in G-ACh but IP is not used in the data plane, is GAP > still required ? GAP is an announcement protocol. If you wish to announce something you will need a protocol to do that, even if you carry it over say UDP/IP. We have not considered the UDP/IP case in this draft, but if you have an application for that you may wish to write such a draft. - Stewart > > Thanks > > On Thu, Jan 5, 2012 at 3:24 AM, Loa Andersson wrote: >> Working Group, >> >> this is to start a two week poll to see if there is support to make >> draft-fbb-mpls-gach-adv-01 >> draft-fbb-mpls-tp-ethernet-addressing-01 >> mpls working group drafts. >> >> Pleased send your comments to the mpls working group mailing list >> (mpls@ietf.org). >> >> This poll ends January 18, 2012! >> >> Loa >> for the mpls wg chairs >> >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Mon Oct 22 08:17:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2D821F8A10 for ; Mon, 22 Oct 2012 08:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.566 X-Spam-Level: X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwfUyf7uqwEa for ; Mon, 22 Oct 2012 08:17:26 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 32FB821F87DF for ; Mon, 22 Oct 2012 08:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8555; q=dns/txt; s=iport; t=1350919046; x=1352128646; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=JLhDZ0KGSvs0Nv6hHh/ByrZvbrOjVFp/A/Nqe2mCzMU=; b=FrCPgc1qPAPoyr5TbwWlAPE4K0npsyWWQUM1TyR3R2W/qhMihU12JD9h 4m6/fASt6DzU3jWD6tcsFGJheTPgIHOU4ctHObSNvuDZNvZ+8Rt673ZMT 3E4PIKZfGAY545qmDmdUdjzPp6FqnmKFHaAVCaTvqDknlKxoNrADrX3yO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFABVjhVCQ/khM/2dsb2JhbABFi3O1HoEIgiABAQEDARIBAmMBDAQLEQQBAQEJFggHCQMCAQIBNAkIBg0BBQIBAR6HXAYLnAiDThCcAYtfhm8DlXGFZIhqgQZlgnA X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208,217";a="8996741" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 22 Oct 2012 15:17:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9MFHOHX016968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 15:17:24 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9MFHKrd006812; Mon, 22 Oct 2012 16:17:21 +0100 (BST) Message-ID: <50856380.5000809@cisco.com> Date: Mon, 22 Oct 2012 16:17:20 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Eric Gray References: <4FC58D13.6050803@pi.nu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000300020503070602070604" Cc: "draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org" , "mpls@ietf.org" , MPLS-TP ad hoc team Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:17:27 -0000 This is a multi-part message in MIME format. --------------000300020503070602070604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/06/2012 22:16, Eric Gray wrote: > > My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01 > > In general, this draft is nearly ready for publishing as an RFC. > There are issues the working group and authors should consider. > > Major Issue: > > This is listed here because I am uncertain of the degree to which > this may be a major or minor issue. > > The issue is with the inclusion of MTU as a discoverable parameter > (Section 4). > > One reason for using a protocol other than LLDP to discover the > Ethernet MAC address of an adjacent LSR, is where a physical link > may include one or more intermediate bridges. > > If this is the case, and LLDP is not in use, then the MTU of the > Ethernet end-stations (the peer/adjacent LSRs) may not be useful, > since the intervening bridges could conceivably have a lower MTU. Well, there may be pt-pt Ethernet switches, but there should never be an Ethernet bridge in an MPLS-TP path, since MPLS-TP is defined to be non-merging. MTU may be useful on a PT-PT direct link, but I am not sure what can be done in the other case other than to use the MTU field as an upper bound in an MTU discovery process. We could define an MTU discovery/verification application at a later date if this was needed. > > Minor Issues: > > IANA Considerations - > > Why do the authors create yet another registry for IANA to maintain, > instead of using TLVs (with type numbers taken from the regitry that > was created in the GAP specification - from which this draft already > takes a new application identifier)? That is the design we have proposed - one registry per application. Note the T size is 256, and thus we would need sub-TLVs if we did not do that, and the sub-TLVs would need their own registries so this is awash. > > This appears to set a very nasty precedent: each new application ID > specified from an IANA registry may establish a new registry. Does > IANA have the head-room for this? I think IANA will be fine with this. They will comment at IETF LC if there is a problem, but I don't anticipate any issue. > > NITs: > > IANA Considerations - > > Not sure why section 6.1 is included. There is no action required > of IANA here, AFAICT. Minimally, the authors should explicitly > state that no further action is required from IANA by this section. It provides traceability back to this RFC. It says " IANA has allocated..." so IANA will see they have no actions. - Stewart > > -- > Eric Gray > > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, May 29, 2012 11:00 PM > To: mpls@ietf.org; MPLS-TP ad hoc team > Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts > > Working Group, > > > This is to start a two week working group last call on two drafts: > > - draft-ietf-mpls-gach-adv-02; and > - draft-ietf-mpls-tp-ethernet-addressing-01 > > Please send comments to the mpls working group list. > > The working group last call ends June 15, 2012. > > > Thanks, Loa > > (as MPLS WG co-chair) > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------000300020503070602070604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 08/06/2012 22:16, Eric Gray wrote:

My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01

In general, this draft is nearly ready for publishing as an RFC.
There are issues the working group and authors should consider.

Major Issue:

This is listed here because I am uncertain of the degree to which
this may be a major or minor issue.

The issue is with the inclusion of MTU as a discoverable parameter
(Section 4).

One reason for using a protocol other than LLDP to discover the
Ethernet MAC address of an adjacent LSR, is where a physical link
may include one or more intermediate bridges.

If this is the case, and LLDP is not in use, then the MTU of the
Ethernet end-stations (the peer/adjacent LSRs) may not be useful,
since the intervening bridges could conceivably have a lower MTU.
Well, there may be pt-pt Ethernet switches, but there should
never be an Ethernet bridge in an MPLS-TP path, since
MPLS-TP is defined to be non-merging.

MTU may be useful on a PT-PT direct link, but I am not sure
what can be done in the other case other than to use the MTU
field as an upper bound in an MTU discovery process.

We could define an MTU discovery/verification application
at a later date if this was needed.


Minor Issues:

IANA Considerations -

Why do the authors create yet another registry for IANA to maintain,
instead of using TLVs (with type numbers taken from the regitry that
was created in the GAP specification - from which this draft already
takes a new application identifier)?
That is the design we have proposed - one registry per application.
Note the T size is 256, and thus we would need sub-TLVs if we
did not do that, and the sub-TLVs would need their own registries
so this is awash.

This appears to set a very nasty precedent: each new application ID
specified from an IANA registry may establish a new registry.  Does
IANA have the head-room for this?
I think IANA will be fine with this. They will comment at IETF LC
if there is a problem, but I don't anticipate any issue.

NITs:

IANA Considerations -

Not sure why section 6.1 is included.  There is no action required 
of IANA here, AFAICT.  Minimally, the authors should explicitly
state that no further action is required from IANA by this section.
It provides traceability back to this RFC.

It says " IANA has allocated..." so IANA will see they have no actions.

- Stewart

--
Eric Gray



-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Tuesday, May 29, 2012 11:00 PM
To: mpls@ietf.org; MPLS-TP ad hoc team
Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts

Working Group,


This is to start a two week working group last call on two drafts:

- draft-ietf-mpls-gach-adv-02; and
- draft-ietf-mpls-tp-ethernet-addressing-01

Please send comments to the mpls working group list.

The working group last call ends June 15, 2012.


Thanks, Loa

(as MPLS WG co-chair)




-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------000300020503070602070604-- From internet-drafts@ietf.org Mon Oct 22 08:29:16 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7328421F8200; Mon, 22 Oct 2012 08:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb25Zq9SHPjw; Mon, 22 Oct 2012 08:29:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF9B21F85E2; Mon, 22 Oct 2012 08:29:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022152915.10072.7077.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 08:29:15 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-gach-adv-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:29:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS Generic Associated Channel (G-ACh) Advertisement Pr= otocol Author(s) : Dan Frost Stewart Bryant Matthew Bocci Filename : draft-ietf-mpls-gach-adv-03.txt Pages : 19 Date : 2012-10-22 Abstract: The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-gach-adv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-gach-adv-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-gach-adv-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eric.gray@ericsson.com Mon Oct 22 08:31:21 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8F121F8BD8 for ; Mon, 22 Oct 2012 08:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usIKyGzCPNUH for ; Mon, 22 Oct 2012 08:31:20 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 302B721F8BB0 for ; Mon, 22 Oct 2012 08:31:19 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9MFXw8a001355; Mon, 22 Oct 2012 10:34:01 -0500 Received: from EUSAAHC002.ericsson.se (147.117.188.78) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 22 Oct 2012 11:31:15 -0400 Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 11:31:14 -0400 From: Eric Gray To: "stbryant@cisco.com" Thread-Topic: [mpls] wg last call on gach-adv and ethernet-addressing drafts Thread-Index: AQHNsFbrI+ty5eXLD0C56iRQhrmbLZfFcFvg Date: Mon, 22 Oct 2012 15:31:14 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF6FA87@EUSAAMB107.ericsson.se> References: <4FC58D13.6050803@pi.nu> <5085463F.6040506@cisco.com> In-Reply-To: <5085463F.6040506@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-gach-adv@tools.ietf.org" Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:31:21 -0000 Stewart, With the exception of one (probable) typo in your response (not your actua= l proposed text) - where you say "adverting" and probably mean "advertising" - I am fine wit= h your proposals. I had missed the text that describes the scoping of TLV types by applicati= on. I have one follow on question - which may or may not require clarification= in the existing text. In the text that describes the scoping of TLV object types, there are possi= bly two areas in which this text may require further clarification: 1) Should the text suggest the creation of a registry for an application th= at does not immediately require TLV types, or should this be left to later work that adds thes= e types? I suspect that the best approach would be to say that a TLV type registry needs only to b= e created if the TLV types are explicitly defined in the document - but you may feel that this is= "micro-management." 2) Is there any value in suggesting a specific template - based on this doc= ument (for the sake of=20 uniformity in IANA management of TLV type spaces for those application= s requiring application- specific TLVs). Again, this might be a form of micromanagement. Thanks for addressing my comments! -- Eric -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Monday, October 22, 2012 9:13 AM To: Eric Gray Cc: Loa Andersson; draft-ietf-mpls-gach-adv@tools.ietf.org; mpls@ietf.org; = MPLS-TP ad hoc team Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts Importance: High Eric, Thank you for your review. To move the draft along I have addressed the poi= nts you make as shown in line. If my co-authors wish to amend this text, we will do so during IETF LC and = copy you on these amendments. On 08/06/2012 21:28, Eric Gray wrote: > > My Last call review comments on draft-ietf-mpls-gach-adv-02: > > In general, this is a very well written draft that is nearly ready to=20 > publish. There is one major issue that needs to be addressed. > > Major Issue: > > There is an important point that does not appear to have been made=20 > sufficiently clear in the IANA Considerations section. > > For the TLV types, I assume that the TLV type numbers (section > 9.4) are intended to be allocated within the context of an application=20 > ID (allocated according to section 9.3). > > This is very much not clear. In fact, reading section 9.4 as it now=20 > stands, it looks as if there is a single context for TLV IDs, that=20 > there are a maximum number of TLV IDs available of 255, and that five=20 > of these are used by the application in this draft. > > This seems odd, given that the number space for application IDs is=20 > from 0x000 to 0xFFFF. It would seem that we anticipate we will have a=20 > lot of applications for this protocol, but not too many will actually=20 > need to say anything. > > Hence my assumption about the intent of the TLV type number space. > > Please clarify what you are really expecting from this TLV Type=20 > Registry. In section 3 it says: The Type field identifies the TLV Object and is scoped to a specific applic= ation; each application creates an IANA registry to track its Type values. and in Section 4 it says: The GAP supports several TLV objects related to its own operation via the A= pplication ID 0x0000. I have clarified that 9.4 refers to the GAP itself by amending the registry= title to be "G-ACh Advertisement Protocol: GAP TLV Objects (Application ID 0)" > > Minor Issue: > > In the second pargraph on page 4, I believe one can also use LLDP to=20 > discover the MAC address of an adjacent Ethernet peer. > The authors mention this proposed GAP protocol standard can be used to=20 > exchange information similar to the use of LLDP, and then follows this=20 > immediately with a special case to find out an adjacent peer's MAC=20 > address in the case where IP isn't supported - using GAP. > > Have the authors given any thought to the possibility that the fact=20 > that IP is not supported may be attributable to the fact that Ethernet=20 > _is_ supported for L2 peer-to-peer exchanges, including LLDP? IMO,=20 > this makes the "special case" not so much so. > > I think - given that there are a few things we know about this case=20 > (e.g. - both Ethernet and MPLS are presumed to apply), it would be=20 > useful to be clear about when it would be the case that: > > 1) IP is not present, > 2) Ethernet is present, > 3) Knowing the MAC address of an adjacent Ethernet entity is > needed, and > 4) LLDP is not already used. The GAP protocol can be used over a datalink other than Ethernet (see secti= on 1.1), including over an MPLS-TP segment that is itself running over an M= PLS-TP segment. Whilst one use is to learn the MAC address, it has a number of purposes inc= luding announcing the configuration of the adverting node. Using a single p= rotocol to announce the MAC address along with other configuration informat= ion seems to be a simplification compared to implementing LLDP just for the= MAC addresses. The paragraph now says: In networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921] that do= not also support IP, the normal protocols used to determine the Ethernet = address of an adjacent MPLS node, such as the Address Resolution Protocol [= RFC0826] and IP version 6 Neighbor Discovery [RFC4861] are not available. T= he G-ACh advertisement protocol can be used to discover the Ethernet MAC ad= dresses of MPLS-TP nodes lacking IP capability [I-D.ietf-mpls-tp-ethernet-a= ddressing]. Where it is anticipated that the sole purpose of the GAP will b= e to provide Ethernet MAC address learning, the use of LLDP SHOULD be consi= dered. > > NIT: > > I find the phrase "a primary purpose" somewhat jarring in the=20 > Introduction. Is there more than one "primary" purpose? > Perhaps "One key" as opposed to "A primary"? s/A primary purpose/ An important use/ - Stewart From stbryant@cisco.com Mon Oct 22 08:43:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A4E21F8C3C for ; Mon, 22 Oct 2012 08:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.566 X-Spam-Level: X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNIN7COgU1jM for ; Mon, 22 Oct 2012 08:43:50 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id C887C21F8C32 for ; Mon, 22 Oct 2012 08:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9408; q=dns/txt; s=iport; t=1350920630; x=1352130230; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=PRW76/wzKVW4n7cBjneWqwsddgsSyrc2z34PPJ5kuO4=; b=Pe+/DRhfKLWTriiDSf3TjRjsNU68PjRtY3xNLH5Co7pxoSw9fAxTlL3s /wZmVejc5XbbT+Z5D6ou0Po1D+UBA9pA3tNbQu5RQpUvwb9oHhC5irhOD 0/sXQXeCySBLIce6nnQffoMyjlMhodw1kGWVY8GOa+0YSWVazlHadwMQJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FAANphVCQ/khM/2dsb2JhbABFi3O1HoEIgiABAQEDAQEBAQ8BAlIHBAYBBQkCCxEDAQIBCRYPCQMCAQIBCQwBJwgGDQEFAgEBHodcBgucB4NOEJwCBItbhm8Dk0SCLYVkiGqBBmWCcIFiFw X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208,217";a="9007684" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 22 Oct 2012 15:43:47 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9MFhkOa023075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 15:43:46 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9MFhfGH008754; Mon, 22 Oct 2012 16:43:43 +0100 (BST) Message-ID: <508569AD.1060903@cisco.com> Date: Mon, 22 Oct 2012 16:43:41 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Lizhong Jin References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070209050008070403050006" Cc: mpls@ietf.org, ahmpls-tp@lists.itu.int Subject: Re: [mpls] wg last call on ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:43:51 -0000 This is a multi-part message in MIME format. --------------070209050008070403050006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/06/2012 09:55, Lizhong Jin wrote: > > Hi authors, > I review draft-ietf-mpls-tp-ethernet-addressing, and have two comments: > 1. When advertising the MAC address in "Ethernet Interface Parameters" > ADB, I think Interface Identifier TLV in "G-ACh Advertisement > Protocol" ADB should also be carried. Is there any required > relationship of "Lifetime" in the two ADBs, should be same? It is not required to carry the identifier, since that identifier is not required by MPLS_TP. The protocol requires that you refresh the announcement, if you are going to carry the SA and the MAC in the same message it would make sense to give them the same lifetime, but the rule (clearly stated in the draft) is that you must refresh before information is expired, so as long as you refresh on the lower of the two you are OK, and it is not harmful to have them set differently if that makes sense in the particular application. > 2. For the "Ethernet Interface Parameters" application, is it allowed > to apply GAP Request, Flush or Suppress message specified in > [I-D.ietf-mpls-gach-adv]? E.g, to use GAP Request to request MAC address. Yes if it makes sense in your application. I can see that you might for example suppress the MAC address refresh and rely on your peer to over-ride the request if the address changed. I am not sure why this needs clarification since the Ethernet draft inherits the rules of the GAP protocol. - Stewart > > Hope to be more clear in Section 4. > > Thanks > Lizhong > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 30 May 2012 04:59:31 +0200 > > From: Loa Andersson > > To: "mpls@ietf.org" , MPLS-TP ad hoc team > > > > Subject: [mpls] wg last call on gach-adv and ethernet-addressing > > drafts > > Message-ID: <4FC58D13.6050803@pi.nu> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > Working Group, > > > > > > This is to start a two week working group last call on two drafts: > > > > - draft-ietf-mpls-gach-adv-02; and > > - draft-ietf-mpls-tp-ethernet-addressing-01 > > > > Please send comments to the mpls working group list. > > > > The working group last call ends June 15, 2012. > > > > > > Thanks, Loa > > > > (as MPLS WG co-chair) > > > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------070209050008070403050006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/06/2012 09:55, Lizhong Jin wrote:

Hi authors,
I review draft-ietf-mpls-tp-ethernet-addressing, and have two comments:
1. When advertising the MAC address in "Ethernet Interface Parameters" ADB, I think Interface Identifier TLV in "G-ACh Advertisement Protocol" ADB should also be carried. Is there any required relationship of "Lifetime" in the two ADBs, should be same?
It is not required to carry the identifier, since that identifier is not required by MPLS_TP.

The protocol requires that you refresh the announcement, if you are going to carry the SA and the MAC in the same message it would make sense to give them the same lifetime, but the rule (clearly stated in the draft) is that you must refresh before information is expired, so as long as you refresh on the lower of the two you are OK, and it is not harmful to have them set differently if that makes sense in the particular application.

2. For the "Ethernet Interface Parameters" application, is it allowed to apply GAP Request, Flush or Suppress message specified in [I-D.ietf-mpls-gach-adv]? E.g, to use GAP Request to request MAC address.
Yes if it makes sense in your application. I can see that you might for example suppress the MAC address refresh and rely on your peer to over-ride the request if the address changed.

I am not sure why this needs clarification since the Ethernet draft inherits the rules of the GAP protocol.

- Stewart



Hope to be more clear in Section 4.

Thanks
Lizhong

 
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 30 May 2012 04:59:31 +0200
> From: Loa Andersson <loa@pi.nu>
> To: "mpls@ietf.org" <mpls@ietf.org>,    MPLS-TP ad hoc team
>    <ahmpls-tp@lists.itu.int>
> Subject: [mpls] wg last call  on gach-adv and ethernet-addressing
>    drafts
> Message-ID: <4FC58D13.6050803@pi.nu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Working Group,
>
>
> This is to start a two week working group last call on two drafts:
>
> - draft-ietf-mpls-gach-adv-02; and
> - draft-ietf-mpls-tp-ethernet-addressing-01
>
> Please send comments to the mpls working group list.
>
> The working group last call ends June 15, 2012.
>
>
> Thanks, Loa
>
> (as MPLS WG co-chair)
>
> --
>
>
> Loa Andersson                         email: loa.andersson@ericsson.com
> Sr Strategy and Standards Manager            loa@pi.nu
> Ericsson Inc                          phone: +46 10 717 52 13
>                                               +46 767 72 92 13
>
> 

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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------070209050008070403050006-- From eric.gray@ericsson.com Mon Oct 22 08:45:57 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A14F21F8617 for ; Mon, 22 Oct 2012 08:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW7BC0vjq26Z for ; Mon, 22 Oct 2012 08:45:56 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1770121F8569 for ; Mon, 22 Oct 2012 08:45:56 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9MFma5P005571; Mon, 22 Oct 2012 10:48:38 -0500 Received: from EUSAAHC002.ericsson.se (147.117.188.78) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 22 Oct 2012 11:45:50 -0400 Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 11:45:49 -0400 From: Eric Gray To: "stbryant@cisco.com" Thread-Topic: [mpls] wg last call on gach-adv and ethernet-addressing drafts Thread-Index: AQHNsGhUI+ty5eXLD0C56iRQhrmbLZfFdXrQ Date: Mon, 22 Oct 2012 15:45:48 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF6FABF@EUSAAMB107.ericsson.se> References: <4FC58D13.6050803@pi.nu> <50856380.5000809@cisco.com> In-Reply-To: <50856380.5000809@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF6FABFEUSAAMB107ericssons_" MIME-Version: 1.0 Cc: "draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org" , "mpls@ietf.org" , MPLS-TP ad hoc team Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:45:57 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF6FABFEUSAAMB107ericssons_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, There is an odd-ball "Ethernet Bridge" that may appear in s= ome circumstances where an operator may also chose to use MPLS-TP. That "odd-ball" bridge is calle= d a Two-Port MAC Relay and corresponds close to what the MEF defines as a "NID" (network int= erface device). Where an operator may choose to use both is (possibly?) at = the E-NNI between two separately maintained service domains that are both owned by the same opera= tor. If this were the case, it seems likely that the NID may re-= encapsulate the frames it forwards in one direction or the other, or may simply use a different techn= ology that has a subtly different native MTU (e.g. - as an adaptation, between different net= work types). One thing people tend to forget is that bridges are truly m= eant to be transparent. -- Eric From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Monday, October 22, 2012 11:17 AM To: Eric Gray Cc: Loa Andersson; draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org; mp= ls@ietf.org; MPLS-TP ad hoc team Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts Importance: High On 08/06/2012 22:16, Eric Gray wrote: My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01 In general, this draft is nearly ready for publishing as an RFC. There are issues the working group and authors should consider. Major Issue: This is listed here because I am uncertain of the degree to which this may be a major or minor issue. The issue is with the inclusion of MTU as a discoverable parameter (Section 4). One reason for using a protocol other than LLDP to discover the Ethernet MAC address of an adjacent LSR, is where a physical link may include one or more intermediate bridges. If this is the case, and LLDP is not in use, then the MTU of the Ethernet end-stations (the peer/adjacent LSRs) may not be useful, since the intervening bridges could conceivably have a lower MTU. Well, there may be pt-pt Ethernet switches, but there should never be an Ethernet bridge in an MPLS-TP path, since MPLS-TP is defined to be non-merging. MTU may be useful on a PT-PT direct link, but I am not sure what can be done in the other case other than to use the MTU field as an upper bound in an MTU discovery process. We could define an MTU discovery/verification application at a later date if this was needed. Minor Issues: IANA Considerations - Why do the authors create yet another registry for IANA to maintain, instead of using TLVs (with type numbers taken from the regitry that was created in the GAP specification - from which this draft already takes a new application identifier)? That is the design we have proposed - one registry per application. Note the T size is 256, and thus we would need sub-TLVs if we did not do that, and the sub-TLVs would need their own registries so this is awash. This appears to set a very nasty precedent: each new application ID specified from an IANA registry may establish a new registry. Does IANA have the head-room for this? I think IANA will be fine with this. They will comment at IETF LC if there is a problem, but I don't anticipate any issue. NITs: IANA Considerations - Not sure why section 6.1 is included. There is no action required of IANA here, AFAICT. Minimally, the authors should explicitly state that no further action is required from IANA by this section. It provides traceability back to this RFC. It says " IANA has allocated..." so IANA will see they have no actions. - Stewart -- Eric Gray -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, May 29, 2012 11:00 PM To: mpls@ietf.org; MPLS-TP ad hoc team Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts Working Group, This is to start a two week working group last call on two drafts: - draft-ietf-mpls-gach-adv-02; and - draft-ietf-mpls-tp-ethernet-addressing-01 Please send comments to the mpls working group list. The working group last call ends June 15, 2012. Thanks, Loa (as MPLS WG co-chair) -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_48E1A67CB9CA044EADFEAB87D814BFF6FABFEUSAAMB107ericssons_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart,

 <= /p>

    &= nbsp;           There is = an odd-ball "Ethernet Bridge" that may appear in some circumstanc= es where

an operator may also chos= e to use MPLS-TP.  That "odd-ball" bridge is called a Two-Po= rt MAC

Relay and corresponds clo= se to what the MEF defines as a "NID" (network interface device).=

 <= /p>

    &= nbsp;           Where an = operator may choose to use both is (possibly?) at the E-NNI between two

separately maintained ser= vice domains that are both owned by the same operator.

 <= /p>

    &= nbsp;           If this w= ere the case, it seems likely that the NID may re-encapsulate the frames it

forwards in one direction= or the other, or may simply use a different technology that has a

subtly different native M= TU (e.g. - as an adaptation, between different network types).

 <= /p>

    &= nbsp;           One thing= people tend to forget is that bridges are truly meant to be transparent.

 <= /p>

--

Eric

 <= /p>

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, October 22, 2012 11:17 AM
To: Eric Gray
Cc: Loa Andersson; draft-ietf-mpls-tp-ethernet-addressing@tools.iet.= org; mpls@ietf.org; MPLS-TP ad hoc team
Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing= drafts
Importance: High

 

On 08/06/2012 22:16, Eric Gray wrote:

 
 
My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01
 
In general, this draft is nearly ready for publishing as an RFC.<=
/o:p>
There are issues the working group and authors should consider.
 
Major Issue:
 
This is listed here because I am uncertain of the degree to which=

this may be a major or minor issue.
 
The issue is with the inclusion of MTU as a discoverable parameter
(Section 4).
 
One reason for using a protocol other than LLDP to discover the
Ethernet MAC address of an adjacent LSR, is where a physical link=

may include one or more intermediate bridges.
 
If this is the case, and LLDP is not in use, then the MTU of the<=
/o:p>
Ethernet end-stations (the peer/adjacent LSRs) may not be useful,=

since the intervening bridges could conceivably have a lower MTU.=

Well, there may be pt-pt Ethernet switches, but ther= e should
never be an Ethernet bridge in an MPLS-TP path, since
MPLS-TP is defined to be non-merging.

MTU may be useful on a PT-PT direct link, but I am not sure
what can be done in the other case other than to use the MTU
field as an upper bound in an MTU discovery process.

We could define an MTU discovery/verification application
at a later date if this was needed.


 
 
Minor Issues:
 
IANA Considerations -
 
Why do the authors create yet another registry for IANA to maintain,
instead of using TLVs (with type numbers taken from the regitry that
was created in the GAP specification - from which this draft already
takes a new application identifier)?

That is the design we have proposed - one registry p= er application.
Note the T size is 256, and thus we would need sub-TLVs if we
did not do that, and the sub-TLVs would need their own registries
so this is awash.

 
 
This appears to set a very nasty precedent: each new application ID
specified from an IANA registry may establish a new registry.  Do=
es
IANA have the head-room for this?

I think IANA will be fine with this. They will comme= nt at IETF LC
if there is a problem, but I don't anticipate any issue.

 
 
NITs:
 
IANA Considerations -
 
Not sure why section 6.1 is included.  There is no action require=
d 
of IANA here, AFAICT.  Minimally, the authors should explicitly
state that no further action is required from IANA by this section.

It provides traceability back to this RFC.

It says " IANA has allocated..." so IANA will see they have no ac= tions.

- Stewart

 
 
--
Eric Gray
 
 
 
-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Tuesday, May 29, 2012 11:00 PM
To: mpls@ietf.org; MPLS-TP ad hoc=
 team
Subject: [mpls] wg last call on gach-adv and ethernet-addressing draft=
s
 
Working Group,
 
 
This is to start a two week working group last call on two drafts:
 
- draft-ietf-mpls-gach-adv-02; and
- draft-ietf-mpls-tp-ethernet-addressing-01
 
Please send comments to the mpls working group list.
 
The working group last call ends June 15, 2012.
 
 
Thanks, Loa
 
(as MPLS WG co-chair)
 




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
--_000_48E1A67CB9CA044EADFEAB87D814BFF6FABFEUSAAMB107ericssons_-- From internet-drafts@ietf.org Mon Oct 22 08:52:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68AD21F8C5A; Mon, 22 Oct 2012 08:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85RyUQe27iVe; Mon, 22 Oct 2012 08:52:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF8221F8C54; Mon, 22 Oct 2012 08:52:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022155248.6122.57629.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 08:52:48 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:52:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : LDP Extensions for Multi Topology Routing Author(s) : Quintin Zhao Luyuan Fang Chao Zhou Lianyuan Li Ning So Kamran Raza Filename : draft-ietf-mpls-ldp-multi-topology-05.txt Pages : 21 Date : 2012-10-22 Abstract: Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGP protocols. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document updates RFC4379. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-multi-topology-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eric.gray@ericsson.com Mon Oct 22 09:09:00 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C077321F84AB for ; Mon, 22 Oct 2012 09:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPlU18mOplNI for ; Mon, 22 Oct 2012 09:08:58 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DBDDB21F89E9 for ; Mon, 22 Oct 2012 09:08:57 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9MGBTLn012138; Mon, 22 Oct 2012 11:11:40 -0500 Received: from EUSAAHC008.ericsson.se (147.117.188.96) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 22 Oct 2012 12:08:50 -0400 Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 12:08:50 -0400 From: Eric Gray To: "stbryant@cisco.com" Thread-Topic: [mpls] wg last call on gach-adv and ethernet-addressing drafts Thread-Index: AQHNsGhUI+ty5eXLD0C56iRQhrmbLZfFe8lA Date: Mon, 22 Oct 2012 16:08:49 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF6FB40@EUSAAMB107.ericsson.se> References: <4FC58D13.6050803@pi.nu> <50856380.5000809@cisco.com> In-Reply-To: <50856380.5000809@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF6FB40EUSAAMB107ericssons_" MIME-Version: 1.0 Cc: "draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org" , "mpls@ietf.org" , MPLS-TP ad hoc team Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:09:01 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF6FB40EUSAAMB107ericssons_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, On the IANA allocation, this is a subtle issue, but is unli= kely to be a problem. As you know, IANA is occasionally asked to pre-allocate cod= e points. This process - as I understand it - is different from an actual allocation in th= at (AFAIK) the allocation is not actually made in the registry but is reserved in IANA= 's notes somewhere. Should it be made clear which case this allocation is? I s= uspect that IANA can figure that out, though, so it is not a big deal... -- Eric From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Monday, October 22, 2012 11:17 AM To: Eric Gray Cc: Loa Andersson; draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org; mp= ls@ietf.org; MPLS-TP ad hoc team Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts Importance: High On 08/06/2012 22:16, Eric Gray wrote: My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01 In general, this draft is nearly ready for publishing as an RFC. There are issues the working group and authors should consider. Major Issue: This is listed here because I am uncertain of the degree to which this may be a major or minor issue. The issue is with the inclusion of MTU as a discoverable parameter (Section 4). One reason for using a protocol other than LLDP to discover the Ethernet MAC address of an adjacent LSR, is where a physical link may include one or more intermediate bridges. If this is the case, and LLDP is not in use, then the MTU of the Ethernet end-stations (the peer/adjacent LSRs) may not be useful, since the intervening bridges could conceivably have a lower MTU. Well, there may be pt-pt Ethernet switches, but there should never be an Ethernet bridge in an MPLS-TP path, since MPLS-TP is defined to be non-merging. MTU may be useful on a PT-PT direct link, but I am not sure what can be done in the other case other than to use the MTU field as an upper bound in an MTU discovery process. We could define an MTU discovery/verification application at a later date if this was needed. Minor Issues: IANA Considerations - Why do the authors create yet another registry for IANA to maintain, instead of using TLVs (with type numbers taken from the regitry that was created in the GAP specification - from which this draft already takes a new application identifier)? That is the design we have proposed - one registry per application. Note the T size is 256, and thus we would need sub-TLVs if we did not do that, and the sub-TLVs would need their own registries so this is awash. This appears to set a very nasty precedent: each new application ID specified from an IANA registry may establish a new registry. Does IANA have the head-room for this? I think IANA will be fine with this. They will comment at IETF LC if there is a problem, but I don't anticipate any issue. NITs: IANA Considerations - Not sure why section 6.1 is included. There is no action required of IANA here, AFAICT. Minimally, the authors should explicitly state that no further action is required from IANA by this section. It provides traceability back to this RFC. It says " IANA has allocated..." so IANA will see they have no actions. - Stewart -- Eric Gray -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, May 29, 2012 11:00 PM To: mpls@ietf.org; MPLS-TP ad hoc team Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts Working Group, This is to start a two week working group last call on two drafts: - draft-ietf-mpls-gach-adv-02; and - draft-ietf-mpls-tp-ethernet-addressing-01 Please send comments to the mpls working group list. The working group last call ends June 15, 2012. Thanks, Loa (as MPLS WG co-chair) -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_48E1A67CB9CA044EADFEAB87D814BFF6FB40EUSAAMB107ericssons_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart,

 <= /p>

    &= nbsp;           On the IA= NA allocation, this is a subtle issue, but is unlikely to be a problem.

 <= /p>

    &= nbsp;           As you kn= ow, IANA is occasionally asked to pre-allocate code points.  This

process – as I unde= rstand it – is different from an actual allocation in that (AFAIK)

the allocation is not act= ually made in the registry but is reserved in IANA's notes

somewhere.

 <= /p>

    &= nbsp;           Should it= be made clear which case this allocation is?  I suspect that IANA

can figure that out, thou= gh, so it is not a big deal…

 <= /p>

--

Eric

 <= /p>

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, October 22, 2012 11:17 AM
To: Eric Gray
Cc: Loa Andersson; draft-ietf-mpls-tp-ethernet-addressing@tools.iet.= org; mpls@ietf.org; MPLS-TP ad hoc team
Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing= drafts
Importance: High

 

On 08/06/2012 22:16, Eric Gray wrote:

 
 
My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01
 
In general, this draft is nearly ready for publishing as an RFC.<=
/o:p>
There are issues the working group and authors should consider.
 
Major Issue:
 
This is listed here because I am uncertain of the degree to which=

this may be a major or minor issue.
 
The issue is with the inclusion of MTU as a discoverable parameter
(Section 4).
 
One reason for using a protocol other than LLDP to discover the
Ethernet MAC address of an adjacent LSR, is where a physical link=

may include one or more intermediate bridges.
 
If this is the case, and LLDP is not in use, then the MTU of the<=
/o:p>
Ethernet end-stations (the peer/adjacent LSRs) may not be useful,=

since the intervening bridges could conceivably have a lower MTU.=

Well, there may be pt-pt Ethernet switches, but ther= e should
never be an Ethernet bridge in an MPLS-TP path, since
MPLS-TP is defined to be non-merging.

MTU may be useful on a PT-PT direct link, but I am not sure
what can be done in the other case other than to use the MTU
field as an upper bound in an MTU discovery process.

We could define an MTU discovery/verification application
at a later date if this was needed.


 
 
Minor Issues:
 
IANA Considerations -
 
Why do the authors create yet another registry for IANA to maintain,
instead of using TLVs (with type numbers taken from the regitry that
was created in the GAP specification - from which this draft already
takes a new application identifier)?

That is the design we have proposed - one registry p= er application.
Note the T size is 256, and thus we would need sub-TLVs if we
did not do that, and the sub-TLVs would need their own registries
so this is awash.

 
 
This appears to set a very nasty precedent: each new application ID
specified from an IANA registry may establish a new registry.  Do=
es
IANA have the head-room for this?

I think IANA will be fine with this. They will comme= nt at IETF LC
if there is a problem, but I don't anticipate any issue.

 
 
NITs:
 
IANA Considerations -
 
Not sure why section 6.1 is included.  There is no action require=
d 
of IANA here, AFAICT.  Minimally, the authors should explicitly
state that no further action is required from IANA by this section.

It provides traceability back to this RFC.

It says " IANA has allocated..." so IANA will see they have no ac= tions.

- Stewart

 
 
--
Eric Gray
 
 
 
-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Tuesday, May 29, 2012 11:00 PM
To: mpls@ietf.org; MPLS-TP ad hoc=
 team
Subject: [mpls] wg last call on gach-adv and ethernet-addressing draft=
s
 
Working Group,
 
 
This is to start a two week working group last call on two drafts:
 
- draft-ietf-mpls-gach-adv-02; and
- draft-ietf-mpls-tp-ethernet-addressing-01
 
Please send comments to the mpls working group list.
 
The working group last call ends June 15, 2012.
 
 
Thanks, Loa
 
(as MPLS WG co-chair)
 




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
--_000_48E1A67CB9CA044EADFEAB87D814BFF6FB40EUSAAMB107ericssons_-- From internet-drafts@ietf.org Mon Oct 22 09:23:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9176721F8B9F; Mon, 22 Oct 2012 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kcz-+gYDJfI; Mon, 22 Oct 2012 09:23:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1206F21F8B6C; Mon, 22 Oct 2012 09:23:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022162331.13823.71965.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 09:23:31 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-mip-mep-map-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:23:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Handling MPLS-TP OAM Packets Targeted at Internal MIPs Author(s) : Adrian Farrel Hideki Endo Rolf Winter Yoshinori Koike Manuel Paul Filename : draft-ietf-mpls-tp-mip-mep-map-03.txt Pages : 15 Date : 2012-10-22 Abstract: The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document describes a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces, forwarded correctly through the forwarding engine, and handled efficiently in node implementations where there is no distinction between the incoming and outgoing MIP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-mip-mep-map-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-mip-mep-map-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Rolf.Winter@neclab.eu Mon Oct 22 09:36:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DBD21F8B43 for ; Mon, 22 Oct 2012 09:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.661, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZYHgSYp33cq for ; Mon, 22 Oct 2012 09:36:12 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 86E8521F8ACF for ; Mon, 22 Oct 2012 09:36:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9E61D101E88 for ; Mon, 22 Oct 2012 18:36:11 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwYDzkh1Sbst for ; Mon, 22 Oct 2012 18:36:11 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 83C23101E76 for ; Mon, 22 Oct 2012 18:36:06 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 22 Oct 2012 18:36:06 +0200 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: I-D Action: draft-ietf-mpls-tp-mip-mep-map-03.txt Thread-Index: AQHNsHHFgeBBF8e1wkijCX7tg+TBaJfFhS0Q Date: Mon, 22 Oct 2012 16:35:49 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D554F778B@DAPHNIS.office.hd> References: <20121022162331.13823.71965.idtracker@ietfa.amsl.com> In-Reply-To: <20121022162331.13823.71965.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-mip-mep-map-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:36:13 -0000 WG, the authors believe all received comments have been incorporated in this ne= w version. Please review. BTW, if you review the document and don't find an= ything wrong with it, then we'd also like to hear from you. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Montag, 22. Oktober 2012 18:24 > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: I-D Action: draft-ietf-mpls-tp-mip-mep-map-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. >=20 > Title : Handling MPLS-TP OAM Packets Targeted at > Internal MIPs > Author(s) : Adrian Farrel > Hideki Endo > Rolf Winter > Yoshinori Koike > Manuel Paul > Filename : draft-ietf-mpls-tp-mip-mep-map-03.txt > Pages : 15 > Date : 2012-10-22 >=20 > Abstract: > The Framework for Operations, Administration and Maintenance (OAM) > within the MPLS Transport Profile (MPLS-TP) describes how > Maintenance > Entity Group Intermediate Points (MIPs) may be situated within > network nodes at the incoming and outgoing interfaces. >=20 > This document describes a way of forming OAM messages so that they > can be targeted at MIPs on incoming or MIPs on outgoing interfaces, > forwarded correctly through the forwarding engine, and handled > efficiently in node implementations where there is no distinction > between the incoming and outgoing MIP. >=20 > This document is a product of a joint Internet Engineering Task > Force > (IETF) / International Telecommunication Union Telecommunication > Standardization Sector (ITU-T) effort to include an MPLS Transport > Profile within the IETF MPLS and PWE3 architectures to support the > capabilities and functionalities of a packet transport network. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-tp-mip-mep-map-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-mip-mep-map-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stbryant@cisco.com Mon Oct 22 10:02:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C9F21F8427 for ; Mon, 22 Oct 2012 10:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.568 X-Spam-Level: X-Spam-Status: No, score=-110.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbG0aiJhp6wk for ; Mon, 22 Oct 2012 10:02:45 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1675421F845B for ; Mon, 22 Oct 2012 10:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4984; q=dns/txt; s=iport; t=1350925364; x=1352134964; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Zbd9dRfoRGnSTTnj/kXeNNqdRpRx3cFb1tUXs4IiCWI=; b=ZpcUwNyEDg1kQguFM9kkP3p8nw7IO3FLeapHecoyfl0dMwKQT9ovhG3H 7Wct8cpiX6lPr5gcDw/hHMknEl4hqZczOl8hG7bEg5SUCxC+JHmHxvzAA 5oRTx1xozndz8GUVjYSD2NFTp5ypr0gqk36m3t0dIlMLTNpf1r2OX5dwb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAx7hVCQ/khN/2dsb2JhbABFwRaBCIIgAQEBBBIBAh0BBUABDAQLEQQBAQEJFggHCQMCAQIBNAkIBg0BBQIBAR6HYgucCYNOEJwXi1+GbwOVcYVkiGqBBmWCcA X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="8999471" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 22 Oct 2012 17:02:42 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9MH2f2L016354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 17:02:42 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9MH2ci6014252; Mon, 22 Oct 2012 18:02:39 +0100 (BST) Message-ID: <50857C2E.9030005@cisco.com> Date: Mon, 22 Oct 2012 18:02:38 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Eric Gray References: <4FC58D13.6050803@pi.nu> <50856380.5000809@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF6FB40@EUSAAMB107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF6FB40@EUSAAMB107.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org" , "mpls@ietf.org" , MPLS-TP ad hoc team Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:02:52 -0000 Hi Eric Early allocation is a well known process and IANA annotate the registry entry accordingly. In particular they set a death date for the allocation and this is visible in the registry. Stewart On 22/10/2012 17:08, Eric Gray wrote: > > Stewart, > > On the IANA allocation, this is a subtle issue, but is unlikely to be > a problem. > > As you know, IANA is occasionally asked to pre-allocate code points. This > > process – as I understand it – is different from an actual allocation > in that (AFAIK) > > the allocation is not actually made in the registry but is reserved in > IANA's notes > > somewhere. > > Should it be made clear which case this allocation is? I suspect that IANA > > can figure that out, though, so it is not a big deal… > > -- > > Eric > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Monday, October 22, 2012 11:17 AM > *To:* Eric Gray > *Cc:* Loa Andersson; > draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org; mpls@ietf.org; > MPLS-TP ad hoc team > *Subject:* Re: [mpls] wg last call on gach-adv and ethernet-addressing > drafts > *Importance:* High > > On 08/06/2012 22:16, Eric Gray wrote: > > > > > > My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01 > > > > In general, this draft is nearly ready for publishing as an RFC. > > There are issues the working group and authors should consider. > > > > Major Issue: > > > > This is listed here because I am uncertain of the degree to which > > this may be a major or minor issue. > > > > The issue is with the inclusion of MTU as a discoverable parameter > > (Section 4). > > > > One reason for using a protocol other than LLDP to discover the > > Ethernet MAC address of an adjacent LSR, is where a physical link > > may include one or more intermediate bridges. > > > > If this is the case, and LLDP is not in use, then the MTU of the > > Ethernet end-stations (the peer/adjacent LSRs) may not be useful, > > since the intervening bridges could conceivably have a lower MTU. > > Well, there may be pt-pt Ethernet switches, but there should > never be an Ethernet bridge in an MPLS-TP path, since > MPLS-TP is defined to be non-merging. > > MTU may be useful on a PT-PT direct link, but I am not sure > what can be done in the other case other than to use the MTU > field as an upper bound in an MTU discovery process. > > We could define an MTU discovery/verification application > at a later date if this was needed. > > > > > Minor Issues: > > IANA Considerations - > > Why do the authors create yet another registry for IANA to maintain, > instead of using TLVs (with type numbers taken from the regitry that > was created in the GAP specification - from which this draft already > takes a new application identifier)? > > That is the design we have proposed - one registry per application. > Note the T size is 256, and thus we would need sub-TLVs if we > did not do that, and the sub-TLVs would need their own registries > so this is awash. > > > > This appears to set a very nasty precedent: each new application ID > specified from an IANA registry may establish a new registry. Does > IANA have the head-room for this? > > I think IANA will be fine with this. They will comment at IETF LC > if there is a problem, but I don't anticipate any issue. > > > > NITs: > > IANA Considerations - > > Not sure why section 6.1 is included. There is no action required > of IANA here, AFAICT. Minimally, the authors should explicitly > state that no further action is required from IANA by this section. > > It provides traceability back to this RFC. > > It says " IANA has allocated..." so IANA will see they have no actions. > > - Stewart > > > > -- > Eric Gray > > > > -----Original Message----- > From:mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, May 29, 2012 11:00 PM > To:mpls@ietf.org ; MPLS-TP ad hoc team > Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts > > Working Group, > > > This is to start a two week working group last call on two drafts: > > - draft-ietf-mpls-gach-adv-02; and > - draft-ietf-mpls-tp-ethernet-addressing-01 > > Please send comments to the mpls working group list. > > The working group last call ends June 15, 2012. > > > Thanks, Loa > > (as MPLS WG co-chair) > > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Mon Oct 22 10:11:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A411611E80E5 for ; Mon, 22 Oct 2012 10:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.568 X-Spam-Level: X-Spam-Status: No, score=-110.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwlQmeXM3uwL for ; Mon, 22 Oct 2012 10:11:25 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 885A611E80EC for ; Mon, 22 Oct 2012 10:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22481; q=dns/txt; s=iport; t=1350925883; x=1352135483; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=0BHlU0Fb/MSsBOUY0XmV/TH1Ojn2nYFLno7wOluarBU=; b=XQgGrQzpVCdUBSfBIjgJj44o2pgsV6WuXnX3SuTAYcGZXqZ5VP0NP4V1 e4/P2seqVkf6pnYYiVv0ojvWDJuRAvgZvC2GDCqNvVqO7j2enbiPupuay hBzRkWNpolNg67si8IXnWnUB3hG3TVi3c0W615y7H1ncuASRpVt1TpGqN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FAIl9hVCQ/khN/2dsb2JhbABFgkqJKbUjgQiCIAEBAQQSAQIYSwEMBAsRBAEBAQkWAQcHCQMCAQIBNAkIBg0BBQIBARcHh2ILnA2DThCcF4tfhm8DlXGFZIhqgQZlgnA X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208,217";a="8999604" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 22 Oct 2012 17:11:22 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9MHBMuj019121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 17:11:22 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9MHBJYg015074; Mon, 22 Oct 2012 18:11:19 +0100 (BST) Message-ID: <50857E37.4090908@cisco.com> Date: Mon, 22 Oct 2012 18:11:19 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Eric Gray References: <4FC58D13.6050803@pi.nu> <50856380.5000809@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF6FABF@EUSAAMB107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF6FABF@EUSAAMB107.ericsson.se> Content-Type: multipart/alternative; boundary="------------040802010402010707000407" Cc: "draft-ietf-mpls-tp-ethernet-addressing@tools.ietf.org" , "mpls@ietf.org" , MPLS-TP ad hoc team Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:11:27 -0000 This is a multi-part message in MIME format. --------------040802010402010707000407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric The advertized MTU parameter will be the MTU parameter that the operator configured at the TX end, so regardless of whether we are running GAP we have a problem if an MTU reducing node is introduced in the path. The MPLS-TP design assumes that no one is going to configure this sort of transparent bottleneck in the path and currently has no way to detect it. Does Y.1731 detect this sort of problem? If you seriously think we need to do MTU discovery, presumably to report up to the management system - since we can't do much about it at the PE, we can design an application to detect it. However I think we need to confident that it is a real problem and that a solution would be deployed. - Stewart On 22/10/2012 16:45, Eric Gray wrote: > > Stewart, > > There is an odd-ball "Ethernet Bridge" that may appear in some > circumstances where > > an operator may also chose to use MPLS-TP. That "odd-ball" bridge is > called a Two-Port MAC > > Relay and corresponds close to what the MEF defines as a "NID" > (network interface device). > > Where an operator may choose to use both is (possibly?) at the E-NNI > between two > > separately maintained service domains that are both owned by the same > operator. > > If this were the case, it seems likely that the NID may re-encapsulate > the frames it > > forwards in one direction or the other, or may simply use a different > technology that has a > > subtly different native MTU (e.g. - as an adaptation, between > different network types). > > One thing people tend to forget is that bridges are truly meant to be > transparent. > > -- > > Eric > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Monday, October 22, 2012 11:17 AM > *To:* Eric Gray > *Cc:* Loa Andersson; > draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org; mpls@ietf.org; > MPLS-TP ad hoc team > *Subject:* Re: [mpls] wg last call on gach-adv and ethernet-addressing > drafts > *Importance:* High > > On 08/06/2012 22:16, Eric Gray wrote: > > > > > > My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01 > > > > In general, this draft is nearly ready for publishing as an RFC. > > There are issues the working group and authors should consider. > > > > Major Issue: > > > > This is listed here because I am uncertain of the degree to which > > this may be a major or minor issue. > > > > The issue is with the inclusion of MTU as a discoverable parameter > > (Section 4). > > > > One reason for using a protocol other than LLDP to discover the > > Ethernet MAC address of an adjacent LSR, is where a physical link > > may include one or more intermediate bridges. > > > > If this is the case, and LLDP is not in use, then the MTU of the > > Ethernet end-stations (the peer/adjacent LSRs) may not be useful, > > since the intervening bridges could conceivably have a lower MTU. > > Well, there may be pt-pt Ethernet switches, but there should > never be an Ethernet bridge in an MPLS-TP path, since > MPLS-TP is defined to be non-merging. > > MTU may be useful on a PT-PT direct link, but I am not sure > what can be done in the other case other than to use the MTU > field as an upper bound in an MTU discovery process. > > We could define an MTU discovery/verification application > at a later date if this was needed. > > > > > Minor Issues: > > IANA Considerations - > > Why do the authors create yet another registry for IANA to maintain, > instead of using TLVs (with type numbers taken from the regitry that > was created in the GAP specification - from which this draft already > takes a new application identifier)? > > That is the design we have proposed - one registry per application. > Note the T size is 256, and thus we would need sub-TLVs if we > did not do that, and the sub-TLVs would need their own registries > so this is awash. > > > > This appears to set a very nasty precedent: each new application ID > specified from an IANA registry may establish a new registry. Does > IANA have the head-room for this? > > I think IANA will be fine with this. They will comment at IETF LC > if there is a problem, but I don't anticipate any issue. > > > > NITs: > > IANA Considerations - > > Not sure why section 6.1 is included. There is no action required > of IANA here, AFAICT. Minimally, the authors should explicitly > state that no further action is required from IANA by this section. > > It provides traceability back to this RFC. > > It says " IANA has allocated..." so IANA will see they have no actions. > > - Stewart > > > > -- > Eric Gray > > > > -----Original Message----- > From:mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, May 29, 2012 11:00 PM > To:mpls@ietf.org ; MPLS-TP ad hoc team > Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts > > Working Group, > > > This is to start a two week working group last call on two drafts: > > - draft-ietf-mpls-gach-adv-02; and > - draft-ietf-mpls-tp-ethernet-addressing-01 > > Please send comments to the mpls working group list. > > The working group last call ends June 15, 2012. > > > Thanks, Loa > > (as MPLS WG co-chair) > > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------040802010402010707000407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Eric

The advertized MTU parameter will be the MTU parameter that
the operator configured at the TX end, so regardless of
whether we are running GAP we have a problem if an MTU reducing
node is introduced in the path.

The MPLS-TP design assumes that no one is going to configure
this sort of transparent bottleneck in the path and currently
has no way to detect it. Does Y.1731 detect this sort of problem?

If you seriously think we need to do MTU discovery, presumably
to report up to the management system - since we can't
do much about it at the PE, we can design an application to detect
it. However I think we need to confident that it is a real problem
and that a solution would be deployed.

- Stewart

On 22/10/2012 16:45, Eric Gray wrote:

Stewart,

 

                There is an odd-ball "Ethernet Bridge" that may appear in some circumstances where

an operator may also chose to use MPLS-TP.  That "odd-ball" bridge is called a Two-Port MAC

Relay and corresponds close to what the MEF defines as a "NID" (network interface device).

 

                Where an operator may choose to use both is (possibly?) at the E-NNI between two

separately maintained service domains that are both owned by the same operator.

 

                If this were the case, it seems likely that the NID may re-encapsulate the frames it

forwards in one direction or the other, or may simply use a different technology that has a

subtly different native MTU (e.g. - as an adaptation, between different network types).

 

                One thing people tend to forget is that bridges are truly meant to be transparent.

 

--

Eric

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, October 22, 2012 11:17 AM
To: Eric Gray
Cc: Loa Andersson; draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org; mpls@ietf.org; MPLS-TP ad hoc team
Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts
Importance: High

 

On 08/06/2012 22:16, Eric Gray wrote:

 
 
My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01
 
In general, this draft is nearly ready for publishing as an RFC.
There are issues the working group and authors should consider.
 
Major Issue:
 
This is listed here because I am uncertain of the degree to which
this may be a major or minor issue.
 
The issue is with the inclusion of MTU as a discoverable parameter
(Section 4).
 
One reason for using a protocol other than LLDP to discover the
Ethernet MAC address of an adjacent LSR, is where a physical link
may include one or more intermediate bridges.
 
If this is the case, and LLDP is not in use, then the MTU of the
Ethernet end-stations (the peer/adjacent LSRs) may not be useful,
since the intervening bridges could conceivably have a lower MTU.

Well, there may be pt-pt Ethernet switches, but there should
never be an Ethernet bridge in an MPLS-TP path, since
MPLS-TP is defined to be non-merging.

MTU may be useful on a PT-PT direct link, but I am not sure
what can be done in the other case other than to use the MTU
field as an upper bound in an MTU discovery process.

We could define an MTU discovery/verification application
at a later date if this was needed.


 
 
Minor Issues:
 
IANA Considerations -
 
Why do the authors create yet another registry for IANA to maintain,
instead of using TLVs (with type numbers taken from the regitry that
was created in the GAP specification - from which this draft already
takes a new application identifier)?

That is the design we have proposed - one registry per application.
Note the T size is 256, and thus we would need sub-TLVs if we
did not do that, and the sub-TLVs would need their own registries
so this is awash.

 
 
This appears to set a very nasty precedent: each new application ID
specified from an IANA registry may establish a new registry.  Does
IANA have the head-room for this?

I think IANA will be fine with this. They will comment at IETF LC
if there is a problem, but I don't anticipate any issue.

 
 
NITs:
 
IANA Considerations -
 
Not sure why section 6.1 is included.  There is no action required 
of IANA here, AFAICT.  Minimally, the authors should explicitly
state that no further action is required from IANA by this section.

It provides traceability back to this RFC.

It says " IANA has allocated..." so IANA will see they have no actions.

- Stewart

 
 
--
Eric Gray
 
 
 
-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Tuesday, May 29, 2012 11:00 PM
To: mpls@ietf.org; MPLS-TP ad hoc team
Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts
 
Working Group,
 
 
This is to start a two week working group last call on two drafts:
 
- draft-ietf-mpls-gach-adv-02; and
- draft-ietf-mpls-tp-ethernet-addressing-01
 
Please send comments to the mpls working group list.
 
The working group last call ends June 15, 2012.
 
 
Thanks, Loa
 
(as MPLS WG co-chair)
 




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------040802010402010707000407-- From stbryant@cisco.com Mon Oct 22 10:18:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CFB21F84C4 for ; Mon, 22 Oct 2012 10:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SR1owUnkfLK for ; Mon, 22 Oct 2012 10:18:17 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6FF21F847F for ; Mon, 22 Oct 2012 10:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1781; q=dns/txt; s=iport; t=1350926296; x=1352135896; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=F7+JjNHMiH/T95DnObx8QRg9mwvDHpL793xaXuh9Sss=; b=NW5fuX8Xt3dAGqpnqu0pT1Y8MUN2Th72l715vFrFatSg40/hqEmxTa+L BtOOtjO1iZR2ObhPNek69oNsiUHiV4pNWGaoVNeLBaPsnb6sgsohFR6LZ ARgEf8Et4FwKSygPGld82ZwopX49Jyy3Y9DKKEOoThugsQ/ARHLsjOh01 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFACx/hVCQ/khR/2dsb2JhbABFvVSDQoEIgiABAQEDARIBAiNAAQULCxgJFg8JAwIBAgFFBg0BBwEBHodcBpwag04QnBmLX4ZvA5VxhWSIaoEGZYJw X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="77662144" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 22 Oct 2012 17:18:15 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9MHIFPE016964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 17:18:15 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9MHIB8r015575; Mon, 22 Oct 2012 18:18:12 +0100 (BST) Message-ID: <50857FD3.2090502@cisco.com> Date: Mon, 22 Oct 2012 18:18:11 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Eric Gray References: <4FC58D13.6050803@pi.nu> <5085463F.6040506@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF6FA87@EUSAAMB107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF6FA87@EUSAAMB107.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-gach-adv@tools.ietf.org" Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:18:19 -0000 Hi Eric, I think that (for the right reasons) you are trying to help IANA, but they have a well oiled process for this, and it is best to leave them to decide what is best practice in each case. On 22/10/2012 16:31, Eric Gray wrote: > Stewart, > > With the exception of one (probable) typo in your response (not your actual proposed text) > - where you say "adverting" and probably mean "advertising" - I am fine with your proposals. > > I had missed the text that describes the scoping of TLV types by application. > > I have one follow on question - which may or may not require clarification in the existing text. > In the text that describes the scoping of TLV object types, there are possibly two areas in which this > text may require further clarification: > > 1) Should the text suggest the creation of a registry for an application that does not immediately > require TLV types, or should this be left to later work that adds these types? I think that it should be a case of first TLV creator registers the registry. > I suspect that the > best approach would be to say that a TLV type registry needs only to be created if the TLV types > are explicitly defined in the document - but you may feel that this is "micro-management." > > 2) Is there any value in suggesting a specific template - based on this document (for the sake of > uniformity in IANA management of TLV type spaces for those applications requiring application- > specific TLVs). Again, this might be a form of micromanagement. The right thing is to let the authors (of the new work), IANA and the IESG cause the right thing to happen. The latter two groups are well rehearsed on how to best approach registries. - Stewart From internet-drafts@ietf.org Mon Oct 22 11:05:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B3611E80E3; Mon, 22 Oct 2012 11:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0jMxwxasAoG; Mon, 22 Oct 2012 11:05:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D745D11E80E7; Mon, 22 Oct 2012 11:05:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022180509.31838.67605.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 11:05:09 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-in-band-signaling-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:05:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Multipoint LDP in-band signaling for Point-to-Multipoint= and Multipoint- to-Multipoint Label Switched Paths Author(s) : IJsbrand Wijnands Toerless Eckert Nicolai Leymann Maria Napierala Filename : draft-ietf-mpls-mldp-in-band-signaling-07.txt Pages : 14 Date : 2012-10-22 Abstract: Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), needs to pass through an MPLS domain in which Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- Multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. This document describes procedures how IP multicast trees are spliced together with multipoint LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-in-band-signaling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-mldp-in-band-signaling-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-mldp-in-band-signaling-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Mon Oct 22 13:12:07 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6DA11E80A5 for ; Mon, 22 Oct 2012 13:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUmnczlLF3mq for ; Mon, 22 Oct 2012 13:12:06 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1C40921F88EF for ; Mon, 22 Oct 2012 13:12:05 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9MKC4ZK011327; Mon, 22 Oct 2012 21:12:05 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9MKC3kj011298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Oct 2012 21:12:04 +0100 From: "Adrian Farrel" To: References: <0da001cdb063$c0d75200$4285f600$@olddog.co.uk> In-Reply-To: <0da001cdb063$c0d75200$4285f600$@olddog.co.uk> Date: Mon, 22 Oct 2012 21:12:02 +0100 Message-ID: <0e6501cdb091$80866410$81932c30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG1vys+CUn6vgd0S3LvA4OdHSWAw5f1pFtg Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] One last problem with draft-ietf-mpls-return-path-specified-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 20:12:07 -0000 OK. Loa points out to me on IM that (not for the first time) I don't know what I am talking about. Think I read the registry not the RFC and got the allocation policies wrong (again). Back to the drawing board. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 22 October 2012 15:45 > To: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: [mpls] One last problem with draft-ietf-mpls-return-path-specified-lsp- > ping > > Thanks to the authors for a rapid turn-round on my review. > We are almost there. > > But the remaining issue is with the codepoints for the sub-TLVs of the Reply > Path TLV. There seems to be some *massive* disconnect! > > From the discussion of the 4379-defined "TLVs and sub-TLVs" sub-registry of the > "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) > Ping Parameters - TLVs" registry in old versions of the I-D, I had assumed that > you wanted to allow top-level TLVs from the registry to be used as sub-TLVs of > the new Reply Path TLV. The reason I thought this is that the document discusses > the allocation ranges for the top-level TLVs and says that new sub-TLVs of the > Reply Path TLV that apply only to the Reply Path TLV must be allocated out of > "safe" ranges - i.e. those ranges that cannot be allocated for top-level TLVs. > > But when I look at the early allocations done in the registry (and presumably > agreed by the authors) I see something completely different. What I see there is > that the Reply Path TLV can carry as its own sub-TLVs those sub-TLVs that can be > carried as sub-TLVs of the Target FEC Stack top-level TLV. > > So, I *think* what you are asking for is: > 1. A new top-level LSP Ping TLV called "Reply Path TLV" > Early allocation has assigned this value 21 > 2. The ability to carry any sub-TLV of the Target FEC Stack > top-level TLV as a sub-TLV of the Reply Path TLV > 3. A way to "lock step" the two sub-TLV registries so that > new sub-TLVs that can be carried in the Target FEC Stack > TLV can also be carried in the Reply Path TLV > 4. A way to create and register sub-TLVs that are only to > be used in the Reply Path TLV and are not to be carried in > the Target FEC Stack TLV > > All of this has nothing to do with 4379 allocation polices or ranges applied to > the top-level TLV registry. > > If this is what we are trying to do, then: > - we can delete the sections of text talking about TLV allocation > policies > - we can introduce some text instructing IANA to lock-step the > registries of sub-TLVs > - we can work out a policy that allows values used as sub-TLVs of > the Target FEC Stack TLV to be reserved so that they do not conflict > with allocations for sub-TLVs of the Reply Path TLV > > So, step 1: please confirm that I have now (finally) understood what it is > you're trying to achieve. > > Sorry it has taken me so long to understand. Hopefully we can resolve this > quickly from here on in. > > Regards, > Adrian > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Mon Oct 22 15:19:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAAE11E8099; Mon, 22 Oct 2012 15:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0eZJxbjXbhm; Mon, 22 Oct 2012 15:19:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF8021F8464; Mon, 22 Oct 2012 15:19:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022221917.15872.94985.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 15:19:17 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mpls-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:19:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Seamless MPLS Architecture Author(s) : Nicolai Leymann Bruno Decraene Clarence Filsfils Maciek Konstantynowicz Dirk Steinberg Filename : draft-ietf-mpls-seamless-mpls-02.txt Pages : 42 Date : 2012-10-22 Abstract: This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mpls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-seamless-mpls-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mach.chen@huawei.com Mon Oct 22 18:50:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1C21F898B for ; Mon, 22 Oct 2012 18:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.988 X-Spam-Level: ** X-Spam-Status: No, score=2.988 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tniCWLf11WSK for ; Mon, 22 Oct 2012 18:50:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B7CA821F8981 for ; Mon, 22 Oct 2012 18:50:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALX37275; Tue, 23 Oct 2012 01:49:59 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 02:49:53 +0100 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 02:49:59 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.192]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 09:49:55 +0800 From: Mach Chen To: "adrian@olddog.co.uk" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" Thread-Topic: One last problem with draft-ietf-mpls-return-path-specified-lsp-ping Thread-Index: Ac2wY5bU1kBGg+iDQ9ywvx/GF0lebAAVOgqw Date: Tue, 23 Oct 2012 01:49:55 +0000 Message-ID: References: <0da001cdb063$c0d75200$4285f600$@olddog.co.uk> In-Reply-To: <0da001cdb063$c0d75200$4285f600$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogT25lIGxhc3QgcHJvYmxlbSB3aXRoIGRyYWZ0?= =?gb2312?b?LWlldGYtbXBscy1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtbHNwLXBpbmc=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 01:50:02 -0000 SGkgQWRyaWFuLA0KDQo+IFNvLCBJICp0aGluayogd2hhdCB5b3UgYXJlIGFza2luZyBmb3IgaXM6 DQo+IDEuIEEgbmV3IHRvcC1sZXZlbCBMU1AgUGluZyBUTFYgY2FsbGVkICJSZXBseSBQYXRoIFRM ViINCj4gICAgIEVhcmx5IGFsbG9jYXRpb24gaGFzIGFzc2lnbmVkIHRoaXMgdmFsdWUgMjENCj4g Mi4gVGhlIGFiaWxpdHkgdG8gY2FycnkgYW55IHN1Yi1UTFYgb2YgdGhlIFRhcmdldCBGRUMgU3Rh Y2sNCj4gICAgdG9wLWxldmVsIFRMViBhcyBhIHN1Yi1UTFYgb2YgdGhlIFJlcGx5IFBhdGggVExW DQo+IDMuIEEgd2F5IHRvICJsb2NrIHN0ZXAiIHRoZSB0d28gc3ViLVRMViByZWdpc3RyaWVzIHNv IHRoYXQNCj4gICAgbmV3IHN1Yi1UTFZzIHRoYXQgY2FuIGJlIGNhcnJpZWQgaW4gdGhlIFRhcmdl dCBGRUMgU3RhY2sNCj4gICAgVExWIGNhbiBhbHNvIGJlIGNhcnJpZWQgaW4gdGhlIFJlcGx5IFBh dGggVExWDQo+IDQuIEEgd2F5IHRvIGNyZWF0ZSBhbmQgcmVnaXN0ZXIgc3ViLVRMVnMgdGhhdCBh cmUgb25seSB0bw0KPiAgICBiZSB1c2VkIGluIHRoZSBSZXBseSBQYXRoIFRMViBhbmQgYXJlIG5v dCB0byBiZSBjYXJyaWVkIGluDQo+ICAgIHRoZSBUYXJnZXQgRkVDIFN0YWNrIFRMVg0KDQpZZXMs IHRoZXNlIGFyZSB0aGUgdGFyZ2V0cyB0aGF0IHRoZSBJLUQgaXMgdHJ5aW5nIHRvIGFjaGlldmUs IGFuZCB0aGUgZG9jdW1lbnQgcmVkZWZpbmVzIHRoZSAiVmVuZG9yIFByaXZhdGUgVXNlIiByYW5n ZSB0byBhY2hpZXZlIHRoZSB0YXJnZXQgNCBhYm92ZS4NCg0KQmVzdCByZWdhcmRzLA0KTWFjaA0K DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IEFkcmlhbiBGYXJyZWwgW21haWx0bzph ZHJpYW5Ab2xkZG9nLmNvLnVrXQ0KPiC3osvNyrG85DogMjAxMsTqMTDUwjIyyNUgMjI6NDUNCj4g ytW8/sjLOiBkcmFmdC1pZXRmLW1wbHMtcmV0dXJuLXBhdGgtc3BlY2lmaWVkLWxzcC1waW5nLmFs bEB0b29scy5pZXRmLm9yZw0KPiCzrcvNOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZw0KPiDW98ziOiBPbmUgbGFzdCBwcm9ibGVtIHdpdGggZHJhZnQtaWV0Zi1tcGxz LXJldHVybi1wYXRoLXNwZWNpZmllZC1sc3AtcGluZw0KPiANCj4gVGhhbmtzIHRvIHRoZSBhdXRo b3JzIGZvciBhIHJhcGlkIHR1cm4tcm91bmQgb24gbXkgcmV2aWV3Lg0KPiBXZSBhcmUgYWxtb3N0 IHRoZXJlLg0KPiANCj4gQnV0IHRoZSByZW1haW5pbmcgaXNzdWUgaXMgd2l0aCB0aGUgY29kZXBv aW50cyBmb3IgdGhlIHN1Yi1UTFZzIG9mIHRoZSBSZXBseQ0KPiBQYXRoIFRMVi4gVGhlcmUgc2Vl bXMgdG8gYmUgc29tZSAqbWFzc2l2ZSogZGlzY29ubmVjdCENCj4gDQo+IEZyb20gdGhlIGRpc2N1 c3Npb24gb2YgdGhlIDQzNzktZGVmaW5lZCAiVExWcyBhbmQgc3ViLVRMVnMiIHN1Yi1yZWdpc3Ry eSBvZiB0aGUNCj4gIk11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIEFyY2hpdGVjdHVyZSAo TVBMUykgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExTUHMpDQo+IFBpbmcgUGFyYW1ldGVycyAtIFRM VnMiIHJlZ2lzdHJ5IGluIG9sZCB2ZXJzaW9ucyBvZiB0aGUgSS1ELCBJIGhhZCBhc3N1bWVkIHRo YXQNCj4geW91IHdhbnRlZCB0byBhbGxvdyB0b3AtbGV2ZWwgVExWcyBmcm9tIHRoZSByZWdpc3Ry eSB0byBiZSB1c2VkIGFzIHN1Yi1UTFZzIG9mDQo+IHRoZSBuZXcgUmVwbHkgUGF0aCBUTFYuIFRo ZSByZWFzb24gSSB0aG91Z2h0IHRoaXMgaXMgdGhhdCB0aGUgZG9jdW1lbnQNCj4gZGlzY3Vzc2Vz DQo+IHRoZSBhbGxvY2F0aW9uIHJhbmdlcyBmb3IgdGhlIHRvcC1sZXZlbCBUTFZzIGFuZCBzYXlz IHRoYXQgbmV3IHN1Yi1UTFZzIG9mIHRoZQ0KPiBSZXBseSBQYXRoIFRMViB0aGF0IGFwcGx5IG9u bHkgdG8gdGhlIFJlcGx5IFBhdGggVExWIG11c3QgYmUgYWxsb2NhdGVkIG91dCBvZg0KPiAic2Fm ZSIgcmFuZ2VzIC0gaS5lLiB0aG9zZSByYW5nZXMgdGhhdCBjYW5ub3QgYmUgYWxsb2NhdGVkIGZv ciB0b3AtbGV2ZWwgVExWcy4NCj4gDQo+IEJ1dCB3aGVuIEkgbG9vayBhdCB0aGUgZWFybHkgYWxs b2NhdGlvbnMgZG9uZSBpbiB0aGUgcmVnaXN0cnkgKGFuZCBwcmVzdW1hYmx5DQo+IGFncmVlZCBi eSB0aGUgYXV0aG9ycykgSSBzZWUgc29tZXRoaW5nIGNvbXBsZXRlbHkgZGlmZmVyZW50LiBXaGF0 IEkgc2VlIHRoZXJlDQo+IGlzDQo+IHRoYXQgdGhlIFJlcGx5IFBhdGggVExWIGNhbiBjYXJyeSBh cyBpdHMgb3duIHN1Yi1UTFZzIHRob3NlIHN1Yi1UTFZzIHRoYXQgY2FuDQo+IGJlDQo+IGNhcnJp ZWQgYXMgc3ViLVRMVnMgb2YgdGhlIFRhcmdldCBGRUMgU3RhY2sgdG9wLWxldmVsIFRMVi4NCj4g DQo+IFNvLCBJICp0aGluayogd2hhdCB5b3UgYXJlIGFza2luZyBmb3IgaXM6DQo+IDEuIEEgbmV3 IHRvcC1sZXZlbCBMU1AgUGluZyBUTFYgY2FsbGVkICJSZXBseSBQYXRoIFRMViINCj4gICAgIEVh cmx5IGFsbG9jYXRpb24gaGFzIGFzc2lnbmVkIHRoaXMgdmFsdWUgMjENCj4gMi4gVGhlIGFiaWxp dHkgdG8gY2FycnkgYW55IHN1Yi1UTFYgb2YgdGhlIFRhcmdldCBGRUMgU3RhY2sNCj4gICAgdG9w LWxldmVsIFRMViBhcyBhIHN1Yi1UTFYgb2YgdGhlIFJlcGx5IFBhdGggVExWDQo+IDMuIEEgd2F5 IHRvICJsb2NrIHN0ZXAiIHRoZSB0d28gc3ViLVRMViByZWdpc3RyaWVzIHNvIHRoYXQNCj4gICAg bmV3IHN1Yi1UTFZzIHRoYXQgY2FuIGJlIGNhcnJpZWQgaW4gdGhlIFRhcmdldCBGRUMgU3RhY2sN Cj4gICAgVExWIGNhbiBhbHNvIGJlIGNhcnJpZWQgaW4gdGhlIFJlcGx5IFBhdGggVExWDQo+IDQu IEEgd2F5IHRvIGNyZWF0ZSBhbmQgcmVnaXN0ZXIgc3ViLVRMVnMgdGhhdCBhcmUgb25seSB0bw0K PiAgICBiZSB1c2VkIGluIHRoZSBSZXBseSBQYXRoIFRMViBhbmQgYXJlIG5vdCB0byBiZSBjYXJy aWVkIGluDQo+ICAgIHRoZSBUYXJnZXQgRkVDIFN0YWNrIFRMVg0KPiANCj4gQWxsIG9mIHRoaXMg aGFzIG5vdGhpbmcgdG8gZG8gd2l0aCA0Mzc5IGFsbG9jYXRpb24gcG9saWNlcyBvciByYW5nZXMg YXBwbGllZCB0bw0KPiB0aGUgdG9wLWxldmVsIFRMViByZWdpc3RyeS4NCj4gDQo+IElmIHRoaXMg aXMgd2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIGRvLCB0aGVuOg0KPiAtIHdlIGNhbiBkZWxldGUgdGhl IHNlY3Rpb25zIG9mIHRleHQgdGFsa2luZyBhYm91dCBUTFYgYWxsb2NhdGlvbg0KPiAgICBwb2xp Y2llcw0KPiAtIHdlIGNhbiBpbnRyb2R1Y2Ugc29tZSB0ZXh0IGluc3RydWN0aW5nIElBTkEgdG8g bG9jay1zdGVwIHRoZQ0KPiAgIHJlZ2lzdHJpZXMgb2Ygc3ViLVRMVnMNCj4gLSB3ZSBjYW4gd29y ayBvdXQgYSBwb2xpY3kgdGhhdCBhbGxvd3MgdmFsdWVzIHVzZWQgYXMgc3ViLVRMVnMgb2YNCj4g ICB0aGUgVGFyZ2V0IEZFQyBTdGFjayBUTFYgdG8gYmUgcmVzZXJ2ZWQgc28gdGhhdCB0aGV5IGRv IG5vdCBjb25mbGljdA0KPiAgIHdpdGggYWxsb2NhdGlvbnMgZm9yIHN1Yi1UTFZzIG9mIHRoZSBS ZXBseSBQYXRoIFRMVg0KPiANCj4gU28sIHN0ZXAgMTogcGxlYXNlIGNvbmZpcm0gdGhhdCBJIGhh dmUgbm93IChmaW5hbGx5KSB1bmRlcnN0b29kIHdoYXQgaXQgaXMNCj4geW91J3JlIHRyeWluZyB0 byBhY2hpZXZlLg0KPiANCj4gU29ycnkgaXQgaGFzIHRha2VuIG1lIHNvIGxvbmcgdG8gdW5kZXJz dGFuZC4gSG9wZWZ1bGx5IHdlIGNhbiByZXNvbHZlIHRoaXMNCj4gcXVpY2tseSBmcm9tIGhlcmUg b24gaW4uDQo+IA0KPiBSZWdhcmRzLA0KPiBBZHJpYW4NCg0K From lizhong.jin@zte.com.cn Mon Oct 22 19:32:54 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9581F0429 for ; Mon, 22 Oct 2012 19:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.358 X-Spam-Level: X-Spam-Status: No, score=-99.358 tagged_above=-999 required=5 tests=[AWL=3.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TurpstU9AODL for ; Mon, 22 Oct 2012 19:32:53 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF4021F847F for ; Mon, 22 Oct 2012 19:32:53 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id A3449124A7FD for ; Tue, 23 Oct 2012 10:33:45 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id A633670E89C; Tue, 23 Oct 2012 10:29:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q9N2Whix009176; Tue, 23 Oct 2012 10:32:43 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <508569AD.1060903@cisco.com> To: stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Tue, 23 Oct 2012 10:32:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-23 10:32:42, Serialize complete at 2012-10-23 10:32:42 Content-Type: multipart/alternative; boundary="=_alternative 000DFB6948257AA0_=" X-MAIL: mse02.zte.com.cn q9N2Whix009176 Cc: mpls@ietf.org, ahmpls-tp@lists.itu.int Subject: Re: [mpls] wg last call on ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 02:32:55 -0000 This is a multipart message in MIME format. --=_alternative 000DFB6948257AA0_= Content-Type: text/plain; charset="US-ASCII" Hi Stewart, Please see inline below. Thanks Lizhong Stewart Bryant wrote 2012/10/22 23:43:41: > On 11/06/2012 09:55, Lizhong Jin wrote: > > Hi authors, > I review draft-ietf-mpls-tp-ethernet-addressing, and have two comments: > 1. When advertising the MAC address in "Ethernet Interface > Parameters" ADB, I think Interface Identifier TLV in "G-ACh > Advertisement Protocol" ADB should also be carried. Is there any > required relationship of "Lifetime" in the two ADBs, should be same? > > It is not required to carry the identifier, since that identifier is > not required by MPLS_TP. > The protocol requires that you refresh the announcement, if you are > going to carry the SA and the MAC in the same message it would make > sense to give them the same lifetime, but the rule (clearly stated > in the draft) is that you must refresh before information is > expired, so as long as you refresh on the lower of the two you are > OK, and it is not harmful to have them set differently if that makes > sense in the particular application. [Lizhong] clear, thanks. > 2. For the "Ethernet Interface Parameters" application, is it > allowed to apply GAP Request, Flush or Suppress message specified in > [I-D.ietf-mpls-gach-adv]? E.g, to use GAP Request to request MAC address. > Yes if it makes sense in your application. I can see that you might > for example suppress the MAC address refresh and rely on your peer > to over-ride the request if the address changed. > > I am not sure why this needs clarification since the Ethernet draft > inherits the rules of the GAP protocol. [Lizhong] in section 4, all the description is for application "0x0001", while the request/suppress message in [I-D.ietf-mpls-gach-adv] is for application "0x0000". e.g, "This document defines a new GAP application, "Ethernet Interface Parameters", to support the advertisement of Ethernet-specific parameters associated with the sending interface." It seems the procedure in section 4 only inherits the GAP message, but not GAP application "0x0000". It would be good have some description to say, the GAP application "0x0000" could be also applied to this draft. > > - Stewart > > > Hope to be more clear in Section 4. > > Thanks > Lizhong > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 30 May 2012 04:59:31 +0200 > > From: Loa Andersson > > To: "mpls@ietf.org" , MPLS-TP ad hoc team > > > > Subject: [mpls] wg last call on gach-adv and ethernet-addressing > > drafts > > Message-ID: <4FC58D13.6050803@pi.nu> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > Working Group, > > > > > > This is to start a two week working group last call on two drafts: > > > > - draft-ietf-mpls-gach-adv-02; and > > - draft-ietf-mpls-tp-ethernet-addressing-01 > > > > Please send comments to the mpls working group list. > > > > The working group last call ends June 15, 2012. > > > > > > Thanks, Loa > > > > (as MPLS WG co-chair) > > > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > --=_alternative 000DFB6948257AA0_= Content-Type: text/html; charset="US-ASCII"
Hi Stewart,
Please see inline below.

Thanks
Lizhong


Stewart Bryant <stbryant@cisco.com> wrote 2012/10/22 23:43:41:

> On 11/06/2012 09:55, Lizhong Jin wrote:
>
> Hi authors,
> I review draft-ietf-mpls-tp-ethernet-addressing, and have two comments:
> 1. When advertising the MAC address in "Ethernet Interface
> Parameters" ADB, I think Interface Identifier TLV in "G-ACh
> Advertisement Protocol" ADB should also be carried. Is there any
> required relationship of "Lifetime" in the two ADBs, should be same?
>
> It is not required to carry the identifier, since that identifier is
> not required by MPLS_TP.
> The protocol requires that you refresh the announcement, if you are
> going to carry the SA and the MAC in the same message it would make
> sense to give them the same lifetime, but the rule (clearly stated
> in the draft) is that you must refresh before information is
> expired, so as long as you refresh on the lower of the two you are
> OK, and it is not harmful to have them set differently if that makes
> sense in the particular application.
[Lizhong] clear, thanks.
> 2. For the "Ethernet Interface Parameters" application, is it
> allowed to apply GAP Request, Flush or Suppress message specified in
> [I-D.ietf-mpls-gach-adv]? E.g, to use GAP Request to request MAC address.
> Yes if it makes sense in your application. I can see that you might
> for example suppress the MAC address refresh and rely on your peer
> to over-ride the request if the address changed.
>
> I am not sure why this needs clarification since the Ethernet draft
> inherits the rules of the GAP protocol.
[Lizhong] in section 4, all the description is for application "0x0001", while the request/suppress message in [I-D.ietf-mpls-gach-adv] is for application "0x0000".
e.g, "This document defines a new GAP application, "Ethernet Interface Parameters", to support the advertisement of Ethernet-specific parameters associated with the sending interface."
It seems the procedure in section 4 only inherits the GAP message, but not GAP application "0x0000". It would be good have some description to say, the GAP application "0x0000" could be also applied to this draft.

>
> - Stewart
>

>
> Hope to be more clear in Section 4.
>
> Thanks
> Lizhong
>
>  
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 30 May 2012 04:59:31 +0200
> > From: Loa Andersson <loa@pi.nu>
> > To: "mpls@ietf.org" <mpls@ietf.org>,    MPLS-TP ad hoc team
> >    <ahmpls-tp@lists.itu.int>
> > Subject: [mpls] wg last call  on gach-adv and ethernet-addressing
> >    drafts
> > Message-ID: <4FC58D13.6050803@pi.nu>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Working Group,
> >
> >
> > This is to start a two week working group last call on two drafts:
> >
> > - draft-ietf-mpls-gach-adv-02; and
> > - draft-ietf-mpls-tp-ethernet-addressing-01
> >
> > Please send comments to the mpls working group list.
> >
> > The working group last call ends June 15, 2012.
> >
> >
> > Thanks, Loa
> >
> > (as MPLS WG co-chair)
> >
> > --
> >
> >
> > Loa Andersson                         email: loa.andersson@ericsson.com
> > Sr Strategy and Standards Manager            loa@pi.nu
> > Ericsson Inc                          phone: +46 10 717 52 13
> >                                               +46 767 72 92 13
> >
> >

> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

> --
> For corporate legal information go to:
>
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
--=_alternative 000DFB6948257AA0_=-- From mach.chen@huawei.com Tue Oct 23 02:08:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B6F21F8662; Tue, 23 Oct 2012 02:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[AWL=4.639, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo+nSNtBHu3p; Tue, 23 Oct 2012 02:08:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DE67521F8646; Tue, 23 Oct 2012 02:08:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALZ23989; Tue, 23 Oct 2012 09:08:17 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 10:08:09 +0100 Received: from SZXEML447-HUB.china.huawei.com (10.82.67.185) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 10:08:15 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.192]) by szxeml447-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 17:05:29 +0800 From: Mach Chen To: "ccamp@ietf.org" Thread-Topic: =?utf-8?B?U29saWNpdCBjb21tZW50cyBvbiBDb250cm9sIFBsYW5lIGJhc2VkIE1QTFMt?= =?utf-8?B?VFAgTG9jayBJbnN0dWN0IGFuZCBMb29wYmFjay/nrZTlpI06IE5ldyBWZXJz?= =?utf-8?B?aW9uIE5vdGlmaWNhdGlvbiBmb3IJZHJhZnQtZG9uZy1jY2FtcC1yc3ZwLXRl?= =?utf-8?Q?-mpls-tp-li-lb-04.txt?= Thread-Index: AQHNsC+Is7bA31wG60Wde5s2cwwm15fGlaOw Date: Tue, 23 Oct 2012 09:05:29 +0000 Message-ID: References: <20121022083037.4415.84960.idtracker@ietfa.amsl.com> In-Reply-To: <20121022083037.4415.84960.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: [mpls] =?utf-8?q?Solicit_comments_on_Control_Plane_based_MPLS-TP_?= =?utf-8?q?Lock_Instuct_and_Loopback/=E7=AD=94=E5=A4=8D=3A_New_Version_Not?= =?utf-8?q?ification_for=09draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-04=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:08:19 -0000 SGksDQoNCldlIGp1c3QgdXBsb2FkZWQgYW4gdXBkYXRlIHRvIHRoZSAiUlNWUC1URSBFeHRlbnNp b25zIGZvciBMb2NrIEluc3RydWN0IGFuZCBMb29wYmFjayBpbiBNUExTIFRyYW5zcG9ydCBQcm9m aWxlIiBkcmFmdCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZG9uZy1jY2FtcC1y c3ZwLXRlLW1wbHMtdHAtbGktbGItMDQpLg0KDQpUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBleHRl bnNpb25zIHRvIFJTVlAtVEUgdG8gaW1wbGVtZW50IExJIGFuZCBMQiBmdW5jdGlvbnMgZm9yIE1Q TFMtVFAgTFNQcyB3aGVuIE1QTFMtVFAgY29udHJvbCBwbGFuZSBpcyB1c2VkLiAgVGhlIG1lY2hh bmlzbXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBjb21wbGVtZW50YXJ5IHRvIFtSRkM2 NDM1XSAoTWFuYWdlbWVudCBwbGFuZSBiYXNlZCBMSSBhbmQgTEIpLg0KDQpUaGUgZHJhZnQgaXMg c2hvcnQsIHdlJ2QgYXBwcmVjaWF0ZSB0aGF0IHlvdSBjb3VsZCBzcGVuZCBzZXZlcmFsIG1pbnV0 ZXMgdG8gcmV2aWV3IGFuZCBjb21tZW50IHRoZSBkcmFmdC4NCg0KTWFueSB0aGFua3MsDQpNYWNo DQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IOWPkemAgeaXtumX tDogMjAxMuW5tDEw5pyIMjLml6UgMTY6MzENCj4g5pS25Lu25Lq6OiBKaWUgRG9uZw0KPiDmioTp gIE6IE1hY2ggQ2hlbjsgbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQo+IOS4u+mimDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1kb25nLWNjYW1wLXJzdnAtdGUtbXBs cy10cC1saS1sYi0wNC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt ZG9uZy1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAtbGktbGItMDQudHh0DQo+IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgSmllIERvbmcgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiBy ZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6CSBkcmFmdC1kb25nLWNjYW1wLXJzdnAtdGUtbXBs cy10cC1saS1sYg0KPiBSZXZpc2lvbjoJIDA0DQo+IFRpdGxlOgkJIFJTVlAtVEUgRXh0ZW5zaW9u cyBmb3IgTG9jayBJbnN0cnVjdCBhbmQgTG9vcGJhY2sgaW4gTVBMUw0KPiBUcmFuc3BvcnQgUHJv ZmlsZQ0KPiBDcmVhdGlvbiBkYXRlOgkgMjAxMi0xMC0yMg0KPiBXRyBJRDoJCSBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiA4DQo+IFVSTDoNCj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZG9uZy1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAt bGktbGItMDQudA0KPiB4dA0KPiBTdGF0dXM6DQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZG9uZy1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAtbGktbGINCj4gSHRtbGl6ZWQ6 DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbmctY2NhbXAtcnN2cC10ZS1t cGxzLXRwLWxpLWxiLTA0DQo+IERpZmY6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWRvbmctY2NhbXAtcnN2cC10ZS1tcGxzLXRwLWxpLWxiLTA0DQo+IA0KPiBBYnN0 cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgZXh0ZW5zaW9ucyB0byBSU1ZQLVRF IHRvIHN1cHBvcnQgbG9jaw0KPiAgICBpbnN0cnVjdCBhbmQgbG9vcGJhY2sgbWVjaGFuaXNtIGZv ciBNUExTLVRQIExTUHMuICBUaGUgbWVjaGFuaXNtcyBhcmUNCj4gICAgaW50ZW5kZWQgdG8gYmUg YXBwbGljYWJsZSB0byBvdGhlciB0ZWNobm9sb2dpZXMgd2hpY2ggdXNlIEdNUExTLw0KPiAgICBS U1ZQLVRFIGFzIGNvbnRyb2wgcGxhbmUuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0K From mach.chen@huawei.com Tue Oct 23 02:11:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05F521F8658; Tue, 23 Oct 2012 02:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=4.059, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAE+ocJKLmPq; Tue, 23 Oct 2012 02:11:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AAC1121F8646; Tue, 23 Oct 2012 02:11:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALZ24344; Tue, 23 Oct 2012 09:11:35 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 10:11:15 +0100 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 10:11:21 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.192]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 17:10:32 +0800 From: Mach Chen To: "pwe3@ietf.org" Thread-Topic: =?utf-8?B?U29saWNpdCBjb21tZW50cyBvbiBDb250cm9sIFBsYW5lIChMRFApIGJhc2Vk?= =?utf-8?B?IE1QTFMtVFAgTG9jayBJbnN0dWN0IGFuZCBMb29wYmFjay8v6L2s5Y+ROiBO?= =?utf-8?B?ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbmctcHdlMy1t?= =?utf-8?Q?pls-tp-li-lb-02.txt?= Thread-Index: AQHNsP5BE3x9i2Hlykaq1t6JI/FCVg== Date: Tue, 23 Oct 2012 09:10:32 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: [mpls] =?utf-8?q?Solicit_comments_on_Control_Plane_=28LDP=29_base?= =?utf-8?q?d_MPLS-TP_Lock_Instuct_and_Loopback//=E8=BD=AC=E5=8F=91=3A_New_?= =?utf-8?q?Version_Notification_for_draft-dong-pwe3-mpls-tp-li-lb-02=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:11:37 -0000 SGksDQoNCldlIGp1c3QgdXBsb2FkZWQgYW4gdXBkYXRlIHRvIHRoZSAiIExEUCBFeHRlbnNpb25z IGZvciBMb2NrIEluc3RydWN0IGFuZCBMb29wYmFjayBvZiBQc2V1ZG93aXJlIGluIE1QTFMgVHJh bnNwb3J0IFByb2ZpbGUgIiBkcmFmdCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt ZG9uZy1wd2UzLW1wbHMtdHAtbGktbGItMDIgKS4NCg0KVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMg ZXh0ZW5zaW9ucyB0byBMRFAgdG8gaW1wbGVtZW50IExJIGFuZCBMQiBmdW5jdGlvbnMgZm9yIE1Q TFMtVFAgTFNQcyB3aGVuIE1QTFMtVFAgY29udHJvbCBwbGFuZSBpcyB1c2VkLiAgVGhlIG1lY2hh bmlzbXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBjb21wbGVtZW50YXJ5IHRvIFtSRkM2 NDM1XSAoTWFuYWdlbWVudCBwbGFuZSBiYXNlZCBMSSBhbmQgTEIpLg0KDQpXZSdkIGFwcHJlY2lh dGUgdGhhdCB5b3UgY291bGQgc3BlbmQgc2V2ZXJhbCBtaW51dGVzIHRvIHJldmlldyBhbmQgY29t bWVudCB0aGUgZHJhZnQuDQoNCk1hbnkgdGhhbmtzLA0KTWFjaA0KDQotLS0tLemCruS7tuWOn+S7 ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTLlubQxMOaciDIy5pelIDE2 OjExDQrmlLbku7bkuro6IEppZSBEb25nDQrmioTpgIE6IGdyZWdvcnkubWlyc2t5QGVyaWNzc29u LmNvbTsgTWFjaCBDaGVuDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtZG9uZy1wd2UzLW1wbHMtdHAtbGktbGItMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWRvbmctcHdlMy1tcGxzLXRwLWxpLWxiLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBKaWUgRG9uZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBv c2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWRvbmctcHdlMy1tcGxzLXRwLWxpLWxiDQpSZXZp c2lvbjoJIDAyDQpUaXRsZToJCSBMRFAgRXh0ZW5zaW9ucyBmb3IgTG9jayBJbnN0cnVjdCBhbmQg TG9vcGJhY2sgb2YgUHNldWRvd2lyZSBpbiBNUExTIFRyYW5zcG9ydCBQcm9maWxlDQpDcmVhdGlv biBkYXRlOgkgMjAxMi0xMC0yMg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1i ZXIgb2YgcGFnZXM6IDgNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtZG9uZy1wd2UzLW1wbHMtdHAtbGktbGItMDIudHh0DQpTdGF0dXM6 ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZG9uZy1wd2Uz LW1wbHMtdHAtbGktbGINCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZG9uZy1wd2UzLW1wbHMtdHAtbGktbGItMDINCkRpZmY6ICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZG9uZy1wd2UzLW1wbHMtdHAtbGkt bGItMDINCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBleHRlbnNpb25z IHRvIHRoZSBMYWJlbCBEaXN0cmlidXRpb24gUHJvdG9jb2wNCiAgIChMRFApIHRvIHN1cHBvcnQg cHJvdmlzaW9uaW5nIG9mIGxvY2sgaW5zdHJ1Y3QgYW5kIGxvb3BiYWNrIG1lY2hhbmlzbQ0KICAg Zm9yIE1QTFMtVFAgUHNldWRvd2lyZXMuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From ietfc@btconnect.com Tue Oct 23 04:43:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE59A21F86CE for ; Tue, 23 Oct 2012 04:43:53 -0700 (PDT) X-Quarantine-ID: <3M3RvWC96HXU> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char B4 hex): Subject: Re: [mpls] \264\360\270\264: One last p[...] X-Spam-Flag: NO X-Spam-Score: -1.053 X-Spam-Level: X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[AWL=-2.130, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SUBJECT_NEEDS_ENCODING=0.001, SUBJ_ILLEGAL_CHARS=1.586] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M3RvWC96HXU for ; Tue, 23 Oct 2012 04:43:53 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id B35A721F8644 for ; Tue, 23 Oct 2012 04:43:52 -0700 (PDT) Received: from mail3-db3-R.bigfish.com (10.3.81.241) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 23 Oct 2012 11:43:51 +0000 Received: from mail3-db3 (localhost [127.0.0.1]) by mail3-db3-R.bigfish.com (Postfix) with ESMTP id 8CE6740161; Tue, 23 Oct 2012 11:43:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(z5109hz9371Ic89bh542M1432Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h941hd24hf0ah107ah1177h1179h1269h1288h12a5h12a9h12bdh12e1h137ah139eh13b6h1441h1504h304l1155h) Received: from mail3-db3 (localhost.localdomain [127.0.0.1]) by mail3-db3 (MessageSwitch) id 1350992630705089_15809; Tue, 23 Oct 2012 11:43:50 +0000 (UTC) Received: from DB3EHSMHS013.bigfish.com (unknown [10.3.81.233]) by mail3-db3.bigfish.com (Postfix) with ESMTP id A98A040006B; Tue, 23 Oct 2012 11:43:50 +0000 (UTC) Received: from DBXPRD0710HT004.eurprd07.prod.outlook.com (157.56.253.197) by DB3EHSMHS013.bigfish.com (10.3.87.113) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 23 Oct 2012 11:43:50 +0000 Received: from DBXPRD0610HT003.eurprd06.prod.outlook.com (157.56.252.181) by pod51017.outlook.com (10.255.79.167) with Microsoft SMTP Server (TLS) id 14.16.224.5; Tue, 23 Oct 2012 11:43:49 +0000 Message-ID: <00bf01cdb113$9f1d3980$4001a8c0@gateway.2wire.net> From: t.petch To: Mach Chen , , References: <0da001cdb063$c0d75200$4285f600$@olddog.co.uk> Subject: Re: [mpls] ´ð¸´: One last problem with draft-ietf-mpls-return-path-specified-lsp-ping Date: Tue, 23 Oct 2012 12:43:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:43:53 -0000 ----- Original Message ----- From: "Mach Chen" To: ; Cc: ; Sent: Tuesday, October 23, 2012 2:49 AM > Hi Adrian, > > > So, I *think* what you are asking for is: > > 1. A new top-level LSP Ping TLV called "Reply Path TLV" > > Early allocation has assigned this value 21 > > 2. The ability to carry any sub-TLV of the Target FEC Stack > > top-level TLV as a sub-TLV of the Reply Path TLV > > 3. A way to "lock step" the two sub-TLV registries so that > > new sub-TLVs that can be carried in the Target FEC Stack > > TLV can also be carried in the Reply Path TLV > > 4. A way to create and register sub-TLVs that are only to > > be used in the Reply Path TLV and are not to be carried in > > the Target FEC Stack TLV > > Yes, these are the targets that the I-D is trying to achieve, and the document redefines the "Vendor Private Use" range to achieve the target 4 above. Yes, I too think that this is, technically, broadly, what the I-D is setting out to do. With the benefit of hindsight, RFC4379 would have done better to define a range of values for common sub-TLVs, likely to be used by several TLVs; and a range of values for sub-TLVs which are TLV specific. And a requirement for future definers of sub-TLVs to be clear about the usage of any common ones. Other IANA registries have this concept. So I see this I-D as moving towards that sort of registry. Tom Petch > Best regards, > Mach > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Adrian Farrel [mailto:adrian@olddog.co.uk] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA10=D4=C222=C8=D5 22:45 > > =CA=D5=BC=FE=C8=CB: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org > > =B3=AD=CB=CD: mpls@ietf.org; mpls-chairs@tools.ietf.org > > =D6=F7=CC=E2: One last problem with draft-ietf-mpls-return-path-specified-lsp-ping > > > > Thanks to the authors for a rapid turn-round on my review. > > We are almost there. > > > > But the remaining issue is with the codepoints for the sub-TLVs of the Reply > > Path TLV. There seems to be some *massive* disconnect! > > > > From the discussion of the 4379-defined "TLVs and sub-TLVs" sub-registry of the > > "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) > > Ping Parameters - TLVs" registry in old versions of the I-D, I had assumed that > > you wanted to allow top-level TLVs from the registry to be used as sub-TLVs of > > the new Reply Path TLV. The reason I thought this is that the document > > discusses > > the allocation ranges for the top-level TLVs and says that new sub-TLVs of the > > Reply Path TLV that apply only to the Reply Path TLV must be allocated out of > > "safe" ranges - i.e. those ranges that cannot be allocated for top-level TLVs. > > > > But when I look at the early allocations done in the registry (and presumably > > agreed by the authors) I see something completely different. What I see there > > is > > that the Reply Path TLV can carry as its own sub-TLVs those sub-TLVs that can > > be > > carried as sub-TLVs of the Target FEC Stack top-level TLV. > > > > So, I *think* what you are asking for is: > > 1. A new top-level LSP Ping TLV called "Reply Path TLV" > > Early allocation has assigned this value 21 > > 2. The ability to carry any sub-TLV of the Target FEC Stack > > top-level TLV as a sub-TLV of the Reply Path TLV > > 3. A way to "lock step" the two sub-TLV registries so that > > new sub-TLVs that can be carried in the Target FEC Stack > > TLV can also be carried in the Reply Path TLV > > 4. A way to create and register sub-TLVs that are only to > > be used in the Reply Path TLV and are not to be carried in > > the Target FEC Stack TLV > > > > All of this has nothing to do with 4379 allocation polices or ranges applied to > > the top-level TLV registry. > > > > If this is what we are trying to do, then: > > - we can delete the sections of text talking about TLV allocation > > policies > > - we can introduce some text instructing IANA to lock-step the > > registries of sub-TLVs > > - we can work out a policy that allows values used as sub-TLVs of > > the Target FEC Stack TLV to be reserved so that they do not conflict > > with allocations for sub-TLVs of the Reply Path TLV > > > > So, step 1: please confirm that I have now (finally) understood what it is > > you're trying to achieve. > > > > Sorry it has taken me so long to understand. Hopefully we can resolve this > > quickly from here on in. > > > > Regards, > > Adrian > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From ietfc@btconnect.com Tue Oct 23 05:06:28 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E6421F86FE for ; Tue, 23 Oct 2012 05:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.826 X-Spam-Level: X-Spam-Status: No, score=-4.826 tagged_above=-999 required=5 tests=[AWL=1.773, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n05w+Ml1t628 for ; Tue, 23 Oct 2012 05:06:28 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id C8FAB21F86F6 for ; Tue, 23 Oct 2012 05:06:27 -0700 (PDT) Received: from mail265-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 23 Oct 2012 12:06:27 +0000 Received: from mail265-tx2 (localhost [127.0.0.1]) by mail265-tx2-R.bigfish.com (Postfix) with ESMTP id 165D41B80128; Tue, 23 Oct 2012 12:06:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zzbb2dI98dI9371I936eI542M1432I4015Izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h946hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h304l1155h) Received: from mail265-tx2 (localhost.localdomain [127.0.0.1]) by mail265-tx2 (MessageSwitch) id 1350993984576879_6050; Tue, 23 Oct 2012 12:06:24 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.252]) by mail265-tx2.bigfish.com (Postfix) with ESMTP id 881331C00045; Tue, 23 Oct 2012 12:06:24 +0000 (UTC) Received: from AMSPRD0710HT005.eurprd07.prod.outlook.com (157.56.249.85) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 23 Oct 2012 12:06:24 +0000 Received: from DBXPRD0610HT001.eurprd06.prod.outlook.com (157.56.252.181) by pod51017.outlook.com (10.255.160.168) with Microsoft SMTP Server (TLS) id 14.16.224.5; Tue, 23 Oct 2012 12:06:22 +0000 Message-ID: <014401cdb116$c562dd40$4001a8c0@gateway.2wire.net> From: t.petch To: , Eric Gray References: <4FC58D13.6050803@pi.nu><50856380.5000809@cisco.com><48E1A67CB9CA044EADFEAB87D814BFF6FB40@EUSAAMB107.ericsson.se> <50857C2E.9030005@cisco.com> Date: Tue, 23 Oct 2012 13:05:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org, mpls@ietf.org, MPLS-TP ad hoc team Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 12:06:29 -0000 ----- Original Message ----- From: "Stewart Bryant" To: "Eric Gray" Cc: ; ; "MPLS-TP ad hoc team" Sent: Monday, October 22, 2012 6:02 PM Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts Hi Eric Early allocation is a well known process and IANA annotate the registry entry accordingly. In particular they set a death date for the allocation and this is visible in the registry. All as decribed in RFC4020. Interestingly, that specifies that " IANA makes an allocation from the appropriate registry, marking it as "temporary", valid for a period of one year from the date of allocation. The date of allocation should also be recorded in the registry and made visible to the public." and " In particular, it is not IANA's responsibility to track the status of allocations, their expiration, or when they may be re-allocated. " What you can see, in, for example, the MPLS registries, is "TEMPORARY - expires 2012-01-20" so IANA have not exactly put in the date of allocation, but equally, it is not up to them to take any further action. Tom Petch Stewart On 22/10/2012 17:08, Eric Gray wrote: > > Stewart, > > On the IANA allocation, this is a subtle issue, but is unlikely to be > a problem. > > As you know, IANA is occasionally asked to pre-allocate code points. This > > process =96 as I understand it =96 is different from an actual allocati= on > in that (AFAIK) > > the allocation is not actually made in the registry but is reserved in > IANA's notes > > somewhere. > > Should it be made clear which case this allocation is? I suspect that IANA > > can figure that out, though, so it is not a big deal=85 > > -- > > Eric > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Monday, October 22, 2012 11:17 AM > *To:* Eric Gray > *Cc:* Loa Andersson; > draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org; mpls@ietf.org; > MPLS-TP ad hoc team > *Subject:* Re: [mpls] wg last call on gach-adv and ethernet-addressing > drafts > *Importance:* High > > On 08/06/2012 22:16, Eric Gray wrote: > > > > > > My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01 > > > > In general, this draft is nearly ready for publishing as an RFC. > > There are issues the working group and authors should consider. > > > > Major Issue: > > > > This is listed here because I am uncertain of the degree to which > > this may be a major or minor issue. > > > > The issue is with the inclusion of MTU as a discoverable parameter > > (Section 4). > > > > One reason for using a protocol other than LLDP to discover the > > Ethernet MAC address of an adjacent LSR, is where a physical link > > may include one or more intermediate bridges. > > > > If this is the case, and LLDP is not in use, then the MTU of the > > Ethernet end-stations (the peer/adjacent LSRs) may not be useful, > > since the intervening bridges could conceivably have a lower MTU. > > Well, there may be pt-pt Ethernet switches, but there should > never be an Ethernet bridge in an MPLS-TP path, since > MPLS-TP is defined to be non-merging. > > MTU may be useful on a PT-PT direct link, but I am not sure > what can be done in the other case other than to use the MTU > field as an upper bound in an MTU discovery process. > > We could define an MTU discovery/verification application > at a later date if this was needed. > > > > > Minor Issues: > > IANA Considerations - > > Why do the authors create yet another registry for IANA to maintain, > instead of using TLVs (with type numbers taken from the regitry that > was created in the GAP specification - from which this draft already > takes a new application identifier)? > > That is the design we have proposed - one registry per application. > Note the T size is 256, and thus we would need sub-TLVs if we > did not do that, and the sub-TLVs would need their own registries > so this is awash. > > > > This appears to set a very nasty precedent: each new application ID > specified from an IANA registry may establish a new registry. Does > IANA have the head-room for this? > > I think IANA will be fine with this. They will comment at IETF LC > if there is a problem, but I don't anticipate any issue. > > > > NITs: > > IANA Considerations - > > Not sure why section 6.1 is included. There is no action required > of IANA here, AFAICT. Minimally, the authors should explicitly > state that no further action is required from IANA by this section. > > It provides traceability back to this RFC. > > It says " IANA has allocated..." so IANA will see they have no actions. > > - Stewart > > > > -- > Eric Gray > > > > -----Original Message----- > From:mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, May 29, 2012 11:00 PM > To:mpls@ietf.org ; MPLS-TP ad hoc team > Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts > > Working Group, > > > This is to start a two week working group last call on two drafts: > > - draft-ietf-mpls-gach-adv-02; and > - draft-ietf-mpls-tp-ethernet-addressing-01 > > Please send comments to the mpls working group list. > > The working group last call ends June 15, 2012. > > > Thanks, Loa > > (as MPLS WG co-chair) > > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From stbryant@cisco.com Tue Oct 23 06:11:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A5C21F86F3 for ; Tue, 23 Oct 2012 06:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.272 X-Spam-Level: X-Spam-Status: No, score=-110.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pquc7iO1mcWp for ; Tue, 23 Oct 2012 06:11:54 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AACF621F86FA for ; Tue, 23 Oct 2012 06:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6805; q=dns/txt; s=iport; t=1350997913; x=1352207513; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fvXNKfT5/xwDzSnBR+AW2AV80MNTtV7+R2fCu1FE6fk=; b=U21RXTME+QtYhX8J6rFiRdaD18wZrL8/Fl43hgHd3rselir9YXj548Ve glRVN8ZdhI1vDVFbg6jVtJWvHEmbz7g/T5yMLVJs+69jPAzlq+jnTszgt dAXWxGDKV0dXtL/Ci17zlvCSEE/s5j2nioUlePZ+J7w25xt9pMLW7Exci U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAM6WhlCQ/khM/2dsb2JhbABEwWWBCIIeAQEBBAEBAQ8BAh0BBTYKAQwECxEEAQEBCRYIBwkDAgECARUBHgkIBg0BBQIBAR6HYgucJ4NOEIt+kDqLX4ZeA5NEgi2FZIhqgQZlgnCBWSQ X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="77684592" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 23 Oct 2012 13:11:52 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9NDBq0q021661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2012 13:11:52 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9NDBmNL014973; Tue, 23 Oct 2012 14:11:49 +0100 (BST) Message-ID: <50869794.9070001@cisco.com> Date: Tue, 23 Oct 2012 14:11:48 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "t.petch" References: <4FC58D13.6050803@pi.nu><50856380.5000809@cisco.com><48E1A67CB9CA044EADFEAB87D814BFF6FB40@EUSAAMB107.ericsson.se> <50857C2E.9030005@cisco.com> <014401cdb116$c562dd40$4001a8c0@gateway.2wire.net> In-Reply-To: <014401cdb116$c562dd40$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org, mpls@ietf.org, MPLS-TP ad hoc team Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 13:11:55 -0000 Yes, IANA record the death date and it is up to the WGC to extend that. One extension is allowed and then the allocation is supposed to expire. My practical experience however is that the IETF "does the right thing" when it comes to deployed expired early allocations. Stewart On 23/10/2012 13:05, t.petch wrote: > ----- Original Message ----- > From: "Stewart Bryant" > To: "Eric Gray" > Cc: ; > ; "MPLS-TP ad hoc team" > Sent: Monday, October 22, 2012 6:02 PM > Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing > drafts > > > Hi Eric > > Early allocation is a well known process and IANA annotate the > registry entry accordingly. > > In particular they set a death date for the allocation and > this is visible in the registry. > > > > All as decribed in RFC4020. Interestingly, that specifies that > " IANA makes an allocation from the appropriate registry, marking it > as "temporary", valid for a period of one year from the date of > allocation. The date of allocation should also be recorded in the > registry and made visible to the public." > and > " In particular, it is not IANA's responsibility to track the status > of > allocations, their expiration, or when they may be re-allocated. > " > > What you can see, in, for example, the MPLS registries, is > "TEMPORARY - expires 2012-01-20" > so IANA have not exactly put in the date of allocation, but equally, it > is not up to them to take any further action. > > Tom Petch > > > > > > > Stewart > > > > On 22/10/2012 17:08, Eric Gray wrote: >> Stewart, >> >> On the IANA allocation, this is a subtle issue, but is unlikely to be >> a problem. >> >> As you know, IANA is occasionally asked to pre-allocate code points. > This >> process – as I understand it – is different from an actual allocation >> in that (AFAIK) >> >> the allocation is not actually made in the registry but is reserved in >> IANA's notes >> >> somewhere. >> >> Should it be made clear which case this allocation is? I suspect that > IANA >> can figure that out, though, so it is not a big deal… >> >> -- >> >> Eric >> >> *From:*Stewart Bryant [mailto:stbryant@cisco.com] >> *Sent:* Monday, October 22, 2012 11:17 AM >> *To:* Eric Gray >> *Cc:* Loa Andersson; >> draft-ietf-mpls-tp-ethernet-addressing@tools.iet.org; mpls@ietf.org; >> MPLS-TP ad hoc team >> *Subject:* Re: [mpls] wg last call on gach-adv and ethernet-addressing >> drafts >> *Importance:* High >> >> On 08/06/2012 22:16, Eric Gray wrote: >> >> >> >> >> >> My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01 >> >> >> >> In general, this draft is nearly ready for publishing as an RFC. >> >> There are issues the working group and authors should consider. >> >> >> >> Major Issue: >> >> >> >> This is listed here because I am uncertain of the degree to which >> >> this may be a major or minor issue. >> >> >> >> The issue is with the inclusion of MTU as a discoverable parameter >> >> (Section 4). >> >> >> >> One reason for using a protocol other than LLDP to discover the >> >> Ethernet MAC address of an adjacent LSR, is where a physical link >> >> may include one or more intermediate bridges. >> >> >> >> If this is the case, and LLDP is not in use, then the MTU of the >> >> Ethernet end-stations (the peer/adjacent LSRs) may not be useful, >> >> since the intervening bridges could conceivably have a lower MTU. >> >> Well, there may be pt-pt Ethernet switches, but there should >> never be an Ethernet bridge in an MPLS-TP path, since >> MPLS-TP is defined to be non-merging. >> >> MTU may be useful on a PT-PT direct link, but I am not sure >> what can be done in the other case other than to use the MTU >> field as an upper bound in an MTU discovery process. >> >> We could define an MTU discovery/verification application >> at a later date if this was needed. >> >> >> >> >> Minor Issues: >> >> IANA Considerations - >> >> Why do the authors create yet another registry for IANA to maintain, >> instead of using TLVs (with type numbers taken from the regitry that >> was created in the GAP specification - from which this draft already >> takes a new application identifier)? >> >> That is the design we have proposed - one registry per application. >> Note the T size is 256, and thus we would need sub-TLVs if we >> did not do that, and the sub-TLVs would need their own registries >> so this is awash. >> >> >> >> This appears to set a very nasty precedent: each new application ID >> specified from an IANA registry may establish a new registry. Does >> IANA have the head-room for this? >> >> I think IANA will be fine with this. They will comment at IETF LC >> if there is a problem, but I don't anticipate any issue. >> >> >> >> NITs: >> >> IANA Considerations - >> >> Not sure why section 6.1 is included. There is no action required >> of IANA here, AFAICT. Minimally, the authors should explicitly >> state that no further action is required from IANA by this section. >> >> It provides traceability back to this RFC. >> >> It says " IANA has allocated..." so IANA will see they have no > actions. >> - Stewart >> >> >> >> -- >> Eric Gray >> >> >> >> -----Original Message----- >> From:mpls-bounces@ietf.org > [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Tuesday, May 29, 2012 11:00 PM >> To:mpls@ietf.org ; MPLS-TP ad hoc team >> Subject: [mpls] wg last call on gach-adv and ethernet-addressing > drafts >> Working Group, >> >> >> This is to start a two week working group last call on two drafts: >> >> - draft-ietf-mpls-gach-adv-02; and >> - draft-ietf-mpls-tp-ethernet-addressing-01 >> >> Please send comments to the mpls working group list. >> >> The working group last call ends June 15, 2012. >> >> >> Thanks, Loa >> >> (as MPLS WG co-chair) >> >> >> >> >> >> -- >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From quintin.zhao@huawei.com Tue Oct 23 13:31:03 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0FB1F0C91 for ; Tue, 23 Oct 2012 13:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2Tjd6Ba4mJ8 for ; Tue, 23 Oct 2012 13:31:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E3ADF1F0424 for ; Tue, 23 Oct 2012 13:31:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKW52171; Tue, 23 Oct 2012 20:31:02 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 21:29:11 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 21:29:18 +0100 Received: from QZHAO (10.212.245.109) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.323.3; Tue, 23 Oct 2012 13:29:13 -0700 From: Quintin Zhao To: Date: Tue, 23 Oct 2012 16:29:44 -0400 Message-ID: <011e01cdb15d$24343ad0$6c9cb070$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011F_01CDB13B.9D229AD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2xXSMdTQGDoDzRR+28/v6ZSKNYfg== Content-Language: zh-cn X-Originating-IP: [10.212.245.109] X-CFilter-Loop: Reflected Subject: [mpls] draft-ietf-mpls-ldp-multi-topology-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 20:31:03 -0000 ------=_NextPart_000_011F_01CDB13B.9D229AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear WG, We submitted a new version of our draft: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-05. A summary of updates is provided below: - Addressed OAM issue raised by Pranjal. Out solution is to define two new FEC types for LSP ping. - Added a section on Operation Considerations. - Fixed minor NITS and formatting. The authors believe the document is now stable and would request that those interested in the work review the document so we can prepare for WG Last Call. Unless we see objections we also plan to move the Appendix, which covers use cases, into the MT LDP Applicability draft. Thanks, Quintin. ------=_NextPart_000_011F_01CDB13B.9D229AD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG, =

 

We submitted a new version of our draft: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-05. A = summary of updates is provided below:

 

- Addressed OAM issue raised by = Pranjal. Out solution is to define two new FEC types for LSP = ping.

- = Added a section on Operation Considerations.

- Fixed minor NITS and formatting. =

 

The authors believe the document is now stable and would = request that those interested in the work review the document so we can = prepare for WG Last Call. Unless we see objections we also plan to move = the Appendix, which covers use cases, into the MT LDP Applicability = draft.

 

Thanks,

Quintin.

 

------=_NextPart_000_011F_01CDB13B.9D229AD0-- From iesg-secretary@ietf.org Tue Oct 23 14:48:33 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1455211E80BF; Tue, 23 Oct 2012 14:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H35V6OnD3KFF; Tue, 23 Oct 2012 14:48:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD8F1F0424; Tue, 23 Oct 2012 14:48:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121023214832.24631.12973.idtracker@ietfa.amsl.com> Date: Tue, 23 Oct 2012 14:48:32 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint- to-Multipoint Label Switched Paths) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 21:48:33 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint- to-Multipoint Label Switched Paths' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), needs to pass through an MPLS domain in which Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- Multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. This document describes procedures how IP multicast trees are spliced together with multipoint LSPs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-in-band-signaling/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-in-band-signaling/ballot/ No IPR declarations have been submitted directly on this I-D. However, an IPR declaration against draft-wijnands-mpls-mldp-in-band-signaling that this I-D replaced can be seen at: https://datatracker.ietf.org/ipr/1305/ From ietfc@btconnect.com Wed Oct 24 02:58:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132CA21F8A6A for ; Wed, 24 Oct 2012 02:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=-1.331, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMHytAtUtcHH for ; Wed, 24 Oct 2012 02:58:10 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (unknown [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 940FA21F8A34 for ; Wed, 24 Oct 2012 02:58:10 -0700 (PDT) Received: from mail81-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.23; Wed, 24 Oct 2012 09:58:09 +0000 Received: from mail81-co9 (localhost [127.0.0.1]) by mail81-co9-R.bigfish.com (Postfix) with ESMTP id 896601E00DC; Wed, 24 Oct 2012 09:58:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371I542M1432I4015Izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h304l1155h) Received: from mail81-co9 (localhost.localdomain [127.0.0.1]) by mail81-co9 (MessageSwitch) id 1351072688489916_8662; Wed, 24 Oct 2012 09:58:08 +0000 (UTC) Received: from CO9EHSMHS026.bigfish.com (unknown [10.236.132.246]) by mail81-co9.bigfish.com (Postfix) with ESMTP id 7510880049; Wed, 24 Oct 2012 09:58:08 +0000 (UTC) Received: from AMSPRD0710HT003.eurprd07.prod.outlook.com (157.56.249.85) by CO9EHSMHS026.bigfish.com (10.236.130.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 24 Oct 2012 09:58:08 +0000 Received: from AMSPRD0610HT001.eurprd06.prod.outlook.com (157.56.248.85) by pod51017.outlook.com (10.255.160.166) with Microsoft SMTP Server (TLS) id 14.16.224.5; Wed, 24 Oct 2012 09:58:06 +0000 Message-ID: <016c01cdb1ce$03e17920$4001a8c0@gateway.2wire.net> From: t.petch To: Quintin Zhao , References: <011e01cdb15d$24343ad0$6c9cb070$@zhao@huawei.com> Date: Wed, 24 Oct 2012 10:57:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.85] X-OriginatorOrg: btconnect.com Subject: Re: [mpls] draft-ietf-mpls-ldp-multi-topology-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 09:58:11 -0000 ----- Original Message ----- From: "Quintin Zhao" To: Sent: Tuesday, October 23, 2012 9:29 PM > Dear WG, > > We submitted a new version of our draft: > http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-05. A summary > of updates is provided below: > > - Addressed OAM issue raised by Pranjal. Out solution is to define two new > FEC types for LSP ping. There is a wrinkle associated with the sub-TLVs for Type 1 TLV, namely that these get reused for other top level TLVs, such as Type 21 (reply path specified). With the benefit of hindsight, RFC4379 could have split the available numeric range of sub-TLVs into common ones, likely to be used with multiple TLVs, and TLV-specific ones, likely to be used with just one TLV; but it didn't. This topic is currently live, following the AD review of draft-ietf-mpls-return-path-specified-lsp-ping, the outcome of which could (should!) impact this I-D; do your new sub-TLVs apply solely to Type 1 TLV or also to the others which 'inherit' the sub-TLVs of Type 1, such as Type 21?. Tom Petch > - Added a section on Operation Considerations. > > - Fixed minor NITS and formatting. > > > > The authors believe the document is now stable and would request that those > interested in the work review the document so we can prepare for WG Last > Call. Unless we see objections we also plan to move the Appendix, which > covers use cases, into the MT LDP Applicability draft. > > Thanks, > > Quintin. > From loa@pi.nu Wed Oct 24 03:13:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D800521F8941 for ; Wed, 24 Oct 2012 03:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZprzjTqxOaTU for ; Wed, 24 Oct 2012 03:13:10 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id ADDB221F8940 for ; Wed, 24 Oct 2012 03:13:08 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 911F7824B6; Wed, 24 Oct 2012 12:13:04 +0200 (CEST) Message-ID: <5087BF31.2020605@pi.nu> Date: Wed, 24 Oct 2012 12:13:05 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:13:11 -0000 Working Group, the decreasing number of "reserved labels" has been of concern for some time. draft-kompella-mpls-special-purpose-labels-01 proposes a way to increase the the number of special purpose labels. We propose to take the current label 15 and use it as an extension label, i.e. any label that follows label 15 should be interpreted as belonging to the new "extension registry" that we propose. We also propose changing the name of the special purpose labels from "reserved labels" to "special purpose labels"; the main reason here is that in the IANA registries "reserved" has an another meaning. Please review the draft and comment to the list. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wwwrun@rfc-editor.org Wed Oct 24 03:31:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC20821F886A for ; Wed, 24 Oct 2012 03:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtUWOwube5el for ; Wed, 24 Oct 2012 03:31:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6544521F885A for ; Wed, 24 Oct 2012 03:31:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2FC9D72E038; Wed, 24 Oct 2012 03:25:23 -0700 (PDT) To: nurit.sprecher@nsn.com, lufang@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20121024102523.2FC9D72E038@rfc-editor.org> Date: Wed, 24 Oct 2012 03:25:23 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC6669 (3392) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:31:05 -0000 The following errata report has been submitted for RFC6669, "An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6669&eid=3392 -------------------------------------- Type: Editorial Reported by: Nurit Sprecher Section: 4 Original Text ------------- +------------------------+---------------------------------+---------+ | Lock Instruct (LI) | (1) G-ACh-based Loopback, |[RFC6426]| | | (2) Lock Instruct (LI) | | +------------------------+---------------------------------+---------+ | Lock Report (LKR) | Flag in AIS message |[RFC6426]| Corrected Text -------------- +------------------------+---------------------------------+--------+ | Diagnostic: Loopback | (1) G-ACh based Loopback and | [RFC | | and Lock Instruct | Lock Instruct, (2) LSP Ping | 6435] | +------------------------+---------------------------------+--------+ | Lock Instruct(LI) | Flag in MPLS Fault Management | [RFC | | | message | 6427] | Notes ----- The RFC numbers were correct in version latest draft version (9), and obviously it is an editing mistake. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6669 (draft-ietf-mpls-tp-oam-analysis-09) -------------------------------------- Title : An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks Publication Date : July 2012 Author(s) : N. Sprecher, L. Fang Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nurit.sprecher@nsn.com Wed Oct 24 03:47:54 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE0C21F8B14 for ; Wed, 24 Oct 2012 03:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.357 X-Spam-Level: X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTFgo41aA9LP for ; Wed, 24 Oct 2012 03:47:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E2BE421F8B75 for ; Wed, 24 Oct 2012 03:47:52 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q9OAljWW010711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Oct 2012 12:47:45 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9OAlbTA026005; Wed, 24 Oct 2012 12:47:42 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Oct 2012 12:47:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2012 12:47:34 +0200 Message-ID: In-Reply-To: <20121024102523.2FC9D72E038@rfc-editor.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Editorial Errata Reported] RFC6669 (3392) Thread-Index: Ac2x0rJi0PAsgmb7S1+6Y7ht3g/39gAAjG5w References: <20121024102523.2FC9D72E038@rfc-editor.org> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext RFC Errata System" , , , , , , X-OriginalArrivalTime: 24 Oct 2012 10:47:35.0703 (UTC) FILETIME=[FA790270:01CDB1D4] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3289 X-purgate-ID: 151667::1351075667-000048BF-E02224E4/0-0/0-0 Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC6669 (3392) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:47:54 -0000 Hello, I had an error in the report (:-().... The corrected text should be as follow:=20 +------------------------+---------------------------------+---------+ | Lock Instruct (LI) | (1) G-ACh-based Loopback, |[RFC6435]| | | (2) Lock Instruct (LI) | | +------------------------+---------------------------------+---------+ | Lock Report (LKR) | Flag in MPLS Fault Management |[RFC6427]| | | message | | Best regards, Nurit -----Original Message----- From: ext RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Wednesday, October 24, 2012 12:25 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); lufang@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; rcallon@juniper.net Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls@ietf.org; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC6669 (3392) The following errata report has been submitted for RFC6669, "An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6669&eid=3D3392 -------------------------------------- Type: Editorial Reported by: Nurit Sprecher Section: 4 Original Text ------------- +------------------------+---------------------------------+---------+ | Lock Instruct (LI) | (1) G-ACh-based Loopback, |[RFC6426]| | | (2) Lock Instruct (LI) | | +------------------------+---------------------------------+---------+ | Lock Report (LKR) | Flag in AIS message |[RFC6426]| Corrected Text -------------- +------------------------+---------------------------------+--------+ | Diagnostic: Loopback | (1) G-ACh based Loopback and | [RFC | | and Lock Instruct | Lock Instruct, (2) LSP Ping | 6435] | +------------------------+---------------------------------+--------+ | Lock Instruct(LI) | Flag in MPLS Fault Management | [RFC | | | message | 6427] | Notes ----- The RFC numbers were correct in version latest draft version (9), and obviously it is an editing mistake. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC6669 (draft-ietf-mpls-tp-oam-analysis-09) -------------------------------------- Title : An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks Publication Date : July 2012 Author(s) : N. Sprecher, L. Fang Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From adrian@olddog.co.uk Wed Oct 24 08:20:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF3621F8B6C for ; Wed, 24 Oct 2012 08:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM2JgZs5p386 for ; Wed, 24 Oct 2012 08:20:10 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 03B6821F88A7 for ; Wed, 24 Oct 2012 08:20:09 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9OFK8Pl018653 for ; Wed, 24 Oct 2012 16:20:08 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9OFK6nI018596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 24 Oct 2012 16:20:07 +0100 From: "Adrian Farrel" To: References: <20121024102523.2FC9D72E038@rfc-editor.org> In-Reply-To: <20121024102523.2FC9D72E038@rfc-editor.org> Date: Wed, 24 Oct 2012 16:20:05 +0100 Message-ID: <12a001cdb1fb$0c287ca0$247975e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHT+D4Xc1gYExVkgAT3QfEbqc6qxJe8BTSw Content-Language: en-gb Subject: Re: [mpls] [Editorial Errata Reported] RFC6669 (3392) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 15:20:11 -0000 Hi, Nurit reported to me that she had made a mistake in entering the correct details in the Errata system. I have fixed the report which you can see at http://www.rfc-editor.org/errata_search.php?rfc=6669&eid=3392 I believe the report is correct and plan to approve it. Comments welcome. Adrian > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 24 October 2012 11:25 > To: nurit.sprecher@nsn.com; lufang@cisco.com; stbryant@cisco.com; > adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; rcallon@juniper.net > Cc: nurit.sprecher@nsn.com; mpls@ietf.org; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC6669 (3392) > > > The following errata report has been submitted for RFC6669, > "An Overview of the Operations, Administration, and Maintenance (OAM) > Toolset for MPLS-Based Transport Networks". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6669&eid=3392 > > -------------------------------------- > Type: Editorial > Reported by: Nurit Sprecher > > Section: 4 > > Original Text > ------------- > +------------------------+---------------------------------+---------+ > | Lock Instruct (LI) | (1) G-ACh-based Loopback, |[RFC6426]| > | | (2) Lock Instruct (LI) | | > +------------------------+---------------------------------+---------+ > | Lock Report (LKR) | Flag in AIS message |[RFC6426]| > > > Corrected Text > -------------- > +------------------------+---------------------------------+--------+ > | Diagnostic: Loopback | (1) G-ACh based Loopback and | [RFC | > | and Lock Instruct | Lock Instruct, (2) LSP Ping | 6435] | > +------------------------+---------------------------------+--------+ > | Lock Instruct(LI) | Flag in MPLS Fault Management | [RFC | > | | message | 6427] | > > > Notes > ----- > The RFC numbers were correct in version latest draft version (9), and obviously it > is an editing mistake. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6669 (draft-ietf-mpls-tp-oam-analysis-09) > -------------------------------------- > Title : An Overview of the Operations, Administration, and Maintenance > (OAM) Toolset for MPLS-Based Transport Networks > Publication Date : July 2012 > Author(s) : N. Sprecher, L. Fang > Category : INFORMATIONAL > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG From agmalis@gmail.com Wed Oct 24 08:30:50 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D93B21F867A for ; Wed, 24 Oct 2012 08:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WWd7dVmTb2Z for ; Wed, 24 Oct 2012 08:30:49 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C1A5421F8609 for ; Wed, 24 Oct 2012 08:30:49 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so998879iec.31 for ; Wed, 24 Oct 2012 08:30:49 -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=QRm8mtKYgayhqeWCOUwzw9jCA+I1r/8LPUn2ZBHkaw8=; b=rmDCEU8WLw0WYb4uyGfPVwEnIUCSbjGBcSI8vKUlHq4pIa+OUiKZ6rBkx9WAehJ9qy cu4lEnj0Lre0eSWCwLbdnaj5QxiIa1uUOUpdRRw0Ip8zmyTTxkFRprVimVsnQn/Q4iJM oP8jRwa4RRl6wV6hYi8eQadcLfiQSXePL7kmhD+LEgvwO0NUflIxJEfXeBNJR8CBbBWV jWR3xRO77l/v6zitZ9xiWsRclfrs/7rO6HR6XzHE6miw80w1eXlaPdeOGX1rnYRdmCmZ QP2HoiTx12/cXtRzCrZFm49MRg6VM9dN7MV8YyNbq7mCDWwDEkUOyigELBw3Wkt8xPkB LyXQ== Received: by 10.50.13.133 with SMTP id h5mr2927533igc.2.1351092649207; Wed, 24 Oct 2012 08:30:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.35.195 with HTTP; Wed, 24 Oct 2012 08:30:28 -0700 (PDT) In-Reply-To: <5087BF31.2020605@pi.nu> References: <5087BF31.2020605@pi.nu> From: "Andrew G. Malis" Date: Wed, 24 Oct 2012 11:30:28 -0400 Message-ID: To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 15:30:50 -0000 On the whole, it looks good. I'm curious who's going to have the responsibility of running the process in section 3.2. IANA? (probably not). The WG chairs? What if there's no longer an MPLS working group at some point? This should be clarified. Thanks, Andy On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > Working Group, > > the decreasing number of "reserved labels" has been of concern > for some time. draft-kompella-mpls-special-purpose-labels-01 proposes > a way to increase the the number of special purpose labels. > > We propose to take the current label 15 and use it as an extension > label, i.e. any label that follows label 15 should be interpreted > as belonging to the new "extension registry" that we propose. > > We also propose changing the name of the special purpose labels > from "reserved labels" to "special purpose labels"; the main reason here > is that in the IANA registries "reserved" has an another meaning. > > Please review the draft and comment to the list. > > /Loa > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Wed Oct 24 08:43:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A22521F8BB4 for ; Wed, 24 Oct 2012 08:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC6WoCILk-1m for ; Wed, 24 Oct 2012 08:43:51 -0700 (PDT) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 84ED421F8BB0 for ; Wed, 24 Oct 2012 08:43:51 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id BDD1882475; Wed, 24 Oct 2012 17:43:47 +0200 (CEST) Message-ID: <50880CB4.9000708@pi.nu> Date: Wed, 24 Oct 2012 17:43:48 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Andrew G. Malis" References: <5087BF31.2020605@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 15:43:52 -0000 Andy, this is in the category "good questions", when Scott Bradner were our AD he always said that there should be a "caretaker" appointed when a wg is closed But I don't know if this has been done consistently. /Loa On 2012-10-24 17:30, Andrew G. Malis wrote: > On the whole, it looks good. I'm curious who's going to have the > responsibility of running the process in section 3.2. IANA? (probably > not). The WG chairs? What if there's no longer an MPLS working group > at some point? This should be clarified. > > Thanks, > Andy > > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: >> Working Group, >> >> the decreasing number of "reserved labels" has been of concern >> for some time. draft-kompella-mpls-special-purpose-labels-01 proposes >> a way to increase the the number of special purpose labels. >> >> We propose to take the current label 15 and use it as an extension >> label, i.e. any label that follows label 15 should be interpreted >> as belonging to the new "extension registry" that we propose. >> >> We also propose changing the name of the special purpose labels >> from "reserved labels" to "special purpose labels"; the main reason here >> is that in the IANA registries "reserved" has an another meaning. >> >> Please review the draft and comment to the list. >> >> /Loa >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From adrian@olddog.co.uk Wed Oct 24 10:08:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183EB21F84C1 for ; Wed, 24 Oct 2012 10:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqPsdL+JeXka for ; Wed, 24 Oct 2012 10:08:35 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 23EAA21F847D for ; Wed, 24 Oct 2012 10:08:34 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9OH8Xc9016110; Wed, 24 Oct 2012 18:08:34 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9OH8W1n016093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Oct 2012 18:08:33 +0100 From: "Adrian Farrel" To: Date: Wed, 24 Oct 2012 18:08:31 +0100 Message-ID: <12d901cdb20a$320b7080$96225180$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2yCZaiIJ3hAzVlTta7u8lrdeOypg== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-ipv6-pw-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 17:08:36 -0000 Thanks for this document. I have done my usual AD review and have nothing to add except for some minor comments on the IANA section. If you could make an update that would be very helpful. You do not need to wait for the submission gates to reopen on 5th November. If you send me the file(s) for submission I will get the Secretariat to post them. Thanks, Adrian --- Section 6 It appears you are asking to *replace* the pointer to RFC 4379 for the three IPv4 sub-TLVs. I don't think you should do that because they are defined in 4379. So add the word "also". OLD Update the names of the Value fields of these three Sub-TLVs, adding the "IPv4" qualifier (see Section 2), and update the Reference to point to this document: NEW Update the names of the Value fields of these three Sub-TLVs, adding the "IPv4" qualifier (see Section 2), and update the Reference to also point to this document: END --- Section 6 usefully calls out TBD1 and TBD2, but the rest of the document uniformly uses TBD. If you could update to always use TBD1 and TBD2 this will ensure that the RFC Editor works with IANA to get this right. --- In Section 6, please explicitly ask IANA to make the appropriate entries in the Type 21 sub-TLVs list. From adrian@olddog.co.uk Wed Oct 24 10:39:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0FD21F8441 for ; Wed, 24 Oct 2012 10:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuK5Wmv4n973 for ; Wed, 24 Oct 2012 10:39:10 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id AE8FC21F8440 for ; Wed, 24 Oct 2012 10:39:09 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9OHd77l010777; Wed, 24 Oct 2012 18:39:07 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9OHd660010769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Oct 2012 18:39:06 +0100 From: "Adrian Farrel" To: "'Andrew G. Malis'" , "'Loa Andersson'" References: <5087BF31.2020605@pi.nu> In-Reply-To: Date: Wed, 24 Oct 2012 18:39:04 +0100 Message-ID: <12ed01cdb20e$76d46650$647d32f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCdS8Z4CqoQoOvnU9wXZTQr2mSQEwFEJz83mh9hHuA= Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 17:39:10 -0000 Hi Andy, Section 3.2 is about withdrawing reserved labels. I suspect that we will all be retired long before the MPLS WG closes down :-) However, bullet (a) of 3.2 says: A label value that has been assigned from the "Special Purpose MPLS Label Values" may be deprecated by IETF consensus with review by the MPLS working group (or designated experts if the working group or a successor does not exist). So a designated expert (appointed by the IESG as with all designated experts) will be required. If one has not been appointed at the time of retirement of the label, IANA would ask the IESG to appoint one. I think this would be the same expert(s) as for label allocation. The other steps in the process just ask for RFCs (i.e. publication requests for I-Ds) on specific tracks. I suppose that whoever wants to retire a label will write the RFCs. Did we miss any other decision points? Cheers, Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Andrew G. Malis > Sent: 24 October 2012 16:30 > To: Loa Andersson > Cc: mpls@ietf.org > Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels- > 01 > > On the whole, it looks good. I'm curious who's going to have the > responsibility of running the process in section 3.2. IANA? (probably > not). The WG chairs? What if there's no longer an MPLS working group > at some point? This should be clarified. > > Thanks, > Andy > > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > > Working Group, > > > > the decreasing number of "reserved labels" has been of concern > > for some time. draft-kompella-mpls-special-purpose-labels-01 proposes > > a way to increase the the number of special purpose labels. > > > > We propose to take the current label 15 and use it as an extension > > label, i.e. any label that follows label 15 should be interpreted > > as belonging to the new "extension registry" that we propose. > > > > We also propose changing the name of the special purpose labels > > from "reserved labels" to "special purpose labels"; the main reason here > > is that in the IANA registries "reserved" has an another meaning. > > > > Please review the draft and comment to the list. > > > > /Loa > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Internet-Drafts@ietf.org Wed Oct 24 12:27:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2A321F892A; Wed, 24 Oct 2012 12:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QivsWoYF-1DS; Wed, 24 Oct 2012 12:27:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8313A21F88EB; Wed, 24 Oct 2012 12:27:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121024192740.18372.31679.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2012 12:27:40 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 19:27:41 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs Author(s) : M. Chen, et al Filename : draft-ietf-mpls-ipv6-pw-lsp-ping Pages : 9 Date : Oct. 24, 2012 Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-ipv6-pw-lsp-ping"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-10-24122740.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Wed Oct 24 14:31:16 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF2621F8B7D; Wed, 24 Oct 2012 14:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kFwCuRIoN+j; Wed, 24 Oct 2012 14:31:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1230321F86D9; Wed, 24 Oct 2012 14:31:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121024213116.29724.2375.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2012 14:31:16 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:31:16 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ballot/ No IPR declarations have been submitted directly on this I-D. From kvivek@broadcom.com Wed Oct 24 22:36:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDB011E808D for ; Wed, 24 Oct 2012 22:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG+z7zUj-I0W for ; Wed, 24 Oct 2012 22:36:13 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id DD42E11E80A6 for ; Wed, 24 Oct 2012 22:36:12 -0700 (PDT) Received: from [10.16.192.224] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 24 Oct 2012 22:32:57 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS02.corp.ad.broadcom.com (10.16.192.37) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Wed, 24 Oct 2012 22:36:01 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by sjexchcas02.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Wed, 24 Oct 2012 22:36:00 -0700 From: "Vivek Kumar" To: "mpls@ietf.org" Thread-Topic: new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) Thread-Index: Ac2ycWyq331n4puRQOStlZqXiwKgqQ== Date: Thu, 25 Oct 2012 05:36:00 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A17F@SJEXCHMB09.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7C9610823SK3640911-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 05:36:14 -0000 Hi, Just curious on Section 3.1 statement " In particular, an arbitrary str= ing of consecutive extension labels is legal, and semantically equivalent = to a single extension label (note that this string of extension labels MUS= T be followed by an extended special purpose label that is not the extensi= on label).". Does this mean it will allow recursive extension labels like Exten-label->= Exten-label->"Standard Action label" ? Any special reason not to restrict = only one extension label in MPLS header ? Regards, Vivek =20 ---------------------------------------------------------------------- Message: 1 Date: Wed, 24 Oct 2012 11:30:28 -0400 From: "Andrew G. Malis" To: Loa Andersson Cc: "mpls@ietf.org" Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 On the whole, it looks good. I'm curious who's going to have the responsibility of running the process in section 3.2. IANA? (probably not). The WG chairs? What if there's no longer an MPLS working group at some point? This should be clarified. Thanks, Andy On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > Working Group, > > the decreasing number of "reserved labels" has been of concern > for some time. draft-kompella-mpls-special-purpose-labels-01 proposes > a way to increase the the number of special purpose labels. > > We propose to take the current label 15 and use it as an extension > label, i.e. any label that follows label 15 should be interpreted > as belonging to the new "extension registry" that we propose. > > We also propose changing the name of the special purpose labels > from "reserved labels" to "special purpose labels"; the main reason here > is that in the IANA registries "reserved" has an another meaning. > > Please review the draft and comment to the list. > > /Loa > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls ------------------------------ Message: 2 Date: Wed, 24 Oct 2012 17:43:48 +0200 From: Loa Andersson To: "Andrew G. Malis" Cc: "mpls@ietf.org" Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 Message-ID: <50880CB4.9000708@pi.nu> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Andy, this is in the category "good questions", when Scott Bradner were our AD he always said that there should be a "caretaker" appointed when a wg is closed But I don't know if this has been done consistently. /Loa On 2012-10-24 17:30, Andrew G. Malis wrote: > On the whole, it looks good. I'm curious who's going to have the > responsibility of running the process in section 3.2. IANA? (probably > not). The WG chairs? What if there's no longer an MPLS working group > at some point? This should be clarified. > > Thanks, > Andy > > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: >> Working Group, >> >> the decreasing number of "reserved labels" has been of concern >> for some time. draft-kompella-mpls-special-purpose-labels-01 proposes >> a way to increase the the number of special purpose labels. >> >> We propose to take the current label 15 and use it as an extension >> label, i.e. any label that follows label 15 should be interpreted >> as belonging to the new "extension registry" that we propose. >> >> We also propose changing the name of the special purpose labels >> from "reserved labels" to "special purpose labels"; the main reason here >> is that in the IANA registries "reserved" has an another meaning. >> >> Please review the draft and comment to the list. >> >> /Loa >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ------------------------------ Message: 3 Date: Wed, 24 Oct 2012 18:08:31 +0100 From: "Adrian Farrel" To: Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-ipv6-pw-lsp-ping Message-ID: <12d901cdb20a$320b7080$96225180$@olddog.co.uk> Content-Type: text/plain; charset=3D"us-ascii" Thanks for this document. I have done my usual AD review and have=20 nothing to add except for some minor comments on the IANA section. If you could make an update that would be very helpful. You do not need to wait for the submission gates to reopen on 5th November. If you send me the file(s) for submission I will get the Secretariat to post them. Thanks, Adrian --- Section 6 It appears you are asking to *replace* the pointer to RFC 4379 for the three IPv4 sub-TLVs. I don't think you should do that because they are defined in 4379. So add the word "also". OLD Update the names of the Value fields of these three Sub-TLVs, adding the "IPv4" qualifier (see Section 2), and update the Reference to point to this document: NEW Update the names of the Value fields of these three Sub-TLVs, adding the "IPv4" qualifier (see Section 2), and update the Reference to also point to this document: END --- Section 6 usefully calls out TBD1 and TBD2, but the rest of the document uniformly uses TBD. If you could update to always use TBD1 and TBD2 this will ensure that the RFC Editor works with IANA to get this right. --- In Section 6, please explicitly ask IANA to make the appropriate entries in the Type 21 sub-TLVs list. ------------------------------ Message: 4 Date: Wed, 24 Oct 2012 18:39:04 +0100 From: "Adrian Farrel" To: "'Andrew G. Malis'" , "'Loa Andersson'" Cc: mpls@ietf.org Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 Message-ID: <12ed01cdb20e$76d46650$647d32f0$@olddog.co.uk> Content-Type: text/plain; charset=3D"us-ascii" Hi Andy, Section 3.2 is about withdrawing reserved labels. I suspect that we will al= l be retired long before the MPLS WG closes down :-) However, bullet (a) of 3.2 says: A label value that has been assigned from the "Special Purpose MPLS Label Values" may be deprecated by IETF consensus with review by the MPLS working group (or designated experts if the working group or a successor does not exist). So a designated expert (appointed by the IESG as with all designated expert= s) will be required. If one has not been appointed at the time of retirement o= f the label, IANA would ask the IESG to appoint one. I think this would be the sa= me expert(s) as for label allocation.=20 The other steps in the process just ask for RFCs (i.e. publication requests= for I-Ds) on specific tracks. I suppose that whoever wants to retire a label wi= ll write the RFCs. Did we miss any other decision points? Cheers, Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Andrew G. Malis > Sent: 24 October 2012 16:30 > To: Loa Andersson > Cc: mpls@ietf.org > Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-lab= els- > 01 >=20 > On the whole, it looks good. I'm curious who's going to have the > responsibility of running the process in section 3.2. IANA? (probably > not). The WG chairs? What if there's no longer an MPLS working group > at some point? This should be clarified. >=20 > Thanks, > Andy >=20 > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > > Working Group, > > > > the decreasing number of "reserved labels" has been of concern > > for some time. draft-kompella-mpls-special-purpose-labels-01 proposes > > a way to increase the the number of special purpose labels. > > > > We propose to take the current label 15 and use it as an extension > > label, i.e. any label that follows label 15 should be interpreted > > as belonging to the new "extension registry" that we propose. > > > > We also propose changing the name of the special purpose labels > > from "reserved labels" to "special purpose labels"; the main reason her= e > > is that in the IANA registries "reserved" has an another meaning. > > > > Please review the draft and comment to the list. > > > > /Loa > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls ------------------------------ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls End of mpls Digest, Vol 102, Issue 53 ************************************* From adrian@olddog.co.uk Thu Oct 25 05:41:40 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6B721F8A0B for ; Thu, 25 Oct 2012 05:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp+ZQHZ+6IIH for ; Thu, 25 Oct 2012 05:41:39 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id BFBE721F8A3B for ; Thu, 25 Oct 2012 05:41:38 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9PCfWuX021775; Thu, 25 Oct 2012 13:41:32 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9PCfVLg021749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2012 13:41:32 +0100 From: "Adrian Farrel" To: "'Vivek Kumar'" , References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A17F@SJEXCHMB09.corp.ad.broadcom.com> In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A17F@SJEXCHMB09.corp.ad.broadcom.com> Date: Thu, 25 Oct 2012 13:41:29 +0100 Message-ID: <144b01cdb2ae$0e971b50$2bc551f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJTmGoQTL5Jhrfm9QxzbwdDMfnFzpa+KXXA Content-Language: en-gb Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 12:41:40 -0000 Hello, Well, we were looking for a format that would make things as hard as possible for the chip vendors :-) We wanted labels 0-15 (i.e. what are now to be called the special labels) to preserve their meaning in the extended space. Thus 15->3 has the same meaning as 3. We were not sure that this was important, but it seemed like the right thing to do. That meant that 15->15 has the same meaning as 15. And hence 15->15->3 has the same meaning as 3. I would say that the authors were not strongly wedded to this. If there was group-think that the whole extended special label range (0-1048575) should be new, we could probably live with it. Actually, a chip manufacturer could help here. Assuming that label 15 means you throw the label and look at the next one, does it make things easier or harder to find a special label value (say 3) and have one or two ways of handling it depending on whether you have just found a label 15? Cheers, Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Vivek Kumar > Sent: 25 October 2012 06:36 > To: mpls@ietf.org > Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels- > 01 (Adrian Farrel) > > Hi, > Just curious on Section 3.1 statement " In particular, an arbitrary string of > consecutive extension labels is legal, and semantically equivalent to a single > extension label (note that this string of extension labels MUST be followed by an > extended special purpose label that is not the extension label).". > > Does this mean it will allow recursive extension labels like Exten-label->Exten- > label->"Standard Action label" ? Any special reason not to restrict only one > extension label in MPLS header ? > > Regards, > Vivek > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 24 Oct 2012 11:30:28 -0400 > From: "Andrew G. Malis" > To: Loa Andersson > Cc: "mpls@ietf.org" > Subject: Re: [mpls] new published > draft-kompella-mpls-special-purpose-labels-01 > Message-ID: > B8AhGAmA@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On the whole, it looks good. I'm curious who's going to have the > responsibility of running the process in section 3.2. IANA? (probably > not). The WG chairs? What if there's no longer an MPLS working group > at some point? This should be clarified. > > Thanks, > Andy > > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > > Working Group, > > > > the decreasing number of "reserved labels" has been of concern > > for some time. draft-kompella-mpls-special-purpose-labels-01 proposes > > a way to increase the the number of special purpose labels. > > > > We propose to take the current label 15 and use it as an extension > > label, i.e. any label that follows label 15 should be interpreted > > as belonging to the new "extension registry" that we propose. > > > > We also propose changing the name of the special purpose labels > > from "reserved labels" to "special purpose labels"; the main reason here > > is that in the IANA registries "reserved" has an another meaning. > > > > Please review the draft and comment to the list. > > > > /Loa > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > ------------------------------ > > Message: 2 > Date: Wed, 24 Oct 2012 17:43:48 +0200 > From: Loa Andersson > To: "Andrew G. Malis" > Cc: "mpls@ietf.org" > Subject: Re: [mpls] new published > draft-kompella-mpls-special-purpose-labels-01 > Message-ID: <50880CB4.9000708@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Andy, > > this is in the category "good questions", when Scott Bradner were our AD > he always said that there should be a "caretaker" appointed when a wg > is closed But I don't know if this has been done consistently. > > /Loa > > On 2012-10-24 17:30, Andrew G. Malis wrote: > > On the whole, it looks good. I'm curious who's going to have the > > responsibility of running the process in section 3.2. IANA? (probably > > not). The WG chairs? What if there's no longer an MPLS working group > > at some point? This should be clarified. > > > > Thanks, > > Andy > > > > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > >> Working Group, > >> > >> the decreasing number of "reserved labels" has been of concern > >> for some time. draft-kompella-mpls-special-purpose-labels-01 proposes > >> a way to increase the the number of special purpose labels. > >> > >> We propose to take the current label 15 and use it as an extension > >> label, i.e. any label that follows label 15 should be interpreted > >> as belonging to the new "extension registry" that we propose. > >> > >> We also propose changing the name of the special purpose labels > >> from "reserved labels" to "special purpose labels"; the main reason here > >> is that in the IANA registries "reserved" has an another meaning. > >> > >> Please review the draft and comment to the list. > >> > >> /Loa > >> -- > >> > >> > >> Loa Andersson email: loa.andersson@ericsson.com > >> Sr Strategy and Standards Manager loa@pi.nu > >> Ericsson Inc phone: +46 10 717 52 13 > >> +46 767 72 92 13 > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > > > ------------------------------ > > Message: 3 > Date: Wed, 24 Oct 2012 18:08:31 +0100 > From: "Adrian Farrel" > To: > Cc: mpls@ietf.org > Subject: [mpls] AD review of draft-ietf-mpls-ipv6-pw-lsp-ping > Message-ID: <12d901cdb20a$320b7080$96225180$@olddog.co.uk> > Content-Type: text/plain; charset="us-ascii" > > Thanks for this document. I have done my usual AD review and have > nothing to add except for some minor comments on the IANA section. > If you could make an update that would be very helpful. > > You do not need to wait for the submission gates to reopen on 5th > November. If you send me the file(s) for submission I will get the > Secretariat to post them. > > Thanks, > Adrian > > --- > > Section 6 > > It appears you are asking to *replace* the pointer to RFC 4379 for the > three IPv4 sub-TLVs. I don't think you should do that because they are > defined in 4379. So add the word "also". > > OLD > Update the names of the Value fields of these three Sub-TLVs, adding > the "IPv4" qualifier (see Section 2), and update the Reference to > point to this document: > NEW > Update the names of the Value fields of these three Sub-TLVs, adding > the "IPv4" qualifier (see Section 2), and update the Reference to > also point to this document: > END > > --- > > Section 6 usefully calls out TBD1 and TBD2, but the rest of the document > uniformly uses TBD. If you could update to always use TBD1 and TBD2 this > will ensure that the RFC Editor works with IANA to get this right. > > --- > > In Section 6, please explicitly ask IANA to make the appropriate entries > in the Type 21 sub-TLVs list. > > > > ------------------------------ > > Message: 4 > Date: Wed, 24 Oct 2012 18:39:04 +0100 > From: "Adrian Farrel" > To: "'Andrew G. Malis'" , "'Loa Andersson'" > > Cc: mpls@ietf.org > Subject: Re: [mpls] new published > draft-kompella-mpls-special-purpose-labels-01 > Message-ID: <12ed01cdb20e$76d46650$647d32f0$@olddog.co.uk> > Content-Type: text/plain; charset="us-ascii" > > Hi Andy, > > Section 3.2 is about withdrawing reserved labels. I suspect that we will all be > retired long before the MPLS WG closes down :-) > > However, bullet (a) of 3.2 says: > > A label value that has been assigned from the "Special Purpose > MPLS Label Values" may be deprecated by IETF consensus with > review by the MPLS working group (or designated experts if the > working group or a successor does not exist). > > So a designated expert (appointed by the IESG as with all designated experts) > will be required. If one has not been appointed at the time of retirement of the > label, IANA would ask the IESG to appoint one. I think this would be the same > expert(s) as for label allocation. > > The other steps in the process just ask for RFCs (i.e. publication requests for > I-Ds) on specific tracks. I suppose that whoever wants to retire a label will > write the RFCs. > > Did we miss any other decision points? > > Cheers, > Adrian > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Andrew G. Malis > > Sent: 24 October 2012 16:30 > > To: Loa Andersson > > Cc: mpls@ietf.org > > Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels- > > 01 > > > > On the whole, it looks good. I'm curious who's going to have the > > responsibility of running the process in section 3.2. IANA? (probably > > not). The WG chairs? What if there's no longer an MPLS working group > > at some point? This should be clarified. > > > > Thanks, > > Andy > > > > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > > > Working Group, > > > > > > the decreasing number of "reserved labels" has been of concern > > > for some time. draft-kompella-mpls-special-purpose-labels-01 proposes > > > a way to increase the the number of special purpose labels. > > > > > > We propose to take the current label 15 and use it as an extension > > > label, i.e. any label that follows label 15 should be interpreted > > > as belonging to the new "extension registry" that we propose. > > > > > > We also propose changing the name of the special purpose labels > > > from "reserved labels" to "special purpose labels"; the main reason here > > > is that in the IANA registries "reserved" has an another meaning. > > > > > > Please review the draft and comment to the list. > > > > > > /Loa > > > -- > > > > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > > Sr Strategy and Standards Manager loa@pi.nu > > > Ericsson Inc phone: +46 10 717 52 13 > > > +46 767 72 92 13 > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > ------------------------------ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > End of mpls Digest, Vol 102, Issue 53 > ************************************* > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From agmalis@gmail.com Thu Oct 25 06:01:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360EC21F8A2C for ; Thu, 25 Oct 2012 06:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnZrTyVsmNRJ for ; Thu, 25 Oct 2012 06:01:23 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92D4E21F8A2B for ; Thu, 25 Oct 2012 06:01:23 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so2473679iec.31 for ; Thu, 25 Oct 2012 06:01:23 -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=YBSheCiU5x8Vyn3RGdA1wPjoVZqnafx2esAEtpD55Gk=; b=XOEsDPnWAe9ac9Mj+TLXlmjgvzjxJFm/7YCD9WP/4TLYsQe9CjH9dkkd6Sv5Y0m7Sk ULMAF2eqOA5NyXl/48pz2KIGPA3NRBB52rygPqMo3KDLgox+4W/HnoEJuowaE7cvN7Qm 02lGsdsiFNVHpludnHWK6dQjoKoVoCkJ6fMqEzbB+EbTtMUoTg0zcTNsrChOIfB3Arci TE5VMYNN8WNmSe358Yqbkf+sbO/gXNZZJ4UjuWSQ3dz62j5QOUSliPOP2ldhWmj9zWAo 4GeB++hJAz6jZdv44aeky4Lg6VEIv3tHtZGWxf134lY4Kib9Nv3q2TRLAYmB5HAQFRpv uMKg== Received: by 10.50.12.138 with SMTP id y10mr4232549igb.58.1351170083201; Thu, 25 Oct 2012 06:01:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.35.195 with HTTP; Thu, 25 Oct 2012 06:01:02 -0700 (PDT) In-Reply-To: <12ed01cdb20e$76d46650$647d32f0$@olddog.co.uk> References: <5087BF31.2020605@pi.nu> <12ed01cdb20e$76d46650$647d32f0$@olddog.co.uk> From: "Andrew G. Malis" Date: Thu, 25 Oct 2012 09:01:02 -0400 Message-ID: To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: mpls@ietf.org Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 13:01:24 -0000 Adrian, I was more thinking about someone having the responsibility to do steps b and c after specific amounts of time have passed. It's easy for that kind of thing to be forgotten, esp. when it's volunteer work. Cheers, Andy On Wed, Oct 24, 2012 at 1:39 PM, Adrian Farrel wrote: > Hi Andy, > > Section 3.2 is about withdrawing reserved labels. I suspect that we will all be > retired long before the MPLS WG closes down :-) > > However, bullet (a) of 3.2 says: > > A label value that has been assigned from the "Special Purpose > MPLS Label Values" may be deprecated by IETF consensus with > review by the MPLS working group (or designated experts if the > working group or a successor does not exist). > > So a designated expert (appointed by the IESG as with all designated experts) > will be required. If one has not been appointed at the time of retirement of the > label, IANA would ask the IESG to appoint one. I think this would be the same > expert(s) as for label allocation. > > The other steps in the process just ask for RFCs (i.e. publication requests for > I-Ds) on specific tracks. I suppose that whoever wants to retire a label will > write the RFCs. > > Did we miss any other decision points? > > Cheers, > Adrian > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Andrew G. Malis >> Sent: 24 October 2012 16:30 >> To: Loa Andersson >> Cc: mpls@ietf.org >> Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels- >> 01 >> >> On the whole, it looks good. I'm curious who's going to have the >> responsibility of running the process in section 3.2. IANA? (probably >> not). The WG chairs? What if there's no longer an MPLS working group >> at some point? This should be clarified. >> >> Thanks, >> Andy >> >> On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: >> > Working Group, >> > >> > the decreasing number of "reserved labels" has been of concern >> > for some time. draft-kompella-mpls-special-purpose-labels-01 proposes >> > a way to increase the the number of special purpose labels. >> > >> > We propose to take the current label 15 and use it as an extension >> > label, i.e. any label that follows label 15 should be interpreted >> > as belonging to the new "extension registry" that we propose. >> > >> > We also propose changing the name of the special purpose labels >> > from "reserved labels" to "special purpose labels"; the main reason here >> > is that in the IANA registries "reserved" has an another meaning. >> > >> > Please review the draft and comment to the list. >> > >> > /Loa >> > -- >> > >> > >> > Loa Andersson email: loa.andersson@ericsson.com >> > Sr Strategy and Standards Manager loa@pi.nu >> > Ericsson Inc phone: +46 10 717 52 13 >> > +46 767 72 92 13 >> > _______________________________________________ >> > mpls mailing list >> > mpls@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From kvivek@broadcom.com Thu Oct 25 06:11:09 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927B321F89E8 for ; Thu, 25 Oct 2012 06:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erYovZfJUsLW for ; Thu, 25 Oct 2012 06:11:08 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7303E21F89E5 for ; Thu, 25 Oct 2012 06:11:08 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 25 Oct 2012 06:09:44 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.13) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Thu, 25 Oct 2012 06:10:51 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS05.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Thu, 25 Oct 2012 06:10:51 -0700 From: "Vivek Kumar" To: "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) Thread-Index: Ac2ycWyq331n4puRQOStlZqXiwKgqQAd02OAAA4c6qA= Date: Thu, 25 Oct 2012 13:10:50 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A7BE@SJEXCHMB09.corp.ad.broadcom.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A17F@SJEXCHMB09.corp.ad.broadcom.com> <144b01cdb2ae$0e971b50$2bc551f0$@olddog.co.uk> In-Reply-To: <144b01cdb2ae$0e971b50$2bc551f0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7C97E59241411536041-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 13:11:09 -0000 Hi Adrain, Thanks for keeping us in job :)=20 Having extension approach is good idea but the recursive nature means= more possibility which result in more work for SW/HW without any extra ben= efit. Less the possibilities more deterministic the behavior . Since the idea of the draft is to expand reserved label space , having = only one extension label (15) will make things simpler. The recursive labe= l approach is not giving any additional information or scope but merely tes= ting the system if it can handle Exten-label->Exten-label-> Exten-label->Ex= ten-label ->... One more question, the new special action label range (16 - 1048559/75) nee= d to be excluded or included when doing ECMP using MPLS labels as inputs (d= raft-ietf-mpls-entropy-label-06 ) ? Regards, Vivek -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Thursday, October 25, 2012 6:11 PM To: Vivek Kumar; mpls@ietf.org Subject: RE: [mpls] new published draft-kompella-mpls-special-purpose-label= s-01 (Adrian Farrel) Hello, Well, we were looking for a format that would make things as hard as possib= le for the chip vendors :-) We wanted labels 0-15 (i.e. what are now to be called the special labels) t= o preserve their meaning in the extended space. Thus 15->3 has the same meaning as 3. We were not sure that this was important, but it seemed like the right thin= g to do. That meant that 15->15 has the same meaning as 15. And hence 15->15->3 has the same meaning as 3. I would say that the authors were not strongly wedded to this. If there was group-think that the whole extended special label range (0-1048575) should = be new, we could probably live with it. Actually, a chip manufacturer could help here. Assuming that label 15 means= you throw the label and look at the next one, does it make things easier or har= der to find a special label value (say 3) and have one or two ways of handling = it depending on whether you have just found a label 15? Cheers, Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Vivek Kumar > Sent: 25 October 2012 06:36 > To: mpls@ietf.org > Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-lab= els- > 01 (Adrian Farrel) >=20 > Hi, > Just curious on Section 3.1 statement " In particular, an arbitrary s= tring of > consecutive extension labels is legal, and semantically equivalent to a single > extension label (note that this string of extension labels MUST be follo= wed by an > extended special purpose label that is not the extension label).". >=20 > Does this mean it will allow recursive extension labels like Exten-label->Exten- > label->"Standard Action label" ? Any special reason not to restrict only= one > extension label in MPLS header ? >=20 > Regards, > Vivek >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Wed, 24 Oct 2012 11:30:28 -0400 > From: "Andrew G. Malis" > To: Loa Andersson > Cc: "mpls@ietf.org" > Subject: Re: [mpls] new published > draft-kompella-mpls-special-purpose-labels-01 > Message-ID: > B8AhGAmA@mail.gmail.com> > Content-Type: text/plain; charset=3DISO-8859-1 >=20 > On the whole, it looks good. I'm curious who's going to have the > responsibility of running the process in section 3.2. IANA? (probably > not). The WG chairs? What if there's no longer an MPLS working group > at some point? This should be clarified. >=20 > Thanks, > Andy >=20 > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > > Working Group, > > > > the decreasing number of "reserved labels" has been of concern > > for some time. draft-kompella-mpls-special-purpose-labels-01 proposes > > a way to increase the the number of special purpose labels. > > > > We propose to take the current label 15 and use it as an extension > > label, i.e. any label that follows label 15 should be interpreted > > as belonging to the new "extension registry" that we propose. > > > > We also propose changing the name of the special purpose labels > > from "reserved labels" to "special purpose labels"; the main reason her= e > > is that in the IANA registries "reserved" has an another meaning. > > > > Please review the draft and comment to the list. > > > > /Loa > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Wed, 24 Oct 2012 17:43:48 +0200 > From: Loa Andersson > To: "Andrew G. Malis" > Cc: "mpls@ietf.org" > Subject: Re: [mpls] new published > draft-kompella-mpls-special-purpose-labels-01 > Message-ID: <50880CB4.9000708@pi.nu> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > Andy, >=20 > this is in the category "good questions", when Scott Bradner were our AD > he always said that there should be a "caretaker" appointed when a wg > is closed But I don't know if this has been done consistently. >=20 > /Loa >=20 > On 2012-10-24 17:30, Andrew G. Malis wrote: > > On the whole, it looks good. I'm curious who's going to have the > > responsibility of running the process in section 3.2. IANA? (probably > > not). The WG chairs? What if there's no longer an MPLS working group > > at some point? This should be clarified. > > > > Thanks, > > Andy > > > > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > >> Working Group, > >> > >> the decreasing number of "reserved labels" has been of concern > >> for some time. draft-kompella-mpls-special-purpose-labels-01 proposes > >> a way to increase the the number of special purpose labels. > >> > >> We propose to take the current label 15 and use it as an extension > >> label, i.e. any label that follows label 15 should be interpreted > >> as belonging to the new "extension registry" that we propose. > >> > >> We also propose changing the name of the special purpose labels > >> from "reserved labels" to "special purpose labels"; the main reason he= re > >> is that in the IANA registries "reserved" has an another meaning. > >> > >> Please review the draft and comment to the list. > >> > >> /Loa > >> -- > >> > >> > >> Loa Andersson email: loa.andersson@ericsson.co= m > >> Sr Strategy and Standards Manager loa@pi.nu > >> Ericsson Inc phone: +46 10 717 52 13 > >> +46 767 72 92 13 > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls >=20 > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Wed, 24 Oct 2012 18:08:31 +0100 > From: "Adrian Farrel" > To: > Cc: mpls@ietf.org > Subject: [mpls] AD review of draft-ietf-mpls-ipv6-pw-lsp-ping > Message-ID: <12d901cdb20a$320b7080$96225180$@olddog.co.uk> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Thanks for this document. I have done my usual AD review and have > nothing to add except for some minor comments on the IANA section. > If you could make an update that would be very helpful. >=20 > You do not need to wait for the submission gates to reopen on 5th > November. If you send me the file(s) for submission I will get the > Secretariat to post them. >=20 > Thanks, > Adrian >=20 > --- >=20 > Section 6 >=20 > It appears you are asking to *replace* the pointer to RFC 4379 for the > three IPv4 sub-TLVs. I don't think you should do that because they are > defined in 4379. So add the word "also". >=20 > OLD > Update the names of the Value fields of these three Sub-TLVs, adding > the "IPv4" qualifier (see Section 2), and update the Reference to > point to this document: > NEW > Update the names of the Value fields of these three Sub-TLVs, adding > the "IPv4" qualifier (see Section 2), and update the Reference to > also point to this document: > END >=20 > --- >=20 > Section 6 usefully calls out TBD1 and TBD2, but the rest of the document > uniformly uses TBD. If you could update to always use TBD1 and TBD2 this > will ensure that the RFC Editor works with IANA to get this right. >=20 > --- >=20 > In Section 6, please explicitly ask IANA to make the appropriate entries > in the Type 21 sub-TLVs list. >=20 >=20 >=20 > ------------------------------ >=20 > Message: 4 > Date: Wed, 24 Oct 2012 18:39:04 +0100 > From: "Adrian Farrel" > To: "'Andrew G. Malis'" , "'Loa Andersson'" > > Cc: mpls@ietf.org > Subject: Re: [mpls] new published > draft-kompella-mpls-special-purpose-labels-01 > Message-ID: <12ed01cdb20e$76d46650$647d32f0$@olddog.co.uk> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi Andy, >=20 > Section 3.2 is about withdrawing reserved labels. I suspect that we will = all be > retired long before the MPLS WG closes down :-) >=20 > However, bullet (a) of 3.2 says: >=20 > A label value that has been assigned from the "Special Purpose > MPLS Label Values" may be deprecated by IETF consensus with > review by the MPLS working group (or designated experts if the > working group or a successor does not exist). >=20 > So a designated expert (appointed by the IESG as with all designated expe= rts) > will be required. If one has not been appointed at the time of retirement= of the > label, IANA would ask the IESG to appoint one. I think this would be the = same > expert(s) as for label allocation. >=20 > The other steps in the process just ask for RFCs (i.e. publication reques= ts for > I-Ds) on specific tracks. I suppose that whoever wants to retire a label = will > write the RFCs. >=20 > Did we miss any other decision points? >=20 > Cheers, > Adrian >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Andrew G. Malis > > Sent: 24 October 2012 16:30 > > To: Loa Andersson > > Cc: mpls@ietf.org > > Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels- > > 01 > > > > On the whole, it looks good. I'm curious who's going to have the > > responsibility of running the process in section 3.2. IANA? (probably > > not). The WG chairs? What if there's no longer an MPLS working group > > at some point? This should be clarified. > > > > Thanks, > > Andy > > > > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > > > Working Group, > > > > > > the decreasing number of "reserved labels" has been of concern > > > for some time. draft-kompella-mpls-special-purpose-labels-01 proposes > > > a way to increase the the number of special purpose labels. > > > > > > We propose to take the current label 15 and use it as an extension > > > label, i.e. any label that follows label 15 should be interpreted > > > as belonging to the new "extension registry" that we propose. > > > > > > We also propose changing the name of the special purpose labels > > > from "reserved labels" to "special purpose labels"; the main reason h= ere > > > is that in the IANA registries "reserved" has an another meaning. > > > > > > Please review the draft and comment to the list. > > > > > > /Loa > > > -- > > > > > > > > > Loa Andersson email: loa.andersson@ericsson.c= om > > > Sr Strategy and Standards Manager loa@pi.nu > > > Ericsson Inc phone: +46 10 717 52 13 > > > +46 767 72 92 13 > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > End of mpls Digest, Vol 102, Issue 53 > ************************************* >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From stbryant@cisco.com Thu Oct 25 06:23:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C3F21F8A2E for ; Thu, 25 Oct 2012 06:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.568 X-Spam-Level: X-Spam-Status: No, score=-110.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tExwsLf7v-35 for ; Thu, 25 Oct 2012 06:23:40 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id E08A421F8A43 for ; Thu, 25 Oct 2012 06:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13689; q=dns/txt; s=iport; t=1351171419; x=1352381019; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=f7xP+ZKTlnu1NKcFAlrCIraN6MielNjNdr5lNiNfqn0=; b=PPNmoTfbfzGdNqGbVaRVk9kWUB14hQ1tUPSZKXr26uumoMBIrFrt2mKO bwPDHfOC7tr4eTCWghWZTX+i8i1z+SzUoMPXTqZlWN/2+R9M5AqzDkK9b 6m+F0R7iW8unjacv+kK0xBsTdtVuOAJJVYDH09dBDZWlzzIpvObh//Cfj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALk8iVCQ/khR/2dsb2JhbABEwh6BCIIeAQEBBAEBAQ8BAhIRMwMKAQwCAgsRAwEBAQEJFggHCQMCAQIBCQYGHwkIEwEFAgEBHAKHUAMPC51yg08QkksNiVQEinZnGoZTA5QfgVWFZoVHgyWBBmWCcIFj X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="9094555" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 25 Oct 2012 13:23:31 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9PDNVkY008456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2012 13:23:31 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q9PDNTC1019964; Thu, 25 Oct 2012 14:23:30 +0100 (BST) Message-ID: <50893D50.8070107@cisco.com> Date: Thu, 25 Oct 2012 14:23:28 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A17F@SJEXCHMB09.corp.ad.broadcom.com> <144b01cdb2ae$0e971b50$2bc551f0$@olddog.co.uk> In-Reply-To: <144b01cdb2ae$0e971b50$2bc551f0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, 'Vivek Kumar' Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 13:23:48 -0000 Adrian You are going to have to trap 0..15 anyway, and special case the already defined set, because you don't know if the already defined labels will come as themselves or after L15. However its quite an interesting question as to whether anyone would want to put a 15 before an existing RL, I cannot at the moment see why you would make the stack parsing more complex by doing that. Whilst I think that we should make the whole label space available to SLs, I think that we should try hard to compress the used range to as small a space as possible so that the fast path gets the option of parsing the SL without having to invoke the heavyweight lookup that is needed to do a full 20 bit lookup. That would suggest that the SL set could usefully start at 0 so that it was as compact as possible allowing a faster L15 parser. You could think of two L15 label sets, 0..not very many which were intended for fast h/w operations, and top bit set to as many as you like which were intended to be dispatched to a slower parsing process. Stewart On 25/10/2012 13:41, Adrian Farrel wrote: > Hello, > > Well, we were looking for a format that would make things as hard as possible > for the chip vendors :-) > > We wanted labels 0-15 (i.e. what are now to be called the special labels) to > preserve their meaning in the extended space. > Thus 15->3 has the same meaning as 3. > > We were not sure that this was important, but it seemed like the right thing to > do. > > That meant that 15->15 has the same meaning as 15. > > And hence 15->15->3 has the same meaning as 3. > > I would say that the authors were not strongly wedded to this. If there was > group-think that the whole extended special label range (0-1048575) should be > new, we could probably live with it. > > Actually, a chip manufacturer could help here. Assuming that label 15 means you > throw the label and look at the next one, does it make things easier or harder > to find a special label value (say 3) and have one or two ways of handling it > depending on whether you have just found a label 15? > > Cheers, > Adrian > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Vivek Kumar >> Sent: 25 October 2012 06:36 >> To: mpls@ietf.org >> Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels- >> 01 (Adrian Farrel) >> >> Hi, >> Just curious on Section 3.1 statement " In particular, an arbitrary string > of >> consecutive extension labels is legal, and semantically equivalent to a > single >> extension label (note that this string of extension labels MUST be followed > by an >> extended special purpose label that is not the extension label).". >> >> Does this mean it will allow recursive extension labels like > Exten-label->Exten- >> label->"Standard Action label" ? Any special reason not to restrict only one >> extension label in MPLS header ? >> >> Regards, >> Vivek >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 24 Oct 2012 11:30:28 -0400 >> From: "Andrew G. Malis" >> To: Loa Andersson >> Cc: "mpls@ietf.org" >> Subject: Re: [mpls] new published >> draft-kompella-mpls-special-purpose-labels-01 >> Message-ID: >> > B8AhGAmA@mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On the whole, it looks good. I'm curious who's going to have the >> responsibility of running the process in section 3.2. IANA? (probably >> not). The WG chairs? What if there's no longer an MPLS working group >> at some point? This should be clarified. >> >> Thanks, >> Andy >> >> On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: >>> Working Group, >>> >>> the decreasing number of "reserved labels" has been of concern >>> for some time. draft-kompella-mpls-special-purpose-labels-01 proposes >>> a way to increase the the number of special purpose labels. >>> >>> We propose to take the current label 15 and use it as an extension >>> label, i.e. any label that follows label 15 should be interpreted >>> as belonging to the new "extension registry" that we propose. >>> >>> We also propose changing the name of the special purpose labels >>> from "reserved labels" to "special purpose labels"; the main reason here >>> is that in the IANA registries "reserved" has an another meaning. >>> >>> Please review the draft and comment to the list. >>> >>> /Loa >>> -- >>> >>> >>> Loa Andersson email: loa.andersson@ericsson.com >>> Sr Strategy and Standards Manager loa@pi.nu >>> Ericsson Inc phone: +46 10 717 52 13 >>> +46 767 72 92 13 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 24 Oct 2012 17:43:48 +0200 >> From: Loa Andersson >> To: "Andrew G. Malis" >> Cc: "mpls@ietf.org" >> Subject: Re: [mpls] new published >> draft-kompella-mpls-special-purpose-labels-01 >> Message-ID: <50880CB4.9000708@pi.nu> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Andy, >> >> this is in the category "good questions", when Scott Bradner were our AD >> he always said that there should be a "caretaker" appointed when a wg >> is closed But I don't know if this has been done consistently. >> >> /Loa >> >> On 2012-10-24 17:30, Andrew G. Malis wrote: >>> On the whole, it looks good. I'm curious who's going to have the >>> responsibility of running the process in section 3.2. IANA? (probably >>> not). The WG chairs? What if there's no longer an MPLS working group >>> at some point? This should be clarified. >>> >>> Thanks, >>> Andy >>> >>> On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: >>>> Working Group, >>>> >>>> the decreasing number of "reserved labels" has been of concern >>>> for some time. draft-kompella-mpls-special-purpose-labels-01 proposes >>>> a way to increase the the number of special purpose labels. >>>> >>>> We propose to take the current label 15 and use it as an extension >>>> label, i.e. any label that follows label 15 should be interpreted >>>> as belonging to the new "extension registry" that we propose. >>>> >>>> We also propose changing the name of the special purpose labels >>>> from "reserved labels" to "special purpose labels"; the main reason here >>>> is that in the IANA registries "reserved" has an another meaning. >>>> >>>> Please review the draft and comment to the list. >>>> >>>> /Loa >>>> -- >>>> >>>> >>>> Loa Andersson email: loa.andersson@ericsson.com >>>> Sr Strategy and Standards Manager loa@pi.nu >>>> Ericsson Inc phone: +46 10 717 52 13 >>>> +46 767 72 92 13 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 24 Oct 2012 18:08:31 +0100 >> From: "Adrian Farrel" >> To: >> Cc: mpls@ietf.org >> Subject: [mpls] AD review of draft-ietf-mpls-ipv6-pw-lsp-ping >> Message-ID: <12d901cdb20a$320b7080$96225180$@olddog.co.uk> >> Content-Type: text/plain; charset="us-ascii" >> >> Thanks for this document. I have done my usual AD review and have >> nothing to add except for some minor comments on the IANA section. >> If you could make an update that would be very helpful. >> >> You do not need to wait for the submission gates to reopen on 5th >> November. If you send me the file(s) for submission I will get the >> Secretariat to post them. >> >> Thanks, >> Adrian >> >> --- >> >> Section 6 >> >> It appears you are asking to *replace* the pointer to RFC 4379 for the >> three IPv4 sub-TLVs. I don't think you should do that because they are >> defined in 4379. So add the word "also". >> >> OLD >> Update the names of the Value fields of these three Sub-TLVs, adding >> the "IPv4" qualifier (see Section 2), and update the Reference to >> point to this document: >> NEW >> Update the names of the Value fields of these three Sub-TLVs, adding >> the "IPv4" qualifier (see Section 2), and update the Reference to >> also point to this document: >> END >> >> --- >> >> Section 6 usefully calls out TBD1 and TBD2, but the rest of the document >> uniformly uses TBD. If you could update to always use TBD1 and TBD2 this >> will ensure that the RFC Editor works with IANA to get this right. >> >> --- >> >> In Section 6, please explicitly ask IANA to make the appropriate entries >> in the Type 21 sub-TLVs list. >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Wed, 24 Oct 2012 18:39:04 +0100 >> From: "Adrian Farrel" >> To: "'Andrew G. Malis'" , "'Loa Andersson'" >> >> Cc: mpls@ietf.org >> Subject: Re: [mpls] new published >> draft-kompella-mpls-special-purpose-labels-01 >> Message-ID: <12ed01cdb20e$76d46650$647d32f0$@olddog.co.uk> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi Andy, >> >> Section 3.2 is about withdrawing reserved labels. I suspect that we will all > be >> retired long before the MPLS WG closes down :-) >> >> However, bullet (a) of 3.2 says: >> >> A label value that has been assigned from the "Special Purpose >> MPLS Label Values" may be deprecated by IETF consensus with >> review by the MPLS working group (or designated experts if the >> working group or a successor does not exist). >> >> So a designated expert (appointed by the IESG as with all designated experts) >> will be required. If one has not been appointed at the time of retirement of > the >> label, IANA would ask the IESG to appoint one. I think this would be the same >> expert(s) as for label allocation. >> >> The other steps in the process just ask for RFCs (i.e. publication requests > for >> I-Ds) on specific tracks. I suppose that whoever wants to retire a label will >> write the RFCs. >> >> Did we miss any other decision points? >> >> Cheers, >> Adrian >> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Andrew G. Malis >>> Sent: 24 October 2012 16:30 >>> To: Loa Andersson >>> Cc: mpls@ietf.org >>> Subject: Re: [mpls] new published > draft-kompella-mpls-special-purpose-labels- >>> 01 >>> >>> On the whole, it looks good. I'm curious who's going to have the >>> responsibility of running the process in section 3.2. IANA? (probably >>> not). The WG chairs? What if there's no longer an MPLS working group >>> at some point? This should be clarified. >>> >>> Thanks, >>> Andy >>> >>> On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: >>>> Working Group, >>>> >>>> the decreasing number of "reserved labels" has been of concern >>>> for some time. draft-kompella-mpls-special-purpose-labels-01 proposes >>>> a way to increase the the number of special purpose labels. >>>> >>>> We propose to take the current label 15 and use it as an extension >>>> label, i.e. any label that follows label 15 should be interpreted >>>> as belonging to the new "extension registry" that we propose. >>>> >>>> We also propose changing the name of the special purpose labels >>>> from "reserved labels" to "special purpose labels"; the main reason here >>>> is that in the IANA registries "reserved" has an another meaning. >>>> >>>> Please review the draft and comment to the list. >>>> >>>> /Loa >>>> -- >>>> >>>> >>>> Loa Andersson email: loa.andersson@ericsson.com >>>> Sr Strategy and Standards Manager loa@pi.nu >>>> Ericsson Inc phone: +46 10 717 52 13 >>>> +46 767 72 92 13 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> >> >> ------------------------------ >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> End of mpls Digest, Vol 102, Issue 53 >> ************************************* >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From bruno.decraene@orange.com Thu Oct 25 07:19:25 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC5C21F894F for ; Thu, 25 Oct 2012 07:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm089lrY+OMs for ; Thu, 25 Oct 2012 07:19:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7F121F85C0 for ; Thu, 25 Oct 2012 07:19:24 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id D5C462DC383; Thu, 25 Oct 2012 16:19:22 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BC5DA27C06A; Thu, 25 Oct 2012 16:19:22 +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.02.0298.004; Thu, 25 Oct 2012 16:19:22 +0200 From: To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 Thread-Index: AQHNsdAwbqF16sEJSkOjCQ7wzEcTAZfKEEvQ Date: Thu, 25 Oct 2012 14:19:22 +0000 Message-ID: <11323_1351174762_50894A6A_11323_5351_1_53C29892C857584299CBF5D05346208A0DF4EA@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <5087BF31.2020605@pi.nu> In-Reply-To: <5087BF31.2020605@pi.nu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.25.133322 Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:19:25 -0000 Hello, >Working Group, > >the decreasing number of "reserved labels" has been of concern >for some time. draft-kompella-mpls-special-purpose-labels-01 proposes >a way to increase the the number of special purpose labels. > >We propose to take the current label 15 and use it as an extension >label, i.e. any label that follows label 15 should be interpreted >as belonging to the new "extension registry" that we propose. > >We also propose changing the name of the special purpose labels >from "reserved labels" to "special purpose labels"; the main reason here >is that in the IANA registries "reserved" has an another meaning. > >Please review the draft and comment to the list. I agree that's a question that the WG should consider well in advance. Two questions: - How many special purpose labels do we think we would need? (before I reti= re) - As STD & software & hardware change are required anyway before deployment= , is there an obvious reason against extending the current range from 16 va= lues to let's say 128 values? (depending on the 1rst question). Thanks, Regards, Bruno >/Loa >-- > > >Loa Andersson email: loa.andersson@ericsson.com >Sr Strategy and Standards Manager loa@pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From jdrake@juniper.net Thu Oct 25 07:20:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AA621F86E1 for ; Thu, 25 Oct 2012 07:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.561 X-Spam-Level: X-Spam-Status: No, score=-4.561 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+B7lmqR7IHs for ; Thu, 25 Oct 2012 07:20:34 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5A32021F896B for ; Thu, 25 Oct 2012 07:20:34 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUIlKsjkaF4c1MAOqNxqfz1gpxogPVwD5@postini.com; Thu, 25 Oct 2012 07:20:34 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 25 Oct 2012 07:19:11 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 25 Oct 2012 07:19:11 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.13) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 25 Oct 2012 07:21:16 -0700 Received: from mail232-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 25 Oct 2012 14:19:10 +0000 Received: from mail232-tx2 (localhost [127.0.0.1]) by mail232-tx2-R.bigfish.com (Postfix) with ESMTP id 14DDA9C0103 for ; Thu, 25 Oct 2012 14:19:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -31 X-BigFish: PS-31(zz98dI9371I936eIc85fh148cI542M1432I4015Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail232-tx2 (localhost.localdomain [127.0.0.1]) by mail232-tx2 (MessageSwitch) id 1351174747334573_8052; Thu, 25 Oct 2012 14:19:07 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.244]) by mail232-tx2.bigfish.com (Postfix) with ESMTP id 4DFBCA4004B; Thu, 25 Oct 2012 14:19:07 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 25 Oct 2012 14:19:03 +0000 Received: from CH1PRD0510MB356.namprd05.prod.outlook.com ([169.254.2.205]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0224.004; Thu, 25 Oct 2012 14:19:03 +0000 From: John E Drake To: Vivek Kumar , "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) Thread-Index: AQHNsrJEDdTcJI4yXUu3c+3l+TnfYpfKEXDg Date: Thu, 25 Oct 2012 14:19:02 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E07DE69B1@CH1PRD0510MB356.namprd05.prod.outlook.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A17F@SJEXCHMB09.corp.ad.broadcom.com> <144b01cdb2ae$0e971b50$2bc551f0$@olddog.co.uk> <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A7BE@SJEXCHMB09.corp.ad.broadcom.com> In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A7BE@SJEXCHMB09.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BROADCOM.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:20:36 -0000 Vivek, According to the Entropy Label draft, all special (nee reserved) labels are= to be ignored when performing load balancing. I think a statement to this= effect should be included in this draft. Yours irrespectively, John > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Vivek Kumar > Sent: Thursday, October 25, 2012 6:11 AM > To: adrian@olddog.co.uk; mpls@ietf.org > Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose- > labels-01 (Adrian Farrel) >=20 > Hi Adrain, > Thanks for keeping us in job :) > Having extension approach is good idea but the recursive nature > means more possibility which result in more work for SW/HW without any > extra benefit. Less the possibilities more deterministic the behavior . >=20 > Since the idea of the draft is to expand reserved label space , > having only one extension label (15) will make things simpler. The > recursive label approach is not giving any additional information or > scope but merely testing the system if it can handle Exten-label- > >Exten-label-> Exten-label->Exten-label ->... >=20 > One more question, the new special action label range (16 - 1048559/75) > need to be excluded or included when doing ECMP using MPLS labels as > inputs (draft-ietf-mpls-entropy-label-06 ) ? >=20 > Regards, > Vivek >=20 >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Thursday, October 25, 2012 6:11 PM > To: Vivek Kumar; mpls@ietf.org > Subject: RE: [mpls] new published draft-kompella-mpls-special-purpose- > labels-01 (Adrian Farrel) >=20 > Hello, >=20 > Well, we were looking for a format that would make things as hard as > possible for the chip vendors :-) >=20 > We wanted labels 0-15 (i.e. what are now to be called the special > labels) to preserve their meaning in the extended space. > Thus 15->3 has the same meaning as 3. >=20 > We were not sure that this was important, but it seemed like the right > thing to do. >=20 > That meant that 15->15 has the same meaning as 15. >=20 > And hence 15->15->3 has the same meaning as 3. >=20 > I would say that the authors were not strongly wedded to this. If there > was group-think that the whole extended special label range (0-1048575) > should be new, we could probably live with it. >=20 > Actually, a chip manufacturer could help here. Assuming that label 15 > means you throw the label and look at the next one, does it make things > easier or harder to find a special label value (say 3) and have one or > two ways of handling it depending on whether you have just found a > label 15? >=20 > Cheers, > Adrian >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Vivek Kumar > > Sent: 25 October 2012 06:36 > > To: mpls@ietf.org > > Subject: Re: [mpls] new published > > draft-kompella-mpls-special-purpose-labels- > > 01 (Adrian Farrel) > > > > Hi, > > Just curious on Section 3.1 statement " In particular, an > > arbitrary string > of > > consecutive extension labels is legal, and semantically equivalent > to > > a > single > > extension label (note that this string of extension labels MUST be > > followed > by an > > extended special purpose label that is not the extension label).". > > > > Does this mean it will allow recursive extension labels like > Exten-label->Exten- > > label->"Standard Action label" ? Any special reason not to restrict > > label->only one > > extension label in MPLS header ? > > > > Regards, > > Vivek > > > > > > --------------------------------------------------------------------- > - > > > > Message: 1 > > Date: Wed, 24 Oct 2012 11:30:28 -0400 > > From: "Andrew G. Malis" > > To: Loa Andersson > > Cc: "mpls@ietf.org" > > Subject: Re: [mpls] new published > > draft-kompella-mpls-special-purpose-labels-01 > > Message-ID: > > > B8AhGAmA@mail.gmail.com> > > Content-Type: text/plain; charset=3DISO-8859-1 > > > > On the whole, it looks good. I'm curious who's going to have the > > responsibility of running the process in section 3.2. IANA? (probably > > not). The WG chairs? What if there's no longer an MPLS working group > > at some point? This should be clarified. > > > > Thanks, > > Andy > > > > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > > > Working Group, > > > > > > the decreasing number of "reserved labels" has been of concern for > > > some time. draft-kompella-mpls-special-purpose-labels-01 proposes a > > > way to increase the the number of special purpose labels. > > > > > > We propose to take the current label 15 and use it as an extension > > > label, i.e. any label that follows label 15 should be interpreted > as > > > belonging to the new "extension registry" that we propose. > > > > > > We also propose changing the name of the special purpose labels > from > > > "reserved labels" to "special purpose labels"; the main reason here > > > is that in the IANA registries "reserved" has an another meaning. > > > > > > Please review the draft and comment to the list. > > > > > > /Loa > > > -- > > > > > > > > > Loa Andersson email: > loa.andersson@ericsson.com > > > Sr Strategy and Standards Manager loa@pi.nu > > > Ericsson Inc phone: +46 10 717 52 13 > > > +46 767 72 92 13 > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > ------------------------------ > > > > Message: 2 > > Date: Wed, 24 Oct 2012 17:43:48 +0200 > > From: Loa Andersson > > To: "Andrew G. Malis" > > Cc: "mpls@ietf.org" > > Subject: Re: [mpls] new published > > draft-kompella-mpls-special-purpose-labels-01 > > Message-ID: <50880CB4.9000708@pi.nu> > > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > > > Andy, > > > > this is in the category "good questions", when Scott Bradner were our > > AD he always said that there should be a "caretaker" appointed when a > > wg is closed But I don't know if this has been done consistently. > > > > /Loa > > > > On 2012-10-24 17:30, Andrew G. Malis wrote: > > > On the whole, it looks good. I'm curious who's going to have the > > > responsibility of running the process in section 3.2. IANA? > > > (probably not). The WG chairs? What if there's no longer an MPLS > > > working group at some point? This should be clarified. > > > > > > Thanks, > > > Andy > > > > > > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > > >> Working Group, > > >> > > >> the decreasing number of "reserved labels" has been of concern for > > >> some time. draft-kompella-mpls-special-purpose-labels-01 proposes > a > > >> way to increase the the number of special purpose labels. > > >> > > >> We propose to take the current label 15 and use it as an extension > > >> label, i.e. any label that follows label 15 should be interpreted > > >> as belonging to the new "extension registry" that we propose. > > >> > > >> We also propose changing the name of the special purpose labels > > >> from "reserved labels" to "special purpose labels"; the main > reason > > >> here is that in the IANA registries "reserved" has an another > meaning. > > >> > > >> Please review the draft and comment to the list. > > >> > > >> /Loa > > >> -- > > >> > > >> > > >> Loa Andersson email: > loa.andersson@ericsson.com > > >> Sr Strategy and Standards Manager loa@pi.nu > > >> Ericsson Inc phone: +46 10 717 52 13 > > >> +46 767 72 92 13 > > >> _______________________________________________ > > >> mpls mailing list > > >> mpls@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls > > > > -- > > > > > > Loa Andersson email: > loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 24 Oct 2012 18:08:31 +0100 > > From: "Adrian Farrel" > > To: > > Cc: mpls@ietf.org > > Subject: [mpls] AD review of draft-ietf-mpls-ipv6-pw-lsp-ping > > Message-ID: <12d901cdb20a$320b7080$96225180$@olddog.co.uk> > > Content-Type: text/plain; charset=3D"us-ascii" > > > > Thanks for this document. I have done my usual AD review and have > > nothing to add except for some minor comments on the IANA section. > > If you could make an update that would be very helpful. > > > > You do not need to wait for the submission gates to reopen on 5th > > November. If you send me the file(s) for submission I will get the > > Secretariat to post them. > > > > Thanks, > > Adrian > > > > --- > > > > Section 6 > > > > It appears you are asking to *replace* the pointer to RFC 4379 for > the > > three IPv4 sub-TLVs. I don't think you should do that because they > are > > defined in 4379. So add the word "also". > > > > OLD > > Update the names of the Value fields of these three Sub-TLVs, > adding > > the "IPv4" qualifier (see Section 2), and update the Reference to > > point to this document: > > NEW > > Update the names of the Value fields of these three Sub-TLVs, > adding > > the "IPv4" qualifier (see Section 2), and update the Reference to > > also point to this document: > > END > > > > --- > > > > Section 6 usefully calls out TBD1 and TBD2, but the rest of the > > document uniformly uses TBD. If you could update to always use TBD1 > > and TBD2 this will ensure that the RFC Editor works with IANA to get > this right. > > > > --- > > > > In Section 6, please explicitly ask IANA to make the appropriate > > entries in the Type 21 sub-TLVs list. > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Wed, 24 Oct 2012 18:39:04 +0100 > > From: "Adrian Farrel" > > To: "'Andrew G. Malis'" , "'Loa Andersson'" > > > > Cc: mpls@ietf.org > > Subject: Re: [mpls] new published > > draft-kompella-mpls-special-purpose-labels-01 > > Message-ID: <12ed01cdb20e$76d46650$647d32f0$@olddog.co.uk> > > Content-Type: text/plain; charset=3D"us-ascii" > > > > Hi Andy, > > > > Section 3.2 is about withdrawing reserved labels. I suspect that we > > will all > be > > retired long before the MPLS WG closes down :-) > > > > However, bullet (a) of 3.2 says: > > > > A label value that has been assigned from the "Special Purpose > > MPLS Label Values" may be deprecated by IETF consensus with > > review by the MPLS working group (or designated experts if the > > working group or a successor does not exist). > > > > So a designated expert (appointed by the IESG as with all designated > > experts) will be required. If one has not been appointed at the time > > of retirement of > the > > label, IANA would ask the IESG to appoint one. I think this would be > > the same > > expert(s) as for label allocation. > > > > The other steps in the process just ask for RFCs (i.e. publication > > requests > for > > I-Ds) on specific tracks. I suppose that whoever wants to retire a > > label will write the RFCs. > > > > Did we miss any other decision points? > > > > Cheers, > > Adrian > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of Andrew G. Malis > > > Sent: 24 October 2012 16:30 > > > To: Loa Andersson > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] new published > draft-kompella-mpls-special-purpose-labels- > > > 01 > > > > > > On the whole, it looks good. I'm curious who's going to have the > > > responsibility of running the process in section 3.2. IANA? > > > (probably not). The WG chairs? What if there's no longer an MPLS > > > working group at some point? This should be clarified. > > > > > > Thanks, > > > Andy > > > > > > On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson wrote: > > > > Working Group, > > > > > > > > the decreasing number of "reserved labels" has been of concern > for > > > > some time. draft-kompella-mpls-special-purpose-labels-01 proposes > > > > a way to increase the the number of special purpose labels. > > > > > > > > We propose to take the current label 15 and use it as an > extension > > > > label, i.e. any label that follows label 15 should be interpreted > > > > as belonging to the new "extension registry" that we propose. > > > > > > > > We also propose changing the name of the special purpose labels > > > > from "reserved labels" to "special purpose labels"; the main > > > > reason here is that in the IANA registries "reserved" has an > another meaning. > > > > > > > > Please review the draft and comment to the list. > > > > > > > > /Loa > > > > -- > > > > > > > > > > > > Loa Andersson email: > loa.andersson@ericsson.com > > > > Sr Strategy and Standards Manager loa@pi.nu > > > > Ericsson Inc phone: +46 10 717 52 13 > > > > +46 767 72 92 13 > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > ------------------------------ > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > End of mpls Digest, Vol 102, Issue 53 > > ************************************* > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From adrian@olddog.co.uk Thu Oct 25 08:36:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55D521F890B for ; Thu, 25 Oct 2012 08:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00GHjRWDCEV3 for ; Thu, 25 Oct 2012 08:36:43 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id D8C1121F8901 for ; Thu, 25 Oct 2012 08:36:42 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9PFaf2b030907; Thu, 25 Oct 2012 16:36:41 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9PFaeKN030896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2012 16:36:41 +0100 From: "Adrian Farrel" To: , "'Loa Andersson'" , References: <5087BF31.2020605@pi.nu> <11323_1351174762_50894A6A_11323_5351_1_53C29892C857584299CBF5D05346208A0DF4EA@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <11323_1351174762_50894A6A_11323_5351_1_53C29892C857584299CBF5D05346208A0DF4EA@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Thu, 25 Oct 2012 16:36:38 +0100 Message-ID: <14e201cdb2c6$864b6850$92e238f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCdS8Z4CqoQoOvnU9wXZTQr2mSQEwH9iR3tmhsHKzA= Content-Language: en-gb Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:36:43 -0000 My thoughts, Bruno, we wish you a long and prosperous working life. However, if we are creating a registry, it might as well be large. Extending the special label space from 0-15 to (say) 0-127 is not backward compatible. There is no way for a new implementation supporting special label 16 to know whether it is connected to another new implementation or to an old implementation that has picked 16 to label a data packet. Using 15 with a special meaning is same because an implementation that does not recognise 15 is required to drop the packet. With regard to the (infinite) nesting, we could simply define that labels 0-15 MUST NOT appear after label 15 making the new registry run 16 to 1048575 Yes, it is a really good idea to explain the rules for hashing. Cheers, Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > bruno.decraene@orange.com > Sent: 25 October 2012 15:19 > To: Loa Andersson; mpls@ietf.org > Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels- > 01 > > Hello, > > >Working Group, > > > >the decreasing number of "reserved labels" has been of concern > >for some time. draft-kompella-mpls-special-purpose-labels-01 proposes > >a way to increase the the number of special purpose labels. > > > >We propose to take the current label 15 and use it as an extension > >label, i.e. any label that follows label 15 should be interpreted > >as belonging to the new "extension registry" that we propose. > > > >We also propose changing the name of the special purpose labels > >from "reserved labels" to "special purpose labels"; the main reason here > >is that in the IANA registries "reserved" has an another meaning. > > > >Please review the draft and comment to the list. > > I agree that's a question that the WG should consider well in advance. > > Two questions: > - How many special purpose labels do we think we would need? (before I retire) > - As STD & software & hardware change are required anyway before > deployment, is there an obvious reason against extending the current range from > 16 values to let's say 128 values? (depending on the 1rst question). > > Thanks, > Regards, > Bruno > > >/Loa > >-- > > > > > >Loa Andersson email: loa.andersson@ericsson.com > >Sr Strategy and Standards Manager loa@pi.nu > >Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > ______________________________________________________________ > ___________________________________________________________ > > 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, > France Telecom - 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, France Telecom - Orange is not liable for messages that > have been modified, changed or falsified. > Thank you. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From martin.vigoureux@alcatel-lucent.com Thu Oct 25 09:24:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274FB21F8632 for ; Thu, 25 Oct 2012 09:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8G8bA-gfShW for ; Thu, 25 Oct 2012 09:24:18 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 726B321F8531 for ; Thu, 25 Oct 2012 09:24:18 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q9PGO8aR032605 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 25 Oct 2012 18:24:17 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 25 Oct 2012 18:24:10 +0200 Received: from [135.244.11.80] (135.5.27.18) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 25 Oct 2012 12:24:07 -0400 Message-ID: <508967A3.9060801@alcatel-lucent.com> Date: Thu, 25 Oct 2012 18:24:03 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.18] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [mpls] IETF85 - MPLS Sessions - Agenda available / Time to send slides X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:24:19 -0000 All, the agenda is available here: http://www.ietf.org/proceedings/85/agenda/agenda-85-mpls Please have a look at it. It is now time for the speakers to send their slides. Please send them to me and the co-chairs no later than Sunday 4th, 8pm, Atlanta time. Thanks. Martin From kireeti.kompella@gmail.com Thu Oct 25 09:48:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7965621F86B0 for ; Thu, 25 Oct 2012 09:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddgbGY1hra7e for ; Thu, 25 Oct 2012 09:48:18 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD44821F8661 for ; Thu, 25 Oct 2012 09:48:18 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2137800pbb.31 for ; Thu, 25 Oct 2012 09:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0QCGm2rgGMbxKo1h3gn3bzHt9oHIV5jlwPtUqnFbkMU=; b=mMOn3KxiZEsxQnw86+vFgjqQvsvoVn9Ej8hlpS2TR40rODNHiOk7zMu8cmAk9zBoeL aKnrJCQFu6ddDkimIhR0aV39xijMgbsb682CaDqInM5T/qDJY5M5WKn91AHK3QOKKeZL C4q8Za+qfkRGNlSLO1r+qWrdZikNsNDBFJTjVKREWIuvgOmO8LSwWcdcGyxp8uDb+hJJ Z9Kba/LJ0BAXbeRoWGjJXsZaHUP9wNSgISeQwpUiBduK9LMIw/YfgsKczY44oydMBYGj dN6zICJaHrI1Lfhel9KI2T5JlIuuFB84YUpQmf9TGTcVtReeF6F607U1VTcd+uHy6bDx HUQA== Received: by 10.68.136.229 with SMTP id qd5mr61270051pbb.154.1351183698564; Thu, 25 Oct 2012 09:48:18 -0700 (PDT) Received: from [10.1.2.200] ([108.60.97.219]) by mx.google.com with ESMTPS id j9sm11543739pav.15.2012.10.25.09.48.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Oct 2012 09:48:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Kireeti Kompella In-Reply-To: <11323_1351174762_50894A6A_11323_5351_1_53C29892C857584299CBF5D05346208A0DF4EA@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Thu, 25 Oct 2012 09:48:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5087BF31.2020605@pi.nu> <11323_1351174762_50894A6A_11323_5351_1_53C29892C857584299CBF5D05346208A0DF4EA@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1499) Cc: "mpls@ietf.org" Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:48:19 -0000 Hi Bruno, On Oct 25, 2012, at 07:19 , wrote: > Hello, >=20 >> Working Group, >>=20 >> the decreasing number of "reserved labels" has been of concern >> for some time. draft-kompella-mpls-special-purpose-labels-01 proposes >> a way to increase the the number of special purpose labels. >>=20 >> We propose to take the current label 15 and use it as an extension >> label, i.e. any label that follows label 15 should be interpreted >> as belonging to the new "extension registry" that we propose. >>=20 >> We also propose changing the name of the special purpose labels >> from "reserved labels" to "special purpose labels"; the main reason = here >> is that in the IANA registries "reserved" has an another meaning. >>=20 >> Please review the draft and comment to the list. >=20 > I agree that's a question that the WG should consider well in advance. >=20 > Two questions: > - How many special purpose labels do we think we would need? (before I = retire) I think the purpose here is to _prepare_ for the case where more special = purpose labels are needed, not that we need them now or in our working = lifetimes. Background: there was quite a long gap of time with no new = special purpose labels, and then of a sudden, two new requests (for the = ELI and for an ISIS label). Understandably, there was pushback. So, it would be nice to have technical discussions about whether a new = special purpose label is needed, what it means, how it would be used, = etc., without worrying about scarcity. > - As STD & software & hardware change are required anyway before = deployment, is there an obvious reason against extending the current = range from 16 values to let's say 128 values? (depending on the 1rst = question). You're right that any new special purpose label, even in the current = space of 0-15, needs hardware and software changes to be useful. But = there is also the potential issue that older implementations may not = understand the new label, and the specification for the new label MUST = take this into account. =20 Re-purposing an existing space of regular labels poses a very different = problem. If a current implementation signals label 16 (say as a PW = label), but 16 is re-classified as a special purpose label (say as the = Evil Label, which spammers insert in the stack to indicate they are = doing Bad Things, a la RFC 3514), much havoc could ensue. In a previous incarnation of my working life, a proposal to increase the = special purpose label space from 0-15 to 0-31 was viewed with deep = concern; I can't speak for Cisco, but I believe the reaction was similar = there. Kireeti. > Thanks, > Regards, > Bruno >=20 >> /Loa >> -- >>=20 >>=20 >> Loa Andersson email: = loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=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, > France Telecom - 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From kireeti.kompella@gmail.com Thu Oct 25 09:58:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B2021F8905 for ; Thu, 25 Oct 2012 09:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.244 X-Spam-Level: X-Spam-Status: No, score=-3.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjRYhbBp72y9 for ; Thu, 25 Oct 2012 09:58:00 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id D6B9621F8695 for ; Thu, 25 Oct 2012 09:58:00 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so1302793pad.31 for ; Thu, 25 Oct 2012 09:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Efqkdfkh2T9JBeDaWwFcXjCxgXGSb4O5S8KRw9PdXk0=; b=DH/k703VALPs4KLoB6aVPrmQZpnDJQ1ei5NEwcPs9Bj/QSnD9921Orn3t4NLKWa77d IHzUqCtr7KEJ9zE5ld/VlcOzg0YnXMnXM9BKvesMTBu7s016eMyjCtO1VSwcjY5lCAmc 6LYp9Q+WBmRWn4XC/Ktmah40q/zd9Harq3g1DGYHgCs4a2QMPoJzttQFaiAaTAEkD8eI /pGu5GNGN3DhL6kCKqYmPl7Q1J5hNCG9nGcwaC9ZEb14ZU9lajY04DiDu52JwSPRNgnL CijERCvx/B3hIT2mYGbdjh8PSa5fDPWycpc9TKbX/pSYojfeC7DHW6JMsj7L1V1s6YHc 58PA== Received: by 10.68.216.131 with SMTP id oq3mr60683060pbc.147.1351184280501; Thu, 25 Oct 2012 09:58:00 -0700 (PDT) Received: from [10.1.2.200] ([108.60.97.219]) by mx.google.com with ESMTPS id o5sm11548006paz.32.2012.10.25.09.57.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Oct 2012 09:58:00 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Kireeti Kompella In-Reply-To: <14e201cdb2c6$864b6850$92e238f0$@olddog.co.uk> Date: Thu, 25 Oct 2012 09:58:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0D9E31EC-5568-49B1-A0E1-F0FB6B93463E@gmail.com> References: <5087BF31.2020605@pi.nu> <11323_1351174762_50894A6A_11323_5351_1_53C29892C857584299CBF5D05346208A0DF4EA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <14e201cdb2c6$864b6850$92e238f0$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1499) Cc: mpls@ietf.org Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:58:01 -0000 Hi Adrian, On Oct 25, 2012, at 08:36 , "Adrian Farrel" wrote: > With regard to the (infinite) nesting, we could simply define that = labels 0-15 > MUST NOT appear after label 15 making the new registry run 16 to = 1048575 While we could specify this, there are a host of ways people could do = silly but innocuous things with the label stack, such as insert 52 = explicit nulls, or 93 sets of ELI+EL. This is a case where my allergy against MUSTs breaks out in full-blown, = throat-closing glory =85 which may be an excellent reason for the = suggestion :-) Kireeti. From kireeti.kompella@gmail.com Thu Oct 25 11:23:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF64921F8823 for ; Thu, 25 Oct 2012 11:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX3DdnNhIBWU for ; Thu, 25 Oct 2012 11:23:10 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D546821F88A7 for ; Thu, 25 Oct 2012 11:23:10 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2194444pbb.31 for ; Thu, 25 Oct 2012 11:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=a0ow22zCfOfEEC0uzw6E3TBxQfoZtBGZHaBioUDBbsw=; b=pFiAfATSVxc4E9UyxQzxrjKJEfj/3VJaKnUCEjVXtqnMkiwULFdnXIMS3r1JvXnCa5 OVEBwe7vqHKJG8mPT1gy4rY7KWQ+zLRhcM8RHOytOKw+MImjh7KRQ7jUwe1YsP68xfHW 5zPDwwmZVXGNcNpaQG/5Me9Gx0C/ZbchkPVp45nqPPX5lPDPu0smxeoVoGxowm9wdMbx B4Oowsp5P1cuc+UY+U9HQl4zNOaUg2umJn3Yl2kdGNd9k1X1HtWEft0ifKE7MqVqQUct iYLpYraSIxgTIQgDgy0HNV838cmvehOBjjHHvMxz35TxZZxdr4S2dwEMCHXGppdQ2cKf qLaw== Received: by 10.66.78.199 with SMTP id d7mr55311650pax.77.1351189390573; Thu, 25 Oct 2012 11:23:10 -0700 (PDT) Received: from [10.1.2.200] ([108.60.97.219]) by mx.google.com with ESMTPS id ox7sm5529135pbb.14.2012.10.25.11.22.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Oct 2012 11:23:07 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Kireeti Kompella In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A7BE@SJEXCHMB09.corp.ad.broadcom.com> Date: Thu, 25 Oct 2012 11:22:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8479C703-C85F-49F9-ACAC-2E325DEF87CB@gmail.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A17F@SJEXCHMB09.corp.ad.broadcom.com> <144b01cdb2ae$0e971b50$2bc551f0$@olddog.co.uk> <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A7BE@SJEXCHMB09.corp.ad.broadcom.com> To: "Vivek Kumar" X-Mailer: Apple Mail (2.1499) Cc: "mpls@ietf.org" Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 18:23:12 -0000 On Oct 25, 2012, at 06:10 , "Vivek Kumar" wrote: > Hi Adrain, I wouldn't say that -- Adrian is stimulating and fun, and if one does = feel drained after talking with him, it's just the effort of keeping up. > Thanks for keeping us in job :)=20 > Having extension approach is good idea but the recursive nature = means more possibility which result in more work for SW/HW without any = extra benefit. Less the possibilities more deterministic the behavior . >=20 > Since the idea of the draft is to expand reserved label space , = having only one extension label (15) will make things simpler. =20 With or without recursion, only one extension label is proposed. > The recursive label approach is not giving any additional information = or scope but merely testing the system if it can handle = Exten-label->Exten-label-> Exten-label->Exten-label ->=85 I agree that a string of extension labels doesn't add info to the stack. = However, that's not the goal. Assume for a second that we all decide that having a protocol identifier = is a Good Thing (note: this is just a Thought Experiment; please start a = separate thread on the merits or demerits of such a notion; also, see = draft-bitar-mpls-isis-explicit-null-label). Assume further that all the labels from 0-15 have been assigned. So, we = have to use an extended special purpose labels for ISIS, Appletalk and = NetBUI. We already have explicit nulls for IPv4 and IPv6. Would you = rather: a) have quite different ways (and label stack depths) to announce the = payload type: 0 -> IPv4 2 -> IPv6 15, 24 -> ISIS 15, 25 -> Appletalk (etc.) b) unify these as: 15, 0 -> IPv4 15, 2 -> IPv6 15, 24 -> ISIS 15, 25 -> Appletalk (etc.) c) create new code points for IPv4 and IPv6, while keeping the old ones: 0 -> IPv4 15, 22 -> IPv4 2 -> IPv6 15, 23 -> IPv6 15, 24 -> ISIS 15, 25 -> Appletalk (etc.) I'm not a hardware or microcode guy, but (b) sounds like a reasonable = option to me. You may have deeper insights. And yes, I wish I had a more convincing example to hand; hopefully, = though, I've given you a sense of the possibilities. And no, I'm not = wedded to this; I just don't like limiting possibilities with no real = purpose. > One more question, the new special action label range (16 - = 1048559/75) need to be excluded or included when doing ECMP using MPLS = labels as inputs (draft-ietf-mpls-entropy-label-06 ) ? Agree with John's logic here -- the new special purpose labels = (0-1048575) MUST be excluded from ECMP. Will add to next revision = (along with Bruno's suggestion to specify what happens if the extension = label is the last label in the stack). Kireeti. From kireeti.kompella@gmail.com Thu Oct 25 11:27:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1B221F8969 for ; Thu, 25 Oct 2012 11:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qeqbcur1a6zr for ; Thu, 25 Oct 2012 11:27:34 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0653B21F8960 for ; Thu, 25 Oct 2012 11:27:34 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2196782pbb.31 for ; Thu, 25 Oct 2012 11:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DTAEDqdGuyHDtN1080f/kPPSXPHcevfgM7V17wWVYwg=; b=mOlXGH3f3ZQzIr2Uw6oMYwetemZgAVGvvC2cq451aLQBNRggs9VA3u4WQ7qtUGT6U1 nD4NnRp1VdjibZJLMwnksEL23e49J2IeMYK9WqDC8b8Pn9h3OSEQyeaewQaMrMx9/iUj XAJtt79piXeMTL00g7bURkDWnuG1zy1uneG7XYcoOkVGJZpTxaBSBRm1y/GXaOPKjjTN MaT8JpIyhRvWYmEC7zVSAgEPxuWhq+zuZkMX0P7tFnlYPVsZg9OiIXUHKRS0p/S7VZyT ulFgqTaSt7QYaqQJiovaIXXylMiDHCbMgjXWPbzvzkt2ugQ0BO3j7UXAoTEThppso0Ol sYLw== Received: by 10.68.129.5 with SMTP id ns5mr61966664pbb.103.1351189653854; Thu, 25 Oct 2012 11:27:33 -0700 (PDT) Received: from [10.1.2.200] ([108.60.97.219]) by mx.google.com with ESMTPS id sf4sm6135872pbc.75.2012.10.25.11.27.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Oct 2012 11:27:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Kireeti Kompella In-Reply-To: <50893D50.8070107@cisco.com> Date: Thu, 25 Oct 2012 11:27:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <66BFBB48-C403-4E58-AB04-1324E84B347A@gmail.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DE8A17F@SJEXCHMB09.corp.ad.broadcom.com> <144b01cdb2ae$0e971b50$2bc551f0$@olddog.co.uk> <50893D50.8070107@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1499) Cc: 'Vivek Kumar' , mpls@ietf.org Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 18:27:34 -0000 Hi Stewart, On Oct 25, 2012, at 06:23 , Stewart Bryant wrote: > Whilst I think that we should make the whole label space > available to SLs, I think that we should try hard to compress > the used range to as small a space as possible so that > the fast path gets the option of parsing the SL without > having to invoke the heavyweight lookup that is needed > to do a full 20 bit lookup. That would suggest that > the SL set could usefully start at 0 so that it was > as compact as possible allowing a faster L15 parser. I see the logic of this, but in the entropy label draft, we did state = that someone wishing to do load balancing could scan the label stack for = the ELI (label 7), and use just the next label for hashing. I think = that's a nice optimization; however, reusing label 7 would break that. Considering backward compatibility, there are two choices: a) either allow 0-15 following the extension label, but keep the meaning = the same as a "regular" SL; OR b) disallow 0-15 following the extension label. Kireeti. From kireeti.kompella@gmail.com Thu Oct 25 11:36:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D39E21F8987 for ; Thu, 25 Oct 2012 11:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LykEGXLk35ax for ; Thu, 25 Oct 2012 11:36:06 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0368121F8989 for ; Thu, 25 Oct 2012 11:36:05 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so1361803pad.31 for ; Thu, 25 Oct 2012 11:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version:x-mailer; bh=m9PqYPqmdub1+ryUVqSorjg6bOPazSP46oJUBK6ZnYk=; b=ydLCyth3whvWvq0+yRR9KPk/uGwvJDqvGepaqoYTHUKjbif0bbkvKVibTFEFj9wfE0 a4eKI6mNqgKTm0TRoEcnGZOAwAq7Oz4oO1neMg2RuCPNKKaPWTKzJu6qZEXxdGYQjM3I zHWJn3tgoQM7HFzaUgJYwID4IC5O7viMD7Cp5n4Bwxu+NFbshnLueQEhfXrlv2be4saw l2Z1Lk/S6OwaBqYmPAL9e+u1kcHtvv5RFP93XwyhaXWQFh/zj5PywbkqqOCL27ka0iHC MSBwn3UtG2cL3UNQOhWmJwHAhdesk8mUKI+heP8Gs1uhv1cPtoX/0EeD5Tr+EUU/f2Z5 227Q== Received: by 10.68.209.136 with SMTP id mm8mr61934781pbc.146.1351190165793; Thu, 25 Oct 2012 11:36:05 -0700 (PDT) Received: from [10.1.2.200] ([108.60.97.219]) by mx.google.com with ESMTPS id y5sm11660643pav.36.2012.10.25.11.36.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Oct 2012 11:36:05 -0700 (PDT) From: Kireeti Kompella Content-Type: multipart/alternative; boundary="Apple-Mail=_A7A69A46-111E-4AD5-A115-3037CBC6503E" Message-Id: Date: Thu, 25 Oct 2012 11:36:09 -0700 To: "mpls@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [mpls] RFC 5331 -- upstream labels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 18:36:06 -0000 --Apple-Mail=_A7A69A46-111E-4AD5-A115-3037CBC6503E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii While we're on the subject of special purpose labels, could the authors = of RFC 5331 comment on whether a reserved (aka special purpose) label = can be signaled as an upstream label? The RFC is silent on the subject, = saying only (in Section 5): The only requirement on an upstream LSR assigning upstream-assigned labels is that an upstream-assigned label must be unambiguous in the context-specific label space in which the downstream LSR will look it up. =20 which seems to imply that a reserved label can be assigned as an = upstream label. Thanks, Kireeti.= --Apple-Mail=_A7A69A46-111E-4AD5-A115-3037CBC6503E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii While we're on the subject of special purpose labels, could the authors of RFC 5331 comment on whether a reserved (aka special purpose) label can be signaled as an upstream label?  The RFC is silent on the subject, saying only (in Section 5):

   The only requirement on an upstream LSR assigning upstream-assigned
   labels is that an upstream-assigned label must be unambiguous in the
   context-specific label space in which the downstream LSR will look it
   up.

which seems to imply that a reserved label can be assigned as an upstream label.

Thanks,
Kireeti.
--Apple-Mail=_A7A69A46-111E-4AD5-A115-3037CBC6503E-- From erosen@cisco.com Thu Oct 25 15:17:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1362921F86E1 for ; Thu, 25 Oct 2012 15:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.196 X-Spam-Level: X-Spam-Status: No, score=-9.196 tagged_above=-999 required=5 tests=[AWL=1.403, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku9HlH7XFUpw for ; Thu, 25 Oct 2012 15:17:17 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBF221F88CE for ; Thu, 25 Oct 2012 15:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5620; q=dns/txt; s=iport; t=1351203430; x=1352413030; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=NYNCXvAhtjBlZlfZ6+p/OytUxXhFj1gjvur4D06gI7c=; b=Dj+QPQXVsWewqh1dIVoJwgUCaKIBgHKbELK9/EFDK2/uYnN1+iHPX1YD wjSGWu5p3vLcmwFBHKq1siZ3h5i6bw9dF7uOBgOeoe1O9/SCfHyl5W76A 41+YUS3t6sD2eGZf/eRemH0NGaV+b+YTWOkx1z9b10pURd4RhwUmdgaBq 8=; X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="132475259" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 25 Oct 2012 22:17:10 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9PMH9M2008091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2012 22:17:09 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id q9PMH8bt008049; Thu, 25 Oct 2012 18:17:08 -0400 To: Kireeti Kompella In-reply-to: Your message of Thu, 25 Oct 2012 11:27:37 -0700. <66BFBB48-C403-4E58-AB04-1324E84B347A@gmail.com> Date: Thu, 25 Oct 2012 18:17:08 -0400 Message-ID: <8048.1351203428@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org, 'Vivek Kumar' Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 22:17:18 -0000 Stewart> Whilst I think that we should make the whole label space available Stewart> to SLs, I think that we should try hard to compress the used range Stewart> to as small a space as possible so that the fast path gets the Stewart> option of parsing the SL without having to invoke the heavyweight Stewart> lookup that is needed to do a full 20 bit lookup. That would Stewart> suggest that the SL set could usefully start at 0 so that it was as Stewart> compact as possible allowing a faster L15 parser. Kireeti> I see the logic of this, but in the entropy label draft, we did Kireeti> state that someone wishing to do load balancing could scan the Kireeti> label stack for the ELI (label 7), and use just the next label for Kireeti> hashing. I think that's a nice optimization; however, reusing Kireeti> label 7 would break that. Kireeti> Considering backward compatibility, there are two choices: Kireeti> a) either allow 0-15 following the extension label, but keep the Kireeti> meaning the same as a "regular" SL; OR Kireeti> b) disallow 0-15 following the extension label. It seems to me that Kireeti's argument above leads rather to the following two choices: a) Define label 7 in the extended special purpose label registry to have the same meaning it has in the non-extended special purpose label registry, or b) Disallow label 7 following the extension label. The argument for applying this same choice to labels 0 and 2 seems to be the following: Kireeti> Assume for a second that we all decide that having a protocol Kireeti> identifier is a Good Thing (note: this is just a Thought Kireeti> Experiment; please start a separate thread on the merits or Kireeti> demerits of such a notion; also, see Kireeti> draft-bitar-mpls-isis-explicit-null-label). Kireeti> Assume further that all the labels from 0-15 have been assigned. Kireeti> So, we have to use an extended special purpose labels for ISIS, Kireeti> Appletalk and NetBUI. We already have explicit nulls for IPv4 and Kireeti> IPv6. Would you rather: Kireeti> a) have quite different ways (and label stack depths) to announce Kireeti> the payload type: Kireeti> 0 -> IPv4 Kireeti> 2 -> IPv6 Kireeti> 15, 24 -> ISIS Kireeti> 15, 25 -> Appletalk Kireeti> (etc.) Kireeti> b) unify these as: Kireeti> 15, 0 -> IPv4 Kireeti> 15, 2 -> IPv6 Kireeti> 15, 24 -> ISIS Kireeti> 15, 25 -> Appletalk Kireeti> (etc.) Kireeti> c) create new code points for IPv4 and IPv6, while keeping the old ones: Kireeti> 0 -> IPv4 Kireeti> 15, 22 -> IPv4 Kireeti> 2 -> IPv6 Kireeti> 15, 23 -> IPv6 Kireeti> 15, 24 -> ISIS Kireeti> 15, 25 -> Appletalk Kireeti> (etc.) Kireeti> I'm not a hardware or microcode guy, but (b) sounds like a Kireeti> reasonable option to me. To me, the best option is a. Why make the stack longer for IP just because someone somewhere is still using Appletalk? I think most implementations can handle variable length rewrite strings. BTW, you forgot DECnet. I definitely wouldn't allow the silliness of having an arbitrarily long sequence of extension labels mean the same thing as a single extension label. I'm also skeptical about whether we really need the extended special purpose label registry to have 20-bit values. Maybe 4 bits is too little, but 8 should be more than sufficient. Any more than 8 bits and there is very little point to requiring the "standards action" allocation policy, as it becomes very easy to "squat" on codepoints. (In fact, even 8 bits can be enough to encourage squatting; just look at the number of 8-bit codepoints that have been assigned values like 128 or 129 ;-)) BTW, once there is an extension label, one can ask whether the extension label should just be interpreted as a "context label" that identifies a second per-platform label space. A second per-platform label space could be divided into special purpose labels and dynamically assigned labels, just like the existing per-platform label space. The draft should be clear about whether this use is allowed, prohibited, or just out of scope. Kireeti> So, it would be nice to have technical discussions about whether a Kireeti> new special purpose label is needed, what it means, how it would be Kireeti> used, etc., without worrying about scarcity. That seems likely to lead to a "just say yes" policy, in which we will end up with hundreds of special purpose labels, each implemented by only a subset of vendors. If hardware/microcode needs to have a priori awareness of the special purpose labels, there still is scarcity, even if the scarcity is not imposed by the protocol syntax. Kireeti> While we're on the subject of special purpose labels, could the Kireeti> authors of RFC 5331 comment on whether a reserved (aka special Kireeti> purpose) label can be signaled as an upstream label? The RFC is Kireeti> silent on the subject, I think there are really two separate questions here: - When doing dynamic upstream label assignment, is it legal to assign label values 0-15? I think it would not be wise to do this, as it falls into the category of "asking for trouble". Probably it should have been prohibited. - What should you do in a context where you believe a particular label is upstream-assigned, but (a) it has a value in the range 0-15, and (b) that value has not been dynamically bound? I am not aware of any situation in which this would be legal, but I'd be interested in hearing other opinions. From zali@cisco.com Fri Oct 26 08:54:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1280621F84B1 for ; Fri, 26 Oct 2012 08:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMXEk2cMauHF for ; Fri, 26 Oct 2012 08:54:30 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id DD18D21F84A6 for ; Fri, 26 Oct 2012 08:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1604; q=dns/txt; s=iport; t=1351266870; x=1352476470; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yAit57XQ/gQKzRx4CYIADRkpaPpZw9h7MTt7Wb/wfgg=; b=nLbGaFr2Fxn8LlaSoHQpuAjVoShpvBeOJcPnaVogIrnMnWgWVoIrENgk +TyQl/W1G96TsgpeHqrNyLs9nfCOJdVBowDh1KZqaUejhJOzmyGmb1VAS t621wiN6ydsuDPCmh9zsYiBO4ikt15i4kcwQrj+ePdAhWSIJw+Q0e0YAx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEGxilCtJV2c/2dsb2JhbABEwj+BCIIeAQEBBBIBJzQLDAICAgEIEQQBAQsUBQQHGxcUCQgCBAENBQgah2QLnR6gHwSLbYYNYQOXCo08gWuCb4FkFx4 X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="135774774" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 26 Oct 2012 15:54:26 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9QFsQjN027569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Oct 2012 15:54:26 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Fri, 26 Oct 2012 10:54:25 -0500 From: "Zafar Ali (zali)" To: Loa Andersson , "mpls@ietf.org" , "Martin Vigoureux" , "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" Thread-Topic: poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document Thread-Index: AQHNrQHxPYkZ727bnEGw9/i5Dys4ApfLyjAg Date: Fri, 26 Oct 2012 15:54:25 +0000 Message-ID: References: <507FAF2D.5020907@pi.nu> In-Reply-To: <507FAF2D.5020907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19310.001 x-tm-as-result: No--29.485400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 15:54:35 -0000 Support.=20 n.b. I am one of the co-authors.=20 Thanks Regards...Zafar > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, October 18, 2012 3:27 AM > To: mpls@ietf.org; Martin Vigoureux; draft-ali-mpls-inter-domain-p2mp-rsv= p-te- > lsp@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org > Subject: poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp= -te-lsp a working > group document >=20 > Working group, >=20 > this is to start a two week poll on adopting > draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-09 > as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working group= mailing list (mpls at > ietf.org). Please give an technical motivation for your support/not suppo= rt, especially if you think > that the document should not be adopted as a working group document. >=20 > This poll ends November 07, 2012. >=20 > There is one IPR claim against this document - http://datatracker.ietf.or= g/ipr/1861/ . >=20 > All the co-authors has stated on the mailing list that they are not aware= of any other IPR claims > than those already disclosed. > If there are IPR claims from any other party, please remember that the IP= R is open. >=20 > /Loa > (mpls wg co-chair) > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From msiva@cisco.com Fri Oct 26 09:46:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760B121F85C0 for ; Fri, 26 Oct 2012 09:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFHJT0POG3cp for ; Fri, 26 Oct 2012 09:46:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D6E5121F85B8 for ; Fri, 26 Oct 2012 09:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1627; q=dns/txt; s=iport; t=1351269966; x=1352479566; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=q/3WEXv4n4gUDP3fc95DCzXwLNryeIPZuOUC2jili+E=; b=ikLPEdXcdUt1U1qWSs6Kq5KPjTt1umte+1zki+F19LHBePg92SgroogG OqmG2WF2yGXYOPmSBPgewsLo+JZjkE3TW6IL6NeVLNAm/uCLftiIVajxT /gloSs443r07a1HCN1P8+hDv3IJGTCNOXxME/7GH2brLBMm0+ftQ7hELZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPm8ilCtJV2b/2dsb2JhbABEwj+BCIIeAQEBBAEBAQ8BJzQLDAICAgEIEQQBAQsUBQQHGwwLFAkIAgQBDQUIGodkC50DoB0Ei22GDWEDlwqNPIFrgm+BZBce X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="135754429" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 26 Oct 2012 16:46:05 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9QGk5HR013955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Oct 2012 16:46:05 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.63]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Fri, 26 Oct 2012 11:46:04 -0500 From: "Siva Sivabalan (msiva)" To: Loa Andersson , "mpls@ietf.org" , "Martin Vigoureux" , "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" Thread-Topic: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document Thread-Index: AQHNrQH5iQMMv/7t4UaaVUpqZMsgQZfL2KpQ Date: Fri, 26 Oct 2012 16:46:04 +0000 Message-ID: References: <507FAF2D.5020907@pi.nu> In-Reply-To: <507FAF2D.5020907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.209.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19310.001 x-tm-as-result: No--26.992800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:46:06 -0000 Support. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, October 18, 2012 3:27 AM To: mpls@ietf.org; Martin Vigoureux; draft-ali-mpls-inter-domain-p2mp-rsvp-= te-lsp@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp= -rsvp-te-lsp a working group document Working group, this is to start a two week poll on adopting draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-09 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls at ietf.org). Please give an technical motivation for you= r support/not support, especially if you think that the document should not= be adopted as a working group document. This poll ends November 07, 2012. There is one IPR claim against this document - http://datatracker.ietf.org/= ipr/1861/ . All the co-authors has stated on the mailing list that they are not aware o= f any other IPR claims than those already disclosed. If there are IPR claims from any other party, please remember that the IPR = is open. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ____________= ___________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mach.chen@huawei.com Fri Oct 26 20:17:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBE521F85D5 for ; Fri, 26 Oct 2012 20:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.996 X-Spam-Level: * X-Spam-Status: No, score=1.996 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FFHvF7AQ-gx for ; Fri, 26 Oct 2012 20:17:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 442BD21F85C1 for ; Fri, 26 Oct 2012 20:17:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMC26987; Sat, 27 Oct 2012 03:17:47 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 27 Oct 2012 04:17:30 +0100 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 27 Oct 2012 04:17:46 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.192]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 27 Oct 2012 11:17:01 +0800 From: Mach Chen To: Loa Andersson , Dan King , Thomas Morin Thread-Topic: MPLS-RT review of draft-zjns-mpls-lsp-ping-relay-reply Thread-Index: AQHNqJcrIkWg3D9WQE2r/huopqKsjZfMkPsw Date: Sat, 27 Oct 2012 03:17:00 +0000 Message-ID: References: <50784613.6070509@pi.nu> In-Reply-To: <50784613.6070509@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-zjns-mpls-lsp-ping-relay-reply@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtempu?= =?gb2312?b?cy1tcGxzLWxzcC1waW5nLXJlbGF5LXJlcGx5?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 03:17:49 -0000 SGksDQoNCkkgaGF2ZSBkb25lIG15IE1QTFMtUlQgcmV2aWV3LCBoZXJlIGFyZSBteSBjb21tZW50 cy4NCg0KSXMgdGhpcyBkcmFmdCB1c2VmdWw/DQoNClllcywgSSB0aGluayB0aGlzIGRyYWZ0IGlz IHVzZWZ1bC4NCg0KSXMgdGhlIGRvY3VtZW50IGNvaGVyZW50Pw0KDQpJIHRoaW5rIHRoZSBkcmFm dCBuZWVkcyBtb3JlIHdvcmssIGVzcGVjaWFsbHkgb24gdGhlICJLIGJpdCIgcmVsYXRlZCBkZXNp Z24gYW5kIHByb2Nlc3MuIA0KDQpJcyB0aGUgZG9jdW1lbnQgcmVhZHkgdG8gYmUgY29uc2lkZXJl ZCBmb3IgV0cgYWRvcHRpb24uDQoNCkl0IGlzIGNsb3NlIHRvLCBiZXR0ZXIgYWZ0ZXIgc29sdmlu ZyB0aGUgZm9sbG93aW5nIGNvbW1lbnRzIHdpdGggY2xhcmlmaWNhdGlvbiBvciBhIG5ldyByZXZp c2lvbi4gDQoNCg0KQ29tbWVudHM6DQoNCjEuIEZyb20gdGhlIG1vdGl2YXRpb24sIGl0IHNlZW1z IHRoYXQgZHJhZnQgaW50ZW5kcyB0byBzb2x2ZSB0aGUgdHJhY2Vyb3V0ZSBwcm9ibGVtIGluIGlu dGVyLWFzL2FyZWEgc2NlbmFyaW9zLCBpZiBpdCdzIHRydWUsIHRoaXMgc2hvdWxkIGJlIGV4cGxp Y2l0bHkgc3RhdGVkIGluIHRoZSBJbnRyb2R1Y3Rpb24gYW5kL29yIEFic3RyYWN0IHNlY3Rpb24u DQoNCjIuIFNlY3Rpb24gMy4yLA0KYS4gdGhlIFJlbGF5IE5vZGUgQWRkcmVzcyBTdGFjayBUTFYg c2hvdWxkIGJlIGFuIG9wdGlvbmFsIFRMViwgaXQncyBiZXR0ZXIgdG8gc3RhdGUgdGhpcyBpbiB0 aGUgZHJhZnQsIGFuZCBuZWVkIHRvIHNwZWNpZnkgdG8gd2hpY2ggcmVwbHkgbW9kZXMgKGFsbCB0 aGUgZml2ZSBvciBwYXJ0aWN1bGFyIG1vZGVzICkgdGhpcyBUTFYgY291bGQgYXBwbHkuDQpiLiBp dCBkZWZpbmVzIHR3byB0eXBlcyB0aGUgcmVsYXkgYWRkcmVzcyAoSVB2NCwgSVB2NiksIGRvZXMg aXQgYWxsb3cgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZSB0d28gdHlwZXMgKGUuZy4sIElQdjQtSVB2 NC1JUHY2LUlQdjQpIGluIGEgc2luZ2xlIHN0YWNrLCBpZiBub3QsIGl0IHNob3VsZCBleHBsaWNp dGx5IHNwZWxsIG91dC4gQW5kIGlmIGEgbm9kZSBzdXBwb3J0IGR1YWwgc3RhY2tzLCBob3cgZG9l cyBpdCBkZWNpZGUgd2hpY2ggdHlwZSBzaG91bGQgYmUgdXNlZD8NCmMuIHRoZSBLIGJpdCwgdGhl IGRyYWZ0IHNhaWQ6ICJUaGUgSyBiaXQgbWF5IGJlIHNldCBieSBBU0JScyB3aGljaCBhZGRyZXNz IHdvdWxkIGJlIGtlcHQgaW4gdGhlIHN0YWNrIGlmIG5lY2Vzc2FyeS4iIEhvdyBhbmQgd2hlbiBk b2VzIGFuIEFTQlIga25vdyBpdCBzaG91bGQgc2V0IHRoZSBLIGJpdD8gQ2FuIGFuIG5vbi1BU0JS IHNldCB0aGUgSyBiaXQ/IA0KDQozLiBTZWN0aW9uIDQuMSwgc2hvdWxkIGluaXRpYXRvciBhZGRy ZXNzIGVudHJ5IHNldCB0aGUgSyBiaXQsIGlmIG5vdCwgYWNjb3JkaW5nIHRvIHRoZSBjb21wcmVz cyBwcm9jZXNzIGluIHNlY3Rpb24gNC4yLCB0aGUgaW5pdGlhdG9yIGFkZHJlc3Mgd2lsbCBiZSBk ZWxldGVkIHdoZW4gYW4gaW50ZXJtZWRpYXRlIG5vZGUgY29tcHJlc3NlZCB0aGUgc3RhY2suIFRo ZXJlZm9yZSwgd2hlbiBkbyByZWxheSByZXBseSwgc2luY2Ugc291cmNlIGFuZCBkZXN0aW5hdGlv biBhZGRyZXNzZXMgYXJlIG5vdCBiZSB0aGUgaW5pdGlhdG9yIGFkZHJlc3MgYW55bW9yZSwgdGhl IGludGVybWVkaWF0ZSBub2RlIG1heSBub3Qgd2hlcmUgdG8gc2VuZCB0byByZXBseS4gSXMgbXkg dW5kZXJzdGFuZGluZyByaWdodD8gSU1ITywgdGhlIGluaXRpYXRvciBhZGRyZXNzIE1VU1QgYWx3 YXlzIGJlIGtlcHQgaW4gdGhlIHN0YWNrIGFzIHRoZSBmaXJzdCBlbnRyeS4gSSBoYXZlIGZlZWxp bmcgdGhhdCB0aGVyZSBpcyBubyBuZWVkIHRvIGRlZmluZSB0aGUgSyBiaXQsIG1ha2VzIHRoZSBw cm9jZWR1cmVzIG1vcmUgY29tcGxleCBhbmQgYnJpbmdzIGxlc3MgdmFsdWUuDQoNCjQuIFNlY3Rp b24gNC4yLCAidGhlIHJlY2VpdmVyIHdvdWxkIGNoZWNrIHRoZSBhZGRyZXNzZXMgb2YgdGhlIHN0 YWNrIGluIHNlcXVlbmNlIGZyb20gdG9wIHRvIGJvdHRvbSIsIEkgYW0gbm90IHN1cmUgdGhlIGNv bmNlcHQgb2YgdG9wIGFuZCBib3R0b20gaXMgc2FtZSBhcyB0aGUgbm9ybWFsIHN0YWNrIChlLmcu LCBmaXJzdCBpbiBsYXN0IG91dCwgYWthIHRoZSBmaXJzdCB3aWxsIGJlIHRoZSBib3R0b20gYW5k IHRoZSBsYXN0IHdpbGwgYmUgdGhlIHRvcCksIGlmIHllcywgSU1ITywgZnJvbSB0aGUgYm90dG9t IHRvIHRvcCBzaG91bGQgYmUgbW9yZSBlZmZpY2llbnQsIGl0IHdpbGwgZWxpbWluYXRlIHVubmVj ZXNzYXJ5IHJlbGF5IHByb2Nlc3Nlcy4gDQoNCjUuIFNldGlvbiA0LjMgICIuLi5XaGVuIHRoZSBy ZXBseWluZyBMU1IgcmVjZWl2ZWQgYW4gZWNobyByZXF1ZXN0IHdpdGggdGhlIGluaXRpYXRvcg0K ICAgSVAgYWRkcmVzcyBpbiB0aGUgUmVsYXkgTm9kZSBBZGRyZXNzIFN0YWNrIFRMViBpcyBJUCB1 bnJvdXRhYmxlLCB0aGUNCiAgIHJlcGx5aW5nIExTUiB3b3VsZCBzZW5kIGFuIGVjaG8gcmVsYXkg cmVwbHkgbWVzc2FnZSB0byB0aGUgZmlyc3QNCiAgIHJvdXRhYmxlIGludGVybWVkaWF0ZSBub2Rl LiIgVGhpcyBjb25maXJtIG15IGFzc3VtcHRpb24gdGhhdCB0aGUgaW5pdGlhdG9yIE1VU1QgYmUg aW4gdGhlIHN0YWNrIGFuZCBNVVNUIGJlIHRoZSBmaXJzdCBlbnRyeS4NCg0KDQpCZXN0IHJlZ2Fy ZHMsDQpNYWNoDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogTG9hIEFuZGVyc3Nv biBbbWFpbHRvOmxvYUBwaS5udV0NCj4gt6LLzcqxvOQ6IDIwMTLE6jEw1MIxM8jVIDA6MzINCj4g ytW8/sjLOiBNYWNoIENoZW47IERhbiBLaW5nOyBUaG9tYXMgTW9yaW4NCj4gs63LzTogZHJhZnQt empucy1tcGxzLWxzcC1waW5nLXJlbGF5LXJlcGx5QHRvb2xzLmlldGYub3JnOw0KPiBtcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZzsgTWFydGluIFZpZ291cmV1eA0KPiDW98ziOiBNUExTLVJUIHJl dmlldyBvZiBkcmFmdC16am5zLW1wbHMtbHNwLXBpbmctcmVsYXktcmVwbHkNCj4gDQo+IE1hY2gs IERhbmllbCBhbmQgVGhvbWFzLA0KPiANCj4gDQo+IFlvdSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMg YW4gTVBMUyBSZXZpZXcgdGVhbSByZXZpZXdlcnMgZm9yDQo+IGRyYWZ0LXpqbnMtbXBscy1sc3At cGluZy1yZWxheS1yZXBseS4NCj4gDQo+IE5vdGUgdG8gYXV0aG9yczogWW91IGhhdmUgYmVlbiBD Q6GvZCBvbiB0aGlzIGVtYWlsIHNvIHRoYXQgeW91IGNhbiBrbm93DQo+IHRoYXQgdGhpcyByZXZp ZXcgaXMgZ29pbmcgb24uIEhvd2V2ZXIsIHBsZWFzZSBkbyBub3QgcmV2aWV3IHlvdXIgb3duDQo+ IGRvY3VtZW50Lg0KPiANCj4gUmV2aWV3cyBzaG91bGQgY29tbWVudCBvbiB3aGV0aGVyIHRoZSBk b2N1bWVudCBpcyBjb2hlcmVudCwNCj4gaXMgaXQgdXNlZnVsIChpZSwgaXMgaXQgbGlrZWx5IHRv IGJlIGFjdHVhbGx5IHVzZWZ1bCBpbiBvcGVyYXRpb25hbA0KPiBuZXR3b3JrcyksIGFuZCBpcyB0 aGUgZG9jdW1lbnQgdGVjaG5pY2FsbHkgc291bmQ/ICBXZSBhcmUgaW50ZXJlc3RlZCBpbg0KPiBr bm93aW5nIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIGNvbnNpZGVyZWQgZm9y IFdHIGFkb3B0aW9uDQo+IChpZSwgaXQgZG9lc26hr3QgaGF2ZSB0byBiZSBwZXJmZWN0IGF0IHRo aXMgcG9pbnQsIGJ1dCBzaG91bGQgYmUgYSBnb29kDQo+IHN0YXJ0KS4NCj4gDQo+IFJldmlld3Mg c2hvdWxkIGJlIHNlbnQgdG8gdGhlIGRvY3VtZW50IGF1dGhvcnMsIFdHIGNvLWNoYWlycyBhbmQN Cj4gc2VjcmV0YXJ5LCBhbmQgQ0Ohr2QgdG8gdGhlIE1QTFMgV0cgZW1haWwgbGlzdC4gSWYgbmVj ZXNzYXJ5LCBjb21tZW50cw0KPiBtYXkgYmUgc2VudCBwcml2YXRlbHkgdG8gb25seSB0aGUgV0cg Y2hhaXJzLg0KPiANCj4gQXJlIHlvdSBhYmxlIHRvIHJldmlldyB0aGlzIGRyYWZ0IGJ5IE9jdCAz MCwgMjAxMj8NCj4gDQo+IFRoYW5rcywgTG9hDQo+IChhcyBNUExTIFdHIGNoYWlyKQ0KPiANCj4g LS0NCj4gDQo+IA0KPiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWls Og0KPiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KPiBTciBTdHJhdGVneSBhbmQgU3RhbmRh cmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnUNCj4gRXJpY3Nzb24gSW5jICAgICAgICAg ICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5MiAxMw0K From wyaacov@gmail.com Sun Oct 28 04:31:57 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F6F21F86EB for ; Sun, 28 Oct 2012 04:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+kfIypTdcYH for ; Sun, 28 Oct 2012 04:31:55 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31FC821F86D5 for ; Sun, 28 Oct 2012 04:31:55 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4685915vcb.31 for ; Sun, 28 Oct 2012 04:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qYRpabenMues3mpHPUv28ufnu1uhfvFfcBQ3roHeSS8=; b=W2gUF0PnYPWHa6EdAzKaTzvTTSNbOGWXMfnKrqfhCfuIVplasl6owS3P1HX41JIXxl qnmU22JUZh2YqRvoFRTZeSbmjdlb6tjCuTbeElc31wSNEaO5aYogiwc43DRzJt0ExMvP rA49doM4p4BwQc/AG7YC/ZY3ujvxgQ6HHkemTnzKx/tuiZ6TPi/HH6cchbwukOs6i0Rt YB4zczDRtZIgE9kQ6ls4uwz+wvewGYz/NjhYQVUiyx7e/vMdejR6WKePBZw4aeP7oH3k X1WvrSvVRyEoTBIm0bkvbaj4bDn7caQkCXjR/H1ONqpgD7aVRKfmRIHuFT0gv5ArIFjO YXEA== MIME-Version: 1.0 Received: by 10.221.11.15 with SMTP id pc15mr25756470vcb.70.1351423914571; Sun, 28 Oct 2012 04:31:54 -0700 (PDT) Received: by 10.58.254.194 with HTTP; Sun, 28 Oct 2012 04:31:54 -0700 (PDT) In-Reply-To: References: <5059A308.3050307@pi.nu> Date: Sun, 28 Oct 2012 13:31:54 +0200 Message-ID: From: Yaacov Weingarten To: Gregory Mirsky Content-Type: multipart/alternative; boundary=bcaec54ee85a5e798004cd1ce659 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 11:31:57 -0000 --bcaec54ee85a5e798004cd1ce659 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Greg, hi Thank you for your comments regarding the draft - after some consideration I would like to provide answers to your comments, inline (prefixed by yw>>) below. Note that I will upload a new version within the next weeks. Hope this helps, yaacov On Mon, Oct 1, 2012 at 5:53 PM, Gregory Mirsky wrote: > Dear Authors, Editors, WG Chairs, et al., > Please find my comments to the document below: > > - Section 2.1 > > > - Verbal explanation of the wrapping in the first paragraph might > benefit if LSRs be referenced as in Figure 1. > > yw>> Will update according to your suggestion, although the explanation i= s meant to be a general explanation. > > - As described, wrapping can provide local protection of > bi-directional co-routed LSP only in case of link failure. If node > protection requested, as mentioned in the third sentence of the first = para, > MP is not the downstream LSR but next down to downstream. If we expect= that > PLR in forward direction is MP in reverse direction of given bi-direct= ional > LSP, then we have case of segment, not local protection. (Same, I beli= eve, > applies to FRR of bi-directional co-routed p2p LSP). > > yw>> Not sure that I understand the implications of what you are saying (to me it seems that you are raising a semantic point) - would help if you could provide either a suggestion for better text or a direction that you think we should go to, referencing also the text in section 2.3.3 > > - s/arounf/around/ > > yw>> Corrected > > - Figure 1 I think that this figure illustrates wrapping of a single > direction in case of local link protection. If that is the intention, = then > caption might explicitly state that. If a case of a bi-directional LSP= to > be illustrated for local link protection, then another wrapped data pa= th > F-E-D-C-B-A might be added. > > yw>> To the best of my understanding, the same SPME (which, by defintion, is bi-directional) would protect both directions. There is an error in Figure 1 that has been pointed out to the authors and is corrected in the upoming revision that extends the SPME to end at F rather than at E. > > - "If protecting both the links and the nodes of a LSP, then, for a > ring with N nodes, there is a need for O(2N) alternate paths." I > assume that this estimate is for bi-directional co-routed p2p LSP. But > co-routed LSP implies coordinated protection which, as mentined before= , can > not be achieved for node protection with local protection. Coordinated= node > protection, if not end-to-end, can be in form of segment protection. > > yw>> As above, it would help if you could provide some more guidance on the implications for this draft or better text. > > - Section 2.2 > > > - "The process of notifying the ingress node adds to the latency of > the protection switching process, after the detection of the fault > condition." I think that that is not necessarily true as ingress > notification doesn't have to be explicit but can be implicit if e2e CC= /CV > monitors working and protecting paths. > > yw>> This may be true if the network is completely reliant on CC/CV for its indications. However, as is mentioned in RFC6378, the indications my originate from other sources, e.g. control plane,or a lower (e.g. physical) layer. > > - Very last para "=85 there is the necessity for the ring to maintain > enough capacity for all of the data in both directions around the ring= " > seems as too strong requirement considering cases of 1:N linear and sh= ared > mesh protection, where bandwidth of a protection path shared. > > yw>> I am not sure that I understand the relevance to this document that is addressing protection on a "ring" - not sure that there is a requirement in a ring to support these additional (1:n or SMP) protection. > > - Section 2.3 > > > - "=85 since we will perform all of the OAM functionality on the SPME > configured for the traffic, we can minimize the number of OAM sessions > needed to monitor the data traffic of the ring - rather than monitorin= g > each individual LSP." Such improvement in OAM scale doesn't come for f= ree > as SPME OAM might introduce or hide connectivity and/or continuity def= ects > of enclosed LSPs. > > yw>> Can you elaborate on this? Seems that this comment should be relate= d to the MPLS-TP Framework document > > - "In all of the following subsections, we use 1:1 linear protection > [SurvivFwk] [LinProtect] to perform protection switching and coordinat= ion > when a signal fault is detected." For 1:1 linear protection scope of t= he > RFC 6378 is limited to bi-directional p2p MPLS-TP constructs. > "Applicability of the protocol for 1:1 unidirectional protection and f= or > 1:n protection schemes may be documented in a future document and is o= ut of > scope for this document", stated in section 1.2. Thus use of PSC for > unidirectional p2p and p2mp MPLS-TP constructs is undefined. Perhaps t= his > has to be mentioned and reflected in change of the scope of the docume= nt. > > yw>> As mentioned above (and in conjunction with the text referred to in your previous comment), the SPME is, by defintion, bi-directional > > - Section 2.3.1 > > > - First para "=85 each one acts as the ingress and egress in one > direction of the bidirectional SPME". I think that terminology > "ingress/egress MEP" is not the best and perhaps view of nodal MEP per= LSP > is sufficient, so that no need to split MEP on given LSP per direction= . > > yw>> There was no intention of splitting the MEP relative to its position on the node, will try and find a better way of referring to the MEP at the ingress and egress points of the SPME. > > - Section 2.3.2 > > > - I think that title of the section needs to say explicitly that link > protection by wrapping is discussed in the section (node protection in= the > 2.3.3) > > yw>> Corrected > > - Section 2.3.3 > > > - As mentioned, in case of bi-directional co-routed LSP to which node > protection required (Figure 4) SPME approach is, effectively, segment,= not > local protection. SPME level OAM between LSR A and LSR E monitors not = only > link between LSR A and LSR F and LSR F but link between LSR F and LSR = E as > well (from LSP POV). The primary SPME, effectively, changes ring topol= ogy > by excluding LSR F from topology as LSR F would not be processing LSP'= s > outer label but process only SPME's outer label. > > yw>> Not sure what correction you are looking for in relation to this comment! > > - Section 2.3.4 > > > - Local node protection monitors immediate link for link as well as > node protection. The difference between these protection modes in sele= ction > of a MP, whether immediate neighbor can (link protection) or can not (= node > protection) be used as MP. The section seems based on misunderstanding= of > difference between local link and node protection and might be removed= . > > yw>> Can you provide some more detail or be more specific? > > - Section 2.4 > > > - s/steeing/steering/ > > yw>> Corrected > > - What are three OAM sessions that each ring node will have if > wrapping used to protect the ring? I see two OAM sessions: immediate l= ink > to downstream LSR; around ring to the same LSR. Where the third OAM se= ssion? > > yw>> This takes into account both link and node protection which would require an OAM session on the alternate protection SPME. Will calrify in the next revision if this is OK with you. > > - "Special consideration" seems as unfounded: > > > - Not clear why CC/CV OAM in case of SPME steering viewed as > insufficient for fast defect detection. > > yw>> Alarm reporting is justified in the OAM requirements document on the basis of this argument that is merely repeated here. > > - Local node and link protection are not mutualy exclusive. Local node > protection provides link protection as part of node protection. The > problem, from my POV, is that bi-directional co-routed LSP can not hav= e > local node protection but only segment protection. > > yw>> Again the question of whether this goes beyond a question of semantics. > > - Section 3 > > > - As noted earlier, applicability of RFC 6378 and PSC for 1:1 linear > protection of unidirectional MPLS-TP constructs, including unidirectio= nal > p2mp LSP, not yet been defined. Neither CC/CV OAM on these constructs.= What > mechanism(s) could be used to perform defect detection, coordination a= nd > protections switchover? > > yw>> Could you be more specific regarding which text you would like to se= e corrected? In general, the protection over the ring is based on the use of a bi-directional SPME, and for the p2mp cases use of Context-labels to allow distribution to the specific egress points of the underlying LSPs. > > - Section 4 > > > - As as stated in RFC 6378 "Applicability of the protocol [PSC, my > note] for 1:1 unidirectional protection and for 1:n protection schemes= may > be documented in a future document and is out of scope for this docume= nt". > > yw>> And as stated above in several comments, SPME are bi-directional. > A note on textual conventions: > > - References are both direct RFC, e.g. [RFC4090], and content-based, > i.e. [TPReqs]. May consider choosing single style of referencing. > > yw>> This will be corrected prior to publication, it is just tedious during the progression of the document, while some of the other documents were still drafts. > > Thank you for your kind consideration. > > Regards, > Greg > > -----Original Message----- > From: mpls-bounces@ietf.org [*mailto:mpls-bounces@ietf.org*] > On Behalf Of Loa Andersson > Sent: Wednesday, September 19, 2012 3:49 AM > Cc: mpls@ietf.org; MPLS-TP ad hoc team; > draft-ietf-mpls-tp-ring-protection@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection > > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 related > to this document. > > Please send your comments to the mpls working group mailing lists ( > mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13___________= ____________________________________ > mpls mailing list > mpls@ietf.org > *https://www.ietf.org/mailman/listinfo/mpls* > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --bcaec54ee85a5e798004cd1ce659 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Greg, hi

Thank you for your comments re= garding the draft - after some consideration I would like to provide answer= s to your comments, inline (prefixed by yw>>) below. =A0Note that I w= ill upload a new version within the next weeks.

Hope this helps,
yaacov

On Mon, Oct 1, 2012 at 5:53 PM, Gregory Mirsky <gre= gory.mirsky@ericsson.com> wrote:
Dear Authors, Editors, WG Chairs, et al.,
Please find my comments to the document below:
  • Section 2.1
  • Verbal explanation of the wrapping in the first paragraph might benefit= if LSRs be referenced as in Figure 1.
<= div>yw>> Will update according to your suggestion, although the expla= nation is meant to be a general explanation.=A0
  • As described,= wrapping can provide local protection of bi-directional co-routed LSP only= in case of link failure. If node protection requested, as mentioned in the= third sentence of the first para, MP is not the downstream LSR but next do= wn to downstream. If we expect that PLR in forward direction is MP in reverse direction of gi= ven bi-directional LSP, then we have case of segment, not local protection.= (Same, I believe, applies to FRR of bi-directional co-routed p2p LSP).
yw>> Not sure that I understand t= he implications of what you are saying (to me it seems that you are raising= a semantic point) - would help if you could provide either a suggestion fo= r better text or a direction that you think we should go to, referencing al= so the text in section 2.3.3=A0
  • s/arounf/arou= nd/
yw>> Corrected=A0
  • Figure 1 I think that this figure illustrates wrapping of a single dire= ction in case of local link protection. If that is the intention, then capt= ion might explicitly state that. If a case of a bi-directional LSP to be il= lustrated for local link protection, then another wrapped data path F-E-D-C-B-A might be added.
=
yw>> To the best of my understanding, the sam= e SPME (which, by defintion, is bi-directional) would protect both directio= ns. There is an error in Figure 1 that has been pointed out to the authors = and is corrected in the upoming revision that extends the SPME to end at F = rather than at E.
  • "If protecting both the links and the nodes of a LSP, then, for a ring with N nodes, = there is a need for O(2N) alternate= paths." I assume that this estimate is for bi-directional co-routed p2p LSP. But co-routed LSP im= plies coordinated protection which, as mentined before, can not be achieved= for node protection with local protection. Coordinated node protection, if= not end-to-end, can be in form of segment protection.
yw>> A= s above, it would help if you could provide some more guidance on the impli= cations for this draft or better text.=A0
  • Section 2.2
  • "The process of notifying the ingress node adds to the latency of = the protection switching process, after the detection of the fault conditio= n." I think that that is not necessarily true as ingress notification = doesn't have to be explicit but can be implicit if e2e CC/CV monitors working and protecting paths.
<= /blockquote>
yw>> This may be true if the network is completely r= eliant on CC/CV for its indications. However, =A0as is mentioned in RFC6378= , the indications my originate from other sources, e.g. control plane,or a = lower (e.g. physical) layer.
  • Very last par= a "=85 there is the necessity for the ring to maintain enough capacity= for all of the data in both directions around the ring" seems as too = strong requirement considering cases of 1:N linear and shared mesh protecti= on, where bandwidth of a protection path shared.
yw>> I am not su= re that I understand the relevance to this document that is addressing prot= ection on a "ring" - not sure that there is a requirement in a ri= ng to support these additional (1:n or SMP) protection. =A0=A0
  • Section 2.3
  • "=85 since we will perform all of the OAM functionality on the SPM= E configured for the traffic, we can minimize the number of OAM sessions ne= eded to monitor the data traffic of the ring - rather than monitoring each = individual LSP." Such improvement in OAM scale doesn't come for free as SPME OAM might introduce or hide connect= ivity and/or continuity defects of enclosed LSPs.
yw>> Can you elaborate on this? =A0Seems that this com= ment should be related to the MPLS-TP Framework document=A0
  • "In all = of the following subsections, we use 1:1 linear protection [SurvivFwk] [Lin= Protect] to perform protection switching and coordination when a signal fau= lt is detected." For 1:1 linear protection scope of the RFC 6378 is li= mited to bi-directional p2p MPLS-TP constructs. "Applicability of the protocol for 1:1 unidirectio= nal protection and for 1:n protection schemes may be documented in a future= document and is out of scope for this document", stated in section 1.= 2. Thus use of PSC for unidirectional p2p and p2mp MPLS-TP constructs is undefined. Perhaps this has to be mentioned = and reflected in change of the scope of the document.
yw>> As mentioned above (and in conjunction with t= he text referred to in your previous comment), the SPME is, by defintion, b= i-directional=A0
  • Section 2.3.1
  • First para "=85 each one acts as the ingress and egress in one dir= ection of the bidirectional SPME". I think that terminology "ingr= ess/egress MEP" is not the best and perhaps view of nodal MEP per LSP = is sufficient, so that no need to split MEP on given LSP per direction.
yw>> There was= no intention of splitting the MEP relative to its position on the node, wi= ll try and find a better way of referring to the MEP at the ingress and egr= ess points of the SPME.=A0
  • Section 2.3.2
  • I think that title of the section needs to say explicitly that link pro= tection by wrapping is discussed in the section (node protection in the 2.3= .3)
yw>> Corrected=A0
  • Section 2.3.3
  • As mentioned, in case of bi-directional co-routed LSP to which node pro= tection required (Figure 4) SPME approach is, effectively, segment, not loc= al protection. SPME level OAM between LSR A and LSR E monitors not only lin= k between LSR A and LSR F and LSR F but link between LSR F and LSR E as well (from LSP POV). The primary SPME= , effectively, changes ring topology by excluding LSR F from topology as LS= R F would not be processing LSP's outer label but process only SPME'= ;s outer label.
yw>> Not sure what correction you= are looking for in relation to this comment!=A0
  • Section 2.3.4
  • Local node protection monitors immediate link for link as well as node = protection. The difference between these protection modes in selection of a= MP, whether immediate neighbor can (link protection) or can not (node prot= ection) be used as MP. The section seems based on misunderstanding of difference between local link and node p= rotection and might be removed.
yw&= gt;> Can you provide some more detail or be more specific?=A0
  • Section 2.4
  • s/steeing/steering/
yw>> = Corrected=A0
  • What are three OAM sessions that each ring node will have if wrapping u= sed to protect the ring? I see two OAM sessions: immediate link to downstre= am LSR; around ring to the same LSR. Where the third OAM session?
yw>> This takes into account both link= and node protection which would require an OAM session on the alternate pr= otection SPME. =A0Will calrify in the next revision if this is OK with you.= =A0
  • "Special= consideration" seems as unfounded:
  • Not clear why CC/CV OAM in case of SPME steering viewed as insufficient= for fast defect detection.
yw>&= gt; Alarm reporting is justified in the OAM requirements document on the ba= sis of this argument that is merely repeated here.=A0
  • Local node an= d link protection are not mutualy exclusive. Local node protection provides= link protection as part of node protection. The problem, from my POV, is t= hat bi-directional co-routed LSP can not have local node protection but onl= y segment protection.
yw>> Again the question of whethe= r this goes beyond a question of semantics.=A0
  • Section 3
  • As noted earlier, applicability of RFC 6378 and PSC for 1:1 linear prot= ection of unidirectional MPLS-TP constructs, including unidirectional p2mp = LSP, not yet been defined. Neither CC/CV OAM on these constructs. What mech= anism(s) could be used to perform defect detection, coordination and protections switchover?
=
yw>> Could you be more specific regarding whi= ch text you would like to see corrected? =A0In general, the protection over= the ring is based on the use of a bi-directional SPME, and for the p2mp ca= ses use of Context-labels to allow distribution to the specific egress poin= ts =A0of the underlying LSPs.
  • Section 4
  • As as stated in RFC 6378 "Applicability of the protocol [PSC, my n= ote] for 1:1 unidirectional protection and for 1:n protection schemes may b= e documented in a future document and is out of scope for this document&quo= t;.
yw>> And as =A0stated above in se= veral comments, SPME are bi-directional.
A note on textual conventions:
  • References are both direct RFC, e.g. [RFC4090], and content-based, i.e.= [TPReqs]. May consider choosing single style of referencing.
yw>> This will be corrected prior to publi= cation, it is just tedious during the progression of the document, while so= me of the other documents were still drafts.=A0
=A0
Thank you for your kind consideration.
=A0
=A0=A0=A0=A0=A0=A0=A0 Regards,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg
=A0
-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mp= ls-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Wednesday, September 19, 2012 3= :49 AM
Subject: [mpls] Working group last ca= ll on draft-ietf-mpls-tp-ring-protection
=A0
Working Group,
=A0
this is to start a two week working g= roup last call on draft-ietf-mpls-tp-ring-protection-02-txt.
=A0
Please note that there are two IPR di= sclosures # 1462 and=A0 # 1872 related to this document.
=A0
Please send your comments to the mpls= working group mailing lists (mpls@ietf.org).
=A0
The working group last call ends Octo= ber 3, 2012.
=A0
/Loa
for the mpls wg co-chairs
=A0
=A0
--
=A0
=A0
Loa Andersson=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 email: loa.andersson@ericsson.com=
Sr Strategy and Standards Manager=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 loa@pi.nu
Ericsson Inc=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 phone: +46 10 = 717 52 13
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +46 767 72 92 13 __________________= _____________________________
mpls mailing list
=A0

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




--
Thanx and BR,
yaacov

Still looking= for new opportunity

--bcaec54ee85a5e798004cd1ce659-- From wyaacov@gmail.com Sun Oct 28 04:52:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9797821F84D9; Sun, 28 Oct 2012 04:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.649 X-Spam-Level: * X-Spam-Status: No, score=1.649 tagged_above=-999 required=5 tests=[AWL=-2.047, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiZrBP-ZYKwr; Sun, 28 Oct 2012 04:52:27 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8762621F86F9; Sun, 28 Oct 2012 04:52:27 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4785738vbb.31 for ; Sun, 28 Oct 2012 04:52:26 -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=BOagx3myZV1NjHMbSgiy1RwBila0SOOtZgrhbCrsIoU=; b=uMEvjxlZriFf0m8rIv+Mom899Z4pQAQ3vK453R1a5JT9rXOIHe2rbjUcoSHiNFGD+i iJZGPPOlvjL3jQrQbeaDQVua9JNpnfN9bwps+zU/MnrQ3AnZrrL8xREWqWQPhI9qwqch O0d6L2eBiro+mGNmypssDDy1tHBS2PJQTz+uQi2281Y3d7tHn+F8yQL/EvWp7YrJiOp0 f+5E6wWRJNdbFd3COjIsvI7DrA+MfPhODgfjPrbkD6VT9BteVyDo4HJoAQ128RgIgJNp p0IJxIrTjorB+U++zGQnHKQA9/0+2xdgB4gNerXoiAp76vfrnV2QgWTtYFnUlW+AvCn4 SN4A== MIME-Version: 1.0 Received: by 10.52.93.238 with SMTP id cx14mr35433317vdb.42.1351425146482; Sun, 28 Oct 2012 04:52:26 -0700 (PDT) Received: by 10.58.254.194 with HTTP; Sun, 28 Oct 2012 04:52:26 -0700 (PDT) In-Reply-To: References: <5059A308.3050307@pi.nu> Date: Sun, 28 Oct 2012 13:52:26 +0200 Message-ID: From: Yaacov Weingarten To: yang.jian90@zte.com.cn Content-Type: multipart/alternative; boundary=20cf3071d090cbf11e04cd1d2fcd Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , mpls-bounces@ietf.org, draft-ietf-mpls-tp-ring-protection@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] =?gb2312?b?tPC4tDogV29ya2luZyBncm91cCBsYXN0IGNhbGwgb24g?= =?gb2312?b?ZHJhZnQtaWV0Zi1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbg==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 11:52:31 -0000 --20cf3071d090cbf11e04cd1d2fcd Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Jian, hi Thank you for your consideration of the draft and comment during the WGLC. After consideration of the many comments and reading of the LS received from the ITU I would like to provide my feedback to your comments. After careful reading of the ITU liaison statement, I do not see very many issues raised in that document that are relevant to this draft. The LS points to some scenarios of multiple failures across interconnected rings and claims that the mechanisms suggested in this draft cannot protect for these situations. However - 1. The specific scenarios mentioned in the LS seem to be easily covered by applying the mechanisms in this draft to each of the interconnected rings separately. 2. There is text at the end of the Introduction that clearly states that interconnected rings is for further study due to the large number of different scenarios that need to be addressed. Aside from this issue the LS includes a table of comparison between the mechanism that is provided in this draft with two other solutions that are not provided in the LS. The table itself contains what seem to be rather subjective judgements of the different mechanisms but nowhere indicates that the mechanisms mentioned in this draft are not workable. Seeing as this draft is an applicability statement and does not preclude any other mechanism from being developed, within the IETF, I am not sure what you are suggesting be addressed by the draft to satisfy your comments. Your clarification would be helpful. Thank you and BR, yaacov weingarten *Still looking for new opportunity.* On Sat, Sep 29, 2012 at 11:14 AM, wrote: > Hi All, > > I think we should address all the issues that ITU liaison mentioned. > > BR, > Jian > > > > > > Loa Andersson > > =B7=A2=BC=FE=C8=CB: = =CA=D5=BC=FE=C8=CB > mpls-bounces@i > etf.org =B3= =AD=CB=CD > "mpls@ietf.org" , > MPLS-TP ad hoc team > 2012-09-19 , > 18:48 draft-ietf-mpls-tp-ring-protection@to= o > ls.ietf.org, > "mpls-chairs@tools.ietf.org" > > =D6= =F7=CC=E2 > [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection > > > > > > > > > > > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 > related to this document. > > Please send your comments to the mpls working group mailing lists > (mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --20cf3071d090cbf11e04cd1d2fcd Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Jian, hi

Thank you for your considerati= on of the draft and comment during the WGLC.  After consideration of t= he many comments and reading of the LS received from the ITU I would like t= o provide my feedback to your comments.

After careful reading of the ITU liaison statement, I d= o not see very many issues raised in that document that are relevant to thi= s draft.  The LS points to some scenarios of multiple failures across = interconnected rings and claims that the mechanisms suggested in this draft= cannot protect for these situations.  However -
1. The specific scenarios mentioned in the LS seem to be easily covere= d by applying the mechanisms in this draft to each of the interconnected ri= ngs separately.
2. There is text at the end of the Introduction t= hat clearly states that interconnected rings is for further study due to th= e large number of different scenarios that need to be addressed.

Aside from this issue the LS includes a table of compar= ison between the mechanism that is provided in this draft with two other so= lutions that are not provided in the LS.  The table itself contains wh= at seem to be rather subjective judgements of the different mechanisms but = nowhere indicates that the mechanisms mentioned in this draft are not worka= ble.  Seeing as this draft is an applicability statement and does not = preclude any other mechanism from being developed, within the IETF, I am no= t sure what you are suggesting be addressed by the draft to satisfy your co= mments.

Your clarification would be helpful.

Thank you and BR,
yaacov weingarten

Still looking for new opportunity.

On Sat, Sep 29, 2012 at 11:14 AM, <yang.j= ian90@zte.com.cn> wrote:
Hi All,

I think we should address all the issues that ITU liaison mentioned.

BR,
Jian





             Loa Andersson
             <loa@pi.nu>
             =B7=A2=BC=FE=C8=CB:   =                      = ;                     &nb= sp;  =CA=D5=BC=FE=C8=CB
             mpls-bounces@i
             etf.org             &nb= sp;                     &= nbsp;              =B3=AD=CB=CD
                     = ;               "mpls@ietf.org" <mpls@ietf.org>,
                     = ;               MPLS-TP ad hoc team
             2012-09-19     &n= bsp;       <ahmpls-tp@lists.itu.int>,
             18:48       =            draft-ietf-mpls-tp-ring-protection= @too
                     = ;               ls.ietf.org,
                     = ;               "mpls-chairs@tools.ietf.org"
                     = ;               <mpls-chairs@tools.ietf.org&= gt;
                     = ;                     &nb= sp;                     &= nbsp;     =D6=F7=CC=E2
                     = ;               [mpls] Working group las= t call on
                     = ;               draft-ietf-mpls-tp-ring-= protection










Working Group,

this is to start a two week working group last call on
draft-ietf-mpls-tp-ring-protection-02-txt.

Please note that there are two IPR disclosures # 1462 and  # 1872
related to this document.

Please send your comments to the mpls working group mailing lists
(mpls@ietf.org).

The working group last call ends October 3, 2012.

/Loa
for the mpls wg co-chairs


--


Loa Andersson                  = ;       email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            = loa@pi.nu
Ericsson Inc                  =        phone: +46 10 717 52 13
                     = ;                     &nb= sp;   +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

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



--
=
Thanx and BR,
yaacov

Still= looking for new opportunity

--20cf3071d090cbf11e04cd1d2fcd-- From wyaacov@gmail.com Sun Oct 28 05:12:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0DB21F84D5 for ; Sun, 28 Oct 2012 05:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.42 X-Spam-Level: X-Spam-Status: No, score=0.42 tagged_above=-999 required=5 tests=[AWL=1.229, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PY2HMARWUDVG for ; Sun, 28 Oct 2012 05:12:38 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A704C21F848A for ; Sun, 28 Oct 2012 05:12:37 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4793888vbb.31 for ; Sun, 28 Oct 2012 05:12:37 -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=GR+s6f+15QjycGpCrxO5B+RhRRjHEeEaaUu/F7Q1iPU=; b=lbsA/c0DUIMSFmaBJ5EPTvX/yb4aZoLryVJkY/GmLA8XmQWYR1iS6dCI+GxK6UN4w4 qX51/ayZahcqUlN1TXi309H4UTWvcjkK5+roH4XtbN0XQzsiZcCKUCGhzT6xNUAsAcqF ZVHFYSxYRiIRaD9BAiVHbCHVXS+QRu0DbgoN5DvEdNfaNwLtZ/j+XGRulNpxW7UrEaz1 DD8BJ3932kMmIZ+vQ5cpaaJus5vLVfbX5md+r7l8Sem64MUarE9XZi5l+q2DobLyhb0e roIPW5crPxHml+5BECVkYPFEx3GALnLcoCVoQCOyc/T4oyIimVstzND3WxcF4ybVNcSi 7jsA== MIME-Version: 1.0 Received: by 10.52.36.201 with SMTP id s9mr35623041vdj.101.1351426356923; Sun, 28 Oct 2012 05:12:36 -0700 (PDT) Received: by 10.58.254.194 with HTTP; Sun, 28 Oct 2012 05:12:36 -0700 (PDT) In-Reply-To: <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> Date: Sun, 28 Oct 2012 14:12:36 +0200 Message-ID: From: Yaacov Weingarten To: Hejia Content-Type: multipart/alternative; boundary=20cf307ca01ef1cd8104cd1d77a5 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 12:12:39 -0000 --20cf307ca01ef1cd8104cd1d77a5 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Jia, hi Thank you for your comment regarding the draft. In preparing an updated version that would address your comments. However, while the analysis that you refer to does include descriptions of considerations that should be known, I do not see that there are any "deficiencies" that need to be "solved". In addition, the section does point to an operative conclusion, i.e. for efficiency use of Steering is recommended, on a working protection method based on the application of LP to a ring. If you could be more specific about what correction could be made to the document, it would be helpful. Please keep in mind that this document is an applicability statement. Thank you and BR, yaacov weingarten *Still looking for new opportunity.* On Sat, Sep 29, 2012 at 12:53 PM, Hejia wrote: > Do not support. > > Based on the analysis in Section 2.4 of > draft-ietf-mpls-tp-ring-protection-02, the ring protection scheme using > SPME as described, either wrapping or steering, does have deficiencies, > which IMHO should be better reconsidered and solved if possible. > > > B.R. > Jia > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] = =B4=FA=B1=ED Loa Andersson > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA9=D4=C219=C8=D5 18:49 > =B3=AD=CB=CD: mpls@ietf.org; MPLS-TP ad hoc team; > draft-ietf-mpls-tp-ring-protection@tools.ietf.org; > mpls-chairs@tools.ietf.org > =D6=F7=CC=E2: [mpls] Working group last call on draft-ietf-mpls-tp-ring-p= rotection > > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 > related to this document. > > Please send your comments to the mpls working group mailing lists > (mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --20cf307ca01ef1cd8104cd1d77a5 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Jia, hi

Thank you for your comment rega= rding the draft.  In preparing an updated version that would address y= our comments.  However, while the analysis that you refer to does incl= ude descriptions of considerations that should be known, I do not see that = there are any "deficiencies" that need to be "solved". =  In addition, the section does point to an operative conclusion, i.e. = for efficiency use of Steering is recommended, on a working protection meth= od based on the application of LP to a ring.

If you could be more specific about what correction cou= ld be made to the document, it would be helpful.

P= lease keep in mind that this document is an applicability statement.

Thank you and BR,
yaacov weingarten

Still looking for new opportunity.

On Sat, Sep 29, 2012 at 12:53 PM, Hejia = <hejia@huawei.com<= /a>> wrote:
Do not support.

Based on the analysis in Section 2.4 of draft-ietf-mpls-tp-ring-protection-= 02, the ring protection scheme using SPME as described, either wrapping or = steering, does have deficiencies, which IMHO should be better reconsidered = and solved if possible.


B.R.
Jia

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: mpls-bounces@i= etf.org [mailto:mpls-bounces@i= etf.org] =B4=FA=B1=ED Loa Andersson
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA9=D4=C219=C8=D5 18:49
=B3=AD=CB=CD: mpls@ietf.org; MPLS-TP a= d hoc team; draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: [mpls] Working group last call on dr= aft-ietf-mpls-tp-ring-protection

Working Group,

this is to start a two week working group last call on
draft-ietf-mpls-tp-ring-protection-02-txt.

Please note that there are two IPR disclosures # 1462 and  # 1872
related to this document.

Please send your comments to the mpls working group mailing lists
(mpls@ietf.org).

The working group last call ends October 3, 2012.

/Loa
for the mpls wg co-chairs


--


Loa Andersson                  = ;       email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            = loa@pi.nu
Ericsson Inc                  =        phone: +46 10 717 52 13
                     = ;                     &nb= sp;   +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
=
Thanx and BR,
yaacov

Still= looking for new opportunity

--20cf307ca01ef1cd8104cd1d77a5-- From wyaacov@gmail.com Sun Oct 28 05:33:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0636A21F8545 for ; Sun, 28 Oct 2012 05:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[AWL=2.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVNyQht9Rg2f for ; Sun, 28 Oct 2012 05:32:59 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18F5B21F855B for ; Sun, 28 Oct 2012 05:32:58 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4710019vcb.31 for ; Sun, 28 Oct 2012 05:32:58 -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=4EJWLmDzA9IFwaVRix3+61GH99zLBk/Xvd+AbGIm/I8=; b=Cn1Sfgt68HM3UbJlwXIaLBSnG0RaxKXo+Oj6Q8j+iXHsjmcxlVmHSyLwRqke+EarVM rCME53LBrcsHBXPPkikwMjHdOI6CtY2szPf/wWcxdVK8DhYdJd1mW7rPfQF0+tAoFbF/ ZeqgRAzdA+Hc6srs8oD/65WkjaT2UJjjROy/2b5l3fhwACftrqTVudyG75noinai6KiQ 6fFxrg9/ZuPsAwXN/BemCMQ1ETEYlIJLACaHcWb0gJ2rQZ6LiHM1VOEveTb4wS6KOwDe pwYngRawpIopWBkQjMVNNjNQ5A0BknkoTCDfVQy9NkAvTflkqxI+OoxkSJfp/TuQje7j WeiQ== MIME-Version: 1.0 Received: by 10.52.155.199 with SMTP id vy7mr36869442vdb.54.1351427577926; Sun, 28 Oct 2012 05:32:57 -0700 (PDT) Received: by 10.58.254.194 with HTTP; Sun, 28 Oct 2012 05:32:57 -0700 (PDT) In-Reply-To: References: <5059A308.3050307@pi.nu> Date: Sun, 28 Oct 2012 14:32:57 +0200 Message-ID: From: Yaacov Weingarten To: Gregory Mirsky Content-Type: multipart/alternative; boundary=bcaec53aef50b8d47004cd1dc0ea Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 12:33:01 -0000 --bcaec53aef50b8d47004cd1dc0ea Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Greg, hi Thank you for your further comments to the ring-protection applicability document. However, as I pointed out in my previous message, the applicability of linear protection is based on the use of SPME as the working and protection paths and being as these are bi-directional and seeing as this scope limitation (that you mention) is really to RFC6378 and should be known to the reader of this draft, I am not sure that it is appropriate to this document, although we will naturally follow the WG instructions. Thanx and BR, yaacov *Still looking for new opportunity.* On Wed, Oct 3, 2012 at 9:16 PM, Gregory Mirsky wrote: > Dear All, > I wanted to add a proposal to my comments: > > - As the document essentially describes application of MPLS-TP Linear > Protection to ring toplogies, it might be reasonable to have scope of = this > document match scope of the RFC 6378: > > > - 1:1 protection of bi-directional p2p LSP > - 1+1 protection of unidirectional p2p LSP > > Unidirectional p2mp LSP, both 1+1 and 1:1, as well as 1:1 protection of > unidirectional p2p can be set for further study. > > Regards, > Greg > _____________________________________________ > *From: *Gregory Mirsky > *Sent: *Monday, October 01, 2012 8:53 AM > *To: *draft-ietf-mpls-tp-ring-protection@tools.ietf.org; mpls@ietf.or= g; > MPLS-TP ad hoc team; mpls-chairs@tools.ietf.org > *Subject: *RE: [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection > > Dear Authors, Editors, WG Chairs, et al., > Please find my comments to the document below: > > - Section 2.1 > > > - Verbal explanation of the wrapping in the first paragraph might > benefit if LSRs be referenced as in Figure 1. > - As described, wrapping can provide local protection of > bi-directional co-routed LSP only in case of link failure. If node > protection requested, as mentioned in the third sentence of the first = para, > MP is not the downstream LSR but next down to downstream. If we expect= that > PLR in forward direction is MP in reverse direction of given bi-direct= ional > LSP, then we have case of segment, not local protection. (Same, I beli= eve, > applies to FRR of bi-directional co-routed p2p LSP). > - s/arounf/around/ > - Figure 1 I think that this figure illustrates wrapping of a single > direction in case of local link protection. If that is the intention, = then > caption might explicitly state that. If a case of a bi-directional LSP= to > be illustrated for local link protection, then another wrapped data pa= th > F-E-D-C-B-A might be added. > - "If protecting both the links and the nodes of a LSP, then, for a > ring with N nodes, there is a need for O(2N) alternate paths." I > assume that this estimate is for bi-directional co-routed p2p LSP. But > co-routed LSP implies coordinated protection which, as mentined before= , can > not be achieved for node protection with local protection. Coordinated= node > protection, if not end-to-end, can be in form of segment protection. > > > - Section 2.2 > > > - "The process of notifying the ingress node adds to the latency of > the protection switching process, after the detection of the fault > condition." I think that that is not necessarily true as ingress > notification doesn't have to be explicit but can be implicit if e2e CC= /CV > monitors working and protecting paths. > - Very last para "=85 there is the necessity for the ring to maintain > enough capacity for all of the data in both directions around the ring= " > seems as too strong requirement considering cases of 1:N linear and sh= ared > mesh protection, where bandwidth of a protection path shared. > > > - Section 2.3 > > > - "=85 since we will perform all of the OAM functionality on the SPME > configured for the traffic, we can minimize the number of OAM sessions > needed to monitor the data traffic of the ring - rather than monitorin= g > each individual LSP." Such improvement in OAM scale doesn't come for f= ree > as SPME OAM might introduce or hide connectivity and/or continuity def= ects > of enclosed LSPs. > - "In all of the following subsections, we use 1:1 linear protection > [SurvivFwk] [LinProtect] to perform protection switching and coordinat= ion > when a signal fault is detected." For 1:1 linear protection scope of t= he > RFC 6378 is limited to bi-directional p2p MPLS-TP constructs. > "Applicability of the protocol for 1:1 unidirectional protection and f= or > 1:n protection schemes may be documented in a future document and is o= ut of > scope for this document", stated in section 1.2. Thus use of PSC for > unidirectional p2p and p2mp MPLS-TP constructs is undefined. Perhaps t= his > has to be mentioned and reflected in change of the scope of the docume= nt. > > > - Section 2.3.1 > > > - First para "=85 each one acts as the ingress and egress in one > direction of the bidirectional SPME". I think that terminology > "ingress/egress MEP" is not the best and perhaps view of nodal MEP per= LSP > is sufficient, so that no need to split MEP on given LSP per direction= . > > > - Section 2.3.2 > > > - I think that title of the section needs to say explicitly that link > protection by wrapping is discussed in the section (node protection in= the > 2.3.3) > > > - Section 2.3.3 > > > - As mentioned, in case of bi-directional co-routed LSP to which node > protection required (Figure 4) SPME approach is, effectively, segment,= not > local protection. SPME level OAM between LSR A and LSR E monitors not = only > link between LSR A and LSR F and LSR F but link between LSR F and LSR = E as > well (from LSP POV). The primary SPME, effectively, changes ring topol= ogy > by excluding LSR F from topology as LSR F would not be processing LSP'= s > outer label but process only SPME's outer label. > > > - Section 2.3.4 > > > - Local node protection monitors immediate link for link as well as > node protection. The difference between these protection modes in sele= ction > of a MP, whether immediate neighbor can (link protection) or can not (= node > protection) be used as MP. The section seems based on misunderstanding= of > difference between local link and node protection and might be removed= . > > > - Section 2.4 > > > - s/steeing/steering/ > - What are three OAM sessions that each ring node will have if > wrapping used to protect the ring? I see two OAM sessions: immediate l= ink > to downstream LSR; around ring to the same LSR. Where the third OAM se= ssion? > - "Special consideration" seems as unfounded: > > > - Not clear why CC/CV OAM in case of SPME steering viewed as > insufficient for fast defect detection. > - Local node and link protection are not mutualy exclusive. Local node > protection provides link protection as part of node protection. The > problem, from my POV, is that bi-directional co-routed LSP can not hav= e > local node protection but only segment protection. > > > - Section 3 > > > - As noted earlier, applicability of RFC 6378 and PSC for 1:1 linear > protection of unidirectional MPLS-TP constructs, including unidirectio= nal > p2mp LSP, not yet been defined. Neither CC/CV OAM on these constructs.= What > mechanism(s) could be used to perform defect detection, coordination a= nd > protections switchover? > > > - Section 4 > > > - As as stated in RFC 6378 "Applicability of the protocol [PSC, my > note] for 1:1 unidirectional protection and for 1:n protection schemes= may > be documented in a future document and is out of scope for this docume= nt". > > A note on textual conventions: > > - References are both direct RFC, e.g. [RFC4090], and content-based, > i.e. [TPReqs]. May consider choosing single style of referencing. > > > Thank you for your kind consideration. > > Regards, > Greg > > -----Original Message----- > From: mpls-bounces@ietf.org [*mailto:mpls-bounces@ietf.org*] > On Behalf Of Loa Andersson > Sent: Wednesday, September 19, 2012 3:49 AM > Cc: mpls@ietf.org; MPLS-TP ad hoc team; > draft-ietf-mpls-tp-ring-protection@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: [mpls] Working group last call on > draft-ietf-mpls-tp-ring-protection > > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-ring-protection-02-txt. > > Please note that there are two IPR disclosures # 1462 and # 1872 related > to this document. > > Please send your comments to the mpls working group mailing lists ( > mpls@ietf.org). > > The working group last call ends October 3, 2012. > > /Loa > for the mpls wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13___________= ____________________________________ > mpls mailing list > mpls@ietf.org > *https://www.ietf.org/mailman/listinfo/mpls* > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --bcaec53aef50b8d47004cd1dc0ea Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Greg, hi

Thank you for your further com= ments to the ring-protection applicability document. =A0However, as I point= ed out in my previous message, the applicability of linear protection is ba= sed on the use of SPME as the working and protection paths and being as the= se are bi-directional and seeing as this scope limitation (that you mention= ) is really to RFC6378 and should be known to the reader of this draft, I a= m not sure that it is appropriate to this document, although we will natura= lly follow the WG instructions.

Thanx and BR,
yaacov

Still looking for new opportunity.

On Wed, Oct 3, 2012 at 9:16 PM, Gregory Mirsky <gregory.mirsky= @ericsson.com> wrote:
Dear All,
I wanted to add a proposal to my comments:
  • As the document essentially describes application of MPLS-TP Linear Pro= tection to ring toplogies, it might be reasonable to have scope of this doc= ument match scope of the RFC 6378:
    •
  • 1:1 protection of bi-directional p2p LSP
  • 1+1 protection of unid= irectional p2p LSP
    •
Unidirectional p2m= p LSP, both 1+1 and 1:1, as well as 1:1 protection of unidirectional p2p ca= n be set for further study.
=A0
=A0=A0=A0=A0=A0=A0=A0 Regards,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Greg
_________________________= ____________________
From:=A0=A0=A0 Gregory Mirsky=A0
Sent:=A0=A0 Monday, October 01, 2012 8:53 AM
Subject:=A0=A0=A0=A0=A0=A0=A0 RE: [mpls] Working group last call = on draft-ietf-mpls-tp-ring-protection
=A0
Dear Authors, Editors, WG Chairs, et al.,
Please find my comments to the document below:
  • Section 2.1
  • Verbal explanation of the wrapping in the first paragraph might benefit= if LSRs be referenced as in Figure 1.
  • As described, wrapping can p= rovide local protection of bi-directional co-routed LSP only in case of lin= k failure. If node protection requested, as mentioned in the third sentence= of the first para, MP is not the downstream LSR but next down to downstrea= m. If we expect that PLR in forward direction is MP in reverse direction of gi= ven bi-directional LSP, then we have case of segment, not local protection.= (Same, I believe, applies to FRR of bi-directional co-routed p2p LSP).
  • s/arounf/around/
  • Figure 1 I think that this figure illustrates = wrapping of a single direction in case of local link protection. If that is= the intention, then caption might explicitly state that. If a case of a bi= -directional LSP to be illustrated for local link protection, then another wrapped data path F-E-D-C-B-A might be added.
  • "If protecting both the links and the nodes o= f a LSP, then, for a ring with N no= des, there is a need for O(2N) alte= rnate paths." I assume that this estimate is for bi-directional co-routed p2p LSP. But co-routed LSP im= plies coordinated protection which, as mentined before, can not be achieved= for node protection with local protection. Coordinated node protection, if= not end-to-end, can be in form of segment protection.
  • Section 2.2
  • "The process of notifying the ingress node adds to the latency of = the protection switching process, after the detection of the fault conditio= n." I think that that is not necessarily true as ingress notification = doesn't have to be explicit but can be implicit if e2e CC/CV monitors working and protecting paths.
  • Very last para = "=85 there is the necessity for the ring to maintain enough capacity f= or all of the data in both directions around the ring" seems as too st= rong requirement considering cases of 1:N linear and shared mesh protection= , where bandwidth of a protection path shared.
  • Section 2.3
  • "=85 since we will perform all of the OAM functionality on the SPM= E configured for the traffic, we can minimize the number of OAM sessions ne= eded to monitor the data traffic of the ring - rather than monitoring each = individual LSP." Such improvement in OAM scale doesn't come for free as SPME OAM might introduce or hide connect= ivity and/or continuity defects of enclosed LSPs.
  • "In all of t= he following subsections, we use 1:1 linear protection [SurvivFwk] [LinProt= ect] to perform protection switching and coordination when a signal fault i= s detected." For 1:1 linear protection scope of the RFC 6378 is limite= d to bi-directional p2p MPLS-TP constructs. "Applicability of the protocol for 1:1 unidirectio= nal protection and for 1:n protection schemes may be documented in a future= document and is out of scope for this document", stated in section 1.= 2. Thus use of PSC for unidirectional p2p and p2mp MPLS-TP constructs is undefined. Perhaps this has to be mentioned = and reflected in change of the scope of the document.
  • Section 2.3.1
  • First para "=85 each one acts as the ingress and egress in one dir= ection of the bidirectional SPME". I think that terminology "ingr= ess/egress MEP" is not the best and perhaps view of nodal MEP per LSP = is sufficient, so that no need to split MEP on given LSP per direction.
  • Section 2.3.2
  • I think that title of the section needs to say explicitly that link pro= tection by wrapping is discussed in the section (node protection in the 2.3= .3)
  • Section 2.3.3
  • As mentioned, in case of bi-directional co-routed LSP to which node pro= tection required (Figure 4) SPME approach is, effectively, segment, not loc= al protection. SPME level OAM between LSR A and LSR E monitors not only lin= k between LSR A and LSR F and LSR F but link between LSR F and LSR E as well (from LSP POV). The primary SPME= , effectively, changes ring topology by excluding LSR F from topology as LS= R F would not be processing LSP's outer label but process only SPME'= ;s outer label.
  • Section 2.3.4
  • Local node protection monitors immediate link for link as well as node = protection. The difference between these protection modes in selection of a= MP, whether immediate neighbor can (link protection) or can not (node prot= ection) be used as MP. The section seems based on misunderstanding of difference between local link and node p= rotection and might be removed.
  • Section 2.4
  • s/steeing/steering/
  • What are three OAM sessions that each ring = node will have if wrapping used to protect the ring? I see two OAM sessions= : immediate link to downstream LSR; around ring to the same LSR. Where the = third OAM session?
  • "Special consideration" seems as unfounded:
  • Not clear why CC/CV OAM in case of SPME steering viewed as insufficient= for fast defect detection.
  • Local node and link protection are not = mutualy exclusive. Local node protection provides link protection as part o= f node protection. The problem, from my POV, is that bi-directional co-rout= ed LSP can not have local node protection but only segment protection.
  • Section 3
  • As noted earlier, applicability of RFC 6378 and PSC for 1:1 linear prot= ection of unidirectional MPLS-TP constructs, including unidirectional p2mp = LSP, not yet been defined. Neither CC/CV OAM on these constructs. What mech= anism(s) could be used to perform defect detection, coordination and protections switchover?
  • Section 4
  • As as stated in RFC 6378 "Applicability of the protocol [PSC, my n= ote] for 1:1 unidirectional protection and for 1:n protection schemes may b= e documented in a future document and is out of scope for this document&quo= t;.
A note on textual conventions:
  • References are both direct RFC, e.g. [RFC4090], and content-based, i.e.= [TPReqs]. May consider choosing single style of referencing.
=A0
Thank you for your kind consideration.
=A0
=A0=A0=A0=A0=A0=A0=A0 Regards,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg
=A0
-----Or= iginal Message-----
From: mpls-bounces@ietf.org [mailto:mp= ls-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Wednesday, September 19, 2012 3= :49 AM
Subject: [mpls] Working group last ca= ll on draft-ietf-mpls-tp-ring-protection
=A0
Working Group,
=A0
this is to start a two week working g= roup last call on draft-ietf-mpls-tp-ring-protection-02-txt.
=A0
Please note that there are two IPR di= sclosures # 1462 and=A0 # 1872 related to this document.
=A0
Please send your comments to the mpls= working group mailing lists (mpls@ietf.org).
=A0
The working group last call ends Octo= ber 3, 2012.
=A0
/Loa
for the mpls wg co-chairs
=A0
=A0
--
=A0
=A0
Loa Andersson=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 email: loa.andersson@ericsson.com=
Sr Strategy and Standards Manager=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 loa@pi.nu
Ericsson Inc=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 phone: +46 10 = 717 52 13
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +46 767 72 92 13 __________________= _____________________________
mpls mailing list
=A0

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




--
Thanx and BR,
yaacov

Still looking= for new opportunity

--bcaec53aef50b8d47004cd1dc0ea-- From wyaacov@gmail.com Sun Oct 28 05:53:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2C321F86F4 for ; Sun, 28 Oct 2012 05:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AukNaM0zEpOx for ; Sun, 28 Oct 2012 05:53:25 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B08021F86DC for ; Sun, 28 Oct 2012 05:53:25 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4718769vcb.31 for ; Sun, 28 Oct 2012 05:53:24 -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=p7gvFwDV55zrpfkFWzZrLyDZJtaxbusOcMAiXN80X58=; b=MbsOgtxChaE1AT3k9N+R978+7WNAoGcfhvuJxayvePsaPamtmy2jjEsR3QW6xT0phr GiYXZZ4Cbv7SqiaCO0czL1DfpulGQufOOXR0JYDWvU/okC0jQcFh5C0TwgxZQitqIwMS Y+wz6P3c6vBrfXgnd8t3xXxWISmKiE3PD3pyPl9prYNgMvRyR80tqbe7Mfd1rQKtR1Pu +SPLEW0cbSdGrloYLqKUu2MQ6ulzS09b7QOnA8lSG58OoOL6klJJrrydnQUoHttXAf8e wP2Q5+5YfsrwalTISgvpNcbtwhKgOz9oPjNG73IPURaLiMZPwkZXyT/xbnQ94UtuOf8m oqvA== MIME-Version: 1.0 Received: by 10.220.227.199 with SMTP id jb7mr25836714vcb.26.1351428804391; Sun, 28 Oct 2012 05:53:24 -0700 (PDT) Received: by 10.58.254.194 with HTTP; Sun, 28 Oct 2012 05:53:24 -0700 (PDT) In-Reply-To: References: <0c4c01cda0a7$8f112320$ad336960$@olddog.co.uk> Date: Sun, 28 Oct 2012 14:53:24 +0200 Message-ID: From: Yaacov Weingarten To: cheng weiqiang Content-Type: multipart/alternative; boundary=14dae9cdca9bd331f104cd1e0943 Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-ring-protection@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 12:53:26 -0000 --14dae9cdca9bd331f104cd1e0943 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cheng, hi Thank you for your comments regarding the ring protection applicability statement. I find your scenarios as being very interesting and understand the concenr in certain networks for the prevelance of such scenarios. While I agree with your analysis that the Wrapping solution that is proposed in the draft would have difficulty in addressing the scenarios of multiple failures in adjacent nodes or links, I think that this just strenghthens the recommnedation of Section 2.4 that it is better to apply Steering as a preferred methoid of protection. In addition to the considerations mentioned in Section 2.4, Steering would easily overcome the scenarios that you mention and is an easy application of LP to the ring scenarios. Regarding your second point, I would like to clarify that, in my understanding, the optimization criteria mentioned in RFC5654 are optimizations compared to using linear protection to protect each individual LSP, which this draft certainly optimizes by protecting the SPME that tunnels numerous LSPs and therefore provides the desired optimization. The optimization certainly was never intended to be relative to a theoretical protection scheme that extends MPLS beyond its present definition by using constructs that are not supported in MPLS. Hope this helps, yaacov weingarten *Still looking for new opportunity.* On Wed, Oct 3, 2012 at 11:40 AM, cheng weiqiang wrote: > Dear adrian, > > Here I would like to try to describe some issues on the ring > protection solution from my point view. > > 1. The Wrapping solution doesn=92t work when Multi-links faults happen > > For each link in the ring, current wrapping solution defines two SPME > - the first is a SPME between the two LSRs that are connected by the > link,and the second SPME > > between these same two LSRs but traversing the entire ring (except the > link that connects the LSRs). > > ___ ___ x ___ > =3D=3D=3D=3D=3D=3D>/LSR\********/LSR\********/LSR\ > \_B_/ \_A_/ \_F_/ > * > * > * > * > * > *x > _* ___ > *_ > > /LSR\********/LSR\********/LSR\=3D=3D=3D=3D=3D=3D> > \_C_/ \_D_/ \_E_/ > > =3D=3D=3D> connected LSP *** physical link > x link fault > > > Above figure shows that One LSP enter the ring from LSR B and Exit > from LSR E. And at the same time the link A-F and link F-E are both > broken.According to current > > solution, both the protection SPME for A-F and the protection SPME for > Link F-E should be activated synchronously. Obviously, it does not > work. > > At the same situation, the ring protection for SDH, G.8132(T-MPLS) and > the MSRP solution (C-2098 =93MPLS-TP Shared-Ring protection (MSRP) > mechanism for ring topology", > > ITU-T SG15 meeting, Sep. 2012) can work well. > > 2.Steering function is totally the same with 1:1 linear protection > > As the draft mentioned "we use 1:1 linear protection [SurvivFwk] > [LinProtect] to perform protection switching and coordination when a > signal fault is detected." It is > > the basic 1:1 linear protection(we can see it as a SNC protection,in > another words 1:1 linear protection is using in sub-network). > > It does not provide any more simplicity and optimism than 1:1 linear > protection. That is why we say this draft cannot meet R100 of RFC5654 > the requirement. > > > So I don't think we need defined it in the ring draft redundantly again. > > > > Best Regards, > > Cheng Weiqiang > Research Institute of China Mobile > e-mail:chengweiqiang@chinamobile.com > mobile: +86 138 1001 9089 > > > > > 2012/10/2 Adrian Farrel : > > Hi, > > > > Let me pitch in here as an individual contributor who sourced a lot of > the text > > in 2.5.6.1 of RFC 5654 basing it on the explicit requirements liaised > from the > > ITU-T. > > > > I have read and reread that section trying to find the text that is > claimed > > below. It does not exist. > > > > Could you please point to the specific requirement you believe is not > met? Or > > maybe you are confused by the preamble text in the section that > describes the > > circumstances under which an optimized protection mechanism (rather tha= n > one > > built from the mechanisms that operate outside a ring) might be > developed. > > > > Maybe, also, you could explain in what way you consider the current > proposal > > does not make good use of the resources on the ring (i.e. what features > don't > > work) so that the authors can look at improving their solution. > > > > Cheers, > > Adrian > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf O= f > >> cheng weiqiang > >> Sent: 02 October 2012 14:02 > >> To: mpls-bounces@ietf.org > >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-ring= - > >> protection@tools.ietf.org > >> Subject: Re: [mpls] Working group last call on > > draft-ietf-mpls-tp-ring-protection > >> > >> Do not support. > >> > >> In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should be > >> optimized for simplification of the ring operation and the resources > >> consumption around the ring. This draft cannot meet the requirement. > >> > >> Best Regards, > >> > >> Cheng Weiqiang > >> Research Institute of China Mobile > >> Department of Network Technology > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --14dae9cdca9bd331f104cd1e0943 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Cheng, hi

Thank you for your comments r= egarding the ring protection applicability statement. =A0

I find your scenarios as being very interesting and understand the = concenr in certain networks for the prevelance of such scenarios. =A0While = I agree with your analysis that the Wrapping solution that is proposed in t= he draft would have difficulty in addressing the scenarios of multiple fail= ures in adjacent nodes or links, I think that this just strenghthens the re= commnedation of Section 2.4 that it is better to apply Steering as a prefer= red methoid of protection. =A0In addition to the considerations mentioned i= n Section 2.4, Steering would easily overcome the scenarios that you mentio= n and is an easy application of LP to the ring scenarios.

Regarding your second point, I would like to clarify th= at, in my understanding, the optimization criteria mentioned in RFC5654 are= optimizations compared to using linear protection to protect each individu= al LSP, which this draft certainly optimizes by protecting the SPME that tu= nnels numerous LSPs and therefore provides the desired optimization. =A0The= optimization certainly was never intended to be relative to a theoretical = protection scheme that extends MPLS beyond its present definition by using = constructs that are not supported in MPLS.

Hope this helps,
yaacov weingarten
=
Still looking for new opportunity.

On Wed, Oct 3, 2012 at 11:40 AM, cheng weiqiang <chengwq= @gmail.com> wrote:
Dear adrian,

Here I would like to try to describe some issues on the ring
protection solution from my point view.

1. The Wrapping solution doesn=92t work when Multi-links faults happen

For each link in the ring, current wrapping solution defines two SPME
- the first is a SPME between the two LSRs that are connected by the
link,and the second SPME

between these same two LSRs but traversing the entire ring (except the
link that connects the LSRs).

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ___= =A0 =A0 =A0 =A0 =A0 =A0 =A0___ =A0 =A0 x =A0 =A0 =A0 ___
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D=3D=3D=3D=3D=3D>/LSR\********= /LSR\********/LSR\
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\_B_= / =A0 =A0 =A0 =A0 =A0 =A0\_A_/ =A0 =A0 =A0 =A0 =A0 \_F_/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 *
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 *
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 *x
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _* = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ___ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*_

/LSR\********/LSR\********/LSR\=3D=3D=3D=3D=3D=3D>
=A0 =A0 =A0 =A0 \_C_/ =A0 =A0 =A0 =A0 =A0 =A0\_D_/ =A0 =A0 =A0 =A0 =A0 =A0\= _E_/

=A0 =A0 =A0 =A0 =A0 =A0 =3D=3D=3D> connected LSP =A0 =A0*** physical lin= k
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0x =A0 link fault


Above figure shows that One LSP enter the ring from LSR B and Exit
from LSR E. And at the same time the link A-F and link F-E are both
broken.According to current

solution, both the protection SPME for A-F and the protection SPME for
Link F-E should be activated synchronously. Obviously, it does not
work.

At the same situation, the ring protection for SDH, G.8132(T-MPLS) and
the MSRP solution (C-2098 =93MPLS-TP Shared-Ring protection (MSRP)
mechanism for ring topology",

ITU-T SG15 meeting, Sep. 2012) can work well.

2.Steering function is totally the same with 1:1 linear protection

As the draft mentioned "we use 1:1 linear protection [SurvivFwk]
[LinProtect] to perform protection switching and coordina= tion when a
signal fault is detected." It is

the basic 1:1 linear protection(we can see it as a SNC protection,in
another words 1:1 linear protection is using in sub-network).

It does not provide any more simplicity and optimism than 1:1 linear
protection. That is why we say this draft cannot meet R100 of RFC5654
the requirement.


So I don't think we need defined it in the ring draft redundantly again= .



Best Regards,

Cheng Weiqiang
Research Institute of China Mobile
e-mail:chen= gweiqiang@chinamobile.com
mobile: = +86 138 1001 9089




2012/10/2 Adrian Farrel <adrian@o= lddog.co.uk>:
> Hi,
>
> Let me pitch in here as an individual contributor who sourced a lot of= the text
> in 2.5.6.1 of RFC 5654 basing it on the explicit requirements liaised = from the
> ITU-T.
>
> I have read and reread that section trying to find the text that is cl= aimed
> below. It does not exist.
>
> Could you please point to the specific requirement you believe is not = met? Or
> maybe you are confused by the preamble text in the section that descri= bes the
> circumstances under which an optimized protection mechanism (rather th= an one
> built from the mechanisms that operate outside a ring) might be develo= ped.
>
> Maybe, also, you could explain in what way you consider the current pr= oposal
> does not make good use of the resources on the ring (i.e. what feature= s don't
> work) so that the authors can look at improving their solution.
>
> Cheers,
> Adrian
>
>> -----Original Message-----
>> From: mpls-bounces@ietf.o= rg [mailto:mpls-bounces@ietf.o= rg] On Behalf Of
>> cheng weiqiang
>> Sent: 02 October 2012 14:02
>> To: mpls-bounces@ietf.org=
>> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-i= etf-mpls-tp-ring-
>> protection@tools.ietf= .org
>> Subject: Re: [mpls] Working group last call on
> draft-ietf-mpls-tp-ring-protection
>>
>> Do not support.
>>
>> In Section 2.5.6.1 of RFC5654, the MPLS-TP ring protection should = be
>> optimized for simplification of the ring operation and the resourc= es
>> consumption around the ring. This draft cannot meet the requiremen= t.
>>
>> Best Regards,
>>
>> Cheng Weiqiang
>> Research Institute of China Mobile
>> Department of Network Technology
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
=
Thanx and BR,
yaacov

Still= looking for new opportunity

--14dae9cdca9bd331f104cd1e0943-- From wyaacov@gmail.com Sun Oct 28 06:02:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F079B21F843D for ; Sun, 28 Oct 2012 06:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=1.448, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PG0CJb14QTBH for ; Sun, 28 Oct 2012 06:02:38 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4880E21F86DB for ; Sun, 28 Oct 2012 06:02:38 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4722980vcb.31 for ; Sun, 28 Oct 2012 06:02:37 -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=FurEjmAnKWdFqlndEfx+CVZv3pNR7pGa/gYum6RCsos=; b=u6u+7y0bk2ICJvch9o7WZQ0/DD2gMnSEKE0hjt8pxx4cMCQCTe16Qvi+TMp7qI8Qbl cBU+T7LrF8hA0skKknvkvQ20xaGfQlWDUDorHk9hLPG9kgSXmL9gsELdGCpMWbc5ooYj HgXoYEr0DmbInFvU6zVgaKMqbInUbvNiH+ZfZvJU4WbsIld2uGgxK3esn4SB2ZyLxJgY JHRzpmKNrNorklIKDlofMRSYokh9bgJ2NV1FLDR/xeDRyAg/Bi90FrhivCnnG7BXJY9z NN5c4LkapspETmlsbyynSrhHXoTdW29o4HvftchhK6vOwUSb7cfZ68qwl/+BXaWo5SQl Us8Q== MIME-Version: 1.0 Received: by 10.58.15.227 with SMTP id a3mr49097796ved.38.1351429357814; Sun, 28 Oct 2012 06:02:37 -0700 (PDT) Received: by 10.58.254.194 with HTTP; Sun, 28 Oct 2012 06:02:37 -0700 (PDT) In-Reply-To: References: <0e2901cda16b$09f5d1d0$1de17570$@olddog.co.uk> Date: Sun, 28 Oct 2012 15:02:37 +0200 Message-ID: From: Yaacov Weingarten To: cheng weiqiang Content-Type: multipart/alternative; boundary=047d7b5daf50cfc36c04cd1e2aaf Cc: mpls@ietf.org, ahmpls-tp@lists.itu.int, draft-ietf-mpls-tp-ring-protection@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] [AHMPLS-TP] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 13:02:39 -0000 --047d7b5daf50cfc36c04cd1e2aaf Content-Type: text/plain; charset=ISO-8859-1 Cheng, hi Thank you for you additional comment on the draft. I would like to point out that there is a statement at the end of the Introduction section that states that the considerations of interconnected rings include very many scenarios and is for further study and should be addressed in a separate document. Hope this helps, yaacov weingarten *Still looking for new opportunity.* On Wed, Oct 3, 2012 at 5:23 PM, cheng weiqiang wrote: > Support. > > And additional question to authors: > > R27 of RFC 5654 requires " B. It MUST be possible to deploy MPLS-TP > in arbitrarily interconnected rings with one or two points of > interconnection. " > > Arccording the draft solution, It seems very hard to implement it. > Could you give more information on "How the solution in draft to > implement it" ? > > > > Best Regards, > > Cheng Weiqiang > Research Institute of China Mobile > e-mail:chengweiqiang@chinamobile.com > mobile: +86 138 1001 9089 > -- Thanx and BR, yaacov *Still looking for new opportunity* --047d7b5daf50cfc36c04cd1e2aaf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Cheng, hi

Thank you for you additional = comment on the draft.

I would like to point out th= at there is a statement at the end of the Introduction section that states = that the considerations of interconnected rings include very many scenarios= and is for further study and should be addressed in a separate document. = =A0

Hope this helps,
yaacov weingarten
=
Still looking for new opportunity.

On Wed, Oct 3, 2012 at 5:23 PM, cheng weiqiang <chengwq= @gmail.com> wrote:
Support.

And additional question to authors:

R27 of RFC 5654 requires " B. =A0It MUST be possible to deploy MPLS-TP=
in arbitrarily interconnected rings with one or two points of
interconnection. "

Arccording the draft solution, It seems very hard to implement it.
Could you give more information on "How the solution in draft to
implement it" ?



Best Regards,

Cheng Weiqiang
Research Institute of China Mobile
e-mail:chengweiqi= ang@chinamobile.com
mobile: = +86 138 1001 9089



--
=
Thanx and BR,
yaacov

Still= looking for new opportunity

--047d7b5daf50cfc36c04cd1e2aaf-- From wyaacov@gmail.com Sun Oct 28 06:17:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F19D21F85E3 for ; Sun, 28 Oct 2012 06:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCWaYdezo0Ji for ; Sun, 28 Oct 2012 06:17:33 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42DB621F85DF for ; Sun, 28 Oct 2012 06:17:33 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4821751vbb.31 for ; Sun, 28 Oct 2012 06:17:32 -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=q733YnVLfiboomofF7m6h25MLIy5AfeZSYLR11vN7Kk=; b=mPBinbCHNreHKZw9MZzW7W0JkvboylTxclRjoX4CQeyL4Akl6qZThdMxTgjpq0pRK+ yazVFbbm3LQ28MNMcAnuDWuDWK9+DbDEmVvLewJU/+zWurjlvaAeQnISB+LtX2P5Z2nA TmDLOv8w1J/oCgAKQp15t4+eErk7xZVIZDWYBM7wytwS1QYGwhMYL7Byh24936ix0Q1L yUCe1IrLDCUBRsHJEZJv7ufpOHYftux3C2HTolDkdaYkIhUQsah/D44eSWFevTX3q6qg ndgO6nXwSKg8ZQxDTDUCisWDqA6EDmEcOjTTukLHgwCcrpX5F06+N51outMpqSD48Xg8 6hww== MIME-Version: 1.0 Received: by 10.58.15.227 with SMTP id a3mr49149150ved.38.1351430252601; Sun, 28 Oct 2012 06:17:32 -0700 (PDT) Received: by 10.58.254.194 with HTTP; Sun, 28 Oct 2012 06:17:32 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Oct 2012 15:17:32 +0200 Message-ID: From: Yaacov Weingarten To: "D'Alessandro Alessandro Gerardo" Content-Type: multipart/alternative; boundary=047d7b5daf502520fe04cd1e6025 Cc: "mpls@ietf.org" Subject: Re: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 13:17:34 -0000 --047d7b5daf502520fe04cd1e6025 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Alessandro, hi Thank you for your detailed list of comments to the draft. I will try to address your concerns below while I attempt to publish an updated version of the draft that would address your concerns. I would like to reiterate a point that was made by several of the respondents to this very interesting LC correspondence - the document in question is merely an applicability statement intended to be an Informative IETF document pointing out that it is possible to apply linear protection to a "ring topology" in MPLS-TP. This does not preclude the discussion of any other mechanism that may be proposed based on existing MPLS constructs, or by proposing new constructs - after these are fully defined in the MPLS community. My calrifications are provided inline below (prefixed by "yw>>"). Hope this helps, yaacov weingarten *Still looking for new opportunity.* On Wed, Oct 3, 2012 at 5:03 PM, D'Alessandro Alessandro Gerardo < alessandro.dalessandro@telecomitalia.it> wrote: > Dear authors of draft-ietf-mpls-tp-ring-protection-02,**** > > Could you please clarify the following points**** > > ** ** > > 2.1. Wrapping**** > > In this figure we have a ring with a LSP that enters the ring at LS= R-B > and exits at LSR-E. The normal working path follows through B-A-F-E. = If > a fault is detected on the link A<-->F, then the wrapping mechanism > decides that LSR-A would wrap the traffic around the ring, on a > wrapped data path A-B-C-D-E-F, to arrive at LSR-F (on the far side of > the failed link). LSR-F would then wrap the data packets back onto > the working path F-->E to the egress node. In this protection scheme, > the traffic will follow the path B-A-B-C-D-E-F-E.**** > > Figure 1 and the text above seems not to be aligned. What is the intended > behavior? > yw>> Figure 1 will be corrected to show the protection path connecting to the proper node, this had been pointed out to the authors by other commenters. > **** > > ** ** > > ** ** > > 2.1. Wrapping**** > > If a double-fault situation occurs in the ring, then wrapping will no= t > be able to deliver any packets except between the ingress and the first > fault location.**** > > How is defined first/second fault location in a ring? is =93first=94 tim= e or > location related? Can you please elaborate a little bit this concept? > yw>> Not sure that I understand the difficulty in understanding, nor am I sure whether the "first" refers to the node that failed before the other or the one that is encountered earlier along the path since the statement is clearly stating that this would cause a complete disconnect situation. Could you please provide a suggestion for text that would help your comprehension of the limitation? > **** > > ** ** > > Best regards,**** > > Alessandro **** > > ------------------------------------------------------------------ > *Telecom Italia > *Alessandro Gerardo D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino* > *phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07**** > > ** ** > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =E8 necessario.* > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --047d7b5daf502520fe04cd1e6025 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Alessandro, hi

Thank you for your detai= led list of comments to the draft. =A0I will try to address your concerns b= elow while I attempt to publish an updated version of the draft that would = address your concerns.

I would like to reiterate a point that was made by seve= ral of the respondents to this very interesting LC correspondence - the doc= ument in question is merely an applicability statement intended to be an In= formative IETF document pointing out that it is possible to apply linear pr= otection to a "ring topology" in MPLS-TP. =A0This does not preclu= de the discussion of any other mechanism that may be proposed based on exis= ting MPLS constructs, or by proposing new constructs - after these are full= y defined in the MPLS community.

My calrifications are provided inline below (prefixed b= y "yw>>").

Hope this helps,
<= div>yaacov weingarten

Still looking for new opp= ortunity.

On Wed, Oct 3, 2012 at 5:03 PM, D'Alessa= ndro Alessandro Gerardo <alessandro.dalessandro@tele= comitalia.it> wrote:

Dear authors of draft-ietf-mpls-tp-ring-protection-0= 2,

Could you please clarify the following points<= /span>

=A0

2.1.=A0 Wrapping

=A0=A0 In this figure we have a ring wi= th a LSP that enters the ring at=A0=A0=A0 LSR-B and exits at LSR-E.=A0 The normal working path fo= llows through=A0=A0 B-A-F-E.=A0 If a fault is detected on the link A<--&= gt;F, then the=A0=A0 wrapping mechanism decides that LSR-A would wrap the traffic around<= span>=A0=A0=A0 the ring, on a wrapped data path A-B-C-D-E-F, to arrive at LSR-F (on= =A0=A0=A0 the far side of the failed link).=A0 LSR-F would then w= rap the data=A0=A0=A0 packets back onto the working path F-->E to the egress node.=A0 In this=A0=A0=A0 protection scheme, the traffic will fo= llow the path=A0=A0=A0 B-A-B-C-D-E-F-E.

Figure 1 and the text abov= e seems not to be aligned. What is the intended behavior?

yw>> Figure 1 will be corrected to show t= he protection path connecting to the proper node, this had been pointed out= to the authors by other commenters.=A0

=A0

=A0

2.1.=A0 Wrapping

If a double-fault situation occurs in the ring, then= wrapping will=A0=A0=A0=A0 not be able to deliver any packets except between the ingress and=A0=A0 the first fault location.

How is defined first/second=A0 fault location in a ring? is =93first=94 time or= location related? Can you please elaborate a little bit this concept?

yw>> Not sure that I understand t= he difficulty in understanding, nor am I sure whether the "first"= refers to the node that failed before the other or the one that is encount= ered earlier along the path since the statement is clearly stating that thi= s would cause a complete disconnect situation. =A0Could you please provide = a suggestion for text that would help your comprehension of the limitation?= =A0

=

=A0

Best regards,

Alessandro

--= ----------------------------------------------------------------
Telecom Italia
Alessandro Gerardo D'Ales= sandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Tor= ino
phone:=A0 +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07=

=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"ri=Rispetta l'ambiente. = Non stampare questa mail se non =E8 necessario.


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




--
Thanx and BR,
yaacov

Still looking= for new opportunity

--047d7b5daf502520fe04cd1e6025-- From wyaacov@gmail.com Sun Oct 28 06:45:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9D821F85D4 for ; Sun, 28 Oct 2012 06:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1IgZ7yZ4JTz for ; Sun, 28 Oct 2012 06:45:36 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB3B21F85C9 for ; Sun, 28 Oct 2012 06:45:36 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4834201vbb.31 for ; Sun, 28 Oct 2012 06:45:36 -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=61rh4DQFktWZYTukgPlV0YyzZjOFnMYats5B9W9udso=; b=ocvtoy9dLsF98OkOIQKgTa6TwmHzkuV0Q0T+2Rmk/XQ4Ktl3PSadYyBPA02u1nWzlt B04bnseFNbYstaga0DQ5HJZxWRUjCN5fVb2fcXMSVCTTZfOIpLXvYLVrv9ZKmw5qrdZJ JEi46BfNl2UdHqMpKzXF8ddGdgGcolhB7fxAcRBsvWfo3+05smMdHO/5oM9dj/ulRZqq XRz2MS7fpu6YpA+de4Fyj/KlkAKS4f7rfthycIHiGaGSb5OxRvdqAdfDrQRxCV410OhB r0kHRZ4x3UhF9cs7rOYHZdCfDzuxvZt/WN74/TZV8x5kkwvlZitM4RLJ/Vvls4jxSyPK vYQw== MIME-Version: 1.0 Received: by 10.52.95.201 with SMTP id dm9mr36183150vdb.95.1351431936047; Sun, 28 Oct 2012 06:45:36 -0700 (PDT) Received: by 10.58.254.194 with HTTP; Sun, 28 Oct 2012 06:45:35 -0700 (PDT) In-Reply-To: References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> <506B2036.3040508@cisco.com> Date: Sun, 28 Oct 2012 15:45:35 +0200 Message-ID: From: Yaacov Weingarten To: "D'Alessandro Alessandro Gerardo" Content-Type: multipart/alternative; boundary=20cf3071c69c7c7ad804cd1ec4f8 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] R: [AHMPLS-TP] R: Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 13:45:38 -0000 --20cf3071c69c7c7ad804cd1ec4f8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Alessandro, Thank you for your detailed list of comments regarding the ring-protection applicability draft. As I mentioned in my earlier response, I am trying to prepare a new version of the draft that will address your concerns, if possible. Please see my comments below inline (prefixed by "yw>>") Thank you and BR, yaacov weingarten *Still looking for new opportunity* On Wed, Oct 3, 2012 at 3:55 PM, D'Alessandro Alessandro Gerardo < alessandro.dalessandro@telecomitalia.it> wrote: > Dear Stewart, dear Nurit,**** > > ** ** > > Citing Stewart=92s answer**** > > ** ** > > =93The MUST is that all other requirements MUST be met, and the SHOULD**= ** > > is that the solution SHOULD be those in general transport networks, **** > > which is actually is not a ring specific statement. Indeed by **** > > reusing the mesh approach (RFC6378) we comply with that requirement **** > > since the mesh solution are by definition "identical to those in **** > > general transport networks"=94 **** > > ** ** > > indeed I do not believe that we comply with the requirements =93MUST=94 > refers to.**** > > ** ** > > More specifically, as an example, **** > > RFC 5654, Req. 106B: =93MPLS-TP recovery mechanisms in a ring SHOULD > protect against multiple failures=94**** > > Do we comply with that requirement? What is the solution (and relevant > operation/configuration cost) in the proposed draft when two adjacent nod= es > fail? Did we investigate further approaches before considering current > draft as the protection solution for ring topologies? > yw>> Yes, we comply based on the recommendation that is provided in Section 2.4 of the document that states that Steering is the preferred method of protection. This would also address the problems of multiple failures, even adjacent ones. In answer to the final question in this series, yes we investigated different approaches that were proposed to the group in other drafts and found that they are based on constructs that are not supported by MPLS and therefore would take time to acheive apporval. The proposal in this draft is merely an applicability statement and does not preclude defining a separate mechanism. > **** > > ** ** > > Another example:**** > > RFC 5654, Req. 105: =93It MUST be possible to lockout (disable) protecti= on > mechanisms on selected links (spans) in a ring=94**** > > Do we comply with that requirement? What is the proposed solution (and > relevant operation/configuration cost) to satisfy the requirement? > yw>> Yes, just as linear protection supports a Lockout of Protection operator command, this proposal would support the same operator command. Could you elaborate some more your understanding of this requirement? > **** > > ** ** > > ** ** > > If we look into the draft-ietf-mpls-tp-ring-protection, e.g. for the > wrapping solution, we find the following:**** > > ** ** > > Section 1. Introduction**** > > =93We show that this mechanism provides the ability to protect all of > the basic conditions within a reasonable time frame and does optimize > the criteria set out in [TPReqs] as summarized above.=94**** > > Does the proposed solution optimize the criteria as specified in [TPReqs= ]? > I rose the point in a previous email on October 2nd to Stewart Bryant. **= * > * > > Was the proposed solution compared with other approaches to better > understand pro and cons (e.g. respect to the criteria above mentioned and > respect to the overall behavior and complexity)? > yw>> RFC5654 mentions the requirement to optimize relative to protecting each LSP that traverses the "ring" and relative to that measurement the proposal does optimize the criteria. It would be very hard to optimize against all theoretical mechanisms until they all are standardized and prove that they are based on standard MPLS constructs, or if they require new constructs (as was the case with one proposed solution) - that these new constructs be defined and verified to comply with IETF standards for MPLS. > **** > > ** ** > > Section 1.1. Problem statement**** > > =93In either of these two situations, there is a need to address the fo= llowing > different cases -**** > > 3. An operator command is issued to a specific ring node. A descriptio= nof the different operator commands is found in Section 4.12 of [RFC4427]. > Examples of these commands include Manual Switch, Forced Switch, or > Clear operations.=94**** > > I did not find the Freeze command as specified in section 4.13 of RFC 442= 7 > in the proposed solution. What are the commands that draft-ietf-mpls-tp-r= ing-protection > support? > yw>> Being an applicability statement this draft supports all operator commands supported by RFC6378. If there is a need to support additional commands then these should be proposed as extensions to RFC6378 following the regular IETF process for proposing extensions (While not relevant to the current discussion, I might point out that RFC6378 does provide for extensions of its protocol based on IANA allocation) **** > > Obs: reference should be to section 4.13 of RFC4427 and not to section > 4.12 > yw>> Thank you - Corrected. > **** > > ** ** > > Section 2.1. Wrapping**** > > =93Configuration of the protection being performed (i.e. link protectio= n > or node protection) needs to be performed a-priori, since the > configuration of the proper protection path is dependent upon this > decision.=94**** > > I believe this is a consequence of the proposed solution and not the > general behavior that operator should expect for ring based protection. > That clearly shows draft-ietf-mpls-tp-ring-protection limitations in > terms of optimization for ring based topology it is intended for > yw>> I assume that there is supposed to be a continuation to this sentence, but based on my understanding of the start of the statement, I will agree that the Wrapping solution does display certain limitations, some of these limitationsare intrinsic to Wrapping and some are based on the limitations added by use of standard MPLS constructs (for example, the use of LSPs that have a defined starting point and that cannot be used in the same manner as Ethernet or SDH paths that start at arbitrary points in the network). For this reason, the document strongly recommends that Steering be the mechanism of choice when applying linear protection to ring topoplogies. > **** > > ** ** > > ** ** > > Section 2.3.4. Wrapping for link and node protection**** > > =93 In addition, the neighboring LSR, that detects the fault, cannot > readily differentiate between a link failure or a node failure.**** > > It would be possible to configure extra SPME to protect both for link > and node failures, arriving at a configuration of the ring that is sho= wn > in Figure 5. Choosing the SPME to use for the wrapping would, however, > then involve considerable effort and could result in the protected > traffic not sharing the same protection path in both directions.=94***= * > > Self-explaining=85 anyway I believe this is a consequence of the proposed > solution and not the general behavior that operator should expect for rin= g > based protection. That clearly shows draft-ietf-mpls-tp-ring-protection > limitations in terms of optimization for ring topology it is intended for > yw>> See previous comment. > **** > > ** ** > > ** ** > > So, there are two main points I rose:**** > > **1. **Compliance to requirements > yw>> I believe that I addressed these concerns > **** > > **2. **Limitations and complexity that are clearly stated in the > document itself > yw>> I would like to say that if the limitations are "clearly stated" then this should not be a limitation of approval of the document as long as the user is aware of the limitations, especially considering that this is intended to be an Informative Applicability Document. > **** > > ** ** > > Those points bring me to consider the draft not still mature.**** > > ** ** > > Best regards,**** > > Alessandro**** > > ------------------------------------------------------------------ > *Telecom Italia > *Alessandro Gerardo D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino* > *phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07**** > > ** ** > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --20cf3071c69c7c7ad804cd1ec4f8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Dear Alessandro,

Thank you for your det= ailed list of comments regarding the ring-protection applicability draft. = =A0As I mentioned in my earlier response, I am trying to prepare a new vers= ion of the draft that will address your concerns, if possible. =A0Please se= e my comments below inline (prefixed by "yw>>")

Thank you and BR,
yaacov weingarten

Still looking for new opportunity

On Wed, Oct 3, 2012 at 3:55 PM, D'Alessandro Alessandr= o Gerardo <alessandro.dalessandro@telecomitalia.it> wrote:
<= p class=3D"MsoNormal">Dear Stewart, dear N= urit,

=A0<= /p>

Citing Stewart=92s answer<=
/span>
=A0
 =93The MUST is that all other requirements MUST =
be met, and the SHOULD
is that the solution SHOULD be those in=
 general transport networks, 
which is=
 actually is not a ring specific statement. Indeed by 
reusing the mesh approach (RFC6378) we comply with that r=
equirement 
since the mesh solution ar=
e by definition "identical to those in 
general transport networks"=94 =A0

=A0

indeed I do not believe that we comply with the requi= rements =93MUST=94 refers to.

=A0<= /p>

More specifically, as = an example,

RFC 5654, Req= . 106B:=A0 =93MPLS-TP recovery mechanisms in a ring SHOULD pr= otect against multiple failures=94

Do we comply = with that requirement?=A0 What is the solution (and relevant o= peration/configuration cost) in the proposed draft when two adjacent nodes = fail? Did we investigate further approaches before considering current draf= t as the protection solution for ring topologies?

yw>> Yes, we comply based on the recomm= endation that is provided in Section 2.4 of the document that states that S= teering is the preferred method of protection. =A0This would also address t= he problems of multiple failures, even adjacent ones. =A0In answer to the f= inal question in this series, yes we investigated different approaches that= were proposed to the group in other drafts and found that they are based o= n constructs that are not supported by MPLS and therefore would take time t= o acheive apporval. =A0The proposal in this draft is merely an applicabilit= y statement and does not preclude defining a separate mechanism.=A0

=A0=

RFC 5654, Req= . 105:=A0 =93It MUST be possible to lockout (disable) protect= ion mechanisms on selected links (spans) in a ring=94

Do we comply = with that requirement?=A0 What is the proposed solution (and r= elevant operation/configuration cost) to satisfy the requirement?

yw>> Yes, just as linear protection sup= ports a Lockout of Protection operator command, this proposal would support= the same operator command. =A0Could you elaborate some more your understan= ding of this requirement?

=A0<= /p>

=A0

If we look into the draft= -ietf-mpls-tp-ring-protection, e.g. = for the wrapping solution, we find the following:

=A0

Se= ction 1.=A0 Introduction

=93We show that this mechanism provides the ability to=A0=A0=A0 <= /span>protect all of the basic conditions within a reasonable time frame=A0=A0=A0 and does optimize the criteria set out in [TPReqs= ] as summarized=A0=A0=A0 above.=94=

Does the prop= osed solution optimize the criteria as specified in=A0 [= TPReqs]? I rose the point in a previous email on Octobe= r 2nd to Stewart Bryant.

Was the propo= sed solution compared with other approaches to better understand pro and co= ns (e.g. respect to the criteria above mentioned and respect to the overall= behavior and complexity)?

yw>> RFC5654 mentions the requirement t= o optimize relative to protecting each LSP that traverses the "ring&qu= ot; and relative to that measurement the proposal does optimize the criteri= a. =A0It would be very hard to optimize against all theoretical mechanisms = until they all are standardized and prove that they are based on standard M= PLS constructs, or if they require new constructs (as was the case with one= proposed solution) - that these new constructs be defined and verified to = comply with IETF standards for MPLS.

=A0

Section 1.1.=A0 P= roblem statement

=93In either of these tw= o situations, there is a need to address the=A0=A0 following d= ifferent cases=A0 -

3.=A0 An operato= r command is issued to a specific ring node.=A0 A= =A0 description of the different operator commands is found i= n Section 4.12 of [RFC4427].=A0 Examples of these commands include=A0 Manual Switch, Forced Switch, or Clear op= erations.=94

I did not fin= d the Freeze command as specified in section 4.13 of RFC 4427 in the propos= ed solution. What are the commands that draft-ietf-mpls<= /span>-tp-ring-protection support?

yw>> Being an applicability statement t= his draft supports all operator commands supported by RFC6378. =A0If there = is a need to support additional commands then these should be proposed as e= xtensions to RFC6378 following the regular IETF process for proposing exten= sions (While not relevant to the current discussion, I might point out that= RFC6378 does provide for extensions of its protocol based on IANA =A0alloc= ation)

Obs:=A0 referenc= e should be to section 4.13 of RFC4427 and not to section 4.12

yw>> Thank you - Corrected.=A0

<= u>

=A0

Section 2.1.=A0 Wrapping

=93Configuration of the protection being p= erformed (i.e.=A0=A0 link protection or node prot= ection) needs to be performed=A0=A0=A0 a-priori, since the con= figuration of the proper protection path is=A0=A0 dependent up= on this decision.=94

I believe thi= s is a consequence of the proposed solution and not the general behavior th= at operator should expect for ring based protection. That clearly=A0 shows=A0 draft-ietf-mpl= s-tp-ring-protection limitations in terms of optimizati= on for ring based =A0topology it is intended for

yw>> I assume that there is supposed to= be a continuation to this sentence, but based on my understanding of the s= tart of the statement, I will agree that the Wrapping solution does display= certain limitations, some of these limitationsare intrinsic to Wrapping an= d some are based on the limitations added by use of standard MPLS construct= s (for example, the use of LSPs that have a defined starting point and that= cannot be used in the same manner as Ethernet or SDH paths that start at a= rbitrary points in the network). =A0For this reason, the document strongly = recommends that Steering be the mechanism of choice when applying linear pr= otection to ring topoplogies.=A0

=A0

=A0

Section 2.3.4.=A0 Wrapping for link and node pro= tection

=A0 =93 In addition, the neighb= oring LSR, that detects the fault,=A0=A0=A0 cannot readily dif= ferentiate between a link failure or a node=A0=A0=A0 failure.<= u>

=A0=A0 It would be possible to configure extr= a SPME to protect both for link=A0=A0=A0 and node failures, ar= riving at a configuration of the ring that is=A0=A0=A0 shown i= n Figure 5.=A0 Choosing the SPME to use for the wrapping would= ,=A0 however, then involve considerable effort an= d could result in the=A0=A0=A0 protected traffic not sharing t= he same protection path in both=A0=A0=A0 directions.=94=

Self-explaini= ng=85 anyway I believe this is a consequence of the proposed solution and n= ot the general behavior that operator should expect for ring based protecti= on. That clearly shows=A0 draft-ietf= -mpls-tp-ring-protection limitations in terms of = optimization for ring topology it is intended for

yw>> See previous comment.=A0

=

=A0

=A0=

1.=A0=A0=A0=A0=A0=A0 Compliance to requirements<= /span>

yw>> I believe that I addressed these c= oncerns=A0

= 2.=A0=A0=A0=A0=A0=A0 <= u>Limitations and complexity tha= t are clearly stated in the document itself

yw>> I would like to say that if the li= mitations are "clearly stated" then this should not be a limitati= on of approval of the document as long as the user is aware of the limitati= ons, especially considering that this is intended to be an Informative Appl= icability Document.=A0
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls




--
Thanx and BR,
yaacov

Still looking= for new opportunity

--20cf3071c69c7c7ad804cd1ec4f8-- From wyaacov@gmail.com Mon Oct 29 02:03:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE49321F8529 for ; Mon, 29 Oct 2012 02:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEr6knxVxVyG for ; Mon, 29 Oct 2012 02:03:28 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 900B421F84FA for ; Mon, 29 Oct 2012 02:03:28 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5358247vcb.31 for ; Mon, 29 Oct 2012 02:03:28 -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=K8N8xhNTHqZE579bo2y2qmXFLIZWDAZLdUc3YdvPnS0=; b=opqdZfoiNav5ZyqqEtgguYhgOF7XB5u+SPtarXjZdGb3YWxg+78lO/ltfg2pWfpOCX PLeb78cIvadciLx8kZSP9MD/uCz754YylU/xPYbjOvmGAZssk7oXxenjfP40Y3ibWR1V F4OD7cHuf6XflQ+SBgl+BuATzT/p8ZEzc+uExfUeAgfA3r8nhGl0WQBT8RPpumaMTI7Z dyJ8LDagR0xRDM9Jt7Gqmh3IAO0hrGWmnIFvLJ7rFJUfhc8G7VWTE3O5k/DFVV1nTCA0 117yyUIY0r2cwS04nR9HhTvgbgWKfQTeGny3MSQt3pKOhVhT9dmqDgiX5HHKVWaq1WAE NKww== MIME-Version: 1.0 Received: by 10.221.11.15 with SMTP id pc15mr29028199vcb.70.1351501407913; Mon, 29 Oct 2012 02:03:27 -0700 (PDT) Received: by 10.58.254.194 with HTTP; Mon, 29 Oct 2012 02:03:27 -0700 (PDT) In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC20277022C56B4@INOAVREX11.ptin.corpPT.com> References: <5059A308.3050307@pi.nu> <735916399E11684EAF4EB4FB376B7195264A40F9@SZXEML505-MBS.china.huawei.com> <52981DB05D3C5247A12D0AEE309F3CC20277022C56B4@INOAVREX11.ptin.corpPT.com> Date: Mon, 29 Oct 2012 11:03:27 +0200 Message-ID: From: Yaacov Weingarten To: Rui Costa Content-Type: multipart/alternative; boundary=bcaec54ee85a55092304cd2ef1d4 Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 09:03:29 -0000 --bcaec54ee85a55092304cd2ef1d4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Rui, hi Thank you for your comments to this WGLC, I will try to answer some of your comments that deal directly with my aspect of the draft in question and leave your other comments for those that are more qualified. See inline below. Hope this helps, yaacov weingarten *Still looking for new opportunity.* On Wed, Oct 3, 2012 at 6:09 PM, Rui Costa wrote: > Hello, > > 1. RFC1958 states "If a previous design, in the Internet context or > elsewhere, has successfully solved the same problem [...]". > yw>> Not sure what you are driving at =96 the question whether protection schemes that were designed for the physical layer, where rings are prevalent, is applicable to the logical layer of MPLS may need to be examined further. However, this document merely states that it is possible to address the protection by applying an existing design to the domain. > > 2. This draft looks quite different from G.841's sections about rings (or > G.8132.1 draft), IMHO. If there's a problem with the liaison accessibilit= y, > perhaps the expired comparison > http://tools.ietf.org/html/draft-yang-mpls-tp-ring-protection-analysishel= ps. > yw>> This is very true and it was not a goal of the authors to adhere to either G.841 nor G.8132.1 (except in the description of the Wrapping and Steering mechanisms). I find the comparison presented in the referenced draft as very helpful and I notice that there are several instances in which this comparison has come to different conclusions from those listed in the LS from ITU-T SG15 (in particular in the categories of Simplicity, Resource use, and Configuration), but I am not sure why this is relevant to the draft in question. > > 3. Could the authors explain, remembering the RFC1958 quote above > ("Internet context or ELSEWHERE"), what's the benefit of this draft versu= s > existing G.841 (Jul/1995)/G.8132.1 > draft/draft-helvoort-mpls-tp-ring-protection-switching? > yw>> As mentioned above, this is merely an applicability statement that says that many of the issues in ring protection can be addressed by use of the existing Linear Protection mechanism. In addition, it is very unclear how the two mechanisms that you mention (one is a physical layer mechanism, the other is a draft that was discussed [under a different name and author] in WG) really can be applied to MPLS without introducing new constructs to MPLS whose definition and technology would need to precede the work on these mechanisms. In particular (just one example that needs to be examined more closely), there is a claim that running OAM on a segment LSP can notify all other LSPs that traverse a particular LSR that they must reroute their traffic without a real MPLS description of how this is done. While this is very understandable in an Ethernet environment that works at the MAC address level, it is unclear how this is applied to MPLS label, without causing layer violations. > > 4. What is the benefit of RFC6378 (Feb2012) versus existing > G.841(Jul/1995)/G.8131.1 draft (again, remembering RFC1958...)? What new > brings PSC versus APS? > yw>> I believe that this was a WGLC on a different document > > 5. Why did we approve RFC6670, essentially saying "1 standard's better > than 2", but create 2 completely new protection standards, alternate to > options architecturally similar to those we have in the field for almost > 20years? > yw>> Again I believe that this was a WGLC on a different document. But it is interesting that you have a mechanism in the field for almost 20 years for a technology that is only 13 years old!! I do believe that new technologies call for a reexamination of tools that we have in the field rather than the other way around. > > 6. Why isn't the intersection of the authors of this draft, RFCs 6378 and > 6670, the empty set? > yw>> Again this was a WGLC on a different document. > > Regards, > Rui > > > Thanx and BR, yaacov *Still looking for new opportunity* --bcaec54ee85a55092304cd2ef1d4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Rui, hi

Thank you for your comments to = this WGLC, I will try to answer some of your comments that deal directly wi= th my aspect of the draft in question and leave your other comments for tho= se that are more qualified. =A0See inline below.

Hope this helps,
yaacov weingarten
=
Still looking for new opportunity.

On Wed, Oct 3, 2012 at 6:09 PM, Rui Costa <RCosta@ptin= ovacao.pt> wrote:
Hello,

1. RFC1958 states "If a previous design, in the Internet context or el= sewhere, has successfully solved the same problem [...]".
yw>> =A0Not sure what you are driving at =96 the question wh= ether protection schemes that were designed for the physical layer, where r= ings are prevalent, is applicable to the logical layer of MPLS may need to = be examined further. =A0However, this document merely states that it is pos= sible to address the protection by applying an existing design to the domai= n.

2. This draft looks quite different from G.841's sections about rings (= or G.8132.1 draft), IMHO. If there's a problem with the liaison accessi= bility, perhaps the expired comparison http://too= ls.ietf.org/html/draft-yang-mpls-tp-ring-protection-analysis helps.
yw>> =A0This is very true and it was not a goal of = the authors to adhere to either G.841 nor G.8132.1 (except in the descripti= on of the Wrapping and Steering mechanisms). =A0I find the comparison prese= nted in the referenced draft as very helpful and I notice that there are se= veral instances in which this comparison has come to different conclusions = from those listed in the LS from ITU-T SG15 (in particular in the categorie= s of Simplicity, Resource use, and Configuration), but I am not sure why th= is is relevant to the draft in question.

3. Could the authors explain, remembering the RFC1958 quote above ("In= ternet context or ELSEWHERE"), what's the benefit of this draft ve= rsus existing G.841 (Jul/1995)/G.8132.1 draft/draft-helvoort-mpls-tp-ring-p= rotection-switching?
yw>> =A0As mentioned above, this is merely an appli= cability statement that says that many of the issues in ring protection can= be addressed by use of the existing Linear Protection mechanism. =A0In add= ition, it is very unclear how the two mechanisms that you mention (one is a= physical layer mechanism, the other is a draft that was discussed [under a= different name and author] in WG) really can be applied to MPLS without in= troducing new constructs to MPLS whose definition and technology would need= to precede the work on these mechanisms. =A0In particular (just one exampl= e that needs to be examined more closely), there is a claim that running OA= M on a segment LSP can notify all other LSPs that traverse a particular LSR= =A0that they must reroute their traffic without a real MPLS description of= how this is done. =A0While this is very understandable in an Ethernet envi= ronment that works at the =A0MAC address level, it is unclear how this is a= pplied to MPLS label, without causing layer violations.

4. What is the benefit of RFC6378 (Feb2012) versus existing G.841(Jul/1995)= /G.8131.1 draft (again, remembering RFC1958...)? What new brings PSC versus= APS?
yw>> I believe that this was a WGLC on a d= ifferent document=A0

5. Why did we approve RFC6670, essentially saying "1 standard's be= tter than 2", but create 2 completely new protection standards, altern= ate to options architecturally similar to those we have in the field for al= most 20years?
yw>> Again I believe that this was a WGLC on a diff= erent document. =A0But it is interesting that you have a mechanism in the f= ield for almost 20 years for a technology that is only 13 years old!! =A0I = do believe that new technologies call for a reexamination of tools that we = have in the field rather than the other way around.=A0

6. Why isn't the intersection of the authors of this draft, RFCs 6378 a= nd 6670, the empty set?
yw>> Again this was a WG= LC on a different document.=A0

Regards,
Rui


Thanx and BR,
yaacov

Still looking for new opportunity
--bcaec54ee85a55092304cd2ef1d4-- From wyaacov@gmail.com Mon Oct 29 03:14:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A9321F8635 for ; Mon, 29 Oct 2012 03:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NtoJep6degs for ; Mon, 29 Oct 2012 03:14:38 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE6F221F8620 for ; Mon, 29 Oct 2012 03:14:37 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so5513081vbb.31 for ; Mon, 29 Oct 2012 03:14:37 -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=AQbvfEJiD3ejB/WuKO+tn/pZQa1FZ5gDe2u1WP0VMT8=; b=nHkBB9Zd+ZsNf2DuVMHA0kEsoc2MckgY8MGvf5VmQdFLk8AWy/yKQjTq61hMvABkCw 7k4xe7DZrNcvwFaAOQbOlgugF7iGjasHm9a0AcyrVSUtG+rXal2mWJfEmvoJ+U79JcnC DXTGct1k+Cq+oOpXtRvSPyIcVYuQF7MGjo3jnlgD+siCr51R9sMhJCOd5ROLcWY6DteS LCL6BaNjl/tlTboNqJ45vOR7gtGVlC37pMNBOn8hqk0/fCTL8l6PoxQ/6zb5VCoCkVmQ eao7sOccfOs8NwNFFLeR4UgEFGSwEgVE5nikShxBhXUOg3b7vRqQqY75cOmSqkspGOEn RW7w== MIME-Version: 1.0 Received: by 10.58.186.147 with SMTP id fk19mr43978046vec.13.1351505677233; Mon, 29 Oct 2012 03:14:37 -0700 (PDT) Received: by 10.58.254.194 with HTTP; Mon, 29 Oct 2012 03:14:37 -0700 (PDT) In-Reply-To: <506CB54F.2050706@lab.ntt.co.jp> References: <5059A308.3050307@pi.nu> <506CB54F.2050706@lab.ntt.co.jp> Date: Mon, 29 Oct 2012 12:14:37 +0200 Message-ID: From: Yaacov Weingarten To: Yoshinori Koike Content-Type: multipart/alternative; boundary=047d7b6d7df6cdad2e04cd2fef60 Cc: mpls@ietf.org Subject: Re: [mpls] Working group last call on draft-ietf-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 10:14:39 -0000 --047d7b6d7df6cdad2e04cd2fef60 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yoshinori, hello Thank you for your very helpful comments on the draft. In preparing the new version of the draft I will take these comments into account, as described in my comments inline below. Thank you and BR, yaacov weingarten *Still looking for new opportunity* On Wed, Oct 3, 2012 at 11:59 PM, Yoshinori Koike < koike.yoshinori@lab.ntt.co.jp> wrote: > Hello, > > Followings are my comments and questions. > > 1)It seems necessary to develop a ring protection mechanism to meet > requirements of ring protection in RFC5654. This document doesn=92t seem = to > specify a ring protection. > yw>> Not sure that I fully understand what you mean by "doesn't seem to specify a ring protection" - the document explains how it is possible to protect traffic that is traversing a ring, for most common scenarios, based on MPLS constructs and the extensions defined for MPLS-TP. Keep in mind that providing protection at the physical layer (where the ring exists) is really not MPLS, and may be based on constructs that are not well-defined in MPLS. 2)It seems that this document intends to address only parts of requirements > for protection of ring topologies; therefore I would suggest that the ter= m > =93ring protection=94 (total 12 in this document) should be modified to a= n > appropriate expression such as =93a protection for a ring topology=94. Ti= tle > and the first sentence in abstract seem to be appropriate. > yw>> I double-checked the twelve instances in which "ring protection" is mentioned in the document and noticed that they all are part of the description of the general mechanisms, i.e. Steering and Wrapping, and do not refer to the proposals that are described in the document. Therefore, unless you do not consider Wrapping and Steering to be "ring protection", I do not see a need to change the text. 3)In the second paragraph of clause 1, this document refers to RFC5654. > However, 5 requirements are not consistent with RFC5654. When they are > intentionally changed, it seems necessary to clearly explain them and the > reason. Otherwise, they are confusing. The followings are differences. > a.=93minimize=94 is missing > b.=93minimize=94 is missing > c.=93minimize=94 is missing > yw>> The sentence before the bullets (and that applies to all of the bullets) mentions the requirement to "optimize" all of the criteria. Will change this word to "minimize" if that will help. > d.=93recovery operation=94 is used instead of =93maintenance operation=94 > yw>> OK will change > e.=93during protection=94 is missing, > yw>> OK, will change. 4)In 1st paragraph of section 2.1, what is the objective/intention of > including the sentence =93Wrapping behavior is similar to MPLS-TE FRR as > defined in [RFC4090] using either bypass or detour tunnels.=94? Is it a > caution in terms of operation? Could you be more specific on the draft, > please? > yw>> The intent of the statement was to make a comparison that would be familiar to people that are more familiar with existing MPLS mechanisms rather than ITU mechanisms. There is no reason for a =93caution=94 since F= RR is very successful. 5)In 3rd paragraph of section 2.1, the following sentence is not clear. > =93Coordination would only be needed (where?) to maintain co-routed > bidirectional traffic (why and when?) even in cases(why plural?) of a > unidirectional fault condition.=94 Could you be more specific on this poi= nt, > please? > yw>> The sentence is stating that if there is a need to maintain the traffic as co-routed bidirectional at all times, both on the working path and whenever protection is activated, then there will be a need for coordination between the two local LSRs for cases of a unidirectional fault in order to verify that both endpoints realize that they need to switchover to the protection path. If there is no need to maintain the co-routed nature, then there is no need for coordination since one direction may continue to transmit on the working path, while the second direction transmits on the protection path, just notification is needed! Regarding the use of the plural =93cases=94 that is part of the English language usage for generalization! > 6)In the 5th bullet in section 2.1, it is not clear what is problematic. > Probably, it is meant that in-efficiency of resource allocation is > problematic. If it is correct, it seems better to clearly describe that > point. > yw>> It is problematic since there are a large number of parallel SPMEs that are being defined and if we allocate the full resources to all of the SPMEs there will be major over-subscription of the resources available. Therefore, it is advised to only reserve the resources and not allocate! Will try to clarify by adding text. > > [Editorial] > -In the item 3 in section 1.1 on page 4, section 4.12 of RFC 4427 is > referred. However, external commands are defined in section 4.13, correct= ly. > yw>> OK Corrected > -In the example 2 on page 5, a description of index =931=94 is missing in= the > explanation of [PB1(G)|LE]. > yw>> The one is referring to the fact that it is the label related to SPME-1 (which is mentioned in the explanation) > -In the first paragraph of section 2.1, in the third line from the bottom= , > =93arounf=94 should be =93around=94. > yw>> OK Corrected > -In figure 1, wrapped data path=94@@@=94 is not described between LSR E &= LSR > F. > yw>> OK Corrected > -In figure 8, branches at C, F, G, J, K and A should be removed for > aligning with the example shown in 3.2.2. > yw>> These branches are the egress points of the protection path SPME, however, due to the limitations of ASCII art it was difficult to draw them properly, I have slightly changed them and labelled them in the figure. > -In the first sentence of section 5, =93prevelant=94 should be =93prevale= nt=94. > yw>> OK Corrected > > Best regards, > > Yoshinori > > > (2012/09/19 19:48), Loa Andersson wrote: > >> Working Group, >> >> this is to start a two week working group last call on >> draft-ietf-mpls-tp-ring-**protection-02-txt. >> >> Please note that there are two IPR disclosures # 1462 and # 1872 >> related to this document. >> >> Please send your comments to the mpls working group mailing lists >> (mpls@ietf.org). >> >> The working group last call ends October 3, 2012. >> >> /Loa >> for the mpls wg co-chairs >> >> >> > > -- > Yoshinori Koike > koike.yoshinori@lab.ntt.co.jp > > > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --047d7b6d7df6cdad2e04cd2fef60 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Yoshinori, hello

Thank you for your ver= y helpful comments on the draft. =A0In preparing the new version of the dra= ft I will take these comments into account, as described in my comments inl= ine below.

Thank you and BR,
yaacov weingarten

Still looking for new opportunity

On Wed, Oct 3, 2012 at 11:59 PM, Yoshinori Koike <koike.yoshinori@lab.ntt.co.jp> wrote:
Hello,

Followings are my comments and questions.

1)It seems necessary to develop a ring protection mechanism to meet require= ments of ring protection in RFC5654. This document doesn=92t seem to specif= y a ring protection.
yw>> Not sure that I fully = understand what you mean by "doesn't seem to specify a ring protec= tion" - the document explains how it is possible to protect traffic th= at is traversing a ring, for most common scenarios, based on MPLS construct= s and the extensions defined for MPLS-TP. =A0Keep in mind that providing pr= otection at the physical layer (where the ring exists) is really not MPLS, = and may be based on constructs that are not well-defined in MPLS.=A0

2)It seems that this document intends to address only parts of requirements= for protection of ring topologies; therefore I would suggest that the term= =93ring protection=94 (total 12 in this document) should be modified to an= appropriate expression such as =93a protection for a ring topology=94. Tit= le and the first sentence in abstract seem to be appropriate.
yw>> I double-checked the twelve instances in which= "ring protection" is mentioned in the document and noticed that = they all are part of the description of the general mechanisms, i.e. Steeri= ng and Wrapping, and do not refer to the proposals that are described in th= e document. =A0Therefore, unless you do not consider Wrapping and Steering = to be "ring protection", I do not see a need to change the text.<= /div>

3)In the second paragraph of clause 1, this document refers to RFC5654. How= ever, 5 requirements are not consistent with RFC5654. When they are intenti= onally changed, it seems necessary to clearly explain them and the reason. = Otherwise, they are confusing. The followings are differences.
a.=93minimize=94 is missing
b.=93minimize=94 is missing
c.=93minimize=94 is missing
yw>> The sentence be= fore the bullets (and that applies to all of the bullets) mentions the requ= irement to "optimize" all of the criteria. =A0Will change this wo= rd to "minimize" if that will help.=A0
d.=93recovery operation=94 is used instead of =93maintenance operation=94
yw>> OK will change=A0
e.=93during protection=94 is missing,
yw>> OK, w= ill change.=A0

4)In 1st paragraph of section 2.1, what is the objective/intention of inclu= ding the sentence =93Wrapping behavior is similar to MPLS-TE FRR as defined= in [RFC4090] using either bypass or detour tunnels.=94? Is it a caution in= terms of operation? Could you be more specific on the draft, please?
yw>>=A0The intent of the statement was to make a co= mparison that would be familiar to people that are more familiar with exist= ing MPLS mechanisms rather than ITU mechanisms. =A0There is no reason for a= =93caution=94 since FRR is very successful.

5)In 3rd paragraph of section 2.1, the following sentence is not clear. =93= Coordination would only be needed (where?) to maintain co-routed bidirectio= nal traffic (why and when?) even in cases(why plural?) of a unidirectional = fault condition.=94 Could you be more specific on this point, please?
yw>>=A0The sentence is stating that if there is a n= eed to maintain the traffic as co-routed bidirectional at all times, both o= n the working path and whenever protection is activated, then there will be= a need for coordination between the two local LSRs for cases of a unidirec= tional fault in order to verify that both endpoints realize that they need = to switchover to the protection path. =A0If there is no need to maintain th= e co-routed nature, then there is no need for coordination since one direct= ion may continue to transmit on the working path, while the second directio= n transmits on the protection path, just notification is needed! =A0
Regarding the use of the plural =93cases=94 that is part of the Englis= h language usage for generalization!
=A0
6)In the 5th bullet in section 2.1, it is not clear what is problematic. Pr= obably, it is meant that in-efficiency of resource allocation is problemati= c. If it is correct, it seems better to clearly describe that point.
yw>> It is problematic since there are a large numb= er of parallel SPMEs that are being defined and if we allocate the full res= ources to all of the SPMEs there will be major over-subscription of the res= ources available. =A0Therefore, it is advised to only reserve the resources= and not allocate! Will try to clarify by adding text.

[Editorial]
-In the item 3 in section 1.1 on page 4, section 4.12 of RFC 4427 is referr= ed. However, external commands are defined in section 4.13, correctly.
<= /blockquote>
yw>> OK Corrected=A0
-In the example 2 on page 5, a description of index =931=94 is missing in t= he explanation of [PB1(G)|LE].
yw>> The one is r= eferring to the fact that it is the label related to SPME-1 (which is menti= oned in the explanation)
-In the first paragraph of section 2.1, in the third line from the bottom, = =93arounf=94 should be =93around=94.
yw>> OK Cor= rected=A0
-In figure 1, wrapped data path=94@@@=94 is not described between LSR E &am= p; LSR F.
yw>> OK Corrected=A0
-In figure 8, branches at C, F, G, J, K and A should be removed for alignin= g with the example shown in 3.2.2.
yw>> These br= anches are the egress points of the protection path SPME, however, due to t= he limitations of ASCII art it was difficult to draw them properly, I have = slightly changed them and labelled them in the figure.=A0
-In the first sentence of section 5, =93prevelant=94 should be =93prevalent= =94.
yw>> OK Corrected=A0

Best regards,

Yoshinori


(2012/09/19 19:48), Loa Andersson wrote:
Working Group,

this is to start a two week working group last call on
draft-ietf-mpls-tp-ring-protection-02-txt.

Please note that there are two IPR disclosures # 1462 and =A0# 1872
related to this document.

Please send your comments to the mpls working group mailing lists
(mpls@ietf.org).

The working group last call ends October 3, 2012.

/Loa
for the mpls wg co-chairs




--
Yoshinori Koike
koike.yo= shinori@lab.ntt.co.jp


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



--
=
Thanx and BR,
yaacov

Still= looking for new opportunity

--047d7b6d7df6cdad2e04cd2fef60-- From rgandhi@cisco.com Tue Oct 30 06:19:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2821F84BC for ; Tue, 30 Oct 2012 06:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvtNOMOiV9jH for ; Tue, 30 Oct 2012 06:19:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BF01B21F84AE for ; Tue, 30 Oct 2012 06:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1602; q=dns/txt; s=iport; t=1351603145; x=1352812745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fA4JBZ0xy4tOyh4D/fBqhfDhzZj39k+6DUKuSlevQtE=; b=iDaoFFm+k41haQ+DUw/bDDfVOe/MRr04HbWYspHqjuo+xJSVDB/cNOv8 upJpKvgemYFD3QUWtKEEWZmfAzs5wXL/0MjVpiDRqwsviQFNxQeOMYMDT eSguReLYSJ8T8fOBAB9Gun/4l40TctRpPt5bAnNJM/17E/Om91zavUSDT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABjRj1CtJXG9/2dsb2JhbABEwzWBCIIeAQEBBBIBJzQLDAICAgEIEQQBAQsUBQQHGxcUCQgCBAENBQgah2QLnFmPZ5A0BItxhXxhA5cOjT2Ba4JvgWQXHg X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="136885029" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 30 Oct 2012 13:19:05 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9UDJ4Bt017231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 13:19:04 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.191]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 08:19:04 -0500 From: "Rakesh Gandhi (rgandhi)" To: Loa Andersson , "mpls@ietf.org" , "Martin Vigoureux" , "draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" Thread-Topic: poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document Thread-Index: AQHNrQHxFvUuaxj/NEa3ZQH8HY36fJfMHiWAgAXJv2A= Date: Tue, 30 Oct 2012 13:19:03 +0000 Message-ID: References: <507FAF2D.5020907@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.208.193] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19320.004 x-tm-as-result: No--29.485400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll for consensus to make draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 13:19:06 -0000 Support.=20 Note: I am one of the co-authors.=20 Thanks Rakesh > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, October 18, 2012 3:27 AM > To: mpls@ietf.org; Martin Vigoureux;=20 > draft-ali-mpls-inter-domain-p2mp-rsvp-te- > lsp@tools.ietf.org > Cc: mpls-chairs@tools.ietf.org > Subject: poll for consensus to make=20 > draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp a working group document >=20 > Working group, >=20 > this is to start a two week poll on adopting > draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-09 > as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working=20 > group mailing list (mpls at ietf.org). Please give an technical=20 > motivation for your support/not support, especially if you think that the= document should not be adopted as a working group document. >=20 > This poll ends November 07, 2012. >=20 > There is one IPR claim against this document - http://datatracker.ietf.or= g/ipr/1861/ . >=20 > All the co-authors has stated on the mailing list that they are not=20 > aware of any other IPR claims than those already disclosed. > If there are IPR claims from any other party, please remember that the IP= R is open. >=20 > /Loa > (mpls wg co-chair) > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From jcucchiara@mindspring.com Tue Oct 30 23:36:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7989F21F867D; Tue, 30 Oct 2012 23:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJHjXbdr-oIi; Tue, 30 Oct 2012 23:36:42 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5C69D21F8679; Tue, 30 Oct 2012 23:36:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fxaLPswRF7OdfjfRo7oP+IR/L9CqrpHNLA4tW7an6dVe53TAfgHIZHzRxrS04Pz2; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TTRuq-0001AU-4o; Wed, 31 Oct 2012 02:36:40 -0400 Message-ID: <008801cdb732$13fc1db0$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Loa Andersson" , , "MIB Doctors \(E-mail\)" References: <50782094.5050104@pi.nu> Date: Wed, 31 Oct 2012 01:36:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26547b52e12a19be81aa59ca605b5933bb40387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: MPLS-TP ad hoc team , draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org Subject: [mpls] MIB DR. review of draft-ietf-mpls-tp-oam-id-mib-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 06:36:43 -0000 Hello, Please accept this MIB review as part of the WG LC comments. Compiler output which is followed by General Comments and then more specific comments. Thank you, -Joan smicngPRO E: f(MPLS-OAM-ID-STD-MIB.my), (111,8) Row "mplsOamIdMegEntry" may not have columns with MAX-ACCESS of read-write if any column is read-create E: f(MPLS-OAM-ID-STD-MIB.my), (162,17) Index item "mplsOamIdMegIndex" must be defined with syntax that includes a range E: f(MPLS-OAM-ID-STD-MIB.my), (240,19) Size of default value for "mplsOamIdMegIdIcc" is outside allowed range E: f(MPLS-OAM-ID-STD-MIB.my), (257,19) Size of default value for "mplsOamIdMegIdUmc" is outside allowed range E: f(MPLS-OAM-ID-STD-MIB.my), (433,23) Index item "mplsOamIdMegIndex" must be defined with syntax that includes a range E: f(MPLS-OAM-ID-STD-MIB.my), (434,23) Index item "mplsOamIdMeIndex" must be defined with syntax that includes a range E: f(MPLS-OAM-ID-STD-MIB.my), (435,23) Index item "mplsOamIdMeMpIndex" must be defined with syntax that includes a range Compiles cleanly with smilint. GENERAL COMMENTS -------------------------------------- 0) The draft proposes supporting LSPs, pseudowires and sections. Was the LC posted on pwe3 WG? 1) The MIB Module and Managed Objects do not reflect that this is MPLS-TP, why is that? 2) Terminology is not consistent with rfc5654 or rfc5860. They use the terms MPLS in Transport Networks, or MPLS Transport Profile, and this draft refers to this as "MPLS based Transport Profile". Please be consistent with these RFCs. 3) In general need more REFERENCES and more specific REFERENCES. Specifying an entire RFC is not nearly as helpful as specifying a section or subsection of an rfc. 4) Inconsistent use of RFC names. For example in Section 3.2 "This document uses terminology from the MPLS architecture document [RFC3031], MPLS Traffic Engineering Management information [RFC3812], MPLS Label Switch Router MIB [RFC3813] ....and MPLS-TP Identifiers document [RFC6370]." Sometimes a very informal name for document title, sometimes part of a title and sometimes the full title. Please consistently give the full title, so: MPLS Label Switching Architecture [RFC3031], MPLS Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) [RFC3812] and so forth. 5) Similar to the above, please reference MIB Modules by the Module Name. Someplaces do this, but some say MPLS Traffic Engineering MIB or LSR MIB. Again, please just be consistent. 6) Please capitalize the MIB. SPECIFIC COMMENTS ------------------------------- Section 5.1 s/in this table for MPLS tunnel/ in this table for MPLS tunnels/ Section 6. Please rework the title of this Section. It is awkward to read. s/for MPLS co-routed/ for an MPLS co-routed/ s/of MPLS tunnel/of an MPLS tunnel/ MIB MODULE ------------ *) DESCRIPTION "MPLS OAM Identifiers mib objects for LSPs and Pseudowires" s/mib/MIB/ *) Why is there no IndexNext scalar to assist operators in configuring the mplsOamIdMegTable? *) mplsOamIdMegIndex May want to consider starting the index at 1 per the rfc4181 Section 4.6.1.1 *) Mix of read-write and read-create in this table, and when creating a row (i.e. utilizing RowStatus, should use read-create.) *) some of these SnmpAdminString values say that NULL is acceptable, so maybe SIZE starting at 0 ? *) mplsOamIdMegServiceType DESCRIPTION clause is awkward. Indicates the service type for the MEG? What is the "service pointer", could you please state which object and be very specific, i.e. points to an entry in the mplsTunnelTable [RFC3812], etc. Same issue with the next 2 paragraphs. * Order of these objects. Typically, all objects are appear before StorageType and RowStatus. I don't believe this is mandatory, but certainly, convention. If objects are added after RowStatus that usually happens for revisions of the RFC. *) mplsOamIdMeTable Are entries in this table created dynamically and/or manually? Please clarify. *) mplsOamIdMeIndex and mplsOamIdMeMpIndex Same comment as above with regard to a IndexNext scalar and starting these indices at 1 as suggested by rfc4181 Section 4.6.1.1 *) mplsOamIdMeMpIfIndex Please include in the DESCRIPTION which ifType is associated with the various possiblities for this value. *) mplsOamIdMeMepDirection The DESCRIPTION is confusing. If the mplsOamIdMeMpType is not mep(1), what happens if this value is set? What happens upon a get request? *) mplsOamIdMeProactiveOamPhbTCValue/mplsOamIdMeOnDemandOamPhbTCValue Was the intention to make this a TC? Is this something that IANA should administer? *) same comments as before with regards to the order of StorageType and RowStatus objects. *) Notifications Why are these accessible-for-notify objects not included as part of the Tables? I think they would be relevant and helpful in monitoring. The mplsOamIdDefectCondition When is this supposed to be sent? I think the DESCRIPTION should be specific about when this notification is triggered. *) OID layout is not as suggested by rfc4181 \-2 mplsOamIdConformance \-v-1 mplsOamIdGroups | \-v-1 mplsOamIdMegGroup | |-2 mplsOamIdMeGroup | |-3 mplsOamIdNotificationObjectsGroup | \-4 mplsOamIdNotificationGroup \-2 mplsOamIdCompliances \---1 mplsOamIdModuleFullCompliance rfc4181, Appendix D. xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) *) Compliance There is no read-only compliance. Has it been made clear to the WGs (MPLS and PWE3) that SNMP sets will need to be supported in order to be compliant with the MIB? 8. Security Considerations This section needs to be completed. Please rework this section. 9.IANA Considerations This section needs to be completed. 10.2 Informative References What order are these in? -- end -- ----- Original Message ----- From: "Loa Andersson" To: Cc: "MPLS-TP ad hoc team" ; Sent: Friday, October 12, 2012 8:52 AM Subject: [mpls] mpls wg last call for draft-ietf-mpls-tp-oam-id-mib > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-oam-id-mib-01. > > Please send your comments to the mpls working group mailing > list (mpls@ietf.org). > > Please send both technical comments, and if you are happy with the > document as is also indications of support. > > This working group last call will end on October 28. > > /Loa > for the wg co-chairs > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From minto@juniper.net Wed Oct 31 22:18:56 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED33721F8545 for ; Wed, 31 Oct 2012 22:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE5ZVa2MEhmE for ; Wed, 31 Oct 2012 22:18:56 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id DEF8421F8511 for ; Wed, 31 Oct 2012 22:18:55 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUJIGPzZuJi+xA2K3DOpamHwdDuywCVDm@postini.com; Wed, 31 Oct 2012 22:18:55 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 31 Oct 2012 22:18:54 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 31 Oct 2012 22:18:54 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.182) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 31 Oct 2012 22:20:45 -0700 Received: from mail69-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Nov 2012 05:18:53 +0000 Received: from mail69-ch1 (localhost [127.0.0.1]) by mail69-ch1-R.bigfish.com (Postfix) with ESMTP id 94D861C0155 for ; Thu, 1 Nov 2012 05:18:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -37 X-BigFish: PS-37(zz9371Id6eah936eI542Mec9Q4015Izz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail69-ch1 (localhost.localdomain [127.0.0.1]) by mail69-ch1 (MessageSwitch) id 1351747131137412_24339; Thu, 1 Nov 2012 05:18:51 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail69-ch1.bigfish.com (Postfix) with ESMTP id 15F8E2E007F for ; Thu, 1 Nov 2012 05:18:51 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Nov 2012 05:18:47 +0000 Received: from BL2PRD0510MB374.namprd05.prod.outlook.com ([169.254.2.41]) by BL2PRD0510HT005.namprd05.prod.outlook.com ([10.255.100.40]) with mapi id 14.16.0233.002; Thu, 1 Nov 2012 05:18:46 +0000 From: Minto Jeyananth To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-minto-rsvp-lsp-egress-fast-protection-01.txt Thread-Index: AQHNsKLP1gfRxuUN70m/j2kzKum+CpfUfWFw Date: Thu, 1 Nov 2012 05:18:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Hannes Gredler Subject: [mpls] FW: New Version Notification for draft-minto-rsvp-lsp-egress-fast-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 05:18:57 -0000 SGkgRm9sa3MsDQogDQogIFRoaXMgZHJhZnQgcHJvcG9zZXMgYSBtZWNoYW5pc20gdG8gZW5hYmxl IGZhc3QgdHJhZmZpYyByZXN0b3JhdGlvbiBmb3IgUlNWUCBpbiB0aGUgZXZlbnQgb2YgTFNQIGVn cmVzcyBub2RlIGZhaWx1cmUuIFdlIGFyZSBhbHNvIGdvaW5nIHRvIHByZXNlbnQgdGhpcyBpbiB1 cGNvbWluZyBpZXRmIG1lZXRpbmcuIA0KDQpQbGVhc2UgcmVhZCBhbmQgY29tbWVudCB0byB0aGUg bGlzdCBvciB0byB0aGUgZHJhZnQgYXV0aG9ycy4gDQoNCg0KVGhhbmtzLA0KLW1pbnRvIA0KDQoN CkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMiwgMjAxMiA2OjE2IFBNDQpUbzogTWlu dG8gSmV5YW5hbnRoDQpDYzogSGFubmVzIEdyZWRsZXI7IFlpbWluIFNoZW4NClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWludG8tcnN2cC1sc3AtZWdyZXNzLWZh c3QtcHJvdGVjdGlvbi0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWlu dG8tcnN2cC1sc3AtZWdyZXNzLWZhc3QtcHJvdGVjdGlvbi0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgSmV5YW5hbnRoIE1pbnRvIEplZ2FuYXRoYW4gYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LW1pbnRvLXJzdnAt bHNwLWVncmVzcy1mYXN0LXByb3RlY3Rpb24NClJldmlzaW9uOgkgMDENClRpdGxlOgkJIFJTVlAt VEUgTFNQIGVncmVzcyBmYXN0LXByb3RlY3Rpb24NCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTEwLTIy DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTQNClVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt bWludG8tcnN2cC1sc3AtZWdyZXNzLWZhc3QtcHJvdGVjdGlvbi0wMS50eHQNClN0YXR1czogICAg ICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taW50by1yc3ZwLWxz cC1lZ3Jlc3MtZmFzdC1wcm90ZWN0aW9uDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1pbnRvLXJzdnAtbHNwLWVncmVzcy1mYXN0LXByb3RlY3Rpb24t MDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtbWludG8tcnN2cC1sc3AtZWdyZXNzLWZhc3QtcHJvdGVjdGlvbi0wMQ0KDQpBYnN0cmFjdDoN CiAgIFJGQzQwOTAgZGVmaW5lcyBhIGZhc3QgcmVyb3V0ZSBtZWNoYW5pc20gZm9yIGxvY2FsbHkg cmVwYWlyaW5nIGFuDQogICBSU1ZQLVRFIExTUCBpbiB0aGUgb3JkZXIgb2YgMTBzIG9mIG1pbGxp c2Vjb25kcywgaW4gdGhlIGV2ZW50IG9mIGENCiAgIGRvd25zdHJlYW0gbGluayBvciBub2RlIGZh aWx1cmUuICBIb3dldmVyLCB0aGlzIG1lY2hhbmlzbSBkb2VzIG5vdA0KICAgcHJvdmlkZSBub2Rl IHByb3RlY3Rpb24gZm9yIExTUCBlZ3Jlc3Mgbm9kZXMsIGV2ZW4gd2hlbiBhbiBhbHRlcm5hdGUN CiAgIGVncmVzcyBub2RlIChhIGJhY2t1cCBlZ3Jlc3MpIGlzIGF2YWlsYWJsZSB0aGF0IGNvdWxk IGNhcnJ5IHRoZQ0KICAgdHJhZmZpYyB0byBpdHMgdWx0aW1hdGUgZGVzdGluYXRpb24uICBUaGlz IGRvY3VtZW50IGFkZHJlc3NlcyB0aGlzDQogICBzY2VuYXJpbyBhbmQgZGVzY3JpYmVzIGhvdyB0 byBwcm92aWRlIGVncmVzcyBwcm90ZWN0aW9uIGJ5DQogICBlc3RhYmxpc2hpbmcgYSBieXBhc3Mg TFNQIGZyb20gdGhlIHBlbnVsdGltYXRlLWhvcCBub2RlIG9mIGEgTFNQIHRvDQogICB0aGUgYmFj a3VwIGVncmVzcyBub2RlLiAgVGhlIG1ldGhvZHMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQN CiAgIGVuYWJsZSBsb2NhbCByZXBhaXIgaW4gdGhlIG9yZGVyIG9mIDEwcyBvZiBtaWxsaXNlY29u ZHMsIGluIHRoZSBldmVudA0KICAgb2YgdGhlIGVncmVzcyBub2RlIGZhaWx1cmUuICBUaGVzZSBt ZXRob2RzIGFyZSBvbmx5IGFwcGxpY2FibGUgaWYNCiAgIHRyYWZmaWMgY2FycmllZCBieSB0aGUg TFNQIGNhbiBiZSByZXJvdXRlZCB0byBpdHMgdWx0aW1hdGUNCiAgIGRlc3RpbmF0aW9uIGJ5IHRo ZSBiYWNrdXAgZWdyZXNzIG5vZGUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg==