From ietf-ipr@ietf.org Tue May 31 09:37:32 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4900CE07E6; Tue, 31 May 2011 09:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3I5bP96mFsv; Tue, 31 May 2011 09:37:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2A9E0795; Tue, 31 May 2011 09:37:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat <"ietf-ipr@ietf.org"@ietfa.amsl.com> To: Mustapha.aissaoui@Alcatel-lucent.com, florin.balus@alcatel-lucent.com, matthew.bocci@alcatel-lucent.com, mduckett@bellsouth.net, lmartini@cisco.com, chmetz@cisco.com, tnadeau@lucidvision.com, X-Test-IDTracker: no Message-ID: <20110531163726.28776.73969.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2011 09:37:26 -0700 X-Mailman-Approved-At: Wed, 01 Jun 2011 15:17:55 -0700 Cc: housley@vigilsec.com, pwe3@ietf.org, andrew.g.malis@verizon.com, ipr-announce@ietf.org, stbryant@cisco.com Subject: [PWE3] IPR Disclosure: Alcatel Lucent's Statement of IPR Related to RFC 6073 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:37:32 -0000 Dear Mustapha Aissaoui, Florin Balus, Matthew Bocci, Michael Duckett, Luca = Martini, Chris Metz, Thomas Nadeau: An IPR disclosure that pertains to your RFC entitled "Segmented Pseudowire" (RFC6073) was submitted to the IETF Secretariat on 2011-05-26 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1566/). The title of the IPR disclosure is "Alcatel Lucent's Statement of IPR Related to RFC 6073.""); The IETF Secretariat From matthew.bocci@alcatel-lucent.com Thu Jun 2 02:12:51 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB29E0718 for ; Thu, 2 Jun 2011 02:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.249 X-Spam-Level: X-Spam-Status: No, score=-104.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj7n7E8+SNST for ; Thu, 2 Jun 2011 02:12:51 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id D2125E0697 for ; Thu, 2 Jun 2011 02:12:48 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p529Cid5025608 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 2 Jun 2011 11:12:46 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 2 Jun 2011 11:12:46 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Thu, 2 Jun 2011 11:12:42 +0200 Thread-Topic: WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt Thread-Index: AcwhBTuuGB0/lJDuRQuHdtzUjAzUPQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA0D129A10507matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 09:12:51 -0000 --_000_CA0D129A10507matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that = this draft be adopted as a PWE3 working group draft. This email begins a two week poll of the list to help judge if there is con= sensus to adopt the draft. Please review the draft and reply to the PWE3 list stating whether you supp= ort adoption, together with any comments. Regards, Matthew --_000_CA0D129A10507matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The authors of draf= t-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that this draft be adopt= ed as a PWE3 working group draft.

This email begin= s a two week poll of the list to help judge if there is consensus to adopt = the draft.

Please review the draft and reply to th= e PWE3 list stating whether you support adoption, together with any comment= s.

Regards,

Matthew
= --_000_CA0D129A10507matthewboccialcatellucentcom_-- From Alexander.Vainshtein@ecitele.com Thu Jun 2 07:00:15 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BF9E0787 for ; Thu, 2 Jun 2011 07:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMSfHTwb6bKW for ; Thu, 2 Jun 2011 07:00:14 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEC5E065B for ; Thu, 2 Jun 2011 07:00:13 -0700 (PDT) X-AuditID: 93eaf2e8-b7b4fae00000179b-22-4de797074625 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id FE.02.06043.70797ED4; Thu, 2 Jun 2011 16:58:31 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 2 Jun 2011 17:00:11 +0300 From: Alexander Vainshtein To: "Praveen.muley@alcatel-lucent.com" , "mustapha.aissaoui@alcatel-lucent.com" Date: Thu, 2 Jun 2011 17:00:10 +0300 Thread-Topic: draft-ietf-pwe3-redundancy? Thread-Index: AcwhLWLc82QLF/v0TA+rKmMbQ9x4NA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76E9BDB8AF57ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTbUgTYRznudvmuXZxzrfHEbGuKKwmW5bOatGXwD6IlhYUQV3b0+5ou1u7 Fc6ChAxJsDdJc0gtMCsNFTMQllTqh7JIjcBeFdO0tKxkZBZqdzs0IXo+/Z7/7+X+9/D/E7j+ s8ZAcLwPeXnGRWu0qrLRibApqmIkyxx8lm4tulKPWftu1KisZyeaVVvxzNPDrerM6uopLAfb Wwg2Mzwv+BgfMjqQaLfROV7uGGP300bOYaMttNHjYuzIjXifjWY8HsQ76C1a4z9nsyTjeCPi 7YKD4502entutslq3ZBhstBbVi63pG7S5rGcaEQmN8O5jG4kiowTGaXKgWac7XrcofY0Ls3/ HgqCQvDbUAKiCUith8HKHo2CE2B3X0ME66kQgG0NQgnQSvgSgHcujUcIDWWDTXXvNDIRRwUA fPEhiMsXnOoB8FTXV0xWqagVsK7rbsQRK+FXz1sj9TgqGRa2X1crOAUOnLsPZExS2fBG5YxK xkBqY7LzdkSPU4nw9dBVTGmPgtX3unAFx8NPgzNqRR8P3xY3AEUvwEfdvZiSGQMfVw6pFH0S fHjzpeo8iAssiA0ssAQWWJT6WhgMTWgUvAbWXBvD5/DTB4PYwnoQRNWCeM7l8R10O83rUpCd 8yEXSrEL7iagjMrHFvDmaXIboAhA68iWluEsvZo5JvrdbSCJwOh4Mrl8JEu/+KDg8LOMyO73 HnUhsQ1AAqfjyFq/xJEOxl+AvMIctU165Qu4YZFdkIaS9+1PNZv/f6ETyY4rg1l6yinN4GGE PMg7l7OEIGhIfpY/H+NFTpR/iHP5/tIYES23oZPaiK6Q2xA9jFvknArfCZYZEsmwbKZkgj3K z3vlJTk5Ozs7ChKln44lE2S7TlqhefeoFIxJweZVkWBpP+YpQyHYPX689kPPWBmLqkK67kP7 Xrf2Nh6uGjphCOw5w/eWp81siKr/9vN6v+lJoKcvOtRZcFPMK8vDCy6f6n/Dfiv6sXNAn16q +8KmhZ9P6YunM5rLi8b3dXYkl9alVpRaciYCuTuyr9Yd2XiLfi/WgF+xu7SZwen2cPv9cIxQ Uj55kVaJLGNZjXtF5g+iyOuF/wMAAA== Cc: Manish Vora , "pwe3@ietf.org" , Robert Rennison , Rotem Cohen Subject: [PWE3] draft-ietf-pwe3-redundancy? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 14:00:15 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BDB8AF57ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Praveen, Mustafa and all, I've looked up the PWE3 redundancy drafts at the IETF web site and only foun= d one of them (http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-04)= . Its mate (http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-03) has ex= pired some time ago. To add to the confusion, the existing draft contains a reference to -04 ver= sion (missing) of the expired one. This suggests that expiration of the PW redundancy draft was not intentional= . Did I miss something? Are the Editors merging the two drafts back (after spl= itting the original draft-muley)? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76E9BDB8AF57ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Praveen, Mustafa a= nd all,

 

I’ve looked up the PWE3 redundancy drafts at the IETF web sit= e and only found one of them (http://tools.ietf.org/html/draft-ietf-pwe3-redund= ancy-bit-04). Its mate (http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-0= 3) has expired some time ago.

&n= bsp;

To add to the confusion, the existing &nb= sp;draft contains a reference to -04 version (missing) of the expired one.

This suggests that expiration of the PW re= dundancy draft was not intentional.

=  

Did I miss something? Are the Editors m= erging the two drafts back (after splitting the original draft-muley)?<= /o:p>

 

Rega= rds, and lots of thanks in advance,

 = ;    Sasha

 

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76E9BDB8AF57ILPTMAIL02eci_-- From mustapha.aissaoui@alcatel-lucent.com Thu Jun 2 07:24:11 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58117E07A1 for ; Thu, 2 Jun 2011 07:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XTNLjYCnnln for ; Thu, 2 Jun 2011 07:24:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 01180E0786 for ; Thu, 2 Jun 2011 07:24:09 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p52EO6Cj029347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 09:24:07 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p52EO3ql012685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Jun 2011 09:24:06 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 2 Jun 2011 09:24:05 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: Alexander Vainshtein , "Muley, Praveen V (Praveen)" Date: Thu, 2 Jun 2011 09:24:03 -0500 Thread-Topic: draft-ietf-pwe3-redundancy? Thread-Index: AcwhLWLc82QLF/v0TA+rKmMbQ9x4NAAAsSSw Message-ID: <5DF53972F7E9134782DCE51624466FE50AD10B8B4B@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5DF53972F7E9134782DCE51624466FE50AD10B8B4BUSNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: Manish Vora , "pwe3@ietf.org" , Robert Rennison , Rotem Cohen Subject: Re: [PWE3] draft-ietf-pwe3-redundancy? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 14:24:11 -0000 --_000_5DF53972F7E9134782DCE51624466FE50AD10B8B4BUSNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha, I was planning on publishing version 04 of draft-ietf-pwe3-redundancy at th= e same time as the solution one. I however missed the publication deadline = for the last IETF meeting. I should be able of publishing this shortly. Regards, Mustapha. ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, June 02, 2011 10:00 AM To: Muley, Praveen V (Praveen); Aissaoui, Mustapha (Mustapha) Cc: pwe3@ietf.org; Manish Vora; Prashant Desai; Robert Rennison; Rotem Cohe= n Subject: draft-ietf-pwe3-redundancy? Praveen, Mustafa and all, I've looked up the PWE3 redundancy drafts at the IETF web site and only fou= nd one of them (http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-0= 4). Its mate (http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-03) has= expired some time ago. To add to the confusion, the existing draft contains a reference to -04 ve= rsion (missing) of the expired one. This suggests that expiration of the PW redundancy draft was not intentiona= l. Did I miss something? Are the Editors merging the two drafts back (after sp= litting the original draft-muley)? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_5DF53972F7E9134782DCE51624466FE50AD10B8B4BUSNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sasha,
I=20 was planning on publishing version 04 of draft-ietf-pwe3-red= undancy=20 at the same time as the solution one. I however missed the publication dead= line=20 for the last IETF meeting. I should be able of publishing this=20 shortly.
 
Regards,
Mustapha.

From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Thursday, June 0= 2,=20 2011 10:00 AM
To: Muley, Praveen V (Praveen); Aissaoui, Mustapha= =20 (Mustapha)
Cc: pwe3@ietf.org; Manish Vora; Prashant Desai; Robert= =20 Rennison; Rotem Cohen
Subject:=20 draft-ietf-pwe3-redundancy?

Praveen, Mustafa and all,

 

I’ve looked up the PWE3 redundancy drafts at the= IETF web=20 site and only found one of them (http:= //tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-04).=20 Its mate (http://to= ols.ietf.org/html/draft-ietf-pwe3-redundancy-03)=20 has expired some time ago.

 

To add to the confusion, the existing  draft cont= ains a=20 reference to -04 version (missing) of the expired one.

This suggests that expiration of the PW redundancy dra= ft was=20 not intentional.

 

Did I miss something? Are the Editors merging the two = drafts=20 back (after splitting the original draft-muley)?

 

Regards, and lots of thanks in advance,

     Sasha

 

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

--_000_5DF53972F7E9134782DCE51624466FE50AD10B8B4BUSNAVSXCHMBSC_-- From Alexander.Vainshtein@ecitele.com Thu Jun 2 07:25:41 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF3AE0786 for ; Thu, 2 Jun 2011 07:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNzAAHfSBOdq for ; Thu, 2 Jun 2011 07:25:39 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id B8419E0726 for ; Thu, 2 Jun 2011 07:25:38 -0700 (PDT) X-AuditID: 93eaf2e8-b7b4fae00000179b-3c-4de79cfdcf11 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 54.72.06043.DFC97ED4; Thu, 2 Jun 2011 17:23:57 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 2 Jun 2011 17:25:36 +0300 From: Alexander Vainshtein To: "Aissaoui, Mustapha (Mustapha)" Date: Thu, 2 Jun 2011 17:25:36 +0300 Thread-Topic: draft-ietf-pwe3-redundancy? Thread-Index: AcwhLWLc82QLF/v0TA+rKmMbQ9x4NAAAsSSwAAAqiJA= Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD10B8B4B@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD10B8B4B@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76E9BDB8AF86ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTa2wMURTH3ZlpO10dxtbqbaPJGIpim916ZKkV4hGvhoT4QKjp7rU7sTOz 2VlN1yNWEEmlpdEGrRSx9Ww03istofigEYQm3o3YenRpSpEGYd3Z0Woi5tN/zv93zzn35hya NJYlZdCi7Ec+WfDwiQZqT7Tri/nngbf5loMRk21bzWnC1nrsKGUr6zpPTSfnbn9zJWFuKPSN WEwsD4KpgiwrfsGPOCdSHXZ+sU8sEhwBnhOddt7Kc16P4EASkv12XvB6kezkpxm4f76pGBNl DskOxSnKLjs/b8kis802cbLZyk8bOdw6Ps+w1C2qHDJLgujhJKSqggtxOLL6POl+V3EAeE8v KG5pXhYE1TNLQDIN2QmwNbyd0vUQeL+1PlHTRrYBwHApWQIMWFcC2LG1m9CMRNYOz556EYcG s/Phw5YopUEkW0HAzs+xOESxI2DN+/txKJUdDW8/OZOgH8iGwRu1WNNYT4F1n8dqYYZdBC/d ayT0YiEAo69OAM1IZgvgxdrv8e4A7q67uS6en2TT4NO2g4TeNQtDjfdIXZtge+RXgs6b4PMd 9UDnFdgY2UnpxQbB2/vb/tw4HV4//pjaDYZU9Ulb1edIVZ8jenwcPNTQlajrsfDo4fdkj75z LUL0jR8CSSeBSfR4/YWSy5KbgxyiH3lQjkORzgJ9gN6FwbM72U2ApQGfwoTDb/KNCUKRGpCa QDpN8Camff/bfOOAQsUZcAuqu8C3zoPUJgBpkh/MnAxgj3EKgfXIp/RYs/Hrl5MZ/R0KHlXZ XzDeYvn/D5/G3KyJ5BtZF57MtQh5ka8nz1Ca5iFThsfbOMiHXKh4jejx/7UJOllrIwW3IWsM o3oFSRVdut8MzPSnKx3XgZGSFRllpDElGsRqkHud3JtHW6PNsVgsCtLwA6QyN6sxlYKXrDdT FBchcBHLqHgRvEG9VkYQJA/YowzMmpR09da5GTmZlV9LZ5Y8yFw762WwX92jy+0f4N1Lzyc1 dLfU7zLlFr/8ZVi1oTM07Fk2urrwdUySVxTMy/Ou3rJx75HcH9+rHmU2ZXFBKBVuTL+wcM6X jtFt+8pfvc4p6jySV2u09puxhZyS9fHapiXHSx+XF/+8yK00V6ZW8JTqFqxjSJ8q/AYI1/NW IQQAAA== Cc: Manish Vora , "pwe3@ietf.org" , Robert Rennison , Rotem Cohen Subject: Re: [PWE3] draft-ietf-pwe3-redundancy? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 14:25:41 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BDB8AF86ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Mustapha, Lots of thanks for a prompt and encouraging clarification. Regards, Sasha From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel-lucent= .com] Sent: Thursday, June 02, 2011 5:24 PM To: Alexander Vainshtein; Muley, Praveen V (Praveen) Cc: pwe3@ietf.org; Manish Vora; Prashant Desai; Robert Rennison; Rotem Cohen Subject: RE: draft-ietf-pwe3-redundancy? Sasha, I was planning on publishing version 04 of draft-ietf-pwe3-redundancy at the= same time as the solution one. I however missed the publication deadline fo= r the last IETF meeting. I should be able of publishing this shortly. Regards, Mustapha. ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, June 02, 2011 10:00 AM To: Muley, Praveen V (Praveen); Aissaoui, Mustapha (Mustapha) Cc: pwe3@ietf.org; Manish Vora; Prashant Desai; Robert Rennison; Rotem Cohen Subject: draft-ietf-pwe3-redundancy? Praveen, Mustafa and all, I've looked up the PWE3 redundancy drafts at the IETF web site and only foun= d one of them (http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-04)= . Its mate (http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-03) has ex= pired some time ago. To add to the confusion, the existing draft contains a reference to -04 ver= sion (missing) of the expired one. This suggests that expiration of the PW redundancy draft was not intentional= . Did I miss something? Are the Editors merging the two drafts back (after spl= itting the original draft-muley)? Regards, and lots of thanks in advance, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76E9BDB8AF86ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Mustapha,<= /p>

Lots of thanks for a prompt and encouraging clarification.

&n= bsp;

Regards,

     Sasha

 

From: Aissaoui, Mustapha (Mustapha) [mailto:musta= pha.aissaoui@alcatel-lucent.com]
Sent: Thursday, June 02, 2011 5:= 24 PM
To: Alexander Vainshtein; Muley, Praveen V (Praveen)
C= c: pwe3@ietf.org; Manish Vora; Prashant Desai; Robert Rennison; Rotem Co= hen
Subject: RE: draft-ietf-pwe3-redundancy?

=

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Sasha,

I was planning on publishing version 04 of dra= ft-ietf-pwe3-redundancy at the same time as the solution one. I however miss= ed the publication deadline for the last IETF meeting. I should be able of p= ublishing this shortly.

 

Regards,

Mustaph= a.

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=
Sent: Thursday, June 02, 2011 10:00 AM
To: Muley, Prav= een V (Praveen); Aissaoui, Mustapha (Mustapha)
Cc: pwe3@ietf.org;= Manish Vora; Prashant Desai; Robert Rennison; Rotem Cohen
Subject: draft-ietf-pwe3-redundancy?

Pr= aveen, Mustafa and all,

 =

I’ve looked up the PWE3 redundancy drafts at= the IETF web site and only found one of them (http://tools.ietf.org/html/draft= -ietf-pwe3-redundancy-bit-04). Its mate (http://tools.ietf.org/html/draft-ietf-= pwe3-redundancy-03) has expired some time ago.

 

To add to the confusion,= the existing  draft contains a reference to -04 version (missing) of t= he expired one.

This suggests that expira= tion of the PW redundancy draft was not intentional.

 

Did I miss something?= Are the Editors merging the two drafts back (after splitting the original d= raft-muley)?

 

Regards, and lots of thanks in advance,

     Sasha

 

This e-mail message is intended for the recipient= only and contains information which is CONFIDENTIAL and which may be propri= etary to ECI Telecom. If you have received this transmission in error, pleas= e inform us by e-mail, phone or fax, and then delete the original and all co= pies thereof.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76E9BDB8AF86ILPTMAIL02eci_-- From internet-drafts@ietf.org Thu Jun 2 11:14:29 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D76E079B; Thu, 2 Jun 2011 11:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1cqfWDFlth1; Thu, 2 Jun 2011 11:14:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D706BE06FB; Thu, 2 Jun 2011 11:14:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110602181428.14112.26767.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 11:14:28 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-static-pw-status-04.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:14:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Pseudowire Status for Static Pseudowires Author(s) : Luca Martini George Swallow Giles Heron Matthew Bocci Filename : draft-ietf-pwe3-static-pw-status-04.txt Pages : 12 Date : 2011-06-02 This document specifies a mechanism to signal Pseudowire (PW) status messages using an PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far end T-PE. The mechanism allows PW OAM message mapping and PW redundancy to operate on static PWs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-static-pw-status-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-static-pw-status-04.txt From lizhong.jin@zte.com.cn Fri Jun 3 06:12:53 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6476E066C for ; Fri, 3 Jun 2011 06:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u7PVWvyPR4I for ; Fri, 3 Jun 2011 06:12:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDE5E06EB for ; Fri, 3 Jun 2011 06:12:51 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 18341397396305; Fri, 3 Jun 2011 21:02:52 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 15366.2368962204; Fri, 3 Jun 2011 21:12:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p53DCeNA061152; Fri, 3 Jun 2011 21:12:40 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: matthew.bocci@alcatel-lucent.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Fri, 3 Jun 2011 21:12:30 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-03 21:12:40, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-03 21:12:40, Serialize complete at 2011-06-03 21:12:40, S/MIME Sign failed at 2011-06-03 21:12:40: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-03 21:12:43, Serialize complete at 2011-06-03 21:12:43 Content-Type: multipart/alternative; boundary="=_alternative 0048922F482578A4_=" X-MAIL: mse01.zte.com.cn p53DCeNA061152 Cc: pwe3@ietf.org Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 13:12:54 -0000 This is a multipart message in MIME format. --=_alternative 0048922F482578A4_= Content-Type: text/plain; charset="US-ASCII" Yes, support. Lizhong > ------------------------------ > > Message: 2 > Date: Thu, 2 Jun 2011 11:12:42 +0200 > From: "Bocci, Matthew (Matthew)" > To: "pwe3@ietf.org" > Subject: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have > requested that this draft be adopted as a PWE3 working group draft. > > This email begins a two week poll of the list to help judge if there > is consensus to adopt the draft. > > Please review the draft and reply to the PWE3 list stating whether > you support adoption, together with any comments. > > Regards, > > Matthew > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/pwe3/attachments/20110602/c02f2bc8/attachment.htm> > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0048922F482578A4_= Content-Type: text/html; charset="US-ASCII"
Yes, support.

Lizhong


> ------------------------------
>
> Message: 2
> Date: Thu, 2 Jun 2011 11:12:42 +0200
> From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
> To: "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt
> Message-ID: <CA0D129A.10507%matthew.bocci@alcatel-lucent.com>
> Content-Type: text/plain; charset="us-ascii"
>
> The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have
> requested that this draft be adopted as a PWE3 working group draft.
>
> This email begins a two week poll of the list to help judge if there
> is consensus to adopt the draft.
>
> Please review the draft and reply to the PWE3 list stating whether
> you support adoption, together with any comments.
>
> Regards,
>
> Matthew
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/pwe3/attachments/20110602/c02f2bc8/attachment.htm>
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0048922F482578A4_=-- From Manuel.Paul@telekom.de Fri Jun 3 10:34:14 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF07E06DE for ; Fri, 3 Jun 2011 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vi2kspwyizg for ; Fri, 3 Jun 2011 10:34:14 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8195DE0692 for ; Fri, 3 Jun 2011 10:34:13 -0700 (PDT) Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 03 Jun 2011 19:34:07 +0200 Received: from HE101452.emea1.cds.t-internal.com ([169.254.2.189]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Fri, 3 Jun 2011 19:34:08 +0200 From: To: Date: Fri, 3 Jun 2011 19:34:00 +0200 Thread-Topic: WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt Thread-Index: AcwhBTuuGB0/lJDuRQuHdtzUjAzUPQBDyXnw Message-ID: <9435EDACD941174099E143BCA2BCD615F729300B8B@HE101452.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_9435EDACD941174099E143BCA2BCD615F729300B8BHE101452emea1_" MIME-Version: 1.0 Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 17:34:14 -0000 --_000_9435EDACD941174099E143BCA2BCD615F729300B8BHE101452emea1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KDQpSZWdhcmRzLA0KDQpNYW51ZWwNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkZyb206IHB3ZTMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnB3ZTMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KQ0KU2Vu dDogVGh1cnNkYXksIEp1bmUgMDIsIDIwMTEgMTE6MTMgQU0NClRvOiBwd2UzQGlldGYub3JnDQpT dWJqZWN0OiBbUFdFM10gV0cgUG9sbCBmb3IgZHJhZnQtYm91dHJvcy1wd2UzLW1wbHMtdHAtbXMt cHctMDEudHh0DQoNClRoZSBhdXRob3JzIG9mIGRyYWZ0LWJvdXRyb3MtcHdlMy1tcGxzLXRwLW1z LXB3LTAxLnR4dCBoYXZlIHJlcXVlc3RlZCB0aGF0IHRoaXMgZHJhZnQgYmUgYWRvcHRlZCBhcyBh IFBXRTMgd29ya2luZyBncm91cCBkcmFmdC4NCg0KVGhpcyBlbWFpbCBiZWdpbnMgYSB0d28gd2Vl ayBwb2xsIG9mIHRoZSBsaXN0IHRvIGhlbHAganVkZ2UgaWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRv IGFkb3B0IHRoZSBkcmFmdC4NCg0KUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHJlcGx5IHRv IHRoZSBQV0UzIGxpc3Qgc3RhdGluZyB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9uLCB0b2dl dGhlciB3aXRoIGFueSBjb21tZW50cy4NCg0KUmVnYXJkcywNCg0KTWF0dGhldw0K --_000_9435EDACD941174099E143BCA2BCD615F729300B8BHE101452emea1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9VVRGLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93 d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCg0KPG1ldGEgbmFtZT1HZW5lcmF0 b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9c Oioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHls ZT4NCjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2 IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpD YWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAw O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6 IzYwNjQyMDsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjp3 aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0 ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NTk1LjNw dCA4NDEuOXB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYu U2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQoNCjwvaGVhZD4NCg0K PGJvZHkgbGFuZz1ERSBsaW5rPWJsdWUgdmxpbms9IiM2MDY0MjAiIHN0eWxlPSd3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7DQotd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZSc+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5TdXBwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBzdHlsZT0nbWFyZ2lu OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxmb250IHNpemU9MiBjb2xvcj1ibGFjaw0KZmFj ZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpibGFjayc+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBz dHlsZT0nbWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxmb250IHNpemU9MiBjb2xv cj1ibGFjaw0KZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpBcmlhbDtjb2xvcjpibGFjayc+TWFudWVsPC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0x IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTpBcmlh bCc+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IGNsYXNzPU1z b05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBzaXpl PTMNCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn Pg0KDQo8aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQoN Cjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBzaXpl PTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWls eTpUYWhvbWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBz aXplPTINCmZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OlRhaG9tYSc+DQpwd2UzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwd2UzLWJvdW5jZXNA aWV0Zi5vcmddIDxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDoNCmJvbGQnPk9uIEJlaGFsZiBP ZiA8L3NwYW4+PC9iPkJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KTxicj4NCjxiPjxzcGFuIHN0eWxl PSdmb250LXdlaWdodDpib2xkJz5TZW50Ojwvc3Bhbj48L2I+IFRodXJzZGF5LCBKdW5lIDAyLCAy MDExDQoxMToxMyBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5Ubzo8 L3NwYW4+PC9iPiBwd2UzQGlldGYub3JnPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0 OmJvbGQnPlN1YmplY3Q6PC9zcGFuPjwvYj4gW1BXRTNdIFdHIFBvbGwgZm9yDQpkcmFmdC1ib3V0 cm9zLXB3ZTMtbXBscy10cC1tcy1wdy0wMS50eHQ8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgY29sb3I9YmxhY2sgZmFjZT1DYWxpYnJpPjxzcGFuDQpzdHlsZT0nZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrJz5UaGUgYXV0aG9ycw0K b2YmbmJzcDtkcmFmdC1ib3V0cm9zLXB3ZTMtbXBscy10cC1tcy1wdy0wMS50eHQgaGF2ZSByZXF1 ZXN0ZWQgdGhhdCB0aGlzIGRyYWZ0DQpiZSBhZG9wdGVkIGFzIGEgUFdFMyB3b3JraW5nIGdyb3Vw IGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9Q2FsaWJy aT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9YmxhY2sgZmFj ZT1DYWxpYnJpPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxp YnJpO2NvbG9yOmJsYWNrJz5UaGlzIGVtYWlsIGJlZ2lucyBhDQp0d28gd2VlayBwb2xsIG9mIHRo ZSBsaXN0IHRvIGhlbHAganVkZ2UgaWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIGFkb3B0IHRoZQ0K ZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9YmxhY2sgZmFjZT1DYWxpYnJp PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y OmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibGFjayBmYWNl PUNhbGlicmk+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGli cmk7Y29sb3I6YmxhY2snPlBsZWFzZSByZXZpZXcgdGhlDQpkcmFmdCBhbmQgcmVwbHkgdG8gdGhl IFBXRTMgbGlzdCBzdGF0aW5nIHdoZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24sIHRvZ2V0aGVy DQp3aXRoIGFueSBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibGFj ayBmYWNlPUNhbGlicmk+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsYWNrIGZhY2U9Q2FsaWJyaT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayc+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBjb2xvcj1ibGFjayBmYWNlPUNhbGlicmk+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9Q2FsaWJyaT48c3Bhbg0Kc3R5bGU9J2Zv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayc+TWF0dGhldzxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+ DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_9435EDACD941174099E143BCA2BCD615F729300B8BHE101452emea1_-- From venkatflex@gmail.com Fri Jun 3 12:25:53 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C46AE07D3 for ; Fri, 3 Jun 2011 12:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sewGXSxOezhz for ; Fri, 3 Jun 2011 12:25:52 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7849E07D2 for ; Fri, 3 Jun 2011 12:25:52 -0700 (PDT) Received: by vws12 with SMTP id 12so2071460vws.31 for ; Fri, 03 Jun 2011 12:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=9jKhKKqGaBBlsKMZSPI3oWs3Bc4IaH16oJOOuFmj15M=; b=jKGl0JRvyPoS0ItJpYYLFGgu8z+daXghwYK3ZCFMB3Qg8g7CsNdgrg+x3cvT2Ll/zF Utrnldo57Hzjq9m3CbyimzTD5pNFlljoRYOzj31i0ZJ34ZF9h3lcEZsh+WbocksmiAQy bD2N+2T9tHBjgHMv4zfFNslPbsla5+4j6Z9pY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UKvAdK807+GO7dVObO5onsDDnPkqviDVX0vMeJcF/1NtxeWDyyXTdZhYwrmOdgVoRY dkz3kiTTZpGXey81ie1g+lJ9gTXxaULo3xuGz5cb+8Q/fDsIUyQTp+9vlP4X+CxZn/hw cCc5AVaw14TL/hLWKXS9HN5lBuANhOhZf+HFs= MIME-Version: 1.0 Received: by 10.52.175.99 with SMTP id bz3mr3091482vdc.117.1307129152137; Fri, 03 Jun 2011 12:25:52 -0700 (PDT) Received: by 10.52.113.163 with HTTP; Fri, 3 Jun 2011 12:25:52 -0700 (PDT) Date: Fri, 3 Jun 2011 15:25:52 -0400 Message-ID: From: venkatesan mahalingam To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=bcaec5161845c9e9f404a4d3b838 Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 19:25:53 -0000 --bcaec5161845c9e9f404a4d3b838 Content-Type: text/plain; charset=ISO-8859-1 Yes/Support. Thanks, Venkat. ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Thursday, June 02, 2011 11:13 AM To: pwe3@ietf.org Subject: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that this draft be adopted as a PWE3 working group draft. This email begins a two week poll of the list to help judge if there is consensus to adopt the draft. Please review the draft and reply to the PWE3 list stating whether you support adoption, together with any comments. Regards, Matthew --bcaec5161845c9e9f404a4d3b838 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes/Support.

Thanks,
Venkat.
_________________________= _______
From:=A0pwe3-bounces@ietf.org=A0[mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Thursday, June 02, 2011 11:13 AM
To:=A0pwe3@ietf.org
Subject: [PWE3] = WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt

The authors of d= raft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that this draft be ad= opted as a PWE3 working group draft.

This email begins a two week poll of the list to help judge if there is= consensus to adopt the draft.

Please review the draft and reply to = the PWE3 list stating whether you support adoption, together with any comme= nts.

Regards,

Matthew
--bcaec5161845c9e9f404a4d3b838-- From yaacov.weingarten@nsn.com Mon Jun 6 05:07:06 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B999D11E812D for ; Mon, 6 Jun 2011 05:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhVVuvT4WSWQ for ; Mon, 6 Jun 2011 05:07:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id AB27F11E8128 for ; Mon, 6 Jun 2011 05:07:05 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p56C6wut025384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 6 Jun 2011 14:06:58 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p56C6unb028144 for ; Mon, 6 Jun 2011 14:06:58 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 14:06:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2442.390D2447" Date: Mon, 6 Jun 2011 14:06:48 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt Thread-index: AcwhBTuuGB0/lJDuRQuHdtzUjAzUPQDPPKCg References: From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 06 Jun 2011 12:06:52.0817 (UTC) FILETIME=[38E98010:01CC2442] Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 12:07:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2442.390D2447 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Yes/Support =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Bocci, Matthew (Matthew) Sent: Thursday, June 02, 2011 12:13 PM To: pwe3@ietf.org Subject: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt =20 The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that this draft be adopted as a PWE3 working group draft. =20 This email begins a two week poll of the list to help judge if there is consensus to adopt the draft. =20 Please review the draft and reply to the PWE3 list stating whether you support adoption, together with any comments. =20 Regards, =20 Matthew ------_=_NextPart_001_01CC2442.390D2447 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Yes/Support

 

From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = ext Bocci, Matthew (Matthew)
Sent: Thursday, June 02, 2011 = 12:13 PM
To: pwe3@ietf.org
Subject: [PWE3] WG Poll = for = draft-boutros-pwe3-mpls-tp-ms-pw-01.txt

=

 

The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have = requested that this draft be adopted as a PWE3 working group = draft.

 

This email begins a two week poll of the list to help judge if there is = consensus to adopt the draft.

 

Please review the draft and reply to the PWE3 list stating whether you = support adoption, together with any = comments.

 

Regards,

 

Matthew

------_=_NextPart_001_01CC2442.390D2447-- From yaakov_s@rad.com Mon Jun 6 23:15:54 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E6F21F855D for ; Mon, 6 Jun 2011 23:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StNS2C0OJaAL for ; Mon, 6 Jun 2011 23:15:53 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by ietfa.amsl.com (Postfix) with ESMTP id A31A721F855A for ; Mon, 6 Jun 2011 23:15:49 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir2.rad.co.il with ESMTP; 07 Jun 2011 09:15:47 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 7 Jun 2011 09:15:47 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Tue, 7 Jun 2011 09:15:47 +0300 From: Yaakov Stein To: "pwe3@ietf.org" Thread-Topic: comments on draft-ietf-pwe3-mpls-eth-oam-iwk Thread-Index: Acwk2lQ7ALyHyEfHQpWYicf0B2iJeg== Date: Tue, 7 Jun 2011 06:15:44 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903E55C04@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.232.33.112] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC903E55C04EXRAD5adradcoil_" MIME-Version: 1.0 Subject: [PWE3] comments on draft-ietf-pwe3-mpls-eth-oam-iwk X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 06:15:54 -0000 --_000_07F7D7DED63154409F13298786A2ADC903E55C04EXRAD5adradcoil_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I apologize for taking so long to get to review this document, and must admit that I did not have the time to carefully review all of the = defect entry and exit criteria. But here are my comments : General comment - The lack of definite and indefinite articles makes the te= xt hard to read. For example, in section 1.2 all of the statements of the = type =93AC receive defect =85=94 would be more understandable if the text s= aid =93An AC receive defect =85=94 Similarly =93there is need=94 -> =93ther= e is a need=94. In 3.3 =93 PW defect is detected=94 assumedly means =93a PW= defect is detected=94. And so on throughout the document. In section 1 =93When an Ethernet AC is an Ethernet PHY=94 should be =93When= an Ethernet AC is a single Ethernet link=94. =93In addition, scalability constraints may not allow running proactive mon= itoring, such as CCMs with transmission on=94. I am not sure I understand the sentence. Does it mean =93In addition, scala= bility constraints may not allow proactive monitoring such as CCMs=94 ? Figure 1 please update to corrected version in oam-msg-map, this version h= as several typos and is incorrect ! Other CCM interface status TLVs will not be used -> Other CCM interface s= tatus TLV values will not be used (There is only one CCM interface TLV but it can take several values) =93could point to problems associated with PE2=92s inability to transmit=94= this should be "problems with its ability to transmit" (a problem with inability to transmit would assumedly mean that the PE is f= unctioning perfectly) 3.1 However, with the completion of Ethernet OAM work - this remark is s= o old that it should be removed. =93and when CCM transmission is configured not to be turned ON=94 suggest = saying =93and when CCM transmission is disabled=94. I have a question about this =96 although AIS is more crucial when CCM is d= isabled, are you disallowing it when CCM is enabled ? The second option, suspension of CCM frames of the downstream MEP, leads to= uninhibited alarm propagation. In section 3.2 forward and reverse defects are defined as in oam-msg-map. However, the draft sometimes uses the term =93forward defect indication=94 = and sometimes =93forward defect notification=94. Is there a difference ? Also, in section 5.6 it is stated that the forward defect notification is c= leared. Shouldn=92t this be =93the forward defect is cleared=94 ? On the other hand, the term =93reverse defect notification=94 is consistent= ly used (not indication), except in Section 5.1 where we have the term = =93reverse defect failure notification=94. 3.2 first paragraph has 2 SHOULDs. Why is LDP status messaging not a MUST (= that is my interpretation of 4447)?. What is done in other cases if diag codes are NOT used ? (The text in oam-msg-map states that if LDP is not used then some alternati= ve method MUST be used.) 4.1 iss removed -> is removed if AIS was resulted -> if receiving AIS re= sulted =93period indicated by previously received AIS=94 assumedly refers to the A= IS transmission period carried in the AIS PDU. Missing a single AIS should not be taken as an indication that AIS is clear= ed =96 one should probably wait 3 =BD transmission period times. Similarly in 4.2, I think you want to clear the transmit defect upon receiv= ing CCMs with RDI cleared, not based on not receiving CCMs with RDI set as = stated. In all of section 5, can the clumsy =93is (not) configured to be turned on= =94 be replaced with =93is (dis)abled=94 ? In 5.1 =93When Native Service OAM mechanism is supported on PE, it can also= use the NS OAM notification=94 =96 is this instead or in addition to PW st= atus ? Section 5.6 For consistency I believe that the second paragraph should sta= te that when LDP has been used LDP status messaging MUST be used, rather than the convoluted =93When NS OAM is not supported and MPLS PSN=94 = (and not even mentioning LDP!). Section 8 =96 I suggest that you harmonize the security section with that o= f oam-msg-map. In the references 802.1ag needs updating from D8.1 to the published versio= n Appendix =96 newer versions of Y.1731 define additional functions. Y(J)S --_000_07F7D7DED63154409F13298786A2ADC903E55C04EXRAD5adradcoil_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I apologize for taking so long to get to = review this document,

and must admit that I did not have the ti= me to carefully review all of the defect entry and exit criteria.

 

But here are my comments :

 

General comment - The lack of definite an= d indefinite articles makes the text hard to read.  For example, in se= ction 1.2 all of the statements of the type =93AC receive defect =85=94 would be more understandable if the text said =93An AC receive defe= ct =85=94 Similarly =93there is need=94 -> =93there is a need=94. In 3.3= =93 PW defect is detected=94 assumedly means =93a PW defect is detected=94= . And so on throughout the document.

 

In section 1 =93When an Ethernet AC is an= Ethernet PHY=94 should be =93When an Ethernet AC is a single Ethernet link= =94.

 

=
=93In addition, scalability constraints may not allow running proactive mon=
itoring, such as CCMs with transmission on=94. 
I=
 am not sure I understand the sentence. Does it mean =93In addition, scalab=
ility constraints may not allow proactive monitoring such as CCMs=94 ?=

<=
o:p> 

Figure 1  please update to corrected= version in oam-msg-map, this version has several typos and is incorrect !<= o:p>

 

Other CCM interface status TLVs will not = be used  ->  Other CCM interface status TLV values will not be= used

(There is only one CCM interface TLV but = it can take several values)

 

=93could point to problems associated wit= h PE2=92s inability to transmit=94 this should be "problems with its a= bility to transmit"

(a problem with inability to transmit wou= ld assumedly mean that the PE is functioning perfectly)

 

3.1  However, with the completion of= Ethernet OAM work  -  this remark is so old that it should be re= moved.

 

=93and when CCM transmission is configure= d not to be turned ON=94  suggest saying =93and when CCM transmission = is disabled=94.

I have a question about this =96 although= AIS is more crucial when CCM is disabled, are you disallowing it when CCM = is enabled ?

The second option, suspension of CCM fram= es of the downstream MEP, leads to uninhibited alarm propagation. 

 

In section 3.2 forward and reverse defect= s are defined as in oam-msg-map.

However, the draft sometimes uses the ter= m =93forward defect indication=94 and sometimes =93forward defect notificat= ion=94. Is there a difference ?

Also, in section 5.6 it is stated that th= e forward defect notification is cleared. Shouldn=92t this be =93the forwar= d defect is cleared=94 ? 

On the other hand, the term =93reverse de= fect notification=94 is consistently used (not indication), except  in= Section 5.1 where  we have the term =93reverse defect failure notific= ation=94.

 

3.2 first paragraph has 2 SHOULDs. Why is= LDP status messaging not a MUST (that is my interpretation of 4447)?.

What is done in other cases if diag codes= are NOT used ?

(The text in oam-msg-map states that if L= DP is not used then some alternative method MUST be used.)

 

4.1 iss removed -> is removed &nb= sp;  if AIS was resulted -> if receiving AIS resulted

 

=93period indicated by previously receive= d AIS=94 assumedly refers to the AIS transmission period carried in the AIS= PDU.

Missing a single AIS should not be taken = as an indication that AIS is cleared =96 one should probably wait 3 =BD tra= nsmission period times.

 

Similarly in 4.2, I think you want to cle= ar the transmit defect upon receiving CCMs with RDI cleared, not based on n= ot receiving CCMs with RDI set as stated.

 

In all of section 5, can the clumsy =93is= (not) configured to be turned on=94 be replaced with =93is (dis)abled=94 ?=

 

I=
n 5.1 =93When Native Service OAM mechanism is supported on PE, it can also =
use the NS OAM notification=94 =96 is this instead or in addition to PW sta=
tus ? 
<=
o:p> 

Section 5.6  For consistency I belie= ve that the second paragraph should state that when LDP has been used LDP s= tatus messaging MUST be used,

rather than the convoluted =93When NS OAM= is not supported and MPLS PSN=94 (and not even mentioning LDP!).

 

Section 8 =96 I suggest that you harmoniz= e the security section with that of oam-msg-map.

 

In the references  802.1ag needs upd= ating from D8.1 to the published version

 

Appendix =96 newer versions of Y.1731 def= ine additional functions.

 

 

Y(J)S

 

 

--_000_07F7D7DED63154409F13298786A2ADC903E55C04EXRAD5adradcoil_-- From lmartini@cisco.com Tue Jun 7 12:29:41 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6763011E821F for ; Tue, 7 Jun 2011 12:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uxqKTAIuIpT for ; Tue, 7 Jun 2011 12:29:40 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 4383B11E8225 for ; Tue, 7 Jun 2011 12:29:40 -0700 (PDT) Received: from seven.monoski.com (pool-96-227-66-119.phlapa.fios.verizon.net [96.227.66.119]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p57JTKMT010347 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 7 Jun 2011 13:29:23 -0600 (MDT) Message-ID: <4DED666A.9020204@cisco.com> Date: Mon, 06 Jun 2011 17:44:42 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Bocci, Matthew (Matthew)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060104000906030805030509" Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 19:29:41 -0000 This is a multi-part message in MIME format. --------------060104000906030805030509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit yes, Support. Luca On 06/02/2011 03:12 AM, Bocci, Matthew (Matthew) wrote: > The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that this draft be adopted as a PWE3 working group draft. > > This email begins a two week poll of the list to help judge if there is consensus to adopt the draft. > > Please review the draft and reply to the PWE3 list stating whether you support adoption, together with any comments. > > Regards, > > Matthew > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --------------060104000906030805030509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit yes, Support.
Luca

On 06/02/2011 03:12 AM, Bocci, Matthew (Matthew) wrote: 
The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that this draft be adopted as a PWE3 working group draft.

This email begins a two week poll of the list to help judge if there is consensus to adopt the draft.

Please review the draft and reply to the PWE3 list stating whether you support adoption, together with any comments.

Regards,

Matthew



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

--------------060104000906030805030509-- From aldrin.ietf@gmail.com Tue Jun 7 12:33:40 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F0011E8228 for ; Tue, 7 Jun 2011 12:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxpkxdNncX8B for ; Tue, 7 Jun 2011 12:33:39 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA10311E8147 for ; Tue, 7 Jun 2011 12:33:38 -0700 (PDT) Received: by pwi5 with SMTP id 5so31764pwi.31 for ; Tue, 07 Jun 2011 12:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=tTkvIFUJIxx4c9JBSQ5QIH8OkvvDTOXSkbsQj4KHBuk=; b=xgBhUa3TWACZzhico9roCmD49DB/IVa00KjjSuxUuCa3WuydEN7jZZ3+x2Pb4TMN9i mb7e+o0wu+SytjVe3rlX27RWziFLT1hyyKKfT+jkmDHM0wD+lbwd/zUrFfV8uWcwWBZk QEuXhjKFYb8HcV+xS1FV1Teu0APNa5t1eOAw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=s9SfBvFbvXt3BKFvNEXOlp7nDu8kQ/l9GFnCxUrcJqn6iebboizEfTHGrRFY/AIicB X+cEou8Dia5eEuNIDKGVyKX84qpf1yGEYV18iFHaAmQBX8fnQF1w212TBgr+opaYWoKT zGe/U5BLj9EM5g/N8wIfvc3bCuxZeMPsTlkjc= Received: by 10.68.30.73 with SMTP id q9mr340045pbh.431.1307475217974; Tue, 07 Jun 2011 12:33:37 -0700 (PDT) Received: from [192.168.0.41] ([12.133.183.34]) by mx.google.com with ESMTPS id i7sm338215pbj.58.2011.06.07.12.33.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2011 12:33:36 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8J2) From: Sam Aldrin Date: Tue, 7 Jun 2011 12:34:10 -0700 To: "Bocci, Matthew (Matthew)" Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 19:33:40 -0000 Yes, support. -sam Sent from my iPad On Jun 2, 2011, at 2:12 AM, "Bocci, Matthew (Matthew)" wrote: > The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that= this draft be adopted as a PWE3 working group draft. >=20 > This email begins a two week poll of the list to help judge if there is co= nsensus to adopt the draft. >=20 > Please review the draft and reply to the PWE3 list stating whether you sup= port adoption, together with any comments. >=20 > Regards, >=20 > Matthew > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From ping@pingpan.org Tue Jun 7 19:39:24 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D1011E8072 for ; Tue, 7 Jun 2011 19:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oG5IDo9MeR4 for ; Tue, 7 Jun 2011 19:39:23 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with SMTP id E958521F8461 for ; Tue, 7 Jun 2011 19:39:22 -0700 (PDT) Received: from mail-ew0-f47.google.com ([209.85.215.47]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTe7g2rVFNaXrfMwZrIRSeFOLBE0mIgGA@postini.com; Tue, 07 Jun 2011 19:39:23 PDT Received: by ewy5 with SMTP id 5so25379ewy.6 for ; Tue, 07 Jun 2011 19:39:20 -0700 (PDT) Received: by 10.14.11.1 with SMTP id 1mr2798977eew.138.1307500760140; Tue, 07 Jun 2011 19:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.95.79 with HTTP; Tue, 7 Jun 2011 19:38:40 -0700 (PDT) In-Reply-To: References: From: Ping Pan Date: Tue, 7 Jun 2011 19:38:40 -0700 Message-ID: To: "Bocci, Matthew (Matthew)" Content-Type: multipart/alternative; boundary=0016364c7d735a0de604a52a3efc Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 02:39:24 -0000 --0016364c7d735a0de604a52a3efc Content-Type: text/plain; charset=ISO-8859-1 Support - Ping On Thu, Jun 2, 2011 at 2:12 AM, Bocci, Matthew (Matthew) < matthew.bocci@alcatel-lucent.com> wrote: > The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that > this draft be adopted as a PWE3 working group draft. > > This email begins a two week poll of the list to help judge if there is > consensus to adopt the draft. > > Please review the draft and reply to the PWE3 list stating whether you > support adoption, together with any comments. > > Regards, > > Matthew > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --0016364c7d735a0de604a52a3efc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support

- Ping


On Thu, Jun 2, 2011 at 2:12 AM, Bocci, M= atthew (Matthew) <matthew.bocci@alcatel-lucent.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">
The authors of=A0draft-boutros-pwe3-mpls-tp= -ms-pw-01.txt have requested that this draft be adopted as a PWE3 working g= roup draft.

This email begins a two week poll of the list to help j= udge if there is consensus to adopt the draft.

Ple= ase review the draft and reply to the PWE3 list stating whether you support= adoption, together with any comments.

Regards,

Matthew

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


--0016364c7d735a0de604a52a3efc-- From vishwas.ietf@gmail.com Tue Jun 7 22:26:23 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7D811E8082 for ; Tue, 7 Jun 2011 22:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYvItr9kvPp2 for ; Tue, 7 Jun 2011 22:26:23 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B3F2911E808E for ; Tue, 7 Jun 2011 22:26:22 -0700 (PDT) Received: by wwa36 with SMTP id 36so87084wwa.13 for ; Tue, 07 Jun 2011 22:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jnwH1xs5mOHtOVBrrItZqxUS82UQ9on2VuqNN0jx3Ts=; b=vXbX9+HuGbg0cXsbSGMrQKGU0FxmW5GIkgi/Oxzq1ghMSdrJHUpJhLyYrqyYBCqk4q OvZs9+y92pPsw0z9s4+35e2KUomX+n8SUdza36Yr/45qRZBPqwyQiDOSiqFLeRmHqWlF CrOuT4bx1UD0iWe8f6OJjGDQK0Qb0xdQ9K9oM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XlnvgH6ahANlp/1TGAPFZ+CjppyLtDffY7wFfgSeX8CEruBg830keJEG6bVGEehQQo CIE03OHHD1smdmOAuT9tGWz5Rle5hnsa40S4jmWm5bGPUCHRZ3IHP1KMu/Ku/Kn6lVxe ucY/IK0U+VafWP88h84TIC940VKqd8XtsGPQE= MIME-Version: 1.0 Received: by 10.216.144.2 with SMTP id m2mr6635266wej.114.1307510781754; Tue, 07 Jun 2011 22:26:21 -0700 (PDT) Received: by 10.216.4.19 with HTTP; Tue, 7 Jun 2011 22:26:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jun 2011 22:26:21 -0700 Message-ID: From: Vishwas Manral To: Ping Pan Content-Type: multipart/alternative; boundary=0016e6dab368afbe1004a52c9382 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 05:26:23 -0000 --0016e6dab368afbe1004a52c9382 Content-Type: text/plain; charset=ISO-8859-1 Support -Vishwas On Tue, Jun 7, 2011 at 7:38 PM, Ping Pan wrote: > Support > > - Ping > > > > On Thu, Jun 2, 2011 at 2:12 AM, Bocci, Matthew (Matthew) < > matthew.bocci@alcatel-lucent.com> wrote: > >> The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested >> that this draft be adopted as a PWE3 working group draft. >> >> This email begins a two week poll of the list to help judge if there is >> consensus to adopt the draft. >> >> Please review the draft and reply to the PWE3 list stating whether you >> support adoption, together with any comments. >> >> Regards, >> >> Matthew >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --0016e6dab368afbe1004a52c9382 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support
=A0
-Vishwas

On Tue, Jun 7, 2011 at 7:38 PM, Ping Pan <ping@pingpan.org>= wrote:
Support

- Ping=20



On Thu, Jun 2, 2011 at 2:12 AM, Bocci, Matthew (= Matthew) <matthew.bocci@alcatel-lucent.com> w= rote:
The authors of=A0draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requeste= d that this draft be adopted as a PWE3 working group draft.

This email begins a two week poll of the list to help judge if there i= s consensus to adopt the draft.

Please review the draft and reply to the PWE3 list stating whether you= support adoption, together with any comments.

Regards,

Matthew

________________________________________= _______
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3


________________________________= _______________
pwe3 mailing list
pw= e3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3


--0016e6dab368afbe1004a52c9382-- From gregory.mirsky@ericsson.com Wed Jun 8 10:12:33 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA8821F855C for ; Wed, 8 Jun 2011 10:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.948 X-Spam-Level: X-Spam-Status: No, score=-6.948 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+-GZy6l2jZW for ; Wed, 8 Jun 2011 10:12:32 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2198721F8543 for ; Wed, 8 Jun 2011 10:12:32 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p58HCTuw001783 for ; Wed, 8 Jun 2011 12:12:31 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.108]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 8 Jun 2011 13:12:29 -0400 From: Gregory Mirsky To: "pwe3@ietf.org" Date: Wed, 8 Jun 2011 13:12:27 -0400 Thread-Topic: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt Thread-Index: Acwl/s0n9EK7dYcuTjqznCfDZUG6LAAAEUtw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF121F39EEFC0EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 17:12:33 -0000 --_000_FE60A4E52763E84B935532D7D9294FF121F39EEFC0EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes/support Regards, Greg ________________________________ From: Bocci, Matthew (Matthew) > Date: Thu, Jun 2, 2011 at 2:12 AM Subject: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt To: "pwe3@ietf.org" > The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that = this draft be adopted as a PWE3 working group draft. This email begins a two week poll of the list to help judge if there is con= sensus to adopt the draft. Please review the draft and reply to the PWE3 list stating whether you supp= ort adoption, together with any comments. Regards, Matthew _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_FE60A4E52763E84B935532D7D9294FF121F39EEFC0EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
yes/support
 
   =20 Regards,
       =20 Greg

From: Bocci, Matthew (Matthew) <matthew.bocci@alcatel-luce= nt.com>
Date:=20 Thu, Jun 2, 2011 at 2:12 AM
Subject: [PWE3] WG Poll for=20 draft-boutros-pwe3-mpls-tp-ms-pw-01.txt
To: "pwe3@ietf.org" <pwe3@ietf.org>


The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have reque= sted=20 that this draft be adopted as a PWE3 working group draft.

This email begins a two week poll of the list to help judge if there i= s=20 consensus to adopt the draft.

Please review the draft and reply to the PWE3 list stating whether you= =20 support adoption, together with any comments.

Regards,

Matthew

________________________________________= _______
pwe3=20 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3


--_000_FE60A4E52763E84B935532D7D9294FF121F39EEFC0EUSAACMS0715e_-- From matthew.bocci@alcatel-lucent.com Thu Jun 9 02:49:22 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4695721F8491 for ; Thu, 9 Jun 2011 02:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7Lzc0PMmgzb for ; Thu, 9 Jun 2011 02:49:21 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 76C8421F8490 for ; Thu, 9 Jun 2011 02:49:21 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p599kR2a029603 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 9 Jun 2011 11:49:18 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 9 Jun 2011 11:48:50 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Thu, 9 Jun 2011 11:48:46 +0200 Thread-Topic: WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Thread-Index: Acwmim8YgO2wxXLFTRmMrx1MED7Xzg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA16558E10C01matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 09:49:22 -0000 --_000_CA16558E10C01matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email begins a two week working group last call for draft-ietf-pwe3-mp= ls-tp-gal-in-pw-01.txt Please review the draft and post any comments to the PWE3 mailing list. The working group last call will end on Friday 24th June. Best regards, Matthew & Andy --_000_CA16558E10C01matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This email begins a two = week working group last call for draft-ietf-pwe3-mpls-tp-gal-in-pw-01.= txt

Please review the draft and post any comments = to the PWE3 mailing list.

The working group last c= all will end on Friday 24th June.

Best regards,

Matthew & Andy
--_000_CA16558E10C01matthewboccialcatellucentcom_-- From mach.chen@huawei.com Thu Jun 9 03:00:57 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8263411E80A7 for ; Thu, 9 Jun 2011 03:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEUHJfTYIonT for ; Thu, 9 Jun 2011 03:00:57 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B94B911E8071 for ; Thu, 9 Jun 2011 03:00:56 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMI0037SP2ZQ1@szxga03-in.huawei.com> for pwe3@ietf.org; Thu, 09 Jun 2011 17:59:23 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMI00CBOP2Z5K@szxga03-in.huawei.com> for pwe3@ietf.org; Thu, 09 Jun 2011 17:59:23 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 09 Jun 2011 17:59:20 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.87]) by szxeml412-hub.china.huawei.com ([169.254.150.116]) with mapi id 14.01.0270.001; Thu, 09 Jun 2011 17:59:21 +0800 Date: Thu, 09 Jun 2011 09:59:20 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.110.98.37] To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HG/qo7ow3cyseMjbq/ZVgg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt Thread-index: AcwhBTuuGB0/lJDuRQuHdtzUjAzUPQFhpfvw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 10:00:57 -0000 --Boundary_(ID_HG/qo7ow3cyseMjbq/ZVgg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Yes/support. Best regards, Mach From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Thursday, June 02, 2011 5:13 PM To: pwe3@ietf.org Subject: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that this draft be adopted as a PWE3 working group draft. This email begins a two week poll of the list to help judge if there is consensus to adopt the draft. Please review the draft and reply to the PWE3 list stating whether you support adoption, together with any comments. Regards, Matthew --Boundary_(ID_HG/qo7ow3cyseMjbq/ZVgg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Yes/support.

 

Best regards,

Mach

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Thursday, June 02, 2011 5:13 PM
To: pwe3@ietf.org
Subject: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt

 

The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have requested that this draft be adopted as a PWE3 working group draft.

 

This email begins a two week poll of the list to help judge if there is consensus to adopt the draft.

 

Please review the draft and reply to the PWE3 list stating whether you support adoption, together with any comments.

 

Regards,

 

Matthew

--Boundary_(ID_HG/qo7ow3cyseMjbq/ZVgg)-- From gregimirsky@gmail.com Thu Jun 9 14:58:15 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8A821F8470; Thu, 9 Jun 2011 14:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS4K+ZjJmwtF; Thu, 9 Jun 2011 14:58:14 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5002C21F846C; Thu, 9 Jun 2011 14:58:14 -0700 (PDT) Received: by vxg33 with SMTP id 33so2159468vxg.31 for ; Thu, 09 Jun 2011 14:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=TYqoAqv/k4HxTinAazbI8524xLrmkdrWI3ogna1HmyQ=; b=WvWdoDhmjAOwltfRhfz68fDfdoOAQvYLEMCNnkvATAWgoeuDKgvEweM6zRvftXv/hI sDGbi7O1lgL81oN5wkUw5PAwrjH7W1MMic8DHUwstmO3V9CRX3bL0GIaRSEZlmWy0TRH LerNijk+zPpiQN38cjGYngCBNBOl0MfZUirJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Hn1gICBKEtOuBWMamXH/v+sJjfZnLAl0emrXTOn00EN0xIj+td0CaDbkpgP3Du1YOM VkMGWOeD1BqxFRIjhys9ZWYC3jD26SoN6eMhPdW167govJj4dRVWzcvZj74yxQEwydV/ ZruXcVQcGYCtjj8b5Mmrb5LSMZ1AjpKFdTJ60= MIME-Version: 1.0 Received: by 10.52.97.104 with SMTP id dz8mr1893146vdb.146.1307656693593; Thu, 09 Jun 2011 14:58:13 -0700 (PDT) Received: by 10.52.169.165 with HTTP; Thu, 9 Jun 2011 14:58:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Jun 2011 14:58:13 -0700 Message-ID: From: Greg Mirsky To: Thomas Nadeau , Luca Martini , pwe3 , mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf307f35f4b5b7a804a54e8ced Subject: Re: [PWE3] Comments to draft-nadeau-pwe3-vccv-2-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 21:58:15 -0000 --20cf307f35f4b5b7a804a54e8ced Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, perhaps I've missed your response and I've decided to re-post. Regards, Greg On Fri, Mar 11, 2011 at 2:26 PM, Greg Mirsky wrote: > Dear Authors, > please find my comments below. > > - this proposal is closely related to changes to RFC 5586 put forward > in draft-lm-pwe3-mpls-tp-gal-in-pw-00 but there's no reference to the draft. > - RFC 5586 states and the draft-lm-pwe3-mpls-tp-gal-in-pw-00 maintains > that in MPLS-TP network the GAL must be BoS. Only in non-TP MPLS netowrks > GAL might be not a BoS. In your proposal the GAL precedes the PW and thus is > not BoS. But the document's scope is for all MPLS PWs, including over > MPLS-TP PSN. Unless statement in Section 4.2 RFC 5586 "In MPLS-TP (GAL) ... > MUST always be at the bottom of the label stack (i.e., S bit set to 1)" > updated proposed use of GAL is allowed only in non-TP MPLS PSN. > - Section 2 lists of allowed ACH. Since these are hexadecimal numbers > I'd suggest prepending them with '0x' to make as "0x07, 0x21, and 0x57". And > I'd ask for clarification of "allowed". Is it "MAY", "SHOULD" or "MUST" be > limited to ... A, B, C"? > - In Section 3 stated that TTL in PW LSE must be set to 1 for SS-PW and > to appropriate value in MS-PW to reach intended PE. Hence my question, Is > this mechanism to reach MIP, i.e. S-PE, or this is mechanism to generate > exception? But that is how PW VCCV Control Channel Type 3 works. What is the > interpretation of GAL in a label stack? To indicate PW CW after the PW LSE? > - editorial - in Abstract s/The MPLS/the MPLS or a reference to, > perhaps, RFC 5654. > > > Regards, > Greg > > > > --20cf307f35f4b5b7a804a54e8ced Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,
perhaps I've missed your response and I've decided= to re-post.

Regards,
Greg

On F= ri, Mar 11, 2011 at 2:26 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Authors,
please find my comments be= low.
  • this proposal is closely related to changes to RFC 5586 put= forward in draft-lm-pwe3-mpls-tp-gal-in-pw-00 but there's no reference= to the draft.
  • RFC 5586 states and the draft-lm-pwe3-mpls-tp-gal-in-pw-00 maintains th= at in MPLS-TP network the GAL must be BoS. Only in non-TP MPLS netowrks GAL= might be not a BoS. In your proposal the GAL precedes the PW and thus is n= ot BoS. But the document's scope is for all MPLS PWs, including over MP= LS-TP PSN. Unless statement in Section 4.2 RFC 5586 "In MPLS-TP (GAL) = ... MUST always be at the bottom of the label stack (i.e., S bit set to 1= )" updated proposed use of GAL is allowed only in non-TP MPLS PSN.
  • Section 2 lists of allowed ACH. Since these are hexadecimal numbers I&#= 39;d suggest prepending them with '0x' to make as "0x07, 0x21,= and 0x57". And I'd ask for clarification of "allowed". = Is it "MAY", "SHOULD" or "MUST" be limited to= ... A, B, C"?
  • In Section 3 stated that TTL in PW LSE must be set to 1 for SS-PW and t= o appropriate value in MS-PW to reach intended PE. Hence my question, Is th= is mechanism to reach MIP, i.e. S-PE, or this is mechanism to generate exce= ption? But that is how PW VCCV Control Channel Type 3 works. What is the in= terpretation of GAL in a label stack? To indicate PW CW after the PW LSE?
  • editorial - in Abstract s/The MPLS/the MPLS or a reference to, perhaps,= RFC 5654.

Regards,
Greg



--20cf307f35f4b5b7a804a54e8ced-- From david.i.allan@ericsson.com Thu Jun 9 15:44:00 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8404A11E80BB for ; Thu, 9 Jun 2011 15:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqn5t7EbIoO3 for ; Thu, 9 Jun 2011 15:43:59 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 61AB111E807A for ; Thu, 9 Jun 2011 15:43:57 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p59MhuAk004590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 9 Jun 2011 17:43:56 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.12]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 9 Jun 2011 18:43:56 -0400 From: David Allan I To: "pwe3@ietf.org" Date: Thu, 9 Jun 2011 18:43:55 -0400 Thread-Topic: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Thread-Index: Acwm9rZWnLNXSkd/TsWJeOldt2bIOA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD521B518CF3@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD521B518CF3EUSAACMS0703e_" MIME-Version: 1.0 Subject: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 22:44:00 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD521B518CF3EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm opposed to this draft progressing at this time. At the moment the PW with a CW is a unifying agent that will work in both T= P domains and those that employ ECMP and LAG. The GAL/ACh version cannot ma= ke this claim. What would be required to make this acceptable IMO would be agreement with = the MPLS WG to produce an RFC that documented excluding reserved labels fro= m ECMP consideration such that GAL/GACh encapsulated PW OAM had "feature pa= rity" with ACh encapsulated PW-OAM... Then we could reasonably consider taking steps to move to a common OAM enca= psulation mechanism common to LSPs and PWs. My 2 cents Dave --_000_60C093A41B5E45409A19D42CF7786DFD521B518CF3EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm opposed to this draft progressing at this time.
 
At the moment the PW with a CW is a unifying agent that will work in b= oth TP domains and those that employ ECMP and LAG. The GAL/ACh version cann= ot make this claim.
 
What would be required to make this acceptable IMO would be agreement = with the MPLS WG to produce an RFC that documented excluding reserved label= s from ECMP consideration such that GAL/GACh encapsulated PW OAM had "= feature parity" with ACh encapsulated PW-OAM…
 
Then we could reasonably consider taking steps to move to a common OAM= encapsulation mechanism common to LSPs and PWs.
 
My 2 cents
Dave
 
 --_000_60C093A41B5E45409A19D42CF7786DFD521B518CF3EUSAACMS0703e_-- From gregory.mirsky@ericsson.com Thu Jun 9 15:54:21 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFFB11E80EB for ; Thu, 9 Jun 2011 15:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.773 X-Spam-Level: X-Spam-Status: No, score=-6.773 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HOBtA6Jo8Qs for ; Thu, 9 Jun 2011 15:54:21 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D897D11E807A for ; Thu, 9 Jun 2011 15:54:20 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p59MsJYC005274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jun 2011 17:54:19 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.108]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 9 Jun 2011 18:54:18 -0400 From: Gregory Mirsky To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Thu, 9 Jun 2011 18:54:17 -0400 Thread-Topic: WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Thread-Index: Acwmim8YgO2wxXLFTRmMrx1MED7XzgAbPOAw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF121F3A4799FEUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 22:54:21 -0000 --_000_FE60A4E52763E84B935532D7D9294FF121F3A4799FEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm opposed to progressing this document ahead of addressing issues raised = on closely related to it draft-nadeau-pwe3-vccv-2-01 and detailed investiga= tion of impact both can have on ECMP in non-TP MPLS networks. Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Thursday, June 09, 2011 2:49 AM To: pwe3@ietf.org Subject: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt This email begins a two week working group last call for draft-ietf-pwe3-mp= ls-tp-gal-in-pw-01.txt Please review the draft and post any comments to the PWE3 mailing list. The working group last call will end on Friday 24th June. Best regards, Matthew & Andy --_000_FE60A4E52763E84B935532D7D9294FF121F3A4799FEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm opposed=20 to progressing this document ahead of addressing issues raised on closely=20 related to it draft-nadeau-pwe3-vccv-2-01 and detailed investigation of imp= act=20 both can have on ECMP in non-TP MPLS networks.
 
  &n= bsp; Regards,
        Greg

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew=20 (Matthew)
Sent: Thursday, June 09, 2011 2:49 AM
To:=20 pwe3@ietf.org
Subject: [PWE3] WG LC on=20 draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt

This email begins a two week working group last call=20 for draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt

Please review the draft and post any comments to the PWE3 mailing=20 list.

The working group last call will end on Friday 24th June.

Best regards,

Matthew & Andy
--_000_FE60A4E52763E84B935532D7D9294FF121F3A4799FEUSAACMS0715e_-- From liu.guoman@zte.com.cn Thu Jun 9 18:05:45 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FE721F855D for ; Thu, 9 Jun 2011 18:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.146 X-Spam-Level: X-Spam-Status: No, score=-96.146 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rctmBHtrnCCI for ; Thu, 9 Jun 2011 18:05:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id F15E521F855C for ; Thu, 9 Jun 2011 18:05:43 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 395841397396305; Fri, 10 Jun 2011 09:04:03 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 58615.1397396305; Fri, 10 Jun 2011 09:05:17 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id p5A15T56037027 for ; Fri, 10 Jun 2011 09:05:29 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p5A0rZfS024908; Fri, 10 Jun 2011 08:53:35 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201106100105.p5A15T56037027@mse02.zte.com.cn> In-Reply-To: To: "Bocci, Matthew (Matthew)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Fri, 10 Jun 2011 08:53:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-10 08:53:36, Serialize complete at 2011-06-10 08:53:36 Content-Type: multipart/alternative; boundary="=_alternative 00050545482578AB_=" X-MAIL: mse02.zte.com.cn p5A15T56037027 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 01:05:45 -0000 This is a multipart message in MIME format. --=_alternative 00050545482578AB_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQNCg0KDQoNCg0KDQoNCg0KIkJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KSIgPG1h dHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPiANCreivP7IyzogIHB3ZTMtYm91bmNlc0Bp ZXRmLm9yZw0KMjAxMS0wNi0wOSAxNzo0OA0KDQrK1bz+yMsNCiJwd2UzQGlldGYub3JnIiA8cHdl M0BpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KW1BXRTNdIFdHIExDIG9uIGRyYWZ0LWlldGYtcHdl My1tcGxzLXRwLWdhbC1pbi1wdy0wMS50eHQNCg0KDQoNCg0KDQoNClRoaXMgZW1haWwgYmVnaW5z IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIA0KZHJhZnQtaWV0Zi1wd2Uz LW1wbHMtdHAtZ2FsLWluLXB3LTAxLnR4dA0KDQpQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQg cG9zdCBhbnkgY29tbWVudHMgdG8gdGhlIFBXRTMgbWFpbGluZyBsaXN0Lg0KDQpUaGUgd29ya2lu ZyBncm91cCBsYXN0IGNhbGwgd2lsbCBlbmQgb24gRnJpZGF5IDI0dGggSnVuZS4NCg0KQmVzdCBy ZWdhcmRzLA0KDQpNYXR0aGV3ICYgQW5keV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0KcHdlM0BpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQoNCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFi b3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 00050545482578AB_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcy9zdXBwb3J0PGJyPg0KPC9m b250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1jZW50ZXI+PC9kaXY+DQo8dGQ+ PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj4mcXVvdDtCb2NjaSwgTWF0dGhldyAoTWF0dGhldykmcXVvdDsNCiZsdDttYXR0aGV3LmJv Y2NpQGFsY2F0ZWwtbHVjZW50LmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wNi0wOSAxNzo0ODwv Zm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4m cXVvdDtwd2UzQGlldGYub3JnJnF1b3Q7ICZsdDtwd2UzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W1BXRTNdIFdH IExDIG9uIGRyYWZ0LWlldGYtcHdlMy1tcGxzLXRwLWdhbC1pbi1wdy0wMS50eHQ8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+VGhpcyBlbWFpbCBiZWdpbnMgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwDQpsYXN0IGNhbGwg Zm9yIGRyYWZ0LWlldGYtcHdlMy1tcGxzLXRwLWdhbC1pbi1wdy0wMS50eHQ8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0 IGFuZCBwb3N0IGFueSBjb21tZW50cw0KdG8gdGhlIFBXRTMgbWFpbGluZyBsaXN0LjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhlIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIHdpbGwgZW5kIG9uDQpGcmlkYXkgMjR0aCBKdW5lLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+QmVzdCByZWdhcmRzLDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+TWF0dGhldyAmYW1wOyBBbmR5PC9mb250 Pjxmb250IHNpemU9Mj48dHQ+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpwd2UzIG1haWxpbmcgbGlzdDxicj4NCnB3ZTNAaWV0Zi5vcmc8YnI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTM8YnI+DQo8L3R0PjwvZm9u dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkm bmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJz cDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0 eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7 VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRp YWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtv YmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNw O2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0 aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJz cDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNw O2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtj b25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZu YnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29y Jm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2Fk ZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3Ro aXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkm bmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZu YnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7 bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5i c3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7 YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00050545482578AB_=-- From Alexander.Vainshtein@ecitele.com Fri Jun 10 06:47:05 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B1311E8181 for ; Fri, 10 Jun 2011 06:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiEpRe6TnTPe for ; Fri, 10 Jun 2011 06:47:05 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id AA15011E817F for ; Fri, 10 Jun 2011 06:47:04 -0700 (PDT) X-AuditID: 93eaf2e8-b7ba4ae000000a73-23-4df21ff4dc72 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 66.88.02675.4FF12FD4; Fri, 10 Jun 2011 16:45:24 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 10 Jun 2011 16:47:03 +0300 From: Alexander Vainshtein To: David Allan I , "pwe3@ietf.org" Date: Fri, 10 Jun 2011 16:46:14 +0300 Thread-Topic: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Thread-Index: Acwm9rZWnLNXSkd/TsWJeOldt2bIOAAfg2bx Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD521B518CF3@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD521B518CF3@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTeUzTUBjntWUUpKRMxp4LxlkDicd0A4zzGJooiokoRI3Gf7B2j62ydUs7 FdREjPGIGo9oDJt/AAbEiAYkGLyPBS8OISYe8UYJKEgME+OBEdtVEWP/+r3f8X3vNd9H4toW jYHkBR8SBdbFaGKIIz2hAdPAuFC2+Zh/mrWjrQG3HgjVE/OwrO+fH2qyKiq+YTnYmmIwhxUE j4/1IaMdSZyNyRH5jSxXxBh5u42xMEavi+WQGwk+G8N6vUiwMxkxxv++ObKNF4xI4Dx2XnDY mMXLl5ms1ukzTRYmI2WCJW12zAonLxmRyc3yLqMbSRLrQEaZWVuPO+uP9GHe9qjCS5+6iWLg 1+wF0SSk02HliV5MxYmw/WWNzMeQWvoigPuuhyLVw1EAH3d0hV0a2gbrql+E0wl0Lqy6GCQU TNDJ8M3r42F+NL0Qtg48+O1ZBDsHG3AVp8Lvjc2RCqboZbC2/WyY19KrYPePPWAvIMloejV8 eM2i0EC+0JemM+G2OK2HTztLf1+UhhVX2nAV6+D7tz8jVb8OPt9dA1S/GX68X4qreDI8Wd6L q23j4T1/J6Fmx8Cbp54Qh0BiYESLwIh4YEQ8MCJeBojTQMe7vL51boc5dSrieB9yoamcx10H 1Ll4dwE8a5kYBDQJmFjqblR/tjaS3SgVuYNgDIkxOiphbChbG7fOYy9yspIzT9zgQlIQQBJn EqiP0bJG2dmizUj0/JGs8k8+jBtGcR55AgVfXprZ/M+B0VP7uA/ZWtohD1oBQl4k/okmkSQD qT55ULXxInKgwnze5fsrY2S00jlW7rxS8VCSl3VLvEPVm8B4g566rAi0Ijg3CMNZZQm2DQ0N 9QC9/M7R1AfFFSuvyHC6Ry6MyYV3BfuVwvISDEuGYsBl5Uc9XlObfDBliei/VKW/kfMCG2xc 2pGQ0cxk5typ7h+YtX++O6mvo6w34vao9Ekz4gz9PbdMhdtndt4vufWj3Z8ZOxgobdyallv5 KuJL8zmy5GqrSHcRczcVru+y7+RuVC59G3e55cGFgqTavCl8w+CCrzcdO+pTtugenS8XySSG kJysZRIuSuwvVUG4+d8DAAA= Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:47:05 -0000 Hi all, I concur with Dave. Regards, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of David Allan= I [david.i.allan@ericsson.com] Sent: Friday, June 10, 2011 1:43 AM To: pwe3@ietf.org Subject: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt I'm opposed to this draft progressing at this time. At the moment the PW with a CW is a unifying agent that will work in both TP= domains and those that employ ECMP and LAG. The GAL/ACh version cannot make= this claim. What would be required to make this acceptable IMO would be agreement with t= he MPLS WG to produce an RFC that documented excluding reserved labels from= ECMP consideration such that GAL/GACh encapsulated PW OAM had "feature pari= ty" with ACh encapsulated PW-OAM=85 Then we could reasonably consider taking steps to move to a common OAM encap= sulation mechanism common to LSPs and PWs. My 2 cents Dave This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From matthew.bocci@alcatel-lucent.com Fri Jun 10 07:20:41 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBBB11E817C for ; Fri, 10 Jun 2011 07:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcprJkgb7BFD for ; Fri, 10 Jun 2011 07:20:41 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6BD11E80CA for ; Fri, 10 Jun 2011 07:20:41 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5AEKb0l026373 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 10 Jun 2011 16:20:39 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 10 Jun 2011 16:20:38 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Fri, 10 Jun 2011 16:20:36 +0200 Thread-Topic: Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 Thread-Index: AcwneZIC9SLtrk3zQqq8mJoJ6GgmAA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA17E6C310D60matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 14:20:42 -0000 --_000_CA17E6C310D60matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email begins a two week poll of the PWE3 list for WG adoption of draft= -delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational document. Please reply to this thread indicating whether or not you support this. The poll closes on Friday 24th June 2011. Regards, Matthew & Andy --_000_CA17E6C310D60matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This email begins a two we= ek poll of the PWE3 list for WG adoption of draft-delregno-pw= e3-pw-vccv-impl-survey-results-00 as in Informational document.

Please reply to this thread i= ndicating whether or not you support this.

The poll closes on Friday 24th June 2011.

Regards,
=
Matthew & Andy

--_000_CA17E6C310D60matthewboccialcatellucentcom_-- From tnadeau@lucidvision.com Fri Jun 10 07:36:45 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D865111E81BB for ; Fri, 10 Jun 2011 07:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r8X+dci2C8z for ; Fri, 10 Jun 2011 07:36:45 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 67D4211E818D for ; Fri, 10 Jun 2011 07:36:45 -0700 (PDT) Received: from [10.100.68.11] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id EAC401BCD486; Fri, 10 Jun 2011 10:36:44 -0400 (EDT) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <60B9D8EA-E31A-4F44-9507-EE54AF9FE58A@lucidvision.com> X-Mailer: iPad Mail (8J2) From: Thomas Nadeau Date: Fri, 10 Jun 2011 10:36:41 -0400 To: "Bocci, Matthew (Matthew)" Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 14:36:46 -0000 Yes On Jun 10, 2011, at 10:20 AM, "Bocci, Matthew (Matthew)" wrote: > This email begins a two week poll of the PWE3 list for WG adoption of draf= t-delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational document.= >=20 > Please reply to this thread indicating whether or not you support this. >=20 > The poll closes on Friday 24th June 2011. >=20 > Regards, >=20 > Matthew & Andy >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From amalis@gmail.com Fri Jun 10 07:46:04 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5EC11E8101 for ; Fri, 10 Jun 2011 07:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jo8b8AyV5Ql for ; Fri, 10 Jun 2011 07:46:04 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82EC311E80FF for ; Fri, 10 Jun 2011 07:45:31 -0700 (PDT) Received: by bwz13 with SMTP id 13so2668727bwz.31 for ; Fri, 10 Jun 2011 07:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=bF+/ZcCsTC9lTGvIqULjPPYi+xAcauL/S/OXgLIXKhs=; b=byZKiZJoLclHG2fEKH6/xH6Kk3ApSa0sE/qoBW0Et7T2szTd4mDqevOelmu2NmuNE4 kVCFe4Q5SI1r8gIor/PQPnMHtOzxH8xCy9QUM72BEKpLTWxvmjr4wDPqotgsxUT+yRg2 L/GJfBH4RZyfKWmylgiYtN3DWxgSDGcGmZe8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=kFcsLkIHVHmPi0gJTrjMjU+hatW2ODVyhKYCaucki4oor43U8y9KnKLiuXcLDFo3QA zPcxKrfHvFrZoVHR2UznC5bsOshhDYPT+hT5rWnouEm24yei7+kGJedMtqT+9e2wMdUO jMFOB01TXUYWUA2BB6V0NMSBncRn9A/o3tn6w= Received: by 10.204.156.22 with SMTP id u22mr283096bkw.9.1307717130223; Fri, 10 Jun 2011 07:45:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.82.138 with HTTP; Fri, 10 Jun 2011 07:45:10 -0700 (PDT) From: "Andrew G. Malis" Date: Fri, 10 Jun 2011 10:45:10 -0400 Message-ID: To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [PWE3] PWE3 WG last call for draft-ietf-pwe3-static-pw-status-04 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 14:46:04 -0000 This email begins a two week WG last call for draft-ietf-pwe3-static-pw-status-04 as a Proposed Standard RFC. Please reply to this thread with any last call comments. The last call closes on Friday 24th June 2011. Regards, Andy & Matthew From Alexander.Vainshtein@ecitele.com Fri Jun 10 08:06:14 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A67911E80E0 for ; Fri, 10 Jun 2011 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh5ZFkjDqbOE for ; Fri, 10 Jun 2011 08:06:13 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 5B97111E8093 for ; Fri, 10 Jun 2011 08:06:01 -0700 (PDT) X-AuditID: 93eaf2e8-b7ba4ae000000a73-c3-4df232733fe3 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id E8.E8.02675.37232FD4; Fri, 10 Jun 2011 18:04:20 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 10 Jun 2011 18:05:58 +0300 From: Alexander Vainshtein To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Fri, 10 Jun 2011 18:05:38 +0300 Thread-Topic: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 Thread-Index: AcwneZIC9SLtrk3zQqq8mJoJ6GgmAAABkk1p Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C965ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTWUwTURTNmxnKgAwZCpUHLtQhLmBKKGBSowV/TCCmsYn8qEEc2mc70k6b zoBUYyQYMakRFzRqXQDTuGFcEBdUTKi4oUYT/aiCGiNxKRosEpVoqDOMIonxfZ13z7nn3vdy L4mrI6p0kuNF5OFZB6OKJxrDQ8M6MW/IlNu4I9Fw0/cCGBqG2olFWPGWt50xxYHACGbGVtSC hSzPu0RWRForEixGxuzhqlmLl9FyViOjZ7RuB2tBTsSLRoZ1uxFvZQrjtf+chZKM47WIt7is HG8zMiXLluoMhnnzdXqmcFamPn9BfKmdE7RI52Q5h9aJBIG1Ia0UWd2O2z8/i8a466bVXGru iK0FT9N8gCQhXQBbB5N9IE6Ck+Hjl2dVPhBPqukOABtCtbhy2QNgtHEwRlapaCNsa32hknEK bYUBfyhWxgQ9E3a3PsRknEyXwcHm70DRrIL77oUwBefBO76rY3qKXgqfbK0fi6slz0d1flzG cXQhfHj/y1gtIHX0ref0mAanU+Hz/iZM6ZSGgeuPcAVr4Ic3o7/1Gti39SxQ9C54++UXlVIr Cd470E8o+jTYdSJE7AQa/wRb/4QU/4QUJZ4DQ3v3qBQ8Fx5rGcAVrIP7R4PExHgziD0FNJzD LVY4bbl5OcjCiciBciwuZxtQ5uX9FdD7ICsIaBIwCdTd2IhJHcNWC15nEKSRGKOhLuQMmdSJ FS6r184K9nJPlQMJQQBJnEmhBuMkjrKy3vXI4/pDLZZ+fxeePsnikiaTF8vzc3P/f2FSqW2W jyY1bZOmsRIhN/L88ZlKkgykonqpRJIH2VDNGs4h/qUxMk5uI0Fq47WsoQQ36xQ4m8L3gBnp qVSfTNAyYa/ix3PlTdkUjUbDIFV6dDI1LKsSpD0azw5LxphkXB+MyMbSpoxT6bXgeKfhoLjS /MMVPVMRvFNANXl3HP46sj1j492yDb33L7ecn1pvurXOfP7dz56azOxhwnQuUuRf21Xata1h Rdara+bO0k8ZKeuzL3YsaZq9oeQtOlrCLK47knnUWxSe7uFGXl9vPxQYWE7MGa2asrm+0tp/ Mkze6P5WEknqn13UWIbvZgjBzuqzcY/A/gI7bRu0BAQAAA== Subject: Re: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 15:06:14 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C965ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Yes/support. Regards, Sasha ________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Bocci, Matt= hew (Matthew) [matthew.bocci@alcatel-lucent.com] Sent: Friday, June 10, 2011 5:20 PM To: pwe3@ietf.org Subject: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey= -results-00 This email begins a two week poll of the PWE3 list for WG adoption of draft-= delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational document. Please reply to this thread indicating whether or not you support this. The poll closes on Friday 24th June 2011. Regards, Matthew & Andy This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C965ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Yes/support.
 
Regards,
     Sasha
 
From: pwe3-bounces= @ietf.org [pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) [mat= thew.bocci@alcatel-lucent.com]
Sent: Friday, June 10, 2011 5:20 PM
To: pwe3@ietf.org
Subject: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl= -survey-results-00

This email begins a two week poll of the PWE3 list for WG adoption of&n= bsp;draft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informati= onal document.

Please reply to this thread indicating whether or not you support= this.

The poll closes on Friday 24th June 2011.

Regards,

Matthew & Andy

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C965ILPTMAIL02eci_-- From prvs=3142c9bf3c=edwin.mallette@bhnis.com Fri Jun 10 08:19:56 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D62411E80F0 for ; Fri, 10 Jun 2011 08:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywO096Mqca8W for ; Fri, 10 Jun 2011 08:19:56 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX2.mybrighthouse.com [209.16.122.104]) by ietfa.amsl.com (Postfix) with ESMTP id C4CE511E80E0 for ; Fri, 10 Jun 2011 08:19:55 -0700 (PDT) Received: from pps.filterd (mx2 [127.0.0.1]) by mx2.mybrighthouse.com (8.14.3/8.14.3) with SMTP id p5AFEoF1013264; Fri, 10 Jun 2011 11:19:49 -0400 Received: from cntpaowa1.corp.local ([10.225.4.5]) by mx2.mybrighthouse.com with ESMTP id wumcq0fv7-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Jun 2011 11:19:49 -0400 Received: from CNEMAIL.corp.local ([10.225.1.128]) by cntpaowa1.corp.local ([10.225.4.5]) with mapi; Fri, 10 Jun 2011 11:19:49 -0400 From: "Mallette, Edwin" To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Fri, 10 Jun 2011 11:19:43 -0400 Thread-Topic: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 Thread-Index: Acwngda9TF7nEQjDRzGn5o96vIqX1w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA17AE44E4EAedwinmallettebhniscom_" MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1106100115 Subject: Re: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 15:19:56 -0000 --_000_CA17AE44E4EAedwinmallettebhniscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Ed From: "Bocci, Matthew (Matthew)" > Date: Fri, 10 Jun 2011 10:20:36 -0400 To: "pwe3@ietf.org" > Subject: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-surve= y-results-00 This email begins a two week poll of the PWE3 list for WG adoption of draft= -delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational document. Please reply to this thread indicating whether or not you support this. The poll closes on Friday 24th June 2011. Regards, Matthew & Andy ________________________________ CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. --_000_CA17AE44E4EAedwinmallettebhniscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support.

Ed

From: "Bocci, Matthew (Matthew= )" <matthew.boc= ci@alcatel-lucent.com>
Date: Fri, 10 Jun 2011 10:20:36 -04= 00
To: "pwe3@ietf.org" <pwe3@i= etf.org>
Subject: [PWE3] Poll for adoption o= f draft-delregno-pwe3-pw-vccv-impl-survey-results-00

This email begins a two week poll of the PWE3 list for WG adoption of&= nbsp;draft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in Info= rmational document.

Please reply to this thread indicating whether or not you sup= port this.

The poll closes on Friday 24th June 2011.

Regards,

Matthew & Andy


CONFIDENTIALITY NOTICE: This= e-mail may contain information that is privileged, confidential or otherwi= se protected from disclosure. If you are not the intended recipient of this= e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.
 --_000_CA17AE44E4EAedwinmallettebhniscom_-- From lizhong.jin@zte.com.cn Mon Jun 13 04:07:40 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17ACB11E8075 for ; Mon, 13 Jun 2011 04:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRFmofLiEAR1 for ; Mon, 13 Jun 2011 04:07:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id CEAAA11E8078 for ; Mon, 13 Jun 2011 04:07:38 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 395841397396305; Mon, 13 Jun 2011 19:05:12 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 23654.2368962204; Mon, 13 Jun 2011 19:07:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p5DB7IR9085899; Mon, 13 Jun 2011 19:07:18 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: matthew.bocci@alcatel-lucent.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Mon, 13 Jun 2011 19:06:23 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-13 19:07:21, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-13 19:07:21, Serialize complete at 2011-06-13 19:07:21, S/MIME Sign failed at 2011-06-13 19:07:21: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-13 19:07:21 Content-Type: multipart/alternative; boundary="=_alternative 003D1938482578AE_=" X-MAIL: mse02.zte.com.cn p5DB7IR9085899 Cc: pwe3@ietf.org Subject: Re: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 11:07:40 -0000 This is a multipart message in MIME format. --=_alternative 003D1938482578AE_= Content-Type: text/plain; charset="US-ASCII" Yes, support Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 10 Jun 2011 16:20:36 +0200 > From: "Bocci, Matthew (Matthew)" > To: "pwe3@ietf.org" > Subject: [PWE3] Poll for adoption of > draft-delregno-pwe3-pw-vccv-impl-survey-results-00 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > This email begins a two week poll of the PWE3 list for WG adoption > of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in > Informational document. > > Please reply to this thread indicating whether or not you support this. > > The poll closes on Friday 24th June 2011. > > Regards, > > Matthew & Andy > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/pwe3/attachments/20110610/2eb3f64d/attachment.htm> > > ------------------------------ > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003D1938482578AE_= Content-Type: text/html; charset="US-ASCII"
Yes, support

Lizhong

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 10 Jun 2011 16:20:36 +0200
> From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
> To: "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: [PWE3] Poll for adoption of
>    draft-delregno-pwe3-pw-vccv-impl-survey-results-00
> Message-ID: <CA17E6C3.10D60%matthew.bocci@alcatel-lucent.com>
> Content-Type: text/plain; charset="us-ascii"
>
> This email begins a two week poll of the PWE3 list for WG adoption
> of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in
> Informational document.
>
> Please reply to this thread indicating whether or not you support this.
>
> The poll closes on Friday 24th June 2011.
>
> Regards,
>
> Matthew & Andy
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/pwe3/attachments/20110610/2eb3f64d/attachment.htm>
>
> ------------------------------
> --=_alt
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 003D1938482578AE_=-- From raymond.key@hotmail.com Mon Jun 13 04:25:24 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8B921F843D for ; Mon, 13 Jun 2011 04:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX1cDOAlZ+zH for ; Mon, 13 Jun 2011 04:25:24 -0700 (PDT) Received: from snt0-omc1-s23.snt0.hotmail.com (snt0-omc1-s23.snt0.hotmail.com [65.55.90.34]) by ietfa.amsl.com (Postfix) with ESMTP id E507921F843C for ; Mon, 13 Jun 2011 04:25:23 -0700 (PDT) Received: from SNT123-W28 ([65.55.90.7]) by snt0-omc1-s23.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 04:25:23 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ba712ba5-77d4-49b8-bc86-c95a945addf2_" X-Originating-IP: [203.35.82.133] From: Raymond Key Sender: To: , Date: Mon, 13 Jun 2011 21:55:23 +1030 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jun 2011 11:25:23.0941 (UTC) FILETIME=[96516950:01CC29BC] Subject: Re: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 11:25:24 -0000 --_ba712ba5-77d4-49b8-bc86-c95a945addf2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes=2C I support. Raymond Key =20 From: matthew.bocci@alcatel-lucent.com To: pwe3@ietf.org Date: Fri=2C 10 Jun 2011 16:20:36 +0200 Subject: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-surve= y-results-00 This email begins a two week poll of the PWE3 list for WG adoption of draft= -delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational document. Please reply to this thread indicating whether or not you support this. The poll closes on Friday 24th June 2011. Regards=2C Matthew & Andy _______________________________________________ pwe3 mailing list pwe3@ietf= .org https://www.ietf.org/mailman/listinfo/pwe3 = --_ba712ba5-77d4-49b8-bc86-c95a945addf2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes=2C I support.
Raymond Key
 =3B
From: matthew.bocci@alcatel-lucent.com
To: pwe3@ietf.org
Date: Fri=2C= 10 Jun 2011 16:20:36 +0200
Subject: [PWE3] Poll for adoption of draft-d= elregno-pwe3-pw-vccv-impl-survey-results-00

This email begins a two week poll of the PWE3 list for WG adoption of&= nbsp=3Bdraft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in I= nformational document.

Please reply to this thread indicating whether or not you su= pport this.

The poll closes on Friday 24th June 2011.

Regards=2C

Matthew &=3B Andy


_______________________________________= ________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listi= nfo/pwe3 = --_ba712ba5-77d4-49b8-bc86-c95a945addf2_-- From yaakov_s@rad.com Mon Jun 13 05:27:06 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823459E800D for ; Mon, 13 Jun 2011 05:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl3euNFw+a2a for ; Mon, 13 Jun 2011 05:27:05 -0700 (PDT) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3759E8009 for ; Mon, 13 Jun 2011 05:27:04 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 13 Jun 2011 15:26:57 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 13 Jun 2011 15:26:56 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Mon, 13 Jun 2011 15:26:56 +0300 From: Yaakov Stein To: "pwe3@ietf.org" Thread-Topic: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 Thread-Index: AcwneZIC9SLtrk3zQqq8mJoJ6GgmAACS5IoQ Date: Mon, 13 Jun 2011 12:26:55 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903E57ABB@EXRAD5.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC903E57ABBEXRAD5adradcoil_" MIME-Version: 1.0 Subject: Re: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 12:27:06 -0000 --_000_07F7D7DED63154409F13298786A2ADC903E57ABBEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Friday, June 10, 2011 17:21 To: pwe3@ietf.org Subject: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-surve= y-results-00 This email begins a two week poll of the PWE3 list for WG adoption of draft= -delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational document. Please reply to this thread indicating whether or not you support this. The poll closes on Friday 24th June 2011. Regards, Matthew & Andy --_000_07F7D7DED63154409F13298786A2ADC903E57ABBEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Y(J)S

 

From: pwe3-bou= nces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, June 10, 2011 17:21
To: pwe3@ietf.org
Subject: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-imp= l-survey-results-00

 

This email begins a two week poll of the PWE3 list for WG adop= tion of draft-delregno-pwe3-pw-vccv-i= mpl-survey-results-00 as in Informational document.

 

Please = reply to this thread indicating whether or not you support this.

 

The pol= l closes on Friday 24th June 2011.

 

Regards= ,

 

Matthew= & Andy

 

--_000_07F7D7DED63154409F13298786A2ADC903E57ABBEXRAD5adradcoil_-- From lizhong.jin@zte.com.cn Mon Jun 13 05:39:14 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0451A9E8010 for ; Mon, 13 Jun 2011 05:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xOhsCWytPKu for ; Mon, 13 Jun 2011 05:39:13 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1349421F8476 for ; Mon, 13 Jun 2011 05:39:12 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 395841397396305; Mon, 13 Jun 2011 20:36:54 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 85765.6117912792; Mon, 13 Jun 2011 20:39:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5DCd2ml041146; Mon, 13 Jun 2011 20:39:02 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) To: lmartini@cisco.com, swallow@cisco.com, giheron@cisco.com, matthew.bocci@alcatel-lucent.co.uk MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Mon, 13 Jun 2011 20:38:06 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-13 20:39:04, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-13 20:39:04, Serialize complete at 2011-06-13 20:39:04, S/MIME Sign failed at 2011-06-13 20:39:04: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-13 20:39:04 Content-Type: multipart/alternative; boundary="=_alternative 00457ECE482578AE_=" X-MAIL: mse01.zte.com.cn p5DCd2ml041146 Cc: pwe3@ietf.org Subject: [PWE3] S-PE bypass mode in draft-ietf-pwe3-static-pw-status-04 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 12:39:14 -0000 This is a multipart message in MIME format. --=_alternative 00457ECE482578AE_= Content-Type: text/plain; charset="US-ASCII" Dear authors, I have a concern for the S-PE bypass mode. If one PW segment using LDP control plane is in graceful restart state, then how to send the PW status codes defined in section 5.5 for S-PE? These PW status may be discarded, because the control plane may be down or in recovering state. Hope to see the clarification, thank you. Regards Lizhong -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00457ECE482578AE_= Content-Type: text/html; charset="US-ASCII"
Dear authors,
I have a concern for the S-PE bypass mode. If one PW segment using LDP control plane is in graceful restart state, then how to send the PW status codes defined in section 5.5 for S-PE? These PW status may be discarded, because the control plane may be down or in recovering state.

Hope to see the clarification, thank you.

Regards
Lizhong 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00457ECE482578AE_=-- From Alexander.Vainshtein@ecitele.com Mon Jun 13 05:43:34 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461E721F8476; Mon, 13 Jun 2011 05:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o94Y5O8mnwRs; Mon, 13 Jun 2011 05:43:33 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id EE28221F847F; Mon, 13 Jun 2011 05:43:31 -0700 (PDT) X-AuditID: 93eaf2e8-b7c74ae000000a6f-b6-4df605903a4c Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 48.2F.02671.09506FD4; Mon, 13 Jun 2011 15:41:52 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 13 Jun 2011 15:43:29 +0300 From: Alexander Vainshtein To: "ma.yuxia@zte.com.cn" Date: Mon, 13 Jun 2011 15:43:26 +0300 Thread-Topic: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9A38ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURjlzszujubUuPm4icU0UqC15WbFRq4UWRioPTGqHznOXncnd2eW mTE0iLaiAiuxpJdFL1TyUYH0frcRsWL2gJ5m/VijspAws/xhNrOT5p/+nXu+c849M3yXxK3b LEmkIKpIFjkva44mqrt7+2xVpv689CtVEx0/jrzGHW/qGkyOyt6LxAI8p7Z2AMtpvv2LWI6t C4BMThQllVMR40IK72SXy8Imji9nGcHlZO0s4/dyPPIhUXWynN+PRBebFZ2pkYLIIJGXXILo drJLVy2zORxz5tnsbNbUFHvG/OjVHkFhkM3HCV7GhxSFcyNGY/Saogu5mGJJZlQPYuTCatxz 7DrvH9hY1j64JgDqCytAFAnp2fB4uAUYOAE+eXfBXAGiSSt9A8BHH0KYcTgE4Pmmp4SuMtNO 2NLUadZxHD0T7jgajrhxOhu++9hq0TFBT4HBgV0mHY+nC2HrvtsWQ8/BS6GzuIFnwWvnnkd4 il4Gh0IfI/lWeiW88rU/oomiV8GOz/ciPNDa/Wxtxoy7EuGbrpOY0ZqGtTcf4waOh5/Dv02G Ph6+3X3hbzcJ9oT6/t4VC0NHuwhDPwHeO/uKqAIJNaNia0ZZakZZDH46PHWj12zgabD+9Bd8 GLfdDWOj+VPA0gjiBa9fLfK502fNQLygIi+awUu+FmDsz6eroKMtNQhoErAxVPBxX57VxG1S yn1BMIHE2HiqkujPs44tklzlHk7xbJBLvUgJAkjibBy1r1uTUy6ufDOSpeHRYu3v78eTxvCS vgLqhoz09P8f2ERqD/81z0q7tcUsQciP5OGcZJJkIZWtbbc1VkZuVFYseNV/Y4yM0mvEaDVy 9YqU4ud8iuA25q1gclIitUI30/rAUyqOePWXs3VoaKgbJGofPZ6y6KoYbWFH3N1aMKYF06Xf 9WDt0YyMkgLgekn44MvvzvzL49oJoXr91TkHYzvrYooLHr4I2NqXdJwJlOR+i8u5H+e8lJJV +cKfNii93ZiWO2327nzHiXUJB/IfPW8kkgu2hK4dLn3wfvvO1JU9HzBkWZu9sMsxd5K6qIdY WP/LB24eaeDaJsL2OxnWinHnOm8pq/c6mp7Zi843s4Ti4expuKxwfwDDXEeLFAQAAA== Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 12:43:34 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9A38ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dear Ma and all, Adding the PWE3 WG to my response. The PW redundancy mechanism supports linear protection of MS-PWs as one of m= any additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses= cases in addition to MS-PW with single-homed CEs (which is listed there as= use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Sta= tic PW Status Messages draft( if, for whatever reason, you do not wa= nt to, or cannot, use RFC 4447). Hence I doubt the need for yet another PW redundancy mechanism with narrow= scope of applicability. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.y= uxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Appli= cability to MS-PW" Hi all, The linear protection mechanism for LSP and PW(including MS-PW) should be th= e same and it is valuable to describe it clearly. BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". " Figure 1 illustrates such a scenario, where two MS-PWs are established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 respectively. Each PW segment is established over an LSP (e.g. PW- s12 over LSP12). " -----Original Message----- From: Daniel Cohn Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author? Looking forward to your feedback, Daniel This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9A38ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Dear Ma and= all,

Adding the PWE3 WG to= my response.

 

The PW redundancy mechanism support= s linear protection of MS-PWs as one of many additional application use case= s:

Appendix A of the PW redundancy Bit draft describes 5 application uses cases in= addition to MS-PW with single-homed CEs (which is listed there as use case= 5).

And it is equally appli= cable to IP/MPLS and MPLS - with the help of  the St= atic PW Status Messages draft( if, for whatever reason, you do not want=  to, or cannot, use RFC 4447).

 

Hence I doubt= the need for yet another PW redundancy  mechanism with narrow scope of= applicability.

 <= /o:p>

Regards,

     Sasha

 

<= p class=3DMsoNormal>From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] <= b>On Behalf Of ma.yuxia@zte.com.cn
Sent: Monday, June 13, 2011= 3:25 PM
To: mpls@ietf.org
Subject: Re: [mpls] Seeking f= eedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW"<= o:p>

 

<= p>Hi all,

The linear protection mechanism for LSP and PW(including MS-PW) sho= uld be the same and it is valuable to describe it clearly.

BTW, there i= s a typo, it is "T-PE Z" instead of "T-PE B".

 "
  Figure 1 illustrates such= a scenario, where two MS-PWs are
  established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4
  respec= tively. Each PW segment is established over an LSP (e.g. PW-
  s12 ove= r LSP12).
 "

-----Original Message-----
From: Daniel Cohn
Sent: Tuesday, May= 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS= -TP Linear Protection
Applicability to MS-PW"
Importance: High
Hi MPLSers,

I uploaded "MPLS-TP Linear Protection Applicabi= lity to MS-PW" I-D
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw= -protection-00)

The abstract goes:
<= br>One of the requirements of the MPLS transport profile [RFC 5654] is
to= provide linear protection for transport paths, which include both
LSPs a= nd PWs. The functional architecture described in [SurvivFwk]
is applicabl= e to both LSP and PWs, however [LinearProt] does not
explicitly describe= mechanisms for PW protection in MPLS-TP.
<= br>This document extends the applicability of the linear protection
mecha= nism described in [LinearProt] to MPLS-TP segmented PWs
(MS-PWs) as defi= ned in [RFC 6073].

Could you please review it and send feedback to th= e mailing list or
directly to the author?

Looking forward to your= feedback,

Daniel

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9A38ILPTMAIL02eci_-- From binnyjeshan@gmail.com Mon Jun 13 05:58:10 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6FC1F0C44; Mon, 13 Jun 2011 05:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8fOiHVBfQal; Mon, 13 Jun 2011 05:58:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 968611F0C3D; Mon, 13 Jun 2011 05:58:09 -0700 (PDT) Received: by yxt33 with SMTP id 33so643142yxt.31 for ; Mon, 13 Jun 2011 05:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Q36mHbhPccEYf6AdrexTUhzXrwvL+RA2MMsSvVl7/aw=; b=jQFVIfGRRV7jsHf3e1NjuZ8Qjd4t+uYJfGAVx0udhKUqRvZCZYlUlAZwSZ7AIvvxX5 r3Wd4kD3g2TWD44oJK1x0C5noFq2snNbbdqDLHhbj4RKfieTOP8uKs9syIIM136Fm4+B +uYkbdi5G0bkb2zuT9Md0M+N+KswI+jyJdGEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jWlWvcdZhsmH6rRRsjnbunYsmHIWGjI3kA5hoXz3ft6gsrR0NCe4T9oyzAl2NSSnKt zR6yMWNaK/8o8IoiIfKAbqDbCkk6BgP8l2/m9W6BI1cMYzvkYxZCWM+cSwSDRLdZBt5u Lvmsn+0FFDsjMxxjN0LuiF99OMChYtWX7VyGw= MIME-Version: 1.0 Received: by 10.101.138.14 with SMTP id q14mr5060715ann.49.1307969888534; Mon, 13 Jun 2011 05:58:08 -0700 (PDT) Received: by 10.100.226.6 with HTTP; Mon, 13 Jun 2011 05:58:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Jun 2011 18:28:08 +0530 Message-ID: From: binny jeshan To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=0016e6d27c62953fac04a5977843 Cc: "pwe3@ietf.org" , "mpls@ietf.org" , "ma.yuxia@zte.com.cn" Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 12:58:11 -0000 --0016e6d27c62953fac04a5977843 Content-Type: text/plain; charset=ISO-8859-1 Hello authors, I have a generic question on the *co-existence* of PW monitoring at the MS-PW level (PSMEG) and the individual segment level (PMEG). Firstly, I believe there is no such restriction on having co-existence in monitoring these independently.. Now lets say if a monitored mid segment (a simple PMEG) of a 5 segment MSPW fails, its quite possible that the PSMEG also detects it at the endpoints. Now, what would determine the switching priority? Wouldn't it become * costlier* if the PSMEG does a MS-PW level switching? Instead, one could prefer to switch to a backup path at a segment level itself. Is this addressed? Thanks, Binny. On 13 June 2011 18:13, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Dear Ma and all, > > Adding the PWE3 WG to my response. > > > > The PW redundancy mechanism supports linear protection of MS-PWs as one of > many additional application use cases: > > Appendix A of the PW redundancy Bit draftdescribes 5 application uses cases in addition to MS-PW with single-homed > CEs (which is listed there as use case 5). > > And it is equally applicable to IP/MPLS and MPLS - with the help of the Static > PW Status Messages draft( > if, for whatever reason, you do not want to, or cannot, use RFC 4447 > ). > > > > Hence I doubt the need for yet another PW redundancy mechanism with narrow > scope of applicability. > > > > Regards, > > Sasha > > > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf Of > *ma.yuxia@zte.com.cn > *Sent:* Monday, June 13, 2011 3:25 PM > *To:* mpls@ietf.org > *Subject:* Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection > Applicability to MS-PW" > > > > Hi all, > > The linear protection mechanism for LSP and PW(including MS-PW) should be > the same and it is valuable to describe it clearly. > > BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". > > " > Figure 1 illustrates such a scenario, where two MS-PWs are > established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 > respectively. Each PW segment is established over an LSP (e.g. PW- > s12 over LSP12). > " > > -----Original Message----- > From: Daniel Cohn > Sent: Tuesday, May 17, 2011 4:14 PM > To: mpls > Subject: Seeking feedback on I-D "MPLS-TP Linear Protection > Applicability to MS-PW" > Importance: High > > Hi MPLSers, > > I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D > (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) > > The abstract goes: > > One of the requirements of the MPLS transport profile [RFC 5654] is > to provide linear protection for transport paths, which include both > LSPs and PWs. The functional architecture described in [SurvivFwk] > is applicable to both LSP and PWs, however [LinearProt] does not > explicitly describe mechanisms for PW protection in MPLS-TP. > > This document extends the applicability of the linear protection > mechanism described in [LinearProt] to MPLS-TP segmented PWs > (MS-PWs) as defined in [RFC 6073]. > > Could you please review it and send feedback to the mailing list or > directly to the author? > > Looking forward to your feedback, > > Daniel > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --0016e6d27c62953fac04a5977843 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello authors,

I have a generic question on the co-existence = of PW monitoring at the MS-PW level (PSMEG) and the individual segment leve= l (PMEG). Firstly, I believe there is no such restriction on having co-exis= tence in monitoring these independently..

Now lets say if a monitored mid segment (a simple PMEG) of a 5 segment = MSPW fails, its quite possible that the PSMEG also detects it at the endpoi= nts. Now, what would determine the switching priority? Wouldn't it beco= me costlier if the PSMEG does a MS-PW level switching? Instead, one = could prefer to switch to a backup path at a segment level itself. Is this = addressed?

Thanks,
Binny.

On 13 June 2011 18:= 13, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wro= te:

Dear Ma and all,

Addin= g the PWE3 WG to my response.

=A0

The PW redundancy mechanism su= pports linear protection of MS-PWs as one of many additional application us= e cases:

Appen= dix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed= CEs (which is listed there as use case 5).

And i= t is equally applicable to IP/MPLS and MPLS - with the help of =A0the Static PW Status Messages draft( if, f= or whatever reason, you do not want =A0to, or cannot, use RFC = 4447).

=A0

Hence I doubt the need for yet another PW redundancy =A0mechanism with = narrow scope of applicability.

=A0

Regards,

=A0=A0=A0=A0 Sasha

=A0

From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf= Of ma.yuxia@z= te.com.cn
Sent: Monday, June 13, 2011 3:25 PM
To: mpls@ietf.org
Subject: Re: [= mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability= to MS-PW"

=A0

Hi all,

The linear protec= tion mechanism for LSP and PW(inclu= ding MS-PW) should be the same and it is valuable to describe it clearly.

BTW, there is a typo, it is "T-PE= Z" instead of "T-PE B". <= /span>

=A0"
=A0 Figure 1 illustrates such a scenario, where two MS-PWs are
=A0 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4
=A0 respectively. Each PW segment is established over an LSP (e.g. PW-
=A0 s12 over LSP12).
=A0"

-----Original Message-----
From: Daniel Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Su= bject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicabi= lity to MS-PW"
Importance: High

Hi MPLSers,

I uploade= d "MPLS-TP Linear Protection Applicability to MS-PW" I-D
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protect= ion-00)

The abstract goes:

One of the requirements of the = MPLS transport profile [RFC 5654] is
to provide linear protection for tr= ansport paths, which include both
LSPs and PWs. The functional architect= ure described in [SurvivFwk]
is applicable to both LSP and PWs, however [LinearProt] does not
explici= tly describe mechanisms for PW protection in MPLS-TP.

This document extends the applicability of the linear protection
mechani= sm described in [LinearProt] to MPLS-TP segmented PWs
(MS-PWs) as defin= ed in [RFC 6073].

Could you please review it and send feedback to th= e mailing list or
directly to the author?

Looking forward to your feedback,

D= aniel

This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


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


--0016e6d27c62953fac04a5977843-- From nurit.sprecher@nsn.com Mon Jun 13 06:02:34 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552BB21F84A8; Mon, 13 Jun 2011 06:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pFYwjmFGbm8; Mon, 13 Jun 2011 06:02:33 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8F17B21F84AC; Mon, 13 Jun 2011 06:02:32 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p5DD2Tdq005836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2011 15:02:29 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p5DD2StM016885; Mon, 13 Jun 2011 15:02:28 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 15:02:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC29CA.26091F69" Date: Mon, 13 Jun 2011 15:02:24 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskA= References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Alexander Vainshtein" , X-OriginalArrivalTime: 13 Jun 2011 13:02:28.0503 (UTC) FILETIME=[26070A70:01CC29CA] Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 13:02:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC29CA.26091F69 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 ------_=_NextPart_001_01CC29CA.26091F69 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

I would like to second Sasha.

End-to-end PW protection (with diverse paths) does not scale, and put = hard restrictions on the utilization of the resources. =  

MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. = Therefore, an obvious way to provide protection for a PW is to protect = the LSP that carries it. 

If the PW is a multi-segment PW, then LSP recovery can only protect = the PW in individual segments.  This means that a single LSP = recovery action cannot protect against a failure of a PW switching point = (an S-PE).

When protecting against an AC or T/S-PE failure by dual connectivity, = PW redundancy mechanisms provide means for the PEs to coordinate over = which LSP the traffic of the PW is carried.

I also doubt why there is a need for additional mechanism. =

Best regards,

Nurit

 

From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = ext Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 = PM
To: ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; = pwe3@ietf.org
Subject: Re: [PWE3] [mpls] Seeking feedback on = I-D "MPLS-TP LinearProtection Applicability to = MS-PW"

 

Dear Ma and all,

Adding the PWE3 WG to my response.

 

The PW redundancy mechanism supports linear protection of MS-PWs as = one of many additional application use cases:

Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed = there as use case 5).

And it is equally applicable to IP/MPLS and MPLS - with the help of =  the Static PW Status Messages draft( if, for whatever = reason, you do not want  to, or cannot, use RFC = 4447).

 

Hence I doubt the need for yet another PW redundancy  mechanism = with narrow scope of applicability.

 

Regards,

     Sasha

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ma.yuxia@zte.com.cn
Sent: Monday, June 13, 2011 3:25 = PM
To: mpls@ietf.org
Subject: Re: [mpls] Seeking = feedback on I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

 

Hi all,

The = linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

BTW, there = is a typo, it is "T-PE Z" instead of "T-PE B".

 &qu= ot;
  = Figure 1 illustrates such a scenario, where two MS-PWs are
  = established between T-PE A and T-PE B, = over S-PEs 1-2 and 3-4
  = respectively. Each PW segment is established over an LSP (e.g. = PW-
  = s12 over LSP12).
 &qu= ot;

-----Original Message-----
From: Daniel = Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: = Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability = to MS-PW"
Importance: High

Hi MPLSers,

I uploaded = "MPLS-TP Linear Protection Applicability to MS-PW" = I-D
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)
The abstract goes:

One of the requirements of the MPLS = transport profile [RFC 5654] is
to provide linear protection for = transport paths, which include both
LSPs and PWs. The functional = architecture described in [SurvivFwk]
is applicable to both LSP and = PWs, however [LinearProt] does not
explicitly describe mechanisms for = PW protection in MPLS-TP.

This document extends the applicability = of the linear protection
mechanism described in [LinearProt] to = MPLS-TP segmented PWs
(MS-PWs) as defined in [RFC = 6073].

Could you please review it and send feedback to the = mailing list or
directly to the author?

Looking forward to = your feedback,

Daniel

This e-mail = message is intended for the recipient only and contains information = which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by = e-mail, phone or fax, and then delete the original and all copies = thereof.

------_=_NextPart_001_01CC29CA.26091F69-- From binnyjeshan@gmail.com Mon Jun 13 06:31:30 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB799E8012; Mon, 13 Jun 2011 06:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrOPAFa9RBqN; Mon, 13 Jun 2011 06:31:29 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5099E8007; Mon, 13 Jun 2011 06:31:29 -0700 (PDT) Received: by yie30 with SMTP id 30so1205845yie.31 for ; Mon, 13 Jun 2011 06:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zqg45oH2ohCDPaIYxZTNC7ujPGS4+h5d2kLCSSqUpE0=; b=dIsUOwujnmO+5iLY5bMdvXdMorKMlGkOQjZLJqheWmdjUFitEEzZg493dPsER/6mh7 Y1n3zPoJg5yuW7jkuha38h3d3LsWrTRfKiwCHakjfsYkDmry7vM0s1wvMWnS7Ya1Nk6F GtWe/exVtX4LaDTJcWVZQ0s/RzXTY7XK4TGqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NuP8CpQ14OuyNlC/+1jhAVOLez4woWH4lsV5aL9uBEljEhOKXNQTB0feGR5tN5Kitk JPCydTwbX17Wv0swYuxRERMHJxs2gRtu4su0ZTiOlQvUSJiVRIXa2LN7QNDxqEljips2 bMUFPCiDqZDVW8wRm1Na8JMggUCT+GvG5ob5U= MIME-Version: 1.0 Received: by 10.101.175.33 with SMTP id c33mr5054575anp.93.1307971888682; Mon, 13 Jun 2011 06:31:28 -0700 (PDT) Received: by 10.100.226.6 with HTTP; Mon, 13 Jun 2011 06:31:28 -0700 (PDT) In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> Date: Mon, 13 Jun 2011 19:01:28 +0530 Message-ID: From: binny jeshan To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Content-Type: multipart/alternative; boundary=001636c5c006cd168904a597efba Cc: pwe3@ietf.org, mpls@ietf.org, ma.yuxia@zte.com.cn Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 13:31:31 -0000 --001636c5c006cd168904a597efba Content-Type: text/plain; charset=ISO-8859-1 Hello, Though on one side I'd think its costlier to do a MS-PW level protection considering the resource usages, pre-configuration and monitoring overload, on the other i would think - why wouldn't having such a mechanism help in case if a local repair procedure fails ( failure in protection switch) for a underlying broken LSP or a mid-PW segment. A provider would never hesitate look into his pocket to have an end-end level protection considering a risky situation for an high priority service that he runs on the MS-PW. Wouldn't he? I believe he could be only concerned in the view of giving precedence to efficient switching the server layers, and not messing up with multiple switches happening for one failure. -Binny. On 13 June 2011 18:32, Sprecher, Nurit (NSN - IL/Hod HaSharon) < nurit.sprecher@nsn.com> wrote: > Hi, > > I would like to second Sasha. > > End-to-end PW protection (with diverse paths) does not scale, and put hard > restrictions on the utilization of the resources. > > MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, > an obvious way to provide protection for a PW is to protect the LSP that > carries it. > > If the PW is a multi-segment PW, then LSP recovery can only protect the PW > in individual segments. This means that a single LSP recovery action cannot > protect against a failure of a PW switching point (an S-PE). > > When protecting against an AC or T/S-PE failure by dual connectivity, PW > redundancy mechanisms provide means for the PEs to coordinate over which LSP > the traffic of the PW is carried. > > I also doubt why there is a need for additional mechanism. > > Best regards, > > Nurit > > > > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On Behalf Of > *ext Alexander Vainshtein > *Sent:* Monday, June 13, 2011 3:43 PM > *To:* ma.yuxia@zte.com.cn > *Cc:* mpls@ietf.org; pwe3@ietf.org > *Subject:* Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP > LinearProtection Applicability to MS-PW" > > > > Dear Ma and all, > > Adding the PWE3 WG to my response. > > > > The PW redundancy mechanism supports linear protection of MS-PWs as one of > many additional application use cases: > > Appendix A of the PW redundancy Bit draftdescribes 5 application uses cases in addition to MS-PW with single-homed > CEs (which is listed there as use case 5). > > And it is equally applicable to IP/MPLS and MPLS - with the help of the Static > PW Status Messages draft( > if, for whatever reason, you do not want to, or cannot, use RFC 4447 > ). > > > > Hence I doubt the need for yet another PW redundancy mechanism with narrow > scope of applicability. > > > > Regards, > > Sasha > > > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf Of > *ma.yuxia@zte.com.cn > *Sent:* Monday, June 13, 2011 3:25 PM > *To:* mpls@ietf.org > *Subject:* Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection > Applicability to MS-PW" > > > > Hi all, > > The linear protection mechanism for LSP and PW(including MS-PW) should be > the same and it is valuable to describe it clearly. > > BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". > > " > Figure 1 illustrates such a scenario, where two MS-PWs are > established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 > respectively. Each PW segment is established over an LSP (e.g. PW- > s12 over LSP12). > " > > -----Original Message----- > From: Daniel Cohn > Sent: Tuesday, May 17, 2011 4:14 PM > To: mpls > Subject: Seeking feedback on I-D "MPLS-TP Linear Protection > Applicability to MS-PW" > Importance: High > > Hi MPLSers, > > I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D > (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) > > The abstract goes: > > One of the requirements of the MPLS transport profile [RFC 5654] is > to provide linear protection for transport paths, which include both > LSPs and PWs. The functional architecture described in [SurvivFwk] > is applicable to both LSP and PWs, however [LinearProt] does not > explicitly describe mechanisms for PW protection in MPLS-TP. > > This document extends the applicability of the linear protection > mechanism described in [LinearProt] to MPLS-TP segmented PWs > (MS-PWs) as defined in [RFC 6073]. > > Could you please review it and send feedback to the mailing list or > directly to the author? > > Looking forward to your feedback, > > Daniel > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --001636c5c006cd168904a597efba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

Though on one side I'd think its costlier to do a MS-PW level protectio= n considering the resource usages, pre-configuration and monitoring=20 overload, on the other i would think - why wouldn't having such a=20 mechanism help in case if a local repair procedure fails ( failure in prote= ction=20 switch) for a underlying broken LSP or a mid-PW segment. A provider=20 would never hesitate look into his pocket to have an end-end level=20 protection considering a risky situation for an high priority service=20 that he runs on the MS-PW. Wouldn't he? I believe he could be only conc= erned in the view of giving precedence to efficient switching the server la= yers, and not messing up with multiple switches happening for one failure.<= br>
-Binny.

On 13 June 2011 18:32, Sprecher, = Nurit (NSN - IL/Hod HaSharon) <nurit.sprecher@nsn.com> wrote:

Hi,

I would like = to second Sasha.

End-t= o-end PW protection (with diverse paths) does not scale, and put hard restr= ictions on the utilization of the resources. =A0

MPLS-TP PWs are carried acro= ss the network inside MPLS-TP LSPs. Therefore, an obvious way to provide pr= otection for a PW is to protect the LSP that carries it.=A0

If the PW is a multi-segment= PW, then LSP recovery can only protect the PW in individual segments.=A0 T= his means that a single LSP recovery action cannot protect against a failur= e of a PW switching point (an S-PE).

When = protecting against an AC or T/S-PE failure by dual connectivity, PW redunda= ncy mechanisms provide means for the PEs to coordinate over which LSP the t= raffic of the PW is carried.

I als= o doubt why there is a need for additional mechanism.

Best regards,=

Nurit=

=A0

From:= pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf= Of ext Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 PM
To: ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; pwe3@ietf.org
Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Lin= earProtection Applicability to MS-PW"

=

=A0

Dear Ma and all,

Addin= g the PWE3 WG to my response.

=A0

The PW redundancy mechanism su= pports linear protection of MS-PWs as one of many additional application us= e cases:

Appen= dix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed= CEs (which is listed there as use case 5).

And i= t is equally applicable to IP/MPLS and MPLS - with the help of =A0the Static PW Status Messages draft( if, f= or whatever reason, you do not want =A0to, or cannot, use RFC = 4447).

=A0

Hence I doubt the need for yet another PW redundancy =A0mechanism with = narrow scope of applicability.

=A0

Regards,

=A0=A0=A0=A0 Sasha

=A0

From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf= Of ma.yuxia@z= te.com.cn
Sent: Monday, June 13, 2011 3:25 PM
To: mpls@ietf.org
Subject: Re: [= mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability= to MS-PW"

=A0

Hi all,

The linear protection mechanism for LSP and PW(including MS-PW) should be the same and= it is valuable to describe it clearly.

BTW, there is a typo, it is "T-PE= Z" instead of "T-PE B". <= /span>

=A0"
=A0 Figure 1 illustrates such a scenario, where two MS-PWs are
=A0 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4
=A0 respectively. Each PW segment is established over an LSP (e.g. PW-
=A0 s12 over LSP12).
=A0"

-----Original Message-----
From: Daniel Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Su= bject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicabi= lity to MS-PW"
Importance: High

Hi MPLSers,

I uploade= d "MPLS-TP Linear Protection Applicability to MS-PW" I-D
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protect= ion-00)

The abstract goes:

One of the requirements of the = MPLS transport profile [RFC 5654] is
to provide linear protection for tr= ansport paths, which include both
LSPs and PWs. The functional architect= ure described in [SurvivFwk]
is applicable to both LSP and PWs, however [LinearProt] does not
explici= tly describe mechanisms for PW protection in MPLS-TP.

This document extends the applicability of the linear protection
mechani= sm described in [LinearProt] to MPLS-TP segmented PWs
(MS-PWs) as defin= ed in [RFC 6073].

Could you please review it and send feedback to th= e mailing list or
directly to the author?

Looking forward to your feedback,

D= aniel

This e-mail message is intended for the recipient= only and contains information which is CONFIDENTIAL and which may be propr= ietary to ECI Telecom. If you have received this transmission in error, ple= ase inform us by e-mail, phone or fax, and then delete the original and all= copies thereof.


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


--001636c5c006cd168904a597efba-- From nurit.sprecher@nsn.com Mon Jun 13 06:38:56 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CEC9E8028; Mon, 13 Jun 2011 06:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPIPI113eM7a; Mon, 13 Jun 2011 06:38:55 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF4C9E8009; Mon, 13 Jun 2011 06:38:54 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p5DDcpLg015945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2011 15:38:51 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p5DDcpHr006124; Mon, 13 Jun 2011 15:38:51 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 15:38:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC29CF.3ADAC149" Date: Mon, 13 Jun 2011 15:38:48 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403F64991@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" Thread-Index: AcwpzjaHFo2CCA4qTaOKh1pH4XerfgAAG31Q References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext binny jeshan" X-OriginalArrivalTime: 13 Jun 2011 13:38:50.0976 (UTC) FILETIME=[3AE1FE00:01CC29CF] Cc: pwe3@ietf.org, mpls@ietf.org, ma.yuxia@zte.com.cn Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 13:38:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC29CF.3ADAC149 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, For end-to-end, you can do it on the client service level.=20 If the intention is to protect against a S/T-PE failure, I think the solution should be efficient and not necessarily on the end-to-end PW level.=20 We may come soon with idea how to do it.=20 Best regards, Nurit =20 From: ext binny jeshan [mailto:binnyjeshan@gmail.com]=20 Sent: Monday, June 13, 2011 4:31 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: ext Alexander Vainshtein; ma.yuxia@zte.com.cn; mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Hello, Though on one side I'd think its costlier to do a MS-PW level protection considering the resource usages, pre-configuration and monitoring overload, on the other i would think - why wouldn't having such a mechanism help in case if a local repair procedure fails ( failure in protection switch) for a underlying broken LSP or a mid-PW segment. A provider would never hesitate look into his pocket to have an end-end level protection considering a risky situation for an high priority service that he runs on the MS-PW. Wouldn't he? I believe he could be only concerned in the view of giving precedence to efficient switching the server layers, and not messing up with multiple switches happening for one failure. -Binny. On 13 June 2011 18:32, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 ------_=_NextPart_001_01CC29CF.3ADAC149 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

For end-to-end, you can do it on the client service level. =

If the intention is to protect against a S/T-PE  failure, I = think the solution should be efficient and not necessarily on the = end-to-end PW level.

We may come soon with idea how to do it.

Best regards,

Nurit

 

From:= = ext binny jeshan [mailto:binnyjeshan@gmail.com]
Sent: Monday, = June 13, 2011 4:31 PM
To: Sprecher, Nurit (NSN - IL/Hod = HaSharon)
Cc: ext Alexander Vainshtein; ma.yuxia@zte.com.cn; = mpls@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] [PWE3] = Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to = MS-PW"

 

Hello,

Though on one side I'd = think its costlier to do a MS-PW level protection considering the = resource usages, pre-configuration and monitoring overload, on the other = i would think - why wouldn't having such a mechanism help in case if a = local repair procedure fails ( failure in protection switch) for a = underlying broken LSP or a mid-PW segment. A provider would never = hesitate look into his pocket to have an end-end level protection = considering a risky situation for an high priority service that he runs = on the MS-PW. Wouldn't he? I believe he could be only concerned in the = view of giving precedence to efficient switching the server layers, and = not messing up with multiple switches happening for one = failure.

-Binny.

On 13 = June 2011 18:32, Sprecher, Nurit (NSN - IL/Hod HaSharon) <nurit.sprecher@nsn.com> = wrote:

Hi,

I would like to second = Sasha.

End-to-end PW protection (with = diverse paths) does not scale, and put hard restrictions on the = utilization of the resources.  

MPLS-TP PWs are carried across = the network inside MPLS-TP LSPs. Therefore, an obvious way to provide = protection for a PW is to protect the LSP that carries it.  =

If the PW is a multi-segment = PW, then LSP recovery can only protect the PW in individual = segments.  This means that a single LSP recovery action cannot = protect against a failure of a PW switching point (an = S-PE).

When protecting against an AC = or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide = means for the PEs to coordinate over which LSP the traffic of the PW is = carried.

I also doubt why there is a = need for additional mechanism.

Best = regards,

Nurit

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext = Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 = PM
To: ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; pwe3@ietf.org
Subject: Re: [PWE3] [mpls] = Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to = MS-PW"

 <= /o:p>

Dear Ma and = all,

Adding the PWE3 WG to my = response.

 

The PW redundancy mechanism = supports linear protection of MS-PWs as one of many additional = application use cases:

Appendix A of the PW redundancy Bit draft describes = 5 application uses cases in addition to MS-PW with single-homed CEs = (which is listed there as use case 5).

And it is equally applicable to = IP/MPLS and MPLS - with the help of  the Static PW Status Messages = draft( if, for whatever reason, you do not want  to, or cannot, = use RFC 4447).

 

Hence I doubt the need for yet = another PW redundancy  mechanism with narrow scope of = applicability.

 

Regards,

     = Sasha

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn
Sent: Monday, June = 13, 2011 3:25 PM
To: mpls@ietf.org
Subject: Re: [mpls] = Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

 <= /o:p>

Hi all, =

The linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

BTW, there is a typo, it is "T-PE = Z" instead of "T-PE B". =

 " =
  Figure 1 illustrates such a = scenario, where two MS-PWs are
  established between T-PE A and = T-PE B, over S-PEs 1-2 and 3-4 =
  respectively. Each PW = segment is established over an LSP (e.g. PW-
  s12 over LSP12).
 " =

-----Original = Message-----
From: Daniel Cohn
Sent: Tuesday, May 17, 2011 4:14 = PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear = Protection
Applicability to MS-PW"
Importance: High

Hi = MPLSers,

I uploaded "MPLS-TP Linear Protection Applicability = to MS-PW" I-D
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protec= tion-00)

The abstract goes:

One of the requirements of the MPLS = transport profile [RFC 5654] is
to provide linear protection for = transport paths, which include both
LSPs and PWs. The functional = architecture described in [SurvivFwk]
is applicable to both LSP and = PWs, however [LinearProt] does not
explicitly describe mechanisms for = PW protection in MPLS-TP.

This document extends the applicability = of the linear protection
mechanism described in [LinearProt] to = MPLS-TP segmented PWs
(MS-PWs) as defined in [RFC = 6073].

Could you please review it and send feedback to the = mailing list or
directly to the author?

Looking forward to = your feedback,

Daniel

This e-mail = message is intended for the recipient only and contains information = which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by = e-mail, phone or fax, and then delete the original and all copies = thereof.


______________________________________= _________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

 

------_=_NextPart_001_01CC29CF.3ADAC149-- From DanielC@orckit.com Mon Jun 13 07:55:05 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF60111E8090; Mon, 13 Jun 2011 07:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=1.093, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmGB42tfqr8S; Mon, 13 Jun 2011 07:55:01 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id AB04411E8075; Mon, 13 Jun 2011 07:55:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC29DA.15F28627" Date: Mon, 13 Jun 2011 17:54:56 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> In-reply-to: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygA== References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> From: "Daniel Cohn" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Alexander Vainshtein" , Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 14:55:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC29DA.15F28627 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Thanks all for the feedback. I believe we all agree that PW protection is only required in the event of S-PE failure at an MS-PW - this is clearly stated in the draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW protection requirements. =20 First of all a word on scalability. Please note that in an MPLS-TP environment without a control plane, the PW redundancy mechanism must also rely on proactive connectivity check for fast failure detection to meet the sub-50 ms requirement. Therefore any scalability considerations that apply to the PW protection draft apply to the PW redundancy draft as well. Also wrt scalability, there is no such thing as "scales" or "doesn't scale" - scalability is not a binary concept. You can say that PW protection scales worse than LSP protection, just like you can say that LSP protection scales worse than interface protection. Which didn't stop IETF from defining LSP protection for scenarios where interface protection doesn't do the job. =20 Now let's turn our attention back to whether the PW redundancy draaft can be used to meet MPLS-TP PW protection requirements. I can identify the following reasons why in its current form it doesn't: =20 - It explicitly ("outside the scope") does not define protection triggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79 - It does not support the ability to distinguish between different types of triggers (i.e. one end doesn't know why the other end triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially important to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP Requirements), req #65 - It's a two-phase protocol, with the consequent impact on timing - It doesn't define retransmission of protection coordination messages, so loss of a single PDU can result in switchover not taking place, thus not supporting sub-50 ms recovery in this case =20 In summary, PW redundancy was not designed with TP requirements in mind, and as such does not meet the TP requirements. Of course modifications may be introduced, but why reinvent the wheel when there is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards track that supports all the above requirements and can be applied to MS-PW protection with minor modifications? =20 Regards, =20 Daniel =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" =20 Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 ------_=_NextPart_001_01CC29DA.15F28627 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Thanks all for the feedback. I believe we all agree that PW = protection is only required in the event of S-PE failure at an MS-PW = – this  is clearly stated in the draft. Now, both Sasha and = Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW = protection requirements.

 

First of all a word on scalability. Please note that in an MPLS-TP = environment without a control plane, the PW redundancy mechanism must = also rely on proactive connectivity check for fast failure detection to =  meet the sub-50 ms requirement. Therefore any scalability = considerations that apply to the PW protection draft apply to the PW = redundancy draft as well.

Also wrt scalability, there is no such thing as “scales” = or “doesn’t scale” – scalability is not a binary = concept. You can say that PW protection scales worse than LSP = protection, just like you can say that LSP protection scales worse than = interface protection. Which didn’t stop IETF from defining LSP = protection for scenarios where interface protection doesn’t do the = job.

 

Now let’s turn our attention back to whether the PW redundancy = draaft can be used to meet MPLS-TP PW protection requirements. I can = identify the following reasons why in its current form it = doesn’t:

 

-          = It explicitly (“outside the scope”) does not define = protection triggers and how to handle coexisting triggers, as requested = in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and = #79

-          = It does not support the ability to distinguish between different = types of triggers (i.e. one end doesn’t know why the other end = triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req = #77

-          = It does not define revertive/nonrevertive behavior, as requested in = RFC 5654 (MPLS-TP Requirements), req #64

-          = It does not define holdoff support, which is especially important to = avoid race conditions with LSP protection when it = exists

-          = It doesn’t support 1+1 mode, as requested in RFC 5654 (MPLS-TP = Requirements), req #65

-          = It’s a two-phase protocol, with the consequent impact on = timing

-          = It doesn’t define retransmission of protection coordination = messages, so loss of a single PDU can result in switchover not taking = place, thus not supporting sub-50 ms recovery in this = case

 

In summary, PW redundancy was not designed with TP requirements in = mind, and as such does not meet the TP requirements. Of course = modifications may be introduced, but why reinvent the wheel when there = is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards = track that supports all the above requirements and can be applied to = MS-PW protection with minor modifications?

 

Regards,

 

Daniel

 

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Monday, June = 13, 2011 4:02 PM
To: ext Alexander Vainshtein; = ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; = pwe3@ietf.org
Subject: Re: [mpls] [PWE3] Seeking feedback on = I-D "MPLS-TPLinearProtection Applicability to = MS-PW"

 

Hi,

I would like to second Sasha.

End-to-end PW protection (with diverse paths) does not scale, and put = hard restrictions on the utilization of the resources. =  

MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. = Therefore, an obvious way to provide protection for a PW is to protect = the LSP that carries it. 

If the PW is a multi-segment PW, then LSP recovery can only protect = the PW in individual segments.  This means that a single LSP = recovery action cannot protect against a failure of a PW switching point = (an S-PE).

When protecting against an AC or T/S-PE failure by dual connectivity, = PW redundancy mechanisms provide means for the PEs to coordinate over = which LSP the traffic of the PW is carried.

I also doubt why there is a need for additional mechanism. =

Best regards,

Nurit

 

From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = ext Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 = PM
To: ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; = pwe3@ietf.org
Subject: Re: [PWE3] [mpls] Seeking feedback on = I-D "MPLS-TP LinearProtection Applicability to = MS-PW"

 

Dear Ma and all,

Adding the PWE3 WG to my response.

 

The PW redundancy mechanism supports linear protection of MS-PWs as = one of many additional application use cases:

Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed = there as use case 5).

And it is equally applicable to IP/MPLS and MPLS - with the help of =  the Static PW Status Messages draft( if, for whatever = reason, you do not want  to, or cannot, use RFC = 4447).

 

Hence I doubt the need for yet another PW redundancy  mechanism = with narrow scope of applicability.

 

Regards,

     Sasha

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ma.yuxia@zte.com.cn
Sent: Monday, June 13, 2011 3:25 = PM
To: mpls@ietf.org
Subject: Re: [mpls] Seeking = feedback on I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

 

Hi all,

The = linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

BTW, there = is a typo, it is "T-PE Z" instead of "T-PE B".

 &qu= ot;
  = Figure 1 illustrates such a scenario, where two MS-PWs are
  = established between T-PE A and T-PE B, = over S-PEs 1-2 and 3-4
  = respectively. Each PW segment is established over an LSP (e.g. = PW-
  = s12 over LSP12).
 &qu= ot;

-----Original Message-----
From: Daniel = Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: = Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability = to MS-PW"
Importance: High

Hi MPLSers,

I uploaded = "MPLS-TP Linear Protection Applicability to MS-PW" = I-D
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)
The abstract goes:

One of the requirements of the MPLS = transport profile [RFC 5654] is
to provide linear protection for = transport paths, which include both
LSPs and PWs. The functional = architecture described in [SurvivFwk]
is applicable to both LSP and = PWs, however [LinearProt] does not
explicitly describe mechanisms for = PW protection in MPLS-TP.

This document extends the applicability = of the linear protection
mechanism described in [LinearProt] to = MPLS-TP segmented PWs
(MS-PWs) as defined in [RFC = 6073].

Could you please review it and send feedback to the = mailing list or
directly to the author?

Looking forward to = your feedback,

Daniel

This e-mail = message is intended for the recipient only and contains information = which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by = e-mail, phone or fax, and then delete the original and all copies = thereof.

------_=_NextPart_001_01CC29DA.15F28627-- From Alexander.Vainshtein@ecitele.com Mon Jun 13 08:11:10 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EC711E8090; Mon, 13 Jun 2011 08:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFYK4UPxd41Q; Mon, 13 Jun 2011 08:11:05 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 98D7C11E808C; Mon, 13 Jun 2011 08:11:03 -0700 (PDT) X-AuditID: 93eaf2e8-b7c74ae000000a6f-06-4df628248b4e Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 30.71.02671.42826FD4; Mon, 13 Jun 2011 18:09:24 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 13 Jun 2011 18:11:01 +0300 From: Alexander Vainshtein To: Daniel Cohn Date: Mon, 13 Jun 2011 18:10:59 +0300 Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpw Message-ID: References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9AB7ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLsWRmVeSWpSXmKPExsUy+dWnL7oqGt98DRa/krBouLSYyeLrjJvM FreWrmS1uH1/O7tF36ctLA6sHkuW/GTy+Ln+KrtH94bJzB5r9v1gCWCJamC0SczLyy9JLElV SEktTrZVCijKLEtMrlRSyEyxVTJUUijISUxOzU3NK7FVSiwoSM1LUbLjsgEKZuYppOYl56dk 5qXbKnkG++taWJha6hoq2akpGxpbc4VkZBYrpOrmJmbmKOSmFhcnpqcqAEVATs9LSU1RSMsv UijJSFUoSpjMnDHhz2+Wgk+bmSq+TP/I3sDYO4mpi5GTQ0LAROLLtR/MELaYxIV769m6GLk4 hAR2M0rsuDqNEcKZxijR97gBrINNwFZi0+q7bCC2iICKxMZrH9lBbGaBnYwSV874gNgsAqoS bx6fBprKwSEskCqxYkYYRHmaxPSOHqhWN4nJ/UvARvIK+Es8fTwfavFEJomfLy6CJTgFHCQO LTkPNp8R6Lrvp9YwQewSl7j1ZD7UBwISS/ach/pAVOLl43+sEPWiEnfa1zNC1OdLPJvWwAyx TFDi5MwnLBD1khIHV9xgmcAoNgvJ2FlIWmYhaYGI60gs2P2JDcLWlli28DUzjH3mwGMmZPEF jOyrGEUzcwpKknLTDYz0UpMzS1JzUvWS83M3MULS1YsdjLfPaB5iFOBgVOLhPXT+i68Qa2JZ cWXuIUZJDiYlUV4u9W++QnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4e18BlfOmJFZWpRblw6Rc gaE/kVmKOzkflAxK4o0NDHBzlMR5u5Pf+AoJpAMTZ3ZqakFqEcwcGQ4OJQnegyDrBYtS01Mr 0jJzShDSTBycIGfwAJ2xE6SGt7ggMbc4Mx0if4rRmOPvnE2HGDkmLwOSQix5+XmpUuK8s0BK BUBKM0rz4KaB8lj9////XzGKA4NBmPcQSBUPMBnDzXsFtIoJaJVA6WeQVcCsBJeSamAUjdZO EDsXxPHg8Yx1ltc8dp8LLQrwnsL6cE9aJtvlOX/YlvuZCatOVT6b4Dzb21moqIe/6aag5uL8 OaXzCl3kdUvDJm2ftPvbycNzjySbB99fd1SuZLZcq6Odpsemq8ePGYfs+qM72cqhMMTzlbV7 iEZh6xU24dV9+/a6HZnPv5Rf3K06KUaJpTgj0VCLuag4EQDhPw/hPgQAAA== Cc: "ma.yuxia@zte.com.cn" , "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:11:10 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9AB7ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Daniel and all, Please see some comments inline below. Regards, Sasha From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@= zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi, Thanks all for the feedback. I believe we all agree that PW protection is on= ly required in the event of S-PE failure at an MS-PW - this is clearly stat= ed in the draft. Now, both Sasha and Nurit mention that the PW redundancy me= chanism can meet the MPLS-TP PW protection requirements. First of all a word on scalability. Please note that in an MPLS-TP environme= nt without a control plane, the PW redundancy mechanism must also rely on pr= oactive connectivity check for fast failure detection to meet the sub-50 ms= requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here. Det= ecting S-PE failures based on the control plane would not fast enough. Therefore any scalability considerations that apply to the PW protection dra= ft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised th= e scalability issue. My issue was limited applicability scope when compared= to PW redundancy. E.g., the PW redundancy mechanisms take care of dual-home= d CEs in SS- and MS-PWs - something that liner protection of PWs cannot do. Also wrt scalability, there is no such thing as "scales" or "doesn't scale"= - scalability is not a binary concept. You can say that PW protection scale= s worse than LSP protection, just like you can say that LSP protection scale= s worse than interface protection. Which didn't stop IETF from defining LSP= protection for scenarios where interface protection doesn't do the job. Now let's turn our attention back to whether the PW redundancy draaft can be= used to meet MPLS-TP PW protection requirements. I can identify the followi= ng reasons why in its current form it doesn't: - It explicitly ("outside the scope") does not define protection tr= iggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS= -TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinated= protection switching happens. - It does not support the ability to distinguish between different= types of triggers (i.e. one end doesn't know why the other end triggered sw= itch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested= in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially important= to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP Re= quirements), req #65 [[[Sasha]]] All these claims are correct - and this should not be a surpris= e, because MPLS-TP requirements have been defined much later than the PW red= undancy mechanism. But I do not think that this justifies co-existence of two different mechani= sms. - It's a two-phase protocol, with the consequent impact on timing[[= [Sasha]]] Could you please elaborate? - It doesn't define retransmission of protection coordination messa= ges, so loss of a single PDU can result in switchover not taking place, thus= not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which bene= fits from TCP retransmissions) or on top of static PW status messages (where= retransmission is defined). In summary, PW redundancy was not designed with TP requirements in mind, and= as such does not meet the TP requirements. Of course modifications may be i= ntroduced, but why reinvent the wheel when there is a protocol (draft-ietf-m= pls-tp-linear-protection-06) in the standards track that supports all the ab= ove requirements and can be applied to MS-PW protection with minor modificat= ions? [[[Sasha]]] As I said, because the applicability scope is by far too narrow= to justify a dedicated protocol. Regards, Daniel From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spre= cher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard r= estrictions on the utilization of the resources. MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, a= n obvious way to provide protection for a PW is to protect the LSP that carr= ies it. If the PW is a multi-segment PW, then LSP recovery can only protect the PW i= n individual segments. This means that a single LSP recovery action cannot= protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW red= undancy mechanisms provide means for the PEs to coordinate over which LSP th= e traffic of the PW is carried. I also doubt why there is a need for additional mechanism. Best regards, Nurit From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext= Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection= Applicability to MS-PW" Dear Ma and all, Adding the PWE3 WG to my response. The PW redundancy mechanism supports linear protection of MS-PWs as one of m= any additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses= cases in addition to MS-PW with single-homed CEs (which is listed there as= use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Sta= tic PW Status Messages draft( if, for whatever reason, you do not wa= nt to, or cannot, use RFC 4447). Hence I doubt the need for yet another PW redundancy mechanism with narrow= scope of applicability. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.y= uxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Appli= cability to MS-PW" Hi all, The linear protection mechanism for LSP and PW(including MS-PW) should be th= e same and it is valuable to describe it clearly. BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". " Figure 1 illustrates such a scenario, where two MS-PWs are established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 respectively. Each PW segment is established over an LSP (e.g. PW- s12 over LSP12). " -----Original Message----- From: Daniel Cohn Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author? Looking forward to your feedback, Daniel This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9AB7ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Daniel and a= ll,

Please see some comments= inline below.

 

Regards,

     Sasha=

 

From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, June 13, 2011 5:55 PM
To: Sprecher, Nurit (N= SN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; pwe3@ietf.org
Subject: RE: [mpls] [PWE3] Seeking= feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW"<= o:p>

 

<= p class=3DMsoNormal>Hi,

 

Thanks all for the= feedback. I believe we all agree that PW protection is only required in the= event of S-PE failure at an MS-PW – this  is clearly stated in t= he draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism= can meet the MPLS-TP PW protection requirements.

 

First of all a word on scalability. Please note that in an MPLS-TP environm= ent without a control plane, the PW redundancy mechanism must also rely on p= roactive connectivity check for fast failure detection to  meet the sub= -50 ms requirement. [[[Sasha]]] IMO there is nothing spec= ific to MPLS-TP here. Detecting S-PE failures based on the control plane wou= ld  not fast enough.

= Therefore any scalability considerations that apply to the PW protecti= on draft apply to the PW redundancy draft as well.[[[Sa= sha]]] I have not raised the scalability issue. My issue was limited applica= bility scope when compared to PW redundancy. E.g., the PW redundancy mechani= sms take care of dual-homed CEs in SS- and MS-PWs – something that lin= er protection of PWs cannot do.

Also wrt scalability, there is no such thing as = 220;scales” or “doesn’t scale” – scalability i= s not a binary concept. You can say that PW protection scales worse than LSP= protection, just like you can say that LSP protection scales worse than int= erface protection. Which didn’t stop IETF from defining LSP protection= for scenarios where interface protection doesn’t do the job.

 

Now let’s turn our attention back to whether the PW= redundancy draaft can be used to meet MPLS-TP PW protection requirements. I= can identify the following reasons why in its current form it doesn’t= :

 

-      &nb= sp;   It explicitly (“outside the scope”) does not define protection= triggers and how to handle coexisting triggers, as requested in RFC 5654 (M= PLS-TP Requirements), reqs #75, #76 and #79

[[[Sasha]]] So what? Definition of triggers is orthogo= nal to how coordinated protection switching happens.

-   &nbs= p;      It does not support the ability to distinguish between diff= erent types of triggers (i.e. one end doesn’t know why the other end t= riggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req #77

-   &nb= sp;      It does not define revertive/nonrevertive behavior, as r= equested in RFC 5654 (MPLS-TP Requirements), req #64

-       =    It= does not define holdoff support, which is especially important to avoid rac= e conditions with LSP protection when it exists

<= ![if !supportLists]>-        =   It doesn&= #8217;t support 1+1 mode, as requested in RFC 5654 (MPLS-TP Requirements), r= eq #65

[[[Sasha]]] All these claims are correct – a= nd  this should not be a surprise, because MPLS-TP requirements have be= en defined much later than the PW redundancy mechanism.

But I do not think that this just= ifies co-existence of two different mechanisms.

-    &nb= sp;     <= /span>It’s a two-phase protocol, with the consequent impact on t= iming[[[Sasha]]] Could you please elaborate?

-It doesn’t define retransmis= sion of protection coordination messages, so loss of a single PDU can result= in switchover not taking place, thus not supporting sub-50 ms recovery in t= his case

[[[Sasha]]] T= he PW redundancy protocol runs either on top of LDP (which benefits from TCP= retransmissions) or on top of static PW status messages (where retransmissi= on is defined).

 

In summary,= PW redundancy was not designed with TP requirements in mind, and as such do= es not meet the TP requirements. Of course modifications may be introduced,= but why reinvent the wheel when there is a protocol (draft-ietf-mpls-tp-lin= ear-protection-06) in the standards track that supports all the above requir= ements and can be applied to MS-PW protection with minor modifications?=

[[[Sasha]]] As I said, bec= ause the applicability scope is by far too narrow to justify a dedicated pro= tocol.

 

Regards,<= /span>

 

Daniel

=  

 

From: mpls-bounces@ietf.org [mailto:mpls-bou= nces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)Sent: Monday, June 13, 2011 4:02 PM
To: ext Alexander Vai= nshtein; ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; pwe3@ietf.org
<= b>Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinear= Protection Applicability to MS-PW"

 

Hi,<= /o:p>

I would like to second Sasha.

End-to-end PW protection (with= diverse paths) does not scale, and put hard restrictions on the utilization= of the resources.  

MP= LS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an= obvious way to provide protection for a PW is to protect the LSP that carri= es it. 

If the PW is a= multi-segment PW, then LSP recovery can only protect the PW in individual s= egments.  This means that a single LSP recovery action cannot protect a= gainst a failure of a PW switching point (an S-PE).

When protecting against an AC or T/S-PE failure by= dual connectivity, PW redundancy mechanisms provide means for the PEs to co= ordinate over which LSP the traffic of the PW is carried. =

I also doubt why there is a need for addition= al mechanism.

Best regards,=

Nurit

=

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Be= half Of ext Alexander Vainshtein
Sent: Monday, June 13, 2011 3= :43 PM
To: ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; pwe3@i= etf.org
Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "M= PLS-TP LinearProtection Applicability to MS-PW"

 

Dear Ma and all,

Adding t= he PWE3 WG to my response.

<= o:p> 

The PW redundancy mech= anism supports linear protection of MS-PWs as one of many additional applica= tion use cases:

Appendix A o= f the PW redundancy Bit draft describes 5 application u= ses cases in addition to MS-PW with single-homed CEs (which is listed there= as use case 5).

And it is e= qually applicable to IP/MPLS and MPLS - with the help of  the Static PW Status Messages draft( if, for whatever reason, yo= u do not want  to, or cannot, use RFC 4447).

 

H= ence I doubt the need for yet another PW redundancy  mechanism with nar= row scope of applicability.

 

Regards,<= /span>

     Sasha

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces= @ietf.org] On Behalf Of ma.yuxia@zte.com.cn
Sent: Monday, J= une 13, 2011 3:25 PM
To: mpls@ietf.org
Subject: Re: [mpl= s] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to= MS-PW"

&nbs= p;

Hi all,

The linear protection mechanism for LSP and PW(includi= ng MS-PW) should be the same and it is valuable to describe it clearly.

BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".

 "
  Figure 1 illu= strates such a scenario, where two MS-PWs are
  established between T-= PE A and T-PE B, over S-PEs 1-2 and 3-4
&= nbsp; respectively. Each PW segment is established over an LSP (e.g. PW-
&n= bsp; s12 over LSP12).
 "

-----Original Message-----
From: Daniel Cohn
Sent:= Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I= -D "MPLS-TP Linear Protection
Applicability to MS-PW"
Import= ance: High

Hi MPLSers,

I uploaded "MPLS-TP Linear Protect= ion Applicability to MS-PW" I-D
(http://tools.ietf.org/html/draft-co= hn-mpls-tp-pw-protection-00)

The abstract goes:

One of the requirements of the MPLS transport profile [RFC 5= 654] is
to provide linear protection for transport paths, which include b= oth
LSPs and PWs. The functional architecture described in [SurvivFwk]is applicable to both LSP and PWs, however [LinearProt] does not
explici= tly describe mechanisms for PW protection in MPLS-TP.

This document extends the applicability of the linear protect= ion
mechanism described in [LinearProt] to MPLS-TP segmented PWs
(MS-= PWs) as defined in [RFC 6073].

Could you please review it and send fe= edback to the mailing list or
directly to the author?

Looking for= ward to your feedback,

Daniel

This e-= mail message is intended for the recipient only and contains information whi= ch is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have= received this transmission in error, please inform us by e-mail, phone or f= ax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9AB7ILPTMAIL02eci_-- From nurit.sprecher@nsn.com Mon Jun 13 08:23:39 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA67521F84A2; Mon, 13 Jun 2011 08:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.997 X-Spam-Level: X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiZ9CLZ31lVI; Mon, 13 Jun 2011 08:23:33 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A62F621F8493; Mon, 13 Jun 2011 08:23:32 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p5DFNS69019138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2011 17:23:28 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p5DFNRtA028980; Mon, 13 Jun 2011 17:23:27 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Jun 2011 17:23:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC29DD.D836CE89" Date: Mon, 13 Jun 2011 17:23:25 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403F64A13@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpwAADpDNA= References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Alexander Vainshtein" , "Daniel Cohn" X-OriginalArrivalTime: 13 Jun 2011 15:23:27.0803 (UTC) FILETIME=[D829C8B0:01CC29DD] Cc: ma.yuxia@zte.com.cn, mpls@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:23:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC29DD.D836CE89 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable If you do it on the client service layer, you can protect also the T-PE... Why do you want to protect only against a failure of the S-PE? The PW starts at the T-PE... =20 From: ext Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, June 13, 2011 6:11 PM To: Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" =20 Daniel and all, Please see some comments inline below. =20 Regards, Sasha =20 From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" =20 Hi, =20 Thanks all for the feedback. I believe we all agree that PW protection is only required in the event of S-PE failure at an MS-PW - this is clearly stated in the draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW protection requirements. =20 First of all a word on scalability. Please note that in an MPLS-TP environment without a control plane, the PW redundancy mechanism must also rely on proactive connectivity check for fast failure detection to meet the sub-50 ms requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here. Detecting S-PE failures based on the control plane would not fast enough. Therefore any scalability considerations that apply to the PW protection draft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised the scalability issue. My issue was limited applicability scope when compared to PW redundancy. E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS- and MS-PWs - something that liner protection of PWs cannot do. Also wrt scalability, there is no such thing as "scales" or "doesn't scale" - scalability is not a binary concept. You can say that PW protection scales worse than LSP protection, just like you can say that LSP protection scales worse than interface protection. Which didn't stop IETF from defining LSP protection for scenarios where interface protection doesn't do the job. =20 Now let's turn our attention back to whether the PW redundancy draaft can be used to meet MPLS-TP PW protection requirements. I can identify the following reasons why in its current form it doesn't: =20 - It explicitly ("outside the scope") does not define protection triggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinated protection switching happens. - It does not support the ability to distinguish between different types of triggers (i.e. one end doesn't know why the other end triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially important to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP Requirements), req #65=20 [[[Sasha]]] All these claims are correct - and this should not be a surprise, because MPLS-TP requirements have been defined much later than the PW redundancy mechanism.=20 But I do not think that this justifies co-existence of two different mechanisms. - It's a two-phase protocol, with the consequent impact on timing[[[Sasha]]] Could you please elaborate?=20 - It doesn't define retransmission of protection coordination messages, so loss of a single PDU can result in switchover not taking place, thus not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which benefits from TCP retransmissions) or on top of static PW status messages (where retransmission is defined).=20 =20 In summary, PW redundancy was not designed with TP requirements in mind, and as such does not meet the TP requirements. Of course modifications may be introduced, but why reinvent the wheel when there is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards track that supports all the above requirements and can be applied to MS-PW protection with minor modifications? [[[Sasha]]] As I said, because the applicability scope is by far too narrow to justify a dedicated protocol. =20 Regards, =20 Daniel =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" =20 Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 ------_=_NextPart_001_01CC29DD.D836CE89 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

If you do it on the client service layer, you can protect also the = T-PE…

Why do you want to protect only against a failure of the S-PE? The PW = starts at the T-PE…

 

From:= = ext Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] =
Sent: Monday, June 13, 2011 6:11 PM
To: Daniel = Cohn
Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - = IL/Hod HaSharon); ma.yuxia@zte.com.cn
Subject: RE: [mpls] = [PWE3] Seeking feedback on I-D = "MPLS-TPLinearProtectionApplicability to = MS-PW"

 

Daniel and all,

Please see some comments inline below.

 

Regards,

     Sasha

 

From:= = Daniel Cohn [mailto:DanielC@orckit.com]
Sent: Monday, June = 13, 2011 5:55 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); = Alexander Vainshtein; ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; = pwe3@ietf.org
Subject: RE: [mpls] [PWE3] Seeking feedback on = I-D "MPLS-TPLinearProtection Applicability to = MS-PW"

 

Hi,

 

Thanks all for the feedback. I believe we all agree that PW = protection is only required in the event of S-PE failure at an MS-PW = – this  is clearly stated in the draft. Now, both Sasha and = Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW = protection requirements.

 

First of all a word on scalability. Please note that in an MPLS-TP = environment without a control plane, the PW redundancy mechanism must = also rely on proactive connectivity check for fast failure detection to =  meet the sub-50 ms requirement. [[[Sasha]]] IMO there is = nothing specific to MPLS-TP here. Detecting S-PE failures based on the = control plane would  not fast = enough.

Therefore any scalability considerations that apply to the PW = protection draft apply to the PW redundancy draft as = well.[[[Sasha]]] I have not raised the scalability issue. My issue = was limited applicability scope when compared to PW redundancy. E.g., = the PW redundancy mechanisms take care of dual-homed CEs in SS- and = MS-PWs – something that liner protection of PWs cannot = do.

Also wrt scalability, there is no such thing as “scales” = or “doesn’t scale” – scalability is not a binary = concept. You can say that PW protection scales worse than LSP = protection, just like you can say that LSP protection scales worse than = interface protection. Which didn’t stop IETF from defining LSP = protection for scenarios where interface protection doesn’t do the = job.

 

Now let’s turn our attention back to whether the PW redundancy = draaft can be used to meet MPLS-TP PW protection requirements. I can = identify the following reasons why in its current form it = doesn’t:

 

-          = It explicitly (“outside the scope”) does not define = protection triggers and how to handle coexisting triggers, as requested = in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and = #79

[[[Sasha]]] So what? Definition of triggers is orthogonal to how = coordinated protection switching happens.

-          = It does not support the ability to distinguish between different = types of triggers (i.e. one end doesn’t know why the other end = triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req = #77

-          = It does not define revertive/nonrevertive behavior, as requested in = RFC 5654 (MPLS-TP Requirements), req #64

-          = It does not define holdoff support, which is especially important to = avoid race conditions with LSP protection when it = exists

-          = It doesn’t support 1+1 mode, as requested in RFC 5654 (MPLS-TP = Requirements), req #65

[[[Sasha]]] All these claims are correct – and  this = should not be a surprise, because MPLS-TP requirements have been defined = much later than the PW redundancy mechanism. =

But I do not think that this justifies co-existence of two different = mechanisms.

-          = It’s a two-phase protocol, with the consequent impact on = timing[[[Sasha]]] Could you please elaborate? =

-          = It doesn’t define retransmission of protection coordination = messages, so loss of a single PDU can result in switchover not taking = place, thus not supporting sub-50 ms recovery in this = case

[[[Sasha]]] The PW redundancy protocol runs either on top of LDP = (which benefits from TCP retransmissions) or on top of static PW status = messages (where retransmission is defined).

 

In summary, PW redundancy was not designed with TP requirements in = mind, and as such does not meet the TP requirements. Of course = modifications may be introduced, but why reinvent the wheel when there = is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards = track that supports all the above requirements and can be applied to = MS-PW protection with minor modifications?

[[[Sasha]]] As I said, because the applicability scope is by far too = narrow to justify a dedicated protocol.

 

Regards,

 

Daniel

 

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Monday, June = 13, 2011 4:02 PM
To: ext Alexander Vainshtein; = ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; = pwe3@ietf.org
Subject: Re: [mpls] [PWE3] Seeking feedback on = I-D "MPLS-TPLinearProtection Applicability to = MS-PW"

 

Hi,

I would like to second Sasha.

End-to-end PW protection (with diverse paths) does not scale, and put = hard restrictions on the utilization of the resources. =  

MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. = Therefore, an obvious way to provide protection for a PW is to protect = the LSP that carries it. 

If the PW is a multi-segment PW, then LSP recovery can only protect = the PW in individual segments.  This means that a single LSP = recovery action cannot protect against a failure of a PW switching point = (an S-PE).

When protecting against an AC or T/S-PE failure by dual connectivity, = PW redundancy mechanisms provide means for the PEs to coordinate over = which LSP the traffic of the PW is carried.

I also doubt why there is a need for additional mechanism. =

Best regards,

Nurit

 

From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = ext Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 = PM
To: ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; = pwe3@ietf.org
Subject: Re: [PWE3] [mpls] Seeking feedback on = I-D "MPLS-TP LinearProtection Applicability to = MS-PW"

 

Dear Ma and all,

Adding the PWE3 WG to my response.

 

The PW redundancy mechanism supports linear protection of MS-PWs as = one of many additional application use cases:

Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed = there as use case 5).

And it is equally applicable to IP/MPLS and MPLS - with the help of =  the Static PW Status Messages draft( if, for whatever = reason, you do not want  to, or cannot, use RFC = 4447).

 

Hence I doubt the need for yet another PW redundancy  mechanism = with narrow scope of applicability.

 

Regards,

     Sasha

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ma.yuxia@zte.com.cn
Sent: Monday, June 13, 2011 3:25 = PM
To: mpls@ietf.org
Subject: Re: [mpls] Seeking = feedback on I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

 

Hi all,

The = linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

BTW, there = is a typo, it is "T-PE Z" instead of "T-PE B".

 &qu= ot;
  = Figure 1 illustrates such a scenario, where two MS-PWs are
  = established between T-PE A and T-PE B, = over S-PEs 1-2 and 3-4
  = respectively. Each PW segment is established over an LSP (e.g. = PW-
  = s12 over LSP12).
 &qu= ot;

-----Original Message-----
From: Daniel = Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: = Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability = to MS-PW"
Importance: High

Hi MPLSers,

I uploaded = "MPLS-TP Linear Protection Applicability to MS-PW" = I-D
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)
The abstract goes:

One of the requirements of the MPLS = transport profile [RFC 5654] is
to provide linear protection for = transport paths, which include both
LSPs and PWs. The functional = architecture described in [SurvivFwk]
is applicable to both LSP and = PWs, however [LinearProt] does not
explicitly describe mechanisms for = PW protection in MPLS-TP.

This document extends the applicability = of the linear protection
mechanism described in [LinearProt] to = MPLS-TP segmented PWs
(MS-PWs) as defined in [RFC = 6073].

Could you please review it and send feedback to the = mailing list or
directly to the author?

Looking forward to = your feedback,

Daniel

This e-mail = message is intended for the recipient only and contains information = which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by = e-mail, phone or fax, and then delete the original and all copies = thereof.

This e-mail message is intended for the = recipient only and contains information which is CONFIDENTIAL and which = may be proprietary to ECI Telecom. If you have received this = transmission in error, please inform us by e-mail, phone or fax, and = then delete the original and all copies thereof. =

------_=_NextPart_001_01CC29DD.D836CE89-- From lmartini@cisco.com Mon Jun 13 11:15:10 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFCF11E8144 for ; Mon, 13 Jun 2011 11:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msu+fLFswB44 for ; Mon, 13 Jun 2011 11:15:10 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id EE9B311E813F for ; Mon, 13 Jun 2011 11:15:09 -0700 (PDT) Received: from seven.monoski.com (eth-0-26-82-6c-5-1e.dhcp.nanog.merit.net [192.35.166.196]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p5DIF2xZ012481 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 13 Jun 2011 12:15:04 -0600 (MDT) Message-ID: <4DF653A1.9010302@cisco.com> Date: Mon, 13 Jun 2011 12:14:57 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: lizhong.jin@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: swallow@cisco.com, matthew.bocci@alcatel-lucent.co.uk, giheron@cisco.com, pwe3@ietf.org Subject: Re: [PWE3] S-PE bypass mode in draft-ietf-pwe3-static-pw-status-04 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:15:10 -0000 On 06/13/2011 06:38 AM, lizhong.jin@zte.com.cn wrote: > Dear authors, > I have a concern for the S-PE bypass mode. If one PW segment using LDP > control plane is in graceful restart state, then how to send the PW status > codes defined in section 5.5 for S-PE? These PW status may be discarded, > because the control plane may be down or in recovering state I do not believe that graceful restart is supported , not should it be supported for PW. The problem is very different for PWs that it is for IP label bindings. Graceful restart as it is today can actually cause service interruptions to PWs, and cause problems. S-PE bypass mode is end to end only, so S-PE do not see/process the inband ACH OAM messages. Luca > Hope to see the clarification, thank you. > > Regards > Lizhong > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From gregory.mirsky@ericsson.com Mon Jun 13 11:59:23 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF6D11E80ED for ; Mon, 13 Jun 2011 11:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.738 X-Spam-Level: X-Spam-Status: No, score=-6.738 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFGX2tNlX8Ff for ; Mon, 13 Jun 2011 11:59:23 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0158811E80C2 for ; Mon, 13 Jun 2011 11:59:22 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5DIxIK8002146 for ; Mon, 13 Jun 2011 13:59:23 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.108]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 13 Jun 2011 14:59:21 -0400 From: Gregory Mirsky To: "pwe3@ietf.org" Date: Mon, 13 Jun 2011 14:59:20 -0400 Thread-Topic: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 Thread-Index: AcwneZIC9SLtrk3zQqq8mJoJ6GgmAACgl5gQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF121F3A483F1EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:59:23 -0000 --_000_FE60A4E52763E84B935532D7D9294FF121F3A483F1EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes/support Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Friday, June 10, 2011 7:21 AM To: pwe3@ietf.org Subject: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-surve= y-results-00 This email begins a two week poll of the PWE3 list for WG adoption of draft= -delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational document. Please reply to this thread indicating whether or not you support this. The poll closes on Friday 24th June 2011. Regards, Matthew & Andy --_000_FE60A4E52763E84B935532D7D9294FF121F3A483F1EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
yes/support
 
  &n= bsp; Regards,
        Greg

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew=20 (Matthew)
Sent: Friday, June 10, 2011 7:21 AM
To:=20 pwe3@ietf.org
Subject: [PWE3] Poll for adoption of=20 draft-delregno-pwe3-pw-vccv-impl-survey-results-00

This email begins a two week poll of the PWE3 list for WG adoption=20 of draft-delregno-pwe3-pw-vcc= v-impl-survey-results-00=20 as in Informational document.

Please reply to this threa= d=20 indicating whether or not you support this.

The poll closes on Friday = 24th=20 June 2011.

Regards,

Matthew & Andy<= /DIV>

--_000_FE60A4E52763E84B935532D7D9294FF121F3A483F1EUSAACMS0715e_-- From wwwrun@ietfa.amsl.com Mon Jun 13 12:35:00 2011 Return-Path: X-Original-To: pwe3@ietf.org Delivered-To: pwe3@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 7DEF81F0C5B; Mon, 13 Jun 2011 12:35:00 -0700 (PDT) From: Andrew Malis(IETF PWE3 WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110613193500.7DEF81F0C5B@ietfa.amsl.com> Date: Mon, 13 Jun 2011 12:35:00 -0700 (PDT) X-Mailman-Approved-At: Mon, 13 Jun 2011 12:38:38 -0700 Cc: stbryant@cisco.com, greg.jones@itu.int, lear@cisco.com, yoichi.maeda@ttc.or.jp, kam.lam@alcatel-lucent.com, ahmpls-tp@lists.itu.int, pwe3@ietf.org, mpls-tp@ietf.org, tsbsg15@itu.int, hhelvoort@huawei.com, andrew.g.malis@verizon.com, ghani.abbas@ericsson.com Subject: [PWE3] New Liaison Statement, "Two MPLS-TP related PWE3 Working Group Last Calls" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pwe3@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 19:35:00 -0000 Title: Two MPLS-TP related PWE3 Working Group Last Calls Submission Date: 2011-06-13 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1057 From: Andrew Malis(IETF PWE3 WG) To: ITU-T SG15 Q9, Q10, Q12 and Q14(greg.jones@itu.int) Cc: yoichi.maeda@ttc.or.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int adrian@olddog.co.uk matthew.bocci@alcatel-lucent.com lear@cisco.com stbryant@cisco.com pwe3@ietf.org mpls-tp@ietf.org Reponse Contact: andrew.g.malis@verizon.com matthew.bocci@alcatel-lucent.com Technical Contact: andrew.g.malis@verizon.com matthew.bocci@alcatel-lucent.com Purpose: For information Body: The PWE3 Working Group would like to inform you that we have recently started working group last calls on two MPLS-TP related drafts: Using the Generic Associated Channel Label for Pseudowire in MPLS-TP http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01 Pseudowire Status for Static Pseudowires http://tools.ietf.org/html/draft-ietf-pwe3-static-pw-status-04 Please send your comments to the pwe3@ietf.org mailing list before June 27, 2011. Regards, Andrew Malis Matthew Bocci PWE3 Working Group co-chairs Attachment(s): No document has been attached From aldrin.ietf@gmail.com Mon Jun 13 13:11:24 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2872D1F0C69 for ; Mon, 13 Jun 2011 13:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTKKa3vaSo2O for ; Mon, 13 Jun 2011 13:11:23 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 797101F0C5E for ; Mon, 13 Jun 2011 13:11:18 -0700 (PDT) Received: by pvh18 with SMTP id 18so2492659pvh.31 for ; Mon, 13 Jun 2011 13:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=QEdA267tjUzjOnxR78ZB27HBRaBH+31qdAGI40FX2L4=; b=cUdXQhV0OoE9bd7cCrLaGou69wisUsGEzWaGHH5SYBWb9nreOyUJxXWnIU2UT9pudl 5Y6HUs70VofP/fSSuXUZ9FPXV8olP+28hzUeq5odJ+KGVLgBfhN8ASOOaSnMDu3lIulC 9VJpxws3iv/kphoPcmJAXPFojY7SH7InAvSWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=jfrWE/jKmh/yM34AdwGO/kbj+nK72fCKvJt4CPJ07lGalFn6+4FSp0GBFtC8UaQUfb SNM7oNuL4xZY8rwNSgTciifGURkX4vWcm0eTpWYO1rzbjeFPMAxKcd6B4qpst9dp18E8 8k6KDku1WRf4xhS1OQB2dYNC7ivBVCr5QESyE= Received: by 10.68.1.170 with SMTP id 10mr2336704pbn.189.1307995877970; Mon, 13 Jun 2011 13:11:17 -0700 (PDT) Received: from [192.168.255.124] ([12.207.18.42]) by mx.google.com with ESMTPS id x1sm4907722pbb.34.2011.06.13.13.11.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2011 13:11:16 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8J2) From: Sam Aldrin Date: Mon, 13 Jun 2011 13:12:02 -0700 To: "Bocci, Matthew (Matthew)" Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 20:11:24 -0000 Support. -sam Sent from my iPad On Jun 10, 2011, at 7:20 AM, "Bocci, Matthew (Matthew)" wrote: > This email begins a two week poll of the PWE3 list for WG adoption of draf= t-delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational document.= >=20 > Please reply to this thread indicating whether or not you support this. >=20 > The poll closes on Friday 24th June 2011. >=20 > Regards, >=20 > Matthew & Andy >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From gregory.mirsky@ericsson.com Mon Jun 13 18:54:16 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1749121F84E0; Mon, 13 Jun 2011 18:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAKH4Egw2yRr; Mon, 13 Jun 2011 18:54:10 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6F99621F84DE; Mon, 13 Jun 2011 18:54:10 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5E1s3ns021337; Mon, 13 Jun 2011 20:54:04 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.108]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 13 Jun 2011 21:53:53 -0400 From: Gregory Mirsky To: Alexander Vainshtein , Daniel Cohn Date: Mon, 13 Jun 2011 21:53:51 -0400 Thread-Topic: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpwABZ9x4A= Message-ID: References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF121F3A96A90EUSAACMS0715e_" MIME-Version: 1.0 Cc: "pwe3@ietf.org" , "mpls@ietf.org" , "ma.yuxia@zte.com.cn" Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 01:54:16 -0000 --_000_FE60A4E52763E84B935532D7D9294FF121F3A96A90EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, I cannot find any reference to Inter-Chassis Communication Protocol (ICCP) = as part of MPLS-TP Control Plane. That might be our omission but as of now = Control plane solution for PW redundancy might be outside of MPLS-TP scope. Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Monday, June 13, 2011 8:11 AM To: Daniel Cohn Cc: ma.yuxia@zte.com.cn; mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Daniel and all, Please see some comments inline below. Regards, Sasha From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia= @zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi, Thanks all for the feedback. I believe we all agree that PW protection is o= nly required in the event of S-PE failure at an MS-PW - this is clearly st= ated in the draft. Now, both Sasha and Nurit mention that the PW redundancy= mechanism can meet the MPLS-TP PW protection requirements. First of all a word on scalability. Please note that in an MPLS-TP environm= ent without a control plane, the PW redundancy mechanism must also rely on = proactive connectivity check for fast failure detection to meet the sub-50= ms requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here.= Detecting S-PE failures based on the control plane would not fast enough. Therefore any scalability considerations that apply to the PW protection dr= aft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised = the scalability issue. My issue was limited applicability scope when compar= ed to PW redundancy. E.g., the PW redundancy mechanisms take care of dual-h= omed CEs in SS- and MS-PWs - something that liner protection of PWs cannot = do. Also wrt scalability, there is no such thing as "scales" or "doesn't scale"= - scalability is not a binary concept. You can say that PW protection scal= es worse than LSP protection, just like you can say that LSP protection sca= les worse than interface protection. Which didn't stop IETF from defining L= SP protection for scenarios where interface protection doesn't do the job. Now let's turn our attention back to whether the PW redundancy draaft can b= e used to meet MPLS-TP PW protection requirements. I can identify the follo= wing reasons why in its current form it doesn't: - It explicitly ("outside the scope") does not define protection t= riggers and how to handle coexisting triggers, as requested in RFC 5654 (MP= LS-TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinate= d protection switching happens. - It does not support the ability to distinguish between different= types of triggers (i.e. one end doesn't know why the other end triggered s= witch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested= in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially importan= t to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP R= equirements), req #65 [[[Sasha]]] All these claims are correct - and this should not be a surpri= se, because MPLS-TP requirements have been defined much later than the PW r= edundancy mechanism. But I do not think that this justifies co-existence of two different mechan= isms. - It's a two-phase protocol, with the consequent impact on timing[= [[Sasha]]] Could you please elaborate? - It doesn't define retransmission of protection coordination mess= ages, so loss of a single PDU can result in switchover not taking place, th= us not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which ben= efits from TCP retransmissions) or on top of static PW status messages (whe= re retransmission is defined). In summary, PW redundancy was not designed with TP requirements in mind, an= d as such does not meet the TP requirements. Of course modifications may be= introduced, but why reinvent the wheel when there is a protocol (draft-iet= f-mpls-tp-linear-protection-06) in the standards track that supports all th= e above requirements and can be applied to MS-PW protection with minor modi= fications? [[[Sasha]]] As I said, because the applicability scope is by far too narrow= to justify a dedicated protocol. Regards, Daniel From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spr= echer, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard = restrictions on the utilization of the resources. MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, = an obvious way to provide protection for a PW is to protect the LSP that ca= rries it. If the PW is a multi-segment PW, then LSP recovery can only protect the PW = in individual segments. This means that a single LSP recovery action canno= t protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW re= dundancy mechanisms provide means for the PEs to coordinate over which LSP = the traffic of the PW is carried. I also doubt why there is a need for additional mechanism. Best regards, Nurit From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext= Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtectio= n Applicability to MS-PW" Dear Ma and all, Adding the PWE3 WG to my response. The PW redundancy mechanism supports linear protection of MS-PWs as one of = many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application us= es cases in addition to MS-PW with single-homed CEs (which is listed there = as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the St= atic PW Status Messages draft( if, for whatever reason, you do not= want to, or cannot, use RFC 4447). Hence I doubt the need for yet another PW redundancy mechanism with narrow= scope of applicability. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.= yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Appl= icability to MS-PW" Hi all, The linear protection mechanism for LSP and PW(including MS-PW) should be t= he same and it is valuable to describe it clearly. BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". " Figure 1 illustrates such a scenario, where two MS-PWs are established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 respectively. Each PW segment is established over an LSP (e.g. PW- s12 over LSP12). " -----Original Message----- From: Daniel Cohn Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author? Looking forward to your feedback, Daniel This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_FE60A4E52763E84B935532D7D9294FF121F3A96A90EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear All,
I cannot find any reference to Inter-Chassis Commu= nication=20 Protocol (ICCP) as part of MPLS-TP Control Plane. That might be our omissio= n but=20 as of now Control plane solution for PW redundancy might be outside of MPLS= -TP=20 scope.
 
    Regards,
      &= nbsp;=20 Greg
From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Alexander=20 Vainshtein
Sent: Monday, June 13, 2011 8:11 AM
To: Dani= el=20 Cohn
Cc: ma.yuxia@zte.com.cn; mpls@ietf.org;=20 pwe3@ietf.org
Subject: Re: [PWE3] [mpls] Seeking feedback on I-D= =20 "MPLS-TPLinearProtection Applicability to MS-PW"

Daniel=20 and all,

Please=20 see some comments inline below.

 

Regards,

    =20 Sasha

 

From:<= /B> Daniel Cohn= =20 [mailto:DanielC@orckit.com]
Sent: Monday, June 13, 2011 5:55=20 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainsht= ein;=20 ma.yuxia@zte.com.cn
Cc: mpls@ietf.org;=20 pwe3@ietf.org
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D= =20 "MPLS-TPLinearProtection Applicability to=20 MS-PW"

 

Hi,

 

Thanks=20 all for the feedback. I believe we all agree that PW protection is only req= uired=20 in the event of S-PE failure at an MS-PW – this  is clearly stat= ed in the=20 draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism c= an=20 meet the MPLS-TP PW protection requirements.

 

First=20 of all a word on scalability. Please note that in an MPLS-TP environment wi= thout=20 a control plane, the PW redundancy mechanism must also rely on proactive=20 connectivity check for fast failure detection to  meet the sub-50 ms=20 requirement. [[[Sasha]]]=20 IMO there is nothing specific to MPLS-TP here. Detecting S-PE failures base= d on=20 the control plane would  not fast enough.

Therefore=20 any scalability considerations that apply to the PW protection draft apply = to=20 the PW redundancy draft as well.[[[Sasha]]]=20 I have not raised the scalability issue. My issue was limited applicability= =20 scope when compared to PW redundancy. E.g., the PW redundancy mechanisms ta= ke=20 care of dual-homed CEs in SS- and MS-PWs – something that liner prote= ction of=20 PWs cannot do.

Also=20 wrt scalability, there is no such thing as “scales” or “d= oesn’t scale” –=20 scalability is not a binary concept. You can say that PW protection scales = worse=20 than LSP protection, just like you can say that LSP protection scales worse= than=20 interface protection. Which didn’t stop IETF from defining LSP protec= tion for=20 scenarios where interface protection doesn’t do the job.

 

Now=20 let’s turn our attention back to whether the PW redundancy draaft can= be used to=20 meet MPLS-TP PW protection requirements. I can identify the following reaso= ns=20 why in its current form it doesn’t:

 

-      &= nbsp;  =20 It=20 explicitly (“outside the scope”) does not define protection tri= ggers and how to=20 handle coexisting triggers, as requested in RFC 5654 (MPLS-TP Requirements)= ,=20 reqs #75, #76 and #79

[[[Sasha]]]=20 So what? Definition of triggers is orthogonal to how coordinated protection= =20 switching happens.

-      &= nbsp;  =20 It=20 does not support the ability to distinguish between different types of trig= gers=20 (i.e. one end doesn’t know why the other end triggered switch), as re= quested in=20 RFC 5654 (MPLS-TP Requirements), req #77

-      &= nbsp;  =20 It=20 does not define revertive/nonrevertive behavior, as requested in RFC 5654=20 (MPLS-TP Requirements), req #64

-      &= nbsp;  =20 It=20 does not define holdoff support, which is especially important to avoid rac= e=20 conditions with LSP protection when it exists

-      &= nbsp;  =20 It=20 doesn’t support 1+1 mode, as requested in RFC 5654 (MPLS-TP Requireme= nts), req=20 #65=20

[[[Sasha]]]=20 All these claims are correct – and  this should not be a surpris= e, because=20 MPLS-TP requirements have been defined much later than the PW redundancy=20 mechanism.

But=20 I do not think that this justifies co-existence of two different=20 mechanisms.

-      &= nbsp;  =20 It’s=20 a two-phase protocol, with the consequent impact on timing[[[Sasha]]]=20 Could you please elaborate?=20

-      &= nbsp;  =20 It=20 doesn’t define retransmission of protection coordination messages, so= loss of a=20 single PDU can result in switchover not taking place, thus not supporting s= ub-50=20 ms recovery in this case

[[[Sasha]]]=20 The PW redundancy protocol runs either on top of LDP (which benefits from T= CP=20 retransmissions) or on top of static PW status messages (where retransmissi= on is=20 defined).

 

In=20 summary, PW redundancy was not designed with TP requirements in mind, and a= s=20 such does not meet the TP requirements. Of course modifications may be=20 introduced, but why reinvent the wheel when there is a protocol=20 (draft-ietf-mpls-tp-linear-protection-06) in the standards track that suppo= rts=20 all the above requirements and can be applied to MS-PW protection with mino= r=20 modifications?

[[[Sasha]]]=20 As I said, because the applicability scope is by far too narrow to justify = a=20 dedicated protocol.

 

Regards,

 

Daniel

 

 

From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Monday, June 13= ,=20 2011 4:02 PM
To: ext Alexander Vainshtein;=20 ma.yuxia@zte.com.cn
Cc: mpls@ietf.org;=20 pwe3@ietf.org
Subject: Re: [mpls] [PWE3] Seeking feedback on I-D= =20 "MPLS-TPLinearProtection Applicability to=20 MS-PW"

 

Hi,

I=20 would like to second Sasha.

End-to-end=20 PW protection (with diverse paths) does not scale, and put hard restriction= s on=20 the utilization of the resources.  

MPLS-TP=20 PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvio= us=20 way to provide protection for a PW is to protect the LSP that carries it.&n= bsp;=20

If=20 the PW is a multi-segment PW, then LSP recovery can only protect the PW in= =20 individual segments.  This means that a single LSP recovery action can= not=20 protect against a failure of a PW switching point (an=20 S-PE).

When=20 protecting against an AC or T/S-PE failure by dual connectivity, PW redunda= ncy=20 mechanisms provide means for the PEs to coordinate over which LSP the traff= ic of=20 the PW is carried.

I=20 also doubt why there is a need for additional mechanism. =

Best=20 regards,

Nurit

 

From:<= /B>=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ex= t=20 Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 PM
To= :=20 ma.yuxia@zte.com.cn
Cc: mpls@ietf.org;=20 pwe3@ietf.org
Subject: Re: [PWE3] [mpls] Seeking feedback on I-D= =20 "MPLS-TP LinearProtection Applicability to=20 MS-PW"

 

Dear=20 Ma and all,

Adding=20 the PWE3 WG to my response.

 

The=20 PW redundancy mechanism supports linear protection of MS-PWs as one of many= =20 additional application use cases:

Appendix=20 A of the PW=20 redundancy Bit draft describes 5 application uses cases in addition to = MS-PW=20 with single-homed CEs (which is listed there as use case=20 5).

And=20 it is equally applicable to IP/MPLS and MPLS - with the help of  the <= A=20 href=3D"http://datatracker.ietf.org/doc/draft-ietf-pwe3-static-pw-status/?i= nclude_text=3D1">Static=20 PW Status Messages draft( if, for whatever reason, you do not want &nbs= p;to,=20 or cannot, use RFC=20 4447).

 

Hence=20 I doubt the need for yet another PW redundancy  mechanism with narrow = scope=20 of applicability.

 

Regards,

    =20 Sasha

 

From:<= /B>=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 ma.yuxia@zte.com.cn
Sent: Monday, June 13, 2011 3:25=20 PM
To: mpls@ietf.org
Subject: Re: [mpls] Seeking feedba= ck on=20 I-D "MPLS-TP Linear Protection Applicability to=20 MS-PW"

 

Hi all,

The linear protection mechanism for= LSP=20 and PW(including MS-PW) should be the same and it is valuable to describe i= t=20 clearly.

BTW, there is = a typo,=20 it is "T-PE Z" instead of "T-PE B".=20

 "=20
&nbs= p;=20 Figure 1 illustrates such a scenario, where two MS-PWs are
 =20 established between T-PE A and T-PE B, o= ver=20 S-PEs 1-2 and 3-4
 =20 respectively. Each PW segment is established over an LSP (e.g. PW- <= SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">
  s12= over=20 LSP12).
 "=20

-----Original Message-----
From: Dani= el Cohn=20
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking fee= dback=20 on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance:= =20 High

Hi MPLSers,

I uploaded "MPLS-TP Linear Protection=20 Applicability to MS-PW"=20 I-D
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)
=
The=20 abstract goes:

One of the requirements of the MPLS transport= =20 profile [RFC 5654] is
to provide linear protection for transport paths, = which=20 include both
LSPs and PWs. The functional architecture described in=20 [SurvivFwk]
is applicable to both LSP and PWs, however [LinearProt] does= =20 not
explicitly describe mechanisms for PW protection in MPLS-TP.<= SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">

This document extends the applicability of th= e=20 linear protection
mechanism described in [LinearProt] to MPLS-TP segment= ed=20 PWs
(MS-PWs) as defined in [RFC 6073].

Could you please review i= t and=20 send feedback to the mailing list or
directly to the author?

Loo= king=20 forward to your feedback,

Daniel

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

--_000_FE60A4E52763E84B935532D7D9294FF121F3A96A90EUSAACMS0715e_-- From jie.dong@huawei.com Mon Jun 13 19:39:27 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4681911E80B9 for ; Mon, 13 Jun 2011 19:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6HjdePnU3h2 for ; Mon, 13 Jun 2011 19:39:26 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2522A11E8075 for ; Mon, 13 Jun 2011 19:39:26 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMR00205E1O8A@szxga05-in.huawei.com> for pwe3@ietf.org; Tue, 14 Jun 2011 10:39:25 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMR00EXIE1NXK@szxga05-in.huawei.com> for pwe3@ietf.org; Tue, 14 Jun 2011 10:39:24 +0800 (CST) Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 14 Jun 2011 10:39:20 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.8.243]) by szxeml409-hub.china.huawei.com ([169.254.57.252]) with mapi id 14.01.0270.001; Tue, 14 Jun 2011 10:39:23 +0800 Date: Tue, 14 Jun 2011 02:39:22 +0000 From: Jie Dong In-reply-to: X-Originating-IP: [10.110.98.32] To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C927B4E33C@szxeml508-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_JuMmEodBdpp2LT3RuV97NQ)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 Thread-index: AcwneZIC9SLtrk3zQqq8mJoJ6GgmAACwomyw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 02:39:27 -0000 --Boundary_(ID_JuMmEodBdpp2LT3RuV97NQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Yes/support. Regards, Jie From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Friday, June 10, 2011 10:21 PM To: pwe3@ietf.org Subject: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 This email begins a two week poll of the PWE3 list for WG adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational document. Please reply to this thread indicating whether or not you support this. The poll closes on Friday 24th June 2011. Regards, Matthew & Andy --Boundary_(ID_JuMmEodBdpp2LT3RuV97NQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Yes/support.

 

Regards,

Jie

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, June 10, 2011 10:21 PM
To: pwe3@ietf.org
Subject: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00

 

This email begins a two week poll of the PWE3 list for WG adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational document.

 

Please reply to this thread indicating whether or not you support this.

 

The poll closes on Friday 24th June 2011.

 

Regards,

 

Matthew & Andy

 

--Boundary_(ID_JuMmEodBdpp2LT3RuV97NQ)-- From lizhong.jin@zte.com.cn Mon Jun 13 19:42:43 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B2D11E80B9 for ; Mon, 13 Jun 2011 19:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDepADBZ68I7 for ; Mon, 13 Jun 2011 19:42:43 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 543E111E8075 for ; Mon, 13 Jun 2011 19:42:42 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641397396305; Tue, 14 Jun 2011 10:41:50 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 23654.6117912792; Tue, 14 Jun 2011 10:42:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5E2gRee021237; Tue, 14 Jun 2011 10:42:27 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <4DF653A1.9010302@cisco.com> To: Luca Martini MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Tue, 14 Jun 2011 10:41:26 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-14 10:42:28, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-14 10:42:28, Serialize complete at 2011-06-14 10:42:28, S/MIME Sign failed at 2011-06-14 10:42:28: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-14 10:42:28 Content-Type: multipart/alternative; boundary="=_alternative 000EDFE6482578AF_=" X-MAIL: mse01.zte.com.cn p5E2gRee021237 Cc: matthew.bocci@alcatel-lucent.co.uk, swallow@cisco.com, giheron@cisco.com, pwe3@ietf.org Subject: Re: [PWE3] S-PE bypass mode in draft-ietf-pwe3-static-pw-status-04 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 02:42:43 -0000 This is a multipart message in MIME format. --=_alternative 000EDFE6482578AF_= Content-Type: text/plain; charset="US-ASCII" Luca, Thank you for the clarification. I got some misunderstanding. Then the feature in section 5.5.1 is only for the first or last PW segment, hope to make it more clear, like: "When the first/last PW Segment along an MS-PW is using..." In section 2: "Where an LDP control plane exists, this MUST be used for signaling all PW status messages with the exception of those specified in [REDUNDANCY]." The description is not accurate, for the exception will also include local AC fault. Regards Lizhong Luca Martini wrote on 2011-06-14 02:14:57: > On 06/13/2011 06:38 AM, lizhong.jin@zte.com.cn wrote: > > Dear authors, > > I have a concern for the S-PE bypass mode. If one PW segment using LDP > > control plane is in graceful restart state, then how to send the PW status > > codes defined in section 5.5 for S-PE? These PW status may be discarded, > > because the control plane may be down or in recovering state > I do not believe that graceful restart is supported , not should it be > supported for PW. > The problem is very different for PWs that it is for IP label bindings. > Graceful restart as it is today can actually cause service interruptions > to PWs, and cause problems. > > S-PE bypass mode is end to end only, so S-PE do not see/process the > inband ACH OAM messages. > Luca > > > > Hope to see the clarification, thank you. > > > > Regards > > Lizhong > > > > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000EDFE6482578AF_= Content-Type: text/html; charset="US-ASCII"
Luca,
Thank you for the clarification. I got some misunderstanding. Then the feature in section 5.5.1 is only for the first or last PW segment, hope to make it more clear, like: "When the first/last PW Segment along an MS-PW is using..."

In section 2: "Where an LDP control plane exists, this MUST be used for signaling all PW status messages with the exception of those specified in [REDUNDANCY]."
The description is not accurate, for the exception will also include local AC fault.

Regards
Lizhong
 

Luca Martini <lmartini@cisco.com> wrote on 2011-06-14 02:14:57:

> On 06/13/2011 06:38 AM, lizhong.jin@zte.com.cn wrote:
> > Dear authors,
> > I have a concern for the S-PE bypass mode. If one PW segment using LDP
> > control plane is in graceful restart state, then how to send the PW status
> > codes defined in section 5.5 for S-PE? These PW status may be discarded,
> > because the control plane may be down or in recovering state
> I do not believe that graceful restart is supported , not should it be
> supported for PW.
> The problem is very different for PWs that it is for IP label bindings.
> Graceful restart as it is today can actually cause service interruptions
> to PWs, and cause problems.
>
> S-PE bypass mode is end to end only, so S-PE do not see/process  the
> inband ACH OAM messages.
> Luca
>
>
> > Hope to see the clarification, thank you.
> >
> > Regards
> > Lizhong
> >
> >
> >
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000EDFE6482578AF_=-- From lmartini@cisco.com Mon Jun 13 20:43:57 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1C521F8463 for ; Mon, 13 Jun 2011 20:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG6CvRucA7zx for ; Mon, 13 Jun 2011 20:43:57 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 06E5E21F8462 for ; Mon, 13 Jun 2011 20:43:56 -0700 (PDT) Received: from seven.monoski.com (rasputinw [2.2.2.22]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p5E3aJLH025714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 13 Jun 2011 21:36:20 -0600 (MDT) Message-ID: <4DF6D72E.2000302@cisco.com> Date: Mon, 13 Jun 2011 21:36:14 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: lizhong.jin@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: matthew.bocci@alcatel-lucent.co.uk, swallow@cisco.com, giheron@cisco.com, pwe3@ietf.org Subject: Re: [PWE3] S-PE bypass mode in draft-ietf-pwe3-static-pw-status-04 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 03:43:57 -0000 On 06/13/2011 08:41 PM, lizhong.jin@zte.com.cn wrote: > Luca, > Thank you for the clarification. I got some misunderstanding. Then the > feature in section 5.5.1 is only for the first or last PW segment, hope to > make it more clear, like: "When the first/last PW Segment along an MS-PW > is using..." Yes, i'll add a clarification. > In section 2: "Where an LDP control plane exists, this MUST be used for > signaling all PW status messages with the exception of those specified in > [REDUNDANCY]." > The description is not accurate, for the exception will also include local > AC fault. > I cannot find this text in section 2. however in section 4 , I see that we need to update the text there. Thanks! Luca > Regards > Lizhong > > > Luca Martini wrote on 2011-06-14 02:14:57: > >> On 06/13/2011 06:38 AM, lizhong.jin@zte.com.cn wrote: >>> Dear authors, >>> I have a concern for the S-PE bypass mode. If one PW segment using LDP >>> control plane is in graceful restart state, then how to send the PW > status >>> codes defined in section 5.5 for S-PE? These PW status may be > discarded, >>> because the control plane may be down or in recovering state >> I do not believe that graceful restart is supported , not should it be >> supported for PW. >> The problem is very different for PWs that it is for IP label bindings. >> Graceful restart as it is today can actually cause service interruptions >> to PWs, and cause problems. >> >> S-PE bypass mode is end to end only, so S-PE do not see/process the >> inband ACH OAM messages. >> Luca >> >> >>> Hope to see the clarification, thank you. >>> >>> Regards >>> Lizhong >>> >>> >>> > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From zhang.fei3@zte.com.cn Mon Jun 13 20:47:11 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C2321F84B4; Mon, 13 Jun 2011 20:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.335 X-Spam-Level: X-Spam-Status: No, score=-96.335 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WBygAZ6peFj; Mon, 13 Jun 2011 20:47:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2670921F84B3; Mon, 13 Jun 2011 20:47:09 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 48643491178658; Tue, 14 Jun 2011 11:46:35 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 67648.4462744557; Tue, 14 Jun 2011 11:37:23 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5E3bJnW094677; Tue, 14 Jun 2011 11:37:19 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: "Bocci, Matthew (Matthew)" MIME-Version: 1.0 X-KeepSent: 62E5BA66:02505DEA-482578AF:0013B87F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 14 Jun 2011 11:37:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-14 11:37:20, Serialize complete at 2011-06-14 11:37:20 Content-Type: multipart/alternative; boundary="=_alternative 0013E3EA482578AF_=" X-MAIL: mse01.zte.com.cn p5E3bJnW094677 Cc: pwe3-bounces@ietf.org, "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 03:47:11 -0000 This is a multipart message in MIME format. --=_alternative 0013E3EA482578AF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVhaC9TdXBwb3J0IA0KDQpGZWkNCg0KDQoNCiJCb2NjaSwgTWF0dGhldyAoTWF0dGhldykiIDxt YXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbT4gDQq3orz+yMs6ICBwd2UzLWJvdW5jZXNA aWV0Zi5vcmcNCjIwMTEtMDYtMDIgMTc6MTINCg0KytW8/sjLDQoicHdlM0BpZXRmLm9yZyIgPHB3 ZTNAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINCltQV0UzXSBXRyBQb2xsIGZvciBkcmFmdC1ib3V0 cm9zLXB3ZTMtbXBscy10cC1tcy1wdy0wMS50eHQNCg0KDQoNCg0KDQoNClRoZSBhdXRob3JzIG9m IGRyYWZ0LWJvdXRyb3MtcHdlMy1tcGxzLXRwLW1zLXB3LTAxLnR4dCBoYXZlIHJlcXVlc3RlZCB0 aGF0IA0KdGhpcyBkcmFmdCBiZSBhZG9wdGVkIGFzIGEgUFdFMyB3b3JraW5nIGdyb3VwIGRyYWZ0 Lg0KDQpUaGlzIGVtYWlsIGJlZ2lucyBhIHR3byB3ZWVrIHBvbGwgb2YgdGhlIGxpc3QgdG8gaGVs cCBqdWRnZSBpZiB0aGVyZSBpcyANCmNvbnNlbnN1cyB0byBhZG9wdCB0aGUgZHJhZnQuDQoNClBs ZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCByZXBseSB0byB0aGUgUFdFMyBsaXN0IHN0YXRpbmcg d2hldGhlciB5b3UgDQpzdXBwb3J0IGFkb3B0aW9uLCB0b2dldGhlciB3aXRoIGFueSBjb21tZW50 cy4NCg0KUmVnYXJkcywNCg0KTWF0dGhld19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0KcHdlM0BpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQoNCg0K --=_alternative 0013E3EA482578AF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllYWgvU3VwcG9ydCA8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxi cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtCb2NjaSwg TWF0dGhldyAoTWF0dGhldykmcXVvdDsNCiZsdDttYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50 LmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ t6K8/sjLOiAmbmJzcDtwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wNi0wMiAxNzoxMjwvZm9udD4NCjx0ZCB3aWR0aD02 NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtwd2UzQGlldGYub3Jn JnF1b3Q7ICZsdDtwd2UzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W1BXRTNdIFdHIFBvbGwgZm9yIGRyYWZ0LWJv dXRyb3MtcHdlMy1tcGxzLXRwLW1zLXB3LTAxLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGUgYXV0aG9ycyBv ZiBkcmFmdC1ib3V0cm9zLXB3ZTMtbXBscy10cC1tcy1wdy0wMS50eHQNCmhhdmUgcmVxdWVzdGVk IHRoYXQgdGhpcyBkcmFmdCBiZSBhZG9wdGVkIGFzIGEgUFdFMyB3b3JraW5nIGdyb3VwIGRyYWZ0 LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhpcyBlbWFp bCBiZWdpbnMgYSB0d28gd2VlayBwb2xsIG9mIHRoZQ0KbGlzdCB0byBoZWxwIGp1ZGdlIGlmIHRo ZXJlIGlzIGNvbnNlbnN1cyB0byBhZG9wdCB0aGUgZHJhZnQuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5QbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQgcmVw bHkgdG8gdGhlDQpQV0UzIGxpc3Qgc3RhdGluZyB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9u LCB0b2dldGhlciB3aXRoIGFueSBjb21tZW50cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPlJlZ2FyZHMsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj5NYXR0aGV3PC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwd2UzIG1haWxpbmcg bGlzdDxicj4NCnB3ZTNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3B3ZTM8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0013E3EA482578AF_=-- From zhang.fei3@zte.com.cn Mon Jun 13 20:47:14 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C68321F84BB; Mon, 13 Jun 2011 20:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.768 X-Spam-Level: X-Spam-Status: No, score=-96.768 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMNCR9YSjb3G; Mon, 13 Jun 2011 20:47:14 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 540BB21F84B8; Mon, 13 Jun 2011 20:47:13 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 48643491178658; Tue, 14 Jun 2011 11:46:35 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 67648.4462744557; Tue, 14 Jun 2011 11:38:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5E3bwtE095486; Tue, 14 Jun 2011 11:37:59 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: "Bocci, Matthew (Matthew)" MIME-Version: 1.0 X-KeepSent: 49BE7BA4:51750A4B-482578AF:0013ECBC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 14 Jun 2011 11:37:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-14 11:38:00, Serialize complete at 2011-06-14 11:38:00 Content-Type: multipart/alternative; boundary="=_alternative 0013F36D482578AF_=" X-MAIL: mse01.zte.com.cn p5E3bwtE095486 Cc: pwe3-bounces@ietf.org, "pwe3@ietf.org" Subject: Re: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 03:47:14 -0000 This is a multipart message in MIME format. --=_alternative 0013F36D482578AF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVhaC9TdXBwb3J0DQoNCkZlaQ0KDQoNCg0KIkJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KSIgPG1h dHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPiANCreivP7IyzogIHB3ZTMtYm91bmNlc0Bp ZXRmLm9yZw0KMjAxMS0wNi0xMCAyMjoyMA0KDQrK1bz+yMsNCiJwd2UzQGlldGYub3JnIiA8cHdl M0BpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KW1BXRTNdIFBvbGwgZm9yIGFkb3B0aW9uIG9mIA0K ZHJhZnQtZGVscmVnbm8tcHdlMy1wdy12Y2N2LWltcGwtc3VydmV5LXJlc3VsdHMtMDANCg0KDQoN Cg0KDQoNClRoaXMgZW1haWwgYmVnaW5zIGEgdHdvIHdlZWsgcG9sbCBvZiB0aGUgUFdFMyBsaXN0 IGZvciBXRyBhZG9wdGlvbiBvZiANCmRyYWZ0LWRlbHJlZ25vLXB3ZTMtcHctdmNjdi1pbXBsLXN1 cnZleS1yZXN1bHRzLTAwIGFzIGluIEluZm9ybWF0aW9uYWwgDQpkb2N1bWVudC4NCg0KUGxlYXNl IHJlcGx5IHRvIHRoaXMgdGhyZWFkIGluZGljYXRpbmcgd2hldGhlciBvciBub3QgeW91IHN1cHBv cnQgdGhpcy4NCg0KVGhlIHBvbGwgY2xvc2VzIG9uIEZyaWRheSAyNHRoIEp1bmUgMjAxMS4NCg0K UmVnYXJkcywNCg0KTWF0dGhldyAmIEFuZHkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0KcHdlM0BpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQoNCg0K --=_alternative 0013F36D482578AF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllYWgvU3VwcG9ydDwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0JvY2NpLCBN YXR0aGV3IChNYXR0aGV3KSZxdW90Ow0KJmx0O21hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQu Y29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63 orz+yMs6ICZuYnNwO3B3ZTMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTA2LTEwIDIyOjIwPC9mb250Pg0KPHRkIHdpZHRoPTY0 JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3B3ZTNAaWV0Zi5vcmcm cXVvdDsgJmx0O3B3ZTNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bUFdFM10gUG9sbCBmb3IgYWRvcHRpb24gb2Yg ZHJhZnQtZGVscmVnbm8tcHdlMy1wdy12Y2N2LWltcGwtc3VydmV5LXJlc3VsdHMtMDA8L2ZvbnQ+ PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFi bGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+VGhpcyBlbWFpbCBiZWdpbnMgYSB0d28gd2VlayBwb2xsIG9mIHRoZQ0KUFdFMyBsaXN0 IGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1kZWxyZWduby1wd2UzLXB3LXZjY3YtaW1wbC1zdXJ2 ZXktcmVzdWx0cy0wMA0KYXMgaW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudC48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlBsZWFzZSByZXBseSB0byB0aGlzIHRo cmVhZCBpbmRpY2F0aW5nDQp3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCB0aGlzLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhlIHBvbGwgY2xvc2VzIG9u IEZyaWRheSAyNHRoIEp1bmUgMjAxMS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNhbGlicmkiPlJlZ2FyZHMsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj5NYXR0aGV3ICZhbXA7IEFuZHk8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnB3 ZTMgbWFpbGluZyBsaXN0PGJyPg0KcHdlM0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcHdlMzxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0013F36D482578AF_=-- From liu.guoman@zte.com.cn Tue Jun 14 00:10:43 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B98C11E8092 for ; Tue, 14 Jun 2011 00:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnsHTdYuQHUl for ; Tue, 14 Jun 2011 00:10:42 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id BEB9F11E8070 for ; Tue, 14 Jun 2011 00:10:41 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 48641397396305; Tue, 14 Jun 2011 15:09:29 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 29809.1397396305; Tue, 14 Jun 2011 15:10:14 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id p5E7AIAL023808 for ; Tue, 14 Jun 2011 15:10:18 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p5E6rHN2001591; Tue, 14 Jun 2011 14:53:17 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201106140710.p5E7AIAL023808@mse02.zte.com.cn> In-Reply-To: To: "Bocci, Matthew (Matthew)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Tue, 14 Jun 2011 14:53:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-14 14:53:19, Serialize complete at 2011-06-14 14:53:19 Content-Type: multipart/alternative; boundary="=_alternative 0025F5B4482578AF_=" X-MAIL: mse02.zte.com.cn p5E7AIAL023808 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 07:10:43 -0000 This is a multipart message in MIME format. --=_alternative 0025F5B4482578AF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WUVTL3N1cHBvcnQNCg0KDQoNCg0KDQoNCg0KIkJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KSIgPG1h dHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPiANCreivP7IyzogIHB3ZTMtYm91bmNlc0Bp ZXRmLm9yZw0KMjAxMS0wNi0wMiAxNzoxMg0KDQrK1bz+yMsNCiJwd2UzQGlldGYub3JnIiA8cHdl M0BpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KW1BXRTNdIFdHIFBvbGwgZm9yIGRyYWZ0LWJvdXRy b3MtcHdlMy1tcGxzLXRwLW1zLXB3LTAxLnR4dA0KDQoNCg0KDQoNCg0KVGhlIGF1dGhvcnMgb2Yg ZHJhZnQtYm91dHJvcy1wd2UzLW1wbHMtdHAtbXMtcHctMDEudHh0IGhhdmUgcmVxdWVzdGVkIHRo YXQgDQp0aGlzIGRyYWZ0IGJlIGFkb3B0ZWQgYXMgYSBQV0UzIHdvcmtpbmcgZ3JvdXAgZHJhZnQu DQoNClRoaXMgZW1haWwgYmVnaW5zIGEgdHdvIHdlZWsgcG9sbCBvZiB0aGUgbGlzdCB0byBoZWxw IGp1ZGdlIGlmIHRoZXJlIGlzIA0KY29uc2Vuc3VzIHRvIGFkb3B0IHRoZSBkcmFmdC4NCg0KUGxl YXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHJlcGx5IHRvIHRoZSBQV0UzIGxpc3Qgc3RhdGluZyB3 aGV0aGVyIHlvdSANCnN1cHBvcnQgYWRvcHRpb24sIHRvZ2V0aGVyIHdpdGggYW55IGNvbW1lbnRz Lg0KDQpSZWdhcmRzLA0KDQpNYXR0aGV3X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnB3ZTMgbWFpbGluZyBsaXN0DQpwd2UzQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTMNCg0KDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlz IG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRl ZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVy cy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0 aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3Nl IG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0025F5B4482578AF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPllFUy9zdXBwb3J0PGJyPg0KPC9m b250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1jZW50ZXI+PC9kaXY+DQo8dGQ+ PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj4mcXVvdDtCb2NjaSwgTWF0dGhldyAoTWF0dGhldykmcXVvdDsNCiZsdDttYXR0aGV3LmJv Y2NpQGFsY2F0ZWwtbHVjZW50LmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wNi0wMiAxNzoxMjwv Zm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4m cXVvdDtwd2UzQGlldGYub3JnJnF1b3Q7ICZsdDtwd2UzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W1BXRTNdIFdH IFBvbGwgZm9yIGRyYWZ0LWJvdXRyb3MtcHdlMy1tcGxzLXRwLW1zLXB3LTAxLnR4dDwvZm9udD48 L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJs ZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj5UaGUgYXV0aG9ycyBvZiBkcmFmdC1ib3V0cm9zLXB3ZTMtbXBscy10cC1tcy1wdy0wMS50 eHQNCmhhdmUgcmVxdWVzdGVkIHRoYXQgdGhpcyBkcmFmdCBiZSBhZG9wdGVkIGFzIGEgUFdFMyB3 b3JraW5nIGdyb3VwIGRyYWZ0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+VGhpcyBlbWFpbCBiZWdpbnMgYSB0d28gd2VlayBwb2xsIG9mIHRoZQ0KbGlzdCB0 byBoZWxwIGp1ZGdlIGlmIHRoZXJlIGlzIGNvbnNlbnN1cyB0byBhZG9wdCB0aGUgZHJhZnQuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5QbGVhc2UgcmV2aWV3 IHRoZSBkcmFmdCBhbmQgcmVwbHkgdG8gdGhlDQpQV0UzIGxpc3Qgc3RhdGluZyB3aGV0aGVyIHlv dSBzdXBwb3J0IGFkb3B0aW9uLCB0b2dldGhlciB3aXRoIGFueSBjb21tZW50cy48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJlZ2FyZHMsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5NYXR0aGV3PC9mb250Pjxmb250IHNp emU9Mj48dHQ+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpwd2UzIG1haWxpbmcgbGlzdDxicj4NCnB3ZTNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTM8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4N Cjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3Rp Y2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNw O21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7 UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQm bmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNw O25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtj b250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNw O290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5i c3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRp YWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZu YnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50 aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4m bmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtl bWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUm bmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZu YnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZu YnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7 c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5l ZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDta VEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0025F5B4482578AF_=-- From DanielC@orckit.com Tue Jun 14 00:12:48 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ECE11E8070 for ; Tue, 14 Jun 2011 00:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.847, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lloi43-7oOic for ; Tue, 14 Jun 2011 00:12:48 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id D46FF11E8105 for ; Tue, 14 Jun 2011 00:12:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2A62.AC5322A9" Date: Tue, 14 Jun 2011 10:12:40 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306CF3468@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Thread-Index: Acwmim8YgO2wxXLFTRmMrx1MED7XzgD1/7Cw References: From: "Daniel Cohn" To: "Bocci, Matthew (Matthew)" , Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 07:12:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2A62.AC5322A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Thursday, June 09, 2011 12:49 PM To: pwe3@ietf.org Subject: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt =20 This email begins a two week working group last call for draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt =20 Please review the draft and post any comments to the PWE3 mailing list. =20 The working group last call will end on Friday 24th June. =20 Best regards, =20 Matthew & Andy ------_=_NextPart_001_01CC2A62.AC5322A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = Bocci, Matthew (Matthew)
Sent: Thursday, June 09, 2011 = 12:49 PM
To: pwe3@ietf.org
Subject: [PWE3] WG LC on = draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt

 

This email begins a two week working group last call = for draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt

 

Please review the draft and post any comments to the PWE3 mailing = list.

 

The working group last call will end on Friday 24th = June.

 

Best regards,

 

Matthew & Andy

------_=_NextPart_001_01CC2A62.AC5322A9-- From frederic.jounay@orange-ftgroup.com Tue Jun 14 01:01:01 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2711411E8092 for ; Tue, 14 Jun 2011 01:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtX88I8OUbKz for ; Tue, 14 Jun 2011 01:01:00 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 642FA11E8070 for ; Tue, 14 Jun 2011 01:01:00 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2ED2D8B8005; Tue, 14 Jun 2011 10:01:42 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 22DB88B8003; Tue, 14 Jun 2011 10:01:42 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 10:00:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2A69.31FB301A" Date: Tue, 14 Jun 2011 10:00:58 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Poll for adoption ofdraft-delregno-pwe3-pw-vccv-impl-survey-results-00 thread-index: AcwpuiGxS/3kg0TyRAKKqc8JvZUt2gApq3Pw References: From: To: X-OriginalArrivalTime: 14 Jun 2011 08:00:59.0289 (UTC) FILETIME=[326DC890:01CC2A69] Cc: pwe3@ietf.org Subject: Re: [PWE3] Poll for adoption ofdraft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 08:01:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2A69.31FB301A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Fred=20 =20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Fri, 10 Jun 2011 16:20:36 +0200 > From: "Bocci, Matthew (Matthew)" > To: "pwe3@ietf.org" > Subject: [PWE3] Poll for adoption of > draft-delregno-pwe3-pw-vccv-impl-survey-results-00 > Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" >=20 > This email begins a two week poll of the PWE3 list for WG adoption=20 > of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in=20 > Informational document. >=20 > Please reply to this thread indicating whether or not you support this. >=20 > The poll closes on Friday 24th June 2011. >=20 > Regards, >=20 > Matthew & Andy >=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/pwe3/attachments/20110610/2eb3f64d/attachment.htm> >=20 > ------------------------------ > --=3D_alt =20 ------_=_NextPart_001_01CC2A69.31FB301A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support.
Fred 
 
>=20 ---------------------------------------------------------------------->=20
> Message: 1
> Date: Fri, 10 Jun 2011 16:20:36 = +0200
> From:=20 "Bocci, Matthew (Matthew)" = <matthew.bocci@alcatel-lucent.com>
> To:=20 "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: [PWE3] Poll for = adoption=20 of
>  =20  draft-delregno-pwe3-pw-vccv-impl-survey-results-00
> = Message-ID:=20 <CA17E6C3.10D60%matthew.bocci@alcatel-lucent.com>
> = Content-Type:=20 text/plain; charset=3D"us-ascii"
>
> This email begins a = two week=20 poll of the PWE3 list for WG adoption
> of=20 draft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in
> = Informational=20 document.
>
> Please reply to this thread indicating = whether or not=20 you support this.
>
> The poll closes on Friday 24th June=20 2011.
>
> Regards,
>
> Matthew & = Andy
>=20
> -------------- next part --------------
> An HTML = attachment was=20 scrubbed...
> URL: <http://www.ietf.org/mail-
>=20 archive/web/pwe3/attachments/20110610/2eb3f64d/attachment.htm>
>= =20
> ------------------------------
> = --=3D_alt
 
------_=_NextPart_001_01CC2A69.31FB301A-- From davari@broadcom.com Tue Jun 14 01:07:57 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC25D11E8126 for ; Tue, 14 Jun 2011 01:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKAESJ+xQ3Vo for ; Tue, 14 Jun 2011 01:07:57 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0428B11E8123 for ; Tue, 14 Jun 2011 01:07:56 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 14 Jun 2011 01:11:45 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Tue, 14 Jun 2011 01:07:39 -0700 From: "Shahram Davari" To: "'frederic.jounay@orange-ftgroup.com'" , "'matthew.bocci@alcatel-lucent.com'" Date: Tue, 14 Jun 2011 01:07:39 -0700 Thread-Topic: [PWE3] Poll for adoption ofdraft-delregno-pwe3-pw-vccv-impl-survey-results-00 Thread-Index: AcwpuiGxS/3kg0TyRAKKqc8JvZUt2gApq3PwAAJUVJA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A85F0311B4@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 61E9C84B4NS20392886-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6A85F0311B4SJEXCHCCR02co_ Cc: "'pwe3@ietf.org'" Subject: Re: [PWE3] Poll for adoption ofdraft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 08:07:57 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6A85F0311B4SJEXCHCCR02co_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHB3ZTMt Ym91bmNlc0BpZXRmLm9yZyA8cHdlMy1ib3VuY2VzQGlldGYub3JnPg0KVG86IG1hdHRoZXcuYm9j Y2lAYWxjYXRlbC1sdWNlbnQuY29tIDxtYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbT4N CkNjOiBwd2UzQGlldGYub3JnIDxwd2UzQGlldGYub3JnPg0KU2VudDogVHVlIEp1biAxNCAwMTow MDo1OCAyMDExDQpTdWJqZWN0OiBSZTogW1BXRTNdIFBvbGwgZm9yIGFkb3B0aW9uIG9mZHJhZnQt ZGVscmVnbm8tcHdlMy1wdy12Y2N2LWltcGwtc3VydmV5LXJlc3VsdHMtMDANCg0KU3VwcG9ydC4N CkZyZWQNCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IE1lc3NhZ2U6IDENCj4gRGF0ZTogRnJpLCAx MCBKdW4gMjAxMSAxNjoyMDozNiArMDIwMA0KPiBGcm9tOiAiQm9jY2ksIE1hdHRoZXcgKE1hdHRo ZXcpIiA8bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb20+DQo+IFRvOiAicHdlM0BpZXRm Lm9yZyIgPHB3ZTNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtQV0UzXSBQb2xsIGZvciBhZG9wdGlv biBvZg0KPiAgICBkcmFmdC1kZWxyZWduby1wd2UzLXB3LXZjY3YtaW1wbC1zdXJ2ZXktcmVzdWx0 cy0wMA0KPiBNZXNzYWdlLUlEOiA8Q0ExN0U2QzMuMTBENjAlbWF0dGhldy5ib2NjaUBhbGNhdGVs LWx1Y2VudC5jb20+DQo+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNj aWkiDQo+DQo+IFRoaXMgZW1haWwgYmVnaW5zIGEgdHdvIHdlZWsgcG9sbCBvZiB0aGUgUFdFMyBs aXN0IGZvciBXRyBhZG9wdGlvbg0KPiBvZiBkcmFmdC1kZWxyZWduby1wd2UzLXB3LXZjY3YtaW1w bC1zdXJ2ZXktcmVzdWx0cy0wMCBhcyBpbg0KPiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50Lg0KPg0K PiBQbGVhc2UgcmVwbHkgdG8gdGhpcyB0aHJlYWQgaW5kaWNhdGluZyB3aGV0aGVyIG9yIG5vdCB5 b3Ugc3VwcG9ydCB0aGlzLg0KPg0KPiBUaGUgcG9sbCBjbG9zZXMgb24gRnJpZGF5IDI0dGggSnVu ZSAyMDExLg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBNYXR0aGV3ICYgQW5keQ0KPg0KPiAtLS0tLS0t LS0tLS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS0NCj4gQW4gSFRNTCBhdHRhY2htZW50IHdh cyBzY3J1YmJlZC4uLg0KPiBVUkw6IDxodHRwOi8vd3d3LmlldGYub3JnL21haWwtDQo+IGFyY2hp dmUvd2ViL3B3ZTMvYXR0YWNobWVudHMvMjAxMTA2MTAvMmViM2Y2NGQvYXR0YWNobWVudC5odG0+ DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLT1fYWx0DQoNCg0K --_000_2C2F1EBA8050E74EA81502D5740B4BD6A85F0311B4SJEXCHCCR02co_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjU3MzAuMTMiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPjxkaXY+PGZvbnQgc2l6 ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD4NClN1cHBvcnQuPC9mb250PjwvZGl2Pg0KPGJyPjxk aXY+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KPGZv bnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IHB3ZTMtYm91bmNlc0BpZXRmLm9y ZyAmbHQ7cHdlMy1ib3VuY2VzQGlldGYub3JnJmd0Ow08YnI+PGI+VG88L2I+OiBtYXR0aGV3LmJv Y2NpQGFsY2F0ZWwtbHVjZW50LmNvbSAmbHQ7bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5j b20mZ3Q7DTxicj48Yj5DYzwvYj46IHB3ZTNAaWV0Zi5vcmcgJmx0O3B3ZTNAaWV0Zi5vcmcmZ3Q7 DTxicj48Yj5TZW50PC9iPjogVHVlIEp1biAxNCAwMTowMDo1OCAyMDExPGJyPjxiPlN1YmplY3Q8 L2I+OiBSZTogW1BXRTNdIFBvbGwgZm9yIGFkb3B0aW9uIG9mZHJhZnQtZGVscmVnbm8tcHdlMy1w dy12Y2N2LWltcGwtc3VydmV5LXJlc3VsdHMtMDANPGJyPjwvZm9udD48YnI+PC9kaXY+DQoNCjxE SVY+PFRUPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz00MDY1NzAwMDctMTQwNjIwMTE+PEZPTlQg ZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmY+U3VwcG9ydC48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48 L1RUPjwvRElWPg0KPERJVj48VFQ+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTQwNjU3MDAwNy0x NDA2MjAxMT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZj5GcmVkPC9GT05UPiZuYnNw OzwvU1BBTj48L0ZPTlQ+PC9UVD48L0RJVj4NCjxESVY+PFRUPjxGT05UIHNpemU9Mj48U1BBTiBj bGFzcz00MDY1NzAwMDctMTQwNjIwMTE+Jm5ic3A7PC9TUEFOPjxCUj4mZ3Q7IA0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxCUj4mZ3Q7IA0KPEJSPiZndDsgTWVzc2FnZTogMTxCUj4mZ3Q7IERhdGU6IEZyaSwgMTAg SnVuIDIwMTEgMTY6MjA6MzYgKzAyMDA8QlI+Jmd0OyBGcm9tOiANCiJCb2NjaSwgTWF0dGhldyAo TWF0dGhldykiICZsdDttYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbSZndDs8QlI+Jmd0 OyBUbzogDQoicHdlM0BpZXRmLm9yZyIgJmx0O3B3ZTNAaWV0Zi5vcmcmZ3Q7PEJSPiZndDsgU3Vi amVjdDogW1BXRTNdIFBvbGwgZm9yIGFkb3B0aW9uIA0Kb2Y8QlI+Jmd0OyAmbmJzcDsgDQombmJz cDtkcmFmdC1kZWxyZWduby1wd2UzLXB3LXZjY3YtaW1wbC1zdXJ2ZXktcmVzdWx0cy0wMDxCUj4m Z3Q7IE1lc3NhZ2UtSUQ6IA0KJmx0O0NBMTdFNkMzLjEwRDYwJW1hdHRoZXcuYm9jY2lAYWxjYXRl bC1sdWNlbnQuY29tJmd0OzxCUj4mZ3Q7IENvbnRlbnQtVHlwZTogDQp0ZXh0L3BsYWluOyBjaGFy c2V0PSJ1cy1hc2NpaSI8QlI+Jmd0OyA8QlI+Jmd0OyBUaGlzIGVtYWlsIGJlZ2lucyBhIHR3byB3 ZWVrIA0KcG9sbCBvZiB0aGUgUFdFMyBsaXN0IGZvciBXRyBhZG9wdGlvbiA8QlI+Jmd0OyBvZiAN CmRyYWZ0LWRlbHJlZ25vLXB3ZTMtcHctdmNjdi1pbXBsLXN1cnZleS1yZXN1bHRzLTAwIGFzIGlu IDxCUj4mZ3Q7IEluZm9ybWF0aW9uYWwgDQpkb2N1bWVudC48QlI+Jmd0OyA8QlI+Jmd0OyBQbGVh c2UgcmVwbHkgdG8gdGhpcyB0aHJlYWQgaW5kaWNhdGluZyB3aGV0aGVyIG9yIG5vdCANCnlvdSBz dXBwb3J0IHRoaXMuPEJSPiZndDsgPEJSPiZndDsgVGhlIHBvbGwgY2xvc2VzIG9uIEZyaWRheSAy NHRoIEp1bmUgDQoyMDExLjxCUj4mZ3Q7IDxCUj4mZ3Q7IFJlZ2FyZHMsPEJSPiZndDsgPEJSPiZn dDsgTWF0dGhldyAmYW1wOyBBbmR5PEJSPiZndDsgDQo8QlI+Jmd0OyAtLS0tLS0tLS0tLS0tLSBu ZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS08QlI+Jmd0OyBBbiBIVE1MIGF0dGFjaG1lbnQgd2FzIA0K c2NydWJiZWQuLi48QlI+Jmd0OyBVUkw6ICZsdDtodHRwOi8vd3d3LmlldGYub3JnL21haWwtPEJS PiZndDsgDQphcmNoaXZlL3dlYi9wd2UzL2F0dGFjaG1lbnRzLzIwMTEwNjEwLzJlYjNmNjRkL2F0 dGFjaG1lbnQuaHRtJmd0OzxCUj4mZ3Q7IA0KPEJSPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPEJSPiZndDsgPC9GT05UPjwvVFQ+LS09X2FsdDxCUj48L0RJVj48UFJFPiZuYnNw OzwvUFJFPjwvQk9EWT48L0hUTUw+DQo= --_000_2C2F1EBA8050E74EA81502D5740B4BD6A85F0311B4SJEXCHCCR02co_-- From simon.delord@gmail.com Tue Jun 14 02:21:13 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E4E11E80B9 for ; Tue, 14 Jun 2011 02:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEnqawr2ip6P for ; Tue, 14 Jun 2011 02:21:13 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC9711E8083 for ; Tue, 14 Jun 2011 02:21:12 -0700 (PDT) Received: by fxm15 with SMTP id 15so4066725fxm.31 for ; Tue, 14 Jun 2011 02:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VQrzSC1B3KyPO/QcMmpUYBh0aQCOOuu+rPag/W8UCNk=; b=NbyMg3yov5/kNzUAl487mYNUOzxTSFDw9yD/HiAYyYycnv4Q0Ahvbjt5QtW2n2bYzZ 0g6JBACUB6KsN+kRo2SqFuGj6bIFjHzq/4lkM5lpC9RSM1cVcHxuwNV2SwFuH6BVi7sN bycVKprafHOXw1Qm4toKJ3O5ypYzIZYwRxg5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qfukLjgkEdr508DmDOXQOUf8SahZSlX/9Ka4qA+XM1TLMwq+1b9XOWNCRhLYO9p+yY /f28+GbiFcwrX+gnLqtDRdHoBOvIXoyV6JaRFwBwOwdJqmsAUJlpKjKb/lwAD3dgcyb8 7M8VQRKzCSW+ihhw19kaINhVLqCn2VfSqJyWU= MIME-Version: 1.0 Received: by 10.223.156.9 with SMTP id u9mr6600717faw.70.1308043271297; Tue, 14 Jun 2011 02:21:11 -0700 (PDT) Received: by 10.223.28.86 with HTTP; Tue, 14 Jun 2011 02:21:11 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A85F0311B4@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6A85F0311B4@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 14 Jun 2011 17:21:11 +0800 Message-ID: From: Simon Delord To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=002354010a9a895b1904a5a88e35 Subject: Re: [PWE3] Poll for adoption ofdraft-delregno-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 09:21:13 -0000 --002354010a9a895b1904a5a88e35 Content-Type: text/plain; charset=ISO-8859-1 Support. Simon > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 10 Jun 2011 16:20:36 +0200 > From: "Bocci, Matthew (Matthew)" > To: "pwe3@ietf.org" > Subject: [PWE3] Poll for adoption of > draft-delregno-pwe3-pw-vccv-impl-survey-results-00 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > This email begins a two week poll of the PWE3 list for WG adoption > of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in > Informational document. > > Please reply to this thread indicating whether or not you support this. > > The poll closes on Friday 24th June 2011. > > Regards, > > Matthew & Andy > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/pwe3/attachments/20110610/2eb3f64d/attachment.htm> > > ------------------------------ > --=_alt > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --002354010a9a895b1904a5a88e35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support.
=A0
Simon
> -----------------------------------= -----------------------------------
>
> Message: 1
> Dat= e: Fri, 10 Jun 2011 16:20:36 +0200
> From: "Bocci, Matthew (Matt= hew)" <matthew.bocci@alcatel-lucent.com>
> To: "pwe3@ietf= .org" <pwe3@= ietf.org>
> Subject: [PWE3] Poll for adoption of
> =A0 = =A0draft-delregno-pwe3-pw-vccv-impl-survey-results-00
> Message-ID: <CA17E6C3.10D60%matthew.bocci@alcatel-lucen= t.com>
> Content-Type: text/plain; charset=3D"us-ascii&qu= ot;
>
> This email begins a two week poll of the PWE3 list for WG ado= ption
> of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in =
> Informational document.
>
> Please reply to this thre= ad indicating whether or not you support this.
>
> The poll closes on Friday 24th June 2011.
>
> Re= gards,
>
> Matthew & Andy
>
> -------------- = next part --------------
> An HTML attachment was scrubbed...
> URL: <http:= //www.ietf.org/mail-
> archive/web/pwe3/attachments/20110610/2eb3= f64d/attachment.htm>
>
> ------------------------------
> --=3D_alt
=A0

_____________________= __________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3<= br>

--002354010a9a895b1904a5a88e35-- From DanielC@orckit.com Tue Jun 14 04:31:02 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942C211E80B7; Tue, 14 Jun 2011 04:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqcEPxttvqaF; Tue, 14 Jun 2011 04:30:56 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4632811E8071; Tue, 14 Jun 2011 04:30:54 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2A86.BA816F8A" Date: Tue, 14 Jun 2011 14:30:42 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306CF3547@tlvmail1> In-reply-to: <077E41CFFD002C4CAB7DFA4386A5326403F64A13@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpwAADpDNAAJfe4EA== References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> <077E41CFFD002C4CAB7DFA4386A5326403F64A13@DEMUEXC014.nsn-intra.net> From: "Daniel Cohn" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Alexander Vainshtein" Cc: ma.yuxia@zte.com.cn, mpls@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 11:31:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2A86.BA816F8A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nurit, =20 The exact same argument can be made for LSP linear protection as in draft-ietf-mpls-tp-linear-protection - it protects LSRs (transit LERs) but doesn't protect head/tail LERs. So why not drop LSP linear protection altogether and protect the client service layer instead?=20 Protection is a statistical business. Protecting S-PE will improve availability, even when T-PE is not protected - especially when you remember that typically there are many more S-PEs than T-PEs in a given PW. Also as the T-PE is typically closest to the edge, a T-PE will typically carry less PWs than an S-PE so S-PE protection would be more significant for the operator.=20 AC protection (required in order to protect T-PE) using ICCP or similar, as Greg pointed out, is not defined as part of the MPLS-TP framework. In the most extreme case, which is gradually becoming the norm, operators deploy MPLS to the customer edge, so the T-PE will actually be a CE in which case CE/T-PE protection is technically an impossibility. =20 On the other hand, there is a clear MPLS-TP requirement to provide protection for MPLS-TP transport paths, which includes PWs. The purpose of this draft is to meet this requirement, for which there is currently no solution. If you have an alternative solution please share it with the list so we can discuss it. =20 Thanks, =20 Daniel =20 =20 From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com]=20 Sent: Monday, June 13, 2011 6:23 PM To: ext Alexander Vainshtein; Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" =20 If you do it on the client service layer, you can protect also the T-PE... Why do you want to protect only against a failure of the S-PE? The PW starts at the T-PE... =20 From: ext Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, June 13, 2011 6:11 PM To: Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" =20 Daniel and all, Please see some comments inline below. =20 Regards, Sasha =20 From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" =20 Hi, =20 Thanks all for the feedback. I believe we all agree that PW protection is only required in the event of S-PE failure at an MS-PW - this is clearly stated in the draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW protection requirements. =20 First of all a word on scalability. Please note that in an MPLS-TP environment without a control plane, the PW redundancy mechanism must also rely on proactive connectivity check for fast failure detection to meet the sub-50 ms requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here. Detecting S-PE failures based on the control plane would not fast enough. Therefore any scalability considerations that apply to the PW protection draft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised the scalability issue. My issue was limited applicability scope when compared to PW redundancy. E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS- and MS-PWs - something that liner protection of PWs cannot do. Also wrt scalability, there is no such thing as "scales" or "doesn't scale" - scalability is not a binary concept. You can say that PW protection scales worse than LSP protection, just like you can say that LSP protection scales worse than interface protection. Which didn't stop IETF from defining LSP protection for scenarios where interface protection doesn't do the job. =20 Now let's turn our attention back to whether the PW redundancy draaft can be used to meet MPLS-TP PW protection requirements. I can identify the following reasons why in its current form it doesn't: =20 - It explicitly ("outside the scope") does not define protection triggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinated protection switching happens. - It does not support the ability to distinguish between different types of triggers (i.e. one end doesn't know why the other end triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially important to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP Requirements), req #65=20 [[[Sasha]]] All these claims are correct - and this should not be a surprise, because MPLS-TP requirements have been defined much later than the PW redundancy mechanism.=20 But I do not think that this justifies co-existence of two different mechanisms. - It's a two-phase protocol, with the consequent impact on timing[[[Sasha]]] Could you please elaborate?=20 - It doesn't define retransmission of protection coordination messages, so loss of a single PDU can result in switchover not taking place, thus not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which benefits from TCP retransmissions) or on top of static PW status messages (where retransmission is defined).=20 =20 In summary, PW redundancy was not designed with TP requirements in mind, and as such does not meet the TP requirements. Of course modifications may be introduced, but why reinvent the wheel when there is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards track that supports all the above requirements and can be applied to MS-PW protection with minor modifications? [[[Sasha]]] As I said, because the applicability scope is by far too narrow to justify a dedicated protocol. =20 Regards, =20 Daniel =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" =20 Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 ------_=_NextPart_001_01CC2A86.BA816F8A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nurit,

 

The exact same argument can be made for LSP linear protection as in = draft-ietf-mpls-tp-linear-protection – it protects LSRs = (transit LERs) but doesn’t protect head/tail LERs. So why not drop = LSP linear protection altogether and protect the client service layer = instead?

Protection is a statistical business. Protecting S-PE will improve = availability, even when T-PE is not protected – especially when = you remember that typically there are many more S-PEs than T-PEs in a = given PW. Also as the T-PE is typically closest to the edge, a T-PE will = typically carry less PWs than an S-PE so S-PE protection would be more = significant for the operator.

AC protection (required in order to protect T-PE) using ICCP or = similar, as Greg pointed out, is not defined as part of the MPLS-TP = framework. In the most extreme case, which is gradually becoming the norm, = operators deploy MPLS to the customer edge, so the T-PE will actually be = a CE in which case CE/T-PE protection is technically an = impossibility.

 

On the other hand, there is a clear MPLS-TP requirement to provide = protection for MPLS-TP transport paths, which includes PWs. The purpose = of this draft is to meet this requirement, for which there is currently = no solution. If you have an alternative solution please share it with = the list so we can discuss it.

 

Thanks,

 

Daniel

 

 

From:= = Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@ns= n.com]
Sent: Monday, June 13, 2011 6:23 PM
To: = ext Alexander Vainshtein; Daniel Cohn
Cc: mpls@ietf.org; pwe3@ietf.org; ma.yuxia@zte.com.cn
Subject= : RE: [mpls] [PWE3] Seeking feedback on I-D = "MPLS-TPLinearProtectionApplicability to = MS-PW"

 

If you do it on the client service layer, you can protect also the = T-PE…

Why do you want to protect only against a failure of the S-PE? The PW = starts at the T-PE…

 

From:= = ext Alexander Vainshtein [mailto:Alexand= er.Vainshtein@ecitele.com]
Sent: Monday, June 13, 2011 = 6:11 PM
To: Daniel Cohn
Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - = IL/Hod HaSharon); ma.yuxia@zte.com.cn
Subject= : RE: [mpls] [PWE3] Seeking feedback on I-D = "MPLS-TPLinearProtectionApplicability to = MS-PW"

 

Daniel and all,

Please see some comments inline below.

 

Regards,

     Sasha

 

From:= = Daniel Cohn [mailto:DanielC@orckit.com]
Sent: Monday, June 13, 2011 5:55 PM
To: = Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@zte.com.cn
Cc:= mpls@ietf.org; pwe3@ietf.org
Subject: RE: = [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection = Applicability to MS-PW"

 

Hi,

 

Thanks all for the feedback. I believe we all agree that PW = protection is only required in the event of S-PE failure at an MS-PW = – this  is clearly stated in the draft. Now, both Sasha and = Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW = protection requirements.

 

First of all a word on scalability. Please note that in an MPLS-TP = environment without a control plane, the PW redundancy mechanism must = also rely on proactive connectivity check for fast failure detection to =  meet the sub-50 ms requirement. [[[Sasha]]] IMO there is = nothing specific to MPLS-TP here. Detecting S-PE failures based on the = control plane would  not fast = enough.

Therefore any scalability considerations that apply to the PW = protection draft apply to the PW redundancy draft as = well.[[[Sasha]]] I have not raised the scalability issue. My issue = was limited applicability scope when compared to PW redundancy. E.g., = the PW redundancy mechanisms take care of dual-homed CEs in SS- and = MS-PWs – something that liner protection of PWs cannot = do.

Also wrt scalability, there is no such thing as “scales” = or “doesn’t scale” – scalability is not a binary = concept. You can say that PW protection scales worse than LSP = protection, just like you can say that LSP protection scales worse than = interface protection. Which didn’t stop IETF from defining LSP = protection for scenarios where interface protection doesn’t do the = job.

 

Now let’s turn our attention back to whether the PW redundancy = draaft can be used to meet MPLS-TP PW protection requirements. I can = identify the following reasons why in its current form it = doesn’t:

 

-          = It explicitly (“outside the scope”) does not define = protection triggers and how to handle coexisting triggers, as requested = in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and = #79

[[[Sasha]]] So what? Definition of triggers is orthogonal to how = coordinated protection switching happens.

-          = It does not support the ability to distinguish between different = types of triggers (i.e. one end doesn’t know why the other end = triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req = #77

-          = It does not define revertive/nonrevertive behavior, as requested in = RFC 5654 (MPLS-TP Requirements), req #64

-          = It does not define holdoff support, which is especially important to = avoid race conditions with LSP protection when it = exists

-          = It doesn’t support 1+1 mode, as requested in RFC 5654 (MPLS-TP = Requirements), req #65

[[[Sasha]]] All these claims are correct – and  this = should not be a surprise, because MPLS-TP requirements have been defined = much later than the PW redundancy mechanism. =

But I do not think that this justifies co-existence of two different = mechanisms.

-          = It’s a two-phase protocol, with the consequent impact on = timing[[[Sasha]]] Could you please elaborate? =

-          = It doesn’t define retransmission of protection coordination = messages, so loss of a single PDU can result in switchover not taking = place, thus not supporting sub-50 ms recovery in this = case

[[[Sasha]]] The PW redundancy protocol runs either on top of LDP = (which benefits from TCP retransmissions) or on top of static PW status = messages (where retransmission is defined).

 

In summary, PW redundancy was not designed with TP requirements in = mind, and as such does not meet the TP requirements. Of course = modifications may be introduced, but why reinvent the wheel when there = is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards = track that supports all the above requirements and can be applied to = MS-PW protection with minor modifications?

[[[Sasha]]] As I said, because the applicability scope is by far too = narrow to justify a dedicated protocol.

 

Regards,

 

Daniel

 

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.= org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod = HaSharon)
Sent: Monday, June 13, 2011 4:02 PM
To: = ext Alexander Vainshtein; ma.yuxia@zte.com.cn
Cc:= mpls@ietf.org; pwe3@ietf.org
Subject: Re: = [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection = Applicability to MS-PW"

 

Hi,

I would like to second Sasha.

End-to-end PW protection (with diverse paths) does not scale, and put = hard restrictions on the utilization of the resources. =  

MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. = Therefore, an obvious way to provide protection for a PW is to protect = the LSP that carries it. 

If the PW is a multi-segment PW, then LSP recovery can only protect = the PW in individual segments.  This means that a single LSP = recovery action cannot protect against a failure of a PW switching point = (an S-PE).

When protecting against an AC or T/S-PE failure by dual connectivity, = PW redundancy mechanisms provide means for the PEs to coordinate over = which LSP the traffic of the PW is carried.

I also doubt why there is a need for additional mechanism. =

Best regards,

Nurit

 

From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.= org] On Behalf Of ext Alexander Vainshtein
Sent: = Monday, June 13, 2011 3:43 PM
To: ma.yuxia@zte.com.cn
Cc:= mpls@ietf.org; pwe3@ietf.org
Subject: Re: = [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection = Applicability to MS-PW"

 

Dear Ma and all,

Adding the PWE3 WG to my response.

 

The PW redundancy mechanism supports linear protection of MS-PWs as = one of many additional application use cases:

Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed = there as use case 5).

And it is equally applicable to IP/MPLS and MPLS - with the help of =  the Static PW Status Messages draft( if, for whatever = reason, you do not want  to, or cannot, use RFC = 4447).

 

Hence I doubt the need for yet another PW redundancy  mechanism = with narrow scope of applicability.

 

Regards,

     Sasha

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.= org] On Behalf Of ma.yuxia@zte.com.cn
Sent: Monday, June 13, 2011 3:25 PM
To: mpls@ietf.org
Subject: Re: = [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection = Applicability to MS-PW"

 

Hi all,

The = linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

BTW, there = is a typo, it is "T-PE Z" instead of "T-PE B".

 &qu= ot;
  = Figure 1 illustrates such a scenario, where two MS-PWs are
  = established between T-PE A and T-PE B, = over S-PEs 1-2 and 3-4
  = respectively. Each PW segment is established over an LSP (e.g. = PW-
  = s12 over LSP12).
 &qu= ot;

-----Original Message-----
From: Daniel = Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: = Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability = to MS-PW"
Importance: High

Hi MPLSers,

I uploaded = "MPLS-TP Linear Protection Applicability to MS-PW" I-D
(h= ttp://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)
The abstract goes:

One of the requirements of the MPLS = transport profile [RFC 5654] is
to provide linear protection for = transport paths, which include both
LSPs and PWs. The functional = architecture described in [SurvivFwk]
is applicable to both LSP and = PWs, however [LinearProt] does not
explicitly describe mechanisms for = PW protection in MPLS-TP.

This document extends the applicability = of the linear protection
mechanism described in [LinearProt] to = MPLS-TP segmented PWs
(MS-PWs) as defined in [RFC = 6073].

Could you please review it and send feedback to the = mailing list or
directly to the author?

Looking forward to = your feedback,

Daniel

This e-mail = message is intended for the recipient only and contains information = which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by = e-mail, phone or fax, and then delete the original and all copies = thereof.

This e-mail message is intended for the = recipient only and contains information which is CONFIDENTIAL and which = may be proprietary to ECI Telecom. If you have received this = transmission in error, please inform us by e-mail, phone or fax, and = then delete the original and all copies thereof. =

------_=_NextPart_001_01CC2A86.BA816F8A-- From DanielC@orckit.com Tue Jun 14 04:33:57 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373A111E80E9; Tue, 14 Jun 2011 04:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUskkkFeo9rZ; Tue, 14 Jun 2011 04:33:51 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id B8D1A11E8071; Tue, 14 Jun 2011 04:33:49 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2A87.25E02F99" Date: Tue, 14 Jun 2011 14:33:46 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306CF354A@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpwACeE3pA= References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> From: "Daniel Cohn" To: "Alexander Vainshtein" Cc: ma.yuxia@zte.com.cn, mpls@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 11:33:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2A87.25E02F99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, thanks again and see inline with [DC]. =20 From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Monday, June 13, 2011 6:11 PM To: Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); ma.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" =20 Daniel and all, Please see some comments inline below. =20 Regards, Sasha =20 From: Daniel Cohn [mailto:DanielC@orckit.com]=20 Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" =20 Hi, =20 Thanks all for the feedback. I believe we all agree that PW protection is only required in the event of S-PE failure at an MS-PW - this is clearly stated in the draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW protection requirements. =20 First of all a word on scalability. Please note that in an MPLS-TP environment without a control plane, the PW redundancy mechanism must also rely on proactive connectivity check for fast failure detection to meet the sub-50 ms requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here. Detecting S-PE failures based on the control plane would not fast enough. [DC] Agreed - I just pointed our that MPLS-TP has a requirement for sub-50ms protection. Therefore any scalability considerations that apply to the PW protection draft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised the scalability issue. My issue was limited applicability scope when compared to PW redundancy.=20 [DC] Correct - scalability issue was a response to Nurit's comment. E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS- and MS-PWs - something that liner protection of PWs cannot do. [DC] I'm afraid I don't follow you here. Where does PW redundancy take care of dual-homed CE? Actually PW redundancy draft explicitly states: "The method for dual-homing of CE1 to PE1 and to PE3 nodes, and the protocols used, are outside the scope of this document".=20 Also wrt scalability, there is no such thing as "scales" or "doesn't scale" - scalability is not a binary concept. You can say that PW protection scales worse than LSP protection, just like you can say that LSP protection scales worse than interface protection. Which didn't stop IETF from defining LSP protection for scenarios where interface protection doesn't do the job. =20 Now let's turn our attention back to whether the PW redundancy draaft can be used to meet MPLS-TP PW protection requirements. I can identify the following reasons why in its current form it doesn't: =20 - It explicitly ("outside the scope") does not define protection triggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinated protection switching happens. [DC] It is. But still it needs to be defined by the recovery framework, e.g. what should the endpoint do when one PW is in SF and the other is in SD, or when both are in SD. Operators expect well-defined behavior in these and other scenarios, and PW redundancy does not define them (because it was not in their scope).=20 - It does not support the ability to distinguish between different types of triggers (i.e. one end doesn't know why the other end triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially important to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP Requirements), req #65=20 [[[Sasha]]] All these claims are correct - and this should not be a surprise, because MPLS-TP requirements have been defined much later than the PW redundancy mechanism.=20 But I do not think that this justifies co-existence of two different mechanisms. [DC] So how do you propose to meet the PW protection requirement?=20 - It's a two-phase protocol, with the consequent impact on timing[[[Sasha]]] Could you please elaborate? [DC] In draft-ietf-mpls-tp-linear-protection, each endpoint will immediately switch traffic to the other path upon identifying an SF condition in a path, without waiting for the far end to acknowledge the switch (1-phase). In PW redundancy, an endpoint detecting an SF condition in a path will not switch until the far end has acknowledged the switch (2-phase). Needless to say, recovery is slower in a 2-phase protocol. =20 - It doesn't define retransmission of protection coordination messages, so loss of a single PDU can result in switchover not taking place, thus not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which benefits from TCP retransmissions) or on top of static PW status messages (where retransmission is defined).=20 [DC] True - but static PW status defines slow retransmission ("will be transmitted twice at an initial interval of one second") while draft-ietf-mpls-tp-linear-protection specifies fast retransmission when required for fast recovery (section 3.1.4).=20 =20 In summary, PW redundancy was not designed with TP requirements in mind, and as such does not meet the TP requirements. Of course modifications may be introduced, but why reinvent the wheel when there is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards track that supports all the above requirements and can be applied to MS-PW protection with minor modifications? [[[Sasha]]] As I said, because the applicability scope is by far too narrow to justify a dedicated protocol. [DC] If we were discussing designing a new protocol, I might agree with you. But from a practical standpoint, the PW protection draft is not a dedicated protocol - it's an applicability statement to an existing protocol. Both from the implementation and the operational point of view it defines a new use case for an existing protocol and concept. =20 =20 Regards, =20 Daniel =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW" =20 Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. =20 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. =20 If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.=20 I also doubt why there is a need for additional mechanism.=20 Best regards, Nurit =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" =20 Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 ------_=_NextPart_001_01CC2A87.25E02F99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sasha, thanks again and see inline with = [DC].

 

From:= = Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] =
Sent: Monday, June 13, 2011 6:11 PM
To: Daniel = Cohn
Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - = IL/Hod HaSharon); ma.yuxia@zte.com.cn
Subject: RE: [mpls] = [PWE3] Seeking feedback on I-D = "MPLS-TPLinearProtectionApplicability to = MS-PW"

 

Daniel and all,

Please see some comments inline below.

 

Regards,

     Sasha

 

From:= = Daniel Cohn [mailto:DanielC@orckit.com]
Sent: Monday, June = 13, 2011 5:55 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); = Alexander Vainshtein; ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; = pwe3@ietf.org
Subject: RE: [mpls] [PWE3] Seeking feedback on = I-D "MPLS-TPLinearProtection Applicability to = MS-PW"

 

Hi,

 

Thanks all for the feedback. I believe we all agree that PW = protection is only required in the event of S-PE failure at an MS-PW = – this  is clearly stated in the draft. Now, both Sasha and = Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW = protection requirements.

 

First of all a word on scalability. Please note that in an MPLS-TP = environment without a control plane, the PW redundancy mechanism must = also rely on proactive connectivity check for fast failure detection to =  meet the sub-50 ms requirement. [[[Sasha]]] IMO there is = nothing specific to MPLS-TP here. Detecting S-PE failures based on the = control plane would  not fast = enough.

[DC] Agreed – I just pointed our that MPLS-TP has a requirement = for sub-50ms protection.

Therefore any scalability considerations that apply to the PW = protection draft apply to the PW redundancy draft as = well.[[[Sasha]]] I have not raised the scalability issue. My issue = was limited applicability scope when compared to PW redundancy. =

[DC] Correct – scalability issue was a response to = Nurit’s comment.

E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS- = and MS-PWs – something that liner protection of PWs cannot = do.

[DC] I’m afraid I don’t follow you here. Where does PW = redundancy take care of dual-homed CE? Actually PW redundancy draft = explicitly states: “The method for dual-homing of CE1 to PE1 and = to PE3 nodes, and the protocols used, are outside the scope of this = document”.

Also wrt scalability, there is no such thing as “scales” = or “doesn’t scale” – scalability is not a binary = concept. You can say that PW protection scales worse than LSP = protection, just like you can say that LSP protection scales worse than = interface protection. Which didn’t stop IETF from defining LSP = protection for scenarios where interface protection doesn’t do the = job.

 

Now let’s turn our attention back to whether the PW redundancy = draaft can be used to meet MPLS-TP PW protection requirements. I can = identify the following reasons why in its current form it = doesn’t:

 

-          = It explicitly (“outside the scope”) does not define = protection triggers and how to handle coexisting triggers, as requested = in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and = #79

[[[Sasha]]] So what? Definition of triggers is orthogonal to how = coordinated protection switching = happens.

[DC] It is. But still it needs to be defined by the recovery = framework, e.g. what should the endpoint do when one PW is in SF and the = other is in SD, or when both are in SD. Operators expect well-defined = behavior in these and other scenarios, and PW redundancy does not define = them (because it was not in their scope). =

-          = It does not support the ability to distinguish between different = types of triggers (i.e. one end doesn’t know why the other end = triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req = #77

-          = It does not define revertive/nonrevertive behavior, as requested in = RFC 5654 (MPLS-TP Requirements), req #64

-          = It does not define holdoff support, which is especially important to = avoid race conditions with LSP protection when it = exists

-          = It doesn’t support 1+1 mode, as requested in RFC 5654 (MPLS-TP = Requirements), req #65

[[[Sasha]]] All these claims are correct – and  this = should not be a surprise, because MPLS-TP requirements have been defined = much later than the PW redundancy mechanism. =

But I do not think that this justifies co-existence of two different = mechanisms.

[DC] So how do you propose to meet the PW protection requirement? =

-          = It’s a two-phase protocol, with the consequent impact on = timing[[[Sasha]]] Could you please elaborate? [DC] = In draft-ietf-mpls-tp-linear-protection, each endpoint will immediately = switch traffic to the other path upon identifying an SF condition in a = path, without waiting for the far end to acknowledge the switch = (1-phase). In PW redundancy, an endpoint detecting an SF condition in a = path will not switch until the far end has acknowledged the switch = (2-phase). Needless to say, recovery is slower in a 2-phase = protocol.

 

-          = It doesn’t define retransmission of protection coordination = messages, so loss of a single PDU can result in switchover not taking = place, thus not supporting sub-50 ms recovery in this = case

[[[Sasha]]] The PW redundancy protocol runs either on top of LDP = (which benefits from TCP retransmissions) or on top of static PW status = messages (where retransmission is defined). =

[DC] True – but static PW status defines slow retransmission = (“will be transmitted twice at an initial interval of one = second”) while draft-ietf-mpls-tp-linear-protection specifies fast = retransmission when required for fast recovery (section 3.1.4). =

 

In summary, PW redundancy was not designed with TP requirements in = mind, and as such does not meet the TP requirements. Of course = modifications may be introduced, but why reinvent the wheel when there = is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards = track that supports all the above requirements and can be applied to = MS-PW protection with minor modifications?

[[[Sasha]]] As I said, because the applicability scope is by far too = narrow to justify a dedicated protocol.

[DC] If we were discussing designing a new protocol, I might agree = with you. But from a practical standpoint, the PW protection draft is = not a dedicated protocol – it’s an applicability statement = to an existing protocol. Both from the implementation and the = operational point of view it defines a new use case for an existing = protocol and concept.

 

 

Regards,

 

Daniel

 

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Monday, June = 13, 2011 4:02 PM
To: ext Alexander Vainshtein; = ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; = pwe3@ietf.org
Subject: Re: [mpls] [PWE3] Seeking feedback on = I-D "MPLS-TPLinearProtection Applicability to = MS-PW"

 

Hi,

I would like to second Sasha.

End-to-end PW protection (with diverse paths) does not scale, and put = hard restrictions on the utilization of the resources. =  

MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. = Therefore, an obvious way to provide protection for a PW is to protect = the LSP that carries it. 

If the PW is a multi-segment PW, then LSP recovery can only protect = the PW in individual segments.  This means that a single LSP = recovery action cannot protect against a failure of a PW switching point = (an S-PE).

When protecting against an AC or T/S-PE failure by dual connectivity, = PW redundancy mechanisms provide means for the PEs to coordinate over = which LSP the traffic of the PW is carried.

I also doubt why there is a need for additional mechanism. =

Best regards,

Nurit

 

From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = ext Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 = PM
To: ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; = pwe3@ietf.org
Subject: Re: [PWE3] [mpls] Seeking feedback on = I-D "MPLS-TP LinearProtection Applicability to = MS-PW"

 

Dear Ma and all,

Adding the PWE3 WG to my response.

 

The PW redundancy mechanism supports linear protection of MS-PWs as = one of many additional application use cases:

Appendix A of the PW redundancy Bit draft describes 5 application = uses cases in addition to MS-PW with single-homed CEs (which is listed = there as use case 5).

And it is equally applicable to IP/MPLS and MPLS - with the help of =  the Static PW Status Messages draft( if, for whatever = reason, you do not want  to, or cannot, use RFC = 4447).

 

Hence I doubt the need for yet another PW redundancy  mechanism = with narrow scope of applicability.

 

Regards,

     Sasha

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ma.yuxia@zte.com.cn
Sent: Monday, June 13, 2011 3:25 = PM
To: mpls@ietf.org
Subject: Re: [mpls] Seeking = feedback on I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

 

Hi all,

The = linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

BTW, there = is a typo, it is "T-PE Z" instead of "T-PE B".

 &qu= ot;
  = Figure 1 illustrates such a scenario, where two MS-PWs are
  = established between T-PE A and T-PE B, = over S-PEs 1-2 and 3-4
  = respectively. Each PW segment is established over an LSP (e.g. = PW-
  = s12 over LSP12).
 &qu= ot;

-----Original Message-----
From: Daniel = Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: = Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability = to MS-PW"
Importance: High

Hi MPLSers,

I uploaded = "MPLS-TP Linear Protection Applicability to MS-PW" = I-D
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)
The abstract goes:

One of the requirements of the MPLS = transport profile [RFC 5654] is
to provide linear protection for = transport paths, which include both
LSPs and PWs. The functional = architecture described in [SurvivFwk]
is applicable to both LSP and = PWs, however [LinearProt] does not
explicitly describe mechanisms for = PW protection in MPLS-TP.

This document extends the applicability = of the linear protection
mechanism described in [LinearProt] to = MPLS-TP segmented PWs
(MS-PWs) as defined in [RFC = 6073].

Could you please review it and send feedback to the = mailing list or
directly to the author?

Looking forward to = your feedback,

Daniel

This e-mail = message is intended for the recipient only and contains information = which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by = e-mail, phone or fax, and then delete the original and all copies = thereof.

This e-mail message is intended for the = recipient only and contains information which is CONFIDENTIAL and which = may be proprietary to ECI Telecom. If you have received this = transmission in error, please inform us by e-mail, phone or fax, and = then delete the original and all copies thereof. =

------_=_NextPart_001_01CC2A87.25E02F99-- From maarten.vissers@huawei.com Tue Jun 14 04:41:27 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A83611E8097; Tue, 14 Jun 2011 04:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7W2Bin0ZVL1; Tue, 14 Jun 2011 04:41:26 -0700 (PDT) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by ietfa.amsl.com (Postfix) with ESMTP id C8AA511E8071; Tue, 14 Jun 2011 04:41:25 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMS00A4P350BQ@lhrga04-in.huawei.com>; Tue, 14 Jun 2011 12:41:24 +0100 (BST) Received: from LHREML201-EDG.china.huawei.com ([172.18.7.118]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMS0020D34ZIS@lhrga04-in.huawei.com>; Tue, 14 Jun 2011 12:41:23 +0100 (BST) Received: from LHREML401-HUB.china.huawei.com (10.201.5.30) by LHREML201-EDG.china.huawei.com (172.18.7.188) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 14 Jun 2011 12:41:17 +0100 Received: from LHREML503-MBX.china.huawei.com ([fe80::f93f:958b:5b06:4f36]) by LHREML401-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 14 Jun 2011 12:41:22 +0100 Date: Tue, 14 Jun 2011 11:41:22 +0000 From: Maarten vissers In-reply-to: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> X-Originating-IP: [10.47.154.38] To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_OxQQfV0EyXT1AJcxP7ctMw)" Content-language: en-US Accept-Language: en-GB, en-US Thread-topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" Thread-index: AQHMKco1J8PEH1bAJECgcknBiPna2pS7RefQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 11:41:27 -0000 --Boundary_(ID_OxQQfV0EyXT1AJcxP7ctMw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Nurit, If I translate your proposal in terms of SDH protection, then your proposal would imply that LOVC (e.g. VC-12, VC-11 protection should not be deployed, instead only HOVC (VC-4, VC-3) protection should be deployed. We all know that the SDH network has many protected LOVC connections, and that this is scaling well. My question is therefore why protecting MS-PW connections (and Service-LSP connections) would not scale? Regards, Maarten From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: 13 June 2011 15:02 To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources. MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried. I also doubt why there is a need for additional mechanism. Best regards, Nurit From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW" Dear Ma and all, Adding the PWE3 WG to my response. The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft( if, for whatever reason, you do not want to, or cannot, use RFC 4447). Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Hi all, The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly. BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". " Figure 1 illustrates such a scenario, where two MS-PWs are established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 respectively. Each PW segment is established over an LSP (e.g. PW- s12 over LSP12). " -----Original Message----- From: Daniel Cohn Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author? Looking forward to your feedback, Daniel This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. --Boundary_(ID_OxQQfV0EyXT1AJcxP7ctMw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Nurit,<= /p>

 <= /p>

If I translate your propo= sal in terms of SDH protection, then your proposal would imply that LOVC (e= .g. VC-12, VC-11 protection should not be deployed, instead only HOVC (VC-4, VC-3) protection should be deployed. We all know that the= SDH network has many protected LOVC connections, and that this is scaling = well. My question is therefore why protecting MS-PW connections (and Servic= e-LSP connections) would not scale?

 <= /p>

Regards,

Maarten=

 <= /p>

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: 13 June 2011 15:02
To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Lin= earProtection Applicability to MS-PW"

 

Hi,

I would li= ke to second Sasha.

End-to-end= PW protection (with diverse paths) does not scale, and put hard restrictio= ns on the utilization of the resources.  

MPLS-TP PW= s are carried across the network inside MPLS-TP LSPs. Therefore, an obvious= way to provide protection for a PW is to protect the LSP that carries it. 

If the PW = is a multi-segment PW, then LSP recovery can only protect the PW in individ= ual segments.  This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE).

When prote= cting against an AC or T/S-PE failure by dual connectivity, PW redundancy m= echanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.

I also dou= bt why there is a need for additional mechanism.

Best regar= ds,

Nurit=

 = ;

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 PM
To: ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; pwe3@ietf.org
Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Lin= earProtection Applicability to MS-PW"

 

Dear Ma an= d all,

Adding the= PWE3 WG to my response.

 = ;

The PW red= undancy mechanism supports linear protection of MS-PWs as one of many addit= ional application use cases:

Appendix A= of the PW redundancy Bit draft describes 5 application uses cases in addition = to MS-PW with single-homed CEs (which is listed there as use case 5).<= /o:p>

And it is = equally applicable to IP/MPLS and MPLS - with the help of  the Static PW Status Messages draft( if, for whatever reason, you do not wa= nt  to, or cannot, use RFC 4= 447).

 = ;

Hence I do= ubt the need for yet another PW redundancy  mechanism with narrow scop= e of applicability.

 = ;

Regards,

 &nbs= p;   Sasha

 = ;

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn
Sent: Monday, June 13, 2011 3:25 PM
To: mpls@ietf.org
Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Pro= tection Applicability to MS-PW"

 

Hi all,

The linear protection mechanism for LSP and PW(including MS-PW) sh= ould be the same and it is valuable to describe it clearly.

BTW, there is a typo, it is "T-PE Z&q= uot; instead of "T-PE B".

 " =
  Figure 1 illustrates such a scenario, where two MS-PWs are
  established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4
  respectively. Each PW segment is established over an LSP (e.g. PW-
  s12 over LSP12).
 "

-----Original Message---= --
From: Daniel Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D=
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)

The abstract goes:

One of the requirements of the MPLS transport profile [RFC 5654] is
to provide linear protection for transport paths, which include both
LSPs and PWs. The functional architecture described in [SurvivFwk]
is applicable to both LSP and PWs, however [LinearProt] does not
explicitly describe mechanisms for PW protection in MPLS-TP.

This document extends the applicability of the linear protection
mechanism described in [LinearProt] to MPLS-TP segmented PWs
(MS-PWs) as defined in [RFC 6073].

Could you please review it and send feedback to the mailing list or
directly to the author?

Looking forward to your feedback,

Daniel

This e-mail message is intended for the recipient o= nly and contains information which is CONFIDENTIAL and which may be proprie= tary to ECI Telecom. If you have received this transmission in error, pleas= e inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

--Boundary_(ID_OxQQfV0EyXT1AJcxP7ctMw)-- From DanielC@orckit.com Tue Jun 14 04:44:05 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE5111E8071; Tue, 14 Jun 2011 04:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnPmCbtPBjjb; Tue, 14 Jun 2011 04:44:04 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9BB11E80A8; Tue, 14 Jun 2011 04:44:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2A88.93759A2A" Date: Tue, 14 Jun 2011 14:44:00 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306CF3552@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwpydFuQ8gnnYX6SMu1tAmQpJ1OkwAvSjPA References: From: "Daniel Cohn" To: "binny jeshan" , "Alexander Vainshtein" Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 11:44:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2A88.93759A2A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Binny, =20 The assumption is that lower-layer protection (LSP or link protection) will take care of single-segment failures not affecting S-PEs. The hold-off mechanism defined in [LinearProt], when properly configured, prevents MS-PW switchover in this scenario. As you say, this is because lower-layer protection is more efficient so it should be used when possible. =20 Regards, =20 Daniel =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of binny jeshan Sent: Monday, June 13, 2011 3:58 PM To: Alexander Vainshtein Cc: pwe3@ietf.org; mpls@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hello authors, I have a generic question on the co-existence of PW monitoring at the MS-PW level (PSMEG) and the individual segment level (PMEG). Firstly, I believe there is no such restriction on having co-existence in monitoring these independently.. Now lets say if a monitored mid segment (a simple PMEG) of a 5 segment MSPW fails, its quite possible that the PSMEG also detects it at the endpoints. Now, what would determine the switching priority? Wouldn't it become costlier if the PSMEG does a MS-PW level switching? Instead, one could prefer to switch to a backup path at a segment level itself. Is this addressed? Thanks, Binny. On 13 June 2011 18:13, Alexander Vainshtein wrote: Dear Ma and all, Adding the PWE3 WG to my response. =20 The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Static PW Status Messages draft ( if, for whatever reason, you do not want to, or cannot, use RFC 4447 ). =20 Hence I doubt the need for yet another PW redundancy mechanism with narrow scope of applicability. =20 Regards, Sasha =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" =20 Hi all,=20 The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.=20 BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 "=20 Figure 1 illustrates such a scenario, where two MS-PWs are=20 established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 respectively. Each PW segment is established over an LSP (e.g. PW-=20 s12 over LSP12).=20 "=20 -----Original Message----- From: Daniel Cohn=20 Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author?=20 Looking forward to your feedback,=20 Daniel=20 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 =20 ------_=_NextPart_001_01CC2A88.93759A2A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Binny,

 

The assumption is that lower-layer protection (LSP or link = protection) will take care of single-segment failures not affecting = S-PEs. The hold-off mechanism defined in [LinearProt], when properly = configured, prevents MS-PW switchover in this scenario. As you say, this = is because lower-layer protection is more efficient so it should be used = when possible.

 

Regards,

 

Daniel

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = binny jeshan
Sent: Monday, June 13, 2011 3:58 = PM
To: Alexander Vainshtein
Cc: pwe3@ietf.org; = mpls@ietf.org
Subject: Re: [mpls] [PWE3] Seeking feedback on = I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

 

Hello authors,

I have a generic = question on the co-existence of PW monitoring at the MS-PW level = (PSMEG) and the individual segment level (PMEG). Firstly, I believe = there is no such restriction on having co-existence in monitoring these = independently..

Now lets say if a monitored mid segment (a simple = PMEG) of a 5 segment MSPW fails, its quite possible that the PSMEG also = detects it at the endpoints. Now, what would determine the switching = priority? Wouldn't it become costlier if the PSMEG does a MS-PW = level switching? Instead, one could prefer to switch to a backup path at = a segment level itself. Is this = addressed?

Thanks,
Binny.

On 13 June 2011 18:13, Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com> wrote:

Dear Ma and = all,

Adding the PWE3 WG to my = response.

 

The PW redundancy mechanism = supports linear protection of MS-PWs as one of many additional = application use cases:

Appendix A of the PW redundancy Bit draft describes = 5 application uses cases in addition to MS-PW with single-homed CEs = (which is listed there as use case 5).

And it is equally applicable to = IP/MPLS and MPLS - with the help of  the Static PW Status Messages = draft( if, for whatever reason, you do not want  to, or cannot, = use RFC 4447).

 

Hence I doubt the need for yet = another PW redundancy  mechanism with narrow scope of = applicability.

 

Regards,

     = Sasha

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn
Sent: Monday, June = 13, 2011 3:25 PM
To: mpls@ietf.org
Subject: Re: [mpls] = Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to = MS-PW"

 <= /o:p>

Hi all, =

The linear protection mechanism = for LSP and PW(including MS-PW) should be the same and it is valuable to = describe it clearly.

BTW, there is a typo, it is "T-PE = Z" instead of "T-PE B". =

 " =
  Figure 1 illustrates such a = scenario, where two MS-PWs are
  established between T-PE A and = T-PE B, over S-PEs 1-2 and 3-4 =
  respectively. Each PW = segment is established over an LSP (e.g. PW-
  s12 over LSP12).
 " =

-----Original = Message-----
From: Daniel Cohn
Sent: Tuesday, May 17, 2011 4:14 = PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear = Protection
Applicability to MS-PW"
Importance: High

Hi = MPLSers,

I uploaded "MPLS-TP Linear Protection Applicability = to MS-PW" I-D
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protec= tion-00)

The abstract goes:

One of the requirements of the MPLS = transport profile [RFC 5654] is
to provide linear protection for = transport paths, which include both
LSPs and PWs. The functional = architecture described in [SurvivFwk]
is applicable to both LSP and = PWs, however [LinearProt] does not
explicitly describe mechanisms for = PW protection in MPLS-TP.

This document extends the applicability = of the linear protection
mechanism described in [LinearProt] to = MPLS-TP segmented PWs
(MS-PWs) as defined in [RFC = 6073].

Could you please review it and send feedback to the = mailing list or
directly to the author?

Looking forward to = your feedback,

Daniel =

This e-mail message is = intended for the recipient only and contains information which is = CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have = received this transmission in error, please inform us by e-mail, phone = or fax, and then delete the original and all copies thereof. =


______________________________________= _________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

 

------_=_NextPart_001_01CC2A88.93759A2A-- From Alexander.Vainshtein@ecitele.com Tue Jun 14 05:02:25 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F2311E80AF; Tue, 14 Jun 2011 05:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUjyl1prLlrM; Tue, 14 Jun 2011 05:02:17 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 79EF211E808A; Tue, 14 Jun 2011 05:02:15 -0700 (PDT) X-AuditID: 93eaf2e8-b7c74ae000000a6f-96-4df74d6235df Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id DC.FF.02671.26D47FD4; Tue, 14 Jun 2011 15:00:35 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 14 Jun 2011 15:02:12 +0300 From: Alexander Vainshtein To: Daniel Cohn Date: Tue, 14 Jun 2011 15:02:10 +0300 Thread-Topic: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" Thread-Index: AcwpxQYkt1VB87JDQZmWlDJG9yJyKgAABTPQAADcskAABE5ygAAADmpwACeE3pAAA/tUMA== Message-ID: References: <077E41CFFD002C4CAB7DFA4386A5326403F64953@DEMUEXC014.nsn-intra.net> <44F4E579A764584EA9BDFD07D0CA081306CF33B5@tlvmail1> <44F4E579A764584EA9BDFD07D0CA081306CF354A@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306CF354A@tlvmail1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9D92ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELsWRmVeSWpSXmKPExsUy+dWnL7rJvt99DWbPFrRouLSYyeLrjJvM FreWrmS1uH1/O7tF36ctLA6sHkuW/GTy+Ln+KrtH94bJzB5r9v1gCWCJamC0SczLyy9JLElV SEktTrZVCijKLEtMrlRSyEyxVTJUUijISUxOzU3NK7FVSiwoSM1LUbLjUsAANkBlmXkKqXnJ +SmZeem2Sp7B/roWFqaWuoZKdmrKhsbWXCEZmcUKqbq5iZk5CrmpxcWJ6akKQJGELcwZS46+ Zi64e56l4tGPKywNjPN6WLoYOTkkBEwkfmzcwwhhi0lcuLeerYuRi0NIYCejxLKdt6GcKYwS J1Z/ZQepYhOwldi0+i4biC0ioCKx8dpHsDgzSMeVMz4gNouAqsSpR33MILawQIrEokk3WSDq UyVe794L1RsmcajzOJjNK+AvcWHeQ2aIZb3MEtOb3oGdxCngILHlxT0wmxHovO+n1jBBLBOX uPVkPhPE2QISS/acZ4awRSVePv7HClEvKnGnfT0jRH2+xOVbp9ghlglKnJz5BOp9SYmDK26w TGAUm4Vk7CwkLbOQtEDEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjKKZOQUlSbnpBkZ6 qcmZJak5qXrJ+bmbGCEJ68UOxttnNA8xCnAwKvHwbrD45ivEmlhWXJl7iFGSg0lJlFfN57uv EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe3ldffIV4UxIrq1KL8mFSrsDgn8gsxZ2cD0zCeSXx xgYGuDlK4rzdyW98hQTSgakzOzW1ILUIZo4MB4eSBO8bkPWCRanpqRVpmTklCGkmDk6QM3iA zpAGZg0h3uKCxNzizHSI/ClGS473h9cfYuT4O2cTkJy8DEgKseTl56VKifOeBxkqANKQUZoH NxOU1er/////ilEcGBjCvA9AqniAGRFu6iughUxAC2+9/AayEJij4FJSDYzmtpEp7rlHTG/N u+o5RWknp6n8Cr01oR/raxWWXX2mvmjizgt9nByF1gqvH1ivtNvR18f2e7HXD13P3/PCjxkL hzz1WcJbFBbBPrlO+OOUmCn6+SwShyRZ178JtHaZdfXCVSaFpQ+ONqwwrg+yWc27NfNhmPu1 xeu3/F1jkFeTZx0eeDjuUoESS3FGoqEWc1FxIgBy16YKRQQAAA== Cc: "ma.yuxia@zte.com.cn" , "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 12:02:26 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9D92ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Daniel, Please see more inline (bold purple italics). I've also stripped the portion= s of the text that are not related to this round of comments. Regards, Sasha From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Tuesday, June 14, 2011 2:34 PM To: Alexander Vainshtein Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); m= a.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionA= pplicability to MS-PW" Hi Sasha, thanks again and see inline with [DC]. From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, June 13, 2011 6:11 PM To: Daniel Cohn Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); m= a.yuxia@zte.com.cn Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionA= pplicability to MS-PW" Daniel and all, Please see some comments inline below. Regards, Sasha From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, June 13, 2011 5:55 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@= zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi, Thanks all for the feedback. I believe we all agree that PW protection is on= ly required in the event of S-PE failure at an MS-PW - this is clearly stat= ed in the draft. Now, both Sasha and Nurit mention that the PW redundancy me= chanism can meet the MPLS-TP PW protection requirements. [[[Sasha]]] ... snipped ... E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS- and MS= -PWs - something that liner protection of PWs cannot do. [DC] I'm afraid I don't follow you here. Where does PW redundancy take care= of dual-homed CE? Actually PW redundancy draft explicitly states: "The meth= od for dual-homing of CE1 to PE1 and to PE3 nodes, and the protocols used, a= re outside the scope of this document". [[[Sasha]]] Quoting from the draft: 15.2. Multiple Multi-homed CEs with single SS-PW redundancy |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnels-->| | | | V V (not shown) V V | V AC +----+ +----+ AC V +-----+ | |....|.......PW1........|....| | +-----+ | |----------| PE1|...... .........| PE3|----------| | | CE1 | +----+ \ / PW3 +----+ | CE2 | | | +----+ X +----+ | | | | | |....../ \..PW4....| | | | | |----------| PE2| | PE4|--------- | | +-----+ | |....|.....PW2..........|....| | +-----+ AC +----+ +----+ AC Figure 15-2 Multiple Multi-homed CEs with single SS-PW redundancy The application in Figure 15-2 makes use of the Independent mode of operation. CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. The method for dual-homing and the used protocols are outside the scope of this document. Note that the PSN tunnels are not shown in this figure for clarity. However, it can be assumed that each of the PWs shown is encapsulated in a separate PSN tunnel. Assume that the AC from CE1 to PE1 is Active, from CE1 to PE2 is Standby; furthermore, assume that the AC from CE2 to PE3 is Standby and from CE2 to PE4 is Active. The method of deriving Active/Standby status of the AC is outside the scope of this document. PE1 advertises the preferential status "Active" and operational status "Pseudowire forwarding" for pseudowires PW1 and PW4 connected to PE3 and PE4. This status reflects the forwarding state of the AC attached to PE1. PE2 advertises preferential status "Standby" and operational status "Pseudowire forwarding" for pseudowires PW2 and PW3 to PE3 and PE4. PE3 advertises preferential status "Standby" and operational status "Pseudowire forwarding" for pseudowires PW1 and PW3 to PE1 and PE2. PE4 advertise the preferential status "Active" and operational status "Pseudowire forwarding" for pseudowires PW2 and PW4 to PE2 and PE1 respectively. Thus by matching the local and remote preferential forwarding status of "Active" and operational status of "Pseudowire forwarding" of pseudowires, the PE nodes determine which PW should be in the Active state. In this case it is PW4 that will be selected. On failure of the AC between CE1 and PE1, the forwarding state of the AC on PE2 is changed to Active. PE2 then announces the newly changed 'preferential forwarding' status bit of "active" to PE3 and PE4. PE1 will advertise a PW status notification message indicating that the AC between CE1 and PE1 is operationally down. PE2 and PE4 match the local and remote preferential forwarding status of "Active" and operational status "Pseudowire forwarding" and select PW2 as the new active pseudowire to send traffic to. On failure of PE1 node, PE2 will detect it and will transition the forwarding state of its AC to Active. The method by which PE2 detects that PE1 is down is outside the scope of this document. PE2 then announces the newly changed 'preferential forwarding' status bit of "Active" to PE3 and PE4. PE2 and PE4 match the local and remote preferential forwarding status of "Active" and operational status "Pseudowire forwarding" and select PW2 as the new active pseudowire to send traffic to. Note that PE3 and PE4 may have detected that the PW to PE1 went down via T-LDP Hello timeout or via other means. However, they will not be able to forward user traffic until they received the updated status bit from PE2. Because each dual-homing algorithm running on the two node sets, i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently, there is a need to signal the active status of the AC such that the PE nodes can select a common active PW for end-to-end forwarding between CE1 and CE2 as per the procedures in the independent mode. Note that any primary/secondary procedures, as defined in sections 5.1. and 5.2. , do not apply in this use case as the Active/Standby status is driven by the AC forwarding state as determined by the AC dual-homing protocol used. I believe you've taken your "out of scope" reference from this text, but IMH= O you misinterpreted it. What it means (or so I read it) is that specific dual-homing protocol is out= of scope as long as it meets certain assumptions. Aside: It would be good if the authors of the PW redundancy drafts could exp= licitly specify these assumptions. [[[Sasha]]] ... snipped ... Now let's turn our attention back to whether the PW redundancy draaft can be= used to meet MPLS-TP PW protection requirements. I can identify the followi= ng reasons why in its current form it doesn't: - It explicitly ("outside the scope") does not define protection tr= iggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS= -TP Requirements), reqs #75, #76 and #79 [[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinated= protection switching happens. [DC] It is. But still it needs to be defined by the recovery framework, e.g.= what should the endpoint do when one PW is in SF and the other is in SD, or= when both are in SD. Operators expect well-defined behavior in these and ot= her scenarios, and PW redundancy does not define them (because it was not in= their scope). [[[Sasha]]] I wonder if you have followed the discussion regarding ability t= o define SD condition for LSPs and PWs on the MPLS-TP list? IMO it is not po= ssible to define it in a meaningful way. Hence I do not see a proposal that= does not address a scenario that does not exist in reality as a flawed one. - It does not support the ability to distinguish between different= types of triggers (i.e. one end doesn't know why the other end triggered sw= itch), as requested in RFC 5654 (MPLS-TP Requirements), req #77 - It does not define revertive/nonrevertive behavior, as requested= in RFC 5654 (MPLS-TP Requirements), req #64 - It does not define holdoff support, which is especially important= to avoid race conditions with LSP protection when it exists - It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP Re= quirements), req #65 [[[Sasha]]] All these claims are correct - and this should not be a surpris= e, because MPLS-TP requirements have been defined much later than the PW red= undancy mechanism. But I do not think that this justifies co-existence of two different mechani= sms. [DC] So how do you propose to meet the PW protection requirement? - It's a two-phase protocol, with the consequent impact on timing[[= [Sasha]]] Could you please elaborate? [DC] In draft-ietf-mpls-tp-linear-prot= ection, each endpoint will immediately switch traffic to the other path upon= identifying an SF condition in a path, without waiting for the far end to a= cknowledge the switch (1-phase). In PW redundancy, an endpoint detecting an= SF condition in a path will not switch until the far end has acknowledged t= he switch (2-phase). Needless to say, recovery is slower in a 2-phase protoc= ol. [[[Sasha]]] To the best of my understanding, 1-phase protection is only poss= ible in 1+1 unidirectional architectures. And yes, I know that MPLS-TP requi= res a mechanism to support this; whether anybody would really do that in th= e packet-switching network is not clear to me. And I acknowledge that the PW= redundancy drafts do not support 1+1 unidirectional scheme. - It doesn't define retransmission of protection coordination messa= ges, so loss of a single PDU can result in switchover not taking place, thus= not supporting sub-50 ms recovery in this case [[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which bene= fits from TCP retransmissions) or on top of static PW status messages (where= retransmission is defined). [DC] True - but static PW status defines slow retransmission ("will be trans= mitted twice at an initial interval of one second") while draft-ietf-mpls-tp= -linear-protection specifies fast retransmission when required for fast reco= very (section 3.1.4). In summary, PW redundancy was not designed with TP requirements in mind, and= as such does not meet the TP requirements. Of course modifications may be i= ntroduced, but why reinvent the wheel when there is a protocol (draft-ietf-m= pls-tp-linear-protection-06) in the standards track that supports all the ab= ove requirements and can be applied to MS-PW protection with minor modificat= ions? [[[Sasha]]] As I said, because the applicability scope is by far too narrow= to justify a dedicated protocol. [DC] If we were discussing designing a new protocol, I might agree with you.= But from a practical standpoint, the PW protection draft is not a dedicated= protocol - it's an applicability statement to an existing protocol. Both fr= om the implementation and the operational point of view it defines a new use= case for an existing protocol and concept. Regards, Daniel From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spre= cher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, June 13, 2011 4:02 PM To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection= Applicability to MS-PW" Hi, I would like to second Sasha. End-to-end PW protection (with diverse paths) does not scale, and put hard r= estrictions on the utilization of the resources. MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, a= n obvious way to provide protection for a PW is to protect the LSP that carr= ies it. If the PW is a multi-segment PW, then LSP recovery can only protect the PW i= n individual segments. This means that a single LSP recovery action cannot= protect against a failure of a PW switching point (an S-PE). When protecting against an AC or T/S-PE failure by dual connectivity, PW red= undancy mechanisms provide means for the PEs to coordinate over which LSP th= e traffic of the PW is carried. I also doubt why there is a need for additional mechanism. Best regards, Nurit From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext= Alexander Vainshtein Sent: Monday, June 13, 2011 3:43 PM To: ma.yuxia@zte.com.cn Cc: mpls@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection= Applicability to MS-PW" Dear Ma and all, Adding the PWE3 WG to my response. The PW redundancy mechanism supports linear protection of MS-PWs as one of m= any additional application use cases: Appendix A of the PW redundancy Bit draft describes 5 application uses= cases in addition to MS-PW with single-homed CEs (which is listed there as= use case 5). And it is equally applicable to IP/MPLS and MPLS - with the help of the Sta= tic PW Status Messages draft( if, for whatever reason, you do not wa= nt to, or cannot, use RFC 4447). Hence I doubt the need for yet another PW redundancy mechanism with narrow= scope of applicability. Regards, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.y= uxia@zte.com.cn Sent: Monday, June 13, 2011 3:25 PM To: mpls@ietf.org Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Appli= cability to MS-PW" Hi all, The linear protection mechanism for LSP and PW(including MS-PW) should be th= e same and it is valuable to describe it clearly. BTW, there is a typo, it is "T-PE Z" instead of "T-PE B". " Figure 1 illustrates such a scenario, where two MS-PWs are established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 respectively. Each PW segment is established over an LSP (e.g. PW- s12 over LSP12). " -----Original Message----- From: Daniel Cohn Sent: Tuesday, May 17, 2011 4:14 PM To: mpls Subject: Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Importance: High Hi MPLSers, I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) The abstract goes: One of the requirements of the MPLS transport profile [RFC 5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs (MS-PWs) as defined in [RFC 6073]. Could you please review it and send feedback to the mailing list or directly to the author? Looking forward to your feedback, Daniel This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9D92ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Daniel,=

Please see more inline (bold pur= ple italics). I’ve also stripped the portions of the text that are not= related to this round of comments.

 

Regards,=

     Sa= sha

 <= /span>

From: Daniel Cohn [mailto:Dani= elC@orckit.com]
Sent: Tuesday, June 14, 2011 2:34 PM
To: Alexander Vainshtein
Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher,= Nurit (NSN - IL/Hod HaSharon); ma.yuxia@zte.com.cn
Subject: RE: [= mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicabil= ity to MS-PW"

 

Hi Sasha, thanks again and see= inline with [DC].

&nbs= p;

From: Alexander Vainshtei= n [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Monday, June 13= , 2011 6:11 PM
To: Daniel Cohn
Cc: mpls@ietf.org; pwe3@i= etf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); ma.yuxia@zte.com.cn
= Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearPr= otectionApplicability to MS-PW"

 

Daniel and al= l,

Please see some comments= inline below.

 

Regards,

     Sasha=

 

From: Daniel Cohn [mailto:DanielC@orckit.com] Sent: Monday, June 13, 2011 5:55 PM
To: Sprecher, Nurit (N= SN - IL/Hod HaSharon); Alexander Vainshtein; ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; pwe3@ietf.org
Subject: RE: [mpls] [PWE3] Seeking= feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW"<= o:p>

 

<= p class=3DMsoNormal>Hi,

 

Thanks all for the= feedback. I believe we all agree that PW protection is only required in the= event of S-PE failure at an MS-PW – this  is clearly stated in t= he draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism= can meet the MPLS-TP PW protection requirements.

[[[Sasha]]] … snipped …

E.g., the PW redundancy me= chanisms take care of dual-homed CEs in SS- and MS-PWs – something tha= t liner protection of PWs cannot do.

[DC] I’m afraid I don’t follow you here= . Where does PW redundancy take care of dual-homed CE? Actually PW redundanc= y draft explicitly states: “The method for dual-homing of CE1 to PE1 a= nd to PE3 nodes, and the protocols used, are outside the scope of this docum= ent”.

[= [[Sasha]]] Quoting from the draft:

15.2. Multiple Multi-homed CEs with si= ngle SS-PW redundancy

 

       &nbs= p;     |<-------------- Emulated Service ------------= ---->| 

          =    |         &nb= sp;            &= nbsp;            = ;            &nb= sp;  | 

         &nbs= p;   |         = |<------- Pseudo Wire ------>|      &nb= sp;   | 

        &nbs= p;    |        &= nbsp; |           &nb= sp;            &= nbsp;   |          |&= nbsp;

           &nbs= p; |          |  = ;  |<-- PSN Tunnels-->|    |   &nbs= p;      | 

     &nbs= p;       |     &= nbsp;    V    V    (not shown)&= nbsp;  V    V       &= nbsp;  | 

         &= nbsp;   V    AC    +----+ =             &nbs= p;    +----+     AC   V  <= o:p>

<= b>&= nbsp;      +-----+    | &n= bsp;   |....|.......PW1........|....|     |&nb= sp;   +-----+ 

       |&nb= sp;    |----------| PE1|......   .........| PE3|---= -------|     | 

     &nbs= p; | CE1 |          +----+=       \ /  PW3    +----+ &= nbsp;        | CE2 | 

  &n= bsp;    |     |   &nb= sp;      +----+      = X          +----+  &= nbsp;       |     | <= /o:p>

 =       |     |  &= nbsp;       |    |....../ \..PW= 4....|    |        &n= bsp; |     | 

      &= nbsp;|     |----------| PE2|    &nbs= p;             |= PE4|--------- |     | 

<= p class=3DMsoNormal style=3D'margin-left:25.5pt'>    &nb= sp;  +-----+    |     |....|...= ..PW2..........|....|     |    +-----+&nb= sp;

            =       AC    +----+  &= nbsp;            = ;   +----+    AC      = ;

    

   &n= bsp; Figure 15-2 Multiple Multi-homed CEs with single SS-PW redundancy&= nbsp;

 

   The application in Figure 15-2 makes use of the Ind= ependent mode of

 

   CE1 is dual= -homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. The =

   = method for dual-homing and the used protocols are outside the scope

 &n= bsp; of this document.  Note that the PSN tunnels are not shown in= this

   figure for clarity. However, it can be assumed that= each of the PWs

 

   Assume that the AC from CE1 to PE1 is Active, from= CE1 to PE2 is

   Standby; furthermore, assume that the AC fr= om CE2 to PE3 is Standby

   and from CE2 to PE4 is Active. Th= e method of deriving Active/Standby

   status of the AC is ou= tside the scope of this document.

 

   PE1 advertises the pr= eferential status "Active" and operational <= /p>

   statu= s "Pseudowire forwarding" for pseudowires PW1 and PW4 connected

&n= bsp;  to PE3 and PE4. This status reflects the forwarding state of= the AC

   attached to PE1. PE2 advertises preferential statu= s "Standby" and

   operational status "Pseudow= ire forwarding" for pseudowires PW2 and

   PW3 to PE3 an= d PE4. PE3 advertises preferential status "Standby" and

 &nbs= p; operational status "Pseudowire forwarding" for pseudowires= PW1 and

   PW3 to PE1 and PE2. PE4 advertise the preferentia= l status "Active"

   and operational status "P= seudowire forwarding" for pseudowires PW2

   and PW4 to= PE2 and PE1 respectively. Thus by matching the local and =

   = remote preferential forwarding status of "Active" and operational=

   status of "Pseudowire forwarding" of pseudowire= s, the PE nodes

   determine which PW should be in the Active= state. In this case it is

   PW4 that will be selected. = ;

   On failure of the AC between CE1 and PE1, the forwardin= g state of

   the AC on PE2 is changed to Active. PE2 then an= nounces the newly

   changed 'preferential forwarding' status= bit of "active" to PE3 and

   PE4. PE1 will advert= ise a PW status notification message indicating

   that the A= C between CE1 and PE1 is operationally down. PE2 and PE4 <= /b>

   m= atch the local and remote preferential forwarding status of

  &n= bsp;"Active" and operational status "Pseudowire forwarding&qu= ot; and select

   PW2 as the new active pseudowire to send tr= affic to.

 

   On failure of PE1 node, PE2 will detect it and= will transition the

   forwarding state of its AC to Active.= The method by which PE2

   detects that PE1 is down is outsi= de the scope of this document. PE2

   then announces the newl= y changed 'preferential forwarding' status

   bit of "Ac= tive" to PE3 and PE4. PE2 and PE4 match the local and

   = ;remote preferential forwarding status of "Active" and operational=

   status "Pseudowire forwarding" and select PW2 a= s the new active

   detected that the PW to PE1 went d= own via T-LDP Hello timeout or via

   other means. However, t= hey will not be able to forward user traffic

   until they re= ceived the updated status bit from PE2.

 

   Because each du= al-homing algorithm running on the two node sets,

=

   i.e., {C= E1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC <= /b>

   i= ndependently, there is a need to signal the active status of the AC

 &n= bsp; such that the PE nodes can select a common active PW for end-to-en= d

   independent mode.

 

   Note that any p= rimary/secondary procedures, as defined in sections

   5.1.&n= bsp; and 5.2. , do not apply in this use case as the Active/Standby

 &n= bsp; status is driven by the AC forwarding state as determined by the A= C

 

I believe you’ve taken your “out of scope= 221; reference from this text, but IMHO you misinterpreted it.

What it means (or so I rea= d it) is that specific dual-homing protocol is out of scope as long as it me= ets certain assumptions.

<= b>Aside: It would be good if the authors of the PW redundancy draft= s could explicitly specify these assumptions.

<= p class=3DMsoNormal> 

[[[Sasha]]] … snipped …

 

Now let’s turn our attention back to whether the P= W redundancy draaft can be used to meet MPLS-TP PW protection requirements.= I can identify the following reasons why in its current form it doesn’= ;t:

 =

-      =     It explicitly (“outside the scope”) does not define protectio= n triggers and how to handle coexisting triggers, as requested in RFC 5654 (= MPLS-TP Requirements), reqs #75, #76 and #79

[[[Sasha]]] So what? Definition of triggers is orth= ogonal to how coordinated protection switching happens.

[DC] It is. But still it needs to= be defined by the recovery framework, e.g. what should the endpoint do when= one PW is in SF and the other is in SD, or when both are in SD. Operators e= xpect well-defined behavior in these and other scenarios, and PW redundancy= does not define them (because it was not in their scope).

[[[Sasha]]] I wonder if you ha= ve followed the discussion regarding ability to define SD condition for LSPs= and PWs on the MPLS-TP list? IMO it is not possible to define it in a meani= ngful way. Hence I do not see a proposal that does not address a scenario th= at does not exist in reality as a flawed one.

<= p class=3DMsoNormal> 

-        &= nbsp; It does no= t support the ability to distinguish between different types of triggers (i.= e. one end doesn’t know why the other end triggered switch), as reques= ted in RFC 5654 (MPLS-TP Requirements), req #77

<= ![if !supportLists]>-        =   It does n= ot define revertive/nonrevertive behavior, as requested in RFC 5654 (MPLS-TP= Requirements), req #64

-          It does not define holdoff suppor= t, which is especially important to avoid race conditions with LSP protectio= n when it exists

-&nb= sp;         It doesn’t support 1+1 mode, as re= quested in RFC 5654 (MPLS-TP Requirements), req #65

[[[Sasha]]] All these claims ar= e correct – and  this should not be a surprise, because MPLS-TP r= equirements have been defined much later than the PW redundancy mechanism. <= o:p>

But I do not t= hink that this justifies co-existence of two different mechanisms.

[DC] So how do you prop= ose to meet the PW protection requirement? =

-  &nbs= p;       It’s a two-phase protocol, with the consequent= impact on timing[[[Sasha]]] Could you please elaborate? [DC] In draft-ietf-mpls-tp-linear-protection, each endpoint will immediatel= y switch traffic to the other path upon identifying an SF condition in a pat= h, without waiting for the far end to acknowledge the switch (1-phase). In P= W redundancy, an endpoint detecting an SF condition in a path will not switc= h until the far end has acknowledged the switch (2-phase). Needless to say,= recovery is slower in a 2-phase protocol.

[[[Sasha]]] To the best of my understanding, 1-= phase protection is only possible in 1+1 unidirectional architectures. And y= es, I know that MPLS-TP requires a  mechanism to support this; whether= anybody would really do that in the packet-switching network is not clear t= o me. And I acknowledge that the PW redundancy drafts do not support 1+1 uni= directional scheme.

 

-It doesn’t define retransmis= sion of protection coordination messages, so loss of a single PDU can result= in switchover not taking place, thus not supporting sub-50 ms recovery in t= his case

[[[Sasha]]] T= he PW redundancy protocol runs either on top of LDP (which benefits from TCP= retransmissions) or on top of static PW status messages (where retransmissi= on is defined).

[DC] True – but static PW status defines slow retransmission (̶= 0;will be transmitted twice at an initial interval of one second”) whi= le draft-ietf-mpls-tp-linear-protection specifies fast retransmission when r= equired for fast recovery (section 3.1.4).

 

In summary, PW redundancy was not designed with TP requirements in mind,= and as such does not meet the TP requirements. Of course modifications may= be introduced, but why reinvent the wheel when there is a protocol (draft-i= etf-mpls-tp-linear-protection-06) in the standards track that supports all t= he above requirements and can be applied to MS-PW protection with minor modi= fications?

[[[Sasha]]]= As I said, because the applicability scope is by far too narrow to justify= a dedicated protocol.

= [DC] If we were discussing designing a new protocol, I might agree= with you. But from a practical standpoint, the PW protection draft is not a= dedicated protocol – it’s an applicability statement to an exis= ting protocol. Both from the implementation and the operational point of vie= w it defines a new use case for an existing protocol and concept.=

 

 

Regards,

 

Daniel

 

 

From: mpls-bounces= @ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit= (NSN - IL/Hod HaSharon)
Sent: Monday, June 13, 2011 4:02 PM
To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn
Cc: mpls@ie= tf.org; pwe3@ietf.org
Subject: Re: [mpls] [PWE3] Seeking feedback= on I-D "MPLS-TPLinearProtection Applicability to MS-PW"

 

Hi,

I wou= ld like to second Sasha.

End= -to-end PW protection (with diverse paths) does not scale, and put hard rest= rictions on the utilization of the resources.  

MPLS-TP PWs are carried across the network inside M= PLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to= protect the LSP that carries it. 

If the PW is a multi-segment PW, then LSP recovery can only pro= tect the PW in individual segments.  This means that a single LSP recov= ery action cannot protect against a failure of a PW switching point (an S-PE= ).

When protecting against a= n AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provid= e means for the PEs to coordinate over which LSP the traffic of the PW is ca= rried.

I also doubt why the= re is a need for additional mechanism.

Best regards,

Nu= rit

 =

From: pwe3-bounces@ietf.org [mailto:pwe3-b= ounces@ietf.org] On Behalf Of ext Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 PM
To: ma.yuxia@zte.com.cn
Cc:<= /b> mpls@ietf.org; pwe3@ietf.org
Subject: Re: [PWE3] [mpls] Seekin= g feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW"= ;

 

Dear Ma and all,

Adding the PWE3 WG to my response.

<= p class=3DMsoNormal> 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4= 97D'>The PW redundancy mechanism supports linear protection of MS-PWs as one= of many additional application use cases:

Appendix A of the PW redundancy Bit draft describes 5 application uses cases in addition to MS-PW with single-homed= CEs (which is listed there as use case 5).

And it is equally applicable to IP/MPLS and MPLS - with the= help of  the Static PW Status Messages draft( i= f, for whatever reason, you do not want  to, or cannot, use RFC 4447).

 

Hence I doubt the need for yet another PW redundanc= y  mechanism with narrow scope of applicability.

<= p class=3DMsoNormal> 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4= 97D'>Regards,

  &n= bsp;  Sasha

 =

From: mpls-bounces@ietf= .org [mailto:mpls-bounces@ietf.org] On Behalf Of ma.yuxia@zte.com.cn<= br>Sent: Monday, June 13, 2011 3:25 PM
To: mpls@ietf.orgSubject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Pro= tection Applicability to MS-PW"

 

Hi a= ll,

The linear protection mechanis= m for LSP and PW(including MS-PW) should be the same and it is valuable to d= escribe it clearly.

BTW, there is a typo, it is "T-PE Z" inst= ead of "T-PE B".

 &quo= t; =
  Figure 1 illustrates such a scenario, where two MS-PWs are=
 = ; established between T-PE A and T-PE B, o= ver S-PEs 1-2 and 3-4
  respectively. Each PW segment is established o= ver an LSP (e.g. PW-
  s12 over LSP12).
 "

-----Original Message-----
From= : Daniel Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject= : Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability t= o MS-PW"
Importance: High

Hi MPLSers,

I uploaded "= ;MPLS-TP Linear Protection Applicability to MS-PW" I-D
(http://tools= .ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)

The abstract goes= :

One of the requirements of the MPLS t= ransport profile [RFC 5654] is
to provide linear protection for transport= paths, which include both
LSPs and PWs. The functional architecture desc= ribed in [SurvivFwk]
is applicable to both LSP and PWs, however [LinearPr= ot] does not
explicitly describe mechanisms for PW protection in MPLS-TP.=

This document extends the applicabilit= y of the linear protection
mechanism described in [LinearProt] to MPLS-TP= segmented PWs
(MS-PWs) as defined in [RFC 6073].

Could you pleas= e review it and send feedback to the mailing list or
directly to the auth= or?

Looking forward to your feedback,

Daniel

This e-mail message is intended for the recipient only and c= ontains information which is CONFIDENTIAL and which may be proprietary to EC= I Telecom. If you have received this transmission in error, please inform us= by e-mail, phone or fax, and then delete the original and all copies thereo= f.

This e-mail message is intended for the recipient= only and contains information which is CONFIDENTIAL and which may be propri= etary to ECI Telecom. If you have received this transmission in error, pleas= e inform us by e-mail, phone or fax, and then delete the original and all co= pies thereof.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76E9BDCA9D92ILPTMAIL02eci_-- From matthew.bocci@alcatel-lucent.com Tue Jun 14 06:40:15 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3EE9E8006 for ; Tue, 14 Jun 2011 06:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtMsUdBJwEct for ; Tue, 14 Jun 2011 06:40:14 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 285A89E8004 for ; Tue, 14 Jun 2011 06:40:13 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5EDdne4011576 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 14 Jun 2011 15:40:09 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 14 Jun 2011 15:40:03 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Tue, 14 Jun 2011 15:40:01 +0200 Thread-Topic: Poll for WG adoption of draft-raza-pwe3-pw-typed-wc-fec-01.txt Thread-Index: AcwqmJBWb2BHTooNS0a4gZnddl6Lng== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA1D2341110CFmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [PWE3] Poll for WG adoption of draft-raza-pwe3-pw-typed-wc-fec-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 13:40:15 -0000 --_000_CA1D2341110CFmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The authors of draft-raza-pwe3-pw-typed-wc-fec-01 have requested that this = draft be adopted by the PWE3 working group. This email begins a two week poll of the list to help judge the consensus f= or this. Please send any comments to the PWE3 list by Tuesday 16th June 2011. Regards, Matthew and Andy --_000_CA1D2341110CFmatthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The authors of draf= t-raza-pwe3-pw-typed-wc-fec-01 have requested that this draft be adopted by= the PWE3 working group.

This email begins a two w= eek poll of the list to help judge the consensus for this.

Please send any comments to the PWE3 list by Tuesday 16th June 201= 1.

Regards,

Matthew and A= ndy

--_000_CA1D2341110CFmatthewboccialcatellucentcom_-- From rrahman@cisco.com Tue Jun 14 08:10:26 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AC911E808D for ; Tue, 14 Jun 2011 08:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2Xeiw8qhSdD for ; Tue, 14 Jun 2011 08:10:24 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6B17611E80AD for ; Tue, 14 Jun 2011 08:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rrahman@cisco.com; l=5573; q=dns/txt; s=iport; t=1308064224; x=1309273824; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=g84xyzfG2QaXg2VV55r4ykyclq03CgXkeLNsfVoLsvE=; b=WIBmsQdjxjz5ep2RqgCgNL5lHSS3Yilqr34FvttIk4qlWa/FFU82TDd2 KSS/ADwOackO7zzh63FNYvCHsL9fL96S8d8yGDKNqGkCe9XTgXg3k8rsI uOmYXlqDn0k1qt+gjWwfwm97J9lh7ruJl4mAHATI2v9qQLdKCd/uiT2V+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBAMx4902tJV2Y/2dsb2JhbABSglGUe451d6tDnkaGJASHFY8TiyU X-IronPort-AV: E=Sophos;i="4.65,365,1304294400"; d="scan'208,217";a="336723541" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2011 15:10:23 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5EFANYO022102; Tue, 14 Jun 2011 15:10:23 GMT Received: from xmb-rcd-204.cisco.com ([72.163.62.211]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 10:10:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2AA5.2EC12EAF" Date: Tue, 14 Jun 2011 10:10:22 -0500 Message-ID: <654701C60BCC7C4EBD533B89D72BDFEA04D6144B@XMB-RCD-204.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Poll for WG adoption ofdraft-raza-pwe3-pw-typed-wc-fec-01.txt Thread-Index: AcwqmJBWb2BHTooNS0a4gZnddl6LngADFNvQ References: From: "Reshad Rahman (rrahman)" To: "Bocci, Matthew (Matthew)" , X-OriginalArrivalTime: 14 Jun 2011 15:10:23.0303 (UTC) FILETIME=[2EFA5570:01CC2AA5] Subject: Re: [PWE3] Poll for WG adoption ofdraft-raza-pwe3-pw-typed-wc-fec-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:10:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2AA5.2EC12EAF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Support. =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Tuesday, June 14, 2011 9:40 AM To: pwe3@ietf.org Subject: [PWE3] Poll for WG adoption ofdraft-raza-pwe3-pw-typed-wc-fec-01.txt =20 The authors of draft-raza-pwe3-pw-typed-wc-fec-01 have requested that this draft be adopted by the PWE3 working group. =20 This email begins a two week poll of the list to help judge the consensus for this. =20 Please send any comments to the PWE3 list by Tuesday 16th June 2011. =20 Regards, =20 Matthew and Andy =20 ------_=_NextPart_001_01CC2AA5.2EC12EAF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Support.

 

From:= pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = Bocci, Matthew (Matthew)
Sent: Tuesday, June 14, 2011 9:40 AM
To: pwe3@ietf.org
Subject: [PWE3] Poll for WG adoption ofdraft-raza-pwe3-pw-typed-wc-fec-01.txt

 

The authors of draft-raza-pwe3-pw-typed-wc-fec-01 have requested that this draft be adopted by the PWE3 working = group.

 

This email begins a two week poll of the list to help judge = the consensus for this.

 

Please send any comments to the PWE3 list by Tuesday 16th = June 2011.

 

Regards,

 

Matthew and Andy

 

------_=_NextPart_001_01CC2AA5.2EC12EAF-- From matthew.bocci@alcatel-lucent.com Tue Jun 14 10:08:27 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65ABB11E8096 for ; Tue, 14 Jun 2011 10:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svbtB5hYuGha for ; Tue, 14 Jun 2011 10:08:26 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id BF8AA11E8078 for ; Tue, 14 Jun 2011 10:08:25 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5EH8ORQ001028 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 14 Jun 2011 19:08:24 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 14 Jun 2011 19:08:24 +0200 From: "Bocci, Matthew (Matthew)" To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Tue, 14 Jun 2011 19:08:21 +0200 Thread-Topic: [PWE3] Poll for WG adoption of draft-raza-pwe3-pw-typed-wc-fec-01.txt Thread-Index: Acwqtate8tWwp9qWQhqnkvuZN3QUIg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA1D53E9111F3matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [PWE3] Poll for WG adoption of draft-raza-pwe3-pw-typed-wc-fec-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 17:08:27 -0000 --_000_CA1D53E9111F3matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This should read Tuesday June 28th for the closing date. Sorry for any confusion. Matthew On 14/06/2011 14:40, "Bocci, Matthew (Matthew)" > wrote: The authors of draft-raza-pwe3-pw-typed-wc-fec-01 have requested that this = draft be adopted by the PWE3 working group. This email begins a two week poll of the list to help judge the consensus f= or this. Please send any comments to the PWE3 list by Tuesday 16th June 2011. Regards, Matthew and Andy --_000_CA1D53E9111F3matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,

This should read Tuesday June 28th for the closing date.
=
Sorry for any confusion.

Matthew

On 14/06/2011= 14:40, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com> wrote:
=

The authors of draft-raza-pwe3-pw-typed-w= c-fec-01 have requested that this draft be adopted by the PWE3 working grou= p.

This email begins a two week poll of the list t= o help judge the consensus for this.

Please send a= ny comments to the PWE3 list by Tuesday 16th June 2011.

Regards,

Matthew and Andy

 --_000_CA1D53E9111F3matthewboccialcatellucentcom_-- From erosen@cisco.com Tue Jun 14 08:38:52 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F92111E8169 for ; Tue, 14 Jun 2011 08:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-zlnpiPswie for ; Tue, 14 Jun 2011 08:38:51 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C5CE311E815F for ; Tue, 14 Jun 2011 08:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=14; q=dns/txt; s=iport; t=1308065931; x=1309275531; h=to:cc:subject:date:message-id:from; bh=2FsnakxMV7EU5XeQfUfK7Zrk/wlXXgULKSQ+mdo5Ta4=; b=XR2/Q8/U0gcBF1UHpYXrzFHKF0Aqw5/lNXfv/jORCzhgxLdupO5M9Ab3 Ojp/OCHFDptn2jY5Ct4nwGWWs6UePn6OnhJ6EESb6Rs6UaeheSDQEvn0U Ug88bb+cSLOKitOWbmLDO33uP8/4Z/DW2SojhkDgbOSeYsWQgeKmTcZdN o=; X-IronPort-AV: E=Sophos;i="4.65,365,1304294400"; d="scan'208";a="336745617" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2011 15:38:51 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5EFcoF0017576; Tue, 14 Jun 2011 15:38:51 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p5EFcoAp001816; Tue, 14 Jun 2011 11:38:50 -0400 To: "Bocci, Matthew (Matthew)" Comments: In-reply-to "Bocci, Matthew (Matthew)" message dated "Tue, 14 Jun 2011 15:40:01 +0200." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Tue, 14 Jun 2011 11:38:50 -0400 Message-ID: <1815.1308065930@erosen-linux> From: Eric Rosen X-Mailman-Approved-At: Wed, 15 Jun 2011 08:05:11 -0700 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Poll for WG adoption of draft-raza-pwe3-pw-typed-wc-fec-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:38:52 -0000 Yes/support. From zali@cisco.com Tue Jun 14 19:59:58 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3D111E8099 for ; Tue, 14 Jun 2011 19:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjhHKsxz72aE for ; Tue, 14 Jun 2011 19:59:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 829EC11E8093 for ; Tue, 14 Jun 2011 19:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=5526; q=dns/txt; s=iport; t=1308106797; x=1309316397; h=mime-version:subject:date:message-id:from:to; bh=WSnKXan9cDqyxDvQRH/ZGkyrvc/IKd9QHL5asHqVhd4=; b=R5Bao0p8c1FxBM3NJfjt6aDqQxHmb7gkoytguwrq/EBYvdanVsQKIu46 cyHHxymZpmAKWnxH4YhlYd5WV5MHjjUe56VAnHIRg+fbL00AHIAOX+b+L 7Xe4S8E/F4t05YZ7IJs2g+4V2NPw2hVM2L+fOEMgDs8Sfob8KUo3ZYTLZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAP0e+E2tJXG//2dsb2JhbABSglGkAHepSp5BhiYEhxWPFosq X-IronPort-AV: E=Sophos;i="4.65,368,1304294400"; d="scan'208,217";a="713619893" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-6.cisco.com with ESMTP; 15 Jun 2011 02:59:55 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5F2xtoR000394; Wed, 15 Jun 2011 02:59:55 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 21:59:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2B08.4DCA2A80" Date: Tue, 14 Jun 2011 21:59:53 -0500 Message-ID: <7CC717E2F49DAA4A827DA3FEA237111B0525ACB4@XMB-RCD-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Poll for WG adoption of draft-raza-pwe3-pw-typed-wc-fec-01.txt thread-index: AcwrCEy6g/T86teITJacP1iN4HlWuw== From: "Zafar Ali (zali)" To: , X-OriginalArrivalTime: 15 Jun 2011 02:59:55.0019 (UTC) FILETIME=[4DB2ADB0:01CC2B08] X-Mailman-Approved-At: Wed, 15 Jun 2011 08:05:11 -0700 Subject: [PWE3] Poll for WG adoption of draft-raza-pwe3-pw-typed-wc-fec-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 02:59:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2B08.4DCA2A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support.=20 =20 Thanks =20 Regards ... Zafar=20 =20 From: "Bocci, Matthew (Matthew)" Date: Tue, 14 Jun 2011 15:40:01 +0200 To: "pwe3@ietf.org" Subject: [PWE3] Poll for WG adoption of draft-raza-pwe3-pw-typed-wc-fec-01.txt The authors of draft-raza-pwe3-pw-typed-wc-fec-01 have requested that this draft be adopted by the PWE3 working group. This email begins a two week poll of the list to help judge the consensus for this. Please send any comments to the PWE3 list by Tuesday 16th June 2011. Regards, Matthew and Andy ________________________________ _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 =20 ------_=_NextPart_001_01CC2B08.4DCA2A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Thanks

 

Regards ... Zafar

 

From: "Bocci, Matthew = (Matthew)" <matthew.bocci@alcatel-lucent.co= m>
Date: Tue, 14 Jun 2011 15:40:01 +0200
To: "pwe3@ietf.org" = <pwe3@ietf.org>
Subject: [PWE3] Poll for WG adoption of draft-raza-pwe3-pw-typed-wc-fec-01.txt

The authors of draft-raza-pwe3-pw-typed-wc-fec-01 have requested that = this draft be adopted by the PWE3 working group.

This email begins a two week poll of the list to help judge the = consensus for this.

Please send any comments to the PWE3 list by Tuesday 16th June 2011.

Regards,

Matthew and Andy

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

 

------_=_NextPart_001_01CC2B08.4DCA2A80-- From hejia@huawei.com Wed Jun 15 13:30:29 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C40621F862A for ; Wed, 15 Jun 2011 13:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAalolh7V5K9 for ; Wed, 15 Jun 2011 13:30:28 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF2621F8619 for ; Wed, 15 Jun 2011 13:30:28 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMU008OWMAPMP@szxga03-in.huawei.com> for pwe3@ietf.org; Thu, 16 Jun 2011 04:30:25 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMU00BRCMAPQG@szxga03-in.huawei.com> for pwe3@ietf.org; Thu, 16 Jun 2011 04:30:25 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 16 Jun 2011 04:30:17 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.8.3]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Thu, 16 Jun 2011 04:30:24 +0800 Date: Wed, 15 Jun 2011 20:30:02 +0000 From: Hejia In-reply-to: X-Originating-IP: [172.24.2.40] To: Alexander Vainshtein , David Allan I Message-id: <735916399E11684EAF4EB4FB376B7195AA3765@SZXEML504-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Thread-index: AQHMJ3T5akGt/gwupE2rCyvdMNhpMZS+0PFN X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <60C093A41B5E45409A19D42CF7786DFD521B518CF3@EUSAACMS0703.eamcs.ericsson.se> Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 20:30:29 -0000 Hi Dave and Sasha, In fact, RFC5586 places no restrictions on the usage of GAL with PWs in MPL= S environment but states that GAL MUST NOT be used with PWs in MPLS-TP envi= ronment.=20 draft-ietf-pwe3-mpls-tp-gal-in-pw is created to remove the restrictions pla= ced on GAL usage with PWs in MPLS-TP environment. B.R. Jia ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Alexander = Vainshtein [Alexander.Vainshtein@ecitele.com] Sent: Friday, June 10, 2011 9:46 PM To: David Allan I; pwe3@ietf.org Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Hi all, I concur with Dave. Regards, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of David Alla= n I [david.i.allan@ericsson.com] Sent: Friday, June 10, 2011 1:43 AM To: pwe3@ietf.org Subject: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt I'm opposed to this draft progressing at this time. At the moment the PW with a CW is a unifying agent that will work in both T= P domains and those that employ ECMP and LAG. The GAL/ACh version cannot ma= ke this claim. What would be required to make this acceptable IMO would be agreement with = the MPLS WG to produce an RFC that documented excluding reserved labels fro= m ECMP consideration such that GAL/GACh encapsulated PW OAM had "feature pa= rity" with ACh encapsulated PW-OAM=85 Then we could reasonably consider taking steps to move to a common OAM enca= psulation mechanism common to LSPs and PWs. My 2 cents Dave This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3= From matthew.bocci@alcatel-lucent.com Thu Jun 16 03:13:33 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18D11E81F5 for ; Thu, 16 Jun 2011 03:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXmRTsDs0HE9 for ; Thu, 16 Jun 2011 03:13:33 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6C11E809C for ; Thu, 16 Jun 2011 03:13:30 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5GA2KJq013533 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Jun 2011 12:13:27 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 16 Jun 2011 12:12:57 +0200 From: "Bocci, Matthew (Matthew)" To: "draft-ietf-pwe3-mpls-eth-oam-iwk@tools.ietf.org" Date: Thu, 16 Jun 2011 12:12:43 +0200 Thread-Topic: Doc Shepherd's review of draft-ietf-pwe3-eth-oam-iwk-04 Thread-Index: AcwsDfZ8k/Ti5QBpR4+7J4aeRjGlfA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA1F95AB114E9matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "pwe3@ietf.org" Subject: [PWE3] Doc Shepherd's review of draft-ietf-pwe3-eth-oam-iwk-04 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 10:13:33 -0000 --_000_CA1F95AB114E9matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, I am the document shepherd for draft-ietf-pwe3-mpls-eth-oam-iwk-04. I have = the reviewed the draft, and have some comments, prefixed by **Matthew>, bel= ow. In general the draft is well written, but I would appreciate if you could a= ddress the comments below and also those from Yaakov Stein in a new revisio= n of the draft prior to progressing this to AD review. Best regards, Matthew Internet-Draft D. Mohan (Editor), Nortel PWE3 Working Group N. Bitar (Editor), Verizon Intended status: Standards Track P. Niger, France Telecom Date Created: March 02, 2011 S. Delord, Telstra Expiration Date: September 02, 2011 A. Sajassi (Editor), Cisco R. Qiu, Huawei MPLS and Ethernet OAM Interworking draft-ietf-pwe3-mpls-eth-oam-iwk-04.txt Abstract This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet Pseudowires (PWs) connected in accordance to the PWE3 architecture [RFC3985] to realize an end-to-end emulated Ethernet service. This document augments the mapping of defect states between a PW and associated AC of the end-to-end emulated service in [PW-OAM-MSG- MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack of Ethernet OAM maturity. However, since then, [Y.1731] and [802.1ag] have been completed, and this document specifies the mapping of defect states between Ethernet ACs and corresponding Ethernet PWs. **Matthew> The history is not required in the RFC. I suggest removing the 2nd half of the penultimate sentence and the last sentence. Also, please remove any references in the abstract, e.g. [RFC3985]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in September 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Mohan, et. al. Expires: September 2011 [Page 1] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. Table of Contents Status of this Memo................................................1 Conventions used in this document..................................2 1. Introduction....................................................3 1.1. Reference Model and Defect Locations..........................4 1.2. Abstract Defect States........................................4 2. Terminology.....................................................6 3. PW Status and Defects...........................................6 3.1 Use of Native Service notification.............................6 3.2 Use of PW Status notification for MPLS PSNs....................7 3.3 Use of BFD Diagnostic Codes....................................7 4. Ethernet AC Defect States Entry or Exit Criteria................8 4.1 AC Receive Defect State Entry or Exit..........................8 4.2 AC Transmit Defect State Entry or Exit.........................8 5. Ethernet AC and PW Defect States Interworking...................9 5.1 PW Receive Defect Entry Procedures.............................9 5.2 PW Receive Defect Exit Procedures.............................10 5.3 PW Transmit Defect Entry Procedures...........................11 5.4 PW Transmit Defect Exit Procedures............................11 5.5 AC Receive Defect Entry Procedures............................12 5.6 AC Receive Defect Exit Procedures.............................12 5.7 AC Transmit Defect Entry Procedures...........................12 5.8 AC Transmit Defect Exit Procedures............................13 6. Acknowledgments................................................13 7. IANA Considerations............................................13 8. Security Considerations........................................13 9. References.....................................................13 9.1 Normative References..........................................13 9.2 Informative References........................................14 Appendix A: Ethernet Native Service Management....................14 Intellectual Property Statement...................................15 Authors' Addresses................................................16 Mohan, et. al. Expires: September 2011 [Page 2] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 1. Introduction This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet Pseudowires (PWs) connected in accordance to the PWE3 architecture [RFC3985] to realize an end-to-end emulated Ethernet service. This document augments the mapping of defect states between a PW and associated AC of the end-to-end emulated service in [PW-OAM-MSG- MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack of Ethernet OAM maturity. However, since then, [Y.1731] and [802.1ag] have been completed, and this document specifies the mapping of defect states between Ethernet ACs and corresponding Ethernet PWs. **Matthew> See comment above about the document history. **Matthew> For the sake of clarity, the authors might want to call out the Ethernet OAM mechanisms covered by this document as a bulleted list, along with references. Ethernet Link OAM [802.3] allows some Link defect states to be detected and communicated across an Ethernet Link. When an Ethernet AC is an Ethernet PHY, there may be some application of Ethernet Link OAM [802.3]. Further, E-LMI [MEF16] also allows for some EVC defect states to be communicated across an Ethernet UNI where Ethernet UNI constitutes a single hop Ethernet Link (i.e. without any 802.1Q/.1ad compliant bridges in between). There may be some application of E-LMI [MEF16] for failure notification across single hop Ethernet AC in certain deployments that specifically do not support [802.1ag] and/or [Y.1731]. [Y.1731] and [802.1ag] based mechanisms are applicable in all types of Ethernet ACs. Link OAM [802.3] and E-LMI [MEF16] are optional and their applicability is called out, where applicable. Native Service (NS) OAM may be transported transparently over the corresponding PW as user data. For Ethernet, as an example, 802.1ag continuity check messages (CCMs) between two Maintenance End Points (MEPs) can be transported transparently as user data over the corresponding PW. At MEP locations, service failure is detected when a number of consecutive CCMs are missed. **Matthew> It might be worth clarifying that various CCM defect conditions may be raised, including a timeout condition that is detected after 3.5times the local CCM interval. MEP locations can be the PE, the CE or both with different Maintenance Domain Levels. **Matthew> I think this might be clearer if you rephrase this as: "MEP peers can exist between CE pairs (MEP of a given MEG reside on the CEs), PE pairs (the MEPs of a given MEG reside on the PEs), or even peering between the CE-PE (the MEPs of a given MEG reside on the PE and CE), as long as the domain nesting rules are maintained." However, when interworking two networking domains, such as native Ethernet and PWs to provide an end-to-end emulated service, there is need to identify the failure domain and location even when a PE supports both the NS OAM mechanisms and the PW OAM mechanisms. In addition, scalability constraints may not allow running proactive monitoring, such as CCMs with transmission on, at a PE to detect the failure of an Ethernet Virtual circuit (EVC) across the PW domain. Thus, network driven alarms generated upon failure detection in the NS or PW domain and their mappings to the other domain are needed. There are also cases where a PE may not be able to process NS OAM messages received on the PW even when such messages are defined, as in Ethernet case, necessitating the need for fault notification message mapping between the PW domain and the Client domain. For Multi-Segment PWs (MS-PWs) [RFC5659], Switching PEs (S-PEs) are not aware of the NS. Thus failure detection and notification at S-PEs will be based on PW OAM mechanisms. Mapping between PW OAM and Mohan, et. al. Expires: September [Page 3] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 NS OAM will be required at the Terminating PEs (T-PEs) to propagate the failure notification to the EVC endpoints. Similar to [PW-OAM-MSG-MAP], the intent of this document is to standardize the behavior of PEs with respect to failures on Ethernet ACs and PWs, so that there is no ambiguity about the alarms generated and consequent actions undertaken by PEs in response to specific failure conditions. 1.1. Reference Model and Defect Locations Figure 1 is the same as used in [PW-OAM-MSG-MAP] and is reproduced in this document as a reference to highlight defect locations. ACs PSN tunnel ACs +----+ +----+ +----+ | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D| PE2| +----+ | |---(a)---(b)..(c)......PW1..(d)..(c)..(f)---(e)---| | | CE1| (N1) | | | | (N2) |CE2 | | |----------|............PW2.............|----------| | +----+ | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D| | +----+ ^ +----+ +----+ ^ | Provider Edge 1 Provider Edge 2 | | | |<-------------- Emulated Service ---------------->| Customer Customer Edge 1 Edge 2 Figure 1: PWE3 Network Defect Locations **Matthew> I think that the reference architecture for Ethernet is more complicated than this model, which served us well for other technologies. Can you illustrate where the NTE is? I think this is important because it impacts how service provider and customer MEGs are overlaid on this, and where the MEPs reside. It would also be worth illustrating in a figure how these MEGs are overlaid. Customer Customer Edge 1 Edge 2 1.2. Abstract Defect States Abstract Defect States are also introduced in [PW-OAM-MSG-MAP]. This document uses the same conventions, as shown in Figure 2 from [PW- OAM-MSG-MAP]. It may be noted however that CE devices, shown in Figure 2, do not necessarily have to be end customer devices; these are essentially devices in client network segments that are connecting to PSN network for the emulated services. +-----+ ----AC receive ----->| |-----PW transmit----> CE1 | PE1 | PE2/CE2 <---AC transmit------| |<----PW receive----- +-----+ (arrows indicate direction of user traffic impacted by a defect) Figure 2: Transmit and Receive Defect States and Notifications **Matthew> For the 1731/802.1ag case, can you show the possible MEP locations on a similar diagram? You should also call out the case where there are no SP MEPs on the PEs, in which case any faults in the PW would be detected by the PEs but not mapped to any Ethernet indications on the ACs. It would be up to CCM between the CEs (of NTEs) to detect a failure. Here is an example of the kind of diagram I am referring to, for the case of a simple AC failure. Of course, feel free To make a proposal: +-------+ | |----PW transmit----> CE1 =3D=3D=3DNID=3D=3DAC=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| PE1 | = PE2/CE2 | |<----PW receive----- +-------+ MEP=3DL2<----->MEP=3DL2 UP|DOwn DOWN MEP=3DL4----------------NID to NID-----------------MEP=3DL4 UP UP MEP=3DL6------------------Customer Domain-----------------------MEP=3DL6 Mohan, et. al. Expires: September 2011 [Page 4] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 PE1 may detect a receive defect in local Ethernet AC via one of the following mechanisms: - An AIS alarm generated at an upstream node in the client domain (CE1 in Figure 2) and received by a local MEP associated with the local AC. - Failure of the local link on which the AC is configured. Link failure may be detected via physical failures (e.g., loss of signal (LoS)), or via Ethernet Link OAM [802.3] critical link event notifications generated at an upstream node CE1 with "Dying Gasp" or "Critical Event" indication. - Failure to receive CCMs on the AC if a local MEP is configured for the AC. - A CCM from CE1 with interface status TLV indicating interface down. Other CCM interface status TLVs will not be used to indicate failure or recovery from failure. **Matthew> Given the above suggestion to show the possible MEGs on the reference architecture, you should rephrase these sections and following similar sections through out the draft. Also, you seem to be limiting this to interface up/down events on the AC. I think you could also account for any MAC status defect that affects the overall MAC defect state. AC receive defect at PE1 impacts the ability of PE1 to receive user traffic from the Client domain attached to PE1 via that AC. Similarly, PE1 may detect a receive defect in the PW via one of the following mechanisms: - Forward Defect indication received from PE2. This defect indication could point to problems associated with PE2's inability to transmit traffic on the PW or PE2's inability to receive traffic on its local AC. - Unavailability of a PSN path in the PW domain to PE2. PW forward defect indication received on PE1 impacts the ability of PE1 to receive traffic on the PW. PE1 may be notified of an AC transmit defect via one of the following mechanisms: - CCMs with RDI (Remote Defect Indication) bit set. - In case when the AC is associated with a physical port, failure of the local link on which the AC is configured (e.g., LOS or via Ethernet Link OAM [802.3] critical link event notifications generated at an upstream node CE1 with "Link Fault" indication). AC transmit defect impacts the ability of PE1 to send user traffic on the local AC. Similarly, PE1 may be notified of a PW transmit defect via Reverse Defect indication from PE2, which could point to problems associated with PE2's inability to receive traffic on the PW or PE2's inability to transmit traffic on its local AC. PW transmit defect impacts PE1 ability to send user traffic toward CE2. The procedures outlined in this document define the entry and exit criteria for each of the four defect states with respect to Ethernet ACs and corresponding PWs, and the consequent actions that PE1 must support to properly interwork these defect states and corresponding notification messages between the PW domain and the Native Service (NS) domain. Receive Defect state should have precedence over Transmit Defect state in terms of handling, when both transmit and Mohan, et. al. Expires: September 2011 [Page 5] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 receive defect states are identified simultaneously. 2. Terminology This document uses the following terms: AIS Alarm Indication Signal MD Level Maintenance Domain (MD) Level which identifies a value in the range of 0-7 associated with Ethernet OAM frame. MD Level identifies the span of the Ethernet OAM frame. MEP Maintenance End Point is responsible for origination and termination of OAM frames for a given MEG MIP Maintenance Intermediate Point is located between peer MEPs and can process OAM frames but does not initiate or terminate them RDI Remote Defect Indication Further, this document also uses the terminology and conventions used in [PW-OAM-MSG-MAP]. 3. PW Status and Defects [PW-OAM-MSG-MAP] introduces a range of defects that impact PW status. All these defect conditions are applicable for Ethernet PWs. Similarly, there are different mechanisms described in [PW-OAM-MSG- MAP] to detect PW defects, depending on the PSN type (e.g. MPLS PSN, MPLS-IP PSN). Any of these mechanisms can be used when monitoring the state of Ethernet PWs. [PW-OAM-MSG-MAP] also discusses the applicability of these failure detection mechanisms. 3.1 Use of Native Service (NS) notification There is no NS fault notification capability currently specified for Ethernet PWs. However, with the completion of Ethernet OAM work, this capability should be added. This includes the ability to create a MEP associated with the Ethernet PW on the PE. The native service notification options include: **Matthew> The above text seems out of date, since this draft addresses many Ethernet fault notification mechanisms. - AIS Frames sent by the local MEP to the MEP on the remote PE when the MEP needs to convey PE receive defects, and when CCM transmission is configured not to be turned ON. - Suspension of CCM frames transmission from the MEP to the peer MEP on the other PE to convey PE receive defects, when CCM transmission is configured to be turned ON. - RDI bit set in transmitted CCM frames, when loss of CCMs from the peer MEP is detected or PE needs to convey PW reverse defects. These NS OAM notifications are inserted into the corresponding PW. Similarly, when the defect conditions are cleared, a PE can take one of the following actions, depending on the mechanism that was used for failure notification, to clear the defect sate on the peer PE: Mohan, et. al. Expires: September 2011 [Page 6] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 - Stop AIS Frame transmission from the local MEP to the MEP on the remote PE to clear PW receive defects; - Resuming CCM frames transmission from the MEP to the peer MEP to clear PW forward defects notification, when CCM transmission is configured to be turned ON. - Clearing RDI indication in transmitted CCM frames, to clear PW transmit defects notification. **Matthew> Is there any impact of Y.1731 CSF? Is that in scope of this draft or will it be addressed separately? 3.2 Use of PW Status notification for MPLS PSNs When PWs are established using LDP, LDP status notification signaling SHOULD be used as the default mechanism to signal AC and PW status and defects [RFC4447]. For PWs established over an MPLS or MPLS-IP PSN using other mechanisms (e.g. static configuration), inband signaling using VCCV-BFD [RFC5885] SHOULD be used to convey AC and PW status and defects. **Matthew> The use of MUST and SHOULD above conflicts with the OAM message mapping draft. I suggest you align with that draft. [PW-OAM-MSG-MAP] identifies the following PW defect status codepoints: - Forward defect: corresponds to a logical OR of local AC (ingress) Receive fault, local PSN-facing PW (egress) transmit fault, and PW not forwarding fault. - Reverse defect: corresponds to a logical OR of local AC (egress) transmit fault and local PW PSN-facing (ingress) receive fault. There are also scenarios where a PE carries out PW label withdrawal instead of PW status notification. These include administrative disablement of the PW or loss of Target LDP session with the peer PE. 3.3 Use of BFD Diagnostic Codes When using VCCV, the control channel (CC) type and Connectivity Verification (CV) Type are agreed on between the peer PEs using the OAM capability sub-TLV signaled as part of the interface parameter TLV when using FEC 129 and the interface parameter sub-TLV when using FEC 128. As defined in [PW-OAM-MSG-MAP], when CV type of 0x04 0r 0x1 is used to indicate that BFD is used for PW fault detection only, PW defect is detected via the BFD session while other defects, such as AC detected or PE internal defects preventing it from forwarding traffic, are communicated via LDP Status notification message in MPLS and MPLS-IP PSN or other mechanisms in L2TP-IP PSN. Similarly, when CV type of 0x08 or 0x20 is used to indicate that BFD is used for both PW fault detection and AC/PW Fault Notification, all defects are signaled via BFD. Mohan, et. al. Expires: September 2011 [Page 7] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 4. Ethernet AC Defect States Entry or Exit Criteria 4.1 AC Receive Defect State Entry or Exit PE1 enters the AC Receive Defect state if any of the following conditions are met: - It detects or is notified of a physical layer fault on the Ethernet interface. Ethernet link failure can be detected based on loss of signal (LoS) or via Ethernet Link OAM [802.3] critical link event notifications generated at an upstream node CE1 with "Dying Gasp" or "Critical Event" indication. - A MEP associated with the local AC receives an Ethernet AIS frame. - A MEP associated with the local AC does not receive CCM frames from the peer MEP in the client domain (e.g. CE1) within a configurable interval equal to a multiple (e.g. 3.5) of the CCM transmission period configured for the MEP. This is the case when CCM transmission is configured to be turned ON. **Matthew> I don;t think the interval is configurable, but the transmission period is. So the text above should read: "A MEP associated with the local AC does not receive CCM frames from the peer MEP in the client domain (e.g. CE1) within an interval equal to a multiple (e.g. 3.5) of the CCM transmission period configured for the MEP." - A CCM with interface status TLV indicating interface down. Other CCM interface status TLVs will not be used to indicate failure or recovery from failure. PE1 exits the AC Receive Defect state if all of the conditions that resulted in entering the defect state are cleared. This includes all of the following conditions: - Any physical layer fault on the Ethernet interface, if detected or notified previously, iss removed (e.g. via loss of signal (LoS), or Ethernet Link OAM [802.3] critical link event notifications with "Dying Gasp" or "Critical Event" indication cleared at an upstream node CE1). - A MEP associated with the local AC does not receive any Ethernet AIS frame within a period indicated by previously received AIS, if AIS was resulted in entering the defect state. - A MEP associated with the local AC and configured with CCM transmission on receives a configured number (e.g. 3 or more) of consecutive CCM frames from the peer MEP on CE1 within an interval equal to a multiple (e.g. 3.5) of the CCM transmission period configured for the MEP. - CCM indicates interface status up. 4.2 AC Transmit Defect State Entry or Exit PE1 enters the AC Transmit Defect state if any of the following conditions is met: - It detects or is notified of a physical layer fault on the Ethernet interface (e.g. via loss of signal (LoS) or Ethernet Link OAM [802.3] critical link event notifications generated at an upstream node CE1 with "Link Fault" indication). - A MEP configured with CCM transmission turned ON and associated with the local AC receives a CCM frame, with its RDI bit set, from peer MEP in the client domain (e.g. CE1). Mohan, et. al. Expires: September 2011 [Page 8] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 PE1 exits the AC Transmit Defect state if all of the conditions that resulted in entering the defect state are cleared. This includes all of the following conditions: - Any physical layer fault on the Ethernet interface, if detected or notified previously, is removed (e.g. via Ethernet Link OAM [802.3] critical link event notifications with "Link Fault" indication cleared at an upstream node CE1). - A MEP configured with CCM transmission turned ON and associated with the local AC does not receive a CCM frame with RDI bit set, having received a previous CCM frame with RDI bit set from the peer MEP in the client domain (e.g. CE1). 5. Ethernet AC and PW Defect States Interworking 5.1 PW Receive Defect Entry Procedures When the PW status on PE1 transitions from working to PW Receive Defect state, PE1's ability to receive user traffic from CE2 is impacted. As a result, PE1 needs to notify CE1 about this problem. Upon entry to the PW Receive Defect state, the following must be done: - If PE1 is configured with a MEP associated with the local AC and CCM transmission is not configured to be turned ON, the MEP associated with the AC must transmit AIS frames periodically to the MEP in the client domain (e.g. on CE1) based on configured AIS transmission period. **Matthew> Is this an UP MEP pointing away from the AC into the PSN? Please clarify. - If PE1 is configured with a MEP associated with the local AC and CCM transmission is configured to be turned ON, and the MEP associated with the AC is configured to support Interface Status TLV in CCM messages, the MEP associated with the AC must transmit CCM frames with Interface Status TLV as being down to the peer MEP in the client domain (e.g. on CE1). **Matthew> Please clarify if this is a DOWN MEP. - If PE1 is configured with a MEP associated with the local AC and CCM transmission is configured to be turned ON, and the MEP associated with the AC is configured to not support Interface Status TLV in CCM messages, the MEP associated with the AC must stop transmitting CCM frames to the peer MEP in the client domain (e.g. on CE1). **Matthew> Ditto - If PE1 is configured to run E-LMI [MEF16] with CE1 and if E-LMI is used for failure notification, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Not Active. Further, when PE1 enters the Receive Defect state, it must assume that PE2 has no knowledge of the defect and must send reverse defect Mohan, et. al. Expires: September 2011 [Page 9] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 failure notification to PE2. For MPLS PSN or MPLS-IP PSN, this is done via either a PW Status notification message indicating a reverse defect; or via VCCV-BFD diagnostic code of reverse defect if VCCV CV type of 0x08 had been negotiated. When Native Service OAM mechanism is supported on PE, it can also use the NS OAM notification as specified in Section 3.1. If PW receive defect is entered as a result of a forward defect notification from PE2 or via loss of control adjacency, no additional action is needed since PE2 is expected to be aware of the defect. Note: The location of the MEP associated with the local AC within a PE can be a down MEP on the port associated with the AC or an Up MEP associated with an emulated LAN interface within the PE, as defined in L2VPN framework for a VPLS PE. Though for the purposes of VPWS service, VPLS PE architecture is not mandatory, the VPLS PE architecture serves as a generic case where the PE can support both VPWS and VPLS services. **Matthew> I am not sure that fault propagation as described in this draft is applicable to mp-mp services such as VPLS, since there is a many-many relationship between PWs and ACs at a given PE. 5.2 PW Receive Defect Exit Procedures When the PW status transitions from PW Receive Defect state to working, PE1's ability to receive user traffic from CE2 is restored. As a result, PE1 needs to cease defect notification to CE1 by performing the following: - If PE1 is configured with a a MEP associated with the local AC and CCM transmission is not configured to be turned ON, the MEP associated with the AC must stop transmitting AIS frames towards the peer MEP in the client domain (e.g. on CE1). - If PE1 is configured with a MEP associated with the local AC and CCM transmission is configured to be turned ON, and the MEP associated with the AC is configured to support Interface Status TLV in CCM messages, the MEP associated with the AC must transmit CCM frames with Interface Status TLV as being Up to the peer MEP in the client domain (e.g. on CE1). - If PE1 is configured with a MEP associated with the local AC and CCM transmission is configured to be turned ON, and the MEP associated with the AC is configured to not support Interface Status TLV in CCM messages, the MEP associated with the AC must resume transmitting CCM frames to the peer MEP in the client domain (e.g. on CE1). - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is used for fault notification, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Active. Mohan, et. al. Expires: September 2011 [Page 10] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 Further, if the PW receive defect was explicitly detected by PE1, it must now notify PE2 about clearing of Receive Defect state by clearing reverse defect notification. For PWs over MPLS PSN or MPLS- IP PSN, this is either done via PW Status message indicating working; or via VCCV-BFD diagnostic code if VCCV CV type of 0x08/0x20 had been negotiated. When Native Service OAM mechanism is supported on PE, it can also clear the NS OAM notification specified in Section 3.1. If PW receive defect was established via notification from PE2 or via loss of control adjacency, no additional action is needed, since PE2 is expected to be aware of the defect clearing. 5.3 PW Transmit Defect Entry Procedures When the PW status transitions from working to PW Transmit Defect state, PE1's ability to transmit user traffic to CE2 is impacted. As a result, PE1 needs to notify CE1 about this problem which has been detected by PE1. Upon entry to the PW Transmit Defect state, the following must be done: - If PE1 is configured with a MEP associated with the local AC and CCM transmission is configured to be turned ON, the MEP associated with the AC must set the RDI bit in transmitted CCM frames sent to the peer MEP in the client domain (e.g. on CE1). **Matthew> Is it a MUST to set RDI? Or is it a MAY, since you may also use the interface status TLV? - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is used for fault notification, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Not Active. 5.4 PW Transmit Defect Exit Procedures When the PW status transitions from PW Transmit Defect state to working, PE1's ability to transmit user traffic to CE2 is restored. As a result, PE1 needs to cease defect notifications to CE1 and perform the following - If PE1 is configured with a MEP associated with the local AC and CCM transmission is configured to be turned ON, the MEP associated with the AC must clear the RDI bit in the transmitted CCM frames to the peer MEP (e.g. on CE1). - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Active. Mohan, et. al. Expires: September 2011 [Page 11] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 5.5 AC Receive Defect Entry Procedures When AC status transitions from working to AC Receive Defect state, PE1's ability to receive user traffic from CE1 is impacted. As a result, PE1 needs to notify PE2 and CE1 about this problem. If the AC receive defect is detected by PE1, it must notify PE2 in the form of a forward defect notification. When NS OAM is not supported on PE1, and for PW over MPLS PSN or MPLS-IP PSN, forward defect notification is done via either PW Status message indicating a forward defect or via VCCV-BFD diagnostic code of forward defect if VCCV CV type of 0x08/0x20 had been negotiated. When Native Service OAM mechanism is supported on PE1, it can also use the NS OAM notification as specified in Section 3.1. In addition to above actions, PE1 must perform the following: - If PE1 is configured with a MEP associated with the local AC and CCM transmission is configured to be turned ON, the MEP associated with AC must set the RDI bit in transmitted CCM frames. 5.6 AC Receive Defect Exit Procedures When AC status transitions from AC Receive Defect to working, PE1's ability to receive user traffic from CE1 is restored. As a result, PE1 needs to cease defect notifications to PE2 and CE1 and perform the following: - When NS OAM is not supported on PE1 and for PW over MPLS PSN or MPLS-IP PSN, forward defect notification is cleared via PW Status message indicating a working state; or via VCCV-BFD diagnostic code if VCCV CV type of 0x08 or 0x20 had been negotiated. - When Native Service OAM mechanism is supported on PE1, PE1 clears the NS OAM notification as specified in Section 3.1. - If PE1 is configured with a MEP associated with the local AC and CCM transmission is configured to be turned ON, the MEP associated with the AC must clear the RDI bit in transmitted CCM frames to the peer MEP in the client domain (e.g. on CE1). 5.7 AC Transmit Defect Entry Procedures When AC status transitions from working to AC Transmit Defect, PE1's ability to transmit user traffic to CE1 is impacted. As a result, PE1 needs to notify PE2 about this problem. Mohan, et. al. Expires: September 2011 [Page 12] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 If the AC transmit defect is detected by PE1, it must notify PE2 in the form of a reverse defect notification. When NS OAM is not supported on PE, in PW over MPLS PSN or MPLS-IP PSN, reverse defect notification is either done via PW Status message indicating a reverse defect; or via VCCV-BFD diagnostic code of reverse defect if VCCV CV type of 0x08 or 0x20 had been negotiated. When Native Service OAM mechanism is supported on PE, it can also use the NS OAM notification as specified in Section 3.1. 5.8 AC Transmit Defect Exit Procedures When AC status transitions from AC Transmit defect to working, PE1's ability to transmit user traffic to CE1 is restored. As a result, PE1 needs to clear notification to PE2. If the AC Transmit defect is cleared, PE1 must clear reverse defect notification to PE2. When NS OAM is not supported on PE1 and for PW over MPLS PSN or MPLS-IP PSN, reverse defect notification is cleared via either a PW Status message indicating a working state or via VCCV-BFD diagnostic code of if VCCV CV type of 0x08 had been negotiated. When Native Service OAM mechanism is supported on PE1, PE1 can clear NS OAM notification as specified in Section 3.1. 6. Acknowledgments The authors are thankful to Samer Salam for his valuable comments. 7. IANA Considerations This document has no actions for IANA. 8. Security Considerations This document does not impose any security concerns since it makes use of existing OAM mechanisms and mapping of these messages does not change inherent security features. 9. References 9.1 Normative References Mohan, et. al. Expires: September 2011 [Page 13] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 [Y.1731] "OAM Functions and mechanisms for Ethernet based networks", ITU-T Y.1731, May 2006 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag/D8.1, Jul 2007 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, April 2006 [RFC5885] "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC5885, June 2010 [802.3] "CDMA/CD access method and physical layer specifications", Clause 57 for Operations, Administration and Maintenance, 2005 [MEF16] "Ethernet Local Management Interface", MEF16, January 2006 9.2 Informative References [RFC3985] "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005 [PW-OAM-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", draft-ietf- pwe3-oam-msg-map-14.txt, Work in progress, October 2010 [RFC5659] "An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge", RFC5659, October 2009 Appendix A: Ethernet Native Service Management Ethernet OAM mechanisms are broadly classified into two categories: Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731 provides coverage for both FM and PM while IEEE 802.1ag provides coverage for a sub-set of FM functions. Ethernet OAM also introduces the concept of Maintenance Entity (ME) which is used to identify the entity that needs to be managed. A ME is inherently a point-to-point association. However, in case of a multipoint association, Maintenance Entity Group (MEG) consisting of different MEs is used. IEEE 802.1 uses the concept of Maintenance Association (MA) which is used to identify both point-to-point and multipoint associations. Each MA consists of Maintenance End Points (MEPs) which are responsible for originating OAM frames. In between the MEPs, there can also be Maintenance Intermediate Points (MIPs) which do not originate OAM frames however do respond to OAM frames from MEPs. Mohan, et. al. Expires: September 2011 [Page 14] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 Ethernet OAM allows for hierarchical maintenance entities to allow for simultaneous end-to-end and segment monitoring. This is achieved by having a provision of up to 8 Maintenance Domain Levels (MD Levels) where each MEP or MIP is associated with a specific MD Level. It is important to note that the common set of FM mechanisms between IEEE 802.1ag and ITU-T Y.1731 are completely compatible. The common FM mechanisms include: 1) Continuity Check Messages (CCM) 2) Loopback Message (LBM) and Loopback Reply (LBR) 3) Linktrace Message (LTM) and Linktrace Reply (LTR) CCM messages are used for fault detection including misconnections and mis-configurations. Typically CCM messages are sent as multicast frames or Unicast frames and also allow RDI notifications. LBM/LBR are used to perform fault verification, while also allow for MTU verification and CIR/EIR measurements. LTM/LTR can be used for discovering the path traversed between a MEP and another target MIP/MEP in the same MA. LTM/LTR also allow for fault localization. In addition, ITU-T Y.1731 also specifies the following FM functions: 4) Alarm Indication Signal (AIS) AIS allows for fault notification to downstream and upstream nodes. Further, ITU-T Y.1731 also specifies the following PM functions: 5) Loss Measurement Message (LMM) and Reply (LMR) 6) Delay Measurement Message (DMR) and Reply (DMR) 7) 1-way Delay Message (1DM) Mohan, et. al. Expires: September 2011 [Page 15] Internet-Draft MPLS & Ethernet OAM Interworking Mar 2011 While LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is used to measure single-ended (aka two-way) Frame Delay (FD) and Frame Delay Variation (FDV, also known as Jitter). 1DM can be used for dual-ended (aka one-way) FD and FDV measurements. Authors' Addresses Dinesh Mohan Nortel 3500 Carling Ave Ottawa, ON K2H8E9 Email: dinmohan@hotmail.com Nabil Bitar Verizon Communications 117 West Street Waltham, MA 02451 Email : nabil.n.bitar@verizon.com Simon Delord Telstra 242 Exhibition St Melbourne VIC 3000, Australia E-mail: simon.a.delord@team.telstra.com Philippe Niger France Telecom 2 av. Pierre Marzin 22300 LANNION, France E-mail: philippe.niger@francetelecom.com Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: sajassi@cisco.com Ray Qiu Email: rayq@huawei.com Mohan, et. al. Expires: September 2011 [Page 16] --_000_CA1F95AB114E9matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors,
I am the document shepherd for draft-ie= tf-pwe3-mpls-eth-oam-iwk-04. I have the reviewed the draft, and have some c= omments, prefixed by **Matthew>, below.
<= span style=3D"font-family: Courier; ">
In general the draft is well written, but I would app= reciate if you could address the comments below and also those from Yaakov = Stein in a new revision of the draft prior to progressing this to AD review= .

Best regards,

Matthew

Internet-Draft     &nbs= p;                     D.= Mohan (Editor), Nortel
PWE3 Working Group   =                    N. Bit= ar (Editor), Verizon
Intended status: Standards Tra= ck          P. Niger, France Telecom=
Date Created: March 02, 2011           =          S. Delord, Telstra
<= font class=3D"Apple-style-span" size=3D"3">            =                     &nbs= p;                  R. Qiu, Hu= awei 


=
              MPL= S and Ethernet OAM Interworking
    = ;         draft-ietf-pwe3-mpls-eth-oam-iwk-04.txt

Abstract

This document specifies the mapping of = defect states between
Ethernet Attachment Circuits = (ACs) and associated Ethernet
Pseudowires (PWs) con= nected in accordance to the PWE3 architecture
[RFC3= 985] to realize an end-to-end emulated Ethernet service. This <= /font>
document augments the mapping of defect states between a = PW and
associated AC of the end-to-end emulated ser= vice in [PW-OAM-MSG-
MAP]. In [PW-OAM-MSG-MAP], Eth= ernet OAM was not covered due to lack
of Ethernet O= AM maturity. However, since then, [Y.1731] and
[802= .1ag] have been completed, and this document specifies the
mapping of defect states between Ethernet ACs and corresponding
Ethernet PWs.
=
**Matthew> The history is not required in the RFC. I sugge= st removing 
the 2nd half of the penultimate s= entence and the last sentence. 
Also, please r= emove any references in the abstract, e.g. [RFC3985].<= /div>

Status of this Memo

   This Internet-Draft is submitted= to IETF in full conformance with the
   = provisions of BCP 78 and BCP 79.

=
   Internet-Drafts are working documents of the Intern= et Engineering
   Task Force (IETF), its = areas, and its working groups.  Note that
&nbs= p;  other groups may also distribute working documents as Internet-
   Drafts.
<= span style=3D"font-family: Courier; ">
   Internet-Drafts are draft documents vali= d for a maximum of six months
   and may = be updated, replaced, or obsoleted by other documents at any<= /span>
   time.  It is inappropriate to use Internet-Draf= ts as reference
   material or to cite th= em other than as "work in progress."

   The list of current Internet-Drafts can be acce= ssed at
   http://www.ietf.org/ietf/1id-a= bstracts.txt.

<= span style=3D"font-family: Courier; "> &n= bsp; The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft= will expire in September 2011.

=
Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified= as the
   document authors.  All ri= ghts reserved.

=  &= nbsp; This document is subject to BCP 78 and the IETF Trust's Legal<= /font>
   Provisions Relating to IETF Documents=


<= /div>
Mohan, et. al.       Expires: September 2011    = ;           [Page 1]
=0C
Internet-Draft    MPLS & Ethernet OAM = Interworking         Mar 2011    


&nbs= p;  (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Plea= se review these documents
   carefully, a= s they describe your rights and restrictions with respect
   to this document. Code Components extracted from this d= ocument must 
   include Simplified = BSD License text as described in Section 4.e of <= /div>
   the Trust Legal Provisions and are provided without warrant= y as 
   described in the Simplified= BSD License.

<= span style=3D"font-family: Courier; ">
Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIR= ED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", = "RECOMMENDED", "MAY", and "OPTIONAL" in this
docume= nt are to be interpreted as described in RFC 2119.
=
=
Table of Contents=

Status of this Memo..= ..............................................1
<= div>Con= ventions used in this document..................................2
1. Introduction.............................................= .......3
1.1. Reference Model and Defect Locations.= .........................4
1.2. Abstract Defect Sta= tes........................................4
2. Ter= minology.....................................................6
3. PW Status and Defects.......................................= ....6
3.1 Use of Native Service notification.......= ......................6
3.2 Use of PW Status notif= ication for MPLS PSNs....................7
<= span style=3D"font-family: Courier; ">3.3 Use = of BFD Diagnostic Codes....................................7<= /span>
4. Ethernet AC Defect States Entry or Exit Criteria..............= ..8
<= font class=3D"Apple-style-span" size=3D"3">4.1 AC Receive Defect State Entry or Exit......= ....................8
4.2 AC Transmit Defect State = Entry or Exit.........................8
5. Ethernet= AC and PW Defect States Interworking...................9
5.1 PW Receive Defect Entry Procedures.............................9=
5.2 PW Receive Defect Exit Procedures.............= ................10
5.3 PW Transmit Defect Entry Pro= cedures...........................11
5.4 PW Transmi= t Defect Exit Procedures............................11=
5.5 AC Receive Defect Entry Procedures............................12
5.6 AC Receive Defect Exit Procedures................= .............12
5.7 AC Transmit Defect Entry Proced= ures...........................12
5.8 AC Transmit D= efect Exit Procedures............................13
6. Acknowledgments................................................13
7. IANA Considerations..................................= ..........13
8. Security Considerations............= ............................13
9. References.....= ................................................13
= 9.1 Normative References..........................................13=
9.2 Informative References...............................= .........14
Appendix A: Ethernet Native Service Man= agement....................14
Intellectual Property= Statement...................................15
<= div>Aut= hors' Addresses................................................16


=


=
Mohan, et. al.       Expires: September 2011 &nbs= p;             [Page 2]<= /div>
=0C
Internet-Draft    MPLS & Ether= net OAM Interworking         Mar 2011    

1. Introduction

This document specifies th= e mapping of defect states between
<= span class=3D"Apple-style-span" style=3D"font-size: 12px;">Ethernet Attachm= ent Circuits (ACs) and associated Ethernet
<= span style=3D"font-family: Courier; ">Pseudowi= res (PWs) connected in accordance to the PWE3 architecture
[RFC3985] to realize an end-to-end emulated Ethernet service. This<= /span>
document augments the mapping of defect states betw= een a PW and
associated AC of the end-to-end emulat= ed service in [PW-OAM-MSG-
MAP]. In [PW-OAM-MSG-MAP= ], Ethernet OAM was not covered due to lack
= of Ethe= rnet OAM maturity. However, since then, [Y.1731] and
mapping of defect states between Ethernet ACs and correspondi= ng
Ethernet PWs.

**Matthew> See comment above about the document hi= story.

=

**Matthew> For the sake of cl= arity, the authors might want to 
call out the= Ethernet OAM mechanisms covered by this document 
as a bulleted list, along with references.
<= div>

Ethernet Link OAM = [802.3] allows some Link defect states to be
detect= ed and communicated across an Ethernet Link. When an Ethernet=
AC is an Ethernet PHY, there may be some application of Ethernet=
Link OAM [802.3]. Further, E-LMI [MEF16] also allo= ws for some EVC
defect states to be communicated ac= ross an Ethernet UNI where
Ethernet UNI constitutes= a single hop Ethernet Link (i.e. without
any 802.= 1Q/.1ad compliant bridges in between). There may be some
application of E-LMI [MEF16] for failure notification across single
hop Ethernet AC in certain deployments that specific= ally do not
support [802.1ag] and/or [Y.1731]. [Y.1= 731] and [802.1ag] based
mechanisms are applicable = in all types of Ethernet ACs. 
=


<= div>Lin= k OAM [802.3] and E-LMI [MEF16] are optional and their=
applicability is called out, where applicable.
=
= Native Service (NS) OAM may be transported tra= nsparently over the
corresponding PW as user data. = For Ethernet, as an example, 802.1ag
continuity che= ck messages (CCMs) between two Maintenance End Points<= /div>
(MEPs) can be transported transparently as user data over the
corresponding PW. At MEP locations, service failure is detect= ed when
a number of consecutive CCMs are missed.&nb= sp;
<= font class=3D"Apple-style-span" size=3D"3">
**Matthew> It m= ight be worth clarifying that various CCM defect =
conditions may be raised, including a timeout condition that is 
detected after 3.5times the local CCM interval. = ;

MEP locations can = be the
PE, the CE or both with different Maintenanc= e Domain Levels. 

<= /div>
**Matthew> I think this might be clearer if you rephrase this as:&nbs= p;
"MEP peers can exist between CE pairs (MEP of a = given MEG reside 
on the CEs), PE pairs (the= MEPs of a given MEG reside on the PEs), 
or e= ven peering between the CE-PE (the MEPs of a given MEG reside <= /font>
on the PE and CE), as long as the domain nesting rules ar= e maintained."

=
However, when interworking two networking domains, su= ch as native
Ethernet and PWs to provide an end-to-= end emulated service, there is
need to identify t= he failure domain and location even when a PE
suppo= rts both the NS OAM mechanisms and the PW OAM mechanisms. In<= /span>
addition, scalability constraints may not allow running proactive=
monitoring, such as CCMs with transmission on, at = a PE to detect the
failure of an Ethernet Virtual c= ircuit (EVC) across the PW domain.
<= span class=3D"Apple-style-span" style=3D"font-size: 12px;">Thus, network dr= iven alarms generated upon failure detection in the
NS or PW domain and their mappings to the other domain are needed.<= /font>
There are also cases where a PE may not be able to proces= s NS OAM
messages received on the PW even when such= messages are defined, as
in Ethernet case, necessi= tating the need for fault notification
message mapp= ing between the PW domain and the Client domain.
=
For Multi-Segment PWs (MS-PWs) [RFC5659], Switch= ing PEs (S-PEs)
are not aware of the NS. Thus failu= re detection and notification at
S-PEs will be base= d on PW OAM mechanisms. Mapping between PW OAM and
=
=
Mohan, et. al. &n= bsp;     Expires: September           &n= bsp;        [Page 3]
=0C
Internet-Draft    MPLS & Ethernet OAM I= nterworking         Mar 2011    

NS OAM will be required at the Ter= minating PEs (T-PEs) to propagate
the failure notif= ication to the EVC endpoints.

Similar to [PW-OAM-MSG-MAP], the intent of this document is to
standardize the behavior of PEs with respect to failu= res on Ethernet
ACs and PWs, so that there is no am= biguity about the alarms
generated and consequent a= ctions undertaken by PEs in response to
specific fa= ilure conditions.


=
1.1.          Reference M= odel and Defect Locations

=
Figure 1 is the same as used in [PW-OAM-MSG-MAP] and is reproduced
in this document as a reference to highlight defect l= ocations.


<= /font>
        ACs      =       PSN tunnel             =   ACs
          =      +----+              = ;    +----+
+----+       &= nbsp;  | PE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| P= E2|          +----+
| &nbs= p;  |---(a)---(b)..(c)......PW1..(d)..(c)..(f)---(e)---|    = |
| CE1|   (N1)   |    |  =                |    | &n= bsp;  (N2)  |CE2 |
|    |------= ----|............PW2.............|----------|    |<= /span>
+----+          |    |=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|    |   &nb= sp;      +----+
    = ;^           +----+         &n= bsp;        +----+          ^<= /span>
    |      Provider E= dge 1         Provider Edge 2     |
    |           &nbs= p;                     &n= bsp;                |=
    |<-------------- Emulated Service --------= -------->|

<= span style=3D"font-family: Courier; ">Customer=                     &nbs= p;                     &n= bsp;    Customer
Edge 1     &nb= sp;                     &= nbsp;                    =  Edge 2

<= span style=3D"font-family: Courier; "> &n= bsp;           Figure 1: PWE3 Network Defect Locat= ions
=
**Matthew> I t= hink that the reference architecture for Ethernet is 
more complicated than this model, which served us well for other&nb= sp;
<= font class=3D"Apple-style-span" size=3D"3">technologies. Can you illustrate where the NTE = is? I think this is 
important because it impa= cts how service provider and customer MEGs 
=
ar= e overlaid on this, and where the MEPs reside. It would also be 
worth illustrating in a figure how these MEGs are overla= id.
<= font class=3D"Apple-style-span" size=3D"3">

=

Customer        = ;                     &nb= sp;                  Customer<= /span>
Edge 1             &n= bsp;                     =                Edge 2=



1.2.          Abstract Defe= ct States

Abstract Def= ect States are also introduced in [PW-OAM-MSG-MAP]. This
document uses the same conventions, as shown in Figure 2 from [PW-
OAM-MSG-MAP]. It may be noted however that CE devices= , shown in
Figure 2, do not necessarily have to be = end customer devices; these
are essentially devices= in client network segments that are
connecting to = PSN network for the emulated services.

<= /font>
               &n= bsp;       +-----+
  ----A= C receive ----->|     |-----PW transmit----><= /span>
CE1                  = ;  | PE1 |                 &nb= sp;     PE2/CE2
  <---AC tra= nsmit------|     |<----PW receive-----
                    = ;   +-----+

(arro= ws indicate direction of user traffic impacted by a defect)

Figure 2: Transmit and Receive Defect= States and Notifications

=
**Matthew> For the 1731/802.1ag case, can you show the possible MEP<= /span>
 locations on a similar diagram? You should al= so call out the case 
where there are no SP ME= Ps on the PEs, in which case any faults in 
=
th= e PW would be detected by the PEs but not mapped to any Ethernet 
indications on the ACs. It would be up to CCM between= the CEs (of NTEs) 
to detect a failure. Here = is an example of the kind of diagram I am 
<= div>ref= erring to, for the case of a simple AC failure. Of course, feel free=
To make a proposal:

               &n= bsp;          +-------+
=
&n= bsp;                    &= nbsp;    |       |----PW transmit---->
CE1 =3D=3D=3DNID=3D=3DAC=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D|  PE1  |               &nb= sp;       PE2/CE2
         =        |       |<----PW receive-----=
             &n= bsp;            +-------+
        MEP=3DL2<----->MEP=3DL2<= /font>
       UP|DOwn       &= nbsp;DOWN

  =   MEP=3DL4----------------NID to NID-----------------MEP=3DL4<= /font>
       UP        =                     &nbs= p;                 UP=

 MEP=3DL6------------------Cus= tomer Domain-----------------------MEP=3DL6
=
Mohan, et. al.       Expires: Septembe= r 2011               [Page 4]
=0C
Internet-Draft    MPLS = & Ethernet OAM Interworking         Mar 2011  =  

PE1 may detect= a receive defect in local Ethernet AC via one of the<= /div>
following mechanisms:
- An AIS alarm generated a= t an upstream node in the client domain
(CE1 in Fig= ure 2) and received by a local MEP associated with the=
local AC.
- Failure of the local link on which = the AC is configured. Link
failure may be detected = via physical failures (e.g., loss of signal
= (LoS)),= or via Ethernet Link OAM [802.3] critical link event<= /div>
notifications generated at an upstream node CE1 with "Dying Gasp"=
or "Critical Event" indication.
-= Failure to receive CCMs on the AC if a local MEP is configured for<= /font>
the AC.
- A CCM from CE1 with int= erface status TLV indicating interface down. 
= Other CCM interface status TLVs will not be used to indicate<= /span>
failure or recovery from failure. 
<= br>
<= font class=3D"Apple-style-span" size=3D"3">**Matthew> Given the above suggestion to sho= w the possible MEGs on the 
reference architec= ture, you should  rephrase these sections and following<= /span>
 similar sections through out the draft. Also, you seem to b= e limiting 
this to interface up/down events o= n the AC. I think you could also 
account for = any MAC status defect that affects the overall MAC defect
 state. 

=
 
AC receive defect at PE1 impacts the abi= lity of PE1 to receive user 
traffic from the = Client domain attached to PE1 via that AC.
<= span style=3D"font-family: Courier; ">
Similarly, PE1 may detect a receive defect in the PW = via one of the
following mechanisms:<= /span>
- Forward Defect indication received from PE2. This defect=
indication could point to problems associated with PE2's = inability
to transmit traffic on the PW or PE2's in= ability to receive traffic
on its local AC.<= /font>
- Unavailability of a PSN path in the PW domain to PE2.

PW forward defect indic= ation received on PE1 impacts the ability of PE1 =
to receive traffic on the PW.

PE1 may be notified of an AC transmit defect via one of the fol= lowing
mechanisms:
<= span style=3D"font-family: Courier; ">- CCMs w= ith RDI (Remote Defect Indication) bit set.
= - In ca= se when the AC is associated with a physical port, failure of=
the local link on which the AC is configured (e.g., LOS or via E= thernet
Link OAM [802.3] critical link event notifi= cations generated at an
upstream node CE1 with "Li= nk Fault" indication).

<= /div>
AC transmit defect impacts the ability of PE1 to send user traffic on
the local AC.
=
Similarly, PE1 may be notified of a PW transmit defect via Re= verse
Defect indication from PE2, which could point= to problems associated
with PE2's inability to re= ceive traffic on the PW or PE2's inability
<= span style=3D"font-family: Courier; ">to trans= mit traffic on its local AC. PW transmit defect impacts PE1
ability to send user traffic toward CE2.
<= br>
<= font class=3D"Apple-style-span" size=3D"3">The procedures outlined in this document define= the entry and exit
criteria for each of the four d= efect states with respect to Ethernet
ACs and corre= sponding PWs, and the consequent actions that PE1 must=
support to properly interwork these defect states and corresponding
notification messages between the PW domain and the N= ative Service
(NS) domain. Receive Defect state sho= uld have precedence over
Transmit Defect state in t= erms of handling, when both transmit and

Mohan, et. al.       Expires: Septembe= r 2011               [Page 5]
=0C
Internet-Draft    MPLS = & Ethernet OAM Interworking         Mar 2011  =  

receive defect= states are identified simultaneously.

<= /font>
2. Terminology

=
This document uses the following terms:
= AIS       Alarm Indication Signal
=
MD= Level  Maintenance Domain (MD) Level which identifies a value<= /font>
          in the range of 0= -7 associated with Ethernet OAM frame.
  =        MD Level identifies the span of the Ethernet OA= M frame.
MEP       Maintenance End P= oint is responsible for origination
=    &n= bsp;      and termination of OAM frames for a given MEG
MIP       Maintenance Intermediate Poi= nt is located between peer
     &nbs= p;    MEPs and can process OAM frames but does not initiate
          or terminate the= m
RDI       Remote Defect Indication=

Further, this documen= t also uses the terminology and conventions
= used in= [PW-OAM-MSG-MAP].

<= div>
3. PW Status and Defects
=
= [PW-OAM-MSG-MAP] introduces a range of defects= that impact PW
status. All these defect conditions= are applicable for Ethernet PWs.

Similarly, there are different mechanisms described in [PW-OAM-= MSG-
= MAP] to detect PW defects, depending on the PS= N type (e.g. MPLS PSN,
MPLS-IP PSN). Any of these= mechanisms can be used when monitoring
the state o= f Ethernet PWs.  [PW-OAM-MSG-MAP] also discusses the
applicability of these failure detection mechanisms.

3.1 Use of Native Service (NS) notifi= cation

= There is no NS = fault notification capability currently specified for<= /div>
Ethernet PWs. However, with the completion of Ethernet OAM work,<= /font>
this capability should be added. This includes the abilit= y to create
a MEP associated with the Ethernet PW o= n the PE. The native service
notification options i= nclude:

**Matthew> = The above text seems out of date, since this draft addresses 
many Ethernet fault notification mechanisms. =


<= /div>
- AIS Frames sent by the local MEP to the MEP on the remote PE when
the MEP needs to convey PE receive defects, and when = CCM
<= font class=3D"Apple-style-span" size=3D"3">transmission is configured not to be turned ON.=
- Suspension of CCM frames transmission from the M= EP to the peer MEP
on the other PE to convey PE rec= eive defects, when CCM
transmission is configured= to be turned ON.
- RDI bit set in transmitted CCM = frames, when loss of CCMs from the 
peer MEP= is detected or PE needs to convey PW reverse defects.=

These NS OAM notifications are inserted in= to the corresponding PW.

<= /div>
Similarly, when the defect conditions are cleared, a PE can take one
of the following actions, depending on the mechanism = that was used
for failure notification, to clear th= e defect sate on the peer PE:


Mohan, et. al.       Ex= pires: September 2011               [Pag= e 6]
= =0C
Internet-Draft &nb= sp;  MPLS & Ethernet OAM Interworking         = Mar 2011    

<= /div>

- Stop AIS Frame transmission from the loca= l MEP to the MEP on the
remote PE to clear PW rece= ive defects;
- Resuming CCM frames transmission fro= m the MEP to the peer MEP to
clear PW forward defec= ts notification, when CCM transmission is
configur= ed to be turned ON.
- Clearing RDI indication in tr= ansmitted CCM frames, to clear PW
transmit defects = notification.

<= span style=3D"font-family: Courier; ">**Matthe= w> Is there any impact of Y.1731 CSF? Is that in scope of this 
draft or will it be addressed separately?


3.2 = Use of PW Status notification for MPLS PSNs
=
When PWs are established using LDP, LDP status notifi= cation
signaling SHOULD be used as the default mech= anism to signal AC and
PW status and defects [RFC= 4447]. For PWs established over an MPLS or
<= span style=3D"font-family: Courier; ">MPLS-IP = PSN using other mechanisms (e.g. static configuration),
inband signaling using VCCV-BFD [RFC5885] SHOULD be used to convey AC<= /span>
and PW status and defects.
=
= **Matthew> The use of MUST and SHOULD above= conflicts with the OAM message
 mapping draf= t. I suggest you align with that draft.

=
[PW-OAM-MSG-MAP] identifies the following PW defect statu= s
codepoints:
- Forward def= ect: corresponds to a logical OR of local AC (ingress)=
Receive fault, local PSN-facing PW (egress) transmit fault, and PW = ;
not forwarding fault.
<= div>- R= everse defect: corresponds to a logical OR of local AC (egress)
transmit fault and local PW PSN-facing (ingress) receive fault= .

There are also sce= narios where a PE carries out PW label withdrawal
i= nstead of PW status notification. These include administrative
disablement of the PW or loss of Target LDP session with the pe= er
PE.

=

3.3 Use of BFD Diagnostic Codes

When using VCCV, the con= trol channel (CC) type and Connectivity
Verificatio= n (CV) Type are agreed on between the peer PEs using the
OAM capability sub-TLV signaled as part of the interface parameter
TLV when using FEC 129 and the interface parameter su= b-TLV when
using FEC 128.
<= br>
<= font class=3D"Apple-style-span" size=3D"3">As defined in [PW-OAM-MSG-MAP], when CV type of= 0x04 0r 0x1 is used
to indicate that BFD is used f= or PW fault detection only, PW defect 
= is dete= cted via the BFD session while other defects, such as AC
detected or PE internal defects preventing it from forwarding traffic= ,
are communicated via LDP Status notification mess= age in MPLS and 
MPLS-IP PSN or other mechanis= ms in L2TP-IP PSN.

<= div>Sim= ilarly, when CV type of 0x08 or 0x20 is used to indicate that BFD 
is used for both PW fault detection and AC/PW Fault N= otification, 
all defects are signaled via BFD= .


=


Mohan,= et. al.       Expires: September 2011       =         [Page 7]
=0C
Internet-Draft    MPLS & Ethernet OAM Interwork= ing         Mar 2011    =

4. Ethernet AC Defect States Entry or Exit= Criteria

4.1 AC Recei= ve Defect State Entry or Exit

PE1 enters the AC Receive Defect state if any of the following
conditions are met:

- It detects or is notified of a physical layer fault= on the
Ethernet interface. Ethernet link failure c= an be detected based on
loss of signal (LoS) or vi= a Ethernet Link OAM [802.3] critical
link event not= ifications generated at an upstream node CE1 with
"= Dying Gasp" or "Critical Event" indication.
= - A MEP= associated with the local AC receives an Ethernet AIS frame.=
- A MEP associated with the local AC does not receive CCM frames=
from the peer MEP in the client domain (e.g. CE1) = within a
configurable interval equal to a multiple = (e.g. 3.5) of the CCM
transmission period configure= d for the MEP. This is the case when
CCM transmissi= on is configured to be turned ON. 

=
**Matthew> I don;t think the interval is configurable,= but the 
transmission period is. So the text = above should read: "A MEP 
associated with th= e local AC does not receive CCM frames from the <= /div>
peer MEP in the client domain (e.g. CE1) within an interval equal to a&n= bsp;
= multiple (e.g. 3.5) of the CCM transmission pe= riod configured for 
the MEP."

- A CCM with interface status TLV ind= icating interface down. Other 
= CCM interface s= tatus TLVs will not be used to indicate
failure or = recovery from failure. 



PE1 exit= s the AC Receive Defect state if all of the conditions that
resulted in entering the defect state are cleared. This includes a= ll
of the following conditions:

- Any physical layer fault on the Etherne= t interface, if detected or
notified previously, is= s removed (e.g. via loss of signal (LoS), or
Ethern= et Link OAM [802.3] critical link event notifications with
"Dying Gasp" or "Critical Event" indication cleared at an upstream<= /span>
node CE1).
<= span class=3D"Apple-style-span" style=3D"font-size: 12px;">- A MEP associat= ed with the local AC does not receive any Ethernet
= AIS frame within a period indicated by previously received AIS, if
AIS was resulted in entering the defect state. 

- A MEP associated with = the local AC and configured with CCM
transmission o= n receives a configured number (e.g. 3 or more) of
= consecutive CCM frames from the peer MEP on CE1 within an interval
equal to a multiple (e.g. 3.5) of the CCM transmission pe= riod
= configured for the MEP.  

- CCM indicates interface status up.&= nbsp;

<= span class=3D"Apple-style-span" style=3D"font-size: 12px;">
4.2 AC Transmit Defect State Entry or Exit

PE1 enters the AC Transmit Defect state i= f any of the following
conditions is met:<= /font>

- It detects or is notifie= d of a physical layer fault on the
<= span class=3D"Apple-style-span" style=3D"font-size: 12px;">Ethernet interfa= ce (e.g. via loss of signal (LoS) or Ethernet Link
= OAM [802.3] critical link event notifications generated at an=
upstream node CE1 with "Link Fault" indication).  
- A MEP configured with CCM transmission turned ON and as= sociated
with the local AC receives a CCM frame, wi= th its RDI bit set, from
peer MEP in the client dom= ain (e.g. CE1).


Mohan, et. al.       Expires: Septemb= er 2011               [Page 8]
=0C
Internet-Draft    MPLS= & Ethernet OAM Interworking         Mar 2011  = ;  

PE1 exits the= AC Transmit Defect state if all of the conditions that
resulted in entering the defect state are cleared. This includes all
of the following conditions:

- Any physical layer fault on the Ethernet in= terface, if detected or
notified previously, is re= moved (e.g. via Ethernet Link OAM
[802.3] critical = link event notifications with "Link Fault"
<= span style=3D"font-family: Courier; ">indicati= on cleared at an upstream node CE1).
- A MEP config= ured with CCM transmission turned ON and associated
with the local AC does not receive a CCM frame with RDI bit set,
having received a previous CCM frame with RDI bit set from t= he
peer MEP in the client domain (e.g. CE1).=


<= /div>
5. Ethernet AC and PW Defect States Interworking

5.1 PW Receive Defect Entry Procedures=

When the PW status on PE1 = transitions from working to PW Receive
Defect state= , PE1's ability to receive user traffic from CE2 is
impacted. As a result, PE1 needs to notify CE1 about this problem.<= /font>

Upon entry to the PW Recei= ve Defect state, the following must be
done:=

- If PE1 is configured wit= h a MEP associated with the local AC and
CCM tran= smission is not configured to be turned ON, the MEP
associated with the AC must transmit AIS frames periodically to the=
MEP in the client domain (e.g. on CE1) based on configure= d AIS
transmission period.  

**Matthew> Is this an UP MEP pointin= g away from the AC into the PSN? 
Please clari= fy.
<= font class=3D"Apple-style-span" size=3D"3">

=
- If PE1 is configured with a MEP associated with the local AC a= nd
CCM transmission is configured to be turned ON, = and the MEP
associated with the AC is configured to= support Interface Status TLV
in CCM messages, the = MEP associated with the AC must transmit CCM
frames= with Interface Status TLV as being down to the peer MEP in
the client domain (e.g. on CE1).  
=
**Matthew> Please clarify if this is a DOWN M= EP.
<= font class=3D"Apple-style-span" size=3D"3">
- If PE1 is config= ured with a MEP associated with the local AC and
=
CC= M transmission is configured to be turned ON, and the MEP
associated with the AC is configured to not support Interface Status=
TLV in CCM messages, the MEP associated with the A= C must stop
transmitting CCM frames to the peer MEP= in the client domain (e.g.
on CE1).  <= /font>

**Matthew> Ditto=


<= /div>
- If PE1 is configured to run E-LMI [MEF16] with CE1 and if E-LMI=
is used for failure notification, PE1 must transmit E-LMI=
asynchronous STATUS message with report type Singl= e EVC Asynchronous
Status indicating that PW is Not= Active.  



Further, when PE1 enter= s the Receive Defect state, it must assume
<= span style=3D"font-family: Courier; ">that PE2= has no knowledge of the defect and must send reverse defect<= /span>


= Mohan, = et. al.       Expires: September 2011       &= nbsp;       [Page 9]
= =0C
Internet-Draft    MPLS & Ethernet OAM Interworki= ng         Mar 2011    <= /div>

failure notification to PE2. For MPLS PSN o= r MPLS-IP PSN, this is
done via either a PW Statu= s notification message indicating a
= reverse defect;= or via VCCV-BFD diagnostic code of reverse defect if<= /div>
VCCV CV type of 0x08 had been negotiated. When Native Service OAM=
mechanism is supported on PE, it can also use the NS OAM<= /span>
notification as specified in Section 3.1.

If PW receive defect is entered= as a result of a forward defect
notification from = PE2 or via loss of control adjacency, no
addition= al action is needed since PE2 is expected to be aware of the<= /span>
defect.

Note= : The location of the MEP associated with the local AC within a
PE can be a down MEP on the port associated with the AC or an = Up MEP
associated with an emulated LAN interface wi= thin the PE, as defined
in L2VPN framework for a V= PLS PE. Though for the purposes of VPWS
service, VP= LS PE architecture is not mandatory, the VPLS PE
=
ar= chitecture serves as a generic case where the PE can support both
VPWS and VPLS services.  

<= /span>
**Matthew> I am not sure that fault propagation = as described in this draft 
is applicable to m= p-mp services such as VPLS, since there is a 
= many-many relationship between PWs and ACs at a given PE.



5.2 PW Receive Defect Exit Procedures

When the PW status transitions from P= W Receive Defect state to
working, PE1's ability to= receive user traffic from CE2 is restored.
= As a re= sult, PE1 needs to cease defect notification to CE1 by=
performing the following:


- If PE1 is configured with a a MEP as= sociated with the local AC and
CCM transmission i= s not configured to be turned ON, the MEP
associat= ed with the AC must stop transmitting AIS frames towards the<= /span>
peer MEP in the client domain (e.g. on CE1).=

- If PE1 is configured with a MEP associat= ed with the local AC and
CCM transmission is config= ured to be turned ON, and the MEP
associated with t= he AC is configured to support Interface Status TLV
in CCM messages, the MEP associated with the AC must transmit CCM
frames with Interface Status TLV as being Up to the peer = MEP in the
client domain (e.g. on CE1).

- If PE1 is configured with a MEP= associated with the local AC and
CCM transmission = is configured to be turned ON, and the MEP
<= span style=3D"font-family: Courier; ">associat= ed with the AC is configured to not support Interface Status<= /span>
TLV in CCM messages, the MEP associated with the AC must resume
transmitting CCM frames to the peer MEP in the clien= t domain (e.g.
on CE1).
<= div>
- If PE1 is configured to run E-LMI [MEF16] with = CE1 and E-LMI is
used for fault notification, PE1 m= ust transmit E-LMI asynchronous
STATUS message wit= h report type Single EVC Asynchronous Status
indica= ting that PW is Active.

<= /div>


Mohan, et. al.=       Expires: September 2011         &= nbsp;    [Page 10]
=0C
Internet-Draft    MPLS & Ethernet OAM Interworking &nbs= p;       Mar 2011    

=
Further, if the PW receive defect was explicitly d= etected by PE1, it
must now notify PE2 about cleari= ng of Receive Defect state by
clearing reverse defe= ct notification. For PWs over MPLS PSN or MPLS-
<= div>IP = PSN, this is either done via PW Status message indicating
working; or via VCCV-BFD diagnostic code if VCCV CV type of 0x08/0x2= 0
had been negotiated. When Native Service OAM mech= anism is supported 
on PE, it can also clear t= he NS OAM notification specified in Section
= 3.1.

If PW receive defect was= established via notification from PE2 or
via loss= of control adjacency, no additional action is needed, since<= /span>
PE2 is expected to be aware of the defect clearing.=


5.3 PW= Transmit Defect Entry Procedures

When the PW status transitions from working to PW Transmit Defe= ct
state, PE1's ability to transmit user traffic to= CE2 is impacted. As
a result, PE1 needs to notify = CE1 about this problem which has been
detected by P= E1.
<= font class=3D"Apple-style-span" size=3D"3">
Upon entry to the = PW Transmit Defect state, the following must be
<= div>don= e:

- If PE1 is config= ured with a MEP associated with the local AC and
=
CC= M transmission is configured to be turned ON, the MEP associated
with the AC must set the RDI bit in transmitted CCM frames se= nt to
the peer MEP in the client domain (e.g. on CE= 1).  

**Matthew&g= t; Is it a MUST to set RDI? Or is it a MAY, since you may 
also use the interface status TLV?
<= div>

- If PE1 is config= ured to run E-LMI [MEF16] with CE1 and E-LMI is
<= div>use= d for fault notification, PE1 must transmit E-LMI asynchronous
STATUS message with report type Single EVC Asynchronous Status<= /span>
indicating that PW is Not Active.


5.4 PW T= ransmit Defect Exit Procedures

=
When the PW status transitions from PW Transmit Defect state to<= /span>
working, PE1's ability to transmit user traffic to = CE2 is restored.
As a result, PE1 needs to cease de= fect notifications to CE1 and
perform the following=

- If PE1 is configure= d with a MEP associated with the local AC and
CCM t= ransmission is configured to be turned ON, the MEP associated=
with the AC must clear the RDI bit in the transmitted CCM frames= to
<= font class=3D"Apple-style-span" size=3D"3">the peer MEP (e.g. on CE1).

- If PE1 is configured to run E-LMI [MEF1= 6] with CE1, PE1 must
transmit E-LMI asynchronous S= TATUS message with report type Single
EVC Asynchron= ous Status indicating that PW is Active.




Mohan, et. al.       Expir= es: September 2011              [Page 11= ]
=0C
Internet-Draft  =  MPLS & Ethernet OAM Interworking         Mar= 2011    

=
5.= 5 AC Receive Defect Entry Procedures

When AC status transitions from working to AC Receive Defect= state,
PE1's ability to receive user traffic from = CE1 is impacted. As a
result, PE1 needs to notify P= E2 and CE1 about this problem.

=
If the AC receive defect is detected by PE1, it must notify PE2 = in
the form of a forward defect notification.

When NS OAM is not support= ed on PE1, and for PW over MPLS PSN or
MPLS-IP PSN,= forward defect notification is done via either PW
= Status message indicating a forward defect or via VCCV-BFD
diagnostic code of forward defect if VCCV CV type of 0x08/0x20 had<= /span>
been negotiated.

When Native Service OAM mechanism is supported on PE1= , it can also
use the NS OAM notification as specif= ied in Section 3.1.

=
In= addition to above actions, PE1 must perform the following:

- If PE1 is configured with a MEP ass= ociated with the local AC and
CCM transmission is c= onfigured to be turned ON, the MEP associated
with = AC must set the RDI bit in transmitted CCM frames.
=
=
5.6 AC Receive De= fect Exit Procedures

W= hen AC status transitions from AC Receive Defect to working, PE1's
ability to receive user traffic from CE1 is restored. As = a result,
PE1 needs to cease defect notifications t= o PE2 and CE1 and perform
the following:

- When NS OAM is not supported o= n PE1 and for PW over MPLS PSN or
MPLS-IP PSN, forw= ard defect notification is cleared via PW Status
=
me= ssage indicating a working state; or via VCCV-BFD diagnostic code
if VCCV CV type of 0x08 or 0x20 had been negotiated.<= /font>

- When Native Service OAM = mechanism is supported on PE1, PE1 clears
the NS O= AM notification as specified in Section 3.1.


- If PE1 is configured = with a MEP associated with the local AC and
= CCM tra= nsmission is configured to be turned ON, the MEP associated
with the AC must clear the RDI bit in transmitted CCM frames to th= e
peer MEP in the client domain (e.g. on CE1).


5.7 AC Transmit Defect Entry Procedures

When AC status transitions from working to AC Transm= it Defect, PE1's
ability to transmit user traffic t= o CE1 is impacted. As a result,
PE1 needs to notif= y PE2 about this problem.

=


Mohan, et. al= .       Expires: September 2011         =       [Page 12]
=0C<= /span>
Internet-Draft    MPLS & Ethernet OAM Interworking =         Mar 2011    
=
= If the AC transmit defect is detected by PE1, = it must notify PE2 in
the form of a reverse defect = notification.

<= span style=3D"font-family: Courier; ">When NS = OAM is not supported on PE, in PW over MPLS PSN or MPLS-IP
PSN, reverse defect notification is either done via PW Status
message indicating a reverse defect; or via VCCV-BFD dia= gnostic code
of reverse defect if VCCV CV type of 0= x08 or 0x20 had been negotiated.

=
When Native Service OAM mechanism is supported on PE, it can als= o
use the NS OAM notification as specified in Secti= on 3.1.


5.8 AC Transmit Defect Exit Procedures<= /div>

When AC status transitions from AC Transmit= defect to working, PE1's
ability to transmit user = traffic to CE1 is restored. As a result,
PE1 need= s to clear notification to PE2.

=
If the AC Transmit defect is cleared, PE1 must clear reverse def= ect
<= font class=3D"Apple-style-span" size=3D"3">notification to PE2.
=
When NS OAM is not supported on PE1 and for PW o= ver MPLS PSN or
MPLS-IP PSN, reverse defect notific= ation is cleared via either a PW
Status message ind= icating a working state or via VCCV-BFD diagnostic
= code of if VCCV CV type of 0x08 had been negotiated.
When Native Service OAM mechanism is support= ed on PE1, PE1 can clear
NS OAM notification as spe= cified in Section 3.1.

<= /div>

6. Acknowledgments
=
= The authors are thankful to Samer Salam for hi= s valuable
comments.


7. IANA Considerations<= /span>

This document has no a= ctions for IANA.


<= /span>
8. Security Considerations
=
= This document does not impose any security con= cerns since it makes
use of existing OAM mechanisms= and mapping of these messages does
= not change inhe= rent security features.

<= /div>
9. References

9.1 N= ormative References

=

Mohan, et. al. &nb= sp;     Expires: September 2011          = ;    [Page 13]
=0C


[Y.1731] "OAM Functions = and mechanisms for Ethernet based networks",
ITU-T = Y.1731, May 2006

[802.= 1ag] "Connectivity Fault Management", IEEE 802.1ag/D8.1, Jul<= /span>
2007

= [RFC444= 7] "Pseudowire Setup and Maintenance using LDP", RFC4447,
April 2006

[RFC= 5885] "Bidirectional Forwarding Detection (BFD) for the =
Pseudowire Virtual Circuit Connectivity Verification (VCCV)",&nb= sp;
<= font class=3D"Apple-style-span" size=3D"3">RFC5885, June 2010

=
[802.3] "CDMA/CD access method and physical layer = specifications",
Clause 57 for Operations, Administ= ration and Maintenance, 2005

[MEF16] "Ethernet Local Management Interface", MEF16, January 2006

9.2 Informative Referen= ces
<= font class=3D"Apple-style-span" size=3D"3">
[RFC3985] "Pseudo = Wire Emulation Edge-to-Edge (PWE3) Architecture",
R= FC 3985, March 2005

=
[P= W-OAM-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", draft-ietf-
pwe3-oam-msg-map-14.txt, Work in progress, October 2010

[RFC5659] "An Architect= ure for Multi-Segment Pseudo Wire
Emulation Edge-to= -Edge", RFC5659, October 2009


Appendix A: Ethernet Native Service Ma= nagement

Ethernet OAM = mechanisms are broadly classified into two categories:=
Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731
provides coverage for both FM and PM while IEEE 802.1= ag provides
coverage for a sub-set of FM functions.=

Ethernet OAM also int= roduces the concept of Maintenance Entity (ME)
whic= h is used to identify the entity that needs to be managed. A ME
is inherently a point-to-point association. However, in case o= f a
<= font class=3D"Apple-style-span" size=3D"3">multipoint association, Maintenance Entity Grou= p (MEG) consisting of
different MEs is used. IEEE 8= 02.1 uses the concept of Maintenance
Association (M= A) which is used to identify both point-to-point and
(MEPs) which are responsible for originating OAM frames.= In between
the MEPs, there can also be Maintenance= Intermediate Points (MIPs)
which do not originate = OAM frames however do respond to OAM frames
= from ME= Ps.
<= font class=3D"Apple-style-span" size=3D"3">

=
Mohan, et. al.       Expires: September 2011 &nbs= p;            [Page 14]<= /div>
=0C
Internet-Draft    MPLS & Ether= net OAM Interworking         Mar 2011    


Ethernet OAM allows for hierarchical maintenance entities to allow
for simultaneous end-to-end and segment monitoring. T= his is achieved
by having a provision of up to 8 Ma= intenance Domain Levels (MD
Levels) where each MEP = or MIP is associated with a specific MD
Level.

It is important to note = that the common set of FM mechanisms between
IEEE 8= 02.1ag and ITU-T Y.1731 are completely compatible.
=
= The common FM mechanisms include:

1) Continuity Check Messages (CCM)=
2) Loopback Message (LBM) and Loopback Reply (LBR)=
3) Linktrace Message (LTM) and Linktrace Reply (LT= R)

CCM messages are u= sed for fault detection including misconnections
=
an= d mis-configurations. Typically CCM messages are sent as multicast
frames or Unicast frames and also allow RDI notifications= . LBM/LBR
are used to perform fault verification, w= hile also allow for MTU
verification and CIR/EIR m= easurements. LTM/LTR can be used for
discovering th= e path traversed between a MEP and another target
M= IP/MEP in the same MA. LTM/LTR also allow for fault localization.

In addition, ITU-T Y.1731 also = specifies the following FM functions:

4) Alarm Indication Signal (AIS)
=
= AIS allows for fault notification to downstrea= m and upstream nodes.

= Further, ITU-T Y.1731 also specifies the following PM functions:

5) Loss Measurement Message (LMM= ) and Reply (LMR)
6) Delay Measurement Message (DMR= ) and Reply (DMR)
7) 1-way Delay Message (1DM)


Mohan, et. al.       Expires: September 2011   &nb= sp;          [Page 15]
<= div>=0C=
Internet-Draft    MPLS & Ethernet OA= M Interworking         Mar 2011    


=
Wh= ile LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is
used to measure single-ended (aka two-way) Frame Delay (FD) = and
<= font class=3D"Apple-style-span" size=3D"3">Frame Delay Variation (FDV, also known as Jitte= r). 1DM can be used
for dual-ended (aka one-way) FD= and FDV measurements.

<= /div>
Authors' Addresses

= Dinesh Mohan
Nortel
= 3500 Ca= rling Ave
Ottawa, ON K2H8E9
Email: dinmohan@hotmail.com

Nabil Bitar
Verizon Communications
117 West Street
Waltham, MA 02451<= /span>
Email : nabil.n.bitar@verizon.com

Simon Delord
=
Te= lstra  
242 Exhibition St  =
Melbourne VIC 3000, Australia  
<= div>E-m= ail: simon.a.delord@team.telstra.com  
=
Philippe Niger
France Telecom=
2 av. Pierre Marzin
22300 = LANNION, France
E-mail: philippe.niger@franceteleco= m.com

<= span class=3D"Apple-style-span" style=3D"font-size: 12px;">Ali Sajassi
Cisco
170 West Tasman Drive
San Jose, CA  95134, US
Email: sajassi@cisco.com

=
Ray Qiu
Email: rayq@huawei.com


Mohan, e= t. al.       Expires: September 2011       &n= bsp;      [Page 16]
<= span class=3D"Apple-style-span" style=3D"font-size: 12px;">=0C



<= /span>


--_000_CA1F95AB114E9matthewboccialcatellucentcom_-- From lmartini@cisco.com Fri Jun 17 14:38:33 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB16B11E80EF for ; Fri, 17 Jun 2011 14:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfmg6wyVhS4u for ; Fri, 17 Jun 2011 14:38:33 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 561FF11E807F for ; Fri, 17 Jun 2011 14:38:33 -0700 (PDT) Received: from seven.monoski.com ([64.101.67.244]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p5HLcORC023529 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2011 15:38:25 -0600 (MDT) Message-ID: <4DFBC94B.9010801@cisco.com> Date: Fri, 17 Jun 2011 15:38:19 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: David Allan I References: <60C093A41B5E45409A19D42CF7786DFD521B518CF3@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD521B518CF3@EUSAACMS0703.eamcs.ericsson.se> Content-Type: multipart/alternative; boundary="------------000908010605000809050103" Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 21:38:34 -0000 This is a multi-part message in MIME format. --------------000908010605000809050103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave, And everybody else. Thanks you for your support! Since this document does not describe anything of what you mentioned below, you must be a supporter ! Please read the document . Thank you. Luca On 06/09/2011 04:43 PM, David Allan I wrote: > I'm opposed to this draft progressing at this time. > > At the moment the PW with a CW is a unifying agent that will work in both TP domains and those that employ ECMP and LAG. The GAL/ACh version cannot make this claim. > > What would be required to make this acceptable IMO would be agreement with the MPLS WG to produce an RFC that documented excluding reserved labels from ECMP consideration such that GAL/GACh encapsulated PW OAM had "feature parity" with ACh encapsulated PW-OAM... > > Then we could reasonably consider taking steps to move to a common OAM encapsulation mechanism common to LSPs and PWs. > > My 2 cents > Dave > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --------------000908010605000809050103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave,
And everybody else.

Thanks you for your support!
Since this document does not describe anything of what you mentioned below,
you must be a supporter !

Please read the document .

Thank you.
Luca


On 06/09/2011 04:43 PM, David Allan I wrote: 
I'm opposed to this draft progressing at this time.

At the moment the PW with a CW is a unifying agent that will work in both TP domains and those that employ ECMP and LAG. The GAL/ACh version cannot make this claim.

What would be required to make this acceptable IMO would be agreement with the MPLS WG to produce an RFC that documented excluding reserved labels from ECMP consideration such that GAL/GACh encapsulated PW OAM had "feature parity" with ACh encapsulated PW-OAM...

Then we could reasonably consider taking steps to move to a common OAM encapsulation mechanism common to LSPs and PWs.

My 2 cents
Dave




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

--------------000908010605000809050103-- From david.i.allan@ericsson.com Fri Jun 17 14:45:29 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11C611E80EF for ; Fri, 17 Jun 2011 14:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnNxJx5XblK4 for ; Fri, 17 Jun 2011 14:45:28 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA2411E807F for ; Fri, 17 Jun 2011 14:45:28 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p5HLjRTM022888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jun 2011 16:45:27 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.12]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 17 Jun 2011 17:45:26 -0400 From: David Allan I To: Luca Martini Date: Fri, 17 Jun 2011 17:45:26 -0400 Thread-Topic: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Thread-Index: AcwtNxa2EnOZRZPoTTmUbPrDv1VtmwAAE/cQ Message-ID: <60C093A41B5E45409A19D42CF7786DFD521B61CAF1@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD521B518CF3@EUSAACMS0703.eamcs.ericsson.se> <4DFBC94B.9010801@cisco.com> In-Reply-To: <4DFBC94B.9010801@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD521B61CAF1EUSAACMS0703e_" MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 21:45:29 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD521B61CAF1EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did read it and given this extract from the document am wondering what pa= rt I missed? Therefore, this document specifies that the GAL can be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, Sections, and PWs in both MPLS and MPLS-TP environments without discrimination. I would argue that using the GAL for PWs in any environment is a mistake, a= nd this is not the only symptom of the problem... The fix to 5586 should be= to PLACE a restiction on the use of the GAL on PWs in MPLS environments...= not eliminate the restriction in TP environments. I hope that is clearer. cheers Dave ________________________________ From: Luca Martini [mailto:lmartini@cisco.com] Sent: Friday, June 17, 2011 2:38 PM To: David Allan I Cc: pwe3@ietf.org Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Dave, And everybody else. Thanks you for your support! Since this document does not describe anything of what you mentioned below, you must be a supporter ! Please read the document . Thank you. Luca On 06/09/2011 04:43 PM, David Allan I wrote: I'm opposed to this draft progressing at this time. At the moment the PW with a CW is a unifying agent that will work in both T= P domains and those that employ ECMP and LAG. The GAL/ACh version cannot ma= ke this claim. What would be required to make this acceptable IMO would be agreement with = the MPLS WG to produce an RFC that documented excluding reserved labels fro= m ECMP consideration such that GAL/GACh encapsulated PW OAM had "feature pa= rity" with ACh encapsulated PW-OAM... Then we could reasonably consider taking steps to move to a common OAM enca= psulation mechanism common to LSPs and PWs. My 2 cents Dave _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_60C093A41B5E45409A19D42CF7786DFD521B61CAF1EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I did read it and given this extract from the docu= ment am=20 wondering what part I missed?

   Therefore, this document speci= fies that=20 the GAL can be used with
   packets on a G-ACh on LSPs,=20 Concatenated Segments of LSPs, Sections,
   and PWs in both MP= LS=20 and MPLS-TP environments without discrimination.
 
I would argue that using the GAL for PWs in any en= vironment=20 is a mistake, and this is not the only symptom of the problem... The fix to= 5586=20 should be to PLACE a restiction on the use of the GAL on PWs in MPLS=20 environments...not eliminate the restriction in TP=20 environments.
 
I hope that is clearer.
 
cheers
Dave
From: Luca = Martini=20 [mailto:lmartini@cisco.com]
Sent: Friday, June 17, 2011 2:38=20 PM
To: David Allan I
Cc: pwe3@ietf.org
Subject:=20 Re: [PWE3] WG LC on=20 draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt

Dave,
And everybody else.

Thanks you for your=20 support!
Since this document does not describe anything of what you ment= ioned=20 below,
you must be a supporter !

Please read the document=20 .

Thank you.
Luca


On 06/09/2011 04:43 PM, David Allan = I=20 wrote:=20 
I'm opposed to this draft progressing at this =
time.

At the moment the PW with a CW is a unifying agent that will work in both T=
P domains and those that employ ECMP and LAG. The GAL/ACh version cannot ma=
ke this claim.

What would be required to make this acceptable IMO would be agreement with =
the MPLS WG to produce an RFC that documented excluding reserved labels fro=
m ECMP consideration such that GAL/GACh encapsulated PW OAM had "feature pa=
rity" with ACh encapsulated PW-OAM...

Then we could reasonably consider taking steps to move to a common OAM enca=
psulation mechanism common to LSPs and PWs.

My 2 cents
Dave




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

--_000_60C093A41B5E45409A19D42CF7786DFD521B61CAF1EUSAACMS0703e_-- From Alexander.Vainshtein@ecitele.com Sat Jun 18 08:08:49 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEF011E80FF for ; Sat, 18 Jun 2011 08:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgEcl4aTSKMV for ; Sat, 18 Jun 2011 08:08:48 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 37D7D11E809F for ; Sat, 18 Jun 2011 08:08:46 -0700 (PDT) X-AuditID: 93eaf2e7-b7c2dae0000028e9-9d-4dfcbf76ae15 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id C8.85.10473.67FBCFD4; Sat, 18 Jun 2011 18:08:38 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sat, 18 Jun 2011 18:08:45 +0300 From: Alexander Vainshtein To: David Allan I Date: Sat, 18 Jun 2011 18:07:59 +0300 Thread-Topic: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Thread-Index: AcwtNxa2EnOZRZPoTTmUbPrDv1VtmwAAE/cQACSHB2c= Message-ID: References: <60C093A41B5E45409A19D42CF7786DFD521B518CF3@EUSAACMS0703.eamcs.ericsson.se> <4DFBC94B.9010801@cisco.com>, <60C093A41B5E45409A19D42CF7786DFD521B61CAF1@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD521B61CAF1@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97DILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTm7syuozk1rq3ezGi8Pahsxc2i7bFmPxKDloSCQoIaZ6+7Q7uz y84kGURG9DKIHmqmhgpiL0MMoSjZcisiISsoSrNISiStIEks17Q7TpkQ3V/fPd93vnPu5RyG Mh+LSmIkWcVBWfAiUwx9tn/wm7Xwzqgzvepwqr3nyQ3K3tf9M8p+crCFzqJySiPNxpyRoRem nPr6H4ZcKq8YrBVk2a8KKuZdWBEdKDcoFQpiEeIllwPZEB/wCiL2YVl1ICEQwLILZcbw/5y1 RCbJPJZFv0uS3Q60cctmq92+YpXVhjIXzrNlrInZ6pEUHlt9guTlfVhRBDfmSWRXC+UpK/9M B0KOvY/PfzYVg8blJSCagdxyeOpkBa3jBPj0bZOpBMQwZu42gN0Xm6L0SzmAw7WjEyoT54DX r74xaXgmlwYbn0WMGqa4bHjh4J2JOM0tgOGSIaDheG4D/PkwZNT12fBWWwvxYQheDe91ylqY 5TbDE4frDHqtMIBNnUcmfKK57fDGm9cTPoB0N9zeaNBrJcKuDzUGvWsO1rc+oXRsgR/fjxl1 vQV2H20Cut4PG6rvGvVicfDR+Q+/XzwLtl16RZ8CCZVTbCunpFROSdHjafBVWalJx6mwoW6A 0rEVVoyF6anxWhB1BVgkb0DN97nTbWlYlFTsxWmi33cd6GPUdxOM1MwPA44BKJbddSjiNBuF QqXIFwazGAOysJdDo07z9Hy/q8gjKJ6dwT1erJAfYig0k02pJhzrEor24aD/D7WB/P5pKmma 6CcDK6s7M9LT/39BiWyv+Mlp5txkNHdjHMDBPz7JDIMgm0KG3BwXxG68t0Dyqn9pAxOttRFL 2ojTNKwSEHyK5Nb5dpCSlMg+0HrnNMKzR57M1RbowPj4eD9IJI+OZ+s1VSxZr8nsfmJsIMZj IyOaMVmbSSqpGHwZGIy7OuB2hN5xIXRusdNyICOSW/D92vHnm5qjq1aub+ntmBvhXvdRJULZ wWR2/4uvX5cxYF9HyjmuOSuboZfO7jaeFU/01Kpj/Sh0f/a26hnFrty6HndWV+3TzIsV6/xz 7uft2MpXfXqe3PZS2tS2vrz1cvLRgNpxpr10UbAB0YpHsC2hgorwC+UQxXgbBAAA Cc: Luca Martini , "pwe3@ietf.org" Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 15:08:49 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97DILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Dave, Lots of thanks - I could not say it any better even if I have tried. Regards, Sasha ________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of David Allan= I [david.i.allan@ericsson.com] Sent: Saturday, June 18, 2011 12:45 AM To: Luca Martini Cc: pwe3@ietf.org Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt I did read it and given this extract from the document am wondering what par= t I missed? Therefore, this document specifies that the GAL can be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, Sections, and PWs in both MPLS and MPLS-TP environments without discrimination. I would argue that using the GAL for PWs in any environment is a mistake, an= d this is not the only symptom of the problem... The fix to 5586 should be t= o PLACE a restiction on the use of the GAL on PWs in MPLS environments...not= eliminate the restriction in TP environments. I hope that is clearer. cheers Dave ________________________________ From: Luca Martini [mailto:lmartini@cisco.com] Sent: Friday, June 17, 2011 2:38 PM To: David Allan I Cc: pwe3@ietf.org Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Dave, And everybody else. Thanks you for your support! Since this document does not describe anything of what you mentioned below, you must be a supporter ! Please read the document . Thank you. Luca On 06/09/2011 04:43 PM, David Allan I wrote: I'm opposed to this draft progressing at this time. At the moment the PW with a CW is a unifying agent that will work in both TP= domains and those that employ ECMP and LAG. The GAL/ACh version cannot make= this claim. What would be required to make this acceptable IMO would be agreement with t= he MPLS WG to produce an RFC that documented excluding reserved labels from= ECMP consideration such that GAL/GACh encapsulated PW OAM had "feature pari= ty" with ACh encapsulated PW-OAM... Then we could reasonably consider taking steps to move to a common OAM encap= sulation mechanism common to LSPs and PWs. My 2 cents Dave _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97DILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Dave,
Lots of thanks - I could not say it any= better even if I have tried.
 
Regards,
     Sasha
 
From: pwe3-bounces= @ietf.org [pwe3-bounces@ietf.org] On Behalf Of David Allan I [david.i.allan@= ericsson.com]
Sent: Saturday, June 18, 2011 12:45 AM
To: Luca Martini
Cc: pwe3@ietf.org
Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt=

I did read it and given this extrac= t from the document am wondering what part I missed?

   Therefore, this document specifies that the GAL can be used wit= h
   packets on a G-ACh on LSPs, Concatenated Segments of LSPs, Sect= ions,
   and PWs in both MPLS and MPLS-TP environments without discrimin= ation.
 
I would argue that using the= GAL for PWs in any environment is a mistake, and this is not the only sympt= om of the problem... The fix to 5586 should be to PLACE a restiction on the use of the GAL on PWs in MPLS environments.= ..not eliminate the restriction in TP environments.
 
I hope that is clearer.
 
cheers
Dave
From: Luca Martini [mailto:lmartini@cisco.com]
Sent: Friday, June 17, 2011 2:38 PM
To: David Allan I
Cc: pwe3@ietf.org
Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt=

Dave,
And everybody else.

Thanks you for your support!
Since this document does not describe anything of what you mentioned below,=
you must be a supporter !

Please read the document .

Thank you.
Luca


On 06/09/2011 04:43 PM, David Allan I wrote: 
I'm opposed to this draft progressing at this time.

At the moment the PW with a CW is a unifying agent that will work in both TP=
 domains and those that employ ECMP and LAG. The GAL/ACh version cannot make=
 this claim.

What would be required to make this acceptable IMO would be agreement with t=
he MPLS WG to produce an RFC that documented excluding reserved labels from=
 ECMP consideration such that GAL/GACh encapsulated PW OAM had "feature=
 parity" with ACh encapsulated PW-OAM...

Then we could reasonably consider taking steps to move to a common OAM encap=
sulation mechanism common to LSPs and PWs.

My 2 cents
Dave




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

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97DILPTMAIL02eci_-- From Alexander.Vainshtein@ecitele.com Sat Jun 18 08:42:52 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4F211E818A; Sat, 18 Jun 2011 08:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ2B9CVtCQmB; Sat, 18 Jun 2011 08:42:51 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id CDEA811E816C; Sat, 18 Jun 2011 08:42:50 -0700 (PDT) X-AuditID: 93eaf2e7-b7c2dae0000028e9-9d-4dfcc7711943 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id 0D.B5.10473.177CCFD4; Sat, 18 Jun 2011 18:42:41 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sat, 18 Jun 2011 18:42:48 +0300 From: Alexander Vainshtein To: "yaacov.weingarten@nsn.com" , "annamaria.fulignoli@ericsson.com" Date: Sat, 18 Jun 2011 18:42:46 +0300 Thread-Topic: 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? Thread-Index: AQHMLc5fhdiAGpqKu0G7uB0M08zc9w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97EILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTa0gUURTHuTvj7rg5MW5r3kRiu72g2s3FgrFaiSTQSCwqe5KOu7fdqdnZ bWcL1w9l2QM07OEqJZI9trDMRBNKK6qNXgb2IKHUSiiL7PEhilqrtRmHTIjup//5n98953C5 hyIMlbokihf92CdyAtLqyYr+z1/Mm+/8zE7Z25bKnu97o2F31lwAbNepMzFs98uLOrb8cwvJ dvTVALbp8hHtfF1m8EdTTObA105tZigU0WRGGjt1S8g1xWAeJ4oeP+fHJgeW7Da0xMdv5ewB ZOIdNmRFJq/A2bEbi34b4rxeLDpQut70z5knY7xowqLd4+BFpw1lLcsxs+zsNLMVpU+ZaE2d q1/u4iUTNrs5XjC5sSRxTmySnfwWwhVuK/BGFhZWBC8RxeDWnFIQS0FmFuz4dAWoeix8+KJR Wwr0lIFpBTB6/Z5ODYIAHnrWTiqUlrHB5vrnQ5SR2QVga8cFjRIQzD4SVtXfIhSKZCbDUEP9 UN0xzFJYMliqVbSRyYWRtyd1qrbAaNdJ2acomsmBJ/pWKzaQx/jWfk6jaIJJhF2vazXqeAwM XXlAqDoBvnsVjVH5BNiztxGovAfuKSsb8mkmHt478ppU+XHwRt1T8gAwVo8oWz3iSvWIK6pv gU8rg1pVT4enj78nVG2Gh6NhcqR/DOjOggRe8PoL3M4UqwXbeT8WsMXucTcD9R+9vQQGaieF AUMBFEfnl/zINsRwW6WAOwzGURqUQNfe/pltGF3gcQRcnOTK820RsBQGkCKQkZ5QI+doBxco wj7Pn9RC+ZEPEkmj7B75x4r+vNSUlP8HKJHus3/INjBO+QtuwtiLfX/qJFMUgnSP0j7eh524 cAMv+P+mNVSsMkacPMYKhaElL+eWeKeabwdm6kTDuzAwkKJHxEmJdJYCMQrk2iIO11G2afvg 4GA/SJQfYAxdrVBx8q4NV+qXm2jkJtGBAaWJvCrDqaRigDLKd/xq2N+2w1jVfTTrqhisuFlW uc5xeNHjort1ya29Tz5lpNvur390Xj9+/tpmy+qIq3PWpJbRG+PnCItnzsgITP0Qdy43Oe1Z bGlayfebebPT0lt7mkP524pcGwo/wpfXJuRsq2pahV7xd2p6heuXF5zdvXE8CK0s7/76eOXi wO1eREouzjqN8Encb6nSqMEoBAAA Cc: "mpls@ietf.org" , "eosborne@cisco.com" , Vladimir Kleiner , Andrew Sergeev , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen , Robert Rennison , "Stewart Bryant \(stbryant@cisco.com\)" Subject: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 15:42:52 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97EILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi all, I would highly appreciate some clarification on the following issue: Is 1+1 linear protection architecture for LSPs compatible with the MPLS-TP d= ata plane? We have been recently reminded by Daniel Cohn that 1+1 protection has been d= eclared as MUST to support for MPLS-TP in RFC 5654 (Req. #65). What's more,= Req. #65-B states that it MUST be supported in the unidirectional mode for= P2P connectivity. The problematic use case from my point of view is PW traffic carried within= a 1+1-protected LSP between a pair of PEs. To the best of my understanding, unidirectional 1+1 linear protection, in it= s absolutely minimal form, would imply that: 1. Some form of proactive connectivity check (CC) would be applied to both Wor= king (W) and Protection (P) LSPs. It is my understanding that the GAL/G-ACH= mechanism would be used as the encapsulation for the CC packets 2. Based on the results of CC, one of the incoming LSPs would be selected as Ac= tive 3. When in comes to PW client traffic in these LSPs: * In the Tx direction: * Each PW packet would be replicated and forwarded thru both W and P LSPs * Replication would leave the PW label (and everything after this label) the= same for both copies, so that only Tunnel labels and accompanying linke lay= er encapsulations would be different * In the Rx direction: * Both W and P LSPs would be terminated, i.e., their labels would be popped an= d, if the resulting packets are still labeled, the next label looked up * PW packets received from the Active LSP would be forwarded to the= appropriate PW Forwarder, and PW packets received from the inactive LSP wou= ld be silently discarded If this understanding is correct, this would mean that treatment of the rece= ived PW labels would depend on the specific terminated LSP from which the pa= ckets labeled with those have been received. In principle, this would be pos= sible if we would treat these LSPs and interfaces and allocate PW labels fro= m the per-interface space(even this would be non-trivial, because there is n= o way to guarantee that the same label value has simiilar meaning in differe= nt label spaces). But, as per RFC 4447, PW labels MUST be allocated from th= e per-platform label space. And of course, simply discarding all the packets received from the inactive= LSP would not do because this would affect CC operation. Did I miss something substantial in my analysis? Please note also that 1:1 protection could rely on the remote Tx endpoint on= ly sending packets to the (common) Active LSP making life simpler (no real n= eed for selection on the Rx side). I understand that draft-ietf-mpls-tp-linear-protection is in the final stage= s of the WG discussion, and apologize for raising this question so late. But= late is (sometimes) better than never... Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97EILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Hi all,
I would highly appreciate so= me clarification on the following issue:
Is 1+1 linear protection= architecture for LSPs compatible with the MPLS-TP data plane?
We have been recently remind= ed by Daniel Cohn that 1+1 protection has been declared as MUST to suppo= rt for MPLS-TP in RFC 5654 (Req. #65). What's more, Req. #65-B states that i= t MUST be supported in the unidirectional mode for P2P connectivity.
 
The problematic use case fro= m my point of view is PW traffic carried within a 1+1-protected LSP betw= een a pair of PEs.
 
To the best of my understand= ing, unidirectional 1+1 linear protection, in its absolutely m= inimal form, would imply that:
  1. Some form of proactive connectivity chec= k (CC) would be applied to both  Working (W) and Protection= (P) LSPs. It is my understanding that= the GAL/G-ACH mechanism would be used as the encapsulation for the CC packets
  2. Based on the results of CC, one of the i= ncoming LSPs would be selected as Active
  3. When in comes to PW client traffic<= a> in these LSPs:
    • In the Tx direction:<= /font>
      • Each PW packet would be replicated and f= orwarded thru both W and P LSPs
      •  Replication would leave the PW lab= el (and everything after this label) the same for both copies, so that only= Tunnel labels and accompanying linke layer encapsulation= s would be different
    • In the Rx direction:
      • Both W an= d P LSPs would be terminated, i.e., their labels would be popped and,= if the resulting packets are still labeled, the next label looked up=
      • PW packets received from the Active= LSP would be forwarded to the appropriate PW Forwarder, and PW packe= ts received from the inactive LSP would be silently discarded<= /li>

If this understanding is correct, this wou= ld mean that treatment of the received PW labels would depend on the specifi= c terminated LSP from which the packets labeled with those have been receive= d. In principle, this would be possible if we would treat these LSPs and interfaces and allocate PW labels= from the per-interface space(even this would be non-triv= ial, because there is no way to guarantee that the same label value has = ;simiilar meaning in different label spaces).  But, as per RFC 4447, PW labels MUST be allocated from the p= er-platform label space.

And of course, simply discarding all the p= ackets received from the inactive LSP would not do because this would affect= CC operation.

 

Did I miss something substantial in my ana= lysis?

 

Please note also that 1:1 protection could= rely on the remote Tx endpoint only sending packets to the (common)= Active LSP making life simpler (no real need for selection on the Rx side).=

 

I understand that draft-ietf= -mpls-tp-linear-protection is in the final stage= s of the WG discussion, and apologize for raising this question so late. But= late is (sometimes) better than never...

 

Regards,

     Sasha

 

 

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97EILPTMAIL02eci_-- From gregimirsky@gmail.com Sat Jun 18 09:17:03 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B6411E81C4; Sat, 18 Jun 2011 09:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-y9L6AFqsZC; Sat, 18 Jun 2011 09:17:02 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0F511E81A2; Sat, 18 Jun 2011 09:17:02 -0700 (PDT) Received: by vws12 with SMTP id 12so3259936vws.31 for ; Sat, 18 Jun 2011 09:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Q4HRkwglnOtEjiNSVwsXD94WSp3uddTg86UtmKJa9pQ=; b=PCwY6hpVZ9BX+m68kr0mQL7iEVs6ZXZo0VOqhDbCSyeTY0hHCs3cdWcN8zNEa+7eZC AtesZhNSrJqq3VsyA84PtOM9Gv8FvPCgW7sSZgZCnd/4i9gkK+sUa6HVNButmH1XHzdK 5XnDpLQ7EtrKYrhD1zoJOoiP2M3UutZdDp8tU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=p8JUOZxwFYmpAlxZIP7IAxredeJiDwdmCB9BOSoH/+nrMewuiz9ocvUdfwtK4FmYvl AtLbe6ks8EsMqTPB17lYrx9eNcXj3iT8er9PDrGSPVDiH4jOiZ2vrX7ZLB/rfx6ADZkS qXC8lNbkynf63kvpVloRO6B6xaSaMEsCOKKlk= MIME-Version: 1.0 Received: by 10.52.162.72 with SMTP id xy8mr4871685vdb.87.1308413821755; Sat, 18 Jun 2011 09:17:01 -0700 (PDT) Received: by 10.52.160.67 with HTTP; Sat, 18 Jun 2011 09:17:01 -0700 (PDT) In-Reply-To: References: Date: Sat, 18 Jun 2011 09:17:01 -0700 Message-ID: From: Greg Mirsky To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=bcaec53f95dd10a42304a5fed5ec Cc: "mpls@ietf.org" , "eosborne@cisco.com" , Vladimir Kleiner , Andrew Sergeev , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant@cisco.com\)" , Robert Rennison , Rotem Cohen Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 16:17:04 -0000 --bcaec53f95dd10a42304a5fed5ec Content-Type: text/plain; charset=ISO-8859-1 Dear Sasha, I think that there is one assumption in line of your logic that changes the result. When we consider 1+1 LSP protection sink discards traffic from one source on LSP level. As result there should not be issue with Rx on PW client traffic since sink receives PW packets only from Active LSP and PW packets from Inactive LSP would never be seen. If we consider 1:1 PW protection, then, as I imagine, we have redundant PW and thus PW labels are different. Then the sink selects one of PWs as active but there should be no issue with PW labels. Please let me know if understood scenarios correctly. Kind regards, Greg On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Hi all, > I would highly appreciate some clarification on the following issue: > > Is 1+1 linear protection architecture for LSPs compatible with the MPLS-TP > data plane? > > We have been recently reminded by Daniel Cohn that 1+1 protection has been > declared as MUST to support for MPLS-TP in RFC 5654 (Req. #65). What's more, > Req. #65-B states that it MUST be supported in the unidirectional mode for > P2P connectivity. > > The problematic use case from my point of view is PW traffic carried within > a 1+1-protected LSP between a pair of PEs. > > To the best of my understanding, unidirectional 1+1 linear protection, in > its absolutely minimal form, would imply that: > > 1. Some form of proactive connectivity check (CC) would be applied > to both Working (W) and Protection (P) LSPs. It is my understanding > that the GAL/G-ACH mechanism would be used as the encapsulation for the > CC packets > 2. Based on the results of CC, one of the incoming LSPs would be > selected as Active > 3. When in comes to PW client traffic in these LSPs: > - In the Tx direction: > - Each PW packet would be replicated and forwarded thru both W and > P LSPs > - Replication would leave the PW label (and everything after > this label) the same for both copies, so that only Tunnel labels and > accompanying linke layer encapsulations would be different > - In the Rx direction: > - Both W and P LSPs would be terminated, i.e., their labels would > be popped and, if the resulting packets are still labeled, the next label > looked up > - PW packets received from the Active LSP would be forwarded to > the appropriate PW Forwarder, and PW packets received from the > inactive LSP would be silently discarded > > If this understanding is correct, this would mean that treatment of the > received PW labels would depend on the specific terminated LSP from which > the packets labeled with those have been received. In principle, this would > be possible if we would treat these LSPs and interfaces and allocate PW > labels from the per-interface space(even this would be non-trivial, > because there is no way to guarantee that the same label value has simiilarmeaning in different label spaces). But, as per RFC 4447, PW labels MUST be > allocated from the per-platform label space. > > And of course, simply discarding all the packets received from the inactive > LSP would not do because this would affect CC operation. > > > > Did I miss something substantial in my analysis? > > > > Please note also that 1:1 protection could rely on the remote Tx endpoint > only sending packets to the (common) Active LSP making life simpler (no real > need for selection on the Rx side). > > > > I understand that draft-ietf-mpls-tp-linear-protection is in the final > stages of the WG discussion, and apologize for raising this question so > late. But late is (sometimes) better than never... > > > > Regards, > > Sasha > > > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --bcaec53f95dd10a42304a5fed5ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sasha,
I think that there is one assumption in line of your logic t= hat changes the result.
When we consider 1+1 LSP protection sink discard= s traffic from one source on LSP level. As result there should not be issue= with Rx on PW client traffic since sink receives PW packets only from Acti= ve LSP and PW packets from Inactive LSP would never be seen.
If we consider 1:1 PW protection, then, as I imagine, we have redundant PW = and thus PW labels are different. Then the sink selects one of PWs as activ= e but there should be no issue with PW labels.

Please let me know if= understood scenarios correctly.

Kind regards,
Greg

On Sat, Jun 18,= 2011 at 8:42 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com&= gt; wrote:
Hi all,
I would highly appreciate s= ome clarification on the following issue:
Is 1+1 linear protection ar= chitecture for LSPs compatible with the MPLS-TP data plane?
We have been recently remin= ded by Daniel Cohn that 1+1 protection has been declared as MUST to support= for MPLS-TP in RFC 5654 (Req. #65). What's more, Req. #65-B states tha= t it MUST be supported in=A0the unidirectional mode for P2P connectivity.
=A0
The problematic use case fr= om my point of view is PW traffic carried within a 1+1-protected LSP betwee= n a=A0pair of PEs.
=A0
To the best of my understan= ding, unidirectional=A01+1 linear protection,=A0in its absolutely minimal f= orm,=A0would imply that:
  1. Some form of proactive connectivity che= ck (CC) would be applied to=A0both=A0 Working (W) and Protection (P)= LSPs. It is my understanding that th= e GAL/G-ACH mechanism would=A0be used=A0as the encapsulation for the CC packets
  2. Based on the results of CC, one of the = incoming LSPs would be selected as Active
  3. When in comes to PW client=A0traffic= in these LSPs:
    • In the=A0Tx direction:
      • Each PW packet would be replicated and = forwarded thru both W and P LSPs
      • =A0Replication would leave the PW label= (and everything after this label) the same for both copies, so that only T= unnel labels and accompanying=A0linke layer encapsulations wo= uld be different
    • In the Rx direction:
      • Both W a= nd P LSPs would be terminated, i.e., their labels would be popped an= d, if the resulting packets are still labeled, the next label looked up
      • PW packets received from the Active= LSP would be forwarded to the appropriate PW Forwarder, and PW pack= ets received from the inactive LSP would be silently discarded

If this understanding is correct, this wo= uld mean that treatment of the received PW labels would depend on the speci= fic terminated LSP from which the packets labeled with those have been rece= ived. In principle, this would be possible if we would treat these LSPs and interfaces and allocate PW label= s from=A0the per-interface space(even this would be non-trivi= al, because there is no way to guarantee that the same label value has=A0si= miilar meaning in different label spaces). =A0But, as per RFC 4447, PW labels MUST be allocated from the per= -platform label space.

And of course, simply discarding all the = packets received from the inactive LSP would not do because this would affe= ct CC operation.

=A0

Did I miss something substantial in my an= alysis?

=A0

Please note also that 1:1 protection coul= d rely on the remote Tx endpoint only sending packets to the (common= ) Active LSP making life simpler (no real need for selection on the Rx side= ).

=A0

I understand that draft-ietf-mpls-tp-linear-protection is in the final sta= ges of the WG discussion, and apologize for raising this question so late. = But late is (sometimes) better than never...

=A0

Regards,

=A0=A0=A0=A0 Sasha

=A0

=A0

This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


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


--bcaec53f95dd10a42304a5fed5ec-- From lmartini@cisco.com Sat Jun 18 11:09:28 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA539E8005 for ; Sat, 18 Jun 2011 11:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6mvblt0v2ku for ; Sat, 18 Jun 2011 11:09:27 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id B4D4B9E8021 for ; Sat, 18 Jun 2011 11:09:27 -0700 (PDT) Received: from seven.monoski.com (host721710020496.direcway.com [72.171.96.204] (may be forged)) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p5II94Ns003858 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 18 Jun 2011 12:09:16 -0600 (MDT) Message-ID: <4DFCE9BB.40704@cisco.com> Date: Sat, 18 Jun 2011 12:08:59 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: David Allan I References: <60C093A41B5E45409A19D42CF7786DFD521B518CF3@EUSAACMS0703.eamcs.ericsson.se> <4DFBC94B.9010801@cisco.com> <60C093A41B5E45409A19D42CF7786DFD521B61CAF1@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD521B61CAF1@EUSAACMS0703.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 18:09:28 -0000 Alan, Thanks for the clarification. Indeed we have totally opposite views. Luca On 06/17/2011 03:45 PM, David Allan I wrote: > I did read it and given this extract from the document am wondering what part I missed? > > Therefore, this document specifies that the GAL can be used with > packets on a G-ACh on LSPs, Concatenated Segments of LSPs, Sections, > and PWs in both MPLS and MPLS-TP environments without discrimination. > > I would argue that using the GAL for PWs in any environment is a mistake, and this is not the only symptom of the problem... The fix to 5586 should be to PLACE a restiction on the use of the GAL on PWs in MPLS environments...not eliminate the restriction in TP environments. > > I hope that is clearer. > > cheers > Dave > ________________________________ > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Friday, June 17, 2011 2:38 PM > To: David Allan I > Cc: pwe3@ietf.org > Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt > > Dave, > And everybody else. > > Thanks you for your support! > Since this document does not describe anything of what you mentioned below, > you must be a supporter ! > > Please read the document . > > Thank you. > Luca > > > On 06/09/2011 04:43 PM, David Allan I wrote: > > I'm opposed to this draft progressing at this time. > > At the moment the PW with a CW is a unifying agent that will work in both TP domains and those that employ ECMP and LAG. The GAL/ACh version cannot make this claim. > > What would be required to make this acceptable IMO would be agreement with the MPLS WG to produce an RFC that documented excluding reserved labels from ECMP consideration such that GAL/GACh encapsulated PW OAM had "feature parity" with ACh encapsulated PW-OAM... > > Then we could reasonably consider taking steps to move to a common OAM encapsulation mechanism common to LSPs and PWs. > > My 2 cents > Dave > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > From Alexander.Vainshtein@ecitele.com Sat Jun 18 12:02:27 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6412511E81FC; Sat, 18 Jun 2011 12:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nljVXDvZ88+C; Sat, 18 Jun 2011 12:02:26 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3487411E81FB; Sat, 18 Jun 2011 12:02:24 -0700 (PDT) X-AuditID: 93eaf2e7-b7c2dae0000028e9-2c-4dfcf63853d3 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id B6.F6.10473.836FCFD4; Sat, 18 Jun 2011 22:02:16 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sat, 18 Jun 2011 22:02:22 +0300 From: Alexander Vainshtein To: Greg Mirsky Date: Sat, 18 Jun 2011 21:58:41 +0300 Thread-Topic: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? Thread-Index: Acwt0ynNZ3JEDsDySsWhgBj3eR20rgAFpOiu Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97FILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLsWRmVeSWpSXmKPExsUy+dWnL7oW3/74GvzaIWux7ukzJoumOZsZ Lb5Ne8pqcWvpSlaLvk9bWCzOPZ3DaLFx90w2B3aPKb83snr8+nqVzWPnrLvsHkuW/GTy+Ln+ KnsAa1QDo01iXl5+SWJJqkJKanGyrVJAUWZZYnKlkkJmiq2SoZJCQU5icmpual6JrVJiQUFq XoqSHZcCBrABKsvMU0jNS85PycxLt1XyDPbXtbAwtdQ1VLJTUzY0tuYKycgsVkjVzU3MzFHI TS0uTkxPVQCKJGxhzjhzwrPgdFHFq65vzA2M0xO6GDk5JARMJGZcOcsIYYtJXLi3nq2LkYtD SGA3o0T73+1MEM40Rom599awglSxCdhKbFp9lw3EFhFQl+jcdpwdpIhZ4DaLxKzHt9lBEiwC qhLfd5wE6ubgEBaIkXjeJAdRHysx+1UHI4RtJHH1xkKwmbwC/hJ3nn+G2tzCKPF+xVOwIk4B R4nTc/aygNiMQOd9P7WGCcRmFhCXuPVkPhPE2QISS/acZ4awRSVePv7HClEvKnGnfT0jRH2+ xMOLU6CWCUqcnPmEBaJeUuLgihssExjFZiEZOwtJyywkLRBxPYkbU6ewQdjaEssWvmaGsHUl Zvw7xIIsvoCRfRWjaGZOQUlSbrqBoV5qcmZJak6qXnJ+7iZGSCJ7voPx13yVQ4wCHIxKPLwJ zb99hVgTy4orcw8xSnIwKYnyTvz6x1eILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK/iHKAcb0pi ZVVqUT5MyhUY+hOZpbiT84HJOa8k3tjAADdHSZz3afIbXyGBdGDSzE5NLUgtgpkjw8GhJME7 AWS9YFFqempFWmZOCUKaiYMT5AweoDM4QGp4iwsSc4sz0yHypxiNORatfXmIkWPZ7DeHGIVY 8vLzUqXEeXVBSgVASjNK8+CmgTJc/f///18xigODQZi3EaSKB5gd4ea9AlrFBLTq369fIKuA GQkuJdXAOOnVHDbbx/y6kSdSOTYcOPjg8N/Loryndi43WDbd/dgxQ/5NESsPO6/4eUWv/c/f iIuy+i8+2T03Fn/fEF349tayt2Yfnp2t+fhPqtml5+7xYE+/iLidKzx59Fs3Gx7zL5mqe+rC 6rzUv5Ea0l8WNy8IEFSTEZ13zF2I4VtLlNLWYF57ya8LnZVYijMSDbWYi4oTAUaOe95LBAAA Cc: "mpls@ietf.org" , "eosborne@cisco.com" , Vladimir Kleiner , Andrew Sergeev , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant@cisco.com\)" , Robert Rennison , Rotem Cohen Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 19:02:27 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97FILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Dear Greg, Lots of thanks for a prompt response. However, I disagree with your conclusion: if you discard the traffic at the= LSP level (i.e. based on the incoming tunnel label), you would also discard= CC and PSC traffic: at this level they are undistinguishable from the PW tr= affic. The situation with the PW protection will be indeed different because Workin= g and Protection PWs would use different PW labels. Hopefully this clarifies my point. Regards, Sasha ________________________________ From: Greg Mirsky [gregimirsky@gmail.com] Sent: Saturday, June 18, 2011 7:17 PM To: Alexander Vainshtein Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; mpls@ietf.o= rg; eosborne@cisco.com; Vladimir Kleiner; Andrew Sergeev; Mishael Wexler; pw= e3; Oren Gal; John Shirron; Rotem Cohen; Robert Rennison; Stewart Bryant (st= bryant@cisco.com) Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are th= ey compatible? Dear Sasha, I think that there is one assumption in line of your logic that changes the= result. When we consider 1+1 LSP protection sink discards traffic from one source on= LSP level. As result there should not be issue with Rx on PW client traffic= since sink receives PW packets only from Active LSP and PW packets from Ina= ctive LSP would never be seen. If we consider 1:1 PW protection, then, as I imagine, we have redundant PW a= nd thus PW labels are different. Then the sink selects one of PWs as active= but there should be no issue with PW labels. Please let me know if understood scenarios correctly. Kind regards, Greg On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainshtein > wrote: Hi all, I would highly appreciate some clarification on the following issue: Is 1+1 linear protection architecture for LSPs compatible with the MPLS-TP d= ata plane? We have been recently reminded by Daniel Cohn that 1+1 protection has been d= eclared as MUST to support for MPLS-TP in RFC 5654 (Req. #65). What's more,= Req. #65-B states that it MUST be supported in the unidirectional mode for= P2P connectivity. The problematic use case from my point of view is PW traffic carried within= a 1+1-protected LSP between a pair of PEs. To the best of my understanding, unidirectional 1+1 linear protection, in it= s absolutely minimal form, would imply that: 1. Some form of proactive connectivity check (CC) would be applied to both Wor= king (W) and Protection (P) LSPs. It is my understanding that the GAL/G-ACH= mechanism would be used as the encapsulation for the CC packets 2. Based on the results of CC, one of the incoming LSPs would be selected as Ac= tive 3. When in comes to PW client traffic in these LSPs: * In the Tx direction: * Each PW packet would be replicated and forwarded thru both W and P LSPs * Replication would leave the PW label (and everything after this label) the= same for both copies, so that only Tunnel labels and accompanying linke lay= er encapsulations would be different * In the Rx direction: * Both W and P LSPs would be terminated, i.e., their labels would be popped an= d, if the resulting packets are still labeled, the next label looked up * PW packets received from the Active LSP would be forwarded to the= appropriate PW Forwarder, and PW packets received from the inactive LSP wou= ld be silently discarded If this understanding is correct, this would mean that treatment of the rece= ived PW labels would depend on the specific terminated LSP from which the pa= ckets labeled with those have been received. In principle, this would be pos= sible if we would treat these LSPs and interfaces and allocate PW labels fro= m the per-interface space(even this would be non-trivial, because there is n= o way to guarantee that the same label value has simiilar meaning in differe= nt label spaces). But, as per RFC 4447, PW labels MUST be allocated from th= e per-platform label space. And of course, simply discarding all the packets received from the inactive= LSP would not do because this would affect CC operation. Did I miss something substantial in my analysis? Please note also that 1:1 protection could rely on the remote Tx endpoint on= ly sending packets to the (common) Active LSP making life simpler (no real n= eed for selection on the Rx side). I understand that draft-ietf-mpls-tp-linear-protection is in the final stage= s of the WG discussion, and apologize for raising this question so late. But= late is (sometimes) better than never... Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97FILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Dear Greg,
Lots of thanks for a prompt response.
 
However, I disagree with your conclusion= : if you discard the traffic at the LSP level (i.e. based on the incoming tu= nnel label), you would also discard CC and PSC traffic: at this level they a= re undistinguishable from the PW traffic.
The situation with the PW protection will be indeed different because W= orking and Protection PWs would use different PW labels.
 
Hopefully this clarifies my point.
Regards,
     Sasha
From: Greg Mirsky= [gregimirsky@gmail.com]
Sent: Saturday, June 18, 2011 7:17 PM
To: Alexander Vainshtein
Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; mpls= @ietf.org; eosborne@cisco.com; Vladimir Kleiner; Andrew Sergeev; Mishael Wex= ler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert Rennison; Stewart Bry= ant (stbryant@cisco.com)
Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data pl= ane: are they compatible?

Dear Sasha,
I think that there is one assumption in line of your logic that changes the= result.
When we consider 1+1 LSP protection sink discards traffic from one sourc= e on LSP level. As result there should not be issue with Rx on PW client tra= ffic since sink receives PW packets only from Active LSP and PW packets from= Inactive LSP would never be seen.
If we consider 1:1 PW protection, then, as I imagine, we have redundant PW a= nd thus PW labels are different. Then the sink selects one of PWs as active= but there should be no issue with PW labels.

Please let me know if understood scenarios correctly.

Kind regards,
Greg

On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainsh= tein <Alexander.Vainshtein= @ecitele.com> wrote:
Hi all,
I would highly appreciate so= me clarification on the following issue:
Is 1+1 linear protection= architecture for LSPs compatible with the MPLS-TP data plane?
We have been recently remind= ed by Daniel Cohn that 1+1 protection has been declared as MUST to suppo= rt for MPLS-TP in RFC 5654 (Req. #65). What's more, Req. #65-B states that i= t MUST be supported in the unidirectional mode for P2P connectivity.
 
The problematic use case fro= m my point of view is PW traffic carried within a 1+1-protected LSP betw= een a pair of PEs.
 
To the best of my understand= ing, unidirectional 1+1 linear protection, in its absolutely m= inimal form, would imply that:
  1. Some form of proactive connectivity chec= k (CC) would be applied to both  Working (W) and Protection= (P) LSPs. It is my understanding that= the GAL/G-ACH mechanism would be used as the encapsulation for the CC packets
  2. Based on the results of CC, one of the i= ncoming LSPs would be selected as Active
  3. When in comes to PW client traffic<= a> in these LSPs:
    • In the Tx direction:<= /font>
      • Each PW packet would be replicated and f= orwarded thru both W and P LSPs
      •  Replication would leave the PW lab= el (and everything after this label) the same for both copies, so that only= Tunnel labels and accompanying linke layer encapsulation= s would be different
    • In the Rx direction:
      • Both W an= d P LSPs would be terminated, i.e., their labels would be popped and,= if the resulting packets are still labeled, the next label looked up=
      • PW packets received from the Active= LSP would be forwarded to the appropriate PW Forwarder, and PW packe= ts received from the inactive LSP would be silently discarded

If this understanding is correct, this wou= ld mean that treatment of the received PW labels would depend on the specifi= c terminated LSP from which the packets labeled with those have been receive= d. In principle, this would be possible if we would treat these LSPs and interfaces and allocate PW labels= from the per-interface space(even this would be non-triv= ial, because there is no way to guarantee that the same label value has = ;simiilar meaning in different label spaces).  But, as per RFC 4447, PW labels MUST be allocated from the p= er-platform label space.

And of course, simply discarding all the p= ackets received from the inactive LSP would not do because this would affect= CC operation.

 

Did I miss something substantial in my ana= lysis?

 

Please note also that 1:1 protection could= rely on the remote Tx endpoint only sending packets to the (common)= Active LSP making life simpler (no real need for selection on the Rx side).=

 

I understand that draft-ietf= -mpls-tp-linear-protection is in the final stage= s of the WG discussion, and apologize for raising this question so late. But= late is (sometimes) better than never...

 

Regards,

     Sasha

 

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


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


This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76E9BD80C97FILPTMAIL02eci_-- From Alexander.Vainshtein@ecitele.com Sat Jun 18 21:04:50 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F22211E80BD; Sat, 18 Jun 2011 21:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-5grqlbhmcK; Sat, 18 Jun 2011 21:04:50 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id EEB8E11E80B6; Sat, 18 Jun 2011 21:04:48 -0700 (PDT) X-AuditID: 93eaf2e7-b7c82ae0000020ff-c6-4dfd7557b9bc Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id A1.D0.08447.7557DFD4; Sun, 19 Jun 2011 07:04:39 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 19 Jun 2011 07:04:46 +0300 From: Alexander Vainshtein To: "davarish@yahoo.com" , "mpls-bounces@ietf.org" , Greg Mirsky Date: Sun, 19 Jun 2011 07:04:45 +0300 Thread-Topic: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? Thread-Index: Acwt+GKfP7ICXhYOQty4JE+eqpbXyAAPF4qM Message-ID: References: , , <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry> In-Reply-To: <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTW0wTWRjOmZm2Q2XWoVp7IKjNCCS7aw31Ou5a18f6QMCIl/ggDtNjO7Gd Np1BrT5ICGgWE7O7GrLb9VqrUVEJRI0CkbRe4jYqJhAgoEYCDYK3WI0XFHCmE1mM5+k7//d9 5zvn5P9J3FRjyCEFUUZBkfMyeiNxcCT11raxYqyosD+Cs7GhKsC+q0vq2Ja2TgPbe+qsjj2Q ukSw95OHwSq989CnRp3zWviRwRmNfsSc4fANrITYVAlWcKLolzkZWV1I4h1MSVDYzvEhxiq4 HIydsQa8HI98SJQdDBcIINHFrDRav1srFJkgWpHI+12C6HYwq9cW21h2yXKbnVlZMM++6Fdj qUeQrMjm4wSv1YckiXMjq1LZcgn3NHYdMQSGpu98s69DXwmOULUgg4T0YtjdfgZoeBZ88LhB XwuMpIluAfBqrBvTNnUAXu5tTqv0tAM21T/Sq3gmXQPg/uosVYTTdzGYetdnUAmCzof9LyOY imfQ5fDiqSpMM/Cwq3JCp+GFMHnlZFpP0cXwzvh+Qkurx+Dz5r60IYMOwIGeG+lkoNzvfeJ8 uo7TFtg7eAzT7k3DaGs7rmEzHB4Y12l6M3y4rwFo+vnweEtKr+Gf4ekTz3AtOAv+988goXmz YexMD/EHsISnRISn2MNT7OEp9uOAOAfMgjcgl/vchfYFiBdk5EULeL+vCWhNNHQVjB7LiwOa BEwm9bRgrMik47ZLIV8cZJMYY6ZqZaX0Q7nfFfJwkqcsWOFFUhxAEmdmUqG1Cke5uNAuFPR/ pVjlm//Ec6bxfqVdRblsUWHhNxvGQiX550Um2q303TaEAij41ZpLkgykGtTErCByo51bBa/8 P42RGWpyppJ8QtVQUoDzSYJb4xPARkYuDMeBiRD9IsqxUDWqiFZFngpx8hx1evZMTEyMAIvy 5hmUW1VlKrM1edKIEoIpIeOjo2qIMh+TVE4lWC83J8YGS49iu2KONX1P7m05eLP01qey6mXJ V9HOPXUbPh9+kX/PYlv3Ovdfb+bWvPntZcup+Et3m7k1tKZ+6aZQTXHL75HfTjrn7C6WE4n2 vz4c2Fx1Le+Xyx3039Hq97M9Jav3+lI/yjFjdast+3bHwN3I8I650/ML+s9dfzvalmtnCMnD 2X/CgxL3BQxKDzEYBAAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [PWE3] [mpls] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 04:04:50 -0000 Shahram, The problem IMHO is in the combination of two points : - At the LSP level both LSP OAM and PW traffic look exactly the same (after= popping the Tunnel label a labeled packet remains). You can only differenti= ate between them when you look up the next label in the stack - When you look at the next label after having popped the tunnel label, PW p= ackets received from both active and inactive LSPs look exactly the same wit= h the same label from the per-platform label space. IMO this means that you cannot describe the desired behavior in the terms of= RFC 3031 and 3032. Hopefully this clarifies my question. Regards, Sasha ________________________________________ From: davarish@yahoo.com [davarish@yahoo.com] Sent: Saturday, June 18, 2011 11:43 PM To: Alexander Vainshtein; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John Sh= irron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:= are they compatible? Sasha All traffic except LSP OAM traffic from protection LSP must be discarded in= Rx. So what is the issue? Thx Shahram Sent via BlackBerry by AT&T -----Original Message----- From: Alexander Vainshtein Sender: mpls-bounces@ietf.org Date: Sat, 18 Jun 2011 21:58:41 To: Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren= Gal; John Shirron; Stewart= Bryant \(stbryant@cisco.com\); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Sun Jun 19 11:13:59 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8C011E80AB; Sun, 19 Jun 2011 11:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L18CKZ5+u1jB; Sun, 19 Jun 2011 11:13:59 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3163911E80D2; Sun, 19 Jun 2011 11:13:57 -0700 (PDT) X-AuditID: 93eaf2e7-b7c82ae0000020ff-1d-4dfe3c5da4bd Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id D2.B3.08447.D5C3EFD4; Sun, 19 Jun 2011 21:13:49 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sun, 19 Jun 2011 21:13:55 +0300 From: Alexander Vainshtein To: "davarish@yahoo.com" , "mpls-bounces@ietf.org" , Greg Mirsky Date: Sun, 19 Jun 2011 21:13:55 +0300 Thread-Topic: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? Thread-Index: Acwt+GKfP7ICXhYOQty4JE+eqpbXyAAPF4qMAB2hhpo= Message-ID: References: , , <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTf0wTVxzfu7u2R+XcUcA+ycwuNzBBV0eji6dQZrJkYVlAIpIlywy7Xh/t be216R0ETIxNh5KgYRqIy25b6GYxys9ANAGd2ayLATLdJvsVxBmjlQDGTWJYKALeccowvr8+ 730+n+/nvZfvl8RtDZYcUpQUFJZ4P2u2Ei1TM48c+4oWSwuSXZu4SxNRwM2eSJq4C9//ZuHG 2s+YuOaZswR3LfkV2GUuaZ3vM5UMqjctJfH4HFaiqpexcuKDCCjiJSmo8ApiPEgWXGx5WKzl hXqWET0u1skyIT8voACSFBfLh0JI8rDFVuaFVaTJRIlBkhD0iJLXxb5bsdvBcW/ucDjZ4o2v ObcWWvf6RJlBjgAv+pkAkmXeixjt5KOzuK+7519z6EtYd+72ZRABn2Y1gTQS0ttga/wHzMDr 4C9/95qbgJW00YMANvX/jhmbVgDPT5wz6Soz7YL9nTfNOs6iDwF4pCFDF+H0Txicmb1h0QmC zoMdCw8JHWfSbtjTHsUMgwD/iCyZDLwTDjVe1wqRJEXvhqM3HEbYPxhMnZ5fDkijy2H8645l DLTr/TfStVwHp+1w7G7b02vTMP7dz7iBs+HknUWToc+G4429wNC/DmMXZswG3gxPfTO9rKfo DDj8xV3C8K6Hl07/RRwDdnVVhLrKrq6yq6vsMUB0gGzRH1LcAW+BcwsSRAX50RYhGOgHRg9N DIBUW24C0CRg0ymfY7HUZuJr5fpAAqwnMTabKt+pHa11Bz31Pl72VYVr/EhOAEjibBa1kK9x lIev34/CwWcUp/3ycTxnjRDUulVSqrYWFDy3Ye1UUrhfaqO9Wtt9glAIhZ9ZXyFJFlJ9hVrV jDDyorpq0a/8T2Nkmp6criXbdQ0lh/iALHoNfgQ4yG+7JxPARkhBCeXYqWZdROsiX420Ukcf noNLS0tTwK69OZOSdFW6Nlorlaa0EEwLWUyl9BBtPFaonAi4V7cu+s6O1gUm7+iQ58dOt9JV bS/ero50mdtiVJybtn3+8nA0v+zh4TuWNc63XqoeU+8/qBj6+NU3Tg6knancFSt7r2X0s/ff zv3wwPza8ck527Ge1HH84obmmG/6UUMClSXbq0Yfj+dXKTX3+q5eSe+INKl5j2d/rfwzemsP 2XI9yBKyj3duwsMy/wSCHEv3FwQAAA== Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [PWE3] [mpls] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 18:14:00 -0000 Shahram, Greg and all, After some thought: One way to model selection in 1+1 linear protection architecture could be to= define a "special" internal interface in the box and to define the ILM acti= on on the tunnel label of an inactive LSP as "Pop and forward to special int= erface". The special interface then would then forward resulting labeled packets with= a reserved top label to control and discard all the rest. This behavior wou= ld not be part of "normal" MPLS data plane hence no contradictions with its= architecture. I assume that this is roughly the formal model for what Shahram and Greg hav= e said. Regards, Sasha ________________________________________ From: Alexander Vainshtein Sent: Sunday, June 19, 2011 7:04 AM To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John Sh= irron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: RE: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:= are they compatible? Shahram, The problem IMHO is in the combination of two points : - At the LSP level both LSP OAM and PW traffic look exactly the same (after= popping the Tunnel label a labeled packet remains). You can only differenti= ate between them when you look up the next label in the stack - When you look at the next label after having popped the tunnel label, PW p= ackets received from both active and inactive LSPs look exactly the same wit= h the same label from the per-platform label space. IMO this means that you cannot describe the desired behavior in the terms of= RFC 3031 and 3032. Hopefully this clarifies my question. Regards, Sasha ________________________________________ From: davarish@yahoo.com [davarish@yahoo.com] Sent: Saturday, June 18, 2011 11:43 PM To: Alexander Vainshtein; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John Sh= irron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:= are they compatible? Sasha All traffic except LSP OAM traffic from protection LSP must be discarded in= Rx. So what is the issue? Thx Shahram Sent via BlackBerry by AT&T -----Original Message----- From: Alexander Vainshtein Sender: mpls-bounces@ietf.org Date: Sat, 18 Jun 2011 21:58:41 To: Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren= Gal; John Shirron; Stewart= Bryant \(stbryant@cisco.com\); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From davarish@yahoo.com Sat Jun 18 13:50:10 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D2611E81FE for ; Sat, 18 Jun 2011 13:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx3LfRzOkMBJ for ; Sat, 18 Jun 2011 13:50:10 -0700 (PDT) Received: from smtp108-mob.biz.mail.gq1.yahoo.com (smtp108-mob.biz.mail.gq1.yahoo.com [98.136.185.199]) by ietfa.amsl.com (Postfix) with SMTP id 1847211E81F8 for ; Sat, 18 Jun 2011 13:50:10 -0700 (PDT) Received: (qmail 11300 invoked from network); 18 Jun 2011 20:43:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:Subject:To:Cc:From:Date:Content-Type:MIME-Version; b=qlDhpurPR/97BMNMREEYkqYpnI4xhEiWpK75HFvcyXU5P3lYLyJAhzpmNClj8cJ028CwBfePdC02z7zlcu96vrzEMlXg6GN7k6WYNl7sc2bSqXn+tYwj6rwHtXT3pid5OB/16486yA9xfIQAA+calFwYrEvxGsyYm+8YehHLgC4= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1308429807; bh=FNW2hzhUrGk3VCubm2OyMzjvSeQ/PyWd99JMw67MU+A=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:Subject:To:Cc:From:Date:Content-Type:MIME-Version; b=KvYnaZFslfSJ+dCcjhCc7yx89h364uEmrD2ojAPv9g1ttyJjMg5Dx6zY9Ifm95wlKWlEYEcy3pziUm0WQik1MbO7O7h9rYFpcdJFz8tzLk4/FaqlXNaovf7knSRFtAvDPAJwTTIvY58n8b1+fTqzT3lwy5qCtewRLrXXPyVAVtE= Received: from b15.c27.bise6.blackberry (davarish@74.82.86.201 with xymcookie) by smtp108-mob.biz.mail.gq1.yahoo.com with SMTP; 18 Jun 2011 13:43:26 -0700 PDT X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-YMail-OSG: 3c0T3lcVM1k0I263SuqJMGafKQexPnfdKxcPudqKk2SglfE wywmlrAmrTNmh_.UqnJoIAgOJFW80OURxlEJYkn2BLSSXiSkMe289HYELxNt G8vNZrfHPlsnK2TVO3avmriU0yZSvwktf0_R4obj9bjp7z7eBV9ahmuBecH4 tjqZ4k74DbfAcwqr6vIRBVC0FJ9Moow2kgJat.4A4eha7fCWe9CiGm6otxqF RDVpUnxDMgTS8uZ9_wUcUOdFIe2ItziaYMuPoQhpah7u.oRf5LZCuymaTWro Ns2SvwyRh7P0EcMJtC0fhmL1Seo2Nf6ipp9rZ2orSOTlNJzIgah4vBmvuQBb a_mNgoBYSbfiVIV.G_3_U52ONCGaL03fxoktr7anC X-Yahoo-Newman-Property: ymail-3 X-rim-org-msg-ref-id: 1398490709 Message-ID: <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry> Content-Transfer-Encoding: quoted-printable X-Priority: Normal References: , In-Reply-To: Sensitivity: Normal Importance: Normal To: "Alexander Vainshtein" , mpls-bounces@ietf.org, "Greg Mirsky" From: davarish@yahoo.com Date: Sat, 18 Jun 2011 20:43:38 +0000 Content-Type: text/plain MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 19 Jun 2011 18:49:13 -0700 Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen , "Stewart Bryant \(stbryant@cisco.com\)" Subject: Re: [PWE3] [mpls] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: davarish@yahoo.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 20:50:10 -0000 Sasha All=20traffic=20except=20LSP=20OAM=20traffic=20from=20protection=20LSP=20mu= st=20be=20discarded=20in=20Rx.=20So=20what=20is=20the=20issue? Thx Shahram Sent=20via=20BlackBerry=20by=20AT&T -----Original=20Message----- From:=20Alexander=20Vainshtein=20 Sender:=20mpls-bounces@ietf.org Date:=20Sat,=2018=20Jun=202011=2021:58:41=20 To:=20Greg=20Mirsky Cc:=20mpls@ietf.org;=20Vladimir=20Kleiner;=20Mishael=20Wexler;=20pwe3;=20Oren=20Gal;=20John=20Shirron;=20Stewart=20Bryant=20\(stbryant@cisco.com\);=20Rotem=20Cohen Subject:=20Re:=20[mpls]=20[PWE3]=201+1=20linear=20LSP=20protection=20and=20= MPLS-TP=20data=20plane: =20are=20they=20compatible? _______________________________________________ mpls=20mailing=20list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Sun Jun 19 22:22:52 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3756811E8093; Sun, 19 Jun 2011 22:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3lfvWF45hEW; Sun, 19 Jun 2011 22:22:51 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9550211E807B; Sun, 19 Jun 2011 22:22:51 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sun, 19 Jun 2011 22:27:01 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Sun, 19 Jun 2011 22:22:37 -0700 From: "Shahram Davari" To: "Alexander Vainshtein" , "davarish@yahoo.com" , "mpls-bounces@ietf.org" , "Greg Mirsky" Date: Sun, 19 Jun 2011 22:22:32 -0700 Thread-Topic: [PWE3] [mpls] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? Thread-Index: Acwt+GKfP7ICXhYOQty4JE+eqpbXyAAPF4qMADVBtzA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93138B358@SJEXCHCCR02.corp.ad.broadcom.com> References: , , <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 61E005AF62O11202431-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant@cisco.com\)" , Rotem Cohen Subject: Re: [PWE3] [mpls] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 05:22:52 -0000 Hi Sasha, That is correct. But the behavior is what I call Leaky drop. Meaning that a= ll the Protection LSP packets must be dropped (including the PW traffic) ex= cept the LSP OAM packets. Thanks Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Saturday, June 18, 2011 9:05 PM To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Rotem Cohen; Stewart Bryant (stbryant@cisco.com) Subject: Re: [PWE3] [mpls] 1+1 linear LSP protection and MPLS-TP data plane= :are they compatible? Shahram, The problem IMHO is in the combination of two points : - At the LSP level both LSP OAM and PW traffic look exactly the same (after= popping the Tunnel label a labeled packet remains). You can only different= iate between them when you look up the next label in the stack - When you look at the next label after having popped the tunnel label, PW = packets received from both active and inactive LSPs look exactly the same w= ith the same label from the per-platform label space. IMO this means that you cannot describe the desired behavior in the terms o= f RFC 3031 and 3032. Hopefully this clarifies my question. Regards, Sasha ________________________________________ From: davarish@yahoo.com [davarish@yahoo.com] Sent: Saturday, June 18, 2011 11:43 PM To: Alexander Vainshtein; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= :are they compatible? Sasha All traffic except LSP OAM traffic from protection LSP must be discarded in= Rx. So what is the issue? Thx Shahram Sent via BlackBerry by AT&T -----Original Message----- From: Alexander Vainshtein Sender: mpls-bounces@ietf.org Date: Sat, 18 Jun 2011 21:58:41 To: Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Ore= n Gal; John Shirron; Stewar= t Bryant \(stbryant@cisco.com\); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= : are they compatible? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From davari@broadcom.com Sun Jun 19 22:41:53 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A3D11E80E5; Sun, 19 Jun 2011 22:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUBOSuDWVTiJ; Sun, 19 Jun 2011 22:41:52 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id B38EF11E80E6; Sun, 19 Jun 2011 22:41:52 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sun, 19 Jun 2011 22:46:21 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Sun, 19 Jun 2011 22:41:40 -0700 From: "Shahram Davari" To: "Alexander Vainshtein" , "davarish@yahoo.com" , "mpls-bounces@ietf.org" , "Greg Mirsky" Date: Sun, 19 Jun 2011 22:41:16 -0700 Thread-Topic: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? Thread-Index: Acwt+GKfP7ICXhYOQty4JE+eqpbXyAAPF4qMAB2hhpoAGDsEAA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93138B372@SJEXCHCCR02.corp.ad.broadcom.com> References: , , <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 61E001273B46064640-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant@cisco.com\)" , Rotem Cohen Subject: Re: [PWE3] [mpls] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 05:41:53 -0000 Hi Sahsa, Actually what you can do is to define 2 special interfaces, one for working= and one for protection LSP. Then for working interface, set the behavior a= s pop and forward as normal, and for protection interface pop and forward t= o control plane only reserved labels. In case of failure the behavior of th= e two interfaces must be changed. IS that correct? Thx Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Sunday, June 19, 2011 11:14 AM To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Rotem Cohen; Stewart Bryant (stbryant@cisco.com) Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= :are they compatible? Shahram, Greg and all, After some thought: One way to model selection in 1+1 linear protection architecture could be t= o define a "special" internal interface in the box and to define the ILM ac= tion on the tunnel label of an inactive LSP as "Pop and forward to special = interface". The special interface then would then forward resulting labeled packets wit= h a reserved top label to control and discard all the rest. This behavior w= ould not be part of "normal" MPLS data plane hence no contradictions with i= ts architecture. I assume that this is roughly the formal model for what Shahram and Greg ha= ve said. Regards, Sasha ________________________________________ From: Alexander Vainshtein Sent: Sunday, June 19, 2011 7:04 AM To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: RE: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= :are they compatible? Shahram, The problem IMHO is in the combination of two points : - At the LSP level both LSP OAM and PW traffic look exactly the same (after= popping the Tunnel label a labeled packet remains). You can only different= iate between them when you look up the next label in the stack - When you look at the next label after having popped the tunnel label, PW = packets received from both active and inactive LSPs look exactly the same w= ith the same label from the per-platform label space. IMO this means that you cannot describe the desired behavior in the terms o= f RFC 3031 and 3032. Hopefully this clarifies my question. Regards, Sasha ________________________________________ From: davarish@yahoo.com [davarish@yahoo.com] Sent: Saturday, June 18, 2011 11:43 PM To: Alexander Vainshtein; mpls-bounces@ietf.org; Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= :are they compatible? Sasha All traffic except LSP OAM traffic from protection LSP must be discarded in= Rx. So what is the issue? Thx Shahram Sent via BlackBerry by AT&T -----Original Message----- From: Alexander Vainshtein Sender: mpls-bounces@ietf.org Date: Sat, 18 Jun 2011 21:58:41 To: Greg Mirsky Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Ore= n Gal; John Shirron; Stewar= t Bryant \(stbryant@cisco.com\); Rotem Cohen Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane= : are they compatible? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Sun Jun 19 23:51:12 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10ECD21F8598; Sun, 19 Jun 2011 23:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTPWOZrFQdbS; Sun, 19 Jun 2011 23:51:11 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 17AC421F8595; Sun, 19 Jun 2011 23:51:09 -0700 (PDT) X-AuditID: 93eaf2e7-b7b6cae000001c92-ab-4dfeedd2b4cc Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id 24.F5.07314.2DDEEFD4; Mon, 20 Jun 2011 09:50:59 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 20 Jun 2011 09:51:05 +0300 From: Alexander Vainshtein To: Shahram Davari , "davarish@yahoo.com" , "mpls-bounces@ietf.org" , Greg Mirsky Date: Mon, 20 Jun 2011 09:51:01 +0300 Thread-Topic: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? Thread-Index: Acwt+GKfP7ICXhYOQty4JE+eqpbXyAAPF4qMAB2hhpoAGDsEAAACc5zg Message-ID: References: , , <1398490709-1308429804-cardhu_decombobulator_blackberry.rim.net-749160581-@b4.c27.bise6.blackberry>, <2C2F1EBA8050E74EA81502D5740B4BD6A93138B372@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A93138B372@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2WTa0wTWRTH985M2wEZMxSwV+JjHN+PknbR7Gy0RhOzW2KIxkeMxgSG6bWd 2E4nnWKs+0H0i5GNqJH4qKygAR/4IKIfimiUGj/UJ4oYbVQiQnia7BKCi5p2ZzorYpxP/3PP /5zfvZNzSNxcacolRSmIAhLvZY3pxJH+oWFr24dEoa28xcQ1HCjgWnr2Am7kaLeBa7793MTF 6y4YuIqh6wT3uLsKrDA5wx2PjM7Kz1cNzqbwG5OztnYUc4bDd7G1hi1lYBkvSf4gH0SMCymC g10bEHfwQohlRJeDtbOM7OUF5ENS0MHysowkF7s8nfnhW6baRIlBkuB3iZLbwRasX2PluCW/ Wu3s8jkz7flL0zd4RIVBVh8vehkfUhTejRj1pPg67rm674FJPrVwZ7Lqi6kMRGaWgzQS0ovh 0+ZRQteTYOvbBmM5SCfNdDOAxweaCD04CmBf05+45jLSDth48U3KlU1fBnD/w+OpAKcfYrDi 74tGzUXQs+G5RCKls2gBvmivNmg6m3bBuninUde/wT2nXpk0TdFr4P4rBzEdV0HAuwd7VTZJ ptFbYOwjpnmAer+P9y+lNE5bYLyrGtPvTcPam09wXefAvvcJg+7Pga/3NQDdvwjWNA8Zdb0Q nj09gOvcTBg70fX/+yfDlvMviUPAEh6HCI8rD48rD48rrwFEPcgRvXKwxOe22fOQIAaRF+UJ fl8j0KepJwI+Vc+KApoEbAblsSYKzQZ+hxLyRcFkEmNzqM5B9Whiid8V8vCKpyhQ6kVKFEAS Z7OpovdqjnLxoV0o4P+a4tS/fBjPnSD41bmVgkX5Ntt3AWuhuoXBQjPtVuduO0IyCnwtnUKS LKRWq+NtzgwgN9q5TfQGv6UxMk0jZ6jk/C6NrMi8TxHdev4+yCfPXO6LAvLsycEoMBOSX0K5 FqpEa0drVk+pNNZNW6bdyWSyH1jUl2dRvObKUFdtrF+/isJUVLI/hVK3ZCyVWwZWnh7ZW7ch 9s/USJu8imTi/94bKZhWdW3dg9KBa00RhZkR+n1uZbLmWGZhny0299Gczs+W6fKdtvqs+t52 7NnmTa03hisy5mdvrHy+Mr60wz36S0/L7Pbe4rwO342GxIRhi2HriGf9XxMbMeGPtLe1t8oj P53Iixb/7HzXOmv7ppJ5MZZQPLx9AR5Q+P8AN0qvkycEAAA= Cc: "mpls@ietf.org" , Vladimir Kleiner , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant@cisco.com\)" , Rotem Cohen Subject: Re: [PWE3] [mpls] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 06:51:12 -0000 Shahram, Lots of thanks for a prompt response. I doubt the value of two special interfaces: IMHO at least one of the LSPs (= Active) should be terminated (i.e. the ILM for its action would look "Pop an= d look up the next label"). But the "leaky drop" interface seems to be the right thing to do. The name i= s nice. I wonder if adding a clarification would benefit the linear protection draft= ? Regards, Sasha > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Monday, June 20, 2011 8:41 AM > To: Alexander Vainshtein; davarish@yahoo.com; mpls-bounces@ietf.org; > Greg Mirsky > Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; > John Shirron; Rotem Cohen; Stewart Bryant (stbryant@cisco.com) > Subject: RE: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data > plane:are they compatible? > > Hi Sahsa, > > Actually what you can do is to define 2 special interfaces, one for > working and one for protection LSP. Then for working interface, set the > behavior as pop and forward as normal, and for protection interface pop > and forward to control plane only reserved labels. In case of failure > the behavior of the two interfaces must be changed. > > IS that correct? > > Thx > Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Sunday, June 19, 2011 11:14 AM > To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky > Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; > John Shirron; Rotem Cohen; Stewart Bryant (stbryant@cisco.com) > Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data > plane:are they compatible? > > Shahram, Greg and all, > After some thought: > One way to model selection in 1+1 linear protection architecture could > be to define a "special" internal interface in the box and to define > the ILM action on the tunnel label of an inactive LSP as "Pop and > forward to special interface". > > The special interface then would then forward resulting labeled packets > with a reserved top label to control and discard all the rest. This > behavior would not be part of "normal" MPLS data plane hence no > contradictions with its architecture. > > I assume that this is roughly the formal model for what Shahram and > Greg have said. > > Regards, > Sasha > > > > > > ________________________________________ > From: Alexander Vainshtein > Sent: Sunday, June 19, 2011 7:04 AM > To: davarish@yahoo.com; mpls-bounces@ietf.org; Greg Mirsky > Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; > John Shirron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen > Subject: RE: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data > plane:are they compatible? > > Shahram, > The problem IMHO is in the combination of two points : > > - At the LSP level both LSP OAM and PW traffic look exactly the same > (after popping the Tunnel label a labeled packet remains). You can only > differentiate between them when you look up the next label in the stack > > - When you look at the next label after having popped the tunnel label, > PW packets received from both active and inactive LSPs look exactly the > same with the same label from the per-platform label space. > > IMO this means that you cannot describe the desired behavior in the > terms of RFC 3031 and 3032. > > Hopefully this clarifies my question. > > Regards, > Sasha > > > > ________________________________________ > From: davarish@yahoo.com [davarish@yahoo.com] > Sent: Saturday, June 18, 2011 11:43 PM > To: Alexander Vainshtein; mpls-bounces@ietf.org; Greg Mirsky > Cc: mpls@ietf.org; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; > John Shirron; Stewart Bryant (stbryant@cisco.com); Rotem Cohen > Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data > plane:are they compatible? > > Sasha > > All traffic except LSP OAM traffic from protection LSP must be > discarded in Rx. So what is the issue? > > Thx > Shahram > Sent via BlackBerry by AT&T > > -----Original Message----- > From: Alexander Vainshtein > Sender: mpls-bounces@ietf.org > Date: Sat, 18 Jun 2011 21:58:41 > To: Greg Mirsky > Cc: mpls@ietf.org; Vladimir > Kleiner; Mishael > Wexler; pwe3; Oren > Gal; John Shirron; > Stewart Bryant \(stbryant@cisco.com\); Rotem > Cohen > Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data > plane: > are they compatible? > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform > us by e-mail, phone or fax, and then delete the original and all copies > thereof. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Mon Jun 20 01:49:48 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E553A11E80B4; Mon, 20 Jun 2011 01:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.232 X-Spam-Level: ** X-Spam-Status: No, score=2.232 tagged_above=-999 required=5 tests=[AWL=-3.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, SARE_HTML_SINGLETS=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgy9vg0tZl2S; Mon, 20 Jun 2011 01:49:46 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1F91511E8083; Mon, 20 Jun 2011 01:49:43 -0700 (PDT) X-AuditID: 93eaf2e7-b7b6cae000001c92-fe-4dff099e7f55 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id 45.3B.07314.E990FFD4; Mon, 20 Jun 2011 11:49:35 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 20 Jun 2011 11:49:41 +0300 From: Alexander Vainshtein To: "ma.yuxia@zte.com.cn" Date: Mon, 20 Jun 2011 11:49:39 +0300 Thread-Topic: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwvJHl1sOtCtFDMRBOfIAQ+qt8VRgAAbbvg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76EA32634CFEILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTe2xLURzHc+693b2dXblK9WwhqcskKp11I8p0SJD6Yxkm8fpjrtujvdHe Vm/JKhIN5jEimOeCqQ3zrMmCzLwqElviGY+tHjOb0JF4BGMede8us0Scvz7nfL+/3/mdk9+P wnVlZBoliAHkFzk3m5RMlLZ/+Ggu1ybyMit20NbQ3QrM+mlXE26NHTyisT5qPktaN32oISZo 7JWVXzH718h90r7hVCluP37xCzGNmBsC4zhR9Aa4ADI6kMTb2Gl+YSnHB1mj4LCxFtboc3M8 8iAxYGM5nw+JDjY32fjPGifbBNGIRN7rEESnjZ1akG+2WkeNMVvY3KGDLdk5yTNdgmREZg8n uI0eJEmcExnlk/k1uOvI3jUa34VibdGZqkNYCITPUyVAS0FmJIzU1pEq94e3n0aSSkAypWPO A/ijuhxXNzsATFw+q1FcSYwNnj72JEnhfswIuGp3K1BMOHMSwO3rf3aZCCYdPvz+sYv7Motg y4kqQg1ww+rINVLlLHiw7kFXIprJh1t/HO5iHbMLwIaO3gprmQJYG1+HKwzk8joajmMK44wB xtrKMbVsBlbW3cJV1sN4q1oDkPnx2ghQ/V5Yu/8kqd7VB9bvbiNUfyq8UtVIbAb9y3qkLesR UtYjRD03wX2hb789g+C2DS2kysPgvdLobx4OD4Vf4/sBeRToBbcvsMDjzLRkIF4IIDfK4L2e 00BtrJfnQGf5kChgKMCm0C7zzzydhlsqBT1RkEphrJ42yH2n673A6wi6OMlV6F/iRlIUQApn +9GFrbKddnDBZcjv/SNNln9/C57Wi/fKLSwGCrMzM/+/YQ30C/5Nno5xyt25CCEf8v/JM4Ci WEjHKfn6Pn7kREULBXfgr4xRWqWMFKUMxUNLPs4jCU5VbwCD0gz0W0VgFMG1ROyOVUZqRSKR aAcG+dF96WeKK0UeuO7odjkxJidOtCvvk+TJ6ZbSQsBzQG+zTSHWFV8viM/LXR2OT9p3qeRl rDHcNrpjTlGOI2f2VTFr2eb0h2b96ts3xgsUHs4YvrOlLuvzjOCd2MXCwWK0eiD52rR848R3 U8CeWRvf29fnF/MLb7668Rx7Fk1tbG42xbJNIzpNzZ1NM+sj9fks86hm8fSSprETVq58YGAJ ycVZTLhf4n4BIzkCkC0EAAA= Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 08:49:49 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76EA32634CFEILPTMAIL02eci_ Content-Type: text/plain; charset="gb2312" content-transfer-encoding: base64 RGVhciBNYSwNCkxvdHMgb2YgdGhhbmtzIGZvciBvdXIgcmVzcG9uc2UuIFBsZWFzZSBzZWUg c29tZSBjb21tZW50cy9hbnN3ZXJzIGlubGluZSBiZWxvdy4NCg0KUmVnYXJkcywNCiAgICAg U2FzaGENCg0KRnJvbTogbWEueXV4aWFAenRlLmNvbS5jbiBbbWFpbHRvOm1hLnl1eGlhQHp0 ZS5jb20uY25dDQpTZW50OiBNb25kYXksIEp1bmUgMjAsIDIwMTEgMTE6MzEgQU0NClRvOiBB bGV4YW5kZXIgVmFpbnNodGVpbg0KQ2M6IERhbmllbCBDb2huOyBtcGxzQGlldGYub3JnOyBT cHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik7IHB3ZTNAaWV0Zi5vcmcN ClN1YmplY3Q6ILTwuLQ6IFJFOiBbbXBsc10gW1BXRTNdIFNlZWtpbmcgZmVlZGJhY2sgb24g SS1EICJNUExTLVRQTGluZWFyUHJvdGVjdGlvbkFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQoN Cg0KSGkgU2FzaGEsDQoNCiJMaW5lYXIgcHJvdGVjdGlvbiIgaXMgZGlmZmVyZW50IGZyb20g Ik11bHRpLWhvbWVkIENFIHJlZHVuZGFuY3kiIGFuZCBoYXMgbm8gcmVmZXJlbmNlIHdpdGgg QUMuDQpbW1tTYXNoYV1dXSBBYnNvbHV0ZWx5Lg0KDQpXb3JraW5nIHBhdGgocykgYW5kIHBy b3RlY3Rpb24gcGF0aChzKSBoYXZlIHNhbWUgc291cmNlIGFuZCBzaW5rIGVuZHBvaW50cyBp biBsaW5lYXIgcHJvdGVjdGlvbiB0eXBlLg0KW1tbU2FzaGFdXV0gT2YgY291cnNlLg0KDQoN CklNSE8sIFdoZW4gUy1QRSBmYWlscywgaXQgaXMgbW9yZSBzaW1wbGUgdG8gdXNlICJMaW5l YXIgcHJvdGVjdGlvbiIgdG8gcHJvdGVjdCBpdC4NCltbW1Nhc2hhXV1dIFdlbGwsIHNpbXBs aWNpdHkgLCBsaWtlIGJlYXV0eSwgaXMgaW4gdGhlIGV5ZSBvZiB0aGUgYmVob2xkZXI6KS4N CkJ1dCBJTUhPICBpbnRyb2R1Y2luZyBtdWx0aXBsZSBzaW1wbGUgYWQgaG9jIHNvbHV0aW9u cyAoZWFjaCBmb3IgaXRzIHNwZWNpZmljIGNhc2UpIGFuZCBtYWludGFpbmluZyB0aGVtICBl dmVudHVhbGx5IG1ha2UgeW91ciBsaWZlIG1vcmUgIGNvbXBsaWNhdGVkIHdoZW4gY29tcGFy ZWQgd2l0aCBvbmUgZ2VuZXJpYyBtZWNoYW5pc22hrQ0KDQpCZXN0IFJlZ2FyZHMsDQpNYQ0K DQoNCkFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbT4g0LTT2iAyMDExLTA2LTE0IDIwOjAyOjEwOg0KDQo+IERhbmllbCwNCj4gUGxlYXNl IHNlZSBtb3JlIGlubGluZSAoYm9sZCBwdXJwbGUgaXRhbGljcykuIEmhr3ZlIGFsc28gc3Ry aXBwZWQgdGhlDQo+IHBvcnRpb25zIG9mIHRoZSB0ZXh0IHRoYXQgYXJlIG5vdCByZWxhdGVk IHRvIHRoaXMgcm91bmQgb2YgY29tbWVudHMuDQo+DQo+IFJlZ2FyZHMsDQo+ICAgICAgU2Fz aGENCj4NCj4gRnJvbTogRGFuaWVsIENvaG4gW21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb21d DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTQsIDIwMTEgMjozNCBQTQ0KPiBUbzogQWxleGFu ZGVyIFZhaW5zaHRlaW4NCj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHB3ZTNAaWV0Zi5vcmc7IFNw cmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kDQo+IEhhU2hhcm9uKTsgbWEueXV4aWFAenRl LmNvbS5jbg0KPiBTdWJqZWN0OiBSRTogW21wbHNdIFtQV0UzXSBTZWVraW5nIGZlZWRiYWNr IG9uIEktRCAiTVBMUy0NCj4gVFBMaW5lYXJQcm90ZWN0aW9uQXBwbGljYWJpbGl0eSB0byBN Uy1QVyINCj4NCj4gSGkgU2FzaGEsIHRoYW5rcyBhZ2FpbiBhbmQgc2VlIGlubGluZSB3aXRo IFtEQ10uDQo+DQo+IEZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluIFttYWlsdG86QWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dDQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxMywg MjAxMSA2OjExIFBNDQo+IFRvOiBEYW5pZWwgQ29obg0KPiBDYzogbXBsc0BpZXRmLm9yZzsg cHdlM0BpZXRmLm9yZzsgU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QNCj4gSGFTaGFy b24pOyBtYS55dXhpYUB6dGUuY29tLmNuDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10gW1BXRTNd IFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLQ0KPiBUUExpbmVhclByb3RlY3Rpb25B cHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPg0KPiBEYW5pZWwgYW5kIGFsbCwNCj4gUGxlYXNl IHNlZSBzb21lIGNvbW1lbnRzIGlubGluZSBiZWxvdy4NCj4NCj4gUmVnYXJkcywNCj4gICAg ICBTYXNoYQ0KPg0KPiBGcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0 LmNvbV0NCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDU6NTUgUE0NCj4gVG86IFNw cmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTsgQWxleGFuZGVyIFZhaW5z aHRlaW47DQo+IG1hLnl1eGlhQHp0ZS5jb20uY24NCj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IHB3 ZTNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVk YmFjayBvbiBJLUQgIk1QTFMtDQo+IFRQTGluZWFyUHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5 IHRvIE1TLVBXIg0KPg0KPiBIaSwNCj4NCj4gVGhhbmtzIGFsbCBmb3IgdGhlIGZlZWRiYWNr LiBJIGJlbGlldmUgd2UgYWxsIGFncmVlIHRoYXQgUFcNCj4gcHJvdGVjdGlvbiBpcyBvbmx5 IHJlcXVpcmVkIGluIHRoZSBldmVudCBvZiBTLVBFIGZhaWx1cmUgYXQgYW4gTVMtUFcNCj4g qEMgdGhpcyAgaXMgY2xlYXJseSBzdGF0ZWQgaW4gdGhlIGRyYWZ0LiBOb3csIGJvdGggU2Fz aGEgYW5kIE51cml0DQo+IG1lbnRpb24gdGhhdCB0aGUgUFcgcmVkdW5kYW5jeSBtZWNoYW5p c20gY2FuIG1lZXQgdGhlIE1QTFMtVFAgUFcNCj4gcHJvdGVjdGlvbiByZXF1aXJlbWVudHMu DQo+IFtbW1Nhc2hhXV1dIKGtIHNuaXBwZWQgoa0NCj4gRS5nLiwgdGhlIFBXIHJlZHVuZGFu Y3kgbWVjaGFuaXNtcyB0YWtlIGNhcmUgb2YgZHVhbC1ob21lZCBDRXMgaW4NCj4gU1MtIGFu ZCBNUy1QV3MgqEMgc29tZXRoaW5nIHRoYXQgbGluZXIgcHJvdGVjdGlvbiBvZiBQV3MgY2Fu bm90IGRvLg0KPiBbRENdIEmhr20gYWZyYWlkIEkgZG9uoa90IGZvbGxvdyB5b3UgaGVyZS4g V2hlcmUgZG9lcyBQVyByZWR1bmRhbmN5DQo+IHRha2UgY2FyZSBvZiBkdWFsLWhvbWVkIENF PyBBY3R1YWxseSBQVyByZWR1bmRhbmN5IGRyYWZ0IGV4cGxpY2l0bHkNCj4gc3RhdGVzOiCh sFRoZSBtZXRob2QgZm9yIGR1YWwtaG9taW5nIG9mIENFMSB0byBQRTEgYW5kIHRvIFBFMyBu b2RlcywNCj4gYW5kIHRoZSBwcm90b2NvbHMgdXNlZCwgYXJlIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnShsS4NCj4gW1tbU2FzaGFdXV0gUXVvdGluZyBmcm9tIHRoZSBk cmFmdDoNCj4gMTUuMi4gTXVsdGlwbGUgTXVsdGktaG9tZWQgQ0VzIHdpdGggc2luZ2xlIFNT LVBXIHJlZHVuZGFuY3kNCj4NCj4gICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0gRW11 bGF0ZWQgU2VydmljZSAtLS0tLS0tLS0tLS0tLS0tPnwNCj4gICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAg ICAgICAgICAgIHwgICAgICAgICAgfDwtLS0tLS0tIFBzZXVkbyBXaXJlIC0tLS0tLT58ICAg ICAgICAgIHwNCj4gICAgICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgIHwNCj4gICAgICAgICAgICAgIHwgICAgICAgICAgfCAg ICB8PC0tIFBTTiBUdW5uZWxzLS0+fCAgICB8ICAgICAgICAgIHwNCj4gICAgICAgICAgICAg IHwgICAgICAgICAgViAgICBWICAgIChub3Qgc2hvd24pICAgViAgICBWICAgICAgICAgIHwN Cj4gICAgICAgICAgICAgIFYgICAgQUMgICAgKy0tLS0rICAgICAgICAgICAgICAgICAgKy0t LS0rICAgICBBQyAgIFYNCj4gICAgICAgICstLS0tLSsgICAgfCAgICAgfC4uLi58Li4uLi4u LlBXMS4uLi4uLi4ufC4uLi58ICAgICB8ICAgICstLS0tLSsNCj4gICAgICAgIHwgICAgIHwt LS0tLS0tLS0tfCBQRTF8Li4uLi4uICAgLi4uLi4uLi4ufCBQRTN8LS0tLS0tLS0tLXwgICAg IHwNCj4gICAgICAgIHwgQ0UxIHwgICAgICAgICAgKy0tLS0rICAgICAgXCAvICBQVzMgICAg Ky0tLS0rICAgICAgICAgIHwgQ0UyIHwNCj4gICAgICAgIHwgICAgIHwgICAgICAgICAgKy0t LS0rICAgICAgIFggICAgICAgICAgKy0tLS0rICAgICAgICAgIHwgICAgIHwNCj4gICAgICAg IHwgICAgIHwgICAgICAgICAgfCAgICB8Li4uLi4uLyBcLi5QVzQuLi4ufCAgICB8ICAgICAg ICAgIHwgICAgIHwNCj4gICAgICAgIHwgICAgIHwtLS0tLS0tLS0tfCBQRTJ8ICAgICAgICAg ICAgICAgICAgfCBQRTR8LS0tLS0tLS0tIHwgICAgIHwNCj4gICAgICAgICstLS0tLSsgICAg fCAgICAgfC4uLi58Li4uLi5QVzIuLi4uLi4uLi4ufC4uLi58ICAgICB8ICAgICstLS0tLSsN Cj4gICAgICAgICAgICAgICAgICAgQUMgICAgKy0tLS0rICAgICAgICAgICAgICAgICAgKy0t LS0rICAgIEFDDQo+DQo+DQo+ICAgICAgRmlndXJlIDE1LTIgTXVsdGlwbGUgTXVsdGktaG9t ZWQgQ0VzIHdpdGggc2luZ2xlIFNTLVBXIHJlZHVuZGFuY3kNCj4NCj4gICAgVGhlIGFwcGxp Y2F0aW9uIGluIEZpZ3VyZSAxNS0yIG1ha2VzIHVzZSBvZiB0aGUgSW5kZXBlbmRlbnQgbW9k ZSBvZg0KPiAgICBvcGVyYXRpb24uDQo+DQo+ICAgIENFMSBpcyBkdWFsLWhvbWVkIHRvIFBF MSBhbmQgUEUyLiBDRTIgaXMgZHVhbC1ob21lZCBQRTMgYW5kIFBFNC4gVGhlDQo+ICAgIG1l dGhvZCBmb3IgZHVhbC1ob21pbmcgYW5kIHRoZSB1c2VkIHByb3RvY29scyBhcmUgb3V0c2lk ZSB0aGUgc2NvcGUNCj4gICAgb2YgdGhpcyBkb2N1bWVudC4gIE5vdGUgdGhhdCB0aGUgUFNO IHR1bm5lbHMgYXJlIG5vdCBzaG93biBpbiB0aGlzDQo+ICAgIGZpZ3VyZSBmb3IgY2xhcml0 eS4gSG93ZXZlciwgaXQgY2FuIGJlIGFzc3VtZWQgdGhhdCBlYWNoIG9mIHRoZSBQV3MNCj4g ICAgc2hvd24gaXMgZW5jYXBzdWxhdGVkIGluIGEgc2VwYXJhdGUgUFNOIHR1bm5lbC4NCj4N Cj4gICAgQXNzdW1lIHRoYXQgdGhlIEFDIGZyb20gQ0UxIHRvIFBFMSBpcyBBY3RpdmUsIGZy b20gQ0UxIHRvIFBFMiBpcw0KPiAgICBTdGFuZGJ5OyBmdXJ0aGVybW9yZSwgYXNzdW1lIHRo YXQgdGhlIEFDIGZyb20gQ0UyIHRvIFBFMyBpcyBTdGFuZGJ5DQo+ICAgIGFuZCBmcm9tIENF MiB0byBQRTQgaXMgQWN0aXZlLiBUaGUgbWV0aG9kIG9mIGRlcml2aW5nIEFjdGl2ZS9TdGFu ZGJ5DQo+ICAgIHN0YXR1cyBvZiB0aGUgQUMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhp cyBkb2N1bWVudC4NCj4NCj4gICAgUEUxIGFkdmVydGlzZXMgdGhlIHByZWZlcmVudGlhbCBz dGF0dXMgIkFjdGl2ZSIgYW5kIG9wZXJhdGlvbmFsDQo+ICAgIHN0YXR1cyAiUHNldWRvd2ly ZSBmb3J3YXJkaW5nIiBmb3IgcHNldWRvd2lyZXMgUFcxIGFuZCBQVzQgY29ubmVjdGVkDQo+ ICAgIHRvIFBFMyBhbmQgUEU0LiBUaGlzIHN0YXR1cyByZWZsZWN0cyB0aGUgZm9yd2FyZGlu ZyBzdGF0ZSBvZiB0aGUgQUMNCj4gICAgYXR0YWNoZWQgdG8gUEUxLiBQRTIgYWR2ZXJ0aXNl cyBwcmVmZXJlbnRpYWwgc3RhdHVzICJTdGFuZGJ5IiBhbmQNCj4gICAgb3BlcmF0aW9uYWwg c3RhdHVzICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIGZvciBwc2V1ZG93aXJlcyBQVzIgYW5k DQo+ICAgIFBXMyB0byBQRTMgYW5kIFBFNC4gUEUzIGFkdmVydGlzZXMgcHJlZmVyZW50aWFs IHN0YXR1cyAiU3RhbmRieSIgYW5kDQo+ICAgIG9wZXJhdGlvbmFsIHN0YXR1cyAiUHNldWRv d2lyZSBmb3J3YXJkaW5nIiBmb3IgcHNldWRvd2lyZXMgUFcxIGFuZA0KPiAgICBQVzMgdG8g UEUxIGFuZCBQRTIuIFBFNCBhZHZlcnRpc2UgdGhlIHByZWZlcmVudGlhbCBzdGF0dXMgIkFj dGl2ZSINCj4gICAgYW5kIG9wZXJhdGlvbmFsIHN0YXR1cyAiUHNldWRvd2lyZSBmb3J3YXJk aW5nIiBmb3IgcHNldWRvd2lyZXMgUFcyDQo+ICAgIGFuZCBQVzQgdG8gUEUyIGFuZCBQRTEg cmVzcGVjdGl2ZWx5LiBUaHVzIGJ5IG1hdGNoaW5nIHRoZSBsb2NhbCBhbmQNCj4gICAgcmVt b3RlIHByZWZlcmVudGlhbCBmb3J3YXJkaW5nIHN0YXR1cyBvZiAiQWN0aXZlIiBhbmQgb3Bl cmF0aW9uYWwNCj4gICAgc3RhdHVzIG9mICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIG9mIHBz ZXVkb3dpcmVzLCB0aGUgUEUgbm9kZXMNCj4gICAgZGV0ZXJtaW5lIHdoaWNoIFBXIHNob3Vs ZCBiZSBpbiB0aGUgQWN0aXZlIHN0YXRlLiBJbiB0aGlzIGNhc2UgaXQgaXMNCj4gICAgUFc0 IHRoYXQgd2lsbCBiZSBzZWxlY3RlZC4NCj4NCj4gICAgT24gZmFpbHVyZSBvZiB0aGUgQUMg YmV0d2VlbiBDRTEgYW5kIFBFMSwgdGhlIGZvcndhcmRpbmcgc3RhdGUgb2YNCj4gICAgdGhl IEFDIG9uIFBFMiBpcyBjaGFuZ2VkIHRvIEFjdGl2ZS4gUEUyIHRoZW4gYW5ub3VuY2VzIHRo ZSBuZXdseQ0KPiAgICBjaGFuZ2VkICdwcmVmZXJlbnRpYWwgZm9yd2FyZGluZycgc3RhdHVz IGJpdCBvZiAiYWN0aXZlIiB0byBQRTMgYW5kDQo+ICAgIFBFNC4gUEUxIHdpbGwgYWR2ZXJ0 aXNlIGEgUFcgc3RhdHVzIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGluZGljYXRpbmcNCj4gICAg dGhhdCB0aGUgQUMgYmV0d2VlbiBDRTEgYW5kIFBFMSBpcyBvcGVyYXRpb25hbGx5IGRvd24u IFBFMiBhbmQgUEU0DQo+ICAgIG1hdGNoIHRoZSBsb2NhbCBhbmQgcmVtb3RlIHByZWZlcmVu dGlhbCBmb3J3YXJkaW5nIHN0YXR1cyBvZg0KPiAgICAiQWN0aXZlIiBhbmQgb3BlcmF0aW9u YWwgc3RhdHVzICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIGFuZCBzZWxlY3QNCj4gICAgUFcy IGFzIHRoZSBuZXcgYWN0aXZlIHBzZXVkb3dpcmUgdG8gc2VuZCB0cmFmZmljIHRvLg0KPg0K PiAgICBPbiBmYWlsdXJlIG9mIFBFMSBub2RlLCBQRTIgd2lsbCBkZXRlY3QgaXQgYW5kIHdp bGwgdHJhbnNpdGlvbiB0aGUNCj4gICAgZm9yd2FyZGluZyBzdGF0ZSBvZiBpdHMgQUMgdG8g QWN0aXZlLiBUaGUgbWV0aG9kIGJ5IHdoaWNoIFBFMg0KPiAgICBkZXRlY3RzIHRoYXQgUEUx IGlzIGRvd24gaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gUEUyDQo+ ICAgIHRoZW4gYW5ub3VuY2VzIHRoZSBuZXdseSBjaGFuZ2VkICdwcmVmZXJlbnRpYWwgZm9y d2FyZGluZycgc3RhdHVzDQo+ICAgIGJpdCBvZiAiQWN0aXZlIiB0byBQRTMgYW5kIFBFNC4g UEUyIGFuZCBQRTQgbWF0Y2ggdGhlIGxvY2FsIGFuZA0KPiAgICByZW1vdGUgcHJlZmVyZW50 aWFsIGZvcndhcmRpbmcgc3RhdHVzIG9mICJBY3RpdmUiIGFuZCBvcGVyYXRpb25hbA0KPiAg ICBzdGF0dXMgIlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgYW5kIHNlbGVjdCBQVzIgYXMgdGhl IG5ldyBhY3RpdmUNCj4gICAgcHNldWRvd2lyZSB0byBzZW5kIHRyYWZmaWMgdG8uIE5vdGUg dGhhdCBQRTMgYW5kIFBFNCBtYXkgaGF2ZQ0KPiAgICBkZXRlY3RlZCB0aGF0IHRoZSBQVyB0 byBQRTEgd2VudCBkb3duIHZpYSBULUxEUCBIZWxsbyB0aW1lb3V0IG9yIHZpYQ0KPiAgICBv dGhlciBtZWFucy4gSG93ZXZlciwgdGhleSB3aWxsIG5vdCBiZSBhYmxlIHRvIGZvcndhcmQg dXNlciB0cmFmZmljDQo+ICAgIHVudGlsIHRoZXkgcmVjZWl2ZWQgdGhlIHVwZGF0ZWQgc3Rh dHVzIGJpdCBmcm9tIFBFMi4NCj4NCj4gICAgQmVjYXVzZSBlYWNoIGR1YWwtaG9taW5nIGFs Z29yaXRobSBydW5uaW5nIG9uIHRoZSB0d28gbm9kZSBzZXRzLA0KPiAgICBpLmUuLCB7Q0Ux LCBQRTEsIFBFMn0gYW5kIHtDRTIsIFBFMywgUEU0fSwgc2VsZWN0cyB0aGUgYWN0aXZlIEFD DQo+ICAgIGluZGVwZW5kZW50bHksIHRoZXJlIGlzIGEgbmVlZCB0byBzaWduYWwgdGhlIGFj dGl2ZSBzdGF0dXMgb2YgdGhlIEFDDQo+ICAgIHN1Y2ggdGhhdCB0aGUgUEUgbm9kZXMgY2Fu IHNlbGVjdCBhIGNvbW1vbiBhY3RpdmUgUFcgZm9yIGVuZC10by1lbmQNCj4gICAgZm9yd2Fy ZGluZyBiZXR3ZWVuIENFMSBhbmQgQ0UyIGFzIHBlciB0aGUgcHJvY2VkdXJlcyBpbiB0aGUN Cj4gICAgaW5kZXBlbmRlbnQgbW9kZS4NCj4NCj4gICAgTm90ZSB0aGF0IGFueSBwcmltYXJ5 L3NlY29uZGFyeSBwcm9jZWR1cmVzLCBhcyBkZWZpbmVkIGluIHNlY3Rpb25zDQo+ICAgIDUu MS4gIGFuZCA1LjIuICwgZG8gbm90IGFwcGx5IGluIHRoaXMgdXNlIGNhc2UgYXMgdGhlIEFj dGl2ZS9TdGFuZGJ5DQo+ICAgIHN0YXR1cyBpcyBkcml2ZW4gYnkgdGhlIEFDIGZvcndhcmRp bmcgc3RhdGUgYXMgZGV0ZXJtaW5lZCBieSB0aGUgQUMNCj4gICAgZHVhbC1ob21pbmcgcHJv dG9jb2wgdXNlZC4NCj4NCj4NCj4gSSBiZWxpZXZlIHlvdaGvdmUgdGFrZW4geW91ciChsG91 dCBvZiBzY29wZaGxIHJlZmVyZW5jZSBmcm9tIHRoaXMgdGV4dCwNCj4gYnV0IElNSE8geW91 IG1pc2ludGVycHJldGVkIGl0Lg0KPiBXaGF0IGl0IG1lYW5zIChvciBzbyBJIHJlYWQgaXQp IGlzIHRoYXQgc3BlY2lmaWMgZHVhbC1ob21pbmcNCj4gcHJvdG9jb2wgaXMgb3V0IG9mIHNj b3BlIGFzIGxvbmcgYXMgaXQgbWVldHMgY2VydGFpbiBhc3N1bXB0aW9ucy4NCj4gQXNpZGU6 IEl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIGF1dGhvcnMgb2YgdGhlIFBXIHJlZHVuZGFuY3kg ZHJhZnRzDQo+IGNvdWxkIGV4cGxpY2l0bHkgc3BlY2lmeSB0aGVzZSBhc3N1bXB0aW9ucy4N Cj4NCj4gW1tbU2FzaGFdXV0goa0gc25pcHBlZCChrQ0KPg0KPiBOb3cgbGV0oa9zIHR1cm4g b3VyIGF0dGVudGlvbiBiYWNrIHRvIHdoZXRoZXIgdGhlIFBXIHJlZHVuZGFuY3kNCj4gZHJh YWZ0IGNhbiBiZSB1c2VkIHRvIG1lZXQgTVBMUy1UUCBQVyBwcm90ZWN0aW9uIHJlcXVpcmVt ZW50cy4gSSBjYW4NCj4gaWRlbnRpZnkgdGhlIGZvbGxvd2luZyByZWFzb25zIHdoeSBpbiBp dHMgY3VycmVudCBmb3JtIGl0IGRvZXNuoa90Og0KPg0KPiAtICAgICAgICAgIEl0IGV4cGxp Y2l0bHkgKKGwb3V0c2lkZSB0aGUgc2NvcGWhsSkgZG9lcyBub3QgZGVmaW5lDQo+IHByb3Rl Y3Rpb24gdHJpZ2dlcnMgYW5kIGhvdyB0byBoYW5kbGUgY29leGlzdGluZyB0cmlnZ2Vycywg YXMNCj4gcmVxdWVzdGVkIGluIFJGQyA1NjU0IChNUExTLVRQIFJlcXVpcmVtZW50cyksIHJl cXMgIzc1LCAjNzYgYW5kICM3OQ0KPiBbW1tTYXNoYV1dXSBTbyB3aGF0PyBEZWZpbml0aW9u IG9mIHRyaWdnZXJzIGlzIG9ydGhvZ29uYWwgdG8gaG93DQo+IGNvb3JkaW5hdGVkIHByb3Rl Y3Rpb24gc3dpdGNoaW5nIGhhcHBlbnMuDQo+IFtEQ10gSXQgaXMuIEJ1dCBzdGlsbCBpdCBu ZWVkcyB0byBiZSBkZWZpbmVkIGJ5IHRoZSByZWNvdmVyeQ0KPiBmcmFtZXdvcmssIGUuZy4g d2hhdCBzaG91bGQgdGhlIGVuZHBvaW50IGRvIHdoZW4gb25lIFBXIGlzIGluIFNGIGFuZA0K PiB0aGUgb3RoZXIgaXMgaW4gU0QsIG9yIHdoZW4gYm90aCBhcmUgaW4gU0QuIE9wZXJhdG9y cyBleHBlY3Qgd2VsbC0NCj4gZGVmaW5lZCBiZWhhdmlvciBpbiB0aGVzZSBhbmQgb3RoZXIg c2NlbmFyaW9zLCBhbmQgUFcgcmVkdW5kYW5jeQ0KPiBkb2VzIG5vdCBkZWZpbmUgdGhlbSAo YmVjYXVzZSBpdCB3YXMgbm90IGluIHRoZWlyIHNjb3BlKS4NCj4gW1tbU2FzaGFdXV0gSSB3 b25kZXIgaWYgeW91IGhhdmUgZm9sbG93ZWQgdGhlIGRpc2N1c3Npb24gcmVnYXJkaW5nDQo+ IGFiaWxpdHkgdG8gZGVmaW5lIFNEIGNvbmRpdGlvbiBmb3IgTFNQcyBhbmQgUFdzIG9uIHRo ZSBNUExTLVRQIGxpc3Q/DQo+IElNTyBpdCBpcyBub3QgcG9zc2libGUgdG8gZGVmaW5lIGl0 IGluIGEgbWVhbmluZ2Z1bCB3YXkuIEhlbmNlIEkgZG8NCj4gbm90IHNlZSBhIHByb3Bvc2Fs IHRoYXQgZG9lcyBub3QgYWRkcmVzcyBhIHNjZW5hcmlvIHRoYXQgZG9lcyBub3QNCj4gZXhp c3QgaW4gcmVhbGl0eSBhcyBhIGZsYXdlZCBvbmUuDQo+DQo+IC0gICAgICAgICAgSXQgZG9l cyBub3Qgc3VwcG9ydCB0aGUgYWJpbGl0eSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuDQo+IGRp ZmZlcmVudCB0eXBlcyBvZiB0cmlnZ2VycyAoaS5lLiBvbmUgZW5kIGRvZXNuoa90IGtub3cg d2h5IHRoZSBvdGhlcg0KPiBlbmQgdHJpZ2dlcmVkIHN3aXRjaCksIGFzIHJlcXVlc3RlZCBp biBSRkMgNTY1NCAoTVBMUy1UUA0KPiBSZXF1aXJlbWVudHMpLCByZXEgIzc3DQo+IC0gICAg ICAgICAgSXQgZG9lcyBub3QgZGVmaW5lIHJldmVydGl2ZS9ub25yZXZlcnRpdmUgYmVoYXZp b3IsIGFzDQo+IHJlcXVlc3RlZCBpbiBSRkMgNTY1NCAoTVBMUy1UUCBSZXF1aXJlbWVudHMp LCByZXEgIzY0DQo+IC0gICAgICAgICAgSXQgZG9lcyBub3QgZGVmaW5lIGhvbGRvZmYgc3Vw cG9ydCwgd2hpY2ggaXMgZXNwZWNpYWxseQ0KPiBpbXBvcnRhbnQgdG8gYXZvaWQgcmFjZSBj b25kaXRpb25zIHdpdGggTFNQIHByb3RlY3Rpb24gd2hlbiBpdCBleGlzdHMNCj4gLSAgICAg ICAgICBJdCBkb2VzbqGvdCBzdXBwb3J0IDErMSBtb2RlLCBhcyByZXF1ZXN0ZWQgaW4gUkZD IDU2NTQNCj4gKE1QTFMtVFAgUmVxdWlyZW1lbnRzKSwgcmVxICM2NQ0KPiBbW1tTYXNoYV1d XSBBbGwgdGhlc2UgY2xhaW1zIGFyZSBjb3JyZWN0IKhDIGFuZCAgdGhpcyBzaG91bGQgbm90 IGJlIGENCj4gc3VycHJpc2UsIGJlY2F1c2UgTVBMUy1UUCByZXF1aXJlbWVudHMgaGF2ZSBi ZWVuIGRlZmluZWQgbXVjaCBsYXRlcg0KPiB0aGFuIHRoZSBQVyByZWR1bmRhbmN5IG1lY2hh bmlzbS4NCj4gQnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBqdXN0aWZpZXMgY28tZXhp c3RlbmNlIG9mIHR3byBkaWZmZXJlbnQNCj4gbWVjaGFuaXNtcy4NCj4gW0RDXSBTbyBob3cg ZG8geW91IHByb3Bvc2UgdG8gbWVldCB0aGUgUFcgcHJvdGVjdGlvbiByZXF1aXJlbWVudD8N Cj4gLSAgICAgICAgICBJdKGvcyBhIHR3by1waGFzZSBwcm90b2NvbCwgd2l0aCB0aGUgY29u c2VxdWVudCBpbXBhY3Qgb24gdGltaW5nDQo+IFtbW1Nhc2hhXV1dIENvdWxkIHlvdSBwbGVh c2UgZWxhYm9yYXRlPyBbRENdIEluIGRyYWZ0LWlldGYtbXBscy10cC0NCj4gbGluZWFyLXBy b3RlY3Rpb24sIGVhY2ggZW5kcG9pbnQgd2lsbCBpbW1lZGlhdGVseSBzd2l0Y2ggdHJhZmZp YyB0bw0KPiB0aGUgb3RoZXIgcGF0aCB1cG9uIGlkZW50aWZ5aW5nIGFuIFNGIGNvbmRpdGlv biBpbiBhIHBhdGgsIHdpdGhvdXQNCj4gd2FpdGluZyBmb3IgdGhlIGZhciBlbmQgdG8gYWNr bm93bGVkZ2UgdGhlIHN3aXRjaCAoMS1waGFzZSkuIEluIFBXDQo+IHJlZHVuZGFuY3ksIGFu IGVuZHBvaW50IGRldGVjdGluZyBhbiBTRiBjb25kaXRpb24gaW4gYSBwYXRoIHdpbGwgbm90 DQo+IHN3aXRjaCB1bnRpbCB0aGUgZmFyIGVuZCBoYXMgYWNrbm93bGVkZ2VkIHRoZSBzd2l0 Y2ggKDItcGhhc2UpLg0KPiBOZWVkbGVzcyB0byBzYXksIHJlY292ZXJ5IGlzIHNsb3dlciBp biBhIDItcGhhc2UgcHJvdG9jb2wuDQo+IFtbW1Nhc2hhXV1dIFRvIHRoZSBiZXN0IG9mIG15 IHVuZGVyc3RhbmRpbmcsIDEtcGhhc2UgcHJvdGVjdGlvbiBpcw0KPiBvbmx5IHBvc3NpYmxl IGluIDErMSB1bmlkaXJlY3Rpb25hbCBhcmNoaXRlY3R1cmVzLiBBbmQgeWVzLCBJIGtub3cN Cj4gdGhhdCBNUExTLVRQIHJlcXVpcmVzIGEgIG1lY2hhbmlzbSB0byBzdXBwb3J0IHRoaXM7 IHdoZXRoZXIgYW55Ym9keQ0KPiB3b3VsZCByZWFsbHkgZG8gdGhhdCBpbiB0aGUgcGFja2V0 LXN3aXRjaGluZyBuZXR3b3JrIGlzIG5vdCBjbGVhciB0bw0KPiBtZS4gQW5kIEkgYWNrbm93 bGVkZ2UgdGhhdCB0aGUgUFcgcmVkdW5kYW5jeSBkcmFmdHMgZG8gbm90IHN1cHBvcnQNCj4g MSsxIHVuaWRpcmVjdGlvbmFsIHNjaGVtZS4NCj4NCj4gLSAgICAgICAgICBJdCBkb2VzbqGv dCBkZWZpbmUgcmV0cmFuc21pc3Npb24gb2YgcHJvdGVjdGlvbg0KPiBjb29yZGluYXRpb24g bWVzc2FnZXMsIHNvIGxvc3Mgb2YgYSBzaW5nbGUgUERVIGNhbiByZXN1bHQgaW4NCj4gc3dp dGNob3ZlciBub3QgdGFraW5nIHBsYWNlLCB0aHVzIG5vdCBzdXBwb3J0aW5nIHN1Yi01MCBt cyByZWNvdmVyeQ0KPiBpbiB0aGlzIGNhc2UNCj4gW1tbU2FzaGFdXV0gVGhlIFBXIHJlZHVu ZGFuY3kgcHJvdG9jb2wgcnVucyBlaXRoZXIgb24gdG9wIG9mIExEUA0KPiAod2hpY2ggYmVu ZWZpdHMgZnJvbSBUQ1AgcmV0cmFuc21pc3Npb25zKSBvciBvbiB0b3Agb2Ygc3RhdGljIFBX DQo+IHN0YXR1cyBtZXNzYWdlcyAod2hlcmUgcmV0cmFuc21pc3Npb24gaXMgZGVmaW5lZCku DQo+IFtEQ10gVHJ1ZSCoQyBidXQgc3RhdGljIFBXIHN0YXR1cyBkZWZpbmVzIHNsb3cgcmV0 cmFuc21pc3Npb24gKKGwd2lsbA0KPiBiZSB0cmFuc21pdHRlZCB0d2ljZSBhdCBhbiBpbml0 aWFsIGludGVydmFsIG9mIG9uZSBzZWNvbmShsSkgd2hpbGUNCj4gZHJhZnQtaWV0Zi1tcGxz LXRwLWxpbmVhci1wcm90ZWN0aW9uIHNwZWNpZmllcyBmYXN0IHJldHJhbnNtaXNzaW9uDQo+ IHdoZW4gcmVxdWlyZWQgZm9yIGZhc3QgcmVjb3ZlcnkgKHNlY3Rpb24gMy4xLjQpLg0KPg0K PiBJbiBzdW1tYXJ5LCBQVyByZWR1bmRhbmN5IHdhcyBub3QgZGVzaWduZWQgd2l0aCBUUCBy ZXF1aXJlbWVudHMgaW4NCj4gbWluZCwgYW5kIGFzIHN1Y2ggZG9lcyBub3QgbWVldCB0aGUg VFAgcmVxdWlyZW1lbnRzLiBPZiBjb3Vyc2UNCj4gbW9kaWZpY2F0aW9ucyBtYXkgYmUgaW50 cm9kdWNlZCwgYnV0IHdoeSByZWludmVudCB0aGUgd2hlZWwgd2hlbg0KPiB0aGVyZSBpcyBh IHByb3RvY29sIChkcmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24tMDYpIGlu IHRoZQ0KPiBzdGFuZGFyZHMgdHJhY2sgdGhhdCBzdXBwb3J0cyBhbGwgdGhlIGFib3ZlIHJl cXVpcmVtZW50cyBhbmQgY2FuIGJlDQo+IGFwcGxpZWQgdG8gTVMtUFcgcHJvdGVjdGlvbiB3 aXRoIG1pbm9yIG1vZGlmaWNhdGlvbnM/DQo+IFtbW1Nhc2hhXV1dIEFzIEkgc2FpZCwgYmVj YXVzZSB0aGUgYXBwbGljYWJpbGl0eSBzY29wZSBpcyBieSBmYXIgdG9vDQo+IG5hcnJvdyB0 byBqdXN0aWZ5IGEgZGVkaWNhdGVkIHByb3RvY29sLg0KPiBbRENdIElmIHdlIHdlcmUgZGlz Y3Vzc2luZyBkZXNpZ25pbmcgYSBuZXcgcHJvdG9jb2wsIEkgbWlnaHQgYWdyZWUNCj4gd2l0 aCB5b3UuIEJ1dCBmcm9tIGEgcHJhY3RpY2FsIHN0YW5kcG9pbnQsIHRoZSBQVyBwcm90ZWN0 aW9uIGRyYWZ0DQo+IGlzIG5vdCBhIGRlZGljYXRlZCBwcm90b2NvbCCoQyBpdKGvcyBhbiBh cHBsaWNhYmlsaXR5IHN0YXRlbWVudCB0byBhbg0KPiBleGlzdGluZyBwcm90b2NvbC4gQm90 aCBmcm9tIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgdGhlIG9wZXJhdGlvbmFsDQo+IHBvaW50 IG9mIHZpZXcgaXQgZGVmaW5lcyBhIG5ldyB1c2UgY2FzZSBmb3IgYW4gZXhpc3RpbmcgcHJv dG9jb2wgYW5kIGNvbmNlcHQuDQo+DQo+DQo+IFJlZ2FyZHMsDQo+DQo+IERhbmllbA0KPg0K Pg0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hv ZCBIYVNoYXJvbikNCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDQ6MDIgUE0NCj4g VG86IGV4dCBBbGV4YW5kZXIgVmFpbnNodGVpbjsgbWEueXV4aWFAenRlLmNvbS5jbg0KPiBD YzogbXBsc0BpZXRmLm9yZzsgcHdlM0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21wbHNd IFtQV0UzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy0NCj4gVFBMaW5lYXJQcm90 ZWN0aW9uIEFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+DQo+IEhpLA0KPiBJIHdvdWxkIGxp a2UgdG8gc2Vjb25kIFNhc2hhLg0KPiBFbmQtdG8tZW5kIFBXIHByb3RlY3Rpb24gKHdpdGgg ZGl2ZXJzZSBwYXRocykgZG9lcyBub3Qgc2NhbGUsIGFuZA0KPiBwdXQgaGFyZCByZXN0cmlj dGlvbnMgb24gdGhlIHV0aWxpemF0aW9uIG9mIHRoZSByZXNvdXJjZXMuDQo+IE1QTFMtVFAg UFdzIGFyZSBjYXJyaWVkIGFjcm9zcyB0aGUgbmV0d29yayBpbnNpZGUgTVBMUy1UUCBMU1Bz Lg0KPiBUaGVyZWZvcmUsIGFuIG9idmlvdXMgd2F5IHRvIHByb3ZpZGUgcHJvdGVjdGlvbiBm b3IgYSBQVyBpcyB0bw0KPiBwcm90ZWN0IHRoZSBMU1AgdGhhdCBjYXJyaWVzIGl0Lg0KPiBJ ZiB0aGUgUFcgaXMgYSBtdWx0aS1zZWdtZW50IFBXLCB0aGVuIExTUCByZWNvdmVyeSBjYW4g b25seSBwcm90ZWN0DQo+IHRoZSBQVyBpbiBpbmRpdmlkdWFsIHNlZ21lbnRzLiAgVGhpcyBt ZWFucyB0aGF0IGEgc2luZ2xlIExTUA0KPiByZWNvdmVyeSBhY3Rpb24gY2Fubm90IHByb3Rl Y3QgYWdhaW5zdCBhIGZhaWx1cmUgb2YgYSBQVyBzd2l0Y2hpbmcNCj4gcG9pbnQgKGFuIFMt UEUpLg0KPiBXaGVuIHByb3RlY3RpbmcgYWdhaW5zdCBhbiBBQyBvciBUL1MtUEUgZmFpbHVy ZSBieSBkdWFsDQo+IGNvbm5lY3Rpdml0eSwgUFcgcmVkdW5kYW5jeSBtZWNoYW5pc21zIHBy b3ZpZGUgbWVhbnMgZm9yIHRoZSBQRXMgdG8NCj4gY29vcmRpbmF0ZSBvdmVyIHdoaWNoIExT UCB0aGUgdHJhZmZpYyBvZiB0aGUgUFcgaXMgY2FycmllZC4NCj4gSSBhbHNvIGRvdWJ0IHdo eSB0aGVyZSBpcyBhIG5lZWQgZm9yIGFkZGl0aW9uYWwgbWVjaGFuaXNtLg0KPiBCZXN0IHJl Z2FyZHMsDQo+IE51cml0DQo+DQo+IEZyb206IHB3ZTMtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IGV4dCBBbGV4YW5k ZXIgVmFpbnNodGVpbg0KPiBTZW50OiBNb25kYXksIEp1bmUgMTMsIDIwMTEgMzo0MyBQTQ0K PiBUbzogbWEueXV4aWFAenRlLmNvbS5jbg0KPiBDYzogbXBsc0BpZXRmLm9yZzsgcHdlM0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BXRTNdIFttcGxzXSBTZWVraW5nIGZlZWRiYWNr IG9uIEktRCAiTVBMUy1UUA0KPiBMaW5lYXJQcm90ZWN0aW9uIEFwcGxpY2FiaWxpdHkgdG8g TVMtUFciDQo+DQo+IERlYXIgTWEgYW5kIGFsbCwNCj4gQWRkaW5nIHRoZSBQV0UzIFdHIHRv IG15IHJlc3BvbnNlLg0KPg0KPiBUaGUgUFcgcmVkdW5kYW5jeSBtZWNoYW5pc20gc3VwcG9y dHMgbGluZWFyIHByb3RlY3Rpb24gb2YgTVMtUFdzIGFzDQo+IG9uZSBvZiBtYW55IGFkZGl0 aW9uYWwgYXBwbGljYXRpb24gdXNlIGNhc2VzOg0KPiBBcHBlbmRpeCBBIG9mIHRoZSBQVyBy ZWR1bmRhbmN5IEJpdCBkcmFmdCBkZXNjcmliZXMgNSBhcHBsaWNhdGlvbg0KPiB1c2VzIGNh c2VzIGluIGFkZGl0aW9uIHRvIE1TLVBXIHdpdGggc2luZ2xlLWhvbWVkIENFcyAod2hpY2gg aXMNCj4gbGlzdGVkIHRoZXJlIGFzIHVzZSBjYXNlIDUpLg0KPiBBbmQgaXQgaXMgZXF1YWxs eSBhcHBsaWNhYmxlIHRvIElQL01QTFMgYW5kIE1QTFMgLSB3aXRoIHRoZSBoZWxwIG9mICB0 aGUNCj4gU3RhdGljIFBXIFN0YXR1cyBNZXNzYWdlcyBkcmFmdCggaWYsIGZvciB3aGF0ZXZl ciByZWFzb24sIHlvdSBkbyBub3QNCj4gd2FudCAgdG8sIG9yIGNhbm5vdCwgdXNlIFJGQyA0 NDQ3KS4NCj4NCj4gSGVuY2UgSSBkb3VidCB0aGUgbmVlZCBmb3IgeWV0IGFub3RoZXIgUFcg cmVkdW5kYW5jeSAgbWVjaGFuaXNtIHdpdGgNCj4gbmFycm93IHNjb3BlIG9mIGFwcGxpY2Fi aWxpdHkuDQo+DQo+IFJlZ2FyZHMsDQo+ICAgICAgU2FzaGENCj4NCj4gRnJvbTogbXBscy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YNCj4gbWEueXV4aWFAenRlLmNvbS5jbg0KPiBTZW50OiBNb25kYXksIEp1bmUgMTMs IDIwMTEgMzoyNSBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21w bHNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLVRQIExpbmVhcg0KPiBQcm90ZWN0 aW9uIEFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+DQo+IEhpIGFsbCwNCj4NCj4gVGhlIGxp bmVhciBwcm90ZWN0aW9uIG1lY2hhbmlzbSBmb3IgTFNQIGFuZCBQVyhpbmNsdWRpbmcgTVMt UFcpDQo+IHNob3VsZCBiZSB0aGUgc2FtZSBhbmQgaXQgaXMgdmFsdWFibGUgdG8gZGVzY3Jp YmUgaXQgY2xlYXJseS4NCj4NCj4gQlRXLCB0aGVyZSBpcyBhIHR5cG8sIGl0IGlzICJULVBF IFoiIGluc3RlYWQgb2YgIlQtUEUgQiIuDQo+DQo+ICAiDQo+ICAgRmlndXJlIDEgaWxsdXN0 cmF0ZXMgc3VjaCBhIHNjZW5hcmlvLCB3aGVyZSB0d28gTVMtUFdzIGFyZQ0KPiAgIGVzdGFi bGlzaGVkIGJldHdlZW4gVC1QRSBBIGFuZCBULVBFIEIsIG92ZXIgUy1QRXMgMS0yIGFuZCAz LTQNCj4gICByZXNwZWN0aXZlbHkuIEVhY2ggUFcgc2VnbWVudCBpcyBlc3RhYmxpc2hlZCBv dmVyIGFuIExTUCAoZS5nLiBQVy0NCj4gICBzMTIgb3ZlciBMU1AxMikuDQo+ICAiDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERhbmllbCBDb2huDQo+IFNlbnQ6 IFR1ZXNkYXksIE1heSAxNywgMjAxMSA0OjE0IFBNDQo+IFRvOiBtcGxzDQo+IFN1YmplY3Q6 IFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLVRQIExpbmVhciBQcm90ZWN0aW9uDQo+ IEFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+IEltcG9ydGFuY2U6IEhpZ2gNCj4NCj4gSGkg TVBMU2VycywNCj4NCj4gSSB1cGxvYWRlZCAiTVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbiBB cHBsaWNhYmlsaXR5IHRvIE1TLVBXIiBJLUQNCj4gKGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWNvaG4tbXBscy10cC1wdy1wcm90ZWN0aW9uLTAwKQ0KPg0KPiBUaGUgYWJz dHJhY3QgZ29lczoNCj4NCj4gT25lIG9mIHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIE1QTFMg dHJhbnNwb3J0IHByb2ZpbGUgW1JGQyA1NjU0XSBpcw0KPiB0byBwcm92aWRlIGxpbmVhciBw cm90ZWN0aW9uIGZvciB0cmFuc3BvcnQgcGF0aHMsIHdoaWNoIGluY2x1ZGUgYm90aA0KPiBM U1BzIGFuZCBQV3MuIFRoZSBmdW5jdGlvbmFsIGFyY2hpdGVjdHVyZSBkZXNjcmliZWQgaW4g W1N1cnZpdkZ3a10NCj4gaXMgYXBwbGljYWJsZSB0byBib3RoIExTUCBhbmQgUFdzLCBob3dl dmVyIFtMaW5lYXJQcm90XSBkb2VzIG5vdA0KPiBleHBsaWNpdGx5IGRlc2NyaWJlIG1lY2hh bmlzbXMgZm9yIFBXIHByb3RlY3Rpb24gaW4gTVBMUy1UUC4NCj4NCj4gVGhpcyBkb2N1bWVu dCBleHRlbmRzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBsaW5lYXIgcHJvdGVjdGlvbg0K PiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFtMaW5lYXJQcm90XSB0byBNUExTLVRQIHNlZ21l bnRlZCBQV3MNCj4gKE1TLVBXcykgYXMgZGVmaW5lZCBpbiBbUkZDIDYwNzNdLg0KPg0KPiBD b3VsZCB5b3UgcGxlYXNlIHJldmlldyBpdCBhbmQgc2VuZCBmZWVkYmFjayB0byB0aGUgbWFp bGluZyBsaXN0IG9yDQo+IGRpcmVjdGx5IHRvIHRoZSBhdXRob3I/DQo+DQo+IExvb2tpbmcg Zm9yd2FyZCB0byB5b3VyIGZlZWRiYWNrLA0KPg0KPiBEYW5pZWwNCj4gVGhpcyBlLW1haWwg bWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlu cw0KPiBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBi ZSBwcm9wcmlldGFyeSB0bw0KPiBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZQ0KPiBpbmZvcm0gdXMgYnkgZS1t YWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kDQo+ IGFsbCBjb3BpZXMgdGhlcmVvZi4NCj4gVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRl ZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucw0KPiBpbmZvcm1hdGlvbiB3 aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0bw0K PiBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIHBsZWFzZQ0KPiBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgs IGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kDQo+IGFsbCBjb3BpZXMgdGhlcmVv Zi4NCj4gVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVu dCBvbmx5IGFuZCBjb250YWlucw0KPiBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJ QUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0bw0KPiBFQ0kgVGVsZWNvbS4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZQ0K PiBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0 aGUgb3JpZ2luYWwgYW5kDQo+IGFsbCBjb3BpZXMgdGhlcmVvZi4gqW16udo/P2JyPg0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBz ZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZp ZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KDQpUaGlzIGVtYWlsIGFu ZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQoNClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KDQoN ClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25s eSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3 aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5 IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFu ZCBhbGwgY29waWVzIHRoZXJlb2YuDQoNCg== --_000_A3C5DF08D38B6049839A6F553B331C76EA32634CFEILPTMAIL02eci_ Content-Type: text/html; charset="gb2312" content-transfer-encoding: quoted-printable

Dear Ma,

Lots of thanks for our response= . Please see some comments/answers inline below.

 

Regards,

   =   Sasha

 

From: ma.yuxia@zte.com.cn= [mailto:ma.yuxia@zte.com.cn]
Sent: Monday, June 20, 2011 11:31 A= M
To: Alexander Vainshtein
Cc: Daniel Cohn; mpls@ietf.or= g; Sprecher, Nurit (NSN - IL/Hod HaSharon); pwe3@ietf.org
Subject:= =B4=F0=B8=B4: RE: [mpls]= [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability t= o MS-PW"

&nb= sp;


Hi Sasha,

"Linear protection" is= different from "Multi-home= d CE redundancy" and ha= s no reference with AC.

[[[Sasha]]] Absolutely.  <= /o:p>


Working path(s) and protection path(s= ) have same source and sink endpoints in linear protection type.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4= 97D'>[[[Sasha]]] Of course.



= IMHO, When S-PE fails, it is more simple to use "Linear protection"= ; to protect it.

=

[[[Sasha]]] Well, simplicity , like beauty,= is in the eye of the beholderJ.

But IMHO  = introducing multiple simple ad hoc solutions (each for its specific case) an= d maintaining them  eventually make your life more  complicated wh= en compared with one generic mechanism=A1=AD

 

Best Regards,
Ma


Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> =D0=B4=D3=DA 2011-06-14 20:02:10:

> Daniel,
> Please see more inline (bold purple italics). I= =A1=AFve also stripped the
> portions of the text that a= re not related to this round of comments.
>  
> Regards,
&g= t;  <= tt>  Sasha
&g= t; > From: Dan= iel Cohn [mailto:DanielC@orckit.com]
> Sent: Tuesday, June 14, 2011 2:34 PM
> To:= Alexander Vainshtein
> Cc: mpls@ietf.org; pwe3@ietf.org; Spr= echer, Nurit (NSN - IL/Hod
> HaSharon); ma.yuxia@zte.com.cn<= /tt>
> Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MP= LS-
> TPLinearProtectionApplicability to MS-PW"
>  
= > Hi Sasha, thanks again and see inline= with [DC].
>  <= /span>
> From: Alexander Va= inshtein [mailto:Alexander.Vainshtein@ecitele.com]
> Sent: Monday, June 13, 2011 6:11 PM<= br>> To: Daniel Cohn
> Cc: mpls@ietf.org; pwe3@ietf.or= g; Sprecher, Nurit (NSN - IL/Hod
> HaSharon); ma.yuxia@zte.c= om.cn
> Subject: RE: [mpls] [PWE3] Seeking feedback on I-D &q= uot;MPLS-
> TPLinearProtectionApplicability to MS-PW"
>   > Daniel and all,
= > Please see some comments inline be= low.
> <= tt> <= /tt>
> Regards,
= >      Sasha >  
> From: Daniel Cohn [mailto:DanielC@orckit.co= m]
> Sent: Monday, J= une 13, 2011 5:55 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSh= aron); Alexander Vainshtein;
> ma.yuxia@zte.com.cn
<= tt>> Cc: mpls@ietf.org; pwe3@ietf.org
> Subject: RE: [mpls= ] [PWE3] Seeking feedback on I-D "MPLS-
> TPLinearProtec= tion Applicability to MS-PW"
>  
&= gt; Hi,
>  
> Thanks all for the fee= dback. I believe we all agree that PW
> protection is only required in the event of S-PE failure= at an MS-PW
> =A8C this  is clearly= stated in the draft. Now, both Sasha and Nurit
> mention that the PW redundancy mechanism can m= eet the MPLS-TP PW
> protection requirements. > [[[Sasha]]] =A1=AD snipped =A1=AD
> E.g., the PW redundancy mechanisms take care= of dual-homed CEs in
&= gt; SS- and MS-PWs =A8C some= thing that liner protection of PWs cannot do.
> [DC] I=A1=AFm afraid I don=A1=AFt follow you here. Where does PW redundancy
> take care of dual-homed CE? Actually PW redund= ancy draft explicitly
> states: =A1=B0The method for dual-homing of CE1 to PE1 and to= PE3 nodes,
> and th= e protocols used, are outside the scope of this document=A1=B1.
> [[[Sasha]]] Quoting from the draft:
> 15.2. Multiple Multi-homed CEs with sing= le SS-PW redundancy
>= ;  
>        <= tt>    |<-= ------------- Emulated Service ---------------->|  
<= tt>>     <= /span>&n= bsp;  =     <= /tt> |       <= tt> <= /tt>              <= /span>       <= tt> <= /tt>              <= /span>      | =  =
>              |  <= tt>      =  |<------- Pseudo Wire ------>|          |  
>           &nb= sp;  |          |   =       &nbs= p;                  |    =      | =  =
>              |  <= tt>      =  |    |<-- PSN T= unnels-->|   =  |       <= tt> <= /tt>  |  
>          =  |   &nbs= p;      V    V    <= /span> V    V          |  =
>       <= tt> <= /tt>      V  <= tt>  AC   &nbs= p;+----+  <= tt>      =       <= tt> <= /tt>  +----+     AC   V  
<= span style=3D'font-size:10.0pt'>>      =  +-----+    |  =   |....|.......PW1........|....| =     |   <= /span>&n= bsp;+-----+  
>       <= tt> <= /tt>|     |----------| PE1|......   .........| PE3|----------|     | <= /tt> 
>       =  | CE1 |  =     <= /tt>   +----+     =  \ /  PW3    +----+ &nbs= p;        | CE2 |  
>     &nbs= p;  |     | <= /tt>        <= tt> <= /tt>+----+       X          +----+          |    = |
>     <= /tt>   |     |        <= tt>|    |....= ../ \..PW4....|    = |       =  =  |   | =  
>       <= tt> <= /tt>|     |----------| PE2|   <= /span>&n= bsp;  =     <= /tt>       | PE4|--------= - |  = |  
>     <= tt> <= /tt>  +-----+    |     |....|.....PW2..........|....|  =   |    <= /span>+-----+   >              <= /span>     AC    +----+       =  =          +----+  = =  AC  <= tt>    
>      
> <= /span>&n= bsp;  =
>    =  Figure 15-2 Multiple Multi-homed CEs with single= SS-PW redundancy  
>  
>  <= /span>  The application in Figure 15-2 makes use of the= Independent mode of
&g= t;  <= tt>operation.
>  
>    = ;CE1 is dual-homed to PE1 a= nd PE2. CE2 is dual-homed PE3 and PE4. The
>    method for dual-= homing and the used protocols are outside the scope
>    of this d= ocument.  Note that the= PSN tunnels are not shown in this
>    = ;figure for clarity. Howeve= r, it can be assumed that each of the PWs
>   shown is encapsulat= ed in a separate PSN tunnel.
>  
> <= /span>&n= bsp;  = Assume that the AC from CE1 to PE1 is Activ= e, from CE1 to PE2 is
&= gt;  = Standby; furthermore, assume that the A= C from CE2 to PE3 is Standby
>    and from CE2 to PE4 is Active. T= he method of deriving Active/Standby
>   &nb= sp;status of the AC is outs= ide the scope of this document.
>  
>= ;    PE1 advertises the preferential status &q= uot;Active" and operational
>    <= /span>status "Pseudowire forw= arding" for pseudowires PW1 and PW4 connected
>    to PE3 and= PE4. This status reflects the forwarding state of the AC
>    att= ached to PE1. PE2 advertises preferential status "Standby" and
>  =  operational status "Pseudowire forwarding" for pseudow= ires PW2 and
>  =  PW3 to PE3 and PE4. PE3 advertises preferential= status "Standby" and
>   =  operational status "Pseu= dowire forwarding" for pseudowires PW1 and
>    PW3 to PE1 an= d PE2. PE4 advertise the preferential status "Active" =
>    and operational status "Pseudowire forwarding" for pseudowires= PW2
> <= tt> <= /tt>  and PW4 to PE2 and PE1 respectively. Thus by matching= the local and
> &nbs= p;  remote preferential forwarding status of "= ;Active" and operational
>    status of "Pseudowire forw= arding" of pseudowires, the PE nodes
>   determine which PW= should be in the Active state. In this case it is
>    PW4 that w= ill be selected.  
= >  
> =    On failure of the AC between CE1 and PE1, the fo= rwarding state of
>= =    the AC on PE2 is changed to Active. PE2 th= en announces the newly
= >   =  changed 'preferential forwarding' stat= us bit of "active" to PE3 and
>  = =  PE4. PE1 will adverti= se a PW status notification message indicating
>    that the AC be= tween CE1 and PE1 is operationally down. PE2 and PE4
>    match th= e local and remote preferential forwarding status of
>    "Ac= tive" and operational status "Pseudowire forwarding" and sele= ct
>    PW2 as the new active pseudowire to send traffic to.
>  
<= tt>>    On= failure of PE1 node, PE2 will detect it and will transition the
>    forwarding state of its AC to Active. The method by which PE2 =
>    detects that PE1 is down is outside the scope of this document. PE2=
> <= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =  then announces the newly changed 'preferential forwarding' s= tatus
> =  =  bit of "Active" to PE3 and PE4. PE2 and PE4= match the local and
&g= t;  <= tt>remote preferential forwarding status of= "Active" and operational
>   &nbs= p;status "Pseudowire f= orwarding" and select PW2 as the new active
>    pseudowire t= o send traffic to. Note that PE3 and PE4 may have
>    detected t= hat the PW to PE1 went down via T-LDP Hello timeout or via
<= tt>>    ot= her means. However, they will not be able to forward user traffic
>    until they received the updated status bit from PE2.
= >  
>    Because each= dual-homing algorithm running on the two node sets,
>    i.e., {C= E1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC
>    inde= pendently, there is a need to signal the active status of the AC
>    such that the PE nodes can select a common active PW for end-to-end <= /span>
>    forwarding between CE1 and CE2 as per the procedures in the
>    independent mode.
>  
>= =    Note that any primary/secondary procedures= , as defined in sections
>   <= tt> <= /tt>5.1.  and 5.2. , do not apply in this use case as the Acti= ve/Standby
> =    status is driven by the AC forwarding state as d= etermined by the AC
>= ;    dual-homing protocol used. >  
>  
> I believe you=A1=AFve taken your =A1=B0out of scope=A1=B1 refer= ence from this text,
>= ; but IMHO you misinterpreted it.
> What it means (or so I read it) is that specific dual-homing=
> protocol is out o= f scope as long as it meets certain assumptions.
> Aside: It would be good if the authors of the= PW redundancy drafts
&= gt; could explicitly specify these assumptions.
>  
> [[[Sasha]]] =A1=AD snipped =A1=AD
= >  
> Now let= = =A1=AFs turn our attention= back to whether the PW redundancy
> draaft can be used to meet MPLS-TP PW protection requiremen= ts. I can
> identify the following reasons why in its current= form it doesn=A1=AFt:
>  
<= tt>> -          It explicitly (=A1=B0outside the scope=A1=B1) does not define
>= ; protection triggers and how to handle coexisting triggers, as
> requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79
> [[[Sasha]]] So what?= Definition of triggers is orthogonal to how
> coordinated protection switching happens.
> [DC] It is. But still it= needs to be defined by the recovery
> framework, e.g. what should the endpoint do when one PW i= s in SF and
> the other is in SD, or when both are in SD. Ope= rators expect well-
> defined behavior in these and other sce= narios, and PW redundancy
> does not define them (because it= was not in their scope).
> [[[Sasha]]] I wonder if you have followed the discussion regarding <= /span>
> ability to define S= D condition for LSPs and PWs on the MPLS-TP list?
> IMO it is= not possible to define it in a meaningful way. Hence I do
>= not see a proposal that does not address a scenario that does not
= > exist in reality as a flawed one.
>  
> -    = ;      It does not s= upport the ability to distinguish between
> different types of triggers (i.e. one end doesn= =A1=AF= t know why the other=
> end triggered switch), as= requested in RFC 5654 (MPLS-TP
> Requirements), req #77
> -        <= /span>  It does not define revertive/nonrevertive behavi= or, as
> requested i= n RFC 5654 (MPLS-TP Requirements), req #64
> -     <= tt> <= /tt>    It does not define holdoff support, which is especially
> important to avoid race conditions wi= th LSP protection when it exists
> -    = ;      It doesn=A1=AF= t support 1+1 mode, as requ= ested in RFC 5654
>= (MPLS-TP Requirements), req #65
> [[[Sasha]]] All these claims are correct =A8C<= span style=3D'font-size:10.0pt'> and  this should not be a
> surprise, because MPLS-TP requirements have been defined mu= ch later
> than the PW redundancy mechanism. > But I do not think that this just= ifies co-existence of two different
> mechanisms.
> [DC] So how do you propose to meet the PW protection requirement?=
> -       &nb= sp;  It=A1=AFs a two-phase protocol, with the consequent impact on timing
> [[[Sasha]]] Could you p= lease elaborate? [DC] In draft-ietf-mpls-tp-
> linear-protect= ion, each endpoint will immediately switch traffic to
> the= other path upon identifying an SF condition in a path, without
> waiting for the far end to acknowledge the switch (1-phase). In PW
> redundancy, an endpoint detecting an SF condition in a path w= ill not
> switch until the far end has acknowledged the switc= h (2-phase).
> Needless to say, recovery is slower in a 2-ph= ase protocol.
> [[[S= asha]]] To the best of my understanding, 1-phase protection is <= span style=3D'font-size:10.0pt'>
> only possible in 1+1 unidirecti= onal architectures. And yes, I know
> that MPLS-TP requires= a mechanism to suppor= t this; whether anybody
> would really do that in the packet-switching network is not clear to
> me. And I acknowledge that the PW redundancy drafts do not s= upport
> 1+1 unidirectional scheme.
>  
> -    <= tt>    It doe= sn=A1=AFt define retransmiss= ion of protection
>= coordination messages, so loss of a single PDU can result in
&= gt; switchover not taking place, thus not supporting sub-50 ms recovery
> in this case
> [[[Sasha]]] The PW redundancy protocol runs either on top of LDP
> (which benefits from= TCP retransmissions) or on top of static PW
> status messag= es (where retransmission is defined).
> [DC] True =A8C but static PW status defines slow retransmission (=A1=B0will
> be transmitted twice at an initial interval of one sec= ond) while
> draft-ietf-mpls-tp-linear-pro= tection specifies fast retransmission
> when required for fa= st recovery (section 3.1.4).
>  
> I= n summary, PW redundancy was not designed with TP requirements in
> mind, and as such does not m= eet the TP requirements. Of course
> modifications may be in= troduced, but why reinvent the wheel when
> there is a proto= col (draft-ietf-mpls-tp-linear-protection-06) in the
> standa= rds track that supports all the above requirements and can be
&= gt; applied to MS-PW protection with minor modifications?
> [[[Sasha]]] As I said, because the a= pplicability scope is by far too
> narrow to justify a dedicated protocol.
> [DC] If we were discussing designing a n= ew protocol, I might agree
= > with you. But from a practical standpoint, the PW protection draft=
> is not a dedicated protocol =A8C it=A1=AFs an applicability statement to an
> existing protocol. Both from the implementation and t= he operational
> point of view it defines a new use case for= an existing protocol and concept.
>  
= >  
> Regards= ,
> =  
> Daniel
<= span style=3D'font-size:10.0pt'>>  
>  
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On= Behalf Of
> Spreche= r, Nurit (NSN - IL/Hod HaSharon)
> Sent: Monday, June 13, 201= 1 4:02 PM
> To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn=
> Cc: mpls@ietf.org; pwe3@ietf.org
> Subject:= Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-
> TPLi= nearProtection Applicability to MS-PW"
>  
> Hi,
>= I would like to second Sasha.
> End-to-end PW protection (with diverse paths) does not scale, a= nd
> put hard restri= ctions on the utilization of the resources.  
> MPLS-TP PWs are carried across the network= inside MPLS-TP LSPs.
&= gt; Therefore, an obvious way to provide protection for a PW is to
= > protect the LSP that carries it.  
> If the PW is a multi-segment PW, then LSP reco= very can only protect
&= gt; the PW in individual segments.  This means that a single LSP
> recovery action cannot protect against a failure of= a PW switching
> point (an S-PE).
> When protecting against an AC or T/S-PE fai= lure by dual
> conne= ctivity, PW redundancy mechanisms provide means for the PEs to
= > coordinate over which LSP the traffic of the PW is carried.
> I also doubt why there is a n= eed for additional mechanism.
> Best regards,
> Nurit
>  = ;
> From: pwe3-bounc= es@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> ext Alexander Vainshtein
&= gt; Sent: Monday, June 13, 2011 3:43 PM
> To: ma.yuxia@zte.co= m.cn
> Cc: mpls@ietf.org; pwe3@ietf.org
> Subj= ect: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP
&g= t; LinearProtection Applicability to MS-PW"
>  
> Dear Ma and all,
> Adding the PWE3 WG to my response.
>  
> The PW redundancy mechanism supports linear protectio= n of MS-PWs as
> one= of many additional application use cases:
> Appendix A of the PW redundancy Bit draft describ= es 5 application
> u= ses cases in addition to MS-PW with single-homed CEs (which is
= > listed there as use case 5).
> And it is equally applicable to IP/MPLS and MPLS - with the= help of  the
> Static PW Status Messages d= raft( if, for whatever reason, you do not
> want =  = to, or cannot, use RFC 4447).
>   > Hence I doubt the need for yet an= other PW redundancy  me= chanism with
> narrow= scope of applicability.
>  
> Rega= rds,
> <= tt> <= /tt>    Sasha
>  
> From: mpls-bounces@ietf= .org [mailto:mpls-bounces@ietf.org] On Behalf Of
> ma.yuxia@zte.com.cn
> Sent: Mo= nday, June 13, 2011 3:25 PM
> To: mpls@ietf.org
&= gt; Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear > Protection Applicability to MS-PW"
>  
> Hi all, >
> The linear protection mechanism for LSP and PW(= including MS-PW)
> should be the same and it is valuable to= describe it clearly.
>
> BTW, there is a ty= po, it is "T-PE Z" instead of "T-PE B".
>= ;
>  &q= uot;
> <= tt> <= /tt> Figure 1 illustrates such a scenar= io, where two MS-PWs are
>   established b= etween T-PE A and T-PE B, over S-PEs 1-2 and 3-4
>   respectively. Each PW segment is established over an LSP (e.g. PW-=
> <= span style=3D'font-size:10.0pt;font-family:"Courier New"'> = s12 over LSP12).
>  "
&= gt; -----Original Message-----<= br>> From: Daniel Cohn
> Sent: Tuesday, May 17, 2011= 4:14 PM
> To: mpls
> Subject: Seeking feedbac= k on I-D "MPLS-TP Linear Protection
> Applicability to M= S-PW"
> Importance: High
>
&= gt; Hi MPLSers,
>
> I uploaded "MPLS-TP= Linear Protection Applicability to MS-PW" I-D
> (http:/= /tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)
> <= /tt>
> The abstract goes:
>
> One o= f the requirements of the MPLS transport profile [RFC 5654] is
&= gt; to provide linear protection for transport paths, which include both
> LSPs and PWs. The functional architecture described in [Surviv= Fwk]
> is applicable to both LSP and PWs, however [LinearProt= ] does not
> explicitly describe mechanisms for PW protection= in MPLS-TP.
>
> This document extends the ap= plicability of the linear protection
> mechanism described in= [LinearProt] to MPLS-TP segmented PWs
> (MS-PWs) as defined= in [RFC 6073].
>
> Could you please review i= t and send feedback to the mailing list or
> directly to the= author?
>
> Looking forward to your feedbac= k,
>
> Daniel
> This e-mail message is intended for the recipien= t only and contains
>= ; information which is CONFIDENTIAL and which may be proprietary to > ECI Telecom. If you have received this transmission in error, plea= se
> inform us by e-mail, phone or fax, and then delete the o= riginal and
> all copies thereof.
> This e-mail message is intended for the rec= ipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to
> ECI Telecom. If you have received this transmission in error,= please
> inform us by e-mail, phone or fax, and then delete= the original and
> all copies thereof.
= > This e-mail message is intended for th= e recipient only and contains <= br>> information which is CONFIDENTIAL and which may be proprietary t= o
> ECI Telecom. If you have received this transmission in e= rror, please
> inform us by e-mail, phone or fax, and then de= lete the original and
> all copies thereof. =A9mz=B9=DA??br>

 
-------------------------------------=
-------------------
ZTE Information=
 Security =
Notice: The information contained in this mail is solely&n=
bsp;property of=
 the sender's organization. m=
ail communication is confidential. Recipients&=
nbsp;named abov=
e are obligated to =
maintain secrec=
y and are not permitted to disclose the of this communication to others.
This email=
 and any files transmitted with&nb=
sp;it are confidential and intended&nb=
sp;solely for the use of th=
e individual or entity&n=
bsp;to whom they are If you have received this ema=
il in error please =
notify the originator of the message. Any views expressed in this message are those&=
nbsp;of the individual sender.
This message has been scanned for viruses and by=
 ZTE Anti-Spam system.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76EA32634CFEILPTMAIL02eci_-- From DanielC@orckit.com Mon Jun 20 02:50:53 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85D411E8119; Mon, 20 Jun 2011 02:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.193 X-Spam-Level: X-Spam-Status: No, score=0.193 tagged_above=-999 required=5 tests=[AWL=-1.925, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_CHARSET_FARAWAY=2.45, SARE_HTML_SINGLETS=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89rUhYk8pISZ; Mon, 20 Jun 2011 02:50:50 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 44BA111E80A9; Mon, 20 Jun 2011 02:50:47 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2F2F.B73C97F0" Date: Mon, 20 Jun 2011 12:50:38 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306D5F116@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwvJHl1sOtCtFDMRBOfIAQ+qt8VRgAAbbvgAAI39/A= References: From: "Daniel Cohn" To: "Alexander Vainshtein" , Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 09:50:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2F2F.B73C97F0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Sasha, =20 I think the main question here is why call PW linear protection an = ad-hoc mechanism when it=A1=AFs simply an extension of LSP linear = protection. From an implementation point of view, the differences are = minimal =A8C you could even say semantic. I think this is what Ma means = by simplicity and I wholly agree with her =A8C you have a single = mechanism to protect all transport paths =A8C be them LSP or PW.=20 =20 My two cents, =20 DC =20 From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Monday, June 20, 2011 11:50 AM To: ma.yuxia@zte.com.cn Cc: Daniel Cohn; mpls@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); = pwe3@ietf.org Subject: RE: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear = Protection Applicability to MS-PW" =20 Dear Ma, Lots of thanks for our response. Please see some comments/answers inline = below. =20 Regards, Sasha =20 From: ma.yuxia@zte.com.cn [mailto:ma.yuxia@zte.com.cn]=20 Sent: Monday, June 20, 2011 11:31 AM To: Alexander Vainshtein Cc: Daniel Cohn; mpls@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); = pwe3@ietf.org Subject: =B4=F0=B8=B4: RE: [mpls] [PWE3] Seeking feedback on I-D = "MPLS-TPLinearProtectionApplicability to MS-PW" =20 Hi Sasha,=20 "Linear protection" is different from "Multi-homed CE redundancy" and = has no reference with AC.=20 [[[Sasha]]] Absolutely. =20 Working path(s) and protection path(s) have same source and sink = endpoints in linear protection type.=20 [[[Sasha]]] Of course. IMHO, When S-PE fails, it is more simple to use "Linear protection" to = protect it.=20 [[[Sasha]]] Well, simplicity , like beauty, is in the eye of the = beholderJ.=20 But IMHO introducing multiple simple ad hoc solutions (each for its = specific case) and maintaining them eventually make your life more = complicated when compared with one generic mechanism=A1=AD =20 Best Regards,=20 Ma=20 Alexander Vainshtein =D0=B4=D3=DA = 2011-06-14 20:02:10: > Daniel,=20 > Please see more inline (bold purple italics). I=A1=AFve also stripped = the > portions of the text that are not related to this round of comments.=20 > =20 > Regards,=20 > Sasha=20 > =20 > From: Daniel Cohn [mailto:DanielC@orckit.com]=20 > Sent: Tuesday, June 14, 2011 2:34 PM > To: Alexander Vainshtein > Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod=20 > HaSharon); ma.yuxia@zte.com.cn > Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS- > TPLinearProtectionApplicability to MS-PW"=20 > =20 > Hi Sasha, thanks again and see inline with [DC].=20 > =20 > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 > Sent: Monday, June 13, 2011 6:11 PM > To: Daniel Cohn > Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod=20 > HaSharon); ma.yuxia@zte.com.cn > Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS- > TPLinearProtectionApplicability to MS-PW"=20 > =20 > Daniel and all,=20 > Please see some comments inline below.=20 > =20 > Regards,=20 > Sasha=20 > =20 > From: Daniel Cohn [mailto:DanielC@orckit.com]=20 > Sent: Monday, June 13, 2011 5:55 PM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein;=20 > ma.yuxia@zte.com.cn > Cc: mpls@ietf.org; pwe3@ietf.org > Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS- > TPLinearProtection Applicability to MS-PW"=20 > =20 > Hi,=20 > =20 > Thanks all for the feedback. I believe we all agree that PW=20 > protection is only required in the event of S-PE failure at an MS-PW > =A8C this is clearly stated in the draft. Now, both Sasha and Nurit=20 > mention that the PW redundancy mechanism can meet the MPLS-TP PW=20 > protection requirements.=20 > [[[Sasha]]] =A1=AD snipped =A1=AD=20 > E.g., the PW redundancy mechanisms take care of dual-homed CEs in=20 > SS- and MS-PWs =A8C something that liner protection of PWs cannot do.=20 > [DC] I=A1=AFm afraid I don=A1=AFt follow you here. Where does PW = redundancy=20 > take care of dual-homed CE? Actually PW redundancy draft explicitly=20 > states: =A1=B0The method for dual-homing of CE1 to PE1 and to PE3 = nodes,=20 > and the protocols used, are outside the scope of this document=A1=B1.=20 > [[[Sasha]]] Quoting from the draft:=20 > 15.2. Multiple Multi-homed CEs with single SS-PW redundancy=20 > =20 > |<-------------- Emulated Service ---------------->| =20 > | | =20 > | |<------- Pseudo Wire ------>| | =20 > | | | | =20 > | | |<-- PSN Tunnels-->| | | =20 > | V V (not shown) V V | =20 > V AC +----+ +----+ AC V =20 > +-----+ | |....|.......PW1........|....| | = +-----+ =20 > | |----------| PE1|...... .........| PE3|----------| = | =20 > | CE1 | +----+ \ / PW3 +----+ | CE2 = | =20 > | | +----+ X +----+ | = |=20 > | | | |....../ \..PW4....| | | = | =20 > | |----------| PE2| | PE4|--------- | = | =20 > +-----+ | |....|.....PW2..........|....| | = +-----+ =20 > AC +----+ +----+ AC =20 > =20 > =20 > Figure 15-2 Multiple Multi-homed CEs with single SS-PW redundancy = =20 > =20 > The application in Figure 15-2 makes use of the Independent mode of = > operation.=20 > =20 > CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. = The=20 > method for dual-homing and the used protocols are outside the scope = > of this document. Note that the PSN tunnels are not shown in this=20 > figure for clarity. However, it can be assumed that each of the PWs = > shown is encapsulated in a separate PSN tunnel.=20 > =20 > Assume that the AC from CE1 to PE1 is Active, from CE1 to PE2 is=20 > Standby; furthermore, assume that the AC from CE2 to PE3 is Standby = > and from CE2 to PE4 is Active. The method of deriving = Active/Standby=20 > status of the AC is outside the scope of this document.=20 > =20 > PE1 advertises the preferential status "Active" and operational=20 > status "Pseudowire forwarding" for pseudowires PW1 and PW4 = connected=20 > to PE3 and PE4. This status reflects the forwarding state of the AC = > attached to PE1. PE2 advertises preferential status "Standby" and=20 > operational status "Pseudowire forwarding" for pseudowires PW2 and=20 > PW3 to PE3 and PE4. PE3 advertises preferential status "Standby" = and=20 > operational status "Pseudowire forwarding" for pseudowires PW1 and=20 > PW3 to PE1 and PE2. PE4 advertise the preferential status "Active"=20 > and operational status "Pseudowire forwarding" for pseudowires PW2=20 > and PW4 to PE2 and PE1 respectively. Thus by matching the local and = > remote preferential forwarding status of "Active" and operational=20 > status of "Pseudowire forwarding" of pseudowires, the PE nodes=20 > determine which PW should be in the Active state. In this case it = is=20 > PW4 that will be selected. =20 > =20 > On failure of the AC between CE1 and PE1, the forwarding state of=20 > the AC on PE2 is changed to Active. PE2 then announces the newly=20 > changed 'preferential forwarding' status bit of "active" to PE3 and = > PE4. PE1 will advertise a PW status notification message indicating = > that the AC between CE1 and PE1 is operationally down. PE2 and PE4=20 > match the local and remote preferential forwarding status of=20 > "Active" and operational status "Pseudowire forwarding" and select=20 > PW2 as the new active pseudowire to send traffic to.=20 > =20 > On failure of PE1 node, PE2 will detect it and will transition the=20 > forwarding state of its AC to Active. The method by which PE2=20 > detects that PE1 is down is outside the scope of this document. PE2 = > then announces the newly changed 'preferential forwarding' status=20 > bit of "Active" to PE3 and PE4. PE2 and PE4 match the local and=20 > remote preferential forwarding status of "Active" and operational=20 > status "Pseudowire forwarding" and select PW2 as the new active=20 > pseudowire to send traffic to. Note that PE3 and PE4 may have=20 > detected that the PW to PE1 went down via T-LDP Hello timeout or = via=20 > other means. However, they will not be able to forward user traffic = > until they received the updated status bit from PE2.=20 > =20 > Because each dual-homing algorithm running on the two node sets,=20 > i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC=20 > independently, there is a need to signal the active status of the = AC=20 > such that the PE nodes can select a common active PW for end-to-end = > forwarding between CE1 and CE2 as per the procedures in the=20 > independent mode.=20 > =20 > Note that any primary/secondary procedures, as defined in sections=20 > 5.1. and 5.2. , do not apply in this use case as the = Active/Standby=20 > status is driven by the AC forwarding state as determined by the AC = > dual-homing protocol used.=20 > =20 > =20 > I believe you=A1=AFve taken your =A1=B0out of scope=A1=B1 reference = from this text, > but IMHO you misinterpreted it.=20 > What it means (or so I read it) is that specific dual-homing=20 > protocol is out of scope as long as it meets certain assumptions.=20 > Aside: It would be good if the authors of the PW redundancy drafts=20 > could explicitly specify these assumptions.=20 > =20 > [[[Sasha]]] =A1=AD snipped =A1=AD=20 > =20 > Now let=A1=AFs turn our attention back to whether the PW redundancy=20 > draaft can be used to meet MPLS-TP PW protection requirements. I can > identify the following reasons why in its current form it = doesn=A1=AFt:=20 > =20 > - It explicitly (=A1=B0outside the scope=A1=B1) does not = define=20 > protection triggers and how to handle coexisting triggers, as=20 > requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79=20 > [[[Sasha]]] So what? Definition of triggers is orthogonal to how=20 > coordinated protection switching happens.=20 > [DC] It is. But still it needs to be defined by the recovery=20 > framework, e.g. what should the endpoint do when one PW is in SF and > the other is in SD, or when both are in SD. Operators expect well- > defined behavior in these and other scenarios, and PW redundancy=20 > does not define them (because it was not in their scope).=20 > [[[Sasha]]] I wonder if you have followed the discussion regarding=20 > ability to define SD condition for LSPs and PWs on the MPLS-TP list? > IMO it is not possible to define it in a meaningful way. Hence I do=20 > not see a proposal that does not address a scenario that does not=20 > exist in reality as a flawed one.=20 > =20 > - It does not support the ability to distinguish between=20 > different types of triggers (i.e. one end doesn=A1=AFt know why the = other > end triggered switch), as requested in RFC 5654 (MPLS-TP=20 > Requirements), req #77=20 > - It does not define revertive/nonrevertive behavior, as=20 > requested in RFC 5654 (MPLS-TP Requirements), req #64=20 > - It does not define holdoff support, which is especially=20 > important to avoid race conditions with LSP protection when it exists=20 > - It doesn=A1=AFt support 1+1 mode, as requested in RFC 5654=20 > (MPLS-TP Requirements), req #65=20 > [[[Sasha]]] All these claims are correct =A8C and this should not be = a > surprise, because MPLS-TP requirements have been defined much later=20 > than the PW redundancy mechanism.=20 > But I do not think that this justifies co-existence of two different > mechanisms.=20 > [DC] So how do you propose to meet the PW protection requirement?=20 > - It=A1=AFs a two-phase protocol, with the consequent impact = on timing > [[[Sasha]]] Could you please elaborate? [DC] In draft-ietf-mpls-tp- > linear-protection, each endpoint will immediately switch traffic to=20 > the other path upon identifying an SF condition in a path, without=20 > waiting for the far end to acknowledge the switch (1-phase). In PW=20 > redundancy, an endpoint detecting an SF condition in a path will not > switch until the far end has acknowledged the switch (2-phase).=20 > Needless to say, recovery is slower in a 2-phase protocol.=20 > [[[Sasha]]] To the best of my understanding, 1-phase protection is=20 > only possible in 1+1 unidirectional architectures. And yes, I know=20 > that MPLS-TP requires a mechanism to support this; whether anybody=20 > would really do that in the packet-switching network is not clear to > me. And I acknowledge that the PW redundancy drafts do not support=20 > 1+1 unidirectional scheme.=20 > =20 > - It doesn=A1=AFt define retransmission of protection=20 > coordination messages, so loss of a single PDU can result in=20 > switchover not taking place, thus not supporting sub-50 ms recovery=20 > in this case=20 > [[[Sasha]]] The PW redundancy protocol runs either on top of LDP=20 > (which benefits from TCP retransmissions) or on top of static PW=20 > status messages (where retransmission is defined).=20 > [DC] True =A8C but static PW status defines slow retransmission = (=A1=B0will=20 > be transmitted twice at an initial interval of one second=A1=B1) while = > draft-ietf-mpls-tp-linear-protection specifies fast retransmission=20 > when required for fast recovery (section 3.1.4).=20 > =20 > In summary, PW redundancy was not designed with TP requirements in=20 > mind, and as such does not meet the TP requirements. Of course=20 > modifications may be introduced, but why reinvent the wheel when=20 > there is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the > standards track that supports all the above requirements and can be=20 > applied to MS-PW protection with minor modifications?=20 > [[[Sasha]]] As I said, because the applicability scope is by far too > narrow to justify a dedicated protocol.=20 > [DC] If we were discussing designing a new protocol, I might agree=20 > with you. But from a practical standpoint, the PW protection draft=20 > is not a dedicated protocol =A8C it=A1=AFs an applicability statement = to an=20 > existing protocol. Both from the implementation and the operational=20 > point of view it defines a new use case for an existing protocol and = concept.=20 > =20 > =20 > Regards,=20 > =20 > Daniel=20 > =20 > =20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of=20 > Sprecher, Nurit (NSN - IL/Hod HaSharon) > Sent: Monday, June 13, 2011 4:02 PM > To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn > Cc: mpls@ietf.org; pwe3@ietf.org > Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS- > TPLinearProtection Applicability to MS-PW"=20 > =20 > Hi,=20 > I would like to second Sasha.=20 > End-to-end PW protection (with diverse paths) does not scale, and=20 > put hard restrictions on the utilization of the resources. =20 > MPLS-TP PWs are carried across the network inside MPLS-TP LSPs.=20 > Therefore, an obvious way to provide protection for a PW is to=20 > protect the LSP that carries it. =20 > If the PW is a multi-segment PW, then LSP recovery can only protect=20 > the PW in individual segments. This means that a single LSP=20 > recovery action cannot protect against a failure of a PW switching=20 > point (an S-PE).=20 > When protecting against an AC or T/S-PE failure by dual=20 > connectivity, PW redundancy mechanisms provide means for the PEs to=20 > coordinate over which LSP the traffic of the PW is carried.=20 > I also doubt why there is a need for additional mechanism.=20 > Best regards,=20 > Nurit=20 > =20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of=20 > ext Alexander Vainshtein > Sent: Monday, June 13, 2011 3:43 PM > To: ma.yuxia@zte.com.cn > Cc: mpls@ietf.org; pwe3@ietf.org > Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP=20 > LinearProtection Applicability to MS-PW"=20 > =20 > Dear Ma and all,=20 > Adding the PWE3 WG to my response.=20 > =20 > The PW redundancy mechanism supports linear protection of MS-PWs as=20 > one of many additional application use cases:=20 > Appendix A of the PW redundancy Bit draft describes 5 application=20 > uses cases in addition to MS-PW with single-homed CEs (which is=20 > listed there as use case 5).=20 > And it is equally applicable to IP/MPLS and MPLS - with the help of = the=20 > Static PW Status Messages draft( if, for whatever reason, you do not > want to, or cannot, use RFC 4447).=20 > =20 > Hence I doubt the need for yet another PW redundancy mechanism with > narrow scope of applicability.=20 > =20 > Regards,=20 > Sasha=20 > =20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of=20 > ma.yuxia@zte.com.cn > Sent: Monday, June 13, 2011 3:25 PM > To: mpls@ietf.org > Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear=20 > Protection Applicability to MS-PW"=20 > =20 > Hi all,=20 >=20 > The linear protection mechanism for LSP and PW(including MS-PW)=20 > should be the same and it is valuable to describe it clearly.=20 >=20 > BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".=20 >=20 > "=20 > Figure 1 illustrates such a scenario, where two MS-PWs are=20 > established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4=20 > respectively. Each PW segment is established over an LSP (e.g. PW-=20 > s12 over LSP12).=20 > "=20 > -----Original Message----- > From: Daniel Cohn=20 > Sent: Tuesday, May 17, 2011 4:14 PM > To: mpls > Subject: Seeking feedback on I-D "MPLS-TP Linear Protection > Applicability to MS-PW" > Importance: High >=20 > Hi MPLSers, >=20 > I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D > (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00) >=20 > The abstract goes: >=20 > One of the requirements of the MPLS transport profile [RFC 5654] is > to provide linear protection for transport paths, which include both > LSPs and PWs. The functional architecture described in [SurvivFwk] > is applicable to both LSP and PWs, however [LinearProt] does not > explicitly describe mechanisms for PW protection in MPLS-TP. >=20 > This document extends the applicability of the linear protection > mechanism described in [LinearProt] to MPLS-TP segmented PWs=20 > (MS-PWs) as defined in [RFC 6073]. >=20 > Could you please review it and send feedback to the mailing list or > directly to the author?=20 >=20 > Looking forward to your feedback,=20 >=20 > Daniel=20 > This e-mail message is intended for the recipient only and contains=20 > information which is CONFIDENTIAL and which may be proprietary to=20 > ECI Telecom. If you have received this transmission in error, please > inform us by e-mail, phone or fax, and then delete the original and=20 > all copies thereof.=20 > This e-mail message is intended for the recipient only and contains=20 > information which is CONFIDENTIAL and which may be proprietary to=20 > ECI Telecom. If you have received this transmission in error, please > inform us by e-mail, phone or fax, and then delete the original and=20 > all copies thereof.=20 > This e-mail message is intended for the recipient only and contains=20 > information which is CONFIDENTIAL and which may be proprietary to=20 > ECI Telecom. If you have received this transmission in error, please > inform us by e-mail, phone or fax, and then delete the original and=20 > all copies thereof. =A9mz=B9=DA??br> =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof.=20 ------_=_NextPart_001_01CC2F2F.B73C97F0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Sasha,

 

I think the main question here is why call PW linear protection an = ad-hoc mechanism when it=A1=AFs simply an extension of LSP linear = protection. From an implementation point of view, the differences are = minimal =A8C you could even say semantic. I think this is what Ma means = by simplicity and I wholly agree with her =A8C you have a single = mechanism to protect all transport paths =A8C be them LSP or PW. =

 

My two cents,

 

DC

 

From:= = Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] =
Sent: Monday, June 20, 2011 11:50 AM
To: = ma.yuxia@zte.com.cn
Cc: Daniel Cohn; mpls@ietf.org; Sprecher, = Nurit (NSN - IL/Hod HaSharon); pwe3@ietf.org
Subject: RE: RE: = [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection = Applicability to MS-PW"

 

Dear Ma,

Lots of thanks for our response. Please see some comments/answers = inline below.

 

Regards,

     Sasha

 

From:= = ma.yuxia@zte.com.cn [mailto:ma.yuxia@zte.com.cn]
Sent: = Monday, June 20, 2011 11:31 AM
To: Alexander = Vainshtein
Cc: Daniel Cohn; mpls@ietf.org; Sprecher, Nurit = (NSN - IL/Hod HaSharon); pwe3@ietf.org
Subject: =B4=F0=B8=B4: RE: = [mpls] [PWE3] Seeking feedback on I-D = "MPLS-TPLinearProtectionApplicability to = MS-PW"

 


Hi = Sasha,

"Linear = protection" is different from "Multi-homed CE = redundancy" and = has no reference with AC.

[[[Sasha]]] Absolutely.  


Working = path(s) and protection path(s) have same source and sink endpoints in = linear protection type.

[[[Sasha]]] Of course.



IMHO, When = S-PE fails, it is more simple to use "Linear protection" to = protect it.

[[[Sasha]]] Well, simplicity , like beauty, is in the eye of the = beholderJ.

But IMHO  introducing multiple simple ad hoc solutions (each for = its specific case) and maintaining them  eventually make your life = more  complicated when compared with one generic = mechanism=A1=AD

 

Best = Regards,
Ma =


Alexander Vainshtein = <Alexander.Vainshtein@ecitele.com> =D0=B4=D3=DA 2011-06-14 20:02:10:

> Daniel, =
> Please see more inline = (bold purple italics). I=A1=AFve also = stripped the
> portions of the text that = are not related to this round of comments.
>   =
> Regards, =
>   =   =  Sasha
>   =
> From: Daniel Cohn = [mailto:DanielC@orckit.com]
> Sent: Tuesday, June 14, = 2011 2:34 PM
> = To: Alexander Vainshtein
> Cc: mpls@ietf.org; = pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod
> HaSharon); = ma.yuxia@zte.com.cn
> Subject: RE: [mpls] = [PWE3] Seeking feedback on I-D "MPLS-
> = TPLinearProtectionApplicability to MS-PW"
>   =
> Hi Sasha, thanks again and = see inline with [DC].
>   =
> From: Alexander Vainshtein = [mailto:Alexander.Vainshtein@ecitele.com]
> Sent: Monday, June 13, = 2011 6:11 PM
> = To: Daniel Cohn
> = Cc: mpls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - IL/Hod =
> HaSharon); = ma.yuxia@zte.com.cn
> Subject: RE: [mpls] = [PWE3] Seeking feedback on I-D "MPLS-
> = TPLinearProtectionApplicability to MS-PW"
>   =
> Daniel and = all,
> Please = see some comments inline below.
>   =
> Regards, =
>   =   =  Sasha
>   =
> From: Daniel Cohn = [mailto:DanielC@orckit.com]
> Sent: Monday, June 13, = 2011 5:55 PM
> = To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; =
> = ma.yuxia@zte.com.cn
> Cc: mpls@ietf.org; = pwe3@ietf.org
> = Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-
> TPLinearProtection = Applicability to MS-PW"
>   =
> Hi, =
>   =
> Thanks all for the = feedback. I believe we all agree that PW
> protection is only = required in the event of S-PE failure at an MS-PW
> =A8C this =  is clearly = stated in the draft. Now, both Sasha and Nurit
> mention that the PW = redundancy mechanism can meet the MPLS-TP PW
> protection = requirements.
> = [[[Sasha]]] =A1=AD snipped = =A1=AD
> = E.g., the PW redundancy mechanisms take care of dual-homed CEs in =
> SS- and = MS-PWs =A8C something = that liner protection of PWs cannot do.
> [DC] I=A1=AFm afraid I = don=A1=AFt follow = you here. Where does PW redundancy
> take care of dual-homed = CE? Actually PW redundancy draft explicitly
> states: =A1=B0The method = for dual-homing of CE1 to PE1 and to PE3 nodes,
> and the protocols used, = are outside the scope of this document=A1=B1. =
> [[[Sasha]]] = Quoting from the draft:
> 15.2. Multiple Multi-homed CEs with = single SS-PW redundancy
>   =
>   =   =   =   =   =   =  |<-------------- Emulated Service = ---------------->|   =
>   =   =   =   =   =   =  | =   =   =   =   =   =   =   =   =   =   =   =   =   =   =   =   =   =   =   =   =   =   =   =   =  | =  
> =   =   =   =   =   =   =  | =   =   =   =   =  |<------- Pseudo Wire ------>| =   =   =   =   =  | =  
> =   =   =   =   =   =   =  | =   =   =   =   =  | =   =   =   =   =   =   =   =   =   =   =   =   =   =  | =   =   =   =   =  | =  
> =   =   =   =   =   =   =  | =   =   =   =   =  | =   =  |<-- PSN = Tunnels-->|   =  | =   =   =   =   =  | =  
> =   =   =   =   =   =   =  | =   =   =   =   =  V =   =  V =   =  (not shown) =   V =   =  V =   =   =   =   =  | =  
> =   =   =   =   =   =   =  V =   =  AC =   =  +----+ =   =   =   =   =   =   =   =   =  +----+ =   =   AC =   V =  
> =   =   =   =  +-----+ =   =  | =   =   = |....|.......PW1........|....|   =   | =   =  +-----+ =  
> =   =   =   =  | =   =   = |----------| PE1|......   .........| = PE3|----------|   =   | =  
> =   =   =   =  | CE1 | =   =   =   =   =  +----+ =   =   =  \ / =  PW3 =   =  +----+ =   =   =   =   =  | CE2 | =  
> =   =   =   =  | =   =   | =   =   =   =   =  +----+ =   =   =   X =   =   =   =   =  +----+ =   =   =   =   =  | =   =   | =
> =   =   =   =  | =   =   | =   =   =   =   =  | =   =  |....../ = \..PW4....|   =  | =   =   =   =   =  | =   =   | =  
> =   =   =   =  | =   =   = |----------| PE2|   =   =   =   =   =   =   =   =  | = PE4|--------- |   =   | =  
> =   =   =   =  +-----+ =   =  | =   =   = |....|.....PW2..........|....|   =   | =   =  +-----+ =  
> =   =   =   =   =   =   =   =   =   AC =   =  +----+ =   =   =   =   =   =   =   =   =  +----+ =   =  AC =   =   =   =
> =   =   =  
> =   =   =
> =   =   =  Figure 15-2 = Multiple Multi-homed CEs with single SS-PW redundancy =  
> =  
> =   =  The = application in Figure 15-2 makes use of the Independent mode of =
> =   =  operation. =
> =  
> =   =  CE1 is = dual-homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. The =
> =   =  method for = dual-homing and the used protocols are outside the scope =
> =   =  of this = document.  Note that = the PSN tunnels are not shown in this
>   =  figure for = clarity. However, it can be assumed that each of the PWs =
> =   =  shown is = encapsulated in a separate PSN tunnel.
>   =
>   =  Assume that = the AC from CE1 to PE1 is Active, from CE1 to PE2 is =
> =   =  Standby; = furthermore, assume that the AC from CE2 to PE3 is Standby =
> =   =  and from = CE2 to PE4 is Active. The method of deriving Active/Standby =
> =   =  status of = the AC is outside the scope of this document.
>   =
>   =  PE1 = advertises the preferential status "Active" and operational =
> =   =  status = "Pseudowire forwarding" for pseudowires PW1 and PW4 connected =
> =   =  to PE3 and = PE4. This status reflects the forwarding state of the AC =
> =   =  attached to = PE1. PE2 advertises preferential status "Standby" and =
> =   =  operational = status "Pseudowire forwarding" for pseudowires PW2 and =
> =   =  PW3 to PE3 = and PE4. PE3 advertises preferential status "Standby" and =
> =   =  operational = status "Pseudowire forwarding" for pseudowires PW1 and =
> =   =  PW3 to PE1 = and PE2. PE4 advertise the preferential status "Active" =
> =   =  and = operational status "Pseudowire forwarding" for pseudowires PW2 =
> =   =  and PW4 to = PE2 and PE1 respectively. Thus by matching the local and =
> =   =  remote = preferential forwarding status of "Active" and operational =
> =   =  status of = "Pseudowire forwarding" of pseudowires, the PE nodes =
> =   =  determine = which PW should be in the Active state. In this case it is =
> =   =  PW4 that = will be selected.   =
>   =
>   =  On failure = of the AC between CE1 and PE1, the forwarding state of =
> =   =  the AC on = PE2 is changed to Active. PE2 then announces the newly =
> =   =  changed = 'preferential forwarding' status bit of "active" to PE3 and =
> =   =  PE4. PE1 = will advertise a PW status notification message indicating =
> =   =  that the AC = between CE1 and PE1 is operationally down. PE2 and PE4 =
> =   =  match the = local and remote preferential forwarding status of =
> =   =  "Active" and operational status = "Pseudowire forwarding" and select
>   =  PW2 as the = new active pseudowire to send traffic to.
>   =
>   =  On failure = of PE1 node, PE2 will detect it and will transition the =
> =   =  forwarding = state of its AC to Active. The method by which PE2 =
> =   =  detects = that PE1 is down is outside the scope of this document. PE2 =
> =   =  then = announces the newly changed 'preferential forwarding' status =
> =   =  bit of = "Active" to PE3 and PE4. PE2 and PE4 match the local and =
> =   =  remote = preferential forwarding status of "Active" and operational =
> =   =  status = "Pseudowire forwarding" and select PW2 as the new active =
> =   =  pseudowire = to send traffic to. Note that PE3 and PE4 may have =
> =   =  detected = that the PW to PE1 went down via T-LDP Hello timeout or via =
> =   =  other = means. However, they will not be able to forward user traffic =
> =   =  until they = received the updated status bit from PE2.
>   =
>   =  Because = each dual-homing algorithm running on the two node sets, =
> =   =  i.e., {CE1, = PE1, PE2} and {CE2, PE3, PE4}, selects the active AC =
> =   =  independently, there is a need to signal the = active status of the AC
>   =  such that = the PE nodes can select a common active PW for end-to-end =
> =   =  forwarding = between CE1 and CE2 as per the procedures in the =
> =   =  independent = mode.
> =  
> =   =  Note that = any primary/secondary procedures, as defined in sections =
> =   =  5.1. =  and 5.2. , = do not apply in this use case as the Active/Standby =
> =   =  status is = driven by the AC forwarding state as determined by the AC =
> =   =  dual-homing = protocol used.
> =  
> =  
> I = believe you=A1=AFve taken = your =A1=B0out of = scope=A1=B1 reference = from this text,
> but IMHO you = misinterpreted it.
> = What it means (or so I read it) is that specific dual-homing =
> = protocol is out of scope as long as it meets certain assumptions. =
> Aside: It would be good if = the authors of the PW redundancy drafts
> could explicitly specify = these assumptions.
> =  
> = [[[Sasha]]] =A1=AD snipped = =A1=AD
> =  
> = Now let=A1=AFs turn our = attention back to whether the PW redundancy
> draaft can be used to = meet MPLS-TP PW protection requirements. I can
> identify the following = reasons why in its current form it doesn=A1=AFt:
>   =
> -   =   =   =   =  It = explicitly (=A1=B0outside the = scope=A1=B1) does not = define
> = protection triggers and how to handle coexisting triggers, as
> requested in RFC 5654 = (MPLS-TP Requirements), reqs #75, #76 and #79
> [[[Sasha]]] So what? Definition of = triggers is orthogonal to how
> coordinated protection = switching happens.
> = [DC] It is. But still it needs to be defined by the recovery =
> = framework, e.g. what should the endpoint do when one PW is in SF = and
> the other = is in SD, or when both are in SD. Operators expect well-
> defined behavior in these = and other scenarios, and PW redundancy
> does not define them = (because it was not in their scope).
> [[[Sasha]]] I wonder if you have = followed the discussion regarding
> ability to define SD = condition for LSPs and PWs on the MPLS-TP list?
> IMO it is not possible to = define it in a meaningful way. Hence I do
> not see a proposal that = does not address a scenario that does not
> exist in reality as a = flawed one.
> =  
> - =   =   =   =   =  It does not = support the ability to distinguish between
> different types of = triggers (i.e. one end doesn=A1=AFt know why = the other
> end triggered switch), as = requested in RFC 5654 (MPLS-TP
> Requirements), req = #77
> - =   =   =   =   =  It does not = define revertive/nonrevertive behavior, as
> requested in RFC 5654 = (MPLS-TP Requirements), req #64
> -   =   =   =   =  It does not = define holdoff support, which is especially
> important to avoid race = conditions with LSP protection when it exists
> -   =   =   =   =  It = doesn=A1=AFt support = 1+1 mode, as requested in RFC 5654
> (MPLS-TP Requirements), = req #65
> [[[Sasha]]] = All these claims are correct =A8C and =  this should = not be a
> = surprise, because MPLS-TP requirements have been defined much later =
> than the PW = redundancy mechanism.
> = But I do not think that this justifies co-existence of two = different
> mechanisms. =
> [DC] So how do you propose = to meet the PW protection requirement?
> -   =   =   =   =  It=A1=AFs a = two-phase protocol, with the consequent impact on = timing
> = [[[Sasha]]] Could you please elaborate? [DC] In = draft-ietf-mpls-tp-
> linear-protection, each = endpoint will immediately switch traffic to
> the other path upon = identifying an SF condition in a path, without
> waiting for the far end = to acknowledge the switch (1-phase). In PW
> redundancy, an endpoint = detecting an SF condition in a path will not
> switch until the far end = has acknowledged the switch (2-phase).
> Needless to say, recovery = is slower in a 2-phase protocol.
> [[[Sasha]]] To the best of my = understanding, 1-phase protection is
> only possible in 1+1 = unidirectional architectures. And yes, I know
> that MPLS-TP requires a =  mechanism = to support this; whether anybody
> would really do that in = the packet-switching network is not clear to
> me. And I acknowledge = that the PW redundancy drafts do not support
> 1+1 unidirectional = scheme.
> =  
> - =   =   =   =   =  It = doesn=A1=AFt define = retransmission of protection
> coordination messages, so = loss of a single PDU can result in
> switchover not taking = place, thus not supporting sub-50 ms recovery
> in this case =
> [[[Sasha]]] The PW = redundancy protocol runs either on top of LDP
> (which benefits from TCP = retransmissions) or on top of static PW
> status messages (where = retransmission is defined).
> [DC] True =A8C but static = PW status defines slow retransmission (=A1=B0will =
> be = transmitted twice at an initial interval of one second=A1=B1) while =
> = draft-ietf-mpls-tp-linear-protection specifies fast retransmission =
> when required = for fast recovery (section 3.1.4).
>   =
> In summary, PW redundancy = was not designed with TP requirements in
> mind, and as such does = not meet the TP requirements. Of course
> modifications may be = introduced, but why reinvent the wheel when
> there is a protocol = (draft-ietf-mpls-tp-linear-protection-06) in the
> standards track that = supports all the above requirements and can be
> applied to MS-PW = protection with minor modifications?
> [[[Sasha]]] As I said, because the = applicability scope is by far too
> narrow to justify a = dedicated protocol.
> = [DC] If we were discussing designing a new protocol, I might agree =
> with = you. But from a practical standpoint, the PW protection draft
> is not a dedicated = protocol =A8C = it=A1=AFs an = applicability statement to an
> existing protocol. Both = from the implementation and the operational
> point of view it defines = a new use case for an existing protocol and concept.
>   =
>   =
> Regards, =
>   =
> Daniel =
>   =
>   =
> From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of =
> = Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Sent: Monday, June 13, = 2011 4:02 PM
> = To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn
> Cc: mpls@ietf.org; = pwe3@ietf.org
> = Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-
> TPLinearProtection = Applicability to MS-PW"
>   =
> Hi, =
> I would like to second = Sasha.
> = End-to-end PW protection (with diverse paths) does not scale, and =
> put = hard restrictions on the utilization of the resources.   =
> MPLS-TP PWs are carried = across the network inside MPLS-TP LSPs.
> Therefore, an obvious way = to provide protection for a PW is to
> protect the LSP that = carries it.   =
> If the PW is a = multi-segment PW, then LSP recovery can only protect
> the PW in individual = segments.  This means = that a single LSP
> recovery action cannot = protect against a failure of a PW switching
> point (an S-PE). =
> When protecting against an = AC or T/S-PE failure by dual
> connectivity, PW = redundancy mechanisms provide means for the PEs to
> coordinate over which LSP = the traffic of the PW is carried.
> I also doubt why there is a need for = additional mechanism.
> Best regards,
> Nurit
>   =
> From: = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of =
> ext = Alexander Vainshtein
> Sent: Monday, June 13, = 2011 3:43 PM
> = To: ma.yuxia@zte.com.cn
> Cc: mpls@ietf.org; = pwe3@ietf.org
> = Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP =
> = LinearProtection Applicability to MS-PW"
>   =
> Dear Ma and = all,
> Adding = the PWE3 WG to my response.
>   =
> The PW redundancy = mechanism supports linear protection of MS-PWs as
> one of many additional = application use cases:
> Appendix A of the PW redundancy Bit = draft describes 5 application
> uses cases in addition to = MS-PW with single-homed CEs (which is
> listed there as use case = 5).
> And it is equally = applicable to IP/MPLS and MPLS - with the help of  the =
> Static = PW Status Messages draft( if, for whatever reason, you do not
> want  to, or = cannot, use RFC 4447).
>   =
> Hence I doubt the need for = yet another PW redundancy  mechanism = with
> = narrow scope of applicability.
>   =
> Regards, =
>   =   =  Sasha
>   =
> From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of =
> = ma.yuxia@zte.com.cn
> Sent: Monday, June 13, = 2011 3:25 PM
> = To: mpls@ietf.org
> Subject: Re: [mpls] = Seeking feedback on I-D "MPLS-TP Linear
> Protection Applicability = to MS-PW"
> =  
> = Hi all,
> =
> The linear = protection mechanism for LSP and PW(including MS-PW)
> should be the same and it = is valuable to describe it clearly.
>
> BTW, there is a typo, it = is "T-PE Z" instead of "T-PE B".
>
>  " =
> =   Figure 1 = illustrates such a scenario, where two MS-PWs are
>   = established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4 =
> =   = respectively. Each PW segment is established over an LSP (e.g. PW- =
> =   s12 over = LSP12).
> =  " =
> -----Original = Message-----
> From: Daniel Cohn =
> Sent: Tuesday, = May 17, 2011 4:14 PM
> To: mpls
> Subject: Seeking feedback = on I-D "MPLS-TP Linear Protection
> Applicability to = MS-PW"
> = Importance: High
>
> Hi MPLSers,
>
> I uploaded "MPLS-TP = Linear Protection Applicability to MS-PW" I-D
> = (http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)
>
> The abstract = goes:
> =
> One of the = requirements of the MPLS transport profile [RFC 5654] is
> to provide linear = protection for transport paths, which include both
> LSPs and PWs. The = functional architecture described in [SurvivFwk]
> is applicable to both LSP = and PWs, however [LinearProt] does not
> explicitly describe = mechanisms for PW protection in MPLS-TP.
>
> This document extends the = applicability of the linear protection
> mechanism described in = [LinearProt] to MPLS-TP segmented PWs
> (MS-PWs) as defined in = [RFC 6073].
> =
> Could you = please review it and send feedback to the mailing list or
> directly to the author? =
>
> Looking forward to your = feedback,
> =
> Daniel =
> This e-mail message = is intended for the recipient only and contains
> information which is = CONFIDENTIAL and which may be proprietary to
> ECI Telecom. If you have = received this transmission in error, please
> inform us by e-mail, = phone or fax, and then delete the original and
> all copies thereof. =
> This e-mail message = is intended for the recipient only and contains
> information which is = CONFIDENTIAL and which may be proprietary to
> ECI Telecom. If you have = received this transmission in error, please
> inform us by e-mail, = phone or fax, and then delete the original and
> all copies thereof. =
> This e-mail message = is intended for the recipient only and contains
> information which is = CONFIDENTIAL and which may be proprietary to
> ECI Telecom. If you have = received this transmission in error, please
> inform us by e-mail, = phone or fax, and then delete the original and
> all copies thereof. = =A9mz=B9=DA??br>

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

This e-mail message = is intended for the recipient only and contains information which is = CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have = received this transmission in error, please inform us by e-mail, phone = or fax, and then delete the original and all copies thereof. =

------_=_NextPart_001_01CC2F2F.B73C97F0-- From eosborne@cisco.com Mon Jun 20 15:19:55 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651C411E80C1; Mon, 20 Jun 2011 15:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RQzWIGGMGK8; Mon, 20 Jun 2011 15:19:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id 3551711E80D1; Mon, 20 Jun 2011 15:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=6926; q=dns/txt; s=iport; t=1308608394; x=1309817994; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=vaeQkCXKbXMRBvIhzv4UszCTReylKNjWo1SWSnQvSkg=; b=QuMSDPTKCWOQzpv01fbLPWBVL5KIwpUZw3v2pgQ9a6H50/dTTqfZ6aei Bf2YSbxULXkWZbQSg4E/JxXu/AqnXX8X18FrShzZ22ldiCTTIbziXbyI7 X4YhkPKGAoTBgxTIc2PqO2HuIQEhPkuZfgwTxNSHW/UIBM8wqBt5CTLpi M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAADnG/02tJV2d/2dsb2JhbABTl1uPDHeqQZ4ehioEhyCPJ4Q8hno X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208";a="237518248" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 20 Jun 2011 22:19:52 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p5KMJqub024844; Mon, 20 Jun 2011 22:19:52 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 17:19:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 17:19:50 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? Thread-Index: Acwt0ynNZ3JEDsDySsWhgBj3eR20rgAFpOiuAGuJVeA= References: , From: "Eric Osborne (eosborne)" To: "Alexander Vainshtein" , "Greg Mirsky" X-OriginalArrivalTime: 20 Jun 2011 22:19:52.0515 (UTC) FILETIME=[2D1A8930:01CC2F98] Cc: mpls@ietf.org, Vladimir Kleiner , Andrew Sergeev , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant\)" , Robert Rennison , Rotem Cohen Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 22:19:55 -0000 Hi Sasha, Greg- If I understand correctly, the point that's being raised is that an implementation must distinguish Rx'd P-LSP packets it needs to discard (e.g. user traffic) vs. those that it must not (managmentm such as CC and PSC). If this is the point, I agree with it. But I don't see that it's any cause for concern. An implementation ought to be able to examine all traffic in an LSP and decide what it wants to keep; for CC and PSC (and for everything, as far as I can see), all traffic we want to keep will be in the GACH. eric > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Saturday, June 18, 2011 2:59 PM > To: Greg Mirsky > Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; > mpls@ietf.org; Eric Osborne (eosborne); Vladimir Kleiner; Andrew Sergeev; > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert > Rennison; Stewart Bryant (stbryant) > Subject: RE: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are > they compatible? >=20 > Dear Greg, > Lots of thanks for a prompt response. >=20 > However, I disagree with your conclusion: if you discard the traffic at > the LSP level (i.e. based on the incoming tunnel label), you would also > discard CC and PSC traffic: at this level they are undistinguishable from > the PW traffic. > The situation with the PW protection will be indeed different because > Working and Protection PWs would use different PW labels. >=20 > Hopefully this clarifies my point. > Regards, > Sasha > ________________________________ >=20 > From: Greg Mirsky [gregimirsky@gmail.com] > Sent: Saturday, June 18, 2011 7:17 PM > To: Alexander Vainshtein > Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; > mpls@ietf.org; eosborne@cisco.com; Vladimir Kleiner; Andrew Sergeev; > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert > Rennison; Stewart Bryant (stbryant@cisco.com) > Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are > they compatible? >=20 >=20 > Dear Sasha, > I think that there is one assumption in line of your logic that changes > the result. > When we consider 1+1 LSP protection sink discards traffic from one source > on LSP level. As result there should not be issue with Rx on PW client > traffic since sink receives PW packets only from Active LSP and PW packets > from Inactive LSP would never be seen. > If we consider 1:1 PW protection, then, as I imagine, we have redundant PW > and thus PW labels are different. Then the sink selects one of PWs as > active but there should be no issue with PW labels. >=20 > Please let me know if understood scenarios correctly. >=20 > Kind regards, > Greg >=20 >=20 > On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainshtein > wrote: >=20 >=20 > Hi all, > I would highly appreciate some clarification on the following issue: >=20 > Is 1+1 linear protection architecture for LSPs compatible with > the MPLS-TP data plane? >=20 > We have been recently reminded by Daniel Cohn that 1+1 protection > has been declared as MUST to support for MPLS-TP in RFC 5654 (Req. #65). > What's more, Req. #65-B states that it MUST be supported in the > unidirectional mode for P2P connectivity. >=20 > The problematic use case from my point of view is PW traffic carried > within a 1+1-protected LSP between a pair of PEs. >=20 > To the best of my understanding, unidirectional 1+1 linear > protection, in its absolutely minimal form, would imply that: >=20 > 1. > Some form of proactive connectivity check (CC) would be > applied to both Working (W) and Protection (P) LSPs. It is my > understanding that the GAL/G-ACH mechanism would be used as the > encapsulation for the CC packets > 2. > Based on the results of CC, one of the incoming LSPs would be > selected as Active > 3. > When in comes to PW client traffic in these LSPs: >=20 > * > In the Tx direction: >=20 > * > Each PW packet would be replicated and forwarded > thru both W and P LSPs > * > Replication would leave the PW label (and > everything after this label) the same for both copies, so that only Tunnel > labels and accompanying linke layer encapsulations would be different >=20 > * > In the Rx direction: >=20 > * > Both W and P LSPs would be terminated, i.e., their > labels would be popped and, if the resulting packets are still labeled, > the next label looked up > * PW packets received from the Active LSP would be > forwarded to the appropriate PW Forwarder, and PW packets received from > the inactive LSP would be silently discarded >=20 > If this understanding is correct, this would mean that treatment of > the received PW labels would depend on the specific terminated LSP from > which the packets labeled with those have been received. In principle, > this would be possible if we would treat these LSPs and interfaces and > allocate PW labels from the per-interface space(even this would be non- > trivial, because there is no way to guarantee that the same label value > has simiilar meaning in different label spaces). But, as per RFC 4447, PW > labels MUST be allocated from the per-platform label space. >=20 > And of course, simply discarding all the packets received from the > inactive LSP would not do because this would affect CC operation. >=20 >=20 >=20 > Did I miss something substantial in my analysis? >=20 >=20 >=20 > Please note also that 1:1 protection could rely on the remote Tx > endpoint only sending packets to the (common) Active LSP making life > simpler (no real need for selection on the Rx side). >=20 >=20 >=20 > I understand that draft-ietf-mpls-tp-linear-protection is in the > final stages of the WG discussion, and apologize for raising this question > so late. But late is (sometimes) better than never... >=20 >=20 >=20 > Regards, >=20 > Sasha >=20 >=20 >=20 >=20 >=20 > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 >=20 >=20 > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. From zhanghaiyan@huawei.com Mon Jun 20 23:10:23 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8404F11E80F0 for ; Mon, 20 Jun 2011 23:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.45 X-Spam-Level: ** X-Spam-Status: No, score=2.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC7WNyGUPZO0 for ; Mon, 20 Jun 2011 23:10:22 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2B96611E809F for ; Mon, 20 Jun 2011 23:09:58 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN4008T8MEOXS@szxga04-in.huawei.com> for pwe3@ietf.org; Tue, 21 Jun 2011 14:08:48 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN400AW3MBKQV@szxga04-in.huawei.com> for pwe3@ietf.org; Tue, 21 Jun 2011 14:08:48 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABU05160; Tue, 21 Jun 2011 14:08:33 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 21 Jun 2011 14:08:31 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.16.74]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Tue, 21 Jun 2011 14:08:33 +0800 Date: Tue, 21 Jun 2011 06:08:32 +0000 From: Zhanghaiyan In-reply-to: X-Originating-IP: [10.70.77.115] To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Message-id: <7367637CA8EB7A43B0B3F995C5355895076C96FE@SZXEML510-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_YdUuaCzSOa04nDF9i8jkIQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Thread-index: Acwmim8YgO2wxXLFTRmMrx1MED7XzgJTsOEQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: [PWE3] =?gb2312?b?tPC4tDogV0cgTEMgb24gZHJhZnQtaWV0Zi1wd2UzLW1w?= =?gb2312?b?bHMtdHAtZ2FsLWluLXB3LTAxLnR4dA==?= X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 06:10:23 -0000 --Boundary_(ID_YdUuaCzSOa04nDF9i8jkIQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 U3VwcG9ydC4NCg0KDQoNCkIuUi4NCg0KSGFpeWFuDQoNCreivP7IyzogcHdlMy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEJvY2NpLCBNYXR0aGV3 IChNYXR0aGV3KQ0Kt6LLzcqxvOQ6IDIwMTHE6jbUwjnI1SAxNzo0OQ0KytW8/sjLOiBwd2UzQGll dGYub3JnDQrW98ziOiBbUFdFM10gV0cgTEMgb24gZHJhZnQtaWV0Zi1wd2UzLW1wbHMtdHAtZ2Fs LWluLXB3LTAxLnR4dA0KDQpUaGlzIGVtYWlsIGJlZ2lucyBhIHR3byB3ZWVrIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXB3ZTMtbXBscy10cC1nYWwtaW4tcHctMDEudHh0 DQoNClBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBwb3N0IGFueSBjb21tZW50cyB0byB0aGUg UFdFMyBtYWlsaW5nIGxpc3QuDQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCB3aWxsIGVu ZCBvbiBGcmlkYXkgMjR0aCBKdW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCk1hdHRoZXcgJiBBbmR5 DQo= --Boundary_(ID_YdUuaCzSOa04nDF9i8jkIQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Support.

 

B.R.

Haiyan

 = ;

=B7=A2=BC=FE=C8=CB: pwe3-bounces@ietf.org= [mailto:pwe3-bounces@ietf.org] =B4=FA=B1=ED = Bocci, Matthew (Matthew)
=B7=A2=CB=CD= =CA=B1=BC=E4: 2011=C4=EA6=D4=C2<= span lang=3D"EN-US">9=C8=D5 17:49
=CA=D5=BC=FE=C8=CB: pwe3@ietf.org
=D6=F7=CC=E2: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt

 

This email b= egins a two week working group last call for draft-ietf-pwe3-mpls-tp-g= al-in-pw-01.txt

 <= /o:p>

Please revie= w the draft and post any comments to the PWE3 mailing list.

 <= /o:p>

The working = group last call will end on Friday 24th June.

 <= /o:p>

Best regards= ,

 <= /o:p>

Matthew &= ; Andy

--Boundary_(ID_YdUuaCzSOa04nDF9i8jkIQ)-- From Alexander.Vainshtein@ecitele.com Tue Jun 21 01:47:46 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2086B11E807B; Tue, 21 Jun 2011 01:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4mhyWRXHJ9y; Tue, 21 Jun 2011 01:47:45 -0700 (PDT) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAAD11E80B1; Tue, 21 Jun 2011 01:47:44 -0700 (PDT) X-AuditID: 93eaf2e7-b7ce9ae0000066df-dd-4e005aa6b5ec Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Messaging Gateway) with SMTP id 67.4C.26335.6AA500E4; Tue, 21 Jun 2011 11:47:35 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 21 Jun 2011 11:47:41 +0300 From: Alexander Vainshtein To: "Eric Osborne (eosborne)" Date: Tue, 21 Jun 2011 11:47:38 +0300 Thread-Topic: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? Thread-Index: Acwt0ynNZ3JEDsDySsWhgBj3eR20rgAFpOiuAGuJVeAAFJBKwA== Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTXWzTVhjttZ3EKTUyaUIvFUKW+ZEYTdXAkIxo2I94CEih5ecBwjowzl3i LXFCbBDtwyho2iYElEKF1FCpBUoLpTQKZWurriAiIVYq0U0baK0ADWgGhPISGONHIlzPUIrw g3Xud86557P1fTRpa7QU07KioZgihnhzPnUok33ibPflrSq72kkLXel/CGF3UzcQnh5Om4TR E6dMwv7sOUq4mm4CQrK/0fypxdPwMmnyvPj3mtnTF79p8bS2Pic8zxPXLJUmXy0oFxUlooka 4vxIldx8ZUzeLkrVPCf73byL56IhUUJhpGhuXoxGkeLnl+VzHzzlWCYrHFKkiF9WAm5+xdoK pyAsXuJ08cvmzXYtWpq/LiirHHKGRTnEhZGqigHE4crmc2SwJ/HQFD2/fMftJ92gFsQX7wFW GrIfw66OSxYDT4e/3UqY94B82sb2AZhtug2MQwOAQ9luk64ys2549vRNs47t7EJY13OB0EUk O0TB75+9BDpBsXPhif5hLKLpQvYLeG/3LENfBY9kfgR62c5+Dn+6G9TLDFsBkwdH3mTtI2D6 1u+ETlhZLxyrf0TpGODu/rvS+X+dZIvg6FgzYXTNwtZfhkkDO+CDu69Mht4Bb/yQAIa+BLb0 Z80GXgDbjj4kjeBpcLBxjDK8M+DFk39RB0BRfFJEfJI9Psken2RvAVQHcMihqLYlHChzlSJJ 1lAIlUqR8FlgDNO9XvCieU4KsDTgC5i8hpzXZhK3q9XhFJhBE7yDcW3IW2WbuiXirw6KanBT bFsIqSkAaZK3M3XrMcf4xeoaFIu8pQT8k+vJ4ilSBI+tom1aVFb23oEvYtLSuNfGBvDUfYNQ FMXeWmfSNA+ZEjzdtmkxFEA7vpJD2juaoK16cgFO3qt3xahRMazKAYO/ApbQPS0PUoA+dkZ/ tx0ZTwEbpUQUVIwjdQOrG4LblIk79Y3amcvlMqAIf38h49CjC/C+TdyawYEEDsxlXnlxIN6U Caq4FvSyU+zzG7Xr7X7gHFq50efq6/n7szklNcSNztGAz97MjR24811pSD1TWTO1lr8/0u4Z tTZ7OpaPnPpj/M63a+CC1amqDcODM+/Tl/eigY2Prf25X0dmtQ12+Z2bHw301k0flpLup197 L1ddp5JfLvyzuzDxScXxnwfKLVvrlw7s8vGUGhRdH5ExVXwNKfBebCwEAAA= Cc: "mpls@ietf.org" , Vladimir Kleiner , Andrew Sergeev , Mishael Wexler , pwe3 , Oren Gal , John Shirron , "Stewart Bryant \(stbryant\)" , Robert Rennison , Rotem Cohen Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 08:47:46 -0000 Eric, I believe the issue has been successfully resolved with help from Shahram an= d Greg. The way to resolve it, from my point of view, was to say that the inactive L= SP would not be terminated in the tail-end in the normal way LSPs are termin= ated i.e., the ILM-defined action on its label would not be "Pop and look up= the next label (if it exists)". Rather, this action would be "Pop and forwa= rd to a "leaky drop" interface". Thus the problem has been effectively remov= ed from the scope of MPLS data plane architecture (as defined in RFC 3031 an= d 3032): it would be the responsibility of the "leaky drop" interface to "le= ak" GACH packets to control while dropping all the rest (user traffic). Acco= rdingly, implementation could be partitioned into two components: - implementation of the "leaky drop" interface (one such per box would suffi= ce) - manipulation of the ILM entries referring to the labels of the two LSPs. Hopefully these notes will be useful. Regards, Sasha > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Tuesday, June 21, 2011 1:20 AM > To: Alexander Vainshtein; Greg Mirsky > Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; > mpls@ietf.org; Vladimir Kleiner; Andrew Sergeev; Mishael Wexler; pwe3; > Oren Gal; John Shirron; Rotem Cohen; Robert Rennison; Stewart Bryant > (stbryant) > Subject: RE: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: > are they compatible? > > Hi Sasha, Greg- > > If I understand correctly, the point that's being raised is that an > implementation must distinguish Rx'd P-LSP packets it needs to discard > (e.g. user traffic) vs. those that it must not (managmentm such as CC > and PSC). > > If this is the point, I agree with it. But I don't see that it's any > cause for concern. An implementation ought to be able to examine all > traffic in an LSP and decide what it wants to keep; for CC and PSC (and > for everything, as far as I can see), all traffic we want to keep will > be in the GACH. > > > > eric > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Saturday, June 18, 2011 2:59 PM > > To: Greg Mirsky > > Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; > > mpls@ietf.org; Eric Osborne (eosborne); Vladimir Kleiner; Andrew > Sergeev; > > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert > > Rennison; Stewart Bryant (stbryant) > > Subject: RE: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: > are > > they compatible? > > > > Dear Greg, > > Lots of thanks for a prompt response. > > > > However, I disagree with your conclusion: if you discard the traffic > at > > the LSP level (i.e. based on the incoming tunnel label), you would > also > > discard CC and PSC traffic: at this level they are undistinguishable > from > > the PW traffic. > > The situation with the PW protection will be indeed different because > > Working and Protection PWs would use different PW labels. > > > > Hopefully this clarifies my point. > > Regards, > > Sasha > > ________________________________ > > > > From: Greg Mirsky [gregimirsky@gmail.com] > > Sent: Saturday, June 18, 2011 7:17 PM > > To: Alexander Vainshtein > > Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; > > mpls@ietf.org; eosborne@cisco.com; Vladimir Kleiner; Andrew Sergeev; > > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert > > Rennison; Stewart Bryant (stbryant@cisco.com) > > Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: > are > > they compatible? > > > > > > Dear Sasha, > > I think that there is one assumption in line of your logic that > changes > > the result. > > When we consider 1+1 LSP protection sink discards traffic from one > source > > on LSP level. As result there should not be issue with Rx on PW > client > > traffic since sink receives PW packets only from Active LSP and PW > packets > > from Inactive LSP would never be seen. > > If we consider 1:1 PW protection, then, as I imagine, we have > redundant PW > > and thus PW labels are different. Then the sink selects one of PWs as > > active but there should be no issue with PW labels. > > > > Please let me know if understood scenarios correctly. > > > > Kind regards, > > Greg > > > > > > On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainshtein > > wrote: > > > > > > Hi all, > > I would highly appreciate some clarification on the following > issue: > > > > Is 1+1 linear protection architecture for LSPs > compatible with > > the MPLS-TP data plane? > > > > We have been recently reminded by Daniel Cohn that 1+1 > protection > > has been declared as MUST to support for MPLS-TP in RFC 5654 (Req. > #65). > > What's more, Req. #65-B states that it MUST be supported in the > > unidirectional mode for P2P connectivity. > > > > The problematic use case from my point of view is PW traffic > carried > > within a 1+1-protected LSP between a pair of PEs. > > > > To the best of my understanding, unidirectional 1+1 linear > > protection, in its absolutely minimal form, would imply that: > > > > 1. > > Some form of proactive connectivity check (CC) would be > > applied to both Working (W) and Protection (P) LSPs. It is my > > understanding that the GAL/G-ACH mechanism would be used as the > > encapsulation for the CC packets > > 2. > > Based on the results of CC, one of the incoming LSPs > would be > > selected as Active > > 3. > > When in comes to PW client traffic in these LSPs: > > > > * > > In the Tx direction: > > > > * > > Each PW packet would be replicated and > forwarded > > thru both W and P LSPs > > * > > Replication would leave the PW label > (and > > everything after this label) the same for both copies, so that only > Tunnel > > labels and accompanying linke layer encapsulations would be different > > > > * > > In the Rx direction: > > > > * > > Both W and P LSPs would be terminated, > i.e., their > > labels would be popped and, if the resulting packets are still > labeled, > > the next label looked up > > * PW packets received from the Active LSP > would be > > forwarded to the appropriate PW Forwarder, and PW packets received > from > > the inactive LSP would be silently discarded > > > > If this understanding is correct, this would mean that treatment > of > > the received PW labels would depend on the specific terminated LSP > from > > which the packets labeled with those have been received. In > principle, > > this would be possible if we would treat these LSPs and interfaces > and > > allocate PW labels from the per-interface space(even this would be > non- > > trivial, because there is no way to guarantee that the same label > value > > has simiilar meaning in different label spaces). But, as per RFC > 4447, PW > > labels MUST be allocated from the per-platform label space. > > > > And of course, simply discarding all the packets received from > the > > inactive LSP would not do because this would affect CC operation. > > > > > > > > Did I miss something substantial in my analysis? > > > > > > > > Please note also that 1:1 protection could rely on the remote Tx > > endpoint only sending packets to the (common) Active LSP making life > > simpler (no real need for selection on the Rx side). > > > > > > > > I understand that draft-ietf-mpls-tp-linear-protection is in the > > final stages of the WG discussion, and apologize for raising this > question > > so late. But late is (sometimes) better than never... > > > > > > > > Regards, > > > > Sasha > > > > > > > > > > > > This e-mail message is intended for the recipient only and > contains > > information which is CONFIDENTIAL and which may be proprietary to ECI > > Telecom. If you have received this transmission in error, please > inform us > > by e-mail, phone or fax, and then delete the original and all copies > > thereof. > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > This e-mail message is intended for the recipient only and contains > > information which is CONFIDENTIAL and which may be proprietary to ECI > > Telecom. If you have received this transmission in error, please > inform us > > by e-mail, phone or fax, and then delete the original and all copies > > thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From ma.yuxia@zte.com.cn Mon Jun 20 01:31:38 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9974211E8086; Mon, 20 Jun 2011 01:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.19 X-Spam-Level: X-Spam-Status: No, score=-92.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIzZXUnVegzT; Mon, 20 Jun 2011 01:31:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 19F0111E8080; Mon, 20 Jun 2011 01:31:34 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 48642203882679; Mon, 20 Jun 2011 16:27:17 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 20423.3642717021; Mon, 20 Jun 2011 16:31:23 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5K8VNPO039544; Mon, 20 Jun 2011 16:31:23 +0800 (GMT-8) (envelope-from ma.yuxia@zte.com.cn) In-Reply-To: To: Alexander Vainshtein MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: ma.yuxia@zte.com.cn Date: Mon, 20 Jun 2011 16:31:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-20 16:31:24, Serialize complete at 2011-06-20 16:31:24 Content-Type: multipart/alternative; boundary="=_alternative 002EE0C8482578B5_=" X-MAIL: mse01.zte.com.cn p5K8VNPO039544 X-Mailman-Approved-At: Wed, 22 Jun 2011 08:02:50 -0700 Cc: "pwe3@ietf.org" , "mpls@ietf.org" Subject: [PWE3] =?gb2312?b?tPC4tDogUkU6IFttcGxzXSAgU2Vla2luZyBmZWVkYmFj?= =?gb2312?b?ayBvbiBJLUQgIk1QTFMtVFBMaW5lYXJQcm90ZWN0aW9uQXBwbGljYWJpbGl0?= =?gb2312?b?eSB0byBNUy1QVyI=?= X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 08:31:38 -0000 This is a multipart message in MIME format. --=_alternative 002EE0C8482578B5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2FzaGEsDQoNCiJMaW5lYXIgcHJvdGVjdGlvbiIgaXMgZGlmZmVyZW50IGZyb20gIk11bHRp LWhvbWVkIENFIHJlZHVuZGFuY3kiIGFuZCBoYXMgDQpubyByZWZlcmVuY2Ugd2l0aCBBQy4NCg0K V29ya2luZyBwYXRoKHMpIGFuZCBwcm90ZWN0aW9uIHBhdGgocykgaGF2ZSBzYW1lIHNvdXJjZSBh bmQgc2luayBlbmRwb2ludHMgDQppbiBsaW5lYXIgcHJvdGVjdGlvbiB0eXBlLg0KDQpJTUhPLCBX aGVuIFMtUEUgZmFpbHMsIGl0IGlzIG1vcmUgc2ltcGxlIHRvIHVzZSAiTGluZWFyIHByb3RlY3Rp b24iIHRvIA0KcHJvdGVjdCBpdC4NCg0KDQoNCkJlc3QgUmVnYXJkcywNCk1hDQoNCg0KQWxleGFu ZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPiDQtNPaIDIw MTEtMDYtMTQgDQoyMDowMjoxMDoNCg0KPiBEYW5pZWwsDQo+IFBsZWFzZSBzZWUgbW9yZSBpbmxp bmUgKGJvbGQgcHVycGxlIGl0YWxpY3MpLiBJoa92ZSBhbHNvIHN0cmlwcGVkIHRoZQ0KPiBwb3J0 aW9ucyBvZiB0aGUgdGV4dCB0aGF0IGFyZSBub3QgcmVsYXRlZCB0byB0aGlzIHJvdW5kIG9mIGNv bW1lbnRzLg0KPiANCj4gUmVnYXJkcywNCj4gICAgICBTYXNoYQ0KPiANCj4gRnJvbTogRGFuaWVs IENvaG4gW21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb21dIA0KPiBTZW50OiBUdWVzZGF5LCBKdW5l IDE0LCAyMDExIDI6MzQgUE0NCj4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+IENjOiBtcGxz QGlldGYub3JnOyBwd2UzQGlldGYub3JnOyBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCAN Cj4gSGFTaGFyb24pOyBtYS55dXhpYUB6dGUuY29tLmNuDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10g W1BXRTNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLQ0KPiBUUExpbmVhclByb3RlY3Rp b25BcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPiANCj4gSGkgU2FzaGEsIHRoYW5rcyBhZ2FpbiBh bmQgc2VlIGlubGluZSB3aXRoIFtEQ10uDQo+IA0KPiBGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVp biBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXSANCj4gU2VudDogTW9u ZGF5LCBKdW5lIDEzLCAyMDExIDY6MTEgUE0NCj4gVG86IERhbmllbCBDb2huDQo+IENjOiBtcGxz QGlldGYub3JnOyBwd2UzQGlldGYub3JnOyBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCAN Cj4gSGFTaGFyb24pOyBtYS55dXhpYUB6dGUuY29tLmNuDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10g W1BXRTNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLQ0KPiBUUExpbmVhclByb3RlY3Rp b25BcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPiANCj4gRGFuaWVsIGFuZCBhbGwsDQo+IFBsZWFz ZSBzZWUgc29tZSBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQo+IA0KPiBSZWdhcmRzLA0KPiAgICAg IFNhc2hhDQo+IA0KPiBGcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNv bV0gDQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxMywgMjAxMSA1OjU1IFBNDQo+IFRvOiBTcHJlY2hl ciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik7IEFsZXhhbmRlciBWYWluc2h0ZWluOyAN Cj4gbWEueXV4aWFAenRlLmNvbS5jbg0KPiBDYzogbXBsc0BpZXRmLm9yZzsgcHdlM0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSRTogW21wbHNdIFtQV0UzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAi TVBMUy0NCj4gVFBMaW5lYXJQcm90ZWN0aW9uIEFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+IA0K PiBIaSwNCj4gDQo+IFRoYW5rcyBhbGwgZm9yIHRoZSBmZWVkYmFjay4gSSBiZWxpZXZlIHdlIGFs bCBhZ3JlZSB0aGF0IFBXIA0KPiBwcm90ZWN0aW9uIGlzIG9ubHkgcmVxdWlyZWQgaW4gdGhlIGV2 ZW50IG9mIFMtUEUgZmFpbHVyZSBhdCBhbiBNUy1QVw0KPiCoQyB0aGlzICBpcyBjbGVhcmx5IHN0 YXRlZCBpbiB0aGUgZHJhZnQuIE5vdywgYm90aCBTYXNoYSBhbmQgTnVyaXQgDQo+IG1lbnRpb24g dGhhdCB0aGUgUFcgcmVkdW5kYW5jeSBtZWNoYW5pc20gY2FuIG1lZXQgdGhlIE1QTFMtVFAgUFcg DQo+IHByb3RlY3Rpb24gcmVxdWlyZW1lbnRzLg0KPiBbW1tTYXNoYV1dXSChrSBzbmlwcGVkIKGt DQo+IEUuZy4sIHRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbXMgdGFrZSBjYXJlIG9mIGR1YWwt aG9tZWQgQ0VzIGluIA0KPiBTUy0gYW5kIE1TLVBXcyCoQyBzb21ldGhpbmcgdGhhdCBsaW5lciBw cm90ZWN0aW9uIG9mIFBXcyBjYW5ub3QgZG8uDQo+IFtEQ10gSaGvbSBhZnJhaWQgSSBkb26hr3Qg Zm9sbG93IHlvdSBoZXJlLiBXaGVyZSBkb2VzIFBXIHJlZHVuZGFuY3kgDQo+IHRha2UgY2FyZSBv ZiBkdWFsLWhvbWVkIENFPyBBY3R1YWxseSBQVyByZWR1bmRhbmN5IGRyYWZ0IGV4cGxpY2l0bHkg DQo+IHN0YXRlczogobBUaGUgbWV0aG9kIGZvciBkdWFsLWhvbWluZyBvZiBDRTEgdG8gUEUxIGFu ZCB0byBQRTMgbm9kZXMsIA0KPiBhbmQgdGhlIHByb3RvY29scyB1c2VkLCBhcmUgb3V0c2lkZSB0 aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudKGxLiANCj4gW1tbU2FzaGFdXV0gUXVvdGluZyBmcm9t IHRoZSBkcmFmdDoNCj4gMTUuMi4gTXVsdGlwbGUgTXVsdGktaG9tZWQgQ0VzIHdpdGggc2luZ2xl IFNTLVBXIHJlZHVuZGFuY3kgDQo+IA0KPiAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLSBF bXVsYXRlZCBTZXJ2aWNlIC0tLS0tLS0tLS0tLS0tLS0+fCANCj4gICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQo+ICAgICAg ICAgICAgICB8ICAgICAgICAgIHw8LS0tLS0tLSBQc2V1ZG8gV2lyZSAtLS0tLS0+fCAgICAgICAg ICB8IA0KPiAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgfCANCj4gICAgICAgICAgICAgIHwgICAgICAgICAgfCAgICB8PC0tIFBT TiBUdW5uZWxzLS0+fCAgICB8ICAgICAgICAgIHwgDQo+ICAgICAgICAgICAgICB8ICAgICAgICAg IFYgICAgViAgICAobm90IHNob3duKSAgIFYgICAgViAgICAgICAgICB8IA0KPiAgICAgICAgICAg ICAgViAgICBBQyAgICArLS0tLSsgICAgICAgICAgICAgICAgICArLS0tLSsgICAgIEFDICAgViAN Cj4gICAgICAgICstLS0tLSsgICAgfCAgICAgfC4uLi58Li4uLi4uLlBXMS4uLi4uLi4ufC4uLi58 ICAgICB8ICAgICstLS0tLSsgDQo+ICAgICAgICB8ICAgICB8LS0tLS0tLS0tLXwgUEUxfC4uLi4u LiAgIC4uLi4uLi4uLnwgUEUzfC0tLS0tLS0tLS18ICAgICB8IA0KPiAgICAgICAgfCBDRTEgfCAg ICAgICAgICArLS0tLSsgICAgICBcIC8gIFBXMyAgICArLS0tLSsgICAgICAgICAgfCBDRTIgfCAN Cj4gICAgICAgIHwgICAgIHwgICAgICAgICAgKy0tLS0rICAgICAgIFggICAgICAgICAgKy0tLS0r ICAgICAgICAgIHwgICAgIHwgDQo+ICAgICAgICB8ICAgICB8ICAgICAgICAgIHwgICAgfC4uLi4u Li8gXC4uUFc0Li4uLnwgICAgfCAgICAgICAgICB8ICAgICB8IA0KPiAgICAgICAgfCAgICAgfC0t LS0tLS0tLS18IFBFMnwgICAgICAgICAgICAgICAgICB8IFBFNHwtLS0tLS0tLS0gfCAgICAgfCAN Cj4gICAgICAgICstLS0tLSsgICAgfCAgICAgfC4uLi58Li4uLi5QVzIuLi4uLi4uLi4ufC4uLi58 ICAgICB8ICAgICstLS0tLSsgDQo+ICAgICAgICAgICAgICAgICAgIEFDICAgICstLS0tKyAgICAg ICAgICAgICAgICAgICstLS0tKyAgICBBQyANCj4gDQo+IA0KPiAgICAgIEZpZ3VyZSAxNS0yIE11 bHRpcGxlIE11bHRpLWhvbWVkIENFcyB3aXRoIHNpbmdsZSBTUy1QVyByZWR1bmRhbmN5IA0KPiAN Cj4gICAgVGhlIGFwcGxpY2F0aW9uIGluIEZpZ3VyZSAxNS0yIG1ha2VzIHVzZSBvZiB0aGUgSW5k ZXBlbmRlbnQgbW9kZSBvZiANCj4gICAgb3BlcmF0aW9uLiANCj4gDQo+ICAgIENFMSBpcyBkdWFs LWhvbWVkIHRvIFBFMSBhbmQgUEUyLiBDRTIgaXMgZHVhbC1ob21lZCBQRTMgYW5kIFBFNC4gVGhl IA0KPiAgICBtZXRob2QgZm9yIGR1YWwtaG9taW5nIGFuZCB0aGUgdXNlZCBwcm90b2NvbHMgYXJl IG91dHNpZGUgdGhlIHNjb3BlIA0KPiAgICBvZiB0aGlzIGRvY3VtZW50LiAgTm90ZSB0aGF0IHRo ZSBQU04gdHVubmVscyBhcmUgbm90IHNob3duIGluIHRoaXMgDQo+ICAgIGZpZ3VyZSBmb3IgY2xh cml0eS4gSG93ZXZlciwgaXQgY2FuIGJlIGFzc3VtZWQgdGhhdCBlYWNoIG9mIHRoZSBQV3MgDQo+ ICAgIHNob3duIGlzIGVuY2Fwc3VsYXRlZCBpbiBhIHNlcGFyYXRlIFBTTiB0dW5uZWwuIA0KPiAN Cj4gICAgQXNzdW1lIHRoYXQgdGhlIEFDIGZyb20gQ0UxIHRvIFBFMSBpcyBBY3RpdmUsIGZyb20g Q0UxIHRvIFBFMiBpcyANCj4gICAgU3RhbmRieTsgZnVydGhlcm1vcmUsIGFzc3VtZSB0aGF0IHRo ZSBBQyBmcm9tIENFMiB0byBQRTMgaXMgU3RhbmRieSANCj4gICAgYW5kIGZyb20gQ0UyIHRvIFBF NCBpcyBBY3RpdmUuIFRoZSBtZXRob2Qgb2YgZGVyaXZpbmcgQWN0aXZlL1N0YW5kYnkgDQo+ICAg IHN0YXR1cyBvZiB0aGUgQUMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4g DQo+IA0KPiAgICBQRTEgYWR2ZXJ0aXNlcyB0aGUgcHJlZmVyZW50aWFsIHN0YXR1cyAiQWN0aXZl IiBhbmQgb3BlcmF0aW9uYWwgDQo+ICAgIHN0YXR1cyAiUHNldWRvd2lyZSBmb3J3YXJkaW5nIiBm b3IgcHNldWRvd2lyZXMgUFcxIGFuZCBQVzQgY29ubmVjdGVkIA0KPiAgICB0byBQRTMgYW5kIFBF NC4gVGhpcyBzdGF0dXMgcmVmbGVjdHMgdGhlIGZvcndhcmRpbmcgc3RhdGUgb2YgdGhlIEFDIA0K PiAgICBhdHRhY2hlZCB0byBQRTEuIFBFMiBhZHZlcnRpc2VzIHByZWZlcmVudGlhbCBzdGF0dXMg IlN0YW5kYnkiIGFuZCANCj4gICAgb3BlcmF0aW9uYWwgc3RhdHVzICJQc2V1ZG93aXJlIGZvcndh cmRpbmciIGZvciBwc2V1ZG93aXJlcyBQVzIgYW5kIA0KPiAgICBQVzMgdG8gUEUzIGFuZCBQRTQu IFBFMyBhZHZlcnRpc2VzIHByZWZlcmVudGlhbCBzdGF0dXMgIlN0YW5kYnkiIGFuZCANCj4gICAg b3BlcmF0aW9uYWwgc3RhdHVzICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIGZvciBwc2V1ZG93aXJl cyBQVzEgYW5kIA0KPiAgICBQVzMgdG8gUEUxIGFuZCBQRTIuIFBFNCBhZHZlcnRpc2UgdGhlIHBy ZWZlcmVudGlhbCBzdGF0dXMgIkFjdGl2ZSIgDQo+ICAgIGFuZCBvcGVyYXRpb25hbCBzdGF0dXMg IlBzZXVkb3dpcmUgZm9yd2FyZGluZyIgZm9yIHBzZXVkb3dpcmVzIFBXMiANCj4gICAgYW5kIFBX NCB0byBQRTIgYW5kIFBFMSByZXNwZWN0aXZlbHkuIFRodXMgYnkgbWF0Y2hpbmcgdGhlIGxvY2Fs IGFuZCANCj4gICAgcmVtb3RlIHByZWZlcmVudGlhbCBmb3J3YXJkaW5nIHN0YXR1cyBvZiAiQWN0 aXZlIiBhbmQgb3BlcmF0aW9uYWwgDQo+ICAgIHN0YXR1cyBvZiAiUHNldWRvd2lyZSBmb3J3YXJk aW5nIiBvZiBwc2V1ZG93aXJlcywgdGhlIFBFIG5vZGVzIA0KPiAgICBkZXRlcm1pbmUgd2hpY2gg UFcgc2hvdWxkIGJlIGluIHRoZSBBY3RpdmUgc3RhdGUuIEluIHRoaXMgY2FzZSBpdCBpcyANCj4g ICAgUFc0IHRoYXQgd2lsbCBiZSBzZWxlY3RlZC4gDQo+IA0KPiAgICBPbiBmYWlsdXJlIG9mIHRo ZSBBQyBiZXR3ZWVuIENFMSBhbmQgUEUxLCB0aGUgZm9yd2FyZGluZyBzdGF0ZSBvZiANCj4gICAg dGhlIEFDIG9uIFBFMiBpcyBjaGFuZ2VkIHRvIEFjdGl2ZS4gUEUyIHRoZW4gYW5ub3VuY2VzIHRo ZSBuZXdseSANCj4gICAgY2hhbmdlZCAncHJlZmVyZW50aWFsIGZvcndhcmRpbmcnIHN0YXR1cyBi aXQgb2YgImFjdGl2ZSIgdG8gUEUzIGFuZCANCj4gICAgUEU0LiBQRTEgd2lsbCBhZHZlcnRpc2Ug YSBQVyBzdGF0dXMgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaW5kaWNhdGluZyANCj4gICAgdGhhdCB0 aGUgQUMgYmV0d2VlbiBDRTEgYW5kIFBFMSBpcyBvcGVyYXRpb25hbGx5IGRvd24uIFBFMiBhbmQg UEU0IA0KPiAgICBtYXRjaCB0aGUgbG9jYWwgYW5kIHJlbW90ZSBwcmVmZXJlbnRpYWwgZm9yd2Fy ZGluZyBzdGF0dXMgb2YgDQo+ICAgICJBY3RpdmUiIGFuZCBvcGVyYXRpb25hbCBzdGF0dXMgIlBz ZXVkb3dpcmUgZm9yd2FyZGluZyIgYW5kIHNlbGVjdCANCj4gICAgUFcyIGFzIHRoZSBuZXcgYWN0 aXZlIHBzZXVkb3dpcmUgdG8gc2VuZCB0cmFmZmljIHRvLiANCj4gDQo+ICAgIE9uIGZhaWx1cmUg b2YgUEUxIG5vZGUsIFBFMiB3aWxsIGRldGVjdCBpdCBhbmQgd2lsbCB0cmFuc2l0aW9uIHRoZSAN Cj4gICAgZm9yd2FyZGluZyBzdGF0ZSBvZiBpdHMgQUMgdG8gQWN0aXZlLiBUaGUgbWV0aG9kIGJ5 IHdoaWNoIFBFMiANCj4gICAgZGV0ZWN0cyB0aGF0IFBFMSBpcyBkb3duIGlzIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuIFBFMiANCj4gICAgdGhlbiBhbm5vdW5jZXMgdGhlIG5l d2x5IGNoYW5nZWQgJ3ByZWZlcmVudGlhbCBmb3J3YXJkaW5nJyBzdGF0dXMgDQo+ICAgIGJpdCBv ZiAiQWN0aXZlIiB0byBQRTMgYW5kIFBFNC4gUEUyIGFuZCBQRTQgbWF0Y2ggdGhlIGxvY2FsIGFu ZCANCj4gICAgcmVtb3RlIHByZWZlcmVudGlhbCBmb3J3YXJkaW5nIHN0YXR1cyBvZiAiQWN0aXZl IiBhbmQgb3BlcmF0aW9uYWwgDQo+ICAgIHN0YXR1cyAiUHNldWRvd2lyZSBmb3J3YXJkaW5nIiBh bmQgc2VsZWN0IFBXMiBhcyB0aGUgbmV3IGFjdGl2ZSANCj4gICAgcHNldWRvd2lyZSB0byBzZW5k IHRyYWZmaWMgdG8uIE5vdGUgdGhhdCBQRTMgYW5kIFBFNCBtYXkgaGF2ZSANCj4gICAgZGV0ZWN0 ZWQgdGhhdCB0aGUgUFcgdG8gUEUxIHdlbnQgZG93biB2aWEgVC1MRFAgSGVsbG8gdGltZW91dCBv ciB2aWEgDQo+ICAgIG90aGVyIG1lYW5zLiBIb3dldmVyLCB0aGV5IHdpbGwgbm90IGJlIGFibGUg dG8gZm9yd2FyZCB1c2VyIHRyYWZmaWMgDQo+ICAgIHVudGlsIHRoZXkgcmVjZWl2ZWQgdGhlIHVw ZGF0ZWQgc3RhdHVzIGJpdCBmcm9tIFBFMi4gDQo+IA0KPiAgICBCZWNhdXNlIGVhY2ggZHVhbC1o b21pbmcgYWxnb3JpdGhtIHJ1bm5pbmcgb24gdGhlIHR3byBub2RlIHNldHMsIA0KPiAgICBpLmUu LCB7Q0UxLCBQRTEsIFBFMn0gYW5kIHtDRTIsIFBFMywgUEU0fSwgc2VsZWN0cyB0aGUgYWN0aXZl IEFDIA0KPiAgICBpbmRlcGVuZGVudGx5LCB0aGVyZSBpcyBhIG5lZWQgdG8gc2lnbmFsIHRoZSBh Y3RpdmUgc3RhdHVzIG9mIHRoZSBBQyANCj4gICAgc3VjaCB0aGF0IHRoZSBQRSBub2RlcyBjYW4g c2VsZWN0IGEgY29tbW9uIGFjdGl2ZSBQVyBmb3IgZW5kLXRvLWVuZCANCj4gICAgZm9yd2FyZGlu ZyBiZXR3ZWVuIENFMSBhbmQgQ0UyIGFzIHBlciB0aGUgcHJvY2VkdXJlcyBpbiB0aGUgDQo+ICAg IGluZGVwZW5kZW50IG1vZGUuIA0KPiANCj4gICAgTm90ZSB0aGF0IGFueSBwcmltYXJ5L3NlY29u ZGFyeSBwcm9jZWR1cmVzLCBhcyBkZWZpbmVkIGluIHNlY3Rpb25zIA0KPiAgICA1LjEuICBhbmQg NS4yLiAsIGRvIG5vdCBhcHBseSBpbiB0aGlzIHVzZSBjYXNlIGFzIHRoZSBBY3RpdmUvU3RhbmRi eSANCj4gICAgc3RhdHVzIGlzIGRyaXZlbiBieSB0aGUgQUMgZm9yd2FyZGluZyBzdGF0ZSBhcyBk ZXRlcm1pbmVkIGJ5IHRoZSBBQyANCj4gICAgZHVhbC1ob21pbmcgcHJvdG9jb2wgdXNlZC4gDQo+ IA0KPiANCj4gSSBiZWxpZXZlIHlvdaGvdmUgdGFrZW4geW91ciChsG91dCBvZiBzY29wZaGxIHJl ZmVyZW5jZSBmcm9tIHRoaXMgdGV4dCwNCj4gYnV0IElNSE8geW91IG1pc2ludGVycHJldGVkIGl0 LiANCj4gV2hhdCBpdCBtZWFucyAob3Igc28gSSByZWFkIGl0KSBpcyB0aGF0IHNwZWNpZmljIGR1 YWwtaG9taW5nIA0KPiBwcm90b2NvbCBpcyBvdXQgb2Ygc2NvcGUgYXMgbG9uZyBhcyBpdCBtZWV0 cyBjZXJ0YWluIGFzc3VtcHRpb25zLg0KPiBBc2lkZTogSXQgd291bGQgYmUgZ29vZCBpZiB0aGUg YXV0aG9ycyBvZiB0aGUgUFcgcmVkdW5kYW5jeSBkcmFmdHMgDQo+IGNvdWxkIGV4cGxpY2l0bHkg c3BlY2lmeSB0aGVzZSBhc3N1bXB0aW9ucy4NCj4gDQo+IFtbW1Nhc2hhXV1dIKGtIHNuaXBwZWQg oa0NCj4gDQo+IE5vdyBsZXShr3MgdHVybiBvdXIgYXR0ZW50aW9uIGJhY2sgdG8gd2hldGhlciB0 aGUgUFcgcmVkdW5kYW5jeSANCj4gZHJhYWZ0IGNhbiBiZSB1c2VkIHRvIG1lZXQgTVBMUy1UUCBQ VyBwcm90ZWN0aW9uIHJlcXVpcmVtZW50cy4gSSBjYW4NCj4gaWRlbnRpZnkgdGhlIGZvbGxvd2lu ZyByZWFzb25zIHdoeSBpbiBpdHMgY3VycmVudCBmb3JtIGl0IGRvZXNuoa90Og0KPiANCj4gLSAg ICAgICAgICBJdCBleHBsaWNpdGx5ICihsG91dHNpZGUgdGhlIHNjb3BlobEpIGRvZXMgbm90IGRl ZmluZSANCj4gcHJvdGVjdGlvbiB0cmlnZ2VycyBhbmQgaG93IHRvIGhhbmRsZSBjb2V4aXN0aW5n IHRyaWdnZXJzLCBhcyANCj4gcmVxdWVzdGVkIGluIFJGQyA1NjU0IChNUExTLVRQIFJlcXVpcmVt ZW50cyksIHJlcXMgIzc1LCAjNzYgYW5kICM3OQ0KPiBbW1tTYXNoYV1dXSBTbyB3aGF0PyBEZWZp bml0aW9uIG9mIHRyaWdnZXJzIGlzIG9ydGhvZ29uYWwgdG8gaG93IA0KPiBjb29yZGluYXRlZCBw cm90ZWN0aW9uIHN3aXRjaGluZyBoYXBwZW5zLg0KPiBbRENdIEl0IGlzLiBCdXQgc3RpbGwgaXQg bmVlZHMgdG8gYmUgZGVmaW5lZCBieSB0aGUgcmVjb3ZlcnkgDQo+IGZyYW1ld29yaywgZS5nLiB3 aGF0IHNob3VsZCB0aGUgZW5kcG9pbnQgZG8gd2hlbiBvbmUgUFcgaXMgaW4gU0YgYW5kDQo+IHRo ZSBvdGhlciBpcyBpbiBTRCwgb3Igd2hlbiBib3RoIGFyZSBpbiBTRC4gT3BlcmF0b3JzIGV4cGVj dCB3ZWxsLQ0KPiBkZWZpbmVkIGJlaGF2aW9yIGluIHRoZXNlIGFuZCBvdGhlciBzY2VuYXJpb3Ms IGFuZCBQVyByZWR1bmRhbmN5IA0KPiBkb2VzIG5vdCBkZWZpbmUgdGhlbSAoYmVjYXVzZSBpdCB3 YXMgbm90IGluIHRoZWlyIHNjb3BlKS4gDQo+IFtbW1Nhc2hhXV1dIEkgd29uZGVyIGlmIHlvdSBo YXZlIGZvbGxvd2VkIHRoZSBkaXNjdXNzaW9uIHJlZ2FyZGluZyANCj4gYWJpbGl0eSB0byBkZWZp bmUgU0QgY29uZGl0aW9uIGZvciBMU1BzIGFuZCBQV3Mgb24gdGhlIE1QTFMtVFAgbGlzdD8NCj4g SU1PIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBkZWZpbmUgaXQgaW4gYSBtZWFuaW5nZnVsIHdheS4g SGVuY2UgSSBkbyANCj4gbm90IHNlZSBhIHByb3Bvc2FsIHRoYXQgZG9lcyBub3QgYWRkcmVzcyBh IHNjZW5hcmlvIHRoYXQgZG9lcyBub3QgDQo+IGV4aXN0IGluIHJlYWxpdHkgYXMgYSBmbGF3ZWQg b25lLg0KPiANCj4gLSAgICAgICAgICBJdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBhYmlsaXR5IHRv IGRpc3Rpbmd1aXNoIGJldHdlZW4gDQo+IGRpZmZlcmVudCB0eXBlcyBvZiB0cmlnZ2VycyAoaS5l LiBvbmUgZW5kIGRvZXNuoa90IGtub3cgd2h5IHRoZSBvdGhlcg0KPiBlbmQgdHJpZ2dlcmVkIHN3 aXRjaCksIGFzIHJlcXVlc3RlZCBpbiBSRkMgNTY1NCAoTVBMUy1UUCANCj4gUmVxdWlyZW1lbnRz KSwgcmVxICM3Nw0KPiAtICAgICAgICAgIEl0IGRvZXMgbm90IGRlZmluZSByZXZlcnRpdmUvbm9u cmV2ZXJ0aXZlIGJlaGF2aW9yLCBhcyANCj4gcmVxdWVzdGVkIGluIFJGQyA1NjU0IChNUExTLVRQ IFJlcXVpcmVtZW50cyksIHJlcSAjNjQNCj4gLSAgICAgICAgICBJdCBkb2VzIG5vdCBkZWZpbmUg aG9sZG9mZiBzdXBwb3J0LCB3aGljaCBpcyBlc3BlY2lhbGx5IA0KPiBpbXBvcnRhbnQgdG8gYXZv aWQgcmFjZSBjb25kaXRpb25zIHdpdGggTFNQIHByb3RlY3Rpb24gd2hlbiBpdCBleGlzdHMNCj4g LSAgICAgICAgICBJdCBkb2VzbqGvdCBzdXBwb3J0IDErMSBtb2RlLCBhcyByZXF1ZXN0ZWQgaW4g UkZDIDU2NTQgDQo+IChNUExTLVRQIFJlcXVpcmVtZW50cyksIHJlcSAjNjUgDQo+IFtbW1Nhc2hh XV1dIEFsbCB0aGVzZSBjbGFpbXMgYXJlIGNvcnJlY3QgqEMgYW5kICB0aGlzIHNob3VsZCBub3Qg YmUgYQ0KPiBzdXJwcmlzZSwgYmVjYXVzZSBNUExTLVRQIHJlcXVpcmVtZW50cyBoYXZlIGJlZW4g ZGVmaW5lZCBtdWNoIGxhdGVyIA0KPiB0aGFuIHRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbS4g DQo+IEJ1dCBJIGRvIG5vdCB0aGluayB0aGF0IHRoaXMganVzdGlmaWVzIGNvLWV4aXN0ZW5jZSBv ZiB0d28gZGlmZmVyZW50DQo+IG1lY2hhbmlzbXMuDQo+IFtEQ10gU28gaG93IGRvIHlvdSBwcm9w b3NlIHRvIG1lZXQgdGhlIFBXIHByb3RlY3Rpb24gcmVxdWlyZW1lbnQ/IA0KPiAtICAgICAgICAg IEl0oa9zIGEgdHdvLXBoYXNlIHByb3RvY29sLCB3aXRoIHRoZSBjb25zZXF1ZW50IGltcGFjdCBv biANCnRpbWluZw0KPiBbW1tTYXNoYV1dXSBDb3VsZCB5b3UgcGxlYXNlIGVsYWJvcmF0ZT8gW0RD XSBJbiBkcmFmdC1pZXRmLW1wbHMtdHAtDQo+IGxpbmVhci1wcm90ZWN0aW9uLCBlYWNoIGVuZHBv aW50IHdpbGwgaW1tZWRpYXRlbHkgc3dpdGNoIHRyYWZmaWMgdG8gDQo+IHRoZSBvdGhlciBwYXRo IHVwb24gaWRlbnRpZnlpbmcgYW4gU0YgY29uZGl0aW9uIGluIGEgcGF0aCwgd2l0aG91dCANCj4g d2FpdGluZyBmb3IgdGhlIGZhciBlbmQgdG8gYWNrbm93bGVkZ2UgdGhlIHN3aXRjaCAoMS1waGFz ZSkuIEluIFBXIA0KPiByZWR1bmRhbmN5LCBhbiBlbmRwb2ludCBkZXRlY3RpbmcgYW4gU0YgY29u ZGl0aW9uIGluIGEgcGF0aCB3aWxsIG5vdA0KPiBzd2l0Y2ggdW50aWwgdGhlIGZhciBlbmQgaGFz IGFja25vd2xlZGdlZCB0aGUgc3dpdGNoICgyLXBoYXNlKS4gDQo+IE5lZWRsZXNzIHRvIHNheSwg cmVjb3ZlcnkgaXMgc2xvd2VyIGluIGEgMi1waGFzZSBwcm90b2NvbC4NCj4gW1tbU2FzaGFdXV0g VG8gdGhlIGJlc3Qgb2YgbXkgdW5kZXJzdGFuZGluZywgMS1waGFzZSBwcm90ZWN0aW9uIGlzIA0K PiBvbmx5IHBvc3NpYmxlIGluIDErMSB1bmlkaXJlY3Rpb25hbCBhcmNoaXRlY3R1cmVzLiBBbmQg eWVzLCBJIGtub3cgDQo+IHRoYXQgTVBMUy1UUCByZXF1aXJlcyBhICBtZWNoYW5pc20gdG8gc3Vw cG9ydCB0aGlzOyB3aGV0aGVyIGFueWJvZHkgDQo+IHdvdWxkIHJlYWxseSBkbyB0aGF0IGluIHRo ZSBwYWNrZXQtc3dpdGNoaW5nIG5ldHdvcmsgaXMgbm90IGNsZWFyIHRvDQo+IG1lLiBBbmQgSSBh Y2tub3dsZWRnZSB0aGF0IHRoZSBQVyByZWR1bmRhbmN5IGRyYWZ0cyBkbyBub3Qgc3VwcG9ydCAN Cj4gMSsxIHVuaWRpcmVjdGlvbmFsIHNjaGVtZS4gDQo+IA0KPiAtICAgICAgICAgIEl0IGRvZXNu oa90IGRlZmluZSByZXRyYW5zbWlzc2lvbiBvZiBwcm90ZWN0aW9uIA0KPiBjb29yZGluYXRpb24g bWVzc2FnZXMsIHNvIGxvc3Mgb2YgYSBzaW5nbGUgUERVIGNhbiByZXN1bHQgaW4gDQo+IHN3aXRj aG92ZXIgbm90IHRha2luZyBwbGFjZSwgdGh1cyBub3Qgc3VwcG9ydGluZyBzdWItNTAgbXMgcmVj b3ZlcnkgDQo+IGluIHRoaXMgY2FzZQ0KPiBbW1tTYXNoYV1dXSBUaGUgUFcgcmVkdW5kYW5jeSBw cm90b2NvbCBydW5zIGVpdGhlciBvbiB0b3Agb2YgTERQIA0KPiAod2hpY2ggYmVuZWZpdHMgZnJv bSBUQ1AgcmV0cmFuc21pc3Npb25zKSBvciBvbiB0b3Agb2Ygc3RhdGljIFBXIA0KPiBzdGF0dXMg bWVzc2FnZXMgKHdoZXJlIHJldHJhbnNtaXNzaW9uIGlzIGRlZmluZWQpLiANCj4gW0RDXSBUcnVl IKhDIGJ1dCBzdGF0aWMgUFcgc3RhdHVzIGRlZmluZXMgc2xvdyByZXRyYW5zbWlzc2lvbiAoobB3 aWxsIA0KPiBiZSB0cmFuc21pdHRlZCB0d2ljZSBhdCBhbiBpbml0aWFsIGludGVydmFsIG9mIG9u ZSBzZWNvbmShsSkgd2hpbGUgDQo+IGRyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJvdGVjdGlv biBzcGVjaWZpZXMgZmFzdCByZXRyYW5zbWlzc2lvbiANCj4gd2hlbiByZXF1aXJlZCBmb3IgZmFz dCByZWNvdmVyeSAoc2VjdGlvbiAzLjEuNCkuIA0KPiANCj4gSW4gc3VtbWFyeSwgUFcgcmVkdW5k YW5jeSB3YXMgbm90IGRlc2lnbmVkIHdpdGggVFAgcmVxdWlyZW1lbnRzIGluIA0KPiBtaW5kLCBh bmQgYXMgc3VjaCBkb2VzIG5vdCBtZWV0IHRoZSBUUCByZXF1aXJlbWVudHMuIE9mIGNvdXJzZSAN Cj4gbW9kaWZpY2F0aW9ucyBtYXkgYmUgaW50cm9kdWNlZCwgYnV0IHdoeSByZWludmVudCB0aGUg d2hlZWwgd2hlbiANCj4gdGhlcmUgaXMgYSBwcm90b2NvbCAoZHJhZnQtaWV0Zi1tcGxzLXRwLWxp bmVhci1wcm90ZWN0aW9uLTA2KSBpbiB0aGUNCj4gc3RhbmRhcmRzIHRyYWNrIHRoYXQgc3VwcG9y dHMgYWxsIHRoZSBhYm92ZSByZXF1aXJlbWVudHMgYW5kIGNhbiBiZSANCj4gYXBwbGllZCB0byBN Uy1QVyBwcm90ZWN0aW9uIHdpdGggbWlub3IgbW9kaWZpY2F0aW9ucz8NCj4gW1tbU2FzaGFdXV0g QXMgSSBzYWlkLCBiZWNhdXNlIHRoZSBhcHBsaWNhYmlsaXR5IHNjb3BlIGlzIGJ5IGZhciB0b28N Cj4gbmFycm93IHRvIGp1c3RpZnkgYSBkZWRpY2F0ZWQgcHJvdG9jb2wuDQo+IFtEQ10gSWYgd2Ug d2VyZSBkaXNjdXNzaW5nIGRlc2lnbmluZyBhIG5ldyBwcm90b2NvbCwgSSBtaWdodCBhZ3JlZSAN Cj4gd2l0aCB5b3UuIEJ1dCBmcm9tIGEgcHJhY3RpY2FsIHN0YW5kcG9pbnQsIHRoZSBQVyBwcm90 ZWN0aW9uIGRyYWZ0IA0KPiBpcyBub3QgYSBkZWRpY2F0ZWQgcHJvdG9jb2wgqEMgaXShr3MgYW4g YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgdG8gYW4gDQo+IGV4aXN0aW5nIHByb3RvY29sLiBCb3Ro IGZyb20gdGhlIGltcGxlbWVudGF0aW9uIGFuZCB0aGUgb3BlcmF0aW9uYWwgDQo+IHBvaW50IG9m IHZpZXcgaXQgZGVmaW5lcyBhIG5ldyB1c2UgY2FzZSBmb3IgYW4gZXhpc3RpbmcgcHJvdG9jb2wg YW5kIA0KY29uY2VwdC4NCj4gDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gRGFuaWVsDQo+IA0KPiAN Cj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgDQo+IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hh cm9uKQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMTMsIDIwMTEgNDowMiBQTQ0KPiBUbzogZXh0IEFs ZXhhbmRlciBWYWluc2h0ZWluOyBtYS55dXhpYUB6dGUuY29tLmNuDQo+IENjOiBtcGxzQGlldGYu b3JnOyBwd2UzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gW1BXRTNdIFNlZWtpbmcg ZmVlZGJhY2sgb24gSS1EICJNUExTLQ0KPiBUUExpbmVhclByb3RlY3Rpb24gQXBwbGljYWJpbGl0 eSB0byBNUy1QVyINCj4gDQo+IEhpLA0KPiBJIHdvdWxkIGxpa2UgdG8gc2Vjb25kIFNhc2hhLg0K PiBFbmQtdG8tZW5kIFBXIHByb3RlY3Rpb24gKHdpdGggZGl2ZXJzZSBwYXRocykgZG9lcyBub3Qg c2NhbGUsIGFuZCANCj4gcHV0IGhhcmQgcmVzdHJpY3Rpb25zIG9uIHRoZSB1dGlsaXphdGlvbiBv ZiB0aGUgcmVzb3VyY2VzLiANCj4gTVBMUy1UUCBQV3MgYXJlIGNhcnJpZWQgYWNyb3NzIHRoZSBu ZXR3b3JrIGluc2lkZSBNUExTLVRQIExTUHMuIA0KPiBUaGVyZWZvcmUsIGFuIG9idmlvdXMgd2F5 IHRvIHByb3ZpZGUgcHJvdGVjdGlvbiBmb3IgYSBQVyBpcyB0byANCj4gcHJvdGVjdCB0aGUgTFNQ IHRoYXQgY2FycmllcyBpdC4gDQo+IElmIHRoZSBQVyBpcyBhIG11bHRpLXNlZ21lbnQgUFcsIHRo ZW4gTFNQIHJlY292ZXJ5IGNhbiBvbmx5IHByb3RlY3QgDQo+IHRoZSBQVyBpbiBpbmRpdmlkdWFs IHNlZ21lbnRzLiAgVGhpcyBtZWFucyB0aGF0IGEgc2luZ2xlIExTUCANCj4gcmVjb3ZlcnkgYWN0 aW9uIGNhbm5vdCBwcm90ZWN0IGFnYWluc3QgYSBmYWlsdXJlIG9mIGEgUFcgc3dpdGNoaW5nIA0K PiBwb2ludCAoYW4gUy1QRSkuDQo+IFdoZW4gcHJvdGVjdGluZyBhZ2FpbnN0IGFuIEFDIG9yIFQv Uy1QRSBmYWlsdXJlIGJ5IGR1YWwgDQo+IGNvbm5lY3Rpdml0eSwgUFcgcmVkdW5kYW5jeSBtZWNo YW5pc21zIHByb3ZpZGUgbWVhbnMgZm9yIHRoZSBQRXMgdG8gDQo+IGNvb3JkaW5hdGUgb3ZlciB3 aGljaCBMU1AgdGhlIHRyYWZmaWMgb2YgdGhlIFBXIGlzIGNhcnJpZWQuIA0KPiBJIGFsc28gZG91 YnQgd2h5IHRoZXJlIGlzIGEgbmVlZCBmb3IgYWRkaXRpb25hbCBtZWNoYW5pc20uIA0KPiBCZXN0 IHJlZ2FyZHMsDQo+IE51cml0DQo+IA0KPiBGcm9tOiBwd2UzLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCj4gZXh0IEFsZXhhbmRl ciBWYWluc2h0ZWluDQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxMywgMjAxMSAzOjQzIFBNDQo+IFRv OiBtYS55dXhpYUB6dGUuY29tLmNuDQo+IENjOiBtcGxzQGlldGYub3JnOyBwd2UzQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbUFdFM10gW21wbHNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJN UExTLVRQIA0KPiBMaW5lYXJQcm90ZWN0aW9uIEFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+IA0K PiBEZWFyIE1hIGFuZCBhbGwsDQo+IEFkZGluZyB0aGUgUFdFMyBXRyB0byBteSByZXNwb25zZS4N Cj4gDQo+IFRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbSBzdXBwb3J0cyBsaW5lYXIgcHJvdGVj dGlvbiBvZiBNUy1QV3MgYXMgDQo+IG9uZSBvZiBtYW55IGFkZGl0aW9uYWwgYXBwbGljYXRpb24g dXNlIGNhc2VzOg0KPiBBcHBlbmRpeCBBIG9mIHRoZSBQVyByZWR1bmRhbmN5IEJpdCBkcmFmdCBk ZXNjcmliZXMgNSBhcHBsaWNhdGlvbiANCj4gdXNlcyBjYXNlcyBpbiBhZGRpdGlvbiB0byBNUy1Q VyB3aXRoIHNpbmdsZS1ob21lZCBDRXMgKHdoaWNoIGlzIA0KPiBsaXN0ZWQgdGhlcmUgYXMgdXNl IGNhc2UgNSkuDQo+IEFuZCBpdCBpcyBlcXVhbGx5IGFwcGxpY2FibGUgdG8gSVAvTVBMUyBhbmQg TVBMUyAtIHdpdGggdGhlIGhlbHAgb2YgIHRoZSANCg0KPiBTdGF0aWMgUFcgU3RhdHVzIE1lc3Nh Z2VzIGRyYWZ0KCBpZiwgZm9yIHdoYXRldmVyIHJlYXNvbiwgeW91IGRvIG5vdA0KPiB3YW50ICB0 bywgb3IgY2Fubm90LCB1c2UgUkZDIDQ0NDcpLg0KPiANCj4gSGVuY2UgSSBkb3VidCB0aGUgbmVl ZCBmb3IgeWV0IGFub3RoZXIgUFcgcmVkdW5kYW5jeSAgbWVjaGFuaXNtIHdpdGgNCj4gbmFycm93 IHNjb3BlIG9mIGFwcGxpY2FiaWxpdHkuDQo+IA0KPiBSZWdhcmRzLA0KPiAgICAgIFNhc2hhDQo+ IA0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiANCj4gbWEueXV4aWFAenRlLmNvbS5jbg0KPiBTZW50OiBNb25k YXksIEp1bmUgMTMsIDIwMTEgMzoyNSBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW21wbHNdIFNlZWtpbmcgZmVlZGJhY2sgb24gSS1EICJNUExTLVRQIExpbmVhciANCj4g UHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPiANCj4gSGkgYWxsLCANCj4gDQo+ IFRoZSBsaW5lYXIgcHJvdGVjdGlvbiBtZWNoYW5pc20gZm9yIExTUCBhbmQgUFcoaW5jbHVkaW5n IE1TLVBXKSANCj4gc2hvdWxkIGJlIHRoZSBzYW1lIGFuZCBpdCBpcyB2YWx1YWJsZSB0byBkZXNj cmliZSBpdCBjbGVhcmx5LiANCj4gDQo+IEJUVywgdGhlcmUgaXMgYSB0eXBvLCBpdCBpcyAiVC1Q RSBaIiBpbnN0ZWFkIG9mICJULVBFIEIiLiANCj4gDQo+ICAiIA0KPiAgIEZpZ3VyZSAxIGlsbHVz dHJhdGVzIHN1Y2ggYSBzY2VuYXJpbywgd2hlcmUgdHdvIE1TLVBXcyBhcmUgDQo+ICAgZXN0YWJs aXNoZWQgYmV0d2VlbiBULVBFIEEgYW5kIFQtUEUgQiwgb3ZlciBTLVBFcyAxLTIgYW5kIDMtNCAN Cj4gICByZXNwZWN0aXZlbHkuIEVhY2ggUFcgc2VnbWVudCBpcyBlc3RhYmxpc2hlZCBvdmVyIGFu IExTUCAoZS5nLiBQVy0gDQo+ICAgczEyIG92ZXIgTFNQMTIpLiANCj4gICIgDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERhbmllbCBDb2huIA0KPiBTZW50OiBUdWVzZGF5 LCBNYXkgMTcsIDIwMTEgNDoxNCBQTQ0KPiBUbzogbXBscw0KPiBTdWJqZWN0OiBTZWVraW5nIGZl ZWRiYWNrIG9uIEktRCAiTVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbg0KPiBBcHBsaWNhYmlsaXR5 IHRvIE1TLVBXIg0KPiBJbXBvcnRhbmNlOiBIaWdoDQo+IA0KPiBIaSBNUExTZXJzLA0KPiANCj4g SSB1cGxvYWRlZCAiTVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1T LVBXIiBJLUQNCj4gKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNvaG4tbXBscy10 cC1wdy1wcm90ZWN0aW9uLTAwKQ0KPiANCj4gVGhlIGFic3RyYWN0IGdvZXM6DQo+IA0KPiBPbmUg b2YgdGhlIHJlcXVpcmVtZW50cyBvZiB0aGUgTVBMUyB0cmFuc3BvcnQgcHJvZmlsZSBbUkZDIDU2 NTRdIGlzDQo+IHRvIHByb3ZpZGUgbGluZWFyIHByb3RlY3Rpb24gZm9yIHRyYW5zcG9ydCBwYXRo cywgd2hpY2ggaW5jbHVkZSBib3RoDQo+IExTUHMgYW5kIFBXcy4gVGhlIGZ1bmN0aW9uYWwgYXJj aGl0ZWN0dXJlIGRlc2NyaWJlZCBpbiBbU3Vydml2RndrXQ0KPiBpcyBhcHBsaWNhYmxlIHRvIGJv dGggTFNQIGFuZCBQV3MsIGhvd2V2ZXIgW0xpbmVhclByb3RdIGRvZXMgbm90DQo+IGV4cGxpY2l0 bHkgZGVzY3JpYmUgbWVjaGFuaXNtcyBmb3IgUFcgcHJvdGVjdGlvbiBpbiBNUExTLVRQLg0KPiAN Cj4gVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBsaW5lYXIg cHJvdGVjdGlvbg0KPiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFtMaW5lYXJQcm90XSB0byBNUExT LVRQIHNlZ21lbnRlZCBQV3MgDQo+IChNUy1QV3MpIGFzIGRlZmluZWQgaW4gW1JGQyA2MDczXS4N Cj4gDQo+IENvdWxkIHlvdSBwbGVhc2UgcmV2aWV3IGl0IGFuZCBzZW5kIGZlZWRiYWNrIHRvIHRo ZSBtYWlsaW5nIGxpc3Qgb3INCj4gZGlyZWN0bHkgdG8gdGhlIGF1dGhvcj8gDQo+IA0KPiBMb29r aW5nIGZvcndhcmQgdG8geW91ciBmZWVkYmFjaywgDQo+IA0KPiBEYW5pZWwgDQo+IFRoaXMgZS1t YWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFp bnMgDQo+IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJl IHByb3ByaWV0YXJ5IHRvIA0KPiBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZQ0KPiBpbmZvcm0gdXMgYnkgZS1tYWlsLCBw aG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIA0KPiBhbGwgY29w aWVzIHRoZXJlb2YuIA0KPiBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUg cmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIA0KPiBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05G SURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byANCj4gRUNJIFRlbGVjb20u IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UN Cj4gaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhl IG9yaWdpbmFsIGFuZCANCj4gYWxsIGNvcGllcyB0aGVyZW9mLiANCj4gVGhpcyBlLW1haWwgbWVz c2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyANCj4g aW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJp ZXRhcnkgdG8gDQo+IEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5z bWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9y IGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgDQo+IGFsbCBjb3BpZXMgdGhl cmVvZi4gDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2Vu ZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRp YWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNy ZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp cyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMg bWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRp LVNwYW0gc3lzdGVtLg0K --=_alternative 002EE0C8482578B5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNhc2hhLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7TGluZWFyIHByb3Rl Y3Rpb24mcXVvdDsgaXMgZGlmZmVyZW50DQpmcm9tICZxdW90OzwvZm9udD48dHQ+PGZvbnQgc2l6 ZT0yPk11bHRpLWhvbWVkPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pg0KQ0UgPC9mb250Pjx0dD48Zm9udCBzaXplPTI+cmVkdW5kYW5jeTwvZm9udD48L3R0Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsNCmFuZCBoYXMgbm8gcmVmZXJlbmNlIHdp dGggQUMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5X b3JraW5nIHBhdGgocykgYW5kIHByb3RlY3Rpb24gcGF0aChzKQ0KaGF2ZSBzYW1lIHNvdXJjZSBh bmQgc2luayBlbmRwb2ludHMgaW4gbGluZWFyIHByb3RlY3Rpb24gdHlwZS48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklNSE8sIFdoZW4gUy1QRSBmYWls cywgaXQgaXMgbW9yZSBzaW1wbGUNCnRvIHVzZSAmcXVvdDtMaW5lYXIgcHJvdGVjdGlvbiZxdW90 OyB0byBwcm90ZWN0IGl0LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCBSZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+TWE8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5BbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb20mZ3Q7DQrQtNPaIDIwMTEtMDYtMTQgMjA6MDI6MTA6PGJyPg0KPGJyPg0KJmd0OyBE YW5pZWwsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFBsZWFzZSBzZWUg bW9yZSBpbmxpbmUgKGJvbGQgcHVycGxlIGl0YWxpY3MpLg0KSaGvdmUgYWxzbyBzdHJpcHBlZCB0 aGU8YnI+DQomZ3Q7IHBvcnRpb25zIG9mIHRoZSB0ZXh0IHRoYXQgYXJlIG5vdCByZWxhdGVkIHRv IHRoaXMgcm91bmQgb2YgY29tbWVudHMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBSZWdh cmRzLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1Nhc2hhPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNw OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBEYW5pZWwgQ29o biBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbV0NCjxicj4NCiZndDsgU2VudDogVHVlc2RheSwg SnVuZSAxNCwgMjAxMSAyOjM0IFBNPGJyPg0KJmd0OyBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW48 YnI+DQomZ3Q7IENjOiBtcGxzQGlldGYub3JnOyBwd2UzQGlldGYub3JnOyBTcHJlY2hlciwgTnVy aXQgKE5TTiAtIElML0hvZCA8YnI+DQomZ3Q7IEhhU2hhcm9uKTsgbWEueXV4aWFAenRlLmNvbS5j bjxicj4NCiZndDsgU3ViamVjdDogUkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBv biBJLUQgJnF1b3Q7TVBMUy08YnI+DQomZ3Q7IFRQTGluZWFyUHJvdGVjdGlvbkFwcGxpY2FiaWxp dHkgdG8gTVMtUFcmcXVvdDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg Jm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEhpIFNhc2hhLCB0 aGFua3MgYWdhaW4gYW5kIHNlZSBpbmxpbmUgd2l0aCBbRENdLjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbV0NCjxicj4NCiZndDsgU2VudDogTW9uZGF5LCBKdW5lIDEzLCAy MDExIDY6MTEgUE08YnI+DQomZ3Q7IFRvOiBEYW5pZWwgQ29objxicj4NCiZndDsgQ2M6IG1wbHNA aWV0Zi5vcmc7IHB3ZTNAaWV0Zi5vcmc7IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIDxi cj4NCiZndDsgSGFTaGFyb24pOyBtYS55dXhpYUB6dGUuY29tLmNuPGJyPg0KJmd0OyBTdWJqZWN0 OiBSRTogW21wbHNdIFtQV0UzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAmcXVvdDtNUExTLTxi cj4NCiZndDsgVFBMaW5lYXJQcm90ZWN0aW9uQXBwbGljYWJpbGl0eSB0byBNUy1QVyZxdW90Ozwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRGFuaWVsIGFuZCBhbGwsPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFBsZWFzZSBzZWUgc29tZSBjb21tZW50cyBpbmxpbmUg YmVsb3cuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBSZWdhcmRzLDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Nhc2hhPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENA b3Jja2l0LmNvbV0NCjxicj4NCiZndDsgU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDU6NTUg UE08YnI+DQomZ3Q7IFRvOiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik7 IEFsZXhhbmRlciBWYWluc2h0ZWluOw0KPGJyPg0KJmd0OyBtYS55dXhpYUB6dGUuY29tLmNuPGJy Pg0KJmd0OyBDYzogbXBsc0BpZXRmLm9yZzsgcHdlM0BpZXRmLm9yZzxicj4NCiZndDsgU3ViamVj dDogUkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgJnF1b3Q7TVBMUy08 YnI+DQomZ3Q7IFRQTGluZWFyUHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXJnF1b3Q7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBIaSw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IFRoYW5rcyBhbGwgZm9yIHRoZSBmZWVkYmFjay4gSSBiZWxpZXZlIHdlIGFsbA0KYWdyZWUg dGhhdCBQVyA8YnI+DQomZ3Q7IHByb3RlY3Rpb24gaXMgb25seSByZXF1aXJlZCBpbiB0aGUgZXZl bnQgb2YgUy1QRSBmYWlsdXJlIGF0IGFuIE1TLVBXPGJyPg0KJmd0OyCoQyB0aGlzICZuYnNwO2lz IGNsZWFybHkgc3RhdGVkIGluIHRoZSBkcmFmdC4gTm93LCBib3RoIFNhc2hhIGFuZA0KTnVyaXQg PGJyPg0KJmd0OyBtZW50aW9uIHRoYXQgdGhlIFBXIHJlZHVuZGFuY3kgbWVjaGFuaXNtIGNhbiBt ZWV0IHRoZSBNUExTLVRQIFBXIDxicj4NCiZndDsgcHJvdGVjdGlvbiByZXF1aXJlbWVudHMuPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFtbW1Nhc2hhXV1dIKGtIHNuaXBw ZWQgoa08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRS5nLiwgdGhlIFBX IHJlZHVuZGFuY3kgbWVjaGFuaXNtcyB0YWtlIGNhcmUNCm9mIGR1YWwtaG9tZWQgQ0VzIGluIDxi cj4NCiZndDsgU1MtIGFuZCBNUy1QV3MgqEMgc29tZXRoaW5nIHRoYXQgbGluZXIgcHJvdGVjdGlv biBvZiBQV3MgY2Fubm90IGRvLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyBbRENdIEmhr20gYWZyYWlkIEkgZG9uoa90IGZvbGxvdyB5b3UgaGVyZS4NCldoZXJlIGRvZXMg UFcgcmVkdW5kYW5jeSA8YnI+DQomZ3Q7IHRha2UgY2FyZSBvZiBkdWFsLWhvbWVkIENFPyBBY3R1 YWxseSBQVyByZWR1bmRhbmN5IGRyYWZ0IGV4cGxpY2l0bHkNCjxicj4NCiZndDsgc3RhdGVzOiCh sFRoZSBtZXRob2QgZm9yIGR1YWwtaG9taW5nIG9mIENFMSB0byBQRTEgYW5kIHRvIFBFMyBub2Rl cywNCjxicj4NCiZndDsgYW5kIHRoZSBwcm90b2NvbHMgdXNlZCwgYXJlIG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoaXMgZG9jdW1lbnShsS4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyBbW1tTYXNoYV1dXSBRdW90aW5nIGZyb20gdGhlIGRyYWZ0OjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAxNS4yLiBNdWx0aXBsZSBNdWx0aS1ob21lZCBDRXMg d2l0aCBzaW5nbGUgU1MtUFcNCnJlZHVuZGFuY3kgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jmx0Oy0t LS0tLS0tLS0tLS0tDQpFbXVsYXRlZCBTZXJ2aWNlIC0tLS0tLS0tLS0tLS0tLS0mZ3Q7fCAmbmJz cDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fCZsdDstLS0tLS0tIFBzZXVkbyBXaXJlIC0tLS0tLSZndDt8DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 fA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fCAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fA0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwO3wmbHQ7LS0gUFNOIFR1bm5lbHMt LSZndDt8DQombmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 fCAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fA0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO1YgJm5ic3A7ICZuYnNwO1YgJm5ic3A7ICZuYnNwOyhub3Qgc2hv d24pDQombmJzcDsgViAmbmJzcDsgJm5ic3A7ViAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fCAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Vg0KJm5ic3A7ICZu YnNwO0FDICZuYnNwOyAmbmJzcDsrLS0tLSsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0rICZuYnNwOyAmbmJzcDsgQUMg Jm5ic3A7IFYgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOystLS0tLSsgJm5ic3A7ICZuYnNwO3wNCiZuYnNwOyAm bmJzcDsgfC4uLi58Li4uLi4uLlBXMS4uLi4uLi4ufC4uLi58ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDsgJm5ic3A7Ky0tLS0tKw0KJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8LS0tLS0t LS0tLXwNClBFMXwuLi4uLi4gJm5ic3A7IC4uLi4uLi4uLnwgUEUzfC0tLS0tLS0tLS18ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCBDRTEgfCAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOystLS0tKyAmbmJzcDsgJm5ic3A7ICZuYnNwO1wgLyAmbmJzcDtQVzMgJm5i c3A7ICZuYnNwOystLS0tKw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgQ0Uy IHwgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Ky0tLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7IFggJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsrLS0tLSsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3wgJm5ic3A7DQombmJzcDsgfCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IHwNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDt8Li4uLi4uLyBc Li5QVzQuLi4ufCAmbmJzcDsNCiZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgfC0t LS0tLS0tLS18DQpQRTJ8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCBQRTR8LS0tLS0tLS0tDQp8ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Ky0tLS0tKyAmbmJzcDsgJm5ic3A7fA0KJm5ic3A7ICZuYnNwOyB8Li4u LnwuLi4uLlBXMi4uLi4uLi4uLi58Li4uLnwgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsr LS0tLS0rDQombmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7IEFDICZuYnNwOyAmbmJzcDsrLS0tLSsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0rICZuYnNwOyAmbmJzcDtBQyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RmlndXJlIDE1LTIgTXVsdGlwbGUgTXVsdGktaG9tZWQN CkNFcyB3aXRoIHNpbmdsZSBTUy1QVyByZWR1bmRhbmN5ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO1RoZSBhcHBsaWNhdGlvbiBpbiBGaWd1cmUgMTUtMiBt YWtlcw0KdXNlIG9mIHRoZSBJbmRlcGVuZGVudCBtb2RlIG9mIDwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7b3BlcmF0aW9uLiA8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtDRTEgaXMgZHVhbC1ob21lZCB0byBQRTEgYW5k IFBFMi4NCkNFMiBpcyBkdWFsLWhvbWVkIFBFMyBhbmQgUEU0LiBUaGUgPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDttZXRob2QgZm9yIGR1YWwtaG9t aW5nIGFuZCB0aGUgdXNlZA0KcHJvdG9jb2xzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSA8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO29mIHRoaXMgZG9j dW1lbnQuICZuYnNwO05vdGUgdGhhdA0KdGhlIFBTTiB0dW5uZWxzIGFyZSBub3Qgc2hvd24gaW4g dGhpcyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNw O2ZpZ3VyZSBmb3IgY2xhcml0eS4gSG93ZXZlciwgaXQNCmNhbiBiZSBhc3N1bWVkIHRoYXQgZWFj aCBvZiB0aGUgUFdzIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDsgJm5ic3A7c2hvd24gaXMgZW5jYXBzdWxhdGVkIGluIGEgc2VwYXJhdGUNClBTTiB0dW5uZWwu IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO0Fzc3VtZSB0aGF0IHRo ZSBBQyBmcm9tIENFMSB0byBQRTENCmlzIEFjdGl2ZSwgZnJvbSBDRTEgdG8gUEUyIGlzIDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7U3RhbmRieTsg ZnVydGhlcm1vcmUsIGFzc3VtZSB0aGF0DQp0aGUgQUMgZnJvbSBDRTIgdG8gUEUzIGlzIFN0YW5k YnkgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDth bmQgZnJvbSBDRTIgdG8gUEU0IGlzIEFjdGl2ZS4gVGhlDQptZXRob2Qgb2YgZGVyaXZpbmcgQWN0 aXZlL1N0YW5kYnkgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNw OyAmbmJzcDtzdGF0dXMgb2YgdGhlIEFDIGlzIG91dHNpZGUgdGhlDQpzY29wZSBvZiB0aGlzIGRv Y3VtZW50LiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtQRTEgYWR2 ZXJ0aXNlcyB0aGUgcHJlZmVyZW50aWFsDQpzdGF0dXMgJnF1b3Q7QWN0aXZlJnF1b3Q7IGFuZCBv cGVyYXRpb25hbCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 ICZuYnNwO3N0YXR1cyAmcXVvdDtQc2V1ZG93aXJlIGZvcndhcmRpbmcmcXVvdDsNCmZvciBwc2V1 ZG93aXJlcyBQVzEgYW5kIFBXNCBjb25uZWN0ZWQgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDt0byBQRTMgYW5kIFBFNC4gVGhpcyBzdGF0dXMgcmVm bGVjdHMNCnRoZSBmb3J3YXJkaW5nIHN0YXRlIG9mIHRoZSBBQyA8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO2F0dGFjaGVkIHRvIFBFMS4gUEUyIGFk dmVydGlzZXMNCnByZWZlcmVudGlhbCBzdGF0dXMgJnF1b3Q7U3RhbmRieSZxdW90OyBhbmQgPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtvcGVyYXRp b25hbCBzdGF0dXMgJnF1b3Q7UHNldWRvd2lyZQ0KZm9yd2FyZGluZyZxdW90OyBmb3IgcHNldWRv d2lyZXMgUFcyIGFuZCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i c3A7ICZuYnNwO1BXMyB0byBQRTMgYW5kIFBFNC4gUEUzIGFkdmVydGlzZXMNCnByZWZlcmVudGlh bCBzdGF0dXMgJnF1b3Q7U3RhbmRieSZxdW90OyBhbmQgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtvcGVyYXRpb25hbCBzdGF0dXMgJnF1b3Q7UHNl dWRvd2lyZQ0KZm9yd2FyZGluZyZxdW90OyBmb3IgcHNldWRvd2lyZXMgUFcxIGFuZCA8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO1BXMyB0byBQRTEg YW5kIFBFMi4gUEU0IGFkdmVydGlzZQ0KdGhlIHByZWZlcmVudGlhbCBzdGF0dXMgJnF1b3Q7QWN0 aXZlJnF1b3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsg Jm5ic3A7YW5kIG9wZXJhdGlvbmFsIHN0YXR1cyAmcXVvdDtQc2V1ZG93aXJlDQpmb3J3YXJkaW5n JnF1b3Q7IGZvciBwc2V1ZG93aXJlcyBQVzIgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDthbmQgUFc0IHRvIFBFMiBhbmQgUEUxIHJlc3BlY3RpdmVs eS4NClRodXMgYnkgbWF0Y2hpbmcgdGhlIGxvY2FsIGFuZCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO3JlbW90ZSBwcmVmZXJlbnRpYWwgZm9yd2Fy ZGluZyBzdGF0dXMNCm9mICZxdW90O0FjdGl2ZSZxdW90OyBhbmQgb3BlcmF0aW9uYWwgPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtzdGF0dXMgb2Yg JnF1b3Q7UHNldWRvd2lyZSBmb3J3YXJkaW5nJnF1b3Q7DQpvZiBwc2V1ZG93aXJlcywgdGhlIFBF IG5vZGVzIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5i c3A7ZGV0ZXJtaW5lIHdoaWNoIFBXIHNob3VsZCBiZSBpbg0KdGhlIEFjdGl2ZSBzdGF0ZS4gSW4g dGhpcyBjYXNlIGl0IGlzIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bmJzcDsgJm5ic3A7UFc0IHRoYXQgd2lsbCBiZSBzZWxlY3RlZC4gJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7T24gZmFpbHVyZSBvZiB0aGUgQUMgYmV0d2Vl biBDRTENCmFuZCBQRTEsIHRoZSBmb3J3YXJkaW5nIHN0YXRlIG9mIDwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7dGhlIEFDIG9uIFBFMiBpcyBjaGFu Z2VkIHRvIEFjdGl2ZS4NClBFMiB0aGVuIGFubm91bmNlcyB0aGUgbmV3bHkgPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtjaGFuZ2VkICdwcmVmZXJl bnRpYWwgZm9yd2FyZGluZycNCnN0YXR1cyBiaXQgb2YgJnF1b3Q7YWN0aXZlJnF1b3Q7IHRvIFBF MyBhbmQgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJz cDtQRTQuIFBFMSB3aWxsIGFkdmVydGlzZSBhIFBXIHN0YXR1cw0Kbm90aWZpY2F0aW9uIG1lc3Nh Z2UgaW5kaWNhdGluZyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i c3A7ICZuYnNwO3RoYXQgdGhlIEFDIGJldHdlZW4gQ0UxIGFuZCBQRTENCmlzIG9wZXJhdGlvbmFs bHkgZG93bi4gUEUyIGFuZCBQRTQgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ICZuYnNwOyAmbmJzcDttYXRjaCB0aGUgbG9jYWwgYW5kIHJlbW90ZSBwcmVmZXJlbnRpYWwN CmZvcndhcmRpbmcgc3RhdHVzIG9mIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyAmbmJzcDsgJm5ic3A7JnF1b3Q7QWN0aXZlJnF1b3Q7IGFuZCBvcGVyYXRpb25hbA0Kc3Rh dHVzICZxdW90O1BzZXVkb3dpcmUgZm9yd2FyZGluZyZxdW90OyBhbmQgc2VsZWN0IDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7UFcyIGFzIHRoZSBu ZXcgYWN0aXZlIHBzZXVkb3dpcmUNCnRvIHNlbmQgdHJhZmZpYyB0by4gPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7T24gZmFpbHVyZSBvZiBQRTEgbm9kZSwgUEUyIHdp bGwNCmRldGVjdCBpdCBhbmQgd2lsbCB0cmFuc2l0aW9uIHRoZSA8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO2ZvcndhcmRpbmcgc3RhdGUgb2YgaXRz IEFDIHRvIEFjdGl2ZS4NClRoZSBtZXRob2QgYnkgd2hpY2ggUEUyIDwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ZGV0ZWN0cyB0aGF0IFBFMSBpcyBk b3duIGlzIG91dHNpZGUNCnRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiBQRTIgPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDt0aGVuIGFubm91bmNl cyB0aGUgbmV3bHkgY2hhbmdlZA0KJ3ByZWZlcmVudGlhbCBmb3J3YXJkaW5nJyBzdGF0dXMgPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtiaXQgb2Yg JnF1b3Q7QWN0aXZlJnF1b3Q7IHRvIFBFMw0KYW5kIFBFNC4gUEUyIGFuZCBQRTQgbWF0Y2ggdGhl IGxvY2FsIGFuZCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 ICZuYnNwO3JlbW90ZSBwcmVmZXJlbnRpYWwgZm9yd2FyZGluZyBzdGF0dXMNCm9mICZxdW90O0Fj dGl2ZSZxdW90OyBhbmQgb3BlcmF0aW9uYWwgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtzdGF0dXMgJnF1b3Q7UHNldWRvd2lyZSBmb3J3YXJkaW5n JnF1b3Q7DQphbmQgc2VsZWN0IFBXMiBhcyB0aGUgbmV3IGFjdGl2ZSA8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO3BzZXVkb3dpcmUgdG8gc2VuZCB0 cmFmZmljIHRvLiBOb3RlDQp0aGF0IFBFMyBhbmQgUEU0IG1heSBoYXZlIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ZGV0ZWN0ZWQgdGhhdCB0aGUg UFcgdG8gUEUxIHdlbnQNCmRvd24gdmlhIFQtTERQIEhlbGxvIHRpbWVvdXQgb3IgdmlhIDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7b3RoZXIgbWVh bnMuIEhvd2V2ZXIsIHRoZXkgd2lsbA0Kbm90IGJlIGFibGUgdG8gZm9yd2FyZCB1c2VyIHRyYWZm aWMgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDt1 bnRpbCB0aGV5IHJlY2VpdmVkIHRoZSB1cGRhdGVkDQpzdGF0dXMgYml0IGZyb20gUEUyLiA8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtCZWNhdXNlIGVhY2ggZHVhbC1o b21pbmcgYWxnb3JpdGhtDQpydW5uaW5nIG9uIHRoZSB0d28gbm9kZSBzZXRzLCA8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO2kuZS4sIHtDRTEsIFBF MSwgUEUyfSBhbmQge0NFMiwNClBFMywgUEU0fSwgc2VsZWN0cyB0aGUgYWN0aXZlIEFDIDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7aW5kZXBlbmRl bnRseSwgdGhlcmUgaXMgYSBuZWVkIHRvDQpzaWduYWwgdGhlIGFjdGl2ZSBzdGF0dXMgb2YgdGhl IEFDIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7 c3VjaCB0aGF0IHRoZSBQRSBub2RlcyBjYW4gc2VsZWN0DQphIGNvbW1vbiBhY3RpdmUgUFcgZm9y IGVuZC10by1lbmQgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNw OyAmbmJzcDtmb3J3YXJkaW5nIGJldHdlZW4gQ0UxIGFuZCBDRTIgYXMNCnBlciB0aGUgcHJvY2Vk dXJlcyBpbiB0aGUgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNw OyAmbmJzcDtpbmRlcGVuZGVudCBtb2RlLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZu YnNwOyAmbmJzcDtOb3RlIHRoYXQgYW55IHByaW1hcnkvc2Vjb25kYXJ5DQpwcm9jZWR1cmVzLCBh cyBkZWZpbmVkIGluIHNlY3Rpb25zIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyAmbmJzcDsgJm5ic3A7NS4xLiAmbmJzcDthbmQgNS4yLiAsIGRvIG5vdCBhcHBseQ0KaW4g dGhpcyB1c2UgY2FzZSBhcyB0aGUgQWN0aXZlL1N0YW5kYnkgPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtzdGF0dXMgaXMgZHJpdmVuIGJ5IHRoZSBB QyBmb3J3YXJkaW5nDQpzdGF0ZSBhcyBkZXRlcm1pbmVkIGJ5IHRoZSBBQyA8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO2R1YWwtaG9taW5nIHByb3Rv Y29sIHVzZWQuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEkgYmVsaWV2ZSB5b3Whr3ZlIHRha2VuIHlvdXIg obBvdXQgb2Ygc2NvcGWhsQ0KcmVmZXJlbmNlIGZyb20gdGhpcyB0ZXh0LDxicj4NCiZndDsgYnV0 IElNSE8geW91IG1pc2ludGVycHJldGVkIGl0LiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgV2hhdCBpdCBtZWFucyAob3Igc28gSSByZWFkIGl0KSBpcyB0aGF0IHNwZWNp ZmljDQpkdWFsLWhvbWluZyA8YnI+DQomZ3Q7IHByb3RvY29sIGlzIG91dCBvZiBzY29wZSBhcyBs b25nIGFzIGl0IG1lZXRzIGNlcnRhaW4gYXNzdW1wdGlvbnMuPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IEFzaWRlOiBJdCB3b3VsZCBiZSBnb29kIGlmIHRoZSBhdXRob3Jz IG9mIHRoZQ0KUFcgcmVkdW5kYW5jeSBkcmFmdHMgPGJyPg0KJmd0OyBjb3VsZCBleHBsaWNpdGx5 IHNwZWNpZnkgdGhlc2UgYXNzdW1wdGlvbnMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBb W1tTYXNoYV1dXSChrSBzbmlwcGVkIKGtPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBOb3cg bGV0oa9zIHR1cm4gb3VyIGF0dGVudGlvbiBiYWNrIHRvIHdoZXRoZXINCnRoZSBQVyByZWR1bmRh bmN5IDxicj4NCiZndDsgZHJhYWZ0IGNhbiBiZSB1c2VkIHRvIG1lZXQgTVBMUy1UUCBQVyBwcm90 ZWN0aW9uIHJlcXVpcmVtZW50cy4gSSBjYW48YnI+DQomZ3Q7IGlkZW50aWZ5IHRoZSBmb2xsb3dp bmcgcmVhc29ucyB3aHkgaW4gaXRzIGN1cnJlbnQgZm9ybSBpdCBkb2VzbqGvdDo8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IC0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0l0 IGV4cGxpY2l0bHkNCiihsG91dHNpZGUgdGhlIHNjb3BlobEpIGRvZXMgbm90IGRlZmluZSA8YnI+ DQomZ3Q7IHByb3RlY3Rpb24gdHJpZ2dlcnMgYW5kIGhvdyB0byBoYW5kbGUgY29leGlzdGluZyB0 cmlnZ2VycywgYXMgPGJyPg0KJmd0OyByZXF1ZXN0ZWQgaW4gUkZDIDU2NTQgKE1QTFMtVFAgUmVx dWlyZW1lbnRzKSwgcmVxcyAjNzUsICM3NiBhbmQgIzc5PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IFtbW1Nhc2hhXV1dIFNvIHdoYXQ/IERlZmluaXRpb24gb2YgdHJpZ2dl cnMgaXMNCm9ydGhvZ29uYWwgdG8gaG93IDxicj4NCiZndDsgY29vcmRpbmF0ZWQgcHJvdGVjdGlv biBzd2l0Y2hpbmcgaGFwcGVucy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgW0RDXSBJdCBpcy4gQnV0IHN0aWxsIGl0IG5lZWRzIHRvIGJlIGRlZmluZWQNCmJ5IHRoZSBy ZWNvdmVyeSA8YnI+DQomZ3Q7IGZyYW1ld29yaywgZS5nLiB3aGF0IHNob3VsZCB0aGUgZW5kcG9p bnQgZG8gd2hlbiBvbmUgUFcgaXMgaW4gU0YgYW5kPGJyPg0KJmd0OyB0aGUgb3RoZXIgaXMgaW4g U0QsIG9yIHdoZW4gYm90aCBhcmUgaW4gU0QuIE9wZXJhdG9ycyBleHBlY3Qgd2VsbC08YnI+DQom Z3Q7IGRlZmluZWQgYmVoYXZpb3IgaW4gdGhlc2UgYW5kIG90aGVyIHNjZW5hcmlvcywgYW5kIFBX IHJlZHVuZGFuY3kgPGJyPg0KJmd0OyBkb2VzIG5vdCBkZWZpbmUgdGhlbSAoYmVjYXVzZSBpdCB3 YXMgbm90IGluIHRoZWlyIHNjb3BlKS4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IFtbW1Nhc2hhXV1dIEkgd29uZGVyIGlmIHlvdSBoYXZlIGZvbGxvd2VkIHRoZQ0KZGlz Y3Vzc2lvbiByZWdhcmRpbmcgPGJyPg0KJmd0OyBhYmlsaXR5IHRvIGRlZmluZSBTRCBjb25kaXRp b24gZm9yIExTUHMgYW5kIFBXcyBvbiB0aGUgTVBMUy1UUCBsaXN0Pzxicj4NCiZndDsgSU1PIGl0 IGlzIG5vdCBwb3NzaWJsZSB0byBkZWZpbmUgaXQgaW4gYSBtZWFuaW5nZnVsIHdheS4gSGVuY2Ug SSBkbw0KPGJyPg0KJmd0OyBub3Qgc2VlIGEgcHJvcG9zYWwgdGhhdCBkb2VzIG5vdCBhZGRyZXNz IGEgc2NlbmFyaW8gdGhhdCBkb2VzIG5vdA0KPGJyPg0KJmd0OyBleGlzdCBpbiByZWFsaXR5IGFz IGEgZmxhd2VkIG9uZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i c3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC0gJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0l0IGRvZXMgbm90DQpzdXBwb3J0IHRoZSBhYmlsaXR5IHRv IGRpc3Rpbmd1aXNoIGJldHdlZW4gPGJyPg0KJmd0OyBkaWZmZXJlbnQgdHlwZXMgb2YgdHJpZ2dl cnMgKGkuZS4gb25lIGVuZCBkb2VzbqGvdCBrbm93IHdoeSB0aGUgb3RoZXI8YnI+DQomZ3Q7IGVu ZCB0cmlnZ2VyZWQgc3dpdGNoKSwgYXMgcmVxdWVzdGVkIGluIFJGQyA1NjU0IChNUExTLVRQIDxi cj4NCiZndDsgUmVxdWlyZW1lbnRzKSwgcmVxICM3NzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAtICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJdCBkb2Vz IG5vdA0KZGVmaW5lIHJldmVydGl2ZS9ub25yZXZlcnRpdmUgYmVoYXZpb3IsIGFzIDxicj4NCiZn dDsgcmVxdWVzdGVkIGluIFJGQyA1NjU0IChNUExTLVRQIFJlcXVpcmVtZW50cyksIHJlcSAjNjQ8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgLSAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7SXQgZG9lcyBub3QNCmRlZmluZSBob2xkb2ZmIHN1cHBvcnQsIHdo aWNoIGlzIGVzcGVjaWFsbHkgPGJyPg0KJmd0OyBpbXBvcnRhbnQgdG8gYXZvaWQgcmFjZSBjb25k aXRpb25zIHdpdGggTFNQIHByb3RlY3Rpb24gd2hlbiBpdCBleGlzdHM8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgLSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7SXQgZG9lc26hr3QNCnN1cHBvcnQgMSsxIG1vZGUsIGFzIHJlcXVlc3RlZCBpbiBSRkMgNTY1 NCA8YnI+DQomZ3Q7IChNUExTLVRQIFJlcXVpcmVtZW50cyksIHJlcSAjNjUgPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFtbW1Nhc2hhXV1dIEFsbCB0aGVzZSBjbGFpbXMg YXJlIGNvcnJlY3QgqEMNCmFuZCAmbmJzcDt0aGlzIHNob3VsZCBub3QgYmUgYTxicj4NCiZndDsg c3VycHJpc2UsIGJlY2F1c2UgTVBMUy1UUCByZXF1aXJlbWVudHMgaGF2ZSBiZWVuIGRlZmluZWQg bXVjaCBsYXRlcg0KPGJyPg0KJmd0OyB0aGFuIHRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbS4g PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEJ1dCBJIGRvIG5vdCB0aGlu ayB0aGF0IHRoaXMganVzdGlmaWVzIGNvLWV4aXN0ZW5jZQ0Kb2YgdHdvIGRpZmZlcmVudDxicj4N CiZndDsgbWVjaGFuaXNtcy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg W0RDXSBTbyBob3cgZG8geW91IHByb3Bvc2UgdG8gbWVldCB0aGUgUFcgcHJvdGVjdGlvbg0KcmVx dWlyZW1lbnQ/IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAtICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJdKGvcyBhDQp0d28tcGhhc2UgcHJvdG9jb2ws IHdpdGggdGhlIGNvbnNlcXVlbnQgaW1wYWN0IG9uIHRpbWluZzxicj4NCiZndDsgW1tbU2FzaGFd XV0gQ291bGQgeW91IHBsZWFzZSBlbGFib3JhdGU/IFtEQ10gSW4gZHJhZnQtaWV0Zi1tcGxzLXRw LTxicj4NCiZndDsgbGluZWFyLXByb3RlY3Rpb24sIGVhY2ggZW5kcG9pbnQgd2lsbCBpbW1lZGlh dGVseSBzd2l0Y2ggdHJhZmZpYyB0bw0KPGJyPg0KJmd0OyB0aGUgb3RoZXIgcGF0aCB1cG9uIGlk ZW50aWZ5aW5nIGFuIFNGIGNvbmRpdGlvbiBpbiBhIHBhdGgsIHdpdGhvdXQNCjxicj4NCiZndDsg d2FpdGluZyBmb3IgdGhlIGZhciBlbmQgdG8gYWNrbm93bGVkZ2UgdGhlIHN3aXRjaCAoMS1waGFz ZSkuIEluIFBXDQo8YnI+DQomZ3Q7IHJlZHVuZGFuY3ksIGFuIGVuZHBvaW50IGRldGVjdGluZyBh biBTRiBjb25kaXRpb24gaW4gYSBwYXRoIHdpbGwgbm90PGJyPg0KJmd0OyBzd2l0Y2ggdW50aWwg dGhlIGZhciBlbmQgaGFzIGFja25vd2xlZGdlZCB0aGUgc3dpdGNoICgyLXBoYXNlKS4gPGJyPg0K Jmd0OyBOZWVkbGVzcyB0byBzYXksIHJlY292ZXJ5IGlzIHNsb3dlciBpbiBhIDItcGhhc2UgcHJv dG9jb2wuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFtbW1Nhc2hhXV1d IFRvIHRoZSBiZXN0IG9mIG15IHVuZGVyc3RhbmRpbmcsDQoxLXBoYXNlIHByb3RlY3Rpb24gaXMg PGJyPg0KJmd0OyBvbmx5IHBvc3NpYmxlIGluIDErMSB1bmlkaXJlY3Rpb25hbCBhcmNoaXRlY3R1 cmVzLiBBbmQgeWVzLCBJIGtub3cNCjxicj4NCiZndDsgdGhhdCBNUExTLVRQIHJlcXVpcmVzIGEg Jm5ic3A7bWVjaGFuaXNtIHRvIHN1cHBvcnQgdGhpczsgd2hldGhlciBhbnlib2R5DQo8YnI+DQom Z3Q7IHdvdWxkIHJlYWxseSBkbyB0aGF0IGluIHRoZSBwYWNrZXQtc3dpdGNoaW5nIG5ldHdvcmsg aXMgbm90IGNsZWFyDQp0bzxicj4NCiZndDsgbWUuIEFuZCBJIGFja25vd2xlZGdlIHRoYXQgdGhl IFBXIHJlZHVuZGFuY3kgZHJhZnRzIGRvIG5vdCBzdXBwb3J0DQo8YnI+DQomZ3Q7IDErMSB1bmlk aXJlY3Rpb25hbCBzY2hlbWUuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgLSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SXQgZG9lc26hr3QNCmRlZmluZSByZXRyYW5zbWlz c2lvbiBvZiBwcm90ZWN0aW9uIDxicj4NCiZndDsgY29vcmRpbmF0aW9uIG1lc3NhZ2VzLCBzbyBs b3NzIG9mIGEgc2luZ2xlIFBEVSBjYW4gcmVzdWx0IGluIDxicj4NCiZndDsgc3dpdGNob3ZlciBu b3QgdGFraW5nIHBsYWNlLCB0aHVzIG5vdCBzdXBwb3J0aW5nIHN1Yi01MCBtcyByZWNvdmVyeQ0K PGJyPg0KJmd0OyBpbiB0aGlzIGNhc2U8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgW1tbU2FzaGFdXV0gVGhlIFBXIHJlZHVuZGFuY3kgcHJvdG9jb2wgcnVucyBlaXRoZXIN Cm9uIHRvcCBvZiBMRFAgPGJyPg0KJmd0OyAod2hpY2ggYmVuZWZpdHMgZnJvbSBUQ1AgcmV0cmFu c21pc3Npb25zKSBvciBvbiB0b3Agb2Ygc3RhdGljIFBXIDxicj4NCiZndDsgc3RhdHVzIG1lc3Nh Z2VzICh3aGVyZSByZXRyYW5zbWlzc2lvbiBpcyBkZWZpbmVkKS4gPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFtEQ10gVHJ1ZSCoQyBidXQgc3RhdGljIFBXIHN0YXR1cyBk ZWZpbmVzIHNsb3cNCnJldHJhbnNtaXNzaW9uICihsHdpbGwgPGJyPg0KJmd0OyBiZSB0cmFuc21p dHRlZCB0d2ljZSBhdCBhbiBpbml0aWFsIGludGVydmFsIG9mIG9uZSBzZWNvbmShsSkgd2hpbGUN Cjxicj4NCiZndDsgZHJhZnQtaWV0Zi1tcGxzLXRwLWxpbmVhci1wcm90ZWN0aW9uIHNwZWNpZmll cyBmYXN0IHJldHJhbnNtaXNzaW9uDQo8YnI+DQomZ3Q7IHdoZW4gcmVxdWlyZWQgZm9yIGZhc3Qg cmVjb3ZlcnkgKHNlY3Rpb24gMy4xLjQpLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IElu IHN1bW1hcnksIFBXIHJlZHVuZGFuY3kgd2FzIG5vdCBkZXNpZ25lZCB3aXRoDQpUUCByZXF1aXJl bWVudHMgaW4gPGJyPg0KJmd0OyBtaW5kLCBhbmQgYXMgc3VjaCBkb2VzIG5vdCBtZWV0IHRoZSBU UCByZXF1aXJlbWVudHMuIE9mIGNvdXJzZSA8YnI+DQomZ3Q7IG1vZGlmaWNhdGlvbnMgbWF5IGJl IGludHJvZHVjZWQsIGJ1dCB3aHkgcmVpbnZlbnQgdGhlIHdoZWVsIHdoZW4gPGJyPg0KJmd0OyB0 aGVyZSBpcyBhIHByb3RvY29sIChkcmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24t MDYpIGluIHRoZTxicj4NCiZndDsgc3RhbmRhcmRzIHRyYWNrIHRoYXQgc3VwcG9ydHMgYWxsIHRo ZSBhYm92ZSByZXF1aXJlbWVudHMgYW5kIGNhbiBiZQ0KPGJyPg0KJmd0OyBhcHBsaWVkIHRvIE1T LVBXIHByb3RlY3Rpb24gd2l0aCBtaW5vciBtb2RpZmljYXRpb25zPzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBbW1tTYXNoYV1dXSBBcyBJIHNhaWQsIGJlY2F1c2UgdGhl IGFwcGxpY2FiaWxpdHkNCnNjb3BlIGlzIGJ5IGZhciB0b288YnI+DQomZ3Q7IG5hcnJvdyB0byBq dXN0aWZ5IGEgZGVkaWNhdGVkIHByb3RvY29sLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBbRENdIElmIHdlIHdlcmUgZGlzY3Vzc2luZyBkZXNpZ25pbmcgYSBuZXcgcHJv dG9jb2wsDQpJIG1pZ2h0IGFncmVlIDxicj4NCiZndDsgd2l0aCB5b3UuIEJ1dCBmcm9tIGEgcHJh Y3RpY2FsIHN0YW5kcG9pbnQsIHRoZSBQVyBwcm90ZWN0aW9uIGRyYWZ0DQo8YnI+DQomZ3Q7IGlz IG5vdCBhIGRlZGljYXRlZCBwcm90b2NvbCCoQyBpdKGvcyBhbiBhcHBsaWNhYmlsaXR5IHN0YXRl bWVudA0KdG8gYW4gPGJyPg0KJmd0OyBleGlzdGluZyBwcm90b2NvbC4gQm90aCBmcm9tIHRoZSBp bXBsZW1lbnRhdGlvbiBhbmQgdGhlIG9wZXJhdGlvbmFsDQo8YnI+DQomZ3Q7IHBvaW50IG9mIHZp ZXcgaXQgZGVmaW5lcyBhIG5ldyB1c2UgY2FzZSBmb3IgYW4gZXhpc3RpbmcgcHJvdG9jb2wgYW5k DQpjb25jZXB0LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFJlZ2FyZHMsPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyBEYW5pZWw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i c3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQpPbiBCZWhhbGYgT2YgPGJyPg0KJmd0 OyBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik8YnI+DQomZ3Q7IFNlbnQ6 IE1vbmRheSwgSnVuZSAxMywgMjAxMSA0OjAyIFBNPGJyPg0KJmd0OyBUbzogZXh0IEFsZXhhbmRl ciBWYWluc2h0ZWluOyBtYS55dXhpYUB6dGUuY29tLmNuPGJyPg0KJmd0OyBDYzogbXBsc0BpZXRm Lm9yZzsgcHdlM0BpZXRmLm9yZzxicj4NCiZndDsgU3ViamVjdDogUmU6IFttcGxzXSBbUFdFM10g U2Vla2luZyBmZWVkYmFjayBvbiBJLUQgJnF1b3Q7TVBMUy08YnI+DQomZ3Q7IFRQTGluZWFyUHJv dGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXJnF1b3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyBIaSw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSSB3b3Vs ZCBsaWtlIHRvIHNlY29uZCBTYXNoYS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgRW5kLXRvLWVuZCBQVyBwcm90ZWN0aW9uICh3aXRoIGRpdmVyc2UgcGF0aHMpDQpkb2Vz IG5vdCBzY2FsZSwgYW5kIDxicj4NCiZndDsgcHV0IGhhcmQgcmVzdHJpY3Rpb25zIG9uIHRoZSB1 dGlsaXphdGlvbiBvZiB0aGUgcmVzb3VyY2VzLiAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgTVBMUy1UUCBQV3MgYXJlIGNhcnJpZWQgYWNyb3NzIHRoZSBuZXR3 b3JrIGluc2lkZQ0KTVBMUy1UUCBMU1BzLiA8YnI+DQomZ3Q7IFRoZXJlZm9yZSwgYW4gb2J2aW91 cyB3YXkgdG8gcHJvdmlkZSBwcm90ZWN0aW9uIGZvciBhIFBXIGlzIHRvIDxicj4NCiZndDsgcHJv dGVjdCB0aGUgTFNQIHRoYXQgY2FycmllcyBpdC4gJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IElmIHRoZSBQVyBpcyBhIG11bHRpLXNlZ21lbnQgUFcsIHRoZW4g TFNQIHJlY292ZXJ5DQpjYW4gb25seSBwcm90ZWN0IDxicj4NCiZndDsgdGhlIFBXIGluIGluZGl2 aWR1YWwgc2VnbWVudHMuICZuYnNwO1RoaXMgbWVhbnMgdGhhdCBhIHNpbmdsZSBMU1ANCjxicj4N CiZndDsgcmVjb3ZlcnkgYWN0aW9uIGNhbm5vdCBwcm90ZWN0IGFnYWluc3QgYSBmYWlsdXJlIG9m IGEgUFcgc3dpdGNoaW5nDQo8YnI+DQomZ3Q7IHBvaW50IChhbiBTLVBFKS48L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgV2hlbiBwcm90ZWN0aW5nIGFnYWluc3QgYW4gQUMg b3IgVC9TLVBFIGZhaWx1cmUNCmJ5IGR1YWwgPGJyPg0KJmd0OyBjb25uZWN0aXZpdHksIFBXIHJl ZHVuZGFuY3kgbWVjaGFuaXNtcyBwcm92aWRlIG1lYW5zIGZvciB0aGUgUEVzIHRvDQo8YnI+DQom Z3Q7IGNvb3JkaW5hdGUgb3ZlciB3aGljaCBMU1AgdGhlIHRyYWZmaWMgb2YgdGhlIFBXIGlzIGNh cnJpZWQuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJIGFsc28gZG91 YnQgd2h5IHRoZXJlIGlzIGEgbmVlZCBmb3IgYWRkaXRpb25hbA0KbWVjaGFuaXNtLiA8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQmVzdCByZWdhcmRzLDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBOdXJpdDwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgRnJvbTogcHdlMy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cHdlMy1ib3VuY2VzQGll dGYub3JnXQ0KT24gQmVoYWxmIE9mIDxicj4NCiZndDsgZXh0IEFsZXhhbmRlciBWYWluc2h0ZWlu PGJyPg0KJmd0OyBTZW50OiBNb25kYXksIEp1bmUgMTMsIDIwMTEgMzo0MyBQTTxicj4NCiZndDsg VG86IG1hLnl1eGlhQHp0ZS5jb20uY248YnI+DQomZ3Q7IENjOiBtcGxzQGlldGYub3JnOyBwd2Uz QGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW1BXRTNdIFttcGxzXSBTZWVraW5nIGZl ZWRiYWNrIG9uIEktRCAmcXVvdDtNUExTLVRQIDxicj4NCiZndDsgTGluZWFyUHJvdGVjdGlvbiBB cHBsaWNhYmlsaXR5IHRvIE1TLVBXJnF1b3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBE ZWFyIE1hIGFuZCBhbGwsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEFk ZGluZyB0aGUgUFdFMyBXRyB0byBteSByZXNwb25zZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IFRoZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbSBzdXBwb3J0cyBsaW5lYXIgcHJvdGVjdGlv bg0Kb2YgTVMtUFdzIGFzIDxicj4NCiZndDsgb25lIG9mIG1hbnkgYWRkaXRpb25hbCBhcHBsaWNh dGlvbiB1c2UgY2FzZXM6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEFw cGVuZGl4IEEgb2YgdGhlIFBXIHJlZHVuZGFuY3kgQml0IGRyYWZ0IGRlc2NyaWJlcw0KNSBhcHBs aWNhdGlvbiA8YnI+DQomZ3Q7IHVzZXMgY2FzZXMgaW4gYWRkaXRpb24gdG8gTVMtUFcgd2l0aCBz aW5nbGUtaG9tZWQgQ0VzICh3aGljaCBpcyA8YnI+DQomZ3Q7IGxpc3RlZCB0aGVyZSBhcyB1c2Ug Y2FzZSA1KS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQW5kIGl0IGlz IGVxdWFsbHkgYXBwbGljYWJsZSB0byBJUC9NUExTIGFuZCBNUExTDQotIHdpdGggdGhlIGhlbHAg b2YgJm5ic3A7dGhlIDxicj4NCiZndDsgU3RhdGljIFBXIFN0YXR1cyBNZXNzYWdlcyBkcmFmdCgg aWYsIGZvciB3aGF0ZXZlciByZWFzb24sIHlvdSBkbyBub3Q8YnI+DQomZ3Q7IHdhbnQgJm5ic3A7 dG8sIG9yIGNhbm5vdCwgdXNlIFJGQyA0NDQ3KS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IEhlbmNlIEkgZG91YnQgdGhlIG5lZWQgZm9yIHlldCBhbm90aGVyIFBXIHJlZHVuZGFuY3kNCiZu YnNwO21lY2hhbmlzbSB3aXRoPGJyPg0KJmd0OyBuYXJyb3cgc2NvcGUgb2YgYXBwbGljYWJpbGl0 eS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFJlZ2FyZHMsPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U2FzaGE8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZ10NCk9uIEJlaGFsZiBPZiA8YnI+DQomZ3Q7IG1hLnl1eGlhQHp0 ZS5jb20uY248YnI+DQomZ3Q7IFNlbnQ6IE1vbmRheSwgSnVuZSAxMywgMjAxMSAzOjI1IFBNPGJy Pg0KJmd0OyBUbzogbXBsc0BpZXRmLm9yZzxicj4NCiZndDsgU3ViamVjdDogUmU6IFttcGxzXSBT ZWVraW5nIGZlZWRiYWNrIG9uIEktRCAmcXVvdDtNUExTLVRQIExpbmVhciA8YnI+DQomZ3Q7IFBy b3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyZxdW90OzwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgSGkgYWxsLCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGxpbmVhciBwcm90ZWN0 aW9uIG1lY2hhbmlzbSBmb3IgTFNQIGFuZCBQVyhpbmNsdWRpbmcgTVMtUFcpIDxicj4NCiZndDsg c2hvdWxkIGJlIHRoZSBzYW1lIGFuZCBpdCBpcyB2YWx1YWJsZSB0byBkZXNjcmliZSBpdCBjbGVh cmx5LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQlRXLCB0aGVyZSBpcyBhIHR5cG8sIGl0IGlzICZx dW90O1QtUEUgWiZxdW90OyBpbnN0ZWFkIG9mICZxdW90O1QtUEUNCkImcXVvdDsuIDxicj4NCiZn dDsgPGJyPg0KJmd0OyAmbmJzcDsmcXVvdDsgPGJyPg0KJmd0OyAmbmJzcDsgRmlndXJlIDEgaWxs dXN0cmF0ZXMgc3VjaCBhIHNjZW5hcmlvLCB3aGVyZSB0d28gTVMtUFdzIGFyZQ0KPGJyPg0KJmd0 OyAmbmJzcDsgZXN0YWJsaXNoZWQgYmV0d2VlbiBULVBFIEEgYW5kIFQtUEUgQiwgb3ZlciBTLVBF cyAxLTIgYW5kIDMtNA0KPGJyPg0KJmd0OyAmbmJzcDsgcmVzcGVjdGl2ZWx5LiBFYWNoIFBXIHNl Z21lbnQgaXMgZXN0YWJsaXNoZWQgb3ZlciBhbiBMU1AgKGUuZy4NClBXLSA8YnI+DQomZ3Q7ICZu YnNwOyBzMTIgb3ZlciBMU1AxMikuIDxicj4NCiZndDsgJm5ic3A7JnF1b3Q7IDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsgRnJvbTogRGFuaWVsIENvaG4gPGJyPg0KJmd0OyBTZW50OiBUdWVzZGF5LCBNYXkg MTcsIDIwMTEgNDoxNCBQTTxicj4NCiZndDsgVG86IG1wbHM8YnI+DQomZ3Q7IFN1YmplY3Q6IFNl ZWtpbmcgZmVlZGJhY2sgb24gSS1EICZxdW90O01QTFMtVFAgTGluZWFyIFByb3RlY3Rpb248YnI+ DQomZ3Q7IEFwcGxpY2FiaWxpdHkgdG8gTVMtUFcmcXVvdDs8YnI+DQomZ3Q7IEltcG9ydGFuY2U6 IEhpZ2g8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgTVBMU2Vycyw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgSSB1cGxvYWRlZCAmcXVvdDtNUExTLVRQIExpbmVhciBQcm90ZWN0aW9uIEFwcGxpY2FiaWxp dHkgdG8gTVMtUFcmcXVvdDsNCkktRDxicj4NCiZndDsgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWNvaG4tbXBscy10cC1wdy1wcm90ZWN0aW9uLTAwKTxicj4NCiZndDsgPGJyPg0K Jmd0OyBUaGUgYWJzdHJhY3QgZ29lczo8YnI+DQomZ3Q7IDxicj4NCiZndDsgT25lIG9mIHRoZSBy ZXF1aXJlbWVudHMgb2YgdGhlIE1QTFMgdHJhbnNwb3J0IHByb2ZpbGUgW1JGQyA1NjU0XSBpczxi cj4NCiZndDsgdG8gcHJvdmlkZSBsaW5lYXIgcHJvdGVjdGlvbiBmb3IgdHJhbnNwb3J0IHBhdGhz LCB3aGljaCBpbmNsdWRlIGJvdGg8YnI+DQomZ3Q7IExTUHMgYW5kIFBXcy4gVGhlIGZ1bmN0aW9u YWwgYXJjaGl0ZWN0dXJlIGRlc2NyaWJlZCBpbiBbU3Vydml2RndrXTxicj4NCiZndDsgaXMgYXBw bGljYWJsZSB0byBib3RoIExTUCBhbmQgUFdzLCBob3dldmVyIFtMaW5lYXJQcm90XSBkb2VzIG5v dDxicj4NCiZndDsgZXhwbGljaXRseSBkZXNjcmliZSBtZWNoYW5pc21zIGZvciBQVyBwcm90ZWN0 aW9uIGluIE1QTFMtVFAuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgZG9jdW1lbnQgZXh0ZW5k cyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgbGluZWFyIHByb3RlY3Rpb248YnI+DQomZ3Q7IG1l Y2hhbmlzbSBkZXNjcmliZWQgaW4gW0xpbmVhclByb3RdIHRvIE1QTFMtVFAgc2VnbWVudGVkIFBX cyA8YnI+DQomZ3Q7IChNUy1QV3MpIGFzIGRlZmluZWQgaW4gW1JGQyA2MDczXS48YnI+DQomZ3Q7 IDxicj4NCiZndDsgQ291bGQgeW91IHBsZWFzZSByZXZpZXcgaXQgYW5kIHNlbmQgZmVlZGJhY2sg dG8gdGhlIG1haWxpbmcgbGlzdCBvcjxicj4NCiZndDsgZGlyZWN0bHkgdG8gdGhlIGF1dGhvcj8g PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExvb2tpbmcgZm9yd2FyZCB0byB5b3VyIGZlZWRiYWNrLCA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgRGFuaWVsIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBp ZW50DQpvbmx5IGFuZCBjb250YWlucyA8YnI+DQomZ3Q7IGluZm9ybWF0aW9uIHdoaWNoIGlzIENP TkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvDQo8YnI+DQomZ3Q7IEVD SSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJv ciwgcGxlYXNlPGJyPg0KJmd0OyBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFu ZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kDQo8YnI+DQomZ3Q7IGFsbCBjb3BpZXMgdGhl cmVvZi4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoaXMgZS1tYWls IG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQNCm9ubHkgYW5kIGNvbnRhaW5z IDxicj4NCiZndDsgaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBt YXkgYmUgcHJvcHJpZXRhcnkgdG8NCjxicj4NCiZndDsgRUNJIFRlbGVjb20uIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2U8YnI+DQomZ3Q7IGlu Zm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmln aW5hbCBhbmQNCjxicj4NCiZndDsgYWxsIGNvcGllcyB0aGVyZW9mLiA8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBm b3IgdGhlIHJlY2lwaWVudA0Kb25seSBhbmQgY29udGFpbnMgPGJyPg0KJmd0OyBpbmZvcm1hdGlv biB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0bw0K PGJyPg0KJmd0OyBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21p c3Npb24gaW4gZXJyb3IsIHBsZWFzZTxicj4NCiZndDsgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhv bmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZA0KPGJyPg0KJmd0OyBh bGwgY29waWVzIHRoZXJlb2YuIDwvZm9udD48L3R0Pg0KAalternativePGJyPjxwcmU+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF Jm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJz cDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwm bmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtz ZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7 bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFp bnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0 dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2Ym bmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZu YnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZu YnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNw O2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNw O3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91 Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJz cDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3Im bmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtl eHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhv c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5i c3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7 dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3Bh bSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 002EE0C8482578B5_=-- From alessandro.dalessandro@telecomitalia.it Thu Jun 23 08:23:07 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726769E8058; Thu, 23 Jun 2011 08:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.085 X-Spam-Level: **** X-Spam-Status: No, score=4.085 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5M1G6io9UJg; Thu, 23 Jun 2011 08:23:04 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE2D9E805D; Thu, 23 Jun 2011 08:23:01 -0700 (PDT) Content-Type: multipart/mixed; boundary="_971ddeb3-9606-49b8-9f36-e7f7d65cbbe4_" Received: from grfhub701rm001.griffon.local (10.19.3.8) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 23 Jun 2011 17:22:55 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by grfhub701rm001.griffon.local ([10.19.9.234]) with mapi; Thu, 23 Jun 2011 17:22:54 +0200 From: D'Alessandro Alessandro Gerardo To: Daniel Cohn Date: Thu, 23 Jun 2011 17:22:52 +0200 Thread-Topic: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" Thread-Index: AcwvJHl1sOtCtFDMRBOfIAQ+qt8VRgAAbbvgAAI39/AAoPt2UA== Message-ID: References: <44F4E579A764584EA9BDFD07D0CA081306D5F116@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306D5F116@tlvmail1> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT MIME-Version: 1.0 Cc: "ma.yuxia@zte.com.cn" , "mpls@ietf.org" , "pwe3@ietf.org" Subject: [PWE3] R: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 15:23:07 -0000 --_971ddeb3-9606-49b8-9f36-e7f7d65cbbe4_ Content-Type: multipart/alternative; boundary="_000_A1F769BC58A8B146B2EEA818EAE052A2096ABFEF96GRFMBX702RM00_" --_000_A1F769BC58A8B146B2EEA818EAE052A2096ABFEF96GRFMBX702RM00_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBEYW5pZWwsDQptYW55IHRoYW5rcyBmb3IgYnJpbmdpbmcgdG8gb3VyIGF0dGVudGlvbiB0 aGlzIGlzc3VlLg0KDQpJdCBtYWtlcyBzZW5zZSBmb3IgbWUgaGF2aW5nIHRoZSBzYW1lIGxpbmVh ciBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgYXBwbGllZCBhdCBib3RoIExTUCBhbmQgUFcgbGV2ZWwg KGluIHRoZSBNUExTLVRQIGZyYW1ld29yaykuDQoNCkl0IGlzIG9idmlvdXMgdGhhdCB0aGVyZSBh cmUgY2lyY3Vtc3RhbmNlcyB3aGVyZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbXMgY2FuIGJlIGV4 cGxvaXRlZCBiZWNhdXNlIHRoZXkgY292ZXIgdGhlIHJlcXVpcmVtZW50cyBvZiBjZXJ0YWluIGFy Y2hpdGVjdHVyYWwgYXBwcm9hY2hlcw0KYnV0IEkgZG8gbm90IGJlbGlldmUgaXQgY2FuIGJlIGNs YWltZWQgdGhhdCBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbXMgY292ZXIgdGhlIHNhbWUgcmVxdWly ZW1lbnRzICBjb3ZlcmVkIGJ5IGxpbmVhciBwcm90ZWN0aW9uIG1lY2hhbmlzbS4gVGhlcmVmb3Jl IHRoZXJlIGlzIGEgZ2FwIHRoYXQgbmVlZCB0byBiZSBmaWxsZWQgYW5kIGV4dGVuZGluZyB0aGUg YWxyZWFkeSBkZWZpbmVkIGxpbmVhciBwcm90ZWN0aW9uIGZvciBMU1BzIHNlZW1zIHRoZSBtb3N0 IGFwcHJvcHJpYXRlIHdheSB0byBwcm9jZWVkLg0KDQpBY3R1YWxseSwgSSBkbyBub3Qgc2VlIGFu eSBhcmd1bWVudCBiZWxvdyBjb25mdXRpbmcgeW91ciBoeXBvdGhlc2lzIGFuZCB0aGVyZWZvcmUg SSBzdXBwb3J0IHlvdXIgcHJvcG9zYWwuDQoNCkJlc3QgcmVnYXJkcywNCkFsZXNzYW5kcm8NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KVGVsZWNvbSBJdGFsaWENCkFsZXNzYW5kcm8gRCdBbGVzc2FuZHJvDQpUcmFuc3Bv cnQgSW5ub3ZhdGlvbg0KVmlhIFJlaXNzIFJvbW9saSwgMjc0IC0gMTAxNDggVG9yaW5vDQpwaG9u ZTogICszOSAwMTEgMjI4IDU4ODcNCm1vYmlsZTogKzM5IDMzNSA3NjYgOTYwNw0KZmF4OiArMzkg MDYgNDE4IDYzOSAwNw0KDQpEYTogcHdlMy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cHdlMy1i b3VuY2VzQGlldGYub3JnXSBQZXIgY29udG8gZGkgRGFuaWVsIENvaG4NCkludmlhdG86IGx1bmVk qKwgMjAgZ2l1Z25vIDIwMTEgMTE6NTENCkE6IEFsZXhhbmRlciBWYWluc2h0ZWluOyBtYS55dXhp YUB6dGUuY29tLmNuDQpDYzogbXBsc0BpZXRmLm9yZzsgcHdlM0BpZXRmLm9yZw0KT2dnZXR0bzog UmU6IFtQV0UzXSBbbXBsc10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMtVFAgTGluZWFy IFByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCg0KU2FzaGEsDQoNCkkgdGhpbmsg dGhlIG1haW4gcXVlc3Rpb24gaGVyZSBpcyB3aHkgY2FsbCBQVyBsaW5lYXIgcHJvdGVjdGlvbiBh biBhZC1ob2MgbWVjaGFuaXNtIHdoZW4gaXShr3Mgc2ltcGx5IGFuIGV4dGVuc2lvbiBvZiBMU1Ag bGluZWFyIHByb3RlY3Rpb24uIEZyb20gYW4gaW1wbGVtZW50YXRpb24gcG9pbnQgb2Ygdmlldywg dGhlIGRpZmZlcmVuY2VzIGFyZSBtaW5pbWFsIKhDIHlvdSBjb3VsZCBldmVuIHNheSBzZW1hbnRp Yy4gSSB0aGluayB0aGlzIGlzIHdoYXQgTWEgbWVhbnMgYnkgc2ltcGxpY2l0eSBhbmQgSSB3aG9s bHkgYWdyZWUgd2l0aCBoZXIgqEMgeW91IGhhdmUgYSBzaW5nbGUgbWVjaGFuaXNtIHRvIHByb3Rl Y3QgYWxsIHRyYW5zcG9ydCBwYXRocyCoQyBiZSB0aGVtIExTUCBvciBQVy4NCg0KTXkgdHdvIGNl bnRzLA0KDQpEQw0KDQpGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiBbbWFpbHRvOkFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KU2VudDogTW9uZGF5LCBKdW5lIDIwLCAyMDExIDEx OjUwIEFNDQpUbzogbWEueXV4aWFAenRlLmNvbS5jbg0KQ2M6IERhbmllbCBDb2huOyBtcGxzQGll dGYub3JnOyBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik7IHB3ZTNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJFOiBSRTogW21wbHNdIFtQV0UzXSBTZWVraW5nIGZlZWRiYWNrIG9u IEktRCAiTVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbiBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0K DQpEZWFyIE1hLA0KTG90cyBvZiB0aGFua3MgZm9yIG91ciByZXNwb25zZS4gUGxlYXNlIHNlZSBz b21lIGNvbW1lbnRzL2Fuc3dlcnMgaW5saW5lIGJlbG93Lg0KDQpSZWdhcmRzLA0KICAgICBTYXNo YQ0KDQpGcm9tOiBtYS55dXhpYUB6dGUuY29tLmNuIFttYWlsdG86bWEueXV4aWFAenRlLmNvbS5j bl0NClNlbnQ6IE1vbmRheSwgSnVuZSAyMCwgMjAxMSAxMTozMSBBTQ0KVG86IEFsZXhhbmRlciBW YWluc2h0ZWluDQpDYzogRGFuaWVsIENvaG47IG1wbHNAaWV0Zi5vcmc7IFNwcmVjaGVyLCBOdXJp dCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTsgcHdlM0BpZXRmLm9yZw0KU3ViamVjdDogtPC4tDog UkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMtVFBMaW5lYXJQ cm90ZWN0aW9uQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCg0KDQpIaSBTYXNoYSwNCg0KIkxpbmVh ciBwcm90ZWN0aW9uIiBpcyBkaWZmZXJlbnQgZnJvbSAiTXVsdGktaG9tZWQgQ0UgcmVkdW5kYW5j eSIgYW5kIGhhcyBubyByZWZlcmVuY2Ugd2l0aCBBQy4NCltbW1Nhc2hhXV1dIEFic29sdXRlbHku DQoNCldvcmtpbmcgcGF0aChzKSBhbmQgcHJvdGVjdGlvbiBwYXRoKHMpIGhhdmUgc2FtZSBzb3Vy Y2UgYW5kIHNpbmsgZW5kcG9pbnRzIGluIGxpbmVhciBwcm90ZWN0aW9uIHR5cGUuDQpbW1tTYXNo YV1dXSBPZiBjb3Vyc2UuDQoNCg0KSU1ITywgV2hlbiBTLVBFIGZhaWxzLCBpdCBpcyBtb3JlIHNp bXBsZSB0byB1c2UgIkxpbmVhciBwcm90ZWN0aW9uIiB0byBwcm90ZWN0IGl0Lg0KW1tbU2FzaGFd XV0gV2VsbCwgc2ltcGxpY2l0eSAsIGxpa2UgYmVhdXR5LCBpcyBpbiB0aGUgZXllIG9mIHRoZSBi ZWhvbGRlcjopLg0KQnV0IElNSE8gIGludHJvZHVjaW5nIG11bHRpcGxlIHNpbXBsZSBhZCBob2Mg c29sdXRpb25zIChlYWNoIGZvciBpdHMgc3BlY2lmaWMgY2FzZSkgYW5kIG1haW50YWluaW5nIHRo ZW0gIGV2ZW50dWFsbHkgbWFrZSB5b3VyIGxpZmUgbW9yZSAgY29tcGxpY2F0ZWQgd2hlbiBjb21w YXJlZCB3aXRoIG9uZSBnZW5lcmljIG1lY2hhbmlzbaGtDQoNCkJlc3QgUmVnYXJkcywNCk1hDQoN Cg0KQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t PG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+INC009ogMjAxMS0wNi0x NCAyMDowMjoxMDoNCg0KPiBEYW5pZWwsDQo+IFBsZWFzZSBzZWUgbW9yZSBpbmxpbmUgKGJvbGQg cHVycGxlIGl0YWxpY3MpLiBJoa92ZSBhbHNvIHN0cmlwcGVkIHRoZQ0KPiBwb3J0aW9ucyBvZiB0 aGUgdGV4dCB0aGF0IGFyZSBub3QgcmVsYXRlZCB0byB0aGlzIHJvdW5kIG9mIGNvbW1lbnRzLg0K Pg0KPiBSZWdhcmRzLA0KPiAgICAgIFNhc2hhDQo+DQo+IEZyb206IERhbmllbCBDb2huIFttYWls dG86RGFuaWVsQ0BvcmNraXQuY29tXTxtYWlsdG86W21haWx0bzpEYW5pZWxDQG9yY2tpdC5jb21d Pg0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDE0LCAyMDExIDI6MzQgUE0NCj4gVG86IEFsZXhhbmRl ciBWYWluc2h0ZWluDQo+IENjOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsg cHdlM0BpZXRmLm9yZzxtYWlsdG86cHdlM0BpZXRmLm9yZz47IFNwcmVjaGVyLCBOdXJpdCAoTlNO IC0gSUwvSG9kDQo+IEhhU2hhcm9uKTsgbWEueXV4aWFAenRlLmNvbS5jbjxtYWlsdG86bWEueXV4 aWFAenRlLmNvbS5jbj4NCj4gU3ViamVjdDogUkU6IFttcGxzXSBbUFdFM10gU2Vla2luZyBmZWVk YmFjayBvbiBJLUQgIk1QTFMtDQo+IFRQTGluZWFyUHJvdGVjdGlvbkFwcGxpY2FiaWxpdHkgdG8g TVMtUFciDQo+DQo+IEhpIFNhc2hhLCB0aGFua3MgYWdhaW4gYW5kIHNlZSBpbmxpbmUgd2l0aCBb RENdLg0KPg0KPiBGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiBbbWFpbHRvOkFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tXTxtYWlsdG86W21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbV0+DQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxMywgMjAxMSA2OjExIFBNDQo+ IFRvOiBEYW5pZWwgQ29obg0KPiBDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9y Zz47IHB3ZTNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+OyBTcHJlY2hlciwgTnVyaXQg KE5TTiAtIElML0hvZA0KPiBIYVNoYXJvbik7IG1hLnl1eGlhQHp0ZS5jb20uY248bWFpbHRvOm1h Lnl1eGlhQHp0ZS5jb20uY24+DQo+IFN1YmplY3Q6IFJFOiBbbXBsc10gW1BXRTNdIFNlZWtpbmcg ZmVlZGJhY2sgb24gSS1EICJNUExTLQ0KPiBUUExpbmVhclByb3RlY3Rpb25BcHBsaWNhYmlsaXR5 IHRvIE1TLVBXIg0KPg0KPiBEYW5pZWwgYW5kIGFsbCwNCj4gUGxlYXNlIHNlZSBzb21lIGNvbW1l bnRzIGlubGluZSBiZWxvdy4NCj4NCj4gUmVnYXJkcywNCj4gICAgICBTYXNoYQ0KPg0KPiBGcm9t OiBEYW5pZWwgQ29obiBbbWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbV08bWFpbHRvOlttYWlsdG86 RGFuaWVsQ0BvcmNraXQuY29tXT4NCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDU6NTUg UE0NCj4gVG86IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTsgQWxleGFu ZGVyIFZhaW5zaHRlaW47DQo+IG1hLnl1eGlhQHp0ZS5jb20uY248bWFpbHRvOm1hLnl1eGlhQHp0 ZS5jb20uY24+DQo+IENjOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgcHdl M0BpZXRmLm9yZzxtYWlsdG86cHdlM0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IFttcGxzXSBb UFdFM10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1QTFMtDQo+IFRQTGluZWFyUHJvdGVjdGlv biBBcHBsaWNhYmlsaXR5IHRvIE1TLVBXIg0KPg0KPiBIaSwNCj4NCj4gVGhhbmtzIGFsbCBmb3Ig dGhlIGZlZWRiYWNrLiBJIGJlbGlldmUgd2UgYWxsIGFncmVlIHRoYXQgUFcNCj4gcHJvdGVjdGlv biBpcyBvbmx5IHJlcXVpcmVkIGluIHRoZSBldmVudCBvZiBTLVBFIGZhaWx1cmUgYXQgYW4gTVMt UFcNCj4gqEMgdGhpcyAgaXMgY2xlYXJseSBzdGF0ZWQgaW4gdGhlIGRyYWZ0LiBOb3csIGJvdGgg U2FzaGEgYW5kIE51cml0DQo+IG1lbnRpb24gdGhhdCB0aGUgUFcgcmVkdW5kYW5jeSBtZWNoYW5p c20gY2FuIG1lZXQgdGhlIE1QTFMtVFAgUFcNCj4gcHJvdGVjdGlvbiByZXF1aXJlbWVudHMuDQo+ IFtbW1Nhc2hhXV1dIKGtIHNuaXBwZWQgoa0NCj4gRS5nLiwgdGhlIFBXIHJlZHVuZGFuY3kgbWVj aGFuaXNtcyB0YWtlIGNhcmUgb2YgZHVhbC1ob21lZCBDRXMgaW4NCj4gU1MtIGFuZCBNUy1QV3Mg qEMgc29tZXRoaW5nIHRoYXQgbGluZXIgcHJvdGVjdGlvbiBvZiBQV3MgY2Fubm90IGRvLg0KPiBb RENdIEmhr20gYWZyYWlkIEkgZG9uoa90IGZvbGxvdyB5b3UgaGVyZS4gV2hlcmUgZG9lcyBQVyBy ZWR1bmRhbmN5DQo+IHRha2UgY2FyZSBvZiBkdWFsLWhvbWVkIENFPyBBY3R1YWxseSBQVyByZWR1 bmRhbmN5IGRyYWZ0IGV4cGxpY2l0bHkNCj4gc3RhdGVzOiChsFRoZSBtZXRob2QgZm9yIGR1YWwt aG9taW5nIG9mIENFMSB0byBQRTEgYW5kIHRvIFBFMyBub2RlcywNCj4gYW5kIHRoZSBwcm90b2Nv bHMgdXNlZCwgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnShsS4NCj4gW1tb U2FzaGFdXV0gUXVvdGluZyBmcm9tIHRoZSBkcmFmdDoNCj4gMTUuMi4gTXVsdGlwbGUgTXVsdGkt aG9tZWQgQ0VzIHdpdGggc2luZ2xlIFNTLVBXIHJlZHVuZGFuY3kNCj4NCj4gICAgICAgICAgICAg IHw8LS0tLS0tLS0tLS0tLS0gRW11bGF0ZWQgU2VydmljZSAtLS0tLS0tLS0tLS0tLS0tPnwNCj4g ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCj4gICAgICAgICAgICAgIHwgICAgICAgICAgfDwtLS0tLS0tIFBzZXVkbyBXaXJl IC0tLS0tLT58ICAgICAgICAgIHwNCj4gICAgICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIHwNCj4gICAgICAgICAgICAgIHwgICAgICAg ICAgfCAgICB8PC0tIFBTTiBUdW5uZWxzLS0+fCAgICB8ICAgICAgICAgIHwNCj4gICAgICAgICAg ICAgIHwgICAgICAgICAgViAgICBWICAgIChub3Qgc2hvd24pICAgViAgICBWICAgICAgICAgIHwN Cj4gICAgICAgICAgICAgIFYgICAgQUMgICAgKy0tLS0rICAgICAgICAgICAgICAgICAgKy0tLS0r ICAgICBBQyAgIFYNCj4gICAgICAgICstLS0tLSsgICAgfCAgICAgfC4uLi58Li4uLi4uLlBXMS4u Li4uLi4ufC4uLi58ICAgICB8ICAgICstLS0tLSsNCj4gICAgICAgIHwgICAgIHwtLS0tLS0tLS0t fCBQRTF8Li4uLi4uICAgLi4uLi4uLi4ufCBQRTN8LS0tLS0tLS0tLXwgICAgIHwNCj4gICAgICAg IHwgQ0UxIHwgICAgICAgICAgKy0tLS0rICAgICAgXCAvICBQVzMgICAgKy0tLS0rICAgICAgICAg IHwgQ0UyIHwNCj4gICAgICAgIHwgICAgIHwgICAgICAgICAgKy0tLS0rICAgICAgIFggICAgICAg ICAgKy0tLS0rICAgICAgICAgIHwgICAgIHwNCj4gICAgICAgIHwgICAgIHwgICAgICAgICAgfCAg ICB8Li4uLi4uLyBcLi5QVzQuLi4ufCAgICB8ICAgICAgICAgIHwgICAgIHwNCj4gICAgICAgIHwg ICAgIHwtLS0tLS0tLS0tfCBQRTJ8ICAgICAgICAgICAgICAgICAgfCBQRTR8LS0tLS0tLS0tIHwg ICAgIHwNCj4gICAgICAgICstLS0tLSsgICAgfCAgICAgfC4uLi58Li4uLi5QVzIuLi4uLi4uLi4u fC4uLi58ICAgICB8ICAgICstLS0tLSsNCj4gICAgICAgICAgICAgICAgICAgQUMgICAgKy0tLS0r ICAgICAgICAgICAgICAgICAgKy0tLS0rICAgIEFDDQo+DQo+DQo+ICAgICAgRmlndXJlIDE1LTIg TXVsdGlwbGUgTXVsdGktaG9tZWQgQ0VzIHdpdGggc2luZ2xlIFNTLVBXIHJlZHVuZGFuY3kNCj4N Cj4gICAgVGhlIGFwcGxpY2F0aW9uIGluIEZpZ3VyZSAxNS0yIG1ha2VzIHVzZSBvZiB0aGUgSW5k ZXBlbmRlbnQgbW9kZSBvZg0KPiAgICBvcGVyYXRpb24uDQo+DQo+ICAgIENFMSBpcyBkdWFsLWhv bWVkIHRvIFBFMSBhbmQgUEUyLiBDRTIgaXMgZHVhbC1ob21lZCBQRTMgYW5kIFBFNC4gVGhlDQo+ ICAgIG1ldGhvZCBmb3IgZHVhbC1ob21pbmcgYW5kIHRoZSB1c2VkIHByb3RvY29scyBhcmUgb3V0 c2lkZSB0aGUgc2NvcGUNCj4gICAgb2YgdGhpcyBkb2N1bWVudC4gIE5vdGUgdGhhdCB0aGUgUFNO IHR1bm5lbHMgYXJlIG5vdCBzaG93biBpbiB0aGlzDQo+ICAgIGZpZ3VyZSBmb3IgY2xhcml0eS4g SG93ZXZlciwgaXQgY2FuIGJlIGFzc3VtZWQgdGhhdCBlYWNoIG9mIHRoZSBQV3MNCj4gICAgc2hv d24gaXMgZW5jYXBzdWxhdGVkIGluIGEgc2VwYXJhdGUgUFNOIHR1bm5lbC4NCj4NCj4gICAgQXNz dW1lIHRoYXQgdGhlIEFDIGZyb20gQ0UxIHRvIFBFMSBpcyBBY3RpdmUsIGZyb20gQ0UxIHRvIFBF MiBpcw0KPiAgICBTdGFuZGJ5OyBmdXJ0aGVybW9yZSwgYXNzdW1lIHRoYXQgdGhlIEFDIGZyb20g Q0UyIHRvIFBFMyBpcyBTdGFuZGJ5DQo+ICAgIGFuZCBmcm9tIENFMiB0byBQRTQgaXMgQWN0aXZl LiBUaGUgbWV0aG9kIG9mIGRlcml2aW5nIEFjdGl2ZS9TdGFuZGJ5DQo+ICAgIHN0YXR1cyBvZiB0 aGUgQUMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCj4NCj4gICAgUEUx IGFkdmVydGlzZXMgdGhlIHByZWZlcmVudGlhbCBzdGF0dXMgIkFjdGl2ZSIgYW5kIG9wZXJhdGlv bmFsDQo+ICAgIHN0YXR1cyAiUHNldWRvd2lyZSBmb3J3YXJkaW5nIiBmb3IgcHNldWRvd2lyZXMg UFcxIGFuZCBQVzQgY29ubmVjdGVkDQo+ICAgIHRvIFBFMyBhbmQgUEU0LiBUaGlzIHN0YXR1cyBy ZWZsZWN0cyB0aGUgZm9yd2FyZGluZyBzdGF0ZSBvZiB0aGUgQUMNCj4gICAgYXR0YWNoZWQgdG8g UEUxLiBQRTIgYWR2ZXJ0aXNlcyBwcmVmZXJlbnRpYWwgc3RhdHVzICJTdGFuZGJ5IiBhbmQNCj4g ICAgb3BlcmF0aW9uYWwgc3RhdHVzICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIGZvciBwc2V1ZG93 aXJlcyBQVzIgYW5kDQo+ICAgIFBXMyB0byBQRTMgYW5kIFBFNC4gUEUzIGFkdmVydGlzZXMgcHJl ZmVyZW50aWFsIHN0YXR1cyAiU3RhbmRieSIgYW5kDQo+ICAgIG9wZXJhdGlvbmFsIHN0YXR1cyAi UHNldWRvd2lyZSBmb3J3YXJkaW5nIiBmb3IgcHNldWRvd2lyZXMgUFcxIGFuZA0KPiAgICBQVzMg dG8gUEUxIGFuZCBQRTIuIFBFNCBhZHZlcnRpc2UgdGhlIHByZWZlcmVudGlhbCBzdGF0dXMgIkFj dGl2ZSINCj4gICAgYW5kIG9wZXJhdGlvbmFsIHN0YXR1cyAiUHNldWRvd2lyZSBmb3J3YXJkaW5n IiBmb3IgcHNldWRvd2lyZXMgUFcyDQo+ICAgIGFuZCBQVzQgdG8gUEUyIGFuZCBQRTEgcmVzcGVj dGl2ZWx5LiBUaHVzIGJ5IG1hdGNoaW5nIHRoZSBsb2NhbCBhbmQNCj4gICAgcmVtb3RlIHByZWZl cmVudGlhbCBmb3J3YXJkaW5nIHN0YXR1cyBvZiAiQWN0aXZlIiBhbmQgb3BlcmF0aW9uYWwNCj4g ICAgc3RhdHVzIG9mICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIG9mIHBzZXVkb3dpcmVzLCB0aGUg UEUgbm9kZXMNCj4gICAgZGV0ZXJtaW5lIHdoaWNoIFBXIHNob3VsZCBiZSBpbiB0aGUgQWN0aXZl IHN0YXRlLiBJbiB0aGlzIGNhc2UgaXQgaXMNCj4gICAgUFc0IHRoYXQgd2lsbCBiZSBzZWxlY3Rl ZC4NCj4NCj4gICAgT24gZmFpbHVyZSBvZiB0aGUgQUMgYmV0d2VlbiBDRTEgYW5kIFBFMSwgdGhl IGZvcndhcmRpbmcgc3RhdGUgb2YNCj4gICAgdGhlIEFDIG9uIFBFMiBpcyBjaGFuZ2VkIHRvIEFj dGl2ZS4gUEUyIHRoZW4gYW5ub3VuY2VzIHRoZSBuZXdseQ0KPiAgICBjaGFuZ2VkICdwcmVmZXJl bnRpYWwgZm9yd2FyZGluZycgc3RhdHVzIGJpdCBvZiAiYWN0aXZlIiB0byBQRTMgYW5kDQo+ICAg IFBFNC4gUEUxIHdpbGwgYWR2ZXJ0aXNlIGEgUFcgc3RhdHVzIG5vdGlmaWNhdGlvbiBtZXNzYWdl IGluZGljYXRpbmcNCj4gICAgdGhhdCB0aGUgQUMgYmV0d2VlbiBDRTEgYW5kIFBFMSBpcyBvcGVy YXRpb25hbGx5IGRvd24uIFBFMiBhbmQgUEU0DQo+ICAgIG1hdGNoIHRoZSBsb2NhbCBhbmQgcmVt b3RlIHByZWZlcmVudGlhbCBmb3J3YXJkaW5nIHN0YXR1cyBvZg0KPiAgICAiQWN0aXZlIiBhbmQg b3BlcmF0aW9uYWwgc3RhdHVzICJQc2V1ZG93aXJlIGZvcndhcmRpbmciIGFuZCBzZWxlY3QNCj4g ICAgUFcyIGFzIHRoZSBuZXcgYWN0aXZlIHBzZXVkb3dpcmUgdG8gc2VuZCB0cmFmZmljIHRvLg0K Pg0KPiAgICBPbiBmYWlsdXJlIG9mIFBFMSBub2RlLCBQRTIgd2lsbCBkZXRlY3QgaXQgYW5kIHdp bGwgdHJhbnNpdGlvbiB0aGUNCj4gICAgZm9yd2FyZGluZyBzdGF0ZSBvZiBpdHMgQUMgdG8gQWN0 aXZlLiBUaGUgbWV0aG9kIGJ5IHdoaWNoIFBFMg0KPiAgICBkZXRlY3RzIHRoYXQgUEUxIGlzIGRv d24gaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gUEUyDQo+ICAgIHRoZW4g YW5ub3VuY2VzIHRoZSBuZXdseSBjaGFuZ2VkICdwcmVmZXJlbnRpYWwgZm9yd2FyZGluZycgc3Rh dHVzDQo+ICAgIGJpdCBvZiAiQWN0aXZlIiB0byBQRTMgYW5kIFBFNC4gUEUyIGFuZCBQRTQgbWF0 Y2ggdGhlIGxvY2FsIGFuZA0KPiAgICByZW1vdGUgcHJlZmVyZW50aWFsIGZvcndhcmRpbmcgc3Rh dHVzIG9mICJBY3RpdmUiIGFuZCBvcGVyYXRpb25hbA0KPiAgICBzdGF0dXMgIlBzZXVkb3dpcmUg Zm9yd2FyZGluZyIgYW5kIHNlbGVjdCBQVzIgYXMgdGhlIG5ldyBhY3RpdmUNCj4gICAgcHNldWRv d2lyZSB0byBzZW5kIHRyYWZmaWMgdG8uIE5vdGUgdGhhdCBQRTMgYW5kIFBFNCBtYXkgaGF2ZQ0K PiAgICBkZXRlY3RlZCB0aGF0IHRoZSBQVyB0byBQRTEgd2VudCBkb3duIHZpYSBULUxEUCBIZWxs byB0aW1lb3V0IG9yIHZpYQ0KPiAgICBvdGhlciBtZWFucy4gSG93ZXZlciwgdGhleSB3aWxsIG5v dCBiZSBhYmxlIHRvIGZvcndhcmQgdXNlciB0cmFmZmljDQo+ICAgIHVudGlsIHRoZXkgcmVjZWl2 ZWQgdGhlIHVwZGF0ZWQgc3RhdHVzIGJpdCBmcm9tIFBFMi4NCj4NCj4gICAgQmVjYXVzZSBlYWNo IGR1YWwtaG9taW5nIGFsZ29yaXRobSBydW5uaW5nIG9uIHRoZSB0d28gbm9kZSBzZXRzLA0KPiAg ICBpLmUuLCB7Q0UxLCBQRTEsIFBFMn0gYW5kIHtDRTIsIFBFMywgUEU0fSwgc2VsZWN0cyB0aGUg YWN0aXZlIEFDDQo+ICAgIGluZGVwZW5kZW50bHksIHRoZXJlIGlzIGEgbmVlZCB0byBzaWduYWwg dGhlIGFjdGl2ZSBzdGF0dXMgb2YgdGhlIEFDDQo+ICAgIHN1Y2ggdGhhdCB0aGUgUEUgbm9kZXMg Y2FuIHNlbGVjdCBhIGNvbW1vbiBhY3RpdmUgUFcgZm9yIGVuZC10by1lbmQNCj4gICAgZm9yd2Fy ZGluZyBiZXR3ZWVuIENFMSBhbmQgQ0UyIGFzIHBlciB0aGUgcHJvY2VkdXJlcyBpbiB0aGUNCj4g ICAgaW5kZXBlbmRlbnQgbW9kZS4NCj4NCj4gICAgTm90ZSB0aGF0IGFueSBwcmltYXJ5L3NlY29u ZGFyeSBwcm9jZWR1cmVzLCBhcyBkZWZpbmVkIGluIHNlY3Rpb25zDQo+ICAgIDUuMS4gIGFuZCA1 LjIuICwgZG8gbm90IGFwcGx5IGluIHRoaXMgdXNlIGNhc2UgYXMgdGhlIEFjdGl2ZS9TdGFuZGJ5 DQo+ICAgIHN0YXR1cyBpcyBkcml2ZW4gYnkgdGhlIEFDIGZvcndhcmRpbmcgc3RhdGUgYXMgZGV0 ZXJtaW5lZCBieSB0aGUgQUMNCj4gICAgZHVhbC1ob21pbmcgcHJvdG9jb2wgdXNlZC4NCj4NCj4N Cj4gSSBiZWxpZXZlIHlvdaGvdmUgdGFrZW4geW91ciChsG91dCBvZiBzY29wZaGxIHJlZmVyZW5j ZSBmcm9tIHRoaXMgdGV4dCwNCj4gYnV0IElNSE8geW91IG1pc2ludGVycHJldGVkIGl0Lg0KPiBX aGF0IGl0IG1lYW5zIChvciBzbyBJIHJlYWQgaXQpIGlzIHRoYXQgc3BlY2lmaWMgZHVhbC1ob21p bmcNCj4gcHJvdG9jb2wgaXMgb3V0IG9mIHNjb3BlIGFzIGxvbmcgYXMgaXQgbWVldHMgY2VydGFp biBhc3N1bXB0aW9ucy4NCj4gQXNpZGU6IEl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIGF1dGhvcnMg b2YgdGhlIFBXIHJlZHVuZGFuY3kgZHJhZnRzDQo+IGNvdWxkIGV4cGxpY2l0bHkgc3BlY2lmeSB0 aGVzZSBhc3N1bXB0aW9ucy4NCj4NCj4gW1tbU2FzaGFdXV0goa0gc25pcHBlZCChrQ0KPg0KPiBO b3cgbGV0oa9zIHR1cm4gb3VyIGF0dGVudGlvbiBiYWNrIHRvIHdoZXRoZXIgdGhlIFBXIHJlZHVu ZGFuY3kNCj4gZHJhYWZ0IGNhbiBiZSB1c2VkIHRvIG1lZXQgTVBMUy1UUCBQVyBwcm90ZWN0aW9u IHJlcXVpcmVtZW50cy4gSSBjYW4NCj4gaWRlbnRpZnkgdGhlIGZvbGxvd2luZyByZWFzb25zIHdo eSBpbiBpdHMgY3VycmVudCBmb3JtIGl0IGRvZXNuoa90Og0KPg0KPiAtICAgICAgICAgIEl0IGV4 cGxpY2l0bHkgKKGwb3V0c2lkZSB0aGUgc2NvcGWhsSkgZG9lcyBub3QgZGVmaW5lDQo+IHByb3Rl Y3Rpb24gdHJpZ2dlcnMgYW5kIGhvdyB0byBoYW5kbGUgY29leGlzdGluZyB0cmlnZ2VycywgYXMN Cj4gcmVxdWVzdGVkIGluIFJGQyA1NjU0IChNUExTLVRQIFJlcXVpcmVtZW50cyksIHJlcXMgIzc1 LCAjNzYgYW5kICM3OQ0KPiBbW1tTYXNoYV1dXSBTbyB3aGF0PyBEZWZpbml0aW9uIG9mIHRyaWdn ZXJzIGlzIG9ydGhvZ29uYWwgdG8gaG93DQo+IGNvb3JkaW5hdGVkIHByb3RlY3Rpb24gc3dpdGNo aW5nIGhhcHBlbnMuDQo+IFtEQ10gSXQgaXMuIEJ1dCBzdGlsbCBpdCBuZWVkcyB0byBiZSBkZWZp bmVkIGJ5IHRoZSByZWNvdmVyeQ0KPiBmcmFtZXdvcmssIGUuZy4gd2hhdCBzaG91bGQgdGhlIGVu ZHBvaW50IGRvIHdoZW4gb25lIFBXIGlzIGluIFNGIGFuZA0KPiB0aGUgb3RoZXIgaXMgaW4gU0Qs IG9yIHdoZW4gYm90aCBhcmUgaW4gU0QuIE9wZXJhdG9ycyBleHBlY3Qgd2VsbC0NCj4gZGVmaW5l ZCBiZWhhdmlvciBpbiB0aGVzZSBhbmQgb3RoZXIgc2NlbmFyaW9zLCBhbmQgUFcgcmVkdW5kYW5j eQ0KPiBkb2VzIG5vdCBkZWZpbmUgdGhlbSAoYmVjYXVzZSBpdCB3YXMgbm90IGluIHRoZWlyIHNj b3BlKS4NCj4gW1tbU2FzaGFdXV0gSSB3b25kZXIgaWYgeW91IGhhdmUgZm9sbG93ZWQgdGhlIGRp c2N1c3Npb24gcmVnYXJkaW5nDQo+IGFiaWxpdHkgdG8gZGVmaW5lIFNEIGNvbmRpdGlvbiBmb3Ig TFNQcyBhbmQgUFdzIG9uIHRoZSBNUExTLVRQIGxpc3Q/DQo+IElNTyBpdCBpcyBub3QgcG9zc2li bGUgdG8gZGVmaW5lIGl0IGluIGEgbWVhbmluZ2Z1bCB3YXkuIEhlbmNlIEkgZG8NCj4gbm90IHNl ZSBhIHByb3Bvc2FsIHRoYXQgZG9lcyBub3QgYWRkcmVzcyBhIHNjZW5hcmlvIHRoYXQgZG9lcyBu b3QNCj4gZXhpc3QgaW4gcmVhbGl0eSBhcyBhIGZsYXdlZCBvbmUuDQo+DQo+IC0gICAgICAgICAg SXQgZG9lcyBub3Qgc3VwcG9ydCB0aGUgYWJpbGl0eSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuDQo+ IGRpZmZlcmVudCB0eXBlcyBvZiB0cmlnZ2VycyAoaS5lLiBvbmUgZW5kIGRvZXNuoa90IGtub3cg d2h5IHRoZSBvdGhlcg0KPiBlbmQgdHJpZ2dlcmVkIHN3aXRjaCksIGFzIHJlcXVlc3RlZCBpbiBS RkMgNTY1NCAoTVBMUy1UUA0KPiBSZXF1aXJlbWVudHMpLCByZXEgIzc3DQo+IC0gICAgICAgICAg SXQgZG9lcyBub3QgZGVmaW5lIHJldmVydGl2ZS9ub25yZXZlcnRpdmUgYmVoYXZpb3IsIGFzDQo+ IHJlcXVlc3RlZCBpbiBSRkMgNTY1NCAoTVBMUy1UUCBSZXF1aXJlbWVudHMpLCByZXEgIzY0DQo+ IC0gICAgICAgICAgSXQgZG9lcyBub3QgZGVmaW5lIGhvbGRvZmYgc3VwcG9ydCwgd2hpY2ggaXMg ZXNwZWNpYWxseQ0KPiBpbXBvcnRhbnQgdG8gYXZvaWQgcmFjZSBjb25kaXRpb25zIHdpdGggTFNQ IHByb3RlY3Rpb24gd2hlbiBpdCBleGlzdHMNCj4gLSAgICAgICAgICBJdCBkb2VzbqGvdCBzdXBw b3J0IDErMSBtb2RlLCBhcyByZXF1ZXN0ZWQgaW4gUkZDIDU2NTQNCj4gKE1QTFMtVFAgUmVxdWly ZW1lbnRzKSwgcmVxICM2NQ0KPiBbW1tTYXNoYV1dXSBBbGwgdGhlc2UgY2xhaW1zIGFyZSBjb3Jy ZWN0IKhDIGFuZCAgdGhpcyBzaG91bGQgbm90IGJlIGENCj4gc3VycHJpc2UsIGJlY2F1c2UgTVBM Uy1UUCByZXF1aXJlbWVudHMgaGF2ZSBiZWVuIGRlZmluZWQgbXVjaCBsYXRlcg0KPiB0aGFuIHRo ZSBQVyByZWR1bmRhbmN5IG1lY2hhbmlzbS4NCj4gQnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhp cyBqdXN0aWZpZXMgY28tZXhpc3RlbmNlIG9mIHR3byBkaWZmZXJlbnQNCj4gbWVjaGFuaXNtcy4N Cj4gW0RDXSBTbyBob3cgZG8geW91IHByb3Bvc2UgdG8gbWVldCB0aGUgUFcgcHJvdGVjdGlvbiBy ZXF1aXJlbWVudD8NCj4gLSAgICAgICAgICBJdKGvcyBhIHR3by1waGFzZSBwcm90b2NvbCwgd2l0 aCB0aGUgY29uc2VxdWVudCBpbXBhY3Qgb24gdGltaW5nDQo+IFtbW1Nhc2hhXV1dIENvdWxkIHlv dSBwbGVhc2UgZWxhYm9yYXRlPyBbRENdIEluIGRyYWZ0LWlldGYtbXBscy10cC0NCj4gbGluZWFy LXByb3RlY3Rpb24sIGVhY2ggZW5kcG9pbnQgd2lsbCBpbW1lZGlhdGVseSBzd2l0Y2ggdHJhZmZp YyB0bw0KPiB0aGUgb3RoZXIgcGF0aCB1cG9uIGlkZW50aWZ5aW5nIGFuIFNGIGNvbmRpdGlvbiBp biBhIHBhdGgsIHdpdGhvdXQNCj4gd2FpdGluZyBmb3IgdGhlIGZhciBlbmQgdG8gYWNrbm93bGVk Z2UgdGhlIHN3aXRjaCAoMS1waGFzZSkuIEluIFBXDQo+IHJlZHVuZGFuY3ksIGFuIGVuZHBvaW50 IGRldGVjdGluZyBhbiBTRiBjb25kaXRpb24gaW4gYSBwYXRoIHdpbGwgbm90DQo+IHN3aXRjaCB1 bnRpbCB0aGUgZmFyIGVuZCBoYXMgYWNrbm93bGVkZ2VkIHRoZSBzd2l0Y2ggKDItcGhhc2UpLg0K PiBOZWVkbGVzcyB0byBzYXksIHJlY292ZXJ5IGlzIHNsb3dlciBpbiBhIDItcGhhc2UgcHJvdG9j b2wuDQo+IFtbW1Nhc2hhXV1dIFRvIHRoZSBiZXN0IG9mIG15IHVuZGVyc3RhbmRpbmcsIDEtcGhh c2UgcHJvdGVjdGlvbiBpcw0KPiBvbmx5IHBvc3NpYmxlIGluIDErMSB1bmlkaXJlY3Rpb25hbCBh cmNoaXRlY3R1cmVzLiBBbmQgeWVzLCBJIGtub3cNCj4gdGhhdCBNUExTLVRQIHJlcXVpcmVzIGEg IG1lY2hhbmlzbSB0byBzdXBwb3J0IHRoaXM7IHdoZXRoZXIgYW55Ym9keQ0KPiB3b3VsZCByZWFs bHkgZG8gdGhhdCBpbiB0aGUgcGFja2V0LXN3aXRjaGluZyBuZXR3b3JrIGlzIG5vdCBjbGVhciB0 bw0KPiBtZS4gQW5kIEkgYWNrbm93bGVkZ2UgdGhhdCB0aGUgUFcgcmVkdW5kYW5jeSBkcmFmdHMg ZG8gbm90IHN1cHBvcnQNCj4gMSsxIHVuaWRpcmVjdGlvbmFsIHNjaGVtZS4NCj4NCj4gLSAgICAg ICAgICBJdCBkb2VzbqGvdCBkZWZpbmUgcmV0cmFuc21pc3Npb24gb2YgcHJvdGVjdGlvbg0KPiBj b29yZGluYXRpb24gbWVzc2FnZXMsIHNvIGxvc3Mgb2YgYSBzaW5nbGUgUERVIGNhbiByZXN1bHQg aW4NCj4gc3dpdGNob3ZlciBub3QgdGFraW5nIHBsYWNlLCB0aHVzIG5vdCBzdXBwb3J0aW5nIHN1 Yi01MCBtcyByZWNvdmVyeQ0KPiBpbiB0aGlzIGNhc2UNCj4gW1tbU2FzaGFdXV0gVGhlIFBXIHJl ZHVuZGFuY3kgcHJvdG9jb2wgcnVucyBlaXRoZXIgb24gdG9wIG9mIExEUA0KPiAod2hpY2ggYmVu ZWZpdHMgZnJvbSBUQ1AgcmV0cmFuc21pc3Npb25zKSBvciBvbiB0b3Agb2Ygc3RhdGljIFBXDQo+ IHN0YXR1cyBtZXNzYWdlcyAod2hlcmUgcmV0cmFuc21pc3Npb24gaXMgZGVmaW5lZCkuDQo+IFtE Q10gVHJ1ZSCoQyBidXQgc3RhdGljIFBXIHN0YXR1cyBkZWZpbmVzIHNsb3cgcmV0cmFuc21pc3Np b24gKKGwd2lsbA0KPiBiZSB0cmFuc21pdHRlZCB0d2ljZSBhdCBhbiBpbml0aWFsIGludGVydmFs IG9mIG9uZSBzZWNvbmShsSkgd2hpbGUNCj4gZHJhZnQtaWV0Zi1tcGxzLXRwLWxpbmVhci1wcm90 ZWN0aW9uIHNwZWNpZmllcyBmYXN0IHJldHJhbnNtaXNzaW9uDQo+IHdoZW4gcmVxdWlyZWQgZm9y IGZhc3QgcmVjb3ZlcnkgKHNlY3Rpb24gMy4xLjQpLg0KPg0KPiBJbiBzdW1tYXJ5LCBQVyByZWR1 bmRhbmN5IHdhcyBub3QgZGVzaWduZWQgd2l0aCBUUCByZXF1aXJlbWVudHMgaW4NCj4gbWluZCwg YW5kIGFzIHN1Y2ggZG9lcyBub3QgbWVldCB0aGUgVFAgcmVxdWlyZW1lbnRzLiBPZiBjb3Vyc2UN Cj4gbW9kaWZpY2F0aW9ucyBtYXkgYmUgaW50cm9kdWNlZCwgYnV0IHdoeSByZWludmVudCB0aGUg d2hlZWwgd2hlbg0KPiB0aGVyZSBpcyBhIHByb3RvY29sIChkcmFmdC1pZXRmLW1wbHMtdHAtbGlu ZWFyLXByb3RlY3Rpb24tMDYpIGluIHRoZQ0KPiBzdGFuZGFyZHMgdHJhY2sgdGhhdCBzdXBwb3J0 cyBhbGwgdGhlIGFib3ZlIHJlcXVpcmVtZW50cyBhbmQgY2FuIGJlDQo+IGFwcGxpZWQgdG8gTVMt UFcgcHJvdGVjdGlvbiB3aXRoIG1pbm9yIG1vZGlmaWNhdGlvbnM/DQo+IFtbW1Nhc2hhXV1dIEFz IEkgc2FpZCwgYmVjYXVzZSB0aGUgYXBwbGljYWJpbGl0eSBzY29wZSBpcyBieSBmYXIgdG9vDQo+ IG5hcnJvdyB0byBqdXN0aWZ5IGEgZGVkaWNhdGVkIHByb3RvY29sLg0KPiBbRENdIElmIHdlIHdl cmUgZGlzY3Vzc2luZyBkZXNpZ25pbmcgYSBuZXcgcHJvdG9jb2wsIEkgbWlnaHQgYWdyZWUNCj4g d2l0aCB5b3UuIEJ1dCBmcm9tIGEgcHJhY3RpY2FsIHN0YW5kcG9pbnQsIHRoZSBQVyBwcm90ZWN0 aW9uIGRyYWZ0DQo+IGlzIG5vdCBhIGRlZGljYXRlZCBwcm90b2NvbCCoQyBpdKGvcyBhbiBhcHBs aWNhYmlsaXR5IHN0YXRlbWVudCB0byBhbg0KPiBleGlzdGluZyBwcm90b2NvbC4gQm90aCBmcm9t IHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgdGhlIG9wZXJhdGlvbmFsDQo+IHBvaW50IG9mIHZpZXcg aXQgZGVmaW5lcyBhIG5ldyB1c2UgY2FzZSBmb3IgYW4gZXhpc3RpbmcgcHJvdG9jb2wgYW5kIGNv bmNlcHQuDQo+DQo+DQo+IFJlZ2FyZHMsDQo+DQo+IERhbmllbA0KPg0KPg0KPiBGcm9tOiBtcGxz LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9y Z10+IE9uIEJlaGFsZiBPZg0KPiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJv bikNCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDExIDQ6MDIgUE0NCj4gVG86IGV4dCBBbGV4 YW5kZXIgVmFpbnNodGVpbjsgbWEueXV4aWFAenRlLmNvbS5jbjxtYWlsdG86bWEueXV4aWFAenRl LmNvbS5jbj4NCj4gQ2M6IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBwd2Uz QGlldGYub3JnPG1haWx0bzpwd2UzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW21wbHNdIFtQ V0UzXSBTZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy0NCj4gVFBMaW5lYXJQcm90ZWN0aW9u IEFwcGxpY2FiaWxpdHkgdG8gTVMtUFciDQo+DQo+IEhpLA0KPiBJIHdvdWxkIGxpa2UgdG8gc2Vj b25kIFNhc2hhLg0KPiBFbmQtdG8tZW5kIFBXIHByb3RlY3Rpb24gKHdpdGggZGl2ZXJzZSBwYXRo cykgZG9lcyBub3Qgc2NhbGUsIGFuZA0KPiBwdXQgaGFyZCByZXN0cmljdGlvbnMgb24gdGhlIHV0 aWxpemF0aW9uIG9mIHRoZSByZXNvdXJjZXMuDQo+IE1QTFMtVFAgUFdzIGFyZSBjYXJyaWVkIGFj cm9zcyB0aGUgbmV0d29yayBpbnNpZGUgTVBMUy1UUCBMU1BzLg0KPiBUaGVyZWZvcmUsIGFuIG9i dmlvdXMgd2F5IHRvIHByb3ZpZGUgcHJvdGVjdGlvbiBmb3IgYSBQVyBpcyB0bw0KPiBwcm90ZWN0 IHRoZSBMU1AgdGhhdCBjYXJyaWVzIGl0Lg0KPiBJZiB0aGUgUFcgaXMgYSBtdWx0aS1zZWdtZW50 IFBXLCB0aGVuIExTUCByZWNvdmVyeSBjYW4gb25seSBwcm90ZWN0DQo+IHRoZSBQVyBpbiBpbmRp dmlkdWFsIHNlZ21lbnRzLiAgVGhpcyBtZWFucyB0aGF0IGEgc2luZ2xlIExTUA0KPiByZWNvdmVy eSBhY3Rpb24gY2Fubm90IHByb3RlY3QgYWdhaW5zdCBhIGZhaWx1cmUgb2YgYSBQVyBzd2l0Y2hp bmcNCj4gcG9pbnQgKGFuIFMtUEUpLg0KPiBXaGVuIHByb3RlY3RpbmcgYWdhaW5zdCBhbiBBQyBv ciBUL1MtUEUgZmFpbHVyZSBieSBkdWFsDQo+IGNvbm5lY3Rpdml0eSwgUFcgcmVkdW5kYW5jeSBt ZWNoYW5pc21zIHByb3ZpZGUgbWVhbnMgZm9yIHRoZSBQRXMgdG8NCj4gY29vcmRpbmF0ZSBvdmVy IHdoaWNoIExTUCB0aGUgdHJhZmZpYyBvZiB0aGUgUFcgaXMgY2FycmllZC4NCj4gSSBhbHNvIGRv dWJ0IHdoeSB0aGVyZSBpcyBhIG5lZWQgZm9yIGFkZGl0aW9uYWwgbWVjaGFuaXNtLg0KPiBCZXN0 IHJlZ2FyZHMsDQo+IE51cml0DQo+DQo+IEZyb206IHB3ZTMtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86cHdlMy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZ108 bWFpbHRvOlttYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxmIE9mDQo+IGV4 dCBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPiBTZW50OiBNb25kYXksIEp1bmUgMTMsIDIwMTEgMzo0 MyBQTQ0KPiBUbzogbWEueXV4aWFAenRlLmNvbS5jbjxtYWlsdG86bWEueXV4aWFAenRlLmNvbS5j bj4NCj4gQ2M6IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBwd2UzQGlldGYu b3JnPG1haWx0bzpwd2UzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW1BXRTNdIFttcGxzXSBT ZWVraW5nIGZlZWRiYWNrIG9uIEktRCAiTVBMUy1UUA0KPiBMaW5lYXJQcm90ZWN0aW9uIEFwcGxp Y2FiaWxpdHkgdG8gTVMtUFciDQo+DQo+IERlYXIgTWEgYW5kIGFsbCwNCj4gQWRkaW5nIHRoZSBQ V0UzIFdHIHRvIG15IHJlc3BvbnNlLg0KPg0KPiBUaGUgUFcgcmVkdW5kYW5jeSBtZWNoYW5pc20g c3VwcG9ydHMgbGluZWFyIHByb3RlY3Rpb24gb2YgTVMtUFdzIGFzDQo+IG9uZSBvZiBtYW55IGFk ZGl0aW9uYWwgYXBwbGljYXRpb24gdXNlIGNhc2VzOg0KPiBBcHBlbmRpeCBBIG9mIHRoZSBQVyBy ZWR1bmRhbmN5IEJpdCBkcmFmdCBkZXNjcmliZXMgNSBhcHBsaWNhdGlvbg0KPiB1c2VzIGNhc2Vz IGluIGFkZGl0aW9uIHRvIE1TLVBXIHdpdGggc2luZ2xlLWhvbWVkIENFcyAod2hpY2ggaXMNCj4g bGlzdGVkIHRoZXJlIGFzIHVzZSBjYXNlIDUpLg0KPiBBbmQgaXQgaXMgZXF1YWxseSBhcHBsaWNh YmxlIHRvIElQL01QTFMgYW5kIE1QTFMgLSB3aXRoIHRoZSBoZWxwIG9mICB0aGUNCj4gU3RhdGlj IFBXIFN0YXR1cyBNZXNzYWdlcyBkcmFmdCggaWYsIGZvciB3aGF0ZXZlciByZWFzb24sIHlvdSBk byBub3QNCj4gd2FudCAgdG8sIG9yIGNhbm5vdCwgdXNlIFJGQyA0NDQ3KS4NCj4NCj4gSGVuY2Ug SSBkb3VidCB0aGUgbmVlZCBmb3IgeWV0IGFub3RoZXIgUFcgcmVkdW5kYW5jeSAgbWVjaGFuaXNt IHdpdGgNCj4gbmFycm93IHNjb3BlIG9mIGFwcGxpY2FiaWxpdHkuDQo+DQo+IFJlZ2FyZHMsDQo+ ICAgICAgU2FzaGENCj4NCj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86 W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YNCj4gbWEueXV4aWFA enRlLmNvbS5jbjxtYWlsdG86bWEueXV4aWFAenRlLmNvbS5jbj4NCj4gU2VudDogTW9uZGF5LCBK dW5lIDEzLCAyMDExIDM6MjUgUE0NCj4gVG86IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0 Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gU2Vla2luZyBmZWVkYmFjayBvbiBJLUQgIk1Q TFMtVFAgTGluZWFyDQo+IFByb3RlY3Rpb24gQXBwbGljYWJpbGl0eSB0byBNUy1QVyINCj4NCj4g SGkgYWxsLA0KPg0KPiBUaGUgbGluZWFyIHByb3RlY3Rpb24gbWVjaGFuaXNtIGZvciBMU1AgYW5k IFBXKGluY2x1ZGluZyBNUy1QVykNCj4gc2hvdWxkIGJlIHRoZSBzYW1lIGFuZCBpdCBpcyB2YWx1 YWJsZSB0byBkZXNjcmliZSBpdCBjbGVhcmx5Lg0KPg0KPiBCVFcsIHRoZXJlIGlzIGEgdHlwbywg aXQgaXMgIlQtUEUgWiIgaW5zdGVhZCBvZiAiVC1QRSBCIi4NCj4NCj4gICINCj4gICBGaWd1cmUg MSBpbGx1c3RyYXRlcyBzdWNoIGEgc2NlbmFyaW8sIHdoZXJlIHR3byBNUy1QV3MgYXJlDQo+ICAg ZXN0YWJsaXNoZWQgYmV0d2VlbiBULVBFIEEgYW5kIFQtUEUgQiwgb3ZlciBTLVBFcyAxLTIgYW5k IDMtNA0KPiAgIHJlc3BlY3RpdmVseS4gRWFjaCBQVyBzZWdtZW50IGlzIGVzdGFibGlzaGVkIG92 ZXIgYW4gTFNQIChlLmcuIFBXLQ0KPiAgIHMxMiBvdmVyIExTUDEyKS4NCj4gICINCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGFuaWVsIENvaG4NCj4gU2VudDogVHVlc2Rh eSwgTWF5IDE3LCAyMDExIDQ6MTQgUE0NCj4gVG86IG1wbHMNCj4gU3ViamVjdDogU2Vla2luZyBm ZWVkYmFjayBvbiBJLUQgIk1QTFMtVFAgTGluZWFyIFByb3RlY3Rpb24NCj4gQXBwbGljYWJpbGl0 eSB0byBNUy1QVyINCj4gSW1wb3J0YW5jZTogSGlnaA0KPg0KPiBIaSBNUExTZXJzLA0KPg0KPiBJ IHVwbG9hZGVkICJNUExTLVRQIExpbmVhciBQcm90ZWN0aW9uIEFwcGxpY2FiaWxpdHkgdG8gTVMt UFciIEktRA0KPiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY29obi1tcGxzLXRw LXB3LXByb3RlY3Rpb24tMDApDQo+DQo+IFRoZSBhYnN0cmFjdCBnb2VzOg0KPg0KPiBPbmUgb2Yg dGhlIHJlcXVpcmVtZW50cyBvZiB0aGUgTVBMUyB0cmFuc3BvcnQgcHJvZmlsZSBbUkZDIDU2NTRd IGlzDQo+IHRvIHByb3ZpZGUgbGluZWFyIHByb3RlY3Rpb24gZm9yIHRyYW5zcG9ydCBwYXRocywg d2hpY2ggaW5jbHVkZSBib3RoDQo+IExTUHMgYW5kIFBXcy4gVGhlIGZ1bmN0aW9uYWwgYXJjaGl0 ZWN0dXJlIGRlc2NyaWJlZCBpbiBbU3Vydml2RndrXQ0KPiBpcyBhcHBsaWNhYmxlIHRvIGJvdGgg TFNQIGFuZCBQV3MsIGhvd2V2ZXIgW0xpbmVhclByb3RdIGRvZXMgbm90DQo+IGV4cGxpY2l0bHkg ZGVzY3JpYmUgbWVjaGFuaXNtcyBmb3IgUFcgcHJvdGVjdGlvbiBpbiBNUExTLVRQLg0KPg0KPiBU aGlzIGRvY3VtZW50IGV4dGVuZHMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIGxpbmVhciBwcm90 ZWN0aW9uDQo+IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gW0xpbmVhclByb3RdIHRvIE1QTFMtVFAg c2VnbWVudGVkIFBXcw0KPiAoTVMtUFdzKSBhcyBkZWZpbmVkIGluIFtSRkMgNjA3M10uDQo+DQo+ IENvdWxkIHlvdSBwbGVhc2UgcmV2aWV3IGl0IGFuZCBzZW5kIGZlZWRiYWNrIHRvIHRoZSBtYWls aW5nIGxpc3Qgb3INCj4gZGlyZWN0bHkgdG8gdGhlIGF1dGhvcj8NCj4NCj4gTG9va2luZyBmb3J3 YXJkIHRvIHlvdXIgZmVlZGJhY2ssDQo+DQo+IERhbmllbA0KPiBUaGlzIGUtbWFpbCBtZXNzYWdl IGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zDQo+IGluZm9y bWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5 IHRvDQo+IEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lv biBpbiBlcnJvciwgcGxlYXNlDQo+IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwg YW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQNCj4gYWxsIGNvcGllcyB0aGVyZW9mLg0K PiBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkg YW5kIGNvbnRhaW5zDQo+IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hp Y2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvDQo+IEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+IGluZm9ybSB1cyBieSBl LW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQNCj4g YWxsIGNvcGllcyB0aGVyZW9mLg0KPiBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZv ciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zDQo+IGluZm9ybWF0aW9uIHdoaWNoIGlz IENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvDQo+IEVDSSBUZWxl Y29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxl YXNlDQo+IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRl IHRoZSBvcmlnaW5hbCBhbmQNCj4gYWxsIGNvcGllcyB0aGVyZW9mLiCpbXq52j8/YnI+DQoNCg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQoNClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCg0KVGhpcyBtZXNz YWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3Bh bSBzeXN0ZW0uDQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNp cGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFM IGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5 IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBh bGwgY29waWVzIHRoZXJlb2YuDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkg c29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExh IGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFs bGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2 aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJy b3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmlj YXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwg R3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlh bCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhl IGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1 c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRh Y2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0K DQpbY2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAxQFRJLkRpc2NsYWltZXJdUmlz cGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiCoqCBuZWNl c3NhcmlvLg0KDQo= --_000_A1F769BC58A8B146B2EEA818EAE052A2096ABFEF96GRFMBX702RM00_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear Danie= l,

many thank= s for bringing to our attention this issue.

 = ;

It makes s= ense for me having the same linear protection mechanisms applied at both LS= P and PW level (in the MPLS-TP framework).

 = ;

It is obvi= ous that there are circumstances where PW redundancy mechanisms can be expl= oited because they cover the requirements of certain architectural approaches

but I do n= ot believe it can be claimed that PW redundancy mechanisms cover the same r= equirements  covered by linear protection mechanism. Therefore there is a gap that need to be filled and extending the already defined li= near protection for LSPs seems the most appropriate way to proceed.

 = ;

Actually, = I do not see any argument below confuting your hypothesis and therefore I s= upport your proposal.

 = ;

Best regar= ds,

Alessandro=

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

 <= /p>

Da: pwe3-b= ounces@ietf.org [mailto:pwe3-bounces@ietf.org] Per conto di Daniel Cohn
Inviato: luned=A8=AC 20 giugno 2011 11:51
A: Alexander Vainshtein; ma.yuxia@zte.com.cn
Cc: mpls@ietf.org; pwe3@ietf.org
Oggetto: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Lin= ear Protection Applicability to MS-PW"

 

Sasha,

 = ;

I think th= e main question here is why call PW linear protection an ad-hoc mechanism w= hen it=A1=AFs simply an extension of LSP linear protection. From an implementation point of view, the differences are minimal =A8C you coul= d even say semantic. I think this is what Ma means by simplicity and I whol= ly agree with her =A8C you have a single mechanism to protect all transport= paths =A8C be them LSP or PW.

 = ;

My two cen= ts,

 = ;

DC

 = ;

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@eci= tele.com]
Sent: Monday, June 20, 2011 11:50 AM
To: ma.yuxia@zte.com.cn
Cc: Daniel Cohn; mpls@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaShar= on); pwe3@ietf.org
Subject: RE: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP= Linear Protection Applicability to MS-PW"

 

Dear Ma,

Lots of th= anks for our response. Please see some comments/answers inline below.<= /o:p>

 = ;

Regards,

 &nbs= p;   Sasha

 = ;

From: ma.yuxia@zte.com.cn [mailto:ma.yuxia@zte.com.cn]
Sent: Monday, June 20, 2011 11:31 AM
To: Alexander Vainshtein
Cc: Daniel Cohn; mpls@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaShar= on); pwe3@ietf.org
Subject: =B4= =F0=B8=B4: RE: [mpls] [PWE3] Seeking feed= back on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"<= /o:p>

 


Hi Sasha,

"Linear protection" is different= from "Mult= i-homed CE redundancy" and has no reference with AC.

[[[S= asha]]] Absolutely.  


Working path(s) and protection path(s) hav= e same source and sink endpoints in linear protection type.

[[[S= asha]]] Of course.



IMHO, When S-PE fails, it is more simple t= o use "Linear protection" to protect it.

[[[S= asha]]] Well, simplicity , like beauty, is in the eye of the beholderJ.

But = IMHO  introducing multiple simple ad hoc solutions (each for its speci= fic case) and maintaining them  eventually make your life more  complicated when compared with one generic mechanism=A1=AD

 

Best Regards,
Ma


Alexander Vainsh= tein <Alexander.Vain= shtein@ecitele.com> =D0=B4=D3= =DA 2011-06= -14 20:02:10:
> Daniel,
> Please see = more inline (bold purple italics). I=A1=AF<= /tt>ve also stripped the > portions of the text that are not rela= ted to this round of comments.
>  
> Regards,
>      Sasha
>  
> From: Danie= l Cohn [mailto:DanielC@orckit.com]
> Sent: Tuesday, June 14, 2011 2:34 PM
> To: Alexander Vainshtein
> Cc: m= pls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - = IL/Hod
> HaSharon); ma.yuxia@zte.com.cn
> Subject: RE: [mpls] [PWE3] Seeking fee= dback on I-D "MPLS-
> TPLinearProtectionApplicability to MS-= PW"
>  
> Hi Sasha, t= hanks again and see inline with [DC].
>  
> From: Alexa= nder Vainshtein [mailto:Alexan= der.Vainshtein@ecitele.com]
> Sent: Monday, June 13, 2011 6:11 PM
> To: Daniel Cohn
> Cc: m= pls@ietf.org; pwe3@ietf.org; Sprecher, Nurit (NSN - = IL/Hod
> HaSharon); ma.yuxia@zte.com.cn
> Subject: RE: [mpls] [PWE3] Seeking fee= dback on I-D "MPLS-
> TPLinearProtectionApplicability to MS-= PW"
>  
> Daniel and = all,
> Please see = some comments inline below.
>  
> Regards,
>      Sasha
>  
> From: Danie= l Cohn [mailto:DanielC@orckit.com]
> Sent: Monday, June 13, 2011 5:55 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSh= aron); Alexander Vainshtein;
> ma.yuxia@zte.com.cn
> Cc: m= pls@ietf.org; pwe3@ietf.org
> Subject: RE: [mpls] [PWE3] Seeking fee= dback on I-D "MPLS-
> TPLinearProtection Applicability to MS= -PW"
>  
> Hi,<= /tt>
>  
> Thanks all = for the feedback. I believe we all agree that PW
> protection is only required in the eve= nt of S-PE failure at an MS-PW
> =A8C this  is clearly stated in the draft. Now, both Sasha and N= urit
> mention that the PW redundancy mechani= sm can meet the MPLS-TP PW
> protection requirements.
> [[[Sasha]]]= =A1=AD snipped =A1=AD
> E.g., the P= W redundancy mechanisms take care of dual-homed CEs in
> SS- and MS-PWs some= thing that liner protection of PWs cannot do.
> [DC] I=A1=AFm afraid I don=A1=AFt follow you here. Where does PW redundancy
> take care of dual-homed CE? Actually P= W redundancy draft explicitly
> states: =A1= =B0The meth= od for dual-homing of CE1 to PE1 and to PE3 nodes,
> and the protocols used, are outside th= e scope of this document=A1=B1.
> [[[Sasha]]]= Quoting from the draft:
> 15.2. Multi= ple Multi-homed CEs with single SS-PW redundancy
>  
>              |<-------------- Emulated Service ----------------= >|  
>              |                                                  |  
>              |          |<------- Pseudo Wire ------>|          |  
>              |          |                            |          |  
>              |          |    |<-- PSN Tunnels-->|    |          |  
>              |          V    V    (not shown)   V    V          |  
>              V    AC    +----+                  +----+     AC   V  
>        +-----+    |     |....|.......PW1........|....|     |    +-----+  
>        |     |----------| PE1|......   .........| PE3|----------|     |  
>        | CE1 |          +----+      \ /  PW3    +----+          | CE2 |  
>        |     |          +----+       X          +----+          |     |
>        |     |          |    |....../ \..PW4....|    |          |     |  
>        |     |----------| PE2|                  | PE4|--------- |     |  
>        +-----+    |     |....|.....PW2..........|....|     |    +-----+  
>                   AC    +----+                  +----+    AC      
>      
>    
>      Figure 15-2 Multiple Multi-homed CEs with single SS-P= W redundancy  
>  
>    The application in Figure 15-2 makes use of the Indep= endent mode of
>    operation.
>  
>    CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed P= E3 and PE4. The
>    method for dual-homing and the used protocols are out= side the scope
>    of this document.  Note that the PSN tunnels are not shown in this
>    figure for clarity. However, it can be assumed that e= ach of the PWs
>    shown is encapsulated in a separate PSN tunnel.
>  
>    Assume that the AC from CE1 to PE1 is Active, from CE= 1 to PE2 is
>    Standby; furthermore, assume that the AC from CE2 to = PE3 is Standby
>    and from CE2 to PE4 is Active. The method of deriving= Active/Standby
>    status of the AC is outside the scope of this documen= t.
>  
>    PE1 advertises the preferential status "Active&q= uot; and operational
>    status "Pseudowire forwarding" for pseudowi= res PW1 and PW4 connected
>    to PE3 and PE4. This status reflects the forwarding s= tate of the AC
>    attached to PE1. PE2 advertises preferential status &= quot;Standby" and
>    operational status "Pseudowire forwarding" = for pseudowires PW2 and
>    PW3 to PE3 and PE4. PE3 advertises preferential statu= s "Standby" and
>    operational status "Pseudowire forwarding" = for pseudowires PW1 and
>    PW3 to PE1 and PE2. PE4 advertise the preferential st= atus "Active"
>    and operational status "Pseudowire forwarding&qu= ot; for pseudowires PW2
>    and PW4 to PE2 and PE1 respectively. Thus by matching= the local and
>    remote preferential forwarding status of "Active= " and operational
>    status of "Pseudowire forwarding" of pseudo= wires, the PE nodes
>    determine which PW should be in the Active state. In = this case it is
>    PW4 that will be selected.  
>  
>    On failure of the AC between CE1 and PE1, the forward= ing state of
>    the AC on PE2 is changed to Active. PE2 then announce= s the newly
>    changed 'preferential forwarding' status bit of "= ;active" to PE3 and
>    PE4. PE1 will advertise a PW status notification mess= age indicating
>    that the AC between CE1 and PE1 is operationally down= . PE2 and PE4
>    match the local and remote preferential forwarding st= atus of
>    "Active" and operational status "Pseud= owire forwarding" and select
>    PW2 as the new active pseudowire to send traffic to.
>  
>    On failure of PE1 node, PE2 will detect it and will t= ransition the
>    forwarding state of its AC to Active. The method by w= hich PE2
>    detects that PE1 is down is outside the scope of this= document. PE2
>    then announces the newly changed 'preferential forwar= ding' status
>    bit of "Active" to PE3 and PE4. PE2 and PE4= match the local and
>    remote preferential forwarding status of "Active= " and operational
>    status "Pseudowire forwarding" and select P= W2 as the new active
>    pseudowire to send traffic to. Note that PE3 and PE4 = may have
>    detected that the PW to PE1 went down via T-LDP Hello= timeout or via
>    other means. However, they will not be able to forwar= d user traffic
>    until they received the updated status bit from PE2.
>  
>    Because each dual-homing algorithm running on the two= node sets,
>    i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects th= e active AC
>    independently, there is a need to signal the active s= tatus of the AC
>    such that the PE nodes can select a common active PW = for end-to-end
>    forwarding between CE1 and CE2 as per the procedures = in the
>    independent mode.
>  
>    Note that any primary/secondary procedures, as define= d in sections
>    5.1.  and 5.2. , do not apply in this use case as the Activ= e/Standby
>    status is driven by the AC forwarding state as determ= ined by the AC
>    dual-homing protocol used.
>  
>  
> I believe y= ou=A1=AFve taken your =A1=B0out of scope=A1=B1 reference from this text,
> but IMHO you misinterpreted it.
> What it mea= ns (or so I read it) is that specific dual-homing
> protocol is out of scope as long as it= meets certain assumptions.
> Aside: It w= ould be good if the authors of the PW redundancy drafts
> could explicitly specify these assumpt= ions.
>  
> [[[Sasha]]]= =A1=AD snipped =A1=AD
>  
> Now let=A1=AFs turn our attention back to whether the PW redundancy
> draaft can be used to meet MPLS-TP PW = protection requirements. I can
> identify the following reasons why in = its current form it doesn=A1=AFt:
>  
> -          It explicitly (=A1=B0= outside the scope=A1=B1) does not define
> protection triggers and how to handle = coexisting triggers, as
> requested in RFC 5654 (MPLS-TP Require= ments), reqs #75, #76 and #79
> [[[Sasha]]]= So what? Definition of triggers is orthogonal to how
> coordinated protection switching happe= ns.
> [DC] It is.= But still it needs to be defined by the recovery
> framework, e.g. what should the endpoi= nt do when one PW is in SF and
> the other is in SD, or when both are i= n SD. Operators expect well-
> defined behavior in these and other sc= enarios, and PW redundancy
> does not define them (because it was n= ot in their scope).
> [[[Sasha]]]= I wonder if you have followed the discussion regarding
> ability to define SD condition for LSP= s and PWs on the MPLS-TP list?
> IMO it is not possible to define it in= a meaningful way. Hence I do
> not see a proposal that does not addre= ss a scenario that does not
> exist in reality as a flawed one.
>  
> -          It does not support the ability to distinguish betwee= n
> different types of triggers (i.e. one = end doesn=A1=AFt know why the other
> end triggered switch), as requested in= RFC 5654 (MPLS-TP
> Requirements), req #77
> -          It does not define revertive/nonrevertive behavior, a= s
> requested in RFC 5654 (MPLS-TP Require= ments), req #64
> -          It does not define holdoff support, which is especial= ly
> important to avoid race conditions wit= h LSP protection when it exists
> -          It doesn=A1=AFt support 1+1 mode, as requested in RFC 5654
> (MPLS-TP Requirements), req #65
> [[[Sasha]]]= All these claims are correct =A8C and  this should not be a
> surprise, because MPLS-TP requirements= have been defined much later
> than the PW redundancy mechanism.
> But I do no= t think that this justifies co-existence of two different
> mechanisms.
> [DC] So how= do you propose to meet the PW protection requirement?
> -          It=A1=AFs a two-phase protocol, with the consequent impact on timing
> [[[Sasha]]] Could you please elaborate= ? [DC] In draft-ietf-mpls-tp-
> linear-protection, each endpoint will = immediately switch traffic to
> the other path upon identifying an SF = condition in a path, without
> waiting for the far end to acknowledge= the switch (1-phase). In PW
> redundancy, an endpoint detecting an S= F condition in a path will not
> switch until the far end has acknowled= ged the switch (2-phase).
> Needless to say, recovery is slower in= a 2-phase protocol.
> [[[Sasha]]]= To the best of my understanding, 1-phase protection is
> only possible in 1+1 unidirectiona= l architectures. And yes, I know
> that MPLS-TP requires a  mechanism to support this; whether anybody
> would really do that in the packet-swi= tching network is not clear to
> me. And I acknowledge that the PW redu= ndancy drafts do not support
> 1+1 unidirectional scheme. =
>  
> -          It doesn=A1=AFt define retransmission of protection
> coordination messages, so loss of a si= ngle PDU can result in
> switchover not taking place, thus not = supporting sub-50 ms recovery
> in this case
> [[[Sasha]]]= The PW redundancy protocol runs either on top of LDP
> (which benefits from TCP retransmissio= ns) or on top of static PW
> status messages (where retransmission = is defined).
> [DC] True <= /span>=A8C but static PW status defines slow retransmission (=A1=B0will
> be transmitted twice at an initial int= erval of one second=A1=B1) while
> draft-ietf-mpls-tp-linear-protection s= pecifies fast retransmission
> when required for fast recovery (secti= on 3.1.4).
>  
> In summary,= PW redundancy was not designed with TP requirements in
> mind, and as such does not meet the TP= requirements. Of course
> modifications may be introduced, but w= hy reinvent the wheel when
> there is a protocol (draft-ietf-mpls-t= p-linear-protection-06) in the
> standards track that supports all the = above requirements and can be
> applied to MS-PW protection with minor= modifications?
> [[[Sasha]]]= As I said, because the applicability scope is by far too
> narrow to justify a dedicated protocol= .
> [DC] If we = were discussing designing a new protocol, I might agree
> with you. But from a practical standpo= int, the PW protection draft
> is not a dedicated protocol =A8C it=A1=AFs an applicability statement to an
> existing protocol. Both from the imple= mentation and the operational
> point of view it defines a new use cas= e for an existing protocol and concept.
>  
>  
> Regards,
>  
> Daniel
>  
>  
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Sprecher, Nurit (NSN - IL/Hod HaSharon= )
> Sent: Monday, June 13, 2011 4:02 PM
> To: ext Alexander Vainshtein; ma.yuxia@zte.com.cn
> Cc: m= pls@ietf.org; pwe3@ietf.org
> Subject: Re: [mpls] [PWE3] Seeking fee= dback on I-D "MPLS-
> TPLinearProtection Applicability to MS= -PW"
>  
> Hi,<= /tt>
> I would lik= e to second Sasha.
> End-to-end = PW protection (with diverse paths) does not scale, and
> put hard restrictions on the utilizati= on of the resources.  
> MPLS-TP PWs= are carried across the network inside MPLS-TP LSPs.
> Therefore, an obvious way to provide p= rotection for a PW is to
> protect the LSP that carries it.  
> If the PW i= s a multi-segment PW, then LSP recovery can only protect
> the PW in individual segments. =  This means that a single LSP
> recovery action cannot protect against= a failure of a PW switching
> point (an S-PE).
> When protec= ting against an AC or T/S-PE failure by dual
> connectivity, PW redundancy mechanisms= provide means for the PEs to
> coordinate over which LSP the traffic = of the PW is carried.
> I also doub= t why there is a need for additional mechanism.
> Best regard= s,
> Nurit
>  
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> ext Alexander Vainshtein
> Sent: Monday, June 13, 2011 3:43 PM
> To: ma.yuxia@zte.com.cn
> Cc: m= pls@ietf.org; pwe3@ietf.org
> Subject: Re: [PWE3] [mpls] Seeking fee= dback on I-D "MPLS-TP
> LinearProtection Applicability to MS-P= W"
>  
> Dear Ma and= all,
> Adding the = PWE3 WG to my response.
>  
> The PW redu= ndancy mechanism supports linear protection of MS-PWs as
> one of many additional application use= cases:
> Appendix A = of the PW redundancy Bit draft describes 5 application
> uses cases in addition to MS-PW with s= ingle-homed CEs (which is
> listed there as use case 5).
> And it is e= qually applicable to IP/MPLS and MPLS - with the help of  the
> Static PW Status Messages draft( if, f= or whatever reason, you do not
> want  to, or cannot= , use RFC 4447).
>  
> Hence I dou= bt the need for yet another PW redundancy  mechanism with
> narrow scope of applicability.<= /tt>
>  
> Regards,
>      Sasha
>  
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> ma.yuxia@zte.com.cn
> Sent: Monday, June 13, 2011 3:25 PM
> To: m= pls@ietf.org
> Subject: Re: [mpls] Seeking feedback o= n I-D "MPLS-TP Linear
> Protection Applicability to MS-PW"= ;
>  
> Hi all,
>
> The linear protection mechanism for LS= P and PW(including MS-PW)
> should be the same and it is valuable = to describe it clearly.
>
> BTW, there is a typo, it is "T-PE= Z" instead of "T-PE B".
>
>  = "
>  = Figure 1 illustra= tes such a scenario, where two MS-PWs are
>  = established betwe= en T-PE A and T-PE B, over S-PEs 1-2 and 3-4
>  = respectively. Eac= h PW segment is established over an LSP (e.g. PW-
>  = s12 over LSP12).
>  = "
> -----Origin= al Message-----=
> From: Daniel Cohn
> Sent: Tuesday, May 17, 2011 4:14 PM
> To: mpls
> Subject: Seeking feedback on I-D "= ;MPLS-TP Linear Protection
> Applicability to MS-PW"
> Importance: High
>
> Hi MPLSers,
>
> I uploaded "MPLS-TP Linear Protec= tion Applicability to MS-PW" I-D
> (http://tools.ietf.org/html/draft-cohn= -mpls-tp-pw-protection-00)
>
> The abstract goes:
>
> One of the requirements of the MPLS tr= ansport profile [RFC 5654] is
> to provide linear protection for trans= port paths, which include both
> LSPs and PWs. The functional architect= ure described in [SurvivFwk]
> is applicable to both LSP and PWs, how= ever [LinearProt] does not
> explicitly describe mechanisms for PW = protection in MPLS-TP.
>
> This document extends the applicabilit= y of the linear protection
> mechanism described in [LinearProt] to= MPLS-TP segmented PWs
> (MS-PWs) as defined in [RFC 6073].
>
> Could you please review it and send fe= edback to the mailing list or
> directly to the author?
>
> Looking forward to your feedback,
>
> Daniel
> This e-mail= message is intended for the recipient only and contains
> information which is CONFIDENTIAL and = which may be proprietary to
> ECI Telecom. If you have received this= transmission in error, please
> inform us by e-mail, phone or fax, and= then delete the original and
> all copies thereof.
> This e-mail= message is intended for the recipient only and contains
> information which is CONFIDENTIAL and = which may be proprietary to
> ECI Telecom. If you have received this= transmission in error, please
> inform us by e-mail, phone or fax, and= then delete the original and
> all copies thereof.
> This e-mail= message is intended for the recipient only and contains
> information which is CONFIDENTIAL and = which may be proprietary to
> ECI Telecom. If you have received this= transmission in error, please
> inform us by e-mail, phone or fax, and= then delete the original and
> all copies thereof. =A9mz=B9=DA??br>

 
-------------------------------------------------=
-------
ZTE Information&nb=
sp;Security Not=
ice: The =
information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recip=
ients named above are =
obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email=
 and any files transmitted&nbs=
p;with it <=
/span>are confidential=
&=
nbsp;and intend=
ed solely =
forthe use=
&=
nbsp;of the =
;individual or<=
/span>&n=
bsp;entity to&nb=
sp;whom they&nbs=
p;are addressed=
.=
 If you&nbs=
p;have received=
&=
nbsp;this email=
&=
nbsp;in error&nb=
sp;please notif=
y=
 the origi=
nator of =
themessage. Any views expressed in this message are those of the =
individual sender.
This message =
has been=
 scanned for <=
/span>viruses and =
Spam by<=
span lang=3D"EN-US" style=3D"font-family:"Courier New""> ZTE Anti-Spam =
system.

This e-mail message is intended for the recipient o= nly and contains information which is CONFIDENTIAL and which may be proprie= tary to ECI Telecom. If you have received this transmission in error, pleas= e inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

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

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

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

--_000_A1F769BC58A8B146B2EEA818EAE052A2096ABFEF96GRFMBX702RM00_-- --_971ddeb3-9606-49b8-9f36-e7f7d65cbbe4_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_971ddeb3-9606-49b8-9f36-e7f7d65cbbe4_-- From hejia@huawei.com Fri Jun 24 04:11:14 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB1821F84E0 for ; Fri, 24 Jun 2011 04:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=-3.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95E4gJS0HUAy for ; Fri, 24 Jun 2011 04:11:13 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0E121F84DE for ; Fri, 24 Jun 2011 04:11:13 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNA00FOWKCL38@szxga05-in.huawei.com> for pwe3@ietf.org; Fri, 24 Jun 2011 19:09:57 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNA003QTKCLOL@szxga05-in.huawei.com> for pwe3@ietf.org; Fri, 24 Jun 2011 19:09:57 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACB18794; Fri, 24 Jun 2011 19:09:55 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 24 Jun 2011 19:09:49 +0800 Received: from hejia (10.70.77.159) by smtpscn.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 24 Jun 2011 19:09:54 +0800 Date: Fri, 24 Jun 2011 19:09:54 +0800 From: Hejia In-reply-to: X-Originating-IP: [10.70.77.159] To: pwe3@ietf.org Message-id: <03c801cc325f$3f145200$bd3cf600$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wKBq21gFpou9m+8qMDAhGw)" Content-language: zh-cn Thread-index: Acwmim8YgO2wxXLFTRmMrx1MED7XzgL1LsvA X-CFilter-Loop: Reflected References: Subject: Re: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 11:11:14 -0000 --Boundary_(ID_wKBq21gFpou9m+8qMDAhGw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Yes/Support. =20 B.R. Jia =20 =B7=A2=BC=FE=C8=CB: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] = =B4=FA=B1=ED Bocci, Matthew (Matthew) =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA6=D4=C29=C8=D5 17:49 =CA=D5=BC=FE=C8=CB: pwe3@ietf.org =D6=F7=CC=E2: [PWE3] WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt =20 This email begins a two week working group last call for draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt =20 Please review the draft and post any comments to the PWE3 mailing list. =20 The working group last call will end on Friday 24th June. =20 Best regards, =20 Matthew & Andy --Boundary_(ID_wKBq21gFpou9m+8qMDAhGw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Yes/Support.

 

B.R.

Jia

 

=B7=A2=BC=FE=C8=CB: pwe3-bounces@ietf.org = [mailto:pwe3-bounces@ietf.org] =B4=FA=B1=ED = Bocci, Matthew = (Matthew)
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA6=D4=C29=C8=D5 17:49
=CA=D5=BC=FE=C8=CB: = pwe3@ietf.org
=D6=F7=CC=E2: [PWE3] WG LC on = draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt

 

This email begins a two week working group last call = for draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt

 

Please review the draft and post any comments to the PWE3 mailing = list.

 

The working group last call will end on Friday 24th = June.

 

Best regards,

 

Matthew & Andy

= --Boundary_(ID_wKBq21gFpou9m+8qMDAhGw)-- From tnadeau@lucidvision.com Fri Jun 24 12:48:01 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3265611E80A7; Fri, 24 Jun 2011 12:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32cF4ybUuZ2X; Fri, 24 Jun 2011 12:48:00 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3322211E80A3; Fri, 24 Jun 2011 12:48:00 -0700 (PDT) Received: from [10.100.69.31] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id E8AD71C054F4; Fri, 24 Jun 2011 15:47:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--74804653 From: Thomas Nadeau In-Reply-To: Date: Fri, 24 Jun 2011 15:47:56 -0400 Message-Id: <878D233B-D3BA-4A3A-8E2A-314C171F10D9@lucidvision.com> References: To: Greg Mirsky X-Mailer: Apple Mail (2.1084) Cc: pwe3 , Luca Martini , mpls@ietf.org Subject: Re: [PWE3] Comments to draft-nadeau-pwe3-vccv-2-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 19:48:01 -0000 --Apple-Mail-3--74804653 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greg, =20 On Jun 9, 2011, at 5:58 PM, Greg Mirsky wrote: > Dear Authors, > perhaps I've missed your response and I've decided to re-post. Apologies for the delay in responding. =20 >=20 > Regards, > Greg >=20 > On Fri, Mar 11, 2011 at 2:26 PM, Greg Mirsky = wrote: > Dear Authors, > please find my comments below. > this proposal is closely related to changes to RFC 5586 put forward in = draft-lm-pwe3-mpls-tp-gal-in-pw-00 but there's no reference to the = draft. TOM: Cool. We can add that as a requirement. > RFC 5586 states and the draft-lm-pwe3-mpls-tp-gal-in-pw-00 maintains = that in MPLS-TP network the GAL must be BoS. Only in non-TP MPLS = netowrks GAL might be not a BoS. In your proposal the GAL precedes the = PW and thus is not BoS. But the document's scope is for all MPLS PWs, = including over MPLS-TP PSN. Unless statement in Section 4.2 RFC 5586 "In = MPLS-TP (GAL) ... MUST always be at the bottom of the label stack (i.e., = S bit set to 1)" updated proposed use of GAL is allowed only in non-TP = MPLS PSN. TOM: That was a typo. We've swapped the GAL and PW labels in = version -02. > Section 2 lists of allowed ACH. Since these are hexadecimal numbers = I'd suggest prepending them with '0x' to make as "0x07, 0x21, and 0x57". = And I'd ask for clarification of "allowed". Is it "MAY", "SHOULD" or = "MUST" be limited to ... A, B, C"? TOM: We copied the format of the base VCCV RFC, but I can update = this way if no one else objects. > In Section 3 stated that TTL in PW LSE must be set to 1 for SS-PW and = to appropriate value in MS-PW to reach intended PE. Hence my question, = Is this mechanism to reach MIP, i.e. S-PE, or this is mechanism to = generate exception? But that is how PW VCCV Control Channel Type 3 = works. TOM: We added those restrictions so that the protocol behaved = properly for SS and MH PWs. > What is the interpretation of GAL in a label stack? To indicate PW CW = after the PW LSE? TOM: Do you mean the interpretation of the GAL in the label = stack as defined in the draft, or in general? > editorial - in Abstract s/The MPLS/the MPLS or a reference to, = perhaps, RFC 5654. TOM: Will add to version -03 with the other changes above. --Tom >=20 > Regards, > Greg >=20 >=20 >=20 >=20 >=20 --Apple-Mail-3--74804653 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = Greg,
 

On Jun 9, 2011, = at 5:58 PM, Greg Mirsky wrote:

Dear = Authors,
perhaps I've missed your response and I've decided to = re-post.


Apologies = for the delay in responding.  


Regards,
Greg

On = Fri, Mar 11, 2011 at 2:26 PM, Greg Mirsky <gregimirsky@gmail.com>= wrote:
Dear = Authors,
please find my comments below.
  • this proposal is = closely related to changes to RFC 5586 put forward in = draft-lm-pwe3-mpls-tp-gal-in-pw-00 but there's no reference to the = draft.

TOM: = Cool. We can add that as a requirement.
  • RFC 5586 states and the draft-lm-pwe3-mpls-tp-gal-in-pw-00 maintains = that in MPLS-TP network the GAL must be BoS. Only in non-TP MPLS = netowrks GAL might be not a BoS. In your proposal the GAL precedes the = PW and thus is not BoS. But the document's scope is for all MPLS PWs, = including over MPLS-TP PSN. Unless statement in Section 4.2 RFC 5586 "In = MPLS-TP (GAL) ... MUST always be at the bottom of the label stack = (i.e., S bit set to 1)" updated proposed use of GAL is allowed only in = non-TP MPLS PSN.
TOM: That = was a typo. We've swapped the GAL and PW labels in version = -02.
  • Section 2 lists of allowed ACH. Since these are hexadecimal numbers = I'd suggest prepending them with '0x' to make as "0x07, 0x21, and 0x57". = And I'd ask for clarification of "allowed". Is it "MAY", "SHOULD" or = "MUST" be limited to ... A, B, = C"?
TOM: We = copied the format of the base VCCV RFC, but I can update this way if no = one else objects.
  • In Section 3 stated that TTL in PW LSE must be set to 1 for SS-PW = and to appropriate value in MS-PW to reach intended PE. Hence my = question, Is this mechanism to reach MIP, i.e. S-PE, or this is = mechanism to generate exception? But that is how PW VCCV Control Channel = Type 3 works.
TOM: We = added those restrictions so that the protocol behaved properly for SS = and MH PWs.
  • What is = the interpretation of GAL in a label stack? To indicate PW CW after the = PW LSE?
TOM: Do = you mean the interpretation of the GAL in the label stack as defined in = the draft, or in general?
  • editorial - in Abstract s/The MPLS/the MPLS or a reference to, = perhaps, RFC 5654.
TOM: Will = add to version -03 with the other changes = above.

= --Tom



Regards,
Greg





= --Apple-Mail-3--74804653-- From N.Leymann@telekom.de Mon Jun 27 00:41:32 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDC111E8081; Mon, 27 Jun 2011 00:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOsAsym8w7Qd; Mon, 27 Jun 2011 00:41:32 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 83F1911E8086; Mon, 27 Jun 2011 00:41:31 -0700 (PDT) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 27 Jun 2011 09:41:14 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.228]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%15]) with mapi; Mon, 27 Jun 2011 09:41:14 +0200 From: To: , Date: Mon, 27 Jun 2011 09:41:13 +0200 Thread-Topic: LDP DoD and PW Signalling ... Thread-Index: Acw0nZayI9OcF0gpR7qbFZfRRe6WPg== Message-ID: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [PWE3] LDP DoD and PW Signalling ... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 07:41:32 -0000 Hi, We came across an issue related to the Seamless MPLS Architecture when runn= ing LDP DoD between two nodes if we are trying to set up an PW between the = same nodes. Assume we have an Access Node (AN) and an Aggregation Mode (AG). The AN est= ablishes a LDP DoD with the AG. When we are going to establish a PW between= the AN and the AG as well we run into the problem that RFC4447 specifies o= nly the DU mode for the targeted LDP session (section 3): "An LDP session must be set up between the pseudowire endpoints. LDP MUST be used in its 'downstream unsolicited' mode. LDP's 'liberal label retention' mode SHOULD be used." >From our point of view we should reuse the existing LDP session and go with= only a single LDP session between AN and AG. That has the advantage that w= e do not change the behaviour of PW FECs 128/129 (there are other options l= ike using two LDP sessions with additonal lookbacks or two sessions with si= ngle loopback and LDP DoD for IP FECs, but those have an heavy - negative = impact - on the existing implementations and/or standards). For a more long term approach we are in favour of a change to RFC5036 by de= fining a new TLV which denotes the DU/DoD mode per FEC type. Any comments on that? Regards Nic From amalis@gmail.com Mon Jun 27 12:31:00 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B06911E8145 for ; Mon, 27 Jun 2011 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IT3ODIPluHI for ; Mon, 27 Jun 2011 12:30:59 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2AE11E8137 for ; Mon, 27 Jun 2011 12:30:59 -0700 (PDT) Received: by bwb17 with SMTP id 17so1848707bwb.31 for ; Mon, 27 Jun 2011 12:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=cFAS/Chf6Zf81JiEaET4PFwQ5mQasSZYoKu3kIl9R88=; b=T5AXF88u+lgOjusDxZjzj4kUYKiwdNyQ1cZEg0hpuZTeJlZ9ILyV9j90EoXpEYo6uL k50MvqACWeHiIStnwnhQYbT/paVZR/N5Di7YMxzBWgETYTquUTRVG4lVycJY/cSdW8Th 37KeodqGZsWyS6qnBIN0MmBSdB2xUFHUN/+to= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=oL5Epz4f8N6KQfdwMQwT1lmrGJXdMWEAdNimYumw07nFxgFvWETmoGyS2xnDFp0KsN i5jdEnOSt0H/+3Ct4OR9444IdafBk8/71iEvSdnjYILYb6bJmOS+tJdeuR4mteG4Kzgd +f6ccaU+PdOOEhiBpVmv8zMQPtgnK9eepBcyM= Received: by 10.204.50.87 with SMTP id y23mr4592803bkf.58.1309203058152; Mon, 27 Jun 2011 12:30:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.52.75 with HTTP; Mon, 27 Jun 2011 12:30:38 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Mon, 27 Jun 2011 15:30:38 -0400 Message-ID: To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PWE3] PWE3 WG last call for draft-ietf-pwe3-static-pw-status-04 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 19:31:00 -0000 This ends the WG last call for draft-ietf-pwe3-static-pw-status-04. Authors, please update the draft to reflect the email thread "S-PE bypass mode in draft-ietf-pwe3-static-pw-status-04" on the PWE3 list. When -05 has been issued, the draft will be submitted to the IESG. Thanks, Andy and Matthew On Fri, Jun 10, 2011 at 10:45 AM, Andrew G. Malis wrote: > This email begins a two week WG last call for > draft-ietf-pwe3-static-pw-status-04 as a Proposed Standard RFC. > > Please reply to this thread with any last call comments. > > The last call closes on Friday 24th June 2011. > > Regards, > Andy & Matthew > From david.sinicrope@ericsson.com Mon Jun 27 13:03:53 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E29511E8151 for ; Mon, 27 Jun 2011 13:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMJmH+k48+EC for ; Mon, 27 Jun 2011 13:03:52 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 83C7311E810B for ; Mon, 27 Jun 2011 13:03:52 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p5RK3emd003142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Jun 2011 15:03:51 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 27 Jun 2011 16:03:46 -0400 From: David Sinicrope To: "IETF.PWE3" Date: Mon, 27 Jun 2011 16:03:43 -0400 Thread-Topic: PWE3 Agenda Slot call for IETF 81 - Quebec City Thread-Index: Acw1BVIP3RjFO5J6TqOdF4a+6wbr8A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 20:03:53 -0000 Hi All, Please let me know if you would like a time slot for the IETF 81 PWE3 sessi= on by replying to this email with the desired duration, topic/draft title, = and presenter for each slot requested. Thanks, Dave From internet-drafts@ietf.org Mon Jun 27 15:59:31 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4413811E808E; Mon, 27 Jun 2011 15:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCnpv+7mb5zz; Mon, 27 Jun 2011 15:59:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC5011E8076; Mon, 27 Jun 2011 15:59:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110627225930.20776.85898.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2011 15:59:30 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-static-pw-status-05.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 22:59:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Pseudowire Status for Static Pseudowires Author(s) : Luca Martini George Swallow Giles Heron Matthew Bocci Filename : draft-ietf-pwe3-static-pw-status-05.txt Pages : 12 Date : 2011-06-27 This document specifies a mechanism to signal Pseudowire (PW) status messages using an PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far end T-PE. The mechanism allows PW OAM message mapping and PW redundancy to operate on static PWs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-static-pw-status-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-static-pw-status-05.txt From rajiva@cisco.com Mon Jun 27 16:10:15 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3537521F8450; Mon, 27 Jun 2011 16:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqo7h7pFCzzi; Mon, 27 Jun 2011 16:10:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E4F8721F8558; Mon, 27 Jun 2011 16:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2452; q=dns/txt; s=iport; t=1309216213; x=1310425813; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=95mEuMYp4I5VkmdniqJDOmp96jgZEKtBliDpBPydGMY=; b=iCSGSNX5jnsoz8+EPWK0iNCXHUEIYWJsurAmFCqguQe4LyzyLiJJ+d5e Fzo78gEVHjTtKDGes+q0ldOp+9chP3LrFdo9/sQPUCRoOqhX4p/UNo+fG CktAUbDvDDn1UYyEPSLra0hj4NS4dNDYMA4RbMElglDGPxIgHVwXAhyHb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEBAMQMCU6tJV2Y/2dsb2JhbABSmAmPLneIdKIrniaGMASHLI9Oi0I X-IronPort-AV: E=Sophos;i="4.65,434,1304294400"; d="scan'208";a="723055401" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2011 23:10:08 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5RNA783009836; Mon, 27 Jun 2011 23:10:07 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 18:10:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jun 2011 18:10:06 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C054B05F5@XMB-RCD-111.cisco.com> In-Reply-To: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] LDP DoD and PW Signalling ... Thread-Index: Acw0nZayI9OcF0gpR7qbFZfRRe6WPgAfV8uQ References: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> From: "Rajiv Asati (rajiva)" To: , , X-OriginalArrivalTime: 27 Jun 2011 23:10:08.0012 (UTC) FILETIME=[5B5F1CC0:01CC351F] Subject: Re: [PWE3] LDP DoD and PW Signalling ... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 23:10:15 -0000 Hi Nic, > For a more long term approach we are in favour of a change to RFC5036 by > defining a new TLV which denotes the DU/DoD mode per FEC type. You mean, define a new 'Common Session Parameters TLV' (in the initialization message) to denote the DU/DoD mode per FEC type? Or a new 'optional parameter' TLV (in the initialization message) to denote the same? Or simply a new capability? I hope that it is not the former. > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's Have we concluded that the above restriction in RFC4447 can not be relaxed? =20 Cheers, Rajiv > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > N.Leymann@telekom.de > Sent: Monday, June 27, 2011 3:41 AM > To: mpls@ietf.org; pwe3@ietf.org > Subject: [PWE3] LDP DoD and PW Signalling ... >=20 > Hi, >=20 > We came across an issue related to the Seamless MPLS Architecture when running > LDP DoD between two nodes if we are trying to set up an PW between the same > nodes. >=20 > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The AN > establishes a LDP DoD with the AG. When we are going to establish a PW between > the AN and the AG as well we run into the problem that RFC4447 specifies only > the DU mode for the targeted LDP session (section 3): >=20 > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > 'liberal label retention' mode SHOULD be used." >=20 > From our point of view we should reuse the existing LDP session and go with > only a single LDP session between AN and AG. That has the advantage that we do > not change the behaviour of PW FECs 128/129 (there are other options like > using two LDP sessions with additonal lookbacks or two sessions with single > loopback and LDP DoD for IP FECs, but those have an heavy - negative impact - > on the existing implementations and/or standards). >=20 > For a more long term approach we are in favour of a change to RFC5036 by > defining a new TLV which denotes the DU/DoD mode per FEC type. >=20 > Any comments on that? >=20 > Regards >=20 > Nic > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From lizhong.jin@zte.com.cn Mon Jun 27 18:26:51 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B38A21F8590; Mon, 27 Jun 2011 18:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jj6DlFtFozi; Mon, 27 Jun 2011 18:26:50 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7972121F84EC; Mon, 27 Jun 2011 18:26:48 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131322203882679; Tue, 28 Jun 2011 09:23:41 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 20345.3628770995; Tue, 28 Jun 2011 09:26:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5S1QQ8J018105; Tue, 28 Jun 2011 09:26:26 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: N.Leymann@telekom.de MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Tue, 28 Jun 2011 09:26:07 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-28 09:26:27, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-28 09:26:27, Serialize complete at 2011-06-28 09:26:27, S/MIME Sign failed at 2011-06-28 09:26:27: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-28 09:26:26, Serialize complete at 2011-06-28 09:26:26 Content-Type: multipart/alternative; boundary="=_alternative 0007EA36482578BD_=" X-MAIL: mse01.zte.com.cn p5S1QQ8J018105 Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] LDP DoD and PW Signalling ... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 01:26:51 -0000 This is a multipart message in MIME format. --=_alternative 0007EA36482578BD_= Content-Type: text/plain; charset="US-ASCII" Nic, It does seem an issue. Since PW in RFC4447 only supports DU mode, then PW could still work in DU whatever DU or DoD mode indicated by LDP initializtion message. And the mode indicated by LDP initializtion message would be valid for other FECs, not PW FEC. I agree for a long term, if there are two FECs supported both DU and DoD on one LDP session, then your proposal is a one good option. What's more, in RFC5036 section 3.5.3, it says: "If one LSR proposes Downstream Unsolicited and the other proposes Downstream on Demand, the rules for resolving this difference is: - If the session is for a label-controlled ATM link or a label-controlled Frame Relay link, then Downstream on Demand MUST be used. - Otherwise, Downstream Unsolicited MUST be used. If the label advertisement discipline determined in this way is unacceptable to an LSR, it MUST send a Session Rejected/Parameters Advertisement Mode Notification message in response to the Initialization message and not establish the session." That means if link between AN and AG is Ethernet, then session with DoD mode can not be established. I think we should also remove this restriction in 5036. Regards Lizhong > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 27 Jun 2011 09:41:13 +0200 > From: > To: , > Subject: [PWE3] LDP DoD and PW Signalling ... > Message-ID: > <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds. > t-internal.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi, > > We came across an issue related to the Seamless MPLS Architecture > when running LDP DoD between two nodes if we are trying to set up an > PW between the same nodes. > > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The > AN establishes a LDP DoD with the AG. When we are going to establish > a PW between the AN and the AG as well we run into the problem that > RFC4447 specifies only the DU mode for the targeted LDP session (section 3): > > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > 'liberal label retention' mode SHOULD be used." > > From our point of view we should reuse the existing LDP session and go with > only a single LDP session between AN and AG. That has the advantage that we > do not change the behaviour of PW FECs 128/129 (there are other options like > using two LDP sessions with additonal lookbacks or two sessions with single > loopback and LDP DoD for IP FECs, but those have an heavy - negative > impact - on the existing implementations and/or standards). > > For a more long term approach we are in favour of a change to RFC5036 by de- > fining a new TLV which denotes the DU/DoD mode per FEC type. > > Any comments on that? > > Regards > > Nic > > > ------------------------------ > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0007EA36482578BD_= Content-Type: text/html; charset="US-ASCII"
Nic,
It does seem an issue. Since PW in RFC4447 only supports DU mode, then PW could still work in DU whatever DU or DoD mode indicated by LDP initializtion message. And the mode indicated by LDP initializtion message would be valid for other FECs, not PW FEC. I agree for a long term, if there are two FECs supported both DU and DoD on one LDP session, then your proposal is a one good option.

What's more, in RFC5036 section 3.5.3, it says:
"If one LSR proposes Downstream Unsolicited and the other
proposes Downstream on Demand, the rules for resolving this
difference is:
- If the session is for a label-controlled ATM link or a
label-controlled Frame Relay link, then Downstream on Demand
MUST be used.
- Otherwise, Downstream Unsolicited MUST be used.
If the label advertisement discipline determined in this way
is unacceptable to an LSR, it MUST send a Session
Rejected/Parameters Advertisement Mode Notification message
in response to the Initialization message and not establish
the session."

That means if link between AN and AG is Ethernet, then session with DoD mode can not be established. I think we should also remove this restriction in 5036.

Regards
Lizhong


>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 27 Jun 2011 09:41:13 +0200
> From: <N.Leymann@telekom.de>
> To: <mpls@ietf.org>, <pwe3@ietf.org>
> Subject: [PWE3] LDP DoD and PW Signalling ...
> Message-ID:
>    <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.
> t-internal.com>
>    
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> We came across an issue related to the Seamless MPLS Architecture
> when running LDP DoD between two nodes if we are trying to set up an
> PW between the same nodes.
>
> Assume we have an Access Node (AN) and an Aggregation Mode (AG). The
> AN establishes a LDP DoD with the AG. When we are going to establish
> a PW between the AN and the AG as well we run into the problem that
> RFC4447 specifies only the DU mode for the targeted LDP session (section 3):
>
>    "An LDP session must be set up between the pseudowire endpoints.
>     LDP MUST be used in its 'downstream unsolicited' mode.  LDP's
>     'liberal label retention' mode SHOULD be used."
>
> From our point of view we should reuse the existing LDP session and go with
> only a single LDP session between AN and AG. That has the advantage that we
> do not change the behaviour of PW FECs 128/129 (there are other options like
> using two LDP sessions with additonal lookbacks or two sessions with single
> loopback and LDP DoD for IP FECs, but those have an heavy -  negative
> impact - on the existing implementations and/or standards).
>
> For a more long term approach we are in favour of a change to RFC5036 by de-
> fining a new TLV which denotes the DU/DoD mode per FEC type.
>
> Any comments on that?
>
>   Regards
>
>      Nic
>
>
> ------------------------------
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0007EA36482578BD_=-- From lmartini@cisco.com Mon Jun 27 21:56:20 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DAA21F85F1 for ; Mon, 27 Jun 2011 21:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY96Gfcb0GXC for ; Mon, 27 Jun 2011 21:56:20 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id E10DF21F8558 for ; Mon, 27 Jun 2011 21:56:19 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p5S4uJ1X002804 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 27 Jun 2011 22:56:19 -0600 (MDT) Message-ID: <4E095EF3.3050009@cisco.com> Date: Mon, 27 Jun 2011 22:56:19 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [PWE3] draft-ietf-pwe3-static-pw-status V 05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 04:56:20 -0000 Wg, and Chairs, I updated section 4 (Applicability) of the pseudowire status for Static pseudowires document according to coments made on the list. ( thanks Lizhong ) I believe we are ready to progress this document. Thanks. Luca From mach.chen@huawei.com Tue Jun 28 01:51:13 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5CC21F8625; Tue, 28 Jun 2011 01:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E75QKifL--K; Tue, 28 Jun 2011 01:51:13 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0149C21F8624; Tue, 28 Jun 2011 01:51:13 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNH003ENSLC60@szxga04-in.huawei.com>; Tue, 28 Jun 2011 16:51:12 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNH00D71SLCWL@szxga04-in.huawei.com>; Tue, 28 Jun 2011 16:51:12 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABO39116; Tue, 28 Jun 2011 16:51:11 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 28 Jun 2011 16:51:09 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.87]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Tue, 28 Jun 2011 16:51:11 +0800 Date: Tue, 28 Jun 2011 08:51:10 +0000 From: Mach Chen In-reply-to: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> X-Originating-IP: [10.110.98.37] To: "N.Leymann@telekom.de" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: LDP DoD and PW Signalling ... Thread-index: Acw0nZayI9OcF0gpR7qbFZfRRe6WPgAqnZYw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] LDP DoD and PW Signalling ... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 08:51:13 -0000 Hi Nic, IMHO, if we could category the existing FECs into two types: 1) Controlled by the LDP Session mode( e.g., IPv4/IPv6 FEC, P2MP/MP2MP FEC); 2). Independent of the LDP Session mode (e.g., FEC 128/129); then it just need to relax the restriction of FECs 128/129(the specific mode is determined by the FEC type and does not controlled by the session mode), and the issue in question could be solved easily. And from the view of implementation, it's easy to change the L2VPN module to relax the restriction. BTW, I know some implementations that have already done like this. Best regards, Mach > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > N.Leymann@telekom.de > Sent: Monday, June 27, 2011 3:41 PM > To: mpls@ietf.org; pwe3@ietf.org > Subject: [PWE3] LDP DoD and PW Signalling ... > > Hi, > > We came across an issue related to the Seamless MPLS Architecture when > running LDP DoD between two nodes if we are trying to set up an PW between > the same nodes. > > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The AN > establishes a LDP DoD with the AG. When we are going to establish a PW > between the AN and the AG as well we run into the problem that RFC4447 > specifies only the DU mode for the targeted LDP session (section 3): > > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > 'liberal label retention' mode SHOULD be used." > > From our point of view we should reuse the existing LDP session and go with > only a single LDP session between AN and AG. That has the advantage that we > do not change the behaviour of PW FECs 128/129 (there are other options like > using two LDP sessions with additonal lookbacks or two sessions with single > loopback and LDP DoD for IP FECs, but those have an heavy - negative impact > - on the existing implementations and/or standards). > > For a more long term approach we are in favour of a change to RFC5036 by > defining a new TLV which denotes the DU/DoD mode per FEC type. > > Any comments on that? > > Regards > > Nic > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From amalis@gmail.com Tue Jun 28 04:47:51 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3C621F85DE for ; Tue, 28 Jun 2011 04:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1G1zrF8NipL for ; Tue, 28 Jun 2011 04:47:50 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58F5521F85CB for ; Tue, 28 Jun 2011 04:47:50 -0700 (PDT) Received: by bwb17 with SMTP id 17so143171bwb.31 for ; Tue, 28 Jun 2011 04:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=9lIyvdqzRnaEKjnB4T6bLQUKQJwJD/GDGFhGlYWkAH0=; b=dS4PfRcYnOT6VQ5PHYXw3AMe4CZgzOUYRm79p33v7kV3YjSlnjUxriJcPJba0DF6XF 4I1uVHupP5T7XabMTBCG3Io0dQXo3gKMAfphqmfxTVkRsDoeuw0MOm1PdNivCaN0lKin QpWP0Qhy3PvE4QLel1L6kk5kJ21CsPcu7eyVE= Received: by 10.204.36.129 with SMTP id t1mr4024500bkd.193.1309261669286; Tue, 28 Jun 2011 04:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.52.75 with HTTP; Tue, 28 Jun 2011 04:47:29 -0700 (PDT) In-Reply-To: <4E095EF3.3050009@cisco.com> References: <4E095EF3.3050009@cisco.com> From: "Andrew G. Malis" Date: Tue, 28 Jun 2011 07:47:29 -0400 Message-ID: To: Luca Martini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pwe3 Subject: Re: [PWE3] draft-ietf-pwe3-static-pw-status V 05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 11:47:51 -0000 Luca, Thanks, I'll submit it to the IESG. Cheers, Andy On Tue, Jun 28, 2011 at 12:56 AM, Luca Martini wrote: > Wg, and Chairs, > > I updated section 4 (Applicability) of the =A0pseudowire status for Stati= c > pseudowires document according to coments made on the list. > ( thanks Lizhong ) > > I believe we are ready to progress this document. > Thanks. > Luca > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From lizhong.jin@zte.com.cn Tue Jun 28 19:05:50 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EE79E800A; Tue, 28 Jun 2011 19:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD0Q94QkPfpN; Tue, 28 Jun 2011 19:05:50 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2729E9E8004; Tue, 28 Jun 2011 19:05:48 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 48642203882679; Wed, 29 Jun 2011 10:04:40 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 51452.5226469288; Wed, 29 Jun 2011 10:05:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5T25SWU026570; Wed, 29 Jun 2011 10:05:28 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Kishore Tiruveedhula MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Wed, 29 Jun 2011 10:05:05 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-29 10:05:27, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-29 10:05:27, Serialize complete at 2011-06-29 10:05:27, S/MIME Sign failed at 2011-06-29 10:05:27: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-29 10:05:28, Serialize complete at 2011-06-29 10:05:28 Content-Type: multipart/alternative; boundary="=_alternative 000B7C71482578BE_=" X-MAIL: mse01.zte.com.cn p5T25SWU026570 Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] LDP DoD and PW Signalling ... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 02:05:51 -0000 This is a multipart message in MIME format. --=_alternative 000B7C71482578BE_= Content-Type: text/plain; charset="US-ASCII" Kishore, Yes, in that case, the session can be established. And then all the sessions over the AGN's link have to be DoD. Now I guess it is a rare case there are two sessions with different mode over one Ehternet link on AGN. Thanks Lizhong Kishore Tiruveedhula wrote on 2011-06-29 02:35:15: > That means if link between AN and AG is Ethernet, then session with > DoD mode can not be established. I think we should also remove this > restriction in 5036. > [Kishore] If both AN and AGN proposes the DOD, then DOD session can > be established over Ethernet. Right? > Thanks, > Kishore > > Regards > Lizhong > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 27 Jun 2011 09:41:13 +0200 > > From: > > To: , > > Subject: [PWE3] LDP DoD and PW Signalling ... > > Message-ID: > > <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds. > > t-internal.com> > > > > Content-Type: text/plain; charset="us-ascii" > > > > Hi, > > > > We came across an issue related to the Seamless MPLS Architecture > > when running LDP DoD between two nodes if we are trying to set up an > > PW between the same nodes. > > > > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The > > AN establishes a LDP DoD with the AG. When we are going to establish > > a PW between the AN and the AG as well we run into the problem that > > RFC4447 specifies only the DU mode for the targeted LDP session (section 3): > > > > "An LDP session must be set up between the pseudowire endpoints. > > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > > 'liberal label retention' mode SHOULD be used." > > > > From our point of view we should reuse the existing LDP session and go with > > only a single LDP session between AN and AG. That has the advantage that we > > do not change the behaviour of PW FECs 128/129 (there are other options like > > using two LDP sessions with additonal lookbacks or two sessions with single > > loopback and LDP DoD for IP FECs, but those have an heavy - negative > > impact - on the existing implementations and/or standards). > > > > For a more long term approach we are in favour of a change to RFC5036 by de- > > fining a new TLV which denotes the DU/DoD mode per FEC type. > > > > Any comments on that? > > > > Regards > > > > Nic > > > > > > ------------------------------ > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000B7C71482578BE_= Content-Type: text/html; charset="US-ASCII"
Kishore,
Yes, in that case, the session can be established. And then all the sessions over the AGN's link have to be DoD. Now I guess it is a rare case there are two sessions with different mode over one Ehternet link on AGN.

Thanks
Lizhong
 

Kishore Tiruveedhula <kishoret@juniper.net> wrote on 2011-06-29 02:35:15:

> That means if link between AN and AG is Ethernet, then session with
> DoD mode can not be established. I think we should also remove this
> restriction in 5036.

> [Kishore] If both AN and AGN proposes the DOD, then DOD session can
> be established over Ethernet. Right?
> Thanks,
> Kishore
>
> Regards
> Lizhong
>
>
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Mon, 27 Jun 2011 09:41:13 +0200
> > From: <N.Leymann@telekom.de>
> > To: <mpls@ietf.org>, <pwe3@ietf.org>
> > Subject: [PWE3] LDP DoD and PW Signalling ...
> > Message-ID:
> >    <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.
> > t-internal.com>
> >    
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Hi,
> >
> > We came across an issue related to the Seamless MPLS Architecture
> > when running LDP DoD between two nodes if we are trying to set up an
> > PW between the same nodes.
> >
> > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The
> > AN establishes a LDP DoD with the AG. When we are going to establish
> > a PW between the AN and the AG as well we run into the problem that
> > RFC4447 specifies only the DU mode for the targeted LDP session (section 3):
> >
> >    "An LDP session must be set up between the pseudowire endpoints.
> >     LDP MUST be used in its 'downstream unsolicited' mode.  LDP's
> >     'liberal label retention' mode SHOULD be used."
> >
> > From our point of view we should reuse the existing LDP session and go with
> > only a single LDP session between AN and AG. That has the advantage that we
> > do not change the behaviour of PW FECs 128/129 (there are other options like
> > using two LDP sessions with additonal lookbacks or two sessions with single
> > loopback and LDP DoD for IP FECs, but those have an heavy -  negative
> > impact - on the existing implementations and/or standards).
> >
> > For a more long term approach we are in favour of a change to RFC5036 by de-
> > fining a new TLV which denotes the DU/DoD mode per FEC type.
> >
> > Any comments on that?
> >
> >   Regards
> >
> >      Nic
> >
> >
> > ------------------------------
> >
>  
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000B7C71482578BE_=-- From maciek@juniper.net Wed Jun 29 00:51:05 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B0121F8537; Wed, 29 Jun 2011 00:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.359 X-Spam-Level: X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OK5tRb4Hm-3G; Wed, 29 Jun 2011 00:51:03 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40121F8532; Wed, 29 Jun 2011 00:50:59 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTgrZYhaF64Ef+p3bY+P4HcPEtB4Zf4nk@postini.com; Wed, 29 Jun 2011 00:51:02 PDT Received: from [172.26.205.106] (172.26.205.106) by smtp.juniper.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 29 Jun 2011 00:48:24 -0700 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Maciek Konstantynowicz In-Reply-To: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> Date: Wed, 29 Jun 2011 08:48:20 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <16DF3958-C763-4A39-AA34-3C7BCF18F99E@juniper.net> References: <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds.t-internal.com> To: Nicolai Leymann X-Mailer: Apple Mail (2.1081) Cc: mpls@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] LDP DoD and PW Signalling ... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:51:05 -0000 Nic, I don't believe this is a major issue. Proposed short term approach of using DoD mode (negotiated during LDP = session establishment per 'Common Session Parameters' TLV) for IP FECs = and fixed DU mode for PW FECs makes sense to me. I also agree that going forward we should consider introducing per FEC = type indication of label advertisement discipline. The least disruptive approach seems to be to amend rfc5036 and define a = new 'Optional Parameter' TLV in the LDP Initialization message to = indicate label advertisement discipline per FEC type, if different from = the one advertised in 'Common Session Parameters' TLV. Cheers, Maciek. On 27 Jun 2011, at 08:41, = wrote: > Hi, >=20 > We came across an issue related to the Seamless MPLS Architecture when = running LDP DoD between two nodes if we are trying to set up an PW = between the same nodes. >=20 > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The = AN establishes a LDP DoD with the AG. When we are going to establish a = PW between the AN and the AG as well we run into the problem that = RFC4447 specifies only the DU mode for the targeted LDP session (section = 3): >=20 > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > 'liberal label retention' mode SHOULD be used." >=20 > =46rom our point of view we should reuse the existing LDP session and = go with only a single LDP session between AN and AG. That has the = advantage that we do not change the behaviour of PW FECs 128/129 (there = are other options like using two LDP sessions with additonal lookbacks = or two sessions with single loopback and LDP DoD for IP FECs, but those = have an heavy - negative impact - on the existing implementations = and/or standards). >=20 > For a more long term approach we are in favour of a change to RFC5036 = by defining a new TLV which denotes the DU/DoD mode per FEC type. >=20 > Any comments on that? >=20 > Regards >=20 > Nic > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From matthew.bocci@alcatel-lucent.com Wed Jun 29 07:43:04 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032A09E803A for ; Wed, 29 Jun 2011 07:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGEGtYQOLUO4 for ; Wed, 29 Jun 2011 07:42:59 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1899E800D for ; Wed, 29 Jun 2011 07:42:59 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5TEdkip023110 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 29 Jun 2011 16:42:57 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 29 Jun 2011 16:42:25 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Wed, 29 Jun 2011 16:42:23 +0200 Thread-Topic: Changes to draft-ietf-pwe3-dynamic-ms-pw Thread-Index: Acw2asMklyusW3FmS5e0I0X2k5mm1g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA30F85F123FCmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [PWE3] Changes to draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 14:43:04 -0000 --_000_CA30F85F123FCmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While making some updates to the Dynamic Multi-Segment Pseudowire draft (dr= aft-ietf-pwe3-dynamic-ms-pw) to prepare it for WG last call, Luca and I hav= e come to the conclusion that we need to add a significant amount of text d= escribing the procedures for handling explicit routes and the applicability= of different ER techniques. The current draft defines the ER TLV, but not = how it is processed. In order to progress the current draft expeditiously, we think that it woul= d be better to split the ER TLV definition and procedures into a separate d= raft. We have discussed this with the chairs, and since this is being split out f= rom an existing working group draft, we would like to create a new working = group document from it rather than starting an individual draft and asking = for adoption. We would like to know if there are any concerns from the working group with= moving straight to a WG draft for the explicit route TLV definition and pr= ocedures. If you have any concerns, please let us and the chairs know. Regards, Matthew --_000_CA30F85F123FCmatthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
While making some u= pdates to the Dynamic Multi-Segment Pseudowire draft (draft-ietf-pwe3-dynam= ic-ms-pw) to prepare it for WG last call, Luca and I have come to the concl= usion that we need to add a significant amount of text describing the proce= dures for handling explicit routes and the applicability of different ER te= chniques. The current draft defines the ER TLV, but not how it is processed= . 

In order to progress the current draft exp= editiously, we think that it would be better to split the ER TLV definition= and procedures into a separate draft.

We ha= ve discussed this with the chairs, and since this is being split out from a= n existing working group draft, we would like to create a new working group= document from it rather than starting an individual draft and asking for a= doption.

We would like to know if there are any co= ncerns from the working group with moving straight to a WG draft for the ex= plicit route TLV definition and procedures.

If you= have any concerns, please let us and the chairs know.

=
Regards,

Matthew
--_000_CA30F85F123FCmatthewboccialcatellucentcom_-- From kishoret@juniper.net Tue Jun 28 11:38:49 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB1911E811A; Tue, 28 Jun 2011 11:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuLEDqYk1B4J; Tue, 28 Jun 2011 11:38:47 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 0991E11E80EE; Tue, 28 Jun 2011 11:38:40 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTgofqwhYHoXplr5yf4kctVmn4miFXFNQ@postini.com; Tue, 28 Jun 2011 11:38:45 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 28 Jun 2011 11:35:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 28 Jun 2011 14:35:16 -0400 From: Kishore Tiruveedhula To: "lizhong.jin@zte.com.cn" , "N.Leymann@telekom.de" Date: Tue, 28 Jun 2011 14:35:15 -0400 Thread-Topic: [mpls] [PWE3] LDP DoD and PW Signalling ... Thread-Index: Acw1MpfrB9L9SCAqTImcEs1XcwLRqgAjTVvA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A0F87AA600EF73468BA3741CFF49DE4F0363DFDCE6ADEMBX01WFjnp_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 29 Jun 2011 08:02:04 -0700 Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] LDP DoD and PW Signalling ... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 18:38:49 -0000 --_000_A0F87AA600EF73468BA3741CFF49DE4F0363DFDCE6ADEMBX01WFjnp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That means if link between AN and AG is Ethernet, then session with DoD mod= e can not be established. I think we should also remove this restriction in= 5036. [Kishore] If both AN and AGN proposes the DOD, then DOD session can be esta= blished over Ethernet. Right? Thanks, Kishore Regards Lizhong > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 27 Jun 2011 09:41:13 +0200 > From: > To: , > Subject: [PWE3] LDP DoD and PW Signalling ... > Message-ID: > <9762ACF04FA26B4388476841256BDE0201151F467921@HE111543.emea1.cds. > t-internal.com> > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi, > > We came across an issue related to the Seamless MPLS Architecture > when running LDP DoD between two nodes if we are trying to set up an > PW between the same nodes. > > Assume we have an Access Node (AN) and an Aggregation Mode (AG). The > AN establishes a LDP DoD with the AG. When we are going to establish > a PW between the AN and the AG as well we run into the problem that > RFC4447 specifies only the DU mode for the targeted LDP session (section = 3): > > "An LDP session must be set up between the pseudowire endpoints. > LDP MUST be used in its 'downstream unsolicited' mode. LDP's > 'liberal label retention' mode SHOULD be used." > > From our point of view we should reuse the existing LDP session and go wi= th > only a single LDP session between AN and AG. That has the advantage that = we > do not change the behaviour of PW FECs 128/129 (there are other options l= ike > using two LDP sessions with additonal lookbacks or two sessions with sing= le > loopback and LDP DoD for IP FECs, but those have an heavy - negative > impact - on the existing implementations and/or standards). > > For a more long term approach we are in favour of a change to RFC5036 by = de- > fining a new TLV which denotes the DU/DoD mode per FEC type. > > Any comments on that? > > Regards > > Nic > > > ------------------------------ > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_A0F87AA600EF73468BA3741CFF49DE4F0363DFDCE6ADEMBX01WFjnp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That means if link between AN and AG is Ethernet, then session= with DoD mode can not be established. I think we should also remove this r= estriction in 5036.

[Kishore] If both AN and AGN proposes the DOD, then DOD ses= sion can be established over Ethernet. Right?

Thanks,

Kishore


Regards
Lizhong


>
&= gt; ----------------------------------------------------------------------<= /tt>
>
> Message: 1
> Date: Mon, 2= 7 Jun 2011 09:41:13 +0200
> From: <N.Leymann@telekom.de&g= t;
> To: <mpls@ietf.org>, <pwe3@ietf.org>> Subject: [PWE3] LDP DoD and PW Signalling ...
> M= essage-ID:
>    <9762ACF04FA26B4388476841256BDE= 0201151F467921@HE111543.emea1.cds.
> t-internal.com>=
>    
> Content-Type: text/plain; chars= et=3D"us-ascii"
>
> Hi,
>
> We came across an issue related to the Seamless MP= LS Architecture
> when running LDP DoD between two nodes if= we are trying to set up an
> PW between the same nodes.
>
> Assume we have an Access Node (AN) and an A= ggregation Mode (AG). The
> AN establishes a LDP DoD with th= e AG. When we are going to establish
> a PW between the AN a= nd the AG as well we run into the problem that
> RFC4447 sp= ecifies only the DU mode for the targeted LDP session (section 3):
= >
>    "An LDP session must be set up= between the pseudowire endpoints.
>     LDP MUST = be used in its 'downstream unsolicited' mode.  LDP's
> =     'liberal label retention' mode SHOULD be used."
= >
> From our point of view we should reuse the exist= ing LDP session and go with
> only a single LDP session between AN and AG. That has the advant= age that we
> do not change the behaviour of PW FECs 128/129 (there = are other options like
> using two LDP sessions with additon= al lookbacks or two sessions with single
> loopback and LDP = DoD for IP FECs, but those have an heavy -  negative
>= impact - on the existing implementations and/or standards).
&g= t;
> For a more long term approach we are in favour of a ch= ange to RFC5036 by de-
> fining a new TLV which denotes the = DU/DoD mode per FEC type.
>
> Any comments o= n that?
>
>   Regards
> =
>      Nic
>
>= ;
> ------------------------------
> 

 
----------------------=
----------------------------------
ZTE Informatio=
n Security Notice: The information contained =
in this mail is solely property of the&n=
bsp;sender's organization. This mail communication =
;is confidential. Recipients named above are =
obligated to maintain secrecy and are not&nbs=
p;permitted to disclose the contents of this&=
nbsp;communication to others.
This emai=
l and any files transmitted with it are&=
nbsp;confidential and intended solely for the =
;use of the individual or entity to whom=
 they are addressed. If you have receive=
d this email in error please notify the&=
nbsp;originator of the message. Any views exp=
ressed in this message are those of the&=
nbsp;individual sender.
This message ha=
s been scanned for viruses and Spam by&n=
bsp;ZTE Anti-Spam system.
= --_000_A0F87AA600EF73468BA3741CFF49DE4F0363DFDCE6ADEMBX01WFjnp_-- From lizhong.jin@zte.com.cn Wed Jun 29 20:29:48 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF6521F8632 for ; Wed, 29 Jun 2011 20:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQHOw+z5LOhf for ; Wed, 29 Jun 2011 20:29:48 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8684E21F862E for ; Wed, 29 Jun 2011 20:29:47 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641397396305; Thu, 30 Jun 2011 11:28:35 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.2368962204; Thu, 30 Jun 2011 11:29:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5U3TeUi039415; Thu, 30 Jun 2011 11:29:40 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: matthew.bocci@alcatel-lucent.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Thu, 30 Jun 2011 11:29:12 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-30 11:29:40, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-30 11:29:40, Serialize complete at 2011-06-30 11:29:40, S/MIME Sign failed at 2011-06-30 11:29:40: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-30 11:29:41, Serialize complete at 2011-06-30 11:29:41 Content-Type: multipart/alternative; boundary="=_alternative 00133227482578BF_=" X-MAIL: mse01.zte.com.cn p5U3TeUi039415 Cc: pwe3@ietf.org Subject: Re: [PWE3] Changes to draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 03:29:49 -0000 This is a multipart message in MIME format. --=_alternative 00133227482578BF_= Content-Type: text/plain; charset="US-ASCII" Hi Matthew, I agree with to be WG draft. But I would like to know what kind of Explicit Route TLV that would be defined in the new draft. In draft-ietf-pwe3-dynamic-ms-pw, the defined format is from RFC3212 which has been deprecated by RFC 3468. Such kind of normative reference may be not appropriate. Thanks Lizhong > > ------------------------------ > > Message: 3 > Date: Wed, 29 Jun 2011 16:42:23 +0200 > From: "Bocci, Matthew (Matthew)" > To: "pwe3@ietf.org" > Subject: [PWE3] Changes to draft-ietf-pwe3-dynamic-ms-pw > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > While making some updates to the Dynamic Multi-Segment Pseudowire > draft (draft-ietf-pwe3-dynamic-ms-pw) to prepare it for WG last > call, Luca and I have come to the conclusion that we need to add a > significant amount of text describing the procedures for handling > explicit routes and the applicability of different ER techniques. > The current draft defines the ER TLV, but not how it is processed. > > In order to progress the current draft expeditiously, we think that > it would be better to split the ER TLV definition and procedures > into a separate draft. > > We have discussed this with the chairs, and since this is being > split out from an existing working group draft, we would like to > create a new working group document from it rather than starting an > individual draft and asking for adoption. > > We would like to know if there are any concerns from the working > group with moving straight to a WG draft for the explicit route TLV > definition and procedures. > > If you have any concerns, please let us and the chairs know. > > Regards, > > Matthew > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/pwe3/attachments/20110629/076522f4/attachment.htm> > > ------------------------------ > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00133227482578BF_= Content-Type: text/html; charset="US-ASCII"
Hi Matthew,
I agree with to be WG draft. But I would like to know what kind of Explicit Route TLV that would be defined in the new draft. In draft-ietf-pwe3-dynamic-ms-pw, the defined format is from RFC3212 which has been deprecated by RFC 3468. Such kind of normative reference may be not appropriate.

Thanks
Lizhong


>
> ------------------------------
>
> Message: 3
> Date: Wed, 29 Jun 2011 16:42:23 +0200
> From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
> To: "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: [PWE3] Changes to draft-ietf-pwe3-dynamic-ms-pw
> Message-ID: <CA30F85F.123FC%matthew.bocci@alcatel-lucent.com>
> Content-Type: text/plain; charset="us-ascii"
>
> While making some updates to the Dynamic Multi-Segment Pseudowire
> draft (draft-ietf-pwe3-dynamic-ms-pw) to prepare it for WG last
> call, Luca and I have come to the conclusion that we need to add a
> significant amount of text describing the procedures for handling
> explicit routes and the applicability of different ER techniques.
> The current draft defines the ER TLV, but not how it is processed.
>
> In order to progress the current draft expeditiously, we think that
> it would be better to split the ER TLV definition and procedures
> into a separate draft.
>
> We have discussed this with the chairs, and since this is being
> split out from an existing working group draft, we would like to
> create a new working group document from it rather than starting an
> individual draft and asking for adoption.
>
> We would like to know if there are any concerns from the working
> group with moving straight to a WG draft for the explicit route TLV
> definition and procedures.
>
> If you have any concerns, please let us and the chairs know.
>
> Regards,
>
> Matthew
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/pwe3/attachments/20110629/076522f4/attachment.htm>
>
> ------------------------------
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00133227482578BF_=-- From matthew.bocci@alcatel-lucent.com Thu Jun 30 03:47:32 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E902621F867D for ; Thu, 30 Jun 2011 03:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8y98n6xMEcfc for ; Thu, 30 Jun 2011 03:47:32 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7812221F8643 for ; Thu, 30 Jun 2011 03:47:30 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5UAkP3n001106 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jun 2011 12:47:26 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 30 Jun 2011 12:47:11 +0200 From: "Bocci, Matthew (Matthew)" To: "lizhong.jin@zte.com.cn" Date: Thu, 30 Jun 2011 12:47:08 +0200 Thread-Topic: [PWE3] Changes to draft-ietf-pwe3-dynamic-ms-pw Thread-Index: Acw3ExDYSXVeQXnnQTK64fxnLLjDeQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA32108E12580matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Changes to draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 10:47:33 -0000 --_000_CA32108E12580matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lizhong, Yes, I agree with you. We did copy the format of the ER TLV across from the= RFC and remove the reference, but somehow that version of the draft did no= t get posted yet. I think we need to do the following in the new draft: * Include a fully specified ER TLV based on the existing TLV and code po= ints, and remove any reference to RFC3212. * Add a sub-TLV to enable S-PE L2 addresses to be carried. * Explicitly specify the procedures for using the TLV. Best regards, Matthew On 30/06/2011 04:29, "lizhong.jin@zte.com.cn= " > wrote: Hi Matthew, I agree with to be WG draft. But I would like to know what kind of Explicit= Route TLV that would be defined in the new draft. In draft-ietf-pwe3-dynam= ic-ms-pw, the defined format is from RFC3212 which has been deprecated by R= FC 3468. Such kind of normative reference may be not appropriate. Thanks Lizhong > > ------------------------------ > > Message: 3 > Date: Wed, 29 Jun 2011 16:42:23 +0200 > From: "Bocci, Matthew (Matthew)" > > To: "pwe3@ietf.org" > > Subject: [PWE3] Changes to draft-ietf-pwe3-dynamic-ms-pw > Message-ID: > > Content-Type: text/plain; charset=3D"us-ascii" > > While making some updates to the Dynamic Multi-Segment Pseudowire > draft (draft-ietf-pwe3-dynamic-ms-pw) to prepare it for WG last > call, Luca and I have come to the conclusion that we need to add a > significant amount of text describing the procedures for handling > explicit routes and the applicability of different ER techniques. > The current draft defines the ER TLV, but not how it is processed. > > In order to progress the current draft expeditiously, we think that > it would be better to split the ER TLV definition and procedures > into a separate draft. > > We have discussed this with the chairs, and since this is being > split out from an existing working group draft, we would like to > create a new working group document from it rather than starting an > individual draft and asking for adoption. > > We would like to know if there are any concerns from the working > group with moving straight to a WG draft for the explicit route TLV > definition and procedures. > > If you have any concerns, please let us and the chairs know. > > Regards, > > Matthew > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/pwe3/attachments/20110629/076522f4/attachment.htm> > > ------------------------------ > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_CA32108E12580matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Lizhong,
Yes, I agree with you. We did copy the format of the ER TLV ac= ross from the RFC and remove the reference, but somehow that version of the= draft did not get posted yet. 

I think we ne= ed to do the following in the new draft:
  • Include a fully speci= fied ER TLV based on the existing TLV and code points, and remove any refer= ence to RFC3212. 
  • Add a sub-TLV to enable S-PE L2 addresses to= be carried.
  • Explicitly specify the procedures for using the TLV.
Best regards,

Matthew

<= /div>
On 30/06/2011 04:29, "lizhong.jin@zte.com.cn" <lizhong.jin@zte.com.cn> wrote:<= /div>


Hi Matthew,
I agree with to be WG draft. But I would like to know what kind of Explicit Route TLV that would be defined in the new draft. In draft-ietf-pwe3-dynamic-ms-pw, the defined format is from RFC3212 which has been deprecated by RFC 3468. Such kind of normative refer= ence may be not appropriate.

= Thanks
Lizhong

>
> ------------------------------
>
> Message: 3
> Date: Wed, 29 Jun 2011 16:42:23 +0200
> From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
> To: "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: [PWE3] Changes to draft-ietf-pwe3-dynamic-ms-pw
> Message-ID: <CA30F85F.123FC%matthew.bocci@alcatel-lucent.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> While making some updates to the Dynamic Multi-Segment Pseudowire
> draft (draft-ietf-pwe3-dynamic-ms-pw) to prepare it for WG last
> call, Luca and I have come to the conclusion that we need to add a
> significant amount of text describing the procedures for handling
> explicit routes and the applicability of different ER techniques.
> The current draft defines the ER TLV, but not how it is processed.
= >
> In order to progress the current draft expeditiously, we think that
> it would be better to split the ER TLV definition and procedures
> into a separate draft.
>
> We have discussed this with the chairs, and since this is being
> split out from an existing working group draft, we would like to
> create a new working group document from it rather than starting an
> individual draft and asking for adoption.
>
> We would like to know if there are any concerns from the working
> group with moving straight to a WG draft for the explicit route TLV
> definition and procedures.
>
> If you have any concerns, please let us and the chairs know.
>
> Regards,
>
> Matthew
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mai= l-
> archive/web/pwe3/attachments/20110629/076522f4/attachment.htm>
>
> ------------------------------
> 
-------------------------------------------------=
-------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--_000_CA32108E12580matthewboccialcatellucentcom_-- From lizhong.jin@zte.com.cn Thu Jun 30 05:14:15 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948E59E8007 for ; Thu, 30 Jun 2011 05:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+RjDBn7lPA7 for ; Thu, 30 Jun 2011 05:14:14 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 218CC9E8005 for ; Thu, 30 Jun 2011 05:14:13 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131321397396305; Thu, 30 Jun 2011 20:10:38 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.2368962204; Thu, 30 Jun 2011 20:14:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p5UCDrhN019808; Thu, 30 Jun 2011 20:13:53 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: "Bocci, Matthew (Matthew)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Thu, 30 Jun 2011 20:13:26 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-30 20:13:55, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-06-30 20:13:55, Serialize complete at 2011-06-30 20:13:55, S/MIME Sign failed at 2011-06-30 20:13:55: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-30 20:13:56, Serialize complete at 2011-06-30 20:13:56 Content-Type: multipart/alternative; boundary="=_alternative 00433140482578BF_=" X-MAIL: mse02.zte.com.cn p5UCDrhN019808 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Changes to draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 12:14:15 -0000 This is a multipart message in MIME format. --=_alternative 00433140482578BF_= Content-Type: text/plain; charset="US-ASCII" Hi Matthew, That would be good. Thank you for the clarification. Regards Lizhong "Bocci, Matthew (Matthew)" wrote on 2011-06-30 18:47:08: > Hi Lizhong, > > Yes, I agree with you. We did copy the format of the ER TLV across > from the RFC and remove the reference, but somehow that version of > the draft did not get posted yet. > > I think we need to do the following in the new draft: > Include a fully specified ER TLV based on the existing TLV and code > points, and remove any reference to RFC3212. > Add a sub-TLV to enable S-PE L2 addresses to be carried. > Explicitly specify the procedures for using the TLV. > Best regards, > > Matthew > > On 30/06/2011 04:29, "lizhong.jin@zte.com.cn" wrote: > > > Hi Matthew, > I agree with to be WG draft. But I would like to know what kind of > Explicit Route TLV that would be defined in the new draft. In draft- > ietf-pwe3-dynamic-ms-pw, the defined format is from RFC3212 which > has been deprecated by RFC 3468. Such kind of normative reference > may be not appropriate. > > Thanks > Lizhong > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 29 Jun 2011 16:42:23 +0200 > > From: "Bocci, Matthew (Matthew)" > > To: "pwe3@ietf.org" > > Subject: [PWE3] Changes to draft-ietf-pwe3-dynamic-ms-pw > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > > > While making some updates to the Dynamic Multi-Segment Pseudowire > > draft (draft-ietf-pwe3-dynamic-ms-pw) to prepare it for WG last > > call, Luca and I have come to the conclusion that we need to add a > > significant amount of text describing the procedures for handling > > explicit routes and the applicability of different ER techniques. > > The current draft defines the ER TLV, but not how it is processed. > > > > In order to progress the current draft expeditiously, we think that > > it would be better to split the ER TLV definition and procedures > > into a separate draft. > > > > We have discussed this with the chairs, and since this is being > > split out from an existing working group draft, we would like to > > create a new working group document from it rather than starting an > > individual draft and asking for adoption. > > > > We would like to know if there are any concerns from the working > > group with moving straight to a WG draft for the explicit route TLV > > definition and procedures. > > > > If you have any concerns, please let us and the chairs know. > > > > Regards, > > > > Matthew > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > archive/web/pwe3/attachments/20110629/076522f4/attachment.htm> > > > > ------------------------------ > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00433140482578BF_= Content-Type: text/html; charset="US-ASCII"
Hi Matthew,
That would be good. Thank you for the clarification.
Regards
Lizhong
 

"Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com> wrote on 2011-06-30 18:47:08:

> Hi Lizhong,
>
> Yes, I agree with you. We did copy the format of the ER TLV across
> from the RFC and remove the reference, but somehow that version of
> the draft did not get posted yet.
>
> I think we need to do the following in the new draft:
> Include a fully specified ER TLV based on the existing TLV and code
> points, and remove any reference to RFC3212.
> Add a sub-TLV to enable S-PE L2 addresses to be carried.
> Explicitly specify the procedures for using the TLV.
> Best regards,
>
> Matthew
>
> On 30/06/2011 04:29, "lizhong.jin@zte.com.cn" <lizhong.jin@zte.com.cn> wrote:
>
>
> Hi Matthew,
> I agree with to be WG draft. But I would like to know what kind of
> Explicit Route TLV that would be defined in the new draft. In draft-
> ietf-pwe3-dynamic-ms-pw, the defined format is from RFC3212 which
> has been deprecated by RFC 3468. Such kind of normative reference
> may be not appropriate.
>
> Thanks
> Lizhong
>
>
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 29 Jun 2011 16:42:23 +0200
> > From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
> > To: "pwe3@ietf.org" <pwe3@ietf.org>
> > Subject: [PWE3] Changes to draft-ietf-pwe3-dynamic-ms-pw
> > Message-ID: <CA30F85F.123FC%matthew.bocci@alcatel-lucent.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > While making some updates to the Dynamic Multi-Segment Pseudowire
> > draft (draft-ietf-pwe3-dynamic-ms-pw) to prepare it for WG last
> > call, Luca and I have come to the conclusion that we need to add a
> > significant amount of text describing the procedures for handling
> > explicit routes and the applicability of different ER techniques.
> > The current draft defines the ER TLV, but not how it is processed.
> >
> > In order to progress the current draft expeditiously, we think that
> > it would be better to split the ER TLV definition and procedures
> > into a separate draft.
> >
> > We have discussed this with the chairs, and since this is being
> > split out from an existing working group draft, we would like to
> > create a new working group document from it rather than starting an
> > individual draft and asking for adoption.
> >
> > We would like to know if there are any concerns from the working
> > group with moving straight to a WG draft for the explicit route TLV
> > definition and procedures.
> >
> > If you have any concerns, please let us and the chairs know.
> >
> > Regards,
> >
> > Matthew
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://www.ietf.org/mail-
> > archive/web/pwe3/attachments/20110629/076522f4/attachment.htm>
> >
> > ------------------------------
> > 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00433140482578BF_=-- From matthew.bocci@alcatel-lucent.com Thu Jun 30 10:06:01 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40F111E809E for ; Thu, 30 Jun 2011 10:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xja6K+wKEoyc for ; Thu, 30 Jun 2011 10:06:00 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id AE97111E8075 for ; Thu, 30 Jun 2011 10:05:59 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5UH5vRX026171 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 30 Jun 2011 19:05:57 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 30 Jun 2011 19:05:57 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Thu, 30 Jun 2011 19:05:54 +0200 Thread-Topic: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt Thread-Index: Acw3R/pNUcFrsWlpTzeTG9DEfgNJog== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA3269D612690matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:06:01 -0000 --_000_CA3269D612690matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have a new WG draft. Authors: please upload the next version as draft-ietf-pwe3-mpls-tp-ms-pw-00= .txt Regards Matthew > Message: 2 > Date: Thu, 2 Jun 2011 11:12:42 +0200 > From: "Bocci, Matthew (Matthew)" > > To: "pwe3@ietf.org" > > Subject: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt > Message-ID: > > Content-Type: text/plain; charset=3D"us-ascii" > > The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have > requested that this draft be adopted as a PWE3 working group draft. > > This email begins a two week poll of the list to help judge if there > is consensus to adopt the draft. > > Please review the draft and reply to the PWE3 list stating whether > you support adoption, together with any comments. > > Regards, > > Matthew --_000_CA3269D612690matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We have a new WG draft.<= /div>

Authors: please upload the next version as draft-i= etf-pwe3-mpls-tp-ms-pw-00.txt

Regards
Matthew

=

> Message: 2
> Date: Thu, 2 Jun 2011 11:12:42 +0200
> From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
> To: "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: [PWE3] WG Poll for draft-boutros-pwe3-mpls-tp-ms-pw-01.txt > Message-ID: <CA0D129A.10507%matthew.bocci@alcatel-lucent.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> The authors of draft-boutros-pwe3-mpls-tp-ms-pw-01.txt have
> requested that this draft be adopted as a PWE3 working group draft. >
> This email begins a two week poll of the list to help judge if there > is consensus to adopt the draft.
>
> Please review the draft and reply to the PWE3 list stating whether
> you support adoption, together with any comments.
>
> Regards,
>
> Matthew

--_000_CA3269D612690matthewboccialcatellucentcom_-- From matthew.bocci@alcatel-lucent.com Thu Jun 30 10:07:50 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C7D11E8236 for ; Thu, 30 Jun 2011 10:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.248 X-Spam-Level: X-Spam-Status: No, score=-104.248 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY4f9XPqOV3Z for ; Thu, 30 Jun 2011 10:07:50 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 18E3011E809E for ; Thu, 30 Jun 2011 10:07:49 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5UH7lrN026067 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 30 Jun 2011 19:07:48 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 30 Jun 2011 19:07:47 +0200 From: "Bocci, Matthew (Matthew)" To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Thu, 30 Jun 2011 19:07:44 +0200 Thread-Topic: [PWE3] Poll for WG adoption of draft-raza-pwe3-pw-typed-wc-fec-01.txt Thread-Index: Acw3SDwVTIxVNz+FRHOJUn01s91UcA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA326BBC126A3matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [PWE3] Poll for WG adoption of draft-raza-pwe3-pw-typed-wc-fec-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:07:50 -0000 --_000_CA326BBC126A3matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have a new WG draft. Authors: please upload the next version as draft-ietf-pwe3-pw-typed-wc-fec-= 00.txt Regards Matthew On 14/06/2011 14:40, "Bocci, Matthew (Matthew)" > wrote: The authors of draft-raza-pwe3-pw-typed-wc-fec-01 have requested that this = draft be adopted by the PWE3 working group. This email begins a two week poll of the list to help judge the consensus f= or this. Please send any comments to the PWE3 list by Tuesday 16th June 2011. Regards, Matthew and Andy --_000_CA326BBC126A3matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We have a new WG draft.<= /div>

Authors: please upload the next version as dr= aft-ietf-pwe3-pw-typed-wc-fec-00.txt

Regards
=

Matthew

On 14/06/2011 14:40, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.= com> wrote:

The authors of&nb= sp;draft-raza-pwe3-pw-typed-wc-fec-01 have requested that this draft be ado= pted by the PWE3 working group.

This email begins = a two week poll of the list to help judge the consensus for this.

Please send any comments to the PWE3 list by Tuesday 16th J= une 2011.

Regards,

Matthe= w and Andy

--_000_CA326BBC126A3matthewboccialcatellucentcom_-- From internet-drafts@ietf.org Thu Jun 30 10:10:45 2011 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C5011E8255; Thu, 30 Jun 2011 10:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVGZ0J0dqR-N; Thu, 30 Jun 2011 10:10:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0D111E8260; Thu, 30 Jun 2011 10:10:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110630171044.2796.17306.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 10:10:44 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:10:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : LDP Typed Wildcard FEC for the PW FEC Elements Author(s) : Kamran Raza Sami Boutros Carlos Pignataro Filename : draft-ietf-pwe3-pw-typed-wc-fec-00.txt Pages : 8 Date : 2011-06-30 The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80), Generalized PWid (0x81), and P2MP PW (0x82) FEC element types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-00.txt