From loa@pi.nu Wed Jan 2 03:11:46 2013 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 55F0921F9080; Wed, 2 Jan 2013 03:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.493 X-Spam-Level: X-Spam-Status: No, score=-101.493 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 VFeR3lLFJ7Vh; Wed, 2 Jan 2013 03:11:45 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 2C54921F9074; Wed, 2 Jan 2013 03:11:45 -0800 (PST) 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 C499F823B5; Wed, 2 Jan 2013 12:11:42 +0100 (CET) Message-ID: <50E415EE.40304@pi.nu> Date: Wed, 02 Jan 2013 12:11:42 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: The IESG Content-Type: multipart/mixed; boundary="------------050106080205050309070403" Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-ethernet-addressing@tools.ietf.org Subject: [mpls] publication request draft-ietf-mpls-tp-ethernet-addressing 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, 02 Jan 2013 11:11:46 -0000 This is a multi-part message in MIME format. --------------050106080205050309070403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IESG, the MPLS working group requests that MPLS-TP Next-Hop Ethernet Addressing draft-ietf-mpls-tp-ethernet-addressing-04 is published as a RFC on the Standards Track. Please find the shepherd write-up attached. /Loa for the MPLS wg -- 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 --------------050106080205050309070403 Content-Type: text/plain; charset=windows-1252; name="draft-ietf-mpls-tp-ethernet-addressing.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-mpls-tp-ethernet-addressing.txt" DQoNCigxKSBXaGF0IHR5cGUgb2YgUkZDIGlzIGJlaW5nIHJlcXVlc3RlZCAoQkNQLCBQcm9w b3NlZCBTdGFuZGFyZCwgDQogICAgSW50ZXJuZXQgU3RhbmRhcmQsIEluZm9ybWF0aW9uYWws IEV4cGVyaW1lbnRhbCwgb3IgSGlzdG9yaWMpPyANCiAgICBXaHkgaXMgdGhpcyB0aGUgcHJv cGVyIHR5cGUgb2YgUkZDPyBJcyB0aGlzIHR5cGUgb2YgUkZDIGluZGljYXRlZA0KICAgIGlu IHRoZSB0aXRsZSBwYWdlIGhlYWRlcj8NCg0KDQogICBUaGUgTVBMUyB3b3JraW5nIGdyb3Vw IHJlcXVlc3QgdGhhdDogDQoNCiAgICAgICAgICAgICBNUExTLVRQIE5leHQtSG9wIEV0aGVy bmV0IEFkZHJlc3NpbmcNCiAgICAgICAgICAgZHJhZnQtaWV0Zi1tcGxzLXRwLWV0aGVybmV0 LWFkZHJlc3NpbmctMDQNCg0KICAgaXMgcHVibGlzaGVkIGFzIGFuIFJGQyBvbiB0aGUgc3Rh bmRhcmRzIHRyYWNrLg0KDQpUaGlzIGlzIGEgc3RhbmRhcmQgdHJhY2sgZG9jdW1lbnQgYmVj YXVzZSBpdCBpcyBhIHByb3RvY29sDQpzcGVjaWZpY2F0aW9uLg0KDQoNCg0KDQooMikgVGhl IElFU0cgYXBwcm92YWwgYW5ub3VuY2VtZW50IGluY2x1ZGVzIGEgRG9jdW1lbnQgQW5ub3Vu Y2VtZW50DQogICAgV3JpdGUtVXAuIFBsZWFzZSBwcm92aWRlIHN1Y2ggYSBEb2N1bWVudCBB bm5vdW5jZW1lbnQgV3JpdGUtVXAuDQogICAgUmVjZW50IGV4YW1wbGVzIGNhbiBiZSBmb3Vu ZCBpbiB0aGUgIkFjdGlvbiIgYW5ub3VuY2VtZW50cyBmb3INCiAgICBhcHByb3ZlZCBkb2N1 bWVudHMuIFRoZSBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIA0KICAgIGZv bGxvd2luZyBzZWN0aW9uczoNCg0KICAgIFRlY2huaWNhbCBTdW1tYXJ5Og0KDQoNClRoaXMg ZG9jdW1lbnQgcHJlc2VudHMgY29uc2lkZXJhdGlvbnMgZm9yIGxpbmstbGF5ZXIgYWRkcmVz c2luZyANCm9mIEV0aGVybmV0IGZyYW1lcyBjYXJyeWluZyBNUExTLVRQIHBhY2tldHMuDQoN ClRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykgVHJhbnNwb3J0IFBy b2ZpbGUgKE1QTFMtVFApDQppcyB0aGUgc2V0IG9mIE1QTFMgcHJvdG9jb2wgZnVuY3Rpb25z IGFwcGxpY2FibGUgdG8gdGhlIGNvbnN0cnVjdGlvbg0KYW5kIG9wZXJhdGlvbiBvZiBwYWNr ZXQtc3dpdGNoZWQgdHJhbnNwb3J0IG5ldHdvcmtzLiAgDQoNCg0KDQogICAgV29ya2luZyBH cm91cCBTdW1tYXJ5Og0KDQogICAgV2FzIHRoZXJlIGFueXRoaW5nIGluIFdHIHByb2Nlc3Mg dGhhdCBpcyB3b3J0aCBub3Rpbmc/IEZvciANCiAgICBleGFtcGxlLCB3YXMgdGhlcmUgY29u dHJvdmVyc3kgYWJvdXQgcGFydGljdWxhciBwb2ludHMgb3Igd2VyZQ0KICAgIHRoZXJlIGRl Y2lzaW9ucyB3aGVyZSB0aGUgY29uc2Vuc3VzIHdhcyBwYXJ0aWN1bGFybHkgcm91Z2g/DQoN ClRoZXJlIGlzIGdvb2Qgc3VwcG9ydCBpbiB0aGUgd29ya2luZyBncm91cCBmb3IgdGhpcyBk cmFmdC4gVGhlcmUgDQp3ZXJlIG5vIHNpZ25pZmljYW50IGNvbnRyb3ZlcnNpZXMgaW4gcHJv Z3Jlc3Npb24gb2YgdGhlIGRvY3VtZW50Lg0KTGFzdCBjYWxsIGNvbW1lbnRzIHdlcmUgY29u c3RydWN0aXZlIHRlY2huaWNhbCBjb21tZW50cyBhbmQgdGhlIA0KZG9jdW1lbnQgaGFzIGJl ZW4gdXBkYXRlZCBhY2NvcmRpbmdseS4NCg0KDQogICAgRG9jdW1lbnQgUXVhbGl0eToNCg0K ICAgIEFyZSB0aGVyZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIHByb3RvY29s PyBIYXZlIGEgDQogICAgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIHZlbmRvcnMgaW5kaWNhdGVk IHRoZWlyIHBsYW4gdG8gaW1wbGVtZW50DQogICAgdGhlIHNwZWNpZmljYXRpb24/IEFyZSB0 aGVyZSBhbnkgcmV2aWV3ZXJzIHRoYXQgbWVyaXQgc3BlY2lhbCANCiAgICBtZW50aW9uIGFz IGhhdmluZyBkb25lIGEgdGhvcm91Z2ggcmV2aWV3LCBlLmcuLCBvbmUgdGhhdCByZXN1bHRl ZA0KICAgIGluIGltcG9ydGFudCBjaGFuZ2VzIG9yIGEgY29uY2x1c2lvbiB0aGF0IHRoZSBk b2N1bWVudCBoYWQgbm8gDQogICAgc3Vic3RhbnRpdmUgaXNzdWVzPyBJZiB0aGVyZSB3YXMg YSBNSUIgRG9jdG9yLCBNZWRpYSBUeXBlIG9yDQogICAgb3RoZXIgZXhwZXJ0IHJldmlldywg d2hhdCB3YXMgaXRzIGNvdXJzZSAoYnJpZWZseSk/IEluIHRoZSBjYXNlDQogICAgb2YgYSBN ZWRpYSBUeXBlIHJldmlldywgb24gd2hhdCBkYXRlIHdhcyB0aGUgcmVxdWVzdCBwb3N0ZWQ/ DQoNCg0KV2Uga25vdyBvZiBpbnRlbnRpb25zIHRvIGltcGxlbWVudCB0aGlzIHByb3RvY29s LiBTaW5jZSBpcyBjYXJyaWVkIA0Kb3ZlciB0aGUgIk1QTFMgRy1BQ2ggQWR2ZXJ0aXNlbWVu dCBQcm90b2NvbCIsIG1vc3QgaW1wbGVtZW50ZXJzIGFyZQ0KaW4gd2FpdGluZyBtb2RlIGZv ciB0aGUgYXNzaWduZW1udCBvZiB0aGUgQUNoIHR5cGUgZm9yIHRoYXQgcHJvdG9jb2wuDQoN CiAgICBQZXJzb25uZWw6DQoNCiAgICBXaG8gaXMgdGhlIERvY3VtZW50IFNoZXBoZXJkPw0K DQpMb2EgQW5kZXJzc29uIGlzIHRoZSBkb2N1bWVudCBzaGVwaGVyZC4NCg0KICAgIFdobyBp cyB0aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3Rvcj8NCg0KQWRyaWFuIEZhcnJlbCBpcyB0 aGUgcmVzcG9uc2libGUgQUQuDQoNCiAgICAoMykgQnJpZWZseSBkZXNjcmliZSB0aGUgcmV2 aWV3IG9mIHRoaXMgZG9jdW1lbnQgdGhhdCB3YXMgDQogICAgcGVyZm9ybWVkIGJ5IHRoZSBE b2N1bWVudCBTaGVwaGVyZC4gSWYgdGhpcyB2ZXJzaW9uIG9mIHRoZQ0KICAgIGRvY3VtZW50 IGlzIG5vdCByZWFkeSBmb3IgcHVibGljYXRpb24sIHBsZWFzZSBleHBsYWluIHdoeSB0aGUg DQogICAgZG9jdW1lbnQgaXMgYmVpbmcgZm9yd2FyZGVkIHRvIHRoZSBJRVNHLg0KDQpUaGUg ZG9jdW1lbnQgc2hlcGhlcmQgcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGF0IHRoZSBwb2ludCBp biB0aW1lDQp3aGVuIGl0IHdhcyBiZWluZyBwb2xsZWQgdG8gYmVjb21lIGEgd29ya2luZyBn cm91cCBkb2N1bWVudCBhbmQgYWdhaW4NCmFzIGEgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24g Zm9yIHRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4gVGhlIA0KZHJhZnQgaGFzIGFsc28g YmVlbiByZXZpZXdlZCBhIG51bWJlciBvZiB0aW1lcyAocGFydGlhbGx5IG9yIHRoZSANCmVu dGlyZSBkcmFmdCkgYWZ0ZXIgdGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIHdhcyBjb21w bGV0ZWQuDQpUaGUgSUFOQSBzZWN0aW9uIGhhcyBiZWVuIHJldmlld2VkIHNldmVyYWwgdGlt ZXMuDQoNCiAgICAoNCkgRG9lcyB0aGUgZG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBhbnkgY29u Y2VybnMgYWJvdXQgdGhlIGRlcHRoDQogICAgb3IgYnJlYWR0aCBvZiB0aGUgcmV2aWV3cyB0 aGF0IGhhdmUgYmVlbiBwZXJmb3JtZWQ/DQoNCk5vIHN1Y2ggY29uY2VybnMsIHRoZSBkb2N1 bWVudCBoYXMgYmVlbiB0aG9ydWdoIHdvcmtpbmcgZ3JvdXAgbGFzdA0KY2FsbCBhbmQgY29t bWVudHMgaGFzIGJlZW4gc29saWNpdGVkIGZyb20gU0cxNSBpbiB0aGUgSVRVLVQuLg0KDQog ICAgKDUpIERvIHBvcnRpb25zIG9mIHRoZSBkb2N1bWVudCBuZWVkIHJldmlldyBmcm9tIGEg cGFydGljdWxhciBvcg0KICAgIGZyb20gYnJvYWRlciBwZXJzcGVjdGl2ZSwgZS5nLiwgc2Vj dXJpdHksIG9wZXJhdGlvbmFsIA0KICAgIGNvbXBsZXhpdHksIEFBQSwgRE5TLCBESENQLCBY TUwsIG9yIGludGVybmF0aW9uYWxpemF0aW9uPyBJZiBzbywNCiAgICBkZXNjcmliZSB0aGUg cmV2aWV3IHRoYXQgdG9vayBwbGFjZS4NCg0KVGhlIGRvY3VtZW50IHNoZXBoZXJkIGJlbGll dmVzIHRoYXQgdGhlIGN1cnJlbnQgbGV2ZWwgb2YgcmV2aWV3IGlzDQpzdWZmaWNpZW50Lg0K DQogICAgKDYpIERlc2NyaWJlIGFueSBzcGVjaWZpYyBjb25jZXJucyBvciBpc3N1ZXMgdGhh dCB0aGUgRG9jdW1lbnQgDQogICAgU2hlcGhlcmQgaGFzIHdpdGggdGhpcyBkb2N1bWVudCB0 aGF0IHRoZSBSZXNwb25zaWJsZSBBcmVhIA0KICAgIERpcmVjdG9yIGFuZC9vciB0aGUgSUVT RyBzaG91bGQgYmUgYXdhcmUgb2Y/IEZvciBleGFtcGxlLCANCiAgICBwZXJoYXBzIGhlIG9y IHNoZSBpcyB1bmNvbWZvcnRhYmxlIHdpdGggY2VydGFpbiBwYXJ0cyBvZiB0aGUgDQogICAg ZG9jdW1lbnQsIG9yIGhhcyBjb25jZXJucyB3aGV0aGVyIHRoZXJlIHJlYWxseSBpcyBhIG5l ZWQgZm9yIGl0Lg0KICAgIEluIGFueSBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQg dGhvc2UgaXNzdWVzIGFuZCBoYXMgDQogICAgaW5kaWNhdGVkIHRoYXQgaXQgc3RpbGwgd2lz aGVzIHRvIGFkdmFuY2UgdGhlIGRvY3VtZW50LCBkZXRhaWwNCiAgICB0aG9zZSBjb25jZXJu cyBoZXJlLg0KDQpObyBzdWNoIGNvbmNlcm5zLg0KDQogICAgKDcpIEhhcyBlYWNoIGF1dGhv ciBjb25maXJtZWQgdGhhdCBhbnkgYW5kIGFsbCBhcHByb3ByaWF0ZSBJUFINCiAgICBkaXNj bG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZSBwcm92aXNp b25zIG9mDQogICAgQkNQIDc4IGFuZCBCQ1AgNzkgaGF2ZSBhbHJlYWR5IGJlZW4gZmlsZWQu IElmIG5vdCwgZXhwbGFpbiB3aHk/DQoNCkEgcG9sbCBmb3IgSVBScyBoYXMgYmVlbiBkb25l IGFtb25nIHRoZSBhdXRob3JzIGFuZCBpbiB0aGUgd29ya2luZyANCmdyb3VwLg0KQWxsIHRo ZSBhdXRob3JzIGhhcyBjb25maXJtZWQgdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55 IGV4aXN0aW5nDQpJUFIgY2xhaW1zLg0KVGhlcmUgYXJlIG5vIElQVLRSIGNsYWltcyBhZ2Fp bnN0IHRoaXMgZG9jdW1lbnQuDQoNCg0KICAgICg4KSBIYXMgYW4gSVBSIGRpc2Nsb3N1cmUg YmVlbiBmaWxlZCB0aGF0IHJlZmVyZW5jZXMgdGhpcw0KICAgIGRvY3VtZW50PyBJZiBzbywg c3VtbWFyaXplIGFueSBXRyBkaXNjdXNzaW9uIGFuZCBjb25jbHVzaW9uIA0KICAgIHJlZ2Fy ZGluZyB0aGUgSVBSIGRpc2Nsb3N1cmVzLg0KDQpObyBJUFIgZGlzY2xvc3VyZXMgaGF2ZSBi ZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBvbiB0aGlzIGRyYWZ0Lg0KDQogICAgKDkpIEhvdyBz b2xpZCBpcyB0aGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0 DQogICAgcmVwcmVzZW50IHRoZSBzdHJvbmcgY29uY3VycmVuY2Ugb2YgYSBmZXcgaW5kaXZp ZHVhbHMsIHdpdGggDQogICAgb3RoZXJzIGJlaW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgV0cg YXMgYSB3aG9sZSB1bmRlcnN0YW5kIGFuZCANCiAgICBhZ3JlZSB3aXRoIGl0Pw0KDQpUaGVy ZSBhcmUgZ29vZCBzdXBwb3J0IGZvciB0aGlzIGRvY3VtZW50IQ0KDQogICAgKDEwKSBIYXMg YW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lzZSBpbmRpY2F0ZWQNCiAg ICBleHRyZW1lIGRpc2NvbnRlbnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRoZSBhcmVh cyBvZiANCiAgICBjb25mbGljdCBpbiBzZXBhcmF0ZSBlbWFpbCBtZXNzYWdlcyB0byB0aGUg UmVzcG9uc2libGUgQXJlYSANCiAgICBEaXJlY3Rvci4gKEl0IHNob3VsZCBiZSBpbiBhIHNl cGFyYXRlIGVtYWlsIGJlY2F1c2UgdGhpcw0KICAgIHF1ZXN0aW9ubmFpcmUgaXMgcHVibGlj bHkgYXZhaWxhYmxlLikNCg0KTm8gc3VjaCB0aHJlYXRzIQ0KDQogICAgKDExKSBJZGVudGlm eSBhbnkgSUQgbml0cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGFzIGZvdW5kIGluDQogICAg dGhpcyBkb2N1bWVudC4gKFNlZSBodHRwOi8vd3d3LmlldGYub3JnL3Rvb2xzL2lkbml0cy8g YW5kIHRoZQ0KICAgIEludGVybmV0LURyYWZ0cyBDaGVja2xpc3QpLiBCb2lsZXJwbGF0ZSBj aGVja3MgYXJlIG5vdCBlbm91Z2g7IA0KICAgIHRoaXMgY2hlY2sgbmVlZHMgdG8gYmUgdGhv cm91Z2guDQoNClRoaXMgZG9jdW1lbnQgcGFzc2VzIHRoZSBJRC1uaXRzIHRvb2wgY2xlYW4u DQoNCiAgICAoMTIpIERlc2NyaWJlIGhvdyB0aGUgZG9jdW1lbnQgbWVldHMgYW55IHJlcXVp cmVkIGZvcm1hbCByZXZpZXcgDQogICAgY3JpdGVyaWEsIHN1Y2ggYXMgdGhlIE1JQiBEb2N0 b3IsIG1lZGlhIHR5cGUsIGFuZCBVUkkgdHlwZSANCiAgICByZXZpZXdzLg0KDQpObyBzdWNo IGZvcm1hbCByZXZpZXcgcmVxdWlyZW1lbnRzIQ0KDQogICAgKDEzKSBIYXZlIGFsbCByZWZl cmVuY2VzIHdpdGhpbiB0aGlzIGRvY3VtZW50IGJlZW4gaWRlbnRpZmllZCBhcw0KICAgIGVp dGhlciBub3JtYXRpdmUgb3IgaW5mb3JtYXRpdmU/DQoNClllcy4NCg0KICAgICgxNCkgQXJl IHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGRvY3VtZW50cyB0aGF0IGFyZSBub3QN CiAgICByZWFkeSBmb3IgYWR2YW5jZW1lbnQgb3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1bmNs ZWFyIHN0YXRlPyBJZiANCiAgICBzdWNoIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGV4aXN0LCB3 aGF0IGlzIHRoZSBwbGFuIGZvciB0aGVpciANCiAgICBjb21wbGV0aW9uPw0KDQpXaXRoIHRo ZSBleGNlcHRpb24gb2YgImRyYWZ0LWlldGYtbXBscy1nYWNoLWFkdiIgYWxsIG5vcm1hdGl2 ZQ0KcmVmZXJlbmNlcyBhcmUgUkZDcy4NCg0KICAgICgxNSkgQXJlIHRoZXJlIGRvd253YXJk IG5vcm1hdGl2ZSByZWZlcmVuY2VzIHJlZmVyZW5jZXMgDQogICAgKHNlZSBSRkMgMzk2Nyk/ IElmIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMgdG8gc3VwcG9ydA0KICAg IHRoZSBBcmVhIERpcmVjdG9yIGluIHRoZSBMYXN0IENhbGwgcHJvY2VkdXJlLg0KDQpUaGVy ZSBpcyBhIGRvd253YXJkIHJlZmVyZW5jZXMgdG8gUkZDIDI0NjkgIkEgQ2F1dGlvbiBPbiBU aGUgDQpDYW5vbmljYWwgT3JkZXJpbmcgT2YgTGluay1MYXllciBBZGRyZXNzZXMiLg0KDQog ICAgKDE2KSBXaWxsIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgY2hhbmdlIHRoZSBz dGF0dXMgb2YgYW55IA0KICAgIGV4aXN0aW5nIFJGQ3M/IEFyZSB0aG9zZSBSRkNzIGxpc3Rl ZCBvbiB0aGUgdGl0bGUgcGFnZSBoZWFkZXIsIA0KICAgIGxpc3RlZCBpbiB0aGUgYWJzdHJh Y3QsIGFuZCBkaXNjdXNzZWQgaW4gdGhlIGludHJvZHVjdGlvbj8gSWYgDQogICAgdGhlIFJG Q3MgYXJlIG5vdCBsaXN0ZWQgaW4gdGhlIEFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24sIGV4 cGxhaW4NCiAgICB3aHksIGFuZCBwb2ludCB0byB0aGUgcGFydCBvZiB0aGUgZG9jdW1lbnQg d2hlcmUgdGhlIHJlbGF0aW9uc2hpcA0KICAgIG9mIHRoaXMgZG9jdW1lbnQgdG8gdGhlIG90 aGVyIFJGQ3MgaXMgZGlzY3Vzc2VkLiBJZiB0aGlzIA0KICAgIGluZm9ybWF0aW9uIGlzIG5v dCBpbiB0aGUgZG9jdW1lbnQsIGV4cGxhaW4gd2h5IHRoZSBXRyBjb25zaWRlcnMNCiAgICBp dCB1bm5lY2Vzc2FyeS4NCg0KVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHN0 YXR1cyBvZiBhbnkgb3RoZXIgZG9jdW1lbnQuDQoNCiAgICAoMTcpIERlc2NyaWJlIHRoZSBE b2N1bWVudCBTaGVwaGVyZCdzIHJldmlldyBvZiB0aGUgSUFOQSANCiAgICBjb25zaWRlcmF0 aW9ucyBzZWN0aW9uLCBlc3BlY2lhbGx5IHdpdGggcmVnYXJkIHRvIGl0cyANCiAgICBjb25z aXN0ZW5jeSB3aXRoIHRoZSBib2R5IG9mIHRoZSBkb2N1bWVudC4gQ29uZmlybSB0aGF0IGFs bCANCiAgICBwcm90b2NvbCBleHRlbnNpb25zIHRoYXQgdGhlIGRvY3VtZW50IG1ha2VzIGFy ZSBhc3NvY2lhdGVkIHdpdGgNCiAgICB0aGUgYXBwcm9wcmlhdGUgcmVzZXJ2YXRpb25zIGlu IElBTkEgcmVnaXN0cmllcy4gQ29uZmlybSB0aGF0DQogICAgYW55IHJlZmVyZW5jZWQgSUFO QSByZWdpc3RyaWVzIGhhdmUgYmVlbiBjbGVhcmx5IGlkZW50aWZpZWQuIA0KICAgIENvbmZp cm0gdGhhdCBuZXdseSBjcmVhdGVkIElBTkEgcmVnaXN0cmllcyBpbmNsdWRlIGEgZGV0YWls ZWQNCiAgICBzcGVjaWZpY2F0aW9uIG9mIHRoZSBpbml0aWFsIGNvbnRlbnRzIGZvciB0aGUg cmVnaXN0cnksIHRoYXQgDQogICAgYWxsb2NhdGlvbnMgcHJvY2VkdXJlcyBmb3IgZnV0dXJl IHJlZ2lzdHJhdGlvbnMgYXJlIGRlZmluZWQsIA0KICAgIGFuZCBhIHJlYXNvbmFibGUgbmFt ZSBmb3IgdGhlIG5ldyByZWdpc3RyeSBoYXMgYmVlbiBzdWdnZXN0ZWQgDQogICAgKHNlZSBS RkMgNTIyNikuDQoNClRoaXMgZG9jdW1lbnQgaGFzIGEgY2xlYXIgYW5kIHdlbGwtd3JpdHRl biBJQU5BIHNlY3Rpb24uDQoNCk5vdGU6IEluIHNlY3Rpb24gNi4yIHRoaXMgZG9jdW1lbnQg cmVxdWVzdHMgdGhhdCBhIGNvZGUgcG9pbnQgaXMNCiAgICAgIGFsbG9jYXRlZCBmb3IgIGFs bG9jYXRlIGEgbmV3IEFwcGxpY2F0aW9uIElEIGluIHRoZSAiRy1BQ2gNCiAgICAgIEFkdmVy dGlzZW1lbnQgUHJvdG9jb2wgQXBwbGljYXRpb25zIiByZWdpc3RyeQ0KICAgICAgW0ktRC5p ZXRmLW1wbHMtZ2FjaC1hZHZdIChjdXJyZW50bHkgbG9jYXRlZCBpbiB0aGUgDQogICAgICAi UHNldWRvd2lyZSBOYW1lIFNwYWNlcyAoUFdFMykiKS4NCiAgICAgIFN0cmljdGx5IHRoaXMg cmVnaXN0cnkgaXMgaW4gdGhlIHByb2Nlc3Mgb2YgYmVpbmcgc2V0IHVwOw0KICAgICAgdGhl IE1QTFMgd29ya2luZyBncm91cCBoYXMgcmVxdWVzdGVkIHB1YmxpY2F0aW9uIG9mDQogICAg ICBbSS1ELmlldGYtbXBscy1nYWNoLWFkdl0uDQoNCg0KDQogICAgKDE4KSBMaXN0IGFueSBu ZXcgSUFOQSByZWdpc3RyaWVzIHRoYXQgcmVxdWlyZSBFeHBlcnQgUmV2aWV3IGZvcg0KICAg IGZ1dHVyZSBhbGxvY2F0aW9ucy4gUHJvdmlkZSBhbnkgcHVibGljIGd1aWRhbmNlIHRoYXQg dGhlIElFU0cgDQogICAgd291bGQgZmluZCB1c2VmdWwgaW4gc2VsZWN0aW5nIHRoZSBJQU5B IEV4cGVydHMgZm9yIHRoZXNlIG5ldyANCiAgICByZWdpc3RyaWVzLg0KDQpUaGlzIGRvY3Vt ZW50IGNyZWF0ZXMgb25lIG5ldyBJQU5BIHJlZ2lzdHJ5LCB0aGUgYWxsb2NhdGlvbiBwb2xp Y2l5DQppcyAiSUVURiBSZXZpZXciLg0KDQogICAgKDE5KSBEZXNjcmliZSByZXZpZXdzIGFu ZCBhdXRvbWF0ZWQgY2hlY2tzIHBlcmZvcm1lZCBieSB0aGUgDQogICAgRG9jdW1lbnQgU2hl cGhlcmQgdG8gdmFsaWRhdGUgc2VjdGlvbnMgb2YgdGhlIGRvY3VtZW50IHdyaXR0ZW4gDQog ICAgaW4gYSBmb3JtYWwgbGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MIGNvZGUsIEJORiBydWxlcywg TUlCIA0KICAgIGRlZmluaXRpb25zLCBldGMuDQoNCk5vIHN1Y2ggcmV2aWV3IHJlcXVpcmVk Lg== --------------050106080205050309070403-- From stbryant@cisco.com Wed Jan 2 04:23:48 2013 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 AE97121F90BF for ; Wed, 2 Jan 2013 04:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.606 X-Spam-Level: X-Spam-Status: No, score=-110.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 QmEVldHFUKOV for ; Wed, 2 Jan 2013 04:23:47 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA6F21F8C3C for ; Wed, 2 Jan 2013 04:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3454; q=dns/txt; s=iport; t=1357129427; x=1358339027; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sB0wg6imuQiFyKIq3X4EV4oiv3RfmnPtZNOf4q0a8R4=; b=X6Wh5wvJXoe+athcC9Mp5sSbiRWStYTP39WsOCmeNzEFrcf7ZmYwTl0Y Sqlh1B8WsZre9qVOUmO38LzonlD3vWrVAAYqGcE8a/YStwxIYTNNFyuPw DoPnK51OStpkiu4LSaJOESICrPbHPJxBLWcRC5f3+PIITZkk61xmuqlYk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkbACom5FCQ/khM/2dsb2JhbABFgX+BSYJytxMWc4IeAQEBAwEBAQEeAUwGBAEOAgsYAQMFBhAKAwIJAwIBAgEJDDATAQUCAQGICQYMjGaacAGQUwSBG4s4C4MigRYDlgyFa4pdgnSBcQ X-IronPort-AV: E=Sophos;i="4.84,395,1355097600"; d="scan'208";a="10822596" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 02 Jan 2013 12:23:46 +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 r02CNdfT008469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2013 12:23:39 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 r02CNch4001841; Wed, 2 Jan 2013 12:23:38 GMT Message-ID: <50E426CA.7080106@cisco.com> Date: Wed, 02 Jan 2013 12:23:38 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: kenji.fujihira.dj@hitachi.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] MPLS-RT Review of draft-fbb-mpls-tp-p2mp-framework-05 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: Wed, 02 Jan 2013 12:23:48 -0000 On 03/09/2012 11:18, kenji.fujihira.dj@hitachi.com wrote: > Hi, authors and chairs. > > As the MPLS-RT process, I've reviewed draft-fbb-mpls-tp-p2mp-framework-05. > > a. Is the document coherent? > It is almost coherent. I have two comments. > > - Section 7. (Network Management) > I think the following description should be moved from section 7 to section 4 (OAM). > "Packet Loss and Delay Measurement for > MPLS Networks [RFC6374] already considers the P2MP case and it is not > thought that any change is needed to the MPLS-TP profile of [RFC6374] > [RFC6375]." Done. > > - Section 1.2. (Terminology) > I suppose PM is "Performance Monitoring", not "Performance Measurement", > referring to RFC5921, 5951 and 6371. Done > b. Is it useful (ie, is it likely to be actually useful in operational networks)? > I believe this draft is useful. If possible, comments from operators will help. > > c. Is the document technically sound? > My concern is 1:n protection. > As addressed in section 6, it needs further discussion. > Relating to this point, it will be valuable if the draft lists up protection types > P2MP MAY support (for example, partial tree protection as addressed in section 6). The draft says: More sophisticated survivability approaches such as partial tree protection and 1:n protection are for further study. The further study can happen during the WG phase of the draft. At this stage the draft is only up for WG adoption not WG LC, and thus the test is whether the draft is a good starting point for the WG to work on it, and I suggest that it passed that hurdle. > > The other descriptions are clear and well aligned with referred RFCs. > > d. Is the document ready to be considered for WG adoption? > IMO, it's better to close my comments above on section 7 before WG adoption. That one is done. - Stewart > > Best Regards, > Kenji. > > >> Kenji, Jia, Dave; >> >> You have been selected as an MPLS Review team reviewers for >> draft-fbb-mpls-tp-p2mp-framework-05.txt >> >> Note to authors: You have been CC$BCE(B 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$BCU(B >> 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$BCE(B 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 Sep 3, 2012? >> >> Thanks, Loa >> (as MPLS WG 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 From stbryant@cisco.com Wed Jan 2 04:50:37 2013 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 C452721F906E for ; Wed, 2 Jan 2013 04:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.211 X-Spam-Level: X-Spam-Status: No, score=-109.211 tagged_above=-999 required=5 tests=[AWL=-1.401, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 NQvk3vHnwoTW for ; Wed, 2 Jan 2013 04:50:37 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 863D821F8EDF for ; Wed, 2 Jan 2013 04:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4182; q=dns/txt; s=iport; t=1357131036; x=1358340636; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=CsiGZt5WNCCpMqn0jZU6kJhdEAvW4NddTKQV8osRxpk=; b=dNxZEu2RbkSAWFPhJQ3nNrNeU/VJZ02FyROFmcLL1Qegzez238wQNAf/ TfEGWCMRnmwZgffCPoB/2Ish3q1myECKLS0zBahaph9pSscLnaUpyfeTp srTZsOwDT4uvO+VQOhGneIQSiE+2R6Kcw3OSPoIbbjPxzEqX/xexB77Ex c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhxUAJYs5FCQ/khN/2dsb2JhbABFgX+BSYJytxIWc4IeAQEBBDIBRQEQCQIYBAUMCggFAgkDAgECATQRBg0BBQIBAYgPDIxomm8IkEeBHos5C4EDgh6BFwOIMo1ahWuKXYJ0gXE X-IronPort-AV: E=Sophos;i="4.84,395,1355097600"; d="scan'208";a="79474060" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 02 Jan 2013 12:50:33 +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 r02CoXj0025397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2013 12:50:33 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 r02CoVoH003755; Wed, 2 Jan 2013 12:50:32 GMT Message-ID: <50E42D17.7040504@cisco.com> Date: Wed, 02 Jan 2013 12:50:31 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Hejia References: <502F40CC.4060000@pi.nu> <735916399E11684EAF4EB4FB376B7195264993AE@SZXEML505-MBS.china.huawei.com> In-Reply-To: <735916399E11684EAF4EB4FB376B7195264993AE@SZXEML505-MBS.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] MPLS-RT Review of draft-fbb-mpls-tp-p2mp-framework-05 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: Wed, 02 Jan 2013 12:50:37 -0000 On 03/09/2012 13:26, Hejia wrote: > Hi , > > I have finished reviewing draft-fbb-mpls-tp-p2mp-framework-05.txt as the member of MPLS Review team and have the following comments: > > * Is the document coherent? > > It is close to coherent. Please take the following two comments into account when further progressing this draft. > > 1. There are a few drafts referenced in this document have expired, e.g. > [I-D.ietf-pwe3-p2mp-pw-requirements] This one Matthew can give the latest status on. It needs a major re-write, but it does need to be written. The best that we can do at the moment is to keep the reference in as a placeholder. > [I-D.ietf-l2vpn-vpms-frmwk-requirements] This is now current > [I-D.raggarwa-pwe3-p2mp-pw-encaps]. Again Matthew can perhaps comment, but the PWE3 WG will need to produce a document with equivalent text. My assumption is that it will be phased behind the p2mp requirements draft. For the moment this is the best placeholder we have. > > Please check the availability of the relevant content in these drafts referenced in this document. > > 2. Section 4 Operations, Administration and Maintenance (OAM) > There is an editor's note reminding the coordination work between this draft and [I-D.hmk-mpls-tp-p2mp-oam-framework]. It is better to work out the details before moving to WG adoption. I disagree. By adoption the WG is making the statement that it is working on this work and this is only a section of the work. > > > * Is it useful (i.e., is it likely to be actually useful in operational networks), and is the document technically sound? > > I believe this document is useful. One comment about Section 6: > Section 6 summarizes the 1+1 protection scheme for unidirectional P2MP transport paths as defined in [RFC6372]. However, some description in this section (see below) is applicable to 1:1 instead of 1+1 P2MP protection. > > "Fault notification > happens from the node idenifying the fault to the root node and from > the leaves to the root via an out of band path. " I have noted that the referenced text (RFC6373 section 4.7.3) deals with both 1+1 and 1:1 > > * Is the document ready to be considered for WG adoption? > It is suggested to clear up the issues listed above before moving forward to WG adoption. > > > * Nits > > 1. Section 4 Operations, Administration and Maintenance (OAM) > s/spacific/specific done > > 2. Section 5.2 Point-to-Multipoint PW Control Plane > " [I-D.ietf-pwe3-p2mp-pw]" at the beginning of this paragraph should be deleted. done > 3. Section 6 Survivability > s/eather/either > s/ identifying/identifying done (can't find the second issue) - Stewart > > B.R. > Jia > > > -----邮件原件----- > 发件人: Loa Andersson [mailto:loa@pi.nu] > 发送时间: 2012年8月18日 15:14 > 收件人: kenji.fujihira.dj@hitachi.com; Hejia; David Allan I > 抄送: draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org; mpls-chairs@tools.ietf.org; Martin Vigoureux > 主题: MPLS-RT Review of draft-fbb-mpls-tp-p2mp-framework-05 > > Kenji, Jia, Dave; > > You have been selected as an MPLS Review team reviewers for > draft-fbb-mpls-tp-p2mp-framework-05.txt > > 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 Sep 3, 2012? > > Thanks, Loa > (as MPLS WG chair) -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From lmartini@cisco.com Thu Jan 3 11:03:37 2013 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 4DA2321F86C8; Thu, 3 Jan 2013 11:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 tBhDrT6IkxeY; Thu, 3 Jan 2013 11:03:36 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAAC21F861F; Thu, 3 Jan 2013 11:03:36 -0800 (PST) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id r03J3Ufm017174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2013 12:03:32 -0700 (MST) Message-ID: <50E5D601.1010604@cisco.com> Date: Thu, 03 Jan 2013 12:03:29 -0700 From: Luca Martini User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Alexander Vainshtein References: <4FFC75D9.5080604@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , pwe3 Subject: Re: [mpls] [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes 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, 03 Jan 2013 19:03:37 -0000 On 07/10/12 23:21, Alexander Vainshtein wrote: > Luca (and all), > I fully support the idea of progressing RFC 4447 to Internet Standard. > > Looking up the draft, I have found the following difference with the current text: > > RFC 4447, Section 3: > LDP MUST be used in its "downstream unsolicited" mode. > which is quite unambiguous. > > > draft-ietf-pwe3-rfc4447bis-00, Section 3, changes this to: > LDP MUST exchange PW FEC label bindings in downstream unsolicited manner, independent of the > negotiated label advertisement mode of the LDP session. > > I assume that this is the change you've had in mind when you said: > ""Added text to specify that downstream unsolicited bit does not apply to PW application..." > even if the actual text states that it does apply. Yes. > But, what is more serious, this seems to contradict the following statement in RFC 5036, Section 2.6: > However, for any given LDP session, each LSR must be aware of the label distribution method used by its peer > in order to avoid situations where one peer using Downstream Unsolicited label distribution assumes its peer is also. Yes. the MPLS wg is in the process of fixing that problem. There is a draft already in the queue there. Please see draft-ietf-mpls-ldp-applicability-label-adv-00.txt . I am making sure thsi document is compliant with that. > and further in Section 2.6.3: > Each interface on an LSR is configured to operate in either > Downstream Unsolicited or Downstream on Demand advertisement mode. > LSRs exchange advertisement modes during initialization. > > I am not sure that the proposed change in 4447 complies with the quoted statements in 5036. It is not supposed to comply with those statements. > > A reference (in the notes only, not in the draft) to draft-raza (which has not yet been posted as a WG document) does not justify such a deviation IMHO. It could also put 4447bis on hold if an explicit dependency is created. At the very least we should hear what the MPLS WG has to say on that. > > And, speaking about references, I see that RFC 4448 is marked as "Work in Progress" in the draft. So draft-ietf-mpls-ldp-applicability-label-adv-00.txt proposes exactly the text that i added to rfc4447bis. I suggest that you send comments the mpls ldp mode bit to the MPLS WG. I believe that is a typo. will fix it. > Is it just a typo, or do you imply that it is going to undergo a revision soon? > > Hopefully these notes will be useful. Thank you for the review ! Luca > Regards, > Sasha > > ________________________________________ > From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Luca Martini [lmartini@cisco.com] > Sent: Tuesday, July 10, 2012 8:35 PM > To: pwe3 > Subject: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes > > WG, > > At the request of the chairs, I have posted the initial version of an > update to rfc4447. > > This is the next step in the process defined by rfc6410 to progress this > document to "Internet Standard". > Quoting rfc6410: > > " A specification may be, and indeed, is likely to be, revised as it > advances from Proposed Standard to Internet Standard. When a revised > specification is proposed for advancement to Internet Standard, the > IESG shall determine the scope and significance of the changes to the > specification, and, if necessary and appropriate, modify the > recommended action. Minor revisions and the removal of unused > features are expected, but a significant revision may require that > the specification accumulate more experience at Proposed Standard > before progressing." > > According to the above guidelines, I have revised the rfc4447 document > to incorporate all erratas , and a WG discussions about the PW > encapsulation being symmetric in both direction of traffic. I also added > a clarification about the LDP mode bit as per MPLS WG discussion. > Let me know what else I might have missed. > > Here is a list of changes from my log: > -------------------------------------------------------------------------------------------------------------------------------- > - Updated all references - published v00 of bis rfc draft > - Added clarification about PW always being symmetrical in both > direction of traffic. > - Changed Generalized ID FEC element, and Generalized PWid FEC element > to >> Generalized PWid FEC element to be consistent with IANA allocation > and within the document ( this was noted in errata, but IMHO incorrectly > rejected ) > - Errata ID: 1530 - accepted > - Errata ID: 3112 - accepted > - Errata ID: 3114 - accepted > - Errata ID: 3115 - removed table > - Errata ID: 86 - accepted > - Errata ID: 938 - accepted > - Added text to specify that downstream unsolicited bit does not apply > to pw application according to > draft-raza-mpls-ldp-applicability-label-adv-02.txt (WG document of MPLS WG) > - made source identical , to rfc > > -------------------------------------------------------------------------------------------------------------------------------- > > Thanks. > Luca > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > From loa@pi.nu Thu Jan 3 12:12:59 2013 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 675D721F8D4C for ; Thu, 3 Jan 2013 12:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 iSGUiq6cNpqY for ; Thu, 3 Jan 2013 12:12:59 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id CD15D21F8D49 for ; Thu, 3 Jan 2013 12:12:58 -0800 (PST) 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 308B6823B5; Thu, 3 Jan 2013 21:12:55 +0100 (CET) Message-ID: <50E5E64A.8090105@pi.nu> Date: Thu, 03 Jan 2013 21:12:58 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 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-fbb-mpls-tp-p2mp-framework@tools.ietf.org" Subject: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg 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, 03 Jan 2013 20:12:59 -0000 Working group, This is to start a two week poll on adopting draft-fbb-mpls-tp-p2mp-framework-06 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 January 17, 2013. There are no IPR claim against this document. All the active co-authors has stated on the working group mailing list that they are not aware of any other IPR claims than those already disclosed. /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 hejia@huawei.com Thu Jan 3 23:13:26 2013 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 6990121F8E9C for ; Thu, 3 Jan 2013 23:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, 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 yBIMkRqDWSWH for ; Thu, 3 Jan 2013 23:13:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8CB21F8E9A for ; Thu, 3 Jan 2013 23:13:23 -0800 (PST) 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 AOK87909; Fri, 04 Jan 2013 07:13:21 +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; Fri, 4 Jan 2013 07:12:36 +0000 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 Jan 2013 15:13:20 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.68]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Fri, 4 Jan 2013 15:13:15 +0800 From: "Hejia (Jia)" To: "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg document Thread-Index: AQHN6e6+kBz0giqBNUyQk0NnXIK3rJg4wXyg Date: Fri, 4 Jan 2013 07:13:15 +0000 Message-ID: <735916399E11684EAF4EB4FB376B71952BF6403E@SZXEML505-MBS.china.huawei.com> References: <50E5E64A.8090105@pi.nu> In-Reply-To: <50E5E64A.8090105@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.169] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg 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, 04 Jan 2013 07:13:26 -0000 WWVzLCBzdXBwb3J0Lg0KDQpUaGUgbGF0ZXN0IHZlcnNpb24gaGFzIGFkZHJlc3NlZCBteSBjb21t ZW50cy4gDQoNCkIuUi4NCkppYQ0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBtcGxz LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTG9h IEFuZGVyc3Nvbg0Kt6LLzcqxvOQ6IDIwMTPE6jHUwjTI1SA0OjEzDQrK1bz+yMs6IG1wbHNAaWV0 Zi5vcmcNCrOty806IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1mYmItbXBscy10 cC1wMm1wLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZw0K1vfM4jogW21wbHNdIHBvbGwgdG8gc2Vl IGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LWZiYi1tcGxzLXRwLXAybXAtZnJhbWV3 b3JrLTA2LnR4dCBhbiBNUExTIHdnIGRvY3VtZW50DQoNCldvcmtpbmcgZ3JvdXAsDQoNClRoaXMg aXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIGFkb3B0aW5nDQpkcmFmdC1mYmItbXBscy10 cC1wMm1wLWZyYW1ld29yay0wNiBhcyBhbiBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoN ClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBt cGxzIHdvcmtpbmcNCmdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZykuIFBsZWFz ZSBnaXZlIGFuIHRlY2huaWNhbA0KbW90aXZhdGlvbiBmb3IgeW91ciBzdXBwb3J0L25vdCBzdXBw b3J0LCBlc3BlY2lhbGx5IGlmIHlvdSB0aGluayB0aGF0DQp0aGUgZG9jdW1lbnQgc2hvdWxkIG5v dCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4NCg0KVGhpcyBwb2xsIGVu ZHMgSmFudWFyeSAxNywgMjAxMy4NCg0KVGhlcmUgYXJlIG5vIElQUiBjbGFpbSBhZ2FpbnN0IHRo aXMgZG9jdW1lbnQuDQoNCkFsbCB0aGUgYWN0aXZlIGNvLWF1dGhvcnMgaGFzIHN0YXRlZCBvbiB0 aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCnRoYXQgdGhleSBhcmUgbm90IGF3YXJlIG9m IGFueSBvdGhlciBJUFIgY2xhaW1zIHRoYW4gdGhvc2UgYWxyZWFkeQ0KZGlzY2xvc2VkLg0KDQov TG9hDQoobXBscyB3ZyBjby1jaGFpcikNCg0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAg ICAgICAgICAgICAgICAgICBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NClNyIFN0 cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KRXJpY3Nz b24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIg OTIgMTMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt cGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQo= From hejia@huawei.com Fri Jan 4 01:39:39 2013 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 251A821F8EBD; Fri, 4 Jan 2013 01:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.328 X-Spam-Level: X-Spam-Status: No, score=-4.328 tagged_above=-999 required=5 tests=[AWL=2.271, 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 gKvZXCeWtYp1; Fri, 4 Jan 2013 01:39:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3B721F8EBC; Fri, 4 Jan 2013 01:39:37 -0800 (PST) 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 ANE70316; Fri, 04 Jan 2013 09:39:36 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 Jan 2013 09:38:19 +0000 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 Jan 2013 17:39:15 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.68]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 4 Jan 2013 17:37:44 +0800 From: "Hejia (Jia)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-mpls-tp-itu-t-identifiers-06.txt Thread-Index: Ac3qXyTvBrQwmw89THOMUM0w8Qx7SQ== Date: Fri, 4 Jan 2013 09:37:43 +0000 Message-ID: <735916399E11684EAF4EB4FB376B71952BF640C9@SZXEML505-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.169] Content-Type: multipart/alternative; boundary="_000_735916399E11684EAF4EB4FB376B71952BF640C9SZXEML505MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-itu-t-identifiers.all@tools.ietf.org" , "mpls@ietf.org" Subject: [mpls] RtgDir review: draft-ietf-mpls-tp-itu-t-identifiers-06.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: Fri, 04 Jan 2013 09:39:39 -0000 --_000_735916399E11684EAF4EB4FB376B71952BF640C9SZXEML505MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-mpls-tp-itu-t-identifiers-06.txt Reviewer: Jia He Review Date: Jan 4, 2013 IETF LC End Date: Jan 4, 2013 Intended Status: Standards Track Summary: I have one minor concern about this document that I think should be resolve= d before publication. Comments: The document is well structured and easy to understand. It is a useful draf= t that complements the MPLS-TP draft set. Major Issues: No major issues found. Minor Issues: 1) Section 7, the description of "maintenance entities" needs review. Section 7 has the following description about "maintenance entities", which= confusingly implies that MEPs or MIPs are MEs. These maintenance entities can be e.g. Maintenance Entity Group End Points (MEPs) or Maintenance Entity Group Intermediate Points (MIPs). However, there is explicit definition of "maintenance entity" in RFC 6371 (= see below), which indicates a relationship, not separately MEPs or MIPs. Maintenance Entity (ME): Some portion of a transport path that requires management bounded by two points (called MEPs), and the relationship between those points to which maintenance and monitoring operations apply Therefore, it is suggested to replace the sentence "These maintenance entit= ies can be..." with the definition of MEPs and MIPs in RFC 6371, or remove = all the definition description of MEGs, MEPs and MIPs in this paragraph and= refer to RFC 6371. Nits: Section 6 s/In stead of/Instead of Section 7 s/enties/entities Section 7.1 s/CC:ICC:UMC/CC::ICC::UMC B.R. Jia --_000_735916399E11684EAF4EB4FB376B71952BF640C9SZXEML505MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have been selected as the Rou= ting Directorate reviewer for this draft. The Routing Directorate seeks to = review all routing or routing-related drafts as they pass through IETF last= call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to = the Routing ADs. For more information about the Routing Directorate, please= see http://www.ietf.org/iesg/directorate/routing.html

 

Although these comments are pri= marily for the use of the Routing ADs, it would be helpful if you could con= sider them along with any other IETF Last Call comments that you receive, a= nd strive to resolve them through discussion or by updating the draft.

 

Document: draft-ietf-mpls-tp-it= u-t-identifiers-06.txt

Reviewer: Jia He

Review Date: Jan 4, 2013 <= /o:p>

IETF LC End Date: Jan 4, 2013 <= o:p>

 

Intended Status: Standards Trac= k

 

Summary:

 

I have one minor concern about = this document that I think should be resolved before publication.

 

Comments:

 

The document is well structured= and easy to understand. It is a useful draft that complements the MPLS-TP = draft set.

 

 

Major Issues:

No major issues found.

 

 

Minor Issues:

 

1) Section 7, the description o= f "maintenance entities" needs review.

 

Section 7 has the following des= cription about "maintenance entities", which confusingly implies = that MEPs or MIPs are MEs.

 

   These maintenance = entities can be e.g.  Maintenance

   Entity Group End P= oints (MEPs) or Maintenance Entity Group

   Intermediate Point= s (MIPs). 

 

However, there is explicit defi= nition of "maintenance entity" in RFC 6371 (see below), which ind= icates a relationship, not separately MEPs or MIPs.

 

   Maintenance Entity= (ME): Some portion of a transport path that

   requires managemen= t bounded by two points (called MEPs), and the

   relationship be= tween those points to which maintenance and monitoring

   operations apply

 

Therefore, it is suggested to r= eplace the sentence "These maintenance entities can be..." with t= he definition of MEPs and MIPs in RFC 6371, or remove all the definition de= scription of MEGs, MEPs and MIPs in this paragraph and refer to RFC 6371.

 

 

Nits:

 

Section 6

s/In stead of/Instead of

 

Section 7

s/enties/entities

 

Section 7.1

s/CC:ICC:UMC/CC::ICC::UMC<= /o:p>

 

 

 

B.R.

Jia

--_000_735916399E11684EAF4EB4FB376B71952BF640C9SZXEML505MBSchi_-- From daviball@cisco.com Fri Jan 4 03:00:42 2013 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 2BAC221F88E2 for ; Fri, 4 Jan 2013 03:00:42 -0800 (PST) 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 aC6fjaR7Mngb for ; Fri, 4 Jan 2013 03:00:41 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BCAC121F88E1 for ; Fri, 4 Jan 2013 03:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8989; q=dns/txt; s=iport; t=1357297239; x=1358506839; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=EH3yhVcrWVvIMsFGSly/gpfVlbLCmQbCqtGIfgcfJ28=; b=m4AirvKSXaaSii3rnXnuC58vj6FqHlpWEi62rzDgQylN1TAA+rgfknih OVD6VomEballOSn8VDRKOOYGQe78hasC6cGRRF+Dy4E5+1X3ycP/qqF3y LDNcxlahrUWZRngovjIL4+c/Ba+oxANhEcc8Cmnw+EDeWDko/J5XEGegJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqASACW15lCQ/khL/2dsb2JhbAArGoNIpzmRUQJ8FnOCHgEBAQMBAQEBJBMxAwQHBQcECxEEAQEBCR4HDwUTHgEJDhOIAQMJBgwstV2LbGpjgn9hA4tTiGeBUQGGWoRdhRGCdHhwJA X-IronPort-AV: E=Sophos;i="4.84,409,1355097600"; d="scan'208";a="79518261" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 04 Jan 2013 11:00:34 +0000 Received: from ensoft-linux3.cisco.com (ensoft-linux3.cisco.com [10.63.23.12]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r04B0YPA001456 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2013 11:00:34 GMT Received: from daviball by ensoft-linux3.cisco.com with local (Exim 4.76) (envelope-from ) id 1Tr50r-0000tw-Go; Fri, 04 Jan 2013 11:00:33 +0000 Date: Fri, 4 Jan 2013 11:00:33 +0000 From: David Ball To: Yoshinori Koike Message-ID: <20130104110030.GD14216@cisco.com> References: <20121212174431.2DCABB1E002@rfc-editor.org> <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> <50CB6508.10804@lab.ntt.co.jp> <20121217140541.GN4232@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121217140541.GN4232@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 04 Jan 2013 11:00:42 -0000 Hi Yoshinori, Did you have any further thoughts on this? Thanks, David On Mon, Dec 17, 2012, David Ball wrote: > Hi Yoshinori, > > Thanks for your comments. > > With regards to your proposal, I am still a little unclear on the > intended relationship between the dataplane loopback point and the > MIP/MEP. Are these always on the same interface? If not, under what > conditions could they be on different interfaces? How is the location > of the dataplane loopback point determined? > > To take a concrete example, suppose we have an interface with both a LSP > MEP and a PW MEP. OAM packets destined for the LSP MEP will have an LSP > label and a GAL, while OAM packets destined for the PW MEP will have an > LSP label and a PW label. Client data traffic will also have both an > LSP and a PW label. > > Now, if either the LSP MEP or the PW MEP are put into a loopback mode, > all of the client data packets will be looped. But which OAM packets > are looped? > - If the LSP MEP is put into loopback mode, do the LSP OAM packets get > looped? I think so, since RFC6435 says that both data and OAM > packets are looped. > - If the LSP MEP is put into loopback mode, do the PW OAM packets get > looped? Again, I think so. > - If the PW MEP is put into loopback mode, do the PW OAM packets get > looped? I think yes, this is equivalent to the first case. > - If the PW MEP is put into loopback mode, do the LSP OAM packets get > looped. Since they do not have a PW label, I am not sure? I think > probably they shouldn't be, since there may be other PWs flowing over > the same LSP, with different PW labels, right? > > > Regarding ITU-T G.8121 Amd 1 and G.8121.2, the reason the dataplane > loopback process was removed from the MTDe figures in the last SG15 > meeting was because of this confusing sentence in RFC6435 - in other > words, it wasn't clear whether the MTDe function was the right place for > them so as to match the behaviour specified in the RFC. The intent of > G.8121.2 is to exactly match RFC6435 and the other relevant IETF RFCs. > > As a result, in the current ITU-T G.8121/G.8121.2, the dataplane > loopback processes do not appear in any of the termination or adaptation > functions that are specified; so although the processes themselves are > defined, they are never applied. The question is, what is the correct > place to apply them in the ITU-T model so as to match the RFC? > > > David > > > On Sat, Dec 15, 2012, Yoshinori Koike wrote: > > Hello David, > > > > I agree with original text is confusing and thank you for the > > proposal. However, I'm wondering if the proposed text is true and > > exactly reflect the intent explained in the notes. > > > > My suggestion is as follows: > > It should be noted that the data-plane loopback function itself is > > applied to data-plane loopback point which is different from > > MIP/MEP. > > > > Firstly, the description "the data-plane loopback function may be > > applied at MIPs/MEPs" doesn't seem to be true. > > > > In my understanding, data-plane loopback function can be > > set/enabled/disabled at MIP/MEP using a management system but not be > > applied to MIP/MEP itself. So I clarified this point in my proposal. > > > > One of the reason is that MIP/MEP is only involved in OAM packets. > > There seems no specification in any RFC, which describe that MIP/MEP > > could handle data packets which are not OAM packets . > > > > In G.8121 amd1, data-plane loopback sink and source are specified > > and according to Temporary Document(TD673R1<->R0/Plen) during last > > SG15 meeting, the data-plane loopback sink/source was removed from > > figures of MTDe_TT_Sk/So Process(Fig.9-14&16). I guess this might be > > to avoid a restriction of implementations, however it doesn't seem > > to make it possible to apply dataplane loopback point to MIP/MEP. In > > realty, if data-plane loopback function is enabled, for data-plane > > LB function there is no need to parse the packet except for > > outermost label value. > > > > Secondly, if you need to clarify the relationship between data-plane > > LB point at which data-plane LB function is conducted and MIP/MEP at > > which data-plane LB function is enabled/configured using management > > system, it seems enough just to say the two point usually resides on > > the same interface and clarify the binding of two points. I have no > > issue on this specification. However, just in case, it seems better > > to confirm if the change is ok in ITU-T joint interregnum meeting > > Jan 2013, because this is a matter of 8121 or/and G.8121.1. As a > > result, I didn't add related text in my proposal. > > > > I'm not an implementer, so I would appreciate it if you could > > correct me if I'm wrong. Thank you in advance. > > > > Best regards, > > > > Yoshinori > > > > > > (2012/12/13 3:17), Adrian Farrel wrote: > > >Hello, > > > > > >Authors of RFC 6435: I need to hear from you that you meant the text that David > > >suggests. It is very clearly not what you wrote and, if you meant something > > >different, it is clear why people are confused! > > > > > >Working group: I need to hear from you that you agree with David's > > >interpretation and support his proposed change. > > > > > >Only then will I try to work out whether this is a "typo" worthy of an errata > > >report, or a technical change needing a revised RFC. > > > > > >Thanks, > > >Adrian > > > > > >>-----Original Message----- > > >>From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > >>Sent: 12 December 2012 17:45 > > >>To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > > >>martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > > >>stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; > > >>rcallon@juniper.net > > >>Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org > > >>Subject: [Editorial Errata Reported] RFC6435 (3429) > > >> > > >> > > >>The following errata report has been submitted for RFC6435, > > >>"MPLS Transport Profile Lock Instruct and Loopback Functions". > > >> > > >>-------------------------------------- > > >>You may review the report below and at: > > >>http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 > > >> > > >>-------------------------------------- > > >>Type: Editorial > > >>Reported by: David Ball > > >> > > >>Section: 4 (para 5) > > >> > > >>Original Text > > >>------------- > > >>It should be noted that the data-plane loopback function itself is applied to > > >data- > > >>plane loopback points residing on different interfaces from MIPs/MEPs. > > >> > > >>Corrected Text > > >>-------------- > > >>It should be noted that the data-plane loopback function may be applied at > > >>MIPs/MEPs on different interfaces for different LSPs. > > >> > > >>Notes > > >>----- > > >>The existing text has caused confusion (specifically, among experts in ITU-T > > >SG15 > > >>when discussing G.8121.2), in that it seems to suggest that the interface > > >where > > >>the MIP/MEP is located may be a different interface to the one where the > > >>loopback is applied. > > >> > > >>Having spoken with some of the original authors, it seems this was not the > > >intent > > >>of this sentence; the intent was to point out that as different LSPs would > > >have > > >>MIPs/MEPs on different interfaces, the corresponding loopback functions would > > >>also be applied on different interfaces. > > >> > > >>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. > > >> > > >>-------------------------------------- > > >>RFC6435 (draft-ietf-mpls-tp-li-lb-08) > > >>-------------------------------------- > > >>Title : MPLS Transport Profile Lock Instruct and Loopback > > >Functions > > >>Publication Date : November 2011 > > >>Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. > > >Vigoureux, > > >>Ed., X. Dai, Ed. > > >>Category : PROPOSED STANDARD > > >>Source : Multiprotocol Label Switching > > >>Area : Routing > > >>Stream : IETF > > >>Verifying Party : IESG > > > > > >_______________________________________________ > > >mpls mailing list > > >mpls@ietf.org > > >https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > -- > > Yoshinori Koike > > koike.yoshinori@lab.ntt.co.jp > > > > -- > David Ball > -- David Ball From stbryant@cisco.com Fri Jan 4 07:48:20 2013 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 C3F5121F8767 for ; Fri, 4 Jan 2013 07:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 wZYq7qinDoTJ for ; Fri, 4 Jan 2013 07:48:20 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id D37B621F8756 for ; Fri, 4 Jan 2013 07:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=976; q=dns/txt; s=iport; t=1357314500; x=1358524100; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=Zr9Ajjraa8hz8RTfKtCtlwMX4oVjuAAMn8QKGJ+fPlU=; b=LIe1U4mtV7fHDc6X+n/HeeWk2s7n2EKwnpfzRyxm21w1eMLViHslbPmf nKF8e4JiMHfgiInSqseVQgod7gXddjzaB5rdaWA1os4rMyOLar638D2Ke ZYUv0iqZ890kvV8GmggOfYsVQ0VyC/Ez2LorDgnQfdGy92aF7PTSo3ru0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisIACX55lCQ/khN/2dsb2JhbABFg0e2O4FMgX8Wc4IeAQEBBDg2ChELGAkWBAsJAwIBAgFFEwgBAYgQtGeNbIMpA5YLhWuKXoJ0 X-IronPort-AV: E=Sophos;i="4.84,411,1355097600"; d="scan'208";a="10872853" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 04 Jan 2013 15:48:18 +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 r04FmH8V019959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Jan 2013 15:48:18 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 r04FmFrD018338; Fri, 4 Jan 2013 15:48:16 GMT Message-ID: <50E6F9BF.9090601@cisco.com> Date: Fri, 04 Jan 2013 15:48:15 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mpls@ietf.org References: <50E5E64A.8090105@pi.nu> In-Reply-To: <50E5E64A.8090105@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg document 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: Fri, 04 Jan 2013 15:48:20 -0000 On 03/01/2013 20:12, Loa Andersson wrote: > Working group, > > This is to start a two week poll on adopting > draft-fbb-mpls-tp-p2mp-framework-06 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 January 17, 2013. > > There are no IPR claim against this document. > > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. > > /Loa > (mpls wg co-chair) > Loa This draft was written to fulfill our commitment to the ITU-T to document a framework for running p2mp mpls-tp. It is the only candidate text that fulfills this propose. Stewart (as an editor of the draft) From lizhong.jin@zte.com.cn Fri Jan 4 23:29:12 2013 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 3267E21F86CC; Fri, 4 Jan 2013 23:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 EV0ByQQsoWuK; Fri, 4 Jan 2013 23:29:11 -0800 (PST) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4FF21F869A; Fri, 4 Jan 2013 23:29:08 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id CFC3F8A1FC; Sat, 5 Jan 2013 15:28:56 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 84D017194BE; Sat, 5 Jan 2013 15:18:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r057SonE069134; Sat, 5 Jan 2013 15:28:50 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) To: pwe3@ietf.org, lmartini@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Sat, 5 Jan 2013 15:27:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-05 15:28:29, Serialize complete at 2013-01-05 15:28:29 Content-Type: multipart/alternative; boundary="=_alternative 00291A9648257AEA_=" X-MAIL: mse01.zte.com.cn r057SonE069134 Cc: mpls@ietf.org, andrew.g.malis@verizon.com, chen.ran@zte.com.cn, Sami Boutros , lizho.jin@gmail.com, kingston.selvaraj@ipinfusion.com, elisa.bellagamba@ericsson.com Subject: [mpls] PW config checking in draft-reduction and draft-jc 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, 05 Jan 2013 07:29:12 -0000 This is a multipart message in MIME format. --=_alternative 00291A9648257AEA_= Content-Type: text/plain; charset="US-ASCII" Hi Luca, Thanks for the comment during IETF85 for draft-jc-pwe3-static-config-check-01: "Luca: In the refresh reduction draft, it does configuration checking and it is expandable. We need to reconcile what is in the refresh reduction and see if we can reuse it." I review draft-ietf-pwe3-status-reduction-00, and yes, this draft contains the configuration checking, and the main difference between draft-reduction and draft-jc would be: 1. draft-redunction defines a new protocol (status redunction protocol) to do the configuration checking, and draft-jc reuse GAP[ietf-mpls-gach-adv] to do the checking. 2. the text in draft-redunction describes the checking whether the PW is configured or not, while draft-jc describes the checking whether the PW parameters of both ends matches. The second point is easy to reconcile by extending the PW status reduction protocol. Then the key point is which protocol is more suitable for configuration checking, redunction protocol or GAP? Note that there is another MPLS draft to do LSP configuration check using GAP, draft-smiler-mpls-tp-static-lsp-config-check. So the mail is cc to MPLS WG too. I tend to prefer the GAP to do the PW configuration checking, since redunction protocol is a specially designed protocol to reduce PW status message. Hope to see more comments from the WG. Thanks Lizhong --=_alternative 00291A9648257AEA_= Content-Type: text/html; charset="US-ASCII"
Hi Luca,
Thanks for the comment during IETF85 for draft-jc-pwe3-static-config-check-01:
"Luca: In the refresh reduction draft, it does configuration checking and it is expandable.  We need to reconcile what is in the refresh reduction and see if we can reuse it."
I review draft-ietf-pwe3-status-reduction-00, and yes, this draft contains the configuration checking, and the main difference between draft-reduction and draft-jc would be:
1. draft-redunction defines a new protocol (status redunction protocol) to do the configuration checking, and draft-jc reuse GAP[ietf-mpls-gach-adv] to do the checking.
2. the text in draft-redunction describes the checking whether the PW is configured or not, while draft-jc describes the checking whether the PW parameters of both ends matches.
The second point is easy to reconcile by extending the PW status reduction protocol. Then the key point is which protocol is more suitable for configuration checking, redunction protocol or GAP? Note that there is another MPLS draft to do LSP configuration check using GAP, draft-smiler-mpls-tp-static-lsp-config-check. So the mail is cc to MPLS WG too.
I tend to prefer the GAP to do the PW configuration checking, since redunction protocol is a specially designed protocol to reduce PW status message. Hope to see more comments from the WG.

Thanks
Lizhong --=_alternative 00291A9648257AEA_=-- From Alexander.Vainshtein@ecitele.com Sun Jan 6 05:29:29 2013 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 5148521F8775 for ; Sun, 6 Jan 2013 05:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 ox6-aSCnnNaf for ; Sun, 6 Jan 2013 05:29:28 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id A0A0121F876E for ; Sun, 6 Jan 2013 05:29:25 -0800 (PST) Received: from [85.158.138.51:55736] by server-2.bemta-3.messagelabs.com id F3/43-11239-62C79E05; Sun, 06 Jan 2013 13:29:10 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1357478948!19707786!1 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7672 invoked from network); 6 Jan 2013 13:29:09 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Jan 2013 13:29:09 -0000 X-AuditID: 93eaf2e7-b7f816d00000698d-9d-50e974a795fd Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 25.21.27021.7A479E05; Sun, 6 Jan 2013 14:57:11 +0200 (IST) Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Sun, 6 Jan 2013 15:29:08 +0200 Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.02.0328.009; Sun, 6 Jan 2013 15:29:07 +0200 From: Alexander Vainshtein To: Luca Martini Thread-Topic: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes Thread-Index: AQHNXsrYgfdlUXxfr0mSCyPb8SZy+Zcjf45XgRVrXYCABHSHSg== Date: Sun, 6 Jan 2013 13:29:07 +0000 Message-ID: References: <4FFC75D9.5080604@cisco.com> , <50E5D601.1010604@cisco.com> In-Reply-To: <50E5D601.1010604@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTuzj4YN6emTd27S+QwWlC5sssaKO5GBZHVD7cHRIVs4+xtd2h3 ZtsZTevPYj+iLexJkFhaWfaiyJ70bnuZFAmGVFRUZupmWSa9FGtmJ02I7q/v3u875zvncg6u MX7XW3COl1CYZwK03qDdGe+NW+ulLrftQMSR++zQUd1MUFBX9wNzg+UR4GR4XpAYCVFeJLIu 2h3mShm2nKY4r4u201QowLAoiHjJRTOhEOK99AwD9c9xyjKOpxDPCl6O97noeYsLrbm50/Os dnrG5Ay7I9+wxM+JFLIGGS5ABZEoMj5EyS8rz2r8fdWLQwedZRv2vtZGwEtbFCThkMyBV/c1 61WcBptfnkpgI3kdwB99KSq+AODpekcUGGR8G8BI6ymtQuhJF2w4/iIRkEJOgidv9QMFa8g8 eONeRUIznsyHfXuimKpxwqcbB/7g2XBrw44E1pKZsP3jK10U4DhBuuGvDXbVaxOAB1uf6BRN EjkF3mk5k/ACcqHfmk5gqpcJPntbg6kNkLDuyiONilNhV9ugTsXp8My5Np2qz4K1l3v1Kp4G D+9/n9AT5Dh4f89brdqwFTY1RrFtAFaNsKgaEV41IrxqRHgt0B4DqVwgJBUHfTZ7NmI5CQVQ NisEG4A6JB0Xwc+azBggcUAnE40NnW6jjikVy4MxYMYxOpXQiV1u45hiwVvuZ0S/J1wSQGIM QFxDpxBb8mSO8DLl61BYGKLmyD+4XWMZzQryOPKSx2Gz/f9Cm4j6yNJCI+mTh3E1QiEUHsoz AcdpSBjWyxbjwsiHylZxAekvjeFJShnJchmv1ylliCEmKHI+lW8CDryr6Xk7wO/uftEOjFpe 4JHFRPQoUlKR+kv44WxDCxMHJvkbxhOfFFWyvE7D+eKyFSZbobYOxUpenWHKEgE1uYOdXw+d zxi7jM3f2q0b63m4dGHLK+q2OTqtwNxRYd5VJLz54NRfIIo+j8nanNaftXNL9aX4APtl+1oW GFbYhFm1+33pBUXQknGseMFcU2ZO5WEsNr92wpru0lFTPNCQMausZN/Ea8mliypjZwuP4O6b 7zwnzBHPgsqeB80rH9Na0c/Yp2rCIvMbU6YjXQsEAAA= Cc: "mpls@ietf.org" , pwe3 Subject: Re: [mpls] [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes 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, 06 Jan 2013 13:29:29 -0000 Luca, Lots of thanks for a detailed response. I see that in the time that has passed since my original review what has bee= n draft-raza then has become a WG document of the MPLS WG. I I have said before, I wholeheartedly support advancing 4447 to Internet St= andard. However, according to RFC 6410, an Internet Standard must meet the following= requirements that IMHO are relevant for 4447bis: 1. At least two independent interoperable implementations with widespread de= ployment and operational experience. 2. No unused features in the specification that greatly increase implementat= ion complexity. The original 4447 (without the change) would definitely meet these requireme= nts. I am less sure about the proposed modification, and hence worried about= possible delays in the process: - are there two independent interoperable implementations that exchange PW l= abels using DU mode of LDP over a session that has been negotiated as DoD? - are these implementation (and the specific mode of operation we're discus= sing) widely deployed? - if, as I guess, the answer to both questions above is negative, does not t= he proposed change fall under the category of an unused feature in the speci= fication that adds complexity to implementations? Again, I do not have technical concerns about the proposed changes, but I ha= ve procedural concerns about their impact on advancing 4447 to Internet Stan= dard. Hopefully this clarifies my position. Regards, Sasha ________________________________________ From: Luca Martini [lmartini@cisco.com] Sent: Thursday, January 03, 2013 8:03 PM To: Alexander Vainshtein Cc: pwe3; mpls@ietf.org Subject: Re: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes On 07/10/12 23:21, Alexander Vainshtein wrote: > Luca (and all), > I fully support the idea of progressing RFC 4447 to Internet Standard. > > Looking up the draft, I have found the following difference with the curre= nt text: > > RFC 4447, Section 3: > LDP MUST be used in its "downstream unsolicited" mode. > which is quite unambiguous. > > > draft-ietf-pwe3-rfc4447bis-00, Section 3, changes this to: > LDP MUST exchange PW FEC label bindings in downstream unsolicited m= anner, independent of the > negotiated label advertisement mode of the LDP session. > > I assume that this is the change you've had in mind when you said: > ""Added text to specify that downstream unsolicited bit does not apply to= PW application..." > even if the actual text states that it does apply. Yes. > But, what is more serious, this seems to contradict the following statemen= t in RFC 5036, Section 2.6: > However, for any given LDP session, each LSR must be aware of the la= bel distribution method used by its peer > in order to avoid situations where one peer using Downstream Unsoli= cited label distribution assumes its peer is also. Yes. the MPLS wg is in the process of fixing that problem. There is a draft already in the queue there. Please see draft-ietf-mpls-ldp-applicability-label-adv-00.txt . I am making sure thsi document is compliant with that. > and further in Section 2.6.3: > Each interface on an LSR is configured to operate in either > Downstream Unsolicited or Downstream on Demand advertisement mode. > LSRs exchange advertisement modes during initialization. > > I am not sure that the proposed change in 4447 complies with the quoted st= atements in 5036. It is not supposed to comply with those statements. > > A reference (in the notes only, not in the draft) to draft-raza (which has= not yet been posted as a WG document) does not justify such a deviation IMH= O. It could also put 4447bis on hold if an explicit dependency is created. A= t the very least we should hear what the MPLS WG has to say on that. > > And, speaking about references, I see that RFC 4448 is marked as "Work in= Progress" in the draft. So draft-ietf-mpls-ldp-applicability-label-adv-00.txt proposes exactly the text that i added to rfc4447bis. I suggest that you send comments the mpls ldp mode bit to the MPLS WG. I believe that is a typo. will fix it. > Is it just a typo, or do you imply that it is going to undergo a revision= soon? > > Hopefully these notes will be useful. Thank you for the review ! Luca > Regards, > Sasha > > ________________________________________ > From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Luca Mart= ini [lmartini@cisco.com] > Sent: Tuesday, July 10, 2012 8:35 PM > To: pwe3 > Subject: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes > > WG, > > At the request of the chairs, I have posted the initial version of an > update to rfc4447. > > This is the next step in the process defined by rfc6410 to progress this > document to "Internet Standard". > Quoting rfc6410: > > " A specification may be, and indeed, is likely to be, revised as it > advances from Proposed Standard to Internet Standard. When a revised > specification is proposed for advancement to Internet Standard, the > IESG shall determine the scope and significance of the changes to the > specification, and, if necessary and appropriate, modify the > recommended action. Minor revisions and the removal of unused > features are expected, but a significant revision may require that > the specification accumulate more experience at Proposed Standard > before progressing." > > According to the above guidelines, I have revised the rfc4447 document > to incorporate all erratas , and a WG discussions about the PW > encapsulation being symmetric in both direction of traffic. I also added > a clarification about the LDP mode bit as per MPLS WG discussion. > Let me know what else I might have missed. > > Here is a list of changes from my log: > --------------------------------------------------------------------------= ------------------------------------------------------ > - Updated all references - published v00 of bis rfc draft > - Added clarification about PW always being symmetrical in both > direction of traffic. > - Changed Generalized ID FEC element, and Generalized PWid FEC element > to >> Generalized PWid FEC element to be consistent with IANA allocation > and within the document ( this was noted in errata, but IMHO incorrectly > rejected ) > - Errata ID: 1530 - accepted > - Errata ID: 3112 - accepted > - Errata ID: 3114 - accepted > - Errata ID: 3115 - removed table > - Errata ID: 86 - accepted > - Errata ID: 938 - accepted > - Added text to specify that downstream unsolicited bit does not apply > to pw application according to > draft-raza-mpls-ldp-applicability-label-adv-02.txt (WG document of MPLS WG= ) > - made source identical , to rfc > > --------------------------------------------------------------------------= ------------------------------------------------------ > > Thanks. > Luca > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From kenji.fujihira.dj@hitachi.com Mon Jan 7 02:15:48 2013 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 F2DDA21F843F for ; Mon, 7 Jan 2013 02:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 QPQhfW3-fq3f for ; Mon, 7 Jan 2013 02:15:47 -0800 (PST) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 292C721F8417 for ; Mon, 7 Jan 2013 02:15:47 -0800 (PST) Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 11F5F37AC7; Mon, 7 Jan 2013 19:15:46 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id r07AFki6012275; Mon, 7 Jan 2013 19:15:46 +0900 Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id r07AFi2T025933; Mon, 7 Jan 2013 19:15:45 +0900 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id 957FB14003D; Mon, 7 Jan 2013 19:15:44 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id r07AFiX19988654; Mon, 7 Jan 2013 19:15:44 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=ISO-2022-JP To: From: Date: Mon, 7 Jan 2013 19:15:22 +0900 Priority: normal Importance: normal X400-Content-Identifier: X50EAA02D00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28130107191509QRV] Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org Subject: Re: [mpls] MPLS-RT Review of draft-fbb-mpls-tp-p2mp-framework-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: Mon, 07 Jan 2013 10:15:48 -0000 Hi, Stewart. The updated document has addressed my comments. Thank you. Best Regards. Kenji. >On 03/09/2012 11:18, kenji.fujihira.dj@hitachi.com wrote: >> Hi, authors and chairs. >> >> As the MPLS-RT process, I've reviewed draft-fbb-mpls-tp-p2mp-framework-05. >> >> a. Is the document coherent? >> It is almost coherent. I have two comments. >> >> - Section 7. (Network Management) >> I think the following description should be moved from section 7 to section 4 (OAM). >> "Packet Loss and Delay Measurement for >> MPLS Networks [RFC6374] already considers the P2MP case and it is not >> thought that any change is needed to the MPLS-TP profile of [RFC6374] >> [RFC6375]." >Done. >> >> - Section 1.2. (Terminology) >> I suppose PM is "Performance Monitoring", not "Performance Measurement", >> referring to RFC5921, 5951 and 6371. >Done >> b. Is it useful (ie, is it likely to be actually useful in operational networks)? >> I believe this draft is useful. If possible, comments from operators will help. >> >> c. Is the document technically sound? >> My concern is 1:n protection. >> As addressed in section 6, it needs further discussion. >> Relating to this point, it will be valuable if the draft lists up protection types >> P2MP MAY support (for example, partial tree protection as addressed in section 6). >The draft says: >More sophisticated survivability approaches such as partial tree >protection and 1:n protection are for further study. > >The further study can happen during the WG phase of the draft. At this >stage the draft is only up for WG adoption not WG LC, and thus the test is >whether the draft is a good starting point for the WG to work on it, and >I suggest that it passed that hurdle. > >> >> The other descriptions are clear and well aligned with referred RFCs. >> >> d. Is the document ready to be considered for WG adoption? >> IMO, it's better to close my comments above on section 7 before WG adoption. >That one is done. > >- Stewart >> >> Best Regards, >> Kenji. >> >> >>> Kenji, Jia, Dave; >>> >>> You have been selected as an MPLS Review team reviewers for >>> draft-fbb-mpls-tp-p2mp-framework-05.txt >>> >>> Note to authors: You have been CC$BCE(B 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$BCU(B >>> 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$BCE(B 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 Sep 3, 2012? >>> >>> Thanks, Loa >>> (as MPLS WG 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 > > From loa@pi.nu Mon Jan 7 02:21:58 2013 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 D48FE21F842F for ; Mon, 7 Jan 2013 02:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 Z0x1O7DyerH9 for ; Mon, 7 Jan 2013 02:21:57 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id C1B7F21F841A for ; Mon, 7 Jan 2013 02:21:57 -0800 (PST) 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 CDB2B7FE07; Mon, 7 Jan 2013 11:21:55 +0100 (CET) Message-ID: <50EAA1C5.20009@pi.nu> Date: Mon, 07 Jan 2013 11:21:57 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mpls-tp-security-framework@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 07 Jan 2013 10:21:59 -0000 Working Group, This is to start a working group last call on draft-ietf-mpls-tp-security-framework-06. This is the second time this document is working group last called, three has been a major update of the document since last time. Please find a diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-tp-security-framework-05&difftype=--html&submit=Go%21&url2=draft-ietf-mpls-tp-security-framework-06 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. There are no IPR claims against this draft. All the co-authors has stated that they are not ware of any IPRs. This working group last call will end on January 18, 2013. /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 wwwrun@rfc-editor.org Mon Jan 7 13:51:03 2013 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 6903421F892F; Mon, 7 Jan 2013 13:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 GKfyd7wY0Uch; Mon, 7 Jan 2013 13:51:03 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id F3CF521F84D8; Mon, 7 Jan 2013 13:51:02 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9A5CCB1E00F; Mon, 7 Jan 2013 13:40:46 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130107214046.9A5CCB1E00F@rfc-editor.org> Date: Mon, 7 Jan 2013 13:40:46 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6829 on Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 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, 07 Jan 2013 21:51:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6829 Title: Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 Author: M. Chen, P. Pan, C. Pignataro, R. Asati Status: Standards Track Stream: IETF Date: January 2013 Mailbox: mach@huawei.com, ppan@infinera.com, cpignata@cisco.com, rajiva@cisco.com Pages: 8 Characters: 15683 Updates: RFC4379 I-D Tag: draft-ietf-mpls-ipv6-pw-lsp-ping-04.txt URL: http://www.rfc-editor.org/rfc/rfc6829.txt The Multiprotocol 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 LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for PWs are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that are set up and maintained using IPv6 LDP sessions. This document updates RFC 4379. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From mach.chen@huawei.com Mon Jan 7 22:29:51 2013 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 A6F2021F8782 for ; Mon, 7 Jan 2013 22:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=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 dWRC7uYQWzOz for ; Mon, 7 Jan 2013 22:29:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2936921F87AB for ; Mon, 7 Jan 2013 22:29:41 -0800 (PST) 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 AON61861; Tue, 08 Jan 2013 06:29:39 +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; Tue, 8 Jan 2013 06:28:29 +0000 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 Jan 2013 06:29:36 +0000 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.77]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 8 Jan 2013 14:29:11 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AQHN7MDXD3uRZ9LpNE27W98KqaJROZg+86Sw Date: Tue, 8 Jan 2013 06:29:09 +0000 Message-ID: References: <50EAA1C5.20009@pi.nu> In-Reply-To: <50EAA1C5.20009@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.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 08 Jan 2013 06:29:51 -0000 Hi, I have read the latest version of the draft, I am OK with the content and s= upport to move it forward.=20 One comment about the Terminology section, it lists only partial terminolog= ies used in the document and some of the terminologies(e.g., MEP, MIP) are = actually not used in the draft. It's better that the authors could review t= he draft and then add all(or most of ) the major terminologies and remove t= he useless terminologies. Or the simplest way is just to remove the whole T= erminologies Section :-). Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of L= oa > Andersson > Sent: Monday, January 07, 2013 6:22 PM > To: mpls@ietf.org > Cc: draft-ietf-mpls-tp-security-framework@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework >=20 > Working Group, >=20 > This is to start a working group last call on > draft-ietf-mpls-tp-security-framework-06. >=20 > This is the second time this document is working group last called, > three has been a major update of the document since last time. >=20 > Please find a diff: > http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-tp-security-framework-= 05&diff > type=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-security-framework= -06 >=20 > Please send your comments to the mpls working group mailing > list (mpls@ietf.org). >=20 > Please send both technical comments, and if you are happy with the > document as is also indications of support. >=20 > There are no IPR claims against this draft. >=20 > All the co-authors has stated that they are not ware of any IPRs. >=20 > This working group last call will end on January 18, 2013. >=20 > /Loa > for the wg co-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 From ietfc@btconnect.com Tue Jan 8 03:07:25 2013 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 33BDB21F867D for ; Tue, 8 Jan 2013 03:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.019 X-Spam-Level: X-Spam-Status: No, score=-4.019 tagged_above=-999 required=5 tests=[AWL=-2.280, BAYES_20=-0.74, 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 R34Bd2ae2DsH for ; Tue, 8 Jan 2013 03:07:24 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id BE86821F86C8 for ; Tue, 8 Jan 2013 03:07:23 -0800 (PST) Received: from mail68-db3-R.bigfish.com (10.3.81.229) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 8 Jan 2013 11:07:22 +0000 Received: from mail68-db3 (localhost [127.0.0.1]) by mail68-db3-R.bigfish.com (Postfix) with ESMTP id 5B6154002A0; Tue, 8 Jan 2013 11:07:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.181; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 4 X-BigFish: PS4(zzzz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh304l1155h) Received: from mail68-db3 (localhost.localdomain [127.0.0.1]) by mail68-db3 (MessageSwitch) id 1357643240461099_9988; Tue, 8 Jan 2013 11:07:20 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.248]) by mail68-db3.bigfish.com (Postfix) with ESMTP id 6485A1E0052; Tue, 8 Jan 2013 11:07:20 +0000 (UTC) Received: from DBXPRD0711HT003.eurprd07.prod.outlook.com (157.56.254.181) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 8 Jan 2013 11:07:18 +0000 Received: from DBXPRD0611HT003.eurprd06.prod.outlook.com (157.56.254.85) by pod51017.outlook.com (10.255.178.36) with Microsoft SMTP Server (TLS) id 14.16.245.2; Tue, 8 Jan 2013 11:07:17 +0000 Message-ID: <030801cded90$01ab75e0$4001a8c0@gateway.2wire.net> From: t.petch To: Loa Andersson , References: <4FA01005.1080002@pi.nu> Date: Tue, 8 Jan 2013 11:04:56 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.85] X-OriginatorOrg: btconnect.com Subject: [mpls] RFC6639 doubts 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, 08 Jan 2013 11:07:25 -0000 RFC6639 s4.2.9 tells me that " The mplsOutSegmentPerfTable [RFC3813] contains statistical information (total packets received, total errored packets received, total packets discarded, discontinuity time) for outgoing MPLS segments from an LSR." whereas RFC3813 itself says "This table contains statistical information about outgoing segments from an LSR. " and goes on to refer to octets sent, packets sent, packets that could not be sent as well as packets discarded and discontinuity time. Um; RFC6639 looks wrong, but is it worth the administrative effort of an Erratum? I will raise one if you want me to. Tom Petch From ramk@Brocade.com Fri Jan 4 17:52:02 2013 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 42AAB21F8765 for ; Fri, 4 Jan 2013 17:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 xJorWttB4iQI for ; Fri, 4 Jan 2013 17:52:01 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id D12AF21F872C for ; Fri, 4 Jan 2013 17:52:01 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r051q1aL013346 for ; Fri, 4 Jan 2013 17:52:01 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 19p2w0g8am-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 04 Jan 2013 17:52:01 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 4 Jan 2013 17:52:00 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Fri, 4 Jan 2013 17:52:00 -0800 From: ramki Krishnan To: "mpls@ietf.org" Date: Fri, 4 Jan 2013 17:51:57 -0800 Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls- in-udp an mpls working group document Thread-Index: Ac3q5z7e42ggVsWrQdycylLB+zg+HQ== 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_C7634EB63EFD984A978DFB46EA5174F2BF4FC920BBHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1301040315 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-04_07:2013-01-04, 2013-01-04, 1970-01-01 signatures=0 X-Mailman-Approved-At: Tue, 08 Jan 2013 07:32:36 -0800 Subject: [mpls] poll to see if we have support to make draft-xu-mpls- in-udp an mpls 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: Sat, 05 Jan 2013 01:52:02 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FC920BBHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to support this. Thanks, Ram Brocade Communications --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FC920BBHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to support this.

 

Thanks,

Ram

Broc= ade Communications

= --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FC920BBHQ1EXCH01corp_-- From pthaler@broadcom.com Tue Dec 18 15:56: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 E4DD61F0CDF for ; Tue, 18 Dec 2012 15:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.727 X-Spam-Level: X-Spam-Status: No, score=-3.727 tagged_above=-999 required=5 tests=[AWL=-2.871, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_39=0.6, 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 XSlb9lgfm2ow for ; Tue, 18 Dec 2012 15:56:05 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 070C31F041A for ; Tue, 18 Dec 2012 15:56:05 -0800 (PST) Received: from [10.16.192.224] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 18 Dec 2012 15:51:07 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.17) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 18 Dec 2012 15:55:45 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 18 Dec 2012 15:55:45 -0800 From: "Pat Thaler" To: "mpls@ietf.org" Thread-Topic: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: Ac3deyKpJyfWUNRHQJy+hmEkKaWM6w== Message-ID: 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: 7CCFDEE139W14061800-01-01 Content-Type: multipart/alternative; boundary=_000_EB9B93801780FD4CA165E0FBCB3C3E671DF1D85ESJEXCHMB09corpa_ X-Mailman-Approved-At: Tue, 08 Jan 2013 07:32:55 -0800 Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls 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: , Date: Tue, 18 Dec 2012 23:56:06 -0000 X-Original-Date: Tue, 18 Dec 2012 23:55:44 +0000 X-List-Received-Date: Tue, 18 Dec 2012 23:56:06 -0000 --_000_EB9B93801780FD4CA165E0FBCB3C3E671DF1D85ESJEXCHMB09corpa_ Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 KzEgRG8gbm90IHN1cHBvcnQNCg0KDQoNClBhdA0KDQoNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0N Cg0KPiC3orz+yMs6IG1wbHMtYm91bmNlcyBhdCBpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNl cyBhdCBpZXRmLm9yZ10gtPqx7SBTLg0KDQo+IERhdmFyaQ0KDQo+ILeiy83KsbzkOiAyMDEyxOox MtTCMTXI1SAxMzozNA0KDQo+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KDQo+ILOty806IGRyYWZ0 LXh1LW1wbHMtaW4tdWRwIGF0IHRvb2xzLmlldGYub3JnOyBtcGxzIGF0IGlldGYub3JnOw0KDQo+ IG1wbHMtY2hhaXJzIGF0IHRvb2xzLmlldGYub3JnDQoNCj4g1vfM4jogUmU6IFttcGxzXSBwb2xs IHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS1tcGxzLWluLXVkcCBh bg0KDQo+IG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVudA0KDQo+DQoNCj4gSSBkb24ndCBzdXBw b3J0IHRoaXMgZHJhZnQgc2luY2UgaXQgaGFzIG5vIGFwcGxpY2F0aW9uIGluIHRvZGF5J3MgbW9k ZXJuIG1ldHJvDQoNCj4gYW5kIGNvcmUsIHdoZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMg b25seSBwcmFjdGljYWwgYXBwbGljYXRpb24gaW4gaW4gZGF0YQ0KDQo+IGNlbnRlciwgd2hpY2gg YWxyZWFkeSBpcyBjcm93ZGVkIHdpdGggb3RoZXIgc29sdXRpb25zIHN1Y2ggYXMgTlZHUkUgYW5k DQoNCj4gVlhMQU4uDQoNCj4NCg0KPiBJdCBzZWVtcyB0aGUgYXV0aG9ycyBhcmUgdHJ5aW5nIHRv IGJ5cGFzcyB0aGUgTlZPMyBzb2x1dGlvbiBzZWxlY3Rpb24gcHJvY2Vzcw0KDQo+IGJ5IGFkdmFu Y2luZyB0aGUgZHJhZnQgaW4gTVBMUyBXRy4NCg0KPg0KDQo+IFJlZ2FyZHMsDQoNCj4gU2hhaHJh bQ0KDQo+DQoNCj4NCg0KPiBPbiBEZWMgMTQsIDIwMTIsIGF0IDE6MDEgQU0sIExvYSBBbmRlcnNz b24gPGxvYSBhdCBwaS5udT4gd3JvdGU6DQoNCj4NCg0KPiA+IFdvcmtpbmcgZ3JvdXAsDQoNCj4g Pg0KDQo+ID4gVGhpcyBpcyB0byBzdGFydCBhICJ0d28gd2VlayIgcG9sbCBvbiBhZG9wdGluZw0K DQo+ID4gZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRv Y3VtZW50Lg0KDQo+ID4gRHVlIHRvIHRoZSBob2xpZGF5IHNlYXNvbiB0aGlzIHBvbGwgaGFzIGJl ZW4gZXh0ZW5kZWQgd2l0aCBvbmUgd2Vlay4NCg0KPiA+DQoNCj4gPiBQbGVhc2Ugc2VuZCB5b3Vy IGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nDQoNCj4g PiBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHMgYXQgaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBhbiB0 ZWNobmljYWwNCg0KPiA+IG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwg ZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdA0KDQo+ID4gdGhlIGRvY3VtZW50IHNob3VsZCBu b3QgYmUgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNCj4gPg0KDQo+ID4g VGhpcyBwb2xsIGVuZHMgSmFudWFyeSAwNywgMjAxMy4NCg0KPiA+DQoNCj4gPiBUaGVyZSBpcyBv bmUgSVBSIGNsYWltIGFnYWluc3QgdGhpcyBkb2N1bWVudCAtDQoNCj4gPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2lwci8xOTQxLyAuDQoNCj4gPg0KDQo+ID4gQWxsIHRoZSBhY3RpdmUg Y28tYXV0aG9ycyBoYXMgc3RhdGVkIG9uIHRoZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0K DQo+ID4gdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMgdGhh biB0aG9zZSBhbHJlYWR5DQoNCj4gPiBkaXNjbG9zZWQuDQoNCj4gPg0KDQo+ID4gSG93ZXZlciwg dXAgdG8gdmVyc2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQgZm9yIHRoZSBJUFIg cG9sbCkNCg0KPiA+IE1hcnNoYWxsIEV1YmFua3Mgd2FzIGxpc3RlZCBhcyBvbmUgb2YgdGhlIGF1 dGhvcnMuIE1hcnNoYWxsIGhhcw0KDQo+ID4gZGlzY29udGludWVkIGFsbCBpbnRlcmFjdGlvbnMg d2l0aCB0aGUgSUVURiwgaW5jbHVkaW5nIHRoZSBhdXRob3IgdGVhbQ0KDQo+ID4gb2YgZHJhZnQt eHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyBoYXMgdHJpZWQgdG8N Cg0KPiA+IGNvbnRhY3QgTWFyc2hhbGwgYnkgb3RoZXIgbWVhbnMsIHRvIHRyeSBnZXQgYSByZXNw b25zZSBvbiB0aGUgSVBSIHBvbGwuDQoNCj4gPiBXZSBoYXZlIGhhZCBubyBzdWNjZXNzIGluIHRo aXMuDQoNCj4gPg0KDQo+ID4gRnJvbSB2ZXJzaW9uIC0wNCB0aGUgYXV0aG9ycyBkZWNpZGVkIHRv IHJlbW92ZSBNYXJzaGFsbCBhcyBhIGNvLWF1dGhvci4NCg0KPiA+DQoNCj4gPiAvTG9hDQoNCj4g PiAobXBscyB3ZyBjby1jaGFpcikNCg0KPiA+IC0tDQoNCj4gPg0KDQo+ID4NCg0KPiA+IExvYSBB bmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6DQoNCj4gbG9hLmFuZGVyc3Nv biBhdCBlcmljc3Nvbi5jb20NCg0KPiA+IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdl ciAgICAgICAgICAgIGxvYSBhdCBwaS5udQ0KDQo+ID4gRXJpY3Nzb24gSW5jICAgICAgICAgICAg ICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KDQo+ID4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzY3IDcyIDkyIDEzDQoNCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+ID4gbXBs cyBtYWlsaW5nIGxpc3QNCg0KPiA+IG1wbHMgYXQgaWV0Zi5vcmcNCg0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gbXBscyBtYWlsaW5nIGxpc3QNCg0KPiBt cGxzIGF0IGlldGYub3JnDQoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQoNCg== --_000_EB9B93801780FD4CA165E0FBCB3C3E671DF1D85ESJEXCHMB09corpa_ Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable 
+1 Do not support
 
Pat
 
> -----=D3=CA=BC=FE=D4=AD=BC=FE=
-----
> =B7=A2=BC=FE=C8=CB: mpl=
s-bounces at ietf.org [mailto:mpls-bounces<=
/a> at ietf.org] =B4=FA=B1=ED S.<=
o:p>
> Davari
> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34
> =CA=D5=BC=FE=C8=CB: Loa=
 Andersson
> =B3=AD=CB=CD: draft-xu-=
mpls-in-udp at tools.ietf.org; mpls at ietf.org;
> mpls-chairs at tools.ietf.org
> =D6=F7=CC=E2: Re: [mpls=
] poll to see if we have support to make draft-xu-mpls-in-udp an=

> mpls working group document
> 
> I don't support this draft since it has no application in today's=
 modern metro
> and core, where MPLS is dominant, and its only practical applicat=
ion in in data
> center, which already is crowded with other solutions such as NVG=
RE and
> VXLAN.
> 
> It seems the authors are trying to bypass the NVO3 solution selec=
tion process
> by advancing the draft in MPLS WG.
> 
> Regards,
> Shahram
> 
> 
> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa at pi.nu> w=
rote:
> 
> > Working group,
> >
> > This is to start a "two week" poll on adopting
> > draft-xu-mpls-in-udp-06 as an MPLS working group document.
> > Due to the holiday season this poll has been extended with o=
ne week.
> >
> > Please send your comments (support/not support) to the mpls =
working
> > group mailing list (mpls at ietf.org). Please give an techni=
cal
> > motivation for your support/not support, especially if you t=
hink that
> > the document should not be adopted as a working group docume=
nt.
> >
> > This poll ends January 07, 2013.
> >
> > There is one IPR claim against this document -

> > https://d=
atatracker.ietf.org/ipr/1941/ .


> >


> > All the active co-authors has stated on the working group ma=
iling list


> > that they are not aware of any other IPR claims than those a=
lready


> > disclosed.


> >


> > However, up to version -03 (the document that we used for th=
e IPR poll)


> > Marshall Eubanks was listed as one of the authors. Marshall =
has


> > discontinued all interactions with the IETF, including the a=
uthor team


> > of draft-xu-mpls-in-udp-06. The working group chairs has tri=
ed to


> > contact Marshall by other means, to try get a response on th=
e IPR poll.


> > We have had no success in this.


> >


> > From version -04 the authors decided to remove Marshall as a=
 co-author.


> >


> > /Loa


> > (mpls wg co-chair)


> > --


> >


> >


> > Loa Andersson        =
;            &n=
bsp;    email:


> loa.andersson at ericsson.com


> > Sr Strategy and Standards Manager    &nb=
sp;       loa at pi.nu


> > Ericsson Inc        =
             &n=
bsp;    phone: +46 10 717 52 13


> >          &=
nbsp;           &nbs=
p;            &=
nbsp;         +46 767 72 92 13<=
o:p>


> > _______________________________________________

> > mpls mailing list


> > mpls at ietf.org


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


> _______________________________________________


> mpls mailing list


> mpls at ietf.org


> https://ww=
w.ietf.org/mailman/listinfo/mpls


 
--_000_EB9B93801780FD4CA165E0FBCB3C3E671DF1D85ESJEXCHMB09corpa_-- From pthaler@broadcom.com Fri Dec 21 10:07: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 CFE1121F85CC for ; Fri, 21 Dec 2012 10:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 tagged_above=-999 required=5 tests=[AWL=-2.153, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_39=0.6, 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 xivFIlzAjmhr for ; Fri, 21 Dec 2012 10:07:09 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6D72021F8D33 for ; Fri, 21 Dec 2012 10:07:02 -0800 (PST) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 21 Dec 2012 10:04:43 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.13) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 21 Dec 2012 10:06:38 -0800 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; Fri, 21 Dec 2012 10:06:25 -0800 From: "Pat Thaler" To: "mpls@ietf.org" Thread-Topic: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: Ac3deyKpJyfWUNRHQJy+hmEkKaWM6wCKrwOw Message-ID: 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: 7CCA7B311ZK2500722-02-01 Content-Type: multipart/alternative; boundary=_000_EB9B93801780FD4CA165E0FBCB3C3E671DF20252SJEXCHMB09corpa_ X-Mailman-Approved-At: Tue, 08 Jan 2013 07:32:55 -0800 Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls 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: , Date: Fri, 21 Dec 2012 18:07:12 -0000 X-Original-Date: Fri, 21 Dec 2012 18:06:24 +0000 X-List-Received-Date: Fri, 21 Dec 2012 18:07:12 -0000 --_000_EB9B93801780FD4CA165E0FBCB3C3E671DF20252SJEXCHMB09corpa_ Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 KzEgRG8gbm90IHN1cHBvcnQNCg0KDQoNClBhdA0KDQoNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0N Cg0KPiC3orz+yMs6IG1wbHMtYm91bmNlcyBhdCBpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNl cyBhdCBpZXRmLm9yZ10gtPqx7SBTLg0KDQo+IERhdmFyaQ0KDQo+ILeiy83KsbzkOiAyMDEyxOox MtTCMTXI1SAxMzozNA0KDQo+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KDQo+ILOty806IGRyYWZ0 LXh1LW1wbHMtaW4tdWRwIGF0IHRvb2xzLmlldGYub3JnOyBtcGxzIGF0IGlldGYub3JnOw0KDQo+ IG1wbHMtY2hhaXJzIGF0IHRvb2xzLmlldGYub3JnDQoNCj4g1vfM4jogUmU6IFttcGxzXSBwb2xs IHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS1tcGxzLWluLXVkcCBh bg0KDQo+IG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVudA0KDQo+DQoNCj4gSSBkb24ndCBzdXBw b3J0IHRoaXMgZHJhZnQgc2luY2UgaXQgaGFzIG5vIGFwcGxpY2F0aW9uIGluIHRvZGF5J3MgbW9k ZXJuIG1ldHJvDQoNCj4gYW5kIGNvcmUsIHdoZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMg b25seSBwcmFjdGljYWwgYXBwbGljYXRpb24gaW4gaW4gZGF0YQ0KDQo+IGNlbnRlciwgd2hpY2gg YWxyZWFkeSBpcyBjcm93ZGVkIHdpdGggb3RoZXIgc29sdXRpb25zIHN1Y2ggYXMgTlZHUkUgYW5k DQoNCj4gVlhMQU4uDQoNCj4NCg0KPiBJdCBzZWVtcyB0aGUgYXV0aG9ycyBhcmUgdHJ5aW5nIHRv IGJ5cGFzcyB0aGUgTlZPMyBzb2x1dGlvbiBzZWxlY3Rpb24gcHJvY2Vzcw0KDQo+IGJ5IGFkdmFu Y2luZyB0aGUgZHJhZnQgaW4gTVBMUyBXRy4NCg0KPg0KDQo+IFJlZ2FyZHMsDQoNCj4gU2hhaHJh bQ0KDQo+DQoNCj4NCg0KPiBPbiBEZWMgMTQsIDIwMTIsIGF0IDE6MDEgQU0sIExvYSBBbmRlcnNz b24gPGxvYSBhdCBwaS5udT4gd3JvdGU6DQoNCj4NCg0KPiA+IFdvcmtpbmcgZ3JvdXAsDQoNCj4g Pg0KDQo+ID4gVGhpcyBpcyB0byBzdGFydCBhICJ0d28gd2VlayIgcG9sbCBvbiBhZG9wdGluZw0K DQo+ID4gZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRv Y3VtZW50Lg0KDQo+ID4gRHVlIHRvIHRoZSBob2xpZGF5IHNlYXNvbiB0aGlzIHBvbGwgaGFzIGJl ZW4gZXh0ZW5kZWQgd2l0aCBvbmUgd2Vlay4NCg0KPiA+DQoNCj4gPiBQbGVhc2Ugc2VuZCB5b3Vy IGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nDQoNCj4g PiBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHMgYXQgaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBhbiB0 ZWNobmljYWwNCg0KPiA+IG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwg ZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdA0KDQo+ID4gdGhlIGRvY3VtZW50IHNob3VsZCBu b3QgYmUgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNCj4gPg0KDQo+ID4g VGhpcyBwb2xsIGVuZHMgSmFudWFyeSAwNywgMjAxMy4NCg0KPiA+DQoNCj4gPiBUaGVyZSBpcyBv bmUgSVBSIGNsYWltIGFnYWluc3QgdGhpcyBkb2N1bWVudCAtDQoNCj4gPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2lwci8xOTQxLyAuDQoNCj4gPg0KDQo+ID4gQWxsIHRoZSBhY3RpdmUg Y28tYXV0aG9ycyBoYXMgc3RhdGVkIG9uIHRoZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0K DQo+ID4gdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMgdGhh biB0aG9zZSBhbHJlYWR5DQoNCj4gPiBkaXNjbG9zZWQuDQoNCj4gPg0KDQo+ID4gSG93ZXZlciwg dXAgdG8gdmVyc2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQgZm9yIHRoZSBJUFIg cG9sbCkNCg0KPiA+IE1hcnNoYWxsIEV1YmFua3Mgd2FzIGxpc3RlZCBhcyBvbmUgb2YgdGhlIGF1 dGhvcnMuIE1hcnNoYWxsIGhhcw0KDQo+ID4gZGlzY29udGludWVkIGFsbCBpbnRlcmFjdGlvbnMg d2l0aCB0aGUgSUVURiwgaW5jbHVkaW5nIHRoZSBhdXRob3IgdGVhbQ0KDQo+ID4gb2YgZHJhZnQt eHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyBoYXMgdHJpZWQgdG8N Cg0KPiA+IGNvbnRhY3QgTWFyc2hhbGwgYnkgb3RoZXIgbWVhbnMsIHRvIHRyeSBnZXQgYSByZXNw b25zZSBvbiB0aGUgSVBSIHBvbGwuDQoNCj4gPiBXZSBoYXZlIGhhZCBubyBzdWNjZXNzIGluIHRo aXMuDQoNCj4gPg0KDQo+ID4gRnJvbSB2ZXJzaW9uIC0wNCB0aGUgYXV0aG9ycyBkZWNpZGVkIHRv IHJlbW92ZSBNYXJzaGFsbCBhcyBhIGNvLWF1dGhvci4NCg0KPiA+DQoNCj4gPiAvTG9hDQoNCj4g PiAobXBscyB3ZyBjby1jaGFpcikNCg0KPiA+IC0tDQoNCj4gPg0KDQo+ID4NCg0KPiA+IExvYSBB bmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6DQoNCj4gbG9hLmFuZGVyc3Nv biBhdCBlcmljc3Nvbi5jb20NCg0KPiA+IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdl ciAgICAgICAgICAgIGxvYSBhdCBwaS5udQ0KDQo+ID4gRXJpY3Nzb24gSW5jICAgICAgICAgICAg ICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KDQo+ID4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzY3IDcyIDkyIDEzDQoNCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+ID4gbXBs cyBtYWlsaW5nIGxpc3QNCg0KPiA+IG1wbHMgYXQgaWV0Zi5vcmcNCg0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gbXBscyBtYWlsaW5nIGxpc3QNCg0KPiBt cGxzIGF0IGlldGYub3JnDQoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQoNCg== --_000_EB9B93801780FD4CA165E0FBCB3C3E671DF20252SJEXCHMB09corpa_ Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable 
+1 Do not support
 
Pat
 
> -----=D3=CA=BC=
=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=
=CB: mpls-bounces at ietf.org [mailt=
o:mpls-bounces at ietf.org] =B4=FA=B1=ED S.
> Davari
> =B7=A2=CB=CD=CA=
=B1=BC=E4: 2012=C4=
=EA12=D4=C2=
15=C8=D5 13:34
> =CA=D5=BC=FE=C8=
=CB: Loa Andersson
> =B3=AD=CB=CD: draft-xu-mpls-in-udp at tools.ietf.org; mpls at ietf.org;<=
/pre>

> mpls-chairs at tools.ietf.org


> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-ud=
p an


> mpls working group document


> 


> I don't support this draft since it has no application in today's=
 modern metro


> and core, where MPLS is dominant, and its only practical applicat=
ion in in data


> center, which already is crowded with other solutions such as NVG=
RE and


> VXLAN.


> 


> It seems the authors are trying to bypass the NVO3 solution selec=
tion process


> by advancing the draft in MPLS WG.


> 


> Regards,


> Shahram


> 


> 


> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa at pi.nu> w=
rote:


> 


> > Working group,


> >


> > This is to start a "two week" poll on adopting


> > draft-xu-mpls-in-udp-06 as an MPLS working group document.


> > Due to the holiday season this poll has been extended with o=
ne week.


> >


> > Please send your comments (support/not support) to the mpls =
working


> > group mailing list (mpls at ietf.org). Please give an techni=
cal


> > motivation for your support/not support, especially if you t=
hink that


> > the document should not be adopted as a working group docume=
nt.


> >


> > This poll ends January 07, 2013.


> >


> > There is one IPR claim against this document -

> > https://d=
atatracker.ietf.org/ipr/1941/ .


> >


> > All the active co-authors has stated on the working group ma=
iling list


> > that they are not aware of any other IPR claims than those a=
lready


> > disclosed.


> >


> > However, up to version -03 (the document that we used for th=
e IPR poll)


> > Marshall Eubanks was listed as one of the authors. Marshall =
has


> > discontinued all interactions with the IETF, including the a=
uthor team


> > of draft-xu-mpls-in-udp-06. The working group chairs has tri=
ed to


> > contact Marshall by other means, to try get a response on th=
e IPR poll.


> > We have had no success in this.


> >


> > From version -04 the authors decided to remove Marshall as a=
 co-author.


> >


> > /Loa


> > (mpls wg co-chair)


> > --


> >


> >


> > Loa Andersson        =
;            &n=
bsp;    email:


> loa.andersson at ericsson.com


> > Sr Strategy and Standards Manager    &nb=
sp;       loa at pi.nu


> > Ericsson Inc        =
             &n=
bsp;    phone: +46 10 717 52 13


> >          &=
nbsp;           &nbs=
p;            &=
nbsp;         +46 767 72 92 13<=
o:p>


> > _______________________________________________

> > mpls mailing list


> > mpls at ietf.org


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


> _______________________________________________


> mpls mailing list


> mpls at ietf.org


> https://ww=
w.ietf.org/mailman/listinfo/mpls


 
--_000_EB9B93801780FD4CA165E0FBCB3C3E671DF20252SJEXCHMB09corpa_-- From lufang@cisco.com Tue Jan 8 07:50:30 2013 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 0BD8821F8B67 for ; Tue, 8 Jan 2013 07:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 Y8OGrSyGyCLF for ; Tue, 8 Jan 2013 07:50:29 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9527D21F8B69 for ; Tue, 8 Jan 2013 07:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3405; q=dns/txt; s=iport; t=1357660227; x=1358869827; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=r8lsp9dwePeZKx0iGipcepaWaYANCrUrV7mCnOVxsf0=; b=fdi7VV5C+1U7+t/1bbqiTQIWYFjms3IGV4rEstWffIGzOagjbrLNdB/z es3qjStjBWaau9TtolTR43Ffs5oEte20xy2UjJWJrPcwY2Eh8KdgvfhF5 xNvTLudQX0TFrhvOVSZ7xTPeCZxbuwXUstGMchN5Oz9e+xJEj1MVO591c c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFANQ+7FCtJXHB/2dsb2JhbABEg2y5bRZzgh4BAQEEAQEBNzQLDAIEAQgRAwEBAQsUCSIMCxQJCAIEAQ0FCAGIDgcFqTaNHASMWYNXYQOmVYJ0gXE1 X-IronPort-AV: E=Sophos;i="4.84,432,1355097600"; d="scan'208";a="160087681" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 08 Jan 2013 15:50:27 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r08FoQI6005480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jan 2013 15:50:27 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 09:50:26 -0600 From: "Luyuan Fang (lufang)" To: Mach Chen , Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AQHN7MDVTh7zjGol0UmgmGzQlFGPM5g/XgGAgABI/gA= Date: Tue, 8 Jan 2013 15:50:26 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931025B693@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.70.122] Content-Type: text/plain; charset="us-ascii" Content-ID: <43A070A96DE79949A4EC14C6073F4311@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 08 Jan 2013 15:50:30 -0000 Hi Mach, Thank you for your review and comments. We accept your comments on the terminologies section, will re-spin the draft when the wg last call has ended. One way to handle this is to remove the current terminology section as you suggested, and point to RFC5654/5921 for MPLS-TP terms, RFC5920 for security terms which are relevant to MPLS/GMPLS. Thanks, Luyuan -----Original Message----- From: Mach Chen Date: Monday, January 7, 2013 10:29 PM To: Loa Andersson , "mpls@ietf.org" Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: RE: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework Resent-From: Resent-To: , Luyuan Fang , , , , , Resent-Date: Monday, January 7, 2013 10:29 PM >Hi, > >I have read the latest version of the draft, I am OK with the content and >support to move it forward. > >One comment about the Terminology section, it lists only partial >terminologies used in the document and some of the terminologies(e.g., >MEP, MIP) are actually not used in the draft. It's better that the >authors could review the draft and then add all(or most of ) the major >terminologies and remove the useless terminologies. Or the simplest way >is just to remove the whole Terminologies Section :-). > >Best regards, >Mach > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>Loa >> Andersson >> Sent: Monday, January 07, 2013 6:22 PM >> To: mpls@ietf.org >> Cc: draft-ietf-mpls-tp-security-framework@tools.ietf.org; >> mpls-chairs@tools.ietf.org >> Subject: [mpls] 2nd wg last call on >>draft-ietf-mpls-tp-security-framework >>=20 >> Working Group, >>=20 >> This is to start a working group last call on >> draft-ietf-mpls-tp-security-framework-06. >>=20 >> This is the second time this document is working group last called, >> three has been a major update of the document since last time. >>=20 >> Please find a diff: >>=20 >>http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-tp-security-framework-= 05 >>&diff >> type=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-security-framewor= k-06 >>=20 >> Please send your comments to the mpls working group mailing >> list (mpls@ietf.org). >>=20 >> Please send both technical comments, and if you are happy with the >> document as is also indications of support. >>=20 >> There are no IPR claims against this draft. >>=20 >> All the co-authors has stated that they are not ware of any IPRs. >>=20 >> This working group last call will end on January 18, 2013. >>=20 >> /Loa >> for the wg co-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 From agmalis@gmail.com Tue Jan 8 12:44:40 2013 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 1F4CE1F0C6A for ; Tue, 8 Jan 2013 12:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 riw2GZHgX+zi for ; Tue, 8 Jan 2013 12:44:39 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 497081F0C3E for ; Tue, 8 Jan 2013 12:44:39 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so1074628qca.31 for ; Tue, 08 Jan 2013 12:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A5HeGhCt/rl3NUZAvrXwiBO6KC7g+DsrxzRuLgAKY+g=; b=A6HFAQLRtc/bLyUYoyjsvXV7O1+4Q+TpTy9saZZGCQ/CiTp9eEWb5//cgX1s0IbfhW Wi1wp3zzwpe7O5HbI+wcRa9NemMbOYp4zjQ7NQja8VDZyhM1zH9MWWUzOOt4maoXS5TG cr5Yc/tNWeLr/eJFZNWSoZ+W8p+kjse+jx/adMUHe8cHDrieISPjknNAIGiOjsGQ/rxm yxsmfTma7QMqq/LcgPK2FrVJMmEhDNddL1Su9/ZLQ/v/a5ZYdxkT2Qz2svskYWrpeWRC u1GsLWmY05t+175N8HgizQoBKYhEzaczx+Ro9UdB3WXsubzml6Sz+zzjg1C2qlxFQ6ci UFAw== Received: by 10.224.179.205 with SMTP id br13mr47743524qab.37.1357677878735; Tue, 08 Jan 2013 12:44:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.78.72 with HTTP; Tue, 8 Jan 2013 12:44:18 -0800 (PST) In-Reply-To: <50E5E64A.8090105@pi.nu> References: <50E5E64A.8090105@pi.nu> From: "Andrew G. Malis" Date: Tue, 8 Jan 2013 15:44:18 -0500 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=485b397dcd5bae745604d2cd03fd Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg 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, 08 Jan 2013 20:44:40 -0000 --485b397dcd5bae745604d2cd03fd Content-Type: text/plain; charset=ISO-8859-1 Loa, I support adoption of this draft. Cheers, Andy On Thu, Jan 3, 2013 at 3:12 PM, Loa Andersson wrote: > Working group, > > This is to start a two week poll on adopting > draft-fbb-mpls-tp-p2mp-**framework-06 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 January 17, 2013. > > There are no IPR claim against this document. > > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. > > /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 > --485b397dcd5bae745604d2cd03fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Loa,

I support adoption of this draft.
Cheers,
Andy


On Thu, Jan 3, 2013 at 3:12 PM, Loa Andersson <loa@pi.nu&g= t; wrote:
Working group,

This is to start a two week poll on adopting
draft-fbb-mpls-tp-p2mp-framework-06 as an MPLS working group documen= t.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls at i= etf.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 January 17, 2013.

There are no IPR claim against this document.

All the active co-authors has stated on the working group mailing list
that they are not aware of any other IPR claims than those already
disclosed.

/Loa
(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
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--485b397dcd5bae745604d2cd03fd-- From agmalis@gmail.com Tue Jan 8 12:58:09 2013 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 21EBF1F0CFB for ; Tue, 8 Jan 2013 12:58:09 -0800 (PST) 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.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XQEHiPqnjk+U for ; Tue, 8 Jan 2013 12:58:08 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 615791F0CF9 for ; Tue, 8 Jan 2013 12:58:08 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id o19so118164qap.14 for ; Tue, 08 Jan 2013 12:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4Fi/vc3RQmF14Ousdef+zq7MKVcHW2g9x5l1MDde9Eo=; b=kfJeefZdCdmlSgGyxeMowzh7JAvLMbWzbcjjfUMj3wRvG946/MYugOFGfBVEFkwxpS V62tc9OXu1WFpI38UejKblv7kF6GvVbG43m5fbBglVLkhhmh0rLrwfBtQVDlg4BJKRfI r1Zi+wo7yMTsUuQMbQ6vwRLnVEZFBA/2OP0Owdd7YOd+Kk14nQ4zRX3hakY4IKt5OPTv /kyYw+JCLmYmLzlU/StgEFsoJlxQZ7CNh/Sd+tyrh8ffzLQz6ac058ZjBgeV6MDq+6M0 ptY+Qmz1KSv9cQB/npFuT4/BF2gTCyE/92XVRiZ+/TywTrJ3I4nPe/FGMMerzCHnGBeY XRYQ== Received: by 10.224.72.197 with SMTP id n5mr48834101qaj.38.1357678687861; Tue, 08 Jan 2013 12:58:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.78.72 with HTTP; Tue, 8 Jan 2013 12:57:47 -0800 (PST) In-Reply-To: <50EAA1C5.20009@pi.nu> References: <50EAA1C5.20009@pi.nu> From: "Andrew G. Malis" Date: Tue, 8 Jan 2013 15:57:47 -0500 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf3071d1dae8bdf104d2cd33a2 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-security-framework@tools.ietf.org Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 08 Jan 2013 20:58:09 -0000 --20cf3071d1dae8bdf104d2cd33a2 Content-Type: text/plain; charset=ISO-8859-1 It looks ready to publish to me, and the new acknowledgements section should help it sail through the process! :-) Cheers, Andy On Mon, Jan 7, 2013 at 5:21 AM, Loa Andersson wrote: > Working Group, > > This is to start a working group last call on > draft-ietf-mpls-tp-security-**framework-06. > > This is the second time this document is working group last called, > three has been a major update of the document since last time. > > Please find a diff: > http://www.ietf.org/rfcdiff?**url1=draft-ietf-mpls-tp-** > security-framework-05&**difftype=--html&submit=Go%21&** > url2=draft-ietf-mpls-tp-**security-framework-06 > > 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. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not ware of any IPRs. > > This working group last call will end on January 18, 2013. > > /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 > --20cf3071d1dae8bdf104d2cd33a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It looks ready to publish to me, and the new acknowle= dgements section should help it sail through the process! :-)

= Cheers,
Andy


On Mon, Jan 7, 2013 at 5:21 AM, Loa Andersson <loa@pi.nu> wrote:
=
Working Group,

This is to start a working group last call on
draft-ietf-mpls-tp-security-framework-06.

This is the second time this document is working group last called,
three has been a major update of the document since last time.

Please find a diff:
http://www.ietf.org/rfcdif= f?url1=3Ddraft-ietf-mpls-tp-security-framework-05&= difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-<= u>security-framework-06

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.

There are no IPR claims against this draft.

All the co-authors has stated that they are not ware of any IPRs.

This working group last call will end on January 18, 2013.

/Loa
for the wg co-chairs

--


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
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--20cf3071d1dae8bdf104d2cd33a2-- From martin.vigoureux@alcatel-lucent.com Wed Jan 9 06:18:59 2013 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 DF7EF21F87DC for ; Wed, 9 Jan 2013 06:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[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 juhLlXu2Vm-F for ; Wed, 9 Jan 2013 06:18:58 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id D838021F86D9 for ; Wed, 9 Jan 2013 06:18:57 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r09EILR0030424 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Jan 2013 15:18:51 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 9 Jan 2013 15:18:31 +0100 Received: from [172.27.205.205] (135.239.27.11) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 9 Jan 2013 15:18:30 +0100 Message-ID: <50ED7C34.3080707@alcatel-lucent.com> Date: Wed, 9 Jan 2013 15:18:28 +0100 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: "adrian@olddog.co.uk" , "daviball@cisco.com" References: <20121212174431.2DCABB1E002@rfc-editor.org> <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> In-Reply-To: <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.11] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "sboutros@cisco.com" , "msiva@cisco.com" , "rcallon@juniper.net" , "raggarwa_1@yahoo.com" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 09 Jan 2013 14:18:59 -0000 Adrian, David, what I think we meant here was that a loop-back function could be done on an interface regardless of the presence of a MIP/MEP on that interface. Yet, I have to admit that MIP and MEP are used in Section 4 of RFC6435, thus surely causing confusion. I'd welcome the views/souvenirs of my co-authors. -m Le 12/12/2012 19:17, Adrian Farrel a 閏rit : > Hello, > > Authors of RFC 6435: I need to hear from you that you meant the text that David > suggests. It is very clearly not what you wrote and, if you meant something > different, it is clear why people are confused! > > Working group: I need to hear from you that you agree with David's > interpretation and support his proposed change. > > Only then will I try to work out whether this is a "typo" worthy of an errata > report, or a technical change needing a revised RFC. > > Thanks, > Adrian > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: 12 December 2012 17:45 >> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; >> rcallon@juniper.net >> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Editorial Errata Reported] RFC6435 (3429) >> >> >> The following errata report has been submitted for RFC6435, >> "MPLS Transport Profile Lock Instruct and Loopback Functions". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 >> >> -------------------------------------- >> Type: Editorial >> Reported by: David Ball >> >> Section: 4 (para 5) >> >> Original Text >> ------------- >> It should be noted that the data-plane loopback function itself is applied to > data- >> plane loopback points residing on different interfaces from MIPs/MEPs. >> >> Corrected Text >> -------------- >> It should be noted that the data-plane loopback function may be applied at >> MIPs/MEPs on different interfaces for different LSPs. >> >> Notes >> ----- >> The existing text has caused confusion (specifically, among experts in ITU-T > SG15 >> when discussing G.8121.2), in that it seems to suggest that the interface > where >> the MIP/MEP is located may be a different interface to the one where the >> loopback is applied. >> >> Having spoken with some of the original authors, it seems this was not the > intent >> of this sentence; the intent was to point out that as different LSPs would > have >> MIPs/MEPs on different interfaces, the corresponding loopback functions would >> also be applied on different interfaces. >> >> 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. >> >> -------------------------------------- >> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >> -------------------------------------- >> Title : MPLS Transport Profile Lock Instruct and Loopback > Functions >> Publication Date : November 2011 >> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. > Vigoureux, >> Ed., X. Dai, Ed. >> Category : PROPOSED STANDARD >> Source : Multiprotocol Label Switching >> Area : Routing >> Stream : IETF >> Verifying Party : IESG > > From internet-drafts@ietf.org Wed Jan 9 06:21:01 2013 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 4C12321F87E3; Wed, 9 Jan 2013 06:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 6vD8IrhVIDAn; Wed, 9 Jan 2013 06:21:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9EC21F87DC; Wed, 9 Jan 2013 06:21:00 -0800 (PST) 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.37 Message-ID: <20130109142100.10838.86289.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2013 06:21:00 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-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: Wed, 09 Jan 2013 14:21:01 -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-07.txt Pages : 12 Date : 2013-01-09 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 Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-itu-t-identifiers-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Rolf.Winter@neclab.eu Wed Jan 9 06:23:12 2013 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 B417B21F85B8 for ; Wed, 9 Jan 2013 06:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 wyUBea+dvGJL for ; Wed, 9 Jan 2013 06:23:04 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D7A6521F8599 for ; Wed, 9 Jan 2013 06:23:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 499CF102CA6 for ; Wed, 9 Jan 2013 15:23:03 +0100 (CET) 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 s-oNA-GoQXI5 for ; Wed, 9 Jan 2013 15:23:03 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 31B2E102CA4 for ; Wed, 9 Jan 2013 15:22:58 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.175]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 9 Jan 2013 15:22:58 +0100 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-07.txt Thread-Index: AQHN7nSms9bU9OoN10OsZ1ONaJidsphBDGVw Date: Wed, 9 Jan 2013 14:22:21 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D5559163C@DAPHNIS.office.hd> References: <20130109142100.10838.86289.idtracker@ietfa.amsl.com> In-Reply-To: <20130109142100.10838.86289.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.197] 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-itu-t-identifiers-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: Wed, 09 Jan 2013 14:23:13 -0000 WG, This new version should address all comments received during IETF last call= . 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: Mittwoch, 9. Januar 2013 15:21 > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-07.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 : 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-07.txt > Pages : 12 > Date : 2013-01-09 >=20 > 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 Operations, Administration, and Maintenance (OAM) > functions to include identifier information in a format typically > used by the International Telecommunication Union Telecommunication > Standardization Sector (ITU-T). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-itu-t-identifiers >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-tp-itu-t-identifiers-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-itu-t-identifiers- > 07 >=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 N.Leymann@telekom.de Wed Jan 9 06:41:01 2013 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 4B6AA21F85F7 for ; Wed, 9 Jan 2013 06:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Pgf+55Uop7Sy for ; Wed, 9 Jan 2013 06:40:58 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id E096A21F8488 for ; Wed, 9 Jan 2013 06:40:57 -0800 (PST) Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 09 Jan 2013 15:40:48 +0100 Received: from HE113558.emea1.cds.t-internal.com (10.125.65.100) by HE113415.emea1.cds.t-internal.com (10.125.65.81) with Microsoft SMTP Server (TLS) id 8.3.279.5; Wed, 9 Jan 2013 15:40:47 +0100 Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE113558.emea1.cds.t-internal.com ([2002:7cd:4164::7cd:4164]) with mapi; Wed, 9 Jan 2013 15:40:47 +0100 From: To: , Date: Wed, 9 Jan 2013 15:40:46 +0100 Thread-Topic: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod Thread-Index: Ac3dwoCU1/+W3Vi4QaWhGcg8Jjz7ygQtMjWg Message-ID: <9762ACF04FA26B4388476841256BDE020119E21EA8D2@HE111543.emea1.cds.t-internal.com> References: <50D17A08.8050109@pi.nu> In-Reply-To: <50D17A08.8050109@pi.nu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-ldp-dod@tools.ietf.org Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod 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, 09 Jan 2013 14:41:01 -0000 Support. Nic -----Urspr=FCngliche Nachricht----- Von: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Im Auftrag von Lo= a Andersson Gesendet: Mittwoch, 19. Dezember 2012 09:26 An: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; Betreff: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod Working Group, This is to start a working group last call on draft-ietf-mpls-ldp-dod-03. This working last call is extended due to the upcoming holidays. 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. There are no IPR claims against this draft. All the co-authors has stated that they are not ware of any IPRs. This working group last call will end on January 15, 2013. /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 agmalis@gmail.com Wed Jan 9 07:05:33 2013 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 CBD6C21F8809 for ; Wed, 9 Jan 2013 07:05:33 -0800 (PST) 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.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fT+6ShwQBkqc for ; Wed, 9 Jan 2013 07:05:33 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 366FC21F8689 for ; Wed, 9 Jan 2013 07:05:33 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id j15so729349qaq.6 for ; Wed, 09 Jan 2013 07:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QW+SvDDBTSUL2rrLi76G61uYjh48wmphM0bIRHCjoIs=; b=HIp3a50osUFqAGy0eMeesb3mz3g6StRkUQbJjr2hYbMb04HTcKNbzBRV48eJM4xL51 yKrXDaCjInT0j9mRFINHbvUBdZiOgs2HJCF6e8xEkAuVb/1F1NKNc/WF8R1za4U+piw3 fuYlcxVskiGLVVWB5wdJR7zdAezysNdGXB9ZPkg9DwFGTa/A2taJWaOLlLjH2A4n6TFD P3ancydnansh8NIbEoKxRN2qvzm/KL6eP/87Tb/VCLMqbb66Z46SiLm9hweEy32Di+fq 9s2FTbXeF8XVaeXmZuzMLj3oOpJctbzTOfWhf3Oz+ZbJ5omCD/zYc35CLAB7ZLv34KIE s6gg== Received: by 10.224.179.205 with SMTP id br13mr51787753qab.37.1357743932560; Wed, 09 Jan 2013 07:05:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.78.72 with HTTP; Wed, 9 Jan 2013 07:05:12 -0800 (PST) In-Reply-To: <50D17A08.8050109@pi.nu> References: <50D17A08.8050109@pi.nu> From: "Andrew G. Malis" Date: Wed, 9 Jan 2013 10:05:12 -0500 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=485b397dcd5bcbd51704d2dc648a Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "" Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod 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, 09 Jan 2013 15:05:33 -0000 --485b397dcd5bcbd51704d2dc648a Content-Type: text/plain; charset=ISO-8859-1 Loa, The draft looks ready for IESG submission. Cheers, Andy On Wed, Dec 19, 2012 at 3:25 AM, Loa Andersson wrote: > > Working Group, > > This is to start a working group last call on > draft-ietf-mpls-ldp-dod-03. This working last call is extended > due to the upcoming holidays. > > 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. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not ware of any IPRs. > > This working group last call will end on January 15, 2013. > > /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 > --485b397dcd5bcbd51704d2dc648a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Loa,

The draft looks ready for IESG subm= ission.

Cheers,
Andy


=
On Wed, Dec 19, 2012 at 3:25 AM, Loa Andersson <= span dir=3D"ltr"><loa@pi.= nu> wrote:

Working Group,

This is to start a working group last call on
draft-ietf-mpls-ldp-dod-03. This working last call is extended
due to the upcoming holidays.

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.

There are no IPR claims against this draft.

All the co-authors has stated that they are not ware of any IPRs.

This working group last call will end on January 15, 2013.

/Loa
for the wg co-chairs

--


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
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--485b397dcd5bcbd51704d2dc648a-- From sboutros@cisco.com Wed Jan 9 09:59:05 2013 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 7AD0D21F8751 for ; Wed, 9 Jan 2013 09:59:05 -0800 (PST) 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 H3RT8oH11oUo for ; Wed, 9 Jan 2013 09:59:04 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 41AE121F87AC for ; Wed, 9 Jan 2013 09:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4090; q=dns/txt; s=iport; t=1357754344; x=1358963944; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3Y4LUVD2kJ5R2xBUDaKcgGO8L6J5GPorTqCTLTBmC+U=; b=HxT0wjd/EVeQCUtflP2sHOd68HwBfVm3H50XQE0s3M1sk5RCoXAVN21z tFxgE60tDhHuvim5CvXeDdg7PDmwQLGCpi/MUGREjK04QoCs7SxhUfJuy ixq4V7l+7KZ5TGhPHNfr3qEr1FlYux3GhV8+k2drp/7Wm7Ep+VHGzKDv6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFSu7VCtJV2Z/2dsb2JhbAAqGqp9kl0Wc4IeAQEBAwFrDgUHBAIBCBEEAQELHQcyEwEJCAIEDgUIh38DCQYMLLV9i21qg2JhA4gtjA2NCYUSgnR2gS4 X-IronPort-AV: E=Sophos;i="4.84,439,1355097600"; d="scan'208";a="160596773" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 09 Jan 2013 17:59:03 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r09Hx3HI001666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jan 2013 17:59:03 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.232]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 11:59:02 -0600 From: "Sami Boutros (sboutros)" To: Martin Vigoureux Thread-Topic: [Editorial Errata Reported] RFC6435 (3429) Thread-Index: AQHN2JGbr8z20Ev6BkqoT9E++A0mPJgV3TmAgCu+nACAAD2fgA== Date: Wed, 9 Jan 2013 17:59:02 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F113337D8C@xmb-rcd-x08.cisco.com> References: <20121212174431.2DCABB1E002@rfc-editor.org> <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> <50ED7C34.3080707@alcatel-lucent.com> In-Reply-To: <50ED7C34.3080707@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.210.57] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <75ED23833E0306479B8D660C290519BB@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "Siva Sivabalan \(msiva\)" , "raggarwa_1@yahoo.com" , "rcallon@juniper.net" , "David Ball -X \(daviball - Ensoft Ltd at Cisco\)" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 09 Jan 2013 17:59:05 -0000 I agree with Martin, the text proposed by David describe more accurately wh= at we meant. Thanks, Sami On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > Adrian, David, >=20 > what I think we meant here was that a loop-back function could be done on= an interface regardless of the presence of a MIP/MEP on that interface. Ye= t, I have to admit that MIP and MEP are used in Section 4 of RFC6435, thus = surely causing confusion. >=20 > I'd welcome the views/souvenirs of my co-authors. >=20 > -m >=20 > Le 12/12/2012 19:17, Adrian Farrel a =E9crit : >> Hello, >>=20 >> Authors of RFC 6435: I need to hear from you that you meant the text tha= t David >> suggests. It is very clearly not what you wrote and, if you meant someth= ing >> different, it is clear why people are confused! >>=20 >> Working group: I need to hear from you that you agree with David's >> interpretation and support his proposed change. >>=20 >> Only then will I try to work out whether this is a "typo" worthy of an e= rrata >> report, or a technical change needing a revised RFC. >>=20 >> Thanks, >> Adrian >>=20 >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: 12 December 2012 17:45 >>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; >>> rcallon@juniper.net >>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>>=20 >>>=20 >>> The following errata report has been submitted for RFC6435, >>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435&eid=3D3429 >>>=20 >>> -------------------------------------- >>> Type: Editorial >>> Reported by: David Ball >>>=20 >>> Section: 4 (para 5) >>>=20 >>> Original Text >>> ------------- >>> It should be noted that the data-plane loopback function itself is appl= ied to >> data- >>> plane loopback points residing on different interfaces from MIPs/MEPs. >>>=20 >>> Corrected Text >>> -------------- >>> It should be noted that the data-plane loopback function may be applied= at >>> MIPs/MEPs on different interfaces for different LSPs. >>>=20 >>> Notes >>> ----- >>> The existing text has caused confusion (specifically, among experts in = ITU-T >> SG15 >>> when discussing G.8121.2), in that it seems to suggest that the interfa= ce >> where >>> the MIP/MEP is located may be a different interface to the one where th= e >>> loopback is applied. >>>=20 >>> Having spoken with some of the original authors, it seems this was not = the >> intent >>> of this sentence; the intent was to point out that as different LSPs wo= uld >> have >>> MIPs/MEPs on different interfaces, the corresponding loopback functions= would >>> also be applied on different interfaces. >>>=20 >>> 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 >>> -------------------------------------- >>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>> -------------------------------------- >>> Title : MPLS Transport Profile Lock Instruct and Loopback >> Functions >>> Publication Date : November 2011 >>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, = Ed., M. >> Vigoureux, >>> Ed., X. Dai, Ed. >>> Category : PROPOSED STANDARD >>> Source : Multiprotocol Label Switching >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >>=20 >>=20 From loa@pi.nu Wed Jan 9 10:30:51 2013 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 C1E3921F862E for ; Wed, 9 Jan 2013 10:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 C2xuwbWZ0a2d for ; Wed, 9 Jan 2013 10:30:51 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 2594D21F862D for ; Wed, 9 Jan 2013 10:30:51 -0800 (PST) Received: from [192.168.1.104] (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 999AA823B5; Wed, 9 Jan 2013 19:30:46 +0100 (CET) Message-ID: <50EDB759.7020602@pi.nu> Date: Wed, 09 Jan 2013 19:30:49 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux References: <50CAEAD4.6000705@pi.nu> In-Reply-To: <50CAEAD4.6000705@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Poll ended - poll to see if we have support to make draft-xu-mpls-in-udp an mpls 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: Wed, 09 Jan 2013 18:30:51 -0000 Working Group, This poll has ended and we have a new working group document. Could the authors please re-publish the draft as draft-ietf-mpls-in-udp-00.txt without any other changes to the draft that was polled than file name, dates and revision number. /Loa for the mpls wg co-chairs. On 2012-12-14 10:01, Loa Andersson wrote: > Working group, > > This is to start a "two week" poll on adopting > draft-xu-mpls-in-udp-06 as an MPLS working group document. > Due to the holiday season this poll has been extended with one week. > > 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 January 07, 2013. > > There is one IPR claim against this document - > https://datatracker.ietf.org/ipr/1941/ . > > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. > > However, up to version -03 (the document that we used for the IPR poll) > Marshall Eubanks was listed as one of the authors. Marshall has > discontinued all interactions with the IETF, including the author team > of draft-xu-mpls-in-udp-06. The working group chairs has tried to > contact Marshall by other means, to try get a response on the IPR poll. > We have had no success in this. > > From version -04 the authors decided to remove Marshall as a co-author. > > /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 scott.mansfield@ericsson.com Wed Jan 9 11:10:51 2013 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 F303521F872E for ; Wed, 9 Jan 2013 11:10:50 -0800 (PST) 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=[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 RSDHXbT1w89c for ; Wed, 9 Jan 2013 11:10:50 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 049DA21F84C9 for ; Wed, 9 Jan 2013 11:10:49 -0800 (PST) Received: from EUSAAHC005.ericsson.se ([147.117.188.87]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r09JPOrB006171; Wed, 9 Jan 2013 13:25:33 -0600 Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 14:10:46 -0500 From: Scott Mansfield To: "Andrew G. Malis" , Loa Andersson Thread-Topic: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg document Thread-Index: AQHN6e7Dd2F5/MRiV0+nLV7S5I9RgJhAQc8AgAEkUfA= Date: Wed, 9 Jan 2013 19:10:45 +0000 Message-ID: References: <50E5E64A.8090105@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E24558640C5565eusaamb105ericsso_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg 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: Wed, 09 Jan 2013 19:10:51 -0000 --_000_EF35EE4B92789843B1DECBC0E24558640C5565eusaamb105ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support. -scott. From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of And= rew G. Malis Sent: Tuesday, January 08, 2013 3:44 PM To: Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-fbb-mpls-tp-p2mp-frame= work@tools.ietf.org Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-t= p-p2mp-framework-06.txt an MPLS wg document Loa, I support adoption of this draft. Cheers, Andy On Thu, Jan 3, 2013 at 3:12 PM, Loa Andersson >= wrote: Working group, This is to start a two week poll on adopting draft-fbb-mpls-tp-p2mp-framework-06 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 tech= nical 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 January 17, 2013. There are no IPR claim against this document. All the active co-authors has stated on the working group mailing list that they are not aware of any other IPR claims than those already disclosed. /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 --_000_EF35EE4B92789843B1DECBC0E24558640C5565eusaamb105ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support.

 <= /p>

-scott.=

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Tuesday, January 08, 2013 3:44 PM
To: Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-fbb-mpls-tp-p2m= p-framework@tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-fbb= -mpls-tp-p2mp-framework-06.txt an MPLS wg document

 

Loa,

I support adoption of this draft.

Cheers,
Andy

 

On Thu, Jan 3, 2013 at 3:12 PM, Loa Andersson <loa@pi.nu> wrote:<= /o:p>

Working group,

This is to start a two week poll on adopting
draft-fbb-mpls-tp-p2mp-framework-06 as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls at i= etf.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 January 17, 2013.

There are no IPR claim against this document.

All the active co-authors has stated on the working group mailing list
that they are not aware of any other IPR claims than those already
disclosed.

/Loa
(mpls wg co-chair)

--


Loa Andersson           &nb= sp;             email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager     &nbs= p;      loa@p= i.nu
Ericsson Inc           &nbs= p;              phone: +46 10 717 52 13
              &nb= sp;                     &= nbsp;        +46 767 72 92 13
_______________________________________________
mpls mailing list
m= pls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls<= /span>

 

--_000_EF35EE4B92789843B1DECBC0E24558640C5565eusaamb105ericsso_-- From martin.vigoureux@alcatel-lucent.com Wed Jan 9 12:30:04 2013 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 8565F21F884A for ; Wed, 9 Jan 2013 12:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.248 X-Spam-Level: X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 xCc8AoPGMiIm for ; Wed, 9 Jan 2013 12:30:03 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id B550521F8844 for ; Wed, 9 Jan 2013 12:30:02 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r09KTvNd005131 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Jan 2013 21:29:57 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 9 Jan 2013 21:29:57 +0100 From: "VIGOUREUX, MARTIN (MARTIN)" To: "Sami Boutros (sboutros)" Date: Wed, 9 Jan 2013 21:29:56 +0100 Thread-Topic: [Editorial Errata Reported] RFC6435 (3429) Thread-Index: AQHN2JGbr8z20Ev6BkqoT9E++A0mPJgV3TmAgCu+nACAAD2fgP//xZV2 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_CCBFBB7025DF984494DEC3285C05815231568E440BFRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "Siva Sivabalan \(msiva\)" , "raggarwa_1@yahoo.com" , "rcallon@juniper.net" , "David Ball -X \(daviball - Ensoft Ltd at Cisco\)" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 09 Jan 2013 20:30:04 -0000 --_000_CCBFBB7025DF984494DEC3285C05815231568E440BFRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sami, Thanks. Yet, I am not sure David's interpretation and mine exactly match. David, correct me if I am wrong. For me it says that we can do loopback on = different interfaces (for different LSPs) but implies that there is a mip/m= ep for that lsp on that interface, while my interpretation is that the pres= ence of a mip/mep for that lsp on that interface is not needed. -m ________________________________ De : Sami Boutros (sboutros) Envoy=E9 : 09/01/2013 19:00 =C0 : VIGOUREUX, MARTIN (MARTIN) Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco); S= iva Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart= Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.ne= t; mpls@ietf.org Objet : Re: [Editorial Errata Reported] RFC6435 (3429) I agree with Martin, the text proposed by David describe more accurately wh= at we meant. Thanks, Sami On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > Adrian, David, > > what I think we meant here was that a loop-back function could be done on= an interface regardless of the presence of a MIP/MEP on that interface. Ye= t, I have to admit that MIP and MEP are used in Section 4 of RFC6435, thus = surely causing confusion. > > I'd welcome the views/souvenirs of my co-authors. > > -m > > Le 12/12/2012 19:17, Adrian Farrel a =E9crit : >> Hello, >> >> Authors of RFC 6435: I need to hear from you that you meant the text tha= t David >> suggests. It is very clearly not what you wrote and, if you meant someth= ing >> different, it is clear why people are confused! >> >> Working group: I need to hear from you that you agree with David's >> interpretation and support his proposed change. >> >> Only then will I try to work out whether this is a "typo" worthy of an e= rrata >> report, or a technical change needing a revised RFC. >> >> Thanks, >> Adrian >> >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: 12 December 2012 17:45 >>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; >>> rcallon@juniper.net >>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>> >>> >>> The following errata report has been submitted for RFC6435, >>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435&eid=3D3429 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: David Ball >>> >>> Section: 4 (para 5) >>> >>> Original Text >>> ------------- >>> It should be noted that the data-plane loopback function itself is appl= ied to >> data- >>> plane loopback points residing on different interfaces from MIPs/MEPs. >>> >>> Corrected Text >>> -------------- >>> It should be noted that the data-plane loopback function may be applied= at >>> MIPs/MEPs on different interfaces for different LSPs. >>> >>> Notes >>> ----- >>> The existing text has caused confusion (specifically, among experts in = ITU-T >> SG15 >>> when discussing G.8121.2), in that it seems to suggest that the interfa= ce >> where >>> the MIP/MEP is located may be a different interface to the one where th= e >>> loopback is applied. >>> >>> Having spoken with some of the original authors, it seems this was not = the >> intent >>> of this sentence; the intent was to point out that as different LSPs wo= uld >> have >>> MIPs/MEPs on different interfaces, the corresponding loopback functions= would >>> also be applied on different interfaces. >>> >>> 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. >>> >>> -------------------------------------- >>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>> -------------------------------------- >>> Title : MPLS Transport Profile Lock Instruct and Loopback >> Functions >>> Publication Date : November 2011 >>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, = Ed., M. >> Vigoureux, >>> Ed., X. Dai, Ed. >>> Category : PROPOSED STANDARD >>> Source : Multiprotocol Label Switching >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >> >> --_000_CCBFBB7025DF984494DEC3285C05815231568E440BFRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sa= mi,

Thanks. Yet, I am not sure David's interpretation and mine exact= ly match.
David, correct me if I am wrong. For me it says that we can do= loopback on different interfaces (for different LSPs) but implies that the= re is a mip/mep for that lsp on that interface, while my interpretation is = that the presence of a mip/mep for that lsp on that interface is not needed= .

-m
De : Sami Boutros (sboutros)
E= nvoy=E9 : 09/01/2013 19:00
=C0 : VIGOUREUX, MARTIN (MARTIN)<= br>Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco);= Siva Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewa= rt Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.= net; mpls@ietf.org
Objet : Re: [Editorial Errata Reported] RFC6435= (3429)

I agree with Martin, the text pro= posed by David describe more accurately what we meant.

Thanks,

Sami
On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote:

> Adrian, David,
>
> what I think we meant here was that a loop-back function could be done= on an interface regardless of the presence of a MIP/MEP on that interface.= Yet, I have to admit that MIP and MEP are used in Section 4 of RFC6435, th= us surely causing confusion.
>
> I'd welcome the views/souvenirs of my co-authors.
>
> -m
>
> Le 12/12/2012 19:17, Adrian Farrel a =E9crit :
>> Hello,
>>
>> Authors of RFC 6435: I need to hear from you that you meant the te= xt that David
>> suggests. It is very clearly not what you wrote and, if you meant = something
>> different, it is clear why people are confused!
>>
>> Working group: I need to hear from you that you agree with David's=
>> interpretation and support his proposed change.
>>
>> Only then will I try to work out whether this is a "typo"= ; worthy of an errata
>> report, or a technical change needing a revised RFC.
>>
>> Thanks,
>> Adrian
>>
>>> -----Original Message-----
>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
>>> Sent: 12 December 2012 17:45
>>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com;=
>>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@ci= sco.com;
>>> rcallon@juniper.net
>>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.o= rg
>>> Subject: [Editorial Errata Reported] RFC6435 (3429)
>>>
>>>
>>> The following errata report has been submitted for RFC6435, >>> "MPLS Transport Profile Lock Instruct and Loopback Functi= ons".
>>>
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435&= amp;eid=3D3429
>>>
>>> --------------------------------------
>>> Type: Editorial
>>> Reported by: David Ball<daviball@cisco.com>
>>>
>>> Section: 4 (para 5)
>>>
>>> Original Text
>>> -------------
>>> It should be noted that the data-plane loopback function itsel= f is applied to
>> data-
>>> plane loopback points residing on different interfaces from MI= Ps/MEPs.
>>>
>>> Corrected Text
>>> --------------
>>> It should be noted that the data-plane loopback function may b= e applied at
>>> MIPs/MEPs on different interfaces for different LSPs.
>>>
>>> Notes
>>> -----
>>> The existing text has caused confusion (specifically, among ex= perts in ITU-T
>> SG15
>>> when discussing G.8121.2), in that it seems to suggest that th= e interface
>> where
>>> the MIP/MEP is located may be a different interface to the one= where the
>>> loopback is applied.
>>>
>>> Having spoken with some of the original authors, it seems this= was not the
>> intent
>>> of this sentence; the intent was to point out that as differen= t LSPs would
>> have
>>> MIPs/MEPs on different interfaces, the corresponding loopback = functions would
>>> also be applied on different interfaces.
>>>
>>> Instructions:
>>> -------------
>>> This errata is currently posted as "Reported". If ne= cessary, please
>>> use "Reply All" to discuss whether it should be veri= fied or
>>> rejected. When a decision is reached, the verifying party (IES= G)
>>> can log in to change the status and edit the report, if necess= ary.
>>>
>>> --------------------------------------
>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08)
>>> --------------------------------------
>>> Title         &nb= sp;     : MPLS Transport Profile Lock Instruct and Loop= back
>> Functions
>>> Publication Date    : November 2011
>>> Author(s)         = ;  : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M.
>> Vigoureux,
>>> Ed., X. Dai, Ed.
>>> Category         =    : PROPOSED STANDARD
>>> Source         &n= bsp;    : Multiprotocol Label Switching
>>> Area         &nbs= p;      : Routing
>>> Stream         &n= bsp;    : IETF
>>> Verifying Party     : IESG
>>
>>

--_000_CCBFBB7025DF984494DEC3285C05815231568E440BFRMRSSXCHMBSA_-- From mach.chen@huawei.com Wed Jan 9 17:45:28 2013 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 5C57F1F0CDF for ; Wed, 9 Jan 2013 17:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=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 ujWgqNjll159 for ; Wed, 9 Jan 2013 17:45:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3451F0C6A for ; Wed, 9 Jan 2013 17:45:25 -0800 (PST) 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 ANI69997; Thu, 10 Jan 2013 01:45:24 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 01:44:24 +0000 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 01:45:22 +0000 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.77]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 10 Jan 2013 09:45:13 +0800 From: Mach Chen To: "Luyuan Fang (lufang)" , Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AQHN7bfounww1a4JiEe40Y//FfKR+phBy/qw Date: Thu, 10 Jan 2013 01:45:13 +0000 Message-ID: References: <0DB8F45437AB844CBB5102F807A0AD931025B693@xmb-rcd-x03.cisco.com> In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD931025B693@xmb-rcd-x03.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 10 Jan 2013 01:45:28 -0000 Luyuan, Yes, I also intend to remove the term sections, please do that. Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Luyuan Fang (lufang) > Sent: Tuesday, January 08, 2013 11:50 PM > To: Mach Chen; Loa Andersson; mpls@ietf.org > Cc: draft-ietf-mpls-tp-security-framework@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-frame= work >=20 > Hi Mach, >=20 > Thank you for your review and comments. > We accept your comments on the terminologies section, will re-spin the > draft when the wg last call has ended. > One way to handle this is to remove the current terminology section as yo= u > suggested, and point to RFC5654/5921 for MPLS-TP terms, RFC5920 for > security terms which are relevant to MPLS/GMPLS. >=20 > Thanks, > Luyuan >=20 > -----Original Message----- > From: Mach Chen > Date: Monday, January 7, 2013 10:29 PM > To: Loa Andersson , "mpls@ietf.org" > Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org" > , > "mpls-chairs@tools.ietf.org" > Subject: RE: [mpls] 2nd wg last call on > draft-ietf-mpls-tp-security-framework > Resent-From: > Resent-To: , Luyuan Fang , > , , , > , > Resent-Date: Monday, January 7, 2013 10:29 PM >=20 > >Hi, > > > >I have read the latest version of the draft, I am OK with the content an= d > >support to move it forward. > > > >One comment about the Terminology section, it lists only partial > >terminologies used in the document and some of the terminologies(e.g., > >MEP, MIP) are actually not used in the draft. It's better that the > >authors could review the draft and then add all(or most of ) the major > >terminologies and remove the useless terminologies. Or the simplest way > >is just to remove the whole Terminologies Section :-). > > > >Best regards, > >Mach > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf O= f > >>Loa > >> Andersson > >> Sent: Monday, January 07, 2013 6:22 PM > >> To: mpls@ietf.org > >> Cc: draft-ietf-mpls-tp-security-framework@tools.ietf.org; > >> mpls-chairs@tools.ietf.org > >> Subject: [mpls] 2nd wg last call on > >>draft-ietf-mpls-tp-security-framework > >> > >> Working Group, > >> > >> This is to start a working group last call on > >> draft-ietf-mpls-tp-security-framework-06. > >> > >> This is the second time this document is working group last called, > >> three has been a major update of the document since last time. > >> > >> Please find a diff: > >> > >>http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-tp-security-framewor= k-05 > >>&diff > >> type=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-security-framew= ork-06 > >> > >> 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. > >> > >> There are no IPR claims against this draft. > >> > >> All the co-authors has stated that they are not ware of any IPRs. > >> > >> This working group last call will end on January 18, 2013. > >> > >> /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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From mach.chen@huawei.com Wed Jan 9 18:08:59 2013 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 CB68411E80A4 for ; Wed, 9 Jan 2013 18:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 EcER2-DQkGzO for ; Wed, 9 Jan 2013 18:08:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 835B811E8097 for ; Wed, 9 Jan 2013 18:08:58 -0800 (PST) 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 AOP06667; Thu, 10 Jan 2013 02:08:56 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 02:07:56 +0000 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 Jan 2013 02:08:55 +0000 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.77]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Thu, 10 Jan 2013 10:08:53 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg document Thread-Index: AQHN6e6/yMDRox3EBEy+jmgnN4pRSZhB2u7w Date: Thu, 10 Jan 2013 02:08:51 +0000 Message-ID: References: <50E5E64A.8090105@pi.nu> In-Reply-To: <50E5E64A.8090105@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.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg 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, 10 Jan 2013 02:09:00 -0000 Support! Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of L= oa > Andersson > Sent: Friday, January 04, 2013 4:13 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; > draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org > Subject: [mpls] poll to see if we have support to make > draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg document >=20 > Working group, >=20 > This is to start a two week poll on adopting > draft-fbb-mpls-tp-p2mp-framework-06 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 support, especially if you think that > the document should not be adopted as a working group document. >=20 > This poll ends January 17, 2013. >=20 > There are no IPR claim against this document. >=20 > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. >=20 > /Loa > (mpls wg co-chair) >=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 From sboutros@cisco.com Wed Jan 9 18:12:41 2013 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 4965111E80A3 for ; Wed, 9 Jan 2013 18:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.765 X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 npumEsMADPVG for ; Wed, 9 Jan 2013 18:12:40 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2C36711E8097 for ; Wed, 9 Jan 2013 18:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6113; q=dns/txt; s=iport; t=1357783960; x=1358993560; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R3HSSkTuvUlJovT6xJBYExVSBT5dBIt7e2o2rwb68Gk=; b=UJtTK6QWJrEa2hlKPgr4HUGEWQdMdjJDWcpEvBUlTJReZLrsksZ3LWa9 1LeXweOGUoT3FxWM6FnJMLwLAdt4V0reBUhvrcz9PcCyyoG35XoVtpgeK FIE+hQ6PgZnZng4pI0nKtH+Um4sk/eVFbFK9E1BLlUw4QyXlMNodwC1Vt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANIi7lCtJV2b/2dsb2JhbABEvWYWc4IfAQEEAQEBawsOAgIBCCIdBxsMCxQRAgQOBQgBiBAMtgsEjF6DV2EDiC2eKIEvgUWBbzU X-IronPort-AV: E=Sophos;i="4.84,441,1355097600"; d="scan'208,217";a="160758236" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 10 Jan 2013 02:12:39 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0A2CdB8015097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jan 2013 02:12:39 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.232]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 20:12:39 -0600 From: "Sami Boutros (sboutros)" To: "Andrew G. Malis" Thread-Topic: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AQHN7eLmOi0ESYaTGEGFcBteRyLtuZhCOLkA Date: Thu, 10 Jan 2013 02:12:38 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F113338FF8@xmb-rcd-x08.cisco.com> References: <50EAA1C5.20009@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.209.45] Content-Type: multipart/alternative; boundary="_000_473DA00BC97EE04A9B4EE875F48CE5F113338FF8xmbrcdx08ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "" Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 10 Jan 2013 02:12:41 -0000 --_000_473DA00BC97EE04A9B4EE875F48CE5F113338FF8xmbrcdx08ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It looks ready to me too. Thanks, Sami On Jan 8, 2013, at 12:57 PM, Andrew G. Malis wrote: It looks ready to publish to me, and the new acknowledgements section shoul= d help it sail through the process! :-) Cheers, Andy On Mon, Jan 7, 2013 at 5:21 AM, Loa Andersson >= wrote: Working Group, This is to start a working group last call on draft-ietf-mpls-tp-security-framework-06. This is the second time this document is working group last called, three has been a major update of the document since last time. Please find a diff: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-tp-security-framework-05= &difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-security-framew= ork-06 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. There are no IPR claims against this draft. All the co-authors has stated that they are not ware of any IPRs. This working group last call will end on January 18, 2013. /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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_473DA00BC97EE04A9B4EE875F48CE5F113338FF8xmbrcdx08ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <984BAC9B4986B942B9063C2FFA82354D@cisco.com> Content-Transfer-Encoding: quoted-printable It looks ready to me too.

Thanks,

Sami
On Jan 8, 2013, at 12:57 PM, Andrew G. Malis wrote:

It looks ready to publish to me, and the new acknowledgements section = should help it sail through the process! :-)

Cheers,
Andy


On Mon, Jan 7, 2013 at 5:21 AM, Loa Andersson <loa@pi.nu>= wrote:
Working Group,

This is to start a working group last call on
draft-ietf-mpls-tp-security-framework-06.

This is the second time this document is working group last called,
three has been a major update of the document since last time.

Please find a diff:
http://www.ietf.org/rfcdif= f?url1=3Ddraft-ietf-mpls-tp-security-framework-05&= difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-<= u>security-framework-06

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.

There are no IPR claims against this draft.

All the co-authors has stated that they are not ware of any IPRs.

This working group last call will end on January 18, 2013.

/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
                     = ;                     &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
https://www.ietf.org/mailman/listinfo/mpls

--_000_473DA00BC97EE04A9B4EE875F48CE5F113338FF8xmbrcdx08ciscoc_-- From rajiva@cisco.com Wed Jan 9 18:19:43 2013 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 A284B11E80DC for ; Wed, 9 Jan 2013 18:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.932 X-Spam-Level: X-Spam-Status: No, score=-8.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 PpRnqkUimn2g for ; Wed, 9 Jan 2013 18:19:42 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 265DE11E80D7 for ; Wed, 9 Jan 2013 18:19:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6210; q=dns/txt; s=iport; t=1357784382; x=1358993982; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WCgdkJcFhig+CGZt7rw846uX4chnHz+mJd6PAp0YIEk=; b=JP8XSzVeUiuxRINLv7thyZOp4rdMj91M4i0wh1sNp3My53xqM1/BCzmg PcP50IO4XycBaPC+V90IdNCRVW//VYU39isdsnprTBkqlJ/i2dIj7CDe1 spgFBjujg6vNDNQrXiEviqkKnqo34VCfCKrVjgVYb0krvA8Ppda1NkA2P 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUIALck7lCtJV2a/2dsb2JhbABEg0e6HxZzgh8BAQQBAQFrCw4CAgEINQoHGwYGCxQRAgQOBQmHfgMPDK9VDYYwBItpdYNXYQOUNoFWizeFEoEvgUWBbw X-IronPort-AV: E=Sophos;i="4.84,441,1355097600"; d="scan'208,217";a="160546424" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 10 Jan 2013 02:19:41 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0A2Jf6U007667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jan 2013 02:19:41 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 20:19:40 -0600 From: "Rajiv Asati (rajiva)" To: "Andrew G. Malis" Thread-Topic: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AQHN7eLmHYVeXLgnl0yiJ6AQ692YzZhB1h65 Date: Thu, 10 Jan 2013 02:19:40 +0000 Message-ID: References: <50EAA1C5.20009@pi.nu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B721B4CB94944A5E95C2C9347DB46D6Fciscocom_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-security-framework@tools.ietf.org" Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 10 Jan 2013 02:19:43 -0000 --_000_B721B4CB94944A5E95C2C9347DB46D6Fciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks good to me. Cheers, Rajiv Sent from my Phone On Jan 8, 2013, at 3:58 PM, "Andrew G. Malis" > wrote: It looks ready to publish to me, and the new acknowledgements section shoul= d help it sail through the process! :-) Cheers, Andy On Mon, Jan 7, 2013 at 5:21 AM, Loa Andersson >= wrote: Working Group, This is to start a working group last call on draft-ietf-mpls-tp-security-framework-06. This is the second time this document is working group last called, three has been a major update of the document since last time. Please find a diff: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-tp-security-framework-05= &difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-security-framew= ork-06 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. There are no IPR claims against this draft. All the co-authors has stated that they are not ware of any IPRs. This working group last call will end on January 18, 2013. /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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_B721B4CB94944A5E95C2C9347DB46D6Fciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Looks good to me.

Cheers,
Rajiv

Sent from my Phone

On Jan 8, 2013, at 3:58 PM, "Andrew G. Malis" <agmalis@gmail.com> wrote:

It looks ready to publish to me, and the new acknowledgements section = should help it sail through the process! :-)

Cheers,
Andy


On Mon, Jan 7, 2013 at 5:21 AM, Loa Andersson <loa@pi.nu>= wrote:
Working Group,

This is to start a working group last call on
draft-ietf-mpls-tp-security-framework-06.

This is the second time this document is working group last called,
three has been a major update of the document since last time.

Please find a diff:
http://www.ietf.org/rfcdif= f?url1=3Ddraft-ietf-mpls-tp-security-framework-05&= difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-<= u>security-framework-06

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.

There are no IPR claims against this draft.

All the co-authors has stated that they are not ware of any IPRs.

This working group last call will end on January 18, 2013.

/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
                     = ;                     &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
https://www.ie= tf.org/mailman/listinfo/mpls
--_000_B721B4CB94944A5E95C2C9347DB46D6Fciscocom_-- From koike.yoshinori@lab.ntt.co.jp Wed Jan 9 22:17:34 2013 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 ED39421F84BC for ; Wed, 9 Jan 2013 22:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 AebCL3ouQhbT for ; Wed, 9 Jan 2013 22:17:32 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 01B0021F847F for ; Wed, 9 Jan 2013 22:17:31 -0800 (PST) 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 r0A6HQpF000395; Thu, 10 Jan 2013 15:17:26 +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 C8D7BE016E; Thu, 10 Jan 2013 15:17:26 +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 BD0A2E016C; Thu, 10 Jan 2013 15:17:26 +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 r0A6HQ2R013289; Thu, 10 Jan 2013 15:17:26 +0900 Message-ID: <50EE5D7E.2010901@lab.ntt.co.jp> Date: Thu, 10 Jan 2013 15:19:42 +0900 From: Yoshinori Koike User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Ball References: <20121212174431.2DCABB1E002@rfc-editor.org> <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> <50CB6508.10804@lab.ntt.co.jp> <20121217140541.GN4232@cisco.com> <20130104110030.GD14216@cisco.com> In-Reply-To: <20130104110030.GD14216@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 10 Jan 2013 06:17:34 -0000 Hi David, I'm terribly sorry for the delay in replying to you. Thank you very much for the reply. See in line, please. (2013/01/04 20:00), David Ball wrote: > Hi Yoshinori, > > Did you have any further thoughts on this? > > Thanks, > > > David > > > On Mon, Dec 17, 2012, David Ball wrote: >> Hi Yoshinori, >> >> Thanks for your comments. >> >> With regards to your proposal, I am still a little unclear on the >> intended relationship between the dataplane loopback point and the >> MIP/MEP. Are these always on the same interface? If not, under what >> conditions could they be on different interfaces? How is the location >> of the dataplane loopback point determined? I think it depends on the maintenance model. In per-node model, it will be impossible when MIP/MEP is placed on forwarding engine. However, I've heard that in most of the implementation of routers, MIP/MEP is placed on ingress-IF. Then there seems no issue that both MIP/MEP and data-plane loopback point are located on the same ingress-IF. In per-interface model, I think these are usually on the same interface, although some implementation may/might implement on only one side of interfaces(only ingress-IF). It seems ideal that data-plane loopback point is located before MIP/MEP on ingress IF and/or after MIP/MEP on egress IF. >> To take a concrete example, suppose we have an interface with both a LSP >> MEP and a PW MEP. OAM packets destined for the LSP MEP will have an LSP >> label and a GAL, while OAM packets destined for the PW MEP will have an >> LSP label and a PW label. Client data traffic will also have both an >> LSP and a PW label. Correct me if I'm wrong, but I guess you assume that both a LSP MEP and a PW MEP are placed on the same ingress-IF in a per-node model, which is said to be the most typical model of IP/MPLS routers. >> Now, if either the LSP MEP or the PW MEP are put into a loopback mode, >> all of the client data packets will be looped. But which OAM packets >> are looped? >> - If the LSP MEP is put into loopback mode, do the LSP OAM packets get >> looped? I think so, since RFC6435 says that both data and OAM >> packets are looped. >> - If the LSP MEP is put into loopback mode, do the PW OAM packets get >> looped? Again, I think so. >> - If the PW MEP is put into loopback mode, do the PW OAM packets get >> looped? I think yes, this is equivalent to the first case. >> - If the PW MEP is put into loopback mode, do the LSP OAM packets get >> looped. Since they do not have a PW label, I am not sure? I think >> probably they shouldn't be, since there may be other PWs flowing over >> the same LSP, with different PW labels, right? My assumption was that if a data-plane loopback function is enabled using the LSP MEP, a data-plane loopback point(s) (in my understanding, a data-plane loopback sink and source process) in ingress-IF is enabled, all the traffics that the data-plane loopback sink process has received get looped through data-plane source process. Although the position of data-plane loopback process is located is not detailed in G.8121 including G.8121 amd1 under AAP, it doesn't seem to be considered only OAM packets get looped at the loopback process. In addition, when a data-plane loopback function is enabled, I think OAM functions should be disabled in principle. >> >> Regarding ITU-T G.8121 Amd 1 and G.8121.2, the reason the dataplane >> loopback process was removed from the MTDe figures in the last SG15 >> meeting was because of this confusing sentence in RFC6435 - in other >> words, it wasn't clear whether the MTDe function was the right place for >> them so as to match the behaviour specified in the RFC. The intent of >> G.8121.2 is to exactly match RFC6435 and the other relevant IETF RFCs. >> >> >> As a result, in the current ITU-T G.8121/G.8121.2, the dataplane >> loopback processes do not appear in any of the termination or adaptation >> functions that are specified; so although the processes themselves are >> defined, they are never applied. The question is, what is the correct >> place to apply them in the ITU-T model so as to match the RFC? Thank you for the clarification. My understanding of G.8121 amd is that a data-plane loopback point is located before MIP/MEP on ingress IF and/or after MIP/MEP on egress IF and whether the type of data is AI/CI/client depends on the implementation. Best regards, Yoshinori >> >> >> David >> >> >> On Sat, Dec 15, 2012, Yoshinori Koike wrote: >>> Hello David, >>> >>> I agree with original text is confusing and thank you for the >>> proposal. However, I'm wondering if the proposed text is true and >>> exactly reflect the intent explained in the notes. >>> >>> My suggestion is as follows: >>> It should be noted that the data-plane loopback function itself is >>> applied to data-plane loopback point which is different from >>> MIP/MEP. >>> >>> Firstly, the description "the data-plane loopback function may be >>> applied at MIPs/MEPs" doesn't seem to be true. >>> >>> In my understanding, data-plane loopback function can be >>> set/enabled/disabled at MIP/MEP using a management system but not be >>> applied to MIP/MEP itself. So I clarified this point in my proposal. >>> >>> One of the reason is that MIP/MEP is only involved in OAM packets. >>> There seems no specification in any RFC, which describe that MIP/MEP >>> could handle data packets which are not OAM packets . >>> >>> In G.8121 amd1, data-plane loopback sink and source are specified >>> and according to Temporary Document(TD673R1<->R0/Plen) during last >>> SG15 meeting, the data-plane loopback sink/source was removed from >>> figures of MTDe_TT_Sk/So Process(Fig.9-14&16). I guess this might be >>> to avoid a restriction of implementations, however it doesn't seem >>> to make it possible to apply dataplane loopback point to MIP/MEP. In >>> realty, if data-plane loopback function is enabled, for data-plane >>> LB function there is no need to parse the packet except for >>> outermost label value. >>> >>> Secondly, if you need to clarify the relationship between data-plane >>> LB point at which data-plane LB function is conducted and MIP/MEP at >>> which data-plane LB function is enabled/configured using management >>> system, it seems enough just to say the two point usually resides on >>> the same interface and clarify the binding of two points. I have no >>> issue on this specification. However, just in case, it seems better >>> to confirm if the change is ok in ITU-T joint interregnum meeting >>> Jan 2013, because this is a matter of 8121 or/and G.8121.1. As a >>> result, I didn't add related text in my proposal. >>> >>> I'm not an implementer, so I would appreciate it if you could >>> correct me if I'm wrong. Thank you in advance. >>> >>> Best regards, >>> >>> Yoshinori >>> >>> >>> (2012/12/13 3:17), Adrian Farrel wrote: >>>> Hello, >>>> >>>> Authors of RFC 6435: I need to hear from you that you meant the text that David >>>> suggests. It is very clearly not what you wrote and, if you meant something >>>> different, it is clear why people are confused! >>>> >>>> Working group: I need to hear from you that you agree with David's >>>> interpretation and support his proposed change. >>>> >>>> Only then will I try to work out whether this is a "typo" worthy of an errata >>>> report, or a technical change needing a revised RFC. >>>> >>>> Thanks, >>>> Adrian >>>> >>>>> -----Original Message----- >>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>> Sent: 12 December 2012 17:45 >>>>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>>>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>>>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; >>>>> rcallon@juniper.net >>>>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>>>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>>>> >>>>> >>>>> The following errata report has been submitted for RFC6435, >>>>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 >>>>> >>>>> -------------------------------------- >>>>> Type: Editorial >>>>> Reported by: David Ball >>>>> >>>>> Section: 4 (para 5) >>>>> >>>>> Original Text >>>>> ------------- >>>>> It should be noted that the data-plane loopback function itself is applied to >>>> data- >>>>> plane loopback points residing on different interfaces from MIPs/MEPs. >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> It should be noted that the data-plane loopback function may be applied at >>>>> MIPs/MEPs on different interfaces for different LSPs. >>>>> >>>>> Notes >>>>> ----- >>>>> The existing text has caused confusion (specifically, among experts in ITU-T >>>> SG15 >>>>> when discussing G.8121.2), in that it seems to suggest that the interface >>>> where >>>>> the MIP/MEP is located may be a different interface to the one where the >>>>> loopback is applied. >>>>> >>>>> Having spoken with some of the original authors, it seems this was not the >>>> intent >>>>> of this sentence; the intent was to point out that as different LSPs would >>>> have >>>>> MIPs/MEPs on different interfaces, the corresponding loopback functions would >>>>> also be applied on different interfaces. >>>>> >>>>> 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. >>>>> >>>>> -------------------------------------- >>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>>>> -------------------------------------- >>>>> Title : MPLS Transport Profile Lock Instruct and Loopback >>>> Functions >>>>> Publication Date : November 2011 >>>>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. >>>> Vigoureux, >>>>> Ed., X. Dai, Ed. >>>>> Category : PROPOSED STANDARD >>>>> Source : Multiprotocol Label Switching >>>>> Area : Routing >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>> >>> >>> -- >>> Yoshinori Koike >>> koike.yoshinori@lab.ntt.co.jp >>> >> >> -- >> David Ball >> > -- Yoshinori Koike koike.yoshinori@lab.ntt.co.jp From nurit.sprecher@nsn.com Wed Jan 9 23:00:36 2013 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 0016221F886D for ; Wed, 9 Jan 2013 23:00:35 -0800 (PST) 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 Eb0mctvnRNpP for ; Wed, 9 Jan 2013 23:00:34 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6644F21F8864 for ; Wed, 9 Jan 2013 23:00:33 -0800 (PST) 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 r0A70VUn030937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jan 2013 08:00:31 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r0A70SVR028020; Thu, 10 Jan 2013 08:00:29 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jan 2013 08:00:28 +0100 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: Thu, 10 Jan 2013 08:00:27 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: 2nd wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AQHN7MDVTh7zjGol0UmgmGzQlFGPM5hB/dWAgAAoqLA= From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" X-OriginalArrivalTime: 10 Jan 2013 07:00:28.0971 (UTC) FILETIME=[2C8737B0:01CDEF00] 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: 1887 X-purgate-ID: 151667::1357801232-0000215D-4ABA66AC/0-0/0-0 Cc: mpls@ietf.org Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 10 Jan 2013 07:00:36 -0000 Support, - Nurit -----Original Message----- From: Loa Andersson Date: Monday, January 7, 2013 2:21 AM To: "mpls@ietf.org" Cc: "mpls-chairs@tools.ietf.org" , Martin Vigoureux , "draft-ietf-mpls-tp-security-framework@tools.ietf.org" Subject: 2nd wg last call on draft-ietf-mpls-tp-security-framework Resent-From: Resent-To: , Luyuan Fang , , , , , Resent-Date: Monday, January 7, 2013 2:22 AM >Working Group, > >This is to start a working group last call on >draft-ietf-mpls-tp-security-framework-06. > >This is the second time this document is working group last called, >three has been a major update of the document since last time. > >Please find a diff: >http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-tp-security-framework= - 05& >difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-security-fram= ework -06 > >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. > >There are no IPR claims against this draft. > >All the co-authors has stated that they are not ware of any IPRs. > >This working group last call will end on January 18, 2013. > >/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 From tochio@jp.fujitsu.com Wed Jan 9 23:03:50 2013 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 989FE21F88EA for ; Wed, 9 Jan 2013 23:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.489 X-Spam-Level: X-Spam-Status: No, score=-103.489 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, 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 ZQaTsWImY-9G for ; Wed, 9 Jan 2013 23:03:48 -0800 (PST) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2354A21F8864 for ; Wed, 9 Jan 2013 23:03:47 -0800 (PST) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id BA0CC3EE0B6 for ; Thu, 10 Jan 2013 16:03:46 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id A676D45DE56 for ; Thu, 10 Jan 2013 16:03:46 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 9197545DE54 for ; Thu, 10 Jan 2013 16:03:46 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 828AEE08004 for ; Thu, 10 Jan 2013 16:03:46 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.37]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 36136E08001 for ; Thu, 10 Jan 2013 16:03:46 +0900 (JST) Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp [10.25.192.39]) by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs. Domain Mail Master) with ESMTP id r0A73jFl020754 for ; Thu, 10 Jan 2013 16:03:46 +0900 (JST) X-AuditID: 0a19c027-b7f806d000000f60-0e-50ee67d1dcaf Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vskawa.flab.fujitsu.co.jp (Symantec Messaging Gateway) with SMTP id 1F.ED.03936.1D76EE05; Thu, 10 Jan 2013 16:03:46 +0900 (JST) Received: from [127.0.0.1] (dhcp252022-wireless-kawa.meetingroom.flab.fujitsu.co.jp [10.25.252.22]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id r0A73cqW004246 for ; Thu, 10 Jan 2013 16:03:45 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.4 Message-ID: <50EE67AD.7010802@jp.fujitsu.com> Date: Thu, 10 Jan 2013 16:03:09 +0900 From: Yuji Tochio User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mpls@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060807070405020702090800" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsXCJXkgU/dS+rsAg2PvmS1uLV3J6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujG0TdrEXHJ7AWHF321PWBsZd+V2MnBwSAiYSa+4+YoOwxSQu 3FsPZHNxCAk8ZpR4v3YDM4SziEni0MNpUFWmEhPXPWPsYuTg4BXQlTjxIhYkzCKgKjH/Th8z iM0moClxbeYdRhBbVCBYYsPBVUwgNq+AoMTJmU9YQGwRIHva1aNgtrCAncSSO+0sICOFBOIl Pt0zAglzCiRIXP08mx3EZhYIk3gwoZllAiP/LCSTZiFJQdi6EjdPfGSCsOUltr+dwwxh60i8 b77Ijiy+gJFtFaNkWXF2YnmiXlpOYpJeWmlWZklxqV5yvl5WwSZGSOiq72B8tkjzEKMAB6MS D2/JijcBQqyJZcWVuYcYJTiYlUR4Q7a/DRDiTUmsrEotyo8vKs1JLT7EyMTBKdXAqDF/R67p 3hnNe9Wv+v3lttbla7xv87PR+PinNt7dOud/RcbUbX/3gDVBfl/24YU18wum/Q7f3LW8/mHy 33cS/RMMFJ9pVm2eWupw2Y7B5kzt/PAZ4i6fOiZpHLDTs6lV3iAp+XbnLoMcTQXZDXJcp/t0 rNsm6zVUbV0mmDZv99m5LbbpoZnWSizFGYmGWsxFxYkA4p/isDsCAAA= Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 10 Jan 2013 07:03:50 -0000 This is a multi-part message in MIME format. --------------060807070405020702090800 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi In my understanding, the text proposed by David says only loopback function (i.e. a MEP or a MIP on an interface) and there is no description for loopback point. So there is no impliaction that that there is a mip/mep for that lsp on that interface and almost sync with Martin's interpretation. This is why I suport for his proposal. David, please correct me if I am wrong. Regards, Yuji (2013/01/10 5:29), VIGOUREUX, MARTIN (MARTIN) wrote: > Sami, > > Thanks. Yet, I am not sure David's interpretation and mine exactly match. > David, correct me if I am wrong. For me it says that we can do loopback on different interfaces (for different LSPs) but implies that there is a mip/mep for > that lsp on that interface, while my interpretation is that the presence of a mip/mep for that lsp on that interface is not needed. > > -m > ---------------------------------------------------------------------------------------------------------------------------------------------------------------- > De : Sami Boutros (sboutros) > Envoye' : 09/01/2013 19:00 > A` : VIGOUREUX, MARTIN (MARTIN) > Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco); Siva Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant > (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org > Objet : Re: [Editorial Errata Reported] RFC6435 (3429) > > I agree with Martin, the text proposed by David describe more accurately what we meant. > > Thanks, > > Sami > On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > > > Adrian, David, > > > > what I think we meant here was that a loop-back function could be done on an interface regardless of the presence of a MIP/MEP on that interface. Yet, I > have to admit that MIP and MEP are used in Section 4 of RFC6435, thus surely causing confusion. > > > > I'd welcome the views/souvenirs of my co-authors. > > > > -m > > > > Le 12/12/2012 19:17, Adrian Farrel a e'crit : > >> Hello, > >> > >> Authors of RFC 6435: I need to hear from you that you meant the text that David > >> suggests. It is very clearly not what you wrote and, if you meant something > >> different, it is clear why people are confused! > >> > >> Working group: I need to hear from you that you agree with David's > >> interpretation and support his proposed change. > >> > >> Only then will I try to work out whether this is a "typo" worthy of an errata > >> report, or a technical change needing a revised RFC. > >> > >> Thanks, > >> Adrian > >> > >>> -----Original Message----- > >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>> Sent: 12 December 2012 17:45 > >>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > >>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > >>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; > >>> rcallon@juniper.net > >>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org > >>> Subject: [Editorial Errata Reported] RFC6435 (3429) > >>> > >>> > >>> The following errata report has been submitted for RFC6435, > >>> "MPLS Transport Profile Lock Instruct and Loopback Functions". > >>> > >>> -------------------------------------- > >>> You may review the report below and at: > >>> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 > >>> > >>> -------------------------------------- > >>> Type: Editorial > >>> Reported by: David Ball > >>> > >>> Section: 4 (para 5) > >>> > >>> Original Text > >>> ------------- > >>> It should be noted that the data-plane loopback function itself is applied to > >> data- > >>> plane loopback points residing on different interfaces from MIPs/MEPs. > >>> > >>> Corrected Text > >>> -------------- > >>> It should be noted that the data-plane loopback function may be applied at > >>> MIPs/MEPs on different interfaces for different LSPs. > >>> > >>> Notes > >>> ----- > >>> The existing text has caused confusion (specifically, among experts in ITU-T > >> SG15 > >>> when discussing G.8121.2), in that it seems to suggest that the interface > >> where > >>> the MIP/MEP is located may be a different interface to the one where the > >>> loopback is applied. > >>> > >>> Having spoken with some of the original authors, it seems this was not the > >> intent > >>> of this sentence; the intent was to point out that as different LSPs would > >> have > >>> MIPs/MEPs on different interfaces, the corresponding loopback functions would > >>> also be applied on different interfaces. > >>> > >>> 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. > >>> > >>> -------------------------------------- > >>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) > >>> -------------------------------------- > >>> Title : MPLS Transport Profile Lock Instruct and Loopback > >> Functions > >>> Publication Date : November 2011 > >>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. > >> Vigoureux, > >>> Ed., X. Dai, Ed. > >>> Category : PROPOSED STANDARD > >>> Source : Multiprotocol Label Switching > >>> Area : Routing > >>> Stream : IETF > >>> Verifying Party : IESG > >> > >> > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --------------060807070405020702090800 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit
Hi

In my understanding, the text proposed by David says only loopback function
(i.e. a MEP or a MIP on an interface) and there is no description for loopback
point. So there is no impliaction that that there is a mip/mep for that lsp on
that interface and almost sync with Martin's interpretation.

This is why I suport for his proposal. David, please correct me if I am wrong.

Regards, Yuji


(2013/01/10 5:29), VIGOUREUX, MARTIN (MARTIN) wrote:
Sami,

Thanks. Yet, I am not sure David's interpretation and mine exactly match.
David, correct me if I am wrong. For me it says that we can do loopback on different interfaces (for different LSPs) but implies that there is a mip/mep for that lsp on that interface, while my interpretation is that the presence of a mip/mep for that lsp on that interface is not needed.

-m
De : Sami Boutros (sboutros)
Envoyé : 09/01/2013 19:00
À : VIGOUREUX, MARTIN (MARTIN)
Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco); Siva Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org
Objet : Re: [Editorial Errata Reported] RFC6435 (3429)

I agree with Martin, the text proposed by David describe more accurately what we meant.

Thanks,

Sami
On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote:

> Adrian, David,
>
> what I think we meant here was that a loop-back function could be done on an interface regardless of the presence of a MIP/MEP on that interface. Yet, I have to admit that MIP and MEP are used in Section 4 of RFC6435, thus surely causing confusion.
>
> I'd welcome the views/souvenirs of my co-authors.
>
> -m
>
> Le 12/12/2012 19:17, Adrian Farrel a écrit :
>> Hello,
>>
>> Authors of RFC 6435: I need to hear from you that you meant the text that David
>> suggests. It is very clearly not what you wrote and, if you meant something
>> different, it is clear why people are confused!
>>
>> Working group: I need to hear from you that you agree with David's
>> interpretation and support his proposed change.
>>
>> Only then will I try to work out whether this is a "typo" worthy of an errata
>> report, or a technical change needing a revised RFC.
>>
>> Thanks,
>> Adrian
>>
>>> -----Original Message-----
>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
>>> Sent: 12 December 2012 17:45
>>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com;
>>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn;
>>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com;
>>> rcallon@juniper.net
>>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org
>>> Subject: [Editorial Errata Reported] RFC6435 (3429)
>>>
>>>
>>> The following errata report has been submitted for RFC6435,
>>> "MPLS Transport Profile Lock Instruct and Loopback Functions".
>>>
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429
>>>
>>> --------------------------------------
>>> Type: Editorial
>>> Reported by: David Ball<daviball@cisco.com>
>>>
>>> Section: 4 (para 5)
>>>
>>> Original Text
>>> -------------
>>> It should be noted that the data-plane loopback function itself is applied to
>> data-
>>> plane loopback points residing on different interfaces from MIPs/MEPs.
>>>
>>> Corrected Text
>>> --------------
>>> It should be noted that the data-plane loopback function may be applied at
>>> MIPs/MEPs on different interfaces for different LSPs.
>>>
>>> Notes
>>> -----
>>> The existing text has caused confusion (specifically, among experts in ITU-T
>> SG15
>>> when discussing G.8121.2), in that it seems to suggest that the interface
>> where
>>> the MIP/MEP is located may be a different interface to the one where the
>>> loopback is applied.
>>>
>>> Having spoken with some of the original authors, it seems this was not the
>> intent
>>> of this sentence; the intent was to point out that as different LSPs would
>> have
>>> MIPs/MEPs on different interfaces, the corresponding loopback functions would
>>> also be applied on different interfaces.
>>>
>>> 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.
>>>
>>> --------------------------------------
>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08)
>>> --------------------------------------
>>> Title               : MPLS Transport Profile Lock Instruct and Loopback
>> Functions
>>> Publication Date    : November 2011
>>> Author(s)           : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M.
>> Vigoureux,
>>> Ed., X. Dai, Ed.
>>> Category            : PROPOSED STANDARD
>>> Source              : Multiprotocol Label Switching
>>> Area                : Routing
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>
>> 



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

--------------060807070405020702090800-- From zjbdamo@hotmail.com Thu Jan 10 01:10:04 2013 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 7086421F8930 for ; Thu, 10 Jan 2013 01:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, MIME_8BIT_HEADER=0.3] 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 3l-FXpwTJJCJ for ; Thu, 10 Jan 2013 01:10:03 -0800 (PST) Received: from blu0-omc4-s22.blu0.hotmail.com (blu0-omc4-s22.blu0.hotmail.com [65.55.111.161]) by ietfa.amsl.com (Postfix) with ESMTP id C76D521F8936 for ; Thu, 10 Jan 2013 01:10:02 -0800 (PST) Received: from BLU168-W90 ([65.55.111.136]) by blu0-omc4-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jan 2013 01:10:01 -0800 X-EIP: [tNsB/cBfFJCqIXHzIqz9trAv9RfpZXUt] X-Originating-Email: [zjbdamo@hotmail.com] Message-ID: Content-Type: multipart/mixed; boundary="_72523b5d-f17b-407c-886b-6192bb5eebdf_" From: =?utf-8?B?5pu+5bO75rOi?= To: Date: Thu, 10 Jan 2013 17:10:01 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2013 09:10:01.0719 (UTC) FILETIME=[45727070:01CDEF12] Cc: yaacov.weingarten@nsn.com Subject: [mpls] in some scenario RFC6378 can not protect the traffic, so much as take the PSC state to crash. 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, 10 Jan 2013 09:10:04 -0000 --_72523b5d-f17b-407c-886b-6192bb5eebdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCihpZiB0aGUgZmlndXJlIGNhbiBub3QgZGlzcGxheSBub3JtYWxseSxwbGVhc2Ugc2VlIHRo ZSBhdHRhY2ggZmlsZS50aGFua3MuKQ0KDQoNCldoZW4gaW4gbXVsdGkgZmF1bHQvcHJpb3JpdHkg Y29uZGl0aW9uIHNjZW5hcmlvLFJGQzYzNzggY2FuIG5vdCBwcm90ZWN0IHRoZSB0cmFmZmljIHNv IG11Y2ggYXMgdGFrZSB0aGUgUFNDIHN0YXRlIHRvIGNyYXNoLmNvbnNpZGVyIHRoZSBmb2xsb3dp bmcgMiBzY2VuYXJpby4NCg0KwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tLS0tLSvCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tLS0tLSsNCsKgwqDCoMKg wqDCoMKgwqDCoMKgIHwgTEVSMSB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHwgTEVSMiB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tKy0tK8KgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tKy0tKw0KwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0t LT58DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8 LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tLSsNCsKgbG9jYWwgbG9ja291dCB8wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg fA0KwqAgaW5wdXTCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCArLS0tLS0tLS0tLS1MT0NLLS0tLS0tLS0tLS0tLS0tLT58DQrCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8LS0tLS0tLS0tTlItLS0tLS0t LS0tLS0tLS0tLS0tLSsNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKg dW5pZGlyZWN0aW9uwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgU0ZfVyByYWlzZcKgwqDCoCB8wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tLS0tLS0tLS0tLUxPQ0stLS0tLS0tLS0tLS0t LT58DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8 LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tLSsNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHwNCsKgbG9jYWwgY2xlYXLCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoCBpbnB1dMKgwqDC oMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICstLS0tLS0t LS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tPnwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg fMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgfDwtLS0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tKw0K wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCANCg0KwqDCoMKgIMKgwqDCoCDCoMKgwqAgZmlndXJlIDE6IHVuaWRpcmVjdGlv biBTRl9XIHJhaXNlIGFmdGVyIGxvY2FsIGxvY2tvdXQgaW5wdXQNCg0KaW4gZmlndXJlIDEsY29u c2lkZXIgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmUNCjEuTEVSMSBhbmQgTEVSMiBhcmUgYm90aCBp biBOT1JNQUwgc3RhdGUgYW5kIGV4Y2hhbmdlIE5SIFBEVS4NCjIudGhlIGxvY2tvdXQgY29tbWFu ZCBpbnB1dCBpbnRvIExFUjEsdGhlbiBMRVIxIHNlbmQgTE9DSyB0byBMRVIyLExFUjIgc2VuZCBO UiB0byBMRVIxLg0KMy5hIHVuaWRpcmVjdGlvbiBTRl9XIGlzIHJhaXNlZCBpbiBMRVIxLGFjY29y ZGluZyBSRkM2Mzc4LCBMRVIxIHN0aWxsIHNlbmQgTE9DSyB0byBMRVIyLExFUjIgc2VuZCBOUiB0 byBMRVIxLg0KNC50aGUgY2xlYXIgY29tbWFuZCBpbnB1dCBpbnRvIExFUjEsYWNjb3JkaW5nIFJG QzYzNzgsTEVSMSB3aWxsIHNlbmQgTlIgdG8gTEVSMixMRVIyIHN0aWxsIHNlbmQgTlIgdG8gTEVS MS4gc28gdHJhZmZpYyBpcyBicm9rZW4uDQoNCg0KDQoNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tLS0tK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tLS0tKw0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHwgTEVSMSB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHwgTEVSMiB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgKy0tLSstLSvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgKy0tLSstLSsNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgTsKgwqDCoCArLS0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLT58wqDCoMKgwqDC oMKgIE4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgfDwtLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KwqDCoMKgwqAgbG9j YWwgbG9ja291dCBpbnB1dMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBVQTpMTzpMICstLS0tLS0tLS0tLUxPQ0stLS0tLS0tLS0tLS0tLS0tPnwNCsKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8 VUE6TE86Ug0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIHw8LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tLSsNCsKgwqDCoMKgwqDCoCBs b2NhbCBjbGVhciBpbnB1dMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIE7CoCArLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0uLi4u Li4uLi58DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgU0ZfVyByYWlzZcKgIHwgdGhp cyBuciBpcyBsb3N0IGZvciBzbXRoLsKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCBhbmQgU0ZfVyBpcyByYWlzZWQuwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgKy0tLS0tLS0tLS1TRl9XLS0tLS0tLS0tLS0tLS0tLS0+fGFsd2F5 cyBpbiBVQTpMTzpSDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCB8PC0tLS0tLS0tLS0tU0ZfVy0tLS0tLS0tLS0tLS0tLS0rDQrC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg fA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IA0KwqDCoMKgwqDCoCBmaWd1cmUgMjogYWZ0ZXIgY2xlYXIgYSBsb2NhbCBMT0NLT1VUIGNvbW1h bmQsU0ZfVyBpcyByYWlzZSBpbW1lZGlhdGVseSxhbmQgdGhlIE5SIHNlbmQgdG8gTEVSMiBpcyBs b3N0IGZvciBzb21ldGhpbmcuDQoNCmluIGZpZ3VyZSAyLGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcg cHJvY2VkdXJlLg0KMS5MRVIxIGFuZCBMRVIyIGFyZSBib3RoIGluIE5PUk1BTCBzdGF0ZSBhbmQg ZXhjaGFuZ2UgTlIgUERVLg0KMi50aGUgbG9ja291dCBjb21tYW5kIGlucHV0IGludG8gTEVSMSx0 aGVuIExFUjEgc2VuZCBMT0NLIHRvIExFUjIgYW5kIHRyYW5zZmVyIHRvIFVBOkxPOkwsTEVSMiBz ZW5kIE5SIHRvIExFUjEgYW5kIHRyYW5zZmVyIHRvIFVBOkxPOlIuDQozLnRoZSBjbGVhciBjb21t YW5kIGlucHV0IGludG8gTEVSMSxMRVIxIHRyYW5zZmVyIHRvIE5SIGFuZCBzZW5kIE5SIHRvIExF UjIsYnV0IHRoaXMgTlIgaXMgbG9zdCBmb3Igc29tZSB1bmtub3duIHJlYXNvbiwgYW5kIFNGX1cg aXMgcmFpc2VkIGltbWVkaWF0ZWx5IGluIExFUjEsc28gdGhhdCB0aGUgTlIgdGhhdCBzZW5kIGJ5 IExFUjEgdG8gTEVSMiBpcyByZXBsYWNlZCBieSBTRl9XLg0KNC5ubyBOUiByZWFjaCBMRVIyLCBp ZiB0aGUgZXJyb3IgaXMgYmlkaXJlY3Rpb25hbCxMRVIyIHdpbGwgc2VuZCBTRl9XIHRvIExFUjEs b3IgTlIgdG8gTEVSMiBpZiB1bmlkaXJlY3Rpb25hbC5idXQgaW4gYW55IGNvbmRpdGlvbixMRVIy IHdpbGwgc3RpbGwgaW4gVUE6TE86UiBzdGF0ZS50aGUgUFNDIGlzIGNyYXNoZWQuIA0KDQoNCnNv IGkgaGF2ZSAyIHBpZWNlcyBvZiBzdWdnZXN0aW9uDQoxLkxFUiBhbHdheXMgc2VuZCBoaXMgbG9j YWwgaGlnaGVzdCBwcmlvcml0eSB0byBpdCdzIHBlZXIuDQoyLkxFUiBhbHdheXMgYWNjZXB0IHRo ZSBpbnB1dCBmcm9tIGhpcyBwZWVyIGJ5IFBTQyBQRFUuDQoNCg0KDQoNCg0KDQpCZXN0IFJlZ2Fy ZHMhDQoNCsKgDQoNCkp1bmJvIFplbmcoQm9CbykNCg0KDQoNCg0KDQogCQkgCSAgIAkJICA= --_72523b5d-f17b-407c-886b-6192bb5eebdf_ Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="q1.TXT" DQpXaGVuIGluIG11bHRpIGZhdWx0L3ByaW9yaXR5IGNvbmRpdGlvbiBzY2VuYXJpbyxSRkM2Mzc4 IGNhbiBub3QgcHJvdGVjdCB0aGUgdHJhZmZpYyBzbyBtdWNoIGFzIHRha2UgdGhlIFBTQyBzdGF0 ZSB0byBjcmFzaC5jb25zaWRlciB0aGUgZm9sbG93aW5nIDIgc2NlbmFyaW8uDQoNCiAgICAgICAg ICAgKy0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLSsNCiAgICAgICAgICAg fCBMRVIxIHwgICAgICAgICAgICAgICAgICAgICAgICAgfCBMRVIyIHwNCiAgICAgICAgICAgKy0t LSstLSsgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLSstLSsNCiAgICAgICAgICAgICAgICst LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tTlItLS0tLS0t LS0tLS0tLS0tLS0tLSsNCiBsb2NhbCBsb2Nrb3V0IHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgaW5wdXQgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLUxPQ0stLS0tLS0tLS0tLS0tLS0tPnwNCiAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg IHw8LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiB1bmlkaXJlY3Rpb24gIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiBTRl9XIHJhaXNlICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tTE9DSy0tLS0t LS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiBsb2NhbCBjbGVh ciAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgaW5wdXQgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS1OUi0tLS0tLS0tLS0t LS0tLS0tLSsNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgIA0KDQoJCQlmaWd1cmUgMTogdW5pZGlyZWN0aW9uIFNGX1cgcmFp c2UgYWZ0ZXIgbG9jYWwgbG9ja291dCBpbnB1dA0KDQppbiBmaWd1cmUgMSxjb25zaWRlciB0aGUg Zm9sbG93aW5nIHByb2NlZHVyZQ0KMS5MRVIxIGFuZCBMRVIyIGFyZSBib3RoIGluIE5PUk1BTCBz dGF0ZSBhbmQgZXhjaGFuZ2UgTlIgUERVLg0KMi50aGUgbG9ja291dCBjb21tYW5kIGlucHV0IGlu dG8gTEVSMSx0aGVuIExFUjEgc2VuZCBMT0NLIHRvIExFUjIsTEVSMiBzZW5kIE5SIHRvIExFUjEu DQozLmEgdW5pZGlyZWN0aW9uIFNGX1cgaXMgcmFpc2VkIGluIExFUjEsYWNjb3JkaW5nIFJGQzYz NzgsIExFUjEgc3RpbGwgc2VuZCBMT0NLIHRvIExFUjIsTEVSMiBzZW5kIE5SIHRvIExFUjEuDQo0 LnRoZSBjbGVhciBjb21tYW5kIGlucHV0IGludG8gTEVSMSxhY2NvcmRpbmcgUkZDNjM3OCxMRVIx IHdpbGwgc2VuZCBOUiB0byBMRVIyLExFUjIgc3RpbGwgc2VuZCBOUiB0byBMRVIxLiBzbyB0cmFm ZmljIGlzIGJyb2tlbi4NCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0rICAg ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgfCBM RVIxIHwgICAgICAgICAgICAgICAgICAgICAgICAgfCBMRVIyIHwNCiAgICAgICAgICAgICAgICAg ICAgICArLS0tKy0tKyAgICAgICAgICAgICAgICAgICAgICAgICArLS0tKy0tKw0KICAgICAgICAg ICAgICAgICAgICAgTiAgICArLS0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAg IE4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tTlItLS0t LS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgbG9jYWwgbG9ja291dCBpbnB1dCAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICBVQTpMTzpMICst LS0tLS0tLS0tLUxPQ0stLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfFVBOkxPOlINCiAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQog ICAgICAgbG9jYWwgY2xlYXIgaW5wdXQgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgIE4gICstLS0tLS0tTlItLS0tLS0t LS0tLS0tLS4uLi4uLi4uLnwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICBTRl9XIHJhaXNlICB8IHRoaXMg bnIgaXMgbG9zdCBmb3Igc210aC4gICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgIHwg YW5kIFNGX1cgaXMgcmFpc2VkLiAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLVNGX1ctLS0tLS0tLS0tLS0tLS0tLT58YWx3YXlzIGluIFVBOkxP OlINCiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0t LVNGX1ctLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgDQogICAgICBmaWd1cmUgMjogYWZ0ZXIgY2xlYXIgYSBsb2NhbCBMT0NLT1VUIGNvbW1hbmQs U0ZfVyBpcyByYWlzZSBpbW1lZGlhdGVseSxhbmQgdGhlIE5SIHNlbmQgdG8gTEVSMiBpcyBsb3N0 IGZvciBzb21ldGhpbmcuDQoNCmluIGZpZ3VyZSAyLGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgcHJv Y2VkdXJlLg0KMS5MRVIxIGFuZCBMRVIyIGFyZSBib3RoIGluIE5PUk1BTCBzdGF0ZSBhbmQgZXhj aGFuZ2UgTlIgUERVLg0KMi50aGUgbG9ja291dCBjb21tYW5kIGlucHV0IGludG8gTEVSMSx0aGVu IExFUjEgc2VuZCBMT0NLIHRvIExFUjIgYW5kIHRyYW5zZmVyIHRvIFVBOkxPOkwsTEVSMiBzZW5k IE5SIHRvIExFUjEgYW5kIHRyYW5zZmVyIHRvIFVBOkxPOlIuDQozLnRoZSBjbGVhciBjb21tYW5k IGlucHV0IGludG8gTEVSMSxMRVIxIHRyYW5zZmVyIHRvIE5SIGFuZCBzZW5kIE5SIHRvIExFUjIs YnV0IHRoaXMgTlIgaXMgbG9zdCBmb3Igc29tZSB1bmtub3duIHJlYXNvbiwgYW5kIFNGX1cgaXMg cmFpc2VkIGltbWVkaWF0ZWx5IGluIExFUjEsc28gdGhhdCB0aGUgTlIgdGhhdCBzZW5kIGJ5IExF UjEgdG8gTEVSMiBpcyByZXBsYWNlZCBieSBTRl9XLg0KNC5ubyBOUiByZWFjaCBMRVIyLCBpZiB0 aGUgZXJyb3IgaXMgYmlkaXJlY3Rpb25hbCxMRVIyIHdpbGwgc2VuZCBTRl9XIHRvIExFUjEsb3Ig TlIgdG8gTEVSMiBpZiB1bmlkaXJlY3Rpb25hbC5idXQgaW4gYW55IGNvbmRpdGlvbixMRVIyIHdp bGwgc3RpbGwgaW4gVUE6TE86UiBzdGF0ZS50aGUgUFNDIGlzIGNyYXNoZWQuIA0KDQoNCnNvIGkg aGF2ZSAyIHBpZWNlcyBvZiBzdWdnZXN0aW9uDQoxLkxFUiBhbHdheXMgc2VuZCBoaXMgbG9jYWwg aGlnaGVzdCBwcmlvcml0eSB0byBpdCdzIHBlZXIuDQoyLkxFUiBhbHdheXMgYWNjZXB0IHRoZSBp bnB1dCBmcm9tIGhpcyBwZWVyIGJ5IFBTQyBQRFUuDQoNCg0KDQoNCg0KDQoNCg== --_72523b5d-f17b-407c-886b-6192bb5eebdf_-- From koike.yoshinori@lab.ntt.co.jp Thu Jan 10 04:13:56 2013 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 A037421F87CB for ; Thu, 10 Jan 2013 04:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 2QJozdwehaFM for ; Thu, 10 Jan 2013 04:13:55 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 096F421F8684 for ; Thu, 10 Jan 2013 04:13:54 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id r0ACDoiu003594; Thu, 10 Jan 2013 21:13:50 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B05DCE0153; Thu, 10 Jan 2013 21:13:50 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id A3FE3E0150; Thu, 10 Jan 2013 21:13:50 +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 r0ACDoBG023548; Thu, 10 Jan 2013 21:13:50 +0900 Message-ID: <50EEB105.9020600@lab.ntt.co.jp> Date: Thu, 10 Jan 2013 21:16:05 +0900 From: Yoshinori Koike User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Ball References: <20121212174431.2DCABB1E002@rfc-editor.org> <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> <50CB6508.10804@lab.ntt.co.jp> <20121217140541.GN4232@cisco.com> <20130104110030.GD14216@cisco.com> <50EE5D7E.2010901@lab.ntt.co.jp> In-Reply-To: <50EE5D7E.2010901@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 10 Jan 2013 12:13:56 -0000 Hi David, Sorry, there was mis-description. My understanding of G.8121 amd is that a position of data-plan loopback process is not restricted, as I wrote in my email on Dec 15, 2012. Best regards, Yoshinori (2013/01/10 15:19), Yoshinori Koike wrote: > Hi David, > > I'm terribly sorry for the delay in replying to you. Thank you very much > for the reply. See in line, please. > > (2013/01/04 20:00), David Ball wrote: >> Hi Yoshinori, >> >> Did you have any further thoughts on this? >> >> Thanks, >> >> >> David >> >> >> On Mon, Dec 17, 2012, David Ball wrote: >>> Hi Yoshinori, >>> >>> Thanks for your comments. >>> >>> With regards to your proposal, I am still a little unclear on the >>> intended relationship between the dataplane loopback point and the >>> MIP/MEP. Are these always on the same interface? If not, under what >>> conditions could they be on different interfaces? How is the location >>> of the dataplane loopback point determined? > > I think it depends on the maintenance model. In per-node model, it will > be impossible when MIP/MEP is placed on forwarding engine. However, I've > heard that in most of the implementation of routers, MIP/MEP is placed > on ingress-IF. Then there seems no issue that both MIP/MEP and > data-plane loopback point are located on the same ingress-IF. In > per-interface model, I think these are usually on the same interface, > although some implementation may/might implement on only one side of > interfaces(only ingress-IF). > > It seems ideal that data-plane loopback point is located before MIP/MEP > on ingress IF and/or after MIP/MEP on egress IF. > >>> To take a concrete example, suppose we have an interface with both a LSP >>> MEP and a PW MEP. OAM packets destined for the LSP MEP will have an LSP >>> label and a GAL, while OAM packets destined for the PW MEP will have an >>> LSP label and a PW label. Client data traffic will also have both an >>> LSP and a PW label. > > Correct me if I'm wrong, but I guess you assume that both a LSP MEP and > a PW MEP are placed on the same ingress-IF in a per-node model, which is > said to be the most typical model of IP/MPLS routers. > >>> Now, if either the LSP MEP or the PW MEP are put into a loopback mode, >>> all of the client data packets will be looped. But which OAM packets >>> are looped? >>> - If the LSP MEP is put into loopback mode, do the LSP OAM packets get >>> looped? I think so, since RFC6435 says that both data and OAM >>> packets are looped. >>> - If the LSP MEP is put into loopback mode, do the PW OAM packets get >>> looped? Again, I think so. >>> - If the PW MEP is put into loopback mode, do the PW OAM packets get >>> looped? I think yes, this is equivalent to the first case. >>> - If the PW MEP is put into loopback mode, do the LSP OAM packets get >>> looped. Since they do not have a PW label, I am not sure? I think >>> probably they shouldn't be, since there may be other PWs flowing >>> over >>> the same LSP, with different PW labels, right? > > My assumption was that if a data-plane loopback function is enabled > using the LSP MEP, a data-plane loopback point(s) (in my understanding, > a data-plane loopback sink and source process) in ingress-IF is enabled, > all the traffics that the data-plane loopback sink process has received > get looped through data-plane source process. > > Although the position of data-plane loopback process is located is not > detailed in G.8121 including G.8121 amd1 under AAP, it doesn't seem to > be considered only OAM packets get looped at the loopback process. In > addition, when a data-plane loopback function is enabled, I think OAM > functions should be disabled in principle. > >>> >>> Regarding ITU-T G.8121 Amd 1 and G.8121.2, the reason the dataplane >>> loopback process was removed from the MTDe figures in the last SG15 >>> meeting was because of this confusing sentence in RFC6435 - in other >>> words, it wasn't clear whether the MTDe function was the right place for >>> them so as to match the behaviour specified in the RFC. The intent of >>> G.8121.2 is to exactly match RFC6435 and the other relevant IETF RFCs. >>> >>> >>> As a result, in the current ITU-T G.8121/G.8121.2, the dataplane >>> loopback processes do not appear in any of the termination or adaptation >>> functions that are specified; so although the processes themselves are >>> defined, they are never applied. The question is, what is the correct >>> place to apply them in the ITU-T model so as to match the RFC? > > Thank you for the clarification. My understanding of G.8121 amd is that > a data-plane loopback point is located before MIP/MEP on ingress IF > and/or after MIP/MEP on egress IF and whether the type of data is > AI/CI/client depends on the implementation. > > Best regards, > > Yoshinori > >>> >>> >>> David >>> >>> >>> On Sat, Dec 15, 2012, Yoshinori Koike wrote: >>>> Hello David, >>>> >>>> I agree with original text is confusing and thank you for the >>>> proposal. However, I'm wondering if the proposed text is true and >>>> exactly reflect the intent explained in the notes. >>>> >>>> My suggestion is as follows: >>>> It should be noted that the data-plane loopback function itself is >>>> applied to data-plane loopback point which is different from >>>> MIP/MEP. >>>> >>>> Firstly, the description "the data-plane loopback function may be >>>> applied at MIPs/MEPs" doesn't seem to be true. >>>> >>>> In my understanding, data-plane loopback function can be >>>> set/enabled/disabled at MIP/MEP using a management system but not be >>>> applied to MIP/MEP itself. So I clarified this point in my proposal. >>>> >>>> One of the reason is that MIP/MEP is only involved in OAM packets. >>>> There seems no specification in any RFC, which describe that MIP/MEP >>>> could handle data packets which are not OAM packets . >>>> >>>> In G.8121 amd1, data-plane loopback sink and source are specified >>>> and according to Temporary Document(TD673R1<->R0/Plen) during last >>>> SG15 meeting, the data-plane loopback sink/source was removed from >>>> figures of MTDe_TT_Sk/So Process(Fig.9-14&16). I guess this might be >>>> to avoid a restriction of implementations, however it doesn't seem >>>> to make it possible to apply dataplane loopback point to MIP/MEP. In >>>> realty, if data-plane loopback function is enabled, for data-plane >>>> LB function there is no need to parse the packet except for >>>> outermost label value. >>>> >>>> Secondly, if you need to clarify the relationship between data-plane >>>> LB point at which data-plane LB function is conducted and MIP/MEP at >>>> which data-plane LB function is enabled/configured using management >>>> system, it seems enough just to say the two point usually resides on >>>> the same interface and clarify the binding of two points. I have no >>>> issue on this specification. However, just in case, it seems better >>>> to confirm if the change is ok in ITU-T joint interregnum meeting >>>> Jan 2013, because this is a matter of 8121 or/and G.8121.1. As a >>>> result, I didn't add related text in my proposal. >>>> >>>> I'm not an implementer, so I would appreciate it if you could >>>> correct me if I'm wrong. Thank you in advance. >>>> >>>> Best regards, >>>> >>>> Yoshinori >>>> >>>> >>>> (2012/12/13 3:17), Adrian Farrel wrote: >>>>> Hello, >>>>> >>>>> Authors of RFC 6435: I need to hear from you that you meant the >>>>> text that David >>>>> suggests. It is very clearly not what you wrote and, if you meant >>>>> something >>>>> different, it is clear why people are confused! >>>>> >>>>> Working group: I need to hear from you that you agree with David's >>>>> interpretation and support his proposed change. >>>>> >>>>> Only then will I try to work out whether this is a "typo" worthy of >>>>> an errata >>>>> report, or a technical change needing a revised RFC. >>>>> >>>>> Thanks, >>>>> Adrian >>>>> >>>>>> -----Original Message----- >>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>> Sent: 12 December 2012 17:45 >>>>>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>>>>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>>>>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; >>>>>> swallow@cisco.com; >>>>>> rcallon@juniper.net >>>>>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>>>>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>>>>> >>>>>> >>>>>> The following errata report has been submitted for RFC6435, >>>>>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>>>>> >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 >>>>>> >>>>>> -------------------------------------- >>>>>> Type: Editorial >>>>>> Reported by: David Ball >>>>>> >>>>>> Section: 4 (para 5) >>>>>> >>>>>> Original Text >>>>>> ------------- >>>>>> It should be noted that the data-plane loopback function itself is >>>>>> applied to >>>>> data- >>>>>> plane loopback points residing on different interfaces from >>>>>> MIPs/MEPs. >>>>>> >>>>>> Corrected Text >>>>>> -------------- >>>>>> It should be noted that the data-plane loopback function may be >>>>>> applied at >>>>>> MIPs/MEPs on different interfaces for different LSPs. >>>>>> >>>>>> Notes >>>>>> ----- >>>>>> The existing text has caused confusion (specifically, among >>>>>> experts in ITU-T >>>>> SG15 >>>>>> when discussing G.8121.2), in that it seems to suggest that the >>>>>> interface >>>>> where >>>>>> the MIP/MEP is located may be a different interface to the one >>>>>> where the >>>>>> loopback is applied. >>>>>> >>>>>> Having spoken with some of the original authors, it seems this was >>>>>> not the >>>>> intent >>>>>> of this sentence; the intent was to point out that as different >>>>>> LSPs would >>>>> have >>>>>> MIPs/MEPs on different interfaces, the corresponding loopback >>>>>> functions would >>>>>> also be applied on different interfaces. >>>>>> >>>>>> 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. >>>>>> >>>>>> -------------------------------------- >>>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>>>>> -------------------------------------- >>>>>> Title : MPLS Transport Profile Lock Instruct and >>>>>> Loopback >>>>> Functions >>>>>> Publication Date : November 2011 >>>>>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. >>>>>> Aggarwal, Ed., M. >>>>> Vigoureux, >>>>>> Ed., X. Dai, Ed. >>>>>> Category : PROPOSED STANDARD >>>>>> Source : Multiprotocol Label Switching >>>>>> Area : Routing >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> >>>> >>>> >>>> -- >>>> Yoshinori Koike >>>> koike.yoshinori@lab.ntt.co.jp >>>> >>> >>> -- >>> David Ball >>> >> > > -- Yoshinori Koike koike.yoshinori@lab.ntt.co.jp From lufang@cisco.com Thu Jan 10 05:17:08 2013 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 55C9521F84C2 for ; Thu, 10 Jan 2013 05:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 YUpGfLOzuclO for ; Thu, 10 Jan 2013 05:17:07 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C0B7B21F84D8 for ; Thu, 10 Jan 2013 05:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5006; q=dns/txt; s=iport; t=1357823826; x=1359033426; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=v06X9MHDO27DmyGkX96fuKziAGOS97Gqr5ImRdJdan4=; b=j5KX8kEOKRbtg25qgjdRC3bnq1uQ58ldT6ddZnmOK59zIFQMw9Iq/+Eh t4VM7b+TMQC2/9qbfEUfoIk6YCjt67XBvkmcAXWB1ZPev3f26snQRAXNN csRom3LA9ZmD+I2VXPJsKJ/j+EGfDLhp9VJfYJDl/ZGvSBCbrbpHqkpdS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAES+7lCtJV2b/2dsb2JhbABEg2y6ABZzgh4BAQEEAQEBNzQLDAIEAQgRAwEBAQsUCSIMCxQJCAIEAQ0FCAGIEAcFtFQEjGODV2EDplWCdYFvNQ X-IronPort-AV: E=Sophos;i="4.84,444,1355097600"; d="scan'208";a="160967217" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jan 2013 13:17:05 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0ADH5RJ002463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jan 2013 13:17:05 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 10 Jan 2013 07:17:05 -0600 From: "Luyuan Fang (lufang)" To: Mach Chen , Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AQHN7tQ3OjsZYuVDG0qI336KV6s40JhCnKyA Date: Thu, 10 Jan 2013 13:17:05 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931025E522@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.121.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <20B1394ACFE13C4B84206EDAD8DAA89E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 10 Jan 2013 13:17:08 -0000 Mach, Thanks. Consider it is done in the new version. Luyuan -----Original Message----- From: Mach Chen Date: Wednesday, January 9, 2013 5:45 PM To: Luyuan Fang , Loa Andersson , "mpls@ietf.org" Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework >Luyuan, > >Yes, I also intend to remove the term sections, please do that. > >Best regards, >Mach > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Luyuan Fang (lufang) >> Sent: Tuesday, January 08, 2013 11:50 PM >> To: Mach Chen; Loa Andersson; mpls@ietf.org >> Cc: draft-ietf-mpls-tp-security-framework@tools.ietf.org; >> mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] 2nd wg last call on >>draft-ietf-mpls-tp-security-framework >>=20 >> Hi Mach, >>=20 >> Thank you for your review and comments. >> We accept your comments on the terminologies section, will re-spin the >> draft when the wg last call has ended. >> One way to handle this is to remove the current terminology section as >>you >> suggested, and point to RFC5654/5921 for MPLS-TP terms, RFC5920 for >> security terms which are relevant to MPLS/GMPLS. >>=20 >> Thanks, >> Luyuan >>=20 >> -----Original Message----- >> From: Mach Chen >> Date: Monday, January 7, 2013 10:29 PM >> To: Loa Andersson , "mpls@ietf.org" >> Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org" >> , >> "mpls-chairs@tools.ietf.org" >> Subject: RE: [mpls] 2nd wg last call on >> draft-ietf-mpls-tp-security-framework >> Resent-From: >> Resent-To: , Luyuan Fang , >> , , , >> , >> Resent-Date: Monday, January 7, 2013 10:29 PM >>=20 >> >Hi, >> > >> >I have read the latest version of the draft, I am OK with the content >>and >> >support to move it forward. >> > >> >One comment about the Terminology section, it lists only partial >> >terminologies used in the document and some of the terminologies(e.g., >> >MEP, MIP) are actually not used in the draft. It's better that the >> >authors could review the draft and then add all(or most of ) the major >> >terminologies and remove the useless terminologies. Or the simplest way >> >is just to remove the whole Terminologies Section :-). >> > >> >Best regards, >> >Mach >> > >> >> -----Original Message----- >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>Of >> >>Loa >> >> Andersson >> >> Sent: Monday, January 07, 2013 6:22 PM >> >> To: mpls@ietf.org >> >> Cc: draft-ietf-mpls-tp-security-framework@tools.ietf.org; >> >> mpls-chairs@tools.ietf.org >> >> Subject: [mpls] 2nd wg last call on >> >>draft-ietf-mpls-tp-security-framework >> >> >> >> Working Group, >> >> >> >> This is to start a working group last call on >> >> draft-ietf-mpls-tp-security-framework-06. >> >> >> >> This is the second time this document is working group last called, >> >> three has been a major update of the document since last time. >> >> >> >> Please find a diff: >> >> >>=20 >>>>http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-tp-security-framewor= k- >>>>05 >> >>&diff >> >>=20 >>type=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-security-framework= -06 >> >> >> >> 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. >> >> >> >> There are no IPR claims against this draft. >> >> >> >> All the co-authors has stated that they are not ware of any IPRs. >> >> >> >> This working group last call will end on January 18, 2013. >> >> >> >> /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 >>=20 >> _______________________________________________ >> 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 scott.mansfield@ericsson.com Thu Jan 10 05:24:32 2013 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 C608A21F8694 for ; Thu, 10 Jan 2013 05:24:31 -0800 (PST) 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, 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 PUu2SkxVb6XU for ; Thu, 10 Jan 2013 05:24:30 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 49DB921F85E0 for ; Thu, 10 Jan 2013 05:24:30 -0800 (PST) Received: from EUSAAHC006.ericsson.se ([147.117.188.90]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r0ADbYb3015534; Thu, 10 Jan 2013 07:39:19 -0600 Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Thu, 10 Jan 2013 08:23:52 -0500 From: Scott Mansfield To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Loa Andersson" Thread-Topic: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AQHN7MDVne6Kvs6aKkq/ezX8IaKTQ5hB/dWAgAAoqLCAAGtSwA== Date: Thu, 10 Jan 2013 13:23:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 10 Jan 2013 13:24:32 -0000 +1 (disclaimer: co-editor of the document) -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spr= echer, Nurit (NSN - IL/Hod HaSharon) Sent: Thursday, January 10, 2013 2:00 AM To: ext Loa Andersson Cc: mpls@ietf.org Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framewo= rk Support, - Nurit -----Original Message----- From: Loa Andersson Date: Monday, January 7, 2013 2:21 AM To: "mpls@ietf.org" Cc: "mpls-chairs@tools.ietf.org" , Martin Vigou= reux , "draft-ietf-mpls-tp-security-framework@tools.ietf.org" Subject: 2nd wg last call on draft-ietf-mpls-tp-security-framework Resent-From: Resent-To: , Luyuan Fang , , , , ,= Resent-Date: Monday, January 7, 2013 2:22 AM >Working Group, > >This is to start a working group last call on=20 >draft-ietf-mpls-tp-security-framework-06. > >This is the second time this document is working group last called,=20 >three has been a major update of the document since last time. > >Please find a diff: >http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-tp-security-framework- 05& >difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-security-framew= ork -06 > >Please send your comments to the mpls working group mailing list=20 >(mpls@ietf.org). > >Please send both technical comments, and if you are happy with the=20 >document as is also indications of support. > >There are no IPR claims against this draft. > >All the co-authors has stated that they are not ware of any IPRs. > >This working group last call will end on January 18, 2013. > >/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 internet-drafts@ietf.org Thu Jan 10 06:26:20 2013 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 0A10821F885C; Thu, 10 Jan 2013 06:26:20 -0800 (PST) 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 akh+eZMgYavI; Thu, 10 Jan 2013 06:26:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6470721F8833; Thu, 10 Jan 2013 06:26:19 -0800 (PST) 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.37 Message-ID: <20130110142618.9183.29944.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2013 06:26:18 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-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, 10 Jan 2013 14:26:20 -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 : Configuration of Pro-Active Operations, Administration, = and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP= Ping Author(s) : Elisa Bellagamba Loa Andersson Pontus Skoldstrom Dave Ward John Drake Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-05.txt Pages : 22 Date : 2013-01-10 Abstract: This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the LSP-Ping protocol. 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-lsp-ping-mpls-tp-oam-conf There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-mpls-tp-oam-con= f-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Thu Jan 10 08:03:28 2013 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 E0D7F21F8925 for ; Thu, 10 Jan 2013 08:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045, 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 FPV0CE2G07we for ; Thu, 10 Jan 2013 08:03:26 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5F921F874F for ; Thu, 10 Jan 2013 08:03:25 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0AG2urX022806; Thu, 10 Jan 2013 16:02:56 GMT Received: from 950129200 (089144192150.atnat0001.highway.a1.net [89.144.192.150]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0AG2q8S022770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jan 2013 16:02:53 GMT From: "Adrian Farrel" To: "'VIGOUREUX, MARTIN \(MARTIN\)'" , "'Sami Boutros \(sboutros\)'" References: In-Reply-To: Date: Thu, 10 Jan 2013 16:02:53 -0000 Message-ID: <007201cdef4b$f4543f40$dcfcbdc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01CDEF4B.F456B040" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKJyV6+bHSBwG2j2NRvssT27Ly7TZbLBLbw Content-Language: en-gb Cc: mpls@ietf.org, dai.xuehui@zte.com.cn, "'Siva Sivabalan \(msiva\)'" , rcallon@juniper.net, raggarwa_1@yahoo.com, "'David Ball -X \(daviball - Ensoft Ltd at Cisco\)'" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 10 Jan 2013 16:03:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0073_01CDEF4B.F456B040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin, =20 Could you have a stab at drafting what you consider to be the correct = text? =20 A =20 From: VIGOUREUX, MARTIN (MARTIN) = [mailto:martin.vigoureux@alcatel-lucent.com]=20 Sent: 09 January 2013 20:30 To: Sami Boutros (sboutros) Cc: adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco); = Siva Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart = Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org Subject: RE: [Editorial Errata Reported] RFC6435 (3429) =20 Sami, Thanks. Yet, I am not sure David's interpretation and mine exactly = match. David, correct me if I am wrong. For me it says that we can do loopback = on different interfaces (for different LSPs) but implies that there is a = mip/mep for that lsp on that interface, while my interpretation is that the = presence of a mip/mep for that lsp on that interface is not needed. -m _____ =20 De : Sami Boutros (sboutros) Envoy=E9 : 09/01/2013 19:00 =C0 : VIGOUREUX, MARTIN (MARTIN) Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at = Cisco); Siva Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart = Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org Objet : Re: [Editorial Errata Reported] RFC6435 (3429) I agree with Martin, the text proposed by David describe more accurately = what we meant. Thanks, Sami On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > Adrian, David, >=20 > what I think we meant here was that a loop-back function could be done = on an interface regardless of the presence of a MIP/MEP on that interface. = Yet, I have to admit that MIP and MEP are used in Section 4 of RFC6435, thus surely = causing confusion. >=20 > I'd welcome the views/souvenirs of my co-authors. >=20 > -m >=20 > Le 12/12/2012 19:17, Adrian Farrel a =E9crit : >> Hello, >>=20 >> Authors of RFC 6435: I need to hear from you that you meant the text = that David >> suggests. It is very clearly not what you wrote and, if you meant = something >> different, it is clear why people are confused! >>=20 >> Working group: I need to hear from you that you agree with David's >> interpretation and support his proposed change. >>=20 >> Only then will I try to work out whether this is a "typo" worthy of = an errata >> report, or a technical change needing a revised RFC. >>=20 >> Thanks, >> Adrian >>=20 >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: 12 December 2012 17:45 >>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; = swallow@cisco.com; >>> rcallon@juniper.net >>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>>=20 >>>=20 >>> The following errata report has been submitted for RFC6435, >>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435 = &eid=3D3429 >>>=20 >>> -------------------------------------- >>> Type: Editorial >>> Reported by: David Ball >>>=20 >>> Section: 4 (para 5) >>>=20 >>> Original Text >>> ------------- >>> It should be noted that the data-plane loopback function itself is = applied to >> data- >>> plane loopback points residing on different interfaces from = MIPs/MEPs. >>>=20 >>> Corrected Text >>> -------------- >>> It should be noted that the data-plane loopback function may be = applied at >>> MIPs/MEPs on different interfaces for different LSPs. >>>=20 >>> Notes >>> ----- >>> The existing text has caused confusion (specifically, among experts = in ITU-T >> SG15 >>> when discussing G.8121.2), in that it seems to suggest that the = interface >> where >>> the MIP/MEP is located may be a different interface to the one where = the >>> loopback is applied. >>>=20 >>> Having spoken with some of the original authors, it seems this was = not the >> intent >>> of this sentence; the intent was to point out that as different LSPs = would >> have >>> MIPs/MEPs on different interfaces, the corresponding loopback = functions would >>> also be applied on different interfaces. >>>=20 >>> 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 >>> -------------------------------------- >>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>> -------------------------------------- >>> Title : MPLS Transport Profile Lock Instruct and = Loopback >> Functions >>> Publication Date : November 2011 >>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. = Aggarwal, Ed., M. >> Vigoureux, >>> Ed., X. Dai, Ed. >>> Category : PROPOSED STANDARD >>> Source : Multiprotocol Label Switching >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >>=20 >>=20 ------=_NextPart_000_0073_01CDEF4B.F456B040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Martin,

 

Could you have a stab at = drafting what you consider to be the correct = text?

 

A

 

From: VIGOUREUX, MARTIN = (MARTIN) [mailto:martin.vigoureux@alcatel-lucent.com]
Sent: = 09 January 2013 20:30
To: Sami Boutros = (sboutros)
Cc: adrian@olddog.co.uk; David Ball -X (daviball - = Ensoft Ltd at Cisco); Siva Sivabalan (msiva); raggarwa_1@yahoo.com; = dai.xuehui@zte.com.cn; Stewart Bryant (stbryant); loa@pi.nu; George = Swallow (swallow); rcallon@juniper.net; mpls@ietf.org
Subject: = RE: [Editorial Errata Reported] RFC6435 = (3429)

 

Sami,

Thanks. Yet, I am not sure = David's interpretation and mine exactly match.
David, correct me if I = am wrong. For me it says that we can do loopback on different interfaces = (for different LSPs) but implies that there is a mip/mep for that lsp on = that interface, while my interpretation is that the presence of a = mip/mep for that lsp on that interface is not = needed.

-m

De : Sami Boutros (sboutros)
Envoy=E9 : 09/01/2013 19:00
=C0 : VIGOUREUX, MARTIN (MARTIN)
Cc : adrian@olddog.co.uk; David Ball -X = (daviball - Ensoft Ltd at Cisco); Siva Sivabalan (msiva); = raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant); = loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; = mpls@ietf.org
Objet : Re: [Editorial Errata Reported] RFC6435 = (3429)

I = agree with Martin, the text proposed by David describe more accurately = what we meant.

Thanks,

Sami
On Jan 9, 2013, at 6:18 AM, = Martin Vigoureux wrote:

> Adrian, David,
>
> what = I think we meant here was that a loop-back function could be done on an = interface regardless of the presence of a MIP/MEP on that interface. = Yet, I have to admit that MIP and MEP are used in Section 4 of RFC6435, = thus surely causing confusion.
>
> I'd welcome the = views/souvenirs of my co-authors.
>
> -m
>
> = Le 12/12/2012 19:17, Adrian Farrel a =E9crit :
>> = Hello,
>>
>> Authors of RFC 6435: I need to hear from = you that you meant the text that David
>> suggests. It is very = clearly not what you wrote and, if you meant something
>> = different, it is clear why people are confused!
>>
>> = Working group: I need to hear from you that you agree with = David's
>> interpretation and support his proposed = change.
>>
>> Only then will I try to work out = whether this is a "typo" worthy of an errata
>> = report, or a technical change needing a revised RFC.
>> =
>> Thanks,
>> Adrian
>>
>>> = -----Original Message-----
>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.or= g]
>>> Sent: 12 December 2012 17:45
>>> To: = sboutros@cisco.com; msiva@cisco.com; = raggarwa_1@yahoo.com;
>>> = martin.vigoureux@alcatel-lucent.com; = dai.xuehui@zte.com.cn;
>>> stbryant@cisco.com; = adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com;
>>> = rcallon@juniper.net
>>> Cc: daviball@cisco.com; = mpls@ietf.org; rfc-editor@rfc-editor.org
>>> Subject: = [Editorial Errata Reported] RFC6435 (3429)
>>> =
>>>
>>> The following errata report has been = submitted for RFC6435,
>>> "MPLS Transport Profile Lock = Instruct and Loopback Functions".
>>>
>>> = --------------------------------------
>>> You may review = the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435&eid=3D34= 29
>>>
>>> = --------------------------------------
>>> Type: = Editorial
>>> Reported by: David = Ball<daviball@cisco.com>
>>>
>>> Section: = 4 (para 5)
>>>
>>> Original = Text
>>> -------------
>>> It should be noted = that the data-plane loopback function itself is applied to
>> = data-
>>> plane loopback points residing on different = interfaces from MIPs/MEPs.
>>>
>>> Corrected = Text
>>> --------------
>>> It should be noted = that the data-plane loopback function may be applied at
>>> = MIPs/MEPs on different interfaces for different LSPs.
>>> =
>>> Notes
>>> -----
>>> The = existing text has caused confusion (specifically, among experts in = ITU-T
>> SG15
>>> when discussing G.8121.2), in = that it seems to suggest that the interface
>> = where
>>> the MIP/MEP is located may be a different = interface to the one where the
>>> loopback is = applied.
>>>
>>> Having spoken with some of the = original authors, it seems this was not the
>> = intent
>>> of this sentence; the intent was to point out = that as different LSPs would
>> have
>>> MIPs/MEPs = on different interfaces, the corresponding loopback functions = would
>>> also be applied on different = interfaces.
>>>
>>> = 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.
>>> =
>>> --------------------------------------
>>> = RFC6435 (draft-ietf-mpls-tp-li-lb-08)
>>> = --------------------------------------
>>> = Title           &n= bsp;   : MPLS Transport Profile Lock Instruct and = Loopback
>> Functions
>>> Publication = Date    : November 2011
>>> = Author(s)           : = S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M.
>> = Vigoureux,
>>> Ed., X. Dai, Ed.
>>> = Category           = ; : PROPOSED STANDARD
>>> = Source           &= nbsp;  : Multiprotocol Label Switching
>>> = Area           &nb= sp;    : Routing
>>> = Stream           &= nbsp;  : IETF
>>> Verifying = Party     : IESG
>>
>> =

------=_NextPart_000_0073_01CDEF4B.F456B040-- From adrian@olddog.co.uk Thu Jan 10 08:18:33 2013 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 DA0A821F89CB for ; Thu, 10 Jan 2013 08:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_15=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 HkvjwFfbtSyS for ; Thu, 10 Jan 2013 08:18:33 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 135F721F89C0 for ; Thu, 10 Jan 2013 08:18:30 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0AGIPtD000429; Thu, 10 Jan 2013 16:18:25 GMT Received: from 950129200 (089144192150.atnat0001.highway.a1.net [89.144.192.150]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0AGINMT000398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jan 2013 16:18:24 GMT From: "Adrian Farrel" To: "'t.petch'" , "'Loa Andersson'" , References: <4FA01005.1080002@pi.nu> <030801cded90$01ab75e0$4001a8c0@gateway.2wire.net> In-Reply-To: <030801cded90$01ab75e0$4001a8c0@gateway.2wire.net> Date: Thu, 10 Jan 2013 16:18:24 -0000 Message-ID: <00a601cdef4e$1e878d60$5b96a820$@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: AQLYW/765bolXqfmUmRErZjWcoSkyQHlkQrplh62miA= Content-Language: en-gb Subject: Re: [mpls] RFC6639 doubts 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, 10 Jan 2013 16:18:34 -0000 Yes, looks like a sloppy block-copy from the previous paragraph. I'm shocked that no-one noticed before ;-) An editorial errata report would be in order if you have the energy, but I don't think it impacts the understanding of the document, so I wouldn't lose any sleep over it. Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > t.petch > Sent: 08 January 2013 11:05 > To: Loa Andersson; mpls@ietf.org > Subject: [mpls] RFC6639 doubts > > RFC6639 s4.2.9 tells me that > > " The mplsOutSegmentPerfTable [RFC3813] contains statistical > information (total packets received, total errored packets received, > total packets discarded, discontinuity time) for outgoing MPLS > segments from an LSR." > > whereas RFC3813 itself says > > "This table contains statistical information about > outgoing segments from an LSR. " > and goes on to refer to octets sent, packets sent, packets that could > not be sent as well as packets discarded and discontinuity time. > > Um; RFC6639 looks wrong, but is it worth the administrative effort of an > Erratum? I will raise one if you want me to. > > Tom Petch > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From wyaacov@gmail.com Thu Jan 10 09:12:10 2013 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 ED21121F84F0 for ; Thu, 10 Jan 2013 09:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3, 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 aNvCclpYEYYj for ; Thu, 10 Jan 2013 09:12:09 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 16D0021F84DA for ; Thu, 10 Jan 2013 09:12:08 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hn14so480944wib.3 for ; Thu, 10 Jan 2013 09:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l45gbqBEAEDBFigCEXpbafpN42ydnuvd3hkXOOMFA9w=; b=QsMIJcR6i4E+3IuLbwpWEehBD/dUTpX36r3htVTrsSqiXza76EODcKIQ4mpI/aw8vU D004djRbkbB7ATvRMoqOhk5G/ARl5YXJS10hSZ1qLIPDJlmUlgGWG1pQZdgHwA+FFABj ZbtGXsJ/hCK6WATsu20ZEVs8GyfVLGYcUmA0jsThqker21vFrDPK5ErMGZoPM8EhfwbE UOdUZJawSy+rYNtvrHEPxRVdjVx7cmTbFfOzlYJfpmz+/CFVpaw7IXSmBsfFFdXOJQa6 W2YgqPmzCFYGOb+TLYYz2d0KJX1zldQWMr71WhkseX2HlpRo3GjjupDL9THpLZb1xvR8 uYnQ== MIME-Version: 1.0 Received: by 10.194.7.104 with SMTP id i8mr115739331wja.27.1357837928089; Thu, 10 Jan 2013 09:12:08 -0800 (PST) Received: by 10.194.90.243 with HTTP; Thu, 10 Jan 2013 09:12:08 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Jan 2013 19:12:08 +0200 Message-ID: From: Yaacov Weingarten To: =?UTF-8?B?5pu+5bO75rOi?= Content-Type: multipart/alternative; boundary=047d7b5d43a45dca4004d2f2475e Cc: mpls@ietf.org, yaacov.weingarten@nsn.com Subject: Re: [mpls] in some scenario RFC6378 can not protect the traffic, so much as take the PSC state to crash. 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, 10 Jan 2013 17:12:11 -0000 --047d7b5d43a45dca4004d2f2475e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Junbo, hi Thank you for your scenarios. However, both of these scenarios are addressed by the text of RFC6378. 1. Regarding Scenario #1: The second paragraph of Section 4.3.3.1 states - "When the LER transitions into the Normal state, the PSC Control Process SHALL check the persistent state of the local triggers to decide if it should further transition into a new state...." Meaning that in your scenario, after receiving the Clear, before transitioning into Normal State, LER-1 should have checked the status of the other triggers and decided, based upon the still active SF-W to transition into Protecting Failure state, transmitting a SF(1,1) message. As to the reaction of LER-2, see below. 2. Regarding Scenario #2: The second paragraph of Section 4.3.3 states -"When a LER is in a remote state, i.e. state transition in reaction to a PSC message recieved from the far-end LER, and receives a new PSC message from the far-end LER that indicates a contradictory state, e.g. in remote Unavailable state receiving a remote FS(1,1) message, then the PSC Control Logic SHALL reevaluate all inputs (both the local input and the remote message) as if the LER is in the Normal state." Meaning that in both the continuation of the previous scenario as well as in your scenario, LER-2 should react to the remote SF message as if in Normal and transition into Remote Protecting Failure State. Therefore, I contend that neither scenario will cause PSC to crash. On Thu, Jan 10, 2013 at 11:10 AM, =E6=9B=BE=E5=B3=BB=E6=B3=A2 wrote: > > > (if the figure can not display normally,please see the attach file.thanks= .) > > > When in multi fault/priority condition scenario,RFC6378 can not protect > the traffic so much as take the PSC state to crash.consider the following= 2 > scenario. > > +------+ +------+ > | LER1 | | LER2 | > +---+--+ +---+--+ > +----------NR------------------->| > | | > | | > |<---------NR--------------------+ > local lockout | | > input | | > +-----------LOCK---------------->| > | | > | | > |<---------NR--------------------+ > | | > unidirection | | > SF_W raise | | > +-------------LOCK-------------->| > | | > | | > |<---------NR--------------------+ > | | > local clear | | > input | | > +------------NR----------------->| > | | > | | > |<-----------NR------------------+ > | | > > > figure 1: unidirection SF_W raise after local lockout input > > in figure 1,consider the following procedure > 1.LER1 and LER2 are both in NORMAL state and exchange NR PDU. > 2.the lockout command input into LER1,then LER1 send LOCK to LER2,LER2 > send NR to LER1. > 3.a unidirection SF_W is raised in LER1,according RFC6378, LER1 still sen= d > LOCK to LER2,LER2 send NR to LER1. > 4.the clear command input into LER1,according RFC6378,LER1 will send NR t= o > LER2,LER2 still send NR to LER1. so traffic is broken. > > > > > +------+ +------+ > | LER1 | | LER2 | > +---+--+ +---+--+ > N +----------NR------------------->| N > | | > | | > |<---------NR--------------------+ > local lockout input | | > | | > UA:LO:L +-----------LOCK---------------->| > | |UA:LO:R > | | > |<---------NR--------------------+ > local clear input | | > | | > | | > N +-------NR--------------.........| > | | > SF_W raise | this nr is lost for smth. | > | and SF_W is raised. | > | | > +----------SF_W----------------->|always in > UA:LO:R > | | > | | > | | > |<-----------SF_W----------------+ > | | > | | > > figure 2: after clear a local LOCKOUT command,SF_W is raise > immediately,and the NR send to LER2 is lost for something. > > in figure 2,consider the following procedure. > 1.LER1 and LER2 are both in NORMAL state and exchange NR PDU. > 2.the lockout command input into LER1,then LER1 send LOCK to LER2 and > transfer to UA:LO:L,LER2 send NR to LER1 and transfer to UA:LO:R. > 3.the clear command input into LER1,LER1 transfer to NR and send NR to > LER2,but this NR is lost for some unknown reason, and SF_W is raised > immediately in LER1,so that the NR that send by LER1 to LER2 is replaced = by > SF_W. > 4.no NR reach LER2, if the error is bidirectional,LER2 will send SF_W to > LER1,or NR to LER2 if unidirectional.but in any condition,LER2 will still > in UA:LO:R state.the PSC is crashed. > > > so i have 2 pieces of suggestion > 1.LER always send his local highest priority to it's peer. > 2.LER always accept the input from his peer by PSC PDU. > > > > > > > Best Regards! > > > > Junbo Zeng(BoBo) > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --047d7b5d43a45dca4004d2f2475e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SnVuYm8sIGhpPGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT5UaGFuayB5 b3UgZm9yIHlvdXIgc2NlbmFyaW9zLiDCoEhvd2V2ZXIsIGJvdGggb2YgdGhlc2Ugc2NlbmFyaW9z IGFyZSBhZGRyZXNzZWQgYnkgdGhlIHRleHQgb2YgUkZDNjM3OC48L2Rpdj48ZGl2IHN0eWxlPjxi cj48L2Rpdj48ZGl2IHN0eWxlPjEuIFJlZ2FyZGluZyBTY2VuYXJpbyAjMTogVGhlIHNlY29uZCBw YXJhZ3JhcGggb2YgU2VjdGlvbiA0LjMuMy4xIHN0YXRlcyAtICZxdW90O1doZW4gdGhlIExFUiB0 cmFuc2l0aW9ucyBpbnRvIHRoZSBOb3JtYWwgc3RhdGUsIHRoZSBQU0MgQ29udHJvbMKgUHJvY2Vz cyBTSEFMTCBjaGVjayB0aGUgcGVyc2lzdGVudCBzdGF0ZSBvZiB0aGUgbG9jYWwgdHJpZ2dlcnMg dG/CoGRlY2lkZSBpZiBpdCBzaG91bGQgZnVydGhlciB0cmFuc2l0aW9uIGludG8gYSBuZXcgc3Rh dGUuLi4uJnF1b3Q7IE1lYW5pbmcgdGhhdCBpbiB5b3VyIHNjZW5hcmlvLCBhZnRlciByZWNlaXZp bmcgdGhlIENsZWFyLCBiZWZvcmUgdHJhbnNpdGlvbmluZyBpbnRvIE5vcm1hbCBTdGF0ZSwgTEVS LTEgc2hvdWxkIGhhdmUgY2hlY2tlZCB0aGUgc3RhdHVzIG9mIHRoZSBvdGhlciB0cmlnZ2VycyBh bmQgZGVjaWRlZCwgYmFzZWQgdXBvbiB0aGUgc3RpbGwgYWN0aXZlIFNGLVcgdG8gdHJhbnNpdGlv biBpbnRvIFByb3RlY3RpbmcgRmFpbHVyZSBzdGF0ZSwgdHJhbnNtaXR0aW5nIGEgU0YoMSwxKSBt ZXNzYWdlLiBBcyB0byB0aGUgcmVhY3Rpb24gb2YgTEVSLTIsIHNlZSBiZWxvdy48L2Rpdj4KPGRp diBzdHlsZT48YnI+PC9kaXY+PGRpdiBzdHlsZT4yLiBSZWdhcmRpbmcgU2NlbmFyaW8gIzI6IFRo ZSBzZWNvbmQgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4zLjMgc3RhdGVzIC0mcXVvdDtXaGVuIGEg TEVSIGlzIGluIGEgcmVtb3RlIHN0YXRlLCBpLmUuIHN0YXRlIHRyYW5zaXRpb24gaW4gcmVhY3Rp b24gdG/CoGEgUFNDIG1lc3NhZ2UgcmVjaWV2ZWQgZnJvbSB0aGUgZmFyLWVuZCBMRVIsIGFuZCBy ZWNlaXZlcyBhIG5ldyBQU0PCoG1lc3NhZ2UgZnJvbSB0aGUgZmFyLWVuZCBMRVIgdGhhdCBpbmRp Y2F0ZXMgYSBjb250cmFkaWN0b3J5IHN0YXRlLMKgZS5nLiBpbiByZW1vdGUgVW5hdmFpbGFibGUg c3RhdGUgcmVjZWl2aW5nIGEgcmVtb3RlIEZTKDEsMSkgbWVzc2FnZSzCoHRoZW4gdGhlIFBTQyBD b250cm9sIExvZ2ljIFNIQUxMIHJlZXZhbHVhdGUgYWxsIGlucHV0cyAoYm90aCB0aGXCoGxvY2Fs IGlucHV0IGFuZCB0aGUgcmVtb3RlIG1lc3NhZ2UpIGFzIGlmIHRoZSBMRVIgaXMgaW4gdGhlIE5v cm1hbMKgc3RhdGUuJnF1b3Q7IMKgTWVhbmluZyB0aGF0IGluIGJvdGggdGhlIGNvbnRpbnVhdGlv biBvZiB0aGUgcHJldmlvdXMgc2NlbmFyaW8gYXMgd2VsbCBhcyBpbiB5b3VyIHNjZW5hcmlvLCBM RVItMiBzaG91bGQgcmVhY3QgdG8gdGhlIHJlbW90ZSBTRiBtZXNzYWdlIGFzIGlmIGluIE5vcm1h bCBhbmQgdHJhbnNpdGlvbiBpbnRvIFJlbW90ZSBQcm90ZWN0aW5nIEZhaWx1cmUgU3RhdGUuPC9k aXY+CjxkaXYgc3R5bGU+PGJyPjwvZGl2PjxkaXYgc3R5bGU+VGhlcmVmb3JlLCBJIGNvbnRlbmQg dGhhdCBuZWl0aGVyIHNjZW5hcmlvIHdpbGwgY2F1c2UgUFNDIHRvwqBjcmFzaC48L2Rpdj48ZGl2 IHN0eWxlPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxicj48ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+T24gVGh1LCBKYW4gMTAsIDIwMTMgYXQgMTE6MTAgQU0sIOabvuWz u+azoiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzp6amJkYW1vQGhvdG1haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+empiZGFtb0Bob3RtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3 cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxi cj4KPGJyPgooaWYgdGhlIGZpZ3VyZSBjYW4gbm90IGRpc3BsYXkgbm9ybWFsbHkscGxlYXNlIHNl ZSB0aGUgYXR0YWNoIGZpbGUudGhhbmtzLik8YnI+Cjxicj4KPGJyPgpXaGVuIGluIG11bHRpIGZh dWx0L3ByaW9yaXR5IGNvbmRpdGlvbiBzY2VuYXJpbyxSRkM2Mzc4IGNhbiBub3QgcHJvdGVjdCB0 aGUgdHJhZmZpYyBzbyBtdWNoIGFzIHRha2UgdGhlIFBTQyBzdGF0ZSB0byBjcmFzaC5jb25zaWRl ciB0aGUgZm9sbG93aW5nIDIgc2NlbmFyaW8uPGJyPgo8YnI+CsKgwqDCoMKgwqDCoMKgwqDCoMKg ICstLS0tLS0rwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg ICstLS0tLS0rPGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IExFUjEgfMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IExFUjIgfDxicj4KwqDCoMKgwqDC oMKgwqDCoMKgwqAgKy0tLSstLSvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgKy0tLSstLSs8YnI+CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0t LS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4KwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8Jmx0Oy0tLS0tLS0tLU5SLS0t LS0tLS0tLS0tLS0tLS0tLS0rPGJyPgrCoGxvY2FsIGxvY2tvdXQgfMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8YnI+CsKgIGlu cHV0wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8YnI+CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgKy0tLS0tLS0tLS0tTE9DSy0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4KwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8Jmx0Oy0tLS0tLS0t LU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rPGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCB8PGJyPgrCoHVuaWRpcmVjdGlvbsKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8PGJyPgrCoFNGX1cgcmFpc2XC oMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHw8YnI+CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tLS0tLS0t LS0tLS1MT0NLLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfDxi cj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8Jmx0Oy0tLS0tLS0tLU5SLS0tLS0tLS0t LS0tLS0tLS0tLS0rPGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8PGJy PgrCoGxvY2FsIGNsZWFywqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfDxicj4KwqAgaW5wdXTCoMKgwqDCoMKgwqDCoCB8 wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tLS0tLS0tLS0tTlIt LS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCB8PGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8PGJyPgrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwmbHQ7LS0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0t LS0tLSs8YnI+CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8YnI+CsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8YnI+Cjxicj4KwqDCoMKgIMKgwqDCoCDCoMKgwqAgZmln dXJlIDE6IHVuaWRpcmVjdGlvbiBTRl9XIHJhaXNlIGFmdGVyIGxvY2FsIGxvY2tvdXQgaW5wdXQ8 YnI+Cjxicj4KaW4gZmlndXJlIDEsY29uc2lkZXIgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmU8YnI+ CjEuTEVSMSBhbmQgTEVSMiBhcmUgYm90aCBpbiBOT1JNQUwgc3RhdGUgYW5kIGV4Y2hhbmdlIE5S IFBEVS48YnI+CjIudGhlIGxvY2tvdXQgY29tbWFuZCBpbnB1dCBpbnRvIExFUjEsdGhlbiBMRVIx IHNlbmQgTE9DSyB0byBMRVIyLExFUjIgc2VuZCBOUiB0byBMRVIxLjxicj4KMy5hIHVuaWRpcmVj dGlvbiBTRl9XIGlzIHJhaXNlZCBpbiBMRVIxLGFjY29yZGluZyBSRkM2Mzc4LCBMRVIxIHN0aWxs IHNlbmQgTE9DSyB0byBMRVIyLExFUjIgc2VuZCBOUiB0byBMRVIxLjxicj4KNC50aGUgY2xlYXIg Y29tbWFuZCBpbnB1dCBpbnRvIExFUjEsYWNjb3JkaW5nIFJGQzYzNzgsTEVSMSB3aWxsIHNlbmQg TlIgdG8gTEVSMixMRVIyIHN0aWxsIHNlbmQgTlIgdG8gTEVSMS4gc28gdHJhZmZpYyBpcyBicm9r ZW4uPGJyPgo8YnI+Cjxicj4KPGJyPgo8YnI+CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCArLS0tLS0tK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCArLS0tLS0tKzxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHwgTEVSMSB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHwgTEVSMiB8PGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgKy0tLSstLSvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgKy0tLSstLSs8YnI+CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgTsKgwqDCoCArLS0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8wqDC oMKgwqDCoMKgIE48YnI+CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8PGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCZsdDstLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0t LS0tKzxicj4KwqDCoMKgwqAgbG9jYWwgbG9ja291dCBpbnB1dMKgIHzCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8PGJyPgrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfDxi cj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBVQTpMTzpMICstLS0tLS0tLS0t LUxPQ0stLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8VUE6TE86Ujxicj4KwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8YnI+CsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwmbHQ7LS0tLS0t LS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tLSs8YnI+CsKgwqDCoMKgwqDCoCBsb2NhbCBjbGVhciBp bnB1dMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB8PGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8YnI+CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIE7CoCArLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0uLi4uLi4u Li58PGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgU0ZfVyByYWlzZcKgIHwg dGhpcyBuciBpcyBsb3N0IGZvciBzbXRoLsKgwqDCoMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCBhbmQgU0ZfVyBpcyByYWlzZWQu wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8PGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tLS0tLS0tLS1TRl9XLS0tLS0tLS0tLS0t LS0tLS0mZ3Q7fGFsd2F5cyBpbiBVQTpMTzpSPGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8YnI+CsKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8PGJyPgrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8Jmx0Oy0tLS0t LS0tLS0tU0ZfVy0tLS0tLS0tLS0tLS0tLS0rPGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfDxicj4KwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8YnI+CsKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPGJyPgrCoMKgwqDCoMKgIGZp Z3VyZSAyOiBhZnRlciBjbGVhciBhIGxvY2FsIExPQ0tPVVQgY29tbWFuZCxTRl9XIGlzIHJhaXNl IGltbWVkaWF0ZWx5LGFuZCB0aGUgTlIgc2VuZCB0byBMRVIyIGlzIGxvc3QgZm9yIHNvbWV0aGlu Zy48YnI+Cjxicj4KaW4gZmlndXJlIDIsY29uc2lkZXIgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmUu PGJyPgoxLkxFUjEgYW5kIExFUjIgYXJlIGJvdGggaW4gTk9STUFMIHN0YXRlIGFuZCBleGNoYW5n ZSBOUiBQRFUuPGJyPgoyLnRoZSBsb2Nrb3V0IGNvbW1hbmQgaW5wdXQgaW50byBMRVIxLHRoZW4g TEVSMSBzZW5kIExPQ0sgdG8gTEVSMiBhbmQgdHJhbnNmZXIgdG8gVUE6TE86TCxMRVIyIHNlbmQg TlIgdG8gTEVSMSBhbmQgdHJhbnNmZXIgdG8gVUE6TE86Ui48YnI+CjMudGhlIGNsZWFyIGNvbW1h bmQgaW5wdXQgaW50byBMRVIxLExFUjEgdHJhbnNmZXIgdG8gTlIgYW5kIHNlbmQgTlIgdG8gTEVS MixidXQgdGhpcyBOUiBpcyBsb3N0IGZvciBzb21lIHVua25vd24gcmVhc29uLCBhbmQgU0ZfVyBp cyByYWlzZWQgaW1tZWRpYXRlbHkgaW4gTEVSMSxzbyB0aGF0IHRoZSBOUiB0aGF0IHNlbmQgYnkg TEVSMSB0byBMRVIyIGlzIHJlcGxhY2VkIGJ5IFNGX1cuPGJyPgoKPGEgaHJlZj0iaHR0cDovLzQu bm8iIHRhcmdldD0iX2JsYW5rIj40Lm5vPC9hPiBOUiByZWFjaCBMRVIyLCBpZiB0aGUgZXJyb3Ig aXMgYmlkaXJlY3Rpb25hbCxMRVIyIHdpbGwgc2VuZCBTRl9XIHRvIExFUjEsb3IgTlIgdG8gTEVS MiBpZiB1bmlkaXJlY3Rpb25hbC5idXQgaW4gYW55IGNvbmRpdGlvbixMRVIyIHdpbGwgc3RpbGwg aW4gVUE6TE86UiBzdGF0ZS50aGUgUFNDIGlzIGNyYXNoZWQuPGJyPgoKPGJyPgo8YnI+CnNvIGkg aGF2ZSAyIHBpZWNlcyBvZiBzdWdnZXN0aW9uPGJyPgoxLkxFUiBhbHdheXMgc2VuZCBoaXMgbG9j YWwgaGlnaGVzdCBwcmlvcml0eSB0byBpdCYjMzk7cyBwZWVyLjxicj4KMi5MRVIgYWx3YXlzIGFj Y2VwdCB0aGUgaW5wdXQgZnJvbSBoaXMgcGVlciBieSBQU0MgUERVLjxicj4KPGJyPgo8YnI+Cjxi cj4KPGJyPgo8YnI+Cjxicj4KQmVzdCBSZWdhcmRzITxicj4KPGJyPgrCoDxicj4KPGJyPgpKdW5i byBaZW5nKEJvQm8pPGJyPgo8YnI+Cjxicj4KPGJyPgo8YnI+Cjxicj4KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGJyPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgptcGxzIG1haWxp bmcgbGlzdDxicj4KPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8 L2E+PGJyPgo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHM8L2E+PGJyPgo8YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+ PGRpdj48YnI+PC9kaXY+LS0gPGJyPjxkaXYgZGlyPSJsdHIiPlRoYW54IGFuZCBCUiw8ZGl2Pnlh YWNvdjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGk+U3RpbGwgbG9va2luZyBmb3IgbmV3IG9w cG9ydHVuaXR5PC9pPjwvZGl2PjwvZGl2Pgo8L2Rpdj48L2Rpdj4K --047d7b5d43a45dca4004d2f2475e-- From wwwrun@rfc-editor.org Thu Jan 10 09:51:08 2013 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 9B25B21F8A4E for ; Thu, 10 Jan 2013 09:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.154, 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 VIvBnabjOUR3 for ; Thu, 10 Jan 2013 09:51:08 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2857C21F8A2F for ; Thu, 10 Jan 2013 09:51:08 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5EBC9B1E002; Thu, 10 Jan 2013 09:40:41 -0800 (PST) To: daniel@olddog.co.uk, venkat.mahalingams@gmail.com, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20130110174041.5EBC9B1E002@rfc-editor.org> Date: Thu, 10 Jan 2013 09:40:41 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC6639 (3450) 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, 10 Jan 2013 17:51:08 -0000 The following errata report has been submitted for RFC6639, "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6639&eid=3450 -------------------------------------- Type: Editorial Reported by: tom petch Section: 4.2.9 Original Text ------------- The mplsOutSegmentPerfTable [RFC3813] contains statistical information (total packets received, total errored packets received, total packets discarded, discontinuity time) for outgoing MPLS segments from an LSR. Corrected Text -------------- The mplsOutSegmentPerfTable [RFC3813] contains statistical information (total packets sent, total packets that could not be sent due to errors, total packets discarded, discontinuity time) for outgoing MPLS segments from an LSR. Notes ----- mplsOutSegmentPerfTable is for segments sent, current text relates to segments received. 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. -------------------------------------- RFC6639 (draft-ietf-mpls-tp-mib-management-overview-08) -------------------------------------- Title : Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview Publication Date : June 2012 Author(s) : D. King, Ed., M. Venkatesan, Ed. Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From daviball@cisco.com Thu Jan 10 09:56:54 2013 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 BE1CF21F893D for ; Thu, 10 Jan 2013 09:56:54 -0800 (PST) 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 v9AgvOBeOhPi for ; Thu, 10 Jan 2013 09:56:53 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AB3F421F87B2 for ; Thu, 10 Jan 2013 09:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12329; q=dns/txt; s=iport; t=1357840612; x=1359050212; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=F6/nNxw2oZH4peO+T84kiymSsqnR3C6ZmSrqSnqCUbI=; b=FQrMUGVDcMMwYEDrpae4JlcUcKnPwoe9MHptUnGQ34NgBDlJAIQfe6fp A2tnCpLJpCF0tRxgFRPp6tHc+CoNolnT7yXrNx0KJTBe9ZW9TuyqI19rC eNY9c4738x0FAjSkNY03S/ULoPDAU7aDk/tcM5/e3ft5gBVTSnoLmbLrV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMIAK0A71CQ/khL/2dsb2JhbAAqGoNHp0KSYhZzgh4BAQEEAQEBJBMxAwQHDAQLEQQBAQEJHgcPBRMeAQkOE4gHAw8MLLQJi3JqhEMDi1OIZ4FRAYZahF2FEoJ1dnAk X-IronPort-AV: E=Sophos;i="4.84,446,1355097600"; d="scan'208";a="149254902" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 10 Jan 2013 17:56:34 +0000 Received: from ensoft-linux3.cisco.com (ensoft-linux3.cisco.com [10.63.23.12]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0AHuYgB003495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2013 17:56:34 GMT Received: from daviball by ensoft-linux3.cisco.com with local (Exim 4.76) (envelope-from ) id 1TtMLw-0003RE-A9; Thu, 10 Jan 2013 17:55:55 +0000 Date: Thu, 10 Jan 2013 17:55:44 +0000 From: David Ball To: Yoshinori Koike Message-ID: <20130110175529.GH32428@cisco.com> References: <20121212174431.2DCABB1E002@rfc-editor.org> <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> <50CB6508.10804@lab.ntt.co.jp> <20121217140541.GN4232@cisco.com> <20130104110030.GD14216@cisco.com> <50EE5D7E.2010901@lab.ntt.co.jp> <50EEB105.9020600@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50EEB105.9020600@lab.ntt.co.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 10 Jan 2013 17:56:54 -0000 Hi Yoshinori, Currently in G.8121 amd 1, the dataplane loopback function is not present in any atomic functions at all; ie, it cannot be instantiated. David On Thu, Jan 10, 2013, Yoshinori Koike wrote: > Hi David, > > Sorry, there was mis-description. > > My understanding of G.8121 amd is that a position of data-plan > loopback process is not restricted, as I wrote in my email on Dec > 15, 2012. > > Best regards, > > Yoshinori > > (2013/01/10 15:19), Yoshinori Koike wrote: > >Hi David, > > > >I'm terribly sorry for the delay in replying to you. Thank you very much > >for the reply. See in line, please. > > > >(2013/01/04 20:00), David Ball wrote: > >>Hi Yoshinori, > >> > >>Did you have any further thoughts on this? > >> > >>Thanks, > >> > >> > >> David > >> > >> > >>On Mon, Dec 17, 2012, David Ball wrote: > >>>Hi Yoshinori, > >>> > >>>Thanks for your comments. > >>> > >>>With regards to your proposal, I am still a little unclear on the > >>>intended relationship between the dataplane loopback point and the > >>>MIP/MEP. Are these always on the same interface? If not, under what > >>>conditions could they be on different interfaces? How is the location > >>>of the dataplane loopback point determined? > > > >I think it depends on the maintenance model. In per-node model, it will > >be impossible when MIP/MEP is placed on forwarding engine. However, I've > >heard that in most of the implementation of routers, MIP/MEP is placed > >on ingress-IF. Then there seems no issue that both MIP/MEP and > >data-plane loopback point are located on the same ingress-IF. In > >per-interface model, I think these are usually on the same interface, > >although some implementation may/might implement on only one side of > >interfaces(only ingress-IF). > > > >It seems ideal that data-plane loopback point is located before MIP/MEP > >on ingress IF and/or after MIP/MEP on egress IF. > > > >>>To take a concrete example, suppose we have an interface with both a LSP > >>>MEP and a PW MEP. OAM packets destined for the LSP MEP will have an LSP > >>>label and a GAL, while OAM packets destined for the PW MEP will have an > >>>LSP label and a PW label. Client data traffic will also have both an > >>>LSP and a PW label. > > > >Correct me if I'm wrong, but I guess you assume that both a LSP MEP and > >a PW MEP are placed on the same ingress-IF in a per-node model, which is > >said to be the most typical model of IP/MPLS routers. > > > >>>Now, if either the LSP MEP or the PW MEP are put into a loopback mode, > >>>all of the client data packets will be looped. But which OAM packets > >>>are looped? > >>> - If the LSP MEP is put into loopback mode, do the LSP OAM packets get > >>> looped? I think so, since RFC6435 says that both data and OAM > >>> packets are looped. > >>> - If the LSP MEP is put into loopback mode, do the PW OAM packets get > >>> looped? Again, I think so. > >>> - If the PW MEP is put into loopback mode, do the PW OAM packets get > >>> looped? I think yes, this is equivalent to the first case. > >>> - If the PW MEP is put into loopback mode, do the LSP OAM packets get > >>> looped. Since they do not have a PW label, I am not sure? I think > >>> probably they shouldn't be, since there may be other PWs flowing > >>>over > >>> the same LSP, with different PW labels, right? > > > >My assumption was that if a data-plane loopback function is enabled > >using the LSP MEP, a data-plane loopback point(s) (in my understanding, > >a data-plane loopback sink and source process) in ingress-IF is enabled, > >all the traffics that the data-plane loopback sink process has received > >get looped through data-plane source process. > > > >Although the position of data-plane loopback process is located is not > >detailed in G.8121 including G.8121 amd1 under AAP, it doesn't seem to > >be considered only OAM packets get looped at the loopback process. In > >addition, when a data-plane loopback function is enabled, I think OAM > >functions should be disabled in principle. > > > >>> > >>>Regarding ITU-T G.8121 Amd 1 and G.8121.2, the reason the dataplane > >>>loopback process was removed from the MTDe figures in the last SG15 > >>>meeting was because of this confusing sentence in RFC6435 - in other > >>>words, it wasn't clear whether the MTDe function was the right place for > >>>them so as to match the behaviour specified in the RFC. The intent of > >>>G.8121.2 is to exactly match RFC6435 and the other relevant IETF RFCs. > >>> > >>> > >>>As a result, in the current ITU-T G.8121/G.8121.2, the dataplane > >>>loopback processes do not appear in any of the termination or adaptation > >>>functions that are specified; so although the processes themselves are > >>>defined, they are never applied. The question is, what is the correct > >>>place to apply them in the ITU-T model so as to match the RFC? > > > >Thank you for the clarification. My understanding of G.8121 amd is that > >a data-plane loopback point is located before MIP/MEP on ingress IF > >and/or after MIP/MEP on egress IF and whether the type of data is > >AI/CI/client depends on the implementation. > > > >Best regards, > > > >Yoshinori > > > >>> > >>> > >>> David > >>> > >>> > >>>On Sat, Dec 15, 2012, Yoshinori Koike wrote: > >>>>Hello David, > >>>> > >>>>I agree with original text is confusing and thank you for the > >>>>proposal. However, I'm wondering if the proposed text is true and > >>>>exactly reflect the intent explained in the notes. > >>>> > >>>>My suggestion is as follows: > >>>>It should be noted that the data-plane loopback function itself is > >>>>applied to data-plane loopback point which is different from > >>>>MIP/MEP. > >>>> > >>>>Firstly, the description "the data-plane loopback function may be > >>>>applied at MIPs/MEPs" doesn't seem to be true. > >>>> > >>>>In my understanding, data-plane loopback function can be > >>>>set/enabled/disabled at MIP/MEP using a management system but not be > >>>>applied to MIP/MEP itself. So I clarified this point in my proposal. > >>>> > >>>>One of the reason is that MIP/MEP is only involved in OAM packets. > >>>>There seems no specification in any RFC, which describe that MIP/MEP > >>>>could handle data packets which are not OAM packets . > >>>> > >>>>In G.8121 amd1, data-plane loopback sink and source are specified > >>>>and according to Temporary Document(TD673R1<->R0/Plen) during last > >>>>SG15 meeting, the data-plane loopback sink/source was removed from > >>>>figures of MTDe_TT_Sk/So Process(Fig.9-14&16). I guess this might be > >>>>to avoid a restriction of implementations, however it doesn't seem > >>>>to make it possible to apply dataplane loopback point to MIP/MEP. In > >>>>realty, if data-plane loopback function is enabled, for data-plane > >>>>LB function there is no need to parse the packet except for > >>>>outermost label value. > >>>> > >>>>Secondly, if you need to clarify the relationship between data-plane > >>>>LB point at which data-plane LB function is conducted and MIP/MEP at > >>>>which data-plane LB function is enabled/configured using management > >>>>system, it seems enough just to say the two point usually resides on > >>>>the same interface and clarify the binding of two points. I have no > >>>>issue on this specification. However, just in case, it seems better > >>>>to confirm if the change is ok in ITU-T joint interregnum meeting > >>>>Jan 2013, because this is a matter of 8121 or/and G.8121.1. As a > >>>>result, I didn't add related text in my proposal. > >>>> > >>>>I'm not an implementer, so I would appreciate it if you could > >>>>correct me if I'm wrong. Thank you in advance. > >>>> > >>>>Best regards, > >>>> > >>>>Yoshinori > >>>> > >>>> > >>>>(2012/12/13 3:17), Adrian Farrel wrote: > >>>>>Hello, > >>>>> > >>>>>Authors of RFC 6435: I need to hear from you that you meant the > >>>>>text that David > >>>>>suggests. It is very clearly not what you wrote and, if you meant > >>>>>something > >>>>>different, it is clear why people are confused! > >>>>> > >>>>>Working group: I need to hear from you that you agree with David's > >>>>>interpretation and support his proposed change. > >>>>> > >>>>>Only then will I try to work out whether this is a "typo" worthy of > >>>>>an errata > >>>>>report, or a technical change needing a revised RFC. > >>>>> > >>>>>Thanks, > >>>>>Adrian > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>>>>>Sent: 12 December 2012 17:45 > >>>>>>To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > >>>>>>martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > >>>>>>stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; > >>>>>>swallow@cisco.com; > >>>>>>rcallon@juniper.net > >>>>>>Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org > >>>>>>Subject: [Editorial Errata Reported] RFC6435 (3429) > >>>>>> > >>>>>> > >>>>>>The following errata report has been submitted for RFC6435, > >>>>>>"MPLS Transport Profile Lock Instruct and Loopback Functions". > >>>>>> > >>>>>>-------------------------------------- > >>>>>>You may review the report below and at: > >>>>>>http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 > >>>>>> > >>>>>>-------------------------------------- > >>>>>>Type: Editorial > >>>>>>Reported by: David Ball > >>>>>> > >>>>>>Section: 4 (para 5) > >>>>>> > >>>>>>Original Text > >>>>>>------------- > >>>>>>It should be noted that the data-plane loopback function itself is > >>>>>>applied to > >>>>>data- > >>>>>>plane loopback points residing on different interfaces from > >>>>>>MIPs/MEPs. > >>>>>> > >>>>>>Corrected Text > >>>>>>-------------- > >>>>>>It should be noted that the data-plane loopback function may be > >>>>>>applied at > >>>>>>MIPs/MEPs on different interfaces for different LSPs. > >>>>>> > >>>>>>Notes > >>>>>>----- > >>>>>>The existing text has caused confusion (specifically, among > >>>>>>experts in ITU-T > >>>>>SG15 > >>>>>>when discussing G.8121.2), in that it seems to suggest that the > >>>>>>interface > >>>>>where > >>>>>>the MIP/MEP is located may be a different interface to the one > >>>>>>where the > >>>>>>loopback is applied. > >>>>>> > >>>>>>Having spoken with some of the original authors, it seems this was > >>>>>>not the > >>>>>intent > >>>>>>of this sentence; the intent was to point out that as different > >>>>>>LSPs would > >>>>>have > >>>>>>MIPs/MEPs on different interfaces, the corresponding loopback > >>>>>>functions would > >>>>>>also be applied on different interfaces. > >>>>>> > >>>>>>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. > >>>>>> > >>>>>>-------------------------------------- > >>>>>>RFC6435 (draft-ietf-mpls-tp-li-lb-08) > >>>>>>-------------------------------------- > >>>>>>Title : MPLS Transport Profile Lock Instruct and > >>>>>>Loopback > >>>>>Functions > >>>>>>Publication Date : November 2011 > >>>>>>Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. > >>>>>>Aggarwal, Ed., M. > >>>>>Vigoureux, > >>>>>>Ed., X. Dai, Ed. > >>>>>>Category : PROPOSED STANDARD > >>>>>>Source : Multiprotocol Label Switching > >>>>>>Area : Routing > >>>>>>Stream : IETF > >>>>>>Verifying Party : IESG > >>>>> > >>>>>_______________________________________________ > >>>>>mpls mailing list > >>>>>mpls@ietf.org > >>>>>https://www.ietf.org/mailman/listinfo/mpls > >>>>> > >>>> > >>>> > >>>>-- > >>>>Yoshinori Koike > >>>>koike.yoshinori@lab.ntt.co.jp > >>>> > >>> > >>>-- > >>>David Ball > >>> > >> > > > > > > > -- > Yoshinori Koike > koike.yoshinori@lab.ntt.co.jp > -- David Ball From daviball@cisco.com Thu Jan 10 09:57:26 2013 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 4F9FF21F87ED for ; Thu, 10 Jan 2013 09:57:26 -0800 (PST) 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 MPCpzMu78ZrW for ; Thu, 10 Jan 2013 09:57:25 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id D82F121F84F9 for ; Thu, 10 Jan 2013 09:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6112; q=dns/txt; s=iport; t=1357840645; x=1359050245; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ryXw4b+ALQGkhTS+d2UGrkAnrZEUMaH2+BiCUI/d0ps=; b=mq9Bq7jYoNhIVTwb9ztgYaCto7xTCI0V882/f3koywbDSuGYwQpc/wU6 NyP7AsksrM5AnvdBPeR0GyG3TzX6bZLLdDFAb/eBJ6ILW8N27GQnzW7Pf BsLrF5ncBL0KKZnAFk/wdqsjKzTWp1TRQ8OnSqjK8EFrWmQNSQY8t3S5K 4=; X-IronPort-AV: E=Sophos;i="4.84,446,1355097600"; d="scan'208";a="10999284" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 10 Jan 2013 17:57:23 +0000 Received: from ensoft-linux3.cisco.com (ensoft-linux3.cisco.com [10.63.23.12]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0AHvNgt007709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2013 17:57:23 GMT Received: from daviball by ensoft-linux3.cisco.com with local (Exim 4.76) (envelope-from ) id 1TtMN7-0003Sl-QE; Thu, 10 Jan 2013 17:57:01 +0000 Date: Thu, 10 Jan 2013 17:56:57 +0000 From: David Ball To: "VIGOUREUX, MARTIN (MARTIN)" Message-ID: <20130110175648.GI32428@cisco.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "Sami Boutros \(sboutros\)" , "Siva Sivabalan \(msiva\)" , "raggarwa_1@yahoo.com" , "rcallon@juniper.net" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 10 Jan 2013 17:57:26 -0000 Hi Martin, Ah, right I see: since the loopback is locally configured, there is no need for a MEP/MIP to send/receive OAM frames - but there may be a MEP/MIP. So would this work to clarify the text? "It should be noted that the data-plane loopback function for a given transport path can be applied to data-plane loopback points residing on interfaces where there may be no corresponding MEP or MIP." For completeness, the references to "MEP or MIP" in paragraphs 3 and 7 of section 4 would also need to be changed, to instead refer to the transport path that is being put in to loopback. As another data point, I found this text in RFC6371 section 6.3.2: "It should be noted that data-plane loopback function itself is applied to data-plane loopback points that can reside on different interfaces from MIPs/MEPs." Note the critical difference compared to RFC6435: "that can reside" instead of "residing". Thanks David On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: > Sami, > > Thanks. Yet, I am not sure David's interpretation and mine exactly match. > David, correct me if I am wrong. For me it says that we can do > loopback on different interfaces (for different LSPs) but implies that > there is a mip/mep for that lsp on that interface, while my > interpretation is that the presence of a mip/mep for that lsp on that > interface is not needed. > > -m > ________________________________ > De : Sami Boutros (sboutros) > Envoy? : 09/01/2013 19:00 > ? : VIGOUREUX, MARTIN (MARTIN) > Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco); Siva Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org > Objet : Re: [Editorial Errata Reported] RFC6435 (3429) > > I agree with Martin, the text proposed by David describe more accurately what we meant. > > Thanks, > > Sami > On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > > > Adrian, David, > > > > what I think we meant here was that a loop-back function could be done on an interface regardless of the presence of a MIP/MEP on that interface. Yet, I have to admit that MIP and MEP are used in Section 4 of RFC6435, thus surely causing confusion. > > > > I'd welcome the views/souvenirs of my co-authors. > > > > -m > > > > Le 12/12/2012 19:17, Adrian Farrel a ?crit : > >> Hello, > >> > >> Authors of RFC 6435: I need to hear from you that you meant the text that David > >> suggests. It is very clearly not what you wrote and, if you meant something > >> different, it is clear why people are confused! > >> > >> Working group: I need to hear from you that you agree with David's > >> interpretation and support his proposed change. > >> > >> Only then will I try to work out whether this is a "typo" worthy of an errata > >> report, or a technical change needing a revised RFC. > >> > >> Thanks, > >> Adrian > >> > >>> -----Original Message----- > >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>> Sent: 12 December 2012 17:45 > >>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > >>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > >>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; > >>> rcallon@juniper.net > >>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org > >>> Subject: [Editorial Errata Reported] RFC6435 (3429) > >>> > >>> > >>> The following errata report has been submitted for RFC6435, > >>> "MPLS Transport Profile Lock Instruct and Loopback Functions". > >>> > >>> -------------------------------------- > >>> You may review the report below and at: > >>> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 > >>> > >>> -------------------------------------- > >>> Type: Editorial > >>> Reported by: David Ball > >>> > >>> Section: 4 (para 5) > >>> > >>> Original Text > >>> ------------- > >>> It should be noted that the data-plane loopback function itself is applied to > >> data- > >>> plane loopback points residing on different interfaces from MIPs/MEPs. > >>> > >>> Corrected Text > >>> -------------- > >>> It should be noted that the data-plane loopback function may be applied at > >>> MIPs/MEPs on different interfaces for different LSPs. > >>> > >>> Notes > >>> ----- > >>> The existing text has caused confusion (specifically, among experts in ITU-T > >> SG15 > >>> when discussing G.8121.2), in that it seems to suggest that the interface > >> where > >>> the MIP/MEP is located may be a different interface to the one where the > >>> loopback is applied. > >>> > >>> Having spoken with some of the original authors, it seems this was not the > >> intent > >>> of this sentence; the intent was to point out that as different LSPs would > >> have > >>> MIPs/MEPs on different interfaces, the corresponding loopback functions would > >>> also be applied on different interfaces. > >>> > >>> 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. > >>> > >>> -------------------------------------- > >>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) > >>> -------------------------------------- > >>> Title : MPLS Transport Profile Lock Instruct and Loopback > >> Functions > >>> Publication Date : November 2011 > >>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. > >> Vigoureux, > >>> Ed., X. Dai, Ed. > >>> Category : PROPOSED STANDARD > >>> Source : Multiprotocol Label Switching > >>> Area : Routing > >>> Stream : IETF > >>> Verifying Party : IESG > >> > >> > -- David Ball From daniele.ceccarelli@ericsson.com Thu Jan 10 09:58:07 2013 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 2C2A921F893D for ; Thu, 10 Jan 2013 09:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 SA8XxeQXxytg for ; Thu, 10 Jan 2013 09:58:06 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9AB21F8570 for ; Thu, 10 Jan 2013 09:58:05 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-23-50ef012bbc78 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 89.2A.10459.B210FE05; Thu, 10 Jan 2013 18:58:04 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.193]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.004; Thu, 10 Jan 2013 18:58:03 +0100 From: Daniele Ceccarelli To: Loa Andersson Thread-Topic: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg document Thread-Index: AQHN6e7Dd2F5/MRiV0+nLV7S5I9RgJhAQc8AgAEkUfCAAV9N0A== Date: Thu, 10 Jan 2013 17:58:02 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4805E29A@ESESSMB301.ericsson.se> References: <50E5E64A.8090105@pi.nu> 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.18] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4805E29AESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvja4O4/sAgznP2S2mLtzBbvFv7hxm i++XlrBY3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoErY9WKj+wF93Mq plzcwdzAOCuui5GTQ0LAROLumnNMELaYxIV769m6GLk4hAQOMUrc2zybFcJZwigxv+s5excj BwebgJXEk0M+IA0iArIS17b9ZAKpYRY4yShxYdJCNpCEsECFxK5p+5ggiiolFt/YwAhhO0k0 PTnPDGKzCKhKrH/QDFbDK+AtsWbda0aIZWsZJTpmT2MBSXAK+Eh8bFkJVsQItG3C7kVgg5gF xCVuPZkPdbaAxJI9EEMlBEQlXj7+xwphK0p8fLUPqj5f4lHrL3aIZYISJ2c+YZnAKDoLyahZ SMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxjZcxMzc9LLDTcxAqPu4JbfujsY T50TOcQozcGiJM4b5nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjeyRXXlhMbNmLJrFt VhP/H70hcTtwVcIhcX+RdhH3/4I7d0j+z1jUfmtxpe9qt9zfPz4UHFg3x3T6+mWO03RdA84+ 4VyXuJqdk0fF7p2150eNpJsH5J/ZrJ6YZ3ln/7pXPCwTnkdG8Pb9zHfN1WdOiQvl6Jt+8pGj 6cO96yfxJVkXb3n738NNiaU4I9FQi7moOBEAgVaRb4gCAAA= Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg 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, 10 Jan 2013 17:58:07 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE4805E29AESESSMB301ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/Support with some very minor comments/suggestions: BR Daniele 1 . MPLS TE-LSP support is discussed in [RFC4875] and [RFC5332], and PW support is being developed based on [I-D.ietf-pwe3-p2mp-pw-requirements] and [I-D.ietf-l2vpn-vpms-frmwk-requirements]. I'd say that P2MP MPLS TE-LSP support is discussed...and P2MP PW support...= . 2. MPLS-TP point-to- multipoint connectivity is analogous to that provided by traditional transport technologies such as Optical Transport Network (OTN) point- to-multipoint [ref?] and optical drop-and-continue [ref?], and thus supports the same class of traditional applications. Maybe it could be worth listing which this applications are? 3. Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and [RFC4873], do not explicitly cover their interactions. MPLS-TP requires a formal definition of recovery techniques for P2MP LSPs. Such a formal definition will be based on existing RFCs and may not require any new protocol mechanisms but, nonetheless, should be documented. Is there any plan to document it in this ID o somewhere else? if so, where?= RFC6372 only provides protection considerations, what about restoration? On Thu, Jan 3, 2013 at 3:12 PM, Loa Andersson >= wrote: Working group, This is to start a two week poll on adopting draft-fbb-mpls-tp-p2mp-framework-06 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 tech= nical 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 January 17, 2013. There are no IPR claim against this document. All the active co-authors has stated on the working group mailing list that they are not aware of any other IPR claims than those already disclosed. /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 --_000_4A1562797D64E44993C5CBF38CF1BE4805E29AESESSMB301ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 Yes/Support
 
with some very minor co= mments/suggestions:
 
BR
Daniele
 
1 .
   MPLS TE-LSP support is discussed = in [RFC4875] and
   [RFC5332], and PW support is being developed based on
   [I-D.ietf-pwe3-p2mp-pw-requirements] and
   [I-D.ietf-l2vpn-vpms-frmwk-requirements].
I'd say that P2MP MPLS TE-LS= P support is discussed...and P2MP PW support....
 
2.
   MPLS-TP point-to-
   multipoint connectivity is analogous to that provided by traditional
   transport technologies such as Optical Transport Network (OTN) point-
   to-multipoint [ref?] and optical drop-and-continue [ref?], and thus
   supports the same class of traditional applications.
 
Maybe it could be worth listing which this applications=
 are?
3. 
 
Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS
   recovery, [RFC4872] and [RFC4873], do not explicitly cover their
   interactions.  MPLS-TP requires a formal definition of recovery
   techniques for P2MP LSPs.  Such a formal definition will be based on
   existing RFCs and may not require any new protocol mechanisms but,
   nonetheless, should be documented. 
Is there a=
ny plan to document it in this ID o somewhere else? if so, where? RFC6372 o=
nly provides protection considerations, what about restoration?
 
On T=
hu, Jan 3, 2013 at 3:12 PM, Loa Andersson <loa@pi.nu> wrote:

Working group,

This is to start a two week poll on adopting
draft-fbb-mpls-tp-p2mp-framework-06 as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls at i= etf.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 January 17, 2013.

There are no IPR claim against this document.

All the active co-authors has stated on the working group mailing list
that they are not aware of any other IPR claims than those already
disclosed.

/Loa
(mpls wg co-chair)

--


Loa Andersson           &nb= sp;             email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager     &nbs= p;      loa@p= i.nu
Ericsson Inc           &nbs= p;              phone: +46 10 717 52 13
              &nb= sp;                     &= nbsp;        +46 767 72 92 13
_______________________________________________
mpls mailing list
m= pls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls<= /span>

 

--_000_4A1562797D64E44993C5CBF38CF1BE4805E29AESESSMB301ericsso_-- From wyaacov@gmail.com Thu Jan 10 10:01:50 2013 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 669CF21F8A68 for ; Thu, 10 Jan 2013 10:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.359 X-Spam-Level: X-Spam-Status: No, score=0.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001, 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 K1DuvvTwnxCE for ; Thu, 10 Jan 2013 10:01:49 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA1521F8967 for ; Thu, 10 Jan 2013 10:01:49 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hq12so1459834wib.2 for ; Thu, 10 Jan 2013 10:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:cc:content-type; bh=QrqXa3OTNxtnJ3muTk/27M6JIYy3f4Qqks9g719TZQs=; b=PGLY3EpMRx74Fo//RLzPgzMVno1btOZdey5DCqUpTxOCYiCTB4Od0dm/KIwLqUm3Au 7v1H/SNgxerEQ9IH0K+4IDxRdH3poBpK0LtMXrCTiIkc77ezY1fnkOspmqtLjxDB+r58 WPbmRjviv8m0M0SrMh7CLWCyfiRZlxIjDEGYqJxhJNOEAXdKQNH5YMHaycMc5+tPpK9z lzMdpE2Xz5Mw/fQOEwOxsq5K5wubOz5SVV8G+MbSlgAu9oS7W3/WSqmX/KcxF6ybd6id wi6zCqCud+5AfL/HSNyWA9yIj0g6xtJpaQrqj3YW7W9icPo/fOXu+q0DS5hkl5KkiLPC yyeA== MIME-Version: 1.0 X-Received: by 10.180.75.135 with SMTP id c7mr10822594wiw.10.1357840907188; Thu, 10 Jan 2013 10:01:47 -0800 (PST) Received: by 10.194.90.243 with HTTP; Thu, 10 Jan 2013 10:01:47 -0800 (PST) In-Reply-To: <50E5E64A.8090105@pi.nu> References: <50E5E64A.8090105@pi.nu> Date: Thu, 10 Jan 2013 20:01:47 +0200 Message-ID: From: Yaacov Weingarten Cc: "mpls@ietf.org" Content-Type: multipart/alternative; boundary=f46d043be240ef37c704d2f2f82f Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg 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, 10 Jan 2013 18:01:50 -0000 --f46d043be240ef37c704d2f2f82f Content-Type: text/plain; charset=ISO-8859-1 Yes/ Support BR, yaacov On Thu, Jan 3, 2013 at 10:12 PM, Loa Andersson wrote: > Working group, > > This is to start a two week poll on adopting > draft-fbb-mpls-tp-p2mp-**framework-06 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 January 17, 2013. > > There are no IPR claim against this document. > > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. > > /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 > -- Thanx and BR, yaacov *Still looking for new opportunity* --f46d043be240ef37c704d2f2f82f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes/ Support

BR,
= yaacov


On Thu, Jan 3, 2013 at 10:12 PM, Loa Andersson <<= a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu> wrot= e:
Working group,

This is to start a two week poll on adopting
draft-fbb-mpls-tp-p2mp-framework-06 as an MPLS working group documen= t.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls at i= etf.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 January 17, 2013.

There are no IPR claim against this document.

All the active co-authors has stated on the working group mailing list
that they are not aware of any other IPR claims than those already
disclosed.

/Loa
(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
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
Thanx and BR,
yaacov

Sti= ll looking for new opportunity
--f46d043be240ef37c704d2f2f82f-- From zjbdamo@hotmail.com Thu Jan 10 18:44:02 2013 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 A14DA21F884F for ; Thu, 10 Jan 2013 18:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.026 X-Spam-Level: ** X-Spam-Status: No, score=2.026 tagged_above=-999 required=5 tests=[AWL=-3.125, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, 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 BoNPEFLPMkja for ; Thu, 10 Jan 2013 18:44:01 -0800 (PST) Received: from blu0-omc3-s2.blu0.hotmail.com (blu0-omc3-s2.blu0.hotmail.com [65.55.116.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9C04F21F884A for ; Thu, 10 Jan 2013 18:44:01 -0800 (PST) Received: from BLU168-W46 ([65.55.116.72]) by blu0-omc3-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jan 2013 18:44:01 -0800 X-EIP: [ZVQ9oULOk3ZXipGH/2LAGyHa0Yl35L36] X-Originating-Email: [zjbdamo@hotmail.com] Message-ID: From: =?gb2312?B?1Pi+/rKo?= To: Date: Fri, 11 Jan 2013 10:44:00 +0800 Importance: Normal In-Reply-To: References: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2013 02:44:01.0041 (UTC) FILETIME=[83053010:01CDEFA5] Cc: mpls@ietf.org, yaacov.weingarten@nsn.com Subject: Re: [mpls] in some scenario RFC6378 can not protect the traffic, so much as take the PSC state to crash. 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, 11 Jan 2013 02:44:02 -0000 yaacov,thanks for your patient explain. 1. Regarding Scenario #1:according the Section 4.3.3.1,i think the there need a new state ---TEMPORARY NORMAL STATE,just as its name implies,this state is a temporary state,and in this state LER shall never send NR PDU to its peer and will check its local persistent state to deside the final state and inform its peer by PSC PDU according this final state. 2.Regarding Scenario #2:I wonder how to define "contradictory". any change of the PSC PDU or the Path is not same with previous PSC PDU or any other? Best Regards! Junbo Zeng(BoBo) ________________________________ > Date: Thu, 10 Jan 2013 19:12:08 +0200 > Subject: Re: [mpls] in some scenario RFC6378 can not protect the > traffic, so much as take the PSC state to crash. > From: wyaacov@gmail.com > To: zjbdamo@hotmail.com > CC: mpls@ietf.org; yaacov.weingarten@nsn.com > > Junbo, hi > > Thank you for your scenarios. However, both of these scenarios are > addressed by the text of RFC6378. > > 1. Regarding Scenario #1: The second paragraph of Section 4.3.3.1 > states - "When the LER transitions into the Normal state, the PSC > Control Process SHALL check the persistent state of the local triggers > to decide if it should further transition into a new state...." Meaning > that in your scenario, after receiving the Clear, before transitioning > into Normal State, LER-1 should have checked the status of the other > triggers and decided, based upon the still active SF-W to transition > into Protecting Failure state, transmitting a SF(1,1) message. As to > the reaction of LER-2, see below. > > 2. Regarding Scenario #2: The second paragraph of Section 4.3.3 states > -"When a LER is in a remote state, i.e. state transition in reaction > to a PSC message recieved from the far-end LER, and receives a new > PSC message from the far-end LER that indicates a contradictory > state, e.g. in remote Unavailable state receiving a remote FS(1,1) > message, then the PSC Control Logic SHALL reevaluate all inputs (both > the local input and the remote message) as if the LER is in the > Normal state." Meaning that in both the continuation of the previous > scenario as well as in your scenario, LER-2 should react to the remote > SF message as if in Normal and transition into Remote Protecting > Failure State. > > Therefore, I contend that neither scenario will cause PSC to crash. > > > > On Thu, Jan 10, 2013 at 11:10 AM, 曾峻波 > > wrote: > > > (if the figure can not display normally,please see the attach file.thanks.) > > > When in multi fault/priority condition scenario,RFC6378 can not protect > the traffic so much as take the PSC state to crash.consider the > following 2 scenario. > > +------+ +------+ > | LER1 | | LER2 | > +---+--+ +---+--+ > +----------NR------------------->| > | | > | | > |<---------NR--------------------+ > local lockout | | > input | | > +-----------LOCK---------------->| > | | > | | > |<---------NR--------------------+ > | | > unidirection | | > SF_W raise | | > +-------------LOCK-------------->| > | | > | | > |<---------NR--------------------+ > | | > local clear | | > input | | > +------------NR----------------->| > | | > | | > |<-----------NR------------------+ > | | > > > figure 1: unidirection SF_W raise after local lockout input > > in figure 1,consider the following procedure > 1.LER1 and LER2 are both in NORMAL state and exchange NR PDU. > 2.the lockout command input into LER1,then LER1 send LOCK to LER2,LER2 > send NR to LER1. > 3.a unidirection SF_W is raised in LER1,according RFC6378, LER1 still > send LOCK to LER2,LER2 send NR to LER1. > 4.the clear command input into LER1,according RFC6378,LER1 will send NR > to LER2,LER2 still send NR to LER1. so traffic is broken. > > > > > +------+ +------+ > | LER1 | | LER2 | > +---+--+ +---+--+ > N +----------NR------------------->| N > | | > | | > |<---------NR--------------------+ > local lockout input | | > | | > UA:LO:L +-----------LOCK---------------->| > | |UA:LO:R > | | > |<---------NR--------------------+ > local clear input | | > | | > | | > N +-------NR--------------.........| > | | > SF_W raise | this nr is lost for smth. | > | and SF_W is raised. | > | | > +----------SF_W----------------->|always in UA:LO:R > | | > | | > | | > |<-----------SF_W----------------+ > | | > | | > > figure 2: after clear a local LOCKOUT command,SF_W is raise > immediately,and the NR send to LER2 is lost for something. > > in figure 2,consider the following procedure. > 1.LER1 and LER2 are both in NORMAL state and exchange NR PDU. > 2.the lockout command input into LER1,then LER1 send LOCK to LER2 and > transfer to UA:LO:L,LER2 send NR to LER1 and transfer to UA:LO:R. > 3.the clear command input into LER1,LER1 transfer to NR and send NR to > LER2,but this NR is lost for some unknown reason, and SF_W is raised > immediately in LER1,so that the NR that send by LER1 to LER2 is > replaced by SF_W. > 4.no NR reach LER2, if the error is bidirectional,LER2 > will send SF_W to LER1,or NR to LER2 if unidirectional.but in any > condition,LER2 will still in UA:LO:R state.the PSC is crashed. > > > so i have 2 pieces of suggestion > 1.LER always send his local highest priority to it's peer. > 2.LER always accept the input from his peer by PSC PDU. > > > > > > > Best Regards! > > > > Junbo Zeng(BoBo) > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > > -- > Thanx and BR, > yaacov > > Still looking for new opportunity From zjbdamo@hotmail.com Thu Jan 10 19:19:19 2013 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 E63A721F88EA for ; Thu, 10 Jan 2013 19:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.063 X-Spam-Level: ** X-Spam-Status: No, score=2.063 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_12=0.6, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3] 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 wwYtX4g0NbrE for ; Thu, 10 Jan 2013 19:19:19 -0800 (PST) Received: from blu0-omc4-s22.blu0.hotmail.com (blu0-omc4-s22.blu0.hotmail.com [65.55.111.161]) by ietfa.amsl.com (Postfix) with ESMTP id 195AD21F88E1 for ; Thu, 10 Jan 2013 19:19:18 -0800 (PST) Received: from BLU168-W60 ([65.55.111.135]) by blu0-omc4-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jan 2013 19:19:18 -0800 X-EIP: [Nvm3G+FizvU5WMbLylhq5Qng2Bexj3tR] X-Originating-Email: [zjbdamo@hotmail.com] Message-ID: From: =?gb2312?B?1Pi+/rKo?= To: Date: Fri, 11 Jan 2013 11:19:18 +0800 Importance: Normal Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2013 03:19:18.0068 (UTC) FILETIME=[70DDDF40:01CDEFAA] Subject: [mpls] doubt of PW_Path_ID and per-interface MIP id in RFC 6370. 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, 11 Jan 2013 03:19:20 -0000 hi,the authors of RFC6370, i have 2 questions about RFC6370 1.in RFC6370 the PW_Path_ID is defined as AGI::A1-{Global_ID::Node_ID::AC_ID}::Z9-{Global_ID::Node_ID::AC_ID}. The AC_ID is refer to RFC5003,and the AC_ID is described as below " Attachment Circuit (AC) ID = This is a fixed-length 4-octet field used to further refine identification of an attachment circuit on the PE.The inclusion of the AC ID is used to identify individual attachment circuits that share a common prefix." in vpws the AC and PW is one to one,but in vpls the the AC and PW maybe n to m,so how to fill the PW_Path_ID? and i suggested that use pwid of FEC128 to replace AC_ID. 2.would any volunteer can give me some example of the MIP's id of PW and LSP in per-interface scenario. From wyaacov@gmail.com Thu Jan 10 20:15:52 2013 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 DD55221F8946 for ; Thu, 10 Jan 2013 20:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.27 X-Spam-Level: X-Spam-Status: No, score=-0.27 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, 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 6vF+A5AcTYIU for ; Thu, 10 Jan 2013 20:15:50 -0800 (PST) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id 11ACD21F8928 for ; Thu, 10 Jan 2013 20:15:49 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id t57so631893wey.11 for ; Thu, 10 Jan 2013 20:15:49 -0800 (PST) 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=paLwNMjTUU/nOyBbQtdr2uHzqiB/94UZ6t8vFXFm8g0=; b=aSsJihC67znM2aJfjKkkm2LrbXVkEZY8Sncyp8t+ITaOBc3AgaGon9LIUKrB15euT3 FRLmx8VPuarhBD/Cp5/5/Hf7mHmYzOA9Ni0wsMrtnp4+i5WNE84gUvlUjhRHoTIMREdH ZmZquTaM30wKkVc4DEKKog89ux68sojScyie//HoWALuLFmyYPWCpPkFtfxLn5EjHYgO X5ER2wLJchqxt0R20APN8jbHxNQHiqPsocivEvX2HLoIIOYVEVA7hsY41RIwScWXZ+HJ UY9T4udnmobDCRzKevm09X4xpjTZnWgaGi8zQNqaEP5OBI9xHJSjO0bwGp7uMzpFSikk x9EQ== MIME-Version: 1.0 Received: by 10.194.7.104 with SMTP id i8mr118313857wja.27.1357877749108; Thu, 10 Jan 2013 20:15:49 -0800 (PST) Received: by 10.194.90.243 with HTTP; Thu, 10 Jan 2013 20:15:48 -0800 (PST) Received: by 10.194.90.243 with HTTP; Thu, 10 Jan 2013 20:15:48 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Jan 2013 06:15:48 +0200 Message-ID: From: Yaacov Weingarten To: =?UTF-8?B?5pu+5bO75rOi?= Content-Type: multipart/alternative; boundary=047d7b5d43a4e251bf04d2fb8c3a Cc: mpls@ietf.org Subject: Re: [mpls] in some scenario RFC6378 can not protect the traffic, so much as take the PSC state to crash. 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, 11 Jan 2013 04:15:53 -0000 --047d7b5d43a4e251bf04d2fb8c3a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, 1. I believe that this is an implementation issue, and therefore out of scope. 2. "Contradictory" means any message that implies a different remote state. Hope this helps BR, yaacov Still looking for new opportunity On Jan 11, 2013 4:44 AM, "=E6=9B=BE=E5=B3=BB=E6=B3=A2" wrote: > > > yaacov,thanks for your patient explain. > > 1. Regarding Scenario #1:according the Section 4.3.3.1,i think the there > need a new state ---TEMPORARY NORMAL STATE,just as its name implies,this > state is a temporary state,and in this state LER shall never send NR PDU = to > its peer and will check its local persistent state to deside the final > state and inform its peer by PSC PDU according this final state. > > 2.Regarding Scenario #2:I wonder how to define "contradictory". any chang= e > of the PSC PDU or the Path is not same with previous PSC PDU or any other= ? > > > > Best Regards! > Junbo Zeng(BoBo) > > > > ________________________________ > > Date: Thu, 10 Jan 2013 19:12:08 +0200 > > Subject: Re: [mpls] in some scenario RFC6378 can not protect the > > traffic, so much as take the PSC state to crash. > > From: wyaacov@gmail.com > > To: zjbdamo@hotmail.com > > CC: mpls@ietf.org; yaacov.weingarten@nsn.com > > > > Junbo, hi > > > > Thank you for your scenarios. However, both of these scenarios are > > addressed by the text of RFC6378. > > > > 1. Regarding Scenario #1: The second paragraph of Section 4.3.3.1 > > states - "When the LER transitions into the Normal state, the PSC > > Control Process SHALL check the persistent state of the local triggers > > to decide if it should further transition into a new state...." Meaning > > that in your scenario, after receiving the Clear, before transitioning > > into Normal State, LER-1 should have checked the status of the other > > triggers and decided, based upon the still active SF-W to transition > > into Protecting Failure state, transmitting a SF(1,1) message. As to > > the reaction of LER-2, see below. > > > > 2. Regarding Scenario #2: The second paragraph of Section 4.3.3 states > > -"When a LER is in a remote state, i.e. state transition in reaction > > to a PSC message recieved from the far-end LER, and receives a new > > PSC message from the far-end LER that indicates a contradictory > > state, e.g. in remote Unavailable state receiving a remote FS(1,1) > > message, then the PSC Control Logic SHALL reevaluate all inputs (both > > the local input and the remote message) as if the LER is in the > > Normal state." Meaning that in both the continuation of the previous > > scenario as well as in your scenario, LER-2 should react to the remote > > SF message as if in Normal and transition into Remote Protecting > > Failure State. > > > > Therefore, I contend that neither scenario will cause PSC to crash. > > > > > > > > On Thu, Jan 10, 2013 at 11:10 AM, =E6=9B=BE=E5=B3=BB=E6=B3=A2 > > > wrote: > > > > > > (if the figure can not display normally,please see the attach > file.thanks.) > > > > > > When in multi fault/priority condition scenario,RFC6378 can not protect > > the traffic so much as take the PSC state to crash.consider the > > following 2 scenario. > > > > +------+ +------+ > > | LER1 | | LER2 | > > +---+--+ +---+--+ > > +----------NR------------------->| > > | | > > | | > > |<---------NR--------------------+ > > local lockout | | > > input | | > > +-----------LOCK---------------->| > > | | > > | | > > |<---------NR--------------------+ > > | | > > unidirection | | > > SF_W raise | | > > +-------------LOCK-------------->| > > | | > > | | > > |<---------NR--------------------+ > > | | > > local clear | | > > input | | > > +------------NR----------------->| > > | | > > | | > > |<-----------NR------------------+ > > | | > > > > > > figure 1: unidirection SF_W raise after local lockout inpu= t > > > > in figure 1,consider the following procedure > > 1.LER1 and LER2 are both in NORMAL state and exchange NR PDU. > > 2.the lockout command input into LER1,then LER1 send LOCK to LER2,LER2 > > send NR to LER1. > > 3.a unidirection SF_W is raised in LER1,according RFC6378, LER1 still > > send LOCK to LER2,LER2 send NR to LER1. > > 4.the clear command input into LER1,according RFC6378,LER1 will send NR > > to LER2,LER2 still send NR to LER1. so traffic is broken. > > > > > > > > > > +------+ +------+ > > | LER1 | | LER2 | > > +---+--+ +---+--+ > > N +----------NR------------------->| N > > | | > > | | > > |<---------NR--------------------+ > > local lockout input | | > > | | > > UA:LO:L +-----------LOCK---------------->| > > | |UA:LO:R > > | | > > |<---------NR--------------------+ > > local clear input | | > > | | > > | | > > N +-------NR--------------.........| > > | | > > SF_W raise | this nr is lost for smth. | > > | and SF_W is raised. | > > | | > > +----------SF_W----------------->|always in > UA:LO:R > > | | > > | | > > | | > > |<-----------SF_W----------------+ > > | | > > | | > > > > figure 2: after clear a local LOCKOUT command,SF_W is raise > > immediately,and the NR send to LER2 is lost for something. > > > > in figure 2,consider the following procedure. > > 1.LER1 and LER2 are both in NORMAL state and exchange NR PDU. > > 2.the lockout command input into LER1,then LER1 send LOCK to LER2 and > > transfer to UA:LO:L,LER2 send NR to LER1 and transfer to UA:LO:R. > > 3.the clear command input into LER1,LER1 transfer to NR and send NR to > > LER2,but this NR is lost for some unknown reason, and SF_W is raised > > immediately in LER1,so that the NR that send by LER1 to LER2 is > > replaced by SF_W. > > 4.no NR reach LER2, if the error is bidirectional,LER2 > > will send SF_W to LER1,or NR to LER2 if unidirectional.but in any > > condition,LER2 will still in UA:LO:R state.the PSC is crashed. > > > > > > so i have 2 pieces of suggestion > > 1.LER always send his local highest priority to it's peer. > > 2.LER always accept the input from his peer by PSC PDU. > > > > > > > > > > > > > > Best Regards! > > > > > > > > Junbo Zeng(BoBo) > > > > > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > -- > > Thanx and BR, > > yaacov > > > > Still looking for new opportunity > > --047d7b5d43a4e251bf04d2fb8c3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PHA+SGksPC9wPgo8cD4xLiBJIGJlbGlldmUgdGhhdCB0aGlzIGlzIGFuIGltcGxlbWVudGF0aW9u IGlzc3VlLCBhbmQgdGhlcmVmb3JlIG91dCBvZiBzY29wZS48YnI+CjIuICZxdW90O0NvbnRyYWRp Y3RvcnkmcXVvdDsgbWVhbnMgYW55IG1lc3NhZ2UgdGhhdCBpbXBsaWVzIGEgZGlmZmVyZW50IHJl bW90ZSBzdGF0ZS48L3A+CjxwPkhvcGUgdGhpcyBoZWxwczwvcD4KPHA+QlIsPGJyPgp5YWFjb3Y8 L3A+CjxwPlN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1bml0eTxicj4KPC9wPgo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+T24gSmFuIDExLCAyMDEzIDQ6NDQgQU0sICZxdW90O+abvuWzu+az oiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpqYmRhbW9AaG90bWFpbC5jb20iPnpqYmRhbW9A aG90bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnIgdHlwZT0iYXR0cmlidXRpb24iPjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1s ZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgo8YnI+Cjxicj4KeWFhY292LHRo YW5rcyBmb3IgeW91ciBwYXRpZW50IGV4cGxhaW4uPGJyPgo8YnI+CjEuIFJlZ2FyZGluZyBTY2Vu YXJpbyAjMTphY2NvcmRpbmcgdGhlIFNlY3Rpb24gNC4zLjMuMSxpIHRoaW5rIHRoZSB0aGVyZSBu ZWVkIGEgbmV3IHN0YXRlIC0tLVRFTVBPUkFSWSBOT1JNQUwgU1RBVEUsanVzdCBhcyBpdHMgbmFt ZSBpbXBsaWVzLHRoaXMgc3RhdGUgaXMgYSB0ZW1wb3Jhcnkgc3RhdGUsYW5kIGluIHRoaXMgc3Rh dGUgTEVSIHNoYWxsIG5ldmVyIHNlbmQgTlIgUERVIHRvIGl0cyBwZWVyIGFuZCB3aWxsIGNoZWNr IGl0cyBsb2NhbCBwZXJzaXN0ZW50IHN0YXRlIHRvIGRlc2lkZSB0aGUgZmluYWwgc3RhdGUgYW5k IGluZm9ybSBpdHMgcGVlciBieSBQU0MgUERVIGFjY29yZGluZyB0aGlzIGZpbmFsIHN0YXRlLjxi cj4KCjxicj4KMi5SZWdhcmRpbmcgU2NlbmFyaW8gIzI6SSB3b25kZXIgaG93IHRvIGRlZmluZSAm cXVvdDtjb250cmFkaWN0b3J5JnF1b3Q7LiBhbnkgY2hhbmdlIG9mIHRoZSBQU0MgUERVIG9yIHRo ZSBQYXRoIGlzIG5vdCBzYW1lIHdpdGggcHJldmlvdXMgUFNDIFBEVSBvciBhbnkgb3RoZXI/PGJy Pgo8YnI+Cjxicj4KPGJyPgpCZXN0IFJlZ2FyZHMhPGJyPgpKdW5ibyBaZW5nKEJvQm8pPGJyPgo8 YnI+Cjxicj4KPGJyPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KJmd0OyBE YXRlOiBUaHUsIDEwIEphbiAyMDEzIDE5OjEyOjA4ICswMjAwPGJyPgomZ3Q7IFN1YmplY3Q6IFJl OiBbbXBsc10gaW4gc29tZSBzY2VuYXJpbyBSRkM2Mzc4IGNhbiBub3QgcHJvdGVjdCB0aGU8YnI+ CiZndDsgdHJhZmZpYywgc28gbXVjaCBhcyB0YWtlIHRoZSBQU0Mgc3RhdGUgdG8gY3Jhc2guPGJy PgomZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzp3eWFhY292QGdtYWlsLmNvbSI+d3lhYWNvdkBn bWFpbC5jb208L2E+PGJyPgomZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86empiZGFtb0Bob3RtYWls LmNvbSI+empiZGFtb0Bob3RtYWlsLmNvbTwvYT48YnI+CiZndDsgQ0M6IDxhIGhyZWY9Im1haWx0 bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnlhYWNv di53ZWluZ2FydGVuQG5zbi5jb20iPnlhYWNvdi53ZWluZ2FydGVuQG5zbi5jb208L2E+PGJyPgom Z3Q7PGJyPgomZ3Q7IEp1bmJvLCBoaTxicj4KJmd0Ozxicj4KJmd0OyBUaGFuayB5b3UgZm9yIHlv dXIgc2NlbmFyaW9zLiDCoEhvd2V2ZXIsIGJvdGggb2YgdGhlc2Ugc2NlbmFyaW9zIGFyZTxicj4K Jmd0OyBhZGRyZXNzZWQgYnkgdGhlIHRleHQgb2YgUkZDNjM3OC48YnI+CiZndDs8YnI+CiZndDsg MS4gUmVnYXJkaW5nIFNjZW5hcmlvICMxOiBUaGUgc2Vjb25kIHBhcmFncmFwaCBvZiBTZWN0aW9u IDQuMy4zLjE8YnI+CiZndDsgc3RhdGVzIC0gJnF1b3Q7V2hlbiB0aGUgTEVSIHRyYW5zaXRpb25z IGludG8gdGhlIE5vcm1hbCBzdGF0ZSwgdGhlIFBTQzxicj4KJmd0OyBDb250cm9sIFByb2Nlc3Mg U0hBTEwgY2hlY2sgdGhlIHBlcnNpc3RlbnQgc3RhdGUgb2YgdGhlIGxvY2FsIHRyaWdnZXJzPGJy PgomZ3Q7IHRvIGRlY2lkZSBpZiBpdCBzaG91bGQgZnVydGhlciB0cmFuc2l0aW9uIGludG8gYSBu ZXcgc3RhdGUuLi4uJnF1b3Q7IE1lYW5pbmc8YnI+CiZndDsgdGhhdCBpbiB5b3VyIHNjZW5hcmlv LCBhZnRlciByZWNlaXZpbmcgdGhlIENsZWFyLCBiZWZvcmUgdHJhbnNpdGlvbmluZzxicj4KJmd0 OyBpbnRvIE5vcm1hbCBTdGF0ZSwgTEVSLTEgc2hvdWxkIGhhdmUgY2hlY2tlZCB0aGUgc3RhdHVz IG9mIHRoZSBvdGhlcjxicj4KJmd0OyB0cmlnZ2VycyBhbmQgZGVjaWRlZCwgYmFzZWQgdXBvbiB0 aGUgc3RpbGwgYWN0aXZlIFNGLVcgdG8gdHJhbnNpdGlvbjxicj4KJmd0OyBpbnRvIFByb3RlY3Rp bmcgRmFpbHVyZSBzdGF0ZSwgdHJhbnNtaXR0aW5nIGEgU0YoMSwxKSBtZXNzYWdlLiBBcyB0bzxi cj4KJmd0OyB0aGUgcmVhY3Rpb24gb2YgTEVSLTIsIHNlZSBiZWxvdy48YnI+CiZndDs8YnI+CiZn dDsgMi4gUmVnYXJkaW5nIFNjZW5hcmlvICMyOiBUaGUgc2Vjb25kIHBhcmFncmFwaCBvZiBTZWN0 aW9uIDQuMy4zIHN0YXRlczxicj4KJmd0OyAtJnF1b3Q7V2hlbiBhIExFUiBpcyBpbiBhIHJlbW90 ZSBzdGF0ZSwgaS5lLiBzdGF0ZSB0cmFuc2l0aW9uIGluIHJlYWN0aW9uPGJyPgomZ3Q7IHRvIGEg UFNDIG1lc3NhZ2UgcmVjaWV2ZWQgZnJvbSB0aGUgZmFyLWVuZCBMRVIsIGFuZCByZWNlaXZlcyBh IG5ldzxicj4KJmd0OyBQU0MgbWVzc2FnZSBmcm9tIHRoZSBmYXItZW5kIExFUiB0aGF0IGluZGlj YXRlcyBhIGNvbnRyYWRpY3Rvcnk8YnI+CiZndDsgc3RhdGUsIGUuZy4gaW4gcmVtb3RlIFVuYXZh aWxhYmxlIHN0YXRlIHJlY2VpdmluZyBhIHJlbW90ZSBGUygxLDEpPGJyPgomZ3Q7IG1lc3NhZ2Us IHRoZW4gdGhlIFBTQyBDb250cm9sIExvZ2ljIFNIQUxMIHJlZXZhbHVhdGUgYWxsIGlucHV0cyAo Ym90aDxicj4KJmd0OyB0aGUgbG9jYWwgaW5wdXQgYW5kIHRoZSByZW1vdGUgbWVzc2FnZSkgYXMg aWYgdGhlIExFUiBpcyBpbiB0aGU8YnI+CiZndDsgTm9ybWFsIHN0YXRlLiZxdW90OyDCoE1lYW5p bmcgdGhhdCBpbiBib3RoIHRoZSBjb250aW51YXRpb24gb2YgdGhlIHByZXZpb3VzPGJyPgomZ3Q7 IHNjZW5hcmlvIGFzIHdlbGwgYXMgaW4geW91ciBzY2VuYXJpbywgTEVSLTIgc2hvdWxkIHJlYWN0 IHRvIHRoZSByZW1vdGU8YnI+CiZndDsgU0YgbWVzc2FnZSBhcyBpZiBpbiBOb3JtYWwgYW5kIHRy YW5zaXRpb24gaW50byBSZW1vdGUgUHJvdGVjdGluZzxicj4KJmd0OyBGYWlsdXJlIFN0YXRlLjxi cj4KJmd0Ozxicj4KJmd0OyBUaGVyZWZvcmUsIEkgY29udGVuZCB0aGF0IG5laXRoZXIgc2NlbmFy aW8gd2lsbCBjYXVzZSBQU0MgdG8gY3Jhc2guPGJyPgomZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7PGJy PgomZ3Q7IE9uIFRodSwgSmFuIDEwLCAyMDEzIGF0IDExOjEwIEFNLCDmm77ls7vms6I8YnI+CiZn dDsgJmx0OzxhIGhyZWY9Im1haWx0bzp6amJkYW1vQGhvdG1haWwuY29tIj56amJkYW1vQGhvdG1h aWwuY29tPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnpqYmRhbW9AaG90bWFpbC5jb20i PnpqYmRhbW9AaG90bWFpbC5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPgomZ3Q7PGJyPgomZ3Q7 PGJyPgomZ3Q7IChpZiB0aGUgZmlndXJlIGNhbiBub3QgZGlzcGxheSBub3JtYWxseSxwbGVhc2Ug c2VlIHRoZSBhdHRhY2ggZmlsZS50aGFua3MuKTxicj4KJmd0Ozxicj4KJmd0Ozxicj4KJmd0OyBX aGVuIGluIG11bHRpIGZhdWx0L3ByaW9yaXR5IGNvbmRpdGlvbiBzY2VuYXJpbyxSRkM2Mzc4IGNh biBub3QgcHJvdGVjdDxicj4KJmd0OyB0aGUgdHJhZmZpYyBzbyBtdWNoIGFzIHRha2UgdGhlIFBT QyBzdGF0ZSB0byBjcmFzaC5jb25zaWRlciB0aGU8YnI+CiZndDsgZm9sbG93aW5nIDIgc2NlbmFy aW8uPGJyPgomZ3Q7PGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgICstLS0tLS0rIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLS0tLS0rPGJyPgomZ3Q7IMKgIMKgIMKgIMKg IMKgIMKgIHwgTEVSMSB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgTEVS MiB8PGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgICstLS0rLS0rIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgICstLS0rLS0rPGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgICstLS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+CiZndDsgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHw8YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+CiZndDsgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfCZsdDstLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKzxicj4K Jmd0OyDCoCBsb2NhbCBsb2Nrb3V0IHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB8PGJyPgomZ3Q7IMKgIMKgaW5wdXQgwqAgwqAgwqAgwqB8IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4KJmd0OyDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCArLS0tLS0tLS0tLS1MT0NLLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJy PgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPgom Z3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwmbHQ7LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0t LS0tLS0tLSs8YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+CiZndDsgwqAgdW5pZGlyZWN0 aW9uIMKgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8 YnI+CiZndDsgwqAgU0ZfVyByYWlzZSDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICst LS0tLS0tLS0tLS0tTE9DSy0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+CiZndDsgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHw8YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgfCZsdDstLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKzxicj4KJmd0OyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgfDxicj4KJmd0OyDCoCBsb2NhbCBjbGVhciDCoCB8IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4KJmd0OyDCoCDCoGlucHV0 IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHw8YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tLS0tLS0tLS0tLU5SLS0t LS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4KJmd0OyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgfDxicj4KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8Jmx0Oy0t LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0rPGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8 PGJyPgomZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgZmlndXJlIDE6 IHVuaWRpcmVjdGlvbiBTRl9XIHJhaXNlIGFmdGVyIGxvY2FsIGxvY2tvdXQgaW5wdXQ8YnI+CiZn dDs8YnI+CiZndDsgaW4gZmlndXJlIDEsY29uc2lkZXIgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmU8 YnI+CiZndDsgMS5MRVIxIGFuZCBMRVIyIGFyZSBib3RoIGluIE5PUk1BTCBzdGF0ZSBhbmQgZXhj aGFuZ2UgTlIgUERVLjxicj4KJmd0OyAyLnRoZSBsb2Nrb3V0IGNvbW1hbmQgaW5wdXQgaW50byBM RVIxLHRoZW4gTEVSMSBzZW5kIExPQ0sgdG8gTEVSMixMRVIyPGJyPgomZ3Q7IHNlbmQgTlIgdG8g TEVSMS48YnI+CiZndDsgMy5hIHVuaWRpcmVjdGlvbiBTRl9XIGlzIHJhaXNlZCBpbiBMRVIxLGFj Y29yZGluZyBSRkM2Mzc4LCBMRVIxIHN0aWxsPGJyPgomZ3Q7IHNlbmQgTE9DSyB0byBMRVIyLExF UjIgc2VuZCBOUiB0byBMRVIxLjxicj4KJmd0OyA0LnRoZSBjbGVhciBjb21tYW5kIGlucHV0IGlu dG8gTEVSMSxhY2NvcmRpbmcgUkZDNjM3OCxMRVIxIHdpbGwgc2VuZCBOUjxicj4KJmd0OyB0byBM RVIyLExFUjIgc3RpbGwgc2VuZCBOUiB0byBMRVIxLiBzbyB0cmFmZmljIGlzIGJyb2tlbi48YnI+ CiZndDs8YnI+CiZndDs8YnI+CiZndDs8YnI+CiZndDs8YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqArLS0tLS0tKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCArLS0tLS0tKzxicj4KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHwgTEVSMSB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgTEVSMiB8 PGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLSstLSsgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tLSstLSs8YnI+CiZndDsgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgTiDCoCDCoCstLS0tLS0tLS0tTlItLS0tLS0tLS0t LS0tLS0tLS0tJmd0O3wgwqAgwqAgwqAgTjxicj4KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB8PGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8 YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8Jmx0Oy0t LS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rPGJyPgomZ3Q7IMKgIMKgIMKgIGxvY2FsIGxv Y2tvdXQgaW5wdXQgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgfDxicj4KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPgom Z3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVUE6TE86TCArLS0tLS0tLS0tLS1MT0NL LS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHxVQTpMTzpSPGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHw8YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8Jmx0 Oy0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rPGJyPgomZ3Q7IMKgIMKgIMKgIMKgIGxv Y2FsIGNsZWFyIGlucHV0IMKgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHw8YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxi cj4KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPgomZ3Q7IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE4gwqArLS0tLS0tLU5SLS0tLS0tLS0tLS0t LS0uLi4uLi4uLi58PGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8 YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBTRl9XIHJhaXNlIMKgfCB0aGlzIG5yIGlz IGxvc3QgZm9yIHNtdGguIMKgIMKgIMKgfDxicj4KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHwgYW5kIFNGX1cgaXMgcmFpc2VkLiDCoCDCoCDCoCDCoCDCoCDC oHw8YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4KJmd0OyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tU0ZfVy0t LS0tLS0tLS0tLS0tLS0tJmd0O3xhbHdheXMgaW4gVUE6TE86Ujxicj4KJmd0OyDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPgomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHw8YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxi cj4KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwmbHQ7LS0t LS0tLS0tLS1TRl9XLS0tLS0tLS0tLS0tLS0tLSs8YnI+CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgfDxicj4KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB8PGJyPgomZ3Q7PGJyPgomZ3Q7IMKgIMKgIMKgIMKgZmlndXJlIDI6IGFmdGVyIGNsZWFyIGEg bG9jYWwgTE9DS09VVCBjb21tYW5kLFNGX1cgaXMgcmFpc2U8YnI+CiZndDsgaW1tZWRpYXRlbHks YW5kIHRoZSBOUiBzZW5kIHRvIExFUjIgaXMgbG9zdCBmb3Igc29tZXRoaW5nLjxicj4KJmd0Ozxi cj4KJmd0OyBpbiBmaWd1cmUgMixjb25zaWRlciB0aGUgZm9sbG93aW5nIHByb2NlZHVyZS48YnI+ CiZndDsgMS5MRVIxIGFuZCBMRVIyIGFyZSBib3RoIGluIE5PUk1BTCBzdGF0ZSBhbmQgZXhjaGFu Z2UgTlIgUERVLjxicj4KJmd0OyAyLnRoZSBsb2Nrb3V0IGNvbW1hbmQgaW5wdXQgaW50byBMRVIx LHRoZW4gTEVSMSBzZW5kIExPQ0sgdG8gTEVSMiBhbmQ8YnI+CiZndDsgdHJhbnNmZXIgdG8gVUE6 TE86TCxMRVIyIHNlbmQgTlIgdG8gTEVSMSBhbmQgdHJhbnNmZXIgdG8gVUE6TE86Ui48YnI+CiZn dDsgMy50aGUgY2xlYXIgY29tbWFuZCBpbnB1dCBpbnRvIExFUjEsTEVSMSB0cmFuc2ZlciB0byBO UiBhbmQgc2VuZCBOUiB0bzxicj4KJmd0OyBMRVIyLGJ1dCB0aGlzIE5SIGlzIGxvc3QgZm9yIHNv bWUgdW5rbm93biByZWFzb24sIGFuZCBTRl9XIGlzIHJhaXNlZDxicj4KJmd0OyBpbW1lZGlhdGVs eSBpbiBMRVIxLHNvIHRoYXQgdGhlIE5SIHRoYXQgc2VuZCBieSBMRVIxIHRvIExFUjIgaXM8YnI+ CiZndDsgcmVwbGFjZWQgYnkgU0ZfVy48YnI+CiZndDsgPGEgaHJlZj0iaHR0cDovLzQubm8iIHRh cmdldD0iX2JsYW5rIj40Lm5vPC9hPiZsdDs8YSBocmVmPSJodHRwOi8vNC5ubyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly80Lm5vPC9hPiZndDsgTlIgcmVhY2ggTEVSMiwgaWYgdGhlIGVycm9yIGlz IGJpZGlyZWN0aW9uYWwsTEVSMjxicj4KJmd0OyB3aWxsIHNlbmQgU0ZfVyB0byBMRVIxLG9yIE5S IHRvIExFUjIgaWYgdW5pZGlyZWN0aW9uYWwuYnV0IGluIGFueTxicj4KJmd0OyBjb25kaXRpb24s TEVSMiB3aWxsIHN0aWxsIGluIFVBOkxPOlIgc3RhdGUudGhlIFBTQyBpcyBjcmFzaGVkLjxicj4K Jmd0Ozxicj4KJmd0Ozxicj4KJmd0OyBzbyBpIGhhdmUgMiBwaWVjZXMgb2Ygc3VnZ2VzdGlvbjxi cj4KJmd0OyAxLkxFUiBhbHdheXMgc2VuZCBoaXMgbG9jYWwgaGlnaGVzdCBwcmlvcml0eSB0byBp dCYjMzk7cyBwZWVyLjxicj4KJmd0OyAyLkxFUiBhbHdheXMgYWNjZXB0IHRoZSBpbnB1dCBmcm9t IGhpcyBwZWVyIGJ5IFBTQyBQRFUuPGJyPgomZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7 PGJyPgomZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7IEJlc3QgUmVnYXJkcyE8YnI+CiZndDs8YnI+CiZn dDs8YnI+CiZndDs8YnI+CiZndDsgSnVuYm8gWmVuZyhCb0JvKTxicj4KJmd0Ozxicj4KJmd0Ozxi cj4KJmd0Ozxicj4KJmd0Ozxicj4KJmd0Ozxicj4KJmd0Ozxicj4KJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KJmd0OyBtcGxzIG1haWxpbmcg bGlzdDxicj4KJmd0OyA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9y ZzwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYu b3JnPC9hPiZndDs8YnI+CiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzPC9hPjxicj4KJmd0Ozxicj4KJmd0Ozxicj4KJmd0Ozxicj4KJmd0 Ozxicj4KJmd0OyAtLTxicj4KJmd0OyBUaGFueCBhbmQgQlIsPGJyPgomZ3Q7IHlhYWNvdjxicj4K Jmd0Ozxicj4KJmd0OyBTdGlsbCBsb29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHk8YnI+Cjxicj4K PC9ibG9ja3F1b3RlPjwvZGl2Pgo= --047d7b5d43a4e251bf04d2fb8c3a-- From zjbdamo@hotmail.com Thu Jan 10 22:58:37 2013 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 58C5821F87CE for ; Thu, 10 Jan 2013 22:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.076 X-Spam-Level: **** X-Spam-Status: No, score=4.076 tagged_above=-999 required=5 tests=[AWL=-2.025, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_57=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3] 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 AvEzUn-R5maf for ; Thu, 10 Jan 2013 22:58:36 -0800 (PST) Received: from blu0-omc3-s11.blu0.hotmail.com (blu0-omc3-s11.blu0.hotmail.com [65.55.116.86]) by ietfa.amsl.com (Postfix) with ESMTP id CA94121F87A3 for ; Thu, 10 Jan 2013 22:58:35 -0800 (PST) Received: from BLU168-W13 ([65.55.116.72]) by blu0-omc3-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jan 2013 22:58:34 -0800 X-EIP: [7Ggq/44ANJ9AdUeHl5nbDccjif8giLsf] X-Originating-Email: [zjbdamo@hotmail.com] Message-ID: Content-Type: multipart/mixed; boundary="_43cb0e82-ed17-4dc1-874b-d8bb77ff2ec8_" From: =?utf-8?B?5pu+5bO75rOi?= To: Date: Fri, 11 Jan 2013 14:58:34 +0800 Importance: Normal In-Reply-To: References: , , , MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2013 06:58:34.0998 (UTC) FILETIME=[13021160:01CDEFC9] Cc: mpls@ietf.org Subject: Re: [mpls] in some scenario RFC6378 can not protect the traffic, so much as take the PSC state to crash. 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, 11 Jan 2013 06:58:37 -0000 --_43cb0e82-ed17-4dc1-874b-d8bb77ff2ec8_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KKGlmIGZpZ3VyZTMgaXMgbm90IGRpc3BsYXkgbm9ybWFsbHkscGxlYXNlIHNlZSBhdHRh Y2ggZmlsZSx0aGFua3MuKQ0KDQpoaSwNCg0KMS4geWVzLGkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0 aGUgVEVNUE9SQVJZIE5PUk1BTCBTVEFURSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZSxidXQg aSB0aGluayBhdXRob3Igb2YgUkZDIHNoYWxsIG1ha2Ugc3VyZSB0aGUgc3RhbmRhcmQgaXMgY2xl YXIgYW5kIG5vIGFtYmlndWl0eS51c3VhbGx5LGEgbmV0d29yayBpcyBjb21wb3NlZCBvZiBkaWZm ZXJlbnQgZXF1aXBtZW50IGNvbWUgZnJvbSBkaWZmZXJlbnQgY29tcGF5LExFUjEgYW5kIExFUjIg d2lsbCBpbnRlcndvcmsgd2l0aCBlYWNoIG90aGVyIGFjY29yZGluZyBSRkM2Mzc4LiBpZiB0aGVy ZSBpcyBhYnNlbmNlIG9mIFRFTVBPUkFSWSBOT1JNQUwgU1RBVEUgZGVmaW5hdGlvbixteWJlIExF UjEgaW4gVEVNUE9SQVJZIE5PUk1BTCBTVEFURSBzZW5kIE5SIHRvIGl0cyBwZWVyIGFuZCBMRVIy IGRvbid0IHNlbmQgTlIgdG8gaXRzIHBlZXIsdGhpcyB3aWxsIG1ha2UgdGhlIFBTQyBzdGF0ZSBj aGFvcy4NCg0KDQoNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgICstLS0tLS0rwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgICstLS0tLS0rDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB8IExFUjEgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB8IExFUjIgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgKy0tLSstLSvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgKy0tLSstLSsNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBOwqDCoMKgICstLS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0t PnzCoCBODQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8LS0tLS0tLS0tTlItLS0tLS0tLS0t LS0tLS0tLS0tLSsNCsKgwqDCoMKgwqAgdW5pZGlyZWN0aW9uIFNGX1cgcmFpc2UgfMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwN CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgKy0tLS0tLS0tLS0tU0ZfVy0tLS0tLS0tLS0tLS0tLS0+fA0KwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCB8PC0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQrC oMKgwqDCoMKgIGxvY2FsIEZTIGNvbW1hbmQgaW5wdXTCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0K wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBQQTpGOkzCoMKgICstLS0t LS0tLS0tLUZTLS0tLS0tLS0tLS0tLS0tLS0tPnwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHxQQTpGOlINCsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgfDwtLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KwqDCoMKgwqDCoMKgwqDC oMKgwqAgbG9jYWwgY2xlYXIgaW5wdXTCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg fA0KwqDCoMKgwqDCoMKgIFRFTVBPUkFSWSBOT1JNQUwgU1RBVEUgKy0tLS0tLS1OUi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0+fCBODQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIHzCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfGlmIHRoaXMgTlIgcmVhY2gsTEVSMiB3aWxsDQrC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoCB8 wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgfHN3aXRjaCB0cmFmZmljIHRvIHdvcmsgcGF0aCwNCsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8dGhpcyB3aWxsIGJy b2tlbiB0aGUgdHJhZmZpYy4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgVsKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqAgZmluYWwgc3RhdGXCoCBQ RjpXOkzCoMKgwqAgKy0tLS0tLS0tLS1TRl9XLS0tLS0tLS0tLS0tLS0tLS0+fFBGOldfUg0KwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8 wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgfExFUjIgd2lsbCBzd2l0Y2ggdHJhZmZpYyB0bw0KwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfHByb3RlY3Rpb24g cGF0aCx0cmFmZmljIGlzDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8cmVzdG9yZWQuDQrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8LS0tLS0tLS0tLS1OUi0t LS0tLS0tLS0tLS0tLS0tLSsNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoCDCoMKgwqAg wqDCoMKgIGZpZ3VyZSAzOmxhY2sgb2YgVEVNUE9SQVJZIE5PUk1BTCBTVEFURSx0cmFmZmljIHdp bGwgYmUgYnJva2VuIGFjY2lkZW50YWxseS4NCg0Kd2hlbiB0aGUgZmxvdyBhcnJpdmVkIGFkIHRo ZSBURU1QT1JBUlkgTk9STUFMIFNUQVRFLGlmIExFUjEgc2VuZCBOUiB0byBpdHMgcGVlcix0aGVu IHRoZSB0cmFmZmljIGlzIGJyb2tlbiBmb3IgYSB3aGlsZSBhY2NpZGVudGFsbHksYW5kIHJlc3Rv cmUgd2hlbiB0aGUgU0ZfVyByZWFjaCBMRVIyLnNvLCBpIHRoaW5rIHRoZSBURU1QT1JBUlkgTk9S TUFMIFNUQVRFIHNoYWxsIGJlIGFkZCB0byB0aGUgUFNDIHN0YXRlIHRvIG1ha2UgdGhlIHN0YXRl IG1hY2hpbmUgY2xlYXIgYW5kIG5vIGFtYmlndWl0eS4NCg0KDQoyLmlmIHRoZSAiQ29udHJhZGlj dG9yeSIgbWVhbnMgYW55IG1lc3NhZ2UgdGhhdCBpbXBsaWVzIGEgZGlmZmVyZW50IHJlbW90ZSBz dGF0ZSx0aGlzIGlzIGFncmVlIHdpdGggbXkgc3VnZ2VzdGlvbiAyOkxFUiBhbHdheXMgYWNjZXB0 IHRoZSBpbnB1dCBmcm9tIGhpcyBwZWVyIGJ5IFBTQyBQRFUuYW5kIGFjY29yZGluZyB0aGUgZGVm aW5hdGlvbiBvZiAiQ29udHJhZGljdG9yeSIsdGhlcmUgYXJlIHNvbWUgZGVzY3JpcHRpb24gaW4g UkZDNjM3OCBzaG91bGQgYmUgY29ycmVjdCxmb3IgZXhhbXBsZQ0KYS5pbiA0LjMuMy4yIC0tIkEg cmVtb3RlIEZvcmNlZCBTd2l0Y2ggbWVzc2FnZSBTSEFMTCBiZSBpZ25vcmVkIGJ5IHRoZSBQU0Mg Q29udHJvbCBsb2dpYyB3aGVuIGluIFVuYXZhaWxhYmxlIHN0YXRlIGFzIGEgcmVzdWx0IG9mIGEg KGxvY2FsIG9yIHJlbW90ZSkgTG9ja291dCBvZiBwcm90ZWN0aW9uLiLCoCBpZiB0aGUgRlMgbWVz c2FnZSBpcyBkaWZlcnJlbnQgZnJvbSBwcmV2aW91cyBQU0MgbXNnLGl0IHNob3VsZCBiZSBhY2Nl cHRlZC4gDQpiLmluIHRoZSBBcHBlbmRpeCBBLiBQU0MgU3RhdGUgTWFjaGluZSBUYWJsZXMsUGFy dCAyOiBSZW1vdGUgbWVzc2FnZXMgc3RhdGUgbWFjaGluZSAtLSAiDQrCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHwgTE/CoMKgwqAgfCBTRi1QIHwgRlPCoMKgIHwgU0YtVyB8IE1TwqDCoCB8 IFdUUsKgIHwgRE5SwqAgfCBOUg0KwqDCoMKgwqDCoMKgIC0tLS0tLS0tKy0tLS0tLS0rLS0tLS0t Ky0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tDQrCoMKgwqDCoMKgwqAg TsKgwqDCoMKgwqDCoCB8VUE6TE86UnxVQTpQOlJ8UEE6RjpSfFBGOlc6UnxQQTpNOlJ8IGnCoMKg wqAgfCBpwqDCoMKgIHwgaQ0KwqDCoMKgwqDCoMKgIFVBOkxPOkwgfCBpwqDCoMKgwqAgfCBpwqDC oMKgIHwgacKgwqDCoCB8IGnCoMKgwqAgfCBpwqDCoMKgIHwgacKgwqDCoCB8IGnCoMKgwqAgfCBp DQrCoMKgwqDCoMKgwqAgVUE6UDpMwqAgfCBbMTBdwqAgfCBpwqDCoMKgIHwgWzE5XSB8IGnCoMKg wqAgfCBpwqDCoMKgIHwgacKgwqDCoCB8IGnCoMKgwqAgfCBpDQrCoMKgwqDCoMKgwqAgVUE6TE86 UiB8IGnCoMKgwqDCoCB8IGnCoMKgwqAgfCBpwqDCoMKgIHwgacKgwqDCoCB8IGnCoMKgwqAgfCBp wqDCoMKgIHwgacKgwqDCoCB8IFsxNl0NCsKgwqDCoMKgwqDCoCBVQTpQOlLCoCB8VUE6TE86Unwg acKgwqDCoCB8UEE6RjpSfCBpwqDCoMKgIHwgacKgwqDCoCB8IGnCoMKgwqAgfCBpwqDCoMKgIHwg WzE2XQ0KwqDCoMKgwqDCoMKgIFBGOlc6TMKgIHwgWzExXcKgIHwgWzEyXSB8UEE6RjpSfCBpwqDC oMKgIHwgacKgwqDCoCB8IGnCoMKgwqAgfCBpwqDCoMKgIHwgaQ0KwqDCoMKgwqDCoMKgIFBGOlc6 UsKgIHxVQTpMTzpSfFVBOlA6UnxQQTpGOlJ8IGnCoMKgwqAgfCBpwqDCoMKgIHwgWzE0XSB8IFsx NV0gfCBODQrCoMKgwqDCoMKgwqAgUEE6RjpMwqAgfFVBOkxPOlJ8IGnCoMKgwqAgfCBpwqDCoMKg IHwgacKgwqDCoCB8IGnCoMKgwqAgfCBpwqDCoMKgIHwgacKgwqDCoCB8IGkNCsKgwqDCoMKgwqDC oCBQQTpNOkzCoCB8VUE6TE86UnxVQTpQOlJ8UEE6RjpSfCBbMTNdIHwgacKgwqDCoCB8IGnCoMKg wqAgfCBpwqDCoMKgIHwgaQ0KwqDCoMKgwqDCoMKgIFBBOkY6UsKgIHxVQTpMTzpSfCBpwqDCoMKg IHwgacKgwqDCoCB8IGnCoMKgwqAgfCBpwqDCoMKgIHwgacKgwqDCoCB8IEROUsKgIHwgWzE3XQ0K wqDCoMKgwqDCoMKgIFBBOk06UsKgIHxVQTpMTzpSfFVBOlA6UnxQQTpGOlJ8IFsxM10gfCBpwqDC oMKgIHwgacKgwqDCoCB8IEROUsKgIHwgTg0KwqDCoMKgwqDCoMKgIFdUUsKgwqDCoMKgIHxVQTpM TzpSfFVBOlA6UnxQQTpGOlJ8UEY6VzpSfFBBOk06UnwgacKgwqDCoCB8IGnCoMKgwqAgfCBbMThd DQrCoMKgwqDCoMKgwqAgRE5SwqDCoMKgwqAgfFVBOkxPOlJ8VUE6UDpSfFBBOkY6UnxQRjpXOlJ8 UEE6TTpSfCBpwqDCoMKgIHwgacKgwqDCoCB8IGkNCiJtb3N0IG9mIHRoZSBJZ25vcmUgc2hhbGwg YmUgY2hhbmdlLg0KYy5zb21lIG90aGVyIHNpbWlsYXIgZGVzY3JpcHRpb24gc2hhbGwgYmUgY29y cmVjdC4NCg0KDQpCZXN0IFJlZ2FyZHMhIA0KSnVuYm8gWmVuZyhCb0JvKSANCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEYXRlOiBGcmksIDExIEphbiAyMDEzIDA2OjE1 OjQ4ICswMjAwIA0KPiBTdWJqZWN0OiBSRTogW21wbHNdIGluIHNvbWUgc2NlbmFyaW8gUkZDNjM3 OCBjYW4gbm90IHByb3RlY3QgdGhlICANCj4gdHJhZmZpYywgc28gbXVjaCBhcyB0YWtlIHRoZSBQ U0Mgc3RhdGUgdG8gY3Jhc2guIA0KPiBGcm9tOiB3eWFhY292QGdtYWlsLmNvbSANCj4gVG86IHpq YmRhbW9AaG90bWFpbC5jb20gDQo+IENDOiBtcGxzQGlldGYub3JnIA0KPiAgDQo+ICANCj4gSGks IA0KPiAgDQo+IDEuIEkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24gaXNz dWUsIGFuZCB0aGVyZWZvcmUgb3V0IG9mICANCj4gc2NvcGUuIA0KPiAyLiAiQ29udHJhZGljdG9y eSIgbWVhbnMgYW55IG1lc3NhZ2UgdGhhdCBpbXBsaWVzIGEgZGlmZmVyZW50IHJlbW90ZSBzdGF0 ZS4gDQo+ICANCj4gSG9wZSB0aGlzIGhlbHBzIA0KPiAgDQo+IEJSLCANCj4geWFhY292IA0KPiAg DQo+IFN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1bml0eSANCj4gIA0KPiBPbiBKYW4gMTEs IDIwMTMgNDo0NCBBTSwgIuabvuWzu+azoiIgIA0KPiA8empiZGFtb0Bob3RtYWlsLmNvbTxtYWls dG86empiZGFtb0Bob3RtYWlsLmNvbT4+IHdyb3RlOiANCj4gIA0KPiAgDQo+IHlhYWNvdix0aGFu a3MgZm9yIHlvdXIgcGF0aWVudCBleHBsYWluLiANCj4gIA0KPiAxLiBSZWdhcmRpbmcgU2NlbmFy aW8gIzE6YWNjb3JkaW5nIHRoZSBTZWN0aW9uIDQuMy4zLjEsaSB0aGluayB0aGUgIA0KPiB0aGVy ZSBuZWVkIGEgbmV3IHN0YXRlIC0tLVRFTVBPUkFSWSBOT1JNQUwgU1RBVEUsanVzdCBhcyBpdHMg bmFtZSAgDQo+IGltcGxpZXMsdGhpcyBzdGF0ZSBpcyBhIHRlbXBvcmFyeSBzdGF0ZSxhbmQgaW4g dGhpcyBzdGF0ZSBMRVIgc2hhbGwgIA0KPiBuZXZlciBzZW5kIE5SIFBEVSB0byBpdHMgcGVlciBh bmQgd2lsbCBjaGVjayBpdHMgbG9jYWwgcGVyc2lzdGVudCBzdGF0ZSAgDQo+IHRvIGRlc2lkZSB0 aGUgZmluYWwgc3RhdGUgYW5kIGluZm9ybSBpdHMgcGVlciBieSBQU0MgUERVIGFjY29yZGluZyB0 aGlzICANCj4gZmluYWwgc3RhdGUuIA0KPiAgDQo+IDIuUmVnYXJkaW5nIFNjZW5hcmlvICMyOkkg d29uZGVyIGhvdyB0byBkZWZpbmUgImNvbnRyYWRpY3RvcnkiLiBhbnkgIA0KPiBjaGFuZ2Ugb2Yg dGhlIFBTQyBQRFUgb3IgdGhlIFBhdGggaXMgbm90IHNhbWUgd2l0aCBwcmV2aW91cyBQU0MgUERV IG9yICANCj4gYW55IG90aGVyPyANCj4gIA0KPiAgDQo+ICANCj4gQmVzdCBSZWdhcmRzISANCj4g SnVuYm8gWmVuZyhCb0JvKSANCj4gIA0KPiAgDQo+ICANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gDQo+ICA+IERhdGU6IFRodSwgMTAgSmFuIDIwMTMgMTk6MTI6MDggKzAyMDAg DQo+ICA+IFN1YmplY3Q6IFJlOiBbbXBsc10gaW4gc29tZSBzY2VuYXJpbyBSRkM2Mzc4IGNhbiBu b3QgcHJvdGVjdCB0aGUgDQo+ICA+IHRyYWZmaWMsIHNvIG11Y2ggYXMgdGFrZSB0aGUgUFNDIHN0 YXRlIHRvIGNyYXNoLiANCj4gID4gRnJvbTogd3lhYWNvdkBnbWFpbC5jb208bWFpbHRvOnd5YWFj b3ZAZ21haWwuY29tPiANCj4gID4gVG86IHpqYmRhbW9AaG90bWFpbC5jb208bWFpbHRvOnpqYmRh bW9AaG90bWFpbC5jb20+IA0KPiAgPiBDQzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRm Lm9yZz47ICANCj4geWFhY292LndlaW5nYXJ0ZW5AbnNuLmNvbTxtYWlsdG86eWFhY292LndlaW5n YXJ0ZW5AbnNuLmNvbT4gDQo+ICA+IA0KPiAgPiBKdW5ibywgaGkgDQo+ICA+IA0KPiAgPiBUaGFu ayB5b3UgZm9yIHlvdXIgc2NlbmFyaW9zLiAgSG93ZXZlciwgYm90aCBvZiB0aGVzZSBzY2VuYXJp b3MgYXJlIA0KPiAgPiBhZGRyZXNzZWQgYnkgdGhlIHRleHQgb2YgUkZDNjM3OC4gDQo+ICA+IA0K PiAgPiAxLiBSZWdhcmRpbmcgU2NlbmFyaW8gIzE6IFRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIFNl Y3Rpb24gNC4zLjMuMSANCj4gID4gc3RhdGVzIC0gIldoZW4gdGhlIExFUiB0cmFuc2l0aW9ucyBp bnRvIHRoZSBOb3JtYWwgc3RhdGUsIHRoZSBQU0MgDQo+ICA+IENvbnRyb2wgUHJvY2VzcyBTSEFM TCBjaGVjayB0aGUgcGVyc2lzdGVudCBzdGF0ZSBvZiB0aGUgbG9jYWwgdHJpZ2dlcnMgDQo+ICA+ IHRvIGRlY2lkZSBpZiBpdCBzaG91bGQgZnVydGhlciB0cmFuc2l0aW9uIGludG8gYSBuZXcgc3Rh dGUuLi4uIiBNZWFuaW5nIA0KPiAgPiB0aGF0IGluIHlvdXIgc2NlbmFyaW8sIGFmdGVyIHJlY2Vp dmluZyB0aGUgQ2xlYXIsIGJlZm9yZSB0cmFuc2l0aW9uaW5nIA0KPiAgPiBpbnRvIE5vcm1hbCBT dGF0ZSwgTEVSLTEgc2hvdWxkIGhhdmUgY2hlY2tlZCB0aGUgc3RhdHVzIG9mIHRoZSBvdGhlciAN Cj4gID4gdHJpZ2dlcnMgYW5kIGRlY2lkZWQsIGJhc2VkIHVwb24gdGhlIHN0aWxsIGFjdGl2ZSBT Ri1XIHRvIHRyYW5zaXRpb24gDQo+ICA+IGludG8gUHJvdGVjdGluZyBGYWlsdXJlIHN0YXRlLCB0 cmFuc21pdHRpbmcgYSBTRigxLDEpIG1lc3NhZ2UuIEFzIHRvIA0KPiAgPiB0aGUgcmVhY3Rpb24g b2YgTEVSLTIsIHNlZSBiZWxvdy4gDQo+ICA+IA0KPiAgPiAyLiBSZWdhcmRpbmcgU2NlbmFyaW8g IzI6IFRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4zLjMgc3RhdGVzIA0KPiAgPiAt IldoZW4gYSBMRVIgaXMgaW4gYSByZW1vdGUgc3RhdGUsIGkuZS4gc3RhdGUgdHJhbnNpdGlvbiBp biByZWFjdGlvbiANCj4gID4gdG8gYSBQU0MgbWVzc2FnZSByZWNpZXZlZCBmcm9tIHRoZSBmYXIt ZW5kIExFUiwgYW5kIHJlY2VpdmVzIGEgbmV3IA0KPiAgPiBQU0MgbWVzc2FnZSBmcm9tIHRoZSBm YXItZW5kIExFUiB0aGF0IGluZGljYXRlcyBhIGNvbnRyYWRpY3RvcnkgDQo+ICA+IHN0YXRlLCBl LmcuIGluIHJlbW90ZSBVbmF2YWlsYWJsZSBzdGF0ZSByZWNlaXZpbmcgYSByZW1vdGUgRlMoMSwx KSANCj4gID4gbWVzc2FnZSwgdGhlbiB0aGUgUFNDIENvbnRyb2wgTG9naWMgU0hBTEwgcmVldmFs dWF0ZSBhbGwgaW5wdXRzIChib3RoIA0KPiAgPiB0aGUgbG9jYWwgaW5wdXQgYW5kIHRoZSByZW1v dGUgbWVzc2FnZSkgYXMgaWYgdGhlIExFUiBpcyBpbiB0aGUgDQo+ICA+IE5vcm1hbCBzdGF0ZS4i ICBNZWFuaW5nIHRoYXQgaW4gYm90aCB0aGUgY29udGludWF0aW9uIG9mIHRoZSBwcmV2aW91cyAN Cj4gID4gc2NlbmFyaW8gYXMgd2VsbCBhcyBpbiB5b3VyIHNjZW5hcmlvLCBMRVItMiBzaG91bGQg cmVhY3QgdG8gdGhlIHJlbW90ZSANCj4gID4gU0YgbWVzc2FnZSBhcyBpZiBpbiBOb3JtYWwgYW5k IHRyYW5zaXRpb24gaW50byBSZW1vdGUgUHJvdGVjdGluZyANCj4gID4gRmFpbHVyZSBTdGF0ZS4g DQo+ICA+IA0KPiAgPiBUaGVyZWZvcmUsIEkgY29udGVuZCB0aGF0IG5laXRoZXIgc2NlbmFyaW8g d2lsbCBjYXVzZSBQU0MgdG8gY3Jhc2guIA0KPiAgPiANCj4gID4gDQo+ICA+IA0KPiAgPiBPbiBU aHUsIEphbiAxMCwgMjAxMyBhdCAxMToxMCBBTSwg5pu+5bO75rOiIA0KPiAgPiAgDQo+IDx6amJk YW1vQGhvdG1haWwuY29tPG1haWx0bzp6amJkYW1vQGhvdG1haWwuY29tPjxtYWlsdG86empiZGFt b0Bob3RtYWlsLmNvbTxtYWlsdG86empiZGFtb0Bob3RtYWlsLmNvbT4+PiAgDQo+IHdyb3RlOiAN Cj4gID4gDQo+ICA+IA0KPiAgPiAoaWYgdGhlIGZpZ3VyZSBjYW4gbm90IGRpc3BsYXkgbm9ybWFs bHkscGxlYXNlIHNlZSB0aGUgYXR0YWNoIGZpbGUudGhhbmtzLikgDQo+ICA+IA0KPiAgPiANCj4g ID4gV2hlbiBpbiBtdWx0aSBmYXVsdC9wcmlvcml0eSBjb25kaXRpb24gc2NlbmFyaW8sUkZDNjM3 OCBjYW4gbm90IHByb3RlY3QgDQo+ICA+IHRoZSB0cmFmZmljIHNvIG11Y2ggYXMgdGFrZSB0aGUg UFNDIHN0YXRlIHRvIGNyYXNoLmNvbnNpZGVyIHRoZSANCj4gID4gZm9sbG93aW5nIDIgc2NlbmFy aW8uIA0KPiAgPiANCj4gID4gICAgICAgICAgICAgKy0tLS0tLSsgICAgICAgICAgICAgICAgICAg ICAgICAgKy0tLS0tLSsgDQo+ICA+ICAgICAgICAgICAgIHwgTEVSMSB8ICAgICAgICAgICAgICAg ICAgICAgICAgIHwgTEVSMiB8IA0KPiAgPiAgICAgICAgICAgICArLS0tKy0tKyAgICAgICAgICAg ICAgICAgICAgICAgICArLS0tKy0tKyANCj4gID4gICAgICAgICAgICAgICAgICstLS0tLS0tLS0t TlItLS0tLS0tLS0tLS0tLS0tLS0tPnwgDQo+ICA+ICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IA0KPiAgPiAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4gID4gICAgICAgICAgICAgICAgIHw8LS0tLS0t LS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQo+ICA+ICAgbG9jYWwgbG9ja291dCB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KPiAgPiAgICBpbnB1dCAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4gID4gICAgICAgICAgICAgICAgICstLS0t LS0tLS0tLUxPQ0stLS0tLS0tLS0tLS0tLS0tPnwgDQo+ICA+ICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KPiAgPiAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4gID4gICAgICAgICAgICAgICAgIHw8 LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQo+ICA+ICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KPiAgPiAgIHVuaWRpcmVjdGlvbiAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4gID4gICBTRl9XIHJhaXNlICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQo+ICA+ICAgICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLUxPQ0stLS0tLS0tLS0tLS0tLT58IA0KPiAgPiAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4gID4gICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQo+ICA+ICAgICAgICAgICAg ICAgICB8PC0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KPiAgPiAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4gID4gICBsb2NhbCBj bGVhciAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQo+ICA+ICAgIGlucHV0 ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KPiAgPiAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0+fCANCj4gID4gICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQo+ICA+ICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KPiAgPiAgICAg ICAgICAgICAgICAgfDwtLS0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tKyANCj4gID4gICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQo+ICA+IA0K PiAgPiANCj4gID4gICAgICAgICAgICAgIGZpZ3VyZSAxOiB1bmlkaXJlY3Rpb24gU0ZfVyByYWlz ZSBhZnRlciBsb2NhbCBsb2Nrb3V0IGlucHV0IA0KPiAgPiANCj4gID4gaW4gZmlndXJlIDEsY29u c2lkZXIgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgDQo+ICA+IDEuTEVSMSBhbmQgTEVSMiBhcmUg Ym90aCBpbiBOT1JNQUwgc3RhdGUgYW5kIGV4Y2hhbmdlIE5SIFBEVS4gDQo+ICA+IDIudGhlIGxv Y2tvdXQgY29tbWFuZCBpbnB1dCBpbnRvIExFUjEsdGhlbiBMRVIxIHNlbmQgTE9DSyB0byBMRVIy LExFUjIgDQo+ICA+IHNlbmQgTlIgdG8gTEVSMS4gDQo+ICA+IDMuYSB1bmlkaXJlY3Rpb24gU0Zf VyBpcyByYWlzZWQgaW4gTEVSMSxhY2NvcmRpbmcgUkZDNjM3OCwgTEVSMSBzdGlsbCANCj4gID4g c2VuZCBMT0NLIHRvIExFUjIsTEVSMiBzZW5kIE5SIHRvIExFUjEuIA0KPiAgPiA0LnRoZSBjbGVh ciBjb21tYW5kIGlucHV0IGludG8gTEVSMSxhY2NvcmRpbmcgUkZDNjM3OCxMRVIxIHdpbGwgc2Vu ZCBOUiANCj4gID4gdG8gTEVSMixMRVIyIHN0aWxsIHNlbmQgTlIgdG8gTEVSMS4gc28gdHJhZmZp YyBpcyBicm9rZW4uIA0KPiAgPiANCj4gID4gDQo+ICA+IA0KPiAgPiANCj4gID4gICAgICAgICAg ICAgICAgICAgICAgICArLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKyAN Cj4gID4gICAgICAgICAgICAgICAgICAgICAgICB8IExFUjEgfCAgICAgICAgICAgICAgICAgICAg ICAgICB8IExFUjIgfCANCj4gID4gICAgICAgICAgICAgICAgICAgICAgICArLS0tKy0tKyAgICAg ICAgICAgICAgICAgICAgICAgICArLS0tKy0tKyANCj4gID4gICAgICAgICAgICAgICAgICAgICAg IE4gICAgKy0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICBOIA0KPiAgPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IA0KPiAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IA0KPiAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0t LS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KPiAgPiAgICAgICBsb2NhbCBsb2Nrb3V0IGlu cHV0ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KPiAgPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KPiAg PiAgICAgICAgICAgICAgICAgICAgVUE6TE86TCArLS0tLS0tLS0tLS1MT0NLLS0tLS0tLS0tLS0t LS0tLT58IA0KPiAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8VUE6TE86UiANCj4gID4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4gID4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgfDwtLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCj4gID4g ICAgICAgICBsb2NhbCBjbGVhciBpbnB1dCAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCANCj4gID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCANCj4gID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4gID4gICAgICAgICAgICAgICAgICAgICAg ICAgTiAgKy0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLi4uLi4uLi4ufCANCj4gID4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4g ID4gICAgICAgICAgICAgICAgU0ZfVyByYWlzZSAgfCB0aGlzIG5yIGlzIGxvc3QgZm9yIHNtdGgu ICAgICAgfCANCj4gID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBhbmQgU0ZfVyBpcyBy YWlzZWQuICAgICAgICAgICAgfCANCj4gID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4gID4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS1TRl9XLS0tLS0tLS0tLS0tLS0tLS0+fGFsd2F5cyAgDQo+IGlu IFVBOkxPOlIgDQo+ICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgDQo+ICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQo+ICA+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQo+ICA+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS1TRl9XLS0tLS0tLS0tLS0tLS0tLSsg DQo+ICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgDQo+ICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgDQo+ICA+IA0KPiAgPiAgICAgICAgZmlndXJlIDI6IGFm dGVyIGNsZWFyIGEgbG9jYWwgTE9DS09VVCBjb21tYW5kLFNGX1cgaXMgcmFpc2UgDQo+ICA+IGlt bWVkaWF0ZWx5LGFuZCB0aGUgTlIgc2VuZCB0byBMRVIyIGlzIGxvc3QgZm9yIHNvbWV0aGluZy4g DQo+ICA+IA0KPiAgPiBpbiBmaWd1cmUgMixjb25zaWRlciB0aGUgZm9sbG93aW5nIHByb2NlZHVy ZS4gDQo+ICA+IDEuTEVSMSBhbmQgTEVSMiBhcmUgYm90aCBpbiBOT1JNQUwgc3RhdGUgYW5kIGV4 Y2hhbmdlIE5SIFBEVS4gDQo+ICA+IDIudGhlIGxvY2tvdXQgY29tbWFuZCBpbnB1dCBpbnRvIExF UjEsdGhlbiBMRVIxIHNlbmQgTE9DSyB0byBMRVIyIGFuZCANCj4gID4gdHJhbnNmZXIgdG8gVUE6 TE86TCxMRVIyIHNlbmQgTlIgdG8gTEVSMSBhbmQgdHJhbnNmZXIgdG8gVUE6TE86Ui4gDQo+ICA+ IDMudGhlIGNsZWFyIGNvbW1hbmQgaW5wdXQgaW50byBMRVIxLExFUjEgdHJhbnNmZXIgdG8gTlIg YW5kIHNlbmQgTlIgdG8gDQo+ICA+IExFUjIsYnV0IHRoaXMgTlIgaXMgbG9zdCBmb3Igc29tZSB1 bmtub3duIHJlYXNvbiwgYW5kIFNGX1cgaXMgcmFpc2VkIA0KPiAgPiBpbW1lZGlhdGVseSBpbiBM RVIxLHNvIHRoYXQgdGhlIE5SIHRoYXQgc2VuZCBieSBMRVIxIHRvIExFUjIgaXMgDQo+ICA+IHJl cGxhY2VkIGJ5IFNGX1cuIA0KPiAgPiA0Lm5vPGh0dHA6Ly80Lm5vPjxodHRwOi8vNC5ubz4gTlIg cmVhY2ggTEVSMiwgaWYgdGhlIGVycm9yIGlzICANCj4gYmlkaXJlY3Rpb25hbCxMRVIyIA0KPiAg PiB3aWxsIHNlbmQgU0ZfVyB0byBMRVIxLG9yIE5SIHRvIExFUjIgaWYgdW5pZGlyZWN0aW9uYWwu YnV0IGluIGFueSANCj4gID4gY29uZGl0aW9uLExFUjIgd2lsbCBzdGlsbCBpbiBVQTpMTzpSIHN0 YXRlLnRoZSBQU0MgaXMgY3Jhc2hlZC4gDQo+ICA+IA0KPiAgPiANCj4gID4gc28gaSBoYXZlIDIg cGllY2VzIG9mIHN1Z2dlc3Rpb24gDQo+ICA+IDEuTEVSIGFsd2F5cyBzZW5kIGhpcyBsb2NhbCBo aWdoZXN0IHByaW9yaXR5IHRvIGl0J3MgcGVlci4gDQo+ICA+IDIuTEVSIGFsd2F5cyBhY2NlcHQg dGhlIGlucHV0IGZyb20gaGlzIHBlZXIgYnkgUFNDIFBEVS4gDQo+ICA+IA0KPiAgPiANCj4gID4g DQo+ICA+IA0KPiAgPiANCj4gID4gDQo+ICA+IEJlc3QgUmVnYXJkcyEgDQo+ICA+IA0KPiAgPiAN Cj4gID4gDQo+ICA+IEp1bmJvIFplbmcoQm9CbykgDQo+ICA+IA0KPiAgPiANCj4gID4gDQo+ICA+ IA0KPiAgPiANCj4gID4gDQo+ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fIA0KPiAgPiBtcGxzIG1haWxpbmcgbGlzdCANCj4gID4gIA0KPiBtcGxzQGll dGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjxtYWlsdG86bXBsc0BpZXRmLm9yZzxtYWlsdG86 bXBsc0BpZXRmLm9yZz4+IA0KPiAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMgDQo+ICA+IA0KPiAgPiANCj4gID4gDQo+ICA+IA0KPiAgPiAtLSANCj4gID4gVGhh bnggYW5kIEJSLCANCj4gID4geWFhY292IA0KPiAgPiANCj4gID4gU3RpbGwgbG9va2luZyBmb3Ig bmV3IG9wcG9ydHVuaXR5IA0KPiAgDQogCQkgCSAgIAkJICA= --_43cb0e82-ed17-4dc1-874b-d8bb77ff2ec8_ Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="figure3.txt" DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLSsgICAgICAgICAgICAgICAgICAg ICAgICAgKy0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgfCBMRVIxIHwgICAgICAg ICAgICAgICAgICAgICAgICAgfCBMRVIyIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgKy0t LSstLSsgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLSstLSsNCiAgICAgICAgICAgICAgICAg ICAgICAgICBOICAgICstLS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tPnwgIE4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tTlIt LS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgIHVuaWRpcmVjdGlvbiBTRl9XIHJhaXNlIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLVNGX1ctLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tTlItLS0t LS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgIGxvY2FsIEZTIGNvbW1hbmQgaW5wdXQgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg IFBBOkY6TCAgICstLS0tLS0tLS0tLUZTLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxQQTpG OlINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tTlIt LS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgbG9jYWwgY2xlYXIgaW5wdXQgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICBU RU1QT1JBUlkgTk9STUFMIFNUQVRFICstLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwg Tg0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfGlmIHRoaXMgTlIgcmVhY2gsTEVSMiB3aWxsDQogICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8c3dpdGNoIHRyYWZm aWMgdG8gd29yayBwYXRoLA0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfHRoaXMgd2lsbCBicm9rZW4gdGhlIHRyYWZmaWMuDQog ICAgICAgICAgICAgICAgICAgICBWICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgICAgZmluYWwgc3RhdGUgIFBGOlc6TCAgICArLS0tLS0tLS0tLVNGX1ctLS0t LS0tLS0tLS0tLS0tLT58UEY6V19SDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8TEVSMiB3aWxsIHN3aXRjaCB0cmFmZmljIHRv DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8cHJvZWN0aW9uIHBhdGgsdHJhZmZpYyBpcw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHJlc3RvcmVkLg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0t LS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICBmaWd1cmUgMzpsYWNrIG9mIFRF TVBPUkFSWSBOT1JNQUwgU1RBVEUsdHJhZmZpYyB3aWxsIGJlIGJyb2tlbiBhY2NpZGVudGFsbHkN Cg0K --_43cb0e82-ed17-4dc1-874b-d8bb77ff2ec8_-- From lizhong.jin@zte.com.cn Fri Jan 11 07:43:03 2013 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 E8C1921F8A08 for ; Fri, 11 Jan 2013 07:43:02 -0800 (PST) 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 YDR0RIgn4PHq for ; Fri, 11 Jan 2013 07:43:02 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DA49E21F89FC for ; Fri, 11 Jan 2013 07:43:00 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 3988B128036B for ; Fri, 11 Jan 2013 23:45:24 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 07EC570DC50; Fri, 11 Jan 2013 23:32:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r0BFghLR059781; Fri, 11 Jan 2013 23:42:43 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: loa@pi.nu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Fri, 11 Jan 2013 23:42:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-11 23:42:37, Serialize complete at 2013-01-11 23:42:37 Content-Type: multipart/alternative; boundary="=_alternative 0056521F48257AF0_=" X-MAIL: mse01.zte.com.cn r0BFghLR059781 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-ldp-dod@tools.ietf.org Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod 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, 11 Jan 2013 15:43:03 -0000 This is a multipart message in MIME format. --=_alternative 0056521F48257AF0_= Content-Type: text/plain; charset="US-ASCII" Hi Loa, I review this draft, and overall, it is well written. And I have following comments: 1. there is protocol extention in this draft. Should it be standard track instead of information? 2. section 3, it says this draft will be updated once [I-D.ietf-mpls-ldp-ipv6] is advanced. Does that mean this last call should be after [I-D.ietf-mpls-ldp-ipv6], or should we just remove this sentance? 3. section 3.1.1, it says: Downstream AN/AGN1x should respond to the label request from the upstream AN/AGN1x with a label mapping (if requested route is present in its RIB, and there is a valid label binding from its downstream) I think more acurate saying of the last sentance would be "if requested route is present in its RIB, and there is a valid label binding from its downstream or it is the egress node". Thanks Lizhong > ------------------------------ > > Date: Wed, 19 Dec 2012 09:25:44 +0100 > From: Loa Andersson > To: "mpls@ietf.org" > Cc: "mpls-chairs@tools.ietf.org" , > "" > > Subject: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod > Message-ID: <50D17A08.8050109@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Working Group, > > This is to start a working group last call on > draft-ietf-mpls-ldp-dod-03. This working last call is extended > due to the upcoming holidays. > > 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. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not ware of any IPRs. > > This working group last call will end on January 15, 2013. > > /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 > > --=_alternative 0056521F48257AF0_= Content-Type: text/html; charset="US-ASCII"
Hi Loa,
I review this draft, and overall, it is well written. And I have following comments:
1. there is protocol extention in this draft. Should it be standard track instead of information?
2. section 3, it says this draft will be updated once [I-D.ietf-mpls-ldp-ipv6] is advanced. Does that mean this last call should be after [I-D.ietf-mpls-ldp-ipv6], or should we just remove this sentance?
3. section 3.1.1, it says:
Downstream AN/AGN1x should respond to the label request from the
   upstream AN/AGN1x with a label mapping (if requested route is present
   in its RIB, and there is a valid label binding from its downstream)
I think more acurate saying of the last sentance would be "if requested route is present in its RIB, and there is a valid label binding from its downstream or it is the egress node".

Thanks
Lizhong


> ------------------------------
>
> Date: Wed, 19 Dec 2012 09:25:44 +0100
> From: Loa Andersson <loa@pi.nu>
> To: "mpls@ietf.org" <mpls@ietf.org>
> Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>,
>    "<draft-ietf-mpls-ldp-dod@tools.ietf.org>"
>    <draft-ietf-mpls-ldp-dod@tools.ietf.org>
> Subject: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod
> Message-ID: <50D17A08.8050109@pi.nu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> Working Group,
>
> This is to start a working group last call on
> draft-ietf-mpls-ldp-dod-03. This working last call is extended
> due to the upcoming holidays.
>
> 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.
>
> There are no IPR claims against this draft.
>
> All the co-authors has stated that they are not ware of any IPRs.
>
> This working group last call will end on January 15, 2013.
>
> /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
>
> --=_alternative 0056521F48257AF0_=-- From rcallon@juniper.net Fri Jan 11 10:53:35 2013 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 ACB8521F8A4E for ; Fri, 11 Jan 2013 10:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.492 X-Spam-Level: X-Spam-Status: No, score=-103.492 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, 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 UJQH+sQb14ri for ; Fri, 11 Jan 2013 10:53:34 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id E231A21F8A49 for ; Fri, 11 Jan 2013 10:53:33 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUPBfrU6tOvr2GclU5IA+LGBVNRerzWLs@postini.com; Fri, 11 Jan 2013 10:53:33 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 11 Jan 2013 10:50:46 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 11 Jan 2013 10:50:45 -0800 Received: from CO9EHSOBE021.bigfish.com (207.46.163.27) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 11 Jan 2013 10:52:45 -0800 Received: from mail115-co9-R.bigfish.com (10.236.132.238) by CO9EHSOBE021.bigfish.com (10.236.130.84) with Microsoft SMTP Server id 14.1.225.23; Fri, 11 Jan 2013 18:50:45 +0000 Received: from mail115-co9 (localhost [127.0.0.1]) by mail115-co9-R.bigfish.com (Postfix) with ESMTP id 0AC411401CA for ; Fri, 11 Jan 2013 18:50:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zz936eIc85fh4015Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275dh1033IL18c673h17326ahz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h34h1155h) Received: from mail115-co9 (localhost.localdomain [127.0.0.1]) by mail115-co9 (MessageSwitch) id 1357930242408007_29403; Fri, 11 Jan 2013 18:50:42 +0000 (UTC) Received: from CO9EHSMHS008.bigfish.com (unknown [10.236.132.225]) by mail115-co9.bigfish.com (Postfix) with ESMTP id 5A51A60005F for ; Fri, 11 Jan 2013 18:50:42 +0000 (UTC) Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by CO9EHSMHS008.bigfish.com (10.236.130.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 11 Jan 2013 18:50:41 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.82]) by CH1PRD0510HT004.namprd05.prod.outlook.com ([10.255.150.39]) with mapi id 14.16.0257.004; Fri, 11 Jan 2013 18:50:39 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: Proposed response to Ring Protection Liaison Thread-Index: Ac3wLIvW2MilEmiNRY61kTc4hga6xg== Date: Fri, 11 Jan 2013 18:50:38 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD309A3976C@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/mixed; boundary="_004_62CCD4C52ACDAD4481149BD5D8A72FD309A3976CCH1PRD0510MB355_" 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 Subject: [mpls] Proposed response to Ring Protection Liaison 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, 11 Jan 2013 18:53:36 -0000 --_004_62CCD4C52ACDAD4481149BD5D8A72FD309A3976CCH1PRD0510MB355_ Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD309A3976CCH1PRD0510MB355_" --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A3976CCH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We've had a small team that prepared a response to an incoming liaison from ITU-T SG15 on ring protection. The incoming liaison is: 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/ The proposed response is attached. Please send comments on the proposed response to the MPLS working group mai= ling list (mpls@ietf.org) by next Friday (January 18, 2013= ). Thanks, Ross (as MPLS WG co-chair) --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A3976CCH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We've had a small team that prepared a response to an incoming liaison=
from ITU-T SG15 on ring protection. The incoming liaison is:
 
    2012-10-03   ITU-T SG 15   = ;   Multiprotocol Label Switching    2012-12-31
           &nbs= p;     Requirements and analysis of ring protection
           &nbs= p;     for MPLS-TP networks
           &nbs= p;     http://datatracker.ietf.org/liaison/1199/=
 
The proposed response is attached.
 
Please send comments on the proposed response to the MPLS working grou= p mailing
list (mpls@ie= tf.org) by next Friday (January 18, 2013).
 
Thanks, Ross
(as = MPLS WG co-chair)
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A3976CCH1PRD0510MB355_-- --_004_62CCD4C52ACDAD4481149BD5D8A72FD309A3976CCH1PRD0510MB355_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="2013_Jan_11 draft ring protection LS response.docx" Content-Description: 2013_Jan_11 draft ring protection LS response.docx Content-Disposition: attachment; filename="2013_Jan_11 draft ring protection LS response.docx"; size=18603; creation-date="Fri, 11 Jan 2013 18:43:34 GMT"; modification-date="Fri, 11 Jan 2013 18:45:12 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBafRY0rgEAAJcGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 Vctu2zAQvBfoPwi8FhKdHoqisJxDHsc2QF00V5pa2UT4Andtx3/flRwLqR+SE7cXAgKxM7Ozw9X4 +tnZbAUJTfCluCpGIgOvQ2X8vBS/pvf5V5EhKV8pGzyUYgMoricfP4ynmwiYcbXHUiyI4jcpUS/A KSxCBM83dUhOEX+muYxKP6k5yM+j0RepgyfwlFODISbjHywgmQqyB5Xou3LMI/USKbhHZ6UhcA8p RLwqGFRkN9vqRkApVIzWaEUsX658tUedh7o2Gqqgl44Jiw60wYNEBvBTgykn41uo1dJSdvfM0rZu JLD4NrqXLguubCXhwsQ+hv5+XpQdc2cdUiW7tvphhm1p0GIKGhB57s4WHbJTxu8cOqnDL90MElde PJ8DIR30oAikjQX89wq2uH30bFYbT8lZvJgfmvhVUOU8j72EnvR/K/G3ocVdXYPmFzccCId5Y3Zx UNvXaZs6BCKe9Tkkf++B/cd4MOwd8qAE4jUDsj0v3wktzCBlzUtnqmYWzvD2jW130IMi1jD7+d/c fwXeJ6RLuw7pHWbsNmRTfSTjsv2tTP4AAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAAL AAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTa vr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGU oTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/W Dl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP 83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQD/mjkzQwEA AMwEAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAKyUzU7DMBCE70i8Q+Q7cVKgRahJL4DUKxTB1XXWiUVsR94N0LfHKjRN f8gpF0seyzPfem3PF9+mjj7Bo3Y2Y2mcsAisdIW2ZcZeV09XdyxCErYQtbOQsQ0gW+SXF/NnqAWF TVjpBqPgYjFjFVFzzznKCozA2DVgw4py3ggKU1/yRsgPUQKfJMmU+74Hyw88o2WRMb8sQv5q04Tk I2+jpXfoFMXSGe6U0nLrOjt05UibGvBNU/WoFEjC4Cd8CZSxk6U4wDJ+nuP6H44zNf7CPDjZGrB0 ptQ/qGOSofjZmPEU2gP79O2Ub8d0iGEyJoNtzRp8uGZ7jk4agkjHhJAtkjPvoevdpYhj3qlcE5jB I5mOSaOcpZVY173WdNLQkdyOCfEF6xcgCo3pvZSeOARyMyYInlDslB0CP/iD8h8AAAD//wMAUEsD BBQABgAIAAAAIQDDUQ+qWAoAAJUcAAARAAAAd29yZC9kb2N1bWVudC54bWzsWMtuGzcU3RfoPxBa Jaj1tCU7Qqwgie02QIoatoKuqRmOhsjMcEpyNFFX/owWSH/OX9JzSY6etuIWKZBFF4mseVxe3nPu uYd6+epTnrGF0Eaq4rzV7/RaTBSRimUxP299mF61z1rMWF7EPFOFOG8thWm9mnz/3ct6HKuoykVh GUIUZrzA3dTactztmigVOTcdVYoCNxOlc27xVc+7Odcfq7IdqbzkVs5kJu2yO+j1Rq0QRp23Kl2M Q4h2LiOtjEosvTJWSSIjET6aN/RT1vVvXoSU3YpdLTLkoAqTytI00fJ/Gw1bTJsgi0ObWORZ81xd PmW1WPMaeOSZT7tWOi61ioQxuHrhb64i9nuH1g4FpBCrN56SwvaaTSY5l8UqDLFjB/8VeB2A1/Vr dynUeiOoxQRcmql4SZ8lq8fgYnxz3ur1zo4HgyH4Fy5dA+heb9g7vhpdrS5eiIRXmaU7pxfD49Hq 8euNSy7ytaYP7T9mXfpSIfSCZ+ctKmQmWrjYDY/gswxvPLj+P4lVj+0EMCWWaWFK8E0wq9i76Qf2 /vakd0ZrWr+y+7906Taruj2fnh6fXa72HAqxfXGjEMOtO64Q4ZLLuom8FYbuuE4em5JHgLJErkIv RGty02dG5mW2ZFUZcysMu3kxoh3wLFM1k9b9XdIDuAhmWhFRW7Fc2FTFhimbCs1sygvWH/cZxIT1 f+h3GJumqIT4ZBk3rNbSWlGwWGGBQlkEElFWxYJxCg2AEEEww3OBMv5WSS2c+GBJH39r4QiLSZOb IzarLJMJ44wuzQWTiC6od7heUu4mVVUWs5mgzEtlRMy2AAEfmoIRFL2Tk8vBiePsI+WShUv05+v3 t+zXHx8Ntl/9SUU0dC8XpJgZe3c5vaK0KN3OVlZEz2+NJgOH7M0x43HMNLbSNqWIJBR7EzBDJLm5 ejscDU9AgdcxjRpAUm8/hJkBzMCktFCZmi9BNi14DMgKxkGvhWCxWIhMlY4FxKlYlJlauq8EMiiE lYCr5R/Bq0zOU5stj1ySa9C3qrqDdX90etZ/fQjrL1LmAZR3+AHql+iObwDxoHflrV1mApx3yvhe GnvNNZ9rXqYkkPVYotb1OBMJqW7QzEe00guR05bJtE8tbWAYDJA1kSi4lorV0AYBdArBNXG9EY/a tSWhaCo39Ql5UoAE8sRUwnLIviyRacJlViFyEJQ5uFGs44MKqoA0wb0wtLeRM7yyQZVcxSLzryIP jn9OTiBIBxMLSeHFXxDYVFHKXCTSF8qyRr1KYvbGlgB1LBLsNKa9YKrD1ezwD0+r5FKT5NhlCRlG C2XZreXa+uKvxOghZgmbPCneZRF/OdpXTQ3jw7Rt+RWzcwKzLq7vaw6+0KwhECAXttFTPp9rMXdm z/U/j0hSoToWbuQj+GiYESVobt0YaDgYK3I4O9K7KxLH/d7Z4JBIsO0Z8BTp/u+G+XTAaJ9lqrnB oDVhVA86w86o06e+CtpMNdmBa8U9GoT9jX1P7u8+P/bsPk/J6O+7DJqX7em1GxybTbOWalVamcvf 0T00HJwloeHiUUXi1HbECoZjB5AkB0JjwV0WRlUamLMI9qvKEYnualU1D+C9+7u/goRUcGgIeH/3 h1/9/u5PRg5IUsUUDIhR2tITTrXdMNq0JJTe9vwLqbuksMZPqsbs0kd75ad8Ya7aN/3eCzghN8SQ sQULsZel15kHF0XUxxAgtN6OhsM3wbZMAsKPPf9UxLz/Mw6NzQ0aFO6zU0RYPgxhwAJA3CGw8NIN W4gK5xju3qWxWto0yLuFCXMDHz1s5LxwEBeY3BjlMIjBRz4YVLC5KISG39gIHcI639jEBtKQd0lT TsAWNCoxw9uJxHgCstv4bcTD3vicVMHvLFLGvxDcCGIdOa44d+q++WHj/iR8AzuD04NXkkRGuL01 v9fLeU4+hhQh+/ri+PLN5SH9mQIA5yRnAgxegMNUk1DmNqa5wDE9poP8el2afgVxdDUzIbBwKhiz kcaxnbrMjevV15XXC6KK7opSSUpKs5kUWVUWJzv4sZAPugoQR6hHaDvxCWaDQu+7gY3MIhwj4OrQ o26MUls0m0HlCzozUAzuIDzQFvs0n+xXasVgLYIoHMyN2tRrUJMSeyY72N//w378sLV5mhVx3bge 9s8hGFkGugocEzekBTZpLtCO+zB4e+Degqwasp3U/u4ES2whTvrGBK1xbPA9Sz4Vd/Hgem2sSqda HELwuxScA/JY2cqG+gF8jIvtU9uOdXh9NYTOH2rdHVF/0DqEKM0hdcM6nL4dnZz2W+HO3u8AB478 dCrzqkQnJioOGguGyh1QjSpTatT15CV41mZKkWxgVAv2zFUP3lt7tw6xgYJjoOEEbtG+9B6O6Kaa 4eQfry8c0ruT0ah33PNFm1jNC/yigmGMXxNTct4YOB6Y1fEgLCJstAeGP5g8ZzlOiGCNZbGkowYO Fo4DXo0qadKmqxuAE61yXMuFSf8GAAD//4xVTW/iQAz9KxaXPbWl4atFLRKFUO2hEoLueTUkBkYk 4+zMhCz769eeQAvdluUAmg+P/fxsv4BBX5HdXAMMzQ5SXGqjvSYDtASrzerKFZjopU6gsOQxCXcV lVnKTzEFT5CQ8UobSDJU9siFA7Wg0kO1Vh5SQt6btF4Y8vLMee1Lj6BCqBrLw03V9wP5t4MH/gP+ OZ3OHhvN5njcG47jhpz7AYM+seUXhdwUxy86vV7rLm4cjqZW3AzHrfjp/XCMS1VmXm5OzadHxidY TtzUaEZXUfP+DtbKgSS3QDSQq5Rz2yqdqUWGsCQL3+PXCVjcaqzAEVR8bxFKEwwCl3mOhunaF2KL 2e4a5pQjFEgFe6nWxFG2yF4U079GZjQpw6P9cUHWS2WE9j0si79KbaUCkO6MyvflpISy2q50fJlS xSVhv/mVck6vDHth6Jg54PKSTdFKvbkRtjo94b7qL4g2ubKbuVeWS97XKZMnvHM0fGz8fKYnlWwa N8LWwTbmdjhYhou3Yv9LMPzOs74rVMLOCs4E7RYbA2mdHJO1MtrldSbaATrHHGqVZTvQqSwTxXlS YEsq8M3BRDkPH3LgxGgZW0HhdwUH4t7PspBRDfwMvsEMZ9zseJFLTvy/Dj9PmOf0Q4Q3TNKs3Tjq dToNTiDMzKU0vnIX7TszIWnA1NVcvf74MtylvmXMuQgWVEqFZ0WB2WTU4mEJasDrdvO+CTw20soL 5bh+Mijnsoyj1rA1PpPlQJndVw4uxQ0v89kUgjZ+5UoY74267d7tGSyf1/E0v8ulK5rcdqPoLdx5 6WoP2814HOSymAY1lQGSElT9TBtu8PZdmFHZzMqMD1TpSVpTEMmTAzLHyj+1h76SxE+lclbTegpv zo/EdNJu9rqjGsdq/oe9VI+N2yhqh+BrXnfueB0koFi98EeEB5AKPm/XJlav1uzpsF2Q95S/7zNc Ht2uWReRdb4XBfdL4s/W+3ZV+rDdh2MBdBxtLyzyJKBgSX22WtRJqJlqnzDKVjfcMiU1G4GdBaW7 sDio8OAvAAAA//8DAFBLAwQUAAYACAAAACEAMN1DKagGAACkGwAAFQAAAHdvcmQvdGhlbWUvdGhl bWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGH Fdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk 8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBu zEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1 jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33 G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWy WKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz 7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7kh zQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy 0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUn I3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLO OlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3u UurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjx Op4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8 gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxEV vrxOuBO/gykbY2JKDRR1p1bHNPm7ws0oVG7L4eIKN5TKF18/rpD7bS3Zm7B7VeXM9olCvQh3sjx3 uQjo21+dt/Ak2SOQEPNb1Lvi/K44e//54rwony++JM+qMBRo3YvYRtu03fHCrntMGRuoKSM3pGm8 Jew9QR8G9Tpz4iTFKSyN4FFnMjBwcKHAZg0SXH1EVTSIcApNe93TREKZkQ4lSrmEw6IZrqSt8dD4 K3vUbOpDiK0cEqtdHtjhFT2cnzUKMkaq0Bxoc0YrmsBZma1cyYiCbq/DrK6FOjO3uhHNFEWHW6Gy NrE5lIPJC9VgsLAmNDUIWiGw8iqc+TVrOOxgRgJtd+uj3C3GCxfpIhnhgGQ+0nrP+6hunJTHypwi Wg8bDPrgeIrVStxamuwbcDuLk8rsGgvY5d57Ey/lETzzElA7mY4sKScnS9BR22s1l5se8nHa9sZw TobHOAWvS91HYhbCZZOvhA37U5PZZPnMm61cMTcJ6nD1Ye0+p7BTB1Ih1RaWkQ0NM5WFAEs0Jyv/ chPMelEKVFSjs0mxsgbB8K9JAXZ0XUvGY+KrsrNLI9p29jUrpXyiiBhEwREasYnYx+B+HaqgT0Al XHeYiqBf4G5OW9tMucU5S7ryjZjB2XHM0ghn5VanaJ7JFm4KUiGDeSuJB7pVym6UO78qJuUvSJVy GP/PVNH7Cdw+rATaAz5cDQuMdKa0PS5UxKEKpRH1+wIaB1M7IFrgfhemIajggtr8F+RQ/7c5Z2mY tIZDpNqnIRIU9iMVCUL2oCyZ6DuFWD3buyxJlhEyEVUSV6ZW7BE5JGyoa+Cq3ts9FEGom2qSlQGD Oxl/7nuWQaNQNznlfHMqWbH32hz4pzsfm8yglFuHTUOT278QsWgPZruqXW+W53tvWRE9MWuzGnlW ALPSVtDK0v41RTjnVmsr1pzGy81cOPDivMYwWDREKdwhIf0H9j8qfGa/dugNdcj3obYi+HihiUHY QFRfso0H0gXSDo6gcbKDNpg0KWvarHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5uXiRxs4s7Nja ji00NXj2ZIrC0Dg/yBjHmM9k5S9ZfHQPHL0F3wwmTEkTTPCdSmDooQcmDyD5LUezdOMvAAAA//8D AFBLAwQUAAYACAAAACEA/UY+H/gDAAD2CgAAEQAAAHdvcmQvc2V0dGluZ3MueG1snFbbjuM2DH0v 0H8I/NxMbNmSHWMzC1/bLWbaotn9AMVWEmMsy5CUyUy/vvRtM4NyF4s+WeIhj0iKFvnh44tsV89C m0Z1O8e7c52V6CpVN91p53z5XK4jZ2Us72reqk7snFdhnI/3P//04RobYS2omRVQdCZWO+eiu9hU ZyG5Wcum0sqoo11XSsbqeGwqMX+c2ULvnLO1fbzZzEZ3qhcdsB2VltyaO6VPm8kyV9VFis5uiOuy jRYtt+CwOTe9Wdjk/2WDo84LyfP3gniW7aJ39dzvac7hXpWuv1r8iHuDQa9VJYyBzMp2Clfyplto TPsjPFM+H5qD5vr1Dck9XNs/SsnVNe6FriChcOcBczYDAAer495yKwA2vWjbsQiqVnA4/hqfNJeS w6VNktGmFkd+ae1nfthb1YPSMwcHQ+JOlNWZa15Zofc9r4AtU53Vql30avWHspmSvYaAZwvYcTty Q03WZnBsWPytlF3MXDfyCaHRZDGgN8T1XUa3KBIEBQkwxPM9NyIowkiSoed4LIy8BLVJaenlGELC MPDQc0jpMYIivktogsYTMAbBYucESeAWqAdBSbOEYjbU9UtWoojn+T4aKQ1DPypQm5zREvWABSQP UsyGURox3GZLCUNzwDJabOfyfV8HrCAhRSMNQxr56DlhCrlGcxBmLAg9zOswpz5DK+TbNRptvZSi HmwLkhWo10nuFyma66SknotmJ01ZRNCbyyDZaYDFk7uMMBxhHsl81CYLkxD1Lc/pN/7TPA+THLUp iJ/g91P4LMUrvqBQo2gdFBFLCHpzxZayDP3nijTwcZvSD9MwxHJQBm7IMhSh8DPiCCNBjvpWMhZ5 aCWWSeBPf9ZmehjhhZTx0ML+0suqhFd2JaenOOPyoBu+ehyaHDyrMj7op7TpFvwgoNmKt8j+cljA 9XoCjORtW8JLvgDQ3yakbkyfi+NI3D5yfboxj0+TjDUqhb7x+1e2oQ8J/atWl35ivWref+pqEC8H ekEw8zWdfWjkIjeXw36x6qDXvYEuXf3nsx4IN7cEXWML44kYMvTAu9PSN0S3/rIfVK9x1er9MMKI R9730LJA5XDydk7bnM7WG/qghV3N9dO4OZzIjJERg92AjRteDZGB9rwYFKYlaM2Lm8xfZP5NFiyy 4Caji4zeZGyRsUF2foXmDs37CUaFZTnIj6pt1VXUvy3CnfMf0ZQEc+a9gHsdejsUmIpHwdzszeo5 Fi8wOYi6sTAd9k0t+cvOIS4d72jWbvmruth3ugPToNy/k65qbjnMIeNVvTOGq4NJ5L0v17gWVQMF uX+Vh9socTc53jbG7kUPU4dVGkIex5FfRubbwHr/LwAAAP//AwBQSwMEFAAGAAgAAAAhAPqjFDi2 CAAAU0IAAA8AAAB3b3JkL3N0eWxlcy54bWzMW21To0gQ/n5V9x8ovu9pEk3U2uyWRr21al/cjdZ9 npCJoSRMDsiq++uvpwcmBAJ0B7bqPkUGpp9+fZrE6fcfX1eB81NGsa/Csdv769h1ZOipuR8+jd3H h9t3Z64TJyKci0CFcuy+ydj9+OHPP96/XMTJWyBjBwSE8UU0dpdJsr44Ooq9pVyJ+C+1liHcW6ho JRK4jJ6O1GLhe/JaeZuVDJOj/vHx8CiSgUgAPF7669hNpb1QpL2oaL6OlCfjGLRdBUbeSvih+wHU myvvWi7EJkhifRndR+lleoUftypMYuflQsSe7z+A4mDiyg9V9OkyjH0X7kgRJ5exL/beXOqn9t7x 4iQn7cqf++6RRox/gcyfIhi7/X62MtEa7KwFInzK1mT47nGa12Ts2qUZyB27Ino3vdTCjtDM7DNn 7nrHeLhCVdbCA8cBjlgkEgII8dA4ga8D3R8Ns4sfmwAWxCZRKQgKALC8WLgseBziClGemiyBu3Lx WXnPcj5N4MbYRSxYfLy7j3wV+cnb2D0/15iwOJUr/5M/n0udlOnaY7j05/KfpQwfYznfrn+/xRRL JXpqEyag/nCEWRDE85tXT651ioHoUOgIf9UbAi02zuGgQht/q41ZKKDi4r8ZZM/EcC/KUgpdRg7q XwuEVm9aA/W1RXkDUC5L10F7ESftRZy2F4HJ284Xo/ZaAHm2jYjJjVxW0oOaKM8kX94Pg/OalNU7 SlnUuKOUNI07SjnSuKOUEo07ShnQuKMU8MYdpfg27iiFs3aHJ5C4ilk0QG+QCvvBTwKp99cSUK8l 1aWtxrkXkXiKxHrp6MZaVLuOLKebWUJTFen0cLKcJpEKnxo9At1Zl+7BnHyzWi9F7MMbTYPr+y1d /yBmgXT+jvx5I9SpSb6STfhisreF3QfCk0sVzGXkPMhXE1HG/q/KmZq3jEblWob1s/+0TJzpEltu I9iwwunVnjDyP/sx+qC2mIYVpjQJJ8VwWJGX1cK/yLm/WWWuIbyNDA2fM8JcgEAV6110okNUrq5G K3QAKCaYdsE3AeUT9DfNhS9fx5iiv2lFB8on6G8a14HyMT/q48tmmmsRPTuk8hqxa3eiAhUtNkFW A430MGJXsIWgmcAuYiufRBIjdgXv0Kdz6XnwzY2Sp+xYbHmUgcIOh0HBYqPbwg5KgfZ6DIvYASpg 9RlY7biWAcQm3R/yp69/eOI2A2Rp+67ZWM6DCg9ACyK9Q3/fqKT5HbpfwXlUlLsQfi6JpUNDG1RU HhUtzSfT7xgxbtf4GEDtOiADqF0rZABV5Ef1O4/tiXSQ9s2RgcWmZdvFMO3IzDxiM7MF4rWAjvom 4f2ronqrc6HcNwko7ACV+yYBhR2dQi+zfZOA1VnfJGBVdI3qGOU5lWMUu2/mgeybAMGibsibANQN eROAuiFvAlB78m4G6Y68CVhsbrCcmidvAhA+wvmqb4Hy5E0AYnODYbv0N6Os76GU+i+3HZA3AYUd oDJ5E1DY0akibwIWPsLJhAKWpToCVjfkTQDqhrwJQN2QNwGoG/ImAHVD3gSg9uTdDNIdeROw2Nxg OTVP3gQgNj1YoDx5E4DwEQ437CVvrPrfTt4EFHaAyuRNQGFHp0Co9iWVgMUOUAHLkjcBCx/hJEOK hcnNMaob8iZY1A15E4C6IW8CUDfkTQBqT97NIN2RNwGLzQ2WU/PkTQBi04MFypM3AYjNDXvJG4vx t5M3AYUdoDJ5E1DY0SkQquU5AhY7QAUsS94ELMyX1uRNAMJHDgXiWNQNeRMs6oa8CUDdkDcBqD15 N4N0R94ELDY3WE7NkzcBiE0PFihP3gQgNjfsJW+skd9O3gQUdoDK5E1AYUenQKiWvAlY7AAVsCzV EbC6IW8CECZma/ImAOEjBwBhFXHC1A15EyzqhrwJQO3JuxmkO/ImYLG5wXJqnrwJQGx6sEB58iYA sblBn7OF86Lk46m9iiSgnjPITjWQAfsVQaICpgb+kAsZwSSTbD4d0hIws5CBWJEeVBOvlHp2aAe7 BxUJQobyZ4Gv8Ej3G57SyQ0iDEY1kwQP3ybOJzMAU9qHKbV78gamh/LjQjiepAeHQM/kbQ0jO+vs ZLmWBgNCeq4rHQHCObQ7GAhKx3r0Zj3nAw/iUFW6jP+3TVHxb5h5m2fPHB+fjkaDs5t0wAlFlpXw lqCFB7NSNUqkR+Ht6SQ8CF9UqeK8PKq1HdbIlEvPzW/frsxzO6c3YQl8WKF3os+I1+iMZ8hrvefg IybeZQVhbAtVatLQnrfCp5NZYAbR4I+7UIcCxv7wf2sm5PNXYcTC/YkMgi8Cx9YSta5+NJCLxNzt HWOfLIiaqSRRq+r9ER4jR032CQAX55Uxl9qIat+Hm9VMRjAHVuP/r0r3F5xX201ccyLWhNtWHmiP eU31erVuO0Vly0jrYtO3pBR2wu1t1G0mYCDvm56vKxVcOVngNB5uqi7F0fXpYHhmnkpnFX3MDx3d sTuCkQmU4MGMCQwlbESQDhnAKhibTSdWFMN+o69EECgV4pBDsVrTe2YCoslgmJ58zhyREzoB6jBa lz1CDSRMd+5Q1u2wf3KdkkPqp7g404n1lE50ntiL/ROd6fQofOyMxY7dB7FUK6ETGAde8wtebK/Q M9v51t7Q2Bv/2s63mjWIEUzj1hXNDtF6mxhqdqrbQZHxiw6ui5yzDUEhX/dSNlpTEUxmIKujhm74 H/h7f01M0umzolezqbSmUgihOLNSyDfhcgXAQBsK2/2ehkvVNHEzGF7BMVh8qpT+3JSfGWMmMX56 emIgU/3k9qx3da2zH0e68VUdxqHxjHzWmu1Udy/lrZ2sx7XmrN8fBZjB8vfzEt7hs5IVuC2IckQO 5aTh5PTmPK38UlDSOXNLQzCmfTAnTUTgzyI/R0rZCkYw73/4SgFrzf6nss6uA4vVsY1KW8axOGlx UN8AdvkmH5EKvsk8tyX4bIXsS/Au9tv4w38AAAD//wMAUEsDBBQABgAIAAAAIQB0Pzl6wgAAACgB AAAeAAgBY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAhM/BigIxDAbgu+A7lNydzngQkel4WRa8ibjgtXQyM8VpU5oo+vYWTyss 7DEJ+f6k3T/CrO6Y2VM00FQ1KIyOeh9HAz/n79UWFIuNvZ0pooEnMuy75aI94WylLPHkE6uiRDYw iaSd1uwmDJYrShjLZKAcrJQyjzpZd7Uj6nVdb3T+bUD3YapDbyAf+gbU+ZlK8v82DYN3+EXuFjDK HxHa3VgoXMJ8zJS4yDaPKAa8YHi3mqrcC7pr9cd/3QsAAP//AwBQSwMEFAAGAAgAAAAhAOEX0cyI BAAA0x0AABIAAAB3b3JkL251bWJlcmluZy54bWzMWdtu4zYQfS/QfzAE9DGx7r5gncXGjoEttoui TdFnWaJjoqIoULK9ft2f6Sf0s/YXOhQl1aIuKzER6pco5v0Mz8wcjd69/0LCyQmxBNNopRn3ujZB kU8DHL2stD+et3dzbZKkXhR4IY3QSrugRHv/8OMP787L6Eh2iMHACawRJcsTdB/SNF5Op4l/QMRL 7mmMIujcU0a8FH6ylynx2F/H+M6nJPZSvMMhTi9TU9ddLV+GrrQji5b5EncE+4wmdJ/yKUu632Mf 5Y9iBuuzr5i5of6RoCjNdpwyFMIZaJQccJwUqxHV1QDioVjk1AXiRMJi3Dnus1vAvDPYmYTi2GfK gphRHyUJtG5EZ7mioXftnRuQL1HO6HOE6p7FSYiHo3IZTg/p/svLu4fLm4q9p3yp/4CALR6ATN4u SZnnp5+PZFL59TFYaXo2JEpwAH0nL4QWZ2bq64WhTflkcgxT/AmdUPh8iVEx5nDZMRz8wvtC3ifG piQOixHu0+OHmfH4JHrCE+/A8OA7wr9pHPrwr60vdF3fZmcAV2BpMT3fHfxgS8rGAPmYePlmsNYz +lL2/WTcl1v97BfLhGifiub4V8bh4Ijj5M0rzXKzoxy86CVzSf4bME/Py2wwPGEPPun69IZ8emOR tQDxge/cT42eaEJ6RuwTSlPEypNXEJmDERn6XAGSWYP0+BpIv1HiRc2IrCZEDL8c2i/JmOtVSNDw /VuyZEjAMc664bfUyTm7CU8n50zHrMLpRTpbhjMe6ZzBkCzTVoDk1CCNRTq3CVE36ayFFBp6kQ7S bC2wjUC6WROeTtLZrkpYmMlwxiPdfDAkx5bCQi8/AsFVvSFjLNItmhB1k841pNDQQjrIS1cZ/bsJ XqSjSoLfuNvZ48IUMVo1wa9nur7ePLllpAfTtiX4vilxdwxDlOcCKb9/+/pPuVPP/A4yht93W34/ L5nQBGxLozSBkV7iY7zSfr+QHQUZCVM/gN0qDTgC4RCgvQfSJ09D2So9xYIuEtPwNNRhGTrULobd HbBbDbOmR4YRm3xG5yvrSK1+stKkpsMwq9X0iC6SxZta7dvXv4fazTSkrCDFnFa7/Qnykr/1wXtQ yalq2zAD1dWNUKVvbKDBDmfOu/NMq4HezuNqSukmPA6IohaKZEcS8Uhqfb3H1cTYjXicbSmG8Kp3 CatV24Z5XF3a3YbHOfAG/T/nuJpMvAmPc2aKsVryrVwBSK2v97iaEr0Rj3NtxRBe9S4Vjxuoa81a 4crSjTkcfy7yuqqudTbb9Wa7zVe5Lv1knnYLhauZm8WjNmHbU4uO9zqnULiy5wqQakJxtNc5hcKV afK6+9XrR8vrXLW8WJd2W77IDRSuFmYVjiR+m0lXk2PjkU6hcOXaCpBqWmk00ikUrmxLCg29SJdZ QQpsI5BueOHK0VXCQk2RjEc6hcLVXAoLvfyoJhdGI51K4cqRQkML6eoJHj7vAM/gL/8SJYpEV6Wt j/xTjfgklZdaYCSvd1WmCR3QOC37iAS7Nk2zMvnQOC0rjBXTxFN8jH34FwAA//8DAFBLAwQUAAYA CAAAACEAedCxb+AAAABVAQAAGAAoAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbCCiJAAooCAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckE1LxDAQhu+C/6HMPZv4FevSdNmmLuxVXPCa TadtoElKkooi/ndTPK1HT8Mzw8zzMtXuw07FO4ZovBNws2FQoNO+M24QcHo9kBKKmJTr1OQdCnAe dvX1VdXFbaeSiskHPCa0RW6YXI+tgC/J5DPn/IncPciG3JctI+W+lISxZs8fDw1vufyGIqtdPhMF jCnNW0qjHtGquPEzujzsfbAqZQwD9X1vNLZeLxZdoreMcaqXrLdvdoJ6zfO7/YJ9vMQ12hLMfy1n c56MH4Kax0+gdUX/qFa+eEX9AwAA//8DAFBLAwQUAAYACAAAACEANxZRmYEBAADvAgAAEQAIAWRv Y1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLNTusw EIX3SLxD5H3qmFyuUNQGiSJWIF1BEYidsYdiiH/kGQh5++skbSCIBTuPz5kvM8dZnn7YJnuHiMa7 FROLgmXglNfGbVfsdnORn7AMSTotG+9gxTpAdlofHixVqJSP8C/6AJEMYJZIDisVVuyZKFSco3oG K3GRHC6JTz5aSamMWx6kepVb4EdF8ZdbIKklSd4D8zAR2Q6p1YQMb7EZAFpxaMCCI+RiIfinlyBa /LFhUL44raEupJ12435lazWKk/sDzWRs23bRlsMYaX7B768ub4ZVc+P6rBSweqlVRYYaqJf885hO +Pb4AorG66lIgoogycd6bVD57KZDAotD817pM3+FrvVRY+qfVQmgAVU0gdJLjvTZRXI3EukqPe2T AX3W1dceMVvLJj3sAPsm91+L8G76P6MuB8dUpu2GMMehQWcpnmoMc6/clevzzQWrjwpR5oXIhdiI k+pPWRXFQ7/VrL+Pa7ywu/l+TzyeE/eAMaD5L1r/BwAA//8DAFBLAwQUAAYACAAAACEAqchcqowA AADaAAAAEwAoAGN1c3RvbVhtbC9pdGVtMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAskmyCs4vLUpOLVYITs1JTS5JTQkuqcxJtVWKcQxw1IsI9lFSAAv4JeYCBYFi SgoVuTl5xVZJtkoZJSUFVvr6xckZqbmJxXr5Bal5QLm0/KLcxBIgtyhdPz8tLTM51SU/uTQ3Na9E 38jAwEw/KTMpJzM/vSixIKMSahhVjLKz0Yd7xo6XCwAAAP//AwBQSwMEFAAGAAgAAAAhADInKEUl AgAAQAgAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzUld9v2jAQx98n7X+I/L7GMeFHUUPVduNxDxvT nk1wiKXYjnyGlP9+5yQUOlytqTpNA4XAnXM5f/h+Lze3j6qK9sKCNDojyRUlkdC52Ui9zciP1fLT jETguN7wymiRkYMAcrv4+OGmmRdGO4jweg1zm5HSuXoex5CXQnG4MrXQmCuMVdzhT7uNTVHIXHw2 +U4J7WJG6SS2ouIO7w2lrIH01ZrXVGuM3dTW5AIAm1VVV09xqcmi7y5q5por7Pr7Qa1N1cZrrg2I BFN7XmWEjvGdUIbHlE7wPKZTEvsCecktCPe0kHXhgitZHY5RaxTXXaKWLi+P8T23kq8r0aVAbjGx gzXFG/Yv0kUShP48wi7WjJ5H8rbO7OwqjGCdp8rYftz9PRcgVlIJiL6KJvrWdu4X/E6EIYUJHSGJ FA+G39IwEfo+RFAHlN3Npici53tDaiciKMaWY5BIu/9kufRrXk/kweysFNYzCeqDoS5G9Bo5eG0w ZDKEhjIbYUMCKeSj2Fyq49+y+IlG8s6HIInxUWCnc1gXQafwnTPd8v/CKA+8kmsrgyAYXbZS8JJI URz4GQYRNAg0EmAQiTsPnH1phY12QKunPkCn970dTgbB8f0Hg9DrgQZZ8RJHxQsg7nFSeAR+VqRv B6GNW9mdWB1q0c7eYRIZ9Zs+n4EdhkFgaDJwcnCFCnmJjJ+dHRc/S4dJZPhTJSwRStO/I5H+8QKL XwAAAP//AwBQSwMEFAAGAAgAAAAhAD3+16+MAQAA/AgAABQAAAB3b3JkL3dlYlNldHRpbmdzLnht bOxWS0/CQBC+m/gfmr1LW1ooJRQSQvCCjyh6X9otbLK70+wuVPj1jgUV0YM9ED300HTn2W/m62R2 MHqRwtkwbTiohPgtjzhMpZBxtUzI03x61SOOsVRlVIBiCdkyQ0bDy4tB2S/Z4pFZi57GwSzK9HVC VtYWfdc16YpJalpQMIW2HLSkFkW9dCHPecomkK4lU9Zte17X1UxQiwjMiheGHLKVv8lWgs4KDSkz BoFIsc8nKVdkiBgzvjGHt1P2eZaQMAzjds8Pgsq+gGw74Ru0bajA+on75i2pnrHcvmu9D+0DX65+ UM+h+O47BmtBnugRzzjTb9+wnzEKO0vQ0ewSgv3HQ0FT7HV1TkEA9pWuLexhiCNk9SIXXxDVi9XH ldcJdSsSqqL3xxM6OlEviEM/buio8xOci47ID/1u0I0aOmrN5LnoiKN27EVBu9tMx3+YDt+PO/iE Qdjw8Vd87JdItdShsFzyHZuCHmsoDdPV9sbLxPZOPd/MKokKAeX97TUKGHp0Zxm+AgAA//8DAFBL AwQUAAYACAAAACEAPw8lPuoBAADoAwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcU8Fu2zAMvQ/YPxi+N3a8tOsCRcWQYuhhWwPYbc+aTDvC ZEmQ2KDZ14+yG1fZdppP5CNBPj0+s5uXQWcH8EFZs8mXizLPwEjbKtNv8ofmy8V1ngUUphXaGtjk Rwj5DX//ju28deBRQchohAmbfI/o1kUR5B4GERZUNlTprB8EUur7wnadknBr5fMABouqLK8KeEEw LbQXbh6YTxPXB/zfoa2VkV94bI6OCHPWwOC0QODfIx3NihlgjUWhGzUAv14SPmdsJ3oInLApYE/W t4GvLgmZQrbdCy8kknq8uvy4YkUCsM/OaSUFkrD8m5LeBtthdj9KkMUBrEhbGMlSg3z2Co+8ZEWa sq/KEJWKNk8RcfOi98LtA7+KBOeM1VJo2NLjeSd0AFa8AewORDzsTihizA64PoBE67OgftFpqzz7 IQJEyTb5QXglDJJ0sW1Kxli7gJ43CjXNptqUj2HalsZqFVWkXgrOGyM4caDCObtxQ7jv6G34D7LL lOzIYaKa0EnCeccfU7d2cMIc+VYFabP6GBCGQGd8haPuP8ODa+xt9M6roOdgYoInhfvaCUmn+lAu P6V2SEqsJtdAS/c9DXwD2B2J73XcSlYyPbSnnr8L0WCP04/Ll9WipG901AkjW8x/FP8NAAD//wMA UEsDBBQABgAIAAAAIQBAdE/HeQkAANNFAAAaAAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWzM W21v2zYQ/j5g/0HQ9zR+Sew2mDs0TrIG6LauTrDPtEzHRCRRk+Sk2a/f8UjRsmRZR0sF9ikxJd5z r8/RCe+XX79HoffC00zIeOYP3w18j8eBXIn4aeY/Ptydvfe9LGfxioUy5jP/jWf+rx9//umX16ss fwt55oGAOLt6TYKZv8nz5Or8PAs2PGLZu0gEqczkOn8XyOhcrtci4OevMl2djwbDAf6WpDLgWQZo cxa/sMw34qK6NJnwGLDWMo1Ynr2T6dN5xNLnbXIG0hOWi6UIRf4GsgeTQoyc+ds0vjIKnVmF1JYr rZD5UexIa1YcwNU7b2SwjXicI+J5ykPQQcbZRiQ7M06VBiZuCpVejhnxEoXFe6/J8KKGZ02mxOAm Za8Qip3AmrgDzljpTVGo/aDiu4tqVeJwcMwYExElwupAUWEfs9AkYiK2Yk5zTdm5UA9d8vu3VG4T q04iukm7j5+tLFWWDpoNJlh5ZdMyJwG10l1sWMJ9Lwqu7p9imbJlCBq9Di88lZH+R6CKlQxu+Jpt wzxTH9OvqfloPuGPOxnnmfd6xbJAiAegEJASCRD4+VOcCR+ecJblnzLBDj7cqLcOPgmyvCTtWqyE f64Qs39B5gsLZ/5oVKzMlQZ7ayGLn4o1Hp89LsqazHy7tAS5M5+lZ4tPStg5mln8LJmb7BkPn1CV hAVQeYDD1jkHEgIWUzihUNEdTYHR9IdvW+Vcts2lAUEBAFYWCx8rHgduAqZaaMaGp3z9RQbPfLXI 4cHMRyxYfLz/mgqZAo3O/A8fFCYsLngkPovViqsGYdYe441Y8b83PH7M+Gq3/tcd0rORGMhtnIP6 kylmQZitbr8HPFE0CaJjpiL8h9oAHAbhKOGgQlux00YvVFBx8Z8CcqhjeBBlw5lqaR7qfxQIrd52 Bhopi8oGoFwnXcfdRVx0F3HZXQQmbzdfTLtrAQeZrhHRuVHKSnpQcxno5Cv7YfzhSMqqHbUsat1R S5rWHbUcad1RS4nWHbUMaN1RC3jrjlp8W3fUwnl0R8CQuKpZNEZvkAr7QeQh9MkWpht2pDrTaryv LGVPKUs2nmqsVbWPkeViu8xpqiKdnk6WizyV6rjZ4hHozqp0T+bk2yjZsEzAqbwNqKPrH9TRx/st FXB8bYG61MlXswkPJgdb2NeQBXwjwxVPvQf+XUfUYf8f0lvoU0arch3D+kU8bXIPToWq5baCTRqc 3uwJLf+LyNAHR7v5pMGUNuGkGE4a8rJZ+O98JbZR4RrCaWSi+dwhzBUIVPG4iy5UiOrV1WqFCgDF BN0u3E1A+QT9dXNxl69iTNFft6IT5RP0143rRPmYH8fj68w0N/BnFY9UXlPn2p3LUKbrbVjUQCs9 TJ0r2ELQTHAuYiufRBJT5wreo0/vUxDANzdKnjrHYsejDijO4dAoWGx0W5yDUqG9oYNFzgGqYI0c sLpxrQOQM+l+4y9C/RHYtRkgS9uzZms5jxs8AC2IdIb+ayvz9jP0qIHzqCj3Mfy5JOMeDW3cUHlU NJNPut85xLhb43MA6tYBHYC6tUIHoIb8aD7z2J5IB+neHB2wnGnZdjFMOzIzT52Z2QK5tYCe+ibh /NVQvc25UO+bBBTnANX7JgHFOTqVXmb7JgGrt75JwGroGs0xKnOqi1HOfbMMZE8CBIv6IW8CUD/k TQDqh7wJQN3Jux2kP/ImYDlzg+XUMnkTgPAVl6/6FqhM3gQgZ27QbGf+ZlT0PZRy/MttD+RNQHEO UJ28CSjO0WkibwIWvuKSCRUsS3UErH7ImwDUD3kTgPohbwJQP+RNAOqHvAlA3cm7HaQ/8iZgOXOD 5dQyeROAnOnBApXJmwCEr7hww0Hyxqr/4eRNQHEOUJ28CSjO0akQqj2kErCcA1TBsuRNwMJXXJLB YGFyuxjVD3kTLOqHvAlA/ZA3Aagf8iYAdSfvdpD+yJuA5cwNllPL5E0AcqYHC1QmbwKQMzccJG8s xh9O3gQU5wDVyZuA4hydCqFaniNgOQeogmXJm4CF+dKZvAlA+MqpQC4W9UPeBIv6IW8CUD/kTQDq Tt7tIP2RNwHLmRssp5bJmwDkTA8WqEzeBCBnbjhI3lgjP5y8CSjOAaqTNwHFOToVQrXkTcByDlAF y1IdAasf8iYAYWJ2Jm8CEL5yAhBWkUuY+iFvgkX9kDcBqDt5t4P0R94ELGdusJxaJm8CkDM9WKAy eROAnLlB3bOF+6Lk66nDhiSg3jMobjWQAUcNQaICGgO/8TVPYaqQt98O6QhYWOiA2JAeVBOvpXz2 aBe7xw0JQoYSy1BIvNL9hrd0SoMI4+mRSYKHP+feZz0AU9uHKbV/8wamh8rjQjiepAaHQM/8LYGR naS4Wa6kwYCQmusyI0A4E3oPA0FmrEdtVnM+8CIOVZll/L+tQcXfYf50VbwzGFxOp+P3t2bACUXW lQg2oEUAs1JHlDBX4e3tJLwIX1Wp4b48qrUb1iiUM/fmd6cr/d7e7U1YAh826J2rO+JHdMY75Ee9 5+ErOt51BWFsC1Vq0xCCuQz18Bn8ch8r97+auS0d5tV3pkXB8zkPw98ZjqrlMml+NeTrXD8dDrA3 VkQtZZ7LqHl/ilfHUZNDAsCtZWX0R2VEs7/jbbTkqbmI3pisqqfgjNp+supbsA2pQPV0s257hWRL R+liU7amFHa/3WPUbclgCO9PNVNXK7J6gsANPNzUXH7Tm8vx5L1+y8wnCswPFd2ZPx0N9LMA5kpg EGHLQjNYAHLB2GIisaEADht9zcJQyhgHG6oVap7pqYc2g2Fi8rlwREnoHOhCa133CDWQMNG5R1N3 k9HFjSEE46esOseJ/582U5wX9sPhKU4zMQo/9kZhZ/4D28iIKdLAIdfyQgCzu+YxemY30zqcaHuz f3czrXoNYgQTuMeKZo9cg20GNbtQLaDK8lUHH4uctwtBJV8P0jRa0xBMx0A2Rw3d8D/w9+GamJuJ s6pXi0m0tlKIoTiLUig33noFwBAbCtv/boZLzTRxO55cw9VXfKuW/q4pv9TGzDP8GagpgUL1i7v3 w+sblf04xo3HcxiBxnvxRTu2k9xDw1t7WY9r7Vl/OAowdyUO8xI+cWclK3BXEPWInMpJk/nl7QdT +bWgmNlyS0Mwmn0yJ81ZKJapKJFSsYIRLPsfvkbAWrv/qayz78Bqdeyi0pVxLI4pDnveLjKzIUj7 fFOOSAPfFJ4DuYbgixWyL8G72G+zj/8BAAD//wMAUEsBAi0AFAAGAAgAAAAhAFp9FjSuAQAAlwYA ABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEa t/MAAABOAgAACwAAAAAAAAAAAAAAAADnAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA/5o5 M0MBAADMBAAAHAAAAAAAAAAAAAAAAAALBwAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BL AQItABQABgAIAAAAIQDDUQ+qWAoAAJUcAAARAAAAAAAAAAAAAAAAAJAJAAB3b3JkL2RvY3VtZW50 LnhtbFBLAQItABQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAAAAAAAAAAAAAABcUAAB3b3JkL3Ro ZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEA/UY+H/gDAAD2CgAAEQAAAAAAAAAAAAAAAADy GgAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA+qMUOLYIAABTQgAADwAAAAAAAAAA AAAAAAAZHwAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAHQ/OXrCAAAAKAEAAB4AAAAA AAAAAAAAAAAA/CcAAGN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVsc1BLAQItABQABgAIAAAA IQDhF9HMiAQAANMdAAASAAAAAAAAAAAAAAAAAAIqAAB3b3JkL251bWJlcmluZy54bWxQSwECLQAU AAYACAAAACEAedCxb+AAAABVAQAAGAAAAAAAAAAAAAAAAAC6LgAAY3VzdG9tWG1sL2l0ZW1Qcm9w czEueG1sUEsBAi0AFAAGAAgAAAAhADcWUZmBAQAA7wIAABEAAAAAAAAAAAAAAAAA+C8AAGRvY1By b3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAKnIXKqMAAAA2gAAABMAAAAAAAAAAAAAAAAAsDIA AGN1c3RvbVhtbC9pdGVtMS54bWxQSwECLQAUAAYACAAAACEAMicoRSUCAABACAAAEgAAAAAAAAAA AAAAAACVMwAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAD3+16+MAQAA/AgAABQA AAAAAAAAAAAAAAAA6jUAAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAD8PJT7q AQAA6AMAABAAAAAAAAAAAAAAAAAAqDcAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEA QHRPx3kJAADTRQAAGgAAAAAAAAAAAAAAAADIOgAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWxQ SwUGAAAAABAAEAAcBAAAeUQAAAAA --_004_62CCD4C52ACDAD4481149BD5D8A72FD309A3976CCH1PRD0510MB355_-- From eosborne@cisco.com Fri Jan 11 12:40:15 2013 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 48F6121F8A3F for ; Fri, 11 Jan 2013 12:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.899 X-Spam-Level: X-Spam-Status: No, score=-7.899 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, 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 ddrqKTcg0-8G for ; Fri, 11 Jan 2013 12:40:14 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B906721F8750 for ; Fri, 11 Jan 2013 12:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13182; q=dns/txt; s=iport; t=1357936814; x=1359146414; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QhmHs20Wt64dMChzf1Luj/CrNcboh2Bas90t4FBd4rU=; b=l7nSgBEoXuUVYX42359cayWQcwgAo//qe1lXRNMeWZ+wFIouveiSsbNW Ca/zH9alidCiPDy2mXoqMf/C6tKbu+6uTRujECETtitIdI0sbT19uaBHk nT5sEL+UFPJDWqm5aX/4s5iGF5nv5wegqJADOVRzcE2x5f8jzWOw8rBNq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAI538FCtJXG9/2dsb2JhbABEhjmkX5FufBZzgh4BAQEEAQEBIAQNOgsMBAIBBgIRAgEBAQEBAgIGGQQDAgICHwYLFAEICAIEAQkEBQiHfwMPDIp0mneIdQ2HSIEjilWEGzJhA5Q1AY0MhRKCdYFmBx0a X-IronPort-AV: E=Sophos;i="4.84,453,1355097600"; d="scan'208";a="161523322" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jan 2013 20:40:09 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0BKe9I6011627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jan 2013 20:40:09 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 14:40:09 -0600 From: "Eric Osborne (eosborne)" To: =?utf-8?B?5pu+5bO75rOi?= , "wyaacov@gmail.com" Thread-Topic: [mpls] in some scenario RFC6378 can not protect the traffic, so much as take the PSC state to crash. Thread-Index: AQHN71WmKVcaywHJ3UaDzYpcjZCtLJhD0O4AgADHSLA= Date: Fri, 11 Jan 2013 20:40:09 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721009D49F@xmb-rcd-x09.cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] in some scenario RFC6378 can not protect the traffic, so much as take the PSC state to crash. 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, 11 Jan 2013 20:40:15 -0000 SSBkb24ndCB0aGluayB0aGVyZSBuZWVkcyB0byBiZSBhIHRyYW5zaWVudCBzdGF0ZSBzdWNoIGFz ICd0ZW1wb3Jhcnkgbm9ybWFsJy4gIElmIGFuIGltcGxlbWVudGF0aW9uIGhhcyBtdWx0aXBsZSBp bnB1dHMgKG9uZSBsb2NhbCwgb25lIHJlbW90ZSkgYW5kIHRoZSBoaWdoZXN0LXByaW9yaXR5IGlu cHV0IGdvZXMgYXdheSwgaXQgc2hvdWxkIGxvb2sgYXQgdGhlIHJlbWFpbmluZyBpbnB1dCB0byBk ZWNpZGUgd2hhdCB0byBkbyBiZWZvcmUgZG9pbmcgYW55dGhpbmcuICBUcmFuc2l0aW9uaW5nIGlu dG8gdGVtcG9yYXJ5IG5vcm1hbCBzZWVtcyBsaWtlIGEgbmHDr3ZlIGltcGxlbWVudGF0aW9uLg0K DQpBcyBmYXIgYXMgIiBidXQgaSB0aGluayBhdXRob3Igb2YgUkZDIHNoYWxsIG1ha2Ugc3VyZSB0 aGUgc3RhbmRhcmQgaXMgY2xlYXIgYW5kIG5vIGFtYmlndWl0eSIsIEkgYWdyZWUuICBXZSd2ZSBn b3R0ZW4gdGhpcyBxdWVzdGlvbiBhIGZldyB0aW1lcyBvbiB0aGUgbGlzdCBhbmQgSSd2ZSBoYWQg aXQgYSBmZXcgb2ZmLWxpc3QgYXMgd2VsbC4gIEkgd2lsbCB0YWtlIHN0ZXBzIHRvIGNsYXJpZnkg dGhlIGxhbmd1YWdlIGluIFJGQzYzNzguICBIb3BlZnVsbHkgSSdsbCBoYXZlIHNvbWV0aGluZyBv dXQgaW4gdGltZSBmb3IgT3JsYW5kby4NCg0KDQoNCmVyaWMNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiA/Pz8NCj4gU2VudDogVGh1cnNkYXksIEphbnVh cnkgMTAsIDIwMTMgOTo0NCBQTQ0KPiBUbzogd3lhYWNvdkBnbWFpbC5jb20NCj4gQ2M6IG1wbHNA aWV0Zi5vcmc7IHlhYWNvdi53ZWluZ2FydGVuQG5zbi5jb20NCj4gU3ViamVjdDogUmU6IFttcGxz XSBpbiBzb21lIHNjZW5hcmlvIFJGQzYzNzggY2FuIG5vdCBwcm90ZWN0IHRoZSB0cmFmZmljLCBz bw0KPiBtdWNoIGFzIHRha2UgdGhlIFBTQyBzdGF0ZSB0byBjcmFzaC4NCj4gDQo+IA0KPiANCj4g eWFhY292LHRoYW5rcyBmb3IgeW91ciBwYXRpZW50IGV4cGxhaW4uDQo+IA0KPiAxLiBSZWdhcmRp bmcgU2NlbmFyaW8gIzE6YWNjb3JkaW5nIHRoZSBTZWN0aW9uIDQuMy4zLjEsaSB0aGluayB0aGUg dGhlcmUgbmVlZCBhDQo+IG5ldyBzdGF0ZSAtLS1URU1QT1JBUlkgTk9STUFMIFNUQVRFLGp1c3Qg YXMgaXRzIG5hbWUgaW1wbGllcyx0aGlzIHN0YXRlIGlzIGENCj4gdGVtcG9yYXJ5IHN0YXRlLGFu ZCBpbiB0aGlzIHN0YXRlIExFUiBzaGFsbCBuZXZlciBzZW5kIE5SIFBEVSB0byBpdHMgcGVlciBh bmQNCj4gd2lsbCBjaGVjayBpdHMgbG9jYWwgcGVyc2lzdGVudCBzdGF0ZSB0byBkZXNpZGUgdGhl IGZpbmFsIHN0YXRlIGFuZCBpbmZvcm0gaXRzIHBlZXINCj4gYnkgUFNDIFBEVSBhY2NvcmRpbmcg dGhpcyBmaW5hbCBzdGF0ZS4NCj4gDQo+IDIuUmVnYXJkaW5nIFNjZW5hcmlvICMyOkkgd29uZGVy IGhvdyB0byBkZWZpbmUgImNvbnRyYWRpY3RvcnkiLiBhbnkgY2hhbmdlIG9mDQo+IHRoZSBQU0Mg UERVIG9yIHRoZSBQYXRoIGlzIG5vdCBzYW1lIHdpdGggcHJldmlvdXMgUFNDIFBEVSBvciBhbnkg b3RoZXI/DQo+IA0KPiANCj4gDQo+IEJlc3QgUmVnYXJkcyENCj4gSnVuYm8gWmVuZyhCb0JvKQ0K PiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IERhdGU6 IFRodSwgMTAgSmFuIDIwMTMgMTk6MTI6MDggKzAyMDANCj4gPiBTdWJqZWN0OiBSZTogW21wbHNd IGluIHNvbWUgc2NlbmFyaW8gUkZDNjM3OCBjYW4gbm90IHByb3RlY3QgdGhlDQo+ID4gdHJhZmZp Yywgc28gbXVjaCBhcyB0YWtlIHRoZSBQU0Mgc3RhdGUgdG8gY3Jhc2guDQo+ID4gRnJvbTogd3lh YWNvdkBnbWFpbC5jb20NCj4gPiBUbzogempiZGFtb0Bob3RtYWlsLmNvbQ0KPiA+IENDOiBtcGxz QGlldGYub3JnOyB5YWFjb3Yud2VpbmdhcnRlbkBuc24uY29tDQo+ID4NCj4gPiBKdW5ibywgaGkN Cj4gPg0KPiA+IFRoYW5rIHlvdSBmb3IgeW91ciBzY2VuYXJpb3MuICBIb3dldmVyLCBib3RoIG9m IHRoZXNlIHNjZW5hcmlvcyBhcmUNCj4gPiBhZGRyZXNzZWQgYnkgdGhlIHRleHQgb2YgUkZDNjM3 OC4NCj4gPg0KPiA+IDEuIFJlZ2FyZGluZyBTY2VuYXJpbyAjMTogVGhlIHNlY29uZCBwYXJhZ3Jh cGggb2YgU2VjdGlvbiA0LjMuMy4xDQo+ID4gc3RhdGVzIC0gIldoZW4gdGhlIExFUiB0cmFuc2l0 aW9ucyBpbnRvIHRoZSBOb3JtYWwgc3RhdGUsIHRoZSBQU0MNCj4gPiBDb250cm9sIFByb2Nlc3Mg U0hBTEwgY2hlY2sgdGhlIHBlcnNpc3RlbnQgc3RhdGUgb2YgdGhlIGxvY2FsIHRyaWdnZXJzDQo+ ID4gdG8gZGVjaWRlIGlmIGl0IHNob3VsZCBmdXJ0aGVyIHRyYW5zaXRpb24gaW50byBhIG5ldyBz dGF0ZS4uLi4iDQo+ID4gTWVhbmluZyB0aGF0IGluIHlvdXIgc2NlbmFyaW8sIGFmdGVyIHJlY2Vp dmluZyB0aGUgQ2xlYXIsIGJlZm9yZQ0KPiA+IHRyYW5zaXRpb25pbmcgaW50byBOb3JtYWwgU3Rh dGUsIExFUi0xIHNob3VsZCBoYXZlIGNoZWNrZWQgdGhlIHN0YXR1cw0KPiA+IG9mIHRoZSBvdGhl ciB0cmlnZ2VycyBhbmQgZGVjaWRlZCwgYmFzZWQgdXBvbiB0aGUgc3RpbGwgYWN0aXZlIFNGLVcg dG8NCj4gPiB0cmFuc2l0aW9uIGludG8gUHJvdGVjdGluZyBGYWlsdXJlIHN0YXRlLCB0cmFuc21p dHRpbmcgYSBTRigxLDEpDQo+ID4gbWVzc2FnZS4gQXMgdG8gdGhlIHJlYWN0aW9uIG9mIExFUi0y LCBzZWUgYmVsb3cuDQo+ID4NCj4gPiAyLiBSZWdhcmRpbmcgU2NlbmFyaW8gIzI6IFRoZSBzZWNv bmQgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4zLjMgc3RhdGVzDQo+ID4gLSJXaGVuIGEgTEVSIGlz IGluIGEgcmVtb3RlIHN0YXRlLCBpLmUuIHN0YXRlIHRyYW5zaXRpb24gaW4gcmVhY3Rpb24NCj4g PiB0byBhIFBTQyBtZXNzYWdlIHJlY2lldmVkIGZyb20gdGhlIGZhci1lbmQgTEVSLCBhbmQgcmVj ZWl2ZXMgYSBuZXcgUFNDDQo+ID4gbWVzc2FnZSBmcm9tIHRoZSBmYXItZW5kIExFUiB0aGF0IGlu ZGljYXRlcyBhIGNvbnRyYWRpY3Rvcnkgc3RhdGUsDQo+ID4gZS5nLiBpbiByZW1vdGUgVW5hdmFp bGFibGUgc3RhdGUgcmVjZWl2aW5nIGEgcmVtb3RlIEZTKDEsMSkgbWVzc2FnZSwNCj4gPiB0aGVu IHRoZSBQU0MgQ29udHJvbCBMb2dpYyBTSEFMTCByZWV2YWx1YXRlIGFsbCBpbnB1dHMgKGJvdGgg dGhlIGxvY2FsDQo+ID4gaW5wdXQgYW5kIHRoZSByZW1vdGUgbWVzc2FnZSkgYXMgaWYgdGhlIExF UiBpcyBpbiB0aGUgTm9ybWFsIHN0YXRlLiINCj4gPiBNZWFuaW5nIHRoYXQgaW4gYm90aCB0aGUg Y29udGludWF0aW9uIG9mIHRoZSBwcmV2aW91cyBzY2VuYXJpbyBhcyB3ZWxsDQo+ID4gYXMgaW4g eW91ciBzY2VuYXJpbywgTEVSLTIgc2hvdWxkIHJlYWN0IHRvIHRoZSByZW1vdGUgU0YgbWVzc2Fn ZSBhcyBpZg0KPiA+IGluIE5vcm1hbCBhbmQgdHJhbnNpdGlvbiBpbnRvIFJlbW90ZSBQcm90ZWN0 aW5nIEZhaWx1cmUgU3RhdGUuDQo+ID4NCj4gPiBUaGVyZWZvcmUsIEkgY29udGVuZCB0aGF0IG5l aXRoZXIgc2NlbmFyaW8gd2lsbCBjYXVzZSBQU0MgdG8gY3Jhc2guDQo+ID4NCj4gPg0KPiA+DQo+ ID4gT24gVGh1LCBKYW4gMTAsIDIwMTMgYXQgMTE6MTAgQU0sIOabvuWzu+azog0KPiA+IDx6amJk YW1vQGhvdG1haWwuY29tPG1haWx0bzp6amJkYW1vQGhvdG1haWwuY29tPj4gd3JvdGU6DQo+ID4N Cj4gPg0KPiA+IChpZiB0aGUgZmlndXJlIGNhbiBub3QgZGlzcGxheSBub3JtYWxseSxwbGVhc2Ug c2VlIHRoZSBhdHRhY2gNCj4gPiBmaWxlLnRoYW5rcy4pDQo+ID4NCj4gPg0KPiA+IFdoZW4gaW4g bXVsdGkgZmF1bHQvcHJpb3JpdHkgY29uZGl0aW9uIHNjZW5hcmlvLFJGQzYzNzggY2FuIG5vdA0K PiA+IHByb3RlY3QgdGhlIHRyYWZmaWMgc28gbXVjaCBhcyB0YWtlIHRoZSBQU0Mgc3RhdGUgdG8g Y3Jhc2guY29uc2lkZXINCj4gPiB0aGUgZm9sbG93aW5nIDIgc2NlbmFyaW8uDQo+ID4NCj4gPiAg ICAgICAgICAgICArLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKw0KPiA+ ICAgICAgICAgICAgIHwgTEVSMSB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwgTEVSMiB8DQo+ ID4gICAgICAgICAgICAgKy0tLSstLSsgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLSstLSsN Cj4gPiAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0+fA0K PiA+ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ ID4gICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4g PiAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+ ICAgbG9jYWwgbG9ja291dCB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4g ICAgaW5wdXQgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tTE9DSy0tLS0tLS0tLS0tLS0tLS0+fA0KPiA+ICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAg ICAgICAgICAgICAgfDwtLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+ICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICB1bmlk aXJlY3Rpb24gIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgIFNGX1cg cmFpc2UgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLUxPQ0stLS0tLS0tLS0tLS0tLT58DQo+ID4gICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAg ICAgICB8PC0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ID4gICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgIGxvY2FsIGNsZWFy ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAgIGlucHV0ICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tPnwNCj4gPiAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAgICAgICAgICAgICAgIHw8 LS0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gPiAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+DQo+ID4NCj4gPiAgICAgICAgICAg ICAgZmlndXJlIDE6IHVuaWRpcmVjdGlvbiBTRl9XIHJhaXNlIGFmdGVyIGxvY2FsIGxvY2tvdXQN Cj4gPiBpbnB1dA0KPiA+DQo+ID4gaW4gZmlndXJlIDEsY29uc2lkZXIgdGhlIGZvbGxvd2luZyBw cm9jZWR1cmUNCj4gPiAxLkxFUjEgYW5kIExFUjIgYXJlIGJvdGggaW4gTk9STUFMIHN0YXRlIGFu ZCBleGNoYW5nZSBOUiBQRFUuDQo+ID4gMi50aGUgbG9ja291dCBjb21tYW5kIGlucHV0IGludG8g TEVSMSx0aGVuIExFUjEgc2VuZCBMT0NLIHRvIExFUjIsTEVSMg0KPiA+IHNlbmQgTlIgdG8gTEVS MS4NCj4gPiAzLmEgdW5pZGlyZWN0aW9uIFNGX1cgaXMgcmFpc2VkIGluIExFUjEsYWNjb3JkaW5n IFJGQzYzNzgsIExFUjEgc3RpbGwNCj4gPiBzZW5kIExPQ0sgdG8gTEVSMixMRVIyIHNlbmQgTlIg dG8gTEVSMS4NCj4gPiA0LnRoZSBjbGVhciBjb21tYW5kIGlucHV0IGludG8gTEVSMSxhY2NvcmRp bmcgUkZDNjM3OCxMRVIxIHdpbGwgc2VuZA0KPiA+IE5SIHRvIExFUjIsTEVSMiBzdGlsbCBzZW5k IE5SIHRvIExFUjEuIHNvIHRyYWZmaWMgaXMgYnJva2VuLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ ID4gICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAg ICArLS0tLS0tKw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgfCBMRVIxIHwgICAgICAgICAg ICAgICAgICAgICAgICAgfCBMRVIyIHwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICstLS0r LS0rICAgICAgICAgICAgICAgICAgICAgICAgICstLS0rLS0rDQo+ID4gICAgICAgICAgICAgICAg ICAgICAgIE4gICAgKy0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICBODQo+ ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0t LS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ID4gICAgICAgbG9jYWwgbG9ja291dCBpbnB1 dCAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAg ICAgICAgICAgICAgICAgVUE6TE86TCArLS0tLS0tLS0tLS1MT0NLLS0tLS0tLS0tLS0tLS0tLT58 DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfFVBOkxPOlINCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgfDwtLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+ICAgICAgICAgbG9jYWwg Y2xlYXIgaW5wdXQgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIE4gICstLS0tLS0tTlItLS0t LS0tLS0tLS0tLS4uLi4uLi4uLnwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAgICAgICAgICAgICAgU0ZfVyBy YWlzZSAgfCB0aGlzIG5yIGlzIGxvc3QgZm9yIHNtdGguICAgICAgfA0KPiA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgYW5kIFNGX1cgaXMgcmFpc2VkLiAgICAgICAgICAgIHwNCj4gPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS1TRl9XLS0tLS0t LS0tLS0tLS0tLS0+fGFsd2F5cyBpbiBVQTpMTzpSDQo+ID4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLVNGX1ctLS0t LS0tLS0tLS0tLS0tKw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4NCj4gPiAgICAgICAgZmlndXJl IDI6IGFmdGVyIGNsZWFyIGEgbG9jYWwgTE9DS09VVCBjb21tYW5kLFNGX1cgaXMgcmFpc2UNCj4g PiBpbW1lZGlhdGVseSxhbmQgdGhlIE5SIHNlbmQgdG8gTEVSMiBpcyBsb3N0IGZvciBzb21ldGhp bmcuDQo+ID4NCj4gPiBpbiBmaWd1cmUgMixjb25zaWRlciB0aGUgZm9sbG93aW5nIHByb2NlZHVy ZS4NCj4gPiAxLkxFUjEgYW5kIExFUjIgYXJlIGJvdGggaW4gTk9STUFMIHN0YXRlIGFuZCBleGNo YW5nZSBOUiBQRFUuDQo+ID4gMi50aGUgbG9ja291dCBjb21tYW5kIGlucHV0IGludG8gTEVSMSx0 aGVuIExFUjEgc2VuZCBMT0NLIHRvIExFUjIgYW5kDQo+ID4gdHJhbnNmZXIgdG8gVUE6TE86TCxM RVIyIHNlbmQgTlIgdG8gTEVSMSBhbmQgdHJhbnNmZXIgdG8gVUE6TE86Ui4NCj4gPiAzLnRoZSBj bGVhciBjb21tYW5kIGlucHV0IGludG8gTEVSMSxMRVIxIHRyYW5zZmVyIHRvIE5SIGFuZCBzZW5k IE5SIHRvDQo+ID4gTEVSMixidXQgdGhpcyBOUiBpcyBsb3N0IGZvciBzb21lIHVua25vd24gcmVh c29uLCBhbmQgU0ZfVyBpcyByYWlzZWQNCj4gPiBpbW1lZGlhdGVseSBpbiBMRVIxLHNvIHRoYXQg dGhlIE5SIHRoYXQgc2VuZCBieSBMRVIxIHRvIExFUjIgaXMNCj4gPiByZXBsYWNlZCBieSBTRl9X Lg0KPiA+IDQubm88aHR0cDovLzQubm8+IE5SIHJlYWNoIExFUjIsIGlmIHRoZSBlcnJvciBpcyBi aWRpcmVjdGlvbmFsLExFUjINCj4gPiB3aWxsIHNlbmQgU0ZfVyB0byBMRVIxLG9yIE5SIHRvIExF UjIgaWYgdW5pZGlyZWN0aW9uYWwuYnV0IGluIGFueQ0KPiA+IGNvbmRpdGlvbixMRVIyIHdpbGwg c3RpbGwgaW4gVUE6TE86UiBzdGF0ZS50aGUgUFNDIGlzIGNyYXNoZWQuDQo+ID4NCj4gPg0KPiA+ IHNvIGkgaGF2ZSAyIHBpZWNlcyBvZiBzdWdnZXN0aW9uDQo+ID4gMS5MRVIgYWx3YXlzIHNlbmQg aGlzIGxvY2FsIGhpZ2hlc3QgcHJpb3JpdHkgdG8gaXQncyBwZWVyLg0KPiA+IDIuTEVSIGFsd2F5 cyBhY2NlcHQgdGhlIGlucHV0IGZyb20gaGlzIHBlZXIgYnkgUFNDIFBEVS4NCj4gPg0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBCZXN0IFJlZ2FyZHMhDQo+ID4NCj4gPg0KPiA+DQo+ID4g SnVuYm8gWmVuZyhCb0JvKQ0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbXBscyBtYWls aW5nIGxpc3QNCj4gPiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+DQo+ID4NCj4gPg0K PiA+DQo+ID4gLS0NCj4gPiBUaGFueCBhbmQgQlIsDQo+ID4geWFhY292DQo+ID4NCj4gPiBTdGls bCBsb29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHkNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From adrian@olddog.co.uk Fri Jan 11 13:10:55 2013 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 D61DB21F8ACE; Fri, 11 Jan 2013 13:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 hL-iEZ67fLul; Fri, 11 Jan 2013 13:10:53 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5948A21F8AC8; Fri, 11 Jan 2013 13:10:50 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0BLAmOk032164; Fri, 11 Jan 2013 21:10:48 GMT Received: from 950129200 (089144192150.atnat0001.highway.a1.net [89.144.192.150]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0BLAj8v032133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Jan 2013 21:10:47 GMT From: "Adrian Farrel" To: , , , , Date: Fri, 11 Jan 2013 21:10:47 -0000 Message-ID: <01cb01cdf040$2219c5e0$664d51a0$@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: Ac3wPqAVHt9RLqNORBmXnogF2kx3kQ== Content-Language: en-gb Subject: [mpls] FW: Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC 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, 11 Jan 2013 21:10:55 -0000 Heads up. A lot of you will be interested in this. Comments as usual for IETF last calls (see the instructions embedded). Do not send your comments in reply to *this* message. Thanks, Adrian > Sent: 11 January 2013 19:36 > To: IETF-Announce > Cc: opsawg@ietf.org > Subject: Last Call: (An > Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) > to Informational RFC > > > The IESG has received a request from the Operations and Management Area > Working Group WG (opsawg) to consider the following document: > - 'An Overview of Operations, Administration, and Maintenance (OAM) > Mechanisms' > as Informational RFC > > 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 2013-01-25. 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 > > > Operations, Administration, and Maintenance (OAM) is a general term > that refers to a toolset that can be used for fault detection and > isolation, and for performance measurement. OAM mechanisms have been > defined for various layers in the protocol stack, and are used with a > variety of protocols. > > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From adrian@olddog.co.uk Fri Jan 11 14:29:29 2013 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 9621D21F8A54 for ; Fri, 11 Jan 2013 14:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 RW26rxvC9FJR for ; Fri, 11 Jan 2013 14:29:29 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3B221F8A50 for ; Fri, 11 Jan 2013 14:29:28 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0BMTRPj024874; Fri, 11 Jan 2013 22:29:27 GMT Received: from 950129200 (089144192060.atnat0001.highway.a1.net [89.144.192.60]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0BMTPoC024858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Jan 2013 22:29:26 GMT From: "Adrian Farrel" To: Date: Fri, 11 Jan 2013 22:29:25 -0000 Message-ID: <01eb01cdf04b$1e64fa40$5b2eeec0$@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: Ac3wSxk5bfKvQOMKT66QgRMzIQV8sQ== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-tp-ethernet-addressing 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, 11 Jan 2013 22:29:29 -0000 Hi, I have conducted my usual AD review of your document as part of the publication request processing. The aim of my review is to catch any issues that might show up in IETF last call, directorate reviews, or IESG evaluation. The intent is to resolve the issues by text changes or through email discussion to smooth the passage of the document through the later stages of the process. I have reviewed this document jointly with draft-ietf-mpls-gach-adv and since the author team is the same for the two documents, I recommend that you process the comments for the two documents at the same time. As usual, all my comments are open for disagreement and discussion. I think that you will probably want to produce a revision of this document to address my comments, so I have put it into "Revised I-D Needed" state in the data tracker. Thanks for the work, Adrian === The abbreviations GAL and OAM are not used in the document and can be removed from Section 1.1. --- Am I missing something? Why do you only support 48-bit MAC addresses? --- I am *really* surprised that this document does not mention LLDP. In [I-D.ietf-mpls-gach-adv] you state... 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. So this document needs to say the same thing (all over and in 18pt red bold). Furthermore, it needs to define what "HOULD" means in this context. --- In Section 4... Could you please identify (with TBD1 - to be assigned by IANA) the application ID of the new "Ethernet Interface Parameters" application. Could you please state: "The format of the TLVs is as defined in [I-D.ietf-mpls-gach-adv]. Could you please include the type values for the two TLVs you are defining (so that people don't have to look ahead to the IANA section). Since the two TLVs you are defining have predictable lengths, it would be nice if you included the specific length values to be used. --- I think section 4 is missing something. It is clear from [I-D.ietf-mpls-gach-adv] that at least one TLV must be present in the Ethernet Interface Parameters" ADB element. Is there a requirement that the Source MAC Address TLV is always present? What are the rules for multiple occurrences of either of the TLVs you have defined? --- Somewhere, probably Section 4, should leverage the stated intention in [ID.ietf-mpls-gach-adv] by stating that the values received in the new ADB element SHOULD (or probably MUST) be made accessible for inspection by network operators, and where local configuration is updated by the received information, it MUST be clear why the configured value has been changed. Furthermore, you probably need to discuss whether information learned in this way is allowed to be persistent across node or interface discontinuities. (The last point suggests to me that you might want to include a brief section on handling changes in adjacent MAC addresses - a point that you have given as a motivation for the work.) --- In my comments on [I-D.ietf-mpls-gach-adv] I ask about the consequences of message loss. This issue seems to apply to this document so, depending on how you handle the issue in [I-D.ietf-mpls-gach-adv] you may need to add something to this document. --- Section 5 should reference [I-D.ietf-mpls-gach-adv] for the security properties of the GAP. It should probably note that an effective attack is modifying the Source MAC Address value, while modifying the MTU value may also have significant consequences. Furthermore, it may be the case that visibility into the contents of either of the TLVs could provide information that is useful for an attacker. --- In section 6.1, please include an IANA action to update the reference for the MAC address to point to the RFC number assigned to this document on publication. --- In section 6.2, could you please replace 0x0001 with TBD1. --- Trivial point, but there are precisely three authors, all marked as editors. You could safely dispense with the "editor" designation (on the front page and in the Authors' Addresses section). From adrian@olddog.co.uk Fri Jan 11 14:29:31 2013 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 DFDC021F8A99 for ; Fri, 11 Jan 2013 14:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 u9YtQaEULhPo for ; Fri, 11 Jan 2013 14:29:30 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5282E21F8A52 for ; Fri, 11 Jan 2013 14:29:29 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0BMTS3K024880; Fri, 11 Jan 2013 22:29:28 GMT Received: from 950129200 (089144192060.atnat0001.highway.a1.net [89.144.192.60]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0BMTPoD024858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Jan 2013 22:29:27 GMT From: "Adrian Farrel" To: Date: Fri, 11 Jan 2013 22:29:25 -0000 Message-ID: <01ec01cdf04b$1ee32af0$5ca980d0$@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: Ac3wSxV3qBP+BoqVSkm3NwGCMJyhBQ== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-gach-adv 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, 11 Jan 2013 22:29:32 -0000 Hi, I have conducted my usual AD review of your document as part of the publication request processing. The aim of my review is to catch any issues that might show up in IETF last call, directorate reviews, or IESG evaluation. The intent is to resolve the issues by text changes or through email discussion to smooth the passage of the document through the later stages of the process. I have reviewed this document jointly with draft-ietf-mpls-tp- ethernet-addressing and since the author team is the same for the two documents, I recommend that you process the comments for the two documents at the same time. It will become clear to you as you read this review that I am not overly impressed with the quality of this protocol specification. It is possible that the issue lies with documentation details and the level of review that the working group gave. However, I have not often seen a better example of why it is valuable to have interworking implementations of a protocol specification before requesting publication. As usual, all my comments are open for disagreement and discussion. I think that you will probably want to produce a revision of this document to address my comments, so I have put it into "Revised I-D Needed" state in the data tracker. Thanks for the work, Adrian === Please update the captions to the figures as "Figure n : blah, blah" --- Section 1 It provides an auxiliary logical data channel associated with an MPLS Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. Marginally ambiguous because of clause ordering. It is not "a section over which a variety of protocols may flow." Suggest re-wording... It provides an auxiliary logical data channel over which a variety of protocols may flow. Each such data channel is associated with an MPLS Label Switched Path (LSP), a pseudowire, or a section (link). --- Section 1 ...Operations, Administration, and Maintenance (OAM) capabilities associated with the underlying LSP, pseudowire, or section. I don't think "underlying" is right, is it? How about: ...Operations, Administration, and Maintenance (OAM) capabilities for the associated LSP, pseudowire, or section. --- Section 1 The main principle guiding the design of the MPLS G-ACh advertisement protocol (GAP) is simplicity. Capitalise, please. --- Section 1.1 After... The G-ACh advertisement protocol presented in this document thus allows LSRs to exchange information of a similar sort to that supported by LLDP for Ethernet links. ...could you please a simple sentence explaining why it was not enough to provide a way to encapsulate LLDP in the G-ACh. [Hint: I think the answer is that you envisage the GAP being used for a larger set of MPLS-specific features than is currently defined in LLDP and for which you do not consider it would be appropriate to extend LLDP.] This is particularly important given that: - the only use of the GAP mentioned anywhere is [I-D.ietf-mpls-tp- ethernet-addressing] - you say... 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. >From where I am sitting, that looks like "This protocol is not needed because LLDP does everything we want." So, the question you need to answer (for me and in the I-D) is why have you invented a new protocol when LLDP does everything that is needed? And, BTW, I would like to understand the meaning of "SHOULD" in a 2119 context in this document. Since it is a protocol spec, and since it references 2119, the implication is that implementations of [I-D.ietf-mpls-tp-ethernet-addressing] should not be made unless another I-D using the GAP is published as an RFC *and* implemented by the same implementation. Please don't think that deleting this text will get you off the hook! You have already made the point (and with WG consensus). Now you need to explain to me why there is a need for either document. I guess you should also say why you consider LMP to be inappropriate. --- It is not really necessary to include LSR in Section 1.2 as the term is only used before that section. --- Section 2 Although one GAP message can contain data for several applications, the receiver maintains the data associated with each application separately. This enables the sender to transmit a targeted update that refreshes the data for a subset of applications without affecting the data of other applications. How the receiver maintains the data is entirely an implementation issues. I suggest you rephrase this as: Each GAP message can contain data for several applications. A sender may transmit a targeted update that refreshes the data for a subset of applications without affecting the data of other applications sent on a previous message. --- Section 3 After "XXXX" please note "(TBD by IANA)" so that the RFC editor spots this, correlates it with the IANA section, and updates it accordingly. In Section 9.1, please mark the value to be assigned as XXXX --- Section 3 s/A Gap message/A GAP message/ --- Section 3 Can two ADB elements for the same application be present in the same message? If so what processing rules apply? If not, how is the error handled? Can two TLVs of the same type be present in the same ADB element? If so what processing rules apply? If not, how is the error handled? And the combination of cases, if two ADB elements for the same application can be present in the same message, can a TLV of the same type be present in each? If so what processing rules apply? If not, how is the error handled? --- Section 3 and 5 Although Section 5.1 tells us how the Message Identifier can be set, it is ambiguous wrt Section 3 since in Section 3 we have: Message Identifier: Unique identifier of this message And in 5.1 we have: The Message Identifier (MI) uniquely identifies this message and is set at the sender's discretion. What does "at the sender's discretion" mean? It seems to say: "If the sender doesn't fancy setting it, that's OK." Additionally, it is not clear what the uniqueness scope of the Message Identifier is supposed to be. Presumably not globally unique! Is it per sender or per data-channel per sender? The sole purpose of the MI seems to be contained in the final paragraph of Section 5.1. If that is the case, you seem to have some confusion between rapid retransmission (same message) and lifetime avoiding retransmission (different message). All this needs to be cleaned up and explained. Noting that the last sentence of 5.1 belongs in 5.2. I have to wonder whether you really need the field. --- Sections 2, 3, and 5 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. Have you considered offering a lifetime value meaning "retain until replaced"? This would *considerably* simplify the job of the sender which would not need to run multiple timers to ensure that the information is updated in a timely manner and doesn't accidentally expire. Note also that 2*16 seconds is not a very long time. things like the MAC address of an interface can safely be considered "stable". In rather a topsy-turvy way you say in Section 5.1... Lifetimes SHOULD be set in such a way that at least three updates will be sent prior to Lifetime expiration. For example, if updates are sent at least every 60 seconds, a Lifetime of 185 seconds may be used. ...Isn't it the other way around? Shouldn't updates be sent according to the lifetime value that has been set? Discarding the information when the timer expires needs to be clarified. I think you mean "revert to the configuration-based state that was held before the information was received." But you might mean "transition to the complete absence of this information." In Section 2 should you discuss message loss and the consequences? Any mitigation you need to add? Is the retransmission to protect against lifetime expiry supposed to handle this? If so, it doesn't seem frequent enough to install the initial state? Do you need a two-speed timer: rapid on first use and dropping down to slow for state retention? Or would an Ack be easier? Probably, the final paragraph of Section 5.1 can be adapted to handle this case, and then you can put a forward pointer in Section 2. But note that the final paragraph of 5.1 is a bit of a mess!... 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. The MI may be used to detect and discard duplicate messages. ...What is a "delay appropriate to the application?" Maybe it means "Each specification of a GAP application must state the appropriate delay to use for such fast retransmission." Which would be fine, but would require this document to make the statement for Application 0x0000 and would require [] to make a statement for Application 0x0001. ... Also "The procedure SHOULD be used..." reads like the procedure is intended to be used. But "...if at all" really means "The procedure SHOULD NOT be used except..." I can't understand what is meant by "If the lifetime is zero the data is immediately marked as expired." Are you trying to say that the data should be processed, potentially replacing any stored information, and then should be "discarded" (noting my previous comment about "discarded" not being clear)? Or are you trying to say, that the ADB element should be discarded unprocessed? Lastly, the recommended multiplier ("at least three updates will be sent prior to Lifetime expiration") cuts it too fine! You need to allow for out-queues, transmission, and processing. The normal approach to this (probably going back to Van Jacobson) is to add a unit of half. Thus, in your case, Lifetime = 3.5 * Update. --- Section 3 Are TLV Value fields padded up to a multiple of 4 octets? --- Section 3 It is clear that each ADB element must contain at least one TLV. What is the error processing for an empty ADB element? --- Section 4 Since the Application ID 0x0000 ADB contains "metadata and processing instructions rather than static data that is meant to be retained" please explain how the Lifetime field is to be set/interpreted. --- Does the TLV in Section 4.1 support the identifiers described in [I-D.ietf-mpls-tp-itu-t-identifiers]? The chain of references for "non-IP MPLS-TP networks" appears to lead through RFC 6428 to RFC 6370 which (I think) does not include the non-IP identifiers. I see that you are adding new values to the Address Family registry in Section 9.2. It is not clear to me where the definitive reference for those types live. I would like to see more clarity in the text about which address (and where it is specified) is intended for each new code point that you are asking IANA to allocate. --- Section 2 says that this is a one-way protocol, however, Section 4.2 defines an Application ID 0x0000 TLV that forms part of a two-way exchange and is actually a direct request for information. Additionally, it seems a little odd to hide this in a TLV when what it really is is a separate message type. By placing it in the TLVs you open up the prospect of message thrash as two implementations send each other updates without clearing out this TLV. The problem might be amusingly exacerbated by placing 0x0000 in the list of Application ID for which a refresh is requested. In any case, please explicitly clarify that setting a length of zero intends retransmission of the 0x0000 Application data. --- Section 4.3 Does the flush apply to the 0x0000 Application Data previously sent? Why do you not allow selective flushing per Application? --- Section 4.4 The request is strictly advisory: the receiver SHOULD accept and act on the request, but MAY override it at any time. The "SHOULD" that you have used is stronger than "advisory". What is more you don't mean "advisory" you mean "a request". I suggest you change this to ...the receiver MAY accept and act on the request, MAY ignore the request, or MAY resume transmissions at any time according to implementation or configuration choices, and depending on local pragmatics. This section is another example of a TLV that violates the statement in Section 2 that this is a one-way protocol. Lastly, you need to say what it means if the Duration leaves the information as expired (i.e. the Duration takes us beyond the end of the Lifetime). Obviously the sender (of the original information) can decide that that would be a bad thing and retransmit anyway, but it is not clear what the receiver (of the information) would do if the transmission is not made. Frankly, however, it is not clear why you have this TLV. Having gone through the hoops of deciding that you need to be able to send the data, that the data can time out, and that you need to retransmit the data, I think you need to give better motivation for this TLV. --- I wish Sections 4.1 through 4.5 would end up containing the actual TLV Type codes to be used for each TLV. This could be achieved by simply including the values in the figures. (This is safe because these are the first allocations from the new registry and there is no question of IANA not allocating them as requested). --- 5.1 I like that operation of GAP SHOULD be configurable per data channel. But you appear to have written "SHALL". This precludes making an implementation that automatically and always runs GAP. (I think it still allows implementations that don't support GAP at all because they don't implement this spec). --- Paragraph 3 of section 5.2 talks about retaining objects for application data that can be handled. But this is implementation- specific. I think it is only the information that has to be retained. Try to talk about function rather than constrain implementation. --- The last paragraph of 5.2 is a bit confusing. The receiver MAY make use of the application data contained in a GAP message to perform some level of autoconfiguration, for example if the application is an OAM protocol. The implementation SHOULD, however, take care to prevent cases of oscillation resulting from each endpoint attempting to adjust its configuration to match the other. Any such autoconfiguration based on GAP information MUST be disabled by default. I *think* you are really trying to place constraints on future specifications rather than on implementations (there is nothing in this specification that could be used for auto-conf). But I note that [I-D.ietf-mpls-tp-ethernet-addressing] looks like auto-conf and is not disabled by default. --- In Section 6.1, you should discuss the operation of key exchange protocols in the absence of IP protocols in the network. After all, one of the use-cases (oh, the only use case :-) for GAP is to operate in networks that don't have IP available. You might also note that GAP is described as a protocol for exchanging capabilities and configuration: keys might be described by some as exactly such information. If your fall-back is that keys have to be manually configured in the absence of IP, then you desperately need to call this out in [I-D.ietf-mpls-tp-ethernet-addressing] because manual configuration of keys seems a whole lot harder than manual configuration of MAC addresses. --- Section 6.1 I believe that RFC 4107 says that you need to discuss mechanisms for dynamic key update, to make a recommendation as to whether such mechanisms are needed, and to state how often keys need to be updated. --- The problem I see with processing of the Timestamp described in 6.2 is that it does not allow for a sender correcting its clock. Can you add text to help clarify how this case is handled. --- The final paragraph of Section 6.2 is a bit of a throw-away. What you are saying, I think is that "Full algorithm flexibility is provided by the protocol's use of the Authentication Key Identifier which acts as an indirect reference to the algorithm and key data in use. Implementors SHOULD consider the use of [I-D.ietf-karp-crypto-key-table] for key management." You might move this text to the end of 6.1 where it will sit with the discussion of the Key ID. --- How do you distinguish "device discovery" in Section 7 from talking to a device whose MAC address you don't know in [I-D.ietf-mpls-tp-ethernet- addressing] ? Very unclear which MAC address to use when. --- Maybe Section 8 should point at Section 6 since Section 6 seems to be all about Security mechanisms. --- You have used [I-D.ietf-karp-crypto-key-table] in a normative way. Not a big risk as it is currently in KARP WG last call. Please move it to Section 10.1. --- Trivial point, but there are precisely three authors, all marked as editors. You could safely dispense with the "editor" designation (on the front page and in the Authors' Addresses section). From internet-drafts@ietf.org Sat Jan 12 01:40:08 2013 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 EE01221F857E; Sat, 12 Jan 2013 01:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 W4xYWBojl4kt; Sat, 12 Jan 2013 01:40:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6491C21F8462; Sat, 12 Jan 2013 01:40:07 -0800 (PST) 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.37 Message-ID: <20130112094007.11411.8070.idtracker@ietfa.amsl.com> Date: Sat, 12 Jan 2013 01:40:07 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-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: Sat, 12 Jan 2013 09:40:08 -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 : Encapsulating MPLS in UDP Author(s) : Xiaohu Xu Nischal Sheth Lucy Yong Carlos Pignataro Yongbing Fan Filename : draft-ietf-mpls-in-udp-00.txt Pages : 9 Date : 2013-01-12 Abstract: Existing technologies to encapsulate Multi-Protocol Label Switching (MPLS) over IP are not adequate for efficient load balancing of MPLS application traffic, such as MPLS-based Layer2 Virtual Private Network (L2VPN) or Layer3 Virtual Private Network (L3VPN) traffic across IP networks. This document specifies additional IP-based encapsulation technology, referred to as MPLS-in-User Datagram Protocol (UDP), which can facilitate the load balancing of MPLS application traffic across IP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-in-udp-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Sat Jan 12 10:39:21 2013 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 5E95921F87AC for ; Sat, 12 Jan 2013 10:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, 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 j742Ir0qr+cm for ; Sat, 12 Jan 2013 10:39:17 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 18F2821F8788 for ; Sat, 12 Jan 2013 10:39:15 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0CIdEYR023352; Sat, 12 Jan 2013 18:39:14 GMT Received: from 950129200 (089144192042.atnat0001.highway.a1.net [89.144.192.42]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0CIdB1T023341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 12 Jan 2013 18:39:13 GMT From: "Adrian Farrel" To: "'Ross Callon'" References: <62CCD4C52ACDAD4481149BD5D8A72FD309A3976C@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD309A3976C@CH1PRD0510MB355.namprd05.prod.outlook.com> Date: Sat, 12 Jan 2013 18:39:13 -0000 Message-ID: <007401cdf0f4$1f5011c0$5df03540$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01CDF0F4.1F525BB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxX1K3ekKKQiWmLJx20drhWdGlKJh/EvaQ Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] Proposed response to Ring Protection Liaison 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: Sat, 12 Jan 2013 18:39:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0075_01CDF0F4.1F525BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ross, Many thanks for driving this. It's somehow appropriate to write a liaison to the ITU-T in Microsoft Word :-) I have some comments (as an individual). --- I assume the chairs will top and tail this liaison with the usual polite niceties. In particular, we should welcome the way that SG15 is engaging with the MPLS working group on ring protection requirements. --- I suggest using a different numbering scheme to avoid confusion between the two lists of requirements. Include the text: "To avoid confusion we have numbered the suggested requirements in your Liaison as IR1, IR2, etc. and we refer to the requirements in RFC 5654 using the notation as published (i.e., R96, R97, etc.)." And then, obviously, fix the liaison text accordingly. --- This draft does not seem to answer the first noted requirements in the incoming liaison viz. | Requirements for ITU-T G.8132 | Requirements and optimization criteria for ring protection specified in RFC5654 "MPLS-TP | requirements" have to be taken into account. I think this deserves the response: We agree that the requirements and optimization criteria for ring protection set out in RFC 5654 should be taken into account. In particular, we draw your attention to the preamble in Section 2.5.6.1 and the statements made about the cost/benefit implications of specialised protection solutions. ---- In your second paragraph, I don't think it is necessary to say "Adding new requirements for a technology already in active development and deployment is not to be taken lightly," I am sure that the ITU-T is well aware of the risks of moving goalposts. Of course, neither of the proposed requirements IR2 and IR3 proposes a change to linear protection - they are both requirements placed on ring protection. In my view IR2 may make a specialist ring protection scheme almost impossible to devise since it would have to seamlessly upgrade from linear protection. So, I think you should: - delete the apple pie text - invite new requirements to be raised within the MPLS WG using the normal IETF process --- I am not a huge fan of holding technical debate via liaison statement. That said your observations on T1 and T2 are correct. --- In your discussion of T2 you say: > The IETF believes in topology-independent mechanisms whenever possible, > as prescribing or proscribing specific network architectures is outside the > IETF's scope. I wonder whether you can give me a reference for this statement. AFAICS there are plenty of examples of the IETF recommending specific technologies/solutions for specific environments/networks. You might say that, as a general rule, the IETF has tended to try to avoid optimizing for special cases. Or you might simply delete this sentence. --- Later in the discussion of T2 you say: > The IETF believes that the reuse of linear protection mechanisms > in a ring topology (i.e. draft-ietf-mpls-tp-ring-protection) will meet > performance targets in a ring topology, and will do so while allowing > the operator to deploy a single protection method across all possible > network topologies. I do not believe it is your intention to test IETF consensus on this before sending the liaison. You might s/IETF/MPLS working group/ and use the review of this liaison statement as the way to test that consensus. When you say "the performance targets" you should append "expressed in RFC 5654". --- The paragraph on the sophistication of ring-based networks is undoubtedly true. Even in traditional transport networks, ring interconnects have made end-to-end paths appear to traverse a mesh. The ease with which packet networks can bridge between rings makes the meshiness all the more likely. Notwithstanding that, there is (or it could be argued that there is) value in imposing logical protection domains in mesh networks. By treating a portion of the mesh network as a logical ring, certain specific ring protection characteristics (such as those discussed in draft-ietf-mpls-tp-ring-protection) can be leveraged. So, I am wondering what this paragraph is attempting to add to the liaison. --- The way you handle answering C-2098 is correct, but maybe s/C-2098/C-2098 referenced from Annex 2/ Also s/IETF's Fast ReRoute./IETF's MPLS Fast ReRoute described in RFC 4090/ And then, s/The IETF recommends/The MPLS working group recommends/ (assuming you have consensus for that) --- The incoming liaison also says: | We would also like to know status of the individual/working group | drafts containing MPLS-TP ring protection solutions. This needs an answer, and the chairs are probably best placed to craft it. Something like... "draft-ietf-mpls-tp-ring-protection describes the applicability of the generic linear protection mechanisms (RFC 6378) to ring topologies. As such it sets a baseline for determining the optimization value of any other proposed solutions. This draft also discusses a number of the different mechanisms that can be used in ring protection and highlights the optimizations that can be made in packet networks as compared to traditional transport networks where tunnelling is not so readily available. The status of this draft is foo. There are also a considerable number of individual drafts proposing different solutions and addressing different aspects of ring protection. The chairs hope that these documents will be discussed further on the MPLS mailing list so that it becomes clear which offer the best solutions addressing all the requirements and providing optimization benefits. The chairs also hope that the authors of the various drafts will attempt to find compromise positions that allow their approaches to be merged. Lastly, the chairs hope to hear of intent to implement that will clearly show which drafts have concrete support." --- Finally, and off the topic of the liaison response, I wonder whether the chairs have time on the agenda in Orlando to allow a 20 minute (or so) slot discussing ring protection to determine what the next steps are for the WG. Maybe one of the ITU-T experts who attend the IETF could lead a discussion based on the received Annex 2. --- Thanks! Adrian From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: 11 January 2013 18:51 To: mpls@ietf.org Subject: [mpls] Proposed response to Ring Protection Liaison We've had a small team that prepared a response to an incoming liaison from ITU-T SG15 on ring protection. The incoming liaison is: 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/ The proposed response is attached. Please send comments on the proposed response to the MPLS working group mailing list (mpls@ietf.org) by next Friday (January 18, 2013). Thanks, Ross (as MPLS WG co-chair) ------=_NextPart_000_0075_01CDF0F4.1F525BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ross,

 

Many thanks for driving = this.

 

It's somehow appropriate to = write a liaison to the ITU-T in Microsoft Word = :-)

 

I have some comments (as an = individual).

 

---

 

I assume the chairs will top = and tail this liaison with the usual polite niceties. In particular, we = should welcome the way that SG15 is engaging with the MPLS working group = on ring protection requirements.

 

---

 

I suggest using a different = numbering scheme to avoid confusion between the two lists of = requirements. Include the text:

"To avoid confusion we = have numbered the suggested requirements in your Liaison as IR1, IR2, = etc. and we refer to the requirements in RFC 5654 using the notation as = published (i.e., R96, R97, etc.)."

And then, obviously, fix the = liaison text accordingly.

 

---

 

This draft does not seem to = answer the first noted requirements in the incoming liaison = viz.

| Requirements for ITU-T = G.8132

| Requirements and = optimization criteria for ring protection specified in RFC5654 = “MPLS-TP

| requirements” have to = be taken into account.

 

I think this deserves the = response:

We agree that the requirements = and optimization criteria for ring protection set out in RFC 5654 should = be taken into account. In particular, we draw your attention to the = preamble in Section 2.5.6.1 and the statements made about the = cost/benefit implications of specialised protection = solutions.

 

----

 

In your second paragraph, I = don't think it is necessary to say "Adding new requirements for a = technology already in active development and deployment is not to be = taken lightly," I am sure that the ITU-T is well aware of the risks = of moving goalposts. Of course, neither of the proposed requirements IR2 = and IR3 proposes a change to linear protection - they are both = requirements placed on ring protection. In my view IR2 may make a = specialist ring protection scheme almost impossible to devise since it = would have to seamlessly upgrade from linear = protection.

 

So, I think you = should:

- delete the apple pie = text

- invite new requirements to = be raised within the MPLS WG using the normal IETF = process

 

---

 

I am not a huge fan of holding = technical debate via liaison statement. That said your observations on = T1 and T2 are correct.

 

---

 

In your discussion of T2 you = say:

 

> The IETF believes in = topology-independent mechanisms whenever = possible,

> as prescribing or = proscribing specific network architectures is outside = the

> IETF’s = scope.

 

I wonder whether you can give = me a reference for this statement. AFAICS there are plenty of examples = of the IETF recommending specific technologies/solutions for specific = environments/networks.  You = might say that, as a general rule, the IETF has tended to try to avoid = optimizing for special cases. Or you might simply delete this = sentence.

 

---

 

Later in the discussion of T2 = you say:

 

> The IETF believes that = the reuse of linear protection mechanisms

> in a ring topology (i.e. = draft-ietf-mpls-tp-ring-protection) will meet

> performance targets in a = ring topology, and will do so while allowing

> the operator to deploy a = single protection method across all possible

> network = topologies.

 

I do not believe it is your = intention to test IETF consensus on this before sending the liaison. You = might s/IETF/MPLS working group/ and use the review of this liaison = statement as the way to test that consensus.

 

When you say "the = performance targets" you should append "expressed in RFC = 5654".

 

---

 

The paragraph on the = sophistication of ring-based networks is undoubtedly true. Even in = traditional transport networks, ring interconnects have made end-to-end = paths appear to traverse a mesh. The ease with which packet networks can = bridge between rings makes the meshiness all the more likely. =

 

Notwithstanding that, there is = (or it could be argued that there is) value in imposing logical = protection domains in mesh networks. By treating a portion of the mesh = network as a logical ring, certain specific ring protection = characteristics (such as those discussed in = draft-ietf-mpls-tp-ring-protection) can be = leveraged.

 

So, I am wondering what this = paragraph is attempting to add to the liaison.

 

---

 

The way you handle answering = C-2098 is correct, but maybe s/C-2098/C-2098 referenced from Annex = 2/

 

Also s/IETF's Fast = ReRoute./IETF's MPLS Fast ReRoute described in RFC = 4090/

 

And then, s/The IETF = recommends/The MPLS working group recommends/  (assuming you have consensus = for that)

 

---

 

The incoming liaison also = says:

 

| We would also like to know = status of the individual/working group

| drafts containing MPLS-TP = ring protection solutions.

 

This needs an answer, and the = chairs are probably best placed to craft it. Something = like...

"draft-ietf-mpls-tp-ring-protection describes = the applicability of the generic linear protection mechanisms (RFC 6378) = to ring topologies. As such it sets a baseline for determining the = optimization value of any other proposed solutions. This draft also = discusses a number of the different mechanisms that can be used in ring = protection and highlights the optimizations that can be made in packet = networks as compared to traditional transport networks where tunnelling = is not so readily available. The status of this draft is = foo.

There are also a considerable = number of individual drafts proposing different solutions and addressing = different aspects of ring protection. The chairs hope that these = documents will be discussed further on the MPLS mailing list so that it = becomes clear which offer the best solutions addressing all the = requirements and providing optimization benefits. The chairs also hope = that the authors of the various drafts will attempt to find compromise = positions that allow their approaches to be merged. Lastly, the chairs = hope to hear of intent to implement that will clearly show which drafts = have concrete support."

 

---

 

Finally, and off the topic of = the liaison response, I wonder whether the chairs have time on the = agenda in Orlando to allow a 20 minute (or so) slot discussing ring = protection to determine what the next steps are for the WG. Maybe one of = the ITU-T experts who attend the IETF could lead a discussion based on = the received Annex 2.

 

---

 

Thanks!

Adrian

 

From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Ross Callon
Sent: 11 January 2013 18:51
To: = mpls@ietf.org
Subject: [mpls] Proposed response to Ring = Protection Liaison

 

We've had a small team that prepared a response to an = incoming liaison

from ITU-T SG15 on ring protection. The incoming = liaison is:

 

    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.iet= f.org/liaison/1199/

 

The proposed response is attached. =

 

Please send comments on the proposed response to the = MPLS working group mailing

list (mpls@ietf.org) by next Friday (January = 18, 2013).

 

Thanks, Ross

(as MPLS WG = co-chair)

 

 

 

------=_NextPart_000_0075_01CDF0F4.1F525BB0-- From internet-drafts@ietf.org Sun Jan 13 11:08:27 2013 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 9B3A621F87AC; Sun, 13 Jan 2013 11:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 ieoCGl5ZV4Jb; Sun, 13 Jan 2013 11:08:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B9921F87A4; Sun, 13 Jan 2013 11:08:26 -0800 (PST) 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.37 Message-ID: <20130113190826.28694.29612.idtracker@ietfa.amsl.com> Date: Sun, 13 Jan 2013 11:08:26 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-use-cases-and-design-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: Sun, 13 Jan 2013 19:08:27 -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 Applicability; Use Cases and Design Author(s) : Luyuan Fang Nabil Bitar Raymond Zhang Masahiro DAIKOKU Ping Pan Filename : draft-ietf-mpls-tp-use-cases-and-design-05.txt Pages : 14 Date : 2013-01-13 Abstract: This document provides applicability, use case studies and network design considerations for the Multiprotocol Label Switching Transport Profile (MPLS-TP). The use cases include Metro Ethernet access and aggregation transport, Mobile backhaul, and packet optical transport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-use-cases-and-design-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-use-cases-and-design-= 05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Uwe.Joorde@telekom.de Mon Jan 14 00:03:49 2013 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 40A6F21F8848 for ; Mon, 14 Jan 2013 00:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 0zqv7VLByzS7 for ; Mon, 14 Jan 2013 00:03:48 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3C44421F874F for ; Mon, 14 Jan 2013 00:03:46 -0800 (PST) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 14 Jan 2013 09:03:38 +0100 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 14 Jan 2013 09:03:38 +0100 From: To: , Date: Mon, 14 Jan 2013 09:03:36 +0100 Thread-Topic: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod Thread-Index: Ac3dwn9ArYc6awlRSCauV8eLEOx9wAUawzqw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E568A@HE111648.emea1.cds.t-internal.com> References: <50D17A08.8050109@pi.nu> In-Reply-To: <50D17A08.8050109@pi.nu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-ldp-dod@tools.ietf.org Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod 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, 14 Jan 2013 08:03:49 -0000 Support. Cheers, Uwe -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Wednesday, December 19, 2012 9:26 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; Subject: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod Working Group, This is to start a working group last call on draft-ietf-mpls-ldp-dod-03. This working last call is extended due to the upcoming holidays. 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. There are no IPR claims against this draft. All the co-authors has stated that they are not ware of any IPRs. This working group last call will end on January 15, 2013. /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 internet-drafts@ietf.org Mon Jan 14 00:23:26 2013 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 431EE21F884C; Mon, 14 Jan 2013 00:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 zEfK9clEPhkv; Mon, 14 Jan 2013 00:23:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C094821F885C; Mon, 14 Jan 2013 00:23:25 -0800 (PST) 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.37 Message-ID: <20130114082325.13555.11380.idtracker@ietfa.amsl.com> Date: Mon, 14 Jan 2013 00:23:25 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-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, 14 Jan 2013 08:23:26 -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 Traffic Engineering (TE) Management Information = Base (MIB) Author(s) : Venkatesan Mahalingam Kannan KV Sampath Sam Aldrin Thomas D. Nadeau Filename : draft-ietf-mpls-tp-te-mib-05.txt Pages : 55 Date : 2013-01-14 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 managed objects of Tunnels, Identifiers, Label Switch Router and Textual conventions 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-te-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-te-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-te-mib-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From manavbhatia@gmail.com Mon Jan 14 01:09:10 2013 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 5E72D21F867E for ; Mon, 14 Jan 2013 01:09:10 -0800 (PST) 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 ixwVDRSlPr5O for ; Mon, 14 Jan 2013 01:09:09 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6087821F859A for ; Mon, 14 Jan 2013 01:09:09 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id fs19so3263909vbb.16 for ; Mon, 14 Jan 2013 01:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CJUAm3V9lakEu9torSIRvYZeohl8oSGzU5KRbnJWcN4=; b=jVVmWEK37tRXHn0tkMeMtSuM3HIF0zD4gM4WSCuWcK5WNojec6hVaeAk1IANBVV3oL xZKNldK/z85ohTdlzcIZe9Rb3U5wcC5s/2pO8Rv4VwQ43L4V2Uf1H/yM0E3cbzDkPrpD DlU+JfeW5SZgAeO8pTB1wYuLzzfjxZ/kiTZ/NPgqtDp6Af1OMc9BjwJHSfS71D16X7/D 47EV1Sfkoa4MkY8+k5kmEK65ai+55qwau8AYIDtizSxn1fN/O99SdRW8FQKp5oLT2Ag2 /bdgSJsvhNtLQvsny/uKvpJJyjfdvOyFERTTyl8hLtiMQMdf0jWMr/98vLRxTLb57DNO MmrQ== MIME-Version: 1.0 Received: by 10.52.22.107 with SMTP id c11mr89244255vdf.73.1358154548704; Mon, 14 Jan 2013 01:09:08 -0800 (PST) Received: by 10.220.28.200 with HTTP; Mon, 14 Jan 2013 01:09:08 -0800 (PST) In-Reply-To: <20ECF67871905846A80F77F8F4A2757202AA32@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A2757202AA32@xmb-rcd-x09.cisco.com> Date: Mon, 14 Jan 2013 14:39:08 +0530 Message-ID: From: Manav Bhatia To: "Eric Osborne (eosborne)" Content-Type: multipart/alternative; boundary=20cf307c9eaa6cf40204d33bffa4 Cc: "mpls@ietf.org" , "Bhatia, Manav \(Manav\) \(manav.bhatia@alcatel-lucent.com\)" , "lizhong.jin@zte.com.cn" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Comments on draft-jjb-mpls-rsvp-te-hsmp-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, 14 Jan 2013 09:09:10 -0000 --20cf307c9eaa6cf40204d33bffa4 Content-Type: text/plain; charset=ISO-8859-1 Hi, We have posted an updated version of draft-jjb-mpls-rsvp-te-hsmp-lsp which we hope addresses some of the questions raised by the MPLS-RT reviewers team earlier. http://www.ietf.org/id/draft-jjb-mpls-rsvp-te-hsmp-lsp-02.txt Cheers, Manav On Mon, Jul 16, 2012 at 9:19 PM, Eric Osborne (eosborne) wrote: > Overall, I think this is a solid draft. It presents a pair of problems > and the solution to those problems. I'd like to see some input from the > larger community as to whether the two problems the draft presents as > prevalent in operational networks. I'm also curious whether there are any > other uses cases that may take advantage of HSMP. Is there an analog in > non-TE mcast that could be addressed with HSMP? > > Assuming the use cases are valid, I can see it eventually being adopted as > a WG document. > > I have a few comments: > > - Section 1.1 talks about time synchronization. I'm not a timing expert, > so I'm just going off of what I can infer from the document. The text > > "This is possible because of the link delay calculation performed locally > by each node, which enables it to calculate the propagation delay over the > path. This scenario permits that the same PTP Sync messages would be sent > by the PTP master to all the PTP slaves" > > implies that each hop in an LSP used for timing distribution would need to > examine the packet, modify it, and send it on. Strictly speaking this is > outside the scope of this draft, but it seems a heck of a thing to just > assume, since it is an important prerequisite for this particular use case. > > Manav, you're on draft-davari-tictoc-1588overmpls as well as this draft. > Do you anticipate that a HSMP LSP would use methods from that draft to > distribute timing? If the methods in draft-davari-tictoc-1588overmpls were > not standardized, would the HSMP draft still be able to solve the timing > distribution use case? > > > - The draft's approach merges the return traffic from the leaves. Using > Figure 1 (p. 5) as an example, node B will assign the same UPSTREAM_LABEL > for all flows from all leaves. This means we can't use this approach for > MPLS-TP. It seems that the problems identified in this draft would be > relevant to those who want to use a TP-style approach for their LSPs. I > know this is not an MPLS-TP draft, but it would be nice to solve the > p2mp+return problem once for both traditional TE and for TP. It would be > nice to have a way for an upstream node to give out different upstream > labels per downstream hop. I realize this increases the ILM requirements > on the HSMP headend, but I fear that without this ability we'll have to > solve the problem twice. > > > - The example on p. 11 is hard to follow. At step 2, it looks like PE1 > builds a p2p LSP to PE3 which is then converted to a p2mp LSP? If the > intent is to build a p2mp LSP to PE3, it should probably say something like > "PE1 signals a P2MP LSP with PE3 as the only leaf" or something. > > > > > eric > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf307c9eaa6cf40204d33bffa4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

We have posted an updated ver= sion of=A0draft-jjb-mpls-rsvp-te-hsmp-lsp which we hope addresses some of t= he questions raised by the MPLS-RT reviewers team earlier.
=

Cheers, Manav


On Mon, Jul 1= 6, 2012 at 9:19 PM, Eric Osborne (eosborne) <eosborne@cisco.com>= wrote:
Overall, I think this is a solid draft. =A0I= t presents a pair of problems and the solution to those problems. =A0I'= d like to see some input from the larger community as to whether the two pr= oblems the draft presents as prevalent in operational networks. =A0I'm = also curious whether there are any other uses cases that may take advantage= of HSMP. =A0Is there an analog in non-TE mcast that could be addressed wit= h HSMP?

Assuming the use cases are valid, I can see it eventually being adopted as = a WG document.

I have a few comments:

- Section 1.1 talks about time synchronization. =A0I'm not a timing exp= ert, so I'm just going off of what I can infer from the document. =A0Th= e text

"This is possible because of the link delay calculation performed loca= lly by each node, which enables it to calculate the propagation delay over = the path. =A0This scenario permits that the same PTP Sync messages would be= sent by the PTP master to all the PTP slaves"

implies that each hop in an LSP used for timing distribution would need to = examine the packet, modify it, and send it on. =A0Strictly speaking this is= outside the scope of this draft, but it seems a heck of a thing to just as= sume, since it is an important prerequisite for this particular use case.
Manav, you're on draft-davari-tictoc-1588overmpls as well as this draft= . =A0Do you anticipate that a HSMP LSP would use methods from that draft to= distribute timing? =A0If the methods in draft-davari-tictoc-1588overmpls w= ere not standardized, would the HSMP draft still be able to solve the timin= g distribution use case?


- =A0The draft's approach merges the return traffic from the leaves. = =A0Using Figure 1 (p. 5) as an example, node B will assign the same UPSTREA= M_LABEL for all flows from all leaves. =A0This means we can't use this = approach for MPLS-TP. =A0It seems that the problems identified in this draf= t would be relevant to those who want to use a TP-style approach for their = LSPs. =A0I know this is not an MPLS-TP draft, but it would be nice to solve= the p2mp+return problem once for both traditional TE and for TP. =A0It wou= ld be nice to have a way for an upstream node to give out different upstrea= m labels per downstream hop. =A0I realize this increases the ILM requiremen= ts on the HSMP headend, but I fear that without this ability we'll have= to solve the problem twice.


- The example on p. 11 is hard to follow. =A0At step 2, it looks like PE1 b= uilds a p2p LSP to PE3 which is then converted to a p2mp LSP? =A0If the int= ent is to build a p2mp LSP to PE3, it should probably say something like &q= uot;PE1 signals a P2MP LSP with PE3 as the only leaf" or something.



eric

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

--20cf307c9eaa6cf40204d33bffa4-- From loa@pi.nu Mon Jan 14 02:40:48 2013 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 716BB21F892E for ; Mon, 14 Jan 2013 02:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 GBdo6Drv2NSl for ; Mon, 14 Jan 2013 02:40:48 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id DE2FB21F892D for ; Mon, 14 Jan 2013 02:40:47 -0800 (PST) Received: from pi.nu (localhost [127.0.0.1]) by mail.pi.nu (Postfix) with ESMTP id 5C8D6823B5; Mon, 14 Jan 2013 11:40:44 +0100 (CET) Received: from 194.237.142.6 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Mon, 14 Jan 2013 11:40:44 +0100 Message-ID: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> Date: Mon, 14 Jan 2013 11:40:44 +0100 From: loa@pi.nu To: mpls@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: [mpls] working group last call 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, 14 Jan 2013 10:40:48 -0000 Working Group, this is to start a two week Working Group last call on draft-ietf-mpls-tp-use-cases-and-design. This is the second time we working group last call this draft, it has been updated after comments during the ADE-review. The changes are such that we have decided to do a full two week wglc. 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. There are no IPR claims against this draft. All the co-authors has stated that they are not aware of any IPRs. This working group last call will end on January 25, 2013. /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 mn1921@att.com Mon Jan 14 07:42:03 2013 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 D075D21F8930 for ; Mon, 14 Jan 2013 07:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 0AZrk1iJeb6P for ; Mon, 14 Jan 2013 07:42:03 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD4221F88E6 for ; Mon, 14 Jan 2013 07:42:02 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 94724f05.0.247421.00-414.669593.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 14 Jan 2013 15:42:03 +0000 (UTC) X-MXL-Hash: 50f4274b7027ab22-beb6c7490bd3173f06cbb989315cb5e7d66eafc8 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0EFg0Lg018308; Mon, 14 Jan 2013 10:42:01 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0EFfqn5018137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 10:41:54 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint02.pst.cso.att.com (RSA Interceptor); Mon, 14 Jan 2013 10:41:45 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0318.001; Mon, 14 Jan 2013 10:41:45 -0500 From: "NAPIERALA, MARIA H" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AQHN7MDbTyhQuEctAkSRZuQomt3B95hJAZxw Date: Mon, 14 Jan 2013 15:41:43 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E010F987F@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <50EAA1C5.20009@pi.nu> In-Reply-To: <50EAA1C5.20009@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Z/Vb6gtA c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=WWNmkhODUH4A:10 a=tw2J3tO_OXAA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=TfbPuJ_W-d8A:10 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8] X-AnalysisOut: [ a=ZGcprn9XnkydsD_q1WEA:9 a=CjuIK1q_8ugA:10 a=zSNQObAR6s4A] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=f7GxY0FH8QIA:10 a=WrwN4x_zsp48PUqu] X-AnalysisOut: [:21 a=FEMeu9X7ed1pe723:21] Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 14 Jan 2013 15:42:03 -0000 Support. Maria > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Monday, January 07, 2013 5:22 AM > To: mpls@ietf.org > Cc: draft-ietf-mpls-tp-security-framework@tools.ietf.org; mpls- > chairs@tools.ietf.org > Subject: [mpls] 2nd wg last call on draft-ietf-mpls-tp-security- > framework >=20 > Working Group, >=20 > This is to start a working group last call on > draft-ietf-mpls-tp-security-framework-06. >=20 > This is the second time this document is working group last called, > three has been a major update of the document since last time. >=20 > Please find a diff: > http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-tp-security-framework- > 05&difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-security- > framework-06 >=20 > Please send your comments to the mpls working group mailing > list (mpls@ietf.org). >=20 > Please send both technical comments, and if you are happy with the > document as is also indications of support. >=20 > There are no IPR claims against this draft. >=20 > All the co-authors has stated that they are not ware of any IPRs. >=20 > This working group last call will end on January 18, 2013. >=20 > /Loa > for the wg co-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 From jcucchiara@mindspring.com Mon Jan 14 08:29:34 2013 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 B3A1221F86BA for ; Mon, 14 Jan 2013 08:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 dryNZLSwVwaV for ; Mon, 14 Jan 2013 08:29:34 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4B721F8550 for ; Mon, 14 Jan 2013 08:29:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Wvt606H6une/z1f53lZJPzgXnZYuUu7bVI0oDKrVqFXCs147NBUkXrkI3k9F/Q4F; 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-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Tumuh-0006jK-N1; Mon, 14 Jan 2013 11:29:31 -0500 Message-ID: <00a401cdf274$544d1b80$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Loa Andersson" , , , "Venkatesan Mahalingam" , , , References: <50C7C556.8050804@pi.nu> <00ca01cdd88c$bfb3dff0$6801a8c0@JoanPC> <50C8C86A.5060309@pi.nu> Date: Mon, 14 Jan 2013 11:29:30 -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: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654b47931811046004c60dbe1854acdb4ca3396037c9e1b016b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: mpls-chairs@tools.ietf.org, draft-smiler-mpls-tp-linear-protection-mib-02@tools.ietf.org, "Bert \(IETF\) Wijnen" Subject: [mpls] MPLS-RT review of draft-smiler-mpls-tp-linear-protection-mib-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: Mon, 14 Jan 2013 16:29:34 -0000 Loa, My review of draft-smiler-mpls-tp-linear-protection-mib-02 for the MPLS Review Team is detailed inline below. Thanks, -Joan >>>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? Yes, the document is coherent. Ideally the MIB Module could be organized slightly differently and have more consistent naming as outlined in the MIB guidelines (rfc4181) and some comments have been included at the end of this email wrt to that. It is likely to be useful in operational networks since it allows for configuration and monitoring of MPLS TP Linear Protection Switching using SNMPv3. The document is technically sound from a MIB perspective. >>> 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). >>> Yes, I think this draft should be considered for WG adoption and is 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. >>> During the reading of this document, there were a few comments which I've included here: * Section 6.1 Should discuss that mplsLpsMeConfigTable is "sparsely augmented" by mplsOamIdMeTable, when the LER supports MPLS TP Linear protection. * Needs REFERENCES throughout the MIB Module. * Naming of MIB and Tables is inconsistent. MIB name: MPLS-TP-LPS-MIB vs. Table prefix (mplsLps...) -- The MIB guidelines (rfc4181) suggest that these be consistent, so either use MPLS-LPS-MIB and "mplsLsp..." prefix OR MPLS-TP-LPS-MIB and use "mplsTpLps..." as a prefix. * Term: traps appears in a MIB Module comment, please use Notifications. Traps is an SNMPv1 construct. * mplsLspConfigGroupIndex (indexes should start at 1, unless there is a good reason not to start at 1) * MIB ordering is not ideal ------------------------------ 1) Typically, a Config Table is followed by its Status Table, and I think that was intended based on the discussion prior to the actual MIB, and also comments within the MIB Module, but that was not done. This will effect the overall MIB OIDs, so changing it sooner rather than later, would be better. 2) Additionally, it is convention that RowStatus and StorageType objects appear together at the end of a table, and this is not done. 3) Ordering of Compliance and Group is NOT as suggested by RFC4181. xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) mplsLpsConformance OBJECT IDENTIFIER ::= { mplsLpsMIB 2 } mplsLpsGroups OBJECT IDENTIFIER ::= { mplsLpsConformance 1 } mplsLpsCompliances OBJECT IDENTIFIER ::= { mplsLpsConformance 2 } ---- From eric.gray@ericsson.com Mon Jan 14 11:57:21 2013 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 73BF721F8B0C for ; Mon, 14 Jan 2013 11:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 WcEIplcpORKN for ; Mon, 14 Jan 2013 11:57:21 -0800 (PST) Received: from usevmg20.ericsson.net (unknown [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id BB5A521F8B08 for ; Mon, 14 Jan 2013 11:57:20 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-4e-50f4631e8b36 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F8.03.31450.E1364F05; Mon, 14 Jan 2013 20:57:19 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 14:57:11 -0500 From: Eric Gray To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg document Thread-Index: AQHN6e7D7xrI2jC7W0Cii6Dles4vIphJTsfg Date: Mon, 14 Jan 2013 19:57:10 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60590BC@eusaamb107.ericsson.se> References: <50E5E64A.8090105@pi.nu> In-Reply-To: <50E5E64A.8090105@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPrK588pcAgwlf2SymLtzBbvFv7hxm i++XlrBY3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoErY3V3H1vBEe6K 3Y0HmBoY33N0MXJySAiYSJw5uoEJwhaTuHBvPVsXIxeHkMARRonXexsYIZzljBL3vuxiB6li E9CQOHZnLSOILSJgJ7Hx1T+wImaBZYwSp379ZANJCAtUSOyato8JoqhSYvGNDVANRhLLJk1k AbFZBFQlJnzaAxbnFfCWWPGrBaxeSEBF4uujTmYQmxOoZmLzNrB6RqDzvp9aA1bDLCAucevJ fKizBSSW7DnPDGGLSrx8/I8VwlaW+D7nEQtEvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEax WUjGzkLSMgtJyywkLQsYWVYxcpQWp5blphsZbGIExtExCTbdHYx7XloeYpTmYFES5w1yvRAg JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTG769wk990Cn6uSjy6SEt+hsOStEx97+yHOBZ72 h73mabDo/FLdMDFnioa64DorntMnT+jN2lnoNl8o6/Dhy2ousz9f3XZBgG3tRkb9VObY3w3r L6w2VOPzV02RipJ/pFn0RNPz58f82aeSJFJqWZ50Zln2CPbdmXBn562IF83SqzZKxum1yiqx FGckGmoxFxUnAgA2eRTQcQIAAA== Cc: "mpls-chairs@tools.ietf.org" , "draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg 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: Mon, 14 Jan 2013 19:57:21 -0000 Support. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, January 03, 2013 3:13 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-fbb-mpls-tp-p2mp-framework@tools.ietf= .org Subject: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2= mp-framework-06.txt an MPLS wg document Working group, This is to start a two week poll on adopting draft-fbb-mpls-tp-p2mp-framework-06 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 January 17, 2013. There are no IPR claim against this document. All the active co-authors has stated on the working group mailing list that= they are not aware of any other IPR claims than those already disclosed. /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 wwwrun@rfc-editor.org Mon Jan 14 17:33:59 2013 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 B2B5821F8B4C; Mon, 14 Jan 2013 17:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.158 X-Spam-Level: X-Spam-Status: No, score=-102.158 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 Xi3InStcvrNX; Mon, 14 Jan 2013 17:33:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0321F8472; Mon, 14 Jan 2013 17:33:59 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CCF3AB1E004; Mon, 14 Jan 2013 17:23:16 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130115012316.CCF3AB1E004@rfc-editor.org> Date: Mon, 14 Jan 2013 17:23:16 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6826 on Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths 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, 15 Jan 2013 01:33:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6826 Title: Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Author: IJ. Wijnands, Ed., T. Eckert, N. Leymann, M. Napierala Status: Standards Track Stream: IETF Date: January 2013 Mailbox: ice@cisco.com, eckert@cisco.com, n.leymann@telekom.de, mnapierala@att.com Pages: 12 Characters: 23927 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-mldp-in-band-signaling-08.txt URL: http://www.rfc-editor.org/rfc/rfc6826.txt Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), that 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 regarding how IP multicast trees are spliced together with multipoint LSPs. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From gregory.mirsky@ericsson.com Mon Jan 14 18:35:41 2013 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 84BB511E80A2 for ; Mon, 14 Jan 2013 18:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 Zmd4VegVhE4k for ; Mon, 14 Jan 2013 18:35:40 -0800 (PST) Received: from usevmg21.ericsson.net (unknown [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 644F211E80A5 for ; Mon, 14 Jan 2013 18:35:40 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-c0-50f4c07bbe37 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id EB.44.03705.B70C4F05; Tue, 15 Jan 2013 03:35:39 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 21:35:38 -0500 From: Gregory Mirsky To: "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg document Thread-Index: AQHN6e7D/IbBd7ar9Uu2/4Nldm1tYphJLbvA Date: Tue, 15 Jan 2013 02:35:38 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11204DA19@eusaamb103.ericsson.se> References: <50E5E64A.8090105@pi.nu> In-Reply-To: <50E5E64A.8090105@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11204DA19eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPrG71gS8BBq/n6llMXbiD3eL7pSUs FreWrmR1YPZYsuQnk8eXy5/ZApiiuGxSUnMyy1KL9O0SuDIW/5zHXDBfv2Li5S3sDYyrNboY OTkkBEwkfvSvYIewxSQu3FvP1sXIxSEkcIRRYvbjr4wQznJGibUT37KAVLEJGEm82NgD1iEi oCxxZGI3K0gRs8AyRolTv36ygSSEBSokdk3bxwRRVCmx+MYGRgjbSOLejt/MIDaLgKrE2sm7 gYZycPAKeEtc/RwOEhYSUJH4+qgTrIQTqGRi8zawvYxA130/tQZsJLOAuMStJ/OZIK4WkFiy 5zwzhC0q8fLxP1YIW1ni+5xHLBD1+RIz/+4BO41XQFDi5MwnLBMYRWchGTULSdksJGUQcR2J Bbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSNHaXFqWW66keEmRmCEHZNgc9zBuOCT5SFGaQ4W JXHeUNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYJzK9OdS74/vL7pn1X+cvN2hp7WkI u3046HKRonXc2pv3Mz4GLvt7VDIq5eS7pWesJE0PPvu/9a/1kz910VuCleZ/vfcu1siZTayo al7H7KathrOqBDrLbEO+Gixdbu1wQpE7IXeve5GKRfcX37VT6tKM3hTN3n7QsSlYQ/fpulXT PjZpPgwJUWIpzkg01GIuKk4EAASNeU5+AgAA Cc: "mpls-chairs@tools.ietf.org" , "draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg 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, 15 Jan 2013 02:35:41 -0000 --_000_7347100B5761DC41A166AC17F22DF11204DA19eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, support As a note/suggestion. * I think that the first paragraph of the Section 6 Survivability mig= ht be interpreted as in 1:1 protection extra traffic on protection path is = not allowed. AFAIK, in 1:1 protection traffic not being sent on protection = paths before the defect detected and the root been informed to shift traffi= c onto the protection path. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, January 03, 2013 12:13 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-fbb-mpls-tp-p2mp-framework@tools.ietf= .org Subject: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2= mp-framework-06.txt an MPLS wg document Working group, This is to start a two week poll on adopting draft-fbb-mpls-tp-p2mp-framework-06 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 January 17, 2013. There are no IPR claim against this document. All the active co-authors has stated on the working group mailing list that= they are not aware of any other IPR claims than those already disclosed. /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 --_000_7347100B5761DC41A166AC17F22DF11204DA19eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear All,
support
 
As a note/suggestion.
  • I think that the first paragraph of the Section 6 Survivability might b= e interpreted as in 1:1 protection extra traffic on protection path is not = allowed. AFAIK, in 1:1 protection traffic not being sent on protection path= s before the defect detected and the root been informed to shift traffic onto the protection path.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: mpls-bounces@ietf.org [= mailto:mpls-bounces@ietf.org] On Beh= alf Of Loa Andersson
Sent: Thursday, January 03, 2013 12:13 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org; draft-fbb-mpls-tp-p2mp-framework@tools= .ietf.org
Subject: [mpls] poll to see if we have support to make draft-fbb-mpls-= tp-p2mp-framework-06.txt an MPLS wg document
 
Working group,
 
This is to start a two week poll on adopting
draft-fbb-mpls-tp-p2mp-framework-06 as an MPLS working group document.=
 
Please send your comments (support/not support) to the mpls working gr= oup mailing list (mpls at ietf.org). Please give an technical motivation fo= r your support/not support, especially if you think that the document shoul= d not be adopted as a working group document.
 
This poll ends January 17, 2013.
 
There are no IPR claim against this document.
 
All the active co-authors has stated on the working group mailing list= that they are not aware of any other IPR claims than those already disclos= ed.
 
/Loa
(mpls wg co-chair)
 
--
 
 
Loa Andersson         &nb= sp;            =    email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager      &= nbsp;     loa@pi.nu
Ericsson Inc         &nbs= p;            &= nbsp;   phone: +46 10 717 52 13
           &nbs= p;            &= nbsp;           &nbs= p;         +46 767 72 92 13 ___= ____________________________________________
mpls mailing list
mpls@ietf.org
 
 --_000_7347100B5761DC41A166AC17F22DF11204DA19eusaamb103ericsso_-- From internet-drafts@ietf.org Tue Jan 15 03:18:42 2013 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 6C19821F87ED; Tue, 15 Jan 2013 03:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 L+7WrJNFirSD; Tue, 15 Jan 2013 03:18:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02BF21F87C5; Tue, 15 Jan 2013 03:18:41 -0800 (PST) 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.37 Message-ID: <20130115111841.15315.19009.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 03:18:41 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-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: Tue, 15 Jan 2013 11:18:42 -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 : A Thesaurus for the Terminology used in Multiprotocol La= bel Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport= Network Recommendations. Author(s) : Huub van Helvoort Loa Andersson Nurit Sprecher Filename : draft-ietf-mpls-tp-rosetta-stone-07.txt Pages : 18 Date : 2013-01-15 Abstract: MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-rosetta-stone-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-rosetta-stone-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From huubatwork@gmail.com Tue Jan 15 03:29:21 2013 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 E8EE721F888C for ; Tue, 15 Jan 2013 03:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 fEssPAkt+vjE for ; Tue, 15 Jan 2013 03:29:21 -0800 (PST) Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id 325F621F8873 for ; Tue, 15 Jan 2013 03:29:21 -0800 (PST) Received: by mail-ea0-f169.google.com with SMTP id d13so911778eaa.14 for ; Tue, 15 Jan 2013 03:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:disposition-notification-to:date:from :reply-to:user-agent:mime-version:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=hnxDWyWWpsLAM+dXxkPJ81QYBNkDGFjAj/twOKUaR3M=; b=ibINOg2UZ1Vh1MeRVQse8twwULY3Ol3xmkCysz1vfPqrE4lxXg+rJC+DMx4fiJVsYQ qlCYQwh1yKLEAo5MFSRAWy4VzEi1wSHdzSxSv6LUTDMG9/583HIpaUxDUoF03sj+DqQu TruRWzs54RZWyf6Wh5dUz4ffM0EhY/3PvBn/mRQjEH0F5cnYW5+7wcGRfr2tzpvHlBAn AifItNZVsKpyqjC5YL6hGsiOgeX8NIMBwctcJ8OKfojR96mYjemhg8FHi//c2XWNN4ke qrLXCvdc54l4gD3lyVrjQaaGizJLrYJlfRI2uGBJytcImoNpkDXEoIKwnD6MKTNcDoQO gEjQ== X-Received: by 10.14.174.132 with SMTP id x4mr237269223eel.39.1358249360380; Tue, 15 Jan 2013 03:29:20 -0800 (PST) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl. [77.250.51.60]) by mx.google.com with ESMTPS id w44sm25196966eep.6.2013.01.15.03.29.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 03:29:19 -0800 (PST) Message-ID: <50F53D8E.3040204@gmail.com> Date: Tue, 15 Jan 2013 12:29:18 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 CC: mpls@ietf.org References: <20130115111841.15315.19009.idtracker@ietfa.amsl.com> In-Reply-To: <20130115111841.15315.19009.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-07.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: Tue, 15 Jan 2013 11:29:22 -0000 All, This is an updated version of In IETF85 (Atlanta) it was suggested by the WG chair to wait for draft mpls-tp-p2mp-framework before finalising. This draft is currently polled for WG adoption and I did find no terminology that should be added to the rosetta draft. I think draft-ietf-mpls-tp-rosetta-stone is ready for WG last call. Regards, Huub. > 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 : A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations. > Author(s) : Huub van Helvoort > Loa Andersson > Nurit Sprecher > Filename : draft-ietf-mpls-tp-rosetta-stone-07.txt > Pages : 18 > Date : 2013-01-15 > > Abstract: > MPLS-TP is based on a profile of the MPLS and PW procedures as > specified in the MPLS-TE and (MS-)PW architectures developed by the > IETF. The ITU-T has specified a Transport Network architecture. > > This document provides a thesaurus for the interpretation of MPLS-TP > terminology within the context of the ITU-T Transport Network > recommendations. > > It is important to note that MPLS-TP is applicable in a wider set of > contexts than just Transport Networks. The definitions presented in > this document do not provide exclusive nor complete interpretations > of MPLS-TP concepts. This document simply allows the MPLS-TP terms > to be applied within the Transport Network context. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-tp-rosetta-stone-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-rosetta-stone-07 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jan 15 04:41:43 2013 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 936B521F888C; Tue, 15 Jan 2013 04:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 noC4iemg82fG; Tue, 15 Jan 2013 04:41:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C9D21F8800; Tue, 15 Jan 2013 04:41:43 -0800 (PST) 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.37 Message-ID: <20130115124143.12114.44371.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 04:41:43 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-08.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, 15 Jan 2013 12:41:43 -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 : A Thesaurus for the Terminology used in Multiprotocol La= bel Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport= Network Recommendations. Author(s) : Huub van Helvoort Loa Andersson Nurit Sprecher Filename : draft-ietf-mpls-tp-rosetta-stone-08.txt Pages : 18 Date : 2013-01-15 Abstract: MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-rosetta-stone-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-rosetta-stone-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From huubatwork@gmail.com Tue Jan 15 04:54:16 2013 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 DFE0021F885E for ; Tue, 15 Jan 2013 04:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 cmB2Q-0qekI3 for ; Tue, 15 Jan 2013 04:54:16 -0800 (PST) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2470521F8846 for ; Tue, 15 Jan 2013 04:54:15 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id d4so30305eek.22 for ; Tue, 15 Jan 2013 04:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:disposition-notification-to:date:from :reply-to:user-agent:mime-version:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0rpaDzlmnw2KUnsMmwMgTm/pORd57259OwLSEdsFSu8=; b=jPJ/4tW1SswUQ70OipxP+it5hj8vnJRwSqvizmPrqrbfIKVsE9NqTZfzfsmdwNKWa7 HkfefDn7U88K+8+LdRwPCYdi2y6U3LdqVvIbqtr9mZdVlsU2tFVD3f5eRM4yluQirdq3 yexvSO09RqR6XFWMXPn2xT22OHRyswef75T+Ecl5lNWBrNmyoU6ImIUREqX7JazH8LEF j7eRLehcp94lBzAc06qocNNhOgez0Aas/puvP6sy7q7n8TFLL89sWBqIcx7XsSV6cvzt HcoktW6QHpfhUAr/4VGoo52jjV3OFlIH1FMLJlDfYp5vqoDQ36Sx+YIjFmjyotzdxQ9R GI4A== X-Received: by 10.14.216.70 with SMTP id f46mr241879383eep.12.1358254455328; Tue, 15 Jan 2013 04:54:15 -0800 (PST) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl. [77.250.51.60]) by mx.google.com with ESMTPS id l3sm14559473een.14.2013.01.15.04.54.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 04:54:14 -0800 (PST) Message-ID: <50F55175.5080106@gmail.com> Date: Tue, 15 Jan 2013 13:54:13 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 CC: mpls@ietf.org References: <20130115124143.12114.44371.idtracker@ietfa.amsl.com> In-Reply-To: <20130115124143.12114.44371.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-08.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: Tue, 15 Jan 2013 12:54:17 -0000 Sorry, I had to re-spin. MS messed up the references. Regards, Huub. > > 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 : A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations. > Author(s) : Huub van Helvoort > Loa Andersson > Nurit Sprecher > Filename : draft-ietf-mpls-tp-rosetta-stone-08.txt > Pages : 18 > Date : 2013-01-15 > > Abstract: > MPLS-TP is based on a profile of the MPLS and PW procedures as > specified in the MPLS-TE and (MS-)PW architectures developed by the > IETF. The ITU-T has specified a Transport Network architecture. > > This document provides a thesaurus for the interpretation of MPLS-TP > terminology within the context of the ITU-T Transport Network > recommendations. > > It is important to note that MPLS-TP is applicable in a wider set of > contexts than just Transport Networks. The definitions presented in > this document do not provide exclusive nor complete interpretations > of MPLS-TP concepts. This document simply allows the MPLS-TP terms > to be applied within the Transport Network context. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-tp-rosetta-stone-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-rosetta-stone-08 > > > 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 eosborne@cisco.com Tue Jan 15 08:03:52 2013 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 1C69A21F871C for ; Tue, 15 Jan 2013 08:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-3.900, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_57=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_74=0.6, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, 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 Ls79UrQRmYKI for ; Tue, 15 Jan 2013 08:03:47 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8824521F8715 for ; Tue, 15 Jan 2013 08:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22432; q=dns/txt; s=iport; t=1358265827; x=1359475427; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XG1+410IX9T6bo3sMwlhMXqfpIySWti6O8C/yVTyfi4=; b=URdrbidAoQ3z/cqIdbBaIMZ4GSIMRAm88UU6bMPc9B0JLnEeGOK3o5TQ k17y0x6CH4w0O8dGaMysQmav9tC6GO0ctCnB5iGi8bBdXA1Gv9PpwTp9n jqnEgMoxgaAijXLiPle9RttcXUPZRyNiTW/3yeJyDp35FqItUxpbJGH77 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAP589VCtJV2b/2dsb2JhbABFhjqkV48qgkl/FnOCHgEBAQMBAQEBIAQNOgsFBwQCAQYCEQIBAQEBAQICBhkEAwICAh8GCxQBCAgCBAEJBAUIh38DCQYMiz+ad4JAhm4DCoc7gSOKZYQdMmEDlDYBgnGKG4USgnWBZgcdGg X-IronPort-AV: E=Sophos;i="4.84,473,1355097600"; d="scan'208";a="162628555" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 15 Jan 2013 16:03:46 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0FG3kMf021678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jan 2013 16:03:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 10:03:46 -0600 From: "Eric Osborne (eosborne)" To: =?utf-8?B?5pu+5bO75rOi?= , "wyaacov@gmail.com" Thread-Topic: [mpls] in some scenario RFC6378 can not protect the traffic, so much as take the PSC state to crash. Thread-Index: AQHN71WmKVcaywHJ3UaDzYpcjZCtLJhD0O4AgADHSLCABiruAP//0U2g Date: Tue, 15 Jan 2013 16:03:45 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572100A1383@xmb-rcd-x09.cisco.com> References: , , , , <20ECF67871905846A80F77F8F4A275721009D49F@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] in some scenario RFC6378 can not protect the traffic, so much as take the PSC state to crash. 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, 15 Jan 2013 16:03:53 -0000 SW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IOabvuWzu+az oiBbbWFpbHRvOnpqYmRhbW9AaG90bWFpbC5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkg MTUsIDIwMTMgNzo0OCBBTQ0KPiBUbzogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IHd5YWFjb3ZA Z21haWwuY29tDQo+IENjOiBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10gaW4g c29tZSBzY2VuYXJpbyBSRkM2Mzc4IGNhbiBub3QgcHJvdGVjdCB0aGUgdHJhZmZpYywgc28NCj4g bXVjaCBhcyB0YWtlIHRoZSBQU0Mgc3RhdGUgdG8gY3Jhc2guDQo+IA0KPiANCj4gaGksDQo+IG9m IGNhdXNlLGlmIHRoZSBQU0Mgc3RhdGUgcmVldmFsdWF0ZSBhbGwgaW5wdXRzIHdoZW4gYW55IG9m IGl0IGhhcyBjaGFuZ2UsdGhlIFBTQw0KPiB3aWxsIHdvcmsgcGVyZmVjdGx5LmJ1dCB0aGVyZSBu byBzdWNoIGRpc2NyaXB0aW9uIGluIFJGQzYzNzguYW5kIGluIFJGQzYzNzgNCj4gbGFuZ3VhZ2Ug dGhlIE5SIHN0YXRlIGlzIG5vdCBjbGVhciBhbmQgYW1iaWd1aXR5LnRoZSAiVEVNUE9SQVJZIE5P Uk1BTA0KPiBTVEFURSIgaXMgb25seSBhIHN1Z2dlc3Rpb24gdG8gaGVscCB0byBtYWtlIHRoZSBQ U0Mgc3RhdGUgbW9yZSBpbnRlZ3JpdHkgaW4gaXQncw0KPiBsYW5ndWFnZS4gdGhlIHNlY3Rpb25z IG9mIFJGQzYzNzggZnJvbSA0LjMuMy4xIHRvIHRoZSBlbmQgZG9zZSBub3QgbWFrZSB0aGUNCj4g UFNDIHN0YXRlIGNsZWFyIGJ1dCBtYWtlIGl0IGNvbmZ1c2VkLiBpZiBSRkM2Mzc4IGNhbiBjbGFy aWZ5IHRoZSBiYXNpYyBvcGVyYXRpb24NCj4gb2YgUFNDIHN0YXRlLS0tInRoZSBQU0Mgc3RhdGUg cmVldmFsdWF0ZSBhbGwgaW5wdXRzIHdoZW4gYW55IG9mIGl0IGhhcw0KPiBjaGFuZ2UiLHRoZW4g YWJzZW50IG9mIHRoZSBzZWN0aW9ucyBvZiBSRkM2Mzc4IGZyb20gNC4zLjMuMSB3aWxsIG9rLg0K DQpBcyBJIHNhaWQgYmVmb3JlLCBJIGhhdmUgc29tZSB0ZXh0IHRoYXQgc2hvdWxkIGFkZHJlc3Mg dGhpcy4gIFdlIHJlY29nbml6ZSB0aGF0IHRoZSB3YXkgaXQncyBjdXJyZW50bHkgd3JpdHRlbiBp cyBjb25mdXNpbmcuICBJIGhvcGUgdG8gaGF2ZSB0ZXh0IGluIHRpbWUgZm9yIHRoZSBPcmxhbmRv IG1lZXRpbmcsIGFuZCB3aWxsIGdldCBiYWNrIHRvIHRoaXMgdGhyZWFkIHdpdGggYSBwb2ludGVy IHRvIHRoZSBkcmFmdC4NCg0KPiANCj4gaSBoYXZlIGEgYW5vdGhlciBzdWdnZXN0aW9uLHRoZSBM RVIgd2lsbCBuZXZlciBzZW5kIE5SIGFzIGEgcmVhY3Rpb24gdG8gaXRzDQo+IHBlZXIsYnV0IGFs d2F5cyBzZW5kIGhpcyBsb2NhbCBoaWdoZXN0IHByaXJvcml0eSBjb25kaXRpb24gd2l0aCB0aGUg Y29vcmRpbmF0ZWVkDQo+IFBBVEggaW5mbyB0byBpdCBwZWVyLnRoaXMgd2lsbCBtYWtlIHRoZSBQ U0Mgc3RhdGUgbW9yZSBzaW1wbGUuYmVjYXVzZSB0aGUgUFNDDQo+IHN0YXRlIGlzIHNpbmdsZS1w aGFzZSBwcm90ZWN0aW9uLGV4Y2VwdCBmb3IgdGhlIFBBVEggaW5mbyx0aGVyZSBpcyBub3RoaW5n IGluZm8NCj4gbmVlZCB0byBiZSBjb29yZGluYXRlZWQuDQoNCk90aGVyIHRoYW4gbWFraW5nIHRo aW5ncyAnc2ltcGxlcicsIGRvZXMgdGhpcyBhY3R1YWxseSBmaXggYW55IGJ1ZyBpbiBQU0M/DQoN Cg0KDQplcmljDQoNCj4gQlIuDQo+IHplbmdqdW5ibyhib2JvKQ0KPiANCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IEZyb206IGVvc2Jvcm5lQGNpc2NvLmNv bQ0KPiA+IFRvOiB6amJkYW1vQGhvdG1haWwuY29tOyB3eWFhY292QGdtYWlsLmNvbQ0KPiA+IEND OiBtcGxzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFttcGxzXSBpbiBzb21lIHNjZW5hcmlv IFJGQzYzNzggY2FuIG5vdCBwcm90ZWN0IHRoZSB0cmFmZmljLCBzbw0KPiBtdWNoIGFzIHRha2Ug dGhlIFBTQyBzdGF0ZSB0byBjcmFzaC4NCj4gPiBEYXRlOiBGcmksIDExIEphbiAyMDEzIDIwOjQw OjA5ICswMDAwDQo+ID4NCj4gPiBJIGRvbid0IHRoaW5rIHRoZXJlIG5lZWRzIHRvIGJlIGEgdHJh bnNpZW50IHN0YXRlIHN1Y2ggYXMgJ3RlbXBvcmFyeSBub3JtYWwnLiBJZg0KPiBhbiBpbXBsZW1l bnRhdGlvbiBoYXMgbXVsdGlwbGUgaW5wdXRzIChvbmUgbG9jYWwsIG9uZSByZW1vdGUpIGFuZCB0 aGUgaGlnaGVzdC0NCj4gcHJpb3JpdHkgaW5wdXQgZ29lcyBhd2F5LCBpdCBzaG91bGQgbG9vayBh dCB0aGUgcmVtYWluaW5nIGlucHV0IHRvIGRlY2lkZSB3aGF0IHRvDQo+IGRvIGJlZm9yZSBkb2lu ZyBhbnl0aGluZy4gVHJhbnNpdGlvbmluZyBpbnRvIHRlbXBvcmFyeSBub3JtYWwgc2VlbXMgbGlr ZSBhDQo+IG5hw692ZSBpbXBsZW1lbnRhdGlvbi4NCj4gPg0KPiA+IEFzIGZhciBhcyAiIGJ1dCBp IHRoaW5rIGF1dGhvciBvZiBSRkMgc2hhbGwgbWFrZSBzdXJlIHRoZSBzdGFuZGFyZCBpcyBjbGVh ciBhbmQNCj4gbm8gYW1iaWd1aXR5IiwgSSBhZ3JlZS4gV2UndmUgZ290dGVuIHRoaXMgcXVlc3Rp b24gYSBmZXcgdGltZXMgb24gdGhlIGxpc3QgYW5kDQo+IEkndmUgaGFkIGl0IGEgZmV3IG9mZi1s aXN0IGFzIHdlbGwuIEkgd2lsbCB0YWtlIHN0ZXBzIHRvIGNsYXJpZnkgdGhlIGxhbmd1YWdlIGlu DQo+IFJGQzYzNzguIEhvcGVmdWxseSBJJ2xsIGhhdmUgc29tZXRoaW5nIG91dCBpbiB0aW1lIGZv ciBPcmxhbmRvLg0KPiA+DQo+ID4NCj4gPg0KPiA+IGVyaWMNCj4gPg0KPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA/Pz8NCj4gPj4gU2VudDog VGh1cnNkYXksIEphbnVhcnkgMTAsIDIwMTMgOTo0NCBQTQ0KPiA+PiBUbzogd3lhYWNvdkBnbWFp bC5jb20NCj4gPj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHlhYWNvdi53ZWluZ2FydGVuQG5zbi5jb20N Cj4gPj4gU3ViamVjdDogUmU6IFttcGxzXSBpbiBzb21lIHNjZW5hcmlvIFJGQzYzNzggY2FuIG5v dCBwcm90ZWN0IHRoZQ0KPiA+PnRyYWZmaWMsIHNvICBtdWNoIGFzIHRha2UgdGhlIFBTQyBzdGF0 ZSB0byBjcmFzaC4NCj4gPj4oaWYgZmlndXJlMyBpcyBub3QgZGlzcGxheSBub3JtYWxseSxwbGVh c2Ugc2VlIGF0dGFjaCBmaWxlLHRoYW5rcy4pDQo+ID4+DQo+ID4+aGksDQo+ID4+DQo+ID4+MS4g eWVzLGkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgVEVNUE9SQVJZIE5PUk1BTCBTVEFURSBpcyBh bg0KPiBpbXBsZW1lbnRhdGlvbiBpc3N1ZSxidXQgaSB0aGluayBhdXRob3Igb2YgUkZDIHNoYWxs IG1ha2Ugc3VyZSB0aGUgc3RhbmRhcmQgaXMNCj4gY2xlYXIgYW5kIG5vIGFtYmlndWl0eS51c3Vh bGx5LGEgbmV0d29yayBpcyBjb21wb3NlZCBvZiBkaWZmZXJlbnQgZXF1aXBtZW50DQo+IGNvbWUg ZnJvbSBkaWZmZXJlbnQgY29tcGF5LExFUjEgYW5kIExFUjIgd2lsbCBpbnRlcndvcmsgd2l0aCBl YWNoIG90aGVyDQo+IGFjY29yZGluZyBSRkM2Mzc4LiBpZiB0aGVyZSBpcyBhYnNlbmNlIG9mIFRF TVBPUkFSWSBOT1JNQUwgU1RBVEUNCj4gZGVmaW5hdGlvbixteWJlIExFUjEgaW4gVEVNUE9SQVJZ IE5PUk1BTCBTVEFURSBzZW5kIE5SIHRvIGl0cyBwZWVyIGFuZA0KPiBMRVIyIGRvbid0IHNlbmQg TlIgdG8gaXRzIHBlZXIsdGhpcyB3aWxsIG1ha2UgdGhlIFBTQyBzdGF0ZSBjaGFvcy4NCj4gPj4N Cj4gPj4NCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0rICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0rDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAg ICB8IExFUjEgfCAgICAgICAgICAgICAgICAgICAgICAgICB8IExFUjIgfA0KPiA+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLSstLSsgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLSst LSsNCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgTiAgICArLS0tLS0tLS0tLU5SLS0tLS0t LS0tLS0tLS0tLS0tLT58ICBODQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQo+ID4+ICAgICAgdW5pZGlyZWN0aW9uIFNGX1cgcmFpc2UgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS1TRl9XLS0tLS0tLS0tLS0tLS0tLT58DQo+ID4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLU5S LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ID4+ICAgICAgbG9jYWwgRlMgY29tbWFuZCBpbnB1dCAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPj4gICAg ICAgICAgICAgICAgICAgICBQQTpGOkwgICArLS0tLS0tLS0tLS1GUy0tLS0tLS0tLS0tLS0tLS0t LT58DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfFBBOkY6Ug0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8PC0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ID4+ICAg ICAgICAgICBsb2NhbCBjbGVhciBpbnB1dCAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4+ICAgICAgIFRFTVBPUkFSWSBOT1JN QUwgU1RBVEUgKy0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCBODQo+ID4+ICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fGlmIHRoaXMgTlIgcmVhY2gsTEVSMiB3aWxsDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHN3aXRjaCB0cmFmZmljIHRv IHdvcmsgcGF0aCwNCj4gPj4gICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8dGhpcyB3aWxsIGJyb2tlbiB0aGUgdHJhZmZpYy4NCj4g Pj4gICAgICAgICAgICAgICAgICAgICBWICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQo+ID4+ICAgICAgIGZpbmFsIHN0YXRlICBQRjpXOkwgICAgKy0tLS0tLS0tLS1T Rl9XLS0tLS0tLS0tLS0tLS0tLS0+fFBGOldfUg0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxMRVIyIHdpbGwgc3dpdGNo IHRyYWZmaWMgdG8NCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8cHJvdGVjdGlvbiBwYXRoLHRyYWZmaWMgaXMNCj4gPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8cmVzdG9yZWQuDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0t LS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ ID4+ICAgICAgICAgICAgZmlndXJlIDM6bGFjayBvZiBURU1QT1JBUlkgTk9STUFMIFNUQVRFLHRy YWZmaWMgd2lsbCBiZSBicm9rZW4NCj4gYWNjaWRlbnRhbGx5Lg0KPiA+Pg0KPiA+PndoZW4gdGhl IGZsb3cgYXJyaXZlZCBhZCB0aGUgVEVNUE9SQVJZIE5PUk1BTCBTVEFURSxpZiBMRVIxIHNlbmQg TlINCj4gdG8gaXRzIHBlZXIsdGhlbiB0aGUgdHJhZmZpYyBpcyBicm9rZW4gZm9yIGEgd2hpbGUg YWNjaWRlbnRhbGx5LGFuZCByZXN0b3JlIHdoZW4NCj4gdGhlIFNGX1cgcmVhY2ggTEVSMi5zbywg aSB0aGluayB0aGUgVEVNUE9SQVJZIE5PUk1BTCBTVEFURSBzaGFsbCBiZSBhZGQNCj4gdG8gdGhl IFBTQyBzdGF0ZSB0byBtYWtlIHRoZSBzdGF0ZSBtYWNoaW5lIGNsZWFyIGFuZCBubyBhbWJpZ3Vp dHkuDQo+ID4+DQo+ID4+DQo+ID4+Mi5pZiB0aGUgIkNvbnRyYWRpY3RvcnkiIG1lYW5zIGFueSBt ZXNzYWdlIHRoYXQgaW1wbGllcyBhIGRpZmZlcmVudA0KPiA+PnJlbW90ZSBzdGF0ZSx0aGlzIGlz IGFncmVlIHdpdGggbXkgc3VnZ2VzdGlvbiAyOkxFUiBhbHdheXMgYWNjZXB0IHRoZSBpbnB1dA0K PiBmcm9tIGhpcyBwZWVyIGJ5IFBTQyBQRFUuYW5kIGFjY29yZGluZyB0aGUgZGVmaW5hdGlvbiBv ZiAiQ29udHJhZGljdG9yeSIsdGhlcmUNCj4gYXJlIHNvbWUgZGVzY3JpcHRpb24gaW4gUkZDNjM3 OCBzaG91bGQgYmUgY29ycmVjdCxmb3IgZXhhbXBsZSBhLmluIDQuMy4zLjIgLS0iQQ0KPiByZW1v dGUgRm9yY2VkIFN3aXRjaCBtZXNzYWdlIFNIQUxMIGJlIGlnbm9yZWQgYnkgdGhlIFBTQyBDb250 cm9sIGxvZ2ljIHdoZW4NCj4gaW4gVW5hdmFpbGFibGUgc3RhdGUgYXMgYSByZXN1bHQgb2YgYSAo bG9jYWwgb3IgcmVtb3RlKSBMb2Nrb3V0IG9mIHByb3RlY3Rpb24uIiAgaWYNCj4gdGhlIEZTIG1l c3NhZ2UgaXMgZGlmZXJyZW50IGZyb20gcHJldmlvdXMgUFNDIG1zZyxpdCBzaG91bGQgYmUgYWNj ZXB0ZWQuDQo+ID4+Yi5pbiB0aGUgQXBwZW5kaXggQS4gUFNDIFN0YXRlIE1hY2hpbmUgVGFibGVz LFBhcnQgMjogUmVtb3RlIG1lc3NhZ2VzDQo+IHN0YXRlIG1hY2hpbmUgLS0gIg0KPiA+PiAgICAg ICAgICAgICAgIHwgTE8gICAgfCBTRi1QIHwgRlMgICB8IFNGLVcgfCBNUyAgIHwgV1RSICB8IERO UiAgfCBOUg0KPiA+PiAgICAgICAtLS0tLS0tLSstLS0tLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0t Ky0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLQ0KPiA+PiAgICAgICBOICAgICAgIHxVQTpMTzpS fFVBOlA6UnxQQTpGOlJ8UEY6VzpSfFBBOk06UnwgaSAgICB8IGkgICAgfCBpDQo+ID4+ICAgICAg IFVBOkxPOkwgfCBpICAgICB8IGkgICAgfCBpICAgIHwgaSAgICB8IGkgICAgfCBpICAgIHwgaSAg ICB8IGkNCj4gPj4gICAgICAgVUE6UDpMICB8IFsxMF0gIHwgaSAgICB8IFsxOV0gfCBpICAgIHwg aSAgICB8IGkgICAgfCBpICAgIHwgaQ0KPiA+PiAgICAgICBVQTpMTzpSIHwgaSAgICAgfCBpICAg IHwgaSAgICB8IGkgICAgfCBpICAgIHwgaSAgICB8IGkgICAgfCBbMTZdDQo+ID4+ICAgICAgIFVB OlA6UiAgfFVBOkxPOlJ8IGkgICAgfFBBOkY6UnwgaSAgICB8IGkgICAgfCBpICAgIHwgaSAgICB8 IFsxNl0NCj4gPj4gICAgICAgUEY6VzpMICB8IFsxMV0gIHwgWzEyXSB8UEE6RjpSfCBpICAgIHwg aSAgICB8IGkgICAgfCBpICAgIHwgaQ0KPiA+PiAgICAgICBQRjpXOlIgIHxVQTpMTzpSfFVBOlA6 UnxQQTpGOlJ8IGkgICAgfCBpICAgIHwgWzE0XSB8IFsxNV0gfCBODQo+ID4+ICAgICAgIFBBOkY6 TCAgfFVBOkxPOlJ8IGkgICAgfCBpICAgIHwgaSAgICB8IGkgICAgfCBpICAgIHwgaSAgICB8IGkN Cj4gPj4gICAgICAgUEE6TTpMICB8VUE6TE86UnxVQTpQOlJ8UEE6RjpSfCBbMTNdIHwgaSAgICB8 IGkgICAgfCBpICAgIHwgaQ0KPiA+PiAgICAgICBQQTpGOlIgIHxVQTpMTzpSfCBpICAgIHwgaSAg ICB8IGkgICAgfCBpICAgIHwgaSAgICB8IEROUiAgfCBbMTddDQo+ID4+ICAgICAgIFBBOk06UiAg fFVBOkxPOlJ8VUE6UDpSfFBBOkY6UnwgWzEzXSB8IGkgICAgfCBpICAgIHwgRE5SICB8IE4NCj4g Pj4gICAgICAgV1RSICAgICB8VUE6TE86UnxVQTpQOlJ8UEE6RjpSfFBGOlc6UnxQQTpNOlJ8IGkg ICAgfCBpICAgIHwgWzE4XQ0KPiA+PiAgICAgICBETlIgICAgIHxVQTpMTzpSfFVBOlA6UnxQQTpG OlJ8UEY6VzpSfFBBOk06UnwgaSAgICB8IGkgICAgfCBpDQo+ID4+Im1vc3Qgb2YgdGhlIElnbm9y ZSBzaGFsbCBiZSBjaGFuZ2UuDQo+ID4+Yy5zb21lIG90aGVyIHNpbWlsYXIgZGVzY3JpcHRpb24g c2hhbGwgYmUgY29ycmVjdC4NCj4gPj4NCj4gPj4NCj4gPj5CZXN0IFJlZ2FyZHMhDQo+ID4+SnVu Ym8gWmVuZyhCb0JvKQ0KPiA+Pg0KPiA+Pg0KPiA+Pl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+PiBEYXRlOiBGcmksIDExIEphbiAyMDEzIDA2OjE1OjQ4ICswMjAwDQo+ID4+ PiBTdWJqZWN0OiBSRTogW21wbHNdIGluIHNvbWUgc2NlbmFyaW8gUkZDNjM3OCBjYW4gbm90IHBy b3RlY3QgdGhlDQo+ID4+PiB0cmFmZmljLCBzbyBtdWNoIGFzIHRha2UgdGhlIFBTQyBzdGF0ZSB0 byBjcmFzaC4NCj4gPj4+IEZyb206IHd5YWFjb3YgYXQgZ21haWwuY29tDQo+ID4+PiBUbzogempi ZGFtbyBhdCBob3RtYWlsLmNvbQ0KPiA+Pj4gQ0M6IG1wbHMgYXQgaWV0Zi5vcmcNCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4gSGksDQo+ID4+Pg0KPiA+Pj4gMS4gSSBiZWxpZXZlIHRoYXQgdGhpcyBpcyBh biBpbXBsZW1lbnRhdGlvbiBpc3N1ZSwgYW5kIHRoZXJlZm9yZSBvdXQgb2YNCj4gPj4+IHNjb3Bl Lg0KPiA+Pj4gMi4gIkNvbnRyYWRpY3RvcnkiIG1lYW5zIGFueSBtZXNzYWdlIHRoYXQgaW1wbGll cyBhIGRpZmZlcmVudCByZW1vdGUNCj4gc3RhdGUuDQo+ID4+Pg0KPiA+Pj4gSG9wZSB0aGlzIGhl bHBzDQo+ID4+Pg0KPiA+Pj4gQlIsDQo+ID4+PiB5YWFjb3YNCj4gPj4+DQo+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID8/Pw0KPiA+PiBTZW50 OiBUaHVyc2RheSwgSmFudWFyeSAxMCwgMjAxMyA5OjQ0IFBNDQo+ID4+IFRvOiB3eWFhY292QGdt YWlsLmNvbQ0KPiA+PiBDYzogbXBsc0BpZXRmLm9yZzsgeWFhY292LndlaW5nYXJ0ZW5AbnNuLmNv bQ0KPiA+PiBTdWJqZWN0OiBSZTogW21wbHNdIGluIHNvbWUgc2NlbmFyaW8gUkZDNjM3OCBjYW4g bm90IHByb3RlY3QgdGhlIHRyYWZmaWMsIHNvDQo+ID4+IG11Y2ggYXMgdGFrZSB0aGUgUFNDIHN0 YXRlIHRvIGNyYXNoLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiB5YWFjb3YsdGhhbmtzIGZvciB5 b3VyIHBhdGllbnQgZXhwbGFpbi4NCj4gPj4NCj4gPj4gMS4gUmVnYXJkaW5nIFNjZW5hcmlvICMx OmFjY29yZGluZyB0aGUgU2VjdGlvbiA0LjMuMy4xLGkgdGhpbmsgdGhlIHRoZXJlIG5lZWQNCj4g YQ0KPiA+PiBuZXcgc3RhdGUgLS0tVEVNUE9SQVJZIE5PUk1BTCBTVEFURSxqdXN0IGFzIGl0cyBu YW1lIGltcGxpZXMsdGhpcyBzdGF0ZQ0KPiBpcyBhDQo+ID4+IHRlbXBvcmFyeSBzdGF0ZSxhbmQg aW4gdGhpcyBzdGF0ZSBMRVIgc2hhbGwgbmV2ZXIgc2VuZCBOUiBQRFUgdG8gaXRzIHBlZXINCj4g YW5kDQo+ID4+IHdpbGwgY2hlY2sgaXRzIGxvY2FsIHBlcnNpc3RlbnQgc3RhdGUgdG8gZGVzaWRl IHRoZSBmaW5hbCBzdGF0ZSBhbmQgaW5mb3JtIGl0cw0KPiBwZWVyDQo+ID4+IGJ5IFBTQyBQRFUg YWNjb3JkaW5nIHRoaXMgZmluYWwgc3RhdGUuDQo+ID4+DQo+ID4+IDIuUmVnYXJkaW5nIFNjZW5h cmlvICMyOkkgd29uZGVyIGhvdyB0byBkZWZpbmUgImNvbnRyYWRpY3RvcnkiLiBhbnkgY2hhbmdl DQo+IG9mDQo+ID4+IHRoZSBQU0MgUERVIG9yIHRoZSBQYXRoIGlzIG5vdCBzYW1lIHdpdGggcHJl dmlvdXMgUFNDIFBEVSBvciBhbnkgb3RoZXI/DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IEJlc3Qg UmVnYXJkcyENCj4gPj4gSnVuYm8gWmVuZyhCb0JvKQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gRGF0ZTogVGh1LCAxMCBKYW4g MjAxMyAxOToxMjowOCArMDIwMA0KPiA+Pj4gU3ViamVjdDogUmU6IFttcGxzXSBpbiBzb21lIHNj ZW5hcmlvIFJGQzYzNzggY2FuIG5vdCBwcm90ZWN0IHRoZQ0KPiA+Pj4gdHJhZmZpYywgc28gbXVj aCBhcyB0YWtlIHRoZSBQU0Mgc3RhdGUgdG8gY3Jhc2guDQo+ID4+PiBGcm9tOiB3eWFhY292QGdt YWlsLmNvbQ0KPiA+Pj4gVG86IHpqYmRhbW9AaG90bWFpbC5jb20NCj4gPj4+IENDOiBtcGxzQGll dGYub3JnOyB5YWFjb3Yud2VpbmdhcnRlbkBuc24uY29tDQo+ID4+Pg0KPiA+Pj4gSnVuYm8sIGhp DQo+ID4+Pg0KPiA+Pj4gVGhhbmsgeW91IGZvciB5b3VyIHNjZW5hcmlvcy4gSG93ZXZlciwgYm90 aCBvZiB0aGVzZSBzY2VuYXJpb3MgYXJlDQo+ID4+PiBhZGRyZXNzZWQgYnkgdGhlIHRleHQgb2Yg UkZDNjM3OC4NCj4gPj4+DQo+ID4+PiAxLiBSZWdhcmRpbmcgU2NlbmFyaW8gIzE6IFRoZSBzZWNv bmQgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4zLjMuMQ0KPiA+Pj4gc3RhdGVzIC0gIldoZW4gdGhl IExFUiB0cmFuc2l0aW9ucyBpbnRvIHRoZSBOb3JtYWwgc3RhdGUsIHRoZSBQU0MNCj4gPj4+IENv bnRyb2wgUHJvY2VzcyBTSEFMTCBjaGVjayB0aGUgcGVyc2lzdGVudCBzdGF0ZSBvZiB0aGUgbG9j YWwgdHJpZ2dlcnMNCj4gPj4+IHRvIGRlY2lkZSBpZiBpdCBzaG91bGQgZnVydGhlciB0cmFuc2l0 aW9uIGludG8gYSBuZXcgc3RhdGUuLi4uIg0KPiA+Pj4gTWVhbmluZyB0aGF0IGluIHlvdXIgc2Nl bmFyaW8sIGFmdGVyIHJlY2VpdmluZyB0aGUgQ2xlYXIsIGJlZm9yZQ0KPiA+Pj4gdHJhbnNpdGlv bmluZyBpbnRvIE5vcm1hbCBTdGF0ZSwgTEVSLTEgc2hvdWxkIGhhdmUgY2hlY2tlZCB0aGUgc3Rh dHVzDQo+ID4+PiBvZiB0aGUgb3RoZXIgdHJpZ2dlcnMgYW5kIGRlY2lkZWQsIGJhc2VkIHVwb24g dGhlIHN0aWxsIGFjdGl2ZSBTRi1XIHRvDQo+ID4+PiB0cmFuc2l0aW9uIGludG8gUHJvdGVjdGlu ZyBGYWlsdXJlIHN0YXRlLCB0cmFuc21pdHRpbmcgYSBTRigxLDEpDQo+ID4+PiBtZXNzYWdlLiBB cyB0byB0aGUgcmVhY3Rpb24gb2YgTEVSLTIsIHNlZSBiZWxvdy4NCj4gPj4+DQo+ID4+PiAyLiBS ZWdhcmRpbmcgU2NlbmFyaW8gIzI6IFRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4z LjMgc3RhdGVzDQo+ID4+PiAtIldoZW4gYSBMRVIgaXMgaW4gYSByZW1vdGUgc3RhdGUsIGkuZS4g c3RhdGUgdHJhbnNpdGlvbiBpbiByZWFjdGlvbg0KPiA+Pj4gdG8gYSBQU0MgbWVzc2FnZSByZWNp ZXZlZCBmcm9tIHRoZSBmYXItZW5kIExFUiwgYW5kIHJlY2VpdmVzIGEgbmV3IFBTQw0KPiA+Pj4g bWVzc2FnZSBmcm9tIHRoZSBmYXItZW5kIExFUiB0aGF0IGluZGljYXRlcyBhIGNvbnRyYWRpY3Rv cnkgc3RhdGUsDQo+ID4+PiBlLmcuIGluIHJlbW90ZSBVbmF2YWlsYWJsZSBzdGF0ZSByZWNlaXZp bmcgYSByZW1vdGUgRlMoMSwxKSBtZXNzYWdlLA0KPiA+Pj4gdGhlbiB0aGUgUFNDIENvbnRyb2wg TG9naWMgU0hBTEwgcmVldmFsdWF0ZSBhbGwgaW5wdXRzIChib3RoIHRoZSBsb2NhbA0KPiA+Pj4g aW5wdXQgYW5kIHRoZSByZW1vdGUgbWVzc2FnZSkgYXMgaWYgdGhlIExFUiBpcyBpbiB0aGUgTm9y bWFsIHN0YXRlLiINCj4gPj4+IE1lYW5pbmcgdGhhdCBpbiBib3RoIHRoZSBjb250aW51YXRpb24g b2YgdGhlIHByZXZpb3VzIHNjZW5hcmlvIGFzIHdlbGwNCj4gPj4+IGFzIGluIHlvdXIgc2NlbmFy aW8sIExFUi0yIHNob3VsZCByZWFjdCB0byB0aGUgcmVtb3RlIFNGIG1lc3NhZ2UgYXMgaWYNCj4g Pj4+IGluIE5vcm1hbCBhbmQgdHJhbnNpdGlvbiBpbnRvIFJlbW90ZSBQcm90ZWN0aW5nIEZhaWx1 cmUgU3RhdGUuDQo+ID4+Pg0KPiA+Pj4gVGhlcmVmb3JlLCBJIGNvbnRlbmQgdGhhdCBuZWl0aGVy IHNjZW5hcmlvIHdpbGwgY2F1c2UgUFNDIHRvIGNyYXNoLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0K PiA+Pj4gT24gVGh1LCBKYW4gMTAsIDIwMTMgYXQgMTE6MTAgQU0sIOabvuWzu+azog0KPiA+Pj4g PHpqYmRhbW9AaG90bWFpbC5jb208bWFpbHRvOnpqYmRhbW9AaG90bWFpbC5jb20+PiB3cm90ZToN Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4gKGlmIHRoZSBmaWd1cmUgY2FuIG5vdCBkaXNwbGF5IG5vcm1h bGx5LHBsZWFzZSBzZWUgdGhlIGF0dGFjaA0KPiA+Pj4gZmlsZS50aGFua3MuKQ0KPiA+Pj4NCj4g Pj4+DQo+ID4+PiBXaGVuIGluIG11bHRpIGZhdWx0L3ByaW9yaXR5IGNvbmRpdGlvbiBzY2VuYXJp byxSRkM2Mzc4IGNhbiBub3QNCj4gPj4+IHByb3RlY3QgdGhlIHRyYWZmaWMgc28gbXVjaCBhcyB0 YWtlIHRoZSBQU0Mgc3RhdGUgdG8gY3Jhc2guY29uc2lkZXINCj4gPj4+IHRoZSBmb2xsb3dpbmcg MiBzY2VuYXJpby4NCj4gPj4+DQo+ID4+PiArLS0tLS0tKyArLS0tLS0tKw0KPiA+Pj4gfCBMRVIx IHwgfCBMRVIyIHwNCj4gPj4+ICstLS0rLS0rICstLS0rLS0rDQo+ID4+PiArLS0tLS0tLS0tLU5S LS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+ID4+PiB8IHwNCj4gPj4+IHwgfA0KPiA+Pj4gfDwtLS0t LS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+Pj4gbG9jYWwgbG9ja291dCB8IHwNCj4g Pj4+IGlucHV0IHwgfA0KPiA+Pj4gKy0tLS0tLS0tLS0tTE9DSy0tLS0tLS0tLS0tLS0tLS0+fA0K PiA+Pj4gfCB8DQo+ID4+PiB8IHwNCj4gPj4+IHw8LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0t LS0tLSsNCj4gPj4+IHwgfA0KPiA+Pj4gdW5pZGlyZWN0aW9uIHwgfA0KPiA+Pj4gU0ZfVyByYWlz ZSB8IHwNCj4gPj4+ICstLS0tLS0tLS0tLS0tTE9DSy0tLS0tLS0tLS0tLS0tPnwNCj4gPj4+IHwg fA0KPiA+Pj4gfCB8DQo+ID4+PiB8PC0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ ID4+PiB8IHwNCj4gPj4+IGxvY2FsIGNsZWFyIHwgfA0KPiA+Pj4gaW5wdXQgfCB8DQo+ID4+PiAr LS0tLS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLT58DQo+ID4+PiB8IHwNCj4gPj4+IHwgfA0K PiA+Pj4gfDwtLS0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+Pj4gfCB8DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+IGZpZ3VyZSAxOiB1bmlkaXJlY3Rpb24gU0ZfVyByYWlzZSBhZnRlciBs b2NhbCBsb2Nrb3V0DQo+ID4+PiBpbnB1dA0KPiA+Pj4NCj4gPj4+IGluIGZpZ3VyZSAxLGNvbnNp ZGVyIHRoZSBmb2xsb3dpbmcgcHJvY2VkdXJlDQo+ID4+PiAxLkxFUjEgYW5kIExFUjIgYXJlIGJv dGggaW4gTk9STUFMIHN0YXRlIGFuZCBleGNoYW5nZSBOUiBQRFUuDQo+ID4+PiAyLnRoZSBsb2Nr b3V0IGNvbW1hbmQgaW5wdXQgaW50byBMRVIxLHRoZW4gTEVSMSBzZW5kIExPQ0sgdG8gTEVSMixM RVIyDQo+ID4+PiBzZW5kIE5SIHRvIExFUjEuDQo+ID4+PiAzLmEgdW5pZGlyZWN0aW9uIFNGX1cg aXMgcmFpc2VkIGluIExFUjEsYWNjb3JkaW5nIFJGQzYzNzgsIExFUjEgc3RpbGwNCj4gPj4+IHNl bmQgTE9DSyB0byBMRVIyLExFUjIgc2VuZCBOUiB0byBMRVIxLg0KPiA+Pj4gNC50aGUgY2xlYXIg Y29tbWFuZCBpbnB1dCBpbnRvIExFUjEsYWNjb3JkaW5nIFJGQzYzNzgsTEVSMSB3aWxsIHNlbmQN Cj4gPj4+IE5SIHRvIExFUjIsTEVSMiBzdGlsbCBzZW5kIE5SIHRvIExFUjEuIHNvIHRyYWZmaWMg aXMgYnJva2VuLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICstLS0tLS0rICst LS0tLS0rDQo+ID4+PiB8IExFUjEgfCB8IExFUjIgfA0KPiA+Pj4gKy0tLSstLSsgKy0tLSstLSsN Cj4gPj4+IE4gKy0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0+fCBODQo+ID4+PiB8IHwN Cj4gPj4+IHwgfA0KPiA+Pj4gfDwtLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+ Pj4gbG9jYWwgbG9ja291dCBpbnB1dCB8IHwNCj4gPj4+IHwgfA0KPiA+Pj4gVUE6TE86TCArLS0t LS0tLS0tLS1MT0NLLS0tLS0tLS0tLS0tLS0tLT58DQo+ID4+PiB8IHxVQTpMTzpSDQo+ID4+PiB8 IHwNCj4gPj4+IHw8LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gPj4+IGxvY2Fs IGNsZWFyIGlucHV0IHwgfA0KPiA+Pj4gfCB8DQo+ID4+PiB8IHwNCj4gPj4+IE4gKy0tLS0tLS1O Ui0tLS0tLS0tLS0tLS0tLi4uLi4uLi4ufA0KPiA+Pj4gfCB8DQo+ID4+PiBTRl9XIHJhaXNlIHwg dGhpcyBuciBpcyBsb3N0IGZvciBzbXRoLiB8DQo+ID4+PiB8IGFuZCBTRl9XIGlzIHJhaXNlZC4g fA0KPiA+Pj4gfCB8DQo+ID4+PiArLS0tLS0tLS0tLVNGX1ctLS0tLS0tLS0tLS0tLS0tLT58YWx3 YXlzIGluIFVBOkxPOlINCj4gPj4+IHwgfA0KPiA+Pj4gfCB8DQo+ID4+PiB8IHwNCj4gPj4+IHw8 LS0tLS0tLS0tLS1TRl9XLS0tLS0tLS0tLS0tLS0tLSsNCj4gPj4+IHwgfA0KPiA+Pj4gfCB8DQo+ ID4+Pg0KPiA+Pj4gZmlndXJlIDI6IGFmdGVyIGNsZWFyIGEgbG9jYWwgTE9DS09VVCBjb21tYW5k LFNGX1cgaXMgcmFpc2UNCj4gPj4+IGltbWVkaWF0ZWx5LGFuZCB0aGUgTlIgc2VuZCB0byBMRVIy IGlzIGxvc3QgZm9yIHNvbWV0aGluZy4NCj4gPj4+DQo+ID4+PiBpbiBmaWd1cmUgMixjb25zaWRl ciB0aGUgZm9sbG93aW5nIHByb2NlZHVyZS4NCj4gPj4+IDEuTEVSMSBhbmQgTEVSMiBhcmUgYm90 aCBpbiBOT1JNQUwgc3RhdGUgYW5kIGV4Y2hhbmdlIE5SIFBEVS4NCj4gPj4+IDIudGhlIGxvY2tv dXQgY29tbWFuZCBpbnB1dCBpbnRvIExFUjEsdGhlbiBMRVIxIHNlbmQgTE9DSyB0byBMRVIyIGFu ZA0KPiA+Pj4gdHJhbnNmZXIgdG8gVUE6TE86TCxMRVIyIHNlbmQgTlIgdG8gTEVSMSBhbmQgdHJh bnNmZXIgdG8gVUE6TE86Ui4NCj4gPj4+IDMudGhlIGNsZWFyIGNvbW1hbmQgaW5wdXQgaW50byBM RVIxLExFUjEgdHJhbnNmZXIgdG8gTlIgYW5kIHNlbmQgTlIgdG8NCj4gPj4+IExFUjIsYnV0IHRo aXMgTlIgaXMgbG9zdCBmb3Igc29tZSB1bmtub3duIHJlYXNvbiwgYW5kIFNGX1cgaXMgcmFpc2Vk DQo+ID4+PiBpbW1lZGlhdGVseSBpbiBMRVIxLHNvIHRoYXQgdGhlIE5SIHRoYXQgc2VuZCBieSBM RVIxIHRvIExFUjIgaXMNCj4gPj4+IHJlcGxhY2VkIGJ5IFNGX1cuDQo+ID4+PiA0Lm5vPGh0dHA6 Ly80Lm5vIDxodHRwOi8vNC5uby8+ID4gTlIgcmVhY2ggTEVSMiwgaWYgdGhlIGVycm9yIGlzDQo+ IGJpZGlyZWN0aW9uYWwsTEVSMg0KPiA+Pj4gd2lsbCBzZW5kIFNGX1cgdG8gTEVSMSxvciBOUiB0 byBMRVIyIGlmIHVuaWRpcmVjdGlvbmFsLmJ1dCBpbiBhbnkNCj4gPj4+IGNvbmRpdGlvbixMRVIy IHdpbGwgc3RpbGwgaW4gVUE6TE86UiBzdGF0ZS50aGUgUFNDIGlzIGNyYXNoZWQuDQo+ID4+Pg0K PiA+Pj4NCj4gPj4+IHNvIGkgaGF2ZSAyIHBpZWNlcyBvZiBzdWdnZXN0aW9uDQo+ID4+PiAxLkxF UiBhbHdheXMgc2VuZCBoaXMgbG9jYWwgaGlnaGVzdCBwcmlvcml0eSB0byBpdCdzIHBlZXIuDQo+ ID4+PiAyLkxFUiBhbHdheXMgYWNjZXB0IHRoZSBpbnB1dCBmcm9tIGhpcyBwZWVyIGJ5IFBTQyBQ RFUuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBCZXN0 IFJlZ2FyZHMhDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBKdW5ibyBaZW5nKEJvQm8pDQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gbXBscyBtYWlsaW5n IGxpc3QNCj4gPj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+ID4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPj4+DQo+ID4+Pg0K PiA+Pj4NCj4gPj4+DQo+ID4+PiAtLQ0KPiA+Pj4gVGhhbnggYW5kIEJSLA0KPiA+Pj4geWFhY292 DQo+ID4+Pg0KPiA+Pj4gU3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5DQo+ID4+DQo+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From eosborne@cisco.com Tue Jan 15 10:04:58 2013 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 0653221F86D5 for ; Tue, 15 Jan 2013 10:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[AWL=3.300, 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 UsEcoIP9bFCG for ; Tue, 15 Jan 2013 10:04:56 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAA021F86C9 for ; Tue, 15 Jan 2013 10:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40616; q=dns/txt; s=iport; t=1358273096; x=1359482696; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=z/Q6lB0BjpqEIPmNi3WFhjBzmNt5b7GVhBdVDTMkqps=; b=T+G50kmDdyuH5T2dK7m15HGiRLIaUok9Ms6GoRB6wXtgr7pK6N3L+NsK sFqPVW4Ea3JysT8eIevNSQrkLC0edNHJ7rvVTUEgMouCemmc/IOFpubyE mahvaGfYlpMAG7PfQa47pfFxmw4j32pTtfall69PV/hyngdmSkaewNiXi 4=; X-Files: eosborne-2013_Jan_15 draft ring protection LS response.docx : 20992 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFAF2Z9VCtJXG9/2dsb2JhbABFuj2DSRZzgh4BAQEDAWsDCwUHBAIBCBEEAQELCxIHAjAUCQgBAQQBDQUIBg2HeAYMqEeOS4YphlYBgQOCVGEDjwiIII8tgnWBbzU X-IronPort-AV: E=Sophos;i="4.84,475,1355097600"; d="xml'?rels'?docx'72,48?scan'72,48,72,48,208";a="162694339" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 15 Jan 2013 18:04:55 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0FI4tPr027147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jan 2013 18:04:55 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 12:04:55 -0600 From: "Eric Osborne (eosborne)" To: "adrian@olddog.co.uk" , "'Ross Callon'" Thread-Topic: [mpls] Proposed response to Ring Protection Liaison Thread-Index: Ac3wLIvW2MilEmiNRY61kTc4hga6xgA+dzKAAIeBAQA= Date: Tue, 15 Jan 2013 18:04:54 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572100A173F@xmb-rcd-x09.cisco.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD309A3976C@CH1PRD0510MB355.namprd05.prod.outlook.com> <007401cdf0f4$1f5011c0$5df03540$@olddog.co.uk> In-Reply-To: <007401cdf0f4$1f5011c0$5df03540$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.84] Content-Type: multipart/mixed; boundary="_002_20ECF67871905846A80F77F8F4A27572100A173Fxmbrcdx09ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Proposed response to Ring Protection Liaison 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, 15 Jan 2013 18:04:58 -0000 --_002_20ECF67871905846A80F77F8F4A27572100A173Fxmbrcdx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian- Inline with EO#. I've also attached a marked-up Word doc with the propos= ed changes. =20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: Saturday, January 12, 2013 1:39 PM > To: 'Ross Callon' > Cc: mpls@ietf.org > Subject: Re: [mpls] Proposed response to Ring Protection Liaison >=20 > Hi Ross, >=20 > Many thanks for driving this. >=20 > It's somehow appropriate to write a liaison to the ITU-T in Microsoft Wor= d :-) EO# The LS came in as PDF, but Word's much easier to edit. When it's done= we should probably send it as PDF.=20 >=20 > I have some comments (as an individual). >=20 > --- >=20 > I assume the chairs will top and tail this liaison with the usual polite = niceties. In > particular, we should welcome the way that SG15 is engaging with the MPLS > working group on ring protection requirements. >=20 EO# I'm not a chair and am good at neither polite nor nice, so I've left t= hese bits out of my edits. > --- >=20 > I suggest using a different numbering scheme to avoid confusion between t= he > two lists of requirements. Include the text: > "To avoid confusion we have numbered the suggested requirements in your > Liaison as IR1, IR2, etc. and we refer to the requirements in RFC 5654 us= ing the > notation as published (i.e., R96, R97, etc.)." > And then, obviously, fix the liaison text accordingly. >=20 EO# Done. > --- >=20 > This draft does not seem to answer the first noted requirements in the > incoming liaison viz. > | Requirements for ITU-T G.8132 > | Requirements and optimization criteria for ring protection specified > | in RFC5654 "MPLS-TP requirements" have to be taken into account. >=20 > I think this deserves the response: > We agree that the requirements and optimization criteria for ring protect= ion > set out in RFC 5654 should be taken into account. In particular, we draw = your > attention to the preamble in Section 2.5.6.1 and the statements made abou= t the > cost/benefit implications of specialised protection solutions. >=20 EO# I could go either way on this, but I've added your text.=20 > ---- >=20 > In your second paragraph, I don't think it is necessary to say "Adding ne= w > requirements for a technology already in active development and deploymen= t > is not to be taken lightly," I am sure that the ITU-T is well aware of th= e risks of > moving goalposts. Of course, neither of the proposed requirements IR2 and= IR3 > proposes a change to linear protection - they are both requirements place= d on > ring protection.=20 EO# When I wrote 'in active deployment' I meant the text in rfc5654, not rf= c6378. Of course, it's not actually possible to have deployed a set of req= uirements. > In my view IR2 may make a specialist ring protection scheme > almost impossible to devise since it would have to seamlessly upgrade fro= m > linear protection. EO# They could be run as ships-in-the-night and then migrated away from, I= guess. That'd move it from 'almost impossible' to 'quite difficult'. >=20 > So, I think you should: > - delete the apple pie text > - invite new requirements to be raised within the MPLS WG using the norma= l > IETF process >=20 EO# Done. I debated suggesting that R2 s/network upgrade/network migratio= n/ and R3 s/upgrade/resize/ (particularly as one could both grow and shrink= a ring as part of the normal course of operations) but I'll leave that for= the standard WG bashing. > --- >=20 > I am not a huge fan of holding technical debate via liaison statement. Th= at said > your observations on T1 and T2 are correct. EO# What is the correct vehicle for technical debate? Discussion on the I= ETF list? Discussion first followed by a LS to formalize the discussion po= ints? I've added some text to this effect as a start - "For the technical = analysis, we invite the discussion of these scenarios on the MPLS WG email = list, as that may help to progress a technical solution more effectively th= an liaison statements." >=20 > --- >=20 > In your discussion of T2 you say: >=20 > > The IETF believes in topology-independent mechanisms whenever > > possible, as prescribing or proscribing specific network architectures > > is outside the IETF's scope. >=20 > I wonder whether you can give me a reference for this statement. AFAICS t= here > are plenty of examples of the IETF recommending specific > technologies/solutions for specific environments/networks. You might say= that, > as a general rule, the IETF has tended to try to avoid optimizing for spe= cial > cases. Or you might simply delete this sentence. EO# I'd much rather delete it than argue IETF history with you, as I'm pre= tty sure I'd get my hat handed to me. Deleted. >=20 > --- >=20 > Later in the discussion of T2 you say: >=20 > > The IETF believes that the reuse of linear protection mechanisms in a > > ring topology (i.e. draft-ietf-mpls-tp-ring-protection) will meet > > performance targets in a ring topology, and will do so while allowing > > the operator to deploy a single protection method across all possible > > network topologies. >=20 > I do not believe it is your intention to test IETF consensus on this befo= re sending > the liaison. You might s/IETF/MPLS working group/ and use the review of t= his > liaison statement as the way to test that consensus. EO# s/IETF/MPLS WG/ done. I'm going to stay away from the consensus point= on this thread, as that's a whole separate thing, but I do note that the r= ing protection doc is a WG draft and thus has at least some level of enthus= iasm behind it. >=20 > When you say "the performance targets" you should append "expressed in RF= C > 5654". >=20 EO# Done. > --- >=20 > The paragraph on the sophistication of ring-based networks is undoubtedly > true. Even in traditional transport networks, ring interconnects have mad= e end- > to-end paths appear to traverse a mesh. The ease with which packet networ= ks > can bridge between rings makes the meshiness all the more likely. >=20 > Notwithstanding that, there is (or it could be argued that there is) valu= e in > imposing logical protection domains in mesh networks. By treating a porti= on of > the mesh network as a logical ring, certain specific ring protection > characteristics (such as those discussed in draft-ietf-mpls-tp-ring-prote= ction) > can be leveraged. >=20 > So, I am wondering what this paragraph is attempting to add to the liaiso= n. >=20 EO# This point, I think, is important. It was an attempt to say "if we're going to discuss ring-specific mechanism= s we should agree when something is and is not a ring". 'Ring' has very pa= rticular significance in the transport world, and the text was an attempt t= o draw out that definition. Some members of the WG (ok...probably just me)= do not understand the distinction between a sufficiently sophisticated rin= g and a mesh. I'd hate to come up with an agreement on what ring-specific = protection looks like only to find out post hoc that one side meant "a set = of no more than 16 nodes [A---B---C---...---P--A] which constitute the enti= rety of a given ring-specific protection domain" and the other meant "an ar= bitrary mesh that has been subdivided into little circles but with end-to-e= nd protection across the ringmesh" or something like that. In my opinion u= nderstanding the definition is key to scoping the requirements properly. =20 > --- >=20 > The way you handle answering C-2098 is correct, but maybe s/C-2098/C-2098 > referenced from Annex 2/ EO# Added a few words to do this. > Also s/IETF's Fast ReRoute./IETF's MPLS Fast ReRoute described in RFC 409= 0/ >=20 EO# Done. > And then, s/The IETF recommends/The MPLS working group recommends/ > (assuming you have consensus for that) >=20 EO# Done > --- >=20 > The incoming liaison also says: >=20 > | We would also like to know status of the individual/working group > | drafts containing MPLS-TP ring protection solutions. >=20 EO# Thanks, clearly we missed that. Added your text in the beginning of t= he document as a placeholder so the chairs can edit as necessary. Ross, Scott, others - comments and edit pen as necessary. eric > This needs an answer, and the chairs are probably best placed to craft it= . > Something like... > "draft-ietf-mpls-tp-ring-protection describes the applicability of the ge= neric > linear protection mechanisms (RFC 6378) to ring topologies. As such it se= ts a > baseline for determining the optimization value of any other proposed > solutions. This draft also discusses a number of the different mechanisms= that > can be used in ring protection and highlights the optimizations that can = be > made in packet networks as compared to traditional transport networks whe= re > tunnelling is not so readily available. The status of this draft is foo. > There are also a considerable number of individual drafts proposing diffe= rent > solutions and addressing different aspects of ring protection. The chairs= hope > that these documents will be discussed further on the MPLS mailing list s= o that > it becomes clear which offer the best solutions addressing all the requir= ements > and providing optimization benefits. The chairs also hope that the author= s of > the various drafts will attempt to find compromise positions that allow t= heir > approaches to be merged. Lastly, the chairs hope to hear of intent to > implement that will clearly show which drafts have concrete support." >=20 > --- >=20 > Finally, and off the topic of the liaison response, I wonder whether the = chairs > have time on the agenda in Orlando to allow a 20 minute (or so) slot disc= ussing > ring protection to determine what the next steps are for the WG. Maybe on= e of > the ITU-T experts who attend the IETF could lead a discussion based on th= e > received Annex 2. >=20 > --- >=20 > Thanks! > Adrian >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Ross Callon > Sent: 11 January 2013 18:51 > To: mpls@ietf.org > Subject: [mpls] Proposed response to Ring Protection Liaison >=20 > We've had a small team that prepared a response to an incoming liaison fr= om > ITU-T SG15 on ring protection. The incoming liaison is: >=20 > 2012-10-03 ITU-T SG 15 Multiprotocol Label Switching 2012-1= 2-31 > Requirements and analysis of ring protection > for MPLS-TP networks > http://datatracker.ietf.org/liaison/1199/ >=20 > The proposed response is attached. >=20 > Please send comments on the proposed response to the MPLS working group > mailing list (mpls@ietf.org) by next Friday (January 18, 2013). >=20 > Thanks, Ross > (as MPLS WG co-chair) >=20 >=20 >=20 --_002_20ECF67871905846A80F77F8F4A27572100A173Fxmbrcdx09ciscoc_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="eosborne-2013_Jan_15 draft ring protection LS response.docx" Content-Description: eosborne-2013_Jan_15 draft ring protection LS response.docx Content-Disposition: attachment; filename="eosborne-2013_Jan_15 draft ring protection LS response.docx"; size=20992; creation-date="Tue, 15 Jan 2013 17:12:11 GMT"; modification-date="Tue, 15 Jan 2013 18:00:11 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBJn4PiqwEAAJcGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lc1u2zAQhO8B+g4Cr4FEJ4eiKCznkCbH1EAdpFeaWtlE+QfuOrHfvivZFpxWtdw4uQiQyJ35OOCu xjdrZ7NnSGiCL8VVMRIZeB0q4xeleJzd519EhqR8pWzwUIoNoLiZfLoYzzYRMONqj6VYEsWvUqJe glNYhAieV+qQnCJ+TQsZlf6lFiCvR6PPUgdP4CmnRkNMxt+gVitL2d2aP29JElgU2e12Y+NVChWj NVoRk8pnX/3hku8cCq5s9+DSRLxkDCF7HZqVfxvs6r5zNMlUkE1VogflGEO+hFTJKuiV4zMUx2V6 OENdGw1dfaMWU9CAyJk7W3QrThm/5+/j0Cuk4H46Kw2Bm6YQ8epsnE600YNEBroM+xjaLPzKzSEx /dnuf4XRSR8LooVA2ljA9yfY6p5o/2RoeVfXoPnWD18Mh3mDXmwtDmqH3YCI8z7F5HUv5kO3D3fK gwgvMP/xYRQH4oMgNc+ImZpbOCHx/wyjkx6EIB58INvn+T3Yyhyz5BHRtjsP0vSGY+8nZVOd8+w5 oc87Rx7CZ+cMzZivoOrxlu1vZfIbAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2j ILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyM Maui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03 Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1 nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQAqQskQQwEAAMwE AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKyUMU/DMBCFdyT+Q+SdOCnQItSkCyB1hSJYXeecWMR2ZF+A/nsOooZULWHJ eM/yvU/Pd16uPk0dvYMP2tmMpXHCIrDSFdqWGXvePFzcsCigsIWonYWM7SCwVX5+tnyEWiBdCpVu QkRdbMhYhdjcch5kBUaE2DVg6UQ5bwRS6UveCPkmSuCzJJlzP+zB8oOe0brImF8X5L/ZNeT8f2+n lJZw52RrwOIJC47EBdRQ+BIwYz9lJ6YxgTJ+muFySoaAu5pC7CG6esx+MaW9chY3YlsPYuilMYjZ lBC2NVvwNGO/MfTSGEQ6JYRsAzrzSs/ev0Uc817lGsGMjsV8SpoP2D4BImUymI2BOBbL9ZQg4Yhi r4whXP2BYLT0LjiFsXSGdxv6vZmLw+Xn3Ra8aKzulQKJgxCOjvYc/OAPyr8AAAD//wMAUEsDBBQA BgAIAAAAIQB+vzGq6BEAAExBAAARAAAAd29yZC9kb2N1bWVudC54bWzsW9tu40iSfR9g/yGhl+3G lGXd5TLGGrjKdk0B1RjD1mCAfVmkyJREmGRyeLFK89SfMQvM/lx/yZ6ITF5FqUR312Af5qFcEkXm JS4nTkQk//DHr4EvXlWceDq86Q37g55QoaNdL9zc9P6yfLi46okklaErfR2qm95eJb0/Lv7jd3/Y XbvayQIVpgJDhMn1LnJuets0ja4vLxNnqwKZ9APPiXWi12nf0cGlXq89R13udOxejgbDAX+KYu2o JMF8H2X4KpOeHS44HE1HKsRcax0HMk36Ot5cBjJ+yaILjB7J1Ft5vpfuMfZglg+jb3pZHF7bBV0U C6JHrs2C7H/5E/HBLlrmNU/eWQnwjJex8rEGHSZbLyq38dbRsMVtvqTXU5t4Dfz8vl00nBzMV2z5 HB3cxXIHVZQDHgzXIgzXPBT4Rg6k31KrzRGHg1ObsRqhIYo1nLOE+pz5SgLphcUwbxNNVbjwiF9j 359inUXFciLv1432OXwpxiLH7LCywYw9r7q1pNMAB677vJWR6onAuf68CXUsVz5WtBtOBFlkbwGw WGl3T/9HYncNsHGfbnqDwdV4NJoCYOylR7jeYDAdjB9mD8XFO7WWmZ/SL/O76XhW3P5YucQjP8b0 X2z+W13SlwxDv0r/pkf44qseLl7aW/B/ZJ9onb/LWLvrdAE7X6ciVkkEBFAi1eLz8i/iy/NkcEVz pmZm/hvxcvNZaRu3k/n8w6htz/VfeM/T+Xx8dc9SzXdgNuKFCQb1XIxIQ8ks3WqI9D72HPHnZKXj EDoCbssU2gEAjy8Gw4vhdDkcXU8H14PBf7XLpxx22HXY0YiHZVnSn3Sx1EK+as8Vjg7XGUUdsVNi K1+VCLNgpWLlinSrRJJtNipJ8S1Wf8u8WFGkSYQXir3OYvHFk16CZ2UiPj8N3+HP6J1QqdMXCFU0 YqzWKiYt0GDNIZ4ePorpbDoRWEC44VtCnTJ404hRVtMYDMasfeV7yRYr+sHrq/478fR+Rn/mZuIf +7WHoHLI7Yi6Hz7Orx7mbequ/8LqtpfYZoyeo+d07ytokk370QfKLdXXlLRX2H+pNDarTrYwPMcW xl1tYWqG5TWyPCnQXyeRdGCNERxHxa+qt1hCX2svTsiX/pbBBEjnpETfqhxsJGVrEF5CCkaoefVc WAyuZ4nQazzgeriUSZ9w7oVUvCHsFQhUaxgRTC+FzOj6T49fni+WjyKmLxgpVQ6FcJFoP+NY3hei plegRqz1+j6OIf90H2Htm1gGz6mMcwXw5hY818W3nk0i5fuHD3sqXZ/16H3oWrWbWd86YRD5yb90 wjR623SkqItSUd8ahHTTkFG72QlXJU7srRRsCsYmo8j3HGkIJdkUXdyoUBGW+l6oZFw1l0A5Wxl6 SZCIHwhcZuP51Y9knGxXqY60rzeeSvriNgG0OVvhpSJRsEUpVjJRNKIAr8UqUhUHxjZpSh2lXuD9 3UAT3D3DpTUwbi80fuY1RDoBJlUMdrmFY7D5CeknWrhe4mRJgp1Ji7H5hlxvDZQkCl/ZQLqVqXBk KFYK+Iih4X9N9yCQ3XqbrY9/2ERzpXSlHCSQ8E4MAk9/UakIVUpeidWQJ4K3M+QDqGPpeuRz0qfP IQJpXLl7h+2qb/riEX9KszCEo8F2vmUwPMB5FgMpI2pA8kAqLN3fI7JJzyfy0xdLKK9EpLRUCZ5a a/3/NVhM3ojqrcSqjEHTNw5bBguKC9A/jMUYtSQUB49UTDYrdl2Cfw73QAv4CAF8ae+FuzBfkK6L +NO4RcIUHBg3/K1h/ka78HiEKbFFQmTMHV4A4pdnxaBinu+TE+X+54p1FuOmWCDA4H8OPgI5Ctkl QAWhDrbEngN0WCk4B3zW8QlrdlsPoIHsiEgNHgVO0d02SInKBiQmpTtqnIf8FWJAUKSpaqCyAqit PaTTbLJ2U4wbtZ0JwyBYHDT8q4w9jXDLOGP3KlME5igl3FtDDezdsQ48SIUUwPHU7A+L1DtaphcT 1MZaomDA0RzyClS8UW5ffJFJ6u/f8W5qwtZiSzLhSJ8SemFCDxHMsAIWIMueRQe3TLaYjCTYcH5L 67b5JpiFwqycGCgMmI4Igb6Xp57B4lHE6MbiLd1ucUbKdsiZaulXPbd4qmRa9V+YhtpLPMhbaCjT 3S40dDQ7h4ZyOthp2EkjJWnnA0vYeM1cckLPvB56oTTrfWcFTc+avOS/NvFhbvCpfzUcj4j1IprZ XOkd4xcukU8CD/AHDoEKHkdcvmgZ7S8//+OpmkkR20CGerEUZtxffv6fJtdt2/Kwc2pp9VhCebvA /wpg38SqxNJDBKvhFsgaqJInWTQNgCZqJXTGqUOR6wEFMt8lQE7liwrBSAAb0nF0FqZ98Zn4SZx6 TubL+B1lkEC2nUk2CddCTgvwBMk0QsAPEOaJ1Txb+Y760/6sP2R9sNzzNCUBxIMAyRUtiH5xdJJe Wthl3ALRNNgIRKvZXEuycYTgUKzyJGKIcs8a4TyGU/LsMtZ0wMM6inwDX87Aw2H3+sP4GIa0AqJd A7ybS1S2HmXKLfnF0yhZ2UXJfoadU/DDusnnmlpLzwQ1KOtpp9ZP/sel+sOU+2koEoqfe5FFLpLr pGmFla10TvsPttLu/nBTrsh8z22+nxFTMNwDDIs+I83b04eKpQcKZTMXRAe+SmQLmdDw2vj18PdD YOQSPpyi3kIJzA4oBHAA64PUKBsANDh+Rv5OQxPbYjCQQY2R0ZRFApfXHMoc7J1YEXgh0ROUV24A NBhdUZ9ExnvOHQsww8pNBliTHIyiahiDyeR+ZAqxR2wASEYLpXqI+OunpgHUBvumlS2qZTX0anzx +X75QDKmHRwAyCExacxwtssdK4eiBg1pdGEJY1O4bGFS1fg/7JzXHHjD4rs69ojDUcMyKt78VoZZ BvPvu/4xZTacfl1whEP/sE4L4EcWOZrkBXVu5UPrxNOGncnn2NTDeZ9VR2pYZluEuFPoNxQlfRoB C6H6bDvw3bqck4VqV98Z8TMJnHG2IRWPUFzwqcwA70fVG0VKFMxd9ap8HXEPljI8V0W+3vNXwgug EcRT8B2u1VA+RbeSSdhlLegzUiFzhdZbMZDO9LoqOBorXaDitfPSranTU+Wqdau2ENsw1QJ3aoLm cdulWQeu3zZMlgTy2CpJ78PZ/Gp4y92ZIxo/C7FPGZqRawOxEYwixCt0394AuOPZaHT7kUDyLOJT v73ZlFpp/UJ9eS5r5x7IqVKIMHjT++9P+gNKgaZuXdraqHNmYUGaxGFT+Qc4DYUxdhvQah/GLv19 4iVM6b3wFUkD32GLMlTrB+vGMyhSJI4KqaxRr4SXRlRZa2cmOjZMtFzrEfutloYQh3GKwvO5NgS/ tWXVQO5RAPEjy1uQNCVU2i33nNeFRKBjJRSKRowXxHSIzRw0Ug5DMnbKgMChOdcncoZSm9xrqlUT TllsbliVSF6/vWlDNpLXO11fUCJ7lDHSRBltc/OhNflqTQ1iugRt5Swgn/QQOxbLIRE1SpVJcrne USOiGuNheX/HmSMXezM+w0IgTHa2RvOK7CdAh9pDAQoXPD/DyJYmbgDTaCZZuyIWp0OoASdpqCKW eJRDVlA70MBk8yjWQbVOJokA0JMLS8yi8OCfMTC3F3gkbpBhlTvIKyIqWmG5MCYXdb/Q1Pe5ite9 d3RCwm/oYJ0Y7Tdd2ht6Xf+qpXXuip1aGBVFKq0yE/glrJjyGioZgU+keYYiN8CRjW2Bw9FRGCFY qTZrEoUKCdLDqhm5ms7YNACkkXwMx8PB1ehURGz0WMmHCShPwcvZSNKZQixHVAkCwsRozKFb16jv wNvzXBU+dJIJVPa9+OXnfx679xCf2mPD0V51kQvaAhl8mtgj5/QeKLPRqglzppeBngU0ScGPyCAh GTAL5yqgc+6rZCjj869om+c3wFJ++fl/LbChMUi4h6KiYUWoHppSFkkMfQv8QfMOdzAfYbZaaUgU NbuS1Vdre5jjT3oHcotCXFP8tF4cvLh4Gg7eI+tmlmv7+dgLav3UXG2dFKMe0wDxto+z6fSDTZEX VsPH7j9XY6bWQA0/dCsqndwEgvsnr5SbFWdP46Mj8qRCNL2U+yg36gM8+IUj8RGqSZqFqjF/IKkm zDaAfnG130vk3IYz26hGjgEtepuQjSdEEwZZBMocthrSOmjZHS/LGHmUTKj6kY8NG6JeDALfTqF7 nONP3oaiJTJwFfleZTxITW4Ib8pCKjekbCKEsd6VjSD+ZoIrfyTLsXZvqzLILfOGc+k55XTG2hvK QYAG5lJSOepc1RvPy+p/DtycKt6N7z/c5+z7zuSPlmMTDtpErR0VllAxl1dWOEUAn+EzUrmwL9CG Uzg164Lp1HS+RdcP/lWwEGaXRInoDATpBBYLtlB8LbRhAwLIibMFl3ZSYjtMbLKU2rEMJrQeIAKM yIHErePZXRymmwVCV2RB2z5i07Rh9RVUkJZ5yNVK/TUPMRA85IKBnYRUp6MxJBvcCXg4191pZcfN pXPldPz+0FxqS7E21NFg2FhomUcVUslzuhfOWhZNeq2Yc7qwVcaGrGp2UE8xn2r7PmEcdfmXqVsx 9uFAi8JxGIwJ3WJl49tJ86JCjAmnuVWZk4GmnfybUtZ/s+n8sB2AqH5gLgfSFsV+Tzb9ozneESiV Nsy44j2dy8OTI2XHqve0h4G64Z/TOMwFd+Cd8IDalkovAmLgKQ5+nSvHbVur6extaMb7Popkp9y+ wotq2z0mO5Q/7FHLXHK15Z8CJRwO3dBhv8Y8FUvpXKBuE2dTk+2Wor5SnLcH+/JUprayUuGn5HcI fybD5KM3YOY4y2R4HjfcKNAStBoGRmU6HEzkejUVYPArCGGlPGGacMhCwUFQosGZpqJekjMQC7p0 qrK2+kb2efswRarwa7NPO0qu+Ur2Of84m8y5HEil02Ydy9Ql2xVBlX/KsrA7e8oJnASMns+hJTrC mUGcRyiSNz7jUOTjmtgbzoYq8QNLD0Wl2JShwPlA1ZEToWHI5+chXJQ/k2yFRqWL3JAGwoVTQpvM ZoPxwAhtUR7GxDtWW1uENIop6l52TDqB3xyXHWPxI05BvBBTTPkUHp2z4PYE6rBE5DKcrM+jaa7g Nc6O4RoOwSGjM4dGQdJuweK4csWyO0wXKkZky3YKe4a15VmiOVBXDgHz4qMZOzqyyn1cyhSKhi4e wwrTDHUPG+15Lc1d5pZBPnh3N7+9My9opIv4pS4RONc3ixsGWG5raUH1+ESdHJnjWeZmEnYFVjq3 byZXJec8gWi3MK6vYgSihAOJsAgtPl6MBu+vmiS6BUlIQPXaryV3drsnZjVz4GUR09xaKdRWzdma /NwtZ9pMcGP16qGlRiBkKqlZSAdzjSEE3CPLTQBNtH1fPFPVIlKaqri7LY4Y0isp1HFj2MpPdeaX 6WQgmRXZjF2WrW9QQdndo9OBViXZonY0HcjEfeCUKLrqHewJ4wYXEgXgDRVgcWRY+Zy34bU3cuvy pQYyfzoCgKPlZhBk5gTeOI5EsCGQceEjNTrwEOErbf4/T0WazmfWJkcYfeW9lCOZGtP8mqP8tvbw gHJIE8Yg8vrbGUcJ41mGuHhSTzi3VSdE5zOEs+Zojw5NV2qEtdn9aD5lflnp2H3bhZanUlQgPmCs yzGJY7ZxanUWKW3WWrEiy+LaxdElax137s4d20dldWdlrfb+PBjUcPwEsNWN+IiTnJLpibFxHkkT 3uFEE+MDXkqsuWTDrt4IzRQl6TA+zmtQKQ1kD8xyjJDABWZ8ngzeD0wHE4fXQXFMUfTUSu5H49vx HVnkEQtfoKBzaoA3bkX89Pz0KOgVlXrgbgiqzvvOjmF14Z9PBkYPQ/ToC2lUCGh9m0wGJreTwf0d 0zfbDKXX7Egr6JWi53fTm1yxr9OXp4xe1oXX62r/NF8Z1d8fizTgKJ7Vl0dnYunWh8lgPvto1rF5 /jtm3+Ewzmg04cm3+Dy9wmfTS978RO85XIPW4/rE3BLT+0Xl15VOUx2U303fN78ZLwXAAm96c3OS AG/ZgAcXXzcZVbCxKjMdojLaqvlZSHqEV4E4/ynG26lGTo9e6mCV41neWjbSWJDVmRea8SGnBov/ EwAAAP//AwBQSwMEFAAGAAgAAAAhADDdQymoBgAApBsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54 bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdh W4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw 7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8 inApEPgI6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9ll Ah1i1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sF fQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlsliiBmQf G3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K+BrA 12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/Q VLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX1XhZ xv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNxvhXD CNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LYAe5yzjpcVFph R/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX +oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQfEuaY8TqeKBxX kRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSKHlTRvIE5LyO3 +EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQPTMRFb68TrgT v4MpG2NiSg0UdadWxzT5u8LNKFRuy+HiCjeUyhdfP66Q+20t2Zuwe1XlzPaJQr0Id7I8d7kI6Ntf nbfwJNkjkBDzW9S74vyuOHv/+eK8KJ8vviTPqjAUaN2L2EbbtN3xwq57TBkbqCkjN6RpvCXsPUEf BvU6c+IkxSksjeBRZzIwcHChwGYNElx9RFU0iHAKTXvd00RCmZEOJUq5hMOiGa6krfHQ+Ct71Gzq Q4itHBKrXR7Y4RU9nJ81CjJGqtAcaHNGK5rAWZmtXMmIgm6vw6yuhTozt7oRzRRFh1uhsjaxOZSD yQvVYLCwJjQ1CFohsPIqnPk1azjsYEYCbXfro9wtxgsX6SIZ4YBkPtJ6z/uobpyUx8qcIloPGwz6 4HiK1UrcWprsG3A7i5PK7BoL2OXeexMv5RE88xJQO5mOLCknJ0vQUdtrNZebHvJx2vbGcE6GxzgF r0vdR2IWwmWTr4QN+1OT2WT5zJutXDE3Cepw9WHtPqewUwdSIdUWlpENDTOVhQBLNCcr/3ITzHpR ClRUo7NJsbIGwfCvSQF2dF1LxmPiq7KzSyPadvY1K6V8oogYRMERGrGJ2Mfgfh2qoE9AJVx3mIqg X+BuTlvbTLnFOUu68o2YwdlxzNIIZ+VWp2ieyRZuClIhg3kriQe6VcpulDu/KiblL0iVchj/z1TR +wncPqwE2gM+XA0LjHSmtD0uVMShCqUR9fsCGgdTOyBa4H4XpiGo4ILa/BfkUP+3OWdpmLSGQ6Ta pyESFPYjFQlC9qAsmeg7hVg927ssSZYRMhFVElemVuwROSRsqGvgqt7bPRRBqJtqkpUBgzsZf+57 lkGjUDc55XxzKlmx99oc+Kc7H5vMoJRbh01Dk9u/ELFoD2a7ql1vlud7b1kRPTFrsxp5VgCz0lbQ ytL+NUU451ZrK9acxsvNXDjw4rzGMFg0RCncISH9B/Y/Knxmv3boDXXI96G2Ivh4oYlB2EBUX7KN B9IF0g6OoHGygzaYNClr2qx10lbLN+sL7nQLvieMrSU7i7/PaeyiOXPZObl4kcbOLOzY2o4tNDV4 9mSKwtA4P8gYx5jPZOUvWXx0Dxy9Bd8MJkxJE0zwnUpg6KEHJg8g+S1Hs3TjLwAAAP//AwBQSwME FAAGAAgAAAAhAPsqtO58BAAAYwwAABEAAAB3b3JkL3NldHRpbmdzLnhtbJxX227jNhB9L9B/MPRc x7qRUoR1Frq2WyRtsd79AEqibSGiKFC0nfTrO9Ql3mwmi0WfTM3MmTs54w8fn0S7OnM1NLLbWs6N ba14V8m66Q5b6+uXYh1aq0Gzrmat7PjWeuaD9fHu118+XKKBaw1iwwpUdEMkqq111LqPNpuhOnLB hhvZ8w6Ye6kE0/CpDhvB1OOpX1dS9Ew3ZdM2+nnj2ja1ZjVya51UF80q1qKplBzkXhtIJPf7puLz z4JQP2N3QmayOgne6dHiRvEWfJDdcGz6YdEm/q82CPG4KDn/KIizaBe5i2P/SHIO9yJV/YL4GfcM oFey4sMABRLtFK5gTfeixvHfKHpJ9Q2kejPZ3hhVAHfs8XT1fGjf4JFqT1W8b0rF1FRmaADjhaii T4dOKla20FQXx7fuoKP+lVKsLlHPVQVFgnb0qLUxDAhG7neaaQ7soedtO/Zn1XIGyi7RQTEBnbW1 JsqI0YpVj5/5uTGtPYykmu/ZqdVfWLnTsgfcmUEYgWtPVqojA4zmatezCgykstNKtotcLf+SOoXG VZDXGTG2sfFwaujddCUA0TEBgU3Uuc0fZM2NsyfVvMndu7k3gNFLxzUmN4slYxMubT0sh89S6kXW tkPPdUk4OWnErhzbsym5RTm+n7s+xnE8xw5H+5PRqzaHunGK2nFoEDoxqi0hhZNhHDcI/CnO7+24 BVhCPfBsl8RoPB4g4hSz41MKaUA5sW/nqG9+QdKYYBhiewUtUI7jeB6aAxIEXpijmIySAvWA+m7m JxiGEhJSHHNLXIpmh6Ykv52v1+sOobkbEDTSICChh9oJEqgCmoMgpX7gYF4HGfEo2jvvd2946yQE 9eA2d9Mc9Tr2A3AP8yDOvDxBqxAXxLHRvCUJDV20pimUIfExO5lNXYpzqOOmHopJgzhAfcsy8s7d zrIgzlBM7noxXrncowl+F3IC3Yt2SB7S2EVrmt8SmqK5zhPfwzGFFyRBgOWg8O2Aoje4IHBNcQ51 /Qz1raA0dNAeLWLfw+9ckQZhMfoGL+/83orIjPp/1N2H6VTAmFiJ6ZVOmShVw1YPZhmA91pEpXpM mm7hlxyWIf4tZ3cqF+Z6PTEGwdq2gFG0MManSkR1M/QZ349q2wemDle9s4RCqTD2/nzRZSYrV78r eeonaxfF+k9dDeTFnOP7s76m0/eNWOjDqdwtqA4G+jesU1f/fVZG4eaankukYQ/kJj/3rDssU4N3 6687IwqzrFU7syvyB9b3MHFBpDw4W6ttDkftmNmn4auGnXH8KA/uzHNHHnwZ3vjBKhMZSM8HIzAd QWo+XGneQvOuNNiIJjn/SiMLjVxpdKHBznqJjs+wrsA68ggzfTka+l62rbzw+o+FuLXekKYkDEfW c6irWU1gnMtoJMy7yrA6R/wJdiFeNxpW8b6pBXuC1ch2x6s5S7fsWZ70K1mjyQj3r6irmmkG8LFU r8DjcvGdL5eo5lUD7bh7FuV1E7qZHG+bQe94D0uTlgpCHveU30bN138Hd/8BAAD//wMAUEsDBBQA BgAIAAAAIQDIgcGe9ggAAOJCAAAPAAAAd29yZC9zdHlsZXMueG1szFvfc5tGEH7vTP8HhvdElmRL iadKJ5btxjNpmkb29PmETtZNgFMBxXH++u7twQmBELuGzPRJ5uD225/fIvn2t9+/R6H3TSap0vHM H74+8z0ZB3ql4seZ/3B/++qN76WZiFci1LGc+c8y9X9/9+svvz1dptlzKFMPBMTpZRTM/E2WbS8H gzTYyEikr/VWxnBzrZNIZHCZPA4ikXzdbV8FOtqKTC1VqLLnwejsbOLnYhKKFL1eq0Be62AXyTjD /YNEhiBRx+lGbdNC2hNF2pNOVttEBzJNwegotPIioWInZnheExSpINGpXmevwZiB1WhgRMH24Rn+ FYW+FwWXd4+xTsQyBOc9Dc/9d+C5lQ6u5Vrswiw1l8nnJL/Mr/DjVsdZ6j1dijRQ6h5cCgIiBbI+ vI9T5cMdKdLsfarE0Zsb89TRO0GalaRdqZXyBwYx/QEyv4lw5o9GxcrcaHCwFor4sViT8auHRVmT me+WliB35ovk1eK9ETZAM4vPkrnbA+PhClXZigCCAThinUlICsgRgxMqk4OjKeSLvfiyM34Vu0zn ICgAwMpi4bLiccgVyJyFTWC4K9cfdfBVrhYZ3Jj5iAWLD3efE6UTSNKZ//atwYTFhYzUB7VaSVMv +dpDvFEr+c9Gxg+pXO3X/77F5M8lBnoXZ6D+ZIpZEKarm++B3Jq0BdGxMBH+ZDZA4kA4Sjio0E7t tbELFVRc/LeAHNoYHkXZSGEq3EP9TwKh1bvOQCNjUdkAlMvSddxdxHl3ERfdRWDydvPFtLsWwOtd I2Jzo5SV9KBmOrDJV/bD+O2JlDU7alnUuqOWNK07ajnSuqOWEq07ahnQuqMW8NYdtfi27qiF8+SO QCBxVbNojN4gFfa9ykJp9p8koGFHqstbjfdZJOIxEduNZxprVe1TZLnYLTOaqkinLyfLRZbo+LHV I9CdTem+mJNvou1GpAreklpcP+ro+nvz1uP9kahVK9SFTb6aTfhicrSFfQ5FIDc6XMnEu5ffbUQZ +z9pb2HfMlqV6xjWj+pxk3mLDbbcVrBJg9ObPWHlf1Qp+uBkMU0aTGkTTorhpCEvm4X/KVdqFxWu IbyNTCyfM8JcgUAVT7vo3ISoXl2tVpgAUEyw7YJvAson6G+bC1++iTFFf9uKXiifoL9tXC+Uj/lx Or5sprmGL60eqbym7Nqd61An611Y1EArPUzZFewgaCawi9jJJ5HElF3BB/TpvQ8C+OZGyVN2LPY8 ykBhh8OiYLHRbWEHpUJ7Q4ZF7ABVsEYMrG5cywBik+4X+U2Z38S4zQBZ2r1rtpbzuMED0IJI79B/ 73TW/g49auA8KspdDD+XpNKjoY0bKo+KlueT7XeMGHdrfAygbh2QAdStFTKAGvKj+Z3H9UQ6SPfm yMBi07LrYph2ZGaespnZAfFaQE99k/D+1VC9zblQ75sEFHaA6n2TgMKOTqWXub5JwOqtbxKwGrpG c4zKnMoxit03y0DuTYBgUT/kTQDqh7wJQP2QNwGoO3m3g/RH3gQsNjc4Ti2TNwEIH+F81XdAZfIm ALG5wbJd/ptR0fdQyukvtz2QNwGFHaA6eRNQ2NFpIm8CFj7CyYQKlqM6AlY/5E0A6oe8CUD9kDcB qB/yJgD1Q94EoO7k3Q7SH3kTsNjc4Di1TN4EIDY9OKAyeROA8BEONxwlb6z6n07eBBR2gOrkTUBh R6dCqO4llYDFDlAFy5E3AQsf4SRDjoXJzTGqH/ImWNQPeROA+iFvAlA/5E0A6k7e7SD9kTcBi80N jlPL5E0AYtODAyqTNwGIzQ1HyRuL8aeTNwGFHaA6eRNQ2NGpEKrjOQIWO0AVLEfeBCzMl87kTQDC R14KxLGoH/ImWNQPeROA+iFvAlB38m4H6Y+8CVhsbnCcWiZvAhCbHhxQmbwJQGxuOEreWCM/nbwJ KOwA1cmbgMKOToVQHXkTsNgBqmA5qiNg9UPeBCBMzM7kTQDCR14AhFXECVM/5E2wqB/yJgB1J+92 kP7Im4DF5gbHqWXyJgCx6cEBlcmbAMTmBnPOFs6Lko+nDhuSgHrOoDjVQAYcNQSJCpgb+EWuZQJD VrL9dEhHwMJCBmJDelBNvNL6q0c72D1uSBAylFqGSuOR7mc8pVMaRBhPT0wS3P819z7YAZjaPkyp w5M3MD1UHhfC8SQzOAR6Zs9bGNnZFifLjTQYEDJzXfkIEI7I3cFAUD7WYzabOR94EIeq8mX8v22O in/DON6qeObs7GI6Hb+5yQecUGRdiWADWgQwK3VCifwovDudhAfhqyo1nJdHtfbDGoVy+bn5/duV fe7g9CYsgQ8b9M7MGfETOuMZ8pPe8/ARG++6gjC2hSq1aQjBXIZ2+Az+uIuN+2F8EP+fZsO8+i6s KLg/l2H4p8BRtUxvmx8N5Tqzd4dn2BsropY6y3TUvD/Bo+OoyTEB4NayMvbSGNHs73gXLWUCs18n fP5Jm56CM2qHyWpPwTakAtXTzbodFJIrHaOLS9maUtj99rdRt6WAIby/zExdrcjqCQIn8HBTc/lN ry/Gkzf2qXw+UWF+mOjO/CmMSaCEAOZKYBBhJ8J8sABWwdhiIrGhAI4bfSXCUOsYBxuqFZrfs1MP bQbDxOTXwhEloXOgC6t13SPUQMJE5wFN3U5G59c5IeR+SqtznFhP+RTnubs4PsWZT4zCx8Eo7My/ FxsdCZPAOORaXghSd4We2c+0DifW3vTHfqbVrkGMYAL3VNEckGuwS6FmF6YFVFm+6uBTkfP2Iajk 61GaRmsagskMZHPU0A3/A38fr4l5PnFW9WoxidZWCjEUZ1EK5cZbrwAYYkNhh9/NcKmZJm7Gkys4 +opP1dKfm/JLa8w8xc/ATAkUqp/fvhleXZvsxzFufD2HEWg8F1+0YzfJPcx56yDrca09649HAeau 1HFewjt8VnIC9wVRj8hLOWkyv7h5m1d+LSj5bLmjIRjNfjEnzUWolokqkVKxghEs+x++RsBau/+p rHPowGp17KPSlXEcTl4c7n27yMyGIB3yTTkiDXxTeA7k5gRfrJB9Cd7Ffpu++w8AAP//AwBQSwME FAAGAAgAAAAhAIKBfqjjBAAAtB8AABIAAAB3b3JkL251bWJlcmluZy54bWzMWd2OozYUvq/Ud4iQ ejkTQ4D8aDOrnWRSTbVdVd2pek2Ik6AFGxmSbG73ZfoIfax9hR5jwgQbsuAMam6GibGPz3d8fj4f 3r3/GoW9PWZJQMnUMO+R0cPEp6uAbKbGXy+Lu5HRS1KPrLyQEjw1jjgx3j/8/NO7w4TsoiVmMLEH MkgyOcT+1NimaTzp9xN/iyMvuY8Cn9GErtN7n0Z9ul4HPu4fKFv1LWSi7L+YUR8nCciZeWTvJUYu LlKl0RgT2GtNWeSlyT1lm37ksS+7+A6kx14aLIMwSI8gG7knMXRq7BiZ5ArdFQrxJROhUP44rWAK iop9xco59XcRJmm2Y5/hEHSgJNkG8SsMXWkAcXtSaX8JxD4KT/MOsWkr+xWQm5zBnHkHOIpXgYq4 CmOsxKIoFHbg5/t6qrJEE10Ck58IF1Ho0ESF8p4nTSIvIIUYPdOcGxdC4hr//pXRXVyoEwfXSXsm XwpZPDJbaIbcLPLOoSWtBCih+3nrxdjoRf7keUMo85YhaHQw7R73SOMBsoW3TFLm+emnXdQr/Xpe TQ2UTSFJsIJ3ey+EEWdoodnYNPp8cbQL0+Aj3uPw5Rjj05ztccmC1e/8XcjfiblpFIenGe7T44eh +fgk3oR7/iKAB98R/k3jEJIMstEYIbTIdIBcx9LT8nx3SHSLqBhcYT+IvHwzkPWCvxbvfjHvi61+ 809iQrxOxXD8B+NwAsJx8uGpMXAzVbYe2WQ5l/8GzP3DJJsMT9iDLzrX3pS1N8fZCKQiyEB7sL3Z EE1ID5h9xGmKWaF5CZHVGpGJRhqQLAXS4zWQ/qSRR6oRDaoQsWCzrT8kc4TKkGDgx6c0kCGBj3Gv a39KF33OrsJz0ecsxyrDaeR0tgynO6dzWkMaWLYGJEeB1JXTuVWILjvdYCylhkZOB8RHSWwdON2w Cs9Fp7NdnbQwlOF053Sj1pAcW0oLjeIIGHX5hMyunG5cheiy07mmlBpqnA7q0llF/2GBF+WoVODn 7mL4OLZEjtYt8LMhQrP5k1tkejBtXYFvWhKXuzDEeS2Q6vv3b/8WOzWs70Bj+HnX1ffDhAlOwBaU pAnM9BI/AGr4+RgtKRB7WPoB7FYaCAgQhxVee0B98jKUSWlIFpAoTO3L0AXL0LZ2Me3LCbvWMDO6 YwFmvU/4cGYdadQHPisNbdtZTeEjSBSLN7Xa92//tLWbZUpVQco5tXb7G+glv9bDzbTwqfJYOwOp 7Eaw0jc2UOuAs0aX60ytgd4u4hSmdBMRB46il4rkQBL5SBq9PuIUMnYjEWcPNFN4ObqE1cpj7SJO pXa3EXEO3KD/5xqn0MSbiDhnqJmrpdjKGYA0en3EKUz0RiLOtTVTeDm6dCKuJa+1lMbVAJkjUH8k 6rour3Xmi9l8scilnLd+ski7hcbV0M3yUR2xbchFu7vOaTSu7JEGJIUodnad02hcWRb/EnJ2/ai5 zpXbiyq1W3AhN9C4GltlOBL5rXY6hY5153QajSvX1oCkcKXOnE6jcWUPpNTQyOkyK0iJrQOna9+4 cpBOWlAYSXdOp9G4GklpoVEcKXShM6fTaVw5UmqocTq1wMPnHfAz+Mu/RIkm0Vlr65l/qhGfpPJW C8zk/a7SMsEDKpdlH5Fg16plg4w+VC7LGmOnZeIpvrY//AcAAP//AwBQSwMEFAAGAAgAAAAhAM6d hOHhAAAAVQEAABgAKABjdXN0b21YbWwvaXRlbVByb3BzMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAnJDBSsQwEIbvgu8Q5p5NbbY1XZou1aWwV1HYazZN20CTlCQV RXx3UzytR0/DN8PM9zP18cPM6F35oJ3l8LDLACkrXa/tyOHttcMMUIjC9mJ2VnGwDo7N/V3dh0Mv ogjReXWOyqDU0KmeTxy+nqqq7CrW4fy5LPCedgVm7Z5iRkva0vyxLSj7BpTUNp0JHKYYlwMhQU7K iLBzi7JpODhvREzoR+KGQUt1cnI1ykaSZ1lJ5Jr05mJmaLY8v9svagi3uEVbvf6v5aqvs3ajF8v0 CaSpyR/VxjevaH4AAAD//wMAUEsDBBQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAgBY3VzdG9tWG1s L19yZWxzL2l0ZW0xLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA hM/BigIxDAbgu+A7lNydzngQkel4WRa8ibjgtXQyM8VpU5oo+vYWTyss7DEJ+f6k3T/CrO6Y2VM0 0FQ1KIyOeh9HAz/n79UWFIuNvZ0pooEnMuy75aI94WylLPHkE6uiRDYwiaSd1uwmDJYrShjLZKAc rJQyjzpZd7Uj6nVdb3T+bUD3YapDbyAf+gbU+ZlK8v82DYN3+EXuFjDKHxHa3VgoXMJ8zJS4yDaP KAa8YHi3mqrcC7pr9cd/3QsAAP//AwBQSwMEFAAGAAgAAAAhANq9LrTsAQAA6gMAABAACAFkb2NQ cm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFPLbtswELwX 6D8Iuse0HDUPg2ZQOChyaBsDVpIzQ61sohRJkBsj7td3KcUO3fYUnfal4XB2yG9ee1PsIETt7KKs JtOyAKtcq+1mUT40386uyiKitK00zsKi3EMsb8TnT3wVnIeAGmJBEDYuyi2inzMW1RZ6GSfUttTp XOglUho2zHWdVnDr1EsPFtlsOr1g8IpgW2jP/BGwHBHnO/woaOtU4hcfm70nwoI30HsjEcTPRMdw dizwxqE0je5BVLNrahxTvpIbiGLG2RjwJxfaKC6vas7GkC+3MkiFJJ+o6wv6Oyvwr94brSSSsuKH VsFF12FxP2hQJADO8hFOuqxBvQSNezHlLE/5d22JyvklZ2NE3ILcBOm3UVQ0nKV8raSBJV1fdNJE 4Oy9wO9AptWupCbKfIfzHSh0oYj6Ny13VhbPMkISbVHuZNDSIomXxsZkiI2PGESj0RA29cZ8CPOx PNa1qIYBCk4HE8DIgRqn7IYT4n1Hd8P/kK1ysgOHkWpGJwuPZ/yFunS9l3YvljoqV6z3EaGPtMe3 chL+V3zwjbtN7nkT9LSYueBJ43btpaJdfZnV57kfshZfk22gpQUfAN8L/I7EDyadSl6yG2gPM/82 ksMex6crqnoypW+w1KFGtji+KfEHAAD//wMAUEsDBBQABgAIAAAAIQCpyFyqjAAAANoAAAATACgA Y3VzdG9tWG1sL2l0ZW0xLnhtbCCiJAAooCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACySbIKzi8tSk4tVghOzUlNLklNCS6pzEm1VYpxDHDUiwj2UVIAC/gl5gIFgWJKChW5OXnFVkm2 ShklJQVW+vrFyRmpuYnFevkFqXlAubT8otzEEiC3KF0/Py0tMznVJT+5NDc1r0TfyMDATD8pMykn Mz+9KLEgoxJqGFWMsrPRh3vGjpcLAAAA//8DAFBLAwQUAAYACAAAACEAh/kA62YCAADLCAAAEgAA AHdvcmQvZm9udFRhYmxlLnhtbNSWXW/aMBSG7yftP0S+L3FMoIAKVcuKtJtdbEy7NsYh1vwR2YaU f7/jJIS2hA20D2kgCLy2X+xH7znh7v5ZyWjHrRNGT1HSwyjimpm10Jsp+rpc3IxQ5DzVayqN5lO0 5w7dz96/uysnmdHeRbBeu4liU5R7X0zi2LGcK+p6puAaBjNjFfXw1W5iRe33bXHDjCqoFyshhd/H BOMhamzsJS4mywTjHwzbKq59tT62XIKj0S4XhTu4lZe4lcauC2sYdw7OrGTtp6jQrU2Snhgpwaxx JvM9OExc7ygOVrA8wdUnJVGk2OTjRhtLVxLYlUmKZg24qJxoqkD8slcrIyu9oNo4nsDQjsopwgN4 JjgY3uIhXAf4FsXBgOXUOu7biaSWM6qE3B9UaxTV9UAhPMsP+o5aEfZTDzmxgYGtW2H4weaBaiWB PLxWyMmc/muFVT6jF6tAAZ/WGbYf18k5AbEUirvoEy+jz9XOw4S3RAhQGOI+kEjhReBT2k0E/xki T7Bx8rBYHInMQbkdpUmjHImMG6WTSHX+pPa5nMjcbK3gNjDpzAeBXPTxGDiEbBBgcg0NZdbcdgUk E898fZqOsyz6/4LFNyjO0JRcJ4nBIWDHa3cuOiuFbr2pp/8XhTKnUqys6ARB8KKKQohECuGA924Q nQXiSuHcVSRCKDB5WSApCA/zVjkWyKFkflIg46rQLi+QJc2hVZwB8QidIiAIvSL9+yCgVZKn9tjQ 80KnGOLB49vqIL/qFAm+vlNQBYk4RyL0yppD6J3XReL6u0h3JHDasjlGAv5sVPee34lEcztxsx8A AAD//wMAUEsDBBQABgAIAAAAIQAuR3bC7AEAALYMAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWzs V01v2zAMvQ/YfzB0b2zFij+COgWCosOAbiu2bndFVhJhkmhISrz014+x2y5rd0gOwXrwwTBFkc+k nijRl1e/jI620nkFtiJ0lJBIWgG1squKfL+/uShI5AO3NddgZUV20pOr2ft3l+20lYtvMgS09BGi WD81oiLrEJppHHuxlob7ETTS4uQSnOEBh24VG+5+bpoLAabhQS2UVmEXj5MkI48w7hgUWC6VkNcg Nkba0PnHTmpEBOvXqvFPaO0xaC24unEgpPeYj9E9nuHKPsNQ9grIKOHAwzKMMJm4jyjeQ6E7TTrJ aBIZMf24suD4QuMKtpSRGS5frbb+8R21U1VXhDFWjguapt38Aurdtdri3JZrpIbEe2tcvFu5DE/a 5Fn7Va3W/1DfQ/Padg4hgHmhx3jmtdt/I/zxsUg6QUP/UBHcGig0XGASnSxAA3LFNwH6MPRBZKd5 Lv6K6DRfd5j5Ka5xR0KXdC++oGOSF2nJaDnQccomOBsdBcuySUHpQMdboCOnjGZplg/VcdIRea7q KPNxmeTpOBuq4y1UB6XlBB+W9nf9cJcf2UGcqzxoVrJ8TDM2HFf/7bjqe6yu54UmKKMe5A24uYPW S9c1t9i/777YH59uuxHXGtq7zx9wgK4Hfxuz3wAAAP//AwBQSwMEFAAGAAgAAAAhAEB0T8d5CQAA 00UAABoAAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbMxbbW/bNhD+PmD/QdD3NH5J7DaYOzRO sgbotq5OsM+0TMdEJFGT5KTZr9/xSNGyZFlHSwX2KTEl3nOvz9EJ75dfv0eh98LTTMh45g/fDXyP x4Fcifhp5j8+3J29970sZ/GKhTLmM/+NZ/6vH3/+6ZfXqyx/C3nmgYA4u3pNgpm/yfPk6vw8CzY8 Ytm7SASpzOQ6fxfI6Fyu1yLg568yXZ2PBsMB/pakMuBZBmhzFr+wzDfioro0mfAYsNYyjVievZPp 03nE0udtcgbSE5aLpQhF/gayB5NCjJz52zS+MgqdWYXUliutkPlR7EhrVhzA1TtvZLCNeJwj4nnK Q9BBxtlGJDszTpUGJm4KlV6OGfEShcV7r8nwooZnTabE4CZlrxCKncCauAPOWOlNUaj9oOK7i2pV 4nBwzBgTESXC6kBRYR+z0CRiIrZiTnNN2blQD13y+7dUbhOrTiK6SbuPn60sVZYOmg0mWHll0zIn AbXSXWxYwn0vCq7un2KZsmUIGr0OLzyVkf5HoIqVDG74mm3DPFMf06+p+Wg+4Y87GeeZ93rFskCI B6AQkBIJEPj5U5wJH55wluWfMsEOPtyotw4+CbK8JO1arIR/rhCzf0HmCwtn/mhUrMyVBntrIYuf ijUenz0uyprMfLu0BLkzn6Vni09K2DmaWfwsmZvsGQ+fUJWEBVB5gMPWOQcSAhZTOKFQ0R1NgdH0 h29b5Vy2zaUBQQEAVhYLHyseB24CplpoxoanfP1FBs98tcjhwcxHLFh8vP+aCpkCjc78Dx8UJiwu eCQ+i9WKqwZh1h7jjVjxvzc8fsz4arf+1x3Ss5EYyG2cg/qTKWZBmK1uvwc8UTQJomOmIvyH2gAc BuEo4aBCW7HTRi9UUHHxnwJyqGN4EGXDmWppHup/FAit3nYGGimLygagXCddx91FXHQXcdldBCZv N19Mu2sBB5muEdG5UcpKelBzGejkK/th/OFIyqodtSxq3VFLmtYdtRxp3VFLidYdtQxo3VELeOuO Wnxbd9TCeXRHwJC4qlk0Rm+QCvtB5CH0yRamG3akOtNqvK8sZU8pSzaeaqxVtY+R5WK7zGmqIp2e TpaLPJXquNniEejOqnRP5uTbKNmwTMCpvA2oo+sf1NHH+y0VcHxtgbrUyVezCQ8mB1vY15AFfCPD FU+9B/5dR9Rh/x/SW+hTRqtyHcP6RTxtcg9OharltoJNGpze7Akt/4vI0AdHu/mkwZQ24aQYThry sln473wltlHhGsJpZKL53CHMFQhU8biLLlSI6tXVaoUKAMUE3S7cTUD5BP11c3GXr2JM0V+3ohPl E/TXjetE+Zgfx+PrzDQ38GcVj1ReU+fanctQputtWNRAKz1MnSvYQtBMcC5iK59EElPnCt6jT+9T EMA3N0qeOsdix6MOKM7h0ChYbHRbnINSob2hg0XOAapgjRywunGtA5Az6X7jL0L9Edi1GSBL27Nm azmPGzwALYh0hv5rK/P2M/SogfOoKPcx/Lkk4x4NbdxQeVQ0k0+63znEuFvjcwDq1gEdgLq1Qgeg hvxoPvPYnkgH6d4cHbCcadl2MUw7MjNPnZnZArm1gJ76JuH81VC9zblQ75sEFOcA1fsmAcU5OpVe ZvsmAau3vknAaugazTEqc6qLUc59swxkTwIEi/ohbwJQP+RNAOqHvAlA3cm7HaQ/8iZgOXOD5dQy eROA8BWXr/oWqEzeBCBnbtBsZ/5mVPQ9lHL8y20P5E1AcQ5QnbwJKM7RaSJvAha+4pIJFSxLdQSs fsibANQPeROA+iFvAlA/5E0A6oe8CUDdybsdpD/yJmA5c4Pl1DJ5E4Cc6cEClcmbAISvuHDDQfLG qv/h5E1AcQ5QnbwJKM7RqRCqPaQSsJwDVMGy5E3AwldcksFgYXK7GNUPeRMs6oe8CUD9kDcBqB/y JgB1J+92kP7Im4DlzA2WU8vkTQBypgcLVCZvApAzNxwkbyzGH07eBBTnANXJm4DiHJ0KoVqeI2A5 B6iCZcmbgIX50pm8CUD4yqlALhb1Q94Ei/ohbwJQP+RNAOpO3u0g/ZE3AcuZGyynlsmbAORMDxao TN4EIGduOEjeWCM/nLwJKM4BqpM3AcU5OhVCteRNwHIOUAXLUh0Bqx/yJgBhYnYmbwIQvnICEFaR S5j6IW+CRf2QNwGoO3m3g/RH3gQsZ26wnFombwKQMz1YoDJ5E4CcuUHds4X7ouTrqcOGJKDeMyhu NZABRw1BogIaA7/xNU9hqpC33w7pCFhY6IDYkB5UE6+lfPZoF7vHDQlChhLLUEi80v2Gt3RKgwjj 6ZFJgoc/595nPQBT24cptX/zBqaHyuNCOJ6kBodAz/wtgZGdpLhZrqTBgJCa6zIjQDgTeg8DQWas R21Wcz7wIg5VmWX8v61Bxd9h/nRVvDMYXE6n4/e3ZsAJRdaVCDagRQCzUkeUMFfh7e0kvAhfVanh vjyqtRvWKJQz9+Z3pyv93t7tTVgCHzbonas74kd0xjvkR73n4Ss63nUFYWwLVWrTEIK5DPXwGfxy Hyv3v5q5LR3m1XemRcHzOQ/D3xmOquUyaX415OtcPx0OsDdWRC1lnsuoeX+KV8dRk0MCwK1lZfRH ZUSzv+NttOSpuYjemKyqp+CM2n6y6luwDalA9XSzbnuFZEtH6WJTtqYUdr/dY9RtyWAI7081U1cr snqCwA083NRcftOby/HkvX7LzCcKzA8V3Zk/HQ30swDmSmAQYctCM1gAcsHYYiKxoQAOG33NwlDK GAcbqhVqnumphzaDYWLyuXBESegc6EJrXfcINZAw0blHU3eT0cWNIQTjp6w6x4n/nzZTnBf2w+Ep TjMxCj/2RmFn/gPbyIgp0sAh1/JCALO75jF6ZjfTOpxoe7N/dzOteg1iBBO4x4pmj1yDbQY1u1At oMryVQcfi5y3C0ElXw/SNFrTEEzHQDZHDd3wP/D34ZqYm4mzqleLSbS2UoihOItSKDfeegXAEBsK 2/9uhkvNNHE7nlzD1Vd8q5b+rim/1MbMM/wZqCmBQvWLu/fD6xuV/TjGjcdzGIHGe/FFO7aT3EPD W3tZj2vtWX84CjB3JQ7zEj5xZyUrcFcQ9YicykmT+eXtB1P5taCY2XJLQzCafTInzVkolqkokVKx ghEs+x++RsBau/+prLPvwGp17KLSlXEsjikOe94uMrMhSPt8U45IA98UngO5huCLFbIvwbvYb7OP /wEAAP//AwBQSwMEFAAGAAgAAAAhACkG9P2GAQAA8AIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIyST0/cMBDF70j9DpHvWdssVCjaDRK0 nIqoxKJW3Iw9LIb4jzwDId8eJ9kNBHHg5vF788vMc1anr64pXiChDX7N5EKwArwOxvrtmt1sLsoT ViApb1QTPKxZB8hO6x8HKx0rHRL8TSFCIgtYZJLHSsc1eyCKFeeoH8ApXGSHz+J9SE5RLtOWR6Wf 1Bb4oRA/uQNSRpHiPbCME5HtkEZPyPicmgFgNIcGHHhCLheSv3sJksMvGwblg9NZ6mLeaTfuR7bR ozi5X9FOxrZtF+1yGCPPL/n/yz/Xw6ql9X1WGli9MroiSw3UK/5+zCd8vnsETeP1VGRBJ1AUUn1u UYfiukMCh0PzXukzf4KuDclg7p9VGWAAdbKR8kuO9NlFdjcK6TI/7b0Fc9bVv5PVxRXeheRhoH3S +88leLH9r1EfDY6pzOsNaY5TgylyPtWY5l75tzz/tblg9aGQy1LIUsqNPKmOlpUQt/1as/4+r/HC 7Qb8DvG4JwoxJ+4BY0Lzf7R+AwAA//8DAFBLAQItABQABgAIAAAAIQBJn4PiqwEAAJcGAAATAAAA AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAB6RGrfzAAAA TgIAAAsAAAAAAAAAAAAAAAAA5AMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhACpCyRBDAQAA zAQAABwAAAAAAAAAAAAAAAAACAcAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAU AAYACAAAACEAfr8xqugRAABMQQAAEQAAAAAAAAAAAAAAAACNCQAAd29yZC9kb2N1bWVudC54bWxQ SwECLQAUAAYACAAAACEAMN1DKagGAACkGwAAFQAAAAAAAAAAAAAAAACkGwAAd29yZC90aGVtZS90 aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAPsqtO58BAAAYwwAABEAAAAAAAAAAAAAAAAAfyIAAHdv cmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAMiBwZ72CAAA4kIAAA8AAAAAAAAAAAAAAAAA KicAAHdvcmQvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQCCgX6o4wQAALQfAAASAAAAAAAAAAAA AAAAAE0wAAB3b3JkL251bWJlcmluZy54bWxQSwECLQAUAAYACAAAACEAzp2E4eEAAABVAQAAGAAA AAAAAAAAAAAAAABgNQAAY3VzdG9tWG1sL2l0ZW1Qcm9wczEueG1sUEsBAi0AFAAGAAgAAAAhAHQ/ OXrCAAAAKAEAAB4AAAAAAAAAAAAAAAAAnzYAAGN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVs c1BLAQItABQABgAIAAAAIQDavS607AEAAOoDAAAQAAAAAAAAAAAAAAAAAKU4AABkb2NQcm9wcy9h cHAueG1sUEsBAi0AFAAGAAgAAAAhAKnIXKqMAAAA2gAAABMAAAAAAAAAAAAAAAAAxzsAAGN1c3Rv bVhtbC9pdGVtMS54bWxQSwECLQAUAAYACAAAACEAh/kA62YCAADLCAAAEgAAAAAAAAAAAAAAAACs PAAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAC5HdsLsAQAAtgwAABQAAAAAAAAA AAAAAAAAQj8AAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAEB0T8d5CQAA00UA ABoAAAAAAAAAAAAAAAAAYEEAAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMueG1sUEsBAi0AFAAGAAgA AAAhACkG9P2GAQAA8AIAABEAAAAAAAAAAAAAAAAAEUsAAGRvY1Byb3BzL2NvcmUueG1sUEsFBgAA AAAQABAAHAQAAM5NAAAAAA== --_002_20ECF67871905846A80F77F8F4A27572100A173Fxmbrcdx09ciscoc_-- From lucy.yong@huawei.com Tue Jan 15 12:20:39 2013 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 EB09421F84F9 for ; Tue, 15 Jan 2013 12:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.364 X-Spam-Level: X-Spam-Status: No, score=-6.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 1fJoqkofLXUR for ; Tue, 15 Jan 2013 12:20:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4866A21F84BA for ; Tue, 15 Jan 2013 12:20:31 -0800 (PST) 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 AOU55748; Tue, 15 Jan 2013 20:20:29 +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, 15 Jan 2013 20:20:18 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Jan 2013 04:20:26 +0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Tue, 15 Jan 2013 12:20:21 -0800 From: Lucy yong To: "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: [mpls] working group last call Thread-Index: AQHN8kOjNM8rY2JDFUmNbqQD1YOrLZhK1Vyw Date: Tue, 15 Jan 2013 20:20:21 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4487679C@dfweml505-mbx> References: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> In-Reply-To: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.88.216] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: Re: [mpls] working group last call 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, 15 Jan 2013 20:20:39 -0000 I support this. The document is well and clearly written. One comment: in section 3.3.1, it= is better to give some recommendation or options regarding how to provide = timing to BTS. This is important for 2G/3G backhaul. Cheers, Lucy=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > loa@pi.nu > Sent: Monday, January 14, 2013 4:41 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-use-cases-and- > design@tools.ietf.org > Subject: [mpls] working group last call >=20 > Working Group, >=20 > this is to start a two week Working Group last call on > draft-ietf-mpls-tp-use-cases-and-design. >=20 > This is the second time we working group last call this > draft, it has been updated after comments during the > ADE-review. The changes are such that we have decided to > do a full two week wglc. >=20 > Please send your comments to the mpls working group > mailing list (mpls@ietf.org). >=20 > Please send both technical comments, and if you are happy > with the document as is also indications of support. >=20 > There are no IPR claims against this draft. >=20 > All the co-authors has stated that they are not aware > of any IPRs. >=20 > This working group last call will end on January 25, 2013. >=20 > /Loa > for the wg co-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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Wed Jan 16 01:46:31 2013 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 4773621F8615 for ; Wed, 16 Jan 2013 01:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 fuSx7MuNRrsi for ; Wed, 16 Jan 2013 01:46:30 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 80D8E21F868F for ; Wed, 16 Jan 2013 01:46:30 -0800 (PST) Received: from [192.168.1.104] (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 B9A2B823B5; Wed, 16 Jan 2013 10:46:27 +0100 (CET) Message-ID: <50F676F3.20200@pi.nu> Date: Wed, 16 Jan 2013 10:46:27 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 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" Subject: [mpls] Change of affiliation 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, 16 Jan 2013 09:46:31 -0000 Working Group, January 15 was my last day at Ericsson. I've decided to re-start my own consultancy company, and as part of this I plan to stay as MPLS working group co-chair. Huawei Technologies has agreed to support my activities in IETF and other standards undertakings. When acting as working group chair I will continue to use my loa@pi.nu mail address, for all other standards address I will use the Huawei address (loa@mail01.huawei.com). /Loa -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From daniel@olddog.co.uk Wed Jan 16 02:42:38 2013 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 619E121F85E8 for ; Wed, 16 Jan 2013 02:42:38 -0800 (PST) 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 FX30AHGMfJGu for ; Wed, 16 Jan 2013 02:42:37 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 517F921F85DF for ; Wed, 16 Jan 2013 02:42:36 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0GAgS9q015392; Wed, 16 Jan 2013 10:42:28 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0GAgQ6m015384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Jan 2013 10:42:27 GMT From: "Daniel King" To: "'RFC Errata System'" , , , , , , References: <20130110174041.5EBC9B1E002@rfc-editor.org> In-Reply-To: <20130110174041.5EBC9B1E002@rfc-editor.org> Date: Wed, 16 Jan 2013 10:42:25 -0000 Message-ID: <002001cdf3d6$2d26c980$87745c80$@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: AQHnBHqqEQURImSl1gYDq0q74FmuRJgZoaiw Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC6639 (3450) 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, 16 Jan 2013 10:42:38 -0000 We (the authors) accept the errata and agree to the proposed text update. Br, Dan. -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] Sent: 10 January 2013 17:41 To: daniel@olddog.co.uk; venkat.mahalingams@gmail.com; stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; rcallon@juniper.net Cc: ietfc@btconnect.com; mpls@ietf.org; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC6639 (3450) The following errata report has been submitted for RFC6639, "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6639&eid=3450 -------------------------------------- Type: Editorial Reported by: tom petch Section: 4.2.9 Original Text ------------- The mplsOutSegmentPerfTable [RFC3813] contains statistical information (total packets received, total errored packets received, total packets discarded, discontinuity time) for outgoing MPLS segments from an LSR. Corrected Text -------------- The mplsOutSegmentPerfTable [RFC3813] contains statistical information (total packets sent, total packets that could not be sent due to errors, total packets discarded, discontinuity time) for outgoing MPLS segments from an LSR. Notes ----- mplsOutSegmentPerfTable is for segments sent, current text relates to segments received. 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. -------------------------------------- RFC6639 (draft-ietf-mpls-tp-mib-management-overview-08) -------------------------------------- Title : Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview Publication Date : June 2012 Author(s) : D. King, Ed., M. Venkatesan, Ed. Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From agmalis@gmail.com Wed Jan 16 03:19:46 2013 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 640A221F86CD for ; Wed, 16 Jan 2013 03:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, 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 7MYwKgtdF9Lt for ; Wed, 16 Jan 2013 03:19:45 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id A515721F86C2 for ; Wed, 16 Jan 2013 03:19:45 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id hg5so3208138qab.8 for ; Wed, 16 Jan 2013 03:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=58tjkup5xwYP4rZc5VF7If98w5h65ECiarMGp4sM/1w=; b=OI5sz1s4qMvLHa8avCjCBjGXJbBaAu5pCIOCcFOlPCan6RuB68Wo7htVfFeaEjNHCf 5LMggn/QahpLvrXoFVVJM2WnA03qReQMEOAtSxMyPsq2k23lY1WaGHHfPqKWJn30X8ao SSUdT29bA3W8afp8cKQIjEwrJ+TdIq/csDHdKHWf6YISBTGh5Km8Zh5jb3n2WVMxKbsU zsrWNuPXujO3YLtzkT6OHLfAxqTKOSMjSj/FH3lXYRsAekdJfWRI+kQjtWGv1sKYxJdc y5Z0hugeJ+1ud3n/KHbaU2y/U3hRZmTiRwDLXLbAD9p7Bzo4lcvzsNycwnyExydmH4TY Vnlg== X-Received: by 10.49.121.40 with SMTP id lh8mr884842qeb.30.1358335185031; Wed, 16 Jan 2013 03:19:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.78.72 with HTTP; Wed, 16 Jan 2013 03:19:24 -0800 (PST) In-Reply-To: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> References: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> From: "Andrew G. Malis" Date: Wed, 16 Jan 2013 12:19:24 +0100 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7bdc1be430938504d3660eb5 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] working group last call 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, 16 Jan 2013 11:19:46 -0000 --047d7bdc1be430938504d3660eb5 Content-Type: text/plain; charset=ISO-8859-1 This draft has very useful use cases and is ready for forwarding to the IESG. On Mon, Jan 14, 2013 at 11:40 AM, wrote: > Working Group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-tp-use-cases-and-design. > > This is the second time we working group last call this > draft, it has been updated after comments during the > ADE-review. The changes are such that we have decided to > do a full two week wglc. > > 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. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not aware > of any IPRs. > > This working group last call will end on January 25, 2013. > > /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 > --047d7bdc1be430938504d3660eb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This draft has very useful use cases and is ready for forw= arding to the IESG.


On Mon, Jan 14, 2013 at 11:40 AM, <<= a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu> wrot= e:
Working Group,

this is to start a two week Working Group last call on
draft-ietf-mpls-tp-use-cases-and-design.

This is the second time we working group last call this
draft, it has been updated after comments during the
ADE-review. The changes are such that we have decided to
do a full two week wglc.

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.

There are no IPR claims against this draft.

All the co-authors has stated that they are not aware
of any IPRs.

This working group last call will end on January 25, 2013.

/Loa
for the wg co-chairs

--


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

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

--047d7bdc1be430938504d3660eb5-- From nurit.sprecher@nsn.com Wed Jan 16 03:35:23 2013 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 CE93D21F86FF for ; Wed, 16 Jan 2013 03:35:23 -0800 (PST) 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 gzuyB3zDI3zB for ; Wed, 16 Jan 2013 03:35:22 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id DA24D21F86C0 for ; Wed, 16 Jan 2013 03:35:13 -0800 (PST) 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 r0GBZBaQ014743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Jan 2013 12:35:11 +0100 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 r0GBZ8iG017847; Wed, 16 Jan 2013 12:35:08 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jan 2013 12:35:08 +0100 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_01CDF3DD.6C594BED" Date: Wed, 16 Jan 2013 12:34:19 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] working group last call Thread-Index: Ac3z22u83LT1+86qT8G53nhXTmRiVAAAf4ug References: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Andrew G. Malis" , "Loa Andersson" X-OriginalArrivalTime: 16 Jan 2013 11:35:08.0388 (UTC) FILETIME=[89813240:01CDF3DD] 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: 28040 X-purgate-ID: 151667::1358336111-0000215D-3741B4B9/0-0/0-0 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] working group last call 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, 16 Jan 2013 11:35:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDF3DD.6C594BED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Andrew G. Malis Sent: Wednesday, January 16, 2013 1:19 PM To: Loa Andersson Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] working group last call =20 This draft has very useful use cases and is ready for forwarding to the IESG. =20 On Mon, Jan 14, 2013 at 11:40 AM, wrote: Working Group, this is to start a two week Working Group last call on draft-ietf-mpls-tp-use-cases-and-design. This is the second time we working group last call this draft, it has been updated after comments during the ADE-review. The changes are such that we have decided to do a full two week wglc. 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. There are no IPR claims against this draft. All the co-authors has stated that they are not aware of any IPRs. This working group last call will end on January 25, 2013. /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 =20 +46 767 72 92 13 =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 ------_=_NextPart_001_01CDF3DD.6C594BED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On Behalf Of ext Andrew G. = Malis
Sent: Wednesday, January 16, 2013 1:19 PM
To: = Loa Andersson
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; = draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org
Subject:= Re: [mpls] working group last call

 

This = draft has very useful use cases and is ready for forwarding to the = IESG.

 

On Mon, Jan 14, 2013 at 11:40 AM, <loa@pi.nu> = wrote:

Working Group,

this is = to start a two week Working Group last call = on
draft-ietf-mpls-tp-use-cases-and-design.

This is the second = time we working group last call this
draft, it has been updated after = comments during the
ADE-review. The changes are such that we have = decided to
do a full two week wglc.

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.

There are no IPR claims against this = draft.

All the co-authors has stated that they are not = aware
of any IPRs.

This working group last call will end on = January 25, 2013.

/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

 

------_=_NextPart_001_01CDF3DD.6C594BED-- From prvs=8728ebc74c=hshah@ciena.com Wed Jan 16 06:16:15 2013 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 E779321F8936 for ; Wed, 16 Jan 2013 06:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 pomJQjuoh+T2 for ; Wed, 16 Jan 2013 06:16:14 -0800 (PST) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 3104E21F8935 for ; Wed, 16 Jan 2013 06:16:13 -0800 (PST) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id r0GEFkb8027308; Wed, 16 Jan 2013 09:16:13 -0500 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 19ww3yr6bv-21 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Jan 2013 09:16:12 -0500 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Wed, 16 Jan 2013 09:15:58 -0500 From: "Shah, Himanshu" To: "loa@pi.nu" , "mpls@ietf.org" Date: Wed, 16 Jan 2013 09:15:57 -0500 Thread-Topic: [mpls] working group last call Thread-Index: Ac3yQ6Q4DJjDoiYNSkinwu61vyyznwBsCzIw Message-ID: References: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> In-Reply-To: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-16_05:2013-01-16, 2013-01-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1211240000 definitions=main-1301160107 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: Re: [mpls] working group last call 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, 16 Jan 2013 14:16:15 -0000 No brainer. Absolutely support it. /himanshu -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of loa= @pi.nu Sent: Monday, January 14, 2013 5:41 AM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-use-cases-and-design@too= ls.ietf.org Subject: [mpls] working group last call Working Group, this is to start a two week Working Group last call on draft-ietf-mpls-tp-u= se-cases-and-design. This is the second time we working group last call this draft, it has been = updated after comments during the ADE-review. The changes are such that we = have decided to do a full two week wglc. 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. There are no IPR claims against this draft. All the co-authors has stated that they are not aware of any IPRs. This working group last call will end on January 25, 2013. /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 PPan@infinera.com Wed Jan 16 06:22:24 2013 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 8307521F8946 for ; Wed, 16 Jan 2013 06:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 aAeqQS37c-If for ; Wed, 16 Jan 2013 06:22:23 -0800 (PST) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id E831C21F8945 for ; Wed, 16 Jan 2013 06:22:23 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 06:22:23 -0800 From: Ping Pan To: "Andrew G. Malis" Thread-Topic: [mpls] working group last call Thread-Index: AQHN89t2gJTlwqdZdUSs1KWI+nQjT5hMAhUm Date: Wed, 16 Jan 2013 14:22:22 +0000 Message-ID: <9664F6FD-51A6-4689-98A8-25B8B410BBE0@infinera.com> References: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: Re: [mpls] working group last call 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, 16 Jan 2013 14:22:24 -0000 +1 On Jan 16, 2013, at 3:20 AM, "Andrew G. Malis" > wrote: This draft has very useful use cases and is ready for forwarding to the IES= G. On Mon, Jan 14, 2013 at 11:40 AM, > wrote: Working Group, this is to start a two week Working Group last call on draft-ietf-mpls-tp-use-cases-and-design. This is the second time we working group last call this draft, it has been updated after comments during the ADE-review. The changes are such that we have decided to do a full two week wglc. 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. There are no IPR claims against this draft. All the co-authors has stated that they are not aware of any IPRs. This working group last call will end on January 25, 2013. /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 huubatwork@gmail.com Wed Jan 16 06:39:20 2013 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 3F72921F89DC for ; Wed, 16 Jan 2013 06:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-1.170, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=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 br-NXLCHcSiY for ; Wed, 16 Jan 2013 06:39:19 -0800 (PST) Received: from mail-we0-x229.google.com (we-in-x0229.1e100.net [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 906C721F8991 for ; Wed, 16 Jan 2013 06:39:19 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t49so96919wey.28 for ; Wed, 16 Jan 2013 06:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received: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=qVvzoQ7RX+LL17hR47wMQmUMGVFij54IrHfAvibnlFg=; b=EL2mmE3s4OqxQ8jDz055AnGRLjTR8wxWc4vKejcRHoCYnurjLUeDfQE8Z7GYU4prFE lQk8CbNABMsqHB+i2pP4J9eP8j2ZBhoz555H8yaCYABvYBQDLi4yIN2kHfptjoNE+Inc FucL9P/c/yhebJj9RRCICRvcqJky7uExVN5svswpV3Z6KwO4fwuvqhWRszxeYREEKSe1 UX8w3Tejl2WLnfvi5rmf0kOGRLUvZ4J3UJc85o6Z1EfIRAKPRAzUdPIydK0szZUSbCr0 MjplIOa8QbrCvlY3PjVCXDIcx/1F7cdYfVHZTexkH+Vn2oz11NfuajZk7lvQJccXOL1K HN2Q== X-Received: by 10.180.101.99 with SMTP id ff3mr2642925wib.21.1358347158468; Wed, 16 Jan 2013 06:39:18 -0800 (PST) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl. [77.250.51.60]) by mx.google.com with ESMTPS id h19sm8569312wiv.7.2013.01.16.06.39.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 06:39:17 -0800 (PST) Message-ID: <50F6BB94.4000206@gmail.com> Date: Wed, 16 Jan 2013 15:39:16 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: loa@pi.nu References: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> In-Reply-To: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> 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-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] working group last call 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: Wed, 16 Jan 2013 14:39:20 -0000 Editors, You need to fix the acronym expansion for MEP and MIP: MEP Maintenance Entity Group End Point MIP Maintenance Entity Group Intermediate Point Regards, Huub. ====== > this is to start a two week Working Group last call on > draft-ietf-mpls-tp-use-cases-and-design. > > This is the second time we working group last call this > draft, it has been updated after comments during the > ADE-review. The changes are such that we have decided to > do a full two week wglc. > > 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. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not aware > of any IPRs. > > This working group last call will end on January 25, 2013. > > /Loa > for the wg co-chairs > From jeff.tantsura@ericsson.com Wed Jan 16 07:39:22 2013 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 8C20C21F8A0D for ; Wed, 16 Jan 2013 07:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=-1.782, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 bj0-g3WCiUaC for ; Wed, 16 Jan 2013 07:39:22 -0800 (PST) Received: from usevmg21.ericsson.net (unknown [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id DAC8921F8930 for ; Wed, 16 Jan 2013 07:39:21 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-83-50f6c9a87e65 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8F.8A.03705.8A9C6F05; Wed, 16 Jan 2013 16:39:21 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 10:39:20 -0500 From: Jeff Tantsura To: Loa Andersson Thread-Topic: [mpls] working group last call Thread-Index: AQHN8kOiFQSobSaV7EOt2HZ2m4zhMZhMJfcA///CgIA= Date: Wed, 16 Jan 2013 15:39:19 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C74839138E61@eusaamb109.ericsson.se> 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.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C74839138E61eusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonXHflyW8BBks2slqce/GX0eLf3DnM Ft8vLWGxuLV0JasDi8eSJT+ZPGZNb2Pz+HL5M1sAcxSXTUpqTmZZapG+XQJXxunv+9kLtmpV HPpwj6WB8btyFyMnh4SAicT+FzvZIGwxiQv31oPZQgJHGCUebqzvYuQCspczSlw/vZcRJMEm YCDx/9txFhBbREBW4tq2n0wgRcwC1xklLn47zw6SEBbQlpj06iMjRJGOxIz5G5kgbCuJzuP/ wZpZBFQlDj99DLaNV8Bb4s6kr6wgNqdAoMSc56eZQWxGoIu+n1oD1sssIC5x68l8JohLBSSW 7DnPDGGLSrx8/A+sV1RAT6Lt2Bl2iLiyxPc5j1ggevMlDt0+yw6xS1Di5MwnLBMYRWchGTsL SdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHgM1WstMf3dUyZkNQsYOVYxcpQWp5blphsZbmIE RuMxCTbHHYwLPlkeYpTmYFES5w11vRAgJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdF+twCT ltX2I+WZ1xa9ZmNQYM1fcHvp5X8JE2pO/OEK/1tgwpc7d/smN0YuhsdVT0M/hPrvP5s2bbX3 ipJbqzmeKL3r+sChq7Lvr8St1zHzokNNEr8GxDy4c/Hqy8KPhldSptb+mbOtm2vyuUOvqrbN ZZHXO1U7vbx0u2n6jEcp+/a9e3/m7O7pSizFGYmGWsxFxYkAVHKF9ZQCAAA= Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: Re: [mpls] working group last call 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, 16 Jan 2013 15:39:22 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C74839138E61eusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Very useful document, support Cheers, Jeff On Mon, Jan 14, 2013 at 11:40 AM, > wrote: Working Group, this is to start a two week Working Group last call on draft-ietf-mpls-tp-use-cases-and-design. This is the second time we working group last call this draft, it has been updated after comments during the ADE-review. The changes are such that we have decided to do a full two week wglc. 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. There are no IPR claims against this draft. All the co-authors has stated that they are not aware of any IPRs. This working group last call will end on January 25, 2013. /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 --_000_60DEDD93F5E54B4AB55647B8B6C74839138E61eusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <5162D43F67426B4B8340E1079138309E@ericsson.com> Content-Transfer-Encoding: quoted-printable
Very useful document, support

Cheers,
Jeff


On Mon, Jan 14, 2013 at 11:40 AM, <loa@pi.nu> wrote:
Working Group,

this is to start a two week Working Group last call on
draft-ietf-mpls-tp-use-cases-and-design.

This is the second time we working group last call this
draft, it has been updated after comments during the
ADE-review. The changes are such that we have decided to
do a full two week wglc.

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.

There are no IPR claims against this draft.

All the co-authors has stated that they are not aware
of any IPRs.

This working group last call will end on January 25, 2013.

/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
                     = ;                     &nb= sp;  +46 767 72 92 13

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

 --_000_60DEDD93F5E54B4AB55647B8B6C74839138E61eusaamb109ericsso_-- From loa@pi.nu Wed Jan 16 07:57:20 2013 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 C84A521F8ABD for ; Wed, 16 Jan 2013 07:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 fN89jtXgY4EY for ; Wed, 16 Jan 2013 07:57:19 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5290621F8AA8 for ; Wed, 16 Jan 2013 07:57:19 -0800 (PST) Received: from [192.168.1.104] (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 439AE823B5; Wed, 16 Jan 2013 16:57:17 +0100 (CET) Message-ID: <50F6CDDD.8010200@pi.nu> Date: Wed, 16 Jan 2013 16:57:17 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: multipart/mixed; boundary="------------080405040305090903090800" Cc: "" , "mpls-chairs@tools.ietf.org" Subject: [mpls] Proposed response to the P2MP liaison form 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: Wed, 16 Jan 2013 15:57:20 -0000 This is a multi-part message in MIME format. --------------080405040305090903090800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Working Group, please find attached a proposed response to the liaison on P2MP from ITU-T SG15. Please comment to the MPLS WH mailing (mpls@ietf.org) no later than Tuesday January 22, 3pm Central European time. The incoming liaison could be found at http://datatracker.ietf.org/liaison/1202/ /Loa for the wg chairs -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 --------------080405040305090903090800 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="LS392 full response v1.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="LS392 full response v1.docx" UEsDBBQABgAIAAAAIQDwIex9jgEAABMGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lE1PwkAQhu8m/odmr6Zd8GCMoXBQPCqJ GM/Ldgobux/ZWb7+vdMWGjRAUfDSpN193/fZ2c70BitdRAvwqKxJWTfpsAiMtJky05S9j5/j exZhECYThTWQsjUgG/Svr3rjtQOMSG0wZbMQ3APnKGegBSbWgaGV3HotAr36KXdCfoop8NtO 545LawKYEIfSg/V7T5CLeRGi4Yo+1yQeCmTRY72xzEqZcK5QUgQi5QuT/UiJNwkJKas9OFMO bwiD8b0J5crhgI3ulUrjVQbRSPjwIjRh8KX1Gc+snGs6Q3LcZg+nzXMlodGXbs5bCYhUc10k zYoWymz5D3KYuZ6AJ+XlQRrrVggM6wLw8gS174nxHyrMhnkOkv649kvRGJeVT+qIHW17GoRA 9T4l5HsfxG03jxvnVoQlTN7+jWLHvBUkp/4ci0kBJ1T8l8VorFshAg0d4NWzezZHZXMsktpz 5K1DGmL+D8feTqlSHVPfO/BBQTOn9vV5k0gD8OzzQTliM8j2ZPNqpPe/AAAA//8DAFBLAwQU AAYACAAAACEAHpEat/MAAABOAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIyS20oDQQyG7wXfYch9N9sKItLZ3kihdyLrA4SZ7AF3Dsyk2r69 oyC6UNte5vTny0/Wm4Ob1DunPAavYVnVoNibYEffa3htt4sHUFnIW5qCZw1HzrBpbm/WLzyR lKE8jDGrouKzhkEkPiJmM7CjXIXIvlS6kBxJCVOPkcwb9Yyrur7H9FcDmpmm2lkNaWfvQLXH WDZf1g5dNxp+Cmbv2MuJFcgHYW/ZLmIqbEnGco1qKfUsGmwwzyWdkWKsCjbgaaLV9UT/X4uO hSwJoQmJz/N8dZwDWl4PdNmiecevOx8hWSwWfXv7Q4OzL2g+AQAA//8DAFBLAwQUAAYACAAA ACEArPP6cy0CAABJDAAAHAAIAXdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHMgogQBKKAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8V8Fu2zAMvQ/YPwS6 14q7NdmKOvVhHdBDL2uLnWmZtpXIkiHRTfP3UxK4TdDGSzrNFwMiYfL5PZKir66fazV6Quuk 0QmLozEboRYml7pM2OPDz7NvbOQIdA7KaEzYCh27nn3+dPULFZB/yVWycSMfRbuEVUTNJedO VFiDi0yD2nsKY2sgf7Qlb0AsoER+Ph5PuN2NwWZ7MUe3ecLsbe7zP6wan/nvsU1RSIE/jGhr 1PROCl75SFZJvfBBwZZICatBKjKX5DJXxheppDaSmjr/ncl96ptnQqtBMf4+xvjLMCDnuYUF pvNWS/8dkcZTcQYlszCaHiBT2JGVsBdT5GU/xNYhsmoprHGmoEiYmm/FXIs43a8T7mil0P2W VN0UBQpyr/nfuPpwTIcRrbRYRnPfPO6DxXU+DM57YYiiO9CukKjyFK0Uzhm9VqNj+Mh2+N/M rkeB83MmBwKyfqL4ZpBIxWbCKAnSw+ZxPJny04AHZXpbix2AhG3PfQUZT4ZR2m2UrkMoHRKw buvMF50uXzl7MfXRNhBrykDayEi3HbwjmyEOydHhCwwVgk2F9OKe3rEXITEuMbtHIi/kzmTe MfZpGQdFcpgttwSlzPKjfMV+TRpiKykr0DKCLAP3L/P4e0i05He7nSt/c+SbZ9yn7NeQGNyb +uosfRCC0tBTW4RPGJE1y8zKvMQUlABCdaZa4ffS07szDsrdYeBWrJtCH7df8r0fgNkfAAAA //8DAFBLAwQUAAYACAAAACEAjEkB2p0OAADKSgAAEQAAAHdvcmQvZG9jdW1lbnQueG1s7FzZ cuM2Fn2fqvkHlJ46VZYseWu3K1bam5xOtROVpSSPUxAJSYxJggFBqz1P+ZCZn8uXzLkASBGy 7LYtddvtmhdbJEAsdzl3wSW//+FTErNrofJIpoeNTqvdYCINZBilk8PGr8Nec7/Bcs3TkMcy FYeNG5E3fuj+8x/fzw5CGRSJSDXDEGl+MMuCw8ZU6+xgczMPpiLheSuJAiVzOdatQCabcjyO ArE5kyrc3Gp32uZXpmQg8hzznfD0mucNN1xyezSZiRRzjaVKuM5bUk02E66uiqyJ0TOuo1EU R/oGY7f3ymHkYaNQ6YFbULNaED1yYBfk/pVPqFu7WDKvffLUUcDMuKlEjDXINJ9G2XwbTx0N W5yWS7q+bxPXSVz2m2WdnVvzVVt+CA9OFZ+BFfMBbw23hBihfSiJLR2Iv3OuLo7Yad+3GccR GqJaw0OW4M9ZriThUVoN8zTS1IkLjVhFvs+VLLJqOVm02mgf0qtqLFLMR6ysvWc0r761/FED 3FLdwZRnosGS4ODDJJWKj2KsaNbZYSSRjS7AYiTDG/qvR7H711fux0DfxILNDq55fNgY0rPn Kgobm675dzTNDhsAJjx9k2FgXmhZNX+U8qp8uL1zZLqNI5XrS4mnOvRUzN3VvPFExkVCgFe2 lzdMl1T+eAzIc5Om8jd71aFJN80eqsXTUmmhE/zHGHat2+23+3aB3u29nXfmth2ifFIrPAT8 DS8xX3v/3d5O75RWRbeGAKPqnqFHYP+6+QNHHDMhnrH0CT/xcqWB7ZjdPcXlqRjzIta1iVzn Pt06bb/de3fsWCivCG8HmiuNPlFFIJ6AK/86l8c8uLL7HoEr1PcsDauehqGW6d1BMUoioL5M 2SnX4sCQ1RAXHUCfzBLa7Xbpng01Mfiqe25v7+zDyFmCL+7ZLRfWarvZ7jTb7+5eKHHVdv9W GOo211MwhXfvC9taLnTrYoAn8Xcw4KL/ccB+l+oKxokZIGVvvCXPDqbABhVH6RVTRjTVhxBe AO5HuZbqhnSd5KhiTt/oVuek3euc2harK8rDox/LUZ1GKad53Y+Ss6M0hOeUy9RbCgShWos3 I+lTbT7jOB3kGQ+gPZkSuVDXotFlseTvs6iVFt8tDjvXim9W2IbypYvah+GvzSEbnLPO7kNk 7O0XlLFzJSbsJ/jd+aIkrCRgEwzb+oOGfR/pohWl+jVK2knwjJK2td/unfZINMiML4Jaxb05 VBkLdBdU3bbNlxa9er2drZ32E9DLCbkuwhsHp53dtcrYIjpXsFsDQUcdt5c6MnZ1Psonnd1S Pr2l1TC8NpjxEbq+IC/0dL4V9Rwp68oZE7iEHe/u0+r1s2OgRTYVKRsqORvBk5wIb8erWpQV mZFrcS1aulrbex4HcNriZlwEiP8prvSWu0B2j7HrYlDHOOpfT2HOpzyN2NFoxNeLxW8mNHCL 08DvhYoCcieIomsjlAlxvh6hzuJIavZRcOXJxMoiLGIM+T6I8kCulTxbX1nTA6k1u+BpPo5E HK6XRqCN1q2kHPzLyNP21yXYT3KKGFHxqzVD4h/IWl2J938UaYS4oZWKpU4QItHSShHqO3tb 3qqFzo82+MiLYJj79HJhshUt/qXMc3bCY6Rx1yt0KjCDPiMld78uJc8FMs+CDWa079l6iZnb Qe/COaDoK4gBL0WeIU0u2IlMNQ/0t+Snd+7NKXwBz/Bl2IvXIXhDEUzTCHj1AiTPT/TWI0SX ZEbSDVT/NlOK/UJlMn/WtO7trOLO8e7Z2bYNlk20SCeNt/NvPamYB+oL4UxtGN2NUnsaiUS2 98zr0JdTwUNkVF8YH92RxCtQk48RjxDu5UyJsVCKcttaMg2nkCE794xm8VWD0yURG0UOImSx ZcAzUvrxccO9CWdyQI6293qnJuo3p4o2bnA3zXnEo845LsWfhcg14+E1B80YTtqvIJ2QUsGy rSRjY4XjP3M3Shmd0zSH/UUsrDJsxqa9Ahf2SMNxnVL1S/6MwvOq1fQYFQPPSFuXtXShft0/ MzpkHIjum4EQbCQQBvrpumXmn5w5W/zgpRR8Hj7sNN6cpHujHO9sHe+ZpLXR+Vpiwm+5tY8y lWFRwnW+xzsaIl15xW5kweD4GBBwGMpmkZ6yANYswqGoLYSq+oRIIMcyM9Vicnyve7Vvz+Pv WQIhjwcwNQft9ja6BqRKfKJnP5wNey1vAMuuhVyPT7g6Y/yWWyS1ojEs8ZErwRksOgLd6Fow gCQtAkDpLaG2BxNEfpYKA4PE5DJMqK6IoV7FDLw46j2EjNIwuo7CAvEQkmFj/Riqmgea49Go mWRx3tRZk+jcrIxBs73X0p/0I1ZDNAoKBcus4xsoFW2tFCeYahI34mJtx6HMdLQ4QynQi1Ts LnjoILhl1JcXhTOYCjYq4lhoWEuZeGpDkhGGOP3PsUkDJeteUE2pM1cO5JU4fESBRJ8rPlE8 m9rynbRIbM8ovqaaJlOa1a7aPlBRj7lXlkS5B0iRnHcx14K8yDKJiiEovtHFX44uSgci5Joz VG5OWT6VRUwEgIKEAoWeIVWW4hFSFn7No5jb6k66x+Ewa5R12kcdDiUI7nGUkhN5uWZu1twM UOu+zKSsovk16lqB4iMDz7pLCMBHEjqPAlotDPiB225hxO0blgugArypHdrWA3SKzaYRhMkM SFvDRv/+6z88vfEogiCCp0yqaBKlQGIo0sVZz2iQTJshKnMJKxSOCQiTKP6YRXFMtJeFofkI Hf7+678txnqFAgMUmFLFucQ79GvKcZP61SeGAmNejDOWBVoAdeX+tlv7tMPL3snuu62OL+GP hj7GQFoFSclZKjH/n0WkLHmx8SkHwT0B8WdbHetrHF9Jn4zuzA6gOo/TJzC8Js/gE0s4ASYL QYZA2xBSoIxboxjayogThRjASuSCPw/xI81KBM8LS7ycvTGRJw2W4ggPA1KPKXIAGCssddGo MHA5tZL73dfVJ0w8jiaF9S/KJdWoYWVCG9ELUKr8ELUypnNWwk8uEwE6UChO9OEpn1jZym9A tQQ2iHDKSJmRtjSMxbol7GTv7fHOvslUrSRhT0HsSzHhisr/yfjWaF2aYuvZbRjqjCWdgFBf ODlkxiKCE7gTNZ3MDe7glM1Kp23vb130LQIZy2AsANAiQ2FpFBQxV+YhYkDAcU4wM+pOkDbH pzrulCJfyWooBWGDZuITjNsDRNRRvHQe7vef18WexwOAqWQm26hE2IdgHsO3vKqZm7OLwebP F4PSmqIKH/4dwaGWqE2GvEKe4e4BBkrmgsLkskO0YW5h0oENpDOCXJYsEgj4cVV2Nrz3bMGb i7Pz5ofTDRiYvvkfY6hSLyUYqKglJ30kbqL3Buv/eGzYe9b8OOjnkCSyRGU1MDRbfEcrBYRL qZt42ugnFm1GMC9ZALxQDTCmRjM0p4FpVs6WSNYDtPNu9vstxtd/NPtLr2ip6fEnqIcZfstq U5fe7vKU95AyjsaaIs/DIDVaBpCXmhYbHqCHU0AUGgBbySX/nM8CH8Lz0J+RBkun9mO5Ovn9 lqeR31j325704xX/jlrhC7i7XONlK6O0j1DTB+jgSOiZQE2aVURSY6uI8DVL5WNwP61DCplx 8W0i0wj11mQUIC8ipfc5wo0SkchLERquA1SYI/JZgBaggNkP47ABCTnIMAn0bhhkMRAIn0N2 csJOfmMUQ6Bw+krgPbCXLWC+FtcFzG95moCV0FLqN4IOq8qcFbkYFzEROBAZ9Bou3DzIClFH VZiQ06VyTYE93pfCcc8EaXFK+NKxROVaI9iQ5BLCyJPrSKcUYKXJGtAELCKHEWVrkES+EKeb Xi8bhH1drzPJb3kak14sCqzHWM+BgnDBAwrrAZRwsfEIvChDmhIs9BRZrsnUiJ2PczUXHShE 75KSJ1B6Qp8HGcpbklmzCEPiXwMXm6/hLJeFgpQDBP8PNybN4ZJnQ6CAzXG4/NYcYgJkPuCm EogTVmRKXEeyyF0ibAP/kaSxWR8e5wZcPo9KLxtGfER/uTBiUlO+FtUTPL4VzmGx80BFI/AS bvyOsSS7Zc5hns1yLr4J2PD7fr/AxGbWN6BB8bovIgVYFbgywRXkBcUjrFwGTMpIwNfEHen5 kguJI0d9m3isnJBxkbokF8Wozh/5VsXIF7CnWaMlLgPpsHl13hh2Ou0ljfUFhJz9kiMlP6jX Un+PXD8k65HXdSoNWEUkYJyTJJpMTXaJMxTdmoOZGoTjpdACy4GzQiJSC0ZMg0UN+BpVusZ5 ORAdm5KhjGgoRogiyxzzLc/mZTPfdzheOIYYdSKTSZFglMPXNxeLGYNKboxbn7OkgIiRM4nY wPmVlbDRLfDQJCBKxwEQUZ0JxDcvm3++itb5d7a9c/bO1CpX74TVIOthib5byvsrJYNwHICj PLCBFBIa0SQQhgbSK0V0VGu1ZcaR4oGimLJlqFbFlUqZMIzmCXL3ph+yoEjou/DBnsfxgGKJ uVH3DuQewBd3uLskzea3rIZsSwN9f4I6X/yW1aau4rCqyGhpfcjCgZO/gi+1tpdAllOKGO8/ Nt6gE6277Lw933f0spb+iPWqCiQyUn2JF1qbWjYv8FWDKKMrU5ZEfsaQUo0m5fyzNT3+y1wV 93CossF+olypumHtrQ1GHwDw1vSMxFx96hr9ngg7OMhje9tvO8SrX/D+THkqcBQmEc5gtb2B gA+G/AJfYUF62VSP+awy1WLHwKpwCWcMDwYEN8kIziE40Pk8Bx5lPeeFpAv6uPDmTe00wG8x WFH7QoYLiu7+NIATMPP2KcqBune9lLPY7/5XTlBPNzugk9Y+SiQOTAEQVT+4tVJjNhn8G030 QZQtemEYv6f4vbuP37aYaHKBQxcsSWa4v2O74Px4iu+ClJcjvFwmk/l1LMa1Vjp7Efikwtst +5UVJO9rl5NCm0s3HbLLME9l7TU9YlaBL0rRV1HQQlXH/QiZzcPG9p5phdTbLXZJCuznZPCj /AhV938AAAD//wMAUEsDBBQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAd29yZC90aGVtZS90 aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOA AcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEp T9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteX lqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+J knrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0 rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZx nna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw /Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY 0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/4 6fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z2 7MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0 zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbt Y3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwr TTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4D q6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hBN8Jx WoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zERW+vE64E7+D KRtjYkoNFHWnVsc0+bvCzShUbsvh4go3lMoXXz+ukPttLdmbsHtV5cz2iUK9CHeyPHe5COjb X5238CTZI5AQ81vUu+L8rjh7//nivCifL74kz6owFGjdi9hG27Td8cKue0wZG6gpIzekabwl 7D1BHwb1OnPiJMUpLI3gUWcyMHBwocBmDRJcfURVNIhwCk173dNEQpmRDiVKuYTDohmupK3x 0Pgre9Rs6kOIrRwSq10e2OEVPZyfNQoyRqrQHGhzRiuawFmZrVzJiIJur8OsroU6M7e6Ec0U RYdbobI2sTmUg8kL1WCwsCY0NQhaIbDyKpz5NWs47GBGAm1366PcLcYLF+kiGeGAZD7Ses/7 qG6clMfKnCJaDxsM+uB4itVK3Fqa7BtwO4uTyuwaC9jl3nsTL+URPPMSUDuZjiwpJydL0FHb azWXmx7ycdr2xnBOhsc4Ba9L3UdiFsJlk6+EDftTk9lk+cybrVwxNwnqcPVh7T6nsFMHUiHV FpaRDQ0zlYUASzQnK/9yE8x6UQpUVKOzSbGyBsHwr0kBdnRdS8Zj4quys0sj2nb2NSulfKKI GETBERqxidjH4H4dqqBPQCVcd5iKoF/gbk5b20y5xTlLuvKNmMHZcczSCGflVqdonskWbgpS IYN5K4kHulXKbpQ7vyom5S9IlXIY/89U0fsJ3D6sBNoDPlwNC4x0prQ9LlTEoQqlEfX7AhoH UzsgWuB+F6YhqOCC2vwX5FD/tzlnaZi0hkOk2qchEhT2IxUJQvagLJnoO4VYPdu7LEmWETIR VRJXplbsETkkbKhr4Kre2z0UQaibapKVAYM7GX/ue5ZBo1A3OeV8cypZsffaHPinOx+bzKCU W4dNQ5PbvxCxaA9mu6pdb5bne29ZET0xa7MaeVYAs9JW0MrS/jVFOOdWayvWnMbLzVw48OK8 xjBYNEQp3CEh/Qf2Pyp8Zr926A11yPehtiL4eKGJQdhAVF+yjQfSBdIOjqBxsoM2mDQpa9qs ddJWyzfrC+50C74njK0lO4u/z2nsojlz2Tm5eJHGzizs2NqOLTQ1ePZkisLQOD/IGMeYz2Tl L1l8dA8cvQXfDCZMSRNM8J1KYOihByYPIPktR7N04y8AAAD//wMAUEsDBBQABgAIAAAAIQAQ a17bJQUAAAcPAAARAAAAd29yZC9zZXR0aW5ncy54bWy0V0uP2zYQvhfofzB07saURD0bp9Cz TZBtgjq59EZLtE2sJAoUvY7z6zvUYx13J0HQoCdR8817huTw5W+f2mb1yNUgZLex7BfEWvGu krXoDhvr44fyLrRWg2ZdzRrZ8Y114YP126uff3p5jgeuNbANK1DRDXFbbayj1n28Xg/Vkbds eCF73gG4l6plGn7VYd0y9XDq7yrZ9kyLnWiEvqwdQnxrViM31kl18azirhWVkoPcayMSy/1e VHz+LBLqe+xOkrmsTi3v9GhxrXgDPshuOIp+WLS1/1UbhHhclDx+K4jHtln4zjb5Fucc7lmq +knie9wzAr2SFR8GKFDbTOG2THRPamz6TNFTql9AqteT7bVRBeI2GVdXz4fmmTxS7amKb8VO MTWVGRrAeNFW8etDJxXbNdBUZ5tar6CjPkvZrs5xz1UFRdpYkW+tDb2Wf0qdi6Fv2OU9O/BU nqAhleDDCEOocr/VTHMQHnreNGP3Vg1nYOocHxRroe821kSZVPI9OzX6A9ttteyB6ZFBRIFD JovHS3/k3dgdf0PfLzh1vAmvjkyxSnO17VkF1jLZaSWbhW90OIMeV1CCWWLseBPN1PvbafeA RMdayMFEnXfEvay58fykxLM0f7VMRmCMArI5xogbkrDblag5hN7wrb40vATnt+IzT7r6zWnQ AvbYGPkPePAtByCvYPkdnA0fLj0vOdMnSNP/ZGysRNmI/l4oJdXrrobO+lFj66WIppxwdNbD svhLSr2UgZDUcb08n3Jh2K4IsQEpcCQgRYoijpPkc2n/pc1zw2Lu3FvEdmyaZ5g223c8P0KR jJQ26rVd+tRDtTmOTTLUAyckZV5idtzA9vB43MzLEjQHbh64y6lwG6lbeHaJ+kZTryhczANa +GWZoEhJPeJgiOeR0ptPgVsPIBjXR2X8gIR5gGnzE2J7Noqkjm+jeQt86oaotiB0i2Q+M299 C0KalKjXQWqnAVq5IA1CD61CUPg0QbWFxKVhiMUTep4doR0f+r4boJGGIYky1IMw8mmJ9miY ETNNjAfgbQ4i23MytEMih3oRqi0KXCdHd0mUermH2klcv8zRmiaRmzg4kgVFie7tlFAa4shX T5eUOim+t1PPKyK0cilUO0C7N6OUBuguyfwgpWi1ASkCNNIscu0M7YOsoDTBZQqv9NH65CTw I7RDctdPStROHrouQTNauPQr2SkCP8P3HAgUPmqnhK3tor6VxE18NNIyISRBq1BmvpvjSEkd Ou5guJdMy8Nt1MZmHH2vlpW54lftNB5krN0pwVb3ZmCFfdLGO/WQim7BdxwGdv4lsj3tFvDu bgKGljVNCTPQAowOtHENU1rO96Pa5p6pw1XvzKFQas33b550memPq9+VPPWTtbNi/XR1L+Zs OoXcxqLTb0W70IfTbrtIdTB0fgHBzPjuURmF62t6zrGGt8o4Ar1l3WG5oXl393FrWOGmb9TW vGf4Pet7GPWAZXewN1YjDkdtm7FFwx+Mow/jz+7gzJgzYvBnsPGHVSYy4J4XhmFaAte8uNLc heZeaTC1T3z0SvMWmnel+QsN3lXnGKZZrmAofoBhclka+l42jTzz+o+FuLGekaYkDEfWc6ir mZmhvWQ8EqBoI2H1GPNPMK/zWmh4LvaibtkneE0SZzwgZ24Y3uVJ3/AaTYa5v6GuaqYZiI+l uhGG0sGEf+sLPA94JaAdt5d2dx3Bf5kcb8Sgt7yHaV1LBSGPA/Kvo+brC/bVPwAAAP//AwBQ SwMEFAAGAAgAAAAhACNxq9dACQAAqEUAAA8AAAB3b3JkL3N0eWxlcy54bWzUXFtz27YSfu9M /wOH74kudqTaU6UT23HtmSRNI/ucZ4iELExIQiWpOM6v72JBQhQpkAuRmTnnSSZI7Ie9fQtK WP/+x/c48r7xNBMyWfiT12Pf40kgQ5E8LfzHh9tXv/lelrMkZJFM+MJ/4Zn/x9tff/n9+TLL XyKeeSAgyS7jYOFv8nx7ORplwYbHLHsttzyBm2uZxiyHy/RpFLP06277KpDxluViJSKRv4ym 4/HML8SkFClyvRYBv5HBLuZJjvNHKY9AokyyjdhmpbRnirRnmYbbVAY8y0DpONLyYiYSI2Zy 3hAUiyCVmVznr0GZkV7RSImC6ZMx/hVHvhcHl/dPiUzZKgLjPU/O/bdguVAGN3zNdlGeqcv0 c1pcFlf4cSuTPPOeL1kWCPEAJgUBsQBZd++STPhwh7Msf5cJdvTmRj119E6Q5RVpVyIU/kgh Zj9A5jcWLfzptBy5Vis4GItY8lSO8eTV47K6koVvhlYgd+Gz9NXynRI2QjXLz4q62wPl4QqX smUBOANw2DrnEBQQIwonEioGp3OIF33xZafsyna5LEBQAIBVxcJlzeIQKxA5Sx3AcJevP8jg Kw+XOdxY+IgFg4/3n1MhUwjShX9xoTBhcMljcSfCkKt8KcYek40I+X83PHnMeLgf//sWg7+Q GMhdksPyZ3OMgigL338P+FaFLYhOmPLwJzUBAgfcUcHBBe3EfjV6oIaKg/+UkBPtw6MoG85U hnu4/lYg1HrXG2iqNKoqgHKd1nrWX8R5fxFv+ovA4O1ni3n/VQCv9/WIjo1KVNKdmstAB1/V DmcXLSGrZjSiqHNGI2g6ZzRipHNGIyQ6ZzQioHNGw+GdMxr+7ZzRcGfrjIAhcdWj6AytQUrs B5FHXM1vJaBJT6orSo33maXsKWXbjacKa33ZbWS53K1y2lKRTk8ny2WeyuSp0yJQnVXqnszJ 7+PthmUCdkkdpp/2NP2D2vV4f6Yi7IR6o4OvoRNuTI6WsM8RC/hGRiFPvQf+XXvUYf4n6S31 LqNzcT3d+kE8bXJvucGS2wk2sxjdbgkt/4PI0AatyTSzqNIlnOTDmSUu7cI/8lDs4tI0hN3I TPO5g5trELjEdhOdKxc1s6tTC+UAigq6XLirgPIJ69fFxV2+8jFl/boUnSifsH5duE6Uj/HR 7l9nprmBl1aPlF5z59y9lpFM17uozIFOepg7Z7CBoKngnMRGPokk5s4ZfECf3rsggDc3Spw6 +2LPow4ozu7QKJhsdF2cnVKjvYmDRs4OqmFNHbD6ca0DkDPpfuHfhPpOzLUYIEubvWZnOp9Z LAAliLSH/nsn8+499NTCeVSU+wS+Lsm4R0M7s2QeFa2IJ13vHHzcr/A5APWrgA5A/UqhA5Al Pux7HlMT6SD9i6MDljMtmyqGYUdm5rkzMxsgtxIwUN0k7L8s2WuPhWbdJKA4O6hZNwkozt6p 1TJTNwlYg9VNApalath9VOVUF6Wc62YVyOwECBoNQ94EoGHImwA0DHkTgPqTdzfIcORNwHLm BsOpVfImAOEjLq/6BqhK3gQgZ27QbFd8Z1TWPZTS/nI7AHkTUJwd1CRvAoqzd2zkTcDCR1wi oYZlqI6ANQx5E4CGIW8C0DDkTQAahrwJQMOQNwGoP3l3gwxH3gQsZ24wnFolbwKQMz0YoCp5 E4DwERduOEremPU/nbwJKM4OapI3AcXZOzVCNZtUApazg2pYhrwJWPiISzAUWBjcLkoNQ94E jYYhbwLQMORNABqGvAlA/cm7G2Q48iZgOXOD4dQqeROAnOnBAFXJmwDkzA1HyRuT8aeTNwHF 2UFN8iagOHunRqiG5whYzg6qYRnyJmBhvPQmbwIQPnIqkItGw5A3QaNhyJsANAx5E4D6k3c3 yHDkTcBy5gbDqVXyJgA504MBqpI3AciZG46SN+bITydvAoqzg5rkTUBx9k6NUA15E7CcHVTD MlRHwBqGvAlAGJi9yZsAhI+cAIRZ5OKmYciboNEw5E0A6k/e3SDDkTcBy5kbDKdWyZsA5EwP BqhK3gQgZ25Q52zhvCj5eOrEEgTUcwblqQYy4NTiJCpgoeAXvuYpNFnx7tMhPQFLDR0QLeFB VfFKyq8e7WD3mSVAyFBiFQmJR7pf8JROpRHhbN7SSfDw17V3pxtgGvMwpA5P3kD3ULVdCNuT VOMQrDN/2ULLzrY8Wa6kQYOQ6usqWoCwRe4eGoKKth41WfX5wIPYVFUM4++2BSr8DYg4sQkV bAArgI6oFqjiwLs5g4TH3evAllPxuJB9S0a5zOJ0/H4PpZ87OKPZuu5cnQRvWTOeFG+1kYeP aK82FwjNWbikrhWCy1aRbjGDP+6TEDSEJkH81Uw7M/zOtCi4f82j6CPDhrRcbu2PRnyd67uT MVbAmqiVzHMZ2+eneEAcV3JMAIRDdTH6Uilhj5NkF694Ch1eLTb/JFXlwE60w5DUZ10toUC1 tH1tB+liEuSKRZGUCZ7krwdrcU8f88d1rRi02f2luuYaaQQtgl/L8YrQa8ic/tEDbbIqZBB0 PL4Zz2cXV1qqrXERQ6toWzw3F8fbFosWSfg46P1c+A9sI2OmfIldndWBIDNXOgNME+dkVuTE j30Tpx4D30DLaVv8HPBMsMsgfLFZsk5rdQO3ec7bu6DmvqOMhdpYnOnoSLvX0Az/a/Y2OXEH 5SVVJmgk6f7OsXSw29POnIevISj10Gyzq+lscqstX5gtUIfX9+kwHt/eqhjF7mLcNULXtFEB Re7Kp1WrNVQEGOwOxuOEAf0/4jhd4B13sjAC93FqN1d3oTm03nhy9ubmvbbeT6WKaxaJVSoq XFGOoAOyChnAdpZkfyoZHBqwTgV7r/QlAoOjzUl2kt0jFhooLbfn3XLkZFuajZBJctzXqFer RpLjHd0+h3g11sTb1Q1k0xDQVYczDzX/7WJ2fnszZCy6bKqu4H8kwL+bUOGhN1VYTAs+AEtn Pxa+/l0HuvPKXnxkmn2fP+zI9ZbrpLlmO3bS7HKzdtJkAf+TIeR3NRYka62n/+e06UC04Keq +f+fd7jHi4La0ZoXn0ZC4Tcl+9vHkqo9n6BbAyftX9Vg73CwJbw6n17NiqwreF7gW4YK2IU/ h5ZalBBADzI0re5YVDShwig4CKfAJ7LDfoOWvf0XAAD//wMAUEsDBBQABgAIAAAAIQABIYaK xAkAAJlIAAAaAAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWzUXFtz27YSfu/M+Q8cvjuW ZEeqPVU6sR3XnknbNLJ7niEKsjAmCZYXO86v72JBghQpkguRmTnnSRZJ7LfXbyEZq19+/Rb4 zguPEyHDpTt9N3EdHnpyI8Knpfv4cHvys+skKQs3zJchX7pvPHF//fCfn355vUzSN58nDggI k8vXyFu6uzSNLk9PE2/HA5a8C4QXy0Ru03eeDE7ldis8fvoq483pbDKd4F9RLD2eJIB2zcIX lri5uKApTUY8BKytjAOWJu9k/HQasPg5i05AesRSsRa+SN9A9mReiJFLN4vDy1yhE6OQWnKp FcpfihVxw4oDuHrljfSygIcpIp7G3AcdZJjsRFSacaw0MHFXqPTSZcRL4BfPvUbT8waeMZkS g5uYvUIoSoENcQecsdGLAl/7QcW3jGpd4nTSZUweESXC6EBRYR+z0CRgIjRijnNN1blQD0Py +7dYZpFRJxLDpN2Hz0aWKksLzSZzrLyqaYmVgEbprnYs4q4TeJf3T6GM2doHjV6n547KSPcD UMVGejd8yzI/TdTb+Eucv83f4cutDNPEeb1kiSfEA1AISAkECLz7GCbChTucJenHRLCDN3fq qYN3vCStSLsSG+GeKsTkO8h8Yf7Snc2KK9dKg71rPgufims8PHlcVTVZuubSGuQuXRafrD4q YadoZvFaMTfaMx7eoSoR86DyAIdtUw4kBCymcHyhojtbAKPpN18z5VyWpTIHQQEAVhULb2se B24Cplppxoa7fPtZes98s0rhxtJFLLj4eP8lFjIGGl26FxcKEy6ueCDuxGbDVYPIrz2GO7Hh /93x8DHhm/L6X7dIz7lET2ZhCurPF5gFfrL59M3jkaJJEB0yFeE/1ALgMAhHBQcVykSpjb5Q Q8WL/xSQUx3Dgyg7zlRLc1D/TiC0OhsMNFMWVQ1AuVa6ng0XcT5cxPvhIjB5h/liMVwL2MgM jYjOjUpW0oOaSk8nX9UPZxcdKatWNLKod0UjaXpXNHKkd0UjJXpXNDKgd0Uj4L0rGvHtXdEI Z+cKjyFx1bPoDL1BKuwHkfrQJ3uYbjqQ6vJW43xhMXuKWbRzVGOtq91FlqtsndJURTo9nixX aSzVdrPHI9CdVekezcmfgmjHEgG78j6gga5/UFsf57dYwPa1B+q9Tr6GTbgxOdjCvvjM4zvp b3jsPPBvOqIW6/+QzkrvMnqVGxjWz+JplzqwK1Qttxds3uL0dk9o+Z9Fgj7o7ObzFlP6hJNi OG/Jy3bhv/ONyILCNYTdyFzzuUWYaxCoYreLzlWImtXVa4UKAMUE3S7sTUD5BP11c7GXr2JM 0V+3oiPlE/TXjetI+Zgf3fG1Zpob+FrFIZXXwrp2r6Uv423mFzXQSw8L6wo2EDQTrIvYyCeR xMK6gvfo0/noefDJjZKn1rEoedQCxTocGgWLjW6LdVBqtDe1sMg6QDWsmQXWMK61ALIm3a/8 RagvgW2bAbK02Wv2lvNZiwegBZH20H9lMu3fQ89aOI+Kch/C1yUJd2hoZy2VR0XL80n3O4sY D2t8FkDDOqAF0LBWaAHUkh/tex7TE+kgw5ujBZY1LZsuhmlHZuaFNTMbILsWMFLfJOy/Wqq3 PReafZOAYh2gZt8koFhHp9bLTN8kYI3WNwlYLV2jPUZVTrUxyrpvVoHMToBg0TjkTQAah7wJ QOOQNwFoOHn3g4xH3gQsa24wnFolbwIQPmLzUd8AVcmbAGTNDZrt8u+Mir6HUro/3I5A3gQU 6wA1yZuAYh2dNvImYOEjNplQwzJUR8Aah7wJQOOQNwFoHPImAI1D3gSgccibADScvPtBxiNv ApY1NxhOrZI3AciaHgxQlbwJQPiIDTccJG+s+h9O3gQU6wA1yZuAYh2dGqGaTSoByzpANSxD 3gQsfMQmGXIsTG4bo8Yhb4JF45A3AWgc8iYAjUPeBKDh5N0PMh55E7CsucFwapW8CUDW9GCA quRNALLmhoPkjcX4w8mbgGIdoCZ5E1Cso1MjVMNzBCzrANWwDHkTsDBfBpM3AQgfORbIxqJx yJtg0TjkTQAah7wJQMPJux9kPPImYFlzg+HUKnkTgKzpwQBVyZsAZM0NB8kba+SHkzcBxTpA TfImoFhHp0aohrwJWNYBqmEZqiNgjUPeBCBMzMHkTQDCR44AwiqyCdM45E2waBzyJgANJ+9+ kPHIm4BlzQ2GU6vkTQCypgcDVCVvApA1N6hztnBelHw8ddqSBNRzBsWpBjLgrCVIVMDcwK98 y2OYKuT9p0MGAhYWWiC2pAfVxCspnx3awe6zlgQhQ4m1LyQe6X7DUzqVQYSzRcckwcOf186d HoBprMOU2j95A9ND1XEhHE9Sg0OgZ/oWwchOVJwsV9JgQEjNdeUjQDgTeg8DQflYj1qs5nzg QRyqyi/j/21zVPgbEHFhE8rbAZYHE1EdUPmBd3MGCY+714FbTsWjIuVIRqFmfjq+3EPp5/bO aHbqnaqT4B0640nxTh85+IiOalNBGM5Clfo0hJCtfT1iBn/chxuw8DWfztLB3HxjWhTcv+a+ /zvDgbRURu2P+nyb6rvTCXbAmqi1TFMZtK+P8YA4anJIAKRDVRn9VhnRnidhFqx5nB83b01J 1TlwEm0/JfVZ15ZUoHq6Xbe9cjEFcsV8X8oQT/LXkzW/p4/5o15rBmN2f6qpuUYZwYjgc3G9 IvQaKmd49sBcuEoZBJ1MbiaL+cWVlto2uIj/kM3HFs/Nm8Nji/mIJLzszX4u3Qe2kwFT9YNT ndULHgyr5rd1BZghzuk8r4nv5RCnvgaxgZHTrvzZ4xkvSyB9cViyTmt1B3dFzilDUAvfQcZC a1qCaRnI9qihG/7X/G1q4g7aS6xc0CjS8s6hcmj3Zztz7n8MQan7bptfzebTW+353G2eOrxe lsNkcnurchSni3HXCHPUxgQUmRVPq584gI4AF/uT8TBhwPyPOEwXeMeeLIzAMk/b3dXfaPa9 N5mevb/5pL33Q6nimvliHYsKVxRXMABJhQxgO0vyP5UM9h1Yp4IyKkOJwOBod5KD1B6RFhoo PFfybnHlaF+ajZApctzXqI9WjSLHO3p8DvFqrIm3qxvIpiNgqg5X7lv+88X8/PZmzFy02VRd wa9ZwO+rqPTQmypspjkfgKeT70tX/18HpvOKWXxkmnLOH3bkest11FqzHTtqdbFZO2qxgN9k 2PC7GguSrdbL/z5uORAtxKnq/v/nHe7hpqB2tOaDT6Og8JuS8vahouquJ5jWwEXlRzXYO+xt Ca/OZ1fzvOpynhf4KUMl7NJdzCZaggczyDC0mjE/H0IFuRAgXAKvyA7lBi358C8AAAD//wMA UEsDBBQABgAIAAAAIQDdT/1e8AEAAO0DAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTwW7bMAy9D9g/GD6v kZMFaRswKoYUQwdsa4C47VmT6USYLAmSGjT7+lF24yrbTtOJfCSop8cnuHnpdHFAH5Q1q3I6 qcoCjbSNMrtV+VB/vrgqixCFaYS2BlflEUN5w9+/g423Dn1UGAoaYcKq3MfolowFucdOhAmV DVVa6zsRKfU7ZttWSby18rlDE9msqhYMXyKaBpsLNw4sh4nLQ/zfoY2ViV94rI+OCHOosXNa ROTfEx0NbASgtlHoWnXIpwSPCWzEDgP/CGwI4Mn6JvDLS0KGENZ74YWMJB6fT6sZsAyAT85p JUUkXfk3Jb0Nto3Ffa9AkQYAy1uAVNmifPYqHnkFLE/hqzKJyhzYEBE3L3ZeuH3g14ngmMFW Co1rejtvhQ4I7A2AOxRprxuhiDEc4vKAMlpfBPWLNjsrix8iYFJsVR6EV8JEUi61DUkfaxei 57WKmmZTbcj7MG/LYzVPylIvBeeNCRw4UOGcXX9DuG/pbfEfZKc52Z7DQDWjk4XjHX9MXdvO CXPkaxWkLbbHELELH4ovRk5oma/FpP7P8OBqe5sM9CrrOZhZ4UnF/dYJSQubXy0WuSmyEmzJ O9jQlk8D3wC4oxV4nW4lQ5kdNqeevwvJZo/D7+XT+aSi0/vqhJE5xm/FfwMAAP//AwBQSwME FAAGAAgAAAAhADLJ7cRMAQAAfAIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySzU7DMBCE70i8Q+R7YruF CkWJKwHqiUpIFIG4GXvbWsQ/sk3Tvj1OUkIrOHFcz/jb2bWr+V432Q58UNbUiBYEZWCElcps avS8WuQ3KAuRG8kba6BGBwhozi4vKuFKYT08euvARwUhSyQTSuFqtI3RlRgHsQXNQ5EcJolr 6zWPqfQb7Lj44BvAE0JmWEPkkkeOO2DuRiI6IqUYke7TNz1ACgwNaDAxYFpQ/OON4HX480Kv nDi1igeXZjrGPWVLMYijex/UaGzbtminfYyUn+LX5cNTP2quTLcrAYhVUpTCA4/WM7Dh3XoD FT457BbY8BCXaddrBfL2wKCxPG26wr+lzu1hp7pnYpPeMZapVT/Z0A9klrKWw2Tfysv07n61 QGxC6DQnNKezFb0ur2YlIW9dqrP7XfbhQB+z/Zv4DWB94vP/wr4AAAD//wMAUEsDBBQABgAI AAAAIQB9ZrDHawIAANsIAAASAAAAd29yZC9mb250VGFibGUueG1s1JVLj9owFIX3lfofIu+H OCE8NTCa0kHqposOVdfGOMSqH5HtkOHf9zoJjylBQ6rRSAVBwrF9cD6de33/8CJFsGPGcq1m KOphFDBF9Yar7Qz9XC3vxiiwjqgNEVqxGdozix7mnz/dl9NUK2cDWK/sVNIZypzLp2FoacYk sT2dMwWDqTaSOPhptqEk5neR31Etc+L4mgvu9mGM8RA1NuYWF52mnLKvmhaSKVetDw0T4KiV zXhuD27lLW6lNpvcaMqshWeWovaThKujTZRcGElOjbY6dT14mLDeUeitYHmEqzspUCDp9NtW aUPWAtiVUYLmDbignCoiQXzey7UWlZ4TpS2LYGhHxAzhAbwj7A1HeAjXAR6h0BvQjBjL3HFi XMspkVzsD6rRkqh6IOeOZgd9Rwz3+6mHLN/CQGHXGP6weaFaiSAPr5X4Yk7/tUIrn/HZKlDA 5+gM2w/r5FyAWHHJbPCdlcGPaud+wt9EYqAwxH0gkcAnhruknQh+HyJPsPH4cbk8EVmAMhon UaOciEwapZVI9fxR7XM7kYUuDGfGM2nNRwy56OMJcPDZiIFJFxpSb5hpC0jKX9jmMh1XWfQ/ gsUvKE7flGwricEhYKdrey5aK4UUTtfT/4tCWRDB14a3gojxsoqCj0QC4YDvdhCtBWJLbm0n Ek++Q8TnBZKA8Lg4Kp0KZFIV2u0FsiIZtIorIL5Ap/AIfK9I/h2E0m5lCrba56zqvd0icqiN 8x5Yd9cTGDhyqw58vXNgXPWb28EsiISEXCPje2fNxffSbhHpfqr4vnEZEZy0RORtEtGbEWmO Fzv/AwAA//8DAFBLAwQUAAYACAAAACEAuFTkLxMCAABjEQAAFAAAAHdvcmQvd2ViU2V0dGlu Z3MueG1s7Fg9b9swEN0L9D8Y3GOJoj6NyAGMIEWBtA3atDst0TZRkieQtFXn1/csOanTdLAH ox40iTzePd3x6VEkr29+aTXaCOskmJLQcUhGwlRQS7MsyffHu6ucjJznpuYKjCjJVjhyM33/ 7rqdtGL+TXiPnm6EKMZNdFWSlffNJAhctRKauzE0wuDgAqzmHrt2GWhuf66bqwp0w72cSyX9 NojCMCV7GHsMCiwWshK3UK21ML6LD6xQiAjGrWTjntHaY9BasHVjoRLOYT1a9XiaS/MCQ+M3 QFpWFhws/BiLCfqMgh0UhtOwa2lFRrqafFwasHyucAZbGpMpTl8tN27/HLUTWZckjnOWR3nS Dc+h3t7KDQ5tuEJmSLBzxrm7Fwv/bA1frF/lcvUP8yM0b31n4D3ov+yYzqy2u3f4PzEGOSfo 6J5Kgl8GNhpeYQ1duwIFSBVfe+jTUAeZnRY5f5XRabH2sPJTQoOOg67ovvmajSzMGCviaGDj lG/gXGzENEqLIgoHOk6S5NnoSMM8YXlBB3VcgjqysIiLmGaDOi5CHUWepYwlMRvUcQnqoDRJ GEvjfFitLkIeNCqSMI2z/UZ42Okeub8+18+cZrTIaZ5E+bBeXcJ6FYVJxFjGov6gOOjjP+ij PxF2B3RovNTySdyBnVlonbDdURwvG7ZfzI9P912PKwXtw+cP2MHQg6uR6W8AAAD//wMAUEsD BBQABgAIAAAAIQAvfktZOgMAAHQPAAASAAAAd29yZC9udW1iZXJpbmcueG1szFfNbptAEL5X 6jtY3GPAJk6KQqIoqStXbVQpqXpew9qssj9od4H42pfpI/Sx+gqdZQ2xIYoC9iEXY8/ufDvz Md/s+OLqidFRgaUigkeOP/acEeaxSAhfR87Ph/nJuTNSGvEEUcFx5Gywcq4uP364KEOesyWW sHEEGFyFZRZHTqp1FrquilPMkBozEkuhxEqPY8FcsVqRGLulkIk78Xyv+pZJEWOlAOcG8QIp ZwvHumgiwxzOWgnJkFZjIdcuQ/Ixz04APUOaLAklegPY3qyGEZGTSx5uAzppAjIuoQ1o+6g9 ZCeLF861nrcizhnmujrRlZhCDIKrlGTPaQxFgxTTOqTitSQKRut9ZeYHnfOalN/yDm4lKuFV PAN24F4gI7FOjFoezPt9fqttRN97LZntGzEQTQxvCWH/zDoShghvYIZRs0suSOKQ+v4iRZ41 4WTkMLQFf2ywjDJ7RObNKuXtpqZ6AXSke5+iDDsjFoeLNRcSLSlEVPrByFSkcwndAi2VlijW dzkb7f1aJJHjVVu4IgmsFYhGziz4PPOns1vHNc4sp5p8wwWmD5sM13vSzVKS5LtZo2bN7tUs o/WOYDq5nk9mnl2hhVkg8DAnwledUWgyXuB98jzPr2KAXid17e5bP2h0c9YYlzmlWDeID/ip Wfr3+29j/xrXKBSvttuzH9JkQ7hJ05gj52xSRZIivq5a7tQG65bhdrO0PnIuuFbghlRMoHLu N2wpQPdlmF4Db3sGwgE4wSsEzJh4AKxCgSfkbiLYZcLvMDE9nAnRlwc/CIYRcSNySbAc3eFy h42WNYbybpnSfixNOiydVhZo/tDzC6j2o9TPn768TXwoGFMFfQvoF5SbueXhompqaN/Wj6Bp hyBbWEcmqLfAJufnwwg6nsKCDjWWrKNS01tx0GmGEdMWku0/LevhirP62u3Q70NxcKcM421f XZa1fVs/xcGI27nCjOWoZTXgSjuFC7VqKn1b0vEUd9ah5j0o7vRsYK9uaWt747eshysO/uq1 Cup9KG4WDGzh++oaojgYmXYGVzM6wTAILMGnmVvtnb+zY2Emu2qArWZOcIed1QQGT/tv+fI/ AAAA//8DAFBLAQItABQABgAIAAAAIQDwIex9jgEAABMGAAATAAAAAAAAAAAAAAAAAAAAAABb Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAB6RGrfzAAAATgIAAAsAAAAAAAAA AAAAAAAAxwMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAKzz+nMtAgAASQwAABwAAAAA AAAAAAAAAAAA6wYAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAA ACEAjEkB2p0OAADKSgAAEQAAAAAAAAAAAAAAAABaCgAAd29yZC9kb2N1bWVudC54bWxQSwEC LQAUAAYACAAAACEAMN1DKagGAACkGwAAFQAAAAAAAAAAAAAAAAAmGQAAd29yZC90aGVtZS90 aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhABBrXtslBQAABw8AABEAAAAAAAAAAAAAAAAAASAA AHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhACNxq9dACQAAqEUAAA8AAAAAAAAA AAAAAAAAVSUAAHdvcmQvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQABIYaKxAkAAJlIAAAa AAAAAAAAAAAAAAAAAMIuAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQItABQABgAI AAAAIQDdT/1e8AEAAO0DAAAQAAAAAAAAAAAAAAAAAL44AABkb2NQcm9wcy9hcHAueG1sUEsB Ai0AFAAGAAgAAAAhADLJ7cRMAQAAfAIAABEAAAAAAAAAAAAAAAAA5DsAAGRvY1Byb3BzL2Nv cmUueG1sUEsBAi0AFAAGAAgAAAAhAH1msMdrAgAA2wgAABIAAAAAAAAAAAAAAAAAZz4AAHdv cmQvZm9udFRhYmxlLnhtbFBLAQItABQABgAIAAAAIQC4VOQvEwIAAGMRAAAUAAAAAAAAAAAA AAAAAAJBAAB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQAvfktZOgMAAHQP AAASAAAAAAAAAAAAAAAAAEdDAAB3b3JkL251bWJlcmluZy54bWxQSwUGAAAAAA0ADQBJAwAA sUYAAAAA --------------080405040305090903090800-- From loa@pi.nu Wed Jan 16 09:15:38 2013 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 EC2DD21F8B5E for ; Wed, 16 Jan 2013 09:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 weNJORgz0nKG for ; Wed, 16 Jan 2013 09:15:38 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 530AA21F8B4A for ; Wed, 16 Jan 2013 09:15:38 -0800 (PST) Received: from [192.168.1.104] (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 0D329823B5; Wed, 16 Jan 2013 18:15:33 +0100 (CET) Message-ID: <50F6E035.6030808@pi.nu> Date: Wed, 16 Jan 2013 18:15:33 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Daniel King References: <20130110174041.5EBC9B1E002@rfc-editor.org> <002001cdf3d6$2d26c980$87745c80$@olddog.co.uk> In-Reply-To: <002001cdf3d6$2d26c980$87745c80$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, rcallon@juniper.net, venkat.mahalingams@gmail.com, 'RFC Errata System' Subject: Re: [mpls] [Editorial Errata Reported] RFC6639 (3450) 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, 16 Jan 2013 17:15:39 -0000 All, with the authors accepting the errata, this is a no brainer. Please register the errata with the new text and that the RFC will be corrected if and when it is updated. /Loa On 2013-01-16 11:42, Daniel King wrote: > We (the authors) accept the errata and agree to the proposed text update. > > Br, Dan. > > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 10 January 2013 17:41 > To: daniel@olddog.co.uk; venkat.mahalingams@gmail.com; stbryant@cisco.com; > adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; rcallon@juniper.net > Cc: ietfc@btconnect.com; mpls@ietf.org; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC6639 (3450) > > > The following errata report has been submitted for RFC6639, "Multiprotocol > Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6639&eid=3450 > > -------------------------------------- > Type: Editorial > Reported by: tom petch > > Section: 4.2.9 > > Original Text > ------------- > The mplsOutSegmentPerfTable [RFC3813] contains statistical > information (total packets received, total errored packets received, > total packets discarded, discontinuity time) for outgoing MPLS > segments from an LSR. > > > Corrected Text > -------------- > The mplsOutSegmentPerfTable [RFC3813] contains statistical > information (total packets sent, > total packets that could not be sent due to errors, > total packets discarded, discontinuity time) for outgoing MPLS > segments from an LSR. > > > Notes > ----- > mplsOutSegmentPerfTable is for segments sent, current text relates to > segments received. > > 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. > > -------------------------------------- > RFC6639 (draft-ietf-mpls-tp-mib-management-overview-08) > -------------------------------------- > Title : Multiprotocol Label Switching Transport Profile > (MPLS-TP) MIB-Based Management Overview > Publication Date : June 2012 > Author(s) : D. King, Ed., M. Venkatesan, Ed. > Category : INFORMATIONAL > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From adrian@olddog.co.uk Wed Jan 16 13:07:22 2013 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 E505311E80D2 for ; Wed, 16 Jan 2013 13:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 kfnmTsRFefVH for ; Wed, 16 Jan 2013 13:07:22 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 99FEA1F0C3E for ; Wed, 16 Jan 2013 13:07:21 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0GL7BD8025994; Wed, 16 Jan 2013 21:07:11 GMT Received: from 950129200 (089144192153.atnat0001.highway.a1.net [89.144.192.153]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0GL71qm025876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Jan 2013 21:07:05 GMT From: "Adrian Farrel" To: "'David Ball'" , "'VIGOUREUX, MARTIN \(MARTIN\)'" References: <20130110175648.GI32428@cisco.com> In-Reply-To: <20130110175648.GI32428@cisco.com> Date: Wed, 16 Jan 2013 21:07:00 -0000 Message-ID: <021701cdf42d$72200860$56601920$@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: AQKJyV6+bHSBwG2j2NRvssT27Ly7TQImhphdlsOTq9A= Content-Language: en-gb Cc: mpls@ietf.org, dai.xuehui@zte.com.cn, "'Sami Boutros \(sboutros\)'" , "'Siva Sivabalan \(msiva\)'" , rcallon@juniper.net, raggarwa_1@yahoo.com Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 16 Jan 2013 21:07:23 -0000 All, are we getting any closer to agreeing what we all intended to say? Once we have that, I can work out what to do with the Errata Report. Thanks, Adrian > -----Original Message----- > From: David Ball [mailto:daviball@cisco.com] > Sent: 10 January 2013 17:57 > To: VIGOUREUX, MARTIN (MARTIN) > Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan (msiva); > raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant); > loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org > Subject: Re: [Editorial Errata Reported] RFC6435 (3429) > > Hi Martin, > > Ah, right I see: since the loopback is locally configured, there is no > need for a MEP/MIP to send/receive OAM frames - but there may be a > MEP/MIP. > > So would this work to clarify the text? > "It should be noted that the data-plane loopback function for a > given transport path can be applied to data-plane loopback points > residing on interfaces where there may be no corresponding MEP or > MIP." > > For completeness, the references to "MEP or MIP" in paragraphs 3 and 7 > of section 4 would also need to be changed, to instead refer to the > transport path that is being put in to loopback. > > As another data point, I found this text in RFC6371 section 6.3.2: > "It should be noted that data-plane loopback function itself is > applied to data-plane loopback points that can reside on different > interfaces from MIPs/MEPs." > Note the critical difference compared to RFC6435: "that can reside" > instead of "residing". > > Thanks > > > David > > > On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: > > Sami, > > > > Thanks. Yet, I am not sure David's interpretation and mine exactly match. > > David, correct me if I am wrong. For me it says that we can do > > loopback on different interfaces (for different LSPs) but implies that > > there is a mip/mep for that lsp on that interface, while my > > interpretation is that the presence of a mip/mep for that lsp on that > > interface is not needed. > > > > -m > > ________________________________ > > De : Sami Boutros (sboutros) > > Envoy? : 09/01/2013 19:00 > > ? : VIGOUREUX, MARTIN (MARTIN) > > Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco); Siva > Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart > Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; > mpls@ietf.org > > Objet : Re: [Editorial Errata Reported] RFC6435 (3429) > > > > I agree with Martin, the text proposed by David describe more accurately what > we meant. > > > > Thanks, > > > > Sami > > On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > > > > > Adrian, David, > > > > > > what I think we meant here was that a loop-back function could be done on > an interface regardless of the presence of a MIP/MEP on that interface. Yet, I > have to admit that MIP and MEP are used in Section 4 of RFC6435, thus surely > causing confusion. > > > > > > I'd welcome the views/souvenirs of my co-authors. > > > > > > -m > > > > > > Le 12/12/2012 19:17, Adrian Farrel a ?crit : > > >> Hello, > > >> > > >> Authors of RFC 6435: I need to hear from you that you meant the text that > David > > >> suggests. It is very clearly not what you wrote and, if you meant something > > >> different, it is clear why people are confused! > > >> > > >> Working group: I need to hear from you that you agree with David's > > >> interpretation and support his proposed change. > > >> > > >> Only then will I try to work out whether this is a "typo" worthy of an errata > > >> report, or a technical change needing a revised RFC. > > >> > > >> Thanks, > > >> Adrian > > >> > > >>> -----Original Message----- > > >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > >>> Sent: 12 December 2012 17:45 > > >>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > > >>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > > >>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; > swallow@cisco.com; > > >>> rcallon@juniper.net > > >>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org > > >>> Subject: [Editorial Errata Reported] RFC6435 (3429) > > >>> > > >>> > > >>> The following errata report has been submitted for RFC6435, > > >>> "MPLS Transport Profile Lock Instruct and Loopback Functions". > > >>> > > >>> -------------------------------------- > > >>> You may review the report below and at: > > >>> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 > > >>> > > >>> -------------------------------------- > > >>> Type: Editorial > > >>> Reported by: David Ball > > >>> > > >>> Section: 4 (para 5) > > >>> > > >>> Original Text > > >>> ------------- > > >>> It should be noted that the data-plane loopback function itself is applied to > > >> data- > > >>> plane loopback points residing on different interfaces from MIPs/MEPs. > > >>> > > >>> Corrected Text > > >>> -------------- > > >>> It should be noted that the data-plane loopback function may be applied at > > >>> MIPs/MEPs on different interfaces for different LSPs. > > >>> > > >>> Notes > > >>> ----- > > >>> The existing text has caused confusion (specifically, among experts in ITU-T > > >> SG15 > > >>> when discussing G.8121.2), in that it seems to suggest that the interface > > >> where > > >>> the MIP/MEP is located may be a different interface to the one where the > > >>> loopback is applied. > > >>> > > >>> Having spoken with some of the original authors, it seems this was not the > > >> intent > > >>> of this sentence; the intent was to point out that as different LSPs would > > >> have > > >>> MIPs/MEPs on different interfaces, the corresponding loopback functions > would > > >>> also be applied on different interfaces. > > >>> > > >>> 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. > > >>> > > >>> -------------------------------------- > > >>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) > > >>> -------------------------------------- > > >>> Title : MPLS Transport Profile Lock Instruct and Loopback > > >> Functions > > >>> Publication Date : November 2011 > > >>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. > > >> Vigoureux, > > >>> Ed., X. Dai, Ed. > > >>> Category : PROPOSED STANDARD > > >>> Source : Multiprotocol Label Switching > > >>> Area : Routing > > >>> Stream : IETF > > >>> Verifying Party : IESG > > >> > > >> > > > > -- > David Ball > From adrian@olddog.co.uk Wed Jan 16 14:51:09 2013 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 184B211E80A6 for ; Wed, 16 Jan 2013 14:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 Sh9LzhRBdF6P for ; Wed, 16 Jan 2013 14:51:08 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id DB12111E809A for ; Wed, 16 Jan 2013 14:51:07 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0GMp3i3028493; Wed, 16 Jan 2013 22:51:03 GMT Received: from 950129200 (089144192153.atnat0001.highway.a1.net [89.144.192.153]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0GMorvX028385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Jan 2013 22:50:59 GMT From: "Adrian Farrel" To: "'Eric Osborne \(eosborne\)'" , "'Ross Callon'" References: <62CCD4C52ACDAD4481149BD5D8A72FD309A3976C@CH1PRD0510MB355.namprd05.prod.outlook.com> <007401cdf0f4$1f5011c0$5df03540$@olddog.co.uk> <20ECF67871905846A80F77F8F4A27572100A173F@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572100A173F@xmb-rcd-x09.cisco.com> Date: Wed, 16 Jan 2013 22:50:53 -0000 Message-ID: <021f01cdf43b$f4bfa2e0$de3ee8a0$@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: AQGxX1K3ekKKQiWmLJx20drhWdGlKAHQn9QXAffji+yYZ2kVEA== Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] Proposed response to Ring Protection Liaison 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, 16 Jan 2013 22:51:09 -0000 Thanks Eric (proxying for Ross :-) Good progress. [snip] > > It's somehow appropriate to write a liaison to the ITU-T in Microsoft Word :-) > > EO# The LS came in as PDF, but Word's much easier to edit. When it's done we > should probably send it as PDF. Not very used to seeing proprietary format documents on the IETF mailing lists. > > I assume the chairs will top and tail this liaison with the usual polite niceties. In > > particular, we should welcome the way that SG15 is engaging with the MPLS > > working group on ring protection requirements. > > EO# I'm not a chair and am good at neither polite nor nice, so I've left these bits > out of my edits. Fair enough. And I am still sure the chairs will top and tail. [snip] > > This draft does not seem to answer the first noted requirements in the > > incoming liaison viz. > > | Requirements for ITU-T G.8132 > > | Requirements and optimization criteria for ring protection specified > > | in RFC5654 "MPLS-TP requirements" have to be taken into account. > > > > I think this deserves the response: > > We agree that the requirements and optimization criteria for ring protection > > set out in RFC 5654 should be taken into account. In particular, we draw your > > attention to the preamble in Section 2.5.6.1 and the statements made about > > the cost/benefit implications of specialised protection solutions. > > EO# I could go either way on this, but I've added your text. You added an additional sentence. I don't really object, but it puzzles me that you refer to G.8132 when it is enough to address the text in the liaison. [snip] > > I am not a huge fan of holding technical debate via liaison statement. That said > > your observations on T1 and T2 are correct. > > EO# What is the correct vehicle for technical debate? Discussion on the IETF list? > Discussion first followed by a LS to formalize the discussion points? I've added > some text to this effect as a start - "For the technical analysis, we invite the > discussion of these scenarios on the MPLS WG email list, as that may help to > progress a technical solution more effectively than liaison statements." My personal opinion is that we are the IETF and the correct vehicle for technical debates is the appropriate working group mailing list, possibly supported by an IETF draft. I would strike the second half of the sentence. Effectiveness may or may not be relevant. Regardless of that, we invite discussion on the mailing list. > > Later in the discussion of T2 you say: > > > > > The IETF believes that the reuse of linear protection mechanisms in a > > > ring topology (i.e. draft-ietf-mpls-tp-ring-protection) will meet > > > performance targets in a ring topology, and will do so while allowing > > > the operator to deploy a single protection method across all possible > > > network topologies. > > > > I do not believe it is your intention to test IETF consensus on this before > > sending the liaison. You might s/IETF/MPLS working group/ and use the > > review of this liaison statement as the way to test that consensus. > > EO# s/IETF/MPLS WG/ done. I'm going to stay away from the consensus point > on this thread, as that's a whole separate thing, but I do note that the ring > protection doc is a WG draft and thus has at least some level of enthusiasm > behind it. The chairs will need to believe there is WG consensus on this point if they intend to send a liaison statement that says the WG believes something. The chairs might consider that putting this draft liaison statement out for WG review gives enough evidence on which to build that belief. [snip] > > The paragraph on the sophistication of ring-based networks is undoubtedly > > true. Even in traditional transport networks, ring interconnects have made end- > > to-end paths appear to traverse a mesh. The ease with which packet networks > > can bridge between rings makes the meshiness all the more likely. > > > > Notwithstanding that, there is (or it could be argued that there is) value in > > imposing logical protection domains in mesh networks. By treating a portion of > > the mesh network as a logical ring, certain specific ring protection > > characteristics (such as those discussed in draft-ietf-mpls-tp-ring-protection) > > can be leveraged. > > > > So, I am wondering what this paragraph is attempting to add to the liaison. > > EO# This point, I think, is important. > > It was an attempt to say "if we're going to discuss ring-specific mechanisms we > should agree when something is and is not a ring". 'Ring' has very particular > significance in the transport world, and the text was an attempt to draw out that > definition. Some members of the WG (ok...probably just me) do not understand > the distinction between a sufficiently sophisticated ring and a mesh. I'd hate to > come up with an agreement on what ring-specific protection looks like only to > find out post hoc that one side meant "a set of no more than 16 nodes [A---B---C- > --...---P--A] which constitute the entirety of a given ring-specific protection > domain" and the other meant "an arbitrary mesh that has been subdivided into > little circles but with end-to-end protection across the ringmesh" or something > like that. In my opinion understanding the definition is key to scoping the > requirements properly. Yes, but what is the paragraph actually saying to the ITU-T? Would it perhaps be better to ask the ITU-T for a clear definition of what they mean by a ring network considering that rings may be multiply interconnected and overlapping? [Note that changes this into a liaison For Action.] [snip] > > And then, s/The IETF recommends/The MPLS working group recommends/ > > (assuming you have consensus for that) Same point for the chairs to note wrt consensus for this. Thanks for the work. Adrian (an individual again) From zjbdamo@hotmail.com Thu Jan 17 04:32:09 2013 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 6166521F88CB for ; Thu, 17 Jan 2013 04:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.317 X-Spam-Level: **** X-Spam-Status: No, score=4.317 tagged_above=-999 required=5 tests=[AWL=1.616, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_12=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3] 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 t-JgSCdHcrNv for ; Thu, 17 Jan 2013 04:32:08 -0800 (PST) Received: from blu0-omc4-s35.blu0.hotmail.com (blu0-omc4-s35.blu0.hotmail.com [65.55.111.174]) by ietfa.amsl.com (Postfix) with ESMTP id AC2D121F88CA for ; Thu, 17 Jan 2013 04:32:08 -0800 (PST) Received: from BLU168-W55 ([65.55.111.136]) by blu0-omc4-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jan 2013 04:32:08 -0800 X-EIP: [MpBGsCrDaFn6p1i8nj7ASI576AaFskDG] X-Originating-Email: [zjbdamo@hotmail.com] Message-ID: From: =?gb2312?B?1Pi+/rKo?= To: Date: Thu, 17 Jan 2013 20:32:07 +0800 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2013 12:32:08.0085 (UTC) FILETIME=[AA374C50:01CDF4AE] Subject: Re: [mpls] doubt of PW_Path_ID and per-interface MIP id in RFC 6370. 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, 17 Jan 2013 12:32:09 -0000 hi,anyone can give some hints? Best Regards! Junbo Zeng(BoBo) ---------------------------------------- > From: zjbdamo@hotmail.com > To: mpls@ietf.org > Date: Fri, 11 Jan 2013 11:19:18 +0800 > Subject: [mpls] doubt of PW_Path_ID and per-interface MIP id in RFC 6370. > > > > hi,the authors of RFC6370, i have 2 questions about RFC6370 > > 1.in RFC6370 the PW_Path_ID is > defined as AGI::A1-{Global_ID::Node_ID::AC_ID}::Z9-{Global_ID::Node_ID::AC_ID}. > The AC_ID is refer to RFC5003,and the AC_ID is described as below " > Attachment Circuit (AC) ID = This is a fixed-length 4-octet field > used to further refine identification of an attachment circuit on > the PE.The inclusion of the AC ID is used to identify > individual attachment circuits that share a common prefix." > > in vpws the AC and PW is one to one,but in vpls the the AC and PW maybe n to m,so how to fill the PW_Path_ID? > and i suggested that use pwid of FEC128 to replace AC_ID. > > 2.would any volunteer can give me some example of the MIP's id of PW and LSP in per-interface scenario. > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From martin.vigoureux@alcatel-lucent.com Thu Jan 17 04:58:13 2013 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 01EF121F86C9 for ; Thu, 17 Jan 2013 04:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[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 W59Q0S3JtOOy for ; Thu, 17 Jan 2013 04:58:10 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8C021F868F for ; Thu, 17 Jan 2013 04:58:10 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0HCvvEM008871 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Jan 2013 13:58:00 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 17 Jan 2013 13:57:57 +0100 Received: from [172.27.205.205] (135.239.27.12) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 17 Jan 2013 13:57:57 +0100 Message-ID: <50F7F553.1070509@alcatel-lucent.com> Date: Thu, 17 Jan 2013 13:57:55 +0100 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: "adrian@olddog.co.uk" , "'David Ball'" References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> In-Reply-To: <021701cdf42d$72200860$56601920$@olddog.co.uk> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.12] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "'Sami Boutros \(sboutros\)'" , "'Siva Sivabalan \(msiva\)'" , "rcallon@juniper.net" , "raggarwa_1@yahoo.com" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 17 Jan 2013 12:58:13 -0000 Adrian, yes, we are. So, David, I am fine with your suggested text which says: It should be noted that the data-plane loopback function for a given transport path can be applied to data-plane loopback points residing on interfaces where there may be no corresponding MEP or MIP. I was thinking of: s/may be no corresponding MEP or MIP./may be no MEP or MIP for that transport path./ but this is optional. The new text will replace: It should be noted that the data-plane loopback function itself is applied to data-plane loopback points residing on different interfaces from MIPs/MEPs. Regarding the other paragraphs: The loopback function is used to test the integrity of a transport path from a MEP up any other node in the same MEG. This is achieved by setting the target node into loopback mode, and transmitting a pattern of test data from the MEP. The target node loops all received data back toward the originator, and the MEP extracts the test data and compares it with what it sent. Loopback is a function that enables a receiving MEP or MIP to return traffic to the sending MEP when in the loopback state. [...] The management plane must ensure that the two MEPs are locked before it requests setting MEP or MIP in the loopback state. They could be changed into: The loopback function is used to test the integrity of a transport path. This is achieved by setting a given node into loopback mode for a given transport path, and sending over it a pattern of test data. The node in loopback mode loops all test data received on the transport path back towards the sender, which extracts the test data and compares it with what it sent. Loopback is a function which enables a given node of a transport path, when in the loopback mode, to return traffic to the sender of that traffic. [...] The management plane must ensure that the MEPs of a transport path are locked before it requests setting a given node of that transport path in loopback mode. Let me know. -m Le 16/01/2013 22:07, Adrian Farrel a 閏rit : > All, are we getting any closer to agreeing what we all intended to say? > > Once we have that, I can work out what to do with the Errata Report. > > Thanks, > Adrian > >> -----Original Message----- >> From: David Ball [mailto:daviball@cisco.com] >> Sent: 10 January 2013 17:57 >> To: VIGOUREUX, MARTIN (MARTIN) >> Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan (msiva); >> raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant); >> loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org >> Subject: Re: [Editorial Errata Reported] RFC6435 (3429) >> >> Hi Martin, >> >> Ah, right I see: since the loopback is locally configured, there is no >> need for a MEP/MIP to send/receive OAM frames - but there may be a >> MEP/MIP. >> >> So would this work to clarify the text? >> "It should be noted that the data-plane loopback function for a >> given transport path can be applied to data-plane loopback points >> residing on interfaces where there may be no corresponding MEP or >> MIP." >> >> For completeness, the references to "MEP or MIP" in paragraphs 3 and 7 >> of section 4 would also need to be changed, to instead refer to the >> transport path that is being put in to loopback. >> >> As another data point, I found this text in RFC6371 section 6.3.2: >> "It should be noted that data-plane loopback function itself is >> applied to data-plane loopback points that can reside on different >> interfaces from MIPs/MEPs." >> Note the critical difference compared to RFC6435: "that can reside" >> instead of "residing". >> >> Thanks >> >> >> David >> >> >> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: >>> Sami, >>> >>> Thanks. Yet, I am not sure David's interpretation and mine exactly match. >>> David, correct me if I am wrong. For me it says that we can do >>> loopback on different interfaces (for different LSPs) but implies that >>> there is a mip/mep for that lsp on that interface, while my >>> interpretation is that the presence of a mip/mep for that lsp on that >>> interface is not needed. >>> >>> -m >>> ________________________________ >>> De : Sami Boutros (sboutros) >>> Envoy? : 09/01/2013 19:00 >>> ? : VIGOUREUX, MARTIN (MARTIN) >>> Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco); > Siva >> Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart >> Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; >> mpls@ietf.org >>> Objet : Re: [Editorial Errata Reported] RFC6435 (3429) >>> >>> I agree with Martin, the text proposed by David describe more accurately > what >> we meant. >>> >>> Thanks, >>> >>> Sami >>> On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: >>> >>>> Adrian, David, >>>> >>>> what I think we meant here was that a loop-back function could be done on >> an interface regardless of the presence of a MIP/MEP on that interface. Yet, I >> have to admit that MIP and MEP are used in Section 4 of RFC6435, thus surely >> causing confusion. >>>> >>>> I'd welcome the views/souvenirs of my co-authors. >>>> >>>> -m >>>> >>>> Le 12/12/2012 19:17, Adrian Farrel a ?crit : >>>>> Hello, >>>>> >>>>> Authors of RFC 6435: I need to hear from you that you meant the text that >> David >>>>> suggests. It is very clearly not what you wrote and, if you meant > something >>>>> different, it is clear why people are confused! >>>>> >>>>> Working group: I need to hear from you that you agree with David's >>>>> interpretation and support his proposed change. >>>>> >>>>> Only then will I try to work out whether this is a "typo" worthy of an > errata >>>>> report, or a technical change needing a revised RFC. >>>>> >>>>> Thanks, >>>>> Adrian >>>>> >>>>>> -----Original Message----- >>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>> Sent: 12 December 2012 17:45 >>>>>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>>>>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>>>>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; >> swallow@cisco.com; >>>>>> rcallon@juniper.net >>>>>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>>>>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>>>>> >>>>>> >>>>>> The following errata report has been submitted for RFC6435, >>>>>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>>>>> >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 >>>>>> >>>>>> -------------------------------------- >>>>>> Type: Editorial >>>>>> Reported by: David Ball >>>>>> >>>>>> Section: 4 (para 5) >>>>>> >>>>>> Original Text >>>>>> ------------- >>>>>> It should be noted that the data-plane loopback function itself is > applied to >>>>> data- >>>>>> plane loopback points residing on different interfaces from MIPs/MEPs. >>>>>> >>>>>> Corrected Text >>>>>> -------------- >>>>>> It should be noted that the data-plane loopback function may be applied > at >>>>>> MIPs/MEPs on different interfaces for different LSPs. >>>>>> >>>>>> Notes >>>>>> ----- >>>>>> The existing text has caused confusion (specifically, among experts in > ITU-T >>>>> SG15 >>>>>> when discussing G.8121.2), in that it seems to suggest that the > interface >>>>> where >>>>>> the MIP/MEP is located may be a different interface to the one where the >>>>>> loopback is applied. >>>>>> >>>>>> Having spoken with some of the original authors, it seems this was not > the >>>>> intent >>>>>> of this sentence; the intent was to point out that as different LSPs > would >>>>> have >>>>>> MIPs/MEPs on different interfaces, the corresponding loopback functions >> would >>>>>> also be applied on different interfaces. >>>>>> >>>>>> 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. >>>>>> >>>>>> -------------------------------------- >>>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>>>>> -------------------------------------- >>>>>> Title : MPLS Transport Profile Lock Instruct and Loopback >>>>> Functions >>>>>> Publication Date : November 2011 >>>>>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, > Ed., M. >>>>> Vigoureux, >>>>>> Ed., X. Dai, Ed. >>>>>> Category : PROPOSED STANDARD >>>>>> Source : Multiprotocol Label Switching >>>>>> Area : Routing >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >>>>> >>>>> >>> >> >> -- >> David Ball >> > > > From david.i.allan@ericsson.com Thu Jan 17 06:45:09 2013 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 90A0E21F85C8 for ; Thu, 17 Jan 2013 06:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 NFPqMnHvKq5G for ; Thu, 17 Jan 2013 06:45:08 -0800 (PST) Received: from usevmg21.ericsson.net (unknown [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A25E221F85C6 for ; Thu, 17 Jan 2013 06:45:08 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-1a-50f80e73d23e Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E7.6A.03705.37E08F05; Thu, 17 Jan 2013 15:45:08 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 09:45:07 -0500 From: David Allan I To: "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-villamizar-mpls-multipath-use Thread-Index: AQHN88WvPCgtdBp3W0SctMThhNeLfZhMhKjggAEVDvA= Date: Thu, 17 Jan 2013 14:45:06 +0000 Message-ID: References: <50F04AF0.4060906@pi.nu> <50F66865.8000104@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXSPn24J348Ag+lNXBaHD0xnt/g3dw6z xZ1dX1gtvl9awmJxa+lKVgdWj9Zne1k9liz5yeSx+Iufx6zpbWweXy5/ZgtgjeKySUnNySxL LdK3S+DKeD3jKHPBfr6Ku+vqGxiPcncxcnJICJhITLqyjQ3CFpO4cG89kM3FISRwhFHiyszp rBDOckaJ1+t+MoNUsQkYSOz5/4URxBYRUJY4MrEbrIhZYBejxO0/u1hBEsICThLfFs9mgihy lug5+hKogQPItpKYdqwExGQRUJWY2RMGUsEr4C2x7cQBsE4hATuJ3uYzYJ2MQAd9P7UGzGYW EJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKYStLfJ/ziAWiXkdiwe5PbBC2tsSyha+ZIXYJSpyc +YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYOUqLU8ty040MNzECo+iYBJvjDsYFnywPMUpzsCiJ 84a6XggQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJhVsqNGKuzG260plwuk99/haBSXmJPx YG3vaY7KNbuPft8sEl+6NqTHQ2f/79bVmuv97zTIaNhyCxsf/HVl78UXAb/4r+r9eDnjks8d LUab1Sv35jNn/S4pOx72o5Q7MCRXPm3Xe/N92+J1Lj1+eyqOV+j8/xaV9+qXL65iMnEROmoV 2FBsH6XEUpyRaKjFXFScCAC0RELncAIAAA== Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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, 17 Jan 2013 14:45:09 -0000 Hi: I was asked to review this document as part of the review team; the followi= ng are my comments. I think such a document in general has merit and addresses a gap. I believe= the issues that exist with this particular version of such a document are = in the incomplete discussion of a solution in section 3. I'd want to see th= at cleaned up such that it read as a technically viable solution....(see be= low).... Nit: Section 1 para 2: Refers to MPLS-TP packet ordering as the constraint. I'm = a bit confused by this, any aggregate that shares an ordering constraint do= es not get spread across parallel links while a set of traffic COULD be in = theory load spread across a set of MPLS-TP paths so long as individual orde= ring constraints were respected. Is this text document really discussing mi= dbox spreading out of load that respects ordering constraints but would mea= n MPLS-TP OAM no longer fate shared? Should be reworded if so. Clarified o= therwise. Main issue: Section 3: I think this needs a bit of work, it starts to discuss tractable= solutions but IMO is technically incomplete. IF an entropy label and ELI (= where all traffic associated with the MPLS_TP LSP shares a common randomly = selected entropy label value, which is not stated) are the only mechanisms = of ensuring proper treatment (with all transit nodes implementing entropy a= nd ELI processing such that seeking sources of entropy is capped for such L= SPs), and the ingress node (which by some means SHOULD be able to know it i= s a TP LSP as it has layer visibility) and the egress node can strip entrop= y and ELI then a solution exists for proper fate sharing and ordering of a = TP LSP over MPLS. It is IMO not quiet eluciated completely. If I'm unclear on any of the above, am happy to discuss... Cheers Dave From pabloisnot@gmail.com Thu Jan 17 07:07:08 2013 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 6969721F868B for ; Thu, 17 Jan 2013 07:07:08 -0800 (PST) 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 3gt-PQE1wQ7Z for ; Thu, 17 Jan 2013 07:07:07 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7A321F84CC for ; Thu, 17 Jan 2013 07:07:07 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2633622vbb.3 for ; Thu, 17 Jan 2013 07:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pOtbJRdHH9njXRi+Spe5akaM0S7YvHkeg3Vzir+vNyw=; b=JpY7Nh3cBKNTeDEyNzxLVDSziV1Ue6quBlSUm9SdF4PIL1We1qsDjTAbvNA7JwiJUU IqpRzgG0UPzbCZGGmChS/buDPeLuhKAmdJbeGFdXR43E/PDJMy/9V2g4zUC0BPadBbm5 pU2m8AzT3ThPJuXoruWCF0+vFr2apH+or7v/NMXBcx+iDMiKXU2wjpP/mFYyvOimPglP KqdWHNw4Cav5QiXo185sgCumLzs3W1Bqr4Cty4AJruBQMgRi57yd1LT5eV7zCePPtWC7 Q9h5mK8sVgNKxpOFh3mOrFFX+15iq0Ul/HjV82vSbWo+LRyPSn7TaBSj3WtPtBVOn3iw ufEQ== MIME-Version: 1.0 X-Received: by 10.52.16.167 with SMTP id h7mr4912861vdd.117.1358435226694; Thu, 17 Jan 2013 07:07:06 -0800 (PST) Received: by 10.59.6.105 with HTTP; Thu, 17 Jan 2013 07:07:06 -0800 (PST) In-Reply-To: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> References: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> Date: Thu, 17 Jan 2013 10:07:06 -0500 Message-ID: From: Pablo Frank To: loa@pi.nu Content-Type: multipart/alternative; boundary=bcaec50409182335ff04d37d59d2 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] working group last call 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, 17 Jan 2013 15:07:08 -0000 --bcaec50409182335ff04d37d59d2 Content-Type: text/plain; charset=ISO-8859-1 Very useful doc. Support. P On Mon, Jan 14, 2013 at 5:40 AM, wrote: > Working Group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-tp-use-cases-and-design. > > This is the second time we working group last call this > draft, it has been updated after comments during the > ADE-review. The changes are such that we have decided to > do a full two week wglc. > > 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. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not aware > of any IPRs. > > This working group last call will end on January 25, 2013. > > /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 > --bcaec50409182335ff04d37d59d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Very useful doc.
Support.=A0

P

On Mon, Jan 14, 2013 at 5:40 AM, <= loa@pi.nu> wro= te:
Working Group,

this is to start a two week Working Group last call on
draft-ietf-mpls-tp-use-cases-and-design.

This is the second time we working group last call this
draft, it has been updated after comments during the
ADE-review. The changes are such that we have decided to
do a full two week wglc.

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.

There are no IPR claims against this draft.

All the co-authors has stated that they are not aware
of any IPRs.

This working group last call will end on January 25, 2013.

/Loa
for the wg co-chairs

--


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

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

--bcaec50409182335ff04d37d59d2-- From adrian@olddog.co.uk Thu Jan 17 08:53:37 2013 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 6544921F865B for ; Thu, 17 Jan 2013 08:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 AC32clXALi8m for ; Thu, 17 Jan 2013 08:53:36 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9C24C21F8614 for ; Thu, 17 Jan 2013 08:53:36 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0HGrZNS018068; Thu, 17 Jan 2013 16:53:35 GMT Received: from 950129200 (089144192047.atnat0001.highway.a1.net [89.144.192.47]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0HGrTx8017915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Jan 2013 16:53:32 GMT From: "Adrian Farrel" To: , References: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> In-Reply-To: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> Date: Thu, 17 Jan 2013 16:53:29 -0000 Message-ID: <016d01cdf4d3$303726d0$90a57470$@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: AQG9WUMRvI+r0iKEJxc/9TjJfH95EJhu80qA Content-Language: en-gb Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] working group last call 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, 17 Jan 2013 16:53:37 -0000 Hi, Just to short-cut things a bit: I sent the document back to the working group when it was last presented for publication; this version addresses my concerns, although Huub points out an important error in the expansions of MIP and MEP. Thanks, Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > loa@pi.nu > Sent: 14 January 2013 10:41 > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-use-cases-and- > design@tools.ietf.org > Subject: [mpls] working group last call > > Working Group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-tp-use-cases-and-design. > > This is the second time we working group last call this > draft, it has been updated after comments during the > ADE-review. The changes are such that we have decided to > do a full two week wglc. > > 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. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not aware > of any IPRs. > > This working group last call will end on January 25, 2013. > > /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 sboutros@cisco.com Thu Jan 17 08:58:58 2013 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 9435A21F87AB for ; Thu, 17 Jan 2013 08:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.182 X-Spam-Level: X-Spam-Status: No, score=-10.182 tagged_above=-999 required=5 tests=[AWL=0.417, 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 Da0oSLp8KXqV for ; Thu, 17 Jan 2013 08:58:57 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC4A21F8798 for ; Thu, 17 Jan 2013 08:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10428; q=dns/txt; s=iport; t=1358441937; x=1359651537; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zutgS6UXwD7/GjKm2BDlxv7cvq75vn8CQY5lfGVCOjg=; b=ik+zzgg651DPsnexatGLY54mzOm18qU77/PhvglmqKFJriR/sdLlKyXE TdR2iUKqwEzNx9BFOn5NHU7z93M5A4XnIfS6jArAmu50qf0umbl5hRuwL qZI+UqK3LoGWoGbaN+lbvlbXqRZVHp6x1NxH6cJcAJnzIHWA9OUUntVuJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMks+FCtJV2a/2dsb2JhbAAqEgirQZJkFnOCHgEBAQMBaw4FBwQCAQgRBAEBAQodBzITAQkIAgQOBQiHfwMJBgwsujKMCG0Xg0thA4gsjA6NCYUSgnV2cAc3 X-IronPort-AV: E=Sophos;i="4.84,486,1355097600"; d="scan'208";a="163930222" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jan 2013 16:58:54 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0HGwssj030824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 16:58:54 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.163]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 10:58:53 -0600 From: "Sami Boutros (sboutros)" To: Martin Vigoureux Thread-Topic: [Editorial Errata Reported] RFC6435 (3429) Thread-Index: AQHN2JGbr8z20Ev6BkqoT9E++A0mPJgV3TmAgCu+nACAAD2fgP//xZV2gAHMLICACaMWAIABCa+AgABDUgA= Date: Thu, 17 Jan 2013 16:58:52 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F11335339E@xmb-rcd-x08.cisco.com> References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> <50F7F553.1070509@alcatel-lucent.com> In-Reply-To: <50F7F553.1070509@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.2.240] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <850209F0DBB43D41BBCE8175B92996CF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "Siva Sivabalan \(msiva\)" , "raggarwa_1@yahoo.com" , "rcallon@juniper.net" , "David Ball -X \(daviball - Ensoft Ltd at Cisco\)" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 17 Jan 2013 16:58:58 -0000 On Jan 17, 2013, at 4:57 AM, Martin Vigoureux wrote: > Adrian, yes, we are. >=20 > So, David, >=20 > I am fine with your suggested text which says: > It should be noted that the data-plane loopback function for a > given transport path can be applied to data-plane loopback points > residing on interfaces where there may be no corresponding MEP or > MIP. >=20 > I was thinking of: > s/may be no corresponding MEP or MIP./may be no MEP or MIP for that trans= port path./ > but this is optional. >=20 Sami: I think this is more clear to add "for that transport path" > The new text will replace: > It should be noted that the data-plane loopback function itself is > applied to data-plane loopback points residing on different > interfaces from MIPs/MEPs. >=20 >=20 > Regarding the other paragraphs: > The loopback function is used to test the integrity of a transport > path from a MEP up any other node in the same MEG. This is achieved > by setting the target node into loopback mode, and transmitting a > pattern of test data from the MEP. The target node loops all > received data back toward the originator, and the MEP extracts the > test data and compares it with what it sent. >=20 > Loopback is a function that enables a receiving MEP or MIP to return > traffic to the sending MEP when in the loopback state. >=20 > [...] >=20 > The management plane must ensure that the two MEPs are locked before > it requests setting MEP or MIP in the loopback state. >=20 >=20 > They could be changed into: > The loopback function is used to test the integrity of a transport > path. This is achieved by setting a given node into loopback mode > for a given transport path, Sami:=20 I would change "a given node into loopback mode for a given transport path" to=20 "a given node on the transport path in loopback mode" Sami:=20 > and sending over it a pattern of test > data. The node in loopback mode loops all test data received on the > transport path back towards the sender, which extracts the test > data and compares it with what it sent. >=20 > Loopback is a function which enables a given node of a transport Sami:=20 I would change=20 "given node of a transport path" to "given node on a transport path" Sami > path, when in the loopback mode, to return traffic to the sender of > that traffic. >=20 > [...] >=20 > The management plane must ensure that the MEPs of a transport path > are locked before it requests setting a given node of that transport > path in loopback mode. Sami: Aren't we saying that MEPs must exist for the transport path to lock = the Path before putting in Loopback. Sami: Then I would explicitly mention that, saying "MEPs must exist at the = end points of a transport path and the management .." Thanks, Sami >=20 > Let me know. > -m >=20 > Le 16/01/2013 22:07, Adrian Farrel a =E9crit : >> All, are we getting any closer to agreeing what we all intended to say? >>=20 >> Once we have that, I can work out what to do with the Errata Report. >>=20 >> Thanks, >> Adrian >>=20 >>> -----Original Message----- >>> From: David Ball [mailto:daviball@cisco.com] >>> Sent: 10 January 2013 17:57 >>> To: VIGOUREUX, MARTIN (MARTIN) >>> Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan (msiva= ); >>> raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant); >>> loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org >>> Subject: Re: [Editorial Errata Reported] RFC6435 (3429) >>>=20 >>> Hi Martin, >>>=20 >>> Ah, right I see: since the loopback is locally configured, there is no >>> need for a MEP/MIP to send/receive OAM frames - but there may be a >>> MEP/MIP. >>>=20 >>> So would this work to clarify the text? >>> "It should be noted that the data-plane loopback function for a >>> given transport path can be applied to data-plane loopback points >>> residing on interfaces where there may be no corresponding MEP or >>> MIP." >>>=20 >>> For completeness, the references to "MEP or MIP" in paragraphs 3 and 7 >>> of section 4 would also need to be changed, to instead refer to the >>> transport path that is being put in to loopback. >>>=20 >>> As another data point, I found this text in RFC6371 section 6.3.2: >>> "It should be noted that data-plane loopback function itself is >>> applied to data-plane loopback points that can reside on different >>> interfaces from MIPs/MEPs." >>> Note the critical difference compared to RFC6435: "that can reside" >>> instead of "residing". >>>=20 >>> Thanks >>>=20 >>>=20 >>> David >>>=20 >>>=20 >>> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: >>>> Sami, >>>>=20 >>>> Thanks. Yet, I am not sure David's interpretation and mine exactly mat= ch. >>>> David, correct me if I am wrong. For me it says that we can do >>>> loopback on different interfaces (for different LSPs) but implies that >>>> there is a mip/mep for that lsp on that interface, while my >>>> interpretation is that the presence of a mip/mep for that lsp on that >>>> interface is not needed. >>>>=20 >>>> -m >>>> ________________________________ >>>> De : Sami Boutros (sboutros) >>>> Envoy? : 09/01/2013 19:00 >>>> ? : VIGOUREUX, MARTIN (MARTIN) >>>> Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisc= o); >> Siva >>> Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart >>> Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper= .net; >>> mpls@ietf.org >>>> Objet : Re: [Editorial Errata Reported] RFC6435 (3429) >>>>=20 >>>> I agree with Martin, the text proposed by David describe more accurate= ly >> what >>> we meant. >>>>=20 >>>> Thanks, >>>>=20 >>>> Sami >>>> On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: >>>>=20 >>>>> Adrian, David, >>>>>=20 >>>>> what I think we meant here was that a loop-back function could be don= e on >>> an interface regardless of the presence of a MIP/MEP on that interface.= Yet, I >>> have to admit that MIP and MEP are used in Section 4 of RFC6435, thus s= urely >>> causing confusion. >>>>>=20 >>>>> I'd welcome the views/souvenirs of my co-authors. >>>>>=20 >>>>> -m >>>>>=20 >>>>> Le 12/12/2012 19:17, Adrian Farrel a ?crit : >>>>>> Hello, >>>>>>=20 >>>>>> Authors of RFC 6435: I need to hear from you that you meant the text= that >>> David >>>>>> suggests. It is very clearly not what you wrote and, if you meant >> something >>>>>> different, it is clear why people are confused! >>>>>>=20 >>>>>> Working group: I need to hear from you that you agree with David's >>>>>> interpretation and support his proposed change. >>>>>>=20 >>>>>> Only then will I try to work out whether this is a "typo" worthy of = an >> errata >>>>>> report, or a technical change needing a revised RFC. >>>>>>=20 >>>>>> Thanks, >>>>>> Adrian >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>>> Sent: 12 December 2012 17:45 >>>>>>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>>>>>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>>>>>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; >>> swallow@cisco.com; >>>>>>> rcallon@juniper.net >>>>>>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>>>>>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>>>>>>=20 >>>>>>>=20 >>>>>>> The following errata report has been submitted for RFC6435, >>>>>>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>>>>>>=20 >>>>>>> -------------------------------------- >>>>>>> You may review the report below and at: >>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435&eid=3D3429 >>>>>>>=20 >>>>>>> -------------------------------------- >>>>>>> Type: Editorial >>>>>>> Reported by: David Ball >>>>>>>=20 >>>>>>> Section: 4 (para 5) >>>>>>>=20 >>>>>>> Original Text >>>>>>> ------------- >>>>>>> It should be noted that the data-plane loopback function itself is >> applied to >>>>>> data- >>>>>>> plane loopback points residing on different interfaces from MIPs/ME= Ps. >>>>>>>=20 >>>>>>> Corrected Text >>>>>>> -------------- >>>>>>> It should be noted that the data-plane loopback function may be app= lied >> at >>>>>>> MIPs/MEPs on different interfaces for different LSPs. >>>>>>>=20 >>>>>>> Notes >>>>>>> ----- >>>>>>> The existing text has caused confusion (specifically, among experts= in >> ITU-T >>>>>> SG15 >>>>>>> when discussing G.8121.2), in that it seems to suggest that the >> interface >>>>>> where >>>>>>> the MIP/MEP is located may be a different interface to the one wher= e the >>>>>>> loopback is applied. >>>>>>>=20 >>>>>>> Having spoken with some of the original authors, it seems this was = not >> the >>>>>> intent >>>>>>> of this sentence; the intent was to point out that as different LSP= s >> would >>>>>> have >>>>>>> MIPs/MEPs on different interfaces, the corresponding loopback funct= ions >>> would >>>>>>> also be applied on different interfaces. >>>>>>>=20 >>>>>>> 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 >>>>>>> -------------------------------------- >>>>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>>>>>> -------------------------------------- >>>>>>> Title : MPLS Transport Profile Lock Instruct and Loop= back >>>>>> Functions >>>>>>> Publication Date : November 2011 >>>>>>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarw= al, >> Ed., M. >>>>>> Vigoureux, >>>>>>> Ed., X. Dai, Ed. >>>>>>> Category : PROPOSED STANDARD >>>>>>> Source : Multiprotocol Label Switching >>>>>>> Area : Routing >>>>>>> Stream : IETF >>>>>>> Verifying Party : IESG >>>>>>=20 >>>>>>=20 >>>>=20 >>>=20 >>> -- >>> David Ball >>> >>=20 >>=20 >>=20 From daviball@cisco.com Thu Jan 17 09:09:39 2013 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 ED74D21F849A for ; Thu, 17 Jan 2013 09:09:38 -0800 (PST) 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 rOSXncLPjXPM for ; Thu, 17 Jan 2013 09:09:37 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 16AC621F883A for ; Thu, 17 Jan 2013 09:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10608; q=dns/txt; s=iport; t=1358442577; x=1359652177; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=z0cmZ4xwSbSiDQIjBbisNjooO2y8Hcf+0yRHLO3gDIs=; b=iG+4pGxB4GoduKtVMYlMgKC3gV363D0l9VdVemfji1TiwjGNq/4Gy1uV ICEctMmtyzHKJzp5NHd5ssAj6jrt1bcL+x2RLMEOvA6dWukOypDQ9yg2v xzkX8rNKhjjBpwGBZDJpf0x2tCUuYoMSNWIcM/5bQUJ+59Kw8PqJOSiZ/ o=; X-IronPort-AV: E=Sophos;i="4.84,486,1355097600"; d="scan'208";a="11165684" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 17 Jan 2013 17:09:35 +0000 Received: from ensoft-linux3.cisco.com (ensoft-linux3.cisco.com [10.63.23.12]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0HH9Zen013334 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 17:09:35 GMT Received: from daviball by ensoft-linux3.cisco.com with local (Exim 4.76) (envelope-from ) id 1Tvsy6-0004nO-6J; Thu, 17 Jan 2013 17:09:34 +0000 Date: Thu, 17 Jan 2013 17:09:34 +0000 From: David Ball To: Martin Vigoureux Message-ID: <20130117170933.GN25804@cisco.com> References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> <50F7F553.1070509@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F7F553.1070509@alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "'Sami Boutros \(sboutros\)'" , "'Siva Sivabalan \(msiva\)'" , "raggarwa_1@yahoo.com" , "rcallon@juniper.net" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 17 Jan 2013 17:09:39 -0000 Thanks Martin. Regarding the first paragraph, I agree with your change to add "for that transport path", that does make it clearer. Regarding the other paragraphs: We have agreed that the intent was that the point doing the loopback does not have to be a MEP or MIP, but your proposal also seems to change it so that the point transmitting the test data does not have to be a MEP. I think the original text was consistent that the test was done *from* a MEP; the question was whether it was done from a MEP *to another MEP/MIP*, or from a MEP *to an arbitrary point*. So you might be right that the text describing the source of the test should also be changed, but I think that is a slightly separate issue. It is probably safest to keep the changes to a minimum and just fix the description of the point that is doing the loopback, ie the target of the test. Do you agree? David On Thu, Jan 17, 2013, Martin Vigoureux wrote: > Adrian, yes, we are. > > So, David, > > I am fine with your suggested text which says: > It should be noted that the data-plane loopback function for a > given transport path can be applied to data-plane loopback points > residing on interfaces where there may be no corresponding MEP or > MIP. > > I was thinking of: > s/may be no corresponding MEP or MIP./may be no MEP or MIP for that > transport path./ > but this is optional. > > The new text will replace: > It should be noted that the data-plane loopback function itself is > applied to data-plane loopback points residing on different > interfaces from MIPs/MEPs. > > > Regarding the other paragraphs: > The loopback function is used to test the integrity of a transport > path from a MEP up any other node in the same MEG. This is achieved > by setting the target node into loopback mode, and transmitting a > pattern of test data from the MEP. The target node loops all > received data back toward the originator, and the MEP extracts the > test data and compares it with what it sent. > > Loopback is a function that enables a receiving MEP or MIP to return > traffic to the sending MEP when in the loopback state. > > [...] > > The management plane must ensure that the two MEPs are locked before > it requests setting MEP or MIP in the loopback state. > > > They could be changed into: > The loopback function is used to test the integrity of a transport > path. This is achieved by setting a given node into loopback mode > for a given transport path, and sending over it a pattern of test > data. The node in loopback mode loops all test data received on the > transport path back towards the sender, which extracts the test > data and compares it with what it sent. > > Loopback is a function which enables a given node of a transport > path, when in the loopback mode, to return traffic to the sender of > that traffic. > > [...] > > The management plane must ensure that the MEPs of a transport path > are locked before it requests setting a given node of that transport > path in loopback mode. > > Let me know. > -m > > Le 16/01/2013 22:07, Adrian Farrel a ?crit : > >All, are we getting any closer to agreeing what we all intended to say? > > > >Once we have that, I can work out what to do with the Errata Report. > > > >Thanks, > >Adrian > > > >>-----Original Message----- > >>From: David Ball [mailto:daviball@cisco.com] > >>Sent: 10 January 2013 17:57 > >>To: VIGOUREUX, MARTIN (MARTIN) > >>Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan (msiva); > >>raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant); > >>loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org > >>Subject: Re: [Editorial Errata Reported] RFC6435 (3429) > >> > >>Hi Martin, > >> > >>Ah, right I see: since the loopback is locally configured, there is no > >>need for a MEP/MIP to send/receive OAM frames - but there may be a > >>MEP/MIP. > >> > >>So would this work to clarify the text? > >> "It should be noted that the data-plane loopback function for a > >> given transport path can be applied to data-plane loopback points > >> residing on interfaces where there may be no corresponding MEP or > >> MIP." > >> > >>For completeness, the references to "MEP or MIP" in paragraphs 3 and 7 > >>of section 4 would also need to be changed, to instead refer to the > >>transport path that is being put in to loopback. > >> > >>As another data point, I found this text in RFC6371 section 6.3.2: > >> "It should be noted that data-plane loopback function itself is > >> applied to data-plane loopback points that can reside on different > >> interfaces from MIPs/MEPs." > >>Note the critical difference compared to RFC6435: "that can reside" > >>instead of "residing". > >> > >>Thanks > >> > >> > >> David > >> > >> > >>On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: > >>>Sami, > >>> > >>>Thanks. Yet, I am not sure David's interpretation and mine exactly match. > >>>David, correct me if I am wrong. For me it says that we can do > >>>loopback on different interfaces (for different LSPs) but implies that > >>>there is a mip/mep for that lsp on that interface, while my > >>>interpretation is that the presence of a mip/mep for that lsp on that > >>>interface is not needed. > >>> > >>>-m > >>>________________________________ > >>>De : Sami Boutros (sboutros) > >>>Envoy? : 09/01/2013 19:00 > >>>? : VIGOUREUX, MARTIN (MARTIN) > >>>Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco); > >Siva > >>Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart > >>Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; > >>mpls@ietf.org > >>>Objet : Re: [Editorial Errata Reported] RFC6435 (3429) > >>> > >>>I agree with Martin, the text proposed by David describe more accurately > >what > >>we meant. > >>> > >>>Thanks, > >>> > >>>Sami > >>>On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > >>> > >>>>Adrian, David, > >>>> > >>>>what I think we meant here was that a loop-back function could be done on > >>an interface regardless of the presence of a MIP/MEP on that interface. Yet, I > >>have to admit that MIP and MEP are used in Section 4 of RFC6435, thus surely > >>causing confusion. > >>>> > >>>>I'd welcome the views/souvenirs of my co-authors. > >>>> > >>>>-m > >>>> > >>>>Le 12/12/2012 19:17, Adrian Farrel a ?crit : > >>>>>Hello, > >>>>> > >>>>>Authors of RFC 6435: I need to hear from you that you meant the text that > >>David > >>>>>suggests. It is very clearly not what you wrote and, if you meant > >something > >>>>>different, it is clear why people are confused! > >>>>> > >>>>>Working group: I need to hear from you that you agree with David's > >>>>>interpretation and support his proposed change. > >>>>> > >>>>>Only then will I try to work out whether this is a "typo" worthy of an > >errata > >>>>>report, or a technical change needing a revised RFC. > >>>>> > >>>>>Thanks, > >>>>>Adrian > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>>>>>Sent: 12 December 2012 17:45 > >>>>>>To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > >>>>>>martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > >>>>>>stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; > >>swallow@cisco.com; > >>>>>>rcallon@juniper.net > >>>>>>Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org > >>>>>>Subject: [Editorial Errata Reported] RFC6435 (3429) > >>>>>> > >>>>>> > >>>>>>The following errata report has been submitted for RFC6435, > >>>>>>"MPLS Transport Profile Lock Instruct and Loopback Functions". > >>>>>> > >>>>>>-------------------------------------- > >>>>>>You may review the report below and at: > >>>>>>http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 > >>>>>> > >>>>>>-------------------------------------- > >>>>>>Type: Editorial > >>>>>>Reported by: David Ball > >>>>>> > >>>>>>Section: 4 (para 5) > >>>>>> > >>>>>>Original Text > >>>>>>------------- > >>>>>>It should be noted that the data-plane loopback function itself is > >applied to > >>>>>data- > >>>>>>plane loopback points residing on different interfaces from MIPs/MEPs. > >>>>>> > >>>>>>Corrected Text > >>>>>>-------------- > >>>>>>It should be noted that the data-plane loopback function may be applied > >at > >>>>>>MIPs/MEPs on different interfaces for different LSPs. > >>>>>> > >>>>>>Notes > >>>>>>----- > >>>>>>The existing text has caused confusion (specifically, among experts in > >ITU-T > >>>>>SG15 > >>>>>>when discussing G.8121.2), in that it seems to suggest that the > >interface > >>>>>where > >>>>>>the MIP/MEP is located may be a different interface to the one where the > >>>>>>loopback is applied. > >>>>>> > >>>>>>Having spoken with some of the original authors, it seems this was not > >the > >>>>>intent > >>>>>>of this sentence; the intent was to point out that as different LSPs > >would > >>>>>have > >>>>>>MIPs/MEPs on different interfaces, the corresponding loopback functions > >>would > >>>>>>also be applied on different interfaces. > >>>>>> > >>>>>>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. > >>>>>> > >>>>>>-------------------------------------- > >>>>>>RFC6435 (draft-ietf-mpls-tp-li-lb-08) > >>>>>>-------------------------------------- > >>>>>>Title : MPLS Transport Profile Lock Instruct and Loopback > >>>>>Functions > >>>>>>Publication Date : November 2011 > >>>>>>Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, > >Ed., M. > >>>>>Vigoureux, > >>>>>>Ed., X. Dai, Ed. > >>>>>>Category : PROPOSED STANDARD > >>>>>>Source : Multiprotocol Label Switching > >>>>>>Area : Routing > >>>>>>Stream : IETF > >>>>>>Verifying Party : IESG > >>>>> > >>>>> > >>> > >> > >>-- > >>David Ball > >> > > > > > > -- David Ball From martin.vigoureux@alcatel-lucent.com Thu Jan 17 09:18:08 2013 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 1098221F854D for ; Thu, 17 Jan 2013 09:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[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 grAnzXmtSNA7 for ; Thu, 17 Jan 2013 09:18:07 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id A603E21F8C3D for ; Thu, 17 Jan 2013 09:18:06 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0HHI1hD005287 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Jan 2013 18:18:03 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 17 Jan 2013 18:18:02 +0100 Received: from [172.27.205.205] (135.239.27.11) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 17 Jan 2013 18:18:02 +0100 Message-ID: <50F83247.7050000@alcatel-lucent.com> Date: Thu, 17 Jan 2013 18:17:59 +0100 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: David Ball References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> <50F7F553.1070509@alcatel-lucent.com> <20130117170933.GN25804@cisco.com> In-Reply-To: <20130117170933.GN25804@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.11] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "'Sami Boutros \(sboutros\)'" , "'Siva Sivabalan \(msiva\)'" , "raggarwa_1@yahoo.com" , "rcallon@juniper.net" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 17 Jan 2013 17:18:08 -0000 David, agreed, and in fact this is consistent with the fact I kept MEP in the last paragraph I changed. -m Le 17/01/2013 18:09, David Ball a 閏rit : > Thanks Martin. > > Regarding the first paragraph, I agree with your change to add "for that > transport path", that does make it clearer. > > Regarding the other paragraphs: We have agreed that the intent was that > the point doing the loopback does not have to be a MEP or MIP, but your > proposal also seems to change it so that the point transmitting the > test data does not have to be a MEP. I think the original text was > consistent that the test was done *from* a MEP; the question was whether > it was done from a MEP *to another MEP/MIP*, or from a MEP *to an > arbitrary point*. > > So you might be right that the text describing the source of the test > should also be changed, but I think that is a slightly separate issue. > It is probably safest to keep the changes to a minimum and just fix the > description of the point that is doing the loopback, ie the target of > the test. > > Do you agree? > > > David > > > On Thu, Jan 17, 2013, Martin Vigoureux wrote: >> Adrian, yes, we are. >> >> So, David, >> >> I am fine with your suggested text which says: >> It should be noted that the data-plane loopback function for a >> given transport path can be applied to data-plane loopback points >> residing on interfaces where there may be no corresponding MEP or >> MIP. >> >> I was thinking of: >> s/may be no corresponding MEP or MIP./may be no MEP or MIP for that >> transport path./ >> but this is optional. >> >> The new text will replace: >> It should be noted that the data-plane loopback function itself is >> applied to data-plane loopback points residing on different >> interfaces from MIPs/MEPs. >> >> >> Regarding the other paragraphs: >> The loopback function is used to test the integrity of a transport >> path from a MEP up any other node in the same MEG. This is achieved >> by setting the target node into loopback mode, and transmitting a >> pattern of test data from the MEP. The target node loops all >> received data back toward the originator, and the MEP extracts the >> test data and compares it with what it sent. >> >> Loopback is a function that enables a receiving MEP or MIP to return >> traffic to the sending MEP when in the loopback state. >> >> [...] >> >> The management plane must ensure that the two MEPs are locked before >> it requests setting MEP or MIP in the loopback state. >> >> >> They could be changed into: >> The loopback function is used to test the integrity of a transport >> path. This is achieved by setting a given node into loopback mode >> for a given transport path, and sending over it a pattern of test >> data. The node in loopback mode loops all test data received on the >> transport path back towards the sender, which extracts the test >> data and compares it with what it sent. >> >> Loopback is a function which enables a given node of a transport >> path, when in the loopback mode, to return traffic to the sender of >> that traffic. >> >> [...] >> >> The management plane must ensure that the MEPs of a transport path >> are locked before it requests setting a given node of that transport >> path in loopback mode. >> >> Let me know. >> -m >> >> Le 16/01/2013 22:07, Adrian Farrel a ?crit : >>> All, are we getting any closer to agreeing what we all intended to say? >>> >>> Once we have that, I can work out what to do with the Errata Report. >>> >>> Thanks, >>> Adrian >>> >>>> -----Original Message----- >>>> From: David Ball [mailto:daviball@cisco.com] >>>> Sent: 10 January 2013 17:57 >>>> To: VIGOUREUX, MARTIN (MARTIN) >>>> Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan (msiva); >>>> raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant); >>>> loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org >>>> Subject: Re: [Editorial Errata Reported] RFC6435 (3429) >>>> >>>> Hi Martin, >>>> >>>> Ah, right I see: since the loopback is locally configured, there is no >>>> need for a MEP/MIP to send/receive OAM frames - but there may be a >>>> MEP/MIP. >>>> >>>> So would this work to clarify the text? >>>> "It should be noted that the data-plane loopback function for a >>>> given transport path can be applied to data-plane loopback points >>>> residing on interfaces where there may be no corresponding MEP or >>>> MIP." >>>> >>>> For completeness, the references to "MEP or MIP" in paragraphs 3 and 7 >>>> of section 4 would also need to be changed, to instead refer to the >>>> transport path that is being put in to loopback. >>>> >>>> As another data point, I found this text in RFC6371 section 6.3.2: >>>> "It should be noted that data-plane loopback function itself is >>>> applied to data-plane loopback points that can reside on different >>>> interfaces from MIPs/MEPs." >>>> Note the critical difference compared to RFC6435: "that can reside" >>>> instead of "residing". >>>> >>>> Thanks >>>> >>>> >>>> David >>>> >>>> >>>> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: >>>>> Sami, >>>>> >>>>> Thanks. Yet, I am not sure David's interpretation and mine exactly match. >>>>> David, correct me if I am wrong. For me it says that we can do >>>>> loopback on different interfaces (for different LSPs) but implies that >>>>> there is a mip/mep for that lsp on that interface, while my >>>>> interpretation is that the presence of a mip/mep for that lsp on that >>>>> interface is not needed. >>>>> >>>>> -m >>>>> ________________________________ >>>>> De : Sami Boutros (sboutros) >>>>> Envoy? : 09/01/2013 19:00 >>>>> ? : VIGOUREUX, MARTIN (MARTIN) >>>>> Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco); >>> Siva >>>> Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart >>>> Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; >>>> mpls@ietf.org >>>>> Objet : Re: [Editorial Errata Reported] RFC6435 (3429) >>>>> >>>>> I agree with Martin, the text proposed by David describe more accurately >>> what >>>> we meant. >>>>> >>>>> Thanks, >>>>> >>>>> Sami >>>>> On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: >>>>> >>>>>> Adrian, David, >>>>>> >>>>>> what I think we meant here was that a loop-back function could be done on >>>> an interface regardless of the presence of a MIP/MEP on that interface. Yet, I >>>> have to admit that MIP and MEP are used in Section 4 of RFC6435, thus surely >>>> causing confusion. >>>>>> >>>>>> I'd welcome the views/souvenirs of my co-authors. >>>>>> >>>>>> -m >>>>>> >>>>>> Le 12/12/2012 19:17, Adrian Farrel a ?crit : >>>>>>> Hello, >>>>>>> >>>>>>> Authors of RFC 6435: I need to hear from you that you meant the text that >>>> David >>>>>>> suggests. It is very clearly not what you wrote and, if you meant >>> something >>>>>>> different, it is clear why people are confused! >>>>>>> >>>>>>> Working group: I need to hear from you that you agree with David's >>>>>>> interpretation and support his proposed change. >>>>>>> >>>>>>> Only then will I try to work out whether this is a "typo" worthy of an >>> errata >>>>>>> report, or a technical change needing a revised RFC. >>>>>>> >>>>>>> Thanks, >>>>>>> Adrian >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>>>> Sent: 12 December 2012 17:45 >>>>>>>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>>>>>>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>>>>>>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; >>>> swallow@cisco.com; >>>>>>>> rcallon@juniper.net >>>>>>>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>>>>>>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>>>>>>> >>>>>>>> >>>>>>>> The following errata report has been submitted for RFC6435, >>>>>>>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>>>>>>> >>>>>>>> -------------------------------------- >>>>>>>> You may review the report below and at: >>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 >>>>>>>> >>>>>>>> -------------------------------------- >>>>>>>> Type: Editorial >>>>>>>> Reported by: David Ball >>>>>>>> >>>>>>>> Section: 4 (para 5) >>>>>>>> >>>>>>>> Original Text >>>>>>>> ------------- >>>>>>>> It should be noted that the data-plane loopback function itself is >>> applied to >>>>>>> data- >>>>>>>> plane loopback points residing on different interfaces from MIPs/MEPs. >>>>>>>> >>>>>>>> Corrected Text >>>>>>>> -------------- >>>>>>>> It should be noted that the data-plane loopback function may be applied >>> at >>>>>>>> MIPs/MEPs on different interfaces for different LSPs. >>>>>>>> >>>>>>>> Notes >>>>>>>> ----- >>>>>>>> The existing text has caused confusion (specifically, among experts in >>> ITU-T >>>>>>> SG15 >>>>>>>> when discussing G.8121.2), in that it seems to suggest that the >>> interface >>>>>>> where >>>>>>>> the MIP/MEP is located may be a different interface to the one where the >>>>>>>> loopback is applied. >>>>>>>> >>>>>>>> Having spoken with some of the original authors, it seems this was not >>> the >>>>>>> intent >>>>>>>> of this sentence; the intent was to point out that as different LSPs >>> would >>>>>>> have >>>>>>>> MIPs/MEPs on different interfaces, the corresponding loopback functions >>>> would >>>>>>>> also be applied on different interfaces. >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> -------------------------------------- >>>>>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>>>>>>> -------------------------------------- >>>>>>>> Title : MPLS Transport Profile Lock Instruct and Loopback >>>>>>> Functions >>>>>>>> Publication Date : November 2011 >>>>>>>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, >>> Ed., M. >>>>>>> Vigoureux, >>>>>>>> Ed., X. Dai, Ed. >>>>>>>> Category : PROPOSED STANDARD >>>>>>>> Source : Multiprotocol Label Switching >>>>>>>> Area : Routing >>>>>>>> Stream : IETF >>>>>>>> Verifying Party : IESG >>>>>>> >>>>>>> >>>>> >>>> >>>> -- >>>> David Ball >>>> >>> >>> >>> > From sboutros@cisco.com Thu Jan 17 09:32:42 2013 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 4F72F21F8586 for ; Thu, 17 Jan 2013 09:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.321 X-Spam-Level: X-Spam-Status: No, score=-10.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 Mvg8yQ4rXk+a for ; Thu, 17 Jan 2013 09:32:41 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E334121F854C for ; Thu, 17 Jan 2013 09:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11811; q=dns/txt; s=iport; t=1358443961; x=1359653561; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wuIo3iVBwmV1kPYFNN4jjOi+UtX6GfetdW9lmvdqoNc=; b=D+q9FzbjguW/uDzOEes/u6OU9uxr5y+JK5GCHmdFtHk10WPV67nJ7xUt hA6toZPWCSPk8DNCdAXuuqmEoPIdeJN/GIv62aCh9U6ox94uwd99tvVtC UDyzZNepGbNOIot0QObeMbICAnijE7En5/05OBylFqYUzHlw9QaTwH7F4 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALI0+FCtJXG+/2dsb2JhbAAqEgirQZJkFnOCHgEBAQMBaw4FBwQCAQgRBAEBAQodBzITAQkIAgQOBQiHfwMJBgwsukWMCG0Xg0thA4gsjA6NCYUSgnV2cAc3 X-IronPort-AV: E=Sophos;i="4.84,486,1355097600"; d="scan'208";a="163991913" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 17 Jan 2013 17:32:40 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0HHWebE026380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 17:32:40 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.163]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 11:32:39 -0600 From: "Sami Boutros (sboutros)" To: Martin Vigoureux Thread-Topic: [Editorial Errata Reported] RFC6435 (3429) Thread-Index: AQHN2JGbr8z20Ev6BkqoT9E++A0mPJgV3TmAgCu+nACAAD2fgP//xZV2gAHMLICACaMWAIABCa+AgABGTwCAAAJagIAABBmA Date: Thu, 17 Jan 2013 17:32:39 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F113355820@xmb-rcd-x08.cisco.com> References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> <50F7F553.1070509@alcatel-lucent.com> <20130117170933.GN25804@cisco.com> <50F83247.7050000@alcatel-lucent.com> In-Reply-To: <50F83247.7050000@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.2.240] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <806D776CBE4ED144AC2628EA289595A9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "Siva Sivabalan \(msiva\)" , "raggarwa_1@yahoo.com" , "rcallon@juniper.net" , "David Ball -X \(daviball - Ensoft Ltd at Cisco\)" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 17 Jan 2013 17:32:42 -0000 Martin, I think the other paragraphs edits shouldn't be included in the ERRATA, the= idea of sending test traffic not from a MEP we have not discussed before. Thanks, Sami On Jan 17, 2013, at 9:17 AM, Martin Vigoureux wrote: > David, >=20 > agreed, and in fact this is consistent with the fact I kept MEP in the la= st paragraph I changed. >=20 > -m >=20 >=20 > Le 17/01/2013 18:09, David Ball a =E9crit : >> Thanks Martin. >>=20 >> Regarding the first paragraph, I agree with your change to add "for that >> transport path", that does make it clearer. >>=20 >> Regarding the other paragraphs: We have agreed that the intent was that >> the point doing the loopback does not have to be a MEP or MIP, but your >> proposal also seems to change it so that the point transmitting the >> test data does not have to be a MEP. I think the original text was >> consistent that the test was done *from* a MEP; the question was whether >> it was done from a MEP *to another MEP/MIP*, or from a MEP *to an >> arbitrary point*. >>=20 >> So you might be right that the text describing the source of the test >> should also be changed, but I think that is a slightly separate issue. >> It is probably safest to keep the changes to a minimum and just fix the >> description of the point that is doing the loopback, ie the target of >> the test. >>=20 >> Do you agree? >>=20 >>=20 >> David >>=20 >>=20 >> On Thu, Jan 17, 2013, Martin Vigoureux wrote: >>> Adrian, yes, we are. >>>=20 >>> So, David, >>>=20 >>> I am fine with your suggested text which says: >>> It should be noted that the data-plane loopback function for a >>> given transport path can be applied to data-plane loopback points >>> residing on interfaces where there may be no corresponding MEP or >>> MIP. >>>=20 >>> I was thinking of: >>> s/may be no corresponding MEP or MIP./may be no MEP or MIP for that >>> transport path./ >>> but this is optional. >>>=20 >>> The new text will replace: >>> It should be noted that the data-plane loopback function itself is >>> applied to data-plane loopback points residing on different >>> interfaces from MIPs/MEPs. >>>=20 >>>=20 >>> Regarding the other paragraphs: >>> The loopback function is used to test the integrity of a transport >>> path from a MEP up any other node in the same MEG. This is achieved >>> by setting the target node into loopback mode, and transmitting a >>> pattern of test data from the MEP. The target node loops all >>> received data back toward the originator, and the MEP extracts the >>> test data and compares it with what it sent. >>>=20 >>> Loopback is a function that enables a receiving MEP or MIP to return >>> traffic to the sending MEP when in the loopback state. >>>=20 >>> [...] >>>=20 >>> The management plane must ensure that the two MEPs are locked before >>> it requests setting MEP or MIP in the loopback state. >>>=20 >>>=20 >>> They could be changed into: >>> The loopback function is used to test the integrity of a transport >>> path. This is achieved by setting a given node into loopback mode >>> for a given transport path, and sending over it a pattern of test >>> data. The node in loopback mode loops all test data received on the >>> transport path back towards the sender, which extracts the test >>> data and compares it with what it sent. >>>=20 >>> Loopback is a function which enables a given node of a transport >>> path, when in the loopback mode, to return traffic to the sender of >>> that traffic. >>>=20 >>> [...] >>>=20 >>> The management plane must ensure that the MEPs of a transport path >>> are locked before it requests setting a given node of that transport >>> path in loopback mode. >>>=20 >>> Let me know. >>> -m >>>=20 >>> Le 16/01/2013 22:07, Adrian Farrel a ?crit : >>>> All, are we getting any closer to agreeing what we all intended to say= ? >>>>=20 >>>> Once we have that, I can work out what to do with the Errata Report. >>>>=20 >>>> Thanks, >>>> Adrian >>>>=20 >>>>> -----Original Message----- >>>>> From: David Ball [mailto:daviball@cisco.com] >>>>> Sent: 10 January 2013 17:57 >>>>> To: VIGOUREUX, MARTIN (MARTIN) >>>>> Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan (msi= va); >>>>> raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant= ); >>>>> loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.o= rg >>>>> Subject: Re: [Editorial Errata Reported] RFC6435 (3429) >>>>>=20 >>>>> Hi Martin, >>>>>=20 >>>>> Ah, right I see: since the loopback is locally configured, there is n= o >>>>> need for a MEP/MIP to send/receive OAM frames - but there may be a >>>>> MEP/MIP. >>>>>=20 >>>>> So would this work to clarify the text? >>>>> "It should be noted that the data-plane loopback function for a >>>>> given transport path can be applied to data-plane loopback points >>>>> residing on interfaces where there may be no corresponding MEP or >>>>> MIP." >>>>>=20 >>>>> For completeness, the references to "MEP or MIP" in paragraphs 3 and = 7 >>>>> of section 4 would also need to be changed, to instead refer to the >>>>> transport path that is being put in to loopback. >>>>>=20 >>>>> As another data point, I found this text in RFC6371 section 6.3.2: >>>>> "It should be noted that data-plane loopback function itself is >>>>> applied to data-plane loopback points that can reside on different >>>>> interfaces from MIPs/MEPs." >>>>> Note the critical difference compared to RFC6435: "that can reside" >>>>> instead of "residing". >>>>>=20 >>>>> Thanks >>>>>=20 >>>>>=20 >>>>> David >>>>>=20 >>>>>=20 >>>>> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: >>>>>> Sami, >>>>>>=20 >>>>>> Thanks. Yet, I am not sure David's interpretation and mine exactly m= atch. >>>>>> David, correct me if I am wrong. For me it says that we can do >>>>>> loopback on different interfaces (for different LSPs) but implies th= at >>>>>> there is a mip/mep for that lsp on that interface, while my >>>>>> interpretation is that the presence of a mip/mep for that lsp on tha= t >>>>>> interface is not needed. >>>>>>=20 >>>>>> -m >>>>>> ________________________________ >>>>>> De : Sami Boutros (sboutros) >>>>>> Envoy? : 09/01/2013 19:00 >>>>>> ? : VIGOUREUX, MARTIN (MARTIN) >>>>>> Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Ci= sco); >>>> Siva >>>>> Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewa= rt >>>>> Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@junip= er.net; >>>>> mpls@ietf.org >>>>>> Objet : Re: [Editorial Errata Reported] RFC6435 (3429) >>>>>>=20 >>>>>> I agree with Martin, the text proposed by David describe more accura= tely >>>> what >>>>> we meant. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Sami >>>>>> On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: >>>>>>=20 >>>>>>> Adrian, David, >>>>>>>=20 >>>>>>> what I think we meant here was that a loop-back function could be d= one on >>>>> an interface regardless of the presence of a MIP/MEP on that interfac= e. Yet, I >>>>> have to admit that MIP and MEP are used in Section 4 of RFC6435, thus= surely >>>>> causing confusion. >>>>>>>=20 >>>>>>> I'd welcome the views/souvenirs of my co-authors. >>>>>>>=20 >>>>>>> -m >>>>>>>=20 >>>>>>> Le 12/12/2012 19:17, Adrian Farrel a ?crit : >>>>>>>> Hello, >>>>>>>>=20 >>>>>>>> Authors of RFC 6435: I need to hear from you that you meant the te= xt that >>>>> David >>>>>>>> suggests. It is very clearly not what you wrote and, if you meant >>>> something >>>>>>>> different, it is clear why people are confused! >>>>>>>>=20 >>>>>>>> Working group: I need to hear from you that you agree with David's >>>>>>>> interpretation and support his proposed change. >>>>>>>>=20 >>>>>>>> Only then will I try to work out whether this is a "typo" worthy o= f an >>>> errata >>>>>>>> report, or a technical change needing a revised RFC. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Adrian >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>>>>> Sent: 12 December 2012 17:45 >>>>>>>>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>>>>>>>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>>>>>>>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; >>>>> swallow@cisco.com; >>>>>>>>> rcallon@juniper.net >>>>>>>>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>>>>>>>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The following errata report has been submitted for RFC6435, >>>>>>>>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>>>>>>>>=20 >>>>>>>>> -------------------------------------- >>>>>>>>> You may review the report below and at: >>>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435&eid=3D3429 >>>>>>>>>=20 >>>>>>>>> -------------------------------------- >>>>>>>>> Type: Editorial >>>>>>>>> Reported by: David Ball >>>>>>>>>=20 >>>>>>>>> Section: 4 (para 5) >>>>>>>>>=20 >>>>>>>>> Original Text >>>>>>>>> ------------- >>>>>>>>> It should be noted that the data-plane loopback function itself i= s >>>> applied to >>>>>>>> data- >>>>>>>>> plane loopback points residing on different interfaces from MIPs/= MEPs. >>>>>>>>>=20 >>>>>>>>> Corrected Text >>>>>>>>> -------------- >>>>>>>>> It should be noted that the data-plane loopback function may be a= pplied >>>> at >>>>>>>>> MIPs/MEPs on different interfaces for different LSPs. >>>>>>>>>=20 >>>>>>>>> Notes >>>>>>>>> ----- >>>>>>>>> The existing text has caused confusion (specifically, among exper= ts in >>>> ITU-T >>>>>>>> SG15 >>>>>>>>> when discussing G.8121.2), in that it seems to suggest that the >>>> interface >>>>>>>> where >>>>>>>>> the MIP/MEP is located may be a different interface to the one wh= ere the >>>>>>>>> loopback is applied. >>>>>>>>>=20 >>>>>>>>> Having spoken with some of the original authors, it seems this wa= s not >>>> the >>>>>>>> intent >>>>>>>>> of this sentence; the intent was to point out that as different L= SPs >>>> would >>>>>>>> have >>>>>>>>> MIPs/MEPs on different interfaces, the corresponding loopback fun= ctions >>>>> would >>>>>>>>> also be applied on different interfaces. >>>>>>>>>=20 >>>>>>>>> Instructions: >>>>>>>>> ------------- >>>>>>>>> This errata is currently posted as "Reported". If necessary, plea= se >>>>>>>>> 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 >>>>>>>>> -------------------------------------- >>>>>>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>>>>>>>> -------------------------------------- >>>>>>>>> Title : MPLS Transport Profile Lock Instruct and Lo= opback >>>>>>>> Functions >>>>>>>>> Publication Date : November 2011 >>>>>>>>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Agga= rwal, >>>> Ed., M. >>>>>>>> Vigoureux, >>>>>>>>> Ed., X. Dai, Ed. >>>>>>>>> Category : PROPOSED STANDARD >>>>>>>>> Source : Multiprotocol Label Switching >>>>>>>>> Area : Routing >>>>>>>>> Stream : IETF >>>>>>>>> Verifying Party : IESG >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> -- >>>>> David Ball >>>>> >>>>=20 >>>>=20 >>>>=20 >>=20 From martin.vigoureux@alcatel-lucent.com Thu Jan 17 09:37:46 2013 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 351AE21F85AE for ; Thu, 17 Jan 2013 09:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 yx7JepF4T1HM for ; Thu, 17 Jan 2013 09:37:42 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8A49921F85A0 for ; Thu, 17 Jan 2013 09:37:41 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0HHaWk2027199 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Jan 2013 18:37:34 +0100 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 17 Jan 2013 18:37:32 +0100 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.51]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 17 Jan 2013 18:37:32 +0100 From: "VIGOUREUX, MARTIN (MARTIN)" To: "Sami Boutros (sboutros)" Thread-Topic: [Editorial Errata Reported] RFC6435 (3429) Thread-Index: AQHN2JGbr8z20Ev6BkqoT9E++A0mPJgV3TmAgCu+nACAAD2fgP//xZV2gAHMLICACaMWAIABCa+AgABGTwCAAAJagIAABBmA//+cyOQ= Date: Thu, 17 Jan 2013 17:37:31 +0000 Message-ID: References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> <50F7F553.1070509@alcatel-lucent.com> <20130117170933.GN25804@cisco.com> <50F83247.7050000@alcatel-lucent.com>, <473DA00BC97EE04A9B4EE875F48CE5F113355820@xmb-rcd-x08.cisco.com> In-Reply-To: <473DA00BC97EE04A9B4EE875F48CE5F113355820@xmb-rcd-x08.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FEA27CFACBAF3A429E381E6FD69CDC73BF9CFR712WXCHMBA09zeual_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "Siva Sivabalan \(msiva\)" , "raggarwa_1@yahoo.com" , "rcallon@juniper.net" , "David Ball -X \(daviball - Ensoft Ltd at Cisco\)" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 17 Jan 2013 17:37:46 -0000 --_000_FEA27CFACBAF3A429E381E6FD69CDC73BF9CFR712WXCHMBA09zeual_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sami, That is what I have agreed to just below.. -m ________________________________ De : Sami Boutros (sboutros) Envoy=E9 : 17/01/2013 18:32 =C0 : VIGOUREUX, MARTIN (MARTIN) Cc : David Ball -X (daviball - Ensoft Ltd at Cisco); adrian@olddog.co.uk; S= iva Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart= Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.ne= t; mpls@ietf.org Objet : Re: [Editorial Errata Reported] RFC6435 (3429) Martin, I think the other paragraphs edits shouldn't be included in the ERRATA, the= idea of sending test traffic not from a MEP we have not discussed before. Thanks, Sami On Jan 17, 2013, at 9:17 AM, Martin Vigoureux wrote: > David, > > agreed, and in fact this is consistent with the fact I kept MEP in the la= st paragraph I changed. > > -m > > > Le 17/01/2013 18:09, David Ball a =E9crit : >> Thanks Martin. >> >> Regarding the first paragraph, I agree with your change to add "for that >> transport path", that does make it clearer. >> >> Regarding the other paragraphs: We have agreed that the intent was that >> the point doing the loopback does not have to be a MEP or MIP, but your >> proposal also seems to change it so that the point transmitting the >> test data does not have to be a MEP. I think the original text was >> consistent that the test was done *from* a MEP; the question was whether >> it was done from a MEP *to another MEP/MIP*, or from a MEP *to an >> arbitrary point*. >> >> So you might be right that the text describing the source of the test >> should also be changed, but I think that is a slightly separate issue. >> It is probably safest to keep the changes to a minimum and just fix the >> description of the point that is doing the loopback, ie the target of >> the test. >> >> Do you agree? >> >> >> David >> >> >> On Thu, Jan 17, 2013, Martin Vigoureux wrote: >>> Adrian, yes, we are. >>> >>> So, David, >>> >>> I am fine with your suggested text which says: >>> It should be noted that the data-plane loopback function for a >>> given transport path can be applied to data-plane loopback points >>> residing on interfaces where there may be no corresponding MEP or >>> MIP. >>> >>> I was thinking of: >>> s/may be no corresponding MEP or MIP./may be no MEP or MIP for that >>> transport path./ >>> but this is optional. >>> >>> The new text will replace: >>> It should be noted that the data-plane loopback function itself is >>> applied to data-plane loopback points residing on different >>> interfaces from MIPs/MEPs. >>> >>> >>> Regarding the other paragraphs: >>> The loopback function is used to test the integrity of a transport >>> path from a MEP up any other node in the same MEG. This is achieved >>> by setting the target node into loopback mode, and transmitting a >>> pattern of test data from the MEP. The target node loops all >>> received data back toward the originator, and the MEP extracts the >>> test data and compares it with what it sent. >>> >>> Loopback is a function that enables a receiving MEP or MIP to return >>> traffic to the sending MEP when in the loopback state. >>> >>> [...] >>> >>> The management plane must ensure that the two MEPs are locked before >>> it requests setting MEP or MIP in the loopback state. >>> >>> >>> They could be changed into: >>> The loopback function is used to test the integrity of a transport >>> path. This is achieved by setting a given node into loopback mode >>> for a given transport path, and sending over it a pattern of test >>> data. The node in loopback mode loops all test data received on the >>> transport path back towards the sender, which extracts the test >>> data and compares it with what it sent. >>> >>> Loopback is a function which enables a given node of a transport >>> path, when in the loopback mode, to return traffic to the sender of >>> that traffic. >>> >>> [...] >>> >>> The management plane must ensure that the MEPs of a transport path >>> are locked before it requests setting a given node of that transport >>> path in loopback mode. >>> >>> Let me know. >>> -m >>> >>> Le 16/01/2013 22:07, Adrian Farrel a ?crit : >>>> All, are we getting any closer to agreeing what we all intended to say= ? >>>> >>>> Once we have that, I can work out what to do with the Errata Report. >>>> >>>> Thanks, >>>> Adrian >>>> >>>>> -----Original Message----- >>>>> From: David Ball [mailto:daviball@cisco.com] >>>>> Sent: 10 January 2013 17:57 >>>>> To: VIGOUREUX, MARTIN (MARTIN) >>>>> Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan (msi= va); >>>>> raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant= ); >>>>> loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.o= rg >>>>> Subject: Re: [Editorial Errata Reported] RFC6435 (3429) >>>>> >>>>> Hi Martin, >>>>> >>>>> Ah, right I see: since the loopback is locally configured, there is n= o >>>>> need for a MEP/MIP to send/receive OAM frames - but there may be a >>>>> MEP/MIP. >>>>> >>>>> So would this work to clarify the text? >>>>> "It should be noted that the data-plane loopback function for a >>>>> given transport path can be applied to data-plane loopback points >>>>> residing on interfaces where there may be no corresponding MEP or >>>>> MIP." >>>>> >>>>> For completeness, the references to "MEP or MIP" in paragraphs 3 and = 7 >>>>> of section 4 would also need to be changed, to instead refer to the >>>>> transport path that is being put in to loopback. >>>>> >>>>> As another data point, I found this text in RFC6371 section 6.3.2: >>>>> "It should be noted that data-plane loopback function itself is >>>>> applied to data-plane loopback points that can reside on different >>>>> interfaces from MIPs/MEPs." >>>>> Note the critical difference compared to RFC6435: "that can reside" >>>>> instead of "residing". >>>>> >>>>> Thanks >>>>> >>>>> >>>>> David >>>>> >>>>> >>>>> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: >>>>>> Sami, >>>>>> >>>>>> Thanks. Yet, I am not sure David's interpretation and mine exactly m= atch. >>>>>> David, correct me if I am wrong. For me it says that we can do >>>>>> loopback on different interfaces (for different LSPs) but implies th= at >>>>>> there is a mip/mep for that lsp on that interface, while my >>>>>> interpretation is that the presence of a mip/mep for that lsp on tha= t >>>>>> interface is not needed. >>>>>> >>>>>> -m >>>>>> ________________________________ >>>>>> De : Sami Boutros (sboutros) >>>>>> Envoy? : 09/01/2013 19:00 >>>>>> ? : VIGOUREUX, MARTIN (MARTIN) >>>>>> Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Ci= sco); >>>> Siva >>>>> Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewa= rt >>>>> Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@junip= er.net; >>>>> mpls@ietf.org >>>>>> Objet : Re: [Editorial Errata Reported] RFC6435 (3429) >>>>>> >>>>>> I agree with Martin, the text proposed by David describe more accura= tely >>>> what >>>>> we meant. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Sami >>>>>> On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: >>>>>> >>>>>>> Adrian, David, >>>>>>> >>>>>>> what I think we meant here was that a loop-back function could be d= one on >>>>> an interface regardless of the presence of a MIP/MEP on that interfac= e. Yet, I >>>>> have to admit that MIP and MEP are used in Section 4 of RFC6435, thus= surely >>>>> causing confusion. >>>>>>> >>>>>>> I'd welcome the views/souvenirs of my co-authors. >>>>>>> >>>>>>> -m >>>>>>> >>>>>>> Le 12/12/2012 19:17, Adrian Farrel a ?crit : >>>>>>>> Hello, >>>>>>>> >>>>>>>> Authors of RFC 6435: I need to hear from you that you meant the te= xt that >>>>> David >>>>>>>> suggests. It is very clearly not what you wrote and, if you meant >>>> something >>>>>>>> different, it is clear why people are confused! >>>>>>>> >>>>>>>> Working group: I need to hear from you that you agree with David's >>>>>>>> interpretation and support his proposed change. >>>>>>>> >>>>>>>> Only then will I try to work out whether this is a "typo" worthy o= f an >>>> errata >>>>>>>> report, or a technical change needing a revised RFC. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Adrian >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>>>>> Sent: 12 December 2012 17:45 >>>>>>>>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>>>>>>>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>>>>>>>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; >>>>> swallow@cisco.com; >>>>>>>>> rcallon@juniper.net >>>>>>>>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>>>>>>>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>>>>>>>> >>>>>>>>> >>>>>>>>> The following errata report has been submitted for RFC6435, >>>>>>>>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>>>>>>>> >>>>>>>>> -------------------------------------- >>>>>>>>> You may review the report below and at: >>>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435&eid=3D3429 >>>>>>>>> >>>>>>>>> -------------------------------------- >>>>>>>>> Type: Editorial >>>>>>>>> Reported by: David Ball >>>>>>>>> >>>>>>>>> Section: 4 (para 5) >>>>>>>>> >>>>>>>>> Original Text >>>>>>>>> ------------- >>>>>>>>> It should be noted that the data-plane loopback function itself i= s >>>> applied to >>>>>>>> data- >>>>>>>>> plane loopback points residing on different interfaces from MIPs/= MEPs. >>>>>>>>> >>>>>>>>> Corrected Text >>>>>>>>> -------------- >>>>>>>>> It should be noted that the data-plane loopback function may be a= pplied >>>> at >>>>>>>>> MIPs/MEPs on different interfaces for different LSPs. >>>>>>>>> >>>>>>>>> Notes >>>>>>>>> ----- >>>>>>>>> The existing text has caused confusion (specifically, among exper= ts in >>>> ITU-T >>>>>>>> SG15 >>>>>>>>> when discussing G.8121.2), in that it seems to suggest that the >>>> interface >>>>>>>> where >>>>>>>>> the MIP/MEP is located may be a different interface to the one wh= ere the >>>>>>>>> loopback is applied. >>>>>>>>> >>>>>>>>> Having spoken with some of the original authors, it seems this wa= s not >>>> the >>>>>>>> intent >>>>>>>>> of this sentence; the intent was to point out that as different L= SPs >>>> would >>>>>>>> have >>>>>>>>> MIPs/MEPs on different interfaces, the corresponding loopback fun= ctions >>>>> would >>>>>>>>> also be applied on different interfaces. >>>>>>>>> >>>>>>>>> Instructions: >>>>>>>>> ------------- >>>>>>>>> This errata is currently posted as "Reported". If necessary, plea= se >>>>>>>>> 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= . >>>>>>>>> >>>>>>>>> -------------------------------------- >>>>>>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>>>>>>>> -------------------------------------- >>>>>>>>> Title : MPLS Transport Profile Lock Instruct and Lo= opback >>>>>>>> Functions >>>>>>>>> Publication Date : November 2011 >>>>>>>>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Agga= rwal, >>>> Ed., M. >>>>>>>> Vigoureux, >>>>>>>>> Ed., X. Dai, Ed. >>>>>>>>> Category : PROPOSED STANDARD >>>>>>>>> Source : Multiprotocol Label Switching >>>>>>>>> Area : Routing >>>>>>>>> Stream : IETF >>>>>>>>> Verifying Party : IESG >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> -- >>>>> David Ball >>>>> >>>> >>>> >>>> >> --_000_FEA27CFACBAF3A429E381E6FD69CDC73BF9CFR712WXCHMBA09zeual_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sami,

That is what I have agreed to just below..

-m
De : Sami B= outros (sboutros)
Envoy=E9 : 17/01/= 2013 18:32
=C0 : VIGOUR= EUX, MARTIN (MARTIN)
Cc : David = Ball -X (daviball - Ensoft Ltd at Cisco); adrian@olddog.co.uk; Siva Sivabal= an (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (st= bryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org
Objet : Re: [E= ditorial Errata Reported] RFC6435 (3429)

Martin,

I think the other paragraphs edits shouldn't be included in the ERRATA, the= idea of sending test traffic not from a MEP we have not discussed before.<= br>
Thanks,

Sami
On Jan 17, 2013, at 9:17 AM, Martin Vigoureux wrote:

> David,
>
> agreed, and in fact this is consistent with the fact I kept MEP in the= last paragraph I changed.
>
> -m
>
>
> Le 17/01/2013 18:09, David Ball a =E9crit :
>> Thanks Martin.
>>
>> Regarding the first paragraph, I agree with your change to add &qu= ot;for that
>> transport path", that does make it clearer.
>>
>> Regarding the other paragraphs: We have agreed that the intent was= that
>> the point doing the loopback does not have to be a MEP or MIP, but= your
>> proposal also seems to change it so that the point transmitting th= e
>> test data does not have to be a MEP.  I think the original te= xt was
>> consistent that the test was done *from* a MEP; the question was w= hether
>> it was done from a MEP *to another MEP/MIP*, or from a MEP *to an<= br> >> arbitrary point*.
>>
>> So you might be right that the text describing the source of the t= est
>> should also be changed, but I think that is a slightly separate is= sue.
>> It is probably safest to keep the changes to a minimum and just fi= x the
>> description of the point that is doing the loopback, ie the target= of
>> the test.
>>
>> Do you agree?
>>
>>
>>       David
>>
>>
>> On Thu, Jan 17, 2013, Martin Vigoureux wrote:
>>> Adrian, yes, we are.
>>>
>>> So, David,
>>>
>>> I am fine with your suggested text which says:
>>>    It should be noted that the data-plane loopb= ack function for a
>>>    given transport path can be applied to data-= plane loopback points
>>>    residing on interfaces where there may be no= corresponding MEP or
>>>    MIP.
>>>
>>> I was thinking of:
>>> s/may be no corresponding MEP or MIP./may be no MEP or MIP for= that
>>> transport path./
>>> but this is optional.
>>>
>>> The new text will replace:
>>>    It should be noted that the data-plane loopb= ack function itself is
>>>    applied to data-plane loopback points residi= ng on different
>>>    interfaces from MIPs/MEPs.
>>>
>>>
>>> Regarding the other paragraphs:
>>>    The loopback function is used to test the in= tegrity of a transport
>>>    path from a MEP up any other node in the sam= e MEG.  This is achieved
>>>    by setting the target node into loopback mod= e, and transmitting a
>>>    pattern of test data from the MEP.  The= target node loops all
>>>    received data back toward the originator, an= d the MEP extracts the
>>>    test data and compares it with what it sent.=
>>>
>>>    Loopback is a function that enables a receiv= ing MEP or MIP to return
>>>    traffic to the sending MEP when in the loopb= ack state.
>>>
>>>    [...]
>>>
>>>    The management plane must ensure that the tw= o MEPs are locked before
>>>    it requests setting MEP or MIP in the loopba= ck state.
>>>
>>>
>>> They could be changed into:
>>>    The loopback function is used to test the in= tegrity of a transport
>>>    path.  This is achieved by setting a gi= ven node into loopback mode
>>>    for a given transport path, and sending over= it a pattern of test
>>>    data.  The node in loopback mode loops = all test data received on the
>>>    transport path back towards the sender, whic= h extracts the test
>>>    data and compares it with what it sent.
>>>
>>>    Loopback is a function which enables a given= node of a transport
>>>    path, when in the loopback mode, to return t= raffic to the sender of
>>>    that traffic.
>>>
>>>    [...]
>>>
>>>    The management plane must ensure that the ME= Ps of a transport path
>>>    are locked before it requests setting a give= n node of that transport
>>>    path in loopback mode.
>>>
>>> Let me know.
>>> -m
>>>
>>> Le 16/01/2013 22:07, Adrian Farrel a ?crit :
>>>> All, are we getting any closer to agreeing what we all int= ended to say?
>>>>
>>>> Once we have that, I can work out what to do with the Erra= ta Report.
>>>>
>>>> Thanks,
>>>> Adrian
>>>>
>>>>> -----Original Message-----
>>>>> From: David Ball [mailto:daviball@cisco.com]
>>>>> Sent: 10 January 2013 17:57
>>>>> To: VIGOUREUX, MARTIN (MARTIN)
>>>>> Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva= Sivabalan (msiva);
>>>>> raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart B= ryant (stbryant);
>>>>> loa@pi.nu; George Swallow (swallow); rcallon@juniper.n= et; mpls@ietf.org
>>>>> Subject: Re: [Editorial Errata Reported] RFC6435 (3429= )
>>>>>
>>>>> Hi Martin,
>>>>>
>>>>> Ah, right I see: since the loopback is locally configu= red, there is no
>>>>> need for a MEP/MIP to send/receive OAM frames - but th= ere may be a
>>>>> MEP/MIP.
>>>>>
>>>>> So would this work to clarify the text?
>>>>>   "It should be noted that the data-pla= ne loopback function for a
>>>>>    given transport path can be applied = to data-plane loopback points
>>>>>    residing on interfaces where there m= ay be no corresponding MEP or
>>>>>    MIP."
>>>>>
>>>>> For completeness, the references to "MEP or MIP&q= uot; in paragraphs 3 and 7
>>>>> of section 4 would also need to be changed, to instead= refer to the
>>>>> transport path that is being put in to loopback.
>>>>>
>>>>> As another data point, I found this text in RFC6371 se= ction 6.3.2:
>>>>>   "It should be noted that data-plane l= oopback function itself is
>>>>>    applied to data-plane loopback point= s that can reside on different
>>>>>    interfaces from MIPs/MEPs."
>>>>> Note the critical difference compared to RFC6435: &quo= t;that can reside"
>>>>> instead of "residing".
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>    David
>>>>>
>>>>>
>>>>> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote= :
>>>>>> Sami,
>>>>>>
>>>>>> Thanks. Yet, I am not sure David's interpretation = and mine exactly match.
>>>>>> David, correct me if I am wrong. For me it says th= at we can do
>>>>>> loopback on different interfaces (for different LS= Ps) but implies that
>>>>>> there is a mip/mep for that lsp on that interface,= while my
>>>>>> interpretation is that the presence of a mip/mep f= or that lsp on that
>>>>>> interface is not needed.
>>>>>>
>>>>>> -m
>>>>>> ________________________________
>>>>>> De : Sami Boutros (sboutros)
>>>>>> Envoy? : 09/01/2013 19:00
>>>>>> ? : VIGOUREUX, MARTIN (MARTIN)
>>>>>> Cc : adrian@olddog.co.uk; David Ball -X (daviball = - Ensoft Ltd at Cisco);
>>>> Siva
>>>>> Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zt= e.com.cn; Stewart
>>>>> Bryant (stbryant); loa@pi.nu; George Swallow (swallow)= ; rcallon@juniper.net;
>>>>> mpls@ietf.org
>>>>>> Objet : Re: [Editorial Errata Reported] RFC6435 (3= 429)
>>>>>>
>>>>>> I agree with Martin, the text proposed by David de= scribe more accurately
>>>> what
>>>>> we meant.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Sami
>>>>>> On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote= :
>>>>>>
>>>>>>> Adrian, David,
>>>>>>>
>>>>>>> what I think we meant here was that a loop-bac= k function could be done on
>>>>> an interface regardless of the presence of a MIP/MEP o= n that interface. Yet, I
>>>>> have to admit that MIP and MEP are used in Section 4 o= f RFC6435, thus surely
>>>>> causing confusion.
>>>>>>>
>>>>>>> I'd welcome the views/souvenirs of my co-autho= rs.
>>>>>>>
>>>>>>> -m
>>>>>>>
>>>>>>> Le 12/12/2012 19:17, Adrian Farrel a ?crit : >>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Authors of RFC 6435: I need to hear from y= ou that you meant the text that
>>>>> David
>>>>>>>> suggests. It is very clearly not what you = wrote and, if you meant
>>>> something
>>>>>>>> different, it is clear why people are conf= used!
>>>>>>>>
>>>>>>>> Working group: I need to hear from you tha= t you agree with David's
>>>>>>>> interpretation and support his proposed ch= ange.
>>>>>>>>
>>>>>>>> Only then will I try to work out whether t= his is a "typo" worthy of an
>>>> errata
>>>>>>>> report, or a technical change needing a re= vised RFC.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Adrian
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
>>>>>>>>> Sent: 12 December 2012 17:45
>>>>>>>>> To: sboutros@cisco.com; msiva@cisco.co= m; raggarwa_1@yahoo.com;
>>>>>>>>> martin.vigoureux@alcatel-lucent.com; d= ai.xuehui@zte.com.cn;
>>>>>>>>> stbryant@cisco.com; adrian@olddog.co.u= k; loa@pi.nu;
>>>>> swallow@cisco.com;
>>>>>>>>> rcallon@juniper.net
>>>>>>>>> Cc: daviball@cisco.com; mpls@ietf.org;= rfc-editor@rfc-editor.org
>>>>>>>>> Subject: [Editorial Errata Reported] R= FC6435 (3429)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The following errata report has been s= ubmitted for RFC6435,
>>>>>>>>> "MPLS Transport Profile Lock Inst= ruct and Loopback Functions".
>>>>>>>>>
>>>>>>>>> --------------------------------------=
>>>>>>>>> You may review the report below and at= :
>>>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435&eid=3D3429 >>>>>>>>>
>>>>>>>>> --------------------------------------=
>>>>>>>>> Type: Editorial
>>>>>>>>> Reported by: David Ball<daviball@ci= sco.com>
>>>>>>>>>
>>>>>>>>> Section: 4 (para 5)
>>>>>>>>>
>>>>>>>>> Original Text
>>>>>>>>> -------------
>>>>>>>>> It should be noted that the data-plane= loopback function itself is
>>>> applied to
>>>>>>>> data-
>>>>>>>>> plane loopback points residing on diff= erent interfaces from MIPs/MEPs.
>>>>>>>>>
>>>>>>>>> Corrected Text
>>>>>>>>> --------------
>>>>>>>>> It should be noted that the data-plane= loopback function may be applied
>>>> at
>>>>>>>>> MIPs/MEPs on different interfaces for = different LSPs.
>>>>>>>>>
>>>>>>>>> Notes
>>>>>>>>> -----
>>>>>>>>> The existing text has caused confusion= (specifically, among experts in
>>>> ITU-T
>>>>>>>> SG15
>>>>>>>>> when discussing G.8121.2), in that it = seems to suggest that the
>>>> interface
>>>>>>>> where
>>>>>>>>> the MIP/MEP is located may be a differ= ent interface to the one where the
>>>>>>>>> loopback is applied.
>>>>>>>>>
>>>>>>>>> Having spoken with some of the origina= l authors, it seems this was not
>>>> the
>>>>>>>> intent
>>>>>>>>> of this sentence; the intent was to po= int out that as different LSPs
>>>> would
>>>>>>>> have
>>>>>>>>> MIPs/MEPs on different interfaces, the= corresponding loopback functions
>>>>> would
>>>>>>>>> also be applied on different interface= s.
>>>>>>>>>
>>>>>>>>> Instructions:
>>>>>>>>> -------------
>>>>>>>>> This errata is currently posted as &qu= ot;Reported". If necessary, please
>>>>>>>>> use "Reply All" to discuss w= hether it should be verified or
>>>>>>>>> rejected. When a decision is reached, = the verifying party (IESG)
>>>>>>>>> can log in to change the status and ed= it the report, if necessary.
>>>>>>>>>
>>>>>>>>> --------------------------------------=
>>>>>>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08)<= br> >>>>>>>>> --------------------------------------=
>>>>>>>>> Title     &nb= sp;         : MPLS Transport Profil= e Lock Instruct and Loopback
>>>>>>>> Functions
>>>>>>>>> Publication Date    : N= ovember 2011
>>>>>>>>> Author(s)     = ;      : S. Boutros, Ed., S. Sivabalan, Ed., R. Ag= garwal,
>>>> Ed., M.
>>>>>>>> Vigoureux,
>>>>>>>>> Ed., X. Dai, Ed.
>>>>>>>>> Category     =        : PROPOSED STANDARD
>>>>>>>>> Source     &n= bsp;        : Multiprotocol Label Switch= ing
>>>>>>>>> Area     &nbs= p;          : Routing
>>>>>>>>> Stream     &n= bsp;        : IETF
>>>>>>>>> Verifying Party    = ; : IESG
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> David Ball
>>>>> <daviball@cisco.com>
>>>>
>>>>
>>>>
>>

--_000_FEA27CFACBAF3A429E381E6FD69CDC73BF9CFR712WXCHMBA09zeual_-- From daviball@cisco.com Thu Jan 17 09:41:15 2013 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 2D33721F86D4 for ; Thu, 17 Jan 2013 09:41:15 -0800 (PST) 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 W9+Xofb1jbZo for ; Thu, 17 Jan 2013 09:41:10 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E1D9B21F886C for ; Thu, 17 Jan 2013 09:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13963; q=dns/txt; s=iport; t=1358444470; x=1359654070; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=7WQgf/2tCWf/QGmPEu3hyh1Qh1JzLJCpnLOonp0U3q8=; b=FJz9p5FM3zmNSxI20TDYf8JYCTqsVQyJToIN5cTXqrtXyR6gQxxUxpAP xd747vR0WN4Vt3ySfdmGcv3V5grReyDyWgTIc42fXIg85zz5hbsaHaO5/ DPxE+a9zXI13YJB67unD3KJAHEXWIF5WT3QWIkI1MTvK9brvSfO0U1+zv A=; X-IronPort-AV: E=Sophos;i="4.84,486,1355097600"; d="scan'208";a="11154179" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 17 Jan 2013 17:41:09 +0000 Received: from ensoft-linux3.cisco.com (ensoft-linux3.cisco.com [10.63.23.12]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0HHf8Yw019552 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 17:41:08 GMT Received: from daviball by ensoft-linux3.cisco.com with local (Exim 4.76) (envelope-from ) id 1TvtSZ-0006oi-8e; Thu, 17 Jan 2013 17:41:03 +0000 Date: Thu, 17 Jan 2013 17:41:02 +0000 From: David Ball To: Martin Vigoureux Message-ID: <20130117174102.GP25804@cisco.com> References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> <50F7F553.1070509@alcatel-lucent.com> <20130117170933.GN25804@cisco.com> <50F83247.7050000@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F83247.7050000@alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "'Sami Boutros \(sboutros\)'" , "'Siva Sivabalan \(msiva\)'" , "raggarwa_1@yahoo.com" , "rcallon@juniper.net" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 17 Jan 2013 17:41:15 -0000 Hi Martin, Actually I think the last paragraph is talking about something different again: this is the MEPs that must be locked. Here is a transport path: |>-------x----------x-------<| --------->| <---------v A B C D A and D are the MEPs; B is the source of the test, C is the loopback point. As we have discussed, C could be a MIP, could be the MEP at D, or could be at a point that is neither a MIP or a MEP. A and D are the MEPs that must be locked during the test. My question was about point B: I think in the original text point B must always be the same as the MEP at point A; your proposal allows it to be some other point, eg at a MIP or at a point where there is no MIP or MEP. If we keep the original text about point B, and just change the text about point C, then combining with your proposal we get the following change: Old text: The loopback function is used to test the integrity of a transport path from a MEP up any other node in the same MEG. This is achieved by setting the target node into loopback mode, and transmitting a pattern of test data from the MEP. The target node loops all received data back toward the originator, and the MEP extracts the test data and compares it with what it sent. Loopback is a function that enables a receiving MEP or MIP to return traffic to the sending MEP when in the loopback state. [...] The management plane must ensure that the two MEPs are locked before it requests setting MEP or MIP in the loopback state. New text: The loopback function is used to test the integrity of a transport path from a MEP to any other node along the same transport path. This is achieved by setting the target node into loopback mode for that transport path, and transmitting a pattern of test data from the MEP. The target node loops all data received on the transport path back towards the sending MEP, which extracts the test data and compares it with what it sent. Loopback is a function that enables a given node of a transport path to return traffic to the sending MEP for that transport path when in the loopback mode. [...] The management plane must ensure that the MEPs at either end of a transport path are locked before it requests setting a given node of that transport path into loopback mode. Does this work? David On Thu, Jan 17, 2013, Martin Vigoureux wrote: > David, > > agreed, and in fact this is consistent with the fact I kept MEP in > the last paragraph I changed. > > -m > > > Le 17/01/2013 18:09, David Ball a ?crit : > >Thanks Martin. > > > >Regarding the first paragraph, I agree with your change to add "for that > >transport path", that does make it clearer. > > > >Regarding the other paragraphs: We have agreed that the intent was that > >the point doing the loopback does not have to be a MEP or MIP, but your > >proposal also seems to change it so that the point transmitting the > >test data does not have to be a MEP. I think the original text was > >consistent that the test was done *from* a MEP; the question was whether > >it was done from a MEP *to another MEP/MIP*, or from a MEP *to an > >arbitrary point*. > > > >So you might be right that the text describing the source of the test > >should also be changed, but I think that is a slightly separate issue. > >It is probably safest to keep the changes to a minimum and just fix the > >description of the point that is doing the loopback, ie the target of > >the test. > > > >Do you agree? > > > > > > David > > > > > >On Thu, Jan 17, 2013, Martin Vigoureux wrote: > >>Adrian, yes, we are. > >> > >>So, David, > >> > >>I am fine with your suggested text which says: > >> It should be noted that the data-plane loopback function for a > >> given transport path can be applied to data-plane loopback points > >> residing on interfaces where there may be no corresponding MEP or > >> MIP. > >> > >>I was thinking of: > >>s/may be no corresponding MEP or MIP./may be no MEP or MIP for that > >>transport path./ > >>but this is optional. > >> > >>The new text will replace: > >> It should be noted that the data-plane loopback function itself is > >> applied to data-plane loopback points residing on different > >> interfaces from MIPs/MEPs. > >> > >> > >>Regarding the other paragraphs: > >> The loopback function is used to test the integrity of a transport > >> path from a MEP up any other node in the same MEG. This is achieved > >> by setting the target node into loopback mode, and transmitting a > >> pattern of test data from the MEP. The target node loops all > >> received data back toward the originator, and the MEP extracts the > >> test data and compares it with what it sent. > >> > >> Loopback is a function that enables a receiving MEP or MIP to return > >> traffic to the sending MEP when in the loopback state. > >> > >> [...] > >> > >> The management plane must ensure that the two MEPs are locked before > >> it requests setting MEP or MIP in the loopback state. > >> > >> > >>They could be changed into: > >> The loopback function is used to test the integrity of a transport > >> path. This is achieved by setting a given node into loopback mode > >> for a given transport path, and sending over it a pattern of test > >> data. The node in loopback mode loops all test data received on the > >> transport path back towards the sender, which extracts the test > >> data and compares it with what it sent. > >> > >> Loopback is a function which enables a given node of a transport > >> path, when in the loopback mode, to return traffic to the sender of > >> that traffic. > >> > >> [...] > >> > >> The management plane must ensure that the MEPs of a transport path > >> are locked before it requests setting a given node of that transport > >> path in loopback mode. > >> > >>Let me know. > >>-m > >> > >>Le 16/01/2013 22:07, Adrian Farrel a ?crit : > >>>All, are we getting any closer to agreeing what we all intended to say? > >>> > >>>Once we have that, I can work out what to do with the Errata Report. > >>> > >>>Thanks, > >>>Adrian > >>> > >>>>-----Original Message----- > >>>>From: David Ball [mailto:daviball@cisco.com] > >>>>Sent: 10 January 2013 17:57 > >>>>To: VIGOUREUX, MARTIN (MARTIN) > >>>>Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan (msiva); > >>>>raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant); > >>>>loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org > >>>>Subject: Re: [Editorial Errata Reported] RFC6435 (3429) > >>>> > >>>>Hi Martin, > >>>> > >>>>Ah, right I see: since the loopback is locally configured, there is no > >>>>need for a MEP/MIP to send/receive OAM frames - but there may be a > >>>>MEP/MIP. > >>>> > >>>>So would this work to clarify the text? > >>>> "It should be noted that the data-plane loopback function for a > >>>> given transport path can be applied to data-plane loopback points > >>>> residing on interfaces where there may be no corresponding MEP or > >>>> MIP." > >>>> > >>>>For completeness, the references to "MEP or MIP" in paragraphs 3 and 7 > >>>>of section 4 would also need to be changed, to instead refer to the > >>>>transport path that is being put in to loopback. > >>>> > >>>>As another data point, I found this text in RFC6371 section 6.3.2: > >>>> "It should be noted that data-plane loopback function itself is > >>>> applied to data-plane loopback points that can reside on different > >>>> interfaces from MIPs/MEPs." > >>>>Note the critical difference compared to RFC6435: "that can reside" > >>>>instead of "residing". > >>>> > >>>>Thanks > >>>> > >>>> > >>>> David > >>>> > >>>> > >>>>On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: > >>>>>Sami, > >>>>> > >>>>>Thanks. Yet, I am not sure David's interpretation and mine exactly match. > >>>>>David, correct me if I am wrong. For me it says that we can do > >>>>>loopback on different interfaces (for different LSPs) but implies that > >>>>>there is a mip/mep for that lsp on that interface, while my > >>>>>interpretation is that the presence of a mip/mep for that lsp on that > >>>>>interface is not needed. > >>>>> > >>>>>-m > >>>>>________________________________ > >>>>>De : Sami Boutros (sboutros) > >>>>>Envoy? : 09/01/2013 19:00 > >>>>>? : VIGOUREUX, MARTIN (MARTIN) > >>>>>Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco); > >>>Siva > >>>>Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart > >>>>Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; > >>>>mpls@ietf.org > >>>>>Objet : Re: [Editorial Errata Reported] RFC6435 (3429) > >>>>> > >>>>>I agree with Martin, the text proposed by David describe more accurately > >>>what > >>>>we meant. > >>>>> > >>>>>Thanks, > >>>>> > >>>>>Sami > >>>>>On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > >>>>> > >>>>>>Adrian, David, > >>>>>> > >>>>>>what I think we meant here was that a loop-back function could be done on > >>>>an interface regardless of the presence of a MIP/MEP on that interface. Yet, I > >>>>have to admit that MIP and MEP are used in Section 4 of RFC6435, thus surely > >>>>causing confusion. > >>>>>> > >>>>>>I'd welcome the views/souvenirs of my co-authors. > >>>>>> > >>>>>>-m > >>>>>> > >>>>>>Le 12/12/2012 19:17, Adrian Farrel a ?crit : > >>>>>>>Hello, > >>>>>>> > >>>>>>>Authors of RFC 6435: I need to hear from you that you meant the text that > >>>>David > >>>>>>>suggests. It is very clearly not what you wrote and, if you meant > >>>something > >>>>>>>different, it is clear why people are confused! > >>>>>>> > >>>>>>>Working group: I need to hear from you that you agree with David's > >>>>>>>interpretation and support his proposed change. > >>>>>>> > >>>>>>>Only then will I try to work out whether this is a "typo" worthy of an > >>>errata > >>>>>>>report, or a technical change needing a revised RFC. > >>>>>>> > >>>>>>>Thanks, > >>>>>>>Adrian > >>>>>>> > >>>>>>>>-----Original Message----- > >>>>>>>>From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>>>>>>>Sent: 12 December 2012 17:45 > >>>>>>>>To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > >>>>>>>>martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > >>>>>>>>stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; > >>>>swallow@cisco.com; > >>>>>>>>rcallon@juniper.net > >>>>>>>>Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org > >>>>>>>>Subject: [Editorial Errata Reported] RFC6435 (3429) > >>>>>>>> > >>>>>>>> > >>>>>>>>The following errata report has been submitted for RFC6435, > >>>>>>>>"MPLS Transport Profile Lock Instruct and Loopback Functions". > >>>>>>>> > >>>>>>>>-------------------------------------- > >>>>>>>>You may review the report below and at: > >>>>>>>>http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 > >>>>>>>> > >>>>>>>>-------------------------------------- > >>>>>>>>Type: Editorial > >>>>>>>>Reported by: David Ball > >>>>>>>> > >>>>>>>>Section: 4 (para 5) > >>>>>>>> > >>>>>>>>Original Text > >>>>>>>>------------- > >>>>>>>>It should be noted that the data-plane loopback function itself is > >>>applied to > >>>>>>>data- > >>>>>>>>plane loopback points residing on different interfaces from MIPs/MEPs. > >>>>>>>> > >>>>>>>>Corrected Text > >>>>>>>>-------------- > >>>>>>>>It should be noted that the data-plane loopback function may be applied > >>>at > >>>>>>>>MIPs/MEPs on different interfaces for different LSPs. > >>>>>>>> > >>>>>>>>Notes > >>>>>>>>----- > >>>>>>>>The existing text has caused confusion (specifically, among experts in > >>>ITU-T > >>>>>>>SG15 > >>>>>>>>when discussing G.8121.2), in that it seems to suggest that the > >>>interface > >>>>>>>where > >>>>>>>>the MIP/MEP is located may be a different interface to the one where the > >>>>>>>>loopback is applied. > >>>>>>>> > >>>>>>>>Having spoken with some of the original authors, it seems this was not > >>>the > >>>>>>>intent > >>>>>>>>of this sentence; the intent was to point out that as different LSPs > >>>would > >>>>>>>have > >>>>>>>>MIPs/MEPs on different interfaces, the corresponding loopback functions > >>>>would > >>>>>>>>also be applied on different interfaces. > >>>>>>>> > >>>>>>>>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. > >>>>>>>> > >>>>>>>>-------------------------------------- > >>>>>>>>RFC6435 (draft-ietf-mpls-tp-li-lb-08) > >>>>>>>>-------------------------------------- > >>>>>>>>Title : MPLS Transport Profile Lock Instruct and Loopback > >>>>>>>Functions > >>>>>>>>Publication Date : November 2011 > >>>>>>>>Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, > >>>Ed., M. > >>>>>>>Vigoureux, > >>>>>>>>Ed., X. Dai, Ed. > >>>>>>>>Category : PROPOSED STANDARD > >>>>>>>>Source : Multiprotocol Label Switching > >>>>>>>>Area : Routing > >>>>>>>>Stream : IETF > >>>>>>>>Verifying Party : IESG > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>>>-- > >>>>David Ball > >>>> > >>> > >>> > >>> > > -- David Ball From martin.vigoureux@alcatel-lucent.com Thu Jan 17 12:00:11 2013 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 C63CB21F88F7 for ; Thu, 17 Jan 2013 12:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.248 X-Spam-Level: X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 xtZjOghqgwfC for ; Thu, 17 Jan 2013 12:00:05 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9101621F890D for ; Thu, 17 Jan 2013 12:00:03 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0HJxsvm002578 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Jan 2013 20:59:58 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 17 Jan 2013 20:59:54 +0100 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.51]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 17 Jan 2013 20:59:54 +0100 From: "VIGOUREUX, MARTIN (MARTIN)" To: David Ball Thread-Topic: [Editorial Errata Reported] RFC6435 (3429) Thread-Index: AQHN9NnRr8z20Ev6BkqoT9E++A0mPJhN8Lr1 Date: Thu, 17 Jan 2013 19:59:53 +0000 Message-ID: References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> <50F7F553.1070509@alcatel-lucent.com> <20130117170933.GN25804@cisco.com> <50F83247.7050000@alcatel-lucent.com>, <20130117174102.GP25804@cisco.com> In-Reply-To: <20130117174102.GP25804@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FEA27CFACBAF3A429E381E6FD69CDC73C492FR712WXCHMBA09zeual_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "mpls@ietf.org" , "dai.xuehui@zte.com.cn" , "'Sami Boutros \(sboutros\)'" , "'Siva Sivabalan \(msiva\)'" , "raggarwa_1@yahoo.com" , "rcallon@juniper.net" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 17 Jan 2013 20:00:11 -0000 --_000_FEA27CFACBAF3A429E381E6FD69CDC73C492FR712WXCHMBA09zeual_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, Yes it does. Thanks. I first thought of removing all references to MEP/MIP but should have given= it a second thought. -m ________________________________ De : David Ball Envoy=E9 : 17/01/2013 18:41 =C0 : VIGOUREUX, MARTIN (MARTIN) Cc : adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan (msiva= )'; raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart Bryant (stbryant)= '; loa@pi.nu; 'George Swallow (swallow)'; rcallon@juniper.net; mpls@ietf.or= g Objet : Re: [Editorial Errata Reported] RFC6435 (3429) Hi Martin, Actually I think the last paragraph is talking about something different again: this is the MEPs that must be locked. Here is a transport path: |>-------x----------x-------<| --------->| <---------v A B C D A and D are the MEPs; B is the source of the test, C is the loopback point. As we have discussed, C could be a MIP, could be the MEP at D, or could be at a point that is neither a MIP or a MEP. A and D are the MEPs that must be locked during the test. My question was about point B: I think in the original text point B must always be the same as the MEP at point A; your proposal allows it to be some other point, eg at a MIP or at a point where there is no MIP or MEP. If we keep the original text about point B, and just change the text about point C, then combining with your proposal we get the following change: Old text: The loopback function is used to test the integrity of a transport path from a MEP up any other node in the same MEG. This is achieved by setting the target node into loopback mode, and transmitting a pattern of test data from the MEP. The target node loops all received data back toward the originator, and the MEP extracts the test data and compares it with what it sent. Loopback is a function that enables a receiving MEP or MIP to return traffic to the sending MEP when in the loopback state. [...] The management plane must ensure that the two MEPs are locked before it requests setting MEP or MIP in the loopback state. New text: The loopback function is used to test the integrity of a transport path from a MEP to any other node along the same transport path. This is achieved by setting the target node into loopback mode for that transport path, and transmitting a pattern of test data from the MEP. The target node loops all data received on the transport path back towards the sending MEP, which extracts the test data and compares it with what it sent. Loopback is a function that enables a given node of a transport path to return traffic to the sending MEP for that transport path when in the loopback mode. [...] The management plane must ensure that the MEPs at either end of a transport path are locked before it requests setting a given node of that transport path into loopback mode. Does this work? David On Thu, Jan 17, 2013, Martin Vigoureux wrote: > David, > > agreed, and in fact this is consistent with the fact I kept MEP in > the last paragraph I changed. > > -m > > > Le 17/01/2013 18:09, David Ball a ?crit : > >Thanks Martin. > > > >Regarding the first paragraph, I agree with your change to add "for that > >transport path", that does make it clearer. > > > >Regarding the other paragraphs: We have agreed that the intent was that > >the point doing the loopback does not have to be a MEP or MIP, but your > >proposal also seems to change it so that the point transmitting the > >test data does not have to be a MEP. I think the original text was > >consistent that the test was done *from* a MEP; the question was whether > >it was done from a MEP *to another MEP/MIP*, or from a MEP *to an > >arbitrary point*. > > > >So you might be right that the text describing the source of the test > >should also be changed, but I think that is a slightly separate issue. > >It is probably safest to keep the changes to a minimum and just fix the > >description of the point that is doing the loopback, ie the target of > >the test. > > > >Do you agree? > > > > > > David > > > > > >On Thu, Jan 17, 2013, Martin Vigoureux wrote: > >>Adrian, yes, we are. > >> > >>So, David, > >> > >>I am fine with your suggested text which says: > >> It should be noted that the data-plane loopback function for a > >> given transport path can be applied to data-plane loopback points > >> residing on interfaces where there may be no corresponding MEP or > >> MIP. > >> > >>I was thinking of: > >>s/may be no corresponding MEP or MIP./may be no MEP or MIP for that > >>transport path./ > >>but this is optional. > >> > >>The new text will replace: > >> It should be noted that the data-plane loopback function itself is > >> applied to data-plane loopback points residing on different > >> interfaces from MIPs/MEPs. > >> > >> > >>Regarding the other paragraphs: > >> The loopback function is used to test the integrity of a transport > >> path from a MEP up any other node in the same MEG. This is achieve= d > >> by setting the target node into loopback mode, and transmitting a > >> pattern of test data from the MEP. The target node loops all > >> received data back toward the originator, and the MEP extracts the > >> test data and compares it with what it sent. > >> > >> Loopback is a function that enables a receiving MEP or MIP to retur= n > >> traffic to the sending MEP when in the loopback state. > >> > >> [...] > >> > >> The management plane must ensure that the two MEPs are locked befor= e > >> it requests setting MEP or MIP in the loopback state. > >> > >> > >>They could be changed into: > >> The loopback function is used to test the integrity of a transport > >> path. This is achieved by setting a given node into loopback mode > >> for a given transport path, and sending over it a pattern of test > >> data. The node in loopback mode loops all test data received on th= e > >> transport path back towards the sender, which extracts the test > >> data and compares it with what it sent. > >> > >> Loopback is a function which enables a given node of a transport > >> path, when in the loopback mode, to return traffic to the sender of > >> that traffic. > >> > >> [...] > >> > >> The management plane must ensure that the MEPs of a transport path > >> are locked before it requests setting a given node of that transpor= t > >> path in loopback mode. > >> > >>Let me know. > >>-m > >> > >>Le 16/01/2013 22:07, Adrian Farrel a ?crit : > >>>All, are we getting any closer to agreeing what we all intended to say= ? > >>> > >>>Once we have that, I can work out what to do with the Errata Report. > >>> > >>>Thanks, > >>>Adrian > >>> > >>>>-----Original Message----- > >>>>From: David Ball [mailto:daviball@cisco.com] > >>>>Sent: 10 January 2013 17:57 > >>>>To: VIGOUREUX, MARTIN (MARTIN) > >>>>Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan (msi= va); > >>>>raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant= ); > >>>>loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.o= rg > >>>>Subject: Re: [Editorial Errata Reported] RFC6435 (3429) > >>>> > >>>>Hi Martin, > >>>> > >>>>Ah, right I see: since the loopback is locally configured, there is n= o > >>>>need for a MEP/MIP to send/receive OAM frames - but there may be a > >>>>MEP/MIP. > >>>> > >>>>So would this work to clarify the text? > >>>> "It should be noted that the data-plane loopback function for a > >>>> given transport path can be applied to data-plane loopback points > >>>> residing on interfaces where there may be no corresponding MEP or > >>>> MIP." > >>>> > >>>>For completeness, the references to "MEP or MIP" in paragraphs 3 and = 7 > >>>>of section 4 would also need to be changed, to instead refer to the > >>>>transport path that is being put in to loopback. > >>>> > >>>>As another data point, I found this text in RFC6371 section 6.3.2: > >>>> "It should be noted that data-plane loopback function itself is > >>>> applied to data-plane loopback points that can reside on differen= t > >>>> interfaces from MIPs/MEPs." > >>>>Note the critical difference compared to RFC6435: "that can reside" > >>>>instead of "residing". > >>>> > >>>>Thanks > >>>> > >>>> > >>>> David > >>>> > >>>> > >>>>On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: > >>>>>Sami, > >>>>> > >>>>>Thanks. Yet, I am not sure David's interpretation and mine exactly m= atch. > >>>>>David, correct me if I am wrong. For me it says that we can do > >>>>>loopback on different interfaces (for different LSPs) but implies th= at > >>>>>there is a mip/mep for that lsp on that interface, while my > >>>>>interpretation is that the presence of a mip/mep for that lsp on tha= t > >>>>>interface is not needed. > >>>>> > >>>>>-m > >>>>>________________________________ > >>>>>De : Sami Boutros (sboutros) > >>>>>Envoy? : 09/01/2013 19:00 > >>>>>? : VIGOUREUX, MARTIN (MARTIN) > >>>>>Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Ci= sco); > >>>Siva > >>>>Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewa= rt > >>>>Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@junip= er.net; > >>>>mpls@ietf.org > >>>>>Objet : Re: [Editorial Errata Reported] RFC6435 (3429) > >>>>> > >>>>>I agree with Martin, the text proposed by David describe more accura= tely > >>>what > >>>>we meant. > >>>>> > >>>>>Thanks, > >>>>> > >>>>>Sami > >>>>>On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > >>>>> > >>>>>>Adrian, David, > >>>>>> > >>>>>>what I think we meant here was that a loop-back function could be d= one on > >>>>an interface regardless of the presence of a MIP/MEP on that interfac= e. Yet, I > >>>>have to admit that MIP and MEP are used in Section 4 of RFC6435, thus= surely > >>>>causing confusion. > >>>>>> > >>>>>>I'd welcome the views/souvenirs of my co-authors. > >>>>>> > >>>>>>-m > >>>>>> > >>>>>>Le 12/12/2012 19:17, Adrian Farrel a ?crit : > >>>>>>>Hello, > >>>>>>> > >>>>>>>Authors of RFC 6435: I need to hear from you that you meant the te= xt that > >>>>David > >>>>>>>suggests. It is very clearly not what you wrote and, if you meant > >>>something > >>>>>>>different, it is clear why people are confused! > >>>>>>> > >>>>>>>Working group: I need to hear from you that you agree with David's > >>>>>>>interpretation and support his proposed change. > >>>>>>> > >>>>>>>Only then will I try to work out whether this is a "typo" worthy o= f an > >>>errata > >>>>>>>report, or a technical change needing a revised RFC. > >>>>>>> > >>>>>>>Thanks, > >>>>>>>Adrian > >>>>>>> > >>>>>>>>-----Original Message----- > >>>>>>>>From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>>>>>>>Sent: 12 December 2012 17:45 > >>>>>>>>To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > >>>>>>>>martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > >>>>>>>>stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; > >>>>swallow@cisco.com; > >>>>>>>>rcallon@juniper.net > >>>>>>>>Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org > >>>>>>>>Subject: [Editorial Errata Reported] RFC6435 (3429) > >>>>>>>> > >>>>>>>> > >>>>>>>>The following errata report has been submitted for RFC6435, > >>>>>>>>"MPLS Transport Profile Lock Instruct and Loopback Functions". > >>>>>>>> > >>>>>>>>-------------------------------------- > >>>>>>>>You may review the report below and at: > >>>>>>>>http://www.rfc-editor.org/errata_search.php?rfc=3D6435&eid=3D3429 > >>>>>>>> > >>>>>>>>-------------------------------------- > >>>>>>>>Type: Editorial > >>>>>>>>Reported by: David Ball > >>>>>>>> > >>>>>>>>Section: 4 (para 5) > >>>>>>>> > >>>>>>>>Original Text > >>>>>>>>------------- > >>>>>>>>It should be noted that the data-plane loopback function itself i= s > >>>applied to > >>>>>>>data- > >>>>>>>>plane loopback points residing on different interfaces from MIPs/= MEPs. > >>>>>>>> > >>>>>>>>Corrected Text > >>>>>>>>-------------- > >>>>>>>>It should be noted that the data-plane loopback function may be a= pplied > >>>at > >>>>>>>>MIPs/MEPs on different interfaces for different LSPs. > >>>>>>>> > >>>>>>>>Notes > >>>>>>>>----- > >>>>>>>>The existing text has caused confusion (specifically, among exper= ts in > >>>ITU-T > >>>>>>>SG15 > >>>>>>>>when discussing G.8121.2), in that it seems to suggest that the > >>>interface > >>>>>>>where > >>>>>>>>the MIP/MEP is located may be a different interface to the one wh= ere the > >>>>>>>>loopback is applied. > >>>>>>>> > >>>>>>>>Having spoken with some of the original authors, it seems this wa= s not > >>>the > >>>>>>>intent > >>>>>>>>of this sentence; the intent was to point out that as different L= SPs > >>>would > >>>>>>>have > >>>>>>>>MIPs/MEPs on different interfaces, the corresponding loopback fun= ctions > >>>>would > >>>>>>>>also be applied on different interfaces. > >>>>>>>> > >>>>>>>>Instructions: > >>>>>>>>------------- > >>>>>>>>This errata is currently posted as "Reported". If necessary, plea= se > >>>>>>>>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= . > >>>>>>>> > >>>>>>>>-------------------------------------- > >>>>>>>>RFC6435 (draft-ietf-mpls-tp-li-lb-08) > >>>>>>>>-------------------------------------- > >>>>>>>>Title : MPLS Transport Profile Lock Instruct and Lo= opback > >>>>>>>Functions > >>>>>>>>Publication Date : November 2011 > >>>>>>>>Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Agga= rwal, > >>>Ed., M. > >>>>>>>Vigoureux, > >>>>>>>>Ed., X. Dai, Ed. > >>>>>>>>Category : PROPOSED STANDARD > >>>>>>>>Source : Multiprotocol Label Switching > >>>>>>>>Area : Routing > >>>>>>>>Stream : IETF > >>>>>>>>Verifying Party : IESG > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>>>-- > >>>>David Ball > >>>> > >>> > >>> > >>> > > -- David Ball --_000_FEA27CFACBAF3A429E381E6FD69CDC73C492FR712WXCHMBA09zeual_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
David,

Yes it does. Thanks.
I first thought of removing all references to MEP/MIP but should have given= it a second thought.

-m
De : David = Ball
Envoy=E9 : 17/01/= 2013 18:41
=C0 : VIGOUR= EUX, MARTIN (MARTIN)
Cc : adrian= @olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan (msiva)'; raggarw= a_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart Bryant (stbryant)'; loa@pi.n= u; 'George Swallow (swallow)'; rcallon@juniper.net; mpls@ietf.org
Objet : Re: [E= ditorial Errata Reported] RFC6435 (3429)

Hi Martin,

Actually I think the last paragraph is talking about something different again: this is the MEPs that must be locked.

Here is a transport path:

  |>-------x----------x-------<|
            --------= ->|
            <----= -----v
  A        B    = ;      C       = D

A and D are the MEPs; B is the source of the test, C is the loopback
point.

As we have discussed, C could be a MIP, could be the MEP at D, or could be at a point that is neither a MIP or a MEP.

A and D are the MEPs that must be locked during the test.

My question was about point B: I think in the original text point B must always be the same as the MEP at point A; your proposal allows it to be some other point, eg at a MIP or at a point where there is no MIP or
MEP.

If we keep the original text about point B, and just change the text
about point C, then combining with your proposal we get the following
change:

Old text:
   The loopback function is used to test the integrity of a trans= port
   path from a MEP up any other node in the same MEG.  This = is achieved
   by setting the target node into loopback mode, and transmittin= g a
   pattern of test data from the MEP.  The target node loops= all
   received data back toward the originator, and the MEP extracts= the
   test data and compares it with what it sent.

   Loopback is a function that enables a receiving MEP or MIP to = return
   traffic to the sending MEP when in the loopback state.

   [...]

   The management plane must ensure that the two MEPs are locked = before
   it requests setting MEP or MIP in the loopback state.

New text:
   The loopback function is used to test the integrity of a trans= port
   path from a MEP to any other node along the same transport pat= h. 
   This is achieved by setting the target node into loopback mode= for
   that transport path, and  transmitting a pattern of test = data from
   the MEP.  The target node loops all data received on the = transport
   path back towards the sending MEP, which extracts the test dat= a
   and compares it with what it sent.

   Loopback is a function that enables a given node of a transpor= t
   path to return traffic to the sending MEP for that transport p= ath
   when in the loopback mode.

   [...]

   The management plane must ensure that the MEPs at either end o= f a
   transport path are locked before it requests setting a given n= ode of
   that transport path into loopback mode.

Does this work?


        David


On Thu, Jan 17, 2013, Martin Vigoureux wrote:
> David,
>
> agreed, and in fact this is consistent with the fact I kept MEP in
> the last paragraph I changed.
>
> -m
>
>
> Le 17/01/2013 18:09, David Ball a ?crit :
> >Thanks Martin.
> >
> >Regarding the first paragraph, I agree with your change to add &qu= ot;for that
> >transport path", that does make it clearer.
> >
> >Regarding the other paragraphs: We have agreed that the intent was= that
> >the point doing the loopback does not have to be a MEP or MIP, but= your
> >proposal also seems to change it so that the point transmitting th= e
> >test data does not have to be a MEP.  I think the original te= xt was
> >consistent that the test was done *from* a MEP; the question was w= hether
> >it was done from a MEP *to another MEP/MIP*, or from a MEP *to an<= br> > >arbitrary point*.
> >
> >So you might be right that the text describing the source of the t= est
> >should also be changed, but I think that is a slightly separate is= sue.
> >It is probably safest to keep the changes to a minimum and just fi= x the
> >description of the point that is doing the loopback, ie the target= of
> >the test.
> >
> >Do you agree?
> >
> >
> >     David
> >
> >
> >On Thu, Jan 17, 2013, Martin Vigoureux wrote:
> >>Adrian, yes, we are.
> >>
> >>So, David,
> >>
> >>I am fine with your suggested text which says:
> >>    It should be noted that the data-plane loop= back function for a
> >>    given transport path can be applied to data= -plane loopback points
> >>    residing on interfaces where there may be n= o corresponding MEP or
> >>    MIP.
> >>
> >>I was thinking of:
> >>s/may be no corresponding MEP or MIP./may be no MEP or MIP for= that
> >>transport path./
> >>but this is optional.
> >>
> >>The new text will replace:
> >>    It should be noted that the data-plane loop= back function itself is
> >>    applied to data-plane loopback points resid= ing on different
> >>    interfaces from MIPs/MEPs.
> >>
> >>
> >>Regarding the other paragraphs:
> >>    The loopback function is used to test the i= ntegrity of a transport
> >>    path from a MEP up any other node in the sa= me MEG.  This is achieved
> >>    by setting the target node into loopback mo= de, and transmitting a
> >>    pattern of test data from the MEP.  Th= e target node loops all
> >>    received data back toward the originator, a= nd the MEP extracts the
> >>    test data and compares it with what it sent= .
> >>
> >>    Loopback is a function that enables a recei= ving MEP or MIP to return
> >>    traffic to the sending MEP when in the loop= back state.
> >>
> >>    [...]
> >>
> >>    The management plane must ensure that the t= wo MEPs are locked before
> >>    it requests setting MEP or MIP in the loopb= ack state.
> >>
> >>
> >>They could be changed into:
> >>    The loopback function is used to test the i= ntegrity of a transport
> >>    path.  This is achieved by setting a g= iven node into loopback mode
> >>    for a given transport path, and sending ove= r it a pattern of test
> >>    data.  The node in loopback mode loops= all test data received on the
> >>    transport path back towards the sender, whi= ch extracts the test
> >>    data and compares it with what it sent.
> >>
> >>    Loopback is a function which enables a give= n node of a transport
> >>    path, when in the loopback mode, to return = traffic to the sender of
> >>    that traffic.
> >>
> >>    [...]
> >>
> >>    The management plane must ensure that the M= EPs of a transport path
> >>    are locked before it requests setting a giv= en node of that transport
> >>    path in loopback mode.
> >>
> >>Let me know.
> >>-m
> >>
> >>Le 16/01/2013 22:07, Adrian Farrel a ?crit :
> >>>All, are we getting any closer to agreeing what we all int= ended to say?
> >>>
> >>>Once we have that, I can work out what to do with the Erra= ta Report.
> >>>
> >>>Thanks,
> >>>Adrian
> >>>
> >>>>-----Original Message-----
> >>>>From: David Ball [mailto:daviball@cisco.com]
> >>>>Sent: 10 January 2013 17:57
> >>>>To: VIGOUREUX, MARTIN (MARTIN)
> >>>>Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva= Sivabalan (msiva);
> >>>>raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart B= ryant (stbryant);
> >>>>loa@pi.nu; George Swallow (swallow); rcallon@juniper.n= et; mpls@ietf.org
> >>>>Subject: Re: [Editorial Errata Reported] RFC6435 (3429= )
> >>>>
> >>>>Hi Martin,
> >>>>
> >>>>Ah, right I see: since the loopback is locally configu= red, there is no
> >>>>need for a MEP/MIP to send/receive OAM frames - but th= ere may be a
> >>>>MEP/MIP.
> >>>>
> >>>>So would this work to clarify the text?
> >>>>   "It should be noted that the data-pl= ane loopback function for a
> >>>>    given transport path can be applied= to data-plane loopback points
> >>>>    residing on interfaces where there = may be no corresponding MEP or
> >>>>    MIP."
> >>>>
> >>>>For completeness, the references to "MEP or MIP&q= uot; in paragraphs 3 and 7
> >>>>of section 4 would also need to be changed, to instead= refer to the
> >>>>transport path that is being put in to loopback.
> >>>>
> >>>>As another data point, I found this text in RFC6371 se= ction 6.3.2:
> >>>>   "It should be noted that data-plane = loopback function itself is
> >>>>    applied to data-plane loopback poin= ts that can reside on different
> >>>>    interfaces from MIPs/MEPs." > >>>>Note the critical difference compared to RFC6435: &quo= t;that can reside"
> >>>>instead of "residing".
> >>>>
> >>>>Thanks
> >>>>
> >>>>
> >>>>  David
> >>>>
> >>>>
> >>>>On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote= :
> >>>>>Sami,
> >>>>>
> >>>>>Thanks. Yet, I am not sure David's interpretation = and mine exactly match.
> >>>>>David, correct me if I am wrong. For me it says th= at we can do
> >>>>>loopback on different interfaces (for different LS= Ps) but implies that
> >>>>>there is a mip/mep for that lsp on that interface,= while my
> >>>>>interpretation is that the presence of a mip/mep f= or that lsp on that
> >>>>>interface is not needed.
> >>>>>
> >>>>>-m
> >>>>>________________________________
> >>>>>De : Sami Boutros (sboutros)
> >>>>>Envoy? : 09/01/2013 19:00
> >>>>>? : VIGOUREUX, MARTIN (MARTIN)
> >>>>>Cc : adrian@olddog.co.uk; David Ball -X (daviball = - Ensoft Ltd at Cisco);
> >>>Siva
> >>>>Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zt= e.com.cn; Stewart
> >>>>Bryant (stbryant); loa@pi.nu; George Swallow (swallow)= ; rcallon@juniper.net;
> >>>>mpls@ietf.org
> >>>>>Objet : Re: [Editorial Errata Reported] RFC6435 (3= 429)
> >>>>>
> >>>>>I agree with Martin, the text proposed by David de= scribe more accurately
> >>>what
> >>>>we meant.
> >>>>>
> >>>>>Thanks,
> >>>>>
> >>>>>Sami
> >>>>>On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote= :
> >>>>>
> >>>>>>Adrian, David,
> >>>>>>
> >>>>>>what I think we meant here was that a loop-bac= k function could be done on
> >>>>an interface regardless of the presence of a MIP/MEP o= n that interface. Yet, I
> >>>>have to admit that MIP and MEP are used in Section 4 o= f RFC6435, thus surely
> >>>>causing confusion.
> >>>>>>
> >>>>>>I'd welcome the views/souvenirs of my co-autho= rs.
> >>>>>>
> >>>>>>-m
> >>>>>>
> >>>>>>Le 12/12/2012 19:17, Adrian Farrel a ?crit : > >>>>>>>Hello,
> >>>>>>>
> >>>>>>>Authors of RFC 6435: I need to hear from y= ou that you meant the text that
> >>>>David
> >>>>>>>suggests. It is very clearly not what you = wrote and, if you meant
> >>>something
> >>>>>>>different, it is clear why people are conf= used!
> >>>>>>>
> >>>>>>>Working group: I need to hear from you tha= t you agree with David's
> >>>>>>>interpretation and support his proposed ch= ange.
> >>>>>>>
> >>>>>>>Only then will I try to work out whether t= his is a "typo" worthy of an
> >>>errata
> >>>>>>>report, or a technical change needing a re= vised RFC.
> >>>>>>>
> >>>>>>>Thanks,
> >>>>>>>Adrian
> >>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> >>>>>>>>Sent: 12 December 2012 17:45
> >>>>>>>>To: sboutros@cisco.com; msiva@cisco.co= m; raggarwa_1@yahoo.com;
> >>>>>>>>martin.vigoureux@alcatel-lucent.com; d= ai.xuehui@zte.com.cn;
> >>>>>>>>stbryant@cisco.com; adrian@olddog.co.u= k; loa@pi.nu;
> >>>>swallow@cisco.com;
> >>>>>>>>rcallon@juniper.net
> >>>>>>>>Cc: daviball@cisco.com; mpls@ietf.org;= rfc-editor@rfc-editor.org
> >>>>>>>>Subject: [Editorial Errata Reported] R= FC6435 (3429)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>The following errata report has been s= ubmitted for RFC6435,
> >>>>>>>>"MPLS Transport Profile Lock Inst= ruct and Loopback Functions".
> >>>>>>>>
> >>>>>>>>--------------------------------------=
> >>>>>>>>You may review the report below and at= :
> >>>>>>>>http://www.rfc-editor.org/errat= a_search.php?rfc=3D6435&eid=3D3429
> >>>>>>>>
> >>>>>>>>--------------------------------------=
> >>>>>>>>Type: Editorial
> >>>>>>>>Reported by: David Ball<daviball@ci= sco.com>
> >>>>>>>>
> >>>>>>>>Section: 4 (para 5)
> >>>>>>>>
> >>>>>>>>Original Text
> >>>>>>>>-------------
> >>>>>>>>It should be noted that the data-plane= loopback function itself is
> >>>applied to
> >>>>>>>data-
> >>>>>>>>plane loopback points residing on diff= erent interfaces from MIPs/MEPs.
> >>>>>>>>
> >>>>>>>>Corrected Text
> >>>>>>>>--------------
> >>>>>>>>It should be noted that the data-plane= loopback function may be applied
> >>>at
> >>>>>>>>MIPs/MEPs on different interfaces for = different LSPs.
> >>>>>>>>
> >>>>>>>>Notes
> >>>>>>>>-----
> >>>>>>>>The existing text has caused confusion= (specifically, among experts in
> >>>ITU-T
> >>>>>>>SG15
> >>>>>>>>when discussing G.8121.2), in that it = seems to suggest that the
> >>>interface
> >>>>>>>where
> >>>>>>>>the MIP/MEP is located may be a differ= ent interface to the one where the
> >>>>>>>>loopback is applied.
> >>>>>>>>
> >>>>>>>>Having spoken with some of the origina= l authors, it seems this was not
> >>>the
> >>>>>>>intent
> >>>>>>>>of this sentence; the intent was to po= int out that as different LSPs
> >>>would
> >>>>>>>have
> >>>>>>>>MIPs/MEPs on different interfaces, the= corresponding loopback functions
> >>>>would
> >>>>>>>>also be applied on different interface= s.
> >>>>>>>>
> >>>>>>>>Instructions:
> >>>>>>>>-------------
> >>>>>>>>This errata is currently posted as &qu= ot;Reported". If necessary, please
> >>>>>>>>use "Reply All" to discuss w= hether it should be verified or
> >>>>>>>>rejected. When a decision is reached, = the verifying party (IESG)
> >>>>>>>>can log in to change the status and ed= it the report, if necessary.
> >>>>>>>>
> >>>>>>>>--------------------------------------=
> >>>>>>>>RFC6435 (draft-ietf-mpls-tp-li-lb-08)<= br> > >>>>>>>>--------------------------------------=
> >>>>>>>>Title     &nb= sp;         : MPLS Transport Profil= e Lock Instruct and Loopback
> >>>>>>>Functions
> >>>>>>>>Publication Date    : N= ovember 2011
> >>>>>>>>Author(s)     = ;      : S. Boutros, Ed., S. Sivabalan, Ed., R. Ag= garwal,
> >>>Ed., M.
> >>>>>>>Vigoureux,
> >>>>>>>>Ed., X. Dai, Ed.
> >>>>>>>>Category     =        : PROPOSED STANDARD
> >>>>>>>>Source     &n= bsp;        : Multiprotocol Label Switch= ing
> >>>>>>>>Area     &nbs= p;          : Routing
> >>>>>>>>Stream     &n= bsp;        : IETF
> >>>>>>>>Verifying Party    = ; : IESG
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>>--
> >>>>David Ball
> >>>><daviball@cisco.com>
> >>>
> >>>
> >>>
> >

--
David Ball
<daviball@cisco.com>
 --_000_FEA27CFACBAF3A429E381E6FD69CDC73C492FR712WXCHMBA09zeual_-- From ietfc@btconnect.com Thu Jan 17 13:01:23 2013 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 7497021F87FB for ; Thu, 17 Jan 2013 13:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.005 X-Spam-Level: X-Spam-Status: No, score=-4.005 tagged_above=-999 required=5 tests=[AWL=-0.406, 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 CIV4NXughJMi for ; Thu, 17 Jan 2013 13:01:22 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 540A821F86B1 for ; Thu, 17 Jan 2013 13:01:21 -0800 (PST) Received: from mail66-ch1-R.bigfish.com (10.43.68.230) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 17 Jan 2013 21:01:20 +0000 Received: from mail66-ch1 (localhost [127.0.0.1]) by mail66-ch1-R.bigfish.com (Postfix) with ESMTP id BE6BB2002C3; Thu, 17 Jan 2013 21:01:20 +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: -20 X-BigFish: PS-20(zz9371I542I1432I1418Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h304l1155h) Received: from mail66-ch1 (localhost.localdomain [127.0.0.1]) by mail66-ch1 (MessageSwitch) id 1358456479584553_28664; Thu, 17 Jan 2013 21:01:19 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail66-ch1.bigfish.com (Postfix) with ESMTP id 8AA4A4E0089; Thu, 17 Jan 2013 21:01:19 +0000 (UTC) Received: from AMSPRD0710HT003.eurprd07.prod.outlook.com (157.56.249.85) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 17 Jan 2013 21:01:11 +0000 Received: from DB3PRD0511HT001.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.160.166) with Microsoft SMTP Server (TLS) id 14.16.257.4; Thu, 17 Jan 2013 21:01:08 +0000 Message-ID: <001401cdf4f5$6c891360$4001a8c0@gateway.2wire.net> From: t.petch To: , References: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> <50F6BB94.4000206@gmail.com> Date: Thu, 17 Jan 2013 20:58:31 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.213] X-OriginatorOrg: btconnect.com Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] working group last call 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, 17 Jan 2013 21:01:23 -0000 ----- Original Message ----- From: "Huub van Helvoort" To: Cc: ; ; Sent: Wednesday, January 16, 2013 2:39 PM > Editors, > > You need to fix the acronym expansion for MEP and MIP: > > MEP Maintenance Entity Group End Point > MIP Maintenance Entity Group Intermediate Point and, at the same time, that other hoary old chestnut OAM Operations, Administration and Maintenance On a slightly different tack, if Security Considerations calls out [RFC5920] as Normative (rightly so, IMO), then I think that [MPLS-TP Sec FW] must also be Normative. And, while I am on, there are still a fair number of places where the English reads oddly. My sense was that Adrian, in August, provided a list of some of the instances where he saw that corrections would be beneficial but I think that his list was never meant to be inclusive. For example, to take a paragraph at random, there is currently OLD Some operators are using the similar model as in 2G and 3G Mobile Backhaul, which uses IP/MPLS in the core, and MPLS-TP with static provisioning through NMS in aggregation and access. The reasoning is the following: X2 traffic load in LTE network is currently a very small percentage, e.g., some large mobile operator observed less than one percent of total S1 traffic. Therefore, optimizing X2 traffic is not the design objective, X2 traffic can be carried through the same static tunnels together with S1 traffic in the aggregation and access networks, and further forwarded accross IP/MPLS core. In addition, Mesh protection may be more efficient in regard of bandwidth utilization, but linear protection and ring protection are considered simpler by some operators from operation maintenance and trouble shooting point of view, therefore widely deployed. In general, using MPLS-TP with NMS model for LTE backhaul is a viable approach. The design objective of using this approach is to keep the operation simple and with unified model for mobile backhaul. which, editing just the English and not the meaning, might produce, with an asterisk(*) indicating a change NEW Some operators are using the *same model as in 2G and 3G Mobile Backhaul, which uses IP/MPLS in the core, and MPLS-TP with static provisioning *(through NMS*) in aggregation and access. The reasoning is *as follows: *the X2 traffic load in LTE *networks is currently a very small percentage, e.g., some large mobile *operators *observe less than one percent of total S1 traffic. Therefore, optimizing X2 traffic is not *a design objective*, X2 traffic can be carried through the same static tunnels *as S1 traffic in the aggregation and access networks, and forwarded *across *the IP/MPLS core. In addition, Mesh protection may be more efficient *with regard *to bandwidth utilization, but linear protection and ring protection are considered simpler by some operators from the *point of view of operation*, maintenance and trouble shooting *and so are widely deployed. In general, using MPLS-TP with *static provisioning *(through NMS) for LTE backhaul is a viable approach. The design objective of using this approach is to keep the operation simple and *use a *common model for mobile backhaul. Um; quite a few changes (or we could leave it to the RFC Editor). Tom Petch > Regards, Huub. > > ====== > > > this is to start a two week Working Group last call on > > draft-ietf-mpls-tp-use-cases-and-design. > > > > This is the second time we working group last call this > > draft, it has been updated after comments during the > > ADE-review. The changes are such that we have decided to > > do a full two week wglc. > > > > 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. > > > > There are no IPR claims against this draft. > > > > All the co-authors has stated that they are not aware > > of any IPRs. > > > > This working group last call will end on January 25, 2013. > > > > /Loa > > for the wg co-chairs > > > From eric.gray@ericsson.com Thu Jan 17 14:03:09 2013 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 5D5AC21F8786 for ; Thu, 17 Jan 2013 14:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 86VqpRtAMk7V for ; Thu, 17 Jan 2013 14:03:06 -0800 (PST) Received: from usevmg20.ericsson.net (unknown [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 45D3721F8777 for ; Thu, 17 Jan 2013 14:03:05 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-50-50f87518671f Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 81.B2.31450.81578F05; Thu, 17 Jan 2013 23:03:05 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 17:03:04 -0500 From: Eric Gray To: "draft-ietf-mpls-ldp-dod@tools.ietf.org" Thread-Topic: Review comments on Draft "LDP Downstream-on-Demand in Seamless MPLS" Thread-Index: Ac306C+R24oo5eZ+SSSmNMTEKQ/BRg== Date: Thu, 17 Jan 2013 22:03:03 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF605EC75@eusaamb107.ericsson.se> 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_48E1A67CB9CA044EADFEAB87D814BFF605EC75eusaamb107ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyuXRPiK5k6Y8AgwmPuCze7HnLanFr6UpW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj9IljzAVTSivetvxma2CcntzFyMkhIWAi se/OHFYIW0ziwr31bF2MXBxCAkcYJda0XWaCcJYzSiy8t40ZpIpNQEPi2J21jCC2iEC4xMXZ d4BsDg5mAWWJU3dlQMLCAr4Sf248Z4YoCZGY2jidFcLWk9hwYzY7iM0ioCqx6XkrM0grr4C3 xIHFxiBhRqAbvp9awwRiMwuIS9x6Mp8J4jYBiSV7zjND2KISLx//g7pZWWLJk/0sEPX5Ek3v t4LFeQUEJU7OfMIygVF4FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2Vcx cpQWp5blphsZbGIExsgxCTbdHYx7XloeYpTmYFES5w1yvRAgJJCeWJKanZpakFoUX1Sak1p8 iJGJg1OqgVHmsdmBmOmTb/LJvz+9iTXHkiXL49D187/TbW2WOC15lbJD4pyD+9Si8rkd699k zt/DkmD7/ye70M2VDyImHmJqCXt12lZqbtZ+Zf0PpYeWspxkminvb1u4WrfvtLlF8UnLqMMF 0V7zXZmeTS/8wLHfZe/02JpOE6sYIQcbSyWfzwpbNhysz1diKc5INNRiLipOBADj91o0XwIA AA== Cc: "mpls@ietf.org" Subject: [mpls] Review comments on Draft "LDP Downstream-on-Demand in Seamless MPLS" 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, 17 Jan 2013 22:03:09 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF605EC75eusaamb107ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, I found this draft to be fairly complete and - with some mi= nor changes - it should be relatively easy to read. One aspect of this draft that I find somewhat unsettling is= the implication that most LSRs do not support downstream on demand label distribution. This would seem to be at odds wit= h the implementation report used in writing RFC 5036 (Draft Standard "LDP Specification"), or DoD would have= been omitted in that RFC. The latter half of the 3rd paragraph on page 5 is an interp= retation of one reason for specification of DoD label allocation, and is not quite accurate even in that sense. The main r= eason for DoD allocation with ATM - in particular - was because of the great difficulty associated with merging to= o many upstream paths into a single downstream LSP - when the downstream LSP is in fact an ATM VCC. It should = be sufficient to state that - in at least some implementations - LDP DoD is not implemented and leave the justi= fication for this implementation decision unspecified. Speculation as to why implementers make the choices they do= is just that - speculation.. Note that RFC 5036 was itself published in October of 2007,= when ATM and Frame Relay deployments were scarce in general and new deployments of MPLS-based ATM and Frame Rela= y were non-existent. Readers might also want to realize that the MPLS Architectu= re assumes both DU and DoD capabilities exist in MPLS but may or may not be implemented in any specific MPLS implem= entation. I do have some issues with the fact that this draft seems i= ntent on describing a subset of DoD specified in RFC 5036 that applies specifically to the use cases that this draft iden= tifies. Might it not be a great deal simpler to state that DoD - as= specified in RFC 5036 and described in RFCs 3031 and 3215 - should be implemented for support of those use cases? Will = we need to describe a different subset when we discover additional use cases? The document does provide a really good discussion of inter= actions between control and distribution modes for labels and the use/support of DoD. It appears to have missed one= or two points that originally came out when all of this stuff was being initially specified. 1) The combination of liberal retention and downstream on demand is a very = inefficient approach to populating an LSR's label tables. If you're going to ask for them all anyway, wh= y not indicate to your peer that you want all of them sent to you in the first place? 2) The combination of ordered control mode and downstream on demand means t= hat a LSR only needs to bind any FEC to a label when - a) it knows how to forward packets for that FEC (i.e. - it has a route= corresponding to the FEC) and b) it has received at least one label-request message from an upstream= LSR. The latter point is incorrectly reflected in the second bul= let in section 4.1. The paragraph after the bullets describing conservative and= liberal retention modes seems to assume a very weak (or very literal) implementation of conservative retenti= on mode, in assuming that a label will not be retained if it is not associated with the current active = route. Obviously an LSR may retain any labels it needs to meet all of the requirements of the services it supp= orts and still be using conservative retention mode if it does not retain every label ever distributed to it. NITs In the second paragraph of the Introduction section, the last two sentences= should be a separate paragraph. The two sentences address a different aspect of the focus of this document. In the 4th paragraph of the Introduction, the expression "a very insufficie= nt" is not particularly meaningful as the degree of insufficiency is subjective and likely immeasurable. Replace thi= s phrase with "an inadequate ..." Also, replace "as they" with "which" in the portion of the same sentence that fol= lows the comma. The phrase "MPLS routers" that is used earlier in the same paragraph is unc= lear and is most likely meant to be "Label Switching Routers" or "LSRs." --_000_48E1A67CB9CA044EADFEAB87D814BFF605EC75eusaamb107ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors,

 

        &nbs= p;       I found this draft to be fairly comp= lete and – with some minor changes – it should be relatively ea= sy to

read.

 

        &nbs= p;       One aspect of this draft that I find= somewhat unsettling is the implication that most LSRs do not support<= /o:p>

downstream on demand label distribution.  This = would seem to be at odds with the implementation report used

in writing RFC 5036 (Draft Standard "LDP Specif= ication"), or DoD would have been omitted in that RFC.

 

        &nbs= p;       The latter half of the 3rd paragraph on page 5 is an interpretation of one reason for specificati= on of DoD

label allocation, and is not quite accurate even in = that sense.  The main reason for DoD allocation with ATM – in

particular – was because of the great difficul= ty associated with merging too many upstream paths into a single=

downstream LSP – when the downstream LSP is in= fact an ATM VCC.  It should be sufficient to state that – in at

least some implementations – LDP DoD is not im= plemented and leave the justification for this implementation

decision unspecified.

 

        &nbs= p;       Speculation as to why implementers m= ake the choices they do is just that – speculation..

 

        &nbs= p;       Note that RFC 5036 was itself publis= hed in October of 2007, when ATM and Frame Relay deployments

were scarce in general and new deployments of MPLS-b= ased ATM and Frame Relay were non-existent.

 

        &nbs= p;       Readers might also want to realize t= hat the MPLS Architecture assumes both DU and DoD capabilities

exist in MPLS but may or may not be implemented in a= ny specific MPLS implementation.

 

        &nbs= p;       I do have some issues with the fact = that this draft seems intent on describing a subset of DoD specified

in RFC 5036 that applies specifically to the use cas= es that this draft identifies.

 

        &nbs= p;       Might it not be a great deal simpler= to state that DoD – as specified in RFC 5036 and described in RFCs

3031 and 3215 – should be implemented for supp= ort of those use cases? Will we need to describe a different

subset when we discover additional use cases?

 

        &nbs= p;       The document does provide a really g= ood discussion of interactions between control and distribution<= /p>

modes for labels and the use/support of DoD.  I= t appears to have missed one or two points that originally came

out when all of this stuff was being initially speci= fied. 

 

1) The combination of liberal retention and downstre= am on demand is a very inefficient approach to populating

     an LSR's label tables.=   If you're going to ask for them all anyway, why not indicate to your= peer that you want

     all of them sent to you in = the first place?

2) The combination of ordered control mode and downs= tream on demand means that a LSR only needs to bind

      any FEC to a lab= el when –

     a) it knows how to forward = packets for that FEC (i.e. – it has a route corresponding to the FEC) and

     b) it has received at least= one label-request message from an upstream LSR.

 

        &nbs= p;       The latter point is incorrectly refl= ected in the second bullet in section 4.1.

 

        &nbs= p;       The paragraph after the bullets desc= ribing conservative and liberal retention modes seems to

assume a very weak (or very literal) implementation = of conservative retention mode, in assuming that a

label will not be retained if it is not associated w= ith the current active route.  Obviously an LSR may retain<= /p>

any labels it needs to meet all of the requirements = of the services it supports and still be using conservative

retention mode if it does not retain every label eve= r distributed to it.

        &nbs= p;      

 

NITs

 

In the second paragraph of the Introduction section,= the last two sentences should be a separate paragraph.

The two sentences address a different aspect of the = focus of this document.

 

In the 4th paragraph of the Introduction,= the expression "a very insufficient" is not particularly meaning= ful as the

degree of insufficiency is subjective and likely imm= easurable.  Replace this phrase with "an inadequate …"= Also,

replace "as they" with "which" i= n the portion of the same sentence that follows the comma.

 

The phrase "MPLS routers" that is used ear= lier in the same paragraph is unclear and is most likely meant to be

"Label Switching Routers" or "LSRs.&q= uot;

 

 

 

 

--_000_48E1A67CB9CA044EADFEAB87D814BFF605EC75eusaamb107ericsso_-- From zjbdamo@hotmail.com Thu Jan 17 17:29:45 2013 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 ED33521F8AF2 for ; Thu, 17 Jan 2013 17:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.544 X-Spam-Level: **** X-Spam-Status: No, score=4.544 tagged_above=-999 required=5 tests=[AWL=1.443, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_72=0.6, MIME_8BIT_HEADER=0.3] 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 IERDl85W-fZu for ; Thu, 17 Jan 2013 17:29:45 -0800 (PST) Received: from blu0-omc4-s30.blu0.hotmail.com (blu0-omc4-s30.blu0.hotmail.com [65.55.111.169]) by ietfa.amsl.com (Postfix) with ESMTP id B928021F8AE7 for ; Thu, 17 Jan 2013 17:29:44 -0800 (PST) Received: from BLU168-W50 ([65.55.111.136]) by blu0-omc4-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jan 2013 17:29:43 -0800 X-EIP: [ceCfQjNuKM0wOyYEq8MdjZLk6tOP34aS] X-Originating-Email: [zjbdamo@hotmail.com] Message-ID: Content-Type: multipart/mixed; boundary="_098b419e-29dc-4fb2-ab60-b6a210ab219e_" From: =?utf-8?B?5pu+5bO75rOi?= To: "mpls@ietf.org" Date: Fri, 18 Jan 2013 09:29:44 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2013 01:29:43.0916 (UTC) FILETIME=[4B4222C0:01CDF51B] Subject: [mpls] doubt about RFC6378. 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, 18 Jan 2013 01:29:46 -0000 --_098b419e-29dc-4fb2-ab60-b6a210ab219e_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCihoaSxlcmljIGFuZCB5YWFjb3YsaSBkb24ndCBrbm93IHdoeSBpIGNhbid0IHJlcGx5IHRo ZSB0b3BpYyB0aGF0IHdlIGRpc2N1c3NlZCBiZWZvcmUtLS0iIGluIHNvbWUgc2NlbmFyaW8gUkZD NjM3OCBjYW4gbm90IHByb3RlY3QgdGhlIHRyYWZmaWMsIHNvIG11Y2ggYXMgdGFrZSB0aGUgUFND IHN0YXRlIHRvIGNyYXNoIi4gYW5kIGkgaGF2ZSB0byBjcmVhdGUgYSBuZXcgdG9waWMgdG8gY29u dGludWUgdGhlIGRpc2N1c3Npb24udGhlIGxhdGVzdCBkaXNjdXNzaW9uIHJlY29yZHMgaXMgaGVy ZSANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNn MDkzNjcuaHRtbA0KdGhlIGZvbGxvd2luZyBpcyBteSBsYXRlc3QgcmVwbHksYW5kIGlmIGZpZ3Vy ZXMgY2FuIG5vdCBiZSBkaXNwbGF5ZWQgbm9ybWFsbHksIHBsZWFzZSBzZWUgdGhlIGF0dGFjaCBm aWxlLikNCg0KeWVzLGl0IHdpbGwgZml4IHNvbWUgYnVncyBpbiBQU0MsY29tcGFyZSB0aGUgZm9s bG93aW5nIDIgZmlndXJlcy4NCmluIGZpZ3VyZTQud2hlbiBMRVIxIHJlY2VpdmUgcGVlcidzIEZT IFBTQyBtc2csYWNjb3JkaW5nIHRvIFJGQzYzNzgsTEVSMSB3aWxsIHNlbmQgTlIgdG8gTEVSMixh bmQgd2hlbiBjbGVhciBjb21tYW5kIGlucHV0IGludG8gTEVSMixMRVIyIHdpbGwgdHJhbnNmZXIg aW50byBOT1JNQUwgc3RhdGUgYW5kIHN3aXRjaCB0cmFmZmljIHRvIHdvcmsgcGF0aCxidXQgTEVS MSdzIHRyYWZmaWMgc3RpbGwgb24gcHJvdGVjdGlvbiBwYXRoLiBzbyB0cmFmZmljIGlzIGJyb2tl bi53aGVuIHRoZSBOUiByZWFjaCBMRVIxLExFUjEgcmVldmFsdWF0ZSBhbGwgaW5wdXRzIGFuZCB0 cmFuc2ZlciBpbmZvIFBBOk06TCxrZWVwIHRyYWZmaWMgb24gcHJvdGVjdGlvbiBhbmQgc2VuZCBN UyB0byBMRVIyLndoZW4gTVMgcmVhY2ggTEVSMix0aGUgdHJhZmZpYyBpcyByZXN0b3JlZC4NCsKg DQppbiBmaWd1cmU1LExFUjEgd2lsbCBzdGlsbCBzZW5kIGhpcyBsb2NhbCBoaWdoZXN0IHByaW9y aXR5IGNvbmRpdGlvbiAoaW4gdGhpcyBleGFtcGxlLGl0IGlzIE1TKSB0byBwZWVyIHdoZW4gcmVj ZWl2ZSBGUyBmcm9tIExFUjIuYW5kIHdoZW4gY2xlYXIgY29tbWFuZCBpbnB1dCBpbnRvIExFUjIs TEVSMiB3aWxsIHRyYW5zZmVyIGluZm8gUEE6TTpSIGFuZCBrZWVwIHRyYWZmaWMgb24gcHJvdGVj dGlvbiBwYXRoIGFuZCBuZXZlciBiZSBicm9rZW4uDQrCoA0KaSB0aGluayBzaW1wbGUgaXMgYmVh dXRpZnVsLg0KwqANCsKgIA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgKy0tLS0tLSvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgKy0tLS0tLSsNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHwgTEVSMSB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHwgTEVSMiB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tKy0tK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tKy0tKw0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIE7CoMKgwqAgKy0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0t LS0tLS0+fMKgIE4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfDwtLS0tLS0tLS1OUi0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KwqDCoMKgwqDCoMKgIGxvY2FsIE1TIGNvbW1hbmQgaW5wdXQgfMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgUEE6TTpMwqDCoCArLS0tLS0tLS0tLS1NUy0tLS0tLS0tLS0tLS0tLS0tLT58wqAgUEE6TTpS DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0t LS0tLSsNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHzCoCBsb2NhbCBGUyBjb21tYW5kIGlucHV0DQrCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBQQTpGOlIgfDwtLS0t LS0tLS1GUy0tLS0tLS0tLS0tLS0tLS0tLS0tKyBQQTpGOkwNCsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgKy0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8 wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgfCBsb2NhbCBjbGVhciBpbnB1dCx0cmFuc2ZlciBpbmZvDQrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8 LS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0tLSsgTiwgc3dpdGNoIHRyYWZmaWMgdG8gd29y ayBwYXRoLg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgfMKgIHRyYWZmaWMgaXMgYnJva2VuDQrCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCB8DQrCoMKgIHJlZXZhbHVhdGUgYWxsIGlucHV0IGFuZMKgwqAgfMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqAg dHJhbnNmZXIgaW5mb8KgwqAgUEE6TTpMwqDCoMKgwqAgKy0tLS0tLS0tLS1NUy0tLS0tLS0tLS0t LS0tLS0tLS0+fFBBOk1fUg0KwqBrZWVwIHRyYWZmaWMgb24gcHJvdGVjdGlvbsKgwqAgfMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHxMRVIyIHdpbGwgc3dpdGNoIHRyYWZmaWMgdG8NCsKgwqDCoMKgwqDCoCBwYXRowqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8cHJvdGVjdGlvbiBwYXRoLHRyYWZm aWMgaXMgcmVzdG9yZWQuDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8LS0tLS0tLS0tLS1OUi0tLS0tLS0tLS0t LS0tLS0tLSsNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgDQrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIGZpZ3VyZSA0OnNlbmQgTlIgdG8gcmVhY3Rpb24gd2hlbiBwZWVyIGlzIGhpZ2hlciBwcmlv cml0eSB3aWxsIG1ha2UgdHJhZmZpYyBicm9rZW4gYWNjaWRlbnRhbGx5DQrCoA0KwqAgDQrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tLS0tK8Kg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tLS0tKw0K wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCBMRVIx IHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCBMRVIy IHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICst LS0rLS0rwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICst LS0rLS0rDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg TsKgwqDCoCArLS0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLT58wqAgTg0KwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg fA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8PC0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQrCoMKg wqDCoMKgwqAgbG9jYWwgTVMgY29tbWFuZCBpbnB1dCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBQQTpNOkzCoMKgICstLS0tLS0t LS0tLU1TLS0tLS0tLS0tLS0tLS0tLS0tPnzCoCBQQTpNOlINCsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgfDwtLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIGxv Y2FsIEZTIGNvbW1hbmQgaW5wdXQNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIFBBOkY6UiB8PC0tLS0tLS0tLUZTLS0tLS0tLS0tLS0tLS0t LS0tLS0rIFBBOkY6TA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS0tLS0tLU1TLS0tLS0t LS0tLS0tLS0tLS0tLS0tLT58DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IGxv Y2FsIGNsZWFyIGlucHV0LHJlZXZhbHVhdGUgYWxsIGlucHV0DQrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8LS0tLS0tLS0tTlItLS0t LS0tLS0tLS0tLS0tLS0tLSsgdHJhbnNmZXIgaW5mbyBQQTpNOlIga2VlcCB0cmFmZmljIG9uDQrC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCB8wqAgcHJvdGVjdGlvbiBwYXRoLg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoCByZWV2YWx1YXRl IGFsbCBpbnB1dCBhbmTCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgIHRyYW5zZmVyIGluZm/CoCBQQTpNOkzC oMKgwqDCoMKgICstLS0tLS0tLS0tTVMtLS0tLS0tLS0tLS0tLS0tLS0tPnxQQTpNX1INCsKga2Vl cCB0cmFmZmljIG9uIHByb3RlY3Rpb27CoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDCoMKgwqAgcGF0aMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0K wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCB8PC0tLS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0rDQrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQrCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCB8DQrCoA0KwqANCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZmlndXJlIDU6YWx3YXlzIHNlbmQg bG9jYWwgaGlnaGVzdCBwcmlvcml0eSBjb25kaXRpb24gdG8gcGVlcix3aWxsIG5ldmVyIGJyb2tl biB0cmFmZmljIGFjY2lkZW50YWxseQ0KwqAgDQrCoA0KQmVzdCBSZWdhcmRzIQ0KDQpKdW5ibyBa ZW5nKEJvQm8pDQoNCg0KIAkJIAkgICAJCSAg --_098b419e-29dc-4fb2-ab60-b6a210ab219e_ Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="figures.txt" ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAg ICArLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICB8IExFUjEgfCAgICAgICAgICAg ICAgICAgICAgICAgICB8IExFUjIgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tKy0t KyAgICAgICAgICAgICAgICAgICAgICAgICArLS0tKy0tKw0KICAgICAgICAgICAgICAgICAgICAg ICAgIE4gICAgKy0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgTg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS1OUi0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgICAgIGxvY2FsIE1TIGNvbW1hbmQgaW5wdXQgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAg UEE6TTpMICAgKy0tLS0tLS0tLS0tTVMtLS0tLS0tLS0tLS0tLS0tLS0+fCAgUEE6TTpSDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLU5S LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBsb2NhbCBGUyBjb21tYW5kIGlucHV0DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgIFBBOkY6UiB8PC0tLS0tLS0tLUZTLS0tLS0t LS0tLS0tLS0tLS0tLS0rIFBBOkY6TA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCBsb2NhbCBjbGVhciBpbnB1dCx0cmFuc2ZlciBpbmZvDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0t LS0rIE4sIHN3aXRjaCB0cmFmZmljIHRvIHdvcmsgcGF0aC4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIHRyYWZmaWMgaXMg YnJva2VuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICByZWV2YWx1YXRlIGFsbCBpbnB1dCBhbmQgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB0cmFuc2ZlciBpbmZvICAgUEE6 TTpMICAgICArLS0tLS0tLS0tLU1TLS0tLS0tLS0tLS0tLS0tLS0tLT58UEE6TV9SDQoga2VlcCB0 cmFmZmljIG9uIHByb3RlY3Rpb24gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 TEVSMiB3aWxsIHN3aXRjaCB0cmFmZmljIHRvDQogICAgICAgcGF0aCAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8cHJvdGVjdGlvbiBwYXRoLHRyYWZm aWMgaXMgcmVzdG9yZWQuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 PC0tLS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCiAg ICAgICAgICAgIGZpZ3VyZSA0OnNlbmQgTlIgdG8gcmVhY3Rpb24gd2hlbiBwZWVyIGlzIGhpZ2hl ciBwcmlvcml0eSB3aWxsIG1ha2UgdHJhZmZpYyBicm9rZW4gYWNjaWRlbnRhbGx5DQogICAgICAg ICAgICANCiAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKyAg ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAg ICB8IExFUjEgfCAgICAgICAgICAgICAgICAgICAgICAgICB8IExFUjIgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICArLS0tKy0tKyAgICAgICAgICAgICAgICAgICAgICAgICArLS0tKy0tKw0K ICAgICAgICAgICAgICAgICAgICAgICAgIE4gICAgKy0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0t LS0tLS0+fCAgTg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfDwtLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgIGxvY2FsIE1TIGNv bW1hbmQgaW5wdXQgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgUEE6TTpMICAgKy0tLS0tLS0tLS0tTVMtLS0tLS0tLS0tLS0t LS0tLS0+fCAgUEE6TTpSDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8PC0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBsb2Nh bCBGUyBjb21tYW5kIGlucHV0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgIFBBOkY6 UiB8PC0tLS0tLS0tLUZTLS0tLS0tLS0tLS0tLS0tLS0tLS0rIFBBOkY6TA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS1NUy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0+fA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBsb2NhbCBjbGVhciBpbnB1 dCxyZWV2YWx1YXRlIGFsbCBpbnB1dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwt LS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tKyB0cmFuc2ZlciBpbmZvIFBBOk06UiBrZWVw IHRyYWZmaWMgb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgIHByb3RlY3Rpb24gcGF0aC4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHJlZXZh bHVhdGUgYWxsIGlucHV0IGFuZCAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgIHRyYW5zZmVyIGluZm8gIFBBOk06TCAgICAgICstLS0tLS0tLS0tTVMtLS0tLS0tLS0tLS0t LS0tLS0tPnxQQTpNX1INCiBrZWVwIHRyYWZmaWMgb24gcHJvdGVjdGlvbiAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICBwYXRoICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCg0KDQogICAgICAgICAgICBmaWd1cmUgNTphbHdheXMgc2VuZCBsb2NhbCBo aWdoZXN0IHByaW9yaXR5IGNvbmRpdGlvbiB0byBwZWVyLHdpbGwgbmV2ZXIgYnJva2VuIHRyYWZm aWMgYWNjaWRlbnRhbGx5DQogICAgICAgICAgICA= --_098b419e-29dc-4fb2-ab60-b6a210ab219e_-- From hejia@huawei.com Thu Jan 17 23:24:51 2013 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 2A87821F8AB8 for ; Thu, 17 Jan 2013 23:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, CN_BODY_35=0.339, 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 uCqoMM3B24m2 for ; Thu, 17 Jan 2013 23:24:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4075A21F8A61 for ; Thu, 17 Jan 2013 23:24:49 -0800 (PST) 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 AOW79427; Fri, 18 Jan 2013 07:24:47 +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; Fri, 18 Jan 2013 07:24:29 +0000 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Jan 2013 07:24:46 +0000 Received: from SZXEML505-MBX.china.huawei.com ([169.254.1.20]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Fri, 18 Jan 2013 15:24:39 +0800 From: "Hejia (Jia)" To: "adrian@olddog.co.uk" , "'Eric Osborne (eosborne)'" , "'Ross Callon'" Thread-Topic: [mpls] Proposed response to Ring Protection Liaison Thread-Index: Ac3wLIvW2MilEmiNRY61kTc4hga6xgAhIQOAAJWs/gAAPEd/gABULlXg Date: Fri, 18 Jan 2013 07:24:38 +0000 Message-ID: <735916399E11684EAF4EB4FB376B71952BF6D76E@SZXEML505-MBX.china.huawei.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD309A3976C@CH1PRD0510MB355.namprd05.prod.outlook.com> <007401cdf0f4$1f5011c0$5df03540$@olddog.co.uk> <20ECF67871905846A80F77F8F4A27572100A173F@xmb-rcd-x09.cisco.com> <021f01cdf43b$f4bfa2e0$de3ee8a0$@olddog.co.uk> In-Reply-To: <021f01cdf43b$f4bfa2e0$de3ee8a0$@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.66.76.169] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Proposed response to Ring Protection Liaison 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, 18 Jan 2013 07:24:51 -0000 SGkgYWxsLA0KDQpJIGNvbmN1ciB3aXRoIG1vc3Qgb2YgQWRyaWFuJ3MgY29tbWVudHMgYW5kIGFw cHJlY2lhdGUgdGhlIGNoYW5nZXMgbWFkZSBieSBFcmljLCBhbmQgc3VwcG9ydCBzZW5kaW5nIHRo ZSByZXNwb25zZSB0byBJVFUtVC4gQnV0IEkgc3RpbGwgaGF2ZSBvbmUgbW9yZSBjb21tZW50IG9u IHRoZSBwYXJhZ3JhcGggYWJvdXQgVDEgaW4gdGhlIGRyYWZ0IExTLCBxdW90ZWQgYmVsb3c6DQoN ClQxIHByZXNlbnRzIGEgc2NlbmFyaW8gd2hlcmUgbGluZWFyIHByb3RlY3Rpb24gd291bGQgbm90 IHN1ZmZpY2UgaW4gdGhlIGZhY2Ugb2YgbXVsdGlwbGUgZmFpbHVyZXMuIFRoZSBnaXZlbiBzY2Vu YXJpbyBpcyBvbmx5IG9uZSBwb3NzaWJsZSBkZXBsb3ltZW50IG1vZGVsLiBUaGVyZSBhcmUgb3Ro ZXJzIHdoZXJlIGxpbmVhciBwcm90ZWN0aW9uIHdvdWxkIHN1ZmZpY2UuIE9uZSBzdWNoIG1vZGVs IGlzIHRoZSB3cmFwcGluZyBwcm90ZWN0aW9uIGFzIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1tcGxz LXRwLXJpbmctcHJvdGVjdGlvbiwgYW5kIGFub3RoZXIgaXMgdHJlYXRpbmcgdGhlIGFnZ3JlZ2F0 aW9uIGFuZCBhY2Nlc3MgbmV0d29ya3MgYXMgc2VwYXJhdGUgcHJvdGVjdGlvbiBkb21haW5zLg0K DQoNCkl0IGlzIGEgYml0IGNvbmZ1c2luZy4gRG9lcyBpdCBtZWFuIHRoZSBleGFtcGxlcyBvZiB3 cmFwcGluZyBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uIGFuZCAic2VwYXJh dGUgcHJvdGVjdGlvbiBkb21haW5zIiBkbyBub3Qgc2F0aXNmeSB0aGUgZ2l2ZW4gc2NlbmFyaW8g ZGVzY3JpYmVkIGJ5IHRoZSBJVFUtVCBMUz8gSWYgdGhlIGRlc2NyaWJlZCBzY2VuYXJpbyBpbiBJ VFUtVCBMUyBhbHNvIGJlbG9uZ3MgdG8gbXVsdGlwbGUgZmFpbHVyZSBzaXR1YXRpb24sIEl0IGlz IG5vdCBzbyBjb252aW5jaW5nIHRvIHNheSAiIFRoZSBnaXZlbiBzY2VuYXJpbyBpcyBvbmx5IG9u ZSBwb3NzaWJsZSBkZXBsb3ltZW50IG1vZGVsLiBUaGVyZSBhcmUgb3RoZXJzIHdoZXJlIGxpbmVh ciBwcm90ZWN0aW9uIHdvdWxkIHN1ZmZpY2UiLiBQZXJoYXBzIGl0IGlzIGJldHRlciB0byBjbGFy aWZ5IHRoZSBzY29wZSBvZiAibXVsdGlwbGUgZmFpbHVyZXMiLg0KDQpBbSBJIG1pc3NpbmcgYW55 dGhpbmc/DQoNCg0KQi5SLg0KSmlhDQoNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzog bXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHt IEFkcmlhbiBGYXJyZWwNCreiy83KsbzkOiAyMDEzxOox1MIxN8jVIDY6NTENCsrVvP7IyzogJ0Vy aWMgT3Nib3JuZSAoZW9zYm9ybmUpJzsgJ1Jvc3MgQ2FsbG9uJw0Ks63LzTogbXBsc0BpZXRmLm9y Zw0K1vfM4jogUmU6IFttcGxzXSBQcm9wb3NlZCByZXNwb25zZSB0byBSaW5nIFByb3RlY3Rpb24g TGlhaXNvbg0KDQpUaGFua3MgRXJpYyAocHJveHlpbmcgZm9yIFJvc3MgOi0pDQoNCkdvb2QgcHJv Z3Jlc3MuDQoNCltzbmlwXQ0KDQo+ID4gSXQncyBzb21laG93IGFwcHJvcHJpYXRlIHRvIHdyaXRl IGEgbGlhaXNvbiB0byB0aGUgSVRVLVQgaW4gTWljcm9zb2Z0IFdvcmQNCjotKQ0KPiANCj4gRU8j ICBUaGUgTFMgY2FtZSBpbiBhcyBQREYsIGJ1dCBXb3JkJ3MgbXVjaCBlYXNpZXIgdG8gZWRpdC4g IFdoZW4gaXQncyBkb25lIHdlDQo+IHNob3VsZCBwcm9iYWJseSBzZW5kIGl0IGFzIFBERi4NCg0K Tm90IHZlcnkgdXNlZCB0byBzZWVpbmcgcHJvcHJpZXRhcnkgZm9ybWF0IGRvY3VtZW50cyBvbiB0 aGUgSUVURiBtYWlsaW5nIGxpc3RzLg0KDQo+ID4gSSBhc3N1bWUgdGhlIGNoYWlycyB3aWxsIHRv cCBhbmQgdGFpbCB0aGlzIGxpYWlzb24gd2l0aCB0aGUgdXN1YWwgcG9saXRlDQpuaWNldGllcy4g SW4NCj4gPiBwYXJ0aWN1bGFyLCB3ZSBzaG91bGQgd2VsY29tZSB0aGUgd2F5IHRoYXQgU0cxNSBp cyBlbmdhZ2luZyB3aXRoIHRoZSBNUExTDQo+ID4gd29ya2luZyBncm91cCBvbiByaW5nIHByb3Rl Y3Rpb24gcmVxdWlyZW1lbnRzLg0KPiANCj4gRU8jICBJJ20gbm90IGEgY2hhaXIgYW5kIGFtIGdv b2QgYXQgbmVpdGhlciBwb2xpdGUgbm9yIG5pY2UsIHNvIEkndmUgbGVmdA0KdGhlc2UgYml0cw0K PiBvdXQgb2YgbXkgZWRpdHMuDQoNCkZhaXIgZW5vdWdoLiBBbmQgSSBhbSBzdGlsbCBzdXJlIHRo ZSBjaGFpcnMgd2lsbCB0b3AgYW5kIHRhaWwuDQoNCltzbmlwXQ0KDQo+ID4gVGhpcyBkcmFmdCBk b2VzIG5vdCBzZWVtIHRvIGFuc3dlciB0aGUgZmlyc3Qgbm90ZWQgcmVxdWlyZW1lbnRzIGluIHRo ZQ0KPiA+IGluY29taW5nIGxpYWlzb24gdml6Lg0KPiA+IHwgUmVxdWlyZW1lbnRzIGZvciBJVFUt VCBHLjgxMzINCj4gPiB8IFJlcXVpcmVtZW50cyBhbmQgb3B0aW1pemF0aW9uIGNyaXRlcmlhIGZv ciByaW5nIHByb3RlY3Rpb24gc3BlY2lmaWVkDQo+ID4gfCBpbiBSRkM1NjU0ICJNUExTLVRQIHJl cXVpcmVtZW50cyIgaGF2ZSB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQuDQo+ID4NCj4gPiBJIHRo aW5rIHRoaXMgZGVzZXJ2ZXMgdGhlIHJlc3BvbnNlOg0KPiA+IFdlIGFncmVlIHRoYXQgdGhlIHJl cXVpcmVtZW50cyBhbmQgb3B0aW1pemF0aW9uIGNyaXRlcmlhIGZvciByaW5nIHByb3RlY3Rpb24N Cj4gPiBzZXQgb3V0IGluIFJGQyA1NjU0IHNob3VsZCBiZSB0YWtlbiBpbnRvIGFjY291bnQuIElu IHBhcnRpY3VsYXIsIHdlIGRyYXcNCnlvdXINCj4gPiBhdHRlbnRpb24gdG8gdGhlIHByZWFtYmxl IGluIFNlY3Rpb24gMi41LjYuMSBhbmQgdGhlIHN0YXRlbWVudHMgbWFkZSBhYm91dA0KPiA+IHRo ZSBjb3N0L2JlbmVmaXQgaW1wbGljYXRpb25zIG9mIHNwZWNpYWxpc2VkIHByb3RlY3Rpb24gc29s dXRpb25zLg0KPiANCj4gRU8jICBJIGNvdWxkIGdvIGVpdGhlciB3YXkgb24gdGhpcywgYnV0IEkn dmUgYWRkZWQgeW91ciB0ZXh0Lg0KDQpZb3UgYWRkZWQgYW4gYWRkaXRpb25hbCBzZW50ZW5jZS4N Cg0KSSBkb24ndCByZWFsbHkgb2JqZWN0LCBidXQgaXQgcHV6emxlcyBtZSB0aGF0IHlvdSByZWZl ciB0byBHLjgxMzIgd2hlbiBpdCBpcw0KZW5vdWdoIHRvIGFkZHJlc3MgdGhlIHRleHQgaW4gdGhl IGxpYWlzb24uDQoNCltzbmlwXQ0KDQo+ID4gSSBhbSBub3QgYSBodWdlIGZhbiBvZiBob2xkaW5n IHRlY2huaWNhbCBkZWJhdGUgdmlhIGxpYWlzb24gc3RhdGVtZW50LiBUaGF0DQpzYWlkDQo+ID4g eW91ciBvYnNlcnZhdGlvbnMgb24gVDEgYW5kIFQyIGFyZSBjb3JyZWN0Lg0KPiANCj4gRU8jICBX aGF0IGlzIHRoZSBjb3JyZWN0IHZlaGljbGUgZm9yIHRlY2huaWNhbCBkZWJhdGU/ICBEaXNjdXNz aW9uIG9uIHRoZSBJRVRGDQpsaXN0Pw0KPiBEaXNjdXNzaW9uIGZpcnN0IGZvbGxvd2VkIGJ5IGEg TFMgdG8gZm9ybWFsaXplIHRoZSBkaXNjdXNzaW9uIHBvaW50cz8gIEkndmUNCmFkZGVkDQo+IHNv bWUgdGV4dCB0byB0aGlzIGVmZmVjdCBhcyBhIHN0YXJ0IC0gIkZvciB0aGUgdGVjaG5pY2FsIGFu YWx5c2lzLCB3ZSBpbnZpdGUNCnRoZQ0KPiBkaXNjdXNzaW9uIG9mIHRoZXNlIHNjZW5hcmlvcyBv biB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0LCBhcyB0aGF0IG1heSBoZWxwIHRvDQo+IHByb2dyZXNz IGEgdGVjaG5pY2FsIHNvbHV0aW9uIG1vcmUgZWZmZWN0aXZlbHkgdGhhbiBsaWFpc29uIHN0YXRl bWVudHMuIg0KDQpNeSBwZXJzb25hbCBvcGluaW9uIGlzIHRoYXQgd2UgYXJlIHRoZSBJRVRGIGFu ZCB0aGUgY29ycmVjdCB2ZWhpY2xlIGZvcg0KdGVjaG5pY2FsIGRlYmF0ZXMgaXMgdGhlIGFwcHJv cHJpYXRlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0LCBwb3NzaWJseQ0Kc3VwcG9ydGVkIGJ5 IGFuIElFVEYgZHJhZnQuDQoNCkkgd291bGQgc3RyaWtlIHRoZSBzZWNvbmQgaGFsZiBvZiB0aGUg c2VudGVuY2UuIEVmZmVjdGl2ZW5lc3MgbWF5IG9yIG1heSBub3QgYmUNCnJlbGV2YW50LiBSZWdh cmRsZXNzIG9mIHRoYXQsIHdlIGludml0ZSBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3Qu DQoNCj4gPiBMYXRlciBpbiB0aGUgZGlzY3Vzc2lvbiBvZiBUMiB5b3Ugc2F5Og0KPiA+DQo+ID4g PiBUaGUgSUVURiBiZWxpZXZlcyB0aGF0IHRoZSByZXVzZSBvZiBsaW5lYXIgcHJvdGVjdGlvbiBt ZWNoYW5pc21zIGluIGENCj4gPiA+IHJpbmcgdG9wb2xvZ3kgKGkuZS4gZHJhZnQtaWV0Zi1tcGxz LXRwLXJpbmctcHJvdGVjdGlvbikgd2lsbCBtZWV0DQo+ID4gPiBwZXJmb3JtYW5jZSB0YXJnZXRz IGluIGEgcmluZyB0b3BvbG9neSwgYW5kIHdpbGwgZG8gc28gd2hpbGUgYWxsb3dpbmcNCj4gPiA+ IHRoZSBvcGVyYXRvciB0byBkZXBsb3kgYSBzaW5nbGUgcHJvdGVjdGlvbiBtZXRob2QgYWNyb3Nz IGFsbCBwb3NzaWJsZQ0KPiA+ID4gbmV0d29yayB0b3BvbG9naWVzLg0KPiA+DQo+ID4gSSBkbyBu b3QgYmVsaWV2ZSBpdCBpcyB5b3VyIGludGVudGlvbiB0byB0ZXN0IElFVEYgY29uc2Vuc3VzIG9u IHRoaXMgYmVmb3JlDQo+ID4gc2VuZGluZyAgdGhlIGxpYWlzb24uIFlvdSBtaWdodCBzL0lFVEYv TVBMUyB3b3JraW5nIGdyb3VwLyBhbmQgdXNlIHRoZQ0KPiA+IHJldmlldyBvZiB0aGlzIGxpYWlz b24gc3RhdGVtZW50IGFzIHRoZSB3YXkgdG8gdGVzdCB0aGF0IGNvbnNlbnN1cy4NCj4gDQo+IEVP IyAgcy9JRVRGL01QTFMgV0cvIGRvbmUuICBJJ20gZ29pbmcgdG8gc3RheSBhd2F5IGZyb20gdGhl IGNvbnNlbnN1cyBwb2ludA0KPiBvbiB0aGlzIHRocmVhZCwgYXMgdGhhdCdzIGEgd2hvbGUgc2Vw YXJhdGUgdGhpbmcsIGJ1dCBJIGRvIG5vdGUgdGhhdCB0aGUgcmluZw0KPiBwcm90ZWN0aW9uIGRv YyBpcyBhIFdHIGRyYWZ0IGFuZCB0aHVzIGhhcyBhdCBsZWFzdCBzb21lIGxldmVsIG9mIGVudGh1 c2lhc20NCj4gYmVoaW5kIGl0Lg0KDQpUaGUgY2hhaXJzIHdpbGwgbmVlZCB0byBiZWxpZXZlIHRo ZXJlIGlzIFdHIGNvbnNlbnN1cyBvbiB0aGlzIHBvaW50IGlmIHRoZXkNCmludGVuZCB0byBzZW5k IGEgbGlhaXNvbiBzdGF0ZW1lbnQgdGhhdCBzYXlzIHRoZSBXRyBiZWxpZXZlcyBzb21ldGhpbmcu IFRoZQ0KY2hhaXJzIG1pZ2h0IGNvbnNpZGVyIHRoYXQgcHV0dGluZyB0aGlzIGRyYWZ0IGxpYWlz b24gc3RhdGVtZW50IG91dCBmb3IgV0cNCnJldmlldyBnaXZlcyBlbm91Z2ggZXZpZGVuY2Ugb24g d2hpY2ggdG8gYnVpbGQgdGhhdCBiZWxpZWYuDQoNCltzbmlwXQ0KDQo+ID4gVGhlIHBhcmFncmFw aCBvbiB0aGUgc29waGlzdGljYXRpb24gb2YgcmluZy1iYXNlZCBuZXR3b3JrcyBpcyB1bmRvdWJ0 ZWRseQ0KPiA+IHRydWUuIEV2ZW4gaW4gdHJhZGl0aW9uYWwgdHJhbnNwb3J0IG5ldHdvcmtzLCBy aW5nIGludGVyY29ubmVjdHMgaGF2ZSBtYWRlDQplbmQtDQo+ID4gdG8tZW5kIHBhdGhzIGFwcGVh ciB0byB0cmF2ZXJzZSBhIG1lc2guIFRoZSBlYXNlIHdpdGggd2hpY2ggcGFja2V0IG5ldHdvcmtz DQo+ID4gY2FuIGJyaWRnZSBiZXR3ZWVuIHJpbmdzIG1ha2VzIHRoZSBtZXNoaW5lc3MgYWxsIHRo ZSBtb3JlIGxpa2VseS4NCj4gPg0KPiA+IE5vdHdpdGhzdGFuZGluZyB0aGF0LCB0aGVyZSBpcyAo b3IgaXQgY291bGQgYmUgYXJndWVkIHRoYXQgdGhlcmUgaXMpIHZhbHVlDQppbg0KPiA+IGltcG9z aW5nIGxvZ2ljYWwgcHJvdGVjdGlvbiBkb21haW5zIGluIG1lc2ggbmV0d29ya3MuIEJ5IHRyZWF0 aW5nIGEgcG9ydGlvbg0Kb2YNCj4gPiB0aGUgbWVzaCBuZXR3b3JrIGFzIGEgbG9naWNhbCByaW5n LCBjZXJ0YWluIHNwZWNpZmljIHJpbmcgcHJvdGVjdGlvbg0KPiA+IGNoYXJhY3RlcmlzdGljcyAo c3VjaCBhcyB0aG9zZSBkaXNjdXNzZWQgaW4NCmRyYWZ0LWlldGYtbXBscy10cC1yaW5nLXByb3Rl Y3Rpb24pDQo+ID4gY2FuIGJlIGxldmVyYWdlZC4NCj4gPg0KPiA+IFNvLCBJIGFtIHdvbmRlcmlu ZyB3aGF0IHRoaXMgcGFyYWdyYXBoIGlzIGF0dGVtcHRpbmcgdG8gYWRkIHRvIHRoZSBsaWFpc29u Lg0KPiANCj4gRU8jICBUaGlzIHBvaW50LCBJIHRoaW5rLCBpcyBpbXBvcnRhbnQuDQo+IA0KPiBJ dCB3YXMgYW4gYXR0ZW1wdCB0byBzYXkgImlmIHdlJ3JlIGdvaW5nIHRvIGRpc2N1c3MgcmluZy1z cGVjaWZpYyBtZWNoYW5pc21zDQp3ZQ0KPiBzaG91bGQgYWdyZWUgd2hlbiBzb21ldGhpbmcgaXMg YW5kIGlzIG5vdCBhIHJpbmciLiAgJ1JpbmcnIGhhcyB2ZXJ5IHBhcnRpY3VsYXINCj4gc2lnbmlm aWNhbmNlIGluIHRoZSB0cmFuc3BvcnQgd29ybGQsIGFuZCB0aGUgdGV4dCB3YXMgYW4gYXR0ZW1w dCB0byBkcmF3IG91dA0KdGhhdA0KPiBkZWZpbml0aW9uLiAgU29tZSBtZW1iZXJzIG9mIHRoZSBX RyAob2suLi5wcm9iYWJseSBqdXN0IG1lKSBkbyBub3QgdW5kZXJzdGFuZA0KPiB0aGUgZGlzdGlu Y3Rpb24gYmV0d2VlbiBhIHN1ZmZpY2llbnRseSBzb3BoaXN0aWNhdGVkIHJpbmcgYW5kIGEgbWVz aC4gIEknZA0KaGF0ZSB0bw0KPiBjb21lIHVwIHdpdGggYW4gYWdyZWVtZW50IG9uIHdoYXQgcmlu Zy1zcGVjaWZpYyBwcm90ZWN0aW9uIGxvb2tzIGxpa2Ugb25seSB0bw0KPiBmaW5kIG91dCBwb3N0 IGhvYyB0aGF0IG9uZSBzaWRlIG1lYW50ICJhIHNldCBvZiBubyBtb3JlIHRoYW4gMTYgbm9kZXMN CltBLS0tQi0tLUMtDQo+IC0tLi4uLS0tUC0tQV0gd2hpY2ggY29uc3RpdHV0ZSB0aGUgZW50aXJl dHkgb2YgYSBnaXZlbiByaW5nLXNwZWNpZmljDQpwcm90ZWN0aW9uDQo+IGRvbWFpbiIgYW5kIHRo ZSBvdGhlciBtZWFudCAiYW4gYXJiaXRyYXJ5IG1lc2ggdGhhdCBoYXMgYmVlbiBzdWJkaXZpZGVk IGludG8NCj4gbGl0dGxlIGNpcmNsZXMgYnV0IHdpdGggZW5kLXRvLWVuZCBwcm90ZWN0aW9uIGFj cm9zcyB0aGUgcmluZ21lc2giIG9yDQpzb21ldGhpbmcNCj4gbGlrZSB0aGF0LiAgSW4gbXkgb3Bp bmlvbiB1bmRlcnN0YW5kaW5nIHRoZSBkZWZpbml0aW9uIGlzIGtleSB0byBzY29waW5nIHRoZQ0K PiByZXF1aXJlbWVudHMgcHJvcGVybHkuDQoNClllcywgYnV0IHdoYXQgaXMgdGhlIHBhcmFncmFw aCBhY3R1YWxseSBzYXlpbmcgdG8gdGhlIElUVS1UPw0KDQpXb3VsZCBpdCBwZXJoYXBzIGJlIGJl dHRlciB0byBhc2sgdGhlIElUVS1UIGZvciBhIGNsZWFyIGRlZmluaXRpb24gb2Ygd2hhdCB0aGV5 DQptZWFuIGJ5IGEgcmluZyBuZXR3b3JrIGNvbnNpZGVyaW5nIHRoYXQgcmluZ3MgbWF5IGJlIG11 bHRpcGx5IGludGVyY29ubmVjdGVkIGFuZA0Kb3ZlcmxhcHBpbmc/IFtOb3RlIHRoYXQgY2hhbmdl cyB0aGlzIGludG8gYSBsaWFpc29uIEZvciBBY3Rpb24uXQ0KDQpbc25pcF0NCiANCj4gPiBBbmQg dGhlbiwgcy9UaGUgSUVURiByZWNvbW1lbmRzL1RoZSBNUExTIHdvcmtpbmcgZ3JvdXAgcmVjb21t ZW5kcy8NCj4gPiAoYXNzdW1pbmcgeW91IGhhdmUgY29uc2Vuc3VzIGZvciB0aGF0KQ0KDQpTYW1l IHBvaW50IGZvciB0aGUgY2hhaXJzIHRvIG5vdGUgd3J0IGNvbnNlbnN1cyBmb3IgdGhpcy4NCg0K VGhhbmtzIGZvciB0aGUgd29yay4NCg0KQWRyaWFuIChhbiBpbmRpdmlkdWFsIGFnYWluKQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWls aW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0K From loa@pi.nu Fri Jan 18 00:10:40 2013 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 4F32621F88DA for ; Fri, 18 Jan 2013 00:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 Fw45ouN6z3hm for ; Fri, 18 Jan 2013 00:10:39 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE0F21F88CA for ; Fri, 18 Jan 2013 00:10:39 -0800 (PST) Received: from [192.168.1.104] (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 1E5FB823B5; Fri, 18 Jan 2013 09:10:34 +0100 (CET) Message-ID: <50F9037B.80900@pi.nu> Date: Fri, 18 Jan 2013 09:10:35 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" References: <50E5E64A.8090105@pi.nu> In-Reply-To: <50E5E64A.8090105@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg 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, 18 Jan 2013 08:10:40 -0000 Working Group, This poll has ended and we have a new working group document. Can the authors please re-publish the draft as draf-ietf-mpls-tp-p2mp-framework-00.txt without any changes but the file name, version number and date. /Loa On 2013-01-03 21:12, Loa Andersson wrote: > Working group, > > This is to start a two week poll on adopting > draft-fbb-mpls-tp-p2mp-framework-06 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 January 17, 2013. > > There are no IPR claim against this document. > > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. > > /Loa > (mpls wg co-chair) > -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From ietfc@btconnect.com Fri Jan 18 01:15:31 2013 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 9870621F87CB for ; Fri, 18 Jan 2013 01:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 BLx3lUNP+nWp for ; Fri, 18 Jan 2013 01:15:29 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 73DB021F87BA for ; Fri, 18 Jan 2013 01:15:28 -0800 (PST) Received: from mail181-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.23; Fri, 18 Jan 2013 09:15:27 +0000 Received: from mail181-tx2 (localhost [127.0.0.1]) by mail181-tx2-R.bigfish.com (Postfix) with ESMTP id 93ECF1A0637 for ; Fri, 18 Jan 2013 09:15:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: PS-18(zz9371I936eI542I1432I1418Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h1724k304l1155h) Received: from mail181-tx2 (localhost.localdomain [127.0.0.1]) by mail181-tx2 (MessageSwitch) id 1358500526137925_18425; Fri, 18 Jan 2013 09:15:26 +0000 (UTC) Received: from TX2EHSMHS010.bigfish.com (unknown [10.9.14.238]) by mail181-tx2.bigfish.com (Postfix) with ESMTP id 14AE442007E for ; Fri, 18 Jan 2013 09:15:26 +0000 (UTC) Received: from AMSPRD0710HT002.eurprd07.prod.outlook.com (157.56.249.85) by TX2EHSMHS010.bigfish.com (10.9.99.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 18 Jan 2013 09:15:23 +0000 Received: from DBXPRD0210HT001.eurprd02.prod.outlook.com (157.56.253.181) by pod51017.outlook.com (10.255.160.165) with Microsoft SMTP Server (TLS) id 14.16.257.4; Fri, 18 Jan 2013 09:16:06 +0000 Message-ID: <000901cdf55b$f96b4bc0$4001a8c0@gateway.2wire.net> From: t.petch CC: References: <20130110142618.9183.29944.idtracker@ietfa.amsl.com> Date: Fri, 18 Jan 2013 09:12:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.181] X-OriginatorOrg: btconnect.com Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-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: Fri, 18 Jan 2013 09:15:31 -0000 I think that this still needs more work (well, I thought so in September 2011 and do even more so now:-). a) RFC6427 and RFC6428 seem to have been lost from the references. b) BFD is attributed with the ability to track liveliness whereas BFD itself only claims to monitor liveness. c) IANA and Security Considerations would be better highlighted as sections in their own right rather than as subsections. This has changed recently but not for the better. d) IANA Considerations fails to say which registries are being updated. More fundamentally, can the idea ever work? If protocol X needs configuring in order to use it, can it be configured by protocol X? We do not, for example, configure IP with options in IP; rather, we use BOOTP or DHCP. I think that this issue needs much more consideration than it gets. When is the configuration sent vis-a-vis other PDU? can it be changed at any time? what happens to operations in progress when it changes? what does it mean to configure these operations, some of which at least seem atomic and stateless for which configuration seems a little odd? Tom Petch ----- Original Message ----- From: To: Cc: Sent: Thursday, January 10, 2013 2:26 PM Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-05.txt > > 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 : Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping > Author(s) : Elisa Bellagamba > Loa Andersson > Pontus Skoldstrom > Dave Ward > John Drake > Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-05.txt > Pages : 22 > Date : 2013-01-10 > > Abstract: > This specification describes the configuration of pro-active MPLS-TP > Operations, Administration, and Maintenance (OAM) Functions for a > given LSP using a set of TLVs that are carried by the LSP-Ping > protocol. > > 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-lsp-ping-mpls-tp-oam-co nf > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-mpls-tp-oam-co nf-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From loa@pi.nu Fri Jan 18 02:17:57 2013 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 4D11E21F8443 for ; Fri, 18 Jan 2013 02:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 5bXVpiIxPr5Y for ; Fri, 18 Jan 2013 02:17:56 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 70CFD21F8442 for ; Fri, 18 Jan 2013 02:17:56 -0800 (PST) Received: from [192.168.1.104] (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 AE37D7FE07; Fri, 18 Jan 2013 11:17:53 +0100 (CET) Message-ID: <50F92152.2090101@pi.nu> Date: Fri, 18 Jan 2013 11:17:54 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" References: <50D17A08.8050109@pi.nu> In-Reply-To: <50D17A08.8050109@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "" Subject: [mpls] Closed - Working Group Last Call on draft-ietf-mpls-ldp-dod 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, 18 Jan 2013 10:17:57 -0000 Working Group, This working group last call is closed. We have had comments that need to be addressed! The authors should review the comments, propose how to address the comments on the list, close loops with the people making the comments to make sure they are comfortable with the comment resolution and when all outstanding comments are addressed republish a new version of the document. /Loa for the wg chairs On 2012-12-19 09:25, Loa Andersson wrote: > > Working Group, > > This is to start a working group last call on > draft-ietf-mpls-ldp-dod-03. This working last call is extended > due to the upcoming holidays. > > 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. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not ware of any IPRs. > > This working group last call will end on January 15, 2013. > > /Loa > for the wg co-chairs > -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From adrian@olddog.co.uk Fri Jan 18 03:10:17 2013 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 5BF9221F8903 for ; Fri, 18 Jan 2013 03:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.036, 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 NualFKWa05vf for ; Fri, 18 Jan 2013 03:10:15 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id D688E21F8900 for ; Fri, 18 Jan 2013 03:10:13 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0IBA0kZ023269; Fri, 18 Jan 2013 11:10:00 GMT Received: from 950129200 (089144192047.atnat0001.highway.a1.net [89.144.192.47]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0IB9aCF022690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Jan 2013 11:09:39 GMT From: "Adrian Farrel" To: "'VIGOUREUX, MARTIN \(MARTIN\)'" , "'David Ball'" References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> <50F7F553.1070509@alcatel-lucent.com> <20130117170933.GN25804@cisco.com> <50F83247.7050000@alcatel-lucent.com>, <20130117174102.GP25804@cisco.com> In-Reply-To: Date: Fri, 18 Jan 2013 11:09:35 -0000 Message-ID: <003a01cdf56c$51c599f0$f550cdd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01CDF56C.51CCC5E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKJyV6+bHSBwG2j2NRvssT27Ly7TQImhphdAWk8zUABjKwFUQFgEbkeAmuTCLkC3usnuwIsWgcQlmeqanA= Content-Language: en-gb Cc: mpls@ietf.org, dai.xuehui@zte.com.cn, "'Sami Boutros \(sboutros\)'" , "'Siva Sivabalan \(msiva\)'" , rcallon@juniper.net, raggarwa_1@yahoo.com Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 18 Jan 2013 11:10:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003B_01CDF56C.51CCC5E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, when we are done, can some write me an email that contains the text = that would have been in the Errata Report if we had known then what we know = now? =20 Then I will process the existing report and the new text. =20 Thanks, Adrian =20 From: VIGOUREUX, MARTIN (MARTIN) = [mailto:martin.vigoureux@alcatel-lucent.com]=20 Sent: 17 January 2013 20:00 To: David Ball Cc: adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan = (msiva)'; raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart Bryant = (stbryant)'; loa@pi.nu; 'George Swallow (swallow)'; rcallon@juniper.net; = mpls@ietf.org Subject: RE: [Editorial Errata Reported] RFC6435 (3429) =20 David, Yes it does. Thanks. I first thought of removing all references to MEP/MIP but should have = given it a second thought. -m _____ =20 De : David Ball Envoy=E9 : 17/01/2013 18:41 =C0 : VIGOUREUX, MARTIN (MARTIN) Cc : adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan = (msiva)'; raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart Bryant = (stbryant)'; loa@pi.nu; 'George Swallow (swallow)'; rcallon@juniper.net; = mpls@ietf.org Objet : Re: [Editorial Errata Reported] RFC6435 (3429) Hi Martin, Actually I think the last paragraph is talking about something different = again: this is the MEPs that must be locked. Here is a transport path: |>-------x----------x-------<| --------->| <---------v A B C D A and D are the MEPs; B is the source of the test, C is the loopback=20 point. As we have discussed, C could be a MIP, could be the MEP at D, or could=20 be at a point that is neither a MIP or a MEP. A and D are the MEPs that must be locked during the test. My question was about point B: I think in the original text point B must = always be the same as the MEP at point A; your proposal allows it to be=20 some other point, eg at a MIP or at a point where there is no MIP or=20 MEP. If we keep the original text about point B, and just change the text=20 about point C, then combining with your proposal we get the following=20 change: Old text: The loopback function is used to test the integrity of a transport path from a MEP up any other node in the same MEG. This is achieved by setting the target node into loopback mode, and transmitting a pattern of test data from the MEP. The target node loops all received data back toward the originator, and the MEP extracts the test data and compares it with what it sent. Loopback is a function that enables a receiving MEP or MIP to return traffic to the sending MEP when in the loopback state. [...] The management plane must ensure that the two MEPs are locked before it requests setting MEP or MIP in the loopback state. New text: The loopback function is used to test the integrity of a transport path from a MEP to any other node along the same transport path. =20 This is achieved by setting the target node into loopback mode for=20 that transport path, and transmitting a pattern of test data from the MEP. The target node loops all data received on the transport=20 path back towards the sending MEP, which extracts the test data=20 and compares it with what it sent. Loopback is a function that enables a given node of a transport=20 path to return traffic to the sending MEP for that transport path=20 when in the loopback mode. [...] The management plane must ensure that the MEPs at either end of a=20 transport path are locked before it requests setting a given node of=20 that transport path into loopback mode. Does this work? David On Thu, Jan 17, 2013, Martin Vigoureux wrote: > David, >=20 > agreed, and in fact this is consistent with the fact I kept MEP in > the last paragraph I changed. >=20 > -m >=20 >=20 > Le 17/01/2013 18:09, David Ball a ?crit : > >Thanks Martin. > > > >Regarding the first paragraph, I agree with your change to add "for = that > >transport path", that does make it clearer. > > > >Regarding the other paragraphs: We have agreed that the intent was = that > >the point doing the loopback does not have to be a MEP or MIP, but = your > >proposal also seems to change it so that the point transmitting the > >test data does not have to be a MEP. I think the original text was > >consistent that the test was done *from* a MEP; the question was = whether > >it was done from a MEP *to another MEP/MIP*, or from a MEP *to an > >arbitrary point*. > > > >So you might be right that the text describing the source of the test > >should also be changed, but I think that is a slightly separate = issue. > >It is probably safest to keep the changes to a minimum and just fix = the > >description of the point that is doing the loopback, ie the target of > >the test. > > > >Do you agree? > > > > > > David > > > > > >On Thu, Jan 17, 2013, Martin Vigoureux wrote: > >>Adrian, yes, we are. > >> > >>So, David, > >> > >>I am fine with your suggested text which says: > >> It should be noted that the data-plane loopback function for a > >> given transport path can be applied to data-plane loopback = points > >> residing on interfaces where there may be no corresponding MEP = or > >> MIP. > >> > >>I was thinking of: > >>s/may be no corresponding MEP or MIP./may be no MEP or MIP for that > >>transport path./ > >>but this is optional. > >> > >>The new text will replace: > >> It should be noted that the data-plane loopback function itself = is > >> applied to data-plane loopback points residing on different > >> interfaces from MIPs/MEPs. > >> > >> > >>Regarding the other paragraphs: > >> The loopback function is used to test the integrity of a = transport > >> path from a MEP up any other node in the same MEG. This is = achieved > >> by setting the target node into loopback mode, and transmitting = a > >> pattern of test data from the MEP. The target node loops all > >> received data back toward the originator, and the MEP extracts = the > >> test data and compares it with what it sent. > >> > >> Loopback is a function that enables a receiving MEP or MIP to = return > >> traffic to the sending MEP when in the loopback state. > >> > >> [...] > >> > >> The management plane must ensure that the two MEPs are locked = before > >> it requests setting MEP or MIP in the loopback state. > >> > >> > >>They could be changed into: > >> The loopback function is used to test the integrity of a = transport > >> path. This is achieved by setting a given node into loopback = mode > >> for a given transport path, and sending over it a pattern of = test > >> data. The node in loopback mode loops all test data received on = the > >> transport path back towards the sender, which extracts the test > >> data and compares it with what it sent. > >> > >> Loopback is a function which enables a given node of a transport > >> path, when in the loopback mode, to return traffic to the sender = of > >> that traffic. > >> > >> [...] > >> > >> The management plane must ensure that the MEPs of a transport = path > >> are locked before it requests setting a given node of that = transport > >> path in loopback mode. > >> > >>Let me know. > >>-m > >> > >>Le 16/01/2013 22:07, Adrian Farrel a ?crit : > >>>All, are we getting any closer to agreeing what we all intended to = say? > >>> > >>>Once we have that, I can work out what to do with the Errata = Report. > >>> > >>>Thanks, > >>>Adrian > >>> > >>>>-----Original Message----- > >>>>From: David Ball [mailto:daviball@cisco.com] > >>>>Sent: 10 January 2013 17:57 > >>>>To: VIGOUREUX, MARTIN (MARTIN) > >>>>Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan = (msiva); > >>>>raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant = (stbryant); > >>>>loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; = mpls@ietf.org > >>>>Subject: Re: [Editorial Errata Reported] RFC6435 (3429) > >>>> > >>>>Hi Martin, > >>>> > >>>>Ah, right I see: since the loopback is locally configured, there = is no > >>>>need for a MEP/MIP to send/receive OAM frames - but there may be a > >>>>MEP/MIP. > >>>> > >>>>So would this work to clarify the text? > >>>> "It should be noted that the data-plane loopback function for a > >>>> given transport path can be applied to data-plane loopback = points > >>>> residing on interfaces where there may be no corresponding MEP = or > >>>> MIP." > >>>> > >>>>For completeness, the references to "MEP or MIP" in paragraphs 3 = and 7 > >>>>of section 4 would also need to be changed, to instead refer to = the > >>>>transport path that is being put in to loopback. > >>>> > >>>>As another data point, I found this text in RFC6371 section 6.3.2: > >>>> "It should be noted that data-plane loopback function itself is > >>>> applied to data-plane loopback points that can reside on = different > >>>> interfaces from MIPs/MEPs." > >>>>Note the critical difference compared to RFC6435: "that can = reside" > >>>>instead of "residing". > >>>> > >>>>Thanks > >>>> > >>>> > >>>> David > >>>> > >>>> > >>>>On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: > >>>>>Sami, > >>>>> > >>>>>Thanks. Yet, I am not sure David's interpretation and mine = exactly match. > >>>>>David, correct me if I am wrong. For me it says that we can do > >>>>>loopback on different interfaces (for different LSPs) but implies = that > >>>>>there is a mip/mep for that lsp on that interface, while my > >>>>>interpretation is that the presence of a mip/mep for that lsp on = that > >>>>>interface is not needed. > >>>>> > >>>>>-m > >>>>>________________________________ > >>>>>De : Sami Boutros (sboutros) > >>>>>Envoy? : 09/01/2013 19:00 > >>>>>? : VIGOUREUX, MARTIN (MARTIN) > >>>>>Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at = Cisco); > >>>Siva > >>>>Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; = Stewart > >>>>Bryant (stbryant); loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; > >>>>mpls@ietf.org > >>>>>Objet : Re: [Editorial Errata Reported] RFC6435 (3429) > >>>>> > >>>>>I agree with Martin, the text proposed by David describe more = accurately > >>>what > >>>>we meant. > >>>>> > >>>>>Thanks, > >>>>> > >>>>>Sami > >>>>>On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > >>>>> > >>>>>>Adrian, David, > >>>>>> > >>>>>>what I think we meant here was that a loop-back function could = be done on > >>>>an interface regardless of the presence of a MIP/MEP on that = interface. Yet, I > >>>>have to admit that MIP and MEP are used in Section 4 of RFC6435, = thus surely > >>>>causing confusion. > >>>>>> > >>>>>>I'd welcome the views/souvenirs of my co-authors. > >>>>>> > >>>>>>-m > >>>>>> > >>>>>>Le 12/12/2012 19:17, Adrian Farrel a ?crit : > >>>>>>>Hello, > >>>>>>> > >>>>>>>Authors of RFC 6435: I need to hear from you that you meant the = text that > >>>>David > >>>>>>>suggests. It is very clearly not what you wrote and, if you = meant > >>>something > >>>>>>>different, it is clear why people are confused! > >>>>>>> > >>>>>>>Working group: I need to hear from you that you agree with = David's > >>>>>>>interpretation and support his proposed change. > >>>>>>> > >>>>>>>Only then will I try to work out whether this is a "typo" = worthy of an > >>>errata > >>>>>>>report, or a technical change needing a revised RFC. > >>>>>>> > >>>>>>>Thanks, > >>>>>>>Adrian > >>>>>>> > >>>>>>>>-----Original Message----- > >>>>>>>>From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>>>>>>>Sent: 12 December 2012 17:45 > >>>>>>>>To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > >>>>>>>>martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > >>>>>>>>stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; > >>>>swallow@cisco.com; > >>>>>>>>rcallon@juniper.net > >>>>>>>>Cc: daviball@cisco.com; mpls@ietf.org; = rfc-editor@rfc-editor.org > >>>>>>>>Subject: [Editorial Errata Reported] RFC6435 (3429) > >>>>>>>> > >>>>>>>> > >>>>>>>>The following errata report has been submitted for RFC6435, > >>>>>>>>"MPLS Transport Profile Lock Instruct and Loopback Functions". > >>>>>>>> > >>>>>>>>-------------------------------------- > >>>>>>>>You may review the report below and at: > >>>>>>>>http://www.rfc-editor.org/errata_search.php?rfc=3D6435 = &eid=3D3429 > >>>>>>>> > >>>>>>>>-------------------------------------- > >>>>>>>>Type: Editorial > >>>>>>>>Reported by: David Ball > >>>>>>>> > >>>>>>>>Section: 4 (para 5) > >>>>>>>> > >>>>>>>>Original Text > >>>>>>>>------------- > >>>>>>>>It should be noted that the data-plane loopback function = itself is > >>>applied to > >>>>>>>data- > >>>>>>>>plane loopback points residing on different interfaces from = MIPs/MEPs. > >>>>>>>> > >>>>>>>>Corrected Text > >>>>>>>>-------------- > >>>>>>>>It should be noted that the data-plane loopback function may = be applied > >>>at > >>>>>>>>MIPs/MEPs on different interfaces for different LSPs. > >>>>>>>> > >>>>>>>>Notes > >>>>>>>>----- > >>>>>>>>The existing text has caused confusion (specifically, among = experts in > >>>ITU-T > >>>>>>>SG15 > >>>>>>>>when discussing G.8121.2), in that it seems to suggest that = the > >>>interface > >>>>>>>where > >>>>>>>>the MIP/MEP is located may be a different interface to the one = where the > >>>>>>>>loopback is applied. > >>>>>>>> > >>>>>>>>Having spoken with some of the original authors, it seems this = was not > >>>the > >>>>>>>intent > >>>>>>>>of this sentence; the intent was to point out that as = different LSPs > >>>would > >>>>>>>have > >>>>>>>>MIPs/MEPs on different interfaces, the corresponding loopback functions > >>>>would > >>>>>>>>also be applied on different interfaces. > >>>>>>>> > >>>>>>>>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. > >>>>>>>> > >>>>>>>>-------------------------------------- > >>>>>>>>RFC6435 (draft-ietf-mpls-tp-li-lb-08) > >>>>>>>>-------------------------------------- > >>>>>>>>Title : MPLS Transport Profile Lock Instruct and Loopback > >>>>>>>Functions > >>>>>>>>Publication Date : November 2011 > >>>>>>>>Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. = Aggarwal, > >>>Ed., M. > >>>>>>>Vigoureux, > >>>>>>>>Ed., X. Dai, Ed. > >>>>>>>>Category : PROPOSED STANDARD > >>>>>>>>Source : Multiprotocol Label Switching > >>>>>>>>Area : Routing > >>>>>>>>Stream : IETF > >>>>>>>>Verifying Party : IESG > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>>>-- > >>>>David Ball > >>>> > >>> > >>> > >>> > > --=20 David Ball ------=_NextPart_000_003B_01CDF56C.51CCC5E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

OK, when we are done, can some = write me an email that contains the text that would have been in the = Errata Report if we had known then what we know = now?

 

Then I will process the = existing report and the new text.

 

Thanks,

Adrian

 

From: VIGOUREUX, MARTIN = (MARTIN) [mailto:martin.vigoureux@alcatel-lucent.com]
Sent: = 17 January 2013 20:00
To: David Ball
Cc: = adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan = (msiva)'; raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart Bryant = (stbryant)'; loa@pi.nu; 'George Swallow (swallow)'; rcallon@juniper.net; = mpls@ietf.org
Subject: RE: [Editorial Errata Reported] RFC6435 = (3429)

 

David,

Yes it does. Thanks.
I = first thought of removing all references to MEP/MIP but should have = given it a second = thought.

-m

De : David Ball
Envoy=E9 : 17/01/2013 18:41
=C0 : VIGOUREUX, MARTIN (MARTIN)
Cc : adrian@olddog.co.uk; 'Sami Boutros = (sboutros)'; 'Siva Sivabalan (msiva)'; raggarwa_1@yahoo.com; = dai.xuehui@zte.com.cn; 'Stewart Bryant (stbryant)'; loa@pi.nu; 'George = Swallow (swallow)'; rcallon@juniper.net; mpls@ietf.org
Objet : Re: [Editorial Errata Reported] RFC6435 = (3429)

Hi = Martin,

Actually I think the last paragraph is talking about = something different
again: this is the MEPs that must be = locked.

Here is a transport path:

  = |>-------x----------x-------<|
     &nb= sp;      = --------->|
         &= nbsp;  <---------v
  = A        = B          = C        D

A and D are the = MEPs; B is the source of the test, C is the loopback =
point.

As we have discussed, C could be a MIP, could be the = MEP at D, or could
be at a point that is neither a MIP or a = MEP.

A and D are the MEPs that must be locked during the = test.

My question was about point B: I think in the original text = point B must
always be the same as the MEP at point A; your proposal = allows it to be
some other point, eg at a MIP or at a point where = there is no MIP or
MEP.

If we keep the original text about = point B, and just change the text
about point C, then combining with = your proposal we get the following
change:

Old = text:
   The loopback function is used to test the = integrity of a transport
   path from a MEP up any other = node in the same MEG.  This is achieved
   by setting = the target node into loopback mode, and transmitting a
   = pattern of test data from the MEP.  The target node loops = all
   received data back toward the originator, and the = MEP extracts the
   test data and compares it with what it = sent.

   Loopback is a function that enables a = receiving MEP or MIP to return
   traffic to the sending = MEP when in the loopback state.

   = [...]

   The management plane must ensure that the two = MEPs are locked before
   it requests setting MEP or MIP in = the loopback state.

New text:
   The loopback = function is used to test the integrity of a transport
   = path from a MEP to any other node along the same transport path.  =
   This is achieved by setting the target node into = loopback mode for
   that transport path, and  = transmitting a pattern of test data from
   the MEP.  = The target node loops all data received on the transport =
   path back towards the sending MEP, which extracts the = test data
   and compares it with what it = sent.

   Loopback is a function that enables a given = node of a transport
   path to return traffic to the = sending MEP for that transport path
   when in the = loopback mode.

   [...]

   The = management plane must ensure that the MEPs at either end of a =
   transport path are locked before it requests setting a = given node of
   that transport path into loopback = mode.

Does this = work?


        = David


On Thu, Jan 17, 2013, Martin Vigoureux wrote:
> = David,
>
> agreed, and in fact this is consistent with the = fact I kept MEP in
> the last paragraph I changed.
> =
> -m
>
>
> Le 17/01/2013 18:09, David Ball a = ?crit :
> >Thanks Martin.
> >
> >Regarding = the first paragraph, I agree with your change to add "for = that
> >transport path", that does make it = clearer.
> >
> >Regarding the other paragraphs: We = have agreed that the intent was that
> >the point doing the = loopback does not have to be a MEP or MIP, but your
> >proposal = also seems to change it so that the point transmitting the
> = >test data does not have to be a MEP.  I think the original text = was
> >consistent that the test was done *from* a MEP; the = question was whether
> >it was done from a MEP *to another = MEP/MIP*, or from a MEP *to an
> >arbitrary point*.
> = >
> >So you might be right that the text describing the = source of the test
> >should also be changed, but I think that = is a slightly separate issue.
> >It is probably safest to keep = the changes to a minimum and just fix the
> >description of the = point that is doing the loopback, ie the target of
> >the = test.
> >
> >Do you agree?
> >
> = >
> >     David
> >
> = >
> >On Thu, Jan 17, 2013, Martin Vigoureux wrote:
> = >>Adrian, yes, we are.
> >>
> >>So, = David,
> >>
> >>I am fine with your suggested = text which says:
> >>    It should be noted = that the data-plane loopback function for a
> = >>    given transport path can be applied to = data-plane loopback points
> >>    residing = on interfaces where there may be no corresponding MEP or
> = >>    MIP.
> >>
> >>I was = thinking of:
> >>s/may be no corresponding MEP or MIP./may = be no MEP or MIP for that
> >>transport path./
> = >>but this is optional.
> >>
> >>The new = text will replace:
> >>    It should be noted = that the data-plane loopback function itself is
> = >>    applied to data-plane loopback points = residing on different
> >>    interfaces from = MIPs/MEPs.
> >>
> >>
> >>Regarding = the other paragraphs:
> >>    The loopback = function is used to test the integrity of a transport
> = >>    path from a MEP up any other node in the same = MEG.  This is achieved
> >>    by = setting the target node into loopback mode, and transmitting a
> = >>    pattern of test data from the MEP.  The = target node loops all
> >>    received data = back toward the originator, and the MEP extracts the
> = >>    test data and compares it with what it = sent.
> >>
> >>    Loopback is a = function that enables a receiving MEP or MIP to return
> = >>    traffic to the sending MEP when in the = loopback state.
> >>
> >>    = [...]
> >>
> >>    The management = plane must ensure that the two MEPs are locked before
> = >>    it requests setting MEP or MIP in the = loopback state.
> >>
> >>
> >>They = could be changed into:
> >>    The loopback = function is used to test the integrity of a transport
> = >>    path.  This is achieved by setting a = given node into loopback mode
> >>    for a = given transport path, and sending over it a pattern of test
> = >>    data.  The node in loopback mode loops = all test data received on the
> >>    = transport path back towards the sender, which extracts the test
> = >>    data and compares it with what it = sent.
> >>
> >>    Loopback is a = function which enables a given node of a transport
> = >>    path, when in the loopback mode, to return = traffic to the sender of
> >>    that = traffic.
> >>
> >>    = [...]
> >>
> >>    The management = plane must ensure that the MEPs of a transport path
> = >>    are locked before it requests setting a given = node of that transport
> >>    path in = loopback mode.
> >>
> >>Let me know.
> = >>-m
> >>
> >>Le 16/01/2013 22:07, Adrian = Farrel a ?crit :
> >>>All, are we getting any closer to = agreeing what we all intended to say?
> >>>
> = >>>Once we have that, I can work out what to do with the Errata = Report.
> >>>
> >>>Thanks,
> = >>>Adrian
> >>>
> = >>>>-----Original Message-----
> >>>>From: = David Ball [mailto:daviball@cisco.com]
>= >>>>Sent: 10 January 2013 17:57
> >>>>To: = VIGOUREUX, MARTIN (MARTIN)
> >>>>Cc: Sami Boutros = (sboutros); adrian@olddog.co.uk; Siva Sivabalan (msiva);
> = >>>>raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart = Bryant (stbryant);
> >>>>loa@pi.nu; George Swallow = (swallow); rcallon@juniper.net; mpls@ietf.org
> = >>>>Subject: Re: [Editorial Errata Reported] RFC6435 = (3429)
> >>>>
> >>>>Hi = Martin,
> >>>>
> >>>>Ah, right I = see: since the loopback is locally configured, there is no
> = >>>>need for a MEP/MIP to send/receive OAM frames - but = there may be a
> >>>>MEP/MIP.
> = >>>>
> >>>>So would this work to clarify = the text?
> >>>>   "It should be noted = that the data-plane loopback function for a
> = >>>>    given transport path can be applied = to data-plane loopback points
> >>>>    = residing on interfaces where there may be no corresponding MEP = or
> >>>>    MIP."
> = >>>>
> >>>>For completeness, the = references to "MEP or MIP" in paragraphs 3 and 7
> = >>>>of section 4 would also need to be changed, to instead = refer to the
> >>>>transport path that is being put in = to loopback.
> >>>>
> >>>>As another = data point, I found this text in RFC6371 section 6.3.2:
> = >>>>   "It should be noted that data-plane = loopback function itself is
> >>>>    = applied to data-plane loopback points that can reside on = different
> >>>>    interfaces from = MIPs/MEPs."
> >>>>Note the critical difference = compared to RFC6435: "that can reside"
> = >>>>instead of "residing".
> = >>>>
> >>>>Thanks
> = >>>>
> >>>>
> >>>>  = David
> >>>>
> >>>>
> = >>>>On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) = wrote:
> >>>>>Sami,
> = >>>>>
> >>>>>Thanks. Yet, I am not = sure David's interpretation and mine exactly match.
> = >>>>>David, correct me if I am wrong. For me it says that = we can do
> >>>>>loopback on different interfaces = (for different LSPs) but implies that
> >>>>>there = is a mip/mep for that lsp on that interface, while my
> = >>>>>interpretation is that the presence of a mip/mep for = that lsp on that
> >>>>>interface is not = needed.
> >>>>>
> = >>>>>-m
> = >>>>>________________________________
> = >>>>>De : Sami Boutros (sboutros)
> = >>>>>Envoy? : 09/01/2013 19:00
> = >>>>>? : VIGOUREUX, MARTIN (MARTIN)
> = >>>>>Cc : adrian@olddog.co.uk; David Ball -X (daviball - = Ensoft Ltd at Cisco);
> >>>Siva
> = >>>>Sivabalan (msiva); raggarwa_1@yahoo.com; = dai.xuehui@zte.com.cn; Stewart
> >>>>Bryant = (stbryant); loa@pi.nu; George Swallow (swallow); = rcallon@juniper.net;
> >>>>mpls@ietf.org
> = >>>>>Objet : Re: [Editorial Errata Reported] RFC6435 = (3429)
> >>>>>
> >>>>>I agree = with Martin, the text proposed by David describe more accurately
> = >>>what
> >>>>we meant.
> = >>>>>
> >>>>>Thanks,
> = >>>>>
> >>>>>Sami
> = >>>>>On Jan 9, 2013, at 6:18 AM, Martin Vigoureux = wrote:
> >>>>>
> = >>>>>>Adrian, David,
> = >>>>>>
> >>>>>>what I think we = meant here was that a loop-back function could be done on
> = >>>>an interface regardless of the presence of a MIP/MEP on = that interface. Yet, I
> >>>>have to admit that MIP = and MEP are used in Section 4 of RFC6435, thus surely
> = >>>>causing confusion.
> = >>>>>>
> >>>>>>I'd welcome the = views/souvenirs of my co-authors.
> = >>>>>>
> >>>>>>-m
> = >>>>>>
> >>>>>>Le 12/12/2012 = 19:17, Adrian Farrel a ?crit :
> = >>>>>>>Hello,
> = >>>>>>>
> >>>>>>>Authors = of RFC 6435: I need to hear from you that you meant the text = that
> >>>>David
> = >>>>>>>suggests. It is very clearly not what you = wrote and, if you meant
> >>>something
> = >>>>>>>different, it is clear why people are = confused!
> >>>>>>>
> = >>>>>>>Working group: I need to hear from you that = you agree with David's
> = >>>>>>>interpretation and support his proposed = change.
> >>>>>>>
> = >>>>>>>Only then will I try to work out whether = this is a "typo" worthy of an
> = >>>errata
> >>>>>>>report, or a = technical change needing a revised RFC.
> = >>>>>>>
> = >>>>>>>Thanks,
> = >>>>>>>Adrian
> = >>>>>>>
> = >>>>>>>>-----Original Message-----
> = >>>>>>>>From: RFC Errata System [mailto:rfc-editor@rfc-editor.or= g]
> >>>>>>>>Sent: 12 December 2012 = 17:45
> >>>>>>>>To: sboutros@cisco.com; = msiva@cisco.com; raggarwa_1@yahoo.com;
> = >>>>>>>>martin.vigoureux@alcatel-lucent.com; = dai.xuehui@zte.com.cn;
> = >>>>>>>>stbryant@cisco.com; adrian@olddog.co.uk; = loa@pi.nu;
> >>>>swallow@cisco.com;
> = >>>>>>>>rcallon@juniper.net
> = >>>>>>>>Cc: daviball@cisco.com; mpls@ietf.org; = rfc-editor@rfc-editor.org
> = >>>>>>>>Subject: [Editorial Errata Reported] = RFC6435 (3429)
> >>>>>>>>
> = >>>>>>>>
> = >>>>>>>>The following errata report has been = submitted for RFC6435,
> = >>>>>>>>"MPLS Transport Profile Lock = Instruct and Loopback Functions".
> = >>>>>>>>
> = >>>>>>>>--------------------------------------> >>>>>>>>You may review the report below = and at:
> >>>>>>>>http://www.rfc-editor.org/errata_search.php?rfc=3D6435&eid=3D34= 29
> >>>>>>>>
> = >>>>>>>>--------------------------------------> >>>>>>>>Type: Editorial
> = >>>>>>>>Reported by: David = Ball<daviball@cisco.com>
> = >>>>>>>>
> = >>>>>>>>Section: 4 (para 5)
> = >>>>>>>>
> = >>>>>>>>Original Text
> = >>>>>>>>-------------
> = >>>>>>>>It should be noted that the data-plane = loopback function itself is
> >>>applied to
> = >>>>>>>data-
> = >>>>>>>>plane loopback points residing on = different interfaces from MIPs/MEPs.
> = >>>>>>>>
> = >>>>>>>>Corrected Text
> = >>>>>>>>--------------
> = >>>>>>>>It should be noted that the data-plane = loopback function may be applied
> >>>at
> = >>>>>>>>MIPs/MEPs on different interfaces for = different LSPs.
> >>>>>>>>
> = >>>>>>>>Notes
> = >>>>>>>>-----
> = >>>>>>>>The existing text has caused confusion = (specifically, among experts in
> >>>ITU-T
> = >>>>>>>SG15
> = >>>>>>>>when discussing G.8121.2), in that it = seems to suggest that the
> >>>interface
> = >>>>>>>where
> = >>>>>>>>the MIP/MEP is located may be a = different interface to the one where the
> = >>>>>>>>loopback is applied.
> = >>>>>>>>
> = >>>>>>>>Having spoken with some of the original = authors, it seems this was not
> >>>the
> = >>>>>>>intent
> = >>>>>>>>of this sentence; the intent was to = point out that as different LSPs
> >>>would
> = >>>>>>>have
> = >>>>>>>>MIPs/MEPs on different interfaces, the = corresponding loopback functions
> >>>>would
> = >>>>>>>>also be applied on different = interfaces.
> >>>>>>>>
> = >>>>>>>>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.
> = >>>>>>>>
> = >>>>>>>>--------------------------------------> >>>>>>>>RFC6435 = (draft-ietf-mpls-tp-li-lb-08)
> = >>>>>>>>--------------------------------------> = >>>>>>>>Title      =          : MPLS Transport = Profile Lock Instruct and Loopback
> = >>>>>>>Functions
> = >>>>>>>>Publication Date    : = November 2011
> = >>>>>>>>Author(s)     &n= bsp;     : S. Boutros, Ed., S. Sivabalan, Ed., R. = Aggarwal,
> >>>Ed., M.
> = >>>>>>>Vigoureux,
> = >>>>>>>>Ed., X. Dai, Ed.
> = >>>>>>>>Category     &nb= sp;      : PROPOSED STANDARD
> = >>>>>>>>Source      = ;        : Multiprotocol Label = Switching
> = >>>>>>>>Area      &= nbsp;         : Routing
> = >>>>>>>>Stream      = ;        : IETF
> = >>>>>>>>Verifying Party     = : IESG
> >>>>>>>
> = >>>>>>>
> >>>>>
> = >>>>
> >>>>--
> = >>>>David Ball
> = >>>><daviball@cisco.com>
> >>>
> = >>>
> >>>
> >

--
David = Ball
<daviball@cisco.com>

------=_NextPart_000_003B_01CDF56C.51CCC5E0-- From daviball@cisco.com Fri Jan 18 04:42:36 2013 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 594DE21F88A8 for ; Fri, 18 Jan 2013 04:42:36 -0800 (PST) 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 v-b98+IkT0o8 for ; Fri, 18 Jan 2013 04:42:34 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0625621F889A for ; Fri, 18 Jan 2013 04:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21415; q=dns/txt; s=iport; t=1358512952; x=1359722552; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=yRppe+qj+rbYkbxlfx+T85MsrfWL4EkZZo/Zrfg13m8=; b=C7Wc5U+BfMh11hrQxZuaplMiZmX+xIlSi8UlFqvJZrb4ogdatE0AZyzk ciVpuQdt0qGTr11hH9seI01uNUtpZrYcLPilE92jprrHA59b8IghZBBmX tOmaTTQgqDYtSBuGjkpKSw79BhlLcvlmv87qLT1f9+fMueBg2jMEMPs// M=; X-IronPort-AV: E=Sophos;i="4.84,492,1355097600"; d="scan'208";a="79835025" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 18 Jan 2013 12:42:29 +0000 Received: from ensoft-linux3.cisco.com (ensoft-linux3.cisco.com [10.63.23.12]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0ICgS4Q014516 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2013 12:42:28 GMT Received: from daviball by ensoft-linux3.cisco.com with local (Exim 4.76) (envelope-from ) id 1TwBHA-0003k8-26; Fri, 18 Jan 2013 12:42:28 +0000 Date: Fri, 18 Jan 2013 12:42:28 +0000 From: David Ball To: Adrian Farrel Message-ID: <20130118124227.GV25804@cisco.com> References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> <50F7F553.1070509@alcatel-lucent.com> <20130117170933.GN25804@cisco.com> <50F83247.7050000@alcatel-lucent.com> <20130117174102.GP25804@cisco.com> <003a01cdf56c$51c599f0$f550cdd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003a01cdf56c$51c599f0$f550cdd0$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mpls@ietf.org, dai.xuehui@zte.com.cn, "'Siva Sivabalan \(msiva\)'" , "'Sami Boutros \(sboutros\)'" , rcallon@juniper.net, raggarwa_1@yahoo.com Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 18 Jan 2013 12:42:36 -0000 Hi Adrian, I think we are done, here is the updated text: ==== Section 4, paragraphs 2-7; old text: The loopback function is used to test the integrity of a transport path from a MEP up any other node in the same MEG. This is achieved by setting the target node into loopback mode, and transmitting a pattern of test data from the MEP. The target node loops all received data back toward the originator, and the MEP extracts the test data and compares it with what it sent. Loopback is a function that enables a receiving MEP or MIP to return traffic to the sending MEP when in the loopback state. This state corresponds to the situation where, at a given node, a forwarding plane loop is configured, and the incoming direction of a transport path is cross-connected to the outgoing reverse direction. Therefore, except in the case of early TTL expiry, traffic sent by the source will be received by that source. Data-plane loopback is an out-of-service function, as required in Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic (including user data and OAM). The traffic can be originated from one internal point at the ingress of a transport path within an interface or inserted from an input port of an interface using external test equipment. The traffic is looped back unmodified (other than normal per-hop processing such as TTL decrement) in the direction of the point of origin by an interface at either an intermediate node or a terminating node. It should be noted that the data-plane loopback function itself is applied to data-plane loopback points residing on different interfaces from MIPs/MEPs. All traffic (including both payload and OAM) received on the looped back interface is sent on the reverse direction of the transport path. For data-plane loopback at an intermediate point in a transport path, the loopback needs to be configured to occur at either the ingress or egress interface. This is done using management. The management plane can be used to configure the loopback function. The management plane must ensure that the two MEPs are locked before it requests setting MEP or MIP in the loopback state. New text: The loopback function is used to test the integrity of a transport path from a MEP to any other node along the same transport path. This is achieved by setting the target node into loopback mode for that transport path, and transmitting a pattern of test data from the MEP. The target node loops all data received on the transport path back towards the sending MEP, which extracts the test data and compares it with what it sent. Loopback is a function that enables a given node on a transport path to return traffic to the sending MEP for that transport path when in the loopback mode. This mode corresponds to the situation where, at a given node, a forwarding plane loop is configured, and the incoming direction of a transport path is cross-connected to the outgoing reverse direction. Therefore, except in the case of early TTL expiry, traffic sent by the source will be received by that source. Data-plane loopback is an out-of-service function, as required in Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic (including user data and OAM). The traffic can be originated from one internal point at the ingress of a transport path within an interface or inserted from an input port of an interface using external test equipment. The traffic is looped back unmodified (other than normal per-hop processing such as TTL decrement) in the direction of the point of origin by an interface at either an intermediate node or a terminating node. It should be noted that the data-plane loopback function for a given transport path can be applied to data-plane loopback points residing on interfaces where there may be no MEP or MIP for that transport path. For data-plane loopback at an intermediate point in a transport path, the loopback needs to be configured to occur at either the ingress or egress interface. This is done using management. The management plane must ensure that the MEPs at either end of a transport path are locked before it requests setting a given node of that transport path into loopback mode. Notes: The existing text has caused confusion about exactly where the loopback is applied. It does not clearly express the original intent, which was that there may or may not be a MEP or MIP at the loopback point. In particular, paragraphs 2 and 7 imply that the loopback point must be at a MEP or MIP, while paragraph 5 implies that loopback is performed at a point where there is no MEP or MIP. The new text updates paragraphs 2, 3, 5 and 7 to clarify that the loopback may be performed at any point along the transport path, whether or not there is a MEP or MIP there, and that the loopback only applies to the transport path in question. Paragraphs 4 and 6 are unchanged. ==== David On Fri, Jan 18, 2013, Adrian Farrel wrote: > OK, when we are done, can some write me an email that contains the text that > would have been in the Errata Report if we had known then what we know now? > > Then I will process the existing report and the new text. > > Thanks, > Adrian > > From: VIGOUREUX, MARTIN (MARTIN) [mailto:martin.vigoureux@alcatel-lucent.com] > Sent: 17 January 2013 20:00 > To: David Ball > Cc: adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan (msiva)'; > raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart Bryant (stbryant)'; > loa@pi.nu; 'George Swallow (swallow)'; rcallon@juniper.net; mpls@ietf.org > Subject: RE: [Editorial Errata Reported] RFC6435 (3429) > > David, > > Yes it does. Thanks. > I first thought of removing all references to MEP/MIP but should have given it a > second thought. > > -m > _____ > > De : David Ball > Envoy? : 17/01/2013 18:41 > ? : VIGOUREUX, MARTIN (MARTIN) > Cc : adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan (msiva)'; > raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart Bryant (stbryant)'; > loa@pi.nu; 'George Swallow (swallow)'; rcallon@juniper.net; mpls@ietf.org > Objet : Re: [Editorial Errata Reported] RFC6435 (3429) > Hi Martin, > > Actually I think the last paragraph is talking about something different > again: this is the MEPs that must be locked. > > Here is a transport path: > > |>-------x----------x-------<| > --------->| > <---------v > A B C D > > A and D are the MEPs; B is the source of the test, C is the loopback > point. > > As we have discussed, C could be a MIP, could be the MEP at D, or could > be at a point that is neither a MIP or a MEP. > > A and D are the MEPs that must be locked during the test. > > My question was about point B: I think in the original text point B must > always be the same as the MEP at point A; your proposal allows it to be > some other point, eg at a MIP or at a point where there is no MIP or > MEP. > > If we keep the original text about point B, and just change the text > about point C, then combining with your proposal we get the following > change: > > Old text: > The loopback function is used to test the integrity of a transport > path from a MEP up any other node in the same MEG. This is achieved > by setting the target node into loopback mode, and transmitting a > pattern of test data from the MEP. The target node loops all > received data back toward the originator, and the MEP extracts the > test data and compares it with what it sent. > > Loopback is a function that enables a receiving MEP or MIP to return > traffic to the sending MEP when in the loopback state. > > [...] > > The management plane must ensure that the two MEPs are locked before > it requests setting MEP or MIP in the loopback state. > > New text: > The loopback function is used to test the integrity of a transport > path from a MEP to any other node along the same transport path. > This is achieved by setting the target node into loopback mode for > that transport path, and transmitting a pattern of test data from > the MEP. The target node loops all data received on the transport > path back towards the sending MEP, which extracts the test data > and compares it with what it sent. > > Loopback is a function that enables a given node of a transport > path to return traffic to the sending MEP for that transport path > when in the loopback mode. > > [...] > > The management plane must ensure that the MEPs at either end of a > transport path are locked before it requests setting a given node of > that transport path into loopback mode. > > Does this work? > > > David > > > On Thu, Jan 17, 2013, Martin Vigoureux wrote: > > David, > > > > agreed, and in fact this is consistent with the fact I kept MEP in > > the last paragraph I changed. > > > > -m > > > > > > Le 17/01/2013 18:09, David Ball a ?crit : > > >Thanks Martin. > > > > > >Regarding the first paragraph, I agree with your change to add "for that > > >transport path", that does make it clearer. > > > > > >Regarding the other paragraphs: We have agreed that the intent was that > > >the point doing the loopback does not have to be a MEP or MIP, but your > > >proposal also seems to change it so that the point transmitting the > > >test data does not have to be a MEP. I think the original text was > > >consistent that the test was done *from* a MEP; the question was whether > > >it was done from a MEP *to another MEP/MIP*, or from a MEP *to an > > >arbitrary point*. > > > > > >So you might be right that the text describing the source of the test > > >should also be changed, but I think that is a slightly separate issue. > > >It is probably safest to keep the changes to a minimum and just fix the > > >description of the point that is doing the loopback, ie the target of > > >the test. > > > > > >Do you agree? > > > > > > > > > David > > > > > > > > >On Thu, Jan 17, 2013, Martin Vigoureux wrote: > > >>Adrian, yes, we are. > > >> > > >>So, David, > > >> > > >>I am fine with your suggested text which says: > > >> It should be noted that the data-plane loopback function for a > > >> given transport path can be applied to data-plane loopback points > > >> residing on interfaces where there may be no corresponding MEP or > > >> MIP. > > >> > > >>I was thinking of: > > >>s/may be no corresponding MEP or MIP./may be no MEP or MIP for that > > >>transport path./ > > >>but this is optional. > > >> > > >>The new text will replace: > > >> It should be noted that the data-plane loopback function itself is > > >> applied to data-plane loopback points residing on different > > >> interfaces from MIPs/MEPs. > > >> > > >> > > >>Regarding the other paragraphs: > > >> The loopback function is used to test the integrity of a transport > > >> path from a MEP up any other node in the same MEG. This is achieved > > >> by setting the target node into loopback mode, and transmitting a > > >> pattern of test data from the MEP. The target node loops all > > >> received data back toward the originator, and the MEP extracts the > > >> test data and compares it with what it sent. > > >> > > >> Loopback is a function that enables a receiving MEP or MIP to return > > >> traffic to the sending MEP when in the loopback state. > > >> > > >> [...] > > >> > > >> The management plane must ensure that the two MEPs are locked before > > >> it requests setting MEP or MIP in the loopback state. > > >> > > >> > > >>They could be changed into: > > >> The loopback function is used to test the integrity of a transport > > >> path. This is achieved by setting a given node into loopback mode > > >> for a given transport path, and sending over it a pattern of test > > >> data. The node in loopback mode loops all test data received on the > > >> transport path back towards the sender, which extracts the test > > >> data and compares it with what it sent. > > >> > > >> Loopback is a function which enables a given node of a transport > > >> path, when in the loopback mode, to return traffic to the sender of > > >> that traffic. > > >> > > >> [...] > > >> > > >> The management plane must ensure that the MEPs of a transport path > > >> are locked before it requests setting a given node of that transport > > >> path in loopback mode. > > >> > > >>Let me know. > > >>-m > > >> > > >>Le 16/01/2013 22:07, Adrian Farrel a ?crit : > > >>>All, are we getting any closer to agreeing what we all intended to say? > > >>> > > >>>Once we have that, I can work out what to do with the Errata Report. > > >>> > > >>>Thanks, > > >>>Adrian > > >>> > > >>>>-----Original Message----- > > >>>>From: David Ball [mailto:daviball@cisco.com] > > >>>>Sent: 10 January 2013 17:57 > > >>>>To: VIGOUREUX, MARTIN (MARTIN) > > >>>>Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan (msiva); > > >>>>raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbryant); > > >>>>loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf.org > > >>>>Subject: Re: [Editorial Errata Reported] RFC6435 (3429) > > >>>> > > >>>>Hi Martin, > > >>>> > > >>>>Ah, right I see: since the loopback is locally configured, there is no > > >>>>need for a MEP/MIP to send/receive OAM frames - but there may be a > > >>>>MEP/MIP. > > >>>> > > >>>>So would this work to clarify the text? > > >>>> "It should be noted that the data-plane loopback function for a > > >>>> given transport path can be applied to data-plane loopback points > > >>>> residing on interfaces where there may be no corresponding MEP or > > >>>> MIP." > > >>>> > > >>>>For completeness, the references to "MEP or MIP" in paragraphs 3 and 7 > > >>>>of section 4 would also need to be changed, to instead refer to the > > >>>>transport path that is being put in to loopback. > > >>>> > > >>>>As another data point, I found this text in RFC6371 section 6.3.2: > > >>>> "It should be noted that data-plane loopback function itself is > > >>>> applied to data-plane loopback points that can reside on different > > >>>> interfaces from MIPs/MEPs." > > >>>>Note the critical difference compared to RFC6435: "that can reside" > > >>>>instead of "residing". > > >>>> > > >>>>Thanks > > >>>> > > >>>> > > >>>> David > > >>>> > > >>>> > > >>>>On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: > > >>>>>Sami, > > >>>>> > > >>>>>Thanks. Yet, I am not sure David's interpretation and mine exactly match. > > >>>>>David, correct me if I am wrong. For me it says that we can do > > >>>>>loopback on different interfaces (for different LSPs) but implies that > > >>>>>there is a mip/mep for that lsp on that interface, while my > > >>>>>interpretation is that the presence of a mip/mep for that lsp on that > > >>>>>interface is not needed. > > >>>>> > > >>>>>-m > > >>>>>________________________________ > > >>>>>De : Sami Boutros (sboutros) > > >>>>>Envoy? : 09/01/2013 19:00 > > >>>>>? : VIGOUREUX, MARTIN (MARTIN) > > >>>>>Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at Cisco); > > >>>Siva > > >>>>Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart > > >>>>Bryant (stbryant); loa@pi.nu; George Swallow (swallow); > rcallon@juniper.net; > > >>>>mpls@ietf.org > > >>>>>Objet : Re: [Editorial Errata Reported] RFC6435 (3429) > > >>>>> > > >>>>>I agree with Martin, the text proposed by David describe more accurately > > >>>what > > >>>>we meant. > > >>>>> > > >>>>>Thanks, > > >>>>> > > >>>>>Sami > > >>>>>On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > > >>>>> > > >>>>>>Adrian, David, > > >>>>>> > > >>>>>>what I think we meant here was that a loop-back function could be done > on > > >>>>an interface regardless of the presence of a MIP/MEP on that interface. > Yet, I > > >>>>have to admit that MIP and MEP are used in Section 4 of RFC6435, thus > surely > > >>>>causing confusion. > > >>>>>> > > >>>>>>I'd welcome the views/souvenirs of my co-authors. > > >>>>>> > > >>>>>>-m > > >>>>>> > > >>>>>>Le 12/12/2012 19:17, Adrian Farrel a ?crit : > > >>>>>>>Hello, > > >>>>>>> > > >>>>>>>Authors of RFC 6435: I need to hear from you that you meant the text > that > > >>>>David > > >>>>>>>suggests. It is very clearly not what you wrote and, if you meant > > >>>something > > >>>>>>>different, it is clear why people are confused! > > >>>>>>> > > >>>>>>>Working group: I need to hear from you that you agree with David's > > >>>>>>>interpretation and support his proposed change. > > >>>>>>> > > >>>>>>>Only then will I try to work out whether this is a "typo" worthy of an > > >>>errata > > >>>>>>>report, or a technical change needing a revised RFC. > > >>>>>>> > > >>>>>>>Thanks, > > >>>>>>>Adrian > > >>>>>>> > > >>>>>>>>-----Original Message----- > > >>>>>>>>From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > >>>>>>>>Sent: 12 December 2012 17:45 > > >>>>>>>>To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > > >>>>>>>>martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > > >>>>>>>>stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; > > >>>>swallow@cisco.com; > > >>>>>>>>rcallon@juniper.net > > >>>>>>>>Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org > > >>>>>>>>Subject: [Editorial Errata Reported] RFC6435 (3429) > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>The following errata report has been submitted for RFC6435, > > >>>>>>>>"MPLS Transport Profile Lock Instruct and Loopback Functions". > > >>>>>>>> > > >>>>>>>>-------------------------------------- > > >>>>>>>>You may review the report below and at: > > >>>>>>>>http://www.rfc-editor.org/errata_search.php?rfc=6435 > &eid=3429 > > >>>>>>>> > > >>>>>>>>-------------------------------------- > > >>>>>>>>Type: Editorial > > >>>>>>>>Reported by: David Ball > > >>>>>>>> > > >>>>>>>>Section: 4 (para 5) > > >>>>>>>> > > >>>>>>>>Original Text > > >>>>>>>>------------- > > >>>>>>>>It should be noted that the data-plane loopback function itself is > > >>>applied to > > >>>>>>>data- > > >>>>>>>>plane loopback points residing on different interfaces from MIPs/MEPs. > > >>>>>>>> > > >>>>>>>>Corrected Text > > >>>>>>>>-------------- > > >>>>>>>>It should be noted that the data-plane loopback function may be > applied > > >>>at > > >>>>>>>>MIPs/MEPs on different interfaces for different LSPs. > > >>>>>>>> > > >>>>>>>>Notes > > >>>>>>>>----- > > >>>>>>>>The existing text has caused confusion (specifically, among experts in > > >>>ITU-T > > >>>>>>>SG15 > > >>>>>>>>when discussing G.8121.2), in that it seems to suggest that the > > >>>interface > > >>>>>>>where > > >>>>>>>>the MIP/MEP is located may be a different interface to the one where > the > > >>>>>>>>loopback is applied. > > >>>>>>>> > > >>>>>>>>Having spoken with some of the original authors, it seems this was not > > >>>the > > >>>>>>>intent > > >>>>>>>>of this sentence; the intent was to point out that as different LSPs > > >>>would > > >>>>>>>have > > >>>>>>>>MIPs/MEPs on different interfaces, the corresponding loopback > functions > > >>>>would > > >>>>>>>>also be applied on different interfaces. > > >>>>>>>> > > >>>>>>>>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. > > >>>>>>>> > > >>>>>>>>-------------------------------------- > > >>>>>>>>RFC6435 (draft-ietf-mpls-tp-li-lb-08) > > >>>>>>>>-------------------------------------- > > >>>>>>>>Title : MPLS Transport Profile Lock Instruct and > Loopback > > >>>>>>>Functions > > >>>>>>>>Publication Date : November 2011 > > >>>>>>>>Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, > > >>>Ed., M. > > >>>>>>>Vigoureux, > > >>>>>>>>Ed., X. Dai, Ed. > > >>>>>>>>Category : PROPOSED STANDARD > > >>>>>>>>Source : Multiprotocol Label Switching > > >>>>>>>>Area : Routing > > >>>>>>>>Stream : IETF > > >>>>>>>>Verifying Party : IESG > > >>>>>>> > > >>>>>>> > > >>>>> > > >>>> > > >>>>-- > > >>>>David Ball > > >>>> > > >>> > > >>> > > >>> > > > > > -- > David Ball > -- David Ball From ietfc@btconnect.com Fri Jan 18 06:18:17 2013 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 2741721F8903 for ; Fri, 18 Jan 2013 06:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.131 X-Spam-Level: X-Spam-Status: No, score=-4.131 tagged_above=-999 required=5 tests=[AWL=-0.532, 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 BIAG-jol-H1m for ; Fri, 18 Jan 2013 06:18:16 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 24B4821F84DE for ; Fri, 18 Jan 2013 06:18:15 -0800 (PST) Received: from mail82-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 18 Jan 2013 14:18:15 +0000 Received: from mail82-db3 (localhost [127.0.0.1]) by mail82-db3-R.bigfish.com (Postfix) with ESMTP id E5C44420339; Fri, 18 Jan 2013 14:18:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zz9371I936eI542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h304l1155h) Received: from mail82-db3 (localhost.localdomain [127.0.0.1]) by mail82-db3 (MessageSwitch) id 135851869397370_3276; Fri, 18 Jan 2013 14:18:13 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.243]) by mail82-db3.bigfish.com (Postfix) with ESMTP id C0270C0052; Fri, 18 Jan 2013 14:18:11 +0000 (UTC) Received: from AMSPRD0711HT002.eurprd07.prod.outlook.com (157.56.250.181) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 18 Jan 2013 14:18:09 +0000 Received: from DBXPRD0611HT001.eurprd06.prod.outlook.com (157.56.254.85) by pod51017.outlook.com (10.242.14.163) with Microsoft SMTP Server (TLS) id 14.16.257.4; Fri, 18 Jan 2013 14:18:08 +0000 Message-ID: <000d01cdf586$49f18440$4001a8c0@gateway.2wire.net> From: t.petch To: References: <20130115124143.12114.44371.idtracker@ietfa.amsl.com> <50F55175.5080106@gmail.com> Date: Fri, 18 Jan 2013 14:14:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.85] X-OriginatorOrg: btconnect.com Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-08.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: Fri, 18 Jan 2013 14:18:17 -0000 Um; I am still seeing [RFC....]. <> Error! Reference source not found., Error! Reference source not found., and Error! Reference source not found.. ITU-T Recommendation Error! Reference source not found which suggests to me that a little more unscrewing is in order. Tom Petch ----- Original Message ----- From: "Huub van Helvoort" Cc: Sent: Tuesday, January 15, 2013 12:54 PM Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-08.txt > Sorry, > > I had to re-spin. MS messed up the references. > > Regards, Huub. > > > > > > 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 : A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations. > > Author(s) : Huub van Helvoort > > Loa Andersson > > Nurit Sprecher > > Filename : draft-ietf-mpls-tp-rosetta-stone-08.txt > > Pages : 18 > > Date : 2013-01-15 > > > > Abstract: > > MPLS-TP is based on a profile of the MPLS and PW procedures as > > specified in the MPLS-TE and (MS-)PW architectures developed by the > > IETF. The ITU-T has specified a Transport Network architecture. > > > > This document provides a thesaurus for the interpretation of MPLS-TP > > terminology within the context of the ITU-T Transport Network > > recommendations. > > > > It is important to note that MPLS-TP is applicable in a wider set of > > contexts than just Transport Networks. The definitions presented in > > this document do not provide exclusive nor complete interpretations > > of MPLS-TP concepts. This document simply allows the MPLS-TP terms > > to be applied within the Transport Network context. > > From sboutros@cisco.com Fri Jan 18 06:33:17 2013 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 93C9021F8888 for ; Fri, 18 Jan 2013 06:33:17 -0800 (PST) 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 eFAb8ic6F6kJ for ; Fri, 18 Jan 2013 06:33:15 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9326C21F8887 for ; Fri, 18 Jan 2013 06:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22762; q=dns/txt; s=iport; t=1358519595; x=1359729195; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yNFGrc1jCZrxgh/z1aNQskwTK2ByMlpISJ29lf+HzIE=; b=PW7DL5D7+6qHc6ouLdfUy6hWxx1wxf4DP1F+e1TqV5nKCbGXsun8QB7D gDv+ewBbXemrVRpl6+F0hEnYV92IznWFq7C2tfIJB85i/BTtgurluQS2h Mb742+Kq4p1lQZ90k9wzCfWkrBqPvZ5Qg/l2h6pR9nDG2wlEI/mZeTcH3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHVc+VCtJXHA/2dsb2JhbAArEgirTpJqFnOCHgEBAQMBGg0TMQ4FBwQCAQgRBAEBAQoUCQcyEwEJCAIEDgUIh38DCQYMLLttjAltCwyDS2EDlDqNCYUSgnV2cAcCFx4 X-IronPort-AV: E=Sophos;i="4.84,492,1355097600"; d="scan'208";a="164477010" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 18 Jan 2013 14:33:14 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0IEXEZ9024261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jan 2013 14:33:14 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.163]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 18 Jan 2013 08:33:14 -0600 From: "Sami Boutros (sboutros)" To: "David Ball -X (daviball - Ensoft Ltd at Cisco)" Thread-Topic: [Editorial Errata Reported] RFC6435 (3429) Thread-Index: AQHN2JGbr8z20Ev6BkqoT9E++A0mPJgV3TmAgCu+nACAAD2fgP//xZV2gAHMLICACaMWAIABCa+AgABGTwCAAAJagIAABnEAgAAmy4CAAP4rgIAAGfQAgAAe8YA= Date: Fri, 18 Jan 2013 14:33:14 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F113356D91@xmb-rcd-x08.cisco.com> References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> <50F7F553.1070509@alcatel-lucent.com> <20130117170933.GN25804@cisco.com> <50F83247.7050000@alcatel-lucent.com> <20130117174102.GP25804@cisco.com> <003a01cdf56c$51c599f0$f550cdd0$@olddog.co.uk> <20130118124227.GV25804@cisco.com> In-Reply-To: <20130118124227.GV25804@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <9A77A9A35961FE43BE90521467139910@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "Siva Sivabalan \(msiva\)" , "" , "" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 18 Jan 2013 14:33:17 -0000 Looks good to me. I agree that in the new text it is clear that we are not requiring a MIP or= MEP at the node that perform the loopback function along the transport pat= h As well I feel it is clear the way I read it, that=20 1- A MEP is required as a must at both ends of the transport path to perfor= m the transport path lock function prior to setting up the loopback on a no= de along the transport path. 2- The Loopback function MUST be done via management only. If the above is not clear to others while reading the new text, then we may= need to update it. Thanks, Sami On Jan 18, 2013, at 4:42 AM, David Ball wrote: > Hi Adrian, >=20 > I think we are done, here is the updated text: >=20 > =3D=3D=3D=3D >=20 > Section 4, paragraphs 2-7; old text: >=20 > The loopback function is used to test the integrity of a transport > path from a MEP up any other node in the same MEG. This is achieved > by setting the target node into loopback mode, and transmitting a > pattern of test data from the MEP. The target node loops all > received data back toward the originator, and the MEP extracts the > test data and compares it with what it sent. >=20 > Loopback is a function that enables a receiving MEP or MIP to return > traffic to the sending MEP when in the loopback state. This state > corresponds to the situation where, at a given node, a forwarding > plane loop is configured, and the incoming direction of a transport > path is cross-connected to the outgoing reverse direction. > Therefore, except in the case of early TTL expiry, traffic sent by > the source will be received by that source. >=20 > Data-plane loopback is an out-of-service function, as required in > Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic > (including user data and OAM). The traffic can be originated from > one internal point at the ingress of a transport path within an > interface or inserted from an input port of an interface using > external test equipment. The traffic is looped back unmodified > (other than normal per-hop processing such as TTL decrement) in the > direction of the point of origin by an interface at either an > intermediate node or a terminating node. >=20 > It should be noted that the data-plane loopback function itself is > applied to data-plane loopback points residing on different > interfaces from MIPs/MEPs. All traffic (including both payload and > OAM) received on the looped back interface is sent on the reverse > direction of the transport path. >=20 > For data-plane loopback at an intermediate point in a transport path, > the loopback needs to be configured to occur at either the ingress or > egress interface. This is done using management. >=20 > The management plane can be used to configure the loopback function. > The management plane must ensure that the two MEPs are locked before > it requests setting MEP or MIP in the loopback state. >=20 > New text: >=20 > The loopback function is used to test the integrity of a transport > path from a MEP to any other node along the same transport path. =20 > This is achieved by setting the target node into loopback mode for=20 > that transport path, and transmitting a pattern of test data from > the MEP. The target node loops all data received on the transport=20 > path back towards the sending MEP, which extracts the test data=20 > and compares it with what it sent. >=20 > Loopback is a function that enables a given node on a transport=20 > path to return traffic to the sending MEP for that transport path=20 > when in the loopback mode. This mode corresponds to the situation=20 > where, at a given node, a forwarding plane loop is configured, and=20 > the incoming direction of a transport path is cross-connected to the=20 > outgoing reverse direction. Therefore, except in the case of early=20 > TTL expiry, traffic sent by the source will be received by that=20 > source. >=20 > Data-plane loopback is an out-of-service function, as required in > Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic > (including user data and OAM). The traffic can be originated from > one internal point at the ingress of a transport path within an > interface or inserted from an input port of an interface using > external test equipment. The traffic is looped back unmodified > (other than normal per-hop processing such as TTL decrement) in the > direction of the point of origin by an interface at either an > intermediate node or a terminating node. >=20 > It should be noted that the data-plane loopback function for a > given transport path can be applied to data-plane loopback points > residing on interfaces where there may be no MEP or MIP for that=20 > transport path. >=20 > For data-plane loopback at an intermediate point in a transport path, > the loopback needs to be configured to occur at either the ingress or > egress interface. This is done using management. >=20 > The management plane must ensure that the MEPs at either end of a=20 > transport path are locked before it requests setting a given node of=20 > that transport path into loopback mode. >=20 > Notes: >=20 > The existing text has caused confusion about exactly where the=20 > loopback is applied. It does not clearly express the original=20 > intent, which was that there may or may not be a MEP or MIP at the=20 > loopback point. In particular, paragraphs 2 and 7 imply that the=20 > loopback point must be at a MEP or MIP, while paragraph 5 implies=20 > that loopback is performed at a point where there is no MEP or MIP. >=20 > The new text updates paragraphs 2, 3, 5 and 7 to clarify that the=20 > loopback may be performed at any point along the transport path,=20 > whether or not there is a MEP or MIP there, and that the loopback=20 > only applies to the transport path in question. Paragraphs 4 and 6=20 > are unchanged. >=20 > =3D=3D=3D=3D >=20 >=20 > David >=20 >=20 > On Fri, Jan 18, 2013, Adrian Farrel wrote: >> OK, when we are done, can some write me an email that contains the text = that >> would have been in the Errata Report if we had known then what we know n= ow? >>=20 >> Then I will process the existing report and the new text. >>=20 >> Thanks, >> Adrian >>=20 >> From: VIGOUREUX, MARTIN (MARTIN) [mailto:martin.vigoureux@alcatel-lucent= .com]=20 >> Sent: 17 January 2013 20:00 >> To: David Ball >> Cc: adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan (msi= va)'; >> raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart Bryant (stbryant)'= ; >> loa@pi.nu; 'George Swallow (swallow)'; rcallon@juniper.net; mpls@ietf.or= g >> Subject: RE: [Editorial Errata Reported] RFC6435 (3429) >>=20 >> David, >>=20 >> Yes it does. Thanks. >> I first thought of removing all references to MEP/MIP but should have gi= ven it a >> second thought. >>=20 >> -m >> _____ =20 >>=20 >> De : David Ball >> Envoy? : 17/01/2013 18:41 >> ? : VIGOUREUX, MARTIN (MARTIN) >> Cc : adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan (ms= iva)'; >> raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart Bryant (stbryant)'= ; >> loa@pi.nu; 'George Swallow (swallow)'; rcallon@juniper.net; mpls@ietf.or= g >> Objet : Re: [Editorial Errata Reported] RFC6435 (3429) >> Hi Martin, >>=20 >> Actually I think the last paragraph is talking about something different= =20 >> again: this is the MEPs that must be locked. >>=20 >> Here is a transport path: >>=20 >> |>-------x----------x-------<| >> --------->| >> <---------v >> A B C D >>=20 >> A and D are the MEPs; B is the source of the test, C is the loopback=20 >> point. >>=20 >> As we have discussed, C could be a MIP, could be the MEP at D, or could= =20 >> be at a point that is neither a MIP or a MEP. >>=20 >> A and D are the MEPs that must be locked during the test. >>=20 >> My question was about point B: I think in the original text point B must= =20 >> always be the same as the MEP at point A; your proposal allows it to be= =20 >> some other point, eg at a MIP or at a point where there is no MIP or=20 >> MEP. >>=20 >> If we keep the original text about point B, and just change the text=20 >> about point C, then combining with your proposal we get the following=20 >> change: >>=20 >> Old text: >> The loopback function is used to test the integrity of a transport >> path from a MEP up any other node in the same MEG. This is achieved >> by setting the target node into loopback mode, and transmitting a >> pattern of test data from the MEP. The target node loops all >> received data back toward the originator, and the MEP extracts the >> test data and compares it with what it sent. >>=20 >> Loopback is a function that enables a receiving MEP or MIP to return >> traffic to the sending MEP when in the loopback state. >>=20 >> [...] >>=20 >> The management plane must ensure that the two MEPs are locked before >> it requests setting MEP or MIP in the loopback state. >>=20 >> New text: >> The loopback function is used to test the integrity of a transport >> path from a MEP to any other node along the same transport path. =20 >> This is achieved by setting the target node into loopback mode for=20 >> that transport path, and transmitting a pattern of test data from >> the MEP. The target node loops all data received on the transport=20 >> path back towards the sending MEP, which extracts the test data=20 >> and compares it with what it sent. >>=20 >> Loopback is a function that enables a given node of a transport=20 >> path to return traffic to the sending MEP for that transport path=20 >> when in the loopback mode. >>=20 >> [...] >>=20 >> The management plane must ensure that the MEPs at either end of a=20 >> transport path are locked before it requests setting a given node of=20 >> that transport path into loopback mode. >>=20 >> Does this work? >>=20 >>=20 >> David >>=20 >>=20 >> On Thu, Jan 17, 2013, Martin Vigoureux wrote: >>> David, >>>=20 >>> agreed, and in fact this is consistent with the fact I kept MEP in >>> the last paragraph I changed. >>>=20 >>> -m >>>=20 >>>=20 >>> Le 17/01/2013 18:09, David Ball a ?crit : >>>> Thanks Martin. >>>>=20 >>>> Regarding the first paragraph, I agree with your change to add "for th= at >>>> transport path", that does make it clearer. >>>>=20 >>>> Regarding the other paragraphs: We have agreed that the intent was tha= t >>>> the point doing the loopback does not have to be a MEP or MIP, but you= r >>>> proposal also seems to change it so that the point transmitting the >>>> test data does not have to be a MEP. I think the original text was >>>> consistent that the test was done *from* a MEP; the question was wheth= er >>>> it was done from a MEP *to another MEP/MIP*, or from a MEP *to an >>>> arbitrary point*. >>>>=20 >>>> So you might be right that the text describing the source of the test >>>> should also be changed, but I think that is a slightly separate issue. >>>> It is probably safest to keep the changes to a minimum and just fix th= e >>>> description of the point that is doing the loopback, ie the target of >>>> the test. >>>>=20 >>>> Do you agree? >>>>=20 >>>>=20 >>>> David >>>>=20 >>>>=20 >>>> On Thu, Jan 17, 2013, Martin Vigoureux wrote: >>>>> Adrian, yes, we are. >>>>>=20 >>>>> So, David, >>>>>=20 >>>>> I am fine with your suggested text which says: >>>>> It should be noted that the data-plane loopback function for a >>>>> given transport path can be applied to data-plane loopback points >>>>> residing on interfaces where there may be no corresponding MEP or >>>>> MIP. >>>>>=20 >>>>> I was thinking of: >>>>> s/may be no corresponding MEP or MIP./may be no MEP or MIP for that >>>>> transport path./ >>>>> but this is optional. >>>>>=20 >>>>> The new text will replace: >>>>> It should be noted that the data-plane loopback function itself is >>>>> applied to data-plane loopback points residing on different >>>>> interfaces from MIPs/MEPs. >>>>>=20 >>>>>=20 >>>>> Regarding the other paragraphs: >>>>> The loopback function is used to test the integrity of a transport >>>>> path from a MEP up any other node in the same MEG. This is achieve= d >>>>> by setting the target node into loopback mode, and transmitting a >>>>> pattern of test data from the MEP. The target node loops all >>>>> received data back toward the originator, and the MEP extracts the >>>>> test data and compares it with what it sent. >>>>>=20 >>>>> Loopback is a function that enables a receiving MEP or MIP to retur= n >>>>> traffic to the sending MEP when in the loopback state. >>>>>=20 >>>>> [...] >>>>>=20 >>>>> The management plane must ensure that the two MEPs are locked befor= e >>>>> it requests setting MEP or MIP in the loopback state. >>>>>=20 >>>>>=20 >>>>> They could be changed into: >>>>> The loopback function is used to test the integrity of a transport >>>>> path. This is achieved by setting a given node into loopback mode >>>>> for a given transport path, and sending over it a pattern of test >>>>> data. The node in loopback mode loops all test data received on th= e >>>>> transport path back towards the sender, which extracts the test >>>>> data and compares it with what it sent. >>>>>=20 >>>>> Loopback is a function which enables a given node of a transport >>>>> path, when in the loopback mode, to return traffic to the sender of >>>>> that traffic. >>>>>=20 >>>>> [...] >>>>>=20 >>>>> The management plane must ensure that the MEPs of a transport path >>>>> are locked before it requests setting a given node of that transpor= t >>>>> path in loopback mode. >>>>>=20 >>>>> Let me know. >>>>> -m >>>>>=20 >>>>> Le 16/01/2013 22:07, Adrian Farrel a ?crit : >>>>>> All, are we getting any closer to agreeing what we all intended to s= ay? >>>>>>=20 >>>>>> Once we have that, I can work out what to do with the Errata Report. >>>>>>=20 >>>>>> Thanks, >>>>>> Adrian >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: David Ball [mailto:daviball@cisco.com] >>>>>>> Sent: 10 January 2013 17:57 >>>>>>> To: VIGOUREUX, MARTIN (MARTIN) >>>>>>> Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan (m= siva); >>>>>>> raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart Bryant (stbrya= nt); >>>>>>> loa@pi.nu; George Swallow (swallow); rcallon@juniper.net; mpls@ietf= .org >>>>>>> Subject: Re: [Editorial Errata Reported] RFC6435 (3429) >>>>>>>=20 >>>>>>> Hi Martin, >>>>>>>=20 >>>>>>> Ah, right I see: since the loopback is locally configured, there is= no >>>>>>> need for a MEP/MIP to send/receive OAM frames - but there may be a >>>>>>> MEP/MIP. >>>>>>>=20 >>>>>>> So would this work to clarify the text? >>>>>>> "It should be noted that the data-plane loopback function for a >>>>>>> given transport path can be applied to data-plane loopback points >>>>>>> residing on interfaces where there may be no corresponding MEP or >>>>>>> MIP." >>>>>>>=20 >>>>>>> For completeness, the references to "MEP or MIP" in paragraphs 3 an= d 7 >>>>>>> of section 4 would also need to be changed, to instead refer to the >>>>>>> transport path that is being put in to loopback. >>>>>>>=20 >>>>>>> As another data point, I found this text in RFC6371 section 6.3.2: >>>>>>> "It should be noted that data-plane loopback function itself is >>>>>>> applied to data-plane loopback points that can reside on differen= t >>>>>>> interfaces from MIPs/MEPs." >>>>>>> Note the critical difference compared to RFC6435: "that can reside" >>>>>>> instead of "residing". >>>>>>>=20 >>>>>>> Thanks >>>>>>>=20 >>>>>>>=20 >>>>>>> David >>>>>>>=20 >>>>>>>=20 >>>>>>> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: >>>>>>>> Sami, >>>>>>>>=20 >>>>>>>> Thanks. Yet, I am not sure David's interpretation and mine exactly= match. >>>>>>>> David, correct me if I am wrong. For me it says that we can do >>>>>>>> loopback on different interfaces (for different LSPs) but implies = that >>>>>>>> there is a mip/mep for that lsp on that interface, while my >>>>>>>> interpretation is that the presence of a mip/mep for that lsp on t= hat >>>>>>>> interface is not needed. >>>>>>>>=20 >>>>>>>> -m >>>>>>>> ________________________________ >>>>>>>> De : Sami Boutros (sboutros) >>>>>>>> Envoy? : 09/01/2013 19:00 >>>>>>>> ? : VIGOUREUX, MARTIN (MARTIN) >>>>>>>> Cc : adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at = Cisco); >>>>>> Siva >>>>>>> Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Ste= wart >>>>>>> Bryant (stbryant); loa@pi.nu; George Swallow (swallow); >> rcallon@juniper.net; >>>>>>> mpls@ietf.org >>>>>>>> Objet : Re: [Editorial Errata Reported] RFC6435 (3429) >>>>>>>>=20 >>>>>>>> I agree with Martin, the text proposed by David describe more accu= rately >>>>>> what >>>>>>> we meant. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>> Sami >>>>>>>> On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: >>>>>>>>=20 >>>>>>>>> Adrian, David, >>>>>>>>>=20 >>>>>>>>> what I think we meant here was that a loop-back function could be= done >> on >>>>>>> an interface regardless of the presence of a MIP/MEP on that interf= ace. >> Yet, I >>>>>>> have to admit that MIP and MEP are used in Section 4 of RFC6435, th= us >> surely >>>>>>> causing confusion. >>>>>>>>>=20 >>>>>>>>> I'd welcome the views/souvenirs of my co-authors. >>>>>>>>>=20 >>>>>>>>> -m >>>>>>>>>=20 >>>>>>>>> Le 12/12/2012 19:17, Adrian Farrel a ?crit : >>>>>>>>>> Hello, >>>>>>>>>>=20 >>>>>>>>>> Authors of RFC 6435: I need to hear from you that you meant the = text >> that >>>>>>> David >>>>>>>>>> suggests. It is very clearly not what you wrote and, if you mean= t >>>>>> something >>>>>>>>>> different, it is clear why people are confused! >>>>>>>>>>=20 >>>>>>>>>> Working group: I need to hear from you that you agree with David= 's >>>>>>>>>> interpretation and support his proposed change. >>>>>>>>>>=20 >>>>>>>>>> Only then will I try to work out whether this is a "typo" worthy= of an >>>>>> errata >>>>>>>>>> report, or a technical change needing a revised RFC. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Adrian >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>>>>>>> Sent: 12 December 2012 17:45 >>>>>>>>>>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>>>>>>>>>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>>>>>>>>>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; >>>>>>> swallow@cisco.com; >>>>>>>>>>> rcallon@juniper.net >>>>>>>>>>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.or= g >>>>>>>>>>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The following errata report has been submitted for RFC6435, >>>>>>>>>>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>>>>>>>>>>=20 >>>>>>>>>>> -------------------------------------- >>>>>>>>>>> You may review the report below and at: >>>>>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435 >> &eid= =3D3429 >>>>>>>>>>>=20 >>>>>>>>>>> -------------------------------------- >>>>>>>>>>> Type: Editorial >>>>>>>>>>> Reported by: David Ball >>>>>>>>>>>=20 >>>>>>>>>>> Section: 4 (para 5) >>>>>>>>>>>=20 >>>>>>>>>>> Original Text >>>>>>>>>>> ------------- >>>>>>>>>>> It should be noted that the data-plane loopback function itself= is >>>>>> applied to >>>>>>>>>> data- >>>>>>>>>>> plane loopback points residing on different interfaces from MIP= s/MEPs. >>>>>>>>>>>=20 >>>>>>>>>>> Corrected Text >>>>>>>>>>> -------------- >>>>>>>>>>> It should be noted that the data-plane loopback function may be >> applied >>>>>> at >>>>>>>>>>> MIPs/MEPs on different interfaces for different LSPs. >>>>>>>>>>>=20 >>>>>>>>>>> Notes >>>>>>>>>>> ----- >>>>>>>>>>> The existing text has caused confusion (specifically, among exp= erts in >>>>>> ITU-T >>>>>>>>>> SG15 >>>>>>>>>>> when discussing G.8121.2), in that it seems to suggest that the >>>>>> interface >>>>>>>>>> where >>>>>>>>>>> the MIP/MEP is located may be a different interface to the one = where >> the >>>>>>>>>>> loopback is applied. >>>>>>>>>>>=20 >>>>>>>>>>> Having spoken with some of the original authors, it seems this = was not >>>>>> the >>>>>>>>>> intent >>>>>>>>>>> of this sentence; the intent was to point out that as different= LSPs >>>>>> would >>>>>>>>>> have >>>>>>>>>>> MIPs/MEPs on different interfaces, the corresponding loopback >> functions >>>>>>> would >>>>>>>>>>> also be applied on different interfaces. >>>>>>>>>>>=20 >>>>>>>>>>> Instructions: >>>>>>>>>>> ------------- >>>>>>>>>>> This errata is currently posted as "Reported". If necessary, pl= ease >>>>>>>>>>> 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 necessa= ry. >>>>>>>>>>>=20 >>>>>>>>>>> -------------------------------------- >>>>>>>>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>>>>>>>>>> -------------------------------------- >>>>>>>>>>> Title : MPLS Transport Profile Lock Instruct and >> Loopback >>>>>>>>>> Functions >>>>>>>>>>> Publication Date : November 2011 >>>>>>>>>>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Ag= garwal, >>>>>> Ed., M. >>>>>>>>>> Vigoureux, >>>>>>>>>>> Ed., X. Dai, Ed. >>>>>>>>>>> Category : PROPOSED STANDARD >>>>>>>>>>> Source : Multiprotocol Label Switching >>>>>>>>>>> Area : Routing >>>>>>>>>>> Stream : IETF >>>>>>>>>>> Verifying Party : IESG >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> David Ball >>>>>>> >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>=20 >>=20 >> --=20 >> David Ball >> >=20 > --=20 > David Ball > From scott.mansfield@ericsson.com Fri Jan 18 08:50:41 2013 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 A9F3321F871D for ; Fri, 18 Jan 2013 08:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 35RkZ1K1LzPv for ; Fri, 18 Jan 2013 08:50:41 -0800 (PST) Received: from usevmg20.ericsson.net (unknown [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A8F8021F8738 for ; Fri, 18 Jan 2013 08:50:39 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-dc-50f97d5d0ff9 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 54.82.31450.D5D79F05; Fri, 18 Jan 2013 17:50:38 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Fri, 18 Jan 2013 11:50:36 -0500 From: Scott Mansfield To: "mpls@ietf.org" Thread-Topic: LS from ITU-T SG15 to IETF on the closure of the ad-hoc group on MPLS-TP Thread-Index: Ac31A9UuFAQBiZIHS9e4ubOSe/IHoAAl3OZg Date: Fri, 18 Jan 2013 16:50:36 +0000 Message-ID: References: <9BA9FE6D8B2F5344BF95CDAC35C8320D637E9E84@TUCHM02.TUECSP.UNICC.ORG> In-Reply-To: <9BA9FE6D8B2F5344BF95CDAC35C8320D637E9E84@TUCHM02.TUECSP.UNICC.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/mixed; boundary="_005_EF35EE4B92789843B1DECBC0E24558640FF46Aeusaamb105ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2WSbUhTYRTHeba7u6so3ebUkwaVYZQpviBUpKJRoPbBFUUWZEpdVDSTzUkI gpmZbkwX5ttNm9pyul6cLwPxbU5E0vxgaGRavuAUzA82zWTmS3f3LhD69jvn+T/nnOf8H4Iv eox7EakZWZQ0IyndB3fGyuQ9iQEJuTZJ0JYi7OzU62ZBJIrWam08CbrlHHaPSk/NpqSBEYnO KcOr/Vhm6YbHw72GZSwPLb/0UCCCADIUulWxCuTEoAeMzbTgCuRMiMhBBPlrm4gLdAjWrTbM rsKZC8auSmRnMXkcBp8pBXZ2I2/AdsMczuXjYVWrc2hCoGLIyrMzRvpC5+oGm3clL0P571lW LyLjYLdAw9Z3IiXQNDXL6hEz0ebIW5b5pCdMWTQ8blIxzH/6iHPsDssLuwKOj4PWYsI4fSqU 6zuEXK+DMFxtwdRITO8rRe+T0ftkXP4BlC52CDj2h7ruNZzj09BYv8L/x6P9C7z/88GgXdE6 9EehdK4d0cwe+aQeQU/VpKPoeWjMNws5PgbPlfMOPgzt5cWOC08QfLDW82jWhW4EfZZRARe0 IjC+bxJyQQ0PdL29GBdYECh/WBwn1Qi+bX9nRxGRufC5po0dEWfGNb1oZLoQjEMnoLbgCNdQ jcAwbWaf5EbehpEKK6JZFxPg6a8tjHY4qvjSz9axO2pQ7mLc+kKhqMsmpB2ODg+pMHt9Fyav m2Q370LGwgDdwK9DYXpEyGVU9v3kkKA2xHzkIcADOlHP8rkB5E1gPp6uVy+NSURkclIWlUZR mZT0jlSeTskGEI9w8spDalmzf7imVqgyyzzVhpxHO8ZqXs5EdFFLz3ZFMlYYYTpwU11XkWac KMxolU2X4CW6xTz8QvCmYXFnyeeit9wp8orM941fmXHJXbMhToeuovh3P/94R9EqQWVU2154 s8VUHNN3t+9a1clTcWe+tq9fHw+fWc/aDIw5JH41btb7YLKUpGA/vlSW9Bcfg2jjlgMAAA== Subject: [mpls] FW: LS from ITU-T SG15 to IETF on the closure of the ad-hoc group on MPLS-TP 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, 18 Jan 2013 16:50:41 -0000 --_005_EF35EE4B92789843B1DECBC0E24558640FF46Aeusaamb105ericsso_ Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E24558640FF46Aeusaamb105ericsso_" --_000_EF35EE4B92789843B1DECBC0E24558640FF46Aeusaamb105ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MPLS Working Group, The pdf document attached is a Liaison from the ITU-T on the closure of the= ad-hoc group on MPLS-TP. I have also attached a follow-up message from Yo= ichi Maeda (the former ITU-T SG15 Study Group Chair). Regards, -scott. Scott Mansfield IETF - ITU-T Liaison manager for MPLS From: Jones, Greg [mailto:greg.jones@itu.int] Sent: Thursday, January 17, 2013 5:45 PM To: statements@ietf.org Cc: Trowbridge, Stephen (Steve.Trowbridge@alcatel-lucent.com); Malcolm.BETT= S@zte.com.cn; Scott Mansfield; Eliot Lear (lear@cisco.com); OTA, Hiroshi; T= SBSG15, ITU Subject: LS from ITU-T SG15 to IETF on the closure of the ad-hoc group on M= PLS-TP On behalf of the Chairman of ITU-T Study Group 15, please find attached a = liaison on the closure of the ad-hoc group on MPLS-TP. Regards, Greg Jones Counsellor, ITU-T Study Group 15 International Telecommunication Union Tel: +41 22 730 5515 Mob: +41 79 249 4832 --_000_EF35EE4B92789843B1DECBC0E24558640FF46Aeusaamb105ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MPLS Working Group,

 

The pdf document attac= hed is a Liaison from the ITU-T on the closure of the ad-hoc group on MPLS-= TP.  I have also attached a follow-up message from Yoichi Maeda (the f= ormer ITU-T SG15 Study Group Chair).

 

Regards,

-scott.

Scott Mansfield

IETF – ITU-T Lia= ison manager for MPLS

 

From: Jones, G= reg [mailto:greg.jones@itu.int]
Sent: Thursday, January 17, 2013 5:45 PM
To: statements@ietf.org
Cc: Trowbridge, Stephen (Steve.Trowbridge@alcatel-lucent.com); Malco= lm.BETTS@zte.com.cn; Scott Mansfield; Eliot Lear (lear@cisco.com); OTA, Hir= oshi; TSBSG15, ITU
Subject: LS from ITU-T SG15 to IETF on the closure of the ad-hoc gro= up on MPLS-TP

 

On behalf of  the Chairman of ITU-T Study Group= 15, please find attached a liaison on the closure of the ad-hoc group on M= PLS-TP.

 

Regards,

Greg Jones

Counsellor, ITU-T Study Group 15

International Telecommunication Union

Tel: +41 22 730 5515

Mob: +41 79 249 4832

 

 

--_000_EF35EE4B92789843B1DECBC0E24558640FF46Aeusaamb105ericsso_-- --_005_EF35EE4B92789843B1DECBC0E24558640FF46Aeusaamb105ericsso_ Content-Type: application/pdf; name="oLS-002.pdf" Content-Description: oLS-002.pdf Content-Disposition: attachment; filename="oLS-002.pdf"; size=264164; creation-date="Thu, 17 Jan 2013 22:42:34 GMT"; modification-date="Thu, 17 Jan 2013 22:42:35 GMT" Content-ID: Content-Transfer-Encoding: base64 JVBERi0xLjQNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDI0IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4v T3V0cHV0SW50ZW50c1s8PC9UeXBlL091dHB1dEludGVudC9TL0dUU19QREZBMS9PdXRwdXRDb25k aXRpb25JZGVudGlmaWVyKHNSR0IpIC9SZWdpc3RyeU5hbWUoaHR0cDovL3d3dy5jb2xvci5vcmcp IC9JbmZvKENyZWF0b3I6IEhQICAgICBNYW51ZmFjdHVyZXI6SUVDICAgIE1vZGVsOnNSR0IpIC9E ZXN0T3V0cHV0UHJvZmlsZSAxNTQgMCBSPj5dIC9NZXRhZGF0YSAxNTUgMCBSPj4NCmVuZG9iag0K MiAwIG9iag0KPDwvVHlwZS9QYWdlcy9Db3VudCAxL0tpZHNbIDMgMCBSXSA+Pg0KZW5kb2JqDQoz IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1 IDAgUi9GMiA3IDAgUi9GMyA5IDAgUi9GNCAxNSAwIFIvRjUgMjAgMCBSPj4vWE9iamVjdDw8L0lt YWdlMjIgMjIgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+ L0Fubm90c1sgMTQgMCBSXSAvTWVkaWFCb3hbIDAgMCA1OTUuMzIgODQyLjA0XSAvQ29udGVudHMg NCAwIFIvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9iag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCA1MDkzPj4NCnN0cmVhbQ0KeJy9HGtz27jxe2byH/BRamOaAPjM3NycEzse d2LnYWU67aXTkSXZZk8idRQVz/XXd3cBSKBIkLKsazvnSCKwu9gXdhcLnp6VVXY/nlTsp59Oz6pq PHmcTdmvp++KqioW/zod/bGcnX4eP2T5uMqK/Oef2bvz9+z316+C1Et8zoLIi9OUBWnoJfCNewEr Z69f/f0vLH/9Sg/DQYkaInaHvBu9fnX6gbOUje5fv+LMh/9zFgovCFjie37ARovXr3z2gH8uX7/6 dQBEzobhIB+mA6BoeJLQx7fDf7HR316/ugB4X56BWexgTjkMdaFmx0ISeNx3IbkdnsgBrCsaLGCZ s2EAaE+E+qVk+HAMv83n+Gn75H7I9dfqEXmymbcY8oRmVMMTHtDvZTaebwBVlfk0gf8eERaOmeIH BY94rD4OOVdDshWbD5NBNs5WBc7PN8NXFUGdDXm4WQA9reBxYMgBiH8MYzXjzuBU89cIj377z2wy NPOAilANuBohFd/YhBAvceAfR5JLwIUXhw65lNmDYVDlIUmKmnwY2YRvmEi/jc2q8Gf8spqZ4UpM wMenIReDjMQ5p6Va/DjOspQ1RakXNRaV5UgFCTubjJHbs6laG/f1wx3JbwSV4U8kWTX9Bwgom8Kf NX4lHaXlTEHOpKLIg7XSa55YeqGZeZy18iTx0va1HpedYeqJpN1412a1DkUogCNab4Vf0yvNMPhY GF6vGGpYoR8namKJT34AmB3r2rF9IkSrHMhzX0cxAwehxQc/0QTL+2TkMFYMtSPVhr5VA8t3AEYi lqgoEcpyszIi6g2ipXF3alysl6FQbCG0LHfFKhxZV0lCgt/UrEJRFW8FUmXKucaWw9rhiu1ciWdH ci2p70mH0ii+Lo3ZlCTnHbIMS/Bjblzh+OhOIgDraVrOVox3wLp5Zhzd2MHSJ9QJRfHjRuRb8bY4 k7HxDaCUoda27L/kkHCw2edPouNKhafCCx2L3vJe7zjekZAKHnhp7MC6I84v+ilgkoKBbxPM94KE /vi+wnX/l72eJ+oxUho3nodBCIww8yGia4LYY4iighhCVGzYUXsoO9fQPSDRz7tWYfATiTUSNs9l 3zK7xzgsKPKigMnE491iZRfXFEGH0ksgZo6S0PNDFvteIlkSeTy1NIidfsbA/Pr91TnzTz+O8wc2 mOUnl++G20ic4CgwEYHB+BXgJG2qyEXdADjslBHsl+CYBFHdpoKGYi4CL+YsBkFA6C9CWGrMhPCE dJDMHSQTIAVH2HBEq/WQndhEi9gLExYDwzdEX6GzuRnh3wu02a/gUG7ORuhu6NGnmzOKfz9CrkBG PcI/NBR/gg/gst7DpE/wSQyur3HmtxuYq34+I9AaFLMefrppuIWXrU6GsLqwvjq3SGQiUPpaJDyK Qe6dIhEOkRCgDdUWoBaqAVFAIXItdo7AWoBsmBJpsomf1+jjeYi8au5Vz8Eq27DG3Ksj/cn33/Gf X4KndXVx4sVJfXUvW00rloTA17B8vGU+7Jw+ap5QMcCxmRiCPcnk/8DFUAZeEP3ZXAxljHtxDcvF 8bEENKNrLU3PqX298LkH20ok0fbbzVR2ek7t7B1wNkQLl+eUPiRJiubRxceL98OTGAz1+htG9DdX 78/w39GV07Udil4Az8EX2uib4j/OCsEb+cZ73o7Obs7PMIL8en6FS/snxpD0AywS/7lhtxfvR/jp 09cjEyThpyStE7SzaFISW/jBi4Xv3jWjFPajYMOZb+e4Bf6DMpDPyJvN7qn2uvOXCKiFCuEL3Kgs KiC6Ajijya8DgCWPjE2QwtXWfHJsFKEXuBcUHRkbRKdBWF9QR3AgICQF3RMQ3SGl0pMx5DwQHrc7 ndAVG1hwhAPO1gJa3aSkde5JsHGTClEQYETdTnHUTbHhcjugru0e7Bhs1rd2kPwBMlMqDGRYlqHk lhU5JsTwvVmCfCEJhnE2DX1+I/6TuBFIjCcjyP24keGnErnwoNhBBeBUlU7wy1t2kWPKTI+ROzRE sexP4lONOLeCmZwLDA7+SXwvTrsMIulOuRCKICiQa+1pD5QkRlGEvlhR+2WNsTHV+vCIBbn0fbD6 PgR1a55qHI4ZUz1Zx9wRr0CkFsWGTzxKKEhyMyp17VgIJzL0tsNxpaYQxoWKVYnZOOUblr5h3H/T siu9AFOcNjBxAXiCU8hbjogIYksvlXVEHc4Qtko0DCUDAXre7b25q0BgAxIOQA6KjXXtQXGNFK6x Uw0EdDYGhiXSiwQWKNIAdBarjaaeYrZEGkBPdh5HuNvp54kXip3nWiLO+RLmbx4rA6gNMAxyAZA+ uCNpnkNMEUY7A4wPMwCiXQgC3FO4hQC7YX3AroMCB4inq2mE8UuX0F35vHYUCEcoOMmejkIEHBUk wqNdq1j96+ArFu3vsQjrsbdsdM58P2XfB+CnLi+wInID5gJuy+GyDqBERsKTYQsl/Q4eNErs4eC5 K8/SRCOYwzw8aERao1md69IhYalPW9HnO138AahTzDHacPc7esWvgIdYCehimDM30UaoyCZADc73 eHpIUHTFS5N9hSV4Ssu+Od3wIfjCGMsQTXwtqcELsERg4KIFy4jd0vHbejo8gSCJDgEZpl6XJZ59 rJesY9c5gBARgMuMWwjptaIQ0gxAo6xIYIdH6FILV+qglNkCBMqMkNqrLK2W5MfoOm0GqgOx+Wwo neazF8YGqxJgsmhD2WtAGp82oG5euZIWLWMbVLo36caIgHSZ2qS/R27Ni9WaTlFZcc+qR2ygYWM6 qnUo2mFECNDIOG4hwmlZB+KBLCGWLXgeCzQk9K3sQZ3/gjkVObv+rKv/goMjPiotEjbzsI2WI69Z YqEhbeBhJz5ECoLqDaPPR0YpUzyKaC6t33PEsefLfeIXV86qzdiCs3f8ApYgUpiaotuyqP5Ih7ln V7f6FIf+JWdyNhrqyheeVtCHm5HLsxxAkoSgM5AtJO0TSyeaKSqMDgFvSj1Kqd+Ic7WsaYQrDtaP Ay43oxxBaAj7JOT93E/pnw4hutI/zTELjiNVcvj+MEy9tMawD0VJvkt1c2C2LAasKpzbwAGoMd2A IL2Ju2MTgNSKbxgmE+BwI2arHcK5UjUCVIMT7h1uhBj0hZGPU7vd0AuQpLiyJpJ+hwBGGeyjS8J1 ZqwFasF5pi4FPp6tN3VJtWTBtrGAeAL/011GclCxCnuvnMp1AC08EJh+NonpVy6FbQ/lcqWEWu4W nOcqF1Ad7KdcByFRytVA0q9cPPaivZSrO92z4TxTuYS/s0Vq5cIuuVAlzQWmfQtMacb7eK4DaOGh 8lwNYvqVS2HbQ7mc+Z+SuwXnucoFVEeykf5djD6wr1hdKNaq1QyQn5XUWAyMxRj2DSVPavAtdW9c urTyAOpESgdWTep6tTJIY2zp2UMru5MnG84ztdL3vbCmCGfLJbINNbH4MZ67lO8QlDhYtuHsVT6N bQ/lc2ZOJF4bznOVz6f2q9206RH1KysXY9gVckydbi8hrfs+gF+5z/4GyuaTCuZratyE75HJ59s1 8BASJU/wBLlJIp6XttTbXoApiDDkaWLq1/U4waB4D13vjvdtOM/T9UBVKSyiz7FcOZ7SGZQ+ozqR nTW3Q7BznxSoib5f7RW2PdTedQylJW3BeabaBwnHqXts6IchoQ29iaRfnUSK53+KpwGFEg7WdGce BCc2VSAEtH/dKQgp+bVdQpFXkHiEg8qpQAfh4z73ZAu+3qKTZhNu+1ha7+CTdCYcKmfUhFuQnlFz Qsrruk+ZdTVbPqIJ5tpRemxE+87TXUlXRR5mrmrFYdQI8F6hbKGm79hcOttUj8GcIMRub3sPnm96 52fz47KAxwJttYHSWYo6FA3VPpp4PuKp/9qU4CiPqo4sZPDNYdyCulfIzqzoGEKW1GdkkfPt9uzI PI94Oya3lxCpj6eS2ksIsAvsrOjyEq70yIYU25D2ElkqsWepaZcjLEO3xKAvwob9dnHc7wVejids x/NXDA5ZLHyWYqdWkjQPc16GGAK7kB/i5oIjC7RhgxcUKGe6B6iVnNvlON9SFB6JIjxeD3ccH/5e PphPX+kaxqqa/UCl86qyeAJS70rahiC7/GWMuqivQDa98ouoC0IKgHqpa3rpF6INMJrvRTtfT7D/ V3lrb1Is+vQoOpLUQj/Blq9eX/5iPJy3b1c7eLbs2ehTgH2Iuj8IKPB9n2+q5a28iWvF+gA2yjDt KtbrEa5ivX4sIowu688jQRG8c34U4PGzea5aaGojkKe4lbog6MqHISFMiBcd5wUBj/F6ozn08fEK lWOj6W6sI0Dp5ohlBxBKeSdUh3wk2Cd0rtGQ1kUlYjxS7BKVGuEUlX4c0h2HVk67ABhOq+dOTtda xFsDepcBKC5BWh/UN2DrIJg9FnRseom+oMQuBPCP+uQ0UIGdfXBqCwFvUSaRDb/uy+pjQZXD+tjR Z6qFPqHzXTHKFe6LEr4sZlN2B99jXVTB6p4cXAKPWZazDyadvyvX42G8Kb+0I5YxHXfUEDPX2MRv jBW+nzB8FwIwQh0ZFOU0y3HbqGbsyZwhlL9hT7Ac4CG7C7y5KEg9Ywr6lG444595sVyYheWVPq5X 59d88NEpggSUeAemUwQJqFl9qJbAV/w7081JxWJLx9S66Zuv2BPe7RWDRxDCLZYTSSIovXwKLGLL sviRTbE7g1SL3YNmmZvVbFmoWkzF7qkg3sOkmG5PKCotqta5fl1BgybFeNDhq6Gg6rHnQICZhJR1 DI1rmjWTa00TW2gGh+IbiKSkhbpQXjxlMB3pQ9KXyKahfpuHacsAlq3wL6lCuX2Rwvbxb6hlM7qu qIxiP6GBwUzm6ykRQH3Y1Azy6Qz+XveIQKbojNVy9tWQ74NL+O4lHKmt3eqoa2KCjrWGATwpVVSn 7BKmc+kJ6oSmH7F4nSq2FMQhcg+pZsTfURVH1Ft1hv7hBscAPYu7GR3FCGyTQO7fkr52L1o1WyiS FuMcBfaAGBcz0Nxqht8X7JGMcmxMF9wCUFDkyBvgNTivigrIFZsUdBo0VW/RoVk5K4s5uV+tB9l0 x9sZRVZ9OrBM46IfwD3DhCXL8OUQ+AoDNi/yB7XK7mVBJLQx+nIGTvP3dVYiFVO2yhBUPjHN6IS/ ROdP6x6r9z2gAj3BYuTgt66+mpqhxRA5hXXcLt8kYthqeX2sdk4Tc96Ts7stt6nujntFBtwr1hWb ZqV5rQX1CIDlgR/4A298oVJYyk/rn89+kOOquhknsJpurmH8vtbN+nQsla/euNTbD+kGsD3XhYb7 SWMsvTCGkSNdTeBPmd0pUd0pH4CbxZMHel5peY0rVurz69USCMv0q3RSnZOhi+TIDOmjV1bv9NDd YDgJlKG2+YxXyMrlhpcr9jheIfe1iuRsATY27WFdEtB9KFrSPYqqWLAv6SmYIAmjYF+4j98QIh2U 3qNgtq/rULZVl93OVbGaCkUR3Xay0brVzad8wh6Ll7boRHGlOjSFNselenVSMXVtKBIbRsI6sO4N pbUkpWK4YDeGQ8NAbkbSk5s7unHyc52W0w9ho6fRp1cBWBMbStgSMkJIt4Nu8EWClN669FdQNasL y7ZmhuGyPZIs0dLY+YzdYytsuYl7Ov1LIHC/tQE65R1EdLHMGkrtxZ/pYjXVo8pFlhdz8qoPam9x SBub6ELngpvCbq2t9Qg7oP3xEGlbM58jbnsa2ehbpxSFer1BF6IdidtDjyNyG2KfzO2xltDpb1nQ O+WsVwTlztyAh3jK4Fx3U/CtHRM9gpfB5rbwMwVvzXyO4O1pyh87LV0KEnwXoh3B20NbBO9MFSGn qU9WaeF+UYdWEXt6n4rYYy0V0VEyNQFM2YXeJUXzfKOmJxH1kDvZ1NST1i6QHj3BO33JQXpizXyO ntjTvnCxh550IdrRE3vocRyEDbFP+vZYS/o3eIZZQcz7G6Zf1HpE73ZT77eiWIj8BvbXu1QhwfN+ JyeaqtDa59KjCj7eXThIFayZz1EFe9oXuivZpwpdiHZUwR56HFWwIfapgj3WqQrX5BDG6hq0iscx O3TWn3x834iTB00laO2UacbXIELsslAQqWsJGIU5g0pTcsyAKOhv5JQmn6zdPdo3qQtjvMpaQ+7k asSxxFIba2p+mX7XXl5UkFgwfOFnketGv7VK8euRf254/cR0gO6bAN08wSBdNWl1pAn40hsR7bcA zeiYb1+6gFnC9+FQUT7bJPoWoTprnquKIenwfXcBtYZgPkM5kWcBRafVIIrHxXKuLtN389oG5ZYL hbC1sdXyFwp+sxWlPtXKoyy3Wnu6bPd9CEkg6ArlgTpTZFS+NO+QRemBwv1QHQ7OdCkI6IVRNezd BtF6aNAip5BjI6LWM5XdUkMK9u4tqIJARrst55CIzBIWlOTiEpfLIssrkw9P2XXpkfGQ4c8nxXzB 3pn6SKXfivl9QBjoqXc3q6oVcvOX/xITZx7p98Kb5Nui1orhizi5aLzytWVl2G1gnIfNbuqKVU1u 1LG4Aiv+asojsIySwts1Vc6wQmupqeqdVaVSqgkkgxK5FOolkUGttoWg+bhS3AAw5CiibkchY4l+ r0a6SyGxRo9tp/ZY5SjeqPQ7n5oa1KTIcQ/QvZlWlbO2tk5m4h0yg0V1KK3n+kYm1kfQd7Dl3GWy kAakO0BmSrWov3bTCepSfx7gGwxr87u1v7XTre6SBdbZuC+91ID8d/1/Lr7DFhnF9ZmdxIS+dWSn X2uVMDwojOjVg/arOyIf36mMiPBuEr4+Et82yFM2ATynV4vxw0wIdl4wc0j3PwT17VANCmVuZHN0 cmVhbQ0KZW5kb2JqDQo1IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1l L0YxL0Jhc2VGb250L0FCQ0RFRStUaW1lcyMyME5ldyMyMFJvbWFuLEJvbGQvRW5jb2RpbmcvV2lu QW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDYgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAx MjEvV2lkdGhzIDE0MiAwIFI+Pg0KZW5kb2JqDQo2IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlw dG9yL0ZvbnROYW1lL0FCQ0RFRStUaW1lcyMyME5ldyMyMFJvbWFuLEJvbGQvRmxhZ3MgMzIvSXRh bGljQW5nbGUgMC9Bc2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjc3L0F2Z1dpZHRo IDQyNy9NYXhXaWR0aCAyNTU4L0ZvbnRXZWlnaHQgNzAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgNDIv U3RlbVYgNDIvRm9udEJCb3hbIC01NTggLTIxNiAyMDAwIDY3N10gL0ZvbnRGaWxlMiAxMzggMCBS Pj4NCmVuZG9iag0KNyAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9G Mi9CYXNlRm9udC9BQkNERUUrVGltZXMjMjBOZXcjMjBSb21hbi9FbmNvZGluZy9XaW5BbnNpRW5j b2RpbmcvRm9udERlc2NyaXB0b3IgOCAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMi9XaWR0 aHMgMTQzIDAgUj4+DQplbmRvYmoNCjggMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9u dE5hbWUvQUJDREVFK1RpbWVzIzIwTmV3IzIwUm9tYW4vRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9B c2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjkzL0F2Z1dpZHRoIDQwMS9NYXhXaWR0 aCAyNjE0L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgNDIvU3RlbVYgNDAvRm9u dEJCb3hbIC01NjggLTIxNiAyMDQ2IDY5M10gL0ZvbnRGaWxlMiAxNDQgMCBSPj4NCmVuZG9iag0K OSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHlwZTAvQmFzZUZvbnQvQUJDREVFK1RpbWVz IzIwTmV3IzIwUm9tYW4sQm9sZC9FbmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyAx MCAwIFIvVG9Vbmljb2RlIDEzNyAwIFI+Pg0KZW5kb2JqDQoxMCAwIG9iag0KWyAxMSAwIFJdIA0K ZW5kb2JqDQoxMSAwIG9iag0KPDwvQmFzZUZvbnQvQUJDREVFK1RpbWVzIzIwTmV3IzIwUm9tYW4s Qm9sZC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkv RFcgMTAwMC9DSURTeXN0ZW1JbmZvIDEyIDAgUi9Gb250RGVzY3JpcHRvciAxMyAwIFIvVyAxNDAg MCBSPj4NCmVuZG9iag0KMTIgMCBvYmoNCjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnko QWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5kb2JqDQoxMyAwIG9iag0KPDwvVHlwZS9Gb250RGVz Y3JpcHRvci9Gb250TmFtZS9BQkNERUUrVGltZXMjMjBOZXcjMjBSb21hbixCb2xkL0ZsYWdzIDMy L0l0YWxpY0FuZ2xlIDAvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvQ2FwSGVpZ2h0IDY3Ny9BdmdX aWR0aCA0MjcvTWF4V2lkdGggMjU1OC9Gb250V2VpZ2h0IDcwMC9YSGVpZ2h0IDI1MC9MZWFkaW5n IDQyL1N0ZW1WIDQyL0ZvbnRCQm94WyAtNTU4IC0yMTYgMjAwMCA2NzddIC9DSURTZXQgMTQxIDAg Ui9Gb250RmlsZTIgMTM4IDAgUj4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsv UmVjdFsgMzI2LjE5IDQ0My4wMSA1MTAuMzMgNDU2LjgxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5 cGUvQWN0aW9uL1MvVVJJL1VSSShtYWlsdG86c3RldmUudHJvd2JyaWRnZUBhbGNhdGVsLWx1Y2Vu dC5jb20pID4+L1N0cnVjdFBhcmVudCAxPj4NCmVuZG9iag0KMTUgMCBvYmoNCjw8L1R5cGUvRm9u dC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FCQ0RFRStTeW1ib2wvRW5jb2RpbmcvSWRlbnRpdHkt SC9EZXNjZW5kYW50Rm9udHMgMTYgMCBSL1RvVW5pY29kZSAxNDYgMCBSPj4NCmVuZG9iag0KMTYg MCBvYmoNClsgMTcgMCBSXSANCmVuZG9iag0KMTcgMCBvYmoNCjw8L0Jhc2VGb250L0FCQ0RFRStT eW1ib2wvU3VidHlwZS9DSURGb250VHlwZTIvVHlwZS9Gb250L0NJRFRvR0lETWFwL0lkZW50aXR5 L0RXIDEwMDAvQ0lEU3lzdGVtSW5mbyAxOCAwIFIvRm9udERlc2NyaXB0b3IgMTkgMCBSL1cgMTQ5 IDAgUj4+DQplbmRvYmoNCjE4IDAgb2JqDQo8PC9PcmRlcmluZyhJZGVudGl0eSkgL1JlZ2lzdHJ5 KEFkb2JlKSAvU3VwcGxlbWVudCAwPj4NCmVuZG9iag0KMTkgMCBvYmoNCjw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK1N5bWJvbC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0Fz Y2VudCAxMDA1L0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjkzL0F2Z1dpZHRoIDYwMC9NYXhXaWR0 aCAxMTEzL0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDYwL0ZvbnRCQm94WyAwIC0y MTYgMTExMyA2OTNdIC9DSURTZXQgMTUwIDAgUi9Gb250RmlsZTIgMTQ3IDAgUj4+DQplbmRvYmoN CjIwIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0Y1L0Jhc2VGb250 L0FCQ0RFRStBcmlhbC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgMjEg MCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAzMi9XaWR0aHMgMTUxIDAgUj4+DQplbmRvYmoNCjIx IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStBcmlhbC9GbGFn cyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA5MDUvRGVzY2VudCAtMjEwL0NhcEhlaWdodCA3Mjgv QXZnV2lkdGggNDQxL01heFdpZHRoIDI3MTAvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvTGVh ZGluZyAzMy9TdGVtViA0NC9Gb250QkJveFsgLTY2NSAtMjEwIDIwNDYgNzI4XSAvRm9udEZpbGUy IDE1MiAwIFI+Pg0KZW5kb2JqDQoyMiAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1h Z2UvV2lkdGggMTA3L0hlaWdodCAxMjAvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBv bmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjgwMj4+ DQpzdHJlYW0NCnic7Z3Nix3XmYfnD8g0WRom6xASmM0sPFkMDsREMBkMk9FgZojBJLHlZGGysWYT pCwigrPw4ATJjsE2Y1kRJhL6sLGD7fa0UVuyLNmSpZFaUvTdre6oZaXT3Y5HKISep+pRvzlTVbfu ube/QcVLUbdu3VPn/M7v/TjvOVV3bq5h+9Pl8Zn3jjd9c3fL2m7fvj3z4n5gXOmKrOFtYuTi5KZn QHKlK7KGNwCc2je00rVYwxsqPHHfo3+emlnpiqzhDRKOrd94V5H73vDFo5//Gg5lpSuyhrfJDVvA 8K5H7nvDBl75q7+7q8gL2bCEYHhXkfve0N+xL37rriIvZLv59E5IWEQ1f5hd6bqsyQ3unblnHRiC 5ErXZa1uWsLCGN7NM/S14Y6xhIuuyLfLbXr21o2pP3wyPTM6fvPqtekQTiJ8y5Wf/e+txbrpSm04 YklIcLiQcsZv3EQOHLn6wu6jP906/P0fvfZvj+9GHnpijwfIP//glfTMfzz5FrJj70l+dfbS5GK1 aJm3ICHSU55BmtHwVwfPbPrFO//48M6v//t/CQsAbtt++OU3jr996Nxb750Cnw/+59Kxc6PsPbN/ 6NSO/ce4RgwBlt9SAuVw8ccjExa+dK1e3A3cBBAkc6IaFBDcaD5w/e0/PccexMDk5JnrkPB3N6dQ 2+nZWYQDhZMKv00PRj+Zuvy7yTOj42ALkgNfeRIkEQhMmdzl0z9+tgwILHCDhNjAOxi2Dk+wYPBN 3P7m3v+kyTScNmLKpmZmA5wQ8By78UnI1clCQCzk4sTk+fHriB/Vblj60+0HoSWc5AwfKXw5Aelj CxI2RjXgA3RQghZ96f5t8IRmwjdpVsetDmMgWcEQAPkID+UtSEI/bgRip65ce/PouTAOnKSQVavX VCxIWORqkqgGoIQOtUL+/l9eQHmBFJn99I8IGLpX4qQCFJITSWEUNASjhz2EctyFPYjBbaDjAvAE YZB8bs8R7SS3pitXEKiWDdAu/PU/hDFEr2kyFQYxcENVsXI0gcZimviot6W9KDKKFhLula/4OdcD ER4EQwfH0HeBBRbgol8oP3pH3w3JERCjEG56/OLY2O8/5ed4JU7ag6vTNhLJhCJjDNc9/muaA1bw BNcJMWgXZ/SYHNBeUAqgaCBSATY8rDEM571Ml82vQCZoCd/QaxALVDm4/zu/osCDZy/z7YcXrsJG fktp9Mtq02hcMPobGO5+7KldB06DAxUGPeoMUFACSImNrXzs0ejbyRZfQTYw4Sd0gXELpWFFEQkG FUEPtquzCEiKEl8Nn74EehyDJAcAeHpsEjD5LWfojlWl0TQ2JSHy8IPPUm1bTTMFSjXUuIWE0fOr 9ILpwi5+ptnkox4B30qxOgiICm/fP3cFGLkLGEJL+gt8RFXiycZXBk+AISylc4156J3VQEXqoAF/ +XPf/Isil5Ehuqzj0Bdgyiqg6ThSST0Iwk/4ITDSfJqMNylHc7MYhyJo2TqscQNJtBvEuJ4DzgAO YAJXEA8zQj2PnB89dnmSPcfEVARXKzsqpCFUHrWieu9844cpCQfvfQSeUH8jlgp6gRjghDQ6Yn5I H+lfOBmxjVE3ao6Oq5gFRbcfxO9oM8ETAMUQQtIFX33oJczj0OlLMBMYMaQquOPr5d/wqtolaoXN oVER0ihAStsdU6ToiVUKXQXGCoDci26CzHKvEhxywEnsHuqsamv6gA7cwAqDiSKDrX3NV46vZS9n OKCEZUYPHUEFIB49G8Mr4uoIaRCOZ17crwUTvZR1GreKNGIoAyGVACKV6Jo9J/k5J4FRWPTg4pl6 f6sNnj/f8yF7sDVCWM5hC+gZcREta8BpBQDCloo3KTB87zhN46uu6HXCEAAdQXO+MtZzJAKArx4c kWPUCpchhljmYkx38gL8hIofXRxHc/kIXPRInOQMl3FyeXT545EJOpEKCJpjK8mATIxcTEMaHQon AaGO3u3aVsEQAUD29JRaqVtRtQEQ9dTXq5gYNDQCM8iVoqSeFrbxcuGCcdkgBtqS8PD5a5hEAOTg 21veWAYeYvdAD0Wg6x2TBoBSgnY5aZIKtpFWi0wLeo0YSkLOOFSZK7M6BjMwzQwM7gBwqAxfURPc BzUxIMeDwF7qDJJGj2AImKAHsEAngOwRdXnp7CElW2Etj0POFEAIqUZXvIl511RPO6HXCUDOYzd0 mjTTcSIRC/eVio5HDAUVRhxcBtk4j4/jeiMZoho0lzO0hY+qMPL68fOIg8qlGPHRBNWBuhn51wFE sE5YEteBVDHc9IzQ1Ucfc/OJ1gBQDAHQkzDHaBPLBqNQBC2k0FkHqyR6XM+xpOWAj1DRoBrciKX5 CAk5lnsB4K4PzhmxL3qMTU2oP7pjJjMFMMIJScgQvu5NIuVV4VuljyoYzpVGwzAPbphUhEsAK9XT HFd0qxhyYKQH5VBwR3ND81QEvTePFlhhMwPAfR/+lv3z757lAu61iOiBm4NQKhzVawTQpDHkKcb+ ydgkhMCmK4CeT6EzA8DGrdVfRzctACJ4ExNBQAeAWD9HIqCHVdTzQksQDgDF0AvwXIuCHg0xU4QV Svu3kwrrJak8jE3DwghsnEPppMIc83OUSOi4qSofwzrOmJPRa1QADBVGUAegphAjFgBU+IhtxAfB CqJBXHAKIFr8mxOjpnQWHthQc4oCCn0Ht24H0DiNxoIkNpPBSN0YnrlnnanXRnVGd6i5eae5Mq0d sySyDni5L7AUbvTQOZ1IJPlTADlpBgzQAkD4ph8BQ1NtXMMZbaAA7jx8gT1DPwzvAgG0AlQVRdAa NwJ46UbRQK2fAiAowr9uem1s/ca6Ikf6OkVvdPymsHBTT4YXDvQc9ZisdlhhSMwFkjAFEDEgpECD wBRAc1+aRHgohimAnARh4t6+0aOeRg6wHcWxSnUA0RRCZYwbmCAcT41OIAzzH37w2fd3DcYEaJ2H Qbwde09yL9CAuhIvAukUwHTGBGxh4J1QeeswteK8GAaAfKRTQAkzGCoMejgOb4dJtCPYc/IOgIdK OXzhe0+9zTCw74wNZXJ3ZxaiSimAYqhnASXsG7BwEOKZuhanPIS3Eg/A5aRBYCWlkALoUC6CQLTD JD8VxrdSGZ0LoFFDwh4IwDEhH/UHMZNjNArEIB6QoiyQjZ9jDAPAl4bPIoX27T3ZB3pXr03TLxRI 4fQgKpACGBiqwoBQH4DkCPDCUpgAOBKvPhau6G8kEyKfwHn6ERiNsc2pvrD7KFYOxQFSGgJoHEAG OgudNa8FesYwHNBMzv/gmXdR5EAPEnKmv+GJkzWoJ63jIBhYIWE4kWIA1aSqOeKKzXTCrp5WTfU3 0EuniXVhoATlDFGkJQK7wDAm3zGJxDPD8yF0iBiyR5EFUIHAlNkH/ehBIwEwTA1Lox+BhLFgpg9x nKLPTaFrtH6VmeLUBWtSOCaOAhPMApA6beeYF0V2KDeUAKgL5sDxDhiiyEBHUM3+iR3v0ws9TaPE SJyaCKATCi0Y4og5ro+Ce8BwwxbzBnX06tavHkKHbbF6umD9iGbQQFov3AigguOAPD97/QSKDIDI L//7zH2P7My3hEAN4PuHTnE7cNOVRH3aSVjJqfYqxDzmvlrQa6FfJYBxBMcxg18TCy0ARhTN/oHS qYGbJES0hJkDZKCG8EaexaB76zAAWp8KhpWsAnswbBwF94DhF79lDraCXgXA+jqZTgDidtFiAMGP CGAFvQAQ9BSd77rHfy2AIPn0m6eKLsgYINPv2F5iSCNPagL/8WuNAKYY2hxjwr69iQKH8enltNEt eqQxjZ+JHgJonKEJWDY+pgCmeZgA0AgQxHAoqDMYbhscAcNvb3kDa9YVQHO/3CJiTphv7rGCYSWe SRW5v5CmUZ0dFfbBvRRA9MigQvfRor8RAYIhtgsMN+/7CBKCJwfg0DXD4OIKqqGtEEOzFlG3Cgnr yZkiqdU0gutHnV/cT48gde7lAAh66hHt0i5VVDjoFwBG9AKGGkMYCICIU8kt6GEk0V+wCmNrAjxG Q10VOTwydszF/ItFxUbu5aCH8BH9xRFH+NdIvxRAfYegMaIPAIGiJUVz4MhVk7TO8pv64Poipjp0 ziCtlFvJ4rRbplgxUxynSftiaMwAecGCQXDUrGeRey7ZapqUvzU/AX1LVw4BwBAPApcqESDoFRH4 7z9FZRS6viJcb0YRVL/60EtEiQ6aGjdCdBCGeJTZ1VrGhoGi66lz/k/63sBK4uUP8F3doSPGnsfw TQDzM37wk2hw4CtPtuRnQA+qU75DP/1vrJCv703ZmSd0QrDrT/rbIw6moFkKoJat008YCAvgcDns BUBYlAKI5qosLeXQHJ8FwCQS2JhzaESP+BkDCAmLdRolA/m5K8o6CQN2AcTICGDXn/QtNCQAxGI4 ceYEeifR4AeAWCfCM9Q5nQQRQIxbSznyBGqhwgjANgKIg6aSlEnhAojj6BXArj9ZIIAYCr2GAMai wUZx8MXFQ2XoAj2gMQCm7kMA28vB/lMOFYB+RIP0WuOQBJzxUxauCnelkzVcHgZScgCIxchnoOst YaBJlZhCchJTANvLkYEQDwCJBiGhZyqbDwpZPv4on4F4YbybALoCaikEktQBzGEgF6cMbAQwh4FO 7AIgltCGVzYuYMjs1IAAZjIQAImvXIdGyVpjp8Nir7SbmoFy7ZlXpr/y2Dr7IEOvDDRuAUDsWDp/ hF/IZyAqzDEqjLjIpLI5WuRGAWA+AwPAuflFzulBHEPy9gK5IK3S7WTVtFsFwEwGmgkUQBto8Lzz UBYDBRDQ4B76C4CVerqZQ9C598RAVyMzUC2e3dh70vWoLqqMSTqjDh/L6gqgc0k+F0YfYZBNcHFS e4vkM9AlbXUAHXcQB2Yy0MyqAxOQqfsR5xMtvCcGAiAMRJznEs90uMexXokIKgdAKF3M/pwbpfxY aW9qNAZrgJzJQAFEAsB05JtvAwFQD0I4jbZWInC62zjTwntlYPH8S/lYgbjFgDRgFMBMBgogIt/g YcA4XA4z+UoAMxloul4AVTEnf2lvvg0UQOgHCSmqkuF3PYAAUjhNyGeg68d8FMhFFCmAiuPHTAYy Ak3nsIiETUu69JRa7TpwOt8GfnRxXACLR29KANO8gSqcz0D8rA+/VB5VNg3INRYugJkMxDqBDHVw xj8kTYz0xMCpfUOA5prSEFfdx9ylrMhhoAAiXPzcniNp3u/5d3tgIBcDIAKANLb+rDeFcI2FQ6p8 BhLbu4zW9Z8YwwqMAWAmAyfue3Ryw5YPLt4IDC0KKEypvXn0Tg0zGahdQvUw8jrfABAm5zMQJ/Kz 10986f5tFFUH0CUiAtgTA8GZCqDFkX8TRsW8nAs2Mhno1N7Y+o3FE+uXJy0hxPK14Zk2EMfhAzjO GS3EBv7k1WP4Ea6vA2iewTnlnhjo/LUPsJiDTcUm65XyGWgqlYO33jvls0VpmdxFAHMY+MrgCbSD voM2MMSnG+CSGRh9QT4DAZBosBHAgTLMTgHMZGCs98Y+Ryq7giT+tFcGRlb//V2DqHO6tgpx5JjD QG4KZ1zi6OIEfTongQIAe2WgANbn2SmfCEfL0BMD9w+dGirXbJvNlocphhz0x0Bl9PNfO/bLPWB4 +Py1CoA5DORXsILx4ANP7DFLjzo75xtDuZ4YSCSD0tUzsT6dSvm9MtCULzYweJhiqPTNwBDcCuWI IffKt4GHzl/HBdPk7z31dpg+Zz1obE8jERnYaSQi34hzuBJM8hnoYNNMr49aYHZiXi8FsD8GprNL mEQAiZw5sHTtX1TAiXJMn7Gfc+VOl/caB5qNaRwLm67hW8oXwEwGxmBThqAsmGsffjERxz6fgTQn Xi3VONGJSQTDnJSvOROuxHHUl7uAHmycK0dhPkDRSbiAWjk1DAMxBY3ZGNeIciMu64mBMdhEwAoM fT6XHo+lFMZFmQw8Mzp+8MfPt6xb4FtGK3Pd0jvAoqnHSmPetw2OCJ3zvKCnHaCeLYXQEJ9kBP9w Io35QHB2pMwFVi+TgTFWCgFDRl7cGiQloUY10wbeUf8fP9+yTslXTmGd2gtEHUwEOb8ZKzqsz9z8 ExwtYiYcQNRfBH1vzEgzmsOkYANp+G9OjOYz0FC/giEIOBWLZ3n14Igal8lAW4qeoq2dMDxzz7o/ XR7vav8HylS2Rqyy+U6bduUdKB+M4mIAET0zWo3PgsFnxshc4ItW8hmIngpgLFN0b+5XkxghWQ6A 9Eg8A9hpjfqVck3mXDmR2l5mwMjdTTD6wJ3vAmoX54/Y1F/2hMpObzVuMAQLCYa4gHwG4uZiiJQi iagvFIudyWdgPACIwEOY3IhhvLNr6WayIhCSfo7jGj2IG9ejcRhYotZ8BgIg3s00TsBY4SR+IZ+B UDrtBX5eGIGm1UpaQpQxh069ipXBeIb7gFoDrSsTXJvKZT15YVQ1AKzDqJwfv57PQHxQCqB9QbG7 H3uqjqEL1Km5kz6LIhhGjRjKG1ksAMTD0lPti6VhHWougF2rJIAoaTEsms8RpUiGWGAmA6F0Cn50 CjDWXbNvZpgrF/lTn64Tf10F2rgIkAIjeAY9BjJ+274sx2gQPzg3H1r7QFmjqMICeGdN3aG/POZT B1Cv16m06Hco3dgLDsQYF9cXzqHL/lcCrcPnOoXa1cOmlKu8o6xYmj44EqELYtd0XeVLvMGVhjGZ GwD6OEAVw3lCshfA/ALjgTUPolPMAMC0I19+sB7Y3Hx6Z/oqSCJbujjeLEqQFoJyPVQOKACNoC7m ZOfKkI+bptCF8uY87EAPukbL9cmUjE8sX/p3K32ckLpRlMeg7fgofTglxZM9jqy+fi8OCGtpha8W xOwAYKUX0oWjYohrrrzqJ1I3uBuXFOZ32VxJORuSQhfouea8xf+mm28n8Ld4ZHQf8PEsjoDc481N OzgqF8AWGOvMTCnKtz6d4ROmFOKygcZy4i67DpzGrXSKtDkPmM4OgCdxRbpsEo0wKcHdqT8treBm 89mDHhXzWZvGAUh9gxIYBFwJJSA4ccB3jOxKV8MhAKQh4KmIZAXMFjwr2NIQLjZv7OT1z/d8qNpG CqVRGnlYF1T+2Z/sjNFE7DsJraaB1EQugQYBXv6qThSE39oFwghinkkBNKchLdthzAQTuLiMplFb aM+eu9AWv5LwFvXcniMAMnjvIznoBSe5HpPYgpvQsX+gXIsFc0TA/FImenOlJQR51CowdFIeoXw+ 8m0KYIqhMAaYJkA68acTyMAFA12MR+XRI27HfYuStx9Gc/tewQ6MkBYjX1dYmwn5nXez7zjpO3ky H1OKDf+l2qYGQTMlmJQPbtwCCRjrYKa07EkAU0JyOx8o/u4XHkMTF/IoWeqy6QVgDOtHc+Cb0MGc aLL06+MlHuZptYSBobZUSQEMGLuC2Q5s5Xzx85JvC3mGsSuM9I6zTvI8ZaPZA77tlX5uwO6jOimG 0m+gTP5rD3U0dakgmSkFhtsPY99QtMXiW1elhtt4fxW2otrFU+dN2bDMjfgTYmtXK7rs893etAXG XpEEQFjR6S0BSyRQkS5LmxnJ50jJ9rf50hgNeD0y93G86LgUyRY8U2Wv7ANtmrNYDzp1pZ8+pcI9 B7/wZOGvq/U1PpXCXaiJgCEeP1XzFMmu5GxBGC+cGeMtBDp6KixeXct6fdK/cYPAjBxTRTa0Rmim UwC65roBqTCzBdjK+fhVy1hjoazbOtw4AAkVo9X9+Y76ZsYSvkVmG9Zxi3DNhtmqc3uYWg+9UtAa hZbWUwd92zp6RNa1BNK0lOa0PBPXx8YwMIxhOPeUZsSfaeieD2MOzuwXQkXwV1u73ssRHC1diOft tPkqSNfIOU50rUjc2hmroOLiwoj0NHZz4CbfMvtUbaL+zuAs+oYxdKXT5vkAqe6dN5ejSHoQKgr1 UlAx00EbmfTUj85lLwV6btOzt77/o9ewflQMJFHbRscBsMb2XJDZ+z3BCEMyHTRo53eNC7AXy3F0 2nwrheiZW2isj3GUWVwM5ub5LMdiCaU9/OCzOVaxyMDUUgd19HzP+fK8GR4e+v8+JlrbK2ZyI3I7 i8JG0LNYyszRaAcaLVlTX6O3nO+En5qZddLT9wm0NxaQNYyG30HR/vTXFXp4fC1wodFbh7v6aL6t q7New3eRLf+/EuhTYkTc3mph9CkVE866mJ5gFC77InKVIcCIYWyHkXgm4ueIJTb94p2V+k8H7rtj 70kfQ84hVSg1Gh3po66BdPpbx+Cd/LtsbPcvxtKby2jBwdpSe4327fb8K7JpWmbc4jVAJxq0graY iIsxXaMdkL1p8NkJ6q5sfPlz38QHLUW03N929tKkr73N9xSh17DXmS9+DpJmgysZHk72NMzxGqOd TpkxqDi56ZnV80fJhTqXL76WivluwmSCSDqm1t24Tgwx0863przSbEMdtEqOgjOYOCKZxpdaX5l/ 19nqgdG3Z6uVm3uJ/Wy1x6izQaaLLgbKdXqcgYeIqFbwDzD9lhIA3OejDekp57tfeGzivkcbCTm2 fiMwrpK/nMYqHjhy1RWMkSrM97YiqYWkI8w6PlBOW8R0jMZQESKpq3iBz9H4Q1/ZdPj8Neo2tW9o csOWOoxQcVVpNEFpvKPYoCXlWCfoDMx0LjGaTjkmweQYAiEpHAFkzwQ/ORY9ujL98ylXnMI34PI9 wxXDWFlgs7KbMPpKWNoS04UpJ+Nj+OV2K9qYpE2NHneRk/g1dKFlfAFQEBL9rYxlAJbzqwrGj0cm 4sFzXW3YMQNsI0NYF5FhV00P3CyEMl2CUjyZvnX46rXpnPAYNv55agasKoR0XQ0wrmyUWNkMGv3T 0vu/8yut00D5LIbWMqaWuk4BqKSGQJRDaeKGF+v7L2mCkP/vacf1Gznp4sPVs30yPXPyzPWX3ziO y8ZGiaRPqYCkjgNGada0dZyBqE4lhJvwpWQv7D7qcrtFqRswIljCyn+GrjY2ut2e/4MbTGX807qv /vavluWq/03jH1gzeOTi8k9t7vxpy1K0S18jkhH8rKpoZw1twBheGyRhZgHjKlPq1b9BPMQwsgga N2wpbONdNva1hbtBwVehi1krG/QTSan4fwSadcMNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMyAwIG9i ag0KPDwvVGl0bGUob0xTOiBDbG9zdXJlIG9mIHRoZSBhZC1ob2MgZ3JvdXAgb24gTVBMUy1UUCkg L0F1dGhvcihTRzE1IENoYWlybWFuKSAvS2V5d29yZHMoMywgOSwgMTAsIDEyLCAxNC8xNSkgL0Ny ZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAFcAbwByAGQAIAAyADAAMQAwKSAvQ3JlYXRp b25EYXRlKEQ6MjAxMzAxMTcyMzQyMzUrMDEnMDAnKSAvTW9kRGF0ZShEOjIwMTMwMTE3MjM0MjM1 KzAxJzAwJykgL1Byb2R1Y2VyKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABXAG8AcgBkACAAMgAw ADEAMCkgPj4NCmVuZG9iag0KMjQgMCBvYmoNCjw8L1R5cGUvU3RydWN0VHJlZVJvb3QvUm9sZU1h cCAyNSAwIFIvUGFyZW50VHJlZSAyNiAwIFIvS1sgMjcgMCBSXSAvUGFyZW50VHJlZU5leHRLZXkg Mj4+DQplbmRvYmoNCjI1IDAgb2JqDQo8PC9Gb290bm90ZS9Ob3RlL0VuZG5vdGUvTm90ZS9UZXh0 Ym94L1NlY3QvSGVhZGVyL1NlY3QvRm9vdGVyL1NlY3QvSW5saW5lU2hhcGUvU2VjdC9Bbm5vdGF0 aW9uL1NlY3QvQXJ0aWZhY3QvU2VjdC9Xb3JrYm9vay9Eb2N1bWVudC9Xb3Jrc2hlZXQvUGFydC9N YWNyb3NoZWV0L1BhcnQvQ2hhcnRzaGVldC9QYXJ0L0RpYWxvZ3NoZWV0L1BhcnQvU2xpZGUvUGFy dC9DaGFydC9TZWN0L0RpYWdyYW0vRmlndXJlPj4NCmVuZG9iag0KMjYgMCBvYmoNCjw8L051bXNb IDAgMzIgMCBSIDEgMTExIDAgUl0gPj4NCmVuZG9iag0KMjcgMCBvYmoNCjw8L1AgMjQgMCBSL1Mv UGFydC9UeXBlL1N0cnVjdEVsZW0vS1sgMjggMCBSIDEyMCAwIFIgMTIxIDAgUiAxMjIgMCBSIDEy MyAwIFIgMTM0IDAgUiAxMzUgMCBSIDEzNiAwIFJdID4+DQplbmRvYmoNCjI4IDAgb2JqDQo8PC9Q IDI3IDAgUi9TL1RhYmxlL1R5cGUvU3RydWN0RWxlbS9LWyAyOSAwIFIgMzcgMCBSIDQ0IDAgUiA1 MCAwIFIgNTggMCBSIDYxIDAgUiA2NiAwIFIgNzEgMCBSIDc1IDAgUiA4MCAwIFIgODUgMCBSIDkw IDAgUiA5NSAwIFIgMTAwIDAgUiAxMTYgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQoyOSAwIG9i ag0KPDwvUCAyOCAwIFIvUy9UUi9UeXBlL1N0cnVjdEVsZW0vS1sgMzAgMCBSIDMzIDAgUiAzNSAw IFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjMwIDAgb2JqDQo8PC9QIDI5IDAgUi9TL1REL1R5cGUv U3RydWN0RWxlbS9LWyAzMSAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjMxIDAgb2JqDQo8PC9Q IDMwIDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDBdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjMy IDAgb2JqDQpbIDMxIDAgUiAzNCAwIFIgMzYgMCBSIDQwIDAgUiA0MSAwIFIgNDMgMCBSIDQ4IDAg UiA0OSAwIFIgNTIgMCBSIDU0IDAgUiA1NiAwIFIgNTcgMCBSIDYwIDAgUiA2MyAwIFIgNjUgMCBS IDY4IDAgUiA3MCAwIFIgNzMgMCBSIDc0IDAgUiA3NyAwIFIgNzkgMCBSIDgyIDAgUiA4NCAwIFIg ODcgMCBSIDg5IDAgUiA5MiAwIFIgOTQgMCBSIDk3IDAgUiA5OSAwIFIgMTAyIDAgUiAxMDQgMCBS IDEwNSAwIFIgMTA2IDAgUiAxMDggMCBSIDExMCAwIFIgMTEzIDAgUiAxMTQgMCBSIDExNSAwIFIg MTE4IDAgUiAxMTkgMCBSIDEyMSAwIFIgMTIyIDAgUiAxMjUgMCBSIDEyNyAwIFIgMTI5IDAgUiAx MzEgMCBSIDEzMyAwIFIgMTM0IDAgUiAxMzUgMCBSIDEzNiAwIFIgMTIwIDAgUl0gDQplbmRvYmoN CjMzIDAgb2JqDQo8PC9QIDI5IDAgUi9TL1REL1R5cGUvU3RydWN0RWxlbS9LWyAzNCAwIFJdIC9Q ZyAzIDAgUj4+DQplbmRvYmoNCjM0IDAgb2JqDQo8PC9QIDMzIDAgUi9TL1AvVHlwZS9TdHJ1Y3RF bGVtL0tbIDFdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjM1IDAgb2JqDQo8PC9QIDI5IDAgUi9TL1RE L1R5cGUvU3RydWN0RWxlbS9LWyAzNiAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjM2IDAgb2Jq DQo8PC9QIDM1IDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDJdIC9QZyAzIDAgUj4+DQplbmRv YmoNCjM3IDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyAzOCAwIFIg MzkgMCBSIDQyIDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMzggMCBvYmoNCjw8L1AgMzcgMCBS L1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQozOSAwIG9iag0K PDwvUCAzNyAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgNDAgMCBSIDQxIDAgUl0gL1BnIDMg MCBSPj4NCmVuZG9iag0KNDAgMCBvYmoNCjw8L1AgMzkgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0v S1sgM10gL1BnIDMgMCBSPj4NCmVuZG9iag0KNDEgMCBvYmoNCjw8L1AgMzkgMCBSL1MvUC9UeXBl L1N0cnVjdEVsZW0vS1sgNF0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNDIgMCBvYmoNCjw8L1AgMzcg MCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQzIDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0K NDMgMCBvYmoNCjw8L1AgNDIgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgNV0gL1BnIDMgMCBS Pj4NCmVuZG9iag0KNDQgMCBvYmoNCjw8L1AgMjggMCBSL1MvVFIvVHlwZS9TdHJ1Y3RFbGVtL0tb IDQ1IDAgUiA0NiAwIFIgNDcgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo0NSAwIG9iag0KPDwv UCA0NCAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1tdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjQ2 IDAgb2JqDQo8PC9QIDQ0IDAgUi9TL1REL1R5cGUvU3RydWN0RWxlbS9LW10gL1BnIDMgMCBSPj4N CmVuZG9iag0KNDcgMCBvYmoNCjw8L1AgNDQgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQ4 IDAgUiA0OSAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjQ4IDAgb2JqDQo8PC9QIDQ3IDAgUi9T L1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDZdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjQ5IDAgb2JqDQo8 PC9QIDQ3IDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDddIC9QZyAzIDAgUj4+DQplbmRvYmoN CjUwIDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA1MSAwIFIgNTMg MCBSIDU1IDAgUiA1NyAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjUxIDAgb2JqDQo8PC9QIDUw IDAgUi9TL1REL1R5cGUvU3RydWN0RWxlbS9LWyA1MiAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoN CjUyIDAgb2JqDQo8PC9QIDUxIDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDhdIC9QZyAzIDAg Uj4+DQplbmRvYmoNCjUzIDAgb2JqDQo8PC9QIDUwIDAgUi9TL1REL1R5cGUvU3RydWN0RWxlbS9L WyA1NCAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjU0IDAgb2JqDQo8PC9QIDUzIDAgUi9TL1Av VHlwZS9TdHJ1Y3RFbGVtL0tbIDldIC9QZyAzIDAgUj4+DQplbmRvYmoNCjU1IDAgb2JqDQo8PC9Q IDUwIDAgUi9TL1REL1R5cGUvU3RydWN0RWxlbS9LWyA1NiAwIFJdIC9QZyAzIDAgUj4+DQplbmRv YmoNCjU2IDAgb2JqDQo8PC9QIDU1IDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDEwXSAvUGcg MyAwIFI+Pg0KZW5kb2JqDQo1NyAwIG9iag0KPDwvUCA1MCAwIFIvUy9TcGFuL1R5cGUvU3RydWN0 RWxlbS9QZyAzIDAgUi9LIDExPj4NCmVuZG9iag0KNTggMCBvYmoNCjw8L1AgMjggMCBSL1MvVFIv VHlwZS9TdHJ1Y3RFbGVtL0tbIDU5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNTkgMCBvYmoN Cjw8L1AgNTggMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDYwIDAgUl0gL1BnIDMgMCBSPj4N CmVuZG9iag0KNjAgMCBvYmoNCjw8L1AgNTkgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMTJd IC9QZyAzIDAgUj4+DQplbmRvYmoNCjYxIDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3Ry dWN0RWxlbS9LWyA2MiAwIFIgNjQgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo2MiAwIG9iag0K PDwvUCA2MSAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgNjMgMCBSXSAvUGcgMyAwIFI+Pg0K ZW5kb2JqDQo2MyAwIG9iag0KPDwvUCA2MiAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAxM10g L1BnIDMgMCBSPj4NCmVuZG9iag0KNjQgMCBvYmoNCjw8L1AgNjEgMCBSL1MvVEQvVHlwZS9TdHJ1 Y3RFbGVtL0tbIDY1IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNjUgMCBvYmoNCjw8L1AgNjQg MCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMTRdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjY2IDAg b2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA2NyAwIFIgNjkgMCBSXSAv UGcgMyAwIFI+Pg0KZW5kb2JqDQo2NyAwIG9iag0KPDwvUCA2NiAwIFIvUy9URC9UeXBlL1N0cnVj dEVsZW0vS1sgNjggMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo2OCAwIG9iag0KPDwvUCA2NyAw IFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAxNV0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNjkgMCBv YmoNCjw8L1AgNjYgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDcwIDAgUl0gL1BnIDMgMCBS Pj4NCmVuZG9iag0KNzAgMCBvYmoNCjw8L1AgNjkgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sg MTZdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjcxIDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUv U3RydWN0RWxlbS9LWyA3MiAwIFIgNzQgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo3MiAwIG9i ag0KPDwvUCA3MSAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgNzMgMCBSXSAvUGcgMyAwIFI+ Pg0KZW5kb2JqDQo3MyAwIG9iag0KPDwvUCA3MiAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAx N10gL1BnIDMgMCBSPj4NCmVuZG9iag0KNzQgMCBvYmoNCjw8L1AgNzEgMCBSL1MvU3Bhbi9UeXBl L1N0cnVjdEVsZW0vUGcgMyAwIFIvSyAxOD4+DQplbmRvYmoNCjc1IDAgb2JqDQo8PC9QIDI4IDAg Ui9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA3NiAwIFIgNzggMCBSXSAvUGcgMyAwIFI+Pg0KZW5k b2JqDQo3NiAwIG9iag0KPDwvUCA3NSAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgNzcgMCBS XSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo3NyAwIG9iag0KPDwvUCA3NiAwIFIvUy9QL1R5cGUvU3Ry dWN0RWxlbS9LWyAxOV0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNzggMCBvYmoNCjw8L1AgNzUgMCBS L1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDc5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNzkg MCBvYmoNCjw8L1AgNzggMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMjBdIC9QZyAzIDAgUj4+ DQplbmRvYmoNCjgwIDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA4 MSAwIFIgODMgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo4MSAwIG9iag0KPDwvUCA4MCAwIFIv Uy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgODIgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo4MiAw IG9iag0KPDwvUCA4MSAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAyMV0gL1BnIDMgMCBSPj4N CmVuZG9iag0KODMgMCBvYmoNCjw8L1AgODAgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDg0 IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KODQgMCBvYmoNCjw8L1AgODMgMCBSL1MvUC9UeXBl L1N0cnVjdEVsZW0vS1sgMjJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjg1IDAgb2JqDQo8PC9QIDI4 IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA4NiAwIFIgODggMCBSXSAvUGcgMyAwIFI+Pg0K ZW5kb2JqDQo4NiAwIG9iag0KPDwvUCA4NSAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgODcg MCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo4NyAwIG9iag0KPDwvUCA4NiAwIFIvUy9QL1R5cGUv U3RydWN0RWxlbS9LWyAyM10gL1BnIDMgMCBSPj4NCmVuZG9iag0KODggMCBvYmoNCjw8L1AgODUg MCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDg5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0K ODkgMCBvYmoNCjw8L1AgODggMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMjRdIC9QZyAzIDAg Uj4+DQplbmRvYmoNCjkwIDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9L WyA5MSAwIFIgOTMgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo5MSAwIG9iag0KPDwvUCA5MCAw IFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgOTIgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo5 MiAwIG9iag0KPDwvUCA5MSAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAyNV0gL1BnIDMgMCBS Pj4NCmVuZG9iag0KOTMgMCBvYmoNCjw8L1AgOTAgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tb IDk0IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KOTQgMCBvYmoNCjw8L1AgOTMgMCBSL1MvUC9U eXBlL1N0cnVjdEVsZW0vS1sgMjZdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjk1IDAgb2JqDQo8PC9Q IDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA5NiAwIFIgOTggMCBSXSAvUGcgMyAwIFI+ Pg0KZW5kb2JqDQo5NiAwIG9iag0KPDwvUCA5NSAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sg OTcgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo5NyAwIG9iag0KPDwvUCA5NiAwIFIvUy9QL1R5 cGUvU3RydWN0RWxlbS9LWyAyN10gL1BnIDMgMCBSPj4NCmVuZG9iag0KOTggMCBvYmoNCjw8L1Ag OTUgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDk5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9i ag0KOTkgMCBvYmoNCjw8L1AgOTggMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMjhdIC9QZyAz IDAgUj4+DQplbmRvYmoNCjEwMCAwIG9iag0KPDwvUCAyOCAwIFIvUy9UUi9UeXBlL1N0cnVjdEVs ZW0vS1sgMTAxIDAgUiAxMDMgMCBSIDEwNyAwIFIgMTE1IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9i ag0KMTAxIDAgb2JqDQo8PC9QIDEwMCAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgMTAyIDAg Ul0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTAyIDAgb2JqDQo8PC9QIDEwMSAwIFIvUy9QL1R5cGUv U3RydWN0RWxlbS9LWyAyOV0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTAzIDAgb2JqDQo8PC9QIDEw MCAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgMTA0IDAgUiAxMDUgMCBSIDEwNiAwIFJdIC9Q ZyAzIDAgUj4+DQplbmRvYmoNCjEwNCAwIG9iag0KPDwvUCAxMDMgMCBSL1MvUC9UeXBlL1N0cnVj dEVsZW0vS1sgMzBdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEwNSAwIG9iag0KPDwvUCAxMDMgMCBS L1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMzFdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEwNiAwIG9i ag0KPDwvUCAxMDMgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMzJdIC9QZyAzIDAgUj4+DQpl bmRvYmoNCjEwNyAwIG9iag0KPDwvUCAxMDAgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDEw OCAwIFIgMTA5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTA4IDAgb2JqDQo8PC9QIDEwNyAw IFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAzM10gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTA5IDAg b2JqDQo8PC9QIDEwNyAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAxMTAgMCBSIDExMSAwIFIg MTE0IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTEwIDAgb2JqDQo8PC9QIDEwOSAwIFIvUy9T cGFuL1R5cGUvU3RydWN0RWxlbS9QZyAzIDAgUi9LIDM0Pj4NCmVuZG9iag0KMTExIDAgb2JqDQo8 PC9QIDEwOSAwIFIvUy9MaW5rL1R5cGUvU3RydWN0RWxlbS9LWyAxMTIgMCBSIDExMyAwIFJdIC9Q ZyAzIDAgUj4+DQplbmRvYmoNCjExMiAwIG9iag0KPDwvVHlwZS9PQkpSL09iaiAxNCAwIFIvUGcg MyAwIFI+Pg0KZW5kb2JqDQoxMTMgMCBvYmoNCjw8L1AgMTExIDAgUi9TL1NwYW4vVHlwZS9TdHJ1 Y3RFbGVtL1BnIDMgMCBSL0sgMzU+Pg0KZW5kb2JqDQoxMTQgMCBvYmoNCjw8L1AgMTA5IDAgUi9T L1NwYW4vVHlwZS9TdHJ1Y3RFbGVtL1BnIDMgMCBSL0sgMzY+Pg0KZW5kb2JqDQoxMTUgMCBvYmoN Cjw8L1AgMTAwIDAgUi9TL1NwYW4vVHlwZS9TdHJ1Y3RFbGVtL1BnIDMgMCBSL0sgMzc+Pg0KZW5k b2JqDQoxMTYgMCBvYmoNCjw8L1AgMjggMCBSL1MvVFIvVHlwZS9TdHJ1Y3RFbGVtL0tbIDExNyAw IFIgMTE5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTE3IDAgb2JqDQo8PC9QIDExNiAwIFIv Uy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgMTE4IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTE4 IDAgb2JqDQo8PC9QIDExNyAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAzOF0gL1BnIDMgMCBS Pj4NCmVuZG9iag0KMTE5IDAgb2JqDQo8PC9QIDExNiAwIFIvUy9TcGFuL1R5cGUvU3RydWN0RWxl bS9QZyAzIDAgUi9LIDM5Pj4NCmVuZG9iag0KMTIwIDAgb2JqDQo8PC9QIDI3IDAgUi9TL0ZpZ3Vy ZS9BbHQoaXR1LW9sZCkgL1R5cGUvU3RydWN0RWxlbS9LWyA1MF0gL1BnIDMgMCBSPj4NCmVuZG9i ag0KMTIxIDAgb2JqDQo8PC9QIDI3IDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQwXSAvUGcg MyAwIFI+Pg0KZW5kb2JqDQoxMjIgMCBvYmoNCjw8L1AgMjcgMCBSL1MvUC9UeXBlL1N0cnVjdEVs ZW0vS1sgNDFdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEyMyAwIG9iag0KPDwvUCAyNyAwIFIvUy9M L1R5cGUvU3RydWN0RWxlbS9LWyAxMjQgMCBSIDEyNiAwIFIgMTI4IDAgUiAxMzAgMCBSIDEzMiAw IFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEyNCAwIG9iag0KPDwvUCAxMjMgMCBSL1MvTEkvVHlw ZS9TdHJ1Y3RFbGVtL0tbIDEyNSAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEyNSAwIG9iag0K PDwvUCAxMjQgMCBSL1MvTEJvZHkvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQyXSAvUGcgMyAwIFI+Pg0K ZW5kb2JqDQoxMjYgMCBvYmoNCjw8L1AgMTIzIDAgUi9TL0xJL1R5cGUvU3RydWN0RWxlbS9LWyAx MjcgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQoxMjcgMCBvYmoNCjw8L1AgMTI2IDAgUi9TL0xC b2R5L1R5cGUvU3RydWN0RWxlbS9LWyA0M10gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTI4IDAgb2Jq DQo8PC9QIDEyMyAwIFIvUy9MSS9UeXBlL1N0cnVjdEVsZW0vS1sgMTI5IDAgUl0gL1BnIDMgMCBS Pj4NCmVuZG9iag0KMTI5IDAgb2JqDQo8PC9QIDEyOCAwIFIvUy9MQm9keS9UeXBlL1N0cnVjdEVs ZW0vS1sgNDRdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEzMCAwIG9iag0KPDwvUCAxMjMgMCBSL1Mv TEkvVHlwZS9TdHJ1Y3RFbGVtL0tbIDEzMSAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEzMSAw IG9iag0KPDwvUCAxMzAgMCBSL1MvTEJvZHkvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQ1XSAvUGcgMyAw IFI+Pg0KZW5kb2JqDQoxMzIgMCBvYmoNCjw8L1AgMTIzIDAgUi9TL0xJL1R5cGUvU3RydWN0RWxl bS9LWyAxMzMgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQoxMzMgMCBvYmoNCjw8L1AgMTMyIDAg Ui9TL0xCb2R5L1R5cGUvU3RydWN0RWxlbS9LWyA0Nl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTM0 IDAgb2JqDQo8PC9QIDI3IDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQ3XSAvUGcgMyAwIFI+ Pg0KZW5kb2JqDQoxMzUgMCBvYmoNCjw8L1AgMjcgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sg NDhdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEzNiAwIG9iag0KPDwvUCAyNyAwIFIvUy9QL1R5cGUv U3RydWN0RWxlbS9LWyA0OV0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTM3IDAgb2JqDQo8PC9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIyND4+DQpzdHJlYW0NCnicXZDBasMwDIbvfgod20Nx0l1D YGsZ5LBuLNsDOLaSGRbZKM4hbz/ZCx1MYIP8/5/4LX3prh35BPqNg+0xwejJMS5hZYsw4ORJ1RU4 b9PeldvOJiotcL8tCeeOxqCaBvS7iEviDQ6PLgx4VPqVHbKnCQ6fl176fo3xG2ekBJVqW3A4yqAX E29mRtAFO3VOdJ+2kzB/jo8tIpxLX/+GscHhEo1FNjShaiqpFppnqVYhuX/6Tg2j/TKc3U+1uM9V /VDc+3vm8vfuoezKLHnKDkqQHMET3tcUQ8xUPj8JSW8rDQplbmRzdHJlYW0NCmVuZG9iag0KMTM4 IDAgb2JqDQo8PC9NZXRhZGF0YSAxMzkgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzIw MzAvTGVuZ3RoMSAxNTUzNDQ+Pg0Kc3RyZWFtDQp4nOx9CWBURdbuqarbS5ZOOhsJCdCddAghTUjo EAhb0llZQiBAgASBJCwx7GERAR0JqIMEGTPu4AIqKqMz0umgBhCN4riigI4jogMoqKggjCM6suS+ r6rDNuP/Zt485/m/+ftczndO1TlVdWq5des2nYQYEUUDNKorGDN08MuvJh0nXlBOFLtkcEFhkTbM WE3M8RoRPzy4dOSYsrMHf0ksaTPRJwsGjxmbN9+QMZl4QCeiAbHDxpQVzUmZYUT5LNTaZXjZmCH3 VbqLiQbdRBTad+SYNFeHqWMfIWJ/hb2qNH942fXRN51B/Y1I9xlXUFI+5qm54UTDnyMKu3PqnOq6 9INzMogml6L9d6YuXmRf9MkPDxAt201k7lFTd/Wcvg8usRJVJxIZc66uXlhHkRSA+upRn/Xq2Utr nrk3aDvRSrS34GDt9Oppn5Tt3Yb2r5ft1SIjQuvQjPRWpBNr5yxasmtNyBG0hf4PSJk1fcFc7qJE YpFu+PDZ86ZWZy0af5zo9H50r3ZO9ZK6mIGRRbAhTfa51XOmdxl2bAKxqAKikLi6eQsX6Ym0C/FU SXvdgul1vLIqmejqaUQRtSTH3rhn4it2Y0ll6MDT5o5mkvTwkcwiKXc/vSLu7Orzt1rJvAC+Acpf EqQpvq2Qxlvp7OozQVa6aGmnkCkyJzSD6klQD+K4rJRG4zBq96FdDqsQM/lzZCCzYb0BI8y6+qTY SDU8nBk4NwuTwcCFdphS9FZako9qA2TdZSX5dsJ1lhtmtRWxDFM82+Empus6Sj9uGC57SpHGfqyT 9OYX+Anaos0nD/0IwTYa3PHv8okm8H7ENaJh4FVg1wUb9MLLfZHOkW38WP2SDK9iBHxyFDjOMI66 a0eop7EfjZH5ojN1v+g7jpJMa6k7/DrDXirzpEQ6SVtIM2EfBj3979oYR/H/VfuIb6JqZy2NQB0j IUci3jzklyBdhH6mXOx3P3Ian6DhMl/1fSF1ay9bjDhHoZyMIwe2iMvqD/uv2vbTv0Ya6Sf/GT82 rm3VFeUW0gBwn586nsvXyMW8J7C/+MlPfvKTn/zkJz/9BMTu1rf/3DH8s6R99v9PrH7yk5/89HMS I327GWwl/77pJz/5yU9+8pOf/OQnP/nJT37yk5/85Cc/+clPfvKTn/zkJz/5yU9+8pOf/OSn/4nU 9iaR3hnyz5flHf8bn2P/b2O6ksTHlCdqaTik+2LeR5R2uY/8mSmtH13NX9Q/v/xnq1Dm73+2qh+l aB7qZJxKVuMS389SKVs/ClSygEZom6ij2EUhYi2FQB+hfU6RvIyiL9YLm2EpWbXr9FPaNzREnKNI KbXVFCnuQHofddZupHBtEIVfrL8X0l2p8085Nv9d6fKx8tP/HOKbqQu4DlxwWV7O3/gMANvA88GF l+W7/8ZvoJTml2nYvzlsP/1kFJphYozdZVQJoxImk1EqUjdG+ry6UqwxYnQ2ZRFFloVaKCc6pIsy HfDZh1PM8Ji7Og3HJp+5dvjw4ZQZaxw+lmjdvyNk40VN/uzxVVf9mE/XC2Y/+elK+j9YFd3/sYuf /knCLvNzh+AnP/nJT37yk5/89H9F6jwjjzT/6FjDOl1wvFQkjTGHVJkii8+mgaOVy79+UrL8yyV/ CrrUwctGJ/1nDenfRoKEmjyDEIyjtzGG40Gt9FezTmYK0NsogAKBgQqDKAgYTMH6ecyQxBAKAYYq tFKofo7CFIaTFRhBYfpZiqRwYBRFADtQJDBaYQxFATtSDDAWeIbiqCOwE8UCOyvsQp30H8hGnYF2 hfHUBZhANqCD7PpfKZHigV0pAZhEDmA34PeUTInA7pQETKFuQCclA3tQd/07SqUUYE9yAtMUplMP /TT1olSgi3oCMygN2JvS9W8pk3oB+5AL2FdhFmUA+1EmsD/10f9CAxQOpL7AQZQFzFaYQ/31b8hN A4C5CvNoIDCfBul/pgLKBhZSDrCI3MDBlKufoiEKh1I+cBgVAIupEDhcYQkV6SdpBA0GjqSh+tdU CjxJo2gY9NFUDByjsIxKgGNpBHAcjdRP0HiF5VQKrKBRwAk0BngV8DhNpDLgJBoLnKywksbrX1EV lQOrqQI4ReFUmgCcRhP1L2k6TQLWKLyaJgNrqRI4A/gFzaRq4CyaApxNU4FzgMdoLk0DzqMaYB1d rX9O84HHaAHVQl9IM4CLFF5Ds/TPaDHNhn4tzYG+ROFSmgtcRnXA62i+/ildr/AXtAB4Ay0ELqdF wHq6Rj9KK2gxcCVdC7xR4U20BHgzLdOP0C/pOuAqhbfQ9cDV9Av9E2qgG4BraDnwVqoHrqUV+sf0 K4W30UpgI90E/DXdrB+m2xXeQb/UD9GdtAr6XXQL8G5ajZx7qAF4L60BrlO4ntbqB+k++hX0++k2 6A8ofJAagRvo18CNdLv+J3qI7gA+THcCH6G7gJsUPkr36B/RY3Qv8HFaB9ys8De0HvgE3ad/SE/S A8DfKvwdPagfoKdoA3CLQg89pH9ATfQwdC89Ar1Z4VbaBHyaHgM+Q48DnwXupxbaDNxGvwFuV7iD ntTfp+fot8Cd9Dvg8wpfoKeAreQBvkhN+h/pJYW7yAt8mZqBvwe+R6/Q08BX6Rnga/Qs8HWFb1CL /gd6k7YDd9MO4FsK36bn9HdpD+0E7qXngfvoBf0deodaob9LL0L/g8L36CUgWgO+T78H7gfuow/o FeABehX4Ib0G/Ihe1/fSn+gN4EF6E3hI4WHaDfyY3tb30Ce0B3hE4VHaC/yU9gE/o3f0t+lzehd4 jP4A/ILeA34JfIu+oj8Cj9N+4An6APi1wpN0QN9Np+hD4J/pI+A39Cf9TfoLHYT+LR2Cflrhd/Qx 8Hv6BPhXOqK/QT8oPENHgWfpU+A5+gx4nj7XX6c2OgbU6Qugf0/37+n+Pf0/b0+/37+n+/f0//g9 vcd/4J5+0r+n+/d0/zn9v+Ge/v7PuKfLz2R83Kn9Q7lvkZKfQ50hjeTvSXdhj9Wwdydg13Rhx+uP 3WowdqCR2D0m4M6fgXt0Me64jawX/8DotkfYCxKiznL5+8VRMhm7aSb2w1zsa0OxS41SZabifl/w d2XkLyU/8g+uqfqmNnbOc/jBw9cefMzw/L/2dQVmvPQJJOPc9yvPr3DAkGgGpQYFSwwLj4iMIjyd ME7tX25LpKRuyd1T8OSgtPReLuqd2aev/D362OQVFVDR4CFDhxUPJxpZOmr0GBo7bnx5RfvvFf8p SShsupjeAX6h9Udd35PQ/vWT/9jZdeeNLXPnZA8aOKB/v6y+mb0zXL3S03qm9nCmdE/ultQ10ZEQ b7d16dwpLrZjTHSHqMiI8DBraIglOCgwwGwyGjTBGfUodBRV2T1JVR4tyTFkSKpMO6qRUX1ZRpXH jqyiK3089irlZr/S0w3Pmr/xdPs83Rc9mdU+kAam9rAXOuyetwoc9hY2YVQ59LUFjgq754TSS5Te qHQL9Ph4FLAXxtQW2D2syl7oKVpc21BYVYDqmoIC8x350wNTe1BTYBDUIGieaEddE4vOZkrh0YX9 mziZLQjKE+soKPR0dBTICDyia2H1NE/pqPLCgrj4+IrUHh6WP9UxxUOOPE+oU7lQvmrGY8z3mFQz 9hmyN7TG3tSjteHWFitNqXIGT3NMq55Y7hHVFbKNMCfaLfBELzsacymJysPzy1ddbo0TDYUxM+wy 2dCwyu7ZOKr8cmu8xIoK1IGyvGtRVUMRmr4Vg1g8xo7W+M0V5R52M5q0y57IXvn6N91RKHOqZto9 AY48R23DzCpMTWyDh0YvjffGxrq34YkcW2hvKCt3xHty4hwV1QWdmiKpYfTS5o5ue8crLak9mqxh voFtCgltV4ItlyvTL9qUptylVjz64sgyGZFjKBaExz7VjkjKHehTloTpWdQwNQtuoAqGUp5pmJEZ noD8qgZrf5kvy3sMXa0Oe8NpwgpwnDh+ZU51e46xq/U0SVWuk4tLDfYLusfp9KSkyCViysecIsZs lc5M7bG4hW9w1FntEBg+KsXYVlf0T8Pwx8fLCV7T4qYpSHjqR5X70naaEucld5qzwsOrpKX1giVq rLTUX7BcLF7lwErequ75KI856eK/UGuHiMLa/h7W4X9jnu6zF49xFI+aUG4vbKhqH9visitSPnvW RVu75onILxdxvF3jcUJZsSgnXnSWifJgj9YV/4xqUU9rMZmxKlUOsxd5rFVDfFgRGB//TxZq0U/J UkpcKtYepqe/88r0gCvSV4QX3CAQsJbEi8smNDQEXmErwg7U0FDksBc1VDVUt+j1Uxx2q6Nhm+gm ujXUFVZdmNEWffuaOE/RrRXoRC3rj9XKKa/JwW4Z1eRmt4yZUL7Nil3/lrJyL2c8vyqvoikRtvJt dmy6KpfLXJkpE3aZoGKGhe7lZuUft81NVK+smspQ6aktjFSe+UIeo6kt3Jdn9TWUpBpy40k9tUXz WdwXvDXkmX159T7v5HZvMyxWadlO2NRJGX0kd438svLL14O6ySpSKTeYyrQovh5vmzYtClekFoH3 N5sW0WzsbLO3aMHNwSEuKb0R0a4WLag52W4LzbVq4VQP5hQKzAFXgoVCRm4t3Lskw90CscAn5vrE TJ8oy3A/B8dheH1s1cKbo2NcMrs5MNhVL6U5QKbDvBMy3LkBWhhe2aRfGF7mlPSWZihziawlDA9w ldtcUOgrlefLzm537p9hy01E2g52g+vAW8CnwEZEH0Zp4EawDtZUSvotB98G3gg+LH1VbeaM0Nw4 zQqLVfXdipGyoowVfa/S5F/B8SgM1cwYFTONBG/QTKRpgV6abduGSkRzoYpUNDt7KulN7u5SBm9s J9dOPJHX4fXdhgzm7RCnLOTNy2tX+mT5lOaUVNeh3ECN6CSYa6QxHFBUqebknq5TLyDNRBuFMiZz xblmayRaE+ebQyNc7lyr+IFKwZw8oolawZzmidO0HMzhvsWb2ks2JLY0B4a4rPA/SXZwPVjQRiBT aTdY+p9sjuggq//cGxqmyh3ypvf2Kc3WGFdpbqT4CPG8Lt4hB9nEJ5BdIF+FxMITr4jXyKLi3NQc anXVo71H4P6IWIqTmk08KpbhvGYTm8UNFKfcPvCG+Nr5wJuc4soNFI+L65XLQjGfekPOFrO8Lpt9 h9gk16M43hwQJOM77rVGuXaKL8QsioTXUXhF20J3irmUBpY9aWkOsLgac4NFC7rZgmGxIUZGGxS6 xTteVIT2fiPqqQNse8QKioJ8Qqz0Rtlad4jvldt3sha09zBWjBTNlhBXa26AeFiuEPENRvwb1dq3 zUlZLspNErdSOphjUI9AOyL/KJL4GtrXmKavMTVfY2q+RhRfyy83ixOwnIBPmjhIdeJDagRvgK6h yqVejOA2pSQmu7aJX4jrMRLWHRg7htwbmgNCZGTXe8MjlNv18gbP2Snep5FgjuD3yzty3g7xK9WV xuaYOFngD96AYAzddb65QMFlcg52inqxUo3ECjUCnueRxPoXN6rCenNwmGs5Zr8MyXnA28B7wSfB GtzK0IcyqgQLuJc2h4S6QneICarwUG9Ihm2nGIKuD1GjNcQblaBiHtyuaKHeuC6u56VCqdjzXFqI ZvSm2UbtEMVYPyPFCO80G2If5UW9suCI5qz+rvQdYoQaixFem8OX7Y3oqJQib4BvXeU3B4bJSAqU o9NrDlHZzvZbUqQ0R0a7bFin/VVvM9RbVF9MX19MTV/cJxlqMlzN1nCs/mnCpXrkoirwRrAHrGGO XXB3YY5ddFjlhIo+6G4f0sECc9uHToGx1YhelAO+DfwC+DDYoHKrwBz56WihCtgI5qgxDWkr0A2u AteDN4JbwafAJtojUtFOKrzTgfVgD/gQWMNc9UAc8s9zhQs7nTcT2Wg5X+fuz5bTcracLxfLteWG 5dblYWZ3ZtceLvdMCT0lJAP6VgXUBdQHiPQAd0BpgLAG2AN4i97qNfXPgHCHG/tnHCj5suRMiQjv 22hsNPE9ucEsjA6BT4IF7WFWpKxIWd2rxJ7sQ9kns8WekkMlJ0vEnoOHDp48KPakHko9mSrcJXH9 XX0r2Ty2nN3GNBtLYzlsJNMqxTyxXNwmNJtIEzlYC1pVUF1QfZBID3IHlQYJa5A9iDcGbQzyBLUG 7Q0yeIytxr3Gw8ZTRkOpscpYZ6w3Nho3Go02U5opx+Q2aqdy8/mHGNSNQA+YUz2wUWlWZWkF7lXp RpWuAtaptBtYqjQHMF1qYAfqOgC/emAjWPrJtAOYLtNgB3b3D5BXB2wEc/6Bu1NCeqI7kVsT7Ymc EtmpRLY38XAi9yS2JvLW3P58v4pyP6Lcr6Lcj5L7Vdv7US80sAPRvq/83off+8rvffhJ7cfyqoB1 SnMDS5XmAKZLjb/vdfQNzY3m96HGSuAG8CGwoDRgDnieStmkB78P6Obrm7v1wAOfr/cmYY+ESPCJ Lj7RSYnmjrGuytxQHFA2gA+BBcmUDZwjU3orX+ctkL7rvIN8on/Godx+eIrKUNbRFjCnkcANSksD 5ihti/IJvZj2AA8rrQ648WK5SqVJPxv4QnmNr8e1DlooX4bcZe4gTh064MQeHmYOb+HbvTPCbS18 qzfZCtHsE14pciO4wPhb2NcKn1K4QeGdCscrDHUHOSw/OCy/d1ged1hyA/kwSkT2KYVfKJzpDkm0 HEu0vJJoeSTR8nCiZQc7QgkwxLtjEyyfJlj+lGB5NsHyRILljgTLxATLqATL8ARZVTLZycI7S2ST FXZyR9st5+yWj+2WN+2W1+yWh+yWCrulvx3u7Bs8Uy3sfoX3KMx8trfF1tvSubdlO8fYsKu8oRSw g3N2FVlEoDcl29YiApTg8d6SrhCdvCW5EHHektEQsd6SBRAR3pI7bLkBPJQ14cBi4yGsySxlsDdl BcxBPmH2pkyGMHhT+tlaWJs3xQFx1lvTGeKMt6YLxHfemt4Qp6V4jv2FanAEtrE/e2seRPXsS0qW 1bLPKYk/CdniLcmB97O+1tlWymZdkY1XOBkF+603BcGxzd6UZIjHvSmJEI/5xCPeFBvEQ96anhAP emvugHjAW3MUYr03ebasbx0lq3rupSQlF3pL4mCe7y2RNdR5S9Ig5nlLMiFmebPfgpjhzT4qi17N mhhWN6uhFBVptbcmBebK9o5MomRlnkiZqubB3hI5JEWyklwLK2zvSAHLl+c+lseaVC1ub0o63LK9 KUkQg3wjN9Bb44TI8iZjjFlfb/KDGLk+7Q10l/PzHEtEGLIihzflSTjZvDXdIbp4awoh4mRJBBXR 3mo4Zaugwrwp0svqTbHbnmdBVKNqDKQktv4Z23nUeza7hY3z2s64W8zMa/s+GeIZ2/GSKbavSlpw 6rV9idv4yWdsh+B6MBuqO8j2UcpR24c1CbY3UuDhjrO9ntLTtitpqa0leYetuaSLrQmBeWqm2LbU qBqeSkIxr21zcgtnKL2xZrjt3hSn7Z6kFhnD7XBeJdtARTenLLWtTFphuwZLYVHJatvClM62uuTJ tpnJsqFo24yU0bZadORqlJlec7WtOuUOW1Wminhyylu2MZmqD8U1qkdDs5VhSM1oWxEigCFHGhDB AKxLF4r2zNwhxwinlfzmt2xj+z7H8SRm9eAF7p6mnaYbTFNMZaY8PHO6mbqa4k1dTJHmcLPVHGIO NgeazWajWTNzM971eGSLftjtlB/fRhqtUhg1iZrSrVyi/KRXvgkyM8fLlidCFPPiMXmevs7iFpM+ 2pPlLPaYS68qb2LsVxWs2NM6lYqn2D3fjXG0sEC8cRscecwTXkzFZXkxcPbwW/DuWlbewnRZ4uY4 +THWNmKsx81r46QsunltRQV1WJwTkxOeHdavqOBHoKodCwuclyjG6bwi1dlzd/GYcs8TnSs8Lqno nSuKPd3lR13b+Gw+s7BgG58lRUX5NlbLZxeOlvmstqACbgOUG2XzWXCjEingxidStnRD/sTL3FgT sguasrN9TiNZk3TCTTNSOU3wOeVf7iTWsHzllC/WKKcHfQ2mIA406JYCbobZlKIaTDHMVm4x0q0p KQk11SRJlyZXEhyaklzKPOqSOdln/p3P/DtpbmHskj0zyRdtMiWpFpJ4MnycPyNNz/sXCrHmQYvn lsuPKKschdPBVZ41i2tjPPVT7PamuYvbP7tMqpoytVbK6umexY7pBZ65jgJ706DyHzGXS/MgR0ET lReWlTeVu6cXeAe5BxU6qgsqmkesyJp/RVurL7aVteJHKlshK8uSbY2Y/yPm+dI8QrY1X7Y1X7Y1 wj1CtVU8Oo8Vl5Y3mSmvIn+iTzbzoEDcLVVx8RV5Hax12erWGRAfc0Pcdo3YZgpyVniCHXkeC1ia UnNTc6UJt7Q0hciPodtNMTcMiI/bzja3m6zIDnPk0aKYwhkF+LcQtGjRNSCM8cKFvrGO8RkWOQuV HQ6LoC1SBE/okheq3Hb7IrrmEjmdPl9a6MwvbyopKYyZURCHg3yzPHs7KxaS0+lr0OkktIleq8N+ B3XYDzJ2yHiv5NOS0yWiVZ3y94IPq1N+K074e8GHccrvIlqz92YfzhatJXtLDsP34N6Dhw+K1tS9 qYdTRd/2CGRTFQwRXrqucS68RmY7meqt6rcMBEFDkb2+MAwLlWGRGhiQL18VdaIi58XizkvKQp/x GlXEl7vw0hqGQVa/6Brn35MvF5Vj7J1Ow6/IZhiuuJO4k+KI9I/BR8HH2obp5wyzyNE2Uz8sIrBl J/q4nbrSTTjsHaO76QWaRG/i7FjIelI5aSyGOmJz70fFGMJoMuARm4yTYzGVUhT2+0+ZhbZQL/qS FdEKPKBH0v04G47Ay3ou/Zo2ssH6F7SC3mUz6EmU3szc1I2GsyH6IRpFpfqzaINoAN1D61kIHljD WSBz6AdRw0JaRdvpj6TTBLrXsBG1lNJomqs/SxNpH5vArtI70VCaSzfQvfQQ7aSj7BbWqhn0Ksqk KbSAmVgESxYr9c2UZdgf8LT+sr6XrPB/CLUe506tSP+a3HRMY3otlkgEZeCaSw/TM/QRi2GZIp9C cASdiLG4nraIZMQ4hFajb9vZdWyLCNE3oTd9aSotx7Jawlp5vGG/4ZS+jMLRv96ItIE20Yu0i75C bUWsTMxpy9FH4DlpJicVoqWb6Jf0FEbuJVwvs1AWz4ai5hfZQfaxmCs+Q82P0wn6jv7KktkMdgPP 4SsNrvMr9KcpCT10o46hNJ5m029ZEnOzq1D2fn4tvwGvzM+Ij7Rk7aSepe8iI+HVnFbSE+jX2/Qu vY/5KmIl7I/8BtFs+KV+HeJNo1r04iZ6lLbRaWZgASyYRTI7y2B90bPrWCv7mHfmDl4upogthlv1 pfpaisdamUTTUXIm3Ug307Mk/6/+KzrBYlEyDSVzWClbi1fll/keMV5MFHdrbu1u7UntJe2cIczw Utu+tsMYdVlPOpXgmkQ1tAxj3YJrFx1ggsWxLqhpEBuGmipZDbueNbK72CPsMfYMe5XtZV+wk+wH HsNv5XfyHfz3fA/fKzqLFFEgNojdWrx2QDtrqj7fue2FtpN6kO7UM/RG/X79Q/2EmoVOWPE5lI/V NYvq0ftGuosewJhvpbfoPay7Q+o6SqcwB2eZEaupIyJKYA7WjfVA78azcnYta2B3sE3sFfYxO8rO ceLBPAFXCu/Dh/GJfCU/zs+JQOEQuWKJuEe8I85oSw0uXE8anjacMh41dTXvPnff+YNt1Daj7e62 +/RMrEUjVl4E7rnelIc1NwyzPI3m41pAi+lajNEyjPj9WDlbyEs76DXajbHfQx/SRypeeX2BmfiW zlMb45hPAzPj8sWejpnJx2qpYtMxt77rOraSrWb34rqPPcgewvjuY++wd9khdoSdln84nafyXD4Y PSrlV/FJuCr5VL6Cr+Fbcb3N/8g/5J/wM8IqwoRNdBOF4mpxi2gQHrFV/EG8pyVpudoQbZb2qrYP PR9iGGqoNEw1rDE8ZHjE8JLhDcNRg268w/iwscV4zBRo6mMqxdF0tek3ph2mj0y6uRvWUwmiv/xn 4O9gV2lpvJHpvAX9fp4vEm/yO9mTl/+PtaEBEUzDS3WL2MkfuL5RfCJ+y1eq39IjaRB2sd30HO02 vKtFGY7RqzyWvsZ+eKeo5s/jdTuG9REDtJu13dh1liLOR/ghbuJb4CG/h1VJY1lH+kYbRycx/nsM DRjTIn6QPclfwevzJNpPm/gOwss9TWd9Ed00eprO0K/ZNmFnz2DdLae9dJwOX4pWSzufx3OMMXyx sT9maBsbpb/Ku+tf4a7/mN1MH4ozWPvj2AiWRo/REcz6e6w3s2ltWhztw87Xhe7Dqv2cmnEPvqEl 4g46TdtEb5qgHcacp51/va3AsEjcyL7juZjOaLVzj5S7Mfbge7FXyX00hLZgJWAXUXf0V/QWS8Ao vms8QOvpNtouoqireJTXc128ptnpdjoshqPVX2B/6sR6o6Y5NAP9sOuftW1CDTMpi7LYFDaBCmAZ Ql30OYj8MexFbn2ivs5QYXDS22w4i6IXsHvFYBTvNgS0nYDnVtyHH9IQtoaa26ZRK54rMawrc2E1 nTAsNjQanjBsNTxveMvYi5bgrr0Ps/gJfYunhp1NxVh8Sd9jrefh7umB+ycXUQzBM2w2rxA7KZ/F Uh32wGTs23kYgwmYyYWoZSXdivvpUTxD3qZTzIq33udpP+6caNznU9G+GfUU01jM+kJ6DLvjjawZ OdOoC6VgnM6wEJbFF6E9uc/ejX22FTF9RJ9h59BVXD3YALwqj0Nd38t7GS30oVK8E5D+DPXDk7JA 7KZPKRFP1zzco5tQrgprI4Q6Uz/DEcapR9sIPYvPEDtZBzwNQ7CqyvBkH8TmI4pQ9OM8RbGRlNk2 GLU9ib2s1PAonr5OPBmieJQ23jAWcR/Ak+xtWqCXs/WmAvG+OKXV4ZneCTPcySC/7mKivK2c7TKa WoTZHUEGbZegQJO2i1FHs9Gwi4vnWC4FYCLGUYzT+t3A8wNHWL8dWHJ+IOVAt54D9EqPD4sP6wpg nTQ6Zxet59wGOkt2rVV+G2iL/imT5w8rdt4bdnKP/OIpv4O68NubOwcwahEd3bFhQ6ODGrts7MK7 REfHBkcOjSV3R1tveokx9XEudBYcGmuL5bE9QoNtwTy4hUW4A14wMmPHzvv3xDgR06SSE5OOTgrv 50w74bSeGGEtnF7w2STKKTn/WU6vdFZUUFQwtIA5krp1S8rs3SfD1SEq0mQyCimNjgSZx2b3MHXr nTZx2JBKV2anhPzKyvz8ysls24KHD7w8tmRy5dDhew8sattXWaAsVeoDvX1iO3oWjFVX6Y7j5vDI 3twc17k3sUDNEhIdRsxkDOkQwkNa2DJ3x8hIEwtbNS96QzSPjo0LXGXXmNYx9lL4I6zfTSo5j3G1 npgf1q8fCwvv108ywsfh0yEuBX5lYlKv2sjxg4pGxLB61/SYiuzBxbF8H1tR3C97/FWZqZPbVrD6 8vT+5ZN7OWrl+/rothp+O6IOp1J38qqQZ0N5X+1efmfAZv5ogIG9RCL4JUuEJTgYvumRoSb5+bQw tfC73AFuK7OOi5h3t1wIk05Mwmqw4qKcEzkneqXTJDaJRRlNuMKs4dEdoqOSKMxK/PbaXgVJ6eOL e0/6c1sTG2GY1bMgd8LaLW2vtO1va5lelOkaxf6Cu8TN5NO5I2KrULGNdif00VYZbgltCdXu5usC HuO/CdAQXQSiw6q1muztUYWNlFFFEmPBwZb0iNGrEd23KjAV5GXRRWT26YsrzMq7JXXL7CCj61jb K7+bLzg2sq2praZnYe6EWz2sP85eg1VwbZa259pebJPHZpqgf84ex54XRAlbaagxSMhVGGQPSA/g AR2D562WE3kOE0myRXb50qKi6imFhf+Ljy8Bk6I61z7nVFd1dfVS1dVb9d5d1dVbzUwP0z1LM8N0 yWZARgY3hNCyqDACysxEGYEQwAVEnyiugGhEo7heQdkaNIEYNW5JMCaR5DeRJFyTeDNqnowkf2B6 /nOqewy59z7/zNNn6T5dM/Ut7/d+3zndixfDgtFNm7bEqJ+M/Q6V8N1SoE0P4xsoIcqNkPG5TmSl 9oIADfeiBtOr08gtEfMgl+4qdW2hm7T1wuv4b2CQR6XqlI3wGL3in6vpO4m/zRw7TR2k+wgSwJm6 3xJkooxqyfjMUtAT86hSxmJm4RAbrkDuZZFO4W4/Yxd9FYrTVaAnkgWga024ybfhpnNSQcdIsxv/ j4FGkZejmOWQlY577NCuuzwFu7/hy7+SGz+jDWIPnHKl7pP1RKogk4vI5CIyucgqGQ6QrGUeXmgM eoZJcceHczy82EdyPbze6PFbSH8Qv2uRr/6uuhanrNGXwGwsHo0jhncIDsQkFFVBjNXG2Sw21mZi PF63FzF+KSAFJYpBmEyaIMVktYyGmIhTXgKSZtyEXL4lME3jJu4IL4GKLbUESF480iAeGdUD0mTr P5vAAByAbrMDYXVi28EqbW8j3ufz0gKZK7KZwVbv83rzLdjEqINF+Rv3XbHkO5Ma4lp3/sSNq3/c PKX6nolL+js0vxpw8x1NLf4sg/a8u2/lnXOuKU8d2Pnd3xzZ+d3H73jlI3hN510TYpLy0ujn1VNL LmyOddxEbGULBuursVZ94NZXgQP+B2wFLHzqkLzQvMqM4AV24xkzJEf2vfApwMO/4+DQCrwI6Q6e BTRrtuEnozi6VSjsyA5HL7+K38tTAg95v+T4PgKARW8CCfngxwbSnyagVO7qEUbLBOtLYvHL4XPw Sw2WNWx4Tje+17wn3ppvaWtrdRaSRAYpFe3yTu+JjrYl5s4MiBNi+Rki/Bvdd/b59dMaVDU9fSM6 dlUuHkucJnfUgu/oEXxHIfAnPXEHehG9QFEp24MU4qycFQI6KO72HvAibwjh/4mzsqEKXHRIzPn2 YfisQPllKLLEXKz2AluhEgccNLRhhxzRg4AWaER/JH7Ah+CxEAwFIjyExyCE/vBRzN23AWKup8sD GB8GekZGy6dBqTRMigq6i9W99hKr+xy48fO4sRcN+8NCmLKgbq94hWGneJHRBwWjfznkLBlrTzsN 2CbwXXYWxSKeCm9jkZVBOR5vBWJrwZCVYUAEvxkYxzJsz1O9534PVz16y1UPX662fbRt2XOLZl5b fQGqKy/IygkvPAibtl1318P245VFT8+4feuR6kFRm0bkOA37+36c98uwV29yMNDC+bk0SFMmN+cJ ekJUBzODOUxTVhrioBMyhQXchk0wYKKwuBboApDdAMjYtyGQBcO9LQdEnP2bKvDzQ2KMOkYhvFDe D4EpUIEP6xzvirqQ6yObHVXQW/vh+yx4BTE4cQ/DL/WAzvayu1mKDSSE9++RoUwwQvYrNYwYwRhx GgPAsHBaGMFiHy4PYxZBRKu7KR0LkNKxNCkif4powpBndcAQvQmLGq8w1UVuqqvA6PFS0r/sthlv 0eYNl8mb9IhMLiqTi8rkojK5qKzjZbIuWmtrtXl1OAVO0Ue05sMBFwyU4WB5AMapuNlEzrUyJkUe Zw44tmE/b2stJOKyGVPAddeOfpqH847uvLtafXjPvO4LtFTv4kkN0dQl36juro4E2+hZ1eoW+2O3 /nD955u6Gzq0ybGpWcF282X7PiI19BLW32EDr9PguB7kqABOZakdlmcsFctbNtNUlvYpNOuLpuAr 8EGcMrDw4f2pFIhi4NZtPA3svveBX/AjP8Fl0RXIKh9Z34dE7tCfGZd7Ty1+1I1dLOaGhWFsoDUz NYC1JZC0iHHVnnSqwUAoEA5QjJqMOZQlICL4l8CkBY9kW3QJDIi4SXAYKMFXQIkfmzaRGOtr7Ubt TD3sEWGJHjcyQSyscZz0CER6pT1/3BLsntv88I9X/WTV0M+/9ePqcpjhslLOn24JpSZrM1KhUPKB X98d8//2B5s/XndHtfrUL6s3D6M7+i8/9OjcjFfr3FP9r+um1vjlH+E56jUclX2g5QjwY8LoF10F ZgYw22aIVp6aYWk45oEev/QV1RoZHWctGPHPi9Ou82P2FUagXrx4aj12U68trsXuxaOD/4riiHwf LL0P6y+OmXyzfr8sWMXSUmG1MKRsETYrz9kPC+aH7PvtCCYUBGRFiXMOa5jzxaWwz2qBFsSGLV6n J+zFMgWy9xsKL8QUEBfiKK6geKNTcDudgoKUOEo7eLfDwaPVDujg1jph3CnwJq8SdzqwhH0KLyfS xhdfnBZ0gadwMOI4C8t7ofcovAUosElXYpy/Odmf3JjcnTyRPJVkVCEZS+rJXvzMtuS+pPme67GA BoTyiD/QM4q5k1QyiFSpK0CiwGiXs/iVj2CmXS5ucTRpLHYd3EtkUH5dI+BXLEpAGIbC8VpbPn9i Frq6zF1ddb6owTi2CDdhi/FWDIIwD721CQmkhtGkKIq6rBovhpqCy6uTZlw1Df6nC/55eqPcPdof nB3zMii0/J0T8JbbJmvFoMCqqvXqXaaJZ5/5TiZKq6pXiIguy+S/wQ+qjRgr54z9jp6LGVcCho8A 79jG/RauEKrUeqbe23Gvz8MDW8ASbHP1BDZ77wrcE9waYlc4V4hrnGvErc6nmWfsT/l+5Hs3yDFe kJzivSC00Xu7b3PwttBh0ysRLpfsiw4xq+2rg5tdR3lzu8MpJsJgPgrjhAa6MdmbH3/WKTro5WHK sdxjgQtzTugM9CdhUlRvOAJbjBCFuZSF56Ic4nr8/pGeP5eD+2ujYcyiyjhXOG0YMRb3X0awaIdH hgEJNBdduualFhZ7dMIbYuy2pE9lLWYLYoJJu5dTARPCjVVyqMASoFVY8+As8V9YHgAY8wz641RI RGeIckQCdu0e4tQJ1FoQE/kWA//a6bmphi92bPj5hNKC1x/Z+IvVg39/6lfVvYffhfNeu+exBf5Y zkyvqGYrr9+3evuRQ9Vf7OzfetPQihfh9MprcMHx7kQuT7wniL1nAEevIGarVn1BYCMWvEIagTQa aZa5+qRl6sOZSppe5rwOT7Y7d3ifdDFXO8yxMJBlNhZ2yEqoiXcguTUYBKzYGOLD0TAKd7PNZthr hub1DZMO1nx/AOeuhNVg4QogKSRRsge4BXezm3K3YZFiIR9K9jS7oTEbnmdkY6WuYU2rCfYqItiZ iiYERJfThZh0KpPKpijmXzPEeD0+j+Txe0xMQtWEpAqzpFECuEm5QqTR8HOa6pFVoAld55PNGoiS aZ4wq/Y6tVJa41jmGEodyMwoFCZfPoNpOg32GWzsLPEW75RiI1r4twcOvrLgvmN3Trp1vuAK5p++ 8uZLLlj6NVWNea6jvtlXSKmT51QrP73nr48uDNhMY2d/e1mS4wcfxvkX/cjahij2kAwApn9ifUyA F+vDXpPfgmL55nx/flv+Gd+H7g99n/j+7rOs4W70fLNpK3Wfm97K7aB2cPd7nqGe4ZiYe5pHz/fm 11A0R3EcypNQ+4DpEcuTphcte9y0DQLzHJvtXTZsjsXCkixrcyZM+F1DWGPmQPguHWbisXBGViAD bGY78Age5PFqbo+X8pl93v1ikzQhnYFNNpuUQRLLmHnzbDMq4eYe817zT80fmxmesGFzS36vdkxD Oa2kzdYWaqu0Ddo92mMaq90qePu927yUN6DnYR7w9qgd2bvjMX9L3TwM46g7V3mAMLiBwRyOFaVa xBSGh7vqCIi5nUhonoYd7y9AGK1341NKoOsgpw2U8Q/OIJxEoXmn0oSUGnsmU6qGdIaijQiJVU18 D49QU3DTjUIyaetZuthVmDjn+//Zok46u7KxMxFwWGkumJzcaFqVDF+3qONhU3X05BPfGZ144wP5 6i39LbF9B6pzVI9DlpZS31zgUbDRVVfdvzFCzk43Yf3uwfptgHG9x2yycA2UbJ1ppRma4bAzUElT kktak7bZ1HRutnUpt5rbzDnWZrY1HTQd5N40vcl9YvqEO0Of4ThHLOyWlXAs7JHl5JyGhgpK68tT 4STPQpYo2RJmcUJinoPQu0zYHImFE7LCms1JZJttR7Nh8pgK1cC+JtgEoJ13RB3I0R3mQRRjQnck EvY3uj0N6QRKw7TNbk+4HeEieUIFaTWBPGxj06sQ4ZA7CZoxVmpYQ11EP10jWD/FXNewMYGGRoXh MoleXTW94vknwifGorquviz/t574OsHCmsoMnREfPC/laT/fM8fVlU/NH5xtUxTXsytSPuyMo501 VRHHNN2ccXzj+q4nsKI+aNt4/ejcH6yrLibuOK4lMq6u23pbkMc6unTsFJOgV4I8XKl7OYFOUKoj c3P0juhtidvUb2fuyHJKPVbZ/lvsypLYNQUP+sx91iHrUOII9X1ThTmcOJw8nOWmKtMzenZLZnOW 3pncnn2a+a75Gesb6rsZ80yHREhyvwQjb4WlBTJJaHQ3fmaDDzrfCvtkJX9e+JLB/OZntUgUClG7 T5JkulWj7K2yBTgFJ3J2w0iglbzfYhMKrWLaX2h9FV6KdXUDPEV0dfFIz5QrD/GWqAVZCN6+ZDEC mnamq6deriHKEYtFiB9AGI9tJPGsJZ+AAPE0AsQtsSzDW7H41VQCg7BZtSkWFTjiwmQYi/ICk8Uz LmVXAR+zTwZsxoh3GG4JqTGinoG3AwbgEnUryQQOemg85o1rGMc+HAidJAcgqm4VAIHjWgy8XZ1S HXlsxzuXLfjxtycsa/NOm6Cg+y/qFCy3VP+4/QdjP2yfDnHIu3ZOwxtiqNmNA6L8+nvPV3/y+A+r v77T44aB3lxSVelowjWz+snEzuueX3Hn87AF7hHYizJFUMNj9BnZ2QV36o1xvT1U4mJhJMuBWFiU 5WAsDGXFGgs7ZUV0IgTZAB+MBlGw28oRFUjTldIpDjZzOtfPHedMC3GDOH8sTl4MBsOFU3HYHz8e R81xPb4wvjG+D0+YSasxGGLk00i8HNQMUDQKT0ROhDOr/9MLPITbEykRL0GfnW/86A0y5q3YKdR/ M/ja+NxteIzvNImZgB3fqQru0duWwCG4TulPmbYp2xJ7EtS/bnqWXLtdrCkqqCQAUAW1X92o7lZp tQKP6EIsnkZYFpBFrPoz8CisoL26919i8SebU3pqd4qadCW5yzrmj4yMYgzBwX60a6TcRYqvvqJx swZNpf5/t+szoBybgj1/dtZ5d/1Bp3HXkuJfNLBy23U5+FE18b/c/e6+osMy68ndNV2b+7AE2uBs fTBC8ghrBFoi6yKouWNaW2/H0+AtQKuhNjgEhkJD4c1gS2hLeGf4mfCn4X+Gbf0dpzpQVIy6om4h Iag0L/Iu3g0SQLW0MecbTdPEcFKuSzE6MazKSi4WbpUxptyhTwHhUAwCkA4F3aFQELS1AdAYjrjD 4QiAbeEQFYUB0NaKIEqq4ZDoZAFo7wgKARjo5n5q/diKrIEOw/dDkYLxD3UQRLJ4vIWOSDSdayKv OclrTaea0PGmE02oyd/eUYGX7Y9jq6vAhtsJQJQNo8OArQ1qBLKxgvwEsiVsheSHtCQG41DMbmnS aJyC4F4yBuOnvQiGlwcJpQUDGoT/bqDnwzhUoNNN3Jk85207X8vUCdiP0g1dCT9v9U4tNox21caj /5BGv6Dtc8vVZkfjxWkrwi9qKAt/Qn0LazUuXXvulvPAffisZnrv3LRrfC0lVYXRQs76dWr+snxK Jf4dxhnJdqzzOBx4WRSxX/7jZXuRdPqQrSiEQrwQCod5+8Qwa3i7T5bRxLBZVpyxsHdWPU/EMTgu hHyQD4e7AXTjy4aDMnDyDgjDvjiLgy5APi/LWyDJIe1woR3a1/cqUBGc6RAIwt4gBMFV2D3Wy4br CyMD5UGigB4SMQdruz3E/wluirWdCYP8kPxvi2n96wA/KdVyPSL6LULX+te3CK9DogVS5gVj+3TN 1Qp4gW8Hg7H++MbYxvi9YBu/LbYtfgAciNtNMVM8a0pZZVc2wAiVsa+/7GrF3R7dJZKTqIIbCsI2 uDu0T9gXYgGJBBi1yfGngwLrDpYEcljRIkolwDpcJVAZ+6I+490lvjL2x/14De5//bLDV4K1c0Tk nA8kpMuMvdmBPE5iBjXLIBXNFEb6VlhFjyrNA/D4FZ1x+dyKFdNi1Wj/lWFtcjc969xhdOFabSLC Cacye9HZ7abrzj1x0yVYwfNXUt9LtMlIJR+TwNr9AuebdhCBz+v5PqHPtYP7UPzQfzJwMvRh+I+i xSyZIz4k2XwBXyglpFwpdzrARUja4yONpx7Y+fOSU9KzxK2uIZGfrIKkEbfDh9BOZif7kG27fQ/a Y/sR/SPLm+EP4Yd2OzKZWcbCcD7oQz6bz+4NW5b6l4Zupodsq/2rw9v5Q9Kh8IfBL1jrFQ5HK6C8 rWaLaPVHb7jSMAccsHU/CArYRHp0ClKBXKwUQzFejIpIxDGcMKsBEst1/t8WiGRTi7w0PF7BJ6F7 DgndXTAiqOGkO2lR6aQ/IAUQw9tFFcspqEIPi0c+Bo+cNocK7SGEW+jivCoImHCjaV3496vSE05e IfZyUkc8wDJika6MjehWsYgksWjDD1QZ+9PLziImS3/BHU1m9qIFz16yF8H4eap5cHyETQsmMJcx o3gslXQKgJbNRnWfIIbYKmCW7MMZ04Pb36reX73vre/AXbDj6OLZay/fuWzalUuu2UUvtFVvqP6s Wn29eu4fr0M7bIL3z/r+I9WPqk/tubFFh/7f4+esN5Dst7d6N/1XbB9ekIRv69NM1j5/X2iZahKt POeawc9wbbHfxW8Vtop3ubZ4uKlwCtcnL1N32rcL28Wdnj3Sc7Enk+/w77jsXmIBsY3nUcJIvRfq vUQspoQHScNYSAOAxcJxNittYwRO5LwXCDPFzfwdLtuQbUi42Tskr1bv4rZLb8I3Ocscx/c5iB3r pC7xzoI1jRtyIOEvVgpYlaCv1UmZSSVWbSiYK7DtADWBaaUr8FrdaY3+DLDMXNHhT6VXxolB1Rig bgcKqWv1uAPHMck3TvLZxUK6FqgNo9LKZ4hRHT5vzUGyJEjMirw4PI+UQLrOEHpYGjY2TDE0lGtm NouYWZstGcdm5lfVZMyrqDBiC6pAEnCTFPFU9kRVLPyQHXc2a4D3qTDhwg22CswQhbqN1S1sYHwM atVlwS44ix784LGNufAD1OyoTBv7QB5SMEkZm6DxGGnheWZEMnfqg6bX7ks3bh86Wv0/M89UP4A7 4ERYhA9VX6vecGDJJeuu2L7j8nU9i2y3b2YnJQ/tK8C1kIHN8P7qyur71X9U19L0K49Wf1t98pmb vvEUvAhOv498nJCwqF/heKKARnizXro8MBjY4aFYRVIuClwYulBeHLpaNouABoxAC4ypObcsOBQc ku9Q3gu+q5zIsTu9Pw/8X+ms/2yAzrG2CvrFARxtZGgMGFmx44FexCxCweTAAIRGRXYrirxBuQsr E2RD8eBG+bQ8IlOC3CufkKkTMpR92ZCsJNWmYAX+XvcpADCJxiaXS0Sxn8XjsozpNYspKaRxygCy QhZlf+urUEj32hIqDpK1batGm62XxK2mSUeg39ihKneRvM7Y6R0lOR7hqMZs2OBxRh442lXfihkY LBdJ+bJYJkGr7MBMQTJYAjaSWKrBHfCo/mRabXBnczAVwI3mbczBjJTMgUDwqyJNvcpd2wxK4yBt tRU11lYMSS5PN6wFlTJeYZAMHEm+2hxrjdc3e8z1AiekjOSSbAahWHBqeXTmVVOCuEerz5zetnLa N+F0PZhpq15evWhe8a47Z9/7OFpeve2GoqyqSscNVD8ZTT287qEl3dFq6zxvlFLRcrRz9MX87St2 PUB4xfKxU6Y4RpYibNSLUvPczFCcYhzQwps1plnifVojrwkZZ06OaYmGtmybtiyzNbM1+2yhkj1a cBW/yvZm6B4wn2+LtqG2ZydgFjg/Fo7GojBawdY1PTIfBIQACjzryWg8m+StPB+yhnjTan51Zhf/ lPWg9XWe0TK81aTQrRMopdVjmQ3HP0pHw7m1AlwFCrpDDHRi/y908mwUE3f81IHohCb/xAosvlSP QaeHCSScMY551AqfvmJ5wHB6kiaWR4bL9SIoGRvDlxjyuXQ9RlkpHqmZpLbceh2/1rqG35y5XXuQ f8H6ivUd6zu8HTv0PEL1BzDXd9Uqn0ZR2vj1uE3Gti8phyrOvLe294PpQRMy9oPqmSD1mjUT/sNt S4c8YT333GeXXlL9+3v64BXN0cBEUVUbzt7bf3u+77YjT8z97ODk7tyWYCBix9lg13M/vf7CRiXX FL/spr6+zc99GUi40xkETv5h7Zzm+XMu+PrG7yx84rRguyA2iWh1JvZuG/buGHjhCJAx3kqBgkyg s1MQCzFZxy53XDY14wGCvzGbz2EdSrGwIMuWWJjHbP83gcC5SDhqDqRBDAk8C/ohUXJWl9laQt7t FyQYk3qlbRIlxYQozqN7oxui26Km6FGYBRJ6cb+B4cIZUkoV8IMkT/X0cLRrvAo2XgbDJJxk17Be I/mfNRSDlCtO2paIXTw1ufBa35SJjaMTa/nikq3dc31Jelb13g2r4uLZT/9FqU3eiXMegquML/ce O0U/iSXSBCn9cYn3y0jiUnJWWad823G3slf5sTKmWIzPqlACFJBA9WNKv8G7wXfE8Vb6ZPpPaQet eByCHIsnlQnx+bL5tfiXCtrjOORAedZM0ms5apQqs7GmMJATTsLBFclHvicd2ZYnLJhDxzZE4cLo WBRF1zc36829zf3Nu5vpZpYcnkHm7kymNwuz63N1bl3fUze49UCNWw/XgEsbByQ5nrbwXDKpOlSr yuZAKm1XhByU45aULQd4GTdExEaEqoPSwCAOUIMukuYw9SSnDj6pZC1frSU/pIyPua2BSuZm9Koy u9Pf/q1FN+zqSYYbL4G/CBVnOe2lkQ/2Lbp1ZUC/gp6lxifeONp3aPXFV794EmW+fjGOkWpTU+zS 0dHPf/5yTn/rWbTjpqJsfNl6HFtnC9aFG/p0KxTESAlHWankJQbaLEYKmPXQwBqGTiu9l36WeVoY sZgWMauZLfTtzIP0g8zT9LPCIXof86rwitNW912enAVgXYzXYxUsQgESam/FA2saIJjmWAMJiIXh XDCo582s6LK6bDj5twIIkTNUgo2c1c3hqyCrbZUXo6/P2KNexPazG1manQsq6CM94Gb3sZDlgC3t dgOE8IXdC123cn6P9yipXcHCS9fXiIuxbU02BUgoyUGhOlK+mBw1GwBEg1voniac/6wnm8nGIQDh beHtebUqAkmNcB6KDd+o+0Js+g5kVlym35/7A0SHZwy9EE+1n01SkbdvUqevm4PFTM86C3yJHzxR 9dLIbO/ZuAR+G9vxgrG/Ub+lfggmgC60QPcwglA0xYRii941tXBX6/3mXa1UN5H44otaDxXht8x7 Gl/oOtz4ZuPJ+IeNJ1s/abS0mqeZZ7pm+ma0Xulbyj4IdrU+BQ/BQ6wtb4Ybu3eaHm58ZIIJdPd2 X+1d1D3oe8izFz418Rg81c2x3t7uGzupr7HII3pQJ/krHb7i552wJc9aWLPWkNYaVK0h05V/Pv9K njLlJ+V78uvz384/lv+P/PfyP8n/Jj+ct/bnYb4TJzDv6dstFnS5m42z17I3sSbEdrKz2LXsVvYx dg/7Fvsr1mJlg1hPlFtkKcmejGr42pmluc6voZbtoJzLIUnPaAVeikoLpVXSY9Je6Zhk/lj6i3QO o5ekO4SChLALWvmGaEOuodRgapiamcKrURWpn2LyK5E/n7OULBssxyymGO4QsAgYBSvwFV3Quzd2 I717UTfqfsYDPeTzKHq6N10aC8KgBtqFdtTeQuuKWliFUzzUTOt0L72INtH+SR2XSxU44fbafpPW MzwwMqD9oIzBcqRMKhvY+8+QEFYihxXxAmw4I6RePTpyWqgFtUHN2HkYPwQovM0KXY6uLpz3wsGa XxywSWEJgfK82t59x8SQwgmUicdcN65ak8WkI+KMAFvMEoGyMpFqjwAhZI9ATsZNh6kzUt+7r+GH ASGbNsHBgTLADzigAcJ11fpOuNpaO95jxMSv9sdrJyHqSNPuM/b8U06mtirfgmY8f0fv8gps9enp C7KBUHJGZ+nywfduuH2Xz8G57YFgpGXF1N753JrOVNzf2HLn9utmr3j+7quWt2fCouSJaukJ02bl v3br9IHJ2e3VB/W4oEozp1z0ICxeOKetvUkJEry5eOw0tRB7ggL+ql//JQMTFjjPsifyBnpDOQk/ hb9HZo6FDSjrnhtdalkWXW1ZzQ1GtrtecL3grqCj7kORo8obkZ+qTgA9LkA5QuQbCBE4AU9BZIJu zDnjLo/kl75wQud/SUmrOf41k5V3QIdGTqXub/GXjNOpQYuzwEO4G+7D7wjsVT/H1sWHoiEUajHX 15H+UFornDBDc60y7iiY/YmOu2uHM8rkOJyRRJMco+f0oAFqwwNCl7GbXh4oDhj4Vj9GRM6mDKiG xBE5iZYfP7Xw1RGL2v5gG6VHJ7+x6pVTS9edvPf5aR2dPRbG54s2y4XLZrRfNOHKv0rfXAMDbx67 d+9984tTL76m5Pfnex677a+dWhPJTWePnTZNw2gewZnEWl3ZYX/GfsR+2GsSxXYWRIQI8kUbLaz0 RDTyhlKLdBX42QH4BBPFg68fZrXbbDbWSj5crPt9a+JJtxlfCgBWwPwOMwlBQlLWEKADS4iHsyHa h8lIIEcO8lzUSrr9nZMKOWMnAsurN3cih/pzu3MoF03CpC6QFzzkrQJsFnShVzghmAR/U8cm6SvH IzIdxJZ8pjYbrvEUTAwJgAvGebayRjkEUlOEZcOV0nLW7kqoiooYMVnbz3WosiuZAlk7blRnPAVT vJYiDlTbOc9u2oSz2Vy/vd/VL/dn9+WO55h+xwZxtW+D0p9Z17jZd2fjDvt2766GPd7nG442ODby W52IaLE8z8gjcvhO/fGSccdSzOhf9kWNOtU8I5fADNPnoVtroXvc9UjpCkd2V+3wYV3l7dTPGLax o3rThaum7++7rO9g35S+ToutefKWmStUSc0VGn3pKy/GceW9693xmCne88AV3btv+d72z9cWLoCB Fd5wKDu6+W539JHHX3ou6bqzZgVUGfuYB8Rgq34lI17kLrtXufs810pr3GaVexq9id52vo/ep07a T3r+Rv3Dzm3w1I59XUEtpVbJQ9QG+VZqs+NT+588liw75oWsxaIRM4ixFFumY14Ap3srMH0gmHSZ 6QqM7LdZLQZnsGLtenW/XPBeB4gHEWUDUoQ4vt/qKABjg8PZCgI5uSQvlD+XTXIsU0sWW4S65xl9 RKz1yeaCYTU2bE4nMBv0x+seaFQtyeEo4oOaRoxF02pHhEZGCTUbKZ/GoXzAsBAMrGFV8vl9iAmJ 0QgIuL0RGHEGI9DnwU3NLrKkYKARJQ/AeM0baxhJFChi/ZkL487qocqjY5b50xZ3LemQZ1XWnFhx xehzd7//maJ6lEK8E355dOWlU+Z6d23avenYp9Dz5ycevzkq5uftUrAoJgNATcZZXiPU9AV6DjKu aALxDDBHGcFsymqYA2Wcgt1mE4HdoQm8LRE1vyHDRJTBPhuMBktBai8OZy3JWzyw0XFrA16CEZzL kcNyfC6a+zhH5TBhgpJB4fzBghTJyDru5W2Z3K8/boSNvwQgUxd61naCh/wvT2CE/KXdLmZs9SN6 pNdzmZZCzHbChnBQsjXbNtq22XbbmP/H2JcAuE2d6+pIsrzJlmzLuy3Zlixv421sz4xns2YymUy2 mQGSkIVJhiwsITQLUBpy06w0ULgNS6GlXB6Ucrtw6SMkQIa0faSXKZReAnm0pRsNea95FGiH0pZy e1vGueccaSZJoe9ewpwjyZIsnf/8///9y/lNsDw7jjdPsu+xZjYYK5aKZKH4g/gxsB4wKFy4dRgH oaBY7ObPbD2zFWpPvPUm/0Hu/e/mjET/HDZAuhGchpITiVEeKkyUa4R6o0UsjuM5iKXaoRXSS0IL pFapparnhCiSqCjxCNmAfm/FC94QYsumf9aoCbfcAn745I4bF/RUexia5f3RFPlZau70jasDSUpR QLi0iLx17dziHccv68j3t8WtERfntXGl2uM3rkUrLRY3B6lfQE4qET3EIvBD7dIkb+caLckD1lvy d2eeop+xHs48XXhP+dOAzVax1pg60xUbNlkg22asGalDGpJut9ycvd/6tfzX5ti1IaU/7sgEeILq NCtCb8ZRZHurbje5FGO/EJzyvZq73qupqWqvJkqw8QaqpV6APj7iDlR7Jyha8woCYlQh2v4Flo0W SUorlqvUBBXRWDiPy18omueqUW4IM5y7gXrNBp85NgSGhgKdE2dPYgHs6ASdrYFtZhJsk8ygiHQc xWiZln4NXgQbrlHsB1y/1E/2D8V5dJDHB3nA8RI0ySYokyao1RK8FVkFXFWqklUtruZa0PdJ8GiL ls5UWxDU4lo2txxsoUZbTraQLTcuhkAL+YEQWDnTjajOTyGYbbTTY1s/hDNlCh9GOQKInbunczhF YAqBLwNLCZoUr+ZWTOXGdDCkH36G6EUOTTh+SCBHpSoUx8aSjNmlGQjl1/GkgtAph4JM2GGAGR35 EHyV9lZ8wIymFpLd7Xqjp5Ka9XNa8YSjdM1t7KnkA6DrSNkT2PzsAmZbvqe995uvjmy9aumer3/6 5Mq5q/duvO4znzp9aGxB5+hIW/doPnbDFfH6J79y24Nc+Frqnz5RTrd1rb/7ElNXRimQBe3mpbfF y+VLS4X5QW3b3L2l8kNX3/pi7w0T92z+xINH+kp//b1LqlUuWTAn6BKhNCYGCYLuwDkibzxDMGff O2yv48BdcWGtahokyVEUtzObTIyPURmacxAJokVy8Am+hXE/7nzWSYYB4VEk5wT5C82VSClSQk5Y FckhyxFFik+QP9fWyWlFapFlEIaXEtCgNyficafTYbNIVmDNCh4t3tfwaHPnVT1aT82jzYF/9U64 UyrDJpWGTS4Pm4QCGzi7PRrvqr7iAZwHxDyveEjeAzwIxLuPF4BUOFQgi4UtaCB6a+hFjsBb4R7e DffwhriHd8J9SwH3mhMyR4HQwVw2ncKH4IO9lwLF1PHUyRSFDh1p76ziHvIO7uFD4VOt0Xg1FcwP 64AETSw4Q3EwkzdQNxRs0CRA0m32v2491o7TLiFMgQAQH6aQAAO63zGOONjewDF8q8A2nCjLCu95 fA64B0WuE2WvO1FKhxNN3rjQOBfmGEMgchvKTIIz1mWkoaM4Nop8zQQ/E4zZNZOWqR9L1cBzi3fP Xb4zk+5pqq1BtzsXTi9q4TxdTbUr6Er1mhZN/+qiOesPPNS8+5qaWVHM8dAG8OXru+Ltc5v29cGE RVGYmO8a6umNVQuKjWUhyJRNmwg7ESF+ofnE3S5/g3MRbiIiuXg3H2H8iuRGkDLhUCQX2pADihT5 Fi5rxKA4crWt+jgDGI0AbIRxu2xWNAYReFS34jQqw7J6jlc24Nfg7XGefmcNp+3HZH25icePe62Y L1UP+cFBPyD8vJ/079DEUZGUxHHxIfGQSBfFhngQbhwXT4tMdPg4FDyQcB+MGVEBRDZoxRl6qDGF JQke6gsTjC8cZzimat/KVZq2cuVLhTlNc68oFPpNm/ABTVvV7JoOr2unFYVM+NeRCbiZhNyZg+Om QO7kCfiybjRq425wyA04E8EQvGTiGZ5n7FDF47GDut6Exw6qfh5uaD4ZXsmYbMSM0rajkbHrI4O6 I/lq1W6MEOo1GQ7RITs4aAeEnbeT9h2S+yH3ITdVdDfcB93H3afdJjc6v1ytov7pfKHqwgOEJvgF IzSTRKLPwa058JHhOHJuGBb99ZOzL099fy16efj2iwiCuQFq0UFyWJPmkcDtljSb2G7hUFnRQckD GWeQAW3tQUWCRt5PnkzkFSkNNzQh0adI3XKCUySPLGspkFCk1AT506Oy1gXaFakLbmtZuV+RBmXZ nMi3xc2AFrtbr6DFK2w22kwMMt1d6ZTgsQ1pUCdhZbhUTFSJoYeGDg0dH6KHIFBycpzEkVw2FIRi K4hk1IPBZ4OvBCkteDBIBt+OJ7KFPPwojz/KP5t/JU9p+YN5Mv82wbVL7WR7tr8PK/Boojred7qP fKjvUN/xPqoIm5N9VF9w3tAEecmROBIqueFz6TlYCXZPz/Rj3bpTCmk9I2OigTLhkNtKT1/EuVR6 qqkhWzC4VYrlcNTuMDElNaKWTQURMOaoPSQC1lFkWkUQZkUd4s44H5HjgJi/ZLvmlmIWa8wipkyS NZ4iYnGLGWCnJpHDBpIyPnR6iGRYha2y2tBrdtOIacQybB2xHx8ydZAjzAj7F4ZG6GzrNt0sGkIL O6J4oI/w3gYzcfbPR6Cgwz0UfxBVvjfbuxz6cdjjfc6u73PG57xxHezR/hP2c3FfDNeRneXV7ar/ WiAi1Gh4RMwfmcAvLt43vPKm+Ojdo5dfl0/1NqP1sFvIRXPL8y5/XzOSynNCMZyOF2vwMxHLTepr O5bMWbJs5eiKW+9t7tlUhXLSlApfDu7aORBvNJq2DaEk4gK5fDG4a5emeKWFTdu6BoOl6SaSx9JU 19ntkC9yJI109ltP2etWBuSxi25hbTQPTFBfJxnqZ+Rr1I9DlJepQU1OvQbeCJNuzknEiZzk5ON8 7nHuWc4CwhFBkThdf6tQZ8sJG9TnWH/HkP72ylCr52Q5HotxnNMWvMJE0eYwNPWPnEQBhbNPacsC NbAdGsmMDWt0r1dAKl2Ac58TQEx4RSAFpN4FqNoFpNoFrdYGG6iRBcQbAlLyAtLvAtLvAtLvvAAE pNQ5KX8oTxbzWyDbQI2eNzQ67uFN8oZmzxuaPG9o+Lyh4fGYcFCz5yN6umk2lVJnVbsKiupx9aRK qYZqVw3VruoqXamqwZZzKh1rdP48lZ5DXr5zcwuzo7GEDl6wFar07vO8/Rfo9Ziu12Mzep1Dej02 o9c5bJMhvc4hvc79rV6HKHQbsjbHtiHv3cxs/piJ/NE5+9zQ/kWrPiXwcEqman7enQstW5CqNVPG 9Nw+PG/DwvrDzc9vwmo9GVwHHrquO76jab+6w3zBNDRWnx6F89BBxMESLfBCCKRY4L7U4lQdgDD7 VbPVYo9q9Izfh9bUXJWjAR2Sdb8P7ubpXQN3R+o9VdRrSjpXPS6flElC1uRxGW2aNPlBmZT1RBTt pB3YDbsf9/DWqH8amvv2IMpv2/1kqtaxFUlOnXi6h8jAX2hdKl5g242JhMXhAIjzSTIpiTGRZASP 10MyjBqOhCLBCIXyVVLwLaMi8FndIhEwR1MoXyUFRMopAo/NLxIRkz913nrSXBYttIDCsJwGdTAf zOe3s6YtzC52F78luJs5yB7kdwe/Tz4v2XaZtzi2cLsCB827Hbu5gwELCitvXYFSU4xAMnb+uf0o 2iPMLDxtw+Ee0Lzp1Ws33PSTH555+5XKfL/TPlTIiymHoCZD1HOffuuzL3zmYZB+7kWQm7f4Vz+4 ZmzegmCiZw2IP7or6kUUTDUX0PBECOqL4Hot6C5akEOBcCGXAu9iPEUZ4i0FOfne1eyGL8FAaFpY zu/3m11uiMaYpCrZGbOTz4CMFg65yzp9y4Zfr4w9CpALR8sny2SprJVHy1vKdNltwBKHG9qgJVZj R9nj7EnWxAZLw1t1aw8zC6s7zVjDacYaTjPECd16Dj+iKj61rJ9aNk4tn3fqBzjlGCNt1CKGvMAb GFNbAmIwmVOjairZEsikgCrCJhvKp0A6kpz1AmJFCOnapWiNeVUZNbsCu8Rd6q4W+nphV3BL9B/k LalduZuF2+V7hS8E7hPvS9yvfFX4RuJR5Wnh24p7wAuwRxBlECRnsgdmOTTubWs3lovqPqSUb2Z9 FORn8Li/NDj9G4yawC3lyvxlV35j+apvblw8p7V92do2uVpXtQ19a5qPDFUDySQZ949Tv0BYcsdQ rLj3/+3/3G92JEKP3FRf8ts/rOi6C2GshQRBfQLOgAxIQXtftdftAsvrLAUFsh3l04WhOWxgPtjv PizV8G5U1A9zPO61lOCr8jlwr/2OHGkPOlxVLkqIREaK8iKfYYDX5/cTiYclEUNV//NSFENVWZEy aDZFZVsrp4ndUOJF2hvclUjJEBlGjNq4McJ2DKwhaLDm6B3mk+bTqBgAOKbZiQznlyB6z8oJfb4l sDao4ij5kXBMj5YLbl/1eAJsmVny+vPssO5J0LEqnEDvvz82NcWf0dF8N1r/gyaHGU8O7EbKncsH QnNAF7czbngj1dTr1123ekZhVU8pfHHs9r6OOX2F2rDZ5oiGMt4YMLPFjqa5J2exqSXqaz+6c83c xpwFAzTjSzQuv+EnHXU+HKQgKKjfRJpGfZGQKYlXsp0hfwRp1Eo+ql1mL3n5Bs07MgIfzdCM4BOe Tz6v/ox/h/8P3pzhk9kOvi17wH6PfI/yDftX5An7k7LdxJocloyXnWdfyDKaXWNJd6tE3E9KACC9 A5Cf5kGcHTBX8xD3u4vwQLX4x1xACt4flkIhJFjhKXeEQGgCXKOJwft9f3S7TWrO7BZVt93gY83t rYJVKK/19JNWgVmKNjSbVSCX6qmr2M1r56r6XgJZq1onlN+SEzhDXBUUqyPVNdXN1V3Vx6tM1W2J oZugllyqZ4po8GJ9KxHKpGe8xEZCGYqzpIMVJPKRxN+aQ0kksENy4SlLDKpRtIRc88NLLJoQb1i6 vTJsfEm4C9/N0KxIRXywDQUQZi6Nx3SL+7RmhfeIr4bXozc5Am+Be3gX3MMbof7w7L1yK87kcO5Y EGjpABzkiAs2fBg2KDNVc/iMBcxEYwp9kSiKXEOcOPt/j7CC3sMzUI8SWfGJ+LxnCBOEXG54rkmE J5pEeJZJmDkFLaEYy83kxuCF7lxRs7kaRc3KwUZfNb0CnaSfhb45mYePBln95BG9h68KoUcyD0EI 3PuhZoUbyTzEJcmJs78/AsUp7M8cRZI4AmXtOXS9gtiqL6ceQw6y85Jr6FlhBrlFpmbzavT6Cm0z iwzJz3OJnn19mU4hBtSx4c8tm7NFtMd9cT6Rf2Cw1NN91X35/nv+cdG8sMvtC1DfbX73c1e1K+Fg 5oXblg3fO5q1t4LR/fu7sqXBeRs7Ll636fEkx+EfvlfP/pG8l54mgsQXNedB+0GWxI2dJYIT4GlI H1oQKO8+EjAxO6roTdm3WTc47WgpvFOLmuxPs6EwoGmCM0km0pT1+LzbBcGjwdH3oCnFQ/ut6Dnu OemhPMEQki56mAGCxfcxHoQAEBf0gLtEY/rMGMqewZGGboDDfPryI688G1/FggW5q9Ey2YlTpziV 7+sUL3p6xQ6X7aZPP9FPTzcfXTf97EXF6Drf8XU9iXvBf8grJrejd22cPUOXqa8RCXDXM4QCn+6r 0CJQTiqklQ2zWXY+S9fZL0W+EZmI0L8zv2shEygTK44azkR4JBPvod8wg7NmgJwJsqxb0CJy68km xmQLbrDabXYikYADwBBM1tDgIoMAPgMRPwNBPoNAPoPwPYOgPYOgPYOQPoPwPYP9dwzgGBBjXmFI guEZkkFg36Ygu0GBOF8xcL5i4HvFwPeoP5zVP4Z3VgyYj3otCAHGcQVIyiGFLCpbFFIRJC/wZjkk aI7AGzsNlO80UL5TvxmWQx4I9t9zgqLzuPOkk3IG5eHZ0CLWEtiTd7737m98eVCNTM368hCqxJgf JZnhij6YKbbN+kAY3UOs63uD6ngJUqpGvZTuae6b85lLRnZkU71gpycTVqLpDoTNpxXka9s5Ov/y vQ+D6xAIn96zvlP0hEbA+4Zl6IGI/F1I/QjYr4XcJEECN+EGdElc4V8RGBWPsqfF90QzShc+7KiJ 6MXViFRt+EZ8yxjK7LRIZtoP/OGA5NepAkwS4+O9km/i7K3aRo6IxMKRyCDHCxzHA4JYzTnhljPi BATN8DEoIXgkLVGIluTDfi7Mc05gikDFaDYzTISwh/+d317iNG6Uo7gx5zsA1WjAKigGHgIkmkyv AAqMoic70j1SxU8YllNVUXNwVR77506LNC+CQ/A9yCjEEtSR+Hchx+V0aryPMtCmg++PvR/Qy+fg VQy6FwSlC8PNA4UcSgg9YCoE8Ebu49avz3SYeDgFVPOK6GFF9LAkj3KNUAPnzunDQh13XtT9+bCd a8wkEq8wASTiIKTTEyo8Hiz09EVmAPym+b16zJ8Hvy+6Ai1f2lHL10FrS0dH8/sR8sf75JA1mXT5 xOQVzS+D4t42KUUmk0zb/ukE4nJXc5CagnQugnVPYa8ni6T2//R4e1EywwJigWMotCK0Mry8sDG0 MXxV4dbwRPj7YWfakxY6iI7QIDHouJK50nwl+8Xi14mvh34SdMC7OooOtuhkWLPEeIM+ycujqoK0 BJWLRxKy3lRayTmLxcFQUAiFgqzDEYCax7EaLUJxOAkA4sVQ0OlgCbM3VSQUtAlMppDyTu4OkVPe Eb0CVAEmJkTYx8uny++VKWwVOIR0tez3hzhv0Ut6ITk1vymTiaWqqYEUlXoxniNMJ6HMDZbK50g9 jKs6jJ2BohV7vnLbZkm9mEfJFMjvpUdu/HV3/YClkNNJ7jRIThhhnf9P5QIL323pxsuKcsQYJKNB tY8QkTQb3t7ZWiGQkcEfmq8O9BXA78vp1oeu7Sr3gnqhc6D5pw3luVddcuW8amsPABYLFwin21Ty qQeGnBCpJwLqluZdIPyFrmQLpLSp54nphc0Pu5esmdO5SJuj2u3R7L2QRmd/Bx6gedJHUERYc5AN ookqRwXpBXNxoRv+TaKxGJW6iNfiNP/XN+g4eGA7AZoHzn6PfNmEaqBqmvh9ClCQXo/rFago9FOO 1pkKVNP0MbJA4pzr6b+pQnVgJ6pCNYbrUL38Yc9+6jnTVX8ZM30FzccugqAHTdcQncT/1iq2XDqX a6E+m340/e30v6XpjcoPlLcUyqJklE5lvkJDE9MLDUwvjSxLORFSJC+2CUjdj61djLSOALUOFypW H4cm5TtVNQEckYmoGAUEgwxiW75VzQFAZh3QcmTf5iLR7aFOwx8bLkKYGnywG3Tvtte6uh/T/ae5 seH39dVlSCl/gCpc8O9jDwCOJfN6LNll+Et1tzWxdSvYthXEz3eixC8Ilci1SnWmuM9MxoZhqSGj ADxLihmtGWoEueafnb7+pm9uhNuy5fJTd629e86i/kZQTrtCDS2eczmoh6eVNQ1aUcwp32py+/SB VX5oaStUyruO3L7un/7X5uqKXOt8f1yNtjt9drc/VlZvQBZ8Gxz5PjjyKtFOvK1xhJkTebMk0kXL jN1+RSKpSJKMrXdZDiqSKMs8YP3BZKbCBXIVVQCqc4JLp1I8zzGSKJpRVsDVgUAwm9GSIPk2cKLF XCS3jW2fMdiLcNSDD9ZBHQ5xR/1jhnhsZoynZpWinrwPh/mMwX7GSOvGd6nN5asl3WpZrXraRaLV WxSBz9/mqoig5ION7obWjW8jqn8+FVTdBVZBytSoLwI/SMZr58X4MUE4obfpWxBybtoExl64SR3v /CmXaWlGcjkr05wGVNjv9ETrl2VFSpu+9fIQCmSZ097LyRuvfPjQNo7/684lJYlUFDoeFi6CB4+G w/60z+ViPQOl2yEf4DgXlMs8cZ8mvPHfjtNEZIJnzo/ToJ+XIfU4jB6eSejhGbvHVzUCM26cEwVt bsk9fi5CQ7mMcFXugzGsFD8aivloIObwbCAGgoyPiUI9R7eCt03LCTsRe5JBxckmwOHD1iB7DDwC PkfoGfvThuC5oKpOz7JlPfDPtBx38A9JsGMgCe4lUQ3cwHcIinoV3u8a+PfaEyZQ5N/X6+mh+pL3 NhXwOjyX16+h3/yvr6Hf/MuPTC3nrgHE37vmT+e+h2geA4PnrrH8N66xEP9+zHLeNfzfvWZ69hqe +N0xXr+GbP4bcQOoUEsIjggT0W8TFrCO8MGxWfckL7ABmiieeP0EKE6dQpdi959ehg7ZSWY8lV08 UjSgcumSW25Zunz50ltuWXLpLxlXY/nyhosBZx5bv2bN+sceWz8+vv6xA8Wbm99rPn9zAY19lNhP /Bp+r59QD/OEewKsgzY1aSb9gGOdLkAUX/9l6wn+l5Og+PLL0y9VyqV2ozqPS+egVLKCOK9S+XWz Pz7MWj12V6TiBmXZzM4V98ci3n5wZYM1C9L26efmuEWoeX5P7AdO+I0i0X3UT3pEiBo98GuPmknS wZop/wR53VHgYG0LUbYXfO+pl1r5qToonjrRWuSnWouVE7hoFTDrE9aop1bBmRZQxuqu0HbgLDRd j4Q/OVBdWs5q/3rpwOLN7Xu+2OuQvAwJVvzY/Wj8zg3VgYsdPyjWLhnf0XstbU3ZoQ5s/hbSgacG CYm4WAuT/0J9iyIpUYpxJSjuOBQGJsUAVJVQjq47HBAj34J0gpeR1z0teY+7gMsOn3jsxOvTp6Za Ibngw/Ivj7UWx1r5E2Ot+JnNPr/hwEUUNOxcQxp5AN/ffD541+Y7tq7d3egYXVxY0pXJ9Xxm7Q5f +h5q8M463T6456YFfa5Aubei1HNXVVUSbIICpvkWfOoQtRROmRjRd9hk4hAd+bC0wnq1lUxbO6xD VspKYOL6pajVbjcFPSZ9VrnqcETRw1bGxirwsYv6DDPjcpl/M9HkhFfA0yz02L3vHVx4aSQ/7/J6 z+i8LTsvWfHzy3rHvXGarLxx4xUQu3Ro/yC11a/aMad70ei+t7e/5kKBa6L/7FvUl6kpwkvkULUu M4WKmEGNkszrC/8mKNtRV0Jl7T6VmKAFnLQDH23MXS+OYVki0qgMjpxAq296SX/CSXoFkcZDWKDB 1OjuywdyQts1X974iUc21do3Pbgt1ZbgSItLKiYW9FI2t5ijpvKLr9j6qfbxY3euXHnXsTWXP3Pw 0kvarj+627dg6bLBll+/qSxfsaQvZUSbqQj1GuTIzqNBhx5mQPUTfQyUe0wJ/4IXzRBBKWxz2iXH BO2Bxvwk/B8Ux049D8Ho689Dfqm06iFDo3AAWoYhkmgZzKLFlbYQvWiom/xBY2CUDrVVhqdLSqyi xcm1/W2KUpsz/T/iWiWGCvYTGnyWr8KRyxBrNEfaLJsomuZkSSZlVPgtiEAP68+ZzT6UvxDza/5R v8nv97mOUQoh0sLhNE2gsolmqFIaFcjIjemXIdHHKpWiCw8unKUnKpixkkZlml4KjikcaidpTvWa Kq0iiSsQeSlzWw8bG/jw1B3f2VqQakNZX7lS8sasIbV90fq+4e0XZaubH7/p7fZK85vlTx/au641 N1SNWgKFpNvf1dNViGTnX96mbdq6bxlNnD1LFJtbqAeon6JCLmffad5OWJ8gdMrX0KeN5j9SR2kX ZSYiBNH8BmE/DAhO/xh/fiW0bl+FKJYhPFG4f/bXcJJBEEqYCeHsOIHOMOpMkhBh4v2ZeokM+gVy 9A16/T34eQTvG3kpcB9SH85YVCs5CdHUMLGOuFVbsIpftmyEn9OplXgzIBZneZstMMrzsQ0BFzci jZAjWQhfiVgsRsYu7ukZWR0D/L7F8gizem9ucG+tVsqBkN9sk6wBSIbJ5uTkZANSYAraKJOT05OT iBQVSJWXT0xOj02+hHYn4R8/fWLyJXf9FCZQEQs/GU0iHI6mMALVd1pnUhqrvTQimL+XqojUrPpF slJ2Ul5vJR5HtEUshOUn5CJ6ZAcd7qxN/yWVEajmm5QnrTa5YsVP79wpd42uWN0yd7xPZZML59Td lSU98UU9pS5bwM34/FawY3olfKtokOXY1nxHd8REzZ1eHysnXEBRQLDQlyE3T9+Z7WsJQpjkbZlT IDevvWzR1tFK1M4HgtZQlKOBN1mNtfbmZEHhhAAZKfUlX33AZnPHYnzQ67a7/OHyvBaj2h4zAqlx BbGL+Kq27Hpx8+ZdG68Uu8W1FovTx63NioGAKg4Omq7IOi8dHXWK8F9hjypJu8CubLmULmzcuHDh ru0FTtx3xdryLmb73vbL9vb1dbeDdDJgMXkl1exHlEHEuIA4lRnqFKEinKVOvVh0VaCMn35ZZyN+ Gh6uo01+stUgVfLjCPX3qEbOUM3gthlBh/SczouQeKjwDESzBUqn38xx0x8olyo3i8m0h2q+RXsy ajOZzHjo5luQmMkmW6oF6D17+rbdv0Jb3Ze2utpHNs4dunFpya9Wwq5sMkiZWas9mkqahxYrzFO3 PVn78AUSWAOyz8ZyDn9cdlQ6QvRrqlaIQDqS4byWRnRNa/nwx+wLuTklSOclS28Zr3gjotUmRoRw aU4mWoy5rD45bON5t8Pq9njtpNp/WdvtVlcoNxwGQkRkuXDQZ+cElm6Ze2n28yh3FlF9HaT6XGIl cR3xsLbkqnXrrusWV2Kar8Q0X71KNBHZkQWDzgGd6DdAol8HrsNEn7d69aolBZHbt7K8ilmyt+/a ve3tfQMD3X1/n+quj3Ll35Cdn6xUpl+G7QV0h+3fozkm80eI3q4TG9McWiugpqrt5ySv1xv/WEoz /nyqGVQziNKUG1I3mcoJeFtVmq58JcTs2UOSiz51zyJvz/zRFFcZvmZex0L1W83fmVkSODi7EMt4 h4YTpuZ7H0PjlFZANKQD2UYe0bRFy/mhBRAq9mEStzSyAdMsK1+09vaVOZKTEzYx7LHbmxd/x+oV PFG/YHV6WKYwek3P+CxlIyGf9TzKkoQN2qpx6j0C/VbgI9qA1xuORSMojV6COCsskuHVLk5wuTiH B3g8sLdYRJKF5CUHWafAsk4nZ7OxLCfF1Ogd6MfIfE6kHTTW5WFtpDnsk7wWLGhbJ/G/BpKmY5Cm IFisBIqIzAf4HE989wCqHQPgIcTOxTF40LKT/9EB0+Skc/KAcxL2LvQpQnB4tUXlXMFKY6U38gCl KKoC5KLFPFhvfrU+mgTLgmBjYiDbJPorJkvf7TvfBcImQXaoYVlmVlxK+T/89oKGLAt+q8DfB65u voFXNf2Wpql3oR4a1EIZwuOBb9XC2SVo4GlQFzkZNZ7NqnH4lkeR58mp+u0QJbVCUYOmLT8FJ6AB mE7A3RNIVRQoPG1QcjGUJLiUoy5V0MTDdehoOsV2jKzvWHz94tSX7ikvG12ojjy9bf/LBxeMHpy8 Yd74QNEXViwp8ub61SOl/hsfWfvSaSHbyK28aNHQ3qc3b/nXgxd7fJ5QDFE0CCl6GfUT2KeJqhb2 aImEKesguLSUJtNZk6QSUsCWVlnJieHSFPLOoQc+hdkMYrx2HS7BuY6WzRtiMI44Skd58HgwWY1z jkgJvlVix4sHh+ceeH739CvgPrMQD91+f+qinUsrsi1SyZK3ZqpRu9z36WPbNzyxb9Fj8bTP/L1X Vz90Qx9CVE4oWo7BJ20lbtOGOSuwMmssmy0PWiiLhWjJhYOhUC7nqKajCaNSYBZFix9KHErQiTLT p0cpYgyVY3JMK1AdIas15KCEVjUtZeGrPSWoUYgLjTd0+aHMKKJincXi2BjU8FCS8KcMjXKiwiMU PnbiBLLGMZFmi84hpIgPUIbIQAOAqs5BosrgsJwZqEi0qtrHFxUtPlXs6Fl/USOo5D/cU+6SrGy8 M09tkO0ZbVXPXaTEtyzsavauXdb8P4lcwBrpXNXbfEHm4+U4eWeiKDrl5q9Lw+2iMTI74ci0EJu0 djPNKCpaqh9TKUZlVEch4QsLs2OCq0AwjMehAjoJoFFOeVrUhKTAIXjS55G8NgyJZ0bAmJ/o9V/i Tz2vy9Ix/gR/4gR+db1EImW8ufe8dz7vpTMrN1KQ16K1xZWwPd5Tnn4+055wohdxUZtlZ3FwvPcA aVl/ZTPfvjAvNH+VhkhDllmxNUUeTJUjdrn5Tudo2UsY3HYb5LYasVxLVSGrhWIiELNCMGgXhHaD 7VKBsEQEgy5GbanVyi2Q9Z4SXKqUgIxXmWqdZbuXEe7HnIc1wthLkLIX8p9RKwBBLhQBYLwfy4uW ZKC+aK028InhXLZVvqwcnRvtWUA6uzuGT265+6e3D4ze9eJN/eNDVa8/ak2SN/dfszDTuPGxa/f8 c1XO2J1vVDLJZLb0rppbsO/wVVu+d9cSt88dSKAfcoSc+WNI1TpxlVaQ5UrFXC8puWwkVi/VyXqd 7XJbWcEcNrLi2IhKEOak152QZAES82jJylSkVvMsbsUtYllQhNR8fVInJ5KurxvzGheKN8jYNjNz vWgooBo8f+98Wv8ne18CH1V173/uvbMlM3Mn+zrLTWay75kEshECDBEhCRCCIgISSGIi2UhCAKVE ccG4VxZppEJ9leJSnualmFJrbQWrQqhV2xRRW7Wx1SqtlGdpS+a+7zn3JERLC9q+z+v/80/O53fO 75577jnf33LWm5kR+q2uvKTRs9PyAl0FGWJCRr7DJNwc6PCmiO7sAofJpuS4R3+TnhdrEn7m/2mq 1x7odhfME3uTvE6rG96cG+//gxCUlOe0uN1WxZswuj4tLzYAvDM3UciiNo/EMDUNeoglU8qiYm22 cFe4GJ5qlMWx35WwBrHBaUCMpb8ren5Hd5ju6A7nZMd9piueF0GcNvpGcr4i2+LzE0T6PkC2KFNS 3AH2PIxEGXl2k9ttsudljK6nqMdGoINAopDpZdEu7BqM8Z+BI4xBOahEJ4ouQkeT0WMT0LAdgnfo 70CKGBs67jx3a2phnBzsKUgSa/J9ybY0b25F63xvcJLb6vImilsz82ONABebnzG6JltJr2igvztO v9m6AegySV3ZFKtgTCWZUdEZ+tjIICUiO0KMiEjITo9PUGJiywl28JkxkRJR4l1AHB1lUwLTRFcG YUM8plusow6fO0xXUpGFtPfnHuOD3/LjXmSNUq0KF3AGt+CmO52Iz7pQqLRfeDZliiLLrlzP6ImM QsWi8z/o9j9hqKjy754906xMTRe+/4E07A6MyfKMNlFncbvNDm+y+KNzu6Rpo52VZW63r1K8ISFX kd2jA/Qc7A/qb3R1kNaD3lEomyzl9JdPRBk2KCNCDhGCYCWREHuiJ8JW7o6yh0e5Iuy2eCJbrbIc EegxxhsCXEZ+BHA4CItIurwopJ/fpvY6fgx7bibx8uXHli9nJ2nCuLkM2vePne8rSZkS/EfaKceX ZAqNvlkJo2mypzTbv332THdkQpzLJtwp7BK+6vImhLnds+ace1aKHB1w53tCIddl4q74KEeQQaA/ 7k3mqCO6J7DCCiVJZEaZh5TdF7Y37MmwV8J0M+h/4maHiWFhKTYnXW+VLQgUAqMT6Qrqv9yJejM/ fVmuHb8sZwcwE/YkdMTSj61J2fRcKuqeqPzqT2+58Sf3L6jeMXRDx9CDV/tfS5pdW5i9Yl5W9LT6 eaWrfB7hg8Zn7l5U0fv9jrU/uKOy/NYf3tz17Y6CzMbHNi18eEt1aefDQI2xShqCNZwkhczHAFxm gyO4rWkugwY11RpiItYgq2KVrK5Eh8OUkhjsCqWdVm9yGcbnHDY68a6i+dvH5xfnY8cy51cZ7vzx JQaGobiC1NHhpHyXPKNSTKr6avusnMY9reu8S5vCshcUJ+3HgGMBJrMzL1nc4fO6Y6c3zJ3WVJk+ t6kx8/LcWKZ7/y+he/qBlalkZVmm1UrKPFV6YbpeyNQLer3ioT+0LmFhXZgdLoSH2zJd9FNKC2KE mJREF13HBlgCrUHexHA9m2roOR03SG7WciaOl9oliB/ayaLRKbGvnmKzSpK2bbiwmYrb9jYETbl8 aV5KVsaG4kV3dyxxXnVvXf55qyWXryzIXFGRHVNaN3da7ewE4YOlj9yyLCR9br7TUmwLSa1onhGx ZPNDy9c+21s5+9bnbu56fO3U9Gsf3bRwz43zS9r2ajbU9bIelUXWlxV6HIIj3h2/wukIczodbo9T UZzOmDKsseISFINgsHlcHtGTag2FYQVrQqIDA1JWIlYQdPJxKrBrPDUs3ZDlarb1fjx2znZs+WE6 6dLzVroJw/J961cO03cbn7U1623M2AZjKPsaJmpx7QwEFpfjpsLiyXmKlY4gYlLb3qbcdde9P7/K /xX/h6XesivzI1rW5+xP88YGinw8+Vpcut3iTixfPW1pV7x/sEVyC0/M9ZRUJi+vxwiKvictQd/z kfvLrrBHeYKsNpunrIyUtJeISklZyX0le0teKdGXlJDyvByvN6qMKF5B8AZ7segrKywLT8myCbLN SU+e7eEGe4RdtOsLE1NyczNTzOGJelkO1LOzMLYCGVuHaI7Bv5+aLTY/pgsRdrG2ECoa0s7PQ88v OvK1RRf9zyynLpIeGGm9nH/nEXUq2i0Mc73LeipKV5Tnhkbbk5JCSquvLV68OK/muramZHtciD53 1b0rpi/z5YRHO+WEpOAZV3fMumZRzoKGNQ0LcsRnZq5dlBkRE5Ee43+ssGFeesX0tOI0T4o3MSY/ zxs9q7MmOywqTFGEjZd1LEifV5I9IzshObt8Ff2OTIwFA/AjF/rQFMeV9mvt6+3SfLtQahey7II9 nGwVhDJByBEERRCgL/ZlBKk27QvEHSTCSPtS6ECQ1WUbm83fpDPoMfjN2/TbuYeCtISv1T679mTn n+7gOGkgSWfPq8y7zKwUZY6+lFTgDq7Jviw3VpckPSAeSF1YmjialDzVbYNjuOA8b6XMmJ9If7xQ ICEYgTuBPwk7uvjw8KhEV5K+PMiV7SpzSS5XCv3+EjEqNVQODyEJrkS61uq3B6DDD2lLLCHrmDYA jx4LoocMQKnNk9rSMXh8MRmsfXqUu7muMzE/3vbqj6/d21pYukB0z5m27is3Xi+7SzKEtdJAUEJp hr/2pR9nXb11iXBmWr7bXTrbL2+4Yee9wn+kTksKcTPc7+m8wG0n15cVmM3BoaEr9MYwfWi43kg/ ESUYjfqYmPDQ0HKdGKYTQ3U6vd0uitkY2YItxgCRhMe4Ys1UGh0dvg6f34Vj872c777Z1pv+/IqQ y/beGNC2moLYN7nSHCqrwYhFQOKYkFhEh4ZO4f9vofPmLU/zP5Pl3x5ZmiMGFJYZTEOHZGtpsbBU GljVcO5PUlthitsdH22NCPNHCQOKN0iJE5ls7NyB7nB6y2bFxxtS09NX2J1h9nTB7oxz2g2GOYKQ Lpit6Vah3GwNM1tN5jC+44kg9iD6gVC3U7FbI8wBgsFljP/sbodJipmfCYs1DnW0oa3nzxmo9EFv HRuTNFgoZKJq3wen/RuJNOGkMF/i4mubiFApOjggY5qwJHVV4TNWd0nW6HdzpsVZfu+ani38RUkM 1Zus/VKCPSHYHud2SzVX+n/pfyltitOMyUoIis/znBH2Ti3G4GqxmcwxIf5hwvuYH/oIJgvKEkwG o9GM5bGoCwwLFElgQOCKYBIWTIKDA0KDZJuNfjlVMJXYSBIDqMRYkh4T2EaWjjJbtcGXCjmEVU7C 2P5VYMNJaJyw8XfVNy0vMie4zpWKKw707o5UoqTquakVa2b6t0l3r+8WpqqqtkrXPyImWrcAoIG8 8bNKElEWKKCPmMLR3eO/qwvH4iBNSMtHaaf4sHib/iZitE4VFokZyGkXnxKLWE4Bz/Ehp5blFPKc 6Xhqtb4TOSU8pxg5LfotyCnjOS71E3Gr+AqruUbdhJy1QFbMcgp4zmzkrGI5hTynDE/ViT9iNWs5 JchpFX/KakaO9m1upl59BVlEWsuK0tJmZSUnhwvu1KzwmFBrakwWwrzFCxfNm2UrdhWLxaW+ebNn pkWEJrtmhacGuhXBYFxYUZxIf0Fo9PCx6XRpMHZ+iREDHhf05pC2vQ4aPR50DIvQEHZAyXZl/Mwx InzMy8Z+guACH/1lCwk6KEae/82vCd/dZghLmj1zhjujoiQ1MNwUkaSwTwcHBKTFJs/LYB8PLooJ 1puDrSHlVfOiNprNPvYVb7mzg82r7pi2JCKRfnA4udAdZM8qifPt8W+bMj3eovN4TEp0g/CNLoeT f4DYzT5rFHmddDDaFWo1BlgM0l8/bIqOSUpIcCRH1+siiqp30O+Eo39TePgP4j8fhArhwfHwvHBK PCHNlN6nQfeCFvQN+n0Tg2GTYZNxtslqGg34SeDPAn9mnsvCUcsR64B8WD5s+zjok+A3Q+pD08bD 2xND+Orw1REhkeGRv446FGOLnRn7Ng325Y4PXBmKHGdDeMd9k/tPnk8TPqQh8Tf/r4Qk8QIhl4ff Jx+81JASNx7mTIbJMBkmwyWEVf8rYdNkmAz/hmFnypMpL0+GyTAZJsNkmAyTYTJMhskwGSbDZJgM k2EyTIb/q5BqSJ2eeg8LH2ghbdo/GbanvZFezsJiHurTW9K70zezcBsP96TvzFieuSRrNgvHs45n Z2bfnBOUc2vOX3N7tFft3lDvHd5P8xbmDeR78wemXDnl6amhU2+ioSCgoPr/IDT9fxw6Cm4ouIWF u3nYWbCnYH/BUywc4uH5gucL2ybDv38g9P8mCPEjTibPET3JJhLxqPcinqqeJGEkDLyHSCyeqjYi vorFyxCnIH8AcbDqQ+xBThYrmYWSPsTLwOeDH0S8DPFU3D2JOBglpxIHiz0szmX5Pjw1lZSzeA6L K1h+NeMXs5JXMH4JiymGyxEIWcxqXsyQLEYNlJ/D4nnsbjXjr2T8MsRXoeS94GhM/xZJHxL6GS36 dx2LJaYZJ7uS2GcoTUII5yVSTX7FeR30dprzehIl5HLeQNKFuZw3ku7xekzQ8AHOB5DbhG7OW8U+ 4RyzBf3L1+3kvEBsuqOcF4lO7+K8RFL0Bs7rSJjexnk9seizOG8gEfpizhtJ8Xg9JhKl+5jzAWSW fiHnrUKlfjv9ILhOQluyUeC8jmQa3mG8nn7ayZjFeR1JNdoYb0C+wXgV53Uk0VjIeCPVm7GH89CV 8RrGm5BvMX6L8zqSbtzK+ACuf43X9K/xmv41XtO/xmv613hN/xqv6V/jNf1rvKZ/jdf0r/Ga/ikf yGR/jfOQ3fhfjDcjP8QkcF5Hco2aTiwUm8nLeeAxhTJepp/0NNVzXkeyTbMZH8Tq8XIe9fDyoVSH ph2chw5N6xgfRvGYvsd54DE9yPhw+t+ppg84ryN5ppcYH0HLBzg4T8uPMj6alg+Yx3mUD0hjfCy1 aUAP52HTAM1GDmbTHs5Tm2r5Llb+Uc7T8r2M91CbBrzGedg0QNNbKtVPgMp56Cfgl4zPoPUEJnEe 9QQaKW+aoH/TBP2bJshlmiCXZUJ5y4Tylgl2sYzZ5VGikFx4QA5ihdSQRlKPtJK0kVZQF9lI2lnO LFx1gKdxLfKbWIlM+r0EpBlBgQc2kWvxfBfpZFf1SOtRuhtxHUrW4H4Ly1VIFdL1rFQb8mpRk4K7 9E4tqIu1UYcy9F4HWYO8NtLwpfB9vmTRRXHMBN+M1hX0o0qUXY0a21CaIujCqH4Fk6qTt6CQKWil APo7X69W6/k6F5BFJGO83kqU/Fv8NeOcj0mwHrW1Qp8KmY92GxgOejcDtAjP0XqbkbORa6OD6Y/W mo6cK1j5LpavkAqmRarPVuQpwFpIvLD3Vbi/DtcUJa1nHbMY1X8jt0YDq7GL2YVetzPZW3C3C6Ge aWkVe7aLW2Y25pMK+IT2bMeEO+1Mj3VoZTWrsYlpbz1razXiC7erXdOyqyHvOiZFHSvbhriO3W/H HU0CqpU63lYTr2E1r0uTnnqs8jeStzFtbmQ2b4KNFeZ7q8bbuhCu1r+p+9K1dL72unE7dzDf6WLI V4978IWl11r/W1zFE3RAJdFk6WLtjfUNWr8max1y1jPJ21h/u7CkmqZrP6PVembZNh5rUmn8Oly1 s1hhaLvHPVerh5ZsRol/aKNHldzsnFylprFeqWxrbeva2F6vzGrraG/rqO1qamvNVGY0NyvVTdc2 dnUq1fWd9R3d9XWZNU0t9Z1KVf16pbqtpbZVaepUapWujtq6+pbajjVKW8Pfr28ss+jzdcxsa65T kiubVne0dbY1dKVcUd/RiQeUKZkFOawsirKSCxZl0LKVNeP119DI11G7vqn1WmV+Q0PT6nolQ1nU VdvaXL8RMDqaOtta05UrmlZ3tXUoFbUddfWtXUpOoTf3qrZ1SkvtRmVdZ73S1QgxGtpwp7ZTaa/v aGnq6qqvU1ZtxJ16Zfbiihm428Eu2jva6tat7lKaWpX1jU2rGyc8i7SpdXXzujo82tWm1DV1tjej gdrWOjzVhAKrUQrNZyrKWONtrc0bleSmFKW+ZRV96nxdrWOlLwiJFa+jMnfUd3Z1QDroa0LzeHy8 rmKGILkJrXTVt1BrdDSh1bq29a3NbbUTGwXoWg1qfYcCedvQFOJ1Xe3rupS6+m6qXJRprG9u/5xE Fx3uad61rPPRQfVipbvIOsEK7oOLlmxgXfVipcpZu10XKyfdLn1fOiz9APFTlyxR0yVJVIH7jeC7 kUefWHfRJy5jw0gnmyy6WLe+uJQfoNOvIZ+ilQ/w9MXKX8FqvlipOUibUWPDJZVeAJ5qZR0GXm1o vbhuJmryolLqXLpSXbFulm6KrkBXppumm6crvGgLNZfsT/OotEIO+IuXpN7cDn1fFLMQTN6V3Li6 uJe0samqdmxPSNQ48jy58J9E6G7GSgSVrXEJqRTfLxeJ9C1CZur1FbhWtIF2Zp3C/lSVfWOPv6ay amZ2tkRuI3wXbsEWTxbpOncxuLuIIN4tfo1IYp/YB/5BEet+cbe4G/zXxYfA7xH/AP4T8Sz4P0vB RJBCJOyRpFCpHPxlEtb6UoW0GXyP1ENE6UbpDPj/ls6BH9V1Yt3dpesikm6dbiP463XXg79B91Xw 9+u2gd+u2w5+hw57Et1OfToR9Bl67K/0Xr0XfB72lpK+xOAjgmG2AW0ZKgyV4KsMV4JfYlgC/irD 1eCXGbrArzNgP2PoNqwHv8FwKxENtxm2gr/d0Av+DuM3iWB8xPgIkYz7jN8Bf9A0g4immabdRDJ9 3XQKq/7fm86A/+8A1BxwVcB6IgVsMGOXaA40W4lkls3J4FPMWPGb88zfAr/f/CT4p8w/BP8j82Hw R8zYA5uPmYeIaD5u/i34D8wfIf9j82nwfzT/N/hPzZ+C/5P5T+DPmv8M/i9mWNZCLD/CTuJ5ywvg f2z5BPxpyx+JaDljxd7bGmSNIpI12roY/BXW5eBXyCuJINfKtTDqKhkalq+Xv0J08mb5afCD8nPI /6F8hEjyC/JbyHlbfhv8L2258AUd9wiRxDEbadbR7MItAs1UQyc1JmjbtMQEnZiWmlaArzWtRtxg akfcbdqI+HrTJtztMd2EeItpC3JuNt0M/hbTbeC3mnrB32G6E/x90DbV82muVRH6TAOfbsae35xt zmYa+xD878y/Y9o4jPiIBVJYXoBmqB7CEUdYI6CBSGsk+CiqGSZNIHlRPEX0tR21q4iyemNHM6m5 tqN+DWlorF/VQTY013a1klsI9sflM6oVYl9c7aPrOsL6lR49LILzBiLTT9Yw3khsJIrpi17r2OlG EImekCNgnx9MYsZz6Oem0EZFzRyFOGuq5ynYQ2gl6Te5hJJYfiURMwnj36elQ7CQcOIgztXtne3k IIufY/HLLH6dxW+vqe9oJb+lsUBYHMXibBZPYXEJi2eyeA5drAlVLF7C4lUsbmZxB4tvY/FjLH6W xa+2rGlZI7zP4lMs/pTFfhqLBhbLLI5gsZONUvHETTxfgAskCSSRJMECKSSVpEFLGdhPfPF8gZB/ EFPPEPmp2t9yAuxLLUp/vMWEFsywghUWJ7BgCGwVBptEwBeiYPEYWM5OLURcGMLj/s5zl5onwuL6 C6ZB8KaLpdeSV8gvyK/Ih+Q0+YsgCoFCiBAjxAupQq5QJMwU5grVwlJhlXCd0CFcL2wR7hDuF/YK B4RnhJeFV4U3hHeFs6Jd9IjpYp5YIlaIy8RmcZN4F0b/x8RB8QXxdfFN8dfiR+IZ8ZykkyxSmGSX PFK6lCeVSD6M+TXSMqlOapa6pE3SLdJd0nZpt/RN6QlpQHoGC6tj0uvSm9KvpY+kM9I5nU5n0YXp 7DqPLl2XpyvR+XQVuhrdMl2drhljzybdLbq76EkKZo7DrDcJyVX0ioje1/Nk6AQ5eV2EnkUKU+/T 0sIXtRGs6JtaOj+Vp+e0dOFSLa0u0NKV6VpaG8bTs1radAXRiTT9FTHAXYT1zxAD/V7n6z0akhve ZkiETf3a9aa3eXpWS7/SqqU9V7Byuptab9py086bHtOutkRtSd9StqWGX/1oy8+3fLjFr13d/NzN r9/825vPac/f8qyW3vqYlt52Cytl2rpia8fW27c+tHVg68tbf7X1U5Zru73/9hduf+P2U71ib0Rv am9pb3VvQ+/1vff0Ptx7sPdlDfEdHub/wh1ztfTON7X0buqNhOjvf/X+M9sithVsW6pdb2vedt+2 gW2/2HZOu94etD1v+5Ltm7bv5dcD29/YQXYk7qjQrnes2nH7jgM7Xt/xF+16Z9DOKTuX7dyycz+7 1u18duf7D8gPTNGuHljwwIYH9j7wIr96d1fgrtxdWsu6XV27du86vOsjipoIXzPwVOZphKaRrzl5 yjX/YKaW7n5YK/dQBE+d8CWaXqHJ+1AjT7t4uoWn9/H0IZ4+wdODPH2Opy/z9HWevs3TD3l6Vkv3 GHgaxtN4nqbztIinc3jK8e2p42krTzfx9A6e7uLpPp7285Tj23Ocp9y+eziuPWd46tfSvSaehvDU ztNEnmbzlOPc6+NpFU+X8HQVT9t5upmnWE3GW1ivekc4JoqiSewQn8R6cYH0mG6Dvkh/zDDFUGJY xUIzQj+LnzO8YHjdKBpFdvU6jY3pCB0Ig8ZBU6mp3fSw6UXTiywfeabjtJTpOA2G1wOSAzoCdhn6 Aw2BNYFbAo+Z2s0i1hK55jctHZZNln2WZ6xF1hutB6zPmV60fkjrMb0oR8mJ8jL5HoTtCMflc/I9 tlTb3iBDUFewIdgTXBS8nd4N/jBkQch18j0ht4PeDW0PfSOsMTwzvCt8H70b/mT4IcRnIxoiBuV7 IuVIT2R15O2Rj0UORB6P/CgqJKosqipqU1Rf1HNRn0YXRFdF3xh9W/R90QeiX49+N4bEVMfcBXo7 Vol91l5n70fOeBi/ugvhbRpQigWU1EI/DTGYihy5oAWOVhZvcvQ5fuF0OgvolbPAWY5wn/NV5znn Oddtrr2uT5U8pcF5n3yP6zalAbRb+bnz1bgNrr1x++KOUZloSeTujnsDcxR9R0ff0BWCikAl6oDw iXqv8GfQX9V7RQEUoJ4UA9UB0aYOyCtRRmBv82LYOzr6Lq/QfxbPOvCsj73VWwqi79QOqo3Wu0H3 +s9a71Md1vtVn3UA9GvkjYDeB/0GdAr3fg/6A+gT0GmU+SPojOpDe42YR+n7QRtqp+/lPHjienWK 9UHQbtDXQQ+B9oD2gr4DOgh6GnRWnYI5XcPpg4w+4PQxnPSd4kG0cTfoXtB9oPP4fMDnAz4f8PmA zwd8PuDzAZ/vc/h8DN+9XxpfBHuzWQgqApWAlqmDwDUIXIPANQhcg8A1CFyDwDUIXIPANQhcg8A1 CFyDwDUIXIPANQhcg8A1SLzsbaYNGgxi2BrZu1Infe8Kou9K6ZtS+p6UviWl70jpG1L6fpS+HaXv RrklIU+jdZN60noj6HbQHaAdoAeRvxv0ddBDoD2gvaBv4N7joCdA3wYdAP0n6Du4R73iadAgrr8L OgT6Huh50GHQEdALoBOgN0AnQWeBI1uTBr4WhKtgpA4gdFKNg89Vh5k0miQD45IsYbb2Wa+HD25S H4EEj0CCRyDBI5DgEeuDyN8N+jroIdAe0F7QN3DvcdAToG+DDoD+E/Qd3DsIeho0iOvvgg6Bvgd6 HnQYdAT0AugE6A3QSdBZYPRwe/ggwQDzFQf8xknfiaP3+JDOAWl2uBfoTwL9SaAfgP4dQL8P6PdB 5w7o3AGdO6BzB3TugM4dQLwP+nVAvw7o1wF0+4BuH9DtA7p9QLcP6PYB3T6g2wedOlgfHuCIfBwR 1ynIhxJzQJo+HWQR8mqQLmH93AFUPqDxAY0PaHxA4wMaH9D4gMRnpf3radBZlc4yB8la7KA+rwH6 jn0Ok/gk6j6JUvT3sG2Qn75TD/6XjB+SLKsjcjQoVh0Bku/QPCChfj5ARyli/kKyBIoZqlecAqoA LfT3iDWqV3aAEkEloBn+Htmnehn+f358Cf6XjAZx/xa92MI9zgT7moSz5E7hz/7TmGksouA/Lcao h6x/9Z+2+v2nZT0o1H+aWDAXXYcShzAXXYd56CjmoaNWXFv96iFZD5LVo3Io0miksepREoAnqlBy BCVHULIKJatQsgqlqs77gehRf0Mi/tf6VgidFYR0tVfIAG692ot5tFAM9P9FtIEi1B4RIzEwPCmL aq8cALKqayDLXNmm7pYjcR2tpgNpOgm4JKljhUzVJWSBckBe0FnSAu2egu5CoN1TYpDqEkPU/WIo 5vIopDGgWJADuBTcS1Fd0P4paP8UMB2EBU4B10Hg6ZZD1KdhjVPAdVCOUp/GnlliM2jjv0RCM9fV UdTyE9SyFhJPhcRT8eRRPHkUpY+i9FSUnkpCUHI/2lwGiU9A4hOQ+AQkPoGn90PKE2IkKBrkAimg RFAKKE09gRr3o8b9qHE/sVL0n0d+UbSBfL4vhw+XQ8OvQcNZ0PBr0N5r0N5r0Nxr0NZrRBBy1YdI 6oR5uHziPIzWT0KOk5CjHHIsE7KR5oC8oLNkPfy4EHW3wPMLgfKkaAWhDhHtQr+NsOJOWPEkLLiT 6VpBvlvdBp03ignISwalIC9V3QnfaYHvtEC6k/CfFkh4ElY9CR9qgXQnYdWTGHupVBrKcqAsB8py oDwIlPsv6l969SAQHv2Mn0XAMzRfG/jSviYy+8F2JBAYeoGhFxh6gaEXbfUySytIE0EpoDS1l+jH +v9nxn7XPyXLP9tngtHqIbR6CK0egmesQ8uH0MIhtHAEmupFC0cgzSG08hO08hPYtBetHIJkh9DS IUh2iJhRyxHUcgS1HEENR1ADfeo9lDwixoMSQSmgNPUI0YlhuOMGJYNS1feYDvfj+f14fj+epz1m PxC8xnpNFFIF1ynoHRduyaU+f8GWJNkDLWeC8qFpK1ZqI1iljZBH1R7ymDpE+tUh2aU+iFIeOdV/ EiU9KOmRC5BXDLpcrSYWzKIjKPEuZtIRORmUqvah5Lso+S5m1hF5Gmg6xoIZqM1HR3G5FLGMkagP z+5CC7+TPcSJ53fh2f1yJvh8UAHyi0ElyJ+B/uxDejlQm/HUW3hqCE+8hRbfQ8khlBxCybfQ2nuo vxFPjOCJt1DahSsPZqZU/0Y5E2mOer+cj7QA+cWgUowRlyHvcrUAG7eDaoUIpOIctU+8HOk8pBXI qwRVYXxc6H9JvBL5S+GrV6u7xGvANyJdg7QZZVtArWo/MG5Gy33AuBkYK9DqEFrsQ4t9wLkZOCuA bzNaHiLRYhFqK1X7xTLUMpu1fhotn0bLI2h5EC2/I85H/kLUXoNyV6nPiCtwXY/7LajZob7CbfAK WhucoP9X0NIgWnqFxKKVngmt9PPal06oeRtq7mM1t+BeG2gtq32ihY+z2rOZ14xZ+DgsPASd91ML Q5ODWDnb1GiMSdETvQkI4oAAGiZecbb/qFiOFuYwLY+g5QZotUJcBmQrwF+j1omrwNer0WID0mtB jbh/HaRoAb8OaTdoAxBvVBsu6qlG1moltF2F1q4Efw34WuJl/qjH3WhoZeQzfSKC+wJFOAR9vQV9 vQc9fQSkQ7B/H1DuAqoGIKr7Qn4ZDj3cDEuMoM19qJVagNq1f8yuX0rr0eNYK9VhyNmIWqms0cxf r0HttUgbgVvzV2rnIXE9a+3SsRuYBq9mNZ5GbawWpkUju3MNa2OE+dBatLmeRLO7EbB/H+Tu4x7Y J84Dskr1brEK6Xx1JdAOcQ8cEVfiKQ9WS8nqD7RxAXy2+hHkPwREP5BLSSAQ/Q5yP0nc8DYCbyPo wRXECXoM9i3C6qBUTUBrg5p1/UPwuBPQ0RnWcgVrfQiY30LrY77fz/FDL6hjI0YuB5C41J8DTa2c CD5ZfQdoaoGkFnr6OfT0c7kE+dOQ76PvI8blnM0sMYLajzLZaqje0Cr1vDWgZq3/QksjTEtfdCyl cmPPAnpU7UMvO8pb7mHa1XrXCOR7jXkW9dllzGf70bOGxDrmaX3oXXQM+6bYhPzrQGtAdBxrA3Wy ntY3oaf1QxePAmUPkPUAWQ908Ch08CjJwQzSjxmkH+uQfqxD+oEKlkD/Z33fvxHIctCj4PPYOdAR lnrolazvV8Cf+oFuibgctEItBkq3uBKt1uJ6FWg17tch1caDJRgPlgC1G6iXAPUSoHYD8RKxHdQB 6gRtAG1Ui7/QHBDMx8kK6LBBnEP9hFmxDhbsYT4Cncku5p10bH8RetgMPWyWC5BXzPzgRWLhI8cu 9MZ+yLmWydmo/pCOXcDTz2eEfrTfz2YBkdqK9RNRbOE9xob5iLZ565eaKWPZ00VYG5RiTVcGHmMF pDoAzzgwYVRrgH+2QLpYbottX6q1MLRSw3q2NpL2MN1VYe89H1q4CgjGRrZL7dXhwN6PWhtQ61rm 0WPWmI8V8kI+VmKc+EK16sV6EgKvGUHvOwpr7ELvO0DMrC7a81cylEPwsWE+ivXDr/rZSNaF/I2w lZWNfqx1rKXoLNyAMaQRo6HWq+mIeAjrgDMTnhohprE5EU/2sbbq0XoDH202Mh+oxfMYdzDG0jGQ 1kbHh1akbcCD2Rhj7NV8jKVl6ZNrsJ/AHbQzgp3nClytBNG7DZitGoGiRf0Z0JxGqWGUwqoIPfMo xoN3UNcQW8PU8jF7DcP+HkrTUelJOjcQCSVPs7sYo6CpZbi3AnKv5CuQBoypzeOaos8dpSUh0Qmg XcGRajp9h5dkKwugXYo7YyMi5mJ2p3V87THMWsTKVG2A3hpYaT43jNdJcV3Hx9MWhtHLtB00PjZi VMVoNMLmhKV85loB/7wGvXEls8LQuBXWIK+VW0PPPXaIj9EvsXotvI7+CXqjY+YRbvd+uv5D6T5o up/pT6BYYdtmll/HdLITLd+Nuk+i5VPMU9qg7Y3cgndO8ELUz2eKsVLwKSKNS/cY6jbiKh9X+ZB1 CLIO8ZG3n468JIzosXsNBA38a874sXofOzt/nJ7UovTfO5GaePJET5MoFh+w+IDFx8/zuyect3UD SzewdANLN7B0A0v3Bc7buoGlG1i6SdA/e9ZGkvhOv5vt9B8HPQW+H/X/O5y/pfAT9D5+gv4u7Psu eRz8U8jrV/v4SfkwUA4D5TBQDgPl8D84KR8GymGgHAbKYaAcBsrhz52UDwPlMFAOA+UwUA4D5TBQ DgPlMFAOA+UwUA6zk/LQz52S/wIof0G9AygHgFI7Ef97p3UTT+roSdxYbb4L1OZDbb4vdPpr+bz/ j59RWdW1sqxOxd5/82fOq4xj551o02T9q1pq9aulsh4UqpYS4+dO9Z7mp3pP49mnsaueeF5lHDt1 Qk3leC4Lz2XhuSw8k4X5XfO8DfyMiduWeeAGyLnhgmdA/PyHBPOznw387GdMS+UTns7D03naOQdS es4Rwk4h8/gZx1FiQKkbUepGlLgRd26EJI9CkkfZKfyPx09iQj530jSxtXK0RqUrQj1FvLUifqqy n7dYNN5iEDtpCMLIpJ02HIc3j6AWtkck38e+hu5E6OoqVY07v7riO5LLMRcEXtJKma6Q42H7Hti+ B7bvoeshVnecekCOB9EaEpCmgNJA6aAMEK0pC2m2+pSci/R/iPv6uKiuO+9zLzC8zoRaagyhhFhC DKGGEEIJoZZFH8XZgVLWUL0FYy0PDANhGWooNS6xMgzzxjBz5wXWB6ylxFIXcRhG17I8PtRYan2o jyHWRWtYa13rUj8ua1nWNdY833PmzjCQNu0fz8vnfL73/M655/X3ds65cO9kA7TlHMRfAOhYXkGc B9AxFSD+C5wGChFvBLDHUmCPpSgCtn70fYUSOwwZ6zn0bOU/V50in2H7Zj8/6N75Ijh7kXnwv0N6 iS8q9kQh9aMXsY/9Gcb4IvaQ9Dz4YvDJAs4c2EvSs6AKuhWBawzgA06i9melFtIQf/yZhEp6JqFi u1H6XIfuU+9JXPYue66Qi/xXgXzk+58veIl8hUx+Dpm8LZ1afx4il9AT60GiQC0qazoqyp1O1PKi 1kHU+j5q0ZFRTnViD/cEzj4ialId6CXrls58H82CY7NYCT8DfSTkNPmMdGZbgKSvQNJX0MNXIekr 0vnt55D4FQV9tpwBfB5Yj/svIM4CsoGXkc5B/AUgF+28gjgPeBW0/6xHpX4FEr8CiV+h5z5I/Qqk fgVSvwKJX8EuK/R09neI/zs9OTAuHWRzpPPLRfpVuu5LnDgrccKNEmdR4qzEATedOWzyKey3c4FX P+qBZ6PrPtOcj639d9Hjy6HaQ04jjyd19C9phNA3fAlHUgl9e+85+kYveQEhHHvPl0gEeRlBRr5A qC98heRh75qPEMPeuo0lryHEkR1EwN6sAuExspt8A3b9XYRVZIgcgwc/QU5CHmMIj5N3yVmyhkwi JJJzCE+Sf0FI4niOJ5/lwrlwkszJOTl5inuMe4ykcE9wT5CnuSe5J8la7inuKfI57mnuaZLKPc99 njzDvcC9QNZxL3Evkec4N+cm6dyPuB+R57l3uXdJBvdT7qfk89x73HtkPfc+9z55gbvMXSaZ3Afc B+RF7p+4fyJZ3K+4X5GXuF9zvybZ3L9x/0Ze5v6d+w+Sw/0n95/kFe5D7kOSxxOeI6/yEXwE+SIf ycvJBv4x/jHyX/jH+cfJZv5JPols4Z/iU8hWPpVPJX/Jp/FpRMU/xz9Hivnn+QxSwq/nXyCl/It8 Finjs/mXyTb+C9gJlvNVfBX5Dl/NV5MDvBq7uzZewzcSHd/MtxAzr+f1xMobeAPpku+V7yU2+dvy t4ld3i5vJ6LcKDcSh9wsNxOnvFPeSVzyLrmNuOWiXCQ98v8mP0z+Vu6T/z35rvw9+TT5vvyafJa8 I78p/w0ZlN+VL5Ah+X35fTIq/1D+IfHJfy9/RE4oeAVP/l4RroggpxTRimgypohVxJJ/UMgVj5Fx xSrFp8n/UDyueIL8WPGk4klyVpGM0+9PFKmKZ8hPFc8q1pGfKdJxOvyfikzFi+SiIluRTaYVuTgN v6/IUxSQS4qNsI5fKjYrisgHCqVCSa4TLmYqlr01yq0mhYQMHQU8hPMeQnwSGAc9gPgMcE6KLwCX JJriKnAduAXcQXnaxj3gvoRH/vhYuB+WZkLcbj8ofSwGdTxLaYDbt9sfezGGY/HAaiAJWAusQ/44 4vVAtr/esTygANiMexjTMZWULmNjWgk6RjbOE5jTCcxnXxriS4Q7AY6cuMq/MXLAd3DE4Ds8NOyV Mcx5CymOZXmFY7neXcf03laGR95ZiuP1o/uPNwFjo/zxCWAamBnlPfd9mz2PfGVDJSOnh7aNnB0S EO8aOes55CugGKoeOT9UP3LRcwfl7vlUQze96QzVKFeP8sMjtxnmvJkUnk2+eI/St3rIN3KXYR5l KcZGFhgWQQMh46xmWErXM2xAehPSFtAUHm8vw0kJ1zEvilt+DK/1PmRYN8oDUcH0eqTXI70dNMXO 0USGQLoKNEXjaMYnYt9o1vCB0dzh02jvLGBA2or0edAXwUvZqJIhzpt+fNVo6fGS0T0Ma5BORrp6 dC8D5T/Fw9ELFB5+tJQhavQqQ8LoHYaU0fsUQw/BL8BT6kvylPtWeyrabZ7dvrWeAciHQpIf4u0j 4b6dATlAJncRpx9PBdLR/7bRPUNNkFkLZNaKWIe4euQyZHhtyIS0DTI/ivYoPH6MxPg2j8RDNybQ FnCMh9yAoUmkKSRZoq8HDHPeHAaflzDMe/MZplCWoh9lKaZBA8ei0F4Ure+NY5jzFlEcU0L2pZC9 CLlTlCNdgXQPaIolXWliWEq3MOxGWo30IZQ9tKy8jmHc28/g8Q5KGGYY9/oYznjHGDzeCYZz0DeK C95JhkveKYY70D2KexKue29KmJMwL8Gfvo8ywHC4hICOZo8qGJZ0OIFhSYcTGJZ0OIUhkNZAfyma oacUTujmQejmZejmtRDdpEgdLYc+lC/pK+jMkHQO9CUf+rJUvgLldwfThbhfhPsCdJtil4T50TMM i6PnGEL9zSTQAt2nmAJN0QoaeCt7lKeAbegZxkYPMdhQ1w1Ifup4L+h+YBY0hW3UgvsW3B/A/Qak RaRFpI8i7QmWv4myN5fsDTwppfgz0pcoYJsVDCmjjyhgi5kUnjTYJ0WGhBRfOAXu5VN4spAHhPix VgrPHt86z17Y8X7feo8esAABWw7gpIRxCWcknJNwQcIlP0ZW+6pGknyakbWw13W+smMKbyaF5yru AyPrfY0j2b5mxPtYXOazjmz3OUd2Iq7yOUP0TMGw5BvTGJZ83Qb4uk3wU9c9oi/b0+PLO64Dj02j +0esviPHrsJGgOEY6DbgUcNXNcBXSTFsfBVDwEeNedcwLIKmWLGWwYfIGOZBU8x4kxkkGaBsKsOc t4RhFn4FOJYAv0LRAN7vAe8H4AMGlvkB/9o47p1m8HhnGK57FymC/MiD/eRh7TiM+R/B/G8gfRsY QtqL9F3QCwC1t1NIP4CekRB7Sx1Vw3YaQtK7ka44PgieDQMBW5B4eDwHNEX9aA9spwd2cBK2M+5R YF2gSMS6QBE1eoshYfQeQ4ovhiKom7nQPeBYIngAeDYgDRxLQRpYufYMx0NeFKslBOZfgLkVjEaF 8M3EsJS2UQTLb0Z5iiS0ARzbi3L7Ue4oeA8MubHO9GLd6Uc8OHJjJA/6WgB9TYO+AiObkVYhnYE0 AH09gLXNANluo/Bchz5T3PJjRAP9bYQeNyPe53OGjMtNERyXCmOiCKTLQAPHffBBFHOg5+he6ES6 59EJqk/5FEE5Sff9cjmReXzsRA72UIdOEN/mEzJf2Yl8byZDHNKrsF7OQw7AiTVIJyPdjzRAv0HC 3sQk7B3MKPb2ZXREdkQ2UUTkRrxKHmPvSH5aViL7K5IoK5d9laSwtyPXsrcUn2HvGK5nbw5ms7cC 89n7gH+Bdj/F/ys/j3afCltL+LBnwzKJLOylsBwSH/adsAWSELEuIoMYIvJlr5JO2QbZRq5TViGr 4RyyWlkt911ZnayeOyxrkn2T64+Njo3mBmJHYk9x78RxcQ3cMfouIv8kff+Qf429dUXfPsiW3s16 AX1HKJwKFyGKHsXfEl4xrXifhCsuK/6RyBRXFb/0v8lC3wKVamqkmowbYS9jjCTMGGbCqP817B4J jyiK2EqiZFmyl0mMLA/jVWC8XyLxrI9VrI8ERa+ij6zGiH5K1rD+Ell/Say/ZKk/ju8BR4LnhsNN QAvhjlQjbgV0oOsRmwCbFGOffrhXoin6gUFgGPChPG1jDJiQMCnFU37s30CIaacflD48jTotS2mA a0z3x0foGGaAWeAmMAfMI1+HeBF46K/3PR6IAhS4hzF9L0FKJ7IxrQQdIxvnDzGnH2I+f30XcS/h fjgI9IM7G4iKlJNdkMMe0koMRCS95Ajx4Ox9llwgM+QGuUMWwcIYLoFL43K5Qk7FCVwV18C1kLCm 6iahqb5pV1OT1kp47SHtUe2A1gPKqV3QHtTeBTWsXdT6tOC8tkd7X+vR3gN1UHuZlgCl097Umthd vfaCdr/2HKhG7UVts/Y8qCbt2A9mtD5QFdrxH1zQngS1E7W3/4DeLdIOakt+MMnuitpNWguo7Wg3 j41lm7ZVm6ltAVWKdtO0e0GptBptkraK1a3XrtJWg1Jo92qjtHsI33hf29z4SFtGwjHefu0YWndj 9L2Np5AzrN2F3Grk1msn3vCi9GVtcuNF7RpQE9qUxkltIglD76q+e9oybVXjfsL3zfXN9y32PQR1 vfFe352++6AW+q713ei7DWqqcbZvpu/m/0UfEMXe4Cbs3W369vRbJFrWKmsncvYu82fYm8iPs3eN n1CcUvwDSSQct42j70bFkVsEdthXAmwDBGAXAFvpq5di6FRfi0RTQH/7oKt90Mk+6FofdK2vV0K/ FA/68TfQ1Y48PyjdN7xEB9AH/e2DbfXBnvpgV32wp75pYMZftg92Au6RPthJ37xEL0p9rwC1a2oD 9ecRt5CchqKGkoZtDSWN1xqExhsNuxqqG+qBpoYW3GlpaG3QIZgabA3uht6G/oZBhGGkfA1jDRMN k+yurmGqYbpBV5/QMPHmrTfvINyrV/Qm9qb0pvVm9Gb15r7jeefkO+PvnIEcPg353iOEX+D/nfD8 f0DW4UzWMibrSCbrOMj6FSKPeDUo8XhI/CvkcdlfQe5PMrknyQSZQJIh9yHyVOwwpJ8K6T8kz8Y+ gg6kQwe+RjKgA2dJ1v+nXjmynRxi+rOBfpcgxFcxP6WZ9Pup76UAaVI+MLAJQA1NwRsFb2x+Q/VG 2RvbNQf27Dp45ODQQOZADmYTy/+O/x1ms8gvwpvnReQRXlYmKyNhsIUdJFz2NVhEROyx2GNEFvv7 2N+TSHkFLCJK8RNYRAyziNj/Q61wqxY+vR2rVxx3mkCv2mC5bY8I0YUDMYR/C+uZLh5YTchbKkL2 7veDpnVJwFpgHbBeysPKqcuT0gVBcBbIsPaGH281As3I34x431J+KELz3zogxYY/Uv6AP99hXXbf P4481o9/bHQsKpRxElK7b6ksYv+cylg51g+rvx3AGqWrAigfGqV0s0Sjnu4AYACs/jIB3qB9hm/D lnVOls+/ddA/l7f84yW6g0v96w77ywL+vtHG3rQ/CHaftld7g589sGDS228ceGCy2G+3EZNov9sm M/XYF9riTIfsD9pWmXpEgvwB5BPTUVHWtsbkEeNQ/qS4qi0ZOWvaUk3jYnJbuumMmIoy51Am03RB TEfdS6gLes8cyl8VM9tyTNfFnLZ80y0xH3XvoEyhSRQL24pM95rOgb4PuhD5mW0lpkdiUds2c7hY 0iaYY8RtbbvM8aLQVm1eLe4CnQS63rxWrG5rMq8T69tazOvFprZWc7bY0qYz54mtqFUg6pCzGTkm s0o0tdnMZSjTZN6ONt3mnaKtrddcJbrb+s0asbdt0Nwo9tfcMDeLg8jfJw6jzAHR1zZsNohjNZfN VnEC+U6U95kPipNtY+bD9httE+wKvr2Z1TZpPgKOTZiHkDNl9mJ20+ZTYrou0XxDLFl2TTHfDl4T 6ZXNbkaXZr4rCsuuGbjO6rLMC2KLLtf8QLwp0RvYdZOFiE06pUWGdkKvpSHXckucOKyrYFc/vduy SpzTqS1rxPm2GfNpcaotk45W12BJFhfbmmit9mudaY5zbbPms8E5shnp9JZ8R0LbsCXZkajbY0kV H+os5lOOlLabrIyfA356jtHz5iPidNui+bwYJ10fSvRFMU7Hmy+jzdBrlPkaroqQq2gphAT9Osak qeuxFIk5ukOWErFfN2DZZr+tO2oRHGl+vdXttaQ7eF0C6mZivqmiW7ffkumIwnxzHAqdx7LLkaE7 aakW63XjlnpHFtVJRy6VvprooixNjg26M5DFbIC2tIizktaxefklSK3mW4NUPx2bdOcsrbCXaljK riXbcSipljpKMUIdRniGyfECnYXuksVEZ2Sx0RlZ3Euzs/RidlfNQ6JMd51KFj1Cl/w0+EP575fv LUs/ZnfHMij26u4x+j6j/Zx5RDlDrcxRTvXZUdEebhkW89tjLD5xsD2ecbUcOjAMbp8K0O2rLdvE ovYkiyBOtq8Fnd++jtHrLWOO3e3ZlgmHuj3PMuloaC9gfEihfGjfDC4l6tLAJaFdZWmy320vY/R2 y5RjD+hp2OmkZcr+wK/PbXPUq7SXMd32y0JJZdG+E3QiNJbSVaYBx952jWUGMrpqmRVl7Y2Wm2JT e7Nlrj6hfZ9lvj6j/QDVonaDecGxv93KaCel/XrVftD8wKGnnsphaT9sznaIkMKiuKr9iOUhPAO8 1pul1D/smWkf6uTrMyj/m2OodtU8oB4Mtgxf4eihNPwepQ+1exn//Tbll0Uipalnaw6nPsQxEKqZ 7ac6oxxH2093KhweWBD43H6W8blgiYZ8g/yn/tBxknoeR277+c4Ex3j7xc5EsVDS5DvU1tovd6Y4 zhjCOxNcg4YYetcQ35nQdM6wGvSYIQn5w4a1LH+d+ZrL157Utegaa8vszIAvaurMgp9J7nwEutca Lg5THXZNQEvDHaUYydmAbhvWmw65Jv3aC9npILtEyKukbY7KUZIp4zM49gDay/hMfa/zNvX2mAV8 rGsKmnzZftevsXR2rml40X2uGd2tJQ2k3t416/erdMx0pl2LoLPBmUxDHrVf/9iMMvMN90ljHJP1 YchaL3kMJgXGpYAm3+jMdVzQD1tVzsb2250bxPn2u52bHJfaFzqVjqvIKUXOQmc5o+ndB50Vjut6 0rnbcUsv61Q77ujjOhvsC/pVnXv27ELJvazkfnFev6ZT77inT6aS1ad2Whz3dfs7xW9W6dM7exyP 9Jmdh5zh+pzOAXjR1s6jYos+v9PjjNEXdp6sT9CpO8frM/RFnWec8fqSznPihH5b5wXnavR1yZmk FzqvOhQoed25Vr+r85Zznb66845zvb6+854zG3Xvw3fBjznzpDWUrVb6JmuMs0DfYo13bta3diqc Kn2ydTXGprMmOTyUdpbpTda1YrreZl3n3K53W9c7d+p7rdnOqrYSax5WWLaW6futBU6NftC62akx rrLp3ePGNTaL+4wx2Sa6zxlTbT3uC8Z02yH3JWOmbcB91ZhjO+q+bsy3edy3jIW2k+47xiLbuPue scR2xn3fuM12zv3Iv0YbBduF7nDjLtslx3VpF8HWa8n2z1B7N1ZbZrtjjPW2hO74UP2hFuc4SS3O NWVswn7ABi960JXTpqNWbGyxXe1ebWy1Xe9OMupst9xXQ/2J0WS7073WaLPd616nu8c8qpJ6UaOb +q72JKrnof68bZ7qtrGX+ahQfwU9715P9bw7O1TnocPwAPCWS97A75kHqDc29lsGu/OMgyGeWcEs /QzVT2M1oyvoKhzqpY3DtvvdBUaf7VH3Zh1vmXXnGvbB7+mMY/bwbpVxwh7TXWactMc791HZdW+n suveCd9yNuCNl9YdcQbr9eWAvzLcRo/J8DmwJr3PWubg9WPW7c5mXHc6m6l2QbeZveBaRa3GqoE2 Tlgbg/mT1mbnPv2UdZ/zAK4HcJ22GpwG/YzV6rTqZ61O6N5N60HsxJh89XPWw06nft56xHlQv2gd ch5uH7J6ocNquk+jV7T/0HrKGd/BWwqdRzqirKcd+g6F9axzSF+Eazy7ejsSrOedpzoSrRedp9n1 LN3L4cp8sv/akWK97Dzvn1dHmvWa82JHhvWG87I+znrbea0jy3rX2diRa13ANcv6wHlDP9xFnLfZ 9W7Hhi6ZeLNjU1ecc6FD2bXK+QDXNc4H1L6+WdVR2pXsIh3lXakuWUdFV7orrmN3V6ZrVYe6K8e1 Rlpbh7ryxfmOhq5CV3LHnq4iV6re11XiSu/Y27WtPkq3t0sAvb9rlyuTygvaS6/5IXROh76run4D rvW4WrqaME6xq8VV6N9Fd/R0tbqK/HzuONSlc5V0DHSZRF/H0S6baxt6dzsUHZ6uXpfQcbKrH7S+ azDY2njXsGtXx5kun6u641zXmKu+40LXhKup41LXpKul42rXlKu143rXtEvXcatrxmXquNM167J1 3Ou66XJ33O+ac/WyNWKS7nNcNw0FXQ9dc22CjRe30fMC1g7szF3zWC8srkXDZtAPDSpLq5v375cM ZaYed5Rhu3m1awplelyLNN+toHskdwKlHYf8ZVh+IvIPId+/7kCT3Sl+2rATbaYZqmxRYrVBY1PA xjMs1e4M7DewNzCwvQE9m7iz6CkAWjHFbKc5mL+B5rs3UfpNf5me0DULO71ZcY1hny1B1BkOmI66 plGmAGMzoHwi3Se4lRjnOMaJHYLzdvt2WyLmZbWYnLdZfinNd5fTXYS7wl/G4LSliKmGg7Y00WQ4 zOgjlKanpKAOj5mHHCmwSuLeDT6fc6v9+szoBkq7FaH5bfO2DJEYhmxZos1QYMtwzRm8tqxv5RhO MT+TQf0M3Y1g/NiNuPdQ2r2X0fsNp225dGdi24CdIVYQ1zzVcLde12PbJOYYztqU2EuH0LS8a56W d+uxZ7tlf2A4byvFySjEX1HabaG0On1ZPtZ6t0jXencPW/dn2XnKHUobsm3l2KVctFXghIUzIPJx 2nLNSHuYy52J7kOGa6Z77gF6/sKMxmy7HSmGGzZ1fbnhtm039gZ3bQ3uo/BsdM9Qij1DPXbCwR0s PT9CP2FfGA9ot4fSNXeZJigMC7Y94qDhgW2v+xD8dirqslXASGz7nfHdC90Peohpg/2wM96Uaz8o trbftq+GvyqyJzm9esG+1qEwTtnXdVd1POqad/X7r8Zp+/pujXHGnt3deGDBntfdbJy1F3TvM960 b+4+IO3w8+2qboPft/ht3zhnL6svl064/lOG/1QbemL1n1XZKdU4b9++4qzKVnDjon1nt9X40F7l WmPi7RrHPVOUvbHbaVLYm51DpgT7PuzTWDumRPuB7oOmFLvBley3X78l0n67D0unaeg88pkmL/O3 wZF0Hwn1kOykbKNnZNeM5Nmox5jyn6/9fslvy3QF6R6iK0j3kGTpzAZNaeb4bq8pw27tPuXXEFOW 3dl92rTJfqT7rPR0gj0xMClN+u7z/qcTplL7UPcB6VkEO/Wbyu3e7oumCvsph0J65uA/3fufKrB9 pmmv/XL33dATpUSz5xV+CzLttp/uvmxS2892XzM12M933zDtsV/svk21oj+Rfp+OfVGShHxRkmdf lAyPKozaTiLYVyST2Fckn2ZfkUyNao7aR16IejvKTHLYFyI3si9ElsY+F5tJtsX+S+xvSQX7Lubr 7CuY30AfL5FU8kVCyCZSSRLJbvIdkk2MCNuIjdjJa+Qw+R75KjmCsIMMEQ8RyI/IGHmdTJJfkK+T 6+SfiZb8htwh3yKL5CPyNxzPpZMOzsRZiIdzc78go9wH3E3yu3BN+Bvkw/CB8B+Qj8LHw3/MhYVP hb/PRYffDv8t96nwxYgw7jMRqRHPcJ+TmWTj3DOyCdmPue2yd2XvcoLsnOw97muyf4yUcf81Mjry cc4V+dnIZG4g8unIt7kj0W9H6/mIaGO0yMuju6MP8o9H90UP8U9GH48+zz8f/X70VX5L9AfRi/yX oz+MSeBr6d/W+LZYRexjvC52VezjvD52NvY3vCXur+P6eHfcgpzjfyJPlCfy78uT5Gv5S/Ln5M/x v5RnyDP4a48pHlPwHxAO3NGwJ670W2pEiAdWA0nAWpIorBaShLXCOmG9kC3kCQXCZkEllAnbhZ1C laARGoVmUPuEA4JBsApO4aBwWKiiX1FkEiZRG6M2Ej5KGUV/E4Mnq/gMPoMQPpfPJRyfx+cRnv8S /yUSxhfyG0k4X8QXERlfzBeTSP41/jUSxX+VF0g0/zr/OpHzu/lvEAX7n8V4/g3+DfIp/k3+TbT5 LX4v+TT7z8XHwfVUskb2nuw98gTmNENm2czY180qWsnuitYKXYWpwlbhruit6BeiBEXFYMVwha9i rGKiYrJiqmJ6x3zFTMUsUhMVNyvmKuaEhor5isWKh5V8ZVSlojKhMrEypTKtMqMyqzK3ckPlpkpl ZWlleWVF5e5KdWVD5Z7KvZX7K/WoEwyo5w8pUtgUDGopWCpFYH9lD3CocqDyaKWn8iTCeOWZynOV FyovVV5FieuVtyrvVN6jf42MfAfcXL1M2+lX3rNJI3Q3j3wbml/ItP0voeUeUgw9/xEpgZb/gnyZ zCGUMh59JfJzkc+QsshnI58lr0U+H/k8KY/8fOR68tXIzMhMsiMyJzKHCJF5kXnka5H5kfmkInJL ZBGpjPxaZAV5PXJn5E5YDcf+2ke5vJZ+qXKHBzgpYZzF+TuGdnh3nNpxGtezO87vuLjj8o5rO27s uL3j7o6FHQ8EIsiEOGHVDq+wRkgWUoV0IVPIEfKFQqFIKBG2CYKwS6gW6oUmoUVoFXSCSbAJbqFX 6BcGhWGkfMKYMCFMClPCtDAjzAo3hTlhXlgUHtJv/kVpo95k38eMWcatbyNkk/+F8DL5NUIObP+f yRfIbYTcyNLIUvJK5GuRr5G8yKrIKvIq4eLuy+kvq8SRdPpt0GrMrnqccLU0PgOcI1xZFXA37KVq T+2h6pO1AywO0OO1R6vP1HoYztWerL5QO85oeu9S7RlWjqYD5Wj6au25Ze1cr72wrE3aBi1zq/ZS ML5TezWYf6/2OksH6Pu1txgduB+oQ8cTKEfv0fZpTEHvP0L6UUi/oGvCMcZHIeVWgtZbCTqGUAT6 W4nA2EJB5x7gS6CcNC42lgBvAuOn+THSWBEzxNeeXAbUCyA4Rwo6NjpPxDWr0Tf4w9qicwj0EZg7 lRfGx9qgacrLq/46rGyAfwEZhY5RaqcmqfZOkLcoF+iLxdJYatbW3mPxutr7rD3alhQH+360vL/A 2Fm7kC/jwfraRx+rH7Oi32xNeE2eJqamQBO/bL6hc/lDY6WxNJbgmM4spdl4aDrAHzo3KabyCE2z ulQnA+UDtkDvSbZRs1mzmuWfWd5XgO8r5x+ct2f5/IPpgA4FZIu+1D5/3so4WAZ91qg0STWHNY01 RzTNH9OPT4jVY3/e/dByH+P3nxGrJ0LSK/l8Zrm8Pimm4whNs3n/kTjAl5W8Vk/6+fSn4j/Fx8A8 luk+1YkyzdqArdVs16yr2alZz2gpDvpPyZZrqjTZwTIaTR6zsUZNQagfrmnWbK7Zp1ExngX0kfZ9 QFNWY9BsD86Rztmq2Vnj1FTVHNRoWJ7kH5gPGdLsq/FqDjBdDOgk7e+UxlBzWmOtOatxsrkEbOu8 5iCF+mZdq3quTkfLq+frTOrFOpv6YZ2b6mstX9fL9Bb91EbV9dcq6gZrE+qGaf2grv4BGQdtMSS/ NhF9ldQl035qU5b6CN5Pq/PVZtSNLfMfFz5BN+OX2/bHfMNKn7LCLwX9FvSoNqtuIjDu2ty6ydoN dVO1m+qmA7wKjuXkcj8UukbVXNQcpgiuewGfLKVrLmuO1FzTDDHc0HhrbmtOsf7vak4zLGjOsnYe aM4vW5uonyCai2qZ5nLo+qaO01xja24AUnn1Ks0N2o56jea2OllzN6iPK6BO1SxQBMcNHVKnax4w PcisI+qcOhnTIWntVufXxQXaDtiPurBuFWurqG4NlS2Tb2gf2+pSqR6ohbp0Ol86R/Wuusxgm9V1 OaH8UtfX5aub6grVLXVF6ta6ErWubpvaVCeobXW71O66anXv1++q++vq1YN1TYExMH0IyDM0Xil3 zyfHK/UrKPsVa5F6qvaoehpyC9W3wDohrZfL1qIVaxLVV/WMX1//YLnA3oD61pmlvUIgVs9iPwd5 B2K2v6Pxn5jnJ/laJsspvy8JxEH+rdxnrFz/Av4HabbvCYmDe5sVPmlZ/MfkEmKvrK2ArQV0L+B/ Vq6rf8RvrJQnazvQv2TDlN/fufWdOx/b2yKuVdbNqIfrWijYHgYI+vuAb6CgPEH7taV1s0Ebpm2F 2GjA/oJ7YzoeaU9C14na8rqb1N6p3bO+K+rmqP2Ftle7u27+Y3vvkD13rbpucdl+WfJRQX8k+aLg 3pmOuaHuIdMB2HHtnno+cD6o3VsfFeSbNM7a/fWKoLxC9q61Yn3KMp2la1SAR7Sevj6h1lKfSO/T k3xUZ1QXIbEvsl84uRN7h9Bf3Xz2/+2Tlogw8hF7ovI6e6LyddmE7F3OyZ6l9LBnKf3sWco0e5by K/Ys5dfRb8ck8IXsCckMe0JyhT0h+SV7QvIr9oTkt/QJSVgifUISto4+IQl7jj4hCcukT0jCXqRP SMLo/6QNkKNLzxG2uknRVvfW3q39Wwe3Dm/1bR3bOrF1cuvU1umtM1tnt97cOrd1fuvi1odKXhml VCgTlInKFIQ0ZYYyS5mr3KDcpFQqS5XlygrlbqVa2aDco9yr3K/UKy1KUdmjPKQcUB5VepQnlePK M8inYUA5gFYRlAoWkFLup6A0BX0mELWD/n/ailPuXsjlb8jbON8OI7zCTrx55D0yjTPtJYQvcj/j zpMN4RfD3ycF9PkV2cT+B2/n0nw3FpK1WxRbErYkbknZkrYlA3EWqKwtuVs2IHfTFiVC6ZbyLRUM uzfu2qLe0rBlD1LluO7ZshelEraUszHSZ0OPs/d+CUkj9Cvz6xB4nKrTSRjJIPQXGdaTF0gE+63M SJzOc0k0xrSJyMlmBAUpQniMKBHiiQrhU6SEfBkj/QopIwnQvO1kNfvBrETSjPAkaUVIIvsRPkum EJIx9/fJU5yCU5Cn2X+1tobM9UBYluqw6ohqSOVVndoYozqtOqs6X3hBdVF1WXVNdUN1u/C66q5q QfWgmBTLVM3FccWritcUJ2+s2ugtTmU4UpxenLlRVZxTnI9rYXEmShUVl2zcuTG+eFtxZuH1zac3 NhYLGzXo53BxuuoUbbVYhhaCobi6ONUfNqrQRn1xE20lEIozpdBSvAs1W1XNJQraFmhTsa1YKF4D +hTDKdV5KdymoVhGw0aV6jLwAONJxii8G1djBoKqsVinOo3xnC92F/eqhopTKTZ6Vf+bva8Bj6q6 2t37/M1MEmJETJGGJMX8GTFGGhHIADGJKWLmzEwEihQDRqAYUxoBIyJSy+VyuXyQUoqKlMaIFBFS ys0FSjFGwIAUMfIgpohIaeDDlFKkmCIiJt9a7zmTTCaD0N7+3Of5yn7We9asvfbaa++99j77/JBT Tf6s9qwjvdrCWs9Gz+bCbZTXZFthaibvmFrIu9a8YhBb3+7ZQb00iurMBFFtqLHas8ezn+0GaoHF ALEPRJ6DdGwgq0z7qBabPIc9x3IbPQMLD3hOetyeuZ7TVPc5zwXPZdQPH3JTUH9w3USmYjo9UQX1 3FrqUeYCxO2nkqxVWG1WwbduFE5uVnkumNO6+B9EyCOfzTVmtLne3NThYRCFk7PM3Irxygwllpt1 PMoWwQ/uG9t/s1deTF6t2cdMJGRKoX5KKqw1++c10K8B5qC8Seawwnoz3xxZWE6RcQBxmmn6qB9N sj3GHJ8X5xlhlnAfFm4zp5rTuCfNmeZs8xlzAdVKY2guNpf5Fb/TXOGP9vfy9/En+lP8/f0D/IP8 w3x7/PkciYGR5Br8I/0+JnOxf4xnoFWC8/zj/SWInUCPBnpvn6cs0KrguAr0gn+qf5p/pn82R4f/ mbz6vNKCZv8CxOoF/2L0BfVNXk0ejW1ebV6Mz/BF5dX6evp65sUhlfp6UxsW++J9SXlx5jKyuiev MPc4z7e8Ql+6L9M30Of20ez1jaDVoIL6qtlzOS82L5ZyTO82ms2abxRZGeeb6OudF+ebkjvTV0bt qPVN983yzSWa71uUN4kspZPVGN9S33OFLb5VvtUe4Vvn2+jbnFft246cHb49vv2+g77DhdW+Y76T vtO+c7T2cLStpfHaZe41G81DNB+m8Ayk30fM4+Yp8wwdz5sXA/1F49rm1bwRFHFteRF5a9HvmD3e mMAs8sZ647z9vGnUt9N5TAoPeDO8Wd4h3hwzGlTgLfQWeccWHvXkdhDmtrfYO8lb6i33dove3OOe EUw8Nt453nmghd5Kjh3vcu9KxJDNcxR5q71rvTXeWu82b71nu7fBu897gHy/GBhXtuht8h7lWelt 9jZ5etJaydTbijtvi/est9V7yUe2aN6Oy5uUu2v6IF5t/cv8K4iqfBd8l71zKJKrC2v8awqbPMK7 zUMRSVFQm7fWv57qGUFxNJ1X47xS/yb/Vn+dfxeNegTJa/Mm+ff6G/3U3/4jnlX+42Y+zYQ2/ynf RJKc8Z/3X/S3+UYUaUURRTG5bbSOrcpNLIotiivqV7iWzgfVPBa8OhWlFWUgXntjpcdKSWeOVorP UUVZRUNwLpxM572U/w77KGrtVFGOu+f8lUExPEtIol7DMykNpOQe7s7Oyc4ZnktpBCWT0qjho7LH Zo8dPo4SyyYOXzR8yvCl2c3ZzcPLKE2nNIvSXErzh8/Prs3mb+AozgnOifw/yMQ94lvUr/cK/vK4 h3YHhrifei+S+vlBcYOQUWeiLsAjPPUqpBExD9Exh45H1G8WZpmNhUOIsmxiPoeowKZCoiKb57yx tl5BkB7/Lg6xMynEZpGtUxp0LA+SV9i/A/wcmw/kB8oUBukV2faLbCoNqjO4XQUheqFUGoYqQqj4 CmWLw9CkMHUGfCoI6ptg+ZCg4xC7ncFUEETBbayw9QM+Ftq/S0PqKLLHq9i2UWTrBspkBZUJjFFo eT7OC/KzNOQY8GWhfaw0O2MjK6TucPUFfC+3j8vDlA+tdyVRNdHaED+DbYfztTTIl3DH4qBjod22 Kx2LbJ8D+gE/K4L8rglpf2g/hLY/tN2hx+D5VWTXFZCFHrOC6qw1Gz0GUdQVxvfvebxSv1/rMbSf v2q8rnasvYZjSB8H+ulqx6v2Q6j/gXq2BY19PVGDzTcE+REcy/uC8g7Y/dRkdl2HjxI1m51rRmA9 bSE6G1Q357USXaI2CFsWWB+orKcnUW+zcy7aR088URJRetcxpn01iPbjjWaipW+mEPUnGmAiFs1B 1pHrMYcR5RONtNsXiNWvmotBctS32a4nqI5AvukjGhMypl8Vm1eLtdA1Jdy6VG7FkTm+02+zhGgq 0TSz+7ocug4FnS88Ay3qOO8F4sT+7XET5do0gsi06qfrF4vG2XYmBpWzY8EzhajM7HJ+80w3rXNu gGx9zyzbzlyi+UHtDyHPIpsCfnMMLbV9eo5old0/9rnbs7rTdqDdnnW2rY3W2GJ8g+vYbvWVZ4fV Xm6jZ0+Qzf1d+8tzkOgw0TGik0Snic4RXSC6TGOiEDmJokPGpDjM8UrjfqXjta5xOWbnuSPcuedK x3DxGk4v+Lwc7jjWHu/Q49Xad7U1N7CW5Jjd+y/cMdCmqx2D9wfhjtc6PqHrwZXOmdd6TisOqj+w 56P+Lc0wu+9teV2YSdTLIuxhVobUG7wPJPvmbLNzDpebXeZoYP517I1Lzc49CZ0nzGes+c7zHnUv sOZfsD1zcZB/IbbZrrksqF22/eD1KbAWdeyd2ecVVj7PY7PK7NjjmmuC+s3201wfJk54Ha8zu8Zs TlAfcblNRFutfH4LCl/VFv/d7tvLpfwVXxElo0WOEO5SonKiCqI5RPOEuCNXiIzDxC+0qZJoOdFK omr7N9NaohpL313bSf170XGbRcx35JOuu94+NtjyfUQHiJqIjhI1279bbP4sUSvRJYEhgk7Ap3qb qJ6hhmV3aBRRzxDf68PT0N4ixx3n7udOc2e4s9xD3DnuAnchpSL3WHexexKlse5Sklmp3F3hnuOe 515I/Fh3pXt5Rrx7pbvavdZd4651b6NjvbvBvc99wN3kPuquva3F3Xxr2a1l7hayd5ao1N3qbiXp paDUwu9/dn8HGN+T1/Al+RvxxfhYfDH+JnwrPg5fie+Lt38T8fbvbfgy/B34JnwWvgZ/J74GPxDf gR+E78APxhfgh//T65Oyp7TepN0ubhUie5kQ6REWZa8gqiJa0ykLpmB59nr7uCm8/i3rLXn21pBy dZ2/kb/J5ndZNrPXd80Psnlrdp/sxJCUEsT3D+IHXEEeJvFfJsE73sI5yvltIfGOt453vCPwjncP Z4XzSdHbOc85j/p+vnMB9f0i53+IxMj+kbeLfpF/iDwtUqJ2R+0WaT1ie8SKW3r07tFbpP/D7Eqx UWzufBrUf7bwpOUG0oAFnTz9eib4V/hklRjwDOsOWGxR9/yvshekMSVUk+8hKs9RXxhKtfI6Le47 ld0iXnlLOSVuNp4wnhB5vIaK/MhfR+4Q93T8taQM+68l3cHflqeSFAnKWmW70JU6stIH2nG2bSli wdv9kTpIyNQByPsZI1mXYpAYFqQRK3qmZqSWZy5PP5rZkBqX2o9SAaXY1DSSZ6UOQcqBjRX8Vq7y ivIKefAL5Rck+aXyS6EotUqtUJUtyhby7zXySac27RVOtCaC/HtdREa+QV7G0IxbKPfiLl6RuF6I FJplmaVXofIr5smUBcKTsi1lW+ooSvspHaTE/OHUwylFKUXMpzSlNPFv5FFKKadUa6VM+tehV37l lDoudVxKC6XazsRlu9i09YIT+VYeIKrjYOp+qwzrZuZm5qYUZY4g/8rhL1tYm2na/pVTXmbAq84a mKcEf1KPoV2jAl6QFvs1kJI7083tTqmg1GSlQBtSJ6ZOxDj+VPmpEMbjxuNCusa5HhSKa4JrojBc k1yThNM1xfVd4XI94npERLq+7/q+iHJNd80QPVwVrifEddccw1LWyIsY7wravYikdddOGSOJaEXM 2BqGRlqUfISO6+3jSCEzrKMnaU3S+OSc5PrkbRlxSbuS65PG0+/65IakYRlZyTlJVSTLSW5Ibsgo orxlGUOSS5NLSTqbaHzGWCozLGkYaVDiclyajgX2kWRJW4lKSHIoeV9SCZWyKbk+Iy6jlEoMo9pK SbfU1gsm8i1A3X3MyGAfk3YRT/4lbyMp/KMj+UZ5ccE+dfpDEtsfbifbTVpmE/t2KKNfRlpyQUYx WS6htItqLCQqINkkKlWYUcGjpCxRaI1WnleeFy7lBeUFEeF6wPUARUCxq5gi4GHXwxQBpa5pItr1 mOsxcUPkrsgG0Svy08hPxdci/xL5F9E78rPIz/jrJX/FGucjmkI0DavcAPy/k3HCTb+K7JVvAPRo R4CVqyBIbwBKpnfoKbQOoV7UEo9aEvgpg/JTinOF4pojXSDSNUS6gUh3INJdiPQIRHokRXqF6AGL 3AaBNuhoQzLq9omx8Nqq+5vwkd/FGEfk7pApIg2eF3TRY695Xe5lyzo9DOf/39Pvzv6uQd1ZkFm9 LcWOIFmj3d/BetvR21KU27Ir+Rv5/xRJHEO9OYZQRqCMRBkFZVSUcULbxc+OutcGe5GwFP2VYzid WrLQHps7IduOd2lmdpGloTcmdpEtQ28UdsiuzY9/fW+F6wv+evd+7Ar68F/7T5wtyDGQJ6EioSgh LnE6KCYhjo/EtSbOIr6COCt/LqX4hFbi4inNZR1K84GLKMUnljGRdkWoxQ57yGFLwXZIt5Wk0+3a 4qyaqS5esVTXQ66HqM3lLopI1+MunkHXfG4StRhB+xlnfBTIk1CdsDahJqGWcFtCfUIDpX1EB0hW ndCUcJSkTZTbnNCScJaoNeESyasTBSfKY/0a6AanrhYD9prodzUssZ0G4htIspbyWsjWpUSD7BqJ UcCeib15lXCVuGb+rS3smw7yxJfGl/dtjC+nY0Z8BR3LCecglcZn9Z3dtyo+ixLLreO8+IWUU4mU YWvOIZmVSpHK+x5CCctiwF4WbFmWylGmtO96cOVkq5x+LwdZuBAtnOya+lecPxRan2huymH2PBzI 36uQA+QgbrlM7yJNk/3EGpL26iLtKQ1RSb/bgqXislTELPrd0kV6SpwXJfT7YBfpAdFM64AUdUFS XkcG0q+1HbJrWR96KquVl0nj58paOiO8qrxKO+oapYZKblI2UZ9sU7YJB/XJTuFUGqhnXMq7ygFa Pw4q74keyvvK++I65bByWMQoR5Qj4nrluHKcbJ5QTtCasT1yO60Zr9Nu/Ebajb9BMRGIJ97b/xi4 BPgCcBlwOfBZbpHsL/kezSC7RXdBVijpvCGTusg0Gg0pY7rIkmQm/brcRdZPxgX1sCXrJfvQr0PB MrGdRojPTcGyi+I8zk3BspPiNP1a0UU2VzTRr/ldZJvELpzDgmXP0ZWkFOO7yMrFSvo1ootssVgg Ov/2rSXrhbNIYoessw9/jEjmkRZYnSVWZwWrs0qrcxmdzafRGu1gbVdpUL//BJISYHHQSCyxx4Pl j6J2vuJTRD86R1n1DxKBa0Gp1Np6jGXUu7OETm1Mojb9m/55xDO/v5JJ83qAMoD4LOUBigr+Zkv/ 6LjokeI2GpkYGpncf7mn/7+QIjR8vUfIP8vPaI3+XLlORPT4Ivrr4htC0ZxCp0D/V/v4b/o3/Zv+ daQIj7CejZWIqXTdws/DvkE7gl+Km/EdsVSxh/YRaeI4pbtoh9ZMZ8aTlAaLjykNwTfFssUfKbnF BUpDaU/xOV3xfkEpR3xJ6W58cSwXXxzLkwbtQvKlU7rEPTJSRopv4RtkI/ANsnvl9fJ6MVLeIG8Q 98kb5Y2iUH5Nfk148G0yE98m88q+sq/w4QtlfnyhrEjeLG8W98tkmSxGyVSZKkbLW+QtYoxcJBeJ b+NrZWPlCrlCPCBXypVinFwlV4nvyCpZJcbLalktHpSr5WpRLNfINWKCXCvXiolynVwnHpLr5XpR ImtkjXhYbpQbxSS5SW4Sk2WtrBVT5Ga5WXxXbpVbxVR8De0R+Zp8TZTK1+Xr4lH5hnxDlMmdcqf4 Hr6SNk3ulrvF9/GttHL5G/kb8Zh8W74tpst35DtihnxXvitm4htqj+MbahX4htoT8rA8LGbJI/KI eBLfU5uN76k9he+pzcH31J7uUdCjQMztMbvHJfGDjjveve2dzGDetxiF/Dw0+rvR/FchQjXwXm7k S1+hkQ2N1V+h4YbGmq/QGMoa0R+HaPC9mz42Cdwp6e5rV53hYb3tqpMT1t+uOneH9birTm4Yn3mn Gg9Nq115QbmW99118rvqkPfdde4J0VkdRqcgRGdNGJ1vddUh77ldfJ3CO9w4PNkQNPPD9XSo1r2w UHEVrZHQeuIqWvdB68mraPEVoLzuhpAej6XrAks3FlqesH0eqmWG9ERFWC1viNYTYbV8XbXIw3Ba /hBbT+LKNrZDzxqhojDed9e6P4z33bVGhfG+u9boMN531xoTxnuev5LiSyWKR5wJ8e2wUdFdb2zY uOiu90CYMQ+nNy5MBCmk1w/azPWG3nfCjnt3vfFhR7673oNhx767XnHY0e/doSltvQlhR7a73sSw Y9td76FrrLckTDs06AU0rTh4OIx/4fQmhfEvnN7kMP6F05vSzT8pIkjXh7v8+BaN9bt9VdBvXdBV jQhcrXe5V+c6KETEJuFxHXc1uk4RnSGsouN510Xi21xrIjTX+YiIiJiImohYV2NEXEQ/khx3nYlI i8iIyOJEJc5QWkO6aVai/OMhFjvskbUYssCWOuxAr40kWZQ7hHQpReRQio3gM2/gmcW13o1slrFo If+vUOHcQXSY6BjRSZs/TXTOPl6w+csWuRQcPc5GZ53zENERwsV0PO48RfwZ5zLneeIvOtuc512a s84V4YohSaPziCvWFefqx4lKHKG0zLmMZEiU3xhisdPecbbFljrtQO8M2e7nPO5KIw1KrgxKmivt b3xOc61PUqPlKPTedHET9cQiIRzFncS/nau6UkAe00J01qZWokuW7HoK1usNoijSW91Jtk0P/yUt RytRkSPNUUlYQVhKKc2xkKSXnIKOC50GpSjKrXf2dNQ4ah3bkNJszTSSWWmSnYItdthjW2wpyE4a 6ZWSZBvVW+/sTVjhaHA0OOMd9X+/ZyZ/S98bNOuNjUHEvyeGEMvHEW0m2k5E0W7ssYn5/UQ0xw2K eqMsiA4j36O36C3GLMImvcboSXiJ8CylGiOKcuYa840oSosoLdWbjFzjOSPTGGi4Oek1libpZlqJ rYVa7LQHW2Sp0w6VbdHPksxN9eYaq/RLdBxBabWR+8/ue3w97JLofPbBZwRnW3lbVNswUDnRsL/i PivvkyVGk++J7m3H/VLcI6UV+dLELxu7rOVRwnHpsBgQRrownPRi5jVKqVVtH/9DJNSKL57s7sMX fw7n2RcvhZN+XniN0u61k96FaeFKXzgYTvrpyWuUhq3pYnVYP7Ww9cdeo5T67/KyMOMd1v8vBoYd 7xHXKP3HRcG/VsI988dwfXDZG3bEHrpGqdB4/yTaS2nPlKLx34E41Xae3xvW+VndKZ7LclfbIV4x WCL7t5VzLrCVUZwztrEFYxQQfNsw8NOheQj7OcFrPr8p0Y6nXYSTSNKvbQflPofc/kANOIdRccLD zcCVQDwllDeAnwS+Ffxe4CmUyoR8KXA/JGORew6SXZDEgcdeU+ZAkg/+OPhngIuAKcAy4ElgnV1j GmE1I/mcBvvxqDcNnqShRYxroF8N+6OA2xhVPEHjb9YRjydiqvXcbjEj9Yvl53XCftOF+pp19gGn wE4TeAWI52faJiDeb9Ss9yisZ1iz0OeHwR8Fjzc02vD0UE1sP8StY5St4MeCXwPsz6gq4KcjtwpY B4xDbg34Z4DrgMshN4HlwBbgfCDq0mLaEVdGK6MjE/xU7ltL4kyH/CKwDPgMcCyii//ii7B4vRqS 45CYkGyGZA54vDukH0W0H4Z8KjSdkO8FXwd5K2J+FdDAXNiKeK4ElnNbjP4sp92GVFfwtQj1WAPx UbacUDkLfrOD/7bLXgft69V09l8dBkxkn5VFwHXAs4zU22ynHDbngE8Hn2PZt+uK4bhlFJcsOfum HuJZ5kxsWy2ksZRRL2D/tVXcFjWKURukz2ObVht51uv1iJNBnEujxpK9PIu1mfo5stbCOrQXYp1m lstduhX5z2GsGwlPtP+ZcAOiKI55ichUWu1cxsHQWYKIxdyXeyARbeOJx0wknUa0ji2UA0dDcw34 SnteTMPso92GMofvIKkf8fxS9rfNB8/6o9HqGOZ1xLn6hPg54VZrvcJ83MWobkW9gnktEppT+b1n 9SN7TeN3d9qdiTRHDnGEtJ234oTmlmz/s2Zwq43PCD9x3MEtNfiac4PezP1goaMno5HIOpyr/onl ylaWaD+E/AQkQuPR36OVEG9q6Yx6KeQPUakElsjt4KMZlXRLX89hHX0K9zZbE/H6ONbXKba1HRrF rf6wvoj4d5jXNumFhAsZ9edYU3+ZeeV/Mapzddqt6TshGcroiISmF3Kh/YbKPgqbO7W7iP818+pH +n+QJAaa02DzCdZ3NKKUFzUegv371AWEQ9X/TdhPfQxlyU9VV39ImKPfTViqMm5SyWdZpb5MeFFd RpKP1Xria1HLBfU2kvwGmKg+znbUYZDwqvKwShGu/FR9m/TrtI9JslutIdyibqGyK9VNxD+vVhF+ oP6S0K/yOwFCqQLWMsqNZKFE8ozYoKwlne/QXlqqknnlMUhGKHt4ZJmXlZCvUMi+/CHXIpdCpwry d1lOmmRB+ZFq8fUsZ14ZDPkJZSuQJFo8I/Fc9oTkWfYkeCGTWF++yOMu/xP8SeLPKkWEMxSOkAsK n53vUj8n/Iak9VA+Ir9H+E14lQKvRsvfo+zvYfMT8LSKKlnyNL5a+ntuEcvl3YpG8ghofgbsJd9j pPMh+/AeLPwCLTqJUpshr4F8HfFZsHan8iHh+5Lv3tyEfruRY0PbhPVnkj6ccICm8EqFaFmCUZ7F crWGecOBmHweMTkZuc8CX0WpHyAmd3FMUkSxPAmajeBfROxNoXVUarryK+LvUO/niNJ59RjPnqvF uk7YrNLOR31JfZDXB5VHX3Dsabr6Y5JgXuiHEXVvACuVTwnfQ+x9hBhbwnLl1+pLhIsR7TtUWpm1 m9ia/iIjxSHjCeD3IX8WPqxga3In66tJ8HOVyrNjl/o6WeihpvIoMKqD1a8R/yn4bwMvq7yyvay+ Qvgr2HyazktcO6FWr9IMVW5T36BVaxXO+zG84rX3AQ7iHUt7BmNbDSQZQMPez/A9tOv0X+PMSNeI 7ZscD2Kv6Ic+7x+wb2k/Y+/uGKdDgn0Irem8bvugiX1LGz895F0H23dDB1+uVnoCz0I/Hpo1dJ6R shg6ubB8B/jtWNuxn1SxI9JgQcU5gvav2PnwWUPHrkm5E/rY/2joAQM7Se2wtVNiTXVrO4/vANjB +0oq3n1T/wQ72J1qFyCZDX4LLO+09LErwG5NrgSPN610a7f5IvUQ5TIqQ6wzGus4rF3lrTgrbbTK whrez9aabU0q5UiA5LS1L4V+E6Me3zab9F9h1FYxKn8AXsRZ9TVGtRyaw+HPPN4/KCbryP0oZZ2L B7KO1odbqjVYe0uU/RPsH4P+Gt5RqBhT9S/AbCDO+1oy+Ci2o9wImxth4TJqH4c+X8roKOMW6ZMY tcPt+Tgvk6ZSwfa1Qua1XIxIDdDanWahV/dBcyAkh/iNdSUFXm1lVBaBfxw4GzgC8pPgi3h3pHzJ qCHa1WFt2NNC8gb2Myfg/1igE31iUMyyzj5EFJ/Tv4Q17LKUPSxXRiA3H3HSYu2lYfluaNa0YRcN SSzGbhTs70FuA+R9gImQT0CP+awZgV3c+vYLfL0A/4+g3jiUHQa+F/ACavmjrVMO/XKMNffndWjF ZOAU6Feht1cBj6Cu62HzblgYD/yLZQ3j24ien4eRXYC91k3WbEUtdRidFniO6y/9FOvr1ejDZtsf 9kRFqRJIfsh26OqPLR+AnQPoPVyF6ZjpdFbm2tci15qVCvTfQK41649buz5r3iHqPmI0cC1pRLPc +CXsjIH+CPh51BpfyL8Oa3+yrp7g+XrUsgdyD+y3tv1fISMmMO/cZEUyEFeCRqtdO6ETK5WjAj5X WCsMZmUdsIQj32iyV4YXMe7jMaPRwzwKch/G5UvWpDO9FQlsvxK50y3E7jcKfXUJ7UpHjZlKPHqJ W42ZSKsBtzTGygU/CLm4ileWw3INMA494wbuheYm4DKM1xbI54GHXMHqbazByDagFZ/BE6zAtFuu JoyiKwxayRnb+zDS/pnvEwr+ljrxg0h+QUviVZ0ltK+O5PMC764pF0hxwXwMcBPfS2K5vFW2EboY xRbwyUAP0AR+hty9wA8gGQD+OrZGdVk2J8KfFj4rOR5lnx23Eq7mK7X2b+GqU+jHgHfgPIgrQR1X hfrLwBbgbiCuLvXfQnMp8D3gzcAZwO9C5+fgF4P/CPzr3C6Nd5UuRrGF+1AmQ+IBmvp65oGfQWcv 8AOd76UMAC/054Cfweb/AY+eN2KFvIx7Ee24Vup4R8B6njqA+wS5zdgVNNi5BVyKo5Gufy3E/RyO Q8KtuGbhq5gy7OjectB46WMYtROMxmBGtS8kgtGxBPwMRickKiTKeiD0DfD6MeTuAKaj1K3IfRb8 o9B5H5JUSKZB8gdIIsCPBL8QuZaOZf9u1DUTls/CqwXwB14ZqEuvBF+MUu9Akg2+D+RTIbkL/P2Q vwJ8AXINluGhVg9+HfhHgK8Bk+DDU0APJB8CM2HzBtj5AGXvhA6sKe8C4Zt2DpgP/Do0NwC/gKQI uAoYDZvWiFxCex+D/duRex/4V5H7NiSfAxuAN8EmPNFHQ+KCpBf43YyRGF/XKCBG34VIcKIWB3Id b8IC+lZpA/87oNUnKuTwUMuFJ9DXJgChqcJD5RT47ShbB030ufoJNGFZRVS0N3NktjdYdzhRtoTn O8VqKTCGV2na9VDc8t0kfQyjdoLRGMyo9oUE95ocS8DPYHRCokKirAdC3wBPs6AMkV+GuVCG+C9D zLPkGMruAKbD5q0o+yz4R2HhfUhSIZkGyR8giQA/EvxC5Fo6Vu13w5OZsHwWPi+At/DZQF16Jfhi lHoHkmzwfSCfCsld4O+H/BXgC5BrsAwPtXrw68A/AnwNmAQfngJ6IPkQmAmbN8DOByh7J3RgTXkX CN+0c8B84NehuQH4BSRFwFXAaNi0xusS2vsY7N+O3PvAv4rctyH5HNgAvAk24Yk+2hpTjBGQVqQy zP0yrGNlWJ3KsDqVYQVjuQsWesHabsZIjLJrFPMuxJILceWEVw4rll5hnUjwjjdRO8ZFaQP/O6DV nyrkaJ2Wi1ZAX5sAhKaK1imnwG9H2TpoYrzUT6AJyyoiSnqxZ3gL+5wxOHefwH5pMPZOfSHBfTnH EvAzGJ2QqJAo1u4I+gZ4/RhydwDTUepW5D4L/lHovA9JKiTTIPkDJBHgR4JfiFxLx7J/N+qaCctn 4dUC+AOvDNSlV4IvRql3IMkG3wfyqZDcBf5+yF8BvgC5BsvwUKsHvw78I0BcQ2lJ8OEpoAeSD4GZ sHkD7HyAsndCB9aUd4HwTTsHzAd+HZobgF9AUgRcBYyGTWtELqG9j8H+7ci9D/yryH0bks+BN8Ea fNBHQ+KCpBf43YyRGFnXKCDG3YUYcMK+A7mON2EBvaq0gf8d0OoNFfIT1jUafIC+NgEITRW+Kdj/ q9tRtg6a6G31E2jCsop4oF0i7VXaYvlePe0SN2OXuBn7MexesDO8oPXB/rCF9ye2nN/HdFt7SPU8 dol1kC/kexGQRDDSLvE0domnsUs8jV3iaewST2OXeBq7xNPYJZ7GLvE0donMX2ftSO2daiHvpfkJ glLFqMaCPwCsBS5ilAuQOwySI+ArgemQDAGugySKUcuAZA/KtvHTN2Us7eilPA3eyTyVYuwJST5y +wOLGdURlhxoAocAMxnlUkY1C/xxyE/ycxblIrDW8TB2VpnsD6M2Bv6cZDnpPAwd1lzEvFwAXAr9 dJQdBlSAUcht0w8Cn+ZWgG8F3593vLIfsD9d43JbnuZ2sQ7h02gp8yk2Po2z6o18lQTP4yARLFEe 0+m6WCtETyrsj+yv+dmC5SEsVIHfz7xaBP4/4c9S40N4xToH0MYjyO3PT47UWEjykXsWfBz4PdBp goU1kKyz66LduPIpNPfAk+N2rsWTz/pg9lbN4x24hvufykX2Qc1Cv8VC8zRaV2fLuYeLMBY9Dd6l 5MO3OLajDNZfwlhwKY1nkFyAFmncq7I3Yqk3ImQkImcw9wztNEhH2YCyo/Ui9PbTfBVsjR3aVQv9 /cBW9LPluY56fw48gRF5wqCrV+UbWhtLoFOD3Bu076EW5uOg+RprqkOhk8goK8HHGS7irRalQPNN q3VsQbPG/UZYewvyn6HsSONb8J/vdo6GTjpyfw1+NttUpqCH70XvPYXe2AM7AlgIHAwdybzcAlwH PAQcjVjKgs6D0L8Nkp7IjdN3EvZliewNTEGLUnG32SoLufqwVkz8GVjIhzwfrVgJO3Nsf9jCDPZf vgBMAC4EjtZXkM4s2ybrnwD2Q6k96MM9sPkl5LdAswnjYkLnCYyjA/INeC6TyjGg3wW8k1Gt5nhQ pb6D8ALz2k7wTyF3DKMShVrOoLfXc13qbmvucORoGYiiLPAx1nqCeP4ddJ7BWPwOK0kPyJ8Bn4lI +5/g66w1EJIySIbw81m1CHFbwbySAhzLc0E5i7mfiFL9scOphA8/wXyvhA9TMBNNYAnqrbItZ2Id c/L9T9j8BueqijUjYLNVfxErQCa84icvU+GPAmtx8MFprSdoo4b+WYR+LuH+ccIfRxXrGPDEqbCO 8Rpi9ReMzhkscWQzr38MTEN7T8CfRFguQV0m7xudi4wFfH9JT4NNfo7ZB337LCK/DivSLnj1Kvys gIW7EEs/QIR8As3NQAn5YzybVKwV6kicL2KNVKxIs9AzfLfhDFZgoT2A2bESM30o9vz8Ll8K87QC Eyq3A2dBsgfnnd+ilvchKUZMxgE/YmvKNvT2af1HVG8hnqIORqk2ltDq+iPc6+Daf4DaT7Od9u3K EYw1eajNZNTngW8EbodkPfAcWlHHqLYgdy6jowS59cBekBcCVwFjIC8ALob+OvDTkNsMayN4H6I+ pPfi8yDzWhLkiZAfs2oEP5916Iw2C3HI8suQDIfNo9B5DVgE3AE8D6xkVI4A7+VSmoG6MhgNDTqX IRkEvgb8MqMf9wOjXg/8CaMRyehYi1YMZZ7WZ8Yp0HkE+HtIfsbXxeQD4+OMygHtSV5RGbUYyF9h JH8YvwOcgRXmLfiwBBKB530nNL6rOUOjldPxPPohhXdW2mTUdTuuwe+CzxJ8O/ihqGW6cQdJfgvN nyD3Zvh5HaOyHPwY9OoOWH4Zrfsz9E9AvwD8t/k+mPEsdg6P8hquv89+6oOR+yK8Ha3fRDr3QPIB 6+snefUjz9n/76LGX2mNkFAM6zif0nr4JbXrS/SwBp+/yesntZ3mrDEfbdmLupbrvAeIZ2t6s87v rY/Ec88I4F8gn846xkU+b2qX9PtZotG+1/gmo/6i5Q9W5oPqND5XWj3MEkcMlzLisLafYWtKAjT7 MhrX8+5as841aJeajxH5IfQ/sSyrb6LVEST/DbeCeqk39jCF8Hwn3/FGnw/EKJ+CnUR9BEaB+Qe4 lDEVNm8Gv47r1d+y3iXA6GC8tGUYtUHcCnUD2pLPdWn57IM6GZJ41DtDJ4mmQ7MIGAt8A3g/o7Ie EfUINKewBQ33mbUk2Hyaefmpzs9PPczTOvMZX81hHlllMxn132q0Nurz2Sb1PD8ZWcJydQlaN8ji 2aa6CHgn6spX+bz5Aiw/yj4o64EjeDSVSkuivcAtQi33wM6HsDAGPdwXfgpESL5dI42COhM4CJ58 Af0vuS59Mp/ltVWocTRKzUArouFJH/1dLsVljRNo4yUg5qZ+O8buPozvKI1izKjgkdU+h7wBOA09 n4Fn3z74NghzZKa1bmDdO4aYvwUR7uf5or2HFaYEEXIU+i8h90bwMZhBR8BPxjtUt+s8dlWYmxKa /wNz9k3Uchmafqw/e6HzAPgTxk8pdzN2I2/wTNR28yhEbOZSrlGs47yN0YVIc2xBvG1ldL3F6Mxn NH6P3A3wdjrrR2yGzijuAbJA6MCar6frE9An1M9qD8TGIpbQuYNQ3Yg5iLM5XctcwDrGZ1sf76b0 M9xXNB/74JzF82sOo7pFz8dZ5k3sn9nOneh5oVrR4uX7IXwla9yI84WHeQVnW60X89o5SN6FhQ3g sf+UJ7H//D7m0RJtMlkw+ZmFlqZFk+RHLFEmoMZPUONU+IZzdHsz3qq6iHe0qvAcNrb9Y17/IakF LrLl/HbWAuDnkAxD7hHwlcB0lD0LeQn4dZBHQYI3weR/sffdcVYUW7e7uk71Ocx015BFMiMgyQFJ kiSLSFTEEQkjySEPMCAiIklERERERERAREQkJwUREVBRSSoCKiBZREQFxIQ68/Ze3RzBe/V6v+/d +897c361ak91dXX1rtqrq7qre2chvZ2gOgW5MeSeyJMbT8/xjFVVEKRdSGmHcpoiT6vgCTuemtVH znkoYTJKqwVshfxVkb808mzGU+9UpExFyqlgnRj2TQ5zyr41BXVxyIVxLII8EHlq4ol2C+SpivTj KG07jtgmrMlZ1HAAtCQpWXiOthJHPIUyF6D+k1HaVJSzDesHRmLf9UFpyBNB+QUC/SOlQKAllNk4 0APkRcFqOtStHEp2kZIHWAV74Xy1wVFewHGPIeUeyCWAeZCzMNJfA16Po6CVFdb+6TfDvURGzgg0 o/Nh33dQ/sBsnsE5syAPQQm3Yesi4KsoYRi2piNlC/JsQR2gYUdBey8DFwB3I70T8BrslRvpRVC3 oK3RavpqYKCNpsgJHepu2Pd0cO444jvACsA+yBlDrbC2hH5Eek7gIziWCc4FeYainAJAQkpy0N9Q ji8aUHjC65TF1r0oAc/XnCj65C7gUayXqCb59RzUU6H+P0C3myDfh3MJ+jBsSp2GvBBbT6KcnEg5 hK2HcZTZwFGocxbkb4ClgceRvjfIg33bhfl3kzxHFnww6JNhr5OUDyBXAq4E9sURz6Mm+YHlAt7A OoTGwHbYdz3WMFQI1zDAllH+T5B/wtbhYT0DWXBGaDW7UecBqL/Yl4OzdoOzC3gMeWJokQi0PQEy Wi2GPhwF17npkCvJVhe2pmFNvFVSwDxmBOzoLpxL8ZDZzsrsDPsOQTpW1DglUYcZ0EMzYFukX4f0 kaj/t8DVqM8iPN/H+hA1EC3bLMBAD9nzwbozwRhzwaVYH4j6vIaSKwbMGTKA4MuBBQE7APcAP0P+ tahti7AnzAX/CP6IrSNDTha5c+Q4H2VIRGajnYMeiOcLm3Bfd1PwfBZPjbOj+4Slo98IxsYyHgmR W4eWxTpiZbXIJ347Lq1vmgizyappPQnvd55wN0tflRXOKg3rnJtiTXU2ZqPWTJT1z7KemeVpSJeU N2UNqsohMg8WFwIlfZfMZxmTpQ6yko2Kyh1dqiMrEKgMMC+Q5MpIhJwkM2LG5kB8I9M8DhwKxNc1 ZXzFe+0E4jm+GYT6SJ7V7hHGocDV0eIiA1e7xZBeDOl1kV4Xch3IdZAnBXlSIM+GPBvys5Dl7sSV kX2CZrgws9tJZPdDYCCXAHZBnieBraUEw7qlM6Yw5PMoc7+kuO0hfws8hDw7gB+ibl1FjnbBXmlA Hj+omVh7MB04060iMnCmWxCy4MxoTpGBM0UDLBdHnkLIUwjpA5EuOM+kCLoNIR+EfEwwmgtyeciP SWvKCmdu02xO0VideNDdJilReS/9xSiXTDMEVRF3Ou4ezBF0NeNSOVN1yowF7kX668BNSGkKeQ1k XKOjrDFnutz9UBUiwX344M52a+B+oNwpqiB9leVCwGtlL1NVrDLEjwSlH3LO9YJR0VJJM0RqFTkv svs+asijODqJ87oQLYX0eUgX/Z90ZyA9CqyJY42RNgrq5s5FmzZFq3UC+ki/FW36LVJqIc9e1KEx 5MNc24ciB7A1hpShwF+Bw4DIabZDHoPeshY9pBN65in0Ye57apuMb9U2rF3ZZlYxPibHdXKYdSw/ jvs8O3A3KYfsq3aIhtXjuI+9A/i4aQT5Tsj3Q74f8n7I+7FvRZz7QuAE4BbUvxTOdxHwEdSwBLAe tkZlTIg7yfOM9K7WsqKez0jYo6Wsxle5pOerGbLGWM2QmqujZo8g+sBRsUHGnoLyZgrL3HPolCur yr+LDuYUT+YL9J0ra5aSxdZUGvp2sivXrzRZC6Q82cp5erOcEJFzaWLqAqXOQ8VOub+1ZVwolusk R2QlQ7KZJOi2hLwD8t3At5HyOFB62okoIb0R9j0AZKZS2SYP472REyLrFdLDtejwM/0DUk4hRe4k J2Prq3qWpEdeQDpK0F8z7sVe2ZEySH8LclnIXBN1MiK16uJ8KbKcl9NFVkdz+mrIgyG/DJlzqgwT kTaK5IPdCSuewfd1z9CdwvBYp3QU3w8hfKeesEqZeIvkkbaoQANFzn5IZEGW20qZwDOyVZXNzmR8 jqpJ68tXJTlliqRkvwu5O9AFPoByRkJ+CvgCyvwZKG13JqscZLnWnPkNlpKVHynXQHbEWrNKMh7P KoMxzxlBKYHlY8B0YA1gfmytAtkD8jxdPYna3gd8Uo7FGJUU4BSkfyilqQ6QWwHXSN04PZjjyLV7 atYFlCl3Vg9nfYF05oFInWyxynlSK9ZJNYzotgnKGfE8a7Tgb2uAYn2HoYGTv50Q/vlN5p6FJb+a h72Ssj+B3gItSQ0ryNnxyASYXQxbBW/Nkru7OaCN0cj/WdZykrH0R8CdQOHteVITrmExHCUdZabj uDWQUkPuV0gJPLuUs3gkmzWv8mQtwKxBVmCqrAmQxb72Is9e1O0o2nGY5GfkqwzVxZtWpbOFG/sg Z1P5ghGPOUVLTZHeJFtW+q3OuhvnJVe0jCy5A1A7W5j2ZbTaZrT70Gx5F2xoFvOSk4at3yP9THZ1 9BDwVbYHeTeQZbU46znGJb/JuzBfYmS1Olvut5+StzXpXXm/jFtQdFJfMHuOvJ1Ev0R49MIjn7ws PwPruCC2kz0R78odAT8fcJuB62bguKxtelXWwLPlfg/LPQt+MCJHmontmyOiYbk2cd2CmstZ3C/t 4sSCPg9mLp118eueCaqG2UWmS2aXrlS8272ZfWlYj8y7+tD0nnd1zaS1fbsMzqAtlJOcJg3aFKcy t7VpXFx81GRnUw4ynB6j0lSWrqObqIK8E4B0l3IxXk3lqAbJVx6LIT2Botw2CVSGylNVqsnskELF xadpuPVKykMlqCLVonrUGN+XviW+NZEKUl5K5rgS1ebj30DMqNQmvt2hfORJLVu0bVqcKrRt07w4 HznYsxDlp6vIp2upDjWgJvjG0K3Y5lFh+Hi3zFfV6HpqSDdSa9LUNtxahApQKUqiKsw9dakRNWWO i9BtlNqt8qBujgvMCSwILAlM6dal72CnBrAusHG3bv0GOM2AbYFpwJ7ATOAw4FjgpO59e/VwpgPn ABcAlwPXAjcCtwB3Avd2z+jfzzkIPA48BTwD/CG9V0YX51dB7QBj6ZldumkLLABMBlYAVu+V0Wuw rg9sAmzRa1D/vroNsB0wjQ/bRXcHDgAO75txdz89HjgJOBU4Azinb/9uffV84GLgyn53de+l1wI3 AN/ijJl6K/AD4F7gAeDR/lLOSeAZ4E+CEQLGBgjmBOYHFgYmA8tkchUjKcCqwFqD+nUbEKkPbAZs C0wD9hwse2UChwHHACcAp5B8y+gK7iFX/hvSxfW8v6Nma4mxtfyZJPnk3WGHe565LOWfSQ5bWJ5/ Gpdme/w9VpTvn6T+vrXMX2LiH1CzpRTFh9P/rqTI/wdM+ANG2PJyMpPk+QtZUam/xCgw0E/wzSzv H7DsX6DDDJX8N2LFDPNXaP+AmvmsEBX+NySHubHkv4xrUCYNozE0gabQDJpLC2klneDR1E+KVEzl VAVUcVVGVVLNVFuVptJVhhqiRqhxapKapmar+WqpekVtUFvUTrVXHVQn1DfqB5XluI518jtFndJO ilPdqes0cVo5qU6ak+5kkCuvYzoRMLF8qxlxLLi2qBxzSMaJKsd8kiu3SmwR/J+4UpCUt5jTc9AV 3hbvE++07/h5/TJ+XT/V7+kP96f4C/31/gf+CT/L5rQlbS3bxna3Q+0klOXY5VZmyDlI2Z9YTxwn ucH/BQoHceHKfDSOi6cFcYl5wdFLvBv8n+ygpITkSsmNk7cmH79qxFULSmaWnF9qXKm1wTFKZ5Ye hRo6paeUXhDsXXpvcG6lT4Tx6SC+ul0YLw3icuPC+FwQl785iFMqEd5pSake/t8+jIeE8ZQwDstJ 2RrG4fEqOoGOKxYN4+5h+uAwnhzGi8NYxsoSHw/qX4kC7VTCt884nhykX1s4jCuFcccw3hrElVOD /JXHB/tXnhGUX/mV0L5ygx8krQLn1HwFb8nJq9QqcqK1eA4rX2D7L/s5M71ljMINXVU3ibRjO6rF 1/hmPG5oT12pd2gr42kyTac5tICW0yu0gUc7O2kvHaTjdJrO068qorwon2N0cXRJdA3ipdG1iJdF X0W8PLqO4yUsvYZ4SXQ94qXR1xEvi25AvDz6ButiSXQj/7eUc29CvCS6GfHS6JuIl0XfQrw8+jbn Xhrdwv8t49zvIF4SfRfx0uh7iJdFtyJeHt3GuZdFt/N/yzn3DsRLojsRL42+j3hZ9APEy6Mfcu7l f9BITxpAQ2nU39LILpz54uhHoWZ2h5rZE2pmb6iZj/k4i6OfhPr5NNTLvlAv+0O9HAg18lmokYOh Rg6FGjkcauQINHI01MixUCPHQ418HmrkRKiRL6CRk6FGvgw1cirUyFehRk6HGvn6X2hkGs2m+bT0 TzXyTaiRb0ONnAk1cjbUyLlQI99BI+dDjXwf9pgfQs38GGrmp1AzP6PHXAj180uon19DvfwW6iUr 1Eh2oBHmX2gkpgKNxJxAIzEtGolFAo3ETKCRmBtoJBYNNBKLBRqJ5fg3NPIWbafddAC+CM7RBZ6+ JcQSAo3EEgONxLxAIzE/0EjMBhqJJYlGYjkDjcRyBRqJ5Q40EssTaCSWN9BILJ9oJJY/0EjsikAj sQJBj4ldGWgmVjDQTKyQ9JhY4UA/sSKhfoqG+ikW6qWUnGmseKiXEqFekkO9XBXqpWSgl39bI6fj GikdauTqUCNlQo2UDTVSLtRIeWikQqiRa0KNpIQaqRhqpFKokWuhkcqhRqqEGqkaaqRaqJHqoUau g0ZqhBqpGWqkVqiR2mGPqRNq5nr0mLqhZuqFmqkfaqZBoBm5Mki95TqgpjDTe5TBF4IYXxMK85iy EuurMc+72nm7mOkbxW6JTPE+CqUnvN2Q2nDanlB6wtvL0g3I93EoPeF9AknyfRpKT8BvT0meR9bg 9mhBqdSZWX0wjaDx3r74kfbHj3QgfqTP4kc6GD/SofiRDsePdOTikbxTLN0Ya8RpX4XSE95pSDdw 2teh9Fc1Ohqv0bF4jY7Ha/R5vEYn4jX6Il6jk/EafRmv0TfxGn0br9GZeI3OxmvEtq9SVAoPEQs6 sj7tKucqEm9BMVJ+FYzD5O7eKJ6f/EOdeQw5j3vzWtrF/fgn7sGeys8jyHKqqqqrmioZsUQSN5MD rx+RxDfj0lsXJWcHS9Mh7YxL78elD+LSh5BkROY5u0R2jjFOw7aP4rl2x6U9kDSfhaW8zl7sITV5 1JFaPIk8H1+SJ78jdZrmvE2ac05zPomX9Glc2heX9selA3Hps7h0MC4dikuHIRlu/7zc55OpjMPX Z2cWH4uvz85sjt/hHLOcdxlnO0fi+x0NzzvqTHImcxvNceZz/gXOYkpwljpLKclZ7qygnM4qZzXl dl5x1nH5GuP9vGxXCt/NJvGkAR+Zz/GGRc4iLnM159fO687rPHrj1nam4suF4vtQ2p6ZHrPJBJ6f aGeGM4OKODOdmVSUy3iDiuFLhPXwJUIp/xzP8gpzn67PnNeRMpjt5tJivv6dDNpL5+byf/TbkWNq hik3IqU9Uvgs/U4s1Qq33YRtt1+SuxlS7ojn7ojcBr46C/CMsST2OY/jnPV5HGpqY5/vcZxz2KcD 9r5kHzmCc15qxfvcIbmlPs45yen8FBxZjuT8ILWTb3twKalSE+jrrHzzy9Q0tbn3iB9H7T7kjnPk TpPWaACdoGXFl6c9jHblq2RK4d16Dinw6XNKyV3R3ZekaflCvJJ7kxsvSVVqqzw3uGzfpWotp02/ bN8Z/JMnS2MvSY2osfhNkvual5U5nEPqZWW2F6+/qvFlZTbhXyqnVrqszEr4cdurgpeVKU9FnMvK dOHL6MylZXJ/OafkqdSBS8vk/+QnrbXl0jKJ9UZLLy2T56zypHbmZWXO5h/rLe6zLihzPH6sE8q8 rEy5x9/+sjLT4I2w6WVlNuNfOv3u1Sgosyp+MlsrGk9X4ZfXtfOzfMmN296jBHec+xC+ZHv5d+IV vgSv8HVlFX7xXZHcWa4QllcRNaqEr/gXjKdJ3uf/zjHs0KBH6i/dIlr4XbnF3BKyLTKVNqsJPJuf wvP5GTyjn8tz+oXcl1byvH4dz+w389x+K8/ud3Ev3Mcz/KM8xz/Fs/xzPM+/wDN9h+f6CTzbz83z /YI840/mOX85nvVX5nl/LZ75N+S5fzOe/bfh+X97J83p6qQ7vZ0MJ9MZ4gxzRjhjnHHOBGayKcyw M5jn5jrznYXMYyuFuZwNzmZni7PV2enscvY6+5yDzlHnhHPK+cY55/zgXHCytKNdPm+rc+v8uqAu qpN1aV1Op+jKurqupevqhrqJbqZb6TY6VbfXabqrTte9dYbO1EP0MD1Cj9Hj9AQ9SU/R0/QMPVvP 1fP1Qr1Ur9Sv6HV6g96st+iteqfepffqffqgPqpP6FP6G31O/6Av6KyIE3EjCREbyR3JHykYKRpJ jpSOlIukRCpHqkdqRepGGkaaRJpFWkXaRFIj7SNpka6R9EjvyACe1Q6NDI+MioyNjI9MjPAMXJ7L 6eIceEasZcUE9yHx9K551i/fv9JjOcj3h8bLClWsqFBa9pvKga96mmfX+AaWrCeV9SQLZfWhrGEk hS9krST5OprSbBPy5S29mYN8uYmZRO+UVccc9nKQFfgHORzlcCKs12kO33A4w+GcvM3AgetorieF bz014NBIVr9yuJHDTRyac2jNQVY6386hAwdZWdmNQw8Osmq4P4dBHLjfm/s4jOQwmsMDHB7k8BCH hznI98ge5fAYh8dl1TsHvmKbpzjwqME8w2GWrKLmwPYkb6OZlzgs4bCCg3wnbA2HdfLuIuGNGCOr Ud/lsJ3DBxz4/M1uWScsK1w5HJb10iTff1HmtLxxwOE8h584/MoWRLIqnAPzlutxyMkhN4e8HApw kFW5RTlcxaGUvCUrK2o5lOdwDQe2X1kBL6sq3Gryri6H2hzqyRuyHFifst5D1nm4stJzUHAXLHE1 B25Hj63YcznwNcWzHPjYXn4OfFyPj+slc2AO8bitvHIcuL08vv57VTnU4FCHA/O115hDUw4tODCH eW05tOPQkUNnDt059OTAVwKvL3MJt5Hl9rHcNpbbxXK7WG4Ty21iuU0st4fltrDcDvZ5DtwW9kVy 7EuWW8Ryi1huEcstYt/hsI3D+xw+4sCatzyOok06pmVCWkwXk7V9+mpydHldnvnrGn0NRfS1+loy upquRq4erUdTVD+gH6CYflA/SDn0Q/ohStAP64cpUT+qH+XRwmP6MfL1E8x8Vj+pn6Qk/bR+mnLq WXoW5dLP6ecot35Bv0B59Ev6JcqrF+lFlE8v0Usov16ml9EVeoVeQQXwvbkr9av6VSqoX9evUyG9 SW+iwvpt/TYV0e/p96io3qF3UDH9of6Qius9eg+V0J/qTylZf6Y/o6v0EX2Exyaf68+plP5Sf0ml 9Vf6K7paf62/pjL6W/0tldVn9VkqZ8qwjZU3FdjKKpg6pg5dY+qaupRi6pv6VNE0NA2pkmlsGtO1 polpQpVNU9OUqphmphlVNa1MK6pm2pg2VN2kmlS6zrQ37amGSTNpVNN0NV2plkk36VTb9Da9qY7J MBl0vck0mVTXDDFDqJ4ZZoZRfTPCjKAGZpQZRQ3NGDOGGpmxZiw1NuPMOLrBjDfjqYmZYCbQjWai mUhNzSQziW4yk81kamammCnU3Ew1U6mFmWamUUsz3UynVmaGmUGtzUwzk242s81susXMMXOojZln 5tGtZoFZQG3le9x0m1lullOqWW1W0+3mFfMKtTPrzGt0h3nDvEEdzJvmTepo3jHvUCezzWyjNPO+ eZ/uNB+aD6mz+ch8RF3Mx2zLXc1+s5+6mUPmEHU3x8wxust8Yb6gdPOV+Yp6mG/Nt9TTfGe+o17m R/Mj9Ta/mF+oj8k22dTX5YsL9XOjbpQy3EQ3kfq7SW4SDXBzublooJvHzUOZ7hXuFTTIvdK9kga7 RdwidLeb7CbTELekW5LucUu7pWmoW8YtQ/e65dxyNMyVVUT3uSluCg2XL47T/W5ltzKNcKu6VWmk W8OtQaPcWm4tGu3WdevSGLe+W58ecBu6DWms29HtSA+6nd3ONM7t7nanh9xMN5PGJ65IXEEPJ65K XEUTEtckrqFHPJ540UTPeIYe9XJ4OWiS53s+Pebl8nLRZC+fl48e9670rqQpXhGvCD3hlfBK0FSv lFeKnvSu9q6maV5Zryw95ZX3ytN0r6JXkZ72qnhVaIZ3nXcdPePV9mrTTK+eV49meY28RjTbu9G7 kZ71mnvNaY7X2mtNz3m3erfSXO9273Z63uvgdaB53p3enfSC183rRvO9Hl4PetHr5fWiBV4frw+9 ZEfYEbTQjrFjaJEdZ8fRYjvBTqAldqKdSEvtZDuZltkpdgott1PtVFphp9vptNLOtDNplZ1j59Bq O9fOpZftPDuPXrHz7XxaYxfYBbTWLraL6VW73C6ndXa1XU2v2S12C623W+1Wet3utDtpg91ld9Eb dq/dSxvtPruPNvFY1dJYHlGU05V0VX1eT+RRwnQ9U8/R8/QCvVqv1ev1Rv2Wfldv1x/o3foTfUAf 1sf1SX1anzZl9XlT1pTXj5iW5hZzm7nDdDJdzF2ml+lnBpq7zb3mfvO8edEsMsvMKu7nr5ryZoPZ bLaYrWan3s3xXrPPHDRHzQlzynxjzpkfzAWT5Tqu6ya4Vp80Ld38Otkt7PZ1q+sS7p1uN7dH4lov 4sU8z8vp5fUKeIW94l5JL8Wr7FX3anl1vYZeE6+Z18pr46V67b00r6uX7mXY0fZB+7B9zD5ln7HP AhfZZXaVXWPfszvsh3aP/dTyXJbGgJEJjKzAxQ64WIOLI+BcA7Z1wbNR8GwMPJsDPJsAnk0En3rg Ux98asGnSeDTnODTXODT3ODTPODTvODTfODT/ODTK8CnBcCnV4JPC4JPC4FJC4NJi4BJi4JJi4El i4MlS4Alk8GSV4ElS4IlS4ElS4MlrwZLlgFLlgVLlgNLlgdLVgBLXgP+SgF/VQR/VQJ/XQv+qgz+ qgL+qgr+qgb+ug78VQP8VRP8VQv8VRv8VQf8dT34qy74qx74qz74qwH4qyH4qxH4qzH46wbwVxPw 143gr6bgr5vAX83AX83BXy3AXy3BX63AX63BXzfzrKAY3QImagP2uRWM0xaMcxsYJxX8cjv4pR34 5Q7wS3vwSwfwS0fwSyfwSxr45U7wS2ewSRewSVewSTewSXewyV1gk3SwSQ+wSU+wSS+wSW+wSR+w SV+wST+wSQbYpD8YZAAYZCAYJBMMMgjcMRh8cTf4Ygj44h5wxFD7IrPDvWCH+8AOw8EO94MdRoAd RoIdRoEdRoMdxoAdHmB2yE3jdAldVlfUVfR3+hH9uH5KP6Of1c/rF/UqvUa/pt/gHv223qbf1x/p j/V+fUgf019IH2V2+I7ZoRyzQwtzs2lr2pmOprPpbnqavmaAGWyGmuFmrplvFpqlZiX3orWmnHnd bDJvm/fMDv0Rx3vMp+Yzc8R8br40X5uz5nvzs/nNVa5xc7i+/sK0cPMxKxRy+7jVTVuW0tyubro5 kviyp72ol+gleXm8K7xCXjHvKu8a71qvmlfTu95r4N3g3eS19G7xbvPu8Dp5Xby7vH52lB1rx9tJ dpqdYWcDF9qldqV9xb5rt9sP7G77iT3ADPHg/2eI/4cYQkYpt4In2oInbgNPpIInbsfIpB3Y4g6w RXuwRQewRUewRSewRRrY4k6wRWewRRewRVewRTewRXewxV1gi3SwRQ+wRU+wRS+wRW+wRR+wRV+w RT+wRQbYoj/YYgDYYiDYIhNsMQhsMRhscTfYYgjY4h6wxVCwxb1gi2EYUdyHEcVwcMb94IwR4IyR 4IxR4IzR4Iwx4IwHwBljwRkPyjo68qgoDaDNtJ320mE6RecpS8VUblWYEuChWvxTp1BVqkX1qQm1 0N+zDY3RPzKO1T8zjte/ME5yx5NjrneHMtZzhzE2cIczNrJrea71uF3H+MSflPgDSvwJJV5Aib+i xIdR4r0o8T6UeD9KfBUlvoYSFUXcEZIb0si4NCoujY5LY+LSA3FpbFx68KLknYtL30FymB0OyTdA zW8mixzmNIfzG9cll7ktgWLMSenwByb3yGK4M5s7cTszy6Oynz71u4x3MZQWX+ByNzmBSiJ3Ts4R ieeNhDlli9Ujma04PYixvyNlcZyCEgrgecUO3us7PUl/FuxluwS5g1jumfBeS3gvufEboXJUiarD f2ZDojDtYssEd/MqoZ7HgPOAx4ELuXwb3FvWuXVu5sobdXPKYaqaqmRNDVObktwb3OaUx23l3koF 3VT3diru3uF2oOTEBYnLqVTihcRsSvFT/U5U1W6yb1Mde9AepAaoRRS1asjYlFqRrKPuGNYvGtau cNhzglpeizo9CzyIJ0Ea8q/AQzjrU9Dkf67OSZTKtZTVGAM4DGF5OI1haQJNZnlaeB84yFmBKlMN 9Pr61ILlNtSOpc6UznLf8Jwqo+6vAQ/jDKrLfa6L55a4HVu2Ac/Hz1D++xq4Cnj0P3rOeXG2Q2gE jeUwgWV5cjyCZtM8WhhKyzlVvl+6Pjz7vGHbNqObOaSyLFprFpYUSMM5dUyohyr/Sz2MjveB/45O 8nAr9qVMGspnP5T1MgE6mUlzL/lvAW8PnhUEe8Q5kIP0hTTqDn38/t8QWasMfVTFOTwOXB2ezx+1 8egl57wU+Pwltnsi1NV/UgsK33ktSRfXdOYMa18N9/03CiYlhdvkaUVj/CRH9TC1AHNRSvgL0h3S ic8lziVKnCe+c+0X8C976ROF3BR4G4s4X5DjyLox5cwJnxAPhpbk2Ud3qmgL2yK2qC1mi9sSNtle ZUvaUra0vdqWsWVtOVveVrDX2BRb0Vay19rKtoqtaqvZ6vY6W8PWtLVsbVvHXm/r2nq2vm1gG9pG trG9wTaxN9qm9ibbDM/dKjh3EDnjnfHg56ZUwv/NOjbJ5rF5bT6b315hr7QF/F/8X/0sP9uSVVbb iDXWtVEbszlsgk20nvWttTltLpvbFrSF8AS8vLqGT/Ws+pHlnx3xP+moGF/b7/SH+ff5w/37/RH+ SH+UP9of4z/gj/Uf9Mf5D/nj/Yf9Cf4j/kT/UX+S/5g/2X/cn+I/4T/rz/Gf85/3F/rL/FX+VP8p /xl/tr/Uf9L/zp/lz/Nn+i/4c/0X/QX+S/58f7G/xF/kr/BX+sv9af5R/0f/aX+1P91/09/hH/HX +q/6r/hr/PX+6/4mf7P/of+Rv9vf43/s7/cP+Af9Q/5x/4T/lX/a/97/wd/pv+yv81/zN/hv+Bv9 t/wt/tv+O/67/nv+Vn+bv91/3//A3+Xv9T/xP/X3+Z/5h/0v/JP+l/4p/2v/G/+c/5P/s3/BP+N/ 65/1z/vH/BmsnVaUA6uNS8Ljs6xoKQSv4snwKl4SXsXLwKt4WXgVrwGv4jXhVbwWvIrXhlfxOvAq fj28iteFV/F68CreAF7FG8KreCN4FW8Mr+I3wKt4E3gVbwqv4jfBq3gzeBVvDq/iLeBVvCW8ireC V/HW8Cp+M7yK3wKv4m1UCVWCboVX8bbwKn4bvIqnwqv47fAq3g5exe+AV/H28CreAV7FO8KreCcl XsXT4FX8TngV7wyv4l3gVbwrvIp3g1fx7vAqfhe8iqfDq3gPeBXvCa/iveBVvDe8iveBV/G+8Cre D17FM+BVvD+8ig+AV/GB8CqeCa/ig+BVfDC8it8Nr+JD4FX8HngVHwqv4vfCq/gweBW/D17Fh8Or +P3wKj4iyn80Er7FR4UW+7+1yr+y+MBi2zsPscU+7DwMi21GyWydYptihXG7ZXv9Ddbq/MFexVov sdXAvm2CrGdQKaoKl5zTyUOuk88pTwnORGcilWDLTeDx+P/Mcmeypc5i+50dWvBcttYX2FLnw1YX sq0uYmtdxra8gq11JVv3DNi3WPaYP1hvYLuvh9b737fdHayl1qHtNiZ5r7MXjWbbfZh/VWkOyZtz y/l3Hb3Kvxq0h3816Qj/atEx/tWmz/lXh07y73qeu5xiqz3Nv3r0I//q0wX+NaBf+deQsiibbVcr zVZrlGGrjaoo3agSuC2a8oTQY9vl5mXbzalysu3mVrnZdvOqvGy7+VV+tt0CqgDbbkFVkG23MM+P blFFVVG23eKqONtuskpm2y2pSrLtluZ5Vaoqo8qw7ZZT5dh2H1GPsO0+pZ5i231aPc22+4x6hm13 lprFtvusepZt9zn1HNvu8+p5tt0X1Atsuy+qF9l2X1Ivse0uUovYdpeoJWy7y9Qytt0VagXbrqxP 7qleVi+z7a5Ra9h216l1bLvr1Xq23Q1qA9vuRrWRbXez2sy2+5Z6i213i9rCtvuuepdtd6vayra7 XW1n292pdrLtfqA+YNvdpXax7e5Wu9l2P1Yfs+1+qj5l292v9rPtHlQH2XYPq8Nsu0fVURqhjqvj NDIai8ZolD+Yr7ujgyswYQzH12gdXqmTwzHBdVjJ8xr/yN5m5V1jWZ+dJ3xboCAl2Oa2hW1pW9nW 9mZ7i21jb7Vt/5jH7+x38bv63fzu/l1+ut/D7+n3+mMelvNSPp7hBG+xBG8kcB7et9e/Ksfv7Q+K 5+nt9/H7+v38DL+/P8Af6Gfytr97rL9RTlgfWeUh45koj54KUPGLs2VffGLfRC38exC39u9F3NIX T8430RuMLWijWJQv6ytaQus3XTo6suLduznSrws1fJtNtbfbdvYO2952sB1tJ5v2P2mF/yvlWB75 7UlMSmJK/ZP194rZWd7ZS+aZVHW272C13TasDtseXzV3XPxbQ/o8Lp24KLn3SO5/sdqsJCXx2LKn 7WV72z62r+1nM2x/O8AOtJl2kB1s7/6TVS6Kx/5JvPfF+XXDcB7bHnO8YHbg2KG2B7AnsBewN7AP sC+wHzAD2B84ADgQmAkcBBwM/PM65Y+3/3qK6Hn6uKzFCGf3KfE7FvntGxTlWbTWz+pf9SF96vL/ w7mVzLUHYB9ZlViGmlq5C3qYZ2aa5yBab2P5vD7F0td6FctHw+3V/53tfKz49vgscFL8qJWpo91A ef/kqKOl7peUH+T8Z8f/GznDmozG+f9jnarGNbuR8ujVvCXYV+71LNXPs6ZPXPLf+XBPmcPlxZ7G bkxKSsqZlCspdzg/ghXYIfYee29Snj+d+fxriwvfX8JbsR7e1yEyzhldKNIj0jPSK8yhglxEBbti ho6/gu0rjSmY6ub4P9WdeTjU6/vHZ7WMJYwlsoxsWYbPDKKyi7GOZWQp0WAwytIYawoT0iJ7hDRj CWUrnJTWo06IaHeUJZSKZCshfD+jUznn2/d7zveP8zvX75rLNe77fj7P55nned+vz/08rmuoJFkk zfJBOWFMhgQBdJnCoFAcD8DNgVTlh8MkkBCAzIFS5QDLYYYODIpgkgAHQG2VR7JIOk4STAL2yw4s ykMhwWAKUCB08MeA/QJkV3WGEKYMXTunIgvbK/qgOllReLG89FWuGJMhoggwECcBBjyeCQfLbxga rKggp6RTlKobp7tXvksFcgrg+zZaKBIcV9TKMOHbEBxo2DYSDg0Isg0uNMqFHOpPDfKjBwfhBAB+ tpMTzelI8QkMDvLBSQOSbA8KLWJL9aYFhwb70jGmwbSQYBqZTgWvkANk2XE4WmJ13IeCIVH9gsBe MfamxoC0GB8OD2wCtPA4LfB9O2hqAprfTCD+4N8yNj6Ahx3nQSNs7ewdvzaH/4fmAAO6fvWcgdUQ nAFuW0A/CsaAQiGXSyz3CCysL6AUieZuuUv2mqcrV6VwiD/Y6yp+xMOFj+oVtJFJXFwfNSB1R4J8 fP5zsaCCaMsNVzXckeRqvHTys1gDustsYslGUpvxe2ojtTDQeTRo+IKibeh9n731Mk/ICckQ2ff+ rgd3WKbW9z/UfnL3V+A06XP07rwE1YuyfvRHHyN/Ih/KzYpR6fR7I37t18ve7/SIBvtho9OxNZ1r LsYfmFl4PZtu0ZSqf6yFM1Ny+mrY8GdvjPLpTdPGTrrSTj5G9QlndaqnIccG+eZZF9asbyirqH4i dgmYgMlhBOZ3u60ZqDpduCs+E27Dl+8lXtd04kr69jORSeH5ezpsxoQadAkwOJgZxQwoHzgj3AAa nEspBQQvgOLgAtWNRHLC4YAU28mPEEUI9zk8XzclbYU0FJK8eaW5jqKWjswFZNhhOcRaQDRO+K7g 67YH9aKu0FYddU1R0Us2eSgZwJndQAZhB9gC1kxLJiHJzJ9OD9msoeFN26Me+HXV1L2DAzVCdlPZ Xo0QWrBPmDc9VANcVFB4oOxAxXkCulhNHBYP4AB1sBGw/esYoVAEEbABrL7aACzJ4LdbRERE/OgW FNp/7Zv+hzSDs5WiUjI7fqNZMfqgl0RkwY7bi2Mit8oi0ffFSBt4eCEmhrprDj/3EU/QjrW41Dka fZjVYVcx0PSOILAk1nPosMB9GxHmhOByz4lOn874Rc2y5sjM4ZjHgYf2PpEkD7YTfS6GGs7tU9L6 6GhIML3BHx9CunkCWmTddF0FHrEvaKHL/IjYBlwpckj0SOOkFVVkp+Zcf2yWHsFMqrrt6J3ZZOm3 S+m8p+04ud8pZgTVZYlDP3nGj1T3HE6N3e6R4NlwLcb8JaFmyVU1PfbQc3MZh+z2Zi9Wwx3P0Vaq +970ihRnjNpmYuZiPkdq1ZFP/ge2XI4yydxk+aHLYywkxSTsNmNb2rqGbWQQTpdBOBV9gROKDDtu sgJRmT8yKeJvyXvZFaGBib72e9yJGkjBkujkwJBVRMIBm/B4vLa27hciaX0zgfi6/wsiKQEKX0zp IFNqiD+FhtlKMsOYkYibzbXxoMp0dHSwusY6G3EKgNyXTyT5w09EotDCqd6UPyXYibHjBFunn92z 454SefSv55g2Ww/t8hPUgNrydt831xAw6uMpsXcUSuYxjcYajlsE+d5JfwVvCxqLqgiQy+/wKuwI KDEcKTZd9iKw6i9vne83upnodOA1s0zNVC7fUQavPbOU53w6xTtiH1CI0kykrWuzamlX6Hi2U1D9 Tu2xyVRTCwKyIRrD83L6/c3LM3XdHbqpC7Jn9VGBiWJdbSNJ8BuaBxsUbrVvL7jV3OOlYEtSECan LqwbGJsl/BJn9kqbJLcxoq22N1d1040w7TW98Tay+uHA7Qu1lFBlC6Xunx/UJhCaIi8/psP7nlqL z5L6InuSZsnJipr1hF+YTskiqmphXwnGDc4IchWsNF6bt/g/DLK7gOnqO0ycJIxb3Jz6HazktD79 6mgegnpntBC+UKda26xdtwZw+gIrEFUAiCqmWZLp/wSrL2H2Kq4sIqjKFVS5rkIVCCrAYhWq9P4a qn7YM/1HxOb6Eb1Cl/ern+pISVaN2T/kIbL3jb/XBNdPps633K2w/t1zFoLp04IFiWNCj5yYYRW6 LLfYsPFfPmh1O5UMdrXH5JzLDANyOKUQJLWNsbGTRtK8+XGDQijMZtwNzjC/gXmtgrHkBRfJl65e mDQzjZ1mFS3H62JogQJKt627g4vKheoCteX85tWeKWAv7TwvjRwx3WBQgAyPmFToQxLEA/ssE1k9 VtZc5rLa5WEbbS7WcZ3tv6j66zWVgMV+bbF2Q947vRydxCx5bwyPuny1p+lWoWj3Xp1nJWZ16ZuF XPYPEX7xfdhZYO48Y8N5foD37OOPj/WKBhoefZI8gNgmsHvtTHqHQ1k2mEbIKyC9Sr7SS1NRYoVe uD/Sy3MFCyjuDMXDmVNqPlBxUTi4FjhxQOx3Tu5vS4XDAqpf8lj+ex47BgeDkADXjupL9SbTKRjj MLp/MI1Kj1qhFADoauLweNwmTTxIKfxvJp5t/pMl3Z+h5gLNzV0c8LkulbcLgzE5GU7aY7DuSXD7 3cm3u5dyRAUG+jfTD0pc1GDix5b7fjYhyj2mQZ5pu6AOt1VjLGcm/CttrVNKr0ZZ780ncPYsKvSf CkvuPBu6NfZp/LPpq1MbS1rdzZ7XVOkPbPDPkSgrpYU6T4plDS9qZ9GYT8I9pSPMDibqinaF7kBe 9nNMKb1A1egR51nKoCsPhms49QoDbp8epHgt3m31NMfZX1JCDxsBnTRlgQ3r7+gQ9Zl4/bQOli5H ojvRmbFBBYm/aP3UznvkAdZr0kx/pJIL8tGcVXh/xzFF0uvos1ZT5p06erqF9RHupWKFKXcFU531 blZye8IffkWNBzgj24E17NRDs7/iBwnAwbdV7PlhHcR+SkitQSBABSYBQhzcv20fRNj/SpndMfg4 +OaDsXtZvI8jPlQ8kv0id9eWclzwGb0r3VhA/FsjYRiCVxoFIUHCwC2HKcT4d3Djr2TsMnJWynmp gP6s8gJFynYbLgHsv8DNEiAAZkxTpnGS4V+H27cwDZQ2m0orYHNaBTYLwBzYugpsuv8L2NgJY/ql 13+vvmBQiNsmg1hF85rRYKPz+IaAUX6NoHLL2VHPsHc2W7BPTat4lu6+weKK5dpj7HPjZHdW6mvY XC4qdy4YCmlqrP8U1WBJmzV4axzb9oJXjHq3tACDneexv+XcgR2yenAlZKScrwhe6jzQeMTaZSrb pGBy+v34UJKMll6jc94ESS5RpYQhmTmYxSk1NUj8dIzV9hpdmk5sWfcglZatsjcwX+KT5ATpiV/7 +mV3qY6iY1eVLkR5O28tcuiYe1Ps6tybDzPbquE501P9iIEP+lySjR4epY5UFKlda1EV4KccP/ns Q9G8kCI3RTdrMlrGqun+C+fXXZEn1rq3aot69mZKWR7HXqvS2io5LiAiAdnZq71D9l7uHe7xRP5j doH8aKJ+jLJFAe3+9J62m2MhxS4ZLvuzUpjrLODbZzuL/VD00o3vsBpiLa9oOkIzwef1/BhzjhdS NEUp0vxHegX6fGaC75k/eij2JuoWov7hglq/zJHCStQCWsmoanjuRUWseRPnLgJllxGx1mSM+K4u PKobpcUdKBmHkxnkd+p9yVp4SRCo8sldthdVj7mOlI0ezDZWojZnpma3pnTny1bzuRdMFFUn+R/k DcA2he+GSJ2omhLd91H0oPyl5M6AcgJOI+/50F79p5ADXoT795JbG9fO89NSbhbr18CMApap+ScG BcoF6nXsuZ406wMMDk6Q3++/8lvUX2uF35L/BL8BHbCsBImtrbmy78XjVkz27hfc9/5j5e+f0fs0 a8/5/mcWGSoxu9XFX1wdHLp90kHOvupe71qi/Jrx+2X3baroAEZwlPOxU7aIZdY6k4zqXHdAsQey +/W+q2OHOdfM8iNyJw63y9zVlD90amrGT1Lt876RZKm3I8Ri1k05UlvKvFknd5dHTVetCaJo7sye TL+nG56bk2qTul5uMFdXqkyy2+bIOwxXWwhISwOCDk27AafmDzzJqXstm3Pg0wP0NNdFUqBjvVna aQuIFcFXUEnZtzxn+CFHvFXRXEKZIEGYm3E64d22yCVonpQ9VyJEADB/d7FPzrzpFtbpdI10pDEu oj2/f8vBTBYZ1iDFd/7zbP4F6L311k7Lc8jmnzE8X+l9DpyRsv9G7x8Whr+jt8BqeoMeCBCf+wW+ 8WlAfMqP8cvyLiH/7fJkCERVibKsmKVVNqGuM5xodcr/G+r/pVIWnGuBnCPN7vCtG3vf1FdFPLsX 5WALPa9O37sjkBd97t61famN6o+Eio4FejW6wO4SMWj7k73RRoMuTTWueZIvpKBJlU2RU0e7xrZA xwevpaKQLSkWgxMkkV67cxnDIykBj+Nuvsqa4tBIhL9JV5FfH7Lw8fNw5El1vlnOwZAra4mnju9G 0bIbWZsK/LC3HfjferkbiuYexRgOckrg59pxVuE4fVUaT8vbEP3lRBS6/2cU+fjE00axUeLR2Nva qh7F10ev7Ocx2feIRJMdB9qaIinuO6BiKGH+Bz3CuR/0Lvm61mE1RuYSk9odnF+fCsnaU7nJ5tHH qOtn10Z7Kb8vylfW4oiQ8GrVlw6UYUzw3FFr6jStezk3tr9hqKScrt1IvL1XTkgxnEfP8dje7eam wlfq6mpt/VpOmyzHRcnGFYoAvq9NhDwkWgrXy3aZvlF90zRj0a72qBsfZ6OoYiHvuf2t8/szfSdP tW0OvhqvROcQHA+XvZ7PuKnk9NP5AP3DrHByfRALfeb6WcKEUPDiEfyeC0v9Di3H5Fp9r56SOiTk A9PH1rilNg7LvmyobfOuj3RCPjJWt6/Mqi2NPFfHPBEm8WvGIXTYeg18OVcQc8cxhevM9wltsk9G pe1a88YtB2ahlODDPPtbqC2vgt6W5dzDKS/z397h3m27jtU9r1FoqL5NdHcrungRx0AUAQxEIQwK BcB0++fq5R+f0H4/6GXG32KXa7/plxuO4119igwO4LvFg+MHVkdF2MXg1wsROBBK+bKek4OPUDu5 X6puGioiSPevV1IDfFZdwotzBpyYKnEbILYQKsQbQoMErxxE+0LoEAzECRIFCQEtP9BPBn/zh0Sx FOPk/2Oy0qNCgv1o5BD/KMwfHioIBhRy8VLHMX8haU/hJbswjXczs9Bs9IGUoW456T0R7ymz4j6G fTmild6HqL9Gbm2r7bdIE+k/VJ4xFKm4nyjkzffkhidcb/cHwzObXPTyLvUor+3b/eJaZeV8qOlr CHfpON8rfjhy9JpGrhHav3LZii/mxk8DE2lXvUg7+8aOmphiCNtIlEyvMpd+SMJ5vrH9iTMKt3ZM Bdm79bvOyMWe9WAdcrO+VqOIU3FERSvJivZf3heS8MkKP+XjQSP+pNV5RFR9uBdvsNNk8oW6nq66 xqgD6kBN2bnAl8rJHjMJMMtHsV64xpijhpJW2g6PE0I+mkfm2L4wHZi23AeZ9vAVzuspxaqnsFgM mAzAgK37vkYcOAaMF3Rxragy8R+rAn53MLdKijuBtauVyPP9jx5Q8J7fIkjcGvYhGg4H6ILb0404 ne3/JsSl8pBk3aW0qbCxlEPA24mwjom5G3/ANFsiqfH811vT+D9QjI0Jlp0FivtPRl1/yuI9bp4Y oPrAoEKoz4p/wlA1QG3q2T3xtySB7oyBtUHb6k8mh72fuv4eln4/dh2WcjbQRHODq8PHWznn1fRq PBMUPIvll846CCInt0xcqMjwuFKT4e1mhLE2N+OXG9KmF91wl+A1xMKFrEebFbWarYR7ySN2d7e5 5YYRqM8JU8q56eGRiFOelWMzxTzRcT0tzhUK0w5ZpTUHycjtaSSjOd5JeTJ1zZOP8pDiD2FvxcM2 ceIMruodnOCT+rC4FTsrq7TvfHrkGS2Fa49doWYjRQae5JpFZEDFvIpv5bz4OiuodNBT/i7K5pSQ 6LwBHQjkX2RCmPkNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMzkgMCBvYmoNCjw8L1R5cGUvTWV0YWRh dGEvU3VidHlwZS9YTUwvTGVuZ3RoIDE0NjM+Pg0Kc3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7 vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRv YmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS03MDEiPgo8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6 Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgo8cmRmOkRlc2NyaXB0aW9u IHJkZjphYm91dD0iIiAgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4K PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiICB4bWxuczp4 bXBSaWdodHM9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9yaWdodHMvIj4KPHhtcFJpZ2h0 czpNYXJrZWQ+VHJ1ZTwveG1wUmlnaHRzOk1hcmtlZD48L3JkZjpEZXNjcmlwdGlvbj4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8L3JkZjpSREY+PC94OnhtcG1ldGE+ PD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDQplbmRvYmoNCjE0MCAwIG9iag0KWyAwWyA3 NzhdICAzWyAyNTBdICAxMVsgMzMzIDMzM10gIDE3WyAyNTAgMjc4IDUwMCA1MDAgNTAwXSAgMjRb IDUwMF0gIDI4WyA1MDAgMzMzXSAgMzZbIDcyMl0gIDM4WyA3MjIgNzIyIDY2NyA2MTEgNzc4XSAg NDRbIDM4OV0gIDQ3WyA2NjcgOTQ0IDcyMiA3NzhdICA1MlsgNzc4IDcyMiA1NTYgNjY3IDcyMl0g IDYxWyA2NjddICA2OFsgNTAwXSAgNzBbIDQ0NCA1NTYgNDQ0IDMzMyA1MDAgNTU2IDI3OF0gIDc5 WyAyNzggODMzIDU1NiA1MDAgNTU2XSAgODVbIDQ0NCAzODkgMzMzIDU1NiA1MDBdICA5MlsgNTAw XSAgMTc3WyA1MDBdIF0gDQplbmRvYmoNCjE0MSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAyNj4+DQpzdHJlYW0NCnicE5Co6eF++b6F++f3Ewxw4ABnAQCh5gabDQplbmRzdHJl YW0NCmVuZG9iag0KMTQyIDAgb2JqDQpbIDI1MCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDAg MCAyNTAgMjc4IDUwMCA1MDAgNTAwIDAgMCA1MDAgMCAwIDAgNTAwIDMzMyAwIDAgMCAwIDAgMCA3 MjIgMCA3MjIgNzIyIDY2NyA2MTEgNzc4IDAgMzg5IDAgMCA2NjcgOTQ0IDcyMiA3NzggMCA3Nzgg NzIyIDU1NiA2NjcgNzIyIDAgMCAwIDAgNjY3IDAgMCAwIDAgMCAwIDUwMCAwIDQ0NCA1NTYgNDQ0 IDMzMyA1MDAgNTU2IDI3OCAwIDAgMjc4IDgzMyA1NTYgNTAwIDU1NiAwIDQ0NCAzODkgMzMzIDU1 NiA1MDAgMCAwIDUwMF0gDQplbmRvYmoNCjE0MyAwIG9iag0KWyAyNTAgMCAwIDAgMCAwIDAgMCAz MzMgMzMzIDAgNTY0IDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgMjc4IDAgMCAwIDAgMCA5MjEgNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIy IDAgMzMzIDM4OSAwIDYxMSA4ODkgNzIyIDcyMiA1NTYgNzIyIDY2NyA1NTYgNjExIDcyMiAwIDk0 NCAwIDcyMiAwIDAgMCAwIDAgNTAwIDAgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAy NzggMjc4IDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcy MiAwIDUwMCA0NDRdIA0KZW5kb2JqDQoxNDQgMCBvYmoNCjw8L01ldGFkYXRhIDE0NSAwIFIvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4NTc1Ny9MZW5ndGgxIDE3NDE4OD4+DQpzdHJlYW0NCnic 7H0JfFRFtv6pqttLlk46IXuA7k6nyU5C2EMknZUlAQIJkCCQhBAIKBAM4IYSFxSDCCqD6DiAC4ui 0ukIBnAkOm6ACggCLgNBgojKiIqoA+S+71YCyjze/83Mmxl/858+N+er5ZyqOlW37nfvbeiEGBGF AhSqySkaMijo5O69xJe0EkUsGpSTm6cM1VcQu2EREW8ZVDiiaOHpZw4Tm1tN1LJmUNHorF5vnLmW +BgjUd9tQ4uK82bET9Oj/evotWtBcdHgEXduKiO65m4i/74jipJTO40tupWI/Qh7eWF2QXHp/juO o/9ClPuMyRlWMtxefSdRwctEAcsrZ1TU9N87MJZoIuz8ocp5c6zcdrIv0bwmIkPLlJqpM2qHro9E V4hXP31qRW0NhZEX+nOiP/PU62+eUpc7L5Po9pVEb2+rrqqY/OnjW80Yf742XjUqOg0LuQXlF1GO rp4x56YJLZFnMFYJ0YD466pumHl++0U9sSrEw5XrZ1VWzHnhmYvEBhVjetUzKm6qCT5ono32h9He OrNiRtWSXm+lEpvaTOQ9oWZW7Rw1miYjHqtmr7mhqiZyc8YPRFMxH/9q0tZev2d8bvNvvirzT//e GI5lhDx5vMtrWvrO5jtCz8+5eL95onEkil7SXxOkBltbLo010/k5P71vnnjZ0iF+k7Qa/560mAQV QDmZKZnGYLheGJfDKkRvtox0ZNQ9puuJLh3tqVhDU3gg03GuFzpFx4XSQvFqM92ULSOAFA/LtpKT rOe57v62PNbTYGPbncRUVUXr5boCbaYUpO/POmve/JI+S60ihxbSVQS2Ymh3La/cRQ74z0S5COmD vD8JhWgo9Aw0EVoEtUInQUugBdD50JHwdV2tf8NEqtC9RWbdGIqCDkXerhyneKWWbMgP7oihp+hC 8TKG4xRn6ALft9QTmh1+UVqKtnbk62AfiLKP7HsJRWopyp2uNrZC6tdaKpbQEOTPI81DrDlICzDm COSvgZoQezrvr1YiH4D8Nfr+FIC8LzQX7X7S2sDfhBgnwx6kaBsSvhjX1D4O+aLPuKvF4JF/rrAx bRt/WcYeCYeG/qPH0fbIf6t7lk79o8fxiEc84hGPeMQj/5nCNqjbfu0Y/lrRRf77xOoRj3jEI7+m MFK3GaFm8vCmRzziEY94xCMe8YhHPOIRj3jEIx7xiEc84hGPeMQjHvGIR/75ov0/2F87Bo94xCMe 8YhHPOKRfzcRxyiLf0wzxWuUJe6gVPE+RYt66qV9Z0qcpGxxiKZr35lS+tNU/ioVat+tEk00XPtu FdrK71ahHPWL71alKx9QnP4t6AaKU6aQXb8OaRR5i10UogyiIcrTFCGWU29RhnKjLIfxYIrhS6mz ModixD6K0UWgz6epk1JHQ8QG8lauoRilK4XwszQMMSUrd5NR8SNvfRFFaPNQAqVP3195Of8loq3V rx2DR/71wsdQKPRmaCC0L9QXOgBqg9o76mx/rZ/Wp9FAA3/teXnkrxX/ngbG2NRqWdDryRg6wXhN 18sySNb3zB3s5wybNIiqqqgqzOksdSb0H+WkA+SUZiOlTswYnN86uXiAe9Kg74onTpyYHNWzuGI8 vVX1Tw1e++5x1VWHGKDBP3dwj/x7CvvfXf4OV4/8LwKW+bVD8IhHPOIRj3jkfxTPXcoj/1Bh0Xj0 YV1ZO8qj64Bwh2JRLKgJYnGsB0sKlXY7Y1Y8Jv0fnpR6/AMD/9uFXUX+f72gBAk5P50QjGOaYbqv fJrpR6OK12Gj2kZe5A30luhDPupF8iVfoEmiH5mA/sALZCZ/YIDEQDIDOwHPUxAFAIMpEBhCQcBQ 4J8pjIKB4RQKjJAYSWHqT9SZIoBdJHalSKCFOgOtwB/JRl2AUWQB2skKjAb+QA6yAbtRFDBGYixF q+cojhzAeOoGTKAYYCLFqt9TEsUBu1M8MFliCiWoZ7HzEoGplATsKbEXJavfUW9KAfaR2Jd6APtR qvot9aeewDTqDRwgMZ36AK8BfkMDqS8wg/oBnZQGzASeoSwaAMymdGAOXQPMBX5NeZQBHERO4GCJ QyhT/RMNpSxgPmUDCygHOIxy1dM0nPKAI2gQsFDiSBqsfkWjaCiwSGIx5QNHU4H6JY2hYcCxEkto BLCUCoHjaKT6BV0rcTyNAk6gIuBEKlZPURmNBpbTGGAFjQVOAn5OlVQCnEzjgFV0LXAK8CRNpfHA apoAnCZxOpWpn9F1VA68niqAMyTOpEnqCZpFlcAamgycTVXAG2iK2kq1NBU4R+JcqgbOo2nAG+k6 9TjdJPFmuh54C80A3koz1U9pvsTbqAZ4O80GLgAeozq6AXgH1QLvpDnAu2iu2kJ30zzgQroReA/d BLwXeJQW0c3A++hWYL3ExTRfPUL3023AJXQ78AGJS6lO/SMtozuAD9KdwIckPkx3AZfT3eon9Bta CFxB9wAfoXvRaiUtgvVRiY/RfcDf0mLg43Q/fH4ncRUtAa6mB4BrgB/TE7QM+CQ9CHyKHgI+DfyI 1tLDwHW0HLieVgA3AD+kZ+gR4LO0EriRHkX9cxKfp9+i5gV6HLhJoot+B2ygVephctNqYCOtAb5I TwA305PqIdpCTwFfkthETwO30jr1IG2TuJ3WA1+mDcDf0zPqB/SKxB20EdhMzwFfpefVA/SaxD/Q C8DXyQV8A7if3qQG4FvUCHybXgTulLiLNqvv027aAnyHXgK+S03A92iruo/20DbgXon7aDvwfXpZ 3Uv76RXgAYmIAniQmtU9dIheBR6W+CH9AfgRva6+Rx9L/ITeAP6R3gQeobfUd+kovQ1soZ3AY7QL +CntVt+h4xJb6R3gCXoP+JnEk7RH3U2f017gKdoH/ELil7Rf3UVf0QHgafoA+CeJX9NB4Bk6BPyG DgO/pQ+B39FH6k46Sx8Dv5d4jj4B/kBH1LfpRzoK/Enin6kFeJ6OqW/RBYkX6TiwjVqBKp1Q3/Rw +n84p38pOf1LyelfSE7/QnL6F5LTv5Ccfkpy+inJ6ackp5+SnH5KcvopyemnJKefkpz+ueT0zyWn fy45/XPJ6Sclp5+UnH5ScvpJyemfSU7/THL6Z5LTP5Oc/pnk9BOS009ITj8hOf2E5PRWyemtktNb Jae3Sk4/Ljn9uOT045LTj0tO/1Ry+qeS0z+VnP6p5PRjktOPSU4/Jjn9mOT0FsnpLZLTWySnt0hO Pyo5/ajk9KOS049KTj8qOf2I5PQjktOP/IqcvrKD0z/8uzj9sOT0w5LTD0tOPyw5/bDk9MOS0w9L Tj8kOf2Q5PRDktMPSU4/JDn9oOT0g5LTD0pOPyg5/QPJ6Qckpx+QnH5AcvoByen7Jafvl5y+X3L6 fsnp70tOf19y+vuS09+XnL5Pcvo+yen7JKe/Lzl9n+T0fZLT90lO3yc5fa/k9L2S0/dKTt8rOX2P 5PQ9ktP3SE7fIzn9Pcnp70lOf09y+nuS09+TnP6u5PR3Jae/Kzn9HcnpuyWn75acvlty+m7J6bsl p++WnL5bcvo7ktN3S07fLTl9t+T03ZLTd0lO3yU5fZfk9F2S03dKTt8pOX2n5PSdktPf/g/i9AQP p3s4/T+G0x/9P3H6oX8Sp2/ycPq/gNO1z2TatXPHh04HUEKOfUQKziaBJa3IeYNd48Bog8A6o8EV pbj+b8QVtoaeZz14X/6h3mnNiQo+z7XfK44WseBVJ3iqoMO3AtfkX/pqv4T8+FWPShxPGw+3sQuu lhuPrNO98rd9IMb0P38kzThv/5XmVzhgyopOZn18yc/fHBDYKSg4JDQsPCKycxdZb492dIuJjYun xCRKTumR2rNX7z59+2EF2n+ncxbl5OYNGjxkaH7BsOEjCkeOKioePWZsSek4Gj/h7/po7H8W8Rfl 7dAdzVd1/UCDj9rz/7Znz5k1utiZMfCa9AFp/fv17dO7V8/UHinJ3ZMSE+LjYmO6OaLtUTarpWuX zpER4WGhIUGdAgPM/n4mXx9vL6NBr1MEZ5SYa88rt7q6lbuUbvbBg5O0sr0CFRW/qCh3WVGVd6WP y1ou3axXejrhOeUvPJ3tns7LnsxsTaf0pERrrt3qejfHbm1i40aWIL8kx15qdZ2W+WEyv0zmTcjb bGhgzQ2rzrG6WLk115U3r7o+tzwH3TX4eGfbs6u8kxKpwdsHWR/kXKH2mgYWOpDJDA/NTWvgZDQh KFeEPSfXFW7P0SJwCUduxWRX4ciS3JxIm600KdHFsivtk1xkz3L5J0gXypbDuPTZLoMcxjpNmw0t tjYkNtff32SmSeUJvpPtkyvGl7hERak2RkACxs1xhd7SGvZzEZ0HZpfc+0trpKjPDZtm1Yr19fda XWtGlvzSatOwtBR9uLgjr7w+DwPfjyXML7JiLL6wtMTFFmJAqzYPbU7ts6uy52o15dOtLi97lr26 fno5TkxEvYtG3WxzR0Q4t+LOG5FrrS8usdtcGZH20oqczg1BVD/q5sZwpzX8SktSYoM5oH1ZG/z8 OzK+pl9mqi7bZE66a7n8UZfXlWkR2YdgO7islVZEUmLHnPppUNWP6iv7wQ1SytDKNRnnY5rLK7u8 3pyGerPW3qVzmO3W+u8J599++qsrayo6avQO8/ekZbVdcnmjwX4p70pIcMXHaxvEkI0zihgHynLv pMR5TdxlrzFbkWD5qBBrW1GalozFt9m007u4yUmTUHDVjSxpL1tpUqSbnMkJpS5erlmaL1mCR2uW ukuWy83L7djHL8orPdhl7Hb5x98c0im3Os3FQv4f5qp2e36RPX/kuBJrbn15x9rmF19Rarf3u2zr yLF2AxbcpTiwUkPs2HqjxpVoFfjROfLsudPKB+NSQ4yuTtklIpKXtud4pJBdYf+Ov9yzVijx1fpS HHq5/yc3GYzYwLKGWfNc5vLB7VjqbbP9lY2a1DNaK5n83KxjTq60hCvLA64oXxGeb71AwEo3nl88 rr7e+wpbHsiqvj7Pbs2rL6+vaFLrJtmtZnv9VlEiSuprcssvnf4mddviSFfe/aWYRDVLw9bmlNVg Z4tGNjjZoqJxJdrfXbEuKi5xc8azy7NKG6JhK9lqBT/LWq7VapVawaoVKJ/hqnBzo/SP3OokqpNW RVbIcmUTI1lnvFTHqLKJt9eZ2wfqJgdy4qZd2aS0W5yXvBXUGdvr6tq9Yzu8jbCYNcs2Av+TNLaL RjHZxSW/3DzyiixNIsr0pmLxNX8eb5YW8SdxGnd3izjt1nexNImvGkW8JSMzWLRSuThFq8UJOgpV yIwaM3IZ0BrkVahObRbHGnNzU51NSBO6y9QdG5e6VTO4Izqn/l4c48/hLdSCiqPukEhpOeLOyurI 9OnXnmmMT0o9muktjtDXUC6OiKO4H8tWjbHdU89kmlDBxO3kzxhegteIP5ILyskpPmqM7pa6eod4 B/ZdYidewrRmO92mgFR0+JZ4Ca/gFrFFbO6wbG70C0ilzFqxBKehGbgX2gI9A1VollhPC6BLoZug CvkDLdBk6AitRmwUGxHnWrT3ByZDZ0GXQhWs7LOov05DsUFM197Pxf1iOd76LWKxeFimTyONQPok 6rsifQJlLV3dUf4tUs3+WEf9oyiHIF3ZkT6C+kikK1DW0t90lOeJubLdnI50jah1d7WYM7vCboWm QAVyy5FbjqVbrj1mAZm4S1wvR2pAmop0RnuK5brNbbPLc3RbY2h46hos6W1Y+tuwcrdh5W4jBab5 l3zmt/skifnwmQ+f+fCZj1VJEbUYr1Z7JgWaoVaowLrXYt21ehewGbpX1t8NXAZdo5XEjVjHOER1 n5jujrVgk01t7O9MzdgupmCpnWJKY3iX1KU/l7y8tY2I1K8j9dd8q6S1qtHLV6utaozo0p7C67pM P1FJt0I5BQGjob2gOVBFVLqjky3bxHCaYSSnn2UBXyAWKAt0SkoOC9whUqnQSNiSgSKJ0uEQZylL Z33LvWq86ryE2cvqleLl9Cr00s0SC8RSISwiWWSIEaJM6JrUZrchrScS5yB9Ws9lPmt8XD7NPnt9 dC59s36vvkV/Rq+z6lP0Tn2hvlxfo6/TL9Ov0Xst0y8z8HKfGp86H2H2sfqk+Dh9Cn10FgNbk7lQ yL+qBDRDa6DLoArWuAz1VjERWoazUYalmKj9QR4goWSG7kW+BakOJX/4+cPPH7X+qPVHLQE1SyG0 HFrTYdVftlxqo/mf0SzQGFj9UOuHtW0BntFy0KEomVAyoWSC115+ARGagVZoIVTIuhao9jJz4bIt pcNeDtVL+xnpc8nm1NryC86KmOY45opja+LYsjjmTM/ITHVGAQIDA8vsZY6y2LK1yiz7LMes2Flr lRH2EY4RsSPWKhn2DEdGbMZaJdme7EiOTV6rWOwWhyXWslZZWrCpYEfBngKlrGBWwYIC0RenrtGd kJIq0yiHlm52h0ek9vXPHMA3YTplwNXQo1BBFmAyNAM6C6rwTUALiDgZmgEdAS2D6tDieY1egJYO m1a/Wtq0nGbnV9gFJv6cO63niMxhoNwy6GqoQN/Pwf6c9G7PbZL1LmCLrB/R4b9G1luAl9oI2Uaj uXEdaIFmQMugNVAd7RFjcYsYq/UPtEBroJugihiHY6wYy5/H8Rx/TiQ6TT2CLRQSgieiwACjOdPM fbETTGyDxJUS75OYITHa6TfUdG6o6ZWhpnuGmmKQ4bGUCcNyiTanT6bpxUzTiExTXKYJvYWSjUw8 WKJeQ/alxOESE51BNtNPNtN3NtM3NtPvbKbZNtM1Nq1dZ1zBJh4k0UdDtkLiUIndnD4W05sW01iL qa/FlGliqxhGpyyJXSVGasi+fdE/x5+8trNvKQc9MXd6nAU3epkw1Z2eiaTNnT4IyUV3+iokf3an P2x5mf3E5I2NnXNHt1oyg9lZNkTRyt91pN+wIbQR6RmkU5Guo3TmQPq0O/0Ozf8ptH8M5Scpyqj5 P0GFst1qNkTW/66j3ePuxEkY9bfuxJsx6mOUKEd9xJ3YitqH3Yn3IXnInXg9kqVuhxbgdHd6vCUz gE2laK75VpKDa5EUdIw4GD1fj3RQe+Ncd6LWKkcboIllu+09kMRoUb7M7FQoh7O47XKSXcguu+hM dhl0JDlk6sf8ZfAmipKp0W2/A73oX3S0Wn5I365NnL5n/u5VluMvY35jUPyUDXFvtOzbqi2X27In sYk5tljes2+3vBHdxMa4Lc2JTUYYdiQ2cbbZ0oBFdsGXsy2WTYlTLc/bpXWtHVac6tXpSZbf2sdZ HnWg7LbckfiyFgbNwIzHwFyaONBSkL7RkudoYjA70zGY09uSZr/B0h/V/ZrYkMaNlh7RTVooKehj 4xZLPEbsZpehjO67jfcmA5vrTDTMMUwyjDGMNAww9DQkGayGLobOhiBjoNFs9DP6Gr2NRqPeqBi5 kYxBTWqLM0H7ECdIb9YSvaKhIvNmrqH2eY/2EMiMHNeOq5PI5/lFWcwVmE/5xVmuvgn5TQZ1lKtf Qr7LWHhtSQNjD5Si5OKL8HxaXIINqlUtjNTearcSY8kLl0Rq6fyFS0pLWb6ruZLyJ1ld54owD288 nevsWWEUMi8jLCNwYED/vJyrQHkHJvwsYQm/lLAurhX5RSWuZ7uUulK1jNqlNN81SHsf3spn81m5 OVt5jZaUlmxlt/DZuaO0enZLTullN4riNXCjdC3R3BopSnOjKNYo3QqkG7ZpVG5OQ1RUu9NrbIjm hO3zmnSa2t5XNIZAX4VaAjfelaJlX9G8q+aG/dDemf8vO/Ml5i878/cl2VlnzanB4YBLokNzaejr gEODo680b/zZbHe0h1NKDjmOg5XKcRj72Se23Qe7oMOHG+GT8I+Uqqy/wZk1VnwyuVL7VKLcnlsF LXctnlcd5qqbZLU2TP6k4+OKbuWTKqu1tKLK9Ym9Ksc12Z5jbaiovIq5UjNX2HMaqDK3uKSh0lmV 465wVuTaK3JKG9ctyM6/Yqz7Lo+VveAqnS3QOsvWxlqXfxVzvmZep42Vr42Vr421zrlOjpU/Kovl F5Y0GCmrFK+1Mm3kPt64HsojbaVZIeaagfLiGGALuz1ym0K4bfkklLp87VkuE1QzJWUmZWomXJ2a yU/73KnDFHb7AFvkNrahw2RGdYA9ixIoLHdazuWf2traObUazJ2bAJwzN0xWzsFVayvKd+Vpr8np rvRcl7M8p5Rp52Nuh2SXOM070vek81npC9KXpq9O35Sumzu3FNWBO6L2RPGyqFlRC6KWRq2O2hSl 1wzjS7Y401dHfR0l5mI7sTmQ3Bw55lyk+NGKc+Zq0dQSBqiFtg+XMDchuyQziirx0Kv9mc4k6gS1 Q3tCi6A6+gNwP/Q49DuoQncBH4Y+BW3UakSSSMoNm5ajjViaoLFOmEhtTOmd2q8JacWU9rRoXHua O7w9Tc9MDUPqzujpnemP529G24C7oB9Bv4D+GaoTqSJVdj63fduW1lJtAkP4hMIcDWoT5rAEZJi2 3HNqExJIU22H4xTANYFdufGJ1c4lLAVOCBI4ydpardlcLb0kMGi9JOgeINIVkAXaWb6pkXoM2gr9 vG2oekF3HdnbpqstQvurnM93KJGDVtBqiqYzrAe9Rs3g8nV42Cmk5TSI9tAm8qOb2W4spx3PGBvA GBYwfx6FMh09Sh/SeLqBTlAL3p7z6QgLRD+5VIO3xv7qKWA+LVK3wsubsukF2sauZ0WUjPxgnoil cNBStZlCKVZ9Vz2M0u/oBItWG2gwcp9RAJ7SF9CDeJ2eTrvUC4g0mibRejafncLTVTktVnop9ep1 NIA20wcsH7lhdLPusNdmPB88SE+xUNasHlVP0iu4m1ahpztpESJ2UzPvLrJ1a8hK3egaGk4VsN5K H7JOrIdwqjFqlvooatfTtzyBvykMiCOBhlAZLaEnsBoHqRUPAz6sN55xNuLYx/6k0/7SbT7NpVuo DpGvQ9vnaCvrwXrwUDwhcswwjkbDtpTWYvxG2svyWSlrZq+KtbqUtgw1SA1WT6oqxVMJIlxNr2KM sywFPhhBRIk5Sldlji714h2Y4WR6nPbSPsRxBOv+Pf3I4nEc47fzBepYdYN6grSvvVqoH42kcTSL 5tGN9CTO6mv0On3DznMveO5R3tDdojujPoS17UZZiH0EvIvQ92KcJTc14TiIWQYwK2bRjw1no9hU tpStYE3sQ/Yh13MbbpZfCJfYLT5R+uh0ahp6CtHe6LFLxlI1zsDtWO2HMN8N9AbtZMGsG0vCjA6i /Tk+gOfgeIrv4UfEQrFUuaC7p62l7cu282o9GbDLBmEd5tKzWIWvWQhiiGPTWS07jsiX8ReFnzAL u+gtMkWxKBWLxHLxtnhPuUHZqHykG6Kr0G00VLTNbNun5qt3yycUPeKKoUTqRX2xf6ZgN12H+Gpw 3EDz6Q6qpwewXx6iNXjibaIdtJM+oD/SVzgDxGyIeRpGn4Fdt5A9gONR9hx7lb3BdrJj7Jx28Cgc sbwPz+DZPI9P5QtxLOd7+UH+uegsKvEeXodjldgiPgRPK4qqS8UxWLdYt16/2xBrGGyYZHznwumL 8RdLLx5po7aItmvbVrS92nZSHaPejPgdlETdEem9iPJR7MG1OJ7FTtxCb9I7dEjG+i3jTIcdH8bs 2A2JOGsZbBAeNoawYWwkjtE4xrJxOCrYJFaNYwGrY3eyu9jdbAn7jTxWYm5r2TNsC46X2DYcH7Cj 7DP2BfuWYxNzgd3s4DE8mffHTLP5ID6Cj8Ixlc/CUcNv4PNwhtbzRr6VHxSdhAN0WyFmi0fFC+I1 cUD8pHAlUUlW0pUxylTlLmWPsk85rJzXWXS5umrdKt1r+kh9L/1o/XT9Sv0m/ef6Cwa9oRAPrPMN Bwyq0QG2egvz3nzFP2Ml6/ewWl2QchM/iusiTNTo7mWjsWJ6XiyuFw+I93VT2BlhZR+xejFNXKc+ JfL4j2IWG8N3sChh0aWJKXQ/qWwjP8bP8pNKMCvmp1is8iB7ic8S2Xing+j2K8HKXbrP8ax7iNL4 bayZvyHuEnepv6c03Sp2VLeK7yOr0sI70VFc1ffyR9DoPT6NL6YSpZfuPE3Duj+juwnrPZAvYvHi gLKKTgg7/w7vVyvAGu+yoUo0n8j7s41g3IusK51ms6mG/YacbDv7I2vCU/EGsZ4VcF+cLRc3sb54 8H5X2NgB4U2lWoysGw9mhfwMHy1e1u8VvfHis5fep1uYYCk0//J6tdFMXAHLeQw4LRdssp+lUhg9 Ar4/2/ayxti6w7rF2GdPiEQaRSk0ge+mNFwbJ3CU0D2UStu0/zdBKXwlzVfr2GTw/jDwJye8uVEy 8wFban85fQHuFyE8ClxYhlF/BP/vAuvnsz/RjcyKK6uZYhXNcr+SC2YqB/8uxjGZJqD0OD2k36zb TyNYKJFibVuFXf4JTcQ95zjGj6B0xDeOnlASEbUVzDwbLR5vG0xOHPfQbsbpNsQ8ENd5oTIYzLtC nY4ZTsM9qgD3xJ00TX2EsnHuRql3qYupTH1CHY931SJ1A/h3nuqmPnSvrpSP0SUovcCxO9nruB99 zBaDtwfTR+AjBwujL3C8gPgH6rZTvXII3Jmh3q9+QMFYjyis0CTcRVtpBv0J6zZYNFPPtuG8Qc0T NbhDHaWR6nrVwrypWr0ezPsyrTXowD111FW3Fnt3sTKFpyDeOAphyagdr1stDolvlBq8anXGbuys fTQGnhzWwNl2/gr4zcB3uEmnNPFXXhTkbdAymxmFG/W6HbBzEiyOvNh1bCKFJZjPpV9MH24+mz7s YjplIG++AOiRYguwBTgArLNCF6yi+YJTR+exq5vRvlVtZW/i6cEXe6V6O3+WwslLbXZ69enXi5zO zF5G7TPFoK62Xt4RP/pN7UPO+N691tNLiLdJDHnJZBAmZycf5Hs7TUTeitkZ0svbqfwYbj53+uzp gMD+yacp43SG+bMeKWy2fPBJYHk5zC669e7Vp2dqSHCQQWiot0dpNay6W4k+Ozk5U5nZPTOzO5RN FfG9IzIKCvLDEi6kZCZp1UmZ2v9IWIir7GVEbsK+efylpvC3w3/wFb5N6o+NdkcvmSal9GJN6ueN CJma1LedXZAJDwNE9AP84MsMvqG+3LvzQkzMhF1e3GgQEX5I3UGCMKUXTSZvxU+bW0hERGiA9wzl D6EzKIAFLIzsvNw2/Ra8f56bcPFc+zQ75noxPUNb8gQ2e0LHK84NTMT8Yra2X06dO/uE8H7dE/p3 6t82qW9I76TEtIg+ws6ibw4Pz0hL6zG6su1jFntLojNtQI+YB9o+1O55xW1D+Xw8D3aiNKd9RcD6 AH6P730B3HulVwCtxJMOToPXBr+oQj3T1wUVT9S2xYTTF9PTzenamTjdA1c+m8CCu8V0473N1DdY r+fBQaFdOZ//SNWyx1nquVtXDbdFDL2tbZajYMqDrP4A68PUmfE5X7WteOPgpvr1jyGG7ohhjIyh vzM6Tok3DtYJDB6AIDqB0Ly8EUD7x81CXxdc8vR/D4JN6NQ7JDQkMNhMht59+gT27hXTnXdfWbX0 8bY9P9y6epgtPH++bnJ8/pSH2m78oG1XG5vpyP2SXffGB676dY/JO+cS5VrlD+RDq50RyTxZWI1W LyWZrDqrPtlnFs3y0ZdjBfBUP5IMIoa8kfrg9SIGN7uR2nMUcl5i5BYfHyrXMd3vUal9hA0UMS+x ciMzbtf7NIkYZ4SuHMNtt/IU7sSdcC/XWTnj431L2ld29tkJuMZaJ1Dy6VZz6wRzuvnsaflzsXVC +1I7Amy9bQE9A2zBtgAe2ubHvi1kZ9t8l7DvRrFv2vxHtZm0szqzbSNbSW/jebLIGVPKS0NfDxFe oeXhe8OFFyODovgbA2lLoNPXR0nzD7YE1wWL4CYW7/Sx+Jf5c//wsMexyLj2Jwy7OEG75FoD+7OA wND+2kqz2Z2wxFjhbvYoQ8eVJjegfubU2V4Gg48jMKhHWn6frKlL2zYmRi0t7GTyCvJK69kjr7Zs aoMWXRGr4yV43hWU4bRyXV2Xyf/FxpcARlFla997q7q7eq/eq3qv7q7uTjrp7qSTQEIklbBIWEyU Hc0QUAEBJYlhVYbAqAHUgXHGBXEgjuKI4i8QlgCO26/OoM6TefpUdOaZ8QGCmhnfDK6Q5j+3OizO /NG+9/bthfT5zvnOd07dTtUaDcbqtRYGER4341a8GffgY1gLQrJiP+pip8yiBhpsoZhnBmCkv0rK AWaYTDSD54jnYfrOvwD+WQKZwYhSih8pWiOj6JWaSr1SVzlbj7frn9cT/d0mGmv8N+0dqRT9bGVZ +UrOQBlFpYpX1TGdUej7MhdOkJHgoQy6TtEjzVsh4C6MKaBmwjgJgV8bOMwIUR9SnGEmy7QybUwP 089omSP4OfIW24eX7PmE/qsDZ6lBa+tquzXp1Gr+NRrcIMXIyLyrGX+h+fkP0zTPUD4af+E0c1Cz APFQyxzeO4cL92HtXo3GRSez2duHrYpd70VxJU6UeGu8J94fZ+M2um2ZDWJ+DZQQPVDrivJh+r1N NITmwDV8S/s3kwaGwmbUSmUijkVjkRgodRAARKuT/b6AL+hjtI64VTbGBdEjEq3E2uaikNY7Fzst sHKbYBXD4bnYx8Fg511zkWiAQWUoOhSrt+LitY4K+zDwDo/b5iRg4UR8GO9x58qrhlXZwIEKLkTG 39c5q/WxO7euf3fuq2tvfW1MdXtVZzCdjVUX1YyuHFdBtp3GTdfVb389//yX+QMPnnzl2/zpPQ/O 6diFq09vvT0rXTU5/xhg9BUEnBYs5kYPK05FaBV6hH6BRYIikGWQ7oml3gEKvR7yWw9kXkZdc7CO AsDfISu+BbIopAL8D8WCrVYof7BGz5kIA8Xot/D0RsVusVgVW2XWusa62dpjZa2i5zCJ4RNDxk3V TuIhamtVdG00YKrR1wPn8deplBq67S0OOWdzut0el1Q5klRSA9DP/xUeLzlqb8iT1uFug072yg3s 7x8/190xPEhkmQTKVpE//6o4HAxRPyyBz/gsfMYgXqCs0wnGao/gv6pCUGAQ6WANut1Fulpdo26n TquEr2dncdd7ZgmLuE5bp/0x468tW2y7jLssRzVHPX8QjnuOC/3h79nvPS4XDrCixucS3aInIOj0 HqNgDFSIV4sbPJvCOkEkxOMVTaLWzIhEoxU8NN04WHMf/Bp6veI01XXpsb6PySkmXuPdJOLt4vMi EQ8zOTDc/b2YmIJ9+H7I6dpPmxyzHUscaxysow/rFAc9ceBFYSXcFWZawz1hEhaP4O8hzsxYUZyz oVxYQzaRl6AA/IT8nXBEDB2G0uqSP5+oLXh0yyQIK54G1sBgSzskzfY9WnrK4OAmPX5J/46eoJb2 makTlMJUZOzV1YQvPGXfavF+ER6faant5jWrX7O8RsVFRwsgVhAYjFSJUGUFQKXVRauGcq1WR3RS eVXVMObZ2ef7oVYKb7vtpu1xWXxn646/ZMc/9f1IPHfx9LFerMmfk3EDfmTn2qeWth96473N8+f/ Zn/+q+F8GW1QTYYonwZ4luOJh5DhQv9eU7WeSqRaU3W9foxhrHFChH1Hj4uKhhcpFa0V71T0V3xr 0KEKXK9fE12VfiZ2KHY4fTT9SfQT+eP055EzsqmRK+rD9/UmkzzqIyd6j2Vxto+p2M9oeDd29+Ht +wNKKlMR6MOjenlzUfIIXoCcSE/+RzE2AwZks4oBINm724RNfXgz7Jd2lZLNpT2lpBT298/WrYHP 3kdOKgalAvdUvFxBQA/hkQcVx0sO4hBzlHBOXwJIRWeAJjYYToCaBOpJDXTUDbQMUImjclBVOhOM G6ysNiJFpZgkS6xWI1vicQOQS4YtnYuDVlhJxsRcbNCntdm5OGQOULbha4c6YcVr4UeNsQ4EwtBR pXIO4ORWwZKGkpQHgo+yT6XKPfFolMYhRVa3oGbPXU9Mbzi8uqvtgfwXG27MSKLXtsIjF897OOoN pR66Jty0fdza1q0L2PEbHlzYNOtX28oO3LF77dOjE4ESTlOnNW5b3DRheCBZHzT85K6m+Wueohwe hmg9BOgaQFV+oCTdZmxFY8yKlVGsuNiEXTogXMzoNVrMmoxmxJrMrNZkhqjyK3Yd59TpOI5hdVoT h0JmbD6CHwMFb8TbFbMGa/WcVstpWJOJPYIbIV44PE8x6vVWBm9nnmcI04e/VQRcp4aXFbcCX/Vb GatW0WGdaLkihtprVYRqIYBgeYqnWr+uOgPKo5Yf4Ac7am3VNjVgutMpFvIVXVqtVmC0DlAj7R3Y FbVFQZPgHEyYOXRgx+CrZOltO/IxfPbn+UfxvC5m3fn7yOODsyl/zQV/X6mZiCQcVEY9yWL7zOAt wTWaNdo1gfvY+wO6SlIpTWWmhqdLi/zLNCv93WSjd6P/CeZpfU+0P2pFUaweDna5PZwTMi9DTWUL S5By2bDk9fkZncBqYHd7bzgsOQ4DkwiMQwGb4k8R+VSSQJUdxiORD1+9v0vXQ/0Yfw1+HMVKtDVK ohAg3x/gSY+EJfomij6s8D084cXIYfwgPqNa7EQL0DzfQq2juvYJIB1YQz5VHRpYn7JMN5dOacBc iN4pEI1i7sAdpCO8Dq8j68JaYBxKNMAzo26YoRgXsUvsNwXbNG0BTctMEFk6ScdSD9Zqr9BYQ84L vpvAzMpr8gtmYv3Wu6ffde3tK1ctSUe9icyESUv3bLv31hcwq5n4zIHEtvV9iw50JYZNLveneKli z5o7/qumVEes1DtnABZ7wDsFqETPK8VL9csMyy3r9MflM7JWy+DVzCp2lftuD1vLJbUaJiomRS0T ng1SFrjjQDiO43EriLP7ewWkoeKk12rGYFyFYqTYjV5UrBQTpbi1uKe4v5gtFgt2h4eQg3eEHVmH 4tjs6HHoHGLRZYlyHgTniSGNolIFEDpYtWWgA8yIL9tyn1Hr0xLVhMAfJX5Zbw/4g36itcnmuKyP AkPwvrlIssAqZojPxX57eC6KmGBAFzUKJQ2VMrDLwugu8jrVKLYKe6wqh7Uu5yWLA/kzD9312ycW xTb/4t6359/59r1zXnwAW79bNPi2/eqxucbpG9avjk/XLJDNTb/5/YYb+3c/c98zN/TiwAE8Lj9j cHT35Na/NmSefOTZH8IQBRMvnGB2QBQY0SuHEHuhv9fhG6lRL6PCQuSwhinWNyDF3GruMb+Jj5IP 8Yek3wwmxUaMzIqZIRoWFOUvFS9DnAxDWMasUa6u1HyKtTBpP8X0tDnecqDHiI2iSXOYnEYM+Uwx IZZnFbaZ7WE17AvkFDIN2Z1WUydUuj5LM2iKH0gV9Gm3ZfVrQ86r79R0au/S3KVlhxwXMmQH2BEU OMhXCWScLvEf5IN8bRt+MH9ve3ZKLqCZGP/hRfZ1X7rVSPsQd4K/bQR/E1Ec5fAq5fBMKO1yoVxx YkluVaTL2GXq8nb51sld8Y25ncIO72/lXtM+78H4kcTrhteNH5jdOmTAWjPx6hNus8crm2XLBHwf /pn5bstOZBmBavAENAE3Jmfj6xM35BaihfgWMj++MLEgdwe+M7Gs5M7cJnaTpkvXxa2zrbNvcm5y P8I+xP3K9pB9q/up+HOJ53J97AHujPFz0xnLmcSZ8iKdWZ+oQdV4eLlmNIdM3gSrDrxH1eJaTSmd HOZAvR54XQ+eT29ZWPPAxTyqVCqJUtla2VPZX8lWRl+ABxiIgWKIAUPWo3g2exiPWHEY/22IWKg8 P6uSysCJswWFTh0e06oLnLw8lQlGbG6Wc8mSJgpyXBeYi0ucxXNR2g4ZMcJCigxSOZ5yl85FGVtp wdWHfJ3mR0o27RS1+OWSTef2FGoftakgVw35OvV8h5ZOQ9kSb3i85e2dT/5h8bO7qyd+tOeVxdNW 4rIVyrJ587oqy6omN99/6+J18avJs3f1TLvrpb0dE7ctWn/NvPZNb62cc/usPe8vXt10y/JlTRUL MvnPxu5oXbt11fRx1QuBg66FSHgafMKDEtik5O5IHNd8EDmeYBewKzWruVX65aYV5pWO5eF7uZ85 DHpuUxEZwWkSgpQQNExQZpFOcxjfiASs7Es0Q2YDZlL0GXmJDMoZBSk8Fg1w1H37PB5kFigDebH1 ILLz9rCdsffhm4GNipSiriJGKWot6inqL2KLMOUwCZ6mGF4yEIOY/JGeGSgImsEC69cNkROvNqds BY6qLuBV7ItxNlOcl/3xaDxkluaigJWWTRyswsYg1E42GCJ6+UpKokCpOcFDuxjDCsw/bEjMEGAn TAEqIKRS0+J1/X8q+vWaTW/Pu+ON3y5/4L/fePxFkrM3rJw0856Z9bPTP/XLZCmOPX/zXw7uvXfn xmfPfZpfuXYhObTumjl/XdGz7d3l00po1Q1V82ZmN/CRBzXsYUR6bCRgnl+1WeyB4k9BOhMQulVx QTFdsdnV4yKuF7AMeeM/MSqwx1lVew91YlL4inLacWVpLQ114Uoy9Q10ZnYXaux0/aCjobBqoJlp Tn6srgSq7QY0Bf9FWfgUeqr+y3oGiMPPiy5/szjVv8ytwzxKnkaf1/dP+2YMO6P5KddT7mPT2HBz +NrwdbMFVkJhDEq2iV2AbibzA92IXYk2onP1zB6uvqEh14CaritrqCeINbLe4qb6HGFH+VAf06Do +ZF45AI0Co+CewcbrGPjqEHnP8I0wL/vY67eP3FtVXCsp4+5VqnSjU1XVBmum88OLyubOs04trjO +1zYl/UpPsbnnVY93NrY1Ugan3bUhCPZiBJpjrARceq0Pny8V3rsJ0IfHnZ3KnUNdarBFihjvlHj nzb+Bk+iurODYNTBU/zJuroB/uuWwZaTqnsVvAyexB/t5i21qqeNGD1h2FWa7NXjxo4bM47Rjqip rSHakrhedsXDsk2OxZOQFEdf1diJJgxrDCBthg0grtTYid0hKMKW9iIh4IX5IPb7RC8v0z0lgCwJ eMa4mlGdePzwiQGkyeoCyJDSdSKn5FFfJfoLsz1qhXk/NhVZOzG6dBaDqnPQ5z/6KS4u0BD9GT4c ajLMXCQZe2UFiUUjLHE57WwujBw5gqRIjFTydpQrZ+0utX9Ao0FbmNW+gtszTEdTz9CbVNHvJ8U1 XUvr/alw4x8f2JF/98Bn+c7P3sJt72Ed3tlZMysfz//pb/kFn36HXzr3Dp70f544v2HiJPuv9o6+ +rbfPXb79aNm8tKrEya1N4+4uqSm677w8EbmxXx7/4pYuOQBPG7vsziy9et8xXen8utfwcAl+b/l d/0V//o7zOGjGD+bP3joYH7Lk+Pqh1/fu3DNwl/gBe2Tx4y5zdHU+frmGXVNMw7esP2mhmvAw3mE NLs1i5AfhYiwh6gZ1o5DQRIMINAxKBDCoGacLzKfIg/cdHAzMJ8qHo74g4yV87sDKNSGu+hfbeKs hEOZOkpEfzz2x0yG+gc/MPC3L3Gm8MOv7n7tNR5uZdQzOYvVauYNQX2oWdK6rA7ea/P6fH4hoJXo sV+5kk692RkV6pxKq/PeosJ2OF7Y9gYL2x51e69LnZSHeUeF2WqEN6+2jreO5RuDTdJM63R+qnNG cKF1Pr8guIzvYrstG63dfLd9Q3B9aKt1K7/FtjV4yHqI/533UPAt65v8HwJvBj+2fsh/YT3Nnw5+ b/2O/z7wfbBEb53gIyHQK2AkFAgG/XqLwad3+z0+N0d0Ps5lc/pcK4JWPswH/f6IjXfa2myYfhXN 0keOKjYSdBISDAV2IFQwXB/er5g43sq43G6O03P+PvyDorfCa8gOi2LrI9nepiAO9pEvFUtYsTRb vrIwlt+GF21UGU/0QswKXloE0K4DdXUYz0JZMFjbbSlo/+4WS1pIdWtWv5YSED+A+Zf/fezmV79W q6uF/9Vi4PJRpg6oAiTVr2m7CBx7GM7hQu9Ibb4aCbNz8J83REbMzU+dKuZG4r9E8YfVLZMHz1xb nbzt1Jf4jfebEqGMTpatQvaX7A3nHll/rUaW2bRUMhubSWzwz1STRRBiT4ESDaIUGk5WK9lZaFZw A1of3JDb4v11Ypd3V+KM9/PEZxnTcLQqsTL3aPmW3I7YM7kPvR8mPkwa2Jo+8lmvdX5VDfUKf6SC zsr/uDwVOUUqgUEMVpQr0SQMvkDF6NhoeYP3OH4/9lHupKxjY1g2l/OMS+vzOoPumDvpyqbLx8TG V0zHM8RZiYeIjUd8zVQ8K9Za01bTVdNTw3mz3vJmxPA6byyYFDOsljBBT7Aptz72aOx4TheuUWqa a24kNzKtmlZtq641u0x7u/d2X1uwM3Z7YlXyLu09vnuCm3JdNW9mPsp8EfshJs7krCGfXorwIZ9b iuZiiGFLUGUqFGMiRcNLckw6kqys1LuLkh6Pm6ST1FM2Q+1D3b6mUp0a6NTVW1dfQe/2jhqrzooT 9ifO9mNDMOsn/qlsKjS8pIw+wI+ptCugwSH39LD9LMPSTYPZVoFYHGYxCPs/KXKJ1uEgU0tMVisd zWYYI+DLVp5MtYbpXeu26poX8J+QhOZgAbIwJJJUqnbSAPjOYEt7qqWdHloqY0rP+NRpYCbQcS31 0I4B1cE6CgIGbuqlJjWpeAqlvqeadiwhsdRnKqJJIYh1Xp/oI1ptPAbCKhdPCvEczujKcjgajOeY ClyWYxK+ohzOatI5JAciORQsZypzUFtAAqi9QtwU+jQYeL+jowN1tF8SqIi22wpSVBuVKnPlQOS0 PxqNVkq0awP7sltl+EK7xjZUlqlNOWbv/WPndH1ycrArN1X2BBKTcmT8kzc+tO3OwTvk2dUP/PKa Vw/f1NzZvv/Faa9uGjnDR/YFG264++ZDU+WqaAez+KdSiSzEDi6f97hVp6tbN2n50+5zS3xPrGh6 YAr9TjJG4y/8VWMFro5hojTogxlMrw9lQg9ZtwSfsD5hP2A9aDdyQfjtoWS+w7XCfT+z0f1r5iHv LuYIozcxFpYExjEzGU2G420x0BhYs5/4MD4MamPCgfCjmqSfwX3kk/221G4e831M/f5N5u1mYu5j MkrGqafH3DEu53c9b8MhW52N2LwKOKC+NixgqxASiKC6h9Ao33SjKlJTLR1qn/+bjnYQFO30KmL7 2Zazp+oGvjwLlENrjKMqvGGXT2vSyd64Me6WtT59KTK5YOBETSk2eMylVJfiK1VpB9TKjqhqdJqm 1T6+R8tGw7R4sMeoSqXIDWP/FAqNPPV490erlw08ctebK0Pz8l8dyT9/aOMBXPe7X24qtvucXqNm UT73zoEN+fc+6cv/Y3P70879T/9w+PxbeMqRcW6HL0t1YBSyJO0WuUGPM8pMo88YuId/kP8vXrOM X+bs5h9xbHEd9R0NvMdzgs3uDAQZnQt3e9cHSZLThnygH3Qhn1mKeiQxlLRYzERMut2I89c22XGh CMjaFbvG3nfhvw9QG9obozQWR9ZVKlEcjuK2KO06MVHJo0ajR41Gj2puD6gOEw/RqFU3tV66qd0W mTOEAY3FQXWEeqEj9Y0KyuWQq74YYn5v0OriZWc8aPVPw14XDAFbaBr2OcRpF81P2xQQMS3tuR8H RhhUEa/TSgmwOgKuhLiI5qbF3H4aAUmcxVe9suuV/NKP10w7jcvz//HVrNvlYdLtzOI14RJ5Y/7F d/MnX3xvrh+PxR4s4tEB6uvFkA/2gcVzuEqpUyrn+5f7t2Z3CruyR7L9ldw0sU3bplvDrdF3abt0 m7hNen0s5AtIETnkS0lRTqEG4SSLJaT3cTpqSonu6CRCQlqfzs/7CI6C/gjk0I5UGpXytKVM3oVU UZICh9oR8J32+wOcfhfHaXfV0T4z0vG6Jh0D73VKaVbfa1l6V0kqVJqBly727gqDovkE1Pbk5so2 KLSZSsSrUPEqKrwKFR+RYypUMXUzpkIV21bRfwh3q+ULhUnFCmKmZeBsy4lBgKtloFa9nsB/CRkd prya2oEqawdraZHHD3yJ+K9TeGgeusbTgm0SjYCcLao2mCV6vSenXu8almMKxHYZQBpLsMK7cHFn okIryxaL/bqp+ff55PBTty/IjqxPLj33RTabCnu8sSlZ1mVNuHLlyZs1ZPB0NN2ZT97ojybz9bMS nnBm5Or8LtnDKzcy7WuDSTn/waJml5UiKgGi9JxnKS7ek8z04aAyTL6pSs/qDbszzCOpw6k3UseZ d1Nn2DOGc+w5g75N06ZdAxh3abq0mwBjTmfQFxOdZDL14bhi5ny6QMjnkSJaAJXuFGl8WouaO4Mh X1yKpkqSBs7EaghADeb3lKJoHCX5JElSpOVEIk7cHi6RSu5CRRgVZaH8boOqe7NWG9LhJh1+SS3j 9ytpZFGRtKigWVQkLZFgQEUyoG4GVCQD29L/FnRnIeZq6eV0tU4H9P7Wcgk8tVBX6/TUEHqDF2eA sJ02tVPYRiEDENMkGrVBpQ3ElnNdkZcu4geP4ye+ndpklmWcGDP6W7MhXJItGzycnRIXzIYQOAXz v+aod8zNCwG0LyYsyVc2jZfz0+ZLol2Q5bLwKmZxYZ1/f/bMJMVrHGSbZyDbVOAWZYqBHZsmYsKb JLzAiyRcpVS1Vq3g2oQ2cUXxZmGzuFvYLRpLM8uM3UZGqEp7m6vaqu5jn2P7q1gTc4/x5SpmHAe4 CP+M2Clq0Qo1//Sq+Qf3ggKcoIwqe7TEIwgRbbKEsSQjepwKBU3U8kHVyEEtNXIwYrM12zfbidXe ZCeUO9fYL9hZO0vRsAOBntinEmgf+U4xGmqb49gaD8UJCKGvFJ6+TZynj8cbK2/aOIQVECLEWSal QqWidkJtIVCU+IuZaoglK8IpHc/JyURRojjBaE0gRKySbQQOh3ibLmUoReYoDHzYMgLpE9pSbJQt pehHRWhxIYWl1Bil0oMmMkAxTCV2IZPZqJyolFz0krTLBjpETWsQuJc678PYMwD7lJUv5ge72x/6 Z9eE++pD9dcRs3hNwHl7/4b88re3TJu398G3xq9cMtzh8DGQ4qb0XLv0j8/9/dX8yw/GZbx+Xp0U j1fIt+bnjKw5/7tve5/8v7dMF4pc0Rwgn4OUt4KeykavKEsklUslhVpNUpKVojTHdlMVF/IRKSKE fHYpIoZ8WIrqQz6bFLXbINw4QSQUN5GjBhdZ+lIxom/jurh+jrnA4SzXzLVyzGzuZe4Yx3AsfRqn xhDXd+G7ffS1sMgrAZXG54TbpC6pX2KyUrPUKjEvS8ckMufPgB4gpgYbQAfYFSJODbOUSoN0lP89 WIbsWggmsmLwyFCMlGSzZEzZ5LgIsZPKyj+KCro+/yt1rWanC39lbGChKDqjjBhjx7Mds53kJk+b 527Ts9aXZY1dwFlZkYmXKxgqoJrILfh5t0gwyToVJ2l2YmcfY9gvJs36gL/vwg/q54bF2X3UHnSh SNQm/ohen+UUbhO3nXue07zEfcJdAKuRITN9rjhVM7lV+3nlT0C79cfkPlLWK/X/hurxEy1qamlp Bw0wZKOBgZb2utrC9bSLCoD3+gwmr8k/AhsNPqM4AgEb1areSq9BtzsuW057uR04dF1iyLpvqwYU Rj3Z+ZPFolQSziU8MV9GtacmoRpx8JYtL97fUlsmhoqvr2qYwmy7ZNMiyA8HwaZhtFvxQb2FwyiM lch0Mp8sJxvDW8I7w4fCJhzpwz9XcpabqqaSG4IEvI6RIu5hPttVEUPIx0vRcCiMskiBkvIzv40n /ihhOLQLLyZ95DUl4/7/CSi93qCSuUHdNaiOaNgmzWm5TOYFu509q17YBxo/0ULNBnbDHSmIYw/z L6WCK64tuJiac6vYh6TOc6dy02SXKonmLZ4e5k3lP7vxsZ8uwMt1+c3y8HAns4jKIRkXKyvP75oc cjnTS8EqUBdr/wFWyeKjymmrgC2I81hEc9JaZC1mszr7VfiqzExhCV4g3JpZKTyMH828JXwknMZf CGazAOJZmx2bZaqEquzVAuPOJoR4ltEKmqzHw6RQEdwbgWo81UKlWJmtK28qX4BWoWXCSrEzuxFt EO7ObkEPZ3eip7I95bvL3/YcFV4u/7PnuHCsfMDzufC52F/+DfrB821WHocbPWMzs/BMz7TMQs8K 8Q3h9ez7wvvZk8LJrKVQ1YZDPq8USYd8SSlCQj5OihbqXCnkS4AuBtpH2IkEEWFREGifZGQ248wK nmxGgDoHfnePVxQ9RM9xCGWziSSXvR5YSsykI+Gw1CPtligr9EtaaZtSjssxoW9h5q1hq41WqGUq XQCW9AjpJKqu6AL8P5MHQNWmido2gf9o5/zSRVOYBXUx9JU82lUGrmlvh/RML5b6MrzTVIcLA18t CLZqgbdXI06o9vRdOLbfU+3JOqsLxzfU20wMoSRh6hk/zuOU8DG+gpuueBgzYwfP+uTmbD6ZBVXt tEyYjLvwl/gE7spMB5UtN2cGX85Oj7oHv2aXnl+2OlQsyxXhDmbZrGQgIZ/7mFXvnt946YGN5+6F iLtw8sLnkOEnogR+RZmw0Y7tmzBUlk2Vmwi2BwhOkFLHcMcKxyPkE3KB6ByRiB0wM0gRwMwnRRiK a9RJcY3a7TZMSMQecdrtEYjQ3yjWxC5s0Osx8Xk5u55R8TDZJ9tsYT7LKzzD913o32cDcPiLhEcX avHDbytSuxNQ/BThMP1yen8RKXI46Vu4JCkbwS9HcESN2Iia0iM0uRvoSyNics5vLkZtge8u1T2w AetT6rGCAtYDA91D18ZBhlWrEOvocT7U0jFqhpLU20V7Ea5D1fYmNN4+G82yL0EL7avsW/FOfATv t7+Ff8D2vxNMM/lMBFqtfRT9fiS58HRv0F5HaAvGba4DSXL6ADiV4q+my71Dk0+dDojVkC3p8kPF aq+2u+3VhHfBTax2wN5eYzW8zbHC9N1+ZzVRbNUXG9sXWxnUq1ALA05V8aP8Fv1XL1Mlvg+3MVdR j8EfUl+KnV/nizeBY1FHGnHViMAIzcTzOsZy0VXObWBHn//dJcd5fkyJQw/1MNWGK9TT1T60Ryl7 2P60bqdhJ88uxyt13Xi9jh3FmZOIcSW1eqGW/j0HghieoccRFUbDNAYovt66ynBACZCArZb+DQhi 1Yf0RN/oH2oe0DJ1Et+e+qZQr148JViOffQ0oDfuiFtMtlLkw0Ipdupg5dbAijeYS7FIYLBzrlLk YV2l6EpjpdZCAENmgSJVouOwKlo/29SjgHYbDzXBAObwz/Kr8l/kT+d/9ueXvj1w24af39r70vcb bgMRtST/Xv6t/AL8c1yLR729p7H76fwL+X2963Exrsc3PLue9gpoJzOlqqcSvOIQSsNH/WVNZSa9 VOj0dfrvTLalH/TrVgoHY4eTH/s+9n8U04oJPp2MV8vViRHJbHpW4pZEW7orbXwDYa+/yD/B/4H4 sU/zdBK/GTvu+Sh2PPFh8ouY1q9EA0nOQqk0gkM+nRQFonVJURQIlxQHknXRpiiUDDpXcdLtdhFO x9mRl/dmvYq3zavxNqaH+gsojZX07jTZnn45fSzNpEuwmiCxmgqxmiBxxGpRo22oAlLzo2VbaboP L++VaMmjtvz+pc/QMon2/eKFvl+c9v0KBZDa5aNHrqrthQxKew+xIo9fkJPxIk88h2N+GBJicQ7L PtCjl3sPjVNApASBfqIj2EgwPAIgDCGs6mqUKlxU7gBJ3UKv/P07w6odPPfQRcCE+3LfToef9Mcn VQwegfzs9EF+xv974D83f/yHso76yusCCx4ed9eUXDO5I7+0KwT5eXiok1lMVxP2rnrqmOVqg+Hx rhkPT3DQqMgv0ayEqHChOBpUisbgGboHMaO14OmwmoeX4XvwZvQQ93vrSaRnrQpqwMw0jnmY7SPH lAznTvIMCu7iOKpf2lAXYtF1HGdmUpHakCPjIJdPq2gcjcmLEZRUoKD11v4/vr4Evo3q3HfOjDSL ZiSNVo/WGVkaSfZYWyzZluNEk8RZcBJiiJM4CSYuS6AFGsdAHktpDCSkAW7jQtnSlqRlS4H3EkIW h9JiaIAuuE17e3m071JCXx5dwG16m/JrL9h55zsjJ8DvvqdEc84czYx0Zr7v+3/rsezUnLTbqTpp 5wWZ/4qDToFvdQDzUVcN8rjJbTeFtKZH06LkkGhW0VNJPUmzaqAxh2JCGDOPG2/SHryb8MdzeFYR CTcCH3IFcyjpxRuS9zaT+tYMubb10L4d4gPpVCpTz8YHXvNT6ByrWUm3aeaujZMP3T392vTvN472 3bID3Y2wyoK2Y9675cime7/6xcMvXr+jp/p994EnJc1+5fNXds77HIq8jIrovunrpif+Of0V25/u eGz6wPTRgzt3fgd1/e3JkZtnvHVXYw7MUmWaNg+mFCBbnRDvjkbk3Z5+Nflqjrkg9VSOVtSG/MYU IyBBT+uLqX60id6UuhXdSl+vXq9tabxJvxvt0B7OPYOe0Y+mX8ydTQVYbRu6N7Utszv1BHqcfjK1 P/dS7q3iX3Jnc04vFURh2pvFXFbqzHcWN6Y+X3A083Q0igJqxJ1opPRshMIWgQvbAmokmkiadIue SjXSyI/NptSztEZzzU1PEIdVA/xcTuZ6uUGOGSUpYlTk2Wh5DH3NdM/KxmJR2u1yIUTxXhL66rdC XwtXVKjE/gS9AitFdOKw3IZMbImfaGPayjzhbJ7cB55wNt8YDBDODpDBAOHswKOVzx1DIeozngx5 YPjMwGaDlCAXLK4u1Lm6rjxNTsqYrQeGC8YUHgiF5ckdEHaCVD1vNYylBIkzGSS3tVRUgO9zpXhS 1XPJQisqxfEm39jSSiVTRW1WK6JmKAtbIMOWz5fgq06SUxHG/IP+KuaDk0f8BDBx9/RhuVqU3Rgi kYWMWN0yjEQCEZb//4kEDiJaaNa5HCvOfvX0g9OVVs0Zl6PpZRUiHIjyjv781sSux55ByuDdmz6e 44sKr7y6587Oy+lbaISmt3xaRNS+e+NtY+npW+/ql+ivo313bN3jA0tn5Oy7NjuWEx30GjPkfaAF uZGbFhnKbctSTXZjBVpBC57OMbTIPNHW0RZmIrYNyobQhvCGCGt32l1U83in7QbxBucNri3uofiQ OlQYKu7k7xJ3OHe4trl3GPts+1plr7PVWXZWYq2xcqwCoYKcTYtralNTrnUumkvXbMVQMV5Ui4k5 5TmVJc4lzX3iaucaeXXTaiOmIpWOtKqVSFuf0hfqC6+ddUnrJeVLKpe0rWt3MaLY5BMjTUlR65zd VOwc9g77dqYe5h4uPFLcVxjPvtz8mjHeebrTfyHfEaE20ZH96OeIRltRPdJgOiu7S9FIbJMaicdf iMFIObTbj4VHl+TyS5LLkJpdtrRAGjaJprAFlC0xySxEIJAZbywjpELgCyVNueB5yUO/40GaZ7/n HQ/jGaN3HFWfjRsyZIHjA9Q9efRS/i/5sxjazMUVM/9zvMNQeS1fxIBny7+IFlFVtIgErkBkDhib sbAcPgPJ28NTw9WCYekeBLfqiX8QVXWBTUCd8w6R3gCSN0/WRWtbqsj5smmxRWilmtwAaj684Yp4 15GTWilRajEyMoY4t6upWfdimOMLLNC85SYim5l8KWwyDA9ghVS4XNzovEq+3LANrB3ARrlBbbZS NiVRcVdtRXe1tegm6uFaRByGVm5OQ5yu51VZieOe1jg9k7yZSs+kI4NTiXlG9w48e8nVXzHm/vEH 9yz9y4uzy+oPw6EYp+vh/sPX3va19s7M9OP3Lzv536+9uaMhnHBgjcjYsffSrRfNbV1628brvn7R 7ncEey1eQL+472uD29bN2tgS/+EN9/bd96+VkFoAyp+LdaMDRDf6q9m5Dq2j18XWxa9B19DXxK6J 84VELbEi8bD9ocg++5MRjkaxeBBs+kYBpGeSU5KUSstuPjFGj5s+ARmU2eCqed34cr3Ufkg1pLNm mBeInBOISBOInBMaG4KqEQf56IIzqLgc3xDfG7fFX6CzVPDsB6YIUjBI5F8QX/157YoByyF/ZgAE XhwLWLECFzgousv4Bhun5K66gxeeDGWKFfye+eg9oupMdYFf98cQ4wKrz/LzpS037ifkEGjr+LH4 bN92p0WfelXfS1gjL0y9DOr5Yxuy5R4uLduXTb/Sl+ps/+jMjCpuk1y+ay9Bc+GuimdP2p/DdzWP 7jxGFbHZ0VwoF0mWRIq0Zl8wWs6ynewy9ma3TU/qmVnJWZmFyYWZJzJcU6aaoXuLN4i3undnXsr8 I812uSynlapGQonGZuK68qkRJZHEpjnGKVrPOoVmbKP99RDcNdx5jxhwpAN3sAksNVkQeFOq8iZW UvgiT/Pgz/L4/YA9BIdY4rUCo89y/5Ff2l2ryEU0VNxbPFA8WbQVVY08TI08TI08TK3R693qQ5t8 yEewy+eCz3xx+MwXKpw5b/8NzPhtII+XWIDGwHlnDsnpnckMKhWXXnTzc+08Zt10IuvwQP4/zbr1 jJ5yaTlK9qSlphwSHQlZz1FZUQerAlnKD4klowHMi9RmYFn0GT9ZJo2x5lOOR8J/dQRifoFOtvYa gYsm3/jte0VtIYSMy32pUGzZrqu3/3I5RhxwnC1QN0/95o13v737jrV/p723XajrldTw1HMr3hju ueHwW7S+VWvBdBA5+y53G6aDKhO3MnmOCKijKe33jDG/A/OSztBRoRixiV5a5KlCoYaFWa0mT53A r3FUgKyckMA6OYl3CJzDUWSrnNel+KoSfkeAnnihHIEMA9xGcWv+AXfahEqhR1hr6xeeEtg0a/At YlbK+rLhpkhzNlNqY6vhcnEx280tFZdE+th+rp9f6+iX+sP9xb7S59kruGvFq8NXR65p3WLbwm7h tjhuEm+Vbg3fFLktepN2Y2G77V7+7uhXCl8p7izdxz0i3u+7X3kk/HDk69kHCl8v7uOfFp4Wnw7v i3w3+nTsqcLz3PP8UcdY+FDx9eI/+X+KH8f+qfVcXbiyeHVpp2DriFwb36R+MWe7kruSv1pglgrL 1CXZpQXb2siawkVFppfr5deJjI2jHBjkosFCc7RJLXFVUainHsco7+zOSFGI2kSPdWcjXp4TkchX M14aPEk1CM69Cq9zOZgRs0WIRnlBcEQx6sXjPMWiCOUL+yO+bKEpkvVK+CqZeDqSqZY6ItWxs0PP R0SHNnZ2k+kv8pwmiWJjBB8dCUejccHhIG6QSBQPRAsxnm8EP1mxUGI5Dj6JFkt4t+TzZrJZbGJR tOhw8DwnzH6UfaKEn9lBs1KyUkZICkg6VywXSyOl0RKzorShNFgaIjsnS6dLfOkP/O+Fi8XI4bD4 Aq1RYfSfpmhKvdIJiZGe6pw9Rn/h+QQkIRmQtB2STyny1BmiIhpT753TCuu+tZkcbtwqn+jw9Q7A qfH/zk365JaTXV08/sfJXWuJO856Ye4DQxEzICCiP5sNOmtx2GhFvFEVr1izLEmsEq5FAQyEWOdL QsFjOjMTbQG4RL4MGC3Em31+EFlwmaxwt1Xmx/3G9F3Z6Z9OT6Smr8tJ/oWz0YdKpaMFie9mNaxD +0IhXxMtpzrKOWRDdEssmJ5jX6any8ltH32Pufzjb9k2frkhret6sTH55SmO3jG8flba5/TyLB5q at06pdLvf6nYgI17HaQ7Vhnt3yXS/d8O2SnkJXJyX61iFi9VLg31Fm0tDbc23Jy+OXNPw84MG7KH WJoqBrhAViv2Fu12O55pNkCTNNQUl82ksnq+WFyEzOJF2CpdF+/P9havZ6/nrs9e3zxUHEEj7DZu W3akeaS4p/kx9Bi9t3g89m+xk0VtO7uD25FlEEdHkAXLalqLqFQ2H6EsgI4rsUg8lVYaGrCy4cf3 keN5oMnGTBbvZZV0QyHLFfksl0krdlVGFKWqcQD0huBM+CM44w2EjukmeNxo8gJNwByPHSV4/qyW gbvgdVa0TDFjZnozQ5mRzGiGy4zRDz9fAKoMQSFkGEv6rrByPjAEtHiOM+G9w2Ypc7i1yBDbKnU6 ND5BdVa/XvLRme7MWCUfxBsMahgaRgaxTuxnT5ouTHEoCxQHGwXcfVKVsxr8u//wnFSdSbSGAhtC ZZgaP+v1Tf8XNIgB4wT6dTh8xcVd08ei6YtbpsZBT5i+d36hx5+mu+OFFXNQBDm6Ym1tmObyqz83 NTX97IzSgObRHVfMSjp0vaUlden0UvSdS/PRlhD4gv8yvcjmnd4Na98eo2goJ6bcDNVmp9FVtsVL sC709y6rZA5POlFJ2LwfvW1LTi/qA3v7grOTzE5mPzWLmsNcUM8h1WokYlgz4akGIlxe50URrHAY 1SmpFXy2otdLr2oNwiF4/7dEnWiFBx+Ax91Kjm2tcqTlcsRlpQn4lHwrFbc1tRTLkingi0pmLAZb D/5IGjv7KzMOB0mSbauCFDKqkCMUWY9zXS02qoA1eixvBrxYv8evicIUkMKvjAlUwDtE7R4ff9sw jsu/moAwYsTcJEbvbqW9K9uQV1OrI7V9whEH4zW8t1G3td5F3SPeU2Fj3mCnXBup2YToMvsydqG2 sHFZp1nbGeMdLk6jGi9ASx0XiBdUlrYv6LxgzhrxKnG7sM2xTXT3Be8M0mptQ40e5Fupcle+KVf+ HoYI+NNJ40eEqpQVqxLx93RWZCx/aRDCgxKjkWaLZJO6FHAgN4nVFcoGZZPCFJStCq18GbMYzLjY ZXbReNpDUD6Zq+D7NsYsMj02MT+eQ7lBnWp1SlK5jG/8x/gJsKtavwcrWWI7G3+jq0rpqj6ij+o2 Uz+t0yM60mU4SP8evYDiqACGErUaGENXmfFIoVriTFdV43q5EY6ROXSaQ1AMsWDugi9a5tXm4WED cssNrIKBlxDr0HWAkD8c6IJc81MD8uTm2uQwpA56qnCMYRQsvjvISAhznVXgUK9tWFyZHU3afe0d bR00K/AOnmYTjVojzVbEqkZ5Yr4o5fW5VWcUNSZn26tRqoMva6hSFr1ROYpcjXjTyXZFKeLhAJOr rtM1WwniwwhzNza1sJ3Vf7DmBegYMKhhzOmHSnimmCJPHpRJc8RVbdfw3C0u16CGShSriiZWG/A7 CtQeFqsO/Cjbs9A6cOvArYBb4ZxPf+a1Fs9Tn6m3a29ra7ecEmygwX+uBg/C1wGS1QN5PgHLxYHP sTLQ6cX/kmqbs+HWeNNPP1izsqan6UJaLxzYc8uFs6NeR4NblgJdQxtLneihlhXdqzuWbbvOE7rj CwtK3TetTu3c2NjY0pmfVc6tHm1S5xvbp39852w/5+zqeLD7fjTQFWoZrC7ZgDn/7EdnTzHH7F+l glQK/dLi/OfiduBgGXjZ7pcohQRmFAmMA2B0CcgMhkgH+FyC451wvCQpDZSNFnygsHr8poAP8weo iC6IibU0Ryzx2tuGZYoTPn3bGJdfw0yLdde6jobhh2LwJfB5cA6cG7fb0zoF2YnsKoUG6oWf849D sI87fz4KQ5KU1j1EIGDGH4feRP37Jqz1JiLmzXIaPc4eYQ9zf1Jt9vQC50Cblr6R2WK7i9lhe5J5 hucWc6iT92ec83xxf7fSIFG2SJCSE+jcLymp9lE7PWgfse+3M/b3pSBFKSlJkp29ziHnqNM2gjcH nAzlBIduEXfHnSecnBNz/9GuinNQf2VpPbMS8h1k8LPJUwPDlo9iuOZpqJI6f8Ia2ZDGiFxaY+Ia CjuUKBVSRCnK4z3VltBQSIxEqRgb0epFP3VL6PbbMcGT7JThtWvR+VpETFuWszyjt3o8wfOOMhbN 3r77X375nXue6X1itVtTos0u5Mu1Xldd/61vXVGpZOkPj/31F2ceGOnsZA5/c0lYTg5NZaf+fVbr j1468P2IH+s3izAN9WD0SKC/H+RtaAY/6PCn0hoJBrBB3S1wg4mhBA3OzsNAT4kYlviHfNiuxJ2f HAFEiZUYLOKx+DYGascnCaFMQM3Bc16SVXl9c65MJeHpNTjX2Omor8+20r6S7eP6I/1R7ir7FvsI NZI4FHlVO6GdpP6PXWhHi9FqZVV0Q3JQGYxuUYajd3u/6hv1jCpPosfp/cnn0cvode710B/5U9E/ aWeQwtI93jXee9R7tJHk6STn0dCLZ09SGn6rWGBQMQoEcBHTxWBiJEFTCTmhkdSWocToJ2LZpxPO xMbYO27kfj2oC1wMAoL+KjRmh7eKJykm3lAltELaJdFSQSZZD4PUEDVKHaDGqZOUAAM09fT14TvD dG8Y7Qmj8BiSTO9pFlGszFoL2djZBY0LjtFfsxxgkKk7MLx5avPAqc2ErAyjNjm5mYjuU946izlW xi6PXR9j7o8hWM0A80ZHRwfqIOVikNJEdPBDlKyA1Xj6iK9ql2Vw2I5jWYkl4/hzcrUelMMkthmB lUxXylTrrJkCwPpyHESQYdnG9Ohv3fnNPyB0aMf/KLXMjnvEZHLuFXMu+vbOyy5sL6NLDv8Qse+8 hVy7lqcL6cAWNd5z2bcf/2hB/mY8++6zp2x2LKFUKkcvrdNWukBymppYhRAVbxEYITZKiwWJwAqK GnFYAD1pxGGhkaPx6D9MyxuhwBla9AXmd1QMgBrSAVUviC7ZZwouepXPT+n4wbW0METjAMlVwG9U 1zDexvrFOCFOrGPMiK+LvfgsShMZBk6NDsWQGRuM0TFVxJcRg0SGBW0gsPAv9EOr2dxuvKXhE00r 5JvIMWRy7CqWLeSJVJswLOFmjE8YBoiLtwcGJmqQbY8FHOaNY1QBG/iLF5cLwCLzjXx5sPAl25fs d9tGCvsL4wXOLIwUaKoQbA4Yq+yr+D7jQY5bwiGt0O5Y7FjteNj2VPPeAjdeOG3QmkZpiRcwtYsY BRd2aSu0S7WNjmu1W7Q91B7tae4Y91qzmOZ9GWmeN+7rDsQywXnReKxbxaeJtpYAuWtqC2ppURlR pcSEpIGC4Q0MBkeC+4OMGhwN0sH3m3pZcEpk82Vojy6usAvyC7bWvT/LJ6eGYQUjeEHOzjCeMhaP MpGPlHxeTIbTho3P6Gm+SaMMG95kOV1DzfYWbSbrHLKeO4DCIbQFoQiMzxid68VfGIgr5yWjBccN 9mTFAw7YOg3Try8Y6Xnw5D9+ePMKLCHDhhN5cu5EMJITp0/n2a7LC/0L1x+4dv1Vi+Z89OqraPHy 736LCMqP3v724qgnufnH6K3uoeqKq3/0k/+JKRpqtlcyByg/FWNuq1N0lg9ivJOgKINykaaepxoo mhSCgCJNUTIseXd2nMhK6JgeyL+gKDGiezjIb6Yh8HQIzuaIdMXHcbaxs2+SM3DnJ0eBG2wlUSSC ATRokiUJrrYBQtYYjgsT4+fBOBYYofZiccTM5GSRH2F9o5WXnQISljmNO8AxFDfIwWIINu4+23ds B20MfBWHpwacmAZy9vvVOJ4ndPFsMdnDbHGDLS485HKp8U9DuDFxAlB84PjAgDHLqpHFZE8cXd4N ykBokBr0v8nYQ1oUq2nRatCMVlVSBLOgp8yrABEqIbFsmQyvbM6XI2xI6PddGtzQsE5ZH+YQI7Cc wEv2wAXsTvpedod0t7w99hj9jHLY9yv61+7fyGfovzE+7yA3yA/h2e0UXuZ+5D7NYaTjnNtoRgA+ YTGf9LQJi+jFwgq1j+4TLqOH6Z2+naFHfI8LjzvG+MPCAcfr9O/pk9IZh58/wSGKO8HRm6GFewfh wQMcy91m81PFYAB+qs9b9W4IbA3sCbwTsAUCkX+Fep6zJzCA2EBF9UHzlrnEW4V7fEkEwRPh3uCD 2UjVHUSbgluDu4JM8IzfPwLpmqM8XeR38e/wjMybPJ4Jf4A/ybP8066AjdoJdMW0mN6iC6rTGMol uzQXc9qFXPBLBHwvXQviC+qaCzYBlk9tBrVlM6zzMYn1fFKyOwwkZQx78CPCuvamANa1DVjq7ww2 sYfJcl9URwdkRS/oP8TCX+/bvJYYByTQN0xsbw5/m5isSmau6sRvWOLvYBYMb2hARhyMWHsR67P6 nsPac1h7AtkzXUI1IIeqIc1TdWok6QYZn9LS165d62Mb6pUnFoJ5AcH0RNqKtPwGXXHFjnXbc2rg Jw8/8f5fj+x+bWoH2meXQ5e3rbyTnv3GDTdcfpN/57sI/fp9xP306c7+VId5O9aHVlAUc4v9Xsqg +Tp36zmCVzkTYCdH7OqIgWQXi3hXE+JJjobXBZmgXmBQl5ewvpWswQI8CRiTHHxKjzdQlLvJPYYi B70s1GpOjsvjtYlJedICpXFQp4/Lr8G/4yR/ts7Ixyg3OYfCp5qxJjaFr8Q3IcKIiAUORESvJj/j LVMk3EjG8f5viH7tcuVaZiDobdjgr5+YsPJ6Iubce7RHAo+kmW6mW1oS2s5sl+y7baiQ25qAP+Wy h98jPCo/6jmQE2QWy6kNzRsMOsq7DsX5+xrRoTg3xvCmmozvib8Up+OelN6AjF5s/Babm7welucc MibwMXTx87uwwTtGf3gQNRtjSDad2SbkdXvk+9xulAJifX5wsEzazk6rrdWsNlUirRmMJsqjLgQk vsE15Bp3nXCxrlDLCwzLcPUQokWUyyfBXwJKdRdu3hs4NUz8T11dU8NdtSls2RbquS9ePeMPpvVA Wg9mo1TGn4qiz0S9sZL0CdcQBA6SlVZsAtaL8QGHiMKELb9AawA9GdXnrpx6uyk7P3TwYP/hzZ/v 7yzHG1p7VDWdN6MfMMumnhxpbEmlst2X0euWdO38wY3duY54JXGdz1e66s35S6Aac870IuZ/YZ18 NnUBtZZ5yLzDG+x9KP1IG0Pl5PX0luYtK2mqmc2zF9+j2WrtK9Zvar8xPbQeVrW4s2Gbsqty99w7 F+5aeteKBxoeUB5ZMWY7Zj/UcEj5cfnHS8fXn1h/cv3p9ZGwFmiVK/42db39Kb6nrRahgkxboidC hRac/7uNgs/nF/gRHXl18A95MQ7p8Dj8Ug1aU/SKtT36fv0lndHH0KOH+40RbGzhQ00nHOvdk9if eCnBJOrnkBafksDHmspoD+qBFcN6TDzU0wKs00OSshFv+jbxaCuPOx4IWFXYR0gVfsmUQj2OQgj1 hkZCdOj79C8pFjPXcqoLf+RgudBF6KKWFvfyHzBFjHdxvK1Sy5miqcpFtKm4q7inyBQVwNeiBCxR rFTzzEgf6oO5OTG34s5PDsl+0vkt8cX0WamNmJH6dDWLSNpPsCFc3pVFK7JD2fHsiawt64IjszOe U9z5s+kFgZG9UVtfXG+u34vvuX09nBoVpfJ6164HF6FFxIuzqKQFkTs4FPw5FvZjZ//D9JA4qASK QZD8xuAY/X3T90gN1UpFppehexkEqXw0A7cyFCuTFl+Vga8HNRk6R2GOzOfXrX8B3YTtOsdzOyFK YCXqD08OT5HOpDF8SjY2W5nphlUMulk+RQoyJuXJOihMvQcQUZNhaQuohRqW4Xh8MEaJQz9PvJOg MU4Mn5mEgmUY0d/R8cjwjJ+37uYl7t4Zn9EtS9d0LkxVorEGBdnT+qxSa6lcYth56RXpvN6cXq33 RVF0djxKLa0s16j5qKZRc+y1KNWbWx6lLjb6NNStLIqiVZk1UbR6Tawzgg+PzKaWlXo0tLSn0mbS C2Btnbm2rii6sHBRlFrZdJFGLWxYELXWQZmJ79c3n15Cv5kskALMD3lUaDOBNtORlzGNVmQv+JpO P+etR/lnovckDR/sdDaZrNtQrLVmEPw7t5qQVUPSTs5C5xbuIIuqsJ/cw/uVvnUTe+8cfMVwMayd cRv/reP4E92LW9REMTr0szkDm77wzY9e3r5U9FS4DWWjigI9V3SXe5ddtrB1+h+FYucV3z/0TGt5 97vowqb7137luGlnhYaww84uGRo54k9X/R6NszF2wTl08ebL71szq01R9PnC5WpJTV5K79hyy6Nr 5g/fsmfd/I9vb+3Xi6m5W5eUg0EbBn3KiYXT37A110bvqmNjrMMExpUdHgcBQoeSgn2FhPIV8PIA TyjgjyMWnuICIlXSgJYqDKQT5UomhxI2SaJXJcg1EjkFrpGDoASM4s6HxGWVm+Ex3PnAdBNQJtfL IWyFzXNgqPXit47fWfzOUGUIvFaIH6vSRmU8sRYbeLEKBbAFMep+8AEmyro9SJRW+fhrs+TjhjUy gQ3E45+wDfvLXmDJCtnib8yU8UXhkp6Mg8Cvg0Cug8Cyo+7pIkN135fS0Y4SZDhBhhNkOIFnc5pI G9z5j0PwAe58fBQ+y+U62uuoTUC73p8ApQvPwvKOAV8h8JIXOszmiqNjEOvNbt2dHukY7bAd6Bjv ONHBGCzq7RjsGIIhswNpvNIU94wxbtPTmGuKZ3oaHU1xuSeZaIqnxxiXmU9WMvl55XilG2mZNorM EqtVHo/sCCkpYdSBDjiQ2zHk2OP4ucPmACGl56hEKq/menODuaGcbSQ3mqMP5BAUd47nTuRsucH2 J7eSJRPAeTZFNFBoZ0KVk1APU62vk1kHZ384audZPZKO2kNRxPFhLgbwXPeUEccwVOmBH8PTZlXD 1Ks+LKwmeWZW3g0xDfFove6ybjGi5ZvumHfhUMTnchTN6bkBc5aDUbuLpS/0BKqLpjvnJP2KWw0H Ci7ktX916rJbFq6+xHx6+sU1mhKF7Er5QtT94KWF8orp6KV5NZXyOTpWM3Ms6xEiM114w2F+EalG uh6ZOUalMBDESJGck5C7M0E8GQmSJpnwKYyAEYTIcgGS9EnADazAegjuZ0fgaMGpzEh83PndoTq7 nZxhtzcPE27TwB3SsCKxKbEVw3DjJszDsHwx0WSJ1Q4XYBtZH9YG38RCfWJAfnug7iGxIjETmCWw zDRgMcxznODUCA8kyBauc2jp0npn3jyrY4ba29lVJri69rI0fClFaYlGzgfT+9CMwpmCkEo6CT84 aSB7J+EHmJnFDwowPuEfPHLUYqFU8hM8YNmY+Le/PVGbsIIVdVYIjabQYGooNZramzqdsmup3hRt wiYFgDlrVpm0HZ1WmytabVInrZkPhcuYQXw9jc6muBezRSY0T4snuqWQ5BvFU6lSVKPE+byOUQEJ VcDggwsq0JjuWoW5RpKcIWdKMY2qQuJGbZ3lUQX1KmhQGVJGlb3KacWuHEwefMxa6hmWHwYewNA7 aampGHmhsvjcorEWRGFSt9zCn1xW6Rxdt7WdW0gW03VT8+zZzc1ds78cKs2bXrAgHxG4eDiadSG/ /avwQVdz8+zpxJS2uooJOdy1Cn3ugRYt5E4NUfTZy6cXoV32XZhqm9DxupwXsz5iBPlUeH5nDoGA Jp06eZ6cIc+3TJ9FnxZtO2DYia33aXIK7nxATsGdfyenqHCKAKeoFNuUAXqVsiY487JNwcjPZKow OQFeO/nNiTpZGsYMYRqvYdvlyDfDiA0hA+50rb3iNA5i8Wcavcaosc+1L7bXYDW8M2IwMh45YTBh PpvR5mXi2e4QTIld5QsLzaGI1iRxwTHkMp0yRUkc/mb3Hh/ygeOrq9l6zObiCpM3GhrC+PlaVEtc fzBTvE2p6qiG3BqC1WtPa4ymEe/g2Nm/Y4sRfIMHm41fJOCZk3T9egTBSo9aeGX3e8vP4Kcvkxzx Ws3iswPsROQQobfJ4bWwYEB9BU6vUV9Q2KobjMZd7pgedatRFHdFQMtBM/YLhglswHyGYD4Rwgq2 foZuskZXl4HJY+RHe9f3lxLhiOdzCSUfPE89u8jHzUbXtPbxxvdPzU8mZzm5Nfqar9H3PmQkCAUh ykNRNgnLvXbmpTr9GGEC/yGytRLJPFZ1g5VUJjmBAoKwxbrBHwiNQMc0LCWhLZNXUV09IPWqCZYo DHmC//kgEFd+Rk/Iz+gJeZCkcIE8lLOSYqW8jDyqLe1oCOtZ8kWgsn8PawtpqoJpz9tGtIW2diod kiQrTsb87oggOQl5M797zsGShWuNuhIxZYyPj58PiNVx+jUsNSGlplS0nBZEJh1zV9Uq7WVlhP/f LzzgGBVHpW+4d3u+4d2t7qk+73BUQ9XwBnmDZ4N6rbzJs0n9Bi28H59U6RHhdtdrzGvuP9J/dE96 /uLla56aUlM7tFp1kXvYcaObL9DNsqZr6UK1A3XIXEBehS6W+zRbUl6D1rjfk/8u2y/wLFFfEV5x /G+HvUEIympMVRfS892s6HH7nGEp5o67VHYls8q20r5W7vP0+diQOxaLqytpW13sF9oUQtNIZhyZ Cr5HX5KQdCvmDQcbykgS/uq6dkOcgok8xBxhH5RmIsdx5z+JHM/nqx3n9Rqi1oA+M4EB6FzAD8ON uUp2I9rj9fnkkBqOh/JYVck0Omgh7gBNJZNsyxTmVeJt3VSBErHcSWmqX0O0pmLdsIhoP0I0lLGq PmTL0G6HLCuOdopqGEMfmMsU6Q1RdLCY8kMhxSEWpRGJPi2hE9JJiR6SxiGm09CwR0FKWK2iKlZt qFShQP1fxr4Evo3q3HfOzEgzGi0z2mdG28jSSBpJlmQtVpSEaJzNWezELElswNiBUMJS4oQ1QIhv byGkpcSX8gqUPpz2vbZweW0WQmJCKW7rUvpaQ94tpaW/S7nv/lIKBQPtL+W2JZbfOWckx+G299XJ zDkazYyORt/51v/3nZyQO4xTdUx9OTCaG8uRueFFtQlw+9PRb9yIp/bOXQj3CLXLDcIulOeIPGiD O5cuwOmjmSyhr4yMIkg4wtKlGKnvaGU8Oox6sTWxKQEWQGD2ofemGAaBX3bt2olCPruaICxiJ2Fk wAlw2nigvRJJQcsLbiEdEl6KR0lsk0etNStqnDXeaCxGgwAOR5y1Jm6/GR1C8XZn1aillqxEvWYz w7ixTVNqVZ8CrTrmxeo5bQsxko3vrLOx0QR44KJPd7377pVthbi0rLEiEUg1fivlehu51TGvlXco sjftBILpgbM7X13pstk8IVJRyNyS1xu/uDOad3DxOPC6/SVwTePUwCIRxONOqz96IbV8vDvgjCFO cwHUsHjIabzgn1r6lR+qF1i/8tjMgGn65zDPAJhnABtSs5ux8N9hC8PWUqFsSNHCofCJuV8/g6Pj puchc2BR7TXCDRmE1T0fF2eQ4pEpzrvvDJ1kCnnwFlgNSTfWkjw4WITC4gTBND13hs8OCxE0KEPp sRnMC3cMpcdm8/vOU/zrOGaEeMqJMf+k/0M/5cfOstVl1OqLa0vKwH/Uvq2zzw90f59/2D/iH/Mf hCcyNi3MrGsDWticjLUC5XBIjJkjQNxua97GgLtUlpTHbKDPBoZtI7Yx20HbhzaT7ahvgdpiqO/1 pecUFWgyY/8Z1lPO101alHGnVO5u1Os52RER5ZQTOE0PfNy1eVEI6yGU/li3oT1jKWIuUIeILdTP mlLEP4CtzQHsg/U78U/r3NRTaPH7AvpB0c9XwPA19BsXMvisTEd1deus1a2zVuMcf3TW6q7uLnxe FyaULkwoXT0e9Gk9ret6WvKlp3UD2PmLLqFzezh0m54MvjyDL89UMcYKHajiohdVhI3CSPdqEN24 io1gdGqVxO/jkgJVJ76HE9/DiQAtxj2UQjP++X3jHkoax0Yn5n6lW9GpCtl8/yykURQv9Un54qo1 SKFSui/ZpKNz8pvAxk07Nu3dRG3abO7uENWslVmaNRnIjjySaIODULGanUR/LYE2r3Gd122SOvKn TAkZ3L6IrYR5p7W+FN4e3t3KmJhLNm1mxI5uJ6Z4p4IDqEoGG8EZfCxT7cKvuvCrrh74PX53wgip 9leRGwEdrhr+BNz5A363Wu3vQTIeHexpzSDY+RN+t6dnoL85cZzzewGOHG/wKxD4O0/X64gpQ+o9 bF9/Sf8LxOq5t4lVcMvDrTD39jOyKInQeDf+BgJ6sMycGvjAR41CEh9A1nbGDsYGoFGtaGFxgjx7 rK2qhTtgR7e29Wjh7nVtTi3sh3b1sVhGCxcmKPuxWJcWXg07+rLYpmRv1yXhTStZrdqr17QUSzBq 9+Yt6IdRszbOyphpE9O9uqMg+rkBqH0Kzni0oIAR5TAq0A8qOl/Vcpn4okIVjFQPV8kqOubr3dIV 7+mJ9Pb1kqO9Y70k0Sv0kr1wXh/3+Mq9w/0DE+SlUGbtFSfANlx99Bym5Qyyy08bzdINSDdF0Gr4 V8f/e7EAa6E4iXmLvWWzt8VtvF2NJeK2aBA4+DaHutBmhyY7WsQIgVuqhsn+Vwz3pizBXnWG8Z/j I/OHmQUW/XkabAn0bXO1by9tvst7zQPr1+6M+uxc5wWNpe4lUT9HB5KbK9f3kKR38epGR0/Naopm N3ZWLm6XOtY3ltSLMtZzkzzwZMj3tvGJ9Lah29ev37T4rsatmxUfNPD9QszZBz43ktMra6yZxnps 9UOpdBE81qGHstWG99LOQDweWLIJXPFwtqUP2wiC+g/IyUrkPCerYE5WwPpwh5Hey/K+GGIJOfQq FoprLGZJzfosmB+wPuxea2bK2D4J2TUgnD7kgU6g031ECF8cwjcK4VuENOxd07DirLUUZM1Q0XDn o2YWCeRtHLpCI4JkvIAYiaUDW2YdRTsqSCrArc3wt+mWOB8vMnLWQInl89i5JmCsWO181XgB/xAQ AxEMJ9s5tnFF3oe989j/3YH7eAAdxv35OIulJ4s5BYu5BuvD8AsfPuRj0SGfr1ImQvjMED4Qwm+G 8BfFCI0Wu9AQM0FnaFql/Pc626BuuriipytsBc3/QqWvMlwZqYxVTO000HF/FL46XDEfrpyqkIcr YBgemKxQIdanhXnD8aZp4fi6NlYLO9bFQlo4ZjjeOpLprkK4Y2WQiBVL+BvHYzGed3B+X5wZY8Fh FvDsCDvOvsLSLHK8BbRSKJ6OaH3aMKqgNaqNaYc1itAEjcSFHCxwwmvDZcP5lvn7nW8uUaLMtCpR /iAwmUWT3JrGRuHGQQy7xr63v+l5QwUaFxw8pwSUwPqvPrj+BsXnsHYsbyxx6yWO7uq97VarA01E z+oOPtKahzPfX7956V2N3VsiEva58RvBbXt2fqYRGvSF4Ezr3gYu+foaGXsuINM+TT0L5xlPhEhb c6YFoRpogBuxOmfYdAICQ9tkGs0d9Cbq6G50kMan0X6VtQoqYUhGA8JmeB3OgSss6H10nowuDiCa kmkPpjiPTcAanIDVNxrrAahL02GbzQBJYFGEiAvKIqIVhl3lGvWCb/qO+34IfmyZCr1uMbt+y4E1 llW+Ld57wP2W/fzrASaiFys0BkeMR8CL3h/LpB4Ba9nWaFy4jGgG6v8bISnS4BTa99HD9Ag9Rh+m zfR7qIh3XbeNQxNnHheAcMHIMZtZfzh18frDfRdeesQWXnskQq+96NL+5xESmqDhFpmbRCJwRf93 CJkqEjThoYrvCO8EFryE0mHgXL2IThByqY4EqQYTnGpOOHmPQoSArACfBfZEBvbcdkEBAQruvFa/ QkgmuGvazK0/jASGtAapDqzo1523kLeY7+DucNzhut13i3hLkB0caC6fYQkKzloAbl4UqLEagRrk MmuWFDXK23f6UbTW42oGXEji1N3X3/rK3lfuuGbPTy+uXL98/DNb7762mzr0+L5Dd54d/frnv3X3 n2/rqj9+10uNXx/8wZn7hxH29s+NddRJSGtJoka2NWlNW4Lx9kUujRoUDkAREbdEKJTmxjzYrWC4 vYJiGy19DfNdZR6Fq1CpjIt2mOWTRtFn3QrVj5zq6BwwM9g/ZiEwFyYApE7IYaHmNoMZ7nmw3Enh RchY8+eh254linNnn0GEWOQQTWKIGsctWQxHh+nWjXmkWzFkAPZeva8HsLKmwLNSZkeSAJIDDsaK RoMGgDG6gsEZwTz651QT/pNBVH03twRRa01YK1wm7HfS92bBkmx9yfrsZdnrnNdlb2J3O3dnP8t+ nXmH/bPFXljSXxoo31Cm9SUgz1IpzeWGapV0b5sbKlfJGJGMbkyGiZWkK5Oi6JzQCdBISAaNSRId xY4IN8aRw9wod4ijuHcVErvwAorSh2Cro1GA4J4GxNMUHV6MAL3YmEFFHZtYXsQOkQfWP++BpRyo Zq5RZF3JVxg7q5YTtkRBrTBFBeTtcFeydCqgw5pTPlEsFccRIQlSask7vxgRpsNkS4Ep+RbEJEwG w0QpKE1FhwRyovvAxs9dvvO+kX9e15kq+mvrG4pUTbq9QiwsqqBscXz64m3LLrxc7y/k41Rt12u7 t97w2VdnHtvr5dsb71xRCqsq8Fk7tlFXDhREx97GP++ILe7f8Kln/2XnBtGF4hQrG+toAtJyiMiA V5u0LCcwq0x4cWEzLzSlw01b2oFsEozMbNYiwXqIAzmBsR6DauVg8IvppGE66wITMvNhV0wVzdqA y8o4DLqBJFNfaDxPYoo1iGYykEYsNJBGdBhIIxqUeTm8WaBAO1a5FTHZ107q7aPt/zN1sJ0uyIVo Pb0os1HQZT26Mb0m08/3yQPhvuil6aHMDuFK+crojvRdwk55b3hndG/mHvkLma/wX5K/Ev5S9JH0 45knfN+Qnwp+K/Os77twBL/KvJf5OJNW2m9Sb0odcD/sftgz2c5c7AZtrANa0MmmBR0Q+XCEiska QF8rpoZEhjE7AgEiEnEgsssTETAGyGEwCg4BCrDY3n830SF4+7zkC95XvB94KS9GAnhXZFvYSZQB P5sZ3GWUqMxjA3umPovo0dWqFSfGU25/3J9QiJQb7lRfTAFJD4JQtny/CAu8c9eiDIIDZ86Z4s26 o030JIH17yrlbC0lgfzB1PViaV2j6F4U8oiX3bf2nv8DPD+oDScWV/4xua0+cvB/3LTkcurQx5/q LwZVVbDWoOp7w8Y//OQdoCpKMD6bB9+G8vq733t2skQYEWPyBKSsFHimhZVMYx5pjvidSaycJsUI aJryCy3fSEuvjbQ00gjiRhghEcGGeQSrsBFs8eITgUCJPgk5c0UiAcnOsTG5I7k3SSVTjGijILOa RhbuDLRv/5NWiqJcwvnh3hi6XQJeu8Oy10Ja4A1EMxwpZpRObMGiMf4FM8oI8gggekUdjLeKRNLa Ag+nMIXxVoPzOmRA3wHNN75IFnmd1PnP0IyeBkNpEEFcDtuL98aSSaUrEU6uJDhr2ulRBECLaHm9 mmADtgGKIhhoEQ6ZgW4G5lwkDdKEMx6JRBQwqowpJKEI0EKcVE4pJmVY+8Z8BpBh4+06vXNXsyDQ rplBZzMjj1gQctoF9TsoOL2dLVx4y+ryzwdSz3P49dy0u7qmHI9t8bq87QW3ffmyRmZ1m8SZ7DE5 kuSAlzr08ssrssnOVR7tisbaniRU3uI+bE9ddfCCIFLgIL1smztN/hzSSwddbtJLsoTppaQj7YwE OFYKcKwU8AGZTdrQ8WSUb7EfHgnSInqf72DYJB+lXRkT2G0CN5iASc0DANKMdFsYXBUGYVWRwbA8 IpOyy0rUpwYHoQ6Uhy1sBhE0G5EI1PumX50WXjUk6Tx1FKN8kqXTvrArZyLTHYxxG8m13gSuN91p Ik1qmlkZBtvCN4fJsOqyAjTCP+gyohaeLxVl1oGtmKQLNclkqdiUmFNGO4Vws4NoE6amBuvCFM66 ambCaJaslCVdrpxurWVT1proGbBdmnhMeChu4hguxWnDpZHSaMnMlyaAou+D7PIn9p84puJT6i9i r8Vfz75FvxV7K/5O1uqqZwezN7bvyR4AB8gD1KgXrbw0GtzffiBnR1VROMpiMwe57EttP46xQcrn cQV9IUkLZB+1PMo9pnwx9sW41ZWxp7LrshtLQ6Xbtduz9zqeiB0qvU29FbRpbEeYeJ4MgwjI44UW MkeJ53MTQNadaTEsPR8IyxEZCLICnxx6U3reh95sc7niMbuV5pO4MYXBj4hcPt1BEOihyndLkogS ODy+PHqw5E9dALgQFOkDhDSjPLp1BK1zN8KP8RQ/ATp1KSlLuQgL2Ox4EgzjVFUK5a2SyZNAIYpA ObK+NTlQ7RFsHM0iFOxcFAwO1PJQrzw6B2AXL4B7Bi/3g8ym0wuKkkCtlIN2Wtxu9djt1laJkgGj RsngrvOqlMBuM5M1p1jsZSJjLF4WTGkRRXCamYgzGgRmjQ0SaAkLgkmZgqDF2JHthSpefMx8JHzk /DhFDw6AXbgQSb8ujYNxcpwat37ZPuYdk8cCY8FH2x6OjbfboHqcQVgmhNHSrflYPv757GPxx7Km wQGkNDtTilSzpKQa0LkaCbeAAciVcRyfq+XgoSzeLDWbEHbVHQraoRJAgRpupFrcgDXHjMaGiuu5 a9lm5YKjLuNevAt+hAt+hKuWVVzomg91noen8TVKsMPPsaMbfKi77PBz7PAcuIlOvH0yRe/8P2Dk 7KHCK/OLIvnnF7RC9dCdpVbSVDy5sOgKORZN3Hb56s1KZOjBnzx/yyU3RL1+ezQafPzKVVu2Nn7d 3v7YnZ29JafgslGHGi998bp17YtSWq77qq/teTTMyaD7/gcurK26YmxxbcvOR/y8Q4Q8zDP3e3Ip /T0iAGZbCOKQ7oI8LIRD6FYbdsDYvG5gcuOuGwsydwst5W7F1d3oWRhFNqxslvd5aAQdJoAZSrLZ U9P5mammDHujlYV3jj9JfgM/iPfeBf0AinpidarVkZA+h8MTI1Zg5QPAe60HrPUA/HE6JEX42dYA MGHjwISdKSYsBU1uw31kxiPF8s/divC53aHgAmcKzgOoz54aHJwUpoWpwRamAf6sgWcJOxxAl602 BIZIsh561Pmo9IL3Bd+E9LbEjIfAfhlstG20D9mG7H8UTWbRKyZFyucVJZkCaOcJHASUt9AcLVUg SWC2VdCgfa9438Q61tWewE8JK4r7ZRUoPHP50OEQGSIAoGlT3NPnBqNugAq8HXZPuk+5/81tdg8H n9rfMg1mjRTZQby0LFrbhajPnjYiefCt0wCKTwJrZ0bdcLwiHsYklbwxJ9apqiWscSUQdrgTr+Gy 7rXXSqnoMmcyNroy15/+p+pN7X6N/l7jZ6tnvz2wTEtdeVVp6Cpye9R37ZrE1UgyknOnqVnqIUIl C02q8iWxD5FtquVWJdWMCDT1ISXctDBPG5gMRcYnyi4cfXC1yM3VskVh5wyGDbniLdPTIapmq+IQ zaGsw8ogZP4zyPRkOSL/Rgahxw0V/r0WNAM3KLNqgR61hTFSFiiWsypW0RFX/fCuxi2tTZ2YM2Jg OCqmyDgiJmMVS+awX8XFsgkFU55iNqICCReK4qFTXC2UEOpg2nO5komFfn+4E7C/Ee0mMcACEiFW xKA+iPNRKiCJrAolieTD4SRdtlYji5U1kTWKSWbdG5HlGd0YVpMxNgm6mDC7UrGqIXYCrNLdHKGq UCSh7+PgrJzVGsXpUg7iMAA8GAHj4BVAAwyRc0ly3OXqc4+5yVG4O+ymjKqCBtlBokt8f+/5ehpa xLi5vr2xZAQunIpGPq+pIQhIIMg7g7wcJARnQAgFW6WjcS3GViDOyItq0SHU25hKtEmdThTfpa7i o75I0tF4v/3Wu1b17swGq2tA10A98+n1tUuph2Z/Po6zob4/unzg/lHwaFcxANTZx0b7OntIZkOV VFHEDtLoDKRRhfxeqwKOhZBdZrx+lRNuCtxI6t+PEAhEMfPee/U8lAj5cz61DpGzBFiLpS0Kr7N6 sPPX4zY7sf3ndJlJfATObwV3FHSf6cy5/wbUOP/GtICz6nSL62KuX7xMoiRczrXShqTQVm/FI3nk mKWNizoVV1xUJEVebKlxi12oFPNieR271rKSWyWuktbK17JfYR+1/Hf5y4HxtieJJ9ivW74mfU1+ IvBd9hnLce64eEI6KT8XmGz7ufgR95H4sdw+bgFtGGM2XMZtpsNow5rRdncbbTJptLGY0TqduNV1 KVjm2+4i0BqxI6a7lH8w3eM80GZZzJa5slgLvGiejP5SZu7j9ov7JKrqWiOSbtETdhMBJUy4OGcY zoJ79axFlhRRkgoWzmOxcAFZjltY2GMZs4mmWaiSuV1QbSLMsmQVJwAUT0McELg4N84d517lTNwe SwARsaCb8wfZZ9mX4ezdY5FukVFhBIWwwPHyrrKlCULHGIJiBTUnbBXCMgnNpQnwwnGhDYy2GU8D noXa47y7HEWMVRIy0NA9g9e5kmfFt1C5EPGMPIPaXeLMfLEQYQZx133NIiHztWr+SqkaoxjNzpZG gEk/AxB8+xlO8dnrkHm9fQK2lrgVwfL+DWopHIIlc+4aq0A1BW5N9AMwsotalT/cbuyKwbVAmmVr UMJH0gkOBZOa9+ev+VlrWxlkyp5YsPGc1njWl4o4i9RDakKJFRpm0r4o5LDwVlWlneHVZ9+nTJ15 wcIi23jutOkYnC1Zaro5WxLRsNNBZpGTz0FYEiJLp9SImTcjMq/X83l/bWG1qJZTLwGl50qMjgxi kwLvRexWYI29mLDQRArffHcWZIlbVKBab0mBlNW4ezbbHo3m2pt+afRZ9cE6goLiDzPgOPipBo64 cBmQYL3iS0ID06kmldxQ7lrLSO4d9Z3Un9Q/pWzohKPuCj7vpUCkHM3ltG2dIUmKBGJCjuYSoUQ2 UUts8n/T/03xmwnWqlbj1eRGogf0MmvZ7vjqZG+qV7uPGRVGnV9Q70vdp43mviw8hE5WnxOeVZ9N vZB7SX0p9br6eupULkKYaMbspf0WlUlaUmat4l8hrHD2mS5iNosXafutB4T7xP3S/th96n2J0Zx/ n+Ve/74EZbcMgNuE25w0nBPw11RVDjBwVgh+Z1hQYtGwQmjZMMFzjjAfkcJhaNbf+zQCDk7M7dF1 UY0rLMNamLiW8mhaClKDmiywFg/LWqB2InnjnOrhODUWjxdEySOKkpaISdBYh/OPg7/Dc+A9OInC 4L2nI4B3olcC4YC6CZSCggANeIUg0UFAZOEpcJKKz4HrCJVgwTd0PqXDwcbjKatylr+agzbVkWOT xNVaDGXNePVAvk8CByXwvPSK9Cbkeg/G83B6B04ovAoE+KM3s0XU54BAJAgvnOE2ncsPJYCeGEWr dID3jln2JPPsSTjNWahOcQqRAqOpD9GqLVD2w0tTBxnsUO3TwChat0XQFE3XDmuT2imN0Ybb57Wm GRRRluSZ2dPQ6NnZnNvwkAwPwLfF0zJUpdDWWjZPNpBRSMVqFSUx+jOGnYVqWGEugLBSbIsdsAuP /N01rFAFK6N8EC4NiHxkkF0gXpFAxeSRYYISltyIT4RQLfn5xoOaD4/6aypqvPjVEW9tPlhhcA6z wThwISuDbbQYSfM1iFEGH7GDUSiGp35YFpO+peDYmrCHPfU9T7IGolu0xsvabxp/VBu/Ci1aCvkJ HQ5GsrO/B9/at9TvoFSV8gsxj3f2D+DjTsUdJlXVfu3Zd8m1sycocm3JjnRGW2M1dQZymOJ8hALK gEyaIm5PgmQIymXsTfEghKMTd1GpuuMk7pKoW8Td4kRLZGdmMu/Bf/X89CAONpyT3GFLhgh5nOQd RVAkXJCnxO5An8F7PCWCKJfmWcsbg1NQ+0KcZdJwhB0W1l/S/zwRmPsTIc19SMjwcXJCE2jxlAXl 3Tgy/00j3eWcb1vnP5ruMZMWi8nFSqxsyXjkhCXuisuJzCLQ6aoEul3bLdu5a6VPyVcFtmdvZ3dz u6Xb5JsDt2f3c/ulR4hHLA/LX8o8R5wq/8YcgzM/k8mm0xzA8lBCQjRbbArRBKtIslxIcx54QjaT weIzk4aXpGULzbFZ2EpwPrOxpiDFBbEccLTJfKwW4st+vyyhORk4wIE3uQ9RSGKE+4CjuD11y0bL kIWy7GER3DiUeY1HsOFxhVQODGVBPlvPklmpVH4SgTPwsrC7ek8P7jw9e2YQ5eLONgEZvbOnM8a8 ma+Lyi6YH6iSlnO+lNZ/NQXATiQrM39L4GGJZ14AGUb6YhUYNdps4Clve3v0zWknw7ZlQFpNiRap 8fnOQxcu6akWorUUF+6OdzVO8FFJ8JcgCSdDyVWNIviLlnJZrHYoEsWoo372xnvuW5lNl3z8soFx 8ulILmYTbMaKJNQNkHq94Ek972JpkR6nx+3jjifpCZoZ9wO7/xZ7R2cf0c/3eakA7Xe4+Svoi/g3 6VM806TKFKD8PoonHSbbehO40wT6TMMm0lSwmVfy4GYeDPE7eJIvkBy06HYNDuLduXWhalCBJD4S hC5vGBmPcb1oMh3jwlbawfNxivZQFE1ZSZoHNoffjj6F7jMBU8FuMwtDPOALgOT458hlhIOgyWV6 lgK5cfi1cn12ULDr9hE7ZZfz/rp/o5/y23LWCkECUvL5vxqd3m8gSXvPnEbL90ECODN4WoD/IKdE +ato1xpjM8MOakj79kyJzVXImg0GiUJTFKpCGBjqmDulW8KuOlWAOxwmtsMOr6NXcR9ChP7rcV+N TnlQ95fHPTV6xIW6Y8ddNVr0ou7bx72wy+PuEb52Xu4cXl+DilZAFJf3i1WjXhDFK55Rl1vP/pIc bry6dak7QKfMFDH7ZbDh2vV+wQqkxm/jVFqKFdc11LOvxrLKNZBzNZ6a+9/kU6btBEUshUYo1U9t J28nn6D+RJqpCfKKp0lgpb5DJQmC/ABVSzsK3qJPkotJB1rG7cyMsUwMJm7IZMmnzg4MUN80bf/L labHEVeUCIK+wPQAoYND8yoUCBzVzD7kQbAT5iXldoJTuAjv51HiAlKhsFcZ26e8CeeumNBKdHHs C8HFD0ym5V2EH5/hx5gUP3aX+DXVgLObUebs/8V2Kuy8i2MEqrq867yc7HOIE+yNzy9dkKK9aSQ/ UibX5fXOz+U/1/lk/snOg8uf6Xyx83Qnt706vHxk+e86f1f9c+fHVaZvOYC2shbmkm3qsbByb5tJ C1uSMf+xcOTemKZ2LvJTHXznoiUby6A8Qa3U7UvUdsLbB9l1IUXRyLXantJShFmJcBauI28S+Dg9 bjoE5408svyV5eRy3R9P7FAPqKT6YFLqWj4BLns6+pSR2AApFYHGWku8YJLFqDGUjY1od2Zmp9OI FCPCrc2jTXxL6+nssvoFddKcSSzN6gpRTy9RMJY0jeNZKBwByamKinw0AcdN2Nf5C7MZ+dk4PXt+ tQEjPxsKYbAD7B2JZiuDjUVXBj0c237HmzZLMKukG7b46mVHjlz94p7N969oj7QValE1mC5d7Zap h8yzi3fUyXg8E74G/GbQzTtn/9cNiugMxuO9nyUvWX9i+tbaQLItF7sw7+Uvqqw5hiKqfkhjdUhj CaIMvjABivcYlPaMPy2KhAO58ZxmgMjNUTa3p72EwipMgkwmWvSWmKe3hBxseuv+YNCbjOlNliGT JvEZJE6eIjG9kU67kWJj3gQ7v8D0Zm/Rm90OH85fobcmBH8BwdWdLhxoKFvzfZ3kwU4w0gnaWPux MHtvW0ILK8k28liYuTcma+FIMua0ZzN+ihTlRCrtb09PgKRean9Z9BJEH2KD5aRTgMQEdd9UIi6N y4dkUpbhDTtLZNyxw37ATtof5KVK539BRy0qMtjfzIyrlQnjX0hDYq7o8nQUC8V8kTK7EzlPKUgU Xe3BeSqCeiekIeQNqS6glWUklGuYrlpLLMPjzvmIl9nrpSyNq8OruhuWVG31kSPMJccu/dSVX0h5 aysateUxj6iouZsXt/lVwUatmT10w4oEJBb9frK/58cv7Fq37uPVl1bDIB4Hbq7zcnISSsknPeFF 6clLES/CGYLUIcIHlJYLxIPx4l6893m8PsbEsiIbgmYcI/qbmHFygb9sIXL8o08ix0X/eelyRL6U cZbqb0wLBn786TER4Bw1qVgsj4iHxA9FShH7RFKHu2FxTKTFZp6c2MyTE5t5cvgqVZLL5xDl62Le pL3LE/autDM+gsGYcjuIYzC5hHLgMJh8zPahjUSIctJ21N/EkiPg0Yzh5KovddXOz3tDaW8ITw7+ RqrbnfInU9yoQ38tsQ0+7XfoIfADU42wEu06vxceoD5tkWz2/4j+5g2D6maI/OC53KtnCTO1YQZJ 0QUJVGBzu663t+t1Uw01aCPA3EmggifAz6C8Ep+HEukEASi0quLEERPIIybYrNsJnmi4wPtA/TZh XGMK/P+vMQX+Mm7aeu4aQPyta35z7nOIxkmw+tw17N9xDUv8x0l2wTXC33GNQHxwUmhdg/IG74a0 HCE26PZgWA+tDDOEFYQoK8rxi3DOstVJ86EkEfd6o5AfAJ4FG9khdgc7x9JsHhIBXoEaKrdvTGWI oSsGxXrvH2X4Sep8An2z7uK5FSQMMOHdG674zgXFlYU2MeRt71Au8FgtthImhYz3R7sPeAOVtpLd omUvzI6hNLXFBlpw+dxpapz6gHATSeJmfUN/ArykgpeioF8BW4LXBMkfBcCP/GCL7xofud8F7nCB +2xgtw3sY8GtLNhHgltIYNoaA4WYHuuLUbGYJhnqZJizeogJ6n2iPl2fBvnBaVz3aLqjMPiJP1BE awM4yFhbjqyUl5H+Ngd8jcqTL4OvcyT4/dbHdy5bdMPB7VeO71q2dvdjW1bt6NUi3Ts29OxYE8v2 Xkt90Pf5567b9p0HB/o+/8KOPZOfWfHp6rWPbF3z4C1rl+98ZMtlX9xeg0R+I+Qx11GvEQGi4xmZ 99iAeQKshaa9p+AhPTIIBCaomWM2PmBHWvAU/A/HPPvrF4Vfvwh/ZC8aE66ZjmYeHJcTDixWIa/T utrFQH5ZrMGm6u2iP1tPUa/F7Ynu2ux3a/WgKR5nlQs6ya0di8OWOJp7yyH53ASfdpYY1qMi5MhM wkTRdOLfbUzBCZxOOccwkiIXkHCQfCepEhGl3tctFEELNEln4AMtHUUspT49W/zpYLE++3IRPdtS Hi9o5KrNFPPTyMwchPSCTBQmWllGVZdR6EEi4Z9cZio1nzfjJS/vHs21XTabzt9449Vqtha1RZf0 5S+5NRNh/InO9VvrfSPd0drtJ//hQGeFPNumbb3y8nhmnV6VsxuWxLasszoXLauXlM5LtuWW7/7s V66m5+aIYmMHVYHfjyF8c2829kH6ijeGqMfgEY6wE4tO2CwMx9AoCr72mJ2xAg5SyFG7BcDv9bSJ ZuAXm4LfbAq5sPM/nJ2ectWE6SL8AXAQKeaEajUDouQ7R49+dfZfyZF1jXXgOPXB2Uf2NYbAV7dS D7w1ezcBR1Fu3Eytp34JRyHO/Uvjfnikf+5t6ohpO2lGei/8HVY0rqeOQ2qwEcv1YDe5j3yYPEHS 5CP0E/AxAwr+c9g4q5Wjn6PQYqQ26v0jFAnlRr2En/h0CSoK+Tx8ztMoiOcFSajuw0ea/H/sfXmU G8d5Z1c3zsbZuIFGN47uxg00gMaNwTEzmPvkcDjDY4akeIuWREqiDuqwROugZFqmHGVlWY5t2ckq cizLlkzdayey5jneLEmtIz1zY8vaZO0Xe21TWWfj3bcRAW5VYy6Kdp7zx771vp353hTQXd3oru/7 fVdVdZeVeKkTuxZ8vlMPD9Ykq/9W4vuGf/6ST/EsBEnQDCro7g7De7kdRvUqjH4fbW/qPEI8o6Dg 3XoxrPNluOcgPOId+Qgrg46Yhtg9ALfVmO3ybgztSUAcfUVuj13enoRnbJLPcHyAtv2w/lW53inX 74H1aO1wFeaSt6/gB9wOQitwp1zv+T7avgvWf1yup+X6TbD+GXnbK28vP9MPt8cxFOnBLFW5T3kK m8T2Y59qVvbGTs2AmYV9o8dG8dHRGMdlYgGP6x7TaWgYlLSLX4zFKgcz8QW+kuupVSp0LF1zLagy fCCHen0twSw5OjUntFrY3qkp0iLASzTaZ7OiREkijHoaS+2lpaXGEvoA4tKPvmNuL51FCgB3vIse 3v+O3NEiIYVYRCHcehMje0yozXZ5WHKdRgeu2ELRc10h64q9TiiDKUX3rAAyUUWVSnFnckszbLC7 9Xa/lzZ5Sky64FE++6wzNZxttxO1ENXZb+KqiU4gXgtZ7rtPHyjN3zmT3TEYtZbHdnZedIeCAT7h zdd9WvBZXGPQm/zKU654jbcwdp3exTmFYGJ4MfPMSPszQxO8ShB04bFe/GD7Mz2jUZMg6CNjDfzg iHj9dfvGU45w0a9gahnfL5zBcNCZmjpUfmhHIBcP27WgKxvV3cpHoGTuwJ5utm4b/OS14Nq9ewcb jcnBaFSs5Wn+2OBpPdArleEAL06JIC2CQXFQnLtrcuhmfm5667a5ucF8epufPqaanuiJhhqylCYj NfJ6YedO7La9Bw5oulK6eA5KSRZTVzyynKQPCwqqzuKiuX1WEqG0ltC+srgssnPrBKaS5ZUiEOfR K4XtAXkZaigm56oZXk59oOS6ic9vkSSOJOksFNYJMlcoGnHFGwOHBrmkz+L2Cj4TEwi7PfkkTxoN 4J7yEBXX+SrpTjFeDhgCtsH6f9b6GwWyo+d4yWe6UrzRxcevl+b7E+rSa50zV8iW9mjsDuUj4XLD zSUVDjFhZ+2kI5SmuY/uKCiIdrXS4g1AELT8YA38+JhJo24/2z+ThDI2p2Z68dkPSXzn109usobr sZ1bL64Je+ujZQ30ETBOQbI+CfXQgkWwm7CnmpnJyQXrrDsana3XW+MDFp6fzeV5SY210i0w25pt 7Tu288C+hS0cf3Dfzh1j9eokEq1voTZOMsINN6SiVocDKFL5vKQXUti+2YH0QQuvwrrCbVyUJBHa 56tEDpAmnu3qIZK1eemsdDG7KmkoZZS6iMiud1cn6coYphhoc01CUNPqhCy5NbFDX9YV8BUbv0Fv lYMav8fNG2wM43Nki7TyiF6wuKIcJ8TprmhIk9VLT85t4VTRfNn5SZYK9cQ7gUhP2No5pOf7Ch19 rk8wXCloE1+dv20CiZp4DIQ1FqfNn6B15V13D0yDgF6zJpPS1oFCWWwl7ISRoUc+mKuPhJGYARka 7cWvbX+6MRrWoW19fGboKikXj123aygK5Yx8FdcZJJ6F+rsdO9jMPDgFDk7dNoXfawd2HXN6GAz3 9gKeYXILcW6WzyULxRyXSxexWdW40OrBYknUgR0nnefNKhOMGi6i2AaWSCWvMJ0ocFg0v4vcGQzJ qHXxmMx/h7Qa9QQ+pG1r+rWisV0Lq5YVFoqQeDa/6/7pVCvpMDpYMzSZQU8m4Aw69Rpaind+rvFk YvFlpTp5suemLx1oHhoOQ5VkWN7D1CVPLsWTHlBzlSt5O/HcpQO3fPXmsoXhLBa/04Dr3a44Vb52 G/7s1v1ZQ/vZ2Hg5uKI6I/f/+V1Vvtjr5ZJad0qIRZDatV4pwDhDhexiZ1D5S8jXW7CPY19oTmuw cZ46eTyVorRa1/3UvYfAoZ1HT9dArVCY5Y+mjwLqKHU08AmX5T4+QHN8IEBh6c3j/P2qw+f3bjOd TN16azlztxCN9gsZjCbVLsj4FzxaFNF0lmRdES+aZeuI+L+0JP0Gm2helQKa6SgrioSqkaL8ziZO +m22E4pC+pcECz5kG4nnfid7d/dvs6B1V6lSsMfzux6Awk+sCV8MOrll4UtXm0pi9He0f7/FokLZ /osQAXNX200cRqeYwkX8ChOg3TzbPGY2u8Ietyti1OzU3KAhOhrwCw2Y0ICYpqLBaQ3QasBfacAr GuDSkBo+4rJFIi6jkSQjghCivUyE4dU5Na6GX9JKtU2pVAOQVjaVOK8ESmUkFBY8EZrWuCjSqAQM zwpmUq2RcyXoLTvZJZkgAMpIS92i5ILuUhJPmlHvNrjRfNK4pITggbshQlb3d9eEvvHGm7rVFKrP pCUU/wMJsMQKWnKhcDggv6EfIYgKEKQtFEnQYNgMrrOFwlFn5yDpZx0mY7HzVF6rsbOsFmQ/xwN1 cLBJMJdeSElumNcQpN1Cxdh77nEGzDbapObBdeA65IEcsPgEcQFGqL3YDLb7xYcmgGfG/jqRxYpY kMg2+dEiJNVs7wyvgkkY7UmmhZmpqXrfgADYBNlbF/SsEeZiaGpMFv1DPkDngWaqv7cElaGrKvJw KAwUFqV16Vggyyq6mQ2rlD+NBEegOT91Bcx/FPILsByOlbwSbTrKTZ9KG6gXwOd2fXx3NaDLtgat 5kyxlPD6YzGSLg3v6rvJVGHU4XQu4aXjhXzK6ArbnGORymzRQ5U/so3OmHi32BfDw5lWwsYxYk9P 0VodTzkVCsLoCuWHUuJQhlGarHolboUZhs4V701nhkSvSUEQl76oUgmVYc4+PlbEcWTrRy7/RIFD HDawo01uqwiK1iErflAE9UYD8/n9IIBlIF9XXmHca34FctQ+lQAJvw9AcuqETKMxVwblDITTN5xC GL0luSFB9CB+QcZREpAXvkW5uCQH1OfQWtNoQWIuRaw4YhurQCNcEDpOo3LNXjicEEayHSF+zatN Dp+d7h0a5cfu3p7lyqPTU8HKXRUX53UaOY1X7F+8Y2Lfq49smTn1+rUT+4Mu1kIqFRRlUnD449ZY IuGg46y5cesz1+56ZH9fyBSR7OFIwm0zVwYGK/zoA68dufHN0zMBE6lX4wqT34u01AO1dAfEFoPl sD1N+lQSVJKgnHg4gVfC4EEdGNKAQQIM4ECJ+OIzx/yxR2NPxRSxmKPAUDnewXICxZrInCh4WWw9 yIB48b2l7qLAaz0UK2kDwtH6tB/IXFB0QQSrcevj7z46aI4NFWq3H7+z0dmZKPn0Zq4QAhWSj4tO 7+zizjGx/5andpoiEYEkLkzd95XF0J5D+2NQtRW80S+F8OPJkl/HXbqBUCsJU6ix+4Gth54+VgcE ASAq8lCnDsJ257DrmoWQwJtMFori0fuH/Tzg+WRBiiS1Lj7JW3iLixVCJmACGlJwuTQRNkRqBGm1 sfLrp7tIWAYEENtL5uW2QzBkESKyYjfrdkJIwOgaiTwsUd0N2Q/JGFCv5wmRJXllun8i+L1vV5qM AkU2mkBf+WXCnozOZGeHejx8ta1Nw/aqPVKcuPCz1khQ1bmDTpSYzuN8OerovMzGab0hPt26zPvE sgffjPZysPXIovTD1iex7c2w0UiZzUnMD+CfIMb9Aqtx8oIRM2JqreA0O82sWoizSdSZw/hZttuZ c7Hb1LUGn11p8bms3FzY1rWmFtc39Yr+ngDRH1bYYoOFzuci5bBdwfO4MdQqPqLy1gqdQKnhV6vY ZoXw4xfTA0l7514NW8t3/iDeI5g7l2Be6OF5R7IfuuVIf9rDLWv7k+u0vSKCUgqUY2DQCA4RSOkB hjE8TzddwOXq1SFUW5C20yyLeb0WFdJ2WdVfdFoEHik7NJUNqavt4nm5E0tW9vNysiUr+zK2ufWq DhtNdSdlGAm7XQ7Cr1J5hYez1+ePje5/bGdSaMxs2xHh67mYGWYtX6NFzrr1zZsevPD4pvFPfe+B whHJ6jLrNBaHQYUL+Ffye8dTsw/+6ezMfftHRIeesmqAYqCGQ+7pAz2Z/5Uubj51Zs/+Nz69YLNr dSrcZHdpkS10QW1HnqSKHWtWVQ4Hz2htJh5jmEQtG07k+SrLJzDBxPpYkZ1iT7NfYFWN5S9vsUqW FfJZrYpV5yAWXuadtjDrEFA01u07QDEZYsyNFxEe3ltRgaX28idERL4r86v7/gL2q5Fh7+Yv/Sq2 VgB/m6/7SX2wlu346XyC7jBqf6PccRcbPrWabZTATwtNvxa3vx/uS3k4zhoflNo/zA9EKZ5Xeat5 4GtH+0QIFo/YF8UFBCWOc6QGUj9DXAnD4iLkCo1FmnraZOfV0AKZDehx+otnaJzF1vovkb98F7Yk cPWdyu0BFzsVscRoFXQ5D76TL9MKLVMSeXusHsH7/T0iwyF/5m9/M1KP2dG1vZd/gu+G1xaxWFNv 94UxFZ8MY0lWhNd+0eMJnjcjd5MV5aufb583v4fe0NO9nk2lQnb0ithzXfCZD+C7c2WPQqHTWct9 I5yznOV0NsZKuSwmDUVr7S4S1wYaefA2cYbN9PGdpwJ9vTU6PZR26T1x1gSdDmnxmDijV6wHcQFy S7YdkFuKO+Adt2AuPNRqYRWg1YKKVq1Nlyq2klZXqlRgbKY2qYFaR1FurU7L024b7dbSJpNOFx0U +Wg2UKL5KF3i1aBfzLKZFmxsk3RbdKYAz1LBZUjBgK0Lqqz8UN06SEFlxN44qZRjtCwK2RahiaWk kxoYtinuXsKQn0GRGupkVqjV0LnIvRsFBL8w+A1GqCtAsNypm1f4Xal8fdOB3jtAf2P/ZMXR8YRY pd5m7Lyu9PXXO0EkWFnE78XrUSugdH7GbvN4lMQFDjeypbn6sc6ftCbCOoLnGaPGaHZQYEfnP3I9 CRfPe8WqD+9ne9Isx+kCNanzDwAj/ZxgMlq0BLeMR+LrkMNBLN+krJTF4uH9dk9QyXv8GBuAvHrJ ohPsrBXy6WL7rIyM9or5PSetwmPVqxBXtBXX1lp+FQ5T6L92NYbHBX7+0vnV9vwX4ow93hLbjzkD Nq06MjfZeZ9nxSqD9wdqIi3fXRDK/5/h3WWxP2se2k6DBwG4DXoOD01wKQqYKB+FUy6TQsu7cZcr nsuE4gEOZtxmDue8f4KBm7CPYfheDLSwWQzN7VZBZ4RjTBqLm+N4PGQxcSzlATRPkYzXm3G53YoM i3d9LQQF9KWIGkvvZJfMl+R+kcV2tmt/s+cXF1cAIkGjYz67iB5AhDWZtBb/DUaHA5CuRgPYDoN7 AQwXehi10lsrdXoyebdC0Xkh0HlBYQ43052TxSqtJDw9ZeJCO4G/w3mzA5H2j8P9WS/PB4ojUXz+ 0uuEt/2VXJPTQwSkijRO9mwte7nldR8Vj0D+hbE/al6jNaU/jYE7sVMYvg0DEQpglIXiAWYDmPpR AHoBMAM/SAMCAEs0TAfSZjdwmyxAY3HRrJt6oMt7s5sk1aw2cNhyhwXfYQHDFlC2AEuIxbQy4965 KLMoC2P9xjvwKwr6gbhz8exi+7zcVQErz59cTnkWF11tlB6DK3SDu1JtoKfLAw5/0hBsZMARfyFk 59pFXbA333mo3ONVBNLRqAcypwwudm2thimmLn2fULe/h/pvoPvNDCXwg1zMoea6Kw3+RFGEXtsO Y/EjTbGYGkrhwxFQjoCSf9iPF+khGt9qPWTFt1sOW/A5wwG0cOB+Nb6dOEzgJPLhFMabeb/8Wtav 8yqelxxw78sYI5h0cUEpJ4LyCzcufiggXVy0rna1yHm8oth138v5jVExMvrAKzccfe2B0bEHXrk+ e9PRg1PimwQltA5PTBweEChCaYu0Dgz3XTOQcGtB+9BLD01OfeJbR6/75qlpe2bTbV/aYdty7ZEd 1eqOI4dmbcHdB/dPZ2PDiwev7WbIxM0QCTzM48ZexdSwGZxZ9Iu4KDJlu0ngGc7FCDHBpNfn7C7W QRZzArcuyG4vdRO55TTu7EqwDZaTNnl1Lyi1ov3qUHs1XwOvOmf3HNicq+28Kd/Yk9ZyAz3tdrAu 0mSwVQFzGl8obouPSEy4NhoUhmzEBcLENfYMDR/sZU26zgdCT9QOww4l06jgo6neqJXrxBWkRhWo zmQaW7J2tRrJN9y5pPBD+QawGvbz5vhQBQznwUgCHI7fEcf3h28J44NhkA+DAR8o+sA8C4YYUHDM OfCCBcxRB6hbKSJPgbJhm+Faw3GDoqIH21TgIRyGcjYk/GL6hBfc7AV7vGDaC3q9IO0FKq/DG/IS pwkY9t1O4F7CSwS/mH4+jZvT/vSjaSKdbgTRubZvkeBrJPg8CY6Q95CnSYIsCtDxv/9yVPASugCL oTWeJBk7CC3dPG+5v335D/UxXT0IiyLCEB9OKfNrfXnQXauhMwIfgpjC/1zntUcW7plNOZTjD75y /Y2v3T8yP+wR01m2sHv7XOLSXy0D7iMy4OzhgRXAdS7hd95t37T/yJ5x6ug3H5rY9InXD9/+nQEX R9u1vdMpuwJ/67fjD2YBCla25APYp5q2hyvg4TKIQxPFJ+O2ZDIOJB5xSKxlMsmPJcGtSbA7CXqT IJmt1WxZg1ribbTJJuWFSBzEVQAYBvoED+uVnXkywxr0JhYzdJ25+ZdyTkgh07y4hlhRflklYhWF AmxLudvxIs+gDgCVahnAH/LW3UAHIlzRde3A4SgU1o3IEt7OvzFaKauejWesnajUCOjIQCMHnvVP bJoRInk6USiIRgCcsXiaafdZYuk8w8a9RqYwIXoLZvBdlAl1fl2uM0qetyVaaTwsDiTsnMLko5mF amowx7uMis6b3jhrU/HgA5gcG42muFR0J8aLPrXc6zAB47p3IOLHsW+/TOkdYxCqDvQMsalszvlz eC5Xn4wI4bAe7ZutfxX7JoZ/FPskhu/CjmB4CgMmzIe6Iyj1/RSYofZQN1FEjmpB1yr2n4iA6QgI RAAWMUfwSKQsniqDxTKolsfKeJlWC/3j48P9CMKiQIdCfhrlMIi9K1nMojwXVcYvZVm/tQjtI0xo zsnb8sD3OXm+FuBCoZVBPjRMwBIrQ39ysg5zPFa5YlPCKWIF8PLzifineDIU4xZiwWyQ4noXyuL2 gRg3futMqLck2ixuSqfgOFO2UpUEJT+Q8/vKM7nsNZNpbuBgK1JPhyinSxfCn4vvkOJRO5dyh5uV SoBuTu2qJvZsLpotZp2JUoPx/sWegJGwhqrRYE+14mPqY4u17OJQzEgZXXYoDxHa2qch1n3YrmbV x36eAfcwpxm8zkwyuI8RGZxxYOBTODiK34vjGbwXx824H8dxk4Y3O4yoh4MBTo3QNb7tpXe76cDZ 9tn3EN/OZc3Ln2sp/hWRhsymIvGEkVOxqWrwD3X+ithJSlVW8wdSb4QieANx4efFPl7fLgmNpJvn 3cmGgH/XEW9Efw7vXgP9413w7svYNc388QTYmjiUwE9R4GEzeEAP7iNBqeTJYqp0bxaYs/5sOktk s5aqx8+7LLQLlNiyB973NyLQGSI3KAfVKJtY9v3dz9U0djlQ6uYWoQ/nON3UFo0SdUPluypNn8ri DCzs2xv567dIlE/8tNDwa3CTv7qjPzg+1LBbHDpoSStpGB3Tmf5I547q8Wh5KGJ89WXw5W54YE8M ZDrzhmLfQFkw0Ak/XSgWGfC0vxB2yDETCduvkCPi+5uDRRqoaAcdogmnpqiBSqLSaHiasdEakmYC AYahPRSlIV0ejYdMuzw2F/xHBe3RMQGXTQVIirUuR5QrPcMNyA/Ucwftj5xaoGnucmewvBPmFfIe OamQWRSSl+GwWpHRCS1zBz3AJcdFn02ljLrOfyCNGkU8BMxBMcTZO38ndJ60CzwKizhg9djCzvZL OOWN+Fw6t4vj2OqWQttGDEolWoGyLM/ln6hgeInVsbea991uALGY32pleT1FYfpEIpv2P118qYiP F0G5CKqFsQKuKYAHSXAzCVQkIAtFovR07qUc/ukcuCMHRnKglAPXSselhyWiKoFbfcAn5fI6pf8h P0Dv88D1fr2/1MQwLV+q10ukL69T2HIFXS0Zo6CzimOWLrtWx5/lhzSQNcmKK4PPFjnUlv/WfV0+ Qj6yC7IuvmTuob7RZWQhs9JlJzQhcqfJ8jLuMke/QDEOg17/938e8cQE3gbu0dEus8ZgVL337wkY +lK03wiy0Jwn3J23Q50POv8odP7CFRLCbshsQu+w2Di2/S3wxp7moF/JcTjpsOt8waCx/d9BW+0N BI0OhtLiHKekYhPNS238+vZjRKzaH1AjSaBxDI3sJU80e61WPYaRGlKvWfaR2WwcOsQ4qfd4Sa8+ 7fHCNNBrt3s4Ly/E416rEGR56Aw9Dg3QW1nbh2GHQriyrIrnsleAz2U+vyjv0SxDUWbeOt4VCus6 U9TE+v6TfJdpL5PBoNtu+u7zjNfkDlhAzRWJpf2/VDC9tY4rU+f0nf/m9PkjPgRIrc3ijDg7fwkc yTzML0gCheyVTOfJv+d6syzPW2ID0l+Cz3MpWod4UpTfO3kB5jLzzdT9WqBVazSYRwe0OjAHgA5g gCd1NpLUQWbZUQZLaoBAkjBtXTagMGs9iwAkz6xaG26BYYAL7kMTgEBgOXftTgPirMT32jvAx7fs r9D6UOjSAfzPOq9Nbpdcet5LXLi0L1CZTHXeJz5rETfVgR7Np5F7dZQP4iHDxzCUZv7gxQnM1tQC TPBp7E0Ag79/wKCxiufRrGr8S3hN+TjmhPmH1HRF7CBsumDCw1BoJ0IhyXUC+g35pf1bX4grlVjj 3KXFc91coptKLOcQKOpWILe4LodALlLhLG3eFaLr9XLCw6QqPUVbdO+W8iNAY/aJwUCSMauB1ptP snEGcl4R2P/JbVFKqM7eMDh282w5aAxtf+w6S3N8shmJ9U6NVAy52/b3+wsDI8NQEsfx58Db8p3D UNbhdJImDYafMDmtDqAmMQ3QwHt+HsBbvrT4oyU0sQCI7exZ8/msiDoKpCujK3kyexgMCwZ3yNN5 wRd1aTVOaCxtysfbJ5mAifD5lJTfA86kcjqtF17dgj+Hj8Krx7EdTYtaqVJxJ4xGdzKm1cLE3Q35 1TrDxlRoeblW03JYC8raEe02LaGDiMHUQI3ujZXvDeWn0EJkkZlAc8FEaWUEHd3mSt/4SoiH8NCd xSAHgXZwOpLymkmxr0N+9DOzdCBbcoYKIYdKVDnz24d7F6telSs1fXwLQSoNDvMf0tecvmFLKFLi zG4ubHAO9acj1ZbXliy25q8fUCB/U4R4cMJ21bDtzYi35jmhDJwo1ZSlkrJGmBvxuMlcq4GaFzOb MEhkSsJCIPQa2IqRoPW8HbboIgTIueXRIUo6BwMrCU0odMIdqwNt1nXNCa80R70WW8mzUtcmbXKv ofDIyadcgZTPro1omNx0jzBU4g4WKrQyPHFsMtMXNvM2VyKW8NBp3hFvbYkpRKVTKIa8cdpooX1G ylKSBHukIkxO2qrVtCa9fTCmt7l0TgdlpexCxpvpi1BQH/RQruOw/SRmxIaaZgOGVJxUEOCEUa9W qJE4TUatDhNBA+DoKTU09XPr8xhq+aI8a7I7GwKW55Yks/wuBHnCoR0arDxQc1Ctf3TkyD2d58Dd cUUH4MrHO5GFM2cWwH96ovMXSAJVKAFR+TAmYL1NNwyeNScYJowLgtlM8DxB4FYXZgAGxHIcshxb Y7kIFTMLkQT5LgMI4UfNrbI1dCVXFWErLkr/lOm/dVuusvN4o3eTQLkiobCDraYYpSMxdfvcU8qH F3bq0iO7KuW9I/FY0O6gbJQr1sOrQ9miGMCBPI4WgPebhxxjMQkrN50YZjiRSOR9yuAJpy+jhNYx jFmABRkQjF02ICgZOoeGybLZLtbhnUK3tzLdYHVWgUICy0PLa2k7zvVdv7XfxQxIiU01ITK4q1jd Nxz1luduOj3XOU0oTcFy1BbnnHpfMS6UlbfgibFDdaPbW5jO53cOxcTNR5rZw/u39Yc6J80xDzc/ kadC9aR7tJWm5fkxsDVFyH0dtIZGQMD24ZhBpyVJLQFl/w0M5kdr8panb0or0zeRpAFn7aK6iBc7 /7jzf/xM7+Mjjui08uG2Gz9FWISg/lmMkLWMgTwLYyVsDNvUFEwgmRyM2PJQ4GXl4CA3kQdKZR1w ZYzNkrYI2Y+xgEUXJmWjgRTMjAo5bbm4vPIBGpJCU6eggq2lIvKY43rV6sawXWYihwqD3S6Lu53E Fzy5BB3o2SxJs/UgJ5UcaHwp1DefyW3vC5n4+mO+qENLh2OmwkApbdOxXqs5mA/lhzV0PqngqJBY 4YONDONNVVh/IRHUM1KhEowNSV422wdj+3R+lz3Mc1Qk5VKVk0Kf/7jGE85x7kLCW5MMvnA2sB5T XuiVak0P4zyh9Pul2AkDRBcjIlAJFgzzAi9iiaXLEvMqrLoJtShdlGRTU1w/BLWML7AcRKxODy9I fddvg7AavAJWzXvfOAFuhKDiSutAhb+Jx9dAtWsoloagGvvC/bPguCnuCW4dz5shpDwjEFLQGzsv /xqv4f+VUBvHMKy9GdN+A2BWmI3k88hXH4eIeluuHZdr1S9gGhJWojoLBvBRuW7iqroi/FWnXDe5 UhfSLdfp4Xnjct3U6hXRNO/uFavwTBF/F9ZOr5xpWDkzAOvy8pmbVs+0rN4rB2uL8pkzK2fiunX3 w8hnbpbrdGdwgLHyqR/65dnVX/Z2fxmtLIhh6n9W3o3NY7c0ezZtMszn87WpgG+In2fnszG+Ng/J to2hvTaDKmiybcpnTfpJNmeYJof6EwFBTdtVHOv3szjM90XUvSIPXa7NIDyPRgnkiAuNVbfPU5K5 nV2dKQr1FmGBW7cmKXoYAj2qpILhV6AoUYXi2huZu7Nf5GRw7amZ7mv8nOve46d4zlndN3mBFqbF 9hvpOd7xx4ux3Kg6ZFYUvpQ60tvbXSRNafLG/J263R/3mpWE2dRKpwuFEZJkvEOdSj1o1+kVDWkw bvvgn+72xQQh57tZoTdaP7II6pn2zcc5bsti4yudfzcX0FuNap4nrYwVraD2RDKd8nimOt7ddqfZ xPNWHe2dw9BfdZmeALZ1NAc+DekyPonfif8p/rfEceIXireV31aNqSn1ec2IdjPpIHeuke4tg9X4 b017zDSloN61/I3lb6yHbejvC/Zzjp87b3fd4i57HvaqvM8zLzIv+p7yPeV/ex39yv+r4Pu8WWiE nok8Ef1BIpT8luhOV7JHpMX8t4u3lp6tWKqNnvn6q42f9Bb6zrU6rc7g4tCO/4fp4S4Nvz7y1u9K ow+u0jc2aIM2aIN+Bzr3f4R+ukEb9PtHY2CMHstv0AZt0AZt0AZt0AZt0AZt0AZt0L+aHtmgDdqg Dfp9pXEw3ho/M/7N8f85gU1oJgYnJifmJ3ZNHJo4OnH7xL0TD008OvHExFMTz0x8ffKjU8emd24i Z8wzL26e3fzj2V2z720Z2/KDuf1zfzx3af6r85e2/tG20LYvbnds/7sdpxfmF15aLCx+becxSJ1d 0/8X6MD/x/Tmbnz3Dbvfv0a85uQ17+8J7Hl+r3NvaG9ub9/e6b279l6/9669H9/75N4v7/3yvsUN +v0n+a1omPw0wGZwL6bCbsIIjL98Gs18ufxDWFbksufyGcyG2WDJYwSs5WEtA8vK5QVY9lxuwXLb 5UOw3C5/X4BlFDPB2ihGySUPa0V47hlYFmGtCM9Fe3ouS7BcgL8pybUSPIuBJSWXPDwyD49/AJYV eEweHo/KhcvPYUV4/A9haYK/U8TM8MgiPAt9Zy4/CUseXreIZeVjWpdvhOWgXA7L5fjlV2A5I3/f In+fk79vlb9vl78vwLIiX6UCr9KCpRlevfK/mfsWuKiua+91zjwYmJkDoiIgwkiIUUOIAlpFmhpD iCGjsYQYY7lGFEZQGGaG8UVUvL6KRKM1ashICFHDtQjMMCXE5nqNVWNSI9xU/azVxOYhNm39jLHW ksfl3P/e5wyOxtvW3ny/fp7ff6+199lnrbXXXvtxzs4QaGH8EFibAS1DkGZBVwYks9QK2zIgmfFP cn4GT/PRikzexkwK7+1BGoFnM6kf54dAZiaXlglpaUgn89QKjZmQxvgneJ08XmcGT59G+aP0KCx8 Eha2Io2Qf420H556knJQ/jTKn0XaD+lMzs/kfD7n8zlPlCEeIPZXPNi/+TzV8MiI5zkN/1tvkhCp 8hqaQR+pvDaojo6ihXEqr6dEYZrKh9CivjoGGkWtKh9K6wSXyptFj9DDYpH/G6PdovIChWvfUXmR QnSDVV5DyTpR5bVBdXRk0qWovJ766TJUPoQm9NUxULT29yofSg/pHlN5szBF9zwkC1r2X5OZ9Oc4 rwMfof8j5/W8/GvOh7DykBDOGzg/iPOhqg8VXvGhwis+VHjFhwqvDaqj+FDhFR8qvOJDhVd8qPCK DxVe8SHjw4LsN3Lb7uG8KahcYnzI9zjP/qyIFPII5/uDjwx5kvMDguoP5H5Q+Kig8hj+7DzOD+a6 FJlDguokBPFJvP5Czo/k/GrO38f5nzDeEGS/IUiXKajcFGjLT8lCqfDIaKQWyqNiKgKdQuVkB9y0 lBy85CHkXOBZWoDyEl4jBXcepFJcFspF2Tw876YKnisCLULtRUgLUTMP98t4qYX/xcPFvFY5ygog yYK77E4B4OY6ClGH3XPRApSVk+0fsu/Wmhl/0w5m+TxaiDYx3RYaDhklNBd8OZ5hdrgxI0/nbatQ 9VhoLHSNgxdvSFdk35A8jZ6ApLzb2J7Xx2Vx6xdDhh02WOhxaLNx7ezufcATeI5JK0XJUtUTLu47 JjUZJdN5fTcvt5CVt4L50o4yCywcj5UhFXNaOdpo4bYxOQt5bzHfF6s9YeMS3bxPWN7BW1yGu25c rE8tNIc/61Z75WHMmlbEg/KsK+iOg3uvEFrmcokl3GeLua65SG+vV8mzunPR3oW8FYW8bjnSQn7f wftpKbfSzu86uD8UCXNVWUrrWbRavtXycu7NpbynS9CzFh53c/p03c4u+7dk//1euiG9sK+fXTxi 3NzyuX3Re/vWK9q/bdeEIB+wlihtcXN9gXHB5CttLUTJYt7ycj7Wbt9SxdMFN3m1iPdsuZoqrVL4 hcg5eGrh1i7qi1xFDqtZihp/tY9+akkdNTrVkldcZJlSbi93L3UUWR4qdznKXQXuknJ7iuXB0lJL bsm8YneFJbeoosi1qKgwJa+krKjCMrVosSW3vKzAbimpsBRY3K6CwqKyAtcCS7ntf5YXKMy4VUZu 0byFpQUuy/ApJXNd5RXlNveI6UWuCjxjGZsybjSvjtq88rQnpuT1Sc9jSZarYHGJfZ7lcZutZG6R 5T7LE+4Ce2nRUhjhKqkotydbppfMdZe7LNYCV2GR3W0ZPT4t9enyhZaygqWWhRVFFncxGmErx52C CoujyFVW4nYXFVrmLMWdIsvDT1ofxF0Xzzhc5YUL57otJXbL4uKSucVBz4KW2OeWLizEo+5yS2FJ haMUCgrshXiqBBXmohbUp1gsAeXl9tKlluElIyxFZXPYUzdk2QO1b2sSr17I2uwqqnC70Dq4Kkg9 Hu+TNYFbMLwEWtxFZawvXCXQWli+2F5aXhCsFEYXKKYWuSxobzlUIV3odix0WwqLFjHnok5xUanj lhZhAi7nQ7EAQWdH0JezgSiYEWjzkf89n4QD9wPTaqEyXWo8mjbNf2jeAn6ueVPTHCSL1S7py3/M ZRfdpKvoJmlcnjZeO1r7mPYR7feRjkftAgwONuyUhaBY8AmvYh/HJoMHUd+FQWTnMvr2lSQPRfXb /9MQ20H1I0GW2dpONEW8mCqSZivRJJ3OirxFCe7APxn/6Adyb96UqbmjRhGtU/aKRCZsEyWR7Rme BLeBBHGj+BJpRI/oAb9D3AG+TqwD/7JYD/4V8Qr4L0Tsm8QvNbBAE6nBHk3TX5MN/hHNY+CtmhXg qzRVJGpWaq6B/7PmG/D/pa3AvsWtdZNGu1C7FHylthL8s9qfgN+ifQH8Vu1W8Nu028Bv1yWToLtP l0oaXZouDXy6bgL4TH0WCfqH9dClt+qngJ+qfwr8DP0M8E/rfwQ+X+8Gv1CPfZN+kX4x+CX6tSTq 1+l/DL5avx58TchuEkJeC3mNNCGNIa+D7zA8SKJhkqGONIaXDZexm/rccA38n0MhOfTp0MWkCV1i xC7VGGY0k8YoGYeDH2HEu5gx3fhv4PcYfeDbjL8Af8h4BPzbxvfAHzd2kmjsMn4G/vfGSyj/v8ar 4P9k/DP468br4P9i/Av4HuOX4L8yomdNZDqEndth01Hw75i+AH/V9CcSTdfM4SSYI8zRpDHHmJ8E P938L+BnSbNJkAqkAnTqHAkeliql5aSVVkhvgN8nHUT5L6S3SSMdlT5EyXnpPPjfhqciFrRqRIg0 lPeR0jtKv6g9As/kwid5BnjbMMMAnxhmGmaBLzDMRWozOJAuMixFWmlYhrtVhn9FusqwCiWrDavB rzGsA/9jw3rwNYbnwG+Gt5mfr6peFeHPe8EnG/H+axxlHMU99gfwfzT+kXvjCNK3TWiF6Sg8w/ww EGmUOQoeGGQeBD6aeYa3JozeFS+TrsBVMIcsc5e6SilvnqtoAdmKi+a4aElpgdtOa9ifCcx+MNdC cU/mZrG1lPi40pGZ/T0FzutJUv9GuAbvFuEUzf3F8lr+hhRBMUElAt4z+lFsX4lAkUyHNW+yheLz ch+zsL9MzmuyvxjSX/3r4VrINtIA9W+Ha3GZaCANofi5jgoHdfD0IE+P8fQUT88vKHLZ6TOWCsTT aJ6O4ulYnmbydBJPJ7MFUpjK0xk8ncPTUp66eLqOp008PcDTE2ULyhYIF3l6mafXedrLUlHPU4mn UTyN57NUIt1FSXfAhdHdNIzuQQ+MoJF0L7x0H/Zwd14eeBe+fcoiQ1TfzL/NCehf1qN6UAM0GNEL ZvQ4+2OSkeirAeiTKMRCNHo8Fj0Xx3qIErCvGfo/PPf3lonocd1taQSi6W/RefQ+ncE78h/oKn0l iEKYECnEConCSCFVyBAmCTlCrjBTmCPMF1xCpbBKqBG2CA1Cq7BfOCacEM4Knwg9YpyYJCaL6WKm aBXzxVJxmbgBs3+TuE88Kp4SPxAviJfEa+I3Gq3GpBmgidMkaZI16ZpMTRbm/DxNvqZQU6pxa5Zp 1mg2aLZq6jS7Nc2ads1+zRHNcc0pzQeaC5pLmmuab7RarUk7QBunTdIma9O1mdosrVWbp83XFmpL Mfcs067RbkCrDFg5jvDRJIzIZjkS04+P0cMnKBlTCg+CjqtWaMZBZQabUKfQaYkqvabQ3FyFPjFK oQVJCp1jUukVhc6fSlr2fW/+GdIjXIQl7aRHWAjPximWLDvNLRGWNyn55adVekWhK2wKXTmV19Ou sq2qXPX8qp1KbnXE6qTV41Zb1dybq7tWf7L6upJbs2/N8TUfrbmmPL+2Q6Hrdir0x8t4LUP19Or5 1Surt1c3Vx+qPlN9mZeGr29af2D9ifUX139VI9Uk1oytyamZVeOqWVfjqWmtOaRY/Fwcj3/huUkK 3XBKoRt7cJ9I98KxFy5tlbaO2pqr5LcWbq3e2rz1/a3XlPw2w7bkbdO2ubfVqvnmbSe29WyP356l 5LfP3L5ye+P249uvKvkXDS+mvJj3YuWLDTyvfbHjxfO1+toUJVc7udZRW1t7UM2dfUl8aeRLimbt S6UvbX1p/0sXmNUkvNSrUI9epZLiEU+USlXP1w1T6Msepd4rkkrZ7obRqUp7X5mt0lKVVqq0WqXb Vbpbpa0q3afSQyo9rtLTKv1EpVdU2qvQBpNKY1WapNJUlU5UqWpfQ75KbSp1q3SVSjertF6lTSpV 7Ws4qlK1fxtUuxouqfS6Ql8llYapdIBK41U6XKWqna9mqjRbpdNUOlOlxSpdpNI1JNyljMLzwlHh G1HEjNKoMWiyNQ1au/aULkO3W9eqO8KvLl2XfgBPE/XD9Rn6Yn0xz2XwdAuuM/ozIfG4doecCOnh ZcijZgarpVyG+JAThmLDRUNPaHaoI7Qj5ETolbCosLiwQ8Z8o8242dhoGm5KMblNO03vmq6a48yp Zod5J6495j1SilRo3iltCdeGLwr/LGJVREPEgX4WdrdfZb/PIkXzzsg4YFV/bX97/28GHBoYPTCH 3R2YP3A+0mtRrYMizDsHLRq0YVDHoGvRUdGW6Ozowuia6P3RR6N7YmJjJsYsimmP6YqlWH1sRGxK 7LTYWbHLYrsGGwbPHLx18Om4ZXHHhkSjpO8K5FDDgBrsOq1ccceUa0g0u1DTNqQW6BhyiqefxFN8 dvyG+EaWi2+Mb8fVm2BK8CdcSLhgqbEcHBo/NH/o8wmmoQfjey01Q58HTiTGJfgTXZaDiXsSzw49 OPQgqzv0BMqvYHViJxzsfGM8+7YPZMrtwhfyJuFL4Gt5kygAofI5MUxuF8Pldmk26gj8/COWn3+w 04/xvT38/IOdfrCzD3bywc49OuQh5o3Apt4e82Z5pHmLnGVuBy6grBu4CPwOuIx7nwNXgC+Aq6jz J+CanAV9Q7A/Y+cn7PQkSS42VwI7gDrgZaAeeAVoAF4HOoA3gB5YEs1PGdgpy3h2UoESdsrCzlg6 IH8jsAnYjNpb5DTYlgbbsmBbFmzLgm1ZsK0YthXDtmLYVgzb0mBbGmxLg21ZWN2ZBnZSw85pkvBE JbADqANeBuqBV4AG4HWAaX4D6MHTUfxEZzw7IWGnG0C+3Aq71sKufNi1CXZtgl2bYNda2LUWdq2F XWth1ybYtQl2bYJdm2DXJti1CXZtgl1r+RnSOX4ixM6D2GkQOwuKZydW0MbOgthJEDsHYqdA7AyI nQCx8x92+sPOftjJT77sRHvyzcvkc+aVQDVQA2wDdqC8DngZqAdeARqAV3FvL9AMtACtgBd4Hfc6 gDeAfcj/HHgT+HfgMHAEeBs4CvwGOAucA3pgb4zSGsQZbw3oELQonp2zgc+C5ycDVrQ7F/knQWcA +YitSsTeDqAOeBmoB14BGoDXgQ7gDaAHz6laoIGdbrGzLXayFc/O+iCdnWyxcy12qsXOtNiJFjvP ykdvVELTDqAOeBmoB14BGoDXATYS3gB6ICdWiRjeliFqW7KgJUvVksbPu9hpFzvrYidd7JyLnXI9 jbi7E00iPw/rICf2VexMjJ2IsfOwHF5qxX128sXOvfp9J+NUI0nyGSkGGCyfwSyB0cjefJBOh9an mFbwxjtqQ5h4n5wmjgWswA97q8Q8jLwhwDAAo1l6sLdKYl7r952M537fyegb+v/FqDGif8PQv2FC D1mFL3sPY0aXRKH3sBgr7zN/3XvY3Nt7WNIB/XsPUyjm/HrU6MScX4/53oP53mP+Wq4398r1kg7o L9crtXDXhru2W+/29X0kWxuEZLlZuE9uFnVAqJwghvX+UgwHouQKEWNXTJIrJFFulkIBs5yA6NFJ 4eAHATHgB8s6SoCUHEgZJKTIacL98nRhtDxYSAP/Za8P1hLa44OGHNEMRCBGIrFi9QeigVhgsDxL HAJYcO8e5Eegt/Ec7CZoz4HtBAtyoHmQFAnaH/lBoNFyDt4X4Ieboro/X/U65ITvpHVhTBoknIOE CuiaBK9OwlPn8NQ51DyHmpNQcxL1g74K6KuAH9rhh3b4oR1+aMfTFXi6EW1vFwcBMUACMAy4Fyu2 KHshzQtpXqykGvk9ZvmtVv9NS0MRSwmIpQT0fzb8PhtRkg0/zoYfZ8OHs+E37L4FtrKMCFp7stW1 pw4zXB00n0MbzqENFWhDhTAKGA2kATxG5XzIzoPsu7hXzEAE2tcPiEJERqNNiF30Zzt8vA99WgE/ 7xPvRn44MAL5kXI77MqDXXnckzpQ5s1IoD945tVo2DdMnYe/gpWsZSKszIaV2f9wxEXJo7+TqBPR dwfQdwcoDDYshw3LYcNy2LAc+pajh89B7nLUWg65y1FzOekCI/amaLWwNqrtyfmnjCABffwhojdF 7oDuDujuQIzMh/4O6OqALh/81gFdPrSrA/p+DH1vo3c7oI9FcQf0daCNHWSElMuQchJSTkLCZUi4 jFg/iZonxURgGPIjQO+VL1MoZF8WB8BX0aCx8u8g9zLk/ka8C2XDgZGIgrBvjafAOGJjiFmQyOOq ndc8GaT9JGoGaz6paj5JOilJ7pZSgNEUI40BfQR7i3DEWjfW+276qVxFTXIn+eVOKQGzRJJslUb2 fo4nrNJo+T/xhFUah/IJwCPIPyqnkwlrXjdqerDudUvDgZHgU4AxQCby3wd+IL8nPQipWXI3CdID SIdirvLgWZs0VG6VEoEkuU66G3QYykaAjpT3SPeCJgP3ASm4fz/oKLlKSgVNB8agbCzo94DxQAaQ iecngj4oV0uTQB8CslD2MGg2MBl4VH5BysHOwwwL3kJbvdD6FqxvQzs70UYv2uiFpLdgfRvsbYS0 bkh5C+3uJCOeyIO9MfDOUtgVg6eegy0xeDIPT+bhiWLUfA56YigOLbWKaL04GSPhMcCK/BRgqlyF ncMvxadwb6bcLf5IrhWfAV8MugC0FHXLALvsh51WaGVetsJOq2qnB9qYl62w0wr7rNy+ODED0h6Q /eJESHmYa74KzVehuRua90Hzx+LjKP8hpOeh3tPyfnEW8kW4XwbJQ6AxQb6KNvqh0Q+N+9BOP9ro h9ar0HoVWv3Qug9a/VxjVZBGv6ppZpCWF6DFw7WU4V454OSaWPSsVqOnAb1eBU2r0cvd0LZajaAG RFAn+sDPIghe9WCWDIdv+wFBUQsrhsIKeJvSYIVNzIaWySh/DPRp5GeCz4d1s8A/IxeKc8AXgbeB zgOK8ex8tKQM/ELQRcASWL0U8fP3jogQrn0KxYhPgT4DWkBpaFsX2tHF78bAtu7bjsVoNU6YxZ3w 4Yfw4afw3SVu+Y9gyTOIDRYfZYj8fyR2o+Cf1eilbtjQCOmsd1j/+wP9/w/3yOA+u6fIv0aENUJy N3wQw2P7GWgoAC1GG5TY9qMNNnEx13jn7dBDAxsxTPJVSO3kcctmFuXOM1wXL0Wc+fmdGMSHB+33 qFGK0YiyKfJGcSro49g7/BDlT8tl8EW3lIB+YfPacKxZgTltFHSweW0c7k0Avo97D1AYfHEJ1n0M P/wEa1u4TIhMIrz5UTzQhDjI6P0Kmm3QvE+NAJs4GZRZYOVWdMLuD2FFOSyoggX+vjYsxvNL+Yjs gkU2WNQJa2xq5Njgqy74isVXJ4+i2L52Psx7oxtS3+Nty2M+gzYWlQuAUmW8w0Pd0BJzx3P5XWgr +y9B0zAKPRiF76maq7h3ldHXjXad5BGmjD4Pj4U54At5xHkw+ticZxNLUD4fWMBjw4M5wiNW8JHo CRqJzA+LYSWLyipYVoX2L0b7F9NorGR+rGR+7Jj82DH5YRW8j/mBzw29S2HZaIwwFvsxfDaeiv3w U3xuiEEsVcG6GPFfMAfM6v0YVoaJs8EXAHOAuahfCFqEOjbQeUAx+BI+Z1hhdRgsThMd4F1ABbAE WIp14U7Wi4HqXGrtixEr78VC9GAVLGUWsJWzU43QavRWJ3rrE0iuhtTqvujMRPn3UZ6F8WJSZ5Za jFA/2m3l7S7mcx1bWfzqqPPDHj8fYVred8U8EpS5SyOWQWogl4h1jdmz9p++iqdwSzLkPfDafIyw KrTVD++1IgJbg2ZTG8ZBGbw4WO3zF/7plkfD4jw+GylzQhXv76kUBktrYeFP+mblf3Q2YnOeX515 nHxUBiLqcTmbz/1Mw2yU/W+06MQiisRI6MaM8h4iqhYzSitawWSzWWw2b0Unxs0lvraWA5iVRTfK liLWwtX9T7f6xDU88TbfjdgwJxZjhl+AslI+n7+J/VB30NPdZAjsBfC0h+srggU2dfZk8kWswTFs HsX7Imv/TGJ1u3npAsyubA60g1d3JVilf6SuIawGk7IA+3Lcgc5u7OBnITcbYHdtWKGLYV2Z/H9g 2VXU+jVqfUgmzD7voV0fQ1Yn39cp619gb8dm3k/xBJt9fWwdhJUz8TzmYYzWWWg/m6Vnq7syG94P mKXKc8yD7Ln3WG208Ddk6GuPUvtjtSZvj9Jy3urA7F/AW90d1Opfc81m+NIGX9r6fDSb147h/YfZ QJyvrh1lfM1I4z0Q3rcOYAXBzNvN17wbfVqlRgHrmca+nrGrvaNXo1xZre3wpVP+JZdrUmX4g/zH 1oe31Vjws70xanvgcT/3ocBshSdLeXkhenKWvB2a2yH/HDRf5vLL4XEeObhbGxSd3dxrgRqIMdL0 tawJckOQG4PcGLSzE+3sVFcYP1thaADp2JdBoB24+ZQh/698vcw3fw5cAb4Agr5eBp0w7MWdOzlh YLZkwZYs2JL1XZwqcFuU04S97Pv1HZwmRPxvv13yX6oEnxh0wfddsKOY2lDm56cb//zvmv1vOQlQ rQTfZ+UdfPXvf8sX/zOQdgZtzoK0TZC26Y6+V/e/5ct+sG1DIG3IHUkzIboSEF0JiK4E9tVREuV6 KRQw401Ikiep3+nYl9dUabCcykcO/+aLFoSZv5aTzb1ysqQD+svJFHLTF1sJq43y1daDZz2kgfTX IP01SHyNS+Jf/CAp4Vtf+vrd8n0v4DUWKdloZ/bf9Q2OSRGDvr8FpIiQkgApTG8qpKRCigdSUiHF AynM7lRI8UCKh/S3+Q5diRZV8hMJT1/7Im987QO90Tdf/VVt4fKz39KowerN3k4/x4r9ORs1vd2Q 23nT15294NuU92X6D5Qd4F97OrEP6sY+iO3/V2Af1I09ENv/D8UeqBt7oG7sgdj76grsgdg760Ds gbqxB2LvhCuwB+rGHqgb+8dO7IO6sQ/qxj6yE/ugbuyBurEH6pbYO282f88diD0Qe2e0YQ/U3fcF 6fgtbx3HIfn4bd86RiD6qhB9VYi+Krb34/s4pQ2BvVzX39jLdfXt5UZD+o39XFfffk5pi7KnY225 sa+bctt93SOQo+zt3uj7tnSJWzUMdLj8KX9fY1IVaZfQrk+D3msv8Xe3QfwdRumzW99jLqHv/EF9 Z0XfXeJfhZLkuXi32It2zeXtGQMa+DqkvFt083eLcHjOCs9Z4Tkr+y51R9+VTEHfhS4EfRe6AH0X bvtdKNC3F9S+9fLayo7ygtq33pu+Imil4fDSaEqTvg/6CPYtkUHvOh71XWejujPdpb4De25559mI HWoMYmYLe/dhfuW71IE33szhy3gAuxSMaqID0DcEtRQtNmkYf8+55S07oIHvgRGJ3D5lx3TTOzAk pqF3POid9+At5Y068BY9jo8MJeoDrfKprSpELR9q+W5pTSF/g9NBVq3aP7WQUav0Cd+R8Hj51q7k fVgy5pZ4eZ9EsmFXw/67wwHE/vubJGK/9xrBTkfoflxa+CSNdDQGl56+hyuExlMGdtmZuMLYrxnJ SE/iMtHTNBPtz2e/VaQ5NJci6BVckdRMLVhxXqcO+PxNXIPoMB2haDqKK5bexTWYfo8rThAFzK+C VtBSvGAWzJQghAvhZBFihBgaKgwWBlMi+/9n013CUGEoJQn3CvfR3cJ2YTsNF34u/JxGCIeFwzRS eEd4h+4VfiX8ipKFk8JJuk84LZymFOFD4UO6X/it8FsaJXwsfEyjhU+FTylV+EL4gtKEPwt/oXTh S+FL+p7wtfA1jRNJFGi8qBN1NEEMEc2UKYaL4fSQGCUOoixxsBhH2WKCmECTxSQxiR4Vk8VkyhFT xPvpMXG0mEpTxHRxDD0ufg/70B+KhWIhLRNtoo2Wi8ViMa0Q54sOqhIXiUtonYiL1ovVYjXVmCvN lfScucpcRRvMa81raaN5vXk9PW9+zvwcbTJvNG+kzeZN5s30E/MW8xZ6wbzD3EBbze3mN8hj/pX5 BNWbPzCfpwbzBfPvaJf5svka/ZsZ+whqNX9t/pq85v8y95JPEiWR/JJW0tHPpFAplF6XjJKROiSz FE5vSJFSf3pTGiTF0H5psBRHb0nxiNBfSEnS3XRYugcj821pJMbDO1K6lE7/KY1DnL4vZUgT6VfS QxgPZ6RsaTKdlXKkHPqQhLDjRhZZJiGKJhE1NQN+Erw9oPuAA+B7QY8Ax1TK8H4Qfxr4APgE+IwE nxb0MnBNxVcK3Usq9ETrjilg/F4TngkLyutJWDZHob4I0EiitRdBo4F4ohVvojwKfBIwUn2G0VEc gi9OvTeKt4XZdCuYjdxOP9r2M9BlFtAwEn4WAUSJZa0ftL3f+knb6aaV3pkcPu9mjh5ve1Ovt33v cO9xDo9vGEPzCd+h5jO+Qy3jfFkcOQpaHW3VrYvanm9K9kY3pXrjm8aBPuCNb41qW8XQlOVNasrx jmwtRL35qNfkXcKRhXo5qL/SO4nD513B0LK/zdpyqC23aZ13MkcH6jJsAM+wHzzDDTvfZAjKH+TQ gmdIAc9g9f6BI1fFMrSLYZUKv+8Bjn2+LCCnL38A+QPIfwae4bIvnyOQvwYeaCaf/a9C73M3m3yV zZN8Wc2TgUjko5GfCj4PWOLbwLHCu6R5jW9Lc7uvg6MG+c3IH/ftZ2hJhd8ZitvCOOy+LRwr26I4 NrQN56htS2doOgRfAS3vts1o6WrLbTnVNqvlbFthaxz6h0HtP9CtoJ5AP6BPJoMuad4O1EH/m76O pmnos+nos3zQOaBZ3lHow7GBvmxNhDyG4SqWQfYq9PkWyGJ4F7Yw1IJn6ALPsNI7lcPnXcOxzpvH 0eGt4QjUP4W6p4KeD+RXemdz+LzbGfaGod8Z0tHvDBHgGTLAAzdiZY+WISh2jnJEgY+6XX3vCY4Z 3iscVu91Fd9wzPCJHLMQXwxWn4GjEDzDfJ/E4fAN4KhG3DE8r2KZL1lFqopxKpT8VtRhaFARiNEj vmkcN2J4Okcgfww8w40YnsMRyH+FGP4qKIbjEZtJiM2ZiMvZQbHJsN1Xi3io7cvvBL8zKL8H8bIH 8XKjfj3q7+7Lt+J+K+4fRGwzHFXQku/r5ZjTpmXom2/UeG8+j/gHWh5AHmi+gDzQkoU8gLHxLgPq fsTQfB3Pf4Pn1XmqRQRvAKaBB3C/C/e7cO8i4EP+FPKnwF9qyXk2sUVC3QG+Q02oy9A33twYawyB fCX4ytvmIzjsvnqO2rYMBozFFQwt9RifDLtV1LZNZMC9GoaWJpQBQfPYcYaWS23zW65iHPe0OVp6 2xytWiAwlgNIUZGuIkPFRBXZKqwq2BxQ3dbQ+jzoVozXs7ARaM3FPQZPWyPmhmZQP6fNbUda/W3H WveBHmg7FhRn0zhuzI3FDM0jfe69Wj7XrcRctw7zVFxrWNui1oi2Zc1/QD9d8R1q/aztg72LMEYY 1PHQ8hHmqotthQGKMW7j8HnrODZg3WDYD3v38zkrsJbt5FgHnqEDPEO9t5TjEJ5lWOl1cfi8ezh2 Y05hOIs5BdgbB78zTMQ8MPGmeUBZG2f4YjmsPgtHYE254Y8sIKd5FMbTWLTfhrgrBTJvGV+B8ea6 Zbxt9zVh7PiC8ruRr2+JRWxagMBYUH3YMh15AGPnLMbOWYyDq0BPyzqsCwxbsC4wrGxL5NjQlsJR 25bNEPBLiw+xBzR9BD8ALR3IA00XkQduXXv2NqLNjerctDWo/e+j/e/7coL8doYhKH+eI1D/NOoz NEMGQyLqMGTD/0BTMdYZuzezyQ1a6c1EPFa3NiBeL6HvAZ5vRP4q8ld5fh/i9QD6tpWhdQZimWGW iiOI32OI4/dBT7cdC7LrAkfArg9gE0Mg/wl4oGUY5p9k3/5nJ/qyGFod/sjWRf5o6KphCPRT4H7z CX988xl/Uss4/0jsoT7yj2qr9o9te96f6V3BMQn5ybC/A/YD/qnI5yGvxjf7uxf8F6jEf3tq4L86 DdWl69JJ0o3TTaBw/tvQ/vqp+icoVj9d/xRZ+K9CE/mvM+/mv61M4b+YTOe/hszkv4N8kP2iVvxc vAK5CZpEEjX3aEaRXpOmGUsRmn/VXKMBuuG6ZKrWZeon0Eb9A/qHhI36fP084QV9ib5EeEW/QF8q NOhd+gphpzHUGCrsNrYZ9wmvmQSTXWhhv8EUB7PfXYr8b4Ww/wcSpau/SbsfunXSVmkbkVQrvUSi dEI6ibfv09KvSS+dlc4pv+Bhv35Vn5yvPjmKeUMzBjaSZr2mBlZ/rrlKWt1k3aNk0Kfqx1CYPgP2 SrD3BxTBdURyHQOkOullioJF71A01xfL9cVxffGqPkGshUf63hvq3UAlCbsOgq4E1oE/CroB2KJS htogvh7YDTQBPtQ/DtoB7FdxSKXvqugiqtyigPH1p/DMiaB8FwmOkQrddQb0LNHSVtCPALw/uFah /Dz4S8BV9RlGeziEXRfUez28LcymW8Fs5HY2om2NoOV4n2g8QULjGeA8vPMAWWk6zUY/uGkFVdMW qqNG8uHt+gh10Rn6hC7RdbgwTBggDBPGCZMEqzBTKBTswhLSuKJdJle8K9KV5FxGorPSuc650rkB nMO5z7nI6Qdnc7qca5xLwOU7d6NGPbhc5yznfGcDuMnOzc7ZzjpwDzhznNOdteDSncucVucicCOd Y1+TnGvAWZzFr2mdc8BFOROdKa8ROJMzz5m0+xtww5ySM9Y5AFycc6IzwpkBLtrxlVPvZPUGOJMd 3ziHgYtwXHRcdVziz0Y7PnNGkug46hzmOF92Adx+53DHKWciaWFznrPUORPWzXZOdTSiZLYzEqXR KI13usoaUft5h8fR6EAbHGscxx11jqOkcYY5eusinVpnlMOO8lLHkrowB0a5Y46jqY4cu8HNcBTu uO6YD26qY/uOS47N/w/nAAP/5Trx36yzX40/S6H6Ffq1ZOa/4R7If4E9iP/GOkbaJ/07xZIg5AnH MF5MdJEwDndMA6YD+QDeb3cUA3aVMriDeMTfDoyjHesAjJUdiPEdtSrqVbpbBcbPYrsCxu/wBfEB YFwtqgHFeNqBcVU+CxRjakeXep/RUyreVel0Vfct2LUT2ENUinf/Xa001j7JPhmYunCOPW9hsX2m fbbdZi+1TwVcwBL7Clxr7DW4Ntu32+vsO+17UNpqb0fJHn6XXTX2N0tj7TULdy9sWuhb2FE6zJPh meHJ9Vg92Z6Ju1J2pe/K2DUR/dAf/YtRK14T/0yi+Bf0tZb3tZ73dQjvaxP6ejyZdRP6ejwCPf5D GqR/Av0+mPd7nH6mfibFo9+bKcHYit5PQu9/Q/cYexEDIxEDP6JkxMARSv0naRVoBtXz+HmA/T2G esRNPeKmHvFRj/6df7Rv3lXm3GIFr6Ls1UoylQ0vS5k/EWl6Wfr8andS7dHa46+2vtqO1hjFP4l/ Qmuui9cxm2foMML1uf/N3rcAxXVcifa9QsMMAxhjjFkyHhGMEMYyIQSPCasoLChoMiBCWLh3ZsBj mBmwrCUYa2WiUBizMAzzZ34QohAVT48lWhVRKJ6WIoQosoL1FJVKS2RFT0+rqFiiVVhZRekprKIl ivJO9713uDMCS8nmJa9qU12n+9zT3adPnz59+sNwr6QKbYK5oENRklqYEZvl35F/B0nkv5H/BkXH 1cGMkMZ/ADMihswI+R+IC5W48owWVq9Y6iRqRqgHbK8HbPFAEgH6nVJ4BlvsAV/eA368B/x4D/jo HhiLAzA3emCm9zwEvIsDSxRPh3KWmBBQzmpEv7nIwTvlAFVAT4BUu0bfCN4xAJifoBz4oXdaAdrI M5ELgyWZlw3LokD0395D6M2OsLpcuXQox0B9Lg9Zsn53gDUO8w6BwNeSg2h/AcDOUJ+xXkPtW2DH ceAAAfJ8YO+GQPKhHUjp6902+1Gvv9tjP+4d6g7aT3gPdx+yz3hHu0fsp7zHusfsZ7wTQD8P9KD9 onfqjSX7Fe9s97j9uvd096T9hvds97T9lvdC90n7He+l7jn7Pe9VKDkD5cfsD0jdGe9Ct8dBQ8lz Dqn3JuDx0Na8IwnKXHakem93X3Okee92Bx2Z3imIkyBedGz33u9ecuR5H3YvOwp8UXtjHTt9Md0r jl2+hO5Vh8aX3IOg3dkeiaPSp+iJdTC+9J5ER50vqyfFYfTl9Cgde335PCUDHNftnmzHAaBIII6B uB1qSRxdEOc6rL7CHpXD5Svq2eHw+0qBfxfwlziGgGex47D3ao/aMeor76lwHPNV9VQ7JnzaHr1j yuvnYqy3zvieeqyxnibHLJRvdpz2Hu7Z7zgL8VHHQ+/DsPi4MyoUH8Ux6Z2554QzBtoVxzMkPuVM gF6cciaTOMG3r+cMoZx3KqBHFyGOCYuvONNJnAXxCWcO4bYWz5D4ujPf19pz0HHBZwCdY2lvOAt9 bT0SzKFX68r1S3o6HZegjxbSU65HD5xVvu6eDKfWZ+u55SwCbTRDH6egJC5T77gKGuBwh2MBcI7i ddyEkeLiQR6/DfGw4y7wFMdHHPfDYwvtNPiyOBvjRtMidZq9Ny3xzn2+IkuSs9U78cZlZ5tPy9kt 369hqDvVc4dIeM9Z+tZ9oJf7Oiypzg6fB/TQ7VNY0pw2sGSwSV8Qj37HdM+w0wMtZmJLs2wneJ4z 6IvirM5SgPtl2YlHEM+adx9g+3x32LILJB/tXnEeAssMzR3fIWyleyWcBiwaPI6WStwLC+McwT1y juEeOcfXeuechN6lYvux1OGRtRgJvpeM8jDRPxlfS4tz2nvWstN50ldoOUDwdoJ3Ec1YsWbwLPON EHseAy3NeYcsLuc5X6nFT7Q6RGzgCLFPYhWWw6DJ+5ZMrEnLKNaq5RjBJ5zzvnHLlPOyb9Iy67zm m7acJno4i/VguYC1BPoPglSXiMauEnyBjP5x5yK0Uk/wo8SSHWSOHCfa2O7sIK3DWPQ0E3wG49jb dMZbbjqXgD7sXPZOWW47V3zprcvO1bduWu46y1sVvBUl4llguU9wbkZwdpWIZwr2VJ13ic2ctDx0 Ie/p3iiXxJeDvZZvDvuHzsreGFdsqwLr33eOK4k9mG8e+4rOSs6bEb9xuTfBcdp3rTeZzC8yFr0K jGPPBtywD1nsTcf6783C+u/NcSX6lnrzXSm+ZTJHDnPzrrdQhBet6R/7w8544nlWektdSu/d3nJX BrS+ZsmrvVWubD/q24lz+3bh3D4NwSsJzhC8TlzLc9JX1R10qaAViWsHSDvvugded9X1AFoEGw6c xTYcuMDPdOKdOOvtMzo0gUt9ex1XA1d5X8TN6BkypkTPfS2Cnt+9jrUXWOg7YJ8J3MQ+NnCbn9HE YnHvAje53kFb90O9Bm8fuMv7VZHMvFfhPAyRzaIhntO7Nu628jX+tirM06bFPFsXXcX+WGusO89/ oue6S+1r7TW4KvyJveavjPlTeve5qoFidun9KXxuq6ve19bb5mryK3s7XM3+jNZl137vaG+366A/ G0p2kloWKGlzOfy5rUtkZD0ur1/Vc8816N/RG3QN+4t7D7mO+NW9I66j/oqeRNdxX1bvmOuEvxrk mXnrZu+461SronfSdcav7512nffX9550XfQ3QVtH/M29c64rvg5O8t5zruv+/b3zrhv+g72XXbf8 nVD3jq8D+zG/xWZwSINL3GrVe81N+x29i26p39u75ErxD4JsnSDbsjvet4xx/3DvihvW2dZFdypw XnWn+Y9YkTvTf5RbYbm1zCpxb/cf5+Leff31vlZrRX+T/wSWKrhsM/c3B1ds+/r3B1dtrf0HB5Ct rb9zQGLr6LcMxNq6+x0DiTZbv3cgxeYButIW7B8cyODWaNuh/uGBbNtI/xFfG7eL4NZr25izYyAX xgvP/XrPovesbdyz5MvHuwWwB2I/MFNOA37FqQjctk06tgfoNy47JgIa2zSexbaT/UcHVLa5/uMg 1bn+EwM7ME9iD8DTNu9I8yfaLvfPDBSDDYc8Krc22a4RW+LWKW5FJj7KtojtHMovhGxe5E/ENm9b WvMAYs9sW8be2LZCvDHx0rZVjPOe9ijxtEbRrBd5aTvqPzWgtkv6zwxUiP2ePbb//EC1PbH/4oC+ d7z/iq8Vj91APR67gSbYgeDZcdXxcKAZz9xgEb/uNJPZMQNSJYtnkzXRXeA/YU1x7/TPQLzLP0Os q5Wnk7jnulvj67Aq3ZVAJ/PImuFm/CprtrvOf4qPc91G/xmryr3Xf966w93i30HKK7jxtRa7D/gv WtXudv8Va4W7C2wpxm31dfSO430aiTus1W6XX2/Vu/3eWWu9ewjmxaT7cFg8aG1yj/qvW5vdx/w3 SHwL7+UgJj6Zi6373RP+O71z7imQ9qB71n/P2uk+7X9gtbjPBmirw90SkFq97gsQO9yXAvHWQffV QFIoXgikWofdNwNp1iPu24FMiO8GMvH8Cmy3HnXfD+Tx8XH3w0ABj5/wRPn13Kj1xnhioF21JyGw 0zrjSQ7ssp7yKFoV1jOe9LduWs97sgC/6MmB3WM1tl4SV4pwjfWKJ781CuJCEhfhUfCUBhhuF229 7ikP1PF6vuGpChjfzvZoA3uttzyGQAtotR00ecdjDsChybMPcIEPju95WgPt1geetkAX4B0Bax/t 6Q64+qQeW8DfF+/xBIb6kjzBwOG+VM+hwGhfmmckcKwv0zMWmOjb7hkPTOE1wjdJ1oj7fe0e2EXA ulngS+jrsh8PkJ154BI+OwSjMB6M6bPivVCfi+zSJ+0znZf6/I5dQbIvCibjfVRQ0TcEeDrZU13u Owx4FtTdFcwh1pvfN+rQBAvFlmwZ9ZzzTvQd88x7Z3sLPZfBqq/wewaYI30TeI7gswn4CjgFBEt5 +pTnGkeHnTmml2M8WEVOCgrx3qBvFvufvtPE/8DeAGQ+C2eHFYIvYDyoxTuEoIFf4y54loOGvkue lcACoZsxPbiP4K0Eb+u76ln1Xupb6Efe2303CX4b4/iUFOzou+toCXb33ScnBbKHxzuNTiu256AN 40EPwRUED3J2bknql3gnei72x8LedZTgVzDe1479TN9D7GfwbqTzEt6NBA8RfIHgI7ao/kS8M+lP gZ0h7HiDY9jCg+O2mH6l96YtoT8D9tJdBE/GOC4fHMPlg+N97fi8ZlP0Z8PJCPxVcBJbfqeL4FEY D06L/RhZ6+9ya/3armavBOPBKowHT9rS+3PhRHalXwVjBGfAziR82gqW2rLW9jD4VBicw+cv0Exz /w7vlC2nvxjmEYfn96uD58Cz4T3DLbxnsBWu7WCxhwzO4/kVvEzwaxh/Y5FYwqKtqL/CV9pX2V8N +r9I9hhkFbCV9uv9aDBpMG0w1V5vLR64gWM4S17vvw6+a7L/hn+wd67/lq/DntJ/Z2B/X55nMjDb V+CZDpy2K/vvDRy0Z/Q/GOjstnnpAYs92ysdcLwx740P3ObPyB5v0oAXa35gkHjvYXuuN3XgCHfC 5U4Z/Kk2/MTaLpxS7SpvWvhZlVvBuf2DfYc3c+Covdi73Z9rV3vzBo5zftVCewtg/SJ8rGrvzsBO e4V318AJMmdzuJmI2x2Y4U/T+Ox8mbNkLMnAKd7fhiQZOCP2kOSkrMBn5IHznE/DHmPgIne+5vwS nsvBk3jtGLjCxRyFa8Ve7dgZYOx6r2bgOmcheNUASpO3cuAWfztBbgzszfajA3e42wn7fi8DNkbu IrhTv/2gt27gnr3Ta4QWyZ0DpzfuVoHbZ9qHvV2DUvGJkh8d7r4Cag08sFu8e98dtju8Le9m2L3e A4E6+6C3fZDG9tAxht/LR96kiURv0qTJmzSjpMVSLdpM3p6pIG/P/CR5e2aGtE3agT4lfU/qRCry ZswS8mbMSvmL8lxULf83+UeojrwP9HXy9k8TtPEZlIE+hxDahV5DqciI/g7lIzuEauRFPlSDRtB/ Qywag6BD42gC6dH30Ax6HZ1BP0UNaAH9K3ob/QLdRl9F99Bv0bsUTWWjPspBudAENUj9FP0P6mfU DfTLqH1RX0G/jhqN+jb6bdRs1PvUpqjzUR9SsqilqI+op6Pubd5EPbs5Y/NW6gWJQzJLbZWckrxP aSU/kvyI0kvOSn5C1Ur+V7SEaoyWRT9HDUQ/H62kRqM/Gf0eNSZ7T2alN8vsMj8dJ/u67BD9nOxb snH6E7Lvys7RL8k+lF2ld8t+JrtHf0n265gk+k38tzW6Rx4vf4q2yBPlz9FW+XX5L2hX7Fux36IH Y1fiKPqDuNS4VPrDOEVcOn0p7sW4F+l/jtset52+9lT8U/H0zxAF2tlHblyV+P1kry3xsAywglJf W3pt+bWV11YNyCAxxBoSDSkGpSHDkG3INagMOwzFBrWhwlBt0BvqDU2GZsN+KKPCb48kI4ykJdIS REs1Ug3C30VIJL9KRHQBXYAoupAuRDT9efrzaBNdTJfg/+uj1UhC76H3oGi6hq5BUpql9UhGv06/ juJoI21C8eTXign0V+ivoKfpd+h3gOdX6Xb0DPnN4nOg9QyUIvmJ5CfoL6BPV9B10jP8V0Kkq0BG XafOonPovLpB3bDuiO6o7rjuhG5Gd0p3RnceqBd1V3TXdTd0t3R3dPd0D/S0XqqP11Xok/Sp+jRd tT5Tv12fp9PrC/Q79bv0Gn2lrl7P6Ov0Rv1efYuuSX9A367v0jXrrboKUajmg54P9aHQxAW9S7df 79cd1A8BzOoP60f1x/QT+in9af1Z/QX9Xf0l/VVoaQFK3tTjN9dR0X8P2kwOs3b8RvF81Aq2W4i+ BpZfTKy9DKx8Au0BO/8eqgAr/yn6EroFoZLo6MvRL0RvRVXR26K3oZrol6JfQkz0y9E5iI3Ojc5F umhVtArpowujC1Ft9I7oHaguene0Gr0WXRtdh16PNkQbYNZQ5K99WMvp+A2djB9giIfDAKNoBxNk DjEjzBgzzkwy08xJZo45x8wzl5lrzCLQl5hlZoVZZcZZxErYWGaMTQQ8hVWyGWw2m8uq2B1sMatm K9hqVs/Ws01sM7ufPch2shbWwXrZQXaYPcIeZY+z59kzQDsONU+wM+wp/K5D6dvSd8h7QWPCtPU1 CPnonyC8gn4OQQVz/1/Rq2gJQkF0ZXQl+mx0TXQNKow2R5vRXyIq9n4c+eoFysbvRK0HT1YPfsxU CWkXgBVRVecA5jZ9pr7FVFB/wLSTAMbbTbvqu0wagmOwmirrXSYmlOc31YXyhHK4LsZxvpA3ZDKG cEw/bNpbP2pqCUsxb4xjOGY6QEDAJ0ztoTwBBFmEchgwfwHHPKfgeYqXCbcrPGPA+U8KgjxiuZ4U BB1hGQSaWA4hX5Af02Z5WXGK4TT0VQzi+mLAsuF+4vQsjAHWzyyvb6GNKT7FYyR+xvrs4utgWXGd C3wqyCbwEXR7ydQVNqazolSQ5arJStIFkyvUVmSK28HtC6kgu9AXzO+myf9IvdmIdm+bhurvmg7X 3zeNhuS8ENGX9WQV+iPmLdbXQ9Ezlg/LJKSnI54FmxTbotAPntYQZTrWEGOaCBt3nB7YoP/rySR+ FuaXQIc6xmqOFpmK6zYkmKYaDOaoBrM5JmxcH5Ma9U+WH1YuUt9PkJL6wnOkniN18XHpw/Bn3O8N 05a1VMzHWM/p6XHpx8ol7sd69sbPtYZk02yDwnSa4Hwa8sv8HGxIN50NlckyXcC20pBjuiT21w35 pqsNhaYForOWNdtoKDLdbCg13RbbX0O56W5Dlel+g9b0MOQfeH/QsM+cQOav2L/g9lrNyaRum1kR snOQr6HDnI6B6O2gebWh25xF8M5GZLQ0SrC9Gh2NsUZvY6JxsDHFONyoxM/Ez0N9YzP4RGENWm8s I8fmCLTF+2nj0bU2QvnHGzOMJxqzHxmLjWzzdMTcfpy/iszndWScacw1nmpUCXJj3RrPNO4Q6yok Q/sGfgjr02bOwRBa1wSfLOR7zPkNQXMhgUPmooYRc6l4PW0YM5eHrbeidbZh3FwVub41TJq1ZCwE EPhMmw0kPWk2N8yZ9zWcM7eSdjaAhnlzGwbiywTaZXNHaA7za2nDNXN3w6LZJvZpDUtmD+nbsjm4 4bqMbW/FfAj3F/exYdU8IvA0IvOYWF9GiXncGGueNCaap40p5pNGpXnOmGE+Z8w2zxtzzZeNKvM1 4w7zorHYvBS2dghzT5wKa0mkH94ojbSv9ohUoGO/f3ode9poLYpck6CusYm31/XKidZTUk40l4m9 4nkH4y2kZG+C08f182N8LUnP8nsNIRXmzYGIeRS5/gn7EXg27g9PQ3ubY4/2I3K9fWJ5+fzQWhm5 rm60/4gcT35uhdrD9gf67pJ0xT6yt8XtnW8sNqrNy8YK84rxYqPaeKWxImzPiPliwH3GvK43Vofm MNaXeH8szD9hH8LLY7zRqMfrhPFWY31o3mP6ncYmPP/E9Y33GptD8kXyBr7GB4378bOJXptfYv8k +KLQ3hlSk7TxoJBvim/sFPy7KanREtIbL7MptdERth/i9Wja3jgcNsbYPoQ1EddLa/SaMhsHMY5P 8lK3tB8h+afJl11uy28j/CXDbX/cm5bNm9BvyY3K6+RGpUFySvIjKkjuUobIXcoRcpdykdyl/Au5 S/m57L2YJLqY3JBcITck/5vckPwzuSH5F3JD8hG+IdmUim9INmXhG5JNL+Ibkk25+IZk06fxDckm /Ju0UXRs7R5BM4XUmguaS5qrmgXNTc1tzd0v1mvuax6WRZXFlCWUJWumyhQA6WVZZTma02X5ZYVf rP9ifVlRWWlZeVlVmbbMUGYu21fWWtZW1lHWXWYr85QFNbNlh8pGysbKxssmNWfLpstOls2VndPs 1MyScBbCFAmnScBPswQwDoDvBKQ6/Pu0iFNuO4zLu+g9ON8eh/BZcuItRD9BF+FMewnC56gfU+fQ zqj5qA9REb6/gpr4N3iGtf6WFKN0oafQzwVIFwCD/mIK6TP0ukwBPVZwvcZ9hv4qoMdFZUVQ5y6U UxAZzSDjc+Q/exHKhEChLAg0nKqz8Xc5IUShHPQptJl8kzEaTucFSAYy7UJxqBRCPFJDeAppICSg cghPowr0JZD0y6gKJYHlaVEy+fpcKmqD8AnUCUGBuiA8j85DUELfP0RbqHgqHn2S/Kq1U9RX86a8 msWapZrlmpWa1WIrgxhJ8ULxAhPLJDIpNYuMEmgZTHaJh8lllIyK2QG0YkbNVDDVjL7EU2IrGWPq a5Y0SqapZolpZvbXLJWMMweZTsbCOBgvoyopYgZLSplh5gi0s8gcrVnFXCFUrIXiTOBDgkapUZZ0 MycwFyFAq0I4DvVmSsbZXYSXkklhzgPnYnhaJbCKZSfyK9cCyJZY0g09cIDcR2pWmFPQg2Ho1xno bT2UvchcqVlm9BhKPMC3grnO3KhZAXyFucXcqVktsYE2mplEzEmjJPoCYJQgWzb0E4Bwv8c8AC15 iZ4wQGsYSsqZepbGfIVWMEcBsAwYWCmkEuAKULygUYJczThl49kkwJuYWDaVTSsJFsN4sZkszW4n 7RMZ2DzSfm7xhVDbAGwBu5PZwQyS3nYRTACgcLUZFXC7SWR7BNajszfZ2+xdsfxiwHlE5vvsQ22U NiYkoQjWo2OaNkGbLJZeAEzXJuBR5gDLgXUjyM9qdNVMdc0qW8lUE2DYOtDwCmtk9zIVbAt7gG1n uxjEWlkX68eWje2UHWIPA6dORsmOssc0TcxBdgLrEPhMsbNYk+xp9ix7gdVAqzCG7CX2Kr6hZBf0 s/wt5SX9Vf0Cvp/U39Xf1z+sjRJGErfAFtTGYKhNqE1mmrgaOK9WUZvO2Q+vUV5z3IiDfYXGlLOr kCbAtmqzanOwddTm1xYyp0pKa4swB/a2tpXUwPrJrVnV6ZlqctPaXOLR7Wf0uoO6TnwLzO7SOfBN MNuiq9YN1izphqHFCWixWaNcuxkG+indmZJx3Xn+bpi/HWYswv0wu4vdpY/XJ2ly9amMSp/G3RHr tzMO/pZ4l+6eHsZEd4VR6iuF22LdoL6luh3ncHfGeqveVVKu9+uH9IdL8sH3YGtbYqq1CvauNl2b pc0pzsQzUJuvLdQWaUu15dpC9pK2StCXVqs1aM3afbj3xVbwQUiYPdo2YRZpO7TdWpvWQ/SKRz1W G9Qe0o5ox7TjBCa109qTbB54kf0CcGMD1jinPaed116OtFTwGgcxcOPDPsSgvaZdxLajXdIu41TA sS/QrmhXdUgn0cXqErH8uhSdEqehcQX/qMvQZeNZqcvVRtUslpRiIKMJdqdT6XboinVq7Qj4lUGg VegqWrXY29aW1pbXVtVq8d15raHWDJIv79KDn8qt3VfbWtvGVIN3HqvtgH4fBFk5b3wELLC71lbr AQ5e5mBtUJ9We6h2pBZ8OMTjtZO100A9WTtXe652vvYy2HdB7bXaxdql2uXalRJb7WodqpPUxRan 1SVi/4d9LrZdpqkupU5JdAJy1+Vy3hL0lA2+1FuXUZdN1sJGWPcy/yvso6C3e1EruT3H3x9CJQhR AEnFD4oflNAQ8J+J4iEkQUiFkAYhE8J2CHkQCiDsLDlQsguCBkIlBAZCHQQjhL0QWkpaoB1a+rq0 Hv8HGfoC2g16/SIqg33FHtgdSNBfg/bkoOfX0DOIir0de49IRP7qVQq7E7UL0nRI/Zs+U5qstpYq eMB4OkAWj2PIAcgX5RWK8oRyCh5PF+UViXBMLwUoj0hzeBxDFQ8CrhXlCSDIUiWiJYvwUlGbigh5 kvn8J4WqCIiU5eNA0JEiQk4BhHwxPV2UpvN9FUPyBlDFl6/ixyBfpG9xG+V8vvg5R1RHwdcRUqFc aURqiBhTcSrIYubTfevIIKQKvn0hFcsu8Gldp15ku20AHQDdIjkj+7KerOvpZ6M0h5dpo1SwSbEt pkfQbACej9FDZP8fJ5N4fglzRqBFpuK6QYBFgKUNxvcPmW6k9ydNI/X8pOO1Xhp8wlRcT9DT49KP a1fcj43yMX4IYITHhVTwy4JOx0R547yeJtXh/noa4KR6zWcItjEHcC6i7XmAywDX1Gv+QbDDZTU3 f8X+BacrfN1Vddh83I04wLTdVwAkPH4d4Iaa2OLuWwB3AO4BPOCeiZ/H/StUr61BTzCmpK1STi5x G0K+mgaQrqPrjWzzcbYW6a/W80tQTx0PkCSig27VqeG6ekSGSF5Yn7EchNY1wU6E/ESAFB6UABnq sPV0d7aornhtwvrKVT+yvu1W8WMhgMBnB58WA6gBKtSPrk0i2F3NAbEhgaYX6ZVfS3fXAzRFjGkz 37f9oj5HApTdfZDrL+7j7k4RT0u4vnY7ALwAgwDDAEcAjgIcBzgBMANwCuCMaEyENXu9dL2x2ih9 Uh+XtYE9PS59Ut8onrvrpYX8eEem/xlfK/gScRo5fzZa/x+XPq4/v6+8H7dmPsm4lke0z/umvRXq R/e22D+lgd2dB7gIeCbAdr6uQtROOt9n4KXOU6/N4Rx1+P5YmH/CPoSXR12gJuuEeqd6bd5j+i5u /onrqzUi+SJ5A191pYgmzC+RfxJ8UWjvjGVm1vLVdeqQf1cbRXrjZVbvjbATwY+7IsY4S702F3G9 FoADHI5/BUW+Jo7+q93bU1789WIUS8WjIoRU4wCTCL0Sz4FqGtIkSE8CzAGcA5gHuAxwDfJSIV3k YYmn43LLa7A9iStHyq7wZXHeKkKvIo7+qgQgFiDx94AUjo8AIX5KTv5XM3jeGLLDy0bUK1LlqPJV haoiVamqXFWl0qoMEMz5d+B5n2ofpK1AayOhQ9Wtsqk8qqCqDeiHVCOqMdX4Kw9fefjyCo5xymGq SRJPq06+tP+l/ao5lRm4mFXnVPOq+RzQmCjM4d9/PvobYGmxtApFSbVSLXpW2i7tQMnS96R/h/5C 2iPtQQppn9SOnie//k0jv/59Wf6i/CX0aXmuPBflyz+Sf4Reif1R7BxSxZ6JPYMK4hLinkWfJV++ //wfvT2KSqS4X9LOoJdA5y0IZcdw8ApI8Uo7QNcabSN4xQrgeoJyfoAhgMPcc74yIn/08Tx4eCn/ wSt0RJC+tEaLF9NfSRLwlx6tFRbwm0nIb7yRtFrKIor8xnsz+Y13DPmNd5y0Tfo1lCLtlnaD7i1S K+jeIXWiNPl2+adQuvzf5LdQZuwHsR+grLjkuGT0YlxKXArK/n/Gl0LH0Ym1vwblRqE9eZqsYi7k 7QWoDD0xeXU8RkpwOXlGIV+oAXFLXkuIosEhPF/gJ/DCnAQ+PAfMu1OoJ7SM7xDpQdCFhB6hfwDO /X36A6Sk/yd9E70g+arkq6gE+1C0S/49+Sn0hdDbknL4tyV9GmpGQU2wEnqMnkGb6VngkkpKK3je FEomOK+PbQWI2pZH8r6FY+BOoQK0U1QiGSVmJW5r26bY1pbbDXE6hFIIyduytuVsy99WSEIR4TGE f5VLf5v+NkjwHfo7QPku/V1E05P0JNpE/yP9jyDf90GmzdCns0hKehMD8v0AyeU/BCkTYMbZqLPk Fq8KPY1QJsyG3EKAoo+B0g3zqEwX2rOtnguZVZlVAr7t/Lbz5Ll6W3Vma2YrfuZzcnGcK8mVZE5n TufG5sbicvg5VFccoD7h3ZbZtu1MZlAccN3I8ricOETm56bkpohlzFXmKgWcl47IlzmN+5ObAVJV f5w8on5x7WO5EnMTMz2Znm1noIQHl+NCZjfQZrbNQNpNxvGb9DcRkrwjeQdRMr3sNUTLXpfVI4nM LDMjqaxJ9gaSyd6UvYnksrdkb6FY2X7Z36I4WZvsq+ipJ7Zhihqn7pPxboPdC8o4+uSQA141B7xq zs51wMrB1glIu/jUiqicYwhVWdGejNGt5Thk7MyJ2jrJ4TlZOVkv38+J2VqU0ZVRB5RpCAooM7RV kTGUMfTy3Zfv4noZGigVlROFnzkePK+9fDoKHCZwmmHcOgm8RteAtJAPbeVjvjhw5cJhaznmTNqC /JxCXsYiLOPWaSxjSL6RNflweZArAeoWCTKtJw/mQehDQj7IZnz5YUZ7RntODpRox+UgJAPektG+ 1bB1DNLTeJRoNw0+mv46/XUko79BfwPFyHQyHViAQWYACzDJTGAB+2QtKF72tuxt9Iz8tHwOJcl/ Kf8lek7+7/J/RynyX8l/hb+a8jv4uEqAJoAW4uXyyP+d6NEOeKriPV8eKQc7AuK5SkXl8kjN7FA5 GvwQaZe0oiStbMF/ZaC/CXZOg11jS0fE0qOIpUuIpUcTS5cRS48hli4HS29DcYQj7gMifdhM+rCV tF2JtERqru3PEBnxbzH0ADtCNBplEclLw8phqbFfTuJpaxKuJ/8fUu41fY+TtvMJjdM2hU6JaBd4 fYvLzRBtU6iVp20kr/w/ZUnYhlKwDZE6iNShSB2a1NlE6khJaRn+29GjrRF+csIp/mPHcD/0xMaP zSuENkN+S3MgjJZFtFEfRvMTbZSHaE8mx59eW+vpgkJT6DzZFaTi9/mnGREIRmDPFsUWbZo+DWHY kgAxxlFavfJumn6LAmhcflNa05aVtHqgrUDaRMqgtGYS70/bj6kkKEgI58jz43OAk5gPUOoBENca lOZaBk64L7IGWQP0uVUGFil7R4Zn0BOvTWiSjCD/N05lLIE9W2xbPFuCWw5BPLJlbMs4hEmAaaDZ tpzcMgfUk5B7bsv8lssA17YsAt22ZYmEEVI+SMqKQzhHgd9JeLYBPk/4jBN8BEpNw/MS8F0GyjL0 FMeradjOaJlRduD37eHz2QT2KAuVhc9PKYsgLVWWQ1ykrALQEorheeb5LqUBQhEEITVDzj4SSskz hC0ZSjMGzA2CVsRxjZ+B8OI4CXzalFHKji3ZwKsQnlsJ4BgC6WGjbO/vsH7Q4J9gblI7+Xmowl+k oPKoAtxzKjuMmkWlo1GgJoVREykJ8sDzQzEVPaBodBCel8KoN9FdZITni2HUebQIfoBCsyIq9iMq eBoL0Z7EPyTSR+j/DiX+nh6DFeEf6H+AHfU4PQ41J+gJ0Mk0PY2iQSfvIyk9B5qR0f9Ez4P/uEh/ iOLon9I/RU/RV+grKIG+Sl9FT9ML9ALw/Dn9c/AZM/IZ8Bk/gN34s7Ab/yHYhGBPeG/vI7GbxN8g sZ/EQRIP4B5R2yl8R1PA9+hVQiunYN2gMsJoUTAaFJUQRsugcuHpQRgtnVKINMzRkqhUeLokpqEZ GCG8Nolp92Ek8Nokpt1At+BpKIzWiS7DkyWMNoFOkzVMTBuEkySF6sJoregQPKnDaC4E+8zQu285 WhJZRdJCtDUd+ogl45FGxDtTxDvTxDtvAu/cDKt5C/joaFxatk+k9wChGElsEI2Emx8PTP8b0jo+ 8dEoHdYorv0CJJwFKTiXceVw3AzaPYg2Qx8zoE9/hj8e4Jm/nc6FeZ1H5wGeT+vAKvDXWrbHK+I1 6GUYmQQYmeI/uaT/vwCNosj3eRD1f6hfgY/+D/opFBP36/hPoE8iOkqKNoOh/6ll/DP8Gf4Mfzqg 0R7E/W3MiPbCuQX/PeyTsCP4LnqBfClsGzoD+4gstADhVdihLcLKeAPCZ9EvIBSSr4b9JfoIwg50 D8LnYE/xH3Di/TWEIvQbCH9FvilWTL4pVkJJYBeyi5JSMvQFSk7J0W7ylTE1+crYF6mnqaeRhnqG egaVUc9Sz6Jy6jnqObSHfH2sgnx97EvU89TzqJJ8g+zL5BtkVdQL1Avor6mt1FZUTW2jtqEa6kXq RcRQDsqBWPJtMi01RA0hHXWIOoT01DA1jGqpw9RhVEeNUCPoNeoIdQQZqFFqFL1OjVFjqJ46Sh1F DdQx6hgyUuPUODJRx6njyExNUBOokZqkJlETdYI6gd6gpqgptJd8++xN6vvU99E+6gfUD9DfUD+k foiaqfep99FXyDfRWqgPqA/QW+TLaK3Uj6kfo7ep/8vc2cDpVOb//zrnOufc90wzQ5LQ5GHY8jB5 6mGRSoUkVMLOFvIcGsUoJLXlZyVk/WOtrKxky6JhJau2LU0aepLVhCR5WjQ0i1SS7vv3/b7PafJw /9r29///f/+/+3V/ztfn+l7f63t9r4dzneucOfc7zjumwHnPec+McN533jf38otp9/GLaSP5xbRR zhZnixntbHW2mvv59bQx/HraA/x62lh+Pe3BzHaZ7cxDmWMyj5tfle94V41WMi103RJ01PuhWXdm 6VshTtdoqRpnPf0jGlegMf9HNFqhseBHNK5Ujax9p2no3k316GvYKTnT11N1rk7p7ak6rVP6e6rO NSk9PlXn2hQ+60q1Bpphva47KTX0/kydNqfqiPdn6rQ9TWd+Cp12p+ksSKFz/ak64r3WS69TdIWb zZ0NIyM/VaRP17oBCyP/hVYHtEb9C60b0br/X2jpFaBT4ZzTIl5FrgtC3SpodUoZ89O1Op8WiZEp tW46TWtUSq2bT9O6P6XWLadqST30yrZKuV7YQl1SeH+m1q0pvD9Tq2sK78/U6pbC+zO1uqfwXsev I/3LyrcG/cyYX6TsFWfq5aXsF2fq/TJlzzhT77aUfaOqXLU57N1VJY8xt6ds9zP1eqRs+TP1eqZs +zP1eqVs/arlmk6kd0fKlj1Tr3fKtj1Tr0/K1j1Tr28K/zz0vtcM+0G/FP6l0uufwr9UegNS+JdK b+AZ/jkmXXT7//BbNOH/k3NO+r9vqgl+f7V+yl5d2hZj0ieYTml75XMQnJW2LK1EPnNFXpR2RCTl jqUlRE6ke3JMCJNIT08rSa+oH0nVfEfSjqRH//j/6Ra/t7dXbJVEliQVbbWwKN0Ta+npVbBQkp4t Uk46u0fRPYufuhu5y6lCDfWvQk1cahjfLt898i2N5EPy/So6ngjlNDf6xjl2ipfIZys4IT43XiSf KSLPiu8QSbm98YMiH4wfke9BYQ7Gj0lKgs8E8u2Qz7Hoo/8vSasiln6wOCXSKsFWaCm0U4KFWcIk 4sfSPCwUpaWneWkV07z/5n2an3onNcvpSvQKpNeYeL4xsV4/fPX/8Vanfr/nKy456bs8+q6S76vy XSPft0Wv4IdvxaPk7RQbIp9hsTzBDbH+csyL9Yo1kk89uE2xsbGR8mkUmxjbFhsn312x/WjpJzvS rBebGn2GRJ9hYDYWv7c3RGwNERsT5aupU7EwBNt58r/ZsTK42fI5Gpv9f+6eyX8n9sFDxlSo+8M3 2Cjf0ad+4a+V75zoO1++C6OvyoXyXRHKFRqc9H0IvpNfJp+j/ja/LOjq75fjNn+Xv1w+S+BuC4x/ XD7Lg4ygdxDId2CQj5Z+5kWaS4JK4QdrocWycou7RFatMrG1TWxkBEFsihwrYaFMbQtfKagRFCgn xxrB6KDG/3Ts+fWw4+aHex96RognhiUyElfx5fNv7LPqOtmhNXVPdF2S/VL2SGVGPt77u62nzOUZ JnZ8i+mfgp2Yij1W/BNZqVXi8/8rjNTi2xFn+vDtgVSeffv7VOw3H/1E9szSRe+ru1Pl/tpLxR4d 8xPZlCUdm5HSzwap2K/m/URW4ndiQor2fjll/G7+/7QX/L9lNDLvpYrBibb/W/3NeLJ+cor8yqC+ 42Ovjl+nKFEi2MvfpnOFP1rkXF1pObmJYfpUMXgULPIeEuygsjkUrFKbgc7tJnEVcgHrOaNzvj4p keRul2B/ZRKrJXUmqeHK7xByV3AamAu/ApwNcq/QOQe5P/JR5HXgXph3wdbgDjAHXAUuUHTzwDj4 MJgPtokstMJmPXyoh2818Koe86fyYymxFbn2KNoM5AuRuc/lhXf3pihKbVUejTwMnYGgS4kTwE1g AXbmkloLOzwXYd8GucPnEA13OTa5V+V4yPPAbcR5Gdg7tJMsUT8VnaPIecgLwFxF6yIXkDoXfAVm FantYR4GF4Iz4DuDw8D94HiQsryKIM+EuFuj2Ooq/ngwCJwG6h3EdYHemTseexhsAl+IrNePB4IO 9KgFijDGnwdzFHkK8iDk28D+4Db6+RZSPVDvYO7VHi69fQ59dZj6H+QqE7yrMn4WkboXflwsW3kt 19ZS32wDRfeVWBvBYkWnV3IXeVtpr0ucUAYsCvnELHTmaK9QOV4rMV+u+acp+u2SgfBzNNVmhDrq v1tGBPbqOPVfDXuUpkr8lVmnY000D4m1/aoTTPNVZ5fyMqIZ4+5c8BlFZxPyBm1HZ7fgYvdZwQ2y ZpBykYeDLcBXlHd3q+wMAne4L+oItYqjlLFT0dzt/llzKS/W3lHLyC20dFvFXam9S/PaEzI+HPeY M1NHk1NLZOO8IHKx8w/kb1V2r6dEnYuOuvfo6PMa6Ch2Fum4du5Txor/Tra7VmxmO5vJG2JoZy64 WzWVd6Zq3R3POQi/Rce+W0lr7RSqrL/a6Oa5NbWOKoum5urm7hd+ks5XUq+PyfsnsVnNLdb+LKPc sZfKGJVRY2U2s2NUtgPtLB2t9jHB+appl8DU9GVd5I3nafzp/tXSgjd5YtDr5HcUrAZuhm+qslsZ nOnLXOqH8nl+M2nlN1T2e/ntRL+Wd7/I9bxOIrfwtJSn/c4iz0Jnssr+WF/8jHX2Rccf6kts/dl+ d9EZozr2d+5fBM+xtwre7j8oONb3BdfY3oJX2p5Su2esjDs7xP5e5Dv9X4mF4bYdjOJEaj3Eakx+ b38u+KjV+J9vpwr/otW++if7tJZlnxK8xc6Q0vdrLr8f0bvTLhW+rpXxa3vavwkutBeJha/BMkVb Fz/PtufpiLPSi2xjRWekfQ4P1ebTGmevgp0sOhXsa6LTw+q5qbKOJm+X9xbtJf3HH+EPFvk+Wq2m ry0y0JPe4q32Jwnu9VYSnyGC9fzbaZeetMjtWju/h1jwNNW9UBlpkSG0SF+x9ppfUfBbcBnWVpI6 W1s/dgt9YBZ599kJRFj7SY4dLthRz8LWt48IDvWvoRUeV96KHWe83SM4w+6Af1Xr7v9VLI+0I9AZ QSvo7HR71BbjaAsZj06et4+2eE09sctoi+WCH9mXdPwm1+uYTR7WGYC5erfKTjfkxaS2gOnF3FiM pkn00DGIjkHHKG8OojMV/TuRC5Fbcm66mdHUmVxjdTfY3q9zptsUm+/qfGifRr9pUlYX9lnkZxT9 5xXtc+Bl+rcK9tmE9G1nXOgPZT2j5xc7EZvp+tSRV1HRnhvaVz6x318nZ8bD3jLODoHWOvha8MNY U617oLtIw/1dKocYqwSv89WHmmofhF+gjJcNv1gZp9jLA6UnuHV11nLr0tbG6wNKqruM2ewvMN8p OpvDXH5r1fH1edJkIH3efKlnHPeV8HzE2byurj1kBSV1TFZUObEyYhSrsz6ZIusgPfe9xPnuIpCd v+AbxaT0WDkz1WPdpRZ4PijB0z+J8PmcRZS1Jlq5qbwFXA/Svom3o1yhBS2Xp3JlVlULNcDKkc46 1qDK+FgIn+M6G2TX2bkAfjH6+31p2UQLRWmjQJHVqfHqwui9gQoRKrNef59XUhvpeiyUZZWkEVik 3qoFSV2GPnKo43KnwasOXxG5N/iyxieWrz7EZLZJPK1y8vrYA9hcAc4gnt2QnwTHgx+Dm0m9FrkU +QOwDjiYNUwaqbNgWL34JchYCEbD8HS29lXBQ+BuUqchv4pcxTgnWOUm9xHPamCFaK9czhfJr0g9 TJ/5KuIrwwh/Yq+OOFkFtQdXgiGja7zOnvbzvt4TMvrWxmRW97srervBEYruIkV7gWIsxMdhQM+g 00IxAP1cUlvDr0a+C34x+sjehzBPkfolzBVYqIw8C/nXpL4J48LUx2YMfifMRPwZiDVk/xL4y8gV 1mUh/BH4q2FuxkJv5MakejA9YFYgTwbnUeJF8H+AOY5+OtgGfij8PvBBmP7IReBh8GuQCHvtkYfh D9EI0Aw+IDWsdSH2m8J3gn8UHAPSCvYj5CT4OcwUxXTaK62rYpzWiWWjUwCzB+ZJmAfAR8hLbL0S 6vsY5YalN4JvCz8TpjZMR7CYvAPA8SD6/nvgXBh0POTkLu1vyTXa3wy+2W5Y7qtXmm6eXEkoykh3 W+qI9tfqFYHfXdHbDY5QdBcp2gsUYyE+DgN6XEe4LRQDUPp2Pr06n/6cT9/Op7cr5pK3NblWI99F rsVYQ/Y+DC2j/xQ6X8JcQSmVkWch/5rUN2FcmPpYjsHvhJmIzwMpBdm/BP4ycoX1XQh/BP5qmJux 0Bu5MakeTA+YFciTwXmUeBH8H2COo58OtoEfCr8PfBCmP3IReBj8GqQVvPbIw/CHmARoBh+QGta6 EPtN4TvBPwqOAWkp+xFyEvw8bDuNqgVl5OYzn+Qz2+Qz8yhOUc102i6tq8pxWjmWjZ0CmD1hlFQn nR4SexLmAfARSqctvBLi8xh+ht42gm8LPxOmNkxHsJi8A5C/SNusvR2GXP574FwYNL1Q7qbo3KTz sL9WV1N+d0VvNzhC0V2kaC9QjIX4OAzosQZzWygGoJ9Lamv41ch3wS9GH9n7EOYpUr+EuQILlZFn If+a1DdhXJj62IzB74SZiD8DsYbsXwJ/GbnCuiyEPwJ/NczNWOiN3JhUD6YHzArkyeA8SrwI/g8w x9FPB9vAD4XfBz4I0x+5CDwMfg0SYa898jD8IRoBmsEHpIa1LsR+U/hO8I+CY0BawX6EnAQ/h5mi mE57pXVVjNM6sWx0CmD2wDwJ8wD4CHmJrVdCfR+j3LD0RvBt4WfC1IbpCBaTdwA4HkTffw+cC4OO F8rdkHexI8Tfg9ntrKWnIvM8uVdRGY+1n8fKwdP1ghOwF2fnoz8+Kasv7wXWe8XwrOJ81h6WvxPw 6iPzbLe7EJwR7pKFu4XsHw4i1zhWgE11BWK7sJ6/HH2uF5xSrAXIj2gut4zU71QOwl2+X6LDTpcb 7v7lqh3vE5i+lLVK0duVGKNegScU3bngBq5lhhMf/kZYroGb6f6Ypjq90N+O/2EcuD5yia1zOTtI 89Gpgn4HrmLmU3oY7WuI22ZiWwfmf4V7Yvj2MczFeB6npd7G23+EV1uksj73H6Mt7qR274IvJNtI KmPf2aTles2xsJUS78fP3XhIn3Qp147Rv/zzrsWHJppLajqfms4nPvN17YfcAHyb66ljyF1YGS4E y7CcAb+SK6/B8B8qyhl6JteJw9AfhoeqPzXxNnkV4zAr2SVbSblbweGktlG0XPv47Je6f1XL1sXb Asq9i/3qQZT7CtbWIO9EE/tuNvFMyPpX20tTZ2DhI8oqRl4VyWptOToP43MvbJ7AkyrgrWjmE+3q YHg9ezb+xMjbAzsd4PlLCPcYOBJ8jh67hRZ5BGYw+BvwHfB1PJ9Oe9VEcyfMhiiGgj772H4e470y dVxPKiV6/N2d1w9rzDPOm1gbQL0uj84vKh+AvwXNx0I/sdOMHsh86/4Jhr13dxT67Jb7TSnlJVJb RGURc+T7wdvBP5NrfHhdic5qLLAz77/AiG6Czmvo51DHZlgmbvZTyqpBfdfh1Y1ozotG/W9l7mU3 Pr6MkXIInIz9D7FDT4ixJx/QG73jeHIrDPv5stZUm8sZ0WmkXq5jLbgjmqmkFHcyfeZTWr83cxe7 7m4mft5F6uP0h1HIXXWvw+NuhZzp2msr4w+9y70eD7kb4mbz+3BPUXdiZWNguFO9Gv0LabW16IRj 8EWYeaQ+GrWvlt6W1CVo3k59t4APgdeiWYjOpcjF4Cj06yFzxyFgRSG9S3vRbvy5Am9fi67Zx3HN Pk+vK+0RrtPncOU+k2vqijDNudZuzjU7V+iqKdfsocz1r67w5dp2pl65k1oBNG4c+QQ6HXU06d6+ OxIsA18BJ4F9FZ1S5GJwuaIdCLowlZCrgBlgCfxc8m7i3lapf1z3hMGjXIOMVNmthFwJviqYCx9X tBmkxrFQCI4N75Tp3TTrIifQaYm8A/lYLK7+xy7TORC5TNFWAafi2zFSiyPNuM5OygiG+pehr8wm 3f0QvEM9Rz6KXNVfCvbH2zuoxSJQZRPUFVwc+gbTktQWurtltxOZql5bYSylTCa1L+U2CD3RuzkS MeU3wHyMXIxciPwb5LV49XfkqtxJibP/6cKUojmS+raE6Rr6ifwn8nYIsjTaMEd1P8SdSxz6Epkd 6r83Ec8vDX4m2Ed3X91jwd90tqd2r2N/A/pFMJM01a0U1KYsvVth/I+0dHKVUlYubWHY39sDnyC2 CTxsgs5Y5OH+73SP1M/Q1sHyHmL1HOWWUYsies679Jx09hU7ggZczH7jJfqefre2J7G1v2GncRet 4JA6SlPtldS0srag0y20EORo6TCHtEa2TchrXvsC+5xrsPMkfFcsVwtz+b8gbw5+quUe6AzUe21u Q3pCsdcOVAvnqexyJ8514AuVd/4Ivgl2Y+ezDP0LkYvBbCLsoZOtjDX+VJ2rSf2OOH/qyXrMnU/e NtQo3EddFtaXvNXAL+CfpBb1o7p0ENxJXoOfuyNv9zAS8QTN3ZSVq3F2mmufcVYp473ly3nfDxRt fe87PS/rLp+d78ckdbC/UeSGpOYoullE8iAR+xXlvkjMx4Tjl35eQk9wIzmOrL2olNG3MBwX9LQ9 4VxH314YznX02N8y89Bz3K3wn9Eua8OZSvcS3Z5gJfALSr9Me7WMF821nN5bVXcU7XT8aY8/A/En A7mKWpNRGWf8MmPgSX447vS+vzMW7MDV8afknYV+Qu8oSVkPMjYZO8EEPccxsr6jxBheWcZLnvof H6JMbLky/ieKQYlGMshiFLdTjK2C2a2yn6no3cr4Wqwe2vOxGaeUNpSbpfWNT9RnEsRyZcl1UFFG nMbtSh0LzmzG4yo82YqFPPL2gy+Ab43mjHDUMIKGBLoqaKPjxXIusOcR/zLde3dztJ84TzLP3+j9 iZGrPapDoBaaRaNA9fvQA3Ppw7/D/uu05lH/fpHfpyyDnU3KyNnkfnqs5r2JXIvUWnKN7nLb6Xqu 8TqCX4HrwTlgd0W/BjhTUc6YoxnpyjRDp7pikIBZxJlrP3xF5BLkXaROAccpxjoj303qmtCm7rHb GNG+SmUvwEIt+P1ge02Vc5DqX0jqeNpoNKldwPHgfEX3FXCDoszzldVblf3j6JyglObIS5Dv1TOF vwi8CjyhGKzAz/oqe/vgMzinXKcoZwplqoGb4VvorqN4oniXorvQ+52OMkX7FPyfwb+Cnyt6zGZ+ dzz5D5gR3GE03jHxYQcRW0uNKlnpP15NyjqfHc4KyF8jD8bPSyj3y+A8Ya4h9TFsrqd/9kRnNzFs TTzzqOPtaMbQ3EXtvmB8cd/Ka+xv1X0hIjYNnRu9byV1J7mmozlWz2W2F3mH6z6txxnQb6S828J7 nf20LFpB6z5Ae77U/S72adWrK2ijsX4tXa9q3f23fAcd3U/opDHxz9LUYISe0bxFfib6+tcRLdHc rWWJvnoyxvbXvSnuqI5QJuipuYJKKvvb1b7zip5Z3EUwY31izigrU97e6H2pOz+hTb0HHWxQHf9K WmE/98df9OSaMXgH/5+mBXtS3/v0/qx7QuvoH8F+U80bTELeoedBry6tcK0dAIq3do/9FtT4vKi9 wuNukVcHnbPR+QBsregukisex3ZT38RDlR9X9G5UlFpcJ7hNvXVbKCPrtOt0r0z9DGDscfBFtean 232S+g1xy9H4SGQ0PneQdxF2vgQXcUd+jr1BcF+Yqn66c6h1C28wNtWTpdgfpbnsEK2d31RR6mWF ORz6zL3sa0PUeEotVH+s2vcu17Ot1z6qke5mDIPnnldwF3UpAq8k/r+mlxYSt71eQ+Fdtek9SuoY cBA9qi5PQXTQsvzmtGlz+nbHsDXB6vTYqfTzN+nnDyK/r7K3jN7+CnNFAs3RWLgk1KGfl6CzAb4m +7rnwzTE2hFKGcD4fYlcJ9C8nlF8M2e3tti5Xp+Akl6ha61rdGSlM1+lddXU2OOKccMcm82ILlCM 72GWbgFuxMOzVDOdGVvyVievxuQBRsojjL769IH9MI/pHWopdwqjQ1dTaxXtk5xTinXt6j/BbPwb Ij/df4Nx+ga5GnEWUHkpa79FzGMzPa3Lm9qm/vhwbldrnkOf6U+vKKBH7aanPe5J//dv1REk/eo4 a78B9Ac9mxfjf5zSWUMmv+KvgIzuOLnH2OMaCZYl92l7IU8C+0Y8Ty+A08K9O3A5u2QDQTfUTMj1 pttS7dgM+BL4PPJuUt4pBROUFUc+ilyJ6/pKaFblWYjRMHHkA1Hpqt8hsqCWW7LnWRTuxKKTCK/f w6casLwY5C6t3R75ptgAvjNX/ZPYlRqJtQ5olpA6Fx/2hl6hyTW+u5yrfhc5js4e1TcHYIajnx3W Dsst8SoL/hL0d+NDOn52RL6EEmsj/wbNXWg62OmGV6NIvRK5cshHZSkeIg5t0BmF/AIW1oBPUlYL fYbB7Yp++ARINqnDsdkDnYEweaQW49V5lFUI/hF8Ewz7zIXkDSNMrS02ne+w9ik688E28N3I25X7 5ofA4/izAPwibGs0K4JLw1LItRMsgv9W6+IUI4e7yrlo1qXPbIVfxb7xWzwDE7Dr+5bmsvXRn47P +OYNRm6I/zmkhu11EPlXxORF8Hl2pWaDpbTvwqiHqLwHPoFcFmlqroVRHyshlyJP7LivsOcZB/HZ /QzPS5EnIa+N5GGMlPngMOy3p4+V0CeVn4HlqhHTHlnrNZAdrSroxJHdaDdYdbJ4buEAuVri87TI 2/mMiBJKYVzAHA3HNXIRmnnkrQTm0Ubs+8WHqGaMucL/RDG4S1P9N6jRQcVYa2WC52idv4O30nvP Vz4+kby0gjOOXK3xeUbYq8EhtPtw/Al3pIvwIRwLVcHz0DyWfJY5bQ7z3rPUtAe10B1R2t25kT7T gTo2w04v6p5BXz1A6QlwE1gIbgFzsfA78r4Ovk+59FL3JqwtUl68rCdMb2+PIj1wpNdZ8HXucr7O nuHr3N9vyHMpx2OSapbG1Yd18S5gD1CfeloXK+bp3NXgpdqv/Ho8hVukz0TxpHqWrkvNcT3XyDVd ZeW9g4Jv8JTvIZgvwY08+7RRdybNTr0uMzX0nGJasQ9ZD6wMmggH8ERNLjuQN8J8Cx6EqYwsZ2ez IvhI53ZwRUw9HA2uCJDBFbGr4a9GboXcCp3H0HkMeTKyPq9YnfVAdf9a8EvFYB7owbQDm2ou/+9a U28j8nrsPELdpyJvA8eCreGH4kOeysEz5MIrXY85c72nwd8q+r8EVypqXsEcmHnIr+r8plc6zgL/ t6BqLkBzAdeqCyh9s19DMbhJ2y7WE1k92ax7AmaZPmVtXld0bvK/kXo10Cev3AbYLFMLIk8GpyoG PtgJ1Gg0iLmsMa7nevkpRfYZcrW9RJ4CrlMMOsN/CB4g13+IPMgbAr6k6N+MppZe3TtONC5SOehJ 3fX9UNvxvFRLF7422I3UWzQ1KMX+X2gXRhC5DoXIc+mHyJvrvwh/CyUO0jnZ60DqWfA8sUz/ORRk wDwK1gTfoE3fpc+s0tnVH6Xo/QpZW7OQNVgm1wVjPX2yepWimxncY3SvtY3y/h+VB8fqClnkjsgj kEcgP4j8IPJ05OnYkXLdGyg91/8UfAZvXwP/Sb0m0d/Ow9t/6vrE20wPOUfPg+qbaOq7tw7FeoAa 55t4TvUcT58tn+21UPR/LviZPg/pfEZbf6ZPyglqf/sslovck548S3BfoO9lLtUnKs0+X9sox++t 855XR+WA3WntV6aUkbIv6C5MOuW284pBHemjdWRJa1bVudH7DP89UJ+q7ewPAC8CH1cM6pN6AKa5 nkGCMDXkh4L3UCPdUZzicT7V52+dKXYo8ibkCcgw3h9hPoEpQ34PfF9rrWtmt4/7KJHRZ0372Bzk K5CrIV+JfL7IgzUCZoV9gX5ylcbc1AHv0JlT79Imd/FmBsMbwA3MYfMGOk9oNMxwlZOe2gEPJasi V0VHUp0GSZ1J5pvLkOeonFyH/Bjogx3AieAfsfMNSA/XOV/kKci1wXPBr8FbSb0YWf/6uTRRiTN1 G/AbzuDDwJ7gufABchVwv5Q7GQ97gZO1LMH6yoBrWSf0J/U+cLZ6JbyeB2ck67E+eQ3Ua+fshJ71 WiYXag9XH5wFhnsKic9B3XVvn3xE8buF4Heis4Nab/9O/yKjVFHsfK55yRXDTm4UGfUqV2vkDAox WZFUxYKEjq9M6p6P/s6EznWtk2vALeCbWK6NhxWRuT+LtQWKXiPNK9cUWu7SpFxbOT8nhjY5RjEx CfkqHRHobMKrzxJHpcRHNMLmkURSsK3aF5+3S+odaF6o71CRaGu5s5PpypDaLvmJ9p/E/dSrFnE+ gOXGgusSz+lIVH25htKxuQnmUJIzmjIi10JeAo4XnecT2gOf/05mJGcn640VSb2GLU3KbC+riyZG r7/qEj3B5DyeGf7W07HjcX4/zoj4vfZ/sd8Yy/r3BQXEc4GirDxrM5bbMh4PMzPfxJjdzui2pD6L LHNLcgpn3p16jjDbgnC2n419OeObl/RZGvE13WnubzR+n4I+fU2tfvcX5JsxdxYMuMvMGjSgb4FZ ld/n3rtNsUTRbXdNl1qmXrcubWrp73okkybN+MLHzYWmvvm5ucHk6tPX8IE5W/Ai08A0N/pmvJrw 6SZmKgnWMw3NpaaFjPtGppb+DmSUWs2cY2qbxqaludq04Z28t5SnniWtWdnkyLGJuULKb2vkrGy6 lKe75lyToV527Nq+lsnt2uXGWlJymPN8U0VmnUzT1LQy15h2vJflVtIyTDa/i51lmsnYudJca643 NxlrukapF5iq5memgrnEXG6uMteZ9uZmKbGb6d6v2Yh+bgBWBKuDdcFG/frk3+s2B68C2/TrN3SY 2wHsCvYCB4EF4BhwPDi1f/7gO91Z4DxwIbgMXAWuBovB9eCm/nffM9TdDu4BS8FD4FcDB9/dxz2h aF0wPrCgTz+bBVYFc8Bc8PLBdw++17YG24EdB4+4J992AfPAXlJsH9sfHAaOzb/7vqF2IjgVnAHO Bufl39Mv3z4LLgGXDx3Qf7BdBb4KrhHFAvs2uAHcBG4Dd92jdvaDh8Bjip4B48MUK4JVwGwwB6xX IC56jcBLwZYjhvYb5rUGO4BdwV7goHs1VwE4BhwHTgKfMPr+l/Okh1T7N6Tv35P0A1oZLXEZLf+V pHr6Jyau9Dz/FCaV5MoIOyflsY6pe9LRkfFyJvtDar0fxbNOQysjpQYvm/6pkmMyz8D009CTkVdR ZpJzfkR2ZJb5MeQJlig+4XuGMs7Amj+CrsxQOT/h6Mg88WOYdRpamc/ON9n/huTK3Hjhvzxebu42 I81DZoKZKueSueZZU2h2mYPmqDnheE6GU9nJduo6uU4752bnNqevM8QpcMY445xJzhPObGe+s8hZ 7rzsFDlvOxudrc4up9Q54hx3XTfdreRWd3PcBm4zt6V7rdvB7eLeZgL9407nKLOw444Pj7FDnFec tGlG12tO2kyj52nnrFbh/8/S3RL5ZMwRPs2cl7EyY13GtowjmV5m1cxGme0y8zLzM8dlzs5ckrk6 c1NmWZbJqpzVIOvarK5Zg7Iewpab9WyWXAlIbierLDqeCI/nxsNjNf2FYTle0CE81oi8qbEi+n8Z ltJrZtdsUnNlzQ21htSaUbtX7SdyCnIWhGXU6VUnHw/dOg/VmRHmrlMU1q3Oxui4JTzWbRMdZ4fH iwqi4/bwWK9VeGyYbXiitGFO9P920bFvdHwoOs4OY9lwZXQsDvncjOhYLzpG5eb2jo5y9a1tkjsr 9Dd3RRiNiyvpX+DLsU3IX7whOu4Jj40qRseHwmPj9FC/caswf+POof3GQ6KxVIm5QDn9XSArZ+tO Qr/gvGDcWMtYS95Q9T/8O1D+EF2PODnupbadlydjpqWczzvIGuE209cMMQVmjBlnJpppZpaZZxaa ZWaleVVWNuvNJrPd7PlhjMRWGhtbEns+9heOhbFVHJfGXuK4LPayHJ8X6a8cn4+9wrEw9jeOS2Ov clwWe01i8XxstfyvULRf5/h8rIhjYewNjktjazgui70p2oWxYvnfUtFey/H52DqOhbG3OC6Nvc1x Wewd0V4ae1f+t0y03+P4fGw9x8LY+xyXxjZwXBb7u2gvOy0i+tvgo83DPykiG6n5ktgHUWRKosh8 GEVmUxSZzVLOktiWKD4fRXHZGsXl4ygu26KIfBJFZHsUkU+jiOyIIrKTiOyKIrI7isieKCL/iCKy N4rIPiKyP4rIZ1FESqOIHIgicjCKyOf/IiLfz53/VUTKooj8M4rIoSgih6OIHIki8gURORpF5Muo x3wVRebrKDLHosh8Q485HsXn2yg+J6K4fBfFJRFFJBlGJG7CiMSdMCJxN4xI3GpE4l4YkbgfRiQe hBGJx8KIxONhROJp/0ZE1ph3TYnZxrvaj5jjjuukx9PDiMTPCiMSzwgjEs8MIxLPCiMSr6ARiVcM IxI/O4xIvFIYkfg5YUTilcOIxM/ViMSrhBGJnxdGJF417DHxamFk4tXDyMTP1x4Tzw7jE78gik+N KD41o7j8TGsarxXFpXYUl5woLnWiuNQN4/JvR+RgeUQujCJyURSRelFE6kcRaRBFpCERyY0icnEU kUZRRBpHEWkSRaQpEWkWReSSKCKXRhG5LIrI5VFEfk5EmkcRaRFFpGUUkSuiHtMqisyV9Jiroshc HUWmdRSZa8LI6JlB/dbzgPOEzPQZ5m45EcTlnJAtK5AmEq82co2Vl7FRZvrr4rd4T2R8EEnTM0qQ ugj3YSRNz9gkUlv0NkfS9IwtSKr3USRN53dN6so1Y3Npj46mu+kts/q9staZmLG1vKSPy0vaVl7S J+UlbS8v6dPyknaUl7Tz+5IySkW6Pn6dcAciaXrGQaS2wn0eST/m0a5yj3aXe7Sn3KN/lHu0t9yj feUe7S/36LNyj8rKPfpnuUeHyj06XO6RjH2nkdNIloPVXb0fXsetY/TXVGRVlHkJ6657pdUelmuR M3w2s80C6c2rzEbpx8ekB2c4VZxaTgPnUucqp70zUvJ6ZxUZl19F8M56o1xa873kvifSLKT15dL7 5dKGcunvSK6shTLcjSq7uwVnkvZBuVZJufQhkpVaZJnK7iZyqCePu+rFb9HZfJJOFVd9mum+aaxo znS3lFv6qFzaWi59XC5tK5c+KZe2l0uflks7kHxp/8rS53NMPVfOz+5TUpacn925clwrGk+56wTn ujvL8+2K6h1zp7rTpI3muc+K/kJ3iUl3C91CU8Fd5v7ZVHRfcFeYSu5K92Wxb1nbV5Zx5fBeYWMa mvA3BJ+WhMXuYrG5QvSt+zf3b0bfX+i6M3izm/42nLa9zPRcOabL1Z11Z7uzzQXuHHeOqSE2XjM1 eVPb1bypTe0fkSu6bOnTrWXO6yFXE6PNfLNEzn/7w/ayspJ0v87MM67fImKuh7kNRmqZ2VOkllHa DaT94iTtDjC/LNfugbbPbxlWlavDuuQ5SjmHM7tL6hXk+ZJyjpDndnKflEdLcI+qV5Lnl6qt/rhH VNM9FpasJblfqXfuF1jprp4Qr8P6NzJ+C/8K6T36O3c2eDSY4OqukrU0gE236bpPaTNY7er7nRyH tz7JN5ffPCl11gtXchJn9Q3azsvCrj6JdXjPy6JT8hY6el9j1il5Z8tH/0pz/Ems54znM1X4u0+x qev+7qfYvE1/FdVpc4rNdvLRew9NTrHZhI/e26h+is1G8nVPsRnwWy+HTrYp/eWIo9dc2062Kf/T j7ZW8ck2jcRN5piTbJrl/CrXnFNszpWPxK38N71CmxP5SExMwSk29W+2bzvFZi85Q//wmy+hzQ7y yTc//OpLaPNSPhKT6M0RyjvRm6mt+42+JUvaPsOkBxOCR3nT56nv0S6/ns0ahbwAOXzn9YXyzY2s XoxfTXjXefVyTnM881NKyhod9kv7WXCB1VneCWoGtXVmcCaZIltqa9l6Ntc2ss3s5XacHW8n2Il2 kp1qp9kZdqadbefa+fZZu8gusYV2mV1uV9qX7au2yBbbt+16u9FuslvtdrvL7hVbB22ZPWSP+PX8 XP9K/2r/Gv86v61/vX+Df6N/k3+r/wv/dv8Ov59/p3+Xf48/wh/lP/Cf7J0HVBTJwu+rp6gmTFeB oAgICKhIpgdQMGAABVTEAGJCkAxKFhEUBUZFRTEHFAMgKAYUBSPGdXXNOa1ZxEXFLLuY/WoKZFmv e/fe952997zzHn2mprq7uqa6uv6/qapp+o/SUAaaiqajGWgWmo2y0Ty0AC1CS9AytBzlolVoDcpH RWgDKkHb0A60C+1F+9Ah9CM6jk6j8+giuoyuoVvoHqpCj9BT9BLVorfoIw94JV6FF3gNXpNvzuvw erwh34Zvx7fnzXlL3pq35WW8Pd+B78R34bvzPXlXfhQfyIfy46TbpeXSnYJE4AU1gQiagragJxgK JoKpYCZYCFaCKDgITkJXoYfQS/AQPIWBgo8wTPATRgshQoQwRogiaWQqmUFmk2yygCwiS8hysork k7WkiKwnG0gJ2UZ2kJ/IKXKOXCLXCP0OAYehClR0xlvD1pQV7WF7IIGW0JJeNWtoDZSgDMoAgh1g B8DDDJgBlOFUOBWowOlwOlCFM+AMoAZnwVlACrNhNiXlPDgPYLiIXm8Cl8AlQB0uh8uBBlwFV4Fm MB/mA01YBIuAFtwAN4DmcBPcBFrAElgCtOFWuBW0hNvgNqADd8AdQBfugXuAHtwP94NW8DA8DPTh UXgUGMAT8AQwhGfgGdAaXoAXgBG8Aq8AY/gz/BmYwNvwNmgD78P7lMsP4UPQDj6Gj4EprIE1oD18 Bp8BM/gCvgDm8BV8BSxomzEDlrTdWAEr1BV1BdaoG+oGbFAP1APYIhfkAkTUC/UCMuSG3IAd8kAe wB71RX2BA/JCXqADGowGg47IF/kCRzQCjQBOyB/5g04oCAWBzigMhYEuaAwd63dFMSgGOKMElAC6 oSSUBLqjiWgi6IGmoCmgJ0pH6cAFyZEcuKJpaBrohTJRJuiNZqKZwA1loSzgjuagOcADzUVzQR80 H80HfdFCtBD0Q4vRYuCJlqKloD/KQTnAC61AK8AAtBKtBAPRarQaDEJ5KA8MRoWoEHijYlQMfBTP agVDUCkqBb6oHJWDoWgn2gmG0bZeAYajg+ggGImOoCPAD/2EfgKj0Cl0Cvijc+gcCEAX0AUwGl1C l0AgVcI1EIRuopsgGN1Fd0EIeoAegFBUjapBGKpBNSAcvUAvQAR6g96ASFSH6sAY9AF9AGPRF/QF RPGQhyCaV+aVQQwv5aUgllfn1UEc34xvBuJ5LV4LJPAt+ZZgHK/L64JE3oA3AON5E94EJPFt+bZg Am/KmyruJ+HNQApvwVuAibwVbwUm8Ta8DUjlRV4Ek3k73g5M4R14B5DGO/FOIJ3vzHcGGXw3vhuQ 8z34HmAq78K7gGm8H+8HpvOj+dEgkw/hQ8AMPoFPADOl26TbwCxpmbQMZEl3SXeB2QLtdII5AhIQ yBZUBVUwV8ACBvOEZkIzMF9oIbQACwRdQRcsFAwEA7BIMBaMwWKhndAOLBHaC+3BUsFcMAfLBEvB EuQItoItWC7YC/ZgheAoOIJcoYvQBawUugvdwSrBVXAFqwV3wR2sEfoJ/UCeMEAYAPIFb8EbFAhD haFgrTBSGAkKhQAhABQJwUIwWCeEC+FgvRApRIJiYawwFmwgU8gUsJHIiRxsIpkkE2wmWSQLlJA5 ZA7YQuaT+WArWUgWglKymCwG20gOyQHbyUqyEpSRPJIHykkBKQA7SCEpBDvJOrIO7CLFpBjsJpvJ ZrCHlJJSsJeUk3JQQY6RY2AfOUlOgv3kLDkLDpCL5CI4SK6Sq+AQuUFugMP0O4GAadAEWkAROsBa OAcuhDlwJcyDhbAYlsPdcB88BH+Ex+FpeB5ehtfhLXgPVsFHlPxPkTmsRebIEs5G/dEgNAQNR6NQ IApFkSgaxaPxKAVNRmvRerQJbUVltJ3vQZboAPoBHUMn0Vl4mb5fRTfQHVSJfkFP0HP0Gv2G3qPP vITneTWewEeoP68NTXh9PorvCI35AD6YD5fuFpQEFUEQNITmgo6gLxgJbQUbwU7oKHQWugkugpvQ V/ASBgu+wgjBXwgSwoQYkkGmk1lkHllGcskaFm4iW0kZ2UVOkDPkArlCfia0Hw/kjMiAEZljLJYw FkPGYiXGXMRoyzPOKjPOqjDOqjLOqjHOShlPBcZTzHhKGE/VGU81GE+bMZ5qMp5qMZ42ZzxtwXiq zXjakvFUh/FUl/FUj/G0FSOpPiOpASOpISNpa0ZJI0ZJY0ZJE0bJNoySbRkl2zFKmjJKtmeUNGOU NGeUtGCUtGSUtGKUtGb8smH8smX8Ehm/ZIxfdoxf9oxfDoxfHRi/HBm/nBi/OjF+dWb86sL41ZXx y5nxqxvjV3fGrx6MXz0Zv1wYv1wZv3oxfvVm/HJj/HJn/PJg/OrD+NWX8asf45cn41d/xi8vxq8B jF8DaV+oNRjESDSY0cebEceHEWcII44v48tQxpdhjC/DGV9GML6MZHzxY3wZxfjiz/gSwPgymtEk kNEkiNEkmNEkhNEklNEkjNEknNEkgtEkktFkDKPJWEaTKEaTaEaTGEaTWEaQOEaQeEaQBEaQcYwd iYwX4xkvkhgvJjBGJNMeSDFIYXSYxOiQyugwmdFhCqNDGqNDOqNDBqODnNFhKqWDJsiExtAc2kJ7 +AbOhgvgMpgL18C1cD0sg7tgBTxIW/RReAqeg5fgNXgT3oUPYLWijVI6vKF0sKB08EQDkQ8ahvzQ aBSCIlAUikOJKBmlogK0Dm1EW9B22op2Iwu0Hx1GR9EJdAZeou9X0M/oNrqPHqLH6Bl6hX5F79An nuMRr8pjWI08+RaUCq34sXxH5ENj/nwQH4buS3fQwZeyIBXUBS2hpdBKaC20EawFmdBB6CQ4Cz2F 3kIfob8wSBgiDBdGCYFCqBBN0sk0MpPMJUvJCrKahRvJFrKd7CTHyWlynlwm1wkd84Pp/58Q/w8R QtFL8Wac8GGcGMI44cs4MZT1TIYxWgxntBjBaDGS0cKP0WIUo4U/o0UAo8VoRotARosgRotgRosQ RotQRoswRotwRosIRotIRosxjBZjGS2iGC2iGS1iGC1iGS3iGC3iGS0SGC3GMVokMlqMZ7RIYrSY wGiRzGiRwmgxkfUoJrEeRSpjxmTGjCmMGWmMGemMGRmMGXLGjKmMGdMYM6azu6kEOkKOAz+A0+Aq HcU/AbXgM6fCaXL6QI25lyq8S23oWLoz6AHcgCf8lWpIDutoOA2+o+FM+IGGc/mZQIKceTqeRd35 iTTsyafS0JXsBhI60tpLw0V/kuNvLMe3LMf3LMePLMdZLMcUluMkluNkluMelmMFy5EDSvwURWoW S2uMpTfGMhpj8sbY1MbYtMbY9K8x4XVj7A2LSSgd7sJ7AKBP6DOQUKZJaHrE02EsZZsaUKFMCmNe MYqZARU2K6UpPU3Jkq04Dj75Pc4r7krkFM9gBYqZNDXQlqXWoCmUGtMqNaRU7CEwjdKKbq9/Z8dL 6v9nj9ahIgcdNld7hh71Bs6Ft+uPIoH1qevf4RN2VAk9SjHppQQsgAg6smeSuwDQsO3rlamfw7Bh 5XzAQjb3oXhWLA030vxJ/bwa1ISalJXusB9QRQ7IARDkhLoAdb433w9o8V68N9DjffmhwIgfzo8E JtJiaSloJ30v/QJssC8eBRzIYXIUdCV3yB3Qk5VCmZXKhYYewAv4gHrP3/o99aXTb2g59aW0ZWVa w8I7bBYcsvhHFt5lZ/2E1eTfV2Z14EtLqfglOo6+kmg8FchpLAvMp/GlDXNg9SmtgB1wYq2+B/Ck 8cFgGI2NBmE0HtVwTiIrewUL77Ez6Ahf/n5u0tNszykW1jaeoWLtGQvLWFj5t55zc3a2ivtRptFX Fo0rfjWbAlaDQrCxIVZKtyqe/rmv4eybN1zbvmAgffnSuKLW+jbkVB9LpVvlDfUg+1/WQ0ZjG/jP 1IkWvYpRIAEk07NPpvWSxepkJShoslbMvKi3NNSI1u8MpC9FW/AHIaw+fl9LUtyTCRqevAoUT/lS hOUN5/NtbWQ3OectLFzbRLu/NNTV31kLHHsebFvw9d41jYbSs9+oyCFFqK7esM+GvvdiiyKFQ8NW Hcoim4alfrsEQGm+tAAAaaHCV5FUs3nYpvOomqDeiUZJUg0kEsX9u4onONX/OpbIakkx7xsCbIk+ MSCGpDUxIsbEhLQhbUk7YkraEzNiTiyIJbEi1sSG2BKRyIgdsScOpAPpSByJE+lEOpMupCtxJt1I d9KD9CQuxJX0Ir2JG3EnHqQP6ct+c7CSDAeA+Ucr+OwBjPEnIiHqRIs0Jy2INmlJdIkO/oA/4s/4 CwGEI5AoEUR4okxUiCpRI1IiEEwI0SDNiCbRI63Yr3//4LhMe/wq9Ls9AE/Ek3Aqnoyn4DScjjOw HE/F0/B0nIln4Jl4Fs7Cs/EcnI3n4nl4Pl6AF+JFeA3Ow/l4Ld6It+IyvBgvw7l4Nd6Cl+A3eBUu xCtxES7A63Ex3oDX4c24BG/C2/B2XIqX4kpch5fjcpyDj+Az+D7ejffgnXgX3of348P4B3wBX8KX 8RV8Dd/Et/AdfBdX4V9wDX6Kf8W/4bN4B96LK/ABfBAfwj/iY/go/gkfxyfwSXwKn8bn8Hl8EV/F 1/HP+Aa+je/havwIP8ZP8DP8HL/Gb/E7/B6/xC/wK1yLH2CF35QXUGV3VbZlbqCKX/NbMcdZE+Y4 25Y5zpoxx1lz5jjrxBxnOzHH2c7McbYLc5ztyhxnnZnjbDfmONudOc72ZI6zLsxx1pU5zvZijrO9 meOsG3Oc9WCOs32Y42xf5jjbjznOejLH2f7McdaLOc4OYI6zA5nj7CDmODuYM+aMgTdznPVhjrND mOOsL3OcHcocZ4cxx9nhzHF2BHOcHckcZ/2Y4+woTuE4688cZwOY4+xo5jgbyBxng5jjbDBznA1h jrOhzHE2jDnOhjPH2QjmOBvJHGfHMMfZscxxNoo5zkYzx9kY5jgbyxxn45jjbDxznE1gjrPjmONs InOcHc8cZ5OY4+wE5jibzBxnU5jj7ETmODuJOc6mMsfZycxxdooy/QNpzHc2vUGx/1tV/jPF1yt2 hGQGVewsySym2L7AhKpToU2FCht1S/X6ialV8o1eFWptotV6fRPFfXZKnA1nT3PWkGgBXtJCYgnU JHMkcxQu6Zwa7Y//nyl3JVXqKqrf1Q0KLqBqLaJKXce0upFqdRNV61aq5W1UrdupulcwfSuULf9G vfXa3d+g3v+8ds/QWhrQoN1eQPGfV5Egg2p3Fl0cQB7IBx1oP6IUOII9dHECV+jSCdynS2fwgC5d wEO6dAWP6OJMxy5PqGqf0qU7qKNLD/CeLj3BR7q4gM/gC9Uu5CBVLeIQVa0ypwzcOTV6LTzogFCg 2qWXl2pXg9Og2tXkNKl2m3PNqXa1OW2qXR1Oh2pXj9Oj2tWn46NBnCFnSLVrxBlR7ZpwJlS7bbm2 VLumdFzly5lxZlS7FpwF1e5sbjbV7jJuGdXucm451W4ul0u1u4pbRbW7hltDtZvP5VPtruXWUu0W cUVUu+u59VS7G7gNVLubuE1UuyVcCdXuVm4r1e42bhvVruLezAhuB7eDancXt4tqdy+3l2p3H7eP avcAd4Bq9xB3iGr3B+4Hqt0fuR+pdo9xx6h2j3PHqXZPciepdk9zp6l2z3JnqXbPc+epdi9yF6l2 L3OXqXavcdeodn/mfqbavcndpNq9w92h2r3H3aPareQqwRSuiqsCacoqyiogHSfS792M+m9gwPpw 9Dv6q3OzSUOfoAO7i6GCLoAMIf6KPhx9aTXcFa0H1Eg/4kn6Ey8ygAwkg8hg4k18vk2DR+NAHISD cQgOxWE4HEfgyG/T0Hhz0IKOcOrv1q+/85qmocdG/lU+eAwe98c+BlH4pzLXYdouOeZ4rELHJxo0 b6OvI1us8DbtAzzxBPY+AKew9/5Y4cjZBxykoSc4pGj9WPELcH+WW5+GkozBY3EUjsYxOBbH4Xic QEvwr55RfWn/aT5Nz5rWuy8ZSoaR4WQEGUn8yCji/29fBUJ7bFek6uoUhX9yzzBHqar4nyITOgLq SHVZf4fQKXZHy+nGO32qFJ6lLPawMfbL1xg/QZH6L+6QaQvUaZ8wgkSSMWQsiSLRJIbEkjgSTxLI OJJIxv/Jb/Ic7bOr06O/jotdGsafI9jYrL5XLyHJJJyFESyMZOEYFo5lYRQLo1kYw8JYFsaxMJ6F CSwcx8JEFv55mbQbW9w+OrovhFV09P11VG7TONOgTQ4CZTr6hXAN/Ajvwid/XG8YEynGyHHsGMWd VGbAgyhmL+/RERWkYwcIT9F4LXxCY89gGY1XNuzv+O/sp5/VuL9x9Da38VPtgB85AJr/yadmKMre JP/6lN/7/H8hZUNJMtj5/2OZHBpr9hDQguV0T/2xijmaLXAtrelfmqzVNhypGHs1Z0cickhdXV1D vZm6ZsO4hqmAJJEJJIU5SX9/xPLXiqsnI8f+a09g/1MAAJK8hK2UwpUilCIbUnD1qQDQS2Qja/an FyXK9SJ4VYtMj8w6zClL8uR6w+mmIRKOk0lFVR5ZEijRQ0AM5NUsedqNlTtKOKU8b3GQaNVki36B Ybo+FYFiGUA70+NALJVAKEikr26KRTRukplS80hdcOhOXs5FE5cAizqPB6/ju7u458lb2IpypeWi HGbkQdptlmjRnhBYZZjdfsvuN9fZ0xHAKhE3llbxfGwxhRUTDlHitSRDvGVaYjPFioqW2tDAcRGR MeGJsTEyDZEoNiprKQ8ODYmOjQmRGYr6ii1qWi36RwYnxI6LDUs0co1NiItNCEyMpEe0EY0V+6GW XtP9IaFG3pHhMTRXo4GuPUXDllhmJ3YSHexkDvR9BF21F+0bV8WMqX9L2bAoVeyXain1HzBw8Nfk 8E+Si3LOpGmd0V4MlNPhBt2uJpFzHNhb2CdK44PJytAC7ZwupwKD3ieal2Tzuhfjh+lm+Q/FkUEx HfO8Ppmk3DP4SS9w7vuPa5u10z5+aJiVLGvmFjvDmTfTuiUOrZte2NH7ZM8XkbsjV0f71sRUbTft P+5CSHx566uB02YC4xcRw6aO7DOv/O6lDldP/Syu8f44ceyKaZa7jMMTL/+WvDNwRs7iVItz4Y91 D/y8N/hZV69ukyU1b9K2nlPflTGl9sOjugUeFfOc5xxXXqT/Zv/4qo/BRuZrOr3p6eNk6BPSo3za Rsctb8CcSvw+f7u6yY71G7ZcbblHfClpY6Txfuxw9Xsla1aPzlgEPXFukG5ZxdJ9C0asS85Myo06 4/lUc4eTuwRSZayVc5jWiKqoRevSoJ2SIKrxKrR1I6QMoWig2EiUtJWa3xl0q9Vrw76ou6b+4X1H ykKtFqAcsbVidxslHVE7vfmpZo9OXizXHsadcLSx19be47lCrbXoq0jQWmmA2F/sl9cnzz2zd0Ri YlxnW9vghCib6K9XzSY4Nto2bmykYqttXEJsyPjgxHG29KLShkebHW1xAaKTtb3M2k6UiTY0kTji axk5TslL9BT7fl0XJZndGj5iwoQJ3/uI0IR/mnfiNzKDipZiUVj3/NAR04lTg/SSV448+ulpix/X J2tdaOltJhWAS3cn9Vm3QnSndUjz2HOuZuKs/DMDNtyreOau8bnljRmzNC54tsh72ezLjaXnQs5l fLJffyR5UVXqlegZ8Vf1AytPe4XsGtf93aT2Dr8N7u7ueohkxHkfXsoV9Ks4aAEnTIr5cN4tq6WZ rAg90M7a/apvZItR9u/upi3u6t7bYMvJ2T/VzTR88nmBsGaAsuoz04UxZYt1ubcBGdVbbsyalzbC f1rAjgOpbg/dt34eZrkgbcYtt9aDlpw+EpS/46eAmhORfvELNmT7Gll19lr0KZefV5L1NmJKl70p Los69fn1vP/TuGyX8UflQ+a32jEkkMLpCIXTpiZwsuxk53F4+wmPN4ymlt/CacLfAgBj1uKo4nV+ 3+8TGR1q7Z0YGB33LZpkdvYODE10w9dVMaPsP4Gm9mK7+lXDGNfIuIjQBKNe3r2Nent7dXYV3Rys 7UWnjta9ers5ydqJberPSP+7Z+QdmpAUGRz6lyhbt1MkMHTLwBGZY6ev8cg3PHHouX8f5en34pam HtgTEBTAm16a3alCx6TIZmHJ9X4zO+ttzZ265bh/pzk/2E3STn7m6NT5VdCHCLkk4mlNRY+sbZ/z rToGjY7rNDqIfDim4xRbuvBqD5y+DifP7jg2M8u0pc6X0pr+eyvMtX7x85gb59bR9LNDh00O9+tu XPd7snyybFf/1kNrUq8uwWGCIbFr2c3qSnr+2Zq6nAWSW4cDPjmlv+2UNirkpKNfl0EjR00POGuo /8HhQMBDsyFxPit3P00FQ9xGmuWY+Xref7VXVXdphoeFeLzO3iiqOvJI2eUjXudEQ8fLOYMvb2jT e/sWv559BpQHRSz6ijJVWiOoCbWKdOy9uy8Zne+q/WLusa0XLfeuHnb+D9Rq4/D258FucWrPenxI +lBmWXqkQ5m66FNPLcoskTIrr3em679FrfrdiqvILiJtlYxZw5owixJL9GjCrK7/GrO+m3Pi99Ct 8j2MTTldOumh7YFq3x3nxt3cOPiCdqdj5WfeX/tsGLqj2uNNrttMFDbGNNP/84xht44Fz3VKr1Vx S7Uct40c7Lnx1E8bFxc6vgzpdP/olXdnlc9uqmr3MnLLZbfKz2F2Xa8tO2pn/P65Xrs8f8HFqpl9 Z/nUT88Myg6cXVC4oF38nk0Jpau3Vp0DQbPiNuzuO3DOc1uTkKLiX/qPXWKln/J0/VrZjfmj5xfG fF4kwd2t2uJjY0wzBk3tq1ExPrjXxkiVY7Cm8pz0mW/npy8S1qsJteCSye6tJgll1T+ulJrlpZ98 cP9apzCx2q2lTvV7+fvh0on7ivFn/S9wdvD2/pqSNgOsy6ZP61KZ7/7oXAtRjvZRjBXWY0wt0N5U j9FL9i29AhgW1FQXms5a9NoqhNPVhvRayHTFln/YqNp4qWTWomW9jtv+ruPBsbEUEvTaRYZFBgcm hhr1HJ8YEZsQmZjCKCWKTpRMdrJO9naUUnYNq3aK1f9m3+6vULM9Ybifrhhy0GDFaCMjl+VJ3lHd Wl2NPX3q1ZOxn5dpa9y72zlxqt4u2zy7p1/u/ODi1eZKArjZYajarJNbjPrUvozY3L9fdtH+lH7x ue7KNz61u7tq/MxzG8f1SruWcfPN/tcdC0/49b61tcT5nlnEMr31RQnjfF+1XFz1qcPihLyrSQGG E3pPne6kfX7cSLQ3fHB20fZI2xu60s8LE80rk2x9bjcXh7+9mB306dSJADfZwD3ttap6iOcSzDXM TH5y9HLOs3OefybfiZ/u5+UrN7NAdrv6XRsQXH3ROuhVb+fqzSrgN7f81RdGzjH1fjRxY9/Xbucc uzqtLp/gV9RydfapZvN8ux7erBoAL31FjT+tkRGiukJ6Whz3RQmJkL41Yc93O0SKbwkDdSUl2gIz RU1etWEc0YJTQixj+nXQuE2iyOXTBZnXJdOsJfdzRncplsWu67rvurWo25iouURJMFQD3mA8HXu4 gp5/gBvZLB/dw7f9softtD5a3FfzXjK8qlAcWA+3PqK72DvPNa9nZvd/HW6NuxNo01ZQiYHNpwnY PEQ3sVcTsDn9O2BTCMa1Ptd/7IZJODC8U7c0U7etNbE9ttntGFNDbGOK+9TVBIx/5tnF+pprifTz qcfWsrVtTqcOzEk3HrXZ2dZzb0Gx78oHcRW7y9+m7OiTUNftSc+0k/eFlpGnilYaWb+XDvzR94z1 g74X98VVF+MCWOR7b3dWv6Gvl7isfPXmxfMHma0duu72XfHSu810i0K5/qLKxcoGryu93s7JP/lI q2iB1/FWF+clLLGIj87Ve6v/0vtq+GmTL34GZwrm7G+/PSXYt1fBoDPvHq8d5ns7V9K7l21A7Y0t l+V2MR8Ll2hV1URWbyiwOnDcUoOEzl1+89eC95qmqqFOi19NbN234sJ930fnk5fq+J3ooB1we5FB n7nWB0oceuk/12ihB0bd7jDS+GzOT6rPp5M5A6KJlpdzqrnHyoQLb6JOHn4at3bowqGTF2fntfKA I+rOrQ1XSyzq+MzatuXxXxIcNWtjt3UNl78bvD3bXjvUkGTd1rgTUht71u3ypZaPU35UKr/0wepu 66zVm9U+aLXvUVL17v6GNLcK5dHuoaN7eJW6PPV6VpaUcl3NQTVaP13WupL43H6Y/+Ghu0ZJSM6X gdo2qQeR8cTKJT3bRx5ZNG/JiezrucZbsN/KlwVbMiOmCmOsK5LGAoOlJa+1J/2mPbXtnpnnxhS7 y2xX3HoQ73wNTAlyv3B25ondOu9JQvbhtc5bJT3GfInMXVqpUaxR7jhQ5eoRZ1HOK1N+v/jKb+0I B8Zv/f8Gv0VH0UGkxO5gzwbAdjK2qhgG0wHwf637+1f0XpMfte3uTY+FFqljbXTv7698cHT5oDYD S87e1vFqq/78wvoLniWJolGzGuUrPkta9FncymXhlhw/0fQGGPto0v6ns5TV64hSzstZp1ufsm87 Y9Xr2nB9q4+TqmcaPKn2Wpt/uI33yez3vc+pnvffer7URang3bqoReHXzG65eZdmnn9o5mbTfnPm gCGDhSpo9WHM/PlizIw3w8VV76dcXVb2yHjZlLcXtd6o7PKOHlzee/4aD9DXPaxZe/Ow4mVVl/iM vgXvpq1v5t5cVb5m2rMhyZ+5FQYDVaYDDdHt2a47bdwqfrT2WbPVMLmnbMLp3Ltdpi7KD5TsMMDb PtblbufOmvTz+fIOHfnBSPqV3ptojaz/Z/T+bsfwD/TWaEpvugWIGTn18M2YL2Zkfx+/+cGFgX97 85RrpJRo5/fNKyrxHDesVlnLJvT/Gur/S11ZWtcay7KO+MFeHW8/Li+ZcPNsyqD+3DabxPiR0YLW prMHJs3bbXNZs2BOdNDuoZJTXkZaA5ffntijcmjF1mEr9O8bcJmbK5Jfzz7/tAv3vPLAPDV0PNuj 8qV3i9sDNi2sqs4ecyX98C+LX/O20+HjBRZtTeI+/PaxKnm5Da5Trozbp+O1au5YtYQlu/M7rQy3 PjqIPAny666dM9uoe6Wynt2707K+STJnywTp8Sdxzl+mq2nd/UEtcO7La7tb1njNTjvawdJ/7cGa fZOlLpMueycYPxdPViSH+o3kWqo1JxdvNM/5teuesGFl1rbV76Znnh7k+2hV3OKozZ08L/+WcnCj zsQg8xcFueYO/AS9oBPOhtGt5S+lP1lVnHMte/ju6eQdDwqLEzvs9joa30bTNEnadfCc+BFurs33 lZWV9g8/vsblS3qKcfrqFmLYIxdNf73jq02Mz7s+tnxcUetx2urydbt0T1MLj7YBI574vlh3Z/mq k51j92e0T+SbPU8yPpgrP9zeZ+e2Mc6z8pMCy2PytdYd3Oj+UjP2U5Zd1PbPdwcdn9PmRNj+VQYz NEMkztZbh8/bXWX8cEfpyeDyZB90uafNwM2LS4uSN5XlLR2v9/PCGVrjTWztilVi8kbOaXcw78W0 k8ZXawwHnFjxvM+9Oi40dpZ08vHI47/EPFm/7KzM/As5OtLvev9W+dff267ubjNEe+wJrbWfZHIl KmGl9RKOE6nc/nv95e9P1f4+45uX8aOiu9bQflWhTGg6nUwL8PuaVEbEpntbKDqDXw9UklEoba+t KLA0PDX3hwDT35a3fzdqkpFbrhjS5BBB5iv65Fmkm4H+IBIEgwQQy2akw0AiMAI+IAXE0bVwuj2Q xiJASr5pets/FWtiSlxseEJgXESK0TdfKkpyDvhLg8ZHtXuKjlpcy6qJUZ5yz6r22cwPe0JTFtY6 Wj0wR2v3+KSblTqvd3xoe39bzAQ10uWE/b3JKgtuns22mTXAV6y8UnZ9hDw4WTeqS+yQS3M3TW6n dUIjvp91dHHEgJrhR98l3N1jP+x4r+COVstvxA9VKgx1uD/N9uazFxNXDl6hWT2w3TWNuztvPf5i e9MxdXisu/kkh0UWm4qHL7K1BwvCUtepx/Q02Rs6eGZMXVV1XanbpxYvkjIdFh855fqhPO2u594h s6fl5/J9KuM1JtxzdFVd72o9b/aJtFJfXanTIJ2K7qNLQeQNqSwpiy/Y+dgycsWr4mzt+zLzTUmr PuyR3t5gXBuzcly+XGImyiVtf79GvEwuoYNMSTPWKuf+13oB35+ha9ImR4k6TZuk9PefQTj64Y17 kExdMZsmk4lOdJzaUeY44h9a5F2jsGdLdBOmWKnXkrhXU3u32Kk1+RteK9qKq900/47a426dGb// VILyD5mmsZWpbtL5/P8E6AAX/0RUVrjPVxRuF6IYu6UBEQoQvcUO7pBGtViBIzLTea6rMM5kIQsv jsoKfp63VWi8om7TlEUyd60BCf0Ba9pnsmWNUFC7ZeqY6bKp59ihteTNzOIpsOjyYReYkQNF9aAR b7cApyCNZLSMMrxPtrryaEK47Pu8cVFwBAyebWvEb2ImEYFky83hZAfthqinRmiQVcjZ+6w1PEbH zOZ3OQiLL72i5I6QGAr8lYRhjj61mbPbnZfsU4iSEp63ao9DA5W/78h+sHTCGtv3lglcM6PHY7gY ANaYdVmumlbwHfILALY2ZEdBjlFE8UQPAKxMDQplbmRzdHJlYW0NCmVuZG9iag0KMTQ1IDAgb2Jq DQo8PC9UeXBlL01ldGFkYXRhL1N1YnR5cGUvWE1ML0xlbmd0aCAxNDYzPj4NCnN0cmVhbQ0KPD94 cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz48eDp4bXBt ZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSIzLjEtNzAxIj4KPHJkZjpSREYg eG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4K PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2Jl LmNvbS94YXAvMS4wLyI+CjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjph Ym91dD0iIiAgeG1sbnM6eG1wUmlnaHRzPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvcmln aHRzLyI+Cjx4bXBSaWdodHM6TWFya2VkPlRydWU8L3htcFJpZ2h0czpNYXJrZWQ+PC9yZGY6RGVz Y3JpcHRpb24+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPC9yZGY6 UkRGPjwveDp4bXBtZXRhPjw/eHBhY2tldCBlbmQ9InciPz4NCmVuZHN0cmVhbQ0KZW5kb2JqDQox NDYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjI1Pj4NCnN0cmVhbQ0KeJxd kMFqwzAMhu9+Ch27Q3G6S3sIga1jkEO7smwP4NhKZlhkoziHvP1kL3QwgQ3y/3/it/S5fWnJJ9A3 DrbDBIMnxziHhS1Cj6MndajAeZu2rtx2MlFpgbt1Tji1NARV16DfRZwTr7B7cqHHB6Xf2CF7GmH3 ee6k75YYv3FCSlCppgGHgwy6mHg1E4Iu2L51ovu07oX5c3ysEeGx9IffMDY4nKOxyIZGVHUl1UD9 KtUoJPdP36h+sF+Gs/t4yu7q+Vjc23vm8vfuoezCLHnKDkqQHMET3tcUQ8xUPj8UIW9QDQplbmRz dHJlYW0NCmVuZG9iag0KMTQ3IDAgb2JqDQo8PC9NZXRhZGF0YSAxNDggMCBSL0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMTIyMjAvTGVuZ3RoMSAyNDMzMj4+DQpzdHJlYW0NCniczHsJXFRV+/9z 7p2NYRv2TeDCsG8zgAso6iDghqICKqglwzDAKDATM4ComVK54BJvlpYt8qr1prYMLomZW9nmq+35 y6xM5VUrLSuXTOH+n3tmMDAM7NP7+b/ncr/3Oc9ZnuU858w5wx0gAOCOIAIuM2/MqONxcQEAGTsA AgrG5eeNnv4VsxcLLVjr0IQ8VVLhiz/KAMgLmJ8yJXN8QV3x/W0A4hS8L+gqtaa4R+PaAQJXYJ1p uloLF3PoxsMAkTexXFRqKqu8Z/B5FiDoPObXl2nNJvADB5S3CftTlFXUl4LDgccA4jErPlReUjln zOQXngFwDEMly8v12pJPt2iWYd9xWGGgwHBtZodivgTzYeWVljkho5lvARjMMpYKo0579OKRGQBJ h7BOQ6V2jonxlgj6L8UKXJW2Un9KMXE2QP/RAK5pJqPZwocB9pXxkFBuqtabpmx+bjh2jfVZMwi+ EgOszrsyaaZr2hVZIHaFaePo14cIz4OjUsU83zFMdk7miFlHWl9I+JQ5dgxDnNKx9WaC7Nytks40 l3IOQApVXTBAASqYjNQP4vW2PkRHSRNKl4nXiZMxG257ss1Qyrg7sWIxYYhUwoilt/UM+eMzONBc 4i7tEq/oGEmSZY7kjYW3SkVHoYwSv9nyzBZoE+8A7e29/K8maSCE/7f6Zi9D1l9pJyoBw9+ty19N 7Msw6/+3Dj2kA1JC4PG78O70ntnt3XJre++npO8ie0sEWCJmWZx3hE5nX3r9KuNBBjK+A9c1B0Q5 yBEdwRHRCZz4dnAGZ0QXcEF0BVf+Js51BaIbuCG6gzuiB3ggeoInohd48zfAm6IP+CCiHP43XDn9 EP3BHzEAAvjr0A/6IQZCEHKCEK9DMAQjcsAhhkAIYiiEIipByf8KYRCGGA4RiBEUIyGSvwZREIUY DdGIMRCDGAux/FWIgzjEeEhATAAVooqiGtT8FUiERMQkSEJMhmT+MvSH/kgPgIFID4RBiIMopkAK Yiqk8r/AYBiMOASGIKZBGv8zDIVhiMNgOOJw0PA/gQbxZ0iHdMQRMAIxAzKQnwmZiFkwEnEkjOIv wSgYjTia4hgYgzgWxiJmQzbiOBiHOB5y+B8hByYgToCJiBNhEv8DTKKYC7mIeZCHmA/5iJNhCn8R psBUxKlQgFgAhYiFFKfBNP4Chud0xBkwA/EeuBfxXpjJfw8zoQixCLSIWsTvoBiKkdaBDrEESpCj h1LEUihDLINy/lsoBwOiAWYhzkI8D7NhNmIFVCBWQhV/DqrAiLQRTIgmuA8590E1YjVFM5gRLWBB rIFa/izUQh1iHcxBnAP1iPUwF3EuzOP/A/Mozof5iPfDAsQF8ADiA7CQb4OFsAhxETQgNsCD/Bl4 kOJD8BDiw7AYcTEsQVwCSxGXwjL+NCyDRsRGWI64HPEUrIAViCthJeIqeIT/Bh6BJsQm+Ady/gGP Iv0orEZcDY8hPoZ4Eh6HxxHXwFrEtfAE/zU8AU8iPgnrENfBU4hPwdP8V/A04tfwDDyD9LOwHun1 0Ix0M/wT8Z+wAXEDbOS/hI2wCXETPIf4HMXn4V+I/4IXEF+AzYibYQt/ArbAVsSt8CL/BbwILyH9 EuIX8DK8gvgKWBGt0MIfhxbYhrgNtiNuhx2IO2An/znshFcRX4VdiLugFbEVdiPuhtf4/4PXYA/i Hngd8XXYyx+DvbAPcR/sR85+OID0ATiIeBDeQHwD3uQ/gzfhEOIheAvxLXib/xTehncQ34F3kfMu vIf0e3AY8TD8G/HfcATxCBxFPArvI74PH/KfwAcUP4SPED+Cj/mP4WP4BPET+BTxU/iM/wg+g2NI H4PPEf8P8SP4HI4jHocvEL+AE/yHcAK+RPwSvkL8Cr7mP4Cv4RvEk3AK8RvE9+EUnEb6NJxBPANt yGmD/yD+B84inoXz/FE4B98inqf4LXzHH4Hv4HvE7+EC4gW4iHgRfkD8AS4h/gg/8f+GS/Az0j9R /Bl+Qc4vcBnxMlzhD8MVuIr0VfgV6WtwHfFX+A3xOuJ7uO+5gfQNuIl4E9qR0w4d/LvQQQCRJwRR WNtx/+solwqL/h92WHdO8p7Z4m65PvQn7r1KH5OTzQaHvrf437PB2UmGG+S7scGpZ3Z3lWS99yPp u8hekquLA9ogcux7C5ee2d217oNP/j4bFK7yu7TBtWe2w5/kekx9GKo+Jjdqg9i57y3+92zwcHNE GyR3YYNbz2z5n+R6THcxBXtJXp7OwILkDs7tKXn2zHb8k1yPqQ9m9jH5erugDbI7OLen5N0zu/ty 1YdxvYsp2EsK8FWgDQ4efW/h2zO7u9Z9GNe7CN9eUmCAG4jAwavvLQJ6ZndfchW99/P32cAFeqAN cp++twjsma3olutDbN7hc+YvpJAgT7TB8S5sCOqZreiW64MNd7GM9JLCld64TXC8Q4D0lJQ9s927 5e6weHVNd7GM9JJiIvzQBpc7BEhPKaJndnet77B4dU13sYz0khKi++HOxSWk7y2ie2Z319qv9376 MFR9TEnxQWiD4g4B0lOK75ndfcntQ2zexRTsJQ1M4nCz7xbZ9xZJPbO7a32Hid813eFz5i+kwQOU aIP7HQKkpzSgZ3a/brng3vu5i2Wkl5QxNAp3kF6qvrcY2jOb65YL672fPpjZx5SdGY87SN87OLen lNkzu/t/AKJ67ye07yJ7SXnZSbiD9B/S9xbZPbO7R+MdJn7XdIc1+i+kGXmDcAcZmN73Fnk9s7tr ndh7PzF9F9lLKilIw21z8Ki+tyjoma3ulhvYez8JfRfZe2Ls/xn0xE04JuKPtwS6/iMR/vC/QyEv uotvV9Q9s7u7bnLf+7tzmvN3dEKTCDQgnIuEL35El0Ivjb9Ucqn60i6eB7gU8nvO9Yz9Oni7lzSa /OHDhqYNGZyaMmhA/+SkRLUqIT4uNiY6KjIiPEwZGsIFBwX2C/D38/Xx9vL0cHdTuLo4OznKHWRS iVjEMgTispQjizhrRJFVFKEcPTpeyCu1yNB2YRRZOWSN7F7HyhXRalz3mhqsWXpbTY2tpuZWTaLg 0iAtPo7LUnLWo5lKrpVMm1SA9MpMZSFnvUjp8ZQWRdCMM2ZCQrAFl+VbnslZSRGXZR1ZW96YVZSJ /bU4yjOUGXp5fBy0yB2RdETK6qM0tRCfYYQSjE/W4BYGZM6oldVfmZll9VNmCipY2fAsbYl14qSC rMyAkJDC+DgrydApi62gHGF1jaVVIIOKsUoyrFIqhjMI5sByriXuQOOKVgUUF8U6lShLtDMKrKy2 UJDhFotyM60+c9t8f89i5+4ZBUu6lgawjVm+Bk7INjYu4azNkwq6loYIWFiIfWBbJnxkUeNIFL0C vZidx6E05uHCAit5GEVygiWCVTb79MosgVM0i7M6KEcoyxtnFeHY+DdaIbc+ZJu/v2Y3/w34Z3GN +QXKEOvwAGWhNrNfiyc05tZv99Nwft1L4uNaFG42x7a4uNoJJ+euhP5WGaVodYHKzr3lWSJopByD EWHldBxqUqBEm1IE0KdAoy4Fq2EqJNjKWoIjYrA6ZBQ1KgYLfKG9VRyuUHKNVwAjQHnxQneO1s6R hCuugEAKcXIr1rC8k7bGxlpjYoQQkWbgmKKOw2h+QHxcbSuTrjQpOHyg+2Ai+lZbOFiF7g8JEQZ4 easGijFjXTipwJbnoDhgG2hUsYVWpkgoOdBZ4jVZKFnYWXKreZESI3kHncxeVlnErT9XhbdHVvlg K/H+k2K9rTw7T5k9aVoBl9VYZPdtdn63nK085VaZnbJ6ZBSwAYydYgJYWopBOeNWZSFT4GQVheOf hAZ1SatUhlFJOYQbaVUUjbZhoTwkpI+NWvlLQiv6+L2ZXU3r4Nju+SHd8t3Uc2pkUWFRBJOdP62x Ud6tDCf4iBYlWTqpRUOW5k0r2K3AveDS/IJtDGEyikYUtoRhWcFuDpdOymVucYUcJ+Qgm2DAbmNk tChgNy7RC2mpiDJoXtdKgPJknTwCulbGxlNQHqZ4aMl3T/dkIvGKYCLASLyx3kyKEygOp6gSkFFt UwUHtzIJ25qFR9y2wGh8hGkcT/kHJ0a6B6dFCnkfzZCK6OBvtvgFn8J7a2RS8NK0pOAH8VbhXYt5 oV7kluhgY6Sx0rjYuEQ0CLyF06G7m0zTSs68OtnTwdNhUFMr2a9JlTbtlTZtlzaVSZtKpE1TpU0j pU0DpU0J0qZYaVO4tClM6ilzlylkLjInmVwmk0lkIhkjA5lnK/+NJlb4jPaUKISHRCSgiNIKRkDh hR8MYIbIGBgLVg82m8nOG0GyrQd0kF3MWa/mKVuJHEdWrBxBrO7ZkJ0/wteaEpvdKuVzrYNis63S idMLWghZVYhcK7MUPZ5f0Ep4gfVwgLCI7gZC+IdXBtifhYXgXTvcd7j7MLfUkZk9QJEdY39PvrFd U/bE+tchmNTgMSqYWLZLg1dLBW4ecpsot0ngNlGub6B1TXZegXVLYKE1SSD4wEKyPX2nZp6w7hYp s/R4F1mX15b7WhcWc1yLZqd9QY4oKtaVC0+t3rpTqc+0apSZXEv6vB6K5wnF6crMFpiXlV/QMk+j z9yWrknPUmozC3dDDiluiVnVTdyyTnG7IYYU/7HHVlIsdBkjSMxZ1YPEVUJxjiBxlSBxlSAxR5ND JWYZhAGcWNAigxGFONnpczvjKMexKAoIKRzhrTANowMzJMR3QcBrIuGFOkdc+5zwc9QZb6EoPj0+ XSjCgBGKXISPWHuR74IhIQGvkRfsRQpkuylHQGxN7G3JLCTwzTJkCjdqsps/wCzc5h6cFFsYC+J7 IFE8DoLx7sc+JhxO+VP2u62jkL8ong3Kjln8l5HC12k77LctafHMdS+eWcbCG3AJ9pEYmAgH+A9B BwVMHZ4DxsIjsAsOwNd4ZCvBEPcn84Hjn4YVeGx5EJohVeTP74RxcF7mCt546hxMjCABLyiDZ8mX MAYPSfEwBLeky6AacRLyr5EULCF42LoHpT8GT8E+eB9Ogh/2mADHiJRc4/dABh5NdDAPdsPX4hHi 5eAB/4B/wWY4CP8hCWQT+Y79gd/JH+G/x1bReEIZCNOFNzLgUfgn1vsX/JtRsht5f34e/wL/Lp7v M2ErWn0Q3kJZVwlHphAd8zxb3/EbX8VvpTtSL0F7vNLRmhywwHNY8xjcIA54NeA6OZzRdbjxPsJM wbN2LOo3GSphASyFlWjFOlgPr8B5MpyUk6PkB8aZWcjsF0+U5khzHPa3f8aP4q8Kbw1BCGo7FWbj jnqB8IYErMGW/0RZh/C6BO1kIBlChpExJJc8QhaT58ivTCxzgrnBurCubBxbyBax89nT7HWZuH1C x9qOD/mJ/Bz0JS5H6M9w9Fom5MMMMIEZ6mA+LETtVuHVhN7bipcV/bkfrzfhKziD11k4DxcIQ8Ro o5zE4KXGawjRkLFkMplJyoiZrCWvklayj7xFviOXmf7MQCaVmcDkMmWMibEwTYyVaWH2M23ML6jl YDaLNbMPsFvZN9h32Y/ZLzDqx4q0IoOoRvSYyCr6THRJdFnUIQaxEq8EsVbc3L6hI7tjOh/BD+GL +ZV8E17n0cdBwttMEIn2TMRR1Qlv1aBVJrgPr3r03cNo0Rp4Fn0neO9VaIXXMUrfEN6hgA/hC7Tv KzgtvCWAzhHs8yIhJJ4kon+HklF4TcNxqiXzyUKyiqxDP7eQnXgdIF+ilR1o4RSmkLmXqWXmMyuZ tcxTzG7mAHMMR4JnJTgSvuwoNpudyk5n72Ut7Br2CfZJ9ll2PdvKHmDfFjGiwaKJomrRg6Im0QbR K6J3RJ+IvhSrxUPEjXhZxTvFe8VnJe6SAEl/SZ6kVSqR1cvOyTpgO7wDLbDz9iMTWUoUpAVeIudY EbuQOcIUMI7MMdIg+oBE4gikERCvgir4GTUMJB8zg8hUVkemof8aSCmZDs+w/dgN7Fg4Iq4ieexE UgJ5orVwU/wmaMWNzDaWETey7eQ6sxXKYRUzu30zX0hcII9sYp7HiLkf0iBa5A/HmFTRbhLORDP7 pS+TVhgmlbCp7GCZK+Y2sWdQzTyZK/kOtOxpnD+ncG7lMs/jmnCWfCmdgNq1s69gnfthGNnU4Qab xYVMEenHbCLj2h9s/5x9il9P/JjTAO1u7elMBkbcZH4Lsw9+hLUd10XfwD7mBEzGVUNHZ87POPfq cKWZAjcZZ5xPebiOmHBtKsPjZRmen1mMnyGaIIlUh6c9sUjHglwi1rEs4+8gFekI+MmiU3xjcxSX 08a3p+UorqaNV7SnwfC09jThTlQnu4W4hYe4hZSJ4CbHHripEcMN4EQH6OvIfBucxvXUCXxh0C4g zh5SHKFWsmCHd6LC0b+VBGqc5P2dE0X9PWb66Vf4xiqutrW3tcHw9qtpw4mbe2pqotpDyUYM6D8w OQkPqFIPT4ky1J59KKJAMkKlThcz6Qnx6enxCemkjI0d4JUxbtw4v5gbbyakpyckaDS216Lx+Izr vRTn/WbNuBRIYUaLykWtII6Xp8nHyWfIK+Tz5RKQyYnUQS6ROohBxrBOIkc8BIsC5RJPuVxCGJYN lBMkCUgDZQ4OEjE6TN7KWHZoRKzcaT9zH+5mXsLVTowoJ9e3OwqO81NcbvO/eNEXPeZ/cXhaWlqq Ct0mXpIQu+T+Q0sSfIUHcU8VLuFPmpaGf4lquIfcQzySiZIke4hDCHtmc0n73vL2PeVbmefbHyLD 2f1k5W87xOM6zLr2INupX/IhWqiC45r4UaqpqlrVYpXIVRnkEBoarAzyCw2NVwZFhoYyyiBZqFKh DPIKVXLKoIhQZSv/j10+oOJ8E1SqVmLUaHx8PX18fL2xz0gfbyS9vdGBKh+VL+cTzyT4ENbP19uL UUVGOOBOT/UZ5Pkk+vj4cwnxkcHcEVfCCJ3IFa5+6sQjIek7cQeVQ0MHo0aInyx95lmMoLMg+CIt TUCfVGGo3VLdBCe4pXZzTecOLFFN7gkhbp4+3snJXiEDkpMGDRzg1j9CqRwQQkiIlzJUKvG6rZSw Ye2XA8Inqjui1FPCvHOm+eL6dYG0kYWqqWHe/cInqtoPqKcqvduviMw359wfHBMe3p+rZmstueE3 Toho5mbjLfaKG8tsEX2KnYUrSDQMghpN0NwYEh3bDxfNGJTYnw1wTo6PCWCBEatDw5SurSRE4+yd JCPqJKVjKjrJqZVIdyUv5a5E+CWJcXurcYxXRfilpF4JiSmnjhp/8fJFRfvFthzBTTB8/MXhFy8q 0tLcqIt8UmlcRERG2GaA8JUNTgfMRkYoQyVent4+3gIPbFNkoI9E4CUnoWZYg7RGJayesmbj3lkj EsO93fzmhak0hTNnvXouN7fj230vfnvv6588/czTpfOWq0L92ZmRyvvmDcipHR0/LFQtd13s7jM+ Ia6ycllt7YqjHScvWQ3vNUj839y1a/+76/IeVYdRz3SMxJXTijM9Cl7URAVpAr2GySAgMGy6szQw yctR5BLjwy11u+rANhHiFyVqikqTOfhFtxKXllU48TFGLrahqYo2tB9Np7a7CQtARr0mLihS7hkR 7hoeGuEREe4UFQ6OcqULF06CPBEiHcPCSYgCIdg9MBwwWkhsrCKNxs2iRTAmv17j7t0vIMIn3N83 cLWon7ffatSSYA2h7qJBuK4oB9J4GmT3qpS6lfX0tnsvgsbX4eCtXhJ5Q8Pbp2unG1efmjQibmBi Q979L89+foY5KXhQzbWHNVGZZcyiDx56cMOC9dvXvu3rRqYvq8g+tPmB4+WFA161fWf5CXOCfRkc IWQ3sGSHxsVBCv7OEj8n5x9DhPUiNqdNQUceI77LYsecOLb2iWPHnlh7jEm3PY+B8E8m21UL5/4b F3nqbi4m6k+uPX/Ldfp/66Ibjv5M7a1vXWdA5/fUwh5Tb6cZ/Nx52E6zuHLMsNOiLnXE+Bm5wk7j 5xA8YadluJdvttMOuB/ebqflhINP7bQjJJHLdtoJkpkIO+1M1jKFdtoFEthLwrfrIlydwEkURGmx 8IsbUQKlJZQ/jNJSyh9LaRmlp1FaePGpVTTLThNwEve30wy4iC12moVccaidFnWpIwZfcYOdloBC vM5OyyBCvMVOO8AI8Yd2Ws5oJO522hFKZLl22glKZa/aaWemzaGfnXaBGU5AaXkXG4WXxBROMyjt 1IXvItBOFZRWCPo7zae0B9LuTo2U9uxS34v6wUZ7d+H70bZPUzqAyrL1GdilTnAXOozWt9kbT+lW gZZ10VnWpX+nLnwnu/759SZ9qVan5zZz+eV6bryxymhBFpdhrDYZq7UWg7GKM1XoErhMrUX7Z5XS Kyq4XENZucXM5erN+upafUlnvcF59ZXFxgpucK2+2izUTUwYpOaixht01UazsdQSnasvq6nQVk+x Fw9IUKttTcbn35KFihrLqrWm8vquLD2XWa2tM1SVcRNKSw1oRmJqSmp+ucHMlRqrLJwOQWuoMnP5 hkq9mcvR13G5xkptFTeqWq+fzem0JoNFW2HmtFUlXIWxTl+t05r1cVypoaymWm9jF2vNBh1nqqnS WWpsllqMZXpLub6aqzNYyjktCqmo0OtokbGUq9RiGYJBp63gzIayKls3ZfoqfTVyTDXoMrOem2jg dOXaaq3OgkYncNxk5JUaqzmz3mIRzOnWjdCBWWfQV1kMaCRXZ6yeTXlaMxVfaapA89Bci5HDVpyZ +k5wQQ1WMlRxZgvW1laXUKeYE8otFtNglaquri6h0u7LBOxFVW6prFBVWoQf9akqzTNt3SQI3D62 qNNXIFdPm+RMyB8zckxGev6YCTnchJHcuDEZWTl5WVz6qNysrPFZOfnOcmd5nyoVGmvQHfVcDbrI cmto0XaTvrrSYLHocZDqqeFZk8elUy8KGVO1saRGZxHsrys36Mq7tMWnoUpXUVOCTdFnJQazqQIF CC41VRvscYMOxXHpFG6sqqjnogzRnL6yWGj1e19VnbV7VIlWLxFGFAPKUm2gcdJFPDa/1dcQqkGU AaVY9JXCzKo2oNQSY11VhVHbVSgqrbWpimGI9hppPBprLKYaC1eirxVmAtYp11eYbrPoT0dSyKkq sHGV2TaIkANGqIZKPOdV4FmyHnPFUE+c8bNmFua/FX5Dc6s8Dyz4rIISxGooYdexLexedj/eu9nX 2BchH9ubhN/qYLkOnxxsxjsfT78CPR57Enqz2GtxkEH7NlHUIt9Aa3DIqcD2CUhlUr72L/eULvwe CJ+5yCnD1hYw05wen3qsW4tY8of+BqOl9WhzMfKE1oNpvWps09lvImo3CNRIRWFrA2pbjSVmvEux l2gqoQxqsLXgqSm3tR6ArdV4dZUyHq37o102jxqxr2p6Ei/H/J1q6am/hHp1KKkK23AwAfUppfrp qdapkIK34EcD9UQp7cuClM5OaWlbM+3VgNrpKZ2DzzrqOSONBcGKUShLj9ds2lrQzkDbV9AWtjjh MGfEloL9Qh3B63FUroH6p9ref2ftYlpH0FeIghrk6rDPmm5jaqH+0OOznPbLUXuFHEcjRUf9WYFl ui6thJHhqO62dpX2PnVUY45KLbNb3qmNIKWKyrDVMVGNTXSkBX9OxDaCvHI6yloqzzbSQuxyMNle r5TGJUdzFirVNjp31qZTAzNyDFQLobTU7pk62t/sLvW0dr1t1lfSGWQbPdvoCj7j7LKEXn+Pu84o qLH3ZKDeMnef6V0iRbCtnFphwnmhwquOXgnYY/e4TLDroqL1K1GWCtGCdbRUMyFnhpndtEm4Vffv lSFEYIW9rr6LlBycIfkwBkbinYGrhUBPQK4wc0YijqP8LOTkIQrrySicA1l4jafcfHAGOb0LqQ9t Y1qPzxr72Ft6mGu20TLRWKmksWuh65AQ//VdxikLI2gcyvw9gjpLTHS9KUEpOtqjbdTqqCwdnQk9 ybXlDXRWVWDbErtUW3SU0HITXbPqu8SWIMtw2yphiytblN9uuVCjglJR2C4an3o6vp2yetKr6g99 991Lv/decmtm2dYVC9X891WgZ+sN9lXldr2GdPGBYInNFguV1/lJI/Rvs7WErnNVdL3T3tFSm6e1 3bxqW8OMdvx9VRO8aqFrjoX2r8dPoc6V3NZPOY1qUy9j9NdnUmeZiq4mOtqj+bb507k70NI6nflT dDeh77a70HfbP9B1RRQkShRli0aJhiKmYm0t2ih4T9AsXfidLl2XhFas7dDMh9zx5+ksffPJHQjP 09qEXvSMHSC8FGl/STkgTd0QkCJxiFk8evE1ZyJlmhsCopEVzhCS6Kh2kIhjXVjGXwxqrUQeKyEi 0jCIIaLmPPUkdVwXTr8NQQv7CT/HxmsCBqCZLmB66vhhwqUO6dKZyPO9USPiiscNPHaB/+xY/4VX tj0b9e9ZzQ1eJ9UN7CG845tZhjCMYtR+v8dPrswdmXHtROVo58RNaudbqhIxKrVoOVWSnSySeDDT 0hO91B5CRubhNBW3n/rqKi5Da9IneqrdBbbUwzGzprpYW1VrwCNMoiv2hly5hyS/XFtn0ScGqgME hqOHp43BZeir6RGEHoQSg9WBQjHr4W0vpqcsi7bSJOx3M9LVQT7O6uTEJHV/NU3TfJwThWxyUvKA 1AGp09R5XZSdnJfoo/ayyXfBk6AhD89OcdyYKl1CYqw62iYotLOAiuLyOmXl4XkTt61mQWgDCe3q FSIGtoG4AvLlTAMhsPnwtk1HjnKvyO9f9uKSmks7cn46edB1f5l278aSfl/suX44eetD6mUFC1ac mP3VwGdd9390Yc7Pdc8vMKbtX/2K82vllyseO7w3N37r6KFXXv3snpkBzPrfVLODNl3buO55/3eZ Uw+Myz3jUnRB02/Bbuevh7+z4+SSvTPnzkpMYJ9c5PHCKO79RLPz1Pijc/onP+7+pPvur8tVW86e eaNxRcyby0OWlO59sGCqsWZ/2paIJfccVnilrX/ou/yD8qpDHW+N/Wq31G1t6PwTwyI/CppzYX3i ez+dDfU7cWj7qIx1/jObg5ra7r3yw/yf7t9aTB65Mt7x6w9Dp7zw+NGXl9a+/MNrzr+0jT/efKO8 +WXPIduXHNzDsBj4GxedUC/6XN1fIsOIFYulhIii1BHqsM68miz2tR8VjDqzKQFP7gbhMCucFWjs BHoQwotkagk+GALqdIEXLBqsTlEPbO7fnLRYbW+uq67o1lpli5WuoZKRnoC1aKQGhouc1PJOLViZ 2kVgugqyhFcIJagh5t1EGJmb/NQ+nfHNejjl56VjoKXEJ8YPSL5tVrCLFsHY2de/K3gjs1/isvon Y9fsb3iRHOs37qi1saDqpCx6473vHl7tcU6U6/zjqEgVpFjb3luds+7T0GKva8MHhUwwJS78aXnK ku3nz6+Fjg8mr8kJ+3hzZM7cl3dp03+Jef/ce8fv/WpP7MPDdj6z8/ipqfy+HW8tuPKB07OX1nbE fjIkNyAgJfLa8LE4h3l1A3POPo+dv4299Onn0Ut9k8QO966rXXr7PP6vzIw/Tkd1StfpOLWPQlXq eJvQiN6ECmX66l6n5LaJUaO/+qR87kO+maU19yw41LpeF8EPzXh6vluKInyy+XhNpKE9Zzc34xP5 9eaAmIuTp4RoPw860fZ68ux3fvxq4yD9qoDVTq/mBc2YXzpgprgxq6M252Tewg2LuGdeXjpjg+za f9TXfwgdNG6E/P2TbwcfOjb520XDd+ZujNtC5v68YcvKAR3rz94zS7x+6Owz+9cc6DhSdF1zTtqc +f2iSVXPxfz8aqMi6uIjX0qaF09cN2+szFkdeFjx7Oxr3xa8LNqseXJb1PlHvF9MO5NnzP5kwDM7 jSWB29fE7Rl6rv77yrnXvc9GvPTKj0/m7dLEPd5av6Xj09yt0ZYFIy6kBm2Y5X22cE9Y+eewMEOx ZOFs+5Q8rF70zl+ckk63piSDR8dk22SMU8eoo5ojmsMWh95pMlrM5nidlk4/bzr9hC7+ZAZKDvRp Bva/fQYKo7xkjumLnFzCTf+m/r0G9aH23X5r9v4D3tx79Ojbl10+56+PP5BcrHZ764ol4NNHv575 NOfRMj9r38SjD55b6PPgvyJXl3mMvHG49Yl09shTk6aLlz/wgvGXgIkBYQk/G1ZWhF7bc9j78YtO lgPldce/f7J4yUFz06/LLHOVWzc+MW9ty7VHou8bn1ATMDr9i0s7nbn8Y3XNaxt0hnaHDxov1exx eOr4dbfJEeu0SfvmMtZ5i/dteHN5aNycjwbUvv6oecb13WfHecmVR9o+/rR/whiNV5pr0dywt58r /XHNB6bvh5277Lzgy4/mb6y9z3Dw6Qmj1ANCWja84l+cFnt81ZYY6bzPfbfPmHf6meeMHWnLXlI3 iNxxCfjNtgS4wkFYnpa21O2jYVd1F05qunpMhCuAqXNu/7/qzTOsiWyN4wkJHS8QilRJaCqoTCCS 0KVIWaSFqhSBEKQoICLNAglIU0TUUKUEpCNFhKCiFOlNFMErsOBeOiJKXRWBmwACe9VnP+3dZz/l OXMyM+fMec/v/P/vmWHlEtX09ArwpuVW4ftw++FIBQU0fCt5up6EPYTcAwht/JnnjzWb6VkkAhDZ GCa+7Xqsp6cPXP28j4unt6tPAA0PCmgAiQQA9CYeZAGkrBxys/g3tOhPl3K6J7VeY0pzhoL70uL9 7YCpjLxoiZOfVknHMimrKRlw1YsmGckZMfay7i80nAJmCn1bzPrm3t0JE4pJC3Uua3APdBTrFVYe ZAffnIirrz7onJTkIpnYpXigmq3cSrJWe5xFFRN3IG+fQu60XojGcCj746TT5g6FxItk+4N+xyYT HzgpJRkLIZnEudPyxmOl+cZUEnDc9lb0+DRhNDb895wPt+kaBburzY+WRQZXK06b3TYsWskJPONj WMzXHse8DwGyvGHvin6sD2NUtlizXr7rzMKU/ZJgYfmhQsmOl+AH7Vt6WhRMWi3pCOrNEfC2UW6t +siUKQqUMVxpKYP7cV0Z2uRGLkDIAggZtHkJhhKSAEJ8MId1l9cHV+9UMZPL3PcNrq+1kb3//+NH /JMYX6cCaYK1Jno+nu/w+0qw+L/9OOdt7GXTUlnbVOljI2JaFMcQcx8tbx0oT9dpdvzw9XW7ktKJ PHkz11XxM2ot7fmD9Bd/RUarpHF4uT1ehRnxudZ87dIc5jwBN5pyvFCcz98sjZY4+BRPhkVJsOMy fzcT+oxo6eWZxxZ6aMoyrhB3fxo9dXqXydKTWWzTk/F64CscyRwhTNovYNAjTJc1G/wW8sB6ofTX ZssZvF4T1qziAWQfbO1G70emmMuV8Q0F6AMjgSO5fsO+6aAuN7Xal/JRb9VhuYfdBN36D//2Sgg6 knsU2nxCDuNhILTLkcKSca27x0xNu0PIPNurH6YYfut8Ws7LdCoVnlHFQfGmMHBjTTSqAQkXcPbV 05Gd9z76ZhKE/y4kAPJUvYBColEoJIom4KmIl5X/hgRC9h8lAxfAuWE3WCwdzrlQpYAP9T4c60sI 1WwwYvFOZzw9nL61jOVnLftZN2WpN/2um2IAYqMbAjtrnPDr4oOmRozXTQH8e5LsopGEaZ0kz9rh 0VVDa6rGM4F1r8Qllnw7EWsdUhaGrXcoxPuHAw6C6nOZenAtlKylydra3tJrcRmMX9griNikd8TG JxwNuTUz7qHXTQUfG39xAkfW8r4iuoCO+GstwjCGyziTt19UHo6iS4dwjGJKZ4+gdBbci7QX957b I9qmwb/HpAKb1J3ZxdXIr3aW4cwcCaF1UuN9TUuiE7yyFvU1Q2vswn1hmcrswQXyUDKCfdUKqW6O uVxsNT4yfTxAouB3KRlONYy/qkZQjsvIZVGX3WO/3Kz318LqkI1CI28l15y6MMW8HAa5tJR4Vlk6 xzmhfejgf6TpBNhRuvhFZVjxbLiQsCTWs50ae5BMIliK+jwkf6TDIf8MvMAYmDcNOA+VL3QQCAi6 blGF/wXlhXJLfJLWt232Nrs3upQutZt3ufazKQHg3zqFmw7KtocFZAo6T7XrmiB1gHVd+Kz7Dm2A fUtg0QMQ6s+OebmOMdzw23n6ypIpVlbUCyJSNdLxaA9TzmcHfPMhyBeMrvrz8rm9Id3DDRamueX8 ne1js+mfLSp0b+uIj+aJDAS+WuINhPXP3xCcZrItu3Lj4TWrx0LtpG7SbbmF2MG1iGQ7fT1jBUlF uKAZ+uslG55bzwaErn90wCqPMr53/hAwHdNpicOT+PTSA4fwlCHJotVmWEVjRnvjyate8639BUQP xgE8/8PcpbA6Zo2EWclC18DSWumcEmeRrOJwJvd4rsoS+cQ99JlcmMyaQkD1EeI1kN3qCBMqtowe nQ3kfGSnzIaevVV7M8IQeoLepul5b96b3y7F+u9dfuCRFcMgZ1VqJ8XJDhDp5agoE9zAGIuDdmob 7b1rEP67DMU/BRnb7FNAyaHkaW4JTdVG1OJhWhHw+Uv6sVkP+Un9n0qiDkIcpsgmY652aLCrgBTd q5wicvWZbdgh24+l3osFhRFu5X2lohdYm5uz9GPtRLkmPy+KpZQvePgWfZi5q9xUX3PcRq2g7Jyc ZLYjwSGA7LjgEUHq8vi1Ke3lXRNOX4dHXlF4chxvZI4toUvLebTfIvVI69cBX/FDWgBotPfSBRJn j5Vw5oQRa0vEQEavaeLpVlxrolvSTbtjBpwTMt3W1nYnsZnnDmY9Dj266xo/j28bU19SthfPhMG0 64rtffeY9/tN0Jirjdp6PLeNE0oWXO6+HmQ+e8on1e+a8BX3+Knxk0fb346d3fUCB7p1AZlwnfUB 15OyrpnZIcRMnr3DDFpT5dmGJCKCb1KfyPXvvMs2DGbeuOedN+0wmhE05GfYk3mn4PntlZ+QL492 VAxKIAOE1OAfUoTsc/fv4N/3YkF/w/hpARrAkXTVdOUwxR3G78y366w7Py93V9pRmc1t8nMytAlA i39q7MuuG0KjHU5UE1AH1LacKF2Y3M595O+vi/f+/oI+P/KEmDcfSJhkmwRuWzMP1yG65vGy5e46 g3syBUFmu/pkKz65je1aRgj4qWa5BD4gXY6ymdOsD0nGX4owNrlI5F4MOfc646lNK51Xp+Tp3VVY 7qzIGsoIuZ18PiX2rIpgjQXIovxTqGSfndxyr0SgXVJf9vLCnLpAobn2Pd2BWAyXFbPe7DwyXKQK et0ahodMspp0kdmiEp+8qc3tYuKRQJRXWEYKvbAOO5zVupIfPp2HVqNoug/DZ49WXS6anDW/T9at wj81Rb1pmWDAQRn8PYzXdB8nT2meCO+/xxK8eLzhwMhokPUvo7IBM6JXbrIdLDO2bqw7YmVV8LJj WKa2Y/pMGjoASYS2UbHZRAcGA4Tyfwwc/wD47TR2OmEC4N5aUPeBkYwQ+vVkO22Z3Rx6ZgiSbWfm nNr07RIr8l/AzloeQGz7RCiSOm8lB/eYdnyxAl/b/0pXBq2Fa117eAzw3nEKG9IJcEzHBMv/YOcd DtLe2mv5ya47WTJY/Kex7bP1DtL/qkkoEQxq5Zj33l3U9jWgPLFEVF86JaE9IvkeeCHIRSCfXa4c 0eO2N6ZOzTB+rJA3oANVHs1aA1GYI4nPQWSOE0JdbmDDFT1NhhOynz1CWavgGpcPmWL8jygXGX55 y5jf9q62OOP5oo5xagRMOS0eEdqVbDpthTkiDCaJKXFyrU7rpbC9qqqeTGwVDKF0XvU6OXdxyYiF tZr3dD9C1KlHGm2iXTitM3ATU8NRWuDVEZsUSRF5+UsE0FoxX239jpnFSS8ENMMy+kywIVpkJkEt SEm6U9rg3Xnzvk75EWZheJrqnI0tJJKJ/4KXa6uJSh5h8HhNSRR/pZtRM/fK1YQ4ypke+ioUlEyk yiIieHl7xBiQRPA09dAELbxP/SVJzR+kUtkYmDYaQEelTPpxgG9n7LFub+2AqaG3VUOPZKet99QF XlaW9m076gSVvztCDwblMEwUpZQPSkUJ2QMjn1fjen8QAu6mWrpvuw5ptq3Yehj0JL3XqL+jRLGQ 9D9m75Svv/dKufmxHh7N0JQvXuqBOjr1w1e7Gx6tva972bRmCQ7xL53sRwS5oh6py+SoBj44nEJ/ p77SkBsNCp9Uup5/3lka5os1JybINOGY7ldj6waffmQhr9TRzS+I95VqOvQxQDxX9RNSZ0OKq9D3 4ZppFWPD1fXjaKBeb+Xi/jnRc0NA2j2p8Z4wPiQF3hBZZ6ypMoWXU3QzA6nq5EdJJZoKAllTTg6e 2eaUbGkEe6H+4Ou1EIYsEb90gzuLBgLlkN0vPvvtbr7BcUWt9FRnZA4WJ7a6rHAixTYYeG6mMlNC mQ/pH7jxX39/QU8NCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNDggMCBvYmoNCjw8L1R5cGUvTWV0YWRh dGEvU3VidHlwZS9YTUwvTGVuZ3RoIDE0NjM+Pg0Kc3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7 vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRv YmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS03MDEiPgo8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6 Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgo8cmRmOkRlc2NyaXB0aW9u IHJkZjphYm91dD0iIiAgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4K PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiICB4bWxuczp4 bXBSaWdodHM9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9yaWdodHMvIj4KPHhtcFJpZ2h0 czpNYXJrZWQ+VHJ1ZTwveG1wUmlnaHRzOk1hcmtlZD48L3JkZjpEZXNjcmlwdGlvbj4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8L3JkZjpSREY+PC94OnhtcG1ldGE+ PD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDQplbmRvYmoNCjE0OSAwIG9iag0KWyAwWyA2 MDBdICAxMjBbIDQ2MF0gXSANCmVuZG9iag0KMTUwIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDE1Pj4NCnN0cmVhbQ0KeJxjYEABDQxoAAAIoACBDQplbmRzdHJlYW0NCmVuZG9i ag0KMTUxIDAgb2JqDQpbIDI3OF0gDQplbmRvYmoNCjE1MiAwIG9iag0KPDwvTWV0YWRhdGEgMTUz IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDUxMDg5L0xlbmd0aDEgMTI5NDM2Pj4NCnN0 cmVhbQ0KeJzsfQl4VEXW9qm6t/c9ZE8n3Z0mAdKBQBKWQIZ0yAIY2UNMI4EEiCyKLAEFN8IognFB HQdxGREdFXXUziI2AYeojAuCMIrrqCyC4Mwg6Icrkvu/dbvDMuqvzzzz/X5+f5+b89apqlPLPffU qbo3EYkRUTxAptrSCSOH31Iy4FNie2OJklcNLy0rtw9ynCRqe4eIfz187JgJD5alLiZ6ZjfRkQPD J0wctqT+1UPE7m8jGuo/b0Jl+dys2VpiH55Ar2nnV04Y4RvtepGocAORbe2YCTm59n7TXyJiR1Bf O7bk/MpTVw4tQf/3Iz+gqnRU9djb53xBdL6fyHHH9Ll189fPvvZxopo9aPP69MsWuR+7/v1LiRoq ibSTLpo/c+4rW97TEE1F/7rnZtY1zKdEMqC/W9GffeYlSy/KTvloFtHSIPrrOau+bsb+d58vRF+X iPFmoSDmtrhnkf8j8t1nzV20pG6hpgP3OoJocO0l86bXTcquVIiacP+urLl1S+bHbjGPgv7L0Hdf Wje3fvGK1XcSPSYTGefMn9ewSMmiNRh/vqifv7B+/s2eo8VEMzGe6TAJW2t3TS7404rHptoKv9Cn 6EnQAx/1yBLpjqeX07dPnZppn6Ifh6xB1ReEVDe0czSV2FH/zev2KadrImS5V5TY7qD+xNUCTnbK oQAe6xaMK0iSVrFbSUN6zd2aPHSZEk6lv9JFPEav4SatzAXJ+yhL6aAlJeoMQJWjStzkJ7fWr3mj cxzL0w1lLX5iigK7yJmazeJOKVYbmRIvOM1B/jZNof8BpHmJ7vspHe1jtPYH2q3/T4wvN1D5v9OO P0Yr/hPjRylKUYpSlKIUpShFKUr/SmyD0v5Lz+Hnkibl1zPXKEUpSlH6JYmR0q4H2ykaN6MUpShF KUpRilKUohSlKEUpSlGKUpSiFKUoRSlKUYpSlKIUpShFKUpRilKUohSl/x/JcB49/J/sTz78/f/e 6l9J89L3deS//XS7KEUpSv/byHaHjjH2uPYnFc1dwmIBMd+r956T++n+ohSlX4TYT6v8G6pR+glC lPmlpxClKEUpSlGKUpSi9MvSDx2HTpf1EWD7fzaXKP2PI4kkJkgjSYzj7Jyo+aepg77WK6QnvdJJ BjIop8hIRqCJTEAzmYEWsgCtKtrICrSTDegAfof3dgewG8UAY6kbMA54kuIpFphAccBE4LeURAmQ kykJcgolA50qplIKMI2cyjfkUtFNqUAPuYDp5AZ6gV9Td/IAMygdmAn8inqQF9iTugN7USYwS0Uf 9VC+pGzqCeytYh/KAuaQD9iXegP7Ab+gXOoDzKMcYD71VU5QfxUHUD/gQMoDDqJ85b+oQMXB1B84 RMVCGgD8DQ0EDqVBwCIqUD4nPw0GFtMQ4DAqBJYAP6NS+g2wjIYCy6lIOU7DyQ8cQcXAkTQMeJ6K FVQCPJ9KgaOoXDlGo1UcQ8OBY2kEcByNVD6l8SpOoPOAlVShHKWJNApYpeIFNBpYTWOUf1KAxgIn AY/ShTQO8mSaAKyhSuAUFafSROUfVEtVwDq6ADgN+HeaTgHgDJoErKcLgRfRZOUTmqniLKoBzqYp yhGaQ7WQL1bxEqoDzqVpKL+UpgPnqTifZiiHaQHVAxfSTGCDiotolvIxLabZwMtoDvBy4CFaQhcD l9Jc4BV0KfBKFa+iecCraT7wGlqgHKRlKjZSA3A5LQL+lhYrH9G1dBnwOhVX0OXKAbqelgBX0lLg KroCeANdqeynJroKeCNdjZKbgPvpZroGeAstA66m5cBbgfvoNvot8Ha6Fvg7uk7ZS3eo+HtaAVxD K4F30irUrgXupbvoBuDd1KR8SPfQjcB76SbgH1S8j24BrqPVwPvpVuB64Af0AN0GfJBuB/6Rfgd8 iO5Q3qeH6ffK3+gRWgPcQHcCH1XxMVoLfJzuAv6J7gE+oeKTdC/wKfoDMEj3AZuB71ELrQO20v3A NnpAeZeepgeVd2ijis/QH4Ehegi4iR4Gtqu4mTYAt9Cjytv0LD0G/LOKW+lxYAf9CfgcPQF8np4E vkBPKW/RNgoC/0LNypv0ooovUQvwZWpV9tAr1AbcTk8DX6WNwB30DHAnhYCv0SbgLhV3Uzvwr7QF +Do9q7xBbwBfpz30Z+CbtBX4FnUof6W3VXyHnge+Sy8A36NtwL+p+D79BfgBvQj8kF5SdtNeFffR K8ou2k/bgQfoVeBHKh6kHcBDtBP4Mb0GPEy7ldfoiIqf0F+Bf6fXlZ30D3oD+E8Vj9Ie4Kf0lrKD jtHbwOMqfkbvAD+nd4H/Re8BT6j4Bb2vvEpf0gfAr+hD4NfA7fQN7QV+S/uAJ2k/8DsVT9FHyivU SQeBCh0CRmP6f39M/+xXHtP/8bNj+ic/EtM/+V5MP/IjMf3w92L6xz8jph88HdMXnhPTP/qRmP6R GtM/+l5MP6DG9ANnxfQDakw/oMb0A2fF9P3fi+n71Ji+T43p+36FMf3dXyim74nG9GhM/9XF9F/7 Of3XG9N/7JwejenRmP7DMf3l/wUxXXyTCbMz8qFuEXKQ2BUkIxqIv4qwo4QjupYivozHyl5I92v9 4t/0RvT9lzLlo7Ou6d8Ff/i3zUx75qsg45wi/xL5WQqYkqz5yc9JPbqEvgL6f69++Dm5iT/Z379H 0r/X7L/Nuv7y6guqJlYW+4uG/qZwyOCCQQP75+fl9uub06d3ti+rV88emRndveketyst1ZmSnJSY EB8X2y3GYbdZLWaT0aDXaTWyxBlll3nLa93BzNqgnOkdMaK3yHvrUFB3VkFt0I2i8nN1gu5aVc19 rqYfmhf9i6Y/rOk/rcns7kIq7J3tLvO6gztLve4QmzSuGvLNpd6AO3hUlUep8q2qbIHs8aCBuyxx Vqk7yGrdZcHyy2Y1ldWWortmk7HEW1Jv7J1NzUYTRBOkYIJ3fjNLGMpUgSeUDW7mpLdgUsFkb2lZ MMlbKmYQlDLK6mYEx46rLitN8XgCvbODrGS6d1qQvMOCNp+qQiXqMEFtSVCnDuOeLe6GbnQ3Z3c0 3RSy07Ran3mGd0bd5OqgVBcQYzh8GLc0mHDFwcQzWXQeU1K98uzaFKmpLHG2W2Sbmla6g/ePqz67 1iMwEEAfaMszymubyjH0TTBixQQ3RuMrAtVBtgJDusWdiLsK31+9t0yU1M5xBw3eYd5ZTXNq8WiS m4I0fqmnJTnZvwk7UXKZu6my2usJFqV4A3WlzuZYahq/tDXJ7046t6Z3drPdETZss9UWEcyWs4X6 03WqpKoLqWL8acsyMSPvSDhE0D3djZlUe3FPgwTUD6Km6YOgBgowtArOwBOZHTSU1DbZB4ty0T6o ybB73U1fEDzAe/Sf55bURUq0GfYvSIjCT067Guq75KDPF8zKEi6iK8EzxRyHqvn+vbMvC3Gvd77d jQTmo7GwbV1gcA7M7/GIB3xjyE/TkAk2jqsO5900LaWF/Dm+QJDXipqOrpq4iaKmsavmdPNaLzy5 TV3XcUF95ukfmz2+W9mswUEW/3+prg/XV0zwVoybVO0ua6qN2Lai8pxcuH7Q6bqIFOxWUi2l8IjE UyS1Fk45+bSyyFSbg3IGfrSqU88I6fTwSrWEucuD9toRYQwYPZ6f2SikHBet1ORMs8g0g4N95+aH nJM/Z3rmJgkTljN5ReWkpibjOXVwtfCAIyMJPJ4qqz3ukiBNxMrMwE9I6RgkOJAS9MNkJUIB/hcu imTPUUyJyAGQ8M7e2eUIdE1N5V53eVNtU11IaZzmddu9TZv48/z5pvlltV2OE1Lab0wJlt8UgK1m scFYFJyGNXvZqnHNfrZqwqTqTXZsAKsqq1s44yW1wwLN3VFXvcmN+K6WclEqCkXGLTJUwXCTLVyv 6qds8hM1qrWyWqDmp4cYqWX6rjJG00M8XGYPD5SpDuTHpjQ9JIdr/F3aMsr04bLGsHbPiLYeNXZR 007YO0itDJMITiWV1We7nbqWRcUFvmozb6qYgIcmKo2DUoxnVbtFwyDzBqd6l3ia0WewyrvUg0Jv 0I0AB6VmGu4MNDW5cXkx/PSq6jCKKpbtRE+BYOO0Lt0UZ8B7VtaMpuqjaHWKZXd6tCu7RluI0YTQ 1DVccPoPjobZB9mFAtUfdfrNA8gbHh8bW3jQpslNk7wexM1UMXBkHshanQG1B8xkrZgJVnexmSql bHHxdLz1uiSflIV3SJeU1aJNdYWknq2Zia7dW6RetA/MpV4tvlTXJqmHlNoyxOUPSd7WmLhcW3Fv yY0HnKOiGzgP/BR4K1imqVIayu3AZeBG8FPgreDdYJzRgKLWDZ4HXgfeJ2qkVMnZ4nbZi3tISWib BFexSQl0DKyAJcwzAaMm0BjwVPBq8DqwVtUTJfPAy8BbwcfVGr+U0HJ7Huae0HKjmrTOuSRXzdaF s5Nr1GzrBYFwOmpcOC0dGVYbHFbrlx8u7jMsnPbIDqcxGbmNIjVacjuK46V43GQ8Jj4fyPg2sjFG LrpfiqMgmEvaSIlfimntnpm7bqskE5O4xHAccykdEmuxOHKLjVzhx3CIc/FP+dFwDT/aanXkris+ jx+gp8BbwRI/gGs/30/L+D5hc2AReB14K3gX+BhYy/fh2ovrQ/4h2fgHlAMuAk8FrwNvBR8D6/gH QDt/X2wGKgq5CMz5+0A7/xtu629AG38P0nv8PUztjZaBBbmbVMGXExFcGREhISUixMTnhvjrLd/0 gkdl4knDozZL6TSU8qT0lox+cL/ElsLZrhD/qNXtc91f3JfvoSBYHOT3YOQ95AaPBdeC54O1kN6C 9BY1gm8F3w8OguFlQDvYzbeDd4Dfor5gP3gsWM93t2CYEN/VkjnMVRzPX+MvUQIsvpO/rKY7+Itq +ir/i5q+gjQN6Xb+Ykuai4pNqCe0sSO1I81BvYY/19o9xqUUO/hW2M4FzAEXgceAp4JXg7V8K09v meGKQSebabueoNlCn6jpw/SAnvxzXP7MEjigW0Dm4N9AAqxzr8vk/sw1dyErIPOW2yEJyLzuJkgC Mq9YDklA5iWXQRKQOWMOJAGZk6ZCEpA5phISIMTve6Z7D9fAMRczd7GNXw4rXQ4rXQ4rXU4yv1xc 9I0s5nZPS1YWLHa339cry9XYzhq3sMbxrPEB1ljPGq9hjctZYyFrnMIafazRyRrTWKOfNW5mg2CK RuZvOydb4E9kjdtZ4xOssYE1ZrLGDNbYnTW62UB/iHtaRuapSZmatBaLRYf0N0MRfWzcA4t64PMe xIStwF1gRc35oeRODysnpYk0vTWrKJzvMzh3HpbPC2j4Ah7DC7QXLOMBvQA3egGdvIAObMAi8FRw B/gYWAFroZ2Oia9W0QbMAReBp4KXgY+Btep0joE5zYtM8Sl1YmLSOZGJjwHL/AVc6bg83ONPtTvt PvsIabWT2dLYmDQljQ+k+HjxIufQO0LMsvEry9dfWchQbOC38NUidPNbI+nqlm8QutnalszNruI4 dielyfA8VkCZLAPpIGpQ8/3JqRdpPjn540hzW5xVaGZrycx2tTOraLXR9Y3zoOsTZ4hDPOLc7Hrb HZJZi+tNlDy+0bXHeYPrlZyQHiVbMkMMSbtbVd3kHOR6YruquhwVd7e4rhHJRtfVzuGui51qRX24 YkoDcn6ba3zmJNcI9FfqnObyN6DPja4i5xRXYVirv2iz0dUXU/CFxSxMtpdTHdSbpnY4cWCIzfJn 69boqnVjdAN0ubpsnUfn0qXqUnSx+hi9XW/Vm/VGvV6v1ct6rid9bEjZ5/eJrwCxWrtItLJAWZXt XKD4YCACH9NzOo+C3aQKXjFhGKsIdkynimnu4JcTvCFmxPFQ4x3GgjEVVFE5LDjIVxHSKeODA30V Qd3YC6ubGbslgNIgX4VjUWV1iCmiaEWKeBHbRIw5VtycItKeK24OBCgx/rKixKKYoY6C8tIfgNoI +s5Q4jlyanBNxYTq4GOpgWCuEJTUQEXwd+JNbRP7nB0vK93EPhNJoHqTNJR9XjZelEtDSwOBihCr UvXIzT6DHjzmM1VPj81Z6JFbnxbWuzusl4H20OsuEugZDJSh6mUYDKqezIRec0P3stLm7t1VnQQ3 Nag6DQnus3W2Z0AnI0PViW+k7arO9vhGoRMcqqo4nVBJc6oqLJmcqoqTJasqVWdUciIqN5xWuUEd SWJndJxhHcu+Lh3LPuj4fi7VD/P5WOuQwPTJ4i231ltWD64N3njZrERx4nI3Tw9EXn8za6dNnyXS uvpgwFtfGpzuLXU3D5n8A9WTRfUQb2kzTS6rrG6e7K8vbRniH1LmrSsNtA4fmz/wnLFuOD1W/tgf 6Gys6CxfjDV84A9UDxTVw8VYA8VYA8VYw/3D1bFI9fGx1c16GhbAS5WatnKTEf5ai6PmsHj7/KGq 8w7xJF6T0o4TywYy4R3T7B0WtIBFVe/i3sWiCmtKVFnFp4xIVeI1Qzwp7WxDpMqOYod3GPkWLW5Y TIlls0vDPw0gFC1aLAweRl/DjxHqyoL+utKGRUQVwawJFcEiHPSbdTqU1opbCg7uKjOZyvAyFS7s g8LBolCSTiuKskJRZjBEFL///BdH0hKxChr55lbmT2OLqCEgBdMqKjlCQWXknbEd5ymxRTQEcIMN zMcauvqITNvno3CexD138aLFESlii0WRNNwSTRq6THKahLF8py22SO1WNaePNO2UBE7WPEJJciYl EimHwUdE2jlbOSLqRcr/joAXijDRBnqCzaYnaCs9z46j1VO0idpIHIdK6V66iu6gldjiJqHkBhqP S4PyO1iS0kY5tB6b3HraCd0L6Bpqp3iWqHxCy2iF9AZarSALpVMxjaV5dDM7X1lMk2mvfC0NpPPp UprPGpVq5RblduWP9BBtkl5Wf/+XTNNx7VQ+1byjvE+90eL3dBftZbcbniY/RmmE5h9oId0t1chM mal8ixl46HLMQaZRtJN1cB96r6fDLJFdJZWglweVoLINWk6qoVl0N7Wz/mw492gmK6OUnRSPMZag 17uohTbiCtGz9B4za44rf1SOUxJl00jcTxu9xjqkzlPLO4tgMQ2s1IsKUDOP/kwv0W7mZc/xeRqz Jlfj11yh7KFY6kcTMdtH0PJj9hW/Btcy6UW5XBlGVtjlNmFt+gvtZ8ksh41hVbwXn8fvkxbi1Tcb bfvh+D8b9l6L3j+EO23kZr5LelB+XD6pTe3cp1jxRDLpHvoDPccsuFM3a2C/ZW+xj3gJn8rv4Qek O+RH5dd1dbjrKTSXbqbH6SsWwwaxcexCNotdxVay29hdbCfbzY7wYl7JL+bHpFnSAulZeRiuCXKD fK3mes2N2iOd1Z3bOv/a+ZWSq1xP4+APyzH739N9uLNNtIvexbWXDjANMzErLjfzsInsSlzXsJvZ A2wDe5S1YZTd7AD7BFvTF+wkx47LtTwFhyBxFPLyhTht3sHv5btw7eb/5N9ICVI63lL7S4VSQJqH Wa2UbsX1tLRfTpZ3yQrsnKtZo1mn2aB5XPO85rjWrPst9vod3z14KuvUh53UuapzTWdLZ5uyn+Lw DLGL4OWrELOvwzUHz3sNPO4peoOZYbtklsWGsvNhmalsDlvAlsCS17G72UPq3J9kW2Clt9kxzNnC neqc+/D+fBgfg2sKr+cLcCi7nbfxt/i3kk4ySTYpTsqShks1Ur20SFoqrZGC0g7pA+mA9KX0HS5F NsouOV3OlH3ycHmqvFi+Tz4sH9ZM1ryqOaQ1audqr9eGtJ/hdDNUN1Y3TlejW63bqNujr4V3vkBP 0zNnf59n+6TlUpn0NN3C8+QkvM68Bn+eSjOkURyeyjewVfxq1sa7a5Zoh/AhbDQdlzNh6xf5Ov4l HyKNYhVsAs3h/cK9aWPlx5AUyi/QUXkL7u019LxEa2bX8GNaM7Uw9f+xyv4i9ZV90qv0nrSX6eT1 9DfZyBLYUf6INBZe8Kw8VFNNHuleelJawK6mp3kZkfGk/ib48Wj2GOJCJctlX0sK3mRHw4sGSuL3 pBfzd+go1vEqupPNkGfSLZTHrqLD9DBWRS/NpdosbRx7hc+Wm3g31kZcflT8v15ZdyZpYuk6ViPd rT3G36XFtEs20ofSnzD7XfxJaZR8XDOezcIKuJqupwXKclqqqZZfZzNJYlWUIYvfnV4l5coepMsQ VSYjpm3E6m5HHCiWRqEkEZ5zPvxiIiLE3bjWIk7I8KDZWOMXIIq9Rm3aSh6imRorQ9Qhkl/tHE+T lIfpLmUmXarcTr0RD1YqV6HHDXSIVtMGtqLzSpqP18p3sbbP15TzXZpypTdv4u/yCXzNuc8X1s5g ifR3XE8iM1SzmZrkt2kCFSk3KW/Cu3siwt5F03BwPYi7/BQjjJA6KK9zNG9WyqX5uN+9NE55RHEx I81SLqExtIUe0mmoTufDMw6y13G/V1I9H68skuo7Z8MOq2EFP6y1GPHnBnmBfK38DZH6HQ6BTyN+ RaWjYW2cHdTqQvwufzfSyAclMurkg4yS9FrNQS5tgUMZEF76UKLP/mXhqcLR9hOFo04VUhFk+3eA fn09Do8jA4CzOH3nljq+82voJLnlDvEbvCDuezX2Kw0Z6Opmrfjk18JJE+JP+U36Qq3RMFgu1A5m LOfgqYNUdOrjopRmp1qbiVpOWqPpVckwWDNILqRB0JMKOXczxl41Gk3LPevX4iyNGdUUjrIftR9E Fwftn1JR0Sj7qY9xlm7V4KjD7IX2wkCgX99ukiPPIUn98+IOD9yb/+AudolkYGWdm7/7qvOOnTvF XKdIrfxyda4mWrwJm+3XrekZ+ZqQ8rU/PbNXvklrhLnxNqbRaE2fGvR6SeKk0xcabYZGAzfg7OGP s9jyDR8ySS7kzG9x5LMk84JHEsUUfcJq9lO+mkLVeGJSpwoBzBFTUCC4X1/m83UT05PyVLw1d2fv D/rt7Cu1soTjxzs/CaOY5314fpMwTxulst7+GLeLleidqWmccYc9zUb6hGK70in+9ob5qYoSlM/F X+NE5C9RbmF+v6sqIdNtYC6/xcInGtx2O9BoswET1ZKQcsJvNpu1Ew3JrlS71WQKMX9bld1osYQF 1EHwW6vsbqZ+RxQ9UEj5sk10ogqiHwjftpnNqvBVm+iPhDnRDaSatCGThVuFz0OwDLAwkq05Ko5D wsuKVCcrWeofIKXo8DaowfugrE1KTE7kWpPRbLQYJW1cfGx8t3hJmyIleFiMFZCod3pYvNHhwbEK hs0CLWc1eQ5PbkJ8QnxMXCy3cm+GJ3fAwAED+udn9sj0eu5j3zw+6ZrAoobRV9y2c0VnMyu47aF+ ZaPuvGT0E507NO1xqedP69y17ZHOzkfrcp8Y0K/sk4c//ipLfCtdi3hrw/OwSzmt+ixT2EIcwiZh 9GYunH4T6ZUv/SZhCr3V4uATeUj5tE0I8K9P/T2FZI4R1RqbWTIQ43qDyUp6AzeatMK2Jruwpwn2 3Ci0THYY8uO2iNW/7rL6d2Gr58B4O1XAaujosO/e3eGISSjw+VQv81FKeCX6XTq3yaSdqFVRUlFW UaOiPqR87vcKiZtVDa14gtyq+oXqHUYVdWIG4pHqxcN1CSlTw8xuY0y+TQWNWSJmNZFez7hR3Ljo TRXUTjbzKvErb17lt5A6EGm7XEXtlpi4lxM5J1SXKCosDN9MTfhuzjqUp/iXEbfpY3mKXr7MfL35 ZZjSPNI80ib1kjMs2dZq6UL5MssS60qL3sQ1+gLLAOsYXiGV6vz6UZZhVuNafpe0RrdGv0F6RKeN 4Tarta+Gx2o0XG+2WPpq9BD15vG28czPONfrDUaTyWKxWu3iOdXGNMbwmHa+AeurX4vGrQ+xfk+b DQhU4bVjNIaXjKHK6Pabl5mYqR23bWUm6PIQEhujYiMWaNdiJXWxYhE/U0Vu23w7s4d41TNuTa2m USMhRm5odQwJJPqSEP8QARNPicVzNDnJfhS55LOyB2sosaioUI05XVey/ejRlZo+vpVXb1vZJ1Ek /friXcqEd6k0vEs9S2blJDz2LeLKW4MGDQqwiqAZdT3HTQrykqB/7CQ4tEX5utlqFJXqa5VF2bPR U2DN9hRYQhAHFlhzB6ri071R2rsg/JwCCxfU0IIaVhPAC5YP65HFJwwYyDwOrwNnb8daHAQu7Buf 1B9HOM3mzqqnOqs17Sc/v23E2Huk774tl1892V/ed9ItouB6RMEnsOoSKZ2P9XtiTFYWM8A5yXWR fq5LNthVd1RRp2J3xGc1EmFKJ1TB3CWYuoSYkHKgNSY5H+nx1vQe+Q6RT+2Rb4+ktkiK+ndaUzPD 9dC3R1JR7x8JIcN6nvM89wTTZOdc50LDEutS2wrjKtudlkdtIdsR62GbHUvI7bDFOhw2h81siMEJ OjneqI1x2C1mTaLBEJ+QnJSW8Gel46zIjd1FLI2EBPKki1hPiYk2m1Wfdk6wTzsr2Kd1Bfunq9Iy rfdqQ8oRNUxou4KzVnxRSxI3rtUKE2lr3N3nd2/sLnVPT+Sqs7ZVJXaF/kSj2RKO+Ik/GfHDcY60 6lL+ocDvHbIhvCt2hf5R4dhfowb/pIOJkegvXFXE/5gCBADsn4UFOVj5zJFQsNLax6e52g63ZTXn vFaLQFADh/Qb9X5bgc0+2BEzWPgdW6B6qVX50J+cVOBITyqIAVv9zgJ7eizYBY6LOKkvIDaK+Pi4 WK0Ou0VCN6/Uh2OL8DpQrO4XXs963rRtxxXb3xjVc+L5yonnJ156QW9PxX62fsWa0Xc+2NlX0z7m 5aX3vpWa0X304s4FrN91Nw0y6U4tlvIGLh0+63rhv+XKEWkv/NeBXfyQ/yojly0ZlnxLqUXTP7a/ 8wJeaRwfO8E5k8/Q1Bumx9Y6O1x7NG92+yDpULdDsccS/pF0KHWfS3HFu1y+5ML4wuSK5PmuW126 Pry7pU/8YN7fUsHLLOWxI50XGKssMy2HtIfjv2UnrHYWJ1lNdhulOE06BxnjnJIpEWHna/FXuqrb JEJW3QnPPI/R5i6PasMx22GDt51RtSknTnuerUvP373KlmG373Ywu8PvqHU0OmSX32TiE8NnDUeM 8BuHOF84hOM4tFYrUD11OMR+YxJe47Da7VqRD+8Qjq6dwLG5a3YbqxyLYvSR40iMOeKuMWF33VgV 011nj5SJ9S88d0jVVt0u3V6dopNduiLdGJ2kSxPz0iUKb9WliRno1O1HZ1bjRrK6tyWl5Y89y1lr Fvh8o4R7njrL6WoWINYixQGv8KDw3KPYpsAOcbRDZK1hIup5+mu96ZmZ/fNjBuTlxifgOMpi4/Ny VX9K10qD6rcte3PxnD3X1q7JaT3l/tPiyx7acOWS9dffd9PJB9cxqWlcMbd+W85jdmx/7sX3dmwT n7pXwJFelIfChw77h+R0Y3aZeeV8uQSv/RfJi2StwaE36A2Wbg6DhSQ9Mzm1OqYlo6HnrXqmT3d3 Y914uqNrhTu6rOnosqYjg5E41trzBuQfF1/W3ST+tlFWN+auo4ffIR4gyV1LPnIOEc+PxFOOt9lO b+h6dfmPjhm+7cy5TzWpevY7aK85sRBvAUVFRx04FBcUqIdjsr+y0qruTzULxQkuL24AzJegEzbT aeMcKx4YOrvowilDhw0bMiU2Tc5cv2DE4Ed6DC+qXXhqD2yktOO9awN7A287ic8S58dwtPoHzHa8 WcNy7BjtKEKIp7+HbeiMYZ+yjCcjbTQpP91Gk/LtOk3dmTaMfqzNoTPjUGc7Kz/TRv8z2ujpq3b9 WW3sP6ONnY612yNtxL+8p39S8wbl0xx/6Yp+7PJ+rGf2oGw+0cvKvWx4MitPqkriZYlshYFdbmA9 5UEyT8lzU6a7J9lMbgv1SXN6PA5tWrxk5T3NpKeibdvwmPLycvKOspz3j+ba3z9qP5rbr2/NGfI4 8vtwb7qVx2Fzz4vLGyrl5abxhEgqCk/Xy+f5qn57weK1k7wdG/XOwIIVI0bdsDCQqu9Rv/TGUZeG rjuvA/XVi9cGvNJ5/4e9bwGL6jrXXnvtYRiB2VwFVJSBICLeEIy3EKOGGGPQWCUGqTGgoAMiEBhE U5qmqSVqJBo11toRLyH8cpsZOcQnpRxrDJqY32NFor8N1qqxUWzisdZ4jDXs86611wyjYmpO2qf/ 8xxcz7u/b+29Lu/61rcue41uX/t1Ufxzb/528W1Mnv8v4blJA8OfyJ/5eG5yzMRNXzXernFPgFkW e3Md3n3BuDcZPzFyrI+UpJcep5Iuys/X5Et9fUN6DyQGk4EavIYYvHoPIe/JsWz4olXPf4ll5/kv eZsCI0zE349ERIxJiJ9AH2bEH9oi2aRIKaLzYuelzolN13M2zR8Sn/nWwi91L3Ze7rzQ+VnnmYoE 8/bcvC3zBxPtLcFjBJj0JjsnztsSJK0IklKDpKeCpKCAgIE6OUgnB+he8/6FN13mLS32luZ4S09g j2g0DvTQB3nojR5rPKQVHtJY36m+tFj3cx3V+fl66Dzl3gMpDdF7DiS9THgJlYP03mhBo4dOMnix Tmp5LKElnrUlHo35MgGrJ+saP/L+ax5DsHxKz7uioa44Xukf8n8I2zFc2QYtOCRhNPZoCR4jbPrO utc7bTqbpJcCgvoZqPeAEKnPl/Lrt4tl6+1M3YvfBI9aYApfnEjPCNsfRotDMG+kThwWFMzmoCg/ NpH4R5EwvzBTmBwW5hUZahhIvExe1Kt3UFDoEE/PXqYhrBENUi/WBDYZgLl/AlrxTYs/75N4wH8c f2uOwNosP8SZMq/Cit07OESK0GbVCN3hCycGPvrYtJG7mmhY5o6CxPrqHy35Zr70yOr1P1rd6ZDG jH5yiH+nn+5F01Mlqa/uDNaN3CrNmJP5zGx2YDNahLWY8753wBx0V5AXOoPug78fPP50/6Av6Qk9 oSf0hJ7wHcKb/5RQ2xN6wv+H4aD+j/qve0JP6Ak9oSf0hJ7QE3pCT+gJPaEn9ISe0BN6wv/e4Lns AcNv7g6GUa6wqSf0hJ7wvynwf9wwnu4jzo9e5fCrzP8xrhePMZ0ShXxBnF8WSyJHha5zS+NBQqUA oeuJIsUK3ZNkutIYSBxK0vReZI00VuhGukU64Pr21cO6NKFLxEO3TuiUeOp+J3SZROr2C13nlsaD +OjOC12P9FeE7klGutIYSKguQ+i9yBO6r4RulJI9xrMvpenY17t89GVc94Dup9/MdT2/X8V1T36/ gesGrh/gei9hQ03XbKjpmg01XbOhpuvc0mg21HTNhpruSRbojwtds6GmazbUdM2GTPdy4+/NuHmO 4rqP232F6Z5JXPdj3DxTuB4IPcBzAdeD3NL35m3U9GC3+314Xv6FOV0/XpdWZn+3NOFuehRP/yrX Y7m+nuvDuF7BdIMbf4NbXT5u932cbakmJhIPi4zE1URSiJlkQU4n+SQPsJAVpIDfeRyxQujsmoH7 2TzFcDyZRHIRTGQW7i1Gfgsp4rEsyCykXoZrJlJOgp6NvCytCRpLlQFYeImZSLUUspAswb18suh/ xObulOPvqJVxWkyK2Zc1cddEYpA+myyEng82rE4LGUzmcNZFokwTGY1yx8I+XSVNB7N7OaW4tCTO qgSp81CfiTyDkhfxmtjTYZxJPlnAn5vIDP7EjDuMVxEZinszeasK+ZNsbqXZuBYjfaZgZwKjceAV T+YiZzHizHorIIu53ZldzcLKizhXC7c3ixfwMpbiqQWB9Y4JbFaIPCzvE+RZkowWa3kL3Z4UcGtl opaFvEStDSW8LtaK7uvV4iztQrSymLcik6fNxzWTPy/g7V/BWebxpwXcAloJC0VZWfzK/O7udrPn uVyLQa7BkMyjFrhq6o5V3j0lP7iNukrPdPV0Ifd6Z885/bL7tmu138vrETcLsJZobbHw+pwez8rX 2pqJOyW85fl8FHXfUs3OGXfYNIv3a764aq3S9GLECvjVxNkuc/muVg5LmYsU39pD1ab4uJHxphRz lml6fl6+ZUVBlunx/MKC/MIMS3Z+3nDTpNxc06zsxWZLkWlWVlFW4bKszOGTCrMzck3ZRaYMk6Uw IzNraUbhElP+ovuX4rw5Xss5K2txcW5GoSlmevbCwvyi/EWWwXOyCouQ0jR6+NiRPNH0FFdJKeyS VJhRkp232PTMokXZC7NMw0yz8hdk55lmZC805+dmFA01zcywFGYvzM4wzc4ozstEcaaR48bGz80v Ni3NWGEqLsoyWcygvCg/z2LKKDIVZBUuzbZYsjJNC1bgSZbpiWeTJ+FpIY8UFOZnFi+0mFBDiRlV uOWFzM5bmFuciayWfFNmdlFBLirIyMtErmwkWIhUWXmW4SZn3fl5uStMMdmDTVlLF7BMXUXlORN3 y4gnz2SNLswqYo1jtnSrHdldZT3CCcRkoxZL1lJm+MJs1JqZX5KXm5/hXik4Z2hMswpNaG4+qsK1 2FJQbDFlZi1j1kUac1ZuwV0NwhyYz0cbm13z4NdsdlwhGeFLOYh38JnW+Xw2vEsbH2wcZMpb5T3y v8u/BX4tN8l1d8z4/5xVpostqyXbFT/H2Wfd0ZqsO/hyxroBupG6p3VP6h7FdRxSZ2CEMW5a7WbJ Ie3Epo7NKKwthXzeZ2W4PqyqDiKbSfd/ZMJ2U/5EUlXtq7XT6W8j6ThdNCETP/VoQtykDRXnHxV/ yGNq56RZybPi4pBK2zfy/wmYRtPhKG0utLVEouX0l0SmW+lW6L+iv4JupVbo2yj2HXQ7vQr9L/Qm 9K9lMJADZOzF5EB5CvQn5aehJ8svQ/+J/BNC5Vfk69C/km9D/0buhK6yf02tI7oi7GcsOuyJdMW6 FdBf0r0E/Ue6N6Fv0G2Evkm3Cfpburegb/aIJ5JHggf2aB4Pe4yBPtbjEeiJ+iQi6Z/Qo159sn46 9Bn62dBT2L+p08/RPwc9VZ8Kfa7+h9Dn6S3Qi/XF0JfpS6Av1/+cUH2Z/jXoq/Sroa/xrCSS5zue 7xDZs8rzXeh7DZMINUw2lBLZ8GMDWmf4icEKfZsBe2fDfxquQ/+qF2rpNbdXCZF7LffGrtbby9tI ZG/FOwb6YO8E6KO8/w/03d526A7v96Ef8G6BftD7/0I/4v0fhHof9e6Aftn7S9y/4v1X6Ne9b0D/ L+//gn7TG5b3/tr7FvS/ofNkH8nnA+z0Wnw+hP6RzzXof/W5TqjPV0Y/Ihn9jX2IbOxrnAP9OeN8 6C8oqFc5oBwgVPnAN5RIvn18Iwj1jfSNJrLvIN8JuPOY72PQJ/puZJ8fEp5CSQTvL62ntD4SvQPL zIIdUgywtiHVADsY0gyoy5BhWIjrIkMBrssMK3B9CTZk1vsprq8asMM1/MzwM+grDdixGl4zrIa+ xvA69PWwMLPtNWFJChsOgT7UewQsEOcdx630Z+hfeH/BLXAQ10M+h2CHD2EN1vZgXEOMIWh1qBEt NfZh1uCt8SIf0SvEI6MwYwExLVxRmEtSFhdmLSGLzFkLCsny3AxLHllJsOefMmmWiYQ9OyuJrdOE jzcPYiTBQsf7BwkRuifxJaHcXiyu429RfqSP2x0J7yL+pK/rjsS/g0yTU6aayICUWU+bsC/UUlIw DCT9REwm3iSIhImYDqO2N+lPBiwsKCoge/l1P79+zK+f8OuZJVmFeeQSu0qEX0P5NY5fR/NrIr9O 5tepbBmWZvBrKr8u4Ndcfi3k1zJ+reHXffx6fOmSpUukz/n1Cr/e4NdOdqV6flX4NZhfB2jvpeQh EvUdNC8ykESTQeiBwSSWDIGVhvH/Ve+73ne+L3d/lfkHtuT7aBL6l/Uo3phx9UKP+MAP2H/r54de DET/9IZXhMAD2Fc8+qG3+rPP8WGFibhPvge9R9nbe7fSD9709+RicoycImfJZXKN3JKo5CUFSH2l SClWipfGS5OladIsKU1aIOVIhdJL0qvSGmmDtIN/S+Rj6bj0qXReuklDqYnG0Dg6lk6lqdRMl9NV dAutoo30AD1GT9Gz9BK9Sm/KGLaynxwqm+QYOU4eK0+Up8oz5VQ5XTbLBfJyrAar5PXyFnmHvFt2 yO/J++WP5GPyKfmsfEm+Kt+Eaxt0frpQnUkXo4vTjdVN1E3VzdSl6tJ1Zl2BbrnuFd0qtMqAVWQ/ H01S/AIWI/TRyxNiYRPcmbAeFoSctE+Tj9/QZrCk45qcm6rJtFhN/nCVJuct0mROmiaXTNZkbrQm i1YSHfsEm0UheriL9NPLRA+3kFbO0piU+XAmUhn712OeRHrNR7v/WrSQVk2uXsnT6V63vu54veX1 U1ps7ZS1aWvz1r6qxcqTylPLc8tfEbErb9A3gt+I1fK/8YUm153S5PoGnsrw5to3d7y5980jb55/ 8+YGZUMUv2vccHbD9Y2GjWEb4zYmbUzdmLvxlY2bNu7e2LzxmMZ2UyT3fWnTVE2+9akmN3fiOSEe 1mPWa9uCto3elqrFt+Vse2Nbw7aT225p8QqlIr5iTsVLFRUi3lBxqqJze9T2aVp8e/r2su11249v v6nFdyg7Ru1I2/HKjioe1+1o3nFhp8/OUVps54ydy3ZW7DwkYmd3GXbF7dJq1u0q3LV114Fdlxlr Ir2tE9JHyADNGm/3FfK6Jt8xa7KqQku3O0DIvvAjJidr7d2dImS6kHlClgq5RsgtQu4Ssk7IvULu F/JjIU8KeUHIa5qsJkIqQoYKGS3kKCEFv+qZQqYJaRZymZArhdwgZIWQgl91k5AfCSl4VZ8V8rKQ 14Xs1GSNQcgAIcOEFDxr4oQcL2SSkDOEnCdkjpDLiTTkEhtRkg+NpMl0Dp1HD8g+co78nk7vYfa4 pX/F85DnMc8znpeAa57XDKP4dbJhk+Gy4aYXZTGvUGhpXMtECPWqQrjgdcG70yfZ52WfSp+9PpX8 WZXPWWOw4abnNWMwC4abxlzjVuNZhSorla3KJex5cn2rfE/5UT8fv33+85SV/psDwgIWBeQG7Ao4 5VMZSAP9UBpC4ITAqYFlgUcCTwalBB3vrQs80ju+9+3g+cEXQl4O2R3SFBqEZ0dCF4XWhR6AvBp4 pM/8vkl9D/XLDIsNyw2rYE/D3gs7Hnikf8oA/QBL4JEBnw+4GT46fHn4rvC68OPhF0wBpkTTFFOK aZlpi6nG9ElEcMSoiLSI3IiXIlZGVEW0RByN+CIyIDImclpkZeTnDyV6VT30clRcVFnU6YGjcc8V ok4L7fPIzwdaBo7mtkFaLSC9Fk6zEDltYNnA/cCZgbfZNdorOiY6LXpLdINhFI8fM4yKPhY4YdCA QUmDzsSYYmJj4hCOxlwfHD24dPCBwV8MSoqdEDgB8S9irsfOjN066MyQUYOjh+QN2RE7IXYCS427 M4fsBfPuQkx3AWtflLqOjFHbSaLaLv1FXSd9DfxNXUcloJfaTr0AXzynxrfVsYpBZV9sDVLNWHll ntNMxgHj1UaUYCZzkTINmAfsVc1GK1ABbFcbjTshPwD+ClwHvgJuqA7jN3jWCahqo0IASTUrFJBR XgDxVfsTfwA8javV540bVAtjYqyBXgvUAfWADbADLcBB4BBwRrUonurznDV2puDYxdfM+c7Dvb0o uYun+T48zeBpBk8zeJrB03wHz0CU3k58O28SfyAKqVYDG9QqcI0CVzO4msHVDK5mcDWDqxlczeBq BlczuFaBqxlco1Aa65FxwHitZ8CvHfzawa8d/NrBrx382sGvHfzawa0d3NrBrR3c2sGtHdzaFcYq VeMGG/qhx5gt+wMDuE3NJB7PkqBPAaYCybDILMhnIedApkKmId88WKlYPW9cBpSiph+r/Y0/BX6G nmNtfR331gEb1CbjLyB/CbwNvRLyfu134FkT8BugGfh3YB/gbpcPEf8IOAx8DBwH2oBPgBPAGdRx CbIDuIwWazZsUhar5xUzkA3kAEuAXGApkAfkAwXAi0AhUARYALRRQRuVEmA5sAJ4CfgRUArUq/2V X8NLm4DfAM2wTxSsmySsmwTrNsK6jdy6ScBU3E+GlWdBMqsyi8LvYEEzLGh2WXCDegoW2/CA3nJK tHQDGJnvYRQBRuvAqB2M1oFROxi1g1EjGDWCEWPTDjbwDj5ar4BNI9g0gs0VsGkEk6Ng0ggmjWDS CCaNYNIIJo1g0ggmjWDSCBaNYHEULBrB4gpYXAGLK2BxhfzANSr8YBc2MvqDzQD1R262SRIel0Rm I54CmYo0c7m3NcHbWsAsCcyShJdZ4WVWPrJ+AflL4G01B15mNVYB9/c0KzzNCk+zwtOs8DQrPM16 l6dZ4WlWeJoVnmaFp1nhaVZ4mhWeZmUjFJ5mhadZ4WlWYf8cpRf0xfA4M5AN5ABLgFxgKZAH5AMF wItAodoCb2uBt7XA21rgbS3wthZ4Wwu8rQXe1gJva4G3tcCqSdg9PcVmU7xnybxXWY/uJcnsi/iw mD9AXff9vveMKyv91VZlEBCrtpIgWD0H1h4LK+th3RxYNwfWzYF1c2DdHFg3B1bMgRVzYMUcWGks LJMDy+gVL0gjEAREAuPUcry5vYuR+o8uVeaz+xy+6rSTyT2+I3zHgw5T0+loIBn4gdpMU9TmO7yE rXfp8JL0brzk7vUuHV6SDi9J57uBFrSg5Z6yvvva6fu9VrcpPavSfValQMwK4ZgVwqWbpBL7uiTs 65Kwr0uifdXddBBJxUhKwkhKUvwxfwdBhkJGAJHQB5I0JRp6DDCYpBEflNCOEtpRAtsV7sOucB9K OIESTiD3Ccwb+5DzBOaOfZg79pFeyHHQLeVBpDyIlAeR6qArlU6KVz+jYervaZR6mK5VPyNe0nD1 M2kEMBJIwFM/IAQwAZFANDAEKY3o4yrenzWQtUAdUA/YADvQAhwEDvHdVRXrA9L7n7LWefM57QHm MjaPEX9pqHpCGgb7eKgnsM82w05m2MlMg2FdrNWwRjv65QT65IQSBu/pDwyA3aK5hc2wnZkYmHW/ tQ9MqKcc9ZTDplNgzymw5xT4Qw36xozeNKM3zeBQTo1qBQ2AHqg20lDIvpD9IFEv7D4F/rKADlan oDYzajODWzlqNINfOXiVw28qULMZfjMTHMvhNxXwm5mYgbzUVrSs9Y51JZC/PeAN4R9iB4WVxkoS pax2lvJ3cwYg1/uofx3scxE+dxE2uggbXURJ78PvLsLvLtI+QDhgAqKBwcAQ9SJKfx+lv48S37+H g/mBOThH1okHHlleYl91C3uqW+496eod1jORbGeA0VWBUVVBhoq3AD4jYB8Wjn1YOPi2o/XtaH24 FAeMBBL4jNF8l4e0w0PaYZFwivw0SJ2BHpoBT8nhntIfcgDeGE149pA6E722jg7EvUGkmcYg3WDc j1VnuHlPu/CednhOu/AcNuO0w3Pa+YwzyNVKP3UKa6nYPa67j0/fzfhOnw6G3r1fr/gf+bWC2hvg MQ1g0AAGDbBNAzzl9yi1AV7SgFIb4CUNKHkVSl6FUlehpFXYm6Nd//JxGYCaS8C/EbWXwEtqwKAE bShBbe2wVg1qa0d7KlBjO2pko7EGNZagbSWosQRtK4Fn1RCJzd7EeM8I6m70RN45gniuc8h1DrnO IRfzsHNIfQ6pzyF1K7zpd8hxDjnOwYN+h1zn+ApxGLkOI9dh5DqMXIdR12HkPIych5HzMHIcJrJr dWEri/d98znzRGv5UMthQpWJapsyR20jvhg3eowbPalWS0gN0IAnw2FN2Az7zxLlUYClToJ8Even AcippGK35a8MVS8gdRtStykPQx+DNWMc9EeBiWoHcrUhVxtytSlP43kyns9Qf6vMhJytfoGSOsBm OlLOhBaOeTMdZSbwMuNEuaN42QnKWMjxwCNAoqhjAjAJeJwzbFOeAKaIOqcCT7nqTlCegfwBMAtI AZ4FnuMtqVTmwhas9pJ/We0+ylASgpo7lIchx5Bh3H5PAtOAp3EvGfemY6c1G5LZzRupm8GxWfRT s+inZuRqRq5mpG4WfdVG4tG6cjqBJNFJagd9ggyjYEifgv40JNtDT1er6Azso38AHcxoGgmhuZBL kSYPegnqHYr+0azToSSQJFgHfHFvDHYgY6GPBx4BEoFH8XwCJGsH6oSV4A+49wTkFN42ZqUOWKlD WCkd/lEFS3XAUh2wVAcs1QFLdbD2wlodsFQHCaXoB96KqZx9B9hXgn0r2HdQ2BktqGRvA2hFB0UO mgUsRQ1DYWtuYcgxWK/vsDDuJeMes2wEamim6F06kdfUTJ/gtTWjtmbUVoLamrmtnoHNtNrKUVMz nY90i4Bc6Mxu+cCL0FeghqHqW6L2t1B7s1vNb6HmZj4KZqD9M3mPdZDo7sYmmJWAWQlYtYFVOZ2C dk+FBH/OIA36PGA+0rwALICeBSwCFgNm3MuBXApZDLkMWA6sgA896Lj3otPhDzO4pZtoBnzKjPhS +McY7qchaEsb2tFEdJznEu4F2owTLHquTes55JsOX0wBmL+9gNnTzHur4zuPhyDRS06faEMvdXCf wLhjfvCde8D/Di/T2tz0nXl5cA4/5BYKcc113oJZh9ZugNlwiZYKPtOB8daVuh/3eadHsnbCwvC+ StG2NvR3G/fzfN7OP3CGCfDph6FrM3Kl8hh2dtqsXOnW9j+gzZW8zWyUsbliHPYmP8a+5MfYl7Rh X9IG7yt3eR5KcPM+t77ko7BNjMJKziqNj4l09GsV+rWKluDeClh6qHqSM+TzCDxMm0dOolfa7p1H 8HyC8CDXPIJ7XfNIh9s8wlp0Er3Zdp95pM01j5hcNuUzIpg6WwNf4CP8GbRQO1lo4nMJ66l0eOqL 3Mbff+Ub5PoNoFqtgo2rxAhnc08znYjaNGZtYFXJ5xvNppUY4VWwaTlGdxXNBLJwbxG3cTrNhmQj fAkf5eXwiCpaBBQDy4DlwAqM5uHodbZ6aCtHh1g5KsG4krMbCS+4Ci+46vICjWUlWHYIb6gUntDM Z8cZfM7V/PGHAJuHnkcazQNKaDqeZ3DWlXQh9EzILNxfBLkYYHNTNmQOsAR6PmQBUAgUAcsBbZ56 8HXPT/RyM2eZjNqnu0ZNE2pnvniRl/Yw5Bi0nZXISnsacfg08eFtdM7+WhubxCzVxrlM5H2t1c3m OD33orRu5kM996HuZkoT232wGfxftgMZynZfbvNMs/C+JoyLNjHK2dhIEPNOulhfK/9ljPtp4wRr hnMEPwO22mzYjJEawvqXr8cr/gGzYpgYmVViDq50W2vKhU3YbFcpRuP3r1GH0dLh2oO9yPbrGP2t vI4XcCcdyODzPquPr7PMJ2keXwea+c7DApRwC7CxkMZWIoDtU7pKYDukVm4n5tVLXHVqJb2I0i3a Hgbv52JPgpLaBI82UUIbcjMObTwlRZ42toaRXqLGNje+zW47pDbGE239odvaZyHDsEI6873gYtnF kO9Kxe4KNWFPgvGGMobxtTSD9b3bmporymZ8KL/LrCnzGljJeEYMbhy19jgtny+sz1K0iqdNdz/l rdZxrzN3reDcYnyO57Znfsntjj2TZjHRGqT0Q8oEpEwgNcifJvYMXTlCeA6tly5ijtRyMhto/dtB PF0Wc2fv5NbL1ftOe3b1ttOWzOfuegorvSBiS7n1cjHyX8RuVLMXt7az/8UbQ76Lj9OiTubOp6wm 6mqvp2un27XSpGOlSWfrIenFT03/3ompB0lUj5ImoEM9KrUBn0E3kDHqeTxpwZMWPGmRwtXzUgTQ Bv0z3Avm53Ueqpl4AUY1hzRCar/wl3Xze1OZ8TrwFXAD+Lbfm/xcq3ut2t+4Wl1nfFtdZayBrAXq gHrABtiBFuAgcEhdp3gCBnUV6c1/+/EAPy+gkZ8rfv9f9P1cv+bXdt4Er1Lwehm8SsGrFLxKwasU vErBqxS8SsGrFLxKwasUvF52nbh1/e6OFpI90Bv432Uoc/t1wur268Qq8etEGWoqQ01lqKkMNZWh prJv+XWiDAzKwKDsAX6dsN7160SZsKT779i1QBdb9vv0ef572YP9Pn3e+RsXL7Xrt2j0KkptR6nt /OxdK7XpQc7fRamN/BQ/+J7fltFPKDkJJSd9L76+8KUm+FITfKkJvtQEXzoKXzoKP7LAjyzwo6Pw o6Pwo6Pwoxb4jQV+Y4HfWNjfF73TE7WTYdfYEeOm21Nhk3r0jpNhT9d5ba0a7vq1hv1SE4l2en7r GbF8x+m0p/O0GFa6dc8psc9d9dz/jFacz7ITMbdzWZQJy0+B5bs/h3SeQYrzR6K/769BrMVWMLGC iRWpjiIV+22K/SZ11PW3bO45Ef67DAZ0w6IX+qQFfdKCPmlBn7RgJ5KMHUgy9rdHsdNIxr72qDhf 8MMMy2beWmAPdO38713s5VqVeHUD9i4fYj/Xir1cK99vj4d8BEgEHsWzCfwche3pWrGna8We5kPs 6Vqxp2vF3uZd7OlasadrxR7nXex1W7Cna8WerhV7ulbs6Vqxp2sVb2Wt7GwB+7pW4ge+n7q9XX3K 39bHqX+5z9vVp/ztfQZqmI33bu1MEfM+7p4nkjKSbMablgdWLC+gEdDO+ZK72bMyCzXxfeu4++xd H0NND7Z/ZVZuumMPO1vNuWsf28z3sd3112SwmQw2p1DSZJR0ynVC2CZOHkLEyYOoz/U+0XXy0Ju/ wfmxkwy3t7ha6HtwD29x/O1lBCwVjzoT8N6svVGdFG9UJ7t9o/IH23KwLQfbcnaq6DoVZCeCztNA dvo3UZz4dfWUdsLHuHk98GlcEFJWi3c+1kfVSN0Bphd4nzzGPeKm8AiN7dNIk4w07uc5s/n51U1+ fqW75+0rAHXsFHt1VsdOfhIxjr8dO+twep2T4U5+ysD27LNhQeeePfqes5Pazh+j9Mtu5x0fivOO y/c57/iwm/OOD7/lvOPyA513KGLFbnNbsZ3jnZ0EXETNzveSi3ecBPigx0+hx0+hx0+hx0+hPeXi nbn8rnfmcv7O7NHte7HPHTOOyz5uM89QkojxuhYengiPTsQesZj9DRhC2H+mw/5+JmH/Uj4KQSaD EXRkBIIHSUDQk4cRPMkYBAMZR8ZjXCUieJOnEHzIswhGMpekwRLzEPzIArIQ3rwdIZDUkXqU/W8I weRdshc73SaEPqQFoS85hNCPfIQQxv+fgv6kA2EA+TNCuMT+mymTpJN0JEIySkYSKflKvuQhyV/y J1FSH6kPGSj1k/qRaClcCieDpAgpgsRIQ6RhZLA0QhpBhkrxUgIZJm2WNpMR0q+lX5M46QPpAzJS +lD6kMRLrVIrSZDapDYySjopnSQPS3+Q/kBGS3+U/kjGSOekc2Ss9Jn0GRkn/Un6Exkv/UX6C3lE +kr6L5IofS19TR6T/ib9jUyk7D+1nEQ9qAd5nHpSL7yD+FAjmUp9qS+ZRkNoCHma9qF9SDLtR8PI dBpOI8gzNIpGkVk0mkaT2XQwHUxS6BA6lDxLh9MR5Dk6ko4kc+ko+jBJo2Pw3jWPZtJF5DVqxtvA GppDC8jrtIgWkQ10GV1ONtIyWkY201V0FfkFXUvXki3GYuMy8kvjauNq8ivjG8Y3iNW4ybiJbDNu MW4hFcatxq1ku9FqtJIdxgrjdrLTiEDeNr5jfIdUGmuMdvKO8QPjIVJrPGv8jNiNfzZ+Sf7N+Ffj DbLX+I0ikybFU/Ek7yteihc5oPgoRvKB4q/4k4NKoBJEDimhSij5SOmr9CWHlTBlAPlYMSmR5D+U aCWGHFNilRGkTRkJn/y9koBZ41NlnDKR/FF5XHmcYIwoT5JLylPKMwSjDrPuVeVZ5TlyTZmrzCVf KYuVUnKDSF6feA9lX1CQgslkQqpXAmuIZI+CXA9shh4LaQV2CWkV6Zz6bsAGNAJNwH7kiYM8BBwB jgOngDPABeAycBW4AdwmpIYCBuQZDakAQfyZ9HPUW9MX9xMhTUA0MBSIB8biPvjWTACSCFkFHjXT gJm4PxVyDjBP8Nt/Dxg/zrEBdTQwibobEonUMBWYTPNthj2KTdkTVF1nK+M4bTvAUBNlu1YTC6TY /TgO2ecz1Hbab9XpgFR7KUckdIYc6ED9ZseheqvjSHWqLal6vm1adSZkjm1afaJjP0N1gW1m9TLb nPo1SLce6U7aKjkKkG4Z0tfZ8jhO22oY6s471tRdcqyvbrBZOM4jLcN70BkuQQe6+NpucnTFOzni oDOkQWdYbo/keFlgN9rHYBM4Y1/GccFeCrzqil9G/LL91dog+zKOvvZNHM64CTrDUHvVtyLeXlc7 1t5Qm2cvrbUAExBPQvwl6K8AlfYWjhpbZa3D/nHtWfsVjr2INyN+036doW4W7M7whmMqxyb7xxxV jhSOBscijn2OQobqK7AXUHfFsbnuumN93S2HtZ44dtVPRv8wiP6DPA55Cn3g4KiDrU+j7gPAR6j/ c/uV6lL02avos1WQb0AW2OahDxc4+7J+KspjmCGwC2XvRp/vQ1kM18GFoQU6wy3oDHW2lzhO2/Zy NNhe4Thva+YQ6WsI+p105XfF62xrOU7bPmKoGY1+Z0hHvzMkQmdYBJ3B5SsbCHxd5+b7XhyToU/u Lv36DRwr7TEcy+3DBUZxrLSP51gD/1rD/W0ix3roDJvtUzis9mSORvgdQ5PAbnumQI5AgYAW3480 DEcEnD561b6Ko8uH3+Bwxm9AB9x8eCuHMx4N/4128+Fp8M2Z8M0y+OVaN99kOGA/Bn845oofhX7U Lf4J/OUT+EtX+pNIf9oV/xTPP8XzL+DbDNc01L3qSORY5ZjM4Jp3nP7uBd9nmA+dwQ86QyZ0oPam gzDUzXKEcrA5KqZrnqobDn0UUACdIdKhr4sBchwD8PwS4j6I+yAeBcQ601eX2ksZXONtK8YagzO+ A/qObuMzODbZT3LscyxnwFisYahrwfhk+Fhgn+NlBjxrZqg7hntA1zxmD2aoD3Dsrg91rK8f4LDV RwGxgHMsO5EikCaQLrBIIFegUIDNATbHmfpGyCbHkRq9zcFQvxzPGPY7LmBuuAx5lctTe2j9mT2G +guQl/cY3PxsFYPb3LiDY469riaOz3XvYa7bh3kqrT7O0Vg/2tFUFww7h9lv2YL29K3ZhTHCIMZD vR5zlQ/mKiExxjdwnLYd5XgP6wbDJdiUoWtN+4SjATrDeegMH9u2cFyxfcpRZ6vgOG07y3EM8wqA tldyTIXdGXIxB+S6zwPoC4aV9lkcy+2pHM41pcsepcCrtfMwnhag/Rvgp1sA813jyzneKu4abwfs 5zF2LrnFTyN+sm48bDYRcI4FYcO6ZdCB2k5HQJ0OmOWIA0bX1WFdYHgP6wJDlSOdo8GRy7HPsZLB aZe6k/A9oMYHNgDqTiMO1AQgDty99tQcR5uPi7lpv1v7b6P9t7GWdtktjOPu+VSkr6XgDtScQhkM M5CGoRC2B6o3YZ3ZajNX74Csspnhj4fqD8FfQ22fM/D4EcQHID6Ax2/UH3fcRt9+wVD/MnyZYaXA VfjvDfjx7T3URuHHXTx1HE5eBvACXHEFcaBuCuafZIDND6VsL7Rnbb11D/PPZgZXP4nnWr/s2VKX in5JdYzeU+Y4tOcVPt4+Z9jzEuIWrJfnbZ8z7MlD3Iz4JcQB9v0w/vUOwr/bYeBf7OjFv6uh8C9q +PFvaQTxr2j049/PiOBfzniIf7Uimn9zYjj/ksQo/sWIRP6tiEns35rT/6TYucrhciSh8iB5NNHL P5Wvk2CPGI+hZI1Hov4Rsk4/Qf+4tE4/T79Yekufrc+WduqX6HOlXfpCfZFU6d3Lu9d/k/c1QG1l V5pXz1jIgDFNGJp2aMYhxKHdBBNCMGE8booQSY1phzD6QzhuLMTPUo7juN00YRliPQn9IT2EyktL KrfLwzqEchHiZRmKsB4vcRzCulxeQojXyzgehvGwlMN4KYd4vY6H7Hev3pOF2u5OpnZmt2rq1nfv 0X3355xzzzn33Yd4kg0m/ofECdn3krikb8p+kPw3OzK4V+lbKTg9+198+n+opeJ/7O/FrHJ5kfyL hCT/JvkR4ZL/d/ITErfjCzuKiHzHvh0lRLHjT3bsJwn0P33p20LE/q1i/wKqjS1fBKdki2uLG1z/ zy0PSdxW9dY3iUJeiHET5KXgOhlcv0FS2BypbI605H9M3iDp4CuXZLD5drL5Mtl8WeJ8Mu7SFsWz 88MHuBf/oJLIBnCf/0E1oAON+/0PcC/+gUksD4vtJLoFOA6cAjqA0+gDLX9gBzyAHwgA54ALwEXg EjAOXAauAjPog/PEBzeBeXZN1k7nXUA9zhgfLALLwCrwEHhMZP8e544PNgg5F0dIJ/g4lwCkoF6B Mh3IFPk7/SFQ/hiP38Uc36Ul5v7uUyIbxDlmEKdt6KIaJ3n6Jpx2whMP6SfnyUUyRq7gjD5H7pBl skae4EyeLMuQZcvyZAdk1TKjzCw7KeuU2WU+siVUHJoK7Q9Nh8pDNwgXHH/nSvByyAxqIlQfHH3v NKiBdy4Gx0LVoC6EqoIX3zsGSninPzgYUoPyhUqCZ0MVoDre4YP+UC6ozlBO0PkerWt653jQFkoD 1RJKCZ5+D3YSrHnHGGwNZYDSBJ8G68NX31EGdcFVUObgSrDqPax1sP6dwmB58Daow8H5YEnbOijD O1nB/OA11ncqmNO2CKr6nYTgzuAlUFXB4WBKG+QIPMBVeXAa1FrwauBp2wSJCx6hIwcfBGuC60FD cAk1NagxoOYIaszBJ2g9fvJK4GYQ8gcmgvWBa22nyZZgRfBcsDJ4IbgreJGN3B5YD3axkTsC99uO gFoImgP2YCuopeCxQGdb5T9jbIhnbwMi7D1A4TfubGNvu3mZvavmFfY2mk/ueGVHJskkMplGRv97 Pgl2AM8M4dQLbZPQTgAn3RBOuqE8sdwtXpdonH5DJQBOvlhdEsKpFzZAQjjxhmCtIXhZCB4VgkeF 4FEheFQIVhuCN4XgTSF4UwjeFDon1sOjQvCoEDwqBI8KwaNC8KjQDABv+jadEx4VWgDgRaFlkY/K D2NgDJgEcMoemCbFgZLAAaACqAxUB3SBwwFToCVwPHAq0BE4HbAHPAF/IBA4F7jQrkR+MXAJaTxw OXC1PbNd2Z4SmAnM/FuhvRR0buBmYL69JrDAqMXAcmA18BDp8V9sDMQNJAzQN1d+AisL3+bWud8Q jvtfWOU4tspytsrxbJWTsMpfwlr/SWStX8Jaf41kyP8MK57JVvxVuVFuJH+MFR8muxJHsO6fSfxt 4j+Szyb+Dqu/B6t/mORh9T9DCv8fzSojBnKO2c8B+narmOhJ3jkVEz07wjgP+ryHJL3f9P4xS+f7 J99vf7/rfdv77vd97/ef7zpvgzSJ3K+5X0OaR9wjxPfSraWEk9fIa8gWeEEtiZPXwRe2Jn4/8ftE nriRuEHit38dvqDYsRu+kMB8IfH/0iiy1PVPGLCfJcmukGOEnHoArANPCHkXQwvwg3flAOR/NxXI ED9nATnAHvFzgYhisc1+oDwC2btGjFVCuFNnUB5gJXkX8VNAlDw1HIXzqEP8EKrDoHXfqgGtC/dn OCzCJLZvAY4Dp4COSPtnPB0CNIARqGdjUJ5ZH3Fe8m4TcIy144TTYt3JfwLaga4o2AA30wd30ke4 ExciIO/6wnUAebef8cb4Y5/PvhDh6wO05O42D9nWPfOWTn7Es9A8Zl/1LFp4vtyzbHHaH3pWLbz9 Ma4KqHloOYP8sSVk3/BsWM5bhr1xrGbVMuiI8yZYhh0J3hTLGUcK2qC9Nx19H3ozLaOgs+lo3lyL kx9BTSfofLRMR0unI9Nb1DzdPecttUygZRmrUVquOLI9C5ZrjlxvleU6xq+yzPJnkd/CCDXN9xz5 XoPlji3be8Qy6yjymi1LaFNjWbGFvK2WB8hPWNZZzRP7Lm8bTxyl3k5e7ijz1vBJyKswghK9Zh1V Xp5PddR4W1s4h8Hr5DMcR7wC6pVomeUwe8/wOegbAq0EneVo9Z5vfuQ44R3k9zjavEXIO8E/9OYd 5gscvGeVL3Y4PY/5/Q7Bmw76DGS87lhiUjzLlxwrjEbO21gNlW4W9Q8g14dy3u1Y9wq8z/EE8oac xHsLudyz0ZLmTAKf/c5UjPOC3LLuzPDeYTltidxyi+VL6Gvgyx0h76hFcJwHt2edWd4lfgD1K5Zh 1wHBzasdg5DxkGMY+X7HKNqMOPcIhB9zFghyfggtHzQPOIu9me0nHBNoo2EaCPcyOnjvhFhT77ji vcI3Ib/GH3NcQ37Scd17nW9nY0bnXY5ZaK/LcYvllJ6074a9LdnWhSTLA8sdIZWfcu73lvHTznKs yA3MsmK55XggZFB7g91SudaxFne8yjCHFt6ZA6uj9U/4OafamwK9HRKy+CanxrPRPGR/KOQ0P+LP Cnv4206jUNC85qyH9u5Smr9H6eY1tCnmC5xNsE+snZDE33ceE/bza45WoZx/5Bj1LPNP4QsLzHdW rZzzpKDm15ztQrlV4ezyrGLGDKHYmuy0CUnWNKfb22bd6fRBopXmIUo74kA/4adhq13OYs/jljSs e1X7IKWtu5z93irrbudZ+NSScwC8FTiLwZvbOSQc4tWUtuY5iaCB5nnB2LLTOSJkWAvtq0K9tcQ5 JjRZD2AVFkBPCsesFWzMSueU1xCmYRvTsATa96S12nlDyBBpHaWbx5xznmXrYedtod1qct71ZlJ7 EIzWFibRcYywCK76QZ9y3ovQHc77iAzUzg2QCDTfT2nraUpb7Yz2QKIUqx/jdFkDsKLwunRZBOea YLOec06h/gLj9qLzkbfGesm5Bm6XnE9Bj9urvVesl12cZ4M/5lJ4NqyXnYTRyYyGd1iv8tOCGzFh QvBZZ1xpQr/1pmuncNY6j/EHLEvNc8KQdQGRpIZGMKGctRyhswhjvNy1S+hqHkMsykXcMAtd/H5w mA6psRZ8e5h27ca6LPLlwoB12TYsTMILYO0tOx1LwpRlkNqDtcSV5xWsq2E9o32N9aGoc/hgWP/M T2usj+m8zXcdSki94SoU5LY4V4nnsS0BbeZbdrp2C9O8u1sNa9lwn/eW2lLcg94Q6GFGjzI6Um9L cF3CSg2B82mL4KqAZyW5KhENzrgWIVES1tHQLbet+xK6kxy5vpT2E3QX6E51T/jSbdmuBV8mjbG+ bF7jWvCsdme4r2AdGQ3LROztznJf8+V257ive9u699gmfPnQ3qiviEZ+Xyn6lvnK+HbQSvSd9a53 FzjSfTTqtvpqrKuOdG8u6m/BBhadaz5Dd7H7jnfWluDIBA/7US/S4L/VO9t+oqdYMDavOVZ6C7uz evb7cm2zPeWw/PYeNeTqp3HMWtFzCPvLOqWbx1zV8GLMReOnSycU21JgOQ9t6diblvlp12Fvgi3d ZfIs2zJdLd4ayHvcO2HLdZ3yLNryXR3QEu86Lhiht9PelOYbLjuiSidaGuiuIdxoHnJ5WI1fOImW AWHOVuQ6503BmBeE27ZS10XhLotU92xl3f2eDZsSa1Fm9bvG6Q5lPQzOp22lwn1blesyWp7BuhfY ahxFwhpmvAofH3bNeNNtBtdN7HRjrnn4VKdrHFax6FoQHlkm6K6KPcjgPWM7ArrMZrbuhCWXWGaF p7DkFEShO5YzvRylexWY/TS0MeLI7E22tbqWe9P4ftdi705bun21dxfGae3djci52puHiIFICCsF n7bRHk1fF+Qt6rN1T/UY+9zd0z31fb7uGz1Nff3dcz3H+s523+452TfQfdcy3OvpvtfT3jfUfb+n q2+ke63H1jfWfM+dDTt51OPum+x+6szqm4Jfz+EOAfs1ZPH0+EDfov7eXd5zyLNq53r6fVcsgm1J sFH76a3A+p4VbHR9QT/qGeibtqz3DCE+POkZ6bthV/SM9bntyeBqzp4Grm7bd/ZIsb2r+UbPpFBA d4S+u+h7yDsBu8Vui7mmYFfToNdhV6CpXWG/eNQz7Z0I248tgdFsf+zOwm51y3q5p9x7RaId675c 6yq1Pau/5waNBpS2LIE2YJw5b659V8/tvnu8htKWOz23va3W0z13JftE3whtGeyZ7rtvLbHl961Z bmGPG7Lvdtf0Peo2Ou/1PbXn9dyDDdxAhFHbC3Hns2K7Y1sHh1g7P0fXzq+g3hGWorfQlm1f9a1T z2XaC3tHqtdgL+m5781EXFqBZ9U47/YWWmZdq70lthOOot4SSyfuoAy2NljCAcSfVvgL7gZ7K+A7 l6jNux6y/DHa8K6N3kpbG/Jq1r7a5kSu4yfdcb2H0f444mSSO4Hm8L4qm4DxTS3J7hRvPrUlrB2b i+a9LZYVPsvbZjtjG43kIUtn7/FwbnnAT/eesnS604U123l3Zm8Hy0+z3M78ZYjyLwyFLQ0zFmHG QXcuPHHYnU/jM7VM26i7qNdvm7DwyEdtht4An+ou7T3H8lM097barrTsFvphma1UUuddYYrPcpf1 XgAnzt6Ltmvwpku265Y71Kfcyt5x26ztWu9lPgP5uGXWneCtadntroI+oQ1hyuZ012CEHLcBcbgT nj6FXaZImKLrJexhHnfVMotVmKFxuHfGdg1t+q1+trITFkHo5+WY/Wb4rgyjHRH5mbfdcpuhPdyd 9i7Y7jSP9Y7TemHaxrtbexdb0lyXhC7bRPM0RujHLmmwLblP9C7z5e623lXbiruz96Gt1G0W7toe uHlob93t7H2MXOjdsAjuM4gSY+4QdodpRJsM2xPXuC+O7RFHmu9jjzB3l8MC862FuK82dKv5Eewd hxxxvlbsdCO+E/QO3NfWfgK73rzVj5o4ej/v62Q0z2gn309pumP6hJY02NhNWi+oLeugZ2hk853B Oub7zJTGHRSj+Uf0DNKtoXf7fLvrki+Ee/ui3hlrBc4LudZkyg/1Ed952x3wMNhtpPXd9ZH6YVY/ yugJSvfetF61bwiT9LwAS9CgfWZ3E9pcsWWjjYHJUsPoa4xOgcViBMuKfZevqPsY6OvdJ5uHfLOs /jqrv8XoO5TuPdfd7rrsW+ruci95l7rb3SuMfuCl+bpvpdvmfoLcCP/KZfvpOnaZS74HuNPI95Ux +jyjsxm9Tunem7y6h3gzca9YJqxF07YE6NDY7aaWbJ0Hz0+6fe7SPsLoYUbL0V6OfbyfP9uX1DzU I/c5u8+CTqX1fRndA7bSvqQP0VmsfQ5iZpI3n29qXuvbg3iV1FdgCTXf7yuOovczupzSvafA8/E+ NazU3NtCad8EpWlMlui+Q/T+BPeQOlj1buxrl3APMOQu69NYN+hJ0JbSk+oNNc91z/UZ+Zye1L56 3A+k0Pb8GNZoM83uE/gx7yzs5CG95+HH2I72sK+pu5gf6zvG6AJGn2xJs5XirqapJ6OvvXukJ8sb 6h7ryfHOdqf27MHdxWRPgbfVv+Bf9C/bL3kqvG32i54K/wV41jisFBFJmKSnSCGHRmyv0E3gTbZw bj/Qs+ZPtlf0PPKn2Ssdg/6d9uqep/5ddp2H8+8On5Hthx28P4+eNP2F9BTpL7GbPArcFYRPuOxs Gz7VRp9Yw2fV8CnV3uJJ3nxWDZ9G7cc9af4D9lOenf4Ke4dnl7/Sftqz219tt3vy/Dq7x5PnbQ2P Y/d7Cr1V9oCnxH+Yzus3sXnNdF5/i3iapmdnMz07+49TTvynGCfmZ5z4O8JShCMkPSn7T9Mzsv90 WC56csfI7HxN4xLrm+99QncQv53uIH4PrfH7qQ/6O+zn+LP+QHg0dvo22y94DvjP2cc9lb2L4acT 4ScG9su2df9FixP3Oav2q55q/yXxWQQ79dtnPDr/uP2m57D/cviZQ1hv4acK4fO7fdnT4b8pPrVg zwdEOvy8Ar18w/Z5j8mXbV/wtPTJ7ec8x/1X7YueU/6Zc4ety8JT+hcm9v5xEvX+cY69fzxOUa4w kK3sneOZ7J3jn2LvHM9RtCk6yV7FdxQ9pJi9T/zL7H3i1YmvJRYQTeL9xFVymL05/W32nvQGzPEF kkP+lBBSQb5OdhITsZAi4kLSEB/pI1pynvwF0ZNBpFoyTC4RI/khmSRvk2nyC3KULJK/J98i/4Os kvfII/I78ucyTraHOGRumYdckvXLfkH+o+yXsnvk13Gtcd8gv427EPc98ru4y3E/km2JuxH3c9m2 uJW4X8leinu0dYvsj7bmbP2M7NNyt/yy7DPyKfmPZAb5j+U/lhnlM/Kfyerk/y1eLmuM3xb/suzf xb8anyW7EP+p+O/IBrd9Z5ud27rNtc3Pbd/2/rYQ9/K2D7YNc5/c9oNt17nXt/182wKn2vbLbY+4 r277bUIa92/o39w4a2Jy4g7Olpia+DJnT/ybxBXOk3Qi6RzXn/Sb7Rz3k+2f3P5J7ufbX93+aW5+ +57te7i/3v657Z/j7uz45o5vcr8kMminlT1xzaJvdtUMASPAGDBJdmpGNGOaSc2UZlpzQzMH6rbm ruae5r5mTfNI81TLada0Cm2yNk27U7tLu1ubpy3UltB3brMVJoovK75MOEWlopLQX5xK5fK4PEK4 Eq6EyLhSrpRw3BvcG2QLV859mcRxak5N5Nxb3FskntNyWqLg9JyRbOPe5t4m2zkT10CS2fcbU7hv cN8gL3Hvcu9izPe4DvIJ9v3Gl6H1HJIh/5n8Z+QVyHSb3GWSsfffatqISdOm6dTwGqdG0JzRhDTn NYOaYc2oZkJzRXNNc10zq7mluaNZ0qxoHmjWNU80K1qilWuTtKnaDG2WNke7R1ugLdbu15Zr1dpD Wo3WiLocbb22SXtMe1Lbru3S2rRurU/bjz7PUk446TidgibpM2qSw0l7VjugHdKlaUeAVO2YdhJX p0BNa29o57RPtbe1d/Hpnva+dk37iP59Mv670Gb6Jmunv/FSRE7AdkvJt2H55czaD8LKL5G3YOc/ JIdg5b8gXyX3kaqZjr4W/+n4z5Ca+M/Gf5Zo41+Pf53o4j8Xn0/08QXxBaQ2vji+mBjjS+NLSV38 /vj95HC8Kl5Nvh5fF3+YvB1/JP4Iob8ydhb+RLWcTd9rDpshmilgGrgBzJH9moeax5oNbZw2QZui TUeeqc3W5mrztUWoK9WWaZXaKm2N1qA9gtwMtGpPaNu0nVoeyakVtGe0Ie157SDyYe2odgJ1V1B3 TXtdK2hWNYvaWc0i0gLoZeSLmquaGc1NzTx9S7TiW4p32dvUEzZp69tIReS/In2R/B1SMXz/78k+ soJUEl8dX02+FK+N15LSeHO8mfwJkSU93s5+T4zsoW+SP5oEwKoa1lFmAFmgnxCZmWz5wlF5wwpD UsMDBkqnNqwfzWh4wj5nmcnRHLOc1e8xJx0tMKeyenqd1kntpH4SXWzOiIxN62lfCjqWRNOxJXq/ OYuBXqclnUe6JqHcnMOuS/0oTeejpQQ15lOL8tC5D6HUgEdaxo73PJ6ieYvGi/rGgspqNO9hemky F0Rkl/iivNDrVD+SXtXPQT3mjAbtJ4HKIkHijeqM9qNjHsOckm6kuaPXkI4hyXjSXLxJj4fEkl6X 2kslvdZu3h/RrTQ2LbtEHihtM5ez0m1WR/QuldLc9DNdT6mUeKT6onxRGXzmQx/qL8kmlf1mzdGz ZuPRAXP9Jj6jZYnlVR2jB6nMiOKNyiPpL9YW6qPoaJuVizJI+qN10hhD5qZNc0hl0gvkl+RNipFf +kzth9JSP8zVkBCuiy0jbUbMx46OmU8efWoeM3HmyRfq5Xll1+95/ePa/SHz1Iv6lfScEbNeH1V2 PfvckBKW+0VlRC8xum5ID+vp48rIuqufU0bLEW37tJw0t0fixpS56+i02cZoqZRisuSfN8zuyLU5 s4/NS+1eite3zf1H75rPRnQmf2YbrLxnHojISNvfNw8dXUObR+aRiJ+LfUwK85Qp2TzNxpFsEqUp zXyDjmHaaZ6L2KtUirHOlGe+Z9plvs10mN94uaGo8WpDaeNMQ1njTRrXG5SN86yuqnGhoaZxkbUz ICbSeBm7xtBhQybGj62H/5suNOqY3R95Nkdkzc2Ny1SGiK4/zvbqY3w71qZi41VsXBJ1RHlqaG1c lWJIw4nGhw1tjY8bOhs3IrqS5oyNx5LdPG9/iqk37TbfZXqmKDTfN5WY16L3KdMB8yNThfmpqbKR 2zSWtM8CpupGhUnXmMzow41pbM+VII1jatzJypbGXabjjbtNpxrzmPwvgKmjsZBCsjvT6cYSVtob D0TvpSZPY4XJ31gZvfeYAo3VrDyHMaBHtr7Re3tO2A5MFxsPU3mZjJcaTabxxhbW73Lj8Wh9ma42 njLNNHaYbjaeNs032k0LjR7TYqPftNwYMK02njM9bLxgetx40bTReOlDsfB5e5+0p0TH4ReVsfYV O55UT/ex+ih7e17c73rO+FJMlO4PJD+RfF4eZUu0HbXFbHF/3v+sbMgNr7dURvBxcr4g1m6y5ehS 8pukGD+K3f+iYimTJ6qM7PsxMWlT+SJ+D8XoM2a+yF4Zu6/Glsei4l10Ka2JFK/3hPXdeaNzTvK3 Br4pjvpBg7MpoUFoSmmIaxxnONOUThG5D5fGk8am/IWaMiM+TOeJvj+W/E+6Nxb7s/iNfaLhfFN2 xO9pPfyO+l/0eA2DTbnPvfcWx20Ybsrf5IcxMUqKRQ2jTUWb7onoNRoTJ5pKj8qbyo4mNSkbrjRV MXpPU83RnCbD0f1NRxquNZnZZ1w/Wt7Uyq7jWsNsUyerRxtWimMwOqvpBGtzvamNzkVP8gqvopeQ xM+z38D7h8R/IPQ3oj/7L/ukZesW8jv2ROVt9kTlqHxK/mPZGfYsJcCepQywZylz7FnK37JnKX+3 7TsJaVw5e0Jymz0h+e/sCclfsyckf8uekPyKPiHZspM+IdmSS5+QbHmNPiHZUkCfkGz5PH1CsoV+ J+0CufjsOYIqgahVSlWVqkZlUB1RmVVFqlbVCVWbqhM5DzpB5VQJqjOqkOq8KkVVqhrElWHVqCqd pQngiioX+TWk66pZ1S3VHVX6V9yqJdWK6oFqXZWJ9ERN1HJ1kiqbpVxVPmahqZSNSD9lM5Shbakq lz4TUNTS76fFnHI7sC5/Tr6D8+0I0pfYibeU/IzM4Uw7j/Snsv8iu04OxM3G/ZyU0edXpIJ9B+9I lLy5ROKgFPOFJS8VZZck56NkPgOJqbwTkHMU6QpataquMR7N4PFl9n/EhOwm9HeIcpE4nKrp74Dn IcWRfPafxfTXruNxOi8h28BTBdlOlEjJBIohO0glUgqpQnqJHCJfBadfIzUkDZZnIOns94B3kjak T5IupExyGulVcgMpC7L/nPyxLFmWTD7Fvs/a9UxW3cyWQt1MZYnupm5et3DwiG5Rt6ycq/LplnWr uoe6x6jf0K3q4/QJynp9QmWePkWffrBUn4m67IOZqrzKwsoKfa4+XzmkL6K5KlmlOJipL9WXKYcO llYqVAq9Urd4sEpfpa/Rzehm9AbdAh1Vn4DxI0l/AuOwVJVTWaGc07fRUaSkUoSTck1/BD07D2Ya suhYoJ16QV91sBT0AsOC3qxvVc6B55s06RNYOqNbBX8JlG9wMV/VBKrq4BE9r1vU52K2kP687ubB TArlGsZZ1Q/qh3XzqjzdvH5UP6FbqCykI0TwWKVgQHt9HEaO019ho1/TX1fWVyr0CaowMJuIWf0t Oq40CxtRAnig0N9BuYxRAf0ZfRtNVBP6Jf1KlQ/afQB58tFuXf9Et2ogBrk0mj7OkETn3zQ3YEg1 ZOhToH1ICy5BSaA1rCdaMb7+ECwYBjbxvwmGAeWccsgwZBgxjBkmI/JG4Xn1tM4wpdrEfUQK1Bum 6SqHQXmgc0T4v1lZqM825MDGsg17YJVMMljzTUOBcs1QbNh/sMxQrls0qA2HDBrYxjKzU4XBqHts qEerJsOxg2Y9bzhJdQi9thu6qCYNNoMbtpMPy8UaGnyGflhHveGsvtToNArGM8aQ8bxx0DhsHDVO KNVGg75Tt2i8wlYTMxivGa9TGHzGK/qicA96zThrvMVsJ6LNsOb0ZyrT6Io/W1PdBmzrLPxuDXhK bct4x7jExl4xPjhYVlmibGe2GtKfoD2obioLVXlKNVJ97eXaqxLNkrp2BraTi/ImMA/55cqzNFV1 VXXVLtQu1i7XrtY+VOXVPoZ+1LUbxjhjQlV/Vb8xRc/rl5RDleO1yQczjenGTGO2Mbe2w5hvLGIz tKvyjKXwzmljGWwdcxiVlZUHUwztzJ8ws7HKWGPoh+7qK8crk40G4xGj2UCMrbrHxhN0lYxt+nwq SWUJVvCGYc5w23BXb4BU8EDDPeC+4a5hTZWnDxkeRfQVMjyt5WoVVPqDRyorJL3rlmuTw6U+vzat dmftrtrd1IukOv0DjEVq8yhqC2tLag/UVugeqpIjYL5tcNdWop36WVyIYENfShH2+9pqQFd7uLaE 2k6tqbaFxQGRZlZ0t7a69njtKUN7bYdBXXu61l7rqfXXBiTrRkRVou25sGfWXkB0raKgqxmOHbXJ tRdrL9WOVyrQogq2f/YbWTTaGtexDuvGJ8ZOI19H9GU0HoK/Vaz9AYP6YKs+G9GZyqbQlyqHwtGY rk+dXB8yltKV15di9uy6pLrUugzUZ9Xl1O2pK4B93zL46orr9teV6w116rpDdZo6Y119XZNSXXes 7mRde51at3rQjNVKoDEXMRvRqa6rzkZ1Qvmu6w9HSmrBWFVFnbvOx/bCRux7u/813EdB2hZygj09 T0dO3sCOC6S90YF0GsmO1ILkQfK/Mf9GAOkcUiHSBSQ/0kWkS0i0bhzpMtJVpMNIM0g337hJf0tU 8baiHnNsJV8hKuj1TXIQ9xVv4e5ATv4M2kuEnr9OPkFkSatJjxhH7K9eyiEie7MA5QjK4i1fUA4o 1xiGRFB6BBgTP08CU2L9NHBDrB8T68Zi+kn0nFhK9dMipqLoySj6togpsbwRdU3CXfH6ZNRYQ2Ip IVoeqZR4jB3veTxF8xaNF/WNBZX1njjn/SjZJb7GxOtzMfzGInb+sSgMRUHi7bbYb0qcU9LNdFS9 tIZjUTKuxehRKqej2kslvfYoSrfR1yQeaPk0XKq4KB6GYuYeEtdTKqN5nwyX9M7vQ/1HlJtkVCUD acDOGD6jZYnlNVYPsWXsnLFrEY1om5VkkPR3+9kYql0fMdfz5I/lIbaci1oHaX6pLrYU26h2A3nA KaDjI/Ty/0sp6VcqX7ReH1NG5P6YMlbHkp4+rtzkX7Hl9HP4l8YvVEZ8R1UCHBDpA1HtomxZVRHV pjI8PrN7MV6rqgFdlM6ibYOu/2HlJj9UmYAW4HiU3iVbOQ3YlRFfjPikR+TFr9wca0aUkVinugAE wrSaB5yAAJxRsriuDol154FBcW4aE+8/Zw0lGWLrMZc6Myxb9BzSdfVwWIZNMfDjbC023n5UvHpe XJoM86QefVavngCuANeidPWiOCTJ+rz9KaZedU7UM8VF4JJy0z6lGgcuA1djxrr9DKoZ4KZIz4fX JgJpnAWxXASWgVVR/hdA9TAMye5Uj8VyQ7lpL1XHAQnKTXFanSKW6aIeM6NklwBdqbPD8lIZ1blA vtivaLO+1KVAGaAEqoAawAAcAcxAK3ACaPs97CN6T/mouPz72ptUSr71or3nRWV0bIz29dhSWvMX lTdegI+b/+Ni7/P0F+s/z9v/P66MikXPLf+Q9Yke9wV75nPnf145HTV/lN4b05QRf1NfD/uBeha4 BXSKuBNG5H5V6i+NTW15SfnMhyeVm++PJf+T7o3F/jR+031CvfKMB+Z7CWH/ix5P/UD5/HtvcVz1 unKzH8bEKCkWqZ8oN98TTYf9+E3yTL435VF2IbZ7MynGTkR9v5nxTJeRdYv2AdomNXydfgsqMSFx O/sW1L+q5/YyH0ffFZIkSyZlhOyzAx7ADwSAc8AF4CJwSfw8DlwGroqfZ0TcFNvMAwtRWIxqswys Ag+Bx2L/DUJK4sL1JQn/BKQA6VHIBLLDfJTkAvniXEBJ0UeglJTtO7CvYl/lvup9un2H95n2tbCk i0rHI9SpfR37Tu+zi9c7AM8+/74A0jmW0zJMXRA/taBVh9j3IvpeQjq3bzwqXabf//zwd4AV5Yoa EqcwKAzkjxQdik6SrviOwkJeUVgVVpKpcChc5FX27d9d7Nu/n0t8LfF18vnEgsQCUpS4mrhKvph0 LeknpDjpp0k/JSXbX9qeTr60PWN7BnnjX3w+mSxVFv4m7SR5nZAi2FLR5RhcFaEQS9hNEWyraD4K sKsi2FXRsogZEati+TBqLNoWa1+0IeKyOLYEXCuc+Fi8XqQrOhyTTB+q+ej65yT6ThL2HW+i0Cj0 RMa+472Vfcc7gX3He7uiTfFtkqHgFTx0b1PYoXu3oofsSsxL3EuyE+8n/orsTppOmia521/e/jJ5 bfsr218he/7ZxpWRETL27K9B+X7yVuH5/HGaCgfzdYXDhaOFE4Wj7PMVWjJcA64Xzoqtxgtv0XqW 7rC6FaRbYjpPkzRi4RJGjIzH8mvhkaRx8nWsdhZtLtB+rP5KuAd9hsj107cocee5v0Jw/xH3E5LF /ZRbJp+Wvyd/j3yZxlBSkfjDxCnylcj7k/LF9yd9Hj3j0BMRkBvkJslW7jJG2claZ4pjy0g6o0V9 5OURGQWufUBzjC4jJeRAVIt0kvra7GuzeZl7h/eO5mXmZefl5lUhpeflv3YnrwgozSvLU7IxAvRb udz3uO+Bg+9z30fND7gfEI4b5UbJFu4vub8Ef/8JPG2FTDNEwaRJAH9/RRIT/zO4TIHHOWUz7Cle DXmJkL2I8nuVIqqi6GjUvKAePO2dIG/tTd3blZ+51/a5x3vdtNxj2tuer9zry8/d209p6fPruXvP 0jZ7M/YO0Lq9WXuHWLv0vSOsTdXegb05e8f+D3tnH19FdSb+c+bO3OQmuSFFxBQBAwQMIQkpIgLS kiJiREQbI0ZEDBAjYMQYXkxZimjRWkRKlVqK1LIBXUqpZWmKrEsrYqtUqVIXkCJFUEoVLKJSigi5 +zzfMyCB+6Nsd3/b/aOf+cx3nvucZ57znJc5c+bl3qtbtdW1e373Z9lHbLsXd1/bvVf3F4+vum/h 4eJUXdUna/vuG7q3L25zYpXYjq8Sm+a/N4zx2e7l3Q+E8tGiI8We5DeLvIbj5/UwrulhTI0nxbMQ 38XFOd0rux8S/e7u1cWZ3WuKWx0vf/5giaNf99e7D+i+lXKVSnmPy0O776AdH/ceNyY6OTrZ2Njw 2M3Gi90SqzTRWFWsyqTGqmO3mVhsXGycSY/dGbvTZMTqYhNNPDYldrdpcdZ92Nrl9jDtPUVmL6ZQ RsOiaeF6n6wPhuscWefJukDWRW4tHCbb5W578lq08jO5IOOzVT7bou3IVxc0yZLatVW33UX1eb0K UvOG5g0t6FHQo9uhglYi9c4bWthaPxe17NqqYEm33XmNsgwtml6YVphXpJZegac2YtW7a6u8Rtmj sWubrq26tiqaWVQu2i5dWxWmFeQUts2rLkgt7HhixWdhma7d9hb01rUwLa9XYVrRY8dXYju+EGNB gYuxsLXsV1JUrXLR9KKagj1FLbvt1kXj09hcXAVNknuWeM7SiMR7GI/413h6FA6ROGdJFHM17oJU V36xKyoaXphXWCS5yb4FXSRHkYsq5VPfwiJtJe9hT8Zo77ved03M+573PZMWuzF2o/SAkbGR0gPG xMZIDxgfm2AyY3fF7jLnpK9L/6VplX4w/aA5L/1Q+iGTnX44/bD5/H9pjLtW1mpZJzDK9eB7J8NN P/lUFo58PbCTGQEj16CT7HqwZ/4JO0/GIfIll/bkcoE+ZfAel37uSb/Wnm7o6T49PUpPT6Gnx+jp afT0dOnpU0wcj1oGQxkCytC5WdzLyfsidC5qa9aepHs1jPtku2eJ2praUJc8bv31ov9Oi2hbZGtb sI9hH8s+HvtE2CcV65g+gzk9N/yl4ynz/1kXntRFBS3o2qEnZdT3UoaHdeJ0nsmjFQc1s9M67MEv 1jvdZ62VvE7+59pQ466T/B4M47kY3bO8SzOpmS6PVqxspnuEVhxyQnd29ff3b+VkdWHNKrOBWUEb /Q+BzteeWK/uXCpLduehncs7DxdWyqfh6Kqhk0sltbRzjSyVnev4rHJpuEyXpbTzzHAtPcljVJZS 1uP+jns62U8NW02pJ/9q91nLEhsVGyVlro3JkRSbHNNec9bnJrOSFgyfceaOkHWJuTp3kSwl8KkT 20Unlqdyl5+QV8oi7LSi0+xOE3Q5yfIXnVawHv/sPC1n+5mH5Sc8OT+TctOcptMwWdd1Gt1pXe7q 3NXKTuv0yIjdGhv7t5awk1yPdPrIXN1pf6eDnY7kmtxobkZuS6Fus3Pb5+Yi5+cWC01ur9x+omuf OyC3VOShueUslWKZnVstS69w0X2iJzzW5NbB7Nx6sVFv0dDT9NBPZaeDkqaaKHvrOoCU4ZRwdGzS f+H84cm4Ksem/VJ4HPbSf8GwPWxvLbnNb6bNsx3NEtG2aqZtaaNmjnxuOllrjlrP1Mvnd5tp95iP zGj5/Hoz7UbztowD1qw5SavjSC/59NQJ3dmMDy29Bm+xWDzpPSWj4A+9H8qMerm3XPZc4a2QOlnt rTYpUifPm1Tvl1IzMe81b6OMH697/2Hi3mZvs2nhbfW2mixvm7fNfM7b6e0Un+9478iY8Wz6szJm /Fxm4+fKbPw56RPHa1vn9t+GD8PvwUfgPPgdLZH1bZrUXlZYokvQZVv9/dWjJ+vMdrU7UXNOd0Bs rNnUTLdfbPRcebJup9SxnitP1rlvhc5vpptu9FcrZzbTLTGrOKeerJtlGuTTiGa6Ktq7tJluBmem ns10rTg35ZzQfVY33+ZaTFvQMOpaRl0db2s4p9nY+JPq8FE0o+HIk2r14bBuVX87OerVm2c6yvnG 5dn7xHWdlWssZ6eskZqvN4GUK1fK8Y/1f2/Vo7jAK5ZjtIfXQ+Se3o1yXOq/tBRkdsu80RRKy2RJ ywz4u0f6f2WVI4V/8DH2Q/sXGW8/8VqYtMy0zHzTwXh+qgmko/+9Y/zH+o/1H+vfb/XM1cY95xpt xso1iD7b6iCzgJ+YTvy72IXmRZk75PGPYpfIbOttOTPulqWP+aMsffmPsUv5j7F+5pAsXzSHzSdy 1f2pLCXmmCxf5r/HBvDfY5fZqMz5BtpUGzOX23Sbbq7g38hK+TeyK/k3ssH2HHuOucqea881Q+x5 9jxzNf9PNpT/J7vGtrPtzLX8S9lX+JeyMtvJdjLX2c62sym3F9oLzfW2q+1qhtlZdpa5gX8sq7Dz 7Xxzo11gF5jhdqFdaG6yT9gnzAi7yC4yN9sG22BG2iV2ibnFPmWfMpV2qV1qRtlldpkZbZfb5WaM fdo+barsCrvC3GpX2pWm2jbaRnObXWVXmbH8I9o4++/23814+3P7c3O7fc4+Z2rs8/Z5cwf/lDbB /sr+ytzJ/6XV2l/bX5u77Cv2FVNnf2N/Yyba1+xrZhL/ozaZ/1Gbwv+o3W232q2m3m6z28xX+U+1 qfyn2j/xn2rT+E+1r8WviF9hpse/mRkz95y4e50dzmT66LwlOkSfbWauz9wimlMt+qpF+j+fweJS LBrOYNEPiyVnsPiiWrQoPcVC7z20CVfD3ZrTY21u0z9ptM1tSpLG29zmy0kjbm4zIEnMOjttj6Ur 12UnpbroT7cZ2NxGoj/d5vJTbBqS2Aw6xWZJEpsrmttI9FouvebQGS6/PC8ppUlr+lSrK9Uq842/ YjUYq61/xeoqrLb9FashxDzplBpvLdcCzrY1VlcnrfNTrYY2t5JyJLO65hSrrUmtrj3FaltSq6+c UveTuEptfcLOtVBZkuhPt7ouSfSnW5Unif50q+uTRH+61bAk0evxa6V/RWRtTz8z5oakveJ0u4qk /eJ0uxuT9ozT7YYn7RvZctVmuQ+XzT7G3JS03U+3G5G05U+3uzlp259uNzJp62efsLSh3S1JW/Z0 u8qkbXu63aikrXu63egk8fnYHbd0/WBMkviS2VUliS+Z3a1J4ktmV31afNakiW1V4o8m/KcZkyrr fSc+pcn13ufd/95wrd7srlvmIVmPmqszD2c2tfBlTWuR1aK1ULdt5XPHFnmyZLUoEvZs0Vf0JbKk iX5QiyEt2rJUhdu27Hfy0lrs0loUiZ/x4qNWtmrjh6k9ZZ3Soow0t7euZSx5LSqEFS30jsTxO+5n +1Qv05ZTwjopt8nqJWu/k9YBspbKOlTWclmHh3q123rKuiPc7g7lvbJWylota437/LkZ5uqMaVkZ WS2F2Vnts3Kz8mVpn1Wc1Stjmi5Z/bKK2Q4Qq1KxKc0amlUqn3NZ+mUNzxpOeqlbwr2Oe6zEY6Xz l1WtvvD0mZ8a+dQrKyM+QOTyeG5GVca8rHLhtIyq/7n792d5T/dt25q61+/WmnierEWy9gy3uvaV tSTcDgrT1G5IuJZJfU6Jt5dy3BfPjxfHe8X7yTIgXppxX8YUXUQewLafWOXL0j4+NF7OZ1lkWyq2 ml7ulnCvzzxWn+xPfYWejvspjrcXy/bqK6M248GMB+PD45WynZLx4N/4hOdv6rmZ0iMzpWdmSo/N lB6bKT02U3pspvTYTOmFmdILM2tCu5myzpJ1rqyPybpQ1gZZl4ZpT8taJ2t9uMrn4jXm6ti6eFm8 QjgyPl6WWlnGZ2bHp8XW6RK/Lz6Fba1YzRGbOfF58Tl81uWp+KL4ItLnuCXcq7nH8WKFP/WFp8/8 jJdP02StFXlB2vjYsti2+ALhutiy//Weq6PmEfPZPX6d5Uabao/tPr78lbuqam9pPb0Duj7B3VHu iMoIfKTy2LZmI3eGSTmy1VQl0T6YTHv4xbPUSima/vT/RSOl+HTi6TF8ui9ZZJ8+nkz7ye/OUnt6 7mJ3aEKyvf/iJ9MenHqW2qQ5HZ6XNM78ZNpDi85SK/V39IEk7f1s0vq79v9oL/j7arRmfpOsDo5e /t/pb4lzopmS1++VJuY/pzMtf5XMl36cMlC4GM6LyhHuPQ/3w22qj5yvcmQtmo3Ir8F8NN38F4QD 4ZWOqrdNyBuVdi/y83AK7Ots8JOBn/6qT3zofSianGC1sf4cf7nM8Ap8mc35f1LZfw793crgJn+Z yE0q26nKyFBSH0dzdfDvck3VEksL78DDOnxWwDiaqfj5Z2zS4DnKlMF4ewc6/w2RBi07/EFklnBz sFJrRjVeWfCyyLv9TsJnVGML/C7C7spIL+Quah9tGXr4kfAF1Xv3+O1Evjki8dg/+xeL/HP2elQZ TESuhgvhvyqjI/FzVBndSY4TVO9H0e/Fsgw5m7xykGdieamfR4TC4ENl5HWlj8a7C3lGZKvYPIDl SGxehsuV5nw7THsRjMFUu01acL/3M36rtlg0e+w64fbI+Rq5kbm53elpPTQpI+d7+8WyWGXvCeT7 I6XaH5D3w7dU4y2GG1Vj26E/rDRHInrlekTlSDXMJ3Wj30bL6/yo7C1Fvg1uw/Jl5MWwAnazcpb0 hhJPN9iXaH3kLkqzx1+hRN7lNBqD5K42/WEF+gPsexDNW8rEAb+H1OqQYIJwRdAoe91Oi0wm2mrk R5EblGIzgT4vlv6rSm8xe+WjaaOpkXexmRRqGunJjVpLWGag+boymIjcG/tH4DA8rEUer6kp52Hz COyKh0fx1qQ0CWLLUJpd+HyBmKe6fkU93+ZfJHIKfeyc4BaxuYS9+rgywlJl4m0dl7wnEq+KpnVC jnqP5/eRHJVtO1IXa6pXgbwZeSWchX1NqFf7g2iK4UDYsmmE9j21kVR9f4i3BrwueOjCXnvh3djw /oH0AKXPSPoC1P/ulONI30aQlh4nnIOf/U2rtOzYbE9ERa5VOSAXsVfLmU06MizW96vkSFA9T8z9 C5Anw6lYjvUfF8ub/LfFcpjXR2WvTGrpZ94M+DO4m9rYJdxNv4p7Mgp5lqOpDM6n113l79N5nv+O aL6vniM5+K9AfldpD6JZg2YmLFP6bdB3QbMKvgZvVwZ52HwXuRXyCuR6fK5DMwT7+bBWaY74S4Tr 4TeUNht5kVKiUnkX/AWatnibSySpoQfV4NkrRi6AG+Bq9PNgDZyBfiT7mjB3lYnTbIfL4IHQRvkY nA0nKBOVyFWwn/qJ9MQz7WWXkNdGSrqJehjkvCW2w7e1bhP/prWRWKHlgvuVoteRpFFpC9CsInUN HIh+Ltyp9IdgUwZzYAZ8F/vF2LyNz/XsdRBmw2nYzMK+FhvD/ZJB0CR+rbP7xOtG77WlIaumfeJT mTOsVU3TJrhK6bXlGJnLUZBK/1+PZiSaYuQCd9yRWoX8Q1LnwY3uSEc/DZsj7thE/gkzlt56vZG4 TCn5qtxGKT41hinwLjhBKeX9tfYlLYUcI2nIjB5aCq8Km9Vwbii7yPWqZjbcA1+Hi+AuchyLvN0w S9EjznxDfFg7OLxjpYwR80JKMTAsy2N63kGOw/5wN6XeizzLjSSwQu0jvHNrrwnrVu9mHUCzBE1L 5OudvfiQvJT2IJyrNEeQfwjXYdMFLkVTgByH/eFu9HuR18BZcL8yUkbqS3AavIZcDmDTF81guAT+ ADaRuhnWoCkn8nJqvlxbyg5Bvgb5Gm0jKbXrjdo/C6nV88OeYHj/RvsMbzr5A/D2U1gStoLOLhZg yT9m2w3wJfgDd6bA8lyO0AEwHV4Be3O8fx05ChkJzQUwKxyF9GgajOXPlMeuSkwn5gfhQjgeFsGf QT37BKF+EvyKUub+Kv8STldvnLPMscOkitz0RtAk+jejcs3d9EE0Xa8XlDJeLYOvKKPcGQ9n9Yfg PUTobPTN7nGhTDyRj5H1LqkJ3kd+Af17yK/Cf4bDmeOtQyZ+rYHE++rftCKXD5GNXwkpiy9lbHo7 RVrk2O6Uvhp5Sg2aGqItIV9GyOgHMBP+HG6BdVDHbZNyP+wLU9mXd5WjHZGPIN8Bp8HL4L16jASL 4PMyMg9L7Sl8Sem/o4z2UXrQN3Ai+mXKlIeVFnsPTSo2Ke2UxtnvI/V6uFwZQR/sQsaDvxnNr/G8 Hbk/cgA/h6YEeSr2k2ATeWXAHFI/wvIG5Bh0nm/CntRIOppPSS1C8wc07yH/CDmOfQtYDz34AaV4 Ak5A8yiswdt1kMj9auhK3Qq+gmY2rIR5sByOgJTRv51IXGyXUrpnIKmpLv6fknon8lrybYs8GBJ5 5G289UZzjzKNNorRXqlVEH1kIf7n4Kcb+kHop7PvU/jZAh9AQ/0HtIV3gH2zSX0SD1eS2ogH9EFP 5EXIFXAPLEZPD0ncpP1Q+Lxe68Fp9MxRej1o/yXaQvunHh3BS0r/HWW0j9KDvoET0S9TpjystNh7 aKSHz6eHz6dvz9ce6zyonNLOeVbZOG/7nE/VeNdjuVwZITXYhUwu/mY0vyb37cj9kQP4OTQlyFOx nwSbiDMD5pD6EZY3IMeg83wT9qRG0tF8SmoRmj+geQ/5R8hx7FvAeuhBxhnvCTgBzaOwBm/XQSL3 q6ErdSv4CprZsBLmwXI4AlJG/3YicbFdSumegaSmuvh/SuqdyGvJty3yYEjkEcZDvzeae1yb0nbb 4WaljEvzGYXmMy7Np5/P135OXlWQfSML8TCHvLqhN84eeRA208nrKfLdAh9AQ3sFtJ13AD/ZpD6J tytJbcQD+qAn8iLkCrgHFqOnXyVu0tlv4vqE9PYE39LwftR0tfAdeJcy0lZpoWdgH/TXwxeVBnuL xscmMge9s59Maj4cBmegP4CMB2883M2+E5B/gOzBVDSLkL+I3Bfeg+YBOBd+FfrQ+fwxRG/vRz5G 6nloPkJzEHkzMt68FNgPWng3NtfAS9BcCXvhrSu8AM1F0JU3Dd6KZhAshq1gEcyBF2P5Xfh9vL0J KbUfYPM7Up9B3klqJvKT8Bukfojs2us5ZeDahTbye8D+WL6Kh5fgueg7oWcv7z/g7fAy+Cz8OTb1 7DUbTRlyLvI2Up1+AfJGnSNJvxpBv1Iuh30gMyjj9B8rpReNoL+pZj7yn7HJSxzSOy3MMFfRVw8z zxwGo5C5fYQ344NlaNz3lvag4SogwnvuAd/D8vnmgd8Gby/CNU21eg+EvZ5s0vfdX0dTq7Q7makO RsO3KSI9VU7hCst2hO46ogL7TPKqx9vrWooUrssCd72Q7a6z1NIbqAz6Kf0oXIH+sNI0uvswTaU6 w1d692tskdfc/QryGgtL8MMbRjYTP1uxedddzVGf5crIckqxib2e1nsgEXfFx/v9PqOBHH2a+g7x N9Ii+/E/HA36KKWQ+pHUYL3SHwIXyvWoXKeQ4xL89yTfBuwzyD0Dn1OcB72HIyektXrFp5SyK1vC NXAGnAKLQ/0mals5D81S5BnUXhdYA/dzn6eGSPiehB/e3WqaqdfFqpfcG2gp9fCi0hwJS6GtcCD0 s4k+sIma3EStuhxVsyG038QotwnPrrfXYtmA3EDpVJ9K/exUS/+L7goID1Xw+3C966XhcdFAbxlB u7vWrKUeqH96VyNtVE/rZyE/hIdfuutT7PvSsnM5stZT9mxYR88ZS1vUse8g139cPwmPoJjID+i+ Ue4eBLM1NcpTDG+0+vHfJ5dt5Pswsc1WxuiNqR8pU7jPEF0dephK6whTuPqOjlQ5MOiXUnsvO5/k 9YQ7rtGk6p09u1fpz3T9ijjXUqIS/TZswP0N7067XfTtsJlPibKRR9C+RyjvdjQNaB7D/240ZdTn dDgetoFDSF2F5VLuIm7Bs48Haib4DUfEDDfiERvjQKQTUd3Fs5VZcDFPW3KQN/P8pSPyp3AKqWUw Bc1SeFe0nbADT206oOmC3BIPc9EMVJp9cJezQd6Ot2r3xAcW8zxoCTwHDwfRvwXnhU+jdB6ymWdP OcqgFT7nhbM7tVkTztkG6j0NZsIdQw7U2mYekhP6UV4ZLde+R44+3oqJbSb51sBU1fhD0K8iwgL0 S/F80NUGnr8E8yFzOe88UhfAS9hrFvqS4AM9K6H/RcpoHU+4CmaO5FWgv5gcu5JLHZoaai+BPAPL bTCupfDc87IIZfmta1+9mva64YeZcKQ79muoqxeRh5JaitwWmTmttJT6/Bj5n1yt4vlC4sl2sntO R+Svk+Nu2JKSrsRmGvJ+POwn323uWSGa97BfifyWK5d76hckNM6w1z2k8ejVfaSPypGZeC7A8jA2 jyJXkNdiV89Rfa+khNSppA6l7TaQGsfDTiej/4R7HfuQR7o+r3LkdpiCfp0jrXAA+U3kx+Ae1+eD +zR+lYNl8NuuP8tZS8Y0bNpSt2vI/Qk0rcInpNM4aoSW6zLxiRw+ex2jvTHsk2o5hXq7n9TryOVp NBshVzTeQHgX/X8fxw7XWZERrq0pxb3sey/yB8gfOJl9I+T4HpEchHO5dqC3pxB/dLAyhf4ZrCee HytT/5XU76DvB7mqitS6OsEPkaRQG9Gx1DbXEXaaG0nIvQuRjHae8TCb+Ge78SFaT/3U008eYnRS uSzaWzx8D5s+gY7Y9wcZjDn79VpPbcw7Kku788wRDoLc+/KKSN1O39hFnaxWP94PwvGtvR4j0bvV fzgStmcEU/38IFVnkuT1NmPICjidct1N/C9TP5noGW8DAwvRfBebBurkNaXfRhkcQbMDTTrsjeZ8 ONn10uBjkf+E5l34IZZD9D6b9MMS4qkn3xLG0hJyF6Zwdgjqyf1dbIYoxUblNtTtLLhG7WWsqGdf ZRUsVEYaOGbfha8FnGsCd3TTn+EapZ+LzQ7kdGV0SUBvUaY8Qw85j7JfTwyv4n9y4OIkqsAdZZr7 IFJX4fMT5E+oT0ZF36Mefoz+ZUrR1tlT3qOBO2bredapEW7Ez6PIFdTq+Uq/N9EOI3UTey1y5zV3 vgijLaH165FVfwV5HXWjpfMf1qTm+HXkvvg8Sqv9CZtummPKt/CznXwn0XO24PPr5PULct8BOe78 hbArrXkJ9huQ81wvcjI2v3d+4CNYUmPBfcj0dqnVVrS+anqh4RiMPo08EZ9VyGnwBVJvZK9h1PlF 8G3K9X2Ol7ZousLfwysYB0qQLXImnjkGvdvgMTysdX7ckYWcw16HkOez1yB3LlCm3I83xvmUGheP G6Wx/Daa95EZjaW2NZUzQgpnpeAXeG4ILqQ/X8jZ6jra60J674X09gs57h7Re1nkyFkyWo58OXI2 eb1K5M/B9/G/iGhfdLLzA9eS121Y9uaImwVrwv5fQuvocX2PekgbrnLsEZVTe0KPfJlFxIo4mnjT JmAmlrIYD9fSV9sgLwvHB6UNe74wbSL2vO3j3xr2bWU0cH2shKND5avQX0EuPVSOMnpHR1PDY+jt 6/X5ReT3wSZhHXUy0f+SyOn+Uu3h/iyxZLZpX1JZjohZei8OjlDakbRIP93Ln6i1JD22t94D9PWK oE41drPm4jOe++78wmh/bGj4dOZeYQvkFuFzmV6Q5yaJr8MaeC33l/Yhz9ZnHGqfOJTYhOYRPZur H+8uZaQ18iy4Bk0f5M1K2xFuQFNBahnMQTMPOQN5P5wCl6J/DXkx/B4shl3gQDzHnObY7/TsRunq kXfhoZrU/qqRqxi1Hwmb0L+FvFNTPRfDZpX9i5A3kloAs/F8BH3qsW06J0TOI5cRyDVYHsRbXxch 3oZgswoNZTfbnSWaOPaz8LlTGUlxMbuyq8Yrg2uUZg8eXiB1pWuFY0u1XHAumtvw/yZ7dcFnDv7v hpfDdfi5Cpv9sD/+f4K8GZsC5HhYLpWL0XdEnoHnmfh5w9WMa2VSV3Kldg7209AfRv88tVHrWsH5 ITUCh6K50smudcKaVD9vai+1v1VKT9AeewT9J+zVFvlG9iontlLyKkV2ddgNm8HYzKW8+1wZkR+D B7AZCb9A7i0TuUos+4aRqL4bflYrg28r/U81VeRcHU/QtHGxuWOk6UvaIvBid7wgFyttO7y1U9ns UkZak9oNOSfxbW0XroUj6J+AS12NOaKZAfu6VNgWzoMrsXyFOvmS6+cuHrgfjoZvYdnS9TQ0NcT2 Btzn7v/g5wZ3FGDzItzIvtso12A4En5AGf+AzTN4/hb6nXCsGwGQx9B/emE5xXmDEdfi1MlrLk54 G3s1Iaci15HXFvrnHt0rtafKKRzX0XJYQttdr6kpjGnRC1X236cd21OuqUR1HX2jCktGuajz77s+ 4yI/NoWeo1znYnYjA/eaItzRmo3P2Rz1T2g/kfEzl/6cy+iXqyOVG5FgH8au+/HTl/GEMc28g2aQ GxWxiblxTxmpduMh+ib4JvwtPgc25QsNchGW9UT7A3esUYcfcy+0D+T5vjef8v7ZlZo3TCr93RLP FH+oyvT257l+qeSO9/M8N+zm7o7qVaFc5c3lqlblRTzL3sNT7EUp+sZgo1JSS6Ba8pQqUhbezejC nYe2etSo7G1DUxt6foCZrciROUqZJ+s9gf08Tz8S2cQcoKPOCiLv6r1ifwjn9Ae0vQLuyuqTfW8b bzis4628VSaPUbq3jifwaThYGSlrmo+slu+qHNnk7gGqxo/qvpJTnl4HKb01SnNEKZGp/lb0+5Up 3DsN6nmProx7bgX6voQ4Kodz4RbuKem7AXv0Xoo5kLJR9fqGgKTuRV4KO2he0dXIek4/EL0Re87v 0Z1cy6+m5tEEcpY3PdzbBViagN+5471Hg6XRd/OMSXkCTTmp65G1/tcTz/qU3crUqXCmtmnqCO7+ NXD25A0KRg/T1BPWwgzmFW2wnMmorlejXKHYHkFE5I+DZcjaIjn+UT0D8o7fx9ic5/M+arSHcGug v5GzV+dCpr2vM5xCUs/3uwt7+foeRX9/ACX6AlSblv4MZN6y8C+V2c5f/FzkITAP9oaXU+pieC71 cAP04bOy72p981Dkz2P/JlRNIWUxvr730hjluIONKeq/HjZGkWFjSn/0/ZH7IffD5pvYfBP5IWS9 G9CGPtwmGAD/rIwugj6aQVBL3Rj8VvuD/zryq/jR+eGBYA7ydjgNlqC/gxgq6EuL2Yuogi9L/T+h b8sIv6MMboSrlLqvsCOaRci/MHr/87vK4DtQLZdguUSPWZE19zcCfavnjeg19PabkTWSN+ilK6Ib hM8r7TXBJ1KufH0Dx8vH5371IPJDcI4yGkCeHlIb+Sme8DH/Cj3W/O8rg68hf4o8G65XRoei3wz3 sZfOQ8bqG0HCf1MG12Kpubfxj1AbOidvE72ZsuuvLO0g8r2au+g7wOtJ1behdnD8FvjP0C6l5P4d ah5Gx0If/c/Qf4UcRe/d4w8mNR39O8h5MAPNN+AF8AXadAN9RseHvcHdSn2LSWRtzae17F48uExn bv5PdYaj9OLRO/UMwj3nacGTqofTgiHIQ5C/hvw15EeRH2Xf1To/IceC4C24mAifgx9Qlln0sQ5E +AF63Wuo/wZ94xzhTzQq0T/MaDYCag1fE3lFZ5v6fpdd4PdRBpcI3wuqlbTye9HZUHvaeykFyDfT h2X0Nn+M6m8U7/VHqRxo63QMKvXsoN9osB2jF3Om0GNtL8fIH6PDRJNGvoP8F+H7Wqt6TEk7Zuvc w3+P+H34ojK4FV4IH1ZGu5K6D01vPYNEXarT3wHvpESdhbP1is8uiOibM7MjdyBvQX4AGY3/JJrf o9mP/Bv4mtLTVn4v8hPxPMr7BvWjd+ZHRToiX4r8eeQvIp8v8jitB9MY+Sn9RMfwo0b77V4zG/Ie IL85FzM/gpPR6BnkgHlE68TcpXJCx8lGeCCRjZyNjaTa/ISOJA3mYuSFKifWI38TBnAwfBA+iZ9P 4K2wUsn55YBevYrcAZ6LJop8HXJvWAiHoNfvtu5tamn0WvVb8BOo7VLB88GKppvhfPR6pn6IaEfC hzRHYVfVwJd4UllF6mS4QGMTvb6lPy+Rx8z8Ofg75up/lLlB34Sex5do7naJ7iWz9D/BDlzX3Mt1 zVJ4zOhVktbAjmM6Q9irFD9/0n3ZKwU/BWEtaVQFWgo71jGRRaqyrkmf18QpdQ32u5p03CvRtzSF W+Gv8NyBCLOQa/FZS743oxH6RepBru41958khht9u0NrL5KYynx4FrLO1bdgs4XY3ms6KPneS0vd 25QQXu5aLbFDUm/Bsov+NonUuea+IKFv0nYhdVDi99qjmr5K6XKo7X14lrO/Xd/0L3qEqr2pb9Jj dguaAwnOcaoROQe5FKqHHzdpn/zxMRmv7C73vD6hz1z26nwmscjXN10/9XUeeySoF73P+5mP8/by EXOL2MzmvLlLR3iZv7mxegF5yfna/Jv2PTmuX+EYfwo5wlG8g2P2Q/SXY9+dqP6F3vUrRrwXwvd/ 02ylzOuCUXWjRpucMV+tqzFTb6u79XazaOyto+vM+ppRkyaYLVJf3qAvl+WYvOvLBubov1wkEnKk BqJPNR1MrulhBpoL9bvJ6KPmc8KOprO5yFwu89Q26NNMimkp7GS6mO6mpxlkuprz9V8RSc00rUxb ky99tq/pz+/TXiHjxDBzk6k0t56wamHONe1MuukmI8alEoe+0VRqyswNZoQZZapP2HnmHJOhUQ8p L80xPcvLrsoxw0MPrU17EzcF5hLTz3yZ3zm50lxnKszNZrS5DZssc565QCIqNMWmt/miGWCuMREz 2JSbG81IM8aMDa2yTY74KzJfMH3Ml8xl5lrJ/ypzveR0i6ky48z4MT0mjvGmwwfhI3AhfGrMqJpJ 3gq4Cq4ZM+aOWm8d3AC3wJ1wL/wIHlVGolU1426LZMFsmAPzqibceUekCPaEfWEJHFQ9bsKoyBBY Biuq60aNiYyEY2EdnAYfGDdh3KTIXPgYXDhu4p01kQa4FD4t2Y6KNMK1cEPNhMl3RLbCHXA33AsP 1Nw5piZyCB5V+t4dt1aN81NhJmwlhnV+G5gDu8AC2ONO2fi9YQkshdfCilplJayGNbAO1tdJiP50 OBPOmij178+Fj8GFsAEunXjHmFr/abgaroMb4JaJE4u/4O+Ee+D78CN4WNjDb1IGPkyDWbC18KKg LewI82AR7DlJog36wgFwMCyDwydPGDcmGA3HwglwEtRvWEXk2OvK74yfrXT8l5A+Y0SO5hS+p5Fc Ujt9gcKTvh800ySTPBkBzkmytXJcKz9/RqafQv0VnvP4BZSzlayJn8a0U+jLMZ0lI9g5Z5CtyT0j 3fd7XLnbw4zT2OYM9GT86XAWW2s6npGZp/H8MzAiI3YXGcfPXjqzP2vanZFtz0BPxtZOZ7E9Ux69 TZ2Zau4zs2QeucA0mGVmh9kjM8bD1thUm2WzbY7Ns8V2qK2wo+14W2en2vvsLPuIXWAb7DK70j5r 19mX7et2m33b7rUf2SOe56V5Lb02Xkcv3+vh9fUGeIO9Mm+4N9ob79WZqH7tw0vlPKT/PMI2lSt8 Y2NLjEo2tszovMSmV7nP6S/L55g5L+OXGVsy9sZNvGW8S7xfvDxeHZ8anxtfGn82/mp8d/xoZmZm x8zemddmjs6ckqkzVP09oEZ8eZmvZurdmZixLVqH21y3PbeL235+gOQm23Yj3bb9Ipd7+1+Gn5vw lHFBwQUlF6y9YHtOfc4jHQo6DOuY07G8U89O1S6f3La5+UTr5fbLLXMecme48uXONbzzmftY+PnZ cLsl3H7ktp0zw+18t+0S2nVtDLfHP4f7dQ33yw/3y88Pt4PC7ehw+6rbditw26KMcFsfbiVd2+cL T7m4v7DO1UyPHP3Ov2zD8vTYEW4/ctuL/pO9846P2tj6/hnJo11szQgwGGyMwQaMAWPWBTCmN2M6 AUIP1RTT7BhTQghg02voIVTTu+m9hwChmt4JPRBKqAkd3qOzYq/JTW5y3+dz7/PPs/NZaTQajUZn zu+r0axWCrDmday5tT6is3O7iBnOciLSnPuJOGgpH68HaPQOsL+iYFot7K8AW8vWgmKLskXRk7D+ y++O4p3NXhsLUCLUaLcmqLQo7N3UwB5UM+z9dLb0MhzGwVRIhcWwCjbADtgHR7EP+CPchPvwDN4w N6bbNoBqW25bYdtI8zTbJpqvtG2m+SrbFpyvwNhWmq+wbaN5mm07zVfadtB8lW0n2mKFbRcupWHu 3TRfYfuO5mm2PTRfafue5qtsezF3mm0fLq3E3PtpvsL2A83TbAdovtJ2kOarbIcw90rbYVxahbmP 0HyF7SjN02zpNF9pO0bzVbbjmHvV7yxivk+8Dwz8WxY5QUe+3HbSsswpyzKnLcucsSxzFvez3HbO ss95yy4XLLtctOxyybLIZcsiP1oWuWJZ5KplkWtkkeuWRW5YFrlpWeSWZZGfLIvcJovcsSzys2WR u5ZF7lkWuW9Z5MFfWGQKzIKFkPanFvnFsshDyyKPLIs8tizyxLLIU7LIM8siv1oe85tlmeeWZV5Y lnlJHvPKss9ryz5vLLu8tezyzrLIe6dF8IRMFrEzp0XsitMidtW0CBKaLGLnTovYNadF7DanRex2 p0Xsmf4Ni3wPh+EUXEKL3IUn8IopzN3u7rSI3cNpEbvutIhdOC1il06L2A3TIvbMTovYszgtYs/q tIjd02kRezanRezZTYvYvZwWsedwWsSe0+kxdm+nZew+TsvYc5keY/d12see27KPn2WfPJZdCphH as9r2cXfskuAZZd8ll3yO+3yb1vkvssigZZFCloWCbIsUsiySGHLIkXIIsGWRYpaFgmxLFLMsojD skgoWSTMski4ZZEIyyLFLYuUsCxSkiwSaVmklGWRKMsipS2PKWNZpix5TDnLMuUty1SwLFPRaRnz zGDW2zwPsAlIeh26m39/xHOCL/adHGivKnjt2UQ/iaSvbP/EbYJ+yopN1E9TrD6mnbFiE/WzGKtK +c5ZsYn6eYqZ+S5YsYn0LpT8eE0aie1RC6+fWyPVk6A/DNcvuvZ0ybWny649/eja0xXXnq669nTN tafrH/ak38NYNXtlTLtvxSbqDyhWFdN+sWL/qkY3XDW66arRLVeNfnLV6LarRndcNfrZVaO7rho9 dNXokatGj101euKqEWqfhbAQ7ET6KD7YT8un5APzDSx2YCKC+lVJ2GqT8Krjn+qM/cj56M2b4AT6 8Qv0YJ15YS+yMItg5VgMM0ei3Ty+A4XeuODmsccV+/5DTDmCsakUO+qKpbtix1yx4xRTsE+lKyfM uHIDp1No3UlXrlOu2GmKqXgUErIpZ2gLsyZjFLMWkynP2Qx5vBSzTlOUvaBizinKOVdJ512xC67Y RVfskit22RX70RW74opdpZjNGicJRA8oAWUUPEcrM3F/B2ivM5X9mGumgmdsZRYuH6TUWcoPmDpL ueYq67plC5syVhmH7ZaqLMSci5Xl4K6kKWlgKKuU1ZBZWausg6zKBmULXruqdJWQDbXG6JnGAMHg fBfhHFyxTFmGZa7D/KqyXdmOPTr0AGUSPVfOfMec6Q9If7qmNcesVGWaMg1yKzOUGeCHZeyEPPSc uPL0nDiz/Cd4TeqLR1kBOdgCuiMB58JyPCfecbahmhXLfy6agsJLWSnVKKU5peBRipYYi7LWVad1 TTLkrkEpzVy5P6PcnN6JmBOvMvPTNs9oP49FY1xbmrb5lfbzhLZpQVtn2Mbcg/LMrBVu08zMbdZH eWLmVF4492zuSfnNrJ3ylEppbNaE7PXY/McXL8VLo0eZY494DcLon134LUpvWrnLzF73qQxpqvls boZ9fLYrQypjB/G79KNt05j5u8/Uj7adhmE+pg7OkOrGBlMYi+ndPyrTvBu70UdlNjPfncqqfFRm NAbzVxnHR2U6KGDLMp+PygzBr/JRmRrzBeuJEx/KRG94wszf7S5lLBOXzGC2xb6MZYJ57ZaWsUxY Q+/umvFRmbMwmNdGwz8qczgFtAkkflTmBDCfwpOxzJZgXqnFfFRmDQzmb/kRH5UZQcF8OpWfK/3D M69V5aWKx6+6qzq4a0O1YfQky4+f0O18BrfzubbOZ21/eBY49ni0YdpQxRyjVVUSKZbkbo73Y3kK 1dy8Yg229htCNXfQc9Z9XGlmmfP+Tl3keec+1Z+13KpJfqbl0WgEhY2GPepdNY8apBZRQ9QwtYSa og5Wh6jD1ZHqWPVrdZI6Wf1WnaXOVReqS9Rl6gp1pbpaXa9uVreru9W96kH1qHpcPa2eVy+r19Rb WNZ99YH6SH3Cg3gwL8vL84q8Mq/Co3l1XoPX4fV5I96Mt+RteUfehcfzHrw3/5L35wN5Ch/Mh/Lh fCQfzcfycXwCn8Sn8Kl8Gp/BZ/FUPp8v5sv5Kr6Ob+Rb+Fa+k+/h+/khns6P81P8HL/Ir/Ab/A6/ zx/xZ/wFf83fa6pm0zw0Q8uieWo5NB/ND487r+avBWj5tUAtSCusBWshmkML14prkVpprbxWUaus tdBaa+21Hh5rPNZ5bNAVXdPddaln1b10Hz2Pnk8P1IP0wnqwHqoX10vpZfQKelW9ul5br6c31Jvo LfTWeqzeVV6VN+UdeV/+Ip/IZ/I3+Uq+MxTDzdAMu+FuSCOr4WUEGcGGw4gwIo0y2Co7VbtqdtHz qHnQEwqqBUHBVimC7VZULQpuaqgaClwtrhYHTU1Wk8GmDlIHgR1bawhkUoepw8BdHaGOAA91jDoG Wfm1+jUIdSK2uMRWnAwGtuS3kFmdqc6ELOocdQ5kVReoC8ATW3YJZMPWXQbZsYVXgBe28krIgS29 GnJia68Hb2zxzeCDrb4dcmHL7wZfbP29kFs9oB4AP/WIegTyoCcch7zoDafBHz3iPASgV1yGfOgZ 15DMt9RbUED9Wf0ZAtV76j0oiJ7yAILUh+pDKKQ+Vh9DYfSaICiCnhMMwbwMLwNFeTleDkJ4BV4B ivFKvBI40JuqQCh6VDSE8RgeA+HoWTUgAr2rDhRHD6sPJdDLGkFJ9LRmEIne1hJKoce1hSjegXeA 0rwz7wxleHfeHcryRJ4I5Xgv3gvK8768L1RAb+wPFdEjB0Il9MoUqIyeORiqoHcOharoocMhGr10 JFRDTx0NMeitY6E6euw4qIFeOwFqoudOglrovVOgNnrwVKiDXjwN6qInz4B66M2z4BP06FSoj149 HxqgZy+Ghujdy+FT9PBV0Ai9fB005hv4Bmhiejs0RX/fCc3R5/dAC/T7/fAZ+v4haIn+nw6tUAPH oTU/yU9CG36Wn4W2qIeL0A41cQViURc3oD2/zW9DB36P34OO/CF/CJ34U/4U4vhz/hw6o15eQxf+ nr+HrqgbFbqhdmzQHfXjAfGoIQMSUEdZ4HPUkickop5yQA/NW/OGJC23lht6orYCoJf5Sjnoi+oK hC9RYUHQD1VWGL5CpQVDf1RbCAxAxTlgoBamhUGyFqFFQAqqLxIGaVFaFAzWymnlYIhWQasAQ7VK WiUYhopsAcNRla1hhBarxcJILVFLhFEeqz1Ww2iPtR5rYYzHeo/1MBbVqsDXqFgNxqFq3WE8KlfC BFRvVpiICvaCSahiH5is++l+MEUP0APgG1R0IExFVQfBt6jswjAN1R0M03WH7oAZeoQeATP1SD0S ZqHay8BsVHwFSNWr6FVgjh6jx8BcvZZeC+YhAerBfKRAQ1iAJGgCC5EGLWAREqE1LEYqxMISvave FZbKK/IKLJM35A1YLm/L27BC3pP3IE0+kA9gpXwsH8Mq+VQ+hdXyV/krrJEv5UtYK9/Kt7DOYAaD 9YZqqLDB4AaHjYbNsMEmI5ORCTYbwhCwxchiZIGtRnYjO2wzChoFYbtRxCgCO4xiRjHYaYQb4bDL KGmUhN1GaaM0YA+ZSRis+quFVIcaoT5VR6nj1W/U6epsdZ66SF2rblS3qjuJ+IfVY+op9Zx6Ub2q 3lBvI+/v80LqU16IF1FH8Vq8Hm/Im/AWvDWP5Z14V57Ak3gf3o/P5Qv5Up7G16Bvb+ZF+A7+Hd/H D/Kj6imcn+EX+GV+jd/id/kv/An/jb/i7zRF0zR3Tai3eS0tuxqg5dK6aiV4Q4y11NpqHfk1j026 m27XdT2znk3PqfvqefX8eogerpfUS+vl9cp6Nb2mXlevrzfSm+kt9bZ6B727vC5/knflI/lCvjHA 0I3MRjYjp1HYCDHCjBJGlFEOWTyIKAxEYUb8VYi/KvHXjTjLibAasdVGbLUTWzMRW92JrR7EUJ0Y KoihkhhqEEMzE0OzEEOzEkM9iaHZiKHZiaFexNAcxNCcxFBvYqgPMTQX0dOX6Jmb6OlH9MxDZMxL ZPQnMgYQGfMRGfMTGQsQGQOJjAWJjEFExkJExsJExiJExmAiY1FiVggxqxgxy0HMCiVmhRGzwolZ EcSs4sSsksSsSGJWKWJWFDGrNDGrDDGrLDGrHDGrPDGrAjGrIjGrEjGrMjGrCjGrKjErmphVjZgV Q8yqTsyqQcyqScyqRcyqTcyqQ8yqS8yqh7TKA58QfeoTdxoQdxoSaz4l1jQi1jQm1jQhvjQlvjQj vjQnvrQgvnxGfGlJfGlFfGlNfGlDfGlLNGlHNIklmrQnmnQgmnQkmnQimsQRTToTTboQTboSTboR TboTTeKJJglEk8+JJolEkx5EkySiSU/iSC9iR29iRx9ixxfEiL7EiC+JEf2IEV8RI/oTIwYQIwYS I5KJESnEiEEZGFFMDf+XjDikpqsn1bPIiCvECPRUixGF/zYjNvHCfDvfzffyA/yIehLnp/l5ixE/ 8wf8Mf+Vv+RvNaZxLZOLEf7IiC7ECH9iRAdkxMY/ZESYXkKP0svplfRovYZe53eMuCZvyZ/lQ/lc vpbvDQ/DMDyNHEYho6gRahQ3Shll/48R/8eI/2PEPzHCfNqMOQLUHXbBQTgFP8IdvNJ/wzSWGdzp HanmG1JD8Lo6CswnYNRSf0XVpKjPcTpYfYnT4eprnI7VhoPCy2p9cFpe64vTilo/nFY2vEGRT4xc OH32JyX+RiW+oBJfUYlvqMQRVOIXVOKXVOJXVKIPlehLJTJw0/qbuSk2wBUb6Iolu2IprtggV2yw KzaEYjR2pD814/qzDylIxasA/C1/BwryS8HcXNNAQ465gx3504GeZmmOANiphKweh5EkY8zt1Lv/ iGvmXclMNe/nNUfM3CE/5c6MOdxced2snOYaqQ5AOmG6c07bK2ZZOA+hEnLSOO0R3OopXv9fdm4l v3Pmds7Vu7TVCtzKHLhwg8LgwK9592oZACvNbBcv6/4LgGJUzxs0nUfTJViydI6cqVnVrEjFampN yMTDeQRIHslLQ2atqlYTsml1tAaQS2ukNQZ/ranWHPJ5LPZYCYEer3WAENFYtIQII8AIhDJGeaM8 VKT92y1fiIJaUB+/5h2Era262c0RP6yvH9a6BH7LWHV0UL1m0/QyjX+rFL9C07F0zHfJjv+5etvM 0WGohNMYqAPm/0RaWLW2WX7ua3m6s86hf1LnN66a/+frbEAjrKX5u3kCfnthvB+kYGwkjMP4FGv8 zpkzGMIgklqmArZKGLZNE4y1hg4Y72odUxjVfStNr9IRlFAf/ePYPA7TmkM0feo6QnPpAU3X0vTa f/SYs9HR9oL+MBi/IzFu/sbXH2bBfFhqxVZh6gZwvlncuY2zbWtAPfw2wrhptRpWSc5YP0xNsewQ /j+0Q3IG7/1v2MQTWxHPM9AHj74P2mUk2WQGzM2wtBgSrTFe5xYuZuPX9IWWEEv2+MdSL/M+W7IH /Saljv/oeH5vjTEZjnlFBto4yXPLstV/0gqM3jSXHz7c75fZqn1xGvv1p2mCtc4c1a1CwXn3vzM1 J9IzxArOdAVUjzkecwE85ptvmzRi6I2MGUd4s4LzDT1uym1QlOXmXpRU5295QB6EOVQr3wcml6Rf d7ZiANlMtjM9CL+e1n1nPuAuO8BDeASP5Q65U8bKXXK3bP9PeZrJ5rKF/Ey2lK1ka9lGtpXt/u1y QiCbGCqGyVFytBwjR8rpcrz8Rn4rp8mx8ms5Tk6VE+UEOUlOllMwd2akiDkuXhfMfzcdgqOYdg2D Bi8w2JjEqxTzvrbMkIllZVnBnd6+6kHvXdXpvauCbWFbQLJn7BkY7D17D5kVqUjIooQqYWgjBYlU VAwWQ0Rf8aXoJ74S/cUAMVAkixQxSC6UC+QiuUQulkvlVjlTzpKz5Qy5Tm6W8+RyuUKukmvkWrle bpTLZKqcI+fKNDlfrpSr5Sa5RW6TG7B8f/Cmuzmd76wMpt/kQsgfzF8c3MgnONTGI9TwLNAQMkFj DNiTxOABcdi70mEzhqx0/J50/DngLoacZAVvpjIVfMzXl0AusogvWSQ3WcSP5WV5IQ8LwL5aXvYN +wb8yUYBZKN8ZKP8bD3bCAXIUkHsB/YDFGKn2CkozG6ym1DE5m5zN2vNYmCO6Cl6iT6it/hC9HTe Eyl60Z20RTBHUTyqYuZa5Ho4Hltx9OeS4gsohcovjbQrK7vIrrKH/EoOkp1kRxmHy51lV4jFtESZ JHvi8R2GI/IrSIfjcAw6QppMkclykPmeYczfGVbCFtwqCbfuiVvgOrgK1+Em3Iaf4R78Bi/hNbxl dtkdQ7yMZ5r8AkNf2ZcJZrAssj+GgXIgy8G8WS6Wm+Vh/nIYhuFyOCvICrGRspvsxqayabIXht4Y +sg+bC6bzxayxWwpWi4N7baGrWMb2GY5QA5g29lOtpvtYXvZfjkYwxAMQzGMkCPYcXZSJsgEdo5d YJfZFXaN3bDZ6O77/ESNILpXzoFndgXPlJHkC5+hL7SFdpAH2iNj/aET9IB80BMGYL8qGUMUpMIc tOZyWAFl8byzCsqTd1SAfdgHrwgnMERjX/wUVCNPiYEbGKrDLQw1sH9+B2qS79SC+xhqw3MMdeAV hrrwBkM9eAfv4ROmoDc1YDZmg8YsE9OhCXlWC/Ksz9CzvKAly8lyQjvmw3wglvkyX2jP/JgfdCCP 64geFwidWBALgm6sMCsM3dkoNgri2RT0wQT2LfsWEtl0Ngd6sHlsHvRlC9gC+JItYougH1vClsBX bBlbBv3ZCrYCBrCVbCUMZKvZakim+wlT0GfXwyC2ET13MHruNhjCdrAdMJztYrtgBPuOfQcj2ffs exjF9rF9MBr9+hiMYSfYCZhC3v0NO8POwlR2np2HaewiuwjT2Y/sR5jBrrKrMJNdZ9dhFilgts1u s4PFWDGcGFvLyTvRRrQV7USsaC86iI6ik4gTnX/PRIxng+zWHdnemJKL3mHLcNvOH/L8WTmii0hy 5ekiuopuoruIFwnic5Eoeoikv72vv1GOqz6xUEyWklGytCwjy8pysrysICvKSrKyrCKrymhZTcbI 6rKGrClrydqyjqwr68lPZH3ZQDaUn8pGsrFsIovIYFlUhshi0iFDZZgMlxGyuCwhS8pI2ZR+SW+m DMOdjVBG0NVIDQiQ7lJIKXNJX+knA2Q+mV8WkB54OW3IzDKLzCo9ZTaZXXrJHDKn9MF8uWUemVf6 y0KysAyUBWWQ9Dbvd2AhLBxLzqx4gqZkV4qAuzJaGY1aUpg7pMjtYoQYKUaJ0WKMGCu+FuPEeDFB TBSTxGQxRXwjpopvxTQxXcwQM8UsMVukijlirlgmlorlIk2sECvFKrFGrBZrxTqxQawXG8UmsVls FVvENrFDbBe7xE6xW3wnloh5YqGYLxUsf4F4LDWxWOwRi8QJ8UjsFz+Iw2Kv2CcOiWPiuLgqrosb 4qb4SdwV98QD8Yt4Kn4Vr8Rr6Sa5uCy+FwfEQXFEHBXp4qQ4LU6JM+KsOCfOiwviovhRXBHXxC1x W9wRP4v74qH4TTwXL8RL8Ua8RdnapF1mEu/Ee4kXheKJuIRWqovnGfP/DCZxGJ5lktFTRmCIIL4U J7KUJLJEwmkMpYgmUUST0kSTMkSTskSTckST8kSTCkSTikSTSkSTynSGqkpnqGhiSjXmjm0Rw3Qk S3UiSw0iS006Z9Vi2Vg2qM28kDJ1iDJ1iTL1iDKfEGXqE2Ua0HmtIcvP8sOnLBCJ04iI05iI04SI 05TOes2IOM2RONORYjPZTKTYbDYbKTYHGdSKGNSaGNSGGNSWGNSOGBRLDGpPDOpADOpIDOpEDIoj BnWms2cXtg1J1JVI1I1I1J1IFE8kSiASfU5n2ER2kB1E9h1mhyGJHWVHoSc7hoTqRYTqTYTqw84i ob4gQvUlQn1JhOpHhPqKCNWfCDWACDVQDEc6JVsK/lcK/J+q26ngYKUp6my4MpwUHAP+qNUsGbTr 1KQ7atjUtanijzXsTSr2zahjulOtCCuK3dbH7DnGXyoGUk1hdkj+/1RumqXYzajO70iTS1HF20mZ y1HFy1DHq1HJpo7Xo463oZJ3oYJ3/k61lyzdOlV7+H9Bt+Y4Sh1Lt/lReYzuPM1l9o6wp78ce0f5 YQuGIOwLnMJe2VUMkdg/uo7qvYkhCvtJt1G9P2Mog/2le1jGbxjKYS/yJar3NYaK8BZDJfNlUahb N4Z9EqYxDdVrZ5lQvR7MA3UrmEDdGsxA3WZhWVC3nswTdZudZUfd5mA5ULfezBt1m4vlQt3mZrlR t3lYHtStP/NH3eZj+VC3BVgB1G1BVhB1W4gVQt2OZCNRt1PYFNTtVDYVdTuNTUPdzmAzULez2CzU bSpLRd3OZXNRt/PZfNTtQrYQdbuYLUbdLmVLUbdmHzcWe2tpqFuzp9uBerodsee2DnW7gW1A3W5m m1G3W9lW1O12th11u5PtRN3uZrtRt3vYHtTtXrYXdbuf7UfdHmAHULeH2CHU7RF2BHWbztJRt8fZ cdTtSXYSdXuGnUHdnmPnULcX2AXU7WV2GXV7hV1B3V5j11C3N9gN6G/DDwwQ1UQ1GGhepWLv77SH YcR7yD/55wTDc6T5/9MA7GmXQMo675M8RPfwHXbd73jTfEc0xW65Yj99iGm9zdx/cU9gfjDwWvOA PCgPycPyiDwq0+UxeVyekCflKXkar0L/+C4kBv3BoNE2hzX64RzXakZjPs7RAkWelz/Q9ABND9L0 EE0P0/QITY/SNJ2mx2h6nKYnaHqSpqdoepqmf14nrw9Xy0ZucFPnqTfUJa5RgjDXmGtOIy/Y1cug qrPVK+pY/N79fYo13jKbruU/bOeFuWxWrjfWVhmWM2wzgbYxnwZU2Bz9MfzAUK+qj/Bq/zDmPoTx p+pdjD1Q12L8mrW+xF+s/2h73Nu/3D7jetd401iql3l/bBi0MPJAtj+pVbJ5dBnKd+b8o/r9jZxW TZLJQv9cpwhXm/mDJ667Zm1rjoOvoDa8lWHpqbWlOVqUjbbkhr+RYHxuJBo9rJEY0pc8K8/JC0bS n46x/PUYB/3bif45rtM/vwC48kjN5dbRrZNbHC3Tf9ScOX2SaCSQPj5dHSk+nbRMhYfGDH0umE1J TfFpikmfKoyFejgyabyIVBUfDo42mnsRDcGbUlJhbqkNHJ84gjOk+M71G+iL4jJDXcR/D4hHabWH JPyWM4PDP0NhbtlG15oy9sWO1vdeiPI+Py0p+8OvIxZ6paZkL+ZIcfvWkaImp6oIesUT+8sw029M wbRNT8/Rs3tgpkO4ass41usLqqb6qZvmqXzaINTTkcVcsHu6N27To1Nc945J8d1DMzukmWjztNVv H9stvntsqJ/D10xx98xeO65dYnyP+A5JeSvHJybEJ7ZJisMt8jn8zfWqp0/G9bHt8zaI69gdS81b r3JFh18OERrmKOWICAuNwHkzXAx3hLsWHcmD/iN1Ew4Pc72Hp1vtuvXqf8iu/kl2RwoLyGgz7Ouq KXiCxHR3JYUx2DK/etfMrwNmtJ/rNbX0oTZtXyUVWjFG8z7xeRPvkS0bi7i23Uuk1nkb8MXV3Pt9 2ox99WZelgJeP+xqEhw6cnhamN/wiwPKJTV+PmR+iQYHKz6M2xQ3q1uje91vrgms3eN47Ofr8pxp M3g4+D/s1GRQ8+pfr7tysviZQ+cdsxu86dtl2uAiG/07Jp36rc+GNsOmTupXOL3jz947zm9p96BM nXJfKfeeDliZbmxM7v/s9Z3n42O2fl129A+2ib5Pt/e8+aZd3kKzSz2t2DDSr2FshXWDl5ZMewqj r4tXc9YYAesXLUk7k2Oz45GSL2/mV12aGldXzJ7VOnmiWktMb+u9duuUbeObLewztNf0rkdq3c+6 PrKaoqIy5qUwgRbJ5PBEW+Yu4KY73DU7ejfnNlV15DYTpZuXW7YfP7mU64lfDV4+q+/ubXvWtg8e z6c68pir87nldHgNzHYoy52DJ9Z5NWEHSoaEe3ltrjXNPY+jkZkhj1tdR21HzdTqqdWGVu2UlJQQ VaxYu8SuId0+tFpIu/huxRK6xJmpxRIS42N7tkvqUQwbFR0P3Q49rpUjsmh4aNEwR6gjBDM5mn2o I2NudRy1HDU+LDuUoeWsXfTu3fuPdtE+8V+WnfQ7mammpxSe//yXXXsC+w5q69NnRvO9b+9n/35R H8/jORoEeehQqXykMeJSrPfg4gNiNqff6ztizpG6S65ufVAt87scF4aNyHy8VvbUR1neX5iSHpue /DZ80Z4+E2/2O91t2OdnfNtcP1wndmOP8i+/LBjxW/3y1SrvkskJDXZPYXNrbt1ZWO39ZffXx6JH 5ggKXcBveI3c9LhGXPbPwl9eGTCpTLWqudMOjtr/fLjf3Xfj9dl1bZkeBE7ovnaSN3vRKvl22oUR Xw9o1nJwq/U7+kXfqrbyXZMi4wcMuxSd55PJh/e0nbN+f6t7B+JafD5+yZhGeYOj6kx8O137esXI F536l97yRaWJpar/eqzl/YQxlXruTfl0XK71n7ZBOO1BOC3LAKcipcJidq85EPOUaFrk93Dq/R8B gD95HCo+5z/WN4zr1r5og6Q23RJ+j6bQsPAIQhMmfFh0JK/9b6CpoKOAc9Gve+W4hE7tE/NWaVA1 b9UGdaIqO6IjioY7IksUrVI1OjK0gCOf84h8//CIGrRP7BXXrv1fomzhBodU26fVaza0y5DZMXP8 Duz6pWV125CrCVP67djcqm0rLfDkqFJbcwYsCJmw4lzN4VE+K6cPSvuhZanR34V96dXnQcnIqMdt X3dKUTrdv7e1wsjV7+YEl2jbOqFU67by9b6ckfGrJpypIAYuFH1GlegydGRgjpzvV92rvWVrIc+f WsSMTYguEfguoviyiGvPL5xrcffbr0I31s7T+F6/M5NFB91PhuUoF3x64Jyj955PHa9c2t3qbeTA F6UGfBZ7sGSL0p80/2xIq6N+vq8jdrS6FfRpQsMZm+73g0+jmwdNDWpU69rjLZm8pyTHFHb88Dw8 b9fbcXvWntpTJ93hV/LU1PqnluSruiatRcXqdde17TTxA8oyoUV4BmotyBneoPzk1nMqez0cu2/l iSJbZjU59hG18kW8OF8/OsH9QYXXvV6vLbJqT/G1hqOhk1rILAcyK7Xq0Mr/FrWcq81WpEZEryRm NcnALCSWIyYDs8r8PWb9YclJf4Ru+x9hrP/hVV/eKrbjdqP16T0uLq1/3KvUvnVHXp1959d+/e2Y p9Ojh/MOnQOHtnw3rMmlfe3GRg58Zo/uV6THarmz4tJD+5dOml/yUWypa3tPvzxqO7rsZoFHcWmn oq+/6xBW5uw3e8P8X/3iUyC1pV4pOEt4VMqgtw9yr91xdPz88QU+37wscdWslTfToe2IhCWbatQb /UuxgNgFi3+q3WVysO8X9xfNC70wrvW4+d3fTVRE+eD8Yl/nwORPBtXIvLVnuypL4+z71HvX0z0e NIq6/zBxkbv+DE4GbFoZkLj29vczPIJSBx68ce1sqQ6O29E5ct5+lfKqqUffbYvFO9/36qh2a2pn VfLVLbp2yODS1+dUu5Oe3ZHCtyHG5jsx5t4mPNCH6BX6e3q1Iiy4Z5oQOGLik+BY5u2lYluEejty fJSYydVUoUUdRZw6zv8PHdePj0dIYNvFdYhr1yapfd6KPZM6xSfGJX1BlHI4IpFMYaGlwsOQUmHW Ypi5+L/Zt/sr1KxJbNrC2xG7M/e01nnzVvq2V4Ou5XKdiT986PHdLu++8cp89UpU0iCfjcVSw+6/ //G7SnXynU6Ei8Ubu484mJa3+rNHnZbXrjlmwfYvan4+vZrtwtsCV2b2HJ6+tEeVAWeTLz7d/qTE /AMtql5auaLs1aBO3/gsWpDYo9HjHJNuvi0+KTH1TK9Wfr2rDhoS6XWsR3O+pWP9MQvWxBW74O3x bkJSoeu9ijW8nM3R9MWJMW3fHjrQKjq03uaCnjcrONITC2UOCthfsk7Z1LCy447MidSGtKjTKCWo MA/bWPNs3Xa3TxRt+7hq2dvL7fBb9JxZx5uPDmxwp+/SGk+i00uWiZy1rneLBTlmjTmU5etGZXYv z9RKPfkBNS3RIs0chik9T8beu3GHirMM7PnDDpF5lshtuLmhBw51ZNUyWdcR2Zkbp4LxdOBKU8xS 3h4PrXMycOTka1Nbl14cGr+wzLZzRR3erkzZFDfdzx0aQE+89qgMFT+Cm1ye0rpCo4Lf3Crg+abw NfcGk5venO+o54RbdUc1R9XUyqkVh5b/+3BzrU5E1zapRGBrmAFsMY5oR5UMYIv8d8BmCqays9R/ 7oYpDJqWKjcgMHrlvfgKq8PWd74ni/2/6swzqqktDcOhCwEMRIr0Jr0kFJErUSnShBAEAwJKkd7J RSQoCFFAkabSQ0sA4UovXqMRGJomNGkXsCASQoeAgPQrNzrjyNxxyp9Zrvl3vr3XXuesfd79nPd7 T0Cp6ca80+VF8+MqwwYVwE+dsyrQQumua4jMKMkL5TA186f4UmTORBCRUL+JfmSK2jgxp3e9Y5xT wLuzOEdCZRuIaEN2q0yY9T8Lmi7lwjMVI98T4s/YrqTp53xYXaJNxIpr6hKQ2cvW0jGKRRiR+5RU NtEVCnwzAdcxAy6+CycJ9yej0hSD/bFCmyLL1kOeXVJ7jqLd+IQGuVr0JaQh3qp7a7bQDjmKZTxt qOa09rpyEKMesFuUBqbOe0//glduJCmBuN2Tst58xG/zyrK7H0v9EC5uRuwbR870hqULOpK1+J1G 74uaJqk0VmgaitBAfEKAC6NaDpI9mS/YaTHcCZb+3GA47JqCSQ6qb9Wvo3khqND2nm1EamKBsAmT /cbLQk+OkOKjiypqAqQplDbvWmCNridm62xtoga/uxh3/CjondtaYI/R4IDALLqNuX5gR3lMPD6v nGMHLHeqgro1/st1IyKbs7G78yl4tf4CfLEuFD3CocnuLxIFFadw24xO4nYmjUEVbpl7CH7Va00s kuGUND0579b7yWnkxBGsZCWXY84yvjLW6wanjwox1Bcgml6xwn91nf+GzJNbL31KjaFq2W8ngmHD gEhX476eW2SC4DY3KrG5EFbFeMpnzxubTgGVguq1EQeGWmEQDCsbnd9LX/nN76X5hd8iP4LfEG2I JoRObC2NLw2wOvRL+bkNpjfAP8z+/id65+P8asbemNxTvOareni8gTLRnmUljajoGRWEyxyk9ZX0 mVeEQCR45tl+s0njM00V1r9XmekIkX0N8J252rBwm+3gBjdz5vLtLvFODZm43JU1TxHl3avTt0Tn puGFuGZp647E7dMv2XsvVvVW6zPjtx743fccln9rZF0d2zspb6QqVx5ree4sJ5VJeccnJQUSELd6 HpK7HTmUUTcjmRG52Q9ePfDY2v9s/emUfBOAmbEHj5yCR2kGdYA12gy/dbOEx/gQOyb/5uK5sE8M 2aKIAzEAEMRo8fE7aSNim4pNfpVYmB70Shd27PiN+zgXxkeiXDW7G9hahh6pMzZ7WyytLRLAr/Qu o+9Iyb+j93eN4T/QG7Sf3vQRACQ686/wjU6BRCd+H7+4S0Uu/3N5YkDoCn6cWUFxhfnPdmtsYFX3 /xvq/1dWlr7XoIz4Vkcmw6Ojs/UVV970oK0sGGpUQ4Id/DnBZT2NV5MJqoO8+AR/V4ItYydcAozI Gg0/RbElVtlli4yLMsSWE8NW7vQuHGegURqTOVhIiSaUZWu+Ucuye9TpRJ/fopqnUldY1WKYZu8q ykgF7azvUsOyVLk22ChBzwThuUm+HKg0Ak4nx1Ol3Yp7ztXxJH/mHYmTFDYh9a0uqFkoFKaEApLm gmB7MRzgsRYOl6TlYYLAPPzO9XYtpYuFTfPPIoD6VwetUZI0SAcxzN3RgUGA4xB3/+tDmR91n3jY 1amoTW/FxHZZIWdyg1L9ynXMB9fRTQ8Fw10VlvBYBU3WK0KuZJiYvzhmGfhCmfjSoG5yayHi0URR aYgWAd4eLM0rGwrUPZsQbG9kcOhZXV21hScpX38vCi0ZlccH8ZjR570oRMqTkuw1mFWaJa6ZdCkP jqhHmcsqmsg42c8hlx68y8rt+CmwIVouhJWHFirZhMU0y9n8WuMDu40LdakPwIEfND00XuYN/D1e 3a/205gVKUGa7NGQKxrH68YIU6k6n0ygSk4+qu64VB9mwzKop4ooT60uDiurK0i/LPTqXhz4spSa eumBgAKHhCNNBUs3OySH5sUsydk00/cbDO6Bt4ERJG/SVMBcSUYPVGGPu93BccRCGDeyrZZ3UvUc vy8ZXPg7FMNMP8LMJYwMDBD6cftxfvn7Ue23xLcguu2zXfubftmZoJz742T6A3yrgFBuyP5Zvs9m 8OtCZigdSrmZLky2VVJLE7sT5A4u4TovPegxiNu+JZxQJMSmQDFKHmAB8AZcAqAAgV8SaQ9ACEAC YANAA4LolSd93IV+5QVA42SjZP7lYQ1BBwV6olyCvNASf/qoMGMYANo05iVTQk/v859hxa/87Mwe 9/e/ZRfSOdOGvDn5UafEEbrd7XypNC2jzitOIPLVmM5hoPwc9YR2F9eVNpz9IJHvUKWw/vldN0sq Xx5RU1Ov8oJrFCphyoati1ohf7SJ8Yiyk2j8ySc56tsrhPyh+A6V5nRjhadxKcYZTK8Xl0zK+mtP 7Hg/s4BNn6vxYFb1ZcuwkTDIwEVrH3uI023z4Blw1uhRD6XOFVTjEKVWY50eRSzDYWJ9s2+rRj4G 9uJRfqhjT1GMZS+qkS9b23fuSvtEFHfuPU/prmHazgdvtpP64yRdNed2Bi8/1zVXn2/GJmc3pmNt F9rWSzSk7BJJo++e4DCM8hAMo8y3d8QKxTDSm0xGni+qTPphLuD7Cd0+TV6ACO6XJPDbbxAG+s3/ PsMCPfg5TYNCIcfofepRqLb9Pyky0vlTkmmYITq0j2GcqqMltATC8v+J15+1wlcPIM2M+CmeIM/U T/VtSKix2FD+QuNXb/o1SKn8Vr/daoKbg05rbWmJHrDHcn1su6plmMh9pMhVuAlpsSPeUD+8tUl4 E3IX9u6G0VSkB98TTb1TzkZV8Bb9w1tV82XvPRsPip2kRgwLX8+eVuq+PT8y6zY0EYtMSVuV6wL5 WiUfONLnr4U4ONhH1qNw/WTbbKAjgpbnpKlHtbXc6KN1ixgjbl4pDC/rbhCZql1HPLX3JY/Kg+7u XjdMxqvLamD7P5bdkV9arwwm5z3cbC5UfHFkYHndqYPkMPbgWgiAAxEkweI5PIYis9UPyFNSZ4Tz E6hZMOas8LxQMdmWhMqE+A9/AAN9nssNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNTMgMCBvYmoNCjw8 L1R5cGUvTWV0YWRhdGEvU3VidHlwZS9YTUwvTGVuZ3RoIDE0NjM+Pg0Kc3RyZWFtDQo8P3hwYWNr ZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pjx4OnhtcG1ldGEg eG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS03MDEiPgo8cmRmOlJERiB4bWxu czpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgo8cmRm OkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiAgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29t L3hhcC8xLjAvIj4KPC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PSIiICB4bWxuczp4bXBSaWdodHM9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9yaWdodHMv Ij4KPHhtcFJpZ2h0czpNYXJrZWQ+VHJ1ZTwveG1wUmlnaHRzOk1hcmtlZD48L3JkZjpEZXNjcmlw dGlvbj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8L3JkZjpSREY+ PC94OnhtcG1ldGE+PD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDQplbmRvYmoNCjE1NCAw IG9iag0KPDwvTiAzL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjU5Mz4+DQpzdHJlYW0NCnic nZZ3VFTXFofPvXd6oc0wdBh6r1IGEOkdpFdRGGYGGMoAwwzYCyIqEFFEpCmCBAUMGA1FYkUUCwFR AXtAgoASg1FsqGRG1kp8eXnv5eX3xz3f2mfvc/fZe9+1LgAkLz8uLx2WAiCNJ+AHe7rQI6Oi6dh+ AAM8wABzAJisrAz/EI9QIJK3uys9S+QE/kWvhwEkXm8ZewXS6eD/kzQrgy8AAAoU8RI2J4sl4jwR p+YIMsT2WRFT41PEDKPEzBclKGJ5MScustFnn0V2EjM7jccWsTjnDHYaW8w9It6RLeSIGPETcX42 l5Mj4tsi1koVpnFF/FYcm8ZhZgGAIontAg4rScRmIibxQ4NdRbwUABwp8QuO/4IFnNUC8aVc0zPW 8LmJSQK6Hkufbm5ry6B7cXJSOQKBcSCTlcLks+mu6WkZTN4aABbv/Fky4trSRUW2Nre1tja2MDH/ olD/dfNvStzbRXoZ9LlnEK3vD9tf+aXXAcCYE9Vm9x+2+AoAOrYBIH/vD5vWIQAkRX1rH/jiPjTx vCQJBBl2pqY5OTkmXA7LRFzQ3/U/Hf6Gvnififi438tDd+MkMIWpArq4bqz01HQhn56VwWRx6MZ/ HuJ/HPjXeRgFcxI4fA5PFBEumjIuL1HUbh6bK+Cm8+hc3n9q4j8M+5MW51okSv0nQI01AVIDVID8 3AdQFCJAYg6KdqDf++aHDweBojVCbXJx7j8L+vdT4WLxI4ub+DnONTiUzhLysxf3xJ8lQAMCkARU oABUgSbQA8bAAtgAe+AE3IEPCAChIAqsAiyQBNIAH+SA9WALyAeFYDfYBypBDagHjaAFnAAd4DS4 AC6D6+AGGAL3wSiYAM/ALHgN5iEIwkJkiAIpQGqQNmQIWUAMaBnkDvlBwVAUFAclQjxICK2HtkKF UAlUCdVCjdC30CnoAnQVGoTuQmPQNPQr9B5GYBJMhVVgHdgUZsDOsC8cCq+EE+FMeC2cB++Cy+E6 +BjcDl+Ar8ND8Cj8DJ5DAEJEaIg6YowwEFckAIlGEhA+shEpQMqQOqQF6UJ6kVvIKDKDvENhUBQU HWWMskd5ocJQLFQmaiOqCFWJOopqR/WgbqHGULOoT2gyWhltiLZDe6Mj0YnoHHQ+ugzdgG5DX0IP oSfQrzEYDA2ji7HBeGGiMMmYdZgizAFMK+Y8ZhAzjpnDYrEKWEOsAzYAy8QKsPnYCuwx7DnsTewE 9i2OiFPDWeA8cNE4Hi4XV4Zrwp3F3cRN4ubxUnhtvB0+AM/Gr8EX4+vxXfgB/AR+niBN0CU4EEIJ yYQthHJCC+ES4QHhJZFI1CDaEoOIXOJmYjnxOPEKcYz4jiRDMiC5kmJIQtIu0hHSedJd0ksymaxD diJHkwXkXeRG8kXyI/JbCYqEiYS3BFtik0SVRLvETYnnknhJbUlnyVWSayXLJE9KDkjOSOGldKRc pZhSG6WqpE5JjUjNSVOkzaUDpNOki6SbpK9KT8lgZXRk3GXYMnkyh2UuyoxTEIomxZXComyl1FMu USaoGKou1ZuaTC2kfkPtp87KyshayobLrpatkj0jO0pDaDo0b1oqrZh2gjZMey+nIucsx5HbKdci d1PujbySvJM8R75AvlV+SP69Al3BXSFFYY9Ch8JDRZSigWKQYo7iQcVLijNKVCV7JZZSgdIJpXvK sLKBcrDyOuXDyn3KcyqqKp4qGSoVKhdVZlRpqk6qyaqlqmdVp9UoasvUuGqlaufUntJl6c70VHo5 vYc+q66s7qUuVK9V71ef19DVCNPI1WjVeKhJ0GRoJmiWanZrzmqpaflrrddq1rqnjddmaCdp79fu 1X6jo6sTobNdp0NnSlde11t3rW6z7gM9sp6jXqZend5tfYw+Qz9F/4D+DQPYwMogyaDKYMAQNrQ2 5BoeMBw0QhvZGvGM6oxGjEnGzsbZxs3GYyY0Ez+TXJMOk+emWqbRpntMe00/mVmZpZrVm903lzH3 Mc817zL/1cLAgmVRZXF7CXmJx5JNSzqXvLA0tORYHrS8Y0Wx8rfabtVt9dHaxppv3WI9baNlE2dT bTPCoDICGUWMK7ZoWxfbTbanbd/ZWdsJ7E7Y/WJvbJ9i32Q/tVR3KWdp/dJxBw0HpkOtw+gy+rK4 ZYeWjTqqOzId6xwfO2k6sZ0anCad9Z2TnY85P3cxc+G7tLm8cbVz3eB63g1x83QrcOt3l3EPc690 f+Sh4ZHo0ewx62nluc7zvBfay9drj9eIt4o3y7vRe9bHxmeDT48vyTfEt9L3sZ+BH9+vyx/29/Hf 6/9gufZy3vKOABDgHbA34GGgbmBm4PdBmKDAoKqgJ8HmweuDe0MoIbEhTSGvQ11Ci0Pvh+mFCcO6 wyXDY8Ibw99EuEWURIxGmkZuiLwepRjFjeqMxkaHRzdEz61wX7FvxUSMVUx+zPBK3ZWrV15dpbgq ddWZWMlYZuzJOHRcRFxT3AdmALOOORfvHV8dP8tyZe1nPWM7sUvZ0xwHTglnMsEhoSRhKtEhcW/i dJJjUlnSDNeVW8l9keyVXJP8JiUg5UjKQmpEamsaLi0u7RRPhpfC60lXTV+dPphhmJGfMZppl7kv c5bvy2/IgrJWZnUKqKKfqT6hnnCbcCx7WXZV9tuc8JyTq6VX81b3rTFYs3PN5FqPtV+vQ61jrete r75+y/qxDc4bajdCG+M3dm/S3JS3aWKz5+ajWwhbUrb8kGuWW5L7amvE1q48lbzNeePbPLc150vk 8/NHtttvr9mB2sHd0b9zyc6KnZ8K2AXXCs0Kywo/FLGKrn1l/lX5Vwu7Enb1F1sXH9yN2c3bPbzH cc/REumStSXje/33tpfSSwtKX+2L3Xe1zLKsZj9hv3D/aLlfeWeFVsXuig+VSZVDVS5VrdXK1Tur 3xxgH7h50OlgS41KTWHN+0PcQ3dqPWvb63Tqyg5jDmcfflIfXt/7NePrxgbFhsKGj0d4R0aPBh/t abRpbGxSbipuhpuFzdPHYo7d+Mbtm84W45baVlpr4XFwXHj86bdx3w6f8D3RfZJxsuU77e+q2yht Be1Q+5r22Y6kjtHOqM7BUz6nurvsu9q+N/n+yGn101VnZM8UnyWczTu7cG7tubnzGednLiReGO+O 7b5/MfLi7Z6gnv5LvpeuXPa4fLHXuffcFYcrp6/aXT11jXGt47r19fY+q762H6x+aOu37m8fsBno vGF7o2tw6eDZm443L9xyu3X5tvft60PLhwaHw4bvjMSMjN5h35m6m3r3xb3se/P3Nz9APyh4KPWw 7JHyo7of9X9sHbUePTPmNtb3OOTx/XHW+LOfsn76MJH3hPykbFJtsnHKYur0tMf0jacrnk48y3g2 P5P/s/TP1c/1nn/3i9MvfbORsxMv+C8Wfi16qfDyyCvLV91zgXOPXqe9nn9T8Fbh7dF3jHe97yPe T87nfMB+KP+o/7Hrk++nBwtpCwu/AfeE8/sNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNTUgMCBvYmoN Cjw8L1R5cGUvTWV0YWRhdGEvU3VidHlwZS9YTUwvTGVuZ3RoIDM0MDA+Pg0Kc3RyZWFtDQo8P3hw YWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pjx4OnhtcG1l dGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS03MDEiPgo8cmRmOlJERiB4 bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgo8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUu Y29tL3BkZi8xLjMvIj4KPHBkZjpQcm9kdWNlcj5NaWNyb3NvZnTCriBXb3JkIDIwMTA8L3BkZjpQ cm9kdWNlcj48cGRmOktleXdvcmRzPjMsIDksIDEwLCAxMiwgMTQvMTU8L3BkZjpLZXl3b3Jkcz48 L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgIHhtbG5zOmRj PSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyI+CjxkYzp0aXRsZT48cmRmOkFsdD48 cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPm9MUzogQ2xvc3VyZSBvZiB0aGUgYWQtaG9jIGdy b3VwIG9uIE1QTFMtVFA8L3JkZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRsZT48ZGM6Y3JlYXRvcj48 cmRmOlNlcT48cmRmOmxpPlNHMTUgQ2hhaXJtYW48L3JkZjpsaT48L3JkZjpTZXE+PC9kYzpjcmVh dG9yPjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiAgeG1s bnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KPHhtcDpDcmVhdG9yVG9vbD5N aWNyb3NvZnTCriBXb3JkIDIwMTA8L3htcDpDcmVhdG9yVG9vbD48eG1wOkNyZWF0ZURhdGU+MjAx My0wMS0xN1QyMzo0MjozNSswMTowMDwveG1wOkNyZWF0ZURhdGU+PHhtcDpNb2RpZnlEYXRlPjIw MTMtMDEtMTdUMjM6NDI6MzUrMDE6MDA8L3htcDpNb2RpZnlEYXRlPjwvcmRmOkRlc2NyaXB0aW9u Pgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiAgeG1sbnM6eGFwTU09Imh0dHA6Ly9ucy5h ZG9iZS5jb20veGFwLzEuMC9tbS8iPgo8eGFwTU06RG9jdW1lbnRJRD51dWlkOkFBNEFGREFELTc3 NUEtNDZCRS05NjI0LTE3NEQ2NzdDNTQxODwveGFwTU06RG9jdW1lbnRJRD48eGFwTU06SW5zdGFu Y2VJRD51dWlkOkFBNEFGREFELTc3NUEtNDZCRS05NjI0LTE3NEQ2NzdDNTQxODwveGFwTU06SW5z dGFuY2VJRD48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIg IHhtbG5zOnBkZmFpZD0iaHR0cDovL3d3dy5haWltLm9yZy9wZGZhL25zL2lkLyI+CjxwZGZhaWQ6 cGFydD4xPC9wZGZhaWQ6cGFydD48cGRmYWlkOmNvbmZvcm1hbmNlPkE8L3BkZmFpZDpjb25mb3Jt YW5jZT48L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjwvcmRmOlJE Rj48L3g6eG1wbWV0YT48P3hwYWNrZXQgZW5kPSJ3Ij8+DQplbmRzdHJlYW0NCmVuZG9iag0KeHJl Zg0KMCAxNTYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAwMDAw MzQyIDAwMDAwIG4NCjAwMDAwMDAzOTggMDAwMDAgbg0KMDAwMDAwMDY2MCAwMDAwMCBuDQowMDAw MDA1ODI4IDAwMDAwIG4NCjAwMDAwMDYwMTQgMDAwMDAgbg0KMDAwMDAwNjI4MiAwMDAwMCBuDQow MDAwMDA2NDYzIDAwMDAwIG4NCjAwMDAwMDY3MjYgMDAwMDAgbg0KMDAwMDAwNjg3NSAwMDAwMCBu DQowMDAwMDA2OTA1IDAwMDAwIG4NCjAwMDAwMDcwODMgMDAwMDAgbg0KMDAwMDAwNzE1NyAwMDAw MCBuDQowMDAwMDA3NDQxIDAwMDAwIG4NCjAwMDAwMDc2MTcgMDAwMDAgbg0KMDAwMDAwNzc0OSAw MDAwMCBuDQowMDAwMDA3Nzc5IDAwMDAwIG4NCjAwMDAwMDc5MzkgMDAwMDAgbg0KMDAwMDAwODAx MyAwMDAwMCBuDQowMDAwMDA4MjY2IDAwMDAwIG4NCjAwMDAwMDg0MzQgMDAwMDAgbg0KMDAwMDAw ODY4NCAwMDAwMCBuDQowMDAwMDE1NjY4IDAwMDAwIG4NCjAwMDAwMTU5NzggMDAwMDAgbg0KMDAw MDAxNjA4NyAwMDAwMCBuDQowMDAwMDE2MzQxIDAwMDAwIG4NCjAwMDAwMTYzOTIgMDAwMDAgbg0K MDAwMDAxNjUxNiAwMDAwMCBuDQowMDAwMDE2Njk0IDAwMDAwIG4NCjAwMDAwMTY3ODMgMDAwMDAg bg0KMDAwMDAxNjg1OCAwMDAwMCBuDQowMDAwMDE2OTI3IDAwMDAwIG4NCjAwMDAwMTczMjkgMDAw MDAgbg0KMDAwMDAxNzQwNCAwMDAwMCBuDQowMDAwMDE3NDczIDAwMDAwIG4NCjAwMDAwMTc1NDgg MDAwMDAgbg0KMDAwMDAxNzYxNyAwMDAwMCBuDQowMDAwMDE3NzA2IDAwMDAwIG4NCjAwMDAwMTc3 NzQgMDAwMDAgbg0KMDAwMDAxNzg1NiAwMDAwMCBuDQowMDAwMDE3OTI1IDAwMDAwIG4NCjAwMDAw MTc5OTQgMDAwMDAgbg0KMDAwMDAxODA2OSAwMDAwMCBuDQowMDAwMDE4MTM4IDAwMDAwIG4NCjAw MDAwMTgyMjcgMDAwMDAgbg0KMDAwMDAxODI5NSAwMDAwMCBuDQowMDAwMDE4MzYzIDAwMDAwIG4N CjAwMDAwMTg0NDUgMDAwMDAgbg0KMDAwMDAxODUxNCAwMDAwMCBuDQowMDAwMDE4NTgzIDAwMDAw IG4NCjAwMDAwMTg2NzkgMDAwMDAgbg0KMDAwMDAxODc1NCAwMDAwMCBuDQowMDAwMDE4ODIzIDAw MDAwIG4NCjAwMDAwMTg4OTggMDAwMDAgbg0KMDAwMDAxODk2NyAwMDAwMCBuDQowMDAwMDE5MDQy IDAwMDAwIG4NCjAwMDAwMTkxMTIgMDAwMDAgbg0KMDAwMDAxOTE4MiAwMDAwMCBuDQowMDAwMDE5 MjU3IDAwMDAwIG4NCjAwMDAwMTkzMzIgMDAwMDAgbg0KMDAwMDAxOTQwMiAwMDAwMCBuDQowMDAw MDE5NDg0IDAwMDAwIG4NCjAwMDAwMTk1NTkgMDAwMDAgbg0KMDAwMDAxOTYyOSAwMDAwMCBuDQow MDAwMDE5NzA0IDAwMDAwIG4NCjAwMDAwMTk3NzQgMDAwMDAgbg0KMDAwMDAxOTg1NiAwMDAwMCBu DQowMDAwMDE5OTMxIDAwMDAwIG4NCjAwMDAwMjAwMDEgMDAwMDAgbg0KMDAwMDAyMDA3NiAwMDAw MCBuDQowMDAwMDIwMTQ2IDAwMDAwIG4NCjAwMDAwMjAyMjggMDAwMDAgbg0KMDAwMDAyMDMwMyAw MDAwMCBuDQowMDAwMDIwMzczIDAwMDAwIG4NCjAwMDAwMjA0NDMgMDAwMDAgbg0KMDAwMDAyMDUy NSAwMDAwMCBuDQowMDAwMDIwNjAwIDAwMDAwIG4NCjAwMDAwMjA2NzAgMDAwMDAgbg0KMDAwMDAy MDc0NSAwMDAwMCBuDQowMDAwMDIwODE1IDAwMDAwIG4NCjAwMDAwMjA4OTcgMDAwMDAgbg0KMDAw MDAyMDk3MiAwMDAwMCBuDQowMDAwMDIxMDQyIDAwMDAwIG4NCjAwMDAwMjExMTcgMDAwMDAgbg0K MDAwMDAyMTE4NyAwMDAwMCBuDQowMDAwMDIxMjY5IDAwMDAwIG4NCjAwMDAwMjEzNDQgMDAwMDAg bg0KMDAwMDAyMTQxNCAwMDAwMCBuDQowMDAwMDIxNDg5IDAwMDAwIG4NCjAwMDAwMjE1NTkgMDAw MDAgbg0KMDAwMDAyMTY0MSAwMDAwMCBuDQowMDAwMDIxNzE2IDAwMDAwIG4NCjAwMDAwMjE3ODYg MDAwMDAgbg0KMDAwMDAyMTg2MSAwMDAwMCBuDQowMDAwMDIxOTMxIDAwMDAwIG4NCjAwMDAwMjIw MTMgMDAwMDAgbg0KMDAwMDAyMjA4OCAwMDAwMCBuDQowMDAwMDIyMTU4IDAwMDAwIG4NCjAwMDAw MjIyMzMgMDAwMDAgbg0KMDAwMDAyMjMwMyAwMDAwMCBuDQowMDAwMDIyNDA0IDAwMDAwIG4NCjAw MDAwMjI0ODIgMDAwMDAgbg0KMDAwMDAyMjU1NCAwMDAwMCBuDQowMDAwMDIyNjQ4IDAwMDAwIG4N CjAwMDAwMjI3MjAgMDAwMDAgbg0KMDAwMDAyMjc5MiAwMDAwMCBuDQowMDAwMDIyODY0IDAwMDAw IG4NCjAwMDAwMjI5NTAgMDAwMDAgbg0KMDAwMDAyMzAyMiAwMDAwMCBuDQowMDAwMDIzMTE1IDAw MDAwIG4NCjAwMDAwMjMxODcgMDAwMDAgbg0KMDAwMDAyMzI3NSAwMDAwMCBuDQowMDAwMDIzMzMw IDAwMDAwIG4NCjAwMDAwMjM0MDIgMDAwMDAgbg0KMDAwMDAyMzQ3NCAwMDAwMCBuDQowMDAwMDIz NTQ2IDAwMDAwIG4NCjAwMDAwMjM2MzEgMDAwMDAgbg0KMDAwMDAyMzcwOSAwMDAwMCBuDQowMDAw MDIzNzgxIDAwMDAwIG4NCjAwMDAwMjM4NTMgMDAwMDAgbg0KMDAwMDAyMzk0MyAwMDAwMCBuDQow MDAwMDI0MDE0IDAwMDAwIG4NCjAwMDAwMjQwODUgMDAwMDAgbg0KMDAwMDAyNDE5MyAwMDAwMCBu DQowMDAwMDI0MjcxIDAwMDAwIG4NCjAwMDAwMjQzNDcgMDAwMDAgbg0KMDAwMDAyNDQyNSAwMDAw MCBuDQowMDAwMDI0NTAxIDAwMDAwIG4NCjAwMDAwMjQ1NzkgMDAwMDAgbg0KMDAwMDAyNDY1NSAw MDAwMCBuDQowMDAwMDI0NzMzIDAwMDAwIG4NCjAwMDAwMjQ4MDkgMDAwMDAgbg0KMDAwMDAyNDg4 NyAwMDAwMCBuDQowMDAwMDI0OTYzIDAwMDAwIG4NCjAwMDAwMjUwMzQgMDAwMDAgbg0KMDAwMDAy NTEwNSAwMDAwMCBuDQowMDAwMDI1MTc2IDAwMDAwIG4NCjAwMDAwMjU0NzYgMDAwMDAgbg0KMDAw MDA5NzYxNiAwMDAwMCBuDQowMDAwMDk5MTYzIDAwMDAwIG4NCjAwMDAwOTk0OTAgMDAwMDAgbg0K MDAwMDA5OTU5MSAwMDAwMCBuDQowMDAwMDk5ODg5IDAwMDAwIG4NCjAwMDAxMDAyMjkgMDAwMDAg bg0KMDAwMDE4NjA5NiAwMDAwMCBuDQowMDAwMTg3NjQzIDAwMDAwIG4NCjAwMDAxODc5NDQgMDAw MDAgbg0KMDAwMDIwMDI3MyAwMDAwMCBuDQowMDAwMjAxODIwIDAwMDAwIG4NCjAwMDAyMDE4NjQg MDAwMDAgbg0KMDAwMDIwMTk1NCAwMDAwMCBuDQowMDAwMjAxOTgyIDAwMDAwIG4NCjAwMDAyNTMx ODEgMDAwMDAgbg0KMDAwMDI1NDcyOCAwMDAwMCBuDQowMDAwMjU3NDAyIDAwMDAwIG4NCnRyYWls ZXINCjw8L1NpemUgMTU2L1Jvb3QgMSAwIFIvSW5mbyAyMyAwIFIvSURbPEFERkQ0QUFBNUE3N0JF NDY5NjI0MTc0RDY3N0M1NDE4PjxBREZENEFBQTVBNzdCRTQ2OTYyNDE3NEQ2NzdDNTQxOD5dID4+ DQpzdGFydHhyZWYNCjI2MDg4Ng0KJSVFT0Y= --_005_EF35EE4B92789843B1DECBC0E24558640FF46Aeusaamb105ericsso_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 18 Jan 2013 16:50:35 GMT"; modification-date="Fri, 18 Jan 2013 16:50:35 GMT" Received: from esessmw0184.eemea.ericsson.se (153.88.115.81) by EUSAAHC001.ericsson.se (147.117.188.75) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 17 Jan 2013 19:22:45 -0500 Received: from sessmg11.ericsson.net (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.83) with Microsoft SMTP Server id 8.3.279.1; Fri, 18 Jan 2013 01:22:29 +0100 Received: from mail8.itu.ch (mail8.itu.ch [156.106.192.38]) (using TLS with cipher AES256-SHA (AES256-SHA/256 bits)) (Client did not present a certificate) by sessmg11.ericsson.net (Symantec Mail Security) with SMTP id 1D.97.10468.4C598F05; Fri, 18 Jan 2013 01:22:28 +0100 (CET) Received: from sympa1.itu.ch (sympa1.itu.ch [156.106.192.98]) by mail8.itu.ch (8.13.8/8.14.4) with ESMTP id r0I0MPhA020563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2013 01:22:25 +0100 Received: from sympa1.itu.ch (sympa1.itu.ch [127.0.0.1]) by sympa1.itu.ch (8.13.8/8.13.8) with ESMTP id r0I0MPBG012537; Fri, 18 Jan 2013 01:22:25 +0100 Received: (from sympa@localhost) by sympa1.itu.ch (8.13.8/8.13.8/Submit) id r0I0MPkC012535; Fri, 18 Jan 2013 01:22:25 +0100 From: Yoichi MAEDA To: "Jones, Greg" CC: "yoichi.maeda@ttc.or.jp" , "ahmpls-tp@lists.itu.int" , "TSBSG15, ITU" Subject: Re: [AHMPLS-TP] Closure of the ad hoc Group on MPLS-TP and associated mailing list Thread-Topic: [AHMPLS-TP] Closure of the ad hoc Group on MPLS-TP and associated mailing list Thread-Index: Ac31BT31SGjq4LRlTES4JeRz7wI6KwAM5M4A Date: Fri, 18 Jan 2013 00:01:04 +0000 Message-ID: <20130118090103.BDAA.B5F9D168@ttc.or.jp> References: <9BA9FE6D8B2F5344BF95CDAC35C8320D637E9EC5@TUCHM02.TUECSP.UNICC.ORG> List-Help: List-Subscribe: List-Unsubscribe: In-Reply-To: <9BA9FE6D8B2F5344BF95CDAC35C8320D637E9EC5@TUCHM02.TUECSP.UNICC.ORG> Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0184.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb3d-b7f646d0000028e4-83-50f895c42b3c x-brightmail-tracker: H4sIAAAAAAAAA02Sa0hTYRjHfc+Z87g8eZzaeV2JNVKjmbYom2IXrECEcNQni8yZRzedU86Z op+8pjItJS+pWxdRVmmo3UitSK1kKpFKQmHah00Jw0Kxkq1c53i8ffs9z//5v8//hQdDxc1C CUbl6ilap9JKhSKBKa0v6MDbumXlQetYhKJjZhZR1N8zI4pvC+Nuik9lFqAwvBgUnnSNsf+a ECrBBVFUMqXV5FB02PFEkXqu8wmS9ZXMtZbcFBaA32IDcMcgcRhOfXC48rwDjk53Cg1AhIkJ EwJLquwIX9gArDDMuPKFEcCRXqsbZxET+XD8hxXw9r1wdOyVG8/R8I59YY13wyJb4doKX1jb 8JPtYywHwcLes3ybhDXND1COBUQgXO4YWbUKCRl8bTQDbtyHHb9VEsBFQIliAItetqBc351Q whprOJ8mDg4NXhNwjLMfM0+Xozx7waFG22ofJUKgpW0Q5TkAPp83oXyEAGgYKEW59yFxHcCp MqeALwoAfFhiWnV7E5fgcP0CWHf0vRsR8EzA74ZHq6FdiX1woWsR4Zhg+7dbezZ45cbo2rwX tBiMaDUIbtoSsGlLwKYtAe8CtA34MhTDZKTK5aEUrbnCMJm6UB2lfwzYu+h/6jjWDSwdRweA H4ZIfXF7zbJSvD0pMzlPrWLUl+lsLcUMgJ2YQEriPZOtSjGRqtJT6RSVRdHr6i4Mk0I8r5Z1 etFUKpWbotHqN2UEcx8AEPOQ+uDl3AzOZKkyGE0qrw+DPRISv8oJBCeos3UbXu5y851O5zjw l3jjwMXFRezB7s3Q6Dd17rLnAIkBqTfewL3iodHpN16fYxcj7GKfsT/cYr1qU5IUgLr29I/n u0A8WV9zyCMhTSZpeYZYikdml8IuRpk1LY3WsL99ujbPSn9nhcneTkweIY2xnxcdSboEZcj9 pNgIc398zGlnafXKxKnQxRy1rMqvUm4Lf58SGEwXvSHNidF+xsTu0XlP2Zmlyi/xjkhrf+S2 OLJzUlt9osB8rvqfVMCoVfL9KM2o/gOc5BOJtAMAAA== list-archive: list-post: list-id: errors-to: ahmpls-tp-owner@lists.itu.int x-no-archive: yes x-sequence: 1640 x-loop: ahmpls-tp@lists.itu.int x-greylist: Delayed for 00:20:15 by milter-greylist-4.4a2 (mail8.itu.ch [156.106.192.38]); Fri, 18 Jan 2013 01:22:20 +0100 (CET) list-owner: x-originating-ip: [1.33.190.161] x-starscan-version: 6.7; banners=-,-,- x-viruschecked: Checked x-msg-ref: server-2.tower-54.messagelabs.com!1358467314!14514699!1 x-env-sender: yoichi.maeda@ttc.or.jp Content-Type: text/plain; charset="us-ascii" Content-ID: <51C654A18A4FFD4B92746CEFA031228F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Dear Greg and all; Thank you for your information. Congratulation on the closure of the ad hoc group. =20 As the ex-SG15 chairman, I am very glad to see this announcement after the long collaboration between ITU-T and IETF since 2008. I hope the remaining work on MPLS-TP will be carried out in the relevant questions under the leadership of the new SG15 Chairman, Dr. Steve Trowbridge.. I would like to express my sincere thanks to all colleagues in ITU-T and IETF who contributed to this important subject in the last study period.=20 I hope you will keep the collaborative relations with other SDOs and Fora, and will have fruitful results in your new study period of 2013-2016. Regards, Yoichi Maeda Ex-SG15 Chairman and Chairman of Review Committee On Thu, 17 Jan 2013 22:53:14 +0000 "Jones, Greg" wrote: > The ad hoc Group on MPLS-TP was formed by SG 15 in February 2008 to coord= inate work on the development of the MPLS-TP Recommendations within SG 15 a= nd to provide a focal point for communications with the IETF. > Following the approval of the several of the key Recommendation including= the OAM Recommendations (G.8113.1 and G.8113.2) approved by WTSA in Novemb= er 2012 the SG 15 management team have concluded that coordination role pro= vided by the ad hoc group is no longer required since the remaining work on= MPLS-TP can be carried out directly in the relevant questions, as describe= d below. Note that responsibility for the equipment aspects has been moved = from Q9/15 to Q10/15 effective in the 2013-2016 study period. > Q3/15: responsible for MPLS-TP Terminology > Q9/15: responsible for MPLS-TP Protection > Q10/15: responsible for MPLS-TP OAM and Equipment > Q12/15: responsible for MPLS-TP Network Architecture > Q14/15: responsible for MPLS-TP Network Management >=20 > Consequently the ad hoc Group on MPLS-TP will not be continued in the new= study period (2013-2016). Therefore, the email reflector (ahmpls-tp@lists.= itu.int) will be deactivated after this message has been transmitted. >=20 > The SG15 management team has appointed Mr. Malcolm Betts (malcolm.betts@z= te.com.cn) as the acting liaison Rapporteur to the IETF for matters related= to MPLS-TP, pending confirmation in the July 2013 plenary. He will also co= ntinue to act as the contact point for any issues on MPLS-TP that are not d= irectly related to the work of the Questions. >=20 >=20 > Regards, > Greg Jones > Counsellor, ITU-T Study Group 15 > International Telecommunication Union > Tel: +41 22 730 5515 > Mob: +41 79 249 4832 >=20 ****** New position from October 1st. 2010 ****** Yoichi MAEDA The Telecommunication Technology Committee (TTC) CEO & S.V.P. Chairman ITU-T Study Group 15,=20 Fellow of IEICE Address: 1-1-12 Shiba kouen, Minato-ku, Tokyo, 105-0011, JAPAN Tel: +81-3-5776-7730 Fax: +81-3-3432-1553 E-mail: yoichi.maeda@ttc.or.jp ************************************************** --_005_EF35EE4B92789843B1DECBC0E24558640FF46Aeusaamb105ericsso_-- From gregory.mirsky@ericsson.com Fri Jan 18 12:28:58 2013 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 61A1321F871D for ; Fri, 18 Jan 2013 12:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 4-vf0h01MypL for ; Fri, 18 Jan 2013 12:28:55 -0800 (PST) Received: from usevmg21.ericsson.net (unknown [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 24CD921F86FD for ; Fri, 18 Jan 2013 12:28:54 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-5d-50f9b085b998 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B4.9B.03705.580B9F05; Fri, 18 Jan 2013 21:28:54 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Fri, 18 Jan 2013 15:28:53 -0500 From: Gregory Mirsky To: "Sami Boutros (sboutros)" , "David Ball -X (daviball - Ensoft Ltd at Cisco)" Thread-Topic: [Editorial Errata Reported] RFC6435 (3429) Thread-Index: AQHN9YjKXqS8nJERl0GBsX5ZHKx9iJhPhUNw Date: Fri, 18 Jan 2013 20:28:52 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11204F34D@eusaamb103.ericsson.se> References: <20130110175648.GI32428@cisco.com> <021701cdf42d$72200860$56601920$@olddog.co.uk> <50F7F553.1070509@alcatel-lucent.com> <20130117170933.GN25804@cisco.com> <50F83247.7050000@alcatel-lucent.com> <20130117174102.GP25804@cisco.com> <003a01cdf56c$51c599f0$f550cdd0$@olddog.co.uk> <20130118124227.GV25804@cisco.com> <473DA00BC97EE04A9B4EE875F48CE5F113356D91@xmb-rcd-x08.cisco.com> In-Reply-To: <473DA00BC97EE04A9B4EE875F48CE5F113356D91@xmb-rcd-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11204F34Deusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXSPn27bhp8BBmcOCVjsmziZ3eL+Cy+L W0tXslpceHSc2WLRpStsFn9XXGGxODblE6MDu8eU3xtZPZYs+cnkcb3pKrvHrFmHmTzW7PvB EsAaxWWTkpqTWZZapG+XwJXxY/oXxoLDzSwVh++dYWxg3LONuYuRk0NCwERiwumnLBC2mMSF e+vZuhi5OIQEjjBKnLvZzAjhLGeU2NR4lB2kik3ASOLFxh4wW0SgWmLK7pXsIEXMAq8YJWbs mgaWEBYwlzjxbgkzRJGFxPlz31khbCOJM6cWM4LYLAKqEkufNYKt5hXwluiZvQEsLiSwmUXi d1MCiM0p4Cvx+MpZsDmMQOd9P7WGCcRmFhCXuPVkPhPE2QISS/ach3pHVOLl43+sELayxPc5 j1gg6vMltr+azAyxS1Di5MwnLBMYRWchGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjM hCy+gJF9FSNHaXFqWW66keEmRmCsHpNgc9zBuOCT5SFGaQ4WJXHeUNcLAUIC6YklqdmpqQWp RfFFpTmpxYcYmTg4pRoYHZ51r4qYfCOQY/s2yyjdLbMquq7PSH677+7igxG/nS7M639tdq1m c2pI0hFpnztfT/zhibhftFFVjjtB4WOAZf2jx/xsdroVF/m+czDtVX0V2S76J7rc9a4rf8K7 Itc/F9k+K6kv+1LnvfThdb+O0xNFme3cd5re8LZxKNrH+qfx16vcb9ozlViKMxINtZiLihMB 39LIT6MCAAA= Cc: "" , "" , "" , "Siva Sivabalan \(msiva\)" , "" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 18 Jan 2013 20:28:58 -0000 --_000_7347100B5761DC41A166AC17F22DF11204F34Deusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sami, I think that the "This is done using management." can not and should not be= interpreted as "The Loopback function MUST be done via management only." I= would ask you to consider changing it to "This can be done using managemen= t plane.", thus leaving non-management means for further consideration. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sam= i Boutros (sboutros) Sent: Friday, January 18, 2013 6:33 AM To: David Ball -X (daviball - Ensoft Ltd at Cisco) Cc: ; ; Siva Sivabalan (msiva); ; Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) Looks good to me. I agree that in the new text it is clear that we are not requiring a MIP or= MEP at the node that perform the loopback function along the transport pat= h As well I feel it is clear the way I read it, that 1- A MEP is required as a must at both ends of the transport path to perfor= m the transport path lock function prior to setting up the loopback on a no= de along the transport path. 2- The Loopback function MUST be done via management only. If the above is not clear to others while reading the new text, then we may= need to update it. Thanks, Sami On Jan 18, 2013, at 4:42 AM, David Ball wrote: > Hi Adrian, > > I think we are done, here is the updated text: > > =3D=3D=3D=3D > > Section 4, paragraphs 2-7; old text: > > The loopback function is used to test the integrity of a transport > path from a MEP up any other node in the same MEG. This is achieved > by setting the target node into loopback mode, and transmitting a > pattern of test data from the MEP. The target node loops all > received data back toward the originator, and the MEP extracts the > test data and compares it with what it sent. > > Loopback is a function that enables a receiving MEP or MIP to return > traffic to the sending MEP when in the loopback state. This state > corresponds to the situation where, at a given node, a forwarding > plane loop is configured, and the incoming direction of a transport > path is cross-connected to the outgoing reverse direction. > Therefore, except in the case of early TTL expiry, traffic sent by > the source will be received by that source. > > Data-plane loopback is an out-of-service function, as required in > Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic > (including user data and OAM). The traffic can be originated from > one internal point at the ingress of a transport path within an > interface or inserted from an input port of an interface using > external test equipment. The traffic is looped back unmodified > (other than normal per-hop processing such as TTL decrement) in the > direction of the point of origin by an interface at either an > intermediate node or a terminating node. > > It should be noted that the data-plane loopback function itself is > applied to data-plane loopback points residing on different > interfaces from MIPs/MEPs. All traffic (including both payload and > OAM) received on the looped back interface is sent on the reverse > direction of the transport path. > > For data-plane loopback at an intermediate point in a transport path, > the loopback needs to be configured to occur at either the ingress or > egress interface. This is done using management. > > The management plane can be used to configure the loopback function. > The management plane must ensure that the two MEPs are locked before > it requests setting MEP or MIP in the loopback state. > > New text: > > The loopback function is used to test the integrity of a transport > path from a MEP to any other node along the same transport path. > This is achieved by setting the target node into loopback mode for > that transport path, and transmitting a pattern of test data from > the MEP. The target node loops all data received on the transport > path back towards the sending MEP, which extracts the test data > and compares it with what it sent. > > Loopback is a function that enables a given node on a transport > path to return traffic to the sending MEP for that transport path > when in the loopback mode. This mode corresponds to the situation > where, at a given node, a forwarding plane loop is configured, and > the incoming direction of a transport path is cross-connected to the > outgoing reverse direction. Therefore, except in the case of early > TTL expiry, traffic sent by the source will be received by that > source. > > Data-plane loopback is an out-of-service function, as required in > Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic > (including user data and OAM). The traffic can be originated from > one internal point at the ingress of a transport path within an > interface or inserted from an input port of an interface using > external test equipment. The traffic is looped back unmodified > (other than normal per-hop processing such as TTL decrement) in the > direction of the point of origin by an interface at either an > intermediate node or a terminating node. > > It should be noted that the data-plane loopback function for a > given transport path can be applied to data-plane loopback points > residing on interfaces where there may be no MEP or MIP for that > transport path. > > For data-plane loopback at an intermediate point in a transport path, > the loopback needs to be configured to occur at either the ingress or > egress interface. This is done using management. > > The management plane must ensure that the MEPs at either end of a > transport path are locked before it requests setting a given node of > that transport path into loopback mode. > > Notes: > > The existing text has caused confusion about exactly where the > loopback is applied. It does not clearly express the original > intent, which was that there may or may not be a MEP or MIP at the > loopback point. In particular, paragraphs 2 and 7 imply that the > loopback point must be at a MEP or MIP, while paragraph 5 implies > that loopback is performed at a point where there is no MEP or MIP. > > The new text updates paragraphs 2, 3, 5 and 7 to clarify that the > loopback may be performed at any point along the transport path, > whether or not there is a MEP or MIP there, and that the loopback > only applies to the transport path in question. Paragraphs 4 and 6 > are unchanged. > > =3D=3D=3D=3D > > > David > > > On Fri, Jan 18, 2013, Adrian Farrel wrote: >> OK, when we are done, can some write me an email that contains the >> text that would have been in the Errata Report if we had known then what= we know now? >> >> Then I will process the existing report and the new text. >> >> Thanks, >> Adrian >> >> From: VIGOUREUX, MARTIN (MARTIN) >> [mailto:martin.vigoureux@alcatel-lucent.com] >> Sent: 17 January 2013 20:00 >> To: David Ball >> Cc: adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan >> (msiva)'; raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart >> Bryant (stbryant)'; loa@pi.nu; 'George Swallow (swallow)'; >> rcallon@juniper.net; mpls@ietf.org >> Subject: RE: [Editorial Errata Reported] RFC6435 (3429) >> >> David, >> >> Yes it does. Thanks. >> I first thought of removing all references to MEP/MIP but should have >> given it a second thought. >> >> -m >> _____ >> >> De : David Ball >> Envoy? : 17/01/2013 18:41 >> ? : VIGOUREUX, MARTIN (MARTIN) >> Cc : adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan >> (msiva)'; raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart >> Bryant (stbryant)'; loa@pi.nu; 'George Swallow (swallow)'; >> rcallon@juniper.net; mpls@ietf.org Objet : Re: [Editorial Errata >> Reported] RFC6435 (3429) Hi Martin, >> >> Actually I think the last paragraph is talking about something >> different >> again: this is the MEPs that must be locked. >> >> Here is a transport path: >> >> |>-------x----------x-------<| >> --------->| >> <---------v >> A B C D >> >> A and D are the MEPs; B is the source of the test, C is the loopback >> point. >> >> As we have discussed, C could be a MIP, could be the MEP at D, or >> could be at a point that is neither a MIP or a MEP. >> >> A and D are the MEPs that must be locked during the test. >> >> My question was about point B: I think in the original text point B >> must always be the same as the MEP at point A; your proposal allows >> it to be some other point, eg at a MIP or at a point where there is >> no MIP or MEP. >> >> If we keep the original text about point B, and just change the text >> about point C, then combining with your proposal we get the following >> change: >> >> Old text: >> The loopback function is used to test the integrity of a transport >> path from a MEP up any other node in the same MEG. This is achieved >> by setting the target node into loopback mode, and transmitting a >> pattern of test data from the MEP. The target node loops all >> received data back toward the originator, and the MEP extracts the >> test data and compares it with what it sent. >> >> Loopback is a function that enables a receiving MEP or MIP to return >> traffic to the sending MEP when in the loopback state. >> >> [...] >> >> The management plane must ensure that the two MEPs are locked before >> it requests setting MEP or MIP in the loopback state. >> >> New text: >> The loopback function is used to test the integrity of a transport >> path from a MEP to any other node along the same transport path. >> This is achieved by setting the target node into loopback mode for >> that transport path, and transmitting a pattern of test data from >> the MEP. The target node loops all data received on the transport >> path back towards the sending MEP, which extracts the test data >> and compares it with what it sent. >> >> Loopback is a function that enables a given node of a transport >> path to return traffic to the sending MEP for that transport path >> when in the loopback mode. >> >> [...] >> >> The management plane must ensure that the MEPs at either end of a >> transport path are locked before it requests setting a given node of >> that transport path into loopback mode. >> >> Does this work? >> >> >> David >> >> >> On Thu, Jan 17, 2013, Martin Vigoureux wrote: >>> David, >>> >>> agreed, and in fact this is consistent with the fact I kept MEP in >>> the last paragraph I changed. >>> >>> -m >>> >>> >>> Le 17/01/2013 18:09, David Ball a ?crit : >>>> Thanks Martin. >>>> >>>> Regarding the first paragraph, I agree with your change to add "for >>>> that transport path", that does make it clearer. >>>> >>>> Regarding the other paragraphs: We have agreed that the intent was >>>> that the point doing the loopback does not have to be a MEP or MIP, >>>> but your proposal also seems to change it so that the point >>>> transmitting the test data does not have to be a MEP. I think the >>>> original text was consistent that the test was done *from* a MEP; >>>> the question was whether it was done from a MEP *to another >>>> MEP/MIP*, or from a MEP *to an arbitrary point*. >>>> >>>> So you might be right that the text describing the source of the >>>> test should also be changed, but I think that is a slightly separate i= ssue. >>>> It is probably safest to keep the changes to a minimum and just fix >>>> the description of the point that is doing the loopback, ie the >>>> target of the test. >>>> >>>> Do you agree? >>>> >>>> >>>> David >>>> >>>> >>>> On Thu, Jan 17, 2013, Martin Vigoureux wrote: >>>>> Adrian, yes, we are. >>>>> >>>>> So, David, >>>>> >>>>> I am fine with your suggested text which says: >>>>> It should be noted that the data-plane loopback function for a >>>>> given transport path can be applied to data-plane loopback points >>>>> residing on interfaces where there may be no corresponding MEP or >>>>> MIP. >>>>> >>>>> I was thinking of: >>>>> s/may be no corresponding MEP or MIP./may be no MEP or MIP for >>>>> that transport path./ but this is optional. >>>>> >>>>> The new text will replace: >>>>> It should be noted that the data-plane loopback function itself is >>>>> applied to data-plane loopback points residing on different >>>>> interfaces from MIPs/MEPs. >>>>> >>>>> >>>>> Regarding the other paragraphs: >>>>> The loopback function is used to test the integrity of a transport >>>>> path from a MEP up any other node in the same MEG. This is achieve= d >>>>> by setting the target node into loopback mode, and transmitting a >>>>> pattern of test data from the MEP. The target node loops all >>>>> received data back toward the originator, and the MEP extracts the >>>>> test data and compares it with what it sent. >>>>> >>>>> Loopback is a function that enables a receiving MEP or MIP to retur= n >>>>> traffic to the sending MEP when in the loopback state. >>>>> >>>>> [...] >>>>> >>>>> The management plane must ensure that the two MEPs are locked befor= e >>>>> it requests setting MEP or MIP in the loopback state. >>>>> >>>>> >>>>> They could be changed into: >>>>> The loopback function is used to test the integrity of a transport >>>>> path. This is achieved by setting a given node into loopback mode >>>>> for a given transport path, and sending over it a pattern of test >>>>> data. The node in loopback mode loops all test data received on th= e >>>>> transport path back towards the sender, which extracts the test >>>>> data and compares it with what it sent. >>>>> >>>>> Loopback is a function which enables a given node of a transport >>>>> path, when in the loopback mode, to return traffic to the sender of >>>>> that traffic. >>>>> >>>>> [...] >>>>> >>>>> The management plane must ensure that the MEPs of a transport path >>>>> are locked before it requests setting a given node of that transpor= t >>>>> path in loopback mode. >>>>> >>>>> Let me know. >>>>> -m >>>>> >>>>> Le 16/01/2013 22:07, Adrian Farrel a ?crit : >>>>>> All, are we getting any closer to agreeing what we all intended to s= ay? >>>>>> >>>>>> Once we have that, I can work out what to do with the Errata Report. >>>>>> >>>>>> Thanks, >>>>>> Adrian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Ball [mailto:daviball@cisco.com] >>>>>>> Sent: 10 January 2013 17:57 >>>>>>> To: VIGOUREUX, MARTIN (MARTIN) >>>>>>> Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan >>>>>>> (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart >>>>>>> Bryant (stbryant); loa@pi.nu; George Swallow (swallow); >>>>>>> rcallon@juniper.net; mpls@ietf.org >>>>>>> Subject: Re: [Editorial Errata Reported] RFC6435 (3429) >>>>>>> >>>>>>> Hi Martin, >>>>>>> >>>>>>> Ah, right I see: since the loopback is locally configured, there >>>>>>> is no need for a MEP/MIP to send/receive OAM frames - but there >>>>>>> may be a MEP/MIP. >>>>>>> >>>>>>> So would this work to clarify the text? >>>>>>> "It should be noted that the data-plane loopback function for a >>>>>>> given transport path can be applied to data-plane loopback points >>>>>>> residing on interfaces where there may be no corresponding MEP or >>>>>>> MIP." >>>>>>> >>>>>>> For completeness, the references to "MEP or MIP" in paragraphs 3 >>>>>>> and 7 of section 4 would also need to be changed, to instead >>>>>>> refer to the transport path that is being put in to loopback. >>>>>>> >>>>>>> As another data point, I found this text in RFC6371 section 6.3.2: >>>>>>> "It should be noted that data-plane loopback function itself is >>>>>>> applied to data-plane loopback points that can reside on differen= t >>>>>>> interfaces from MIPs/MEPs." >>>>>>> Note the critical difference compared to RFC6435: "that can reside" >>>>>>> instead of "residing". >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: >>>>>>>> Sami, >>>>>>>> >>>>>>>> Thanks. Yet, I am not sure David's interpretation and mine exactly= match. >>>>>>>> David, correct me if I am wrong. For me it says that we can do >>>>>>>> loopback on different interfaces (for different LSPs) but >>>>>>>> implies that there is a mip/mep for that lsp on that interface, >>>>>>>> while my interpretation is that the presence of a mip/mep for >>>>>>>> that lsp on that interface is not needed. >>>>>>>> >>>>>>>> -m >>>>>>>> ________________________________ De : Sami Boutros (sboutros) >>>>>>>> Envoy? : 09/01/2013 19:00 ? : VIGOUREUX, MARTIN (MARTIN) Cc : >>>>>>>> adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at >>>>>>>> Cisco); >>>>>> Siva >>>>>>> Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; >>>>>>> Stewart Bryant (stbryant); loa@pi.nu; George Swallow (swallow); >> rcallon@juniper.net; >>>>>>> mpls@ietf.org >>>>>>>> Objet : Re: [Editorial Errata Reported] RFC6435 (3429) >>>>>>>> >>>>>>>> I agree with Martin, the text proposed by David describe more >>>>>>>> accurately >>>>>> what >>>>>>> we meant. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Sami >>>>>>>> On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: >>>>>>>> >>>>>>>>> Adrian, David, >>>>>>>>> >>>>>>>>> what I think we meant here was that a loop-back function could >>>>>>>>> be done >> on >>>>>>> an interface regardless of the presence of a MIP/MEP on that interf= ace. >> Yet, I >>>>>>> have to admit that MIP and MEP are used in Section 4 of RFC6435, >>>>>>> thus >> surely >>>>>>> causing confusion. >>>>>>>>> >>>>>>>>> I'd welcome the views/souvenirs of my co-authors. >>>>>>>>> >>>>>>>>> -m >>>>>>>>> >>>>>>>>> Le 12/12/2012 19:17, Adrian Farrel a ?crit : >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Authors of RFC 6435: I need to hear from you that you meant >>>>>>>>>> the text >> that >>>>>>> David >>>>>>>>>> suggests. It is very clearly not what you wrote and, if you >>>>>>>>>> meant >>>>>> something >>>>>>>>>> different, it is clear why people are confused! >>>>>>>>>> >>>>>>>>>> Working group: I need to hear from you that you agree with >>>>>>>>>> David's interpretation and support his proposed change. >>>>>>>>>> >>>>>>>>>> Only then will I try to work out whether this is a "typo" >>>>>>>>>> worthy of an >>>>>> errata >>>>>>>>>> report, or a technical change needing a revised RFC. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Adrian >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>>>>>>> Sent: 12 December 2012 17:45 >>>>>>>>>>> To: sboutros@cisco.com; msiva@cisco.com; >>>>>>>>>>> raggarwa_1@yahoo.com; martin.vigoureux@alcatel-lucent.com; >>>>>>>>>>> dai.xuehui@zte.com.cn; stbryant@cisco.com; >>>>>>>>>>> adrian@olddog.co.uk; loa@pi.nu; >>>>>>> swallow@cisco.com; >>>>>>>>>>> rcallon@juniper.net >>>>>>>>>>> Cc: daviball@cisco.com; mpls@ietf.org; >>>>>>>>>>> rfc-editor@rfc-editor.org >>>>>>>>>>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The following errata report has been submitted for RFC6435, >>>>>>>>>>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>>>>>>>>>> >>>>>>>>>>> -------------------------------------- >>>>>>>>>>> You may review the report below and at: >>>>>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435 >> >> &eid=3D3429 >>>>>>>>>>> >>>>>>>>>>> -------------------------------------- >>>>>>>>>>> Type: Editorial >>>>>>>>>>> Reported by: David Ball >>>>>>>>>>> >>>>>>>>>>> Section: 4 (para 5) >>>>>>>>>>> >>>>>>>>>>> Original Text >>>>>>>>>>> ------------- >>>>>>>>>>> It should be noted that the data-plane loopback function >>>>>>>>>>> itself is >>>>>> applied to >>>>>>>>>> data- >>>>>>>>>>> plane loopback points residing on different interfaces from MIP= s/MEPs. >>>>>>>>>>> >>>>>>>>>>> Corrected Text >>>>>>>>>>> -------------- >>>>>>>>>>> It should be noted that the data-plane loopback function may >>>>>>>>>>> be >> applied >>>>>> at >>>>>>>>>>> MIPs/MEPs on different interfaces for different LSPs. >>>>>>>>>>> >>>>>>>>>>> Notes >>>>>>>>>>> ----- >>>>>>>>>>> The existing text has caused confusion (specifically, among >>>>>>>>>>> experts in >>>>>> ITU-T >>>>>>>>>> SG15 >>>>>>>>>>> when discussing G.8121.2), in that it seems to suggest that >>>>>>>>>>> the >>>>>> interface >>>>>>>>>> where >>>>>>>>>>> the MIP/MEP is located may be a different interface to the >>>>>>>>>>> one where >> the >>>>>>>>>>> loopback is applied. >>>>>>>>>>> >>>>>>>>>>> Having spoken with some of the original authors, it seems >>>>>>>>>>> this was not >>>>>> the >>>>>>>>>> intent >>>>>>>>>>> of this sentence; the intent was to point out that as >>>>>>>>>>> different LSPs >>>>>> would >>>>>>>>>> have >>>>>>>>>>> MIPs/MEPs on different interfaces, the corresponding >>>>>>>>>>> loopback >> functions >>>>>>> would >>>>>>>>>>> also be applied on different interfaces. >>>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> -------------------------------------- >>>>>>>>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>>>>>>>>>> -------------------------------------- >>>>>>>>>>> Title : MPLS Transport Profile Lock Instruct and >> Loopback >>>>>>>>>> Functions >>>>>>>>>>> Publication Date : November 2011 >>>>>>>>>>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Ag= garwal, >>>>>> Ed., M. >>>>>>>>>> Vigoureux, >>>>>>>>>>> Ed., X. Dai, Ed. >>>>>>>>>>> Category : PROPOSED STANDARD >>>>>>>>>>> Source : Multiprotocol Label Switching >>>>>>>>>>> Area : Routing >>>>>>>>>>> Stream : IETF >>>>>>>>>>> Verifying Party : IESG >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> David Ball >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >> >> -- >> David Ball >> > > -- > David Ball > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_7347100B5761DC41A166AC17F22DF11204F34Deusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sami,
I think that the "This is done using management." can not an= d should not be interpreted as "The Loopback function MUST be done via= management only." I would ask you to consider changing it to "Th= is can be done using management plane.", thus leaving non-management means for further consideration.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: mpls-bounces@ietf.org [= mailto:mpls-bounces@ietf.org] On Beh= alf Of Sami Boutros (sboutros)
Sent: Friday, January 18, 2013 6:33 AM
To: David Ball -X (daviball - Ensoft Ltd at Cisco)
Cc: <mpls@ietf.org>; <dai.xuehui@zte.com.cn>; Siva Sivabal= an (msiva); <raggarwa_1@yahoo.com>; <rcallon@juniper.net>
Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429)
 
Looks good to me.
 
I agree that in the new text it is clear that we are not requiring a M= IP or MEP at the node that perform the loopback function along the transpor= t path
 
As well I feel it is clear the way I read it, that
 
1- A MEP is required as a must at both ends of the transport path to p= erform the transport path lock function prior to setting up the loopback on= a node along the transport path.
2- The Loopback function MUST be done via management only.
 
If the above is not clear to others while reading the new text, then w= e may need to update it.
 
Thanks,
 
Sami
On Jan 18, 2013, at 4:42 AM, David Ball wrote:
 
> Hi Adrian,
>
> I think we are done, here is the updated text:
>
> =3D=3D=3D=3D
>
> Section 4, paragraphs 2-7; old text:
>
>   The loopback function is used to test the integrity o= f a transport
>   path from a MEP up any other node in the same MEG.&nb= sp; This is achieved
>   by setting the target node into loopback mode, and tr= ansmitting a
>   pattern of test data from the MEP.  The target n= ode loops all
>   received data back toward the originator, and the MEP= extracts the
>   test data and compares it with what it sent.
>
>   Loopback is a function that enables a receiving MEP o= r MIP to return
>   traffic to the sending MEP when in the loopback state= .  This state
>   corresponds to the situation where, at a given node, = a forwarding
>   plane loop is configured, and the incoming direction = of a transport
>   path is cross-connected to the outgoing reverse direc= tion.
>   Therefore, except in the case of early TTL expiry, tr= affic sent by
>   the source will be received by that source.
>
>   Data-plane loopback is an out-of-service function, as= required in
>   Section 2.2.5 of RFC 5860 [1].  This function lo= ops back all traffic
>   (including user data and OAM).  The traffic can = be originated from
>   one internal point at the ingress of a transport path= within an
>   interface or inserted from an input port of an interf= ace using
>   external test equipment.  The traffic is looped = back unmodified
>   (other than normal per-hop processing such as TTL dec= rement) in the
>   direction of the point of origin by an interface at e= ither an
>   intermediate node or a terminating node.
>
>   It should be noted that the data-plane loopback funct= ion itself is
>   applied to data-plane loopback points residing on dif= ferent
>   interfaces from MIPs/MEPs.  All traffic (includi= ng both payload and
>   OAM) received on the looped back interface is sent on= the reverse
>   direction of the transport path.
>
>   For data-plane loopback at an intermediate point in a= transport path,
>   the loopback needs to be configured to occur at eithe= r the ingress or
>   egress interface.  This is done using management= .
>
>   The management plane can be used to configure the loo= pback function.
>   The management plane must ensure that the two MEPs ar= e locked before
>   it requests setting MEP or MIP in the loopback state.=
>
> New text:
>
>   The loopback function is used to test the integrity o= f a transport
>   path from a MEP to any other node along the same tran= sport path. 
>   This is achieved by setting the target node into loop= back mode for
>   that transport path, and  transmitting a pattern= of test data from
>   the MEP.  The target node loops all data receive= d on the transport
>   path back towards the sending MEP, which extracts the= test data
>   and compares it with what it sent.
>
>   Loopback is a function that enables a given node on a= transport
>   path to return traffic to the sending MEP for that tr= ansport path
>   when in the loopback mode.  This mode correspond= s to the situation
>   where, at a given node, a forwarding plane loop is co= nfigured, and
>   the incoming direction of a transport path is cross-c= onnected to the
>   outgoing reverse direction.  Therefore, except i= n the case of early
>   TTL expiry, traffic sent by the source will be receiv= ed by that
>   source.
>
>   Data-plane loopback is an out-of-service function, as= required in
>   Section 2.2.5 of RFC 5860 [1].  This function lo= ops back all traffic
>   (including user data and OAM).  The traffic can = be originated from
>   one internal point at the ingress of a transport path= within an
>   interface or inserted from an input port of an interf= ace using
>   external test equipment.  The traffic is looped = back unmodified
>   (other than normal per-hop processing such as TTL dec= rement) in the
>   direction of the point of origin by an interface at e= ither an
>   intermediate node or a terminating node.
>
>   It should be noted that the data-plane loopback funct= ion for a
>   given transport path can be applied to data-plane loo= pback points
>   residing on interfaces where there may be no MEP or M= IP for that
>   transport path.
>
>   For data-plane loopback at an intermediate point in a= transport path,
>   the loopback needs to be configured to occur at eithe= r the ingress or
>   egress interface.  This is done using management= .
>
>   The management plane must ensure that the MEPs at eit= her end of a
>   transport path are locked before it requests setting = a given node of
>   that transport path into loopback mode.
 
>
> Notes:
>
>   The existing text has caused confusion about exactly = where the
>   loopback is applied.  It does not clearly expres= s the original
>   intent, which was that there may or may not be a MEP = or MIP at the
>   loopback point.  In particular, paragraphs 2 and= 7 imply that the
>   loopback point must be at a MEP or MIP, while paragra= ph 5 implies
>   that loopback is performed at a point where there is = no MEP or MIP.
>
>   The new text updates paragraphs 2, 3, 5 and 7 to clar= ify that the
>   loopback may be performed at any point along the tran= sport path,
>   whether or not there is a MEP or MIP there, and that = the loopback
>   only applies to the transport path in question. = Paragraphs 4 and 6
>   are unchanged.
>
> =3D=3D=3D=3D
>
>
>        David
>
>
> On Fri, Jan 18, 2013, Adrian Farrel wrote:
>> OK, when we are done, can some write me an email that contain= s the
>> text that would have been in the Errata Report if we had know= n then what we know now?
>>
>> Then I will process the existing report and the new text.
>>
>> Thanks,
>> Adrian
>>
>> From: VIGOUREUX, MARTIN (MARTIN)
>> Sent: 17 January 2013 20:00
>> To: David Ball
>> Cc: adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Siv= abalan
>> (msiva)'; raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewa= rt
>> Bryant (stbryant)'; loa@pi.nu; 'George Swallow (swallow)';
>> rcallon@juniper.net; mpls@ietf.org
>> Subject: RE: [Editorial Errata Reported] RFC6435 (3429)
>>
>> David,
>>
>> Yes it does. Thanks.
>> I first thought of removing all references to MEP/MIP but sho= uld have
>> given it a second thought.
>>
>> -m
>>  _____
>>
>> De : David Ball
>> Envoy? : 17/01/2013 18:41
>> ? : VIGOUREUX, MARTIN (MARTIN)
>> Cc : adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Si= vabalan
>> (msiva)'; raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewa= rt
>> Bryant (stbryant)'; loa@pi.nu; 'George Swallow (swallow)';
>> rcallon@juniper.net; mpls@ietf.org Objet : Re: [Editorial Err= ata
>> Reported] RFC6435 (3429) Hi Martin,
>>
>> Actually I think the last paragraph is talking about somethin= g
>> different
>> again: this is the MEPs that must be locked.
>>
>> Here is a transport path:
>>
>>  |>-------x----------x-------<|
>>          &n= bsp; --------->|
>>          &n= bsp; <---------v
>>  A        B &nbs= p;        C     = ;   D
>>
>> A and D are the MEPs; B is the source of the test, C is the l= oopback
>> point.
>>
>> As we have discussed, C could be a MIP, could be the MEP at D= , or
>> could be at a point that is neither a MIP or a MEP.
>>
>> A and D are the MEPs that must be locked during the test.
>>
>> My question was about point B: I think in the original text p= oint B
>> must always be the same as the MEP at point A; your proposal = allows
>> it to be some other point, eg at a MIP or at a point where th= ere is
>> no MIP or MEP.
>>
>> If we keep the original text about point B, and just change t= he text
>> about point C, then combining with your proposal we get the f= ollowing
>> change:
>>
>> Old text:
>>   The loopback function is used to test the integri= ty of a transport
>>   path from a MEP up any other node in the same MEG= .  This is achieved
>>   by setting the target node into loopback mode, an= d transmitting a
>>   pattern of test data from the MEP.  The targ= et node loops all
>>   received data back toward the originator, and the= MEP extracts the
>>   test data and compares it with what it sent.
>>
>>   Loopback is a function that enables a receiving M= EP or MIP to return
>>   traffic to the sending MEP when in the loopback s= tate.
>>
>>   [...]
>>
>>   The management plane must ensure that the two MEP= s are locked before
>>   it requests setting MEP or MIP in the loopback st= ate.
>>
>> New text:
>>   The loopback function is used to test the integri= ty of a transport
>>   path from a MEP to any other node along the same = transport path. 
>>   This is achieved by setting the target node into = loopback mode for
>>   that transport path, and  transmitting a pat= tern of test data from
>>   the MEP.  The target node loops all data rec= eived on the transport
>>   path back towards the sending MEP, which extracts= the test data
>>   and compares it with what it sent.
>>
>>   Loopback is a function that enables a given node = of a transport
>>   path to return traffic to the sending MEP for tha= t transport path
>>   when in the loopback mode.
>>
>>   [...]
>>
>>   The management plane must ensure that the MEPs at= either end of a
>>   transport path are locked before it requests sett= ing a given node of
>>   that transport path into loopback mode.
>>
>> Does this work?
>>
>>
>>        David
>>
>>
>> On Thu, Jan 17, 2013, Martin Vigoureux wrote:
>>> David,
>>>
>>> agreed, and in fact this is consistent with the fact I ke= pt MEP in
>>> the last paragraph I changed.
>>>
>>> -m
>>>
>>>
>>> Le 17/01/2013 18:09, David Ball a ?crit :
>>>> Thanks Martin.
>>>>
>>>> Regarding the first paragraph, I agree with your chan= ge to add "for
>>>> that transport path", that does make it clearer.=
>>>>
>>>> Regarding the other paragraphs: We have agreed that t= he intent was
>>>> that the point doing the loopback does not have to be= a MEP or MIP,
>>>> but your proposal also seems to change it so that the= point
>>>> transmitting the test data does not have to be a MEP.=   I think the
>>>> original text was consistent that the test was done *= from* a MEP;
>>>> the question was whether it was done from a MEP *to a= nother
>>>> MEP/MIP*, or from a MEP *to an arbitrary point*.
>>>>
>>>> So you might be right that the text describing the so= urce of the
>>>> test should also be changed, but I think that is a sl= ightly separate issue.
>>>> It is probably safest to keep the changes to a minimu= m and just fix
>>>> the description of the point that is doing the loopba= ck, ie the
>>>> target of the test.
>>>>
>>>> Do you agree?
>>>>
>>>>
>>>>    David
>>>>
>>>>
>>>> On Thu, Jan 17, 2013, Martin Vigoureux wrote:
>>>>> Adrian, yes, we are.
>>>>>
>>>>> So, David,
>>>>>
>>>>> I am fine with your suggested text which says:
>>>>>   It should be noted that the data-plan= e loopback function for a
>>>>>   given transport path can be applied t= o data-plane loopback points
>>>>>   residing on interfaces where there ma= y be no corresponding MEP or
>>>>>   MIP.
>>>>>
>>>>> I was thinking of:
>>>>> s/may be no corresponding MEP or MIP./may be no M= EP or MIP for
>>>>> that transport path./ but this is optional.
>>>>>
>>>>> The new text will replace:
>>>>>   It should be noted that the data-plan= e loopback function itself is
>>>>>   applied to data-plane loopback points= residing on different
>>>>>   interfaces from MIPs/MEPs.
>>>>>
>>>>>
>>>>> Regarding the other paragraphs:
>>>>>   The loopback function is used to test= the integrity of a transport
>>>>>   path from a MEP up any other node in = the same MEG.  This is achieved
>>>>>   by setting the target node into loopb= ack mode, and transmitting a
>>>>>   pattern of test data from the MEP.&nb= sp; The target node loops all
>>>>>   received data back toward the origina= tor, and the MEP extracts the
>>>>>   test data and compares it with what i= t sent.
>>>>>
>>>>>   Loopback is a function that enables a= receiving MEP or MIP to return
>>>>>   traffic to the sending MEP when in th= e loopback state.
>>>>>
>>>>>   [...]
>>>>>
>>>>>   The management plane must ensure that= the two MEPs are locked before
>>>>>   it requests setting MEP or MIP in the= loopback state.
>>>>>
>>>>>
>>>>> They could be changed into:
>>>>>   The loopback function is used to test= the integrity of a transport
>>>>>   path.  This is achieved by setti= ng a given node into loopback mode
>>>>>   for a given transport path, and sendi= ng over it a pattern of test
>>>>>   data.  The node in loopback mode= loops all test data received on the
>>>>>   transport path back towards the sende= r, which extracts the test
>>>>>   data and compares it with what it sen= t.
>>>>>
>>>>>   Loopback is a function which enables = a given node of a transport
>>>>>   path, when in the loopback mode, to r= eturn traffic to the sender of
>>>>>   that traffic.
>>>>>
>>>>>   [...]
>>>>>
>>>>>   The management plane must ensure that= the MEPs of a transport path
>>>>>   are locked before it requests setting= a given node of that transport
>>>>>   path in loopback mode.
>>>>>
>>>>> Let me know.
>>>>> -m
>>>>>
>>>>> Le 16/01/2013 22:07, Adrian Farrel a ?crit :
>>>>>> All, are we getting any closer to agreeing wh= at we all intended to say?
>>>>>>
>>>>>> Once we have that, I can work out what to do = with the Errata Report.
>>>>>>
>>>>>> Thanks,
>>>>>> Adrian
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> Sent: 10 January 2013 17:57
>>>>>>> To: VIGOUREUX, MARTIN (MARTIN)
>>>>>>> Cc: Sami Boutros (sboutros); adrian@olddo= g.co.uk; Siva Sivabalan
>>>>>>> (msiva); raggarwa_1@yahoo.com; dai.xuehui= @zte.com.cn; Stewart
>>>>>>> Bryant (stbryant); loa@pi.nu; George Swal= low (swallow);
>>>>>>> rcallon@juniper.net; mpls@ietf.org
>>>>>>> Subject: Re: [Editorial Errata Reported] = RFC6435 (3429)
>>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> Ah, right I see: since the loopback is lo= cally configured, there
>>>>>>> is no need for a MEP/MIP to send/receive = OAM frames - but there
>>>>>>> may be a MEP/MIP.
>>>>>>>
>>>>>>> So would this work to clarify the text?
>>>>>>>  "It should be noted that the d= ata-plane loopback function for a
>>>>>>>   given transport path can be a= pplied to data-plane loopback points
>>>>>>>   residing on interfaces where = there may be no corresponding MEP or
>>>>>>>   MIP."
>>>>>>>
>>>>>>> For completeness, the references to "= ;MEP or MIP" in paragraphs 3
>>>>>>> and 7 of section 4 would also need to be = changed, to instead
>>>>>>> refer to the transport path that is being= put in to loopback.
>>>>>>>
>>>>>>> As another data point, I found this text = in RFC6371 section 6.3.2:
>>>>>>>  "It should be noted that data-= plane loopback function itself is
>>>>>>>   applied to data-plane loopbac= k points that can reside on different
>>>>>>>   interfaces from MIPs/MEPs.&qu= ot;
>>>>>>> Note the critical difference compared to = RFC6435: "that can reside"
>>>>>>> instead of "residing".
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (= MARTIN) wrote:
>>>>>>>> Sami,
>>>>>>>>
>>>>>>>> Thanks. Yet, I am not sure David's in= terpretation and mine exactly match.
>>>>>>>> David, correct me if I am wrong. For = me it says that we can do
>>>>>>>> loopback on different interfaces (for= different LSPs) but
>>>>>>>> implies that there is a mip/mep for t= hat lsp on that interface,
>>>>>>>> while my interpretation is that the p= resence of a mip/mep for
>>>>>>>> that lsp on that interface is not nee= ded.
>>>>>>>>
>>>>>>>> -m
>>>>>>>> ________________________________ De := Sami Boutros (sboutros)
>>>>>>>> Envoy? : 09/01/2013 19:00 ? : VIGOURE= UX, MARTIN (MARTIN) Cc :
>>>>>>>> adrian@olddog.co.uk; David Ball -X (d= aviball - Ensoft Ltd at
>>>>>>>> Cisco);
>>>>>> Siva
>>>>>>> Sivabalan (msiva); raggarwa_1@yahoo.com; = dai.xuehui@zte.com.cn;
>>>>>>> Stewart Bryant (stbryant); loa@pi.nu; Geo= rge Swallow (swallow);
>> rcallon@juniper.net;
>>>>>>> mpls@ietf.org
>>>>>>>> Objet : Re: [Editorial Errata Reporte= d] RFC6435 (3429)
>>>>>>>>
>>>>>>>> I agree with Martin, the text propose= d by David describe more
>>>>>>>> accurately
>>>>>> what
>>>>>>> we meant.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Sami
>>>>>>>> On Jan 9, 2013, at 6:18 AM, Martin Vi= goureux wrote:
>>>>>>>>
>>>>>>>>> Adrian, David,
>>>>>>>>>
>>>>>>>>> what I think we meant here was th= at a loop-back function could
>>>>>>>>> be done
>> on
>>>>>>> an interface regardless of the presence o= f a MIP/MEP on that interface.
>> Yet, I
>>>>>>> have to admit that MIP and MEP are used i= n Section 4 of RFC6435,
>>>>>>> thus
>> surely
>>>>>>> causing confusion.
>>>>>>>>>
>>>>>>>>> I'd welcome the views/souvenirs o= f my co-authors.
>>>>>>>>>
>>>>>>>>> -m
>>>>>>>>>
>>>>>>>>> Le 12/12/2012 19:17, Adrian Farre= l a ?crit :
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Authors of RFC 6435: I need t= o hear from you that you meant
>>>>>>>>>> the text
>> that
>>>>>>> David
>>>>>>>>>> suggests. It is very clearly = not what you wrote and, if you
>>>>>>>>>> meant
>>>>>> something
>>>>>>>>>> different, it is clear why pe= ople are confused!
>>>>>>>>>>
>>>>>>>>>> Working group: I need to hear= from you that you agree with
>>>>>>>>>> David's interpretation and su= pport his proposed change.
>>>>>>>>>>
>>>>>>>>>> Only then will I try to work = out whether this is a "typo"
>>>>>>>>>> worthy of an
>>>>>> errata
>>>>>>>>>> report, or a technical change= needing a revised RFC.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Adrian
>>>>>>>>>>
>>>>>>>>>>> -----Original Message----= -
>>>>>>>>>>> Sent: 12 December 2012 17= :45
>>>>>>>>>>> To: sboutros@cisco.com; m= siva@cisco.com;
>>>>>>>>>>> raggarwa_1@yahoo.com; mar= tin.vigoureux@alcatel-lucent.com;
>>>>>>>>>>> dai.xuehui@zte.com.cn; st= bryant@cisco.com;
>>>>>>>>>>> adrian@olddog.co.uk; loa@= pi.nu;
>>>>>>> swallow@cisco.com;
>>>>>>>>>>> rcallon@juniper.net
>>>>>>>>>>> Cc: daviball@cisco.com; m= pls@ietf.org;
>>>>>>>>>>> rfc-editor@rfc-editor.org=
>>>>>>>>>>> Subject: [Editorial Errat= a Reported] RFC6435 (3429)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The following errata repo= rt has been submitted for RFC6435,
>>>>>>>>>>> "MPLS Transport Prof= ile Lock Instruct and Loopback Functions".
>>>>>>>>>>>
>>>>>>>>>>> -------------------------= -------------
>>>>>>>>>>> You may review the report= below and at:
>> &eid=3D3429
>>>>>>>>>>>
>>>>>>>>>>> -------------------------= -------------
>>>>>>>>>>> Type: Editorial
>>>>>>>>>>> Reported by: David Ball&l= t;daviball@cisco.com>
>>>>>>>>>>>
>>>>>>>>>>> Section: 4 (para 5)
>>>>>>>>>>>
>>>>>>>>>>> Original Text
>>>>>>>>>>> -------------
>>>>>>>>>>> It should be noted that t= he data-plane loopback function
>>>>>>>>>>> itself is
>>>>>> applied to
>>>>>>>>>> data-
>>>>>>>>>>> plane loopback points res= iding on different interfaces from MIPs/MEPs.
>>>>>>>>>>>
>>>>>>>>>>> Corrected Text
>>>>>>>>>>> --------------
>>>>>>>>>>> It should be noted that t= he data-plane loopback function may
>>>>>>>>>>> be
>> applied
>>>>>> at
>>>>>>>>>>> MIPs/MEPs on different in= terfaces for different LSPs.
>>>>>>>>>>>
>>>>>>>>>>> Notes
>>>>>>>>>>> -----
>>>>>>>>>>> The existing text has cau= sed confusion (specifically, among
>>>>>>>>>>> experts in
>>>>>> ITU-T
>>>>>>>>>> SG15
>>>>>>>>>>> when discussing G.8121.2)= , in that it seems to suggest that
>>>>>>>>>>> the
>>>>>> interface
>>>>>>>>>> where
>>>>>>>>>>> the MIP/MEP is located ma= y be a different interface to the
>>>>>>>>>>> one where
>> the
>>>>>>>>>>> loopback is applied.
>>>>>>>>>>>
>>>>>>>>>>> Having spoken with some o= f the original authors, it seems
>>>>>>>>>>> this was not
>>>>>> the
>>>>>>>>>> intent
>>>>>>>>>>> of this sentence; the int= ent was to point out that as
>>>>>>>>>>> different LSPs
>>>>>> would
>>>>>>>>>> have
>>>>>>>>>>> MIPs/MEPs on different in= terfaces, the corresponding
>>>>>>>>>>> loopback
>> functions
>>>>>>> would
>>>>>>>>>>> also be applied on differ= ent interfaces.
>>>>>>>>>>>
>>>>>>>>>>> Instructions:
>>>>>>>>>>> -------------
>>>>>>>>>>> This errata is currently = posted as "Reported". If necessary,
>>>>>>>>>>> please use "Reply Al= l" to discuss whether it should be
>>>>>>>>>>> verified or rejected. Whe= n a decision is reached, the
>>>>>>>>>>> verifying party (IESG) ca= n log in to change the status and edit the report, if necessary.
>>>>>>>>>>>
>>>>>>>>>>> -------------------------= -------------
>>>>>>>>>>> RFC6435 (draft-ietf-mpls-= tp-li-lb-08)
>>>>>>>>>>> -------------------------= -------------
>>>>>>>>>>> Title   &n= bsp;           : MPLS Tra= nsport Profile Lock Instruct and
>> Loopback
>>>>>>>>>> Functions
>>>>>>>>>>> Publication Date &nb= sp;  : November 2011
>>>>>>>>>>> Author(s)  &nbs= p;        : S. Boutros, Ed., S. Sivabala= n, Ed., R. Aggarwal,
>>>>>> Ed., M.
>>>>>>>>>> Vigoureux,
>>>>>>>>>>> Ed., X. Dai, Ed.
>>>>>>>>>>> Category   = ;         : PROPOSED STANDARD
>>>>>>>>>>> Source   &= nbsp;          : Multiprotocol= Label Switching
>>>>>>>>>>> Area   &nb= sp;            : Rou= ting
>>>>>>>>>>> Stream   &= nbsp;          : IETF
>>>>>>>>>>> Verifying Party &nbs= p;   : IESG
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> David Ball
>>>>>>> <daviball@cisco.com>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>> --
>> David Ball
>> <daviball@cisco.com>
>
> --
> David Ball
> <daviball@cisco.com>
 
_______________________________________________
mpls mailing list
mpls@ietf.org
 
--_000_7347100B5761DC41A166AC17F22DF11204F34Deusaamb103ericsso_-- From kvivek@broadcom.com Fri Jan 18 19:58:49 2013 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 CE08221F84D9 for ; Fri, 18 Jan 2013 19:58:49 -0800 (PST) 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 cnCjdLxTKmdA for ; Fri, 18 Jan 2013 19:58:48 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5961121F84D8 for ; Fri, 18 Jan 2013 19:58:48 -0800 (PST) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 18 Jan 2013 19:53:22 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.13) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 18 Jan 2013 19:58:37 -0800 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; Fri, 18 Jan 2013 19:58:16 -0800 From: "Vivek Kumar" To: "mpls@ietf.org" Thread-Topic: [Editorial Errata Reported] RFC6435 (3429) Thread-Index: Ac31+D+Crh7sRgwMSLaaReDr1DTY5w== Date: Sat, 19 Jan 2013 03:58:15 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC41DECB60A@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: 7CE4C7383Q44048751-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 19 Jan 2013 03:58:49 -0000 Hi David, The new text says "The traffic is looped back unmodified (other than nor= mal per-hop processing such as TTL decrement) in the direction of the poin= t of origin by an interface at either an intermediate node or a terminatin= g node". I feel if we are mentioning TTL processing as one exception , then we sho= uld also mention swapping src and destination Ethernet address when doing l= oopback . What do you say ? Regards, Vivek Message: 1 Date: Fri, 18 Jan 2013 20:28:52 +0000 From: Gregory Mirsky To: "Sami Boutros (sboutros)" , "David Ball -X (daviball - Ensoft Ltd at Cisco)" Cc: "" , "" , "" , "Siva Sivabalan \(msiva\)" , "" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) Message-ID: <7347100B5761DC41A166AC17F22DF11204F34D@eusaamb103.ericsson.se> Content-Type: text/plain; charset=3D"us-ascii" Hi Sami, I think that the "This is done using management." can not and should not be= interpreted as "The Loopback function MUST be done via management only." I= would ask you to consider changing it to "This can be done using managemen= t plane.", thus leaving non-management means for further consideration. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sam= i Boutros (sboutros) Sent: Friday, January 18, 2013 6:33 AM To: David Ball -X (daviball - Ensoft Ltd at Cisco) Cc: ; ; Siva Sivabalan (msiva); ; Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) Looks good to me. I agree that in the new text it is clear that we are not requiring a MIP or= MEP at the node that perform the loopback function along the transport pat= h As well I feel it is clear the way I read it, that 1- A MEP is required as a must at both ends of the transport path to perfor= m the transport path lock function prior to setting up the loopback on a no= de along the transport path. 2- The Loopback function MUST be done via management only. If the above is not clear to others while reading the new text, then we may= need to update it. Thanks, Sami On Jan 18, 2013, at 4:42 AM, David Ball wrote: > Hi Adrian, > > I think we are done, here is the updated text: > > =3D=3D=3D=3D > > Section 4, paragraphs 2-7; old text: > > The loopback function is used to test the integrity of a transport > path from a MEP up any other node in the same MEG. This is achieved > by setting the target node into loopback mode, and transmitting a > pattern of test data from the MEP. The target node loops all > received data back toward the originator, and the MEP extracts the > test data and compares it with what it sent. > > Loopback is a function that enables a receiving MEP or MIP to return > traffic to the sending MEP when in the loopback state. This state > corresponds to the situation where, at a given node, a forwarding > plane loop is configured, and the incoming direction of a transport > path is cross-connected to the outgoing reverse direction. > Therefore, except in the case of early TTL expiry, traffic sent by > the source will be received by that source. > > Data-plane loopback is an out-of-service function, as required in > Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic > (including user data and OAM). The traffic can be originated from > one internal point at the ingress of a transport path within an > interface or inserted from an input port of an interface using > external test equipment. The traffic is looped back unmodified > (other than normal per-hop processing such as TTL decrement) in the > direction of the point of origin by an interface at either an > intermediate node or a terminating node. > > It should be noted that the data-plane loopback function itself is > applied to data-plane loopback points residing on different > interfaces from MIPs/MEPs. All traffic (including both payload and > OAM) received on the looped back interface is sent on the reverse > direction of the transport path. > > For data-plane loopback at an intermediate point in a transport path, > the loopback needs to be configured to occur at either the ingress or > egress interface. This is done using management. > > The management plane can be used to configure the loopback function. > The management plane must ensure that the two MEPs are locked before > it requests setting MEP or MIP in the loopback state. > > New text: > > The loopback function is used to test the integrity of a transport > path from a MEP to any other node along the same transport path. > This is achieved by setting the target node into loopback mode for > that transport path, and transmitting a pattern of test data from > the MEP. The target node loops all data received on the transport > path back towards the sending MEP, which extracts the test data > and compares it with what it sent. > > Loopback is a function that enables a given node on a transport > path to return traffic to the sending MEP for that transport path > when in the loopback mode. This mode corresponds to the situation > where, at a given node, a forwarding plane loop is configured, and > the incoming direction of a transport path is cross-connected to the > outgoing reverse direction. Therefore, except in the case of early > TTL expiry, traffic sent by the source will be received by that > source. > > Data-plane loopback is an out-of-service function, as required in > Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic > (including user data and OAM). The traffic can be originated from > one internal point at the ingress of a transport path within an > interface or inserted from an input port of an interface using > external test equipment. The traffic is looped back unmodified > (other than normal per-hop processing such as TTL decrement) in the > direction of the point of origin by an interface at either an > intermediate node or a terminating node. > > It should be noted that the data-plane loopback function for a > given transport path can be applied to data-plane loopback points > residing on interfaces where there may be no MEP or MIP for that > transport path. > > For data-plane loopback at an intermediate point in a transport path, > the loopback needs to be configured to occur at either the ingress or > egress interface. This is done using management. > > The management plane must ensure that the MEPs at either end of a > transport path are locked before it requests setting a given node of > that transport path into loopback mode. > > Notes: > > The existing text has caused confusion about exactly where the > loopback is applied. It does not clearly express the original > intent, which was that there may or may not be a MEP or MIP at the > loopback point. In particular, paragraphs 2 and 7 imply that the > loopback point must be at a MEP or MIP, while paragraph 5 implies > that loopback is performed at a point where there is no MEP or MIP. > > The new text updates paragraphs 2, 3, 5 and 7 to clarify that the > loopback may be performed at any point along the transport path, > whether or not there is a MEP or MIP there, and that the loopback > only applies to the transport path in question. Paragraphs 4 and 6 > are unchanged. > > =3D=3D=3D=3D > > > David > > From kvivek@broadcom.com Fri Jan 18 20:03:38 2013 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 920CC21F8432 for ; Fri, 18 Jan 2013 20:03:38 -0800 (PST) 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 88IchipqxscQ for ; Fri, 18 Jan 2013 20:03:37 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id B929C21F842F for ; Fri, 18 Jan 2013 20:03:37 -0800 (PST) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 18 Jan 2013 19:58:12 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 18 Jan 2013 20:03:27 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 18 Jan 2013 20:03:06 -0800 From: "Vivek Kumar" To: "mpls@ietf.org" Thread-Topic: [Editorial Errata Reported] RFC6435 (3429) Thread-Index: Ac31+D+Crh7sRgwMSLaaReDr1DTY5wAAVAsg Date: Sat, 19 Jan 2013 04:03:06 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC41DECB622@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: 7CE4C65E3Q44049729-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 19 Jan 2013 04:03:38 -0000 Hi David, =20 Sorry . Ignore my previous comment . I said in context of ETH-OAM . It's no= t applicable here .=20 Regards, vivek -----Original Message----- From: Vivek Kumar=20 Sent: Saturday, January 19, 2013 9:28 AM To: mpls@ietf.org Subject: Re: [Editorial Errata Reported] RFC6435 (3429)=20 Hi David, The new text says "The traffic is looped back unmodified (other than nor= mal per-hop processing such as TTL decrement) in the direction of the poin= t of origin by an interface at either an intermediate node or a terminatin= g node". I feel if we are mentioning TTL processing as one exception , then we sho= uld also mention swapping src and destination Ethernet address when doing l= oopback . What do you say ? Regards, Vivek Message: 1 Date: Fri, 18 Jan 2013 20:28:52 +0000 From: Gregory Mirsky To: "Sami Boutros (sboutros)" , "David Ball -X (daviball - Ensoft Ltd at Cisco)" Cc: "" , "" , "" , "Siva Sivabalan \(msiva\)" , "" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) Message-ID: <7347100B5761DC41A166AC17F22DF11204F34D@eusaamb103.ericsson.se> Content-Type: text/plain; charset=3D"us-ascii" Hi Sami, I think that the "This is done using management." can not and should not be= interpreted as "The Loopback function MUST be done via management only." I= would ask you to consider changing it to "This can be done using managemen= t plane.", thus leaving non-management means for further consideration. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sam= i Boutros (sboutros) Sent: Friday, January 18, 2013 6:33 AM To: David Ball -X (daviball - Ensoft Ltd at Cisco) Cc: ; ; Siva Sivabalan (msiva); ; Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) Looks good to me. I agree that in the new text it is clear that we are not requiring a MIP or= MEP at the node that perform the loopback function along the transport pat= h As well I feel it is clear the way I read it, that 1- A MEP is required as a must at both ends of the transport path to perfor= m the transport path lock function prior to setting up the loopback on a no= de along the transport path. 2- The Loopback function MUST be done via management only. If the above is not clear to others while reading the new text, then we may= need to update it. Thanks, Sami On Jan 18, 2013, at 4:42 AM, David Ball wrote: > Hi Adrian, > > I think we are done, here is the updated text: > > =3D=3D=3D=3D > > Section 4, paragraphs 2-7; old text: > > The loopback function is used to test the integrity of a transport > path from a MEP up any other node in the same MEG. This is achieved > by setting the target node into loopback mode, and transmitting a > pattern of test data from the MEP. The target node loops all > received data back toward the originator, and the MEP extracts the > test data and compares it with what it sent. > > Loopback is a function that enables a receiving MEP or MIP to return > traffic to the sending MEP when in the loopback state. This state > corresponds to the situation where, at a given node, a forwarding > plane loop is configured, and the incoming direction of a transport > path is cross-connected to the outgoing reverse direction. > Therefore, except in the case of early TTL expiry, traffic sent by > the source will be received by that source. > > Data-plane loopback is an out-of-service function, as required in > Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic > (including user data and OAM). The traffic can be originated from > one internal point at the ingress of a transport path within an > interface or inserted from an input port of an interface using > external test equipment. The traffic is looped back unmodified > (other than normal per-hop processing such as TTL decrement) in the > direction of the point of origin by an interface at either an > intermediate node or a terminating node. > > It should be noted that the data-plane loopback function itself is > applied to data-plane loopback points residing on different > interfaces from MIPs/MEPs. All traffic (including both payload and > OAM) received on the looped back interface is sent on the reverse > direction of the transport path. > > For data-plane loopback at an intermediate point in a transport path, > the loopback needs to be configured to occur at either the ingress or > egress interface. This is done using management. > > The management plane can be used to configure the loopback function. > The management plane must ensure that the two MEPs are locked before > it requests setting MEP or MIP in the loopback state. > > New text: > > The loopback function is used to test the integrity of a transport > path from a MEP to any other node along the same transport path. > This is achieved by setting the target node into loopback mode for > that transport path, and transmitting a pattern of test data from > the MEP. The target node loops all data received on the transport > path back towards the sending MEP, which extracts the test data > and compares it with what it sent. > > Loopback is a function that enables a given node on a transport > path to return traffic to the sending MEP for that transport path > when in the loopback mode. This mode corresponds to the situation > where, at a given node, a forwarding plane loop is configured, and > the incoming direction of a transport path is cross-connected to the > outgoing reverse direction. Therefore, except in the case of early > TTL expiry, traffic sent by the source will be received by that > source. > > Data-plane loopback is an out-of-service function, as required in > Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic > (including user data and OAM). The traffic can be originated from > one internal point at the ingress of a transport path within an > interface or inserted from an input port of an interface using > external test equipment. The traffic is looped back unmodified > (other than normal per-hop processing such as TTL decrement) in the > direction of the point of origin by an interface at either an > intermediate node or a terminating node. > > It should be noted that the data-plane loopback function for a > given transport path can be applied to data-plane loopback points > residing on interfaces where there may be no MEP or MIP for that > transport path. > > For data-plane loopback at an intermediate point in a transport path, > the loopback needs to be configured to occur at either the ingress or > egress interface. This is done using management. > > The management plane must ensure that the MEPs at either end of a > transport path are locked before it requests setting a given node of > that transport path into loopback mode. > > Notes: > > The existing text has caused confusion about exactly where the > loopback is applied. It does not clearly express the original > intent, which was that there may or may not be a MEP or MIP at the > loopback point. In particular, paragraphs 2 and 7 imply that the > loopback point must be at a MEP or MIP, while paragraph 5 implies > that loopback is performed at a point where there is no MEP or MIP. > > The new text updates paragraphs 2, 3, 5 and 7 to clarify that the > loopback may be performed at any point along the transport path, > whether or not there is a MEP or MIP there, and that the loopback > only applies to the transport path in question. Paragraphs 4 and 6 > are unchanged. > > =3D=3D=3D=3D > > > David > > From loa@pi.nu Sat Jan 19 00:47:18 2013 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 C264321F857A for ; Sat, 19 Jan 2013 00:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 T09WDyBHDB7J for ; Sat, 19 Jan 2013 00:47:18 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 0F26021F8566 for ; Sat, 19 Jan 2013 00:47:17 -0800 (PST) Received: from [192.168.1.104] (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 EA5667FE07; Sat, 19 Jan 2013 09:47:15 +0100 (CET) Message-ID: <50FA5D96.4060707@pi.nu> Date: Sat, 19 Jan 2013 09:47:18 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" References: <50EAA1C5.20009@pi.nu> In-Reply-To: <50EAA1C5.20009@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mpls-tp-security-framework@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject: [mpls] Closed - 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 19 Jan 2013 08:47:18 -0000 Working Group, this working group last call has ended. We have one comment from Mach concerning the terminology section, the authors have agreed to fix this and re-spin the draft. As soon as the wg chair have the new version we will ask our AD to continue the publication process. /Loa for the wg co-chairs On 2013-01-07 11:21, Loa Andersson wrote: > Working Group, > > This is to start a working group last call on > draft-ietf-mpls-tp-security-framework-06. > > This is the second time this document is working group last called, > three has been a major update of the document since last time. > > Please find a diff: > http://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-tp-security-framework-05&difftype=--html&submit=Go%21&url2=draft-ietf-mpls-tp-security-framework-06 > > > 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. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not ware of any IPRs. > > This working group last call will end on January 18, 2013. > > /Loa > for the wg co-chairs > -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From internet-drafts@ietf.org Sun Jan 20 11:11:34 2013 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 BD64921F84CA; Sun, 20 Jan 2013 11:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 vGbwxD4O+qQj; Sun, 20 Jan 2013 11:11:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FE121F85DA; Sun, 20 Jan 2013 11:11:29 -0800 (PST) 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.37 Message-ID: <20130120191129.23983.54573.idtracker@ietfa.amsl.com> Date: Sun, 20 Jan 2013 11:11:29 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-security-framework-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: Sun, 20 Jan 2013 19:11: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 : MPLS-TP Security Framework Author(s) : Luyuan Fang Ben Niven-Jenkins Scott Mansfield Richard F. Graveman Filename : draft-ietf-mpls-tp-security-framework-07.txt Pages : 11 Date : 2013-01-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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-security-framework-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jan 20 12:01:04 2013 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 4885321F84BC; Sun, 20 Jan 2013 12:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 fMBO+S8xKzwk; Sun, 20 Jan 2013 12:01:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9913321F84D8; Sun, 20 Jan 2013 12:01:03 -0800 (PST) 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.37 Message-ID: <20130120200103.23484.22317.idtracker@ietfa.amsl.com> Date: Sun, 20 Jan 2013 12:01:03 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-09.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: Sun, 20 Jan 2013 20:01:04 -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 : A Thesaurus for the Terminology used in Multiprotocol La= bel Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport= Network Recommendations. Author(s) : Huub van Helvoort Loa Andersson Nurit Sprecher Filename : draft-ietf-mpls-tp-rosetta-stone-09.txt Pages : 18 Date : 2013-01-20 Abstract: MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-rosetta-stone-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-rosetta-stone-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From huubatwork@gmail.com Sun Jan 20 12:49:49 2013 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 F326721F86D9 for ; Sun, 20 Jan 2013 12:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.382, 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 3EBZ1LnTPJSh for ; Sun, 20 Jan 2013 12:49:48 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3621821F86D4 for ; Sun, 20 Jan 2013 12:49:48 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id fn15so3434935wgb.32 for ; Sun, 20 Jan 2013 12:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received: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=b1BdELWrfeyI7Gqw6mWjyTYaoeNF5rh7aTHXlqu4wtM=; b=dpW4wXu9RiAXV413W3K8jYkXuzwSlehB9rrUMm8hCxDWGKEsLNXOGI3qqrpO3t60uy VQubzm+xzHUT8ZtlvC+utEe8xaHOML6AwXoch0sHmnbP+eus4s0iWjX71bEnNBsDAElZ OwWdkhWdT6uYVBTHwEJM9D4b19vy1M7RbAt9J96t48evkkCTltlgkZ6w0JcQLHI0Q4dN 6+d2XHnODQYj7HtL0UGyzZG8ZwmjN1DyV/jBThT04ABBFdsRdJclF9zDCvlowwnu0nye vCk/hMD1tjH7a5OUGXpLbIhEAJD686rFH4wKITpQZeoZHiLNTAH18LU8UIOTxJHzmh0H tWCw== X-Received: by 10.194.179.34 with SMTP id dd2mr23150839wjc.1.1358714987276; Sun, 20 Jan 2013 12:49:47 -0800 (PST) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl. [77.250.51.60]) by mx.google.com with ESMTPS id p3sm13922721wic.8.2013.01.20.12.49.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jan 2013 12:49:46 -0800 (PST) Message-ID: <50FC5869.1020600@gmail.com> Date: Sun, 20 Jan 2013 21:49:45 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "t.petch" References: <20130115124143.12114.44371.idtracker@ietfa.amsl.com> <50F55175.5080106@gmail.com> <000d01cdf586$49f18440$4001a8c0@gateway.2wire.net> In-Reply-To: <000d01cdf586$49f18440$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-08.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: Sun, 20 Jan 2013 20:49:49 -0000 Hello Tom, Sorry for that. I have uploaded draft-ietf-mpls-tp-rosetta-stone-09 to fix these issues after double checking and unscrewing. Regards, Huub. ======================== > Um; I am still seeing > > [RFC....]. > > <> > > Error! Reference source not found., Error! > Reference source not found., and Error! Reference source not found.. > ITU-T Recommendation Error! Reference source not found > > which suggests to me that a little more unscrewing is in order. > > Tom Petch > > ----- Original Message ----- > From: "Huub van Helvoort" > Cc: > Sent: Tuesday, January 15, 2013 12:54 PM > Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-08.txt > > >> Sorry, >> >> I had to re-spin. MS messed up the references. >> >> Regards, Huub. >> >> >>> >>> 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 : A Thesaurus for the Terminology used in > Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs > and ITU-T's Transport Network Recommendations. >>> Author(s) : Huub van Helvoort >>> Loa Andersson >>> Nurit Sprecher >>> Filename : draft-ietf-mpls-tp-rosetta-stone-08.txt >>> Pages : 18 >>> Date : 2013-01-15 >>> >>> Abstract: >>> MPLS-TP is based on a profile of the MPLS and PW procedures as >>> specified in the MPLS-TE and (MS-)PW architectures developed by > the >>> IETF. The ITU-T has specified a Transport Network architecture. >>> >>> This document provides a thesaurus for the interpretation of > MPLS-TP >>> terminology within the context of the ITU-T Transport Network >>> recommendations. >>> >>> It is important to note that MPLS-TP is applicable in a wider > set of >>> contexts than just Transport Networks. The definitions > presented in >>> this document do not provide exclusive nor complete > interpretations >>> of MPLS-TP concepts. This document simply allows the MPLS-TP > terms >>> to be applied within the Transport Network context. >>> > > -- ***************************************************************** 璇疯浣忥紝浣犳槸鐙竴鏃犱簩鐨勶紝灏卞儚鍏朵粬姣忎竴涓汉涓鏍 From cpignata@cisco.com Sun Jan 20 13:08:26 2013 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 A705D21F87E7 for ; Sun, 20 Jan 2013 13:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 S48ojehRSEfd for ; Sun, 20 Jan 2013 13:08:25 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8481F21F87EE for ; Sun, 20 Jan 2013 13:08:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2444; q=dns/txt; s=iport; t=1358716105; x=1359925705; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=+59ST8iPF5aviGeF4o5TqVCtwvRYrRvXahlC8bDna1k=; b=HLiGXVdOBDKUUaHJS9T+PM3UudKEM7zNxwW7kqtzszg33ywom+dIiM/q f5jzTxfVBN9mcDHeaCmp59ZBhYbCHWPF9M1R4Esk5oAIpokQFLjOJgde6 0OlUudPlZFUqa8ErkzFyEYrx1rMCDxzUhSyNUjy/dPDb26tZvZMOx1XoB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAD1b/FCtJXG9/2dsb2JhbAA6Cr43FnOCIAEEOj8SASoUQicEAQ0NE4d+uxaNB4NRYQOmVYJ1giQ X-IronPort-AV: E=Sophos;i="4.84,501,1355097600"; d="scan'208";a="165214972" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 20 Jan 2013 21:08:25 +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 r0KL8PbP018374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jan 2013 21:08:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Sun, 20 Jan 2013 15:08:24 -0600 From: "Carlos Pignataro (cpignata)" To: "draft-villamizar-mpls-multipath-use@tools.ietf.org" , "" , Martin Vigoureux Thread-Topic: MPLS-RT review of draft-villamizar-mpls-multipath-use Thread-Index: AQHN91JIJFyYpNkTVE2p5oCIr0f+cQ== Date: Sun, 20 Jan 2013 21:08:24 +0000 Message-ID: <95067C434CE250468B77282634C96ED3228D4D01@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.105.142] Content-Type: text/plain; charset="us-ascii" Content-ID: <49DD8E25FECB7F47BCDDBC36706D69ED@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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, 20 Jan 2013 21:08:26 -0000 Hello, I have been selected as an MPLS Review team reviewer for draft-villamizar-m= pls-multipath-use-00. I read this document, and I believe it is ready to be considered for WG ado= ption and it is a really good start -- although I also believe that more wo= rk and discussion needs to happen in Section 3 (where solutions and require= ments are presented). I also believe this is a very well written document. It describes a real pr= oblem space adequately providing citations with context and background, and= explains cases that are useful in real operational networks. Additionally, I have some (minor and editorial) comments and questions for = consideration. Minor: 1. I was surprised that Section 3.1.1 of RFC 5960 was not cited, as that de= fines the MPLS-TP requirements for ECMP load balancing. 2. In the requirement MP#1, what does "identify" mean? Identify in the edge= s where nodes have visibility to both layers, tag, identify in mid-point no= des? 3. I think the concepts of utilizing {ELI; EL} need further discussion in t= he document. Similarly, so do the implications on the topic of the differen= ces of LAG vs. ECMP (both defined explicitly). 4. The concepts of unequal load split or otherwise load balancing proportio= nally to some ratio in different links/paths are briefly mentioned but coul= d be more explicitly covered. The ECMP definition mentions this (proportion= ally to capacity), but in that case it would not be "Equal". Similarly, con= cepts like "fairly evenly distributed" are used in definitions but not expl= ained -- might not be needed perhaps, but what is fair and what is even in = different scenarios can be understood differently. 5. In requirement MP#2, is the requirement to "completely exclude from the = hash", or to "always coming up with the same output, either by excluding or= including but always resulting in the same"? (i.e., is excluding a way of = getting to the result, or is it the result?) Nits: 1. Some times, I think that in many instances, "MPLS LSP" and "MPLS-TP LSP"= should be plural (s/LSP/LSPs/). Consequently, not always clear when is tal= king about splitting a single LSP as opposed to splitting multiple LSPs. 2. Some acronyms are not expanded on first use (or not defined), like CSPF,= PSC, ILM, others. 3. s/overa/over a/ I hope these are clear and useful. Thank you, Carlos Pignataro. From lufang@cisco.com Sun Jan 20 13:13:06 2013 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 0705E21F87F3 for ; Sun, 20 Jan 2013 13:13:06 -0800 (PST) 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 Hr3fwjPmE8t4 for ; Sun, 20 Jan 2013 13:13:04 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B5DDA21F87EE for ; Sun, 20 Jan 2013 13:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2438; q=dns/txt; s=iport; t=1358716384; x=1359925984; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MITXklbMmWvkGGUeMbYpVqR8Xxktfm07opi+eQCHLss=; b=GCqM0jnJOciXGF2nXiziCImtQk71CVaRVqxnXuYtUAotnyzPaYmkQbQV CfMge2ke9y6lxi1Cn6xJsu5Dl1XHnQAbgHAihuZH9LLCjcOpN2AYNYlP7 OAQzsPjcBvSdqXnBQcXv0KFVrsM+khdPlEaq/rC5y4DWCJxZ/2PiRQZAJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEhd/FCtJXHA/2dsb2JhbABEg3W6QhZzgh4BAQEEOjEDCwwCBAEIEQMBAgEKFCsXHQgCBAENBQgBiBAHBbsKBIx9g1dhA6ZVgnWBbzU X-IronPort-AV: E=Sophos;i="4.84,501,1355097600"; d="scan'208";a="165235011" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 20 Jan 2013 21:13:04 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0KLD4Q0023103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jan 2013 21:13:04 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Sun, 20 Jan 2013 15:13:03 -0600 From: "Luyuan Fang (lufang)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: Closed - [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AQHN7MDVTh7zjGol0UmgmGzQlFGPM5hQzkAAgAH8uIA= Date: Sun, 20 Jan 2013 21:13:02 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD93102676A9@xmb-rcd-x03.cisco.com> In-Reply-To: <50FA5D96.4060707@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.114.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <298CE8BC2EAC254185726F5DA66C96BF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Closed - 2nd wg last call on draft-ietf-mpls-tp-security-framework 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, 20 Jan 2013 21:13:06 -0000 Done. We posted 07 draft with the fix concerning the terminology section which was agreed with Mach, and added ack to Mach. Loa, Adrian, and all, Thanks to all of you who gave us strong support, and provided helpful input. Luyuan -----Original Message----- From: Loa Andersson Date: Saturday, January 19, 2013 12:47 AM To: "mpls@ietf.org" Cc: "draft-ietf-mpls-tp-security-framework@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Closed - [mpls] 2nd wg last call on draft-ietf-mpls-tp-security-framework Resent-From: Resent-To: , Luyuan Fang , , , , , Resent-Date: Saturday, January 19, 2013 12:47 AM >Working Group, > >this working group last call has ended. > >We have one comment from Mach concerning the terminology section, >the authors have agreed to fix this and re-spin the draft. > >As soon as the wg chair have the new version we will ask our AD >to continue the publication process. > >/Loa >for the wg co-chairs > >On 2013-01-07 11:21, Loa Andersson wrote: >> Working Group, >> >> This is to start a working group last call on >> draft-ietf-mpls-tp-security-framework-06. >> >> This is the second time this document is working group last called, >> three has been a major update of the document since last time. >> >> Please find a diff: >>=20 >>http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mpls-tp-security-framework-= 05 >>&difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-mpls-tp-security-fram= ework- >>06 >> >> >> 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. >> >> There are no IPR claims against this draft. >> >> All the co-authors has stated that they are not ware of any IPRs. >> >> This working group last call will end on January 18, 2013. >> >> /Loa >> for the wg co-chairs >> > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >MPLS Expert loa@pi.nu >Huawei Technologies (consult) phone: +46 739 81 21 64 From lufang@cisco.com Sun Jan 20 15:03:27 2013 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 B3EA121F857A for ; Sun, 20 Jan 2013 15:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 qBgCHAp-vcIm for ; Sun, 20 Jan 2013 15:03:27 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1ED21F84B9 for ; Sun, 20 Jan 2013 15:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1787; q=dns/txt; s=iport; t=1358723005; x=1359932605; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IQ/Tk8Coibkefixoz4nIe9C38AjNEzLtS5Wgwg0CNl0=; b=m96Smv1nwQtkJ6ROX3l4F2fSKMOBWZZRUVeiOMW3svLZH2YlK0fBUmHw SZLmvaUhlJIIfcDWWqaWImHA7xvyLZZl3DqM0BY6HsRVhKFo7VUcP3GQR rik6AhaTJiXa8FMuc4StTP+A7wWv8KHoInz4aIbKkjnzMybxDA1ilc3RF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOV2/FCtJXG8/2dsb2JhbABDvjcWc4IeAQEBBAEBATc0CwwGAQgRAwECCxQxBgsUCQgCBAENBQiHfwMPDLIWDYheBIwJhE9hA5Q2iECETYUSgnWCJA X-IronPort-AV: E=Sophos;i="4.84,501,1355097600"; d="scan'208";a="165238934" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 20 Jan 2013 23:03:12 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0KN3BPE004166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jan 2013 23:03:11 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sun, 20 Jan 2013 17:03:11 -0600 From: "Luyuan Fang (lufang)" To: "huubatwork@gmail.com" , "loa@pi.nu" Thread-Topic: [mpls] working group last call Thread-Index: AQHN8kOhO9NeXmS+hEuIsU0xoNTiYphMbpIAgAaCTAA= Date: Sun, 20 Jan 2013 23:03:11 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD93102677F1@xmb-rcd-x03.cisco.com> In-Reply-To: <50F6BB94.4000206@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.114.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: Re: [mpls] working group last call 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, 20 Jan 2013 23:03:28 -0000 Huub, Thank you for picking this up. We will fix the the acronym expansion for MEP and MIP as you correctly pointed out in the re-spin of the draft when the WG last call has ended. Luyuan -----Original Message----- From: Huub van Helvoort Reply-To: "huubatwork@gmail.com" Date: Wednesday, January 16, 2013 6:39 AM To: "loa@pi.nu" Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: Re: [mpls] working group last call >Editors, > >You need to fix the acronym expansion for MEP and MIP: > >MEP Maintenance Entity Group End Point >MIP Maintenance Entity Group Intermediate Point > >Regards, Huub. > >=3D=3D=3D=3D=3D=3D > >> this is to start a two week Working Group last call on >> draft-ietf-mpls-tp-use-cases-and-design. >> >> This is the second time we working group last call this >> draft, it has been updated after comments during the >> ADE-review. The changes are such that we have decided to >> do a full two week wglc. >> >> 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. >> >> There are no IPR claims against this draft. >> >> All the co-authors has stated that they are not aware >> of any IPRs. >> >> This working group last call will end on January 25, 2013. >> >> /Loa >> for the wg co-chairs >> > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From mach.chen@huawei.com Sun Jan 20 18:34:58 2013 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 2796821F8759 for ; Sun, 20 Jan 2013 18:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 eTLjZneWmaD8 for ; Sun, 20 Jan 2013 18:34:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E551621F868D for ; Sun, 20 Jan 2013 18:34:54 -0800 (PST) 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 ANS32910; Mon, 21 Jan 2013 02:34:53 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 21 Jan 2013 02:34:44 +0000 Received: from SZXEML463-HUB.china.huawei.com (10.82.67.206) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 21 Jan 2013 02:34:49 +0000 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.33]) by szxeml463-hub.china.huawei.com ([10.82.67.206]) with mapi id 14.01.0323.007; Mon, 21 Jan 2013 10:34:45 +0800 From: Mach Chen To: Gregory Mirsky , "Sami Boutros (sboutros)" , "David Ball -X (daviball - Ensoft Ltd at Cisco)" Thread-Topic: [Editorial Errata Reported] RFC6435 (3429) Thread-Index: AQHN9YjHdP6wRFSkhE6oKZHqlafHQJhPA60AgAQIAdCAAAAqcA== Date: Mon, 21 Jan 2013 02:34:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "" , "" , "Siva Sivabalan \(msiva\)" , "" Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) 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, 21 Jan 2013 02:34:58 -0000 Hi Greg, I totally agree with you here! This errata only intends to clarify whether the location of the loopback fu= nction should be with MIP/MEP, through the discussion, the consensus is mad= e. We should not change other aspects other than the location issue.=20 The last para of the new text says: "The management plane must ensure that the MEPs at either end of a=20 transport path are locked before it requests setting a given node of=20 that transport path into loopback mode." While the original text says: "The management plane can be used to configure the loopback function. The management plane must ensure that the two MEPs are locked before it requests setting MEP or MIP in the loopback state." It removes "The management plane can be used to configure the loopback func= tion " and implicitly makes that management plane as a "MUST" for loopback = function although the original text says "the management plane can be...". = =20 So, I'd like to suggest to change the last para of the new text as follows: Old new text: The management plane must ensure that the MEPs at either end of a=20 transport path are locked before it requests setting a given node of=20 that transport path into loopback mode. New text: The management plane can be used to configure the loopback function. The management plane must ensure that the MEPs at either end of a=20 transport path are locked before it requests setting a given node of=20 that transport path into loopback mode. Best regards, Mach > -----Original Message----- > From: Mach Chen > Sent: Monday, January 21, 2013 10:03 AM > To: Mach Chen > Subject: FW: [Editorial Errata Reported] RFC6435 (3429) >=20 >=20 >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Gregory Mirsky > Sent: Saturday, January 19, 2013 4:29 AM > To: Sami Boutros (sboutros); David Ball -X (daviball - Ensoft Ltd at Cisc= o) > Cc: ; ; ; Siva > Sivabalan (msiva); > Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) >=20 > Hi Sami, > I think that the "This is done using management." can not and should not = be > interpreted as "The Loopback function MUST be done via management only." = I > would ask you to consider changing it to "This can be done using manageme= nt > plane.", thus leaving non-management means for further consideration. >=20 > =A0=A0=A0=A0=A0=A0=A0 Regards, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Sami Boutros (sboutros) > Sent: Friday, January 18, 2013 6:33 AM > To: David Ball -X (daviball - Ensoft Ltd at Cisco) > Cc: ; ; Siva Sivabalan (msiva); > ; > Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) >=20 > Looks good to me. >=20 > I agree that in the new text it is clear that we are not requiring a MIP = or MEP at > the node that perform the loopback function along the transport path >=20 > As well I feel it is clear the way I read it, that >=20 > 1- A MEP is required as a must at both ends of the transport path to perf= orm > the transport path lock function prior to setting up the loopback on a no= de > along the transport path. > 2- The Loopback function MUST be done via management only. >=20 > If the above is not clear to others while reading the new text, then we m= ay > need to update it. >=20 > Thanks, >=20 > Sami > On Jan 18, 2013, at 4:42 AM, David Ball wrote: >=20 > > Hi Adrian, > > > > I think we are done, here is the updated text: > > > > =3D=3D=3D=3D > > > > Section 4, paragraphs 2-7; old text: > > > >=A0=A0 The loopback function is used to test the integrity of a transpor= t > >=A0=A0 path from a MEP up any other node in the same MEG.=A0 This is ach= ieved > >=A0=A0 by setting the target node into loopback mode, and transmitting a > >=A0=A0 pattern of test data from the MEP.=A0 The target node loops all > >=A0=A0 received data back toward the originator, and the MEP extracts th= e > >=A0=A0 test data and compares it with what it sent. > > > >=A0=A0 Loopback is a function that enables a receiving MEP or MIP to ret= urn > >=A0=A0 traffic to the sending MEP when in the loopback state.=A0 This st= ate > >=A0=A0 corresponds to the situation where, at a given node, a forwarding > >=A0=A0 plane loop is configured, and the incoming direction of a transpo= rt > >=A0=A0 path is cross-connected to the outgoing reverse direction. > >=A0=A0 Therefore, except in the case of early TTL expiry, traffic sent b= y > >=A0=A0 the source will be received by that source. > > > >=A0=A0 Data-plane loopback is an out-of-service function, as required in > >=A0=A0 Section 2.2.5 of RFC 5860 [1].=A0 This function loops back all tr= affic > >=A0=A0 (including user data and OAM).=A0 The traffic can be originated f= rom > >=A0=A0 one internal point at the ingress of a transport path within an > >=A0=A0 interface or inserted from an input port of an interface using > >=A0=A0 external test equipment.=A0 The traffic is looped back unmodified > >=A0=A0 (other than normal per-hop processing such as TTL decrement) in t= he > >=A0=A0 direction of the point of origin by an interface at either an > >=A0=A0 intermediate node or a terminating node. > > > >=A0=A0 It should be noted that the data-plane loopback function itself i= s > >=A0=A0 applied to data-plane loopback points residing on different > >=A0=A0 interfaces from MIPs/MEPs.=A0 All traffic (including both payload= and > >=A0=A0 OAM) received on the looped back interface is sent on the reverse > >=A0=A0 direction of the transport path. > > > >=A0=A0 For data-plane loopback at an intermediate point in a transport > >path, > >=A0=A0 the loopback needs to be configured to occur at either the ingres= s > >or > >=A0=A0 egress interface.=A0 This is done using management. > > > >=A0=A0 The management plane can be used to configure the loopback functi= on. > >=A0=A0 The management plane must ensure that the two MEPs are locked bef= ore > >=A0=A0 it requests setting MEP or MIP in the loopback state. > > > > New text: > > > >=A0=A0 The loopback function is used to test the integrity of a transpor= t > >=A0=A0 path from a MEP to any other node along the same transport path. > >=A0=A0 This is achieved by setting the target node into loopback mode fo= r > >=A0=A0 that transport path, and=A0 transmitting a pattern of test data f= rom > >=A0=A0 the MEP.=A0 The target node loops all data received on the transp= ort > >=A0=A0 path back towards the sending MEP, which extracts the test data > >=A0=A0 and compares it with what it sent. > > > >=A0=A0 Loopback is a function that enables a given node on a transport > >=A0=A0 path to return traffic to the sending MEP for that transport path > >=A0=A0 when in the loopback mode.=A0 This mode corresponds to the situat= ion > >=A0=A0 where, at a given node, a forwarding plane loop is configured, an= d > >=A0=A0 the incoming direction of a transport path is cross-connected to = the > >=A0=A0 outgoing reverse direction.=A0 Therefore, except in the case of e= arly > >=A0=A0 TTL expiry, traffic sent by the source will be received by that > >=A0=A0 source. > > > >=A0=A0 Data-plane loopback is an out-of-service function, as required in > >=A0=A0 Section 2.2.5 of RFC 5860 [1].=A0 This function loops back all tr= affic > >=A0=A0 (including user data and OAM).=A0 The traffic can be originated f= rom > >=A0=A0 one internal point at the ingress of a transport path within an > >=A0=A0 interface or inserted from an input port of an interface using > >=A0=A0 external test equipment.=A0 The traffic is looped back unmodified > >=A0=A0 (other than normal per-hop processing such as TTL decrement) in t= he > >=A0=A0 direction of the point of origin by an interface at either an > >=A0=A0 intermediate node or a terminating node. > > > >=A0=A0 It should be noted that the data-plane loopback function for a > >=A0=A0 given transport path can be applied to data-plane loopback points > >=A0=A0 residing on interfaces where there may be no MEP or MIP for that > >=A0=A0 transport path. > > > >=A0=A0 For data-plane loopback at an intermediate point in a transport > >path, > >=A0=A0 the loopback needs to be configured to occur at either the ingres= s > >or > >=A0=A0 egress interface.=A0 This is done using management. > > > >=A0=A0 The management plane must ensure that the MEPs at either end of a > >=A0=A0 transport path are locked before it requests setting a given node= of > >=A0=A0 that transport path into loopback mode. >=20 > > > > Notes: > > > >=A0=A0 The existing text has caused confusion about exactly where the > >=A0=A0 loopback is applied.=A0 It does not clearly express the original > >=A0=A0 intent, which was that there may or may not be a MEP or MIP at th= e > >=A0=A0 loopback point.=A0 In particular, paragraphs 2 and 7 imply that t= he > >=A0=A0 loopback point must be at a MEP or MIP, while paragraph 5 implies > >=A0=A0 that loopback is performed at a point where there is no MEP or MI= P. > > > >=A0=A0 The new text updates paragraphs 2, 3, 5 and 7 to clarify that the > >=A0=A0 loopback may be performed at any point along the transport path, > >=A0=A0 whether or not there is a MEP or MIP there, and that the loopback > >=A0=A0 only applies to the transport path in question.=A0 Paragraphs 4 a= nd 6 > >=A0=A0 are unchanged. > > > > =3D=3D=3D=3D > > > > > >=A0=A0=A0=A0=A0=A0=A0 David > > > > > > On Fri, Jan 18, 2013, Adrian Farrel wrote: > >> OK, when we are done, can some write me an email that contains the > >> text that would have been in the Errata Report if we had known then wh= at > we know now? > >> > >> Then I will process the existing report and the new text. > >> > >> Thanks, > >> Adrian > >> > >> From: VIGOUREUX, MARTIN (MARTIN) > >> [mailto:martin.vigoureux@alcatel-lucent.com] > >> Sent: 17 January 2013 20:00 > >> To: David Ball > >> Cc: adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan > >> (msiva)'; raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart > >> Bryant (stbryant)'; loa@pi.nu; 'George Swallow (swallow)'; > >> rcallon@juniper.net; mpls@ietf.org > >> Subject: RE: [Editorial Errata Reported] RFC6435 (3429) > >> > >> David, > >> > >> Yes it does. Thanks. > >> I first thought of removing all references to MEP/MIP but should have > >> given it a second thought. > >> > >> -m > >>=A0 _____ > >> > >> De : David Ball > >> Envoy? : 17/01/2013 18:41 > >> ? : VIGOUREUX, MARTIN (MARTIN) > >> Cc : adrian@olddog.co.uk; 'Sami Boutros (sboutros)'; 'Siva Sivabalan > >> (msiva)'; raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; 'Stewart > >> Bryant (stbryant)'; loa@pi.nu; 'George Swallow (swallow)'; > >> rcallon@juniper.net; mpls@ietf.org Objet : Re: [Editorial Errata > >> Reported] RFC6435 (3429) Hi Martin, > >> > >> Actually I think the last paragraph is talking about something > >> different > >> again: this is the MEPs that must be locked. > >> > >> Here is a transport path: > >> > >>=A0 |>-------x----------x-------<| > >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 --------->| > >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <---------v > >>=A0 A=A0=A0=A0=A0=A0=A0=A0 B=A0=A0=A0=A0=A0=A0=A0=A0=A0 C=A0=A0=A0=A0= =A0=A0=A0 D > >> > >> A and D are the MEPs; B is the source of the test, C is the loopback > >> point. > >> > >> As we have discussed, C could be a MIP, could be the MEP at D, or > >> could be at a point that is neither a MIP or a MEP. > >> > >> A and D are the MEPs that must be locked during the test. > >> > >> My question was about point B: I think in the original text point B > >> must always be the same as the MEP at point A; your proposal allows > >> it to be some other point, eg at a MIP or at a point where there is > >> no MIP or MEP. > >> > >> If we keep the original text about point B, and just change the text > >> about point C, then combining with your proposal we get the following > >> change: > >> > >> Old text: > >>=A0=A0 The loopback function is used to test the integrity of a transpo= rt > >>=A0=A0 path from a MEP up any other node in the same MEG.=A0 This is > >>achieved > >>=A0=A0 by setting the target node into loopback mode, and transmitting = a > >>=A0=A0 pattern of test data from the MEP.=A0 The target node loops all > >>=A0=A0 received data back toward the originator, and the MEP extracts t= he > >>=A0=A0 test data and compares it with what it sent. > >> > >>=A0=A0 Loopback is a function that enables a receiving MEP or MIP to > >>return > >>=A0=A0 traffic to the sending MEP when in the loopback state. > >> > >>=A0=A0 [...] > >> > >>=A0=A0 The management plane must ensure that the two MEPs are locked > >>before > >>=A0=A0 it requests setting MEP or MIP in the loopback state. > >> > >> New text: > >>=A0=A0 The loopback function is used to test the integrity of a transpo= rt > >>=A0=A0 path from a MEP to any other node along the same transport path. > >>=A0=A0 This is achieved by setting the target node into loopback mode f= or > >>=A0=A0 that transport path, and=A0 transmitting a pattern of test data = from > >>=A0=A0 the MEP.=A0 The target node loops all data received on the trans= port > >>=A0=A0 path back towards the sending MEP, which extracts the test data > >>=A0=A0 and compares it with what it sent. > >> > >>=A0=A0 Loopback is a function that enables a given node of a transport > >>=A0=A0 path to return traffic to the sending MEP for that transport pat= h > >>=A0=A0 when in the loopback mode. > >> > >>=A0=A0 [...] > >> > >>=A0=A0 The management plane must ensure that the MEPs at either end of = a > >>=A0=A0 transport path are locked before it requests setting a given nod= e > >>of > >>=A0=A0 that transport path into loopback mode. > >> > >> Does this work? > >> > >> > >>=A0=A0=A0=A0=A0=A0=A0 David > >> > >> > >> On Thu, Jan 17, 2013, Martin Vigoureux wrote: > >>> David, > >>> > >>> agreed, and in fact this is consistent with the fact I kept MEP in > >>> the last paragraph I changed. > >>> > >>> -m > >>> > >>> > >>> Le 17/01/2013 18:09, David Ball a ?crit : > >>>> Thanks Martin. > >>>> > >>>> Regarding the first paragraph, I agree with your change to add "for > >>>> that transport path", that does make it clearer. > >>>> > >>>> Regarding the other paragraphs: We have agreed that the intent was > >>>> that the point doing the loopback does not have to be a MEP or MIP, > >>>> but your proposal also seems to change it so that the point > >>>> transmitting the test data does not have to be a MEP.=A0 I think the > >>>> original text was consistent that the test was done *from* a MEP; > >>>> the question was whether it was done from a MEP *to another > >>>> MEP/MIP*, or from a MEP *to an arbitrary point*. > >>>> > >>>> So you might be right that the text describing the source of the > >>>> test should also be changed, but I think that is a slightly separate= issue. > >>>> It is probably safest to keep the changes to a minimum and just fix > >>>> the description of the point that is doing the loopback, ie the > >>>> target of the test. > >>>> > >>>> Do you agree? > >>>> > >>>> > >>>>=A0=A0=A0 David > >>>> > >>>> > >>>> On Thu, Jan 17, 2013, Martin Vigoureux wrote: > >>>>> Adrian, yes, we are. > >>>>> > >>>>> So, David, > >>>>> > >>>>> I am fine with your suggested text which says: > >>>>>=A0=A0 It should be noted that the data-plane loopback function for = a > >>>>>=A0=A0 given transport path can be applied to data-plane loopback > >>>>>points > >>>>>=A0=A0 residing on interfaces where there may be no corresponding ME= P > >>>>>or > >>>>>=A0=A0 MIP. > >>>>> > >>>>> I was thinking of: > >>>>> s/may be no corresponding MEP or MIP./may be no MEP or MIP for > >>>>> that transport path./ but this is optional. > >>>>> > >>>>> The new text will replace: > >>>>>=A0=A0 It should be noted that the data-plane loopback function itse= lf > >>>>>is > >>>>>=A0=A0 applied to data-plane loopback points residing on different > >>>>>=A0=A0 interfaces from MIPs/MEPs. > >>>>> > >>>>> > >>>>> Regarding the other paragraphs: > >>>>>=A0=A0 The loopback function is used to test the integrity of a > >>>>>transport > >>>>>=A0=A0 path from a MEP up any other node in the same MEG.=A0 This is > >>>>>achieved > >>>>>=A0=A0 by setting the target node into loopback mode, and transmitti= ng > >>>>>a > >>>>>=A0=A0 pattern of test data from the MEP.=A0 The target node loops a= ll > >>>>>=A0=A0 received data back toward the originator, and the MEP extract= s > >>>>>the > >>>>>=A0=A0 test data and compares it with what it sent. > >>>>> > >>>>>=A0=A0 Loopback is a function that enables a receiving MEP or MIP to > >>>>>return > >>>>>=A0=A0 traffic to the sending MEP when in the loopback state. > >>>>> > >>>>>=A0=A0 [...] > >>>>> > >>>>>=A0=A0 The management plane must ensure that the two MEPs are locked > >>>>>before > >>>>>=A0=A0 it requests setting MEP or MIP in the loopback state. > >>>>> > >>>>> > >>>>> They could be changed into: > >>>>>=A0=A0 The loopback function is used to test the integrity of a > >>>>>transport > >>>>>=A0=A0 path.=A0 This is achieved by setting a given node into loopba= ck > >>>>>mode > >>>>>=A0=A0 for a given transport path, and sending over it a pattern of > >>>>>test > >>>>>=A0=A0 data.=A0 The node in loopback mode loops all test data receiv= ed on > >>>>>the > >>>>>=A0=A0 transport path back towards the sender, which extracts the te= st > >>>>>=A0=A0 data and compares it with what it sent. > >>>>> > >>>>>=A0=A0 Loopback is a function which enables a given node of a transp= ort > >>>>>=A0=A0 path, when in the loopback mode, to return traffic to the sen= der > >>>>>of > >>>>>=A0=A0 that traffic. > >>>>> > >>>>>=A0=A0 [...] > >>>>> > >>>>>=A0=A0 The management plane must ensure that the MEPs of a transport > >>>>>path > >>>>>=A0=A0 are locked before it requests setting a given node of that > >>>>>transport > >>>>>=A0=A0 path in loopback mode. > >>>>> > >>>>> Let me know. > >>>>> -m > >>>>> > >>>>> Le 16/01/2013 22:07, Adrian Farrel a ?crit : > >>>>>> All, are we getting any closer to agreeing what we all intended to= say? > >>>>>> > >>>>>> Once we have that, I can work out what to do with the Errata Repor= t. > >>>>>> > >>>>>> Thanks, > >>>>>> Adrian > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: David Ball [mailto:daviball@cisco.com] > >>>>>>> Sent: 10 January 2013 17:57 > >>>>>>> To: VIGOUREUX, MARTIN (MARTIN) > >>>>>>> Cc: Sami Boutros (sboutros); adrian@olddog.co.uk; Siva Sivabalan > >>>>>>> (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; Stewart > >>>>>>> Bryant (stbryant); loa@pi.nu; George Swallow (swallow); > >>>>>>> rcallon@juniper.net; mpls@ietf.org > >>>>>>> Subject: Re: [Editorial Errata Reported] RFC6435 (3429) > >>>>>>> > >>>>>>> Hi Martin, > >>>>>>> > >>>>>>> Ah, right I see: since the loopback is locally configured, there > >>>>>>> is no need for a MEP/MIP to send/receive OAM frames - but there > >>>>>>> may be a MEP/MIP. > >>>>>>> > >>>>>>> So would this work to clarify the text? > >>>>>>>=A0 "It should be noted that the data-plane loopback function for = a > >>>>>>>=A0=A0 given transport path can be applied to data-plane loopback > >>>>>>>points > >>>>>>>=A0=A0 residing on interfaces where there may be no corresponding = MEP > >>>>>>>or > >>>>>>>=A0=A0 MIP." > >>>>>>> > >>>>>>> For completeness, the references to "MEP or MIP" in paragraphs 3 > >>>>>>> and 7 of section 4 would also need to be changed, to instead > >>>>>>> refer to the transport path that is being put in to loopback. > >>>>>>> > >>>>>>> As another data point, I found this text in RFC6371 section 6.3.2= : > >>>>>>>=A0 "It should be noted that data-plane loopback function itself i= s > >>>>>>>=A0=A0 applied to data-plane loopback points that can reside on > >>>>>>>different > >>>>>>>=A0=A0 interfaces from MIPs/MEPs." > >>>>>>> Note the critical difference compared to RFC6435: "that can resid= e" > >>>>>>> instead of "residing". > >>>>>>> > >>>>>>> Thanks > >>>>>>> > >>>>>>> > >>>>>>> David > >>>>>>> > >>>>>>> > >>>>>>> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote: > >>>>>>>> Sami, > >>>>>>>> > >>>>>>>> Thanks. Yet, I am not sure David's interpretation and mine exact= ly > match. > >>>>>>>> David, correct me if I am wrong. For me it says that we can do > >>>>>>>> loopback on different interfaces (for different LSPs) but > >>>>>>>> implies that there is a mip/mep for that lsp on that interface, > >>>>>>>> while my interpretation is that the presence of a mip/mep for > >>>>>>>> that lsp on that interface is not needed. > >>>>>>>> > >>>>>>>> -m > >>>>>>>> ________________________________ De : Sami Boutros (sboutros) > >>>>>>>> Envoy? : 09/01/2013 19:00 ? : VIGOUREUX, MARTIN (MARTIN) Cc : > >>>>>>>> adrian@olddog.co.uk; David Ball -X (daviball - Ensoft Ltd at > >>>>>>>> Cisco); > >>>>>> Siva > >>>>>>> Sivabalan (msiva); raggarwa_1@yahoo.com; dai.xuehui@zte.com.cn; > >>>>>>> Stewart Bryant (stbryant); loa@pi.nu; George Swallow (swallow); > >> rcallon@juniper.net; > >>>>>>> mpls@ietf.org > >>>>>>>> Objet : Re: [Editorial Errata Reported] RFC6435 (3429) > >>>>>>>> > >>>>>>>> I agree with Martin, the text proposed by David describe more > >>>>>>>> accurately > >>>>>> what > >>>>>>> we meant. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Sami > >>>>>>>> On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote: > >>>>>>>> > >>>>>>>>> Adrian, David, > >>>>>>>>> > >>>>>>>>> what I think we meant here was that a loop-back function could > >>>>>>>>> be done > >> on > >>>>>>> an interface regardless of the presence of a MIP/MEP on that > interface. > >> Yet, I > >>>>>>> have to admit that MIP and MEP are used in Section 4 of RFC6435, > >>>>>>> thus > >> surely > >>>>>>> causing confusion. > >>>>>>>>> > >>>>>>>>> I'd welcome the views/souvenirs of my co-authors. > >>>>>>>>> > >>>>>>>>> -m > >>>>>>>>> > >>>>>>>>> Le 12/12/2012 19:17, Adrian Farrel a ?crit : > >>>>>>>>>> Hello, > >>>>>>>>>> > >>>>>>>>>> Authors of RFC 6435: I need to hear from you that you meant > >>>>>>>>>> the text > >> that > >>>>>>> David > >>>>>>>>>> suggests. It is very clearly not what you wrote and, if you > >>>>>>>>>> meant > >>>>>> something > >>>>>>>>>> different, it is clear why people are confused! > >>>>>>>>>> > >>>>>>>>>> Working group: I need to hear from you that you agree with > >>>>>>>>>> David's interpretation and support his proposed change. > >>>>>>>>>> > >>>>>>>>>> Only then will I try to work out whether this is a "typo" > >>>>>>>>>> worthy of an > >>>>>> errata > >>>>>>>>>> report, or a technical change needing a revised RFC. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Adrian > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>>>>>>>>>> Sent: 12 December 2012 17:45 > >>>>>>>>>>> To: sboutros@cisco.com; msiva@cisco.com; > >>>>>>>>>>> raggarwa_1@yahoo.com; martin.vigoureux@alcatel-lucent.com; > >>>>>>>>>>> dai.xuehui@zte.com.cn; stbryant@cisco.com; > >>>>>>>>>>> adrian@olddog.co.uk; loa@pi.nu; > >>>>>>> swallow@cisco.com; > >>>>>>>>>>> rcallon@juniper.net > >>>>>>>>>>> Cc: daviball@cisco.com; mpls@ietf.org; > >>>>>>>>>>> rfc-editor@rfc-editor.org > >>>>>>>>>>> Subject: [Editorial Errata Reported] RFC6435 (3429) > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> The following errata report has been submitted for RFC6435, > >>>>>>>>>>> "MPLS Transport Profile Lock Instruct and Loopback Functions"= . > >>>>>>>>>>> > >>>>>>>>>>> -------------------------------------- > >>>>>>>>>>> You may review the report below and at: > >>>>>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6435 > >> > >> &eid=3D3429 > >>>>>>>>>>> > >>>>>>>>>>> -------------------------------------- > >>>>>>>>>>> Type: Editorial > >>>>>>>>>>> Reported by: David Ball > >>>>>>>>>>> > >>>>>>>>>>> Section: 4 (para 5) > >>>>>>>>>>> > >>>>>>>>>>> Original Text > >>>>>>>>>>> ------------- > >>>>>>>>>>> It should be noted that the data-plane loopback function > >>>>>>>>>>> itself is > >>>>>> applied to > >>>>>>>>>> data- > >>>>>>>>>>> plane loopback points residing on different interfaces from > MIPs/MEPs. > >>>>>>>>>>> > >>>>>>>>>>> Corrected Text > >>>>>>>>>>> -------------- > >>>>>>>>>>> It should be noted that the data-plane loopback function may > >>>>>>>>>>> be > >> applied > >>>>>> at > >>>>>>>>>>> MIPs/MEPs on different interfaces for different LSPs. > >>>>>>>>>>> > >>>>>>>>>>> Notes > >>>>>>>>>>> ----- > >>>>>>>>>>> The existing text has caused confusion (specifically, among > >>>>>>>>>>> experts in > >>>>>> ITU-T > >>>>>>>>>> SG15 > >>>>>>>>>>> when discussing G.8121.2), in that it seems to suggest that > >>>>>>>>>>> the > >>>>>> interface > >>>>>>>>>> where > >>>>>>>>>>> the MIP/MEP is located may be a different interface to the > >>>>>>>>>>> one where > >> the > >>>>>>>>>>> loopback is applied. > >>>>>>>>>>> > >>>>>>>>>>> Having spoken with some of the original authors, it seems > >>>>>>>>>>> this was not > >>>>>> the > >>>>>>>>>> intent > >>>>>>>>>>> of this sentence; the intent was to point out that as > >>>>>>>>>>> different LSPs > >>>>>> would > >>>>>>>>>> have > >>>>>>>>>>> MIPs/MEPs on different interfaces, the corresponding > >>>>>>>>>>> loopback > >> functions > >>>>>>> would > >>>>>>>>>>> also be applied on different interfaces. > >>>>>>>>>>> > >>>>>>>>>>> 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 ed= it the > report, if necessary. > >>>>>>>>>>> > >>>>>>>>>>> -------------------------------------- > >>>>>>>>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) > >>>>>>>>>>> -------------------------------------- > >>>>>>>>>>> Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : MPLS Transp= ort Profile Lock Instruct > >>>>>>>>>>> and > >> Loopback > >>>>>>>>>> Functions > >>>>>>>>>>> Publication Date=A0=A0=A0 : November 2011 > >>>>>>>>>>> Author(s)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : S. Boutros, Ed., S.= Sivabalan, Ed., R. > >>>>>>>>>>> Aggarwal, > >>>>>> Ed., M. > >>>>>>>>>> Vigoureux, > >>>>>>>>>>> Ed., X. Dai, Ed. > >>>>>>>>>>> Category=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : PROPOSED STANDARD > Source > >>>>>>>>>>> : Multiprotocol Label Switching Area=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 : > >>>>>>>>>>> Routing Stream=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : IETF = Verifying Party=A0=A0=A0=A0 : > >>>>>>>>>>> IESG > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> David Ball > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >> > >> -- > >> David Ball > >> > > > > -- > > David Ball > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From ms-daikoku@kddi.com Sun Jan 20 22:34:03 2013 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 8E80D21F8765 for ; Sun, 20 Jan 2013 22:34:03 -0800 (PST) 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 Yp6Bap1PVhyI for ; Sun, 20 Jan 2013 22:34:02 -0800 (PST) Received: from UTMC1101.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id C602C21F874F for ; Sun, 20 Jan 2013 22:34:02 -0800 (PST) Received: from UTMC1133 (unknown [10.5.16.198]) by UTMC1101.kddi.com (Postfix) with SMTP id 973DF127E; Mon, 21 Jan 2013 15:34:00 +0900 (JST) Received: from UTMC1123.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id C597E18BC; Mon, 21 Jan 2013 15:33:56 +0900 (JST) Received: from LTMC1006.kddi.com (unknown [10.5.16.217]) by UTMC1123.kddi.com (Postfix) with ESMTP id 983CF1BDF; Mon, 21 Jan 2013 15:33:56 +0900 (JST) Received: from LTMC1006.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r0L6XuUK001413; Mon, 21 Jan 2013 15:33:56 +0900 Received: from LTMC1006.kddi.com.mid_14028197 (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r0L6SfYC029163; Mon, 21 Jan 2013 15:28:41 +0900 Received: from KDDI-0803PC0021 ([10.200.131.200] [10.200.131.200]) by post-zip.kddi.com with ESMTPA; Mon, 21 Jan 2013 15:28:41 +0900 To: PPan@infinera.com, agmalis@gmail.com From: Masahiro DAIKOKU References: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> <9664F6FD-51A6-4689-98A8-25B8B410BBE0@infinera.com> In-Reply-To: <9664F6FD-51A6-4689-98A8-25B8B410BBE0@infinera.com> Message-Id: <201301211528.FIH17123.PTVNELLtJB@kddi.com> X-Mailer: Winbiff [Version 2.51 PL4] X-Accept-Language: ja,en,zh Date: Mon, 21 Jan 2013 15:28:41 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SA-MID: 14028197 X-WAuditID: 1301211533560000311798 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] working group last call X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ms-daikoku@kddi.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 06:34:03 -0000 Support > +1 > > On Jan 16, 2013, at 3:20 AM, "Andrew G. Malis" > wrote: > > This draft has very useful use cases and is ready for forwarding to the IESG. > > > On Mon, Jan 14, 2013 at 11:40 AM, > wrote: > Working Group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-tp-use-cases-and-design. > > This is the second time we working group last call this > draft, it has been updated after comments during the > ADE-review. The changes are such that we have decided to > do a full two week wglc. > > 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. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not aware > of any IPRs. > > This working group last call will end on January 25, 2013. > > /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 ryoo@etri.re.kr Mon Jan 21 00:13:07 2013 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 7D15821F8867 for ; Mon, 21 Jan 2013 00:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.273 X-Spam-Level: X-Spam-Status: No, score=-89.273 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_72=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_KS5601=0.222, 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 gkr2-mn+WV35 for ; Mon, 21 Jan 2013 00:13:06 -0800 (PST) Received: from mailx.etri.re.kr (mailx.etri.re.kr [129.254.38.251]) by ietfa.amsl.com (Postfix) with ESMTP id DB7BB21F8865 for ; Mon, 21 Jan 2013 00:13:05 -0800 (PST) Received: from SMTPEG2.etri.info (ssbmailx [127.0.0.1]) by mailx.etri.re.kr (8.13.8/8.13.8) with ESMTP id r0L8Cwve032152; Mon, 21 Jan 2013 17:12:58 +0900 Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 21 Jan 2013 17:13:02 +0900 Received: from SMTP2.etri.info ([169.254.2.197]) by SMTP3.etri.info ([169.254.4.137]) with mapi id 14.01.0355.002; Mon, 21 Jan 2013 17:12:46 +0900 From: "Ryoo, Jeong-dong" To: =?ks_c_5601-1987?B?8fTx2vfu?= , "mpls@ietf.org" Thread-Topic: [mpls] doubt about RFC6378. Thread-Index: AQHN9RtU8ocqvQTkj06wXuP1UpukBZhTaj5T Date: Mon, 21 Jan 2013 08:12:45 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A0DF06078@SMTP2.etri.info> References: 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_5B4A6CBE3924BB41A3BEE462A8E0B75A0DF06078SMTP2etriinfo_" MIME-Version: 1.0 Subject: [mpls] =?ks_c_5601-1987?b?yLi9xTogIGRvdWJ0IGFib3V0IFJGQzYzNzgu?= 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, 21 Jan 2013 08:13:07 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A0DF06078SMTP2etriinfo_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBKdW5ibyBhbmQgdGhlIGF1dGhvcnMgb2YgUFNDIFJGQywNCg0KSW4gbXkgb3Bpbmlvbiwg dGhlIGdsaXRjaCBpbiBGaWd1cmUgNCBpbiB0aGUgcHJldmlvdXMgSnVuYm8ncyBlbWFpbCBjYW4g YmUgdGhlIG9uZSB3ZSBoYXZlIHRvIGJlYXIgd2l0aCB0aGUgc2luZ2xlLXBoYXNlIHByb3RvY29s LCB3aG9zZSB0cmFmZmljIGNhbiBiZSBkaXNydXB0ZWQgdXB0byBSVFQgKHJvdW5kIHRyaXAgdGlt ZSkuDQoNCklmIHRoZSBvcGVyYXRpb25zIGRlc2NyaWJlZCBpbiBGaWd1cmUgNSBzaG91bGQgYmUg cmVxdWlyZWQsIHRoZW4gdGhlIFBTQyBSRkMgbmVlZHMgdG8gYmUgYW1lbmRlZCBpbiB0d28gcG9p bnRzOg0KMS4gdGhlIHJlZXZhbHVhdGlvbiB3aXRoIHRoZSBsYXN0IHJlY2VpdmVkIFBTQyBtZXNz YWdlIHdoZW4gbG9jYWwgbm9kZSB0cmllcyB0byBlbnRlciBOb3JtYWwgc3RhdGUgKGN1cnJlbnRs eSwgdGhlIFBTQyBSRkMgZGVzY3JpYmVzIHRoZSByZWV2YWx1YXRpb24gaXMgcGVyZm9ybWVkIHZp YSBjaGVja2luZyB0aGUgcGVyc2lzdGVudCBzdGF0ZSBvZiB0aGUgbG9jYWwgdHJpZ2dlcnMuIFNl ZSB0aGUgZmlyc3Qgc2VudGVuY2Ugb2YgdGhlIHNlY29uZCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA0 LjMuMy4xLiksIGFuZA0KMi4gdHJhbnNtaXR0aW5nIE1TKDEsMSkgaW5zdGVhZCBvZiBOUigwLDEp IGluIHRoZSBmaXJzdCBzZW50ZW5jZSBpbiBwYWdlIDI4IG9mIHRoZSBQU0MgUkZDLg0KDQpBbm90 aGVyIHNvbHV0aW9uIChiZXR0ZXIgc29sdXRpb24gaW4gbXkgb3BpbmlvbikgdG8gYXZpb2QgdGhl IGdsaXRjaCBpbiBGaWd1cmUgNCBtaWdodCBiZSBvdmVycnVsaW5nIGFuZCBmb3JnZXR0aW5nIGFu eSBleGlzdGluZyBsb3dlciBwcmlvcml0eSBsb2NhbCBjb21tYW5kcyB3aGVuIGEgaGlnaGVyIHBy aW9yaXR5IHJlbW90ZSByZXF1ZXN0IGFycml2ZXMuDQoNCkJlc3QgcmVnYXJkcywNCg0KSmVvbmct ZG9uZw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrq4s70gu+e29yA6 ICLx9PHa9+4iIDx6amJkYW1vQGhvdG1haWwuY29tPg0KurizvSCzr8KlIDogMjAxMy0wMS0xOCAx MDoyOTo1OCAoICswOTowMCApDQq53rTCILvntvcgOiBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYu b3JnPg0KwvzBtiA6DQrBprjxIDogW21wbHNdIGRvdWJ0IGFib3V0IFJGQzYzNzguDQoNCg0KDQoo aGksZXJpYyBhbmQgeWFhY292LGkgZG9uJ3Qga25vdyB3aHkgaSBjYW4ndCByZXBseSB0aGUgdG9w aWMgdGhhdCB3ZSBkaXNjdXNzZWQgYmVmb3JlLS0tIiBpbiBzb21lIHNjZW5hcmlvIFJGQzYzNzgg Y2FuIG5vdCBwcm90ZWN0IHRoZSB0cmFmZmljLCBzbyBtdWNoIGFzIHRha2UgdGhlIFBTQyBzdGF0 ZSB0byBjcmFzaCIuIGFuZCBpIGhhdmUgdG8gY3JlYXRlIGEgbmV3IHRvcGljIHRvIGNvbnRpbnVl IHRoZSBkaXNjdXNzaW9uLnRoZSBsYXRlc3QgZGlzY3Vzc2lvbiByZWNvcmRzIGlzIGhlcmUNCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMDkzNjcu aHRtbA0KdGhlIGZvbGxvd2luZyBpcyBteSBsYXRlc3QgcmVwbHksYW5kIGlmIGZpZ3VyZXMgY2Fu IG5vdCBiZSBkaXNwbGF5ZWQgbm9ybWFsbHksIHBsZWFzZSBzZWUgdGhlIGF0dGFjaCBmaWxlLikN Cg0KeWVzLGl0IHdpbGwgZml4IHNvbWUgYnVncyBpbiBQU0MsY29tcGFyZSB0aGUgZm9sbG93aW5n IDIgZmlndXJlcy4NCmluIGZpZ3VyZTQud2hlbiBMRVIxIHJlY2VpdmUgcGVlcidzIEZTIFBTQyBt c2csYWNjb3JkaW5nIHRvIFJGQzYzNzgsTEVSMSB3aWxsIHNlbmQgTlIgdG8gTEVSMixhbmQgd2hl biBjbGVhciBjb21tYW5kIGlucHV0IGludG8gTEVSMixMRVIyIHdpbGwgdHJhbnNmZXIgaW50byBO T1JNQUwgc3RhdGUgYW5kIHN3aXRjaCB0cmFmZmljIHRvIHdvcmsgcGF0aCxidXQgTEVSMSdzIHRy YWZmaWMgc3RpbGwgb24gcHJvdGVjdGlvbiBwYXRoLiBzbyB0cmFmZmljIGlzIGJyb2tlbi53aGVu IHRoZSBOUiByZWFjaCBMRVIxLExFUjEgcmVldmFsdWF0ZSBhbGwgaW5wdXRzIGFuZCB0cmFuc2Zl ciBpbmZvIFBBOk06TCxrZWVwIHRyYWZmaWMgb24gcHJvdGVjdGlvbiBhbmQgc2VuZCBNUyB0byBM RVIyLndoZW4gTVMgcmVhY2ggTEVSMix0aGUgdHJhZmZpYyBpcyByZXN0b3JlZC4NCg0KaW4gZmln dXJlNSxMRVIxIHdpbGwgc3RpbGwgc2VuZCBoaXMgbG9jYWwgaGlnaGVzdCBwcmlvcml0eSBjb25k aXRpb24gKGluIHRoaXMgZXhhbXBsZSxpdCBpcyBNUykgdG8gcGVlciB3aGVuIHJlY2VpdmUgRlMg ZnJvbSBMRVIyLmFuZCB3aGVuIGNsZWFyIGNvbW1hbmQgaW5wdXQgaW50byBMRVIyLExFUjIgd2ls bCB0cmFuc2ZlciBpbmZvIFBBOk06UiBhbmQga2VlcCB0cmFmZmljIG9uIHByb3RlY3Rpb24gcGF0 aCBhbmQgbmV2ZXIgYmUgYnJva2VuLg0KDQppIHRoaW5rIHNpbXBsZSBpcyBiZWF1dGlmdWwuDQoN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKyAgICAgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICB8IExFUjEgfCAgICAgICAg ICAgICAgICAgICAgICAgICB8IExFUjIgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICArLS0t Ky0tKyAgICAgICAgICAgICAgICAgICAgICAgICArLS0tKy0tKw0KICAgICAgICAgICAgICAgICAg ICAgICAgIE4gICAgKy0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgTg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS1OUi0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgIGxvY2FsIE1TIGNvbW1hbmQgaW5wdXQgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAg ICAgUEE6TTpMICAgKy0tLS0tLS0tLS0tTVMtLS0tLS0tLS0tLS0tLS0tLS0+fCAgUEE6TTpSDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0t LU5SLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBsb2NhbCBGUyBjb21tYW5kIGlucHV0 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgIFBBOkY6UiB8PC0tLS0tLS0tLUZTLS0t LS0tLS0tLS0tLS0tLS0tLS0rIFBBOkY6TA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCBsb2NhbCBjbGVhciBpbnB1dCx0cmFuc2ZlciBpbmZvDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLU5SLS0tLS0tLS0tLS0tLS0t LS0tLS0rIE4sIHN3aXRjaCB0cmFmZmljIHRvIHdvcmsgcGF0aC4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIHRyYWZmaWMg aXMgYnJva2VuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICByZWV2YWx1YXRlIGFsbCBpbnB1dCBhbmQg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB0cmFuc2ZlciBpbmZvICAg UEE6TTpMICAgICArLS0tLS0tLS0tLU1TLS0tLS0tLS0tLS0tLS0tLS0tLT58UEE6TV9SDQoga2Vl cCB0cmFmZmljIG9uIHByb3RlY3Rpb24gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8TEVSMiB3aWxsIHN3aXRjaCB0cmFmZmljIHRvDQogICAgICAgcGF0aCAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8cHJvdGVjdGlvbiBwYXRoLHRy YWZmaWMgaXMgcmVzdG9yZWQuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8PC0tLS0tLS0tLS0tTlItLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoN CiAgICAgICAgICAgIGZpZ3VyZSA0OnNlbmQgTlIgdG8gcmVhY3Rpb24gd2hlbiBwZWVyIGlzIGhp Z2hlciBwcmlvcml0eSB3aWxsIG1ha2UgdHJhZmZpYyBicm9rZW4gYWNjaWRlbnRhbGx5DQoNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAg ICArLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICB8IExFUjEgfCAgICAgICAgICAg ICAgICAgICAgICAgICB8IExFUjIgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tKy0t KyAgICAgICAgICAgICAgICAgICAgICAgICArLS0tKy0tKw0KICAgICAgICAgICAgICAgICAgICAg ICAgIE4gICAgKy0tLS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgTg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS1OUi0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgICAgIGxvY2FsIE1TIGNvbW1hbmQgaW5wdXQgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAg UEE6TTpMICAgKy0tLS0tLS0tLS0tTVMtLS0tLS0tLS0tLS0tLS0tLS0+fCAgUEE6TTpSDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLU5S LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBsb2NhbCBGUyBjb21tYW5kIGlucHV0DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgIFBBOkY6UiB8PC0tLS0tLS0tLUZTLS0tLS0t LS0tLS0tLS0tLS0tLS0rIFBBOkY6TA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS1NUy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCBsb2NhbCBjbGVhciBpbnB1dCxyZWV2YWx1YXRlIGFsbCBpbnB1 dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS1OUi0tLS0tLS0tLS0t LS0tLS0tLS0tKyB0cmFuc2ZlciBpbmZvIFBBOk06UiBrZWVwIHRyYWZmaWMgb24NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg IHByb3RlY3Rpb24gcGF0aC4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHJlZXZhbHVhdGUgYWxsIGlucHV0IGFuZCAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHRyYW5zZmVyIGluZm8gIFBB Ok06TCAgICAgICstLS0tLS0tLS0tTVMtLS0tLS0tLS0tLS0tLS0tLS0tPnxQQTpNX1INCiBrZWVw IHRyYWZmaWMgb24gcHJvdGVjdGlvbiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICBwYXRoICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8LS0t LS0tLS0tLS1OUi0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCg0KDQogICAg ICAgICAgICBmaWd1cmUgNTphbHdheXMgc2VuZCBsb2NhbCBoaWdoZXN0IHByaW9yaXR5IGNvbmRp dGlvbiB0byBwZWVyLHdpbGwgbmV2ZXIgYnJva2VuIHRyYWZmaWMgYWNjaWRlbnRhbGx5DQoNCg0K QmVzdCBSZWdhcmRzIQ0KDQpKdW5ibyBaZW5nKEJvQm8pDQoNCg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A0DF06078SMTP2etriinfo_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
Dear Junbo and the authors of PSC RFC,
 
In my opinion, the glitch in Figure 4 in t= he previous Junbo's email can be the one we have to bear wit= h the single-phase protocol, whose traffic can be disrupted upto&= nbsp;RTT (round trip time).
  
If the operations described in Figure 5&nb= sp;should be required, then the PSC RFC needs to be amended in two poi= nts:
1. the reevaluation with the last rec= eived PSC message when local node tries to enter Normal stat= e (currently, the PSC RFC describes the reevaluation is performed = ;via checking the persistent state of the local triggers. See the first sentence of the second paragraph in Section 4.3.3.1.), and 
2. transmitting MS(1,1) instead of NR= (0,1) in the first sentence in page 28 of the PSC RFC.
 
Another solution (better solution in my op= inion) to aviod the glitch in Figure 4 might be overruling and forgett= ing any existing lower priority local commands when a higher priority remot= e request arrives. 
 
Best regards,
 
Jeong-dong
    


=BA=B8=B3=BD =BB=E7=B6=F7 : "= =F1=F4=F1=DA=F7=EE" <zjbdamo@hotmail.com>
=BA=B8=B3=BD =B3=AF=C2=A5 : 2013-01-18 10:29:58 ( +09:00 )
=B9=DE=B4=C2 =BB=E7=B6=F7 : mpls@ietf.org <mpls@ietf.org>
=C2=FC=C1=B6 :
=C1=A6=B8=F1 : [mpls] doubt about RFC6378.



(hi,eric and yaacov,i don't know why i can't reply the topic that we discus= sed before---" in some scenario RFC6378 can not protect the traffic, s= o much as take the PSC state to crash". and i have to create a new top= ic to continue the discussion.the latest discussion records is here
http://www.ietf.org/mail-archive/web/mpls/current/msg09367.html
the following is my latest reply,and if figures can not be displayed normal= ly, please see the attach file.)

yes,it will fix some bugs in PSC,compare the following 2 figures.
in figure4.when LER1 receive peer's FS PSC msg,according to RFC6378,LER1 wi= ll send NR to LER2,and when clear command input into LER2,LER2 will transfe= r into NORMAL state and switch traffic to work path,but LER1's traffic stil= l on protection path. so traffic is broken.when the NR reach LER1,LER1 reevaluate all inputs and transfer i= nfo PA:M:L,keep traffic on protection and send MS to LER2.when MS reach LER= 2,the traffic is restored.
 
in figure5,LER1 will still send his local highest priority condition (in th= is example,it is MS) to peer when receive FS from LER2.and when clear comma= nd input into LER2,LER2 will transfer info PA:M:R and keep traffic on prote= ction path and never be broken.
 
i think simple is beautiful.
 
 
            &nb= sp;            = +------+         &nbs= p;            &= nbsp;  +------+
            &nb= sp;            = | LER1 |           =             &nb= sp; | LER2 |
            &nb= sp;            = +---+--+         =             &nb= sp;   +---+--+
            &nb= sp;            N&nbs= p;   +----------NR------------------->|  N
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |<---------NR--------------------+
       local MS command input |  &n= bsp;            = ;            &n= bsp;    |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;        PA:M:L   +-----= ------MS------------------>|  PA:M:R
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |<---------NR--------------------+
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |  loca= l FS command input
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;          PA:F:R |<-----= ----FS--------------------+ PA:F:L
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      +-------NR---------------------->|
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           | local clea= r input,transfer info
            &nb= sp;            =      |<---------NR--------------------+ N, switc= h traffic to work path.
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |  traf= fic is broken
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
   reevaluate all input and   |    =             &nb= sp;            =    |
   transfer info   PA:M:L     += ----------MS------------------->|PA:M_R
 keep traffic on protection   |     = ;            &n= bsp;            = ;  |LER2 will switch traffic to
       path     &nbs= p;             = |            &n= bsp;            = ;       |protection path,traffic is restored.=
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |<-----------NR------------------+
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
 
            figure 4= :send NR to reaction when peer is higher priority will make traffic broken = accidentally
 
 
            &nb= sp;            = +------+         &nbs= p;            &= nbsp;  +------+
            &nb= sp;            = | LER1 |           =             &nb= sp; | LER2 |
            &nb= sp;            = +---+--+         =             &nb= sp;   +---+--+
            &nb= sp;            N&nbs= p;   +----------NR------------------->|  N
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |<---------NR--------------------+
       local MS command input |  &n= bsp;            = ;            &n= bsp;    |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;        PA:M:L   +-----= ------MS------------------>|  PA:M:R
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |<---------NR--------------------+
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |  loca= l FS command input
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;          PA:F:R |<-----= ----FS--------------------+ PA:F:L
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      +-------MS---------------------->|
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           | local clea= r input,reevaluate all input
            &nb= sp;            =      |<---------NR--------------------+ transfer= info PA:M:R keep traffic on
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |  prot= ection path.
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
   reevaluate all input and   |    =             &nb= sp;            =    |
   transfer info  PA:M:L      += ----------MS------------------->|PA:M_R
 keep traffic on protection   |     = ;            &n= bsp;            = ;  |
       path     &nbs= p;             = |            &n= bsp;            = ;       |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |<-----------NR------------------+
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
            &nb= sp;            =      |        &= nbsp;           &nbs= p;           |
 
 
            figure 5= :always send local highest priority condition to peer,will never broken tra= ffic accidentally
 
 
Best Regards!

Junbo Zeng(BoBo)


--_000_5B4A6CBE3924BB41A3BEE462A8E0B75A0DF06078SMTP2etriinfo_-- From loa@pi.nu Mon Jan 21 01:50:58 2013 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 1764F21F84CC for ; Mon, 21 Jan 2013 01:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 jJSwdyVMZMwR for ; Mon, 21 Jan 2013 01:50:57 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 853B121F84CA for ; Mon, 21 Jan 2013 01:50:57 -0800 (PST) Received: from [192.168.1.104] (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 A255A7FE07; Mon, 21 Jan 2013 10:50:55 +0100 (CET) Message-ID: <50FD0F81.4010509@pi.nu> Date: Mon, 21 Jan 2013 10:50:57 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-villamizar-mpls-multipath-use@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] IPR poll on draft-villamizar-mpls-multipath-use 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, 21 Jan 2013 09:50:58 -0000 Working Group and authors; The authors of draft-villamizar-mpls-multipath-use has indicated that the draft is ready to be adopted as a working group document. Before starting the poll to see if there is wg consensus to make the draft 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-villamizar- mpls-multipath-use? 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. Note: There were an IPR disclosure on an earlier document "draft-villamizar-mpls-tp-multipath" that IPR is not applicable to this document. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From loa@pi.nu Mon Jan 21 02:05:21 2013 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 B04E421F85A2 for ; Mon, 21 Jan 2013 02:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 uqrJZSAjjoNr for ; Mon, 21 Jan 2013 02:05:21 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 048BA21F86B6 for ; Mon, 21 Jan 2013 02:05:19 -0800 (PST) Received: from [192.168.1.104] (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 A78877FE07; Mon, 21 Jan 2013 11:05:15 +0100 (CET) Message-ID: <50FD12DD.8050709@pi.nu> Date: Mon, 21 Jan 2013 11:05:17 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 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-ldp-multi-topology@tools.ietf.org Subject: [mpls] working group last call on draft-ietf-mpls-ldp-multi-topology 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, 21 Jan 2013 10:05:22 -0000 Working Group, this is to start a two week Working Group last call on draft-ietf-mpls-ldp-multi-topology. 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. There are IPR claims against this draft, IPR disclosures #1707 and #1875. All the co-authors has stated that they are not aware of any IPRs other than the ones that has been disclosed. This working group last call will end on February 2, 2013. /Loa for the wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From mach.chen@huawei.com Mon Jan 21 02:05:26 2013 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 C619921F86E6 for ; Mon, 21 Jan 2013 02:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 yN5gP8heVfDJ for ; Mon, 21 Jan 2013 02:05:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3621F86DD for ; Mon, 21 Jan 2013 02:05:25 -0800 (PST) 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 ANS66688; Mon, 21 Jan 2013 10:05:24 +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.7; Mon, 21 Jan 2013 10:05:15 +0000 Received: from SZXEML453-HUB.china.huawei.com (10.82.67.196) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 21 Jan 2013 10:05:23 +0000 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.33]) by SZXEML453-HUB.china.huawei.com ([10.82.67.196]) with mapi id 14.01.0323.007; Mon, 21 Jan 2013 18:03:59 +0800 From: Mach Chen To: "draft-villamizar-mpls-multipath-use@tools.ietf.org" , "" , Martin Vigoureux Thread-Topic: MPLS-RT review of draft-villamizar-mpls-multipath-use Thread-Index: Ac33vqG/XaAhVQmsSZecdBf2MY8Bkw== Date: Mon, 21 Jan 2013 10:03:59 +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.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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, 21 Jan 2013 10:05:26 -0000 Hi, I was selected as an MPLS-RT team reviewer for draft-villamizar-mpls-multip= ath-use. I read the draft and think it is a useful draft that discusses a real issue= . I think that this draft is ready to be considered for WG adoption. At sam= e time, the draft also needs more work to make it more clear, especially fo= r Section 3.=20 Here are my comments: 1. Section 3,=20 The 1th para after the 4 requirements, this para talks how to satisfy MP#1,= but at the end of this para, it starts to talk about Entropy label but wit= h limited text. Not sure the entropy label is an alternative solution to sa= tisfy MP#1 or entropy label is an alternative idea to make sure the MPLS-TP= payload and OAM packets have the same path. I guess it's later. So, I'd su= ggest to remove the last sentence or move it the 3rd para after the 4 requi= rements.=20 2. I am not sure why MP#3 is a requirement, the result should be no differe= nt from the situation where a component link is failed and the MPLS-TP LSP = is then moved to other links, a potential temp "out of order" may occur and= IMHO this is acceptable.=20 In addition, there are some nits like redundant/missing words, for example:= the abstract Section: s/MPLS can LSP can/MPLS LSP can Best regards, Mach From stbryant@cisco.com Mon Jan 21 02:39:09 2013 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 0328121F8619 for ; Mon, 21 Jan 2013 02:39:09 -0800 (PST) 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=[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 kskUxWgFkLK5 for ; Mon, 21 Jan 2013 02:39:08 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA8F21F8600 for ; Mon, 21 Jan 2013 02:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15495; q=dns/txt; s=iport; t=1358764747; x=1359974347; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=xE1zSG44OK2FEUe0YkZcrFch5eYTf+TO0spBjSGGnzU=; b=NWGQt5qT+xglfouQOA9v9dCKHcBWXshT3lWsAHvMCV/DMEYSk31DDj2a IWmlHdYLKb94GtsYaL/IBsVsvgpxZxAtc0k10EHxFoZwl2NdbdBLLoNB2 fu/IxoX0r2pDbAQdnlfEo1SAqviV0ArZZ2FSWaEISN2lUymfGOKtXQhni Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAH4a/VCQ/khM/2dsb2JhbABEgkiJWbALggEWc4IeAQEBBAEBASpBCgEOAgsYCRYEBAcJAwIBAgEJDB8RBg0BBQIBAYgVDLsIBIx9hDgDlgyBHI8tgnWBbw X-IronPort-AV: E=Sophos;i="4.84,505,1355097600"; d="scan'208,217";a="11219119" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 21 Jan 2013 10:39:06 +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 r0LAd5hU028187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jan 2013 10:39:05 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r0LAd4ot025468; Mon, 21 Jan 2013 10:39:04 GMT Message-ID: <50FD1AC8.4070309@cisco.com> Date: Mon, 21 Jan 2013 10:39:04 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Daniele Ceccarelli References: <50E5E64A.8090105@pi.nu> <4A1562797D64E44993C5CBF38CF1BE4805E29A@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4805E29A@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------040604060809010008000304" Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-fbb-mpls-tp-p2mp-framework-06.txt an MPLS wg document 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, 21 Jan 2013 10:39:09 -0000 This is a multi-part message in MIME format. --------------040604060809010008000304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We will take a look at the points below as part of -01. - Stewart On 10/01/2013 17:58, Daniele Ceccarelli wrote: > Yes/Support > with some very minor comments/suggestions: > BR > Daniele > 1 . > MPLS TE-LSP support is discussed in [RFC4875] and > [RFC5332], and PW support is being developed based on > [I-D.ietf-pwe3-p2mp-pw-requirements] and > [I-D.ietf-l2vpn-vpms-frmwk-requirements]. > I'd say that P2MP MPLS TE-LSP support is discussed...and P2MP PW > support.... > 2. > MPLS-TP point-to- > multipoint connectivity is analogous to that provided by traditional > transport technologies such as Optical Transport Network (OTN) point- > to-multipoint [ref?] and optical drop-and-continue [ref?], and thus > supports the same class of traditional applications. > Maybe it could be worth listing which this applications are? > 3. > > Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS > recovery, [RFC4872] and [RFC4873], do not explicitly cover their > interactions. MPLS-TP requires a formal definition of recovery > techniques for P2MP LSPs. Such a formal definition will be based on > existing RFCs and may not require any new protocol mechanisms but, > nonetheless, should be documented. > Is there any plan to document it in this ID o somewhere else? if so, where? RFC6372 only provides protection considerations, what about restoration? > > On Thu, Jan 3, 2013 at 3:12 PM, Loa Andersson > wrote: > > Working group, > > This is to start a two week poll on adopting > draft-fbb-mpls-tp-p2mp-framework-06 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 January 17, 2013. > > There are no IPR claim against this document. > > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. > > /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 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------040604060809010008000304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
We will take a look at the points below as part of -01.

- Stewart

On 10/01/2013 17:58, Daniele Ceccarelli wrote:
 Yes/Support
 
with some very minor comments/suggestions:
 
BR
Daniele
 
1 .
   MPLS TE-LSP support is discussed in [RFC4875] and
   [RFC5332], and PW support is being developed based on
   [I-D.ietf-pwe3-p2mp-pw-requirements] and
   [I-D.ietf-l2vpn-vpms-frmwk-requirements].
I'd say that P2MP MPLS TE-LSP support is discussed...and P2MP PW support....
 
2.
   MPLS-TP point-to-
   multipoint connectivity is analogous to that provided by traditional
   transport technologies such as Optical Transport Network (OTN) point-
   to-multipoint [ref?] and optical drop-and-continue [ref?], and thus
   supports the same class of traditional applications.
 
Maybe it could be worth listing which this applications are?
3. 
 
Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS
   recovery, [RFC4872] and [RFC4873], do not explicitly cover their
   interactions.  MPLS-TP requires a formal definition of recovery
   techniques for P2MP LSPs.  Such a formal definition will be based on
   existing RFCs and may not require any new protocol mechanisms but,
   nonetheless, should be documented. 
Is there any plan to document it in this ID o somewhere else? if so, where? RFC6372 only provides protection considerations, what about restoration?
 
On Thu, Jan 3, 2013 at 3:12 PM, Loa Andersson <loa@pi.nu> wrote:

Working group,

This is to start a two week poll on adopting
draft-fbb-mpls-tp-p2mp-framework-06 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 January 17, 2013.

There are no IPR claim against this document.

All the active co-authors has stated on the working group mailing list
that they are not aware of any other IPR claims than those already
disclosed.

/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

 



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------040604060809010008000304-- From internet-drafts@ietf.org Mon Jan 21 03:02:37 2013 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 BEC5A21F84F0; Mon, 21 Jan 2013 03:02:37 -0800 (PST) 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 c5niiBqAxHZJ; Mon, 21 Jan 2013 03:02:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F4E21F84DC; Mon, 21 Jan 2013 03:02:37 -0800 (PST) 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.37 Message-ID: <20130121110237.7916.55261.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2013 03:02:37 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-p2mp-framework-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, 21 Jan 2013 11:02:37 -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 : A Framework for Point-to-Multipoint MPLS in Transport Ne= tworks Author(s) : Dan Frost Stewart Bryant Matthew Bocci Lou Berger Filename : draft-ietf-mpls-tp-p2mp-framework-00.txt Pages : 13 Date : 2013-01-21 Abstract: The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture applicable specifically to supporting point-to- multipoint transport paths. 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-p2mp-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-p2mp-framework-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietfc@btconnect.com Mon Jan 21 06:40:39 2013 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 57F3821F84B2 for ; Mon, 21 Jan 2013 06:40:39 -0800 (PST) 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 ph7hn2dgZ1CT for ; Mon, 21 Jan 2013 06:40:38 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 952E021F8499 for ; Mon, 21 Jan 2013 06:40:38 -0800 (PST) Received: from mail99-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Mon, 21 Jan 2013 14:40:38 +0000 Received: from mail99-tx2 (localhost [127.0.0.1]) by mail99-tx2-R.bigfish.com (Postfix) with ESMTP id 167384A01CA; Mon, 21 Jan 2013 14:40:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371Ic89bh936eI542I1432I1418Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h304l1155h) Received: from mail99-tx2 (localhost.localdomain [127.0.0.1]) by mail99-tx2 (MessageSwitch) id 1358779236363897_17864; Mon, 21 Jan 2013 14:40:36 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.252]) by mail99-tx2.bigfish.com (Postfix) with ESMTP id 540DD440163; Mon, 21 Jan 2013 14:40:36 +0000 (UTC) Received: from AMXPRD0711HT001.eurprd07.prod.outlook.com (157.56.250.69) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 21 Jan 2013 14:40:35 +0000 Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.242.9.162) with Microsoft SMTP Server (TLS) id 14.16.257.4; Mon, 21 Jan 2013 14:40:32 +0000 Message-ID: <018801cdf7e4$e70b6420$4001a8c0@gateway.2wire.net> From: t.petch To: References: <20130115124143.12114.44371.idtracker@ietfa.amsl.com> <50F55175.5080106@gmail.com> <000d01cdf586$49f18440$4001a8c0@gateway.2wire.net> <50FC5869.1020600@gmail.com> Date: Mon, 21 Jan 2013 14:35:43 +0000 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.248.133] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-08.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, 21 Jan 2013 14:40:39 -0000 ----- Original Message ----- From: "Huub van Helvoort" To: "t.petch" Cc: Sent: Sunday, January 20, 2013 8:49 PM Hello Tom, Sorry for that. I have uploaded draft-ietf-mpls-tp-rosetta-stone-09 to fix these issues after double checking and unscrewing. Huub Thanks for that - definitely not so kinky. My big comment is that I would like all the entries in section 3 in alphabetic order. Technically, it makes no difference but to the user, I think it would be a big improvement. At the moment, it is like turning to an English dictionary that is divided into sections and needing to know whether a word derives from Greek or Arabic, Sanskrit or Chinese, in order to know which section it is in. The fact that the first half is in alphabetic order just makes it harder to use - if the ordering were seemingly random, it would be less of a problem! Lesser comments. PST and SPME have made it into significant MPLS-TP RFC and will be there for ever. I would like (deprecated) entries for these in this. 3.12 CE is not expanded anywhere 3.16 spurious period after the reference 3.43 an MEG??? 3.43 et seq. The various ME entries lack any references; since ME seems to me to have been the most troublesome aspect of MPLS-TP and one that still leads to errors, such as the erroneous expansion of MEP, I think that these entries above all need references. 3.45 This is a comprehensive entry and yet ... TCM is not expanded anywhere - I think it deserves an entry of its own. Statements like "A MEP terminates all the OAM packets that it receives" makes me think 'from where?' do I really understand this? while "MPLS-TP MEP notifies a fault indication" seems odd in highlighting just one aspect of a MEP's functionality; again, why that? 5 Operations and Management (OAM) I love it - could we push for this usage to be adopted across the IETF:-) I would like a reference for this section - there are a number of OAM RFC to choose from, e.g. framework, analysis, requirements. 6 I would like a reference for this section, perhaps the just-WGLC'd draft-ietf-mpls-tp-security-framework 9 I do like alphabetic order, for references as well (a comment I saw recently from a GenArt reviewer). Overall, it remains an impressive piece of work. Tom Petch Regards, Huub. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Um; I am still seeing > > [RFC....]. > > <> > > Error! Reference source not found., Error! > Reference source not found., and Error! Reference source not found.. > ITU-T Recommendation Error! Reference source not found > > which suggests to me that a little more unscrewing is in order. > > Tom Petch > > ----- Original Message ----- > From: "Huub van Helvoort" > Cc: > Sent: Tuesday, January 15, 2013 12:54 PM > Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-rosetta-stone-08.txt > > >> Sorry, >> >> I had to re-spin. MS messed up the references. >> >> Regards, Huub. >> >> >>> >>> 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 : A Thesaurus for the Terminology used in > Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs > and ITU-T's Transport Network Recommendations. >>> Author(s) : Huub van Helvoort >>> Loa Andersson >>> Nurit Sprecher >>> Filename : draft-ietf-mpls-tp-rosetta-stone-08.txt >>> Pages : 18 >>> Date : 2013-01-15 >>> >>> Abstract: >>> MPLS-TP is based on a profile of the MPLS and PW procedures as >>> specified in the MPLS-TE and (MS-)PW architectures developed by > the >>> IETF. The ITU-T has specified a Transport Network architecture. >>> >>> This document provides a thesaurus for the interpretation of > MPLS-TP >>> terminology within the context of the ITU-T Transport Network >>> recommendations. >>> >>> It is important to note that MPLS-TP is applicable in a wider > set of >>> contexts than just Transport Networks. The definitions > presented in >>> this document do not provide exclusive nor complete > interpretations >>> of MPLS-TP concepts. This document simply allows the MPLS-TP > terms >>> to be applied within the Transport Network context. >>> > > -- ***************************************************************** =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 From lufang@cisco.com Mon Jan 21 09:29:13 2013 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 445C721F85CC for ; Mon, 21 Jan 2013 09:29:13 -0800 (PST) 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 Xl0AixNBxbPS for ; Mon, 21 Jan 2013 09:29:12 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 238B421F85B6 for ; Mon, 21 Jan 2013 09:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7056; q=dns/txt; s=iport; t=1358789352; x=1359998952; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ZPRdQWLtm+2xDb4KEiXeEmIL1haGJCzw+jOoUIKufCQ=; b=WpfKiTP9bvc0V+0WU9kJ5Y026OaL/CKjpaHf0Un8iJ0lHvNZPNtPp05j WURUPJ1ejZ8VANdqitTMbcb3kWgO2wsWaqK/PQx8lkSaWWc9J0EyByqX6 orQIpQvrhVyKbI++Zaf10maV9PQxLMVRtKoYAtF9JHWVMl0ytsAknUoVJ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKd5/VCtJV2a/2dsb2JhbABEvioWc4IeAQEBBAEBATctBwsMBgEIEQMBAQELFDEGCx0IAgQBDQUIh38DDwyyNw2IXgSMCYRPYQOUNo0NhRKCdYIk X-IronPort-AV: E=Sophos;i="4.84,508,1355097600"; d="scan'208";a="165485995" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 21 Jan 2013 17:29:11 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0LHTAwA025700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jan 2013 17:29:11 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 21 Jan 2013 11:29:10 -0600 From: "Luyuan Fang (lufang)" To: "t.petch" , "huubatwork@gmail.com" , "loa@pi.nu" Thread-Topic: [mpls] working group last call Thread-Index: AQHN9PVnO9NeXmS+hEuIsU0xoNTiYphUIHsA Date: Mon, 21 Jan 2013 17:29:09 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931026817B@xmb-rcd-x03.cisco.com> In-Reply-To: <001401cdf4f5$6c891360$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.124.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <0F36A726BA0BAC41B5F46C5A2CF31E15@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: Re: [mpls] working group last call 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, 21 Jan 2013 17:29:13 -0000 Hi Tom, Thank you for your review, comments, and suggestions. Please see in-line. -----Original Message----- From: "t.petch" Date: Thursday, January 17, 2013 12:58 PM To: "huubatwork@gmail.com" , "loa@pi.nu" Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: Re: [mpls] working group last call >----- Original Message ----- >From: "Huub van Helvoort" >To: >Cc: ; ; > >Sent: Wednesday, January 16, 2013 2:39 PM > >> Editors, >> >> You need to fix the acronym expansion for MEP and MIP: >> >> MEP Maintenance Entity Group End Point >> MIP Maintenance Entity Group Intermediate Point > >and, at the same time, that other hoary old chestnut >OAM Operations, Administration and Maintenance [luyuan] Yes, good point, will use the suggested text. > >On a slightly different tack, if Security Considerations calls out >[RFC5920] as >Normative (rightly so, IMO), then I think that [MPLS-TP Sec FW] must >also >be Normative. [luyuan] I'm OK with that, will check with Adrian and Loa too. > >And, while I am on, there are still a fair number of places where the >English >reads oddly. My sense was that Adrian, in August, provided a list of >some of the >instances where he saw that corrections would be beneficial but I think >that >his list was never meant to be inclusive. [luyuan] We actually made major effort in 03 to improve the 'entire' document=20 after Adrian made his comments on 02 version. You can check the diff between 03 and 02. > >For example, to take a paragraph at random, there is currently [luyuan] This paragraph was added in 05 just before the last call based on an operator's input. We can improve the text per your comments. > >OLD > Some operators are using the similar model as in 2G and 3G Mobile > Backhaul, which uses IP/MPLS in the core, and MPLS-TP with static > provisioning through NMS in aggregation and access. The reasoning is > the following: X2 traffic load in LTE network is currently a very > small percentage, e.g., some large mobile operator observed less than > one percent of total S1 traffic. Therefore, optimizing X2 traffic is > not the design objective, X2 traffic can be carried through the same > static tunnels together with S1 traffic in the aggregation and access > networks, and further forwarded accross IP/MPLS core. In addition, > Mesh protection may be more efficient in regard of bandwidth > utilization, but linear protection and ring protection are considered > simpler by some operators from operation maintenance and trouble > shooting point of view, therefore widely deployed. In general, using > MPLS-TP with NMS model for LTE backhaul is a viable approach. The > design objective of using this approach is to keep the operation > simple and with unified model for mobile backhaul. > >which, editing just the English and not the meaning, might produce, >with an asterisk(*) indicating a change > >NEW > Some operators are using the *same model as in 2G and 3G Mobile > Backhaul, which uses IP/MPLS in the core, and MPLS-TP with static > provisioning *(through NMS*) in aggregation and access. The >reasoning is > *as follows: *the X2 traffic load in LTE *networks is currently a >very > small percentage, e.g., some large mobile *operators *observe less >than > one percent of total S1 traffic. Therefore, optimizing X2 traffic is > not *a design objective*, X2 traffic can be carried through the same > static tunnels *as S1 traffic in the aggregation and access > networks, and forwarded *across *the IP/MPLS core. In >addition, > Mesh protection may be more efficient *with regard *to bandwidth > utilization, but linear protection and ring protection are considered > simpler by some operators from the *point of view of operation*, >maintenance and trouble > shooting *and so are widely deployed. In general, using > MPLS-TP with *static provisioning *(through NMS) for LTE backhaul is >a viable approach. The > design objective of using this approach is to keep the operation > simple and *use a *common model for mobile backhaul. > >Um; quite a few changes (or we could leave it to the RFC Editor). [luyuan] Thanks for your detailed suggestions and your discussion with me. Below is the proposed new text, which you are OK with. Some operators are using the same model as in 2G and 3G Mobile Backhaul, which uses IP/MPLS in the core, and MPLS-TP with static provisioning (through NMS) in aggregation and access. The reasoning is as follows: the X2 traffic load in LTE networks currently may be a very small percentage of the total traffic, e.g., a large mobile operator observed the X2 traffic was less than one percent of the total S1 traffic. Therefore, optimizing the X2 traffic may not the design objective in this case,=20 The X2 traffic can be carried through the same static tunnels together with the S1 traffic in the aggregation and access networks, and further forwarded=20 across the IP/MPLS core. In addition, mesh protection may be more efficient with regard to bandwidth utilization, but linear protection and ring protection are=20 often considered simpler by some operators from the point of view of operation maintenance and trouble shooting, and so are widely deployed. In general, using MPLS-TP with static provisioning for LTE backhaul is a viable option. The design objective of using this approach is to keep the operation simple and=20 use a common model for mobile backhaul, especially during the transition period. Thanks, Luyuan > >Tom Petch > >> Regards, Huub. >> >> =3D=3D=3D=3D=3D=3D >> >> > this is to start a two week Working Group last call on >> > draft-ietf-mpls-tp-use-cases-and-design. >> > >> > This is the second time we working group last call this >> > draft, it has been updated after comments during the >> > ADE-review. The changes are such that we have decided to >> > do a full two week wglc. >> > >> > 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. >> > >> > There are no IPR claims against this draft. >> > >> > All the co-authors has stated that they are not aware >> > of any IPRs. >> > >> > This working group last call will end on January 25, 2013. >> > >> > /Loa >> > for the wg co-chairs >> > >> > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Mon Jan 21 23:21:04 2013 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 F1D0221F882E; Mon, 21 Jan 2013 23:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 gu9Nygf0FlUD; Mon, 21 Jan 2013 23:21:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDBB21F8831; Mon, 21 Jan 2013 23:21:03 -0800 (PST) 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.37 Message-ID: <20130122072102.17309.91260.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2013 23:21:02 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-hello-crypto-auth-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: Tue, 22 Jan 2013 07:21:04 -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 Hello Cryptographic Authentication Author(s) : Lianshu Zheng Mach(Guoyi) Chen Manav Bhatia Filename : draft-ietf-mpls-ldp-hello-crypto-auth-01.txt Pages : 15 Date : 2013-01-21 Abstract: This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-hello-crypto-auth-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jan 22 07:14:48 2013 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 5154421F89BF; Tue, 22 Jan 2013 07:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 6jwM18a402X0; Tue, 22 Jan 2013 07:14:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DF121F89CB; Tue, 22 Jan 2013 07:14:47 -0800 (PST) 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.37 Message-ID: <20130122151447.31628.99625.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 07:14:47 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-06.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, 22 Jan 2013 15:14:48 -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 : Inter-Area P2MP Segmented LSPs Author(s) : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-06.txt Pages : 39 Date : 2013-01-22 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-seamless-mcast-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From curtis@occnc.com Tue Jan 22 18:40:24 2013 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 13DAD21F8818 for ; Tue, 22 Jan 2013 18:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 LcS0pP4Su8N2 for ; Tue, 22 Jan 2013 18:40:23 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id EC65A21F86AB for ; Tue, 22 Jan 2013 18:40:22 -0800 (PST) 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 r0N2cvFh068921; Tue, 22 Jan 2013 21:38:57 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301230238.r0N2cvFh068921@gateway1.orleans.occnc.com> To: David Allan I From: Curtis Villamizar In-reply-to: Your message of "Thu, 17 Jan 2013 14:45:06 GMT." Date: Tue, 22 Jan 2013 21:38:57 -0500 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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: Wed, 23 Jan 2013 02:40:24 -0000 In message David Allan I writes: > > Hi: > > I was asked to review this document as part of the review team; the > following are my comments. > > I think such a document in general has merit and addresses a gap. I > believe the issues that exist with this particular version of such a > document are in the incomplete discussion of a solution in section > 3. I'd want to see that cleaned up such that it read as a technically > viable solution....(see below).... Dave, If it is unclear to you, then the document is not sufficiently clear and needs fixing. See below. > Nit: > > Section 1 para 2: Refers to MPLS-TP packet ordering as the > constraint. I'm a bit confused by this, any aggregate that shares an > ordering constraint does not get spread across parallel links while a > set of traffic COULD be in theory load spread across a set of MPLS-TP > paths so long as individual ordering constraints were respected. Is > this text document really discussing midbox spreading out of load that > respects ordering constraints but would mean MPLS-TP OAM no longer > fate shared? Should be reworded if so. Clarified otherwise. Section 1 paragraph 2 contains: RFC 5654 requirement 33 requires the capability to carry a client MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. This is possible in all cases with one exception. When an MPLS LSP exceeds the capacity of any single component link it may be carried by a network using multipath techniques, but may not be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP OAM packet ordering constraints. The sentence in question is: When an MPLS LSP exceeds the capacity of any single component link it may be carried by a network using multipath techniques, but may not be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP OAM packet ordering constraints. Perhaps I could clarify this by changing "carried by an MPLS-TP LSP" to "carried by a single MPLS-TP LSP". The "MPLS-TP OAM packet ordering constraints" is the "fate sharing" which is the reason that MPLS-TP prohibits using ECMP (aka multipath, though ECMP is only one form of multipath) with MPLS-TP. This is why an MPLS LSP (client layer) with capacity greater than a component link cannot be carried over a *single* MPLS-TP LSP. Since this is explained in later sections I could make the substitution suggested above or I could drop the last sentence and mention that limitation later. > Main issue: > > Section 3: I think this needs a bit of work, it starts to discuss > tractable solutions but IMO is technically incomplete. IF an entropy > label and ELI (where all traffic associated with the MPLS_TP LSP > shares a common randomly selected entropy label value, which is not > stated) are the only mechanisms of ensuring proper treatment (with all > transit nodes implementing entropy and ELI processing such that > seeking sources of entropy is capped for such LSPs), and the ingress > node (which by some means SHOULD be able to know it is a TP LSP as it > has layer visibility) and the egress node can strip entropy and ELI > then a solution exists for proper fate sharing and ordering of a TP > LSP over MPLS. It is IMO not quiet eluciated completely. Your paragraph above describes the solution, but then says "It is IMO not quiet eluciated completely." So lets parse your paragraph and see what the draft is missing: > Section 3: I think this needs a bit of work, it starts to discuss > tractable solutions but IMO is technically incomplete. OK ... > IF an entropy label and ELI (where all traffic associated with the > MPLS_TP LSP shares a common randomly selected entropy label value, > which is not stated) You mention "IF an entropy label and ELI (where all traffic associated with the MPLS_TP LSP shares a common randomly selected entropy label value, which is not stated)". Regarding the "which is not stated" part of that phrase I can change the following paragraph: OLD: MPLS-TP LSP can be carried as client LSP within an MPLS server LSP if an Entropy Label Indicator (ELI) and entropy label (EL) is added after the server layer LSP label(s) in the label stack, just above the MPLS-TP LSP label entry [RFC6790]. [...] NEW: MPLS-TP LSP can be carried as client LSP within an MPLS server LSP if an Entropy Label Indicator (ELI) and Entropy Label (EL) is added after the server layer LSP label(s) in the label stack, just above the MPLS-TP LSP label entry [RFC6790]. The value of EL can be randomly selected at LSP setup time and the same EL value used for all packets of the MPLS-TP LSP. [...] One sentence is added to the end. (and Entropy Label is capitalized). > are the only mechanisms of ensuring proper treatment Actually link-bundling is mentioned as another mechanism. > (with all transit nodes implementing entropy and ELI processing such > that seeking sources of entropy is capped for such LSPs), The requirement to terminate search for additional entropy below the EL is a requirement of RFC 6790. The intent is to say that non-compliant midpoint LSR would in this case cause packet order problems where in MPLS only (no TP carried) use of RFC 6790, those non-compliant midpoint LSR are tolerable as long as they can get enough entropy from the traffic to adequately load split. > and the ingress node (which by some means SHOULD be able to know it > is a TP LSP as it has layer visibility) That is discussed in the following paragraph: There is currently no signaling mechanism defined to support requirement MP#1. In the absense of a signaling extension, MPLS-TP can be identified through some form of configuration, such as configuration which provides an MPLS-TP compatible server layer to all LSP arriving on a specific interface or originating from a specific set of ingress LSR. Alternately an MPLS-TP LSP can be created with and Entropy Label Indicator (ELI) and entropy label (EL) below the MPLS-TP label [RFC6790]. Obviously the EL can be added at the MPLS-TP ingress LSR. This paragraph is considering the case where a set of MPLS-TP LSR are not EL capable but also do not have multipath enabled, but multipath is enabled elsewhere (ie: the core where lots of traffic needs to get aggregated into a smaller number of LSP). The lack of a signaling extension is noted as a (fixable) limitation. The fix comes in a later draft (draft-villamizar-mpls-multipath-extn). > and the egress node can strip entropy and ELI That is a hard requirement of RFC 6790 for an LSR claiming to support RFC 6790. > then a solution exists for proper fate sharing and ordering of a TP > LSP over MPLS. OK ... agreed. > It is IMO not quiet eluciated completely. You seem to have figured out all of the details. If there are additional clarifications that are needed besides the ones suggested above, please point out what details of the solution are still not clear in the existing text. > If I'm unclear on any of the above, am happy to discuss... Thanks. Please let me know if the above clarifications are sufficient or whether additional clarifications are needed. > Cheers > Dave Cheers, Curtis btw - s/I-D.ietf-mpls-entropy-label/RFC6790/g I didn't think it was worth reving the doc for that one change but I do know about it. From curtis@occnc.com Tue Jan 22 19:41:43 2013 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 D097A21F880B for ; Tue, 22 Jan 2013 19:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 dqHFau-Dyejt for ; Tue, 22 Jan 2013 19:41:43 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id BFC9821F859D for ; Tue, 22 Jan 2013 19:41:42 -0800 (PST) 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 r0N3eIO6069247; Tue, 22 Jan 2013 22:40:18 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301230340.r0N3eIO6069247@gateway1.orleans.occnc.com> To: "Carlos Pignataro (cpignata)" From: Curtis Villamizar In-reply-to: Your message of "Sun, 20 Jan 2013 21:08:24 GMT." <95067C434CE250468B77282634C96ED3228D4D01@xmb-aln-x02.cisco.com> Date: Tue, 22 Jan 2013 22:40:18 -0500 Cc: "mpls@ietf.org" , "" , "draft-villamizar-mpls-multipath-use@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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: Wed, 23 Jan 2013 03:41:44 -0000 In message <95067C434CE250468B77282634C96ED3228D4D01@xmb-aln-x02.cisco.com> "Carlos Pignataro (cpignata)" writes: > > Hello, > > I have been selected as an MPLS Review team reviewer for > draft-villamizar-mpls-multipath-use-00. > > I read this document, and I believe it is ready to be considered for > WG adoption and it is a really good start -- although I also believe > that more work and discussion needs to happen in Section 3 (where > solutions and requirements are presented). Looks like you and Dave are in agreement on that. I look forward to specific suggestions, but I will reread the section and try to make it more clear and more explicit. > I also believe this is a very well written document. It describes a > real problem space adequately providing citations with context and > background, and explains cases that are useful in real operational > networks. > > Additionally, I have some (minor and editorial) comments and questions > for consideration. > > Minor: > > 1. I was surprised that Section 3.1.1 of RFC 5960 was not cited, as > that defines the MPLS-TP requirements for ECMP load balancing. Thank you for pointing that out. The requirement to not load split MPLS-TP is mentioned but the citation is not made. In fact I will quote the following paragraph verbatim. Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY operate over a server layer that supports load-balancing, but this load-balancing MUST operate in such a manner that it is transparent to MPLS-TP. This does not preclude the future definition of new MPLS-TP LSP types that have different requirements regarding the use of ECMP in the server layer. Use of ECMP is allowed in the server layer, as long as it is transparent to the MPLS-TP client layer. > 2. In the requirement MP#1, what does "identify" mean? Identify in the > edges where nodes have visibility to both layers, tag, identify in > mid-point nodes? A MPLS-TP LSP may be aggregated by a midpoint LSR into a very large MPLS LSP, as would be the case in a core node to core node MPLS LSP between major cities. In this case the ingress of the MPLS LSP cannot through any existing signaling mechanism identify those client LSP contained with it as MPLS-TP or not MPLS-TP. For those client LSP that are MPLS-TP LSP, a single EL value must be chosen. For those client LSP that are MPLS LSP, per packet entropy below the top label must be (for practical reasons "must" not "should") used to determine the entropy label value. Also, a MPLS-TP ingress may not know that an LSP it is setting up is going over a RFC 6790 capable LAG. If the LSP is not identified as being MPLS-TP, then load splitting would occur. OTOH - If the MPLS-TP ingress picked a random number and used that in an EL, even if it had no multipath interface the problem is solved, but that is already pointed out in the document. Do I need to change the text to clarify what is meant by "identify" in this context? Perhaps the requirement should be: MP#1 It MUST be possible to identify MPLS-TP LSP or otherwise accommodate the MPLS-TP LSP requirement to avoid reordering of packets. The latter phrase acknowledges that adding an ELI and EL is fine. > 3. I think the concepts of utilizing {ELI; EL} need further discussion > in the document. Similarly, so do the implications on the topic of > the differences of LAG vs. ECMP (both defined explicitly). Perhaps the use of ELI and EL needs to be more explicit. Dave seems to share your opinion that more detail is needed. > 4. The concepts of unequal load split or otherwise load balancing > proportionally to some ratio in different links/paths are briefly > mentioned but could be more explicitly covered. The ECMP definition > mentions this (proportionally to capacity), but in that case it > would not be "Equal". Similarly, concepts like "fairly evenly > distributed" are used in definitions but not explained -- might not > be needed perhaps, but what is fair and what is even in different > scenarios can be understood differently. Familiarity with prior work in multipath in core routers would help the reader. Unfortunately not much has been published. Some useful information can be found in draft-ietf-rtgwg-cl-use-cases in Appendix B. There is also useful descriptions of expectations regarding limiting the frequency of load balancing and the inevitable imperfect balancing in that document and the CL documents in RTGWG: draft-ietf-rtgwg-cl-{requirements,framework} > 5. In requirement MP#2, is the requirement to "completely exclude from > the hash", or to "always coming up with the same output, either by > excluding or including but always resulting in the same"? (i.e., is > excluding a way of getting to the result, or is it the result?) In this context "completely excluding the MPLS-TP LSP ..." is the functional equivalent to MPLS Link Bundling with pinning. There is very little distinction between MP#2 and MP#3, except that MP#3 allows that the LSP could be moved if requirements could no longer be met (component link down, LSP preempted from the component link, etc). > Nits: > > 1. Some times, I think that in many instances, "MPLS LSP" and "MPLS-TP > LSP" should be plural (s/LSP/LSPs/). Consequently, not always clear > when is talking about splitting a single LSP as opposed to > splitting multiple LSPs. OK. I'll look for instances of LSP that should be LSPs. > 2. Some acronyms are not expanded on first use (or not defined), like > CSPF, PSC, ILM, others. ILM is expanded in RFC 3031 (MPLS Architecture) in the table of contents. :-) PSC is expanded in RFC 3471 (GMPLS Signaling Functional Description). CSPF is expanded in RFC 3945 (GMPLS Architecture). These are all base MPLS documents, but I agree that expanding even well known acronyms makes the document more readable. Thanks for pointing this out. > 3. s/overa/over a/ Got it. > I hope these are clear and useful. They are both clear and useful. I will try to reword the sections where clarity may be lacking or where I need to be more explicit. Thank you for the review. > Thank you, > > Carlos Pignataro. Regards, Curtis From curtis@occnc.com Tue Jan 22 20:07:48 2013 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 751F421F859A for ; Tue, 22 Jan 2013 20:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 o+k+66iaXOsj for ; Tue, 22 Jan 2013 20:07:48 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id CC72221F855C for ; Tue, 22 Jan 2013 20:07:47 -0800 (PST) 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 r0N45d9Z069405; Tue, 22 Jan 2013 23:05:41 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301230405.r0N45d9Z069405@gateway1.orleans.occnc.com> To: Mach Chen From: Curtis Villamizar In-reply-to: Your message of "Mon, 21 Jan 2013 10:03:59 GMT." Date: Tue, 22 Jan 2013 23:05:38 -0500 Cc: "mpls@ietf.org" , "" , "draft-villamizar-mpls-multipath-use@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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: Wed, 23 Jan 2013 04:07:48 -0000 In message Mach Chen writes: > > Hi, > > I was selected as an MPLS-RT team reviewer for > draft-villamizar-mpls-multipath-use. > > I read the draft and think it is a useful draft that discusses a real > issue. I think that this draft is ready to be considered for WG > adoption. At same time, the draft also needs more work to make it more > clear, especially for Section 3. Three for three on Section 3 needs clarity. > Here are my comments: > > 1. Section 3, > > The 1th para after the 4 requirements, this para talks how to > satisfy MP#1, but at the end of this para, it starts to talk about > Entropy label but with limited text. Not sure the entropy label is > an alternative solution to satisfy MP#1 or entropy label is an > alternative idea to make sure the MPLS-TP payload and OAM packets > have the same path. I guess it's later. So, I'd suggest to remove > the last sentence or move it the 3rd para after the 4 requirements. In response to Carlos I suggested that MP#1 be made more clear by adding a phrase. MP#1 It MUST be possible to identify MPLS-TP LSP or otherwise accommodate the MPLS-TP LSP requirement to avoid reordering of packets. The last sentence you refer to identifies a means to "otherwise accommodate the MPLS-TP LSP requirement to avoid reordering of packets". That could be made more clear by making the sentence into a separate paragraph that explains this. > 2. I am not sure why MP#3 is a requirement, the result should be no > different from the situation where a component link is failed and > the MPLS-TP LSP is then moved to other links, a potential temp "out > of order" may occur and IMHO this is acceptable. The wording on MP#2 and MP#3 could be more clear. The intent is that MP#2 indicates that an equivalent to MPLS Link Bundling "pinning" should be available. The intent of MP#3 is to indicate that it should be possible to signal LSP that are only moved if the component can no longer be used (component link down, etc). As Carlos pointed out, the most obvious requirement is not explicitly mentioned in the bullet list, but only in the text, and that is the requirement that MPLS-TP traffic not get reordered as per RFC 5960 "MUST NOT use ECMP" (paraphrased). > In addition, there are some nits like redundant/missing words, for > example: the abstract Section: s/MPLS can LSP can/MPLS LSP can Thanks. Got that one. Please point out any other that you notice. > Best regards, > Mach Thank you for your review and comments. Best regards, Curtis From loa@pi.nu Wed Jan 23 00:57:06 2013 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 32B1F21F872C for ; Wed, 23 Jan 2013 00:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 6HREhQBISTwp for ; Wed, 23 Jan 2013 00:57:05 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id A518121F8652 for ; Wed, 23 Jan 2013 00:57:05 -0800 (PST) Received: from [192.168.1.104] (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 561247FE07; Wed, 23 Jan 2013 09:57:01 +0100 (CET) Message-ID: <50FFA5E1.7070001@pi.nu> Date: Wed, 23 Jan 2013 09:57:05 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org, "mpls-chairs@tools.ietf.org" , Martin Vigoureux Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] IPR poll on draft-smiler-mpls-tp-linear-protection-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: Wed, 23 Jan 2013 08:57:06 -0000 Working Group and authors; The authors of draft-smiler-mpls-tp-linear-protection-mib has indicated that the draft is ready to be adopted as a working group document. Before starting the poll to see if there is wg consensus to make the draft 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-smiler-mpls-tp-linear- protection-mib? 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@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From daniel@olddog.co.uk Wed Jan 23 01:10:14 2013 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 494BE21F86D9 for ; Wed, 23 Jan 2013 01:10:14 -0800 (PST) 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 q8alfDU7FC2E for ; Wed, 23 Jan 2013 01:10:13 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0710321F86D2 for ; Wed, 23 Jan 2013 01:10:12 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0N9A22h024982; Wed, 23 Jan 2013 09:10:02 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0N99qc9024797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Jan 2013 09:09:58 GMT From: "Daniel King" To: "'Loa Andersson'" , , "'Martin Vigoureux'" References: <50FFA5E1.7070001@pi.nu> In-Reply-To: <50FFA5E1.7070001@pi.nu> Date: Wed, 23 Jan 2013 09:09:49 -0000 Message-ID: <002e01cdf949$6bdda8b0$4398fa10$@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: AQJXAfaUvM7m/7kf6RKvWjqVx/vlG5dEjQ6w Content-Language: en-gb Subject: Re: [mpls] IPR poll on draft-smiler-mpls-tp-linear-protection-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: Wed, 23 Jan 2013 09:10:14 -0000 Hi Loa, all. I am (as an author) not aware of any IPR related to draft-smiler-mpls-tp-linear-protection-mib. Br, Dan. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: 23 January 2013 08:57 To: mpls@ietf.org; draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org; mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: IPR poll on draft-smiler-mpls-tp-linear-protection-mib Working Group and authors; The authors of draft-smiler-mpls-tp-linear-protection-mib has indicated that the draft is ready to be adopted as a working group document. Before starting the poll to see if there is wg consensus to make the draft 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-smiler-mpls-tp-linear- protection-mib? 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@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From aldrin.ietf@gmail.com Wed Jan 23 01:49:29 2013 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 0CF6721F86BA for ; Wed, 23 Jan 2013 01:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[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 MoP1UK33oM2I for ; Wed, 23 Jan 2013 01:49:28 -0800 (PST) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9469121F8698 for ; Wed, 23 Jan 2013 01:49:28 -0800 (PST) Received: by mail-da0-f48.google.com with SMTP id k18so3744769dae.7 for ; Wed, 23 Jan 2013 01:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=9oHAhVYQvlppfzEfkTBhC26xuBjo6BCt4s9kqyQq3aY=; b=jjk160EsS/PXvH96n3jM6wuQmsr+tCa6GOKb5O60W+zySbsphoozROXL25B+0a7c0L QfEk49y0jA3e2LB0opgdNl8HWTUe7bHJNY4Fz5vXvIT6VEsj8/hTtNvI8uFFxLhzsJdU MQQ/AcZ8uof8jGsIyAOrEkGScRJfGv3UHWw6Oeae1G1qTHarn2GMSasoUvwKPFuajtKY f6ZjKagg0pg4ZMA1MEm5M2SUxZ4CUsQC8Su1zsHh79+dTCTZ9/cTcnUqzAZPSQG8+f6y YBfaRMuCbzO1SOiC+HTYCtpO+WuYjPdTgncModPCD/9uJU+KW1tEx2VpbFzRuWoKWklT 6jsw== X-Received: by 10.66.87.67 with SMTP id v3mr2951475paz.63.1358934568411; Wed, 23 Jan 2013 01:49:28 -0800 (PST) Received: from [192.168.1.2] ([117.195.186.199]) by mx.google.com with ESMTPS id m3sm13261032pav.4.2013.01.23.01.49.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jan 2013 01:49:27 -0800 (PST) References: <50FFA5E1.7070001@pi.nu> <4090125F3B48764B84FB3439456F00E9377DAE59@BY2PRD0512MB656.namprd05.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4090125F3B48764B84FB3439456F00E9377DAE59@BY2PRD0512MB656.namprd05.prod.outlook.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <608BEB93-22F8-4BD4-87D5-623077EA3C0E@gmail.com> X-Mailer: iPhone Mail (10A551) From: Sam Aldrin Date: Wed, 23 Jan 2013 15:19:19 +0530 To: Kingston Selvaraj Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-smiler-mpls-tp-linear-protection-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: Wed, 23 Jan 2013 09:49:29 -0000 As a co-author, I am not aware of any IPR, related to this draft. Thanks Sam Sent from my iPhone On Jan 23, 2013, at 2:46 PM, Kingston Selvaraj wrote: > Hi Loa, >=20 > I'm not aware of any IPR related to draft-smiler-mpls-tp-linear-protection= -mib >=20 > Regards, > S. Kingston Smiler. >=20 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu]=20 > Sent: Wednesday, January 23, 2013 2:27 PM > To: mpls@ietf.org; draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.o= rg; mpls-chairs@tools.ietf.org; Martin Vigoureux > Subject: IPR poll on draft-smiler-mpls-tp-linear-protection-mib >=20 > Working Group and authors; >=20 > The authors of draft-smiler-mpls-tp-linear-protection-mib has indicated th= at the draft is ready to be adopted as a working group document. >=20 > Before starting the poll to see if there is wg consensus to make the draft= a working group document we will do an IPR poll to check whether there is I= PR on the document that needs to be disclosed. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-smiler-mpls-tp-linear- prot= ection-mib? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). >=20 > If you are listed as a document author or contributor please respond to th= is email regardless of whether or not you are aware of any relevant IPR. *Th= e 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 a= uthor and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. >=20 >=20 > Thanks, Loa > (as MPLS WG co-chair) >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > MPLS Expert loa@pi.nu > Huawei Technologies (consult) phone: +46 739 81 21 64 >=20 >=20 From venkat.mahalingams@gmail.com Wed Jan 23 05:53:36 2013 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 427C721F87BA for ; Wed, 23 Jan 2013 05:53:36 -0800 (PST) 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 Cofm2t5k056h for ; Wed, 23 Jan 2013 05:53:35 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 990D121F87B6 for ; Wed, 23 Jan 2013 05:53:35 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id o6so8589514oag.11 for ; Wed, 23 Jan 2013 05:53:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xMHcYXlyMVvU3YdnT7BB/ZznNqnSaV6TM0pFluc8nG0=; b=Gfkx5f46BOkeb+bXaQCXt5yIQkP5EXydiw01VBPE4ID/3Id+amVStpQofALQ+iNTW1 g5WSlPUgNIpWmCynTY8Q9G081x6/BpGpGjLRRXWgAtDeiyp5+GvUnJnH0oKrIzoF+vkw GjeGg1BG62pudCUv0gAhZdu8sJp2Q7rjSAMKQ2+tfpid35APKrwk6pQ8M8mG/OCDyaAW xa5GkVfv6ymBz6Np3Z/Uy+aw9CppoHZO6K87v6thGF3/MDDHL90SulRDP6aZOy4WgjcT mgEYPC0T7xzis+AwN7zPdtZ+6v8gwSQfXjiXtf7gfU5VvYbdyC4OqqodpZGzdgtVMADe vRJA== MIME-Version: 1.0 X-Received: by 10.182.144.7 with SMTP id si7mr988051obb.94.1358949214849; Wed, 23 Jan 2013 05:53:34 -0800 (PST) Received: by 10.76.83.129 with HTTP; Wed, 23 Jan 2013 05:53:34 -0800 (PST) In-Reply-To: <50FFA5E1.7070001@pi.nu> References: <50FFA5E1.7070001@pi.nu> Date: Wed, 23 Jan 2013 05:53:34 -0800 Message-ID: From: Venkatesan Mahalingam To: Loa Andersson Content-Type: multipart/alternative; boundary=14dae9399c9b38097e04d3f505c2 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-smiler-mpls-tp-linear-protection-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: Wed, 23 Jan 2013 13:53:36 -0000 --14dae9399c9b38097e04d3f505c2 Content-Type: text/plain; charset=ISO-8859-1 Loa, I'm not aware of any IPR related to this draft. Thanks, Venkat. On Wed, Jan 23, 2013 at 12:57 AM, Loa Andersson wrote: > Working Group and authors; > > The authors of draft-smiler-mpls-tp-linear-**protection-mib has indicated > that the draft is ready to be adopted as a working group document. > > Before starting the poll to see if there is wg consensus to make the > draft 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-smiler-mpls-tp-linear- > protection-mib? > > 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@mail01.huawei.com > MPLS Expert loa@pi.nu > Huawei Technologies (consult) phone: +46 739 81 21 64 > --14dae9399c9b38097e04d3f505c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Loa,

I'm not aware of any IPR related to this draft.

Than= ks,
Venkat.

On Wed, Jan 23, 2013 at 12= :57 AM, Loa Andersson <loa@pi.nu> wrote:
Working Group and authors;

The authors of draft-smiler-mpls-tp-linear-protection-mib has indica= ted
that the draft is ready to be adopted as a working group document.

Before starting the poll to see if there is wg consensus to make the
draft 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-smiler-mpls-tp-linear-
protection-mib?

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 docum= ents 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 =A0email: loa@mail01.huawei.com
MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= loa@pi.nu
Huawei Technologies (consult) =A0 =A0 =A0 =A0phone: +46 739 81 21 = 64

--14dae9399c9b38097e04d3f505c2-- From iesg-secretary@ietf.org Wed Jan 23 08:04:45 2013 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 C836321F869A; Wed, 23 Jan 2013 08:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 u+pNWS-kxp0A; Wed, 23 Jan 2013 08:04:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E4921F857D; Wed, 23 Jan 2013 08:04:45 -0800 (PST) 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.37 Message-ID: <20130123160445.29483.85902.idtracker@ietfa.amsl.com> Date: Wed, 23 Jan 2013 08:04:45 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (MPLS-TP Security Framework) to Informational RFC 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, 23 Jan 2013 16:04:45 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Security Framework' as Informational RFC 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 2013-02-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-security-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-security-framework/ballot/ No IPR declarations have been submitted directly on this I-D. From david.i.allan@ericsson.com Wed Jan 23 10:43:17 2013 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 ECE4F21F8790 for ; Wed, 23 Jan 2013 10:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 zHGBkxbeLpLR for ; Wed, 23 Jan 2013 10:43:17 -0800 (PST) Received: from usevmg21.ericsson.net (unknown [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id F198B21F871F for ; Wed, 23 Jan 2013 10:43:16 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-31-51002f439787 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5C.52.03705.34F20015; Wed, 23 Jan 2013 19:43:16 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Wed, 23 Jan 2013 13:43:15 -0500 From: David Allan I To: "curtis@occnc.com" Thread-Topic: MPLS-RT review of draft-villamizar-mpls-multipath-use Thread-Index: AQHN+RLRhjn59v73gkmIPrV6gzHbXZhXO2uA Date: Wed, 23 Jan 2013 18:43:15 +0000 Message-ID: References: Your message of "Thu, 17 Jan 2013 14:45:06 GMT." <201301230238.r0N2cvFh068921@gateway1.orleans.occnc.com> In-Reply-To: <201301230238.r0N2cvFh068921@gateway1.orleans.occnc.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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPgq6LPkOgQV8/u8XhA9PZLf7NncNs cWfXF1aL75eWsFjcWrqS1YHVo/XZXlaPJUt+Mnks/uLnMWt6G5vHl8uf2QJYo7hsUlJzMstS i/TtErgyXrycy1Lw1rVixeG5zA2MC826GDk5JARMJJqPH2WFsMUkLtxbz9bFyMUhJHCEUaKl 9ywzSEJIYDmjRN+SLBCbTcBAYs//L4wgtoiApsTfSZvZQWxmga2MEqt3iILYwgJOEt8Wz2aC qHGW6Dn6EqreSOLMv2MsIDaLgKrE02e7gWwODl4Bb4n7Czkh9h5llHhwdgfYXk4BV4kzU9eA HccIdNz3U2uYIHaJS9x6Mp8J4mgBiSV7zjND2KISLx//g3pGWWLJk/0sEPU6Egt2f2KDsLUl li18DVbPKyAocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGLkKC1OLctNNzLcxAiMr2MSbI47 GBd8sjzEKM3BoiTOG+p6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD46xnrfp3Le+eTv68 2TksbnFhX6eEbmNe4fU5GsZxhbpyRvlVMVbOW0vlj1tdv3xnedXrOE8z1nt6dRdt8xyU+19k bKxlOBT2ZsXF78p/WS/N2i29/cYphlfbNxS6xX3KC351YG6NxI7jj1ctuXb7+wu9WdIVvcK+ 9VL9SayelvU2zu/59+VrK7EUZyQaajEXFScCACl46LF9AgAA Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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, 23 Jan 2013 18:43:18 -0000 HI Curtis:=20 Some snipping to help readability and replies prefixed by [Dave] If it is unclear to you, then the document is not sufficiently clear and ne= eds fixing. See below. [Dave] Great.... > Nit: > =20 > Section 1 para 2: Refers to MPLS-TP packet ordering as the constraint.=20 > I'm a bit confused by this, any aggregate that shares an ordering=20 > constraint does not get spread across parallel links while a set of=20 > traffic COULD be in theory load spread across a set of MPLS-TP paths=20 > so long as individual ordering constraints were respected. Is this=20 > text document really discussing midbox spreading out of load that=20 > respects ordering constraints but would mean MPLS-TP OAM no longer=20 > fate shared? Should be reworded if so. Clarified otherwise. Section 1 paragraph 2 contains: RFC 5654 requirement 33 requires the capability to carry a client MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. This is possible in all cases with one exception. When an MPLS LSP exceeds the capacity of any single component link it may be carried by a network using multipath techniques, but may not be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP OAM packet ordering constraints. The sentence in question is: When an MPLS LSP exceeds the capacity of any single component link it may be carried by a network using multipath techniques, but may not be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP OAM packet ordering constraints. Perhaps I could clarify this by changing "carried by an MPLS-TP LSP" to "carried by a single MPLS-TP LSP". The "MPLS-TP OAM packet ordering constraints" is the "fate sharing" which is the reason that MPLS-TP prohibits using ECMP (aka multipath, thoug= h ECMP is only one form of multipath) with MPLS-TP. This is why an MPLS LS= P (client layer) with capacity greater than a component link cannot be carr= ied over a *single* MPLS-TP LSP. Since this is explained in later sections I could make the substitution sug= gested above or I could drop the last sentence and mention that limitation = later. [Dave] the sentence I had a problem with was "but may not be carried by an = MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS= -TP OAM packet ordering constraints." It is not an ordering constraint, it is a fate sharing constraint. It read = fairly strangely to me as to what the problem was you were trying to expose= . IMO the TP requirements are focused on both determinism of commitment of = network resources for network planning & SLA purposes, and ability to fully= and reliably instrument the connectivity. IMO multipath violates the latte= r, whether it violates the former would be a topic of debate unresolvable i= n the reality of LAG. LAG simply scoping the domain of uncertainty for OAM = purposes to a link, and requiring extra link OAM and inheritance... [Dave] To make the discussion short, replacing "OAM packet ordering constra= ints" with "OAM fate sharing constraints" should be sufficient. > Main issue: > =20 > Section 3: I think this needs a bit of work, it starts to discuss=20 > tractable solutions but IMO is technically incomplete. IF an entropy=20 > label and ELI (where all traffic associated with the MPLS_TP LSP=20 > shares a common randomly selected entropy label value, which is not > stated) are the only mechanisms of ensuring proper treatment (with all=20 > transit nodes implementing entropy and ELI processing such that=20 > seeking sources of entropy is capped for such LSPs), and the ingress=20 > node (which by some means SHOULD be able to know it is a TP LSP as it=20 > has layer visibility) and the egress node can strip entropy and ELI=20 > then a solution exists for proper fate sharing and ordering of a TP=20 > LSP over MPLS. It is IMO not quiet eluciated completely. Your paragraph above describes the solution, but then says "It is IMO not q= uiet eluciated completely." [Dave] Well I know you and I know the solution, but someone newer to the su= bject would not necessarily be able to infer it from the document in its cu= rrent state. So lets parse your paragraph and see what the draft is missing: > Section 3: I think this needs a bit of work, it starts to discuss=20 > tractable solutions but IMO is technically incomplete. OK ... > IF an entropy label and ELI (where all traffic associated with the=20 > MPLS_TP LSP shares a common randomly selected entropy label value,=20 > which is not stated) You mention "IF an entropy label and ELI (where all traffic associated with the MPLS_TP LSP shares a common randomly selected entropy label value, which is not stated)". Regarding the "which is not stated" part of that phrase I can change the following paragraph: OLD: MPLS-TP LSP can be carried as client LSP within an MPLS server LSP if an Entropy Label Indicator (ELI) and entropy label (EL) is added after the server layer LSP label(s) in the label stack, just above the MPLS-TP LSP label entry [RFC6790]. [...] NEW: MPLS-TP LSP can be carried as client LSP within an MPLS server LSP if an Entropy Label Indicator (ELI) and Entropy Label (EL) is added after the server layer LSP label(s) in the label stack, just above the MPLS-TP LSP label entry [RFC6790]. The value of EL can be randomly selected at LSP setup time and the same EL value used for all packets of the MPLS-TP LSP. [...] [Dave] That edit works for me. One sentence is added to the end. (and Entropy Label is capitalized). > are the only mechanisms of ensuring proper treatment Actually link-bundling is mentioned as another mechanism. > (with all transit nodes implementing entropy and ELI processing such=20 > that seeking sources of entropy is capped for such LSPs), The requirement to terminate search for additional entropy below the EL is a requirement of RFC 6790. The intent is to say that non-compliant midpoint LSR would in this case cause packet order problems where in MPLS only (no TP carried) use of RFC 6790, those non-compliant midpoint LSR are tolerable as long as they can get enough entropy from the traffic to adequately load split. [Dave] Given the relative newness of 6790, I'm assuming some statement to t= he effect that this solution is not necessarily backwards compatible with e= xisting deployments needs to be said. > and the ingress node (which by some means SHOULD be able to know it is=20 > a TP LSP as it has layer visibility) That is discussed in the following paragraph: There is currently no signaling mechanism defined to support requirement MP#1. In the absense of a signaling extension, MPLS-TP can be identified through some form of configuration, such as configuration which provides an MPLS-TP compatible server layer to all LSP arriving on a specific interface or originating from a specific set of ingress LSR. Alternately an MPLS-TP LSP can be created with and Entropy Label Indicator (ELI) and entropy label (EL) below the MPLS-TP label [RFC6790]. Obviously the EL can be added at the MPLS-TP ingress LSR. This paragraph is considering the case where a set of MPLS-TP LSR are not EL capable but also do not have multipath enabled, but multipath is enabled elsewhere (ie: the core where lots of traffic needs to get aggregated into a smaller number of LSP). The lack of a signaling extension is noted as a (fixable) limitation. The fix comes in a later draft (draft-villamizar-mpls-multipath-extn). > and the egress node can strip entropy and ELI That is a hard requirement of RFC 6790 for an LSR claiming to support RFC 6790. > then a solution exists for proper fate sharing and ordering of a TP=20 > LSP over MPLS. OK ... agreed. > It is IMO not quiet eluciated completely. You seem to have figured out all of the details. If there are additional clarifications that are needed besides the ones sug= gested above, please point out what details of the solution are still not c= lear in the existing text. > If I'm unclear on any of the above, am happy to discuss... Thanks. Please let me know if the above clarifications are sufficient or w= hether additional clarifications are needed. [Dave] I think with the change of ordering constraint to fate sharing const= raint in section 1, the EL "fixed value" addition and some disclaimer about= 6790 support in the MPLS network, I would be happy. I'm clearer on what yo= u were saying. Best Dave From curtis@occnc.com Wed Jan 23 14:20:21 2013 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 C9FAE21F882A for ; Wed, 23 Jan 2013 14:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, 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 V-tlGmRp-LUW for ; Wed, 23 Jan 2013 14:20:20 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id EF82321F8801 for ; Wed, 23 Jan 2013 14:20:16 -0800 (PST) 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 r0NMIoAp096605; Wed, 23 Jan 2013 17:18:51 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301232218.r0NMIoAp096605@gateway1.orleans.occnc.com> To: David Allan I From: Curtis Villamizar In-reply-to: Your message of "Wed, 23 Jan 2013 18:43:15 GMT." Date: Wed, 23 Jan 2013 17:18:50 -0500 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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: Wed, 23 Jan 2013 22:20:22 -0000 In message David Allan I writes: > > HI Curtis: > > Some snipping to help readability and replies prefixed by [Dave] > > > > If it is unclear to you, then the document is not sufficiently clear > and needs fixing. See below. > > [Dave] Great.... > > > Nit: > > > > Section 1 para 2: Refers to MPLS-TP packet ordering as the constraint. > > I'm a bit confused by this, any aggregate that shares an ordering > > constraint does not get spread across parallel links while a set of > > traffic COULD be in theory load spread across a set of MPLS-TP paths > > so long as individual ordering constraints were respected. Is this > > text document really discussing midbox spreading out of load that > > respects ordering constraints but would mean MPLS-TP OAM no longer > > fate shared? Should be reworded if so. Clarified otherwise. > > Section 1 paragraph 2 contains: > > RFC 5654 requirement 33 requires the capability to carry a client > MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer > [RFC5654]. This is possible in all cases with one exception. When > an MPLS LSP exceeds the capacity of any single component link it > may be carried by a network using multipath techniques, but may not > be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity > limitation imposed by MPLS-TP OAM packet ordering constraints. > > The sentence in question is: > > When an MPLS LSP exceeds the capacity of any single component link > it may be carried by a network using multipath techniques, but may > not be carried by an MPLS-TP LSP due to the inherent MPLS-TP > capacity limitation imposed by MPLS-TP OAM packet ordering > constraints. > > Perhaps I could clarify this by changing "carried by an MPLS-TP LSP" > to "carried by a single MPLS-TP LSP". > > The "MPLS-TP OAM packet ordering constraints" is the "fate sharing" > which is the reason that MPLS-TP prohibits using ECMP (aka multipath, > though ECMP is only one form of multipath) with MPLS-TP. This is why > an MPLS LSP (client layer) with capacity greater than a component link > cannot be carried over a *single* MPLS-TP LSP. > > Since this is explained in later sections I could make the > substitution suggested above or I could drop the last sentence and > mention that limitation later. > > [Dave] the sentence I had a problem with was "but may not be carried > by an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation > imposed by MPLS-TP OAM packet ordering constraints." The phrase you are objecting to is "packet ordering constraints". Carlos suggested that I reference or quote RFC 5960 which would clear up exactly what the dataplane requirements are. If direct LM OAM is supported, then there is a strict packet reordering requirement (can't reorder the LM OAM packet relative to payload packets or accuracy suffers) so maybe I need to cite RFC 6374 Section 2.9.4 "Equal Cost Multipath" and Section 4.2.10 "Message Loss and Packet Misorder Conditions". > It is not an ordering constraint, it is a fate sharing constraint. It > read fairly strangely to me as to what the problem was you were trying > to expose. IMO the TP requirements are focused on both determinism of > commitment of network resources for network planning & SLA purposes, > and ability to fully and reliably instrument the connectivity. IMO > multipath violates the latter, whether it violates the former would be > a topic of debate unresolvable in the reality of LAG. LAG simply > scoping the domain of uncertainty for OAM purposes to a link, and > requiring extra link OAM and inheritance... This is an aside, but since you brought this up I'll respond. Begin aside. You made two implied assertions. 1) MPLS-TP is more deterministic, 2) MPLS-TP is necessary to reliably instrument the connectivity. A circuit swtiched (or MPLS-TP) network is more deterministic with respect to how much capacity is allocated. When the capacity in question is a large aggregate of traffic, the packet switched (or MPLS) network is more deterministic with respect to individual customer experience. For example, if many LSP travel across a core and if one city pair is exceeding its expected capactiy but others are slidghtly underutilizing their expected capactiy, then in the circuit switched or MPLS-TP network individual flows for that city pair experience congestion, whereas in a packet switched or MPLS network, capacity is shared and therefore no congestion is experienced. In MPLS core networks the SLA traffic is a fraction of traffic and does fine with little more than TC marking and diffserv treatment. The determinism you describe may be an issue in metro networks, such as where mobile backhaul is mixed with pedestrian Internet traffic and capacity is scarse. Kireeti Kompella and other wrote a paper about two years ago on exactly this topic and it might help if I dug up the reference and included in the document. The latter point regarding reliably instrumenting the connectivity is valid. But if the benefit of instrumenting is for a minority of the traffic (SLA traffic) and the cost is a reduction in network efficiency for the vast majority of traffic (plain old Internet), then there is a substantial increase in cost to provide the instrumented service and then it may not be worth it. This is why MPLS-TP carried over MPLS is of interest. End aside. > [Dave] To make the discussion short, replacing "OAM packet ordering > constraints" with "OAM fate sharing constraints" should be > sufficient. In practice the "OAM fate sharing constraints" and "OAM packet ordering constraints" are almost one in the same where LAG or ECMP are the cause of the misordering. LM OAM requires strict packet ordering, not just fate sharing. I'll add the references to RFC 5960 and RFC 6374 and let those RFCs state the requirements. > > Main issue: > > > > Section 3: I think this needs a bit of work, it starts to discuss > > tractable solutions but IMO is technically incomplete. IF an entropy > > label and ELI (where all traffic associated with the MPLS_TP LSP > > shares a common randomly selected entropy label value, which is not > > stated) are the only mechanisms of ensuring proper treatment (with all > > transit nodes implementing entropy and ELI processing such that > > seeking sources of entropy is capped for such LSPs), and the ingress > > node (which by some means SHOULD be able to know it is a TP LSP as it > > has layer visibility) and the egress node can strip entropy and ELI > > then a solution exists for proper fate sharing and ordering of a TP > > LSP over MPLS. It is IMO not quiet eluciated completely. > > Your paragraph above describes the solution, but then says "It is IMO > not quiet eluciated completely." > > [Dave] Well I know you and I know the solution, but someone newer to > the subject would not necessarily be able to infer it from the > document in its current state. OK. Fair enough. > So lets parse your paragraph and see what the draft is missing: > > > Section 3: I think this needs a bit of work, it starts to discuss > > tractable solutions but IMO is technically incomplete. > > OK ... > > > IF an entropy label and ELI (where all traffic associated with the > > MPLS_TP LSP shares a common randomly selected entropy label value, > > which is not stated) > > You mention "IF an entropy label and ELI (where all traffic > associated with the MPLS_TP LSP shares a common randomly selected > entropy label value, which is not stated)". Regarding the "which > is not stated" part of that phrase I can change the following > paragraph: > > OLD: > > MPLS-TP LSP can be carried as client LSP within an MPLS server > LSP if an Entropy Label Indicator (ELI) and entropy label (EL) > is added after the server layer LSP label(s) in the label > stack, just above the MPLS-TP LSP label entry [RFC6790]. > [...] > > NEW: > > MPLS-TP LSP can be carried as client LSP within an MPLS server > LSP if an Entropy Label Indicator (ELI) and Entropy Label (EL) > is added after the server layer LSP label(s) in the label > stack, just above the MPLS-TP LSP label entry [RFC6790]. The > value of EL can be randomly selected at LSP setup time and the > same EL value used for all packets of the MPLS-TP LSP. [...] > > [Dave] That edit works for me. Its in the xml source and will be in the next iteration. > One sentence is added to the end. (and Entropy Label is capitalized). > > > are the only mechanisms of ensuring proper treatment > > Actually link-bundling is mentioned as another mechanism. > > > (with all transit nodes implementing entropy and ELI processing such > > that seeking sources of entropy is capped for such LSPs), > > The requirement to terminate search for additional entropy below > the EL is a requirement of RFC 6790. The intent is to say that > non-compliant midpoint LSR would in this case cause packet order > problems where in MPLS only (no TP carried) use of RFC 6790, those > non-compliant midpoint LSR are tolerable as long as they can get > enough entropy from the traffic to adequately load split. > > [Dave] Given the relative newness of 6790, I'm assuming some statement > to the effect that this solution is not necessarily backwards > compatible with existing deployments needs to be said. OK. Most of the draft-villamizar-mpls-multipath-extn is about fixing the limitation that MPLS-TP LSP need to be identified in signaling and that the ingress needs to know which links can't support MPLS-TP requirements. This text addresses the need to know which links can't support MPLS-TP. MP#4 Where an RSVP-TE control plane is used, it MUST be possible for an ingress LSR which is setting up an MPLS-TP or MPLS LSP to determine at CSPF time whether a link or MPLS PSC LSP within the topology can support the MPLS-TP requirements of the LSP. I'll explicitly mention that legacy LAG and legacy ECMP that do not support ELI and EL are among the "link or MPLS PSC LSP within the topology" that cannot "can support the MPLS-TP requirements of the LSP." Without protocol extensions, the ingress can still know this if color (administrative attributes in RFC 3209) is used to identify these links. Its worth mentioning this, so thanks for bringing it up. So far all I say is: Requirement MP#4 can be supported using administrative attributes. Administrative attributes are defined in [RFC3209]. Some configuration is required to support this. I'll preceed that with: Links or MPLS LSP which traverse LAG or ECMP with adjacent LSR that do not support [RFC6790] cannot support MPLS-TP requirements. This is the reason for including requirement MP#4. The ingress of an MPLS-TP LSP must be able to avoid these links or MPLS LSP. I think this addresses your concern. [btw- sometimes it is better to state what is obvious to some readers than confuse the others readers, so I agree that this is an improvement.] > > and the ingress node (which by some means SHOULD be able to know it is > > a TP LSP as it has layer visibility) > > That is discussed in the following paragraph: > > There is currently no signaling mechanism defined to support > requirement MP#1. In the absense of a signaling extension, > MPLS-TP can be identified through some form of configuration, > such as configuration which provides an MPLS-TP compatible > server layer to all LSP arriving on a specific interface or > originating from a specific set of ingress LSR. Alternately an > MPLS-TP LSP can be created with and Entropy Label Indicator > (ELI) and entropy label (EL) below the MPLS-TP label [RFC6790]. > > Obviously the EL can be added at the MPLS-TP ingress LSR. This > paragraph is considering the case where a set of MPLS-TP LSR are > not EL capable but also do not have multipath enabled, but > multipath is enabled elsewhere (ie: the core where lots of traffic > needs to get aggregated into a smaller number of LSP). The lack > of a signaling extension is noted as a (fixable) limitation. The > fix comes in a later draft (draft-villamizar-mpls-multipath-extn). > > > and the egress node can strip entropy and ELI > > That is a hard requirement of RFC 6790 for an LSR claiming to > support RFC 6790. > > > then a solution exists for proper fate sharing and ordering of a TP > > LSP over MPLS. > > OK ... agreed. > > > It is IMO not quiet eluciated completely. > > You seem to have figured out all of the details. > > If there are additional clarifications that are needed besides the > ones suggested above, please point out what details of the solution > are still not clear in the existing text. > > > If I'm unclear on any of the above, am happy to discuss... > > Thanks. Please let me know if the above clarifications are sufficient > or whether additional clarifications are needed. > > [Dave] I think with the change of ordering constraint to fate sharing > constraint in section 1, the EL "fixed value" addition and some > disclaimer about 6790 support in the MPLS network, I would be > happy. I'm clearer on what you were saying. If the changes above don't adequately address your concerns then please say so. > Best > Dave Cheers, Curtis From david.i.allan@ericsson.com Wed Jan 23 14:43:17 2013 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 0118621F86EA for ; Wed, 23 Jan 2013 14:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 BNj0tWm34gqq for ; Wed, 23 Jan 2013 14:43:15 -0800 (PST) Received: from usevmg21.ericsson.net (unknown [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 95F0421F858C for ; Wed, 23 Jan 2013 14:43:15 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-1f-510067824f74 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8F.9E.03705.28760015; Wed, 23 Jan 2013 23:43:15 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Wed, 23 Jan 2013 17:43:14 -0500 From: David Allan I To: "curtis@occnc.com" Thread-Topic: MPLS-RT review of draft-villamizar-mpls-multipath-use Thread-Index: AQHN+beehjn59v73gkmIPrV6gzHbXZhXfNHA Date: Wed, 23 Jan 2013 22:43:13 +0000 Message-ID: References: Your message of "Wed, 23 Jan 2013 18:43:15 GMT." <201301232218.r0NMIoAp096605@gateway1.orleans.occnc.com> In-Reply-To: <201301232218.r0NMIoAp096605@gateway1.orleans.occnc.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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPiG5zOkOgwfweXovDB6azW/ybO4fZ 4s6uL6wW3y8tYbG4tXQlqwOrR+uzvaweS5b8ZPJY/MXPY9b0NjaPL5c/swWwRnHZpKTmZJal FunbJXBlTL/+kaVgZ1XF5lPfGRsYv8R3MXJySAiYSOy8f5oJwhaTuHBvPVsXIxeHkMARRok9 fVMZIZzljBIvt09nAaliEzCQ2PP/CyOILSKgKfF30mZ2EJtZYCujxOodoiC2sICTxLfFs5kg apwleo6+BKrnALKNJHY1KoCEWQRUJdq27AUbySvgLfH7wBF2iF1HGSX+bv4GNp9TwFXi94nz YDYj0HXfT61hgtglLnHryXyoqwUkluw5zwxhi0q8fPyPFcJWlljyZD8LRL2OxILdn9ggbG2J ZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGW5iBEbYMQk2xx2M Cz5ZHmKU5mBREucNdb0QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRMNjr6YqqkDMajxtd GF+sqpHbsl7tqLyTmZiYy775P2eEfa2VfP1y8oZtfP87xF4FWM4xP31Bo1Tw/MODRxMl9i+U PWkytcLurXvybAc7y19JRqrz73Fc8L/QOiOp69krzrMcB+Y/7evZZLSh4tRduVIu16/LKkIK Pdd89tHdvv2Z16u0gj5lJZbijERDLeai4kQAuY6vRn4CAAA= Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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, 23 Jan 2013 22:43:17 -0000 Hi Curtis Thanks for the reply, and yes LM has a strict ordering constraint, while FM= wants fate sharing, I was brain-farting on the PM/LM component of OAM when= reading it and thinking FM which is the usual discussion on this list.... So now I understand the motivation for the way you had phrased the text. No= t spreading an individual TP LSP out across multiple links actually satifie= s both so IMO there is a dual motivation for the requirement. If referring = to the OAM ordering requirement, I'd suggest calling it "the strict packet = ordering requirement that TP Performance monitoring requires", so it cannot= be confused with simply in order delivery of OAM PDUs in isolation; the OA= M PDU's relative position with respect to the interleaved real traffic actu= ally matters. I also have no issue with the digression on capacity allocation determinism= and SLA monitoring vs. actual behavior. Other that that I would observe ac= tual mileage observed by the different modes of operation depends on the ac= tual traffic profile, e.g. large number of small flows vs. small number of = large flows.... Cheers D -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com]=20 Sent: Wednesday, January 23, 2013 2:19 PM To: David Allan I Cc: curtis@occnc.com; mpls@ietf.org; Martin Vigoureux; mpls-chairs@tools.ie= tf.org; Loa Andersson Subject: Re: MPLS-RT review of draft-villamizar-mpls-multipath-use In message David Allan I writes: >=20 > HI Curtis:=20 > =20 > Some snipping to help readability and replies prefixed by [Dave] > =20 > > =20 > If it is unclear to you, then the document is not sufficiently clear=20 > and needs fixing. See below. > =20 > [Dave] Great.... > =20 > > Nit: > > =20 > > Section 1 para 2: Refers to MPLS-TP packet ordering as the constraint.= =20 > > I'm a bit confused by this, any aggregate that shares an ordering=20 > > constraint does not get spread across parallel links while a set of=20 > > traffic COULD be in theory load spread across a set of MPLS-TP paths=20 > > so long as individual ordering constraints were respected. Is this=20 > > text document really discussing midbox spreading out of load that=20 > > respects ordering constraints but would mean MPLS-TP OAM no longer=20 > > fate shared? Should be reworded if so. Clarified otherwise. > =20 > Section 1 paragraph 2 contains: > =20 > RFC 5654 requirement 33 requires the capability to carry a client > MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer > [RFC5654]. This is possible in all cases with one exception. When > an MPLS LSP exceeds the capacity of any single component link it > may be carried by a network using multipath techniques, but may not > be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity > limitation imposed by MPLS-TP OAM packet ordering constraints. > =20 > The sentence in question is: > =20 > When an MPLS LSP exceeds the capacity of any single component link > it may be carried by a network using multipath techniques, but may > not be carried by an MPLS-TP LSP due to the inherent MPLS-TP > capacity limitation imposed by MPLS-TP OAM packet ordering > constraints. > =20 > Perhaps I could clarify this by changing "carried by an MPLS-TP LSP" > to "carried by a single MPLS-TP LSP". > =20 > The "MPLS-TP OAM packet ordering constraints" is the "fate sharing" > which is the reason that MPLS-TP prohibits using ECMP (aka multipath,=20 > though ECMP is only one form of multipath) with MPLS-TP. This is why=20 > an MPLS LSP (client layer) with capacity greater than a component link=20 > cannot be carried over a *single* MPLS-TP LSP. > =20 > Since this is explained in later sections I could make the=20 > substitution suggested above or I could drop the last sentence and=20 > mention that limitation later. > =20 > [Dave] the sentence I had a problem with was "but may not be carried=20 > by an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation=20 > imposed by MPLS-TP OAM packet ordering constraints." The phrase you are objecting to is "packet ordering constraints". Carlos suggested that I reference or quote RFC 5960 which would clear up ex= actly what the dataplane requirements are. If direct LM OAM is supported, then there is a strict packet reordering req= uirement (can't reorder the LM OAM packet relative to payload packets or ac= curacy suffers) so maybe I need to cite RFC 6374 Section 2.9.4 "Equal Cost = Multipath" and Section 4.2.10 "Message Loss and Packet Misorder Conditions"= . > It is not an ordering constraint, it is a fate sharing constraint. It=20 > read fairly strangely to me as to what the problem was you were trying=20 > to expose. IMO the TP requirements are focused on both determinism of=20 > commitment of network resources for network planning & SLA purposes,=20 > and ability to fully and reliably instrument the connectivity. IMO=20 > multipath violates the latter, whether it violates the former would be=20 > a topic of debate unresolvable in the reality of LAG. LAG simply=20 > scoping the domain of uncertainty for OAM purposes to a link, and=20 > requiring extra link OAM and inheritance... This is an aside, but since you brought this up I'll respond. Begin aside. You made two implied assertions. 1) MPLS-TP is more deterministic, 2) MPLS= -TP is necessary to reliably instrument the connectivity. A circuit swtiched (or MPLS-TP) network is more deterministic with respect = to how much capacity is allocated. When the capacity in question is a larg= e aggregate of traffic, the packet switched (or MPLS) network is more deterministic with respect to individual customer exp= erience. For example, if many LSP travel across a core and if one city pai= r is exceeding its expected capactiy but others are slidghtly underutilizin= g their expected capactiy, then in the circuit switched or MPLS-TP network = individual flows for that city pair experience congestion, whereas in a pac= ket switched or MPLS network, capacity is shared and therefore no congestio= n is experienced. In MPLS core networks the SLA traffic is a fraction of traffic and does fin= e with little more than TC marking and diffserv treatment. The determinism you describe may be an issue in metro networks, such as whe= re mobile backhaul is mixed with pedestrian Internet traffic and capacity i= s scarse. Kireeti Kompella and other wrote a paper about two years ago on exactly thi= s topic and it might help if I dug up the reference and included in the doc= ument. The latter point regarding reliably instrumenting the connectivity is valid= . But if the benefit of instrumenting is for a minority of the traffic (SL= A traffic) and the cost is a reduction in network efficiency for the vast m= ajority of traffic (plain old Internet), then there is a substantial increa= se in cost to provide the instrumented service and then it may not be worth= it. This is why MPLS-TP carried over MPLS is of interest. End aside. > [Dave] To make the discussion short, replacing "OAM packet ordering=20 > constraints" with "OAM fate sharing constraints" should be sufficient. In practice the "OAM fate sharing constraints" and "OAM packet ordering con= straints" are almost one in the same where LAG or ECMP are the cause of the= misordering. LM OAM requires strict packet ordering, not just fate sharin= g. I'll add the references to RFC 5960 and RFC 6374 and let those RFCs state t= he requirements. > > Main issue: > > =20 > > Section 3: I think this needs a bit of work, it starts to discuss=20 > > tractable solutions but IMO is technically incomplete. IF an entropy=20 > > label and ELI (where all traffic associated with the MPLS_TP LSP=20 > > shares a common randomly selected entropy label value, which is not > > stated) are the only mechanisms of ensuring proper treatment (with=20 > > all transit nodes implementing entropy and ELI processing such that=20 > > seeking sources of entropy is capped for such LSPs), and the ingress=20 > > node (which by some means SHOULD be able to know it is a TP LSP as=20 > > it has layer visibility) and the egress node can strip entropy and=20 > > ELI then a solution exists for proper fate sharing and ordering of a=20 > > TP LSP over MPLS. It is IMO not quiet eluciated completely. > =20 > Your paragraph above describes the solution, but then says "It is IMO=20 > not quiet eluciated completely." > =20 > [Dave] Well I know you and I know the solution, but someone newer to=20 > the subject would not necessarily be able to infer it from the=20 > document in its current state. OK. Fair enough. > So lets parse your paragraph and see what the draft is missing: > =20 > > Section 3: I think this needs a bit of work, it starts to discuss=20 > > tractable solutions but IMO is technically incomplete. > =20 > OK ... > =20 > > IF an entropy label and ELI (where all traffic associated with the=20 > > MPLS_TP LSP shares a common randomly selected entropy label value,=20 > > which is not stated) > =20 > You mention "IF an entropy label and ELI (where all traffic > associated with the MPLS_TP LSP shares a common randomly selected > entropy label value, which is not stated)". Regarding the "which > is not stated" part of that phrase I can change the following > paragraph: > =20 > OLD: > =20 > MPLS-TP LSP can be carried as client LSP within an MPLS server > LSP if an Entropy Label Indicator (ELI) and entropy label (EL) > is added after the server layer LSP label(s) in the label > stack, just above the MPLS-TP LSP label entry [RFC6790]. > [...] > =20 > NEW: > =20 > MPLS-TP LSP can be carried as client LSP within an MPLS server > LSP if an Entropy Label Indicator (ELI) and Entropy Label (EL) > is added after the server layer LSP label(s) in the label > stack, just above the MPLS-TP LSP label entry [RFC6790]. The > value of EL can be randomly selected at LSP setup time and the > same EL value used for all packets of the MPLS-TP LSP. [...] > =20 > [Dave] That edit works for me. Its in the xml source and will be in the next iteration. > One sentence is added to the end. (and Entropy Label is capitalized)= . > =20 > > are the only mechanisms of ensuring proper treatment > =20 > Actually link-bundling is mentioned as another mechanism. > =20 > > (with all transit nodes implementing entropy and ELI processing such=20 > > that seeking sources of entropy is capped for such LSPs), > =20 > The requirement to terminate search for additional entropy below > the EL is a requirement of RFC 6790. The intent is to say that > non-compliant midpoint LSR would in this case cause packet order > problems where in MPLS only (no TP carried) use of RFC 6790, those > non-compliant midpoint LSR are tolerable as long as they can get > enough entropy from the traffic to adequately load split. > =20 > [Dave] Given the relative newness of 6790, I'm assuming some statement=20 > to the effect that this solution is not necessarily backwards=20 > compatible with existing deployments needs to be said. OK. Most of the draft-villamizar-mpls-multipath-extn is about fixing the l= imitation that MPLS-TP LSP need to be identified in signaling and that the = ingress needs to know which links can't support MPLS-TP requirements. This text addresses the need to know which links can't support MPLS-TP. MP#4 Where an RSVP-TE control plane is used, it MUST be possible for an ingress LSR which is setting up an MPLS-TP or MPLS LSP to determine at CSPF time whether a link or MPLS PSC LSP within the topology can support the MPLS-TP requirements of the LSP. I'll explicitly mention that legacy LAG and legacy ECMP that do not support= ELI and EL are among the "link or MPLS PSC LSP within the topology" that c= annot "can support the MPLS-TP requirements of the LSP." Without protocol = extensions, the ingress can still know this if color (administrative attrib= utes in RFC 3209) is used to identify these links. Its worth mentioning th= is, so thanks for bringing it up. So far all I say is: Requirement MP#4 can be supported using administrative attributes. Administrative attributes are defined in [RFC3209]. Some configuration is required to support this. I'll preceed that with: Links or MPLS LSP which traverse LAG or ECMP with adjacent LSR that do not support [RFC6790] cannot support MPLS-TP requirements. This is the reason for including requirement MP#4. The ingress of an MPLS-TP LSP must be able to avoid these links or MPLS LSP. I think this addresses your concern. [btw- sometimes it is better to state= what is obvious to some readers than confuse the others readers, so I agre= e that this is an improvement.] > > and the ingress node (which by some means SHOULD be able to know it=20 > > is a TP LSP as it has layer visibility) > =20 > That is discussed in the following paragraph: > =20 > There is currently no signaling mechanism defined to support > requirement MP#1. In the absense of a signaling extension, > MPLS-TP can be identified through some form of configuration, > such as configuration which provides an MPLS-TP compatible > server layer to all LSP arriving on a specific interface or > originating from a specific set of ingress LSR. Alternately an > MPLS-TP LSP can be created with and Entropy Label Indicator > (ELI) and entropy label (EL) below the MPLS-TP label [RFC6790]. > =20 > Obviously the EL can be added at the MPLS-TP ingress LSR. This > paragraph is considering the case where a set of MPLS-TP LSR are > not EL capable but also do not have multipath enabled, but > multipath is enabled elsewhere (ie: the core where lots of traffic > needs to get aggregated into a smaller number of LSP). The lack > of a signaling extension is noted as a (fixable) limitation. The > fix comes in a later draft (draft-villamizar-mpls-multipath-extn). > =20 > > and the egress node can strip entropy and ELI > =20 > That is a hard requirement of RFC 6790 for an LSR claiming to > support RFC 6790. > =20 > > then a solution exists for proper fate sharing and ordering of a TP=20 > > LSP over MPLS. > =20 > OK ... agreed. > =20 > > It is IMO not quiet eluciated completely. > =20 > You seem to have figured out all of the details. > =20 > If there are additional clarifications that are needed besides the=20 > ones suggested above, please point out what details of the solution=20 > are still not clear in the existing text. > =20 > > If I'm unclear on any of the above, am happy to discuss... > =20 > Thanks. Please let me know if the above clarifications are sufficient=20 > or whether additional clarifications are needed. > =20 > [Dave] I think with the change of ordering constraint to fate sharing=20 > constraint in section 1, the EL "fixed value" addition and some=20 > disclaimer about 6790 support in the MPLS network, I would be happy.=20 > I'm clearer on what you were saying. If the changes above don't adequately address your concerns then please say= so. > Best > Dave Cheers, Curtis From lufang@cisco.com Thu Jan 24 07:40:29 2013 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 E238421F873D for ; Thu, 24 Jan 2013 07:40:28 -0800 (PST) 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 oFpJtpDAvCX0 for ; Thu, 24 Jan 2013 07:40:28 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1962721F86FB for ; Thu, 24 Jan 2013 07:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3763; q=dns/txt; s=iport; t=1359042028; x=1360251628; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wP7NLD5muGjRXlCTeqgrdmT9pSFDm71eoC7FeaK0sGg=; b=Tl6o9T3kPsOk2EXwtJZl1b1T1ySWNkDmG3ZdGt9hyqWZa/JXo54xP9qt yZGtkawvtUX6wLbO27Luvoh4sVLP5SAJT7/7Jgj4h0JUze2tkBND1vbBb UZ0XRI7hMs0oEiWVk5aLQWpyfojBCsfhhoJSrVhySbi+oS5o0+RVxul3s M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANtUAVGtJV2d/2dsb2JhbABEvkcWc4IeAQEBBAEBATc0CwwCBAEIEQMBAQELFAkiDAsUCQgCBAENBQiIAAMPDL4CBASMCHeDF2EDplSCeIFvNQ X-IronPort-AV: E=Sophos;i="4.84,530,1355097600"; d="scan'208";a="167479069" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 24 Jan 2013 15:40:27 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0OFeRnP008151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jan 2013 15:40:27 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 09:40:27 -0600 From: "Luyuan Fang (lufang)" To: Lucy yong , "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: [mpls] working group last call Thread-Index: AQHN8kOhO9NeXmS+hEuIsU0xoNTiYphLO4qAgA2C84A= Date: Thu, 24 Jan 2013 15:40:26 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931026B313@xmb-rcd-x03.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4487679C@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.80.121] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: Re: [mpls] working group last call 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, 24 Jan 2013 15:40:29 -0000 Lucy, Thanks for your support and comment. =20 Here is our update to address your comment on timing. =3D=3D=3D In 3.3.1 we already state: "The deterministic nature of MPLS-TP LSP set up can also support packet based synchronization to maintain predictable performance regarding packet delay and jitters." We now expand this to: "The traffic engineered and co-routed bidirectional properties of an MPLS-TP LSP are of benefit in transporting packet based time and frequency synchronization (TFS) protocols such as [draft-ietf-tictoc-1588overmpls]. However the choice between an external, physical layer or packet based TFS method is network dependent and thus is out of scope of this document." =3D=3D=3D=3D Add the following at the end of section 3.3.2: The TFS considerations stated in Section 3.3.1 apply to the 4G/LTE Mobile Backhaul case. =3D=3D=3D=3D Add Informative reference: [draft-ietf-tictoc-1588overmpls] =3D=3D=3D=3D The new text was generated for us by one of the ADs with lots of experience with timing, so we are happy that it is right. We'll acknowledge all folks commented and contributed to the draft. Thanks, Luyuan -----Original Message----- From: Lucy yong Date: Tuesday, January 15, 2013 12:20 PM To: "loa@pi.nu" , "mpls@ietf.org" Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: RE: [mpls] working group last call Resent-From: Resent-To: Luyuan Fang , , Nabil Bitar , , , , , Resent-Date: Tuesday, January 15, 2013 12:20 PM >I support this. > >The document is well and clearly written. One comment: in section 3.3.1, >it is better to give some recommendation or options regarding how to >provide timing to BTS. This is important for 2G/3G backhaul. > >Cheers, >Lucy=20 > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> loa@pi.nu >> Sent: Monday, January 14, 2013 4:41 AM >> To: mpls@ietf.org >> Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-use-cases-and- >> design@tools.ietf.org >> Subject: [mpls] working group last call >>=20 >> Working Group, >>=20 >> this is to start a two week Working Group last call on >> draft-ietf-mpls-tp-use-cases-and-design. >>=20 >> This is the second time we working group last call this >> draft, it has been updated after comments during the >> ADE-review. The changes are such that we have decided to >> do a full two week wglc. >>=20 >> Please send your comments to the mpls working group >> mailing list (mpls@ietf.org). >>=20 >> Please send both technical comments, and if you are happy >> with the document as is also indications of support. >>=20 >> There are no IPR claims against this draft. >>=20 >> All the co-authors has stated that they are not aware >> of any IPRs. >>=20 >> This working group last call will end on January 25, 2013. >>=20 >> /Loa >> for the wg co-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 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From Kingston.selvaraj@ipinfusion.com Wed Jan 23 01:17:31 2013 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 D12C721F8497 for ; Wed, 23 Jan 2013 01:17:30 -0800 (PST) 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 KxfQj+0eviYh for ; Wed, 23 Jan 2013 01:17:30 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2E121F8206 for ; Wed, 23 Jan 2013 01:17:28 -0800 (PST) Received: from mail36-db3-R.bigfish.com (10.3.81.236) by DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 Jan 2013 09:17:28 +0000 Received: from mail36-db3 (localhost [127.0.0.1]) by mail36-db3-R.bigfish.com (Postfix) with ESMTP id E2DEA3802F7; Wed, 23 Jan 2013 09:17:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0512HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371I542I4015I62a3Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received-SPF: pass (mail36-db3: domain of ipinfusion.com designates 157.56.238.5 as permitted sender) client-ip=157.56.238.5; envelope-from=Kingston.selvaraj@ipinfusion.com; helo=BY2PRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail36-db3 (localhost.localdomain [127.0.0.1]) by mail36-db3 (MessageSwitch) id 1358932601122847_9258; Wed, 23 Jan 2013 09:16:41 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.241]) by mail36-db3.bigfish.com (Postfix) with ESMTP id 167D14A0305; Wed, 23 Jan 2013 09:16:41 +0000 (UTC) Received: from BY2PRD0512HT002.namprd05.prod.outlook.com (157.56.238.5) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 Jan 2013 09:16:40 +0000 Received: from BY2PRD0512MB656.namprd05.prod.outlook.com ([169.254.7.162]) by BY2PRD0512HT002.namprd05.prod.outlook.com ([10.255.243.35]) with mapi id 14.16.0257.004; Wed, 23 Jan 2013 09:16:39 +0000 From: Kingston Selvaraj To: Loa Andersson , "mpls@ietf.org" , "draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Thread-Topic: IPR poll on draft-smiler-mpls-tp-linear-protection-mib Thread-Index: AQHN+Uej3MZOdV1iq0GHgwVJ68rd5phWodug Date: Wed, 23 Jan 2013 09:16:38 +0000 Message-ID: <4090125F3B48764B84FB3439456F00E9377DAE59@BY2PRD0512MB656.namprd05.prod.outlook.com> References: <50FFA5E1.7070001@pi.nu> In-Reply-To: <50FFA5E1.7070001@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [182.73.206.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ipinfusion.com X-Mailman-Approved-At: Thu, 24 Jan 2013 10:59:08 -0800 Subject: Re: [mpls] IPR poll on draft-smiler-mpls-tp-linear-protection-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: Wed, 23 Jan 2013 09:20:06 -0000 Hi Loa, I'm not aware of any IPR related to draft-smiler-mpls-tp-linear-protection-= mib Regards, S. Kingston Smiler. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Wednesday, January 23, 2013 2:27 PM To: mpls@ietf.org; draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.or= g; mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: IPR poll on draft-smiler-mpls-tp-linear-protection-mib Working Group and authors; The authors of draft-smiler-mpls-tp-linear-protection-mib has indicated tha= t the draft is ready to be adopted as a working group document. Before starting the poll to see if there is wg consensus to make the draft = a working group document we will do an IPR poll to check whether there is I= PR on the document that needs to be disclosed. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-smiler-mpls-tp-linear- prote= ction-mib? 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. *Th= e response needs to be sent to the MPLS wg mailing list.* The documents wil= l not advance to the next stage until a response has been received from eac= h 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@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From curtis@occnc.com Thu Jan 24 12:08:31 2013 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 1954321F84C6 for ; Thu, 24 Jan 2013 12:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 KRk+B0i2uML1 for ; Thu, 24 Jan 2013 12:08:30 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id CE5DC21F84B9 for ; Thu, 24 Jan 2013 12:08:24 -0800 (PST) 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 r0OK766x017199; Thu, 24 Jan 2013 15:07:06 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301242007.r0OK766x017199@gateway1.orleans.occnc.com> To: Loa Andersson From: Curtis Villamizar In-reply-to: Your message of "Mon, 21 Jan 2013 10:50:57 +0100." <50FD0F81.4010509@pi.nu> Date: Thu, 24 Jan 2013 15:07:05 -0500 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-villamizar-mpls-multipath-use@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-villamizar-mpls-multipath-use 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: Thu, 24 Jan 2013 20:08:31 -0000 Loa, I am not aware of any IPR that is applicable to this internet-draft. Curtis In message <50FD0F81.4010509@pi.nu> Loa Andersson writes: > > Working Group and authors; > > The authors of draft-villamizar-mpls-multipath-use has indicated that > the draft is ready to be adopted as a working group document. > > Before starting the poll to see if there is wg consensus to make the > draft 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-villamizar- > mpls-multipath-use? > > 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. > > Note: There were an IPR disclosure on an earlier document > "draft-villamizar-mpls-tp-multipath" that IPR is not applicable to this > document. > > > Thanks, Loa > (as MPLS WG co-chair) > > -- > > > Loa Andersson email: loa@mail01.huawei.com > MPLS Expert loa@pi.nu > Huawei Technologies (consult) phone: +46 739 81 21 64 From lucy.yong@huawei.com Thu Jan 24 13:37:37 2013 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 1B64421F850C for ; Thu, 24 Jan 2013 13:37:37 -0800 (PST) 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 CqurOado+I4k for ; Thu, 24 Jan 2013 13:37:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB1121F8487 for ; Thu, 24 Jan 2013 13:37:33 -0800 (PST) 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 APB89028; Thu, 24 Jan 2013 21:37:33 +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.7; Thu, 24 Jan 2013 21:37:13 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 24 Jan 2013 21:37:32 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Thu, 24 Jan 2013 13:37:29 -0800 From: Lucy yong To: "Luyuan Fang (lufang)" , "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: [mpls] working group last call Thread-Index: AQHN8kOjNM8rY2JDFUmNbqQD1YOrLZhK1VywgA5eewD//91fIA== Date: Thu, 24 Jan 2013 21:37:29 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4487A513@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4487679C@dfweml505-mbx> <0DB8F45437AB844CBB5102F807A0AD931026B313@xmb-rcd-x03.cisco.com> In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD931026B313@xmb-rcd-x03.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.87.127] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: Re: [mpls] working group last call 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, 24 Jan 2013 21:37:37 -0000 I am glad to see these additions. Text is fine to me. Thanks, Lucy > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Luyuan Fang (lufang) > Sent: Thursday, January 24, 2013 9:40 AM > To: Lucy yong; loa@pi.nu; mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-use-cases-and- > design@tools.ietf.org > Subject: Re: [mpls] working group last call >=20 > Lucy, >=20 > Thanks for your support and comment. >=20 > Here is our update to address your comment on timing. >=20 > =3D=3D=3D > In 3.3.1 we already state: >=20 > "The deterministic nature of MPLS-TP LSP set up can also support packet > based synchronization to maintain predictable performance regarding > packet delay and jitters." >=20 > We now expand this to: >=20 > "The traffic engineered and co-routed bidirectional properties of an > MPLS-TP LSP are of benefit in transporting packet based time and > frequency synchronization (TFS) protocols such as > [draft-ietf-tictoc-1588overmpls]. However the choice between an > external, physical layer or packet based TFS method is > network dependent and thus is out of scope of this document." >=20 > =3D=3D=3D=3D >=20 > Add the following at the end of section 3.3.2: >=20 > The TFS considerations stated in Section 3.3.1 apply to the > 4G/LTE Mobile Backhaul case. >=20 > =3D=3D=3D=3D > Add Informative reference: > [draft-ietf-tictoc-1588overmpls] >=20 >=20 > =3D=3D=3D=3D >=20 > The new text was generated for us by one of the ADs with lots of > experience with timing, so we are happy that it is right. >=20 >=20 > We'll acknowledge all folks commented and contributed to the draft. >=20 > Thanks, > Luyuan >=20 >=20 > -----Original Message----- > From: Lucy yong > Date: Tuesday, January 15, 2013 12:20 PM > To: "loa@pi.nu" , "mpls@ietf.org" > Cc: "mpls-chairs@tools.ietf.org" , > "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" > > Subject: RE: [mpls] working group last call > Resent-From: > Resent-To: Luyuan Fang , , Nabil > Bitar , , > , , , > > Resent-Date: Tuesday, January 15, 2013 12:20 PM >=20 > >I support this. > > > >The document is well and clearly written. One comment: in section > 3.3.1, > >it is better to give some recommendation or options regarding how to > >provide timing to BTS. This is important for 2G/3G backhaul. > > > >Cheers, > >Lucy > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> loa@pi.nu > >> Sent: Monday, January 14, 2013 4:41 AM > >> To: mpls@ietf.org > >> Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-use-cases-and- > >> design@tools.ietf.org > >> Subject: [mpls] working group last call > >> > >> Working Group, > >> > >> this is to start a two week Working Group last call on > >> draft-ietf-mpls-tp-use-cases-and-design. > >> > >> This is the second time we working group last call this > >> draft, it has been updated after comments during the > >> ADE-review. The changes are such that we have decided to > >> do a full two week wglc. > >> > >> 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. > >> > >> There are no IPR claims against this draft. > >> > >> All the co-authors has stated that they are not aware > >> of any IPRs. > >> > >> This working group last call will end on January 25, 2013. > >> > >> /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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Thu Jan 24 13:45:27 2013 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 187A61F0CAF for ; Thu, 24 Jan 2013 13:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 9J9zGmeMnjdx for ; Thu, 24 Jan 2013 13:45:26 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1391121F857D for ; Thu, 24 Jan 2013 13:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5254; q=dns/txt; s=iport; t=1359063926; x=1360273526; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Wht4DFkfK/C+PL2gpOq3d/vGu15rVt3RssVXSH5Km7M=; b=MQE//iDgJhXAnwPZhXUQ8yBT1L0Rlf/3TOxm0b9BWJwMK1RUtdJTISHN +bBMOrOpb64Lbi31AWUey8kNCQz0M3kyc8PwVOD9od3tRr5XABRUeP+J9 vEKyvemJdZoqIur7uSswY1qNGLfAzFOVJQtcZeC6fMjnfrM7tl58MPdjH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFqqAVGtJV2c/2dsb2JhbABEvkoWc4IeAQEBBAEBATc0CwwCBAEIEQMBAQELFAkiDAsUCQgCBAENBQiIAAMPDL4WBASMCHeDF2EDplSCeIFvNQ X-IronPort-AV: E=Sophos;i="4.84,532,1355097600"; d="scan'208";a="167753359" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 24 Jan 2013 21:45:23 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0OLjNQU018445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jan 2013 21:45:23 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 15:45:23 -0600 From: "Luyuan Fang (lufang)" To: Lucy yong , "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: [mpls] working group last call Thread-Index: AQHN8kOhO9NeXmS+hEuIsU0xoNTiYphLO4qAgA2C84CAALeVgP//rmGA Date: Thu, 24 Jan 2013 21:45:22 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931026B9B1@xmb-rcd-x03.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4487A513@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.149.163] Content-Type: text/plain; charset="us-ascii" Content-ID: <9140E374D264AF4BA05473E06A06EBC8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: Re: [mpls] working group last call 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, 24 Jan 2013 21:45:27 -0000 Thanks, Lucy. The text is in the new version now. We'll post it once the last call has ended. Luyuan -----Original Message----- From: Lucy yong Date: Thursday, January 24, 2013 1:37 PM To: Luyuan Fang , "loa@pi.nu" , "mpls@ietf.org" Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" Subject: RE: [mpls] working group last call >I am glad to see these additions. Text is fine to me. >Thanks, >Lucy > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Luyuan Fang (lufang) >> Sent: Thursday, January 24, 2013 9:40 AM >> To: Lucy yong; loa@pi.nu; mpls@ietf.org >> Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-use-cases-and- >> design@tools.ietf.org >> Subject: Re: [mpls] working group last call >>=20 >> Lucy, >>=20 >> Thanks for your support and comment. >>=20 >> Here is our update to address your comment on timing. >>=20 >> =3D=3D=3D >> In 3.3.1 we already state: >>=20 >> "The deterministic nature of MPLS-TP LSP set up can also support packet >> based synchronization to maintain predictable performance regarding >> packet delay and jitters." >>=20 >> We now expand this to: >>=20 >> "The traffic engineered and co-routed bidirectional properties of an >> MPLS-TP LSP are of benefit in transporting packet based time and >> frequency synchronization (TFS) protocols such as >> [draft-ietf-tictoc-1588overmpls]. However the choice between an >> external, physical layer or packet based TFS method is >> network dependent and thus is out of scope of this document." >>=20 >> =3D=3D=3D=3D >>=20 >> Add the following at the end of section 3.3.2: >>=20 >> The TFS considerations stated in Section 3.3.1 apply to the >> 4G/LTE Mobile Backhaul case. >>=20 >> =3D=3D=3D=3D >> Add Informative reference: >> [draft-ietf-tictoc-1588overmpls] >>=20 >>=20 >> =3D=3D=3D=3D >>=20 >> The new text was generated for us by one of the ADs with lots of >> experience with timing, so we are happy that it is right. >>=20 >>=20 >> We'll acknowledge all folks commented and contributed to the draft. >>=20 >> Thanks, >> Luyuan >>=20 >>=20 >> -----Original Message----- >> From: Lucy yong >> Date: Tuesday, January 15, 2013 12:20 PM >> To: "loa@pi.nu" , "mpls@ietf.org" >> Cc: "mpls-chairs@tools.ietf.org" , >> "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" >> >> Subject: RE: [mpls] working group last call >> Resent-From: >> Resent-To: Luyuan Fang , , Nabil >> Bitar , , >> , , , >> >> Resent-Date: Tuesday, January 15, 2013 12:20 PM >>=20 >> >I support this. >> > >> >The document is well and clearly written. One comment: in section >> 3.3.1, >> >it is better to give some recommendation or options regarding how to >> >provide timing to BTS. This is important for 2G/3G backhaul. >> > >> >Cheers, >> >Lucy >> > >> >> -----Original Message----- >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >> >> loa@pi.nu >> >> Sent: Monday, January 14, 2013 4:41 AM >> >> To: mpls@ietf.org >> >> Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-use-cases-and- >> >> design@tools.ietf.org >> >> Subject: [mpls] working group last call >> >> >> >> Working Group, >> >> >> >> this is to start a two week Working Group last call on >> >> draft-ietf-mpls-tp-use-cases-and-design. >> >> >> >> This is the second time we working group last call this >> >> draft, it has been updated after comments during the >> >> ADE-review. The changes are such that we have decided to >> >> do a full two week wglc. >> >> >> >> 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. >> >> >> >> There are no IPR claims against this draft. >> >> >> >> All the co-authors has stated that they are not aware >> >> of any IPRs. >> >> >> >> This working group last call will end on January 25, 2013. >> >> >> >> /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 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From curtis@occnc.com Thu Jan 24 14:43:07 2013 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 89B0B1F0CF6 for ; Thu, 24 Jan 2013 14:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 fw57BUTG+Vf6 for ; Thu, 24 Jan 2013 14:43:07 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id DCA201F0CAF for ; Thu, 24 Jan 2013 14:43:03 -0800 (PST) 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 r0OMffde018746; Thu, 24 Jan 2013 17:41:41 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301242241.r0OMffde018746@gateway1.orleans.occnc.com> To: curtis@occnc.com From: Curtis Villamizar In-reply-to: Your message of "Tue, 22 Jan 2013 22:40:18 EST." <201301230340.r0N3eIO6069247@gateway1.orleans.occnc.com> Date: Thu, 24 Jan 2013 17:41:40 -0500 Cc: "mpls@ietf.org" Subject: [mpls] minor clarification (was Re: MPLS-RT review of draft-villamizar-mpls-multipath-use) 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: Thu, 24 Jan 2013 22:43:07 -0000 Carlos, Looking over prior email, a minor clarification came to mind. In message <201301230340.r0N3eIO6069247@gateway1.orleans.occnc.com> Curtis Villamizar writes: > > > In message <95067C434CE250468B77282634C96ED3228D4D01@xmb-aln-x02.cisco.com> > "Carlos Pignataro (cpignata)" writes: > > [ ... big snip ... ] > > 4. The concepts of unequal load split or otherwise load balancing > > proportionally to some ratio in different links/paths are briefly > > mentioned but could be more explicitly covered. The ECMP definition > > mentions this (proportionally to capacity), but in that case it > > would not be "Equal". Similarly, concepts like "fairly evenly > > distributed" are used in definitions but not explained -- might not > > be needed perhaps, but what is fair and what is even in different > > scenarios can be understood differently. > > Familiarity with prior work in multipath in core routers would help > the reader. Unfortunately not much has been published. > > Some useful information can be found in draft-ietf-rtgwg-cl-use-cases > in Appendix B. There is also useful descriptions of expectations > regarding limiting the frequency of load balancing and the inevitable > imperfect balancing in that document and the CL documents in RTGWG: > draft-ietf-rtgwg-cl-{requirements,framework} The "equal" in "ECMP" applies to equal cost. So if a 10GbE server layer LSP and 100GbE server layer LSP (ie: Packet Switch Capable LSP or PSC LSP) have equal administrative costs, then it still makes sense to split the load unequally. The same applies to ECMP when all of the links have the same next-hop, though I'm not sure who if anyone still supports that. In any case the term "multipath" is used in this document for a number or reasons. One reason is to avoid any confusion about limitations of some ECMP implementations or preconceived notions of ECMP limitations, such as any notion that the load must be split evenly. Another reason is to include Ethernet Link Aggregation, Link Bundling, as well as ECMP, but exclude inverse-mux, hence the definitions (in Section 2): Multipath The term multipath includes all techniques in which 1. Traffic can take more than one path from one node to a destination. 2. Individual packets take one path only. Packets are not subdivided and reassembled at the receiving end. 3. Packets are not resequenced at the receiving end. 4. The paths may be: a. parallel links between two nodes, or b. may be specific paths across a network to a destination node, or c. may be links or paths to an intermediate node used to reach a common destination. [...] Composite Link The term Composite Link had been a registered trademark of Avici Systems, but was abandoned in 2007. The term composite link is now defined by the ITU in [ITU-T.G.800]. The ITU definition includes multipath as defined here, plus inverse multiplexing which is explicitly excluded from the definition of multipath. Regards, Curtis From cpignata@cisco.com Thu Jan 24 15:27:33 2013 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 70B0221F86BA for ; Thu, 24 Jan 2013 15:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 6juZPqSWqT-M for ; Thu, 24 Jan 2013 15:27:30 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 582AA21F853A for ; Thu, 24 Jan 2013 15:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3811; q=dns/txt; s=iport; t=1359070050; x=1360279650; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D9j7Ok8nvtFeWw/vdmZDoouwjwriTrJWmSIg3P6qqBE=; b=UESvyz8MEnpfNo0H54YpZ03jtf085ZwvxDd2QKhXEqSWnL26dIEsoe7h XJvOGCfzRLONVViaDQBHAXLcHGeaJEQs8fLTzHLtavDDATtfoThptwrbN PTrIWHbfnlmAFsayJC8iDpY8i+s73/65VXnzB3ykdJtcG2HpQowBeDypy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPPBAVGtJXG+/2dsb2JhbABEvkUWc4IeAQEBAwE6PwULAgEIIhQQMiUCBA4FCIgMBr4ljQODF2EDplSCeIFmBgMXHg X-IronPort-AV: E=Sophos;i="4.84,532,1355097600"; d="scan'208";a="164771528" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jan 2013 23:27:27 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0ONRR1n009844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jan 2013 23:27:27 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 17:27:27 -0600 From: "Carlos Pignataro (cpignata)" To: "" Thread-Topic: minor clarification (was Re: MPLS-RT review of draft-villamizar-mpls-multipath-use) Thread-Index: AQHN+oQAM5rsuWm05USJfi+M6rAUg5hZhEiA Date: Thu, 24 Jan 2013 23:27:26 +0000 Message-ID: <95067C434CE250468B77282634C96ED3228E8918@xmb-aln-x02.cisco.com> References: <201301242241.r0OMffde018746@gateway1.orleans.occnc.com> In-Reply-To: <201301242241.r0OMffde018746@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <19F9F5BDC71CE14783E4C9416B5B2F01@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] minor clarification (was Re: MPLS-RT review of draft-villamizar-mpls-multipath-use) 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, 24 Jan 2013 23:27:33 -0000 Curtis, On Jan 24, 2013, at 5:41 PM, Curtis Villamizar wrote: >=20 > Carlos, >=20 > Looking over prior email, a minor clarification came to mind. >=20 > In message <201301230340.r0N3eIO6069247@gateway1.orleans.occnc.com> > Curtis Villamizar writes: >>>=20 >> In message <95067C434CE250468B77282634C96ED3228D4D01@xmb-aln-x02.cisco.c= om> >> "Carlos Pignataro (cpignata)" writes: >>>=20 >=20 > [ ... big snip ... ] >=20 >>> 4. The concepts of unequal load split or otherwise load balancing >>> proportionally to some ratio in different links/paths are briefly >>> mentioned but could be more explicitly covered. The ECMP definition >>> mentions this (proportionally to capacity), but in that case it >>> would not be "Equal". Similarly, concepts like "fairly evenly >>> distributed" are used in definitions but not explained -- might not >>> be needed perhaps, but what is fair and what is even in different >>> scenarios can be understood differently. >>=20 >> Familiarity with prior work in multipath in core routers would help >> the reader. Unfortunately not much has been published. >>=20 >> Some useful information can be found in draft-ietf-rtgwg-cl-use-cases >> in Appendix B. There is also useful descriptions of expectations >> regarding limiting the frequency of load balancing and the inevitable >> imperfect balancing in that document and the CL documents in RTGWG: >> draft-ietf-rtgwg-cl-{requirements,framework} >=20 > The "equal" in "ECMP" applies to equal cost. So if a 10GbE server > layer LSP and 100GbE server layer LSP (ie: Packet Switch Capable LSP > or PSC LSP) have equal administrative costs, then it still makes sense > to split the load unequally. The same applies to ECMP when all of the > links have the same next-hop, though I'm not sure who if anyone still > supports that. >=20 > In any case the term "multipath" is used in this document for a number > or reasons. One reason is to avoid any confusion about limitations of > some ECMP implementations or preconceived notions of ECMP limitations, > such as any notion that the load must be split evenly. Another reason > is to include Ethernet Link Aggregation, Link Bundling, as well as > ECMP, but exclude inverse-mux, hence the definitions (in Section 2): >=20 > Multipath I should have said this in my review: I like the approach of using a new te= rm, "Multipath", for this, and abstract from the implications of "ECMP" and= group various techniques. I think it is really good. Normalizing definitio= ns with draft-ietf-rtgwg-cl-* would be ideal as well. Thanks, -- Carlos. > The term multipath includes all techniques in which >=20 > 1. Traffic can take more than one path from one node to a > destination. >=20 > 2. Individual packets take one path only. Packets are not > subdivided and reassembled at the receiving end. >=20 > 3. Packets are not resequenced at the receiving end. >=20 > 4. The paths may be: >=20 > a. parallel links between two nodes, or >=20 > b. may be specific paths across a network to a destination > node, or >=20 > c. may be links or paths to an intermediate node used to > reach a common destination. >=20 > [...] >=20 > Composite Link > The term Composite Link had been a registered trademark of > Avici Systems, but was abandoned in 2007. The term composite > link is now defined by the ITU in [ITU-T.G.800]. The ITU > definition includes multipath as defined here, plus inverse > multiplexing which is explicitly excluded from the definition > of multipath. >=20 > Regards, >=20 > Curtis >=20 From cpignata@cisco.com Thu Jan 24 15:27:36 2013 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 3434511E80D2 for ; Thu, 24 Jan 2013 15:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 EBMKCKmLd-Kq for ; Thu, 24 Jan 2013 15:27:35 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1C60211E809A for ; Thu, 24 Jan 2013 15:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7182; q=dns/txt; s=iport; t=1359070055; x=1360279655; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VKzroztYoyKGoXJEZiTC6EylTSaccd2uFAALGMu48bc=; b=Z5G+YcXboAr95AZGviyLegjODzSHcdUVfR1GkHuswHBs2h/v0yVP9AxQ 6QRvUtO1yz+IQhwNfz81QE2AhjB2noJT8xf8w6IfFYhwlrYwCxUO1Ynyq 6EryCyUbsALFQ4ehZQtRR5aHT7jEy8m7Wq7LYpcYNZo7ktChVBD3XUKCZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABvDAVGtJV2a/2dsb2JhbAA6Cr5FFnOCHgEBAQMBOj8QAgEIEhAUEDIXDgIEDgUIE4d5Br4jjQmDEWEDplSCeIIk X-IronPort-AV: E=Sophos;i="4.84,532,1355097600"; d="scan'208";a="167553391" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jan 2013 23:27:19 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0ONRJnN021307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jan 2013 23:27:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 17:27:19 -0600 From: "Carlos Pignataro (cpignata)" To: "curtis@occnc.com" Thread-Topic: MPLS-RT review of draft-villamizar-mpls-multipath-use Thread-Index: AQHN+RtcJFyYpNkTVE2p5oCIr0f+cZhZhxCA Date: Thu, 24 Jan 2013 23:27:18 +0000 Message-ID: <95067C434CE250468B77282634C96ED3228E88FE@xmb-aln-x02.cisco.com> References: <201301230340.r0N3eIO6069247@gateway1.orleans.occnc.com> In-Reply-To: <201301230340.r0N3eIO6069247@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <1958DB027D340944AB89FC6D6894DC24@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "" , "draft-villamizar-mpls-multipath-use@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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, 24 Jan 2013 23:27:36 -0000 Hi, Curtis, On Jan 22, 2013, at 10:40 PM, Curtis Villamizar wrote: >=20 > In message <95067C434CE250468B77282634C96ED3228D4D01@xmb-aln-x02.cisco.co= m> > "Carlos Pignataro (cpignata)" writes: >>=20 >> Hello, >>=20 >> I have been selected as an MPLS Review team reviewer for >> draft-villamizar-mpls-multipath-use-00. >>=20 >> I read this document, and I believe it is ready to be considered for >> WG adoption and it is a really good start -- although I also believe >> that more work and discussion needs to happen in Section 3 (where >> solutions and requirements are presented). >=20 > Looks like you and Dave are in agreement on that. >=20 > I look forward to specific suggestions, but I will reread the section > and try to make it more clear and more explicit. >=20 >> I also believe this is a very well written document. It describes a >> real problem space adequately providing citations with context and >> background, and explains cases that are useful in real operational >> networks. >>=20 >> Additionally, I have some (minor and editorial) comments and questions >> for consideration. >>=20 >> Minor: >>=20 >> 1. I was surprised that Section 3.1.1 of RFC 5960 was not cited, as >> that defines the MPLS-TP requirements for ECMP load balancing. >=20 > Thank you for pointing that out. The requirement to not load split > MPLS-TP is mentioned but the citation is not made. In fact I will > quote the following paragraph verbatim. >=20 > Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed > on an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY > operate over a server layer that supports load-balancing, but this > load-balancing MUST operate in such a manner that it is transparent > to MPLS-TP. This does not preclude the future definition of new > MPLS-TP LSP types that have different requirements regarding the > use of ECMP in the server layer. >=20 > Use of ECMP is allowed in the server layer, as long as it is > transparent to the MPLS-TP client layer. >=20 >> 2. In the requirement MP#1, what does "identify" mean? Identify in the >> edges where nodes have visibility to both layers, tag, identify in >> mid-point nodes? >=20 > A MPLS-TP LSP may be aggregated by a midpoint LSR into a very large > MPLS LSP, as would be the case in a core node to core node MPLS LSP > between major cities. In this case the ingress of the MPLS LSP cannot > through any existing signaling mechanism identify those client LSP > contained with it as MPLS-TP or not MPLS-TP. For those client LSP > that are MPLS-TP LSP, a single EL value must be chosen. For those > client LSP that are MPLS LSP, per packet entropy below the top label > must be (for practical reasons "must" not "should") used to determine > the entropy label value. >=20 > Also, a MPLS-TP ingress may not know that an LSP it is setting up is > going over a RFC 6790 capable LAG. If the LSP is not identified as > being MPLS-TP, then load splitting would occur. >=20 > OTOH - If the MPLS-TP ingress picked a random number and used that in > an EL, even if it had no multipath interface the problem is solved, > but that is already pointed out in the document. >=20 > Do I need to change the text to clarify what is meant by "identify" in > this context? >=20 > Perhaps the requirement should be: >=20 > MP#1 It MUST be possible to identify MPLS-TP LSP or otherwise > accommodate the MPLS-TP LSP requirement to avoid reordering > of packets. >=20 > The latter phrase acknowledges that adding an ELI and EL is fine. Yes, I agree this is good refinement of the requirement. >=20 >> 3. I think the concepts of utilizing {ELI; EL} need further discussion >> in the document. Similarly, so do the implications on the topic of >> the differences of LAG vs. ECMP (both defined explicitly). >=20 > Perhaps the use of ELI and EL needs to be more explicit. Dave seems > to share your opinion that more detail is needed. I would think so. >=20 >> 4. The concepts of unequal load split or otherwise load balancing >> proportionally to some ratio in different links/paths are briefly >> mentioned but could be more explicitly covered. The ECMP definition >> mentions this (proportionally to capacity), but in that case it >> would not be "Equal". Similarly, concepts like "fairly evenly >> distributed" are used in definitions but not explained -- might not >> be needed perhaps, but what is fair and what is even in different >> scenarios can be understood differently. >=20 > Familiarity with prior work in multipath in core routers would help > the reader. Unfortunately not much has been published. Do you think that an Informative pointer would help? These rtgwg documents = do apply to IP and MPLS. >=20 > Some useful information can be found in draft-ietf-rtgwg-cl-use-cases > in Appendix B. There is also useful descriptions of expectations > regarding limiting the frequency of load balancing and the inevitable > imperfect balancing in that document and the CL documents in RTGWG: > draft-ietf-rtgwg-cl-{requirements,framework} >=20 >> 5. In requirement MP#2, is the requirement to "completely exclude from >> the hash", or to "always coming up with the same output, either by >> excluding or including but always resulting in the same"? (i.e., is >> excluding a way of getting to the result, or is it the result?) >=20 > In this context "completely excluding the MPLS-TP LSP ..." is the > functional equivalent to MPLS Link Bundling with pinning. >=20 > There is very little distinction between MP#2 and MP#3, except that > MP#3 allows that the LSP could be moved if requirements could no > longer be met (component link down, LSP preempted from the component > link, etc). I see. Thanks. >=20 >> Nits: >>=20 >> 1. Some times, I think that in many instances, "MPLS LSP" and "MPLS-TP >> LSP" should be plural (s/LSP/LSPs/). Consequently, not always clear >> when is talking about splitting a single LSP as opposed to >> splitting multiple LSPs. >=20 > OK. I'll look for instances of LSP that should be LSPs. >=20 >> 2. Some acronyms are not expanded on first use (or not defined), like >> CSPF, PSC, ILM, others. >=20 > ILM is expanded in RFC 3031 (MPLS Architecture) in the table of > contents. :-) >=20 > PSC is expanded in RFC 3471 (GMPLS Signaling Functional Description). >=20 > CSPF is expanded in RFC 3945 (GMPLS Architecture). >=20 > These are all base MPLS documents, but I agree that expanding even > well known acronyms makes the document more readable. >=20 > Thanks for pointing this out. >=20 >> 3. s/overa/over a/ >=20 > Got it. >=20 >> I hope these are clear and useful. >=20 > They are both clear and useful. I will try to reword the sections > where clarity may be lacking or where I need to be more explicit. > Thank you for the review. >=20 Anytime! Thanks for considering the comments. -- Carlos. >> Thank you, >>=20 >> Carlos Pignataro. >=20 > Regards, >=20 > Curtis >=20 From curtis@occnc.com Thu Jan 24 16:26:10 2013 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 645AB11E80D3 for ; Thu, 24 Jan 2013 16:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, 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 vrxjnthsK4Iq for ; Thu, 24 Jan 2013 16:26:10 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id CA55C11E8099 for ; Thu, 24 Jan 2013 16:26:09 -0800 (PST) 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 r0P0OkQ0019702; Thu, 24 Jan 2013 19:24:46 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301250024.r0P0OkQ0019702@gateway1.orleans.occnc.com> To: David Allan I From: Curtis Villamizar In-reply-to: Your message of "Wed, 23 Jan 2013 17:18:50 EST." <201301232218.r0NMIoAp096605@gateway1.orleans.occnc.com> Date: Thu, 24 Jan 2013 19:24:45 -0500 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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: Fri, 25 Jan 2013 00:26:10 -0000 Dave, I changed the wording on one of the changes. See below. Regards, Curtis In message <201301232218.r0NMIoAp096605@gateway1.orleans.occnc.com> Curtis Villamizar writes: > > In message > David Allan I writes: [ ... huge snip ... ] > So far all I say is: > > Requirement MP#4 can be supported using administrative attributes. > Administrative attributes are defined in [RFC3209]. Some > configuration is required to support this. > > I'll preceed that with: > > Links or MPLS LSP which traverse LAG or ECMP with adjacent LSR that > do not support [RFC6790] cannot support MPLS-TP requirements. This > is the reason for including requirement MP#4. The ingress of an > MPLS-TP LSP must be able to avoid these links or MPLS LSP. > > I think this addresses your concern. [btw- sometimes it is better to > state what is obvious to some readers than confuse the others > readers, so I agree that this is an improvement.] I replaced the suggested new paragraph above with: An MPLS-TP LSP may not traverse multipath links on the path where MPLS-TP forwarding requirements cannot be met. Such links include any using pre-RFC6790 Ethernet Link Aggregation, pre-RFC6790 Link Bundling using the all-ones component link, or other form of multipath not supporting termination of the entropy search at the EL label as called for in [RFC6790]. An MPLS-TP LSP must not traverse a server layer MPLS LSP which traverses any form of multipath not supporting termination of the entropy search at the EL label. For this to occur, the MPLS-TP ingress LSR must be aware of these links. This is the reason for requirement MP#4. This is a bit verbose, but "LAG and ECMP" in the original suggested wording isn't quite right and there was no mention of avoiding the FA for server layer LSP that traversed these "bad links". Curtis From curtis@occnc.com Thu Jan 24 16:39:52 2013 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 0C34E21F8423 for ; Thu, 24 Jan 2013 16:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 ls5KwyqZLsh9 for ; Thu, 24 Jan 2013 16:39:50 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 369C221F8433 for ; Thu, 24 Jan 2013 16:39:50 -0800 (PST) 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 r0P0cWoZ019764; Thu, 24 Jan 2013 19:38:32 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301250038.r0P0cWoZ019764@gateway1.orleans.occnc.com> To: David Allan I From: Curtis Villamizar In-reply-to: Your message of "Wed, 23 Jan 2013 22:43:13 GMT." Date: Thu, 24 Jan 2013 19:38:32 -0500 Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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: Fri, 25 Jan 2013 00:39:52 -0000 Dave, When explicitly referencing the requirements, there was enough to create a small subsection (3.1). So now section 3 is: 3. MPLS as a Server Layer for MPLS-TP 3.1. MPLS-TP Forwarding and Server Layer Requirements 3.2. Methods of Supporting MPLS-TP client LSPs over MPLS In section 3.2 I now use the phrase "MPLS-TP forwarding requirements" and refer back to section 3.1 rather than using either the phrase "MPLS-TP OAM fate-sharing requirements" or the phrase "MPLS-TP packet ordering requirements" in section 3.2. I did some rewording and additions to improve clarity and be more specific in section 3, as requested in general comments by reviewers. I'll send annotated diffs in a little while so that you and other MPLS-RT expert reviewers can make sure all comments (so far) are addressed and the changes are to your liking. Regards, Cuertis In message David Allan I writes: Hi Curtis Thanks for the reply, and yes LM has a strict ordering constraint, while FM wants fate sharing, I was brain-farting on the PM/LM component of OAM when reading it and thinking FM which is the usual discussion on this list.... So now I understand the motivation for the way you had phrased the text. Not spreading an individual TP LSP out across multiple links actually satifies both so IMO there is a dual motivation for the requirement. If referring to the OAM ordering requirement, I'd suggest calling it "the strict packet ordering requirement that TP Performance monitoring requires", so it cannot be confused with simply in order delivery of OAM PDUs in isolation; the OAM PDU's relative position with respect to the interleaved real traffic actually matters. I also have no issue with the digression on capacity allocation determinism and SLA monitoring vs. actual behavior. Other that that I would observe actual mileage observed by the different modes of operation depends on the actual traffic profile, e.g. large number of small flows vs. small number of large flows.... Cheers D -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Wednesday, January 23, 2013 2:19 PM To: David Allan I Cc: curtis@occnc.com; mpls@ietf.org; Martin Vigoureux; mpls-chairs@tools.ietf.org; Loa Andersson Subject: Re: MPLS-RT review of draft-villamizar-mpls-multipath-use In message David Allan I writes: > > HI Curtis: > > Some snipping to help readability and replies prefixed by [Dave] > > > > If it is unclear to you, then the document is not sufficiently clear > and needs fixing. See below. > > [Dave] Great.... > > > Nit: > > > > Section 1 para 2: Refers to MPLS-TP packet ordering as the constraint. > > I'm a bit confused by this, any aggregate that shares an ordering > > constraint does not get spread across parallel links while a set of > > traffic COULD be in theory load spread across a set of MPLS-TP paths > > so long as individual ordering constraints were respected. Is this > > text document really discussing midbox spreading out of load that > > respects ordering constraints but would mean MPLS-TP OAM no longer > > fate shared? Should be reworded if so. Clarified otherwise. > > Section 1 paragraph 2 contains: > > RFC 5654 requirement 33 requires the capability to carry a client > MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer > [RFC5654]. This is possible in all cases with one exception. When > an MPLS LSP exceeds the capacity of any single component link it > may be carried by a network using multipath techniques, but may not > be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity > limitation imposed by MPLS-TP OAM packet ordering constraints. > > The sentence in question is: > > When an MPLS LSP exceeds the capacity of any single component link > it may be carried by a network using multipath techniques, but may > not be carried by an MPLS-TP LSP due to the inherent MPLS-TP > capacity limitation imposed by MPLS-TP OAM packet ordering > constraints. > > Perhaps I could clarify this by changing "carried by an MPLS-TP LSP" > to "carried by a single MPLS-TP LSP". > > The "MPLS-TP OAM packet ordering constraints" is the "fate sharing" > which is the reason that MPLS-TP prohibits using ECMP (aka multipath, > though ECMP is only one form of multipath) with MPLS-TP. This is why > an MPLS LSP (client layer) with capacity greater than a component link > cannot be carried over a *single* MPLS-TP LSP. > > Since this is explained in later sections I could make the > substitution suggested above or I could drop the last sentence and > mention that limitation later. > > [Dave] the sentence I had a problem with was "but may not be carried > by an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation > imposed by MPLS-TP OAM packet ordering constraints." The phrase you are objecting to is "packet ordering constraints". Carlos suggested that I reference or quote RFC 5960 which would clear up exactly what the dataplane requirements are. If direct LM OAM is supported, then there is a strict packet reordering requirement (can't reorder the LM OAM packet relative to payload packets or accuracy suffers) so maybe I need to cite RFC 6374 Section 2.9.4 "Equal Cost Multipath" and Section 4.2.10 "Message Loss and Packet Misorder Conditions". > It is not an ordering constraint, it is a fate sharing constraint. It > read fairly strangely to me as to what the problem was you were trying > to expose. IMO the TP requirements are focused on both determinism of > commitment of network resources for network planning & SLA purposes, > and ability to fully and reliably instrument the connectivity. IMO > multipath violates the latter, whether it violates the former would be > a topic of debate unresolvable in the reality of LAG. LAG simply > scoping the domain of uncertainty for OAM purposes to a link, and > requiring extra link OAM and inheritance... This is an aside, but since you brought this up I'll respond. Begin aside. You made two implied assertions. 1) MPLS-TP is more deterministic, 2) MPLS-TP is necessary to reliably instrument the connectivity. A circuit swtiched (or MPLS-TP) network is more deterministic with respect to how much capacity is allocated. When the capacity in question is a large aggregate of traffic, the packet switched (or MPLS) network is more deterministic with respect to individual customer experience. For example, if many LSP travel across a core and if one city pair is exceeding its expected capactiy but others are slidghtly underutilizing their expected capactiy, then in the circuit switched or MPLS-TP network individual flows for that city pair experience congestion, whereas in a packet switched or MPLS network, capacity is shared and therefore no congestion is experienced. In MPLS core networks the SLA traffic is a fraction of traffic and does fine with little more than TC marking and diffserv treatment. The determinism you describe may be an issue in metro networks, such as where mobile backhaul is mixed with pedestrian Internet traffic and capacity is scarse. Kireeti Kompella and other wrote a paper about two years ago on exactly this topic and it might help if I dug up the reference and included in the document. The latter point regarding reliably instrumenting the connectivity is valid. But if the benefit of instrumenting is for a minority of the traffic (SLA traffic) and the cost is a reduction in network efficiency for the vast majority of traffic (plain old Internet), then there is a substantial increase in cost to provide the instrumented service and then it may not be worth it. This is why MPLS-TP carried over MPLS is of interest. End aside. > [Dave] To make the discussion short, replacing "OAM packet ordering > constraints" with "OAM fate sharing constraints" should be sufficient. In practice the "OAM fate sharing constraints" and "OAM packet ordering constraints" are almost one in the same where LAG or ECMP are the cause of the misordering. LM OAM requires strict packet ordering, not just fate sharing. I'll add the references to RFC 5960 and RFC 6374 and let those RFCs state the requirements. > > Main issue: > > > > Section 3: I think this needs a bit of work, it starts to discuss > > tractable solutions but IMO is technically incomplete. IF an entropy > > label and ELI (where all traffic associated with the MPLS_TP LSP > > shares a common randomly selected entropy label value, which is not > > stated) are the only mechanisms of ensuring proper treatment (with > > all transit nodes implementing entropy and ELI processing such that > > seeking sources of entropy is capped for such LSPs), and the ingress > > node (which by some means SHOULD be able to know it is a TP LSP as > > it has layer visibility) and the egress node can strip entropy and > > ELI then a solution exists for proper fate sharing and ordering of a > > TP LSP over MPLS. It is IMO not quiet eluciated completely. > > Your paragraph above describes the solution, but then says "It is IMO > not quiet eluciated completely." > > [Dave] Well I know you and I know the solution, but someone newer to > the subject would not necessarily be able to infer it from the > document in its current state. OK. Fair enough. > So lets parse your paragraph and see what the draft is missing: > > > Section 3: I think this needs a bit of work, it starts to discuss > > tractable solutions but IMO is technically incomplete. > > OK ... > > > IF an entropy label and ELI (where all traffic associated with the > > MPLS_TP LSP shares a common randomly selected entropy label value, > > which is not stated) > > You mention "IF an entropy label and ELI (where all traffic > associated with the MPLS_TP LSP shares a common randomly selected > entropy label value, which is not stated)". Regarding the "which > is not stated" part of that phrase I can change the following > paragraph: > > OLD: > > MPLS-TP LSP can be carried as client LSP within an MPLS server > LSP if an Entropy Label Indicator (ELI) and entropy label (EL) > is added after the server layer LSP label(s) in the label > stack, just above the MPLS-TP LSP label entry [RFC6790]. > [...] > > NEW: > > MPLS-TP LSP can be carried as client LSP within an MPLS server > LSP if an Entropy Label Indicator (ELI) and Entropy Label (EL) > is added after the server layer LSP label(s) in the label > stack, just above the MPLS-TP LSP label entry [RFC6790]. The > value of EL can be randomly selected at LSP setup time and the > same EL value used for all packets of the MPLS-TP LSP. [...] > > [Dave] That edit works for me. Its in the xml source and will be in the next iteration. > One sentence is added to the end. (and Entropy Label is capitalized). > > > are the only mechanisms of ensuring proper treatment > > Actually link-bundling is mentioned as another mechanism. > > > (with all transit nodes implementing entropy and ELI processing such > > that seeking sources of entropy is capped for such LSPs), > > The requirement to terminate search for additional entropy below > the EL is a requirement of RFC 6790. The intent is to say that > non-compliant midpoint LSR would in this case cause packet order > problems where in MPLS only (no TP carried) use of RFC 6790, those > non-compliant midpoint LSR are tolerable as long as they can get > enough entropy from the traffic to adequately load split. > > [Dave] Given the relative newness of 6790, I'm assuming some statement > to the effect that this solution is not necessarily backwards > compatible with existing deployments needs to be said. OK. Most of the draft-villamizar-mpls-multipath-extn is about fixing the limitation that MPLS-TP LSP need to be identified in signaling and that the ingress needs to know which links can't support MPLS-TP requirements. This text addresses the need to know which links can't support MPLS-TP. MP#4 Where an RSVP-TE control plane is used, it MUST be possible for an ingress LSR which is setting up an MPLS-TP or MPLS LSP to determine at CSPF time whether a link or MPLS PSC LSP within the topology can support the MPLS-TP requirements of the LSP. I'll explicitly mention that legacy LAG and legacy ECMP that do not support ELI and EL are among the "link or MPLS PSC LSP within the topology" that cannot "can support the MPLS-TP requirements of the LSP." Without protocol extensions, the ingress can still know this if color (administrative attributes in RFC 3209) is used to identify these links. Its worth mentioning this, so thanks for bringing it up. So far all I say is: Requirement MP#4 can be supported using administrative attributes. Administrative attributes are defined in [RFC3209]. Some configuration is required to support this. I'll preceed that with: Links or MPLS LSP which traverse LAG or ECMP with adjacent LSR that do not support [RFC6790] cannot support MPLS-TP requirements. This is the reason for including requirement MP#4. The ingress of an MPLS-TP LSP must be able to avoid these links or MPLS LSP. I think this addresses your concern. [btw- sometimes it is better to state what is obvious to some readers than confuse the others readers, so I agree that this is an improvement.] > > and the ingress node (which by some means SHOULD be able to know it > > is a TP LSP as it has layer visibility) > > That is discussed in the following paragraph: > > There is currently no signaling mechanism defined to support > requirement MP#1. In the absense of a signaling extension, > MPLS-TP can be identified through some form of configuration, > such as configuration which provides an MPLS-TP compatible > server layer to all LSP arriving on a specific interface or > originating from a specific set of ingress LSR. Alternately an > MPLS-TP LSP can be created with and Entropy Label Indicator > (ELI) and entropy label (EL) below the MPLS-TP label [RFC6790]. > > Obviously the EL can be added at the MPLS-TP ingress LSR. This > paragraph is considering the case where a set of MPLS-TP LSR are > not EL capable but also do not have multipath enabled, but > multipath is enabled elsewhere (ie: the core where lots of traffic > needs to get aggregated into a smaller number of LSP). The lack > of a signaling extension is noted as a (fixable) limitation. The > fix comes in a later draft (draft-villamizar-mpls-multipath-extn). > > > and the egress node can strip entropy and ELI > > That is a hard requirement of RFC 6790 for an LSR claiming to > support RFC 6790. > > > then a solution exists for proper fate sharing and ordering of a TP > > LSP over MPLS. > > OK ... agreed. > > > It is IMO not quiet eluciated completely. > > You seem to have figured out all of the details. > > If there are additional clarifications that are needed besides the > ones suggested above, please point out what details of the solution > are still not clear in the existing text. > > > If I'm unclear on any of the above, am happy to discuss... > > Thanks. Please let me know if the above clarifications are sufficient > or whether additional clarifications are needed. > > [Dave] I think with the change of ordering constraint to fate sharing > constraint in section 1, the EL "fixed value" addition and some > disclaimer about 6790 support in the MPLS network, I would be happy. > I'm clearer on what you were saying. If the changes above don't adequately address your concerns then please say so. > Best > Dave Cheers, Curtis From david.i.allan@ericsson.com Thu Jan 24 16:47:41 2013 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 EC69721F84B2 for ; Thu, 24 Jan 2013 16:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=1.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 KiaA47a5gbtR for ; Thu, 24 Jan 2013 16:47:39 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6089721F8421 for ; Thu, 24 Jan 2013 16:47:37 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-7e-5101d628314d Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 90.BC.03705.826D1015; Fri, 25 Jan 2013 01:47:37 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 19:47:36 -0500 From: David Allan I To: "curtis@occnc.com" Thread-Topic: MPLS-RT review of draft-villamizar-mpls-multipath-use Thread-Index: AQHN+pRNhjn59v73gkmIPrV6gzHbXZhZNcEA Date: Fri, 25 Jan 2013 00:47:35 +0000 Message-ID: References: Your message of "Wed, 23 Jan 2013 22:43:13 GMT." <201301250038.r0P0cWoZ019764@gateway1.orleans.occnc.com> In-Reply-To: <201301250038.r0P0cWoZ019764@gateway1.orleans.occnc.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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXRPgq7mNcZAg22vWSwOH5jObnFr6UpW ByaPJUt+Mnks/uIXwBTFZZOSmpNZllqkb5fAlfH32nmWgjmtjBW7Dpg3MJ7M6GLk5JAQMJHY 1HqEEcIWk7hwbz0biC0kcIRR4nqPGYS9nFFi62Q+EJtNwEBiz/8vYPUiApoSfydtZu9i5OBg FlCWOHVXBiQsLOAk8W3xbCaIEmeJnqMvocqNJHq23GQGsVkEVCWWfZvEBtLKK+AtsfI0Sxcj F9Cmo4wSjx5MZQGp4RRwlXj89SmYzQh02vdTa8BmMguIS9x6Mp8J4mQBiSV7zjND2KISLx// Y4WwlSWWPNnPAlGvI7Fg9yc2CFtbYtnC12D1vAKCEidnPmGZwCg2C8nYWUhaZiFpmYWkZQEj yypGjtLi1LLcdCPDTYzA+Dgmwea4g3HBJ8tDjNIcLErivKGuFwKEBNITS1KzU1MLUovii0pz UosPMTJxcEo1MC74MbFtQvz2+VbPAvjcNnGKZCuJNrPb+yi/uH9c0a15S1IfK7N8za/5rv+W ld4uVRK1mXrCT+5TlSl/8Evr0I8TLCY2tGxdX567aMXjwgsLD1XV1p74tUnGd1Lv2f1Jc05L MlbV9i+uF+qsNVj3w+RBx3Ozxxw+SR9rLbZE8mTsPl/5Z9LNPiWW4oxEQy3mouJEAHtTCsxd AgAA Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use 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, 25 Jan 2013 00:47:41 -0000 The set of changes you describe in the last couple of emails addresses all = my concerns... Thanks Dave=20 -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com]=20 Sent: Thursday, January 24, 2013 4:39 PM To: David Allan I Cc: curtis@occnc.com; mpls@ietf.org Subject: Re: MPLS-RT review of draft-villamizar-mpls-multipath-use Dave, When explicitly referencing the requirements, there was enough to create a = small subsection (3.1). So now section 3 is: 3. MPLS as a Server Layer for MPLS-TP 3.1. MPLS-TP Forwarding and Server Layer Requirements 3.2. Methods of Supporting MPLS-TP client LSPs over MPLS In section 3.2 I now use the phrase "MPLS-TP forwarding requirements" and refer back to section 3.1 rather than using either the phrase "MPLS-TP = OAM fate-sharing requirements" or the phrase "MPLS-TP packet ordering requi= rements" in section 3.2. I did some rewording and additions to improve clarity and be more specific = in section 3, as requested in general comments by reviewers. I'll send annotated diffs in a little while so that you and other MPLS-RT e= xpert reviewers can make sure all comments (so far) are addressed and the c= hanges are to your liking. Regards, Cuertis In message David Allan I writes: Hi Curtis Thanks for the reply, and yes LM has a strict ordering constraint, while FM= wants fate sharing, I was brain-farting on the PM/LM component of OAM when= reading it and thinking FM which is the usual discussion on this list.... So now I understand the motivation for the way you had phrased the text. No= t spreading an individual TP LSP out across multiple links actually satifie= s both so IMO there is a dual motivation for the requirement. If referring = to the OAM ordering requirement, I'd suggest calling it "the strict packet = ordering requirement that TP Performance monitoring requires", so it cannot= be confused with simply in order delivery of OAM PDUs in isolation; the OA= M PDU's relative position with respect to the interleaved real traffic actu= ally matters. I also have no issue with the digression on capacity allocation determinism= and SLA monitoring vs. actual behavior. Other that that I would observe ac= tual mileage observed by the different modes of operation depends on the ac= tual traffic profile, e.g. large number of small flows vs. small number of = large flows.... Cheers D -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Wednesday, January 23, 2013 2:19 PM To: David Allan I Cc: curtis@occnc.com; mpls@ietf.org; Martin Vigoureux; mpls-chairs@tools.ie= tf.org; Loa Andersson Subject: Re: MPLS-RT review of draft-villamizar-mpls-multipath-use In message David Allan I writes: >=20 > HI Curtis:=20 > =20 > Some snipping to help readability and replies prefixed by [Dave] > =20 > > =20 > If it is unclear to you, then the document is not sufficiently clear=20 > and needs fixing. See below. > =20 > [Dave] Great.... > =20 > > Nit: > > =20 > > Section 1 para 2: Refers to MPLS-TP packet ordering as the constraint.= =20 > > I'm a bit confused by this, any aggregate that shares an ordering=20 > > constraint does not get spread across parallel links while a set of=20 > > traffic COULD be in theory load spread across a set of MPLS-TP paths=20 > > so long as individual ordering constraints were respected. Is this=20 > > text document really discussing midbox spreading out of load that=20 > > respects ordering constraints but would mean MPLS-TP OAM no longer=20 > > fate shared? Should be reworded if so. Clarified otherwise. > =20 > Section 1 paragraph 2 contains: > =20 > RFC 5654 requirement 33 requires the capability to carry a client > MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer > [RFC5654]. This is possible in all cases with one exception. When > an MPLS LSP exceeds the capacity of any single component link it > may be carried by a network using multipath techniques, but may not > be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity > limitation imposed by MPLS-TP OAM packet ordering constraints. > =20 > The sentence in question is: > =20 > When an MPLS LSP exceeds the capacity of any single component link > it may be carried by a network using multipath techniques, but may > not be carried by an MPLS-TP LSP due to the inherent MPLS-TP > capacity limitation imposed by MPLS-TP OAM packet ordering > constraints. > =20 > Perhaps I could clarify this by changing "carried by an MPLS-TP LSP" > to "carried by a single MPLS-TP LSP". > =20 > The "MPLS-TP OAM packet ordering constraints" is the "fate sharing" > which is the reason that MPLS-TP prohibits using ECMP (aka multipath,=20 > though ECMP is only one form of multipath) with MPLS-TP. This is why=20 > an MPLS LSP (client layer) with capacity greater than a component link=20 > cannot be carried over a *single* MPLS-TP LSP. > =20 > Since this is explained in later sections I could make the=20 > substitution suggested above or I could drop the last sentence and=20 > mention that limitation later. > =20 > [Dave] the sentence I had a problem with was "but may not be carried=20 > by an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation=20 > imposed by MPLS-TP OAM packet ordering constraints." The phrase you are objecting to is "packet ordering constraints". Carlos suggested that I reference or quote RFC 5960 which would clear up ex= actly what the dataplane requirements are. If direct LM OAM is supported, then there is a strict packet reordering req= uirement (can't reorder the LM OAM packet relative to payload packets or ac= curacy suffers) so maybe I need to cite RFC 6374 Section 2.9.4 "Equal Cost = Multipath" and Section 4.2.10 "Message Loss and Packet Misorder Conditions"= . > It is not an ordering constraint, it is a fate sharing constraint. It=20 > read fairly strangely to me as to what the problem was you were trying=20 > to expose. IMO the TP requirements are focused on both determinism of=20 > commitment of network resources for network planning & SLA purposes,=20 > and ability to fully and reliably instrument the connectivity. IMO=20 > multipath violates the latter, whether it violates the former would be=20 > a topic of debate unresolvable in the reality of LAG. LAG simply=20 > scoping the domain of uncertainty for OAM purposes to a link, and=20 > requiring extra link OAM and inheritance... This is an aside, but since you brought this up I'll respond. Begin aside. You made two implied assertions. 1) MPLS-TP is more deterministic, 2) MPLS= -TP is necessary to reliably instrument the connectivity. A circuit swtiched (or MPLS-TP) network is more deterministic with respect = to how much capacity is allocated. When the capacity in question is a larg= e aggregate of traffic, the packet switched (or MPLS) network is more deterministic with respect to individual customer exp= erience. For example, if many LSP travel across a core and if one city pai= r is exceeding its expected capactiy but others are slidghtly underutilizin= g their expected capactiy, then in the circuit switched or MPLS-TP network = individual flows for that city pair experience congestion, whereas in a pac= ket switched or MPLS network, capacity is shared and therefore no congestio= n is experienced. In MPLS core networks the SLA traffic is a fraction of traffic and does fin= e with little more than TC marking and diffserv treatment. The determinism you describe may be an issue in metro networks, such as whe= re mobile backhaul is mixed with pedestrian Internet traffic and capacity i= s scarse. Kireeti Kompella and other wrote a paper about two years ago on exactly thi= s topic and it might help if I dug up the reference and included in the doc= ument. The latter point regarding reliably instrumenting the connectivity is valid= . But if the benefit of instrumenting is for a minority of the traffic (SL= A traffic) and the cost is a reduction in network efficiency for the vast m= ajority of traffic (plain old Internet), then there is a substantial increa= se in cost to provide the instrumented service and then it may not be worth= it. This is why MPLS-TP carried over MPLS is of interest. End aside. > [Dave] To make the discussion short, replacing "OAM packet ordering=20 > constraints" with "OAM fate sharing constraints" should be sufficient. In practice the "OAM fate sharing constraints" and "OAM packet ordering con= straints" are almost one in the same where LAG or ECMP are the cause of the= misordering. LM OAM requires strict packet ordering, not just fate sharin= g. I'll add the references to RFC 5960 and RFC 6374 and let those RFCs state t= he requirements. > > Main issue: > > =20 > > Section 3: I think this needs a bit of work, it starts to discuss=20 > > tractable solutions but IMO is technically incomplete. IF an entropy=20 > > label and ELI (where all traffic associated with the MPLS_TP LSP=20 > > shares a common randomly selected entropy label value, which is not > > stated) are the only mechanisms of ensuring proper treatment (with=20 > > all transit nodes implementing entropy and ELI processing such that=20 > > seeking sources of entropy is capped for such LSPs), and the ingress=20 > > node (which by some means SHOULD be able to know it is a TP LSP as=20 > > it has layer visibility) and the egress node can strip entropy and=20 > > ELI then a solution exists for proper fate sharing and ordering of a=20 > > TP LSP over MPLS. It is IMO not quiet eluciated completely. > =20 > Your paragraph above describes the solution, but then says "It is IMO=20 > not quiet eluciated completely." > =20 > [Dave] Well I know you and I know the solution, but someone newer to=20 > the subject would not necessarily be able to infer it from the=20 > document in its current state. OK. Fair enough. > So lets parse your paragraph and see what the draft is missing: > =20 > > Section 3: I think this needs a bit of work, it starts to discuss=20 > > tractable solutions but IMO is technically incomplete. > =20 > OK ... > =20 > > IF an entropy label and ELI (where all traffic associated with the=20 > > MPLS_TP LSP shares a common randomly selected entropy label value,=20 > > which is not stated) > =20 > You mention "IF an entropy label and ELI (where all traffic > associated with the MPLS_TP LSP shares a common randomly selected > entropy label value, which is not stated)". Regarding the "which > is not stated" part of that phrase I can change the following > paragraph: > =20 > OLD: > =20 > MPLS-TP LSP can be carried as client LSP within an MPLS server > LSP if an Entropy Label Indicator (ELI) and entropy label (EL) > is added after the server layer LSP label(s) in the label > stack, just above the MPLS-TP LSP label entry [RFC6790]. > [...] > =20 > NEW: > =20 > MPLS-TP LSP can be carried as client LSP within an MPLS server > LSP if an Entropy Label Indicator (ELI) and Entropy Label (EL) > is added after the server layer LSP label(s) in the label > stack, just above the MPLS-TP LSP label entry [RFC6790]. The > value of EL can be randomly selected at LSP setup time and the > same EL value used for all packets of the MPLS-TP LSP. [...] > =20 > [Dave] That edit works for me. Its in the xml source and will be in the next iteration. > One sentence is added to the end. (and Entropy Label is capitalized)= . > =20 > > are the only mechanisms of ensuring proper treatment > =20 > Actually link-bundling is mentioned as another mechanism. > =20 > > (with all transit nodes implementing entropy and ELI processing such=20 > > that seeking sources of entropy is capped for such LSPs), > =20 > The requirement to terminate search for additional entropy below > the EL is a requirement of RFC 6790. The intent is to say that > non-compliant midpoint LSR would in this case cause packet order > problems where in MPLS only (no TP carried) use of RFC 6790, those > non-compliant midpoint LSR are tolerable as long as they can get > enough entropy from the traffic to adequately load split. > =20 > [Dave] Given the relative newness of 6790, I'm assuming some statement=20 > to the effect that this solution is not necessarily backwards=20 > compatible with existing deployments needs to be said. OK. Most of the draft-villamizar-mpls-multipath-extn is about fixing the l= imitation that MPLS-TP LSP need to be identified in signaling and that the = ingress needs to know which links can't support MPLS-TP requirements. This text addresses the need to know which links can't support MPLS-TP. MP#4 Where an RSVP-TE control plane is used, it MUST be possible for an ingress LSR which is setting up an MPLS-TP or MPLS LSP to determine at CSPF time whether a link or MPLS PSC LSP within the topology can support the MPLS-TP requirements of the LSP. I'll explicitly mention that legacy LAG and legacy ECMP that do not support= ELI and EL are among the "link or MPLS PSC LSP within the topology" that c= annot "can support the MPLS-TP requirements of the LSP." Without protocol = extensions, the ingress can still know this if color (administrative attrib= utes in RFC 3209) is used to identify these links. Its worth mentioning th= is, so thanks for bringing it up. So far all I say is: Requirement MP#4 can be supported using administrative attributes. Administrative attributes are defined in [RFC3209]. Some configuration is required to support this. I'll preceed that with: Links or MPLS LSP which traverse LAG or ECMP with adjacent LSR that do not support [RFC6790] cannot support MPLS-TP requirements. This is the reason for including requirement MP#4. The ingress of an MPLS-TP LSP must be able to avoid these links or MPLS LSP. I think this addresses your concern. [btw- sometimes it is better to state= what is obvious to some readers than confuse the others readers, so I agre= e that this is an improvement.] > > and the ingress node (which by some means SHOULD be able to know it=20 > > is a TP LSP as it has layer visibility) > =20 > That is discussed in the following paragraph: > =20 > There is currently no signaling mechanism defined to support > requirement MP#1. In the absense of a signaling extension, > MPLS-TP can be identified through some form of configuration, > such as configuration which provides an MPLS-TP compatible > server layer to all LSP arriving on a specific interface or > originating from a specific set of ingress LSR. Alternately an > MPLS-TP LSP can be created with and Entropy Label Indicator > (ELI) and entropy label (EL) below the MPLS-TP label [RFC6790]. > =20 > Obviously the EL can be added at the MPLS-TP ingress LSR. This > paragraph is considering the case where a set of MPLS-TP LSR are > not EL capable but also do not have multipath enabled, but > multipath is enabled elsewhere (ie: the core where lots of traffic > needs to get aggregated into a smaller number of LSP). The lack > of a signaling extension is noted as a (fixable) limitation. The > fix comes in a later draft (draft-villamizar-mpls-multipath-extn). > =20 > > and the egress node can strip entropy and ELI > =20 > That is a hard requirement of RFC 6790 for an LSR claiming to > support RFC 6790. > =20 > > then a solution exists for proper fate sharing and ordering of a TP=20 > > LSP over MPLS. > =20 > OK ... agreed. > =20 > > It is IMO not quiet eluciated completely. > =20 > You seem to have figured out all of the details. > =20 > If there are additional clarifications that are needed besides the=20 > ones suggested above, please point out what details of the solution=20 > are still not clear in the existing text. > =20 > > If I'm unclear on any of the above, am happy to discuss... > =20 > Thanks. Please let me know if the above clarifications are sufficient=20 > or whether additional clarifications are needed. > =20 > [Dave] I think with the change of ordering constraint to fate sharing=20 > constraint in section 1, the EL "fixed value" addition and some=20 > disclaimer about 6790 support in the MPLS network, I would be happy.=20 > I'm clearer on what you were saying. If the changes above don't adequately address your concerns then please say= so. > Best > Dave Cheers, Curtis From curtis@occnc.com Thu Jan 24 17:45:11 2013 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 4ED421F0CFC for ; Thu, 24 Jan 2013 17:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 e+FzKQj746VA for ; Thu, 24 Jan 2013 17:45:10 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id A545A1F0CF8 for ; Thu, 24 Jan 2013 17:45:10 -0800 (PST) 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 r0P1hjED020108; Thu, 24 Jan 2013 20:43:45 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301250143.r0P1hjED020108@gateway1.orleans.occnc.com> To: "Carlos Pignataro (cpignata)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 24 Jan 2013 23:27:18 GMT." <95067C434CE250468B77282634C96ED3228E88FE@xmb-aln-x02.cisco.com> Date: Thu, 24 Jan 2013 20:43:45 -0500 Cc: "mpls@ietf.org" , "" , "draft-villamizar-mpls-multipath-use@tools.ietf.org" Subject: [mpls] ref to rtgwg (was Re: MPLS-RT review of draft-villamizar-mpls-multipath-use) 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: Fri, 25 Jan 2013 01:45:11 -0000 In message <95067C434CE250468B77282634C96ED3228E88FE@xmb-aln-x02.cisco.com> "Carlos Pignataro (cpignata)" writes: > > Hi, Curtis, > > On Jan 22, 2013, at 10:40 PM, Curtis Villamizar wrote: [ ... big snip ... ] > >> 4. The concepts of unequal load split or otherwise load balancing > >> proportionally to some ratio in different links/paths are briefly > >> mentioned but could be more explicitly covered. The ECMP definition > >> mentions this (proportionally to capacity), but in that case it > >> would not be "Equal". Similarly, concepts like "fairly evenly > >> distributed" are used in definitions but not explained -- might not > >> be needed perhaps, but what is fair and what is even in different > >> scenarios can be understood differently. > > > > Familiarity with prior work in multipath in core routers would help > > the reader. Unfortunately not much has been published. > > Do you think that an Informative pointer would help? These rtgwg > documents do apply to IP and MPLS. > > > > > Some useful information can be found in draft-ietf-rtgwg-cl-use-cases > > in Appendix B. There is also useful descriptions of expectations > > regarding limiting the frequency of load balancing and the inevitable > > imperfect balancing in that document and the CL documents in RTGWG: > > draft-ietf-rtgwg-cl-{requirements,framework} The documents draft-ietf-rtgwg-cl-{requirements,use-cases,framework} are expected to advance together in RTGWG. This means that cl-requirements whish was done and last called a long time ago and cl-use-cases which is not likely to change and probably could be last called, will both be held up by cl-framework. The cl-framework is in turn held up by documents it references that are in very early stages, or expired, or are needed but don't exist yet. Cleaning up the cl-framework is somewhere on my to-do-list. Given the long time non-advancement of the CL work in RTGWG, I'd rather not reference that work. Rather than reference one of these, I'd rather break out the part of draft-ietf-rtgwg-cl-use-cases that describes existing MPLS multipath usage as a separate document and advance that separately (perhaps in MPLS WG) and reference that since it would describe only the current practices and would be more likely to advance in finite time. Things like unequal load split and dynamic multipath are not critical to this document, so my preference is to either not mention either technique, or very briefly mention it with enough wording in place to convey what the technique is. I think what we have is enough, but I could be convinced otherwise. Curtis From cpignata@cisco.com Thu Jan 24 17:58:46 2013 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 B30DF21F84D7 for ; Thu, 24 Jan 2013 17:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 HJrFRHIxFRev for ; Thu, 24 Jan 2013 17:58:46 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 165C821F84D5 for ; Thu, 24 Jan 2013 17:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3121; q=dns/txt; s=iport; t=1359079126; x=1360288726; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=itiQ1yodWN8lP9zhniJ8VhSyI34zMTa7tWEUrlh6pVg=; b=jfQip6KmETyQz2w/6VshfwsWqMSUS1szt+hjE5B6qVxFZXN3P5apLbP8 YILyPo+JA2N360+FjZZOslL+vzosE1L8II3T77DIz80OcnqpaCiJR4iGP l78MybVBGNjIbK/Q3Ml0bLy8jWMNkFlYXtPS5SmoEupRnDYRZEkpHXJCP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABjmAVGtJXG+/2dsb2JhbABEvkcWc4IeAQEBAwE6OgUQAgEIGAoUEDIlAgQOBQiIDAa+FpAaYQOmVIJ4giQ X-IronPort-AV: E=Sophos;i="4.84,534,1355097600"; d="scan'208";a="167817494" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jan 2013 01:58:45 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0P1wjTp003094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 01:58:45 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 19:58:45 -0600 From: "Carlos Pignataro (cpignata)" To: "" Thread-Topic: ref to rtgwg (was Re: MPLS-RT review of draft-villamizar-mpls-multipath-use) Thread-Index: AQHN+p1x1J1QcjGztECxM2GUBB8SAJhZrluA Date: Fri, 25 Jan 2013 01:58:44 +0000 Message-ID: <95067C434CE250468B77282634C96ED3228E9712@xmb-aln-x02.cisco.com> References: <201301250143.r0P1hjED020108@gateway1.orleans.occnc.com> In-Reply-To: <201301250143.r0P1hjED020108@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.107.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "" , "draft-villamizar-mpls-multipath-use@tools.ietf.org" Subject: Re: [mpls] ref to rtgwg (was Re: MPLS-RT review of draft-villamizar-mpls-multipath-use) 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, 25 Jan 2013 01:58:46 -0000 On Jan 24, 2013, at 8:43 PM, Curtis Villamizar wrote: >=20 > In message <95067C434CE250468B77282634C96ED3228E88FE@xmb-aln-x02.cisco.co= m> > "Carlos Pignataro (cpignata)" writes: >>=20 >> Hi, Curtis, >>=20 >> On Jan 22, 2013, at 10:40 PM, Curtis Villamizar wrote= : >=20 > [ ... big snip ... ] >=20 >>>> 4. The concepts of unequal load split or otherwise load balancing >>>> proportionally to some ratio in different links/paths are briefly >>>> mentioned but could be more explicitly covered. The ECMP definition >>>> mentions this (proportionally to capacity), but in that case it >>>> would not be "Equal". Similarly, concepts like "fairly evenly >>>> distributed" are used in definitions but not explained -- might not >>>> be needed perhaps, but what is fair and what is even in different >>>> scenarios can be understood differently. >>>=20 >>> Familiarity with prior work in multipath in core routers would help >>> the reader. Unfortunately not much has been published. >>=20 >> Do you think that an Informative pointer would help? These rtgwg >> documents do apply to IP and MPLS. >>=20 >>>=20 >>> Some useful information can be found in draft-ietf-rtgwg-cl-use-cases >>> in Appendix B. There is also useful descriptions of expectations >>> regarding limiting the frequency of load balancing and the inevitable >>> imperfect balancing in that document and the CL documents in RTGWG: >>> draft-ietf-rtgwg-cl-{requirements,framework} >=20 >=20 > The documents draft-ietf-rtgwg-cl-{requirements,use-cases,framework} > are expected to advance together in RTGWG. This means that > cl-requirements whish was done and last called a long time ago and > cl-use-cases which is not likely to change and probably could be last > called, will both be held up by cl-framework. >=20 > The cl-framework is in turn held up by documents it references that > are in very early stages, or expired, or are needed but don't exist > yet. Cleaning up the cl-framework is somewhere on my to-do-list. >=20 > Given the long time non-advancement of the CL work in RTGWG, I'd > rather not reference that work. >=20 > Rather than reference one of these, I'd rather break out the part of > draft-ietf-rtgwg-cl-use-cases that describes existing MPLS multipath > usage as a separate document and advance that separately (perhaps in > MPLS WG) and reference that since it would describe only the current > practices and would be more likely to advance in finite time. >=20 > Things like unequal load split and dynamic multipath are not critical > to this document, so my preference is to either not mention either > technique, or very briefly mention it with enough wording in place to > convey what the technique is. I think what we have is enough, but I > could be convinced otherwise. That approach seems OK. Frankly my only concern is to end up with multiple = definitions of the same terms and concepts in different documents, that inv= ariably end up desynchronized.=20 Thanks, -- Carlos. >=20 > Curtis >=20 From curtis@occnc.com Thu Jan 24 18:09:58 2013 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 A45F321F8555 for ; Thu, 24 Jan 2013 18:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 bdFXVII0QsW7 for ; Thu, 24 Jan 2013 18:09:58 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2FC21F854D for ; Thu, 24 Jan 2013 18:09:57 -0800 (PST) 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 r0P28e2c020271; Thu, 24 Jan 2013 21:08:40 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301250208.r0P28e2c020271@gateway1.orleans.occnc.com> To: "Carlos Pignataro (cpignata)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 24 Jan 2013 23:27:26 GMT." <95067C434CE250468B77282634C96ED3228E8918@xmb-aln-x02.cisco.com> Date: Thu, 24 Jan 2013 21:08:40 -0500 Cc: "mpls@ietf.org" Subject: Re: [mpls] minor clarification (was Re: MPLS-RT review of draft-villamizar-mpls-multipath-use) 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: Fri, 25 Jan 2013 02:09:58 -0000 In message <95067C434CE250468B77282634C96ED3228E8918@xmb-aln-x02.cisco.com> "Carlos Pignataro (cpignata)" writes: > Curtis, > > On Jan 24, 2013, at 5:41 PM, Curtis Villamizar wrote: > > > > > Carlos, > > > > Looking over prior email, a minor clarification came to mind. > > > > In message <201301230340.r0N3eIO6069247@gateway1.orleans.occnc.com> > > Curtis Villamizar writes: > >>> > >> In message <95067C434CE250468B77282634C96ED3228D4D01@xmb-aln-x02.cisco.com> > >> "Carlos Pignataro (cpignata)" writes: > >>> > > > > [ ... big snip ... ] > > > >>> 4. The concepts of unequal load split or otherwise load balancing > >>> proportionally to some ratio in different links/paths are briefly > >>> mentioned but could be more explicitly covered. The ECMP definition > >>> mentions this (proportionally to capacity), but in that case it > >>> would not be "Equal". Similarly, concepts like "fairly evenly > >>> distributed" are used in definitions but not explained -- might not > >>> be needed perhaps, but what is fair and what is even in different > >>> scenarios can be understood differently. > >> > >> Familiarity with prior work in multipath in core routers would help > >> the reader. Unfortunately not much has been published. > >> > >> Some useful information can be found in draft-ietf-rtgwg-cl-use-cases > >> in Appendix B. There is also useful descriptions of expectations > >> regarding limiting the frequency of load balancing and the inevitable > >> imperfect balancing in that document and the CL documents in RTGWG: > >> draft-ietf-rtgwg-cl-{requirements,framework} > > > > The "equal" in "ECMP" applies to equal cost. So if a 10GbE server > > layer LSP and 100GbE server layer LSP (ie: Packet Switch Capable LSP > > or PSC LSP) have equal administrative costs, then it still makes sense > > to split the load unequally. The same applies to ECMP when all of the > > links have the same next-hop, though I'm not sure who if anyone still > > supports that. > > > > In any case the term "multipath" is used in this document for a number > > or reasons. One reason is to avoid any confusion about limitations of > > some ECMP implementations or preconceived notions of ECMP limitations, > > such as any notion that the load must be split evenly. Another reason > > is to include Ethernet Link Aggregation, Link Bundling, as well as > > ECMP, but exclude inverse-mux, hence the definitions (in Section 2): > > > > Multipath > > I should have said this in my review: I like the approach of using a > new term, "Multipath", for this, and abstract from the implications of > "ECMP" and group various techniques. I think it is really > good. Normalizing definitions with draft-ietf-rtgwg-cl-* would be > ideal as well. > > Thanks, > > -- Carlos. AFAIK the definitions in the RTGWG CL work and the definition here are not identical but are consistent. In cl-requirements "composite link" is redefined slightly from the ITU-T definition to exclude inverse-multiplexing, but then a whole lot of requrements are piled on that have nothing to do with ITU-T CL minus inverse-mux. Existing practice is defined in cl-use-cases as "classic multipath". The distinction in the CL work between RTGWG CL (something new) and "classic multipath". The latter (classic multipath) lacks support for new capabilities - for example: explicit support for heterogeneous component links - groups of component links having different metrics for things such as delay and jitter. So "multipath" here is the same as "classic multipath" in the CL documents. The definition here is more precise though and it wouldn't hurt to move that to a common document. This document does not refer to RTGWG definition of "composite link", only the ITU-T definition. I personally don't think the RTGWG documents should have used the term "composite link", given that the ITU-T already had a definition for CL but instead used a different term and then piled the new requirements on that new term. If anything, the definitions in the RTGWG CL work need to be improved, but that is a topic for the rtgwg mailing list. Curtis > > The term multipath includes all techniques in which > > > > 1. Traffic can take more than one path from one node to a > > destination. > > > > 2. Individual packets take one path only. Packets are not > > subdivided and reassembled at the receiving end. > > > > 3. Packets are not resequenced at the receiving end. > > > > 4. The paths may be: > > > > a. parallel links between two nodes, or > > > > b. may be specific paths across a network to a destination > > node, or > > > > c. may be links or paths to an intermediate node used to > > reach a common destination. > > > > [...] > > > > Composite Link > > The term Composite Link had been a registered trademark of > > Avici Systems, but was abandoned in 2007. The term composite > > link is now defined by the ITU in [ITU-T.G.800]. The ITU > > definition includes multipath as defined here, plus inverse > > multiplexing which is explicitly excluded from the definition > > of multipath. > > > > Regards, > > > > Curtis From xuxiaohu@huawei.com Thu Jan 24 18:24:15 2013 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 5B1EC1F0CE4 for ; Thu, 24 Jan 2013 18:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.366 X-Spam-Level: X-Spam-Status: No, score=0.366 tagged_above=-999 required=5 tests=[AWL=2.423, BAYES_00=-2.599, CN_BODY_35=0.339, 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 hfCFIleL1y6t for ; Thu, 24 Jan 2013 18:24:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCFD1F0C3E for ; Thu, 24 Jan 2013 18:24:10 -0800 (PST) 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 ANV71749; Fri, 25 Jan 2013 02:24:09 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 25 Jan 2013 02:23:48 +0000 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 25 Jan 2013 10:24:07 +0800 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.166]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.007; Fri, 25 Jan 2013 10:24:03 +0800 From: Xuxiaohu To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-ldp-multi-topology Thread-Index: AQHN977aw6CPqIBAAEOm7g6KMa6+T5hZTcmQ Date: Fri, 25 Jan 2013 02:24:03 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07597FA0@szxeml525-mbx.china.huawei.com> References: <50FD12DD.8050709@pi.nu> In-Reply-To: <50FD12DD.8050709@pi.nu> 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-multi-topology@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-multi-topology 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, 25 Jan 2013 02:24:15 -0000 SGksDQoNCkl0J3MgYSB3ZWxsLXdyaXR0ZW4gYW5kIHVzZWZ1bCBkb2N1bWVudCwgYW5kIEkgc3Vw cG9ydCBpdC4gSnVzdCBvbmUgbWluZXIgY29tbWVudCBvbiBzZWN0aW9uIDMuNzogIFNpbmNlIHVz aW5nIGRpZmZlcmVudCBsYWJlbCBzcGFjZXMgZm9yIGRpZmZlcmVudCB0b3BvbG9naWVzIHdvdWxk IGltcGx5IHNpZ25pZmljYW50IGNoYW5nZXMgdG8gdGhlIGRhdGEgcGxhbmUgd2hpbGUgaXQgc2Vl bXMgdGhhdCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoaXMgZG9jdW1lbnQgaW50ZW5kcyB0byBr ZWVwIGJhY2t3YXJkcyBjb21wYXRpYmxlIHRvIHRoZSBleGlzdGluZyBkYXRhIHBsYW5lLCBpdCdk IGJldHRlciB0byBjbGVhciB0aGUgY29uZnVzaW9uIGJ5IHJlbW92aW5nIHRoZSBkZXNjcmlwdGlv biBvZiBwZXItdG9wb2xvZ3kgbGFiZWwgc3BhY2UuDQoNCg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqDQozLjcuICBMRFAgU2Vzc2lvbnMNCg0KICAgSWYgYSBz aW5nbGUgZ2xvYmFsIGxhYmVsIHNwYWNlIGlzIHN1cHBvcnRlZCwgdGhlcmUgd2lsbCBiZSBhbiBM RFANCiAgIHNlc3Npb24gc3VwcG9ydGVkIGZvciBlYWNoIHBhaXIgb2YgcGVlcnMsIHJlZ2FyZGxl c3Mgb2YgdGhlIG51bWJlciBvZg0KICAgTVRzIHN1cHBvcnRlZCBiZXR3ZWVuIHBlZXJzLiAgSWYg dGhlcmUgYXJlIGRpZmZlcmVudCBsYWJlbCBzcGFjZXMNCiAgIHN1cHBvcnRlZCBmb3IgZGlmZmVy ZW50IHRvcG9sb2dpZXMsIHdoaWNoIG1lYW5zIHRoYXQgbGFiZWwgc3BhY2VzDQogICBvdmVybGFw IHdpdGggZWFjaCBvdGhlciBmb3IgZGlmZmVyZW50IE1UcywgdGhlbiBpdCBpcyByZWNvbW1lbmRl ZCB0bw0KICAgZXN0YWJsaXNoIG11bHRpcGxlIHNlc3Npb25zIGZvciBtdWx0aXBsZSB0b3BvbG9n aWVzIGJldHdlZW4gdGhlc2UgdHdvDQogICBwZWVycy4gIEluIHRoaXMgY2FzZSwgbXVsdGlwbGUg TFNSLUlEcyB3aWxsIG5lZWQgdG8gYmUgYWxsb2NhdGVkIHNvDQogICB0aGF0IGVhY2ggbXVsdGlw bGUgdG9wb2xvZ3kgY2FuIGhhdmUgaXRzIG93biBsYWJlbCBzcGFjZSBJRC4NCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFv aHUgDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbXBscy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExvYQ0KPiBBbmRlcnNzb24N Cj4gt6LLzcqxvOQ6IDIwMTPE6jHUwjIxyNUgMTg6MDUNCj4gytW8/sjLOiBtcGxzQGlldGYub3Jn DQo+ILOty806IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOw0KPiBkcmFmdC1pZXRmLW1wbHMt bGRwLW11bHRpLXRvcG9sb2d5QHRvb2xzLmlldGYub3JnDQo+INb3zOI6IFttcGxzXSB3b3JraW5n IGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtbGRwLW11bHRpLXRvcG9sb2d5DQo+ IA0KPiBXb3JraW5nIEdyb3VwLA0KPiANCj4gdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIFdv cmtpbmcgR3JvdXAgbGFzdCBjYWxsIG9uDQo+IGRyYWZ0LWlldGYtbXBscy1sZHAtbXVsdGktdG9w b2xvZ3kuDQo+IA0KPiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtp bmcgZ3JvdXANCj4gbWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnKS4NCj4gDQo+IFBsZWFzZSBz ZW5kIGJvdGggdGVjaG5pY2FsIGNvbW1lbnRzLCBhbmQgaWYgeW91IGFyZSBoYXBweQ0KPiB3aXRo IHRoZSBkb2N1bWVudCBhcyBpcyBhbHNvIGluZGljYXRpb25zIG9mIHN1cHBvcnQuDQo+IA0KPiBU aGVyZSBhcmUgSVBSIGNsYWltcyBhZ2FpbnN0IHRoaXMgZHJhZnQsIElQUiBkaXNjbG9zdXJlcyAj MTcwNw0KPiBhbmQgIzE4NzUuDQo+IA0KPiBBbGwgdGhlIGNvLWF1dGhvcnMgaGFzIHN0YXRlZCB0 aGF0IHRoZXkgYXJlIG5vdCBhd2FyZQ0KPiBvZiBhbnkgSVBScyBvdGhlciB0aGFuIHRoZSBvbmVz IHRoYXQgaGFzIGJlZW4gZGlzY2xvc2VkLg0KPiANCj4gVGhpcyB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCB3aWxsIGVuZCBvbiBGZWJydWFyeSAyLCAyMDEzLg0KPiANCj4gL0xvYQ0KPiBmb3IgdGhl IHdnIGNvLWNoYWlycw0KPiAtLQ0KPiANCj4gDQo+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAg ICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+IE1QTFMgRXhwZXJ0ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+IEh1YXdlaSBUZWNobm9s b2dpZXMgKGNvbnN1bHQpICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcg bGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0K From curtis@occnc.com Thu Jan 24 19:02:27 2013 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 243FC1F0CF6 for ; Thu, 24 Jan 2013 19:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.862 X-Spam-Level: * X-Spam-Status: No, score=1.862 tagged_above=-999 required=5 tests=[AWL=-2.357, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_TOOL=2.3, 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 1oOEeQHI5n8x for ; Thu, 24 Jan 2013 19:02:25 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 674451F0CE4 for ; Thu, 24 Jan 2013 19:02:24 -0800 (PST) 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 r0P30uxK020604; Thu, 24 Jan 2013 22:00:56 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301250300.r0P30uxK020604@gateway1.orleans.occnc.com> To: "Carlos Pignataro" , David Allan I , Mach Chen , Markus Jork From: Curtis Villamizar MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <20340.1359082723.0@harbor1.ipv6.occnc.com> Date: Thu, 24 Jan 2013 22:00:56 -0500 Cc: mpls@ietf.org Subject: [mpls] diffs draft-villamizar-mpls-multipath 00 to 01-preview1 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: Fri, 25 Jan 2013 03:02:27 -0000 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20340.1359082723.1@harbor1.ipv6.occnc.com> Carlos, Dave, Mach, Markus, Per request from Loa, I'm not submitting a new draft until the MPLS-RT review is declared finished by the WG chairs. However, attached are the XML diffs in case you would like to look over the changes so far. They are annotated diffs with line numbers on the diffs. The XML diffs are hard to read but the output of rfcdiff on the text version was not much better. > The set of changes you describe in the last couple of emails addresses > all my concerns... > > Thanks > Dave btw- I think I may have worn out Dave. I changed the subject so that actually looking through the diffs could be considered above and beyond the MPLS-RT review. Curtis ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="mpls-multipath-use-diff-00-to-01-preview1-pr.txt" Content-ID: <20340.1359082723.2@harbor1.ipv6.occnc.com> 1 Index: draft-villamizar-mpls-multipath-use.xml 2 =================================================================== 3 --- draft-villamizar-mpls-multipath-use.xml (revision 2657) 4 +++ draft-villamizar-mpls-multipath-use.xml (working copy) 5 @@ -5,14 +5,17 @@ Changed the entity definitions for references. See references below at lines 565-591. (Deleted the not-very-useful and long lines 6-24 from the diff output above). 25 @@ -30,7 +33,7 @@ 26 27 28 30 + docName="draft-villamizar-mpls-multipath-use-01-preview1"> 31 32 33 Changed document name 00 to 01-preview1. 34 @@ -68,18 +71,20 @@ 35 over many types of multipath implementations. 36 </t> 37 <t> 38 - Using MPLS Entropy label, MPLS can LSP can be carried over 39 + Using MPLS Entropy label, MPLS LSPs can be carried over 40 multipath links while also providing a fully MPLS-TP compliant 41 - server layer for MPLS-TP LSP. This document describes the 42 + server layer for MPLS-TP LSPs. This document describes the 43 means of supporting MPLS as a server layer for MPLS-TP. The 44 - use of MPLS-TP LSP as a server layer for MPLS LSP is also 45 + use of MPLS-TP LSPs as a server layer for MPLS LSPs is also 46 discussed. 47 </t> 48 </abstract> 49 </front> LSP to LSPs (requested by Carlos). 50 51 <middle> 52 + 53 <section title="Introduction"> 54 + 55 <t> 56 Today the requirement to handle large aggregations of traffic, 57 can be handled by a number of techniques which we will 58 @@ -90,9 +95,9 @@ 59 aggregation techniques some of which may be vendor specific. 60 Multipath applied to diverse paths rather than parallel links 61 includes Equal Cost MultiPath (ECMP) as applied to OSPF, ISIS, 62 - or BGP, and equal cost LSP. Some vendors support load split 63 - across equal cost MPLS LSP where the load is split 64 - proportionally to the reserved bandwidth of the set of LSP. 65 + or BGP, and equal cost LSPs. Some vendors support load split 66 + across equal cost MPLS LSPs where the load is split 67 + proportionally to the reserved bandwidth of the set of LSPs. 68 </t> 69 <t> 70 RFC 5654 requirement 33 requires the capability to carry a LSP to LSPs (requested by Carlos). 71 @@ -101,8 +106,10 @@ 72 cases with one exception. When an MPLS LSP exceeds the 73 capacity of any single component link it may be carried by a 74 network using multipath techniques, but may not be carried by 75 - an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation 76 - imposed by MPLS-TP OAM packet ordering constraints. 77 + a single MPLS-TP LSP due to the inherent MPLS-TP capacity 78 + limitation imposed by MPLS-TP OAM fate sharing constraints and 79 + MPLS-TP LM OAM packet ordering constraints (see 80 + <xref target="sect.tp-requirements" />). 81 </t> 82 <t> 83 The term composite link is more general than terms such as an MPLS-TP LSP -> a single MPLS-TP LSP. MPLS-TP OAM packet ordering constraints -> a single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP OAM fate sharing constraints and MPLS-TP LM OAM packet ordering constraints (see <xref target="sect.tp-requirements" />). Requested by Dave - sort of. 84 @@ -116,6 +123,7 @@ 85 </section> 86 87 <section anchor="sect.def" title="Definitions"> 88 + 89 <t><list style="hanging" hangIndent="4"> 90 <t hangText="Multipath"><vspace blankLines="0" /> 91 The term multipath includes all techniques in which 92 @@ -157,7 +165,7 @@ 93 split across all members of the bundle. There is no 94 signaling defined which allows a per LSP preference 95 regarding load split, therefore whether to load split is 96 - generally configured per bundle and applied to all LSP 97 + generally configured per bundle and applied to all LSPs 98 across the bundle. 99 </t> 100 <t hangText="Link Aggregation"><vspace blankLines="0" /> LSP to LSPs (requested by Carlos). 101 @@ -243,73 +251,250 @@ 102 make use of keywords such as MUST and SHOULD as described in 103 <xref target="RFC2119" />. 104 </t> 105 + 106 </section> 107 108 <section anchor="sect.mpls-server-layer" 109 title="MPLS as a Server Layer for MPLS-TP"> 110 + 111 <t> 112 - MPLS LSP may be used as a server layer for MPLS-TP LSP as long 113 - as all MPLS-TP requirements are met, including the requirement 114 - that packets within an MPLS-TP LSP are not reordered, 115 - including both payload and OAM packets. 116 + An MPLS LSP may be used as a server layer for MPLS-TP LSPs as 117 + long as all MPLS-TP requirements are met. 118 + <xref target="sect.tp-requirements" /> 119 + reviews the basis for requirements of a server layer that 120 + supports MPLS-TP as a client layer. Key requirements include 121 + OAM "fate-sharing" the the requirement that packets within an 122 + MPLS-TP LSP are not reordered, including both payload and OAM 123 + packets. 124 + <xref target="sect.tp-over-mpls-soln" /> 125 + discusses implied requirements where MPLS is the server layer 126 + for MPLS-TP client LSPs, and describes a set of solutions using 127 + existing MPLS mechanisms. 128 + </t> 129 + Changed the openning paragraph to this section to reflect the break up into subsections 3.1 and 3.2. This also satisfies Dave's preference for not referring to any MPLS-TP packet ordering requirement without qualifying where those requirements come from. The following section is new and is in response to suggestions by Carlos and Dave to reference the base documents that give requirements and to be precise about what the MPLS-TP forwarding and server layer requirements are. 130 + <section anchor="sect.tp-requirements" 131 + title="MPLS-TP Forwarding and Server Layer Requirements"> 132 + 133 + <t> 134 + <!-- ref to RFC5960 suggested by Carlos --> 135 + <xref target="RFC5960" /> 136 + defines the date plane requirements for MPLS-TP. Two very 137 + relevant paragraphs in "Section 3.1.1 LSP Packet Encapsulation 138 + and Forwarding" are the following. 139 + <list style="hanging" hangIndent="4"> 140 + <t hangText="RFC5960, Section 3.1.1, Paragraph 3"> 141 + <vspace blankLines="0" /> 142 + Except for transient packet reordering that may occur, for 143 + example, during fault conditions, packets are delivered in 144 + order on L-LSPs, and on E-LSPs within a specific ordered 145 + aggregate. 146 + </t> 147 + <t hangText="RFC5960, Section 3.1.1, Paragraph 6"> 148 + <vspace blankLines="0" /> 149 + Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be 150 + performed on an MPLS-TP LSP. MPLS-TP LSPs as defined in 151 + this document MAY operate over a server layer that 152 + supports load-balancing, but this load-balancing MUST 153 + operate in such a manner that it is transparent to 154 + MPLS-TP. This does not preclude the future definition of 155 + new MPLS-TP LSP types that have different requirements 156 + regarding the use of ECMP in the server layer. 157 + </t> 158 + </list> 159 </t> 160 <t> 161 - Supporting MPLS-TP LSP overa fully MPLS-TP conformant MPLS LSP 162 - server layer where the MPLS LSP are making use of multipath, 163 - requires special treatment of the MPLS-TP LSP such that those 164 - LSP only are not subject to the multipath load slitting. This 165 - implies the following brief set of requirements. 166 - <list counter="mp" hangIndent="4" style="format MP#%d"> 167 + <xref target="RFC5960" /> 168 + paragraph 3 requires that packets within a specific ordered 169 + aggregate be delivered in order. This same requirement 170 + is already specified by Differentiated Services 171 + <xref target="RFC2475" />. 172 + <xref target="RFC5960" /> 173 + paragraph 6 explicitly allows a server layer to use ECMP 174 + provided that it is transparent to the MPLS-TP client layer. 175 + </t> 176 + <t> 177 + <!-- ref to RFC6371 inspired by conversation with Dave Allen --> 178 + <xref target="RFC6371" /> 179 + adds a requirement for data traffic and OAM traffic 180 + "fate-sharing". The following paragraph in "Section 1 181 + Introduction" summarizes this requirement. 182 + <list style="hanging" hangIndent="4"> 183 + <t hangText="RFC6371, Section 1, Paragraph 7"> 184 + <vspace blankLines="0" /> 185 + OAM packets that instrument a particular direction of a 186 + transport path are subject to the same forwarding 187 + treatment (i.e., fate-share) as the user data packets and 188 + in some cases, where Explicitly TC-encoded-PSC LSPs 189 + (E-LSPs) are employed, may be required to have common 190 + per-hop behavior (PHB) Scheduling Class (PSC) End-to-End 191 + (E2E) with the class of traffic monitored. In case of 192 + Label-Only-Inferred-PSC LSP (L-LSP), only one class of 193 + traffic needs to be monitored, and therefore the OAM 194 + packets have common PSC with the monitored traffic class. 195 + </t> 196 + </list> 197 + </t> 198 <t> 199 - It MUST be possible to identify MPLS-TP LSP. 200 + <xref target="RFC6371" /> 201 + does not prohibit multilink techniques in "Section 4.6 202 + Fate-Sharing Considerations for Multilink", where multilink is 203 + defined as Ethernet Link Aggregation and the use of Link 204 + Bundling for MPLS, but does declare that such a network would 205 + be only partially MPLS-TP compliant. The characteristic that 206 + is to be avoided is contained in the following sentence in 207 + this section. 208 + <list style="hanging" hangIndent="4"> 209 + <t hangText="RFC6371, Section 4.6, Paragraph 1, last sentence"> 210 + <vspace blankLines="0" /> 211 + These techniques frequently share the characteristic that 212 + an LSP may be spread over a set of component links and 213 + therefore be reordered, but no flow within the LSP is 214 + reordered (except when very infrequent and minimally 215 + disruptive load rebalancing occurs). 216 </t> 217 + </list> 218 + A declaration that implies that Link Bundling for MPLS yields 219 + a partially MPLS-TP compliant network, is perhaps overstated 220 + since only the Link Bundling all-ones component link has this 221 + characteristic. 222 + </t> 223 + <t> 224 + <!-- ref to RFC6374 from conversation with Dave Allen --> 225 + <xref target="RFC6374" /> 226 + defines a direct Loss Measurement (LM) where LM OAM packets 227 + cannot be reordered with respect to payload packets. This 228 + will require that payload packets themselves not be reordered. 229 + The following paragraph in "Section 2.9.4 Equal Cost 230 + Multipath" gives the reason for this restriction. 231 + <list style="hanging" hangIndent="4"> 232 + <t hangText="RFC6374, Section 2.9.4, Paragraph 2"> 233 + <vspace blankLines="0" /> 234 + The effects of ECMP on loss measurement will depend on the 235 + LM mode. In the case of direct LM, the measurement will 236 + account for any packets lost between the sender and the 237 + receiver, regardless of how many paths exist between them. 238 + However, the presence of ECMP increases the likelihood of 239 + misordering both of LM messages relative to data packets 240 + and of the LM messages themselves. Such misorderings tend 241 + to create unmeasurable intervals and thus degrade the 242 + accuracy of loss measurement. The effects of ECMP are 243 + similar for inferred LM, with the additional caveat that, 244 + unless the test packets are specially constructed so as to 245 + probe all available paths, the loss characteristics of one 246 + or more of the alternate paths cannot be accounted for. 247 + </t> 248 + </list> 249 + </t> 250 + 251 + </section> 252 + End of new subsection. It would help if reviewers took a look at the above text. 253 + <section anchor="sect.tp-over-mpls-soln" 254 + title="Methods of Supporting MPLS-TP client LSPs over MPLS"> 255 + 256 + <t> 257 + Supporting MPLS-TP LSPs over a fully MPLS-TP conformant MPLS 258 + LSP server layer where the MPLS LSPs are making use of 259 + multipath, requires special treatment of the MPLS-TP LSPs 260 + such that those LSPs meet MPLS-TP forwarding requirements 261 + (see <xref target="sect.tp-requirements" />). This implies 262 + the following brief set of requirements. 263 + <list counter="mp" hangIndent="4" style="format MP#%d"> 264 <t> 265 - It SHOULD be possible to completely exclude MPLS-TP LSP 266 - from the multipath hash and load split. 267 + It MUST be possible for a midpoint MPLS-TP LSR which is 268 + serving as ingress to a server layer MPLS LSP to 269 + identify MPLS-TP LSPs, so that MPLS-TP forwarding 270 + requirements can be applied, or to otherwise accommodate 271 + the MPLS-TP forwarding requirements. 272 + </t> 273 + <t> 274 + It SHOULD be possible to completely exclude MPLS-TP LSPs 275 + from the multipath hash and load split. If the selected 276 + component link no longer meets requirements, an LSP is 277 + considered down which may trigger protection and/or may 278 + require that the ingress LSR select a new path and 279 + signal a new LSP. 280 </t> For those that can't read the XML, the above are MP#1 and MP#2. There was enough rewording here and disconnect from the prior paragraph that diff saw this as a wholesale delete of the prior stuff and an addition here. The changes are as we discussed. 281 <t> 282 - It SHOULD be possible to insure that an MPLS-TP LSP will 283 + It SHOULD be possible to insure that MPLS-TP LSPs will 284 not be moved to another component link as a result of a 285 - composite link load rebalancing operation. 286 + composite link load rebalancing operation. If the 287 + selected component link no longer meets requirements, 288 + another component link may be selected, however a change 289 + in path should not occur solely for load balancing. 290 </t> The above XML is MP#3, reworded and clarified as discussed. 291 <t> 292 Where an RSVP-TE control plane is used, it MUST be 293 - possible for an ingress LSR which is setting up an MPLS-TP 294 - or MPLS LSP to determine at CSPF time whether a link or 295 - MPLS PSC LSP within the topology can support the MPLS-TP 296 - requirements of the LSP. 297 + possible for an ingress LSR which is setting up an 298 + MPLS-TP or an MPLS LSP to determine at path selection 299 + time whether a link or Forwarding Adjacency (FA, see 300 + <xref target="RFC4206" />) within the topology can 301 + support the MPLS-TP requirements of the LSP. 302 </t> The above XML is MP#4. It was OK as is, except it referred to PSC LSP when it probably should have referred to the FA, since that is what the ingress LSR sees when making a path selection. 303 </list> 304 </t> 305 <t> 306 + <!-- inspired by requests to make #1 more clear --> 307 + The reason for requirement MP#1 may not be obvious. A 308 + MPLS-TP LSP may be aggregated along with other client LSP by 309 + a midpoint LSR into a very large MPLS server layer LSP, as 310 + would be the case in a core node to core node MPLS LSP 311 + between major cities. In this case the ingress of the MPLS 312 + LSP cannot through any existing signaling mechanism 313 + determine which client LSP contained within it as MPLS-TP or 314 + not MPLS-TP. For those client LSP that are MPLS-TP LSP, a 315 + single EL value must be chosen. For those client LSP that 316 + are MPLS LSP, per packet entropy below the top label must, 317 + for practical reasons, be used to determine the entropy 318 + label value. Requirement MP#1 simply states that there must 319 + be a means to make this decision. 320 + </t> The comment says it all. I think Dave requested the loudest on this. 321 + <t> 322 There is currently no signaling mechanism defined to support 323 - requirement MP#1. In the absense of a signaling extension, 324 - MPLS-TP can be identified through some form of configuration, 325 - such as configuration which provides an MPLS-TP compatible 326 - server layer to all LSP arriving on a specific interface or 327 - originating from a specific set of ingress LSR. Alternately 328 - an MPLS-TP LSP can be created with and Entropy Label Indicator 329 - (ELI) and entropy label (EL) below the MPLS-TP label 330 - <xref target="I-D.ietf-mpls-entropy-label" />. 331 - </t> 332 - <t> 333 - Some hardware which exists today can support requirement MP#2. 334 - Signaling in the absense of MPLS Entropy Label can make use of 335 - link bundling with a specific component for MPLS-TP LSP and 336 - link bundling with the all-zeros component for MPLS LSP. This 337 - prevents MPLS-TP LSP from being carried within MPLS LSP but 338 - does allow the co-existance of MPLS-TP and very large MPLS 339 - LSP. 340 - </t> 341 - <t> 342 - MPLS-TP LSP can be carried as client LSP within an MPLS server 343 - LSP if an Entropy Label Indicator (ELI) and entropy label (EL) 344 - is added after the server layer LSP label(s) in the label 345 - stack, just above the MPLS-TP LSP label entry 346 - <xref target="I-D.ietf-mpls-entropy-label" />. This allows 347 - MPLS-TP LSP to be carried as client LSP within MPLS LSP and 348 - satisfies requirement MP#2 but requires that MPLS LSR be able 349 - to identify MPLS-TP LSP (requirement MP#1). 350 + requirement MP#1, though that does not preclude a new 351 + extension being defined later. In the absense of a 352 + signaling extension, MPLS-TP can be identified through some 353 + form of configuration, such as configuration which provides 354 + an MPLS-TP compatible server layer to all LSP arriving on a 355 + specific interface or originating from a specific set of 356 + ingress LSR. 357 + </t> 358 + <t> 359 + <!-- separate paragraph inspired by comment from Mach --> 360 + Alternately, the need for requirement MP#1 can be eliminated 361 + if evey MPLS-TP LSP can be created by the MPLS-TP ingress 362 + makes use of an Entropy Label Indicator (ELI) and Entropy 363 + Label (EL) below the MPLS-TP label 364 + <xref target="RFC6790" />. 365 + This would require that all MPLS-TP LSR in a deployment 366 + support Entropy Label, which may render it impractical in 367 + many deployments. 368 + </t> 369 + <!-- 370 + The text below was edited to make it more clear. 371 + In some cases some just plain wrong statements about 372 + satisfying MP#2 and MP#3 had to be corrected. 373 + --> 374 + <t> 375 + Some hardware which exists today can support requirement 376 + MP#2. Signaling in the absense of MPLS Entropy Label can 377 + make use of link bundling with the path pinned to a specific 378 + component for MPLS-TP LSP and link bundling using the 379 + all-ones component for MPLS LSP. This prevents MPLS-TP LSP 380 + from being carried within MPLS LSP but does allow the 381 + co-existance of MPLS-TP and very large MPLS LSP. 382 + </t> 383 + <t> 384 + MPLS-TP LSPs can be carried as client LSPs within an MPLS 385 + server LSP if an Entropy Label Indicator (ELI) and Entropy 386 + Label (EL) is added after the server layer LSP label(s) in 387 + the label stack, just above the MPLS-TP LSP label entry 388 + <xref target="RFC6790" />. The value of EL can be randomly 389 + selected at the client MPLS-TP LSP setup time and the same 390 + EL value used for all packets of that MPLS-TP LSP. This 391 + allows MPLS-TP LSP to be carried as client LSP within MPLS 392 + LSP and satisfies MPLS-TP forwarding requirements but 393 + requires that MPLS LSR be able to identify MPLS-TP LSP 394 + (requirement MP#1). 395 </t> 396 <t> 397 MPLS-TP traffic can be protected from an degraded performance The combination of change in indent (and paragraph reformat) plus changes to the text itself convinced diff that this changed a lot, even though the changes were not quite so dramatic. If its any consolation, rfcdiff lost context here too. 398 @@ -323,24 +508,65 @@ 399 suffer as long as there is a minority of MPLS-TP traffic. 400 </t> 401 <t> 402 - If MPLS-TP LSP are carried within MPLS LSP and ELI and EL are 403 - used, requirement MP#2 is satisfied, but without a signaling 404 - extension, requirement MP#3 is not satisfied if there is a 405 - need to rebalance the load on any composite link carrying the 406 - MPLS server LSP. Load rebalance is generally needed only when 407 - congestion occurs, therefore restricting MPLS-TP to be carried 408 - only over MPLS LSP that are known to traverse only links which 409 + <!-- This paragraph was just plain wrong - fixed it --> 410 + If MPLS-TP LSP are carried within MPLS LSP and ELI and EL 411 + are used, requirement MP#3 is satisfied only for uncongested 412 + links where load balancing is not required, or if MPLS-TP 413 + LSP use TC and Diffserv and the load rebalancing 414 + implementation rebalances only the less preferred traffic. 415 + Load rebalance is generally needed only when congestion 416 + occurs, therefore restricting MPLS-TP to be carried only 417 + over MPLS LSP that are known to traverse only links which 418 are expected to be uncongested can satisfy requirement MP#3. 419 </t> The above paragraph was not just unclear, it was wrong as written. 420 <t> 421 + <!-- summary paragraph, hopefully improves clarity --> 422 + An MPLS-TP LSP can be pinned to a Link Bundle component link 423 + if the behavior of requirement MP#2 is preferred. An 424 + MPLS-TP LSP can be assigned to a Link Bundle but not pinned 425 + if the behavior of requirement MP#3 is preferred. In both 426 + of these cases, the MPLS-TP LSP must be the top level LSP, 427 + except as noted above. 428 + </t> The above summarizes use of link bundling to satisfy MP#2 and MP#3. 429 + <t> 430 + If MPLS-TP LSP can be moved among component links, then the 431 + Link Bundle all-ones component link can be used or server 432 + layer MPLS LSPs can be used with no restrictions on the 433 + server layer MPLS use of multipath except that Entropy Label 434 + must be supported along the entire path. An Entropy Label 435 + must be used to insure that all of the MPLS-TP payload and 436 + OAM traffic are carried on the same component, except during 437 + very infrequent transitions due to load balancing. 438 + </t> If MP#2 and MP#3 are relaxed (note that both say "should provide a mechansism to support ..." but allow that deployments not chose to be that strict), then the above applies - MPLS server layer with EL. 439 + <t> 440 + <!-- multiple requests to be more explicit about this --> 441 + An MPLS-TP LSP may not traverse multipath links on the path 442 + where MPLS-TP forwarding requirements cannot be met. Such 443 + links include any using pre-RFC6790 Ethernet Link 444 + Aggregation, pre-RFC6790 Link Bundling using the all-ones 445 + component link, or other form of multipath not supporting 446 + termination of the entropy search at the EL label as called 447 + for in <xref target="RFC6790" />. An MPLS-TP LSP must not 448 + traverse a server layer MPLS LSP which traverses any form of 449 + multipath not supporting termination of the entropy search 450 + at the EL label. For this to occur, the MPLS-TP ingress LSR 451 + must be aware of these links. This is the reason for 452 + requirement MP#4. 453 + </t> The request was to be explicit about need for support for RFC6790 everywhere, or the need to know where it is not supported. 454 + <t> 455 Requirement MP#4 can be supported using administrative 456 attributes. Administrative attributes are defined in 457 <xref target="RFC3209" />. Some configuration is required to 458 support this. 459 </t> No change here. If RFC6790 is not supported at all LSR, we have a way to handle that. 460 + 461 + </section> 462 + 463 </section> 464 + 465 <section anchor="sect.tp-server-layer" 466 title="MPLS-TP as a Server Layer for MPLS"> 467 + 468 <t> 469 Carrying MPLS LSP which are larger than a component link over 470 a MPLS-TP server layer requires that the large MPLS client 471 @@ -349,7 +575,8 @@ 472 </t> 473 <t> 474 Creating multiple MPLS-TP server layer LSP places a greater 475 - ILM scaling burden on the LSR. High bandwidth MPLS cores with 476 + Incoming Label Map (ILM) scaling burden on the LSR. High 477 + bandwidth MPLS cores with 478 a smaller amount of nodes have the greatest tendency to 479 require LSP in excess of component links, therefore the 480 reduction in number of nodes offsets the impact of increasing Expanded the ILM acronym (requested by Carlos). 481 @@ -374,7 +601,7 @@ 482 fixed allocation of MPLS-TP to component links may not allow 483 another LSP to exceed its predicted capacity. Using MPLS-TP 484 as a server layer may result in less efficient use of 485 - resources may result in a less cost effective network. 486 + resources and may result in a less cost effective network. 487 </t> 488 <t> 489 No additional requirements beyond MPLS-TP as it is now Error noted by Mach. 490 @@ -382,15 +609,65 @@ 491 Layer for MPLS. It is therefore viable but has some 492 undesirable characteristics discussed above. 493 </t> 494 + 495 </section> 496 497 <!-- Possibly an Acknowledgements or a 'Contributors' section ... --> 498 499 + <section title="Acknowledgements"> 500 + 501 + <t> 502 + Carlos Pignataro, Dave Allen, and Mach Chen provided valuable 503 + comments and suggestions. Carlos suggested that MPLS-TP 504 + requirements in RFC 5960 be explicitly referenced or quoted. 505 + An email conversation with Dave led to the inclusion of 506 + references and quotes from RFC 6371 and RFC 6374. Mach made 507 + suggestions to improve clarity of the document. 508 + </t> 509 + 510 + </section> 511 + 512 + <section title="Implementation Status"> 513 + 514 + <t> 515 + Note: this section is temporary and supports the experiment 516 + called for in draft-sheffer-running-code. 517 + </t> 518 + <t> 519 + This is an informational document which describes usage of 520 + MPLS and MPLS-TP. No new protocol extensions or forwarding 521 + behavior are specified. Ethernet Link Aggregation and MPLS 522 + Link Bundling are widely implemented and deployed. 523 + </t> 524 + <t> 525 + Entropy Label is not yet widely implemented and deployed, but 526 + both implementation and deployment are expected soon. At 527 + least a few existing high end commodity packet processing 528 + chips are capable of supporting Entropy Label. It would be 529 + helpful if a few LSR suppliers would state their intentions to 530 + support RFC 6790 on the mpls mailing list. 531 + </t> 532 + <t> 533 + Dynamic multipath (multipath load split adjustment in response 534 + to observed load) is referred to but not a requirement of the 535 + usage recommendations made in this document. Dynamic 536 + multipath has been implemented and deployed, however (afaik) 537 + the only core LSR vendor supporting dynamic multipath is no 538 + longer in the router business (Avici Systems). At least a few 539 + existing high end commodity packet processing chips are 540 + capable of supporting dynamic multipath. 541 + </t> 542 + 543 + </section> Acknowledgement and Implementation Status sections are new. 544 + 545 <section anchor="sect.iana" title="IANA Considerations"> 546 + 547 <t>This memo includes no request to IANA.</t> 548 + 549 </section> 550 551 <section anchor="sect.security" title="Security Considerations"> 552 + 553 <t> 554 This document specifies requirements with discussion of 555 framework for solutions using existing MPLS and MPLS-TP 556 @@ -402,6 +679,7 @@ 557 and for MPLS-TP are documented in <xref target="RFC5920" /> 558 and <xref target="I-D.ietf-mpls-tp-security-framework" />. 559 </t> 560 + 561 </section> 562 563 </middle> 564 @@ -411,6 +689,11 @@ 565 <references title="Normative References"> 566 567 &RFC2119; 568 + &RFC5654; 569 + &RFC5960; 570 + &RFC6790; 571 + &RFC6371; 572 + &RFC6374; 573 574 </references> 575 576 @@ -419,14 +702,12 @@ 577 &RFC2475; 578 &RFC3209; 579 &RFC4201; 580 + &RFC4206; 581 &RFC5286; 582 &RFC5462; 583 - &RFC5654; 584 &RFC5714; 585 &RFC5920; 586 587 - &I-D.ietf-mpls-entropy-label; 588 - 589 &I-D.ietf-mpls-tp-security-framework; 590 591 <reference anchor="IEEE-802.1AX" This is the update to what will be converted to the references section. ------- =_aaaaaaaaaa0-- From mjork@juniper.net Thu Jan 24 20:12:55 2013 Return-Path: <mjork@juniper.net> 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 F2DC411E80DE for <mpls@ietfa.amsl.com>; Thu, 24 Jan 2013 20:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, 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 8sjsUQFMgsU4 for <mpls@ietfa.amsl.com>; Thu, 24 Jan 2013 20:12:54 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7B22011E80D9 for <mpls@ietf.org>; Thu, 24 Jan 2013 20:12:54 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUQIGRt19LHTGUZjVyUXjorIFbbLN5POC@postini.com; Thu, 24 Jan 2013 20:12:54 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 24 Jan 2013 20:12:00 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 24 Jan 2013 20:12:00 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.12) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 24 Jan 2013 20:19:59 -0800 Received: from mail204-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 25 Jan 2013 04:11:59 +0000 Received: from mail204-va3 (localhost [127.0.0.1]) by mail204-va3-R.bigfish.com (Postfix) with ESMTP id 3D497B0025E for <mpls@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Fri, 25 Jan 2013 04:11:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.241.149; KIP:(null); UIP:(null); (null); H:BL2PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzzz1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail204-va3 (localhost.localdomain [127.0.0.1]) by mail204-va3 (MessageSwitch) id 1359087102199411_28358; Fri, 25 Jan 2013 04:11:42 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.252]) by mail204-va3.bigfish.com (Postfix) with ESMTP id 2DF5E40004B; Fri, 25 Jan 2013 04:11:42 +0000 (UTC) Received: from BL2PRD0511HT005.namprd05.prod.outlook.com (157.56.241.149) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 25 Jan 2013 04:11:40 +0000 Received: from BL2PRD0511MB435.namprd05.prod.outlook.com ([169.254.10.72]) by BL2PRD0511HT005.namprd05.prod.outlook.com ([10.255.131.40]) with mapi id 14.16.0257.004; Fri, 25 Jan 2013 04:11:39 +0000 From: Markus Jork <mjork@juniper.net> To: "draft-villamizar-mpls-multipath-use@tools.ietf.org" <draft-villamizar-mpls-multipath-use@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com> Thread-Topic: MPLS-RT review of draft-villamizar-mpls-multipath-use Thread-Index: AQHN8CCsX6XM49HTfEmyUskYf8SSe5hZYzfw Date: Fri, 25 Jan 2013 04:11:38 +0000 Message-ID: <4DDE473A58262547A699C1E7C7AAF2741E4A9962@BL2PRD0511MB435.namprd05.prod.outlook.com> References: <50F04AF0.4060906@pi.nu> In-Reply-To: <50F04AF0.4060906@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] 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%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$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 Cc: "mpls@ietf.org" <mpls@ietf.org> Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jan 2013 04:12:55 -0000 I have been asked to review draft-villamizar-mpls-multipath-use. I think this is a useful document. It focuses in on an area that deserves a= ttention and has not otherwise been covered. The initial terminology defini= tion section provides a good basis for discussion and gives a good overview= of the technology space. The current version of the draft would benefit from fixing some typos and g= rammar to make it more readable. As other reviewers have pointed out already, section 3 could be improved ov= er time by adding some more details and clarifications (which Curtis is alr= eady providing now). Nevertheless, I believe even as is, the document can b= e considered for WG adoption now. -Markus From loa@pi.nu Sat Jan 26 01:30:52 2013 Return-Path: <loa@pi.nu> 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 C7A9621F8484 for <mpls@ietfa.amsl.com>; Sat, 26 Jan 2013 01:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 mInj8ipapYXy for <mpls@ietfa.amsl.com>; Sat, 26 Jan 2013 01:30:52 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4760F21F8835 for <mpls@ietf.org>; Sat, 26 Jan 2013 01:30:52 -0800 (PST) Received: from [192.168.1.104] (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 AF334823B5; Sat, 26 Jan 2013 10:30:47 +0100 (CET) Message-ID: <5103A24F.7020005@pi.nu> Date: Sat, 26 Jan 2013 10:30:55 +0100 From: Loa Andersson <loa@pi.nu> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mpls@ietf.org References: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> In-Reply-To: <3fc8eb084e8034d8deb47c0153623ad9.squirrel@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] working group last call X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 26 Jan 2013 09:30:52 -0000 Working Group, The wglc on draft-ietf-mpls-tp-use-cases-and-design has ended, and there were comments and the authors has promised to upload a new version. After seeing the new version, checking the shepherd write-up and fixing what needs to be fixed in the write-up I will ask our AD to resume the IESG review of the draft. /Loa for the working group co-chairs On 2013-01-14 11:40, loa@pi.nu wrote: > Working Group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-tp-use-cases-and-design. > > This is the second time we working group last call this > draft, it has been updated after comments during the > ADE-review. The changes are such that we have decided to > do a full two week wglc. > > 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. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not aware > of any IPRs. > > This working group last call will end on January 25, 2013. > > /Loa > for the wg co-chairs > -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From curtis@occnc.com Sat Jan 26 10:08:55 2013 Return-Path: <curtis@occnc.com> 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 DED9521F8931 for <mpls@ietfa.amsl.com>; Sat, 26 Jan 2013 10:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.281 X-Spam-Level: X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[AWL=0.214, 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 T19R1qVkMqkB for <mpls@ietfa.amsl.com>; Sat, 26 Jan 2013 10:08:54 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5B921F890D for <mpls@ietf.org>; Sat, 26 Jan 2013 10:08:53 -0800 (PST) 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 r0QI7Viv047153; Sat, 26 Jan 2013 13:07:31 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201301261807.r0QI7Viv047153@gateway1.orleans.occnc.com> To: Loa Andersson <loa@pi.nu> From: Curtis Villamizar <curtis@occnc.com> In-reply-to: Your message of "Sat, 26 Jan 2013 10:30:55 +0100." <5103A24F.7020005@pi.nu> Date: Sat, 26 Jan 2013 13:07:30 -0500 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] working group last call 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 <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 26 Jan 2013 18:08:55 -0000 Loa, Sorry to weigh in this so late in the process, a day after the wglc ended, but I see an issue. First let me say that overall this is a document that deserves to be advanced, but... The entirety of section 4.7 is: 4.7. MPLS-TP and IP/MPLS Interworking considerations Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and IP/MPLS interworking is a reality. The interworking issues are addressed in a separate document [Interworking]. The reference is to an expired individual submission that has received little or no attention on the MPLS WG mailing list. My search of my local mpls mailing list folder turned up zero messages containing the string "draft-martinotti-mpls-tp-interworking" or title substring "Interworking between MPLS". I also search subject lines in the official MPLS WG archive and found no reference to the document name or title substring "Interworking between MPLS" going back as far as 2008 (when the 00 version appeared). Perhaps this section and the reference should be removed. Either that or change it to the following. 4.7. MPLS-TP and IP/MPLS Interworking considerations Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and IP/MPLS interworking is <see below>. This topic requires further study and is out of scope for this document. The authors should also consider replacing "a reality" (the current substitution for <see below> above) with "inevitable if not a reality" unless there are existing deploymenet which either either layers MPLS and MPLS-TP or stitch them. AFAIK both layering and stitching have been discussed, but only ships-in-the-night deployment (control plane for MPLS only, none for TP) or co-deployment (common control plane) of MPLS and MPLS-TP (in only metro networks) is today a reality. If I'm wrong about that, then keep the "is a reality" sentence as-is. I do think that at the very least the referenced should be removed as any work in MPLS on this topic may or may not be based on the referenced document. Again, I appologize for commenting after close of wglc, but I didn't notice this until looking through the references section and following the HTML links in the HTML version of the references section. Curtis In message <5103A24F.7020005@pi.nu> Loa Andersson writes: > > Working Group, > > The wglc on draft-ietf-mpls-tp-use-cases-and-design has ended, > and there were comments and the authors has promised to upload > a new version. > > After seeing the new version, checking the shepherd write-up and > fixing what needs to be fixed in the write-up I will ask our AD > to resume the IESG review of the draft. > > /Loa > for the working group co-chairs > > On 2013-01-14 11:40, loa@pi.nu wrote: > > Working Group, > > > > this is to start a two week Working Group last call on > > draft-ietf-mpls-tp-use-cases-and-design. > > > > This is the second time we working group last call this > > draft, it has been updated after comments during the > > ADE-review. The changes are such that we have decided to > > do a full two week wglc. > > > > 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. > > > > There are no IPR claims against this draft. > > > > All the co-authors has stated that they are not aware > > of any IPRs. > > > > This working group last call will end on January 25, 2013. > > > > /Loa > > for the wg co-chairs > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > MPLS Expert loa@pi.nu > Huawei Technologies (consult) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Sun Jan 27 02:21:56 2013 Return-Path: <loa@pi.nu> 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 8F27B21F87EE for <mpls@ietfa.amsl.com>; Sun, 27 Jan 2013 02:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 Eez6S91fGGg8 for <mpls@ietfa.amsl.com>; Sun, 27 Jan 2013 02:21:50 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 93C6121F85AC for <mpls@ietf.org>; Sun, 27 Jan 2013 02:21:48 -0800 (PST) Received: from [192.168.1.104] (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 96C737FE07; Sun, 27 Jan 2013 11:21:45 +0100 (CET) Message-ID: <5104FFB9.9040805@pi.nu> Date: Sun, 27 Jan 2013 11:21:45 +0100 From: Loa Andersson <loa@pi.nu> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: curtis@occnc.com References: <201301261807.r0QI7Viv047153@gateway1.orleans.occnc.com> In-Reply-To: <201301261807.r0QI7Viv047153@gateway1.orleans.occnc.com> 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-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] working group last call (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 <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Jan 2013 10:21:56 -0000 Curtis, Yes it is a bit inconvenient to have wglc comments coming in late. On the other hand it is better to have them now than during the IETF Last call or the IESG review. I'd like the authors to comment on this. My own take would be the change the second paragraph in section 4.7. and make it say: Interworking is not within the scope of this document, but is for further study. /Loa On 2013-01-26 19:07, Curtis Villamizar wrote: > Loa, > > Sorry to weigh in this so late in the process, a day after the wglc > ended, but I see an issue. > > First let me say that overall this is a document that deserves to be > advanced, but... > > The entirety of section 4.7 is: > > 4.7. MPLS-TP and IP/MPLS Interworking considerations > > Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP > and IP/MPLS interworking is a reality. > > The interworking issues are addressed in a separate document > [Interworking]. > > The reference is to an expired individual submission that has received > little or no attention on the MPLS WG mailing list. My search of my > local mpls mailing list folder turned up zero messages containing the > string "draft-martinotti-mpls-tp-interworking" or title substring > "Interworking between MPLS". I also search subject lines in the > official MPLS WG archive and found no reference to the document name > or title substring "Interworking between MPLS" going back as far as > 2008 (when the 00 version appeared). > > Perhaps this section and the reference should be removed. Either that > or change it to the following. > > 4.7. MPLS-TP and IP/MPLS Interworking considerations > > Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP > and IP/MPLS interworking is <see below>. > > This topic requires further study and is out of scope for this > document. > > The authors should also consider replacing "a reality" (the current > substitution for <see below> above) with "inevitable if not a reality" > unless there are existing deploymenet which either either layers MPLS > and MPLS-TP or stitch them. AFAIK both layering and stitching have > been discussed, but only ships-in-the-night deployment (control plane > for MPLS only, none for TP) or co-deployment (common control plane) of > MPLS and MPLS-TP (in only metro networks) is today a reality. If I'm > wrong about that, then keep the "is a reality" sentence as-is. > > I do think that at the very least the referenced should be removed as > any work in MPLS on this topic may or may not be based on the > referenced document. > > Again, I appologize for commenting after close of wglc, but I didn't > notice this until looking through the references section and following > the HTML links in the HTML version of the references section. > > Curtis > > > In message <5103A24F.7020005@pi.nu> > Loa Andersson writes: >> >> Working Group, >> >> The wglc on draft-ietf-mpls-tp-use-cases-and-design has ended, >> and there were comments and the authors has promised to upload >> a new version. >> >> After seeing the new version, checking the shepherd write-up and >> fixing what needs to be fixed in the write-up I will ask our AD >> to resume the IESG review of the draft. >> >> /Loa >> for the working group co-chairs >> >> On 2013-01-14 11:40, loa@pi.nu wrote: >>> Working Group, >>> >>> this is to start a two week Working Group last call on >>> draft-ietf-mpls-tp-use-cases-and-design. >>> >>> This is the second time we working group last call this >>> draft, it has been updated after comments during the >>> ADE-review. The changes are such that we have decided to >>> do a full two week wglc. >>> >>> 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. >>> >>> There are no IPR claims against this draft. >>> >>> All the co-authors has stated that they are not aware >>> of any IPRs. >>> >>> This working group last call will end on January 25, 2013. >>> >>> /Loa >>> for the wg co-chairs >>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> MPLS Expert loa@pi.nu >> Huawei Technologies (consult) phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From lufang@cisco.com Sun Jan 27 08:11:35 2013 Return-Path: <lufang@cisco.com> 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 D4AD921F86CE for <mpls@ietfa.amsl.com>; Sun, 27 Jan 2013 08:11:35 -0800 (PST) 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 eEt5jNWncH+V for <mpls@ietfa.amsl.com>; Sun, 27 Jan 2013 08:11:30 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 41B7C21F86CA for <mpls@ietf.org>; Sun, 27 Jan 2013 08:11:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6655; q=dns/txt; s=iport; t=1359303090; x=1360512690; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lQFN1PCBhRPDavfL9bnkiNLNZqyuI5rUdSI+izykQPs=; b=EUp4Gpti/0ct91H78dynYy9vn7nuaeuNgZZ6kTG7KdrNNxF1wV5lsRei GpanV63vD6ixM1lG++GjWcI3LSODkQ00RDxj7atyv2Zn5Ef+XnnawwxXh 8VJAEZeKHhkjN7LPTCkZ8nhy8SBhx0hJr5qahtYT1e4VnAPbIneuYjuaA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFRRBVGtJXG+/2dsb2JhbABFvmAWc4IeAQEBBAEBATcxAwsMAgQBCBEDAQIBChQrDAsdCAIEAQ0FCId3Aw8MvjQEBIwMeoM1YQOmVYJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,547,1355097600"; d="scan'208";a="168809176" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 27 Jan 2013 16:11:21 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0RGBLO6019582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Jan 2013 16:11:21 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sun, 27 Jan 2013 10:11:21 -0600 From: "Luyuan Fang (lufang)" <lufang@cisco.com> To: Loa Andersson <loa@pi.nu>, "curtis@occnc.com" <curtis@occnc.com> Thread-Topic: [mpls] working group last call (draft-ietf-mpls-tp-use-cases-and-design) Thread-Index: AQHN/HgixaE8enpOaE2r0xIiX5iAiJhdabWA Date: Sun, 27 Jan 2013 16:11:20 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931026ECCB@xmb-rcd-x03.cisco.com> In-Reply-To: <5104FFB9.9040805@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.82.213.161] Content-Type: text/plain; charset="us-ascii" Content-ID: <76673E6D87D3FD40871863FDF909A100@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" <draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org> Subject: Re: [mpls] working group last call (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 <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Jan 2013 16:11:36 -0000 Curtis and Loa, Thank you for your comments. I am fine to close this now. Here is the brief background on this. We presented the tp-use-case as an individual draft in IETF 80, the slides included a few inter-working scenarios, we asked for WG feedback. Later draft-martinotti-mpls-tp-interworking was resumed, and the draft had extensive discussion on inter-working. WG asked us to work together to align the effort. The two teams met and agreed that draft-martinotti-mpls-tp-interworking would cover all interworking discussion, and the use-case draft would include a pointer to the interworking draft. I had in mind to check with the interworking draft authors later to see if they would have new update or we would remove the pointer. As this is raised now, I'm OK to close it. We are going to remove the reference, and remove section 4.7, as it is no longer providing the information as agreed/intended previously. Thanks, Luyuan -----Original Message----- From: Loa Andersson <loa@pi.nu> Date: Sunday, January 27, 2013 2:21 AM To: "curtis@occnc.com" <curtis@occnc.com> Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" <draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org> Subject: Re: [mpls] working group last call (draft-ietf-mpls-tp-use-cases-and-design) Resent-From: <draft-alias-bounces@tools.ietf.org> Resent-To: Luyuan Fang <lufang@cisco.com>, <ms-daikoku@kddi.com>, Nabil Bitar <nabil.bitar@verizon.com>, <ppan@infinera.com>, <raymond.zhang@alcatel-lucent.com>, <swallow@cisco.com>, <loa@pi.nu>, <rcallon@juniper.net> Resent-Date: Sunday, January 27, 2013 2:21 AM >Curtis, > >Yes it is a bit inconvenient to have wglc comments coming in >late. On the other hand it is better to have them now than during >the IETF Last call or the IESG review. > >I'd like the authors to comment on this. > >My own take would be the change the second paragraph in section 4.7. >and make it say: > > Interworking is not within the scope of this document, but is for > further study. > >/Loa > >On 2013-01-26 19:07, Curtis Villamizar wrote: >> Loa, >> >> Sorry to weigh in this so late in the process, a day after the wglc >> ended, but I see an issue. >> >> First let me say that overall this is a document that deserves to be >> advanced, but... >> >> The entirety of section 4.7 is: >> >> 4.7. MPLS-TP and IP/MPLS Interworking considerations >> >> Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP >> and IP/MPLS interworking is a reality. >> >> The interworking issues are addressed in a separate document >> [Interworking]. >> >> The reference is to an expired individual submission that has received >> little or no attention on the MPLS WG mailing list. My search of my >> local mpls mailing list folder turned up zero messages containing the >> string "draft-martinotti-mpls-tp-interworking" or title substring >> "Interworking between MPLS". I also search subject lines in the >> official MPLS WG archive and found no reference to the document name >> or title substring "Interworking between MPLS" going back as far as >> 2008 (when the 00 version appeared). >> >> Perhaps this section and the reference should be removed. Either that >> or change it to the following. >> >> 4.7. MPLS-TP and IP/MPLS Interworking considerations >> >> Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP >> and IP/MPLS interworking is <see below>. >> >> This topic requires further study and is out of scope for this >> document. >> >> The authors should also consider replacing "a reality" (the current >> substitution for <see below> above) with "inevitable if not a reality" >> unless there are existing deploymenet which either either layers MPLS >> and MPLS-TP or stitch them. AFAIK both layering and stitching have >> been discussed, but only ships-in-the-night deployment (control plane >> for MPLS only, none for TP) or co-deployment (common control plane) of >> MPLS and MPLS-TP (in only metro networks) is today a reality. If I'm >> wrong about that, then keep the "is a reality" sentence as-is. >> >> I do think that at the very least the referenced should be removed as >> any work in MPLS on this topic may or may not be based on the >> referenced document. >> >> Again, I appologize for commenting after close of wglc, but I didn't >> notice this until looking through the references section and following >> the HTML links in the HTML version of the references section. >> >> Curtis >> >> >> In message <5103A24F.7020005@pi.nu> >> Loa Andersson writes: >>> >>> Working Group, >>> >>> The wglc on draft-ietf-mpls-tp-use-cases-and-design has ended, >>> and there were comments and the authors has promised to upload >>> a new version. >>> >>> After seeing the new version, checking the shepherd write-up and >>> fixing what needs to be fixed in the write-up I will ask our AD >>> to resume the IESG review of the draft. >>> >>> /Loa >>> for the working group co-chairs >>> >>> On 2013-01-14 11:40, loa@pi.nu wrote: >>>> Working Group, >>>> >>>> this is to start a two week Working Group last call on >>>> draft-ietf-mpls-tp-use-cases-and-design. >>>> >>>> This is the second time we working group last call this >>>> draft, it has been updated after comments during the >>>> ADE-review. The changes are such that we have decided to >>>> do a full two week wglc. >>>> >>>> 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. >>>> >>>> There are no IPR claims against this draft. >>>> >>>> All the co-authors has stated that they are not aware >>>> of any IPRs. >>>> >>>> This working group last call will end on January 25, 2013. >>>> >>>> /Loa >>>> for the wg co-chairs >>>> >>> >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> MPLS Expert loa@pi.nu >>> Huawei Technologies (consult) phone: +46 739 81 21 64 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >MPLS Expert loa@pi.nu >Huawei Technologies (consult) phone: +46 739 81 21 64 From lufang@cisco.com Sun Jan 27 10:34:51 2013 Return-Path: <lufang@cisco.com> 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 31DB921F84D8 for <mpls@ietfa.amsl.com>; Sun, 27 Jan 2013 10:34:51 -0800 (PST) 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 ojaK3ISXNMIN for <mpls@ietfa.amsl.com>; Sun, 27 Jan 2013 10:34:50 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2BACC21F84C9 for <mpls@ietf.org>; Sun, 27 Jan 2013 10:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7674; q=dns/txt; s=iport; t=1359311690; x=1360521290; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hNzQPJ+f+wpQ96/0ITowQLMCjx7O/AGlCoyfliN8/Zg=; b=ZCwYRWvLH3oM6p93Y+orMmd3yJAqIG5GWuX7h1gvpexAYfVYYui+sg8e pu25W/KtZ6QPLW8Exl6mMC+0Eh582bLBSxqZ6C+UK9cS67MUMzNWHDXsU +wwju/duZn5yj6a07LVcBsaMniv7jc9x5G8/ZH6kSqfcP+jXhab+CuO1Z c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAM1yBVGtJV2Y/2dsb2JhbABFvmAWc4IeAQEBBAEBATcxAwsMAgQBCBEDAQIBChQrDAsdCAIEAQ0FCId3Aw8MvkMEBIwMeoM1YQOmVYJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,547,1355097600"; d="scan'208";a="168841762" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 27 Jan 2013 18:34:49 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0RIYn2H012107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Jan 2013 18:34:49 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Sun, 27 Jan 2013 12:34:49 -0600 From: "Luyuan Fang (lufang)" <lufang@cisco.com> To: Loa Andersson <loa@pi.nu>, "curtis@occnc.com" <curtis@occnc.com> Thread-Topic: [mpls] working group last call (draft-ietf-mpls-tp-use-cases-and-design) Thread-Index: AQHN/HgixaE8enpOaE2r0xIiX5iAiJhdabWAgAAoFYA= Date: Sun, 27 Jan 2013 18:34:48 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931026EEBB@xmb-rcd-x03.cisco.com> In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD931026ECCB@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.82.213.161] Content-Type: text/plain; charset="us-ascii" Content-ID: <CCF14CE6EC6C58429DB8D293AA20D05D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" <draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org> Subject: Re: [mpls] working group last call (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 <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Jan 2013 18:34:51 -0000 Synched with loa. Here is the new text for 4.7. 4.7. MPLS-TP and IP/MPLS Interworking considerations Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and IP/MPLS Interworking is inevitable if not a reality. However, Interworking discussion is out of the scope of this document, it is for further study. Thanks, Luyuan -----Original Message----- From: Luyuan Fang <lufang@cisco.com> Date: Sunday, January 27, 2013 11:11 AM To: Loa Andersson <loa@pi.nu>, "curtis@occnc.com" <curtis@occnc.com> Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" <draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org> Subject: Re: [mpls] working group last call (draft-ietf-mpls-tp-use-cases-and-design) >Curtis and Loa, > >Thank you for your comments. I am fine to close this now. > >Here is the brief background on this. We presented the tp-use-case as an >individual draft in IETF 80, the slides included a few inter-working >scenarios, we asked for WG feedback. Later >draft-martinotti-mpls-tp-interworking was resumed, and the draft had >extensive discussion on inter-working. WG asked us to work together to >align the effort. The two teams met and agreed that >draft-martinotti-mpls-tp-interworking would cover all interworking >discussion, and the use-case draft would include a pointer to the >interworking draft. > >I had in mind to check with the interworking draft authors later to see if >they would have new update or we would remove the pointer. > >As this is raised now, I'm OK to close it. >We are going to remove the reference, and remove section 4.7, as it is no >longer providing the information as agreed/intended previously. > > >Thanks, >Luyuan > > >-----Original Message----- >From: Loa Andersson <loa@pi.nu> >Date: Sunday, January 27, 2013 2:21 AM >To: "curtis@occnc.com" <curtis@occnc.com> >Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" ><mpls-chairs@tools.ietf.org>, >"draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" ><draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org> >Subject: Re: [mpls] working group last call >(draft-ietf-mpls-tp-use-cases-and-design) >Resent-From: <draft-alias-bounces@tools.ietf.org> >Resent-To: Luyuan Fang <lufang@cisco.com>, <ms-daikoku@kddi.com>, Nabil >Bitar <nabil.bitar@verizon.com>, <ppan@infinera.com>, ><raymond.zhang@alcatel-lucent.com>, <swallow@cisco.com>, <loa@pi.nu>, ><rcallon@juniper.net> >Resent-Date: Sunday, January 27, 2013 2:21 AM > >>Curtis, >> >>Yes it is a bit inconvenient to have wglc comments coming in >>late. On the other hand it is better to have them now than during >>the IETF Last call or the IESG review. >> >>I'd like the authors to comment on this. >> >>My own take would be the change the second paragraph in section 4.7. >>and make it say: >> >> Interworking is not within the scope of this document, but is for >> further study. >> >>/Loa >> >>On 2013-01-26 19:07, Curtis Villamizar wrote: >>> Loa, >>> >>> Sorry to weigh in this so late in the process, a day after the wglc >>> ended, but I see an issue. >>> >>> First let me say that overall this is a document that deserves to be >>> advanced, but... >>> >>> The entirety of section 4.7 is: >>> >>> 4.7. MPLS-TP and IP/MPLS Interworking considerations >>> >>> Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP >>> and IP/MPLS interworking is a reality. >>> >>> The interworking issues are addressed in a separate document >>> [Interworking]. >>> >>> The reference is to an expired individual submission that has received >>> little or no attention on the MPLS WG mailing list. My search of my >>> local mpls mailing list folder turned up zero messages containing the >>> string "draft-martinotti-mpls-tp-interworking" or title substring >>> "Interworking between MPLS". I also search subject lines in the >>> official MPLS WG archive and found no reference to the document name >>> or title substring "Interworking between MPLS" going back as far as >>> 2008 (when the 00 version appeared). >>> >>> Perhaps this section and the reference should be removed. Either that >>> or change it to the following. >>> >>> 4.7. MPLS-TP and IP/MPLS Interworking considerations >>> >>> Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP >>> and IP/MPLS interworking is <see below>. >>> >>> This topic requires further study and is out of scope for this >>> document. >>> >>> The authors should also consider replacing "a reality" (the current >>> substitution for <see below> above) with "inevitable if not a reality" >>> unless there are existing deploymenet which either either layers MPLS >>> and MPLS-TP or stitch them. AFAIK both layering and stitching have >>> been discussed, but only ships-in-the-night deployment (control plane >>> for MPLS only, none for TP) or co-deployment (common control plane) of >>> MPLS and MPLS-TP (in only metro networks) is today a reality. If I'm >>> wrong about that, then keep the "is a reality" sentence as-is. >>> >>> I do think that at the very least the referenced should be removed as >>> any work in MPLS on this topic may or may not be based on the >>> referenced document. >>> >>> Again, I appologize for commenting after close of wglc, but I didn't >>> notice this until looking through the references section and following >>> the HTML links in the HTML version of the references section. >>> >>> Curtis >>> >>> >>> In message <5103A24F.7020005@pi.nu> >>> Loa Andersson writes: >>>> >>>> Working Group, >>>> >>>> The wglc on draft-ietf-mpls-tp-use-cases-and-design has ended, >>>> and there were comments and the authors has promised to upload >>>> a new version. >>>> >>>> After seeing the new version, checking the shepherd write-up and >>>> fixing what needs to be fixed in the write-up I will ask our AD >>>> to resume the IESG review of the draft. >>>> >>>> /Loa >>>> for the working group co-chairs >>>> >>>> On 2013-01-14 11:40, loa@pi.nu wrote: >>>>> Working Group, >>>>> >>>>> this is to start a two week Working Group last call on >>>>> draft-ietf-mpls-tp-use-cases-and-design. >>>>> >>>>> This is the second time we working group last call this >>>>> draft, it has been updated after comments during the >>>>> ADE-review. The changes are such that we have decided to >>>>> do a full two week wglc. >>>>> >>>>> 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. >>>>> >>>>> There are no IPR claims against this draft. >>>>> >>>>> All the co-authors has stated that they are not aware >>>>> of any IPRs. >>>>> >>>>> This working group last call will end on January 25, 2013. >>>>> >>>>> /Loa >>>>> for the wg co-chairs >>>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> MPLS Expert loa@pi.nu >>>> Huawei Technologies (consult) phone: +46 739 81 21 64 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >> >>--=20 >> >> >>Loa Andersson email: loa@mail01.huawei.com >>MPLS Expert loa@pi.nu >>Huawei Technologies (consult) phone: +46 739 81 21 64 > From internet-drafts@ietf.org Sun Jan 27 11:36:50 2013 Return-Path: <internet-drafts@ietf.org> 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 DA7D921F85C6; Sun, 27 Jan 2013 11:36:50 -0800 (PST) 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 YGcrXdfGSeGd; Sun, 27 Jan 2013 11:36:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7DB21F8713; Sun, 27 Jan 2013 11:36:50 -0800 (PST) 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.37 Message-ID: <20130127193650.22258.87439.idtracker@ietfa.amsl.com> Date: Sun, 27 Jan 2013 11:36:50 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-use-cases-and-design-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Jan 2013 19:36:51 -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 Applicability; Use Cases and Design Author(s) : Luyuan Fang Nabil Bitar Raymond Zhang Masahiro Daikoku Ping Pan Filename : draft-ietf-mpls-tp-use-cases-and-design-06.txt Pages : 15 Date : 2013-01-27 Abstract: This document provides applicability, use case studies and network design considerations for the Multiprotocol Label Switching Transport Profile (MPLS-TP). The use cases include Metro Ethernet access and aggregation transport, Mobile backhaul, and packet optical transport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-use-cases-and-design-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-use-cases-and-design-= 06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lufang@cisco.com Sun Jan 27 11:46:49 2013 Return-Path: <lufang@cisco.com> 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 B497321F866E for <mpls@ietfa.amsl.com>; Sun, 27 Jan 2013 11:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 rOpLh-zVM1RF for <mpls@ietfa.amsl.com>; Sun, 27 Jan 2013 11:46:48 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 03D7121F871D for <mpls@ietf.org>; Sun, 27 Jan 2013 11:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2436; q=dns/txt; s=iport; t=1359316008; x=1360525608; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rZ55mIr7QP8ufPY/Q55Xlg8p+NQX606PocFXJSVRJGw=; b=go6+d+L7l0HLc0Mj6iu+D6xIZUYGuvnbaIrArZqd6rg86W4mxJ0lHgwP lnRcd8oWYioWuBT7nDS+YiLH73YCSXHHEKpluvP/PUdaN/zZAOzymMC6G 6kSwr5SyGHNZ/jdZjuEvCeVnggrZAXihA3w8cfHkmGAlAjRT0ZybyeEqq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOODBVGtJXG9/2dsb2JhbABFvmAWc4IeAQEBBDoxAwsMAgQBCBEDAQIBChQrFx0IAgQBDQUIh3cDD75VBIwMeoM1YQOmVYJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,547,1355097600"; d="scan'208";a="168852009" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 27 Jan 2013 19:46:41 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0RJkfvq013783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Jan 2013 19:46:41 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Sun, 27 Jan 2013 13:46:40 -0600 From: "Luyuan Fang (lufang)" <lufang@cisco.com> To: Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org> Thread-Topic: working group last call (draft-ietf-mpls-tp-use-cases-and-design) Thread-Index: AQHN/McGb/Q8FLZa3Uqfdun8DWxOqw== Date: Sun, 27 Jan 2013 19:46:40 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931026EF77@xmb-rcd-x03.cisco.com> In-Reply-To: <5103A24F.7020005@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.82.213.161] Content-Type: text/plain; charset="us-ascii" Content-ID: <48730B2675FEB548B5C76EAD20A79397@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" <draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org> Subject: Re: [mpls] working group last call (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 <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Jan 2013 19:46:49 -0000 Loa and all, New version of draft-ietf-mpls-tp-use-cases-and-design is posted. We addressed all on-line and off-line comments from Lucy, Pablo, Huub, Tom, Curtis, and Loa, and acknowledged the folks in the document. Thanks, Luyuan -----Original Message----- From: Loa Andersson <loa@pi.nu> Date: Saturday, January 26, 2013 1:30 AM To: "mpls@ietf.org" <mpls@ietf.org> Cc: "draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org" <draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "martin.vigoureux@alcatel-lucent.com" <martin.vigoureux@alcatel-lucent.com> Subject: Re: working group last call Resent-From: <draft-alias-bounces@tools.ietf.org> Resent-To: Luyuan Fang <lufang@cisco.com>, <ms-daikoku@kddi.com>, Nabil Bitar <nabil.bitar@verizon.com>, <ppan@infinera.com>, <raymond.zhang@alcatel-lucent.com>, <swallow@cisco.com>, <loa@pi.nu>, <rcallon@juniper.net> Resent-Date: Saturday, January 26, 2013 1:30 AM >Working Group, > >The wglc on draft-ietf-mpls-tp-use-cases-and-design has ended, >and there were comments and the authors has promised to upload >a new version. > >After seeing the new version, checking the shepherd write-up and >fixing what needs to be fixed in the write-up I will ask our AD >to resume the IESG review of the draft. > >/Loa >for the working group co-chairs > >On 2013-01-14 11:40, loa@pi.nu wrote: >> Working Group, >> >> this is to start a two week Working Group last call on >> draft-ietf-mpls-tp-use-cases-and-design. >> >> This is the second time we working group last call this >> draft, it has been updated after comments during the >> ADE-review. The changes are such that we have decided to >> do a full two week wglc. >> >> 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. >> >> There are no IPR claims against this draft. >> >> All the co-authors has stated that they are not aware >> of any IPRs. >> >> This working group last call will end on January 25, 2013. >> >> /Loa >> for the wg co-chairs >> > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >MPLS Expert loa@pi.nu >Huawei Technologies (consult) phone: +46 739 81 21 64 From vishwas.ietf@gmail.com Sun Jan 27 13:27:14 2013 Return-Path: <vishwas.ietf@gmail.com> 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 61AF521F84B9 for <mpls@ietfa.amsl.com>; Sun, 27 Jan 2013 13:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 m+MsJCsb7l08 for <mpls@ietfa.amsl.com>; Sun, 27 Jan 2013 13:27:13 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5129B21F84A1 for <mpls@ietf.org>; Sun, 27 Jan 2013 13:27:13 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id o13so407505qaj.1 for <mpls@ietf.org>; Sun, 27 Jan 2013 13:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Q6LYYyPjku8wD3DvTml/842j6mNKBcVqThd/evy3TSY=; b=XS6GFtqhFstf4RZ48/xw6XI6vMu1Jn9yLU3m0R53bypjEWsOf8QMmDFdY9IzRT/OG7 RsBSxK6fjcijYBj3/ShilY1zqvnbo3tF+IIO0hDFESm2hkM56cKPbbpuxV43tKQkf4Dl ykTPKaC2RkIUbX9+NIA7uTt44VE8AqtEOiWwgcz1LIffkuybF8InDXHP7uHbTItWDoSP rtFcMUt2xSq6fm8PgjFW7l3BY+UJxMjLIF7EAblXWLtpAdcrtXUqquhHMNIkf/GjqcUe HQSV2+zEZnSeye+a1x670367SZ9Dwplt6rTyp2sY5VWiFCiESRrLCWsTDD97r/B70V2+ GBfw== MIME-Version: 1.0 X-Received: by 10.224.221.145 with SMTP id ic17mr13380977qab.34.1359322032826; Sun, 27 Jan 2013 13:27:12 -0800 (PST) Received: by 10.229.92.77 with HTTP; Sun, 27 Jan 2013 13:27:12 -0800 (PST) In-Reply-To: <50FFA5E1.7070001@pi.nu> References: <50FFA5E1.7070001@pi.nu> Date: Sun, 27 Jan 2013 13:27:12 -0800 Message-ID: <CAOyVPHR0nBzMkV8gVdAzB7eHK7u0DyXBAnwNiArp3wmSP=PGrw@mail.gmail.com> From: Vishwas Manral <vishwas.ietf@gmail.com> To: Loa Andersson <loa@pi.nu> Content-Type: multipart/alternative; boundary=20cf3074b458e6e7ae04d44bd295 Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-smiler-mpls-tp-linear-protection-mib X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Jan 2013 21:27:14 -0000 --20cf3074b458e6e7ae04d44bd295 Content-Type: text/plain; charset=ISO-8859-1 Hi Loa, I am unaware of any IPR related to this draft. Thanks, Vishwas On Wed, Jan 23, 2013 at 12:57 AM, Loa Andersson <loa@pi.nu> wrote: > Working Group and authors; > > The authors of draft-smiler-mpls-tp-linear-**protection-mib has indicated > that the draft is ready to be adopted as a working group document. > > Before starting the poll to see if there is wg consensus to make the > draft 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-smiler-mpls-tp-linear- > protection-mib? > > 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@mail01.huawei.com > MPLS Expert loa@pi.nu > Huawei Technologies (consult) phone: +46 739 81 21 64 > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls> > --20cf3074b458e6e7ae04d44bd295 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Loa,<br><br>I am unaware of any IPR related to this draft.<br><br>Thanks= ,<br>Vishwas<br><div class=3D"gmail_quote">On Wed, Jan 23, 2013 at 12:57 AM= , Loa Andersson <span dir=3D"ltr"><<a href=3D"mailto:loa@pi.nu" target= =3D"_blank">loa@pi.nu</a>></span> wrote:<br> <blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-= color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class= =3D"gmail_quote">Working Group and authors;<br> <br> The authors of draft-smiler-mpls-tp-linear-<u></u>protection-mib has indica= ted<br> that the draft is ready to be adopted as a working group document.<br> <br> Before starting the poll to see if there is wg consensus to make the<br> draft a working group document we will do an IPR poll to check whether<br> there is IPR on the document that needs to be disclosed.<br> <br> This mail starts that IPR poll.<br> <br> Are you aware of any IPR that applies to draft-smiler-mpls-tp-linear-<br> protection-mib?<br> <br> If so, has this IPR been disclosed in compliance with IETF IPR rules<br> (see RFCs 3979, 4879, 3669 and 5378 for more details).<br> <br> If you are listed as a document author or contributor please respond to<br> this email regardless of whether or not you are aware of any relevant<br> IPR. *The response needs to be sent to the MPLS wg mailing list.* The docum= ents will not advance to the next stage until a response<br> has been received from each author and contributor.<br> <br> If you are on the MPLS WG email list but are not listed as an author or<br> contributor, then please explicitly respond only if you are aware of any<br= > IPR that has not yet been disclosed in conformance with IETF rules.<br> <br> <br> Thanks, Loa<br> (as MPLS WG co-chair)<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> <br> <br> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: <a href= =3D"mailto:loa@mail01.huawei.com" target=3D"_blank">loa@mail01.huawei.com</= a><br> MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= <a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu</a><br> Huawei Technologies (consult) =A0 =A0 =A0 =A0phone: <a href=3D"tel:%2B46%20= 739%2081%2021%2064" target=3D"_blank" value=3D"+46739812164">+46 739 81 21 = 64</a><br> ______________________________<u></u>_________________<br> mpls mailing list<br> <a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">ht= tps://www.ietf.org/mailman/<u></u>listinfo/mpls</a><br> </font></span></blockquote></div><br> --20cf3074b458e6e7ae04d44bd295-- From loa@pi.nu Mon Jan 28 01:12:58 2013 Return-Path: <loa@pi.nu> 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 DFCD121F842C for <mpls@ietfa.amsl.com>; Mon, 28 Jan 2013 01:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 2YcjHOG-t7tD for <mpls@ietfa.amsl.com>; Mon, 28 Jan 2013 01:12:58 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3921F8203 for <mpls@ietf.org>; Mon, 28 Jan 2013 01:12:57 -0800 (PST) Received: from [192.168.1.104] (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 9D9E67FE07; Mon, 28 Jan 2013 10:12:53 +0100 (CET) Message-ID: <51064116.8050508@pi.nu> Date: Mon, 28 Jan 2013 10:12:54 +0100 From: Loa Andersson <loa@pi.nu> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" <mpls@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, draft-ietf-mpls-tp-ring-protection@tools.ietf.org Subject: [mpls] working group last call - 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 <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jan 2013 09:12:59 -0000 Working Group, This is to start a working group last call on draft-ietf-mpls-tp-ring-protection. 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. There are tw IPR claims against this draft; ID # 1462 and ID # 1872. All the co-authors has stated that they are not ware of any IPRs, other than the two listed above. This working group last call will end on February 9, 2013. /Loa for the wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From loa@pi.nu Mon Jan 28 02:33:02 2013 Return-Path: <loa@pi.nu> 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 4EA4F21F862B for <mpls@ietfa.amsl.com>; Mon, 28 Jan 2013 02:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 LdRC3taPthQF for <mpls@ietfa.amsl.com>; Mon, 28 Jan 2013 02:33:02 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id B6FE921F842F for <mpls@ietf.org>; Mon, 28 Jan 2013 02:33:01 -0800 (PST) Received: from [192.168.1.104] (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 0164A7FE07; Mon, 28 Jan 2013 11:32:57 +0100 (CET) Message-ID: <510653DA.5050200@pi.nu> Date: Mon, 28 Jan 2013 11:32:58 +0100 From: Loa Andersson <loa@pi.nu> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" <mpls@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "<mpls-ads@tools.ietf.org>" <mpls-ads@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org Subject: [mpls] poll to see if we have consensus to adopt draft-smiler-mpls-tp-linear-protection-mib as a wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jan 2013 10:33:02 -0000 Working group, This is to start a two week poll on adopting draft-smiler-mpls-tp-linear-protection-mib 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 a 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 February 8, 2013. There are no IPR claim against this document. All the active co-authors has stated on the working group mailing list that they are not aware of any other IPR claims than those already disclosed. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) -- -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From loa@pi.nu Mon Jan 28 03:26:22 2013 Return-Path: <loa@pi.nu> 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 9E01E21F8450 for <mpls@ietfa.amsl.com>; Mon, 28 Jan 2013 03:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 VWijO2CmfPxs for <mpls@ietfa.amsl.com>; Mon, 28 Jan 2013 03:26:22 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 059C721F8444 for <mpls@ietf.org>; Mon, 28 Jan 2013 03:26:21 -0800 (PST) Received: from [192.168.1.104] (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 E64A37FE07; Mon, 28 Jan 2013 12:26:18 +0100 (CET) Message-ID: <5106605B.3060800@pi.nu> Date: Mon, 28 Jan 2013 12:26:19 +0100 From: Loa Andersson <loa@pi.nu> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: [mpls] time to resume the publication process for 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 <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jan 2013 11:26:22 -0000 Adrian, 1. draft-ietf-mpls-tp-use-cases-and-design has been updated after AD review comments 2. The document has been through a 2nd wglc and updated 3. The Shepherd write-up has been updated It is time to resume the publication process for ths document. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From daniel@olddog.co.uk Mon Jan 28 05:50:25 2013 Return-Path: <daniel@olddog.co.uk> 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 1B81621F8659 for <mpls@ietfa.amsl.com>; Mon, 28 Jan 2013 05:50:25 -0800 (PST) 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 ZomdfZgg2vFX for <mpls@ietfa.amsl.com>; Mon, 28 Jan 2013 05:50:24 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 590A421F862B for <mpls@ietf.org>; Mon, 28 Jan 2013 05:50:24 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0SDoLPH008239 for <mpls@ietf.org>; Mon, 28 Jan 2013 13:50:22 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0SDoKpn008208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <mpls@ietf.org>; Mon, 28 Jan 2013 13:50:21 GMT From: "Daniel King" <daniel@olddog.co.uk> To: <mpls@ietf.org> References: <510653DA.5050200@pi.nu> In-Reply-To: <510653DA.5050200@pi.nu> Date: Mon, 28 Jan 2013 13:50:19 -0000 Message-ID: <004f01cdfd5e$69787eb0$3c697c10$@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: AQK//rZzsnfPaMtl1Ck1Y0qscbgSjZZ6vyGQ Content-Language: en-gb Subject: Re: [mpls] poll to see if we have consensus to adopt draft-smiler-mpls-tp-linear-protection-mib as a wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jan 2013 13:50:25 -0000 Support (as an author). RFC6378 presents a protocol/mechanism for MPLS-TP linear protection. This (draft-smiler-mpls-tp-linear-protection-mib) document specifies the necessary textual conventions and MIB module for monitoring MPLS-TP linear protection on the LER. Br, Dan. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: 28 January 2013 10:33 To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org; <mpls-ads@tools.ietf.org>; Martin Vigoureux Subject: poll to see if we have consensus to adopt draft-smiler-mpls-tp-linear-protection-mib as a wg doc Working group, This is to start a two week poll on adopting draft-smiler-mpls-tp-linear-protection-mib 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 a 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 February 8, 2013. There are no IPR claim against this document. All the active co-authors has stated on the working group mailing list that they are not aware of any other IPR claims than those already disclosed. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) -- -- Loa Andersson email: loa@mail01.huawei.com MPLS Expert loa@pi.nu Huawei Technologies (consult) phone: +46 739 81 21 64 From internet-drafts@ietf.org Mon Jan 28 06:52:59 2013 Return-Path: <internet-drafts@ietf.org> 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 5C57421F87FA; Mon, 28 Jan 2013 06:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 bJCm-FgftFdA; Mon, 28 Jan 2013 06:52:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5AB21F880B; Mon, 28 Jan 2013 06:52:58 -0800 (PST) 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.37 Message-ID: <20130128145258.31255.25887.idtracker@ietfa.amsl.com> Date: Mon, 28 Jan 2013 06:52:58 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-targeted-mldp-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jan 2013 14:52: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 : Using LDP Multipoint Extensions on Targeted LDP Sessions Author(s) : Maria Napierala Eric C. Rosen Filename : draft-ietf-mpls-targeted-mldp-01.txt Pages : 9 Date : 2013-01-28 Abstract: Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. The existing specification for this functionality assumes that a pair of LDP neighbors are directly connected. However, the LDP base specification allows for the case where a pair of LDP neighbors are not directly connected; the LDP session between such a pair of neighbors is known as a "Targeted LDP" session. This document provides the specification for using the LDP P2MP/MP2MP extensions over a Targeted LDP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-targeted-mldp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-targeted-mldp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-targeted-mldp-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Mon Jan 28 09:22:08 2013 Return-Path: <adrian@olddog.co.uk> 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 CFCFB21F86CE for <mpls@ietfa.amsl.com>; Mon, 28 Jan 2013 09:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 2VAaobE38Dos for <mpls@ietfa.amsl.com>; Mon, 28 Jan 2013 09:22:05 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 84E8B21F842F for <mpls@ietf.org>; Mon, 28 Jan 2013 09:22:05 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0SHLxop002349; Mon, 28 Jan 2013 17:22:00 GMT Received: from 950129200 (089144192207.atnat0001.highway.a1.net [89.144.192.207]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0SHLr58002245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 17:21:58 GMT From: "Adrian Farrel" <adrian@olddog.co.uk> To: "'Loa Andersson'" <loa@pi.nu> References: <5106605B.3060800@pi.nu> In-Reply-To: <5106605B.3060800@pi.nu> Date: Mon, 28 Jan 2013 17:21:54 -0000 Message-ID: <00fd01cdfd7b$fb1ba4b0$f152ee10$@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: AQKlh3iV9P4kdCODB5iv2CvO71fF2pav4KUA Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: Re: [mpls] time to resume the publication process for 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 <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jan 2013 17:22:08 -0000 received thanks Adrian > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 28 January 2013 11:26 > To: Adrian Farrel > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; Martin Vigoureux; draft-ietf-mpls- > tp-use-cases-and-design@tools.ietf.org > Subject: time to resume the publication process for draft-ietf-mpls-tp-use-cases- > and-design > > Adrian, > > 1. draft-ietf-mpls-tp-use-cases-and-design has been updated after AD > review comments > 2. The document has been through a 2nd wglc and updated > 3. The Shepherd write-up has been updated > > It is time to resume the publication process for ths document. > > /Loa > for the MPLS wg co-chairs > > -- > > > Loa Andersson email: loa@mail01.huawei.com > MPLS Expert loa@pi.nu > Huawei Technologies (consult) phone: +46 739 81 21 64 From iesg-secretary@ietf.org Mon Jan 28 12:01:19 2013 Return-Path: <iesg-secretary@ietf.org> 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 9447721F8994; Mon, 28 Jan 2013 12:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 5TWb29OYEHB5; Mon, 28 Jan 2013 12:01:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AF021F87FA; Mon, 28 Jan 2013 12:01:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130128200109.10916.38496.idtracker@ietfa.amsl.com> Date: Mon, 28 Jan 2013 12:01:09 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: <draft-ietf-mpls-tp-use-cases-and-design-06.txt> (MPLS-TP Applicability; Use Cases and Design) to Informational RFC 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 <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jan 2013 20:01:19 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Applicability; Use Cases and Design' <draft-ietf-mpls-tp-use-cases-and-design-06.txt> as Informational RFC 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 2013-02-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides applicability, use case studies and network design considerations for the Multiprotocol Label Switching Transport Profile (MPLS-TP). The use cases include Metro Ethernet access and aggregation transport, Mobile backhaul, and packet optical transport. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design/ballot/ No IPR declarations have been submitted directly on this I-D. From mach.chen@huawei.com Tue Jan 29 16:41:37 2013 Return-Path: <mach.chen@huawei.com> 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 608DF21F886F for <mpls@ietfa.amsl.com>; Tue, 29 Jan 2013 16:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 gSci8gp8lsXR for <mpls@ietfa.amsl.com>; Tue, 29 Jan 2013 16:41:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D042D21F884C for <mpls@ietf.org>; Tue, 29 Jan 2013 16:41:35 -0800 (PST) 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 ANZ32568; Wed, 30 Jan 2013 00:41:33 +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.7; Wed, 30 Jan 2013 00:40:57 +0000 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 30 Jan 2013 00:41:32 +0000 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.187]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.007; Wed, 30 Jan 2013 08:41:29 +0800 From: Mach Chen <mach.chen@huawei.com> To: Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org> Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-smiler-mpls-tp-linear-protection-mib as a wg doc Thread-Index: AQHN/ULgsooHO/zsGUO+a21GaujfJJhhCncA Date: Wed, 30 Jan 2013 00:41:29 +0000 Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2501E571B@szxeml558-mbs.china.huawei.com> References: <510653DA.5050200@pi.nu> In-Reply-To: <510653DA.5050200@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.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "<mpls-ads@tools.ietf.org>" <mpls-ads@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org" <draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org> Subject: Re: [mpls] poll to see if we have consensus to adopt draft-smiler-mpls-tp-linear-protection-mib as a wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jan 2013 00:41:37 -0000 Support. Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of L= oa > Andersson > Sent: Monday, January 28, 2013 6:33 PM > To: mpls@ietf.org > Cc: <mpls-ads@tools.ietf.org>; mpls-chairs@tools.ietf.org; > draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org > Subject: [mpls] poll to see if we have consensus to adopt > draft-smiler-mpls-tp-linear-protection-mib as a wg doc >=20 > Working group, >=20 > This is to start a two week poll on adopting > draft-smiler-mpls-tp-linear-protection-mib 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 a technical > 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 February 8, 2013. >=20 > There are no IPR claim against this document. >=20 > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. However if you are on the the mpls working group mailing > list and aware of IPR that relates to this draft, the time to disclose > this is now. >=20 > /Loa > (mpls wg co-chair) >=20 > -- > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > MPLS Expert loa@pi.nu > Huawei Technologies (consult) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From krishnamurthymayya@gmail.com Wed Jan 30 04:44:08 2013 Return-Path: <krishnamurthymayya@gmail.com> 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 B960921F8945 for <mpls@ietfa.amsl.com>; Wed, 30 Jan 2013 04:44:08 -0800 (PST) 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 G1YnsGVRUAew for <mpls@ietfa.amsl.com>; Wed, 30 Jan 2013 04:44:08 -0800 (PST) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by ietfa.amsl.com (Postfix) with ESMTP id AE45421F8939 for <mpls@ietf.org>; Wed, 30 Jan 2013 04:44:07 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id uz6so1541590obc.6 for <mpls@ietf.org>; Wed, 30 Jan 2013 04:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=J82PBpKV2TJ7rykDVFHCEM6aU28kaQex1j01eY3Cfp0=; b=hNxkge4TzF6EtvfWYb1UxU5C4h0RFQ9VfELzndiGt81syFbs8THamWBG0C1SX6kQuH Z0IWN1ubHWZcRueDYwr/VKi898kYD1rCBdZvP4dIrHb+4CVn/7kNc8X1D42qZBpFCzDW YfUC2JkbZQjjLEjbpXeYrRI/sDsSArL0+AATOu0KB59VXnsaVT9LwsvocqGN/f6iO5H6 gvKlLAKaFcXVVmdDSnjg2mfhKnjrddY3/JC0nkYYYnLBHcUJJjrVnMGB3arZtDaFx4zT HoOj9U2J2ATumA05uIKymHctq5KkZ7IG4gx0rLQ2/Q0/G2YRL6shf/qpR+InPkqQ32RE HAgg== MIME-Version: 1.0 X-Received: by 10.60.1.42 with SMTP id 10mr3364103oej.125.1359549847088; Wed, 30 Jan 2013 04:44:07 -0800 (PST) Received: by 10.60.172.46 with HTTP; Wed, 30 Jan 2013 04:44:06 -0800 (PST) In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2501E571B@szxeml558-mbs.china.huawei.com> References: <510653DA.5050200@pi.nu> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2501E571B@szxeml558-mbs.china.huawei.com> Date: Wed, 30 Jan 2013 18:14:06 +0530 Message-ID: <CA+cY5y5DP-O1BwSvApP4a7_xSdy6N8eKNUQJX=agPRwHpHRPAA@mail.gmail.com> From: Krishnamurthy Mayya <krishnamurthymayya@gmail.com> To: Loa Andersson <loa@pi.nu> Content-Type: multipart/alternative; boundary=e89a8fb1fe18b0ad8004d480dd54 Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org" <draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org>, "<mpls-ads@tools.ietf.org>" <mpls-ads@tools.ietf.org> Subject: Re: [mpls] poll to see if we have consensus to adopt draft-smiler-mpls-tp-linear-protection-mib as a wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jan 2013 12:44:08 -0000 --e89a8fb1fe18b0ad8004d480dd54 Content-Type: text/plain; charset=ISO-8859-1 Support from my side ! Regards, Krishnamurthy Mayya On Wed, Jan 30, 2013 at 6:11 AM, Mach Chen <mach.chen@huawei.com> wrote: > Support. > > Best regards, > Mach > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa > > Andersson > > Sent: Monday, January 28, 2013 6:33 PM > > To: mpls@ietf.org > > Cc: <mpls-ads@tools.ietf.org>; mpls-chairs@tools.ietf.org; > > draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org > > Subject: [mpls] poll to see if we have consensus to adopt > > draft-smiler-mpls-tp-linear-protection-mib as a wg doc > > > > Working group, > > > > This is to start a two week poll on adopting > > draft-smiler-mpls-tp-linear-protection-mib 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 a 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 February 8, 2013. > > > > There are no IPR claim against this document. > > > > All the active co-authors has stated on the working group mailing list > > that they are not aware of any other IPR claims than those already > > disclosed. However if you are on the the mpls working group mailing > > list and aware of IPR that relates to this draft, the time to disclose > > this is now. > > > > /Loa > > (mpls wg co-chair) > > > > -- > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > MPLS Expert loa@pi.nu > > Huawei Technologies (consult) phone: +46 739 81 21 64 > > _______________________________________________ > > 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 > --e89a8fb1fe18b0ad8004d480dd54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support from my side !<div><br></div><div>Regards,</div><div>Krishnamurthy = Mayya<br><br><div class=3D"gmail_quote">On Wed, Jan 30, 2013 at 6:11 AM, Ma= ch Chen <span dir=3D"ltr"><<a href=3D"mailto:mach.chen@huawei.com" targe= t=3D"_blank">mach.chen@huawei.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Support.<br> <br> Best regards,<br> Mach<br> <div class=3D"im HOEnZb"><br> > -----Original Message-----<br> > From: <a href=3D"mailto:mpls-bounces@ietf.org">mpls-bounces@ietf.org</= a> [mailto:<a href=3D"mailto:mpls-bounces@ietf.org">mpls-bounces@ietf.org</= a>] On Behalf Of Loa<br> > Andersson<br> > Sent: Monday, January 28, 2013 6:33 PM<br> > To: <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a><br> > Cc: <<a href=3D"mailto:mpls-ads@tools.ietf.org">mpls-ads@tools.ietf= .org</a>>; <a href=3D"mailto:mpls-chairs@tools.ietf.org">mpls-chairs@too= ls.ietf.org</a>;<br> > <a href=3D"mailto:draft-smiler-mpls-tp-linear-protection-mib@tools.iet= f.org">draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org</a><br> > Subject: [mpls] poll to see if we have consensus to adopt<br> > draft-smiler-mpls-tp-linear-protection-mib as a wg doc<br> ><br> </div><div class=3D"HOEnZb"><div class=3D"h5">> Working group,<br> ><br> > This is to start a two week poll on adopting<br> > draft-smiler-mpls-tp-linear-protection-mib as an MPLS working<br> > group document.<br> ><br> > Please send your comments (support/not support) to the mpls working<br= > > group mailing list (mpls at <a href=3D"http://ietf.org" target=3D"_bla= nk">ietf.org</a>). Please give a technical<br> > motivation for your support/not support, especially if you think that<= br> > the document should not be adopted as a working group document.<br> ><br> > This poll ends February 8, 2013.<br> ><br> > There are no IPR claim against this document.<br> ><br> > All the active co-authors has stated on the working group mailing list= <br> > that they are not aware of any other IPR claims than those already<br> > disclosed. However if you are on the the mpls working group mailing<br= > > list and aware of IPR that relates to this draft, the time to disclose= <br> > this is now.<br> ><br> > /Loa<br> > (mpls wg co-chair)<br> ><br> > --<br> > --<br> ><br> ><br> > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: <a= href=3D"mailto:loa@mail01.huawei.com">loa@mail01.huawei.com</a><br> > MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 <a href=3D"mailto:loa@pi.nu">loa@pi.nu</a><br> > Huawei Technologies (consult) =A0 =A0 =A0 =A0phone: +46 739 81 21 64<b= r> > _______________________________________________<br> > mpls mailing list<br> > <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blan= k">https://www.ietf.org/mailman/listinfo/mpls</a><br> _______________________________________________<br> mpls mailing list<br> <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/mpls</a><br> </div></div></blockquote></div><br></div> --e89a8fb1fe18b0ad8004d480dd54-- From binnyjeshan@gmail.com Wed Jan 30 04:58:54 2013 Return-Path: <binnyjeshan@gmail.com> 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 E83AB21F8941 for <mpls@ietfa.amsl.com>; Wed, 30 Jan 2013 04:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 oOoGEfUu+wag for <mpls@ietfa.amsl.com>; Wed, 30 Jan 2013 04:58:54 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A994621F8947 for <mpls@ietf.org>; Wed, 30 Jan 2013 04:58:53 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x8so1207781wey.34 for <mpls@ietf.org>; Wed, 30 Jan 2013 04:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KZecrHf5eykbxaG3PAo2TZaJ0RQ7oYJdQOOizD7gYCE=; b=jWy9c/UsBR7Pcole5jHVioGB0DCyaOnJlz0TO0ZsNIHR7iZHJ1CvbufrHjvY15yKoP AgzZrf6eMZno7TZNq01kpH+mH0gj9HVEYmoVumV7n52L/9DDfq4EUOow7Jx6EDCx3yc1 Pg5LBPaiT7jkIge6yqhpPRnaBYPMO+xAaD6Ug0FxF2DaUaKCqcQyhp9CaHpLK6XPMauF Q6cBfsyrhNFQmy9ll8ndST0Ikcl5fgXLr/Za0lZI74TJMJMaN/9ZNxXUcwTp8z5JvwVC hSy0kFrRAoHnjjH2LzLdurh2H5q/ajmI2WbK9c4FxPyhKrGNH5qn3ifdJPmq6RWmkRCQ pVAQ== MIME-Version: 1.0 X-Received: by 10.180.79.37 with SMTP id g5mr8666026wix.8.1359550732594; Wed, 30 Jan 2013 04:58:52 -0800 (PST) Received: by 10.194.15.3 with HTTP; Wed, 30 Jan 2013 04:58:52 -0800 (PST) In-Reply-To: <CA+cY5y5DP-O1BwSvApP4a7_xSdy6N8eKNUQJX=agPRwHpHRPAA@mail.gmail.com> References: <510653DA.5050200@pi.nu> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2501E571B@szxeml558-mbs.china.huawei.com> <CA+cY5y5DP-O1BwSvApP4a7_xSdy6N8eKNUQJX=agPRwHpHRPAA@mail.gmail.com> Date: Wed, 30 Jan 2013 18:28:52 +0530 Message-ID: <CAHcPYOzhTSD+1B7_+2r_17eEYZWVo5Py=6t_tL3DnD=riciXKg@mail.gmail.com> From: Binny Jeshan <binnyjeshan@gmail.com> To: Krishnamurthy Mayya <krishnamurthymayya@gmail.com> Content-Type: multipart/alternative; boundary=f46d044306b0786e9404d4811294 Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "<mpls-ads@tools.ietf.org>" <mpls-ads@tools.ietf.org>, "draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org" <draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org> Subject: Re: [mpls] poll to see if we have consensus to adopt draft-smiler-mpls-tp-linear-protection-mib as a wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jan 2013 12:58:55 -0000 --f46d044306b0786e9404d4811294 Content-Type: text/plain; charset=ISO-8859-1 I just read the 3'rd version of the draft. I Support ! -Binny Aricent Group On 30 January 2013 18:14, Krishnamurthy Mayya <krishnamurthymayya@gmail.com>wrote: > Support from my side ! > > Regards, > Krishnamurthy Mayya > > > On Wed, Jan 30, 2013 at 6:11 AM, Mach Chen <mach.chen@huawei.com> wrote: > >> Support. >> >> Best regards, >> Mach >> >> > -----Original Message----- >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of Loa >> > Andersson >> > Sent: Monday, January 28, 2013 6:33 PM >> > To: mpls@ietf.org >> > Cc: <mpls-ads@tools.ietf.org>; mpls-chairs@tools.ietf.org; >> > draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org >> > Subject: [mpls] poll to see if we have consensus to adopt >> > draft-smiler-mpls-tp-linear-protection-mib as a wg doc >> > >> > Working group, >> > >> > This is to start a two week poll on adopting >> > draft-smiler-mpls-tp-linear-protection-mib 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 a 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 February 8, 2013. >> > >> > There are no IPR claim against this document. >> > >> > All the active co-authors has stated on the working group mailing list >> > that they are not aware of any other IPR claims than those already >> > disclosed. However if you are on the the mpls working group mailing >> > list and aware of IPR that relates to this draft, the time to disclose >> > this is now. >> > >> > /Loa >> > (mpls wg co-chair) >> > >> > -- >> > -- >> > >> > >> > Loa Andersson email: loa@mail01.huawei.com >> > MPLS Expert loa@pi.nu >> > Huawei Technologies (consult) phone: +46 739 81 21 64 >> > _______________________________________________ >> > 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 > > --f46d044306b0786e9404d4811294 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I just read the 3'rd version of the draft.<div><br></div><div>I Support= !</div><div><br></div><div>-Binny</div><div>Aricent Group<br><br><div clas= s=3D"gmail_quote">On 30 January 2013 18:14, Krishnamurthy Mayya <span dir= =3D"ltr"><<a href=3D"mailto:krishnamurthymayya@gmail.com" target=3D"_bla= nk">krishnamurthymayya@gmail.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Support from my side !<div><br></div><div>Re= gards,</div><div>Krishnamurthy Mayya<div><div class=3D"h5"><br><br><div cla= ss=3D"gmail_quote"> On Wed, Jan 30, 2013 at 6:11 AM, Mach Chen <span dir=3D"ltr"><<a href=3D= "mailto:mach.chen@huawei.com" target=3D"_blank">mach.chen@huawei.com</a>>= ;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Support.<br> <br> Best regards,<br> Mach<br> <div><br> > -----Original Message-----<br> > From: <a href=3D"mailto:mpls-bounces@ietf.org" target=3D"_blank">mpls-= bounces@ietf.org</a> [mailto:<a href=3D"mailto:mpls-bounces@ietf.org" targe= t=3D"_blank">mpls-bounces@ietf.org</a>] On Behalf Of Loa<br> > Andersson<br> > Sent: Monday, January 28, 2013 6:33 PM<br> > To: <a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org</= a><br> > Cc: <<a href=3D"mailto:mpls-ads@tools.ietf.org" target=3D"_blank">m= pls-ads@tools.ietf.org</a>>; <a href=3D"mailto:mpls-chairs@tools.ietf.or= g" target=3D"_blank">mpls-chairs@tools.ietf.org</a>;<br> > <a href=3D"mailto:draft-smiler-mpls-tp-linear-protection-mib@tools.iet= f.org" target=3D"_blank">draft-smiler-mpls-tp-linear-protection-mib@tools.i= etf.org</a><br> > Subject: [mpls] poll to see if we have consensus to adopt<br> > draft-smiler-mpls-tp-linear-protection-mib as a wg doc<br> ><br> </div><div><div>> Working group,<br> ><br> > This is to start a two week poll on adopting<br> > draft-smiler-mpls-tp-linear-protection-mib as an MPLS working<br> > group document.<br> ><br> > Please send your comments (support/not support) to the mpls working<br= > > group mailing list (mpls at <a href=3D"http://ietf.org" target=3D"_bla= nk">ietf.org</a>). Please give a technical<br> > motivation for your support/not support, especially if you think that<= br> > the document should not be adopted as a working group document.<br> ><br> > This poll ends February 8, 2013.<br> ><br> > There are no IPR claim against this document.<br> ><br> > All the active co-authors has stated on the working group mailing list= <br> > that they are not aware of any other IPR claims than those already<br> > disclosed. However if you are on the the mpls working group mailing<br= > > list and aware of IPR that relates to this draft, the time to disclose= <br> > this is now.<br> ><br> > /Loa<br> > (mpls wg co-chair)<br> ><br> > --<br> > --<br> ><br> ><br> > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: <a= href=3D"mailto:loa@mail01.huawei.com" target=3D"_blank">loa@mail01.huawei.= com</a><br> > MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 <a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu</a><br> > Huawei Technologies (consult) =A0 =A0 =A0 =A0phone: <a href=3D"tel:%2B= 46%20739%2081%2021%2064" value=3D"+46739812164" target=3D"_blank">+46 739 8= 1 21 64</a><br> > _______________________________________________<br> > mpls mailing list<br> > <a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org</a><b= r> > <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blan= k">https://www.ietf.org/mailman/listinfo/mpls</a><br> _______________________________________________<br> mpls mailing list<br> <a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/mpls</a><br> </div></div></blockquote></div><br></div></div></div> <br>_______________________________________________<br> mpls mailing list<br> <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/mpls</a><br> <br></blockquote></div><br></div> --f46d044306b0786e9404d4811294-- From muly_i@rad.com Thu Jan 31 01:31:36 2013 Return-Path: <muly_i@rad.com> 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 10B3821F863B for <mpls@ietfa.amsl.com>; Thu, 31 Jan 2013 01:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hii5XHGJomEE for <mpls@ietfa.amsl.com>; Thu, 31 Jan 2013 01:31:35 -0800 (PST) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id 99EED21F8633 for <mpls@ietf.org>; Thu, 31 Jan 2013 01:31:32 -0800 (PST) Received: from Internal Mail-Server by MailRelay01 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 31 Jan 2013 11:35:02 +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; Thu, 31 Jan 2013 11:31:25 +0200 From: Muly Ilan <muly_i@rad.com> To: "mpls@ietf.org" <mpls@ietf.org> Thread-Topic: [mpls] poll to see if we have consensus to adopt draft-smiler-mpls-tp-linear-protection-mib as a wg doc Thread-Index: AQHN/ULEc/IppoySSEGRkl5wk/uwqphg6QiAgADJ5gCAAAQgAIABeZ8A Date: Thu, 31 Jan 2013 09:31:24 +0000 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC87044844CA@EXRAD5.ad.rad.co.il> References: <510653DA.5050200@pi.nu> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2501E571B@szxeml558-mbs.china.huawei.com> <CA+cY5y5DP-O1BwSvApP4a7_xSdy6N8eKNUQJX=agPRwHpHRPAA@mail.gmail.com> <CAHcPYOzhTSD+1B7_+2r_17eEYZWVo5Py=6t_tL3DnD=riciXKg@mail.gmail.com> In-Reply-To: <CAHcPYOzhTSD+1B7_+2r_17eEYZWVo5Py=6t_tL3DnD=riciXKg@mail.gmail.com> 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: multipart/alternative; boundary="_000_32CB7A1F0806AB4688CE3F22C29DAC87044844CAEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A0B020C.510A39F1.009F,ss=1,fgs=0 Subject: Re: [mpls] poll to see if we have consensus to adopt draft-smiler-mpls-tp-linear-protection-mib as a wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Jan 2013 09:31:36 -0000 --_000_32CB7A1F0806AB4688CE3F22C29DAC87044844CAEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Muly From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Bin= ny Jeshan Sent: Wednesday, January 30, 2013 2:59 PM To: Krishnamurthy Mayya Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; <mpls-ads@tools.ietf.org>; d= raft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org Subject: Re: [mpls] poll to see if we have consensus to adopt draft-smiler-= mpls-tp-linear-protection-mib as a wg doc I just read the 3'rd version of the draft. I Support ! -Binny Aricent Group On 30 January 2013 18:14, Krishnamurthy Mayya <krishnamurthymayya@gmail.com= <mailto:krishnamurthymayya@gmail.com>> wrote: Support from my side ! Regards, Krishnamurthy Mayya On Wed, Jan 30, 2013 at 6:11 AM, Mach Chen <mach.chen@huawei.com<mailto:mac= h.chen@huawei.com>> wrote: Support. Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> [mailto:mpls-bo= unces@ietf.org<mailto:mpls-bounces@ietf.org>] On Behalf Of Loa > Andersson > Sent: Monday, January 28, 2013 6:33 PM > To: mpls@ietf.org<mailto:mpls@ietf.org> > Cc: <mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>>; mpls-chair= s@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>; > draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org<mailto:draft-sm= iler-mpls-tp-linear-protection-mib@tools.ietf.org> > Subject: [mpls] poll to see if we have consensus to adopt > draft-smiler-mpls-tp-linear-protection-mib as a wg doc > > Working group, > > This is to start a two week poll on adopting > draft-smiler-mpls-tp-linear-protection-mib as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org<http://ietf.org>). Please give a tec= hnical > 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 February 8, 2013. > > There are no IPR claim against this document. > > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. However if you are on the the mpls working group mailing > list and aware of IPR that relates to this draft, the time to disclose > this is now. > > /Loa > (mpls wg co-chair) > > -- > -- > > > Loa Andersson email: loa@mail01.huawei.com<mailto:= loa@mail01.huawei.com> > MPLS Expert loa@pi.nu<mailto:loa@pi.nu> > Huawei Technologies (consult) phone: +46 739 81 21 64<tel:%2B46%20= 739%2081%2021%2064> > _______________________________________________ > mpls mailing list > mpls@ietf.org<mailto:mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls --_000_32CB7A1F0806AB4688CE3F22C29DAC87044844CAEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Support<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Muly<o:p></o:p></span></p= > <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] <b>On Behalf Of </b>Binny Jeshan<br> <b>Sent:</b> Wednesday, January 30, 2013 2:59 PM<br> <b>To:</b> Krishnamurthy Mayya<br> <b>Cc:</b> mpls@ietf.org; mpls-chairs@tools.ietf.org; <mpls-ads@tools.ie= tf.org>; draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org<br> <b>Subject:</b> Re: [mpls] poll to see if we have consensus to adopt draft-= smiler-mpls-tp-linear-protection-mib as a wg doc<o:p></o:p></span></p> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I just read the 3'rd version of the draft.<o:p></o:p= ></p> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">I Support !<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">-Binny<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Aricent Group<o:p></o= :p></p> <div> <p class=3D"MsoNormal">On 30 January 2013 18:14, Krishnamurthy Mayya <<a= href=3D"mailto:krishnamurthymayya@gmail.com" target=3D"_blank">krishnamurt= hymayya@gmail.com</a>> wrote:<o:p></o:p></p> <p class=3D"MsoNormal">Support from my side !<o:p></o:p></p> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Regards,<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">Krishnamurthy Mayya<o:p></o:p></p> <div> <div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p> </o:p></p> <div> <p class=3D"MsoNormal">On Wed, Jan 30, 2013 at 6:11 AM, Mach Chen <<a hr= ef=3D"mailto:mach.chen@huawei.com" target=3D"_blank">mach.chen@huawei.com</= a>> wrote:<o:p></o:p></p> <p class=3D"MsoNormal">Support.<br> <br> Best regards,<br> Mach<o:p></o:p></p> <div> <p class=3D"MsoNormal"><br> > -----Original Message-----<br> > From: <a href=3D"mailto:mpls-bounces@ietf.org" target=3D"_blank">mpls-= bounces@ietf.org</a> [mailto:<a href=3D"mailto:mpls-bounces@ietf.org" targe= t=3D"_blank">mpls-bounces@ietf.org</a>] On Behalf Of Loa<br> > Andersson<br> > Sent: Monday, January 28, 2013 6:33 PM<br> > To: <a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org</= a><br> > Cc: <<a href=3D"mailto:mpls-ads@tools.ietf.org" target=3D"_blank">m= pls-ads@tools.ietf.org</a>>; <a href=3D"mailto:mpls-chairs@tools.ietf.org" target=3D"_blank">mpls-chairs= @tools.ietf.org</a>;<br> > <a href=3D"mailto:draft-smiler-mpls-tp-linear-protection-mib@tools.iet= f.org" target=3D"_blank"> draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org</a><br> > Subject: [mpls] poll to see if we have consensus to adopt<br> > draft-smiler-mpls-tp-linear-protection-mib as a wg doc<br> ><o:p></o:p></p> </div> <div> <div> <p class=3D"MsoNormal">> Working group,<br> ><br> > This is to start a two week poll on adopting<br> > draft-smiler-mpls-tp-linear-protection-mib as an MPLS working<br> > group document.<br> ><br> > Please send your comments (support/not support) to the mpls working<br= > > group mailing list (mpls at <a href=3D"http://ietf.org" target=3D"_bla= nk">ietf.org</a>). Please give a technical<br> > motivation for your support/not support, especially if you think that<= br> > the document should not be adopted as a working group document.<br> ><br> > This poll ends February 8, 2013.<br> ><br> > There are no IPR claim against this document.<br> ><br> > All the active co-authors has stated on the working group mailing list= <br> > that they are not aware of any other IPR claims than those already<br> > disclosed. However if you are on the the mpls working group mailing<br= > > list and aware of IPR that relates to this draft, the time to disclose= <br> > this is now.<br> ><br> > /Loa<br> > (mpls wg co-chair)<br> ><br> > --<br> > --<br> ><br> ><br> > Loa Andersson                 =        email: <a href=3D"mailto:loa@mail01.huawei.com" = target=3D"_blank"> loa@mail01.huawei.com</a><br> > MPLS Expert                 &n= bsp;               <a href=3D"mailto:loa= @pi.nu" target=3D"_blank"> loa@pi.nu</a><br> > Huawei Technologies (consult)        phone: <a hre= f=3D"tel:%2B46%20739%2081%2021%2064" target=3D"_blank"> +46 739 81 21 64</a><br> > _______________________________________________<br> > mpls mailing list<br> > <a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org</a><b= r> > <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blan= k">https://www.ietf.org/mailman/listinfo/mpls</a><br> _______________________________________________<br> mpls mailing list<br> <a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/mpls</a><o:p></o:p></p> </div> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br> _______________________________________________<br> mpls mailing list<br> <a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/mpls</a><o:p></o:p></p> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </body> </html> --_000_32CB7A1F0806AB4688CE3F22C29DAC87044844CAEXRAD5adradcoil_-- From lizho.jin@gmail.com Thu Jan 31 05:35:59 2013 Return-Path: <lizho.jin@gmail.com> 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 A558F21F8934 for <mpls@ietfa.amsl.com>; Thu, 31 Jan 2013 05:35:59 -0800 (PST) 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 WIsCbFPKvV4z for <mpls@ietfa.amsl.com>; Thu, 31 Jan 2013 05:35:59 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 71D5C21F8765 for <mpls@ietf.org>; Thu, 31 Jan 2013 05:35:58 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id b12so1239040qca.4 for <mpls@ietf.org>; Thu, 31 Jan 2013 05:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=ItgNTuwOM+4PdDnuZN7zTFt0wsGCgbKtK5k2BFmteWM=; b=Edwn/1Y/jstrtGSMYytmWTJkmf3SA76YKp2q+vmL8uG4oU/McR6uLub2dCFQOM6rd3 /F7LI7Z3ZAp8oiR5aEot7k9vfa7w1XVO9qLPiM0gZJaco40P5NOp1cvcKZYZbkTIfR/N EvNPtFgfeWOnN6DMDl4PVUv6YPik72XnYycHCnAxVk3XHQJQ0yRdTsYiSm2iX40baIIx OJNFFamBuZZWWBs66U6gyw1vffg3PZO2NwtKlGZSN00wRFzKG9u5E866QwBigrCHqxUs PFeMzgq10H982mNr16HyhsjZ77pipBhoIwUCggZ8Z1V4VgsbUu1KbgtdD1s5QSAf8qTl 5Fdg== MIME-Version: 1.0 X-Received: by 10.224.180.212 with SMTP id bv20mr8849251qab.6.1359639357780; Thu, 31 Jan 2013 05:35:57 -0800 (PST) Received: by 10.49.29.234 with HTTP; Thu, 31 Jan 2013 05:35:57 -0800 (PST) Date: Thu, 31 Jan 2013 21:35:57 +0800 Message-ID: <CAH==cJwqA6XyU4yjJmk59A1d=Z8sd2tMXSkDFEtWqJzSpN0_=w@mail.gmail.com> From: Lizhong Jin <lizho.jin@gmail.com> To: Loa Andersson <loa@pi.nu> Content-Type: multipart/alternative; boundary=20cf303b40c3f171e504d495b414 Cc: mpls@ietf.org Subject: Re: [mpls] poll to see if we have consensus to adopt draft-smiler-mpls-tp-linear-protection-mib as a wg doc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 31 Jan 2013 13:36:00 -0000 --20cf303b40c3f171e504d495b414 Content-Type: text/plain; charset=ISO-8859-1 Yes, support. Lizhong > > Message: 3 > Date: Mon, 28 Jan 2013 11:32:58 +0100 > From: Loa Andersson <loa@pi.nu> > To: "mpls@ietf.org" <mpls@ietf.org> > Cc: "<mpls-ads@tools.ietf.org>" <mpls-ads@tools.ietf.org>, > "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, > draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org > Subject: [mpls] poll to see if we have consensus to adopt > draft-smiler-mpls-tp-linear-protection-mib as a wg doc > Message-ID: <510653DA.5050200@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Working group, > > This is to start a two week poll on adopting > draft-smiler-mpls-tp-linear-protection-mib 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 a 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 February 8, 2013. > > There are no IPR claim against this document. > > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. However if you are on the the mpls working group mailing > list and aware of IPR that relates to this draft, the time to disclose > this is now. > > /Loa > (mpls wg co-chair) > > -- > -- > > > Loa Andersson email: loa@mail01.huawei.com > MPLS Expert loa@pi.nu > Huawei Technologies (consult) phone: +46 739 81 21 64 > > > --20cf303b40c3f171e504d495b414 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><div>Yes, support.</div><div><br></div><div>Lizh= ong</div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> Message: 3<br> Date: Mon, 28 Jan 2013 11:32:58 +0100<br> From: Loa Andersson <<a href=3D"mailto:loa@pi.nu">loa@pi.nu</a>><br> To: "<a href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a>" <<a h= ref=3D"mailto:mpls@ietf.org">mpls@ietf.org</a>><br> Cc: "<<a href=3D"mailto:mpls-ads@tools.ietf.org">mpls-ads@tools.iet= f.org</a>>" <<a href=3D"mailto:mpls-ads@tools.ietf.org">mpls-ads= @tools.ietf.org</a>>,<br> =A0 =A0 =A0 =A0 "<a href=3D"mailto:mpls-chairs@tools.ietf.org">mpls-ch= airs@tools.ietf.org</a>" <<a href=3D"mailto:mpls-chairs@tools.ietf.= org">mpls-chairs@tools.ietf.org</a>>,<br> =A0 =A0 =A0 =A0 <a href=3D"mailto:draft-smiler-mpls-tp-linear-protection-mi= b@tools.ietf.org">draft-smiler-mpls-tp-linear-protection-mib@tools.ietf.org= </a><br> Subject: [mpls] poll to see if we have consensus to adopt<br> =A0 =A0 =A0 =A0 draft-smiler-mpls-tp-linear-protection-mib as a wg doc<br> Message-ID: <<a href=3D"mailto:510653DA.5050200@pi.nu">510653DA.5050200@= pi.nu</a>><br> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed<br> <br> Working group,<br> <br> This is to start a two week poll on adopting<br> draft-smiler-mpls-tp-linear-protection-mib as an MPLS working<br> group document.<br> <br> Please send your comments (support/not support) to the mpls working<br> group mailing list (mpls at <a href=3D"http://ietf.org" target=3D"_blank">i= etf.org</a>). Please give a technical<br> motivation for your support/not support, especially if you think that<br> the document should not be adopted as a working group document.<br> <br> This poll ends February 8, 2013.<br> <br> There are no IPR claim against this document.<br> <br> All the active co-authors has stated on the working group mailing list<br> that they are not aware of any other IPR claims than those already<br> disclosed. However if you are on the the mpls working group mailing<br> list and aware of IPR that relates to this draft, the time to disclose<br> this is now.<br> <br> /Loa<br> (mpls wg co-chair)<br> <br> --<br> --<br> <br> <br> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: <a href= =3D"mailto:loa@mail01.huawei.com">loa@mail01.huawei.com</a><br> MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= <a href=3D"mailto:loa@pi.nu">loa@pi.nu</a><br> Huawei Technologies (consult) =A0 =A0 =A0 =A0phone: <a href=3D"tel:%2B46%20= 739%2081%2021%2064" value=3D"+46739812164">+46 739 81 21 64</a><br> <br><br></blockquote></div> --20cf303b40c3f171e504d495b414--