From stbryant@cisco.com Fri May 1 06:48:44 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD0F28C1E3 for ; Fri, 1 May 2009 06:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.697 X-Spam-Level: X-Spam-Status: No, score=-9.697 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjMKzA6zRiI9 for ; Fri, 1 May 2009 06:48:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 73E6A28C1EF for ; Fri, 1 May 2009 06:47:44 -0700 (PDT) X-Files: New Liaison Statement, "LS40 - review of the MPLS-TP "; filename*1=" Requirements draft".eml : None X-IronPort-AV: E=Sophos;i="4.40,278,1238976000"; d="scan'208";a="39600151" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 May 2009 13:49:07 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n41Dn76S018011 for ; Fri, 1 May 2009 15:49:07 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n41Dn6tS004282 for ; Fri, 1 May 2009 13:49:06 GMT Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n41Dn6n04131; Fri, 1 May 2009 14:49:06 +0100 (BST) Message-ID: <49FAFDD1.2060003@cisco.com> Date: Fri, 01 May 2009 14:49:05 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: MEAD team Content-Type: multipart/mixed; boundary="------------040907040500040006010106" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3476; t=1241185747; x=1242049747; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20[Fwd=3A=20New=20Liaison=20Statement,=20=22LS40= 20-=20review=20of=20the=20MPLS-TP=20=20=20=20=20=20=0A=20=20 =20=20Requirements=20draft=22] |Sender:=20; bh=lPwEbebeA/SLIkvHbk5r2ebc2Kln9GNQdvC5Ln83lXc=; b=A6o8RQOWHaFJ2Vs8QPQ1dJL8rJG3UhFsfkquu2/zn4ZzzMpKUwn4AR1IkC yz6zKz8bxEuvO6QdKhT52DWoeSx2RgIeosbSAtpz88YwqQVwlvV5Qs218QfZ T1QX/sF7Z1; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Mpls-interop] [Fwd: New Liaison Statement, "LS40 - review of the MPLS-TP Requirements draft"] X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 13:48:44 -0000 This is a multi-part message in MIME format. --------------040907040500040006010106 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ITU-T official response on the MPLS-TP requirements Stewart --------------040907040500040006010106 Content-Type: message/rfc822; name="New Liaison Statement, \"LS40 - review of the MPLS-TP Requirementsdraft\".eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Liaison Statement, \"LS40 - review of the MPLS-TP "; filename*1=" Requirements draft\".eml" X-Account-Key: account3 X-Mozilla-Keys: Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n41Cw8n29042 for ; Fri, 1 May 2009 13:58:09 +0100 (BST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 01 May 2009 12:58:07 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n41Cw7SK027901; Fri, 1 May 2009 05:58:07 -0700 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n41Cw78T014045; Fri, 1 May 2009 12:58:07 GMT X-from-outside-Cisco: 64.170.98.32 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsCADSP+klAqmIgjmdsb2JhbACVOYEtAQEBAQkLCAkPB7hHg38F X-IronPort-AV: E=Sophos;i="4.40,278,1238976000"; d="scan'208";a="90888988" Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-c.cisco.com with ESMTP; 01 May 2009 12:58:05 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id D9D163A7080; Fri, 1 May 2009 05:56:41 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com, loa@pi.nu, martin.vigoureux@alcatel-lucent.com Cc: sob@harvard.edu, stbryant@cisco.com, adrian.farrel@huawei.com, yoichi.maeda@ntt-at.co.jp, sjtrowbridge@alcatel-lucent.com, mpls@ietf.org, tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, betts01@nortel.com Subject: New Liaison Statement, "LS40 - review of the MPLS-TP Requirements draft" reply-to: tsbsg15@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090501125641.D9D163A7080@core3.amsl.com> Date: Fri, 1 May 2009 05:56:41 -0700 (PDT) Authentication-Results: sj-dkim-1; header.From=tsbsg15@itu.int; dkim=neutral Title: LS40 - review of the MPLS-TP Requirements draft Submission Date: 2009-05-01 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=525 Please reply by 2009-05-25 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu,martin.vigoureux@alcatel-lucent.com) Cc: sob@harvard.edu stbryant@cisco.com adrian.farrel@huawei.com yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com mpls@lists.ietf.org Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: betts01@nortel.com Purpose: For action Body: Attachment(s): LS40 - review of the MPLS-TP Requirements draft (body text) (https://datatracker.ietf.org/documents/LIAISON/file632.pdf) LS40 - attachment (https://datatracker.ietf.org/documents/LIAISON/file633.pdf) --------------040907040500040006010106-- From nurit.sprecher@nsn.com Fri May 1 07:42:24 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A745428C17D for ; Fri, 1 May 2009 07:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd78ckSCJEoM for ; Fri, 1 May 2009 07:42:23 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D83183A6CB6 for ; Fri, 1 May 2009 07:42:22 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n41EhjrH026833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 May 2009 16:43:45 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n41EhiMl011541; Fri, 1 May 2009 16:43:44 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 16:43:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9CA6B.3A8530C6" Date: Fri, 1 May 2009 16:43:35 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A7530F@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Alarm notifications v002-MB.doc Thread-Index: AcnKazT9fuo0Pl3JS3KnLw/x6gSQDw== From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "MEAD team" , "ext Malcolm Betts" X-OriginalArrivalTime: 01 May 2009 14:43:44.0736 (UTC) FILETIME=[3A6DDE00:01C9CA6B] Subject: [Mpls-interop] Alarm notifications v002-MB.doc X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 14:42:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CA6B.3A8530C6 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9CA6B.3A8530C6" ------_=_NextPart_002_01C9CA6B.3A8530C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcom, Please see my comment inside the attached. Best regards, Nurit ------_=_NextPart_002_01C9CA6B.3A8530C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Malcom,

Please see my comment inside the = attached.

Best regards,

Nurit

------_=_NextPart_002_01C9CA6B.3A8530C6-- ------_=_NextPart_001_01C9CA6B.3A8530C6 Content-Type: application/msword; name="Alarm notifications v002-MB.doc" Content-Transfer-Encoding: base64 Content-Description: Alarm notifications v002-MB.doc Content-Disposition: attachment; filename="Alarm notifications v002-MB.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPgAAAAAAAAAA EAAAQAAAAAEAAAD+////AAAAAD0AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAJWAJBAAA8BK/AAAAAAAAMAAAAAAABgAA2RgAAA4AYmpiak7gTuAAAAAAAAAAAAAAAAAAAAAA AAAJBBYANDQAACyKAQAsigEAlw0AAAAAAAAAAAAAAAAAAEEDAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAPwEAAAAAAAA/AQAAPwE AAAAAAAA/AQAAAAAAAAOBQAA8gAAAH4GAAAkAAAAogYAABQAAAAAAAAAAAAAALYGAAAAAAAAfhgA AAAAAAB+GAAAAAAAAH4YAAAAAAAAfhgAADQAAACyGAAANAAAALYGAAAAAAAAYB8AAHQBAADyGAAA AAAAAPIYAAAAAAAA8hgAAAAAAADyGAAAAAAAAPIYAAAAAAAAzRkAAAAAAADNGQAAAAAAAM0ZAAAA AAAAax4AAAIAAABtHgAAAAAAAG0eAAAAAAAAbR4AAAAAAABtHgAAAAAAAG0eAAAAAAAAbR4AAAAA AADUIAAAaAIAADwjAABWAAAAbR4AABUAAAAAAAAAAAAAAAAAAAAAAAAA/AQAABIAAADNGQAAWgAA AAAAAAAAAAAAAAAAAAAAAADNGQAAAAAAAM0ZAAAAAAAAJxoAADwAAABjGgAAIAAAAG0eAAAAAAAA AAAAAAAAAAD8BAAAAAAAAPwEAAAAAAAA8hgAAAAAAAAAAAAAAAAAAPIYAADbAAAAgh4AAFYAAABD HAAAAAAAAEMcAAAAAAAAQxwAAAAAAACDGgAAiAAAAPwEAAAAAAAA8hgAAAAAAAD8BAAAAAAAAPIY AAAAAAAAax4AAAAAAAAAAAAAAAAAAEMcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAzRkAAAAAAABrHgAAAAAAAAAAAAAAAAAAQxwAAAAAAAAAAAAA AAAAAEMcAAAAAAAA/AQAAAAAAAD8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQxwAAAAAAADyGAAAAAAAAOYYAAAMAAAAMLCTEmvK yQEAAAAAAAAAAH4YAAAAAAAACxsAAOgAAABDHAAAAAAAAAAAAAAAAAAAax4AAAAAAADYHgAAiAAA AGAfAAAAAAAAQxwAAAAAAACSIwAAAAAAAPMbAAA0AAAAkiMAAAAAAABDHAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJIjAAAAAAAAAAAAAAAAAAAABgAAfgAAAEMcAAAoAgAAzRkAAAAAAADNGQAAAAAAAEMc AAAAAAAAzRkAAAAAAADNGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzRkA AAAAAADNGQAAAAAAAM0ZAAAAAAAAbR4AAAAAAABtHgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAJxwAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM0ZAAAA AAAAzRkAAAAAAADNGQAAAAAAAGAfAAAAAAAAzRkAAAAAAADNGQAAAAAAAM0ZAAAAAAAAzRkAAAAA AAAAAAAAAAAAALYGAAAAAAAAtgYAAAAAAAC2BgAA5AgAAJoPAADkCAAAtgYAAAAAAAC2BgAAAAAA ALYGAAAAAAAAmg8AAAAAAAC2BgAAAAAAALYGAAAAAAAAtgYAAAAAAAD8BAAAAAAAAPwEAAAAAAAA /AQAAAAAAAD8BAAAAAAAAPwEAAAAAAAA/AQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADIuMi43 LiAgTG9jaw0NICAgVGhlIE1QTFMtVFAgT0FNIHRvb2xzZXQgTUFZIHByb3ZpZGUgYSBmdW5jdGlv biBlbmFibGluZyB0bw0gICBhZG1pbmlzdHJhdGl2ZWx5IHNodXQgZG93biBhIFBXLCBMU1Agb3Ig U2VjdGlvbjsgdGhhdCBpcywgdG8gc3RvcA0gICB1c2VyIHRyYWZmaWMgYmVpbmcgc2VudCBvdmVy IHRoYXQgUFcsIExTUCBvciBTZWN0aW9uLg0NVGhlIGxvY2sgZnVuY3Rpb24gTUFZIGJlIGFwcGxp ZWQgdG8gYSB1bmlkaXJlY3Rpb25hbCBvciBiaWRpcmVjdGlvbmFsIFBXLCBMU1Agb3IgU2VjdGlv bgUuICBJZiB0aGUgbG9jayBmdW5jdGlvbiBpcyBhcHBsaWVkIHRvIGJpZGlyZWN0aW9uYWwgYSBQ VywgTFNQIG9yIFNlY3Rpb24gdGhlbiBpdCBTSE9VTEQgYmUgcG9zc2libGUgdG8gY2F1c2UgaXQg dG8gYmUgYXBwbGllZCB0byBib3RoIGRpcmVjdGlvbnMuDQ0gICBUaGlzIGZ1bmN0aW9uIFNIT1VM RCBiZSBwZXJmb3JtZWQgb24tZGVtYW5kLg0NICAgVGhpcyBmdW5jdGlvbiBTSE9VTEQgYmUgcGVy Zm9ybWVkIGJldHdlZW4gRW5kIFBvaW50cyBvZiBQV3MsIExTUHMgYW5kDSAgIFNlY3Rpb25zLg0N Mi4yLjguICBBbGFybSBOb3RpZmljYXRpb24NTUI+IFdlIHNob3VsZCBicmVhayB0aGlzIGludG8g c2V2ZXJhbCBpbmRlcGVuZGVudCByZXF1aXJlbWVudHM6IG5vdGlmaWNhdGlvbiBvZiBMb2NrOiBM b2NhbC9yZW1vdGUgZmF1bHQgY2F1c2luZyBsb3NzIG9mIENDOiBXcm9uZyBDViByZWNlaXZlZAUg PG5vdCBzdXJlIGlmIHdlIG5lZWQgdGhpcywgaXRzIGltcGxpY2l0IGluIDIuMi4zPi4NDTIuMi44 YSBOb3RpZmljYXRpb24gb2YgTG9jawUNDSAgIFRoZSBNUExTLVRQIE9BTSB0b29sc2V0IE1VU1Qg cHJvdmlkZSBhIGZ1bmN0aW9uIHRvIGVuYWJsZSBzZXJ2ZXJ0aGUNICAgbGF5ZXIgRW5kIFBvaW50 cyBQb2ludCBhdCB0aGUgaW5ncmVzcyB0byBub3RpZnkgYSBmYXVsdCBjb25kaXRpb24gb3IgYW4g YWRtaW5pc3RyYXRpdmUNICAgbG9ja2luZyB0byB0aGUgY2xpZW50IGxheWVydGhlIEVuZCBQb2lu dHMgYXQgdGhlIGVncmVzcyBhZmZlY3RlZCBieSB0aGlzIHN0YXR1c3RoYXQgdGhlIGxvY2sgZnVu Y3Rpb24gaXMgYWN0aXZlLiAgVGhlIGVncmVzcyBlbmQgcG9pbnRzIE1VU1Qgbm90aWZ5IHRoZSBs b2NhbCBjbGllbnQgbGF5ZXIgdGhhdCB0aGUgc2VydmVyIGxheWVyIFBXLCBMU1Agb3IgU2VjdGlv biBoYXMgYmVlbiBsb2NrZWQuICAgVGhpcw0gICB3b3VsZCBlbmFibGUgdG8gc3VwcHJlc3MgYWxh cm1zIHRoYXQgbWF5IGJlIGdlbmVyYXRlZCBpbiB0aGUgY2xpZW50DSAgIGxheWVyIGFzIGEgcmVz dWx0IG9mIHRoZSBmYXVsdCBjb25kaXRpb24gb3Igb2YgdGhlIGFkbWluaXN0cmF0aXZlDSAgIGxv Y2tpbmcgaW4gdGhlIHNlcnZlciBsYXllci4NTUI+IEhvdyB0aGlzIGlzIHVzZWQgaXMgb3V0IG9m IHNjb3BlIGZvciB0aGlzIGRyYWZ0Lg0NICAgVGhlIE1QTFMtVFAgT0FNIHRvb2xzZXQgTVVTVCBh bGxvdyBmb3IgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gYQ0gICBmYXVsdCBjb25kaXRpb24gYW5k IGFuIGFkbWluaXN0cmF0aXZlIGxvY2tpbmcgYWN0aW9uLg1NQj4gTm90IHN1cmUgd2UgbmVlZCB0 aGlzIGlmIHdlIHNlcGFyYXRlIHRoZSByZXF1aXJlbWVudHMuDQ0gICBUaGUgc2VydmVyIGxheWVy IEVuZCBQb2ludHMgZ2VuZXJhdGluZyB0aGUgbm90aWZpY2F0aW9uIGFuZCB0aGUNICAgY2xpZW50 IGxheWVyIEVuZCBQb2ludHMgcmVjZWl2aW5nIHRoZSBub3RpZmljYXRpb24gbWF5IG9yIG1heSBu b3QgYmUNICAgdGhlIHNhbWUgbm9kZXMuICBBIG1lY2hhbmlzbSBNVVNUIGJlIHByb3ZpZGVkIHRv IHN1cHBvcnQgYm90aCBjYXNlcy4NDSAgIFRoaXMgZnVuY3Rpb24gU0hPVUxEIGJlIHBlcmZvcm1l ZCBwcm8tYWN0aXZlbHkuDQ0gICBUaGlzIGZ1bmN0aW9uIFNIT1VMRCBiZSBwZXJmb3JtZWQgYmV0 d2VlbiB0aGUgRW5kIFBvaW50cyBvZiBQV3MsIExTUHMNICAgYW5kIFNlY3Rpb25zIGFuZCB0aGUg RW5kIFBvaW50cyBvZiB0aGUgUFdzIGFuZC9vciBMU1BzIGFmZmVjdGVkIGJ5DSAgIHRoZSBmYXVs dCBjb25kaXRpb24gb3IgYWRtaW5pc3RyYXRpdmUgbG9ja2luZy4NDTIuMi44YiBEaWZmZXJlbnRp YXRpb24gYmV0d2VlbiBsb2NhbCBhbmQgcmVtb3RlIGZhdWx0cwUuDQ1XaGVuIGFuIE1QTFMtVFAg b3IFIFBXIGVuZCBwb2ludCBkZXRlY3RzIGEgY29udGludWl0eSBjaGVjayBkZWZlY3QgaXQgTVVT VCBwcm92aWRlIGEgbG9jYWwgaW5kaWNhdGlvbiB0byBhbnkgY2xpZW50cyBhbmQgdGhlIG1hbmFn ZW1lbnQgZnVuY3Rpb24FLiBJdCBNVVNUIGFsc28gaW5kaWNhdGUgaWYgdGhlIGZhdWx0IGNhdXNp bmcgdGhpcyBpcyBsb2NhbCAoaS5lLiB3aXRoaW4gdGhlIG5vZGUgY29udGFpbmluZyB0aGUgZW5k IHBvaW50KSBvciByZW1vdGUuDQ0yLjIuOGMgQ29ubmVjdGl2aXR5IHZlcmlmaWNhdGlvbiBmYWls dXJlDQ1XaGVuIGFuIE1QTFMtVFAgb3IgUFcgZW5kIHBvaW50IGRldGVjdHMgYSBjb250aW51aXR5 IHZlcmlmaWNhdGlvbiBkZWZlY3QgaXQgTVVTVCBwcm92aWRlIGEgbG9jYWwgaW5kaWNhdGlvbiB0 byBhbnkgY2xpZW50cyBhbmQgdGhlIG1hbmFnZW1lbnQgZnVuY3Rpb24uIEl0IE1VU1QgYWxzbyBw cm92aWRlIHRoZSBjYXBhYmlsaXR5IHRvIHNodXQgZG93biB0aGUgUFcsIExTUCBvciBTZWN0aW9u OyB0aGF0IGlzLCBzdG9wIHVzZXIgdHJhZmZpYyBiZWluZyBzZW50IGZyb20gdGhhdCBQVywgTFNQ IG9yIFNlY3Rpb24uDQ0NMi4yLjkuICBDbGllbnQgRmFpbHVyZSBJbmRpY2F0aW9uDQ0gICBUaGUg TVBMUy1UUCBPQU0gdG9vbHNldCBNVVNUIHByb3ZpZGUgYSBmdW5jdGlvbiB0byBlbmFibGUgdGhl DSAgIHByb3BhZ2F0aW9uIG9mIGNsaWVudCBmYXVsdCBjb25kaXRpb24gZGV0ZWN0ZWQgYXQgdGhl IGluZ3Jlc3MgdG8gYSBQVywgTFNQIG9yIFNlY3Rpb25pbmZvcm1hdGlvbiwgYWNyb3NzIHRoZSBN UExTLVRQDSAgIG5ldHdvcmssIGlmIHRoZSBjbGllbnQgbGF5ZXIgT0FNIG1lY2hhbmlzbXMgZG8g bm90IHByb3ZpZGUgYW4gYWxhcm0NICAgbm90aWZpY2F0aW9uL3Byb3BhZ2F0aW9uIG1lY2hhbmlz bS4NTUI+IFRoZQUgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCB0aGUgdG9vbCBzaG91bGQgYmUgY2xp ZW50IGluZGVwZW5kZW50LCB3ZSBjYW4sIG9uIGEgY2FzZSBieSBjYXNlIGJhc2lzIGZvciBlYWNo IGNsaWVudCBkZWNpZGUgaWYgd2Ugd2lsbCB1c2UgdGhpcyB0b29sLiAgTXkgdm90ZSB3b3VsZCBi ZSB0byBhbHdheXMgdXNlIHRoaXMgdG9vbCBzaW5jZSBpdCBwcm92aWRlcyBjb25zaXN0ZW50IGNs aWVudCBpbmRlcGVuZGVudCBvcGVyYXRpb24uDQ0gICBUaGlzIGZ1bmN0aW9uIFNIT1VMRCBiZSBw ZXJmb3JtZWQgcHJvLWFjdGl2ZWx5Lg0NICAgVGhpcyBmdW5jdGlvbiBTSE9VTEQgYmUgcGVyZm9y bWVkIGJldHdlZW4gRW5kIFBvaW50cyBvZiBQV3MsIExTUHMgYW5kDSAgIFNlY3Rpb25zLg0NBVRo aXMgaXMgYSBnZW5lcmFsIHJlcXVpcmVtZW50IGZvciBhbGwgZnVuY3Rpb25zLiBXZSBhc2tzIGZv ciBhIGNvbnNpc3RlbnQgT0FNIGZ1bmN0aW9uYWxpdHkgYXQgZGlmZmVyZW50IG5lc3QgbGF5ZXJz LiBXZSBkbyBub3QgbmVlZCB0byBtZW50aW9uIGl0IHNwZWNpZmljYWxseSBpbiB0aGlzIGNhc2Uu IA0FSSBwcm9wb3NlIHRvIHNlcGFyYXRlIG9pdCB0byB0d28gZnVuY3Rpb25zOiBMb2NrIG5vdGlm aWNhdGlvbiwgYW5kIGFsYXJtIG5vdGlmaWNhdGlvbi4gSSBkbyBub3Qgc2VlIGFueSBiZW5lZml0 IGluIHB1dHRpbmcgdGhlbSBpbiBvbmUgc2VjdGlvbi4gSXQgaXMgbGlrZSBDQyBhbmQgQ1YsIHR3 byBmdW5jdGlvbnMuIA0FSSBwcm9wb3NlIHRvIG5hbWUgaXQgk0xvY2sgTm90ZmljaWF0aW9ulA0F V2UgbmVlZCBhIGZ1bmN0aW9uIJNBbGFybSBOb3RpZmljYXRpb26UDQVJIGd1ZXNzIHlvdSBtZWFu IE1QTFMtVFAgTFNQDQVUaGlzIGlzIHBhcnQgb2YgdGhlIENDIGZ1bmN0aW9uLiBJIHdvdWxkIGxp a2UgdG8gc2VlIGEgZGVzY3JpcHRpb24gb2YgdGhlIGZ1bmN0aW9uIJNhbGFybSBub3RpZmljYXRp b26ULiBXaXRob3V0IHN1Y2ggYSBmdW5jdGlvbiwgSSBkbyBub3Qgc2VlIGEgd2F5IGZvciBhIGNs aWVudCBsYXllciB0byBpZGVudGlmeSBhIJNyZW1vdGUgY2FsbJQuIA1JIHRoaW5rIHRoZSBvcmln aW5hbCBkZXNjcmlwdGlvbiBpbiB0aGUgZG9jdW1lbnQgb24gYWxhcm0gbm90aWZpY2F0aW9uIGlz IGdvb2QgYW5kIEkgd291bGQgbGlrZSB0byBrZWVwIGl0LiANBUkgZG8gbm90IHVuZGVyc3RhbmQg eW91ciBjb21tZW50LiBQbGVhc2UgY2xhcmlmeS4gDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAADJCAAAyggAAMsI AADTCAAA7wgAAPEIAAD0CAAAAAkAAAIJAAARCQAAIwkAACQJAABKCQAAWAkAAFoJAABsCQAAdQkA AHsJAACHCQAAtQkAALYJAABaCgAAXgoAAHgKAACLCgAAmAoAAJkKAADoCgAA6QoAAOoKAAAbCwAA HAsAAB0LAAAeCwAA+e/l2+XRx+XR5bqq26Dbk9uJ24mC+X11cHVwdapwaGT5YAAAAAAAAAAAAAAA AAAAAAAAAAYWaMcYzAAABhZoM3hlAAAPDCoDFWhtDXcAFmhtDXcACQwqBxZobQ13AA8MKgcVaNgb ygAWaNgbygAJDCoHFmjDCyIADBVoujsiABZo5V2sAAATAQiBBEgBAAVoyPPUhhZo5V2sABkBCIEE SAEABWjH89SGFWi6OyIAFmjlXawAEwEIgQRIAQAFaM/z1IYWaDN4ZQAfA2oAAAAAFmhTc9EAMEoR AE9KAABRSgAAVQgBXkoAABkBCIEESAEABWjG89SGFWi6OyIAFmjlXawAEwEIgQRIAQAFaMXz1IYW aDN4ZQATAQiBBEgBAAVoxvPUhhZo5V2sABMBCIEESAEABWjH89SGFmjlXawAEwEIgQRIAQAFaMXz 1IYWaOVdrAATAQiBBEgBAAVoxfPUhhZopWt3AAwVaLo7IgAWaKVrdwAiAAYAAA0IAAAOCAAATAgA AJEIAADKCAAAywgAALYJAAC3CQAA5wkAAOgJAAAxCgAAPgoAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAA AGoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAARw8AQyQBRcaAAAABAMXz1IYAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZOVdrAAA Rw8AQyQBRcaAAAABAMXz1IYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZKVrdwAABA8AZ2Sla3cAAAwABgAAlxUAANgYAAD9/QAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBAj4KAAA/CgAAWgoAAB0LAAAe CwAAOwsAADwLAACDCwAA3QsAAMwMAAATDQAAWA0AAHgNAACtDQAArg0AAPINAAArDgAAZg4AAGcO AACqDgAA8g4AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEcP AEMkAUXGgAAAAQDK89SGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2Sla3cAAAQPAGdkpWt3AAAUHgsAADkLAAA6CwAAOwsAADwL AAB5CwAAfwsAAIILAACGCwAAjAsAAJALAACXCwAAnAsAAKsLAACsCwAAtgsAAMsLAADvCwAA+wsA AP4LAAAKDAAAGAwAACgMAAD15dvX0Las0LbQlol/idBllmVb0FE7AAAAACsACIEVaLo7IgAWaKVr dwAXaOVdrABjSAEAZGgAAAAAZGgAAAAAZGjM89SGEwEIgQRIAQAFaNDz1IYWaDN4ZQATAQiBBEgB AAVoy/PUhhZoM3hlADMACIEVaLo7IgAWaKVrdwAXaOVdrABjSAEAY0gAAGNIAQBkaAAAAABkaAAA AABkaMvz1IYTAQiBBEgBAAVoy/PUhhZo5V2sABkBCIEESAEABWjL89SGFWi6OyIAFmjlXawAKwAI gRVoujsiABZopWt3ABdo5V2sAGNIAQBkaAAAAABkaAAAAABkaMvz1IYTAQiBBEgBAAVoyvPUhhZo 5V2sADMACIEVaLo7IgAWaKVrdwAXaOVdrABjSAEAY0gAAGNIAQBkaAAAAABkaAAAAABkaMrz1IYM FWi6OyIAFmila3cAAAYWaOVdrAAAEwEIgQRIAQAFaMrz1IYWaMMLIgAfA2oAAAAAFmhTc9EAMEoR AE9KAABRSgAAVQgBXkoAABMBCIEESAEABWik8tSGFmjDCyIAABYoDAAALwwAAE8MAABQDAAAaAwA AGwMAAChDAAAswwAAMQMAADFDAAAdw0AAHgNAACsDQAArQ0AACoOAAArDgAAZQ4AAGYOAAAFEAAA GBAAADAQAAAxEAAAOBAAAOXb1NvK272zo42JgXrUiXJr1FXUS0EAAAAAAAAAAAAAAAAAAAAAEwEI gQRIAQAFaKjy1IYWaHwFlgATAQiBBEgBAAVoqPLUhhZopWt3ACsACIEVaLo7IgAWaKVrdwAXaMML IgBjSAEAZGgAAAAAZGgAAAAAZGin8tSGDBVoujsiABZoT0ezAAAPDCoHFWhPR7MAFmhPR7MADBVo ujsiABZowwsiAAAPDCoHFWjDCyIAFmjDCyIABhZopWt3AAArAAiBFWi6OyIAFmila3cAF2jDCyIA Y0gBAGRoAAAAAGRoAAAAAGRopfLUhh8BCIEESAEABWil8tSGFWi6OyIAFmjDCyIAF2jDCyIAEwEI gQRIAQAFaM3z1IYWaOVdrAAZAQiBBEgBAAVozfPUhhVoujsiABZo5V2sABMBCIEESAEABWjQ89SG FmgzeGUADBVoujsiABZopWt3AAATAQiBBEgBAAVozPPUhhZo5V2sADMACIEVaLo7IgAWaKVrdwAX aOVdrABjSAEAY0gAAGNIAQBkaAAAAABkaAAAAABkaMzz1IYAFvIOAAA6DwAAOw8AAG4PAABvDwAA uA8AAP4PAAAwEAAAMRAAAGoQAABrEAAAchEAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEcPAEMkAUXGgAAAAQCw8tSGAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2Sla3cAAEcPAEMk AUXGgAAAAQCo8tSGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAZ2Sla3cAAAQPAGdkpWt3AAALOBAAAGcQAABoEAAAaRAAAGoQAAB6 EAAAfRAAAH4QAACBEAAAjBAAAJUQAACWEAAAphAAAKcQAACtEAAAsRAAANEQAADUEAAA6BAAAPsQ AAD8EAAAABEAAAERAAAmEQAAcxEAAHoRAACbEQAAnBEAAJ0RAAC9EQAAxhEAAN8RAADlEQAAORIA AFsSAAD15fXb9dHl0fXHvbOpx6mflZ+V5ZWfqb2LgXeBbWNtY21ZAAAAABMBCIEESAEABWjL8tSG FmhtDXcAEwEIgQRIAQAFaNLz1IYWaDN4ZQATAQiBBEgBAAVoyfLUhhZobQ13ABMBCIEESAEABWjH 8tSGFmhPR7MAEwEIgQRIAQAFaMfy1IYWaG0NdwATAQiBBEgBAAVotfLUhhZoT0ezABMBCIEESAEA BWjG8tSGFmhtDXcAEwEIgQRIAQAFaMXy1IYWaG0NdwATAQiBBEgBAAVos/LUhhZoT0ezABMBCIEE SAEABWiy8tSGFmhPR7MAEwEIgQRIAQAFaLTy1IYWaE9HswATAQiBBEgBAAVo0fPUhhZoM3hlABMB CIEESAEABWjI8tSGFmhtDXcAEwEIgQRIAQAFaLDy1IYWaHwFlgAfA2oAAAAAFmhTc9EAMEoRAE9K AABRSgAAVQgBXkoAABMBCIEESAEABWiw8tSGFmhPR7MAACJyEQAAcxEAAJwRAACdEQAAwhIAALcA AAAAAAAAAAAAAAC3AAAAAAAAAAAAAAAAbwAAAAAAAAAAAAAAACcAAAAAAAAAAAAAAAAAAAAAAAAA Rw8AQyQBRcaAAAABAMry1IYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZG0NdwAARw8AQyQBRcaAAAABAMfy1IYAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZKVr dwAARw8AQyQBRcaAAAABALTy1IYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZKVrdwAABFsSAABcEgAAZhIAAGkSAACLEgAAjBIA AKQSAACoEgAAwhIAAMMSAADEEgAAURMAAG4TAACAEwAAixMAAKoTAAAMFAAADRQAAA4UAAAVFAAA FhQAAAoVAAALFQAAlhUAAJcVAACYFQAARxYAAEgWAAD+FgAA/xYAACgXAAD16N7o1OjU6N7Nxryv mcaDxn93Z3dgxlxSTlJOUk4AAAYWaDkggAAAEwNqAAAAABZoOSCAADBKEQBVCAEGFmjqUDwAAAwV aLo7IgAWaNgbygAAHwNqAAAAABZoOSCAADBKEQBPSgAAUUoAAFUIAV5KAAAPDCoHFWjYG8oAFmjY G8oABhZopWt3AAArAAiBFWi6OyIAFmila3cAF2jYG8oAY0gBAGRoAAAAAGRoAAAAAGRonfLUhisA CIEVaLo7IgAWaKVrdwAXaAcRfQBjSAEAZGgAAAAAZGgAAAAAZGjX89SGGQEIgQRIAQAFaNfz1IYV aLo7IgAWaAcRfQATAQiBBEgBAAVo1/PUhhZoBxF9AAwVaLo7IgAWaKVrdwAADBVoujsiABZofAWW AAATAQiBBEgBAAVoyvLUhhZobQ13ABMBCIEESAEABWjL8tSGFmhtDXcAGQEIgQRIAQAFaMry1IYV aLo7IgAWaG0NdwATAQiBBEgBAAVoyfLUhhZobQ13AAAewhIAAMMSAADEEgAA5hIAAOcSAAAoEwAA oBMAAOcTAAAOFAAACxUAAAwVAAA/FQAAQBUAAIkVAACWFQAAlxUAAEcWAAD+FgAAKBcAAFEXAACu AAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAqQAAAAAA AAAAAAAAAKkAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAKkAAAAAAAAAAAAA AACpAAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAqQAA AAAAAAAAAAAAAKcAAAAAAAAAAAAAAAClAAAAAAAAAAAAAAAApQAAAAAAAAAAAAAAAKUAAAAAAAAA AAAAAAClAAAAAAAAAAAAAAAAAAAAAAESAAABAAAABA8AZ2Sla3cAUQ8AQyQBRcaAAAABAMvy1IYA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABnZDkggABvxgcBAgBpDNWmZCYBAyQBYSQBABMoFwAAKRcAAFEXAABSFwAAbxcAAHAXAACj GAAApBgAANcYAADYGAAA2RgAAPXx9fH18fXx7ekAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhZo6lA8AAAGFmjdUnIA AAYWaDkggAAAEwNqAAAAABZoOSCAADBKEQBVCAEAClEXAABvFwAANhgAAKMYAADXGAAA2BgAANkY AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9gAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAABBIAZ2RTc9EAAAESAAAGMgAxkGgBOnBzS6IAH7DQLyCw4D0hsKAFIrCg BSOQoAUkkKAFJbAAABew0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACGAhQAEgABAJwADwAEAAAAAwAAAAAABAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAABA8f8C AEQADAAAAAAAAAAAAAYATgBvAHIAbQBhAGwAAAACAAAAHABDShgAX0gBBGFKGABtSAkQbkgRBHNI CRB0SBEEAAAAAAAAAAAAAAAAAAAAAAAARABBQPL/oQBEAAwBAAAAAAAAAAAWAEQAZQBmAGEAdQBs AHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaQDz/7MAUgAMAQAAAAAAAAAA DABUAGEAYgBsAGUAIABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMA AAIACwAAACgAawD0/8EAKAAAAQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAAAAAAAABEAFpA AQDyAEQADAQAAKVrdwAAAAoAUABsAGEAaQBuACAAVABlAHgAdAAAAAIADwAUAENKFABPSgQAUUoE AF5KBABhShQASACZQAEAAgFIAAwFAABTc9EAAAAMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAA AgAQABQAQ0oQAE9KBQBRSgUAXkoFAGFKEABCACdAogARAUIADAUAAFNz0QAAABEAQwBvAG0AbQBl AG4AdAAgAFIAZQBmAGUAcgBlAG4AYwBlAAAACABDShAAYUoQADwAHkABACIBPAAMBQAAU3PRAAAA DABDAG8AbQBtAGUAbgB0ACAAVABlAHgAdAAAAAIAEgAIAENKFABhShQAQABqQCEBIgFAAAwFAABT c9EAAAAPAEMAbwBtAG0AZQBuAHQAIABTAHUAYgBqAGUAYwB0AAAAAgATAAYANQiBXAiBCABzAHAA cgBlAGMAaABlAHIAIwEAAOgCAAA5AwAAZwgAAH0IAAD7CAAAFQwAANkQAAABAHMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGKxpQ0BAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO6xpQ0BAHMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJ6xpQ0BAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANOxpQ0BAHMAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAFqypQ0BAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWypQ0BAHMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAPmypQ1kDNWmAAAAAAAAAAAAAAAAAABmDNWmAAAAAAAAAAAA AAAAAABkDNWmAAAAAAAAAAAAAAAAAABlDNWmAAAAAAAAAAAAAAAAAABnDNWmAAAAAAAAAAAAAAAA AABpDNWmAAAAAAAAAAAAAAAAAABqDNWmAAAAAAAAAAAAAAAAAAAAAAAAsAAAAGcBAACRAQAAugEA ANgBAAAMAwAAQAMAAEMDAAAAAAAA2RAAAAYAADQAAAUA/////wAAAAANAAAADgAAAEwAAACRAAAA ygAAAMsAAAC2AQAAtwEAAOcBAADoAQAAMQIAAD4CAAA/AgAAWgIAAB0DAAAeAwAAOwMAADwDAACD AwAA3QMAAMwEAAATBQAAWAUAAHgFAACtBQAArgUAAPIFAAArBgAAZgYAAGcGAACqBgAA8gYAADoH AAA7BwAAbgcAAG8HAAC4BwAA/gcAADAIAAAxCAAAaggAAGsIAAByCQAAcwkAAJwJAACdCQAAwgoA AMMKAADECgAA5goAAOcKAAAoCwAAoAsAAOcLAAAODAAACw0AAAwNAAA/DQAAQA0AAIkNAACWDQAA lw0AAEcOAAD+DgAAKA8AAFEPAABvDwAANhAAAKMQAADXEAAA2hAAAJpAAAAPMAAAAAAAAAEAAAAA AAAAAMAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJhAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA ABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAI AFjRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAiAFY0QAwADAAAAAAAAABAAAAAAAAAAAAAAAAAIgB WNEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACAAZhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY QAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAEACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmEAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAQAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYQAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJhAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAEACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmEAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAQAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAIAFjRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAgAGYQAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmkAAABIwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAASMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYQAAAEjAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABIwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJhAAAASMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAEjAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAABIwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAASMAAAAAAAAACAAAAAgAAAAAAA AAAAAAQKAAAAADAAAAAAAAAAAAAAAAAfMA4DAAAAAAAHAAAAAA0AAAAOAAAATAAAAJEAAADKAAAA ywAAALYBAAC3AQAA5wEAAOgBAAAxAgAAPgIAAD8CAABaAgAAHQMAAB4DAAA7AwAAPAMAAIMDAADd AwAAzAQAABMFAABYBQAAeAUAAK0FAACuBQAA8gUAACsGAABmBgAAZwYAAKoGAADyBgAAOgcAADsH AABuBwAAbwcAALgHAAD+BwAAMAgAADEIAABqCAAAawgAAHIJAABzCQAAnAkAAJ0JAADCCgAAwwoA AMQKAADmCgAA5woAACgLAACgCwAA5wsAAA4MAAALDQAADA0AAD8NAABADQAAiQ0AAJYNAACXDQAA Rw4AAP4OAAAoDwAAUQ8AAG8PAAA2EAAAoxAAANcQAADaEAAAmEAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAB5hAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAEACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAZhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAH mEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAeY QAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmEAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYQAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYQAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAQAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAGYQAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAZhAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAEACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmEAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAQAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYQAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAgACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmEAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAACAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAIgAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJhAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAgAeYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmEAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAACAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYQAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAIAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJhAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAdY0QAwADAAAAAAAAABAAAAAAAAAAAAAAAAAAAHWNEAMAAwAAAAAAAAAQAAAAAAAAAAAAAA AACAAVjRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAgAFY0QAwADAAAAAAAAABAAAAAAAAAAAAAAAA AIABWNEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACAAVjRADAFMAAAAAAAAAEAAAACAAAAAAAAAAAA AAFY0QAwADAAAAAAAAABAAAAAAAAAAAAAAAAAIABWNEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACA BwgAAAAAMAAAAAAAAAAAAAAAAB8wjgMAAAAAAAcABgAAHgsAACgMAAA4EAAAWxIAACgXAADZGAAA DQAAABEAAAASAAAAFAAAABYAAAAYAAAAAAYAAD4KAADyDgAAchEAAMISAABRFwAA2RgAAA4AAAAQ AAAAEwAAABUAAAAXAAAAGQAAAAAGAADYGAAADwAAAA8AAPA4AAAAAAAG8BgAAAACBAAAAgAAAAEA AAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEA AAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQA AAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQD CQAAAD8DAQABAAAAEfAEAAAAAQAAAP//BwAKAAAAAAFisaUN/////wAAAAHusaUN/////wAAAAGe saUN/////wAAAAHTsaUN/////wAAAAFasqUN/////wAAAAFFsqUN/////wAAAAH5sqUN/////xwB AADgAgAANQMAAGEIAAB7CAAA8wgAABIMAACZDQAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAA ACMBAADoAgAAOQMAAGcIAAB9CAAA+wgAABUMAACZDQAAAAAAACMCAAAmAgAAKAIAACwCAACuBwAA sQcAALMHAAC3BwAA4gcAAOUHAADtBwAA8QcAAHsNAAB+DQAAgA0AAIQNAACXDQAAXg4AAGEOAAAa DwAAJg8AANoQAAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABwAcAAcAHAAHAAAA AAAFAAAADAAAAE8AAABfAAAAlAAAAJgAAAA0AgAAPQIAAEQCAABMAgAAXgIAAGACAAD7AwAA/gMA APUFAAD6BQAArQYAALMGAAD1BgAA+AYAALsHAAC+BwAAAQgAAAQIAAAxCAAAaQgAAMkKAADSCgAA KwsAADYLAACjCwAAqgsAAIwNAACVDQAAlw0AAKQQAADGEAAA2hAAAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAHAAQA BwAAAAAAjA0AAJYNAACXDQAA2A4AAP0OAADGEAAA1hAAANoQAAAHAAUABwAHAAUABwAFAAcAAAAA AJcNAACtEAAAtxAAANoQAAAHAAcABAAHAIQAAAAEAAAACAAAAOUAAAAAAAAAgwAAAJdyAADnXgEA +wkEAEU2CQCdTgwACzQQAB9TEADfBRMAYXETAKsHFABaHhYAghAYAAN2GgBXSxsATgYeAHs5HgC1 BSAAwwsiAJcdIwAkSCMAlUYmAOU9KAB+KCkAxBQyABoqMwCcYTMA/lM0ACB6NQBNEzcAhT04ACJe OQDqUDwAlns8AAtPPQBlGD8Ac3tAAKEXQQCTREIALipDAPwdRwBcb0gAGV5JAN0yTAC8CE0AYVNX AFhsVwDCb1oAyFlcAHwIXQB4HF4AiXVeAD8YYgBkFWQAgHVlADN4ZQCybGYAEDFnAA5CZwB7U2sA WittAOcpbgDZW3AAv0JxAEczcgDdUnIAQW1yANogcwAYDHQA7090AKdEdQBtDXcApWt3AKIceACa MHwAbFd8AAcRfQDCWH8AOSCAABdxhADVVYcAEFWJAKlkjABlQo0A3mqNAFcKjwBTF5EAsSyRAHwF lgDnK5YAkFmfAFh5oQBiG6IANyuiAHNLogBCbqMADCqqAOVdrAALCrMAT0ezAMN7tACJN7UA5zC2 ADlgugD0ZbsAjlzAAJFRwQDydMEAgxjKANgbygDtaMoAxxjMALhTzQANDM4AU3PRAEAB1ADTAtQA 9DHVAJMN2gA+HtsAoTfcADgH4ABsDeAANV7hAA9p4wDdROgA2mzpAHwi7ADqFO0AjVnvAE0Q8gBc bfMAKGP1AP9AAhAAAAAAAAAA2RAAAGAAABAAQAAA//8EAAAABwBVAG4AawBuAG8AdwBuAA0ATQBh AGwAYwBvAGwAbQAgAEIAZQB0AHQAcwAIAHMAcAByAGUAYwBoAGUAcgAIAHMAcAByAGUAYwBoAGUA cgD//wQACAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAwAaAHMAcAByAGUAYwBoAGUAcgAy ADAAMAA5ADAANQAwADEAVAAxADcAMQA4ADEANgA3ADcANABSDNWmAAADAP//BAAAAAAAAAAAAAAA //8AAAIA//8AAAAA//8AAAIA//8AAAAABgAAAEcWkAEAAAICBgMFBAUCAwSHegAgAAAAgAgAAAAA AAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYC BQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSH egAgAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAABHNZABgAoCAgYJBAIFCAMEvwIAoPv8 x2gQAAAAAAAAAJ8AAgAAAAAATQBTACAATQBpAG4AYwBoAG8AAAAt/zP/IAAOZh1nAAA/NZABAAAC BwMJAgIFAgQEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAA NSaQAQAAAgsGBAMFBAQCBId6AGEAAACACAAAAAAAAAD/AQEAAAAAAFQAYQBoAG8AbQBhAAAAIgAE AHGIiBgA8NACAABoAQAAAAD18tSGaQzVpgAAAAAGAFMAAAAHAgAAkAsAAAEABgAAAAQAAxAYAAAA BwIAAJALAAABAAYAAAAYAAAAAAAAACADAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAF oAW0ALQAgYEyNAAAEAAZAGQAAAAZAAAAkQ0AAJENAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAATKDUQDwEAAIAAMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJUAAAAAAp8P8PAQABPwAA5AQAAMkAAAD///9///// fwAAAAD///9/////f////3+la3cAAAAAADIAAAAAAAAAAAAAAAAAAQAAAP//EgAAAAAAAAABADIA AAAAAAAADQBNAGEAbABjAG8AbABtACAAQgBlAHQAdABzAAgAcwBwAHIAZQBjAGgAZQByAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAA AAB4AQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAApAAAAAQAAACwAAAABQAAAMgAAAAGAAAA1AAA AAcAAADgAAAACAAAAPQAAAAJAAAACAEAABIAAAAUAQAACgAAADQBAAAMAAAAQAEAAA0AAABMAQAA DgAAAFgBAAAPAAAAYAEAABAAAABoAQAAEwAAAHABAAACAAAA5wQAAB4AAAAEAAAAMgAAAB4AAAAE AAAAAAAAAB4AAAAQAAAATWFsY29sbSBCZXR0cwAAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4A AAAMAAAATm9ybWFsLmRvdAAAHgAAAAwAAABzcHJlY2hlcgAAAAAeAAAABAAAADYAAAAeAAAAGAAA AE1pY3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAAsk+YCwAAAEAAAAAAPmAQccnJAUAAAAAAJj3Y asrJAQMAAAABAAAAAwAAAAcCAAADAAAAkAsAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA9AAAAAwA AAABAAAAaAAAAA8AAABwAAAABQAAAIgAAAAGAAAAkAAAABEAAACYAAAAFwAAAKAAAAALAAAAqAAA ABAAAACwAAAAEwAAALgAAAAWAAAAwAAAAA0AAADIAAAADAAAANYAAAACAAAA5wQAAB4AAAAQAAAA Tm9ydGVsIE5ldHdvcmtzAAMAAAAYAAAAAwAAAAYAAAADAAAAkQ0AAAMAAAAPJwsACwAAAAAAAAAL AAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAIAAAAyAAwQAAACAAAAHgAAAAYAAABUaXRs ZQADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAC AAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAA AAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAA/v///xwAAAAdAAAAHgAA AB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAA /v///y4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAD+////NgAAADcAAAA4AAAAOQAAADoAAAA7 AAAAPAAAAP7////9////PwAAAP7////+/////v////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////UgBvAG8A dAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAAOGhEmvKyQFBAAAA gAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAADgACAf////8FAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABsAAACSIwAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAQAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQ0AAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBm AG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtAAAAABAAAAAAAAAFAEQAbwBj AHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAA OAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADUAAAAA EAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AQD+/wMKAAD/ ////BgkCAAAAAADAAAAAAAAARh8AAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgRG9jdW1lbnQACgAA AE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------_=_NextPart_001_01C9CA6B.3A8530C6-- From BETTS01@nortel.com Fri May 1 11:23:22 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004933A6D80 for ; Fri, 1 May 2009 11:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qt+iiv8oTyDZ for ; Fri, 1 May 2009 11:23:20 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 911E43A6927 for ; Fri, 1 May 2009 11:23:20 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n41IOf723552; Fri, 1 May 2009 18:24:41 GMT 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: Fri, 1 May 2009 14:24:34 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516FDACA5@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of MPLS-TP OAMrequirements Thread-Index: AcnJ4k/MFASJ50L0Qp2oMklM9jrDrQApdN8g References: <0BDFFF51DC89434FA33F8B37FCE363D516F96AB6@zcarhxm2.corp.nortel.com> From: "Malcolm Betts" To: "Adrian Farrel" , Subject: Re: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of MPLS-TP OAMrequirements X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:23:22 -0000 Adrian, Thank you for your comments. One question for clarification on security: Are you suggesting that we should have a general section for security requirements e.g. authentication of the sender; or that we should have security requirements explicitly for each function; or ???? I notice that you agree that we should separate the notification of lock from the remote alarm issue. So I suggest that we break my initial proposal into 4 parts and discuss them on different threads: 1) Lock and Notification of Lock 2) Differentiation between local and remote faults 3) Reaction to a CV defect 4) Client failure indication Look for emails on each of these topics some time later today. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Thursday, April 30, 2009 6:23 PM To: Betts, Malcolm (CAR:X632); mpls-interop@ietf.org Subject: Re: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of MPLS-TP OAMrequirements Thanks Malcolm, Can the passive voice be cleaned up a bit? :-) > 2.2.7. Lock > > The MPLS-TP OAM toolset MAY provide a function enabling to =20 > administratively shut down a PW, LSP or Section; that is, to stop =20 > user traffic being sent over that PW, LSP or Section. Enabling whom to administratively shut down a PW...? > The lock function MAY be applied to a unidirectional or bidirectional=20 > PW, LSP or Section. If the lock function is applied to bidirectional=20 > a PW, LSP or Section then it SHOULD be possible to cause it to be=20 > applied to both directions. s/to bidirectional a/to a bidirectional/ > This function SHOULD be performed on-demand. I'm not quite sure what this means. Do you mean, only in reaction to user (operator) commands? Or do you mean only in reaction to some event trigger (which would seem to be a redundant thing to say). > This function SHOULD be performed between End Points of PWs, LSPs=20 > and Sections. Question: In the unidirecitonal case I am unclear on the use of this OAM function. Does the egress instruct the ingress to quiesce? Maybe, but if so, surely a midpoint could also issue the instruction. Or does the ingress tell the egress that it has quiesced? But surely this is an alarm correlation notification, not a lock command. So, in fact, isn't the *OAM* Lock function only applicable to bidirectional PWs, LSPs, and sections? Other aspects of the lock function belong in the NM draft. > 2.2.8. Alarm Notification L >MB> We should break this into several independent requirements: > notification of Lock: Local/remote fault causing loss of CC: Wrong CV=20 > received . Yes. I support this segmentation. > 2.2.8a Notification of Lock > > The MPLS-TP OAM toolset MUST provide a function to enable the End=20 > Point at the ingress to notify the End Points at the egress that the=20 > lock function is active. Unclear why these are "MUST" since the support of the lock function is only MAY Thus, I think you need, "If the lock function is supported..." > The egress end points MUST notify the > local client layer that the server layer PW, LSP or Section has been=20 > locked. > MB> How this is used is out of scope for this draft. Quite agree. It is not a protocol requirements issue what the receiver of a notification does with that information. And there is nothing we can design into the protocol to make it happen. In fact, it is an implementation issue (and maybe an architectural issue). So I would delete this sentence. > The MPLS-TP OAM toolset MUST allow for the distinction between a fault > condition and an administrative locking action. > MB> Not sure we need this if we separate the requirements. I'd keep it. Even if the requirements are separated, without this sentence you might easily use the same mechanism to achieve multiple things. > The server layer End Points generating the notification and the client > layer End Points receiving the notification may or may not be the same > nodes. > > A mechanism MUST be provided to support both cases. I'm puzzled! It appears that this notification is an inter-layer notification not an intra-layer notification. If the layer boundary is within a node this is not a protocol issue and cannot be a protocol requirement. If the layer boundary is on a link (a concept I really hate and don't really believe is meaningful!) then this is no different from the OAM on any other link and doesn't need to be mentioned. > This function SHOULD be performed pro-actively. > > This function SHOULD be performed between the End Points of PWs, LSPs=20 > and Sections and the End Points of the PWs and/or LSPs affected by the > administrative locking. Sentence is a bit confusing! Does it mean... This function SHOULD be performed between the End Points of the PWs, LSPs, or Sections affected by the administrative locking. But this seems to contradict the inter-layer implications above since neither an LSP nor a PW can have its ends in different layers (and I'm not sure a section can either). > 2.2.8b Differentiation between local and remote faults. > > When an MPLS-TP or PW end point detects a continuity check defect it=20 > MUST provide a local indication to any clients and the management=20 > function. It MUST also indicate if the fault causing this is local (i.e. > within the node containing the end point) or remote. This isn't a protocol requirement, is it? It is partly an NM requirement, and partly an architecture/implementation requirement. Essentially, this is function that forms part of 2.2.2 where it should say... "The mechanism provided MUST enable a node that detects a continuity check defect to distinguish local and remote faults." > 2.2.8c Connectivity verification failure > > When an MPLS-TP or PW end point detects a continuity verification=20 > defect it MUST provide a local indication to any clients and the=20 > management function. It MUST also provide the capability to shut down=20 > the PW, LSP or Section; that is, stop user traffic being sent from=20 > that PW, LSP or Section. Exactly as noted for 2.2.8b, but applied to 2.2.3. > 2.2.9. Client Failure Indication > > The MPLS-TP OAM toolset MUST provide a function to enable the=20 > propagation of client fault condition detected at the ingress to a PW, > LSP or Section, across the MPLS-TP network. s/of client/of a client/ s/client fault condition/information pertaining to a client fault condition/ s/to/of/ > MB> The requirement to support the tool should be client independent, > we can, on a case by case basis for each client decide if we will use=20 > this tool. My vote would be to always use this tool since it provides > consistent client independent operation. Can we say "transparent propagation"? That is, the MPLS-TP network should neither examine nor modify the client fault condition. > This function SHOULD be performed pro-actively. > > This function SHOULD be performed between End Points of PWs, LSPs and=20 > Sections. BTW, in the security section... Further, OAM messages MAY be authenticated to prove their origin and to make sure that they are destined for the receiving node. These are protocol requirements, so I think this needs to be "mechanisms MUST be provided to allow OAM messages to be authenticated..." (I was prompted to think about this by considering a "lock" command that was spoofed.) Many thanks, Adrian=20 From BETTS01@nortel.com Fri May 1 12:19:57 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B209E3A6BF2 for ; Fri, 1 May 2009 12:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tZk0n7AePwh for ; Fri, 1 May 2009 12:19:56 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A8E303A69AB for ; Fri, 1 May 2009 12:19:56 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n41JLF713449 for ; Fri, 1 May 2009 19:21:15 GMT 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_01C9CA91.FB5AC627" Date: Fri, 1 May 2009 15:21:08 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516FDADC3@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Differentiation between local and remote faults Thread-Index: AcnKkfwWQS6QZKzISuSc1IwiHE7NMw== From: "Malcolm Betts" To: Subject: [Mpls-interop] Differentiation between local and remote faults X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:19:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CA91.FB5AC627 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To capture this requirement I suggest that: As proposed by Adrian, add the following text to section 2.2.2: "The mechanism provided MUST enable a node that detects a continuity check defect to distinguish local and remote faults." Note that the section 2.2.1 includes requirements for the notification of defects therefore they should not be repeated in the section. The current text in 2.2.8 should be deleted and replaced with a description of reporting the lock condition (I will propose text for this later). Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com ------_=_NextPart_001_01C9CA91.FB5AC627 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Differentiation between local and remote faults

To capture this = requirement I suggest that:

As proposed by = Adrian, add the following text to section 2.2.2:

"The mechanism provided MUST = enable a node that detects a continuity
check defect to distinguish = local and remote faults."

Note that the section = 2.2.1 includes requirements for the notification of defects therefore = they should not be repeated in the section.

The current text in = 2.2.8 should be deleted and replaced with a description of reporting the = lock condition (I will propose text for this later).


Malcolm = Betts
Nortel = Networks
Phone: +1 613 763 = 7860 (ESN 393)
email: = betts01@nortel.com

------_=_NextPart_001_01C9CA91.FB5AC627-- From BETTS01@nortel.com Fri May 1 12:31:42 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01BF3A7079 for ; Fri, 1 May 2009 12:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.137 X-Spam-Level: X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbLHx+IYYlUH for ; Fri, 1 May 2009 12:31:41 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D082E3A7080 for ; Fri, 1 May 2009 12:31:38 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n41JW8B00598 for ; Fri, 1 May 2009 19:32:08 GMT 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_01C9CA93.A2203202" Date: Fri, 1 May 2009 15:32:58 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE0E@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reaction to a CV defect Thread-Index: AcnKk6Lcs1QqXRDNTuuazZN+AdEiSQ== From: "Malcolm Betts" To: Subject: [Mpls-interop] Reaction to a CV defect X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:31:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CA93.A2203202 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To capture this requirement I suggest that:=20 As proposed by Adrian, text for this requirement to section 2.2.3. My proposed text is: "When a continuity verification defect is detected the capability to shut down the defective PW, LSP or Section MUST be provided; that is the capability to, stop user traffic being sent from the defective PW, LSP or Section."=20 Note that the section 2.2.1 includes requirements for the notification of defects therefore they should not be repeated in the section. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com ------_=_NextPart_001_01C9CA93.A2203202 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reaction to a CV defect

To capture this = requirement I suggest that: =
As proposed by = Adrian, text for this requirement to section 2.2.3.  My proposed = text is:
"When a continuity = verification defect is detected the capability to shut down the = defective PW, LSP or Section MUST be provided; that is the capability = to, stop user traffic being sent from the defective PW, LSP or = Section."

Note that the section = 2.2.1 includes requirements for the notification of defects therefore = they should not be repeated in the section.

Malcolm = Betts
Nortel = Networks
Phone: +1 613 763 = 7860 (ESN 393)
email: = betts01@nortel.com

------_=_NextPart_001_01C9CA93.A2203202-- From BETTS01@nortel.com Fri May 1 12:44:44 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469063A6B58 for ; Fri, 1 May 2009 12:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.15 X-Spam-Level: X-Spam-Status: No, score=-6.15 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rta5aFTFPT5g for ; Fri, 1 May 2009 12:44:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id EF8243A68C7 for ; Fri, 1 May 2009 12:44:42 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n41JjCB02384 for ; Fri, 1 May 2009 19:45:12 GMT 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_01C9CA95.76395FE8" Date: Fri, 1 May 2009 15:46:03 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS-TP OAM requirements - Lock and notification of lock Thread-Index: AcnKlXbxf2P6WIX7RfmgiUMmvqwy4Q== From: "Malcolm Betts" To: Subject: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:44:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CA95.76395FE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To address the comments from Adrian I suggest the following text for sections 2.2.7 and 2.2.8: Note that this proposal assumes that the text related to local/remote faults is moved from section 2.2.8 to section 2.2.2 as proposed in my previous email. We probably need to discuss this text on the MEAD team call next week. 2.2.7. Lock=20 The OAM toolset SHOULD provide a function enabling a network operator to administratively shut down a PW, LSP or Section; that is, to stop user traffic being sent over that PW, LSP or Section.=20 The lock function MAY be applied to a unidirectional or a bidirectional PW, LSP or Section. If the lock function is activated at the head end of one direction of a bidirectional PW, LSP or Section then it SHOULD be possible to cause the lock function to be activated at the head end of the other direction.=20 This function SHOULD be performed on-demand i.e. in response to an operator command.=20 This function SHOULD be performed between End Points of PWs, LSPs and Sections. 2.2.8 Notification of Lock=20 If the lock function is supported the MPLS-TP OAM toolset MUST provide a function to enable the End Point at the ingress to notify the End Points at the egress that the lock function is active. This function SHOULD be performed pro-actively. The MPLS-TP OAM toolset MUST allow for the distinction between a fault condition and an administrative locking action. =20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com ------_=_NextPart_001_01C9CA95.76395FE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MPLS-TP OAM requirements - Lock and notification of lock

To address the = comments from Adrian I suggest the following text for sections 2.2.7 and = 2.2.8:

Note that this = proposal assumes that the text related to local/remote faults is moved = from section 2.2.8 to section 2.2.2 as proposed in my previous = email.

We probably need to = discuss this text on the MEAD team call next week.

2.2.7.  = Lock

The OAM = toolset SHOULD provide a function enabling a network operator to = administratively shut down a PW, LSP or Section; that is, to stop user = traffic being sent over that PW, LSP or Section.

The lock = function MAY be applied to a unidirectional or a bidirectional PW, LSP = or Section.  If the lock function is activated at the head end of = one direction of a bidirectional PW, LSP or Section then it SHOULD be = possible to cause the lock function to be activated at the head end of = the other direction.

This = function SHOULD be performed on-demand i.e. in response to an operator = command.

This = function SHOULD be performed between End Points of PWs, LSPs and = Sections.


2.2.8 = Notification of Lock

If the lock = function is supported the MPLS-TP OAM toolset MUST provide a function to = enable the End Point at the ingress to notify the End Points at the = egress that the lock function is active.  This function SHOULD be = performed pro-actively.

The MPLS-TP = OAM toolset MUST allow for the distinction between a fault condition and = an administrative locking action.
 



Malcolm = Betts
Nortel = Networks
Phone: +1 613 763 = 7860 (ESN 393)
email: = betts01@nortel.com

------_=_NextPart_001_01C9CA95.76395FE8-- From BETTS01@nortel.com Fri May 1 13:03:51 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB643A6C87 for ; Fri, 1 May 2009 13:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5vU7EV4McXk for ; Fri, 1 May 2009 13:03:51 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id CAA0C3A67FD for ; Fri, 1 May 2009 13:03:50 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n41K4JB05679 for ; Fri, 1 May 2009 20:04:19 GMT 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_01C9CA98.221BC900" Date: Fri, 1 May 2009 16:05:10 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516FDAEB4@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS-TP OAM requirements - Client failure notifications Thread-Index: AcnKmCLVQIHsaVxSTn2DxoKYCagrYw== From: "Malcolm Betts" To: Subject: [Mpls-interop] MPLS-TP OAM requirements - Client failure notifications X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:03:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CA98.221BC900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To address the comments from Adrian I suggest that we replace the first paragraph of section 2.2.9 2.2.9. Client Failure Indication The MPLS-TP OAM toolset MUST provide a function to enable the propagation of client fault condition information, across the MPLS-TP network, if the client layer OAM mechanisms do not provide an alarm notification/propagation mechanism. with them following: 2.2.9. Client Failure Indication=20 The MPLS-TP OAM toolset MUST provide a function to enable the transparent propagation of information pertaining to a client fault condition detected at the ingress to a PW, LSP or Section, across the MPLS-TP network. The requirement to support the tool is not dependent on the capability of the client. If a client supports failure notifications we need not use this tool. However the tool is always available.=20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com ------_=_NextPart_001_01C9CA98.221BC900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MPLS-TP OAM requirements - Client failure notifications

To address the = comments from Adrian I suggest that we replace the first paragraph of = section 2.2.9
2.2.9.  Client Failure Indication

   = The MPLS-TP OAM toolset MUST provide a function to enable = the
   propagation of client fault condition information, = across the MPLS-TP
   network, if the client layer OAM mechanisms do not = provide an alarm
   notification/propagation mechanism.
with them following:
2.2.9.  Client Failure Indication

The MPLS-TP = OAM toolset MUST provide a function to enable the transparent = propagation of information pertaining to a client fault condition = detected at the ingress to a PW, LSP or Section, across the MPLS-TP = network.

The requirement = to support the tool is not dependent on the capability of the = client.  If a client supports failure notifications we need not use = this tool.  However the tool is always available. =


Malcolm = Betts
Nortel = Networks
Phone: +1 613 763 = 7860 (ESN 393)
email: = betts01@nortel.com

------_=_NextPart_001_01C9CA98.221BC900-- From adrian@olddog.co.uk Fri May 1 13:59:16 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55F53A6BFC for ; Fri, 1 May 2009 13:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_05=-1.11, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBJWhgYwJhgV for ; Fri, 1 May 2009 13:59:16 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 0178F3A6D8B for ; Fri, 1 May 2009 13:59:15 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n41L0WTW024181; Fri, 1 May 2009 22:00:33 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n41L0Vbg024175; Fri, 1 May 2009 22:00:32 +0100 Message-ID: <6810BEF9ECCD417788D0AD3870655B0A@your029b8cecfe> From: "Adrian Farrel" To: "Malcolm Betts" , References: <0BDFFF51DC89434FA33F8B37FCE363D516F96AB6@zcarhxm2.corp.nortel.com> <0BDFFF51DC89434FA33F8B37FCE363D516FDACA5@zcarhxm2.corp.nortel.com> Date: Fri, 1 May 2009 22:00:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of MPLS-TP OAMrequirements X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:59:17 -0000 Hi Malcolm, > One question for clarification on security: Are you suggesting > that we should have a general section for security requirements > e.g. authentication of the sender; or that we should have security > requirements explicitly for each function; or ???? It works for me that you have just the existing security section. That should discuss requirements for security. My original mail was basically saying "OK as far as it goes, but you need to add more stuff" and then made a note on one thing you need to add. > I notice that you agree that we should separate the notification > of lock from the remote alarm issue. I do. But I am just one person. > Look for emails on each of these topics some time later today. Oh, I think I may go to bed :-) Cheers, Adrian From adrian@olddog.co.uk Sat May 2 10:03:46 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512FC3A6AFC for ; Sat, 2 May 2009 10:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGn69PS+NlTp for ; Sat, 2 May 2009 10:03:45 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 36BBC3A6991 for ; Sat, 2 May 2009 10:03:45 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n42H55tS014286 for ; Sat, 2 May 2009 18:05:05 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n42H53sh014278 for ; Sat, 2 May 2009 18:05:05 +0100 Message-ID: From: "Adrian Farrel" To: References: <0BDFFF51DC89434FA33F8B37FCE363D516FDADC3@zcarhxm2.corp.nortel.com> Date: Sat, 2 May 2009 17:54:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Mpls-interop] Differentiation between local and remote faults X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 17:03:46 -0000 wfm A ----- Original Message ----- From: "Malcolm Betts" To: Sent: Friday, May 01, 2009 8:21 PM Subject: [Mpls-interop] Differentiation between local and remote faults To capture this requirement I suggest that: As proposed by Adrian, add the following text to section 2.2.2: "The mechanism provided MUST enable a node that detects a continuity check defect to distinguish local and remote faults." Note that the section 2.2.1 includes requirements for the notification of defects therefore they should not be repeated in the section. The current text in 2.2.8 should be deleted and replaced with a description of reporting the lock condition (I will propose text for this later). Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -------------------------------------------------------------------------------- > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > From adrian@olddog.co.uk Sat May 2 10:07:12 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174833A6DB1 for ; Sat, 2 May 2009 10:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+kEK2qVfzmS for ; Sat, 2 May 2009 10:07:11 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 22A0B3A6CDC for ; Sat, 2 May 2009 10:07:10 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n42H8VNH018960; Sat, 2 May 2009 18:08:31 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n42H8SnY018953; Sat, 2 May 2009 18:08:30 +0100 Message-ID: <75C8A28FE26142CEAF3245B2079821C8@your029b8cecfe> From: "Adrian Farrel" To: "Malcolm Betts" , References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE0E@zcarhxm2.corp.nortel.com> Date: Sat, 2 May 2009 18:08:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Mpls-interop] Reaction to a CV defect X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 17:07:12 -0000 Malcolm, Not quite sure about the proposition: > As proposed by Adrian, text for this requirement to section 2.2.3. > My proposed text is: > "When a continuity verification defect is detected the capability to > shut down the defective PW, LSP or Section MUST be provided; that is the > capability to, stop user traffic being sent from the defective PW, LSP > or Section." "sent from" or "sent on"? Pondering the passive voice again :-( "is detected" by whom? "MUST be provided by what"? Try... When a node detects a continuity verification defect, the protocol mechanisms MUST provide a way for the detecting node to shut down the defective PW, LSP, or Section; that is, the capability to stop user traffic being sent on the defective PW, LSP or Section. A From adrian@olddog.co.uk Sat May 2 10:26:40 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE8A3A6E3A for ; Sat, 2 May 2009 10:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aE56Y5-hYIX for ; Sat, 2 May 2009 10:26:39 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 08ECB3A6D57 for ; Sat, 2 May 2009 10:25:49 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n42HRC6V016316; Sat, 2 May 2009 18:27:12 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n42HRAFv016310; Sat, 2 May 2009 18:27:12 +0100 Message-ID: <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> From: "Adrian Farrel" To: "Malcolm Betts" , References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> Date: Sat, 2 May 2009 18:26:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification oflock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 17:26:40 -0000 Hi Malcolm, > To address the comments from Adrian I suggest the following > text for sections 2.2.7 and 2.2.8: > > Note that this proposal assumes that the text related to local/remote > faults is moved from section 2.2.8 to section 2.2.2 as proposed in my > previous email. > > We probably need to discuss this text on the MEAD team call next > week. > > 2.2.7. Lock > > The OAM toolset SHOULD provide a function enabling a network operator to > administratively shut down a PW, LSP or Section; that is, to stop user > traffic being sent over that PW, LSP or Section. This is great. Does it mean that we do not need to add the (similar) text on CV fault behavior in section 2.2.3? It would seem so. > The lock function MAY be applied to a unidirectional or a bidirectional > PW, LSP or Section. If the lock function is activated at the head end > of one direction of a bidirectional PW, LSP or Section then it SHOULD be > possible to cause the lock function to be activated at the head end of > the other direction. > > This function SHOULD be performed on-demand i.e. in response to an > operator command. Or also in response to configured automatic behavior? But this is not a protocol requirement. > This function SHOULD be performed between End Points of PWs, LSPs > and Sections. > > 2.2.8 Notification of Lock > > If the lock function is supported the MPLS-TP OAM toolset MUST > provide a function to enable the End Point at the ingress to notify the > End Points at the egress that the lock function is active. This > function SHOULD be performed pro-actively. > > The MPLS-TP OAM toolset MUST allow for the distinction between > a fault condition and an administrative locking action. Works for me. A From nurit.sprecher@nsn.com Sun May 3 03:18:03 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5313A6873 for ; Sun, 3 May 2009 03:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfXKU45hzlx5 for ; Sun, 3 May 2009 03:18:01 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 778983A680F for ; Sun, 3 May 2009 03:18:00 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n43AJNbT018305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 3 May 2009 12:19:23 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n43AJNjs017545; Sun, 3 May 2009 12:19:23 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 May 2009 12:19:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9CBD8.A0B61A86" Date: Sun, 3 May 2009 12:19:20 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A753D3@DEMUEXC014.nsn-intra.net> In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516FDACA5@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of MPLS-TPOAMrequirements Thread-Index: AcnJ4k/MFASJ50L0Qp2oMklM9jrDrQApdN8gAFO7cWA= References: <0BDFFF51DC89434FA33F8B37FCE363D516F96AB6@zcarhxm2.corp.nortel.com> <0BDFFF51DC89434FA33F8B37FCE363D516FDACA5@zcarhxm2.corp.nortel.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Malcolm Betts" , "Adrian Farrel" , X-OriginalArrivalTime: 03 May 2009 10:19:23.0195 (UTC) FILETIME=[A10A48B0:01C9CBD8] Subject: Re: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of MPLS-TPOAMrequirements X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 10:18:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CBD8.A0B61A86 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9CBD8.A0B61A86" ------_=_NextPart_002_01C9CBD8.A0B61A86 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcolm, I hope you had the chance to look at (and resolve :-)) my comments.=20 Please see more comments: * You need to define what a local fault is and what a remote fault is. I can think about different interpretations for these. I can see a requirement to detect a fault in a particular layer network. Is this local?=20 * I think you still miss a requirement for Alarm Notification, and I do not think you can eliminate it and hide it behind the requirement for "a node that detects a continuity check defect to distinguish local and remote faults." These are two requirements. IMO, the requirement for alarm notification specified in the MPLS-TP OAM requirement is well described and does not refer to an implementation. * Please refer to my comments I sent on Friday. I attached it to the mail. I think it is already hard to track the proposed changes and we need to see a clear proposal now.=20 Best regards, Nurit =20 -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Malcolm Betts Sent: Friday, May 01, 2009 9:25 PM To: Adrian Farrel; mpls-interop@ietf.org Subject: Re: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of MPLS-TPOAMrequirements =20 Adrian, =20 Thank you for your comments. =20 One question for clarification on security: Are you suggesting that we should have a general section for security requirements e.g. authentication of the sender; or that we should have security requirements explicitly for each function; or ???? =20 I notice that you agree that we should separate the notification of lock from the remote alarm issue. So I suggest that we break my initial proposal into 4 parts and discuss them on different threads: =20 1) Lock and Notification of Lock 2) Differentiation between local and remote faults 3) Reaction to a CV defect 4) Client failure indication =20 Look for emails on each of these topics some time later today. =20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com =20 -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Thursday, April 30, 2009 6:23 PM To: Betts, Malcolm (CAR:X632); mpls-interop@ietf.org Subject: Re: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of MPLS-TP OAMrequirements =20 Thanks Malcolm, =20 Can the passive voice be cleaned up a bit? :-) =20 > 2.2.7. Lock >=20 > The MPLS-TP OAM toolset MAY provide a function enabling to =20 > administratively shut down a PW, LSP or Section; that is, to stop =20 > user traffic being sent over that PW, LSP or Section. =20 Enabling whom to administratively shut down a PW...? =20 > The lock function MAY be applied to a unidirectional or bidirectional=20 > PW, LSP or Section. If the lock function is applied to bidirectional=20 > a PW, LSP or Section then it SHOULD be possible to cause it to be=20 > applied to both directions. =20 s/to bidirectional a/to a bidirectional/ =20 > This function SHOULD be performed on-demand. =20 I'm not quite sure what this means. Do you mean, only in reaction to user (operator) commands? Or do you mean only in reaction to some event trigger (which would seem to be a redundant thing to say). =20 > This function SHOULD be performed between End Points of PWs, LSPs=20 > and Sections. =20 Question: In the unidirecitonal case I am unclear on the use of this OAM function. Does the egress instruct the ingress to quiesce? Maybe, but if so, surely a midpoint could also issue the instruction. Or does the ingress tell the egress that it has quiesced? But surely this is an alarm correlation notification, not a lock command. =20 So, in fact, isn't the *OAM* Lock function only applicable to bidirectional PWs, LSPs, and sections? Other aspects of the lock function belong in the NM draft. =20 > 2.2.8. Alarm Notification L >MB> We should break this into several independent requirements: > notification of Lock: Local/remote fault causing loss of CC: Wrong CV=20 > received . =20 Yes. I support this segmentation. =20 > 2.2.8a Notification of Lock >=20 > The MPLS-TP OAM toolset MUST provide a function to enable the End=20 > Point at the ingress to notify the End Points at the egress that the=20 > lock function is active. =20 Unclear why these are "MUST" since the support of the lock function is only MAY =20 Thus, I think you need, "If the lock function is supported..." =20 > The egress end points MUST notify the > local client layer that the server layer PW, LSP or Section has been=20 > locked. > MB> How this is used is out of scope for this draft. =20 Quite agree. It is not a protocol requirements issue what the receiver of a notification does with that information. And there is nothing we can design into the protocol to make it happen. In fact, it is an implementation issue (and maybe an architectural issue). So I would delete this sentence. =20 > The MPLS-TP OAM toolset MUST allow for the distinction between a fault =20 > condition and an administrative locking action. > MB> Not sure we need this if we separate the requirements. =20 I'd keep it. Even if the requirements are separated, without this sentence you might easily use the same mechanism to achieve multiple things. =20 > The server layer End Points generating the notification and the client =20 > layer End Points receiving the notification may or may not be the same =20 > nodes. >=20 > A mechanism MUST be provided to support both cases. =20 I'm puzzled! It appears that this notification is an inter-layer notification not an intra-layer notification. If the layer boundary is within a node this is not a protocol issue and cannot be a protocol requirement. If the layer boundary is on a link (a concept I really hate and don't really believe is meaningful!) then this is no different from the OAM on any other link and doesn't need to be mentioned. =20 > This function SHOULD be performed pro-actively. >=20 > This function SHOULD be performed between the End Points of PWs, LSPs=20 > and Sections and the End Points of the PWs and/or LSPs affected by the =20 > administrative locking. =20 Sentence is a bit confusing! =20 Does it mean... This function SHOULD be performed between the End Points of the PWs, LSPs, or Sections affected by the administrative locking. =20 But this seems to contradict the inter-layer implications above since neither an LSP nor a PW can have its ends in different layers (and I'm not sure a section can either). =20 > 2.2.8b Differentiation between local and remote faults. >=20 > When an MPLS-TP or PW end point detects a continuity check defect it=20 > MUST provide a local indication to any clients and the management=20 > function. It MUST also indicate if the fault causing this is local (i.e. > within the node containing the end point) or remote. =20 This isn't a protocol requirement, is it? It is partly an NM requirement, and partly an architecture/implementation requirement. Essentially, this is function that forms part of 2.2.2 where it should say... "The mechanism provided MUST enable a node that detects a continuity check defect to distinguish local and remote faults." =20 > 2.2.8c Connectivity verification failure >=20 > When an MPLS-TP or PW end point detects a continuity verification=20 > defect it MUST provide a local indication to any clients and the=20 > management function. It MUST also provide the capability to shut down=20 > the PW, LSP or Section; that is, stop user traffic being sent from=20 > that PW, LSP or Section. =20 Exactly as noted for 2.2.8b, but applied to 2.2.3. =20 > 2.2.9. Client Failure Indication >=20 > The MPLS-TP OAM toolset MUST provide a function to enable the=20 > propagation of client fault condition detected at the ingress to a PW, =20 > LSP or Section, across the MPLS-TP network. =20 s/of client/of a client/ s/client fault condition/information pertaining to a client fault condition/ s/to/of/ =20 > MB> The requirement to support the tool should be client independent, > we can, on a case by case basis for each client decide if we will use=20 > this tool. My vote would be to always use this tool since it provides =20 > consistent client independent operation. =20 Can we say "transparent propagation"? That is, the MPLS-TP network should neither examine nor modify the client fault condition. =20 > This function SHOULD be performed pro-actively. >=20 > This function SHOULD be performed between End Points of PWs, LSPs and=20 > Sections. =20 BTW, in the security section... Further, OAM messages MAY be authenticated to prove their origin and to make sure that they are destined for the receiving node. =20 These are protocol requirements, so I think this needs to be "mechanisms MUST be provided to allow OAM messages to be authenticated..." (I was prompted to think about this by considering a "lock" command that was spoofed.) =20 Many thanks, Adrian=20 =20 =20 _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_002_01C9CBD8.A0B61A86 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Malcolm,

I hope you had the chance to look at (and resolve :-)) my = comments.

Please see more comments:

·         You need to = define what a local fault is and what a remote fault is. I can think about = different interpretations for these. I can see a requirement to detect a fault in = a particular layer network. Is this local?

·         I think you = still miss a requirement for Alarm Notification, and I do not think you can = eliminate it and hide it behind the requirement for "a node that detects a = continuity check defect to distinguish local and remote faults." These are two requirements. IMO, the requirement for alarm notification specified in = the MPLS-TP OAM requirement is well described and does not refer to an = implementation.   

·         Please = refer to my comments I sent on Friday. I attached it to the mail.

I think it is already hard to track the proposed changes and we = need to see a clear proposal now.

Best regards,

Nurit

 

-----Original Message-----
From: mpls-interop-bounces@ietf.org = [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Malcolm Betts
Sent: Friday, May 01, 2009 9:25 PM
To: Adrian Farrel; mpls-interop@ietf.org
Subject: Re: [Mpls-interop] Draft text for "AIS" in section = 2.2.8 of MPLS-TPOAMrequirements

 

Adrian,

 

Thank you for your comments.

 

One question for clarification on security:  Are you = suggesting that we

should have a general section for security requirements = e.g.

authentication of the sender; or that we should have = security

requirements explicitly for each function; or = ????

 

I notice that you agree that we should separate the notification = of lock

from the remote alarm issue.  So I suggest that we break my initial

proposal into 4 parts and discuss them on different = threads:

 

1) Lock and Notification of Lock

2) Differentiation between local and remote = faults

3) Reaction to a CV defect

4) Client failure indication

 

Look for emails on each of these topics some time later = today.

 

Malcolm Betts

Nortel Networks

Phone: +1 613 763 7860 (ESN 393)

email: betts01@nortel.com

 

-----Original Message-----

From: Adrian Farrel [mailto:adrian@olddog.co.uk] =

Sent: Thursday, April 30, 2009 6:23 = PM

To: Betts, Malcolm (CAR:X632); = mpls-interop@ietf.org

Subject: Re: [Mpls-interop] Draft text for "AIS" in = section 2.2.8 of

MPLS-TP OAMrequirements

 

Thanks Malcolm,

 

Can the passive voice be cleaned up a bit? = :-)

 

> 2.2.7.  Lock

> 

>  The MPLS-TP OAM toolset MAY provide a function = enabling to 

> administratively shut down a PW, LSP or Section; that is, = to stop 

> user traffic being sent over that PW, LSP or = Section.

 

Enabling whom to administratively shut down a = PW...?

 

> The lock function MAY be applied to a unidirectional or bidirectional

> PW, LSP or Section.  If the lock function is applied = to bidirectional

> a PW, LSP or Section then it SHOULD be possible to cause it = to be

> applied to both directions.

 

s/to bidirectional a/to a = bidirectional/

 

> This function SHOULD be performed = on-demand.

 

I'm not quite sure what this means. Do you mean, only in = reaction to

user

(operator) commands?

Or do you mean only in reaction to some event trigger (which = would seem

to be a redundant thing to say).

 

>  This function SHOULD be performed between End Points = of PWs,  LSPs

> and Sections.

 

Question:

In the unidirecitonal case I am unclear on the use of this OAM function.

Does the egress instruct the ingress to quiesce? Maybe, but if = so,

surely a midpoint could also issue the = instruction.

Or does the ingress tell the egress that it has quiesced? But = surely

this is an alarm correlation notification, not a lock = command.

 

So, in fact, isn't the *OAM* Lock function only applicable = to

bidirectional PWs, LSPs, and = sections?

Other aspects of the lock function belong in the NM = draft.

 

> 2.2.8.  Alarm = Notification

L

>MB> We should break this into several independent = requirements:

> notification of Lock: Local/remote fault causing loss of = CC: Wrong CV

> received <not sure if we need this, its implicit in = 2.2.3>.

 

Yes. I support this segmentation.

 

> 2.2.8a Notification of Lock

> 

> The MPLS-TP OAM toolset MUST provide a function to enable = the End

> Point at the ingress to notify the End Points at the egress = that the

> lock function is active.

 

Unclear why these are "MUST" since the support of the = lock function is

only MAY

 

Thus, I think you need, "If the lock function is supported..."

 

> The egress end points MUST notify = the

> local client layer that the server layer PW, LSP or Section = has been

> locked.

> MB> How this is used is out of scope for this = draft.

 

Quite agree. It is not a protocol requirements issue what the = receiver

of a notification does with that information. And there is = nothing we

can design into the protocol to make it happen. In fact, it is = an

implementation issue (and maybe an architectural = issue).

So I would delete this sentence.

 

> The MPLS-TP OAM toolset MUST allow for the distinction = between a fault

 

> condition and an administrative locking = action.

> MB> Not sure we need this if we separate the = requirements.

 

I'd keep it. Even if the requirements are separated, without = this

sentence you might easily use the same mechanism to achieve = multiple

things.

 

> The server layer End Points generating the notification and = the client

 

> layer End Points receiving the notification may or may not = be the same

 

> nodes.

> 

> A mechanism MUST be provided to support both = cases.

 

I'm puzzled! It appears that this notification is an = inter-layer

notification not an intra-layer = notification.

If the layer boundary is within a node this is not a protocol = issue and

cannot be a protocol requirement.

If the layer boundary is on a link (a concept I really hate and = don't

really believe is meaningful!) then this is no different from = the OAM on

any other link and doesn't need to be = mentioned.

 

> This function SHOULD be performed = pro-actively.

> 

> This function SHOULD be performed between the End Points of = PWs, LSPs

> and Sections and the End Points of the PWs and/or LSPs = affected by the

 

> administrative locking.

 

Sentence is a bit confusing!

 

Does it mean...

   This function SHOULD be performed between the End = Points of the PWs,

   LSPs, or Sections affected by the administrative = locking.

 

But this seems to contradict the inter-layer implications above = since

neither an LSP nor a PW can have its ends in different layers = (and I'm

not sure a section can either).

 

> 2.2.8b Differentiation between local and remote = faults.

> 

> When an MPLS-TP or PW end point detects a continuity check = defect it

> MUST provide a local indication to any clients and the = management

> function. It MUST also indicate if the fault causing this = is local

(i.e.

> within the node containing the end point) or = remote.

 

This isn't a protocol requirement, is = it?

It is partly an NM requirement, and partly = an

architecture/implementation = requirement.

Essentially, this is function that forms part of 2.2.2 where it = should

say...

"The mechanism provided MUST enable a node that detects a continuity

check defect to distinguish local and remote = faults."

 

> 2.2.8c Connectivity verification = failure

> 

> When an MPLS-TP or PW end point detects a continuity = verification

> defect it MUST provide a local indication to any clients = and the

> management function. It MUST also provide the capability to = shut down

> the PW, LSP or Section; that is, stop user traffic being = sent from

> that PW, LSP or Section.

 

Exactly as noted for 2.2.8b, but applied to = 2.2.3.

 

> 2.2.9.  Client Failure = Indication

> 

> The MPLS-TP OAM toolset MUST provide a function to enable = the

> propagation of client fault condition detected at the = ingress to a PW,

 

> LSP or Section, across the MPLS-TP = network.

 

s/of client/of a client/

s/client fault condition/information pertaining to a client = fault

condition/ s/to/of/

 

> MB> The requirement to support the tool should be client independent,

> we can, on a case by case basis for each client decide if = we will use

> this tool.  My vote would be to always use this tool = since it provides

 

> consistent client independent = operation.

 

Can we say "transparent = propagation"?

That is, the MPLS-TP network should neither examine nor modify = the

client fault condition.

 

> This function SHOULD be performed = pro-actively.

> 

> This function SHOULD be performed between End Points of = PWs, LSPs and

> Sections.

 

BTW, in the security section...

   Further, OAM messages MAY be authenticated to prove = their origin and

   to make sure that they are destined for the = receiving node.

 

These are protocol requirements, so I think this needs to be "mechanisms

MUST be provided to allow OAM messages to be = authenticated..." (I was

prompted to think about this by considering a "lock" = command that was

spoofed.)

 

Many thanks,

Adrian

 

 

_______________________________________________=

Mpls-interop mailing list

Mpls-interop@ietf.org

https://www.ietf.org/mailman/listinfo/mpls-interop

------_=_NextPart_002_01C9CBD8.A0B61A86-- ------_=_NextPart_001_01C9CBD8.A0B61A86 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_003_01C9CA6B.1FC3B200" Subject: Alarm notifications v002-MB.doc Date: Fri, 1 May 2009 16:43:35 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Alarm notifications v002-MB.doc Thread-Index: AcnKazT9fuo0Pl3JS3KnLw/x6gSQDw== From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "MEAD team" , "ext Malcolm Betts" This is a multi-part message in MIME format. ------_=_NextPart_003_01C9CA6B.1FC3B200 Content-Type: multipart/alternative; boundary="----_=_NextPart_004_01C9CA6B.1FC3B200" ------_=_NextPart_004_01C9CA6B.1FC3B200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcom, Please see my comment inside the attached. Best regards, Nurit ------_=_NextPart_004_01C9CA6B.1FC3B200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Malcom,

Please see my comment inside the = attached.

Best regards,

Nurit

------_=_NextPart_004_01C9CA6B.1FC3B200-- ------_=_NextPart_003_01C9CA6B.1FC3B200 Content-Type: application/msword; name="Alarm notifications v002-MB.doc" Content-Transfer-Encoding: base64 Content-Description: Alarm notifications v002-MB.doc Content-Disposition: attachment; filename="Alarm notifications v002-MB.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPgAAAAAAAAAA EAAAQAAAAAEAAAD+////AAAAAD0AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAJWAJBAAA8BK/AAAAAAAAMAAAAAAABgAA2RgAAA4AYmpiak7gTuAAAAAAAAAAAAAAAAAAAAAA AAAJBBYANDQAACyKAQAsigEAlw0AAAAAAAAAAAAAAAAAAEEDAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAPwEAAAAAAAA/AQAAPwE AAAAAAAA/AQAAAAAAAAOBQAA8gAAAH4GAAAkAAAAogYAABQAAAAAAAAAAAAAALYGAAAAAAAAfhgA AAAAAAB+GAAAAAAAAH4YAAAAAAAAfhgAADQAAACyGAAANAAAALYGAAAAAAAAYB8AAHQBAADyGAAA AAAAAPIYAAAAAAAA8hgAAAAAAADyGAAAAAAAAPIYAAAAAAAAzRkAAAAAAADNGQAAAAAAAM0ZAAAA AAAAax4AAAIAAABtHgAAAAAAAG0eAAAAAAAAbR4AAAAAAABtHgAAAAAAAG0eAAAAAAAAbR4AAAAA AADUIAAAaAIAADwjAABWAAAAbR4AABUAAAAAAAAAAAAAAAAAAAAAAAAA/AQAABIAAADNGQAAWgAA AAAAAAAAAAAAAAAAAAAAAADNGQAAAAAAAM0ZAAAAAAAAJxoAADwAAABjGgAAIAAAAG0eAAAAAAAA AAAAAAAAAAD8BAAAAAAAAPwEAAAAAAAA8hgAAAAAAAAAAAAAAAAAAPIYAADbAAAAgh4AAFYAAABD HAAAAAAAAEMcAAAAAAAAQxwAAAAAAACDGgAAiAAAAPwEAAAAAAAA8hgAAAAAAAD8BAAAAAAAAPIY AAAAAAAAax4AAAAAAAAAAAAAAAAAAEMcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAzRkAAAAAAABrHgAAAAAAAAAAAAAAAAAAQxwAAAAAAAAAAAAA AAAAAEMcAAAAAAAA/AQAAAAAAAD8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQxwAAAAAAADyGAAAAAAAAOYYAAAMAAAAMLCTEmvK yQEAAAAAAAAAAH4YAAAAAAAACxsAAOgAAABDHAAAAAAAAAAAAAAAAAAAax4AAAAAAADYHgAAiAAA AGAfAAAAAAAAQxwAAAAAAACSIwAAAAAAAPMbAAA0AAAAkiMAAAAAAABDHAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJIjAAAAAAAAAAAAAAAAAAAABgAAfgAAAEMcAAAoAgAAzRkAAAAAAADNGQAAAAAAAEMc AAAAAAAAzRkAAAAAAADNGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzRkA AAAAAADNGQAAAAAAAM0ZAAAAAAAAbR4AAAAAAABtHgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAJxwAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM0ZAAAA AAAAzRkAAAAAAADNGQAAAAAAAGAfAAAAAAAAzRkAAAAAAADNGQAAAAAAAM0ZAAAAAAAAzRkAAAAA AAAAAAAAAAAAALYGAAAAAAAAtgYAAAAAAAC2BgAA5AgAAJoPAADkCAAAtgYAAAAAAAC2BgAAAAAA ALYGAAAAAAAAmg8AAAAAAAC2BgAAAAAAALYGAAAAAAAAtgYAAAAAAAD8BAAAAAAAAPwEAAAAAAAA /AQAAAAAAAD8BAAAAAAAAPwEAAAAAAAA/AQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADIuMi43 LiAgTG9jaw0NICAgVGhlIE1QTFMtVFAgT0FNIHRvb2xzZXQgTUFZIHByb3ZpZGUgYSBmdW5jdGlv biBlbmFibGluZyB0bw0gICBhZG1pbmlzdHJhdGl2ZWx5IHNodXQgZG93biBhIFBXLCBMU1Agb3Ig U2VjdGlvbjsgdGhhdCBpcywgdG8gc3RvcA0gICB1c2VyIHRyYWZmaWMgYmVpbmcgc2VudCBvdmVy IHRoYXQgUFcsIExTUCBvciBTZWN0aW9uLg0NVGhlIGxvY2sgZnVuY3Rpb24gTUFZIGJlIGFwcGxp ZWQgdG8gYSB1bmlkaXJlY3Rpb25hbCBvciBiaWRpcmVjdGlvbmFsIFBXLCBMU1Agb3IgU2VjdGlv bgUuICBJZiB0aGUgbG9jayBmdW5jdGlvbiBpcyBhcHBsaWVkIHRvIGJpZGlyZWN0aW9uYWwgYSBQ VywgTFNQIG9yIFNlY3Rpb24gdGhlbiBpdCBTSE9VTEQgYmUgcG9zc2libGUgdG8gY2F1c2UgaXQg dG8gYmUgYXBwbGllZCB0byBib3RoIGRpcmVjdGlvbnMuDQ0gICBUaGlzIGZ1bmN0aW9uIFNIT1VM RCBiZSBwZXJmb3JtZWQgb24tZGVtYW5kLg0NICAgVGhpcyBmdW5jdGlvbiBTSE9VTEQgYmUgcGVy Zm9ybWVkIGJldHdlZW4gRW5kIFBvaW50cyBvZiBQV3MsIExTUHMgYW5kDSAgIFNlY3Rpb25zLg0N Mi4yLjguICBBbGFybSBOb3RpZmljYXRpb24NTUI+IFdlIHNob3VsZCBicmVhayB0aGlzIGludG8g c2V2ZXJhbCBpbmRlcGVuZGVudCByZXF1aXJlbWVudHM6IG5vdGlmaWNhdGlvbiBvZiBMb2NrOiBM b2NhbC9yZW1vdGUgZmF1bHQgY2F1c2luZyBsb3NzIG9mIENDOiBXcm9uZyBDViByZWNlaXZlZAUg PG5vdCBzdXJlIGlmIHdlIG5lZWQgdGhpcywgaXRzIGltcGxpY2l0IGluIDIuMi4zPi4NDTIuMi44 YSBOb3RpZmljYXRpb24gb2YgTG9jawUNDSAgIFRoZSBNUExTLVRQIE9BTSB0b29sc2V0IE1VU1Qg cHJvdmlkZSBhIGZ1bmN0aW9uIHRvIGVuYWJsZSBzZXJ2ZXJ0aGUNICAgbGF5ZXIgRW5kIFBvaW50 cyBQb2ludCBhdCB0aGUgaW5ncmVzcyB0byBub3RpZnkgYSBmYXVsdCBjb25kaXRpb24gb3IgYW4g YWRtaW5pc3RyYXRpdmUNICAgbG9ja2luZyB0byB0aGUgY2xpZW50IGxheWVydGhlIEVuZCBQb2lu dHMgYXQgdGhlIGVncmVzcyBhZmZlY3RlZCBieSB0aGlzIHN0YXR1c3RoYXQgdGhlIGxvY2sgZnVu Y3Rpb24gaXMgYWN0aXZlLiAgVGhlIGVncmVzcyBlbmQgcG9pbnRzIE1VU1Qgbm90aWZ5IHRoZSBs b2NhbCBjbGllbnQgbGF5ZXIgdGhhdCB0aGUgc2VydmVyIGxheWVyIFBXLCBMU1Agb3IgU2VjdGlv biBoYXMgYmVlbiBsb2NrZWQuICAgVGhpcw0gICB3b3VsZCBlbmFibGUgdG8gc3VwcHJlc3MgYWxh cm1zIHRoYXQgbWF5IGJlIGdlbmVyYXRlZCBpbiB0aGUgY2xpZW50DSAgIGxheWVyIGFzIGEgcmVz dWx0IG9mIHRoZSBmYXVsdCBjb25kaXRpb24gb3Igb2YgdGhlIGFkbWluaXN0cmF0aXZlDSAgIGxv Y2tpbmcgaW4gdGhlIHNlcnZlciBsYXllci4NTUI+IEhvdyB0aGlzIGlzIHVzZWQgaXMgb3V0IG9m IHNjb3BlIGZvciB0aGlzIGRyYWZ0Lg0NICAgVGhlIE1QTFMtVFAgT0FNIHRvb2xzZXQgTVVTVCBh bGxvdyBmb3IgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gYQ0gICBmYXVsdCBjb25kaXRpb24gYW5k IGFuIGFkbWluaXN0cmF0aXZlIGxvY2tpbmcgYWN0aW9uLg1NQj4gTm90IHN1cmUgd2UgbmVlZCB0 aGlzIGlmIHdlIHNlcGFyYXRlIHRoZSByZXF1aXJlbWVudHMuDQ0gICBUaGUgc2VydmVyIGxheWVy IEVuZCBQb2ludHMgZ2VuZXJhdGluZyB0aGUgbm90aWZpY2F0aW9uIGFuZCB0aGUNICAgY2xpZW50 IGxheWVyIEVuZCBQb2ludHMgcmVjZWl2aW5nIHRoZSBub3RpZmljYXRpb24gbWF5IG9yIG1heSBu b3QgYmUNICAgdGhlIHNhbWUgbm9kZXMuICBBIG1lY2hhbmlzbSBNVVNUIGJlIHByb3ZpZGVkIHRv IHN1cHBvcnQgYm90aCBjYXNlcy4NDSAgIFRoaXMgZnVuY3Rpb24gU0hPVUxEIGJlIHBlcmZvcm1l ZCBwcm8tYWN0aXZlbHkuDQ0gICBUaGlzIGZ1bmN0aW9uIFNIT1VMRCBiZSBwZXJmb3JtZWQgYmV0 d2VlbiB0aGUgRW5kIFBvaW50cyBvZiBQV3MsIExTUHMNICAgYW5kIFNlY3Rpb25zIGFuZCB0aGUg RW5kIFBvaW50cyBvZiB0aGUgUFdzIGFuZC9vciBMU1BzIGFmZmVjdGVkIGJ5DSAgIHRoZSBmYXVs dCBjb25kaXRpb24gb3IgYWRtaW5pc3RyYXRpdmUgbG9ja2luZy4NDTIuMi44YiBEaWZmZXJlbnRp YXRpb24gYmV0d2VlbiBsb2NhbCBhbmQgcmVtb3RlIGZhdWx0cwUuDQ1XaGVuIGFuIE1QTFMtVFAg b3IFIFBXIGVuZCBwb2ludCBkZXRlY3RzIGEgY29udGludWl0eSBjaGVjayBkZWZlY3QgaXQgTVVT VCBwcm92aWRlIGEgbG9jYWwgaW5kaWNhdGlvbiB0byBhbnkgY2xpZW50cyBhbmQgdGhlIG1hbmFn ZW1lbnQgZnVuY3Rpb24FLiBJdCBNVVNUIGFsc28gaW5kaWNhdGUgaWYgdGhlIGZhdWx0IGNhdXNp bmcgdGhpcyBpcyBsb2NhbCAoaS5lLiB3aXRoaW4gdGhlIG5vZGUgY29udGFpbmluZyB0aGUgZW5k IHBvaW50KSBvciByZW1vdGUuDQ0yLjIuOGMgQ29ubmVjdGl2aXR5IHZlcmlmaWNhdGlvbiBmYWls dXJlDQ1XaGVuIGFuIE1QTFMtVFAgb3IgUFcgZW5kIHBvaW50IGRldGVjdHMgYSBjb250aW51aXR5 IHZlcmlmaWNhdGlvbiBkZWZlY3QgaXQgTVVTVCBwcm92aWRlIGEgbG9jYWwgaW5kaWNhdGlvbiB0 byBhbnkgY2xpZW50cyBhbmQgdGhlIG1hbmFnZW1lbnQgZnVuY3Rpb24uIEl0IE1VU1QgYWxzbyBw cm92aWRlIHRoZSBjYXBhYmlsaXR5IHRvIHNodXQgZG93biB0aGUgUFcsIExTUCBvciBTZWN0aW9u OyB0aGF0IGlzLCBzdG9wIHVzZXIgdHJhZmZpYyBiZWluZyBzZW50IGZyb20gdGhhdCBQVywgTFNQ IG9yIFNlY3Rpb24uDQ0NMi4yLjkuICBDbGllbnQgRmFpbHVyZSBJbmRpY2F0aW9uDQ0gICBUaGUg TVBMUy1UUCBPQU0gdG9vbHNldCBNVVNUIHByb3ZpZGUgYSBmdW5jdGlvbiB0byBlbmFibGUgdGhl DSAgIHByb3BhZ2F0aW9uIG9mIGNsaWVudCBmYXVsdCBjb25kaXRpb24gZGV0ZWN0ZWQgYXQgdGhl IGluZ3Jlc3MgdG8gYSBQVywgTFNQIG9yIFNlY3Rpb25pbmZvcm1hdGlvbiwgYWNyb3NzIHRoZSBN UExTLVRQDSAgIG5ldHdvcmssIGlmIHRoZSBjbGllbnQgbGF5ZXIgT0FNIG1lY2hhbmlzbXMgZG8g bm90IHByb3ZpZGUgYW4gYWxhcm0NICAgbm90aWZpY2F0aW9uL3Byb3BhZ2F0aW9uIG1lY2hhbmlz bS4NTUI+IFRoZQUgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCB0aGUgdG9vbCBzaG91bGQgYmUgY2xp ZW50IGluZGVwZW5kZW50LCB3ZSBjYW4sIG9uIGEgY2FzZSBieSBjYXNlIGJhc2lzIGZvciBlYWNo IGNsaWVudCBkZWNpZGUgaWYgd2Ugd2lsbCB1c2UgdGhpcyB0b29sLiAgTXkgdm90ZSB3b3VsZCBi ZSB0byBhbHdheXMgdXNlIHRoaXMgdG9vbCBzaW5jZSBpdCBwcm92aWRlcyBjb25zaXN0ZW50IGNs aWVudCBpbmRlcGVuZGVudCBvcGVyYXRpb24uDQ0gICBUaGlzIGZ1bmN0aW9uIFNIT1VMRCBiZSBw ZXJmb3JtZWQgcHJvLWFjdGl2ZWx5Lg0NICAgVGhpcyBmdW5jdGlvbiBTSE9VTEQgYmUgcGVyZm9y bWVkIGJldHdlZW4gRW5kIFBvaW50cyBvZiBQV3MsIExTUHMgYW5kDSAgIFNlY3Rpb25zLg0NBVRo aXMgaXMgYSBnZW5lcmFsIHJlcXVpcmVtZW50IGZvciBhbGwgZnVuY3Rpb25zLiBXZSBhc2tzIGZv ciBhIGNvbnNpc3RlbnQgT0FNIGZ1bmN0aW9uYWxpdHkgYXQgZGlmZmVyZW50IG5lc3QgbGF5ZXJz LiBXZSBkbyBub3QgbmVlZCB0byBtZW50aW9uIGl0IHNwZWNpZmljYWxseSBpbiB0aGlzIGNhc2Uu IA0FSSBwcm9wb3NlIHRvIHNlcGFyYXRlIG9pdCB0byB0d28gZnVuY3Rpb25zOiBMb2NrIG5vdGlm aWNhdGlvbiwgYW5kIGFsYXJtIG5vdGlmaWNhdGlvbi4gSSBkbyBub3Qgc2VlIGFueSBiZW5lZml0 IGluIHB1dHRpbmcgdGhlbSBpbiBvbmUgc2VjdGlvbi4gSXQgaXMgbGlrZSBDQyBhbmQgQ1YsIHR3 byBmdW5jdGlvbnMuIA0FSSBwcm9wb3NlIHRvIG5hbWUgaXQgk0xvY2sgTm90ZmljaWF0aW9ulA0F V2UgbmVlZCBhIGZ1bmN0aW9uIJNBbGFybSBOb3RpZmljYXRpb26UDQVJIGd1ZXNzIHlvdSBtZWFu IE1QTFMtVFAgTFNQDQVUaGlzIGlzIHBhcnQgb2YgdGhlIENDIGZ1bmN0aW9uLiBJIHdvdWxkIGxp a2UgdG8gc2VlIGEgZGVzY3JpcHRpb24gb2YgdGhlIGZ1bmN0aW9uIJNhbGFybSBub3RpZmljYXRp b26ULiBXaXRob3V0IHN1Y2ggYSBmdW5jdGlvbiwgSSBkbyBub3Qgc2VlIGEgd2F5IGZvciBhIGNs aWVudCBsYXllciB0byBpZGVudGlmeSBhIJNyZW1vdGUgY2FsbJQuIA1JIHRoaW5rIHRoZSBvcmln aW5hbCBkZXNjcmlwdGlvbiBpbiB0aGUgZG9jdW1lbnQgb24gYWxhcm0gbm90aWZpY2F0aW9uIGlz IGdvb2QgYW5kIEkgd291bGQgbGlrZSB0byBrZWVwIGl0LiANBUkgZG8gbm90IHVuZGVyc3RhbmQg eW91ciBjb21tZW50LiBQbGVhc2UgY2xhcmlmeS4gDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAADJCAAAyggAAMsI AADTCAAA7wgAAPEIAAD0CAAAAAkAAAIJAAARCQAAIwkAACQJAABKCQAAWAkAAFoJAABsCQAAdQkA AHsJAACHCQAAtQkAALYJAABaCgAAXgoAAHgKAACLCgAAmAoAAJkKAADoCgAA6QoAAOoKAAAbCwAA HAsAAB0LAAAeCwAA+e/l2+XRx+XR5bqq26Dbk9uJ24mC+X11cHVwdapwaGT5YAAAAAAAAAAAAAAA AAAAAAAAAAYWaMcYzAAABhZoM3hlAAAPDCoDFWhtDXcAFmhtDXcACQwqBxZobQ13AA8MKgcVaNgb ygAWaNgbygAJDCoHFmjDCyIADBVoujsiABZo5V2sAAATAQiBBEgBAAVoyPPUhhZo5V2sABkBCIEE SAEABWjH89SGFWi6OyIAFmjlXawAEwEIgQRIAQAFaM/z1IYWaDN4ZQAfA2oAAAAAFmhTc9EAMEoR AE9KAABRSgAAVQgBXkoAABkBCIEESAEABWjG89SGFWi6OyIAFmjlXawAEwEIgQRIAQAFaMXz1IYW aDN4ZQATAQiBBEgBAAVoxvPUhhZo5V2sABMBCIEESAEABWjH89SGFmjlXawAEwEIgQRIAQAFaMXz 1IYWaOVdrAATAQiBBEgBAAVoxfPUhhZopWt3AAwVaLo7IgAWaKVrdwAiAAYAAA0IAAAOCAAATAgA AJEIAADKCAAAywgAALYJAAC3CQAA5wkAAOgJAAAxCgAAPgoAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAA AGoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAARw8AQyQBRcaAAAABAMXz1IYAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZOVdrAAA Rw8AQyQBRcaAAAABAMXz1IYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZKVrdwAABA8AZ2Sla3cAAAwABgAAlxUAANgYAAD9/QAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBAj4KAAA/CgAAWgoAAB0LAAAe CwAAOwsAADwLAACDCwAA3QsAAMwMAAATDQAAWA0AAHgNAACtDQAArg0AAPINAAArDgAAZg4AAGcO AACqDgAA8g4AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEcP AEMkAUXGgAAAAQDK89SGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2Sla3cAAAQPAGdkpWt3AAAUHgsAADkLAAA6CwAAOwsAADwL AAB5CwAAfwsAAIILAACGCwAAjAsAAJALAACXCwAAnAsAAKsLAACsCwAAtgsAAMsLAADvCwAA+wsA AP4LAAAKDAAAGAwAACgMAAD15dvX0Las0LbQlol/idBllmVb0FE7AAAAACsACIEVaLo7IgAWaKVr dwAXaOVdrABjSAEAZGgAAAAAZGgAAAAAZGjM89SGEwEIgQRIAQAFaNDz1IYWaDN4ZQATAQiBBEgB AAVoy/PUhhZoM3hlADMACIEVaLo7IgAWaKVrdwAXaOVdrABjSAEAY0gAAGNIAQBkaAAAAABkaAAA AABkaMvz1IYTAQiBBEgBAAVoy/PUhhZo5V2sABkBCIEESAEABWjL89SGFWi6OyIAFmjlXawAKwAI gRVoujsiABZopWt3ABdo5V2sAGNIAQBkaAAAAABkaAAAAABkaMvz1IYTAQiBBEgBAAVoyvPUhhZo 5V2sADMACIEVaLo7IgAWaKVrdwAXaOVdrABjSAEAY0gAAGNIAQBkaAAAAABkaAAAAABkaMrz1IYM FWi6OyIAFmila3cAAAYWaOVdrAAAEwEIgQRIAQAFaMrz1IYWaMMLIgAfA2oAAAAAFmhTc9EAMEoR AE9KAABRSgAAVQgBXkoAABMBCIEESAEABWik8tSGFmjDCyIAABYoDAAALwwAAE8MAABQDAAAaAwA AGwMAAChDAAAswwAAMQMAADFDAAAdw0AAHgNAACsDQAArQ0AACoOAAArDgAAZQ4AAGYOAAAFEAAA GBAAADAQAAAxEAAAOBAAAOXb1NvK272zo42JgXrUiXJr1FXUS0EAAAAAAAAAAAAAAAAAAAAAEwEI gQRIAQAFaKjy1IYWaHwFlgATAQiBBEgBAAVoqPLUhhZopWt3ACsACIEVaLo7IgAWaKVrdwAXaMML IgBjSAEAZGgAAAAAZGgAAAAAZGin8tSGDBVoujsiABZoT0ezAAAPDCoHFWhPR7MAFmhPR7MADBVo ujsiABZowwsiAAAPDCoHFWjDCyIAFmjDCyIABhZopWt3AAArAAiBFWi6OyIAFmila3cAF2jDCyIA Y0gBAGRoAAAAAGRoAAAAAGRopfLUhh8BCIEESAEABWil8tSGFWi6OyIAFmjDCyIAF2jDCyIAEwEI gQRIAQAFaM3z1IYWaOVdrAAZAQiBBEgBAAVozfPUhhVoujsiABZo5V2sABMBCIEESAEABWjQ89SG FmgzeGUADBVoujsiABZopWt3AAATAQiBBEgBAAVozPPUhhZo5V2sADMACIEVaLo7IgAWaKVrdwAX aOVdrABjSAEAY0gAAGNIAQBkaAAAAABkaAAAAABkaMzz1IYAFvIOAAA6DwAAOw8AAG4PAABvDwAA uA8AAP4PAAAwEAAAMRAAAGoQAABrEAAAchEAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEcPAEMkAUXGgAAAAQCw8tSGAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2Sla3cAAEcPAEMk AUXGgAAAAQCo8tSGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAZ2Sla3cAAAQPAGdkpWt3AAALOBAAAGcQAABoEAAAaRAAAGoQAAB6 EAAAfRAAAH4QAACBEAAAjBAAAJUQAACWEAAAphAAAKcQAACtEAAAsRAAANEQAADUEAAA6BAAAPsQ AAD8EAAAABEAAAERAAAmEQAAcxEAAHoRAACbEQAAnBEAAJ0RAAC9EQAAxhEAAN8RAADlEQAAORIA AFsSAAD15fXb9dHl0fXHvbOpx6mflZ+V5ZWfqb2LgXeBbWNtY21ZAAAAABMBCIEESAEABWjL8tSG FmhtDXcAEwEIgQRIAQAFaNLz1IYWaDN4ZQATAQiBBEgBAAVoyfLUhhZobQ13ABMBCIEESAEABWjH 8tSGFmhPR7MAEwEIgQRIAQAFaMfy1IYWaG0NdwATAQiBBEgBAAVotfLUhhZoT0ezABMBCIEESAEA BWjG8tSGFmhtDXcAEwEIgQRIAQAFaMXy1IYWaG0NdwATAQiBBEgBAAVos/LUhhZoT0ezABMBCIEE SAEABWiy8tSGFmhPR7MAEwEIgQRIAQAFaLTy1IYWaE9HswATAQiBBEgBAAVo0fPUhhZoM3hlABMB CIEESAEABWjI8tSGFmhtDXcAEwEIgQRIAQAFaLDy1IYWaHwFlgAfA2oAAAAAFmhTc9EAMEoRAE9K AABRSgAAVQgBXkoAABMBCIEESAEABWiw8tSGFmhPR7MAACJyEQAAcxEAAJwRAACdEQAAwhIAALcA AAAAAAAAAAAAAAC3AAAAAAAAAAAAAAAAbwAAAAAAAAAAAAAAACcAAAAAAAAAAAAAAAAAAAAAAAAA Rw8AQyQBRcaAAAABAMry1IYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZG0NdwAARw8AQyQBRcaAAAABAMfy1IYAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZKVr dwAARw8AQyQBRcaAAAABALTy1IYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZKVrdwAABFsSAABcEgAAZhIAAGkSAACLEgAAjBIA AKQSAACoEgAAwhIAAMMSAADEEgAAURMAAG4TAACAEwAAixMAAKoTAAAMFAAADRQAAA4UAAAVFAAA FhQAAAoVAAALFQAAlhUAAJcVAACYFQAARxYAAEgWAAD+FgAA/xYAACgXAAD16N7o1OjU6N7Nxryv mcaDxn93Z3dgxlxSTlJOUk4AAAYWaDkggAAAEwNqAAAAABZoOSCAADBKEQBVCAEGFmjqUDwAAAwV aLo7IgAWaNgbygAAHwNqAAAAABZoOSCAADBKEQBPSgAAUUoAAFUIAV5KAAAPDCoHFWjYG8oAFmjY G8oABhZopWt3AAArAAiBFWi6OyIAFmila3cAF2jYG8oAY0gBAGRoAAAAAGRoAAAAAGRonfLUhisA CIEVaLo7IgAWaKVrdwAXaAcRfQBjSAEAZGgAAAAAZGgAAAAAZGjX89SGGQEIgQRIAQAFaNfz1IYV aLo7IgAWaAcRfQATAQiBBEgBAAVo1/PUhhZoBxF9AAwVaLo7IgAWaKVrdwAADBVoujsiABZofAWW AAATAQiBBEgBAAVoyvLUhhZobQ13ABMBCIEESAEABWjL8tSGFmhtDXcAGQEIgQRIAQAFaMry1IYV aLo7IgAWaG0NdwATAQiBBEgBAAVoyfLUhhZobQ13AAAewhIAAMMSAADEEgAA5hIAAOcSAAAoEwAA oBMAAOcTAAAOFAAACxUAAAwVAAA/FQAAQBUAAIkVAACWFQAAlxUAAEcWAAD+FgAAKBcAAFEXAACu AAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAqQAAAAAA AAAAAAAAAKkAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAKkAAAAAAAAAAAAA AACpAAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAqQAA AAAAAAAAAAAAAKcAAAAAAAAAAAAAAAClAAAAAAAAAAAAAAAApQAAAAAAAAAAAAAAAKUAAAAAAAAA AAAAAAClAAAAAAAAAAAAAAAAAAAAAAESAAABAAAABA8AZ2Sla3cAUQ8AQyQBRcaAAAABAMvy1IYA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABnZDkggABvxgcBAgBpDNWmZCYBAyQBYSQBABMoFwAAKRcAAFEXAABSFwAAbxcAAHAXAACj GAAApBgAANcYAADYGAAA2RgAAPXx9fH18fXx7ekAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhZo6lA8AAAGFmjdUnIA AAYWaDkggAAAEwNqAAAAABZoOSCAADBKEQBVCAEAClEXAABvFwAANhgAAKMYAADXGAAA2BgAANkY AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9gAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAABBIAZ2RTc9EAAAESAAAGMgAxkGgBOnBzS6IAH7DQLyCw4D0hsKAFIrCg BSOQoAUkkKAFJbAAABew0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACGAhQAEgABAJwADwAEAAAAAwAAAAAABAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAABA8f8C AEQADAAAAAAAAAAAAAYATgBvAHIAbQBhAGwAAAACAAAAHABDShgAX0gBBGFKGABtSAkQbkgRBHNI CRB0SBEEAAAAAAAAAAAAAAAAAAAAAAAARABBQPL/oQBEAAwBAAAAAAAAAAAWAEQAZQBmAGEAdQBs AHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaQDz/7MAUgAMAQAAAAAAAAAA DABUAGEAYgBsAGUAIABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMA AAIACwAAACgAawD0/8EAKAAAAQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAAAAAAAABEAFpA AQDyAEQADAQAAKVrdwAAAAoAUABsAGEAaQBuACAAVABlAHgAdAAAAAIADwAUAENKFABPSgQAUUoE AF5KBABhShQASACZQAEAAgFIAAwFAABTc9EAAAAMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAA AgAQABQAQ0oQAE9KBQBRSgUAXkoFAGFKEABCACdAogARAUIADAUAAFNz0QAAABEAQwBvAG0AbQBl AG4AdAAgAFIAZQBmAGUAcgBlAG4AYwBlAAAACABDShAAYUoQADwAHkABACIBPAAMBQAAU3PRAAAA DABDAG8AbQBtAGUAbgB0ACAAVABlAHgAdAAAAAIAEgAIAENKFABhShQAQABqQCEBIgFAAAwFAABT c9EAAAAPAEMAbwBtAG0AZQBuAHQAIABTAHUAYgBqAGUAYwB0AAAAAgATAAYANQiBXAiBCABzAHAA cgBlAGMAaABlAHIAIwEAAOgCAAA5AwAAZwgAAH0IAAD7CAAAFQwAANkQAAABAHMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGKxpQ0BAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO6xpQ0BAHMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJ6xpQ0BAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANOxpQ0BAHMAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAFqypQ0BAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWypQ0BAHMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAPmypQ1kDNWmAAAAAAAAAAAAAAAAAABmDNWmAAAAAAAAAAAA AAAAAABkDNWmAAAAAAAAAAAAAAAAAABlDNWmAAAAAAAAAAAAAAAAAABnDNWmAAAAAAAAAAAAAAAA AABpDNWmAAAAAAAAAAAAAAAAAABqDNWmAAAAAAAAAAAAAAAAAAAAAAAAsAAAAGcBAACRAQAAugEA ANgBAAAMAwAAQAMAAEMDAAAAAAAA2RAAAAYAADQAAAUA/////wAAAAANAAAADgAAAEwAAACRAAAA ygAAAMsAAAC2AQAAtwEAAOcBAADoAQAAMQIAAD4CAAA/AgAAWgIAAB0DAAAeAwAAOwMAADwDAACD AwAA3QMAAMwEAAATBQAAWAUAAHgFAACtBQAArgUAAPIFAAArBgAAZgYAAGcGAACqBgAA8gYAADoH AAA7BwAAbgcAAG8HAAC4BwAA/gcAADAIAAAxCAAAaggAAGsIAAByCQAAcwkAAJwJAACdCQAAwgoA AMMKAADECgAA5goAAOcKAAAoCwAAoAsAAOcLAAAODAAACw0AAAwNAAA/DQAAQA0AAIkNAACWDQAA lw0AAEcOAAD+DgAAKA8AAFEPAABvDwAANhAAAKMQAADXEAAA2hAAAJpAAAAPMAAAAAAAAAEAAAAA AAAAAMAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJhAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA ABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAI AFjRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAiAFY0QAwADAAAAAAAAABAAAAAAAAAAAAAAAAAIgB WNEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACAAZhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY QAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAEACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmEAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAQAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYQAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJhAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAEACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmEAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAQAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAIAFjRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAgAGYQAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmkAAABIwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAASMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYQAAAEjAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABIwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJhAAAASMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAEjAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAABIwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAASMAAAAAAAAACAAAAAgAAAAAAA AAAAAAQKAAAAADAAAAAAAAAAAAAAAAAfMA4DAAAAAAAHAAAAAA0AAAAOAAAATAAAAJEAAADKAAAA ywAAALYBAAC3AQAA5wEAAOgBAAAxAgAAPgIAAD8CAABaAgAAHQMAAB4DAAA7AwAAPAMAAIMDAADd AwAAzAQAABMFAABYBQAAeAUAAK0FAACuBQAA8gUAACsGAABmBgAAZwYAAKoGAADyBgAAOgcAADsH AABuBwAAbwcAALgHAAD+BwAAMAgAADEIAABqCAAAawgAAHIJAABzCQAAnAkAAJ0JAADCCgAAwwoA AMQKAADmCgAA5woAACgLAACgCwAA5wsAAA4MAAALDQAADA0AAD8NAABADQAAiQ0AAJYNAACXDQAA Rw4AAP4OAAAoDwAAUQ8AAG8PAAA2EAAAoxAAANcQAADaEAAAmEAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAB5hAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAEACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAZhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAH mEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAeY QAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmEAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYQAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYQAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAQAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAGYQAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAZhAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAEACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmEAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAQAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYQAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAABAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAgACYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmEAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAACAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAIgAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJhAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAgAeYQAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmEAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAACAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYQAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAIAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJhAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAdY0QAwADAAAAAAAAABAAAAAAAAAAAAAAAAAAAHWNEAMAAwAAAAAAAAAQAAAAAAAAAAAAAA AACAAVjRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAgAFY0QAwADAAAAAAAAABAAAAAAAAAAAAAAAA AIABWNEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACAAVjRADAFMAAAAAAAAAEAAAACAAAAAAAAAAAA AAFY0QAwADAAAAAAAAABAAAAAAAAAAAAAAAAAIABWNEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACA BwgAAAAAMAAAAAAAAAAAAAAAAB8wjgMAAAAAAAcABgAAHgsAACgMAAA4EAAAWxIAACgXAADZGAAA DQAAABEAAAASAAAAFAAAABYAAAAYAAAAAAYAAD4KAADyDgAAchEAAMISAABRFwAA2RgAAA4AAAAQ AAAAEwAAABUAAAAXAAAAGQAAAAAGAADYGAAADwAAAA8AAPA4AAAAAAAG8BgAAAACBAAAAgAAAAEA AAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEA AAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQA AAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQD CQAAAD8DAQABAAAAEfAEAAAAAQAAAP//BwAKAAAAAAFisaUN/////wAAAAHusaUN/////wAAAAGe saUN/////wAAAAHTsaUN/////wAAAAFasqUN/////wAAAAFFsqUN/////wAAAAH5sqUN/////xwB AADgAgAANQMAAGEIAAB7CAAA8wgAABIMAACZDQAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAA ACMBAADoAgAAOQMAAGcIAAB9CAAA+wgAABUMAACZDQAAAAAAACMCAAAmAgAAKAIAACwCAACuBwAA sQcAALMHAAC3BwAA4gcAAOUHAADtBwAA8QcAAHsNAAB+DQAAgA0AAIQNAACXDQAAXg4AAGEOAAAa DwAAJg8AANoQAAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABwAcAAcAHAAHAAAA AAAFAAAADAAAAE8AAABfAAAAlAAAAJgAAAA0AgAAPQIAAEQCAABMAgAAXgIAAGACAAD7AwAA/gMA APUFAAD6BQAArQYAALMGAAD1BgAA+AYAALsHAAC+BwAAAQgAAAQIAAAxCAAAaQgAAMkKAADSCgAA KwsAADYLAACjCwAAqgsAAIwNAACVDQAAlw0AAKQQAADGEAAA2hAAAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAHAAQA BwAAAAAAjA0AAJYNAACXDQAA2A4AAP0OAADGEAAA1hAAANoQAAAHAAUABwAHAAUABwAFAAcAAAAA AJcNAACtEAAAtxAAANoQAAAHAAcABAAHAIQAAAAEAAAACAAAAOUAAAAAAAAAgwAAAJdyAADnXgEA +wkEAEU2CQCdTgwACzQQAB9TEADfBRMAYXETAKsHFABaHhYAghAYAAN2GgBXSxsATgYeAHs5HgC1 BSAAwwsiAJcdIwAkSCMAlUYmAOU9KAB+KCkAxBQyABoqMwCcYTMA/lM0ACB6NQBNEzcAhT04ACJe OQDqUDwAlns8AAtPPQBlGD8Ac3tAAKEXQQCTREIALipDAPwdRwBcb0gAGV5JAN0yTAC8CE0AYVNX AFhsVwDCb1oAyFlcAHwIXQB4HF4AiXVeAD8YYgBkFWQAgHVlADN4ZQCybGYAEDFnAA5CZwB7U2sA WittAOcpbgDZW3AAv0JxAEczcgDdUnIAQW1yANogcwAYDHQA7090AKdEdQBtDXcApWt3AKIceACa MHwAbFd8AAcRfQDCWH8AOSCAABdxhADVVYcAEFWJAKlkjABlQo0A3mqNAFcKjwBTF5EAsSyRAHwF lgDnK5YAkFmfAFh5oQBiG6IANyuiAHNLogBCbqMADCqqAOVdrAALCrMAT0ezAMN7tACJN7UA5zC2 ADlgugD0ZbsAjlzAAJFRwQDydMEAgxjKANgbygDtaMoAxxjMALhTzQANDM4AU3PRAEAB1ADTAtQA 9DHVAJMN2gA+HtsAoTfcADgH4ABsDeAANV7hAA9p4wDdROgA2mzpAHwi7ADqFO0AjVnvAE0Q8gBc bfMAKGP1AP9AAhAAAAAAAAAA2RAAAGAAABAAQAAA//8EAAAABwBVAG4AawBuAG8AdwBuAA0ATQBh AGwAYwBvAGwAbQAgAEIAZQB0AHQAcwAIAHMAcAByAGUAYwBoAGUAcgAIAHMAcAByAGUAYwBoAGUA cgD//wQACAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAwAaAHMAcAByAGUAYwBoAGUAcgAy ADAAMAA5ADAANQAwADEAVAAxADcAMQA4ADEANgA3ADcANABSDNWmAAADAP//BAAAAAAAAAAAAAAA //8AAAIA//8AAAAA//8AAAIA//8AAAAABgAAAEcWkAEAAAICBgMFBAUCAwSHegAgAAAAgAgAAAAA AAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYC BQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSH egAgAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAABHNZABgAoCAgYJBAIFCAMEvwIAoPv8 x2gQAAAAAAAAAJ8AAgAAAAAATQBTACAATQBpAG4AYwBoAG8AAAAt/zP/IAAOZh1nAAA/NZABAAAC BwMJAgIFAgQEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAA NSaQAQAAAgsGBAMFBAQCBId6AGEAAACACAAAAAAAAAD/AQEAAAAAAFQAYQBoAG8AbQBhAAAAIgAE AHGIiBgA8NACAABoAQAAAAD18tSGaQzVpgAAAAAGAFMAAAAHAgAAkAsAAAEABgAAAAQAAxAYAAAA BwIAAJALAAABAAYAAAAYAAAAAAAAACADAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAF oAW0ALQAgYEyNAAAEAAZAGQAAAAZAAAAkQ0AAJENAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAATKDUQDwEAAIAAMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJUAAAAAAp8P8PAQABPwAA5AQAAMkAAAD///9///// fwAAAAD///9/////f////3+la3cAAAAAADIAAAAAAAAAAAAAAAAAAQAAAP//EgAAAAAAAAABADIA AAAAAAAADQBNAGEAbABjAG8AbABtACAAQgBlAHQAdABzAAgAcwBwAHIAZQBjAGgAZQByAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAA AAB4AQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAApAAAAAQAAACwAAAABQAAAMgAAAAGAAAA1AAA AAcAAADgAAAACAAAAPQAAAAJAAAACAEAABIAAAAUAQAACgAAADQBAAAMAAAAQAEAAA0AAABMAQAA DgAAAFgBAAAPAAAAYAEAABAAAABoAQAAEwAAAHABAAACAAAA5wQAAB4AAAAEAAAAMgAAAB4AAAAE AAAAAAAAAB4AAAAQAAAATWFsY29sbSBCZXR0cwAAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4A AAAMAAAATm9ybWFsLmRvdAAAHgAAAAwAAABzcHJlY2hlcgAAAAAeAAAABAAAADYAAAAeAAAAGAAA AE1pY3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAAsk+YCwAAAEAAAAAAPmAQccnJAUAAAAAAJj3Y asrJAQMAAAABAAAAAwAAAAcCAAADAAAAkAsAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA9AAAAAwA AAABAAAAaAAAAA8AAABwAAAABQAAAIgAAAAGAAAAkAAAABEAAACYAAAAFwAAAKAAAAALAAAAqAAA ABAAAACwAAAAEwAAALgAAAAWAAAAwAAAAA0AAADIAAAADAAAANYAAAACAAAA5wQAAB4AAAAQAAAA Tm9ydGVsIE5ldHdvcmtzAAMAAAAYAAAAAwAAAAYAAAADAAAAkQ0AAAMAAAAPJwsACwAAAAAAAAAL AAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAIAAAAyAAwQAAACAAAAHgAAAAYAAABUaXRs ZQADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAC AAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAA AAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAA/v///xwAAAAdAAAAHgAA AB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAA /v///y4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAD+////NgAAADcAAAA4AAAAOQAAADoAAAA7 AAAAPAAAAP7////9////PwAAAP7////+/////v////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////UgBvAG8A dAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAAOGhEmvKyQFBAAAA gAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAADgACAf////8FAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABsAAACSIwAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAQAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQ0AAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBm AG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtAAAAABAAAAAAAAAFAEQAbwBj AHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAA OAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADUAAAAA EAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AQD+/wMKAAD/ ////BgkCAAAAAADAAAAAAAAARh8AAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgRG9jdW1lbnQACgAA AE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------_=_NextPart_003_01C9CA6B.1FC3B200-- ------_=_NextPart_001_01C9CBD8.A0B61A86-- From Martin.Vigoureux@alcatel-lucent.com Sun May 3 11:22:15 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41D63A6F5E for ; Sun, 3 May 2009 11:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GMEfdJ35sRn for ; Sun, 3 May 2009 11:22:08 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 1B5A728C276 for ; Sun, 3 May 2009 11:20:45 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n43IM7n6007389; Sun, 3 May 2009 20:22:08 +0200 Received: from [135.244.20.132] ([135.244.20.132]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 May 2009 20:22:07 +0200 Message-ID: <49FDE0C4.7060807@alcatel-lucent.com> Date: Sun, 03 May 2009 20:21:56 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Adrian Farrel , Malcolm Betts References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> In-Reply-To: <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 May 2009 18:22:07.0741 (UTC) FILETIME=[114142D0:01C9CC1C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 18:22:15 -0000 Adrian, Malcolm, all, here are my thoughts on this: As far as I understand, strictly speaking the Lock function does not make sense on a unidir LSP. Indeed locking is performed at the source point and so there is no need to send any message to perform that Lock. (the potentially needed message is to inform the end-point(s) of the status but that is lock notification. I'll come back to this). Therefore Lock is only needed on a bidir entity and what is exactly needed is the capability to request the other end point to admin lock its direction. Coming back to the notification, I believe the following requirement is needed: The MPLS-TP OAM toolset MUST provide a functionality to enable an End Point of a PW, LSP or Section to inform the End Point(s) of that LSP, PW, or Section that the PW, LSP or Section has been administratively shutdown at this End Point. But it is conditionally needed. This function is *only* needed if locking is achieved via Lock, otherwise if it is achieved via NMS commands we (I hope) can safely assume that: for undir LSP there will be commands at both ends, one saying lock, the other saying you are notified of other end locking. for bidir LSP there will be commands at both ends, both saying lock and you are notified of other end locking. The MUST is needed because the egress must be aware of the Lock because we expect him to then inform client MEPs that are "downstream". (see question at the end of this e-mail). The small problem I have is that this function is a notification one but really tightly linked to the Lock. In other words, I do not know where this reqs better fits (especially wrt to the conditional issue): in Lock or in Lock Notification? Opinions are welcomed. Therefore I propose: 2.2.x. Lock The MPLS-TP OAM toolset SHOULD provide a functionality to enable an End Point of a bidirectional PW, LSP or Section to request to its associated End Point that it administratively shuts down the direction of the PW, LSP or Section for which it is the head-end. This function SHOULD be performed on-demand. This function SHOULD be performed between the End Points of a PW, LSP or Section. Note that administratively shutting down corresponds to stopping user traffic being sent on the PW, LSP or Section. 2.2.y. Lock Notification The MPLS-TP OAM toolset MUST provide a function to enable End Points of a (server) LSP or Section to notify, of its administrative locking status, the End Points of (client) PWs or LSPs affected by this status. This function SHOULD be performed on-demand. This function SHOULD be performed between the End Points of a PW, LSP or Section. -comment: this needs to be rephrased as the notifying end points may not be the same nodes than the notified end points. The general case is in fact a notification between end points of different e.g., LSPs while the sentence seems to say that it is between the end-points of the same e.g., LSP. Any suggestion welcomed. See also my e-mail: MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? -question: More generally to the comment above, who should notify and who should notify whom? I would tend to say: the receiving node of a locked direction, informs downstream receiving nodes of nested LSPs. This is a Fowrward Indication and if we do so then receiving points MUST indeed be informed of a Lock (c.f. discussion at the beginning of the e-mail). Should source points (locking points) do some reverse indication and notify the source points of the LSPs that are nested in the locked LSP? (but this maybe falls in the RDI functionality). I guess that is all, sorry for this long e-mail. regards, -m Adrian Farrel a écrit : > Hi Malcolm, > >> To address the comments from Adrian I suggest the following >> text for sections 2.2.7 and 2.2.8: >> >> Note that this proposal assumes that the text related to local/remote >> faults is moved from section 2.2.8 to section 2.2.2 as proposed in my >> previous email. >> >> We probably need to discuss this text on the MEAD team call next >> week. >> >> 2.2.7. Lock >> >> The OAM toolset SHOULD provide a function enabling a network operator to >> administratively shut down a PW, LSP or Section; that is, to stop user >> traffic being sent over that PW, LSP or Section. > > This is great. > Does it mean that we do not need to add the (similar) text on CV fault > behavior in section 2.2.3? > It would seem so. > >> The lock function MAY be applied to a unidirectional or a bidirectional >> PW, LSP or Section. If the lock function is activated at the head end >> of one direction of a bidirectional PW, LSP or Section then it SHOULD be >> possible to cause the lock function to be activated at the head end of >> the other direction. >> >> This function SHOULD be performed on-demand i.e. in response to an >> operator command. > > Or also in response to configured automatic behavior? > > But this is not a protocol requirement. > >> This function SHOULD be performed between End Points of PWs, LSPs >> and Sections. >> >> 2.2.8 Notification of Lock >> >> If the lock function is supported the MPLS-TP OAM toolset MUST >> provide a function to enable the End Point at the ingress to notify the >> End Points at the egress that the lock function is active. This >> function SHOULD be performed pro-actively. >> >> The MPLS-TP OAM toolset MUST allow for the distinction between >> a fault condition and an administrative locking action. > > Works for me. > > A > > > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > From Martin.Vigoureux@alcatel-lucent.com Sun May 3 11:23:54 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58BEB3A7125 for ; Sun, 3 May 2009 11:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tkX5UFNt5IE for ; Sun, 3 May 2009 11:23:53 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 23D8428C298 for ; Sun, 3 May 2009 11:23:30 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n43IOtft008049 for ; Sun, 3 May 2009 20:24:55 +0200 Received: from [135.244.20.132] ([135.244.20.132]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 May 2009 20:24:54 +0200 Message-ID: <49FDE174.7000904@alcatel-lucent.com> Date: Sun, 03 May 2009 20:24:52 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls-interop@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2009 18:24:54.0755 (UTC) FILETIME=[74CD9330:01C9CC1C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 18:23:54 -0000 All, as part of the discussion on AIS/Lock Notification, the server layer MEPs, detecting a fault/lock condition, should inform (the MEPs of) the client layers relying on that server layer and which are affected by the condition. However as I understand it is not the MEP (sMEP) of the server layer that sends a notification to the client layers MEPs (cMEP) but the MIP (cMIP) of the client layer which is hosted on the same node than the MEP (sMEP). See the figure below (where the double dashed line is an LSP, and the ~ line represents an LSP nested in the other LSP. +------+ +------+ +------+ +------+ | | | | | cMIP |~~~~~~| cMEP | | |------| |------| ^ | | | | | | | | | | | | | |------| |------| | | | | | | | | | sMEP | | | +------+ +------+ +------+ +------+ Therefore can MIPs send OAM messages without having priorly received one or did I miss something? regards, -m From Martin.Vigoureux@alcatel-lucent.com Sun May 3 12:27:16 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3503A6FC5 for ; Sun, 3 May 2009 12:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.095 X-Spam-Level: X-Spam-Status: No, score=-6.095 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FQbo5JVEVRL for ; Sun, 3 May 2009 12:27:10 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id A281A3A70DA for ; Sun, 3 May 2009 12:25:44 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n43JR73h026726; Sun, 3 May 2009 21:27:07 +0200 Received: from [135.244.20.132] ([135.244.20.132]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 May 2009 21:27:06 +0200 Message-ID: <49FDF005.50007@alcatel-lucent.com> Date: Sun, 03 May 2009 21:27:01 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Malcolm Betts References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE0E@zcarhxm2.corp.nortel.com> In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE0E@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 May 2009 19:27:07.0278 (UTC) FILETIME=[258F62E0:01C9CC25] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] Reaction to a CV defect X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 19:27:17 -0000 Malcolm, I do not quite understand this. By this requirement we are making some assumptions on what the operator does in reaction to a CV defect and I do not believe the document should make such assumptions. We discussed during the call that we should not take any assumption on the consequent actions taken. Finally, the Lock function requirement is listed. Therefore I believe we do not need that text in the draft. regards, -m Malcolm Betts a écrit : > To capture this requirement I suggest that: > As proposed by Adrian, text for this requirement to section 2.2.3. My > proposed text is: > "When a continuity verification defect is detected the capability to > shut down the defective PW, LSP or Section MUST be provided; that is the > capability to, stop user traffic being sent from the defective PW, LSP > or Section." > > Note that the section 2.2.1 includes requirements for the notification > of defects therefore they should not be repeated in the section. > > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop From Martin.Vigoureux@alcatel-lucent.com Sun May 3 13:52:43 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B263A70DA for ; Sun, 3 May 2009 13:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.106 X-Spam-Level: X-Spam-Status: No, score=-4.106 tagged_above=-999 required=5 tests=[AWL=-1.857, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJA1LqAy+IpY for ; Sun, 3 May 2009 13:52:42 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id D8F0728C0E4 for ; Sun, 3 May 2009 13:52:32 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n43KrurV007786; Sun, 3 May 2009 22:53:56 +0200 Received: from [135.244.19.125] ([135.244.19.125]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 May 2009 22:53:56 +0200 Message-ID: <49FE045D.1060807@alcatel-lucent.com> Date: Sun, 03 May 2009 22:53:49 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Malcolm Betts References: <0BDFFF51DC89434FA33F8B37FCE363D516FDADC3@zcarhxm2.corp.nortel.com> In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516FDADC3@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 May 2009 20:53:56.0604 (UTC) FILETIME=[468F73C0:01C9CC31] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] Differentiation between local and remote faults X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 20:52:43 -0000 Malcolm, I may have missed some important point, but could you please clarify what you propose? Thanks. regards, -m Malcolm Betts a écrit : > To capture this requirement I suggest that: > > As proposed by Adrian, add the following text to section 2.2.2: > > "The mechanism provided MUST enable a node that detects a continuity > check defect to distinguish local and remote faults." > > Note that the section 2.2.1 includes requirements for the notification > of defects therefore they should not be repeated in the section. > > The current text in 2.2.8 should be deleted and replaced with a > description of reporting the lock condition (I will propose text for > this later). > > > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop From hhelvoort@chello.nl Sun May 3 15:57:47 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38343A69C6 for ; Sun, 3 May 2009 15:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Acuu3s5moAA for ; Sun, 3 May 2009 15:57:46 -0700 (PDT) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id BDBF528C276 for ; Sun, 3 May 2009 15:57:42 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090503225904.NOTX15840.viefep11-int.chello.at@edge02.upc.biz>; Mon, 4 May 2009 00:59:04 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge02.upc.biz with edge id nAz31b00n3KDBhC02Az48H; Mon, 04 May 2009 00:59:04 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FE21B7.2090605@chello.nl> Date: Mon, 04 May 2009 00:59:03 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Martin Vigoureux References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> In-Reply-To: <49FDE0C4.7060807@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 22:57:47 -0000 Bonsoir Martin, You wrote: > here are my thoughts on this: > > As far as I understand, strictly speaking the Lock function > does not make sense on a unidir LSP. Indeed locking is performed > at the source point and so there is no need to send any message > to perform that Lock. (the potentially needed message is to inform > the end-point(s) of the status but that is lock notification. > I'll come back to this). What should happen if the CP and MP are separated, i.e the ingress point and egress poinr belong to different SP domains? > Therefore Lock is only needed on a bidir entity and what is exactly > needed is the capability to request the other end point to admin lock > its direction. What do you mean by "its direction", the direction from "the other end point" back to the "source point"? > Coming back to the notification, I believe the following requirement > is needed: > The MPLS-TP OAM toolset MUST provide a functionality to enable an > End Point of a PW, LSP or Section to inform the End Point(s) of that > LSP, PW, or Section that the PW, LSP or Section has been > administratively shutdown at this End Point. > But it is conditionally needed. This function is *only* needed if > locking is achieved via Lock, otherwise if it is achieved via NMS > commands This requires that both end points can be reached via the MP. > we (I hope) can safely assume that: > for undir LSP there will be commands at both ends, one saying lock, the > other saying you are notified of other end locking. > for bidir LSP there will be commands at both ends, both saying lock and > you are notified of other end locking. > > The MUST is needed because the egress must be aware of the Lock because > we expect him to then inform client MEPs that are "downstream". (see > question at the end of this e-mail). > > The small problem I have is that this function is a notification > one but really tightly linked to the Lock. In other words, I do > not know where this reqs better fits (especially wrt to the conditional > issue): in Lock or in Lock Notification? > Opinions are welcomed. > > Therefore I propose: > > 2.2.x. Lock > The MPLS-TP OAM toolset SHOULD provide a functionality to enable an > End Point of a bidirectional PW, LSP or Section to request to its > associated End Point that it administratively shuts down the direction > of the PW, LSP or Section for which it is the head-end. > > This function SHOULD be performed on-demand. > > This function SHOULD be performed between the End Points of a PW, LSP > or Section. > > Note that administratively shutting down corresponds to stopping user > traffic being sent on the PW, LSP or Section. > > > 2.2.y. Lock Notification > The MPLS-TP OAM toolset MUST provide a function to enable End Points > of a (server) LSP or Section to notify, of its administrative locking > status, the End Points of (client) PWs or LSPs affected by this status. > > This function SHOULD be performed on-demand. > > This function SHOULD be performed between the End Points of a PW, LSP > or Section. > -comment: > this needs to be rephrased as the notifying end points may not be > the same nodes than the notified end points. > The general case is in fact a notification between end points of > different e.g., LSPs while the sentence seems to say that it is between > the end-points of the same e.g., LSP. > Any suggestion welcomed. Snip -- I will answer the next in a separate email-- Regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From hhelvoort@chello.nl Sun May 3 16:07:58 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30843A6C19 for ; Sun, 3 May 2009 16:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4BcF5VEv+IK for ; Sun, 3 May 2009 16:07:58 -0700 (PDT) Received: from viefep14-int.chello.at (viefep14-int.chello.at [62.179.121.34]) by core3.amsl.com (Postfix) with ESMTP id 8F5933A6B4D for ; Sun, 3 May 2009 16:07:57 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep14-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090503230921.PVFJ10055.viefep14-int.chello.at@edge01.upc.biz>; Mon, 4 May 2009 01:09:21 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge01.upc.biz with edge id nB9K1b02w3KDBhC01B9MPH; Mon, 04 May 2009 01:09:21 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FE241F.5080007@chello.nl> Date: Mon, 04 May 2009 01:09:19 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Martin Vigoureux References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> In-Reply-To: <49FDE0C4.7060807@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 23:07:58 -0000 Bonsoir Martin, To continue with the othe rquestion: > See also my e-mail: > MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" > OAM messages ? The answer was no. > -question: > More generally to the comment above, who should notify and who should > notify whom? > I would tend to say: > the receiving node of a locked direction, informs downstream receiving > nodes of nested LSPs. To be more exact, the sink side of a locked LSP, PW, Section, has to inform its clients. > This is a Fowrward Indication and if we do > so then receiving points MUST indeed be informed of a Lock (c.f. > discussion at the beginning of the e-mail). > Should source points (locking points) do some reverse indication and > notify the source points of the LSPs that are nested in the locked LSP? > (but this maybe falls in the RDI functionality). Isn't this notification already caused by the locking at the far end? Or is the locking only applied in one direction of a bi-directional path? If yes, then the notification is not required. Cheers, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From hhelvoort@chello.nl Sun May 3 16:12:44 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76513A6E95 for ; Sun, 3 May 2009 16:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqEEhEWzFYln for ; Sun, 3 May 2009 16:12:44 -0700 (PDT) Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id 8C3263A6CA5 for ; Sun, 3 May 2009 16:12:43 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090503231407.VRUS10095.viefep16-int.chello.at@edge04.upc.biz>; Mon, 4 May 2009 01:14:07 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge04.upc.biz with edge id nBE61b00l3KDBhC04BE7WE; Mon, 04 May 2009 01:14:07 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FE253E.5060803@chello.nl> Date: Mon, 04 May 2009 01:14:06 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Martin Vigoureux References: <49FDE174.7000904@alcatel-lucent.com> In-Reply-To: <49FDE174.7000904@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 23:12:44 -0000 Bonsoir Martin, You wrote: > as part of the discussion on AIS/Lock Notification, > the server layer MEPs, detecting a fault/lock condition, should > inform (the MEPs of) the client layers relying on that > server layer and which are affected by the condition. > > However as I understand it is not the MEP (sMEP) of the > server layer that sends a notification to the client layers > MEPs (cMEP) but the MIP (cMIP) of the client layer which > is hosted on the same node than the MEP (sMEP). > See the figure below (where the double dashed line is > an LSP, and the ~ line represents an LSP nested in the > other LSP. > > +------+ +------+ +------+ +------+ > | |------| |------| cMIP |~~~~~~| cMEP | > | | | | | ^ | | | > | | | | | | | | | > | | | | | | | | | > | |======| |======| sMEP | | | > +------+ +------+ +------+ +------+ I modified the figure to align with what you wrote. > Therefore can MIPs send OAM messages without having priorly received one > or did I miss something? No, a MIP can only respond to messages it receives from a MEP that has the same MEG level, i.e. exists in the same path. In your figure the cMIP ignores messages sent by sMEP. Cheers, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From nurit.sprecher@nsn.com Sun May 3 23:09:38 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A013A6C46 for ; Sun, 3 May 2009 23:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQOiMC1rfXZC for ; Sun, 3 May 2009 23:09:31 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 831B43A6950 for ; Sun, 3 May 2009 23:08:41 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n4469x7S021791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2009 08:09:59 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n4469wQa011879; Mon, 4 May 2009 08:09:59 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 08:09:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 08:09:55 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A754DA@DEMUEXC014.nsn-intra.net> In-Reply-To: <49FE21B7.2090605@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock Thread-Index: AcnMQsynGIqM3jHPT/mViHwr9mwQxgAO9FEQ References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com> <49FE21B7.2090605@chello.nl> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , "Martin Vigoureux" X-OriginalArrivalTime: 04 May 2009 06:09:58.0878 (UTC) FILETIME=[F40677E0:01C9CC7E] Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 06:09:38 -0000 Huub,=20 I do not understand why you say that the separation of a CP and MP indicates that the ingress and the egress point belong to different SP domains? =20 Best regards, Nurit -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Huub van Helvoort Sent: Monday, May 04, 2009 1:59 AM To: Martin Vigoureux Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock Bonsoir Martin, You wrote: > here are my thoughts on this: >=20 > As far as I understand, strictly speaking the Lock function > does not make sense on a unidir LSP. Indeed locking is performed > at the source point and so there is no need to send any message > to perform that Lock. (the potentially needed message is to inform > the end-point(s) of the status but that is lock notification. > I'll come back to this). What should happen if the CP and MP are separated, i.e the ingress point and egress poinr belong to different SP domains? > Therefore Lock is only needed on a bidir entity and what is exactly > needed is the capability to request the other end point to admin lock > its direction. What do you mean by "its direction", the direction from "the other end point" back to the "source point"? > Coming back to the notification, I believe the following requirement > is needed: > The MPLS-TP OAM toolset MUST provide a functionality to enable an > End Point of a PW, LSP or Section to inform the End Point(s) of that > LSP, PW, or Section that the PW, LSP or Section has been > administratively shutdown at this End Point. > But it is conditionally needed. This function is *only* needed if > locking is achieved via Lock, otherwise if it is achieved via NMS > commands This requires that both end points can be reached via the MP. > we (I hope) can safely assume that: > for undir LSP there will be commands at both ends, one saying lock, the=20 > other saying you are notified of other end locking. > for bidir LSP there will be commands at both ends, both saying lock and=20 > you are notified of other end locking. >=20 > The MUST is needed because the egress must be aware of the Lock because > we expect him to then inform client MEPs that are "downstream". (see > question at the end of this e-mail). >=20 > The small problem I have is that this function is a notification > one but really tightly linked to the Lock. In other words, I do > not know where this reqs better fits (especially wrt to the conditional > issue): in Lock or in Lock Notification? > Opinions are welcomed. >=20 > Therefore I propose: >=20 > 2.2.x. Lock > The MPLS-TP OAM toolset SHOULD provide a functionality to enable an > End Point of a bidirectional PW, LSP or Section to request to its > associated End Point that it administratively shuts down the direction > of the PW, LSP or Section for which it is the head-end. >=20 > This function SHOULD be performed on-demand. >=20 > This function SHOULD be performed between the End Points of a PW, LSP > or Section. >=20 > Note that administratively shutting down corresponds to stopping user=20 > traffic being sent on the PW, LSP or Section. >=20 >=20 > 2.2.y. Lock Notification > The MPLS-TP OAM toolset MUST provide a function to enable End Points > of a (server) LSP or Section to notify, of its administrative locking > status, the End Points of (client) PWs or LSPs affected by this status. >=20 > This function SHOULD be performed on-demand. >=20 > This function SHOULD be performed between the End Points of a PW, LSP > or Section. > -comment: > this needs to be rephrased as the notifying end points may not be > the same nodes than the notified end points. > The general case is in fact a notification between end points of=20 > different e.g., LSPs while the sentence seems to say that it is between > the end-points of the same e.g., LSP. > Any suggestion welcomed. Snip -- I will answer the next in a separate email-- Regards, Huub. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From nurit.sprecher@nsn.com Sun May 3 23:16:47 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38E63A683D for ; Sun, 3 May 2009 23:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3w3adir5h9RZ for ; Sun, 3 May 2009 23:16:46 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 620943A68C8 for ; Sun, 3 May 2009 23:16:41 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n446I2rT009308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2009 08:18:02 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n446I297008019; Mon, 4 May 2009 08:18:02 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 08:18:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 08:18:01 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net> In-Reply-To: <49FE241F.5080007@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock Thread-Index: AcnMRDWaJxXBJjUiTEW6/qdA75uB6AAOtxGA References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com> <49FE241F.5080007@chello.nl> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , "Martin Vigoureux" X-OriginalArrivalTime: 04 May 2009 06:18:02.0287 (UTC) FILETIME=[1428D3F0:01C9CC80] Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 06:16:47 -0000 You say " To be more exact, the sink side of a locked LSP, PW, Section, has to inform its clients.", BUT the client is not necessarily an endpoint but may be an intermediate point, and it needs to notify its endpoints, that means that a MIP generates an OAM message. Long ago I discussed this point with Italo and he indicated to me that it is not a generation of a message by a MIP BUT it is a variation of an adaptation function at the client intermediate point. Although we are talking here about a way to implement it, this is a conceptual issue that we need to agree on. Also, I think we should generalize the discussion instead of talking every time about LSP, PW, section, etc. we should really talk about client/server layers to cover cases of LSP hierarchies, etc.=20 Best regards, Nurit -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Huub van Helvoort Sent: Monday, May 04, 2009 2:09 AM To: Martin Vigoureux Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock Bonsoir Martin, To continue with the othe rquestion: > See also my e-mail: > MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited"=20 > OAM messages ? The answer was no. > -question: > More generally to the comment above, who should notify and who should > notify whom? > I would tend to say: > the receiving node of a locked direction, informs downstream receiving > nodes of nested LSPs.=20 To be more exact, the sink side of a locked LSP, PW, Section, has to inform its clients. > This is a Fowrward Indication and if we do > so then receiving points MUST indeed be informed of a Lock (c.f. > discussion at the beginning of the e-mail). > Should source points (locking points) do some reverse indication and > notify the source points of the LSPs that are nested in the locked LSP? > (but this maybe falls in the RDI functionality). Isn't this notification already caused by the locking at the far end? Or is the locking only applied in one direction of a bi-directional path? If yes, then the notification is not required. Cheers, Huub. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From nurit.sprecher@nsn.com Sun May 3 23:22:00 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382573A7087 for ; Sun, 3 May 2009 23:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.408 X-Spam-Level: X-Spam-Status: No, score=-5.408 tagged_above=-999 required=5 tests=[AWL=1.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PasvXfn-XID for ; Sun, 3 May 2009 23:21:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 02C3F3A6A68 for ; Sun, 3 May 2009 23:20:44 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n446M65g017038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2009 08:22:06 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n446M60N021425; Mon, 4 May 2009 08:22:06 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 08:22:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CC80.A5695806" Date: Mon, 4 May 2009 08:22:04 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A754E7@DEMUEXC014.nsn-intra.net> In-Reply-To: <49FDE0C4.7060807@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock Thread-Index: AcnMHEui4+8dSk+PTry7huTVsC/F3QAY95BQ References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com><42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Martin Vigoureux" , "Adrian Farrel" , "Malcolm Betts" X-OriginalArrivalTime: 04 May 2009 06:22:05.0915 (UTC) FILETIME=[A55F82B0:01C9CC80] Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 06:22:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CC80.A5695806 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Would not it be fair to say the following? * lock is sent between endpoints (at the same layer) to = synchronizes the lock status (either when the configuration is performed = at one end, or to ensure that it was configured consistently at both = ends). * Lock indication is sent by an endpoint of a server layer to = its clients' endpoints to inform of the administrative lock status?=20 =20 =20 -----Original Message----- From: mpls-interop-bounces@ietf.org = [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Martin Vigoureux Sent: Sunday, May 03, 2009 9:22 PM To: Adrian Farrel; Malcolm Betts Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and = notification of lock =20 Adrian, Malcolm, all, =20 here are my thoughts on this: =20 As far as I understand, strictly speaking the Lock function does not make sense on a unidir LSP. Indeed locking is performed at the source point and so there is no need to send any message to perform that Lock. (the potentially needed message is to inform the end-point(s) of the status but that is lock notification. I'll come back to this). Therefore Lock is only needed on a bidir entity and what is exactly needed is the capability to request the other end point to admin lock its direction. =20 Coming back to the notification, I believe the following requirement is needed: The MPLS-TP OAM toolset MUST provide a functionality to enable an End Point of a PW, LSP or Section to inform the End Point(s) of that LSP, PW, or Section that the PW, LSP or Section has been administratively shutdown at this End Point. But it is conditionally needed. This function is *only* needed if locking is achieved via Lock, otherwise if it is achieved via NMS commands we (I hope) can safely assume that: for undir LSP there will be commands at both ends, one saying lock, the=20 other saying you are notified of other end locking. for bidir LSP there will be commands at both ends, both saying lock and=20 you are notified of other end locking. =20 The MUST is needed because the egress must be aware of the Lock because we expect him to then inform client MEPs that are "downstream". (see question at the end of this e-mail). =20 The small problem I have is that this function is a notification one but really tightly linked to the Lock. In other words, I do not know where this reqs better fits (especially wrt to the conditional issue): in Lock or in Lock Notification? Opinions are welcomed. =20 Therefore I propose: =20 2.2.x. Lock The MPLS-TP OAM toolset SHOULD provide a functionality to enable an End Point of a bidirectional PW, LSP or Section to request to its associated End Point that it administratively shuts down the direction of the PW, LSP or Section for which it is the head-end. =20 This function SHOULD be performed on-demand. =20 This function SHOULD be performed between the End Points of a PW, LSP or Section. =20 Note that administratively shutting down corresponds to stopping user=20 traffic being sent on the PW, LSP or Section. =20 =20 2.2.y. Lock Notification The MPLS-TP OAM toolset MUST provide a function to enable End Points of a (server) LSP or Section to notify, of its administrative locking status, the End Points of (client) PWs or LSPs affected by this status. =20 This function SHOULD be performed on-demand. =20 This function SHOULD be performed between the End Points of a PW, LSP or Section. -comment: this needs to be rephrased as the notifying end points may not be the same nodes than the notified end points. The general case is in fact a notification between end points of=20 different e.g., LSPs while the sentence seems to say that it is between the end-points of the same e.g., LSP. Any suggestion welcomed. =20 See also my e-mail: MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited"=20 OAM messages ? =20 -question: More generally to the comment above, who should notify and who should notify whom? I would tend to say: the receiving node of a locked direction, informs downstream receiving nodes of nested LSPs. This is a Fowrward Indication and if we do so then receiving points MUST indeed be informed of a Lock (c.f. discussion at the beginning of the e-mail). Should source points (locking points) do some reverse indication and notify the source points of the LSPs that are nested in the locked LSP? (but this maybe falls in the RDI functionality). =20 I guess that is all, sorry for this long e-mail. =20 regards, -m =20 =20 Adrian Farrel a =E9crit : > Hi Malcolm, >=20 >> To address the comments from Adrian I suggest the following >> text for sections 2.2.7 and 2.2.8: >>=20 >> Note that this proposal assumes that the text related to local/remote >> faults is moved from section 2.2.8 to section 2.2.2 as proposed in my >> previous email. >>=20 >> We probably need to discuss this text on the MEAD team call next >> week. >>=20 >> 2.2.7. Lock >>=20 >> The OAM toolset SHOULD provide a function enabling a network operator = to >> administratively shut down a PW, LSP or Section; that is, to stop = user >> traffic being sent over that PW, LSP or Section. >=20 > This is great. > Does it mean that we do not need to add the (similar) text on CV fault = > behavior in section 2.2.3? > It would seem so. >=20 >> The lock function MAY be applied to a unidirectional or a = bidirectional >> PW, LSP or Section. If the lock function is activated at the head = end >> of one direction of a bidirectional PW, LSP or Section then it SHOULD = be >> possible to cause the lock function to be activated at the head end = of >> the other direction. >>=20 >> This function SHOULD be performed on-demand i.e. in response to an >> operator command. >=20 > Or also in response to configured automatic behavior? >=20 > But this is not a protocol requirement. >=20 >> This function SHOULD be performed between End Points of PWs, LSPs >> and Sections. >>=20 >> 2.2.8 Notification of Lock >>=20 >> If the lock function is supported the MPLS-TP OAM toolset MUST >> provide a function to enable the End Point at the ingress to notify = the >> End Points at the egress that the lock function is active. This >> function SHOULD be performed pro-actively. >>=20 >> The MPLS-TP OAM toolset MUST allow for the distinction between >> a fault condition and an administrative locking action. >=20 > Works for me. >=20 > A >=20 >=20 >=20 > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop >=20 _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_001_01C9CC80.A5695806 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Would not it be fair to say the = following?

=B7         lock is = sent between endpoints (at the same layer) to synchronizes the lock status (either = when the configuration is performed at one end, or to ensure that it was configured = consistently at both ends).

=B7         Lock = indication is sent by an endpoint of a server layer to its clients' endpoints to = inform of the administrative lock status?

 

 

-----Original Message-----
From: mpls-interop-bounces@ietf.org = [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Martin Vigoureux
Sent: Sunday, May 03, 2009 9:22 PM
To: Adrian Farrel; Malcolm Betts
Cc: mpls-interop@ietf.org
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and = notification of lock

 

Adrian, Malcolm, all,

 

here are my thoughts on this:

 

As far as I understand, strictly speaking the Lock = function

does not make sense on a unidir LSP. Indeed locking is = performed

at the source point and so there is no need to send any = message

to perform that Lock. (the potentially needed message is to = inform

the end-point(s) of the status but that is lock = notification.

I'll come back to this).

Therefore Lock is only needed on a bidir entity and what is = exactly

needed is the capability to request the other end point to admin = lock

its direction.

 

Coming back to the notification, I believe the following = requirement

is needed:

=A0=A0=A0 The MPLS-TP OAM toolset MUST provide a functionality = to enable an

=A0=A0=A0 End Point of a PW, LSP or Section to inform the End = Point(s) of that

=A0=A0=A0 LSP, PW, or Section that the PW, LSP or Section has = been

=A0=A0=A0 administratively shutdown at this End = Point.

But it is conditionally needed. This function is *only* needed = if

locking is achieved via Lock, otherwise if it is achieved via = NMS

commands we (I hope) can safely assume = that:

for undir LSP there will be commands at both ends, one saying = lock, the

other saying you are notified of other end = locking.

for bidir LSP there will be commands at both ends, both saying = lock and

you are notified of other end = locking.

 

The MUST is needed because the egress must be aware of the Lock = because

we expect him to then inform client MEPs that are "downstream". (see

question at the end of this = e-mail).

 

The small problem I have is that this function is a = notification

one but really tightly linked to the Lock. In other words, I = do

not know where this reqs better fits (especially wrt to the = conditional

issue): in Lock or in Lock = Notification?

Opinions are welcomed.

 

Therefore I propose:

 

2.2.x.=A0 Lock

The MPLS-TP OAM toolset SHOULD provide a functionality to enable = an

End Point of a bidirectional PW, LSP or Section to request to = its

associated End Point that it administratively shuts down the = direction

of the PW, LSP or Section for which it is the = head-end.

 

This function SHOULD be performed = on-demand.

 

This function SHOULD be performed between the End Points of a = PW, LSP

or Section.

 

Note that administratively shutting down corresponds to stopping = user

traffic being sent on the PW, LSP or = Section.

 

 

2.2.y.=A0 Lock Notification

The MPLS-TP OAM toolset MUST provide a function to enable End = Points

of a (server) LSP or Section to notify, of its administrative = locking

status, the End Points of (client) PWs or LSPs affected by this = status.

 

This function SHOULD be performed = on-demand.

 

This function SHOULD be performed between the End Points of a = PW, LSP

or Section.

-comment:

this needs to be rephrased as the notifying end points may not = be

the same nodes than the notified end = points.

The general case is in fact a notification between end points of =

different e.g., LSPs while the sentence seems to say that it is = between

the end-points of the same e.g., = LSP.

Any suggestion welcomed.

 

See also my e-mail:

MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited"

OAM messages ?

 

-question:

More generally to the comment above, who should notify and who = should

notify whom?

I would tend to say:

the receiving node of a locked direction, informs downstream = receiving

nodes of nested LSPs. This is a Fowrward Indication and if we = do

so then receiving points MUST indeed be informed of a Lock = (c.f.

discussion at the beginning of the = e-mail).

Should source points (locking points) do some reverse indication = and

notify the source points of the LSPs that are nested in the = locked LSP?

(but this maybe falls in the RDI = functionality).

 

I guess that is all, sorry for this long = e-mail.

 

regards,

-m

 

 

Adrian Farrel a =E9crit :

> Hi Malcolm,

>

>> To address the comments from Adrian I suggest the = following

>> text for sections 2.2.7 and = 2.2.8:

>> 

>> Note that this proposal assumes that the text related = to local/remote

>> faults is moved from section 2.2.8 to section 2.2.2 as proposed in my

>> previous email.

>> 

>> We probably need to discuss this text on the MEAD team = call next

>> week.

>> 

>> 2.2.7.=A0 Lock

>> 

>> The OAM toolset SHOULD provide a function enabling a = network operator to

>> administratively shut down a PW, LSP or Section; that = is, to stop user

>> traffic being sent over that PW, LSP or = Section.

>

> This is great.

> Does it mean that we do not need to add the (similar) text = on CV fault

> behavior in section 2.2.3?

> It would seem so.

>

>> The lock function MAY be applied to a unidirectional or = a bidirectional

>> PW, LSP or Section.=A0 If the lock function is = activated at the head end

>> of one direction of a bidirectional PW, LSP or Section = then it SHOULD be

>> possible to cause the lock function to be activated at = the head end of

>> the other direction.

>> 

>> This function SHOULD be performed on-demand i.e. in = response to an

>> operator command.

>

> Or also in response to configured automatic = behavior?

>

> But this is not a protocol = requirement.

>

>> This function SHOULD be performed between End Points of = PWs, LSPs

>> and Sections.

>> 

>> 2.2.8 Notification of Lock

>> 

>> If the lock function is supported the MPLS-TP OAM = toolset MUST

>> provide a function to enable the End Point at the = ingress to notify the

>> End Points at the egress that the lock function is = active.=A0 This

>> function SHOULD be performed = pro-actively.

>> 

>> The MPLS-TP OAM toolset MUST allow for the distinction = between

>> a fault condition and an administrative locking = action.

>

> Works for me.

>

> A

>

>

>

> = _______________________________________________<= /p>

> Mpls-interop mailing list

> Mpls-interop@ietf.org

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

>

_______________________________________________=

Mpls-interop mailing list

Mpls-interop@ietf.org

https://www.ietf.org/mailman/listinfo/mpls-interop

------_=_NextPart_001_01C9CC80.A5695806-- From hhelvoort@chello.nl Mon May 4 00:13:45 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4FB13A6BFE for ; Mon, 4 May 2009 00:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTEPw-9ls1hZ for ; Mon, 4 May 2009 00:13:44 -0700 (PDT) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id 48D273A69CC for ; Mon, 4 May 2009 00:13:03 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep17-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090504071428.LJMO29379.viefep17-int.chello.at@edge05.upc.biz> for ; Mon, 4 May 2009 09:14:28 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge05.upc.biz with edge id nKES1b03j3KDBhC05KET2k; Mon, 04 May 2009 09:14:28 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FE95D2.5070103@chello.nl> Date: Mon, 04 May 2009 09:14:26 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 CC: mpls-interop@ietf.org References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com> <49FE21B7.2090605@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A754DA@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A754DA@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 07:13:45 -0000 Hi Nurit, You wrote: >> here are my thoughts on this: >> >> As far as I understand, strictly speaking the Lock function >> does not make sense on a unidir LSP. Indeed locking is performed >> at the source point and so there is no need to send any message >> to perform that Lock. (the potentially needed message is to inform >> the end-point(s) of the status but that is lock notification. >> I'll come back to this). > > What should happen if the CP and MP are separated, i.e the > ingress point and egress poinr belong to different SP domains? I do not understand why you say that the separation of a CP and MP indicates that the ingress and the egress point belong to different SP domains? [hvh] because I should have used e.g. instead of i.e (it was late). So there are cases that the lock in dication can only be transferred via the DP. Regards, Huub. >> Therefore Lock is only needed on a bidir entity and what is exactly >> needed is the capability to request the other end point to admin lock >> its direction. > > What do you mean by "its direction", the direction from "the > other end point" back to the "source point"? > >> Coming back to the notification, I believe the following requirement >> is needed: >> The MPLS-TP OAM toolset MUST provide a functionality to enable an >> End Point of a PW, LSP or Section to inform the End Point(s) of > that >> LSP, PW, or Section that the PW, LSP or Section has been >> administratively shutdown at this End Point. >> But it is conditionally needed. This function is *only* needed if >> locking is achieved via Lock, otherwise if it is achieved via NMS >> commands > > This requires that both end points can be reached via the MP. > >> we (I hope) can safely assume that: >> for undir LSP there will be commands at both ends, one saying lock, > the >> other saying you are notified of other end locking. >> for bidir LSP there will be commands at both ends, both saying lock > and >> you are notified of other end locking. >> >> The MUST is needed because the egress must be aware of the Lock > because >> we expect him to then inform client MEPs that are "downstream". (see >> question at the end of this e-mail). >> >> The small problem I have is that this function is a notification >> one but really tightly linked to the Lock. In other words, I do >> not know where this reqs better fits (especially wrt to the > conditional >> issue): in Lock or in Lock Notification? >> Opinions are welcomed. >> >> Therefore I propose: >> >> 2.2.x. Lock >> The MPLS-TP OAM toolset SHOULD provide a functionality to enable an >> End Point of a bidirectional PW, LSP or Section to request to its >> associated End Point that it administratively shuts down the direction >> of the PW, LSP or Section for which it is the head-end. >> >> This function SHOULD be performed on-demand. >> >> This function SHOULD be performed between the End Points of a PW, LSP >> or Section. >> >> Note that administratively shutting down corresponds to stopping user >> traffic being sent on the PW, LSP or Section. >> >> >> 2.2.y. Lock Notification >> The MPLS-TP OAM toolset MUST provide a function to enable End Points >> of a (server) LSP or Section to notify, of its administrative locking >> status, the End Points of (client) PWs or LSPs affected by this > status. >> This function SHOULD be performed on-demand. >> >> This function SHOULD be performed between the End Points of a PW, LSP >> or Section. >> -comment: >> this needs to be rephrased as the notifying end points may not be >> the same nodes than the notified end points. >> The general case is in fact a notification between end points of >> different e.g., LSPs while the sentence seems to say that it is > between >> the end-points of the same e.g., LSP. >> Any suggestion welcomed. > > Snip -- I will answer the next in a separate email-- > > Regards, Huub. > -- ================================================================ Always remember that you are unique...just like everyone else... From hhelvoort@chello.nl Mon May 4 00:25:30 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3B43A6988 for ; Mon, 4 May 2009 00:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCrnLbcn6ia3 for ; Mon, 4 May 2009 00:25:24 -0700 (PDT) Received: from viefep13-int.chello.at (viefep13-int.chello.at [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id 5DA753A67D1 for ; Mon, 4 May 2009 00:25:21 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep13-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090504072644.EROP25679.viefep13-int.chello.at@edge05.upc.biz> for ; Mon, 4 May 2009 09:26:44 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge05.upc.biz with edge id nKSi1b0663KDBhC05KSjh9; Mon, 04 May 2009 09:26:44 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FE98B2.5080801@chello.nl> Date: Mon, 04 May 2009 09:26:42 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mpls-interop@ietf.org References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com> <49FE241F.5080007@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 07:25:30 -0000 Hello Nurit, You wrote: > To continue with the othe rquestion: > >> See also my e-mail: >> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" >> OAM messages ? > > The answer was no. > >> -question: >> More generally to the comment above, who should notify and who should >> notify whom? >> I would tend to say: >> the receiving node of a locked direction, informs downstream receiving >> nodes of nested LSPs. > > To be more exact, the sink side of a locked LSP, PW, Section, has to > inform its clients. You say " To be more exact, the sink side of a locked LSP, PW, Section, has to inform its clients.", [hvh] it should inform its client transport entities in the server/client relation BUT the client is not necessarily an endpoint but may be an intermediate point, and it needs to notify its endpoints, that means that a MIP generates an OAM message. [hvh this requires that a MIP has the capability to send OAM messages based on management command or based on an indication of a MEP in a different layer. This also requires that at every MEP location there are also MIPs for every client entity serviced by that MEP. Long ago I discussed this point with Italo and he indicated to me that it is not a generation of a message by a MIP BUT it is a variation of an adaptation function at the client intermediate point. Although we are talking here about a way to implement it, this is a conceptual issue that we need to agree on. [hvh] I agree with Italo. Also, I think we should generalize the discussion instead of talking every time about LSP, PW, section, etc. we should really talk about client/server layers to cover cases of LSP hierarchies, etc. [hvh] then I use server/client path/trail the next time, OK? Regards, Huub. >> This is a Fowrward Indication and if we do >> so then receiving points MUST indeed be informed of a Lock (c.f. >> discussion at the beginning of the e-mail). >> Should source points (locking points) do some reverse indication and >> notify the source points of the LSPs that are nested in the locked > LSP? >> (but this maybe falls in the RDI functionality). > > Isn't this notification already caused by the locking at the > far end? > Or is the locking only applied in one direction of a bi-directional > path? If yes, then the notification is not required. > > Cheers, Huub. > -- ================================================================ Always remember that you are unique...just like everyone else... From nurit.sprecher@nsn.com Mon May 4 00:47:11 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3673A690B for ; Mon, 4 May 2009 00:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQZnYbHSwAoq for ; Mon, 4 May 2009 00:47:09 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 201C63A680D for ; Mon, 4 May 2009 00:46:08 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n447lV6b015246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2009 09:47:31 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n447lTTG027555; Mon, 4 May 2009 09:47:31 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 09:47:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 09:47:27 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net> In-Reply-To: <49FE98B2.5080801@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock Thread-Index: AcnMibd+2qVOSWcIR5GzbLZ+V24I5QAANxMQ References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net> <49FE98B2.5080801@chello.nl> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , X-OriginalArrivalTime: 04 May 2009 07:47:30.0044 (UTC) FILETIME=[93978BC0:01C9CC8C] Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 07:47:11 -0000 Huub,=20 You say " this requires that a MIP has the capability to send OAM messages based on management command or based on an indication of a MEP in a different layer. This also requires that at every MEP location there are also MIPs for every client entity serviced by that MEP." This looks more as an implementation description. What is actually required is that the endpoints of the client layer are informed of this event.=20 The way you describe it seems a little bit "against" the framework in which it is specified that OAM messages cannot be initiated by MIPs. That is why we actually say that this is an adaptation function, that means that the message is initiated by the MEP of the server to the MEP of the client....... Best regards, NUrit -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Huub van Helvoort Sent: Monday, May 04, 2009 10:27 AM To: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock Hello Nurit, You wrote: > To continue with the othe rquestion: >=20 >> See also my e-mail: >> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" >> OAM messages ? >=20 > The answer was no. >=20 >> -question: >> More generally to the comment above, who should notify and who should >> notify whom? >> I would tend to say: >> the receiving node of a locked direction, informs downstream receiving >> nodes of nested LSPs.=20 >=20 > To be more exact, the sink side of a locked LSP, PW, Section, has to > inform its clients. You say " To be more exact, the sink side of a locked LSP, PW, Section, has to inform its clients.", [hvh] it should inform its client transport entities in the server/client relation BUT the client is not necessarily an endpoint but may be an intermediate point, and it needs to notify its endpoints, that means that a MIP generates an OAM message. [hvh this requires that a MIP has the capability to send OAM messages based on management command or based on an indication of a MEP in a different layer. This also requires that at every MEP location there are also MIPs for every client entity serviced by that MEP. Long ago I discussed this point with Italo and he indicated to me that it is not a generation of a message by a MIP BUT it is a variation of an adaptation function at the client intermediate point. Although we are talking here about a way to implement it, this is a conceptual issue that we need to agree on. [hvh] I agree with Italo. Also, I think we should generalize the discussion instead of talking every time about LSP, PW, section, etc. we should really talk about client/server layers to cover cases of LSP hierarchies, etc. [hvh] then I use server/client path/trail the next time, OK? Regards, Huub. >> This is a Fowrward Indication and if we do >> so then receiving points MUST indeed be informed of a Lock (c.f. >> discussion at the beginning of the e-mail). >> Should source points (locking points) do some reverse indication and >> notify the source points of the LSPs that are nested in the locked > LSP? >> (but this maybe falls in the RDI functionality). >=20 > Isn't this notification already caused by the locking at the > far end? > Or is the locking only applied in one direction of a bi-directional > path? If yes, then the notification is not required. >=20 > Cheers, Huub. >=20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From hhelvoort@chello.nl Mon May 4 02:27:10 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E292F3A6905 for ; Mon, 4 May 2009 02:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+ulTBxS3Inc for ; Mon, 4 May 2009 02:27:05 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id 13B403A6B22 for ; Mon, 4 May 2009 02:26:16 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090504092740.IOVH17051.viefep18-int.chello.at@edge03.upc.biz> for ; Mon, 4 May 2009 11:27:40 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge03.upc.biz with edge id nMTe1b03F3KDBhC03MTfSQ; Mon, 04 May 2009 11:27:40 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FEB4FB.2010804@chello.nl> Date: Mon, 04 May 2009 11:27:23 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mpls-interop@ietf.org References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net> <49FE98B2.5080801@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 09:27:11 -0000 Hi Nurit, > You say " this requires that a MIP has the capability to send OAM > messages based on management command or based on an indication of a MEP > in a different layer. This also requires that at every MEP location > there are also MIPs for every client entity serviced by that MEP." Yes, it was a response to your: > BUT the client is not necessarily an > endpoint but may be an intermediate point, and it needs to notify its > endpoints, that means that a MIP generates an OAM message. This is the disadvantage of top-posting. All your replies are out of context and very difficult to follow. > This looks more as an implementation description. What is actually > required is that the endpoints of the client layer are informed of this > event. Agreed. > The way you describe it seems a little bit "against" the framework in > which it is specified that OAM messages cannot be initiated by MIPs. Due to the top-posting you reversed the meaning of my description. It is my opinion (which is in line with current standards) that a MIP *cannot* initiate OAM messages. > That is why we actually say that this is an adaptation function, that > means that the message is initiated by the MEP of the server to the MEP > of the client....... That is why I answered that I agree with Italo, who said the same...... (read my reply below). Regards, Huub. > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Huub van > Helvoort > Sent: Monday, May 04, 2009 10:27 AM > To: mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and > notification of lock > > Hello Nurit, > > You wrote: > >> To continue with the othe rquestion: >> >>> See also my e-mail: >>> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" > >>> OAM messages ? >> The answer was no. >> >>> -question: >>> More generally to the comment above, who should notify and who should >>> notify whom? >>> I would tend to say: >>> the receiving node of a locked direction, informs downstream > receiving >>> nodes of nested LSPs. >> To be more exact, the sink side of a locked LSP, PW, Section, has to >> inform its clients. > > You say " To be more exact, the sink side of a locked LSP, PW, Section, > has to inform its clients.", > > [hvh] it should inform its client transport entities in the > server/client relation > > BUT the client is not necessarily an > endpoint but may be an intermediate point, and it needs to notify its > endpoints, that means that a MIP generates an OAM message. > > [hvh this requires that a MIP has the capability to > send OAM messages based on management command or based on > an indication of a MEP in a different layer. > This also requires that at every MEP location there are also > MIPs for every client entity serviced by that MEP. > > Long ago I discussed this point with Italo and he indicated to me that > it is not a generation of a message by a MIP BUT it is a variation of an > adaptation function at the client intermediate point. Although we are > talking here about a way to implement it, this is a conceptual issue > that we need to agree on. > > [hvh] I agree with Italo. > > Also, I think we should generalize the discussion instead of talking > every time about LSP, PW, section, etc. we should really talk about > client/server layers to cover cases of LSP hierarchies, etc. > > [hvh] then I use server/client path/trail the next time, OK? > > Regards, Huub. > >>> This is a Fowrward Indication and if we do >>> so then receiving points MUST indeed be informed of a Lock (c.f. >>> discussion at the beginning of the e-mail). >>> Should source points (locking points) do some reverse indication and >>> notify the source points of the LSPs that are nested in the locked >> LSP? >>> (but this maybe falls in the RDI functionality). >> Isn't this notification already caused by the locking at the >> far end? >> Or is the locking only applied in one direction of a bi-directional >> path? If yes, then the notification is not required. >> >> Cheers, Huub. >> > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From Martin.Vigoureux@alcatel-lucent.com Mon May 4 02:30:04 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0363A6F4D for ; Mon, 4 May 2009 02:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szswO3+3tn-P for ; Mon, 4 May 2009 02:30:03 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 2AAA33A6ED9 for ; Mon, 4 May 2009 02:29:50 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n449UrSg015537; Mon, 4 May 2009 11:31:12 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 11:31:08 +0200 Message-ID: <49FEB5DC.4060800@alcatel-lucent.com> Date: Mon, 04 May 2009 11:31:08 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: hhelvoort@chello.nl References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <49FE21B7.2090605@chello.nl> In-Reply-To: <49FE21B7.2090605@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2009 09:31:08.0738 (UTC) FILETIME=[0E38F220:01C9CC9B] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 09:30:04 -0000 Huub, please see inline, regards, -m Huub van Helvoort a écrit : > Bonsoir Martin, > > You wrote: > >> here are my thoughts on this: >> >> As far as I understand, strictly speaking the Lock function >> does not make sense on a unidir LSP. Indeed locking is performed >> at the source point and so there is no need to send any message >> to perform that Lock. (the potentially needed message is to inform >> the end-point(s) of the status but that is lock notification. >> I'll come back to this). > > What should happen if the CP and MP are separated, i.e the > ingress point and egress poinr belong to different SP domains? [mvx] please se my other e-mail. > >> Therefore Lock is only needed on a bidir entity and what is exactly >> needed is the capability to request the other end point to admin lock >> its direction. > > What do you mean by "its direction", the direction from "the > other end point" back to the "source point"? [mvx] in case of bidir, both nodes are sources points. What I mean is that a node (A) should have the means to ask its associated end point (Z) to Lock the direction of the LSP that goes from Z to A. > >> Coming back to the notification, I believe the following requirement >> is needed: >> The MPLS-TP OAM toolset MUST provide a functionality to enable an >> End Point of a PW, LSP or Section to inform the End Point(s) of that >> LSP, PW, or Section that the PW, LSP or Section has been >> administratively shutdown at this End Point. >> But it is conditionally needed. This function is *only* needed if >> locking is achieved via Lock, otherwise if it is achieved via NMS >> commands > > This requires that both end points can be reached via the MP. [mvx] indeed but that does not contradict the above. > >> we (I hope) can safely assume that: >> for undir LSP there will be commands at both ends, one saying lock, >> the other saying you are notified of other end locking. >> for bidir LSP there will be commands at both ends, both saying lock >> and you are notified of other end locking. >> >> The MUST is needed because the egress must be aware of the Lock because >> we expect him to then inform client MEPs that are "downstream". (see >> question at the end of this e-mail). >> >> The small problem I have is that this function is a notification >> one but really tightly linked to the Lock. In other words, I do >> not know where this reqs better fits (especially wrt to the conditional >> issue): in Lock or in Lock Notification? >> Opinions are welcomed. From Martin.Vigoureux@alcatel-lucent.com Mon May 4 02:30:14 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84B13A6F58 for ; Mon, 4 May 2009 02:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPSDH7ODv+D7 for ; Mon, 4 May 2009 02:30:13 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 72F4A3A6AF5 for ; Mon, 4 May 2009 02:30:03 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n449VPUx015872; Mon, 4 May 2009 11:31:26 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 11:31:14 +0200 Message-ID: <49FEB5E2.2070204@alcatel-lucent.com> Date: Mon, 04 May 2009 11:31:14 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: hhelvoort@chello.nl References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com> <49FE21B7.2090605@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A754DA@DEMUEXC014.nsn-intra.net> <49FE95D2.5070103@chello.nl> In-Reply-To: <49FE95D2.5070103@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2009 09:31:14.0535 (UTC) FILETIME=[11AD7F70:01C9CC9B] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 09:30:14 -0000 Huub, I still do not understand how the context you mention impacts what is written in the paragraph. Thanks. regards, -m Huub van Helvoort a écrit : > Hi Nurit, > > You wrote: > >>> here are my thoughts on this: >>> >>> As far as I understand, strictly speaking the Lock function >>> does not make sense on a unidir LSP. Indeed locking is performed >>> at the source point and so there is no need to send any message >>> to perform that Lock. (the potentially needed message is to inform >>> the end-point(s) of the status but that is lock notification. >>> I'll come back to this). >> >> What should happen if the CP and MP are separated, i.e the >> ingress point and egress poinr belong to different SP domains? > > I do not understand why you say that the separation of a CP and MP > indicates that the ingress and the egress point belong to different SP > domains? > > [hvh] because I should have used e.g. instead of i.e (it was late). > So there are cases that the lock in dication can only be transferred > via the DP. > > Regards, Huub. > >>> Therefore Lock is only needed on a bidir entity and what is exactly >>> needed is the capability to request the other end point to admin lock >>> its direction. >> >> What do you mean by "its direction", the direction from "the >> other end point" back to the "source point"? >> >>> Coming back to the notification, I believe the following requirement >>> is needed: >>> The MPLS-TP OAM toolset MUST provide a functionality to enable an >>> End Point of a PW, LSP or Section to inform the End Point(s) of >> that >>> LSP, PW, or Section that the PW, LSP or Section has been >>> administratively shutdown at this End Point. >>> But it is conditionally needed. This function is *only* needed if >>> locking is achieved via Lock, otherwise if it is achieved via NMS >>> commands >> >> This requires that both end points can be reached via the MP. >> >>> we (I hope) can safely assume that: >>> for undir LSP there will be commands at both ends, one saying lock, >> the >>> other saying you are notified of other end locking. >>> for bidir LSP there will be commands at both ends, both saying lock >> and >>> you are notified of other end locking. >>> >>> The MUST is needed because the egress must be aware of the Lock >> because >>> we expect him to then inform client MEPs that are "downstream". (see >>> question at the end of this e-mail). >>> >>> The small problem I have is that this function is a notification >>> one but really tightly linked to the Lock. In other words, I do >>> not know where this reqs better fits (especially wrt to the >> conditional >>> issue): in Lock or in Lock Notification? >>> Opinions are welcomed. >>> >>> Therefore I propose: >>> >>> 2.2.x. Lock >>> The MPLS-TP OAM toolset SHOULD provide a functionality to enable an >>> End Point of a bidirectional PW, LSP or Section to request to its >>> associated End Point that it administratively shuts down the direction >>> of the PW, LSP or Section for which it is the head-end. >>> >>> This function SHOULD be performed on-demand. >>> >>> This function SHOULD be performed between the End Points of a PW, LSP >>> or Section. >>> >>> Note that administratively shutting down corresponds to stopping user >>> traffic being sent on the PW, LSP or Section. >>> >>> >>> 2.2.y. Lock Notification >>> The MPLS-TP OAM toolset MUST provide a function to enable End Points >>> of a (server) LSP or Section to notify, of its administrative locking >>> status, the End Points of (client) PWs or LSPs affected by this >> status. >>> This function SHOULD be performed on-demand. >>> >>> This function SHOULD be performed between the End Points of a PW, LSP >>> or Section. >>> -comment: >>> this needs to be rephrased as the notifying end points may not be >>> the same nodes than the notified end points. >>> The general case is in fact a notification between end points of >>> different e.g., LSPs while the sentence seems to say that it is >> between >>> the end-points of the same e.g., LSP. >>> Any suggestion welcomed. >> >> Snip -- I will answer the next in a separate email-- >> >> Regards, Huub. >> > From Martin.Vigoureux@alcatel-lucent.com Mon May 4 02:38:09 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56EF93A6FB3 for ; Mon, 4 May 2009 02:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.771 X-Spam-Level: X-Spam-Status: No, score=-3.771 tagged_above=-999 required=5 tests=[AWL=-1.522, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meNmIgUcRjIK for ; Mon, 4 May 2009 02:38:03 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id A95313A6FAC for ; Mon, 4 May 2009 02:37:25 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n449cUcp021417; Mon, 4 May 2009 11:38:47 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 11:38:33 +0200 Message-ID: <49FEB799.8080405@alcatel-lucent.com> Date: Mon, 04 May 2009 11:38:33 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: hhelvoort@chello.nl References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <49FE241F.5080007@chello.nl> In-Reply-To: <49FE241F.5080007@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2009 09:38:33.0935 (UTC) FILETIME=[17949DF0:01C9CC9C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 09:38:09 -0000 Dear Huub, please see in-line. regards, martin Huub van Helvoort a écrit : > Bonsoir Martin, > > To continue with the othe rquestion: > >> See also my e-mail: >> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" >> OAM messages ? > > The answer was no. [mvx] well, I am not sure about this. > >> -question: >> More generally to the comment above, who should notify and who should >> notify whom? >> I would tend to say: >> the receiving node of a locked direction, informs downstream receiving >> nodes of nested LSPs. > > To be more exact, the sink side of a locked LSP, PW, Section, has to > inform its clients. [mvx] Indeed but that is not precise enough, in my view. Who are the clients? Both end points or only the one downstream? > >> This is a Fowrward Indication and if we do >> so then receiving points MUST indeed be informed of a Lock (c.f. >> discussion at the beginning of the e-mail). >> Should source points (locking points) do some reverse indication and >> notify the source points of the LSPs that are nested in the locked LSP? >> (but this maybe falls in the RDI functionality). > > Isn't this notification already caused by the locking at the > far end? > Or is the locking only applied in one direction of a bi-directional > path? If yes, then the notification is not required. It appear to me that you are mixing the notification at the same layer and notification at the impacted client layers. My question was: in case a Lock is performed at one point I suppose we need to inform the other end point of that status (same layer) But then what do these two nodes do? Which node of the locked server layer inform which node of the impacted clients layer? > > Cheers, Huub. > From Martin.Vigoureux@alcatel-lucent.com Mon May 4 02:40:06 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23FA3A6A42 for ; Mon, 4 May 2009 02:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.633 X-Spam-Level: X-Spam-Status: No, score=-3.633 tagged_above=-999 required=5 tests=[AWL=-1.384, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K283rn9d0Pf for ; Mon, 4 May 2009 02:40:05 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id A078D3A697D for ; Mon, 4 May 2009 02:40:05 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n449fJU5022751; Mon, 4 May 2009 11:41:27 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 11:41:21 +0200 Message-ID: <49FEB841.2010808@alcatel-lucent.com> Date: Mon, 04 May 2009 11:41:21 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: hhelvoort@chello.nl References: <49FDE174.7000904@alcatel-lucent.com> <49FE253E.5060803@chello.nl> In-Reply-To: <49FE253E.5060803@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2009 09:41:21.0644 (UTC) FILETIME=[7B8AFAC0:01C9CC9C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 09:40:06 -0000 Huub, please see in-line. regards, -m Huub van Helvoort a écrit : > Bonsoir Martin, > > You wrote: > >> as part of the discussion on AIS/Lock Notification, >> the server layer MEPs, detecting a fault/lock condition, should >> inform (the MEPs of) the client layers relying on that >> server layer and which are affected by the condition. >> >> However as I understand it is not the MEP (sMEP) of the >> server layer that sends a notification to the client layers >> MEPs (cMEP) but the MIP (cMIP) of the client layer which >> is hosted on the same node than the MEP (sMEP). >> See the figure below (where the double dashed line is >> an LSP, and the ~ line represents an LSP nested in the >> other LSP. >> >> +------+ +------+ +------+ +------+ >> | |------| |------| cMIP |~~~~~~| cMEP | >> | | | | | ^ | | | >> | | | | | | | | | >> | | | | | | | | | >> | |======| |======| sMEP | | | >> +------+ +------+ +------+ +------+ > > I modified the figure to align with what you wrote. [mvx] thx. In fact the double dashed line was already there but with quite some spacing between the top and bottom. > >> Therefore can MIPs send OAM messages without having priorly received one >> or did I miss something? > > No, a MIP can only respond to messages it receives from a MEP > that has the same MEG level, i.e. exists in the same path. > > In your figure the cMIP ignores messages sent by sMEP. but then, how does a Lock condition of the lower LSP is notified to cMEP? > > Cheers, Huub. > From Martin.Vigoureux@alcatel-lucent.com Mon May 4 02:58:46 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39EB13A699E for ; Mon, 4 May 2009 02:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-1.269, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 402h2vc1ELDv for ; Mon, 4 May 2009 02:58:39 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id B2E673A6782 for ; Mon, 4 May 2009 02:58:38 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n449xX2E029945; Mon, 4 May 2009 12:00:02 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 11:59:59 +0200 Message-ID: <49FEBC9E.3080802@alcatel-lucent.com> Date: Mon, 04 May 2009 11:59:58 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com><42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <077E41CFFD002C4CAB7DFA4386A53264A754E7@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A754E7@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2009 09:59:59.0231 (UTC) FILETIME=[15AD38F0:01C9CC9F] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 09:58:46 -0000 Nurit, this is faithfull to the text I proposed. regards, -m Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit : > Would not it be fair to say the following? > > · lock is sent between endpoints (at the same layer) to > synchronizes the lock status (either when the configuration is performed > at one end, or to ensure that it was configured consistently at both ends). > > · Lock indication is sent by an endpoint of a server layer to > its clients' endpoints to inform of the administrative lock status? > > > > > > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Martin Vigoureux > Sent: Sunday, May 03, 2009 9:22 PM > To: Adrian Farrel; Malcolm Betts > Cc: mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and > notification of lock > > > > Adrian, Malcolm, all, > > > > here are my thoughts on this: > > > > As far as I understand, strictly speaking the Lock function > > does not make sense on a unidir LSP. Indeed locking is performed > > at the source point and so there is no need to send any message > > to perform that Lock. (the potentially needed message is to inform > > the end-point(s) of the status but that is lock notification. > > I'll come back to this). > > Therefore Lock is only needed on a bidir entity and what is exactly > > needed is the capability to request the other end point to admin lock > > its direction. > > > > Coming back to the notification, I believe the following requirement > > is needed: > > The MPLS-TP OAM toolset MUST provide a functionality to enable an > > End Point of a PW, LSP or Section to inform the End Point(s) of that > > LSP, PW, or Section that the PW, LSP or Section has been > > administratively shutdown at this End Point. > > But it is conditionally needed. This function is *only* needed if > > locking is achieved via Lock, otherwise if it is achieved via NMS > > commands we (I hope) can safely assume that: > > for undir LSP there will be commands at both ends, one saying lock, the > > other saying you are notified of other end locking. > > for bidir LSP there will be commands at both ends, both saying lock and > > you are notified of other end locking. > > > > The MUST is needed because the egress must be aware of the Lock because > > we expect him to then inform client MEPs that are "downstream". (see > > question at the end of this e-mail). > > > > The small problem I have is that this function is a notification > > one but really tightly linked to the Lock. In other words, I do > > not know where this reqs better fits (especially wrt to the conditional > > issue): in Lock or in Lock Notification? > > Opinions are welcomed. > > > > Therefore I propose: > > > > 2.2.x. Lock > > The MPLS-TP OAM toolset SHOULD provide a functionality to enable an > > End Point of a bidirectional PW, LSP or Section to request to its > > associated End Point that it administratively shuts down the direction > > of the PW, LSP or Section for which it is the head-end. > > > > This function SHOULD be performed on-demand. > > > > This function SHOULD be performed between the End Points of a PW, LSP > > or Section. > > > > Note that administratively shutting down corresponds to stopping user > > traffic being sent on the PW, LSP or Section. > > > > > > 2.2.y. Lock Notification > > The MPLS-TP OAM toolset MUST provide a function to enable End Points > > of a (server) LSP or Section to notify, of its administrative locking > > status, the End Points of (client) PWs or LSPs affected by this status. > > > > This function SHOULD be performed on-demand. > > > > This function SHOULD be performed between the End Points of a PW, LSP > > or Section. > > -comment: > > this needs to be rephrased as the notifying end points may not be > > the same nodes than the notified end points. > > The general case is in fact a notification between end points of > > different e.g., LSPs while the sentence seems to say that it is between > > the end-points of the same e.g., LSP. > > Any suggestion welcomed. > > > > See also my e-mail: > > MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" > > OAM messages ? > > > > -question: > > More generally to the comment above, who should notify and who should > > notify whom? > > I would tend to say: > > the receiving node of a locked direction, informs downstream receiving > > nodes of nested LSPs. This is a Fowrward Indication and if we do > > so then receiving points MUST indeed be informed of a Lock (c.f. > > discussion at the beginning of the e-mail). > > Should source points (locking points) do some reverse indication and > > notify the source points of the LSPs that are nested in the locked LSP? > > (but this maybe falls in the RDI functionality). > > > > I guess that is all, sorry for this long e-mail. > > > > regards, > > -m > > > > > > Adrian Farrel a écrit : > >> Hi Malcolm, > >> > >> > To address the comments from Adrian I suggest the following > >> > text for sections 2.2.7 and 2.2.8: > >> > > >> > Note that this proposal assumes that the text related to local/remote > >> > faults is moved from section 2.2.8 to section 2.2.2 as proposed in my > >> > previous email. > >> > > >> > We probably need to discuss this text on the MEAD team call next > >> > week. > >> > > >> > 2.2.7. Lock > >> > > >> > The OAM toolset SHOULD provide a function enabling a network operator to > >> > administratively shut down a PW, LSP or Section; that is, to stop user > >> > traffic being sent over that PW, LSP or Section. > >> > >> This is great. > >> Does it mean that we do not need to add the (similar) text on CV fault > >> behavior in section 2.2.3? > >> It would seem so. > >> > >> > The lock function MAY be applied to a unidirectional or a bidirectional > >> > PW, LSP or Section. If the lock function is activated at the head end > >> > of one direction of a bidirectional PW, LSP or Section then it SHOULD be > >> > possible to cause the lock function to be activated at the head end of > >> > the other direction. > >> > > >> > This function SHOULD be performed on-demand i.e. in response to an > >> > operator command. > >> > >> Or also in response to configured automatic behavior? > >> > >> But this is not a protocol requirement. > >> > >> > This function SHOULD be performed between End Points of PWs, LSPs > >> > and Sections. > >> > > >> > 2.2.8 Notification of Lock > >> > > >> > If the lock function is supported the MPLS-TP OAM toolset MUST > >> > provide a function to enable the End Point at the ingress to notify the > >> > End Points at the egress that the lock function is active. This > >> > function SHOULD be performed pro-actively. > >> > > >> > The MPLS-TP OAM toolset MUST allow for the distinction between > >> > a fault condition and an administrative locking action. > >> > >> Works for me. > >> > >> A > >> > >> > >> > >> _______________________________________________ > >> Mpls-interop mailing list > >> Mpls-interop@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-interop > >> > > _______________________________________________ > > Mpls-interop mailing list > > Mpls-interop@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-interop > From Martin.Vigoureux@alcatel-lucent.com Mon May 4 03:18:21 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99E63A6B30 for ; Mon, 4 May 2009 03:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.42 X-Spam-Level: X-Spam-Status: No, score=-5.42 tagged_above=-999 required=5 tests=[AWL=0.829, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FU31Zc9J1zRa for ; Mon, 4 May 2009 03:18:14 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 49CC43A6AC0 for ; Mon, 4 May 2009 03:18:13 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n44AJbA4010366; Mon, 4 May 2009 12:19:37 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 12:19:37 +0200 Message-ID: <49FEC138.2030301@alcatel-lucent.com> Date: Mon, 04 May 2009 12:19:36 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Malcolm Betts References: <0BDFFF51DC89434FA33F8B37FCE363D516F96AB6@zcarhxm2.corp.nortel.com> In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516F96AB6@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2009 10:19:37.0086 (UTC) FILETIME=[D3BBA1E0:01C9CCA1] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] Draft text for "AIS" in section 2.2.8 of MPLS-TP OAM requirements X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 10:18:21 -0000 Malcolm, for the alarm notification, I suggest that we have exactly the same text as for Lock Indication. 2.2.z. Alarm Indication The MPLS-TP OAM toolset MUST provide a function to enable End Points of a (server) LSP or Section to notify, of its faulty or defect status, the End Points of (client) PWs or LSPs affected by this status. This function SHOULD be performed pro-actively. This function SHOULD be performed between the End Points of a PW, LSP or Section. comment: remains here the subtle issue that the notification is not between the end-points of the same e.g., LSP but between end-points of different LSPs. regards, -m Malcolm Betts a écrit : > All, > > You have probably seen the discussion on AIS on the MPLS-TP list. On > the last MEAD team call we reached section 2.2.7 of the MPLS-TP OAM > requirements draft. Section 2.2.8 Alarm Notifications addresses this issue. > > Below (in plain text) and attached in word with change bars etc. is a > proposal to revise sections 2.2.7, 2.2.8 and 2.2.9. > > <> > I would like to get a version of this text that the MEAD team can > support on the MPLS-TP as soon as possible to end this discussion. > > Loa, I look to you for guidance on how to manage the lists e.g. should > we announce on the MPLS-TP that the MEAD team is reviewing text and wait > for a new draft? > > 2.2.7. Lock > > The MPLS-TP OAM toolset MAY provide a function enabling to > administratively shut down a PW, LSP or Section; that is, to stop > user traffic being sent over that PW, LSP or Section. > > The lock function MAY be applied to a unidirectional or bidirectional > PW, LSP or Section. If the lock function is applied to bidirectional a > PW, LSP or Section then it SHOULD be possible to cause it to be applied > to both directions. > > This function SHOULD be performed on-demand. > > This function SHOULD be performed between End Points of PWs, LSPs and > Sections. > > 2.2.8. Alarm Notification > MB> We should break this into several independent requirements: > notification of Lock: Local/remote fault causing loss of CC: Wrong CV > received . > > 2.2.8a Notification of Lock > > The MPLS-TP OAM toolset MUST provide a function to enable the > End Point at the ingress to notify the End Points at the egress that > the lock function is active. The egress end points MUST notify the > local client layer that the server layer PW, LSP or Section has been > locked. > > MB> How this is used is out of scope for this draft. > > The MPLS-TP OAM toolset MUST allow for the distinction between a > fault condition and an administrative locking action. > MB> Not sure we need this if we separate the requirements. > > The server layer End Points generating the notification and the > client layer End Points receiving the notification may or may not be > the same nodes. A mechanism MUST be provided to support both cases. > > This function SHOULD be performed pro-actively. > > This function SHOULD be performed between the End Points of PWs, LSPs > and Sections and the End Points of the PWs and/or LSPs affected by > the administrative locking. > > 2.2.8b Differentiation between local and remote faults. > > When an MPLS-TP or PW end point detects a continuity check defect it > MUST provide a local indication to any clients and the management > function. It MUST also indicate if the fault causing this is local (i.e. > within the node containing the end point) or remote. > > 2.2.8c Connectivity verification failure > > When an MPLS-TP or PW end point detects a continuity verification defect > it MUST provide a local indication to any clients and the management > function. It MUST also provide the capability to shut down the PW, LSP > or Section; that is, stop user traffic being sent from that PW, LSP or > Section. > > > 2.2.9. Client Failure Indication > > The MPLS-TP OAM toolset MUST provide a function to enable the > propagation of client fault condition detected at the ingress to a > PW, LSP or Section, across the MPLS-TP > network. > MB> The requirement to support the tool should be client independent, we > can, on a case by case basis for each client decide if we will use this > tool. My vote would be to always use this tool since it provides > consistent client independent operation. > > This function SHOULD be performed pro-actively. > > This function SHOULD be performed between End Points of PWs, LSPs and > Sections. > > The MPLS-TP OAM toolset MAY provide a function enabling to > administratively shut down a PW, LSP or Section; that is, to stop > user traffic being sent over that PW, LSP or Section. > > > > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop From loa@pi.nu Mon May 4 05:13:12 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29F03A6A56 for ; Mon, 4 May 2009 05:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miCDRVLPjK8E for ; Mon, 4 May 2009 05:13:12 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id D183C3A6B88 for ; Mon, 4 May 2009 05:13:11 -0700 (PDT) Received: from [192.36.158.68] (wdhcp-158-68.verkstad.net [192.36.158.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id B5858D4048 for ; Mon, 4 May 2009 14:14:34 +0200 (CEST) Message-ID: <49FEDC27.40402@pi.nu> Date: Mon, 04 May 2009 14:14:31 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mpls-interop@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Mpls-interop] managing the MEAD team list X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:13:12 -0000 All, just a gentle reminder, in one week from now I will move the MEAD team over to a new mailing list. If you want to continue to be on that mailing list (and has not responded to this mail earlier) you need to send me a mail saying so before May 11. /Loa Loa Andersson wrote: > All, > > we have a comparatively high number of MEAD team members > on our mailing list, as compared the number of people that > are active and contributing. > > A couple of month ago I tried to reduce the number of team > members by asking people to voluntarily resign from the > mailing list. There were no response to this, this could > be interpreted as a genuine interest and that we have the > people we should have on the mailing list; or it could > mean that the interest is so low that people didn't care to > respond. > > This time we'll it the opposite way, you will have to actively > send a request to be *kept on the list after May 11th*. > > /Loa > > PS > > The supporting ADs, mpls and pwe3 wg chairs are already listed > as if they sent positive request :), you won't be let off the > hook that easily ;) > > > > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu From BETTS01@nortel.com Mon May 4 05:27:03 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E14928C14E for ; Mon, 4 May 2009 05:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kh86PH5nGvlt for ; Mon, 4 May 2009 05:27:02 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 93F9528C1A5 for ; Mon, 4 May 2009 05:26:08 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n44CQYo27003; Mon, 4 May 2009 12:26:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 08:27:26 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516FDB211@zcarhxm2.corp.nortel.com> In-Reply-To: <49FDE0C4.7060807@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock Thread-Index: AcnMHBavOqSd0dAlSj2mg7lcw3R0xgAltR7g References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> From: "Malcolm Betts" To: "Martin Vigoureux" , "Adrian Farrel" Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:27:03 -0000 Martin, The key point is that the lock action is implemented locally. e.g. at = the sending end of a LSP the traffic can be blocked. One example of the = use of this is to allow a test source to be connected (vs. client = traffic). Even on a unidirectional LSP it is useful to have a = notification sent to the receiving end of the LSP so that it is aware = that it is not receiving "valid" client traffic. On a bidirectional LSP this notification may be used to activate a lock = in the reverse direction. Hope this clears up the confusion. =20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com]=20 Sent: Sunday, May 03, 2009 2:22 PM To: Adrian Farrel; Betts, Malcolm (CAR:X632) Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and = notification of lock Adrian, Malcolm, all, here are my thoughts on this: As far as I understand, strictly speaking the Lock function does not = make sense on a unidir LSP. Indeed locking is performed at the source = point and so there is no need to send any message to perform that Lock. = (the potentially needed message is to inform the end-point(s) of the = status but that is lock notification. I'll come back to this). Therefore Lock is only needed on a bidir entity and what is exactly = needed is the capability to request the other end point to admin lock = its direction. Coming back to the notification, I believe the following requirement is = needed: The MPLS-TP OAM toolset MUST provide a functionality to enable an End Point of a PW, LSP or Section to inform the End Point(s) of that LSP, PW, or Section that the PW, LSP or Section has been administratively shutdown at this End Point. But it is conditionally needed. This function is *only* needed if = locking is achieved via Lock, otherwise if it is achieved via NMS = commands we (I hope) can safely assume that: for undir LSP there will be commands at both ends, one saying lock, the = other saying you are notified of other end locking. for bidir LSP there will be commands at both ends, both saying lock and = you are notified of other end locking. The MUST is needed because the egress must be aware of the Lock because = we expect him to then inform client MEPs that are "downstream". (see = question at the end of this e-mail). The small problem I have is that this function is a notification one but = really tightly linked to the Lock. In other words, I do not know where = this reqs better fits (especially wrt to the conditional issue): in Lock or in Lock Notification? Opinions are welcomed. Therefore I propose: 2.2.x. Lock The MPLS-TP OAM toolset SHOULD provide a functionality to enable an End = Point of a bidirectional PW, LSP or Section to request to its associated = End Point that it administratively shuts down the direction of the PW, = LSP or Section for which it is the head-end. This function SHOULD be performed on-demand. This function SHOULD be performed between the End Points of a PW, LSP or = Section. Note that administratively shutting down corresponds to stopping user = traffic being sent on the PW, LSP or Section. 2.2.y. Lock Notification The MPLS-TP OAM toolset MUST provide a function to enable End Points of a (server) LSP or Section to notify, of its administrative locking status, the End Points of (client) PWs or LSPs affected by this status. This function SHOULD be performed on-demand. This function SHOULD be performed between the End Points of a PW, LSP or Section. -comment: this needs to be rephrased as the notifying end points may not be the same nodes than the notified end points. The general case is in fact a notification between end points of=20 different e.g., LSPs while the sentence seems to say that it is between the end-points of the same e.g., LSP. Any suggestion welcomed. See also my e-mail: MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited"=20 OAM messages ? -question: More generally to the comment above, who should notify and who should notify whom? I would tend to say: the receiving node of a locked direction, informs downstream receiving nodes of nested LSPs. This is a Fowrward Indication and if we do so then receiving points MUST indeed be informed of a Lock (c.f. discussion at the beginning of the e-mail). Should source points (locking points) do some reverse indication and notify the source points of the LSPs that are nested in the locked LSP? (but this maybe falls in the RDI functionality). I guess that is all, sorry for this long e-mail. regards, -m Adrian Farrel a =E9crit : > Hi Malcolm, >=20 >> To address the comments from Adrian I suggest the following >> text for sections 2.2.7 and 2.2.8: >> >> Note that this proposal assumes that the text related to local/remote >> faults is moved from section 2.2.8 to section 2.2.2 as proposed in my >> previous email. >> >> We probably need to discuss this text on the MEAD team call next >> week. >> >> 2.2.7. Lock >> >> The OAM toolset SHOULD provide a function enabling a network operator = to >> administratively shut down a PW, LSP or Section; that is, to stop = user >> traffic being sent over that PW, LSP or Section. >=20 > This is great. > Does it mean that we do not need to add the (similar) text on CV fault = > behavior in section 2.2.3? > It would seem so. >=20 >> The lock function MAY be applied to a unidirectional or a = bidirectional >> PW, LSP or Section. If the lock function is activated at the head = end >> of one direction of a bidirectional PW, LSP or Section then it SHOULD = be >> possible to cause the lock function to be activated at the head end = of >> the other direction. >> >> This function SHOULD be performed on-demand i.e. in response to an >> operator command. >=20 > Or also in response to configured automatic behavior? >=20 > But this is not a protocol requirement. >=20 >> This function SHOULD be performed between End Points of PWs, LSPs >> and Sections. >> >> 2.2.8 Notification of Lock >> >> If the lock function is supported the MPLS-TP OAM toolset MUST >> provide a function to enable the End Point at the ingress to notify = the >> End Points at the egress that the lock function is active. This >> function SHOULD be performed pro-actively. >> >> The MPLS-TP OAM toolset MUST allow for the distinction between >> a fault condition and an administrative locking action. >=20 > Works for me. >=20 > A >=20 >=20 >=20 > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop >=20 From BETTS01@nortel.com Mon May 4 05:30:07 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E183A7022 for ; Mon, 4 May 2009 05:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LY+T-4bepCi for ; Mon, 4 May 2009 05:30:07 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BA0793A7016 for ; Mon, 4 May 2009 05:30:06 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n44CUao27576; Mon, 4 May 2009 12:30:36 GMT 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: Mon, 4 May 2009 08:31:26 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516FDB21C@zcarhxm2.corp.nortel.com> In-Reply-To: <75C8A28FE26142CEAF3245B2079821C8@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] Reaction to a CV defect Thread-Index: AcnLSKNH01kA+f1GTf+MifuKs4CziQBaxtlg References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE0E@zcarhxm2.corp.nortel.com> <75C8A28FE26142CEAF3245B2079821C8@your029b8cecfe> From: "Malcolm Betts" To: "Adrian Farrel" , Subject: Re: [Mpls-interop] Reaction to a CV defect X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:30:07 -0000 Adrian, =20 A small point, CV defects are only detected by the node at the receiving end of the LSP. Hence I suggested sent from vs sent on. Apart from that small change I like your new text. So how about: When a node detects a continuity verification defect, the protocol mechanisms MUST provide a way for the detecting node to shut down the defective PW, LSP, or Section; that is, the capability to stop user traffic being sent from the defective PW, LSP or Section. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Saturday, May 02, 2009 1:08 PM To: Betts, Malcolm (CAR:X632); mpls-interop@ietf.org Subject: Re: [Mpls-interop] Reaction to a CV defect Malcolm, Not quite sure about the proposition: > As proposed by Adrian, text for this requirement to section 2.2.3. > My proposed text is: > "When a continuity verification defect is detected the capability to=20 > shut down the defective PW, LSP or Section MUST be provided; that is=20 > the capability to, stop user traffic being sent from the defective PW, > LSP or Section." "sent from" or "sent on"? Pondering the passive voice again :-( "is detected" by whom? "MUST be provided by what"? Try... When a node detects a continuity verification defect, the protocol mechanisms MUST provide a way for the detecting node to shut down the defective PW, LSP, or Section; that is, the capability to stop user traffic being sent on the defective PW, LSP or Section. A From hhelvoort@chello.nl Mon May 4 05:30:08 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FA328C155 for ; Mon, 4 May 2009 05:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TErgsPT1XnGw for ; Mon, 4 May 2009 05:30:07 -0700 (PDT) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id 43F803A700E for ; Mon, 4 May 2009 05:30:07 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep17-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090504123132.BEIU29379.viefep17-int.chello.at@edge05.upc.biz>; Mon, 4 May 2009 14:31:32 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge05.upc.biz with edge id nQXW1b05Q3KDBhC05QXX0R; Mon, 04 May 2009 14:31:32 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FEE022.4080708@chello.nl> Date: Mon, 04 May 2009 14:31:30 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Martin Vigoureux References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <49FE21B7.2090605@chello.nl> <49FEB5DC.4060800@alcatel-lucent.com> In-Reply-To: <49FEB5DC.4060800@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:30:08 -0000 Hi Martin, You replied: > please see inline, > > regards, > -m > > Huub van Helvoort a écrit : >> Bonsoir Martin, >> >> You wrote: >> >>> here are my thoughts on this: >>> >>> As far as I understand, strictly speaking the Lock function >>> does not make sense on a unidir LSP. Indeed locking is performed >>> at the source point and so there is no need to send any message >>> to perform that Lock. (the potentially needed message is to inform >>> the end-point(s) of the status but that is lock notification. >>> I'll come back to this). >> >> What should happen if the CP and MP are separated, i.e the >> ingress point and egress poinr belong to different SP domains? > > [mvx] please se my other e-mail. [hvh] OK, I will. >>> Therefore Lock is only needed on a bidir entity and what is exactly >>> needed is the capability to request the other end point to admin lock >>> its direction. >> >> What do you mean by "its direction", the direction from "the >> other end point" back to the "source point"? > > [mvx] in case of bidir, both nodes are sources points. > What I mean is that a node (A) should have the means to ask its > associated end point (Z) to Lock the direction of the LSP that > goes from Z to A. > >> >>> Coming back to the notification, I believe the following requirement >>> is needed: >>> The MPLS-TP OAM toolset MUST provide a functionality to enable an >>> End Point of a PW, LSP or Section to inform the End Point(s) of that >>> LSP, PW, or Section that the PW, LSP or Section has been >>> administratively shutdown at this End Point. >>> But it is conditionally needed. This function is *only* needed if >>> locking is achieved via Lock, otherwise if it is achieved via NMS >>> commands >> >> This requires that both end points can be reached via the MP. > > [mvx] indeed but that does not contradict the above. OK, I was confused by the added *conditionally* >>> we (I hope) can safely assume that: >>> for undir LSP there will be commands at both ends, one saying lock, >>> the other saying you are notified of other end locking. >>> for bidir LSP there will be commands at both ends, both saying lock >>> and you are notified of other end locking. >>> >>> The MUST is needed because the egress must be aware of the Lock because >>> we expect him to then inform client MEPs that are "downstream". (see >>> question at the end of this e-mail). >>> >>> The small problem I have is that this function is a notification >>> one but really tightly linked to the Lock. In other words, I do >>> not know where this reqs better fits (especially wrt to the conditional >>> issue): in Lock or in Lock Notification? >>> Opinions are welcomed. Cheers, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From hhelvoort@chello.nl Mon May 4 05:36:41 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281AF3A6F1F for ; Mon, 4 May 2009 05:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxROxKU4UFBq for ; Mon, 4 May 2009 05:36:40 -0700 (PDT) Received: from viefep20-int.chello.at (viefep20-int.chello.at [62.179.121.40]) by core3.amsl.com (Postfix) with ESMTP id 09C383A6B7B for ; Mon, 4 May 2009 05:36:03 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep20-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090504123727.CBDM20956.viefep20-int.chello.at@edge04.upc.biz>; Mon, 4 May 2009 14:37:27 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge04.upc.biz with edge id nQdR1b0543KDBhC04QdSLT; Mon, 04 May 2009 14:37:27 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FEE185.6030308@chello.nl> Date: Mon, 04 May 2009 14:37:25 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Martin Vigoureux References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com> <49FE21B7.2090605@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A754DA@DEMUEXC014.nsn-intra.net> <49FE95D2.5070103@chello.nl> <49FEB5E2.2070204@alcatel-lucent.com> In-Reply-To: <49FEB5E2.2070204@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:36:41 -0000 Hello Martin, You wrote: > I still do not understand how the context you mention impacts > what is written in the paragraph. Thanks. Now that I am fully awake and re-read the text a few times I understand the intention. I just wanted to have some clarification. Cheers, Huub. ================ > Huub van Helvoort a écrit : >> Hi Nurit, >> >> You wrote: >> >>>> here are my thoughts on this: >>>> >>>> As far as I understand, strictly speaking the Lock function >>>> does not make sense on a unidir LSP. Indeed locking is performed >>>> at the source point and so there is no need to send any message >>>> to perform that Lock. (the potentially needed message is to inform >>>> the end-point(s) of the status but that is lock notification. >>>> I'll come back to this). >>> >>> What should happen if the CP and MP are separated, i.e the >>> ingress point and egress poinr belong to different SP domains? >> >> I do not understand why you say that the separation of a CP and MP >> indicates that the ingress and the egress point belong to different SP >> domains? >> >> [hvh] because I should have used e.g. instead of i.e (it was late). >> So there are cases that the lock in dication can only be transferred >> via the DP. >> >> Regards, Huub. >> >>>> Therefore Lock is only needed on a bidir entity and what is exactly >>>> needed is the capability to request the other end point to admin lock >>>> its direction. >>> >>> What do you mean by "its direction", the direction from "the >>> other end point" back to the "source point"? >>> >>>> Coming back to the notification, I believe the following requirement >>>> is needed: >>>> The MPLS-TP OAM toolset MUST provide a functionality to enable an >>>> End Point of a PW, LSP or Section to inform the End Point(s) of >>> that >>>> LSP, PW, or Section that the PW, LSP or Section has been >>>> administratively shutdown at this End Point. >>>> But it is conditionally needed. This function is *only* needed if >>>> locking is achieved via Lock, otherwise if it is achieved via NMS >>>> commands >>> >>> This requires that both end points can be reached via the MP. >>> >>>> we (I hope) can safely assume that: >>>> for undir LSP there will be commands at both ends, one saying lock, >>> the >>>> other saying you are notified of other end locking. >>>> for bidir LSP there will be commands at both ends, both saying lock >>> and >>>> you are notified of other end locking. >>>> >>>> The MUST is needed because the egress must be aware of the Lock >>> because >>>> we expect him to then inform client MEPs that are "downstream". (see >>>> question at the end of this e-mail). >>>> >>>> The small problem I have is that this function is a notification >>>> one but really tightly linked to the Lock. In other words, I do >>>> not know where this reqs better fits (especially wrt to the >>> conditional >>>> issue): in Lock or in Lock Notification? >>>> Opinions are welcomed. >>>> >>>> Therefore I propose: >>>> >>>> 2.2.x. Lock >>>> The MPLS-TP OAM toolset SHOULD provide a functionality to enable an >>>> End Point of a bidirectional PW, LSP or Section to request to its >>>> associated End Point that it administratively shuts down the direction >>>> of the PW, LSP or Section for which it is the head-end. >>>> >>>> This function SHOULD be performed on-demand. >>>> >>>> This function SHOULD be performed between the End Points of a PW, LSP >>>> or Section. >>>> >>>> Note that administratively shutting down corresponds to stopping >>>> user traffic being sent on the PW, LSP or Section. >>>> >>>> >>>> 2.2.y. Lock Notification >>>> The MPLS-TP OAM toolset MUST provide a function to enable End Points >>>> of a (server) LSP or Section to notify, of its administrative locking >>>> status, the End Points of (client) PWs or LSPs affected by this >>> status. >>>> This function SHOULD be performed on-demand. >>>> >>>> This function SHOULD be performed between the End Points of a PW, LSP >>>> or Section. >>>> -comment: >>>> this needs to be rephrased as the notifying end points may not be >>>> the same nodes than the notified end points. >>>> The general case is in fact a notification between end points of >>>> different e.g., LSPs while the sentence seems to say that it is >>> between >>>> the end-points of the same e.g., LSP. >>>> Any suggestion welcomed. >>> >>> Snip -- I will answer the next in a separate email-- >>> >>> Regards, Huub. >>> >> > -- ================================================================ Always remember that you are unique...just like everyone else... From BETTS01@nortel.com Mon May 4 05:41:46 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCDED28C16A for ; Mon, 4 May 2009 05:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hc15f7-2k67 for ; Mon, 4 May 2009 05:41:45 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D6A3D3A7010 for ; Mon, 4 May 2009 05:41:04 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n44CfXo00086; Mon, 4 May 2009 12:41:33 GMT 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: Mon, 4 May 2009 08:42:26 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof lock Thread-Index: AcnMibd+2qVOSWcIR5GzbLZ+V24I5QAANxMQAAp1z8A= References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net> From: "Malcolm Betts" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , , Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:41:46 -0000 All, I think you are making this far too complicated... I see no need to propagate the locked indication across layers. If the operator decides to lock a LSP (for example to run a test) then the clients of that LSP should be taken out of service before the lock is applied. When a server LSP detects the locked notification it informs the client adaptation that it is no longer receiving valid traffic. If the client has already been taken out of service then this is a "don't care". If the client has not been taken out of service then it should raise an alarm. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, May 04, 2009 3:47 AM To: hhelvoort@chello.nl; mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof lock Huub, You say " this requires that a MIP has the capability to send OAM messages based on management command or based on an indication of a MEP in a different layer. This also requires that at every MEP location there are also MIPs for every client entity serviced by that MEP." This looks more as an implementation description. What is actually required is that the endpoints of the client layer are informed of this event.=20 The way you describe it seems a little bit "against" the framework in which it is specified that OAM messages cannot be initiated by MIPs. That is why we actually say that this is an adaptation function, that means that the message is initiated by the MEP of the server to the MEP of the client....... Best regards, NUrit -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Huub van Helvoort Sent: Monday, May 04, 2009 10:27 AM To: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock Hello Nurit, You wrote: > To continue with the othe rquestion: >=20 >> See also my e-mail: >> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" >> OAM messages ? >=20 > The answer was no. >=20 >> -question: >> More generally to the comment above, who should notify and who should >> notify whom? >> I would tend to say: >> the receiving node of a locked direction, informs downstream receiving >> nodes of nested LSPs.=20 >=20 > To be more exact, the sink side of a locked LSP, PW, Section, has to=20 > inform its clients. You say " To be more exact, the sink side of a locked LSP, PW, Section, has to inform its clients.", [hvh] it should inform its client transport entities in the server/client relation BUT the client is not necessarily an endpoint but may be an intermediate point, and it needs to notify its endpoints, that means that a MIP generates an OAM message. [hvh this requires that a MIP has the capability to send OAM messages based on management command or based on an indication of a MEP in a different layer. This also requires that at every MEP location there are also MIPs for every client entity serviced by that MEP. Long ago I discussed this point with Italo and he indicated to me that it is not a generation of a message by a MIP BUT it is a variation of an adaptation function at the client intermediate point. Although we are talking here about a way to implement it, this is a conceptual issue that we need to agree on. [hvh] I agree with Italo. Also, I think we should generalize the discussion instead of talking every time about LSP, PW, section, etc. we should really talk about client/server layers to cover cases of LSP hierarchies, etc. [hvh] then I use server/client path/trail the next time, OK? Regards, Huub. >> This is a Fowrward Indication and if we do so then receiving points=20 >> MUST indeed be informed of a Lock (c.f. >> discussion at the beginning of the e-mail). >> Should source points (locking points) do some reverse indication and=20 >> notify the source points of the LSPs that are nested in the locked > LSP? >> (but this maybe falls in the RDI functionality). >=20 > Isn't this notification already caused by the locking at the far end? > Or is the locking only applied in one direction of a bi-directional=20 > path? If yes, then the notification is not required. >=20 > Cheers, Huub. >=20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From adrian@olddog.co.uk Mon May 4 05:41:47 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930A13A7010 for ; Mon, 4 May 2009 05:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCDG+KzGLvuu for ; Mon, 4 May 2009 05:41:46 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 1B4733A7025 for ; Mon, 4 May 2009 05:41:09 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n44CgXE2000733; Mon, 4 May 2009 13:42:33 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n44CgKNa000668; Mon, 4 May 2009 13:42:32 +0100 Message-ID: <2495E9BF52FE484EADADD5852561A334@your029b8cecfe> From: "Adrian Farrel" To: "Malcolm Betts" , References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE0E@zcarhxm2.corp.nortel.com> <75C8A28FE26142CEAF3245B2079821C8@your029b8cecfe> <0BDFFF51DC89434FA33F8B37FCE363D516FDB21C@zcarhxm2.corp.nortel.com> Date: Mon, 4 May 2009 13:41:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Mpls-interop] Reaction to a CV defect X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:41:47 -0000 I love prepositions. I was trying s/from/on/ I thought it was your intention to coordinate between the detector (receiver) and the data sender (hence "sent on") "Sent from" may be what you intended, but if this is the case: - the CV defect is detected at the receiver - the "sent from" restriction is provided at the receiver Therefore, there is no protocol requirement and we should delete this entire section. That is, this is an implementation requirement talking about actions between internal components of an NE. Thanks, Adrian ----- Original Message ----- From: "Malcolm Betts" To: "Adrian Farrel" ; Sent: Monday, May 04, 2009 1:31 PM Subject: RE: [Mpls-interop] Reaction to a CV defect Adrian, A small point, CV defects are only detected by the node at the receiving end of the LSP. Hence I suggested sent from vs sent on. Apart from that small change I like your new text. So how about: When a node detects a continuity verification defect, the protocol mechanisms MUST provide a way for the detecting node to shut down the defective PW, LSP, or Section; that is, the capability to stop user traffic being sent from the defective PW, LSP or Section. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Saturday, May 02, 2009 1:08 PM To: Betts, Malcolm (CAR:X632); mpls-interop@ietf.org Subject: Re: [Mpls-interop] Reaction to a CV defect Malcolm, Not quite sure about the proposition: > As proposed by Adrian, text for this requirement to section 2.2.3. > My proposed text is: > "When a continuity verification defect is detected the capability to > shut down the defective PW, LSP or Section MUST be provided; that is > the capability to, stop user traffic being sent from the defective PW, > LSP or Section." "sent from" or "sent on"? Pondering the passive voice again :-( "is detected" by whom? "MUST be provided by what"? Try... When a node detects a continuity verification defect, the protocol mechanisms MUST provide a way for the detecting node to shut down the defective PW, LSP, or Section; that is, the capability to stop user traffic being sent on the defective PW, LSP or Section. A From Martin.Vigoureux@alcatel-lucent.com Mon May 4 05:43:59 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753D128C0D7 for ; Mon, 4 May 2009 05:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZ2KatbayhFx for ; Mon, 4 May 2009 05:43:58 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 523453A701A for ; Mon, 4 May 2009 05:43:58 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n44CjIdX032660; Mon, 4 May 2009 14:45:18 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 14:45:18 +0200 Message-ID: <49FEE35D.6080908@alcatel-lucent.com> Date: Mon, 04 May 2009 14:45:17 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: hhelvoort@chello.nl References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com> <49FE21B7.2090605@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A754DA@DEMUEXC014.nsn-intra.net> <49FE95D2.5070103@chello.nl> <49FEB5E2.2070204@alcatel-lucent.com> <49FEE185.6030308@chello.nl> In-Reply-To: <49FEE185.6030308@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2009 12:45:18.0030 (UTC) FILETIME=[2DBDD6E0:01C9CCB6] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:43:59 -0000 cool :-) Huub van Helvoort a écrit : > Hello Martin, > > You wrote: > >> I still do not understand how the context you mention impacts >> what is written in the paragraph. Thanks. > > Now that I am fully awake and re-read the text a few times > I understand the intention. > I just wanted to have some clarification. > > Cheers, Huub. > > ================ >> Huub van Helvoort a écrit : >>> Hi Nurit, >>> >>> You wrote: >>> >>>>> here are my thoughts on this: >>>>> >>>>> As far as I understand, strictly speaking the Lock function >>>>> does not make sense on a unidir LSP. Indeed locking is performed >>>>> at the source point and so there is no need to send any message >>>>> to perform that Lock. (the potentially needed message is to inform >>>>> the end-point(s) of the status but that is lock notification. >>>>> I'll come back to this). >>>> >>>> What should happen if the CP and MP are separated, i.e the >>>> ingress point and egress poinr belong to different SP domains? >>> >>> I do not understand why you say that the separation of a CP and MP >>> indicates that the ingress and the egress point belong to different SP >>> domains? >>> >>> [hvh] because I should have used e.g. instead of i.e (it was late). >>> So there are cases that the lock in dication can only be transferred >>> via the DP. >>> >>> Regards, Huub. >>> >>>>> Therefore Lock is only needed on a bidir entity and what is exactly >>>>> needed is the capability to request the other end point to admin lock >>>>> its direction. >>>> >>>> What do you mean by "its direction", the direction from "the >>>> other end point" back to the "source point"? >>>> >>>>> Coming back to the notification, I believe the following requirement >>>>> is needed: >>>>> The MPLS-TP OAM toolset MUST provide a functionality to enable an >>>>> End Point of a PW, LSP or Section to inform the End Point(s) of >>>> that >>>>> LSP, PW, or Section that the PW, LSP or Section has been >>>>> administratively shutdown at this End Point. >>>>> But it is conditionally needed. This function is *only* needed if >>>>> locking is achieved via Lock, otherwise if it is achieved via NMS >>>>> commands >>>> >>>> This requires that both end points can be reached via the MP. >>>> >>>>> we (I hope) can safely assume that: >>>>> for undir LSP there will be commands at both ends, one saying lock, >>>> the >>>>> other saying you are notified of other end locking. >>>>> for bidir LSP there will be commands at both ends, both saying lock >>>> and >>>>> you are notified of other end locking. >>>>> >>>>> The MUST is needed because the egress must be aware of the Lock >>>> because >>>>> we expect him to then inform client MEPs that are "downstream". (see >>>>> question at the end of this e-mail). >>>>> >>>>> The small problem I have is that this function is a notification >>>>> one but really tightly linked to the Lock. In other words, I do >>>>> not know where this reqs better fits (especially wrt to the >>>> conditional >>>>> issue): in Lock or in Lock Notification? >>>>> Opinions are welcomed. >>>>> >>>>> Therefore I propose: >>>>> >>>>> 2.2.x. Lock >>>>> The MPLS-TP OAM toolset SHOULD provide a functionality to enable an >>>>> End Point of a bidirectional PW, LSP or Section to request to its >>>>> associated End Point that it administratively shuts down the direction >>>>> of the PW, LSP or Section for which it is the head-end. >>>>> >>>>> This function SHOULD be performed on-demand. >>>>> >>>>> This function SHOULD be performed between the End Points of a PW, LSP >>>>> or Section. >>>>> >>>>> Note that administratively shutting down corresponds to stopping >>>>> user traffic being sent on the PW, LSP or Section. >>>>> >>>>> >>>>> 2.2.y. Lock Notification >>>>> The MPLS-TP OAM toolset MUST provide a function to enable End Points >>>>> of a (server) LSP or Section to notify, of its administrative locking >>>>> status, the End Points of (client) PWs or LSPs affected by this >>>> status. >>>>> This function SHOULD be performed on-demand. >>>>> >>>>> This function SHOULD be performed between the End Points of a PW, LSP >>>>> or Section. >>>>> -comment: >>>>> this needs to be rephrased as the notifying end points may not be >>>>> the same nodes than the notified end points. >>>>> The general case is in fact a notification between end points of >>>>> different e.g., LSPs while the sentence seems to say that it is >>>> between >>>>> the end-points of the same e.g., LSP. >>>>> Any suggestion welcomed. >>>> >>>> Snip -- I will answer the next in a separate email-- >>>> >>>> Regards, Huub. >>>> >>> >> > From Martin.Vigoureux@alcatel-lucent.com Mon May 4 05:44:32 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D91A3A7026 for ; Mon, 4 May 2009 05:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[AWL=0.852, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCCP78eDUHCv for ; Mon, 4 May 2009 05:44:31 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 72D3D3A7025 for ; Mon, 4 May 2009 05:44:31 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n44CjkHN000433; Mon, 4 May 2009 14:45:53 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 14:45:51 +0200 Message-ID: <49FEE37F.8020200@alcatel-lucent.com> Date: Mon, 04 May 2009 14:45:51 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: hhelvoort@chello.nl References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <49FE21B7.2090605@chello.nl> <49FEB5DC.4060800@alcatel-lucent.com> <49FEE022.4080708@chello.nl> In-Reply-To: <49FEE022.4080708@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2009 12:45:51.0295 (UTC) FILETIME=[4191ACF0:01C9CCB6] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:44:32 -0000 ok, perfect. -m Huub van Helvoort a écrit : > Hi Martin, > > You replied: > >> please see inline, >> >> regards, >> -m >> >> Huub van Helvoort a écrit : >>> Bonsoir Martin, >>> >>> You wrote: >>> >>>> here are my thoughts on this: >>>> >>>> As far as I understand, strictly speaking the Lock function >>>> does not make sense on a unidir LSP. Indeed locking is performed >>>> at the source point and so there is no need to send any message >>>> to perform that Lock. (the potentially needed message is to inform >>>> the end-point(s) of the status but that is lock notification. >>>> I'll come back to this). >>> >>> What should happen if the CP and MP are separated, i.e the >>> ingress point and egress poinr belong to different SP domains? >> >> [mvx] please se my other e-mail. > > [hvh] OK, I will. > > >>>> Therefore Lock is only needed on a bidir entity and what is exactly >>>> needed is the capability to request the other end point to admin lock >>>> its direction. >>> >>> What do you mean by "its direction", the direction from "the >>> other end point" back to the "source point"? >> >> [mvx] in case of bidir, both nodes are sources points. >> What I mean is that a node (A) should have the means to ask its >> associated end point (Z) to Lock the direction of the LSP that >> goes from Z to A. >> >>> >>>> Coming back to the notification, I believe the following requirement >>>> is needed: >>>> The MPLS-TP OAM toolset MUST provide a functionality to enable an >>>> End Point of a PW, LSP or Section to inform the End Point(s) of that >>>> LSP, PW, or Section that the PW, LSP or Section has been >>>> administratively shutdown at this End Point. >>>> But it is conditionally needed. This function is *only* needed if >>>> locking is achieved via Lock, otherwise if it is achieved via NMS >>>> commands >>> >>> This requires that both end points can be reached via the MP. >> >> [mvx] indeed but that does not contradict the above. > > OK, I was confused by the added *conditionally* > >>>> we (I hope) can safely assume that: >>>> for undir LSP there will be commands at both ends, one saying lock, >>>> the other saying you are notified of other end locking. >>>> for bidir LSP there will be commands at both ends, both saying lock >>>> and you are notified of other end locking. >>>> >>>> The MUST is needed because the egress must be aware of the Lock because >>>> we expect him to then inform client MEPs that are "downstream". (see >>>> question at the end of this e-mail). >>>> >>>> The small problem I have is that this function is a notification >>>> one but really tightly linked to the Lock. In other words, I do >>>> not know where this reqs better fits (especially wrt to the conditional >>>> issue): in Lock or in Lock Notification? >>>> Opinions are welcomed. > > Cheers, Huub. > From Martin.Vigoureux@alcatel-lucent.com Mon May 4 05:49:20 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E403A688A for ; Mon, 4 May 2009 05:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.451 X-Spam-Level: X-Spam-Status: No, score=-5.451 tagged_above=-999 required=5 tests=[AWL=0.798, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lphSb1JzEFot for ; Mon, 4 May 2009 05:49:19 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 19D1C3A67C0 for ; Mon, 4 May 2009 05:49:18 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n44CnwO9002719; Mon, 4 May 2009 14:50:41 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 14:50:26 +0200 Message-ID: <49FEE492.2070609@alcatel-lucent.com> Date: Mon, 04 May 2009 14:50:26 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Malcolm Betts References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <0BDFFF51DC89434FA33F8B37FCE363D516FDB211@zcarhxm2.corp.nortel.com> In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516FDB211@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2009 12:50:26.0793 (UTC) FILETIME=[E5C75590:01C9CCB6] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:49:20 -0000 Malcolm, I fully agree that the lock is performed locally. I also agree that the other end point must be aware of this lock. This is exactly what I have written below. On bidir LSP the notification may be used to request the lock at the far end but this is for me an implementation decision. We should, as agreed during the call, stick to elementary functionalities. Therefore we need two distinct functionalities: inform the far end that lock has been performed request the far end to perform lock do we agree on that? one functionality I believe we also need is to inform client layers of the lock condition of a server, but I'll discuss this in the other e-mail you sent. regards, -m Malcolm Betts a écrit : > Martin, > > The key point is that the lock action is implemented locally. e.g. at the sending end of a LSP the traffic can be blocked. One example of the use of this is to allow a test source to be connected (vs. client traffic). Even on a unidirectional LSP it is useful to have a notification sent to the receiving end of the LSP so that it is aware that it is not receiving "valid" client traffic. > > On a bidirectional LSP this notification may be used to activate a lock in the reverse direction. > > Hope this clears up the confusion. > > > > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com > > -----Original Message----- > From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] > Sent: Sunday, May 03, 2009 2:22 PM > To: Adrian Farrel; Betts, Malcolm (CAR:X632) > Cc: mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock > > Adrian, Malcolm, all, > > here are my thoughts on this: > > As far as I understand, strictly speaking the Lock function does not make sense on a unidir LSP. Indeed locking is performed at the source point and so there is no need to send any message to perform that Lock. (the potentially needed message is to inform the end-point(s) of the status but that is lock notification. > I'll come back to this). > Therefore Lock is only needed on a bidir entity and what is exactly needed is the capability to request the other end point to admin lock its direction. > > Coming back to the notification, I believe the following requirement is needed: > The MPLS-TP OAM toolset MUST provide a functionality to enable an > End Point of a PW, LSP or Section to inform the End Point(s) of that > LSP, PW, or Section that the PW, LSP or Section has been > administratively shutdown at this End Point. > But it is conditionally needed. This function is *only* needed if locking is achieved via Lock, otherwise if it is achieved via NMS commands we (I hope) can safely assume that: > for undir LSP there will be commands at both ends, one saying lock, the other saying you are notified of other end locking. > for bidir LSP there will be commands at both ends, both saying lock and you are notified of other end locking. > > The MUST is needed because the egress must be aware of the Lock because we expect him to then inform client MEPs that are "downstream". (see question at the end of this e-mail). > > The small problem I have is that this function is a notification one but really tightly linked to the Lock. In other words, I do not know where this reqs better fits (especially wrt to the conditional > issue): in Lock or in Lock Notification? > Opinions are welcomed. > > Therefore I propose: > > 2.2.x. Lock > The MPLS-TP OAM toolset SHOULD provide a functionality to enable an End Point of a bidirectional PW, LSP or Section to request to its associated End Point that it administratively shuts down the direction of the PW, LSP or Section for which it is the head-end. > > This function SHOULD be performed on-demand. > > This function SHOULD be performed between the End Points of a PW, LSP or Section. > > Note that administratively shutting down corresponds to stopping user traffic being sent on the PW, LSP or Section. > > > 2.2.y. Lock Notification > The MPLS-TP OAM toolset MUST provide a function to enable End Points > of a (server) LSP or Section to notify, of its administrative locking > status, the End Points of (client) PWs or LSPs affected by this status. > > This function SHOULD be performed on-demand. > > This function SHOULD be performed between the End Points of a PW, LSP > or Section. > -comment: > this needs to be rephrased as the notifying end points may not be > the same nodes than the notified end points. > The general case is in fact a notification between end points of > different e.g., LSPs while the sentence seems to say that it is between > the end-points of the same e.g., LSP. > Any suggestion welcomed. > > See also my e-mail: > MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" > OAM messages ? > > -question: > More generally to the comment above, who should notify and who should > notify whom? > I would tend to say: > the receiving node of a locked direction, informs downstream receiving > nodes of nested LSPs. This is a Fowrward Indication and if we do > so then receiving points MUST indeed be informed of a Lock (c.f. > discussion at the beginning of the e-mail). > Should source points (locking points) do some reverse indication and > notify the source points of the LSPs that are nested in the locked LSP? > (but this maybe falls in the RDI functionality). > > I guess that is all, sorry for this long e-mail. > > regards, > -m > > > Adrian Farrel a écrit : >> Hi Malcolm, >> >>> To address the comments from Adrian I suggest the following >>> text for sections 2.2.7 and 2.2.8: >>> >>> Note that this proposal assumes that the text related to local/remote >>> faults is moved from section 2.2.8 to section 2.2.2 as proposed in my >>> previous email. >>> >>> We probably need to discuss this text on the MEAD team call next >>> week. >>> >>> 2.2.7. Lock >>> >>> The OAM toolset SHOULD provide a function enabling a network operator to >>> administratively shut down a PW, LSP or Section; that is, to stop user >>> traffic being sent over that PW, LSP or Section. >> This is great. >> Does it mean that we do not need to add the (similar) text on CV fault >> behavior in section 2.2.3? >> It would seem so. >> >>> The lock function MAY be applied to a unidirectional or a bidirectional >>> PW, LSP or Section. If the lock function is activated at the head end >>> of one direction of a bidirectional PW, LSP or Section then it SHOULD be >>> possible to cause the lock function to be activated at the head end of >>> the other direction. >>> >>> This function SHOULD be performed on-demand i.e. in response to an >>> operator command. >> Or also in response to configured automatic behavior? >> >> But this is not a protocol requirement. >> >>> This function SHOULD be performed between End Points of PWs, LSPs >>> and Sections. >>> >>> 2.2.8 Notification of Lock >>> >>> If the lock function is supported the MPLS-TP OAM toolset MUST >>> provide a function to enable the End Point at the ingress to notify the >>> End Points at the egress that the lock function is active. This >>> function SHOULD be performed pro-actively. >>> >>> The MPLS-TP OAM toolset MUST allow for the distinction between >>> a fault condition and an administrative locking action. >> Works for me. >> >> A >> >> >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop >> > From hhelvoort@chello.nl Mon May 4 05:53:58 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECBA23A6981 for ; Mon, 4 May 2009 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYgbbwn-ObX3 for ; Mon, 4 May 2009 05:53:58 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id A51743A6BB7 for ; Mon, 4 May 2009 05:53:57 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090504125521.TFXI17051.viefep18-int.chello.at@edge02.upc.biz>; Mon, 4 May 2009 14:55:21 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge02.upc.biz with edge id nQvK1b06n3KDBhC02QvLZt; Mon, 04 May 2009 14:55:21 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FEE5B7.7010603@chello.nl> Date: Mon, 04 May 2009 14:55:19 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Martin Vigoureux References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <49FE241F.5080007@chello.nl> <49FEB799.8080405@alcatel-lucent.com> In-Reply-To: <49FEB799.8080405@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:53:59 -0000 Bonjour Martin, You replied: > please see in-line. ditto > Huub van Helvoort a écrit : >> Bonsoir Martin, >> >> To continue with the othe rquestion: >> >>> See also my e-mail: >>> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" >>> OAM messages ? >> >> The answer was no. > > [mvx] well, I am not sure about this. [hvh] The definition used in ITU-T is: MEG Intermediate Point (MIP) is an intermediate point in a MEG which is capable of reacting to some OAM frames. A MIP does not initiate OAM frames. A MIP takes no action on the transit packet flows. >>> -question: >>> More generally to the comment above, who should notify and who should >>> notify whom? >>> I would tend to say: >>> the receiving node of a locked direction, informs downstream receiving >>> nodes of nested LSPs. >> >> To be more exact, the sink side of a locked LSP, PW, Section, has to >> inform its clients. > > [mvx] Indeed but that is not precise enough, in my view. > Who are the clients? Both end points or only the one downstream? [hvh] only the downstream (sink) end points (MEPs). >>> This is a Fowrward Indication and if we do >>> so then receiving points MUST indeed be informed of a Lock (c.f. >>> discussion at the beginning of the e-mail). >>> Should source points (locking points) do some reverse indication and >>> notify the source points of the LSPs that are nested in the locked LSP? >>> (but this maybe falls in the RDI functionality). >> >> Isn't this notification already caused by the locking at the >> far end? >> Or is the locking only applied in one direction of a bi-directional >> path? If yes, then the notification is not required. > > It appear to me that you are mixing the notification at the same > layer and notification at the impacted client layers. > My question was: > in case a Lock is performed at one point I suppose we need to inform > the other end point of that status (same layer) [hvh] I agree > But then what do these two nodes do? Which node of the locked server > layer inform which node of the impacted clients layer? [hvh] the sink MEP of the server layer should inform the sink MEPs of the client layer. Cheers, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From hhelvoort@chello.nl Mon May 4 05:58:58 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6493A6EF2 for ; Mon, 4 May 2009 05:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZy4T2xB37Jg for ; Mon, 4 May 2009 05:58:49 -0700 (PDT) Received: from viefep13-int.chello.at (viefep13-int.chello.at [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id 3261D3A6BB7 for ; Mon, 4 May 2009 05:58:48 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep13-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090504130013.VTAI25679.viefep13-int.chello.at@edge04.upc.biz>; Mon, 4 May 2009 15:00:13 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge04.upc.biz with edge id nR0B1b00m3KDBhC04R0CUi; Mon, 04 May 2009 15:00:13 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FEE6DA.3040009@chello.nl> Date: Mon, 04 May 2009 15:00:10 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Martin Vigoureux References: <49FDE174.7000904@alcatel-lucent.com> <49FE253E.5060803@chello.nl> <49FEB841.2010808@alcatel-lucent.com> In-Reply-To: <49FEB841.2010808@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:58:58 -0000 Hi Martin, You responded: > please see in-line. me too [hvh] > Huub van Helvoort a écrit : >> Bonsoir Martin, >> >> You wrote: >> >>> as part of the discussion on AIS/Lock Notification, >>> the server layer MEPs, detecting a fault/lock condition, should >>> inform (the MEPs of) the client layers relying on that >>> server layer and which are affected by the condition. >>> >>> However as I understand it is not the MEP (sMEP) of the >>> server layer that sends a notification to the client layers >>> MEPs (cMEP) but the MIP (cMIP) of the client layer which >>> is hosted on the same node than the MEP (sMEP). >>> See the figure below (where the double dashed line is >>> an LSP, and the ~ line represents an LSP nested in the >>> other LSP. >>> >>> +------+ +------+ +------+ +------+ >>> | |------| |------| cMIP |~~~~~~| cMEP | >>> | | | | | ^ | | | >>> | | | | | | | | | >>> | | | | | | | | | >>> | |======| |======| sMEP | | | >>> +------+ +------+ +------+ +------+ >> >> I modified the figure to align with what you wrote. > > [mvx] thx. In fact the double dashed line was already there > but with quite some spacing between the top and bottom. [hvh] OK, tI had the impression that the upper line indicated the client path/trail, and the lower the server path/trail >>> Therefore can MIPs send OAM messages without having priorly received one >>> or did I miss something? >> >> No, a MIP can only respond to messages it receives from a MEP >> that has the same MEG level, i.e. exists in the same path. >> >> In your figure the cMIP ignores messages sent by sMEP. > > but then, how does a Lock condition of the lower LSP > is notified to cMEP? This is a consequent action performed in the normal adaptation function between server and client layer. Best reagrds, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From BETTS01@nortel.com Mon May 4 06:19:31 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A083A7032 for ; Mon, 4 May 2009 06:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0xoGmW+Prmy for ; Mon, 4 May 2009 06:19:30 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 72B4D3A702F for ; Mon, 4 May 2009 06:19:29 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n44DKpb09395; Mon, 4 May 2009 13:20:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 09:20:35 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D517037DDC@zcarhxm2.corp.nortel.com> In-Reply-To: <49FEE492.2070609@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock Thread-Index: AcnMtvP9JdiiAA1kQsWkpcbeT4AvXgAA4m2w References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <0BDFFF51DC89434FA33F8B37FCE363D516FDB211@zcarhxm2.corp.nortel.com> <49FEE492.2070609@alcatel-lucent.com> From: "Malcolm Betts" To: "Martin Vigoureux" Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 13:19:31 -0000 Martin, I am tempted to simplify still further, just notify the far end that the = lock is in place and allow the decision to lock the reverse direction to = be a locally configured option. I cannot think of a case where you would only want to lock one direction = of a bidirectional LSP, so this would be the default behaviour. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com]=20 Sent: Monday, May 04, 2009 8:50 AM To: Betts, Malcolm (CAR:X632) Cc: Adrian Farrel; mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and = notification of lock Malcolm, I fully agree that the lock is performed locally. I also agree that the other end point must be aware of this lock. This is exactly what I have written below. On bidir LSP the notification may be used to request the lock at the far = end but this is for me an implementation decision. We should, as agreed during the call, stick to elementary = functionalities. Therefore we need two distinct functionalities: inform the far end that lock has been performed request the far end to = perform lock do we agree on that? one functionality I believe we also need is to inform client layers of = the lock condition of a server, but I'll discuss this in the other = e-mail you sent. regards, -m Malcolm Betts a =E9crit : > Martin, >=20 > The key point is that the lock action is implemented locally. e.g. at = the sending end of a LSP the traffic can be blocked. One example of the = use of this is to allow a test source to be connected (vs. client = traffic). Even on a unidirectional LSP it is useful to have a = notification sent to the receiving end of the LSP so that it is aware = that it is not receiving "valid" client traffic. >=20 > On a bidirectional LSP this notification may be used to activate a = lock in the reverse direction. >=20 > Hope this clears up the confusion. > =20 >=20 >=20 > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com >=20 > -----Original Message----- > From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] > Sent: Sunday, May 03, 2009 2:22 PM > To: Adrian Farrel; Betts, Malcolm (CAR:X632) > Cc: mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and=20 > notification of lock >=20 > Adrian, Malcolm, all, >=20 > here are my thoughts on this: >=20 > As far as I understand, strictly speaking the Lock function does not = make sense on a unidir LSP. Indeed locking is performed at the source = point and so there is no need to send any message to perform that Lock. = (the potentially needed message is to inform the end-point(s) of the = status but that is lock notification. > I'll come back to this). > Therefore Lock is only needed on a bidir entity and what is exactly = needed is the capability to request the other end point to admin lock = its direction. >=20 > Coming back to the notification, I believe the following requirement = is needed: > The MPLS-TP OAM toolset MUST provide a functionality to enable an > End Point of a PW, LSP or Section to inform the End Point(s) of = that > LSP, PW, or Section that the PW, LSP or Section has been > administratively shutdown at this End Point. > But it is conditionally needed. This function is *only* needed if = locking is achieved via Lock, otherwise if it is achieved via NMS = commands we (I hope) can safely assume that: > for undir LSP there will be commands at both ends, one saying lock, = the other saying you are notified of other end locking. > for bidir LSP there will be commands at both ends, both saying lock = and you are notified of other end locking. >=20 > The MUST is needed because the egress must be aware of the Lock = because we expect him to then inform client MEPs that are "downstream". = (see question at the end of this e-mail). >=20 > The small problem I have is that this function is a notification one=20 > but really tightly linked to the Lock. In other words, I do not know=20 > where this reqs better fits (especially wrt to the conditional > issue): in Lock or in Lock Notification? > Opinions are welcomed. >=20 > Therefore I propose: >=20 > 2.2.x. Lock > The MPLS-TP OAM toolset SHOULD provide a functionality to enable an = End Point of a bidirectional PW, LSP or Section to request to its = associated End Point that it administratively shuts down the direction = of the PW, LSP or Section for which it is the head-end. >=20 > This function SHOULD be performed on-demand. >=20 > This function SHOULD be performed between the End Points of a PW, LSP = or Section. >=20 > Note that administratively shutting down corresponds to stopping user = traffic being sent on the PW, LSP or Section. >=20 >=20 > 2.2.y. Lock Notification > The MPLS-TP OAM toolset MUST provide a function to enable End Points=20 > of a (server) LSP or Section to notify, of its administrative locking=20 > status, the End Points of (client) PWs or LSPs affected by this = status. >=20 > This function SHOULD be performed on-demand. >=20 > This function SHOULD be performed between the End Points of a PW, LSP=20 > or Section. > -comment: > this needs to be rephrased as the notifying end points may not be the=20 > same nodes than the notified end points. > The general case is in fact a notification between end points of=20 > different e.g., LSPs while the sentence seems to say that it is=20 > between the end-points of the same e.g., LSP. > Any suggestion welcomed. >=20 > See also my e-mail: > MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited"=20 > OAM messages ? >=20 > -question: > More generally to the comment above, who should notify and who should=20 > notify whom? > I would tend to say: > the receiving node of a locked direction, informs downstream receiving = > nodes of nested LSPs. This is a Fowrward Indication and if we do so=20 > then receiving points MUST indeed be informed of a Lock (c.f. > discussion at the beginning of the e-mail). > Should source points (locking points) do some reverse indication and=20 > notify the source points of the LSPs that are nested in the locked = LSP? > (but this maybe falls in the RDI functionality). >=20 > I guess that is all, sorry for this long e-mail. >=20 > regards, > -m >=20 >=20 > Adrian Farrel a =E9crit : >> Hi Malcolm, >> >>> To address the comments from Adrian I suggest the following text for = >>> sections 2.2.7 and 2.2.8: >>> >>> Note that this proposal assumes that the text related to=20 >>> local/remote faults is moved from section 2.2.8 to section 2.2.2 as=20 >>> proposed in my previous email. >>> >>> We probably need to discuss this text on the MEAD team call next=20 >>> week. >>> >>> 2.2.7. Lock >>> >>> The OAM toolset SHOULD provide a function enabling a network=20 >>> operator to administratively shut down a PW, LSP or Section; that=20 >>> is, to stop user traffic being sent over that PW, LSP or Section. >> This is great. >> Does it mean that we do not need to add the (similar) text on CV=20 >> fault behavior in section 2.2.3? >> It would seem so. >> >>> The lock function MAY be applied to a unidirectional or a=20 >>> bidirectional PW, LSP or Section. If the lock function is activated = >>> at the head end of one direction of a bidirectional PW, LSP or=20 >>> Section then it SHOULD be possible to cause the lock function to be=20 >>> activated at the head end of the other direction. >>> >>> This function SHOULD be performed on-demand i.e. in response to an=20 >>> operator command. >> Or also in response to configured automatic behavior? >> >> But this is not a protocol requirement. >> >>> This function SHOULD be performed between End Points of PWs, LSPs=20 >>> and Sections. >>> >>> 2.2.8 Notification of Lock >>> >>> If the lock function is supported the MPLS-TP OAM toolset MUST=20 >>> provide a function to enable the End Point at the ingress to notify=20 >>> the End Points at the egress that the lock function is active. This = >>> function SHOULD be performed pro-actively. >>> >>> The MPLS-TP OAM toolset MUST allow for the distinction between a=20 >>> fault condition and an administrative locking action. >> Works for me. >> >> A >> >> >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop >> >=20 From Martin.Vigoureux@alcatel-lucent.com Mon May 4 06:41:45 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE3F3A6F1F for ; Mon, 4 May 2009 06:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDDMkpHP4r-i for ; Mon, 4 May 2009 06:41:44 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 40CF23A6B7B for ; Mon, 4 May 2009 06:41:44 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n44Dh6Lw025460; Mon, 4 May 2009 15:43:06 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 15:43:06 +0200 Message-ID: <49FEF0EA.4080109@alcatel-lucent.com> Date: Mon, 04 May 2009 15:43:06 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: hhelvoort@chello.nl References: <49FDE174.7000904@alcatel-lucent.com> <49FE253E.5060803@chello.nl> <49FEB841.2010808@alcatel-lucent.com> <49FEE6DA.3040009@chello.nl> In-Reply-To: <49FEE6DA.3040009@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2009 13:43:06.0405 (UTC) FILETIME=[410DDD50:01C9CCBE] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 13:41:45 -0000 Huub, I am merging the two threads as they talk about the same point. Please see below. regards, -m Huub van Helvoort a écrit : > Hi Martin, > > You responded: > >> please see in-line. > > me too [hvh] > >> Huub van Helvoort a écrit : >>> Bonsoir Martin, >>> >>> You wrote: >>> >>>> as part of the discussion on AIS/Lock Notification, >>>> the server layer MEPs, detecting a fault/lock condition, should >>>> inform (the MEPs of) the client layers relying on that >>>> server layer and which are affected by the condition. >>>> >>>> However as I understand it is not the MEP (sMEP) of the >>>> server layer that sends a notification to the client layers >>>> MEPs (cMEP) but the MIP (cMIP) of the client layer which >>>> is hosted on the same node than the MEP (sMEP). >>>> See the figure below (where the double dashed line is >>>> an LSP, and the ~ line represents an LSP nested in the >>>> other LSP. >>>> >>>> +------+ +------+ +------+ +------+ >>>> | |------| |------| cMIP |~~~~~~| cMEP | >>>> | | | | | ^ | | | >>>> | | | | | | | | | >>>> | | | | | | | | | >>>> | |======| |======| sMEP | | | >>>> +------+ +------+ +------+ +------+ >>> >>> I modified the figure to align with what you wrote. >> >> [mvx] thx. In fact the double dashed line was already there >> but with quite some spacing between the top and bottom. > > [hvh] OK, tI had the impression that the upper line indicated > the client path/trail, and the lower the server path/trail > >>>> Therefore can MIPs send OAM messages without having priorly received >>>> one >>>> or did I miss something? >>> >>> No, a MIP can only respond to messages it receives from a MEP >>> that has the same MEG level, i.e. exists in the same path. >>> >>> In your figure the cMIP ignores messages sent by sMEP. >> >> but then, how does a Lock condition of the lower LSP >> is notified to cMEP? > > This is a consequent action performed in the normal > adaptation function between server and client layer. and you also say (in the other thread): [hvh] The definition used in ITU-T is: MEG Intermediate Point (MIP) is an intermediate point in a MEG which is capable of reacting to some OAM frames. A MIP does not initiate OAM frames. A MIP takes no action on the transit packet flows. and: [hvh] the sink MEP of the server layer should inform the sink MEPs of the client layer. How can sMEP send any message to cMEP, they do not belong to the same Maintenance Entity? The only way I see for cMEP to be informed is that cMIP sends the message and if so this contradicts the ITU definition because it does this, as you say, as a consequent action performed in the normal adaptation function between server and client layer (which I read as something different from receiving an OAM message). > > Best reagrds, Huub. > From loa@pi.nu Mon May 4 07:57:39 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25803A6B9A for ; Mon, 4 May 2009 07:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfmWk2eEzkCW for ; Mon, 4 May 2009 07:57:38 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id C47D23A6B18 for ; Mon, 4 May 2009 07:57:38 -0700 (PDT) Received: from [192.36.158.68] (wdhcp-158-68.verkstad.net [192.36.158.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id D0D8CD4048 for ; Mon, 4 May 2009 16:59:02 +0200 (CEST) Message-ID: <49FF02B2.8030904@pi.nu> Date: Mon, 04 May 2009 16:58:58 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: MEAD team Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mpls-interop] Schedule to address the the ITU-T comments on the MPLS-TP requirements X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 14:57:39 -0000 All, this is the schedule to respond to the comments from ITU-T SG15 on the MPLS-TP requirements. 1. Ben will produce a version of the draft for a MEAD team phone conference review on May 12th (At the MEAD team meeting on tomorrow we will try to "finish" the MEAD team review of the MPLS TP OAM requirements). This will be the meeting where we discuss the correct way of stating the reuiremetns thats has been discussed on the list. 2. After the MEAD team review on the 12th Ben will update the document and it will go for a two weeks wg last call, starting the 17 or 18th (depending a bit on how quicjk Ben can turn it around) 3. This wg lst call will overlap the SG15 interim meeting in Sophia, this was not intended from the satart. But Malcolm and I talked about and agreed that that it is not a bug but a feature. SG15 will be able to use their normal procedure to espond to the working group last call. 4. As a side effect I not feel comfortable to send the MPLS-TP NM requirements to a working group last call. /Loa -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu From loa@pi.nu Mon May 4 08:16:38 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13893A6A79 for ; Mon, 4 May 2009 08:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAhJ+wgtFQeH for ; Mon, 4 May 2009 08:16:38 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 69E103A7060 for ; Mon, 4 May 2009 08:16:04 -0700 (PDT) Received: from [192.36.158.68] (wdhcp-158-68.verkstad.net [192.36.158.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 73119D4048 for ; Mon, 4 May 2009 17:17:28 +0200 (CEST) Message-ID: <49FF0705.7020806@pi.nu> Date: Mon, 04 May 2009 17:17:25 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: MEAD team Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mpls-interop] MEAD team meeting in Stockholm prior to the IETF meeting - now scheduled X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 15:16:39 -0000 All, I've tried to organize a f2f meeting to discuss the MPLS-TP OAM solutions space. There seems to be a general agreement that we need such a meeting, with lots of white board time. I could not schedule this meeting in Sophia or in early June. I've therefore decided to run it in Stockholm, Thu through Sat, with an option to continue on Sun for those who have the interest and opportunity, the week before IETF. Start lunch time on Thu July 23rd in Kista north of Stockholm, close to the Arlanda airport. We will be in the Acreo facilities (free coffee, wireles and meeting room(s) provided). It is close to the subway (Kista), I'll be back with more details and some attempt for an agenda, but I guess it is enough to throw in a couple of different colored markers and a few white boards. and that will get you going ;) ). Thursday 1pm to 5pm (July 23) Friday 9am to 5pm (July 24) Saturday 9am to tbd (July 25) Sunday 9am to tbd (July 26, if needed) /Loa -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu From swallow@cisco.com Mon May 4 11:36:30 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611713A6EA2 for ; Mon, 4 May 2009 11:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3KC7-NTMDWZ for ; Mon, 4 May 2009 11:36:29 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 20FCB3A6E84 for ; Mon, 4 May 2009 11:36:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,292,1238976000"; d="scan'208";a="74565288" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 04 May 2009 18:36:49 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n44IanQf029926; Mon, 4 May 2009 11:36:49 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n44IamO8005992; Mon, 4 May 2009 18:36:49 GMT Received: from xmb-rtp-206.amer.cisco.com ([64.102.31.32]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 14:36:49 -0400 Received: from 10.98.32.163 ([10.98.32.163]) by xmb-rtp-206.amer.cisco.com ([64.102.31.32]) with Microsoft Exchange Server HTTP-DAV ; Mon, 4 May 2009 18:36:48 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 04 May 2009 14:36:45 -0400 From: George Swallow To: Martin Vigoureux , Message-ID: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? Thread-Index: AcnM50aOANna1QiNEEiory/5FCCaIQ== In-Reply-To: <49FEF0EA.4080109@alcatel-lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 04 May 2009 18:36:49.0100 (UTC) FILETIME=[48FFB8C0:01C9CCE7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4153; t=1241462209; x=1242326209; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:=20George=20Swallow=20 |Subject:=20Re=3A=20[Mpls-interop]=20MPLS-TP=20OAM=20requir ements=20-=20AIS/LockNotif=20-=20Can=0A=20MIPs=20send=20=22u solicited=22=20OAM=20messages=20? |Sender:=20; bh=Kau5s/5hiw/3z774r21ndh8RzW0vWaLwFQu4WUDju6A=; b=UtGMDc3FdKnEI70xb+SvdhP8EI6wDtye5rohk0T3YCsmAfvWQrrJs22vqW k4at+muehLeu7OYInDvk8TXqTJOHAO1rIRIvs4sm/hOz0vX8qsNqIVefNn1i +pP99T7eDI; Authentication-Results: sj-dkim-4; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 18:36:30 -0000 Huub - I very much agree with Martin here. In MPLS-TP the MEG level is not explicit. It is inferred from the LSP the OAM is received on. In typical LSRs, a Server layer down event, e.g. The failure of a link results in an "Interface Down Event". When this occurs all clients of that interface that have registered for the event would be notified. Further notification of peer entities is the responsibility of those clients. So to me it makes a great deal of sense to have the MEP serving the link declare that the IF is down, and have the client MIPs be responsible for sending any needed OAM messages regarding that event. ...George On 5/4/09 9:43 AM, "Martin Vigoureux" wrote: > Huub, >=20 > I am merging the two threads as they talk about the same point. > Please see below. >=20 > regards, > -m >=20 > Huub van Helvoort a =E9crit : >> Hi Martin, >>=20 >> You responded: >>=20 >>> please see in-line. >>=20 >> me too [hvh] >>=20 >>> Huub van Helvoort a =E9crit : >>>> Bonsoir Martin, >>>>=20 >>>> You wrote: >>>>=20 >>>>> as part of the discussion on AIS/Lock Notification, >>>>> the server layer MEPs, detecting a fault/lock condition, should >>>>> inform (the MEPs of) the client layers relying on that >>>>> server layer and which are affected by the condition. >>>>>=20 >>>>> However as I understand it is not the MEP (sMEP) of the >>>>> server layer that sends a notification to the client layers >>>>> MEPs (cMEP) but the MIP (cMIP) of the client layer which >>>>> is hosted on the same node than the MEP (sMEP). >>>>> See the figure below (where the double dashed line is >>>>> an LSP, and the ~ line represents an LSP nested in the >>>>> other LSP. >>>>>=20 >>>>> +------+ +------+ +------+ +------+ >>>>> | |------| |------| cMIP |~~~~~~| cMEP | >>>>> | | | | | ^ | | | >>>>> | | | | | | | | | >>>>> | | | | | | | | | >>>>> | |=3D=3D=3D=3D=3D=3D| |=3D=3D=3D=3D=3D=3D| sMEP | | | >>>>> +------+ +------+ +------+ +------+ >>>>=20 >>>> I modified the figure to align with what you wrote. >>>=20 >>> [mvx] thx. In fact the double dashed line was already there >>> but with quite some spacing between the top and bottom. >>=20 >> [hvh] OK, tI had the impression that the upper line indicated >> the client path/trail, and the lower the server path/trail >>=20 >>>>> Therefore can MIPs send OAM messages without having priorly received >>>>> one >>>>> or did I miss something? >>>>=20 >>>> No, a MIP can only respond to messages it receives from a MEP >>>> that has the same MEG level, i.e. exists in the same path. >>>>=20 >>>> In your figure the cMIP ignores messages sent by sMEP. >>>=20 >>> but then, how does a Lock condition of the lower LSP >>> is notified to cMEP? >>=20 >> This is a consequent action performed in the normal >> adaptation function between server and client layer. >=20 > and you also say (in the other thread): > [hvh] The definition used in ITU-T is: > MEG Intermediate Point (MIP) is an intermediate point in a MEG which > is capable of reacting to some OAM frames. A MIP does not initiate > OAM frames. A MIP takes no action on the transit packet flows. >=20 > and: > [hvh] the sink MEP of the server layer should inform the sink MEPs > of the client layer. >=20 > How can sMEP send any message to cMEP, they do not belong to the same > Maintenance Entity? > The only way I see for cMEP to be informed is that cMIP sends the > message and if so this contradicts the ITU definition because it does > this, as you say, as a consequent action performed in the normal > adaptation function between server and client layer (which I read > as something different from receiving an OAM message). >=20 >=20 >>=20 >> Best reagrds, Huub. >>=20 > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop From Martin.Vigoureux@alcatel-lucent.com Mon May 4 11:57:39 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756F33A69FC for ; Mon, 4 May 2009 11:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.982 X-Spam-Level: X-Spam-Status: No, score=-3.982 tagged_above=-999 required=5 tests=[AWL=-1.733, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJizSJx+eYs8 for ; Mon, 4 May 2009 11:57:38 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id C5F883A68A0 for ; Mon, 4 May 2009 11:57:36 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n44Iwwjw020353; Mon, 4 May 2009 20:58:58 +0200 Received: from [135.244.33.75] ([135.244.33.75]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 20:58:57 +0200 Message-ID: <49FF3AE6.6010200@alcatel-lucent.com> Date: Mon, 04 May 2009 20:58:46 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Malcolm Betts References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <0BDFFF51DC89434FA33F8B37FCE363D516FDB211@zcarhxm2.corp.nortel.com> <49FEE492.2070609@alcatel-lucent.com> <0BDFFF51DC89434FA33F8B37FCE363D517037DDC@zcarhxm2.corp.nortel.com> In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D517037DDC@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 May 2009 18:58:58.0283 (UTC) FILETIME=[6140F3B0:01C9CCEA] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 18:57:39 -0000 Malcolm, it appears that we agree on the need for the two functionalities: - notification to the receiving end point of lock having been performed at the source point. - request from an end point that the other far end performs a lock. What I do not understand is why do you want to force the piggybacking of the latter on the former. We should stick to required elementary functionalities and not impose a given protocol implementation. regards, martin Malcolm Betts a écrit : > Martin, > > I am tempted to simplify still further, just notify the far end that the lock is in place and allow the decision to lock the reverse direction to be a locally configured option. > > I cannot think of a case where you would only want to lock one direction of a bidirectional LSP, so this would be the default behaviour. > > > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com > > -----Original Message----- > From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] > Sent: Monday, May 04, 2009 8:50 AM > To: Betts, Malcolm (CAR:X632) > Cc: Adrian Farrel; mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock > > Malcolm, > > I fully agree that the lock is performed locally. > I also agree that the other end point must be aware of this lock. > This is exactly what I have written below. > > On bidir LSP the notification may be used to request the lock at the far end but this is for me an implementation decision. > We should, as agreed during the call, stick to elementary functionalities. > Therefore we need two distinct functionalities: > inform the far end that lock has been performed request the far end to perform lock > > do we agree on that? > > one functionality I believe we also need is to inform client layers of the lock condition of a server, but I'll discuss this in the other e-mail you sent. > > regards, > -m > > Malcolm Betts a écrit : >> Martin, >> >> The key point is that the lock action is implemented locally. e.g. at the sending end of a LSP the traffic can be blocked. One example of the use of this is to allow a test source to be connected (vs. client traffic). Even on a unidirectional LSP it is useful to have a notification sent to the receiving end of the LSP so that it is aware that it is not receiving "valid" client traffic. >> >> On a bidirectional LSP this notification may be used to activate a lock in the reverse direction. >> >> Hope this clears up the confusion. >> >> >> >> Malcolm Betts >> Nortel Networks >> Phone: +1 613 763 7860 (ESN 393) >> email: betts01@nortel.com >> >> -----Original Message----- >> From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] >> Sent: Sunday, May 03, 2009 2:22 PM >> To: Adrian Farrel; Betts, Malcolm (CAR:X632) >> Cc: mpls-interop@ietf.org >> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and >> notification of lock >> >> Adrian, Malcolm, all, >> >> here are my thoughts on this: >> >> As far as I understand, strictly speaking the Lock function does not make sense on a unidir LSP. Indeed locking is performed at the source point and so there is no need to send any message to perform that Lock. (the potentially needed message is to inform the end-point(s) of the status but that is lock notification. >> I'll come back to this). >> Therefore Lock is only needed on a bidir entity and what is exactly needed is the capability to request the other end point to admin lock its direction. >> >> Coming back to the notification, I believe the following requirement is needed: >> The MPLS-TP OAM toolset MUST provide a functionality to enable an >> End Point of a PW, LSP or Section to inform the End Point(s) of that >> LSP, PW, or Section that the PW, LSP or Section has been >> administratively shutdown at this End Point. >> But it is conditionally needed. This function is *only* needed if locking is achieved via Lock, otherwise if it is achieved via NMS commands we (I hope) can safely assume that: >> for undir LSP there will be commands at both ends, one saying lock, the other saying you are notified of other end locking. >> for bidir LSP there will be commands at both ends, both saying lock and you are notified of other end locking. >> >> The MUST is needed because the egress must be aware of the Lock because we expect him to then inform client MEPs that are "downstream". (see question at the end of this e-mail). >> >> The small problem I have is that this function is a notification one >> but really tightly linked to the Lock. In other words, I do not know >> where this reqs better fits (especially wrt to the conditional >> issue): in Lock or in Lock Notification? >> Opinions are welcomed. >> >> Therefore I propose: >> >> 2.2.x. Lock >> The MPLS-TP OAM toolset SHOULD provide a functionality to enable an End Point of a bidirectional PW, LSP or Section to request to its associated End Point that it administratively shuts down the direction of the PW, LSP or Section for which it is the head-end. >> >> This function SHOULD be performed on-demand. >> >> This function SHOULD be performed between the End Points of a PW, LSP or Section. >> >> Note that administratively shutting down corresponds to stopping user traffic being sent on the PW, LSP or Section. >> >> >> 2.2.y. Lock Notification >> The MPLS-TP OAM toolset MUST provide a function to enable End Points >> of a (server) LSP or Section to notify, of its administrative locking >> status, the End Points of (client) PWs or LSPs affected by this status. >> >> This function SHOULD be performed on-demand. >> >> This function SHOULD be performed between the End Points of a PW, LSP >> or Section. >> -comment: >> this needs to be rephrased as the notifying end points may not be the >> same nodes than the notified end points. >> The general case is in fact a notification between end points of >> different e.g., LSPs while the sentence seems to say that it is >> between the end-points of the same e.g., LSP. >> Any suggestion welcomed. >> >> See also my e-mail: >> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" >> OAM messages ? >> >> -question: >> More generally to the comment above, who should notify and who should >> notify whom? >> I would tend to say: >> the receiving node of a locked direction, informs downstream receiving >> nodes of nested LSPs. This is a Fowrward Indication and if we do so >> then receiving points MUST indeed be informed of a Lock (c.f. >> discussion at the beginning of the e-mail). >> Should source points (locking points) do some reverse indication and >> notify the source points of the LSPs that are nested in the locked LSP? >> (but this maybe falls in the RDI functionality). >> >> I guess that is all, sorry for this long e-mail. >> >> regards, >> -m >> >> >> Adrian Farrel a écrit : >>> Hi Malcolm, >>> >>>> To address the comments from Adrian I suggest the following text for >>>> sections 2.2.7 and 2.2.8: >>>> >>>> Note that this proposal assumes that the text related to >>>> local/remote faults is moved from section 2.2.8 to section 2.2.2 as >>>> proposed in my previous email. >>>> >>>> We probably need to discuss this text on the MEAD team call next >>>> week. >>>> >>>> 2.2.7. Lock >>>> >>>> The OAM toolset SHOULD provide a function enabling a network >>>> operator to administratively shut down a PW, LSP or Section; that >>>> is, to stop user traffic being sent over that PW, LSP or Section. >>> This is great. >>> Does it mean that we do not need to add the (similar) text on CV >>> fault behavior in section 2.2.3? >>> It would seem so. >>> >>>> The lock function MAY be applied to a unidirectional or a >>>> bidirectional PW, LSP or Section. If the lock function is activated >>>> at the head end of one direction of a bidirectional PW, LSP or >>>> Section then it SHOULD be possible to cause the lock function to be >>>> activated at the head end of the other direction. >>>> >>>> This function SHOULD be performed on-demand i.e. in response to an >>>> operator command. >>> Or also in response to configured automatic behavior? >>> >>> But this is not a protocol requirement. >>> >>>> This function SHOULD be performed between End Points of PWs, LSPs >>>> and Sections. >>>> >>>> 2.2.8 Notification of Lock >>>> >>>> If the lock function is supported the MPLS-TP OAM toolset MUST >>>> provide a function to enable the End Point at the ingress to notify >>>> the End Points at the egress that the lock function is active. This >>>> function SHOULD be performed pro-actively. >>>> >>>> The MPLS-TP OAM toolset MUST allow for the distinction between a >>>> fault condition and an administrative locking action. >>> Works for me. >>> >>> A >>> >>> >>> >>> _______________________________________________ >>> Mpls-interop mailing list >>> Mpls-interop@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-interop >>> > From loa@pi.nu Mon May 4 13:19:20 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE04428C265 for ; Mon, 4 May 2009 13:19:20 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVq292Auksnc for ; Mon, 4 May 2009 13:19:20 -0700 (PDT) Received: from av6-1-sn3.vrr.skanova.net (av6-1-sn3.vrr.skanova.net [81.228.9.179]) by core3.amsl.com (Postfix) with ESMTP id E885028C263 for ; Mon, 4 May 2009 13:19:19 -0700 (PDT) Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id E89143821C; Mon, 4 May 2009 22:20:44 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id B83C037F4D for ; Mon, 4 May 2009 22:20:44 +0200 (CEST) Received: from [127.0.0.1] (h133n2fls33o883.telia.com [217.208.62.133]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 796D837E46 for ; Mon, 4 May 2009 22:20:44 +0200 (CEST) Message-ID: <49FF4E19.2060203@pi.nu> Date: Mon, 04 May 2009 22:20:41 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: MEAD team References: <49FF02B2.8030904@pi.nu> In-Reply-To: <49FF02B2.8030904@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Mpls-interop] Schedule to address the the ITU-T comments on the MPLS-TP requirements X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:19:20 -0000 All, sometimes it is good to have a working group sectreatry :) please see inline Loa Andersson wrote: > All, > > this is the schedule to respond to the comments from ITU-T SG15 > on the MPLS-TP requirements. > > 1. Ben will produce a version of the draft for a MEAD team > phone conference review on May 12th > (At the MEAD team meeting on tomorrow we will try to "finish" > the MEAD team review of the MPLS TP OAM requirements). > This will be the meeting where we discuss the correct way > of stating the reuiremetns thats has been discussed on the > list. > > 2. After the MEAD team review on the 12th Ben will update the > document and it will go for a two weeks wg last call, starting > the 17 or 18th (depending a bit on how quicjk Ben can turn it > around) > > 3. This wg lst call will overlap the SG15 interim meeting in > Sophia, this was not intended from the satart. But Malcolm and > I talked about and agreed that that it is not a bug but a feature. > SG15 will be able to use their normal procedure to espond to > the working group last call. > > 4. As a side effect I not feel comfortable to send the MPLS-TP > NM requirements to a working group last call. this paragraph should hav read> 4. As a side effect I now feel comfortable to send the MPLS-TP NM requirements to a working group last call. /Loa > > /Loa -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu From hhelvoort@chello.nl Mon May 4 14:26:42 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4563A6CA1 for ; Mon, 4 May 2009 14:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbEzKmfk-+vL for ; Mon, 4 May 2009 14:26:40 -0700 (PDT) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id 5C01B3A6FCE for ; Mon, 4 May 2009 14:25:44 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090504212707.PAQQ15840.viefep11-int.chello.at@edge05.upc.biz>; Mon, 4 May 2009 23:27:07 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge05.upc.biz with edge id nZT51b05U3KDBhC05ZT7R5; Mon, 04 May 2009 23:27:07 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FF5DA9.4000807@chello.nl> Date: Mon, 04 May 2009 23:27:05 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Malcolm Betts References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net> <0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:26:42 -0000 Hi Malcolm, You wrote: > I think you are making this far too complicated... I see no need to > propagate the locked indication across layers. > > If the operator decides to lock a LSP (for example to run a test) then > the clients of that LSP should be taken out of service before the lock > is applied. That should be the proper procedure. > When a server LSP detects the locked notification it informs the client > adaptation that it is no longer receiving valid traffic. If the client > has already been taken out of service then this is a "don't care". If > the client has not been taken out of service then it should raise an > alarm. But shouldn't the client layer be able to determine whether the fault cause is in its own layer or in the server layer? This is similar to the notification server trail failure to its client layer. So in fact the same notification can be used for both cases. Regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From hhelvoort@chello.nl Mon May 4 14:34:37 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8881F3A6C87 for ; Mon, 4 May 2009 14:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwqWTugch7Nf for ; Mon, 4 May 2009 14:34:36 -0700 (PDT) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id F26DE3A6B29 for ; Mon, 4 May 2009 14:34:35 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090504213600.PHBY15840.viefep11-int.chello.at@edge03.upc.biz>; Mon, 4 May 2009 23:36:00 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge03.upc.biz with edge id nZby1b06q3KDBhC03Zc0H7; Mon, 04 May 2009 23:36:00 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FF5FBE.9050907@chello.nl> Date: Mon, 04 May 2009 23:35:58 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Martin Vigoureux References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <0BDFFF51DC89434FA33F8B37FCE363D516FDB211@zcarhxm2.corp.nortel.com> <49FEE492.2070609@alcatel-lucent.com> In-Reply-To: <49FEE492.2070609@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:34:37 -0000 Hello Martin, You wrote: > Malcolm, > > I fully agree that the lock is performed locally. > I also agree that the other end point must be aware of this lock. > This is exactly what I have written below. > > On bidir LSP the notification may be used to request the lock > at the far end but this is for me an implementation decision. > We should, as agreed during the call, stick to elementary > functionalities. > Therefore we need two distinct functionalities: > inform the far end that lock has been performed > request the far end to perform lock > > do we agree on that? Not replying for Malcolm, but sharing my own opinion: Yes, I agree. > one functionality I believe we also need is to inform client > layers of the lock condition of a server, but I'll discuss > this in the other e-mail you sent. Is it necessary to be so specific? It should be sufficient to notify the client layer that the path/trail is not usable, without telling the reason. The only purpose of the notification is that the client layer need not to take any fault locating actions. (This is the same as my answer to Malcolm some minutes ago) Best reagrds, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From hhelvoort@chello.nl Mon May 4 15:01:44 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E7D3A69B4 for ; Mon, 4 May 2009 15:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i97IglgKb0wN for ; Mon, 4 May 2009 15:01:44 -0700 (PDT) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id E07EB3A70B9 for ; Mon, 4 May 2009 15:01:40 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090504220303.WQAT19075.viefep19-int.chello.at@edge01.upc.biz>; Tue, 5 May 2009 00:03:03 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge01.upc.biz with edge id na321b01R3KDBhC01a33dj; Tue, 05 May 2009 00:03:03 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49FF6616.3050905@chello.nl> Date: Tue, 05 May 2009 00:03:02 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Swallow References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 22:01:44 -0000 Hello George, You wrote: > I very much agree with Martin here. > > In MPLS-TP the MEG level is not explicit. It is inferred from the LSP the > OAM is received on. In typical LSRs, a Server layer down event, e.g. The > failure of a link results in an "Interface Down Event". When this occurs > all clients of that interface that have registered for the event would be > notified. Further notification of peer entities is the responsibility of > those clients. I agree with this as well. > So to me it makes a great deal of sense to have the MEP serving the link > declare that the IF is down, and have the client MIPs be responsible for > sending any needed OAM messages regarding that event. The notification of the "interface down event" should be accomplished by inserting the OAM message (server failed) in the adaptation function of the server layer MEP. Regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From hejia@huawei.com Mon May 4 19:19:45 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002493A6F73 for ; Mon, 4 May 2009 19:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.743 X-Spam-Level: ** X-Spam-Status: No, score=2.743 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZCysTPyP6yJ for ; Mon, 4 May 2009 19:19:43 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 0A2B13A7132 for ; Mon, 4 May 2009 19:19:43 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ500CQJFUYXM@szxga02-in.huawei.com> for mpls-interop@ietf.org; Tue, 05 May 2009 10:20:58 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ500LHCFUXMG@szxga02-in.huawei.com> for mpls-interop@ietf.org; Tue, 05 May 2009 10:20:58 +0800 (CST) Received: from h48726 ([10.70.77.156]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ500CJMFUWHP@szxml06-in.huawei.com> for mpls-interop@ietf.org; Tue, 05 May 2009 10:20:57 +0800 (CST) Date: Tue, 05 May 2009 10:20:56 +0800 From: Jia HE To: ext Martin Vigoureux Message-id: <006401c9cd28$1faeb8e0$9c4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_hg2JzpqALdnpZCOl4kfb1w)" X-Priority: 3 X-MSMail-priority: Normal References: <077E41CFFD002C4CAB7DFA4386A53264A4243E@DEMUEXC014.nsn-intra.net> Cc: MEAD team Subject: Re: [Mpls-interop] FW: Question for Clarification on the MPLS-TPOAMRequirement Draft X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 02:19:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_hg2JzpqALdnpZCOl4kfb1w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Martin, I have the same concerns as Nurit and Italo. Ans still one more question for clarification about Section 2.1.2. It indicates the first scenario as IP/MPLS environments, how is this interpreted? Does it mean "MPLS-TP is run with IP routing and forwarding capabilities" as described in Section 2.1.3? And what about the description in Section 2.1.3 "When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate any of the existing IP/MPLS and PW OAM functionalities"? Is it the same as the first requirement in Section 2.1.2? Can we simply interpret this as "MPLS-TP OAM doesn't rely on IP routing and forwarding capabilities" and "MPLS-TP OAM doesn't impact existing IP/MPLS and PW OAM functionalities when they are used together"? Thanks for your help! Best Regards, Jia ----- Original Message ----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) To: ext Martin Vigoureux Cc: MEAD team Sent: Thursday, April 30, 2009 2:17 PM Subject: [Mpls-interop] FW: Question for Clarification on the MPLS-TPOAMRequirement Draft Hi martin, Could you please update the text accordingly to avoid confusions? Thanks, Nurit ------------------------------------------------------------------------------ From: ext BUSI ITALO [mailto:Italo.Busi@alcatel-lucent.it] Sent: Wednesday, April 29, 2009 1:43 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); VIGOUREUX MARTIN Cc: MEAD team Subject: RE: [Mpls-interop] Question for Clarification on the MPLS-TP OAMRequirement Draft Nurit, I have the same interpretation as you have. I wonder whether not to rephrase the paragraph on the basis of what you wrote below. Italo ---------------------------------------------------------------------------- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Tuesday, April 28, 2009 6:59 PM To: VIGOUREUX MARTIN Cc: MEAD team Subject: [Mpls-interop] Question for Clarification on the MPLS-TP OAMRequirement Draft Martin, I have a question for clarification on section 2.1.2. In the first bullet it is written that "In some environments.IP routing and forwarding capabilities are inherently present. In this case, the OAM functionality MUST support the use of IP routing and forwarding capabilities." I guess that MUST means that the protocol MUST support OAM mechanisms based on IP functionality to be able to run it in this environment, but do not require that this will be necessarily the implementation in this environment. Right? We can still may select to use OAM mechanisms in this environment that are not based on IP functionality. Right? It is just that the protocol MUST support it. I'll appreciate if you can confirm it or clarify the intention. Thanks and best regards, Nurit. ----------------------------------------- Best regards, Nurit Sprecher Nokia Siemens Networks GmbH & Co. KG Industry Environment Senior Specialist, Carrier Ethernet Transport 3 Hanagar St. Neve Ne'eman B 45241 Hod Hasharon, Israel Tel. +972 9 7751229 Mobile +972 54 2200954 Email: nurit.sprecher@nsn.com ------------------------------------------------------------------------------ _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --Boundary_(ID_hg2JzpqALdnpZCOl4kfb1w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpzdDEgPSANCiJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVp dj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0K PE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC4zNTI3IiBuYW1lPUdFTkVSQVRPUj48IS0t W2lmICFtc29dPg0KPFNUWUxFPnZcOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0K fQ0Kb1w6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQp3XDoqIHsNCglCRUhB VklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0NCi5zaGFwZSB7DQoJQkVIQVZJT1I6IHVybCgjZGVm YXVsdCNWTUwpDQp9DQo8L1NUWUxFPg0KPCFbZW5kaWZdLS0+PG86U21hcnRUYWdUeXBlIG5hbWU9 ImNvdW50cnktcmVnaW9uIiANCm5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6c21hcnR0YWdzIj48L286U21hcnRUYWdUeXBlPjxvOlNtYXJ0VGFnVHlwZSANCm5h bWU9IkNpdHkiIA0KbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmlj ZTpzbWFydHRhZ3MiPjwvbzpTbWFydFRhZ1R5cGU+PG86U21hcnRUYWdUeXBlIA0KbmFtZT0icGxh Y2UiIA0KbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFy dHRhZ3MiPjwvbzpTbWFydFRhZ1R5cGU+PCEtLVtpZiAhbXNvXT4NCjxTVFlMRT4NCnN0MVw6Knti ZWhhdmlvcjp1cmwoI2RlZmF1bHQjaWVvb3VpKSB9DQo8L1NUWUxFPg0KPCFbZW5kaWZdLS0+DQo8 U1RZTEU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5zZWN0aW9uMSwgbGkuc2VjdGlvbjEsIGRp di5zZWN0aW9uMQ0KCXttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkFyaWFs Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eTpBcmlhbDsNCgljb2xvcjpuYXZ5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LlNlY3Rp b24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KPCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQog PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvSEVBRD4NCjxCT0RZIGxhbmc9RU4t VVMgdkxpbms9cHVycGxlIGxpbms9Ymx1ZSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPkhpIE1hcnRp biw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgaGF2ZSB0aGUgc2FtZSBjb25jZXJu cyBhcyBOdXJpdCBhbmQgSXRhbG8uIEFucyBzdGlsbCBvbmUgbW9yZSBxdWVzdGlvbiANCmZvciBj bGFyaWZpY2F0aW9uIGFib3V0IFNlY3Rpb24mbmJzcDsyLjEuMi4gPC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj5JdCBpbmRpY2F0ZXMgdGhlIGZpcnN0Jm5ic3A7c2NlbmFyaW8gYXMmbmJz cDs8Rk9OVCBzaXplPTM+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEwLjVw dDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250LXNpemU6IDEy LjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjMjM0MzU7JiMyMDMwNzs7IG1zby1mb250 LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5JUC9NUExTIA0KZW52aXJv bm1lbnRzLCBob3cgaXMgdGhpcyZuYnNwO2ludGVycHJldGVkPyBEb2VzJm5ic3A7aXQgbWVhbiA8 Rk9OVCANCmNvbG9yPSMwMDAwZmY+Ik1QTFMtVFAgaXMgcnVuIHdpdGggSVAgcm91dGluZyBhbmQg ZjwvRk9OVD48L1NQQU4+PFNQQU4gDQpsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTAu NXB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtc2l6ZTog MTIuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiMyMzQzNTsmIzIwMzA3OzsgbXNvLWZv bnQta2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIA0KY29sb3I9 IzAwMDBmZj5vcndhcmRpbmcgPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9 IkZPTlQtU0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1i aWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiMyMzQzNTsm IzIwMzA3OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1V UzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0Ei PjxGT05UIA0KY29sb3I9IzAwMDBmZj5jYXBhYmlsaXRpZXMiIDxGT05UIGNvbG9yPSMwMDAwMDA+ YXM8L0ZPTlQ+IDwvRk9OVD48Rk9OVCANCmNvbG9yPSMwMDAwMDA+ZGVzY3JpYmVkIGluIDwvRk9O VD48L1NQQU4+U2VjdGlvbiAyLjEuMz88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5BbmQgd2hhdCBhYm91dCB0aGUgZGVzY3JpcHRpb24gaW4gU2VjdGlvbiAyLjEuMyAmbmJz cDsiPEEgDQpzdHlsZT0ibXNvLWNvbW1lbnQtcmVmZXJlbmNlOiBJRF8xOyBtc28tY29tbWVudC1k YXRlOiAyMDA5MDUwNFQxNTUwIj48U1BBTiANCmxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpF OiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1z aXplOiAxMi4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7OyBt c28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFy ZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQpz aXplPTM+V2hlbiA8Rk9OVCBjb2xvcj0jMDAwMGZmPk1QTFMtVFAgaXMgcnVuIHdpdGggDQo8L0ZP TlQ+PC9GT05UPjwvU1BBTj48L0E+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6 IDEwLjVwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250LXNp emU6IDEyLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjMjM0MzU7JiMyMDMwNzs7IG1z by1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJl YXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48Rk9OVCANCnNp emU9Mz48Rk9OVCBjb2xvcj0jMDAwMGZmPklQIHJvdXRpbmcgYW5kIGY8U1BBTiBsYW5nPUVOLVVT IA0Kc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21h bic7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog JiMyMzQzNTsmIzIwMzA3OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1 YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFn ZTogQVItU0EiPm9yd2FyZGluZyANCjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUyANCnN0 eWxlPSJGT05ULVNJWkU6IDEwLjVwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBt c28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjMjM0 MzU7JiMyMDMwNzs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTog RU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFS LVNBIj48Rk9OVCANCmNvbG9yPSMwMDAwZmY+Y2FwYWJpbGl0aWVzPC9GT05UPjwvU1BBTj4sIGl0 IE1VU1QgYmUgcG9zc2libGUgdG8gb3BlcmF0ZSBhbnkgb2YgDQp0aGUgZXhpc3RpbmcgSVAvTVBM UyBhbmQgUFcgT0FNIGZ1bmN0aW9uYWxpdGllcyI/IElzIGl0IHRoZSBzYW1lIGFzIHRoZSBmaXJz dCANCnJlcXVpcmVtZW50IGluJm5ic3A7U2VjdGlvbiZuYnNwOzIuMS4yPzwvRk9OVD48L1NQQU4+ PC9ESVY+DQo8RElWPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQ7 IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4w cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7OyBtc28tZm9udC1r ZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5n dWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PC9TUEFOPiZuYnNwOzwvRElW Pg0KPERJVj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0OyBGT05U LUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBt c28tZmFyZWFzdC1mb250LWZhbWlseTogJiMyMzQzNTsmIzIwMzA3OzsgbXNvLWZvbnQta2Vybmlu ZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIA0Kc2l6ZT0zPkNhbiB3ZSBz aW1wbHkgaW50ZXJwcmV0IHRoaXMgYXMgIk1QTFMtVFAgT0FNIGRvZXNuJ3QgcmVseSBvbiBJUCBy b3V0aW5nIA0KYW5kIGZvcndhcmRpbmcgY2FwYWJpbGl0aWVzIiBhbmQgIk1QTFMtVFAgT0FNIGRv ZXNuJ3QgaW1wYWN0IGV4aXN0aW5nIElQL01QTFMgDQphbmQgUFcgT0FNIGZ1bmN0aW9uYWxpdGll cyB3aGVuIHRoZXkgYXJlIHVzZWQgdG9nZXRoZXIiPzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZ OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBw dDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047 IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BB TiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTogJ1Rp bWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tZmFyZWFzdC1m b250LWZhbWlseTogJiMyMzQzNTsmIzIwMzA3OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1z by1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28t YmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIA0Kc2l6ZT0zPlRoYW5rcyBmb3IgeW91ciBoZWxw ITwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9O VC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGkt Zm9udC1zaXplOiAxMi4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAz MDc7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBt c28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PC9T UEFOPiZuYnNwOzwvRElWPg0KPERJViBzdHlsZT0ibXNvLWVsZW1lbnQ6IGNvbW1lbnQtbGlzdCI+ DQo8RElWIHN0eWxlPSJtc28tZWxlbWVudDogY29tbWVudCI+DQo8RElWIGxhbmd1YWdlPUphdmFT Y3JpcHQgY2xhc3M9bXNvY29tdHh0IGlkPV9jb21fMSANCm9ubW91c2VvdmVyPSJtc29Db21tZW50 U2hvdygnX2FuY2hvcl8xJywnX2NvbV8xJykiIA0Kb25tb3VzZW91dD0ibXNvQ29tbWVudEhpZGUo J19jb21fMScpIj4NCjxQIGNsYXNzPU1zb0NvbW1lbnRUZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAw Y20gMHB0Ij48U1BBTiANCmxhbmc9RU4tVVM+PC9TUEFOPjwvUD48L0RJVj48L0RJVj48L0RJVj4N CjxESVY+QmVzdCBSZWdhcmRzLDwvRElWPg0KPERJVj5KaWE8L0RJVj4NCjxESVY+PFNQQU4gbGFu Zz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEwLjVwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBO ZXcgUm9tYW4nOyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6ICYjMjM0MzU7JiMyMDMwNzs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5z aS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGkt bGFuZ3VhZ2U6IEFSLVNBIj48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMy MzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RF IA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1M RUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAw cHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+LS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0 ZTRlNDsgRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5G cm9tOjwvQj4gDQogIDxBIHRpdGxlPW51cml0LnNwcmVjaGVyQG5zbi5jb20gaHJlZj0ibWFpbHRv Om51cml0LnNwcmVjaGVyQG5zbi5jb20iPlNwcmVjaGVyLCANCiAgTnVyaXQgKE5TTiAtIElML0hv ZCBIYVNoYXJvbik8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsm IzIwMzA3OyI+PEI+VG86PC9CPiA8QSANCiAgdGl0bGU9bWFydGluLnZpZ291cmV1eEBhbGNhdGVs LWx1Y2VudC5jb20gDQogIGhyZWY9Im1haWx0bzptYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVj ZW50LmNvbSI+ZXh0IE1hcnRpbiBWaWdvdXJldXg8L0E+IA0KICA8L0RJVj4NCiAgPERJViBzdHls ZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9bXBscy1p bnRlcm9wQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86bXBscy1pbnRlcm9wQGlldGYub3JnIj5N RUFEIHRlYW08L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIw MzA3OyI+PEI+U2VudDo8L0I+IFRodXJzZGF5LCBBcHJpbCAzMCwgMjAwOSAyOjE3IFBNPC9ESVY+ DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0Ojwv Qj4gW01wbHMtaW50ZXJvcF0gRlc6IFF1ZXN0aW9uIGZvciANCiAgQ2xhcmlmaWNhdGlvbiBvbiB0 aGUgTVBMUy1UUE9BTVJlcXVpcmVtZW50IERyYWZ0PC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0K ICA8RElWIGNsYXNzPVNlY3Rpb24xPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Q09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+ PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5 OyBGT05ULUZBTUlMWTogQXJpYWwiPkhpIA0KICBtYXJ0aW4sPG86cD48L286cD48L1NQQU4+PC9G T05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2 eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBG T05ULUZBTUlMWTogQXJpYWwiPkNvdWxkIHlvdSBwbGVhc2UgDQogIHVwZGF0ZSB0aGUgdGV4dCBh Y2NvcmRpbmdseSB0byBhdm9pZCBjb25mdXNpb25zPzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1G QU1JTFk6IEFyaWFsIj5UaGFua3MsPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJp YWwiPk51cml0PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPERJVj4NCiAgPERJViBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGNlbnRlciIgYWxpZ249Y2VudGVyPjxG T05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4NCiAgPEhSIHRh YkluZGV4PS0xIGFsaWduPWNlbnRlciB3aWR0aD0iMTAwJSIgU0laRT0yPg0KICA8L1NQQU4+PC9G T05UPjwvRElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PEZPTlQgZmFjZT1UYWhvbWEgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IFRhaG9tYSI+RnJvbTo8L1NQQU4+PC9GT05UPjwvQj48Rk9OVCANCiAgZmFj ZT1UYWhvbWEgc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBUYWhvbWEiPiBleHQgDQogIEJVU0kgSVRBTE8gW21haWx0bzpJdGFsby5CdXNpQGFsY2F0ZWwt bHVjZW50Lml0XSA8QlI+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U2Vu dDo8L1NQQU4+PC9CPiBXZWRuZXNkYXksIEFwcmlsIDI5LCAyMDA5IDE6NDMgDQogIEFNPEJSPjxC PjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+VG86PC9TUEFOPjwvQj4gU3ByZWNoZXIs IE51cml0IChOU04gLSANCiAgSUwvSG9kIEhhU2hhcm9uKTsgVklHT1VSRVVYIE1BUlRJTjxCUj48 Qj48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5DYzo8L1NQQU4+PC9CPiBNRUFE IHRlYW08QlI+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U3ViamVjdDo8 L1NQQU4+PC9CPiBSRTogW01wbHMtaW50ZXJvcF0gUXVlc3Rpb24gZm9yIA0KICBDbGFyaWZpY2F0 aW9uIG9uIHRoZSBNUExTLVRQIE9BTVJlcXVpcmVtZW50IA0KICBEcmFmdDwvU1BBTj48L0ZPTlQ+ PG86cD48L286cD48L1A+PC9ESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj5OdXJpdCw8L1NQQU4+PC9GT05U PjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+SSBoYXZlIHRoZSBzYW1lIA0KICBpbnRl cnByZXRhdGlvbiBhcyB5b3UgaGF2ZS48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQ QU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwv Rk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIg c2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0Nv dXJpZXIgTmV3JyI+SSB3b25kZXIgd2hldGhlciBub3QgdG8gDQogIHJlcGhyYXNlIHRoZSBwYXJh Z3JhcGggb24gdGhlIGJhc2lzIG9mIHdoYXQgeW91IHdyb3RlIA0KICBiZWxvdy48L1NQQU4+PC9G T05UPjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+SXRhbG88L1NQQU4+PC9GT05UPjxv OnA+PC9vOnA+PC9QPg0KICA8QkxPQ0tRVU9URSANCiAgc3R5bGU9IkJPUkRFUi1SSUdIVDogbWVk aXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBjbTsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IFBB RERJTkctTEVGVDogNHB0OyBQQURESU5HLUJPVFRPTTogMGNtOyBNQVJHSU46IDVwdCAwY20gNXB0 IDMuNzVwdDsgQk9SREVSLUxFRlQ6IGJsYWNrIDEuNXB0IHNvbGlkOyBQQURESU5HLVRPUDogMGNt OyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZSI+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgIHN0eWxlPSJGT05U LVNJWkU6IDEycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPERJ ViBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGNlbnRlciIgYWxpZ249Y2VudGVy PjxGT05UIA0KICAgIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIHN0eWxlPSJG T05ULVNJWkU6IDEycHQiPg0KICAgIDxIUiB0YWJJbmRleD0tMSBhbGlnbj1jZW50ZXIgd2lkdGg9 IjEwMCUiIFNJWkU9Mj4NCiAgICA8L1NQQU4+PC9GT05UPjwvRElWPg0KICAgIDxQIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMTJwdCI+PEI+PEZPTlQgZmFjZT1UYWhvbWEg DQogICAgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogVGFob21hIj5Gcm9tOjwvU1BBTj48L0ZPTlQ+PC9CPjxG T05UIA0KICAgIGZhY2U9VGFob21hIHNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogVGFob21hIj4gDQogICAgbXBscy1pbnRlcm9wLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptcGxzLWludGVyb3AtYm91bmNlc0BpZXRmLm9yZ10gDQogICAgPEI+PFNQQU4g c3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5PbiBCZWhhbGYgT2YgPC9TUEFOPjwvQj5TcHJlY2hl ciwgTnVyaXQgDQogICAgKE5TTiAtIElML0hvZCBIYVNoYXJvbik8QlI+PEI+PFNQQU4gDQogICAg c3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TZW50OjwvU1BBTj48L0I+IFR1ZXNkYXksIEFwcmls IDI4LCAyMDA5IDY6NTkgDQogICAgUE08QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBi b2xkIj5Ubzo8L1NQQU4+PC9CPiBWSUdPVVJFVVggDQogICAgTUFSVElOPEJSPjxCPjxTUEFOIHN0 eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+Q2M6PC9TUEFOPjwvQj4gTUVBRCANCiAgICB0ZWFtPEJS PjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U3ViamVjdDo8L1NQQU4+PC9CPiAN CiAgICBbTXBscy1pbnRlcm9wXSBRdWVzdGlvbiBmb3IgQ2xhcmlmaWNhdGlvbiBvbiB0aGUgTVBM Uy1UUCBPQU1SZXF1aXJlbWVudCANCiAgICBEcmFmdDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48 L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFO IA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+TWFydGlu LDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBBcmlhbCI+SSBoYXZlIGEgcXVlc3Rpb24gZm9yIA0KICAgIGNsYXJpZmlj YXRpb24gb24gc2VjdGlvbiAyLjEuMi48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAg IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPkluIHRoZSBmaXJzdCBi dWxsZXQgaXQgaXMgDQogICAgd3JpdHRlbiB0aGF0ICJJbiBzb21lIGVudmlyb25tZW50c4VJUCBy b3V0aW5nIGFuZCBmb3J3YXJkaW5nIGNhcGFiaWxpdGllcyANCiAgICBhcmUgaW5oZXJlbnRseSBw cmVzZW50LiBJbiB0aGlzIGNhc2UsIHRoZSBPQU0gZnVuY3Rpb25hbGl0eSBNVVNUIHN1cHBvcnQg dGhlIA0KICAgIHVzZSBvZiBJUCByb3V0aW5nIGFuZCBmb3J3YXJkaW5nIGNhcGFiaWxpdGllcy4i IA0KPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5JIGd1ZXNzIHRoYXQgTVVTVCBtZWFucyB0aGF0IHRoZSAN CiAgICBwcm90b2NvbCBNVVNUIHN1cHBvcnQgT0FNIG1lY2hhbmlzbXMgYmFzZWQgb24gSVAgZnVu Y3Rpb25hbGl0eSB0byBiZSBhYmxlIHRvIA0KICAgIHJ1biBpdCBpbiB0aGlzIGVudmlyb25tZW50 LCBidXQgZG8gbm90IHJlcXVpcmUgdGhhdCB0aGlzIHdpbGwgYmUgbmVjZXNzYXJpbHkgDQogICAg dGhlIGltcGxlbWVudGF0aW9uIGluIHRoaXMgZW52aXJvbm1lbnQuIFJpZ2h0PyBXZSBjYW4gc3Rp bGwgbWF5IHNlbGVjdCB0byANCiAgICB1c2UgT0FNIG1lY2hhbmlzbXMgaW4gdGhpcyBlbnZpcm9u bWVudCB0aGF0IGFyZSBub3QgYmFzZWQgb24gSVAgDQogICAgZnVuY3Rpb25hbGl0eS4gUmlnaHQ/ IEl0IGlzIGp1c3QgdGhhdCB0aGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IA0KICAgIGl0LjxvOnA+ PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBBcmlhbCI+SSdsbCBhcHByZWNpYXRlIGlmIHlvdSBjYW4gDQogICAgY29uZmlybSBp dCBvciBjbGFyaWZ5IHRoZSBpbnRlbnRpb24uPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4N CiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQog ICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5UaGFua3MgYW5k IGJlc3QgDQogICAgcmVnYXJkcyw8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPk51cml0LjxvOnA+PC9vOnA+ PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BB Tj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPXNlY3Rpb24xIHN0eWxlPSJNQVJHSU46IDBjbSAw Y20gMHB0Ij48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tJm5ic3A7PEJSPkJlc3QgDQogICAgcmVnYXJkcywgPG86cD48L286cD48 L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1zZWN0aW9uMSBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDBwdCI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5OdXJpdCANCiAgICBTcHJlY2hlcjwv U1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogICAgPFAgY2xhc3M9c2VjdGlvbjEgc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAg IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7PG86cD48 L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1zZWN0aW9uMSBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdCI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5Ob2tpYSBTaWVtZW5zIE5l dHdvcmtzIEdtYkggDQogICAgJmFtcDsgQ28uIEtHJm5ic3A7PEJSPkluZHVzdHJ5IEVudmlyb25t ZW50PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1zZWN0aW9uMSBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4g DQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5TZW5pb3Ig U3BlY2lhbGlzdCwgQ2FycmllciANCiAgICBFdGhlcm5ldCBUcmFuc3BvcnQ8bzpwPjwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPXNlY3Rpb24xIHN0eWxlPSJNQVJHSU46IDBj bSAwY20gMHB0Ij48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjMgSGFuYWdhciA8VTE6UExBQ0UgDQog ICAgdTI6c3Q9Im9uIj48VTM6UExBQ0UgdTQ6c3Q9Im9uIj48c3QxOnBsYWNlIA0KICAgIHc6c3Q9 Im9uIj5TdC48L1UzOlBMQUNFPjwvVTE6UExBQ0U+PC9zdDE6cGxhY2U+IE5ldmUgTmUnZW1hbiAN CiAgICBCPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1zZWN0aW9u MSBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQ QU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj40NTI0 MSBIb2QgPFUxOlBMQUNFIA0KICAgIHUyOnN0PSJvbiI+PFUxOkNJVFkgdTI6c3Q9Im9uIj48c3Qx OnBsYWNlIHc6c3Q9Im9uIj48c3QxOkNpdHkgdzpzdD0ib24iIA0KICAgIHU1X3gwMDNhX3N0PSJv biI+SGFzaGFyb248L1UxOkNJVFk+PC9zdDE6Q2l0eT4sIDxVMTpDT1VOVFJZLVJFR0lPTiANCiAg ICB1MjpzdD0ib24iPjxzdDE6Y291bnRyeS1yZWdpb24gdzpzdD0ib24iIA0KICAgIHU2X3gwMDNh X3N0PSJvbiI+SXNyYWVsPC9VMTpDT1VOVFJZLVJFR0lPTj48L1UxOlBMQUNFPjwvc3QxOmNvdW50 cnktcmVnaW9uPjwvc3QxOnBsYWNlPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAg PFAgY2xhc3M9c2VjdGlvbjEgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiBBcmlhbCI+PEJSPlRlbC4gKzk3MiA5IA0KICAgIDc3NTEyMjk8bzpwPjwvbzpwPjwvU1BB Tj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPXNlY3Rpb24xIA0KICAgIHN0eWxlPSJNQVJHSU4t Qk9UVE9NOiAxMnB0OyBNQVJHSU4tTEVGVDogMGNtOyBNQVJHSU4tUklHSFQ6IDBjbTsgbXNvLW1h cmdpbi10b3AtYWx0OiAwY20iPjxGT05UIA0KICAgIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGxh bmc9RlIgDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5N b2JpbGUgKzk3MiA1NCANCiAgICAyMjAwOTU0Jm5ic3A7PEJSPkVtYWlsOiZuYnNwOzwvU1BBTj48 L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48QSANCiAgICB0aXRsZT0iYmxvY2tlZDo6bWFp bHRvOm51cml0LnNwcmVjaGVyQG5zbi5jb20mIzEwO21haWx0bzpudXJpdC5zcHJlY2hlckBuc24u Y29tIiANCiAgICBocmVmPSJibG9ja2VkOjptYWlsdG86bnVyaXQuc3ByZWNoZXJAbnNuLmNvbSI+ PFNQQU4gDQogICAgbGFuZz1GUj5udXJpdC5zcHJlY2hlckBuc24uY29tPC9TUEFOPjwvQT48L1NQ QU4+PC9GT05UPjxTUEFOIA0KICAgIGxhbmc9RlI+PG86cD48L286cD48L1NQQU4+PC9QPg0KICAg IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48 U1BBTiBsYW5nPUZSIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPjwvRElWPg0KICA8UD4NCiAgPEhSPg0K DQogIDxQPjwvUD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxCUj5NcGxzLWludGVyb3AgbWFpbGluZyANCiAgbGlzdDxCUj5NcGxzLWludGVyb3BAaWV0Zi5v cmc8QlI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLWludGVyb3A8 QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_hg2JzpqALdnpZCOl4kfb1w)-- From hklam@alcatel-lucent.com Mon May 4 22:49:56 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9D63A6A8D for ; Mon, 4 May 2009 22:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCXNFhLaw-kC for ; Mon, 4 May 2009 22:49:46 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 9F0693A6881 for ; Mon, 4 May 2009 22:49:45 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n455p7gm012040; Tue, 5 May 2009 00:51:07 -0500 (CDT) Received: from ILEXC2U03.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 00:51:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C9CD45.7B7F391A" Date: Tue, 5 May 2009 00:51:05 -0500 Message-ID: In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock andnotificationof lock Thread-Index: AcnMibd+2qVOSWcIR5GzbLZ+V24I5QAANxMQAAp1z8AAIYmmcA== References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net> <0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> From: "Lam, Hing-Kam \(Kam\)" To: "Malcolm Betts" , "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , , , "Martin Vigoureux" X-OriginalArrivalTime: 05 May 2009 05:51:07.0198 (UTC) FILETIME=[7BE78DE0:01C9CD45] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock andnotificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 05:49:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CD45.7B7F391A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9CD45.7B7F391A" ------_=_NextPart_002_01C9CD45.7B7F391A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 See inline below. I am addressing the issue of notification across layers, not addressing notifying the sink (egress) points. =20 Regards, Kam =20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] > On Behalf Of Malcolm Betts > Sent: Monday, May 04, 2009 8:42 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; mpls- > interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock > andnotificationof lock >=20 > All, >=20 > I think you are making this far too complicated... I see no need to > propagate the locked indication across layers. [Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected interruption to the client services so that to reduce unnecessary alarm being raised from the client layer. >=20 > If the operator decides to lock a LSP (for example to run a test) then > the clients of that LSP should be taken out of service before the lock > is applied. [Lam, Hing-Kam (Kam)] This is a reasonable assumption and a good practice. It will be helpful to explicitly say so in the document. The reason is that now we are using the "LOCKED" state and "Lock" event of the X.731 Administrative state model. There are additional state values and events in the model. We need to be precise and accurate, in particular if we support only a subset of the model. Otherwise it may cause unnecessary confusion and inconsistence in the future. The Administrative State model in X.731 defines three state values (namely: UNLOCKED, LOCKED, and SHUTTING DOWN) and events as shown below.=20 =20 If you administratively lock a server, the server will enter the "locked" state. Therefore the server will no longer be able to provide its intended service (of supporting all its clients). The effect (i.e. impact) on the clients is no different than a server failure. Usually you don't want to do this. Instead, you would like to gracefully take the server out of service, i.e. administratively shut down the server, and by doing so the server will enter the "shutting down" state. The "shutting down" state is a transition state. When the last user (in this case the last client service) quit, then the server will automatically enter the "locked" state. If we are not going to support the Shutting Down state of the model, then you better either (1) take the clients of the server LSP out of service before the lock is applied or (2) notify the clients in advance, otherwise alarms will be raised against the supported client services because of the unexpected interruption. =20 >=20 > When a server LSP detects the locked notification it informs the client > adaptation that it is no longer receiving valid traffic. If the client > has already been taken out of service then this is a "don't care". If > the client has not been taken out of service then it should raise an > alarm. >=20 >=20 > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com >=20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > - IL/Hod HaSharon) > Sent: Monday, May 04, 2009 3:47 AM > To: hhelvoort@chello.nl; mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and > notificationof lock >=20 > Huub, > You say " this requires that a MIP has the capability to send OAM > messages based on management command or based on an indication of a MEP > in a different layer. This also requires that at every MEP location > there are also MIPs for every client entity serviced by that MEP." > This looks more as an implementation description. What is actually > required is that the endpoints of the client layer are informed of this > event. > The way you describe it seems a little bit "against" the framework in > which it is specified that OAM messages cannot be initiated by MIPs. > That is why we actually say that this is an adaptation function, that > means that the message is initiated by the MEP of the server to the MEP > of the client....... > Best regards, > NUrit >=20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Huub van > Helvoort > Sent: Monday, May 04, 2009 10:27 AM > To: mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and > notification of lock >=20 > Hello Nurit, >=20 > You wrote: >=20 > > To continue with the othe rquestion: > > > >> See also my e-mail: > >> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" >=20 > >> OAM messages ? > > > > The answer was no. > > > >> -question: > >> More generally to the comment above, who should notify and who should >=20 > >> notify whom? > >> I would tend to say: > >> the receiving node of a locked direction, informs downstream > receiving > >> nodes of nested LSPs. > > > > To be more exact, the sink side of a locked LSP, PW, Section, has to > > inform its clients. >=20 > You say " To be more exact, the sink side of a locked LSP, PW, Section, > has to inform its clients.", >=20 > [hvh] it should inform its client transport entities in the > server/client relation >=20 > BUT the client is not necessarily an > endpoint but may be an intermediate point, and it needs to notify its > endpoints, that means that a MIP generates an OAM message. >=20 > [hvh this requires that a MIP has the capability to send OAM messages > based on management command or based on an indication of a MEP in a > different layer. > This also requires that at every MEP location there are also MIPs for > every client entity serviced by that MEP. >=20 > Long ago I discussed this point with Italo and he indicated to me that > it is not a generation of a message by a MIP BUT it is a variation of an > adaptation function at the client intermediate point. Although we are > talking here about a way to implement it, this is a conceptual issue > that we need to agree on. >=20 > [hvh] I agree with Italo. >=20 > Also, I think we should generalize the discussion instead of talking > every time about LSP, PW, section, etc. we should really talk about > client/server layers to cover cases of LSP hierarchies, etc. >=20 > [hvh] then I use server/client path/trail the next time, OK? >=20 > Regards, Huub. >=20 > >> This is a Fowrward Indication and if we do so then receiving points > >> MUST indeed be informed of a Lock (c.f. > >> discussion at the beginning of the e-mail). > >> Should source points (locking points) do some reverse indication and > >> notify the source points of the LSPs that are nested in the locked > > LSP? > >> (but this maybe falls in the RDI functionality). > > > > Isn't this notification already caused by the locking at the far end? > > Or is the locking only applied in one direction of a bi-directional > > path? If yes, then the notification is not required. > > > > Cheers, Huub. > > >=20 > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_002_01C9CD45.7B7F391A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = all,

 =

See inline = below. I am addressing the issue of notification across layers, not addressing = notifying the sink (egress) points.

 =

Regards,

Kam

 

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

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

> On Behalf Of Malcolm Betts

> Sent: Monday, May 04, 2009 8:42 AM

> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); = hhelvoort@chello.nl; mpls-

> interop@ietf.org

> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - = Lock

> andnotificationof lock

>

> All,

>

> I think you are making this far too complicated...  I = see no need to

> propagate the locked indication across = layers.

[Lam, Hing-Kam (Kam)] The bottom line is to = avoid unexpected interruption to the client services so that to reduce = unnecessary alarm being raised from the client layer.

>

> If the operator decides to lock a LSP (for example to run a = test) then

> the clients of that LSP should be taken out of service = before the lock

> is applied.

[Lam, Hing-Kam (Kam)] This is a reasonable = assumption and a good practice. It will be helpful to explicitly say so in the = document. The reason is that now we are using the “LOCKED” state and = “Lock” event of the X.731 Administrative state model. There are additional = state values and events in the model. We need to be precise and accurate, in particular if we support only a subset of the model. Otherwise it may = cause unnecessary confusion and inconsistence in the future. The Administrative State model in X.731 defines three state values (namely: UNLOCKED, LOCKED, and = SHUTTING DOWN) and events as shown below.

If you administratively lock a server, the server will enter the = "locked" state. Therefore the server will no longer be able to provide its = intended service (of supporting all its clients). The effect (i.e. impact) on the clients is no different than a server failure. Usually you don't want to = do this. Instead, you would like to gracefully take the server out of = service, i.e. administratively shut down the server, and by doing so the server = will enter the "shutting down" state. The "shutting down" = state is a transition state. When the last user (in this case the last client = service) quit, then the server will automatically enter the "locked" = state. If we are not going to support the Shutting Down state of the model, then = you better either (1) take the clients of the server LSP out of service = before the lock is applied or (2) notify the clients in advance, otherwise alarms = will be raised against the supported client services because of the unexpected interruption.

 

>

> When a server LSP detects the locked notification it = informs the client

> adaptation that it is no longer receiving valid = traffic.  If the client

> has already been taken out of service then this is a = "don't care".  If

> the client has not been taken out of service then it should = raise an

> alarm.

>

>

> Malcolm Betts

> Nortel Networks

> Phone: +1 613 763 7860 (ESN 393)

> email: betts01@nortel.com

>

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

> From: mpls-interop-bounces@ietf.org

> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of = Sprecher, Nurit (NSN

> - IL/Hod HaSharon)

> Sent: Monday, May 04, 2009 3:47 AM

> To: hhelvoort@chello.nl; = mpls-interop@ietf.org

> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock = and

> notificationof lock

>

> Huub,

> You say " this requires that a MIP has the capability = to send OAM

> messages based on management command or based on an = indication of a MEP

> in a different layer. This also requires that at every MEP location

> there are also MIPs for every client entity serviced by = that MEP."

> This looks more as an implementation description. What is = actually

> required is that the endpoints of the client layer are = informed of this

> event.

> The way you describe it seems a little bit = "against" the framework in

> which it is specified that OAM messages cannot be initiated = by MIPs.

> That is why we actually say that this is an adaptation = function, that

> means that the message is initiated by the MEP of the = server to the MEP

> of the client.......

> Best regards,

> NUrit

>

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

> From: mpls-interop-bounces@ietf.org

> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext = Huub van

> Helvoort

> Sent: Monday, May 04, 2009 10:27 AM

> To: mpls-interop@ietf.org

> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock = and

> notification of lock

>

> Hello Nurit,

>

> You wrote:

>

> > To continue with the othe rquestion:

> >

> >> See also my e-mail:

> >> MPLS-TP OAM requirements - AIS/LockNotif - Can = MIPs send "usolicited"

>

> >> OAM messages ?

> >

> > The answer was no.

> >

> >> -question:

> >> More generally to the comment above, who should = notify and who should

>

> >> notify whom?

> >> I would tend to say:

> >> the receiving node of a locked direction, informs downstream

> receiving

> >> nodes of nested LSPs.

> >

> > To be more exact, the sink side of a locked LSP, PW, = Section, has to

> > inform its clients.

>

> You say " To be more exact, the sink side of a locked = LSP, PW, Section,

> has to inform its clients.",

>

> [hvh] it should inform its client transport entities in = the

> server/client relation

>

> BUT the client is not necessarily an

> endpoint but may be an intermediate point, and it needs to = notify its

> endpoints, that means that a MIP generates an OAM = message.

>

> [hvh this requires that a MIP has the capability to send = OAM messages

> based on management command or based on an indication of a = MEP in a

> different layer.

> This also requires that at every MEP location there are = also MIPs for

> every client entity serviced by that MEP.

>

> Long ago I discussed this point with Italo and he indicated = to me that

> it is not a generation of a message by a MIP BUT it is a = variation of an

> adaptation function at the client intermediate point. = Although we are

> talking here about a way to implement it, this is a = conceptual issue

> that we need to agree on.

>

> [hvh] I agree with Italo.

>

> Also, I think we should generalize the discussion instead = of talking

> every time about LSP, PW, section, etc. we should really = talk about

> client/server layers to cover cases of LSP hierarchies, = etc.

>

> [hvh] then I use server/client path/trail the next time, = OK?

>

> Regards, Huub.

>

> >> This is a Fowrward Indication and if we do so then receiving points

> >> MUST indeed be informed of a Lock = (c.f.

> >> discussion at the beginning of the = e-mail).

> >> Should source points (locking points) do some = reverse indication and

> >> notify the source points of the LSPs that are = nested in the locked

> > LSP?

> >> (but this maybe falls in the RDI = functionality).

> >

> > Isn't this notification already caused by the locking = at the far end?

> > Or is the locking only applied in one direction of a bi-directional

> > path? If yes, then the notification is not = required.

> >

> > Cheers, 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=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> Always remember that you are unique...just like everyone = else...

> = _______________________________________________

> Mpls-interop mailing list

> Mpls-interop@ietf.org

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

> = _______________________________________________

> Mpls-interop mailing list

> Mpls-interop@ietf.org

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

> = _______________________________________________

> Mpls-interop mailing list

> Mpls-interop@ietf.org

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

------_=_NextPart_002_01C9CD45.7B7F391A-- ------_=_NextPart_001_01C9CD45.7B7F391A Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhBgG0AHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAAAB AbIAgAAAAAAAAAL/hI+py+0Po5y02hOu3rz7D4biFZTZiKbqyragabryTNe2BRvlzff+H4ohdsBi BIZMKpfMpvMJjUqdj1yCaMwyTtourmFVYL3eMfm85Q6FaXTZDd9eze24kW4/75ISfN7m99fFNxEo KGN4CERYqKZY4/g4CMDWFynpkvjBdcKps4Zl1UlJFJZ5aek5gqrIKqJa+in7GZkxioE741oVurIb p+kBS0lcbExcW6ymerrB1gk9dIwkuxeM9ruZa6ucSyvGGTub6dw7rLOMcduNSUpejT6bnrxunL15 v/BcvS8dbz/u0TUO58RNO/btYEAW+cAx43Yl4r9zmAYS7MUPWigh/6M4VmrxsRGpaOiYqWNkslU7 MqYsBVnJC2aWUhYtVpEJBufMk/ds6sTR8CcKOiHBCfV19MellnOSpvDpVJirou6ivgpqVRgvoliz gunqlUTPMVDDijGrqxFNtB32IHvLLS7cuXLr0r1rNy/evXr7YqXGttyUwYQLGz78RGzZwP5ENtMA FsJixk9rRqZQlmrby5SvWkYEVvPFzndEG31cgSk+0jsxc3YJWcVk1i9dg3Ym+zVtrbZRf6m8e1Fq 3ZIjEz8dvEfQ2bBJ5B55PPmR4bdjV055VvoL6r5T5w43zLT2I8ujf4VsXp27W+zHa+sN0vjzifAQ uncOn6F84PTZpf/fXV51+A2VA3v93GedY/Hhxh+CiHC3YIKr/OegPhDqxyCBFT6Yny/7abghhh3O B9R8FKKFnX3ykCeghQtp8lc9IbqoIiopIieiHC/+EmMM4nTEXFKeHLgRRFOduIYDQ671z0jssFhV R/65N2R9QOKyS5DFKYklLe3N09uPbz0pXZVTIgNeTN1JNKYtX4IS5pvtjWfmnG52qSSS6uWU0J3d gKmWNdJQpB1H9VXlpIxNrTnHl+GcRKaaMzbYXI4XXjUpUiNS6h2nmdamoKWdgvjpKpeS+BuppYJa qYcZTriqqZuqOiqsFckUIKN9XKfndzDlGuGAnrWi2iE2aSnpqS//9BqER78qSytmmgJTCbMgQWtr Kohty20UqeAoCbCixtQXX+aWi+65d+Xph7UMYYtpqE6xUmyTt86aLZRWLSWeu9O2iuqWWa0lnr3h wtssvjqB15C/nibrqrxCliTuwQonLPFRdkn77MXLevzrZcgqd1OSbGJcqY94KsNEQvZU+4yhK77Y FkCy/kujwSpuBl86Lvs8jp+KrgjoyzRfdON7Q5VcUtNDo9dzYxApFPRcO5sJT1xynewcLCS5DJ2B Ti7NpZcHRffZntSYBPS6XwPkc11bm4we1uuQpfY2sjF95zIjpz3oym0DahDQU/+Jps6cTW0gRt4U vtBqZSdetOQA/zNuc9V4Qv441XXSE5rjhwf0qM0UZkmTRpGOpqDMLDsyeOamhDG74GcVnJ2zTe+I kjevIPxxxkKlDnwhPFQcMMQTw7krqzQg//B5A+vTr8NkC5+vwPt+lSWuxRfXbsPWA3Jk+B1jb3zk 6wGsMXlLhfz95P0Apnz72tJ9L/oi2Tm69Nu7ljRBQA9q/ulfGtyEwERZI4E+WqACGejABkJwgmMD IO7cMECxWMmAB+yWBz9YL/B5D2RbKaDr0hctAY5Qf8ETVrxitR0S8kxCL4Qhb1houVRlz4YExGF2 5MU4fiWPhy7UHseA2Jic3XBkscog9ZjUOD+ZTTNo29MPiSiZ+P/V6RtGwtvqkrjEjVTwSUwaU4ic yCYjcfF1/nia+hLklradqYCZQqPUprS1ah1KiTWj2Mz0lhE33seOoHibGsc4Jx3FcH17JNPoxpc/ 9tEqH2hboBSnobuxQVIghJQK1yxkCONsMjmdnCHHplIOLPbRh6ZM3yVFUSJVvkpf4wIjPw7FwfrJ snmsZJ0i25jIC+Ivi7t8Yx3cN8y7CapPuQvmznTJNCyW0k5t9JLYePfKE7aqQFNkImmmaaVqUuyE 9ELVFr/YRHDO0ZFmkKMV83VOQZZKnaXjiR/JySdVxdOY84yfL/loyxbe03Wj/Ekp/3nFhKLsk8UM aJ5aVKsaOrT/oc88Zi15uUOKRpOWESuiQDVKzF6mkoYLBelDZYhQkaq0oQcdqUel4s1PtbSHOmxW TOvoT5fWdFkFBRAAIXrEjJoUoNzTUwg72FONiq9XRz3gUCEBwqhKdaqJUepE83nR6dzgpqzhKoCS aj+lgtWgY9VYWRdmUq92Rq1dPStO3LowuK6Erd+U61zTateK5HWue7WYUgrpRxNCpzQUpSvfhmnG hxTBsIHpKdvo0Tl+AlWajvUdV+AUQF30VSCLtSxk/+jYzRqrskH7rOwWK1pjoVYjrN0gApPKWBSl llhWBWlszXJbtuQ2LLMdbWF7K0Dg2kG4edjtwOKornQpN7nM/12uc89FXDhQdbrUpepTr4vd7Gp3 u9ztrne/C97wine85C2vec+L3vSqd73sba970atNmtqLYV/zIkNRqdCIsusl0dXq9dbpuzbprEZK wypGr4bC/0XJLXALhOFsdDLsBNGSBINiAtFEPAYnLokS3B0e+BAzIKVOmFCVkoA9nDO/KTF2Ebnb mQ55uHqScY0IcVw4a7yyE+MtkZPY3IyL9Vg+su12RAsnNUHLOa19WB4/+sjnYAwpHmshbs7snkKS IRHYNUrDUNYxIF+st1yCGZ1VuiYeG9kaa752G5f944nVdqCZcfPMf4pbYGe8uzxj2Gu1UFmBZDZn ebLkvTt9qwdxbXtoERQAADs= ------_=_NextPart_001_01C9CD45.7B7F391A-- From annamaria.fulignoli@ericsson.com Tue May 5 02:43:00 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22833A68AE for ; Tue, 5 May 2009 02:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.071 X-Spam-Level: X-Spam-Status: No, score=-4.071 tagged_above=-999 required=5 tests=[AWL=-1.909, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, SARE_HTML_SINGLETS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Q4gd9AtvvJy for ; Tue, 5 May 2009 02:42:58 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CE0943A6BBB for ; Tue, 5 May 2009 02:42:57 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-50-4a000a76cfc0 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 1D.F2.19078.67A000A4; Tue, 5 May 2009 11:44:22 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 11:44:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C9CD66.113DEE1E" Date: Tue, 5 May 2009 11:44:20 +0200 Message-ID: <93DFCD4B101EB440B5B72997456C5F9403ACC0BB@esealmw118.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock Thread-Index: AcnMibd+2qVOSWcIR5GzbLZ+V24I5QAANxMQAAp1z8AAIYmmcAAKo4iw References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> From: "Annamaria Fulignoli" To: "Lam, Hing-Kam (Kam)" , "Malcolm Betts" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , , , "Martin Vigoureux" X-OriginalArrivalTime: 05 May 2009 09:44:22.0080 (UTC) FILETIME=[11811400:01C9CD66] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 09:43:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CD66.113DEE1E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9CD66.113DEE1E" ------_=_NextPart_002_01C9CD66.113DEE1E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lam, I agree with you. Besides, as many mails were sent on this issue, I'd like to check with = all of us where we are with Lock (2.2.x) and Lock Notification(2.2.y) = requirements.=20 I know we are dealing with requirements and not with solutions, but = please let's consider the following example: topology is A <---> B <---> C <---> D=20 LSP1 goes A-B-C-D - The operator decides to set in A LSP1 administratevly down , due for = example to an out of service test on the path.=20 The Lock requirement (2.2.x ) requires that A is able to set its peer = MEP D in administratevly lock state. As Lam reported , we are using the = "LOCKED" state and "Lock" event of the X.731 Administrative state model. = This implies that when LSP1 in D enters in the administrative lock = state, all traffic on the path MUST be blocked; but MEP D must notify = the clients , otherwise alarms will be raised against the supported = client services because of the unexpected interruption; i.e. D should = send Lock Notification(2.2.y) to its own clients. - In case of bidirectional path even in MEP A the LSP1 (rx direction ) = enters in administrative lock state and even MEP A should notify the = client(s) transported by the path ( i.e. In the backward direction; req. = 2.2.y) - My understanding is that the client to which the Lock Notification is = sent are always MEPs as MIP are transparent to Lock and Lock = Notification=20 - When a MEP receives a Lock Notification it can in turn notify its = MPLS-TP client MEPs or map it into an equivalent signal for whatever = client layer is then being carried. - Lock Notification functionality (req 2.2.y ) applies to all scenarios = where server enters the "locked" state ; for instance if a port in LSR B = is set administratevly down (" Lock" event of the X.731 Administrative = state model) LSR B, as Server MEP of paths transimitted and received on = the port , should generate Lock Notification on all these paths, for = example towards D and A , MEPs of LSP1.=20 Are we all agree on these ? Best regards, Annamaria=20 ________________________________ From: mpls-interop-bounces@ietf.org = [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam) Sent: marted=EC 5 maggio 2009 7.51 To: Malcolm Betts; Sprecher, Nurit (NSN - IL/Hod HaSharon); = hhelvoort@chello.nl; mpls-interop@ietf.org; Martin Vigoureux Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - = Lockandnotificationof lock Dear all, =20 See inline below. I am addressing the issue of notification across = layers, not addressing notifying the sink (egress) points. =20 Regards, Kam =20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org = [mailto:mpls-interop-bounces@ietf.org] > On Behalf Of Malcolm Betts > Sent: Monday, May 04, 2009 8:42 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; = mpls- > interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock > andnotificationof lock >=20 > All, >=20 > I think you are making this far too complicated... I see no need to > propagate the locked indication across layers. [Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected = interruption to the client services so that to reduce unnecessary alarm = being raised from the client layer. >=20 > If the operator decides to lock a LSP (for example to run a test) then > the clients of that LSP should be taken out of service before the lock > is applied. [Lam, Hing-Kam (Kam)] This is a reasonable assumption and a good = practice. It will be helpful to explicitly say so in the document. The = reason is that now we are using the "LOCKED" state and "Lock" event of = the X.731 Administrative state model. There are additional state values = and events in the model. We need to be precise and accurate, in = particular if we support only a subset of the model. Otherwise it may = cause unnecessary confusion and inconsistence in the future. The = Administrative State model in X.731 defines three state values (namely: = UNLOCKED, LOCKED, and SHUTTING DOWN) and events as shown below.=20 =20 If you administratively lock a server, the server will enter the = "locked" state. Therefore the server will no longer be able to provide = its intended service (of supporting all its clients). The effect (i.e. = impact) on the clients is no different than a server failure. Usually = you don't want to do this. Instead, you would like to gracefully take = the server out of service, i.e. administratively shut down the server, = and by doing so the server will enter the "shutting down" state. The = "shutting down" state is a transition state. When the last user (in this = case the last client service) quit, then the server will automatically = enter the "locked" state. If we are not going to support the Shutting = Down state of the model, then you better either (1) take the clients of = the server LSP out of service before the lock is applied or (2) notify = the clients in advance, otherwise alarms will be raised against the = supported client services because of the unexpected interruption. =20 >=20 > When a server LSP detects the locked notification it informs the = client > adaptation that it is no longer receiving valid traffic. If the = client > has already been taken out of service then this is a "don't care". If > the client has not been taken out of service then it should raise an > alarm. >=20 >=20 > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com >=20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Sprecher, Nurit = (NSN > - IL/Hod HaSharon) > Sent: Monday, May 04, 2009 3:47 AM > To: hhelvoort@chello.nl; mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and > notificationof lock >=20 > Huub, > You say " this requires that a MIP has the capability to send OAM > messages based on management command or based on an indication of a = MEP > in a different layer. This also requires that at every MEP location > there are also MIPs for every client entity serviced by that MEP." > This looks more as an implementation description. What is actually > required is that the endpoints of the client layer are informed of = this > event. > The way you describe it seems a little bit "against" the framework in > which it is specified that OAM messages cannot be initiated by MIPs. > That is why we actually say that this is an adaptation function, that > means that the message is initiated by the MEP of the server to the = MEP > of the client....... > Best regards, > NUrit >=20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Huub van > Helvoort > Sent: Monday, May 04, 2009 10:27 AM > To: mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and > notification of lock >=20 > Hello Nurit, >=20 > You wrote: >=20 > > To continue with the othe rquestion: > > > >> See also my e-mail: > >> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send = "usolicited" >=20 > >> OAM messages ? > > > > The answer was no. > > > >> -question: > >> More generally to the comment above, who should notify and who = should >=20 > >> notify whom? > >> I would tend to say: > >> the receiving node of a locked direction, informs downstream > receiving > >> nodes of nested LSPs. > > > > To be more exact, the sink side of a locked LSP, PW, Section, has to > > inform its clients. >=20 > You say " To be more exact, the sink side of a locked LSP, PW, = Section, > has to inform its clients.", >=20 > [hvh] it should inform its client transport entities in the > server/client relation >=20 > BUT the client is not necessarily an > endpoint but may be an intermediate point, and it needs to notify its > endpoints, that means that a MIP generates an OAM message. >=20 > [hvh this requires that a MIP has the capability to send OAM messages > based on management command or based on an indication of a MEP in a > different layer. > This also requires that at every MEP location there are also MIPs for > every client entity serviced by that MEP. >=20 > Long ago I discussed this point with Italo and he indicated to me that > it is not a generation of a message by a MIP BUT it is a variation of = an > adaptation function at the client intermediate point. Although we are > talking here about a way to implement it, this is a conceptual issue > that we need to agree on. >=20 > [hvh] I agree with Italo. >=20 > Also, I think we should generalize the discussion instead of talking > every time about LSP, PW, section, etc. we should really talk about > client/server layers to cover cases of LSP hierarchies, etc. >=20 > [hvh] then I use server/client path/trail the next time, OK? >=20 > Regards, Huub. >=20 > >> This is a Fowrward Indication and if we do so then receiving points > >> MUST indeed be informed of a Lock (c.f. > >> discussion at the beginning of the e-mail). > >> Should source points (locking points) do some reverse indication = and > >> notify the source points of the LSPs that are nested in the locked > > LSP? > >> (but this maybe falls in the RDI functionality). > > > > Isn't this notification already caused by the locking at the far = end? > > Or is the locking only applied in one direction of a bi-directional > > path? If yes, then the notification is not required. > > > > Cheers, Huub. > > >=20 > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_002_01C9CD66.113DEE1E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Lam,

I agree with you.

Besides, as many mails were sent on this issue,  I'd like to check with all of = us where=20 we are with Lock (2.2.x) and Lock Notification(2.2.y) requirements. =

I know we are dealing with requirements and not with = solutions,=20 but please let's consider the following example:

topology is A <---> B <---> C <---> = D=20

LSP1 goes A-B-C-D

- The operator decides to set in A LSP1 = administratevly down ,=20 due for example to an out of service test on the path.

The Lock requirement (2.2.x ) requires that A is able = to set its=20 peer MEP D in administratevly lock state. As Lam reported , we are using the "LOCKED" state and = "Lock"=20 event of the X.731 Administrative state model. This implies that when = LSP1 in D=20 enters in the administrative lock state, all traffic on the path MUST be = blocked; but MEP D must notify the clients , otherwise alarms will be = raised=20 against the supported client services because of the unexpected=20 interruption; i.e. D should send = Lock=20 Notification(2.2.y) to its own clients.

- In case of bidirectional path even in MEP A the LSP1 = (rx=20 direction ) enters in administrative lock state and even MEP A should = notify the=20 client(s) transported by the path ( i.e. In the backward direction; req. = 2.2.y)

- My understanding is that the client to which the = Lock=20 Notification is sent are always MEPs as MIP are transparent to Lock and = Lock=20 Notification

- When a MEP receives a Lock Notification it can in = turn=20 notify  its MPLS-TP client MEPs or map it into an equivalent signal = for=20 whatever client layer is then being carried.

- Lock Notification functionality (req 2.2.y ) applies = to all=20 scenarios where server enters = the "locked"=20 state ; for instance if a port in LSR B is set administratevly down (" = Lock"=20 event of the X.731 Administrative state model) LSR B, as Server MEP of = paths=20 transimitted and received on the port , should generate Lock = Notification=20 on all these paths, for example = towards D=20 and A , MEPs of LSP1.

Are we all agree on these ?

Best = regards,

Annamaria


From: mpls-interop-bounces@ietf.org=20 [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Lam, Hing-Kam = (Kam)
Sent: marted=EC 5 maggio 2009 7.51
To: Malcolm = Betts;=20 Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;=20 mpls-interop@ietf.org; Martin Vigoureux
Subject: Re: = [Mpls-interop]=20 MPLS-TP OAM requirements - Lockandnotificationof = lock

Dear=20 all,

 

See = inline below.=20 I am addressing the issue of notification across layers, not addressing=20 notifying the sink (egress) points.

 

Regards,

Kam

 

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

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

> On Behalf Of Malcolm = Betts

> Sent: Monday, May 04, 2009 8:42=20 AM

> To: Sprecher, Nurit (NSN - IL/Hod = HaSharon);=20 hhelvoort@chello.nl; mpls-

> interop@ietf.org

> Subject: Re: [Mpls-interop] MPLS-TP OAM=20 requirements - Lock

> andnotificationof lock

>

> All,

>

> I think you are making this far too=20 complicated...  I see no need to

> propagate the locked indication across=20 layers.

[Lam, Hing-Kam (Kam)] The = bottom line is to=20 avoid unexpected interruption to the client services so that to reduce=20 unnecessary alarm being raised from the client = layer.

>

> If the operator decides to lock a LSP = (for example=20 to run a test) then

> the clients of that LSP should be taken = out of=20 service before the lock

> is applied.

[Lam, Hing-Kam (Kam)] This is a = reasonable=20 assumption and a good practice. It will be helpful to explicitly say so = in the=20 document. The reason is that now we are using the =93LOCKED=94 state and = =93Lock=94=20 event of the X.731 Administrative state model. There are additional = state values=20 and events in the model. We need to be precise and accurate, in = particular if we=20 support only a subset of the model. Otherwise it may cause unnecessary = confusion=20 and inconsistence in the future. The Administrative State model in X.731 defines = three state=20 values (namely: UNLOCKED, LOCKED, and SHUTTING DOWN) and events as shown = below.=20

If=20 you administratively lock a server, the server will enter the "locked" = state.=20 Therefore the server will no longer be able to provide its intended = service (of=20 supporting all its clients). The effect (i.e. impact) on the clients is = no=20 different than a server failure. Usually you don't want to do this. = Instead, you=20 would like to gracefully take the server out of service, i.e. = administratively=20 shut down the server, and by doing so the server will enter the = "shutting down"=20 state. The "shutting down" state is a transition state. When the last = user (in=20 this case the last client service) quit, then the server will = automatically=20 enter the "locked" state. If we are not going to support the Shutting = Down state=20 of the model, then you better either (1) take the clients of the server = LSP out=20 of service before the lock is applied or (2) notify the clients in = advance,=20 otherwise alarms will be raised against the supported client services = because of=20 the unexpected interruption.

 

>

> When a server LSP detects the locked = notification=20 it informs the client

> adaptation that it is no longer receiving = valid=20 traffic.  If the client

> has already been taken out of service = then this is=20 a "don't care".  If

> the client has not been taken out of = service then=20 it should raise an

> alarm.

>

>

> Malcolm Betts

> Nortel Networks

> Phone: +1 613 763 7860 (ESN = 393)

> email: = betts01@nortel.com

>

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

> From:=20 mpls-interop-bounces@ietf.org

> [mailto:mpls-interop-bounces@ietf.org] On = Behalf Of=20 Sprecher, Nurit (NSN

> - IL/Hod HaSharon)

> Sent: Monday, May 04, 2009 3:47=20 AM

> To: hhelvoort@chello.nl;=20 mpls-interop@ietf.org

> Subject: Re: [Mpls-interop] MPLS-TP OAM=20 requirements - Lock and

> notificationof lock

>

> Huub,

> You say " this requires that a MIP has = the=20 capability to send OAM

> messages based on management command or = based on an=20 indication of a MEP

> in a different layer. This also requires = that at=20 every MEP location

> there are also MIPs for every client = entity=20 serviced by that MEP."

> This looks more as an implementation = description.=20 What is actually

> required is that the endpoints of the = client layer=20 are informed of this

> event.

> The way you describe it seems a little = bit=20 "against" the framework in

> which it is specified that OAM messages = cannot be=20 initiated by MIPs.

> That is why we actually say that this is = an=20 adaptation function, that

> means that the message is initiated by = the MEP of=20 the server to the MEP

> of the client.......

> Best regards,

> NUrit

>

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

> From:=20 mpls-interop-bounces@ietf.org

> [mailto:mpls-interop-bounces@ietf.org] On = Behalf Of=20 ext Huub van

> Helvoort

> Sent: Monday, May 04, 2009 10:27=20 AM

> To: = mpls-interop@ietf.org

> Subject: Re: [Mpls-interop] MPLS-TP OAM=20 requirements - Lock and

> notification of lock

>

> Hello Nurit,

>

> You wrote:

>

> > To continue with the othe=20 rquestion:

> >

> >> See also my = e-mail:

> >> MPLS-TP OAM requirements - = AIS/LockNotif -=20 Can MIPs send "usolicited"

>

> >> OAM messages ?

> >

> > The answer was no.

> >

> >> -question:

> >> More generally to the comment = above, who=20 should notify and who should

>

> >> notify whom?

> >> I would tend to = say:

> >> the receiving node of a locked = direction,=20 informs downstream

> receiving

> >> nodes of nested = LSPs.

> >

> > To be more exact, the sink side of a = locked=20 LSP, PW, Section, has to

> > inform its = clients.

>

> You say " To be more exact, the sink side = of a=20 locked LSP, PW, Section,

> has to inform its = clients.",

>

> [hvh] it should inform its client = transport=20 entities in the

> server/client relation

>

> BUT the client is not necessarily=20 an

> endpoint but may be an intermediate = point, and it=20 needs to notify its

> endpoints, that means that a MIP = generates an OAM=20 message.

>

> [hvh this requires that a MIP has the = capability to=20 send OAM messages

> based on management command or based on = an=20 indication of a MEP in a

> different layer.

> This also requires that at every MEP = location there=20 are also MIPs for

> every client entity serviced by that=20 MEP.

>

> Long ago I discussed this point with = Italo and he=20 indicated to me that

> it is not a generation of a message by a = MIP BUT it=20 is a variation of an

> adaptation function at the client = intermediate=20 point. Although we are

> talking here about a way to implement it, = this is a=20 conceptual issue

> that we need to agree = on.

>

> [hvh] I agree with = Italo.

>

> Also, I think we should generalize the = discussion=20 instead of talking

> every time about LSP, PW, section, etc. = we should=20 really talk about

> client/server layers to cover cases of = LSP=20 hierarchies, etc.

>

> [hvh] then I use server/client path/trail = the next=20 time, OK?

>

> Regards, Huub.

>

> >> This is a Fowrward Indication = and if we do=20 so then receiving points

> >> MUST indeed be informed of a = Lock=20 (c.f.

> >> discussion at the beginning of = the=20 e-mail).

> >> Should source points (locking = points) do=20 some reverse indication and

> >> notify the source points of the = LSPs that=20 are nested in the locked

> > LSP?

> >> (but this maybe falls in the RDI = functionality).

> >

> > Isn't this notification already = caused by the=20 locking at the far end?

> > Or is the locking only applied in = one=20 direction of a bi-directional

> > path? If yes, then the notification = is not=20 required.

> >

> > Cheers, Huub.

> >

>

> --

>=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> Always remember that you are = unique...just like=20 everyone else...

>=20 _______________________________________________

> Mpls-interop mailing = list

> Mpls-interop@ietf.org

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

>=20 _______________________________________________

> Mpls-interop mailing = list

> Mpls-interop@ietf.org

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

>=20 _______________________________________________

> Mpls-interop mailing = list

> Mpls-interop@ietf.org

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

------_=_NextPart_002_01C9CD66.113DEE1E-- ------_=_NextPart_001_01C9CD66.113DEE1E Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: <474363709@05052009-362A> Content-Description: image001.gif Content-Location: image001.gif R0lGODlhBgG0AHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAAAB AbIAgAAAAAAAAAL/hI+py+0Po5y02hOu3rz7D4biFZTZiKbqyragabryTNe2BRvlzff+H4ohdsBi BIZMKpfMpvMJjUqdj1yCaMwyTtourmFVYL3eMfm85Q6FaXTZDd9eze24kW4/75ISfN7m99fFNxEo KGN4CERYqKZY4/g4CMDWFynpkvjBdcKps4Zl1UlJFJZ5aek5gqrIKqJa+in7GZkxioE741oVurIb p+kBS0lcbExcW6ymerrB1gk9dIwkuxeM9ruZa6ucSyvGGTub6dw7rLOMcduNSUpejT6bnrxunL15 v/BcvS8dbz/u0TUO58RNO/btYEAW+cAx43Yl4r9zmAYS7MUPWigh/6M4VmrxsRGpaOiYqWNkslU7 MqYsBVnJC2aWUhYtVpEJBufMk/ds6sTR8CcKOiHBCfV19MellnOSpvDpVJirou6ivgpqVRgvoliz gunqlUTPMVDDijGrqxFNtB32IHvLLS7cuXLr0r1rNy/evXr7YqXGttyUwYQLGz78RGzZwP5ENtMA FsJixk9rRqZQlmrby5SvWkYEVvPFzndEG31cgSk+0jsxc3YJWcVk1i9dg3Ym+zVtrbZRf6m8e1Fq 3ZIjEz8dvEfQ2bBJ5B55PPmR4bdjV055VvoL6r5T5w43zLT2I8ujf4VsXp27W+zHa+sN0vjzifAQ uncOn6F84PTZpf/fXV51+A2VA3v93GedY/Hhxh+CiHC3YIKr/OegPhDqxyCBFT6Yny/7abghhh3O B9R8FKKFnX3ykCeghQtp8lc9IbqoIiopIieiHC/+EmMM4nTEXFKeHLgRRFOduIYDQ671z0jssFhV R/65N2R9QOKyS5DFKYklLe3N09uPbz0pXZVTIgNeTN1JNKYtX4IS5pvtjWfmnG52qSSS6uWU0J3d gKmWNdJQpB1H9VXlpIxNrTnHl+GcRKaaMzbYXI4XXjUpUiNS6h2nmdamoKWdgvjpKpeS+BuppYJa qYcZTriqqZuqOiqsFckUIKN9XKfndzDlGuGAnrWi2iE2aSnpqS//9BqER78qSytmmgJTCbMgQWtr Kohty20UqeAoCbCixtQXX+aWi+65d+Xph7UMYYtpqE6xUmyTt86aLZRWLSWeu9O2iuqWWa0lnr3h wtssvjqB15C/nibrqrxCliTuwQonLPFRdkn77MXLevzrZcgqd1OSbGJcqY94KsNEQvZU+4yhK77Y FkCy/kujwSpuBl86Lvs8jp+KrgjoyzRfdON7Q5VcUtNDo9dzYxApFPRcO5sJT1xynewcLCS5DJ2B Ti7NpZcHRffZntSYBPS6XwPkc11bm4we1uuQpfY2sjF95zIjpz3oym0DahDQU/+Jps6cTW0gRt4U vtBqZSdetOQA/zNuc9V4Qv441XXSE5rjhwf0qM0UZkmTRpGOpqDMLDsyeOamhDG74GcVnJ2zTe+I kjevIPxxxkKlDnwhPFQcMMQTw7krqzQg//B5A+vTr8NkC5+vwPt+lSWuxRfXbsPWA3Jk+B1jb3zk 6wGsMXlLhfz95P0Apnz72tJ9L/oi2Tm69Nu7ljRBQA9q/ulfGtyEwERZI4E+WqACGejABkJwgmMD IO7cMECxWMmAB+yWBz9YL/B5D2RbKaDr0hctAY5Qf8ETVrxitR0S8kxCL4Qhb1houVRlz4YExGF2 5MU4fiWPhy7UHseA2Jic3XBkscog9ZjUOD+ZTTNo29MPiSiZ+P/V6RtGwtvqkrjEjVTwSUwaU4ic yCYjcfF1/nia+hLklradqYCZQqPUprS1ah1KiTWj2Mz0lhE33seOoHibGsc4Jx3FcH17JNPoxpc/ 9tEqH2hboBSnobuxQVIghJQK1yxkCONsMjmdnCHHplIOLPbRh6ZM3yVFUSJVvkpf4wIjPw7FwfrJ snmsZJ0i25jIC+Ivi7t8Yx3cN8y7CapPuQvmznTJNCyW0k5t9JLYePfKE7aqQFNkImmmaaVqUuyE 9ELVFr/YRHDO0ZFmkKMV83VOQZZKnaXjiR/JySdVxdOY84yfL/loyxbe03Wj/Ekp/3nFhKLsk8UM aJ5aVKsaOrT/oc88Zi15uUOKRpOWESuiQDVKzF6mkoYLBelDZYhQkaq0oQcdqUel4s1PtbSHOmxW TOvoT5fWdFkFBRAAIXrEjJoUoNzTUwg72FONiq9XRz3gUCEBwqhKdaqJUepE83nR6dzgpqzhKoCS aj+lgtWgY9VYWRdmUq92Rq1dPStO3LowuK6Erd+U61zTateK5HWue7WYUgrpRxNCpzQUpSvfhmnG hxTBsIHpKdvo0Tl+AlWajvUdV+AUQF30VSCLtSxk/+jYzRqrskH7rOwWK1pjoVYjrN0gApPKWBSl llhWBWlszXJbtuQ2LLMdbWF7K0Dg2kG4edjtwOKornQpN7nM/12uc89FXDhQdbrUpepTr4vd7Gp3 u9ztrne/C97wine85C2vec+L3vSqd73sba970atNmtqLYV/zIkNRqdCIsusl0dXq9dbpuzbprEZK wypGr4bC/0XJLXALhOFsdDLsBNGSBINiAtFEPAYnLokS3B0e+BAzIKVOmFCVkoA9nDO/KTF2Ebnb mQ55uHqScY0IcVw4a7yyE+MtkZPY3IyL9Vg+su12RAsnNUHLOa19WB4/+sjnYAwpHmshbs7snkKS IRHYNUrDUNYxIF+st1yCGZ1VuiYeG9kaa752G5f944nVdqCZcfPMf4pbYGe8uzxj2Gu1UFmBZDZn ebLkvTt9qwdxbXtoERQAADs= ------_=_NextPart_001_01C9CD66.113DEE1E-- From adrian@olddog.co.uk Tue May 5 03:05:29 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A823A6DEA for ; Tue, 5 May 2009 03:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtT0-DutHGLp for ; Tue, 5 May 2009 03:05:29 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id CDC873A68EE for ; Tue, 5 May 2009 03:05:28 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n45A6ZVR022760; Tue, 5 May 2009 11:06:35 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n45A6VAW022686; Tue, 5 May 2009 11:06:34 +0100 Message-ID: <3EC3B42EADEE4472A1C0DEBFFFC22E27@your029b8cecfe> From: "Adrian Farrel" To: "Lam, Hing-Kam \(Kam\)" References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> Date: Tue, 5 May 2009 11:01:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 10:05:29 -0000 Am I missing something? Does notification across layers take place within a node or on the wire? Thanks, Adrian ----- Original Message ----- From: "Lam, Hing-Kam (Kam)" To: "Malcolm Betts" ; "Sprecher, Nurit (NSN - IL/Hod HaSharon)" ; ; ; "Martin Vigoureux" Sent: Tuesday, May 05, 2009 6:51 AM Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock Dear all, See inline below. I am addressing the issue of notification across layers, not addressing notifying the sink (egress) points. Regards, Kam > -----Original Message----- > From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] > On Behalf Of Malcolm Betts > Sent: Monday, May 04, 2009 8:42 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock > andnotificationof lock > > All, > I think you are making this far too complicated... I see no need to > propagate the locked indication across layers. > > [Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected > interruption to the client services so that to reduce unnecessary alarm > being raised from the client layer. From hhelvoort@chello.nl Tue May 5 03:09:19 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35873A68A8 for ; Tue, 5 May 2009 03:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tOnp-ePCJ+r for ; Tue, 5 May 2009 03:09:19 -0700 (PDT) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id 8DC0C3A7084 for ; Tue, 5 May 2009 03:09:18 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090505101043.TNRN19075.viefep19-int.chello.at@edge03.upc.biz>; Tue, 5 May 2009 12:10:43 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge03.upc.biz with edge id nmAi1b01q3KDBhC03mAj4A; Tue, 05 May 2009 12:10:43 +0200 X-SourceIP: 24.132.228.153 Message-ID: <4A0010A2.4090801@chello.nl> Date: Tue, 05 May 2009 12:10:42 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Annamaria Fulignoli References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> <93DFCD4B101EB440B5B72997456C5F9403ACC0BB@esealmw118.eemea.ericsson.se> In-Reply-To: <93DFCD4B101EB440B5B72997456C5F9403ACC0BB@esealmw118.eemea.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 10:09:19 -0000 Ciao Annamaria, You wrote: > Besides, as many mails were sent on this issue, I'd like to check with > all of us where we are with Lock (2.2.x) and Lock Notification(2.2.y) > requirements. > > I know we are dealing with requirements and not with solutions, but > please let's consider the following example: > > topology is A <---> B <---> C <---> D > > LSP1 goes A-B-C-D [hvh] so the LSP1 MEPs are located in LSR A and LSR D > - The operator decides to set in A LSP1 administratevly down , due for > example to an out of service test on the path. > > The Lock requirement (2.2.x ) requires that A is able to set its peer > MEP D in administratevly lock state. As Lam reported , we are using the > "LOCKED" state and "Lock" event of the X.731 Administrative state model. > This implies that when LSP1 in D enters in the administrative lock > state, all traffic on the path MUST be blocked; but MEP D must notify > the clients , otherwise alarms will be raised against the supported > client services because of the unexpected interruption; i.e. D should > send Lock Notification(2.2.y) to its own clients. [hvh] agree > - In case of bidirectional path even in MEP A the LSP1 (rx direction ) > enters in administrative lock state and even MEP A should notify the > client(s) transported by the path ( i.e. In the backward direction; req. > 2.2.y) [hvh] OK > - My understanding is that the client to which the Lock Notification is > sent are always MEPs as MIP are transparent to Lock and Lock Notification [hvh] yes indeed > - When a MEP receives a Lock Notification it can in turn notify its > MPLS-TP client MEPs or map it into an equivalent signal for whatever > client layer is then being carried. [hvh] correct > - Lock Notification functionality (req 2.2.y ) applies to all scenarios > where server enters the "locked" state ; for instance if a port in LSR B > is set administratevly down (" Lock" event of the X.731 Administrative > state model) LSR B, as Server MEP of paths transimitted and received on > the port , should generate Lock Notification on all these paths, for > example towards D and A , MEPs of LSP1. [hvh] note that LSR B does not have a MEP on LSP1. The scenario you describe only works if e.g. between LSR B and LSR C there is a tunnel (LSP2) carrying LSP1 and LSR B and C have MEPs on LSP2. Now locking MEP on LSP2 in B will cconsequently cause that (lock) notifications will inserted in the MEPs of LSP2 to notify the MEPs in LSP1 (its client). > Are we all agree on these ? [hvh] if you agree on the last comment... Cheers, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From stbryant@cisco.com Tue May 5 03:59:10 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873AD3A6CE4 for ; Tue, 5 May 2009 03:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.988 X-Spam-Level: X-Spam-Status: No, score=-8.988 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_20=-0.74, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jK7oJkwUFM0 for ; Tue, 5 May 2009 03:59:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 53A793A69A8 for ; Tue, 5 May 2009 03:59:06 -0700 (PDT) X-Files: (Forward to attendees) Meeting invitation: MEAD weekly.eml : None X-IronPort-AV: E=Sophos;i="4.40,296,1238976000"; d="eml'208?scan'208,208,217";a="39814877" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 May 2009 11:00:31 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n45B0VfO030024 for ; Tue, 5 May 2009 13:00:31 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n45B0VYH003057 for ; Tue, 5 May 2009 11:00:31 GMT Received: from dhcp-gpk02-vlan300-64-103-65-120.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n45B0Tn14901; Tue, 5 May 2009 12:00:30 +0100 (BST) Message-ID: <4A001C4D.5080104@cisco.com> Date: Tue, 05 May 2009 12:00:29 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: MEAD team Content-Type: multipart/mixed; boundary="------------080408050005080907000205" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14977; t=1241521231; x=1242385231; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20[Fwd=3A=20(Forward=20to=20attendees)=20Meeting= 20invitation=3A=20MEAD=20weekly] |Sender:=20; bh=QNx8acPFOvwT0CDlfwnj1wfVMUj0RvQhEh+AWDZCi/s=; b=uyd1ngCpc6ypXNuiXoo87aWxDiBQJyFQdHQo+kRBalJuQ2xIDX0ACuvtuM vBj3EoJIyzr5OsJgCr2eVr8OTANNwytpGICBSEmsWiH0Nvo5pYgFtZFG6c7y +HBOOA+tHV; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Mpls-interop] [Fwd: (Forward to attendees) Meeting invitation: MEAD weekly] X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 10:59:10 -0000 This is a multi-part message in MIME format. --------------080408050005080907000205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This invite is good for tonight and the following four tuesdays Stewart --------------080408050005080907000205 Content-Type: message/rfc822; name="(Forward to attendees) Meeting invitation: MEAD weekly.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="(Forward to attendees) Meeting invitation: MEAD weekly.eml" X-Account-Key: account3 X-Mozilla-Keys: Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n45AvKn14418 for ; Tue, 5 May 2009 11:57:21 +0100 (BST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 05 May 2009 10:57:20 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n45AvKIZ013827 for ; Tue, 5 May 2009 03:57:20 -0700 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n45Av6Pc025376 for ; Tue, 5 May 2009 10:57:20 GMT X-from-outside-Cisco: 64.68.122.13 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAB+4/0lARHoNkWdsb2JhbACCIjGSfgGBJAEBAQEJCwoHEQU+p3AEBY87EoIqBA8FgS0FiAI X-IronPort-AV: E=Sophos;i="4.40,296,1238976000"; d="scan'208,217";a="102519181" Received: from mda3.webex.com ([64.68.122.13]) by sj-inbound-f.cisco.com with ESMTP; 05 May 2009 10:57:20 +0000 Received: from jsj6wl003.webex.com (ns121.webex.com [64.68.121.8]) by mda3.webex.com (8.12.11/8.12.11) with ESMTP id n45AvKbX018983 for ; Tue, 5 May 2009 03:57:20 -0700 Received: from jsj6wl003.webex.com (by jsj6wl003.webex.com (8.13.1/8.13.1) with ESMTP id n45AvJ1U014905 for ; Tue, 5 May 2009 10:57:20 GMT Date: Tue, 5 May 2009 10:57:19 GMT Message-ID: <32808573.1241521039948.JavaMail.nobody@jsj6wl003.webex.com> From: Stewart Bryant Reply-To: stbryant@cisco.com To: stbryant@cisco.com Subject: (Forward to attendees) Meeting invitation: MEAD weekly MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_102_32793381.1241521039948" X-Priority: 3 Importance: normal Authentication-Results: sj-dkim-1; header.From=messenger@webex.com; dkim=neutral ------=_Part_102_32793381.1241521039948 Content-Type: multipart/Alternative; boundary="----=_Part_103_32793903.1241521039948" ------=_Part_103_32793903.1241521039948 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: base64 KioqKiBZb3UgY2FuIGZvcndhcmQgdGhpcyBlbWFpbCBpbnZpdGF0aW9uIHRvIGF0dGVuZGVlcyAq KioqIA0KDQpIZWxsbyAsDQoNClN0ZXdhcnQgQnJ5YW50IGludml0ZXMgeW91IHRvIGF0dGVuZCB0 aGlzIG9ubGluZSBtZWV0aW5nLg0KDQpUb3BpYzogTUVBRCB3ZWVrbHkNCkRhdGU6IEV2ZXJ5IFR1 ZXNkYXksIGZyb20gVHVlc2RheSwgTWF5IDUsIDIwMDkgdG8gVHVlc2RheSwgSnVuZSAyLCAyMDA5 DQpUaW1lOiA0OjAwIHBtLCBHTVQgRGF5bGlnaHQgVGltZSAoR01UICswMTowMCwgTG9uZG9uKQ0K TWVldGluZyBOdW1iZXI6IDIwNCAzMzAgMjk5DQpNZWV0aW5nIFBhc3N3b3JkOiBtZWFkDQoNClBs ZWFzZSBjbGljayB0aGUgbGluayBiZWxvdyB0byBzZWUgbW9yZSBpbmZvcm1hdGlvbiwgb3IgdG8g am9pbiB0aGUgbWVldGluZy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQUxFUlQ6VG9sbC1GcmVlIERpYWwgUmVzdHJp Y3Rpb25zIGZvciAoNDA4KSBhbmQgKDkxOSkgQXJlYSBDb2Rlcw0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpBcyBvZiBB cHJpbCA5dGgsIDIwMDksIHlvdSBjYW4gbm8gbG9uZ2VyIGRpYWwgdG9sbCBmcmVlIGluIHRoZSA0 MDggb3IgOTE5IGFyZWEgY29kZXMgaW4gdGhlIFVuaXRlZCBTdGF0ZXMuICBUaGUgYWZmZWN0ZWQg dG9sbCBmcmVlIG51bWJlcnMgYXJlOiAoODY2KSA0MzItOTkwMyBmb3IgdGhlIFNhbiBKb3NlL01p bHBpdGFzIGFyZWEgYW5kICg4NjYpIDM0OS0zNTIwIGZvciB0aGUgUlRQIGFyZWEuDQoNClBsZWFz ZSBkaWFsIHRoZSBsb2NhbCBhY2Nlc3MgbnVtYmVyIGZvciB5b3VyIGFyZWEgZnJvbSB0aGUgbGlz dCBiZWxvdzoNCi0gIFNhbiBKb3NlL01pbHBpdGFzICg0MDgpIGFyZWE6ICA1MjUtNjgwMA0KLSAg UlRQICg5MTkpIGFyZWE6ICAzOTItMzMzMA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUbyBqb2luIHRoZSBvbmxpbmUgbWVldGluZw0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K MS4gR28gdG8gaHR0cHM6Ly9jaXNjb3NhbGVzLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP0VE PTExOTIwNjU2NyZVSUQ9MCZQVz1lYzM0NWU1MTU0NDkNCjIuIEVudGVyIHlvdXIgbmFtZSBhbmQg ZW1haWwgYWRkcmVzcy4NCjMuIEVudGVyIHRoZSBtZWV0aW5nIHBhc3N3b3JkOiBtZWFkDQo0LiBD bGljayAiSm9pbiBOb3ciLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIA0KVG8gam9pbiB0aGUgdGVsZWNvbmZlcmVuY2Ugb25seSANCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQox LiBEaWFsIGludG8gQ2lzY28gV2ViRXggKHZpZXcgYWxsIEdsb2JhbCBBY2Nlc3MgTnVtYmVycyBh dCANCmh0dHA6Ly9jaXNjby5jb20vZW4vVVMvYWJvdXQvZG9pbmdfYnVzaW5lc3MvY29uZmVyZW5j aW5nL2luZGV4Lmh0bWwgDQoyLiBQcmVzcyAzIHRvIGF0dGVuZCB0aGUgbWVldGluZy4gDQozLiBG b2xsb3cgdGhlIHByb21wdHMgdG8gZW50ZXIgdGhlIE1lZXRpbmcgTnVtYmVyIChsaXN0ZWQgYWJv dmUpIG9yIEFjY2VzcyBDb2RlIGZvbGxvd2VkIGJ5IHRoZSAjIHNpZ24uIA0KDQpTYW4gSm9zZSwg Q0E6ICsxLjQwOC41MjUuNjgwMCAgUlRQOiArMS45MTkuMzkyLjMzMzAgDQoNClVTL0NhbmFkYTog KzEuODY2LjQzMi45OTAzICBVbml0ZWQgS2luZ2RvbTogKzQ0LjIwLjg4MjQuMDExNyANCg0KSW5k aWE6ICs5MS44MC40MzUwLjExMTEgIEdlcm1hbnk6ICs0OS42MTkuNjc3My45MDAyIA0KDQpKYXBh bjogKzgxLjMuNTc2My45Mzk0ICBDaGluYTogKzg2LjEwLjg1MTUuNTY2NiANCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KVG8gam9p biB0aGUgbWVldGluZyBvbiBpUGhvbmUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkdvIHRvIHdieDovL2Npc2Nvc2FsZXMud2ViZXguY29t L2Npc2Nvc2FsZXM/TUs9MjA0MzMwMjk5Jk1QVz1iZjM1YmY5YTlmZDJjOWMwODFhN2ZmZjBkZjll ZTAwM2Y2Nzg1YTNhMmM5YTNmN2Y4ZWQ5ZmE2NGRlNmUzMzVmDQoNCkRvbid0IGhhdmUgdGhlIGlQ aG9uZSBXZWJFeCBhcHBsaWNhdGlvbiB5ZXQ/IA0KR28gdG8gaHR0cDovL2l0dW5lcy5hcHBsZS5j b20vV2ViT2JqZWN0cy9NWlN0b3JlLndvYS93YS92aWV3U29mdHdhcmU/aWQ9Mjk4ODQ0Mzg2IA0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkZvciBhc3Npc3RhbmNlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoxLiBHbyB0byBodHRwczovL2Npc2Nvc2FsZXMud2ViZXguY29t L2Npc2Nvc2FsZXMvbWMNCjIuIE9uIHRoZSBsZWZ0IG5hdmlnYXRpb24gYmFyLCBjbGljayAiU3Vw cG9ydCIuDQoNCllvdSBjYW4gY29udGFjdCBtZSBhdDoNCnN0YnJ5YW50QGNpc2NvLmNvbQ0KNDQt MjAtODgyNCA4ODI4DQoNClRvIGFkZCB0aGlzIG1lZXRpbmcgdG8geW91ciBjYWxlbmRhciBwcm9n cmFtIChmb3IgZXhhbXBsZSBNaWNyb3NvZnQgT3V0bG9vayksIGNsaWNrIHRoaXMgbGluazoNCmh0 dHBzOi8vY2lzY29zYWxlcy53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9FRD0xMTkyMDY1Njcm VUlEPTAmSUNTPU1JJkxEPTEmUkQ9MiZTVD0xJlNIQTI9LWRvYlVDeFNtU0xpYW1oSGVKMUZGbFNs ejJwdk5aV0lpeTNGYzBDSTRhRT0NCg0KVGhlIHBsYXliYWNrIG9mIFVDRiAoVW5pdmVyc2FsIENv bW11bmljYXRpb25zIEZvcm1hdCkgcmljaCBtZWRpYSBmaWxlcyByZXF1aXJlcyBhcHByb3ByaWF0 ZSBwbGF5ZXJzLiBUbyB2aWV3IHRoaXMgdHlwZSBvZiByaWNoIG1lZGlhIGZpbGVzIGluIHRoZSBt ZWV0aW5nLCBwbGVhc2UgY2hlY2sgd2hldGhlciB5b3UgaGF2ZSB0aGUgcGxheWVycyBpbnN0YWxs ZWQgb24geW91ciBjb21wdXRlciBieSBnb2luZyB0byAgaHR0cHM6Ly9jaXNjb3NhbGVzLndlYmV4 LmNvbS9jaXNjb3NhbGVzL3N5c3RlbWRpYWdub3Npcy5waHANCg0KU2lnbiB1cCBmb3IgYSBmcmVl IHRyaWFsIG9mIFdlYkV4DQpodHRwOi8vd3d3LndlYmV4LmNvbS9nby9tY2VtZnJlZXRyaWFsDQoN Cmh0dHA6Ly93d3cud2ViZXguY29tIApXZSd2ZSBnb3QgdG8gc3RhcnQgbWVldGluZyBsaWtlIHRo aXMoVE0pDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoaXMgV2ViRXggc2VydmljZSBpbmNsdWRlcyBh IGZlYXR1cmUgdGhhdCBhbGxvd3MgYXVkaW8gYW5kIGFueSBkb2N1bWVudHMgYW5kIG90aGVyIG1h dGVyaWFscyBleGNoYW5nZWQgb3Igdmlld2VkIGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNv cmRlZC4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQg dG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gdGhlIHJlY29yZGlu ZywgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uDQo= ------=_Part_103_32793903.1241521039948 Content-Type: text/html;charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+PGZvbnQgRkFDRT0nQXJpYWwsIHNhbnMtc2VyaWYsIEhlbHZldGljYSwgR2VuZXZhJyBz aXplPScyJz4qKioqIFlvdSBjYW4gZm9yd2FyZCB0aGlzIGVtYWlsIGludml0YXRpb24gdG8gYXR0 ZW5kZWVzICoqKiogPGJyPiA8YnI+IEhlbGxvICwgPGJyPiA8YnI+IFN0ZXdhcnQgQnJ5YW50IGlu dml0ZXMgeW91IHRvIGF0dGVuZCB0aGlzIG9ubGluZSBtZWV0aW5nLiA8YnI+IDxicj4gVG9waWM6 IE1FQUQgd2Vla2x5IDxicj4gRGF0ZTogRXZlcnkgVHVlc2RheSwgZnJvbSBUdWVzZGF5LCBNYXkg NSwgMjAwOSB0byBUdWVzZGF5LCBKdW5lIDIsIDIwMDkgPGJyPiBUaW1lOiA0OjAwIHBtLCBHTVQg RGF5bGlnaHQgVGltZSAoR01UICswMTowMCwgTG9uZG9uKSA8YnI+IE1lZXRpbmcgTnVtYmVyOiAy MDQgMzMwIDI5OSA8YnI+IE1lZXRpbmcgUGFzc3dvcmQ6IG1lYWQgPGJyPiA8YnI+IFBsZWFzZSBj bGljayB0aGUgbGluayBiZWxvdyB0byBzZWUgbW9yZSBpbmZvcm1hdGlvbiwgb3IgdG8gam9pbiB0 aGUgbWVldGluZy4gPGJyPiA8YnI+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPiBBTEVSVDpUb2xsLUZyZWUgRGlhbCBS ZXN0cmljdGlvbnMgZm9yICg0MDgpIGFuZCAoOTE5KSBBcmVhIENvZGVzIDxicj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8 YnI+IDxicj4gQXMgb2YgQXByaWwgOXRoLCAyMDA5LCB5b3UgY2FuIG5vIGxvbmdlciBkaWFsIHRv bGwgZnJlZSBpbiB0aGUgNDA4IG9yIDkxOSBhcmVhIGNvZGVzIGluIHRoZSBVbml0ZWQgU3RhdGVz LiBUaGUgYWZmZWN0ZWQgdG9sbCBmcmVlIG51bWJlcnMgYXJlOiAoODY2KSA0MzItOTkwMyBmb3Ig dGhlIFNhbiBKb3NlL01pbHBpdGFzIGFyZWEgYW5kICg4NjYpIDM0OS0zNTIwIGZvciB0aGUgUlRQ IGFyZWEuIDxicj4gPGJyPiBQbGVhc2UgZGlhbCB0aGUgbG9jYWwgYWNjZXNzIG51bWJlciBmb3Ig eW91ciBhcmVhIGZyb20gdGhlIGxpc3QgYmVsb3c6IDxicj4gLSBTYW4gSm9zZS9NaWxwaXRhcyAo NDA4KSBhcmVhOiA1MjUtNjgwMCA8YnI+IC0gUlRQICg5MTkpIGFyZWE6IDM5Mi0zMzMwIDxicj4g PGJyPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tIDxicj4gVG8gam9pbiB0aGUgb25saW5lIG1lZXRpbmcgPGJyPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4gMS4gR28gdG8gPEEg aHJlZj0naHR0cHM6Ly9jaXNjb3NhbGVzLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP0VEPTEx OTIwNjU2NyZVSUQ9MCZQVz1lYzM0NWU1MTU0NDknIHRhcmdldD0gJ19ibGFuayc+aHR0cHM6Ly9j aXNjb3NhbGVzLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP0VEPTExOTIwNjU2NyZVSUQ9MCZQ Vz1lYzM0NWU1MTU0NDk8L0E+IDxicj4gMi4gRW50ZXIgeW91ciBuYW1lIGFuZCBlbWFpbCBhZGRy ZXNzLiA8YnI+IDMuIEVudGVyIHRoZSBtZWV0aW5nIHBhc3N3b3JkOiBtZWFkIDxicj4gNC4gQ2xp Y2sgIkpvaW4gTm93Ii4gPGJyPiA8YnI+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPiBUbyBqb2luIHRoZSB0ZWxlY29uZmVyZW5jZSBv bmx5IDxicj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSA8YnI+IDEuIERpYWwgaW50byBDaXNjbyBXZWJFeCAodmlldyBhbGwgR2xvYmFsIEFj Y2VzcyBOdW1iZXJzIGF0IDxicj4gPEEgaHJlZj0naHR0cDovL2Npc2NvLmNvbS9lbi9VUy9hYm91 dC9kb2luZ19idXNpbmVzcy9jb25mZXJlbmNpbmcvaW5kZXguaHRtbCcgdGFyZ2V0PSAnX2JsYW5r Jz5odHRwOi8vY2lzY28uY29tL2VuL1VTL2Fib3V0L2RvaW5nX2J1c2luZXNzL2NvbmZlcmVuY2lu Zy9pbmRleC5odG1sPC9BPiA8YnI+IDIuIFByZXNzIDMgdG8gYXR0ZW5kIHRoZSBtZWV0aW5nLiA8 YnI+IDMuIEZvbGxvdyB0aGUgcHJvbXB0cyB0byBlbnRlciB0aGUgTWVldGluZyBOdW1iZXIgKGxp c3RlZCBhYm92ZSkgb3IgQWNjZXNzIENvZGUgZm9sbG93ZWQgYnkgdGhlICMgc2lnbi4gPGJyPiA8 YnI+IFNhbiBKb3NlLCBDQTogKzEuNDA4LjUyNS42ODAwIFJUUDogKzEuOTE5LjM5Mi4zMzMwIDxi cj4gPGJyPiBVUy9DYW5hZGE6ICsxLjg2Ni40MzIuOTkwMyBVbml0ZWQgS2luZ2RvbTogKzQ0LjIw Ljg4MjQuMDExNyA8YnI+IDxicj4gSW5kaWE6ICs5MS44MC40MzUwLjExMTEgR2VybWFueTogKzQ5 LjYxOS42NzczLjkwMDIgPGJyPiA8YnI+IEphcGFuOiArODEuMy41NzYzLjkzOTQgQ2hpbmE6ICs4 Ni4xMC44NTE1LjU2NjYgPGJyPiA8YnI+IDxicj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+IFRvIGpvaW4gdGhlIG1lZXRpbmcgb24g aVBob25lIDxicj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSA8YnI+IEdvIHRvIDxBIGhyZWY9J3dieDovL2Npc2Nvc2FsZXMud2ViZXguY29t L2Npc2Nvc2FsZXM/TUs9MjA0MzMwMjk5Jk1QVz1iZjM1YmY5YTlmZDJjOWMwODFhN2ZmZjBkZjll ZTAwM2Y2Nzg1YTNhMmM5YTNmN2Y4ZWQ5ZmE2NGRlNmUzMzVmJyB0YXJnZXQ9ICdfYmxhbmsnPndi eDovL2Npc2Nvc2FsZXMud2ViZXguY29tL2Npc2Nvc2FsZXM/TUs9MjA0MzMwMjk5Jk1QVz1iZjM1 YmY5YTlmZDJjOWMwODFhN2ZmZjBkZjllZTAwM2Y2Nzg1YTNhMmM5YTNmN2Y4ZWQ5ZmE2NGRlNmUz MzVmPC9BPiA8YnI+IDxicj4gRG9uJ3QgaGF2ZSB0aGUgaVBob25lIFdlYkV4IGFwcGxpY2F0aW9u IHlldD8gPGJyPiBHbyB0byA8QSBocmVmPSdodHRwOi8vaXR1bmVzLmFwcGxlLmNvbS9XZWJPYmpl Y3RzL01aU3RvcmUud29hL3dhL3ZpZXdTb2Z0d2FyZT9pZD0yOTg4NDQzODYnIHRhcmdldD0gJ19i bGFuayc+aHR0cDovL2l0dW5lcy5hcHBsZS5jb20vV2ViT2JqZWN0cy9NWlN0b3JlLndvYS93YS92 aWV3U29mdHdhcmU/aWQ9Mjk4ODQ0Mzg2PC9BPiA8YnI+IDxicj4gPGJyPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4gRm9yIGFzc2lz dGFuY2UgPGJyPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tIDxicj4gMS4gR28gdG8gPEEgaHJlZj0naHR0cHM6Ly9jaXNjb3NhbGVzLndlYmV4 LmNvbS9jaXNjb3NhbGVzL21jJyB0YXJnZXQ9ICdfYmxhbmsnPmh0dHBzOi8vY2lzY29zYWxlcy53 ZWJleC5jb20vY2lzY29zYWxlcy9tYzwvQT4gPGJyPiAyLiBPbiB0aGUgbGVmdCBuYXZpZ2F0aW9u IGJhciwgY2xpY2sgIlN1cHBvcnQiLiA8YnI+IDxicj4gWW91IGNhbiBjb250YWN0IG1lIGF0OiA8 YnI+ICA8QSBocmVmPSdtYWlsdG86c3RicnlhbnRAY2lzY28uY29tJz5zdGJyeWFudEBjaXNjby5j b208L0E+IDxicj4gNDQtMjAtODgyNCA4ODI4IDxicj4gPGJyPiBUbyBhZGQgdGhpcyBtZWV0aW5n IHRvIHlvdXIgY2FsZW5kYXIgcHJvZ3JhbSAoZm9yIGV4YW1wbGUgTWljcm9zb2Z0IE91dGxvb2sp LCBjbGljayB0aGlzIGxpbms6IDxicj4gPEEgaHJlZj0naHR0cHM6Ly9jaXNjb3NhbGVzLndlYmV4 LmNvbS9jaXNjb3NhbGVzL2oucGhwP0VEPTExOTIwNjU2NyZVSUQ9MCZJQ1M9TUkmTEQ9MSZSRD0y JlNUPTEmU0hBMj0tZG9iVUN4U21TTGlhbWhIZUoxRkZsU2x6MnB2TlpXSWl5M0ZjMENJNGFFPScg dGFyZ2V0PSAnX2JsYW5rJz5odHRwczovL2Npc2Nvc2FsZXMud2ViZXguY29tL2Npc2Nvc2FsZXMv ai5waHA/RUQ9MTE5MjA2NTY3JlVJRD0wJklDUz1NSSZMRD0xJlJEPTImU1Q9MSZTSEEyPS1kb2JV Q3hTbVNMaWFtaEhlSjFGRmxTbHoycHZOWldJaXkzRmMwQ0k0YUU9PC9BPiA8YnI+IDxicj4gVGhl IHBsYXliYWNrIG9mIFVDRiAoVW5pdmVyc2FsIENvbW11bmljYXRpb25zIEZvcm1hdCkgcmljaCBt ZWRpYSBmaWxlcyByZXF1aXJlcyBhcHByb3ByaWF0ZSBwbGF5ZXJzLiBUbyB2aWV3IHRoaXMgdHlw ZSBvZiByaWNoIG1lZGlhIGZpbGVzIGluIHRoZSBtZWV0aW5nLCBwbGVhc2UgY2hlY2sgd2hldGhl ciB5b3UgaGF2ZSB0aGUgcGxheWVycyBpbnN0YWxsZWQgb24geW91ciBjb21wdXRlciBieSBnb2lu ZyB0byA8QSBocmVmPSdodHRwczovL2Npc2Nvc2FsZXMud2ViZXguY29tL2Npc2Nvc2FsZXMvc3lz dGVtZGlhZ25vc2lzLnBocCcgdGFyZ2V0PSAnX2JsYW5rJz5odHRwczovL2Npc2Nvc2FsZXMud2Vi ZXguY29tL2Npc2Nvc2FsZXMvc3lzdGVtZGlhZ25vc2lzLnBocDwvQT4gPGJyPiA8YnI+IFNpZ24g dXAgZm9yIGEgZnJlZSB0cmlhbCBvZiBXZWJFeCA8YnI+IDxBIGhyZWY9J2h0dHA6Ly93d3cud2Vi ZXguY29tL2dvL21jZW1mcmVldHJpYWwnIHRhcmdldD0gJ19ibGFuayc+aHR0cDovL3d3dy53ZWJl eC5jb20vZ28vbWNlbWZyZWV0cmlhbDwvQT4gPGJyPiA8YnI+IDxBIGhyZWY9J2h0dHA6Ly93d3cu d2ViZXguY29tJyB0YXJnZXQ9ICdfYmxhbmsnPmh0dHA6Ly93d3cud2ViZXguY29tPC9BPiA8YnI+ IFdlJ3ZlIGdvdCB0byBzdGFydCBtZWV0aW5nIGxpa2UgdGhpcyhUTSkgPGJyPiA8YnI+IElNUE9S VEFOVCBOT1RJQ0U6IFRoaXMgV2ViRXggc2VydmljZSBpbmNsdWRlcyBhIGZlYXR1cmUgdGhhdCBh bGxvd3MgYXVkaW8gYW5kIGFueSBkb2N1bWVudHMgYW5kIG90aGVyIG1hdGVyaWFscyBleGNoYW5n ZWQgb3Igdmlld2VkIGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZC4gQnkgam9pbmlu ZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRp bmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gdGhlIHJlY29yZGluZywgZG8gbm90IGpvaW4g dGhlIHNlc3Npb24uIDxicj4gPC9mb250PjwvaHRtbD4= ------=_Part_103_32793903.1241521039948-- ------=_Part_102_32793381.1241521039948-- --------------080408050005080907000205-- From annamaria.fulignoli@ericsson.com Tue May 5 05:16:22 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198B53A672F for ; Tue, 5 May 2009 05:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6KxKi19K+h8 for ; Tue, 5 May 2009 05:16:21 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 798043A7184 for ; Tue, 5 May 2009 05:15:51 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-5c-4a002e4c8bdf Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id CE.45.19078.C4E200A4; Tue, 5 May 2009 14:17:16 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 14:17:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 14:17:15 +0200 Message-ID: <93DFCD4B101EB440B5B72997456C5F9403ACC347@esealmw118.eemea.ericsson.se> In-Reply-To: <4A0010A2.4090801@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock Thread-Index: AcnNbT6q6jMRF2ZMR8KHkrw9z6taYQADPoMQ References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> <93DFCD4B101EB440B5B72997456C5F9403ACC0BB@esealmw118.eemea.ericsson.se> <4A0010A2.4090801@chello.nl> From: "Annamaria Fulignoli" To: X-OriginalArrivalTime: 05 May 2009 12:17:16.0479 (UTC) FILETIME=[6DDF44F0:01C9CD7B] X-Brightmail-Tracker: AAAAAA== Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 12:16:22 -0000 Hi Huub, about last comment yes, I agree! Another example could be if B is a = MEP of a Section ME, i.e among A and B. Thank you. Cheers,=20 Annamaria -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 Sent: marted=EC 5 maggio 2009 12.11 To: Annamaria Fulignoli Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - = Lockandnotificationof lock Ciao Annamaria, You wrote: > Besides, as many mails were sent on this issue, I'd like to check=20 > with all of us where we are with Lock (2.2.x) and Lock=20 > Notification(2.2.y) requirements. >=20 > I know we are dealing with requirements and not with solutions, but=20 > please let's consider the following example: >=20 > topology is A <---> B <---> C <---> D >=20 > LSP1 goes A-B-C-D [hvh] so the LSP1 MEPs are located in LSR A and LSR D > - The operator decides to set in A LSP1 administratevly down , due for = > example to an out of service test on the path. >=20 > The Lock requirement (2.2.x ) requires that A is able to set its peer=20 > MEP D in administratevly lock state. As Lam reported , we are using=20 > the "LOCKED" state and "Lock" event of the X.731 Administrative state = model. > This implies that when LSP1 in D enters in the administrative lock=20 > state, all traffic on the path MUST be blocked; but MEP D must notify=20 > the clients , otherwise alarms will be raised against the supported=20 > client services because of the unexpected interruption; i.e. D should=20 > send Lock Notification(2.2.y) to its own clients. [hvh] agree > - In case of bidirectional path even in MEP A the LSP1 (rx direction ) = > enters in administrative lock state and even MEP A should notify the > client(s) transported by the path ( i.e. In the backward direction; = req.=20 > 2.2.y) [hvh] OK > - My understanding is that the client to which the Lock Notification=20 > is sent are always MEPs as MIP are transparent to Lock and Lock=20 > Notification [hvh] yes indeed > - When a MEP receives a Lock Notification it can in turn notify its=20 > MPLS-TP client MEPs or map it into an equivalent signal for whatever=20 > client layer is then being carried. [hvh] correct > - Lock Notification functionality (req 2.2.y ) applies to all=20 > scenarios where server enters the "locked" state ; for instance if a=20 > port in LSR B is set administratevly down (" Lock" event of the X.731=20 > Administrative state model) LSR B, as Server MEP of paths transimitted = > and received on the port , should generate Lock Notification on all=20 > these paths, for example towards D and A , MEPs of LSP1. [hvh] note that LSR B does not have a MEP on LSP1. The scenario you describe only works if e.g. between LSR B and LSR C = there is a tunnel (LSP2) carrying LSP1 and LSR B and C have MEPs on = LSP2. Now locking MEP on LSP2 in B will cconsequently cause that (lock) = notifications will inserted in the MEPs of LSP2 to notify the MEPs in = LSP1 (its client). > Are we all agree on these ? [hvh] if you agree on the last comment... Cheers, 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=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... From BETTS01@nortel.com Tue May 5 06:12:52 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF5B3A6B55 for ; Tue, 5 May 2009 06:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0YAmooHydHs for ; Tue, 5 May 2009 06:12:51 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 109BC3A6859 for ; Tue, 5 May 2009 06:12:50 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n45DE9m08476; Tue, 5 May 2009 13:14:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 09:14:05 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D517038B43@zcarhxm2.corp.nortel.com> In-Reply-To: <49FF4E19.2060203@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] Schedule to address the the ITU-T comments on the MPLS-TP requirements Thread-Index: AcnM9dTo9I8N0nNiQ02kS3n8bSAm0AAjPdTg References: <49FF02B2.8030904@pi.nu> <49FF4E19.2060203@pi.nu> From: "Malcolm Betts" To: "Loa Andersson" , "MEAD team" Subject: Re: [Mpls-interop] Schedule to address the the ITU-T comments on the MPLS-TP requirements X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:12:52 -0000 Loa, I liked the previous version.... Discussion of the OAM requirements identified several of the requirements that are candidates for transfer to the NM requirements. Perhaps we should hold off on the last call on the NM requirements until we discuss this on the MEAD team call today and agree if these requirements should be moved.=20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Monday, May 04, 2009 4:21 PM To: MEAD team Subject: Re: [Mpls-interop] Schedule to address the the ITU-T comments on the MPLS-TP requirements All, sometimes it is good to have a working group sectreatry :) please see inline Loa Andersson wrote: > All, >=20 > this is the schedule to respond to the comments from ITU-T SG15 on the > MPLS-TP requirements. >=20 > 1. Ben will produce a version of the draft for a MEAD team > phone conference review on May 12th > (At the MEAD team meeting on tomorrow we will try to "finish" > the MEAD team review of the MPLS TP OAM requirements). > This will be the meeting where we discuss the correct way > of stating the reuiremetns thats has been discussed on the > list. >=20 > 2. After the MEAD team review on the 12th Ben will update the > document and it will go for a two weeks wg last call, starting > the 17 or 18th (depending a bit on how quicjk Ben can turn it > around) >=20 > 3. This wg lst call will overlap the SG15 interim meeting in > Sophia, this was not intended from the satart. But Malcolm and > I talked about and agreed that that it is not a bug but a feature. > SG15 will be able to use their normal procedure to espond to > the working group last call. >=20 > 4. As a side effect I not feel comfortable to send the MPLS-TP > NM requirements to a working group last call. this paragraph should hav read> 4. As a side effect I now feel comfortable to send the MPLS-TP NM requirements to a working group last call. /Loa >=20 > /Loa --=20 Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13=20 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From hklam@alcatel-lucent.com Tue May 5 06:29:39 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0193A6EAB for ; Tue, 5 May 2009 06:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsuQwMhLRw+R for ; Tue, 5 May 2009 06:29:38 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 679273A6B83 for ; Tue, 5 May 2009 06:29:38 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n45DUrKU010082; Tue, 5 May 2009 08:31:03 -0500 (CDT) Received: from ILEXC2U03.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 08:30:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 08:30:58 -0500 Message-ID: In-Reply-To: <3EC3B42EADEE4472A1C0DEBFFFC22E27@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock Thread-Index: AcnNaTdn6df/qhlyS5Obn24zbR4ScAAGzjdA References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> <3EC3B42EADEE4472A1C0DEBFFFC22E27@your029b8cecfe> From: "Lam, Hing-Kam \(Kam\)" To: "Adrian Farrel" X-OriginalArrivalTime: 05 May 2009 13:30:58.0137 (UTC) FILETIME=[B962BC90:01C9CD85] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:29:39 -0000 Notification across layers takes place within a node. This is the context that my email was responding to. In a separate email from Malcolm, he mentioned "just notify the far end that the lock is in place and allow the decision ..." This is not what my email was responding to. I hope I understand your first question correctly. Regards, Kam > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, May 05, 2009 6:02 AM > To: Lam, Hing-Kam (Kam) > Cc: mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - > Lockandnotificationof lock >=20 > Am I missing something? > Does notification across layers take place within a node or on the wire? >=20 > Thanks, > Adrian >=20 > ----- Original Message ----- > From: "Lam, Hing-Kam (Kam)" > To: "Malcolm Betts" ; "Sprecher, Nurit (NSN - IL/Hod > HaSharon)" ; ; > ; "Martin Vigoureux" > > Sent: Tuesday, May 05, 2009 6:51 AM > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - > Lockandnotificationof > lock >=20 >=20 > Dear all, >=20 > See inline below. I am addressing the issue of notification across > layers, not addressing notifying the sink (egress) points. >=20 > Regards, >=20 > Kam >=20 > > -----Original Message----- > > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] > > On Behalf Of Malcolm Betts > > Sent: Monday, May 04, 2009 8:42 AM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > > mpls-interop@ietf.org > > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock > > andnotificationof lock > > > > All, > > I think you are making this far too complicated... I see no need to > > propagate the locked indication across layers. > > > > [Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected > > interruption to the client services so that to reduce unnecessary alarm > > being raised from the client layer. >=20 From Martin.Vigoureux@alcatel-lucent.com Tue May 5 06:32:30 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A213A6CAD for ; Tue, 5 May 2009 06:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESyRAtjxdNxN for ; Tue, 5 May 2009 06:32:30 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id B60E228C19B for ; Tue, 5 May 2009 06:32:19 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n45DXEdu006322; Tue, 5 May 2009 15:33:43 +0200 Received: from [172.27.205.135] ([172.27.205.135]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 15:33:40 +0200 Message-ID: <4A004034.8000101@alcatel-lucent.com> Date: Tue, 05 May 2009 15:33:40 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Lam, Hing-Kam \(Kam\)" References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> <3EC3B42EADEE4472A1C0DEBFFFC22E27@your029b8cecfe> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 May 2009 13:33:40.0486 (UTC) FILETIME=[1A273A60:01C9CD86] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:32:30 -0000 Kam, does this give the complete view? in other word does the notification stop at the MEP of the Locked LSP or is it propagated to MEPs of clients layers? -m Lam, Hing-Kam (Kam) a écrit : > Notification across layers takes place within a node. This is the > context that my email was responding to. > > In a separate email from Malcolm, he mentioned "just notify the far end > that the lock is in place and allow the decision ..." This is not what > my email was responding to. > > I hope I understand your first question correctly. > > Regards, > Kam > >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Tuesday, May 05, 2009 6:02 AM >> To: Lam, Hing-Kam (Kam) >> Cc: mpls-interop@ietf.org >> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - >> Lockandnotificationof lock >> >> Am I missing something? >> Does notification across layers take place within a node or on the > wire? >> Thanks, >> Adrian >> >> ----- Original Message ----- >> From: "Lam, Hing-Kam (Kam)" >> To: "Malcolm Betts" ; "Sprecher, Nurit (NSN - > IL/Hod >> HaSharon)" ; ; >> ; "Martin Vigoureux" >> >> Sent: Tuesday, May 05, 2009 6:51 AM >> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - >> Lockandnotificationof >> lock >> >> >> Dear all, >> >> See inline below. I am addressing the issue of notification across >> layers, not addressing notifying the sink (egress) points. >> >> Regards, >> >> Kam >> >>> -----Original Message----- >>> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] >>> On Behalf Of Malcolm Betts >>> Sent: Monday, May 04, 2009 8:42 AM >>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; >>> mpls-interop@ietf.org >>> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock >>> andnotificationof lock >>> >>> All, >>> I think you are making this far too complicated... I see no need to >>> propagate the locked indication across layers. >>> >>> [Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected >>> interruption to the client services so that to reduce unnecessary > alarm >>> being raised from the client layer. > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > From BETTS01@nortel.com Tue May 5 06:39:00 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2AE13A6A0D for ; Tue, 5 May 2009 06:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPAbU5Br2U3d for ; Tue, 5 May 2009 06:39:00 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C2B8F3A68BF for ; Tue, 5 May 2009 06:38:59 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n45Ddam16989; Tue, 5 May 2009 13:39:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 09:39:15 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D517038C05@zcarhxm2.corp.nortel.com> In-Reply-To: <49FF5DA9.4000807@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof lock Thread-Index: AcnM/xdqMNUaaij0TQKlGN8wYn1nugAh5Crw References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl> <077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net> <0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> <49FF5DA9.4000807@chello.nl> From: "Malcolm Betts" To: Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:39:00 -0000 Hi Huub, think we agree, see inline.=20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 Sent: Monday, May 04, 2009 5:27 PM To: Betts, Malcolm (CAR:X632) Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof lock Hi Malcolm, You wrote: > I think you are making this far too complicated... I see no need to=20 > propagate the locked indication across layers. > > If the operator decides to lock a LSP (for example to run a test) then > the clients of that LSP should be taken out of service before the lock > is applied. That should be the proper procedure. > When a server LSP detects the locked notification it informs the=20 > client adaptation that it is no longer receiving valid traffic. If=20 > the client has already been taken out of service then this is a "don't > care". If the client has not been taken out of service then it should > raise an alarm. But shouldn't the client layer be able to determine whether the fault cause is in its own layer or in the server layer? This is similar to the notification server trail failure to its client layer. So in fact the same notification can be used for both cases. MB> Agree, I had made that assumption, but it should be an explicit statement (in the NM requirements?). 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=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... From BETTS01@nortel.com Tue May 5 06:41:40 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFBA3A67AE for ; Tue, 5 May 2009 06:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qciPlgXgNipv for ; Tue, 5 May 2009 06:41:38 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C09BF3A6EAB for ; Tue, 5 May 2009 06:41:06 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n45Dfa613893 for ; Tue, 5 May 2009 13:41:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 09:42:06 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D517038C1A@zcarhxm2.corp.nortel.com> In-Reply-To: <49FF3AE6.6010200@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock Thread-Index: AcnM6mlc2PRkOSthQuSu1lDyb/e/LQAnMH3A References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe> <49FDE0C4.7060807@alcatel-lucent.com> <0BDFFF51DC89434FA33F8B37FCE363D516FDB211@zcarhxm2.corp.nortel.com> <49FEE492.2070609@alcatel-lucent.com> <0BDFFF51DC89434FA33F8B37FCE363D517037DDC@zcarhxm2.corp.nortel.com> <49FF3AE6.6010200@alcatel-lucent.com> From: "Malcolm Betts" To: "Martin Vigoureux" Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:41:40 -0000 Martin,=20 I agree. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com]=20 Sent: Monday, May 04, 2009 2:59 PM To: Betts, Malcolm (CAR:X632) Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and = notification of lock Malcolm, it appears that we agree on the need for the two functionalities: - notification to the receiving end point of lock having been performed at the source point. - request from an end point that the other far end performs a lock. What I do not understand is why do you want to force the piggybacking of = the latter on the former. We should stick to required elementary functionalities and not impose a = given protocol implementation. regards, martin Malcolm Betts a =E9crit : > Martin, >=20 > I am tempted to simplify still further, just notify the far end that = the lock is in place and allow the decision to lock the reverse = direction to be a locally configured option. >=20 > I cannot think of a case where you would only want to lock one = direction of a bidirectional LSP, so this would be the default = behaviour. >=20 >=20 > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com >=20 > -----Original Message----- > From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] > Sent: Monday, May 04, 2009 8:50 AM > To: Betts, Malcolm (CAR:X632) > Cc: Adrian Farrel; mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and=20 > notification of lock >=20 > Malcolm, >=20 > I fully agree that the lock is performed locally. > I also agree that the other end point must be aware of this lock. > This is exactly what I have written below. >=20 > On bidir LSP the notification may be used to request the lock at the = far end but this is for me an implementation decision. > We should, as agreed during the call, stick to elementary = functionalities. > Therefore we need two distinct functionalities: > inform the far end that lock has been performed request the far end to = > perform lock >=20 > do we agree on that? >=20 > one functionality I believe we also need is to inform client layers of = the lock condition of a server, but I'll discuss this in the other = e-mail you sent. >=20 > regards, > -m >=20 > Malcolm Betts a =E9crit : >> Martin, >> >> The key point is that the lock action is implemented locally. e.g. = at the sending end of a LSP the traffic can be blocked. One example of = the use of this is to allow a test source to be connected (vs. client = traffic). Even on a unidirectional LSP it is useful to have a = notification sent to the receiving end of the LSP so that it is aware = that it is not receiving "valid" client traffic. >> >> On a bidirectional LSP this notification may be used to activate a = lock in the reverse direction. >> >> Hope this clears up the confusion. >> =20 >> >> >> Malcolm Betts >> Nortel Networks >> Phone: +1 613 763 7860 (ESN 393) >> email: betts01@nortel.com >> >> -----Original Message----- >> From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] >> Sent: Sunday, May 03, 2009 2:22 PM >> To: Adrian Farrel; Betts, Malcolm (CAR:X632) >> Cc: mpls-interop@ietf.org >> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and=20 >> notification of lock >> >> Adrian, Malcolm, all, >> >> here are my thoughts on this: >> >> As far as I understand, strictly speaking the Lock function does not = make sense on a unidir LSP. Indeed locking is performed at the source = point and so there is no need to send any message to perform that Lock. = (the potentially needed message is to inform the end-point(s) of the = status but that is lock notification. >> I'll come back to this). >> Therefore Lock is only needed on a bidir entity and what is exactly = needed is the capability to request the other end point to admin lock = its direction. >> >> Coming back to the notification, I believe the following requirement = is needed: >> The MPLS-TP OAM toolset MUST provide a functionality to enable an >> End Point of a PW, LSP or Section to inform the End Point(s) of = that >> LSP, PW, or Section that the PW, LSP or Section has been >> administratively shutdown at this End Point. >> But it is conditionally needed. This function is *only* needed if = locking is achieved via Lock, otherwise if it is achieved via NMS = commands we (I hope) can safely assume that: >> for undir LSP there will be commands at both ends, one saying lock, = the other saying you are notified of other end locking. >> for bidir LSP there will be commands at both ends, both saying lock = and you are notified of other end locking. >> >> The MUST is needed because the egress must be aware of the Lock = because we expect him to then inform client MEPs that are "downstream". = (see question at the end of this e-mail). >> >> The small problem I have is that this function is a notification one=20 >> but really tightly linked to the Lock. In other words, I do not know=20 >> where this reqs better fits (especially wrt to the conditional >> issue): in Lock or in Lock Notification? >> Opinions are welcomed. >> >> Therefore I propose: >> >> 2.2.x. Lock >> The MPLS-TP OAM toolset SHOULD provide a functionality to enable an = End Point of a bidirectional PW, LSP or Section to request to its = associated End Point that it administratively shuts down the direction = of the PW, LSP or Section for which it is the head-end. >> >> This function SHOULD be performed on-demand. >> >> This function SHOULD be performed between the End Points of a PW, LSP = or Section. >> >> Note that administratively shutting down corresponds to stopping user = traffic being sent on the PW, LSP or Section. >> >> >> 2.2.y. Lock Notification >> The MPLS-TP OAM toolset MUST provide a function to enable End Points=20 >> of a (server) LSP or Section to notify, of its administrative locking = >> status, the End Points of (client) PWs or LSPs affected by this = status. >> >> This function SHOULD be performed on-demand. >> >> This function SHOULD be performed between the End Points of a PW, LSP = >> or Section. >> -comment: >> this needs to be rephrased as the notifying end points may not be the = >> same nodes than the notified end points. >> The general case is in fact a notification between end points of=20 >> different e.g., LSPs while the sentence seems to say that it is=20 >> between the end-points of the same e.g., LSP. >> Any suggestion welcomed. >> >> See also my e-mail: >> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" = >> OAM messages ? >> >> -question: >> More generally to the comment above, who should notify and who should = >> notify whom? >> I would tend to say: >> the receiving node of a locked direction, informs downstream=20 >> receiving nodes of nested LSPs. This is a Fowrward Indication and if=20 >> we do so then receiving points MUST indeed be informed of a Lock = (c.f. >> discussion at the beginning of the e-mail). >> Should source points (locking points) do some reverse indication and=20 >> notify the source points of the LSPs that are nested in the locked = LSP? >> (but this maybe falls in the RDI functionality). >> >> I guess that is all, sorry for this long e-mail. >> >> regards, >> -m >> >> >> Adrian Farrel a =E9crit : >>> Hi Malcolm, >>> >>>> To address the comments from Adrian I suggest the following text=20 >>>> for sections 2.2.7 and 2.2.8: >>>> >>>> Note that this proposal assumes that the text related to=20 >>>> local/remote faults is moved from section 2.2.8 to section 2.2.2 as = >>>> proposed in my previous email. >>>> >>>> We probably need to discuss this text on the MEAD team call next=20 >>>> week. >>>> >>>> 2.2.7. Lock >>>> >>>> The OAM toolset SHOULD provide a function enabling a network=20 >>>> operator to administratively shut down a PW, LSP or Section; that=20 >>>> is, to stop user traffic being sent over that PW, LSP or Section. >>> This is great. >>> Does it mean that we do not need to add the (similar) text on CV=20 >>> fault behavior in section 2.2.3? >>> It would seem so. >>> >>>> The lock function MAY be applied to a unidirectional or a=20 >>>> bidirectional PW, LSP or Section. If the lock function is=20 >>>> activated at the head end of one direction of a bidirectional PW,=20 >>>> LSP or Section then it SHOULD be possible to cause the lock=20 >>>> function to be activated at the head end of the other direction. >>>> >>>> This function SHOULD be performed on-demand i.e. in response to an=20 >>>> operator command. >>> Or also in response to configured automatic behavior? >>> >>> But this is not a protocol requirement. >>> >>>> This function SHOULD be performed between End Points of PWs, LSPs=20 >>>> and Sections. >>>> >>>> 2.2.8 Notification of Lock >>>> >>>> If the lock function is supported the MPLS-TP OAM toolset MUST=20 >>>> provide a function to enable the End Point at the ingress to notify = >>>> the End Points at the egress that the lock function is active. =20 >>>> This function SHOULD be performed pro-actively. >>>> >>>> The MPLS-TP OAM toolset MUST allow for the distinction between a=20 >>>> fault condition and an administrative locking action. >>> Works for me. >>> >>> A >>> >>> >>> >>> _______________________________________________ >>> Mpls-interop mailing list >>> Mpls-interop@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-interop >>> >=20 From BETTS01@nortel.com Tue May 5 06:44:44 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB403A67DA for ; Tue, 5 May 2009 06:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.24 X-Spam-Level: X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaQPC-j+xucf for ; Tue, 5 May 2009 06:44:42 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7C4CA3A67AE for ; Tue, 5 May 2009 06:44:42 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n45Dj9614628; Tue, 5 May 2009 13:45:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 09:46:02 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D517038C44@zcarhxm2.corp.nortel.com> In-Reply-To: <49FF6616.3050905@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? Thread-Index: AcnNBCHP1awuJ2VXTYyy6P/LEGe2YgAg1mTg References: <49FF6616.3050905@chello.nl> From: "Malcolm Betts" To: , "George Swallow" Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:44:44 -0000 Agree, see in line.=20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Huub van Helvoort Sent: Monday, May 04, 2009 6:03 PM To: George Swallow Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ? Hello George, You wrote: > I very much agree with Martin here. >=20 > In MPLS-TP the MEG level is not explicit. It is inferred from the LSP > the OAM is received on. In typical LSRs, a Server layer down event,=20 > e.g. The failure of a link results in an "Interface Down Event". When > this occurs all clients of that interface that have registered for the > event would be notified. Further notification of peer entities is the > responsibility of those clients. I agree with this as well. > So to me it makes a great deal of sense to have the MEP serving the=20 > link declare that the IF is down, and have the client MIPs be=20 > responsible for sending any needed OAM messages regarding that event. The notification of the "interface down event" should be accomplished by inserting the OAM message (server failed) in the adaptation function of the server layer MEP. MB> Not convinced that we need an OAM message, we do need a local notification. 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=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From adrian@olddog.co.uk Tue May 5 06:51:39 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385933A6A2C for ; Tue, 5 May 2009 06:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpjQI8Dcz-Fn for ; Tue, 5 May 2009 06:51:38 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 809913A6D11 for ; Tue, 5 May 2009 06:50:58 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n45Dq35p023294; Tue, 5 May 2009 14:52:03 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n45Dpw9i023098; Tue, 5 May 2009 14:52:03 +0100 Message-ID: <822BE5E3CF2E4EA385C798C8797B81E1@your029b8cecfe> From: "Adrian Farrel" To: "Lam, Hing-Kam \(Kam\)" References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> <3EC3B42EADEE4472A1C0DEBFFFC22E27@your029b8cecfe> Date: Tue, 5 May 2009 14:50:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:51:39 -0000 Hi, Thanks Kam, > Notification across layers takes place within a node. This is > the context that my email was responding to. This is the answer I was hoping to see as it coincides with my view of the world. Doesn't that make inter-layer notificaiton an implementation issue? Or, in terms of which douments we have, it is an architecture/framework item, not a requirements item. Thanks, Adrian > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, May 05, 2009 6:02 AM > To: Lam, Hing-Kam (Kam) > Cc: mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - > Lockandnotificationof lock > > Am I missing something? > Does notification across layers take place within a node or on the wire? > > Thanks, > Adrian > > ----- Original Message ----- > From: "Lam, Hing-Kam (Kam)" > To: "Malcolm Betts" ; "Sprecher, Nurit (NSN - IL/Hod > HaSharon)" ; ; > ; "Martin Vigoureux" > > Sent: Tuesday, May 05, 2009 6:51 AM > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - > Lockandnotificationof > lock > > > Dear all, > > See inline below. I am addressing the issue of notification across > layers, not addressing notifying the sink (egress) points. > > Regards, > > Kam > > > -----Original Message----- > > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] > > On Behalf Of Malcolm Betts > > Sent: Monday, May 04, 2009 8:42 AM > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > > mpls-interop@ietf.org > > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock > > andnotificationof lock > > > > All, > > I think you are making this far too complicated... I see no need to > > propagate the locked indication across layers. > > > > [Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected > > interruption to the client services so that to reduce unnecessary alarm > > being raised from the client layer. > From BETTS01@nortel.com Tue May 5 06:55:04 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 167BD3A700E for ; Tue, 5 May 2009 06:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 tagged_above=-999 required=5 tests=[AWL=-1.590, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EE-S8idunsas for ; Tue, 5 May 2009 06:54:53 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2A90D28C19B for ; Tue, 5 May 2009 06:54:53 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n45DuFm22168; Tue, 5 May 2009 13:56:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C9CD89.410C1FB2" Date: Tue, 5 May 2009 09:56:13 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D517038CA2@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock andnotificationof lock Thread-Index: AcnMibd+2qVOSWcIR5GzbLZ+V24I5QAANxMQAAp1z8AAIYmmcAATgWMA References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net> <0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> From: "Malcolm Betts" To: "Lam, Hing-Kam (Kam)" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , , , "Martin Vigoureux" Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock andnotificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:55:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CD89.410C1FB2 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9CD89.410C1FB2" ------_=_NextPart_002_01C9CD89.410C1FB2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kam, =20 Thank you for the description of the NM aspects of Lock. Just to clarify one point when I stated: I see no need to propagate the locked indication across layers. I was think only of the direct data path. I fully agree that management notifications should be passed between layers as you have described. =20 I think that most of the material in you email should be in the NM requirements document. Malcolm Betts=20 Nortel Networks=20 Phone: +1 613 763 7860 (ESN 393)=20 email: betts01@nortel.com=20 ________________________________ From: Lam, Hing-Kam (Kam) [mailto:hklam@alcatel-lucent.com]=20 Sent: Tuesday, May 05, 2009 1:51 AM To: Betts, Malcolm (CAR:X632); Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; mpls-interop@ietf.org; Martin Vigoureux Subject: RE: [Mpls-interop] MPLS-TP OAM requirements - Lock andnotificationof lock Dear all, =20 See inline below. I am addressing the issue of notification across layers, not addressing notifying the sink (egress) points. =20 Regards, Kam =20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] > On Behalf Of Malcolm Betts > Sent: Monday, May 04, 2009 8:42 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; mpls- > interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock > andnotificationof lock >=20 > All, >=20 > I think you are making this far too complicated... I see no need to > propagate the locked indication across layers. [Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected interruption to the client services so that to reduce unnecessary alarm being raised from the client layer. >=20 > If the operator decides to lock a LSP (for example to run a test) then > the clients of that LSP should be taken out of service before the lock > is applied. [Lam, Hing-Kam (Kam)] This is a reasonable assumption and a good practice. It will be helpful to explicitly say so in the document. The reason is that now we are using the "LOCKED" state and "Lock" event of the X.731 Administrative state model. There are additional state values and events in the model. We need to be precise and accurate, in particular if we support only a subset of the model. Otherwise it may cause unnecessary confusion and inconsistence in the future. The Administrative State model in X.731 defines three state values (namely: UNLOCKED, LOCKED, and SHUTTING DOWN) and events as shown below.=20 =20 If you administratively lock a server, the server will enter the "locked" state. Therefore the server will no longer be able to provide its intended service (of supporting all its clients). The effect (i.e. impact) on the clients is no different than a server failure. Usually you don't want to do this. Instead, you would like to gracefully take the server out of service, i.e. administratively shut down the server, and by doing so the server will enter the "shutting down" state. The "shutting down" state is a transition state. When the last user (in this case the last client service) quit, then the server will automatically enter the "locked" state. If we are not going to support the Shutting Down state of the model, then you better either (1) take the clients of the server LSP out of service before the lock is applied or (2) notify the clients in advance, otherwise alarms will be raised against the supported client services because of the unexpected interruption. =20 >=20 > When a server LSP detects the locked notification it informs the client > adaptation that it is no longer receiving valid traffic. If the client > has already been taken out of service then this is a "don't care". If > the client has not been taken out of service then it should raise an > alarm. >=20 >=20 > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com >=20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN > - IL/Hod HaSharon) > Sent: Monday, May 04, 2009 3:47 AM > To: hhelvoort@chello.nl; mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and > notificationof lock >=20 > Huub, > You say " this requires that a MIP has the capability to send OAM > messages based on management command or based on an indication of a MEP > in a different layer. This also requires that at every MEP location > there are also MIPs for every client entity serviced by that MEP." > This looks more as an implementation description. What is actually > required is that the endpoints of the client layer are informed of this > event. > The way you describe it seems a little bit "against" the framework in > which it is specified that OAM messages cannot be initiated by MIPs. > That is why we actually say that this is an adaptation function, that > means that the message is initiated by the MEP of the server to the MEP > of the client....... > Best regards, > NUrit >=20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Huub van > Helvoort > Sent: Monday, May 04, 2009 10:27 AM > To: mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and > notification of lock >=20 > Hello Nurit, >=20 > You wrote: >=20 > > To continue with the othe rquestion: > > > >> See also my e-mail: > >> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" >=20 > >> OAM messages ? > > > > The answer was no. > > > >> -question: > >> More generally to the comment above, who should notify and who should >=20 > >> notify whom? > >> I would tend to say: > >> the receiving node of a locked direction, informs downstream > receiving > >> nodes of nested LSPs. > > > > To be more exact, the sink side of a locked LSP, PW, Section, has to > > inform its clients. >=20 > You say " To be more exact, the sink side of a locked LSP, PW, Section, > has to inform its clients.", >=20 > [hvh] it should inform its client transport entities in the > server/client relation >=20 > BUT the client is not necessarily an > endpoint but may be an intermediate point, and it needs to notify its > endpoints, that means that a MIP generates an OAM message. >=20 > [hvh this requires that a MIP has the capability to send OAM messages > based on management command or based on an indication of a MEP in a > different layer. > This also requires that at every MEP location there are also MIPs for > every client entity serviced by that MEP. >=20 > Long ago I discussed this point with Italo and he indicated to me that > it is not a generation of a message by a MIP BUT it is a variation of an > adaptation function at the client intermediate point. Although we are > talking here about a way to implement it, this is a conceptual issue > that we need to agree on. >=20 > [hvh] I agree with Italo. >=20 > Also, I think we should generalize the discussion instead of talking > every time about LSP, PW, section, etc. we should really talk about > client/server layers to cover cases of LSP hierarchies, etc. >=20 > [hvh] then I use server/client path/trail the next time, OK? >=20 > Regards, Huub. >=20 > >> This is a Fowrward Indication and if we do so then receiving points > >> MUST indeed be informed of a Lock (c.f. > >> discussion at the beginning of the e-mail). > >> Should source points (locking points) do some reverse indication and > >> notify the source points of the LSPs that are nested in the locked > > LSP? > >> (but this maybe falls in the RDI functionality). > > > > Isn't this notification already caused by the locking at the far end? > > Or is the locking only applied in one direction of a bi-directional > > path? If yes, then the notification is not required. > > > > Cheers, Huub. > > >=20 > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_002_01C9CD89.410C1FB2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Kam,
 
Thank you for the description of the NM = aspects of=20 Lock.  Just to clarify one point when I = stated:
I see no need to propagate the locked=20 indication across layers.
I was think only of the direct data path.  = I fully=20 agree that management notifications should be passed between layers as = you have=20 described.
 
I think that most of the material in you email = should be in=20 the NM requirements document.

Malcolm = Betts=20
Nortel = Networks=20
Phone: +1 613 763 = 7860 (ESN=20 393)
email:=20 betts01@nortel.com

From: Lam, Hing-Kam (Kam)=20 [mailto:hklam@alcatel-lucent.com]
Sent: Tuesday, May 05, 2009 = 1:51=20 AM
To: Betts, Malcolm (CAR:X632); Sprecher, Nurit (NSN - = IL/Hod=20 HaSharon); hhelvoort@chello.nl; mpls-interop@ietf.org; Martin=20 Vigoureux
Subject: RE: [Mpls-interop] MPLS-TP OAM requirements = - Lock=20 andnotificationof lock

Dear=20 all,

 

See = inline below.=20 I am addressing the issue of notification across layers, not addressing=20 notifying the sink (egress) points.

 

Regards,

Kam

 

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

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

> On Behalf Of Malcolm = Betts

> Sent: Monday, May 04, 2009 8:42=20 AM

> To: Sprecher, Nurit (NSN - IL/Hod = HaSharon);=20 hhelvoort@chello.nl; mpls-

> interop@ietf.org

> Subject: Re: [Mpls-interop] MPLS-TP OAM=20 requirements - Lock

> andnotificationof lock

>

> All,

>

> I think you are making this far too=20 complicated...  I see no need to

> propagate the locked indication across=20 layers.

[Lam, Hing-Kam (Kam)] The bottom line is to = avoid=20 unexpected interruption to the client services so that to reduce = unnecessary=20 alarm being raised from the client layer.

>

> If the operator decides to lock a LSP = (for example=20 to run a test) then

> the clients of that LSP should be taken = out of=20 service before the lock

> is applied.

[Lam, Hing-Kam (Kam)] This is a reasonable = assumption=20 and a good practice. It will be helpful to explicitly say so in the = document.=20 The reason is that now we are using the “LOCKED” state and = “Lock” event of the=20 X.731 Administrative state model. There are additional state values and = events=20 in the model. We need to be precise and accurate, in particular if we = support=20 only a subset of the model. Otherwise it may cause unnecessary confusion = and=20 inconsistence in the future. The Administrative State model in X.731 defines = three state=20 values (namely: UNLOCKED, LOCKED, and SHUTTING DOWN) and events as shown = below.=20

If=20 you administratively lock a server, the server will enter the "locked" = state.=20 Therefore the server will no longer be able to provide its intended = service (of=20 supporting all its clients). The effect (i.e. impact) on the clients is = no=20 different than a server failure. Usually you don't want to do this. = Instead, you=20 would like to gracefully take the server out of service, i.e. = administratively=20 shut down the server, and by doing so the server will enter the = "shutting down"=20 state. The "shutting down" state is a transition state. When the last = user (in=20 this case the last client service) quit, then the server will = automatically=20 enter the "locked" state. If we are not going to support the Shutting = Down state=20 of the model, then you better either (1) take the clients of the server = LSP out=20 of service before the lock is applied or (2) notify the clients in = advance,=20 otherwise alarms will be raised against the supported client services = because of=20 the unexpected interruption.

 

>

> When a server LSP detects the locked = notification=20 it informs the client

> adaptation that it is no longer receiving = valid=20 traffic.  If the client

> has already been taken out of service = then this is=20 a "don't care".  If

> the client has not been taken out of = service then=20 it should raise an

> alarm.

>

>

> Malcolm Betts

> Nortel Networks

> Phone: +1 613 763 7860 (ESN = 393)

> email: = betts01@nortel.com

>

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

> From:=20 mpls-interop-bounces@ietf.org

> [mailto:mpls-interop-bounces@ietf.org] On = Behalf Of=20 Sprecher, Nurit (NSN

> - IL/Hod HaSharon)

> Sent: Monday, May 04, 2009 3:47=20 AM

> To: hhelvoort@chello.nl;=20 mpls-interop@ietf.org

> Subject: Re: [Mpls-interop] MPLS-TP OAM=20 requirements - Lock and

> notificationof lock

>

> Huub,

> You say " this requires that a MIP has = the=20 capability to send OAM

> messages based on management command or = based on an=20 indication of a MEP

> in a different layer. This also requires = that at=20 every MEP location

> there are also MIPs for every client = entity=20 serviced by that MEP."

> This looks more as an implementation = description.=20 What is actually

> required is that the endpoints of the = client layer=20 are informed of this

> event.

> The way you describe it seems a little = bit=20 "against" the framework in

> which it is specified that OAM messages = cannot be=20 initiated by MIPs.

> That is why we actually say that this is = an=20 adaptation function, that

> means that the message is initiated by = the MEP of=20 the server to the MEP

> of the client.......

> Best regards,

> NUrit

>

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

> From:=20 mpls-interop-bounces@ietf.org

> [mailto:mpls-interop-bounces@ietf.org] On = Behalf Of=20 ext Huub van

> Helvoort

> Sent: Monday, May 04, 2009 10:27=20 AM

> To: = mpls-interop@ietf.org

> Subject: Re: [Mpls-interop] MPLS-TP OAM=20 requirements - Lock and

> notification of lock

>

> Hello Nurit,

>

> You wrote:

>

> > To continue with the othe=20 rquestion:

> >

> >> See also my = e-mail:

> >> MPLS-TP OAM requirements - = AIS/LockNotif -=20 Can MIPs send "usolicited"

>

> >> OAM messages ?

> >

> > The answer was no.

> >

> >> -question:

> >> More generally to the comment = above, who=20 should notify and who should

>

> >> notify whom?

> >> I would tend to = say:

> >> the receiving node of a locked = direction,=20 informs downstream

> receiving

> >> nodes of nested = LSPs.

> >

> > To be more exact, the sink side of a = locked=20 LSP, PW, Section, has to

> > inform its = clients.

>

> You say " To be more exact, the sink side = of a=20 locked LSP, PW, Section,

> has to inform its = clients.",

>

> [hvh] it should inform its client = transport=20 entities in the

> server/client relation

>

> BUT the client is not necessarily=20 an

> endpoint but may be an intermediate = point, and it=20 needs to notify its

> endpoints, that means that a MIP = generates an OAM=20 message.

>

> [hvh this requires that a MIP has the = capability to=20 send OAM messages

> based on management command or based on = an=20 indication of a MEP in a

> different layer.

> This also requires that at every MEP = location there=20 are also MIPs for

> every client entity serviced by that=20 MEP.

>

> Long ago I discussed this point with = Italo and he=20 indicated to me that

> it is not a generation of a message by a = MIP BUT it=20 is a variation of an

> adaptation function at the client = intermediate=20 point. Although we are

> talking here about a way to implement it, = this is a=20 conceptual issue

> that we need to agree = on.

>

> [hvh] I agree with = Italo.

>

> Also, I think we should generalize the = discussion=20 instead of talking

> every time about LSP, PW, section, etc. = we should=20 really talk about

> client/server layers to cover cases of = LSP=20 hierarchies, etc.

>

> [hvh] then I use server/client path/trail = the next=20 time, OK?

>

> Regards, Huub.

>

> >> This is a Fowrward Indication = and if we do=20 so then receiving points

> >> MUST indeed be informed of a = Lock=20 (c.f.

> >> discussion at the beginning of = the=20 e-mail).

> >> Should source points (locking = points) do=20 some reverse indication and

> >> notify the source points of the = LSPs that=20 are nested in the locked

> > LSP?

> >> (but this maybe falls in the RDI = functionality).

> >

> > Isn't this notification already = caused by the=20 locking at the far end?

> > Or is the locking only applied in = one=20 direction of a bi-directional

> > path? If yes, then the notification = is not=20 required.

> >

> > Cheers, Huub.

> >

>

> --

>=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> Always remember that you are = unique...just like=20 everyone else...

>=20 _______________________________________________

> Mpls-interop mailing = list

> Mpls-interop@ietf.org

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

>=20 _______________________________________________

> Mpls-interop mailing = list

> Mpls-interop@ietf.org

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

>=20 _______________________________________________

> Mpls-interop mailing = list

> Mpls-interop@ietf.org

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

------_=_NextPart_002_01C9CD89.410C1FB2-- ------_=_NextPart_001_01C9CD89.410C1FB2 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: <250295113@05052009-0D95> Content-Description: image001.gif Content-Location: image001.gif R0lGODlhBgG0AHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAEAAAAB AbIAgAAAAAAAAAL/hI+py+0Po5y02hOu3rz7D4biFZTZiKbqyragabryTNe2BRvlzff+H4ohdsBi BIZMKpfMpvMJjUqdj1yCaMwyTtourmFVYL3eMfm85Q6FaXTZDd9eze24kW4/75ISfN7m99fFNxEo KGN4CERYqKZY4/g4CMDWFynpkvjBdcKps4Zl1UlJFJZ5aek5gqrIKqJa+in7GZkxioE741oVurIb p+kBS0lcbExcW6ymerrB1gk9dIwkuxeM9ruZa6ucSyvGGTub6dw7rLOMcduNSUpejT6bnrxunL15 v/BcvS8dbz/u0TUO58RNO/btYEAW+cAx43Yl4r9zmAYS7MUPWigh/6M4VmrxsRGpaOiYqWNkslU7 MqYsBVnJC2aWUhYtVpEJBufMk/ds6sTR8CcKOiHBCfV19MellnOSpvDpVJirou6ivgpqVRgvoliz gunqlUTPMVDDijGrqxFNtB32IHvLLS7cuXLr0r1rNy/evXr7YqXGttyUwYQLGz78RGzZwP5ENtMA FsJixk9rRqZQlmrby5SvWkYEVvPFzndEG31cgSk+0jsxc3YJWcVk1i9dg3Ym+zVtrbZRf6m8e1Fq 3ZIjEz8dvEfQ2bBJ5B55PPmR4bdjV055VvoL6r5T5w43zLT2I8ujf4VsXp27W+zHa+sN0vjzifAQ uncOn6F84PTZpf/fXV51+A2VA3v93GedY/Hhxh+CiHC3YIKr/OegPhDqxyCBFT6Yny/7abghhh3O B9R8FKKFnX3ykCeghQtp8lc9IbqoIiopIieiHC/+EmMM4nTEXFKeHLgRRFOduIYDQ671z0jssFhV R/65N2R9QOKyS5DFKYklLe3N09uPbz0pXZVTIgNeTN1JNKYtX4IS5pvtjWfmnG52qSSS6uWU0J3d gKmWNdJQpB1H9VXlpIxNrTnHl+GcRKaaMzbYXI4XXjUpUiNS6h2nmdamoKWdgvjpKpeS+BuppYJa qYcZTriqqZuqOiqsFckUIKN9XKfndzDlGuGAnrWi2iE2aSnpqS//9BqER78qSytmmgJTCbMgQWtr Kohty20UqeAoCbCixtQXX+aWi+65d+Xph7UMYYtpqE6xUmyTt86aLZRWLSWeu9O2iuqWWa0lnr3h wtssvjqB15C/nibrqrxCliTuwQonLPFRdkn77MXLevzrZcgqd1OSbGJcqY94KsNEQvZU+4yhK77Y FkCy/kujwSpuBl86Lvs8jp+KrgjoyzRfdON7Q5VcUtNDo9dzYxApFPRcO5sJT1xynewcLCS5DJ2B Ti7NpZcHRffZntSYBPS6XwPkc11bm4we1uuQpfY2sjF95zIjpz3oym0DahDQU/+Jps6cTW0gRt4U vtBqZSdetOQA/zNuc9V4Qv441XXSE5rjhwf0qM0UZkmTRpGOpqDMLDsyeOamhDG74GcVnJ2zTe+I kjevIPxxxkKlDnwhPFQcMMQTw7krqzQg//B5A+vTr8NkC5+vwPt+lSWuxRfXbsPWA3Jk+B1jb3zk 6wGsMXlLhfz95P0Apnz72tJ9L/oi2Tm69Nu7ljRBQA9q/ulfGtyEwERZI4E+WqACGejABkJwgmMD IO7cMECxWMmAB+yWBz9YL/B5D2RbKaDr0hctAY5Qf8ETVrxitR0S8kxCL4Qhb1houVRlz4YExGF2 5MU4fiWPhy7UHseA2Jic3XBkscog9ZjUOD+ZTTNo29MPiSiZ+P/V6RtGwtvqkrjEjVTwSUwaU4ic yCYjcfF1/nia+hLklradqYCZQqPUprS1ah1KiTWj2Mz0lhE33seOoHibGsc4Jx3FcH17JNPoxpc/ 9tEqH2hboBSnobuxQVIghJQK1yxkCONsMjmdnCHHplIOLPbRh6ZM3yVFUSJVvkpf4wIjPw7FwfrJ snmsZJ0i25jIC+Ivi7t8Yx3cN8y7CapPuQvmznTJNCyW0k5t9JLYePfKE7aqQFNkImmmaaVqUuyE 9ELVFr/YRHDO0ZFmkKMV83VOQZZKnaXjiR/JySdVxdOY84yfL/loyxbe03Wj/Ekp/3nFhKLsk8UM aJ5aVKsaOrT/oc88Zi15uUOKRpOWESuiQDVKzF6mkoYLBelDZYhQkaq0oQcdqUel4s1PtbSHOmxW TOvoT5fWdFkFBRAAIXrEjJoUoNzTUwg72FONiq9XRz3gUCEBwqhKdaqJUepE83nR6dzgpqzhKoCS aj+lgtWgY9VYWRdmUq92Rq1dPStO3LowuK6Erd+U61zTateK5HWue7WYUgrpRxNCpzQUpSvfhmnG hxTBsIHpKdvo0Tl+AlWajvUdV+AUQF30VSCLtSxk/+jYzRqrskH7rOwWK1pjoVYjrN0gApPKWBSl llhWBWlszXJbtuQ2LLMdbWF7K0Dg2kG4edjtwOKornQpN7nM/12uc89FXDhQdbrUpepTr4vd7Gp3 u9ztrne/C97wine85C2vec+L3vSqd73sba970atNmtqLYV/zIkNRqdCIsusl0dXq9dbpuzbprEZK wypGr4bC/0XJLXALhOFsdDLsBNGSBINiAtFEPAYnLokS3B0e+BAzIKVOmFCVkoA9nDO/KTF2Ebnb mQ55uHqScY0IcVw4a7yyE+MtkZPY3IyL9Vg+su12RAsnNUHLOa19WB4/+sjnYAwpHmshbs7snkKS IRHYNUrDUNYxIF+st1yCGZ1VuiYeG9kaa752G5f944nVdqCZcfPMf4pbYGe8uzxj2Gu1UFmBZDZn ebLkvTt9qwdxbXtoERQAADs= ------_=_NextPart_001_01C9CD89.410C1FB2-- From hklam@alcatel-lucent.com Tue May 5 06:56:38 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DBA63A7199 for ; Tue, 5 May 2009 06:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ubnm1mz+NZ2 for ; Tue, 5 May 2009 06:56:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 6AE533A711F for ; Tue, 5 May 2009 06:55:57 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n45DvMjc019871; Tue, 5 May 2009 08:57:22 -0500 (CDT) Received: from ILEXC2U03.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 08:57:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 08:57:20 -0500 Message-ID: In-Reply-To: <4A004034.8000101@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock Thread-Index: AcnNhh1CxAOec+ikQXq+HDL+9rTiOAAAHXjQ References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> <3EC3B42EADEE4472A1C0DEBFFFC22E27@your029b8cecfe> <4A004034.8000101@alcatel-lucent.com> From: "Lam, Hing-Kam \(Kam\)" To: "Martin Vigoureux" X-OriginalArrivalTime: 05 May 2009 13:57:22.0090 (UTC) FILETIME=[697EC8A0:01C9CD89] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:56:38 -0000 Martin, Within the context of notification across layers, the notification = propagates from the MEP of the Locked LSP to the MEPs of the client = layers.=20 If the "Shutting Down" state is supported, one can "Shut down" the = server LSP. The server LSP will enter the "Shutting Down" state and = waiting for all the existing client services to quit. At this time, the = MEP of the server LSP will notify the client layer. Action can then be = taken on the client services (e.g. reroute or delete the service).=20 If the "Shutting Down" state is not supported and there is no advance = notification to the client layer, then the impact of "Lock" the server = LSP on the supported client services is no difference than a server LSP = failure. That is it will cause alarms to be raised against the client = services. Regards, Kam > -----Original Message----- > From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] > Sent: Tuesday, May 05, 2009 9:34 AM > To: Lam, Hing-Kam (Kam) > Cc: Adrian Farrel; mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - > Lockandnotificationof lock >=20 > Kam, >=20 > does this give the complete view? > in other word does the notification stop at the MEP of the Locked > LSP or is it propagated to MEPs of clients layers? >=20 > -m >=20 > Lam, Hing-Kam (Kam) a =E9crit : > > Notification across layers takes place within a node. This is the > > context that my email was responding to. > > > > In a separate email from Malcolm, he mentioned "just notify the far = end > > that the lock is in place and allow the decision ..." This is not = what > > my email was responding to. > > > > I hope I understand your first question correctly. > > > > Regards, > > Kam > > > >> -----Original Message----- > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> Sent: Tuesday, May 05, 2009 6:02 AM > >> To: Lam, Hing-Kam (Kam) > >> Cc: mpls-interop@ietf.org > >> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - > >> Lockandnotificationof lock > >> > >> Am I missing something? > >> Does notification across layers take place within a node or on the > > wire? > >> Thanks, > >> Adrian > >> > >> ----- Original Message ----- > >> From: "Lam, Hing-Kam (Kam)" > >> To: "Malcolm Betts" ; "Sprecher, Nurit (NSN - > > IL/Hod > >> HaSharon)" ; ; > >> ; "Martin Vigoureux" > >> > >> Sent: Tuesday, May 05, 2009 6:51 AM > >> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - > >> Lockandnotificationof > >> lock > >> > >> > >> Dear all, > >> > >> See inline below. I am addressing the issue of notification across > >> layers, not addressing notifying the sink (egress) points. > >> > >> Regards, > >> > >> Kam > >> > >>> -----Original Message----- > >>> From: mpls-interop-bounces@ietf.org > >> [mailto:mpls-interop-bounces@ietf.org] > >>> On Behalf Of Malcolm Betts > >>> Sent: Monday, May 04, 2009 8:42 AM > >>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > >>> mpls-interop@ietf.org > >>> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock > >>> andnotificationof lock > >>> > >>> All, > >>> I think you are making this far too complicated... I see no need = to > >>> propagate the locked indication across layers. > >>> > >>> [Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected > >>> interruption to the client services so that to reduce unnecessary > > alarm > >>> being raised from the client layer. > > > > _______________________________________________ > > Mpls-interop mailing list > > Mpls-interop@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-interop > > From BETTS01@nortel.com Tue May 5 06:59:05 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B88B3A711F for ; Tue, 5 May 2009 06:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjnaEdhe64q0 for ; Tue, 5 May 2009 06:59:04 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 768673A6858 for ; Tue, 5 May 2009 06:59:04 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n45E0Rm23832; Tue, 5 May 2009 14:00:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 10:00:10 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D517038CC8@zcarhxm2.corp.nortel.com> In-Reply-To: <3EC3B42EADEE4472A1C0DEBFFFC22E27@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock Thread-Index: AcnNaTzT+ZlQ2RXGSTiYI3F4ObWo0wAIHqKA References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> <3EC3B42EADEE4472A1C0DEBFFFC22E27@your029b8cecfe> From: "Malcolm Betts" To: "Adrian Farrel" , "Lam, Hing-Kam (Kam)" Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:59:05 -0000 Adrian, By definition it can only take place within a node.=20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, May 05, 2009 6:02 AM To: Lam, Hing-Kam (Kam) Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock Am I missing something? Does notification across layers take place within a node or on the wire? Thanks, Adrian ----- Original Message ----- From: "Lam, Hing-Kam (Kam)" To: "Malcolm Betts" ; "Sprecher, Nurit (NSN - IL/Hod HaSharon)" ; ; ; "Martin Vigoureux" Sent: Tuesday, May 05, 2009 6:51 AM Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock Dear all, See inline below. I am addressing the issue of notification across layers, not addressing notifying the sink (egress) points. Regards, Kam > -----Original Message----- > From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] > On Behalf Of Malcolm Betts > Sent: Monday, May 04, 2009 8:42 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl; > mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock > andnotificationof lock > > All, > I think you are making this far too complicated... I see no need to > propagate the locked indication across layers. > > [Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected > interruption to the client services so that to reduce unnecessary alarm > being raised from the client layer. _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From BETTS01@nortel.com Tue May 5 07:34:32 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A28E28C168 for ; Tue, 5 May 2009 07:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QFBEUBhAsSR for ; Tue, 5 May 2009 07:34:31 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 4267E3A6B91 for ; Tue, 5 May 2009 07:34:31 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n45EYw628947 for ; Tue, 5 May 2009 14:34:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 10:35:48 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D517038DB1@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock Thread-Index: AcnNhh1CxAOec+ikQXq+HDL+9rTiOAAAHXjQAAGSa+A= References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> <3EC3B42EADEE4472A1C0DEBFFFC22E27@your029b8cecfe><4A004034.8000101@alcatel-lucent.com> From: "Malcolm Betts" To: "Lam, Hing-Kam (Kam)" , "Martin Vigoureux" Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:34:32 -0000 Kam, I am not too sure about this. From a NM perspective you are correct, = however how would this work in the data plane. Consider the case of a client LSP A-B-C-D-E-F that uses a server layer = LSP C-D. If the OSS sets the C-D (server) LSP to shutting down:=20 - How does the C-D (server) LSP know that the A-F (Client) LSP has shut = down;=20 - Nodes C & D on LSP A-F can only have MIPs and they cannot read the lock message (as currently defined). - Also how can the C-D (server) LSP notify the A-F (client) LSP that it = has shut down: - Nodes C & D on LSP A-F can only have MIPs and they cannot send spontaneous (locked) messages (as currently defined). =20 Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-interop-bounces@ietf.org = [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam) Sent: Tuesday, May 05, 2009 9:57 AM To: Martin Vigoureux Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - = Lockandnotificationoflock Martin, Within the context of notification across layers, the notification = propagates from the MEP of the Locked LSP to the MEPs of the client = layers.=20 If the "Shutting Down" state is supported, one can "Shut down" the = server LSP. The server LSP will enter the "Shutting Down" state and = waiting for all the existing client services to quit. At this time, the = MEP of the server LSP will notify the client layer. Action can then be = taken on the client services (e.g. reroute or delete the service).=20 If the "Shutting Down" state is not supported and there is no advance = notification to the client layer, then the impact of "Lock" the server = LSP on the supported client services is no difference than a server LSP = failure. That is it will cause alarms to be raised against the client = services. Regards, Kam > -----Original Message----- > From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] > Sent: Tuesday, May 05, 2009 9:34 AM > To: Lam, Hing-Kam (Kam) > Cc: Adrian Farrel; mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements -=20 > Lockandnotificationof lock >=20 > Kam, >=20 > does this give the complete view? > in other word does the notification stop at the MEP of the Locked LSP=20 > or is it propagated to MEPs of clients layers? >=20 > -m >=20 > Lam, Hing-Kam (Kam) a =E9crit : > > Notification across layers takes place within a node. This is the=20 > > context that my email was responding to. > > > > In a separate email from Malcolm, he mentioned "just notify the far=20 > > end that the lock is in place and allow the decision ..." This is=20 > > not what my email was responding to. > > > > I hope I understand your first question correctly. > > > > Regards, > > Kam > > > >> -----Original Message----- > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> Sent: Tuesday, May 05, 2009 6:02 AM > >> To: Lam, Hing-Kam (Kam) > >> Cc: mpls-interop@ietf.org > >> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements -=20 > >> Lockandnotificationof lock > >> > >> Am I missing something? > >> Does notification across layers take place within a node or on the > > wire? > >> Thanks, > >> Adrian > >> > >> ----- Original Message ----- > >> From: "Lam, Hing-Kam (Kam)" > >> To: "Malcolm Betts" ; "Sprecher, Nurit (NSN - > > IL/Hod > >> HaSharon)" ; ;=20 > >> ; "Martin Vigoureux" > >> > >> Sent: Tuesday, May 05, 2009 6:51 AM > >> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements -=20 > >> Lockandnotificationof lock > >> > >> > >> Dear all, > >> > >> See inline below. I am addressing the issue of notification across=20 > >> layers, not addressing notifying the sink (egress) points. > >> > >> Regards, > >> > >> Kam > >> > >>> -----Original Message----- > >>> From: mpls-interop-bounces@ietf.org > >> [mailto:mpls-interop-bounces@ietf.org] > >>> On Behalf Of Malcolm Betts > >>> Sent: Monday, May 04, 2009 8:42 AM > >>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;=20 > >>> mpls-interop@ietf.org > >>> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock=20 > >>> andnotificationof lock > >>> > >>> All, > >>> I think you are making this far too complicated... I see no need=20 > >>> to propagate the locked indication across layers. > >>> > >>> [Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected=20 > >>> interruption to the client services so that to reduce unnecessary > > alarm > >>> being raised from the client layer. > > > > _______________________________________________ > > Mpls-interop mailing list > > Mpls-interop@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-interop > > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From hklam@alcatel-lucent.com Tue May 5 08:15:35 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633993A6CFA for ; Tue, 5 May 2009 08:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYdCBA+0P01k for ; Tue, 5 May 2009 08:15:27 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 665293A6781 for ; Tue, 5 May 2009 08:15:27 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n45FFnMH001008; Tue, 5 May 2009 10:16:52 -0500 (CDT) Received: from ILEXC2U03.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 10:16:09 -0500 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_01C9CD94.6AC0AEAC" Date: Tue, 5 May 2009 10:16:08 -0500 Message-ID: In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D517038DB1@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock Thread-Index: AcnNhh1CxAOec+ikQXq+HDL+9rTiOAAAHXjQAAGSa+AAAURGMA== References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> <3EC3B42EADEE4472A1C0DEBFFFC22E27@your029b8cecfe><4A004034.8000101@alcatel-lucent.com> <0BDFFF51DC89434FA33F8B37FCE363D517038DB1@zcarhxm2.corp.nortel.com> From: "Lam, Hing-Kam \(Kam\)" To: "Malcolm Betts" , "VIGOUREUX, MARTIN \(MARTIN\)" X-OriginalArrivalTime: 05 May 2009 15:16:09.0532 (UTC) FILETIME=[6B452FC0:01C9CD94] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 15:15:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CD94.6AC0AEAC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Malcolm, =20 How this would work is a solution issue or even an implementation issue. Fortunately the MIP of LSP A-F at Node C and the MEP of LSP CD at Node C = are in the same node (Node C). Similarly the MIP of LSP A-F at Node D and the MEP of LSP CD at Node D = are in the same node (Node D). This may help in finding a solution. =20 But I think it is reasonable to have a requirement to avoid unnecessary = alarm against the client services due to the server LSP's entering the = Locked state. =20 Regards, Kam=20 =20 > -----Original Message----- > From: Malcolm Betts [mailto:betts01@nortel.com] > Sent: Tuesday, May 05, 2009 10:36 AM > To: Lam, Hing-Kam (Kam); VIGOUREUX, MARTIN (MARTIN) > Cc: mpls-interop@ietf.org > Subject: RE: [Mpls-interop] MPLS-TP OAM requirements - > Lockandnotificationoflock >=20 > Kam, >=20 > I am not too sure about this. From a NM perspective you are correct, > however how would this work in the data plane. >=20 > Consider the case of a client LSP A-B-C-D-E-F that uses a server layer = LSP > C-D. >=20 > If the OSS sets the C-D (server) LSP to shutting down: > - How does the C-D (server) LSP know that the A-F (Client) LSP has = shut > down; > - Nodes C & D on LSP A-F can only have MIPs and they cannot > read the lock message (as currently defined). > - Also how can the C-D (server) LSP notify the A-F (client) LSP that = it > has shut down: > - Nodes C & D on LSP A-F can only have MIPs and they cannot > send spontaneous (locked) messages (as currently defined). >=20 >=20 > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com >=20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org = [mailto:mpls-interop-bounces@ietf.org] > On Behalf Of Lam, Hing-Kam (Kam) > Sent: Tuesday, May 05, 2009 9:57 AM > To: Martin Vigoureux > Cc: mpls-interop@ietf.org > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - > Lockandnotificationoflock >=20 > Martin, >=20 > Within the context of notification across layers, the notification > propagates from the MEP of the Locked LSP to the MEPs of the client = layers. >=20 > If the "Shutting Down" state is supported, one can "Shut down" the = server > LSP. The server LSP will enter the "Shutting Down" state and waiting = for > all the existing client services to quit. At this time, the MEP of the > server LSP will notify the client layer. Action can then be taken on = the > client services (e.g. reroute or delete the service). >=20 > If the "Shutting Down" state is not supported and there is no advance > notification to the client layer, then the impact of "Lock" the server = LSP > on the supported client services is no difference than a server LSP > failure. That is it will cause alarms to be raised against the client > services. >=20 > Regards, > Kam >=20 > > -----Original Message----- > > From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] > > Sent: Tuesday, May 05, 2009 9:34 AM > > To: Lam, Hing-Kam (Kam) > > Cc: Adrian Farrel; mpls-interop@ietf.org > > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - > > Lockandnotificationof lock > > > > Kam, > > > > does this give the complete view? > > in other word does the notification stop at the MEP of the Locked = LSP > > or is it propagated to MEPs of clients layers? > > > > -m > > > > Lam, Hing-Kam (Kam) a =E9crit : > > > Notification across layers takes place within a node. This is the > > > context that my email was responding to. > > > > > > In a separate email from Malcolm, he mentioned "just notify the = far > > > end that the lock is in place and allow the decision ..." This is > > > not what my email was responding to. > > > > > > I hope I understand your first question correctly. > > > > > > Regards, > > > Kam > > > > > >> -----Original Message----- > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> Sent: Tuesday, May 05, 2009 6:02 AM > > >> To: Lam, Hing-Kam (Kam) > > >> Cc: mpls-interop@ietf.org > > >> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - > > >> Lockandnotificationof lock > > >> > > >> Am I missing something? > > >> Does notification across layers take place within a node or on = the > > > wire? > > >> Thanks, > > >> Adrian > > >> > > >> ----- Original Message ----- > > >> From: "Lam, Hing-Kam (Kam)" > > >> To: "Malcolm Betts" ; "Sprecher, Nurit (NSN - > > > IL/Hod > > >> HaSharon)" ; ; > > >> ; "Martin Vigoureux" > > >> > > >> Sent: Tuesday, May 05, 2009 6:51 AM > > >> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - > > >> Lockandnotificationof lock > > >> > > >> > > >> Dear all, > > >> > > >> See inline below. I am addressing the issue of notification = across > > >> layers, not addressing notifying the sink (egress) points. > > >> > > >> Regards, > > >> > > >> Kam > > >> > > >>> -----Original Message----- > > >>> From: mpls-interop-bounces@ietf.org > > >> [mailto:mpls-interop-bounces@ietf.org] > > >>> On Behalf Of Malcolm Betts > > >>> Sent: Monday, May 04, 2009 8:42 AM > > >>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); = hhelvoort@chello.nl; > > >>> mpls-interop@ietf.org > > >>> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock > > >>> andnotificationof lock > > >>> > > >>> All, > > >>> I think you are making this far too complicated... I see no = need > > >>> to propagate the locked indication across layers. > > >>> > > >>> [Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected > > >>> interruption to the client services so that to reduce = unnecessary > > > alarm > > >>> being raised from the client layer. > > > > > > _______________________________________________ > > > Mpls-interop mailing list > > > Mpls-interop@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-interop > > > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_001_01C9CD94.6AC0AEAC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Malcolm,

 

How this would work is a solution issue or even an = implementation issue.

Fortunately the MIP of LSP = A-F at Node C and the MEP of LSP CD = at Node C are in the same node (Node C).

Similarly the MIP of LSP A-F = at Node D and the MEP of LSP CD at Node = D are in the same node (Node D).

This may help in finding a = solution.

 

But I think it is reasonable to have a requirement to avoid = unnecessary alarm against the client services due to the server LSP’s entering = the Locked state.

 

Regards,

Kam

 

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

> From: Malcolm Betts = [mailto:betts01@nortel.com]

> Sent: Tuesday, May 05, 2009 10:36 AM

> To: Lam, = Hing-Kam (Kam); VIGOUREUX, MARTIN = (MARTIN)

> Cc: mpls-interop@ietf.org

> Subject: RE: [Mpls-interop] MPLS-TP OAM requirements = -

> Lockandnotificationoflock

>

> Kam,

>

> I am not too sure about this.=A0 From a NM perspective you = are correct,

> however how would this work in the data = plane.

>

> Consider the case of a client LSP A-B-C-D-E-F that uses a = server layer LSP

> C-D.

>

> If the OSS sets the C-D (server) LSP to shutting down:

> - How does the C-D (server) LSP know that the A-F (Client) = LSP has shut

> down;

> =A0=A0=A0- Nodes C & D on LSP A-F can only have MIPs = and they cannot

> =A0=A0=A0=A0=A0read the lock message (as currently = defined).

> - Also how can the C-D (server) LSP notify the A-F (client) = LSP that it

> has shut down:

> =A0=A0=A0- Nodes C & D on LSP A-F can only have MIPs = and they cannot

> =A0=A0=A0=A0=A0send spontaneous (locked) messages (as = currently defined).

>

>

> Malcolm Betts

> Nortel Networks

> Phone: +1 613 763 7860 (ESN 393)

> email: betts01@nortel.com

>

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

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

> On Behalf Of Lam, = Hing-Kam (Kam)

> Sent: Tuesday, May 05, 2009 9:57 AM

> To: Martin Vigoureux

> Cc: mpls-interop@ietf.org

> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements = -

> Lockandnotificationoflock

>

> Martin,

>

> Within the context of notification across layers, the = notification

> propagates from the MEP of the Locked LSP to the MEPs of = the client layers.

>

> If the "Shutting Down" state is supported, one = can "Shut down" the server

> LSP. The server LSP will enter the "Shutting = Down" state and waiting for

> all the existing client services to quit. At this time, the = MEP of the

> server LSP will notify the client layer. Action can then be = taken on the

> client services (e.g. reroute or delete the = service).

>

> If the "Shutting Down" state is not supported and = there is no advance

> notification to the client layer, then the impact of "Lock" the server LSP

> on the supported client services is no difference than a = server LSP

> failure. That is it will cause alarms to be raised against = the client

> services.

>

> Regards,

> Kam

>

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

> > From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com]

> > Sent: Tuesday, May 05, 2009 9:34 AM

> > To: Lam, = Hing-Kam (Kam)

> > Cc: Adrian Farrel; = mpls-interop@ietf.org

> > Subject: Re: [Mpls-interop] MPLS-TP OAM requirements = -

> > Lockandnotificationof lock

> >

> > Kam,

> >

> > does this give the complete view?

> > in other word does the notification stop at the MEP of = the Locked LSP

> > or is it propagated to MEPs of clients = layers?

> >

> > -m

> >

> > Lam, = Hing-Kam (Kam) a =E9crit :

> > > Notification across layers takes place within a = node. This is the

> > > context that my email was responding = to.

> > >

> > > In a separate email from Malcolm, he mentioned "just notify the far

> > > end that the lock is in place and allow the = decision ..." This is

> > > not what my email was responding = to.

> > >

> > > I hope I understand your first question = correctly.

> > >

> > > Regards,

> > > Kam

> > >

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

> > >> From: Adrian Farrel = [mailto:adrian@olddog.co.uk]

> > >> Sent: Tuesday, May 05, 2009 6:02 = AM

> > >> To: Lam, = Hing-Kam (Kam)

> > >> Cc: mpls-interop@ietf.org

> > >> Subject: Re: [Mpls-interop] MPLS-TP OAM = requirements -

> > >> Lockandnotificationof lock

> > >>

> > >> Am I missing something?

> > >> Does notification across layers take place = within a node or on the

> > > wire?

> > >> Thanks,

> > >> Adrian

> > >>

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

> > >> From: "Lam, = Hing-Kam (Kam)" <hklam@alcatel-lucent.com>

> > >> To: "Malcolm Betts" <betts01@nortel.com>; "Sprecher, Nurit (NSN = -

> > > IL/Hod

> > >> HaSharon)" = <nurit.sprecher@nsn.com>; <hhelvoort@chello.nl>;

> > >> <mpls-interop@ietf.org>; "Martin Vigoureux"

> > >> = <martin.vigoureux@alcatel-lucent.com>

> > >> Sent: Tuesday, May 05, 2009 6:51 = AM

> > >> Subject: Re: [Mpls-interop] MPLS-TP OAM = requirements -

> > >> Lockandnotificationof lock

> > >>

> > >>

> > >> Dear all,

> > >>

> > >> See inline below. I am addressing the issue = of notification across

> > >> layers, not addressing notifying the sink = (egress) points.

> > >>

> > >> Regards,

> > >>

> > >> Kam

> > >>

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

> > >>> From: = mpls-interop-bounces@ietf.org

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

> > >>> On Behalf Of Malcolm = Betts

> > >>> Sent: Monday, May 04, 2009 8:42 = AM

> > >>> To: Sprecher, Nurit (NSN - IL/Hod = HaSharon); hhelvoort@chello.nl;

> > >>> mpls-interop@ietf.org

> > >>> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock

> > >>> andnotificationof lock

> > >>>

> > >>> All,

> > >>> I think you are making this far too complicated...=A0 I see no need

> > >>> to propagate the locked indication across layers.

> > >>>

> > >>> [Lam, = Hing-Kam (Kam)] The bottom line is to avoid unexpected

> > >>> interruption to the client services so = that to reduce unnecessary

> > > alarm

> > >>> being raised from the client = layer.

> > >

> > > = _______________________________________________

> > > Mpls-interop mailing list

> > > Mpls-interop@ietf.org

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

> > >

> = _______________________________________________

> Mpls-interop mailing list

> Mpls-interop@ietf.org

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

------_=_NextPart_001_01C9CD94.6AC0AEAC-- From adrian@olddog.co.uk Wed May 6 05:19:22 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10AA53A6F18 for ; Wed, 6 May 2009 05:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.936 X-Spam-Level: X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0IzlS58orDS for ; Wed, 6 May 2009 05:19:21 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 0ADCF3A71C9 for ; Wed, 6 May 2009 05:15:06 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n46CGVc1004309 for ; Wed, 6 May 2009 13:16:32 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n46CGSDL004219 for ; Wed, 6 May 2009 13:16:30 +0100 Message-ID: <73632CCC731C496AACD41C4DEA306288@your029b8cecfe> From: "Adrian Farrel" To: References: <077E41CFFD002C4CAB7DFA4386A53264AB4B6B@DEMUEXC014.nsn-intra.net> <4A0157B1.5050408@chello.nl> Date: Wed, 6 May 2009 13:16:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Mpls-interop] Local and Remote X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 12:19:22 -0000 I know that Malcolm and Huub are going to work on the definition of local and remote. Huub usefully typed during the meeting yesterday that "remote" might be better stated as "non-local." Watching some emails this morning, I wonder whether part of the confusion arises from - where the fault is detected - where the fault exists A node can (IMHO) only be detected locally. That is local to the point of detection. A fault may be reported (to the management plane) from the node of detection (a local report), or may be signaled to another node (through the OAM or control plane) and reported (to the management plane) from that other node (a remote report). The fault that is detected may be in the detecting node, or in a resource directly connected to that node (such as a link). This is a local fault. But the fault may also exist in a node or resource that is not local to the detecting node. This is a remote fault. If an LSP continuity check fails, the fault is detected by an end point (local detection), but the fault might be somewhere out in the network (remote fault). When a server layer provides a connection that is used as a link in the client layer, a server layer fault (that is remote in the server layer) may be reported to the client layer as a fault in the client layer link (that is local in the client layer). The client layer does not know about the route or resources used in the server layer (we MUST assume clean layer separation) so the client layer does not need to know about the location of the server layer remote fault. If the client layer requests the server layer to repair the client layer link (i.e. to repair the server layer connection) the server layer may need to consider the location of the server layer fault. Am I wrong? Is this really so complicated? Thanks, Adrian From nurit.sprecher@nsn.com Wed May 6 05:58:17 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D463A6F53 for ; Wed, 6 May 2009 05:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eR136cNv9-VP for ; Wed, 6 May 2009 05:58:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D35123A6EC5 for ; Wed, 6 May 2009 05:56:10 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n46Cvajo003279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2009 14:57:36 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n46CvZqU021576; Wed, 6 May 2009 14:57:36 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.26]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 14:57:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CE4A.38D6F2E5" Date: Wed, 6 May 2009 14:57:31 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264AB5129@DEMUEXC014.nsn-intra.net> In-Reply-To: <73632CCC731C496AACD41C4DEA306288@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] Local and Remote Thread-Index: AcnORRlyJibQZu/1QUS+nytVL7Z/kAAAVKdg References: <077E41CFFD002C4CAB7DFA4386A53264AB4B6B@DEMUEXC014.nsn-intra.net><4A0157B1.5050408@chello.nl> <73632CCC731C496AACD41C4DEA306288@your029b8cecfe> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "Adrian Farrel" , X-OriginalArrivalTime: 06 May 2009 12:57:35.0567 (UTC) FILETIME=[3A2C8DF0:01C9CE4A] Subject: Re: [Mpls-interop] Local and Remote X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 12:58:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CE4A.38D6F2E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the great clarification. I am sorry for bothering but I still have some questions: * We have a requirement in the document for "Remote Defect Indication" and it specifies that "The MPLS-TP OAM toolset MUST provide a function to enable an End Point to notify its associated End Point of the detection of a fault or defect that it detects on a PW, LSP or Section between them." I.e. in the requirement refers to remote as to the associated endpoint at the same layer! * I would like to refer to the last paragraph in your e-mail: "" When a server layer provides a connection that is used as a link in the client layer, a server layer fault (that is remote in the server layer) may be reported to the client layer as a fault in the client layer link (that is local in the client layer)...." Assuming that we have an LSP that traversed nodes A-B-C-D-E-F-G and we have a fault in the link between D and E. according to the above the server layer needs to notify the client layer. Is it to the client layer in nodes D and E or to the endpoints of the client layers, i.e. nodes A and G? If it is node D and E (this is local) they need now to notify nodes A and G, but according to the requirement document and to the framework they may be MIPs of the LSPs but they cannot initiate OAM messages. Therefore, it seems that the endpoint of the server layer needs to notify the endpoint of the client layers of the fault (remote). And IMO we need to be clear about the requirement. And also to extend the definition in the first bullet for remote (not necessarily endpoint).=20 * Assuming that the failure is in the first (server) link. As a result we have loss of continuity in the LSPs that transmit over this failed link and in the PWs that are attached to these LSPs. As I understand from your definition, as these fault are detected by the endpoint (to which the link is attached), all these faults are considered locals!. Is there still a requirement to distinguish between these failures? Note that all of these are now local.=20 I'll appreciate your further clarification. Best regards, Nurit =20 -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Adrian Farrel Sent: Wednesday, May 06, 2009 3:16 PM To: mpls-interop@ietf.org Subject: [Mpls-interop] Local and Remote =20 I know that Malcolm and Huub are going to work on the definition of local=20 and remote. =20 Huub usefully typed during the meeting yesterday that "remote" might be=20 better stated as "non-local." =20 Watching some emails this morning, I wonder whether part of the confusion=20 arises from - where the fault is detected - where the fault exists =20 A node can (IMHO) only be detected locally. That is local to the point of=20 detection. =20 A fault may be reported (to the management plane) from the node of detection=20 (a local report), or may be signaled to another node (through the OAM or control plane) and reported (to the management plane) from that other node=20 (a remote report). =20 The fault that is detected may be in the detecting node, or in a resource=20 directly connected to that node (such as a link). This is a local fault. =20 But the fault may also exist in a node or resource that is not local to the=20 detecting node. This is a remote fault. =20 If an LSP continuity check fails, the fault is detected by an end point=20 (local detection), but the fault might be somewhere out in the network=20 (remote fault). =20 When a server layer provides a connection that is used as a link in the=20 client layer, a server layer fault (that is remote in the server layer) may=20 be reported to the client layer as a fault in the client layer link (that is=20 local in the client layer). The client layer does not know about the route=20 or resources used in the server layer (we MUST assume clean layer=20 separation) so the client layer does not need to know about the location of=20 the server layer remote fault. If the client layer requests the server layer=20 to repair the client layer link (i.e. to repair the server layer connection)=20 the server layer may need to consider the location of the server layer=20 fault. =20 Am I wrong? Is this really so complicated? =20 Thanks, Adrian=20 =20 =20 _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_001_01C9CE4A.38D6F2E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for the great clarification.

I am sorry for bothering but I still have some = questions:

·         =
We have a requirement in the document for "Remote Defect =
Indication" and it specifies that "The MPLS-TP OAM toolset =
MUST provide a function to enable an End Point to notify its associated End =
Point of the detection of a fault or defect that it detects =
on a PW, LSP or Section between them." I.e. in the =
requirement refers to remote as to the associated endpoint at the same =
layer!

·         I would = like to refer to the last paragraph in your e-mail: "" When a server = layer provides a connection that is used as a link in the client layer, a = server layer fault (that is remote in the server layer) may be reported to the = client layer as a fault in the client layer = link (that is local in the client layer)…." Assuming that we have = an LSP that traversed nodes A-B-C-D-E-F-G and we have a fault in the link = between D and E. according to the above the server layer needs to notify the = client layer. Is it to the client layer in nodes D and E or to the endpoints of = the client layers, i.e. nodes A and G? If it is node D and E (this is local) = they need now to notify nodes A and G, but according to the requirement = document and to the framework they may be MIPs of the LSPs but they cannot initiate = OAM messages. Therefore, it seems that the endpoint of the server layer = needs to notify the endpoint of the client layers of the fault (remote). And IMO = we need to be clear about the requirement. And also to extend the definition in = the first bullet for remote (not necessarily endpoint). =

·         Assuming = that the failure is in the first (server) link. As a result we have loss of = continuity in the LSPs that transmit over this failed link and in the PWs that are attached to these LSPs. As I understand from your definition, as these = fault are detected by the endpoint (to which the link is attached), all these = faults are considered locals!. Is there still a requirement to distinguish = between these failures? Note that all of these are now local. =

I'll appreciate your further = clarification.

Best regards,

Nurit

 

-----Original Message-----
From: mpls-interop-bounces@ietf.org = [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Adrian Farrel
Sent: Wednesday, May 06, 2009 3:16 PM
To: mpls-interop@ietf.org
Subject: [Mpls-interop] Local and Remote

 

I know that Malcolm and Huub are going to work on the definition = of local

and remote.

 

Huub usefully typed during the meeting yesterday that "remote" might be

better stated as = "non-local."

 

Watching some emails this morning, I wonder whether part of the confusion

arises from

- where the fault is detected

- where the fault exists

 

A node can (IMHO) only be detected locally. That is local to the = point of

detection.

 

A fault may be reported (to the management plane) from the node = of detection

(a local report), or may be signaled to another node (through = the OAM or

control plane) and reported (to the management plane) from that = other node

(a remote report).

 

The fault that is detected may be in the detecting node, or in a resource

directly connected to that node (such as a link). This is a = local fault.

 

But the fault may also exist in a node or resource that is not = local to the

detecting node. This is a remote = fault.

 

If an LSP continuity check fails, the fault is detected by an = end point

(local detection), but the fault might be somewhere out in the = network

(remote fault).

 

When a server layer provides a connection that is used as a link = in the

client layer, a server layer fault (that is remote in the server = layer) may

be reported to the client layer as a fault in the client layer = link (that is

local in the client layer). The client layer does not know about = the route

or resources used in the server layer (we MUST assume clean = layer

separation) so the client layer does not need to know about the location of

the server layer remote fault. If the client layer requests the = server layer

to repair the client layer link (i.e. to repair the server layer = connection)

the server layer may need to consider the location of the server = layer

fault.

 

Am I wrong?

Is this really so complicated?

 

Thanks,

Adrian

 

 

_______________________________________________=

Mpls-interop mailing list

Mpls-interop@ietf.org

https://www.ietf.org/mailman/listinfo/mpls-interop

------_=_NextPart_001_01C9CE4A.38D6F2E5-- From hhelvoort@chello.nl Wed May 6 06:42:38 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165283A6DE7 for ; Wed, 6 May 2009 06:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wg4fVkYAo0d9 for ; Wed, 6 May 2009 06:42:31 -0700 (PDT) Received: from viefep14-int.chello.at (viefep14-int.chello.at [62.179.121.34]) by core3.amsl.com (Postfix) with ESMTP id 81BE03A6923 for ; Wed, 6 May 2009 06:41:26 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep14-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090506134252.GJMF10055.viefep14-int.chello.at@edge01.upc.biz> for ; Wed, 6 May 2009 15:42:52 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge01.upc.biz with edge id oDiq1b05t3KDBhC01Dirqk; Wed, 06 May 2009 15:42:52 +0200 X-SourceIP: 24.132.228.153 Message-ID: <4A0193DA.3020805@chello.nl> Date: Wed, 06 May 2009 15:42:50 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mpls-interop@ietf.org References: <077E41CFFD002C4CAB7DFA4386A53264AB4B6B@DEMUEXC014.nsn-intra.net><4A0157B1.5050408@chello.nl> <73632CCC731C496AACD41C4DEA306288@your029b8cecfe> <077E41CFFD002C4CAB7DFA4386A53264AB5129@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264AB5129@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Mpls-interop] Local and Remote X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:42:38 -0000 Hi Nurit, You replied: > Thanks for the great clarification. > > I am sorry for bothering but I still have some questions: [hvh] OK. > · We have a requirement in the document for "Remote Defect > Indication" and it specifies that "The MPLS-TP OAM toolset MUST > provide a function to enable an *End Point to notify its associated > End Point* of the detection of a fault or defect that it detects *on > a PW, LSP or Section* *between them*." I.e. in the requirement refers > to remote as to the associated endpoint *at the same layer*! [hvh] in the example: A-B=C=D-E-F-G if the sink MEP in node G detects a service affecting defect it informs the co-located source MEP and the source MEP in node G transmits RDI towards node A. The RDI is detected by the sink MEP in node A and will interpret this as node G has detected a service affecting defect. For the sink MEP in node A the sink MEP in node G is the */_remote_/*. > · I would like to refer to the last paragraph in your e-mail: "" When > a server layer provides a connection that is used as a link in the > client layer, a server layer fault (that is remote in the server > layer) may be reported to the client layer *as a fault in the client > layer link* (that is local in the client layer)…." Assuming that we > have an LSP that traversed nodes A-B-C-D-E-F-G and we have a fault in > the link between D and E. according to the above the server layer > needs to notify the client layer. Is it to the client layer in nodes > D and E or to the endpoints of the client layers, i.e. nodes A and G? > [hvh] you did not indicate where the server layer starts and ends, I have assumed between D and E. [hvh] the end points (i.e. the sink MEPs) in A and G have to be notified. How this is done is a solution. > If it is node D and E (this is local) they need now to notify nodes A > and G, [hvh] I assume the you mean the link failure is in both directions, and the server layer is betwen D and E. In that case E has to inform G for traffic flowing from A to G, and D has to inform A for traffic flowing from G to A. > but according to the requirement document and to the framework they > may be MIPs of the LSPs but they cannot initiate OAM messages. [hvh] if my assumptions above are right there are (server) MEPs in D and E. If my assumptio is wrong and you are referring to s single LSP, a link fault between D and E will be detected by G: loss of CC without a notification from a server. > Therefore, it seems that the endpoint of the server layer needs to > notify the endpoint of the client layers of the fault (remote). [hvh] and how that is achieved is a solution. > And IMO we need to be clear about the requirement. And also to extend > the definition in the first bullet for remote (not necessarily > endpoint). [hvh] I hope the explanation above makes clear what the purpose is of RDI and where it is generated. > · Assuming that the failure is in the first (server) link. As > a result we have loss of continuity in the LSPs that transmit over > this failed link and in the PWs that are attached to these LSPs. As I > understand from your definition, as these fault are detected by the > endpoint (to which the link is attached), all these faults are > considered locals!. Is there still a requirement to distinguish > between these failures? Note that all of these are now local. [hvh] if the first link (A-B) is a server link, then in A there are two MEPs: one for the LSP and one for the server trail. The MEP in the server trail will detect the defect and will inform the MEP of the LSP, according to the requirement. For the MEP in the server trail the defect is local, for the MEP in the LSp the defect is remote. > I'll appreciate your further clarification. [hvh] I hope the above helped ;-) Kind regards, Huub. > -----Original Message----- From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Adrian Farrel > Sent: Wednesday, May 06, 2009 3:16 PM To: mpls-interop@ietf.org > Subject: [Mpls-interop] Local and Remote > > > > I know that Malcolm and Huub are going to work on the definition of > local > > and remote. > > > > Huub usefully typed during the meeting yesterday that "remote" might > be > > better stated as "non-local." > > > > Watching some emails this morning, I wonder whether part of the > confusion > > arises from > > - where the fault is detected > > - where the fault exists > > > > A node can (IMHO) only be detected locally. That is local to the > point of > > detection. > > > > A fault may be reported (to the management plane) from the node of > detection > > (a local report), or may be signaled to another node (through the OAM > or > > control plane) and reported (to the management plane) from that other > node > > (a remote report). > > > > The fault that is detected may be in the detecting node, or in a > resource > > directly connected to that node (such as a link). This is a local > fault. > > > > But the fault may also exist in a node or resource that is not local > to the > > detecting node. This is a remote fault. > > > > If an LSP continuity check fails, the fault is detected by an end > point > > (local detection), but the fault might be somewhere out in the > network > > (remote fault). > > > > When a server layer provides a connection that is used as a link in > the > > client layer, a server layer fault (that is remote in the server > layer) may > > be reported to the client layer as a fault in the client layer link > (that is > > local in the client layer). The client layer does not know about the > route > > or resources used in the server layer (we MUST assume clean layer > > separation) so the client layer does not need to know about the > location of > > the server layer remote fault. If the client layer requests the > server layer > > to repair the client layer link (i.e. to repair the server layer > connection) > > the server layer may need to consider the location of the server > layer > > fault. > > > > Am I wrong? > > Is this really so complicated? > > > > Thanks, > > Adrian > > > > > > _______________________________________________ > > Mpls-interop mailing list > > Mpls-interop@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-interop > > > ------------------------------------------------------------------------ > > > > _______________________________________________ Mpls-interop mailing > list Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From nurit.sprecher@nsn.com Wed May 6 07:05:56 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531703A6BAD for ; Wed, 6 May 2009 07:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdWT21bt6BFa for ; Wed, 6 May 2009 07:05:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 46FCF3A6EB3 for ; Wed, 6 May 2009 07:04:42 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n46E654K031740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2009 16:06:05 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n46E65Mv032762; Wed, 6 May 2009 16:06:05 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.26]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 16:06:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CE53.CB32C815" Date: Wed, 6 May 2009 16:06:02 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264AB520B@DEMUEXC014.nsn-intra.net> In-Reply-To: <4A0193DA.3020805@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] Local and Remote Thread-Index: AcnOULxUOCX9OUBHQYqSjmrcRvdl0AAAh+sw References: <077E41CFFD002C4CAB7DFA4386A53264AB4B6B@DEMUEXC014.nsn-intra.net><4A0157B1.5050408@chello.nl> <73632CCC731C496AACD41C4DEA306288@your029b8cecfe><077E41CFFD002C4CAB7DFA4386A53264AB5129@DEMUEXC014.nsn-intra.net> <4A0193DA.3020805@chello.nl> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , X-OriginalArrivalTime: 06 May 2009 14:06:05.0109 (UTC) FILETIME=[CBA6E650:01C9CE53] Subject: Re: [Mpls-interop] Local and Remote X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:05:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CE53.CB32C815 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Huub, [hvh] you did not indicate where the server layer starts and ends, I have assumed between D and E. Right.=20 =20 [hvh] the end points (i.e. the sink MEPs) in A and G have to be notified. How this is done is a solution. but we have a requirement to notify them! We need to specify this requirement exactly as we specified RDI. Please refer to my proposal.=20 =20 [hvh] I assume the you mean the link failure is in both directions, and the server layer is between D and E. In that case E has to inform G for traffic flowing from A to G, and D has to inform A for traffic flowing from G to A. so as said above we have a requirement to notify the endpoints. As this "pass on the wire" is should be specified, it is not done by a magic. The requirement is from the endpoints of the server layer to notify the endpoint of the clients.....again please refer to my proposal. Best regards, NUrit =20 =20 =20 =20 -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Huub van Helvoort Sent: Wednesday, May 06, 2009 4:43 PM To: mpls-interop@ietf.org Subject: Re: [Mpls-interop] Local and Remote =20 Hi Nurit, =20 You replied: =20 > Thanks for the great clarification. >=20 > I am sorry for bothering but I still have some questions: =20 [hvh] OK. =20 > * We have a requirement in the document for "Remote Defect=20 > Indication" and it specifies that "The MPLS-TP OAM toolset MUST=20 > provide a function to enable an *End Point to notify its associated=20 > End Point* of the detection of a fault or defect that it detects *on=20 > a PW, LSP or Section* *between them*." I.e. in the requirement refers > to remote as to the associated endpoint *at the same layer*! =20 [hvh] in the example: A-B=3DC=3DD-E-F-G if the sink MEP in node G = detects a service affecting defect it informs the co-located source MEP and the source MEP in node G transmits RDI towards node A. The RDI is detected by the sink MEP in node A and will interpret this as node G has detected a service affecting defect. For the sink MEP in node A the sink MEP in node G is the */_remote_/*. =20 > * I would like to refer to the last paragraph in your e-mail: "" When > a server layer provides a connection that is used as a link in the=20 > client layer, a server layer fault (that is remote in the server=20 > layer) may be reported to the client layer *as a fault in the client=20 > layer link* (that is local in the client layer)...." Assuming that we=20 > have an LSP that traversed nodes A-B-C-D-E-F-G and we have a fault in > the link between D and E. according to the above the server layer=20 > needs to notify the client layer. Is it to the client layer in nodes=20 > D and E or to the endpoints of the client layers, i.e. nodes A and G? >=20 [hvh] you did not indicate where the server layer starts and ends, I have assumed between D and E. =20 [hvh] the end points (i.e. the sink MEPs) in A and G have to be notified. How this is done is a solution. =20 > If it is node D and E (this is local) they need now to notify nodes A > and G, =20 [hvh] I assume the you mean the link failure is in both directions, and the server layer is betwen D and E. In that case E has to inform G for traffic flowing from A to G, and D has to inform A for traffic flowing from G to A. =20 > but according to the requirement document and to the framework they > may be MIPs of the LSPs but they cannot initiate OAM messages. =20 [hvh] if my assumptions above are right there are (server) MEPs in D and E. If my assumptio is wrong and you are referring to s single LSP, a link fault between D and E will be detected by G: loss of CC without a notification from a server. =20 > Therefore, it seems that the endpoint of the server layer needs to=20 > notify the endpoint of the client layers of the fault (remote). =20 [hvh] and how that is achieved is a solution. =20 > And IMO we need to be clear about the requirement. And also to extend > the definition in the first bullet for remote (not necessarily > endpoint). =20 [hvh] I hope the explanation above makes clear what the purpose is of RDI and where it is generated. =20 > * Assuming that the failure is in the first (server) link. As > a result we have loss of continuity in the LSPs that transmit over=20 > this failed link and in the PWs that are attached to these LSPs. As I > understand from your definition, as these fault are detected by the=20 > endpoint (to which the link is attached), all these faults are=20 > considered locals!. Is there still a requirement to distinguish=20 > between these failures? Note that all of these are now local. =20 [hvh] if the first link (A-B) is a server link, then in A there are two MEPs: one for the LSP and one for the server trail. The MEP in the server trail will detect the defect and will inform the MEP of the LSP, according to the requirement. For the MEP in the server trail the defect is local, for the MEP in the LSp the defect is remote. =20 > I'll appreciate your further clarification. =20 [hvh] I hope the above helped ;-) =20 Kind regards, Huub. =20 > -----Original Message----- From: mpls-interop-bounces@ietf.org=20 > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Adrian Farrel > Sent: Wednesday, May 06, 2009 3:16 PM To: mpls-interop@ietf.org=20 > Subject: [Mpls-interop] Local and Remote >=20 >=20 >=20 > I know that Malcolm and Huub are going to work on the definition of=20 > local >=20 > and remote. >=20 >=20 >=20 > Huub usefully typed during the meeting yesterday that "remote" might=20 > be >=20 > better stated as "non-local." >=20 >=20 >=20 > Watching some emails this morning, I wonder whether part of the=20 > confusion >=20 > arises from >=20 > - where the fault is detected >=20 > - where the fault exists >=20 >=20 >=20 > A node can (IMHO) only be detected locally. That is local to the=20 > point of >=20 > detection. >=20 >=20 >=20 > A fault may be reported (to the management plane) from the node of=20 > detection >=20 > (a local report), or may be signaled to another node (through the OAM > or >=20 > control plane) and reported (to the management plane) from that other > node >=20 > (a remote report). >=20 >=20 >=20 > The fault that is detected may be in the detecting node, or in a=20 > resource >=20 > directly connected to that node (such as a link). This is a local=20 > fault. >=20 >=20 >=20 > But the fault may also exist in a node or resource that is not local=20 > to the >=20 > detecting node. This is a remote fault. >=20 >=20 >=20 > If an LSP continuity check fails, the fault is detected by an end=20 > point >=20 > (local detection), but the fault might be somewhere out in the=20 > network >=20 > (remote fault). >=20 >=20 >=20 > When a server layer provides a connection that is used as a link in=20 > the >=20 > client layer, a server layer fault (that is remote in the server=20 > layer) may >=20 > be reported to the client layer as a fault in the client layer link=20 > (that is >=20 > local in the client layer). The client layer does not know about the=20 > route >=20 > or resources used in the server layer (we MUST assume clean layer >=20 > separation) so the client layer does not need to know about the=20 > location of >=20 > the server layer remote fault. If the client layer requests the=20 > server layer >=20 > to repair the client layer link (i.e. to repair the server layer=20 > connection) >=20 > the server layer may need to consider the location of the server=20 > layer >=20 > fault. >=20 >=20 >=20 > Am I wrong? >=20 > Is this really so complicated? >=20 >=20 >=20 > Thanks, >=20 > Adrian >=20 >=20 >=20 >=20 >=20 > _______________________________________________ >=20 > Mpls-interop mailing list >=20 > Mpls-interop@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/mpls-interop >=20 >=20 > ------------------------------------------------------------------------ >=20 >=20 >=20 > _______________________________________________ Mpls-interop mailing=20 > list Mpls-interop@ietf.org=20 > https://www.ietf.org/mailman/listinfo/mpls-interop =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.van-helvoort.eu/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_001_01C9CE53.CB32C815 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Huub,

[hvh] you did not indicate where the server layer starts and = ends,

I have assumed between D and E.

<NS> Right.

 

[hvh] the end points (i.e. the sink MEPs) in A and G have to = be

notified. How this is done is a = solution.

<NS> but we = have a requirement to notify them! We = need to specify this requirement exactly as we specified RDI. Please refer to my = proposal.

 

 [hvh] I assume the you mean the link failure is in both directions,

and the server layer is between D and = E.

In that case E has to inform G for traffic flowing from A to G, = and

D has to inform A for traffic flowing from G to = A.

<NS> so as said above we have a requirement to notify the endpoints. As this "pass on = the wire" is should be specified, it is not done by a magic. The requirement is = from the endpoints of the server layer to notify the endpoint of the = clients…..again please refer to my proposal.

Best regards,

NUrit

 

 

 

 

-----Original Message-----
From: mpls-interop-bounces@ietf.org = [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Huub van Helvoort
Sent: Wednesday, May 06, 2009 4:43 PM
To: mpls-interop@ietf.org
Subject: Re: [Mpls-interop] Local and Remote

 

Hi Nurit,

 

You replied:

 

> Thanks for the great = clarification.

>

> I am sorry for bothering but I still have some = questions:

 

[hvh] OK.

 

> · We have a requirement in the document for = "Remote Defect

> Indication" and it specifies that "The MPLS-TP = OAM toolset MUST

> provide a function to enable an *End Point to notify its associated

> End Point* of the detection of a fault or defect that it = detects *on

> a PW, LSP or Section* *between them*." I.e. in the = requirement refers

>  to remote as to the associated endpoint *at the same = layer*!

 

[hvh] in the example: A-B=3DC=3DD-E-F-G if the sink MEP in node = G detects

a service affecting defect it informs the co-located source MEP = and

the source MEP in node G transmits RDI towards node A. The RDI = is

detected by the sink MEP in node A and will interpret this as = node

G has detected a service affecting defect. For the sink MEP in = node

A the sink MEP in node G is the = */_remote_/*.

 

> · I would like to refer to the last paragraph in = your e-mail: "" When

>  a server layer provides a connection that is used as = a link in the

> client layer, a server layer fault (that is remote in the = server

> layer) may be reported to the client layer *as a fault in = the client

> layer link* (that is local in the client = layer)…." Assuming that we

> have an LSP that traversed nodes A-B-C-D-E-F-G and we have = a fault in

>  the link between D and E. according to the above the = server layer

> needs to notify the client layer. Is it to the client layer = in nodes

> D and E or to the endpoints of the client layers, i.e. = nodes A and G?

>

[hvh] you did not indicate where the server layer starts and = ends,

I have assumed between D and E.

 

[hvh] the end points (i.e. the sink MEPs) in A and G have to = be

notified. How this is done is a = solution.

 

> If it is node D and E (this is local) they need now to = notify nodes A

>  and G,

 

[hvh] I assume the you mean the link failure is in both = directions,

and the server layer is betwen D and = E.

In that case E has to inform G for traffic flowing from A to G, = and

D has to inform A for traffic flowing from G to = A.

 

> but according to the requirement document and to the = framework they

> may be MIPs of the LSPs but they cannot initiate OAM = messages.

 

[hvh] if my assumptions above are right there are (server) MEPs = in

D and E.

If my assumptio is wrong and you are referring to s single LSP, = a

link fault between D and E will be detected by G: loss of CC = without

a notification from a server.

 

> Therefore, it seems that the endpoint of the server layer = needs to

> notify the endpoint of the client layers of the fault = (remote).

 

[hvh] and how that is achieved is a = solution.

 

> And IMO we need to be clear about the requirement. And also = to extend

> the definition in the first bullet for remote (not = necessarily

> endpoint).

 

[hvh] I hope the explanation above makes clear what the = purpose

is of RDI and where it is = generated.

 

> · Assuming that the failure is in the first (server) = link. As

> a result we have loss of continuity in the LSPs that = transmit over

> this failed link and in the PWs that are attached to these = LSPs. As I

> understand from your definition, as these fault are = detected by the

> endpoint (to which the link is attached), all these faults = are

> considered locals!. Is there still a requirement to = distinguish

> between these failures? Note that all of these are now = local.

 

[hvh] if the first link (A-B) is a server link, then in A there = are

two MEPs: one for the LSP and one for the server = trail.

The MEP in the server trail will detect the defect and will = inform

the MEP of the LSP, according to the = requirement.

For the MEP in the server trail the defect is local, for the MEP = in

the LSp the defect is remote.

 

> I'll appreciate your further = clarification.

 

[hvh] I hope the above helped   = ;-)

 

Kind regards, Huub.

 

> -----Original Message----- From: = mpls-interop-bounces@ietf.org

> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext = Adrian Farrel

>  Sent: Wednesday, May 06, 2009 3:16 PM To: mpls-interop@ietf.org

> Subject: [Mpls-interop] Local and = Remote

>

>

>

> I know that Malcolm and Huub are going to work on the = definition of

> local

>

> and remote.

>

>

>

> Huub usefully typed during the meeting yesterday that "remote" might

> be

>

> better stated as = "non-local."

>

>

>

> Watching some emails this morning, I wonder whether part of = the

> confusion

>

> arises from

>

> - where the fault is detected

>

> - where the fault exists

>

>

>

> A node can (IMHO) only be detected locally. That is local = to the

> point of

>

> detection.

>

>

>

> A fault may be reported (to the management plane) from the = node of

> detection

>

> (a local report), or may be signaled to another node = (through the OAM

>  or

>

> control plane) and reported (to the management plane) from = that other

>  node

>

> (a remote report).

>

>

>

> The fault that is detected may be in the detecting node, or = in a

> resource

>

> directly connected to that node (such as a link). This is a = local

> fault.

>

>

>

> But the fault may also exist in a node or resource that is = not local

> to the

>

> detecting node. This is a remote = fault.

>

>

>

> If an LSP continuity check fails, the fault is detected by = an end

> point

>

> (local detection), but the fault might be somewhere out in = the

> network

>

> (remote fault).

>

>

>

> When a server layer provides a connection that is used as a = link in

> the

>

> client layer, a server layer fault (that is remote in the = server

> layer) may

>

> be reported to the client layer as a fault in the client = layer link

> (that is

>

> local in the client layer). The client layer does not know = about the

> route

>

> or resources used in the server layer (we MUST assume clean = layer

>

> separation) so the client layer does not need to know about = the

> location of

>

> the server layer remote fault. If the client layer requests = the

> server layer

>

> to repair the client layer link (i.e. to repair the server = layer

> connection)

>

> the server layer may need to consider the location of the = server

> layer

>

> fault.

>

>

>

> Am I wrong?

>

> Is this really so complicated?

>

>

>

> Thanks,

>

> Adrian

>

>

>

>

>

> = _______________________________________________<= /p>

>

> Mpls-interop mailing list

>

> Mpls-interop@ietf.org

>

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

>

>

> ------------------------------------------------------------------------<= o:p>

>

>

>

> _______________________________________________ = Mpls-interop mailing

> list Mpls-interop@ietf.org

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

 

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

           = ;        http://www.van-helvoort.eu/

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Always remember that you are unique...just like everyone = else...

_______________________________________________=

Mpls-interop mailing list

Mpls-interop@ietf.org

https://www.ietf.org/mailman/listinfo/mpls-interop

------_=_NextPart_001_01C9CE53.CB32C815-- From adrian@olddog.co.uk Wed May 6 07:18:01 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9733A6EAD for ; Wed, 6 May 2009 07:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DE6rqcnEPZ7 for ; Wed, 6 May 2009 07:17:54 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 310213A6D0E for ; Wed, 6 May 2009 07:17:11 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n46EIWtJ015746; Wed, 6 May 2009 15:18:32 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n46EISZv015641; Wed, 6 May 2009 15:18:31 +0100 Message-ID: From: "Adrian Farrel" To: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , References: <077E41CFFD002C4CAB7DFA4386A53264AB4B6B@DEMUEXC014.nsn-intra.net><4A0157B1.5050408@chello.nl> <73632CCC731C496AACD41C4DEA306288@your029b8cecfe> <077E41CFFD002C4CAB7DFA4386A53264AB5129@DEMUEXC014.nsn-intra.net> Date: Wed, 6 May 2009 15:18:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Mpls-interop] Local and Remote X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:18:01 -0000 Hi, > * We have a requirement in the document for "Remote Defect > Indication" and it specifies that "The MPLS-TP OAM toolset > MUST provide a function to enable an End Point to notify its > associated End Point of the detection of a fault or defect that > it detects on a PW, LSP or Section between them." I.e. in the > requirement refers to remote as to the associated endpoint at > the same layer! Why the exclamation point? The associated end-point at the same layer is certainly not local. Not local = remote. The defect indication comes from somewhere else (not local). That means it is a remote indication. > * I would like to refer to the last paragraph in your e-mail: >> When a server layer provides a connection that is used as >> a link in the client layer, a server layer fault (that is remote >> in the server layer) may be reported to the client layer as >> a fault in the client layer link (that is local in the client >> layer) > Assuming that we have an LSP that traversed nodes > A-B-C-D-E-F-G and we have a fault in the link > between D and E. According to the above the server > layer needs to notify the client layer. Well, I said "may," but I agree it would be useful. > Is it to the client layer in nodes D and E or to the > endpoints of the client layers, i.e. nodes A and G? To D and E. The server layer is only providing connectivity between D and E. It has (and should have) no knowledge of the client services carried over the connection. As far as the server layer is concerned, it provides a connection from D to E. The client layer decides to use this connection as the link D-E in the client layer, and decides to route the LSP AG over that link. > If it is node D and E (this is local) they need now to notify > nodes A and G First question is "why?" It may help to think of the client layer network as a single layer network and resolve the issues there first. Let us suppose that the fault was in the client layer at node D. How would A and G find out about the fault? Now suppose that the fault is in the client layer link D-E. How would A and G find out about the fault? Now we can come back to your question. The fault is in the server layer between D and E. It is reported to D and E. D and E map this to a client layer fault on the link D-E. How would A and G find out about the fault? > but according to the requirement document > and to the framework they may be MIPs of the > LSPs but they cannot initiate OAM messages. Therefore, it seems > that the endpoint of the server layer needs to notify the endpoint > of the client layers of the fault (remote). And IMO we need to be > clear about the requirement. And also to extend the definition in > the first bullet for remote (not necessarily endpoint). The answer is that the end points of the link (in the client layer) or the connection (in the server layer) may be MEPs. When they detect faults they raise alarms to their management systems. When the fault is detected by the end points (as surely it will be) they can perform fault localisation to isolate the fault. That is, the MEPs can consult the MIPs and (since the MIPs are allowed to respond) determine where the fault is. If, in the opinion of the deployer, the end points of an LSP need to know about the location of a fault at detection time (I have serious doubts about this) then he can designate every node along the path as a MEP. > * Assuming that the failure is in the first (server) link. As a > result we have loss of continuity in the LSPs that transmit over this > failed link and in the PWs that are attached to these LSPs. As I > understand from your definition, as these fault are detected by the > endpoint (to which the link is attached), all these faults are > considered locals! No. Please read again. The fault is local if the fault exists in a resource that is local (in the layer that is detecting the fault). In your example, G detects a fault in the LSP, but G does not defect a fault in the link FG or at the node G. Therefore the fault is not local. Still in your example, E detects a fault in the server connection DE (say DxyzE). - If the fault is in E or in the link zE, the fault is local in the server layer - If the fault is not in E or in the link zE, the fault is not local in the server layer In *both* cases, once the fault has been reported to the client layer, the fault is local in the client layer (it is a failure of the link DE). May help you to note that local and remote are relative terms. I.e. "local to E" is not the same as "local to G". > Is there still a requirement to distinguish between > these failures? Note that all of these are now local. Yes, there is a requirement to distinguish. No, they are not all local. I would just like to point out that we are now very far into implementation and not standardisation. It is not the job of the IETF (in my personal opinion) to tell people how to build boxes. Thanks, Adrian -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Adrian Farrel Sent: Wednesday, May 06, 2009 3:16 PM To: mpls-interop@ietf.org Subject: [Mpls-interop] Local and Remote I know that Malcolm and Huub are going to work on the definition of local and remote. Huub usefully typed during the meeting yesterday that "remote" might be better stated as "non-local." Watching some emails this morning, I wonder whether part of the confusion arises from - where the fault is detected - where the fault exists A node can (IMHO) only be detected locally. That is local to the point of detection. A fault may be reported (to the management plane) from the node of detection (a local report), or may be signaled to another node (through the OAM or control plane) and reported (to the management plane) from that other node (a remote report). The fault that is detected may be in the detecting node, or in a resource directly connected to that node (such as a link). This is a local fault. But the fault may also exist in a node or resource that is not local to the detecting node. This is a remote fault. If an LSP continuity check fails, the fault is detected by an end point (local detection), but the fault might be somewhere out in the network (remote fault). When a server layer provides a connection that is used as a link in the client layer, a server layer fault (that is remote in the server layer) may be reported to the client layer as a fault in the client layer link (that is local in the client layer). The client layer does not know about the route or resources used in the server layer (we MUST assume clean layer separation) so the client layer does not need to know about the location of the server layer remote fault. If the client layer requests the server layer to repair the client layer link (i.e. to repair the server layer connection) the server layer may need to consider the location of the server layer fault. Am I wrong? Is this really so complicated? Thanks, Adrian _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From nurit.sprecher@nsn.com Wed May 6 12:16:41 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C624F3A6FC8 for ; Wed, 6 May 2009 12:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uggjDvnqerEn for ; Wed, 6 May 2009 12:16:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 47DB028C2D1 for ; Wed, 6 May 2009 12:02:12 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n46J3bRO021126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2009 21:03:37 +0200 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 n46J3XdH019085; Wed, 6 May 2009 21:03:37 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 21:03:36 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CE7D.5B9CF673" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 6 May 2009 21:03:36 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264AB53B0@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] Local and Remote Thread-Index: AcnOVZGR05AMrqRSSy6n5wqVkQV2BAAF6GNw References: <077E41CFFD002C4CAB7DFA4386A53264AB4B6B@DEMUEXC014.nsn-intra.net><4A0157B1.5050408@chello.nl> <73632CCC731C496AACD41C4DEA306288@your029b8cecfe> <077E41CFFD002C4CAB7DFA4386A53264AB5129@DEMUEXC014.nsn-intra.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "Adrian Farrel" X-OriginalArrivalTime: 06 May 2009 19:03:36.0379 (UTC) FILETIME=[5BD688B0:01C9CE7D] Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] Local and Remote X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 19:16:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CE7D.5B9CF673 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks you Adrian for the great explanation. It really clarifies many of the issues very well.=20 I can agree to your definitions. And it is good to finally have them.=20 Please see inline some comments. The main questions that I have now are as follows: * Why do we need to specify in the OAM document a requirement to distinguish between local and remote faults? Does it require any tool that is not already required in the document? Does it require any protocol definition and interoperability between network elements? We have a requirement to detect loss of continuity (in each layer). We have a requirement to send indication of a fault detected by the peer. We have a requirement for connectivity verification, etc. what do we miss?=20 * If we have a requirement to distinguish between remote and local alarms, don't we need a requirement to distinguish between remote alarms happen at the same layer network and remote alarms happen at the server layers? This is actually what is needed if we want the endpoint of the LSPs for example to have the capability to suppress alarms that result form a remote defect at the server layer. We would probably not like to suppress alarms that result at a specific LSP for example as a result of mis-connectivity in a specific node along the path. Consider an LSP that transmit over A-B-C-D-E-F-G and there is a failure at the server link D-E. The endpoints of the server layer are D and E. Consider that D notifies its client layer of the fault, the fault becomes local to the client layer at node D. In order to be able suppress alarms at node A for all LSPs which all LSPs that start at node A and transmit over the failed server layer, node A needs to identify that this is a remote failure. But this is not enough to suppress alarms, because maybe the fault is a result of mis-connectivity and not a failure of the server layer. Fault localization is required at the same layer and since the failure is now considered in node D as a local failure also at the LSP layer (as the server layer notified it about the failure), how can we distinguish between the cases given the list of functions we require? Again I am sorry for all these exchanges, but I believe that if we do not resolve it now, and if we try to "color" the real requirement, we will get into these discussions in last call when we get comments from the ITU-T (and I'll not be the one that will issue them).. =20 Best regards, Nurit =20 -----Original Message----- From: ext Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Wednesday, May 06, 2009 5:18 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls-interop@ietf.org Subject: Re: [Mpls-interop] Local and Remote =20 Hi, =20 > * We have a requirement in the document for "Remote Defect > Indication" and it specifies that "The MPLS-TP OAM toolset > MUST provide a function to enable an End Point to notify its > associated End Point of the detection of a fault or defect that > it detects on a PW, LSP or Section between them." I.e. in the > requirement refers to remote as to the associated endpoint at > the same layer! =20 Why the exclamation point? Because we call the function REMOTE fault indication but ask for a notification only for faults that are detected by the peer endpoint at the same layer. maybe we should change the name of the function to reflect better the specific functionality that is required.=20 =20 The associated end-point at the same layer is certainly not local. Not local=20 =3D remote. Right. But in this case the remote is in the same layer.=20 =20 The defect indication comes from somewhere else (not local). That means it=20 is a remote indication. Correct =20 > * I would like to refer to the last paragraph in your e-mail: >> When a server layer provides a connection that is used as >> a link in the client layer, a server layer fault (that is remote >> in the server layer) may be reported to the client layer as >> a fault in the client layer link (that is local in the client >> layer) > Assuming that we have an LSP that traversed nodes > A-B-C-D-E-F-G and we have a fault in the link > between D and E. According to the above the server > layer needs to notify the client layer. =20 Well, I said "may," but I agree it would be useful. =20 > Is it to the client layer in nodes D and E or to the > endpoints of the client layers, i.e. nodes A and G? =20 To D and E. The server layer is only providing connectivity between D and E. Right. BUT if you refer to the e-mails from Huub and to the discussions with Malcolm last night they want the endpoints of the client (e.g. LSPs, PWs) to identify failures that happened remotely at the server layer! How can the endpoints know about such failures if there is no requirement for someone to notify it about such a failure?=20 =20 It has (and should have) no knowledge of the client services carried over=20 the connection. Correct. This is exactly the problem I am referring (or at least try to refer to).=20 As far as the server layer is concerned, it provides a connection from D to=20 E. Correct.=20 The client layer decides to use this connection as the link D-E in the=20 client layer, and decides to route the LSP AG over that link. =20 NS> to be more specific, in transport it is the management station or the Ingress node which calculate the route and make this decision.=20 =20 > If it is node D and E (this is local) they need now to notify > nodes A and G =20 First question is "why?" =20 Because this is the requirement that was written in the revised document (at least I read it) and that was specified in the mail exchanges with Huub and Malcolm (at least as I understood it). I do not remember the exact words but it was something like that the endpoints of LSP, PW MUST indicate if the fault causing loss of continuity is local (i.e. within the node containing the end point) or remote. How can the endpoints know about REMOTE failures if no one notifies them about it?=20 =20 It may help to think of the client layer network as a single layer network=20 and resolve the issues there first. =20 Let us suppose that the fault was in the client layer at node D. How would A=20 and G find out about the fault? =20 Exactly. That is the point. If they need to know about it as stated in the requirement above, then someone needs to notify them about remote failures.=20 =20 Now suppose that the fault is in the client layer link D-E. How would A and=20 G find out about the fault? =20 Now we can come back to your question. The fault is in the server layer=20 between D and E. It is reported to D and E. D and E map this to a client layer fault on the link D-E. How would A and G find out about the fault? =20 This is exactly the issue I have with the requirement that was specified in the revised document. If the endpoints of an LSP need to distinguish between local and remote faults, someone needs to notify them about it. Otherwise they can not know it.=20 =20 > but according to the requirement document > and to the framework they may be MIPs of the > LSPs but they cannot initiate OAM messages. Therefore, it seems > that the endpoint of the server layer needs to notify the endpoint > of the client layers of the fault (remote). And IMO we need to be > clear about the requirement. And also to extend the definition in > the first bullet for remote (not necessarily endpoint). =20 The answer is that the end points of the link (in the client layer) or the=20 connection (in the server layer) may be MEPs. When they detect faults they=20 raise alarms to their management systems. =20 When the fault is detected by the end points (as surely it will be) they can=20 perform fault localisation to isolate the fault. That is, the MEPs can=20 consult the MIPs and (since the MIPs are allowed to respond) determine where=20 the fault is. =20 > All this is correct. But in order to understand that this is a remote failure you do not need to know the location of the fault. You just need to know that it is a remote failure. In such a case all LSPs need to consult with their immediate MIPS to understand be able to distinguish between the faults.=20 Why do we need at all to specify a requirement for the endpoints to distinguish between local and remote failures? Does it require any interoperation between network elements?=20 =20 If, in the opinion of the deployer, the end points of an LSP need to know=20 about the location of a fault at detection time (I have serious doubts about=20 this) then he can designate every node along the path as a MEP. According to the definition, a MEP is an endpoint of LSP, or PW. If you designate any node along a path as a MEP you have many concatenated LSPs. =20 =20 =20 > * Assuming that the failure is in the first (server) link. As a > result we have loss of continuity in the LSPs that transmit over this > failed link and in the PWs that are attached to these LSPs. As I > understand from your definition, as these fault are detected by the > endpoint (to which the link is attached), all these faults are > considered locals! =20 No. Please read again. =20 The fault is local if the fault exists in a resource that is local (in the=20 layer that is detecting the fault). OK.=20 In your example, G detects a fault in the LSP, but G does not defect a fault=20 in the link FG or at the node G. Therefore the fault is not local. =20 Still in your example, E detects a fault in the server connection DE (say=20 DxyzE). - If the fault is in E or in the link zE, the fault is local in the server=20 layer - If the fault is not in E or in the link zE, the fault is not local in the=20 server layer In *both* cases, once the fault has been reported to the client layer, the=20 fault is local in the client layer (it is a failure of the link DE). OK =20 May help you to note that local and remote are relative terms. I.e. "local=20 to E" is not the same as "local to G". =20 > Is there still a requirement to distinguish between > these failures? Note that all of these are now local. =20 Yes, there is a requirement to distinguish. Why do we need to specify it in the document? Does it require any development of a protocol?=20 No, they are not all local. =20 =20 I would just like to point out that we are now very far into implementation=20 and not standardisation. It is not the job of the IETF (in my personal=20 opinion) to tell people how to build boxes. =20 Thanks, Adrian =20 -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Adrian Farrel Sent: Wednesday, May 06, 2009 3:16 PM To: mpls-interop@ietf.org Subject: [Mpls-interop] Local and Remote =20 =20 =20 I know that Malcolm and Huub are going to work on the definition of local =20 and remote. =20 =20 =20 Huub usefully typed during the meeting yesterday that "remote" might be =20 better stated as "non-local." =20 =20 =20 Watching some emails this morning, I wonder whether part of the confusion arises from - where the fault is detected - where the fault exists =20 A node can (IMHO) only be detected locally. That is local to the point of detection. =20 A fault may be reported (to the management plane) from the node of detection=20 (a local report), or may be signaled to another node (through the OAM or control plane) and reported (to the management plane) from that other node=20 (a remote report). =20 The fault that is detected may be in the detecting node, or in a resource=20 directly connected to that node (such as a link). This is a local fault. =20 But the fault may also exist in a node or resource that is not local to the=20 detecting node. This is a remote fault. =20 =20 =20 If an LSP continuity check fails, the fault is detected by an end point =20 (local detection), but the fault might be somewhere out in the network =20 (remote fault). =20 =20 =20 When a server layer provides a connection that is used as a link in the =20 client layer, a server layer fault (that is remote in the server layer) may =20 be reported to the client layer as a fault in the client layer link (that is =20 local in the client layer). The client layer does not know about the route =20 or resources used in the server layer (we MUST assume clean layer =20 separation) so the client layer does not need to know about the location of =20 the server layer remote fault. If the client layer requests the server layer =20 to repair the client layer link (i.e. to repair the server layer connection) =20 the server layer may need to consider the location of the server layer =20 fault. =20 =20 =20 Am I wrong? =20 Is this really so complicated? =20 =20 =20 Thanks, =20 Adrian =20 =20 =20 =20 =20 _______________________________________________ =20 Mpls-interop mailing list =20 Mpls-interop@ietf.org =20 https://www.ietf.org/mailman/listinfo/mpls-interop =20 =20 =20 ------_=_NextPart_001_01C9CE7D.5B9CF673 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Thanks you Adrian for the great explanation. It really clarifies many of the issues very = well.

I can agree to your definitions. And it is good to finally have = them.

Please see inline some comments.

The main questions that I have now are as = follows:

·         Why do we = need to specify in the OAM document a requirement to distinguish between local = and remote faults? Does it require any tool that is not already required in = the document? Does it require any protocol definition and interoperability = between network elements? We have a requirement to detect loss of continuity (in = each layer). We have a requirement to send indication of a fault detected by = the peer. We have a requirement for connectivity verification, etc. what do = we miss?

·         If we have = a requirement to distinguish between remote and local alarms, don't we = need a requirement to distinguish between remote alarms happen at the same = layer network and remote alarms happen at the server layers? This is actually = what is needed if we want the endpoint of the LSPs for example to have the = capability to suppress alarms that result form a remote defect at the server layer. = We would probably not like to suppress alarms that result at a specific LSP = for example as a result of mis-connectivity in a specific node along the = path. Consider an LSP that transmit over A-B-C-D-E-F-G and there is a failure = at the server link D-E. The endpoints of the server layer are D and E. Consider = that D notifies its client layer of the fault, the fault becomes local to the = client layer at node D. In order to be able suppress alarms at node A for all = LSPs which all LSPs that start at node A and transmit over the failed server = layer, node A needs to identify that this is a remote failure. But this is not = enough to suppress alarms, because maybe the fault is a result of = mis-connectivity and not a failure of the server layer. Fault localization is required at the = same layer and since the failure is now considered in node D as a local = failure also at the LSP layer (as the server layer notified it about the failure), = how can we distinguish between the cases given the list of functions we = require?

Again I am sorry for all these exchanges, but I believe that if = we do not resolve it now, and if we try to "color" the real = requirement, we will get into these discussions in last call when we get comments from = the ITU-T (and I'll not be the one that will issue them).. =  

Best regards,

Nurit

 

-----Original Message-----
From: ext Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, May 06, 2009 5:18 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls-interop@ietf.org
Subject: Re: [Mpls-interop] Local and = Remote

 

Hi,

 

> * We have a requirement in the document for "Remote = Defect

> Indication" and it specifies that "The MPLS-TP = OAM toolset

> MUST provide a function to enable an End Point to notify = its

> associated End Point of the detection of a fault or defect = that

> it detects on a PW, LSP or Section between them." I.e. = in the

> requirement refers to remote as to the associated endpoint = at

> the same layer!

 

Why the exclamation point?

<NS> Because we call the = function REMOTE fault indication but ask for a notification only for faults that are = detected by the peer endpoint at the same layer. maybe we should change the name = of the function to reflect better the specific functionality that is required. =

 

The associated end-point at the same layer is certainly not = local. Not local

=3D remote.

<NS> Right. But in this = case the remote is in the same layer.

 

The defect indication comes from somewhere else (not local). = That means it

is a remote indication.

<NS> = Correct

 

> *  I would like to refer to the last paragraph in your e-mail:

>> When a server layer provides a connection that is used = as

>> a link in the client layer, a server layer fault (that = is remote

>> in the server layer) may be reported to the client = layer as

>> a fault in the client layer link (that is local in the = client

>> layer)

> Assuming that we have an LSP that traversed = nodes

> A-B-C-D-E-F-G and we have a fault in the = link

> between D and E. According to the above the = server

> layer needs to notify the client = layer.

 

Well, I said "may," but I agree it would be = useful.

 

> Is it to the client layer in nodes D and E or to = the

> endpoints of the client layers, i.e. nodes A and = G?

 

To D and E.

The server layer is only providing connectivity between D and = E.

<NS> Right. BUT if you = refer to the e-mails from Huub and to the discussions with Malcolm last night they = want the endpoints of the client (e.g. LSPs, PWs) to identify failures that = happened remotely at the server layer! How can the endpoints know about such = failures if there is no requirement for someone to notify it about such a failure? =

 

It has (and should have) no knowledge of the client services = carried over

the connection.

<NS> Correct. This is = exactly the problem I am referring (or at least try to refer to). =

As far as the server layer is concerned, it provides a = connection from D to

E.

<NS> Correct. =

The client layer decides to use this connection as the link D-E = in the

client layer, and decides to route the LSP AG over that = link.

 

NS> to be more specific, in = transport it is the management station or the Ingress node which calculate the = route and make this decision.

 

> If it is node D and E (this is local) they need now to = notify

> nodes A and G

 

First question is "why?"

 

<NS> Because this is the requirement that was written in = the revised document (at least I read it) and that was specified in the mail exchanges with Huub and Malcolm (at least as I understood it). I do not remember the exact words but it was something like that the endpoints of = LSP, PW MUST indicate if the = fault causing loss of continuity is local (i.e. within the node containing the = end point) or remote. How can = the endpoints know about REMOTE failures if no one notifies them about it? =

 

It may help to think of the client layer network as a single = layer network

and resolve the issues there first.

 

Let us suppose that the fault was in the client layer at node D. = How would A

and G find out about the fault?

 

<NS> Exactly. That is the point. If they need to know about it as stated in the requirement = above, then someone needs to notify them about remote failures. =

 

Now suppose that the fault is in the client layer link D-E. How = would A and

G find out about the fault?

 

Now we can come back to your question. The fault is in the = server layer

between D and E. It is reported to D and E. D and E map this to = a client

layer fault on the link D-E. How would A and G find out about = the fault?

 

<NS> This is exactly the issue I have with the requirement = that was specified in the revised document. If the endpoints of an LSP need = to distinguish between local and remote faults, someone needs to notify = them about it. Otherwise they can not know it.

 

> but according to the requirement = document

> and to the framework they may be MIPs of = the

> LSPs but they cannot initiate OAM messages. Therefore, it = seems

> that the endpoint of the server layer needs to notify the = endpoint

> of the client layers of the fault (remote). And IMO we need = to be

> clear about the requirement. And also to extend the = definition in

> the first bullet for remote (not necessarily = endpoint).

 

The answer is that the end points of the link (in the client = layer) or the

connection (in the server layer) may be MEPs. When they detect = faults they

raise alarms to their management = systems.

 

When the fault is detected by the end points (as surely it will = be) they can

perform fault localisation to isolate the fault. That is, the = MEPs can

consult the MIPs and (since the MIPs are allowed to respond) = determine where

the fault is.

 

<NS> > All this is correct. But in order to = understand that this is a remote failure you do not need to know the location of the = fault. You just need to know that it is a remote failure. In such a case all LSPs = need to consult with their immediate MIPS to understand be able to distinguish = between the faults.

Why do we need at all to specify a requirement for the endpoints = to distinguish between local and remote failures? Does it require any interoperation between network elements?

 

If, in the opinion of the deployer, the end points of an LSP = need to know

about the location of a fault at detection time (I have serious = doubts about

this) then he can designate every node along the path as a = MEP.

<NS> According to the definition, a MEP is an endpoint of LSP, or PW. If you designate any node along a path as a MEP you have many concatenated = LSPs.  

 

 

> * Assuming that the failure is in the first (server) link. = As a

> result we have loss of continuity in the LSPs that transmit = over this

> failed link and in the PWs that are attached to these LSPs. = As I

> understand from your definition, as these fault are = detected by the

> endpoint (to which the link is attached), all these faults = are

> considered locals!

 

No.

Please read again.

 

The fault is local if the fault exists in a resource that is = local (in the

layer that is detecting the fault).

<NS> = OK.

In your example, G detects a fault in the LSP, but G does not = defect a fault

in the link FG or at the node G. Therefore the fault is not = local.

 

Still in your example, E detects a fault in the server = connection DE (say

DxyzE).

- If the fault is in E or in the link zE, the fault is local in = the server

layer

- If the fault is not in E or in the link zE, the fault is not = local in the

server layer

In *both* cases, once the fault has been reported to the client = layer, the

fault is local in the client layer (it is a failure of the link = DE).

<NS> OK

 

May help you to note that local and remote are relative terms. = I.e. "local

to E" is not the same as "local to = G".

 

> Is there still a requirement to distinguish = between

> these failures? Note that all of these are now = local.

 

Yes, there is a requirement to = distinguish.

<NS> Why do we need to specify it in the document? Does it require any = development of a protocol?

No, they are not all local.

 

 

I would just like to point out that we are now very far into implementation

and not standardisation. It is not the job of the IETF (in my = personal

opinion) to tell people how to build = boxes.

 

Thanks,

Adrian

 

-----Original Message-----

From: mpls-interop-bounces@ietf.org

[mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext = Adrian Farrel

Sent: Wednesday, May 06, 2009 3:16 = PM

To: mpls-interop@ietf.org

Subject: [Mpls-interop] Local and = Remote

 

 

 

I know that Malcolm and Huub are going to work on the definition = of

local

 

and remote.

 

 

 

Huub usefully typed during the meeting yesterday that "remote" might be

 

better stated as = "non-local."

 

 

 

Watching some emails this morning, I wonder whether part of = the

confusion arises from

- where the fault is detected

- where the fault exists

 

A node can (IMHO) only be detected locally. That is local to the = point

of detection.

 

A fault may be reported (to the management plane) from the node = of detection

(a local report), or may be signaled to another node (through = the OAM or

control plane) and reported (to the management plane) from that = other node

(a remote report).

 

The fault that is detected may be in the detecting node, or in a resource

directly connected to that node (such as a link). This is a = local fault.

 

But the fault may also exist in a node or resource that is not = local to the

detecting node. This is a remote = fault.

 

 

 

If an LSP continuity check fails, the fault is detected by an = end point

 

(local detection), but the fault might be somewhere out in the = network

 

(remote fault).

 

 

 

When a server layer provides a connection that is used as a link = in the

 

client layer, a server layer fault (that is remote in the server = layer)

may

 

be reported to the client layer as a fault in the client layer = link

(that is

 

local in the client layer). The client layer does not know about = the

route

 

or resources used in the server layer (we MUST assume clean = layer

 

separation) so the client layer does not need to know about the location

of

 

the server layer remote fault. If the client layer requests the = server

layer

 

to repair the client layer link (i.e. to repair the server = layer

connection)

 

the server layer may need to consider the location of the server = layer

 

fault.

 

 

 

Am I wrong?

 

Is this really so complicated?

 

 

 

Thanks,

 

Adrian

 

 

 

 

 

_______________________________________________=

 

Mpls-interop mailing list

 

Mpls-interop@ietf.org

 

https://www.ietf.org/mailman/listinfo/mpls-interop

 

 

 

------_=_NextPart_001_01C9CE7D.5B9CF673-- From nurit.sprecher@nsn.com Thu May 7 06:43:20 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911A33A6B83 for ; Thu, 7 May 2009 06:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.358 X-Spam-Level: X-Spam-Status: No, score=-5.358 tagged_above=-999 required=5 tests=[AWL=1.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdzmXsIWL498 for ; Thu, 7 May 2009 06:43:19 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id C31D23A6B4E for ; Thu, 7 May 2009 06:43:18 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n47Digrh016424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 May 2009 15:44:42 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n47Digmb002592; Thu, 7 May 2009 15:44:42 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 15:44:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9CF19.F913B877" Date: Thu, 7 May 2009 15:44:39 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264AEF8E9@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-sprecher-mpls-tp-oam-analysis-04.txt Thread-Index: AcnPDcbI4ZmUP1UjQhuIWrGdvksuoQAC3lHQ From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 07 May 2009 13:44:42.0156 (UTC) FILETIME=[F95D8EC0:01C9CF19] Cc: "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" , hhelvoort@chello.nl Subject: [Mpls-interop] FW: I-D Action:draft-sprecher-mpls-tp-oam-analysis-04.txt X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 13:43:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CF19.F913B877 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9CF19.F913B877" ------_=_NextPart_002_01C9CF19.F913B877 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have just submitted a new version of the MPLS-TP OAM analysis document. The updated version can be found in the following link: http://www.ietf.org/internet-drafts/draft-sprecher-mpls-tp-oam-analysis- 04.txt=20 This version has been updated to be aligned with the latest available version of the OAM requirements document (we will probably need to update it again once the OAM requirement is revised to include the latest discussions).=20 In this version we addressed comments we received (e.g. on LSP ping, etc.). This version includes also an introduction of Y.1731 (in addition to the OAM existing tools) and some considerations with regards to the requirements.=20 We will appreciate if you can review the document and provide your comments.=20 We believe it is important to discuss this document before we get into the solutions. This is the right context to see the entire picture. Best regards, Nurit =20 =20 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org Sent: Thursday, May 07, 2009 3:15 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-sprecher-mpls-tp-oam-analysis-04.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. =20 Title : MPLS-TP OAM Analysis Author(s) : N. Sprecher, et al. Filename : draft-sprecher-mpls-tp-oam-analysis-04.txt Pages : 22 Date : 2009-05-07 =20 The intention of this document is to analyze the set of requirements for Operations, Administration, and Maintenance (OAM) for the Transport Profile of MPLS(MPLS-TP) as defined in [MPLS-TP OAM Reqs], to evaluate whether existing OAM tools (either from the current MPLS toolset or from the ITU-T documents) can be applied to these requirements. Eventually, the purpose of the document is to recommend which of the existing tools should be extended and what new tools should be defined to support the set of OAM requirements for MPLS-TP. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sprecher-mpls-tp-oam-analysis- 04.txt =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_002_01C9CF19.F913B877 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We have just submitted a new version of the MPLS-TP OAM analysis document. The updated version can be found in the following = link:

http://www.ietf.org/internet-drafts/draft-sprecher-mpls-tp= -oam-analysis-04.txt

This version has been updated to be aligned with the latest = available version of the OAM requirements document (we will probably need to = update it again once the OAM requirement is revised to include the latest = discussions).

In this version we addressed comments we received (e.g. on LSP = ping, etc.). This version includes also an introduction of Y.1731 (in addition to the = OAM existing tools) and some considerations with regards to the = requirements.

We will appreciate if you = can review the document and provide your comments. =

We believe it is important = to discuss this document before we get into the solutions. This is the right = context to see the entire picture.

Best regards,

Nurit

 

 

-----Original Message-----
From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org
Sent: Thursday, May 07, 2009 3:15 PM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-sprecher-mpls-tp-oam-analysis-04.txt =

 

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

 

      = Title           : MPLS-TP OAM Analysis

      = Author(s)       : N. Sprecher, et al.

      Filename   =      : draft-sprecher-mpls-tp-oam-analysis-04.txt

      = Pages           : 22

      = Date            : 2009-05-07

 

The intention of this document is to analyze the set of = requirements

for Operations, Administration, and Maintenance (OAM) for = the

Transport Profile of MPLS(MPLS-TP) as defined in [MPLS-TP OAM = Reqs],

to evaluate whether existing OAM tools (either from the current = MPLS

toolset or from the ITU-T documents) can be applied to = these

requirements.  Eventually, the purpose of the document is = to

recommend which of the existing tools should be extended and = what new

tools should be defined to support the set of OAM requirements = for

MPLS-TP.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-sprecher-mpls-tp-oam-an= alysis-04.txt

 

Internet-Drafts are also available by anonymous FTP = at:

ftp://ftp.ietf.org/internet-drafts/

 

Below is the data which will enable a MIME compliant mail = reader

implementation to automatically retrieve the ASCII version of = the

Internet-Draft.

------_=_NextPart_002_01C9CF19.F913B877-- ------_=_NextPart_001_01C9CF19.F913B877 Content-Type: application/octet-stream; name="draft-sprecher-mpls-tp-oam-analysis-04.URL" Content-Transfer-Encoding: base64 Content-Description: draft-sprecher-mpls-tp-oam-analysis-04.URL Content-Disposition: attachment; filename="draft-sprecher-mpls-tp-oam-analysis-04.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zcHJlY2hlci1tcGxzLXRwLW9hbS1hbmFseXNpcy0wNC50eHQNCg== ------_=_NextPart_001_01C9CF19.F913B877 Content-Type: text/plain; name="ATT191968.txt" Content-Transfer-Encoding: base64 Content-Description: ATT191968.txt Content-Disposition: attachment; filename="ATT191968.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C9CF19.F913B877-- From BETTS01@nortel.com Thu May 7 08:38:11 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6D73A7055 for ; Thu, 7 May 2009 08:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za+SgDLJoH-W for ; Thu, 7 May 2009 08:38:09 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 927593A6CEC for ; Thu, 7 May 2009 08:38:09 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n47Fcao22583; Thu, 7 May 2009 15:38:36 GMT 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, 7 May 2009 11:39:29 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5170DC9D8@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] Local and Remote Thread-Index: AcnOVbKwQRnzGDCBREuCUPTWRc0NQgAymXcw References: <077E41CFFD002C4CAB7DFA4386A53264AB4B6B@DEMUEXC014.nsn-intra.net><4A0157B1.5050408@chello.nl><73632CCC731C496AACD41C4DEA306288@your029b8cecfe><077E41CFFD002C4CAB7DFA4386A53264AB5129@DEMUEXC014.nsn-intra.net> From: "Malcolm Betts" To: "Adrian Farrel" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , Subject: Re: [Mpls-interop] Local and Remote X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 15:38:11 -0000 All, first apologies for my behaviour on the MEAD team call on Tuesday, showing frustration is not an acceptable way of holding a technical discussion. Looking at the chain of email I see signs of convergence but no easy way to simple text. I saw a comment from Sasha on the network management requirements draft: "Section 5.5.2 deals with alarm suppression and defined a MUST requirement to suppress "superfluous alarms". However, the notion of the superfluous alarm" is not defined (neither directly in the draft nor by reference to other sources). Taking into account that there are more than 50 messages discussing AIS/FDI on this list, it seems that the superfluosity of an alarm is in the eye of the beholder..." That triggered a thought that perhaps we have better way to describe the problem: Since we have very different backgrounds first some basic definitions: Fault: An unintended event that impacts a network. Examples: hardware failure; software bug; configuration error. Defect: The observed perturbation of a signal. e.g. Loss of CC messages: Loss of light (following a cable cut fault). Primary defect: The first defect that is observed as the result of a fault. Consequential defect: Any other defect that is caused by the same fault. As an example consider a node that has a 40G OTN interface carrying 4xODU2, one ODU2 carrying GFP mapped MPLS-TP LSPs, some MPLS-TP LSPs transit a switch/crossconnect function and leave the node; Others terminate locally on a PW end point.=20 If the fiber carrying the 40G signal is cut adjacent to the node: The primary defect would be Loss of optical signal. =20 Loss of OTU frame, loss of ODU, loss of CC messages on the terminated LSP, loss of CC messages on the terminated PW are all be consequential defects observed in this "local" node. At some (remote) node the LSP's and the PW's that transited the node adjacent to the fiber cut will be terminated. Assuming no recovery/repair action has taken place, then a loss of CC defect will be observed for both the LSP and PW at this (remote) node. These are consequential defects. So perhaps we could (in the OAM requirements document) include a requirement that states: It MUST be possible to differentiate between primary and consequential defects. The OAM toolkit MUST support mechanisms to support this differentiation. Comments: 1) This includes an implicit requirement that defect information is passed from a server layer to a client layer within a node. 2) The (simple) example about is only to illustrate the concepts, many other scenarios will need to be analyzed to determine if a proposed solution adequately addresses the requirement. 3) If we take this approach do we need definitions for fault, primary/consequential defect. In the NM requirements we could state: It MUST be possible to suppress alarms that result from consequential defects. Hope this helps. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, May 06, 2009 10:18 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls-interop@ietf.org Subject: Re: [Mpls-interop] Local and Remote Hi, > * We have a requirement in the document for "Remote Defect Indication" > and it specifies that "The MPLS-TP OAM toolset MUST provide a function > to enable an End Point to notify its associated End Point of the=20 > detection of a fault or defect that it detects on a PW, LSP or Section > between them." I.e. in the requirement refers to remote as to the=20 > associated endpoint at the same layer! Why the exclamation point? The associated end-point at the same layer is certainly not local. Not local =3D remote. The defect indication comes from somewhere else (not local). That means it is a remote indication. > * I would like to refer to the last paragraph in your e-mail: >> When a server layer provides a connection that is used as a link in=20 >> the client layer, a server layer fault (that is remote in the server=20 >> layer) may be reported to the client layer as a fault in the client=20 >> layer link (that is local in the client >> layer) > Assuming that we have an LSP that traversed nodes A-B-C-D-E-F-G and we > have a fault in the link between D and E. According to the above the=20 > server layer needs to notify the client layer. Well, I said "may," but I agree it would be useful. > Is it to the client layer in nodes D and E or to the endpoints of the=20 > client layers, i.e. nodes A and G? To D and E. The server layer is only providing connectivity between D and E. It has (and should have) no knowledge of the client services carried over the connection. As far as the server layer is concerned, it provides a connection from D to E. The client layer decides to use this connection as the link D-E in the client layer, and decides to route the LSP AG over that link. > If it is node D and E (this is local) they need now to notify nodes A=20 > and G First question is "why?" It may help to think of the client layer network as a single layer network and resolve the issues there first. Let us suppose that the fault was in the client layer at node D. How would A and G find out about the fault? Now suppose that the fault is in the client layer link D-E. How would A and G find out about the fault? Now we can come back to your question. The fault is in the server layer between D and E. It is reported to D and E. D and E map this to a client layer fault on the link D-E. How would A and G find out about the fault? > but according to the requirement document and to the framework they=20 > may be MIPs of the LSPs but they cannot initiate OAM messages.=20 > Therefore, it seems that the endpoint of the server layer needs to=20 > notify the endpoint of the client layers of the fault (remote). And=20 > IMO we need to be clear about the requirement. And also to extend the=20 > definition in the first bullet for remote (not necessarily endpoint). The answer is that the end points of the link (in the client layer) or the connection (in the server layer) may be MEPs. When they detect faults they raise alarms to their management systems. When the fault is detected by the end points (as surely it will be) they can perform fault localisation to isolate the fault. That is, the MEPs can consult the MIPs and (since the MIPs are allowed to respond) determine where the fault is. If, in the opinion of the deployer, the end points of an LSP need to know about the location of a fault at detection time (I have serious doubts about this) then he can designate every node along the path as a MEP. > * Assuming that the failure is in the first (server) link. As a result > we have loss of continuity in the LSPs that transmit over this failed=20 > link and in the PWs that are attached to these LSPs. As I understand=20 > from your definition, as these fault are detected by the endpoint (to=20 > which the link is attached), all these faults are considered locals! No. Please read again. The fault is local if the fault exists in a resource that is local (in the layer that is detecting the fault). In your example, G detects a fault in the LSP, but G does not defect a fault in the link FG or at the node G. Therefore the fault is not local. Still in your example, E detects a fault in the server connection DE (say DxyzE). - If the fault is in E or in the link zE, the fault is local in the server layer - If the fault is not in E or in the link zE, the fault is not local in the server layer In *both* cases, once the fault has been reported to the client layer, the fault is local in the client layer (it is a failure of the link DE). May help you to note that local and remote are relative terms. I.e. "local to E" is not the same as "local to G". > Is there still a requirement to distinguish between these failures?=20 > Note that all of these are now local. Yes, there is a requirement to distinguish. No, they are not all local. I would just like to point out that we are now very far into implementation and not standardisation. It is not the job of the IETF (in my personal opinion) to tell people how to build boxes. Thanks, Adrian -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Adrian Farrel Sent: Wednesday, May 06, 2009 3:16 PM To: mpls-interop@ietf.org Subject: [Mpls-interop] Local and Remote I know that Malcolm and Huub are going to work on the definition of local and remote. Huub usefully typed during the meeting yesterday that "remote" might be better stated as "non-local." Watching some emails this morning, I wonder whether part of the confusion arises from - where the fault is detected - where the fault exists A node can (IMHO) only be detected locally. That is local to the point of detection. A fault may be reported (to the management plane) from the node of detection (a local report), or may be signaled to another node (through the OAM or control plane) and reported (to the management plane) from that other node (a remote report). The fault that is detected may be in the detecting node, or in a resource directly connected to that node (such as a link). This is a local fault. But the fault may also exist in a node or resource that is not local to the detecting node. This is a remote fault. If an LSP continuity check fails, the fault is detected by an end point (local detection), but the fault might be somewhere out in the network (remote fault). When a server layer provides a connection that is used as a link in the client layer, a server layer fault (that is remote in the server layer) may be reported to the client layer as a fault in the client layer link (that is local in the client layer). The client layer does not know about the route or resources used in the server layer (we MUST assume clean layer separation) so the client layer does not need to know about the location of the server layer remote fault. If the client layer requests the server layer to repair the client layer link (i.e. to repair the server layer connection) the server layer may need to consider the location of the server layer fault. Am I wrong? Is this really so complicated? Thanks, Adrian _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From hklam@alcatel-lucent.com Thu May 7 13:17:50 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D923A71C0 for ; Thu, 7 May 2009 13:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuJXpzX4gkFh for ; Thu, 7 May 2009 13:17:47 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 85E833A6A3E for ; Thu, 7 May 2009 13:17:43 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n47KIMi9004701; Thu, 7 May 2009 15:19:07 -0500 (CDT) Received: from ILEXC2U03.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 15:18:21 -0500 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_01C9CF50.F6E621BA" Date: Thu, 7 May 2009 15:18:19 -0500 Message-ID: In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5170DC9D8@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] Local and Remote Thread-Index: AcnOVbKwQRnzGDCBREuCUPTWRc0NQgAymXcwAAtc0pA= References: <077E41CFFD002C4CAB7DFA4386A53264AB4B6B@DEMUEXC014.nsn-intra.net><4A0157B1.5050408@chello.nl><73632CCC731C496AACD41C4DEA306288@your029b8cecfe><077E41CFFD002C4CAB7DFA4386A53264AB5129@DEMUEXC014.nsn-intra.net> <0BDFFF51DC89434FA33F8B37FCE363D5170DC9D8@zcarhxm2.corp.nortel.com> From: "Lam, Hing-Kam \(Kam\)" To: "Malcolm Betts" , "Adrian Farrel" , "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , X-OriginalArrivalTime: 07 May 2009 20:18:21.0014 (UTC) FILETIME=[F74D4760:01C9CF50] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Mpls-interop] Local and Remote X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 20:17:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CF50.F6E621BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcolm, =20 I agree in general with your approach. =20 Please see inline below. =20 Regards, Kam =20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] > On Behalf Of Malcolm Betts > Sent: Thursday, May 07, 2009 11:39 AM > To: Adrian Farrel; Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls- > interop@ietf.org > Subject: Re: [Mpls-interop] Local and Remote >=20 > All, first apologies for my behaviour on the MEAD team call on Tuesday, > showing frustration is not an acceptable way of holding a technical > discussion. >=20 > Looking at the chain of email I see signs of convergence but no easy way > to simple text. I saw a comment from Sasha on the network management > requirements draft: >=20 > "Section 5.5.2 deals with alarm suppression and defined a MUST > requirement to suppress "superfluous alarms". However, the notion of the > superfluous alarm" is not defined (neither directly in the draft nor by > reference to other sources). Taking into account that there are more > than 50 messages discussing AIS/FDI on this list, it seems that the > superfluosity of an alarm is in the eye of the beholder..." >=20 > That triggered a thought that perhaps we have better way to describe the > problem: >=20 > Since we have very different backgrounds first some basic definitions: >=20 > Fault: An unintended event that impacts a network. Examples: hardware > failure; software bug; configuration error. >=20 > Defect: The observed perturbation of a signal. e.g. Loss of CC > messages: Loss of light (following a cable cut fault). >=20 [Lam, Hing-Kam (Kam)] G.806 already has the definitions for Fault and Defect. We should reuse (base on) them as much as possible. The key point here is the differentiation of primary and consequential. =20 > Primary defect: The first defect that is observed as the result of a > fault. >=20 > Consequential defect: Any other defect that is caused by the same > fault. >=20 > As an example consider a node that has a 40G OTN interface carrying > 4xODU2, one ODU2 carrying GFP mapped MPLS-TP LSPs, some MPLS-TP LSPs > transit a switch/crossconnect function and leave the node; Others > terminate locally on a PW end point. >=20 > If the fiber carrying the 40G signal is cut adjacent to the node: >=20 > The primary defect would be Loss of optical signal. > Loss of OTU frame, loss of ODU, loss of CC messages on the terminated > LSP, loss of CC messages on the terminated PW are all be consequential > defects observed in this "local" node. >=20 > At some (remote) node the LSP's and the PW's that transited the node > adjacent to the fiber cut will be terminated. Assuming no > recovery/repair action has taken place, then a loss of CC defect will be > observed for both the LSP and PW at this (remote) node. These are > consequential defects. >=20 > So perhaps we could (in the OAM requirements document) include a > requirement that states: >=20 > It MUST be possible to differentiate between primary and consequential > defects. The OAM toolkit MUST support mechanisms to support this > differentiation. [Lam, Hing-Kam (Kam)] Agree. >=20 > Comments: > 1) This includes an implicit requirement that defect information is > passed from a server layer to a client layer within a node. [Lam, Hing-Kam (Kam)] Agree. The challenge here is, e.g. how the client layer MIP further passes the information to the client MEP. =20 > 2) The (simple) example about is only to illustrate the concepts, many > other scenarios will need to be analyzed to determine if a proposed > solution adequately addresses the requirement. > 3) If we take this approach do we need definitions for fault, > primary/consequential defect. [Lam, Hing-Kam (Kam)] Define primary/consequential defects, but based on the G.806 definitions of fault and defect.=20 >=20 > In the NM requirements we could state: >=20 > It MUST be possible to suppress alarms that result from consequential > defects. [Lam, Hing-Kam (Kam)] Agree to have such a requirement in the NM requirement document. However, if the OAM tookit supports mechanisms to support this differentiation and suppression in the DP, that will make the life of the MP much easier. Otherwise the poor MP will need to perform root cause analysis to find out which/where is primary (root cause) and which are consequential. >=20 > Hope this helps. >=20 >=20 > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com >=20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, May 06, 2009 10:18 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls-interop@ietf.org > Subject: Re: [Mpls-interop] Local and Remote >=20 > Hi, >=20 > > * We have a requirement in the document for "Remote Defect Indication" >=20 > > and it specifies that "The MPLS-TP OAM toolset MUST provide a function >=20 > > to enable an End Point to notify its associated End Point of the > > detection of a fault or defect that it detects on a PW, LSP or Section >=20 > > between them." I.e. in the requirement refers to remote as to the > > associated endpoint at the same layer! >=20 > Why the exclamation point? >=20 > The associated end-point at the same layer is certainly not local. Not > local =3D remote. >=20 > The defect indication comes from somewhere else (not local). That means > it is a remote indication. >=20 > > * I would like to refer to the last paragraph in your e-mail: > >> When a server layer provides a connection that is used as a link in > >> the client layer, a server layer fault (that is remote in the server > >> layer) may be reported to the client layer as a fault in the client > >> layer link (that is local in the client > >> layer) > > Assuming that we have an LSP that traversed nodes A-B-C-D-E-F-G and we >=20 > > have a fault in the link between D and E. According to the above the > > server layer needs to notify the client layer. >=20 > Well, I said "may," but I agree it would be useful. >=20 > > Is it to the client layer in nodes D and E or to the endpoints of the > > client layers, i.e. nodes A and G? >=20 > To D and E. > The server layer is only providing connectivity between D and E. > It has (and should have) no knowledge of the client services carried > over the connection. > As far as the server layer is concerned, it provides a connection from D > to E. > The client layer decides to use this connection as the link D-E in the > client layer, and decides to route the LSP AG over that link. >=20 > > If it is node D and E (this is local) they need now to notify nodes A > > and G >=20 > First question is "why?" >=20 > It may help to think of the client layer network as a single layer > network and resolve the issues there first. >=20 > Let us suppose that the fault was in the client layer at node D. How > would A and G find out about the fault? >=20 > Now suppose that the fault is in the client layer link D-E. How would A > and G find out about the fault? >=20 > Now we can come back to your question. The fault is in the server layer > between D and E. It is reported to D and E. D and E map this to a client > layer fault on the link D-E. How would A and G find out about the fault? >=20 > > but according to the requirement document and to the framework they > > may be MIPs of the LSPs but they cannot initiate OAM messages. > > Therefore, it seems that the endpoint of the server layer needs to > > notify the endpoint of the client layers of the fault (remote). And > > IMO we need to be clear about the requirement. And also to extend the > > definition in the first bullet for remote (not necessarily endpoint). >=20 > The answer is that the end points of the link (in the client layer) or > the connection (in the server layer) may be MEPs. When they detect > faults they raise alarms to their management systems. >=20 > When the fault is detected by the end points (as surely it will be) they > can perform fault localisation to isolate the fault. That is, the MEPs > can consult the MIPs and (since the MIPs are allowed to respond) > determine where the fault is. >=20 > If, in the opinion of the deployer, the end points of an LSP need to > know about the location of a fault at detection time (I have serious > doubts about > this) then he can designate every node along the path as a MEP. >=20 > > * Assuming that the failure is in the first (server) link. As a result >=20 > > we have loss of continuity in the LSPs that transmit over this failed > > link and in the PWs that are attached to these LSPs. As I understand > > from your definition, as these fault are detected by the endpoint (to > > which the link is attached), all these faults are considered locals! >=20 > No. > Please read again. >=20 > The fault is local if the fault exists in a resource that is local (in > the layer that is detecting the fault). >=20 > In your example, G detects a fault in the LSP, but G does not defect a > fault in the link FG or at the node G. Therefore the fault is not local. >=20 > Still in your example, E detects a fault in the server connection DE > (say DxyzE). > - If the fault is in E or in the link zE, the fault is local in the > server layer > - If the fault is not in E or in the link zE, the fault is not local in > the server layer In *both* cases, once the fault has been reported to > the client layer, the fault is local in the client layer (it is a > failure of the link DE). >=20 > May help you to note that local and remote are relative terms. I.e. > "local to E" is not the same as "local to G". >=20 > > Is there still a requirement to distinguish between these failures? > > Note that all of these are now local. >=20 > Yes, there is a requirement to distinguish. > No, they are not all local. >=20 >=20 > I would just like to point out that we are now very far into > implementation and not standardisation. It is not the job of the IETF > (in my personal > opinion) to tell people how to build boxes. >=20 > Thanks, > Adrian >=20 > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Adrian Farrel > Sent: Wednesday, May 06, 2009 3:16 PM > To: mpls-interop@ietf.org > Subject: [Mpls-interop] Local and Remote >=20 >=20 >=20 > I know that Malcolm and Huub are going to work on the definition of > local >=20 > and remote. >=20 >=20 >=20 > Huub usefully typed during the meeting yesterday that "remote" might be >=20 > better stated as "non-local." >=20 >=20 >=20 > Watching some emails this morning, I wonder whether part of the > confusion arises from > - where the fault is detected > - where the fault exists >=20 > A node can (IMHO) only be detected locally. That is local to the point > of detection. >=20 > A fault may be reported (to the management plane) from the node of > detection (a local report), or may be signaled to another node (through > the OAM or control plane) and reported (to the management plane) from > that other node (a remote report). >=20 > The fault that is detected may be in the detecting node, or in a > resource directly connected to that node (such as a link). This is a > local fault. >=20 > But the fault may also exist in a node or resource that is not local to > the detecting node. This is a remote fault. >=20 >=20 >=20 > If an LSP continuity check fails, the fault is detected by an end point >=20 > (local detection), but the fault might be somewhere out in the network >=20 > (remote fault). >=20 >=20 >=20 > When a server layer provides a connection that is used as a link in the >=20 > client layer, a server layer fault (that is remote in the server layer) > may >=20 > be reported to the client layer as a fault in the client layer link > (that is >=20 > local in the client layer). The client layer does not know about the > route >=20 > or resources used in the server layer (we MUST assume clean layer >=20 > separation) so the client layer does not need to know about the location > of >=20 > the server layer remote fault. If the client layer requests the server > layer >=20 > to repair the client layer link (i.e. to repair the server layer > connection) >=20 > the server layer may need to consider the location of the server layer >=20 > fault. >=20 >=20 >=20 > Am I wrong? >=20 > Is this really so complicated? >=20 >=20 >=20 > Thanks, >=20 > Adrian >=20 >=20 >=20 >=20 >=20 > _______________________________________________ >=20 > Mpls-interop mailing list >=20 > Mpls-interop@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/mpls-interop >=20 >=20 >=20 > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_001_01C9CF50.F6E621BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Malcolm,

 =

I agree in = general with your approach.

 =

Please see = inline below.

 =

Regards,

Kam

 

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

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

> On Behalf Of Malcolm = Betts

> Sent: Thursday, May 07, 2009 11:39 AM

> To: Adrian Farrel; Sprecher, Nurit (NSN - IL/Hod HaSharon); = mpls-

> interop@ietf.org

> Subject: Re: [Mpls-interop] Local and = Remote

>

> All, first apologies for my behaviour on the MEAD team call = on Tuesday,

> showing frustration is not an acceptable way of holding a technical

> discussion.

>

> Looking at the chain of email I see signs of convergence = but no easy way

> to simple text.  I saw a comment from Sasha on the = network management

> requirements draft:

>

> "Section 5.5.2 deals with alarm suppression and = defined a MUST

> requirement to suppress "superfluous alarms". = However, the notion of the

> superfluous alarm" is not defined (neither directly in = the draft nor by

> reference to other sources). Taking into account that there = are more

> than 50 messages discussing AIS/FDI on this list, it seems = that the

> superfluosity of an alarm is in the eye of the = beholder..."

>

> That triggered a thought that perhaps we have better way to describe the

> problem:

>

> Since we have very different backgrounds first some basic definitions:

>

> Fault:  An unintended event that impacts a = network.  Examples: hardware

> failure; software bug; configuration = error.

>

> Defect:  The observed perturbation of a signal. e.g. = Loss of CC

> messages:  Loss of light (following a cable cut = fault).

>

[Lam, Hing-Kam (Kam)] G.806 already has the definitions for Fault and Defect. We should reuse (base on) them as much = as possible. The key point here is the differentiation of primary and = consequential.

 

> Primary defect:  The first defect that is observed as = the result of a

> fault.

>

> Consequential defect:  Any other defect that is caused = by the same

> fault.

>

> As an example consider a node that has a 40G OTN interface carrying

> 4xODU2, one ODU2 carrying GFP mapped MPLS-TP LSPs,  = some MPLS-TP LSPs

> transit a switch/crossconnect function and leave the node; = Others

> terminate locally on a PW end point.

>

> If the fiber carrying the 40G signal is cut adjacent to the = node:

>

> The primary defect would be Loss of optical = signal.

> Loss of OTU frame, loss of ODU, loss of CC messages on the terminated

> LSP, loss of CC messages on the terminated PW are all be consequential

> defects observed in this "local" = node.

>

> At some (remote) node the LSP's and the PW's that transited = the node

> adjacent to the fiber cut will be terminated.  = Assuming no

> recovery/repair action has taken place, then a loss of CC = defect will be

> observed for both the LSP and PW at this (remote) = node.  These are

> consequential defects.

>

> So perhaps we could (in the OAM requirements document) = include a

> requirement that states:

>

> It MUST be possible to differentiate between primary and consequential

> defects.  The OAM toolkit MUST support mechanisms to = support this

> differentiation.

[Lam, Hing-Kam (Kam)] = Agree.

>

> Comments:

> 1) This includes an implicit requirement that defect = information is

> passed from a server layer to a client layer within a = node.

[Lam, Hing-Kam (Kam)] Agree. The = challenge here is, e.g. how the client layer MIP further passes the information to the = client MEP.

 

> 2) The (simple) example about is only to illustrate the = concepts, many

> other scenarios will need to be analyzed to determine if a proposed

> solution adequately addresses the = requirement.

> 3) If we take this approach do we need definitions for = fault,

> primary/consequential defect.

[Lam, Hing-Kam (Kam)] Define = primary/consequential defects, but based on the G.806 definitions of fault and defect. =

>

> In the NM requirements we could state:

>

> It MUST be possible to suppress alarms that result from consequential

> defects.

[Lam, Hing-Kam (Kam)] Agree to have such a requirement in the NM requirement document. However, if the OAM tookit = supports mechanisms to support this differentiation and suppression in the DP, = that will make the life of the MP much easier. Otherwise the poor MP will need to = perform root cause analysis to find out which/where is primary (root cause) and = which are consequential.

>

> Hope this helps.

>

>

> Malcolm = Betts

> Nortel Networks

> Phone: +1 613 763 7860 (ESN 393)

> email: betts01@nortel.com

>

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

> From: mpls-interop-bounces@ietf.org

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

> Sent: Wednesday, May 06, 2009 10:18 AM

> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); = mpls-interop@ietf.org

> Subject: Re: [Mpls-interop] Local and = Remote

>

> Hi,

>

> > * We have a requirement in the document for = "Remote Defect Indication"

>

> > and it specifies that "The MPLS-TP OAM toolset = MUST provide a function

>

> > to enable an End Point to notify its associated End = Point of the

> > detection of a fault or defect that it detects on a = PW, LSP or Section

>

> > between them." I.e. in the requirement refers to = remote as to the

> > associated endpoint at the same = layer!

>

> Why the exclamation point?

>

> The associated end-point at the same layer is certainly not = local. Not

> local =3D remote.

>

> The defect indication comes from somewhere else (not = local). That means

> it is a remote indication.

>

> > *  I would like to refer to the last paragraph in = your e-mail:

> >> When a server layer provides a connection that is = used as a link in

> >> the client layer, a server layer fault (that is = remote in the server

> >> layer) may be reported to the client layer as a = fault in the client

> >> layer link (that is local in the = client

> >> layer)

> > Assuming that we have an LSP that traversed nodes A-B-C-D-E-F-G and we

>

> > have a fault in the link between D and E. According to = the above the

> > server layer needs to notify the client = layer.

>

> Well, I said "may," but I agree it would be = useful.

>

> > Is it to the client layer in nodes D and E or to the endpoints of the

> > client layers, i.e. nodes A and G?

>

> To D and E.

> The server layer is only providing connectivity between D = and E.

> It has (and should have) no knowledge of the client = services carried

> over the connection.

> As far as the server layer is concerned, it provides a = connection from D

> to E.

> The client layer decides to use this connection as the link = D-E in the

> client layer, and decides to route the LSP AG over that = link.

>

> > If it is node D and E (this is local) they need now to = notify nodes A

> > and G

>

> First question is "why?"

>

> It may help to think of the client layer network as a = single layer

> network and resolve the issues there = first.

>

> Let us suppose that the fault was in the client layer at = node D. How

> would A and G find out about the fault?

>

> Now suppose that the fault is in the client layer link D-E. = How would A

> and G find out about the fault?

>

> Now we can come back to your question. The fault is in the = server layer

> between D and E. It is reported to D and E. D and E map = this to a client

> layer fault on the link D-E. How would A and G find out = about the fault?

>

> > but according to the requirement document and to the framework they

> > may be MIPs of the LSPs but they cannot initiate OAM messages.

> > Therefore, it seems that the endpoint of the server = layer needs to

> > notify the endpoint of the client layers of the fault (remote). And

> > IMO we need to be clear about the requirement. And = also to extend the

> > definition in the first bullet for remote (not = necessarily endpoint).

>

> The answer is that the end points of the link (in the = client layer) or

> the connection (in the server layer) may be MEPs. When they = detect

> faults they raise alarms to their management = systems.

>

> When the fault is detected by the end points (as surely it = will be) they

> can perform fault localisation to isolate the fault. That = is, the MEPs

> can consult the MIPs and (since the MIPs are allowed to = respond)

> determine where the fault is.

>

> If, in the opinion of the deployer, the end points of an = LSP need to

> know about the location of a fault at detection time (I = have serious

> doubts about

> this) then he can designate every node along the path as a = MEP.

>

> > * Assuming that the failure is in the first (server) = link. As a result

>

> > we have loss of continuity in the LSPs that transmit = over this failed

> > link and in the PWs that are attached to these LSPs. = As I understand

> > from your definition, as these fault are detected by = the endpoint (to

> > which the link is attached), all these faults are = considered locals!

>

> No.

> Please read again.

>

> The fault is local if the fault exists in a resource that = is local (in

> the layer that is detecting the fault).

>

> In your example, G detects a fault in the LSP, but G does = not defect a

> fault in the link FG or at the node G. Therefore the fault = is not local.

>

> Still in your example, E detects a fault in the server = connection DE

> (say DxyzE).

> - If the fault is in E or in the link zE, the fault is = local in the

> server layer

> - If the fault is not in E or in the link zE, the fault is = not local in

> the server layer In *both* cases, once the fault has been = reported to

> the client layer, the fault is local in the client layer = (it is a

> failure of the link DE).

>

> May help you to note that local and remote are relative = terms. I.e.

> "local to E" is not the same as "local to = G".

>

> > Is there still a requirement to distinguish between = these failures?

> > Note that all of these are now = local.

>

> Yes, there is a requirement to = distinguish.

> No, they are not all local.

>

>

> I would just like to point out that we are now very far = into

> implementation and not standardisation. It is not the job = of the IETF

> (in my personal

> opinion) to tell people how to build = boxes.

>

> Thanks,

> Adrian

>

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

> From: mpls-interop-bounces@ietf.org

> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext = Adrian Farrel

> Sent: Wednesday, May 06, 2009 3:16 PM

> To: mpls-interop@ietf.org

> Subject: [Mpls-interop] Local and Remote

>

>

>

> I know that Malcolm and Huub are going to work on the = definition of

> local

>

> and remote.

>

>

>

> Huub usefully typed during the meeting yesterday that "remote" might be

>

> better stated as "non-local."

>

>

>

> Watching some emails this morning, I wonder whether part of = the

> confusion arises from

> - where the fault is detected

> - where the fault exists

>

> A node can (IMHO) only be detected locally. That is local = to the point

> of detection.

>

> A fault may be reported (to the management plane) from the = node of

> detection (a local report), or may be signaled to another = node (through

> the OAM or control plane) and reported (to the management = plane) from

> that other node (a remote report).

>

> The fault that is detected may be in the detecting node, or = in a

> resource directly connected to that node (such as a link). = This is a

> local fault.

>

> But the fault may also exist in a node or resource that is = not local to

> the detecting node. This is a remote = fault.

>

>

>

> If an LSP continuity check fails, the fault is detected by = an end point

>

> (local detection), but the fault might be somewhere out in = the network

>

> (remote fault).

>

>

>

> When a server layer provides a connection that is used as a = link in the

>

> client layer, a server layer fault (that is remote in the = server layer)

> may

>

> be reported to the client layer as a fault in the client = layer link

> (that is

>

> local in the client layer). The client layer does not know = about the

> route

>

> or resources used in the server layer (we MUST assume clean = layer

>

> separation) so the client layer does not need to know about = the location

> of

>

> the server layer remote fault. If the client layer requests = the server

> layer

>

> to repair the client layer link (i.e. to repair the server = layer

> connection)

>

> the server layer may need to consider the location of the = server layer

>

> fault.

>

>

>

> Am I wrong?

>

> Is this really so complicated?

>

>

>

> Thanks,

>

> Adrian

>

>

>

>

>

> = _______________________________________________

>

> Mpls-interop mailing list

>

> Mpls-interop@ietf.org

>

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

>

>

>

> = _______________________________________________

> Mpls-interop mailing list

> Mpls-interop@ietf.org

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

> = _______________________________________________

> Mpls-interop mailing list

> Mpls-interop@ietf.org

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

------_=_NextPart_001_01C9CF50.F6E621BA-- From hhelvoort@chello.nl Thu May 7 15:10:14 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B553A6AC8 for ; Thu, 7 May 2009 15:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VPKxPzgJkak for ; Thu, 7 May 2009 15:10:13 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id 40B6F3A67AC for ; Thu, 7 May 2009 15:10:12 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090507221138.ZGOC24890.viefep18-int.chello.at@edge01.upc.biz>; Fri, 8 May 2009 00:11:38 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge01.upc.biz with edge id omBc1b04e3KDBhC01mBdFJ; Fri, 08 May 2009 00:11:38 +0200 X-SourceIP: 24.132.228.153 Message-ID: <4A035C98.5000708@chello.nl> Date: Fri, 08 May 2009 00:11:36 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Lam, Hing-Kam \(Kam\)" References: <077E41CFFD002C4CAB7DFA4386A53264AB4B6B@DEMUEXC014.nsn-intra.net><4A0157B1.5050408@chello.nl><73632CCC731C496AACD41C4DEA306288@your029b8cecfe><077E41CFFD002C4CAB7DFA4386A53264AB5129@DEMUEXC014.nsn-intra.net> <0BDFFF51DC89434FA33F8B37FCE363D5170DC9D8@zcarhxm2.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] Local and Remote X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 22:10:14 -0000 Hi Kam, You wrote; > */Malcolm,/* > > */I agree in general with your approach./* This is indeed a good approach. Note that the draft rosetta stone already contains the definitions for (primary) defect, fault and failure. These are in line with the definitions in G.806. So only consequential defect needs to be defined. Regards, Huub. > */Please see inline below./* > > */Regards,/* > > */Kam/* > > >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] >> On Behalf Of Malcolm Betts >> Sent: Thursday, May 07, 2009 11:39 AM >> To: Adrian Farrel; Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls- >> interop@ietf.org >> Subject: Re: [Mpls-interop] Local and Remote >> >> All, first apologies for my behaviour on the MEAD team call on Tuesday, >> showing frustration is not an acceptable way of holding a technical >> discussion. >> >> Looking at the chain of email I see signs of convergence but no easy way >> to simple text. I saw a comment from Sasha on the network management >> requirements draft: >> >> "Section 5.5.2 deals with alarm suppression and defined a MUST >> requirement to suppress "superfluous alarms". However, the notion of the >> superfluous alarm" is not defined (neither directly in the draft nor by >> reference to other sources). Taking into account that there are more >> than 50 messages discussing AIS/FDI on this list, it seems that the >> superfluosity of an alarm is in the eye of the beholder..." >> >> That triggered a thought that perhaps we have better way to describe the >> problem: >> >> Since we have very different backgrounds first some basic definitions: >> >> Fault: An unintended event that impacts a network. Examples: hardware >> failure; software bug; configuration error. >> >> Defect: The observed perturbation of a signal. e.g. Loss of CC >> messages: Loss of light (following a cable cut fault). > > */[Lam, Hing-Kam (Kam)] G.806 already has the definitions for Fault and > Defect. We should reuse (base on) them as much as possible. The key > point here is the differentiation of primary and consequential./* > >> Primary defect: The first defect that is observed as the result of a >> fault. >> >> Consequential defect: Any other defect that is caused by the same >> fault. >> >> As an example consider a node that has a 40G OTN interface carrying >> 4xODU2, one ODU2 carrying GFP mapped MPLS-TP LSPs, some MPLS-TP LSPs >> transit a switch/crossconnect function and leave the node; Others >> terminate locally on a PW end point. >> >> If the fiber carrying the 40G signal is cut adjacent to the node: >> >> The primary defect would be Loss of optical signal. >> Loss of OTU frame, loss of ODU, loss of CC messages on the terminated >> LSP, loss of CC messages on the terminated PW are all be consequential >> defects observed in this "local" node. >> >> At some (remote) node the LSP's and the PW's that transited the node >> adjacent to the fiber cut will be terminated. Assuming no >> recovery/repair action has taken place, then a loss of CC defect will be >> observed for both the LSP and PW at this (remote) node. These are >> consequential defects. >> >> So perhaps we could (in the OAM requirements document) include a >> requirement that states: >> >> It MUST be possible to differentiate between primary and consequentia >> defects. The OAM toolkit MUST support mechanisms to support this >> differentiation. > > */[Lam, Hing-Kam (Kam)] Agree./* > >> Comments: >> 1) This includes an implicit requirement that defect information is >> passed from a server layer to a client layer within a node. > > */[Lam, Hing-Kam (Kam)] Agree. The challenge here is, e.g. how the > client layer MIP further passes the information to the client MEP./* > >> 2) The (simple) example about is only to illustrate the concepts, many >> other scenarios will need to be analyzed to determine if a proposed >> solution adequately addresses the requirement. >> 3) If we take this approach do we need definitions for fault, >> primary/consequential defect. > > */[Lam, Hing-Kam (Kam)] Define primary/consequential defects, but based > on the G.806 definitions of fault and defect. /* > >> In the NM requirements we could state: >> >> It MUST be possible to suppress alarms that result from consequential >> defects. > > */[Lam, Hing-Kam (Kam)] Agree to have such a requirement in the NM > requirement document. However, if the OAM tookit supports mechanisms to > support this differentiation and suppression in the DP, that will make > the life of the MP much easier. Otherwise the poor MP will need to > perform root cause analysis to find out which/where is primary (root > cause) and which are consequential./*> > >> Hope this helps. >> >> Malcolm Betts >> Nortel Networks >> Phone: +1 613 763 7860 (ESN 393) >> email: betts01@nortel.com -- ================================================================ Always remember that you are unique...just like everyone else... From nurit.sprecher@nsn.com Fri May 8 03:51:59 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D813A6F95 for ; Fri, 8 May 2009 03:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.133 X-Spam-Level: X-Spam-Status: No, score=-4.133 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTCKdnWiyMCA for ; Fri, 8 May 2009 03:51:58 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A48C13A6D82 for ; Fri, 8 May 2009 03:51:57 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n48ArNYx022522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 May 2009 12:53:24 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n48ArNHX013368 for ; Fri, 8 May 2009 12:53:23 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 12:53:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CFCB.2BB2587B" Date: Fri, 8 May 2009 12:53:05 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264AEFE5F@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MEAD Team Meeting Thread-Index: AcnPyyq3n8RiXqe6RmWjwTdeTHeNVA== From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 08 May 2009 10:53:07.0522 (UTC) FILETIME=[2BB2D220:01C9CFCB] Subject: [Mpls-interop] MEAD Team Meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 10:51:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CFCB.2BB2587B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I am deeply sorry for my contribution to the undesired and regrettable atmosphere in the last MEAD team meeting.=20 I hope to continue contributing effectively to the discussions and work, with full respect to other opinions.=20 Best regards, Nurit =20 =20 -----------------------------------------=20 Best regards,=20 Nurit Sprecher =20 Nokia Siemens Networks GmbH & Co. KG=20 Industry Environment Senior Specialist, Carrier Ethernet Transport 3 Hanagar St. Neve Ne'eman B 45241 Hod Hasharon, Israel Tel. +972 9 7751229 Mobile +972 54 2200954=20 Email: nurit.sprecher@nsn.com =20 =20 ------_=_NextPart_001_01C9CFCB.2BB2587B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

I am deeply sorry for my contribution to the undesired and = regrettable atmosphere in the last MEAD team meeting.

I hope to continue contributing effectively to the discussions = and work, with full respect to other opinions. =

Best regards,

Nurit

 

 

----------------------------= ------------- 
Best regards,

Nurit = Sprecher

 

Nokia = Siemens Networks GmbH & Co. KG 
Industry Environment

Senior = Specialist, Carrier Ethernet Transport

3 = Hanagar St. = Neve Ne'eman B

45241 = Hod Hasharon, Israel


Tel. +972 9 7751229

Mobile +972 54 2200954 
Email: nurit.sprecher@nsn.com

 

------_=_NextPart_001_01C9CFCB.2BB2587B-- From loa@pi.nu Mon May 11 01:00:20 2009 Return-Path: X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC11028C0E2; Mon, 11 May 2009 01:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc5V2ASN3ixo; Mon, 11 May 2009 01:00:20 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 3A27228C0E0; Mon, 11 May 2009 01:00:06 -0700 (PDT) Received: from [192.36.158.68] (wdhcp-158-68.verkstad.net [192.36.158.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id BB455D404F; Mon, 11 May 2009 10:01:31 +0200 (CEST) Message-ID: <4A07DB53.2040507@pi.nu> Date: Mon, 11 May 2009 10:01:23 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Yoichi Maeda , Greg Jones , Ghani Abbas , Huub Van Helvoort , Malcolm Betts , Hing-Kam Lam , tsbsg15@itu.int, statements@ietf.org, ITU-T ad hoc team on MPLS-TP , IETF MEAD team Content-Type: multipart/mixed; boundary="------------080308020506010608000504" Cc: Loa Andersson , Olaf Kolkman , Russ Housley , Scott Bradner , Adrian Farrel Subject: [Mpls-interop] liaison on MPLS-TP document status for the meeting in Sophia Antipolis X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 08:00:20 -0000 This is a multi-part message in MIME format. --------------080308020506010608000504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, please find a liaison on the status of the IETF MPLS-TP documents for the SG15 interim meeting in Sophia Antipolis May 25-29, 2009 included. /Loa -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu --------------080308020506010608000504 Content-Type: application/msword; name="status-of-mpls-tp-docs-for-Sophia-001.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="status-of-mpls-tp-docs-for-Sophia-001.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAWQAAAAAA AAAAEAAAWwAAAAEAAAD+////AAAAAFgAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAf4AJBAAA8BK/AAAAAAAAEAAAAAAACAAA tyoAAA4AYmpiaubm5uYAAAAAAAAAAAAAAAAAAAAAAAAJBBYAMEgAAISMAQCEjAEAtyIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAALcAAAAAAGoIAAAAAAAAaggAAK0VAAAAAAAArRUAAAAAAACtFQAA AAAAAK0VAAAAAAAArRUAABQAAAAAAAAAAAAAAP////8AAAAAwRUAAAAAAADBFQAAAAAAAMEV AAAAAAAAwRUAAFwAAAAdFgAAHAAAAMEVAAAAAAAApTAAAKwBAAA5FgAA7gAAACcXAAAAAAAA JxcAAAAAAAAnFwAAAAAAACcXAAAAAAAAHhgAAAAAAAAeGAAAAAAAAB4YAAAAAAAAJDAAAAIA AAAmMAAAAAAAACYwAAAAAAAAJjAAAAAAAAAmMAAAAAAAACYwAAAAAAAAJjAAACQAAABRMgAA ogIAAPM0AAB2AAAASjAAABUAAAAAAAAAAAAAAAAAAAAAAAAArRUAAAAAAAAeGAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAeGAAAAAAAAB4YAAAAAAAAHhgAAAAAAAAeGAAAAAAAAEowAAAAAAAA AAAAAAAAAACtFQAAAAAAAK0VAAAAAAAAJxcAAAAAAAAAAAAAAAAAACcXAAD3AAAAXzAAABYA AAAIHAAAAAAAAAgcAAAAAAAACBwAAAAAAAAeGAAAqgIAAK0VAAAAAAAAJxcAAAAAAACtFQAA AAAAACcXAAAAAAAAJDAAAAAAAAAAAAAAAAAAAAgcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHhgAAAAAAAAkMAAAAAAAAAAAAAAAAAAA CBwAAAAAAAAIHAAAxgAAAGYtAACQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGi8AAAAAAAAnFwAA AAAAAP////8AAAAAgJpkA/TRyQEAAAAAAAAAAMEVAAAAAAAAyBoAAMoAAAD2LQAAFAAAAAAA AAAAAAAAEDAAABQAAAB1MAAAMAAAAKUwAAAAAAAACi4AABABAABpNQAAAAAAAJIbAAB2AAAA aTUAACgAAAAaLwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaLwAAJgAAAGk1AAAAAAAAAAAAAAAAAACtFQAA AAAAAEAvAADQAAAAAAAAAAAAAAAAAAAAAAAAAAgcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHhgAAAAAAAAeGAAAAAAAAB4YAAAAAAAA SjAAAAAAAABKMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACBwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4YAAAAAAAAHhgAAAAAAAAeGAAA AAAAAKUwAAAAAAAAHhgAAAAAAAAeGAAAAAAAAB4YAAAAAAAAHhgAAAAAAAAAAAAAAAAAAP// //8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAA AAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAGk1AAAAAAAAHhgAAAAAAAAeGAAA AAAAAB4YAAAAAAAAHhgAAAAAAAAeGAAAAAAAAB4YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeGAAAAAAAAB4YAAAAAAAA HhgAAAAAAABqCAAACQwAAHMUAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRvOg1Zb2ljaGkgTWFlZGEgPCB5b2ljaGkubWFlZGFA bnR0LWF0LmNvLmpwID4LR3JlZyBKb25lcyA8Z3JlZy5qb25lc0BpdHUuaW50PgtHaGFuaSBB YmJhcyA8Z2hhbmkuYWJiYXNAZXJpY3Nzb24uY29tPgtIdXViIFZhbiBIZWx2b29ydCA8aGhl bHZvb3J0QGh1YXdlaS5jb20+C01hbGNvbG0gQmV0dHMgPG1hbGNvbG0uYmV0dHNAaHVhd2Vp LmNvbT4LSGluZy1LYW0gTGFtIDxoa2xhbUBhbGNhdGVsLWx1Y2VudC5jb20+Czx0c2JzZzE1 QGl0dS5pbnQ+CzxzdGF0ZW1lbnRzQGlldGYub3JnPgtJVFUtVCBhZCBob2MgdGVhbSBvbiBN UExTLVRQIDxhaG1wbHMtdHBAbGlzdHMuaXR1LmludD4NRnJvbToNTG9hIEFuZGVyc3NvbiA8 bG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20+DUNDOiANRGF2aWQgV2FyZCA8ZHdhcmRAY2lz Y28uY29tPgtBZHJpYW4gRmFycmVsIDxhZHJpYW4uZmFycmVsQGh1YXdlaS5jb20+C1Jvc3Mg Q2FsbG9uIDxyY2FsbG9uQGp1bmlwZXIubmV0PgtTY290dCBCcmFkbmVyIDxzb2JAaGFydmFy ZC5lZHU+C1J1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+C09sYWYgS29sa21h biA8b2xhZkBOTG5ldExhYnMubmw+DUlFVEYgTUVBRCB0ZWFtIDxtcGxzLWludGVyb3BAaWV0 Zi5vcmc+DURhdGU6IE1heSAxMSwgMjAwOQ1JVFUtVCBTRzE1LCBRIDkvMTUsIFExMC8xNSwg UTEyLzE1IGFuZCBRMTQvMTUNU291cmNlOiBJRVRGIE1FQUQgdGVhbQ1UaXRsZTogVGhlIHN0 YXR1cyBvZiBJRVRGIE1QTFMtVFAgZG9jdW1lbnRzIGZvciB0aGUgU0cxNSBpbnRlcmltIG1l ZXRpbmcgaW4gU29waGlhIEFudGlwb2xpcy4NRm9yOiBGb3IgQWN0aW9uDURlYWRsaW5lOiBN YXkgMjUsIDIwMDkgKHNlZSBiZWxvdykNRGVhciBNci4gTWFlZGEsIE1yLiBBYmJhcywgTXIu IHZhbiBIZWx2b29ydCwgTXIuIEJldHRzIGFuZCBNci4gTGFtDVRoZSBJVFUtVCBhZCBob2Mg dGVhbSBvbiBNUExTLVRQIGhhcyBlYXJsaWVyIGluZGljYXRlZCB0aGUgZG9jdW1lbnRzIHRo YXQgdGhlIElUVS1UIG5lZWRzIHNvIHRoYXQgaXQgaXMgYWJsZSB0byBzdGFydCBkcmFmdGlu ZyB3b3JrIG9uIHRoZSBuZXcgTVBMUy1UUCBSZWNvbW1lbmRhdGlvbnMgYXQgdGhlIGludGVy aW0gbWVldGluZyBpbiBTb3BoaWEgQW50aXBvbGlzIE1heSAyNSCWIDI5LCAyMDA5LiBUaGUg bGlhaXNvbiByZXBvcnRzIG9uIHRoZSBzdGF0dXMgb2YgdGhvc2UgZG9jdW1lbnRzLg1SZXF1 aXJlbWVudCBkb2N1bWVudHMNEyBIWVBFUkxJTksgImh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvaWR0cmFja2VyL2RyYWZ0LWlldGYtbXBscy10cC1yZXF1aXJlbWVudHMvIiAUZHJh ZnQtaWV0Zi1tcGxzLXRwLXJlcXVpcmVtZW50cxUuIFRoaXMgZG9jdW1lbnQgd2lsbCBiZSBv biB0aGUgc3RhbmRhcmRzIHRyYWNrLiBBIG5ldyB2ZXJzaW9uIHdpbGwgYmUgYXZhaWxhYmxl IGluIHRpbWUgZm9yIHRoZSBTb3BoaWEgQW50aXBvbGlzIG1lZXRpbmcuC1RoZSBkb2N1bWVu dCBpcyBzdGFibGUgYW5kIHRoZXJlIHdpbGwgYmUgbm8gcHJvYmxlbSB0byB1c2UgaXQgdG8g c3RhcnQgZHJhZnRpbmcgd29yayBmb3IgdGhlIG5ldyBSZWNvbW1lbmRhdGlvbnMuDRMgSFlQ RVJMSU5LICJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lkdHJhY2tlci9kcmFmdC1p ZXRmLW1wbHMtdHAtb2FtLXJlcXVpcmVtZW50cy8iIBRkcmFmdC1pZXRmLW1wbHMtdHAtb2Ft LXJlcXVpcmVtZW50cxUuIFRoaXMgZG9jdW1lbnQgd2lsbCBiZSBvbiB0aGUgc3RhbmRhcmRz IHRyYWNrLiBBIG5ldyB2ZXJzaW9uIGlzIHBsYW5uZWQgcHJpb3IgdG8gdGhlIFNvcGhpYSBB bnRpcG9saXMgbWVldGluZy4LVGhlIGRvY3VtZW50IGlzIHN0YWJsZSBhbmQgdGhlcmUgd2ls bCBiZSBubyBwcm9ibGVtIHRvIHVzZSBpdCB0byBzdGFydCBkcmFmdGluZyB3b3JrIGZvciB0 aGUgbmV3IFJlY29tbWVuZGF0aW9ucy4NEyBIWVBFUkxJTksgImh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvaWR0cmFja2VyL2RyYWZ0LWlldGYtbXBscy10cC1ubS1yZXEvIiAUZHJh ZnQtaWV0Zi1tcGxzLXRwLW5tLXJlcRUuIFRoaXMgZG9jdW1lbnQgaXMgY3VycmVudGx5IGlu IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLiBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwg d2lsbCBlbmQgYmVmb3JlIHRoZSBTb3BoaWEgQW50aXBvbGlzIG1lZXRpbmcsIGFuZCBhIG5l dyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpcyBwbGFubmVkIGFyb3VuZCB0aGUgdGltZSBvZiB0 aGUgU29waGlhIEFudGlwb2xpcyBtZWV0aW5nLiBJZiB3ZSBhcmUgbm90IGFibGUgdG8gcHVi bGlzaCBpbiB0aW1lIGZvciB0aGUgbWVldGluZywgdHdvIG9mIHRoZSBjby1hdXRob3JzIHdp bGwgYXR0ZW5kIHRoZSBTb3BoaWEgQW50aXBvbGlzIG1lZXRpbmcgYW5kIHdpbGwgYmUgYWJs ZSB0byBnaXZlIHRoZSBkZXRhaWxzIG9mIHRoZSBwZW5kaW5nIHVwZGF0ZXMuC1RoZSBkb2N1 bWVudCBpcyBzdGFibGUgYW5kIHRoZXJlIHdpbGwgYmUgbm8gcHJvYmxlbSB0byB1c2UgaXQg dG8gc3RhcnQgZHJhZnRpbmcgd29yayBmb3IgdGhlIG5ldyBSZWNvbW1lbmRhdGlvbnMuDUZy YW1ld29yayBkb2N1bWVudHMNEyBIWVBFUkxJTksgImh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvaWR0cmFja2VyL2RyYWZ0LWlldGYtbXBscy10cC1mcmFtZXdvcmsvIiAUZHJhZnQt aWV0Zi1tcGxzLXRwLWZyYW1ld29yaxUuIFRoaXMgZG9jdW1lbnQgd2lsbCBiZSBwdWJsaXNo ZWQgYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMgd2l0aCBJRVRGIGNvbnNlbnN1cy4gTm8gbmV3 IHZlcnNpb24gaXMgcGxhbm5lZCBiZWZvcmUgdGhlIFNvcGhpYSBBbnRpcG9saXMgbWVldGlu Zy4LVGhlIGRvY3VtZW50IGlzIHN0YWJsZSBhbmQgdGhlcmUgd2lsbCBiZSBubyBwcm9ibGVt IHRvIHVzZSBpdCB0byBzdGFydCBkcmFmdGluZyB3b3JrIGZvciB0aGUgbmV3IFJlY29tbWVu ZGF0aW9ucy4NEyBIWVBFUkxJTksgImh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaWR0 cmFja2VyL2RyYWZ0LWlldGYtbXBscy10cC1vYW0tZnJhbWV3b3JrLyIgFGRyYWZ0LWlldGYt bXBscy10cC1vYW0tZnJhbWV3b3JrFS4gVGhpcyBkb2N1bWVudCB3aWxsIGJlIHB1Ymxpc2hl ZCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQyB3aXRoIElFVEYgY29uc2Vuc3VzLiBObyBuZXcg dmVyc2lvbiBpcyBwbGFubmVkIGJlZm9yZSB0aGUgU29waGlhIEFudGlwb2xpcyBtZWV0aW5n LgtUaGUgZG9jdW1lbnQgaXMgc3RhYmxlIGFuZCB0aGVyZSB3aWxsIGJlIG5vIHByb2JsZW0g dG8gdXNlIGl0IHRvIHN0YXJ0IGRyYWZ0aW5nIHdvcmsgZm9yIHRoZSBuZXcgUmVjb21tZW5k YXRpb25zLg0TIEhZUEVSTElOSyAiaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pZHRy YWNrZXIvZHJhZnQtbWFuc2ZpZWxkLW1wbHMtdHAtbm0tZnJhbWV3b3JrLyIgFGRyYWZ0LW1h bnNmaWVsZC1tcGxzLXRwLW5tLWZyYW1ld29yaxUuIFRoaXMgZG9jdW1lbnQgaXMgbm90IHll dCBhY2NlcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIEl0IHdpbGwgYmUgcHVi bGlzaGVkIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDIHdpdGggSUVURiBjb25zZW5zdXMuIE5v IG5ldyB2ZXJzaW9uIGlzIHBsYW5uZWQgYmVmb3JlIHRoZSBTb3BoaWEgQW50aXBvbGlzIG1l ZXRpbmcuC1RoZSBkb2N1bWVudCBpcyByZWFzb25hYmx5IHN0YWJsZSBhbmQgdGhlcmUgd2ls bCBiZSBwb3NzaWJsZSB0byB1c2UgaXQgdG8gc3RhcnQgZHJhZnRpbmcgd29yayBmb3IgdGhl IG5ldyBSZWNvbW1lbmRhdGlvbnMuIEhvd2V2ZXIgY2xvc2UgY29vcGVyYXRpb24gd2l0aCB0 aGUgZHJhZnQgZWRpdG9ycyBpcyByZWNvbW1lbmRlZC4gVHdvIG9mIHRoZSBlZGl0b3JzIG9m IHRoaXMgZG9jdW1lbnQgd2lsbCBiZSBwcmVzZW50IGluIFNvcGhpYSBBbnRpcG9saXMgYW5k IHdpbGwgYmUgYWJsZSB0byBnaXZlIGRldGFpbHMgb2YgdGhlIHBlbmRpbmcgdXBkYXRlcy4N EyBIWVBFUkxJTksgImh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaWR0cmFja2VyL2Ry YWZ0LWlldGYtbXBscy10cC1zdXJ2aXZlLWZ3ay8iIBRkcmFmdC1pZXRmLW1wbHMtdHAtc3Vy dml2ZS1md2sVLiBUaGlzIGRvY3VtZW50IHdhcyByZWNlbnRseSBhY2NlcHRlZCBhcyBhIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQgYW5kIHdpbGwgYmUgcHVibGlzaGVkIGFzIGFuIEluZm9y bWF0aW9uYWwgUkZDIHdpdGggSUVURiBjb25zZW5zdXMuIEEgbmV3IHZlcnNpb24gaXMgcGxh bm5lZCwgYnV0IHdlIGRvbpJ0IGtub3cgaWYgaXQgd2lsbCBwdWJsaXNoZWQgYmVmb3JlIHRo ZSBTb3BoaWEgQW50aXBvbGlzIG1lZXRpbmcuIFR3byBvZiB0aGUgZWRpdG9ycyBvZiB0aGlz IGRvY3VtZW50IHdpbGwgYmUgcHJlc2VudCBpbiBTb3BoaWEgQW50aXBvbGlzIGFuZCB3aWxs IGJlIGFibGUgdG8gZ2l2ZSBkZXRhaWxzIG9mIHRoZSBwZW5kaW5nIHVwZGF0ZXMuC1RoZSBk b2N1bWVudCBpcyByZWFzb25hYmx5IHN0YWJsZSBhbmQgdGhlcmUgc2hvdWxkIGJlIG5vIHBy b2JsZW0gdG8gdXNlIGl0IHRvIHN0YXJ0IGRyYWZ0aW5nIHdvcmsgZm9yIHRoZSBuZXcgUmVj b21tZW5kYXRpb25zLiBCdXQgdGhlIGF1dGhvcnMgb2YgdGhlIFJlY29tbWVuZGF0aW9ucyBz aG91bGQgYmUgYXdhcmUgcG90ZW50aWFsIGNoYW5nZXMuDVNvbHV0aW9ucyBkb2N1bWVudHMg DRMgSFlQRVJMSU5LICJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lkdHJhY2tlci9k cmFmdC1pZXRmLW1wbHMtdHAtZ2FjaC1nYWwvIiAUZHJhZnQtaWV0Zi1tcGxzLXRwLWdhY2gt Z2FsFS4gVGhpcyBkb2N1bWVudCBpcyBvbiB0aGUgc3RhbmRhcmRzIHRyYWNrLiBBIHJlcXVl c3QgZm9yIHB1YmxpY2F0aW9uIGhhcyBiZWVuIHNlbnQgdG8gSUVTRyBhbmQgaXQgaXMgY3Vy cmVudGx5IGluIElFVEYgbGFzdCBjYWxsIHRoYXQgd2lsbCBlbmQgb24gTWF5IDE0dGguC1Ro ZSBkb2N1bWVudCBpcyBzdGFibGUgYW5kIHRoZXJlIHdpbGwgYmUgbm8gcHJvYmxlbSB0byB1 c2UgaXQgdG8gc3RhcnQgZHJhZnRpbmcgd29yayBmb3IgdGhlIG5ldyBSZWNvbW1lbmRhdGlv bnMuDRMgSFlQRVJMSU5LICJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lkdHJhY2tl ci9kcmFmdC1pZXRmLW1wbHMtdHAtZ2FjaC1kY24vIiAUZHJhZnQtaWV0Zi1tcGxzLXRwLWdh Y2gtZGNuFS4gVGhpcyBkb2N1bWVudCB3aWxsIGJlIG9uIHRoZSBzdGFuZGFyZHMgdHJhY2ss IGEgbmV3IHZlcnNpb24gaXMgcGxhbm5lZCBwcmlvciB0byB0aGUgU29waGlhIEFudGlwb2xp cyBtZWV0aW5nLiBUaGlzIGRvY3VtZW50IGhhcyBhIGRlcGVuZGVuY3kgb24gb25lIG9mIHRo ZSBJRVRGIGRvY3VtZW50cyB0aGF0IGhhcyBub3QgYmVlbiByZXF1ZXN0ZWQgZm9yIHRoZSBT b3BoaWEgQW50aXBvbGlzIG1lZXRpbmcsIHRoZSCTEyBIWVBFUkxJTksgImh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvaWR0cmFja2VyL2RyYWZ0LWJyeWFudC1tcGxzLXRwLWFjaC10 bHYvIiAUZHJhZnQtYnJ5YW50LW1wbHMtdHAtYWNoLXRsdhWULgtUaGUgZG9jdW1lbnQgaXMg c3RhYmxlIGFuZCB0aGVyZSB3aWxsIGJlIG5vIHByb2JsZW0gdG8gdXNlIGl0IHRvIHN0YXJ0 IGRyYWZ0aW5nIHdvcmsgZm9yIHRoZSBuZXcgUmVjb21tZW5kYXRpb25zLg1tcGxzLXRwLWxp bmVhci1wcm90ZWN0aW9uLiBBIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIGEgc29sdXRpb24g Zm9yIGxpbmVhciBwcm90ZWN0aW9uIHdpbGwgYmUgcHVibGlzaGVkIG9uIHRoZSBzdGFuZGFy ZHMgdHJhY2suC0N1cnJlbnRseSB3ZSBkb26SdCBoYXZlIGEgc3RhYmxlIGRvY3VtZW50IHRo YXQgY2FuIGJlIHVzZWQgYXMgYmFzaXMgZm9yIGRyYWZ0aW5nIHdvcmsgb24gbmV3IFJlY29t bWVuZGF0aW9ucy4NbXBscy10cC1vYW0tcHJvdG9jb2wtZGVmLiBPbmUgb3IgbW9yZSBkb2N1 bWVudHMgdGhhdCBzcGVjaWZ5IGEgcHJvdG9jb2wgTVBMUy1UUCBPQU0gc29sdXRpb24gd2ls bCBiZSBwdWJsaXNoZWQgb24gdGhlIHN0YW5kYXJkcyB0cmFjay4LQ3VycmVudGx5IHdlIGRv bpJ0IGhhdmUgYSBzdGFibGUgZG9jdW1lbnQgdGhhdCBjYW4gYmUgdXNlZCBhcyBiYXNpcyBm b3IgZHJhZnRpbmcgd29yayBvbiBuZXcgUmVjb21tZW5kYXRpb25zLiBJdCBpcyBsaWtlbHkg dGhhdCB3ZSB3b26SdCBzdGFydCBwcm9kdWNpbmcgdGhlc2UgZG9jdW1lbnQgdW50aWwgYWZ0 ZXIgdGhlIElFVEYgbWVldGluZyBpbiBTdG9ja2hvbG0gZW5kIG9mIEp1bHkgMjAwOS4NEyBI WVBFUkxJTksgImh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaWR0cmFja2VyL2RyYWZ0 LWJyeWFudC1tcGxzLXRwLWFjaC10bHYvIiAUZHJhZnQtYnJ5YW50LW1wbHMtdHAtYWNoLXRs dhUuIFRoaXMgZG9jdW1lbnQgd2lsbCBiZSBwdWJsaXNoZWQgYXMgYSBzdGFuZGFyZHMgdHJh Y2sgZG9jdW1lbnQsIGJ1dCBoYXMgbm90IGJlZW4gcmVxdWVzdGVkIGZvciB0aGUgU29waGlh IEFudGlwb2xpcyBtZWV0aW5nLiBUaGVyZSBhcmUgYWN0dWFsIGRlcGVuZGVuY2llcyB0byB0 aGlzIGRvY3VtZW50IGZvciBvbmUgb2YgdGhlIGRvY3VtZW50cyBpbiB0aGUgbGlzdCBhYm92 ZSwgYnV0IHRoZXJlIGFyZSBhbHNvIHBvdGVudGlhbCBkZXBlbmRlbmNpZXMgZm9yIGFsbCB0 aGUgT0FNIHByb3RvY29sIGRvY3VtZW50cy4LVGhlIGRvY3VtZW50IGlzIG5vdCBzdGFibGUg ZW5vdWdoIHRvIGJlIHVzZWQgYXMgYmFzaXMgZm9yIGRyYWZ0aW5nIHdvcmsgb24gdGhlIG5l dyBSZWNvbW1lbmRhdGlvbnMgd2l0aG91dCBvdXRtb3N0IGNhcmUuDW1wbHMtdHAtbmFtaW5n LWNvbnZlbnRpb25zIFRoaXMgZG9jdW1lbnQgd2lsbCBiZSBwdWJsaXNoZWQgYXMgYSBzdGFu ZGFyZHMgdHJhY2sgZG9jdW1lbnQuIFRoZSBpbnRlbnRpb24gaXMgdGhhdCBpdCB3aWxsIGNv dmVyIHRoZSBhcmNoaXRlY3R1cmFsIGNvbnNpZGVyYXRpb25zIGZvciBuYW1pbmcgYW5kIGFk ZHJlc3NpbmcgdGhhdCBhcmUgbmVjZXNzYXJ5IHRvIHByb2dyZXNzIHRoZSBNUExTLVRQIHNv bHV0aW9ucyBkb2N1bWVudHMuIEEgZmlyc3QgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgaXMg cGxhbm5lZCBmb3IgdGhlIHNhbWUgdGltZSBmcmFtZSBhcyB0aGUgU29waGlhIEFudGlwb2xp cyBtZWV0aW5nLgtUaGUgZG9jdW1lbnQgaXMgbm90IHN0YWJsZSBlbm91Z2ggdG8gYmUgdXNl ZCBhcyBiYXNpcyBmb3IgZHJhZnRpbmcgd29yayBvbiB0aGUgbmV3IFJlY29tbWVuZGF0aW9u cy4LDVRlcm1pbm9sb2d5IGRvY3VtZW50cw0TIEhZUEVSTElOSyAiaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9pZHRyYWNrZXIvZHJhZnQtaGVsdm9vcnQtbXBscy10cC1yb3NldHRh LXN0b25lLyIgFGRyYWZ0LWhlbHZvb3J0LW1wbHMtdHAtcm9zZXR0YS1zdG9uZRUgVGhpcyBk b2N1bWVudCB3aWxsIGJlIHB1Ymxpc2hlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQyB3aGVu IHRoZSBmaXJzdCByb3VuZCBvZiBNUExTLVRQIGRvY3VtZW50cyBhcmUgZG9uZS4gSXQgaXMg YSB0ZXJtaW5vbG9neSBkb2N1bWVudCB0aGF0IGlzIGNvbnRpbnVvdXNseSB1cGRhdGVkOyBp dCBpcyBwb3NzaWJsZSB0aGF0IHdlIHdpbGwgaGF2ZSBhIG5ldyBkcmFmdCBiZWZvcmUgdGhl IFNvcGhpYSBBbnRpcG9saXMgbWVldGluZy4LTmV2ZXJ0aGVsZXNzIHRoaXMgZG9jdW1lbnQg d2lsbCBiZSB2ZXJ5IHVzZWZ1bCB3aGVuIHRoZSBkcmFmdGluZyB3b3JrIG9uIHRoZSBuZXcg UmVjb21tZW5kYXRpb25zIHN0YXJ0Lg1XZSB3aWxsIG5lZWQgYSByZXNwb25zZSB0byB0aGlz IGxpYWlzb24gdG8gY29uZmlybSB0aGF0IHRoZSBzdGF0dXMgZ2l2ZW4gYWJvdmUgaXMgc3Vm ZmljaWVudCBhbmQgdW5kZXJzdG9vZC4NVGhlcmUgYXJlIHF1aXRlIGEgZmV3IGJpdHMgb2Yg cHJvY2VzcyB0aGF0IG5lZWQgdG8gYmUgc29ydGVkIG91dCB0byBtYWtlIHRoZSBJRVRGIGFu ZCBJVFUtVCBwcm9jZXNzZXMgd29yayB3ZWxsIHRvZ2V0aGVyLiAgV2Ugc3VnZ2VzdCB0aGF0 IHRpbWUgaXMgc2V0IGFzaWRlIGluIFNvcGhpYSBBbnRpcG9saXMgdG8gZGlzY3VzcyB0aGlz IGluIGEgY2xvc2VkIG1lZXRpbmcgb2YgdGhlIElFVEYgd2cgY2hhaXJzLCB0aGUgTUVBRCB0 ZWFtIGNoYWlyLCB0aGUgSUVURiBBRHMsIHRoZSBjaGFpcnMgb2YgdGhlIElUVS1UIGFkIGhv YyB0ZWFtIG9uIE1QTFMtVFAsIHRoZSBTRzE1IGNoYWlyLCBhbmQgdGhlIHJhcHBvcnRldXJz IG9mIFEgOS8xNSwgUTEwLzE1LCBRMTIvMTUsIGFuZCBRMTQvMTUuDVdlIGhhdmUgc2V0IHRo ZSBkZWFkbGluZSBmb3IgdGhpcyBsaWFpc29uIHRvIE1heSAyNSAoc3RhcnRpbmcgZGF5IGZv ciB0aGUgU29waGlhIEFudGlwb2xpcyBtZWV0aW5nKSwgYnV0IHRoZSBjaGFuY2VzIHRoYXQg d2UgY2FuIGFkZHJlc3MgcHJvYmxlbXMgb3IgY2xhcmlmeSBpc3N1ZXMgaW5jcmVhc2UgaWYg dGhlIHJlc3BvbnNlIG9yIHBhcnQgb2YgdGhlIHJlc3BvbnNlIGlzIHJlY2VpdmVkIHNvb25l ci4NDVdlIHdvdWxkIGFsc28gbGlrZSB0byBwb2ludCB0byB0aGUgTVBMUy1UUCB3aWtpOg0T IEhZUEVSTElOSyAiaHR0cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvbWlzYy9tcGxzLXRwLyIg FGh0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL21pc2MvbXBscy10cC8VCw1UaGlzIHdpa2kg d2lsbCBnaXZlIGZ1cnRoZXIgYW5kIG1vcmUgZGV0YWlsZWQgaW5mb3JtYXRpb24gb24gdGhl IHByb2dyZXNzIG9mIHRoZSBNUExTLVRQIHByb2plY3QgYW5kIGNhbiBiZSB1c2VkIHRvIGZp bmQgdGhlIGxhdGVzdCByZXZpc2lvbnMgb2YgdGhlIGRyYWZ0cyBtZW50aW9uZWQgYWJvdmUu DQ1TdG9ja2hvbG0gTWF5IDA4LCAyMDA5DU9uIGJlaGFsZiBvZiB0aGUgTUVBRCB0ZWFtIGFu ZCB0aGUgZG9jdW1lbnQgZWRpdG9ycw1Mb2EgQW5kZXJzc29uDU1FQUQgdGVhbSBDaGFpcg0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAIAAAECAAAEggAABMIAAAsCAAALQgAAK4IAAC2CAAAvAgAAMIIAADVCAAA1ggAAO4I AADvCAAA8QgAAAAJAAABCQAAAgkAAAMJAAAWCQAAFwkAABgJAABOCQAATwkAAGcJAAB+CQAA kAkAAJEJAADx3sjeyN643rjepd6llICU3nClcKVflPFT8UcAAAAWFmgcZDYAQ0oUAF5KAgBf SA0EYUoUAAAWFmgqaRsAQ0oUAF5KAgBfSA0EYUoUAAAgFWiYRkwAFmiYRkwAQ0oUAF5KAgBh ShQAbUgJBHNICQQAHhZomEZMAENKFABeSgIAX0gNBGFKFABtSAkEc0gJBAAmFWiYRkwAFmge HlUAQ0oUAF5KAgBhShQAbUgJBHNICQR3aCNQqwAAIBVomEZMABZoHh5VAENKFABeSgIAYUoU AG1ICQRzSAkEACQVaJhGTAAWaJhGTABDShQAXkoCAF9IDQRhShQAbUgJBHNICQQAHhZovAYn AENKFABeSgIAX0gNBGFKFABtSAkEc0gJBAAqFWiYRkwAFmgeHlUAF2j+JDUAQ0oUAF5KAgBf SA0EYUoUAG1ICQRzSAkEACQVaJhGTAAWaB4eVQBDShQAXkoCAF9IDQRhShQAbUgJBHNICQQA HBVoF1JUABZoHh5VAENKFABeSgIAX0gNBGFKFAAbAAgAAAQIAABPCQAAVQkAAIAJAACFCQAA UgoAAHkKAACMCgAAugoAANEKAAAvCwAAPwsAAGILAAClCwAAwAwAANYMAAA5DgAAmg8AAAgS AAAcEgAAjRMAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA9gAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA6wAAAAAAAAAA AAAAAOsAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAAAM0AAAAAAAAAAAAA AADDAAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAMMAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAA uQAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAomAAtGBQAUpHgAZ2QzOygACgAACiYAC0YEABSk eABnZLIq8QAABgAAFKR4AGdksirxAAAGAAAUpHgAZ2Q3CSwACwAAFKR4ADckADgkAEgkAGdk NwksAAAEAABnZBdSVAAACgAANyQAOCQAQCYASCQAZ2Q3CSwACQAANyQAOCQASCQAZ2Q3CSwA ABWRCQAAoAkAAKIJAAC3CQAAvgkAAL8JAADJCQAAygkAAMsJAADsCQAA7QkAAAwKAAANCgAA MAoAADEKAABRCgAAUgoAAHkKAACLCgAAjAoAANEKAADYCgAAHQsAAC0LAAAuCwAALwsAADQL AAA+CwAAPwsAAGELAADx5fHZ8dnxyruou8q7ypXKu42Cd3BsaGxkd1xUTAAAAA4WaCF2kABe SgIAX0gNBAAOFmiLLZIAXkoCAF9IDQQADhZosirxAF5KAgBfSA0EAAYWaB4eVQAABhZogS0o AAAGFmhdGjIAAAwVaBdSVAAWaB4eVQAAFBVoF1JUABZoHh5VAF5KAgBfSA0EABQVaBdSVAAW aDcJLABeSgIAX0gNBAAOFmi8BicAXkoCAF9IDQQAJBVoF1JUABZoHh5VAENKFABeSgIAX0gN BGFKFABtSAkEc0gJBAAkFWgXUlQAFmg3CSwAQ0oUAF5KAgBfSA0EYUoUAG1ICQRzSAkEABwV aBdSVAAWaB4eVQBDShQAXkoCAF9IDQRhShQAABwVaBdSVAAWaDcJLABDShQAXkoCAF9IDQRh ShQAABYWaLwGJwBDShQAXkoCAF9IDQRhShQAABYWaBxkNgBDShQAXkoCAF9IDQRhShQAABwV aBxkNgAWaBxkNgBDShQAXkoCAF9IDQRhShQAHWELAABiCwAAhQsAAI0LAACkCwAApQsAAO8L AADzCwAA/wsAAAAMAAACDAAADAwAAGwMAAB2DAAAiQwAAL8MAADADAAA1gwAANcMAAAsDQAA LQ0AAEwNAABNDQAATg0AAE8NAABQDQAAew0AAHwNAAB9DQAAfg0AALQNAAC+DQAAxQ0AAMYN AAACDgAABQ4AADkOAAD17OHs2Mi4yLjIuMioyLiYiIB8gHCAbIi4iFyIuIioiLiIuIgfFmjC YYkAQioBUEoAAF5KAgBtSAkEcGgAAAAAc0gJBAYWaMJhiQAAFhZosirxADBKFgA+KgFCKgJw aAAA/wAABhZosirxAAAPA2oAAAAAFmiyKvEAVQgBHxZosirxAEIqAVBKAABeSgIAbUgJBHBo AAAAAHNICQQfFmiNPmcAQioBUEoAAF5KAgBtSAkEcGgAAAAAc0gJBB8WaJpRIwBCKgFQSgAA XkoCAG1ICQRwaAAAAABzSAkEHxZovAYnAEIqAVBKAABeSgIAbUgJBHBoAAAAAHNICQQfFmhd GjIAQioBUEoAAF5KAgBtSAkEcGgAAAAAc0gJBBAVaBdSVAAWaEov3gBeSgIAABQVaBdSVAAW aB4eVQBeSgIAX0gNBAAQFWgXUlQAFmgeHlUAXkoCAAAUFWgXUlQAFmghdpAAXkoCAF9IDQQk OQ4AADoOAACTDgAAlA4AALcOAAC4DgAAuQ4AALoOAAC7DgAA5g4AAOcOAADoDgAA6Q4AAA4P AAAeDwAAKA8AAGMPAABmDwAAmg8AAJsPAADqDwAA6w8AAAQQAAAFEAAABhAAAAcQAAAIEAAA PBAAAD0QAAA+EAAAPxAAAG4QAAB+EAAAiBAAAIwQAADAEAAAyRAAANkQAADmEAAA6RAAAPAQ AAD2EAAA+RAAAEcRAABREQAAZREAAJYRAADREQAA1BEAAAcSAAAREgAAGhIAABsSAAAcEgAA 9/P35/fj89/z4/Pf89vzy7vL9/P35/fj89/z3/Pf89vz3/O327fz3/Pf87Pzr5+7n4yfjMsA AAAAAAAAAAAAACUVaLIq8QAWaLIq8QBCKgFQSgAAXkoCAG1ICQRwaAAAAABzSAkEHxZoMzso AEIqAVBKAABeSgIAbUgJBHBoAAAAAHNICQQGFmgzOygAAAYWaJpRIwAABhZoyk/0AAAfFmi8 BicAQioBUEoAAF5KAgBtSAkEcGgAAAAAc0gJBB8WaLIq8QBCKgFQSgAAXkoCAG1ICQRwaAAA AABzSAkEBhZogS0oAAAGFmi8BicAAAYWaMJhiQAAFhZosirxADBKFgA+KgFCKgJwaAAA/wAA BhZosirxAAAPA2oAAAAAFmiyKvEAVQgBADUcEgAAHRIAAG8SAABwEgAAjBIAAI0SAACOEgAA jxIAAJASAAABEwAAERMAABsTAABWEwAAWRMAAIwTAACNEwAAjhMAAOQTAADlEwAABRQAAAYU AAAHFAAACBQAAAkUAAB6FAAAihQAAJQUAADPFAAA0hQAAAYVAAAHFQAAYRUAAGIVAACGFQAA hxUAAIgVAACJFQAAihUAAJcVAAChFQAAxhUAANAVAAAvFgAAPxYAAEkWAABZFgAA9/P35/fj 89/z2/PLu8uo9/P35/ff89/z2/PLu8ug46CUoOOQ35DjkOOQ25CAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAHxZol0SJAEIqAVBKAABeSgIAbUgJBHBoAAAAAHNICQQGFmiXRIkAABYW aMJhiQAwShYAPioBQioCcGgAAP8AAA8DagAAAAAWaMJhiQBVCAElFWgzOygAFmgzOygAQioB UEoAAF5KAgBtSAkEcGgAAAAAc0gJBB8WaLwGJwBCKgFQSgAAXkoCAG1ICQRwaAAAAABzSAkE HxZoMzsoAEIqAVBKAABeSgIAbUgJBHBoAAAAAHNICQQGFmiBLSgAAAYWaLwGJwAABhZowmGJ AAAWFmgzOygAMEoWAD4qAUIqAnBoAAD/AAAGFmgzOygAAA8DagAAAAAWaDM7KABVCAEALY0T AAAGFQAAhhcAADAaAABFGgAAwhsAAAYeAAD0HgAAXyAAAHAiAAAyJAAASCQAACsmAACYJgAA IigAAAspAAAMKQAAPSkAAKApAABNKgAATioAAGUqAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAA AAAAAPUAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAANoAAAAAAAAAAAAA AADaAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAANAAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAA 7gAAAAAAAAAAAAAAAMYAAAAAAAAAAAAAAAC/AAAAAAAAAAAAAAAAvwAAAAAAAAAAAAAAAL8A AAAAAAAAAAAAAADuAAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAA AAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABSkeABnZDcJ LAAABgAAFKR4AGdkmUAWAAoAAAomAAtGBwAUpHgAZ2SZQBYACgAACiYAC0YEABSkeABnZNRm UwAKAAAKJgALRgQAFKR4AGdkyk/0AAoAAAomAAtGBgAUpHgAZ2SXRIkAAAYAABSkeABnZLIq 8QAKAAAKJgALRgUAFKR4AGdkMzsoAAAVWRYAAGQWAAB9FgAAhRYAAI0WAACQFgAAwxYAAAUX AACFFwAAhhcAAIcXAADbFwAA3BcAAPoXAAD7FwAA/BcAAP0XAAD+FwAAmBgAAJkYAADMGAAA 3BgAAOYYAAAdGQAALRkAAGYZAABnGQAArxkAALIZAAAvGgAAMBoAADkaAABEGgAARRoAAEYa AACXGgAAmBoAALMaAAC0GgAAtRoAALYaAAC3GgAA3RoAAN4aAADfGgAA4BoAAAobAADv3+/f z9/vy9/Dv8Ozw8u/r7+vv8u/r8uvv9/P35yJ33nDv8Ozw8u/r7+vv6+/AAAAAAAAAAAfFmiy KvEAQioBUEoAAF5KAgBtSAkEcGgAAAAAc0gJBCUVaLIq8QAWaLIq8QBCKgFQSgAAXkoCAG1I CQRwaAAAAABzSAkEJRVosirxABZol0SJAEIqAVBKAABeSgIAbUgJBHBoAAAAAHNICQQGFmi8 BicAABYWaJdEiQAwShYAPioBQioCcGgAAP8AAAYWaJdEiQAADwNqAAAAABZol0SJAFUIAQYW aIEtKAAAHxZovAYnAEIqAVBKAABeSgIAbUgJBHBoAAAAAHNICQQfFmiXRIkAQioBUEoAAF5K AgBtSAkEcGgAAAAAc0gJBB8WaMJhiQBCKgFQSgAAXkoCAG1ICQRwaAAAAABzSAkEAC4KGwAA ExsAABYbAABMGwAAThsAAFAbAACLGwAAjhsAAMEbAADCGwAAwxsAABQcAAAVHAAAMBwAADEc AAAyHAAAMxwAADQcAACHHAAAlxwAAKAcAAAIHQAAEh0AACAdAAAhHQAAcx0AAHQdAACQHQAA kR0AAJMdAACUHQAAzx0AANIdAAAGHgAAHx4AACAeAAAhHgAAIh4AAPQeAAAMHwAA/Pj88Pzg 0ODAuPy4rLio/KT8qPz4qPic+JyQnPj84NDgiID8pPxtAAAAAAAAAAAAAAAAAAAAAAAAACUV aLIq8QAWaLIq8QBCKgFQSgAAXkoCAG1ICQRwaAAAAABzSAkEDhZogS0oAG1ICQRzSAkEAA4W aMpP9ABtSAkEc0gJBAAWFmi8BicAMEoWAD4qAUIqAnBoAAD/AAAPA2oAAAAAFmi8BicAVQgB BhZosi37AAAGFmiBLSgAABYWaMpP9AAwShYAPioBQioCcGgAAP8AAA8DagAAAAAWaMpP9ABV CAEfFmiXRIkAQioBUEoAAF5KAgBtSAkEcGgAAAAAc0gJBB8WaLIt+wBCKgFQSgAAXkoCAG1I CQRwaAAAAABzSAkEHxZoyk/0AEIqAVBKAABeSgIAbUgJBHBoAAAAAHNICQQPFWjKT/QAFmjK T/QASCoBBhZovAYnAAAGFmjKT/QAJwwfAAANHwAADh8AAA8fAAAvHwAAMB8AAEgfAABQHwAA 6B8AAPgfAAD5HwAAWCAAAF0gAABeIAAAXyAAAGAgAACyIAAAsyAAAM8gAADQIAAA0SAAANIg AADTIAAANCEAAEQhAADTIQAA1iEAAG8iAABwIgAAiyIAAIwiAAC4IgAAuSIAAAAjAAAPIwAA KSMAADEjAAC6IwAAxCMAAM0jAAAwJAAAMSQAAD0kAABHJAAASCQAAO/f29fb19vX09vT29PA uLS4qLiktNu0pLTbtMCUhJSElHSEdJTvlLSUwJTAAAAAAAAAAAAfFmghdpAAQioBUEoAAF5K AgBtSAkEcGgAAAAAc0gJBB8WaLIt+wBCKgFQSgAAXkoCAG1ICQRwaAAAAABzSAkEHxZo1GZT AEIqAVBKAABeSgIAbUgJBHBoAAAAAHNICQQGFmiBLSgAABYWaNRmUwAwShYAPioBQioCcGgA AP8AAAYWaNRmUwAADwNqAAAAABZo1GZTAFUIASUVaLIq8QAWaLIq8QBCKgFQSgAAXkoCAG1I CQRwaAAAAABzSAkEBhZoIXaQAAAGFmjKT/QAAAYWaLIt+wAAHxZoyk/0AEIqAVBKAABeSgIA bUgJBHBoAAAAAHNICQQfFmiBLSgAQioBUEoAAF5KAgBtSAkEcGgAAAAAc0gJBAAsSCQAAEkk AACjJAAApCQAAMgkAADJJAAAyiQAAMskAACpJQAAuSUAAComAAArJgAAmCYAAKomAACuJgAA sSYAALImAAAjJwAAKicAAD8nAABJJwAAWScAAG8nAAClJwAApicAAKsnAAC5JwAA5ScAAOYn AADvJwAA/icAABQoAAAVKAAAICgAACIoAABzKAAAfSgAAIsoAACPKAAAxigAAM8oAAADKQAA CSkAAAopAAALKQAADCkAAA0pAAAPKQAA9/P35/fz4/Pf89vX8+Pz4/Pj89/z4/Pj8+Pz4/Pj zMTMvLSstMS0xLTEtNecjHwAAAAAAAAAAAAfFmh9XqAAQioBUEoAAF5KAgBtSAkEcGgAAAAA c0gJBB8WaI0+ZwBCKgFQSgAAXkoCAG1ICQRwaAAAAABzSAkEHxZomUAWAEIqAVBKAABeSgIA bUgJBHBoAAAAAHNICQQOFmiBLSgAXkoCAF9IDQQADhZoIXaQAF5KAgBfSA0EAA4WaJlAFgBe SgIAX0gNBAAOFmiyLfsAXkoCAF9IDQQAFBVoF1JUABZomUAWAF5KAgBfSA0EAAYWaCF2kAAA BhZo1GZTAAAGFmiBLSgAAAYWaLIt+wAAFhZomUAWADBKFgA+KgFCKgJwaAAA/wAABhZomUAW AAAPA2oAAAAAFmiZQBYAVQgBAC8PKQAAFSkAABopAAAoKQAALykAADwpAAA9KQAAPikAAEop AAByKQAAdCkAAHUpAACdKQAAnikAALQpAAC8KQAAzikAAAAqAABLKgAATSoAAE4qAABXKgAA WSoAAF4qAABlKgAAoyoAAKQqAADv38/vz7+qz5fPqoaqds92z+/Pdt9m31ZDViUVaIstkgAW aIstkgBCKgFQSgAAXkoCAG1ICQRwaAAAAABzSAkEHxZoiy2SAEIqAVBKAABeSgIAbUgJBHBo AAAAAHNICQQfFmi7P/MAQioBUEoAAF5KAgBtSAkEcGgAAAAAc0gJBB8WaJhGTABCKgFQSgAA XkoCAG1ICQRwaAAAAABzSAkEIBVonhudABZofV6gADBKDwBQSgAAXkoCAG1ICQRzSAkEACUV aH1eoAAWaH1eoABCKgFQSgAAXkoCAG1ICQRwaAAAAABzSAkEKANqAAAAABZofV6gAEIqAVBK AABVCAFeSgIAbUgJBHBoAAAAAHNICQQAHxZoZ1J2AEIqAVBKAABeSgIAbUgJBHBoAAAAAHNI CQQfFmh9XqAAQioBUEoAAF5KAgBtSAkEcGgAAAAAc0gJBB8WaI0+ZwBCKgFQSgAAXkoCAG1I CQRwaAAAAABzSAkEHxZosi37AEIqAVBKAABeSgIAbUgJBHBoAAAAAHNICQQAGmUqAACZKgAA pyoAALcqAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABgAAFKR4AGdkNwksAAADpCoAAKYqAACnKgAAtioAALcqAADs3OzTAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAQFWgXUlQAFmhKL94AXkoCAAAfFmiLLZIAQioBUEoAAF5KAgBtSAkEcGgAAAAA c0gJBCUVaIstkgAWaIstkgBCKgFQSgAAXkoCAG1ICQRwaAAAAABzSAkEAAQuADpwSi/eAB+w 0C8gsOA9IbAIByKwCAcjkKAFJJCgBSWwAAAXsMQCGLDEAgyQxAIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABqBBcAEgABAAsBDwAHAAMAAwADAAAABAAIAAAAmAAAAJ4AAACeAAAAngAAAJ4A AACeAAAAngAAAJ4AAACeAAAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA dgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAAPgIAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAAKgAAAA2BgAANgYAABYAAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAALgAAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AABoAQAASAEAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA sAMAADYGAAAyBgAAGAAAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAE AABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAMgYAACgCAADYAQAA 6AEAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAE AAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAA AAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPAD AAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA 8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOAD AADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAADgBAABYAQAA +AEAAAgCAAAYAgAAVgIAAH4CAAAgAAAAT0oDAFBKAwBRSgMAX0gBBG1ICQRuSAkEc0gJBHRI CQQAAAAARAAAYPH/AgBEAAwQAACNZ+0AAAAGAE4AbwByAG0AYQBsAAAABgAAABSkyAAYAENK GABfSAEEYUoYAG1ICQhzSAkIdEgJBF4AAQABAAIAXgAMFBIAF1JUAJAACQBIAGUAYQBkAGkA bgBnACAAMQAAABAAAQAGJAETpPAAFKQ8AEAmACIANQiBQ0ogAEtIIABPSgMAUEoAAFFKAwBc CIFeSgAAYUogAAAAAAAAAAAAAAAAAAAAAABEAEFg8v+hAEQADA0AAAAAAAAQABYARABlAGYA YQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAUgBpAPP/swBSAAwd AAAAAAAAMAYMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMAADTWBgABCgNsADTW BgABBQMAAGH2AwAAAgALAAAAKABrIPT/wQAoAAANAAAAAAAAMAYHAE4AbwAgAEwAaQBzAHQA AAACAAwAAAAAADYAVUCiAPEANgAMDAAAHh5VADAGCQBIAHkAcABlAHIAbABpAG4AawAAAAwA PioBQioHcGgAAP8AWgA+AAEAAgBaAAwUEQA3CSwAoAAFAFQAaQB0AGwAZQAAABMAEAADJAET pPAAFKQ8AEAmAGEkAQAiADUIgUNKIABLSBwAT0oDAFBKAABRSgMAXAiBXkoAAGFKIABWAP5P ogARAVYADAAQADcJLACgAAoAVABpAHQAbABlACAAQwBoAGEAcgAAACoANQgBQ0ogAEtIHABP SgMAUEoAAFFKAwBcCAFeSgAAYUogAG1ICQhzSAkIXgD+D6IAIQFeAAwAAQAXUlQAkAAOAEgA ZQBhAGQAaQBuAGcAIAAxACAAQwBoAGEAcgAAACoANQgBQ0ogAEtIIABPSgMAUEoAAFFKAwBc CAFeSgAAYUogAG1ICQhzSAkImABlAAEAMgGYAAwJFAC7P/MAMAYRAEgAVABNAEwAIABQAHIA ZQBmAG8AcgBtAGEAdAB0AGUAZAAAADsAEwANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfw KoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABSkAAAAIABDShQAT0oEAFBKAABRSgQAXkoEAGFK FABtSAkEc0gJBFQA/g+iAEEBVAAMARMAuz/zADAGFgBIAFQATQBMACAAUAByAGUAZgBvAHIA bQBhAHQAdABlAGQAIABDAGgAYQByAAAAEABPSgQAUEoAAFFKBABeSgQAHAD+D6IAUQEcAAwA AABnUnYAAAACAGgAMQAAAAAAJAD+T6IAYQEkAAwAAACyKvEAAAAGAGEAYwB0AGkAdgBlAAAA AABQSwMEFAAGAAgAAAAhAIKKvBP6AAAAHAIAABMAAABbQ29udGVudF9UeXBlc10ueG1srJHL asMwEEX3hf6D0LbYcroopdjOokl3fSzSDxjksS1qj4Q0Ccnfd+y4ULoILXQjEGLOmXtVro/j oA4Yk/NU6VVeaIVkfeOoq/T77im71yoxUAODJ6z0CZNe19dX5e4UMCmZplTpnjk8GJNsjyOk 3AckeWl9HIHlGjsTwH5Ah+a2KO6M9cRInPHE0HX5KgtE16B6g8gvMIrHsKDw+/kMJICYC1ir xzNhWqLSEMLgLLBEMAdqfugz37bOYuPtfhRpPoMX2M0EM79cYPU/6i/nBlvYD6y2R+niXH/E If0t21JrLpNz/tS7kC4YLpe3tGHmv60/AQAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2 AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb 69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8 UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6P qMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQA BgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzM TQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0u iLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtH V+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQCWta3ilgYAAFAbAAAWAAAAdGhl bWUvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbY UKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4f qavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJg fSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/Q UJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7Rx dQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLN Rn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5m t7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2K tRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3 r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1 ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSU OMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZ eThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6 gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4o HFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8 gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9 MxHal1CqnQoc0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oyYftE+V2EO1l0u1wE9O2v uVt4kuwRCPP5jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMeU8YGasrIDWmaZAn7 RNCHQb3OnA5JcWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc7MxwJW2NhyZd 2WNhUx8YbD2QWO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb3YhmSp3D rVAZfDivGgwW1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6clMeK uQmA2KnwkT7knWK1EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56 yMdp2xvDmRYe4xS8LnXPh1kIF0O+EjbsT01mk+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0 zFQWAizRnKz8y00w60UpYCP9NaRYWYNg+NekADu6riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN 2ETsY3C/DlXQJ6ASriZMRdAvcI+mrW2m3OKcJV359srg7DhmaYSzcqtTNM9kCzd5XMhg3kri gW6Vshvlzq+KSfkLUqUcxv8zVfR+AjcFK4H2gA/XuAIjna9tjwsVcahCaUT9voDGwdQOiBa4 i4VpCCq4TDb/BTnU/23OWRomreHAp/ZpiASF/UhFgpA9KEsm+k4hVs/2LkuSZYRMRJXElakV e0QOCRvqGriq93YPRRDqpppkZcDgTsaf+55l0CjUTU4535waUuy9Ngf+6c7HJjMo5dZh09Dk 9i9ErNhV7XqzPN97y4roiVmb1cizApiVtoJWlvavKcI5t1pbseY0Xm7mwoEX5zWGwaIhSuG+ B+k/sP9R4TP7ZUJvqEO+D7UVwYcGTQzCBqL6km08kC6QdnAEjZMdtMGkSVnTZq2Ttlq+WV9w p1vwPWFsLdlZ/H1OYxfNmcvOycWLNHZmYcfWdmyhqcGzJ1MUhsb5QcY4xnzSKn914qN74Ogt uN+fMCVNMME3JYGh9RyYPIDktxzN0o2/AAAA//8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAb AQAAJwAAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrCMBSE 94J3CG9v07oQkSbdiNCt1AOE5DUNNj8kUeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVx msFtuOyOQFIWTonZO2SwYIKObzftFWeRSyhNJiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOm Qci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/TgaiWcvHxZd/lFBc9mFBSiixszgI5uqTATK W7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAIKKvBP6AAAAHAIAABMAAAAAAAAAAAAAAAAA AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEApdan58AAAAA2AQAACwAA AAAAAAAAAAAAAAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAa3mWFoMAAACKAAAA HAAAAAAAAAAAAAAAAAAUAgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbFBLAQItABQA BgAIAAAAIQCWta3ilgYAAFAbAAAWAAAAAAAAAAAAAAAAANECAAB0aGVtZS90aGVtZS90aGVt ZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAAAAAAmwkAAHRo ZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BLBQYAAAAABQAFAF0BAACW CgAAAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0i eWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1h dHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJs dDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2NlbnQyIiBhY2Nl bnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1IiBhY2Nl bnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPgAAAAC3 IgAACAAASAAAAAD/////AAgAAJEJAABhCwAAOQ4AABwSAABZFgAAChsAAAwfAABIJAAADykA AKQqAAC3KgAAFgAAABgAAAAZAAAAGgAAABsAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACMAAAAA CAAAjRMAAGUqAAC3KgAAFwAAABwAAAAiAAAA1gQAACwFAABMBQAAOQYAAJMGAAC3BgAAmgcA AOoHAAAECAAAHAoAAG8KAACMCgAAjQsAAOQLAAAFDAAABg0AAGENAACGDQAAhg8AANsPAAD6 DwAARRIAAJcSAACzEgAAwhMAABQUAAAwFAAAIBUAAHMVAACQFQAAXxgAALIYAADPGAAASBwA AKMcAADIHAAAPSEAAHQhAACdIQAAtyIAABNYFP8VjBNYFP8VjBNYFP8VjBNYFP8VjBNYFP8V jBNYFP8VjBNYFP8VjBNYFP8VjBNYFP8VjBNYFP8VjBNYFP8VjBNYFP8VjBNYFP8VgA8AAPBU AAAAAAAG8CAAAAACDAAAAwAAAAEAAAABAAAAAQAAAAIAAAAAAAAAAAAAACMAC/AMAAAAhkEA AAAAxUEAAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAA AQQAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAE AAAFAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAA CAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAAAAAAAdgAAAHoAAADIAAAA0AAAADMFAAA3BQAA OAUAADwFAAA9BQAAPwUAAJoGAACeBgAAnwYAAKMGAACkBgAApgYAAKcGAACqBgAA8QcAAPUH AAD2BwAA+gcAAPsHAAD9BwAAdgoAAHoKAAB7CgAAfwoAAIAKAACCCgAA6wsAAO8LAADwCwAA 9AsAAPULAAD3CwAA+AsAAPsLAABoDQAAcQ0AAHINAAB2DQAAdw0AAHkNAADiDwAA5g8AAOcP AADrDwAA7A8AAO4PAAD3DwAA+g8AAJ4SAACiEgAAoxIAAKcSAACoEgAAqhIAAKsSAACvEgAA GxQAAB8UAAAgFAAAJBQAACUUAAAnFAAAKBQAACwUAAAtFAAAMBQAAHoVAACAFQAAgRUAAIUV AACGFQAAiBUAAI0VAACQFQAABhYAAAoWAAALFgAADRYAAPQWAAD4FgAA+RYAAPsWAAD8FgAA /xYAALkYAAC/GAAAwBgAAMQYAADFGAAAxxgAAMwYAADPGAAAcBoAAHQaAAB1GgAAdxoAAKoc AACyHAAAsxwAALccAAC4HAAAuhwAALscAADCHAAAeR8AAHsfAADvHwAA+h8AALkiAAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAAAAAAC0FAABMBQAAlAYAALcGAADrBwAABAgAAHAKAACMCgAA5QsAAAUMAABiDQAA hg0AANwPAAD6DwAAtxAAAMAQAACYEgAAsxIAABUUAAAwFAAABhYAAB8WAAD0FgAADBcAABQY AAAiGAAAsxgAAM8YAABwGgAAihoAAKQcAADIHAAAuSIAAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAAAAABVAQAA gAEAAHkCAACMAgAALwMAAD4DAAA/AwAAYgMAAAgKAAAbCgAAMBIAAEQSAAC2EgAA3xIAADIc AABIHAAATiIAAGUiAAC5IgAABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA BwAHAJt5nQ3if2RT/w//D/8P/w//D/8P/w//D/8PEADALiYmUH1IfP8P/w//D/8P/w//D/8P /w//DxAAoE9nL66qfuj/D/8P/w//D/8P/w//D/8P/w8QALJWXzTUujRf/w//D/8P/w//D/8P /w//D/8PEADwUDc4AKiYqf8P/w//D/8P/w//D/8P/w//DxAARCApS8JiZoD/D/8P/w//D/8P /w//D/8P/w8QANxSN2RoayII/w//D/8P/w//D/8P/w//D/8PEAABAAAAFxAAAAAAAAAAAAAA aAEAAAAAAAAVEAAAD4TQAhGEmP5ehNACYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/AB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4SgBRGEmP5ehKAFYISY/k9KBABRSgQAXkoE AG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EcAgRhJj+ XoRwCGCEmP5PSgUAUUoFAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAAFRAAAA+EQAsRhJj+XoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAAGRAAAA+EEA4RhJj+XoQQDmCEmP5PSgQAUUoEAF5KBABvKACH aAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhOAQEYSY/l6E4BBg hJj+T0oFAFFKBQBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQ AAAPhLATEYSY/l6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAA AAAAAABoAQAAAAAAABkQAAAPhIAWEYSY/l6EgBZghJj+T0oEAFFKBABeSgQAbygAh2gAAAAA iEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4RQGRGEmP5ehFAZYISY/k9K BQBRSgUAbygAh2gAAAAAiEgAAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TQ AhGEmP5ehNACYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAAZEAAAD4SgBRGEmP5ehKAFYISY/k9KBABRSgQAXkoEAG8oAIdoAAAAAIhIAAAB AG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EcAgRhJj+XoRwCGCEmP5PSgUAUUoF AG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EQAsRhJj+ XoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAAGRAAAA+EEA4RhJj+XoQQDmCEmP5PSgQAUUoEAF5KBABvKACHaAAAAACISAAAAQBvAAEA AAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhOAQEYSY/l6E4BBghJj+T0oFAFFKBQBvKACH aAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhLATEYSY/l6EsBNg hJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkQ AAAPhIAWEYSY/l6EgBZghJj+T0oEAFFKBABeSgQAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAAVEAAAD4RQGRGEmP5ehFAZYISY/k9KBQBRSgUAbygAh2gAAAAA iEgAAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TQAhGEmP5ehNACYISY/k9K AQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4Sg BRGEmP5ehKAFYISY/k9KBABRSgQAXkoEAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAAFRAAAA+EcAgRhJj+XoRwCGCEmP5PSgUAUUoFAG8oAIdoAAAAAIhIAAAB AKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EQAsRhJj+XoRAC2CEmP5PSgEAUUoB AG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRAAAA+EEA4RhJj+ XoQQDmCEmP5PSgQAUUoEAF5KBABvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABo AQAAAAAAABUQAAAPhOAQEYSY/l6E4BBghJj+T0oFAFFKBQBvKACHaAAAAACISAAAAQCn8AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhLATEYSY/l6EsBNghJj+T0oBAFFKAQBvKACH aAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkQAAAPhIAWEYSY/l6EgBZg hJj+T0oEAFFKBABeSgQAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAAVEAAAD4RQGRGEmP5ehFAZYISY/k9KBQBRSgUAbygAh2gAAAAAiEgAAAEAp/ABAAAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAEAAAD4TQAhGEmP5ehNACYISY/gIAAAAuAAEAAAAEgAEAAAAA AAAAAAAAAAAAAAAAAAAQAAAPhKAFEYSY/l6EoAVghJj+AgABAC4AAQAAAAKCAQAAAAAAAAAA AAAAAAAAAAAAABAAAA+EcAgRhEz/XoRwCGCETP8CAAIALgABAAAAAIABAAAAAAAAAAAAAAAA AAAAAAAAEAAAD4RACxGEmP5ehEALYISY/gIAAwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAA AAAQAAAPhBAOEYSY/l6EEA5ghJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABAA AA+E4BARhEz/XoTgEGCETP8CAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4Sw ExGEmP5ehLATYISY/gIABgAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhIAWEYSY /l6EgBZghJj+AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EUBkRhEz/XoRQ GWCETP8CAAgALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TQAhGEmP5ehNACYISY /k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAA D4SgBRGEmP5ehKAFYISY/k9KBABRSgQAXkoEAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAAFRAAAA+EcAgRhJj+XoRwCGCEmP5PSgUAUUoFAG8oAIdoAAAAAIhI AAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EQAsRhJj+XoRAC2CEmP5PSgEA UUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRAAAA+EEA4R hJj+XoQQDmCEmP5PSgQAUUoEAF5KBABvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAA AABoAQAAAAAAABUQAAAPhOAQEYSY/l6E4BBghJj+T0oFAFFKBQBvKACHaAAAAACISAAAAQCn 8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhLATEYSY/l6EsBNghJj+T0oBAFFKAQBv KACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkQAAAPhIAWEYSY/l6E gBZghJj+T0oEAFFKBABeSgQAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAAVEAAAD4RQGRGEmP5ehFAZYISY/k9KBQBRSgUAbygAh2gAAAAAiEgAAAEAp/ABAAAA FxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TQAhGEmP5ehNACYISY/k9KAQBRSgEAbygAh2gA AAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4SgBRGEmP5ehKAFYISY /k9KBABRSgQAXkoEAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA FRAAAA+EcAgRhJj+XoRwCGCEmP5PSgUAUUoFAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAAFRAAAA+EQAsRhJj+XoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhI AAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRAAAA+EEA4RhJj+XoQQDmCEmP5PSgQA UUoEAF5KBABvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAP hOAQEYSY/l6E4BBghJj+T0oFAFFKBQBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAA AABoAQAAAAAAABUQAAAPhLATEYSY/l6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC3 8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkQAAAPhIAWEYSY/l6EgBZghJj+T0oEAFFKBABe SgQAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4RQGRGE mP5ehFAZYISY/k9KBQBRSgUAbygAh2gAAAAAiEgAAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEA AAAAAAAVEAAAD4TQAhGEmP5ehNACYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAA F5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4SgBRGEmP5ehKAFYISY/k9KBABRSgQAXkoEAG8o AIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EcAgRhJj+XoRw CGCEmP5PSgUAUUoFAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA FRAAAA+EQAsRhJj+XoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAAGRAAAA+EEA4RhJj+XoQQDmCEmP5PSgQAUUoEAF5KBABvKACHaAAA AACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhOAQEYSY/l6E4BBghJj+ T0oFAFFKBQBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAP hLATEYSY/l6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAA AABoAQAAAAAAABkQAAAPhIAWEYSY/l6EgBZghJj+T0oEAFFKBABeSgQAbygAh2gAAAAAiEgA AAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4RQGRGEmP5ehFAZYISY/k9KBQBR SgUAbygAh2gAAAAAiEgAAAEAp/AHAAAAslZfNAAAAAAAAAAAAAAAAJt5nQ0AAAAAAAAAAAAA AADwUDc4AAAAAAAAAAAAAAAARCApSwAAAAAAAAAAAAAAANxSN2QAAAAAAAAAAAAAAACgT2cv AAAAAAAAAAAAAAAAwC4mJgAAAAAAAAAAAAAAAP////////////////////////////////// /////wcAAAAAAAAAAAAAAAAAAAAAAP//BwAAABIAAQAJBAMACQQFAAkEAQAJBAMACQQFAAkE AQAJBAMACQQFAAkEEgABAAkEAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQSAAEA CQQDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIADwAJBBkACQQbAAkEDwAJBBkA CQQbAAkEDwAJBBkACQQbAAkEEgABAAkEAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUA CQQSAAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIAAQAJBAMACQQFAAkE AQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAgCyTcsyAAAAAAAAAAAAAQIAAgCiYLtfAAAAAAAA AAAAAQIAAgAuAAAABAAAAAgAAADlAAAAAAAAACoAAADmKQEAu3IEAJlAFgDtcRoAwF4bACpp GwCaUSMAvAYnAIEtKAAzOygANwksAF0aMgBvMjMAHGQ2AA05PAChb0oAmEZMANRmUwAXUlQA Hh5VAI0+ZwC5YW8AnXJyAGdSdgCKPXkAl0SJAMJhiQBiao8AIXaQAIstkgAsZJcATACcAKtx nAB9XqAAKU3CAFd6zgCff9QA5x3VAEov3gBIQ+4AAhnvALIq8QC7P/MAyk/0ACI99wCyLfsA AAAAALciAAC5IgAAAAAAAAEAAAD/QAGAAQADAAAAAwAAAABojwMcABwAAwAAAAAAAAADAAAA AAAAAAIQAAAAAAAAALciAABAAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAA AAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAHAAAARx6QAQAAAgIG AwUEBQIDBO8qAOBBeADACQAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAANR6QAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBt AGIAbwBsAAAAMy6QAQAAAgsGBAICAgICBP8qAOBDeADACQAAAAAAAAD/AQAAAAAAAEEAcgBp AGEAbAAAADcekAEAAAIEBQMFBAYDAgTvAgCgSwAAQAAAAAAAAAAAnwAAAAAAAABDAGEAbQBi AHIAaQBhAAAAPz2QAQAAAgcDCQICBQIEBP8qAOBDeADACQAAAAAAAAD/AQAAAAAAAEMAbwB1 AHIAaQBlAHIAIABOAGUAdwAAADsOkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAA gAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAAEEekAEAAAIEBQMFBAYDAgTvAgCg6yAAQgAAAAAA AAAAnwAAAAAAAABDAGEAbQBiAHIAaQBhACAATQBhAHQAaAAAACIABABxCIgYAPDQAgAAaAEA AAAAaUvVxrJZ1SYAAAAAAwAhBAAALgUAAIkdAAAEABEAAAAEAAMQPwAAAC4FAACJHQAABAAR AAAAPwAAAAAAAAChBADwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAClBsAHtAC0AIAAMjQAABAAGQBkAAAAGQAAAKYiAACmIgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAA AAU6I1EA8BAACAD8/QEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAISAAAAAAAAPD/DwAIAT8A AOQEAAD///9/////f////3////9/////f////3////9/SEPuAAAEAAAyAAAAAAAAAAAAAAAA AAEAAAAAAAAAIQQAAAAAAAAAAAAAAAAAAAAAAAAQHAAABgAAAAAAAAAAAHgAAAB4AAAAAAAA AAAAAACgBQAA//8SAAAAAAAAAAMAVABvADoAAAAAAAAAFgBCAGUAbgBqAGEAbQBpAG4AIABO AGkAdgBlAG4ALQBKAGUAbgBrAGkAbgBzAA0ATABvAGEAIABBAG4AZABlAHIAcwBzAG8AbgAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAAAGAAAABwAAAAAADAABAAwAAgAMAAMADAAEAAwABQAM AAYADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD+/wAABgACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAA AABEAQAADgAAAAEAAAB4AAAAAgAAAIAAAAAEAAAAjAAAAAcAAACsAAAACAAAALwAAAAJAAAA 1AAAABIAAADgAAAACgAAAAABAAAMAAAADAEAAA0AAAAYAQAADgAAACQBAAAPAAAALAEAABAA AAA0AQAAEwAAADwBAAACAAAA5AQAAB4AAAAEAAAAVG86AB4AAAAYAAAAQmVuamFtaW4gTml2 ZW4tSmVua2lucwAAHgAAAAgAAABOb3JtYWwAAB4AAAAQAAAATG9hIEFuZGVyc3NvbgAAAB4A AAAEAAAAMwAAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAAAGRKmTAAAA QAAAAADuPQab0MkBQAAAAAAMkPDz0ckBAwAAAAQAAAADAAAALgUAAAMAAACJHQAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA /v8AAAYAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1Zwu GxCTlwgAKyz5rjABAADsAAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAfAAAAAYAAACEAAAA EQAAAIwAAAAXAAAAlAAAAAsAAACcAAAAEAAAAKQAAAATAAAArAAAABYAAAC0AAAADQAAALwA AAAMAAAAzAAAAAIAAADkBAAAHgAAAAQAAAAAAAAAAwAAAD8AAAADAAAAEQAAAAMAAACmIgAA AwAAAAAADAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAABAAAAFRv OgAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAKAAADAAAAAAAAACAAAAABAAAA OAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAAuAkAAE4A AAADAAAAWQBWAAMAAAAkAAAAAwAAAAAAAAADAAAABQAAAB8AAAApAAAAaAB0AHQAcAA6AC8A LwB3AGkAawBpAC4AdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBpAHMAYwAvAG0A cABsAHMALQB0AHAALwAAAAAAHwAAAAEAAAAAAP0JAwAAAA0AXAADAAAAIQAAAAMAAAAAAAAA AwAAAAUAAAAfAAAATQAAAGgAdAB0AHAAcwA6AC8ALwBkAGEAdABhAHQAcgBhAGMAawBlAHIA LgBpAGUAdABmAC4AbwByAGcALwBpAGQAdAByAGEAYwBrAGUAcgAvAGQAcgBhAGYAdAAtAGgA ZQBsAHYAbwBvAHIAdAAtAG0AcABsAHMALQB0AHAALQByAG8AcwBlAHQAdABhAC0AcwB0AG8A bgBlAC8AAAAAAB8AAAABAAAAAAD9CQMAAAAEAFsAAwAAAB4AAAADAAAAAAAAAAMAAAAFAAAA HwAAAEUAAABoAHQAdABwAHMAOgAvAC8AZABhAHQAYQB0AHIAYQBjAGsAZQByAC4AaQBlAHQA ZgAuAG8AcgBnAC8AaQBkAHQAcgBhAGMAawBlAHIALwBkAHIAYQBmAHQALQBiAHIAeQBhAG4A dAAtAG0AcABsAHMALQB0AHAALQBhAGMAaAAtAHQAbAB2AC8AAAAAAB8AAAABAAAAAAD9CQMA AAAEAFsAAwAAABsAAAADAAAAAAAAAAMAAAAFAAAAHwAAAEUAAABoAHQAdABwAHMAOgAvAC8A ZABhAHQAYQB0AHIAYQBjAGsAZQByAC4AaQBlAHQAZgAuAG8AcgBnAC8AaQBkAHQAcgBhAGMA awBlAHIALwBkAHIAYQBmAHQALQBiAHIAeQBhAG4AdAAtAG0AcABsAHMALQB0AHAALQBhAGMA aAAtAHQAbAB2AC8AAAAAAB8AAAABAAAAAAD9CQMAAAAhAD0AAwAAABgAAAADAAAAAAAAAAMA AAAFAAAAHwAAAEQAAABoAHQAdABwAHMAOgAvAC8AZABhAHQAYQB0AHIAYQBjAGsAZQByAC4A aQBlAHQAZgAuAG8AcgBnAC8AaQBkAHQAcgBhAGMAawBlAHIALwBkAHIAYQBmAHQALQBpAGUA dABmAC0AbQBwAGwAcwAtAHQAcAAtAGcAYQBjAGgALQBkAGMAbgAvAAAAHwAAAAEAAAAAAP0J AwAAACMAPAADAAAAFQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAARAAAAGgAdAB0AHAAcwA6AC8A LwBkAGEAdABhAHQAcgBhAGMAawBlAHIALgBpAGUAdABmAC4AbwByAGcALwBpAGQAdAByAGEA YwBrAGUAcgAvAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBtAHAAbABzAC0AdABwAC0AZwBhAGMA aAAtAGcAYQBsAC8AAAAfAAAAAQAAAAAA/QkDAAAAawA+AAMAAAASAAAAAwAAAAAAAAADAAAA BQAAAB8AAABHAAAAaAB0AHQAcABzADoALwAvAGQAYQB0AGEAdAByAGEAYwBrAGUAcgAuAGkA ZQB0AGYALgBvAHIAZwAvAGkAZAB0AHIAYQBjAGsAZQByAC8AZAByAGEAZgB0AC0AaQBlAHQA ZgAtAG0AcABsAHMALQB0AHAALQBzAHUAcgB2AGkAdgBlAC0AZgB3AGsALwAAAAAAHwAAAAEA AAAAAP0JAwAAAF8AGgADAAAADwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAATQAAAGgAdAB0AHAA cwA6AC8ALwBkAGEAdABhAHQAcgBhAGMAawBlAHIALgBpAGUAdABmAC4AbwByAGcALwBpAGQA dAByAGEAYwBrAGUAcgAvAGQAcgBhAGYAdAAtAG0AYQBuAHMAZgBpAGUAbABkAC0AbQBwAGwA cwAtAHQAcAAtAG4AbQAtAGYAcgBhAG0AZQB3AG8AcgBrAC8AAAAAAB8AAAABAAAAAAD9CQMA AAAPAEcAAwAAAAwAAAADAAAAAAAAAAMAAAAFAAAAHwAAAEkAAABoAHQAdABwAHMAOgAvAC8A ZABhAHQAYQB0AHIAYQBjAGsAZQByAC4AaQBlAHQAZgAuAG8AcgBnAC8AaQBkAHQAcgBhAGMA awBlAHIALwBkAHIAYQBmAHQALQBpAGUAdABmAC0AbQBwAGwAcwAtAHQAcAAtAG8AYQBtAC0A ZgByAGEAbQBlAHcAbwByAGsALwAAAAAAHwAAAAEAAAAAAP0JAwAAAA0ACwADAAAACQAAAAMA AAAAAAAAAwAAAAUAAAAfAAAARQAAAGgAdAB0AHAAcwA6AC8ALwBkAGEAdABhAHQAcgBhAGMA awBlAHIALgBpAGUAdABmAC4AbwByAGcALwBpAGQAdAByAGEAYwBrAGUAcgAvAGQAcgBhAGYA dAAtAGkAZQB0AGYALQBtAHAAbABzAC0AdABwAC0AZgByAGEAbQBlAHcAbwByAGsALwAAAAAA HwAAAAEAAAAAAP0JAwAAAE0AUAADAAAABgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAQgAAAGgA dAB0AHAAcwA6AC8ALwBkAGEAdABhAHQAcgBhAGMAawBlAHIALgBpAGUAdABmAC4AbwByAGcA LwBpAGQAdAByAGEAYwBrAGUAcgAvAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBtAHAAbABzAC0A dABwAC0AbgBtAC0AcgBlAHEALwAAAB8AAAABAAAAAAD9CQMAAAB3AGAAAwAAAAMAAAADAAAA AAAAAAMAAAAFAAAAHwAAAEwAAABoAHQAdABwAHMAOgAvAC8AZABhAHQAYQB0AHIAYQBjAGsA ZQByAC4AaQBlAHQAZgAuAG8AcgBnAC8AaQBkAHQAcgBhAGMAawBlAHIALwBkAHIAYQBmAHQA LQBpAGUAdABmAC0AbQBwAGwAcwAtAHQAcAAtAG8AYQBtAC0AcgBlAHEAdQBpAHIAZQBtAGUA bgB0AHMALwAAAB8AAAABAAAAAAD9CQMAAAB1ACwAAwAAAAAAAAADAAAAAAAAAAMAAAAFAAAA HwAAAEgAAABoAHQAdABwAHMAOgAvAC8AZABhAHQAYQB0AHIAYQBjAGsAZQByAC4AaQBlAHQA ZgAuAG8AcgBnAC8AaQBkAHQAcgBhAGMAawBlAHIALwBkAHIAYQBmAHQALQBpAGUAdABmAC0A bQBwAGwAcwAtAHQAcAAtAHIAZQBxAHUAaQByAGUAbQBlAG4AdABzAC8AAAAfAAAAAQAAAAAA /QkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAA AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAA AAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAAP7///8mAAAAJwAAACgAAAApAAAAKgAAACsA AAAsAAAA/v///y4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAA OQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYA AABHAAAA/v///0kAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAAD+////UQAAAFIAAABTAAAA VAAAAFUAAABWAAAAVwAAAP7////9////WgAAAP7////+/////v////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAA AAAAAABGAAAAAAAAAAAAAAAAIMCKA/TRyQFcAAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUAAAAAEAAA AAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAALQAAAJE1AAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMEgAAAAAAAAFAFMAdQBtAG0A YQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgA AAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAUAAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AQD+/wMKAAD///// BgkCAAAAAADAAAAAAAAARicAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgOTctMjAwMyBEb2N1 bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= --------------080308020506010608000504--