From pwe3-bounces@ietf.org Tue Mar 4 02:18:56 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC90028C5F2; Tue, 4 Mar 2008 02:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.794 X-Spam-Level: X-Spam-Status: No, score=0.794 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, 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 Tc8nxkP2UK8f; Tue, 4 Mar 2008 02:18:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07E528C5AC; Tue, 4 Mar 2008 02:18:52 -0800 (PST) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4912F28C4FD for ; Tue, 4 Mar 2008 02:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 jGLygnPZvZ8P for ; Tue, 4 Mar 2008 02:18:47 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id A6B2628C5D1 for ; Tue, 4 Mar 2008 02:18:10 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m24AEi1M010720 for ; Tue, 4 Mar 2008 11:14:45 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 4 Mar 2008 11:17:59 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Mar 2008 11:17:58 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A018B1D51@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides for Philadelphia Thread-index: Ach94QTe5a8kZca4TAue3yyh2+BluQ== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 04 Mar 2008 10:17:59.0255 (UTC) FILETIME=[05724E70:01C87DE1] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [PWE3] Slides for Philadelphia X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1696320039==" Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1696320039== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87DE1.054A67A0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87DE1.054A67A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The latest PWE3 agenda for Philadelphia is posted at: http://tools.ietf.org/wg/pwe3/agenda If you have a slot, please can you send me your slides by 5pm EDT on Sunday 9th March, at the latest. Please note that if you have not provided slides by then, you will be moved to the end of the agenda. Regards, Matthew ------_=_NextPart_001_01C87DE1.054A67A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Slides for Philadelphia

Folks,

The latest PWE3 agenda for Philadelphia = is posted at:
http://tools.ietf.org/wg/pwe3/agenda

If you have a slot, please can you send = me your slides by 5pm EDT on Sunday 9th March, at the latest.

Please note that if you have not = provided slides by then, you will be moved to the end of the = agenda.

Regards,

Matthew

------_=_NextPart_001_01C87DE1.054A67A0-- --===============1696320039== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --===============1696320039==-- From pwe3-bounces@ietf.org Wed Mar 5 13:54:00 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B635D28C79D; Wed, 5 Mar 2008 13:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.364 X-Spam-Level: X-Spam-Status: No, score=-101.364 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 okQapk-apEDC; Wed, 5 Mar 2008 13:53:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF8E28C190; Wed, 5 Mar 2008 13:53:30 -0800 (PST) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19E83A688A for ; Wed, 5 Mar 2008 13:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 WXIa8GhWEejI for ; Wed, 5 Mar 2008 13:53:27 -0800 (PST) Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id C5B363A686D for ; Wed, 5 Mar 2008 13:53:26 -0800 (PST) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id m25LrFk7002848 for ; Wed, 5 Mar 2008 15:53:16 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 5 Mar 2008 15:52:49 -0600 Received: from USDALSMBS04.ad3.ad.alcatel.com ([172.22.216.6]) by USDALSMBS03.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 5 Mar 2008 15:52:48 -0600 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_01C87F0B.40D14922" Date: Wed, 5 Mar 2008 15:53:03 -0600 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: PW redundancy draft Thread-Index: Ach7Gj9h4DiIsxyiRNO4lA85GNNbIAChO2UwACUiBiAANc5CUA== From: "MULEY Praveen" To: X-OriginalArrivalTime: 05 Mar 2008 21:52:48.0966 (UTC) FILETIME=[40DD1E60:01C87F0B] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Subject: [PWE3] PW redundancy draft X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C87F0B.40D14922 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Haven't seen the draft published yet so sending it mailing list directly. Please review the draft and let us know your comments, if any. Regards, Praveen ------_=_NextPart_001_01C87F0B.40D14922 Content-Type: text/plain; name="draft-ietf-pwe3-redundancy-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-pwe3-redundancy-00.txt Content-Disposition: attachment; filename="draft-ietf-pwe3-redundancy-00.txt" TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFByYXZlZW4gTXVsZXkgDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBNdXN0YXBoYSBBaXNzYW91aSANCkludGVuZGVkIFN0YXR1czogSW5mb3Jt YXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXR0aGV3IEJvY2NpIA0KRXhwaXJl czogQXVndXN0IDIwMDggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFByYW5qYWwgS3Vt YXIgRHV0dGEgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTWFyYyBMYXNzZXJyZSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQWxjYXRlbCAgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEpvbmF0aGFu IE5ld3RvbiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQ2FibGUgJiBXaXJlbGVzcyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9sZW4gU3Rv a2VzIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBFeHRyZW1lIE5ldHdvcmtzIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhhbWlkIE91bGQtQnJhaGlt IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBOb3J0ZWwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERhdmUgTWNkeXNhbiANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBWZXJpem9uIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR2lsZXMgSGVyb24gDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhvbWFz IE5hZGVhdSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQnJpdGlzaCBUZWxlY29tIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMywgMjAwOCANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIFBzZXVkb3dp cmUgKFBXKSBSZWR1bmRhbmN5IA0KICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1wd2UzLXJl ZHVuZGFuY3ktMDAudHh0IA0KDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8gDQoNCiAgIEJ5IHN1Ym1p dHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0ICAg ICAgIA0KICAgYW55IGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hp Y2ggaGUgb3Igc2hlIGlzICAgICAgIA0KICAgYXdhcmUgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlz Y2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSAgICAgICANCiAgIGJlY29tZXMgYXdh cmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgICAg ICAgDQogICBCQ1AgNzkuIA0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l bnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBp dHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgDQogICBvdGhlciBn cm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0N CiAgIERyYWZ0cy4gDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IA0KICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwg cmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgDQogICBhdCBhbnkgdGlt ZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyANCiAgIHJl ZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iIA0KDQoNCiANCiANCiANCk11bGV5IGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMg QXVndXN0IDMsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDFdIA0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgUHNldWRvd2lyZSAoUFcpIFJlZHVuZGFuY3kpICAgICAgICAgIEZlYnJ1YXJ5IDIw MDggDQogICAgDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBi ZSBhY2Nlc3NlZCBhdCANCiAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0 cmFjdHMudHh0IA0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0 b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3No YWRvdy5odG1sIA0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEF1Z3Vz dCAzLCAyMDA4LiANCg0KICAgIA0KDQpBYnN0cmFjdCANCg0KICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgYSBmcmFtZXdvcmsgY29tcHJpc2VkIG9mIGZldyBzY2VuYXJpb3MgYW5kIA0KICAgYXNz b2NpYXRlZCByZXF1aXJlbWVudHMgd2hlcmUgUFcgcmVkdW5kYW5jeSBpcyBuZWVkZWQuIEEgc2V0 IG9mIA0KICAgcmVkdW5kYW50IFBXcyBpcyBjb25maWd1cmVkIGJldHdlZW4gUEUgbm9kZXMgaW4g U1MtUFcgYXBwbGljYXRpb25zLCANCiAgIG9yIGJldHdlZW4gVC1QRSBub2RlcyBpbiBNUy1QVyBh cHBsaWNhdGlvbnMuIEluIG9yZGVyIGZvciB0aGUgUEUvVC1QRSANCiAgIG5vZGVzIHRvIGluZGlj YXRlIHRoZSBwcmVmZXJyZWQgUFcgcGF0aCB0byBmb3J3YXJkIHRvIG9uZSBhbm90aGVyLCBhIA0K ICAgbmV3IHN0YXR1cyBpcyBuZWVkZWQgdG8gaW5kaWNhdGUgdGhlIHByZWZlcmVudGlhbCBmb3J3 YXJkaW5nIHN0YXR1cyANCiAgIG9mIGFjdGl2ZSBvciBzdGFuZGJ5IGZvciBlYWNoIFBXIGluIHRo ZSByZWR1bmRhbmN5IHNldC4gDQoNCkNvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCAN Cg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFM TCIsICJTSEFMTCBOT1QiLCANCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRF RCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KICAgZG9jdW1lbnQgYXJlIHRvIGJl IGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMtMjExOSBbMV0uIA0KDQpUYWJsZSBvZiBD b250ZW50cyANCg0KICAgMS4gVGVybWlub2xvZ3kgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4gMyANCiAgIDIuIEludHJvZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uIDQgDQogICAzLiBSZWZlcmVuY2UgTW9kZWwuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiA0IA0KICAgICAgMy4xLiBNdWx0aXBsZSBNdWx0 aS1ob21lZC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gNSANCiAgICAgIDMuMi4gU2luZ2xl IEhvbWVkIENFIHdpdGggTVMtUFcgcmVkdW5kYW5jeS4uLi4uLi4uLi4uIDYgDQogICAgICAzLjMu IFBXIHJlZHVuZGFuY3kgYmV0d2VlbiBNVFUtcy4uLi4uLi4uLi4uLi4uLi4uLi4uLiA4IA0KICAg ICAgMy40LiBQVyByZWR1bmRhbmN5IGJldHdlZW4gbi1QRXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4g OSANCiAgICAgIDMuNS4gUFcgcmVkdW5kYW5jeSBpbiBCcmlkZ2UgTW9kdWxlIE1vZGVsLi4uLi4u Li4uLi4uIDkgDQogICA0LiBHZW5lcmljIFBXIHJlZHVuZGFuY3kgcmVxdWlyZW1lbnRzLi4uLi4u Li4uLi4uLi4uLi4uIDExIA0KICAgICAgNC4xLiBQcm90ZWN0aW9uIHN3aXRjaGluZyByZXF1aXJl bWVudHMuLi4uLi4uLi4uLi4uLiAxMSANCiAgICAgIDQuMi4gT3BlcmF0aW9uYWwgcmVxdWlyZW1l bnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMTEgDQogICA1LiBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDEyIA0KICAgNi4gQWNrbm93bGVkZ21l bnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxMiANCiAgIDcuIElBTkEg Y29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMTIgDQogICA4 LiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMTIg DQogICAgICA4LjEuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uIDEyIA0KICAgICAgOC4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLiAxMyANCiAgIEF1dGhvcidzIEFkZHJlc3Nlcy4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4gMTQgDQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50 IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDE1IA0KIA0KIA0KTXVsZXkgZXQgYWwuICAgICAgICAg ICAgRXhwaXJlcyBBdWd1c3QgMywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICBQc2V1ZG93aXJlIChQVykgUmVkdW5kYW5jeSkgICAgICAgICAg RmVicnVhcnkgMjAwOCANCiAgICANCg0KICAgRGlzY2xhaW1lciBvZiBWYWxpZGl0eS4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxNSANCiAgIEFja25vd2xlZGdtZW50IC4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMTYgDQogICAgDQoxLiBUZXJtaW5vbG9n eSAgDQoNCiAgIG8gIFBXIFRlcm1pbmF0aW5nIFByb3ZpZGVyIEVkZ2UgKFQtUEUpLiBBIFBFIHdo ZXJlIHRoZSBjdXN0b21lci0gICANCiAgICAgIGZhY2luZyBhdHRhY2htZW50IGNpcmN1aXRzIChB Q3MpIGFyZSBib3VuZCB0byBhIFBXIGZvcndhcmRlci4gQSAgIA0KICAgICAgVGVybWluYXRpbmcg UEUgaXMgcHJlc2VudCBpbiB0aGUgZmlyc3QgYW5kIGxhc3Qgc2VnbWVudHMgb2YgYSBNUy0NCiAg ICAgIFBXLiBUaGlzIGluY29ycG9yYXRlcyB0aGUgZnVuY3Rpb25hbGl0eSBvZiBhIFBFIGFzIGRl ZmluZWQgaW4gDQogICAgICBSRkMzOTg1IFszXS4gDQoNCiAgIG8gIFNpbmdsZS1TZWdtZW50IFBz ZXVkbyBXaXJlIChTUy1QVykuIEEgUFcgc2V0dXAgZGlyZWN0bHkgYmV0d2VlbiANCiAgICAgIHR3 byBULVBFIGRldmljZXMuIEVhY2ggUFcgaW4gb25lIGRpcmVjdGlvbiBvZiBhIFNTLVBXIHRyYXZl cnNlcyANCiAgICAgIG9uZSBQU04gdHVubmVsIHRoYXQgY29ubmVjdHMgdGhlIHR3byBULVBFcy4g IA0KDQogICBvICBNdWx0aS1TZWdtZW50IFBzZXVkbyBXaXJlIChNUy1QVykuIEEgc3RhdGljIG9y IGR5bmFtaWNhbGx5IA0KICAgICAgY29uZmlndXJlZCBzZXQgb2YgdHdvIG9yIG1vcmUgY29udGln dW91cyBQVyBzZWdtZW50cyB0aGF0IGJlaGF2ZSANCiAgICAgIGFuZCBmdW5jdGlvbiBhcyBhIHNp bmdsZSBwb2ludC10by1wb2ludCBQVy4gRWFjaCBlbmQgb2YgYSBNUy1QVyANCiAgICAgIGJ5IGRl ZmluaXRpb24gTVVTVCB0ZXJtaW5hdGUgb24gYSBULVBFLiANCg0KICAgbyAgUFcgU2VnbWVudC4g QSBwYXJ0IG9mIGEgc2luZ2xlLXNlZ21lbnQgb3IgbXVsdGktc2VnbWVudCBQVywgd2hpY2ggDQog ICAgICBpcyBzZXQgdXAgYmV0d2VlbiB0d28gUEUgZGV2aWNlcywgVC1QRXMgYW5kL29yIFMtUEVz LiANCg0KICAgbyAgUFcgU3dpdGNoaW5nIFByb3ZpZGVyIEVkZ2UgKFMtUEUpLiBBIFBFIGNhcGFi bGUgb2Ygc3dpdGNoaW5nIHRoZSANCiAgICAgIGNvbnRyb2wgYW5kIGRhdGEgcGxhbmVzIG9mIHRo ZSBwcmVjZWRpbmcgYW5kIHN1Y2NlZWRpbmcgUFcgDQogICAgICBzZWdtZW50cyBpbiBhIE1TLVBX LiBUaGUgUy1QRSB0ZXJtaW5hdGVzIHRoZSBQU04gdHVubmVscyBvZiB0aGUgDQogICAgICBwcmVj ZWRpbmcgYW5kIHN1Y2NlZWRpbmcgc2VnbWVudHMgb2YgdGhlIE1TLVBXLiANCg0KICAgbyAgUFcg c3dpdGNoaW5nIHBvaW50IGZvciBhIE1TLVBXLiBBIFBXIFN3aXRjaGluZyBQb2ludCBpcyBuZXZl ciB0aGUgDQogICAgICBTLVBFIGFuZCB0aGUgVC1QRSBmb3IgdGhlIHNhbWUgTVMtUFcuIEEgUFcg c3dpdGNoaW5nIHBvaW50IHJ1bnMgDQogICAgICBuZWNlc3NhcnkgcHJvdG9jb2xzIHRvIHNldHVw IGFuZCBtYW5hZ2UgUFcgc2VnbWVudHMgd2l0aCBvdGhlciBQVyANCiAgICAgIHN3aXRjaGluZyBw b2ludHMgYW5kIHRlcm1pbmF0aW5nIFBFcyANCg0KICAgbyAgQWN0aXZlIFBXLiAgQSBQVyB3aG9z ZSBwcmVmZXJlbnRpYWwgc3RhdHVzIGlzIHNldCB0byBBY3RpdmUgYW5kIA0KICAgICAgT3BlcmF0 aW9uYWwgc3RhdHVzIGlzIFVQLiAgDQoNCiAgIG8gIFN0YW5kYnkgUFcuIEEgUFcgd2hvc2UgcHJl ZmVyZW50aWFsIHN0YXR1cyBpcyBzZXQgdG8gU3RhbmRieSBhbmQgDQogICAgICBPcGVyYXRpb25h bCBzdGF0dXMgaXMgVVAuICANCg0KICAgbyAgUHJpbWFyeSBQYXRoLiBUaGUgY29uZmlndXJlZCBw YXRoIHdoaWNoIGlzIHByZWZlcnJlZCB3aGVuIA0KICAgICAgcmV2ZXJ0aXZlIHByb3RlY3Rpb24g c3dpdGNoaW5nIGlzIHVzZWQuIA0KDQogICBvICBTZWNvbmRhcnkgUGF0aC4gIE9uZSBvciBtb3Jl IGNvbmZpZ3VyZWQgcGF0aHMgdGhhdCBhcmUgdXNlZCBieSANCiAgICAgIHByb3RlY3Rpb24gc3dp dGNoaW5nIHdoZW4gY3VycmVudCBhY3RpdmUgUFcgcGF0aCBlbnRlcnMgDQogICAgICBPcGVyYXRp b25hbCBET1dOIHN0YXRlLiANCg0KDQogDQogDQpNdWxleSBldCBhbC4gICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAzLCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAzXSANCgwNCkludGVybmV0 LURyYWZ0ICAgICAgIFBzZXVkb3dpcmUgKFBXKSBSZWR1bmRhbmN5KSAgICAgICAgICBGZWJydWFy eSAyMDA4IA0KICAgIA0KDQogICBvICBSZXZlcnRpdmUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuIFRy YWZmaWMgd2lsbCBiZSBjYXJyaWVkIGJ5IA0KICAgICAgcHJpbWFyeSBwYXRoIGlmIGl0IGlzIE9w ZXJhdGlvbmFsbHkgVVAgYW5kIHRoZSB3YWl0LXRvLXJlc3RvcmUgDQogICAgICB0aW1lciBleHBp cmVzIGFuZCBwcmltYXJ5IHBhdGggaXMgbWFkZSB0aGUgQWN0aXZlIFBXLiANCg0KICAgbyAgTm9u LXJldmVydGl2ZSBwcm90ZWN0aW9uIHN3aXRjaGluZy4gVHJhZmZpYyB3aWxsIGJlIGNhcnJpZWQg YnkgDQogICAgICB0aGUgbGFzdCBQVyBwYXRoIHNlbGVjdGVkIGFzIGEgcmVzdWx0IG9mIHByZXZp b3VzIGFjdGl2ZSBwYXRoIA0KICAgICAgZW50ZXJpbmcgT3BlcmF0aW9uYWxseSBET1dOIHN0YXRl LiAgIA0KDQogICBvICBNYW51YWwgc2VsZWN0aW9uIG9mIFBXIHBhdGguIEFiaWxpdHkgZm9yIHRo ZSBvcGVyYXRvciB0byBtYW51YWxseSANCiAgICAgIHNlbGVjdCB0aGUgcHJpbWFyeS9zZWNvbmRh cnkgcGF0aHMuICAgIA0KDQogICAgDQoNCiAgDQoNCjIuIEludHJvZHVjdGlvbiANCg0KICAgSW4g c2luZ2xlLXNlZ21lbnQgUFcgKFNTLVBXKSBhcHBsaWNhdGlvbnMsIHByb3RlY3Rpb24gZm9yIHRo ZSBQVyBpcyANCiAgIHByb3ZpZGVkIGJ5IHRoZSBQU04gbGF5ZXIuIFRoaXMgbWF5IGJlIGFuIFJT VlAgTFNQIHdpdGggYSBGUlIgYmFja3VwIA0KICAgYW5kL29yIGFuIGVuZC10by1lbmQgYmFja3Vw IExTUC4gVGhlcmUgYXJlIGFwcGxpY2F0aW9ucyBob3dldmVyIHdoZXJlIA0KICAgdGhlIGJhY2t1 cCBQVyB0ZXJtaW5hdGVzIG9uIGEgZGlmZmVyZW50IHRhcmdldCBQRSBub2RlLiBQU04gDQogICBw cm90ZWN0aW9uIG1lY2hhbmlzbXMgY2Fubm90IHByb3RlY3QgYWdhaW5zdCBmYWlsdXJlIG9mIHRo ZSB0YXJnZXQgUEUgDQogICBub2RlIG9yIHRoZSBmYWlsdXJlIG9mIHRoZSByZW1vdGUgQUMuICAN Cg0KICAgSW4gbXVsdGktc2VnbWVudCBQVyAoTVMtUFcpIGFwcGxpY2F0aW9ucywgYSBwcmltYXJ5 IGFuZCBvbmUgb3IgbW9yZSANCiAgIHNlY29uZGFyeSBQV3MgaW4gc3RhbmRieSBtb2RlIGFyZSBj b25maWd1cmVkIGluIHRoZSBuZXR3b3JrLiBUaGUgDQogICBwYXRocyBvZiB0aGVzZSBQV3MgYXJl IGRpdmVyc2UgaW4gdGhlIHNlbnNlIHRoYXQgdGhleSBhcmUgc3dpdGNoZWQgYXQgDQogICBkaWZm ZXJlbnQgUy1QRSBub2Rlcy4gSW4gdGhlc2UgYXBwbGljYXRpb25zLCBQVyByZWR1bmRhbmN5IGlz IA0KICAgaW1wb3J0YW50IGZvciB0aGUgc2VydmljZSByZXNpbGllbmNlLiAgDQoNCiAgICAgICBJ biBzb21lIGRlcGxveW1lbnRzLCBpdCBpcyBpbXBvcnRhbnQgZm9yIG9wZXJhdG9ycyB0aGF0IA0K ICAgcGFydGljdWxhciBQVyBpcyBwcmVmZXJyZWQgaWYgaXQgaXMgYXZhaWxhYmxlLiBGb3IgZXhh bXBsZSwgUFcgcGF0aCANCiAgIHdpdGggbGVhc3QgbGF0ZW5jeSBtYXkgYmUgcHJlZmVycmVkLiAg IA0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBmcmFtZXdvcmsgZm9yIHRoZXNlIGFwcGxp Y2F0aW9ucyBhbmQgaXRzIA0KICAgYXNzb2NpYXRlZCBvcGVyYXRpb25hbCByZXF1aXJlbWVudHMu IFRoZSBmcmFtZXdvcmsgY29tcHJpc2VzIG9mIG5ldyANCiAgIHJlcXVpcmVkIHN0YXR1cyBjYWxs ZWQgcHJlZmVyZW50aWFsIHN0YXR1cyB0byBQVyBhcGFydCBmcm9tIHRoZSANCiAgIG9wZXJhdGlv bmFsIHN0YXR1cyBhbHJlYWR5IGRlZmluZWQgaW4gdGhlIFBXRTMgY29udHJvbCBwcm90b2NvbCBb Ml0uIA0KICAgVGhlIGRlZmluaXRpb24gYW5kIG9wZXJhdGlvbiBvZiB0aGUgcHJlZmVyZW50aWFs IHN0YXR1cyBpcyBjb3ZlcmVkIGluIA0KICAgcmVmLls3XSANCg0KICAgIA0KDQozLiBSZWZlcmVu Y2UgTW9kZWwgICANCg0KICAgRm9sbG93aW5nIGZpZ3VyZXMgc2hvd3MgdGhlIHJlZmVyZW5jZSBt b2RlbCBmb3IgdGhlIFBXIHJlZHVuZGFuY3kgYW5kIA0KICAgaXRzIHVzYWdlIGluIGRpZmZlcmVu dCB0b3BvbG9naWVzIGFuZCBhcHBsaWNhdGlvbnMuIA0KIA0KIA0KTXVsZXkgZXQgYWwuICAgICAg ICAgICAgRXhwaXJlcyBBdWd1c3QgMywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICBQc2V1ZG93aXJlIChQVykgUmVkdW5kYW5jeSkgICAgICAg ICAgRmVicnVhcnkgMjAwOCANCiAgICANCg0KMy4xLiBNdWx0aXBsZSBNdWx0aS1ob21lZCANCg0K ICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLSBFbXVsYXRlZCBTZXJ2aWNlIC0tLS0tLS0tLS0tLS0t LS0+fCAgDQogICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICANCiAgICAgICAgIHwgICAgICAgICAgfDwtLS0tLS0tIFBzZXVkbyBXaXJl IC0tLS0tLT58ICAgICAgICAgIHwgIA0KICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgfCAgDQogICAgICAgICB8ICAgICAgICAgIHwgICAg fDwtLSBQU04gVHVubmVscy0tPnwgICAgfCAgICAgICAgICB8ICANCiAgICAgICAgIHwgICAgICAg ICAgViAgICBWICAgICAgICAgICAgICAgICAgViAgICBWICAgICAgICAgIHwgIA0KICAgICAgICAg ViAgICBBQyAgICArLS0tLSsgICAgICAgICAgICAgICAgICArLS0tLSsgICAgIEFDICAgViAgDQog ICArLS0tLS0rICAgIHwgICAgIHwuLi4ufC4uLi4uLi5QVzEuLi4uLi4uLnwuLi4ufCAgICAgfCAg ICArLS0tLS0rICANCiAgIHwgICAgIHwtLS0tLS0tLS0tfCBQRTF8Li4uLi4uICAgLi4uLi4uLi4u fCBQRTN8LS0tLS0tLS0tLXwgICAgIHwgIA0KICAgfCBDRTEgfCAgICAgICAgICArLS0tLSsgICAg ICBcIC8gIFBXMyAgICArLS0tLSsgICAgICAgICAgfCBDRTIgfCAgDQogICB8ICAgICB8ICAgICAg ICAgICstLS0tKyAgICAgICBYICAgICAgICAgICstLS0tKyAgICAgICAgICB8ICAgICB8IA0KICAg fCAgICAgfCAgICAgICAgICB8ICAgIHwuLi4uLi4vIFwuLlBXNC4uLi58ICAgIHwgICAgICAgICAg fCAgICAgfCAgDQogICB8ICAgICB8LS0tLS0tLS0tLXwgUEUyfCAgICAgICAgICAgICAgICAgIHwg UEU0fC0tLS0tLS0tLSB8ICAgICB8ICANCiAgICstLS0tLSsgICAgfCAgICAgfC4uLi58Li4uLi5Q VzIuLi4uLi4uLi4ufC4uLi58ICAgICB8ICAgICstLS0tLSsgIA0KICAgICAgICAgICAgICBBQyAg ICArLS0tLSsgICAgICAgICAgICAgICAgICArLS0tLSsgICAgQUMgICAgICAgDQogICAgIA0KICAg IA0KICAgRmlndXJlIDEgTXVsdGlwbGUgTXVsdGktaG9tZWQgQ0VzIHdpdGggc2luZ2xlIFNTLVBX IHJlZHVuZGFuY3kgIA0KDQogICBJbiB0aGUgRmlndXJlIDEgaWxsdXN0cmF0ZWQgYWJvdmUgYm90 aCBDRXMsIENFMSBhbmQgQ0UyIGFyZSBkdWFsLSANCiAgIGhvbWVkIHdpdGggUEVzLCBQRTEsIFBF MiBhbmQgUEUzLCBQRTQgcmVzcGVjdGl2ZWx5LiBUaGUgbWV0aG9kIGZvciANCiAgIGR1YWwtaG9t aW5nIGFuZCB0aGUgdXNlZCBwcm90b2NvbHMgc3VjaCBhcyBNdWx0aS1jaGFzc2lzIExpbmsgDQog ICBBZ2dyZWdhdGlvbiBHcm91cCAoTUMtTEFHKSBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhp cyBkb2N1bWVudC4gIA0KICAgTm90ZSB0aGF0IHRoZSBQU04gdHVubmVscyBhcmUgbm90IHNob3du IGluIHRoaXMgZmlndXJlIGZvciBjbGFyaXR5LiANCiAgIEhvd2V2ZXIsIGl0IGNhbiBiZSBhc3N1 bWVkIHRoYXQgZWFjaCBvZiB0aGUgUFdzIHNob3duIGlzIGVuY2Fwc3VsYXRlZCANCiAgIGluIGEg c2VwYXJhdGUgUFNOIHR1bm5lbC4gDQoNCiAgICAgICAgICBQRTEgaGFzIFBXMSBhbmQgUFc0IHNl cnZpY2UgY29ubmVjdGluZyBQRTMgYW5kIFBFNCANCiAgIHJlc3BlY3RpdmVseS4gU2ltaWxhcmx5 IFBFMiBoYXMgUFcyIGFuZCBQdzMgcHNldWRvIHdpcmUgc2VydmljZSANCiAgIGNvbm5lY3Rpbmcg UEU0IGFuZCBQRTMgcmVzcGVjdGl2ZWx5LiBQVzEsIFBXMiwgUFczIGFuZCBQVzQgYXJlIGFsbCAN CiAgIG9wZXJhdGlvbmFsbHkgVVAuIEluIG9yZGVyIHRvIHN1cHBvcnQgTjoxIG9yIDE6MSBvbmx5 IG9uZSBQVyBpcyANCiAgIHJlcXVpcmVkIHRvIGJlIHNlbGVjdGVkIHRvIGZvcndhcmQgdGhlIHRy YWZmaWMuIFRodXMgdGhlIFBXIG5lZWRzIHRvIA0KICAgcmVmbGVjdCBoaXMgbmV3IHN0YXR1cyBh cGFydCBmcm9tIHRoZSBvcGVyYXRpb25hbCBzdGF0dXMuIFdlIGNhbGwgDQogICB0aGlzIGFzIHBy ZWZlcmVudGlhbCBmb3J3YXJkaW5nIHN0YXR1cyB3aXRoIHN0YXRlIHJlcHJlc2VudGluZyANCiAg ICdhY3RpdmUnIHRoZSBvbmUgY2FycnlpbmcgdHJhZmZpYyB3aGlsZSB0aGUgb3RoZXIgJ3N0YW5k YnknIHdoaWNoIGlzIA0KICAgb3BlcmF0aW9uYWxseSBVUCBidXQgbm90IGZvcndhcmRpbmcgdHJh ZmZpYy4gVGhlIG1ldGhvZCBvZiBkZXJpdmluZyANCiAgIEFjdGl2ZS9TdGFuZGJ5IHN0YXR1cyBv ZiB0aGUgQUMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyANCiAgIGRvY3VtZW50LiBJbiBj YXNlIG9mIE1DLUxBRyBpdCBpcyBkZXJpdmVkIGJ5IHRoZSBMaW5rIEFnZ3JlZ2F0aW9uIA0KICAg Q29udHJvbCBwcm90b2NvbCAoTEFDUCkgbmVnb3RpYXRpb24uICAgIA0KDQogICBBIG5ldyBhbGdv cml0aG0gbmVlZHMgdG8gYmUgZGV2ZWxvcGVkIHVzaW5nIHRoZSBwcmVmZXJlbnRpYWwgDQogICBm b3J3YXJkaW5nIHN0YXRlIG9mIFBXIGFuZCBzZWxlY3Qgb25seSBvbmUgUFcgdG8gZm9yd2FyZC4g IA0KDQogICAgICAgICAgICAgICAgICBPbiBmYWlsdXJlIG9mIEFDIGJldHdlZW4gdGhlIGR1YWwg aG9tZWQgQ0UxIGluIHRoaXMgDQogICBjYXNlIGxldHMgc2F5IFBFMSB0aGUgcHJlZmVyZW50aWFs IHN0YXR1cyBvbiBQRTIgbmVlZHMgdG8gYmUgY2hhbmdlZC4gDQogDQogDQpNdWxleSBldCBhbC4g ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAzLCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSA1 XSANCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFBzZXVkb3dpcmUgKFBXKSBSZWR1bmRhbmN5KSAg ICAgICAgICBGZWJydWFyeSAyMDA4IA0KICAgIA0KDQogICBEaWZmZXJlbnQgbWVjaGFuaXNtcy9w cm90b2NvbHMgY2FuIGJlIHVzZWQgdG8gYWNoaWV2ZSB0aGlzIGFuZCB0aGVzZSANCiAgIGFyZSBi ZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuIEZvciBleGFtcGxlIHRoZSBNQy1MQUcg Y29udHJvbCANCiAgIHByb3RvY29sIGNoYW5nZXMgdGhlIGxpbmsgc3RhdHVzIG9uIFBFMiB0byBh Y3RpdmUuIEFmdGVyIHRoZSBjaGFuZ2UgDQogICBpbiBzdGF0dXMgdGhlIGFsZ29yaXRobSBmb3Ig c2VsZWN0aW9uIG9mIFBXIG5lZWRzIHRvIHJldmFsdWF0ZSBhbmQgDQogICBzZWxlY3QgUFcgdG8g Zm9yd2FyZCB0aGUgdHJhZmZpYy4gDQoNCiAgIEluIHRoaXMgYXBwbGljYXRpb24sIGJlY2F1c2Ug ZWFjaCBkdWFsLWhvbWluZyBhbGdvcml0aG0gcnVubmluZyBvbiANCiAgIHRoZSB0d28gbm9kZSBz ZXRzLCBpLmUuLCB7Q0UxLCBQRTEsIFBFMn0gYW5kIHtDRTIsIFBFMywgUEU0fSwgc2VsZWN0cyAN CiAgIHRoZSBhY3RpdmUgQUMgaW5kZXBlbmRlbnRseSwgdGhlcmUgaXMgYSBuZWVkIHRvIHNpZ25h bCB0aGUgYWN0aXZlIA0KICAgc3RhdHVzIG9mIHRoZSBBQyBzdWNoIHRoYXQgdGhlIFBFIG5vZGVz IGNhbiBzZWxlY3QgYSBjb21tb24gYWN0aXZlIFBXIA0KICAgcGF0aCBmb3IgZW5kLXRvLWVuZCBm b3J3YXJkaW5nIGJldHdlZW4gQ0UxIGFuZCBDRTIuIFRoaXMgaGVscHMgaW4gDQogICByZXN0cmlj dGluZyB0aGUgY2hhbmdlcyBvY2N1cnJpbmcgb24gb25lIHNpZGUgb2YgbmV0d29yayBkdWUgdG8g DQogICBmYWlsdXJlIHRvIHRoZSBvdGhlciBzaWRlIG9mIHRoZSBuZXR3b3JrLiAgTm90ZSB0aGlz IG1ldGhvZCBhbHNvIA0KICAgcHJvdGVjdHMgYWdhaW5zdCBhbnkgc2luZ2xlIFBFIGZhaWx1cmUg b3Igc29tZSBkdWFsIFBFIGZhaWx1cmVzLiANCg0KICAgICAgICAgICAgICAgICBPbmUgTXVsdGkt aG9tZWQgQ0Ugd2l0aCBzaW5nbGUgU1MtUFcgcmVkdW5kYW5jeSANCiAgIGFwcGxpY2F0aW9uIGlz IGEgc3Vic2V0IG9mIGFib3ZlLiBPbmx5IFBXMSBhbmQgUFczIGV4aXN0IGluIHRoaXMgDQogICBj YXNlLiBUaGlzIGhlbHBzIGFnYWluc3QgQUMgZmFpbHVyZSBhbmQgUEUgZmFpbHVyZSBvZiBkdWFs IGhvbWVkIEFDLiANCiAgIFNpbWlsYXIgcmVxdWlyZW1lbnRzIGFwcGxpZXMgaW4gdXNhZ2UgTVMt UFcgcmVkdW5kYW5jeSBhcyB3ZWxsLiBBbiANCiAgIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnQgYXBw bGljYWJsZSB0byBNUy1QVyBpcyBmb3J3YXJkaW5nIG9mIHN0YXR1cyANCiAgIG5vdGlmaWNhdGlv biB0aHJvdWdoIFMtUEUuIEluIGdlbmVyYWwgZnJvbSBjdXN0b21lciB2aWV3LCBTUy1QVyBhbmQg DQogICBNUy1QVyBoYXMgc2ltaWxhciByZXNpbGllbmN5IHJlcXVpcmVtZW50LiANCg0KICAgVGhl cmUgaXMgYWxzbyBhIDE6MSBwcm90ZWN0aW9uIHN3aXRjaGluZyBjYXNlIHRoYXQgaXMgYSBzdWJz ZXQgb2YgdGhlIA0KICAgYWJvdmUgd2hlcmUgUFczIGFuZCBQVzQgYXJlIG5vdCBwcmVzZW50IGFu ZCB0aGUgQ0VzIGRvIG5vdCBwZXJmb3JtIA0KICAgbmF0aXZlIHNlcnZpY2UgcHJvdGVjdGlvbiBz d2l0Y2hpbmcsIGJ1dCBpbnN0ZWFkIG1heSB1c2UgbG9hZCANCiAgIGJhbGFuY2luZy4gVGhpcyBw cm90ZWN0cyBhZ2FpbnN0IEFDIGZhaWx1cmVzIGFuZCBjYW4gdXNlIHRoZSBuYXRpdmUgDQogICBz ZXJ2aWNlIHRvIGluZGljYXRlIGFjdGl2ZS9mYWlsZWQgc3RhdGUuICANCg0KICAgICAgSWYgZWFj aCBDRSBob21lcyB0byBkaWZmZXJlbnQgUEVzLCB0aGVuIHRoZSBDRXMgY2FuIGltcGxlbWVudCAN CiAgIG5hdGl2ZSBzZXJ2aWNlIHByb3RlY3Rpb24gc3dpdGNoaW5nLCB3aXRob3V0IGFueSBQVyBy ZWR1bmRhbmN5IA0KICAgZnVuY3Rpb25zLiBBbGwgdGhhdCB0aGUgUFcgbmVlZHMgdG8gZG8gaXMg ZGV0ZWN0IEFDLCBQRSwgb3IgUFNOIA0KICAgdHVubmVsIGZhaWx1cmVzIGFuZCBjb252ZXkgdGhh dCBpbmZvcm1hdGlvbiB0byBib3RoIFBFcyBhdCB0aGUgZW5kIG9mIA0KICAgdGhlIFBXLiBUaGlz IGlzIGFwcGxpY2FibGUgdG8gTVMtUFcgYXMgd2VsbC4gDQoNCjMuMi4gU2luZ2xlIEhvbWVkIENF IHdpdGggTVMtUFcgcmVkdW5kYW5jeSANCg0KICAgVGhpcyBpcyB0aGUgbWFpbiBhcHBsaWNhdGlv biBvZiBpbnRlcmVzdCBhbmQgdGhlIG5ldHdvcmsgc2V0dXAgaXMgDQogICBzaG93biBpbiBGaWd1 cmUgMiANCg0KDQoNCg0KDQoNCg0KDQogDQogDQpNdWxleSBldCBhbC4gICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAzLCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSA2XSANCgwNCkludGVybmV0 LURyYWZ0ICAgICAgIFBzZXVkb3dpcmUgKFBXKSBSZWR1bmRhbmN5KSAgICAgICAgICBGZWJydWFy eSAyMDA4IA0KICAgIA0KDQogICAgICAgTmF0aXZlICAgfDwtLS0tLS0tLS0tLS1Qc2V1ZG8gV2ly ZS0tLS0tLS0tLS0tLT58ICBOYXRpdmUgICANCiAgICAgICBTZXJ2aWNlICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFNlcnZpY2UgICANCiAgICAgICAgKEFDKSAgICB8 ICAgICB8PC1QU04xLS0+fCAgICAgfDwtUFNOMi0tPnwgICAgIHwgIChBQykgICANCiAgICAgICAg ICB8ICAgICBWICAgICBWICAgICAgICAgViAgICAgViAgICAgICAgIFYgICAgIFYgICB8ICAgDQog ICAgICAgICAgfCAgICAgKy0tLS0tKyAgICAgICAgICstLS0tLSsgICAgICAgICArLS0tLS0rICAg fCAgIA0KICAgKy0tLS0rIHwgICAgIHxULVBFMXw9PT09PT09PT18Uy1QRTF8PT09PT09PT09fFQt UEUyfCAgIHwgICArLS0tLSsgICANCiAgIHwgICAgfC0tLS0tLS18Li4uLi4uUFcxLVNlZzEuLi4u Li4ufC5QVzEtU2VnMi4uLi4uLnwtLS0tLS0tfCAgICB8ICAgDQogICB8IENFMXwgICAgICAgfCAg ICAgfD09PT09PT09PXwgICAgIHw9PT09PT09PT18ICAgICB8ICAgICAgIHwgQ0UyfCANCiAgIHwg ICAgfCAgICAgICArLS0tLS0rICAgICAgICAgKy0tLS0tKyAgICAgICAgICstLS0tLSsgICAgICAg fCAgICB8ICAgDQogICArLS0tLSsgICAgICAgIHwufHwufCAgICAgICAgICAgICAgICAgICAgICAg ICAgfC58fC58ICAgICAgICstLS0tKyAgDQogICAgICAgICAgICAgICAgIHwufHwufCAgICAgICAg ICstLS0tLSsgICAgICAgICAgfC58fC58ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAg fC58fC58PT09PT09PT09fCAgICAgfD09PT09PT09PT0gLnx8LnwgDQogICAgICAgICAgICAgICAg IHwufHwuLi5QVzItU2VnMS4uLi4uLnwuUFcyLVNlZzIuLi58fC58ICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgfC58ID09PT09PT09PT09fFMtUEUyfD09PT09PT09PT09PSB8LnwgICAg ICAgIA0KICAgICAgICAgICAgICAgICB8LnwgICAgICAgICAgICArLS0tLS0rICAgICAgICAgICAg IHwufCAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgIHwufD09PT09PT09PT09PSstLS0t LSs9PT09PT09PT09PT09IC58ICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICB8Li4uLi5Q VzMtU2VnMS58ICAgICB8IFBXMy1TZWcyLi4uLi4ufCAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgICA9PT09PT09PT09PT09PXxTLVBFM3w9PT09PT09PT09PT09PT0gICAgICAgICAgICAg IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLSsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgIA0KICAgRmlndXJlIDIgU2luZ2xlIGhv bWVkIENFIHdpdGggbXVsdGktc2VnbWVudCBwc2V1ZG8td2lyZSByZWR1bmRhbmN5IA0KDQogICBJ biBGaWd1cmUgMiwgQ0UxIGlzIGNvbm5lY3RlZCB0byBQRTEgaW4gcHJvdmlkZXIgRWRnZSAxIGFu ZCBDRTIgdG8gDQogICBQRTIgaW4gcHJvdmlkZXIgZWRnZSAyIHJlc3BlY3RpdmVseS4gVGhlcmUg YXJlIHRocmVlIHNlZ21lbnRlZCBQV3MuIEEgIA0KICAgUFcxLCBpcyBzd2l0Y2hlZCBhdCBTLVBF MSwgUFcyLCB3aGljaCBpcyBzd2l0Y2hlZCBhdCBTLVBFMiBhbmQgUFczLCANCiAgIGlzIHN3aXRj aGVkIGF0IFMtUEUzLiANCg0KICAgICAgICAgICAgICAgICAgIFNpbmNlIHRoZXJlIGlzIG5vIG11 bHRpLWhvbWluZyBydW5uaW5nIG9uIHRoZSBBQywgdGhlIA0KICAgVC1QRSBub2RlcyB3b3VsZCBh ZHZlcnRpc2UgJ0FjdGl2ZScgZm9yIHRoZSBmb3J3YXJkaW5nIHN0YXR1cyBiYXNlZCANCiAgIG9u IHRoZSBwcmlvcml0eS4gUHJpb3JpdGllcyBhc3NvY2lhdGUgbWVhbmluZyBvZiAncHJpbWFyeSBQ VycgYW5kIA0KICAgJ3NlY29uZGFyeSBQVycuIFRoZXNlIHByaW9yaXRpZXMgTVVTVCBiZSB1c2Vk IGluIHJldmVydGl2ZSBtb2RlIGFzIA0KICAgd2VsbCBhbmQgcGF0aHMgbXVzdCBiZSBzd2l0Y2hl ZCBhY2NvcmRpbmdseS4gVGhlIHByaW9yaXR5IGNhbiBiZSANCiAgIGNvbmZpZ3VyYXRpb24gb3Ig ZGVyaXZhdGlvbiBmcm9tIHRoZSBQV2lkLiBMb3dlciB0aGUgUFdpZCBoaWdoZXIgdGhlIA0KICAg cHJpb3JpdHkuIEhvd2V2ZXIsIHRoaXMgZG9lcyBub3QgZ3VhcmFudGVlIHRoYXQgcGF0aHMgb2Yg dGhlIFBXIGFyZSANCiAgIHN5bmNocm9uaXplZCBiZWNhdXNlIGZvciBleGFtcGxlIG9mIG1pc21h dGNoIG9mIHRoZSBjb25maWd1cmF0aW9uIG9mIA0KICAgdGhlIFBXIHByaW9yaXR5IGluIGVhY2gg VC1QRS4gVGhlIGludGVudCBvZiB0aGlzIGFwcGxpY2F0aW9uIGlzIHRvIA0KICAgaGF2ZSBULVBF MSBhbmQgVC1QRTIgc3luY2hyb25pemUgdGhlIHRyYW5zbWl0IGFuZCByZWNlaXZlIHBhdGhzIG9m IA0KICAgdGhlIFBXIG92ZXIgdGhlIG5ldHdvcmsuIEluIG90aGVyIHdvcmRzLCBib3RoIFQtUEUg bm9kZXMgYXJlIHJlcXVpcmVkIA0KICAgdG8gdHJhbnNtaXQgb3ZlciB0aGUgUFcgc2VnbWVudCB3 aGljaCBpcyBzd2l0Y2hlZCBieSB0aGUgc2FtZSBTLVBFLiANCiAgIFRoaXMgaXMgZGVzaXJhYmxl IGZvciBlYXNlIG9mIG9wZXJhdGlvbiBhbmQgdHJvdWJsZXNob290aW5nLiAgDQoNCiAgICAgICAN Cg0KDQoNCg0KIA0KIA0KTXVsZXkgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMywg MjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgN10gDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBQ c2V1ZG93aXJlIChQVykgUmVkdW5kYW5jeSkgICAgICAgICAgRmVicnVhcnkgMjAwOCANCiAgICAN Cg0KMy4zLiBQVyByZWR1bmRhbmN5IGJldHdlZW4gTVRVLXMgIA0KDQogICBGb2xsb3dpbmcgZmln dXJlIGlsbHVzdHJhdGVzIHRoZSBhcHBsaWNhdGlvbiBvZiB1c2Ugb2YgUFcgcmVkdW5kYW5jeSAN CiAgIGluIHNwb2tlIFBXIGJ5IGR1YWwgaG9tZWQgTVRVLXMgdG8gUEVzLiANCg0KICAgICAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgIHw8LVBTTjEtLT58ICAgICB8PC1QU04yLS0+fCAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgIFYgICAgICAgICBWICAgICBWICAgICAgICAgViAg ICAgICAgDQogICAgICAgICAgICAgICArLS0tLS0rICAgICAgICAgKy0tLS0tKyAgICAgICAgICAg DQogICAgICAgICAgICAgICB8TVRVLXN8PT09PT09PT09fFBFMSAgfD09PT09PT09ICANCiAgICAg ICAgICAgICAgIHwuLkFjdGl2ZSBQVyBncm91cC4uLi58IEgtVlBMUy1jb3JlIA0KICAgICAgICAg ICAgICAgfCAgICAgfD09PT09PT09PXwgICAgIHw9PT09PT09PT0gDQogICAgICAgICAgICAgICAr LS0tLS0rICAgICAgICAgKy0tLS0tKyAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICB8Lnwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICB8LnwgICAgICAg ICAgICstLS0tLSsgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICB8Lnw9 PT09PT09PT09PXwgICAgIHw9PT09PT09PT09ICANCiAgICAgICAgICAgICAgICAgIHwuLi5TdGFu ZGJ5IFBXIGdyb3VwfC5ILVZQTFMtY29yZSAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAg ICAgPT09PT09PT09PT09PXwgIFBFMnw9PT09PT09PT09ICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tKyAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KICAgICAgICAgICAgICAgRmlndXJlIDMgIE11bHRpLWhvbWVkIE1UVS1zIGluIEgtVlBMUyBj b3JlICAgICAgICAgICAgICAgICAgIA0KDQogICBJbiBGaWd1cmUgMywgTVRVLXMgaXMgZHVhbCBo b21lZCB0byBQRTEgYW5kIFBFMiBhbmQgaGFzIHNwb2tlIFBXcyB0byANCiAgIGVhY2ggb2YgdGhl bS4gTVRVLXMgbmVlZHMgdG8gY2hvb3NlIG9ubHkgb25lIG9mIHRoZSBzcG9rZSBQVyAoYWN0aXZl IA0KICAgUFcpIHRvIG9uZSBvZiB0aGUgUEUgdG8gZm9yd2FyZCB0aGUgdHJhZmZpYyBhbmQgdGhl IG90aGVyIHRvIHN0YW5kYnkgDQogICBzdGF0dXMuIE1UVS1zIGNhbiBkZXJpdmUgdGhlIHN0YXR1 cyBvZiB0aGUgUFdzIGJhc2VkIG9uIGxvY2FsIHBvbGljeSANCiAgIGNvbmZpZ3VyYXRpb24uIFBF MSBhbmQgUEUyIGFyZSBjb25uZWN0ZWQgdG8gSC1WUExTIGNvcmUgb24gdGhlIG90aGVyIA0KICAg c2lkZSBvZiBuZXR3b3JrLiBNVFUtcyBjb21tdW5pY2F0ZXMgdGhlIHN0YXR1cyBvZiBpdHMgbWVt YmVyIFBXcyBmb3IgDQogICBhIHNldCBvZiBWU0lzIGhhdmluZyBjb21tb24gc3RhdHVzIEFjdGl2 ZS9TdGFuZGJ5LiBIZXJlIE1UVS1zIA0KICAgY29udHJvbHMgdGhlIHNlbGVjdGlvbiBvZiBQV3Mg dG8gZm9yd2FyZCB0aGUgdHJhZmZpYy4gU2lnbmFsaW5nICANCiAgIHVzaW5nIFBXIGdyb3VwaW5n IHdpdGggY29tbW9uIGdyb3VwLWlkIGluIFBXaWQgRkVDIEVsZW1lbnQgb3IgDQogICBHcm91cGlu ZyBUTFYgaW4gR2VuZXJhbGl6ZWQgUFdpZCBGRUMgRWxlbWVudCBhcyBkZWZpbmVkIGluIFsyXSB0 byBQRTEgDQogICBhbmQgUEUyIHJlc3BlY3RpdmVseSwgaXMgZW5jb3VyYWdlZCB0byBzY2FsZSBi ZXR0ZXIuICAgDQoNCiAgICAgICAgICAgICAgICAgICAgICBXaGVuZXZlciBNVFUtcyBwZXJmb3Jt cyBhIHN3aXRjaG92ZXIsIGl0IG5lZWRzIHRvIA0KICAgY29tbXVuaWNhdGUgdG8gUEUyLXJzIGZv ciB0aGUgU3RhbmRieSBQVyBncm91cCB0aGUgY2hhbmdlZCBzdGF0dXMgb2YgDQogICBhY3RpdmUu IA0KDQogICAgICAgICAgICAgICAgICAgSW4gdGhpcyBzY2VuYXJpbywgUEUgZGV2aWNlcyBhcmUg YXdhcmUgb2Ygc3dpdGNob3ZlcnMgDQogICBhdCBNVFUtcyBhbmQgY291bGQgZ2VuZXJhdGUgTUFD IFdpdGhkcmF3IE1lc3NhZ2VzIHRvIHRyaWdnZXIgTUFDIA0KICAgZmx1c2hpbmcgd2l0aGluIHRo ZSBILVZQTFMgZnVsbCBtZXNoLiBCeSBkZWZhdWx0LCBNVFUtcyBkZXZpY2VzIA0KICAgc2hvdWxk IHN0aWxsIHRyaWdnZXIgTUFDIFdpdGhkcmF3IG1lc3NhZ2VzIGFzIGN1cnJlbnRseSBkZWZpbmVk IGluIA0KICAgWzVdIHRvIHByZXZlbnQgdHdvIGNvcGllcyBvZiBNQUMgd2l0aGRyYXdzIHRvIGJl IHNlbnQgKG9uZSBieSBNVFUtcyANCiAgIGFuZCBhbm90aGVyIG9uZSBieSBQRXMpLiBNZWNoYW5p c21zIHRvIGRpc2FibGUgTUFDIFdpdGhkcmF3IHRyaWdnZXIgDQogICBpbiBjZXJ0YWluIGRldmlj ZXMgaXMgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiANCg0KDQogDQogDQpNdWxl eSBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAzLCAyMDA4ICAgICAgICAgICAgICAg ICBbUGFnZSA4XSANCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFBzZXVkb3dpcmUgKFBXKSBSZWR1 bmRhbmN5KSAgICAgICAgICBGZWJydWFyeSAyMDA4IA0KICAgIA0KDQozLjQuIFBXIHJlZHVuZGFu Y3kgYmV0d2VlbiBuLVBFcyAgDQoNCiAgIEZvbGxvd2luZyBmaWd1cmUgaWxsdXN0cmF0ZXMgdGhl IGFwcGxpY2F0aW9uIG9mIHVzZSBvZiBQVyByZWR1bmRhbmN5IA0KICAgZm9yIGR1YWwgaG9tZWQg Y29ubmVjdGl2aXR5IGJldHdlZW4gUEUgZGV2aWNlcyBpbiBhIHJpbmcgdG9wb2xvZ3kuIA0KDQog ICAgICAgICAgICAgKy0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rIA0KDQog ICAgICAgICAgICAgfCAgUEUxICB8PT09PT09PT09PT09PT09PT09PT09fCAgUEUyICB8PT09PS4u LiAgICAgIA0KDQogICAgICAgICAgICAgKy0tLS0tLS0rICAgIFBXIEdyb3VwIDEgICAgICAgKy0t LS0tLS0rICAgICANCg0KICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8fCANCg0KICAgVlBMUyBEb21haW4gQSB8fCAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8fCBWUExTIERvbWFpbiBCIA0KDQogICAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHx8ICAgICAgIA0KDQogICAgICAgICAgICAgKy0tLS0tLS0rICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0rICAgICAgICANCg0KICAgICAgICAgICAgIHwgIFBFMyAgfD09 PT09PT09PT09PT09PT09PT09PXwgIFBFNCAgfD09Li4uIA0KDQogICAgICAgICAgICAgKy0tLS0t LS0rICAgIFBXIEdyb3VwIDIgICAgICAgKy0tLS0tLS0rIA0KDQogICAgICAgICAgICAgICAgIEZp Z3VyZSA0ICAgUmVkdW5kYW5jeSBpbiBSaW5nIHRvcG9sb2d5ICAgICAgICAgICAgICAgIA0KDQog ICBJbiBGaWd1cmUgNCwgUEUxIGFuZCBQRTMgZnJvbSBWUExTIGRvbWFpbiBBIGFyZSBjb25uZWN0 ZWQgdG8gUEUyIGFuZCANCiAgIFBFNCBpbiBWUExTIGRvbWFpbiBCIHZpYSBQVyBncm91cCAxIGFu ZCBncm91cCAyLiBFYWNoIG9mIHRoZSBQRSBpbiANCiAgIHJlc3BlY3RpdmUgZG9tYWluIGlzIGNv bm5lY3RlZCB0byBlYWNoIG90aGVyIGFzIHdlbGwgdG8gZm9ybSB0aGUgcmluZyANCiAgIHRvcG9s b2d5LiBTdWNoIHNjZW5hcmlvcyBtYXkgYXJpc2UgaW4gaW50ZXItZG9tYWluIEgtVlBMUyBkZXBs b3ltZW50cyANCiAgIHdoZXJlIFJTVFAgb3Igb3RoZXIgbWVjaGFuaXNtcyBtYXkgYmUgdXNlZCB0 byBtYWludGFpbiBsb29wIGZyZWUgDQogICBjb25uZWN0aXZpdHkgb2YgUFcgZ3JvdXBzLiANCg0K ICAgICAgICAgICAgICAgIFJlZi5bNV0gb3V0bGluZXMgYWJvdXQgbXVsdGktZG9tYWluIFZQTFMg c2VydmljZSB3aXRob3V0IA0KICAgc3BlY2lmeWluZyBob3cgcmVkdW5kYW50IGJvcmRlciBQRXMg cGVyIGRvbWFpbiBwZXIgVlBMUyBpbnN0YW5jZSBjYW4gDQogICBiZSBzdXBwb3J0ZWQuIEluIHRo ZSBleGFtcGxlIGFib3ZlLCBQVyBncm91cDEgbWF5IGJlIGJsb2NrZWQgYXQgUEUxIA0KICAgYnkg UlNUUCBhbmQgaXQgaXMgZGVzaXJhYmxlIHRvIGJsb2NrIHRoZSBncm91cCBhdCBQRTIgYnkgdmly dHVlIG9mIA0KICAgZXhjaGFuZ2luZyB0aGUgUFcgcHJlZmVyZW50aWFsIHN0YXR1cyBhcyBTdGFu ZGJ5LiBIb3cgdGhlIFBXIGdyb3VwaW5nIA0KICAgc2hvdWxkIGJlIGRvbmUgaGVyZSBpcyBhZ2Fp biBkZXBsb3ltZW50IHNwZWNpZmljIGFuZCBpcyBvdXQgb2Ygc2NvcGUgDQogICBvZiB0aGUgc29s dXRpb24uIA0KDQozLjUuIFBXIHJlZHVuZGFuY3kgaW4gQnJpZGdlIE1vZHVsZSBNb2RlbCAgICAg ICANCg0KICAgIA0KDQogICAgDQoNCiAgICANCiANCiANCk11bGV5IGV0IGFsLiAgICAgICAgICAg IEV4cGlyZXMgQXVndXN0IDMsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDldIA0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgUHNldWRvd2lyZSAoUFcpIFJlZHVuZGFuY3kpICAgICAgICAgIEZl YnJ1YXJ5IDIwMDggDQogICAgDQoNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICBQ cm92aWRlciAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAuICAgQ29yZSAgICAgLiAgDQoNCiAgICAgICAgICAgICAgICAgICArLS0t LS0tKyAgICAuICAgICAgICAgICAgLiAgICArLS0tLS0tKyAgDQoNCiAgICAgICAgICAgICAgICAg ICB8IG4tUEUgfD09PT09PT09PT09PT09PT09PT09PT18IG4tUEUgfCAgDQoNCiAgICAgICAgUHJv dmlkZXIgICB8IChQKSAgfC0tLS0tLS0tLVwgICAgLy0tLS0tLS18IChQKSAgfCAgUHJvdmlkZXIg ICANCg0KICAgICAgICBBY2Nlc3MgICAgICstLS0tLS0rICAgIC5fICAgIFwgIC8gICAuICAgICst LS0tLS0rICBBY2Nlc3MgIA0KDQogICAgICAgIE5ldHdvcmsgICAgICAgICAgICAgICAgLiAgICAg IFwvICAgIC4gICAgICAgICAgICAgIE5ldHdvcmsgIA0KDQogICAgICAgICAgKDEpICAgICAgKy0t LS0tLSsgICAgLiAgICAgIC9cICAgIC4gICAgKy0tLS0tLSsgICAgICgyKSAgDQoNCiAgICAgICAg ICAgICAgICAgICB8IG4tUEUgfC0tLS0tLS0tLS0vICBcLS0tLS0tLS18IG4tUEUgfCAgDQoNCiAg ICAgICAgICAgICAgICAgICB8ICAoQikgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18IChCKSAgfF8g IA0KDQogICAgICAgICAgICAgICAgICAgKy0tLS0tLSsgICAgLiAgICAgICAgICAgIC4gICAgKy0t LS0tLSsgIA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLiAgICAgICAgICAgIC4g IA0KDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0gDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNSBC cmlkZ2UgTW9kdWxlIE1vZGVsIA0KDQogICBJbiBGaWd1cmUgNSwgdHdvIHByb3ZpZGVyIGFjY2Vz cyBuZXR3b3JrcywgZWFjaCBoYXZpbmcgdHdvIG4tUEVzLCANCiAgIHdoZXJlIHRoZSBuLVBFcyBh cmUgY29ubmVjdGVkIHZpYSBhIGZ1bGwgbWVzaCBvZiBQV3MgZm9yIGEgZ2l2ZW4gVlBMUyANCiAg IGluc3RhbmNlLiBBcyBzaG93biBpbiB0aGUgZmlndXJlLCBvbmx5IG9uZSBuLVBFIGluIGVhY2gg YWNjZXNzIA0KICAgbmV0d29yayBpcyBzZXJ2aW5nIGFzIGEgUHJpbWFyeSBQRSAoUCkgZm9yIHRo YXQgVlBMUyBpbnN0YW5jZSBhbmQgdGhlIA0KICAgb3RoZXIgbi1QRSBpcyBzZXJ2aW5nIGFzIHRo ZSBiYWNrdXAgUEUgKEIpLkluIHRoaXMgZmlndXJlLCBlYWNoIA0KICAgcHJpbWFyeSBQRSBoYXMg dHdvIGFjdGl2ZSBQV3Mgb3JpZ2luYXRpbmcgZnJvbSBpdC4gVGhlcmVmb3JlLCB3aGVuIGEgDQog ICBtdWx0aWNhc3QsIGJyb2FkY2FzdCwgYW5kIHVua25vd24gdW5pY2FzdCBmcmFtZSBhcnJpdmVz IGF0IHRoZSANCiAgIHByaW1hcnkgbi1QRSBmcm9tIHRoZSBhY2Nlc3MgbmV0d29yayBzaWRlLCB0 aGUgbi1QRSByZXBsaWNhdGVzIHRoZSANCiAgIGZyYW1lIG92ZXIgYm90aCBQV3MgaW4gdGhlIGNv cmUgZXZlbiB0aG91Z2ggaXQgb25seSBuZWVkcyB0byBzZW5kIHRoZSANCiAgIGZyYW1lcyBvdmVy IGEgc2luZ2xlIFBXIChzaG93biB3aXRoID09IGluIHRoZSBmaWd1cmUpIHRvIHRoZSBwcmltYXJ5 IA0KICAgbi1QRSBvbiB0aGUgb3RoZXIgc2lkZS4gVGhpcyBpcyBhbiB1bm5lY2Vzc2FyeSByZXBs aWNhdGlvbiBvZiB0aGUgDQogICBjdXN0b21lciBmcmFtZXMgdGhhdCBjb25zdW1lcyBjb3JlLW5l dHdvcmsgYmFuZHdpZHRoIChoYWxmIG9mIHRoZSANCiAgIGZyYW1lcyBnZXQgZGlzY2FyZGVkIGF0 IHRoZSByZWNlaXZpbmcgbi1QRSkuIFRoaXMgaXNzdWUgZ2V0cyANCiAgIGFnZ3JhdmF0ZWQgd2hl biB0aGVyZSBpcyB0aHJlZSBvciBtb3JlIG4tUEVzIHBlciBwcm92aWRlciwgYWNjZXNzIA0KICAg bmV0d29yay4gRm9yIGV4YW1wbGUgaWYgdGhlcmUgYXJlIHRocmVlIG4tUEVzIG9yIGZvdXIgbi1Q RXMgcGVyIA0KICAgYWNjZXNzIG5ldHdvcmssIHRoZW4gNjclIG9yIDc1JSBvZiBjb3JlLUJXIGZv ciBtdWx0aWNhc3QsIGJyb2FkY2FzdCANCiAgIGFuZCB1bmtub3duIHVuaWNhc3QgYXJlIHJlc3Bl Y3RpdmVseSB3YXN0ZWQuICAgDQoNCg0KIA0KIA0KTXVsZXkgZXQgYWwuICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMywgMjAwOCAgICAgICAgICAgICAgICBbUGFnZSAxMF0gDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICBQc2V1ZG93aXJlIChQVykgUmVkdW5kYW5jeSkgICAgICAgICAgRmVicnVh cnkgMjAwOCANCiAgICANCg0KICAgICAgICAgICAgICAgICAgICAgIEluIHRoaXMgc2NlbmFyaW8s IFN0YW5kYnkgUFcgc2lnbmFsaW5nIGRlZmluZWQgaW4gDQogICBbN10gY2FuIGJlIHVzZWQgYW1v bmcgbi1QRXMgdGhhdCBjYW4gZGlzc2VtaW5hdGUgdGhlIHN0YXR1cyBvZiBQV3MgDQogICAoYWN0 aXZlIG9yIGJsb2NrZWQpIGFtb25nIHRoZW1zZWx2ZXMgYW5kIGZ1cnRoZXJtb3JlIHRvIGhhdmUg aXQgdGllZCANCiAgIHVwIHdpdGggdGhlIHJlZHVuZGFuY3kgbWVjaGFuaXNtIHN1Y2ggdGhhdCBw ZXIgVlBMUyBpbnN0YW5jZSB0aGUgDQogICBzdGF0dXMgb2YgYWN0aXZlL2JhY2t1cCBuLVBFIGdl dHMgcmVmbGVjdGVkIG9uIHRoZSBjb3JyZXNwb25kaW5nIFBXcyANCiAgIGVtYW5hdGluZyBmcm9t IHRoYXQgbi1QRS4gDQoNCjQuIEdlbmVyaWMgUFcgcmVkdW5kYW5jeSByZXF1aXJlbWVudHMgDQoN CjQuMS4gUHJvdGVjdGlvbiBzd2l0Y2hpbmcgcmVxdWlyZW1lbnRzIA0KDQogICBvICBQcm90ZWN0 aW9uIGFyY2hpdGVjdHVyZSBzdWNoIGFzIE46MSwxOjEgb3IgMSsxIGNhbiBiZSB1c2VkLiBOOjEg DQogICAgICBwcm90ZWN0aW9uIGNhc2UgaXMgc29tZXdoYXQgaW5lZmZpY2llbnQgaW4gdGVybXMg b2YgY2FwYWNpdHkgDQogICAgICBjb25zdW1wdGlvbiBoZW5jZSBpbXBsZW1lbnRhdGlvbnMgU0hP VUxEIHN1cHBvcnQgdGhpcyBtZXRob2QgDQogICAgICB3aGlsZSAgMToxIGJlaW5nIHN1YnNldCBh bmQgZWZmaWNpZW50IE1VU1QgYmUgc3VwcG9ydGVkLiAxKzEgDQogICAgICBwcm90ZWN0aW9uIGFy Y2hpdGVjdHVyZSBjYW4gYmUgc3VwcG9ydGVkIGJ1dCBpcyBsZWZ0IGZvciBmdXJ0aGVyIA0KICAg ICAgc3R1ZHkuIA0KDQogICBvICBOb24tcmV2ZXJ0aXZlIG1vZGUgTVVTVCBiZSBzdXBwb3J0ZWQs IHdoaWxlIHJldmVydGl2ZSBtb2RlIGlzIGFuIA0KICAgICAgb3B0aW9uYWwgb25lLiAgDQoNCiAg IG8gIFByb3RlY3Rpb24gc3dpdGNob3ZlciBjYW4gYmUgb3BlcmF0b3IgZHJpdmVuIGxpa2UgTWFu dWFsIA0KICAgICAgbG9ja291dC9mb3JjZSBzd2l0Y2hvdmVyIG9yIGR1ZSB0byBzaWduYWwgZmFp bHVyZS4gQm90aCBtZXRob2RzIA0KICAgICAgTVVTVCBiZSBzdXBwb3J0ZWQgYW5kIHNpZ25hbCBm YWlsdXJlIE1VU1QgYmUgZ2l2ZW4gaGlnaGVyIA0KICAgICAgcHJpb3JpdHkgdGhhbiBhbnkgbG9j YWwgb3IgZmFyIGVuZCByZXF1ZXN0LiANCg0KNC4yLiAgT3BlcmF0aW9uYWwgcmVxdWlyZW1lbnRz IA0KDQogICBvICAoVC0pUEVzIGludm9sdmVkIGluIHByb3RlY3RpbmcgYSBQVyBTSE9VTEQgYXV0 b21hdGljYWxseSBkaXNjb3ZlciANCiAgICAgIGFuZCBhdHRlbXB0IHRvIHJlc29sdmUgaW5jb25z aXN0ZW5jaWVzIGluIHRoZSBjb25maWd1cmF0aW9uIG9mIA0KICAgICAgcHJpbWFyeS9zZWNvbmRh cnkgUFcuICANCg0KICAgbyAgKFQtKVBFcyBpbnZvbHZlZCBpbiBwcm90ZWN0aW5nIGEgUFcgU0hP VUxEIGF1dG9tYXRpY2FsbHkgZGlzY292ZXIgDQogICAgICBhbmQgYXR0ZW1wdCB0byByZXNvbHZl IGluY29uc2lzdGVuY2llcyBpbiB0aGUgY29uZmlndXJhdGlvbiBvZiANCiAgICAgIHJldmVydGl2 ZS9ub24tcmV2ZXJ0aXZlIHByb3RlY3Rpb24gc3dpdGNoaW5nIG1vZGUuICAgDQoNCiAgIG8gIChU LSlQRXMgdGhhdCBkbyBub3QgYXV0b21hdGljYWxseSBkaXNjb3ZlciBvciByZXNvbHZlIA0KICAg ICAgaW5jb25zaXN0ZW5jaWVzIGluIHRoZSBjb25maWd1cmF0aW9uIG9mIHByaW1hcnkvc2Vjb25k YXJ5LCANCiAgICAgIHJldmVydGl2ZS9ub24tcmV2ZXJ0aXZlLCBvciBvdGhlciBwYXJhbWV0ZXJz IE1VU1QgZ2VuZXJhdGUgYW4gDQogICAgICBhbGFybSB1cG9uIGRldGVjdGlvbiBvZiBhbiBpbmNv bnNpc3RlbnQgY29uZmlndXJhdGlvbi4gIA0KDQogICBvICAoVC0pUEVzIGludm9sdmVkIHdpdGgg cHJvdGVjdGlvbiBzd2l0Y2hpbmcgTVVTVCBzdXBwb3J0IHRoZSANCiAgICAgIGNvbmZpZ3VyYXRp b24gb2YgcmV2ZXJ0aXZlIG9yIG5vbi1yZXZlcnRpdmUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgDQog ICAgICBtb2RlLiANCg0KICAgbyAgKFQtKVBFcyBpbnZvbHZlZCB3aXRoIHByb3RlY3Rpb24gc3dp dGNoaW5nIFNIT1VMRCBzdXBwb3J0IHRoZSANCiAgICAgIGxvY2FsIGludm9jYXRpb24gb2YgcHJv dGVjdGlvbiBzd2l0Y2hpbmcuIA0KIA0KIA0KTXVsZXkgZXQgYWwuICAgICAgICAgICAgRXhwaXJl cyBBdWd1c3QgMywgMjAwOCAgICAgICAgICAgICAgICBbUGFnZSAxMV0gDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICBQc2V1ZG93aXJlIChQVykgUmVkdW5kYW5jeSkgICAgICAgICAgRmVicnVhcnkg MjAwOCANCiAgICANCg0KICAgbyAgKFQtKVBFcyBpbnZvbHZlZCB3aXRoIHByb3RlY3Rpb24gc3dp dGNoaW5nIFNIT1VMRCBzdXBwb3J0IHRoZSANCiAgICAgIGxvY2FsIGludm9jYXRpb24gb2YgYSBs b2Nrb3V0IG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nLiAgIA0KDQogICBvICBJbiBzdGFuZGJ5IHN0 YXR1cyBQVyBjYW4gc3RpbGwgcmVjZWl2ZSBwYWNrZXRzIGluIG9yZGVyIHRvIGF2b2lkIA0KICAg ICAgYmxhY2sgaG9saW5nIG9mIGluLWZsaWdodCBwYWNrZXRzIGR1cmluZyBzd2l0Y2hvdmVyLiBI b3dldmVyIGluIA0KICAgICAgY2FzZSBvZiB1c2Ugb2YgVlBMUyBhcHBsaWNhdGlvbiBwYWNrZXRz IGFyZSBkcm9wcGVkIGluIHN0YW5kYnkgDQogICAgICBzdGF0dXMgZXhjZXB0IGZvciB0aGUgT0FN IHBhY2tldHMuICAgDQoNCiAgICANCg0KNS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIA0KDQog ICBUaGlzIGRvY3VtZW50IGV4cGVjdHMgZXh0ZW5zaW9ucyB0byBMRFAgdGhhdCBhcmUgbmVlZGVk IGZvciANCiAgIHByb3RlY3RpbmcgcHNldWRvLXdpcmVzLiBJdCB3aWxsIGhhdmUgdGhlIHNhbWUg c2VjdXJpdHkgcHJvcGVydGllcyBhcyANCiAgIGluIExEUCBbNF0gYW5kIHRoZSBQVyBjb250cm9s IHByb3RvY29sIFsyXS4gDQoNCjYuIEFja25vd2xlZGdtZW50cyAgDQoNCiAgIFRoZSBhdXRob3Jz IHdvdWxkIGxpa2UgdG8gdGhhbmsgVmFjaCBLb21wZWxsYSwgS2VuZGFsbCBIYXJ2ZXksIA0KICAg VGliZXJpdSBHcmlnb3JpdSwgTmVpbCBIYXJ0LCBLYWphbCBTYWhhLCBGbG9yaW4gQmFsdXMgYW5k IFBoaWxpcHBlIA0KICAgTmlnZXIgZm9yIHRoZWlyIHZhbHVhYmxlIGNvbW1lbnRzIGFuZCBzdWdn ZXN0aW9ucy4gDQoNCjcuIElBTkEgY29uc2lkZXJhdGlvbnMgDQoNCiAgIFRoaXMgZG9jdW1lbnQg aGFzIG5vIGFjdGlvbnMgZm9yIElBTkEuIA0KDQo4LiBSZWZlcmVuY2VzICANCg0KOC4xLiBOb3Jt YXRpdmUgUmVmZXJlbmNlcyANCg0KICAgWzFdICAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9y IHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIA0KICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwg QkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4gDQoNCiAgIFsyXSAgIE1hcnRpbmksIEwuLCBl dCBhbC4sICJQc2V1ZG93aXJlIFNldHVwIGFuZCBNYWludGVuYW5jZSB1c2luZyANCiAgICAgICAg IExEUCIsIFJGQyA0NDQ3LCBBcHJpbCAyMDA2LiAgDQoNCiAgIFszXSAgIEJyeWFudCwgUy4sIGV0 IGFsLiwgIiBQc2V1ZG8gV2lyZSBFbXVsYXRpb24gRWRnZS10by1FZGdlIA0KICAgICAgICAgKFBX RTMpIEFyY2hpdGVjdHVyZSIsIE1hcmNoIDIwMDUgDQoNCiAgIFs0XSAgIEFuZGVyc3NvbiwgTC4s IE1pbmVpLCBJLiwgYW5kIEIuIFRob21hcywgIkxEUCBTcGVjaWZpY2F0aW9uIiwgDQogICAgICAg ICBSRkMgNTAzNiwgSmFudWFyeSAyMDAxIA0KDQogICBbNV0gICBLb21wZWxsYSxWLiwgTGFzc2Vy cnJlLCBNLiAsIGV0IGFsLiwgIlZpcnR1YWwgUHJpdmF0ZSBMQU4gDQogICAgICAgICBTZXJ2aWNl IChWUExTKSBVc2luZyBMRFAgU2lnbmFsbGluZyIsIFJGQyA0NzYyLCBKYW51YXJ5IDIwMDcgDQoN Cg0KDQogDQogDQpNdWxleSBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAzLCAyMDA4 ICAgICAgICAgICAgICAgIFtQYWdlIDEyXSANCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFBzZXVk b3dpcmUgKFBXKSBSZWR1bmRhbmN5KSAgICAgICAgICBGZWJydWFyeSAyMDA4IA0KICAgIA0KDQo4 LjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgDQoNCiAgIFs2XSAgIE1hcnRpbmksIEwuLCBldCBh bC4sICJTZWdtZW50ZWQgUHNldWRvIFdpcmUiLCBkcmFmdC1pZXRmLXB3ZTMtDQogICAgICAgICBz ZWdtZW50ZWQtcHctMDcudHh0LCBGZWJydWFyeSAyMDA4LiANCg0KICAgWzddICAgTXVsZXksIFAu IGV0IGFsLiwgIlByZWZlcmVudGlhbCBmb3J3YXJkaW5nIHN0YXR1cyBiaXQiLCBkcmFmdC0NCiAg ICAgICAgIGlldGYtcHdlMy1yZWR1bmRhbmN5LWJpdC0wMC50eHQsIEF1Z3VzdCAyMDA4LiANCg0K ICAgWzhdICAgSUVFRSBTdGQuIDgwMi4xRC0yMDAzLU1lZGlhIEFjY2VzcyBDb250cm9sIChNQUMp IEJyaWRnZXMuIA0KDQogICAgDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogDQogDQpNdWxleSBldCBhbC4gICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAzLCAyMDA4ICAgICAgICAgICAgICAgIFtQYWdlIDEzXSAN CgwNCkludGVybmV0LURyYWZ0ICAgICAgIFBzZXVkb3dpcmUgKFBXKSBSZWR1bmRhbmN5KSAgICAg ICAgICBGZWJydWFyeSAyMDA4IA0KICAgIA0KDQpBdXRob3IncyBBZGRyZXNzZXMgDQoNCiAgIFBy YXZlZW4gTXVsZXkgDQogICBBbGNhdGVsIA0KICAgNzAxIEUuIE1pZGRsZWZpbGVkIFJvYWQgIA0K ICAgTW91bnRhaW4gVmlldywgQ0EsIFVTQSAgDQogICBFbWFpbDogUHJhdmVlbi5tdWxleUBhbGNh dGVsLmNvbSANCiAgICANCiAgIE11c3RhcGhhIEFpc3Nhb3VpICAgDQogICBBbGNhdGVsICAgDQog ICA2MDAgTWFyY2ggUmQgICANCiAgIEthbmF0YSwgT04sIENhbmFkYSBLMksgMkU2ICAgDQogICBF bWFpbDogbXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC5jb20gDQogICAgDQogICBNYXR0aGV3IEJv Y2NpIA0KICAgQWxjYXRlbCANCiAgIFZveWFnZXIgUGxhY2UsIFNob3BwZW5oYW5nZXJzIFJkIA0K ICAgTWFpZGVuaGVhZCwgQmVya3MsIFVLIFNMNiAyUEogDQogICBFbWFpbDogbWF0dGhldy5ib2Nj aUBhbGNhdGVsLmNvLnVrIA0KICAgIA0KICAgUHJhbmphbCBLdW1hciBEdXR0YSAgDQogICBBbGNh dGVsLUx1Y2VudCAgIA0KICAgRW1haWw6IHBkdXR0YUBhbGNhdGVsLWx1Y2VudC5jb20gIA0KICAg ICAgICANCiAgIE1hcmMgTGFzc2VycmUgIA0KICAgQWxjYXRlbC1MdWNlbnQgIA0KICAgRW1haWw6 IG1sYXNzZXJyZUBhbGNhdGVsLWx1Y2VudC5jb20gDQogICAgDQogICBKb25hdGhhbiBOZXd0b24g DQogICBDYWJsZSAmIFdpcmVsZXNzIA0KICAgRW1haWw6IEpvbmF0aGFuLk5ld3RvbkBjd21zZy5j d3BsYy5jb20gDQogICAgDQogICBPbGVuIFN0b2tlcyAgDQogICBFeHRyZW1lIE5ldHdvcmtzICAN CiAgIEVtYWlsOiBvc3Rva2VzQGV4dHJlbWVuZXR3b3Jrcy5jb20gICANCiAgICAgICAgDQogICBI YW1pZCBPdWxkLUJyYWhpbSAgIA0KICAgTm9ydGVsICANCiAgIEVtYWlsOiBoYnJhaGltQG5vcnRl bC5jb20gDQogICAgDQogICBEYXZlIE1jRHlzYW4gDQogICBWZXJpem9uIA0KICAgRW1haWw6IGRh dmUubWNkeXNhbkB2ZXJpem9uLmNvbSANCiAgICANCiAgIEdpbGVzIEhlcm9uIA0KICAgQlQgDQog ICBFbWFpbDogZ2lsZXMuaGVyb25AZ21haWwuY29tIA0KIA0KIA0KTXVsZXkgZXQgYWwuICAgICAg ICAgICAgRXhwaXJlcyBBdWd1c3QgMywgMjAwOCAgICAgICAgICAgICAgICBbUGFnZSAxNF0gDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICBQc2V1ZG93aXJlIChQVykgUmVkdW5kYW5jeSkgICAgICAg ICAgRmVicnVhcnkgMjAwOCANCiAgICANCg0KICAgIA0KICAgVGhvbWFzIE5hZGVhdSANCiAgIEJU IA0KICAgRW1haWw6IHRuYWRlYXVAbHVjaWR2aXNpb24uY29tIA0KICAgIA0KICAgIA0KSW50ZWxs ZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudCANCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRp b24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkgDQogICBJbnRlbGxlY3R1 YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQg DQogICB0byBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hu b2xvZ3kgZGVzY3JpYmVkIA0KICAgaW4gdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdo aWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggDQogICByaWdodHMgbWlnaHQgb3IgbWlnaHQgbm90 IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgDQogICBpdCBoYXMgbWFk ZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIA0K ICAgSW5mb3JtYXRpb24gb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBp biBSRkMgDQogICBkb2N1bWVudHMgY2FuIGJlIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LiAN Cg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFy aWF0IGFuZCBhbnkgDQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxh YmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuIA0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdl bmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIA0KICAgb2Ygc3VjaCBwcm9w cmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgDQogICBzcGVj aWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9z aXRvcnkgDQogICBhdCBodHRwOi8vd3d3LmlldGYub3JnL2lwci4gDQoNCiAgIFRoZSBJRVRGIGlu dml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkg DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVy IHByb3ByaWV0YXJ5IA0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBt YXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50IA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBh ZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdCANCiAgIGlldGYtaXByQGlldGYu b3JnLiANCg0KRGlzY2xhaW1lciBvZiBWYWxpZGl0eSANCg0KICAgVGhpcyBkb2N1bWVudCBhbmQg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIA0KICAgYW4g IkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NI RSANCiAgIFJFUFJFU0VOVFMgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJO RVQgU09DSUVUWSwgVEhFIA0KICAgSUVURiBUUlVTVCBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVS SU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIA0KICAgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJ TVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSANCiAgIFdBUlJBTlRZIFRI QVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIA0K ICAgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElU WSBPUiBGSVRORVNTIA0KICAgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiANCg0KQ29weXJpZ2h0 IFN0YXRlbWVudCANCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwOCkuIA0K DQoNCg0KIA0KIA0KTXVsZXkgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMywgMjAw OCAgICAgICAgICAgICAgICBbUGFnZSAxNV0gDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBQc2V1 ZG93aXJlIChQVykgUmVkdW5kYW5jeSkgICAgICAgICAgRmVicnVhcnkgMjAwOCANCiAgICANCg0K ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCBy ZXN0cmljdGlvbnMgDQogICBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBm b3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyANCiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLiAN CiANCg0KQWNrbm93bGVkZ21lbnQgDQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1 bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUgDQogICBJbnRlcm5ldCBTb2NpZXR5 LiANCg0KICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KIA0KIA0KTXVsZXkgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMywgMjAwOCAgICAgICAgICAgICAgICBbUGFnZSAxNl0gDQoMDQo= ------_=_NextPart_001_01C87F0B.40D14922 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C87F0B.40D14922-- From pwe3-bounces@ietf.org Wed Mar 12 08:17:46 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ADA928C837; Wed, 12 Mar 2008 08:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.075 X-Spam-Level: X-Spam-Status: No, score=-101.075 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 goNBZWNyGypZ; Wed, 12 Mar 2008 08:17:45 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3868D3A6E3D; Wed, 12 Mar 2008 08:16:47 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B08028C718 for ; Wed, 12 Mar 2008 08:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 nZnEIBL2zmbn for ; Wed, 12 Mar 2008 08:16:41 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by core3.amsl.com (Postfix) with ESMTP id 5564528C75C for ; Wed, 12 Mar 2008 08:16:36 -0700 (PDT) Received: from exrad3.ad.rad.co.il ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 12 Mar 2008 17:14:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 17:14:15 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D06BE6293@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: additional text for the TDM control protocol extensions draft Thread-Index: AciEU7yD0Zuh/eM8QSSntQojwPg+tw== From: "Yaakov Stein" To: Cc: Mark Townsley Subject: [PWE3] additional text for the TDM control protocol extensions draft X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Hi all The TDM control protocol extensions draft draft-ietf-pwe3-tdm-control-protocol-extensi-06.txt was sent to the IESG for processing. It requires several IANA actions, and we have been informed that one of which will require some additional text to be added to the draft. The problem is with the TDMoIP AAL2 Options interface parameter. The base length of this field is 8 bytes, but there is an optional extension that is usually just a byte or two in length, but in unusual cases could theoretically be very lengthy. Because of assumptions concerning the amount of state memory that needs to be set aside for LDP implementations, there is concern about allowing allocations of TLVs which could potentially be lengthy. We have agreed to add an informative note clarifying that in cases where this parameter IS indeed lengthy, there would be a limitation on the number of such PWs a PE needs to support. In particular, we intend adding the following text to section 3.5 of the draft before its continued processing by the IESG : The length of basic TDMoIP AAL2 Options interface parameter is 8 bytes, and when the optional CID mapping bases field is used there is one additional byte for each trunk transported. Thus if 4 trunks are being supported, this message occupies 12 bytes. Since there can be no more than 248 CIDs in a given PW, this can never exceed 256 (when precisely one timeslot is used per trunk), but for fully populated E1s it is less than 17 bytes, and for full T1s it can not exceed 19 bytes. A single PE is not required to support more than 10 AAL2 PWs (i.e., up to 2480 individual channels, which is more than carried by a fully populated STM1). Thus the typical memory required to store the AAL2 mapping information is not more than 200 bytes per PE, although for worst case scenarios may reach 2560 bytes. Y(J)S _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Mar 13 08:04:31 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8643D28C14E; Thu, 13 Mar 2008 08:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.652 X-Spam-Level: X-Spam-Status: No, score=-100.652 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 iEl9KAEhdDUk; Thu, 13 Mar 2008 08:04:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D17C3A6D03; Thu, 13 Mar 2008 08:04:27 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B753A3A69D5 for ; Thu, 13 Mar 2008 08:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 3KE-biOduYYa for ; Thu, 13 Mar 2008 08:04:24 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id ACC773A6AD5 for ; Thu, 13 Mar 2008 08:04:23 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 13 Mar 2008 17:35:49 +0200 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Mar 2008 17:02:05 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.210) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id 8.1.240.5; Thu, 13 Mar 2008 17:02:04 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Mar 2008 17:00:15 +0200 Message-ID: <64122293A6365B4A9794DC5636F9ACFD02B62FC0@ilptex01.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: A question regarding draft-mohan-pwe3-mpls-eth-oam-iwk-00 Thread-index: AciFGvGzL5xHTBsDQ1aqxtF1fOIaYg== From: Alexander Vainshtein To: X-OriginalArrivalTime: 13 Mar 2008 15:02:05.0260 (UTC) FILETIME=[336000C0:01C8851B] Cc: pwe3@ietf.org Subject: [PWE3] A question regarding draft-mohan-pwe3-mpls-eth-oam-iwk-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0311085318==" Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org --===============0311085318== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8851B.32FA116B" ------_=_NextPart_001_01C8851B.32FA116B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dinesh, Section 5.1. of the draft describes several options for handing PW forward defect. I have two questions regarding this section: 1. All the options listed in the text require that a (down) MEP associated with the AC of the PW in question has been configured. Any ideas what should happen if there is no MEP there? 2. MEF has ratified the E-LMI IA as its MEF 16 spec (see http://metroethernetforum.org/MSWord_Documents/MEF16.doc ). This mechanisms seems similar to FR LMI that has been used to convey the FR PW defects in draft-ietf-pwe3-oam-msg-map-06.txt. Are there any reasons not to use E-LMI in the same way, at least as one of the options? Regards, Sasha ------_=_NextPart_001_01C8851B.32FA116B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dinesh,
Section 5.1. of the=20 draft describes several options for handing PW forward=20 defect.
I have = two questions=20 regarding this section:
  1. All = the options=20 listed in the text require that a (down) MEP associated with the AC of = the PW=20 in question has been configured. Any ideas what should happen if there = is no=20 MEP there?
  2. MEF has=20 ratified the E-LMI IA  as its MEF 16 spec (see http://metroethernetforum.org/MSWord_Documents/MEF16.doc<= /A>). This mechanisms seems similar to FR LMI that has been used = to convey=20 the FR PW defects in draft-ietf-pwe3-oam-msg-map-06.txt. Are = there any=20 reasons not to use E-LMI in the same way, at least as one of the=20 options?
Regards,
       &nbs= p;   =20 Sasha
------_=_NextPart_001_01C8851B.32FA116B-- --===============0311085318== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --===============0311085318==-- From pwe3-bounces@ietf.org Mon Mar 17 02:21:49 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82FE28C261; Mon, 17 Mar 2008 02:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.826 X-Spam-Level: X-Spam-Status: No, score=-96.826 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, J_CHICKENPOX_23=0.6, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 IiA66QpkQ0kv; Mon, 17 Mar 2008 02:21:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9893A6CD3; Mon, 17 Mar 2008 02:21:37 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F01B3A6B46 for ; Mon, 17 Mar 2008 02:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 tsU9Xa7e9ppT for ; Mon, 17 Mar 2008 02:21:25 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id AE4633A6D09 for ; Mon, 17 Mar 2008 02:21:14 -0700 (PDT) Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m2H921QR019749 for ; Mon, 17 Mar 2008 10:02:01 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 17 Mar 2008 10:18:49 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Mar 2008 10:18:49 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A01A0416C@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Philadelphia minutes Thread-index: AciDhhVlnb53jxM0QZydvfOjCr4B9wCdNvBg From: "BOCCI Matthew" To: X-OriginalArrivalTime: 17 Mar 2008 09:18:49.0752 (UTC) FILETIME=[E925E180:01C8880F] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [PWE3] Philadelphia minutes X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2116518762==" Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============2116518762== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8880F.E909CAB6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8880F.E909CAB6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Please find attached the draft minutes from Philadelphia. Please let me know if you have any comments. Best regards, Matthew > Monday, March 10th, 2008 - 15:20 - 17:20 > ---------------------------------------- > CHAIRS: Danny McPherson & Stewart Bryant > SCRIBE: Matthew Bocci >=20 > ------------------------------ > WG Status and Update - Chairs > ------------------------------ >=20 > Agenda agreed. > 20 RFCs to date > 3 held up > MIBs pushed through to IESG. > MS-PW requirements - many security requirements on this. Trying to > resolve these. There is a backlog behind these. > ATM MIB a little late - updated now > Work in progress - many held up due to MS-PW reqs. > Redundancy - now a WG item. No negatives on the list. A few comments > on list about couple mechanisms together. > Need some work on other MIBs. > New charter being worked on > OSPF routing draft - needs to coordinate with the OSPF. Chairs will > check with ADs that this is OK to take on. >=20 > ---------------------------------------------------------------------- > PW Redundancy Update - Praveen Muley > (Praveen.muley@alcatel-lucent.com) > http://tools.ietf.org/wg/pwe3/draft-ietf-pwe3-redundancy-bit/ > draft-ietf-pwe3-redundancy-00.txt (posted to list) > ---------------------------------------------------------------------- >=20 > Gives an update on the drafts. Both adopted as WG docs. > Major addition is revertive behaviour. > Framework and Requirements: > - added new co-authors > - added new definitions and terminology > - aligned text to be more to FR like > - added generic PW requirements >=20 > Shows new terminology. > Generic PW redundancy requirements - 1:1 is mandatory, N:1 optional > 1+1 is left for further study. > Non-revertive mandatory, revertive optional. > Added operational requirements. >=20 > Preferential forwarding status bit draft: > - updated scope of protection capabilities achieved > - - revertive/non-revertive behaviour > - Added appendix >=20 >=20 > Next steps=20 > - manual lockout case > - more feedback from WG requested >=20 > Danny: has evolved and progressed and fine to go forward > ??: ITU-T have defined some linear protection. Better to align with > ITU-T. > Dave McDyson - I agree. Important clients are TDM etc that have their > own native protection schemes. Framework would be a good place to map > native service terminology and make appropriate references. >=20 > ------------------------------------------------------------------- > MPLS & Ethernet OAM Interworking - Dinesh Mohan (mohand@nortel.com) > http://tools.ietf.org/id/draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt > ------------------------------------------------------------------- > Presented by Nabil Bitar. >=20 > Current PWE3 OAM message mapping does not address interworking with > Ethernet OAM. > Since then, good progress in Ethernet OAM space.=20 > This draft tries to complement the mapping draft with interworking > with PWs. > Shows reference model. > Consistent fwd/reverse defects with message mapping draft > Explains PW and AC defect detection options, and the mapping of > reverse and forward defects between the Ethernet AC and the PW >=20 > Next steps:=20 > Could merge with oam-msg-map or pursue as a separate draft. >=20 > Yaakov Stein - this is important work. Have you also looked into .3ah? > We need this covered too. > Nabil: I thought we did, because we cover link level defects. We need > to go back and make sure this is covered. > Ali Sajassi: This is a very good comment. Counts for ELMI too in MEF. > Luca Martini: I have asked for this years ago, and chairs did not want > to put into. I am in favour of putting this into message mapping. > Stewart - don't remember, but msg-map is quite mature > Luca Martini - this will generate more interest again and we can > progress this. > Stewart - Monique is the editor and she just refreshed it. It would be > good to review msg-map, and progress Ethernet separately as some more > material to add. > Yaakov Stein - agrees should be separate, and not hold up message map. > Danny: is there consistent terminology with OAM and redundancy drafts? > Nabil: The mapping draft is most advanced, and common authors with > redundancy, so hope they are consistent, but need to check. >=20 > Stewart: if existing OAM message mapping draft is nearly done, then > keep separate so as not to hold up. >=20 > Luca Martini: what will the IESG say without the lack of Ethernet? > Stewart: put in informative reference to Ethernet doc. Co-authers need > to add informative reference, and then we will last call it. > George Swallow: The way the industry is going, the Ethernet is the > most important part. >=20 > ---------------------------------------------------------------------- > ------- > LDP AII Reachability - Frederick Jounay > (frederic.jounay@orange-ftgroup.com) > http://tools.ietf.org/id/draft-delord-jounay-pwe3-ldp-aii-reachability > -00.txt > ---------------------------------------------------------------------- > ------- >=20 > First version of the draft. >=20 > Explains rationale. > Procedure to populate AII routing tables in first hop S-PE via LDP > Intended to complement IGP/BGP mechanisms > Problem statement: > Typical to access networks. No IGP or BGP - p2p physical connectivity > But run LDP for PW setup > IP and PW addressing separate >=20 > Does NOT replace routing protocols > Advertise only locally attached AII >=20 > Explains proposed mechanism >=20 > Next steps: > - feedback from WG > - add some extra scenarios (dual homing) > - extend to AGI as well? >=20 >=20 > Luca Martini: What do you mean by extend to AII? > Fred: Just mean also use for VPN provisioning using LDP > Luca Martini: Just haven't found a good application for the AGI in > this context, but would like to know if you have one. > Fred: Network autodiscovery populates on S-PE/T-PE, but VPN > autodiscovery must only be at the end point > Hamid Ould-Brahim: on your 1st slide, what do you mean by interwork > with other auto-discovery mechanisms? > Fred: the S-PE can relay this info based on BGP or IGP > Luca Martini: confusing term is auto-discovery. It should be over > routing protocols. >=20 > Stewart: Who is interested? Lots > Stewart: Who thinks this is a good starting point? Quite a few >=20 >=20 > ---------------------------------------------------------------------- > ----- > Conversation Hashing for Pseudowires - Vach Kompella > (vach.kompella@alcatel-lucent.com) > http://tools.ietf.org/id/draft-vkompella-pwe3-hash-label-00.txt > ---------------------------------------------------------------------- > ----- >=20 > Discussed a long time ago, but no demand at that time. Then Stewart > brought fat PW draft, so I wanted to add this to the pile. >=20 > A PW can carry many flows, and do not want PW to follow one path if > the PW has many flows that can follow different path e.g if PSN has > ECMP or LAG etc > Explains PW hashing fields > Could use hack such as looking at 1stt nibble, but complex and only > works if it is a 4/6 for IP. > Can we do something intelligent with the label stack? >=20 > Shows an example. >=20 > Solution proposes that 2 ends of PW exchange a range of has labels > that can be used by ingress side to hash traffic and pick a next hop > for trhe PSN. > Packet: tunnel, hash, PW label, payload >=20 > At LSR, LSP swaps on tunnel label.=20 >=20 > At egress, tunnel popped, hash is popped, and then you proceed based > on PW label. >=20 > Benefits include the fact that ingress holds one set of labels per > peer. Egress distributes one set of labels. Extensible to PSNs and to > BGP VPNs.=20 > Hasahable info is stable per flow, uses MPLS methods, requires no > changes to the CE, minimises the labels allocated and programmed per > node. > Acknowledges that some P routers don't hash this way (order of > labels), would like to understand if we should... >=20 > Shows some considerations on extending to PSNs.=20 > Ingress PSN- hash label at the top of the stack. > Questions - where should we put hash label? I think it should be > before the PW label to leave PW context processing to the end.=20 > How does this work with existing implementations? > Is this a new FEC? Or just a capabilities exchange? > Diversity for BGP label exchanges. > Should this be done in MPLS WG? > Could this be used to explore PW paths like LSP-ping multi-path? >=20 > Danny: please address these questions first, then we will go to > regular questions >=20 > Yaakov Stein: yes, place to put it is between PW label and tunnel. How > does this work for LSPs. > Vach: For PW, 1stst guy gets a packet with n different hash labels, to > choose n different next hops.=20 > Discussion taken off line > Rahul : not sure if this applies to IP VPNs because IP header > involved. PSNs could be an issue due to application level entropy... > Kireeti Kompella: good stuff here. There are a lot of things you have > not done quite perfectly yet. Happy to help. In picture, how do you > get a good hash if you have 20 bits of option and only using 3 bits? I > think you put labels in wring place - talk about off line - but do > agree we need to extend to IP VPNs and PSNs. > Stewart - include me in this. > Kireeti Kompella - I agree bottom is the right place. Would like to > take out of PWE3 for now, and talk among all the interested people. > Then we can figure out how to proceed. > Danny: agree > Don O'Connor: is this only for best effort? > Vach: this is not developed well enough for multiple levels of service > Don O'Connor: should this be in the charter?=20 > Vach: Could use diffserv TE and use different hash label > Stewart: Not clear that you need to know this > Don O'Connor- if you want to groom traffic by traffic class in an S-PE > this should be allowed > Ali Sajassi: have you considered impact on native and PW OAM? > Vach: No, not yet > Ali Sajassi: It has impacts and needs to be considered. If you exclude > OAM for the time being, why not assign multiple PW labels? > Vach: Service Providers have large numbers of PWs. That would not > scale. Amount of churn on every failure would be too high.=20 > Ali Sajassi: need to address OAM > George Swallow: only time I looked into what labels are hashed on, > everyone hashed on bottom label. Could do this survey again. If this a > general mechanism, should not be in MPLS. I would like to be on this > mailing list. > Stewart: issue that if we do this in MPLS, not clear that the > signalling for PS will work properly. > Kireeti Kompella: need to do something for underlying tunnels, and > make some generalisation about load balancing. We can then farm out > the signalling to individual groups. Framework in MPLS. > Stewart: Agrees to that. > Vach: requirements come from providers, and they have lots of > differences, but there is also differences on the implementation side > so would like to not just give to a set of providers. > Stewart: My draft was with DT because it is a real SP problem. > Mark Townsley: No problem in defining this in MPLS, but pressing > problem is here. Does not seem all that pressing for the IP case. > Dave Allan: Would echo Mark's comments - for something that can hash > IP now, too much complexity. Also need to ensure OAM flows fate share > with combination of PW and hash label. > Luca Martini: Comment on both drafts. Does not solve a generic > problem. Only works if you can identify a flow to has on the input. > What causes such a large flow? And IPSec flow from a bank? This only > works if you can identify the flows on ingress. > Shane Amante: agree this belongs in MPLS. Mark and Rahul had some > discussions about IPVPN. This is needed for that because customers USE > THESE FORLARGE FLOWS. >=20 > Danny - Need framework and requirements and coordination with fat PW > stuff.=20 >=20 > --------------------------------------------------- > T-MPLS Update - Stewart bryant (stbryant@cisco.com) > --------------------------------------------------- >=20 > Describes SG13 plenary in Seoul. T-MPLS protocol and requirements. > Q5/13 in Seoul. Meeting attended by 3 IETF Ads, plus 1 from IAB. Goal > to represent comments from IAB DT. > Considerable work on requirements - amended to become implementation > neutral requirements, which were published as an informational > supplement. Available through ITU-T web site. > Non-normative, but lots of useful info on improving OAM for MPLS and > PWE3. >=20 > G.8114: no technical work. Question recommended that Recommendation > withdrawn from AAP and publication stopped. >=20 > SG5 plenary:=20 > Considerable work done before meeting on structure of JWT. This was > approved. Because of the pending decision on JWT, all related tech > work on T-MPLS halted until decision taken. >=20 > JWT task to recommend option 1 or option 2 to ITU management. > Small team of experts picked. > Jointly chaired by David Ward and Malcolm Betts. > Based on technical studies of 2 large study groups - IETF interop > design team, and ITU-T ad0hoc group. >=20 > IETF Interop design team will perform technical analysis to determine > what ITU or IETF docs/technology mods/extensions needed. Advise JWT on > the deliberations. > IETF MPLS interop DT chaired by Loa. Must report by April deadline. > Technical work is only to understand what needs to be done. Design > will be done in normal standards process. >=20 > Shows work areas. >=20 > ITU Ad Hoc group investigates technical info needed to decide between > option 1 and option 2 >=20 > JWT will compile results of 2 support groups and make a decision. >=20 > Regardless of option 1/2 decision, we have learned a lot about OAM > requirements. Will be a draft on this. > There is also mis-understanding about the use of the EXP bits. There > will be a draft to clarify this as well. >=20 > Don O'Connor: what about protection, data plane, etc > Stewart: the only thing we can really do is reverse engineer the other > documents, as there are no requirements for these. > Don O'Connor: what is ITU design team going to be doing? > Malcolm Betts: we had a n=3Dmeeting in Geneva for 2 days. We developed > some requirements, and posted on ad-hoc teams FTP site. We should have > some improved clarification on requirements in the next few days. > Don O'Connor: so if option 1 is chosen, future methodology is 1 DT > with requirements? > Stewart: some things will be done here, but some things will happen > over in ITU e.g. G.805 modelling. But MPLS technology extensions have > to happen here. > Malcolm Betts: agrees. Note these design teams have no authority to > change IETF or ITU-T documents. These have to be done via regular > standards process in the appropriate bodies. We also need to improve > liaison process. > Stewart: There is a common agreement that we will work together > Danny: Appreciates the incredible amount of work done. Thanks to > everyone. >=20 >=20 > ------------------------------------------------- > PW Multiplexing - Yaakov Stein (yaakov_s@rad.com) > ------------------------------------------------- > No draft on this. >=20 > Heard a bit about protection and load balancing today. These were held > over from last time. This is some architecture work. In PWE3 arch, we > have an element that can help us. This is a PW Mux which is based on > the forwarder in the arch draft. A forwarder gives you a many-many > connection. > Can be used for protection, AC protection, and PW load balancing and > inverse mux. >=20 > Doesn't think label space exhaustion is a problem because 2^20 labels > Explains 1+1 protection. PW mux maps AC to appropriate PWs.=20 > 1:1 can use PW redundancy signalling, but then PW mux makes the > decision on forwarding. >=20 > 1+1 AC protection: AC mux, and associate multiple ACs with single PW > label > 1:1 AC protection : again map single PW label to multiple ACs. > Load balancing and inverse mux: use all PWs at same time, but not for > all the packets. >=20 > Proposal is for pure architecture work.=20 > Need a single method for PW protection, AC protection and load > balancing and PW mux. > Means a single label for associating PW labels to AC IDs. > Designating PW status > Signaling between forwarders >=20 > Sasha V: agree with Yaakov, and 3985 says must be per-tunnel, but 4447 > says must be per-platform because of MPLS arch requirements. Can you > map CE dual homing to this? This is not covered. > Yaakov: why is this not 1+1 AC protection? > Sasha: Because not one PW > Yaakov: This is a very important use case. If it cannot be included, > we should see if we really want to proceed. > Andy Malis: on ACs, why not just use LAG or multi-link > Yaakov: could do, but this is a single AC from arch point of view. > Sure you could do that. But that is not using the function of the > forwarder. > Andy Malis: so why is this needed? > Yaakov: might not be Ethernet, might be ATM IMA etc. > Dave McDyson: why can't these just be native service protection? > Yaakov: If you have native service protection, go ahead and use it if > you want.=20 > Dave McDyson: is this really a requirement then > Ali Sajassi: so you are proposing multiple PWs per AC for load > balancing? > Yaakov: yes > Ali Sajassi: we have an internal PW ID and a hash ID, whether you map > into a single or two labels, that is only an encoding issue. > Yaakov: might be computationally more expensive with two labels that > you have to pop. > Ali: 2 issues: number of labels and processing in the PE. Processing > in the PE is not an issue. > Stewart: putting an extra label in is not computationally complex. >=20 > Danny: proposal is that you publish a draft on anything else you want > to discuss. > Yaakov: wanted to have presentation because wanted to gauge interest > Stewart: touches on a number of areas=20 > Danny: could submit as a draft this is the appropriate way to convey > this. >=20 > ------------------------ > Meeting Closes (early!). >=20 >=20 >=20 >=20 >=20 ------_=_NextPart_001_01C8880F.E909CAB6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Philadelphia minutes

Folks,

Please find attached = the draft minutes from Philadelphia. Please let me know if you have any = comments.

Best regards,

Matthew


Monday, March 10th, 2008 – = 15:20 – 17:20
----------------------------------------
CHAIRS: Danny McPherson & Stewart = Bryant
SCRIBE: Matthew Bocci

------------------------------
WG Status and Update – = Chairs
------------------------------

Agenda agreed.
20 RFCs to date
3 held up
MIBs pushed through to IESG.
MS-PW requirements – = many security requirements on this. Trying to resolve these. There is a = backlog behind these.
ATM MIB a little late – = updated now
Work in progress – many held = up due to MS-PW reqs.
Redundancy – now a WG = item. No negatives on the list. A few comments on list about couple = mechanisms together.
Need some work on other MIBs.
New charter being worked on
OSPF routing draft – = needs to coordinate with the OSPF. Chairs will check with ADs that this = is OK to take on.

----------------------------------------------------------= ------------
PW Redundancy Update – = Praveen Muley (Praveen.muley@alcatel-lucent.com)
http://tools.ietf.org/wg/pwe3/draft-ietf-pwe3-redundancy-b= it/
draft-ietf-pwe3-redundancy-00.txt = (posted to list)
----------------------------------------------------------= ------------

Gives an update on the drafts. Both = adopted as WG docs.
Major addition is revertive = behaviour.
Framework and Requirements:
-       = added new co-authors
-       = added new definitions and terminology
-       = aligned text to be more to FR like
-       = added generic PW requirements

Shows new terminology.
Generic PW redundancy = requirements – 1:1 is mandatory, N:1 optional
1+1 is left for further study.
Non-revertive mandatory, revertive = optional.
Added operational requirements.

Preferential forwarding status bit = draft:
-       = updated scope of protection capabilities achieved
-       = - revertive/non-revertive behaviour
-       = Added appendix


Next steps
-       = manual lockout case
-       = more feedback from WG requested

Danny: has evolved and progressed and = fine to go forward
??: ITU-T have defined some linear = protection. Better to align with ITU-T.
Dave McDyson – I agree. = Important clients are TDM etc that have their own native protection = schemes. Framework would be a good place to map native service = terminology and make appropriate references.

----------------------------------------------------------= ---------
MPLS & Ethernet OAM = Interworking – Dinesh Mohan (mohand@nortel.com)
http://tools.ietf.org/id/draft-mohan-pwe3-mpls-eth-oam-iwk= -00.txt
----------------------------------------------------------= ---------
Presented by Nabil Bitar.

Current PWE3 OAM message mapping does = not address interworking with Ethernet OAM.
Since then, good progress in Ethernet = OAM space.
This draft tries to complement the = mapping draft with interworking with PWs.
Shows reference model.
Consistent fwd/reverse defects with = message mapping draft
Explains PW and AC defect detection = options, and the mapping of reverse and forward defects between the = Ethernet AC and the PW

Next steps:
Could merge with oam-msg-map or pursue = as a separate draft.

Yaakov Stein – this is = important work. Have you also looked into .3ah? We need this covered = too.
Nabil: I thought we did, because we = cover link level defects. We need to go back and make sure this is = covered.
Ali Sajassi: This is a very good = comment. Counts for ELMI too in MEF.
Luca Martini: I have asked for this = years ago, and chairs did not want to put into. I am in favour of = putting this into message mapping.

Stewart – don’t = remember, but msg-map is quite mature
Luca Martini – this will = generate more interest again and we can progress this.
Stewart – Monique is = the editor and she just refreshed it. It would be good to review = msg-map, and progress Ethernet separately as some more material to = add.

Yaakov Stein – agrees = should be separate, and not hold up message map.
Danny: is there consistent terminology = with OAM and redundancy drafts?
Nabil: The mapping draft is most = advanced, and common authors with redundancy, so hope they are = consistent, but need to check.

Stewart: if existing OAM message = mapping draft is nearly done, then keep separate so as not to hold = up.

Luca Martini: what will the IESG say = without the lack of Ethernet?
Stewart: put in informative reference = to Ethernet doc. Co-authers need to add informative reference, and then = we will last call it.

George Swallow: The way the industry is = going, the Ethernet is the  most important part.

----------------------------------------------------------= -------------------
LDP AII Reachability – = Frederick Jounay (frederic.jounay@orange-ftgroup.com)
http://tools.ietf.org/id/draft-delord-jounay-pwe3-ldp-aii-= reachability-00.txt
----------------------------------------------------------= -------------------

First version of the draft.

Explains rationale.
Procedure to populate AII routing = tables in first hop S-PE via LDP
Intended to complement IGP/BGP = mechanisms
Problem statement:
Typical to access networks. No IGP or = BGP – p2p physical connectivity
But run LDP for PW setup
IP and PW addressing separate

Does NOT replace routing = protocols
Advertise only locally attached = AII

Explains proposed mechanism

Next steps:
-       = feedback from WG
-       = add some extra scenarios (dual homing)
-       = extend to AGI as well?


Luca Martini: What do you mean by = extend to AII?
Fred: Just mean also use for VPN = provisioning using LDP
Luca Martini: Just haven’t found = a good application for the AGI in this context, but would like to know = if you have one.

Fred: Network autodiscovery populates = on S-PE/T-PE, but VPN autodiscovery must only be at the end point
Hamid Ould-Brahim: on your 1st slide, = what do you mean by interwork with other auto-discovery = mechanisms?
Fred: the S-PE can relay this info = based on BGP or IGP
Luca Martini: confusing term is = auto-discovery. It should be over routing protocols.

Stewart: Who is interested? Lots
Stewart: Who thinks this is a good = starting point? Quite a few


----------------------------------------------------------= -----------------
Conversation Hashing for = Pseudowires – Vach Kompella = (vach.kompella@alcatel-lucent.com)
= http://tools.ietf.org/id/draft-vkompella-pwe3-hash-label-0= 0.txt
----------------------------------------------------------= -----------------

Discussed a long time ago, but no = demand at that time. Then Stewart brought fat PW draft, so I wanted to = add this to the pile.

A PW can carry many flows, and do not = want PW to follow one path if the PW has many flows that can follow = different path e.g if PSN has ECMP or LAG etc

Explains PW hashing fields
Could use hack such as looking at 1stt = nibble, but complex and only works if it is a 4/6 for IP.
Can we do something intelligent with = the label stack?

Shows an example.

Solution proposes that 2 ends of PW = exchange a range of has labels that can be used by ingress side to hash = traffic and pick a next hop for trhe PSN.

Packet: tunnel, hash, PW label, = payload

At LSR, LSP swaps on tunnel label. =

At egress, tunnel popped, hash is = popped, and then you proceed based on PW label.

Benefits include the fact that ingress = holds one set of labels per peer. Egress distributes one set of labels. = Extensible to PSNs and to BGP VPNs.

Hasahable info is stable per flow, uses = MPLS methods, requires no changes to the CE, minimises the labels = allocated and programmed per node.

Acknowledges that some P routers = don’t hash this way (order of labels), would like to understand if = we should…

Shows some considerations on extending = to PSNs.
Ingress PSN- hash label at the top of = the stack.
Questions – where = should we put hash label? I think it should be before the PW label to = leave PW context processing to the end.

How does this work with existing = implementations?
Is this a new FEC? Or just a = capabilities exchange?
Diversity for BGP label = exchanges.
Should this be done in MPLS WG?
Could this be used to explore PW paths = like LSP-ping multi-path?

Danny: please address these questions = first, then we will go to regular questions

Yaakov Stein: yes, place to put it is = between PW label and tunnel. How does this work for LSPs.
Vach: For PW, 1stst guy gets a packet = with n different hash labels, to choose n different next hops.
Discussion taken off line
Rahul : not sure if this applies to IP = VPNs because IP header involved. PSNs could be an issue due to = application level entropy…

Kireeti Kompella: good stuff here. = There are a lot of things you have not done quite perfectly yet. Happy = to help. In picture, how do you get a good hash if you have 20 bits of = option and only using 3 bits? I think you put labels in wring = place – talk about off line – but do = agree we need to extend to IP VPNs and PSNs.

Stewart – include me = in this.
Kireeti Kompella – I agree = bottom is the right place. Would like to take out of PWE3 for now, and = talk among all the interested people. Then we can figure out how to = proceed.

Danny: agree
Don O’Connor: is this only for = best effort?
Vach: this is not developed well = enough for multiple levels of service
Don O’Connor: should this be in = the charter?
Vach: Could use diffserv TE and use = different hash label
Stewart: Not clear that you need to = know this
Don O’Connor– if = you want to groom traffic by traffic class in an S-PE this should be = allowed
Ali Sajassi: have you considered = impact on native and PW OAM?
Vach: No, not yet
Ali Sajassi: It has impacts and needs = to be considered. If you exclude OAM for the time being, why not assign = multiple PW labels?

Vach: Service Providers have large = numbers of PWs. That would not scale. Amount of churn on every failure = would be too high.

Ali Sajassi: need to address OAM
George Swallow: only time I looked = into what labels are hashed on, everyone hashed on bottom label. Could = do this survey again. If this a general mechanism, should not be in = MPLS. I would like to be on this mailing list.

Stewart: issue that if we do this in = MPLS, not clear that the signalling for PS will work properly.
Kireeti Kompella: need to do something = for underlying tunnels, and make some generalisation about load = balancing. We can then farm out the signalling to individual groups. = Framework in MPLS.

Stewart: Agrees to that.
Vach: requirements come from = providers, and they have lots of differences, but there is also = differences on the implementation side so would like to not just give to = a set of providers.

Stewart: My draft was with DT because = it is a real SP problem.
Mark Townsley: No problem in defining = this in MPLS, but pressing problem is here. Does not seem all that = pressing for the IP case.

Dave Allan: Would echo Mark’s = comments – for something that can hash IP now, too much = complexity. Also need to ensure OAM flows fate share with combination of = PW and hash label.

Luca Martini: Comment on both drafts. = Does not solve a generic problem. Only works if you can identify a flow = to has on the input. What causes such a large flow? And IPSec flow from = a bank? This only works if you can identify the flows on = ingress.

Shane Amante: agree this belongs in = MPLS. Mark and Rahul had some discussions about IPVPN. This is needed = for that because customers USE THESE FORLARGE FLOWS.

Danny – Need = framework and requirements and coordination with fat PW stuff.

---------------------------------------------------=
T-MPLS Update – Stewart = bryant (stbryant@cisco.com)
---------------------------------------------------=

Describes SG13 plenary in Seoul. T-MPLS = protocol and requirements.
Q5/13 in Seoul. Meeting attended by 3 = IETF Ads, plus 1 from IAB. Goal to represent comments from IAB = DT.
Considerable work on = requirements – amended to become implementation neutral = requirements, which were published as an informational supplement. = Available through ITU-T web site.

Non-normative, but lots of useful info = on improving OAM for MPLS and PWE3.

G.8114: no technical work. Question = recommended that Recommendation withdrawn from AAP and publication = stopped.

SG5 plenary:
Considerable work done before meeting = on structure of JWT. This was approved. Because of the pending decision = on JWT, all related tech work on T-MPLS halted until decision = taken.

JWT task to recommend option 1 or = option 2 to ITU management.
Small team of experts picked.
Jointly chaired by David Ward and = Malcolm Betts.
Based on technical studies of 2 large = study groups – IETF interop design team, and ITU-T ad0hoc = group.

IETF Interop design team will perform = technical analysis to determine what ITU or IETF docs/technology = mods/extensions needed. Advise JWT on the deliberations.

IETF MPLS interop DT chaired by Loa. = Must report by April deadline. Technical work is only to understand what = needs to be done. Design will be done in normal standards = process.

Shows work areas.

ITU Ad Hoc group investigates technical = info needed to decide between option 1 and option 2

JWT will compile results of 2 support = groups and make a decision.

Regardless of option 1/2 decision, we = have learned a lot about OAM requirements. Will be a draft on = this.
There is also mis-understanding about = the use of the EXP bits. There will be a draft to clarify this as = well.

Don O’Connor: what about = protection, data plane, etc
Stewart: the only thing we can really = do is reverse engineer the other documents, as there are no requirements = for these.

Don O’Connor: what is ITU design = team going to be doing?
Malcolm Betts: we had a n=3Dmeeting in = Geneva for 2 days. We developed some requirements, and posted on ad-hoc = teams FTP site. We should have some improved clarification on = requirements in the next few days.

Don O’Connor: so if option 1 is = chosen, future methodology is 1 DT with requirements?
Stewart: some things will be done = here, but some things will happen over in ITU e.g. G.805 modelling. But = MPLS technology extensions have to happen here.

Malcolm Betts: agrees. Note these = design teams have no authority to change IETF or ITU-T documents. These = have to be done via regular standards process in the appropriate bodies. = We also need to improve liaison process.

Stewart: There is a common agreement = that we will work together
Danny: Appreciates the incredible = amount of work done. Thanks to everyone.


-------------------------------------------------
PW Multiplexing – Yaakov = Stein (yaakov_s@rad.com)
-------------------------------------------------
No draft on this.

Heard a bit about protection and load = balancing today. These were held over from last time. This is some = architecture work. In PWE3 arch, we have an element that can help us. = This is a PW Mux which is based on the forwarder in the arch draft. A = forwarder gives you a many-many connection.

Can be used for protection, AC = protection, and PW load balancing and inverse mux.

Doesn’t think label space = exhaustion is a problem because 2^20 labels
Explains 1+1 protection. PW mux maps = AC to appropriate PWs.
1:1 can use PW redundancy signalling, = but then PW mux makes the decision on forwarding.

1+1 AC protection: AC mux, and = associate multiple ACs with single PW label
1:1 AC protection : again map single = PW label to multiple ACs.
Load balancing and inverse mux: use = all PWs at same time, but not for all the packets.

Proposal is for pure architecture work. =
Need a single method for PW = protection, AC protection and load balancing and PW mux.
Means a single label for associating = PW labels to AC IDs.
Designating PW status
Signaling between forwarders

Sasha V: agree with Yaakov, and 3985 = says must be per-tunnel, but 4447 says must be per-platform because of = MPLS arch requirements. Can you map CE dual homing to this? This is not = covered.

Yaakov: why is this not 1+1 AC = protection?
Sasha: Because not one PW
Yaakov: This is a very important use = case. If it cannot be included, we should see if we really want to = proceed.
Andy Malis: on ACs, why not just use = LAG or multi-link
Yaakov: could do, but this is a single = AC from arch point of view. Sure you could do that. But that is not = using the function of the forwarder.

Andy Malis: so why is this = needed?
Yaakov: might not be Ethernet, might = be ATM IMA etc.
Dave McDyson: why can’t these = just be native service protection?
Yaakov: If you have native service = protection, go ahead and use it if you want.
Dave McDyson: is this really a = requirement then
Ali Sajassi: so you are proposing = multiple PWs per AC for load balancing?
Yaakov: yes
Ali Sajassi: we have an internal PW ID = and a hash ID, whether you map into a single or two labels, that is only = an encoding issue.

Yaakov: might be computationally more = expensive with two labels that you have to pop.
Ali: 2 issues: number of labels and = processing in the PE. Processing in the PE is not an issue.
Stewart: putting an extra label in is = not computationally complex.

Danny: proposal is that you publish a = draft on anything else you want to discuss.
Yaakov: wanted to have presentation = because wanted to gauge interest
Stewart: touches on a number of areas =
Danny: could submit as a draft this is = the appropriate way to convey this.

------------------------
Meeting Closes (early!).





------_=_NextPart_001_01C8880F.E909CAB6-- --===============2116518762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --===============2116518762==-- From pwe3-bounces@ietf.org Mon Mar 17 20:38:02 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91CEE28C1A6; Mon, 17 Mar 2008 20:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.206 X-Spam-Level: X-Spam-Status: No, score=-101.206 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 lAHYWt6YlahX; Mon, 17 Mar 2008 20:38:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87DD63A6B86; Mon, 17 Mar 2008 20:38:01 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE4F3A6B86 for ; Mon, 17 Mar 2008 20:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 6mx6vsoTYfAZ for ; Mon, 17 Mar 2008 20:37:58 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 616D33A6822 for ; Mon, 17 Mar 2008 20:37:57 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2I3ZZo17824; Tue, 18 Mar 2008 03:35:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Mar 2008 23:35:38 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB11593986@zcarhxm1.corp.nortel.com> In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD02B62FC0@ilptex01.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A question regarding draft-mohan-pwe3-mpls-eth-oam-iwk-00 Thread-Index: AciFGvGzL5xHTBsDQ1aqxtF1fOIaYgDjJb1Q References: <64122293A6365B4A9794DC5636F9ACFD02B62FC0@ilptex01.ecitele.com> From: "Dinesh Mohan" To: "Alexander Vainshtein" Cc: pwe3@ietf.org Subject: Re: [PWE3] A question regarding draft-mohan-pwe3-mpls-eth-oam-iwk-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0741452250==" Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0741452250== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C888A9.1FF00F68" This is a multi-part message in MIME format. ------_=_NextPart_001_01C888A9.1FF00F68 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha, =20 Please see inline: =20 ---=20 Dinesh=20 ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Thursday, March 13, 2008 11:00 AM To: Mohan, Dinesh (CAR:NP02) Cc: pwe3@ietf.org Subject: A question regarding draft-mohan-pwe3-mpls-eth-oam-iwk-00 Dinesh, Section 5.1. of the draft describes several options for handing PW forward defect. I have two questions regarding this section: 1. All the options listed in the text require that a (down) MEP associated with the AC of the PW in question has been configured. Any ideas what should happen if there is no MEP there? DM>> If there is no MEP, then currently there will be no means to communicate the defect status to the CE, therefore, there is certainly an assumption made here that Ethernet OAM must be used at the Ethernet AC for such capabilities. 2. MEF has ratified the E-LMI IA as its MEF 16 spec (see http://metroethernetforum.org/MSWord_Documents/MEF16.doc ). This mechanisms seems similar to FR LMI that has been used to convey the FR PW defects in draft-ietf-pwe3-oam-msg-map-06.txt. Are there any reasons not to use E-LMI in the same way, at least as one of the options? DM>> We can certainly consider adding more options, however, the primary purpose for deploying E-LMI is provisioning of CE devices and not fault notifications, therefore the same question arises as to what happens when E-LMI is not available. The main point here is that the draft focuses on fault notifications, and for fault purposes, Ethernet OAM is a basic assumption across AC to keep things simple.=20 Regards, Sasha ------_=_NextPart_001_01C888A9.1FF00F68 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sasha,
 
Please see inline:
 
---
Dinesh
From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Thursday, = March 13,=20 2008 11:00 AM
To: Mohan, Dinesh (CAR:NP02)
Cc:=20 pwe3@ietf.org
Subject: A question regarding=20 draft-mohan-pwe3-mpls-eth-oam-iwk-00

Dinesh,
Section 5.1. of the=20 draft describes several options for handing PW forward=20 defect.
I have = two questions=20 regarding this section:
  1. All = the options=20 listed in the text require that a (down) MEP associated with the AC of = the PW=20 in question has been configured. Any ideas what should happen if there = is no=20 MEP there?  DM>> If there is no MEP, then = currently there=20 will be no means to communicate the defect status to the CE, = therefore, there=20 is certainly an assumption made here that Ethernet OAM must be = used at=20 the Ethernet AC for such capabilities. 
  2. MEF = has ratified=20 the E-LMI IA  as its MEF 16 spec (see http://metroethernetforum.org/MSWord_Documents/MEF16.doc<= /A>). This mechanisms seems similar to FR LMI = that has=20 been used to convey the FR PW defects in=20 draft-ietf-pwe3-oam-msg-map-06.txt. Are there any reasons not to=20 use E-LMI in the same way, at least as one of the options?  DM>> We = can=20 certainly consider adding more options, however, the primary purpose = for=20 deploying E-LMI is provisioning of CE devices and not fault = notifications,=20 therefore the same question arises as to what happens when E-LMI is = not=20 available. The main point here is that the draft focuses on fault=20 notifications, and for fault purposes, Ethernet OAM is a basic = assumption=20 across AC to keep things=20 simple. 
Regards,
       &nbs= p;   =20 Sasha
------_=_NextPart_001_01C888A9.1FF00F68-- --===============0741452250== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --===============0741452250==-- From pwe3-bounces@ietf.org Thu Mar 20 09:45:39 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716CB28C77E; Thu, 20 Mar 2008 09:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xuTmyjeB--G; Thu, 20 Mar 2008 09:45:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E865F28C6E3; Thu, 20 Mar 2008 09:45:12 -0700 (PDT) X-Original-To: pwe3@ietf.org Delivered-To: pwe3@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4A89428C60A; Thu, 20 Mar 2008 09:45:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080320164501.4A89428C60A@core3.amsl.com> Date: Thu, 20 Mar 2008 09:45:01 -0700 (PDT) Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-tdm-control-protocol-extensi-07.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks Author(s) : S. Vainshtein, Y. Stein Filename : draft-ietf-pwe3-tdm-control-protocol-extensi-07.txt Pages : 13 Date : 2008-3-20 This document defines extension to the PWE3 control protocol [RFC4447] and PWE3 IANA allocations [RFC4446] required for setup of TDM pseudowires in MPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-control-protocol-extensi-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-tdm-control-protocol-extensi-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-3-20094134.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Thu Mar 27 14:34:58 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225F63A6FF7; Thu, 27 Mar 2008 14:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.06 X-Spam-Level: X-Spam-Status: No, score=-100.06 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, DEAR_SOMETHING=1.605, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 HN2pugG5BLCr; Thu, 27 Mar 2008 14:34:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19FBF3A6DCF; Thu, 27 Mar 2008 14:34:57 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100C23A6DCF; Thu, 27 Mar 2008 14:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ecfsxjtOze+t; Thu, 27 Mar 2008 14:34:55 -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 6B06E3A67B4; Thu, 27 Mar 2008 14:34:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,565,1199660400"; d="scan'208";a="4656269" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2008 22:32:33 +0100 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 m2RLWXHT002920; Thu, 27 Mar 2008 22:32:33 +0100 Received: from stewart-bryants-computer.local (ams3-vpn-dhcp400.cisco.com [10.61.65.144]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2RLWWWp011604; Thu, 27 Mar 2008 21:32:32 GMT Message-ID: <47EC1271.9070200@cisco.com> Date: Thu, 27 Mar 2008 21:32:33 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Lam, Hing-Kam (Kam)" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1879; t=1206653553; x=1207517553; 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:=20Liaison=20to=20ITU-T=20SG15=20Q14=20re=20G.7712 |Sender:=20; bh=jcx/MQd8AmlwUVLo2ykHy9oJzlohXpYt1pFcZfSND7g=; b=fM0/TNu+ysJYptOBH4kdjsjhbkygTr5Jey2UYl0tkGxpBFdK4V6Zr2qHBA xPd9+wJL2XidaBwcM7e8LEoM6pYd/ObQ1CTe4YNdZAK8ho2nbZMB5Cm5w/XP CAc5eH4x4T; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "George Swallow \(swallow\)" , mpls@ietf.org, Greg.Jones@itu.int, statements@ietf.org, "Scott O. Bradner" , yoichi.maeda@ntt-at.co.jp, pwe3 , David Ward , Danny McPherson , Mark Townsley , Stewart Bryant Subject: [PWE3] Liaison to ITU-T SG15 Q14 re G.7712 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org From: Stewart Bryant (stbryant@cisco.com) To: Lam, Hing-Kam (Kam) (hklam@alcatel-lucent.com) CC: Yoichi Maeda (yoichi.maeda@ntt-at.co.jp) Greg Jones (greg.jones@itu.int) Steve Trowbridge (sjtrowbridge@alcatel-lucent.com) Ross Callon David Ward Loa Andersson (loa@pi.se) George Swallow (swallow@cisco.com) Mark Townsley (townsley@cisco.com) Stewart Bryant (stbryant@cisco.com) Danny McPherson (danny@tcb.net) Scott Bradner (sob@harvard.edu) IETF PWE3 WG (pwe3@ietf.org) IETF MPLS WG (MPLS@ietf.org) statements@ietf.org ITU-T SG15 Question 14 ITU-T SG15 For action by : G.7712 Editor ITU-T SG15Q14 Rapporteur ITU-T SG15 Dear Sirs It has been drawn to our attention that the document G.7712 which is currently in AAP contains identical text to that which was the subject of a recent liaison to the ITU-T concerning Y.1720. This liaison entitled "Consented text for revision of Y.1720" can be found at https://datatracker.ietf.org/documents/LIAISON/file439.doc This liaison was previously considered by ITU-T SG15 Q9 and their response can be found at: https://datatracker.ietf.org/liaison/427/ We thank SG15Q9 for considering the matter and making suitable changes to Y.1720. We request that the editor of G.7712 address the relevant text in the proposed G.7712 Recommendation and any resulting consequences in G.7712. As the IETF is unfamiliar with ITU-T Recommendations, please can we request that SG15 consider this liaison as a request to address similar text in any other ITU-T SG15 documents that have been published or are in the process of publication. Regards Stewart Bryant IETF Liaison to the ITU on MPLS PWE3 WG Co-Chair _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Mar 28 01:50:22 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1DB3A6C9F; Fri, 28 Mar 2008 01:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.981 X-Spam-Level: X-Spam-Status: No, score=-100.981 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 5eziEH78xYm0; Fri, 28 Mar 2008 01:50:22 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7743A6BED; Fri, 28 Mar 2008 01:50:17 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88BB63A6D14 for ; Fri, 28 Mar 2008 01:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Qv7dXU6TWYT5 for ; Fri, 28 Mar 2008 01:50:13 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id 6AC103A6C1F for ; Fri, 28 Mar 2008 01:50:13 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1JfAHq-0008FP-Tx for pwe3@ietf.org; Fri, 28 Mar 2008 09:50:10 +0100 Received: from h4n2fls31o874.telia.com ([213.66.236.4]:62488 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JfAHp-0008FD-Ib; Fri, 28 Mar 2008 09:50:09 +0100 Message-ID: <47ECB132.7090200@pi.se> Date: Fri, 28 Mar 2008 09:49:54 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mpls@ietf.org, pwe3 , l3vpn@ietf.org, L2VPN , ccamp X-Enigmail-Version: 0.95.6 Cc: George Swallow , David Ward Subject: [PWE3] Question on the status of Y.1711 and RFC3429 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org All, In the discussions the IETF and the ITU-T have had on T-MPLS we have discussed the intended use for label 14 and the different documents where this has been specified. As a side effect we've also started to ask ourselves if there are any implementations and/or deployments that uses label 14. A quick survey among known implementers of MPLS has not shown any implementations/deployments. Since one of the approaches discussed in the Joint Working Team context is a solution that requires the allocation of a reserved label and reserved labels are a scarce resource we'd like to know if it possible to redefine label 14 for that particular use. There are still technical issues to be sorted out with the suggested approach, but in the mean time we would like to know if it is possible to deprecate RFC3429 and redefine the OAM Alert Label. The questions is: "Are there any implementations/deployments of Y.1711 or the OAM Alert label as it is allocated in RFC3429; and is there objection to deprecating the protocol as it stands today?" ITU-T has sent out a question along the same lines, see the included mail below. Please respond to the mpls working group mailing list or to the mpls working chairs directly. As usual non-responses will be counted as that there is no implementation/deployment. Loa and George ------------------- included mail ------------------------------------ All users/implementers of recommendation Y.1711, Currently the Joint Working Team of ITU-T and IETF experts is considering the options of using IETF mechanisms to provide OAM for T-MPLS. One possibility is the following mechanism: ------------------------------------------- Push/pop a label at the MEP/domain boundary. This makes the OAM alert label directly visible at the sink MEP. To make the OAM label visible to a MIP the TTL in the server (lower) layer is set by the MEP to expire when the OAM frame reaches the intended MIP. The OAM alert label will point to an =93opcode=94 at the bottom of the stack. ------------------------------------------ This behaviour (when the OAM alert label is received) is not consistent with the behaviour currently defined in Y.1711 when label 14 is received. *QUESTION* are there any users/implementers of the current Y.1711 concerned with this change in behaviour? If there are no concerns then recommendation Y.1711 can be withdrawn or revised to describe the desired behaviour (described above). Please send me (or this list) your response ASAP. Kind regards, Huub van Helvoort, your rapporteur. -- = Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Mar 28 12:50:41 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A943A6D07; Fri, 28 Mar 2008 12:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.806 X-Spam-Level: X-Spam-Status: No, score=-100.806 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 pkGQfZxuyJUb; Fri, 28 Mar 2008 12:50:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7543A691C; Fri, 28 Mar 2008 12:50:40 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EB803A6A93 for ; Fri, 28 Mar 2008 12:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 zbIF8qDlI+T9 for ; Fri, 28 Mar 2008 12:50:37 -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 469CE3A6880 for ; Fri, 28 Mar 2008 12:50:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,572,1199660400"; d="scan'208";a="4757108" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Mar 2008 20:50:35 +0100 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 m2SJoZ1W021195; Fri, 28 Mar 2008 20:50:35 +0100 Received: from stewart-bryants-computer.local (dhcp-10-61-96-59.cisco.com [10.61.96.59]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2SJoZWY008196; Fri, 28 Mar 2008 19:50:35 GMT Message-ID: <47ED4C0C.2050806@cisco.com> Date: Fri, 28 Mar 2008 19:50:36 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Moran Roth , Black_David@emc.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2302; t=1206733835; x=1207597835; 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:=20Bandwidth=20Resources=20Unavailable |Sender:=20; bh=/7Objg28YKeKRCvwZi9Kg4IgkpgOFHo1oHzfFPAQp/A=; b=Du1Lqm2SH1ysLpe/ZVlDpiHY9mm8Dxhok8g3SU2HCwGwtqt4bkl+5h5Jdl EWUl+IHqZv30fBYRqpgwDx61jwdwpoQSBhB9g9R2tjcRzV66ExquC7gPVBHo 2oba/brLGp; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "Luca Martini \(lmartini\)" , pwe3 , Danny McPherson Subject: [PWE3] Bandwidth Resources Unavailable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Moran, David, In the draft-ietf-pwe3-fc-encap you say 6.1.2. Data Sender Protocol = = In case the transmission rate is equal to CIR for a period greater than RTT, and transmitted frames are still lost in transit, as indicated to the sender by receiving SREJ frames, the sender SHOULD signal PW status of =ECBandwidth resources unavailable=EE (refer to IANA registry of STATUS CODE NAME SPACE) as specified in [RFC4447], and SHOULD shut the PW down for a duration of at least R_A_TOV, as described in Section 6.5 of [RFC3985]. I note that you are talking about a PW status here. but you have been asking about sharing a status code point with draft-ietf-pwe3-dynamic-ms-pw-06. However this draft says In the case where PSN resources towards the previous hop are not available the following procedure MUST be followed: -iii. If the S-PE cannot get enough resources to setup the segment in the MS-PW a label release MUST be returned to the previous hop with a status message of "Bandwidth resources unavailable" and in its IANA section it says 11.1. LDP Status Codes This document uses several new LDP status codes, IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC3036 . The following values have = been pre-allocated: Range/Value E Description Reference ------------- ----- ---------------------- --------- 0x00000037 0 Bandwidth resources unavailable RFCxxxx 0x00000038 0 Resources Unavailable RFCxxxx 0x00000039 0 AII Unreachable RFCxxxx 0x0000003A 0 PW Loop Detected RFCxxxx This seems to me to be referring to a MS PW path status rather than a PW status. It also seems to me to be heavy wieght to tear down the whole PW when you run out of PSN bandwidth, rather than simply asking it to be quiet for the timeout period. So should which should we be using - 1) a dedicated PW status bit from Registry Name: Pseudo Wire Status Codes Registry or 2) a new LDP status code or 3) the LDP status code proposed in draft-ietf-pwe3-dynamic-ms-pw-06 and should we be tearing down the whole PW, or simply telling it to be quiet? Regards Stewart = _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Mar 28 13:30:03 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D4528C9B6; Fri, 28 Mar 2008 13:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 0piwz0wxOWC2; Fri, 28 Mar 2008 13:30:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B70228C49F; Fri, 28 Mar 2008 13:30:03 -0700 (PDT) X-Original-To: pwe3@ietf.org Delivered-To: pwe3@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F37333A6BAA; Fri, 28 Mar 2008 13:30:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080328203001.F37333A6BAA@core3.amsl.com> Date: Fri, 28 Mar 2008 13:30:01 -0700 (PDT) Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-redundancy-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Pseudowire (PW) Redundancy Author(s) : P. Muley, M. Bocci Filename : draft-ietf-pwe3-redundancy-00.txt Pages : 14 Date : 2008-03-28 This document describes a framework comprised of few scenarios and associated requirements where PW redundancy is needed. A set of redundant PWs is configured between PE nodes in SS-PW applications, or between T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to indicate the preferred PW path to forward to one another, a new status is needed to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-redundancy-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-redundancy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-28132935.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Fri Mar 28 14:53:49 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3CDD3A6EB9; Fri, 28 Mar 2008 14:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.466 X-Spam-Level: X-Spam-Status: No, score=-100.466 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 RCbsmMyReWD4; Fri, 28 Mar 2008 14:53:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A34A3A6D44; Fri, 28 Mar 2008 14:53:48 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37823A6D44 for ; Fri, 28 Mar 2008 14:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 CDscicednqHq for ; Fri, 28 Mar 2008 14:53:46 -0700 (PDT) Received: from SJMail1.corrigent.com (unknown [63.250.137.231]) by core3.amsl.com (Postfix) with ESMTP id CAD5B3A6BAA for ; Fri, 28 Mar 2008 14:53:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 14:56:43 -0700 Message-ID: In-Reply-To: <47ED4C0C.2050806@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bandwidth Resources Unavailable Thread-Index: AciRDWx6d7GFOKkDQCWplhLXfWs4/gADuu8Q References: <47ED4C0C.2050806@cisco.com> From: "Moran Roth" To: , Cc: "Luca Martini \(lmartini\)" , pwe3 , Danny McPherson Subject: Re: [PWE3] Bandwidth Resources Unavailable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Stewart, The draft states that in case of severe congestion the PW should be teardow= n for a duration of at least R_A_TOV. It also should indicate insufficient = bandwidth. My intention is to use the same status code proposed in draft-ietf-pwe3-dyn= amic-ms-pw-06, however in MS-PW this indication is used during setup, and i= n FC-PW to indicate a failure after the PW is up and running. I would be happy to here more opinions on whether this is allowed or we sho= uld define a new PW status to indicate insufficient bandwidth for PW operat= ion. Best Regards, Moran -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com] = Sent: Friday, March 28, 2008 12:51 PM To: Moran Roth; Black_David@emc.com Cc: pwe3; Luca Martini (lmartini); Danny McPherson Subject: Bandwidth Resources Unavailable Moran, David, In the draft-ietf-pwe3-fc-encap you say 6.1.2. Data Sender Protocol = = In case the transmission rate is equal to CIR for a period greater than RTT= , and transmitted frames are still lost in transit, as indicated to the sen= der by receiving SREJ frames, the sender SHOULD signal PW status of =ECBand= width resources unavailable=EE (refer to IANA registry of STATUS CODE NAME = SPACE) as specified in [RFC4447], and SHOULD shut the PW down for a duratio= n of at least R_A_TOV, as described in Section 6.5 of [RFC3985]. I note that you are talking about a PW status here. but you have been asking about sharing a status code point with draft-ietf-= pwe3-dynamic-ms-pw-06. However this draft says In the case where PSN resources towards the previous hop are not available the following procedure MUST be followed: -iii. If the S-PE cannot get enough resources to setup the segment in the MS-PW a label release MUST be returned to the previous hop with a status message of "Bandwidth resources unavailable" and in its IANA section it says 11.1. LDP Status Codes This document uses several new LDP status codes, IANA already maintains a r= egistry of name "STATUS CODE NAME SPACE" defined by RFC3036 . The following values have bee= n pre-allocated: Range/Value E Description Reference ------------- ----- ---------------------- --------- 0x00000037 0 Bandwidth resources unavailable RFCxxxx 0x00000038 0 Resources Unavailable RFCxxxx 0x00000039 0 AII Unreachable RFCxxxx 0x0000003A 0 PW Loop Detected RFCxxxx This seems to me to be referring to a MS PW path status rather than a PW st= atus. It also seems to me to be heavy wieght to tear down the whole PW when you r= un out of PSN bandwidth, rather than simply asking it to be quiet for the t= imeout period. So should which should we be using - 1) a dedicated PW status bit from Registry Name: Pseudo Wire Status Codes Registry or 2) a new LDP status code or 3) the LDP status code proposed in draft-ietf-pwe3-dynamic-ms-pw-06 and should we be tearing down the whole PW, or simply telling it to be quie= t? Regards Stewart = _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Mar 28 16:06:59 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E223A7098; Fri, 28 Mar 2008 16:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.826 X-Spam-Level: X-Spam-Status: No, score=-100.826 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 krZ5ecAoXaBC; Fri, 28 Mar 2008 16:06:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A2F3A706D; Fri, 28 Mar 2008 16:05:54 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61ACD3A6E4B for ; Fri, 28 Mar 2008 16:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 5z1udAxKu7VK for ; Fri, 28 Mar 2008 16:05:50 -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 350BB3A706D for ; Fri, 28 Mar 2008 16:05:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,572,1199660400"; d="scan'208";a="4768314" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2008 00:05:19 +0100 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 m2SN5IDD022560; Sat, 29 Mar 2008 00:05:18 +0100 Received: from stewart-bryants-computer.local (dhcp-10-61-96-59.cisco.com [10.61.96.59]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2SN5H89013955; Fri, 28 Mar 2008 23:05:18 GMT Message-ID: <47ED79AF.4010507@cisco.com> Date: Fri, 28 Mar 2008 23:05:19 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: pwe3 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=845; t=1206745518; x=1207609518; 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:=20some=20of=20the=20IANA=20values=20for=20draft-i etf-pwe3-fc-encap |Sender:=20; bh=P1jz+i0oI2jiqBDWQFKf7KAxToj0OQEMDKE5rQ/pc1Y=; b=Ba8vr4FvLNQCh5ik5Log/SfrdSmV6eY3uWVVeiLd//EfhG2MngpgLgrwe7 vxSUTguaHl2MGkrEtaMsQ864/+LZKIKCdeU5LEQTTPCyQtSSRVQYxKctQxLr 7GvhA/XDfC; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [PWE3] some of the IANA values for draft-ietf-pwe3-fc-encap X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org I propose that we make the following value allocations for draft-ietf-pwe3-fc-encap-07.txt The following entry needs to be added to the Pseudowire PW Type Registry: PW type Description Reference 0x001F FC Port Mode [FC-encap] The following entries need to be added to the Pseudowire Interface Parameters Sub-TLV type Registry Parameter ID Length Description Reference 0x12 4 SR Poll Timeout (T1) [FC-encap] 0x13 4 SR Response Timeout (T2) [FC-encap] 0x14 4 SR Poll Retries (N2) [FC-encap] 0x15 4 SR Window Size (k) [FC-encap] In both cases the reference [FC-encap] refers to this document. If anyone knows of a clash with another of our drafts, please let me know. Thanks Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Mar 28 17:13:54 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DDD3A6F89; Fri, 28 Mar 2008 17:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.096 X-Spam-Level: X-Spam-Status: No, score=-100.096 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 AhusUVlJ7Pr9; Fri, 28 Mar 2008 17:13:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E003A69C8; Fri, 28 Mar 2008 17:13:53 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576EB3A69C8 for ; Fri, 28 Mar 2008 17:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 MunE3EVSdL5Y for ; Fri, 28 Mar 2008 17:13:49 -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 0D4823A681B for ; Fri, 28 Mar 2008 17:13:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,573,1199660400"; d="scan'208";a="4769901" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2008 01:13:47 +0100 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 m2T0DlTf026360; Sat, 29 Mar 2008 01:13:47 +0100 Received: from stewart-bryants-computer.local (dhcp-10-61-96-59.cisco.com [10.61.96.59]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2T0Dkr8024991; Sat, 29 Mar 2008 00:13:46 GMT Message-ID: <47ED89BC.8040108@cisco.com> Date: Sat, 29 Mar 2008 00:13:48 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Moran Roth , Black_David@emc.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14996; t=1206749627; x=1207613627; 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:=20draft-ietf-pwe3-fc-encap-07=20-=20mostly=20edit orials |Sender:=20; bh=DN2mxodC3C4P+KbYg/iEZXO3bBAkeupcyeFfPcd3K/Q=; b=Ybw24QZ5QiRJbAOfpLOdCpXhvR5hmlhiqbN/9kHSFS2O7jFaHiWWctYX4i w1iacXCvC3Dho+5G6S+QhVSh9oXkfgPx4Y/AhzGHd/RqFe9O1OXB/ipPdfmP uOQibAG+rV; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Mark Townsley , pwe3 , Danny McPherson Subject: [PWE3] draft-ietf-pwe3-fc-encap-07 - mostly editorials X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org I have just re-read draft-ietf-pwe3-fc-encap-07.txt = Most of this is just editorial. I am concerned that this draft does not use rigorously consistent terms through out the document. We need to make sure we have a single name through out for this PW and we may want to change the proposed name in the IANA text to align with that term. I did not go word by word through section 6.2 and section 6.3 to verify the protocol retransmission protocol. Has anyone other than authors done a word by word verification of these two sections? - Stewart = = 2. Introduction = ..... One such method is FC over MPLS (FC/MPLS), which = provides an alternative to FC/IP, as well as to the various = interconnect technologies described as part of [FC-BB]. I think that you use FC/IP before you define the term = This section focuses on the applicability of methods = and procedures to encapsulate FC over MPLS, specifically those which = are relevant to "FC over an MPLS PSN" or "FC over and MPLS enabled IP PSN" = FC/MPLS provides a method for transporting FC frames = over an MPLS- based transport network, such as a packet-oriented = transport network, in this document also referred to simply as PSN. Do you mean "MPLS based transport network" - that now has a special meaning Note that you really should not hence use PSN as in PWE3 this is = commonly used to mean IP or MPLS It defines the encapsulation of FC Protocol Data Units (PDU) into an = MPLS pseudowire, It is not an MPLS PW - that is something entirely different (the term = means a PW that carries another PW and may well be defined in PWE3 in the near = future) - this is an pseudowire that runs over an MPLS PSN. as well as procedures for using PW encapsulation to enable FC services such as SAN extension and disaster = recovery over a PSN. FC/IP, as described in [RFC3821], defines the = mechanisms that allow the interconnection of islands of FC SANs over = IP Networks. It provides a method for encapsulating FC frames = employing FC Frame Encapsulation, as defined in [RFC3643], and addresses = specific FC concerns related to tunneling FC over an IP-based network. MPLS is normally an IP based network. Maybe you should say something = like "pure IP network". = FC/MPLS is being proposed to complement the currently = available standardized methods for transporting FC frames over a = PSN. Here you do mean PSN = Specifically, FC/IP addresses =EConly the requirements = necessary to properly utilize an IP network as a conduit for FC = Frames=EE, whereas FC/MPLS addresses the requirements necessary to = transport FC over an MPLS-based PSN. I guess that by now you get my point about MPLS being an extension to an IP network An example of such a network might be a L2 PSN or a Calling up L2 PSN will lead to concerns that we do not specify L2 PSNs = in the IETF = packet-oriented multi-service transport network, where = MPLS is used as the universal method for encapsulating and = transporting all type of services, including mission critical FC = applications as well as other TDM and data services. Hence, a key benefit of = FC/MPLS is that it will enable the extension of FC applications to the = carrier transport space. Maybe you should delete the para? = = The following sections describe some of the key = carrier requirements for transporting FC frames over an MPLS-based PSN. = 2.1. Transparency = = Transparent emulation of an FC link is a key = requirement for transporting FC frames over a carrier=EDs transport netwo= rk. Again do you mean transport network - you use the terms lots of times = Conventionally, the coupling (or pairing) of FC = entities with those pertaining to specific encapsulation methods requires = the protocol- specific entity to terminate the FC Entity. This, in = most cases, would require global address synchronization to be = performed by the operator. In addressing this requirement, and = providing full transparency, FC/MPLS defines a port-mode FC = encapsulation into an MPLS PW. Again not an MPLS PW This requires the creation of an FC pseudo-wire = emulating an pseudowire not pseudo-wire FC Link between two FC ports, appearing = architecturally as being wired to those ports, similar to the approach defined = for FC over GFPT in [FC-BB]. This results in transparent = forwarding of FC frames over the MPLS-based PSN from both the FC Fabric and = the operator=EDs point of view. It's really an MPLS PSN, not an MPLS-based PSN - this applies lots of = places. = = 2.3. Traffic Engineering = = effectively enabling network operators to establish an explicit = path over which reliable frame forwarding can be guaranteed. Your protocol makes the FC transfer reliable, but even with MPLS-TE the path is not reliable. = 2.4. Security = = FC/MPLS is designed to transparently support the = forwarding of FC frames received from the local FC port, into a = pre-established FC PW, thus effectively making the FC/MPLS emulated path less = susceptible to attacks when compared to, e.g., IP public networks. If you do not need this sub-section - I would delete it - you have a = security section later where you should discuss the security issues. MPLS is = probably not as secure as for example an IPsec network against snooping on the data which might be more beneficial to an attacker that disrupting it. = = 3. Reference Model = A Fibre Channel pseudowire (PW) allows FC Protocol = Data Units (PDUs) to be carried over an MPLS network. You need to align the terminology with the earlier section. = = = 4. Encapsulation = 4.1. The Control Word = The Generic PW Control Word, as defined in "PWE3 = Control Word" [RFC4385] MUST be used for FC PW to facilitate the = transport of short packets, and convey the flag bit defined below. FC/MPLS PW? Also used later in the document. What do you mean by short packets? = 1 = 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| PT |A|0 0| Length | Sequence = Number | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = Figure 3 - Control Word structure for the one-to-one = mapping mode = The first three bits of the Flags field are not used = and MUST be set to 0 by the ingress PE, and MUST be ignored by the = egress PE. There is a single flag bit in use for FC PW, as specified = below. Do you mean the first four bits, and surely you use 4 flag bits? = PT =F1 Payload Type indication. This field identifies = the payload type = carried within the PW PDU. The following types = are defined: PT =3D 0: FC data frame. PT =3D 1: FC login frame. PT =3D 2: FC Primitive Sequence. PT =3D 6: FC Control Frame (refer to [FC-BB]). = A =F1 The Address bit identifies the frame as either a = command or a = response. This field is used in conjunction with = the Poll Bit of = the Selective Retransmission protocol. Messages = containing commands MUST set this bit to 1. Messages = containing responses = MUST set this bit to 0. This bit MUST be set to 0 = for FC Control = frames as indicated by Payload Type value of 6. = Further details = regarding the use of this flag are provided in = section 6. For my curiosity why is it an A(dress) bit and not a C(ommand) bit? = 4.2. MTU Requirements = The PSN MUST be able to transport the largest Fibre = Channel encapsulation frame, including the overhead associated = with the tunneling protocol. Fragmentation, described in = [RFC4623], SHALL NOT be used for FC PW, therefore the network MUST be = configured with a minimum MTU that is sufficient to transport the = largest encapsulation frame. Is there a upper bound for this so that a PSN engineer who does not know = FC knows how to set the PSN MTU? = 4.3. Mapping of FC traffic to PW PDU = = Each FC frame is mapped to a PW PDU, including the = Start Of Frame (SOF) delimiter, frame header, CRC field and the End = Of Frame (EOF) delimiter, as shown in figure 4. SOF and EOF frame = delimiters are encoded as specified in [FC-BB]. Is the CRC defined there also? = FC Primitive Sequences are encapsulated in a PW PDU = containing the encoded K28.5 character, followed by the encoded 3 = data characters, K28.5 needs a reference, so does ordered sets (below) as shown below. A PW PDU may contain one or more FC = encoded ordered sets. = FC Control frames are transported over the PW, by = encapsulating each frame in a PW PDU. The FC header MUST contain a FC PW = Control Word, I think you mean the FC/MPLS PW header must.... with PT =3D 6 = = 5.1.1. SR Poll Timeout (T1) 5.1.2. SR Response Timeout (T2) = 5.1.3. SR Poll Retries (N2) 5.1.4. SR Window Size (k) You saw my questions on these in the IANA note about the length definitions. = = 6.1.2. Data Sender Protocol = = In case the transmission rate is equal to CIR for a = period greater than RTT, and transmitted frames are still lost in = transit, as indicated to the sender by receiving SREJ frames, the = sender SHOULD signal PW status of =ECBandwidth resources unavailable=EE = (refer to IANA registry of STATUS CODE NAME SPACE) as specified in = [RFC4447], and SHOULD shut the PW down for a duration of at least = R_A_TOV, as described in Section 6.5 of [RFC3985]. If the PW has = been set up using the PWE3 control protocol [RFC4447], the regular = PW teardown procedures SHOULD be used. After this period the PW = MAY be restarted. See my comment to the list = If within R_A_TOV after restarting the PW congestion = is encountered Where is R_A_TOV defined? = 7. Security Considerations = This document specifies only encapsulations, and not = the protocols used to carry the encapsulated packets across the PSN. = Each such protocol may have its own set of security issues = [RFC4447] [RFC3985], but those issues are not affected by the = encapsulations specified herein. Note that the security of the emulated service = will only be as good as the security of the PSN. I think that this is going to need lot more work to get it approved. = = 8. Applicability Statement = FC PW allows the transport of point-to-point Fibre = Channel links I think that you mean FC/MPLS while saving PSN bandwidth. = - The pair of CE devices operates as if they were = connected by an emulated FC link. In particular they react to = Primitive Sequences on their local ACs in the standard way. Do you mean emulated FC link, or FC link - you are designing an emulator = here. = - The PSN carries only FC data frames and a single = copy of a Surely the FC/MPLS PW carries the FC data frames, and the PSN carries the Primitive Sequence. Idle Primitive Signals = encountered between FC data frames, and long streams of the same Primitive = Sequence are suppressed over the PW thus saving the BW. = FC PW traffic can traverse controlled (i.e., providing = committed information rate for the service) networks and = uncontrolled (i.e., providing excess information rate for the service) = networks. In case of FC PW traversing an uncontrolled network, it SHOULD = provide TCP- friendly behavior under network congestion (refer to = Congestion Control section for further details). Why SHOULD and not MUST? . = =3D=3D=3D=3D=3D=3D=3D=3D = _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Mar 28 17:16:50 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9863A6EBB; Fri, 28 Mar 2008 17:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.694 X-Spam-Level: X-Spam-Status: No, score=-100.694 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 4XfWhGZ87QSc; Fri, 28 Mar 2008 17:16:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8BF3A6D3A; Fri, 28 Mar 2008 17:15:24 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7E028C28F for ; Fri, 28 Mar 2008 05:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 aqsF0QXFvR8h for ; Fri, 28 Mar 2008 05:07:49 -0700 (PDT) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by core3.amsl.com (Postfix) with SMTP id 90FB83A6AF3 for ; Fri, 28 Mar 2008 05:07:38 -0700 (PDT) Received: (qmail 98884 invoked from network); 28 Mar 2008 12:07:34 -0000 Received: from unknown (HELO ShahramPC) (davari@rogers.com@99.238.119.231 with login) by smtp101.rog.mail.re2.yahoo.com with SMTP; 28 Mar 2008 12:07:33 -0000 X-YMail-OSG: mRusEWMVM1nWfKQuLna6zRyreXTJvLZw677dNx6vxqcttZNY6kYN3KkSyMa0VDof_A-- X-Yahoo-Newman-Property: ymail-3 From: "Shahram Davari" To: "'Loa Andersson'" , , "'pwe3'" , , "'L2VPN'" , "'ccamp'" References: <47ECB132.7090200@pi.se> In-Reply-To: <47ECB132.7090200@pi.se> Date: Fri, 28 Mar 2008 08:07:30 -0400 Message-ID: <010901c890cc$4d1e7930$e75b6b90$@org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciQsNan1ooQ8ymLR2m8tExWW3LnNQAGeY7w Content-Language: en-ca X-Mailman-Approved-At: Fri, 28 Mar 2008 17:15:22 -0700 Cc: 'David Ward' Subject: Re: [PWE3] Question on the status of Y.1711 and RFC3429 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Hi Loa, Yes we have implemented the Label 14 in our packet processor/switch chips as requested by our customers. So we suggest using a different label for the new function. = Regards, Shahram Davari | Director, Systems Engineering T|PACK| 9 King's Inn Trail | Markham | Ontario L3T 1T6| Canada Direct: +1 905 597 3125 | Mobile: +1 416 371 3139 | Email: davari@tpack.com = www.tpack.com TPACK=A0CONFIDENTIAL Note: This message and any attachment hereto is intended solely for the use of the designated recipient(s) and their appointed delegates and may contain confidential information. Any unauthorized use, disclosure, copying, or distribution of its contents is strictly prohibited. If you have received this message in error, please destroy it and advise the sender immediately by phone or email Thank you for your cooperation. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Loa Andersson Sent: March-28-08 4:50 AM To: mpls@ietf.org; pwe3; l3vpn@ietf.org; L2VPN; ccamp Cc: Ross Callon; David Ward Subject: Question on the status of Y.1711 and RFC3429 All, In the discussions the IETF and the ITU-T have had on T-MPLS we have discussed the intended use for label 14 and the different documents where this has been specified. As a side effect we've also started to ask ourselves if there are any implementations and/or deployments that uses label 14. A quick survey among known implementers of MPLS has not shown any implementations/deployments. Since one of the approaches discussed in the Joint Working Team context is a solution that requires the allocation of a reserved label and reserved labels are a scarce resource we'd like to know if it possible to redefine label 14 for that particular use. There are still technical issues to be sorted out with the suggested approach, but in the mean time we would like to know if it is possible to deprecate RFC3429 and redefine the OAM Alert Label. The questions is: "Are there any implementations/deployments of Y.1711 or the OAM Alert label as it is allocated in RFC3429; and is there objection to deprecating the protocol as it stands today?" ITU-T has sent out a question along the same lines, see the included mail below. Please respond to the mpls working group mailing list or to the mpls working chairs directly. As usual non-responses will be counted as that there is no implementation/deployment. Loa and George ------------------- included mail ------------------------------------ All users/implementers of recommendation Y.1711, Currently the Joint Working Team of ITU-T and IETF experts is considering the options of using IETF mechanisms to provide OAM for T-MPLS. One possibility is the following mechanism: ------------------------------------------- Push/pop a label at the MEP/domain boundary. This makes the OAM alert label directly visible at the sink MEP. To make the OAM label visible to a MIP the TTL in the server (lower) layer is set by the MEP to expire when the OAM frame reaches the intended MIP. The OAM alert label will point to an =93opcode=94 at the bottom of the stack. ------------------------------------------ This behaviour (when the OAM alert label is received) is not consistent with the behaviour currently defined in Y.1711 when label 14 is received. *QUESTION* are there any users/implementers of the current Y.1711 concerned with this change in behaviour? If there are no concerns then recommendation Y.1711 can be withdrawn or revised to describe the desired behaviour (described above). Please send me (or this list) your response ASAP. Kind regards, Huub van Helvoort, your rapporteur. -- = Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Mar 28 17:20:06 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7703A705F; Fri, 28 Mar 2008 17:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.464 X-Spam-Level: X-Spam-Status: No, score=-101.464 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 FxPE+P3yoQTV; Fri, 28 Mar 2008 17:20:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87CB13A6CA4; Fri, 28 Mar 2008 17:20:05 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD9A3A6CA4 for ; Fri, 28 Mar 2008 17:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 WbDFvbboPlpu for ; Fri, 28 Mar 2008 17:20:02 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 0C8883A6AC1 for ; Fri, 28 Mar 2008 17:20:01 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m2T0JuiQ011781; Fri, 28 Mar 2008 20:19:56 -0400 (EDT) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Fri, 28 Mar 2008 20:19:56 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m2T0JQ0N011197; Fri, 28 Mar 2008 20:19:52 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 20:19:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 20:19:33 -0400 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91016F5E7F@CORPUSMX20A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bandwidth Resources Unavailable Thread-Index: AciRDWx6d7GFOKkDQCWplhLXfWs4/gADuu8QAAKoQwA= References: <47ED4C0C.2050806@cisco.com> To: , X-OriginalArrivalTime: 29 Mar 2008 00:19:41.0511 (UTC) FILETIME=[950D0570:01C89132] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_24 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow Cc: lmartini@cisco.com, pwe3@ietf.org, danny@tcb.net Subject: Re: [PWE3] Bandwidth Resources Unavailable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Stuart, There are two concerns in here: (A) What type of status code? > In the draft-ietf-pwe3-fc-encap you say > = > 6.1.2. Data Sender Protocol = > = > In case the transmission rate is equal to CIR for a period = > greater than RTT, and transmitted frames are still lost in = > transit, as indicated to the sender by receiving SREJ frames, = > the sender SHOULD signal PW status of =ECBandwidth resources = > unavailable=EE (refer to IANA registry of STATUS CODE NAME = > SPACE) as specified in [RFC4447], and SHOULD shut the PW down = > for a duration of at least R_A_TOV, as described in Section = > 6.5 of [RFC3985]. > = > I note that you are talking about a PW status here. Actually, it's not. It's supposed to be an LDP status code for the PW, cf. RFC 4447, Section 7.2. The full name of the IANA Registry is: Status Code Name Spaces which is one of the registries for: Label Distribution Protocol (LDP) Name Spaces This is at http://www.iana.org/assignments/ldp-namespaces, but the URL does not belong in the draft. > but you have been asking about sharing a status code point = > with draft-ietf-pwe3-dynamic-ms-pw-06. [... Large Snip ...] > This seems to me to be referring to a MS PW path status = > rather than a PW status. Not exactly. The dynamic-ms-pw draft has defined an LDP status code: 0x00000037 0 Bandwidth resources unavailable RFCxxxx that appears to be useful for the FC pseudo-wire in general, not just when the FC pseudo-wire is a multi-segment pseudo-wire, hence the attempt to reuse it, which seems to have caused confusion. The good news here is that in contrast to pseudo-wire status codes, LDP status codes are not a scarce resource. Given the confusion that's been caused in trying to reuse that status code, let's just define a new one (3B is the next value available): 0x0000003B 0 Unable to maintain minimum transmission rate RFC= xxxx That should be clearer, and removes the interaction between this draft and the dynamic-ms-pw draft. Does that make sense? When Moran writes "PW status" in his email below, what he means is an LDP status code for the PW. (B) Reaction to running out of bandwdith: > It also seems to me to be heavy weight to tear down the whole = > PW when you run out of PSN bandwidth, rather than simply = > asking it to be quiet for the timeout period. This may need a better explanation in the draft because the situation involves more than running out of PSN bandwidth. The intended use of CIR is that the PSN is provisioned so that bandwidth sufficient to support sending at CIR is always available to the FC PW. If the FC PW detects that it cannot sustain that rate (it's transmitting at CIR and seeing drops, implying congestion), something is seriously wrong because the provisioning assumption has been violated (e.g., provisioning didn't anticipate a backhoe event at *that* location). If this situation is sustained, the FC PW needs to come down because continuing to transmit at CIR risks damage to the network. What the draft currently says is that when CIR can't be maintained, the PW is torn down for a timeout (R_A_TOV, usually 10 seconds), and then set back up. If the PW goes down again within the same timeout for inability to maintain CIR, the PW stays down. At the PW level, it's probably more efficient to have the PW go silent the first time, but the second time around the PW needs to be torn down so that the logical FC link that is using it is taken down and FC reacts accordingly. I think an FC inter-switch link will usually ride through an R_A_TOV outage, as it takes over 80 seconds of non-responsiveness for FC to take it down, but the non-responsiveness will probably cause some FC errors. So, I think the answers to your questions are: > So should which should we be using - > = > 1) a dedicated PW status bit from > Registry Name: Pseudo Wire Status Codes Registry or > = > 2) a new LDP status code or > = > 3) the LDP status code proposed in draft-ietf-pwe3-dynamic-ms-pw-06 Let's use a new LDP status code for simplicity. > and should we be tearing down the whole PW, or simply telling = > it to be quiet? It should go quiet for the first R_A_TOV timeout, but if it fails to maintain CIR within that timeout after restarting, it needs to be torn down. While I'm thinking about it, let me go check with some FC experts about whether R_A_TOV is the right timeout for this purpose. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Moran Roth [mailto:moranr@corrigent.com] = > Sent: Friday, March 28, 2008 5:57 PM > To: stbryant@cisco.com; Black, David > Cc: pwe3; Luca Martini (lmartini); Danny McPherson > Subject: RE: Bandwidth Resources Unavailable > = > Stewart, > = > The draft states that in case of severe congestion the PW = > should be teardown for a duration of at least R_A_TOV. It = > also should indicate insufficient bandwidth. > My intention is to use the same status code proposed in = > draft-ietf-pwe3-dynamic-ms-pw-06, however in MS-PW this = > indication is used during setup, and in FC-PW to indicate a = > failure after the PW is up and running. > I would be happy to here more opinions on whether this is = > allowed or we should define a new PW status to indicate = > insufficient bandwidth for PW operation. > = > Best Regards, > Moran > = > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] = > Sent: Friday, March 28, 2008 12:51 PM > To: Moran Roth; Black_David@emc.com > Cc: pwe3; Luca Martini (lmartini); Danny McPherson > Subject: Bandwidth Resources Unavailable > = > Moran, David, > = > In the draft-ietf-pwe3-fc-encap you say > = > 6.1.2. Data Sender Protocol = > = > In case the transmission rate is equal to CIR for a period = > greater than RTT, and transmitted frames are still lost in = > transit, as indicated to the sender by receiving SREJ frames, = > the sender SHOULD signal PW status of =ECBandwidth resources = > unavailable=EE (refer to IANA registry of STATUS CODE NAME = > SPACE) as specified in [RFC4447], and SHOULD shut the PW down = > for a duration of at least R_A_TOV, as described in Section = > 6.5 of [RFC3985]. > = > I note that you are talking about a PW status here. > = > but you have been asking about sharing a status code point = > with draft-ietf-pwe3-dynamic-ms-pw-06. > = > However this draft says > = > In the case where PSN resources towards the previous hop are not > available the following procedure MUST be followed: > = > -iii. If the S-PE cannot get enough resources to setup = > the segment > in the MS-PW a label release MUST be returned to the > previous hop with a status message of "Bandwidth resources > unavailable" > = > and in its IANA section it says > = > = > = > 11.1. LDP Status Codes > = > = > = > This document uses several new LDP status codes, IANA already = > maintains a registry of name "STATUS CODE NAME SPACE" defined by > RFC3036 . The following = > values have been pre-allocated: > = > Range/Value E Description Reference > ------------- ----- ---------------------- --------- > 0x00000037 0 Bandwidth resources unavailable RFCxxxx > 0x00000038 0 Resources Unavailable RFCxxxx > 0x00000039 0 AII Unreachable RFCxxxx > 0x0000003A 0 PW Loop Detected RFCxxxx > = > = > This seems to me to be referring to a MS PW path status = > rather than a PW status. > = > It also seems to me to be heavy wieght to tear down the whole = > PW when you run out of PSN bandwidth, rather than simply = > asking it to be quiet for the timeout period. > = > So should which should we be using - > = > 1) a dedicated PW status bit from > Registry Name: Pseudo Wire Status Codes Registry or > = > 2) a new LDP status code or > = > 3) the LDP status code proposed in draft-ietf-pwe3-dynamic-ms-pw-06 > = > and should we be tearing down the whole PW, or simply telling = > it to be quiet? > = > Regards > = > Stewart > = > = > = > = > = > = > = > = > = > = > = _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Mar 28 17:30:38 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9496B3A68E6; Fri, 28 Mar 2008 17:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.727 X-Spam-Level: X-Spam-Status: No, score=-100.727 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 CQRkUewPs9Rq; Fri, 28 Mar 2008 17:30:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6DF3A69C8; Fri, 28 Mar 2008 17:30:36 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ACFB3A69C8 for ; Fri, 28 Mar 2008 17:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 9Tc27yrcRMnA for ; Fri, 28 Mar 2008 17:30:34 -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 8045D3A68E6 for ; Fri, 28 Mar 2008 17:30:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,573,1199660400"; d="scan'208";a="4770284" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2008 01:30:31 +0100 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 m2T0UVwt028476; Sat, 29 Mar 2008 01:30:31 +0100 Received: from stewart-bryants-computer.local (dhcp-10-61-96-59.cisco.com [10.61.96.59]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2T0UVgp027618; Sat, 29 Mar 2008 00:30:31 GMT Message-ID: <47ED8DA9.5030405@cisco.com> Date: Sat, 29 Mar 2008 00:30:33 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Black_David@emc.com References: <47ED4C0C.2050806@cisco.com> <8CC6CEAB44F131478D3A7B429ECACD91016F5E7F@CORPUSMX20A.corp.emc.com> In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91016F5E7F@CORPUSMX20A.corp.emc.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9457; t=1206750631; x=1207614631; 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:=20Re=3A=20Bandwidth=20Resources=20Unavailable |Sender:=20; bh=vxC+aZdjWlV9yhbb8ABjI/wEtFwPvilfrhLzq34W21I=; b=KjVuYhlyrBa6QprL7BVwhibC807bS4SmxR2ED9alOE3/WOSfo35d5lll/n Lc/WPgcYtst/3F+vJkqD6frFovAEV6hxFeG8IvfJvCTwFOXlm8c0jDNu4yKa yjttR6Bn52; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: lmartini@cisco.com, pwe3@ietf.org, danny@tcb.net Subject: Re: [PWE3] Bandwidth Resources Unavailable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org David Thanks for the clarifications - I think that they need to go in the = draft to clarify things. R_A_TOV is still a number pulled out of a hat - I could not see the definition in the draft, but whatever number you use you really need to define the name and either use or point to the rational for its value. Black_David@emc.com wrote: > Stuart, > > There are two concerns in here: > > (A) What type of status code? > > = >> In the draft-ietf-pwe3-fc-encap you say >> >> 6.1.2. Data Sender Protocol = >> = >> In case the transmission rate is equal to CIR for a period = >> greater than RTT, and transmitted frames are still lost in = >> transit, as indicated to the sender by receiving SREJ frames, = >> the sender SHOULD signal PW status of =ECBandwidth resources = >> unavailable=EE (refer to IANA registry of STATUS CODE NAME = >> SPACE) as specified in [RFC4447], and SHOULD shut the PW down = >> for a duration of at least R_A_TOV, as described in Section = >> 6.5 of [RFC3985]. >> >> I note that you are talking about a PW status here. >> = > > Actually, it's not. It's supposed to be an LDP status code for > the PW, cf. RFC 4447, Section 7.2. The full name of the IANA > Registry is: > Status Code Name Spaces > which is one of the registries for: > Label Distribution Protocol (LDP) Name Spaces > > This is at http://www.iana.org/assignments/ldp-namespaces, but > the URL does not belong in the draft. > > = >> but you have been asking about sharing a status code point = >> with draft-ietf-pwe3-dynamic-ms-pw-06. >> = > > [... Large Snip ...] > > = >> This seems to me to be referring to a MS PW path status = >> rather than a PW status. >> = > > Not exactly. The dynamic-ms-pw draft has defined an LDP > status code: > > 0x00000037 0 Bandwidth resources unavailable RFCxxxx > > that appears to be useful for the FC pseudo-wire in general, > not just when the FC pseudo-wire is a multi-segment pseudo-wire, > hence the attempt to reuse it, which seems to have caused > confusion. > > The good news here is that in contrast to pseudo-wire status > codes, LDP status codes are not a scarce resource. Given the > confusion that's been caused in trying to reuse that status code, > let's just define a new one (3B is the next value available): > > 0x0000003B 0 Unable to maintain minimum transmission rate R= FCxxxx > > That should be clearer, and removes the interaction between this > draft and the dynamic-ms-pw draft. Does that make sense? > = I agree > When Moran writes "PW status" in his email below, what he means > is an LDP status code for the PW. > > (B) Reaction to running out of bandwdith: > > = >> It also seems to me to be heavy weight to tear down the whole = >> PW when you run out of PSN bandwidth, rather than simply = >> asking it to be quiet for the timeout period. >> = > > This may need a better explanation in the draft because the situation > involves more than running out of PSN bandwidth. The intended use of > CIR is that the PSN is provisioned so that bandwidth sufficient to > support sending at CIR is always available to the FC PW. If the FC PW > detects that it cannot sustain that rate (it's transmitting at CIR and > seeing drops, implying congestion), something is seriously wrong because > the provisioning assumption has been violated (e.g., provisioning > didn't anticipate a backhoe event at *that* location). If this > situation is sustained, the FC PW needs to come down because > continuing to transmit at CIR risks damage to the network. > > What the draft currently says is that when CIR can't be maintained, the > PW is torn down for a timeout (R_A_TOV, usually 10 seconds), and then > set back up. If the PW goes down again within the same timeout for > inability to maintain CIR, the PW stays down. At the PW level, it's > probably more efficient to have the PW go silent the first time, but > the second time around the PW needs to be torn down so that the logical > FC link that is using it is taken down and FC reacts accordingly. I > think an FC inter-switch link will usually ride through an R_A_TOV > outage, as it takes over 80 seconds of non-responsiveness for FC to > take it down, but the non-responsiveness will probably cause some FC > errors. > > So, I think the answers to your questions are: > > = >> So should which should we be using - >> >> 1) a dedicated PW status bit from >> Registry Name: Pseudo Wire Status Codes Registry or >> >> 2) a new LDP status code or >> >> 3) the LDP status code proposed in draft-ietf-pwe3-dynamic-ms-pw-06 >> = > > Let's use a new LDP status code for simplicity. > = OK - we will do that. > = >> and should we be tearing down the whole PW, or simply telling = >> it to be quiet? >> = > > It should go quiet for the first R_A_TOV timeout, but if it fails to > maintain CIR within that timeout after restarting, it needs to be > torn down. > = OK > While I'm thinking about it, let me go check with some FC experts > about whether R_A_TOV is the right timeout for this purpose. > > = Let us know what you come up with, but the fact that you need to look = into it suggests that some explanatory material is needed in the draft. Stewart > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > = >> -----Original Message----- >> From: Moran Roth [mailto:moranr@corrigent.com] = >> Sent: Friday, March 28, 2008 5:57 PM >> To: stbryant@cisco.com; Black, David >> Cc: pwe3; Luca Martini (lmartini); Danny McPherson >> Subject: RE: Bandwidth Resources Unavailable >> >> Stewart, >> >> The draft states that in case of severe congestion the PW = >> should be teardown for a duration of at least R_A_TOV. It = >> also should indicate insufficient bandwidth. >> My intention is to use the same status code proposed in = >> draft-ietf-pwe3-dynamic-ms-pw-06, however in MS-PW this = >> indication is used during setup, and in FC-PW to indicate a = >> failure after the PW is up and running. >> I would be happy to here more opinions on whether this is = >> allowed or we should define a new PW status to indicate = >> insufficient bandwidth for PW operation. >> >> Best Regards, >> Moran >> >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] = >> Sent: Friday, March 28, 2008 12:51 PM >> To: Moran Roth; Black_David@emc.com >> Cc: pwe3; Luca Martini (lmartini); Danny McPherson >> Subject: Bandwidth Resources Unavailable >> >> Moran, David, >> >> In the draft-ietf-pwe3-fc-encap you say >> >> 6.1.2. Data Sender Protocol = >> = >> In case the transmission rate is equal to CIR for a period = >> greater than RTT, and transmitted frames are still lost in = >> transit, as indicated to the sender by receiving SREJ frames, = >> the sender SHOULD signal PW status of =ECBandwidth resources = >> unavailable=EE (refer to IANA registry of STATUS CODE NAME = >> SPACE) as specified in [RFC4447], and SHOULD shut the PW down = >> for a duration of at least R_A_TOV, as described in Section = >> 6.5 of [RFC3985]. >> >> I note that you are talking about a PW status here. >> >> but you have been asking about sharing a status code point = >> with draft-ietf-pwe3-dynamic-ms-pw-06. >> >> However this draft says >> >> In the case where PSN resources towards the previous hop are not >> available the following procedure MUST be followed: >> >> -iii. If the S-PE cannot get enough resources to setup = >> the segment >> in the MS-PW a label release MUST be returned to the >> previous hop with a status message of "Bandwidth resources >> unavailable" >> >> and in its IANA section it says >> >> >> >> 11.1. LDP Status Codes >> >> >> >> This document uses several new LDP status codes, IANA already = >> maintains a registry of name "STATUS CODE NAME SPACE" defined by >> RFC3036 . The following = >> values have been pre-allocated: >> >> Range/Value E Description Reference >> ------------- ----- ---------------------- --------- >> 0x00000037 0 Bandwidth resources unavailable RFCxxxx >> 0x00000038 0 Resources Unavailable RFCxxxx >> 0x00000039 0 AII Unreachable RFCxxxx >> 0x0000003A 0 PW Loop Detected RFCxxxx >> >> >> This seems to me to be referring to a MS PW path status = >> rather than a PW status. >> >> It also seems to me to be heavy wieght to tear down the whole = >> PW when you run out of PSN bandwidth, rather than simply = >> asking it to be quiet for the timeout period. >> >> So should which should we be using - >> >> 1) a dedicated PW status bit from >> Registry Name: Pseudo Wire Status Codes Registry or >> >> 2) a new LDP status code or >> >> 3) the LDP status code proposed in draft-ietf-pwe3-dynamic-ms-pw-06 >> >> and should we be tearing down the whole PW, or simply telling = >> it to be quiet? >> >> Regards >> >> Stewart >> >> >> >> >> >> >> >> >> = >> >> >> = > > > = _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Mar 28 17:35:12 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231673A6D60; Fri, 28 Mar 2008 17:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.097 X-Spam-Level: X-Spam-Status: No, score=-101.097 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 gRz17mkZEc0a; Fri, 28 Mar 2008 17:35:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36F33A6D04; Fri, 28 Mar 2008 17:35:09 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A6B3A6EBB for ; Fri, 28 Mar 2008 17:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 XCq6v-zN1-dc for ; Fri, 28 Mar 2008 17:35:07 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 3E7043A6AD5 for ; Fri, 28 Mar 2008 17:35:07 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m2T0Z2o7017509; Fri, 28 Mar 2008 20:35:02 -0400 (EDT) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Fri, 28 Mar 2008 20:35:02 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m2T0YKnA022233; Fri, 28 Mar 2008 20:34:58 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 20:34:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 20:34:29 -0400 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91016F5E80@CORPUSMX20A.corp.emc.com> In-Reply-To: <47ED8DA9.5030405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bandwidth Resources Unavailable Thread-Index: AciRNCIoVXi+oM/yQoKRfP3y/AT3zgAABQtg References: <47ED4C0C.2050806@cisco.com> <8CC6CEAB44F131478D3A7B429ECACD91016F5E7F@CORPUSMX20A.corp.emc.com> <47ED8DA9.5030405@cisco.com> To: X-OriginalArrivalTime: 29 Mar 2008 00:34:49.0763 (UTC) FILETIME=[B2694730:01C89134] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_24 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow Cc: lmartini@cisco.com, pwe3@ietf.org, danny@tcb.net Subject: Re: [PWE3] Bandwidth Resources Unavailable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org > R_A_TOV is still a number pulled out of a hat - I could not see > the definition in the draft, but whatever number you use you > really need to define the name and either use or point to the > rational for its value. Indeed it is - I pulled it out of my hat. One of my last call comments was that the FC standard that defines it needs to be cited, and I'm about to go double-check the reasoning behind R_A_TOV with FC experts, and will supply the result and explanation to Moran for inclusion in the draft. Thanks, --David > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] = > Sent: Friday, March 28, 2008 8:31 PM > To: Black, David > Cc: moranr@corrigent.com; pwe3@ietf.org; lmartini@cisco.com; = > danny@tcb.net > Subject: Re: Bandwidth Resources Unavailable > = > David > = > Thanks for the clarifications - I think that they need to go in the = > draft to clarify things. > = > R_A_TOV is still a number pulled out of a hat - I could not see > the definition in the draft, but whatever number you use you > really need to define the name and either use or point to the > rational for its value. > = > = > = > = > = > Black_David@emc.com wrote: > > Stuart, > > > > There are two concerns in here: > > > > (A) What type of status code? > > > > = > >> In the draft-ietf-pwe3-fc-encap you say > >> > >> 6.1.2. Data Sender Protocol = > >> = > >> In case the transmission rate is equal to CIR for a period = > >> greater than RTT, and transmitted frames are still lost in = > >> transit, as indicated to the sender by receiving SREJ frames, = > >> the sender SHOULD signal PW status of =ECBandwidth resources = > >> unavailable=EE (refer to IANA registry of STATUS CODE NAME = > >> SPACE) as specified in [RFC4447], and SHOULD shut the PW down = > >> for a duration of at least R_A_TOV, as described in Section = > >> 6.5 of [RFC3985]. > >> > >> I note that you are talking about a PW status here. > >> = > > > > Actually, it's not. It's supposed to be an LDP status code for > > the PW, cf. RFC 4447, Section 7.2. The full name of the IANA > > Registry is: > > Status Code Name Spaces > > which is one of the registries for: > > Label Distribution Protocol (LDP) Name Spaces > > > > This is at http://www.iana.org/assignments/ldp-namespaces, but > > the URL does not belong in the draft. > > > > = > >> but you have been asking about sharing a status code point = > >> with draft-ietf-pwe3-dynamic-ms-pw-06. > >> = > > > > [... Large Snip ...] > > > > = > >> This seems to me to be referring to a MS PW path status = > >> rather than a PW status. > >> = > > > > Not exactly. The dynamic-ms-pw draft has defined an LDP > > status code: > > > > 0x00000037 0 Bandwidth resources unavailable RFCxxxx > > > > that appears to be useful for the FC pseudo-wire in general, > > not just when the FC pseudo-wire is a multi-segment pseudo-wire, > > hence the attempt to reuse it, which seems to have caused > > confusion. > > > > The good news here is that in contrast to pseudo-wire status > > codes, LDP status codes are not a scarce resource. Given the > > confusion that's been caused in trying to reuse that status code, > > let's just define a new one (3B is the next value available): > > > > 0x0000003B 0 Unable to maintain minimum = > transmission rate RFCxxxx > > > > That should be clearer, and removes the interaction between this > > draft and the dynamic-ms-pw draft. Does that make sense? > > = > I agree > > When Moran writes "PW status" in his email below, what he means > > is an LDP status code for the PW. > > > > (B) Reaction to running out of bandwdith: > > > > = > >> It also seems to me to be heavy weight to tear down the whole = > >> PW when you run out of PSN bandwidth, rather than simply = > >> asking it to be quiet for the timeout period. > >> = > > > > This may need a better explanation in the draft because the = > situation > > involves more than running out of PSN bandwidth. The = > intended use of > > CIR is that the PSN is provisioned so that bandwidth sufficient to > > support sending at CIR is always available to the FC PW. = > If the FC PW > > detects that it cannot sustain that rate (it's transmitting = > at CIR and > > seeing drops, implying congestion), something is seriously = > wrong because > > the provisioning assumption has been violated (e.g., provisioning > > didn't anticipate a backhoe event at *that* location). If this > > situation is sustained, the FC PW needs to come down because > > continuing to transmit at CIR risks damage to the network. > > > > What the draft currently says is that when CIR can't be = > maintained, the > > PW is torn down for a timeout (R_A_TOV, usually 10 = > seconds), and then > > set back up. If the PW goes down again within the same timeout for > > inability to maintain CIR, the PW stays down. At the PW level, it's > > probably more efficient to have the PW go silent the first time, but > > the second time around the PW needs to be torn down so that = > the logical > > FC link that is using it is taken down and FC reacts accordingly. I > > think an FC inter-switch link will usually ride through an R_A_TOV > > outage, as it takes over 80 seconds of non-responsiveness for FC to > > take it down, but the non-responsiveness will probably cause some FC > > errors. > > > > So, I think the answers to your questions are: > > > > = > >> So should which should we be using - > >> > >> 1) a dedicated PW status bit from > >> Registry Name: Pseudo Wire Status Codes Registry or > >> > >> 2) a new LDP status code or > >> > >> 3) the LDP status code proposed in draft-ietf-pwe3-dynamic-ms-pw-06 > >> = > > > > Let's use a new LDP status code for simplicity. > > = > OK - we will do that. > > = > >> and should we be tearing down the whole PW, or simply telling = > >> it to be quiet? > >> = > > > > It should go quiet for the first R_A_TOV timeout, but if it fails to > > maintain CIR within that timeout after restarting, it needs to be > > torn down. > > = > OK > > While I'm thinking about it, let me go check with some FC experts > > about whether R_A_TOV is the right timeout for this purpose. > > > > = > Let us know what you come up with, but the fact that you need to look = > into it > suggests that some explanatory material is needed in the draft. > = > Stewart > = > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > = > >> -----Original Message----- > >> From: Moran Roth [mailto:moranr@corrigent.com] = > >> Sent: Friday, March 28, 2008 5:57 PM > >> To: stbryant@cisco.com; Black, David > >> Cc: pwe3; Luca Martini (lmartini); Danny McPherson > >> Subject: RE: Bandwidth Resources Unavailable > >> > >> Stewart, > >> > >> The draft states that in case of severe congestion the PW = > >> should be teardown for a duration of at least R_A_TOV. It = > >> also should indicate insufficient bandwidth. > >> My intention is to use the same status code proposed in = > >> draft-ietf-pwe3-dynamic-ms-pw-06, however in MS-PW this = > >> indication is used during setup, and in FC-PW to indicate a = > >> failure after the PW is up and running. > >> I would be happy to here more opinions on whether this is = > >> allowed or we should define a new PW status to indicate = > >> insufficient bandwidth for PW operation. > >> > >> Best Regards, > >> Moran > >> > >> -----Original Message----- > >> From: Stewart Bryant [mailto:stbryant@cisco.com] = > >> Sent: Friday, March 28, 2008 12:51 PM > >> To: Moran Roth; Black_David@emc.com > >> Cc: pwe3; Luca Martini (lmartini); Danny McPherson > >> Subject: Bandwidth Resources Unavailable > >> > >> Moran, David, > >> > >> In the draft-ietf-pwe3-fc-encap you say > >> > >> 6.1.2. Data Sender Protocol = > >> = > >> In case the transmission rate is equal to CIR for a period = > >> greater than RTT, and transmitted frames are still lost in = > >> transit, as indicated to the sender by receiving SREJ frames, = > >> the sender SHOULD signal PW status of =ECBandwidth resources = > >> unavailable=EE (refer to IANA registry of STATUS CODE NAME = > >> SPACE) as specified in [RFC4447], and SHOULD shut the PW down = > >> for a duration of at least R_A_TOV, as described in Section = > >> 6.5 of [RFC3985]. > >> > >> I note that you are talking about a PW status here. > >> > >> but you have been asking about sharing a status code point = > >> with draft-ietf-pwe3-dynamic-ms-pw-06. > >> > >> However this draft says > >> > >> In the case where PSN resources towards the previous hop are not > >> available the following procedure MUST be followed: > >> > >> -iii. If the S-PE cannot get enough resources to setup = > >> the segment > >> in the MS-PW a label release MUST be returned to the > >> previous hop with a status message of = > "Bandwidth resources > >> unavailable" > >> > >> and in its IANA section it says > >> > >> > >> > >> 11.1. LDP Status Codes > >> > >> > >> > >> This document uses several new LDP status codes, IANA already = > >> maintains a registry of name "STATUS CODE NAME SPACE" defined by > >> RFC3036 . The following = > >> values have been pre-allocated: > >> > >> Range/Value E Description Reference > >> ------------- ----- ---------------------- --------- > >> 0x00000037 0 Bandwidth resources unavailable RFCxxxx > >> 0x00000038 0 Resources Unavailable RFCxxxx > >> 0x00000039 0 AII Unreachable RFCxxxx > >> 0x0000003A 0 PW Loop Detected RFCxxxx > >> > >> > >> This seems to me to be referring to a MS PW path status = > >> rather than a PW status. > >> > >> It also seems to me to be heavy wieght to tear down the whole = > >> PW when you run out of PSN bandwidth, rather than simply = > >> asking it to be quiet for the timeout period. > >> > >> So should which should we be using - > >> > >> 1) a dedicated PW status bit from > >> Registry Name: Pseudo Wire Status Codes Registry or > >> > >> 2) a new LDP status code or > >> > >> 3) the LDP status code proposed in draft-ietf-pwe3-dynamic-ms-pw-06 > >> > >> and should we be tearing down the whole PW, or simply telling = > >> it to be quiet? > >> > >> Regards > >> > >> Stewart > >> > >> > >> > >> > >> > >> > >> > >> > >> = > >> > >> > >> = > > > > > > = > = > = > = _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Mar 28 18:55:19 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487D03A6E14; Fri, 28 Mar 2008 18:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.122 X-Spam-Level: X-Spam-Status: No, score=-101.122 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 foyKmt+S2s5l; Fri, 28 Mar 2008 18:55:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BFF93A6BAA; Fri, 28 Mar 2008 18:55:15 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77A43A68BA for ; Fri, 28 Mar 2008 18:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 y-jKT28vs-C8 for ; Fri, 28 Mar 2008 18:55:13 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id E16823A6B89 for ; Fri, 28 Mar 2008 18:55:12 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m2T1sf0T011041; Fri, 28 Mar 2008 21:54:41 -0400 (EDT) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Fri, 28 Mar 2008 21:54:40 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m2T1sbvK029755; Fri, 28 Mar 2008 21:54:37 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 21:54:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 21:53:41 -0400 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91016F5E83@CORPUSMX20A.corp.emc.com> In-Reply-To: <47ED89BC.8040108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pwe3-fc-encap-07 - congestion control Thread-Index: AciRMco37wJgosanRYOtgr4g+c7k4QAAgo1g References: <47ED89BC.8040108@cisco.com> To: , X-OriginalArrivalTime: 29 Mar 2008 01:54:37.0793 (UTC) FILETIME=[D84CAD10:01C8913F] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow Cc: townsley@cisco.com, pwe3@ietf.org, danny@tcb.net Subject: [PWE3] draft-ietf-pwe3-fc-encap-07 - congestion control X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org > I have just re-read draft-ietf-pwe3-fc-encap-07.txt > > > Most of this is just editorial. One comment: > > FC PW traffic can traverse controlled (i.e., providing committed > information rate for the service) networks and uncontrolled (i.e., > providing excess information rate for the service) networks. In case > of FC PW traversing an uncontrolled network, it SHOULD provide TCP- > friendly behavior under network congestion (refer to Congestion > Control section for further details). > Why SHOULD and not MUST? I think that's going to need to be a MUST, congestion control needs to be a MUST, even for controlled networks (even if EIR = CIR, the congestion control mechanisms are what look for lost frames indicating that CIR cannot be maintained), and the shutdown procedures when CIR cannot be retained also need to be a MUST. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sat Mar 29 12:04:08 2008 Return-Path: X-Original-To: ietfarch-pwe3-archive@core3.amsl.com Delivered-To: ietfarch-pwe3-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79D728C33C; Sat, 29 Mar 2008 12:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.217 X-Spam-Level: X-Spam-Status: No, score=-100.217 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 c--prC4Ih-oe; Sat, 29 Mar 2008 12:04:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C98C3A6F48; Sat, 29 Mar 2008 12:03:26 -0700 (PDT) X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C131628C15C for ; Sat, 29 Mar 2008 12:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 wKWCgQs3vkTf for ; Sat, 29 Mar 2008 12:03:20 -0700 (PDT) Received: from snsmtpstl04.stifel.com (snsmtpstl04.stifel.com [63.122.89.12]) by core3.amsl.com (Postfix) with ESMTP id CE70528C4C2 for ; Sat, 29 Mar 2008 12:03:00 -0700 (PDT) Received: from SNEXGCON01SB.stifelnet.stifel.local (snexgcon01sb.stifelnet.stifel.local [172.27.7.111]) by snsmtpstl04.stifel.com (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Sat, 29 Mar 2008 14:02:59 -0500 Received: from SNEXGMB01.stifelnet.stifel.local ([172.28.240.17]) by SNEXGCON01SB.stifelnet.stifel.local with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 Mar 2008 14:02:59 -0500 Received: from 172.26.3.105 ([172.26.3.105]) by SNEXGMB01.stifelnet.stifel.local ([172.28.240.49]) with Microsoft Exchange Server HTTP-DAV ; Sat, 29 Mar 2008 19:02:59 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sat, 29 Mar 2008 14:02:58 -0500 From: mike winslow To: Message-ID: Thread-Topic: Help Thread-Index: AciRzyUywUWbT5G0TEe8eNTFXFg/RQAAFtLN In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 29 Mar 2008 19:02:59.0389 (UTC) FILETIME=[81510ED0:01C891CF] Subject: [PWE3] Help X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0462437267==" Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0462437267== Content-type: multipart/alternative; boundary="B_3289644178_653422" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3289644178_653422 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Unsubscribe ******************************************************************************** All electronic messages sent and received by Stifel Nicolaus Associates are subject to review by Stifel Nicolaus. Stifel Nicolaus may retain and reproduce electronic messages for state, federal, or other regulatory agencies as required by applicable law. IMPORTANT: Please do not use e-mail to request or authorize the purchase or sale of any security or commodity, send fund transfer instructions, or otherwise conduct any securities transactions. Any requests, orders, instructions, or time-sensitive messages sent by e-mail cannot be accepted or processed by Stifel Nicolaus. The accuracy of any information sent by Stifel Nicolaus through e-mail cannot be warranted or guaranteed by Stifel Nicolaus or its affiliates. Stifel, Nicolaus & Company, Incorporated Member NYSE & SIPC Headquarters: 501 N. Broadway, St. Louis, MO 63102 314-342-2000 ******************************************************************************** --B_3289644178_653422 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: quoted-printable Help
Unsubscribe

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

All electronic messag= es sent and received by Stifel Nicolaus

Associates are subjec= t to review by Stifel Nicolaus. Stifel Nicolaus

may retain and reprod= uce electronic messages for state, federal, or

other regulatory agen= cies as required by applicable law.

IMPORTANT: Please do = not use e-mail to request or authorize the

purchase or sale of a= ny security or commodity, send fund transfer

instructions, or othe= rwise conduct any securities transactions. Any

requests, orders, ins= tructions, or time-sensitive messages sent by

e-mail cannot be acce= pted or processed by Stifel Nicolaus. The

accuracy of any infor= mation sent by Stifel Nicolaus through e-mail

cannot be warranted o= r guaranteed by Stifel Nicolaus or its affiliates.

Stifel, Nicolaus &= ; Company, Incorporated

Member NYSE & SIP= C

Headquarters: 501 N.= Broadway, St. Louis, MO 63102

314-342-2000

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

 

--B_3289644178_653422-- --===============0462437267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --===============0462437267==--