From Robert.Rennison@ecitele.com Mon Aug 1 09:30: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 2D7DA21F8E2F for ; Mon, 1 Aug 2011 09:30:25 -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.000, 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 INIJ-ASLSBlZ for ; Mon, 1 Aug 2011 09:30:23 -0700 (PDT) Received: from uspitbmg01-out.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by ietfa.amsl.com (Postfix) with ESMTP id CBCB421F8C43 for ; Mon, 1 Aug 2011 09:30:22 -0700 (PDT) X-AuditID: 3f5e7f87-b7bd6ae000001292-37-4e363763212b Received: from uspitexch02.ecitele.com ( [10.0.0.72]) by uspitbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 38.50.04754.367363E4; Mon, 1 Aug 2011 01:19:31 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.81]) by uspitexch02.ecitele.com ([10.0.0.72]) with mapi; Sun, 31 Jul 2011 22:40:07 -0400 From: Robert Rennison To: Alexander Vainshtein , Yaakov Stein , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Sun, 31 Jul 2011 22:40:02 -0400 Thread-Topic: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxNUHyDZAbasUF1Qk6dQX1EkI++NAAOE9QwAGzyndwALZIXwA== Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE546BB897A55C@USPITMAIL01.ecitele.com> References: , <07F7D7DED63154409F13298786A2ADC903E8FD81@EXRAD5.ad.rad.co.il> 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_786AD2EC3D80A1428B921CDC9BE9EE546BB897A55CUSPITMAIL01ec_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOJsWRmVeSWpSXmKPExsXCxcDgoZtsbuZnsGuqjMXhrruMFn2ftrBY fOj6werA7NH6bC+rx5IlP5k8Jq1NC2COamC0SczLyy9JLElVSEktTrZVCijKLEtMrlRSyEyx VTJUUijISUxOzU3NK7FVSiwoSM1LUbLjUsAANkBlmXkKqXnJ+SmZeem2Sp7B/roWFqaWuoZK dmrKhsbWXCEZmcUKqbq5iZk5CrmpxcWJ6akKQJGELcwZC5feYi+YXF1x9fhD1gbGI7ldjJwc EgImEu9OnGKCsMUkLtxbzwZiCwnsZpTYt0i3i5ELyO5hlNi6bxMjSIJNwFhiw6ezrCAJEYED jBIty3eCJVgEVCVONLWzg9jCAi4SVw+cBYuLCLhKvJ46mQXCdpJYu7MBrIZXIEDi94c9LBAb jjJKLO75A9bACZRYsP0EM4jNCHTS91NrwM5jFhCXuPVkPtSpAhJL9pxnhrBFJV4+/scKUS8q cad9PSNEfb7E5V+zmCGWCUqcnPmEZQKjyCwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZ A4+ZkMUXMLKvYhQrLS7ILEnKTTcw1EtNzixJzUnVS87P3cQITC/2cfXtOxj7p2gdYpTkYFIS 5bUTMPMT4kvKT6nMSCzOiC8qzUktPsToCgzFicxS3Mn5wLSWVxJvbGCAm6MkzruzY4mvkEA6 MFllp6YWpBbBzJHh4FCS4F0jCLRDsCg1PbUiLTOnBCHNxMF5iFGCg0dJhHc+SA1vcUFibnFm OkT+FKMqx9HOY0cZhVjy8vNSpcR5W0GKBECKMkrz4Oa8YhTnYFQS5j3PDpTlAeYOuAmvgIYz AQ2P+GUCMhyY7OFSUg2MQWlJ4cHiG21i2hdZ1gbqrhG3fm7sc/uZ3M2ddk8W63mYCK1x8LoQ d+iWdquA36WT/fF1L6RjnPXYxVKsb30o6jtUIi4id0Bh9ZXlq9+9NNrlcHuW/GlmhkzuRpU5 Lq4z95bsCDFtCvvAsdk45BeXa97RT9OsMuX19VpOXZE/tDL70qY9ziFKLMUZiYZazEXFiQB1 uyH+2gMAAA== Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 01 Aug 2011 16:30:25 -0000 --_000_786AD2EC3D80A1428B921CDC9BE9EE546BB897A55CUSPITMAIL01ec_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable I do Not support the draft, After hearing the results of the earlier user deployment poll I thought, "= ok the way out of this mess is to migrate towards using the CW". Then I se= e this proposal and wondered what am I missing. I've still not seen the lig= ht of why adding a fourth type will simplify matters, hence in the absence o= f me understanding how this will simplify matter versus complicate things, I= 'm against it. Rob From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Alex= ander Vainshtein Sent: Sunday, July 31, 2011 12:45 AM To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Hi all, I do NOT support this draft for the same reasons that Yaakov has indicated. Regards, Sasha ________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stei= n [yaakov_s@rad.com] Sent: Friday, July 29, 2011 3:58 AM To: Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt I do not support ! and I can not understand how anyone can support it ! We do NOT need a fourth VCCV type, there are too many already. I completely agree with the part that says if there is a CW then the ACh sho= uld be marked by it. I do NOT agree that if the CW is not used then we should use a non-PW method= developed for MPLS-TP. I do NOT agree that there is any way to deprecate the use of TTL expiry to m= ark the ACh. I do NOT agree that we should change mechanisms that have been widely deploy= ed for many years now, without an extremely pressing reason. Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the= ADDITIONAL option for ACh marking, I might be convinced not to object as strongly. However, since I don't think that PWs can be limited in this matter (the MPL= S WG adopted the "seamless" draft) it would be difficult to convince me that such a limitation is possible. I would have enthusiastically support this proposal had it been brought 8 ye= ars ago. It's too late for this now. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocc= i, Matthew (Matthew) Sent: Thursday, July 28, 2011 21:02 To: pwe3@ietf.org Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt This email begins a two week poll to help assess if there is consensus to ad= opt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. Please indicate whether or not you support adoption of this draft, and also= send any comments to the PWE3 list. This poll will end on Friday 12th August. 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. 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_786AD2EC3D80A1428B921CDC9BE9EE546BB897A55CUSPITMAIL01ec_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

I do Not sup= port the draft,

 <= /o:p>

After hearing the results of the= earlier user deployment  poll I thought, “ ok  the way out= of this mess is to migrate towards using the CW”. Then I see this pro= posal and wondered what am I missing.  I’ve still not seen the li= ght of why adding a fourth type will simplify matters, hence in the absence= of me understanding how this will simplify matter versus complicate things,= I’m against it.

=  

Rob

<= p class=3DMsoNormal> 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Be= half Of Alexander Vainshtein
Sent: Sunday, July 31, 2011 12:45= AM
To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org
<= b>Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-0= 2.txt

 

Hi all,=

I do NOT support this draft for the same reasons that Yaakov has indicated.=

 

Regards,

     Sasha

 

From: pwe3-bounces@ietf.org [p= we3-bounces@ietf.org] On Behalf Of Yaakov Stein [yaakov_s@rad.com]
Sen= t: Friday, July 29, 2011 3:58 AM
To: Bocci, Matthew (Matthew);= pwe3@ietf.org
Subject: Re: [PWE3] Poll for WG adoption of draft-n= adeau-pwe3-vccv-2-02.txt

I do not support !  &nb= sp; and I can not understand how anyone can support it !

 

We d= o NOT need a fourth VCCV type, there are too many already.

 

I complet= ely agree with the part that says if there is a CW then the ACh should be ma= rked by it.

 

I do NOT agree that if the CW is not used then we should= use a non-PW method developed for MPLS-TP.

I do NOT agree that there= is any way to deprecate the use of TTL expiry to mark the ACh.

I do= NOT agree that we should change mechanisms that have been widely deployed f= or many years now,

<= p class=3DMsoNormal>without an extremely pressing reason.

 

Wer= e the proposal to be that for PWs that traverse ONLY MPLS-TP to have the ADD= ITIONAL option

for ACh marking, I might be convinced not to object as= strongly.

However, since I don't think that PWs can be limited in t= his matter (the MPLS WG adopted the "seamless" draft)

it w= ould be difficult to convince me that such a limitation is possible.<= span style=3D'color:black'>

 

I would have enthusiastically support this proposal had it been brought 8= years ago.

It's too late for this now.

=  

Y(J)S

 

= From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.or= g] On Behalf Of Bocci, Matthew (Matthew)
Sent: Thursday, Ju= ly 28, 2011 21:02
To: pwe3@ietf.org
Subject: [PWE3] Poll= for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

 

T= his email begins a two week poll to help assess if there is consensus to ado= pt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft.

 

Please indicate whether or not you support adoption o= f this draft, and also send any comments to the PWE3 list.

 

This poll will end on Friday 12th August.

 

Regards,

=

 

Matthew & Andy

This e-m= ail message is intended for the recipient only and contains information whic= h is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have r= eceived 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.

--_000_786AD2EC3D80A1428B921CDC9BE9EE546BB897A55CUSPITMAIL01ec_-- From sriganeshkini@gmail.com Mon Aug 1 14:59: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 427531F0C39 for ; Mon, 1 Aug 2011 14:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsRT89LCKEKG for ; Mon, 1 Aug 2011 14:59:55 -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 AE5E921F8DAE for ; Mon, 1 Aug 2011 14:59:55 -0700 (PDT) Received: by vxi40 with SMTP id 40so5789677vxi.31 for ; Mon, 01 Aug 2011 15:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=q1P22XKnpyVWv/AyC6jfONJzr2kkkXIck+VmyJaA1/s=; b=wgfLJpeXeTYlnki/q7ulLU7aC9mV6iwW8aDxvAFJhgUI97aA3P6P8mkEuT3d9jfZs0 A19TAdkV/qR8EsbcBJpY4vD2sLg+pP8EeInqPhLpAaa0wLQJHIuZLszjdeFqGoaDOiUC KQXaxbdMMkPuT2MfLv05GE1A0+pSf/n4Yb+ao= Received: by 10.52.111.161 with SMTP id ij1mr5053450vdb.126.1312236001118; Mon, 01 Aug 2011 15:00:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.106.136 with HTTP; Mon, 1 Aug 2011 14:59:31 -0700 (PDT) From: Sri Date: Mon, 1 Aug 2011 14:59:31 -0700 Message-ID: To: "Bocci, Matthew (Matthew)" , draft-nadeau-pwe3-vccv-2@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pwe3@ietf.org" Subject: [PWE3] Comments - Re: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 01 Aug 2011 21:59:56 -0000 Hello Tom and other authors, Some comments on the draft 1. Why is it called 'unified', and what exactly is it unifying. Seems to be applicable only when control-word is not used. 2. There is no text on whether this VCCV type is inband. If it is not, then data packets and OAM packets may not fate share. What is the applicability of this VCCV in such a case. 3. Section 3 figure does not show bottom of stack bit. 4. Why is the PW label TTL setting to 1 a must ? To reach the T-PE shouldn't any value of TTL >=3D number of PW hops work ? 5. Can this proposal result in a packet having multiple GAL labels ? Thanks On Thu, Jul 28, 2011 at 11:02 AM, Bocci, Matthew (Matthew) wrote: > This email begins a two week poll to help assess if there is consensus to > adopt=A0draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > Please indicate whether or not you support adoption of this draft, and al= so > send any comments to the PWE3 list. > This poll will end on Friday 12th August. > Regards, > Matthew & Andy > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --=20 Sriganesh Kini (Sri) From davari@broadcom.com Mon Aug 1 15:28: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 2658D1F0C51 for ; Mon, 1 Aug 2011 15:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 vXNJbPZPjeFK for ; Mon, 1 Aug 2011 15:28:51 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 97E301F0C49 for ; Mon, 1 Aug 2011 15:28:48 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 01 Aug 2011 15:34:00 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 1 Aug 2011 15:28:45 -0700 From: "Shahram Davari" To: "Robert Rennison" , "Alexander Vainshtein" , "Yaakov Stein" , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Mon, 1 Aug 2011 15:28:42 -0700 Thread-Topic: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxNUHyDZAbasUF1Qk6dQX1EkI++NAAOE9QwAGzyndwALZIXwAAp1lBA Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB5B2@SJEXCHCCR02.corp.ad.broadcom.com> References: , <07F7D7DED63154409F13298786A2ADC903E8FD81@EXRAD5.ad.rad.co.il> <786AD2EC3D80A1428B921CDC9BE9EE546BB897A55C@USPITMAIL01.ecitele.com> In-Reply-To: <786AD2EC3D80A1428B921CDC9BE9EE546BB897A55C@USPITMAIL01.ecitele.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: 6229F6523W4590369-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6A9326CB5B2SJEXCHCCR02co_ Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 01 Aug 2011 22:28:54 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6A9326CB5B2SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I also don't support this draft since I don't think to solve the problem we= need yet a 4th type of VCCV. The best solution is to mandate CW. Shahram From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Rob= ert Rennison Sent: Sunday, July 31, 2011 7:40 PM To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf= .org Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt I do Not support the draft, After hearing the results of the earlier user deployment poll I thought, "= ok the way out of this mess is to migrate towards using the CW". Then I s= ee this proposal and wondered what am I missing. I've still not seen the l= ight of why adding a fourth type will simplify matters, hence in the absenc= e of me understanding how this will simplify matter versus complicate thing= s, I'm against it. Rob From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Sunday, July 31, 2011 12:45 AM To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Hi all, I do NOT support this draft for the same reasons that Yaakov has indicated. Regards, Sasha ________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Ste= in [yaakov_s@rad.com] Sent: Friday, July 29, 2011 3:58 AM To: Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt I do not support ! and I can not understand how anyone can support it ! We do NOT need a fourth VCCV type, there are too many already. I completely agree with the part that says if there is a CW then the ACh sh= ould be marked by it. I do NOT agree that if the CW is not used then we should use a non-PW metho= d developed for MPLS-TP. I do NOT agree that there is any way to deprecate the use of TTL expiry to = mark the ACh. I do NOT agree that we should change mechanisms that have been widely deplo= yed for many years now, without an extremely pressing reason. Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the= ADDITIONAL option for ACh marking, I might be convinced not to object as strongly. However, since I don't think that PWs can be limited in this matter (the MP= LS WG adopted the "seamless" draft) it would be difficult to convince me that such a limitation is possible. I would have enthusiastically support this proposal had it been brought 8 y= ears ago. It's too late for this now. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Thursday, July 28, 2011 21:02 To: pwe3@ietf.org Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt This email begins a two week poll to help assess if there is consensus to a= dopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. Please indicate whether or not you support adoption of this draft, and also= send any comments to the PWE3 list. This poll will end on Friday 12th August. Regards, Matthew & Andy 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_2C2F1EBA8050E74EA81502D5740B4BD6A9326CB5B2SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>


I also don’t support = this draft since I don’t think to solve the problem we need yet a 4th= type of VCCV. The best solution is to mandate CW.

 

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

 <= /o:p>

From: pwe3-bounces@ietf.= org [mailto:pwe3-bounces@ietf.org] On Behalf Of Robert Rennison
<= b>Sent: Sunday, July 31, 2011 7:40 PM
To: Alexander Vainshtei= n; Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org
Subject:= Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

 

I do Not support the draft,

 

After hearing the results of the earlier user deployment  poll I t= hought, “ ok  the way out of this mess is to migrate towards usi= ng the CW”. Then I see this proposal and wondered what am I missing. =  I’ve still not seen the light of why adding a fourth type will = simplify matters, hence in the absence of me understanding how this will si= mplify matter versus complicate things, I’m against it.

 

Rob

 

From: pwe3-bounc= es@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Alexander Va= inshtein
Sent: Sunday, July 31, 2011 12:45 AM
To: Yaako= v Stein; Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PW= E3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

 

Hi all,

I do NOT support = this draft for the same reasons that Yaakov has indicated.

 

Regards,

     Sasha

 

From: pwe3-bounces@ietf.org [pwe3-boun= ces@ietf.org] On Behalf Of Yaakov Stein [yaakov_s@rad.com]
Sent: = Friday, July 29, 2011 3:58 AM
To: Bocci, Matthew (Matthew); pwe3@= ietf.org
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau= -pwe3-vccv-2-02.txt

I do not support !   = ; and I can not understand how anyone can support it !

 

We= do NOT need a fourth VCCV type, there are too many already.

 

I = completely agree with the part that says if there is a CW then the ACh shou= ld be marked by it.

 <= /p>

I do NOT agree that if the CW is not used th= en we should use a non-PW method developed for MPLS-TP.

I do NOT= agree that there is any way to deprecate the use of TTL expiry to mark the= ACh.

I do NOT agree that we should change mechanisms that have be= en widely deployed for many years now,

without an extremely pressi= ng reason.

 

Were the proposal to be that for PWs that traverse ON= LY MPLS-TP to have the ADDITIONAL option=

for ACh marking, I might = be convinced not to object as strongly.<= o:p>

However, since I don't thi= nk that PWs can be limited in this matter (the MPLS WG adopted the "se= amless" draft)

it would be difficult to convince me that such= a limitation is possible.

 <= /span>

I would have enthusiastically support= this proposal had it been brought 8 years ago.

It's too late for = this now.

 

Y(J)S

 =

From: p= we3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew)
Sent: Thursday, July 28, 2011 21:02
T= o: pwe3@ietf.org
Subject: [PWE3] Poll for WG adoption of draf= t-nadeau-pwe3-vccv-2-02.txt

 = ;

This email begins a t= wo week poll to help assess if there is consensus to adopt draft-nadea= u-pwe3-vccv-2-02.txt as a PWE3 working group draft.

 

Please indicate whether or not you support adoption of this draft, = and also send any comments to the PWE3 list.

 

This poll will end on Friday 12th August.

 

R= egards,

=

 

Matthew & Andy

This e-ma= il message is intended for the recipient only and contains information whic= h 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 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_2C2F1EBA8050E74EA81502D5740B4BD6A9326CB5B2SJEXCHCCR02co_-- From tnadeau@lucidvision.com Tue Aug 2 04:57:19 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 D799121F8EEA for ; Tue, 2 Aug 2011 04:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 sgFgH1Wr2soJ for ; Tue, 2 Aug 2011 04:57:19 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 21BCF21F8DA0 for ; Tue, 2 Aug 2011 04:57:19 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id D90BE1D48D7C; Tue, 2 Aug 2011 07:57:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Nadeau In-Reply-To: Date: Tue, 2 Aug 2011 07:57:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <87FDEA26-806B-457C-A8C7-9345AC7C4926@lucidvision.com> References: To: Sri X-Mailer: Apple Mail (2.1244.3) Cc: draft-nadeau-pwe3-vccv-2@tools.ietf.org, "pwe3@ietf.org" Subject: Re: [PWE3] Comments - Re: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 02 Aug 2011 11:57:20 -0000 Hi! > Hello Tom and other authors, >=20 > Some comments on the draft >=20 > 1. Why is it called 'unified', and what exactly is it unifying. Seems > to be applicable only when control-word is not used. The term "unified" was used a bit tongue-and-cheek; it should be more along the lines of "simplified". > 2. There is no text on whether this VCCV type is inband. If it is not, > then data packets and OAM packets may not fate share. What is the > applicability of this VCCV in such a case. There is no change to the operation of VCCV as its already = defined for the CW case. The only thing we've added is the use of the GAL for the cases where you do not want to use a CW so that you can still = reliably=20 identify OAM packets. > 3. Section 3 figure does not show bottom of stack bit. Thanks. > 4. Why is the PW label TTL setting to 1 a must ? To reach the T-PE > shouldn't any value of TTL >=3D number of PW hops work ? This was to handle the MSPW case. > 5. Can this proposal result in a packet having multiple GAL labels ? No, I do not think so.=20 --Tom >=20 > Thanks >=20 > On Thu, Jul 28, 2011 at 11:02 AM, Bocci, Matthew (Matthew) > wrote: >> This email begins a two week poll to help assess if there is = consensus to >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. >> Please indicate whether or not you support adoption of this draft, = and also >> send any comments to the PWE3 list. >> This poll will end on Friday 12th August. >> Regards, >> Matthew & Andy >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >>=20 >>=20 >=20 >=20 >=20 > --=20 > Sriganesh Kini (Sri) > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 From tnadeau@lucidvision.com Tue Aug 2 04:59: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 034EC21F8E7E for ; Tue, 2 Aug 2011 04:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.067, 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 OcROkT1j09Gw for ; Tue, 2 Aug 2011 04:58:59 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 85F4E21F8DA0 for ; Tue, 2 Aug 2011 04:58:58 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 503721D48DBD; Tue, 2 Aug 2011 07:59:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_9047FFC0-4CB3-4C77-AC87-B8E07A185A5F" From: Thomas Nadeau In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB5B2@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 2 Aug 2011 07:59:07 -0400 Message-Id: <3F8EF87B-0D7B-42CA-B542-9F37A865BA40@lucidvision.com> References: , <07F7D7DED63154409F13298786A2ADC903E8FD81@EXRAD5.ad.rad.co.il> <786AD2EC3D80A1428B921CDC9BE9EE546BB897A55C@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB5B2@SJEXCHCCR02.corp.ad.broadcom.com> To: "Shahram Davari" X-Mailer: Apple Mail (2.1244.3) Cc: "pwe3@ietf.org" , Yaakov Stein , Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 02 Aug 2011 11:59:00 -0000 --Apple-Mail=_9047FFC0-4CB3-4C77-AC87-B8E07A185A5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > Hi, >=20 > I also don=92t support this draft since I don=92t think to solve the = problem we need yet a 4th type of VCCV. The best solution is to mandate = CW. While I am with you, that argument went out the window during = the debates we had over the past 3 IETF meetings. Operators were very clear that they do not want to mandate the use of a CW. = Hence, Luca and I came up with this solution that narrows the=20 scope to 2 modes, one that handles the CW case and one that doesn't = while still both modes providing predictable OAM capabilities for the PW. --Tom > =20 > Shahram > =20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Robert Rennison > Sent: Sunday, July 31, 2011 7:40 PM > To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); = pwe3@ietf.org > Subject: Re: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt > =20 > I do Not support the draft, > =20 > After hearing the results of the earlier user deployment poll I = thought, =93 ok the way out of this mess is to migrate towards using = the CW=94. Then I see this proposal and wondered what am I missing. = I=92ve still not seen the light of why adding a fourth type will = simplify matters, hence in the absence of me understanding how this will = simplify matter versus complicate things, I=92m against it. > =20 > Rob > =20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Alexander Vainshtein > Sent: Sunday, July 31, 2011 12:45 AM > To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > Subject: Re: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt > =20 > Hi all, > I do NOT support this draft for the same reasons that Yaakov has = indicated. > =20 > Regards, > Sasha > =20 > From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of = Yaakov Stein [yaakov_s@rad.com] > Sent: Friday, July 29, 2011 3:58 AM > To: Bocci, Matthew (Matthew); pwe3@ietf.org > Subject: Re: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt >=20 > I do not support ! and I can not understand how anyone can support = it ! > =20 > We do NOT need a fourth VCCV type, there are too many already. > =20 > I completely agree with the part that says if there is a CW then the = ACh should be marked by it. > =20 > I do NOT agree that if the CW is not used then we should use a non-PW = method developed for MPLS-TP. > I do NOT agree that there is any way to deprecate the use of TTL = expiry to mark the ACh. > I do NOT agree that we should change mechanisms that have been widely = deployed for many years now, > without an extremely pressing reason. > =20 > Were the proposal to be that for PWs that traverse ONLY MPLS-TP to = have the ADDITIONAL option > for ACh marking, I might be convinced not to object as strongly. > However, since I don't think that PWs can be limited in this matter = (the MPLS WG adopted the "seamless" draft) > it would be difficult to convince me that such a limitation is = possible. > =20 > I would have enthusiastically support this proposal had it been = brought 8 years ago. > It's too late for this now. > =20 > Y(J)S > =20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Bocci, Matthew (Matthew) > Sent: Thursday, July 28, 2011 21:02 > To: pwe3@ietf.org > Subject: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt > =20 > This email begins a two week poll to help assess if there is consensus = to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > =20 > Please indicate whether or not you support adoption of this draft, and = also send any comments to the PWE3 list. > =20 > This poll will end on Friday 12th August. > =20 > Regards, > =20 > Matthew & Andy > 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. > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail=_9047FFC0-4CB3-4C77-AC87-B8E07A185A5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 1, 2011, at 6:28 PM, Shahram = Davari wrote:


I = also don=92t support this draft since I don=92t think to solve the = problem we need yet a 4th type of VCCV. The best solution is to mandate = CW.

While I = am with you, that argument went out the window during the debates we had = over the past 3 IETF meetings. Operators
were very clear that = they do not want to mandate the use of a CW.   Hence, Luca and I = came up with this solution that narrows the 
scope to 2 = modes, one that handles the CW case and one that doesn't while still = both modes providing predictable OAM capabilities
for the = PW.

= --Tom


From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org= ] On Behalf Of Robert = Rennison
Sent: Sunday, July 31, 2011 7:40 = PM
To: Alexander Vainshtein; = Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PWE3] Poll for WG = adoption of = draft-nadeau-pwe3-vccv-2-02.txt
 
I do = Not support the draft,
 
After hearing the results of the = earlier user deployment  poll I thought, =93 ok  the way out = of this mess is to migrate towards using the CW=94. Then I see this = proposal and wondered what am I missing.  I=92ve still not seen the = light of why adding a fourth type will simplify matters, hence in the = absence of me understanding how this will simplify matter versus = complicate things, I=92m against it.
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org= ] On Behalf Of Alexander = Vainshtein
Sent: Sunday, July 31, 2011 12:45 = AM
To: Yaakov = Stein; Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PWE3] Poll for WG = adoption of = draft-nadeau-pwe3-vccv-2-02.txt
 
Hi = all,
I do NOT support this draft for the same reasons that Yaakov = has indicated.
 
     = Sasha
 

 pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of = Yaakov Stein [yaakov_s@rad.com]
Sent: Friday, July 29, 2011 3:58 = AM
To: Bocci, = Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PWE3] Poll for WG = adoption of draft-nadeau-pwe3-vccv-2-02.txt

I do not support !    and I can not = understand how anyone can support it !
 
We do = NOT need a fourth VCCV type, there are too many already.
 
I completely agree with the part = that says if there is a CW then the ACh should be marked by = it.
I do = NOT agree that if the CW is not used then we should use a non-PW method = developed for MPLS-TP.I do NOT = agree that there is any way to deprecate the use of TTL expiry to mark = the ACh.I do NOT = agree that we should change mechanisms that have been widely deployed = for many years now,without an = extremely pressing reason.Were = the proposal to be that for PWs that traverse ONLY MPLS-TP to have the = ADDITIONAL optionfor ACh = marking, I might be convinced not to object as strongly.
However, since I don't think that PWs can be limited = in this matter (the MPLS WG adopted the "seamless" draft)
it would be difficult to convince me that such a = limitation is possible.I = would have enthusiastically support this proposal had it been brought 8 = years ago.It's too = late for this now.
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org= ] On Behalf Of Bocci, Matthew = (Matthew)
Sent: Thursday, July 28, 2011 = 21:02
To: pwe3@ietf.org
Subject: [PWE3] Poll for WG adoption = of draft-nadeau-pwe3-vccv-2-02.txt 
This email begins a two week poll to help assess if there is = consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 = working group draft. 
Please indicate whether or not you support = adoption of this draft, and also send any comments to the PWE3 = list. 
This poll will end on Friday 12th = August. 
Regards, 
Matthew & Andy
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.
___________________________________________= ____
pwe3 mailing list
MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Tue, 2 Aug 2011 20:04:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-02 20:04:56, Serialize complete at 2011-08-02 20:04:56 Content-Type: multipart/alternative; boundary="=_alternative 00428F4B482578E0_=" X-MAIL: mse02.zte.com.cn p72C5R2I065311 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 02 Aug 2011 12:05:31 -0000 This is a multipart message in MIME format. --=_alternative 00428F4B482578E0_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 eWVzL3N1cHBvcnQNCg0KDQoNCg0KDQoNCg0KIkJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KSIgPG1h dHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPiANCreivP7IyzogIHB3ZTMtYm91bmNlc0Bp ZXRmLm9yZw0KMjAxMS0wNy0yOSAwMjowMg0KDQrK1bz+yMsNCiJwd2UzQGlldGYub3JnIiA8cHdl M0BpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KW1BXRTNdIFBvbGwgZm9yIFdHIGFkb3B0aW9uIG9m IGRyYWZ0LW5hZGVhdS1wd2UzLXZjY3YtMi0wMi50eHQNCg0KDQoNCg0KDQoNClRoaXMgZW1haWwg YmVnaW5zIGEgdHdvIHdlZWsgcG9sbCB0byBoZWxwIGFzc2VzcyBpZiB0aGVyZSBpcyBjb25zZW5z dXMgdG8gDQphZG9wdCBkcmFmdC1uYWRlYXUtcHdlMy12Y2N2LTItMDIudHh0IGFzIGEgUFdFMyB3 b3JraW5nIGdyb3VwIGRyYWZ0Lg0KDQpQbGVhc2UgaW5kaWNhdGUgd2hldGhlciBvciBub3QgeW91 IHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCwgYW5kIA0KYWxzbyBzZW5kIGFueSBjb21t ZW50cyB0byB0aGUgUFdFMyBsaXN0Lg0KDQpUaGlzIHBvbGwgd2lsbCBlbmQgb24gRnJpZGF5IDEy dGggQXVndXN0Lg0KDQpSZWdhcmRzLA0KDQpNYXR0aGV3ICYgQW5keV9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0KcHdlM0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQoNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS4NCg== --=_alternative 00428F4B482578E0_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnllcy9zdXBwb3J0PGJyPg0KPC9m b250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1jZW50ZXI+PC9kaXY+DQo8dGQ+ PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj4mcXVvdDtCb2NjaSwgTWF0dGhldyAoTWF0dGhldykmcXVvdDsNCiZsdDttYXR0aGV3LmJv Y2NpQGFsY2F0ZWwtbHVjZW50LmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wNy0yOSAwMjowMjwv Zm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4m cXVvdDtwd2UzQGlldGYub3JnJnF1b3Q7ICZsdDtwd2UzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W1BXRTNdIFBv bGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LW5hZGVhdS1wd2UzLXZjY3YtMi0wMi50eHQ8L2Zv bnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwv dGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+VGhpcyBlbWFpbCBiZWdpbnMgYSB0d28gd2VlayBwb2xsIHRvIGhlbHANCmFzc2Vz cyBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdG8gYWRvcHQgZHJhZnQtbmFkZWF1LXB3ZTMtdmNjdi0y LTAyLnR4dCBhcw0KYSBQV0UzIHdvcmtpbmcgZ3JvdXAgZHJhZnQuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5QbGVhc2UgaW5kaWNhdGUgd2hldGhlciBvciBu b3QgeW91IHN1cHBvcnQNCmFkb3B0aW9uIG9mIHRoaXMgZHJhZnQsIGFuZCBhbHNvIHNlbmQgYW55 IGNvbW1lbnRzIHRvIHRoZSBQV0UzIGxpc3QuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj5UaGlzIHBvbGwgd2lsbCBlbmQgb24gRnJpZGF5IDEydGggQXVndXN0 LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+UmVnYXJkcyw8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPk1hdHRoZXcgJmFt cDsgQW5keTwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KcHdlMyBtYWlsaW5nIGxpc3Q8YnI+DQpwd2UzQGll dGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzPGJy Pg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZu YnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7 Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5 Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5p emF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5i c3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5i c3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3km bmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rp c2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21t dW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQm bmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5i c3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xl bHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2 aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJz cDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVj ZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNl Jm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5i c3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5i c3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFz Jm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5i c3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9w cmU+ --=_alternative 00428F4B482578E0_=-- From prvs=5195aebb47=edwin.mallette@bhnis.com Tue Aug 2 06:12: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 8E0FD21F8D42 for ; Tue, 2 Aug 2011 06:12:22 -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 639UOmzo5Jy0 for ; Tue, 2 Aug 2011 06:12:21 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX2.mybrighthouse.com [209.16.122.104]) by ietfa.amsl.com (Postfix) with ESMTP id F401521F8D3F for ; Tue, 2 Aug 2011 06:12:20 -0700 (PDT) Received: from pps.filterd (mx2 [127.0.0.1]) by mx2.mybrighthouse.com (8.14.3/8.14.3) with SMTP id p72D4cxt015712 for ; Tue, 2 Aug 2011 09:12:28 -0400 Received: from cntpacas1.corp.local ([10.225.1.123]) by mx2.mybrighthouse.com with ESMTP id xxf9ugh55-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 02 Aug 2011 09:12:28 -0400 Received: from CNEMAIL.corp.local ([10.225.1.130]) by cntpacas1.corp.local ([10.225.1.123]) with mapi; Tue, 2 Aug 2011 09:12:27 -0400 From: "Mallette, Edwin" To: "pwe3@ietf.org" Date: Tue, 2 Aug 2011 09:12:24 -0400 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxRFdP4ktOppFGPT0m/827S8XM3AA== Message-ID: In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB5B2@SJEXCHCCR02.corp.ad.broadcom.com> 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_CA5D6F8C130B1edwinmallettebhniscom_" 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-1108020100 Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 02 Aug 2011 13:12:22 -0000 --_000_CA5D6F8C130B1edwinmallettebhniscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No =96 do not support. I also am under the belief that mandating CW is the proper course. The las= t thing I need is yet another VCCV type. Ed From: Shahram Davari > Date: Mon, 1 Aug 2011 18:28:42 -0400 To: Robert Rennison >, Alexander Vainshtein >, Yaakov Stein >, "Bocci, Matthew (Matthew)" >, "pwe3@ietf.org" > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Hi, I also don=92t support this draft since I don=92t think to solve the proble= m we need yet a 4th type of VCCV. The best solution is to mandate CW. Shahram From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Robert Rennison Sent: Sunday, July 31, 2011 7:40 PM To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf= .org Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt I do Not support the draft, After hearing the results of the earlier user deployment poll I thought, = =93 ok the way out of this mess is to migrate towards using the CW=94. The= n I see this proposal and wondered what am I missing. I=92ve still not see= n the light of why adding a fourth type will simplify matters, hence in the= absence of me understanding how this will simplify matter versus complicat= e things, I=92m against it. Rob From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Sunday, July 31, 2011 12:45 AM To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Hi all, I do NOT support this draft for the same reasons that Yaakov has indicated. Regards, Sasha ________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@iet= f.org] On Behalf Of Yaakov Stein [yaakov_s@ra= d.com] Sent: Friday, July 29, 2011 3:58 AM To: Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt I do not support ! and I can not understand how anyone can support it ! We do NOT need a fourth VCCV type, there are too many already. I completely agree with the part that says if there is a CW then the ACh sh= ould be marked by it. I do NOT agree that if the CW is not used then we should use a non-PW metho= d developed for MPLS-TP. I do NOT agree that there is any way to deprecate the use of TTL expiry to = mark the ACh. I do NOT agree that we should change mechanisms that have been widely deplo= yed for many years now, without an extremely pressing reason. Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the= ADDITIONAL option for ACh marking, I might be convinced not to object as strongly. However, since I don't think that PWs can be limited in this matter (the MP= LS WG adopted the "seamless" draft) it would be difficult to convince me that such a limitation is possible. I would have enthusiastically support this proposal had it been brought 8 y= ears ago. It's too late for this now. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Thursday, July 28, 2011 21:02 To: pwe3@ietf.org Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt This email begins a two week poll to help assess if there is consensus to a= dopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. Please indicate whether or not you support adoption of this draft, and also= send any comments to the PWE3 list. This poll will end on Friday 12th August. Regards, Matthew & Andy 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. ________________________________ 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_CA5D6F8C130B1edwinmallettebhniscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
No =96 do not support.

I also am under the belief that mandating CW is the proper course. &nb= sp;The last thing I need is yet another VCCV type.

Ed

From: Shahram Davari <davari@broadcom.com>
Date: Mon, 1 Aug 2011 18:28:42 -040= 0
To: Robert Rennison <robert.rennison@ecitele.com>, Al= exander Vainshtein <= Alexander.Vainshtein@ecitele.com>, Yaakov Stein <yaakov_s@rad.com>, "Bo= cci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>, "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: [PWE3] Poll for WG ado= ption of draft-nadeau-pwe3-vccv-2-02.txt

Hi,


I also don=92t support this draft since I don=92t think to solve the proble= m we need yet a 4th type of VCCV. The best solution is to mandate CW.<= /o:p>

 

Shahram

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Robert Rennison
Sent: Sunday, July 31, 2011 7:40 PM
To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2= -02.txt

 

I do Not support the draft,

 

After hearing the results of the e= arlier user deployment  poll I thought, =93 ok  the way out of th= is mess is to migrate towards using the CW=94. Then I see this proposal and wondered what am I missing.  I=92ve still not= seen the light of why adding a fourth type will simplify matters, hence in= the absence of me understanding how this will simplify matter versus compl= icate things, I=92m against it.

 

Rob

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Sunday, July 31, 2011 12:45 AM
To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2= -02.txt

 

Hi all,

I do NOT support this dr= aft for the same reasons that Yaakov has indicated.

 =

Regards,

    = Sasha

 =

From:= pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Y= aakov Stein [yaakov_s@rad.com]
Sent: Friday, July 29, 2011 3:58 AM
To: Bocci, Matthew (Matthew); pwe3@= ietf.org
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2= -02.txt

I do not support !   &nb= sp;and I can not understand how anyone can support it !

 =

We do NOT need a fourth VCCV type,= there are too many already.<= /span>

 =

I completely agree with the part t= hat says if there is a CW then the ACh should be marked by it.

 =

I do NOT agree that if the CW is n= ot used then we should use a non-PW method developed for MPLS-TP.

I do NOT agree that there is any w= ay to deprecate the use of TTL expiry to mark the ACh.

I do NOT agree that we should chan= ge mechanisms that have been widely deployed for many years now,

without an extremely pressing reas= on.

 =

Were the proposal to be that for P= Ws that traverse ONLY MPLS-TP to have the ADDITIONAL option

for ACh marking, I might be convin= ced not to object as strongly.

However, since I don't think that = PWs can be limited in this matter (the MPLS WG adopted the "seamless&q= uot; draft)

it would be difficult to convince = me that such a limitation is possible.

 =

I would have enthusiastically supp= ort this proposal had it been brought 8 years ago.

It's too late for this now.=

 =

Y(J)S

 =

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Thursday, July 28, 2011 21:02
To: pwe3@ietf.org
Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt

 =

This email begins a two week poll to help a= ssess if there is consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt a= s a PWE3 working group draft.=

 =

Please indicate whether or not you support = adoption of this draft, and also send any comments to the PWE3 list.=

 =

This poll will end on Friday 12th August.

 =

Regards,=

 =

Matthew & Andy

This e-mail message is intended for the recipient only and contains info= rmation 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 info= rmation 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.


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_CA5D6F8C130B1edwinmallettebhniscom_-- From curtis@occnc.com Tue Aug 2 07:25: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 286BA21F85EC for ; Tue, 2 Aug 2011 07:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 rBrsI1+qMxmb for ; Tue, 2 Aug 2011 07:25:26 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 60E5921F84F9 for ; Tue, 2 Aug 2011 07:25:26 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p72EOAbD061259; Tue, 2 Aug 2011 10:24:11 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108021424.p72EOAbD061259@harbor.orleans.occnc.com> To: Thomas Nadeau From: Curtis Villamizar In-reply-to: Your message of "Tue, 02 Aug 2011 07:57:27 EDT." <87FDEA26-806B-457C-A8C7-9345AC7C4926@lucidvision.com> Date: Tue, 02 Aug 2011 10:24:10 -0400 Sender: curtis@occnc.com Cc: draft-nadeau-pwe3-vccv-2@tools.ietf.org, "pwe3@ietf.org" Subject: Re: [PWE3] Comments - Re: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 14:25:27 -0000 In message <87FDEA26-806B-457C-A8C7-9345AC7C4926@lucidvision.com> Thomas Nadeau writes: > > > 5. Can this proposal result in a packet having multiple GAL labels ? > > No, I do not think so. > > --Tom It generally won't because LSP OAM will never take the label stack from PW OAM and put it underneath the LSP OAM label stack. Even if it did, the only GAL label that counts is the one that is immediately below the label being acted on. If it is TTL expired and the label below the one with TTL expiring is GAL, then it is OAM for that label. If a label POP is done and the next label is GAL, it is OAM for the label just popped. That can be handled by a reasonably flexible parser. I can't really think of any case where the PW GAL, or any lower layer GAL would be included to check to see if the "skip over GAL when hashing" processing was happenning right at every point along the path. Generally you would expect to see every GAL skipped or none skipped in the hash. If there were a use for more than one GAL we would already have that use in hierarchical LSP and we don't see it. Curtis From giles.heron@gmail.com Tue Aug 2 09:04:44 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 F325E11E8080 for ; Tue, 2 Aug 2011 09:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7tM3IwltVud for ; Tue, 2 Aug 2011 09:04:43 -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 3C0CD11E807E for ; Tue, 2 Aug 2011 09:04:36 -0700 (PDT) Received: by wwe5 with SMTP id 5so4609762wwe.13 for ; Tue, 02 Aug 2011 09:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=3wBVaFENAXZ12/sQuGTeUbN18D0XG+el+1CvX8Bjxeg=; b=xdmWsF81PAgtoJPpJtfzhhNSrIadigd8/59UTAvLxcEISkKfntjN9Dp8Mju4EcjSeW sfHYpOBmQ8ZxXnOUsjLo3CROtMDa2e0TOj9Tdsod3mdKwOuexTUieSGPKdHS5IBWZEed JjQigavJJ6eesMFIPyv6vzC676/Tmg69baydE= Received: by 10.216.14.85 with SMTP id c63mr755958wec.67.1312301084178; Tue, 02 Aug 2011 09:04:44 -0700 (PDT) Received: from [10.61.102.152] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fc2sm5131311wbb.35.2011.08.02.09.04.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 09:04:42 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 02 Aug 2011 17:06:40 +0100 From: Giles Heron To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Message-ID: Thread-Topic: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt Thread-Index: AcxGGO4Vr5zkZH55TBaz4sxdeixrRwLFTvMV In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.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, 02 Aug 2011 16:04:44 -0000 support On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" wrote: > This email begins a poll of the list to see if there is consensus to adopt > draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working group > draft. > > Please indicate whether or not you support adoption of this draft, and send > any comments to the PWE3 list. > > This poll ends on Tuesday 9th August. > > Regards, > > Matthew and Andy. > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From lmartini@cisco.com Tue Aug 2 09:33: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 B8F9511E807B for ; Tue, 2 Aug 2011 09:33:22 -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 ZDrtAHPgciWe for ; Tue, 2 Aug 2011 09:33:22 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEDB11E8080 for ; Tue, 2 Aug 2011 09:33:21 -0700 (PDT) Received: from seven.monoski.com (dhcp-171-70-247-84.cisco.com [171.70.247.84]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p72GX8bu018122 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 10:33:17 -0600 (MDT) Message-ID: <4E3826BE.6010200@cisco.com> Date: Tue, 02 Aug 2011 10:33:02 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Yaakov Stein References: <07F7D7DED63154409F13298786A2ADC903E8FD81@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903E8FD81@EXRAD5.ad.rad.co.il> Content-Type: multipart/alternative; boundary="------------020806000203050906070704" Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 02 Aug 2011 16:33:23 -0000 This is a multi-part message in MIME format. --------------020806000203050906070704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/28/2011 06:58 PM, Yaakov Stein wrote: > I do not support ! and I can not understand how anyone can support it ! > > We do NOT need a fourth VCCV type, there are too many already. > I agree that there are too many already. Why not move to a single one ? Luca > I completely agree with the part that says if there is a CW then the ACh should be marked by it. > > I do NOT agree that if the CW is not used then we should use a non-PW method developed for MPLS-TP. > I do NOT agree that there is any way to deprecate the use of TTL expiry to mark the ACh. > I do NOT agree that we should change mechanisms that have been widely deployed for many years now, > without an extremely pressing reason. > > Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the ADDITIONAL option > for ACh marking, I might be convinced not to object as strongly. > However, since I don't think that PWs can be limited in this matter (the MPLS WG adopted the "seamless" draft) > it would be difficult to convince me that such a limitation is possible. > > I would have enthusiastically support this proposal had it been brought 8 years ago. > It's too late for this now. > > Y(J)S > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) > Sent: Thursday, July 28, 2011 21:02 > To: pwe3@ietf.org > Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > This email begins a two week poll to help assess if there is consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > > Please indicate whether or not you support adoption of this draft, and also send any comments to the PWE3 list. > > This poll will end on Friday 12th August. > > Regards, > > Matthew & Andy > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --------------020806000203050906070704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/28/2011 06:58 PM, Yaakov Stein wrote: 
I do not support !    and I can not understand how anyone can support it !

We do NOT need a fourth VCCV type, there are too many already.
I agree that there are too many already.
Why not move to a single one ?

Luca

I completely agree with the part that says if there is a CW then the ACh should be marked by it.

I do NOT agree that if the CW is not used then we should use a non-PW method developed for MPLS-TP.
I do NOT agree that there is any way to deprecate the use of TTL expiry to mark the ACh.
I do NOT agree that we should change mechanisms that have been widely deployed for many years now,
without an extremely pressing reason.

Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the ADDITIONAL option
for ACh marking, I might be convinced not to object as strongly.
However, since I don't think that PWs can be limited in this matter (the MPLS WG adopted the "seamless" draft)
it would be difficult to convince me that such a limitation is possible.

I would have enthusiastically support this proposal had it been brought 8 years ago.
It's too late for this now.

Y(J)S

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Thursday, July 28, 2011 21:02
To: pwe3@ietf.org
Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

This email begins a two week poll to help assess if there is consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft.

Please indicate whether or not you support adoption of this draft, and also send any comments to the PWE3 list.

This poll will end on Friday 12th August.

Regards,

Matthew & Andy



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

--------------020806000203050906070704-- From sriganeshkini@gmail.com Tue Aug 2 14:05: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 3E8FC21F886A for ; Tue, 2 Aug 2011 14:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmQHIQLyuTdc for ; Tue, 2 Aug 2011 14:05:26 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 883C521F8777 for ; Tue, 2 Aug 2011 14:05:26 -0700 (PDT) Received: by qwc23 with SMTP id 23so174570qwc.31 for ; Tue, 02 Aug 2011 14:05:33 -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; bh=w+/GplWugRJzO4x6r2cSA5gAUJoXq/VpGZrdOo2bCEI=; b=Z3RnnjV0q6FTEng9w/i1bNBpA5K8qda8VZ8na/WYuKQG7n/YCcVnQlCpLeI2wsZSIv 53iARI+N84F7t4LsfM3Sza2PRjNct8xCKJfYAQ5a3Z8j6BEepiq5GTG+khUW8xbQX9Nk 6L+emDOo7lE6cFgf1TutT9DOFuJHEiUghWoww= Received: by 10.52.70.179 with SMTP id n19mr5872714vdu.260.1312319133111; Tue, 02 Aug 2011 14:05:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.68 with HTTP; Tue, 2 Aug 2011 14:05:03 -0700 (PDT) In-Reply-To: <87FDEA26-806B-457C-A8C7-9345AC7C4926@lucidvision.com> References: <87FDEA26-806B-457C-A8C7-9345AC7C4926@lucidvision.com> From: Sri Date: Tue, 2 Aug 2011 14:05:03 -0700 Message-ID: To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-nadeau-pwe3-vccv-2@tools.ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] Comments - Re: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 02 Aug 2011 21:05:27 -0000 See inline - Sri Sent from my iPad On Aug 2, 2011, at 4:57 AM, Thomas Nadeau wrote: > > Hi! > >> Hello Tom and other authors, >> >> Some comments on the draft >> >> 1. Why is it called 'unified', and what exactly is it unifying. Seems >> to be applicable only when control-word is not used. > > The term "unified" was used a bit tongue-and-cheek; it should be > more along the lines of "simplified". Ok. Maybe "simplified no CW" mode would reflect it better. > >> 2. There is no text on whether this VCCV type is inband. If it is not, >> then data packets and OAM packets may not fate share. What is the >> applicability of this VCCV in such a case. > > There is no change to the operation of VCCV as its already defined > for the CW case. The only thing we've added is the use of the GAL for > the cases where you do not want to use a CW so that you can still reliably > identify OAM packets. All the VCCV types in RFC5085 state ECMP behavior. So to be consistent it needs to be stated for this proposed vccv type too. IMO it is useful to examine if it can ensure fate-sharing with the PW payload. If the connectivity verification cannot be guaranteed for a given flow on the PW then its applicability is limited. > >> 3. Section 3 figure does not show bottom of stack bit. > > Thanks. > >> 4. Why is the PW label TTL setting to 1 a must ? To reach the T-PE >> shouldn't any value of TTL >= number of PW hops work ? > > This was to handle the MSPW case. Even in MSPW why wouldn't PW label TTL >= number of PW segments work to reach the T-PE ? > >> 5. Can this proposal result in a packet having multiple GAL labels ? > > No, I do not think so. Another comment In section 3 it is stated "The first nibble of the next field is set to 0001b to indicate an ACH associated with a pseudowire..." If the GAL is indicating the presence of an ACh, then the first nibble is not needed for the same purpose. Its use would be to prevent incorrect interpretation by an intermediate LSR that examines the first nibble to perform forwarding decisions. > > --Tom > > >> >> Thanks >> >> On Thu, Jul 28, 2011 at 11:02 AM, Bocci, Matthew (Matthew) >> wrote: >>> This email begins a two week poll to help assess if there is consensus to >>> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. >>> Please indicate whether or not you support adoption of this draft, and also >>> send any comments to the PWE3 list. >>> This poll will end on Friday 12th August. >>> Regards, >>> Matthew & Andy >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >>> >> >> >> >> -- >> Sriganesh Kini (Sri) >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > From loa@pi.nu Tue Aug 2 14:31: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 B132F11E80CC; Tue, 2 Aug 2011 14:31:56 -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 6UM-5mN7+c8J; Tue, 2 Aug 2011 14:31:56 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7F74C11E80C5; Tue, 2 Aug 2011 14:31:55 -0700 (PDT) Received: from [10.154.181.21] (unknown [129.192.185.163]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 26F5C514044; Tue, 2 Aug 2011 23:32:02 +0200 (CEST) Message-ID: <4E386CF0.5050700@pi.nu> Date: Tue, 02 Aug 2011 14:32:32 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, rtg-dir@ietf.org, draft-ietf-pwe3-fat.all@tools.ietf.org Subject: [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 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, 02 Aug 2011 21:31:57 -0000 Hello, I have been selected as the Routing Directorate reviewer for draft-ietf-pwe3-fat-pw-07. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pwe3-fat-pw-07 Reviewer: Loa Andersson Review Date: 2 Aug 2011 IETF LC End Date: 3 Aug 2011 Intended Status: Standards Track Summary: I have no major concerns about this document, howver I thing it would be good to reslove the mostly editorial comments below (especially on the IANA section) before publication. Comments: Unexpanded acronyms: OAM appears in the table of content and as header 7. It is not expanded in the document anywhere. Should be done at first occurance. page 6. The last paragraph of section 1 talks about TC bits (and EXP bits). We don't have TC bits - the correct name is TC field. First paragraph section three: This paragraph talks in genral about "load balanced paths" while the rest of the document is very specific about ECMP, it is the intention that this should work for any load balancing paradigm? Second paragraph section three: Normally a label is assigned by the down stream node, this scheme is doing upstream allocation. Don't see a problem under normal operation, but if the label "by accident" becomes top of stack this could have "interesting" effects. Sectyion 4 second paagraph: OLD The absence of a FL Sub-TLV indicates that the PE is unable to process flow labels. A PE that is using PW signalling and that does not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. A PE that is using PW signalling and which does not receive a FL Sub- TLV from its peer MUST NOT include a flow label in the PW packet. This preserves backwards compatibility with existing PW specifications. NEW The absence of a FL Sub-TLV indicates that the PE is unable to process flow labels. An ingress PE that is using PW signalling and that does not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. An ingress PE that is using PW signalling and which does not receive a FL Sub-TLV from its egress peer MUST NOT include a flow label in the PW packet. This preserves backwards compatibility with existing PW specifications. The IANA section: In the IANA section we should use a TBD entry for the Flow label indicator; and maybe add 0x17 as suggest value in the text. The text in the IANA section needs to aligned with the rest of the text, or maybe even better have the rest of the text align with the IANA section; e.g. Flow Labe intdicator is not used anywhere else but in the iana section. To make it easier to find the references to the IANA registries should start with "Pseudowire Name Spaces (PWE3)" point to "Pseudowire Interface Parameters Sub-TLV type Registry" as a sub-registry, and ask for assigment of the next free value from the Experts review space (suggested value 0x17). On the other hand it looks like we have an early assigment (Flow Label shows up with the value 0x17). If this is the case after making the text changes suggest above this should be mentioned in the IANA section. -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From DanielC@orckit.com Wed Aug 3 00:23: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 C69C421F882E for ; Wed, 3 Aug 2011 00:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, 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 0owF1oCms5XQ for ; Wed, 3 Aug 2011 00:23:43 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA2121F84C8 for ; Wed, 3 Aug 2011 00:23:41 -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_01CC51AE.A992A632" Date: Wed, 3 Aug 2011 10:23:50 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED873C@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requesting additional feedback on draft-cohn-mpls-tp-pw-protection-01 Thread-Index: AcxQOYVbNToQFPx5SzGMez8tviQ5SABdKbRw From: "Daniel Cohn" To: Subject: [PWE3] Requesting additional feedback on draft-cohn-mpls-tp-pw-protection-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: Wed, 03 Aug 2011 07:23:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC51AE.A992A632 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 The authors would like to request additional feedback on the MPLS-TP Linear Protection Applicability to MS-PW, http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-01 =20 Specifically, at the PWE3 meeting last week, there was a discussion on whether the PW redundancy bit draft (http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-04) can comply with MPLS-TP requirements for PW protection. We believe the answer to be clearly in the negative, and therefore would like to require WG adoption of the above draft after comments on this are addressed.=20 =20 This is a list of the TP requirements that in our opinion are not met by the PW redundancy draft.=20 =20 Please do not interpret the below as negative criticism of the PW redundancy draft - it is not. The question is not about the merits of the PW redundancy protocol, but whether it complies with TP requirements (which historically came after the PW redundancy draft) =20 1.- According to RFC 5654 (req 65), MPLS-TP MUST support 1+1 protection. PW redundancy draft does not comply with this. =20 2.- According to RFC 5654 (req 76 and 83) MPLS-TP MUST support management-plane triggers as defined in RFC 4427 - specifically lockout, forced and manual switch. Although the OPTIONAL switchover coordination mode in PW redundancy draft (6.3) implicitly support some management triggers, it cannot support all triggers in RFC 4427. For example, forced switch and lockout are not supported (see 6.3.2 - switchover command is ignore if requested PW is not up) =20 3.- According to RFC 5654 (req 75), MPLS-TP MUST support OAM-based triggers. PW redundancy draft exclusively relies on PW status bits triggers. =20 4.- According to RFC 5654 (req 77), there MUST be a mechanism to distinguish administrative recovery actions from recovery actions initiated by other triggers. This is not supported by the PW redundancy draft - the switchover request message does not specify what triggered the action on the other endpoint. =20 5.- According to RFC 5654 (req 79), MPLS-TP protection mechanisms MUST support priority logic to negotiate and accommodate coexisting requests for protection-switching (e.g., administrative requests and requests due to link/node failures). For example, PW redundancy mechanisms do not specify priority between administrative triggers (e.g. forced/manual switch) and failure triggers (e.g. SF or SD). =20 6.- According to RFC 5654 (req 73), MPLS-TP MUST support revertive and non-revertive behavior. PW redundancy draft provides OPTIONAL support of reversion, without explicit definitions of how the WTR timer is handled (e.g. what happens if different timer values are configured in each side, no administrative command to clear the WTR state), and without provisioning mismatch indication (like R bit in linear protection draft). =20 7.- According to RFC 5654 (req 58), MPLS-TP MUST support 50 ms recovery. The linear protection draft supports several features that reduce the recovery time, such as: - 1-phase operation, while PW redundancy draft in the switchover coordination mode is 2-phase (switch only after receiving confirmation from remote endpoint) - Rapid retransmission of PSC messages to overcome packet loss. In PW redundancy, the loss of a single switchover coordination message will result in recovery times significantly higher than 50 ms =20 8.- According to RFC 5654 (req 61), MPLS-TP MUST support coordination with server layer protection protocols to avoid race conditions - linear protection defines hold-off timer to comply with this requirement. PW redundancy does not support this. =20 Looking forward for comments. =20 ------_=_NextPart_001_01CC51AE.A992A632 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The authors = would like to request additional feedback on the MPLS-TP Linear = Protection Applicability to MS-PW, h= ttp://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-01

 

Specifically, at the PWE3 meeting last week, there was = a discussion on whether the PW = redundancy bit draft (htt= p://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-04) can = comply with MPLS-TP requirements for PW protection.

We believe the answer to be clearly in the negative, = and therefore would like to require WG adoption of the above draft after = comments on this are addressed.

 

This is a = list of the TP requirements that in our opinion are not met by the PW = redundancy draft.

 

Please do = not interpret the below as negative criticism of the PW redundancy draft = – it is not. The question is not about the merits of the PW = redundancy protocol, but whether it complies with TP requirements (which = historically came after the PW redundancy draft)

 

1.- = According to RFC 5654 (req 65), MPLS-TP MUST support 1+1 protection. PW = redundancy draft does not comply with this.

 

2.- = According to RFC 5654 (req 76 and 83) MPLS-TP MUST support = management-plane triggers as defined in RFC 4427 - specifically lockout, = forced and manual switch. Although the OPTIONAL switchover coordination = mode in PW redundancy draft (6.3) implicitly support some management = triggers, it cannot support all triggers in RFC 4427. For example, = forced switch and lockout are not supported (see 6.3.2 – = switchover command is ignore if requested PW is not up)

 

3.- = According to RFC 5654 (req 75), MPLS-TP MUST support OAM-based triggers. = PW redundancy draft exclusively relies on PW status bits = triggers.

 

4.- According to RFC 5654 (req 77), there MUST be a = mechanism to distinguish administrative recovery actions from recovery = actions initiated by other triggers. This is not supported by the PW = redundancy draft – the switchover request message does not specify = what triggered the action on the other endpoint.

 

5.- = According to RFC 5654 (req 79), MPLS-TP protection mechanisms MUST = support priority logic to negotiate and accommodate coexisting requests = for protection-switching (e.g., administrative requests and requests due = to link/node failures). For example, PW redundancy mechanisms do not = specify priority between administrative triggers (e.g. forced/manual = switch) and failure triggers (e.g. SF or SD).

 

6.- = According to RFC 5654 (req 73), MPLS-TP MUST support revertive and = non-revertive behavior. PW redundancy draft provides OPTIONAL support of = reversion, without explicit definitions of how the WTR timer is handled = (e.g. what happens if different timer values are configured in each = side, no administrative command to clear the WTR state), and without = provisioning mismatch indication (like R bit in linear protection = draft).

 

7.- According to RFC 5654 (req 58), MPLS-TP MUST = support 50 ms recovery. The linear protection draft supports several = features that reduce the recovery time, such as:

- 1-phase operation, = while PW redundancy draft in the switchover coordination mode is 2-phase = (switch only after receiving confirmation from remote = endpoint)

- Rapid retransmission of PSC messages to = overcome packet loss. In PW redundancy, the loss of a single switchover = coordination message will result in recovery times significantly higher = than 50 ms

 

8.- According to RFC 5654 (req 61), MPLS-TP MUST = support coordination with server layer protection protocols to avoid = race conditions - linear protection defines hold-off timer to comply = with this requirement. PW redundancy does not support = this.

 

Looking forward for comments.

 

------_=_NextPart_001_01CC51AE.A992A632-- From frederic.jounay@orange-ftgroup.com Wed Aug 3 00:35: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 0E95121F8ACE for ; Wed, 3 Aug 2011 00:35:11 -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 Py4unFZdZ3Hf for ; Wed, 3 Aug 2011 00:35:10 -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 41D5221F89B8 for ; Wed, 3 Aug 2011 00:35:07 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4EDCA8C0004 for ; Wed, 3 Aug 2011 09:36:07 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 3399E8B8008 for ; Wed, 3 Aug 2011 09:36:07 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 09:35:17 +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_01CC51AF.E3A9731D" Date: Wed, 3 Aug 2011 09:35:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [PWE3] MPLS 2011 - October 16-19, Washington DC Thread-index: AcxRr+LTFaUtEfmCR+ukwBHmy5jRpQ== From: To: X-OriginalArrivalTime: 03 Aug 2011 07:35:17.0249 (UTC) FILETIME=[E3F4A710:01CC51AF] Subject: [PWE3] MPLS 2011 - October 16-19, Washington DC 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, 03 Aug 2011 07:35:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC51AF.E3A9731D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Bonjour, Registration for MPLS 2011 (October 16-19, Omni Shoreham Hotel in Washington), the 14th annual International Conference on MPLS and related new technologies is now open at: http://www.mpls2011.com/registration/attendees.htm =20 MPLS 2011 will include an extensive four day program consisting of tutorials, technical sessions, panels, and exhibits. The key topics to be discussed at this year's conference include: Scaling MPLS, Data Centers, MPLS Transport Profile, Cloud Computing, Future Networks, Mobile Backhaul, Resiliency, Network Management and Performance, Multi-layer and Optical Networks.=20 In addition, there will be two panel discussions on current topics. =20 The complete program is available at: http://www.mpls2011.com/program/technical_sessions.htm =20 The event will be followed by a Public Interop demonstration. There will also be an exhibit floor, where leading network equipment vendors will showcase their new offerings, the list of current sponsors is available at: http://www.mpls2011.com/sponsors/sponsors.htm =20 The conference hotel is the Omni Shoreham Hotel in Washington DC.=20 Please note that there are only a limited number of rooms available this year at a reduced rate. =20 Please make reservations at: http://www.mpls2011.com/hotel.htm Looking forward to seeing you at MPLS 2011! Regards, Frederic ------_=_NextPart_001_01CC51AF.E3A9731D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable [PWE3] MPLS 2011 - October 16-19, Washington DC

Bonjour,

Registration for MPLS 2011 (October 16-19, Omni = Shoreham Hotel = in Washington),  the 14th annual International Conference on = MPLS and related new technologies is now open at:

http://www.mpls2011.com/registration/attendees.htm

  

MPLS 2011 will include an extensive four day program consisting = of tutorials, technical sessions, panels, and exhibits. The key = topics to be discussed at this year's conference include: Scaling = MPLS, Data Centers, MPLS

Transport Profile, Cloud Computing, Future = Networks, Mobile = Backhaul,

Resiliency, Network Management and Performance, = Multi-layer and Optical Networks. 

In addition, there will be two panel discussions on = current topics.

 

The complete program is available at:

http://www.mpls2011.com/program/technical_sessions.htm

  

The event will be followed by a Public Interop = demonstration. There will also be an exhibit floor,

 where leading network equipment vendors will showcase = their new offerings,

 the list of current sponsors is available = at:

http://www.mpls2011.com/sponsors/sponsors.htm

 

The conference hotel is the Omni Shoreham Hotel in = Washington DC. 

Please note that there are only a limited number of rooms = available this year

at a reduced rate.  

Please make reservations at: http://www.mpls2011.com/hotel.htm

Looking forward = to seeing you at MPLS 2011!

Regards,

Frederic

------_=_NextPart_001_01CC51AF.E3A9731D-- From giles.heron@gmail.com Wed Aug 3 11:08:17 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 F251511E807B for ; Wed, 3 Aug 2011 11:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[AWL=-0.542, 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 k93iGpAwkCFK for ; Wed, 3 Aug 2011 11:08:17 -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 C46BC21F89B8 for ; Wed, 3 Aug 2011 11:08:16 -0700 (PDT) Received: by wwe5 with SMTP id 5so759538wwe.13 for ; Wed, 03 Aug 2011 11:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=StzX812wtyz+LTCe9qjXYAH3+qpgnDgwjeUEg8WbPvk=; b=ushQY6aoQxzPRaLU33p60Ioo22FmI3P09qCp0RQJqhXUySTyPTd+kBSPf2zaxU3dh9 8skbl+uXyFsJ7KhtUqDz6dUwztOZnl/Vd7ZRwQft8tWPFIE09/ujfJpLSVbF5lUo3nSi CKlKWMRF/Bu97EJWjSMtg/qJBPt0mSUdYp560= Received: by 10.227.37.23 with SMTP id v23mr6676763wbd.94.1312394891454; Wed, 03 Aug 2011 11:08:11 -0700 (PDT) Received: from [10.55.88.129] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fr7sm864947wbb.56.2011.08.03.11.08.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Aug 2011 11:08:08 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 03 Aug 2011 19:10:03 +0100 From: Giles Heron To: Thomas Nadeau , Shahram Davari Message-ID: Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSCJDVGWiOSZjqbkq4K5mKiviMWQ== In-Reply-To: <3F8EF87B-0D7B-42CA-B542-9F37A865BA40@lucidvision.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Yaakov Stein , "pwe3@ietf.org" , Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 03 Aug 2011 18:08:18 -0000 Agreed - some operators won't want to use a CW, and on that basis I support this draft.=20 Sure, it'll take a while to move away from the router alert label and TTL approaches, but the GAL approach is definitely better than either of those... Giles On 02/08/2011 12:59, "Thomas Nadeau" wrote: >=20 > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: >=20 >> Hi, >>=20 >> I also don=B9t support this draft since I don=B9t think to solve the problem= we >> need yet a 4th type of VCCV. The best solution is to mandate CW. >=20 > While I am with you, that argument went out the window during the debates= we > had over the past 3 IETF meetings. Operators > were very clear that they do not want to mandate the use of a CW. Hence= , > Luca and I came up with this solution that narrows the > scope to 2 modes, one that handles the CW case and one that doesn't while > still both modes providing predictable OAM capabilities > for the PW. >=20 > --Tom >=20 >=20 >> =20 >> Shahram >> =20 >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Robert Rennison >> Sent: Sunday, July 31, 2011 7:40 PM >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); >> pwe3@ietf.org >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt >> =20 >> I do Not support the draft, >> =20 >> After hearing the results of the earlier user deployment poll I thought= , >> =B3 ok the way out of this mess is to migrate towards using the CW=B2. Then= I >> see this proposal and wondered what am I missing. I=B9ve still not seen t= he >> light of why adding a fourth type will simplify matters, hence in the ab= sence >> of me understanding how this will simplify matter versus complicate thin= gs, >> I=B9m against it. >> =20 >> Rob >> =20 >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Alexander Vainshtein >> Sent: Sunday, July 31, 2011 12:45 AM >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt >> =20 >> Hi all, >> I do NOT support this draft for the same reasons that Yaakov has indicat= ed. >> =20 >> Regards, >> Sasha >> =20 >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov = Stein >> [yaakov_s@rad.com] >> Sent: Friday, July 29, 2011 3:58 AM >> To: Bocci, Matthew (Matthew); pwe3@ietf.org >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt >>=20 >> I do not support ! and I can not understand how anyone can support it= ! >> =20 >> We do NOT need a fourth VCCV type, there are too many already. >> =20 >> I completely agree with the part that says if there is a CW then the ACh >> should be marked by it. >> =20 >> I do NOT agree that if the CW is not used then we should use a non-PW me= thod >> developed for MPLS-TP. >> I do NOT agree that there is any way to deprecate the use of TTL expiry = to >> mark the ACh. >> I do NOT agree that we should change mechanisms that have been widely >> deployed for many years now, >> without an extremely pressing reason. >> =20 >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have = the >> ADDITIONAL option >> for ACh marking, I might be convinced not to object as strongly. >> However, since I don't think that PWs can be limited in this matter (the= MPLS >> WG adopted the "seamless" draft) >> it would be difficult to convince me that such a limitation is possible. >> =20 >> I would have enthusiastically support this proposal had it been brought = 8 >> years ago. >> It's too late for this now. >> =20 >> Y(J)S >> =20 >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Bocci, Matthew (Matthew) >> Sent: Thursday, July 28, 2011 21:02 >> To: pwe3@ietf.org >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt >> =20 >> This email begins a two week poll to help assess if there is consensus t= o >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. >> =20 >> Please indicate whether or not you support adoption of this draft, and a= lso >> send any comments to the PWE3 list. >> =20 >> This poll will end on Friday 12th August. >> =20 >> Regards, >> =20 >> Matthew & Andy >> 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 thereo= f. >> 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 thereo= f. >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From davari@broadcom.com Wed Aug 3 12:45: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 8782921F8B39 for ; Wed, 3 Aug 2011 12:45:43 -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.000, 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 wC4tJeZuKh9e for ; Wed, 3 Aug 2011 12:45:42 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id A3E4221F8B2E for ; Wed, 3 Aug 2011 12:45:38 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 03 Aug 2011 12:50:31 -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; Wed, 3 Aug 2011 12:45:30 -0700 From: "Shahram Davari" To: "Giles Heron" , "Thomas Nadeau" Date: Wed, 3 Aug 2011 12:45:29 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSCJDVGWiOSZjqbkq4K5mKiviMWQADNlFg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com> References: <3F8EF87B-0D7B-42CA-B542-9F37A865BA40@lucidvision.com> 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: 6227790D3KO2271041-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Yaakov Stein , "pwe3@ietf.org" , Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 03 Aug 2011 19:45:43 -0000 Giles, Adding GAL to PW requires HW change, so why not just add CW and use VVCV Ty= pe 1?=20 Also what is wrong with TTL approach for non-CW? Thx Shahram -----Original Message----- From: Giles Heron [mailto:giles.heron@gmail.com]=20 Sent: Wednesday, August 03, 2011 11:10 AM To: Thomas Nadeau; Shahram Davari Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Agreed - some operators won't want to use a CW, and on that basis I support this draft.=20 Sure, it'll take a while to move away from the router alert label and TTL approaches, but the GAL approach is definitely better than either of those... Giles On 02/08/2011 12:59, "Thomas Nadeau" wrote: >=20 > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: >=20 >> Hi, >>=20 >> I also don=B9t support this draft since I don=B9t think to solve the pro= blem we >> need yet a 4th type of VCCV. The best solution is to mandate CW. >=20 > While I am with you, that argument went out the window during the debates= we > had over the past 3 IETF meetings. Operators > were very clear that they do not want to mandate the use of a CW. Hence= , > Luca and I came up with this solution that narrows the > scope to 2 modes, one that handles the CW case and one that doesn't while > still both modes providing predictable OAM capabilities > for the PW. >=20 > --Tom >=20 >=20 >> =20 >> Shahram >> =20 >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Robert Rennison >> Sent: Sunday, July 31, 2011 7:40 PM >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); >> pwe3@ietf.org >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt >> =20 >> I do Not support the draft, >> =20 >> After hearing the results of the earlier user deployment poll I thought= , >> =B3 ok the way out of this mess is to migrate towards using the CW=B2. = Then I >> see this proposal and wondered what am I missing. I=B9ve still not seen= the >> light of why adding a fourth type will simplify matters, hence in the ab= sence >> of me understanding how this will simplify matter versus complicate thin= gs, >> I=B9m against it. >> =20 >> Rob >> =20 >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Alexander Vainshtein >> Sent: Sunday, July 31, 2011 12:45 AM >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt >> =20 >> Hi all, >> I do NOT support this draft for the same reasons that Yaakov has indicat= ed. >> =20 >> Regards, >> Sasha >> =20 >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov = Stein >> [yaakov_s@rad.com] >> Sent: Friday, July 29, 2011 3:58 AM >> To: Bocci, Matthew (Matthew); pwe3@ietf.org >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt >>=20 >> I do not support ! and I can not understand how anyone can support it= ! >> =20 >> We do NOT need a fourth VCCV type, there are too many already. >> =20 >> I completely agree with the part that says if there is a CW then the ACh >> should be marked by it. >> =20 >> I do NOT agree that if the CW is not used then we should use a non-PW me= thod >> developed for MPLS-TP. >> I do NOT agree that there is any way to deprecate the use of TTL expiry = to >> mark the ACh. >> I do NOT agree that we should change mechanisms that have been widely >> deployed for many years now, >> without an extremely pressing reason. >> =20 >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have = the >> ADDITIONAL option >> for ACh marking, I might be convinced not to object as strongly. >> However, since I don't think that PWs can be limited in this matter (the= MPLS >> WG adopted the "seamless" draft) >> it would be difficult to convince me that such a limitation is possible. >> =20 >> I would have enthusiastically support this proposal had it been brought = 8 >> years ago. >> It's too late for this now. >> =20 >> Y(J)S >> =20 >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Bocci, Matthew (Matthew) >> Sent: Thursday, July 28, 2011 21:02 >> To: pwe3@ietf.org >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt >> =20 >> This email begins a two week poll to help assess if there is consensus t= o >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. >> =20 >> Please indicate whether or not you support adoption of this draft, and a= lso >> send any comments to the PWE3 list. >> =20 >> This poll will end on Friday 12th August. >> =20 >> Regards, >> =20 >> Matthew & Andy >> 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 thereo= f. >> 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 thereo= f. >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From curtis@occnc.com Wed Aug 3 16:06: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 CFDCB11E80B0 for ; Wed, 3 Aug 2011 16:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 9+WHeRsDPlVs for ; Wed, 3 Aug 2011 16:06:28 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id BF52C11E809B for ; Wed, 3 Aug 2011 16:06:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p73N5BT6021989; Wed, 3 Aug 2011 19:05:11 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108032305.p73N5BT6021989@harbor.orleans.occnc.com> To: "Shahram Davari" From: Curtis Villamizar In-reply-to: Your message of "Wed, 03 Aug 2011 12:45:29 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 03 Aug 2011 19:05:11 -0400 Sender: curtis@occnc.com Cc: Yaakov Stein , "pwe3@ietf.org" , Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 23:06:28 -0000 In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Giles, > > Adding GAL to PW requires HW change, so why not just add CW and use > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > Thx > Shahram Shahram, Adding GAL to an MPLS label stack requires hardware support. The hardware need not know if the label above the GAL is an MPLS label or a PW label, just that the next label is GAL and the label over it is not a SWAP. Unless we are talking about incredibly inflexible parser hardware, like none I've encounted recently, there should be no problem noticing a GAL below the POP or PW label and then directing the packet to OAM processing. Any remaining labels must be removed and hopefully no implementation neglects to look for BOS before deciding where the payload is supposed to be. TTL is best reserved for traceroute only (in the MS-PW case). In this case TTL-expire would occur where a label swap was called for and a GAL would be below the label containing the expired TTL. Since LDP can have transient loops, this avoids having lots of packets sent to the OAM engine should such a loop occur in a LDP signaled MPLS PSN. This yield one way to do OAM with or without CW. A GAL label is below the label for which action is taken (POP or PW termination) or below a label for which TTL has expired. This method applied to LSP and PW. I think mandating CW would be just as good a solution, but one that was rejected so this is the best we have. Curtis > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Wednesday, August 03, 2011 11:10 AM > To: Thomas Nadeau; Shahram Davari > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > Agreed - some operators won't want to use a CW, and on that basis I support > this draft. > > Sure, it'll take a while to move away from the router alert label and TTL > approaches, but the GAL approach is definitely better than either of > those... > > Giles > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > >> Hi, > >> > >> I also donąt support this draft since I donąt think to solve the problem we > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > While I am with you, that argument went out the window during the debates we > > had over the past 3 IETF meetings. Operators > > were very clear that they do not want to mandate the use of a CW. Hence, > > Luca and I came up with this solution that narrows the > > scope to 2 modes, one that handles the CW case and one that doesn't while > > still both modes providing predictable OAM capabilities > > for the PW. > > > > --Tom > > > > > >> > >> Shahram > >> > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > >> Robert Rennison > >> Sent: Sunday, July 31, 2011 7:40 PM > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > >> pwe3@ietf.org > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > >> > >> I do Not support the draft, > >> > >> After hearing the results of the earlier user deployment poll I thought, > >> ł ok the way out of this mess is to migrate towards using the CW˛. Then I > >> see this proposal and wondered what am I missing. Iąve still not seen the > >> light of why adding a fourth type will simplify matters, hence in the absence > >> of me understanding how this will simplify matter versus complicate things, > >> Iąm against it. > >> > >> Rob > >> > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > >> Alexander Vainshtein > >> Sent: Sunday, July 31, 2011 12:45 AM > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > >> > >> Hi all, > >> I do NOT support this draft for the same reasons that Yaakov has indicated. > >> > >> Regards, > >> Sasha > >> > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein > >> [yaakov_s@rad.com] > >> Sent: Friday, July 29, 2011 3:58 AM > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > >> > >> I do not support ! and I can not understand how anyone can support it ! > >> > >> We do NOT need a fourth VCCV type, there are too many already. > >> > >> I completely agree with the part that says if there is a CW then the ACh > >> should be marked by it. > >> > >> I do NOT agree that if the CW is not used then we should use a non-PW method > >> developed for MPLS-TP. > >> I do NOT agree that there is any way to deprecate the use of TTL expiry to > >> mark the ACh. > >> I do NOT agree that we should change mechanisms that have been widely > >> deployed for many years now, > >> without an extremely pressing reason. > >> > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the > >> ADDITIONAL option > >> for ACh marking, I might be convinced not to object as strongly. > >> However, since I don't think that PWs can be limited in this matter (the MPLS > >> WG adopted the "seamless" draft) > >> it would be difficult to convince me that such a limitation is possible. > >> > >> I would have enthusiastically support this proposal had it been brought 8 > >> years ago. > >> It's too late for this now. > >> > >> Y(J)S > >> > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > >> Bocci, Matthew (Matthew) > >> Sent: Thursday, July 28, 2011 21:02 > >> To: pwe3@ietf.org > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > >> > >> This email begins a two week poll to help assess if there is consensus to > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > >> > >> Please indicate whether or not you support adoption of this draft, and also > >> send any comments to the PWE3 list. > >> > >> This poll will end on Friday 12th August. > >> > >> Regards, > >> > >> Matthew & Andy > >> 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. From davari@broadcom.com Wed Aug 3 16:37: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 67F8121F854C for ; Wed, 3 Aug 2011 16:37:48 -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.000, 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 O9jQ+F8AvKd9 for ; Wed, 3 Aug 2011 16:37:47 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 00ED621F8548 for ; Wed, 3 Aug 2011 16:37:38 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 03 Aug 2011 16:42:30 -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; Wed, 3 Aug 2011 16:37:13 -0700 From: "Shahram Davari" To: "curtis@occnc.com" Date: Wed, 3 Aug 2011 16:37:08 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSMgTAIGs9flP6SR2upnOm0RM11AAArA0g Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com> References: Your message of "Wed, 03 Aug 2011 12:45:29 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com> <201108032305.p73N5BT6021989@harbor.orleans.occnc.com> In-Reply-To: <201108032305.p73N5BT6021989@harbor.orleans.occnc.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: 6227036F3W41285187-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Yaakov Stein , "pwe3@ietf.org" , Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 03 Aug 2011 23:37:48 -0000 Hi Curtis, You are absolutely correct if there is no Entropy label. But with Entropy l= abel most implementation assume a Entropy label to be BoS and below the PW = label.=20 This draft doesn't even talk about whether the GAL should be BoS or the Ent= ropy Label? In either case adding GAL would make the packet un-parsable by = most HW. Thx Shahram -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com]=20 Sent: Wednesday, August 03, 2011 4:05 PM To: Shahram Davari Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Renniso= n Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.= broadcom.com> "Shahram Davari" writes: > =20 > Giles, > =20 > Adding GAL to PW requires HW change, so why not just add CW and use > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > =20 > Thx > Shahram Shahram, Adding GAL to an MPLS label stack requires hardware support. The hardware need not know if the label above the GAL is an MPLS label or a PW label, just that the next label is GAL and the label over it is not a SWAP. Unless we are talking about incredibly inflexible parser hardware, like none I've encounted recently, there should be no problem noticing a GAL below the POP or PW label and then directing the packet to OAM processing. Any remaining labels must be removed and hopefully no implementation neglects to look for BOS before deciding where the payload is supposed to be. TTL is best reserved for traceroute only (in the MS-PW case). In this case TTL-expire would occur where a label swap was called for and a GAL would be below the label containing the expired TTL. Since LDP can have transient loops, this avoids having lots of packets sent to the OAM engine should such a loop occur in a LDP signaled MPLS PSN. This yield one way to do OAM with or without CW. A GAL label is below the label for which action is taken (POP or PW termination) or below a label for which TTL has expired. This method applied to LSP and PW. I think mandating CW would be just as good a solution, but one that was rejected so this is the best we have. Curtis > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com]=20 > Sent: Wednesday, August 03, 2011 11:10 AM > To: Thomas Nadeau; Shahram Davari > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > =20 > Agreed - some operators won't want to use a CW, and on that basis I suppo= rt > this draft.=20 > =20 > Sure, it'll take a while to move away from the router alert label and TTL > approaches, but the GAL approach is definitely better than either of > those... > =20 > Giles > =20 > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > =20 > >=20 > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > >=20 > >> Hi, > >>=20 > >> I also don=B9t support this draft since I don=B9t think to solve the p= roblem we > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > >=20 > > While I am with you, that argument went out the window during the debat= es we > > had over the past 3 IETF meetings. Operators > > were very clear that they do not want to mandate the use of a CW. Hen= ce, > > Luca and I came up with this solution that narrows the > > scope to 2 modes, one that handles the CW case and one that doesn't whi= le > > still both modes providing predictable OAM capabilities > > for the PW. > >=20 > > --Tom > >=20 > >=20 > >> =20 > >> Shahram > >> =20 > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf O= f > >> Robert Rennison > >> Sent: Sunday, July 31, 2011 7:40 PM > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > >> pwe3@ietf.org > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-0= 2.txt > >> =20 > >> I do Not support the draft, > >> =20 > >> After hearing the results of the earlier user deployment poll I thoug= ht, > >> =B3 ok the way out of this mess is to migrate towards using the CW=B2= . Then I > >> see this proposal and wondered what am I missing. I=B9ve still not se= en the > >> light of why adding a fourth type will simplify matters, hence in the = absence > >> of me understanding how this will simplify matter versus complicate th= ings, > >> I=B9m against it. > >> =20 > >> Rob > >> =20 > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf O= f > >> Alexander Vainshtein > >> Sent: Sunday, July 31, 2011 12:45 AM > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-0= 2.txt > >> =20 > >> Hi all, > >> I do NOT support this draft for the same reasons that Yaakov has indic= ated. > >> =20 > >> Regards, > >> Sasha > >> =20 > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaako= v Stein > >> [yaakov_s@rad.com] > >> Sent: Friday, July 29, 2011 3:58 AM > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-0= 2.txt > >>=20 > >> I do not support ! and I can not understand how anyone can support = it ! > >> =20 > >> We do NOT need a fourth VCCV type, there are too many already. > >> =20 > >> I completely agree with the part that says if there is a CW then the A= Ch > >> should be marked by it. > >> =20 > >> I do NOT agree that if the CW is not used then we should use a non-PW = method > >> developed for MPLS-TP. > >> I do NOT agree that there is any way to deprecate the use of TTL expir= y to > >> mark the ACh. > >> I do NOT agree that we should change mechanisms that have been widely > >> deployed for many years now, > >> without an extremely pressing reason. > >> =20 > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to hav= e the > >> ADDITIONAL option > >> for ACh marking, I might be convinced not to object as strongly. > >> However, since I don't think that PWs can be limited in this matter (t= he MPLS > >> WG adopted the "seamless" draft) > >> it would be difficult to convince me that such a limitation is possibl= e. > >> =20 > >> I would have enthusiastically support this proposal had it been brough= t 8 > >> years ago. > >> It's too late for this now. > >> =20 > >> Y(J)S > >> =20 > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf O= f > >> Bocci, Matthew (Matthew) > >> Sent: Thursday, July 28, 2011 21:02 > >> To: pwe3@ietf.org > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.tx= t > >> =20 > >> This email begins a two week poll to help assess if there is consensus= to > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > >> =20 > >> Please indicate whether or not you support adoption of this draft, and= also > >> send any comments to the PWE3 list. > >> =20 > >> This poll will end on Friday 12th August. > >> =20 > >> Regards, > >> =20 > >> Matthew & Andy > >> 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 infor= m us by > >> e-mail, phone or fax, and then delete the original and all copies ther= eof. > >> 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 infor= m us by > >> e-mail, phone or fax, and then delete the original and all copies ther= eof. From curtis@occnc.com Wed Aug 3 16:54: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 BB5BF11E80C1 for ; Wed, 3 Aug 2011 16:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151, 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 SCXdIpPdt9tq for ; Wed, 3 Aug 2011 16:54:05 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 810DF11E80B0 for ; Wed, 3 Aug 2011 16:54:05 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p73NqwfQ023870; Wed, 3 Aug 2011 19:52:58 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108032352.p73NqwfQ023870@harbor.orleans.occnc.com> To: "Shahram Davari" From: Curtis Villamizar In-reply-to: Your message of "Wed, 03 Aug 2011 16:37:08 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 03 Aug 2011 19:52:58 -0400 Sender: curtis@occnc.com Cc: Yaakov Stein , "pwe3@ietf.org" , Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 23:54:06 -0000 In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Hi Curtis, > > You are absolutely correct if there is no Entropy label. But with > Entropy label most implementation assume a Entropy label to be BoS and > below the PW label. > > This draft doesn't even talk about whether the GAL should be BoS or > the Entropy Label? In either case adding GAL would make the packet > un-parsable by most HW. > > Thx > Shahram That should be covered in this work. At least it was covered in WG email. PW, then GAL, then fat-pw (aka Flow label, which is different from Entropy label in MPLS). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... additional labels (ie: fat-pw) may be present | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Associated Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ VCCV Message Body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The above would be a better choice. The VCCV is always after the label entry with BOS (S-bit = 1). The flow label (or entropy label) must not be a reserved label. Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section 1.2 (page 5) you will find. Note that the flow label MUST NOT be an MPLS reserved label (values in the range 0..15) [RFC3032], but is otherwise unconstrained by the protocol. The flow label below GAL is needed so that all data paths which the PW can take are exercised by OAM (ie: LSP Ping used within VCCV). Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Wednesday, August 03, 2011 4:05 PM > To: Shahram Davari > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com> > "Shahram Davari" writes: > > > > Giles, > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > Thx > > Shahram > > > Shahram, > > Adding GAL to an MPLS label stack requires hardware support. The > hardware need not know if the label above the GAL is an MPLS label or > a PW label, just that the next label is GAL and the label over it is > not a SWAP. Unless we are talking about incredibly inflexible parser > hardware, like none I've encounted recently, there should be no > problem noticing a GAL below the POP or PW label and then directing > the packet to OAM processing. Any remaining labels must be removed > and hopefully no implementation neglects to look for BOS before > deciding where the payload is supposed to be. > > TTL is best reserved for traceroute only (in the MS-PW case). In this > case TTL-expire would occur where a label swap was called for and a > GAL would be below the label containing the expired TTL. Since LDP > can have transient loops, this avoids having lots of packets sent to > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > This yield one way to do OAM with or without CW. A GAL label is below > the label for which action is taken (POP or PW termination) or below a > label for which TTL has expired. This method applied to LSP and PW. > > I think mandating CW would be just as good a solution, but one that > was rejected so this is the best we have. > > Curtis > > > > -----Original Message----- > > From: Giles Heron [mailto:giles.heron@gmail.com] > > Sent: Wednesday, August 03, 2011 11:10 AM > > To: Thomas Nadeau; Shahram Davari > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > Agreed - some operators won't want to use a CW, and on that basis I support > > this draft. > > > > Sure, it'll take a while to move away from the router alert label and TTL > > approaches, but the GAL approach is definitely better than either of > > those... > > > > Giles > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > >> Hi, > > >> > > >> I also donąt support this draft since I donąt think to solve the problem we > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > While I am with you, that argument went out the window during the debates we > > > had over the past 3 IETF meetings. Operators > > > were very clear that they do not want to mandate the use of a CW. Hence, > > > Luca and I came up with this solution that narrows the > > > scope to 2 modes, one that handles the CW case and one that doesn't while > > > still both modes providing predictable OAM capabilities > > > for the PW. > > > > > > --Tom > > > > > > > > >> > > >> Shahram > > >> > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > >> Robert Rennison > > >> Sent: Sunday, July 31, 2011 7:40 PM > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > > >> pwe3@ietf.org > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > >> > > >> I do Not support the draft, > > >> > > >> After hearing the results of the earlier user deployment poll I thought, > > >> ł ok the way out of this mess is to migrate towards using the CW˛. Then I > > >> see this proposal and wondered what am I missing. Iąve still not seen the > > >> light of why adding a fourth type will simplify matters, hence in the absence > > >> of me understanding how this will simplify matter versus complicate things, > > >> Iąm against it. > > >> > > >> Rob > > >> > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > >> Alexander Vainshtein > > >> Sent: Sunday, July 31, 2011 12:45 AM > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > >> > > >> Hi all, > > >> I do NOT support this draft for the same reasons that Yaakov has indicated. > > >> > > >> Regards, > > >> Sasha > > >> > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein > > >> [yaakov_s@rad.com] > > >> Sent: Friday, July 29, 2011 3:58 AM > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > >> > > >> I do not support ! and I can not understand how anyone can support it ! > > >> > > >> We do NOT need a fourth VCCV type, there are too many already. > > >> > > >> I completely agree with the part that says if there is a CW then the ACh > > >> should be marked by it. > > >> > > >> I do NOT agree that if the CW is not used then we should use a non-PW method > > >> developed for MPLS-TP. > > >> I do NOT agree that there is any way to deprecate the use of TTL expiry to > > >> mark the ACh. > > >> I do NOT agree that we should change mechanisms that have been widely > > >> deployed for many years now, > > >> without an extremely pressing reason. > > >> > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the > > >> ADDITIONAL option > > >> for ACh marking, I might be convinced not to object as strongly. > > >> However, since I don't think that PWs can be limited in this matter (the MPLS > > >> WG adopted the "seamless" draft) > > >> it would be difficult to convince me that such a limitation is possible. > > >> > > >> I would have enthusiastically support this proposal had it been brought 8 > > >> years ago. > > >> It's too late for this now. > > >> > > >> Y(J)S > > >> > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > >> Bocci, Matthew (Matthew) > > >> Sent: Thursday, July 28, 2011 21:02 > > >> To: pwe3@ietf.org > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > >> > > >> This email begins a two week poll to help assess if there is consensus to > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > > >> > > >> Please indicate whether or not you support adoption of this draft, and also > > >> send any comments to the PWE3 list. > > >> > > >> This poll will end on Friday 12th August. > > >> > > >> Regards, > > >> > > >> Matthew & Andy > > >> 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. From curtis@occnc.com Wed Aug 3 17:02: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 2BC6311E80B7 for ; Wed, 3 Aug 2011 17:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 Jd6qV-K+omlV for ; Wed, 3 Aug 2011 17:02:57 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 881CB11E80B0 for ; Wed, 3 Aug 2011 17:02:57 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p7401nag025027; Wed, 3 Aug 2011 20:01:49 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108040001.p7401nag025027@harbor.orleans.occnc.com> To: "Bocci, Matthew (Matthew)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 28 Jul 2011 20:02:16 +0200." Date: Wed, 03 Aug 2011 20:01:49 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 00:02:58 -0000 In message "Bocci, Matthew (Matthew)" writes: > > This email begins a two week poll to help assess if there is consensus > to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group > draft. > > Please indicate whether or not you support adoption of this draft, and > also send any comments to the PWE3 list. > > This poll will end on Friday 12th August. > > Regards, > > Matthew & Andy +1 yes/support (in case it wasn't already obvious) Curtis From davari@broadcom.com Wed Aug 3 17:06: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 B632511E80B0 for ; Wed, 3 Aug 2011 17:06:29 -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.000, 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 vyLvy+-yAdPE for ; Wed, 3 Aug 2011 17:06:28 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id A9F5111E80AD for ; Wed, 3 Aug 2011 17:06:28 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 03 Aug 2011 17:11:50 -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; Wed, 3 Aug 2011 17:06:33 -0700 From: "Shahram Davari" To: "curtis@occnc.com" Date: Wed, 3 Aug 2011 17:06:31 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSOK5Lkijhxc0mQgGnFOptB76deQAAF/KQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.com> References: Your message of "Wed, 03 Aug 2011 16:37:08 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com> <201108032352.p73NqwfQ023870@harbor.orleans.occnc.com> In-Reply-To: <201108032352.p73NqwfQ023870@harbor.orleans.occnc.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: 62273C4C3W41291909-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Yaakov Stein , "pwe3@ietf.org" , Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 00:06:29 -0000 Hi Curtis, Even if we assume this format (which is not yet incorporated in the fat-pw = draft), then most hardware assume ACH is right after GAL. In this case how= is the HW supposed to examine the ACH channel Type to decide how to proces= s the packet? (unless you assume there is one engine that can process all O= AM packet types such as BFD, AIS, PSC, LSP-ping, LDI, LKR, LM, DM, etc) Thx Shahram -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com]=20 Sent: Wednesday, August 03, 2011 4:53 PM To: Shahram Davari Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.o= rg; Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.= broadcom.com> "Shahram Davari" writes: > =20 > Hi Curtis, > =20 > You are absolutely correct if there is no Entropy label. But with > Entropy label most implementation assume a Entropy label to be BoS and > below the PW label. > =20 > This draft doesn't even talk about whether the GAL should be BoS or > the Entropy Label? In either case adding GAL would make the packet > un-parsable by most HW. > =20 > Thx > Shahram That should be covered in this work. At least it was covered in WG email. PW, then GAL, then fat-pw (aka Flow label, which is different from Entropy label in MPLS). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... additional labels (ie: fat-pw) may be present | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Associated Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ VCCV Message Body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The above would be a better choice. The VCCV is always after the label entry with BOS (S-bit =3D 1). The flow label (or entropy label) must not be a reserved label. Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section 1.2 (page 5) you will find. Note that the flow label MUST NOT be an MPLS reserved label (values in the range 0..15) [RFC3032], but is otherwise unconstrained by the protocol. The flow label below GAL is needed so that all data paths which the PW can take are exercised by OAM (ie: LSP Ping used within VCCV). Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com]=20 > Sent: Wednesday, August 03, 2011 4:05 PM > To: Shahram Davari > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Renni= son > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > =20 > =20 > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.a= d.broadcom.com> > "Shahram Davari" writes: > > =20 > > Giles, > > =20 > > Adding GAL to PW requires HW change, so why not just add CW and use > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > =20 > > Thx > > Shahram > =20 > =20 > Shahram, > =20 > Adding GAL to an MPLS label stack requires hardware support. The > hardware need not know if the label above the GAL is an MPLS label or > a PW label, just that the next label is GAL and the label over it is > not a SWAP. Unless we are talking about incredibly inflexible parser > hardware, like none I've encounted recently, there should be no > problem noticing a GAL below the POP or PW label and then directing > the packet to OAM processing. Any remaining labels must be removed > and hopefully no implementation neglects to look for BOS before > deciding where the payload is supposed to be. > =20 > TTL is best reserved for traceroute only (in the MS-PW case). In this > case TTL-expire would occur where a label swap was called for and a > GAL would be below the label containing the expired TTL. Since LDP > can have transient loops, this avoids having lots of packets sent to > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > =20 > This yield one way to do OAM with or without CW. A GAL label is below > the label for which action is taken (POP or PW termination) or below a > label for which TTL has expired. This method applied to LSP and PW. > =20 > I think mandating CW would be just as good a solution, but one that > was rejected so this is the best we have. > =20 > Curtis > =20 > =20 > > -----Original Message----- > > From: Giles Heron [mailto:giles.heron@gmail.com]=20 > > Sent: Wednesday, August 03, 2011 11:10 AM > > To: Thomas Nadeau; Shahram Davari > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt > > =20 > > Agreed - some operators won't want to use a CW, and on that basis I sup= port > > this draft.=20 > > =20 > > Sure, it'll take a while to move away from the router alert label and T= TL > > approaches, but the GAL approach is definitely better than either of > > those... > > =20 > > Giles > > =20 > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > =20 > > >=20 > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > >=20 > > >> Hi, > > >>=20 > > >> I also don=B9t support this draft since I don=B9t think to solve the= problem we > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > >=20 > > > While I am with you, that argument went out the window during the deb= ates we > > > had over the past 3 IETF meetings. Operators > > > were very clear that they do not want to mandate the use of a CW. H= ence, > > > Luca and I came up with this solution that narrows the > > > scope to 2 modes, one that handles the CW case and one that doesn't w= hile > > > still both modes providing predictable OAM capabilities > > > for the PW. > > >=20 > > > --Tom > > >=20 > > >=20 > > >> =20 > > >> Shahram > > >> =20 > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf= Of > > >> Robert Rennison > > >> Sent: Sunday, July 31, 2011 7:40 PM > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > > >> pwe3@ietf.org > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2= -02.txt > > >> =20 > > >> I do Not support the draft, > > >> =20 > > >> After hearing the results of the earlier user deployment poll I tho= ught, > > >> =B3 ok the way out of this mess is to migrate towards using the CW= =B2. Then I > > >> see this proposal and wondered what am I missing. I=B9ve still not = seen the > > >> light of why adding a fourth type will simplify matters, hence in th= e absence > > >> of me understanding how this will simplify matter versus complicate = things, > > >> I=B9m against it. > > >> =20 > > >> Rob > > >> =20 > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf= Of > > >> Alexander Vainshtein > > >> Sent: Sunday, July 31, 2011 12:45 AM > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2= -02.txt > > >> =20 > > >> Hi all, > > >> I do NOT support this draft for the same reasons that Yaakov has ind= icated. > > >> =20 > > >> Regards, > > >> Sasha > > >> =20 > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaa= kov Stein > > >> [yaakov_s@rad.com] > > >> Sent: Friday, July 29, 2011 3:58 AM > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2= -02.txt > > >>=20 > > >> I do not support ! and I can not understand how anyone can suppor= t it ! > > >> =20 > > >> We do NOT need a fourth VCCV type, there are too many already. > > >> =20 > > >> I completely agree with the part that says if there is a CW then the= ACh > > >> should be marked by it. > > >> =20 > > >> I do NOT agree that if the CW is not used then we should use a non-P= W method > > >> developed for MPLS-TP. > > >> I do NOT agree that there is any way to deprecate the use of TTL exp= iry to > > >> mark the ACh. > > >> I do NOT agree that we should change mechanisms that have been widel= y > > >> deployed for many years now, > > >> without an extremely pressing reason. > > >> =20 > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to h= ave the > > >> ADDITIONAL option > > >> for ACh marking, I might be convinced not to object as strongly. > > >> However, since I don't think that PWs can be limited in this matter = (the MPLS > > >> WG adopted the "seamless" draft) > > >> it would be difficult to convince me that such a limitation is possi= ble. > > >> =20 > > >> I would have enthusiastically support this proposal had it been brou= ght 8 > > >> years ago. > > >> It's too late for this now. > > >> =20 > > >> Y(J)S > > >> =20 > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf= Of > > >> Bocci, Matthew (Matthew) > > >> Sent: Thursday, July 28, 2011 21:02 > > >> To: pwe3@ietf.org > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt > > >> =20 > > >> This email begins a two week poll to help assess if there is consens= us to > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > > >> =20 > > >> Please indicate whether or not you support adoption of this draft, a= nd also > > >> send any comments to the PWE3 list. > > >> =20 > > >> This poll will end on Friday 12th August. > > >> =20 > > >> Regards, > > >> =20 > > >> Matthew & Andy > > >> This e-mail message is intended for the recipient only and contains > > >> information which is CONFIDENTIAL and which may be proprietary to EC= I > > >> Telecom. If you have received this transmission in error, please inf= orm us by > > >> e-mail, phone or fax, and then delete the original and all copies th= ereof. > > >> This e-mail message is intended for the recipient only and contains > > >> information which is CONFIDENTIAL and which may be proprietary to EC= I > > >> Telecom. If you have received this transmission in error, please inf= orm us by > > >> e-mail, phone or fax, and then delete the original and all copies th= ereof. From curtis@occnc.com Thu Aug 4 06:40: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 B2F7321F8AFE for ; Thu, 4 Aug 2011 06:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 3oH-nlGZe1gG for ; Thu, 4 Aug 2011 06:40:00 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5D38B21F8AF6 for ; Thu, 4 Aug 2011 06:40:00 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p74DcrxU043641; Thu, 4 Aug 2011 09:38:53 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108041338.p74DcrxU043641@harbor.orleans.occnc.com> To: "Shahram Davari" From: Curtis Villamizar In-reply-to: Your message of "Wed, 03 Aug 2011 17:06:31 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 04 Aug 2011 09:38:53 -0400 Sender: curtis@occnc.com Cc: Yaakov Stein , "pwe3@ietf.org" , Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:40:01 -0000 In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Hi Curtis, > > Even if we assume this format (which is not yet incorporated in the > fat-pw draft), then most hardware assume ACH is right after GAL. In > this case how is the HW supposed to examine the ACH channel Type to > decide how to process the packet? (unless you assume there is one > engine that can process all OAM packet types such as BFD, AIS, PSC, > LSP-ping, LDI, LKR, LM, DM, etc) > > Thx > Shahram Shahram, This doesn't need to go in the fat-pw draft. It needs to go into the draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic when some other feature, fat-pw or other, puts a label under the PW label. The GAL goes after the PW and before the other labels. A proper multipath distribution will skip any reserved label and use the rest of the label stack to load balance. This allows spraying across the entropy space or testing a spacific payload label stack that has yielded trouble. Hardware that assumes ACH is right after GAL when the S-bit is not set on the GAL is broken. The payload (ACH) is after the BOS (aka S-bit = 1). The IETF has never been sympathetic of broken hardware and should not be since we would halt progress. If the hardware is broken, then the fat-pw label can be omitted but only one path through any multipath would be tested. It would still work for TP, but not work in general. PW does not require TP. The fat-pw work is explicitly done for multipath because multipath is used a lot in deployed networks and isn't going away. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Wednesday, August 03, 2011 4:53 PM > To: Shahram Davari > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com> > "Shahram Davari" writes: > > > > Hi Curtis, > > > > You are absolutely correct if there is no Entropy label. But with > > Entropy label most implementation assume a Entropy label to be BoS and > > below the PW label. > > > > This draft doesn't even talk about whether the GAL should be BoS or > > the Entropy Label? In either case adding GAL would make the packet > > un-parsable by most HW. > > > > Thx > > Shahram > > > That should be covered in this work. At least it was covered in WG > email. PW, then GAL, then fat-pw (aka Flow label, which is different > from Entropy label in MPLS). > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GAL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... additional labels (ie: fat-pw) may be present | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|Version| Reserved | Associated Channel Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ VCCV Message Body ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The above would be a better choice. The VCCV is always after the > label entry with BOS (S-bit = 1). > > The flow label (or entropy label) must not be a reserved label. > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > 1.2 (page 5) you will find. > > Note that the flow label MUST NOT be an MPLS reserved label (values > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > protocol. > > > The flow label below GAL is needed so that all data paths which the PW > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, August 03, 2011 4:05 PM > > To: Shahram Davari > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Giles, > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > Adding GAL to an MPLS label stack requires hardware support. The > > hardware need not know if the label above the GAL is an MPLS label or > > a PW label, just that the next label is GAL and the label over it is > > not a SWAP. Unless we are talking about incredibly inflexible parser > > hardware, like none I've encounted recently, there should be no > > problem noticing a GAL below the POP or PW label and then directing > > the packet to OAM processing. Any remaining labels must be removed > > and hopefully no implementation neglects to look for BOS before > > deciding where the payload is supposed to be. > > > > TTL is best reserved for traceroute only (in the MS-PW case). In this > > case TTL-expire would occur where a label swap was called for and a > > GAL would be below the label containing the expired TTL. Since LDP > > can have transient loops, this avoids having lots of packets sent to > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > This yield one way to do OAM with or without CW. A GAL label is below > > the label for which action is taken (POP or PW termination) or below a > > label for which TTL has expired. This method applied to LSP and PW. > > > > I think mandating CW would be just as good a solution, but one that > > was rejected so this is the best we have. > > > > Curtis > > > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > To: Thomas Nadeau; Shahram Davari > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > Agreed - some operators won't want to use a CW, and on that basis I support > > > this draft. > > > > > > Sure, it'll take a while to move away from the router alert label and TTL > > > approaches, but the GAL approach is definitely better than either of > > > those... > > > > > > Giles > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > >> Hi, > > > >> > > > >> I also donąt support this draft since I donąt think to solve the problem we > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > While I am with you, that argument went out the window during the debates we > > > > had over the past 3 IETF meetings. Operators > > > > were very clear that they do not want to mandate the use of a CW. Hence, > > > > Luca and I came up with this solution that narrows the > > > > scope to 2 modes, one that handles the CW case and one that doesn't while > > > > still both modes providing predictable OAM capabilities > > > > for the PW. > > > > > > > > --Tom > > > > > > > > > > > >> > > > >> Shahram > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > >> Robert Rennison > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > > > >> pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> I do Not support the draft, > > > >> > > > >> After hearing the results of the earlier user deployment poll I thought, > > > >> ł ok the way out of this mess is to migrate towards using the CW˛. Then I > > > >> see this proposal and wondered what am I missing. Iąve still not seen the > > > >> light of why adding a fourth type will simplify matters, hence in the absence > > > >> of me understanding how this will simplify matter versus complicate things, > > > >> Iąm against it. > > > >> > > > >> Rob > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > >> Alexander Vainshtein > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> Hi all, > > > >> I do NOT support this draft for the same reasons that Yaakov has indicated. > > > >> > > > >> Regards, > > > >> Sasha > > > >> > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein > > > >> [yaakov_s@rad.com] > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> I do not support ! and I can not understand how anyone can support it ! > > > >> > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > >> > > > >> I completely agree with the part that says if there is a CW then the ACh > > > >> should be marked by it. > > > >> > > > >> I do NOT agree that if the CW is not used then we should use a non-PW method > > > >> developed for MPLS-TP. > > > >> I do NOT agree that there is any way to deprecate the use of TTL expiry to > > > >> mark the ACh. > > > >> I do NOT agree that we should change mechanisms that have been widely > > > >> deployed for many years now, > > > >> without an extremely pressing reason. > > > >> > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the > > > >> ADDITIONAL option > > > >> for ACh marking, I might be convinced not to object as strongly. > > > >> However, since I don't think that PWs can be limited in this matter (the MPLS > > > >> WG adopted the "seamless" draft) > > > >> it would be difficult to convince me that such a limitation is possible. > > > >> > > > >> I would have enthusiastically support this proposal had it been brought 8 > > > >> years ago. > > > >> It's too late for this now. > > > >> > > > >> Y(J)S > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > >> Bocci, Matthew (Matthew) > > > >> Sent: Thursday, July 28, 2011 21:02 > > > >> To: pwe3@ietf.org > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > >> > > > >> This email begins a two week poll to help assess if there is consensus to > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > > > >> > > > >> Please indicate whether or not you support adoption of this draft, and also > > > >> send any comments to the PWE3 list. > > > >> > > > >> This poll will end on Friday 12th August. > > > >> > > > >> Regards, > > > >> > > > >> Matthew & Andy > > > >> 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. From tnadeau@lucidvision.com Thu Aug 4 06: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 8154D21F8515 for ; Thu, 4 Aug 2011 06:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 6s1TSTbRvJWU for ; Thu, 4 Aug 2011 06:42:42 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 381C421F8512 for ; Thu, 4 Aug 2011 06:42:42 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 80A891D5294B; Thu, 4 Aug 2011 09:42:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Thomas Nadeau In-Reply-To: <201108032352.p73NqwfQ023870@harbor.orleans.occnc.com> Date: Thu, 4 Aug 2011 09:42:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108032352.p73NqwfQ023870@harbor.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1244.3) Cc: Yaakov Stein , "pwe3@ietf.org" , Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 13:42:43 -0000 Curtis, That is a good point, and we will modify the draft to handle the = FAT PW case. --Tom >=20 > In message = <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.c= om> > "Shahram Davari" writes: >>=20 >> Hi Curtis, >>=20 >> You are absolutely correct if there is no Entropy label. But with >> Entropy label most implementation assume a Entropy label to be BoS = and >> below the PW label. >>=20 >> This draft doesn't even talk about whether the GAL should be BoS or >> the Entropy Label? In either case adding GAL would make the packet >> un-parsable by most HW. >>=20 >> Thx >> Shahram >=20 >=20 > That should be covered in this work. At least it was covered in WG > email. PW, then GAL, then fat-pw (aka Flow label, which is different > from Entropy label in MPLS). >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GAL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... additional labels (ie: fat-pw) may be present | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|Version| Reserved | Associated Channel Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ VCCV Message Body ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The above would be a better choice. The VCCV is always after the > label entry with BOS (S-bit =3D 1). >=20 > The flow label (or entropy label) must not be a reserved label. > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > 1.2 (page 5) you will find. >=20 > Note that the flow label MUST NOT be an MPLS reserved label (values > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > protocol. >=20 >=20 > The flow label below GAL is needed so that all data paths which the PW > can take are exercised by OAM (ie: LSP Ping used within VCCV). >=20 > Curtis >=20 >=20 >> -----Original Message----- >> From: curtis@occnc.com [mailto:curtis@occnc.com]=20 >> Sent: Wednesday, August 03, 2011 4:05 PM >> To: Shahram Davari >> Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert = Rennison >> Subject: Re: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt >>=20 >>=20 >> In message = <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.c= om> >> "Shahram Davari" writes: >>>=20 >>> Giles, >>>=20 >>> Adding GAL to PW requires HW change, so why not just add CW and use >>> VVCV Type 1? Also what is wrong with TTL approach for non-CW? >>>=20 >>> Thx >>> Shahram >>=20 >>=20 >> Shahram, >>=20 >> Adding GAL to an MPLS label stack requires hardware support. The >> hardware need not know if the label above the GAL is an MPLS label or >> a PW label, just that the next label is GAL and the label over it is >> not a SWAP. Unless we are talking about incredibly inflexible parser >> hardware, like none I've encounted recently, there should be no >> problem noticing a GAL below the POP or PW label and then directing >> the packet to OAM processing. Any remaining labels must be removed >> and hopefully no implementation neglects to look for BOS before >> deciding where the payload is supposed to be. >>=20 >> TTL is best reserved for traceroute only (in the MS-PW case). In = this >> case TTL-expire would occur where a label swap was called for and a >> GAL would be below the label containing the expired TTL. Since LDP >> can have transient loops, this avoids having lots of packets sent to >> the OAM engine should such a loop occur in a LDP signaled MPLS PSN. >>=20 >> This yield one way to do OAM with or without CW. A GAL label is = below >> the label for which action is taken (POP or PW termination) or below = a >> label for which TTL has expired. This method applied to LSP and PW. >>=20 >> I think mandating CW would be just as good a solution, but one that >> was rejected so this is the best we have. >>=20 >> Curtis >>=20 >>=20 >>> -----Original Message----- >>> From: Giles Heron [mailto:giles.heron@gmail.com]=20 >>> Sent: Wednesday, August 03, 2011 11:10 AM >>> To: Thomas Nadeau; Shahram Davari >>> Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison >>> Subject: Re: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt >>>=20 >>> Agreed - some operators won't want to use a CW, and on that basis I = support >>> this draft.=20 >>>=20 >>> Sure, it'll take a while to move away from the router alert label = and TTL >>> approaches, but the GAL approach is definitely better than either of >>> those... >>>=20 >>> Giles >>>=20 >>> On 02/08/2011 12:59, "Thomas Nadeau" = wrote: >>>=20 >>>>=20 >>>> On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I also don=92t support this draft since I don=92t think to solve = the problem we >>>>> need yet a 4th type of VCCV. The best solution is to mandate CW. >>>>=20 >>>> While I am with you, that argument went out the window during the = debates we >>>> had over the past 3 IETF meetings. Operators >>>> were very clear that they do not want to mandate the use of a CW. = Hence, >>>> Luca and I came up with this solution that narrows the >>>> scope to 2 modes, one that handles the CW case and one that doesn't = while >>>> still both modes providing predictable OAM capabilities >>>> for the PW. >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>>=20 >>>>> Shahram >>>>>=20 >>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On = Behalf Of >>>>> Robert Rennison >>>>> Sent: Sunday, July 31, 2011 7:40 PM >>>>> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); >>>>> pwe3@ietf.org >>>>> Subject: Re: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt >>>>>=20 >>>>> I do Not support the draft, >>>>>=20 >>>>> After hearing the results of the earlier user deployment poll I = thought, >>>>> =93 ok the way out of this mess is to migrate towards using the = CW=94. Then I >>>>> see this proposal and wondered what am I missing. I=92ve still = not seen the >>>>> light of why adding a fourth type will simplify matters, hence in = the absence >>>>> of me understanding how this will simplify matter versus = complicate things, >>>>> I=92m against it. >>>>>=20 >>>>> Rob >>>>>=20 >>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On = Behalf Of >>>>> Alexander Vainshtein >>>>> Sent: Sunday, July 31, 2011 12:45 AM >>>>> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org >>>>> Subject: Re: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt >>>>>=20 >>>>> Hi all, >>>>> I do NOT support this draft for the same reasons that Yaakov has = indicated. >>>>>=20 >>>>> Regards, >>>>> Sasha >>>>>=20 >>>>> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of = Yaakov Stein >>>>> [yaakov_s@rad.com] >>>>> Sent: Friday, July 29, 2011 3:58 AM >>>>> To: Bocci, Matthew (Matthew); pwe3@ietf.org >>>>> Subject: Re: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt >>>>>=20 >>>>> I do not support ! and I can not understand how anyone can = support it ! >>>>>=20 >>>>> We do NOT need a fourth VCCV type, there are too many already. >>>>>=20 >>>>> I completely agree with the part that says if there is a CW then = the ACh >>>>> should be marked by it. >>>>>=20 >>>>> I do NOT agree that if the CW is not used then we should use a = non-PW method >>>>> developed for MPLS-TP. >>>>> I do NOT agree that there is any way to deprecate the use of TTL = expiry to >>>>> mark the ACh. >>>>> I do NOT agree that we should change mechanisms that have been = widely >>>>> deployed for many years now, >>>>> without an extremely pressing reason. >>>>>=20 >>>>> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to = have the >>>>> ADDITIONAL option >>>>> for ACh marking, I might be convinced not to object as strongly. >>>>> However, since I don't think that PWs can be limited in this = matter (the MPLS >>>>> WG adopted the "seamless" draft) >>>>> it would be difficult to convince me that such a limitation is = possible. >>>>>=20 >>>>> I would have enthusiastically support this proposal had it been = brought 8 >>>>> years ago. >>>>> It's too late for this now. >>>>>=20 >>>>> Y(J)S >>>>>=20 >>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On = Behalf Of >>>>> Bocci, Matthew (Matthew) >>>>> Sent: Thursday, July 28, 2011 21:02 >>>>> To: pwe3@ietf.org >>>>> Subject: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt >>>>>=20 >>>>> This email begins a two week poll to help assess if there is = consensus to >>>>> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group = draft. >>>>>=20 >>>>> Please indicate whether or not you support adoption of this draft, = and also >>>>> send any comments to the PWE3 list. >>>>>=20 >>>>> This poll will end on Friday 12th August. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Matthew & Andy >>>>> 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. >=20 From curtis@occnc.com Thu Aug 4 06:54: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 E96AC21F8B4D for ; Thu, 4 Aug 2011 06:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 3iycxDKhO1YT for ; Thu, 4 Aug 2011 06:53:59 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABE321F8777 for ; Thu, 4 Aug 2011 06:53:58 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p74Dqrqi044326; Thu, 4 Aug 2011 09:52:53 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108041352.p74Dqrqi044326@harbor.orleans.occnc.com> To: Thomas Nadeau From: Curtis Villamizar In-reply-to: Your message of "Thu, 04 Aug 2011 09:42:56 EDT." Date: Thu, 04 Aug 2011 09:52:53 -0400 Sender: curtis@occnc.com Cc: Yaakov Stein , "pwe3@ietf.org" , Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:54:00 -0000 In message Thomas Nadeau writes: > > > Curtis, > > That is a good point, and we will modify the draft to handle > the FAT PW case. > > --Tom Gracias mi amigo. [which is about all I remember from HS spanish] Curtis > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com> > > "Shahram Davari" writes: > >> > >> Hi Curtis, > >> > >> You are absolutely correct if there is no Entropy label. But with > >> Entropy label most implementation assume a Entropy label to be BoS and > >> below the PW label. > >> > >> This draft doesn't even talk about whether the GAL should be BoS or > >> the Entropy Label? In either case adding GAL would make the packet > >> un-parsable by most HW. > >> > >> Thx > >> Shahram > > > > > > That should be covered in this work. At least it was covered in WG > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > from Entropy label in MPLS). > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PW Label | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GAL | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ... additional labels (ie: fat-pw) may be present | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ VCCV Message Body ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > The above would be a better choice. The VCCV is always after the > > label entry with BOS (S-bit = 1). > > > > The flow label (or entropy label) must not be a reserved label. > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > > 1.2 (page 5) you will find. > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > protocol. > > > > > > The flow label below GAL is needed so that all data paths which the PW > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > Curtis > > > > > >> -----Original Message----- > >> From: curtis@occnc.com [mailto:curtis@occnc.com] > >> Sent: Wednesday, August 03, 2011 4:05 PM > >> To: Shahram Davari > >> Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > >> > >> > >> In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com> > >> "Shahram Davari" writes: > >>> > >>> Giles, > >>> > >>> Adding GAL to PW requires HW change, so why not just add CW and use > >>> VVCV Type 1? Also what is wrong with TTL approach for non-CW? > >>> > >>> Thx > >>> Shahram > >> > >> > >> Shahram, > >> > >> Adding GAL to an MPLS label stack requires hardware support. The > >> hardware need not know if the label above the GAL is an MPLS label or > >> a PW label, just that the next label is GAL and the label over it is > >> not a SWAP. Unless we are talking about incredibly inflexible parser > >> hardware, like none I've encounted recently, there should be no > >> problem noticing a GAL below the POP or PW label and then directing > >> the packet to OAM processing. Any remaining labels must be removed > >> and hopefully no implementation neglects to look for BOS before > >> deciding where the payload is supposed to be. > >> > >> TTL is best reserved for traceroute only (in the MS-PW case). In this > >> case TTL-expire would occur where a label swap was called for and a > >> GAL would be below the label containing the expired TTL. Since LDP > >> can have transient loops, this avoids having lots of packets sent to > >> the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > >> > >> This yield one way to do OAM with or without CW. A GAL label is below > >> the label for which action is taken (POP or PW termination) or below a > >> label for which TTL has expired. This method applied to LSP and PW. > >> > >> I think mandating CW would be just as good a solution, but one that > >> was rejected so this is the best we have. > >> > >> Curtis > >> > >> > >>> -----Original Message----- > >>> From: Giles Heron [mailto:giles.heron@gmail.com] > >>> Sent: Wednesday, August 03, 2011 11:10 AM > >>> To: Thomas Nadeau; Shahram Davari > >>> Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > >>> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > >>> > >>> Agreed - some operators won't want to use a CW, and on that basis I support > >>> this draft. > >>> > >>> Sure, it'll take a while to move away from the router alert label and TTL > >>> approaches, but the GAL approach is definitely better than either of > >>> those... > >>> > >>> Giles > >>> > >>> On 02/08/2011 12:59, "Thomas Nadeau" wrote: > >>> > >>>> > >>>> On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> I also don’t support this draft since I don’t think to solve the problem we > >>>>> need yet a 4th type of VCCV. The best solution is to mandate CW. > >>>> > >>>> While I am with you, that argument went out the window during the debates we > >>>> had over the past 3 IETF meetings. Operators > >>>> were very clear that they do not want to mandate the use of a CW. Hence, > >>>> Luca and I came up with this solution that narrows the > >>>> scope to 2 modes, one that handles the CW case and one that doesn't while > >>>> still both modes providing predictable OAM capabilities > >>>> for the PW. > >>>> > >>>> --Tom > >>>> > >>>> > >>>>> > >>>>> Shahram > >>>>> > >>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > >>>>> Robert Rennison > >>>>> Sent: Sunday, July 31, 2011 7:40 PM > >>>>> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > >>>>> pwe3@ietf.org > >>>>> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > >>>>> > >>>>> I do Not support the draft, > >>>>> > >>>>> After hearing the results of the earlier user deployment poll I thought, > >>>>> “ ok the way out of this mess is to migrate towards using the CW”. Then I > >>>>> see this proposal and wondered what am I missing. I’ve still not seen the > >>>>> light of why adding a fourth type will simplify matters, hence in the absence > >>>>> of me understanding how this will simplify matter versus complicate things, > >>>>> I’m against it. > >>>>> > >>>>> Rob > >>>>> > >>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > >>>>> Alexander Vainshtein > >>>>> Sent: Sunday, July 31, 2011 12:45 AM > >>>>> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > >>>>> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > >>>>> > >>>>> Hi all, > >>>>> I do NOT support this draft for the same reasons that Yaakov has indicated. > >>>>> > >>>>> Regards, > >>>>> Sasha > >>>>> > >>>>> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein > >>>>> [yaakov_s@rad.com] > >>>>> Sent: Friday, July 29, 2011 3:58 AM > >>>>> To: Bocci, Matthew (Matthew); pwe3@ietf.org > >>>>> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > >>>>> > >>>>> I do not support ! and I can not understand how anyone can support it ! > >>>>> > >>>>> We do NOT need a fourth VCCV type, there are too many already. > >>>>> > >>>>> I completely agree with the part that says if there is a CW then the ACh > >>>>> should be marked by it. > >>>>> > >>>>> I do NOT agree that if the CW is not used then we should use a non-PW method > >>>>> developed for MPLS-TP. > >>>>> I do NOT agree that there is any way to deprecate the use of TTL expiry to > >>>>> mark the ACh. > >>>>> I do NOT agree that we should change mechanisms that have been widely > >>>>> deployed for many years now, > >>>>> without an extremely pressing reason. > >>>>> > >>>>> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the > >>>>> ADDITIONAL option > >>>>> for ACh marking, I might be convinced not to object as strongly. > >>>>> However, since I don't think that PWs can be limited in this matter (the MPLS > >>>>> WG adopted the "seamless" draft) > >>>>> it would be difficult to convince me that such a limitation is possible. > >>>>> > >>>>> I would have enthusiastically support this proposal had it been brought 8 > >>>>> years ago. > >>>>> It's too late for this now. > >>>>> > >>>>> Y(J)S > >>>>> > >>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > >>>>> Bocci, Matthew (Matthew) > >>>>> Sent: Thursday, July 28, 2011 21:02 > >>>>> To: pwe3@ietf.org > >>>>> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > >>>>> > >>>>> This email begins a two week poll to help assess if there is consensus to > >>>>> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > >>>>> > >>>>> Please indicate whether or not you support adoption of this draft, and also > >>>>> send any comments to the PWE3 list. > >>>>> > >>>>> This poll will end on Friday 12th August. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Matthew & Andy > >>>>> 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. From shane@castlepoint.net Thu Aug 4 07:33: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 D422921F8AE6 for ; Thu, 4 Aug 2011 07:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqd9aP8iLEqG for ; Thu, 4 Aug 2011 07:33:41 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id DCDF321F8A57 for ; Thu, 4 Aug 2011 07:33:40 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 73191268037; Thu, 4 Aug 2011 08:33:55 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 04 Aug 2011 08:33:55 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=62710; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Shane Amante In-Reply-To: Date: Thu, 4 Aug 2011 08:33:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <33438AA8-6DFD-4F7D-A17B-08817D9E21D7@castlepoint.net> References: To: Giles Heron X-Mailer: Apple Mail (2.1084) Cc: Yaakov Stein , "pwe3@ietf.org" , Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 14:33:42 -0000 I support this draft becoming a WG doc. On Aug 3, 2011, at 12:10 PM, Giles Heron wrote: > Agreed - some operators won't want to use a CW, and on that basis I = support > this draft.=20 +1 > Sure, it'll take a while to move away from the router alert label and = TTL > approaches, but the GAL approach is definitely better than either of > those... +1 We need a single, /unified/ PW VCCV method across all of our platforms, = and the GAL approach is superior to CW. =20 -shane >=20 > Giles >=20 > On 02/08/2011 12:59, "Thomas Nadeau" wrote: >=20 >>=20 >> On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: >>=20 >>> Hi, >>>=20 >>> I also don=92t support this draft since I don=92t think to solve the = problem we >>> need yet a 4th type of VCCV. The best solution is to mandate CW. >>=20 >> While I am with you, that argument went out the window during the = debates we >> had over the past 3 IETF meetings. Operators >> were very clear that they do not want to mandate the use of a CW. = Hence, >> Luca and I came up with this solution that narrows the >> scope to 2 modes, one that handles the CW case and one that doesn't = while >> still both modes providing predictable OAM capabilities >> for the PW. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Shahram >>>=20 >>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of >>> Robert Rennison >>> Sent: Sunday, July 31, 2011 7:40 PM >>> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); >>> pwe3@ietf.org >>> Subject: Re: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt >>>=20 >>> I do Not support the draft, >>>=20 >>> After hearing the results of the earlier user deployment poll I = thought, >>> =93 ok the way out of this mess is to migrate towards using the = CW=94. Then I >>> see this proposal and wondered what am I missing. I=92ve still not = seen the >>> light of why adding a fourth type will simplify matters, hence in = the absence >>> of me understanding how this will simplify matter versus complicate = things, >>> I=92m against it. >>>=20 >>> Rob >>>=20 >>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of >>> Alexander Vainshtein >>> Sent: Sunday, July 31, 2011 12:45 AM >>> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org >>> Subject: Re: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt >>>=20 >>> Hi all, >>> I do NOT support this draft for the same reasons that Yaakov has = indicated. >>>=20 >>> Regards, >>> Sasha >>>=20 >>> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of = Yaakov Stein >>> [yaakov_s@rad.com] >>> Sent: Friday, July 29, 2011 3:58 AM >>> To: Bocci, Matthew (Matthew); pwe3@ietf.org >>> Subject: Re: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt >>>=20 >>> I do not support ! and I can not understand how anyone can = support it ! >>>=20 >>> We do NOT need a fourth VCCV type, there are too many already. >>>=20 >>> I completely agree with the part that says if there is a CW then the = ACh >>> should be marked by it. >>>=20 >>> I do NOT agree that if the CW is not used then we should use a = non-PW method >>> developed for MPLS-TP. >>> I do NOT agree that there is any way to deprecate the use of TTL = expiry to >>> mark the ACh. >>> I do NOT agree that we should change mechanisms that have been = widely >>> deployed for many years now, >>> without an extremely pressing reason. >>>=20 >>> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to = have the >>> ADDITIONAL option >>> for ACh marking, I might be convinced not to object as strongly. >>> However, since I don't think that PWs can be limited in this matter = (the MPLS >>> WG adopted the "seamless" draft) >>> it would be difficult to convince me that such a limitation is = possible. >>>=20 >>> I would have enthusiastically support this proposal had it been = brought 8 >>> years ago. >>> It's too late for this now. >>>=20 >>> Y(J)S >>>=20 >>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of >>> Bocci, Matthew (Matthew) >>> Sent: Thursday, July 28, 2011 21:02 >>> To: pwe3@ietf.org >>> Subject: [PWE3] Poll for WG adoption of = draft-nadeau-pwe3-vccv-2-02.txt >>>=20 >>> This email begins a two week poll to help assess if there is = consensus to >>> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. >>>=20 >>> Please indicate whether or not you support adoption of this draft, = and also >>> send any comments to the PWE3 list. >>>=20 >>> This poll will end on Friday 12th August. >>>=20 >>> Regards, >>>=20 >>> Matthew & Andy >>> 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. >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>=20 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From davari@broadcom.com Thu Aug 4 07:48: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 3EA7721F8AED for ; Thu, 4 Aug 2011 07:48:53 -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.000, 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 cV+R4z-QRyKx for ; Thu, 4 Aug 2011 07:48:52 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF3721F8B03 for ; Thu, 4 Aug 2011 07:48:52 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 04 Aug 2011 07:48:02 -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; Thu, 4 Aug 2011 07:42:23 -0700 From: "Shahram Davari" To: "'curtis@occnc.com'" Date: Thu, 4 Aug 2011 07:42:21 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSrBRnCGQL7B1FSUadJ84NispK9AACKN0v Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <201108041338.p74DcrxU043641@harbor.orleans.occnc.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: 62246EAB3DK7685414-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 14:48:53 -0000 I don't agree with you. This is not about broken HW. Before this draft how = was one supposed to process a packet with GAL in the middle of the label s= tack?=20 What if this draft had decided to put GAL after entropy? Then the HW proces= sing would have been completely different from what you are proposing on th= e fly now. =20 You are making imaginary assumptions that HW should be able to process what= was in your mind.=20 I strongly object to this unnecessary draft. If you look at RFCs there are = always cases that we wished we had done it differently, but we are not goin= g to change them since in most cases like this one it is too late. Sorry bu= t that is the fact. Thx Shahram ----- Original Message ----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 06:38 AM=0A= To: Shahram Davari Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein = ; pwe3@ietf.org ; Robert Rennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.= broadcom.com> "Shahram Davari" writes: > =20 > Hi Curtis, > =20 > Even if we assume this format (which is not yet incorporated in the > fat-pw draft), then most hardware assume ACH is right after GAL. In > this case how is the HW supposed to examine the ACH channel Type to > decide how to process the packet? (unless you assume there is one > engine that can process all OAM packet types such as BFD, AIS, PSC, > LSP-ping, LDI, LKR, LM, DM, etc) > =20 > Thx > Shahram Shahram, This doesn't need to go in the fat-pw draft. It needs to go into the draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic when some other feature, fat-pw or other, puts a label under the PW label. The GAL goes after the PW and before the other labels. A proper multipath distribution will skip any reserved label and use the rest of the label stack to load balance. This allows spraying across the entropy space or testing a spacific payload label stack that has yielded trouble. Hardware that assumes ACH is right after GAL when the S-bit is not set on the GAL is broken. The payload (ACH) is after the BOS (aka S-bit =3D 1). The IETF has never been sympathetic of broken hardware and should not be since we would halt progress. If the hardware is broken, then the fat-pw label can be omitted but only one path through any multipath would be tested. It would still work for TP, but not work in general. PW does not require TP. The fat-pw work is explicitly done for multipath because multipath is used a lot in deployed networks and isn't going away. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com]=20 > Sent: Wednesday, August 03, 2011 4:53 PM > To: Shahram Davari > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf= .org; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > =20 > =20 > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.a= d.broadcom.com> > "Shahram Davari" writes: > > =20 > > Hi Curtis, > > =20 > > You are absolutely correct if there is no Entropy label. But with > > Entropy label most implementation assume a Entropy label to be BoS and > > below the PW label. > > =20 > > This draft doesn't even talk about whether the GAL should be BoS or > > the Entropy Label? In either case adding GAL would make the packet > > un-parsable by most HW. > > =20 > > Thx > > Shahram > =20 > =20 > That should be covered in this work. At least it was covered in WG > email. PW, then GAL, then fat-pw (aka Flow label, which is different > from Entropy label in MPLS). > =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GAL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... additional labels (ie: fat-pw) may be present | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|Version| Reserved | Associated Channel Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ VCCV Message Body ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > The above would be a better choice. The VCCV is always after the > label entry with BOS (S-bit =3D 1). > =20 > The flow label (or entropy label) must not be a reserved label. > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > 1.2 (page 5) you will find. > =20 > Note that the flow label MUST NOT be an MPLS reserved label (values > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > protocol. > =20 > =20 > The flow label below GAL is needed so that all data paths which the PW > can take are exercised by OAM (ie: LSP Ping used within VCCV). > =20 > Curtis > =20 > =20 > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com]=20 > > Sent: Wednesday, August 03, 2011 4:05 PM > > To: Shahram Davari > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Ren= nison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt > > =20 > > =20 > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp= .ad.broadcom.com> > > "Shahram Davari" writes: > > > =20 > > > Giles, > > > =20 > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > =20 > > > Thx > > > Shahram > > =20 > > =20 > > Shahram, > > =20 > > Adding GAL to an MPLS label stack requires hardware support. The > > hardware need not know if the label above the GAL is an MPLS label or > > a PW label, just that the next label is GAL and the label over it is > > not a SWAP. Unless we are talking about incredibly inflexible parser > > hardware, like none I've encounted recently, there should be no > > problem noticing a GAL below the POP or PW label and then directing > > the packet to OAM processing. Any remaining labels must be removed > > and hopefully no implementation neglects to look for BOS before > > deciding where the payload is supposed to be. > > =20 > > TTL is best reserved for traceroute only (in the MS-PW case). In this > > case TTL-expire would occur where a label swap was called for and a > > GAL would be below the label containing the expired TTL. Since LDP > > can have transient loops, this avoids having lots of packets sent to > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > =20 > > This yield one way to do OAM with or without CW. A GAL label is below > > the label for which action is taken (POP or PW termination) or below a > > label for which TTL has expired. This method applied to LSP and PW. > > =20 > > I think mandating CW would be just as good a solution, but one that > > was rejected so this is the best we have. > > =20 > > Curtis > > =20 > > =20 > > > -----Original Message----- > > > From: Giles Heron [mailto:giles.heron@gmail.com]=20 > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > To: Thomas Nadeau; Shahram Davari > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-= 02.txt > > > =20 > > > Agreed - some operators won't want to use a CW, and on that basis I s= upport > > > this draft.=20 > > > =20 > > > Sure, it'll take a while to move away from the router alert label and= TTL > > > approaches, but the GAL approach is definitely better than either of > > > those... > > > =20 > > > Giles > > > =20 > > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > =20 > > > >=20 > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > >=20 > > > >> Hi, > > > >>=20 > > > >> I also don=B9t support this draft since I don=B9t think to solve t= he problem we > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > >=20 > > > > While I am with you, that argument went out the window during the d= ebates we > > > > had over the past 3 IETF meetings. Operators > > > > were very clear that they do not want to mandate the use of a CW. = Hence, > > > > Luca and I came up with this solution that narrows the > > > > scope to 2 modes, one that handles the CW case and one that doesn't= while > > > > still both modes providing predictable OAM capabilities > > > > for the PW. > > > >=20 > > > > --Tom > > > >=20 > > > >=20 > > > >> =20 > > > >> Shahram > > > >> =20 > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Beha= lf Of > > > >> Robert Rennison > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > > > >> pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >> =20 > > > >> I do Not support the draft, > > > >> =20 > > > >> After hearing the results of the earlier user deployment poll I t= hought, > > > >> =B3 ok the way out of this mess is to migrate towards using the C= W=B2. Then I > > > >> see this proposal and wondered what am I missing. I=B9ve still no= t seen the > > > >> light of why adding a fourth type will simplify matters, hence in = the absence > > > >> of me understanding how this will simplify matter versus complicat= e things, > > > >> I=B9m against it. > > > >> =20 > > > >> Rob > > > >> =20 > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Beha= lf Of > > > >> Alexander Vainshtein > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >> =20 > > > >> Hi all, > > > >> I do NOT support this draft for the same reasons that Yaakov has i= ndicated. > > > >> =20 > > > >> Regards, > > > >> Sasha > > > >> =20 > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Y= aakov Stein > > > >> [yaakov_s@rad.com] > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >>=20 > > > >> I do not support ! and I can not understand how anyone can supp= ort it ! > > > >> =20 > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > >> =20 > > > >> I completely agree with the part that says if there is a CW then t= he ACh > > > >> should be marked by it. > > > >> =20 > > > >> I do NOT agree that if the CW is not used then we should use a non= -PW method > > > >> developed for MPLS-TP. > > > >> I do NOT agree that there is any way to deprecate the use of TTL e= xpiry to > > > >> mark the ACh. > > > >> I do NOT agree that we should change mechanisms that have been wid= ely > > > >> deployed for many years now, > > > >> without an extremely pressing reason. > > > >> =20 > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to= have the > > > >> ADDITIONAL option > > > >> for ACh marking, I might be convinced not to object as strongly. > > > >> However, since I don't think that PWs can be limited in this matte= r (the MPLS > > > >> WG adopted the "seamless" draft) > > > >> it would be difficult to convince me that such a limitation is pos= sible. > > > >> =20 > > > >> I would have enthusiastically support this proposal had it been br= ought 8 > > > >> years ago. > > > >> It's too late for this now. > > > >> =20 > > > >> Y(J)S > > > >> =20 > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Beha= lf Of > > > >> Bocci, Matthew (Matthew) > > > >> Sent: Thursday, July 28, 2011 21:02 > > > >> To: pwe3@ietf.org > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-0= 2.txt > > > >> =20 > > > >> This email begins a two week poll to help assess if there is conse= nsus to > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draf= t. > > > >> =20 > > > >> Please indicate whether or not you support adoption of this draft,= and also > > > >> send any comments to the PWE3 list. > > > >> =20 > > > >> This poll will end on Friday 12th August. > > > >> =20 > > > >> Regards, > > > >> =20 > > > >> Matthew & Andy > > > >> This e-mail message is intended for the recipient only and contain= s > > > >> information which is CONFIDENTIAL and which may be proprietary to = ECI > > > >> Telecom. If you have received this transmission in error, please i= nform 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 contain= s > > > >> information which is CONFIDENTIAL and which may be proprietary to = ECI > > > >> Telecom. If you have received this transmission in error, please i= nform us by > > > >> e-mail, phone or fax, and then delete the original and all copies = thereof. From curtis@occnc.com Thu Aug 4 10:13: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 9344021F8B53 for ; Thu, 4 Aug 2011 10:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jdy-ZShp0jg for ; Thu, 4 Aug 2011 10:13:30 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6904821F8B81 for ; Thu, 4 Aug 2011 10:13:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p74HCMCH057629; Thu, 4 Aug 2011 13:12:22 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108041712.p74HCMCH057629@harbor.orleans.occnc.com> To: "Shahram Davari" From: Curtis Villamizar In-reply-to: Your message of "Thu, 04 Aug 2011 07:42:21 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 04 Aug 2011 13:12:22 -0400 Sender: curtis@occnc.com Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 17:13:31 -0000 In message <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > I don't agree with you. This is not about broken HW. Before this draft > how was one supposed to process a packet with GAL in the middle of the > label stack? Before this draft one had to read the MPLS and PWE3 mailing list and remember what was said. Getting it written in a draft is the next step. Some of the most purist of the MPLS-TP folks have done a good job of shouting down any suggestion that multipath had a valid place in any network for quite some time. > What if this draft had decided to put GAL after entropy? Then the HW > processing would have been completely different from what you are > proposing on the fly now. Putting labels under GAL for the purpose of entropy was proposed on MPLS mailing list for well over a year now, probably close to two years, more recently on PWE3. It is reflected in other internet-drafts, For example, draft-villamizar-mpls-tp-multipath-00 was submitted before Maastricht but fell off the end of the agenda. It is also in a document that we have been giving to chip vendors under NDA stating detailed requirements starting just under a year ago. Before that is was more verbal discussion of requirements and email. Your friends in another part of your company were eliminated from consideration for other reasons a while back but have heard this requirement verbally at least. > You are making imaginary assumptions that HW should be able to process > what was in your mind. That is presumptious on your part. Actually we have given this requirement to chip vendors in our product space for about a year and a half and I have brought this up for even longer in the MPLS WG and more recently on PWE3. Two chip vendors have taken these requirements to heart and will be allowing labels under GAL plus the forwarding functionality described in draft-villamizar-mpls-tp-multipath-01. Of all the packet processors that we have considered, all on the very high end of things, I know of none that have a parser that is so inflexible that it could not deal with a label under GAL and still find the OAM payload with nothing more than a change to the low level programming of the parser. I can envision that chips do exist for which the parser is too hard coded to accommodate such a change. Lucky for us (not luck really) that we are not working with such a chip. Are you? > I strongly object to this unnecessary draft. If you look at RFCs there > are always cases that we wished we had done it differently, but we are > not going to change them since in most cases like this one it is too > late. Sorry but that is the fact. We are implementing labels under GAL for non-TP OAM in our products regardless of your objections. If a provider wants to use it, it will be there. If it can also be used for PW, all the better. Its really easy to do, so it doesn't hurt to do it. If a provider prefers to use CW all the time, I'm fine with that but we still need labels under GAL for non-TP MPLS OAM. > Thx > Shahram Curtis > ----- Original Message ----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: Thursday, August 04, 2011 06:38 AM > To: Shahram Davari > Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.com> > "Shahram Davari" writes: > > > > Hi Curtis, > > > > Even if we assume this format (which is not yet incorporated in the > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > this case how is the HW supposed to examine the ACH channel Type to > > decide how to process the packet? (unless you assume there is one > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > Thx > > Shahram > > > Shahram, > > This doesn't need to go in the fat-pw draft. It needs to go into the > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > when some other feature, fat-pw or other, puts a label under the PW > label. The GAL goes after the PW and before the other labels. A > proper multipath distribution will skip any reserved label and use the > rest of the label stack to load balance. This allows spraying across > the entropy space or testing a spacific payload label stack that has > yielded trouble. > > Hardware that assumes ACH is right after GAL when the S-bit is not set > on the GAL is broken. > > The payload (ACH) is after the BOS (aka S-bit = 1). > > The IETF has never been sympathetic of broken hardware and should not > be since we would halt progress. > > If the hardware is broken, then the fat-pw label can be omitted but > only one path through any multipath would be tested. It would still > work for TP, but not work in general. PW does not require TP. The > fat-pw work is explicitly done for multipath because multipath is used > a lot in deployed networks and isn't going away. > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, August 03, 2011 4:53 PM > > To: Shahram Davari > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > You are absolutely correct if there is no Entropy label. But with > > > Entropy label most implementation assume a Entropy label to be BoS and > > > below the PW label. > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > the Entropy Label? In either case adding GAL would make the packet > > > un-parsable by most HW. > > > > > > Thx > > > Shahram > > > > > > That should be covered in this work. At least it was covered in WG > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > from Entropy label in MPLS). > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PW Label | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GAL | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ... additional labels (ie: fat-pw) may be present | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ VCCV Message Body ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > The above would be a better choice. The VCCV is always after the > > label entry with BOS (S-bit = 1). > > > > The flow label (or entropy label) must not be a reserved label. > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > > 1.2 (page 5) you will find. > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > protocol. > > > > > > The flow label below GAL is needed so that all data paths which the PW > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > To: Shahram Davari > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com> > > > "Shahram Davari" writes: > > > > > > > > Giles, > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > Thx > > > > Shahram > > > > > > > > > Shahram, > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > hardware need not know if the label above the GAL is an MPLS label or > > > a PW label, just that the next label is GAL and the label over it is > > > not a SWAP. Unless we are talking about incredibly inflexible parser > > > hardware, like none I've encounted recently, there should be no > > > problem noticing a GAL below the POP or PW label and then directing > > > the packet to OAM processing. Any remaining labels must be removed > > > and hopefully no implementation neglects to look for BOS before > > > deciding where the payload is supposed to be. > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In this > > > case TTL-expire would occur where a label swap was called for and a > > > GAL would be below the label containing the expired TTL. Since LDP > > > can have transient loops, this avoids having lots of packets sent to > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > This yield one way to do OAM with or without CW. A GAL label is below > > > the label for which action is taken (POP or PW termination) or below a > > > label for which TTL has expired. This method applied to LSP and PW. > > > > > > I think mandating CW would be just as good a solution, but one that > > > was rejected so this is the best we have. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > To: Thomas Nadeau; Shahram Davari > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis I support > > > > this draft. > > > > > > > > Sure, it'll take a while to move away from the router alert label and TTL > > > > approaches, but the GAL approach is definitely better than either of > > > > those... > > > > > > > > Giles > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I also donąt support this draft since I donąt think to solve the problem we > > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > > > While I am with you, that argument went out the window during the debates we > > > > > had over the past 3 IETF meetings. Operators > > > > > were very clear that they do not want to mandate the use of a CW. Hence, > > > > > Luca and I came up with this solution that narrows the > > > > > scope to 2 modes, one that handles the CW case and one that doesn't while > > > > > still both modes providing predictable OAM capabilities > > > > > for the PW. > > > > > > > > > > --Tom > > > > > > > > > > > > > > >> > > > > >> Shahram > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > >> Robert Rennison > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > > > > >> pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> I do Not support the draft, > > > > >> > > > > >> After hearing the results of the earlier user deployment poll I thought, > > > > >> ł ok the way out of this mess is to migrate towards using the CW˛. Then I > > > > >> see this proposal and wondered what am I missing. Iąve still not seen the > > > > >> light of why adding a fourth type will simplify matters, hence in the absence > > > > >> of me understanding how this will simplify matter versus complicate things, > > > > >> Iąm against it. > > > > >> > > > > >> Rob > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > >> Alexander Vainshtein > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> Hi all, > > > > >> I do NOT support this draft for the same reasons that Yaakov has indicated. > > > > >> > > > > >> Regards, > > > > >> Sasha > > > > >> > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein > > > > >> [yaakov_s@rad.com] > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> I do not support ! and I can not understand how anyone can support it ! > > > > >> > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > >> > > > > >> I completely agree with the part that says if there is a CW then the ACh > > > > >> should be marked by it. > > > > >> > > > > >> I do NOT agree that if the CW is not used then we should use a non-PW method > > > > >> developed for MPLS-TP. > > > > >> I do NOT agree that there is any way to deprecate the use of TTL expiry to > > > > >> mark the ACh. > > > > >> I do NOT agree that we should change mechanisms that have been widely > > > > >> deployed for many years now, > > > > >> without an extremely pressing reason. > > > > >> > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the > > > > >> ADDITIONAL option > > > > >> for ACh marking, I might be convinced not to object as strongly. > > > > >> However, since I don't think that PWs can be limited in this matter (the MPLS > > > > >> WG adopted the "seamless" draft) > > > > >> it would be difficult to convince me that such a limitation is possible. > > > > >> > > > > >> I would have enthusiastically support this proposal had it been brought 8 > > > > >> years ago. > > > > >> It's too late for this now. > > > > >> > > > > >> Y(J)S > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > >> Bocci, Matthew (Matthew) > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > >> To: pwe3@ietf.org > > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> This email begins a two week poll to help assess if there is consensus to > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > > > > >> > > > > >> Please indicate whether or not you support adoption of this draft, and also > > > > >> send any comments to the PWE3 list. > > > > >> > > > > >> This poll will end on Friday 12th August. > > > > >> > > > > >> Regards, > > > > >> > > > > >> Matthew & Andy > > > > >> 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. From davari@broadcom.com Thu Aug 4 10:28: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 B293021F8B5C for ; Thu, 4 Aug 2011 10:28:21 -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.000, 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 FgIHDmHs0S+9 for ; Thu, 4 Aug 2011 10:28:20 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4084D21F8B53 for ; Thu, 4 Aug 2011 10:28:20 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 04 Aug 2011 10:27:28 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 4 Aug 2011 10:21:48 -0700 From: "Shahram Davari" To: "curtis@occnc.com" Date: Thu, 4 Aug 2011 10:21:47 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSyeZSnKs+JkOwS+qKBhV112bL/QAAKzdQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F5DD@SJEXCHCCR02.corp.ad.broadcom.com> References: Your message of "Thu, 04 Aug 2011 07:42:21 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> <201108041712.p74HCMCH057629@harbor.orleans.occnc.com> In-Reply-To: <201108041712.p74HCMCH057629@harbor.orleans.occnc.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: 6224090A3DK7734094-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 17:28:21 -0000 Curtis, I am sorry but your RFI and emails are not equal to IETF RFCs and there is = no reason for vendors to follow the words of an IETF participant. Thanks Shahram -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 10:12 AM To: Shahram Davari Cc: 'curtis@occnc.com'; 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com';= 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.= broadcom.com> "Shahram Davari" writes: > > I don't agree with you. This is not about broken HW. Before this draft > how was one supposed to process a packet with GAL in the middle of the > label stack? Before this draft one had to read the MPLS and PWE3 mailing list and remember what was said. Getting it written in a draft is the next step. Some of the most purist of the MPLS-TP folks have done a good job of shouting down any suggestion that multipath had a valid place in any network for quite some time. > What if this draft had decided to put GAL after entropy? Then the HW > processing would have been completely different from what you are > proposing on the fly now. Putting labels under GAL for the purpose of entropy was proposed on MPLS mailing list for well over a year now, probably close to two years, more recently on PWE3. It is reflected in other internet-drafts, For example, draft-villamizar-mpls-tp-multipath-00 was submitted before Maastricht but fell off the end of the agenda. It is also in a document that we have been giving to chip vendors under NDA stating detailed requirements starting just under a year ago. Before that is was more verbal discussion of requirements and email. Your friends in another part of your company were eliminated from consideration for other reasons a while back but have heard this requirement verbally at least. > You are making imaginary assumptions that HW should be able to process > what was in your mind. That is presumptious on your part. Actually we have given this requirement to chip vendors in our product space for about a year and a half and I have brought this up for even longer in the MPLS WG and more recently on PWE3. Two chip vendors have taken these requirements to heart and will be allowing labels under GAL plus the forwarding functionality described in draft-villamizar-mpls-tp-multipath-01. Of all the packet processors that we have considered, all on the very high end of things, I know of none that have a parser that is so inflexible that it could not deal with a label under GAL and still find the OAM payload with nothing more than a change to the low level programming of the parser. I can envision that chips do exist for which the parser is too hard coded to accommodate such a change. Lucky for us (not luck really) that we are not working with such a chip. Are you? > I strongly object to this unnecessary draft. If you look at RFCs there > are always cases that we wished we had done it differently, but we are > not going to change them since in most cases like this one it is too > late. Sorry but that is the fact. We are implementing labels under GAL for non-TP OAM in our products regardless of your objections. If a provider wants to use it, it will be there. If it can also be used for PW, all the better. Its really easy to do, so it doesn't hurt to do it. If a provider prefers to use CW all the time, I'm fine with that but we still need labels under GAL for non-TP MPLS OAM. > Thx > Shahram Curtis > ----- Original Message ----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: Thursday, August 04, 2011 06:38 AM > To: Shahram Davari > Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.a= d.broadcom.com> > "Shahram Davari" writes: > > > > Hi Curtis, > > > > Even if we assume this format (which is not yet incorporated in the > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > this case how is the HW supposed to examine the ACH channel Type to > > decide how to process the packet? (unless you assume there is one > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > Thx > > Shahram > > > Shahram, > > This doesn't need to go in the fat-pw draft. It needs to go into the > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > when some other feature, fat-pw or other, puts a label under the PW > label. The GAL goes after the PW and before the other labels. A > proper multipath distribution will skip any reserved label and use the > rest of the label stack to load balance. This allows spraying across > the entropy space or testing a spacific payload label stack that has > yielded trouble. > > Hardware that assumes ACH is right after GAL when the S-bit is not set > on the GAL is broken. > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > The IETF has never been sympathetic of broken hardware and should not > be since we would halt progress. > > If the hardware is broken, then the fat-pw label can be omitted but > only one path through any multipath would be tested. It would still > work for TP, but not work in general. PW does not require TP. The > fat-pw work is explicitly done for multipath because multipath is used > a lot in deployed networks and isn't going away. > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, August 03, 2011 4:53 PM > > To: Shahram Davari > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ie= tf.org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp= .ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > You are absolutely correct if there is no Entropy label. But with > > > Entropy label most implementation assume a Entropy label to be BoS an= d > > > below the PW label. > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > the Entropy Label? In either case adding GAL would make the packet > > > un-parsable by most HW. > > > > > > Thx > > > Shahram > > > > > > That should be covered in this work. At least it was covered in WG > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > from Entropy label in MPLS). > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PW Label | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GAL | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ... additional labels (ie: fat-pw) may be present | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ VCCV Message Body ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > The above would be a better choice. The VCCV is always after the > > label entry with BOS (S-bit =3D 1). > > > > The flow label (or entropy label) must not be a reserved label. > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > > 1.2 (page 5) you will find. > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > protocol. > > > > > > The flow label below GAL is needed so that all data paths which the PW > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > To: Shahram Davari > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert R= ennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-= 02.txt > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.co= rp.ad.broadcom.com> > > > "Shahram Davari" writes: > > > > > > > > Giles, > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > Thx > > > > Shahram > > > > > > > > > Shahram, > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > hardware need not know if the label above the GAL is an MPLS label or > > > a PW label, just that the next label is GAL and the label over it is > > > not a SWAP. Unless we are talking about incredibly inflexible parser > > > hardware, like none I've encounted recently, there should be no > > > problem noticing a GAL below the POP or PW label and then directing > > > the packet to OAM processing. Any remaining labels must be removed > > > and hopefully no implementation neglects to look for BOS before > > > deciding where the payload is supposed to be. > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In thi= s > > > case TTL-expire would occur where a label swap was called for and a > > > GAL would be below the label containing the expired TTL. Since LDP > > > can have transient loops, this avoids having lots of packets sent to > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > This yield one way to do OAM with or without CW. A GAL label is belo= w > > > the label for which action is taken (POP or PW termination) or below = a > > > label for which TTL has expired. This method applied to LSP and PW. > > > > > > I think mandating CW would be just as good a solution, but one that > > > was rejected so this is the best we have. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > To: Thomas Nadeau; Shahram Davari > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-= 2-02.txt > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis I= support > > > > this draft. > > > > > > > > Sure, it'll take a while to move away from the router alert label a= nd TTL > > > > approaches, but the GAL approach is definitely better than either o= f > > > > those... > > > > > > > > Giles > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrot= e: > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I also don=B9t support this draft since I don=B9t think to solve= the problem we > > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > > > While I am with you, that argument went out the window during the= debates we > > > > > had over the past 3 IETF meetings. Operators > > > > > were very clear that they do not want to mandate the use of a CW.= Hence, > > > > > Luca and I came up with this solution that narrows the > > > > > scope to 2 modes, one that handles the CW case and one that doesn= 't while > > > > > still both modes providing predictable OAM capabilities > > > > > for the PW. > > > > > > > > > > --Tom > > > > > > > > > > > > > > >> > > > > >> Shahram > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Be= half Of > > > > >> Robert Rennison > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew)= ; > > > > >> pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vc= cv-2-02.txt > > > > >> > > > > >> I do Not support the draft, > > > > >> > > > > >> After hearing the results of the earlier user deployment poll I= thought, > > > > >> =B3 ok the way out of this mess is to migrate towards using the= CW=B2. Then I > > > > >> see this proposal and wondered what am I missing. I=B9ve still = not seen the > > > > >> light of why adding a fourth type will simplify matters, hence i= n the absence > > > > >> of me understanding how this will simplify matter versus complic= ate things, > > > > >> I=B9m against it. > > > > >> > > > > >> Rob > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Be= half Of > > > > >> Alexander Vainshtein > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vc= cv-2-02.txt > > > > >> > > > > >> Hi all, > > > > >> I do NOT support this draft for the same reasons that Yaakov has= indicated. > > > > >> > > > > >> Regards, > > > > >> Sasha > > > > >> > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of= Yaakov Stein > > > > >> [yaakov_s@rad.com] > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vc= cv-2-02.txt > > > > >> > > > > >> I do not support ! and I can not understand how anyone can su= pport it ! > > > > >> > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > >> > > > > >> I completely agree with the part that says if there is a CW then= the ACh > > > > >> should be marked by it. > > > > >> > > > > >> I do NOT agree that if the CW is not used then we should use a n= on-PW method > > > > >> developed for MPLS-TP. > > > > >> I do NOT agree that there is any way to deprecate the use of TTL= expiry to > > > > >> mark the ACh. > > > > >> I do NOT agree that we should change mechanisms that have been w= idely > > > > >> deployed for many years now, > > > > >> without an extremely pressing reason. > > > > >> > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP = to have the > > > > >> ADDITIONAL option > > > > >> for ACh marking, I might be convinced not to object as strongly. > > > > >> However, since I don't think that PWs can be limited in this mat= ter (the MPLS > > > > >> WG adopted the "seamless" draft) > > > > >> it would be difficult to convince me that such a limitation is p= ossible. > > > > >> > > > > >> I would have enthusiastically support this proposal had it been = brought 8 > > > > >> years ago. > > > > >> It's too late for this now. > > > > >> > > > > >> Y(J)S > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Be= half Of > > > > >> Bocci, Matthew (Matthew) > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > >> To: pwe3@ietf.org > > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2= -02.txt > > > > >> > > > > >> This email begins a two week poll to help assess if there is con= sensus to > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group dr= aft. > > > > >> > > > > >> Please indicate whether or not you support adoption of this draf= t, and also > > > > >> send any comments to the PWE3 list. > > > > >> > > > > >> This poll will end on Friday 12th August. > > > > >> > > > > >> Regards, > > > > >> > > > > >> Matthew & Andy > > > > >> This e-mail message is intended for the recipient only and conta= ins > > > > >> information which is CONFIDENTIAL and which may be proprietary t= o 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 copie= s thereof. > > > > >> This e-mail message is intended for the recipient only and conta= ins > > > > >> information which is CONFIDENTIAL and which may be proprietary t= o 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 copie= s thereof. From davari@broadcom.com Thu Aug 4 10:29: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 D507F21F8BA2 for ; Thu, 4 Aug 2011 10:29:50 -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.000, 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 R5p3jG+Pl0I1 for ; Thu, 4 Aug 2011 10:29:49 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 72DF921F8B5C for ; Thu, 4 Aug 2011 10:29:49 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 04 Aug 2011 10:35:16 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 4 Aug 2011 10:29:57 -0700 From: "Shahram Davari" To: "Shahram Davari" , "curtis@occnc.com" Date: Thu, 4 Aug 2011 10:29:57 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSyeZSnKs+JkOwS+qKBhV112bL/QAAKzdQAABY5qA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F5FA@SJEXCHCCR02.corp.ad.broadcom.com> References: Your message of "Thu, 04 Aug 2011 07:42:21 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> <201108041712.p74HCMCH057629@harbor.orleans.occnc.com> 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: 622407DE3W41548500-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 17:29:50 -0000 Also I forgot to mention that we have super-flexible fully programmable par= sers, but IETF works should not assume that everyone has such capability. S= pecially for an unnecessary draft such as this one. Thx Shharam -----Original Message----- From: Shahram Davari Sent: Thursday, August 04, 2011 10:22 AM To: 'curtis@occnc.com' Cc: 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com'; 'yaakov_s@rad.com';= 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Curtis, I am sorry but your RFI and emails are not equal to IETF RFCs and there is = no reason for vendors to follow the words of an IETF participant. Thanks Shahram -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 10:12 AM To: Shahram Davari Cc: 'curtis@occnc.com'; 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com';= 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.= broadcom.com> "Shahram Davari" writes: > > I don't agree with you. This is not about broken HW. Before this draft > how was one supposed to process a packet with GAL in the middle of the > label stack? Before this draft one had to read the MPLS and PWE3 mailing list and remember what was said. Getting it written in a draft is the next step. Some of the most purist of the MPLS-TP folks have done a good job of shouting down any suggestion that multipath had a valid place in any network for quite some time. > What if this draft had decided to put GAL after entropy? Then the HW > processing would have been completely different from what you are > proposing on the fly now. Putting labels under GAL for the purpose of entropy was proposed on MPLS mailing list for well over a year now, probably close to two years, more recently on PWE3. It is reflected in other internet-drafts, For example, draft-villamizar-mpls-tp-multipath-00 was submitted before Maastricht but fell off the end of the agenda. It is also in a document that we have been giving to chip vendors under NDA stating detailed requirements starting just under a year ago. Before that is was more verbal discussion of requirements and email. Your friends in another part of your company were eliminated from consideration for other reasons a while back but have heard this requirement verbally at least. > You are making imaginary assumptions that HW should be able to process > what was in your mind. That is presumptious on your part. Actually we have given this requirement to chip vendors in our product space for about a year and a half and I have brought this up for even longer in the MPLS WG and more recently on PWE3. Two chip vendors have taken these requirements to heart and will be allowing labels under GAL plus the forwarding functionality described in draft-villamizar-mpls-tp-multipath-01. Of all the packet processors that we have considered, all on the very high end of things, I know of none that have a parser that is so inflexible that it could not deal with a label under GAL and still find the OAM payload with nothing more than a change to the low level programming of the parser. I can envision that chips do exist for which the parser is too hard coded to accommodate such a change. Lucky for us (not luck really) that we are not working with such a chip. Are you? > I strongly object to this unnecessary draft. If you look at RFCs there > are always cases that we wished we had done it differently, but we are > not going to change them since in most cases like this one it is too > late. Sorry but that is the fact. We are implementing labels under GAL for non-TP OAM in our products regardless of your objections. If a provider wants to use it, it will be there. If it can also be used for PW, all the better. Its really easy to do, so it doesn't hurt to do it. If a provider prefers to use CW all the time, I'm fine with that but we still need labels under GAL for non-TP MPLS OAM. > Thx > Shahram Curtis > ----- Original Message ----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: Thursday, August 04, 2011 06:38 AM > To: Shahram Davari > Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.a= d.broadcom.com> > "Shahram Davari" writes: > > > > Hi Curtis, > > > > Even if we assume this format (which is not yet incorporated in the > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > this case how is the HW supposed to examine the ACH channel Type to > > decide how to process the packet? (unless you assume there is one > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > Thx > > Shahram > > > Shahram, > > This doesn't need to go in the fat-pw draft. It needs to go into the > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > when some other feature, fat-pw or other, puts a label under the PW > label. The GAL goes after the PW and before the other labels. A > proper multipath distribution will skip any reserved label and use the > rest of the label stack to load balance. This allows spraying across > the entropy space or testing a spacific payload label stack that has > yielded trouble. > > Hardware that assumes ACH is right after GAL when the S-bit is not set > on the GAL is broken. > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > The IETF has never been sympathetic of broken hardware and should not > be since we would halt progress. > > If the hardware is broken, then the fat-pw label can be omitted but > only one path through any multipath would be tested. It would still > work for TP, but not work in general. PW does not require TP. The > fat-pw work is explicitly done for multipath because multipath is used > a lot in deployed networks and isn't going away. > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, August 03, 2011 4:53 PM > > To: Shahram Davari > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ie= tf.org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp= .ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > You are absolutely correct if there is no Entropy label. But with > > > Entropy label most implementation assume a Entropy label to be BoS an= d > > > below the PW label. > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > the Entropy Label? In either case adding GAL would make the packet > > > un-parsable by most HW. > > > > > > Thx > > > Shahram > > > > > > That should be covered in this work. At least it was covered in WG > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > from Entropy label in MPLS). > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PW Label | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GAL | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ... additional labels (ie: fat-pw) may be present | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ VCCV Message Body ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > The above would be a better choice. The VCCV is always after the > > label entry with BOS (S-bit =3D 1). > > > > The flow label (or entropy label) must not be a reserved label. > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > > 1.2 (page 5) you will find. > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > protocol. > > > > > > The flow label below GAL is needed so that all data paths which the PW > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > To: Shahram Davari > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert R= ennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-= 02.txt > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.co= rp.ad.broadcom.com> > > > "Shahram Davari" writes: > > > > > > > > Giles, > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > Thx > > > > Shahram > > > > > > > > > Shahram, > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > hardware need not know if the label above the GAL is an MPLS label or > > > a PW label, just that the next label is GAL and the label over it is > > > not a SWAP. Unless we are talking about incredibly inflexible parser > > > hardware, like none I've encounted recently, there should be no > > > problem noticing a GAL below the POP or PW label and then directing > > > the packet to OAM processing. Any remaining labels must be removed > > > and hopefully no implementation neglects to look for BOS before > > > deciding where the payload is supposed to be. > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In thi= s > > > case TTL-expire would occur where a label swap was called for and a > > > GAL would be below the label containing the expired TTL. Since LDP > > > can have transient loops, this avoids having lots of packets sent to > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > This yield one way to do OAM with or without CW. A GAL label is belo= w > > > the label for which action is taken (POP or PW termination) or below = a > > > label for which TTL has expired. This method applied to LSP and PW. > > > > > > I think mandating CW would be just as good a solution, but one that > > > was rejected so this is the best we have. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > To: Thomas Nadeau; Shahram Davari > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-= 2-02.txt > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis I= support > > > > this draft. > > > > > > > > Sure, it'll take a while to move away from the router alert label a= nd TTL > > > > approaches, but the GAL approach is definitely better than either o= f > > > > those... > > > > > > > > Giles > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrot= e: > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I also don=B9t support this draft since I don=B9t think to solve= the problem we > > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > > > While I am with you, that argument went out the window during the= debates we > > > > > had over the past 3 IETF meetings. Operators > > > > > were very clear that they do not want to mandate the use of a CW.= Hence, > > > > > Luca and I came up with this solution that narrows the > > > > > scope to 2 modes, one that handles the CW case and one that doesn= 't while > > > > > still both modes providing predictable OAM capabilities > > > > > for the PW. > > > > > > > > > > --Tom > > > > > > > > > > > > > > >> > > > > >> Shahram > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Be= half Of > > > > >> Robert Rennison > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew)= ; > > > > >> pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vc= cv-2-02.txt > > > > >> > > > > >> I do Not support the draft, > > > > >> > > > > >> After hearing the results of the earlier user deployment poll I= thought, > > > > >> =B3 ok the way out of this mess is to migrate towards using the= CW=B2. Then I > > > > >> see this proposal and wondered what am I missing. I=B9ve still = not seen the > > > > >> light of why adding a fourth type will simplify matters, hence i= n the absence > > > > >> of me understanding how this will simplify matter versus complic= ate things, > > > > >> I=B9m against it. > > > > >> > > > > >> Rob > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Be= half Of > > > > >> Alexander Vainshtein > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vc= cv-2-02.txt > > > > >> > > > > >> Hi all, > > > > >> I do NOT support this draft for the same reasons that Yaakov has= indicated. > > > > >> > > > > >> Regards, > > > > >> Sasha > > > > >> > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of= Yaakov Stein > > > > >> [yaakov_s@rad.com] > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vc= cv-2-02.txt > > > > >> > > > > >> I do not support ! and I can not understand how anyone can su= pport it ! > > > > >> > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > >> > > > > >> I completely agree with the part that says if there is a CW then= the ACh > > > > >> should be marked by it. > > > > >> > > > > >> I do NOT agree that if the CW is not used then we should use a n= on-PW method > > > > >> developed for MPLS-TP. > > > > >> I do NOT agree that there is any way to deprecate the use of TTL= expiry to > > > > >> mark the ACh. > > > > >> I do NOT agree that we should change mechanisms that have been w= idely > > > > >> deployed for many years now, > > > > >> without an extremely pressing reason. > > > > >> > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP = to have the > > > > >> ADDITIONAL option > > > > >> for ACh marking, I might be convinced not to object as strongly. > > > > >> However, since I don't think that PWs can be limited in this mat= ter (the MPLS > > > > >> WG adopted the "seamless" draft) > > > > >> it would be difficult to convince me that such a limitation is p= ossible. > > > > >> > > > > >> I would have enthusiastically support this proposal had it been = brought 8 > > > > >> years ago. > > > > >> It's too late for this now. > > > > >> > > > > >> Y(J)S > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Be= half Of > > > > >> Bocci, Matthew (Matthew) > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > >> To: pwe3@ietf.org > > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2= -02.txt > > > > >> > > > > >> This email begins a two week poll to help assess if there is con= sensus to > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group dr= aft. > > > > >> > > > > >> Please indicate whether or not you support adoption of this draf= t, and also > > > > >> send any comments to the PWE3 list. > > > > >> > > > > >> This poll will end on Friday 12th August. > > > > >> > > > > >> Regards, > > > > >> > > > > >> Matthew & Andy > > > > >> This e-mail message is intended for the recipient only and conta= ins > > > > >> information which is CONFIDENTIAL and which may be proprietary t= o 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 copie= s thereof. > > > > >> This e-mail message is intended for the recipient only and conta= ins > > > > >> information which is CONFIDENTIAL and which may be proprietary t= o 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 copie= s thereof. From loa@pi.nu Thu Aug 4 10:45: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 A666921F8AE1; Thu, 4 Aug 2011 10:45:27 -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 Jj2fFaVsIE7k; Thu, 4 Aug 2011 10:45:27 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id A5CC921F8AD6; Thu, 4 Aug 2011 10:45:26 -0700 (PDT) Received: from [10.154.181.21] (unknown [129.192.185.163]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id C3D79514044; Thu, 4 Aug 2011 19:45:37 +0200 (CEST) Message-ID: <4E3ADAE2.5060907@pi.nu> Date: Thu, 04 Aug 2011 10:46:10 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org References: <4E386CF0.5050700@pi.nu> In-Reply-To: <4E386CF0.5050700@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, pwe3@ietf.org, draft-ietf-pwe3-fat.all@tools.ietf.org Subject: Re: [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 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, 04 Aug 2011 17:45:27 -0000 All, I have one more point on this - I should have captured it in the previous mail but had to think and discuss a bit about it! Doing ECMP hashing over the label stack as described is OK, but has one thing that needs to be taken care of. Introducing a reserved label - most prominently the GAL - into the label stack will change the outcome of the hash. Since we are ECMP-ing on the hash result, we will no longer to be able to guarantee that normal traffic and OAM packets will no longer be fate sharing - draft-ietf-pwe3-fat-pw should say explicitly that reserved labels should be excluded from ECMP hashing. /Loa On 2011-08-02 14:32, Loa Andersson wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for > draft-ietf-pwe3-fat-pw-07. > > The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review > is to provide assistance to the Routing ADs. For more information > about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-pwe3-fat-pw-07 > Reviewer: Loa Andersson > Review Date: 2 Aug 2011 > IETF LC End Date: 3 Aug 2011 > Intended Status: Standards Track > > Summary: > I have no major concerns about this document, howver I thing it > would be good to reslove the mostly editorial comments below > (especially on the IANA section) before publication. > > Comments: > > Unexpanded acronyms: > > OAM appears in the table of content and as header 7. It is not > expanded in the document anywhere. Should be done at first occurance. > > page 6. The last paragraph of section 1 talks about TC bits > (and EXP bits). We don't have TC bits - the correct name is TC field. > > First paragraph section three: > This paragraph talks in genral about "load balanced paths" while the > rest of the document is very specific about ECMP, it is the intention > that this should work for any load balancing paradigm? > > Second paragraph section three: > Normally a label is assigned by the down stream node, this scheme > is doing upstream allocation. Don't see a problem under normal > operation, but if the label "by accident" becomes top of stack > this could have "interesting" effects. > > Sectyion 4 second paagraph: > > OLD > > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. A PE that is using PW signalling and that does > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > A PE that is using PW signalling and which does not receive a FL Sub- > TLV from its peer MUST NOT include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > > NEW > > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. An ingress PE that is using PW signalling > and that does not send a FL Sub-TLV MUST NOT include a flow label > in the PW packet. An ingress PE that is using PW signalling and > which does not receive a FL Sub-TLV from its egress peer MUST NOT > include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > > The IANA section: > > In the IANA section we should use a TBD entry for the Flow label > indicator; and maybe add 0x17 as suggest value in the text. > > The text in the IANA section needs to aligned with the rest of > the text, or maybe even better have the rest of the text align > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > else but in the iana section. > > To make it easier to find the references to the IANA registries > should start with "Pseudowire Name Spaces (PWE3)" point to > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > sub-registry, and ask for assigment of the next free value from > the Experts review space (suggested value 0x17). > > On the other hand it looks like we have an early assigment > (Flow Label shows up with the value 0x17). If this is the case > after making the text changes suggest above this should be mentioned > in the IANA section. -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From davari@broadcom.com Thu Aug 4 10:46: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 EE15921F8AD6; Thu, 4 Aug 2011 10:46:45 -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.000, 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 omjqwJF95bdt; Thu, 4 Aug 2011 10:46:45 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2F67A21F8AB0; Thu, 4 Aug 2011 10:46:45 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 04 Aug 2011 10:52:33 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 4 Aug 2011 10:46:53 -0700 From: "Shahram Davari" To: "Loa Andersson" , "rtg-ads@tools.ietf.org" Date: Thu, 4 Aug 2011 10:46:53 -0700 Thread-Topic: [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 Thread-Index: AcxSzl8e1QBBTsjJST20o/t591BZbwAABiMg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F61D@SJEXCHCCR02.corp.ad.broadcom.com> References: <4E386CF0.5050700@pi.nu> <4E3ADAE2.5060907@pi.nu> In-Reply-To: <4E3ADAE2.5060907@pi.nu> 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: 622403EB3DK7742447-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "rtg-dir@ietf.org" , "pwe3@ietf.org" , "draft-ietf-pwe3-fat.all@tools.ietf.org" Subject: Re: [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 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, 04 Aug 2011 17:46:46 -0000 I agree with Loa. Thx Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, August 04, 2011 10:46 AM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; pwe3@ietf.org; draft-ietf-pwe3-fat.all@tools.ietf.org Subject: Re: [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 All, I have one more point on this - I should have captured it in the previous mail but had to think and discuss a bit about it! Doing ECMP hashing over the label stack as described is OK, but has one thing that needs to be taken care of. Introducing a reserved label - most prominently the GAL - into the label stack will change the outcome of the hash. Since we are ECMP-ing on the hash result, we will no longer to be able to guarantee that normal traffic and OAM packets will no longer be fate sharing - draft-ietf-pwe3-fat-pw should say explicitly that reserved labels should be excluded from ECMP hashing. /Loa On 2011-08-02 14:32, Loa Andersson wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for > draft-ietf-pwe3-fat-pw-07. > > The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review > is to provide assistance to the Routing ADs. For more information > about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-pwe3-fat-pw-07 > Reviewer: Loa Andersson > Review Date: 2 Aug 2011 > IETF LC End Date: 3 Aug 2011 > Intended Status: Standards Track > > Summary: > I have no major concerns about this document, howver I thing it > would be good to reslove the mostly editorial comments below > (especially on the IANA section) before publication. > > Comments: > > Unexpanded acronyms: > > OAM appears in the table of content and as header 7. It is not > expanded in the document anywhere. Should be done at first occurance. > > page 6. The last paragraph of section 1 talks about TC bits > (and EXP bits). We don't have TC bits - the correct name is TC field. > > First paragraph section three: > This paragraph talks in genral about "load balanced paths" while the > rest of the document is very specific about ECMP, it is the intention > that this should work for any load balancing paradigm? > > Second paragraph section three: > Normally a label is assigned by the down stream node, this scheme > is doing upstream allocation. Don't see a problem under normal > operation, but if the label "by accident" becomes top of stack > this could have "interesting" effects. > > Sectyion 4 second paagraph: > > OLD > > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. A PE that is using PW signalling and that does > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > A PE that is using PW signalling and which does not receive a FL Sub- > TLV from its peer MUST NOT include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > > NEW > > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. An ingress PE that is using PW signalling > and that does not send a FL Sub-TLV MUST NOT include a flow label > in the PW packet. An ingress PE that is using PW signalling and > which does not receive a FL Sub-TLV from its egress peer MUST NOT > include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > > The IANA section: > > In the IANA section we should use a TBD entry for the Flow label > indicator; and maybe add 0x17 as suggest value in the text. > > The text in the IANA section needs to aligned with the rest of > the text, or maybe even better have the rest of the text align > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > else but in the iana section. > > To make it easier to find the references to the IANA registries > should start with "Pseudowire Name Spaces (PWE3)" point to > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > sub-registry, and ask for assigment of the next free value from > the Experts review space (suggested value 0x17). > > On the other hand it looks like we have an early assigment > (Flow Label shows up with the value 0x17). If this is the case > after making the text changes suggest above this should be mentioned > in the IANA section. --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From jdrake@juniper.net Thu Aug 4 10:57:09 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 5719021F8853 for ; Thu, 4 Aug 2011 10:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=0.562, 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 GX9zbofz1dyO for ; Thu, 4 Aug 2011 10:57:07 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 67A9C5E8002 for ; Thu, 4 Aug 2011 10:57:05 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTjrdfGBQk7QCN0Tc5mR/imPs7KB6etlX@postini.com; Thu, 04 Aug 2011 10:57:22 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 4 Aug 2011 10:56:05 -0700 From: John E Drake To: "curtis@occnc.com" , Shahram Davari Date: Thu, 4 Aug 2011 10:56:03 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSyeL4keOJqv44SQW5wgy/thjRDQABWHpA Message-ID: <5E893DB832F57341992548CDBB333163A0AC0CCCE1@EMBX01-HQ.jnpr.net> References: Your message of "Thu, 04 Aug 2011 07:42:21 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> <201108041712.p74HCMCH057629@harbor.orleans.occnc.com> In-Reply-To: <201108041712.p74HCMCH057629@harbor.orleans.occnc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 17:57:09 -0000 >From Section 6 of the Entropy Label I-D (http://datatracker.ietf.org/doc/dr= aft-ietf-mpls-entropy-label/?include_text=3D1): "As part of the MPLS-TP work, an in-band OAM channel is defined in [RFC5586= ]. Packets sent in this channel are identified with a reserved label, the = Generic Associated Channel Label (GAL) placed at the bottom of the MPLS lab= el stack. In order to use the inband OAM channel with entropy labels, this= memo relaxes the restriction that the GAL must be at the bottom of the MPL= S label stack. Rather, the GAL is placed in the MPLS label stack above the= entropy label so that it effectively functions as an application label." Sent from my iPhone > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Curtis Villamizar > Sent: Thursday, August 04, 2011 10:12 AM > To: Shahram Davari > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > > In message > <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadco > m.com> > "Shahram Davari" writes: > > > > I don't agree with you. This is not about broken HW. Before this > draft > > how was one supposed to process a packet with GAL in the middle of > the > > label stack? > > Before this draft one had to read the MPLS and PWE3 mailing list and > remember what was said. Getting it written in a draft is the next > step. > > Some of the most purist of the MPLS-TP folks have done a good job of > shouting down any suggestion that multipath had a valid place in any > network for quite some time. > > > What if this draft had decided to put GAL after entropy? Then the HW > > processing would have been completely different from what you are > > proposing on the fly now. > > Putting labels under GAL for the purpose of entropy was proposed on > MPLS mailing list for well over a year now, probably close to two > years, more recently on PWE3. It is reflected in other internet- > drafts, For example, draft-villamizar-mpls-tp-multipath-00 > was submitted before Maastricht but fell off the end of the agenda. > > It is also in a document that we have been giving to chip vendors under > NDA stating detailed requirements starting just under a year ago. > Before that is was more verbal discussion of requirements and email. > Your friends in another part of your company were eliminated from > consideration for other reasons a while back but have heard this > requirement verbally at least. > > > You are making imaginary assumptions that HW should be able to > process > > what was in your mind. > > That is presumptious on your part. Actually we have given this > requirement to chip vendors in our product space for about a year and a > half and I have brought this up for even longer in the MPLS WG and more > recently on PWE3. Two chip vendors have taken these requirements to > heart and will be allowing labels under GAL plus the forwarding > functionality described in draft-villamizar-mpls-tp-multipath-01. > > Of all the packet processors that we have considered, all on the very > high end of things, I know of none that have a parser that is so > inflexible that it could not deal with a label under GAL and still find > the OAM payload with nothing more than a change to the low level > programming of the parser. > > I can envision that chips do exist for which the parser is too hard > coded to accommodate such a change. Lucky for us (not luck really) > that we are not working with such a chip. Are you? > > > I strongly object to this unnecessary draft. If you look at RFCs > there > > are always cases that we wished we had done it differently, but we > are > > not going to change them since in most cases like this one it is too > > late. Sorry but that is the fact. > > We are implementing labels under GAL for non-TP OAM in our products > regardless of your objections. If a provider wants to use it, it will > be there. If it can also be used for PW, all the better. Its really > easy to do, so it doesn't hurt to do it. > > If a provider prefers to use CW all the time, I'm fine with that but we > still need labels under GAL for non-TP MPLS OAM. > > > Thx > > Shahram > > Curtis > > > > ----- Original Message ----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Thursday, August 04, 2011 06:38 AM > > To: Shahram Davari > > Cc: curtis@occnc.com ; Giles Heron > > ; Thomas Nadeau ; > > Yaakov Stein ; pwe3@ietf.org ; > Robert > > Rennison > > Subject: Re: [PWE3] Poll for WG adoption of > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > In message > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadc > > om.com> > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > Even if we assume this format (which is not yet incorporated in the > > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > > this case how is the HW supposed to examine the ACH channel Type to > > > decide how to process the packet? (unless you assume there is one > > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > This doesn't need to go in the fat-pw draft. It needs to go into the > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > > when some other feature, fat-pw or other, puts a label under the PW > > label. The GAL goes after the PW and before the other labels. A > > proper multipath distribution will skip any reserved label and use > the > > rest of the label stack to load balance. This allows spraying across > > the entropy space or testing a spacific payload label stack that has > > yielded trouble. > > > > Hardware that assumes ACH is right after GAL when the S-bit is not > set > > on the GAL is broken. > > > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > > > The IETF has never been sympathetic of broken hardware and should not > > be since we would halt progress. > > > > If the hardware is broken, then the fat-pw label can be omitted but > > only one path through any multipath would be tested. It would still > > work for TP, but not work in general. PW does not require TP. The > > fat-pw work is explicitly done for multipath because multipath is > used > > a lot in deployed networks and isn't going away. > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > To: Shahram Davari > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > > > pwe3@ietf.org; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa > > > dcom.com> > > > "Shahram Davari" writes: > > > > > > > > Hi Curtis, > > > > > > > > You are absolutely correct if there is no Entropy label. But with > > > > Entropy label most implementation assume a Entropy label to be > BoS > > > > and below the PW label. > > > > > > > > This draft doesn't even talk about whether the GAL should be BoS > > > > or the Entropy Label? In either case adding GAL would make the > > > > packet un-parsable by most HW. > > > > > > > > Thx > > > > Shahram > > > > > > > > > That should be covered in this work. At least it was covered in WG > > > email. PW, then GAL, then fat-pw (aka Flow label, which is > > > different from Entropy label in MPLS). > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | PW Label | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GAL | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | ... additional labels (ie: fat-pw) may be present | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | > > > ~ VCCV Message Body ~ > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The above would be a better choice. The VCCV is always after the > > > label entry with BOS (S-bit =3D 1). > > > > > > The flow label (or entropy label) must not be a reserved label. > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 > > > section > > > 1.2 (page 5) you will find. > > > > > > Note that the flow label MUST NOT be an MPLS reserved label > (values > > > in the range 0..15) [RFC3032], but is otherwise unconstrained by > the > > > protocol. > > > > > > > > > The flow label below GAL is needed so that all data paths which the > > > PW can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > To: Shahram Davari > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; > > > > Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > In message > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.br > > > > oadcom.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Giles, > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and > > > > > use VVCV Type 1? Also what is wrong with TTL approach for non- > CW? > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > Shahram, > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > > hardware need not know if the label above the GAL is an MPLS > label > > > > or a PW label, just that the next label is GAL and the label over > > > > it is not a SWAP. Unless we are talking about incredibly > > > > inflexible parser hardware, like none I've encounted recently, > > > > there should be no problem noticing a GAL below the POP or PW > > > > label and then directing the packet to OAM processing. Any > > > > remaining labels must be removed and hopefully no implementation > > > > neglects to look for BOS before deciding where the payload is > supposed to be. > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In > > > > this case TTL-expire would occur where a label swap was called > for > > > > and a GAL would be below the label containing the expired TTL. > > > > Since LDP can have transient loops, this avoids having lots of > > > > packets sent to the OAM engine should such a loop occur in a LDP > signaled MPLS PSN. > > > > > > > > This yield one way to do OAM with or without CW. A GAL label is > > > > below the label for which action is taken (POP or PW termination) > > > > or below a label for which TTL has expired. This method applied > to LSP and PW. > > > > > > > > I think mandating CW would be just as good a solution, but one > > > > that was rejected so this is the best we have. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > To: Thomas Nadeau; Shahram Davari > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that > > > > > basis I support this draft. > > > > > > > > > > Sure, it'll take a while to move away from the router alert > > > > > label and TTL approaches, but the GAL approach is definitely > > > > > better than either of those... > > > > > > > > > > Giles > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > wrote: > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > >> Hi, > > > > > >> > > > > > >> I also don=B9t support this draft since I don=B9t think to sol= ve > > > > > >> the problem we need yet a 4th type of VCCV. The best > solution is to mandate CW. > > > > > > > > > > > > While I am with you, that argument went out the window during > > > > > > the debates we had over the past 3 IETF meetings. Operators > > > > > > were very clear that they do not want to mandate the use of a > CW. Hence, > > > > > > Luca and I came up with this solution that narrows the scope > > > > > > to 2 modes, one that handles the CW case and one that doesn't > > > > > > while still both modes providing predictable OAM capabilities > > > > > > for the PW. > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > >> > > > > > >> Shahram > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > On > > > > > >> Behalf Of Robert Rennison > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew > > > > > >> (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> I do Not support the draft, > > > > > >> > > > > > >> After hearing the results of the earlier user deployment > > > > > >> poll I thought, =B3 ok the way out of this mess is to migrate > > > > > >> towards using the CW=B2. Then I see this proposal and wondered > > > > > >> what am I missing. I=B9ve still not seen the light of why > > > > > >> adding a fourth type will simplify matters, hence in the > > > > > >> absence of me understanding how this will simplify matter > versus complicate things, I=B9m against it. > > > > > >> > > > > > >> Rob > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > On > > > > > >> Behalf Of Alexander Vainshtein > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> Hi all, > > > > > >> I do NOT support this draft for the same reasons that Yaakov > has indicated. > > > > > >> > > > > > >> Regards, > > > > > >> Sasha > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On > Behalf > > > > > >> Of Yaakov Stein [yaakov_s@rad.com] > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> I do not support ! and I can not understand how anyone > can support it ! > > > > > >> > > > > > >> We do NOT need a fourth VCCV type, there are too many > already. > > > > > >> > > > > > >> I completely agree with the part that says if there is a CW > > > > > >> then the ACh should be marked by it. > > > > > >> > > > > > >> I do NOT agree that if the CW is not used then we should use > > > > > >> a non-PW method developed for MPLS-TP. > > > > > >> I do NOT agree that there is any way to deprecate the use of > > > > > >> TTL expiry to mark the ACh. > > > > > >> I do NOT agree that we should change mechanisms that have > > > > > >> been widely deployed for many years now, without an > extremely > > > > > >> pressing reason. > > > > > >> > > > > > >> Were the proposal to be that for PWs that traverse ONLY > > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, I > > > > > >> might be convinced not to object as strongly. > > > > > >> However, since I don't think that PWs can be limited in this > > > > > >> matter (the MPLS WG adopted the "seamless" draft) it would > be > > > > > >> difficult to convince me that such a limitation is possible. > > > > > >> > > > > > >> I would have enthusiastically support this proposal had it > > > > > >> been brought 8 years ago. > > > > > >> It's too late for this now. > > > > > >> > > > > > >> Y(J)S > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > On > > > > > >> Behalf Of Bocci, Matthew (Matthew) > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > >> To: pwe3@ietf.org > > > > > >> Subject: [PWE3] Poll for WG adoption of > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> This email begins a two week poll to help assess if there is > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 > working group draft. > > > > > >> > > > > > >> Please indicate whether or not you support adoption of this > > > > > >> draft, and also send any comments to the PWE3 list. > > > > > >> > > > > > >> This poll will end on Friday 12th August. > > > > > >> > > > > > >> Regards, > > > > > >> > > > > > >> Matthew & Andy > > > > > >> 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. From davari@broadcom.com Thu Aug 4 11:10:08 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 C99CB21F87C3 for ; Thu, 4 Aug 2011 11:10:08 -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.000, 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 WLCuq3U5XeRX for ; Thu, 4 Aug 2011 11:10:07 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 33F9A21F86C1 for ; Thu, 4 Aug 2011 11:10:07 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 04 Aug 2011 11:14:59 -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; Thu, 4 Aug 2011 11:09:57 -0700 From: "Shahram Davari" To: "John E Drake" , "curtis@occnc.com" Date: Thu, 4 Aug 2011 11:09:56 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSyeL4keOJqv44SQW5wgy/thjRDQABWHpAAABpfEA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F652@SJEXCHCCR02.corp.ad.broadcom.com> References: Your message of "Thu, 04 Aug 2011 07:42:21 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> <201108041712.p74HCMCH057629@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB333163A0AC0CCCE1@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0AC0CCCE1@EMBX01-HQ.jnpr.net> 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: 62243E293KO2600388-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 18:10:08 -0000 John, If your point is that this is mentioned in an IETF draft then please look a= t the date of the draft as well (May 5 2011). Also this draft applies only = to MPLS tunnels and not PW. I hope you don't expect people to implement an = IETF draft-00 which was published just 3 months ago. -Shahram -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, August 04, 2011 10:56 AM To: curtis@occnc.com; Shahram Davari Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt >From Section 6 of the Entropy Label I-D (http://datatracker.ietf.org/doc/dr= aft-ietf-mpls-entropy-label/?include_text=3D1): "As part of the MPLS-TP work, an in-band OAM channel is defined in [RFC5586= ]. Packets sent in this channel are identified with a reserved label, the = Generic Associated Channel Label (GAL) placed at the bottom of the MPLS lab= el stack. In order to use the inband OAM channel with entropy labels, this= memo relaxes the restriction that the GAL must be at the bottom of the MPL= S label stack. Rather, the GAL is placed in the MPLS label stack above the= entropy label so that it effectively functions as an application label." Sent from my iPhone > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Curtis Villamizar > Sent: Thursday, August 04, 2011 10:12 AM > To: Shahram Davari > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > > In message > <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadco > m.com> > "Shahram Davari" writes: > > > > I don't agree with you. This is not about broken HW. Before this > draft > > how was one supposed to process a packet with GAL in the middle of > the > > label stack? > > Before this draft one had to read the MPLS and PWE3 mailing list and > remember what was said. Getting it written in a draft is the next > step. > > Some of the most purist of the MPLS-TP folks have done a good job of > shouting down any suggestion that multipath had a valid place in any > network for quite some time. > > > What if this draft had decided to put GAL after entropy? Then the HW > > processing would have been completely different from what you are > > proposing on the fly now. > > Putting labels under GAL for the purpose of entropy was proposed on > MPLS mailing list for well over a year now, probably close to two > years, more recently on PWE3. It is reflected in other internet- > drafts, For example, draft-villamizar-mpls-tp-multipath-00 > was submitted before Maastricht but fell off the end of the agenda. > > It is also in a document that we have been giving to chip vendors under > NDA stating detailed requirements starting just under a year ago. > Before that is was more verbal discussion of requirements and email. > Your friends in another part of your company were eliminated from > consideration for other reasons a while back but have heard this > requirement verbally at least. > > > You are making imaginary assumptions that HW should be able to > process > > what was in your mind. > > That is presumptious on your part. Actually we have given this > requirement to chip vendors in our product space for about a year and a > half and I have brought this up for even longer in the MPLS WG and more > recently on PWE3. Two chip vendors have taken these requirements to > heart and will be allowing labels under GAL plus the forwarding > functionality described in draft-villamizar-mpls-tp-multipath-01. > > Of all the packet processors that we have considered, all on the very > high end of things, I know of none that have a parser that is so > inflexible that it could not deal with a label under GAL and still find > the OAM payload with nothing more than a change to the low level > programming of the parser. > > I can envision that chips do exist for which the parser is too hard > coded to accommodate such a change. Lucky for us (not luck really) > that we are not working with such a chip. Are you? > > > I strongly object to this unnecessary draft. If you look at RFCs > there > > are always cases that we wished we had done it differently, but we > are > > not going to change them since in most cases like this one it is too > > late. Sorry but that is the fact. > > We are implementing labels under GAL for non-TP OAM in our products > regardless of your objections. If a provider wants to use it, it will > be there. If it can also be used for PW, all the better. Its really > easy to do, so it doesn't hurt to do it. > > If a provider prefers to use CW all the time, I'm fine with that but we > still need labels under GAL for non-TP MPLS OAM. > > > Thx > > Shahram > > Curtis > > > > ----- Original Message ----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Thursday, August 04, 2011 06:38 AM > > To: Shahram Davari > > Cc: curtis@occnc.com ; Giles Heron > > ; Thomas Nadeau ; > > Yaakov Stein ; pwe3@ietf.org ; > Robert > > Rennison > > Subject: Re: [PWE3] Poll for WG adoption of > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > In message > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadc > > om.com> > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > Even if we assume this format (which is not yet incorporated in the > > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > > this case how is the HW supposed to examine the ACH channel Type to > > > decide how to process the packet? (unless you assume there is one > > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > This doesn't need to go in the fat-pw draft. It needs to go into the > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > > when some other feature, fat-pw or other, puts a label under the PW > > label. The GAL goes after the PW and before the other labels. A > > proper multipath distribution will skip any reserved label and use > the > > rest of the label stack to load balance. This allows spraying across > > the entropy space or testing a spacific payload label stack that has > > yielded trouble. > > > > Hardware that assumes ACH is right after GAL when the S-bit is not > set > > on the GAL is broken. > > > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > > > The IETF has never been sympathetic of broken hardware and should not > > be since we would halt progress. > > > > If the hardware is broken, then the fat-pw label can be omitted but > > only one path through any multipath would be tested. It would still > > work for TP, but not work in general. PW does not require TP. The > > fat-pw work is explicitly done for multipath because multipath is > used > > a lot in deployed networks and isn't going away. > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > To: Shahram Davari > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > > > pwe3@ietf.org; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa > > > dcom.com> > > > "Shahram Davari" writes: > > > > > > > > Hi Curtis, > > > > > > > > You are absolutely correct if there is no Entropy label. But with > > > > Entropy label most implementation assume a Entropy label to be > BoS > > > > and below the PW label. > > > > > > > > This draft doesn't even talk about whether the GAL should be BoS > > > > or the Entropy Label? In either case adding GAL would make the > > > > packet un-parsable by most HW. > > > > > > > > Thx > > > > Shahram > > > > > > > > > That should be covered in this work. At least it was covered in WG > > > email. PW, then GAL, then fat-pw (aka Flow label, which is > > > different from Entropy label in MPLS). > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | PW Label | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GAL | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | ... additional labels (ie: fat-pw) may be present | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | > > > ~ VCCV Message Body ~ > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The above would be a better choice. The VCCV is always after the > > > label entry with BOS (S-bit =3D 1). > > > > > > The flow label (or entropy label) must not be a reserved label. > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 > > > section > > > 1.2 (page 5) you will find. > > > > > > Note that the flow label MUST NOT be an MPLS reserved label > (values > > > in the range 0..15) [RFC3032], but is otherwise unconstrained by > the > > > protocol. > > > > > > > > > The flow label below GAL is needed so that all data paths which the > > > PW can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > To: Shahram Davari > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; > > > > Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > In message > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.br > > > > oadcom.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Giles, > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and > > > > > use VVCV Type 1? Also what is wrong with TTL approach for non- > CW? > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > Shahram, > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > > hardware need not know if the label above the GAL is an MPLS > label > > > > or a PW label, just that the next label is GAL and the label over > > > > it is not a SWAP. Unless we are talking about incredibly > > > > inflexible parser hardware, like none I've encounted recently, > > > > there should be no problem noticing a GAL below the POP or PW > > > > label and then directing the packet to OAM processing. Any > > > > remaining labels must be removed and hopefully no implementation > > > > neglects to look for BOS before deciding where the payload is > supposed to be. > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In > > > > this case TTL-expire would occur where a label swap was called > for > > > > and a GAL would be below the label containing the expired TTL. > > > > Since LDP can have transient loops, this avoids having lots of > > > > packets sent to the OAM engine should such a loop occur in a LDP > signaled MPLS PSN. > > > > > > > > This yield one way to do OAM with or without CW. A GAL label is > > > > below the label for which action is taken (POP or PW termination) > > > > or below a label for which TTL has expired. This method applied > to LSP and PW. > > > > > > > > I think mandating CW would be just as good a solution, but one > > > > that was rejected so this is the best we have. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > To: Thomas Nadeau; Shahram Davari > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that > > > > > basis I support this draft. > > > > > > > > > > Sure, it'll take a while to move away from the router alert > > > > > label and TTL approaches, but the GAL approach is definitely > > > > > better than either of those... > > > > > > > > > > Giles > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > wrote: > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > >> Hi, > > > > > >> > > > > > >> I also don=B9t support this draft since I don=B9t think to sol= ve > > > > > >> the problem we need yet a 4th type of VCCV. The best > solution is to mandate CW. > > > > > > > > > > > > While I am with you, that argument went out the window during > > > > > > the debates we had over the past 3 IETF meetings. Operators > > > > > > were very clear that they do not want to mandate the use of a > CW. Hence, > > > > > > Luca and I came up with this solution that narrows the scope > > > > > > to 2 modes, one that handles the CW case and one that doesn't > > > > > > while still both modes providing predictable OAM capabilities > > > > > > for the PW. > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > >> > > > > > >> Shahram > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > On > > > > > >> Behalf Of Robert Rennison > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew > > > > > >> (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> I do Not support the draft, > > > > > >> > > > > > >> After hearing the results of the earlier user deployment > > > > > >> poll I thought, =B3 ok the way out of this mess is to migrate > > > > > >> towards using the CW=B2. Then I see this proposal and wondered > > > > > >> what am I missing. I=B9ve still not seen the light of why > > > > > >> adding a fourth type will simplify matters, hence in the > > > > > >> absence of me understanding how this will simplify matter > versus complicate things, I=B9m against it. > > > > > >> > > > > > >> Rob > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > On > > > > > >> Behalf Of Alexander Vainshtein > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> Hi all, > > > > > >> I do NOT support this draft for the same reasons that Yaakov > has indicated. > > > > > >> > > > > > >> Regards, > > > > > >> Sasha > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On > Behalf > > > > > >> Of Yaakov Stein [yaakov_s@rad.com] > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> I do not support ! and I can not understand how anyone > can support it ! > > > > > >> > > > > > >> We do NOT need a fourth VCCV type, there are too many > already. > > > > > >> > > > > > >> I completely agree with the part that says if there is a CW > > > > > >> then the ACh should be marked by it. > > > > > >> > > > > > >> I do NOT agree that if the CW is not used then we should use > > > > > >> a non-PW method developed for MPLS-TP. > > > > > >> I do NOT agree that there is any way to deprecate the use of > > > > > >> TTL expiry to mark the ACh. > > > > > >> I do NOT agree that we should change mechanisms that have > > > > > >> been widely deployed for many years now, without an > extremely > > > > > >> pressing reason. > > > > > >> > > > > > >> Were the proposal to be that for PWs that traverse ONLY > > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, I > > > > > >> might be convinced not to object as strongly. > > > > > >> However, since I don't think that PWs can be limited in this > > > > > >> matter (the MPLS WG adopted the "seamless" draft) it would > be > > > > > >> difficult to convince me that such a limitation is possible. > > > > > >> > > > > > >> I would have enthusiastically support this proposal had it > > > > > >> been brought 8 years ago. > > > > > >> It's too late for this now. > > > > > >> > > > > > >> Y(J)S > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > On > > > > > >> Behalf Of Bocci, Matthew (Matthew) > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > >> To: pwe3@ietf.org > > > > > >> Subject: [PWE3] Poll for WG adoption of > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> This email begins a two week poll to help assess if there is > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 > working group draft. > > > > > >> > > > > > >> Please indicate whether or not you support adoption of this > > > > > >> draft, and also send any comments to the PWE3 list. > > > > > >> > > > > > >> This poll will end on Friday 12th August. > > > > > >> > > > > > >> Regards, > > > > > >> > > > > > >> Matthew & Andy > > > > > >> 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. From jdrake@juniper.net Thu Aug 4 11:18: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 530EF21F88A5; Thu, 4 Aug 2011 11:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 5SMZmW6TbMuq; Thu, 4 Aug 2011 11:18:22 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id C89C421F88A1; Thu, 4 Aug 2011 11:18:21 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTjric1AOxm8Dhb3Ut/uIHpXFLwD1ayaq@postini.com; Thu, 04 Aug 2011 11:18:37 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 4 Aug 2011 10:58:50 -0700 From: John E Drake To: Loa Andersson , "rtg-ads@tools.ietf.org" Date: Thu, 4 Aug 2011 10:58:47 -0700 Thread-Topic: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 Thread-Index: AcxSzlfOoejrgvVqTzS/vqt7j3CKxQAAZu6A Message-ID: <5E893DB832F57341992548CDBB333163A0AC0CCCEE@EMBX01-HQ.jnpr.net> References: <4E386CF0.5050700@pi.nu> <4E3ADAE2.5060907@pi.nu> In-Reply-To: <4E3ADAE2.5060907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Kireeti Kompella , "rtg-dir@ietf.org" , "pwe3@ietf.org" , "draft-ietf-pwe3-fat.all@tools.ietf.org" Subject: Re: [PWE3] [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 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, 04 Aug 2011 18:18:23 -0000 Loa, This statement will also be added to the next version of the entropy label = I-D. Thanks, John Sent from my iPhone > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > Behalf Of Loa Andersson > Sent: Thursday, August 04, 2011 10:46 AM > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; pwe3@ietf.org; draft-ietf-pwe3- > fat.all@tools.ietf.org > Subject: Re: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 >=20 > All, >=20 >=20 > I have one more point on this - I should have captured it in > the previous mail but had to think and discuss a bit about it! >=20 > Doing ECMP hashing over the label stack as described is OK, but > has one thing that needs to be taken care of. Introducing a > reserved label - most prominently the GAL - into the label > stack will change the outcome of the hash. Since we are ECMP-ing > on the hash result, we will no longer to be able to guarantee > that normal traffic and OAM packets will no longer be fate > sharing - draft-ietf-pwe3-fat-pw should say explicitly that > reserved labels should be excluded from ECMP hashing. >=20 > /Loa >=20 > On 2011-08-02 14:32, Loa Andersson wrote: > > Hello, > > > > I have been selected as the Routing Directorate reviewer for > > draft-ietf-pwe3-fat-pw-07. > > > > The Routing Directorate seeks to review all routing or > > routing-related drafts as they pass through IETF last call and IESG > > review, and sometimes on special request. The purpose of the review > > is to provide assistance to the Routing ADs. For more information > > about the Routing Directorate, please see > > http://www.ietf.org/iesg/directorate/routing.html > > > > Although these comments are primarily for the use of the Routing ADs, > > it would be helpful if you could consider them along with any other > > IETF Last Call comments that you receive, and strive to resolve them > > through discussion or by updating the draft. > > > > Document: draft-ietf-pwe3-fat-pw-07 > > Reviewer: Loa Andersson > > Review Date: 2 Aug 2011 > > IETF LC End Date: 3 Aug 2011 > > Intended Status: Standards Track > > > > Summary: > > I have no major concerns about this document, howver I thing it > > would be good to reslove the mostly editorial comments below > > (especially on the IANA section) before publication. > > > > Comments: > > > > Unexpanded acronyms: > > > > OAM appears in the table of content and as header 7. It is not > > expanded in the document anywhere. Should be done at first occurance. > > > > page 6. The last paragraph of section 1 talks about TC bits > > (and EXP bits). We don't have TC bits - the correct name is TC field. > > > > First paragraph section three: > > This paragraph talks in genral about "load balanced paths" while the > > rest of the document is very specific about ECMP, it is the intention > > that this should work for any load balancing paradigm? > > > > Second paragraph section three: > > Normally a label is assigned by the down stream node, this scheme > > is doing upstream allocation. Don't see a problem under normal > > operation, but if the label "by accident" becomes top of stack > > this could have "interesting" effects. > > > > Sectyion 4 second paagraph: > > > > OLD > > > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. A PE that is using PW signalling and that does > > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > > A PE that is using PW signalling and which does not receive a FL Sub- > > TLV from its peer MUST NOT include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > > > NEW > > > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. An ingress PE that is using PW signalling > > and that does not send a FL Sub-TLV MUST NOT include a flow label > > in the PW packet. An ingress PE that is using PW signalling and > > which does not receive a FL Sub-TLV from its egress peer MUST NOT > > include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > > > The IANA section: > > > > In the IANA section we should use a TBD entry for the Flow label > > indicator; and maybe add 0x17 as suggest value in the text. > > > > The text in the IANA section needs to aligned with the rest of > > the text, or maybe even better have the rest of the text align > > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > > else but in the iana section. > > > > To make it easier to find the references to the IANA registries > > should start with "Pseudowire Name Spaces (PWE3)" point to > > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > > sub-registry, and ask for assigment of the next free value from > > the Experts review space (suggested value 0x17). > > > > On the other hand it looks like we have an early assigment > > (Flow Label shows up with the value 0x17). If this is the case > > after making the text changes suggest above this should be mentioned > > in the IANA section. >=20 > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From pabloisnot@gmail.com Thu Aug 4 11:23: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 9F08121F8A64 for ; Thu, 4 Aug 2011 11:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=1.302, 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 M8L+N1QiA5mo for ; Thu, 4 Aug 2011 11:23:27 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 510E621F8634 for ; Thu, 4 Aug 2011 11:23:27 -0700 (PDT) Received: by qwc23 with SMTP id 23so1459718qwc.31 for ; Thu, 04 Aug 2011 11:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ohKgd5/0hGhdPZUyPx88a6Esw4ubMVhwJag5jpZRmno=; b=sWj6Thp8CqRGcRIdHhK3tzFKufeQONi6ZLZfIOPoS5RfmIsZhTJAWwFaAsaBTX/iv/ SBQLdMotj9Ifewg/XCYxcfUGILHeK3Rclbu0AiVzc8OTIQ1T9yKHSm/d0oqW4OI1aJKr UAsG37uhPyQb0XaQuOVl/mEB0ASCx7ykfDOOI= MIME-Version: 1.0 Received: by 10.224.203.131 with SMTP id fi3mr847448qab.381.1312482219845; Thu, 04 Aug 2011 11:23:39 -0700 (PDT) Received: by 10.224.11.143 with HTTP; Thu, 4 Aug 2011 11:23:39 -0700 (PDT) Date: Thu, 4 Aug 2011 14:23:39 -0400 Message-ID: From: Pablo Frank To: "curtis@occnc.com" Content-Type: multipart/alternative; boundary=20cf300512c27ce87104a9b21491 Cc: "yaakov_s@rad.com" , "pwe3@ietf.org" , "Robert.Rennison@ecitele.com" Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 18:23:29 -0000 --20cf300512c27ce87104a9b21491 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Curtis, Why does it matter if the entropy/flow labels are above or below the GAL? What advantage is gained by putting such labels below the GAL? To me, putting the GAL in-between the PW (or LSP) label and the Flow (or Entropy) label just feels out of place. I should only really care about a GAL if I encounter it as a result of disposing of the labels either because they've been popped or because the TTL has expired. When the PW label gets terminated and all of a sudden, I encounter a GAL, it seems awkward because in my mind, I have not finished terminating the PW layer. There is still this flow label that I need to dispose of... so the hardware has to remembe= r that it saw a GAL and continue processing labels. It seems much cleaner if we finish dealing with the multipath labels before considering whether it's carrying normal data or an associated channel. If anything, I see an advantage in having the GAL below the flow label because it allows the option of monitoring individual paths (assuming, of course, that GAL is excluded from the hash). regards, Pablo ----- Original Message ----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: Thursday, August 04, 2011 06:38 AM > To: Shahram Davari > Cc: curtis@occnc.com ; Giles Heron < > giles.heron@gmail.com>; Thomas Nadeau ; Yaakov > Stein ; pwe3@ietf.org ; Robert Rennison = < > Robert.Rennison@ecitele.com> > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > > > In message < > 2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.c= om > > > "Shahram Davari" writes: > > > > Hi Curtis, > > > > Even if we assume this format (which is not yet incorporated in the > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > this case how is the HW supposed to examine the ACH channel Type to > > decide how to process the packet? (unless you assume there is one > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > Thx > > Shahram > > > Shahram, > > This doesn't need to go in the fat-pw draft. It needs to go into the > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > when some other feature, fat-pw or other, puts a label under the PW > label. The GAL goes after the PW and before the other labels. A > proper multipath distribution will skip any reserved label and use the > rest of the label stack to load balance. This allows spraying across > the entropy space or testing a spacific payload label stack that has > yielded trouble. > > Hardware that assumes ACH is right after GAL when the S-bit is not set > on the GAL is broken. > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > The IETF has never been sympathetic of broken hardware and should not > be since we would halt progress. > > If the hardware is broken, then the fat-pw label can be omitted but > only one path through any multipath would be tested. It would still > work for TP, but not work in general. PW does not require TP. The > fat-pw work is explicitly done for multipath because multipath is used > a lot in deployed networks and isn't going away. > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, August 03, 2011 4:53 PM > > To: Shahram Davari > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > pwe3@ietf.org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > In message < > 2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.c= om > > > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > You are absolutely correct if there is no Entropy label. But with > > > Entropy label most implementation assume a Entropy label to be BoS an= d > > > below the PW label. > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > the Entropy Label? In either case adding GAL would make the packet > > > un-parsable by most HW. > > > > > > Thx > > > Shahram > > > > > > That should be covered in this work. At least it was covered in WG > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > from Entropy label in MPLS). > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PW Label | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GAL | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ... additional labels (ie: fat-pw) may be present | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ VCCV Message Body ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > The above would be a better choice. The VCCV is always after the > > label entry with BOS (S-bit =3D 1). > > > > The flow label (or entropy label) must not be a reserved label. > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > > 1.2 (page 5) you will find. > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > protocol. > > > > > > The flow label below GAL is needed so that all data paths which the PW > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > To: Shahram Davari > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert > Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message < > 2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.c= om > > > > > "Shahram Davari" writes: > > > > > > > > Giles, > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > Thx > > > > Shahram > > > > > > > > > Shahram, > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > hardware need not know if the label above the GAL is an MPLS label or > > > a PW label, just that the next label is GAL and the label over it is > > > not a SWAP. Unless we are talking about incredibly inflexible parser > > > hardware, like none I've encounted recently, there should be no > > > problem noticing a GAL below the POP or PW label and then directing > > > the packet to OAM processing. Any remaining labels must be removed > > > and hopefully no implementation neglects to look for BOS before > > > deciding where the payload is supposed to be. > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In thi= s > > > case TTL-expire would occur where a label swap was called for and a > > > GAL would be below the label containing the expired TTL. Since LDP > > > can have transient loops, this avoids having lots of packets sent to > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > This yield one way to do OAM with or without CW. A GAL label is belo= w > > > the label for which action is taken (POP or PW termination) or below = a > > > label for which TTL has expired. This method applied to LSP and PW. > > > > > > I think mandating CW would be just as good a solution, but one that > > > was rejected so this is the best we have. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > To: Thomas Nadeau; Shahram Davari > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis I > support > > > > this draft. > > > > > > > > Sure, it'll take a while to move away from the router alert label a= nd > TTL > > > > approaches, but the GAL approach is definitely better than either o= f > > > > those... > > > > > > > > Giles > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > wrote: > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I also don=B9t support this draft since I don=B9t think to solve= the > problem we > > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > > > While I am with you, that argument went out the window during the > debates we > > > > > had over the past 3 IETF meetings. Operators > > > > > were very clear that they do not want to mandate the use of a CW. > Hence, > > > > > Luca and I came up with this solution that narrows the > > > > > scope to 2 modes, one that handles the CW case and one that doesn= 't > while > > > > > still both modes providing predictable OAM capabilities > > > > > for the PW. > > > > > > > > > > --Tom > > > > > > > > > > > > > > >> > > > > >> Shahram > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of > > > > >> Robert Rennison > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew)= ; > > > > >> pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> I do Not support the draft, > > > > >> > > > > >> After hearing the results of the earlier user deployment poll I > thought, > > > > >> =B3 ok the way out of this mess is to migrate towards using the > CW=B2. Then I > > > > >> see this proposal and wondered what am I missing. I=B9ve still = not > seen the > > > > >> light of why adding a fourth type will simplify matters, hence i= n > the absence > > > > >> of me understanding how this will simplify matter versus > complicate things, > > > > >> I=B9m against it. > > > > >> > > > > >> Rob > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of > > > > >> Alexander Vainshtein > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> Hi all, > > > > >> I do NOT support this draft for the same reasons that Yaakov has > indicated. > > > > >> > > > > >> Regards, > > > > >> Sasha > > > > >> > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of > Yaakov Stein > > > > >> [yaakov_s@rad.com] > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> I do not support ! and I can not understand how anyone can > support it ! > > > > >> > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > >> > > > > >> I completely agree with the part that says if there is a CW then > the ACh > > > > >> should be marked by it. > > > > >> > > > > >> I do NOT agree that if the CW is not used then we should use a > non-PW method > > > > >> developed for MPLS-TP. > > > > >> I do NOT agree that there is any way to deprecate the use of TTL > expiry to > > > > >> mark the ACh. > > > > >> I do NOT agree that we should change mechanisms that have been > widely > > > > >> deployed for many years now, > > > > >> without an extremely pressing reason. > > > > >> > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP = to > have the > > > > >> ADDITIONAL option > > > > >> for ACh marking, I might be convinced not to object as strongly. > > > > >> However, since I don't think that PWs can be limited in this > matter (the MPLS > > > > >> WG adopted the "seamless" draft) > > > > >> it would be difficult to convince me that such a limitation is > possible. > > > > >> > > > > >> I would have enthusiastically support this proposal had it been > brought 8 > > > > >> years ago. > > > > >> It's too late for this now. > > > > >> > > > > >> Y(J)S > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of > > > > >> Bocci, Matthew (Matthew) > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > >> To: pwe3@ietf.org > > > > >> Subject: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> This email begins a two week poll to help assess if there is > consensus to > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group > draft. > > > > >> > > > > >> Please indicate whether or not you support adoption of this draf= t, > and also > > > > >> send any comments to the PWE3 list. > > > > >> > > > > >> This poll will end on Friday 12th August. > > > > >> > > > > >> Regards, > > > > >> > > > > >> Matthew & Andy > > > > >> This e-mail message is intended for the recipient only and > contains > > > > >> information which is CONFIDENTIAL and which may be proprietary t= o > 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 copie= s > thereof. > > > > >> This e-mail message is intended for the recipient only and > contains > > > > >> information which is CONFIDENTIAL and which may be proprietary t= o > 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 copie= s > thereof. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --20cf300512c27ce87104a9b21491 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Curtis,

Why does it matter if the entropy/flow labels ar= e above or below the GAL? =A0What advantage is gained by putting such label= s below the GAL?

To me, putting the GAL in-between= the PW (or LSP) label and the Flow (or Entropy) label just feels out of pl= ace. =A0I should only really care about a GAL if I encounter it as a result= of disposing of the labels either because they've been popped or becau= se the TTL has expired. =A0When the PW label gets terminated and all of a s= udden, I encounter a GAL, it seems awkward because in my mind, I have not f= inished terminating the PW layer. =A0There is still this flow label that I = need to dispose of... so the hardware has to remember that it saw a GAL and= continue processing labels. =A0It seems much cleaner if we finish dealing = with the multipath labels before considering whether it's carrying norm= al data or an associated channel. =A0

If anything, I see an advantage in having the GAL below= the flow label because it allows the option of monitoring individual paths= (assuming, of course, that GAL is excluded from the hash).

regards,
Pablo

----- Original Message -----
From: Curtis Villamizar [mailto:curtis@occnc.com]
Sent: Thursday, August 04, 2011 06:38 AM
To: Shahram Davari
Cc: curtis@occnc.com<= /a> <curtis@occnc.= com>; Giles Heron <giles.heron@gmail.com>; Thomas Nadeau <tnadeau@lucidvision.com= >; Yaakov Stein <yaakov_s@rad.com>; pwe3@ietf.org <pwe3@ietf.org>; Robert Rennison <Robert.Rennison@ecitele.com>
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt=


In message <2C2F1EBA8050E74EA81502= D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.com>
"Shahram Davari" writes:
>
> Hi Curtis,
>
> Even if we assume this format (which is not yet incorporated in the > fat-pw draft), then most hardware assume ACH is right after GAL. In > this case how is the HW supposed to examine the ACH channel Type to > decide how to process the packet? (unless you assume there is one
> engine that can process all OAM packet types such as BFD, AIS, PSC, > LSP-ping, LDI, LKR, LM, DM, etc)
>
> Thx
> Shahram


Shahram,

This doesn't need to go in the fat-pw draft. =A0It needs to go into the=
draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic
when some other feature, fat-pw or other, puts a label under the PW
label. =A0The GAL goes after the PW and before the other labels. =A0A
proper multipath distribution will skip any reserved label and use the
rest of the label stack to load balance. =A0This allows spraying across
the entropy space or testing a spacific payload label stack that has
yielded trouble.

Hardware that assumes ACH is right after GAL when the S-bit is not set
on the GAL is broken.

The payload (ACH) is after the BOS (aka S-bit =3D 1).

The IETF has never been sympathetic of broken hardware and should not
be since we would halt progress.

If the hardware is broken, then the fat-pw label can be omitted but
only one path through any multipath would be tested. =A0It would still
work for TP, but not work in general. =A0PW does not require TP. =A0The
fat-pw work is explicitly done for multipath because multipath is used
a lot in deployed networks and isn't going away.

Curtis


> -----Original Message-----
> From: curtis@occ= nc.com [mailto:cu= rtis@occnc.com]
> Sent: Wednesday, August 03, 2011 4:53 PM
> To: Shahram Davari
> Cc: curtis@occnc= .com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison
> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-0= 2.txt
>
>
> In message <2C2F1EBA8050E74EA= 81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com>
> "Shahram Davari" writes:
> >
> > Hi Curtis,
> >
> > You are absolutely correct if there is no Entropy label. But with=
> > Entropy label most implementation assume a Entropy label to be Bo= S and
> > below the PW label.
> >
> > This draft doesn't even talk about whether the GAL should be = BoS or
> > the Entropy Label? In either case adding GAL would make the packe= t
> > un-parsable by most HW.
> >
> > Thx
> > Shahram
>
>
> That should be covered in this work. =A0At least it was covered in WG<= br> > email. =A0PW, then GAL, then fat-pw (aka Flow label, which is differen= t
> from Entropy label in MPLS).
>
> 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PW Label =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GAL =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | =A0 =A0 ... additional labels (ie: fat-pw) may be present =A0 =A0 = =A0 =A0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |0 0 0 1|Version| =A0 Reserved =A0 =A0| =A0Associated Channel Type =A0= =A0 =A0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> ~ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0VCCV Message Body =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0~
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> The above would be a better choice. =A0The VCCV is always after the > label entry with BOS (S-bit =3D 1).
>
> The flow label (or entropy label) must not be a reserved label.
> Therefore there is no ambiguity. =A0In draft-ietf-pwe3-fat-pw-07 secti= on
> 1.2 (page 5) you will find.
>
> =A0 =A0Note that the flow label MUST NOT be an MPLS reserved label (va= lues
> =A0 =A0in the range 0..15) [RFC3032], but is otherwise unconstrained b= y the
> =A0 =A0protocol.
>
>
> The flow label below GAL is needed so that all data paths which the PW=
> can take are exercised by OAM (ie: LSP Ping used within VCCV).
>
> Curtis
>
>
> > -----Original Message-----
> > From: curti= s@occnc.com [mailto:curtis@occnc.com]
> > Sent: Wednesday, August 03, 2011 4:05 PM
> > To: Shahram Davari
> > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison
> > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vcc= v-2-02.txt
> >
> >
> > In message <2C2F1EBA8050= E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com>
> > "Shahram Davari" writes:
> > >
> > > Giles,
> > >
> > > Adding GAL to PW requires HW change, so why not just add CW = and use
> > > VVCV Type 1? =A0Also what is wrong with TTL approach for non= -CW?
> > >
> > > Thx
> > > Shahram
> >
> >
> > Shahram,
> >
> > Adding GAL to an MPLS label stack requires hardware support. =A0T= he
> > hardware need not know if the label above the GAL is an MPLS labe= l or
> > a PW label, just that the next label is GAL and the label over it= is
> > not a SWAP. =A0Unless we are talking about incredibly inflexible = parser
> > hardware, like none I've encounted recently, there should be = no
> > problem noticing a GAL below the POP or PW label and then directi= ng
> > the packet to OAM processing. =A0Any remaining labels must be rem= oved
> > and hopefully no implementation neglects to look for BOS before > > deciding where the payload is supposed to be.
> >
> > TTL is best reserved for traceroute only (in the MS-PW case). =A0= In this
> > case TTL-expire would occur where a label swap was called for and= a
> > GAL would be below the label containing the expired TTL. =A0Since= LDP
> > can have transient loops, this avoids having lots of packets sent= to
> > the OAM engine should such a loop occur in a LDP signaled MPLS PS= N.
> >
> > This yield one way to do OAM with or without CW. =A0A GAL label i= s below
> > the label for which action is taken (POP or PW termination) or be= low a
> > label for which TTL has expired. =A0This method applied to LSP an= d PW.
> >
> > I think mandating CW would be just as good a solution, but one th= at
> > was rejected so this is the best we have.
> >
> > Curtis
> >
> >
> > > -----Original Message-----
> > > From: Giles Heron [mailto:giles.heron@gmail.com]
> > > Sent: Wednesday, August 03, 2011 11:10 AM
> > > To: Thomas Nadeau; Shahram Davari
> > > Cc: pwe3@= ietf.org; Yaakov Stein; Robert Rennison
> > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe= 3-vccv-2-02.txt
> > >
> > > Agreed - some operators won't want to use a CW, and on t= hat basis I support
> > > this draft.
> > >
> > > Sure, it'll take a while to move away from the router al= ert label and TTL
> > > approaches, but the GAL approach is definitely better than e= ither of
> > > those...
> > >
> > > Giles
> > >
> > > On 02/08/2011 12:59, "Thomas Nadeau" <tnadeau@lucidvision.c= om> wrote:
> > >
> > > >
> > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I also don=B9t support this draft since I don=B9t t= hink to solve the problem we
> > > >> need yet a 4th type of VCCV. The best solution is t= o mandate CW.
> > > >
> > > > While I am with you, that argument went out the window = during the debates we
> > > > had over the past 3 IETF meetings. Operators
> > > > were very clear that they do not want to mandate the us= e of a CW. =A0 Hence,
> > > > Luca and I came up with this solution that narrows the<= br> > > > > scope to 2 modes, one that handles the CW case and one = that doesn't while
> > > > still both modes providing predictable OAM capabilities=
> > > > for the PW.
> > > >
> > > > --Tom
> > > >
> > > >
> > > >>
> > > >> Shahram
> > > >>
> > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> > > >> Robert Rennison
> > > >> Sent: Sunday, July 31, 2011 7:40 PM
> > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matt= hew (Matthew);
> > > >> = pwe3@ietf.org
> > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-n= adeau-pwe3-vccv-2-02.txt
> > > >>
> > > >> I do Not support the draft,
> > > >>
> > > >> After hearing the results of the earlier user deplo= yment =A0poll I thought,
> > > >> =B3 ok =A0the way out of this mess is to migrate to= wards using the CW=B2. Then I
> > > >> see this proposal and wondered what am I missing. = =A0I=B9ve still not seen the
> > > >> light of why adding a fourth type will simplify mat= ters, hence in the absence
> > > >> of me understanding how this will simplify matter v= ersus complicate things,
> > > >> I=B9m against it.
> > > >>
> > > >> Rob
> > > >>
> > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> > > >> Alexander Vainshtein
> > > >> Sent: Sunday, July 31, 2011 12:45 AM
> > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org
> > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-n= adeau-pwe3-vccv-2-02.txt
> > > >>
> > > >> Hi all,
> > > >> I do NOT support this draft for the same reasons th= at Yaakov has indicated.
> > > >>
> > > >> Regards,
> > > >> =A0 =A0 =A0Sasha
> > > >>
> > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Ste= in
> > > >> [yaakov_s@rad.com]
> > > >> Sent: Friday, July 29, 2011 3:58 AM
> > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org
> > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-n= adeau-pwe3-vccv-2-02.txt
> > > >>
> > > >> I do not support ! =A0 =A0and I can not understand = how anyone can support it !
> > > >>
> > > >> We do NOT need a fourth VCCV type, there are too ma= ny already.
> > > >>
> > > >> I completely agree with the part that says if there= is a CW then the ACh
> > > >> should be marked by it.
> > > >>
> > > >> I do NOT agree that if the CW is not used then we s= hould use a non-PW method
> > > >> developed for MPLS-TP.
> > > >> I do NOT agree that there is any way to deprecate t= he use of TTL expiry to
> > > >> mark the ACh.
> > > >> I do NOT agree that we should change mechanisms tha= t have been widely
> > > >> deployed for many years now,
> > > >> without an extremely pressing reason.
> > > >>
> > > >> Were the proposal to be that for PWs that traverse = ONLY MPLS-TP to have the
> > > >> ADDITIONAL option
> > > >> for ACh marking, I might be convinced not to object= as strongly.
> > > >> However, since I don't think that PWs can be li= mited in this matter (the MPLS
> > > >> WG adopted the "seamless" draft)
> > > >> it would be difficult to convince me that such a li= mitation is possible.
> > > >>
> > > >> I would have enthusiastically support this proposal= had it been brought 8
> > > >> years ago.
> > > >> It's too late for this now.
> > > >>
> > > >> Y(J)S
> > > >>
> > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> > > >> Bocci, Matthew (Matthew)
> > > >> Sent: Thursday, July 28, 2011 21:02
> > > >> To: pwe3@ietf.org
> > > >> Subject: [PWE3] Poll for WG adoption of draft-nadea= u-pwe3-vccv-2-02.txt
> > > >>
> > > >> This email begins a two week poll to help assess if= there is consensus to
> > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 wor= king group draft.
> > > >>
> > > >> Please indicate whether or not you support adoption= of this draft, and also
> > > >> send any comments to the PWE3 list.
> > > >>
> > > >> This poll will end on Friday 12th August.
> > > >>
> > > >> Regards,
> > > >>
> > > >> Matthew & Andy
> > > >> This e-mail message is intended for the recipient o= nly 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 o= nly 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
ht= tps://www.ietf.org/mailman/listinfo/pwe3

--20cf300512c27ce87104a9b21491-- From jdrake@juniper.net Thu Aug 4 11:36: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 4F01911E808C for ; Thu, 4 Aug 2011 11:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.75 X-Spam-Level: X-Spam-Status: No, score=-5.75 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_91=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 9fXDSs9qfhII for ; Thu, 4 Aug 2011 11:36:54 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 368C511E8077 for ; Thu, 4 Aug 2011 11:36:52 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTjrmz88zZFV1QBAFe9xsRU8bL+tyBhzG@postini.com; Thu, 04 Aug 2011 11:37:09 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 4 Aug 2011 11:36:46 -0700 From: John E Drake To: Pablo Frank , "curtis@occnc.com" Date: Thu, 4 Aug 2011 11:36:43 -0700 Thread-Topic: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) Thread-Index: AcxS06lVrqqphcdUR2KkfxFwIDqc7wAAPGTg Message-ID: <5E893DB832F57341992548CDBB333163A0AC0CCDD1@EMBX01-HQ.jnpr.net> 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_5E893DB832F57341992548CDBB333163A0AC0CCDD1EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "yaakov_s@rad.com" , "pwe3@ietf.org" , "Robert.Rennison@ecitele.com" Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 18:36:56 -0000 --_000_5E893DB832F57341992548CDBB333163A0AC0CCDD1EMBX01HQjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pablo, At least wrt entropy label, the reasons why it needs to be at the bottom of= stack are detailed in the draft in some detail. The GAL is in exactly the= same place in the stack relative to the labels above it whether or not the= entropy label is used. The fact that the bottom of stack bit is not set i= n the GAL tells the egress that an entropy label is present in the stack af= ter it and needs to be discarded.l Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Pab= lo Frank Sent: Thursday, August 04, 2011 11:24 AM To: curtis@occnc.com Cc: yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitele.com Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) Curtis, Why does it matter if the entropy/flow labels are above or below the GAL? = What advantage is gained by putting such labels below the GAL? To me, putting the GAL in-between the PW (or LSP) label and the Flow (or En= tropy) label just feels out of place. I should only really care about a GA= L if I encounter it as a result of disposing of the labels either because t= hey've been popped or because the TTL has expired. When the PW label gets = terminated and all of a sudden, I encounter a GAL, it seems awkward because= in my mind, I have not finished terminating the PW layer. There is still = this flow label that I need to dispose of... so the hardware has to remembe= r that it saw a GAL and continue processing labels. It seems much cleaner = if we finish dealing with the multipath labels before considering whether i= t's carrying normal data or an associated channel. If anything, I see an advantage in having the GAL below the flow label beca= use it allows the option of monitoring individual paths (assuming, of cours= e, that GAL is excluded from the hash). regards, Pablo ----- Original Message ----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 06:38 AM To: Shahram Davari Cc: curtis@occnc.com >; Giles Heron >; Thomas Nadeau >; Yaakov Stein >; pwe3@ietf.o= rg >; Robert Renn= ison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.= broadcom.com> "Shahram Davari" writes: > > Hi Curtis, > > Even if we assume this format (which is not yet incorporated in the > fat-pw draft), then most hardware assume ACH is right after GAL. In > this case how is the HW supposed to examine the ACH channel Type to > decide how to process the packet? (unless you assume there is one > engine that can process all OAM packet types such as BFD, AIS, PSC, > LSP-ping, LDI, LKR, LM, DM, etc) > > Thx > Shahram Shahram, This doesn't need to go in the fat-pw draft. It needs to go into the draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic when some other feature, fat-pw or other, puts a label under the PW label. The GAL goes after the PW and before the other labels. A proper multipath distribution will skip any reserved label and use the rest of the label stack to load balance. This allows spraying across the entropy space or testing a spacific payload label stack that has yielded trouble. Hardware that assumes ACH is right after GAL when the S-bit is not set on the GAL is broken. The payload (ACH) is after the BOS (aka S-bit =3D 1). The IETF has never been sympathetic of broken hardware and should not be since we would halt progress. If the hardware is broken, then the fat-pw label can be omitted but only one path through any multipath would be tested. It would still work for TP, but not work in general. PW does not require TP. The fat-pw work is explicitly done for multipath because multipath is used a lot in deployed networks and isn't going away. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com<= mailto:curtis@occnc.com>] > Sent: Wednesday, August 03, 2011 4:53 PM > To: Shahram Davari > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau= ; Yaakov Stein; pwe3@ietf.org; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.a= d.broadcom.com> > "Shahram Davari" writes: > > > > Hi Curtis, > > > > You are absolutely correct if there is no Entropy label. But with > > Entropy label most implementation assume a Entropy label to be BoS and > > below the PW label. > > > > This draft doesn't even talk about whether the GAL should be BoS or > > the Entropy Label? In either case adding GAL would make the packet > > un-parsable by most HW. > > > > Thx > > Shahram > > > That should be covered in this work. At least it was covered in WG > email. PW, then GAL, then fat-pw (aka Flow label, which is different > from Entropy label in MPLS). > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GAL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... additional labels (ie: fat-pw) may be present | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|Version| Reserved | Associated Channel Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ VCCV Message Body ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The above would be a better choice. The VCCV is always after the > label entry with BOS (S-bit =3D 1). > > The flow label (or entropy label) must not be a reserved label. > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > 1.2 (page 5) you will find. > > Note that the flow label MUST NOT be an MPLS reserved label (values > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > protocol. > > > The flow label below GAL is needed so that all data paths which the PW > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.co= m] > > Sent: Wednesday, August 03, 2011 4:05 PM > > To: Shahram Davari > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp= .ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Giles, > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > Adding GAL to an MPLS label stack requires hardware support. The > > hardware need not know if the label above the GAL is an MPLS label or > > a PW label, just that the next label is GAL and the label over it is > > not a SWAP. Unless we are talking about incredibly inflexible parser > > hardware, like none I've encounted recently, there should be no > > problem noticing a GAL below the POP or PW label and then directing > > the packet to OAM processing. Any remaining labels must be removed > > and hopefully no implementation neglects to look for BOS before > > deciding where the payload is supposed to be. > > > > TTL is best reserved for traceroute only (in the MS-PW case). In this > > case TTL-expire would occur where a label swap was called for and a > > GAL would be below the label containing the expired TTL. Since LDP > > can have transient loops, this avoids having lots of packets sent to > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > This yield one way to do OAM with or without CW. A GAL label is below > > the label for which action is taken (POP or PW termination) or below a > > label for which TTL has expired. This method applied to LSP and PW. > > > > I think mandating CW would be just as good a solution, but one that > > was rejected so this is the best we have. > > > > Curtis > > > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > To: Thomas Nadeau; Shahram Davari > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Renniso= n > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-= 02.txt > > > > > > Agreed - some operators won't want to use a CW, and on that basis I s= upport > > > this draft. > > > > > > Sure, it'll take a while to move away from the router alert label and= TTL > > > approaches, but the GAL approach is definitely better than either of > > > those... > > > > > > Giles > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > wrote: > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > >> Hi, > > > >> > > > >> I also don=B9t support this draft since I don=B9t think to solve t= he problem we > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > While I am with you, that argument went out the window during the d= ebates we > > > > had over the past 3 IETF meetings. Operators > > > > were very clear that they do not want to mandate the use of a CW. = Hence, > > > > Luca and I came up with this solution that narrows the > > > > scope to 2 modes, one that handles the CW case and one that doesn't= while > > > > still both modes providing predictable OAM capabilities > > > > for the PW. > > > > > > > > --Tom > > > > > > > > > > > >> > > > >> Shahram > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:= pwe3-bounces@ietf.org] On Behalf Of > > > >> Robert Rennison > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > > > >> pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >> > > > >> I do Not support the draft, > > > >> > > > >> After hearing the results of the earlier user deployment poll I t= hought, > > > >> =B3 ok the way out of this mess is to migrate towards using the C= W=B2. Then I > > > >> see this proposal and wondered what am I missing. I=B9ve still no= t seen the > > > >> light of why adding a fourth type will simplify matters, hence in = the absence > > > >> of me understanding how this will simplify matter versus complicat= e things, > > > >> I=B9m against it. > > > >> > > > >> Rob > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:= pwe3-bounces@ietf.org] On Behalf Of > > > >> Alexander Vainshtein > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >> > > > >> Hi all, > > > >> I do NOT support this draft for the same reasons that Yaakov has i= ndicated. > > > >> > > > >> Regards, > > > >> Sasha > > > >> > > > >> From: pwe3-bounces@ietf.org [pwe3-bo= unces@ietf.org] On Behalf Of Yaakov Stein > > > >> [yaakov_s@rad.com] > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >> > > > >> I do not support ! and I can not understand how anyone can supp= ort it ! > > > >> > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > >> > > > >> I completely agree with the part that says if there is a CW then t= he ACh > > > >> should be marked by it. > > > >> > > > >> I do NOT agree that if the CW is not used then we should use a non= -PW method > > > >> developed for MPLS-TP. > > > >> I do NOT agree that there is any way to deprecate the use of TTL e= xpiry to > > > >> mark the ACh. > > > >> I do NOT agree that we should change mechanisms that have been wid= ely > > > >> deployed for many years now, > > > >> without an extremely pressing reason. > > > >> > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to= have the > > > >> ADDITIONAL option > > > >> for ACh marking, I might be convinced not to object as strongly. > > > >> However, since I don't think that PWs can be limited in this matte= r (the MPLS > > > >> WG adopted the "seamless" draft) > > > >> it would be difficult to convince me that such a limitation is pos= sible. > > > >> > > > >> I would have enthusiastically support this proposal had it been br= ought 8 > > > >> years ago. > > > >> It's too late for this now. > > > >> > > > >> Y(J)S > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:= pwe3-bounces@ietf.org] On Behalf Of > > > >> Bocci, Matthew (Matthew) > > > >> Sent: Thursday, July 28, 2011 21:02 > > > >> To: pwe3@ietf.org > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-0= 2.txt > > > >> > > > >> This email begins a two week poll to help assess if there is conse= nsus to > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draf= t. > > > >> > > > >> Please indicate whether or not you support adoption of this draft,= and also > > > >> send any comments to the PWE3 list. > > > >> > > > >> This poll will end on Friday 12th August. > > > >> > > > >> Regards, > > > >> > > > >> Matthew & Andy > > > >> This e-mail message is intended for the recipient only and contain= s > > > >> information which is CONFIDENTIAL and which may be proprietary to = ECI > > > >> Telecom. If you have received this transmission in error, please i= nform 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 contain= s > > > >> information which is CONFIDENTIAL and which may be proprietary to = ECI > > > >> Telecom. If you have received this transmission in error, please i= nform 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 --_000_5E893DB832F57341992548CDBB333163A0AC0CCDD1EMBX01HQjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Pablo,

 

=

At least wrt entropy label, the reasons why it = needs to be at the bottom of stack are detailed in the draft in some detail= .=A0 The GAL is in exactly the same place in the stack relative to the labe= ls above it whether or not the entropy label is used.=A0 The fact that the = bottom of stack bit is not set in the GAL tells the egress that an entropy = label is present in the stack after it and needs to be discarded.l=A0 =

 

Thanks,

 

John <= /o:p>

 

Sent from my iPhone

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] = On Behalf Of Pablo Frank
Sent: Thursday, August 04, 2011 11:2= 4 AM
To: curtis@occnc.com
Cc: yaakov_s@rad.com; pwe3@ie= tf.org; Robert.Rennison@ecitele.com
Subject: Re: [PWE3] Entropy/F= low and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt)

 

<= p class=3DMsoNormal>Curtis,

&n= bsp;

Why does it matter if the ent= ropy/flow labels are above or below the GAL?  What advantage is gained= by putting such labels below the GAL?

 

To me, putti= ng the GAL in-between the PW (or LSP) label and the Flow (or Entropy) label= just feels out of place.  I should only really care about a GAL if I = encounter it as a result of disposing of the labels either because they've = been popped or because the TTL has expired.  When the PW label gets te= rminated and all of a sudden, I encounter a GAL, it seems awkward because i= n my mind, I have not finished terminating the PW layer.  There is sti= ll this flow label that I need to dispose of... so the hardware has to reme= mber that it saw a GAL and continue processing labels.  It seems much = cleaner if we finish dealing with the multipath labels before considering w= hether it's carrying normal data or an associated channel.  

 

If anything, I see an advantage in having the GAL below the = flow label because it allows the option of monitoring individual paths (ass= uming, of course, that GAL is excluded from the hash).

=

 

regards,

Pablo=

 

----- Original = Message -----
From: Curtis Villamizar [mailto:curtis@occnc.com]
Sent: Thursday, August= 04, 2011 06:38 AM
To: Shahram Davari
Cc: curtis@occnc.com <curtis@occnc.com>; Giles Heron <giles.heron@gmail.= com>; Thomas Nadeau <tnadeau@lucidvision.com>; Yaakov Stein <yaakov_s@rad.com>; pwe3@ietf.org <pwe3@ietf.org>; Rober= t Rennison <Robert.Rennison@ecitele.com>
Subject: Re: [PWE3] Poll for WG= adoption of draft-nadeau-pwe3-vccv-2-02.txt


In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12= A@SJEXCHCCR02.corp.ad.broadcom.com>
"Shahram Davari" wr= ites:
>
> Hi Curtis,
>
> Even if we assume this for= mat (which is not yet incorporated in the
> fat-pw draft), then most = hardware assume ACH is right after GAL. In
> this case how is the HW = supposed to examine the ACH channel Type to
> decide how to process t= he packet? (unless you assume there is one
> engine that can process = all OAM packet types such as BFD, AIS, PSC,
> LSP-ping, LDI, LKR, LM,= DM, etc)
>
> Thx
> Shahram


Shahram,

Th= is doesn't need to go in the fat-pw draft.  It needs to go into thedraft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic
w= hen some other feature, fat-pw or other, puts a label under the PW
label= .  The GAL goes after the PW and before the other labels.  A
p= roper multipath distribution will skip any reserved label and use the
re= st of the label stack to load balance.  This allows spraying acrossthe entropy space or testing a spacific payload label stack that has
yi= elded trouble.

Hardware that assumes ACH is right after GAL when the= S-bit is not set
on the GAL is broken.

The payload (ACH) is afte= r the BOS (aka S-bit =3D 1).

The IETF has never been sympathetic of = broken hardware and should not
be since we would halt progress.

I= f the hardware is broken, then the fat-pw label can be omitted but
only = one path through any multipath would be tested.  It would still
wor= k for TP, but not work in general.  PW does not require TP.  The<= br>fat-pw work is explicitly done for multipath because multipath is useda lot in deployed networks and isn't going away.

Curtis

> -----Original Message-----
> From: curtis@occnc.com [mailto:curtis@occnc.com]
> Sent: Wedne= sday, August 03, 2011 4:53 PM
> To: Shahram Davari
> Cc: curtis@occnc.com; Giles= Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison
> Subject: Re: [PWE3]= Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
>
>> In message <2C2F1EBA8050E74E= A81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com>
>= "Shahram Davari" writes:
> >
> > Hi Curtis,> >
> > You are absolutely correct if there is no Entropy l= abel. But with
> > Entropy label most implementation assume a Entr= opy label to be BoS and
> > below the PW label.
> >
&g= t; > This draft doesn't even talk about whether the GAL should be BoS or=
> > the Entropy Label? In either case adding GAL would make the p= acket
> > un-parsable by most HW.
> >
> > Thx> > Shahram
>
>
> That should be covered in this w= ork.  At least it was covered in WG
> email.  PW, then GAL,= then fat-pw (aka Flow label, which is different
> from Entropy label= in MPLS).
>
> 0             &nbs= p;     1                 =   2                   3> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
&= gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&g= t; |                     =        PW Label           &nbs= p;               |
> +-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |    = ;                     &nb= sp;    GAL                = ;              |
> +-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |     = ... additional labels (ie: fat-pw) may be present       &nbs= p; |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
> |0 0 0 1|Version|   Reserved    |  Associat= ed Channel Type      |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |         =                      = ;                     &nb= sp;           |
> ~       &nb= sp;                VCCV Message Bod= y                     &nb= sp;~
> |                 &nbs= p;                     &n= bsp;                     =   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
>
> The above would be a better choice.  The VCCV = is always after the
> label entry with BOS (S-bit =3D 1).
>
= > The flow label (or entropy label) must not be a reserved label.
>= ; Therefore there is no ambiguity.  In draft-ietf-pwe3-fat-pw-07 secti= on
> 1.2 (page 5) you will find.
>
>    Note th= at the flow label MUST NOT be an MPLS reserved label (values
>  =  in the range 0..15) [RFC3032], but is otherwise unconstrained by the=
>    protocol.
>
>
> The flow label belo= w GAL is needed so that all data paths which the PW
> can take are ex= ercised by OAM (ie: LSP Ping used within VCCV).
>
> Curtis
&= gt;
>
> > -----Original Message-----
> > From: curtis@occnc.com [mai= lto:curtis@occnc.com<= /a>]
> > Sent: Wednesday, August 03, 2011 4:05 PM
> > To:= Shahram Davari
> > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; = pwe3@ietf.org; Rober= t Rennison
> > Subject: Re: [PWE3] Poll for WG adoption of draft-n= adeau-pwe3-vccv-2-02.txt
> >
> >
> > In message = <2C2F1EBA8050E74EA81502D5740B4BD6A= 93275EF50@SJEXCHCCR02.corp.ad.broadcom.com>
> > "Shahr= am Davari" writes:
> > >
> > > Giles,
> = > >
> > > Adding GAL to PW requires HW change, so why not= just add CW and use
> > > VVCV Type 1?  Also what is wron= g with TTL approach for non-CW?
> > >
> > > Thx
= > > > Shahram
> >
> >
> > Shahram,
&= gt; >
> > Adding GAL to an MPLS label stack requires hardware s= upport.  The
> > hardware need not know if the label above th= e GAL is an MPLS label or
> > a PW label, just that the next label= is GAL and the label over it is
> > not a SWAP.  Unless we a= re talking about incredibly inflexible parser
> > hardware, like n= one I've encounted recently, there should be no
> > problem notici= ng a GAL below the POP or PW label and then directing
> > the pack= et to OAM processing.  Any remaining labels must be removed
> &g= t; and hopefully no implementation neglects to look for BOS before
> = > deciding where the payload is supposed to be.
> >
> >= ; TTL is best reserved for traceroute only (in the MS-PW case).  In th= is
> > case TTL-expire would occur where a label swap was called f= or and a
> > GAL would be below the label containing the expired T= TL.  Since LDP
> > can have transient loops, this avoids havi= ng lots of packets sent to
> > the OAM engine should such a loop o= ccur in a LDP signaled MPLS PSN.
> >
> > This yield one w= ay to do OAM with or without CW.  A GAL label is below
> > th= e label for which action is taken (POP or PW termination) or below a
>= ; > label for which TTL has expired.  This method applied to LSP an= d PW.
> >
> > I think mandating CW would be just as good = a solution, but one that
> > was rejected so this is the best we h= ave.
> >
> > Curtis
> >
> >
> >= ; > -----Original Message-----
> > > From: Giles Heron [mail= to:giles.heron@g= mail.com]
> > > Sent: Wednesday, August 03, 2011 11:10 AM> > > To: Thomas Nadeau; Shahram Davari
> > > Cc: pwe3@ietf.org; Yaakov = Stein; Robert Rennison
> > > Subject: Re: [PWE3] Poll for WG ad= option of draft-nadeau-pwe3-vccv-2-02.txt
> > >
> > &g= t; Agreed - some operators won't want to use a CW, and on that basis I supp= ort
> > > this draft.
> > >
> > > Sure,= it'll take a while to move away from the router alert label and TTL
>= ; > > approaches, but the GAL approach is definitely better than eith= er of
> > > those...
> > >
> > > Giles<= br>> > >
> > > On 02/08/2011 12:59, "Thomas Nadea= u" <tn= adeau@lucidvision.com> wrote:
> > >
> > > &g= t;
> > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote:=
> > > >
> > > >> Hi,
> > > &g= t;>
> > > >> I also don=B9t support this draft since I= don=B9t think to solve the problem we
> > > >> need yet = a 4th type of VCCV. The best solution is to mandate CW.
> > > &= gt;
> > > > While I am with you, that argument went out the = window during the debates we
> > > > had over the past 3 IET= F meetings. Operators
> > > > were very clear that they do n= ot want to mandate the use of a CW.   Hence,
> > > > Lu= ca and I came up with this solution that narrows the
> > > >= scope to 2 modes, one that handles the CW case and one that doesn't while<= br>> > > > still both modes providing predictable OAM capabilit= ies
> > > > for the PW.
> > > >
> > = > > --Tom
> > > >
> > > >
> > = > >>
> > > >> Shahram
> > > >>=
> > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of=
> > > >> Robert Rennison
> > > >> Sent= : Sunday, July 31, 2011 7:40 PM
> > > >> To: Alexander Va= inshtein; Yaakov Stein; Bocci, Matthew (Matthew);
> > > >>= ; pwe3@ietf.org
&= gt; > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-na= deau-pwe3-vccv-2-02.txt
> > > >>
> > > >&g= t; I do Not support the draft,
> > > >>
> > >= >> After hearing the results of the earlier user deployment  po= ll I thought,
> > > >> =B3 ok  the way out of this m= ess is to migrate towards using the CW=B2. Then I
> > > >>= ; see this proposal and wondered what am I missing.  I=B9ve still not = seen the
> > > >> light of why adding a fourth type will = simplify matters, hence in the absence
> > > >> of me und= erstanding how this will simplify matter versus complicate things,
> = > > >> I=B9m against it.
> > > >>
> >= ; > >> Rob
> > > >>
> > > >> F= rom: pwe3-bounce= s@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> > > >> A= lexander Vainshtein
> > > >> Sent: Sunday, July 31, 2011 = 12:45 AM
> > > >> To: Yaakov Stein; Bocci, Matthew (Matth= ew); pwe3@ietf.org> > > >> Subject: Re: [PWE3] Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt
> > > >>
> > > >= ;> Hi all,
> > > >> I do NOT support this draft for th= e same reasons that Yaakov has indicated.
> > > >>
>= ; > > >> Regards,
> > > >>     &nbs= p;Sasha
> > > >>
> > > >> From: pwe3-bounces@ietf.org [pwe3-bounces= @ietf.org] On Behalf Of Yaakov Stein
> > > >> [yaakov_s@rad.com]
&g= t; > > >> Sent: Friday, July 29, 2011 3:58 AM
> > >= >> To: Bocci, Matthew (Matthew); pwe3@ietf.org
> > > >> Subject: Re: [= PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
> > = > >>
> > > >> I do not support !    an= d I can not understand how anyone can support it !
> > > >&g= t;
> > > >> We do NOT need a fourth VCCV type, there are = too many already.
> > > >>
> > > >> I c= ompletely agree with the part that says if there is a CW then the ACh
&g= t; > > >> should be marked by it.
> > > >>> > > >> I do NOT agree that if the CW is not used then we = should use a non-PW method
> > > >> developed for MPLS-TP= .
> > > >> I do NOT agree that there is any way to deprec= ate the use of TTL expiry to
> > > >> mark the ACh.
&g= t; > > >> I do NOT agree that we should change mechanisms that = have been widely
> > > >> deployed for many years now,> > > >> without an extremely pressing reason.
> >= > >>
> > > >> Were the proposal to be that for = PWs that traverse ONLY MPLS-TP to have the
> > > >> ADDIT= IONAL option
> > > >> for ACh marking, I might be convinc= ed not to object as strongly.
> > > >> However, since I d= on't think that PWs can be limited in this matter (the MPLS
> > &g= t; >> WG adopted the "seamless" draft)
> > > &g= t;> it would be difficult to convince me that such a limitation is possi= ble.
> > > >>
> > > >> I would have ent= husiastically support this proposal had it been brought 8
> > >= >> years ago.
> > > >> It's too late for this now.=
> > > >>
> > > >> Y(J)S
> > &= gt; >>
> > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] = On Behalf Of
> > > >> Bocci, Matthew (Matthew)
> &g= t; > >> Sent: Thursday, July 28, 2011 21:02
> > > >= > To: pwe3@ietf.org
> > > >> Subject: [PWE3] Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt
> > > >>
> > > >= ;> This email begins a two week poll to help assess if there is consensu= s to
> > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a = PWE3 working group draft.
> > > >>
> > > >= > Please indicate whether or not you support adoption of this draft, and= also
> > > >> send any comments to the PWE3 list.
>= ; > > >>
> > > >> This poll will end on Frida= y 12th August.
> > > >>
> > > >> Regard= s,
> > > >>
> > > >> Matthew & Andy=
> > > >> This e-mail message is intended for the recipie= nt only and contains
> > > >> information which is CONFID= ENTIAL and which may be proprietary to ECI
> > > >> Telec= om. 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
> > > >> inf= ormation 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/ma= ilman/listinfo/pwe3

 

= --_000_5E893DB832F57341992548CDBB333163A0AC0CCDD1EMBX01HQjnprn_-- From jdrake@juniper.net Thu Aug 4 11:38: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 F098D11E808C for ; Thu, 4 Aug 2011 11:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.053 X-Spam-Level: X-Spam-Status: No, score=-6.053 tagged_above=-999 required=5 tests=[AWL=0.546, 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 MGEUepUzhQ94 for ; Thu, 4 Aug 2011 11:38:02 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4F18111E809B for ; Thu, 4 Aug 2011 11:38:00 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTjrnEzRTd6Lg2t5ZcIB9kuhu6hvvOp1p@postini.com; Thu, 04 Aug 2011 11:38:17 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 4 Aug 2011 11:38:00 -0700 From: John E Drake To: Shahram Davari , "curtis@occnc.com" Date: Thu, 4 Aug 2011 11:37:58 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSyeL4keOJqv44SQW5wgy/thjRDQABWHpAAABpfEAAAGeMkA== Message-ID: <5E893DB832F57341992548CDBB333163A0AC0CCDDA@EMBX01-HQ.jnpr.net> References: Your message of "Thu, 04 Aug 2011 07:42:21 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> <201108041712.p74HCMCH057629@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB333163A0AC0CCCE1@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93275F652@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F652@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 18:38:04 -0000 Shahram, That is the date at which it became a *working group draft*. The point tha= t Curtis made, and with which I was agreeing, was that moving the GAL from = the bottom of the stack in support of ECMP has been the direction taken by = both MPLS and PWE3 for at least a year. John Sent from my iPhone > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Thursday, August 04, 2011 11:10 AM > To: John E Drake; curtis@occnc.com > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > John, > > If your point is that this is mentioned in an IETF draft then please > look at the date of the draft as well (May 5 2011). Also this draft > applies only to MPLS tunnels and not PW. I hope you don't expect people > to implement an IETF draft-00 which was published just 3 months ago. > > -Shahram > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, August 04, 2011 10:56 AM > To: curtis@occnc.com; Shahram Davari > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > From Section 6 of the Entropy Label I-D > (http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy- > label/?include_text=3D1): > > "As part of the MPLS-TP work, an in-band OAM channel is defined in > [RFC5586]. Packets sent in this channel are identified with a reserved > label, the Generic Associated Channel Label (GAL) placed at the bottom > of the MPLS label stack. In order to use the inband OAM channel with > entropy labels, this memo relaxes the restriction that the GAL must be > at the bottom of the MPLS label stack. Rather, the GAL is placed in > the MPLS label stack above the entropy label so that it effectively > functions as an application label." > > Sent from my iPhone > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of > > Curtis Villamizar > > Sent: Thursday, August 04, 2011 10:12 AM > > To: Shahram Davari > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > 'Robert.Rennison@ecitele.com' > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > > > In message > > > <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadco > > m.com> > > "Shahram Davari" writes: > > > > > > I don't agree with you. This is not about broken HW. Before this > > draft > > > how was one supposed to process a packet with GAL in the middle of > > the > > > label stack? > > > > Before this draft one had to read the MPLS and PWE3 mailing list and > > remember what was said. Getting it written in a draft is the next > > step. > > > > Some of the most purist of the MPLS-TP folks have done a good job of > > shouting down any suggestion that multipath had a valid place in any > > network for quite some time. > > > > > What if this draft had decided to put GAL after entropy? Then the > HW > > > processing would have been completely different from what you are > > > proposing on the fly now. > > > > Putting labels under GAL for the purpose of entropy was proposed on > > MPLS mailing list for well over a year now, probably close to two > > years, more recently on PWE3. It is reflected in other internet- > > drafts, For example, draft-villamizar-mpls-tp-multipath-00 > > was submitted before Maastricht but fell off the end of the agenda. > > > > It is also in a document that we have been giving to chip vendors > under > > NDA stating detailed requirements starting just under a year ago. > > Before that is was more verbal discussion of requirements and email. > > Your friends in another part of your company were eliminated from > > consideration for other reasons a while back but have heard this > > requirement verbally at least. > > > > > You are making imaginary assumptions that HW should be able to > > process > > > what was in your mind. > > > > That is presumptious on your part. Actually we have given this > > requirement to chip vendors in our product space for about a year and > a > > half and I have brought this up for even longer in the MPLS WG and > more > > recently on PWE3. Two chip vendors have taken these requirements to > > heart and will be allowing labels under GAL plus the forwarding > > functionality described in draft-villamizar-mpls-tp-multipath-01. > > > > Of all the packet processors that we have considered, all on the very > > high end of things, I know of none that have a parser that is so > > inflexible that it could not deal with a label under GAL and still > find > > the OAM payload with nothing more than a change to the low level > > programming of the parser. > > > > I can envision that chips do exist for which the parser is too hard > > coded to accommodate such a change. Lucky for us (not luck really) > > that we are not working with such a chip. Are you? > > > > > I strongly object to this unnecessary draft. If you look at RFCs > > there > > > are always cases that we wished we had done it differently, but we > > are > > > not going to change them since in most cases like this one it is > too > > > late. Sorry but that is the fact. > > > > We are implementing labels under GAL for non-TP OAM in our products > > regardless of your objections. If a provider wants to use it, it > will > > be there. If it can also be used for PW, all the better. Its really > > easy to do, so it doesn't hurt to do it. > > > > If a provider prefers to use CW all the time, I'm fine with that but > we > > still need labels under GAL for non-TP MPLS OAM. > > > > > Thx > > > Shahram > > > > Curtis > > > > > > > ----- Original Message ----- > > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > > Sent: Thursday, August 04, 2011 06:38 AM > > > To: Shahram Davari > > > Cc: curtis@occnc.com ; Giles Heron > > > ; Thomas Nadeau ; > > > Yaakov Stein ; pwe3@ietf.org ; > > Robert > > > Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadc > > > om.com> > > > "Shahram Davari" writes: > > > > > > > > Hi Curtis, > > > > > > > > Even if we assume this format (which is not yet incorporated in > the > > > > fat-pw draft), then most hardware assume ACH is right after GAL. > In > > > > this case how is the HW supposed to examine the ACH channel Type > to > > > > decide how to process the packet? (unless you assume there is one > > > > engine that can process all OAM packet types such as BFD, AIS, > PSC, > > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > > > Thx > > > > Shahram > > > > > > > > > Shahram, > > > > > > This doesn't need to go in the fat-pw draft. It needs to go into > the > > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM > traffic > > > when some other feature, fat-pw or other, puts a label under the PW > > > label. The GAL goes after the PW and before the other labels. A > > > proper multipath distribution will skip any reserved label and use > > the > > > rest of the label stack to load balance. This allows spraying > across > > > the entropy space or testing a spacific payload label stack that > has > > > yielded trouble. > > > > > > Hardware that assumes ACH is right after GAL when the S-bit is not > > set > > > on the GAL is broken. > > > > > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > > > > > The IETF has never been sympathetic of broken hardware and should > not > > > be since we would halt progress. > > > > > > If the hardware is broken, then the fat-pw label can be omitted but > > > only one path through any multipath would be tested. It would > still > > > work for TP, but not work in general. PW does not require TP. The > > > fat-pw work is explicitly done for multipath because multipath is > > used > > > a lot in deployed networks and isn't going away. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > > To: Shahram Davari > > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > > > > pwe3@ietf.org; Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > In message > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa > > > > dcom.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Hi Curtis, > > > > > > > > > > You are absolutely correct if there is no Entropy label. But > with > > > > > Entropy label most implementation assume a Entropy label to be > > BoS > > > > > and below the PW label. > > > > > > > > > > This draft doesn't even talk about whether the GAL should be > BoS > > > > > or the Entropy Label? In either case adding GAL would make the > > > > > packet un-parsable by most HW. > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > That should be covered in this work. At least it was covered in > WG > > > > email. PW, then GAL, then fat-pw (aka Flow label, which is > > > > different from Entropy label in MPLS). > > > > > > > > 0 1 2 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | PW Label | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | GAL | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | ... additional labels (ie: fat-pw) may be present | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | | > > > > ~ VCCV Message Body ~ > > > > | | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > The above would be a better choice. The VCCV is always after the > > > > label entry with BOS (S-bit =3D 1). > > > > > > > > The flow label (or entropy label) must not be a reserved label. > > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 > > > > section > > > > 1.2 (page 5) you will find. > > > > > > > > Note that the flow label MUST NOT be an MPLS reserved label > > (values > > > > in the range 0..15) [RFC3032], but is otherwise unconstrained > by > > the > > > > protocol. > > > > > > > > > > > > The flow label below GAL is needed so that all data paths which > the > > > > PW can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > > To: Shahram Davari > > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; > > > > > Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > In message > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.br > > > > > oadcom.com> > > > > > "Shahram Davari" writes: > > > > > > > > > > > > Giles, > > > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW > and > > > > > > use VVCV Type 1? Also what is wrong with TTL approach for > non- > > CW? > > > > > > > > > > > > Thx > > > > > > Shahram > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. > The > > > > > hardware need not know if the label above the GAL is an MPLS > > label > > > > > or a PW label, just that the next label is GAL and the label > over > > > > > it is not a SWAP. Unless we are talking about incredibly > > > > > inflexible parser hardware, like none I've encounted recently, > > > > > there should be no problem noticing a GAL below the POP or PW > > > > > label and then directing the packet to OAM processing. Any > > > > > remaining labels must be removed and hopefully no > implementation > > > > > neglects to look for BOS before deciding where the payload is > > supposed to be. > > > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). > In > > > > > this case TTL-expire would occur where a label swap was called > > for > > > > > and a GAL would be below the label containing the expired TTL. > > > > > Since LDP can have transient loops, this avoids having lots of > > > > > packets sent to the OAM engine should such a loop occur in a > LDP > > signaled MPLS PSN. > > > > > > > > > > This yield one way to do OAM with or without CW. A GAL label > is > > > > > below the label for which action is taken (POP or PW > termination) > > > > > or below a label for which TTL has expired. This method > applied > > to LSP and PW. > > > > > > > > > > I think mandating CW would be just as good a solution, but one > > > > > that was rejected so this is the best we have. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > > To: Thomas Nadeau; Shahram Davari > > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that > > > > > > basis I support this draft. > > > > > > > > > > > > Sure, it'll take a while to move away from the router alert > > > > > > label and TTL approaches, but the GAL approach is definitely > > > > > > better than either of those... > > > > > > > > > > > > Giles > > > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > > > wrote: > > > > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > > > >> Hi, > > > > > > >> > > > > > > >> I also don=B9t support this draft since I don=B9t think to > solve > > > > > > >> the problem we need yet a 4th type of VCCV. The best > > solution is to mandate CW. > > > > > > > > > > > > > > While I am with you, that argument went out the window > during > > > > > > > the debates we had over the past 3 IETF meetings. Operators > > > > > > > were very clear that they do not want to mandate the use of > a > > CW. Hence, > > > > > > > Luca and I came up with this solution that narrows the > scope > > > > > > > to 2 modes, one that handles the CW case and one that > doesn't > > > > > > > while still both modes providing predictable OAM > capabilities > > > > > > > for the PW. > > > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > >> > > > > > > >> Shahram > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > On > > > > > > >> Behalf Of Robert Rennison > > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew > > > > > > >> (Matthew); pwe3@ietf.org > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> I do Not support the draft, > > > > > > >> > > > > > > >> After hearing the results of the earlier user deployment > > > > > > >> poll I thought, =B3 ok the way out of this mess is to > migrate > > > > > > >> towards using the CW=B2. Then I see this proposal and > wondered > > > > > > >> what am I missing. I=B9ve still not seen the light of why > > > > > > >> adding a fourth type will simplify matters, hence in the > > > > > > >> absence of me understanding how this will simplify matter > > versus complicate things, I=B9m against it. > > > > > > >> > > > > > > >> Rob > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > On > > > > > > >> Behalf Of Alexander Vainshtein > > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> Hi all, > > > > > > >> I do NOT support this draft for the same reasons that > Yaakov > > has indicated. > > > > > > >> > > > > > > >> Regards, > > > > > > >> Sasha > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On > > Behalf > > > > > > >> Of Yaakov Stein [yaakov_s@rad.com] > > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> I do not support ! and I can not understand how anyone > > can support it ! > > > > > > >> > > > > > > >> We do NOT need a fourth VCCV type, there are too many > > already. > > > > > > >> > > > > > > >> I completely agree with the part that says if there is a > CW > > > > > > >> then the ACh should be marked by it. > > > > > > >> > > > > > > >> I do NOT agree that if the CW is not used then we should > use > > > > > > >> a non-PW method developed for MPLS-TP. > > > > > > >> I do NOT agree that there is any way to deprecate the use > of > > > > > > >> TTL expiry to mark the ACh. > > > > > > >> I do NOT agree that we should change mechanisms that have > > > > > > >> been widely deployed for many years now, without an > > extremely > > > > > > >> pressing reason. > > > > > > >> > > > > > > >> Were the proposal to be that for PWs that traverse ONLY > > > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, I > > > > > > >> might be convinced not to object as strongly. > > > > > > >> However, since I don't think that PWs can be limited in > this > > > > > > >> matter (the MPLS WG adopted the "seamless" draft) it would > > be > > > > > > >> difficult to convince me that such a limitation is > possible. > > > > > > >> > > > > > > >> I would have enthusiastically support this proposal had it > > > > > > >> been brought 8 years ago. > > > > > > >> It's too late for this now. > > > > > > >> > > > > > > >> Y(J)S > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > On > > > > > > >> Behalf Of Bocci, Matthew (Matthew) > > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > > >> To: pwe3@ietf.org > > > > > > >> Subject: [PWE3] Poll for WG adoption of > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> This email begins a two week poll to help assess if there > is > > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a > PWE3 > > working group draft. > > > > > > >> > > > > > > >> Please indicate whether or not you support adoption of > this > > > > > > >> draft, and also send any comments to the PWE3 list. > > > > > > >> > > > > > > >> This poll will end on Friday 12th August. > > > > > > >> > > > > > > >> Regards, > > > > > > >> > > > > > > >> Matthew & Andy > > > > > > >> 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. > From davari@broadcom.com Thu Aug 4 11:44: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 C404C21F8784 for ; Thu, 4 Aug 2011 11:44:46 -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.000, 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 TPfL5ljUrqNn for ; Thu, 4 Aug 2011 11:44:45 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 00DE621F87AF for ; Thu, 4 Aug 2011 11:44:44 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 04 Aug 2011 11:49:06 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 4 Aug 2011 11:43:48 -0700 From: "Shahram Davari" To: "John E Drake" , "curtis@occnc.com" Date: Thu, 4 Aug 2011 11:43:47 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSyeL4keOJqv44SQW5wgy/thjRDQABWHpAAABpfEAAAGeMkAAA3g+w Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F6B4@SJEXCHCCR02.corp.ad.broadcom.com> References: Your message of "Thu, 04 Aug 2011 07:42:21 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> <201108041712.p74HCMCH057629@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB333163A0AC0CCCE1@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93275F652@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB333163A0AC0CCDDA@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0AC0CCDDA@EMBX01-HQ.jnpr.net> 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: 622436283W41569789-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 18:44:46 -0000 Hi, I don't remember such direction and directions should be documented in stab= le IETF draft and RFCs. And in fact I think that direction is not correct. = I think GAL should be at the bottom of the stack so I like to challenge thi= s draft as well. Thx Shahram -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, August 04, 2011 11:38 AM To: Shahram Davari; curtis@occnc.com Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Shahram, That is the date at which it became a *working group draft*. The point tha= t Curtis made, and with which I was agreeing, was that moving the GAL from = the bottom of the stack in support of ECMP has been the direction taken by = both MPLS and PWE3 for at least a year. John Sent from my iPhone > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Thursday, August 04, 2011 11:10 AM > To: John E Drake; curtis@occnc.com > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > John, > > If your point is that this is mentioned in an IETF draft then please > look at the date of the draft as well (May 5 2011). Also this draft > applies only to MPLS tunnels and not PW. I hope you don't expect people > to implement an IETF draft-00 which was published just 3 months ago. > > -Shahram > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, August 04, 2011 10:56 AM > To: curtis@occnc.com; Shahram Davari > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > From Section 6 of the Entropy Label I-D > (http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy- > label/?include_text=3D1): > > "As part of the MPLS-TP work, an in-band OAM channel is defined in > [RFC5586]. Packets sent in this channel are identified with a reserved > label, the Generic Associated Channel Label (GAL) placed at the bottom > of the MPLS label stack. In order to use the inband OAM channel with > entropy labels, this memo relaxes the restriction that the GAL must be > at the bottom of the MPLS label stack. Rather, the GAL is placed in > the MPLS label stack above the entropy label so that it effectively > functions as an application label." > > Sent from my iPhone > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of > > Curtis Villamizar > > Sent: Thursday, August 04, 2011 10:12 AM > > To: Shahram Davari > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > 'Robert.Rennison@ecitele.com' > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > > > In message > > > <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadco > > m.com> > > "Shahram Davari" writes: > > > > > > I don't agree with you. This is not about broken HW. Before this > > draft > > > how was one supposed to process a packet with GAL in the middle of > > the > > > label stack? > > > > Before this draft one had to read the MPLS and PWE3 mailing list and > > remember what was said. Getting it written in a draft is the next > > step. > > > > Some of the most purist of the MPLS-TP folks have done a good job of > > shouting down any suggestion that multipath had a valid place in any > > network for quite some time. > > > > > What if this draft had decided to put GAL after entropy? Then the > HW > > > processing would have been completely different from what you are > > > proposing on the fly now. > > > > Putting labels under GAL for the purpose of entropy was proposed on > > MPLS mailing list for well over a year now, probably close to two > > years, more recently on PWE3. It is reflected in other internet- > > drafts, For example, draft-villamizar-mpls-tp-multipath-00 > > was submitted before Maastricht but fell off the end of the agenda. > > > > It is also in a document that we have been giving to chip vendors > under > > NDA stating detailed requirements starting just under a year ago. > > Before that is was more verbal discussion of requirements and email. > > Your friends in another part of your company were eliminated from > > consideration for other reasons a while back but have heard this > > requirement verbally at least. > > > > > You are making imaginary assumptions that HW should be able to > > process > > > what was in your mind. > > > > That is presumptious on your part. Actually we have given this > > requirement to chip vendors in our product space for about a year and > a > > half and I have brought this up for even longer in the MPLS WG and > more > > recently on PWE3. Two chip vendors have taken these requirements to > > heart and will be allowing labels under GAL plus the forwarding > > functionality described in draft-villamizar-mpls-tp-multipath-01. > > > > Of all the packet processors that we have considered, all on the very > > high end of things, I know of none that have a parser that is so > > inflexible that it could not deal with a label under GAL and still > find > > the OAM payload with nothing more than a change to the low level > > programming of the parser. > > > > I can envision that chips do exist for which the parser is too hard > > coded to accommodate such a change. Lucky for us (not luck really) > > that we are not working with such a chip. Are you? > > > > > I strongly object to this unnecessary draft. If you look at RFCs > > there > > > are always cases that we wished we had done it differently, but we > > are > > > not going to change them since in most cases like this one it is > too > > > late. Sorry but that is the fact. > > > > We are implementing labels under GAL for non-TP OAM in our products > > regardless of your objections. If a provider wants to use it, it > will > > be there. If it can also be used for PW, all the better. Its really > > easy to do, so it doesn't hurt to do it. > > > > If a provider prefers to use CW all the time, I'm fine with that but > we > > still need labels under GAL for non-TP MPLS OAM. > > > > > Thx > > > Shahram > > > > Curtis > > > > > > > ----- Original Message ----- > > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > > Sent: Thursday, August 04, 2011 06:38 AM > > > To: Shahram Davari > > > Cc: curtis@occnc.com ; Giles Heron > > > ; Thomas Nadeau ; > > > Yaakov Stein ; pwe3@ietf.org ; > > Robert > > > Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadc > > > om.com> > > > "Shahram Davari" writes: > > > > > > > > Hi Curtis, > > > > > > > > Even if we assume this format (which is not yet incorporated in > the > > > > fat-pw draft), then most hardware assume ACH is right after GAL. > In > > > > this case how is the HW supposed to examine the ACH channel Type > to > > > > decide how to process the packet? (unless you assume there is one > > > > engine that can process all OAM packet types such as BFD, AIS, > PSC, > > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > > > Thx > > > > Shahram > > > > > > > > > Shahram, > > > > > > This doesn't need to go in the fat-pw draft. It needs to go into > the > > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM > traffic > > > when some other feature, fat-pw or other, puts a label under the PW > > > label. The GAL goes after the PW and before the other labels. A > > > proper multipath distribution will skip any reserved label and use > > the > > > rest of the label stack to load balance. This allows spraying > across > > > the entropy space or testing a spacific payload label stack that > has > > > yielded trouble. > > > > > > Hardware that assumes ACH is right after GAL when the S-bit is not > > set > > > on the GAL is broken. > > > > > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > > > > > The IETF has never been sympathetic of broken hardware and should > not > > > be since we would halt progress. > > > > > > If the hardware is broken, then the fat-pw label can be omitted but > > > only one path through any multipath would be tested. It would > still > > > work for TP, but not work in general. PW does not require TP. The > > > fat-pw work is explicitly done for multipath because multipath is > > used > > > a lot in deployed networks and isn't going away. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > > To: Shahram Davari > > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > > > > pwe3@ietf.org; Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > In message > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa > > > > dcom.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Hi Curtis, > > > > > > > > > > You are absolutely correct if there is no Entropy label. But > with > > > > > Entropy label most implementation assume a Entropy label to be > > BoS > > > > > and below the PW label. > > > > > > > > > > This draft doesn't even talk about whether the GAL should be > BoS > > > > > or the Entropy Label? In either case adding GAL would make the > > > > > packet un-parsable by most HW. > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > That should be covered in this work. At least it was covered in > WG > > > > email. PW, then GAL, then fat-pw (aka Flow label, which is > > > > different from Entropy label in MPLS). > > > > > > > > 0 1 2 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | PW Label | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | GAL | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | ... additional labels (ie: fat-pw) may be present | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | | > > > > ~ VCCV Message Body ~ > > > > | | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > The above would be a better choice. The VCCV is always after the > > > > label entry with BOS (S-bit =3D 1). > > > > > > > > The flow label (or entropy label) must not be a reserved label. > > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 > > > > section > > > > 1.2 (page 5) you will find. > > > > > > > > Note that the flow label MUST NOT be an MPLS reserved label > > (values > > > > in the range 0..15) [RFC3032], but is otherwise unconstrained > by > > the > > > > protocol. > > > > > > > > > > > > The flow label below GAL is needed so that all data paths which > the > > > > PW can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > > To: Shahram Davari > > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; > > > > > Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > In message > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.br > > > > > oadcom.com> > > > > > "Shahram Davari" writes: > > > > > > > > > > > > Giles, > > > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW > and > > > > > > use VVCV Type 1? Also what is wrong with TTL approach for > non- > > CW? > > > > > > > > > > > > Thx > > > > > > Shahram > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. > The > > > > > hardware need not know if the label above the GAL is an MPLS > > label > > > > > or a PW label, just that the next label is GAL and the label > over > > > > > it is not a SWAP. Unless we are talking about incredibly > > > > > inflexible parser hardware, like none I've encounted recently, > > > > > there should be no problem noticing a GAL below the POP or PW > > > > > label and then directing the packet to OAM processing. Any > > > > > remaining labels must be removed and hopefully no > implementation > > > > > neglects to look for BOS before deciding where the payload is > > supposed to be. > > > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). > In > > > > > this case TTL-expire would occur where a label swap was called > > for > > > > > and a GAL would be below the label containing the expired TTL. > > > > > Since LDP can have transient loops, this avoids having lots of > > > > > packets sent to the OAM engine should such a loop occur in a > LDP > > signaled MPLS PSN. > > > > > > > > > > This yield one way to do OAM with or without CW. A GAL label > is > > > > > below the label for which action is taken (POP or PW > termination) > > > > > or below a label for which TTL has expired. This method > applied > > to LSP and PW. > > > > > > > > > > I think mandating CW would be just as good a solution, but one > > > > > that was rejected so this is the best we have. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > > To: Thomas Nadeau; Shahram Davari > > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that > > > > > > basis I support this draft. > > > > > > > > > > > > Sure, it'll take a while to move away from the router alert > > > > > > label and TTL approaches, but the GAL approach is definitely > > > > > > better than either of those... > > > > > > > > > > > > Giles > > > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > > > wrote: > > > > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > > > >> Hi, > > > > > > >> > > > > > > >> I also don=B9t support this draft since I don=B9t think to > solve > > > > > > >> the problem we need yet a 4th type of VCCV. The best > > solution is to mandate CW. > > > > > > > > > > > > > > While I am with you, that argument went out the window > during > > > > > > > the debates we had over the past 3 IETF meetings. Operators > > > > > > > were very clear that they do not want to mandate the use of > a > > CW. Hence, > > > > > > > Luca and I came up with this solution that narrows the > scope > > > > > > > to 2 modes, one that handles the CW case and one that > doesn't > > > > > > > while still both modes providing predictable OAM > capabilities > > > > > > > for the PW. > > > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > >> > > > > > > >> Shahram > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > On > > > > > > >> Behalf Of Robert Rennison > > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew > > > > > > >> (Matthew); pwe3@ietf.org > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> I do Not support the draft, > > > > > > >> > > > > > > >> After hearing the results of the earlier user deployment > > > > > > >> poll I thought, =B3 ok the way out of this mess is to > migrate > > > > > > >> towards using the CW=B2. Then I see this proposal and > wondered > > > > > > >> what am I missing. I=B9ve still not seen the light of why > > > > > > >> adding a fourth type will simplify matters, hence in the > > > > > > >> absence of me understanding how this will simplify matter > > versus complicate things, I=B9m against it. > > > > > > >> > > > > > > >> Rob > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > On > > > > > > >> Behalf Of Alexander Vainshtein > > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> Hi all, > > > > > > >> I do NOT support this draft for the same reasons that > Yaakov > > has indicated. > > > > > > >> > > > > > > >> Regards, > > > > > > >> Sasha > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On > > Behalf > > > > > > >> Of Yaakov Stein [yaakov_s@rad.com] > > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> I do not support ! and I can not understand how anyone > > can support it ! > > > > > > >> > > > > > > >> We do NOT need a fourth VCCV type, there are too many > > already. > > > > > > >> > > > > > > >> I completely agree with the part that says if there is a > CW > > > > > > >> then the ACh should be marked by it. > > > > > > >> > > > > > > >> I do NOT agree that if the CW is not used then we should > use > > > > > > >> a non-PW method developed for MPLS-TP. > > > > > > >> I do NOT agree that there is any way to deprecate the use > of > > > > > > >> TTL expiry to mark the ACh. > > > > > > >> I do NOT agree that we should change mechanisms that have > > > > > > >> been widely deployed for many years now, without an > > extremely > > > > > > >> pressing reason. > > > > > > >> > > > > > > >> Were the proposal to be that for PWs that traverse ONLY > > > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, I > > > > > > >> might be convinced not to object as strongly. > > > > > > >> However, since I don't think that PWs can be limited in > this > > > > > > >> matter (the MPLS WG adopted the "seamless" draft) it would > > be > > > > > > >> difficult to convince me that such a limitation is > possible. > > > > > > >> > > > > > > >> I would have enthusiastically support this proposal had it > > > > > > >> been brought 8 years ago. > > > > > > >> It's too late for this now. > > > > > > >> > > > > > > >> Y(J)S > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > On > > > > > > >> Behalf Of Bocci, Matthew (Matthew) > > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > > >> To: pwe3@ietf.org > > > > > > >> Subject: [PWE3] Poll for WG adoption of > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> This email begins a two week poll to help assess if there > is > > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a > PWE3 > > working group draft. > > > > > > >> > > > > > > >> Please indicate whether or not you support adoption of > this > > > > > > >> draft, and also send any comments to the PWE3 list. > > > > > > >> > > > > > > >> This poll will end on Friday 12th August. > > > > > > >> > > > > > > >> Regards, > > > > > > >> > > > > > > >> Matthew & Andy > > > > > > >> 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. > From jdrake@juniper.net Thu Aug 4 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 42E1A21F881C for ; Thu, 4 Aug 2011 12:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.059 X-Spam-Level: X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=0.540, 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 Me2B00wfg35t for ; Thu, 4 Aug 2011 12:29:39 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id BD2E521F8560 for ; Thu, 4 Aug 2011 12:29:37 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTjrzK4R5VBbdLXHHfBpVK0Qxp7M8ZJ3p@postini.com; Thu, 04 Aug 2011 12:29:54 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 4 Aug 2011 12:26:45 -0700 From: John E Drake To: Shahram Davari , "curtis@occnc.com" Date: Thu, 4 Aug 2011 12:26:44 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSyeL4keOJqv44SQW5wgy/thjRDQABWHpAAABpfEAAAGeMkAAA3g+wAADyFTA= Message-ID: <5E893DB832F57341992548CDBB333163A0AC0CCEC1@EMBX01-HQ.jnpr.net> References: Your message of "Thu, 04 Aug 2011 07:42:21 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> <201108041712.p74HCMCH057629@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB333163A0AC0CCCE1@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93275F652@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB333163A0AC0CCDDA@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93275F6B4@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F6B4@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 19:29:41 -0000 Shahram, Thanks for your comments! They are *really* incisive and helpful. John Sent from my iPhone > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Thursday, August 04, 2011 11:44 AM > To: John E Drake; curtis@occnc.com > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > Hi, > > I don't remember such direction and directions should be documented in > stable IETF draft and RFCs. And in fact I think that direction is not > correct. I think GAL should be at the bottom of the stack so I like to > challenge this draft as well. > > > Thx > Shahram > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, August 04, 2011 11:38 AM > To: Shahram Davari; curtis@occnc.com > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > Shahram, > > That is the date at which it became a *working group draft*. The point > that Curtis made, and with which I was agreeing, was that moving the > GAL from the bottom of the stack in support of ECMP has been the > direction taken by both MPLS and PWE3 for at least a year. > > John > > Sent from my iPhone > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Thursday, August 04, 2011 11:10 AM > > To: John E Drake; curtis@occnc.com > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > 'Robert.Rennison@ecitele.com' > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > John, > > > > If your point is that this is mentioned in an IETF draft then please > > look at the date of the draft as well (May 5 2011). Also this draft > > applies only to MPLS tunnels and not PW. I hope you don't expect > people > > to implement an IETF draft-00 which was published just 3 months ago. > > > > -Shahram > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, August 04, 2011 10:56 AM > > To: curtis@occnc.com; Shahram Davari > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > 'Robert.Rennison@ecitele.com' > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > From Section 6 of the Entropy Label I-D > > (http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy- > > label/?include_text=3D1): > > > > "As part of the MPLS-TP work, an in-band OAM channel is defined in > > [RFC5586]. Packets sent in this channel are identified with a > reserved > > label, the Generic Associated Channel Label (GAL) placed at the > bottom > > of the MPLS label stack. In order to use the inband OAM channel with > > entropy labels, this memo relaxes the restriction that the GAL must > be > > at the bottom of the MPLS label stack. Rather, the GAL is placed in > > the MPLS label stack above the entropy label so that it effectively > > functions as an application label." > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf > > Of > > > Curtis Villamizar > > > Sent: Thursday, August 04, 2011 10:12 AM > > > To: Shahram Davari > > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > > 'Robert.Rennison@ecitele.com' > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv- > 2- > > > 02.txt > > > > > > > > > In message > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadco > > > m.com> > > > "Shahram Davari" writes: > > > > > > > > I don't agree with you. This is not about broken HW. Before this > > > draft > > > > how was one supposed to process a packet with GAL in the middle > of > > > the > > > > label stack? > > > > > > Before this draft one had to read the MPLS and PWE3 mailing list > and > > > remember what was said. Getting it written in a draft is the next > > > step. > > > > > > Some of the most purist of the MPLS-TP folks have done a good job > of > > > shouting down any suggestion that multipath had a valid place in > any > > > network for quite some time. > > > > > > > What if this draft had decided to put GAL after entropy? Then the > > HW > > > > processing would have been completely different from what you are > > > > proposing on the fly now. > > > > > > Putting labels under GAL for the purpose of entropy was proposed on > > > MPLS mailing list for well over a year now, probably close to two > > > years, more recently on PWE3. It is reflected in other internet- > > > drafts, For example, draft-villamizar-mpls-tp-multipath-00 > > > was submitted before Maastricht but fell off the end of the agenda. > > > > > > It is also in a document that we have been giving to chip vendors > > under > > > NDA stating detailed requirements starting just under a year ago. > > > Before that is was more verbal discussion of requirements and > email. > > > Your friends in another part of your company were eliminated from > > > consideration for other reasons a while back but have heard this > > > requirement verbally at least. > > > > > > > You are making imaginary assumptions that HW should be able to > > > process > > > > what was in your mind. > > > > > > That is presumptious on your part. Actually we have given this > > > requirement to chip vendors in our product space for about a year > and > > a > > > half and I have brought this up for even longer in the MPLS WG and > > more > > > recently on PWE3. Two chip vendors have taken these requirements > to > > > heart and will be allowing labels under GAL plus the forwarding > > > functionality described in draft-villamizar-mpls-tp-multipath-01. > > > > > > Of all the packet processors that we have considered, all on the > very > > > high end of things, I know of none that have a parser that is so > > > inflexible that it could not deal with a label under GAL and still > > find > > > the OAM payload with nothing more than a change to the low level > > > programming of the parser. > > > > > > I can envision that chips do exist for which the parser is too hard > > > coded to accommodate such a change. Lucky for us (not luck really) > > > that we are not working with such a chip. Are you? > > > > > > > I strongly object to this unnecessary draft. If you look at RFCs > > > there > > > > are always cases that we wished we had done it differently, but > we > > > are > > > > not going to change them since in most cases like this one it is > > too > > > > late. Sorry but that is the fact. > > > > > > We are implementing labels under GAL for non-TP OAM in our products > > > regardless of your objections. If a provider wants to use it, it > > will > > > be there. If it can also be used for PW, all the better. Its > really > > > easy to do, so it doesn't hurt to do it. > > > > > > If a provider prefers to use CW all the time, I'm fine with that > but > > we > > > still need labels under GAL for non-TP MPLS OAM. > > > > > > > Thx > > > > Shahram > > > > > > Curtis > > > > > > > > > > ----- Original Message ----- > > > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > > > Sent: Thursday, August 04, 2011 06:38 AM > > > > To: Shahram Davari > > > > Cc: curtis@occnc.com ; Giles Heron > > > > ; Thomas Nadeau ; > > > > Yaakov Stein ; pwe3@ietf.org ; > > > Robert > > > > Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > In message > > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadc > > > > om.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Hi Curtis, > > > > > > > > > > Even if we assume this format (which is not yet incorporated in > > the > > > > > fat-pw draft), then most hardware assume ACH is right after > GAL. > > In > > > > > this case how is the HW supposed to examine the ACH channel > Type > > to > > > > > decide how to process the packet? (unless you assume there is > one > > > > > engine that can process all OAM packet types such as BFD, AIS, > > PSC, > > > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > Shahram, > > > > > > > > This doesn't need to go in the fat-pw draft. It needs to go into > > the > > > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM > > traffic > > > > when some other feature, fat-pw or other, puts a label under the > PW > > > > label. The GAL goes after the PW and before the other labels. A > > > > proper multipath distribution will skip any reserved label and > use > > > the > > > > rest of the label stack to load balance. This allows spraying > > across > > > > the entropy space or testing a spacific payload label stack that > > has > > > > yielded trouble. > > > > > > > > Hardware that assumes ACH is right after GAL when the S-bit is > not > > > set > > > > on the GAL is broken. > > > > > > > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > > > > > > > The IETF has never been sympathetic of broken hardware and should > > not > > > > be since we would halt progress. > > > > > > > > If the hardware is broken, then the fat-pw label can be omitted > but > > > > only one path through any multipath would be tested. It would > > still > > > > work for TP, but not work in general. PW does not require TP. > The > > > > fat-pw work is explicitly done for multipath because multipath is > > > used > > > > a lot in deployed networks and isn't going away. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > > > To: Shahram Davari > > > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > > > > > pwe3@ietf.org; Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > In message > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa > > > > > dcom.com> > > > > > "Shahram Davari" writes: > > > > > > > > > > > > Hi Curtis, > > > > > > > > > > > > You are absolutely correct if there is no Entropy label. But > > with > > > > > > Entropy label most implementation assume a Entropy label to > be > > > BoS > > > > > > and below the PW label. > > > > > > > > > > > > This draft doesn't even talk about whether the GAL should be > > BoS > > > > > > or the Entropy Label? In either case adding GAL would make > the > > > > > > packet un-parsable by most HW. > > > > > > > > > > > > Thx > > > > > > Shahram > > > > > > > > > > > > > > > That should be covered in this work. At least it was covered > in > > WG > > > > > email. PW, then GAL, then fat-pw (aka Flow label, which is > > > > > different from Entropy label in MPLS). > > > > > > > > > > 0 1 2 3 > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > | PW Label > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > | GAL > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > | ... additional labels (ie: fat-pw) may be present > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > |0 0 0 1|Version| Reserved | Associated Channel Type > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > | > | > > > > > ~ VCCV Message Body > ~ > > > > > | > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > > > > > > The above would be a better choice. The VCCV is always after > the > > > > > label entry with BOS (S-bit =3D 1). > > > > > > > > > > The flow label (or entropy label) must not be a reserved label. > > > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 > > > > > section > > > > > 1.2 (page 5) you will find. > > > > > > > > > > Note that the flow label MUST NOT be an MPLS reserved label > > > (values > > > > > in the range 0..15) [RFC3032], but is otherwise > unconstrained > > by > > > the > > > > > protocol. > > > > > > > > > > > > > > > The flow label below GAL is needed so that all data paths which > > the > > > > > PW can take are exercised by OAM (ie: LSP Ping used within > VCCV). > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > > > To: Shahram Davari > > > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; > > > > > > Robert Rennison > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > > > > In message > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.br > > > > > > oadcom.com> > > > > > > "Shahram Davari" writes: > > > > > > > > > > > > > > Giles, > > > > > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW > > and > > > > > > > use VVCV Type 1? Also what is wrong with TTL approach for > > non- > > > CW? > > > > > > > > > > > > > > Thx > > > > > > > Shahram > > > > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. > > The > > > > > > hardware need not know if the label above the GAL is an MPLS > > > label > > > > > > or a PW label, just that the next label is GAL and the label > > over > > > > > > it is not a SWAP. Unless we are talking about incredibly > > > > > > inflexible parser hardware, like none I've encounted > recently, > > > > > > there should be no problem noticing a GAL below the POP or PW > > > > > > label and then directing the packet to OAM processing. Any > > > > > > remaining labels must be removed and hopefully no > > implementation > > > > > > neglects to look for BOS before deciding where the payload is > > > supposed to be. > > > > > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). > > In > > > > > > this case TTL-expire would occur where a label swap was > called > > > for > > > > > > and a GAL would be below the label containing the expired > TTL. > > > > > > Since LDP can have transient loops, this avoids having lots > of > > > > > > packets sent to the OAM engine should such a loop occur in a > > LDP > > > signaled MPLS PSN. > > > > > > > > > > > > This yield one way to do OAM with or without CW. A GAL label > > is > > > > > > below the label for which action is taken (POP or PW > > termination) > > > > > > or below a label for which TTL has expired. This method > > applied > > > to LSP and PW. > > > > > > > > > > > > I think mandating CW would be just as good a solution, but > one > > > > > > that was rejected so this is the best we have. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > > > To: Thomas Nadeau; Shahram Davari > > > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that > > > > > > > basis I support this draft. > > > > > > > > > > > > > > Sure, it'll take a while to move away from the router alert > > > > > > > label and TTL approaches, but the GAL approach is > definitely > > > > > > > better than either of those... > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > > > > > >> Hi, > > > > > > > >> > > > > > > > >> I also don=B9t support this draft since I don=B9t think to > > solve > > > > > > > >> the problem we need yet a 4th type of VCCV. The best > > > solution is to mandate CW. > > > > > > > > > > > > > > > > While I am with you, that argument went out the window > > during > > > > > > > > the debates we had over the past 3 IETF meetings. > Operators > > > > > > > > were very clear that they do not want to mandate the use > of > > a > > > CW. Hence, > > > > > > > > Luca and I came up with this solution that narrows the > > scope > > > > > > > > to 2 modes, one that handles the CW case and one that > > doesn't > > > > > > > > while still both modes providing predictable OAM > > capabilities > > > > > > > > for the PW. > > > > > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > >> Shahram > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > bounces@ietf.org] > > > On > > > > > > > >> Behalf Of Robert Rennison > > > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew > > > > > > > >> (Matthew); pwe3@ietf.org > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> I do Not support the draft, > > > > > > > >> > > > > > > > >> After hearing the results of the earlier user deployment > > > > > > > >> poll I thought, =B3 ok the way out of this mess is to > > migrate > > > > > > > >> towards using the CW=B2. Then I see this proposal and > > wondered > > > > > > > >> what am I missing. I=B9ve still not seen the light of why > > > > > > > >> adding a fourth type will simplify matters, hence in the > > > > > > > >> absence of me understanding how this will simplify > matter > > > versus complicate things, I=B9m against it. > > > > > > > >> > > > > > > > >> Rob > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > bounces@ietf.org] > > > On > > > > > > > >> Behalf Of Alexander Vainshtein > > > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); > pwe3@ietf.org > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> Hi all, > > > > > > > >> I do NOT support this draft for the same reasons that > > Yaakov > > > has indicated. > > > > > > > >> > > > > > > > >> Regards, > > > > > > > >> Sasha > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On > > > Behalf > > > > > > > >> Of Yaakov Stein [yaakov_s@rad.com] > > > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> I do not support ! and I can not understand how > anyone > > > can support it ! > > > > > > > >> > > > > > > > >> We do NOT need a fourth VCCV type, there are too many > > > already. > > > > > > > >> > > > > > > > >> I completely agree with the part that says if there is a > > CW > > > > > > > >> then the ACh should be marked by it. > > > > > > > >> > > > > > > > >> I do NOT agree that if the CW is not used then we should > > use > > > > > > > >> a non-PW method developed for MPLS-TP. > > > > > > > >> I do NOT agree that there is any way to deprecate the > use > > of > > > > > > > >> TTL expiry to mark the ACh. > > > > > > > >> I do NOT agree that we should change mechanisms that > have > > > > > > > >> been widely deployed for many years now, without an > > > extremely > > > > > > > >> pressing reason. > > > > > > > >> > > > > > > > >> Were the proposal to be that for PWs that traverse ONLY > > > > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, I > > > > > > > >> might be convinced not to object as strongly. > > > > > > > >> However, since I don't think that PWs can be limited in > > this > > > > > > > >> matter (the MPLS WG adopted the "seamless" draft) it > would > > > be > > > > > > > >> difficult to convince me that such a limitation is > > possible. > > > > > > > >> > > > > > > > >> I would have enthusiastically support this proposal had > it > > > > > > > >> been brought 8 years ago. > > > > > > > >> It's too late for this now. > > > > > > > >> > > > > > > > >> Y(J)S > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > bounces@ietf.org] > > > On > > > > > > > >> Behalf Of Bocci, Matthew (Matthew) > > > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > > > >> To: pwe3@ietf.org > > > > > > > >> Subject: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> This email begins a two week poll to help assess if > there > > is > > > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a > > PWE3 > > > working group draft. > > > > > > > >> > > > > > > > >> Please indicate whether or not you support adoption of > > this > > > > > > > >> draft, and also send any comments to the PWE3 list. > > > > > > > >> > > > > > > > >> This poll will end on Friday 12th August. > > > > > > > >> > > > > > > > >> Regards, > > > > > > > >> > > > > > > > >> Matthew & Andy > > > > > > > >> 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. > > > > From davari@broadcom.com Thu Aug 4 12:50: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 C417121F8AA8 for ; Thu, 4 Aug 2011 12:50:55 -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.000, 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 bLoeyYD6cbl9 for ; Thu, 4 Aug 2011 12:50:54 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id C677421F8A91 for ; Thu, 4 Aug 2011 12:50:53 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 04 Aug 2011 12:55: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; Thu, 4 Aug 2011 12:50:43 -0700 From: "Shahram Davari" To: "John E Drake" , "curtis@occnc.com" Date: Thu, 4 Aug 2011 12:50:42 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSyeL4keOJqv44SQW5wgy/thjRDQABWHpAAABpfEAAAGeMkAAA3g+wAADyFTAAANR5IA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F741@SJEXCHCCR02.corp.ad.broadcom.com> References: Your message of "Thu, 04 Aug 2011 07:42:21 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> <201108041712.p74HCMCH057629@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB333163A0AC0CCCE1@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93275F652@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB333163A0AC0CCDDA@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93275F6B4@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB333163A0AC0CCEC1@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0AC0CCEC1@EMBX01-HQ.jnpr.net> 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: 622426CB3KO2630232-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 19:50:56 -0000 John, Sorry for not providing enough justification. All I wanted to point out was= that this is not a done deal so vendors march to implement it. Here is my justification for having GAL at the bottom of stack: Having reserved labels such as GAL in the middle of stack is not elegant be= cause the only action one has is to punt that packet to CPU. The reason is = that you can never know what is below GAL since GAL is your terminating lab= el. This is a huge restriction similar to what we had with RAL label as wel= l. However if GAL is BoS, then you could actually process all labels before= GAL and be sure there is an ACH after GAL. Regards, Shahram -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, August 04, 2011 12:27 PM To: Shahram Davari; curtis@occnc.com Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Shahram, Thanks for your comments! They are *really* incisive and helpful. John Sent from my iPhone > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Thursday, August 04, 2011 11:44 AM > To: John E Drake; curtis@occnc.com > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > Hi, > > I don't remember such direction and directions should be documented in > stable IETF draft and RFCs. And in fact I think that direction is not > correct. I think GAL should be at the bottom of the stack so I like to > challenge this draft as well. > > > Thx > Shahram > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, August 04, 2011 11:38 AM > To: Shahram Davari; curtis@occnc.com > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > Shahram, > > That is the date at which it became a *working group draft*. The point > that Curtis made, and with which I was agreeing, was that moving the > GAL from the bottom of the stack in support of ECMP has been the > direction taken by both MPLS and PWE3 for at least a year. > > John > > Sent from my iPhone > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Thursday, August 04, 2011 11:10 AM > > To: John E Drake; curtis@occnc.com > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > 'Robert.Rennison@ecitele.com' > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > John, > > > > If your point is that this is mentioned in an IETF draft then please > > look at the date of the draft as well (May 5 2011). Also this draft > > applies only to MPLS tunnels and not PW. I hope you don't expect > people > > to implement an IETF draft-00 which was published just 3 months ago. > > > > -Shahram > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, August 04, 2011 10:56 AM > > To: curtis@occnc.com; Shahram Davari > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > 'Robert.Rennison@ecitele.com' > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > From Section 6 of the Entropy Label I-D > > (http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy- > > label/?include_text=3D1): > > > > "As part of the MPLS-TP work, an in-band OAM channel is defined in > > [RFC5586]. Packets sent in this channel are identified with a > reserved > > label, the Generic Associated Channel Label (GAL) placed at the > bottom > > of the MPLS label stack. In order to use the inband OAM channel with > > entropy labels, this memo relaxes the restriction that the GAL must > be > > at the bottom of the MPLS label stack. Rather, the GAL is placed in > > the MPLS label stack above the entropy label so that it effectively > > functions as an application label." > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf > > Of > > > Curtis Villamizar > > > Sent: Thursday, August 04, 2011 10:12 AM > > > To: Shahram Davari > > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > > 'Robert.Rennison@ecitele.com' > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv- > 2- > > > 02.txt > > > > > > > > > In message > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadco > > > m.com> > > > "Shahram Davari" writes: > > > > > > > > I don't agree with you. This is not about broken HW. Before this > > > draft > > > > how was one supposed to process a packet with GAL in the middle > of > > > the > > > > label stack? > > > > > > Before this draft one had to read the MPLS and PWE3 mailing list > and > > > remember what was said. Getting it written in a draft is the next > > > step. > > > > > > Some of the most purist of the MPLS-TP folks have done a good job > of > > > shouting down any suggestion that multipath had a valid place in > any > > > network for quite some time. > > > > > > > What if this draft had decided to put GAL after entropy? Then the > > HW > > > > processing would have been completely different from what you are > > > > proposing on the fly now. > > > > > > Putting labels under GAL for the purpose of entropy was proposed on > > > MPLS mailing list for well over a year now, probably close to two > > > years, more recently on PWE3. It is reflected in other internet- > > > drafts, For example, draft-villamizar-mpls-tp-multipath-00 > > > was submitted before Maastricht but fell off the end of the agenda. > > > > > > It is also in a document that we have been giving to chip vendors > > under > > > NDA stating detailed requirements starting just under a year ago. > > > Before that is was more verbal discussion of requirements and > email. > > > Your friends in another part of your company were eliminated from > > > consideration for other reasons a while back but have heard this > > > requirement verbally at least. > > > > > > > You are making imaginary assumptions that HW should be able to > > > process > > > > what was in your mind. > > > > > > That is presumptious on your part. Actually we have given this > > > requirement to chip vendors in our product space for about a year > and > > a > > > half and I have brought this up for even longer in the MPLS WG and > > more > > > recently on PWE3. Two chip vendors have taken these requirements > to > > > heart and will be allowing labels under GAL plus the forwarding > > > functionality described in draft-villamizar-mpls-tp-multipath-01. > > > > > > Of all the packet processors that we have considered, all on the > very > > > high end of things, I know of none that have a parser that is so > > > inflexible that it could not deal with a label under GAL and still > > find > > > the OAM payload with nothing more than a change to the low level > > > programming of the parser. > > > > > > I can envision that chips do exist for which the parser is too hard > > > coded to accommodate such a change. Lucky for us (not luck really) > > > that we are not working with such a chip. Are you? > > > > > > > I strongly object to this unnecessary draft. If you look at RFCs > > > there > > > > are always cases that we wished we had done it differently, but > we > > > are > > > > not going to change them since in most cases like this one it is > > too > > > > late. Sorry but that is the fact. > > > > > > We are implementing labels under GAL for non-TP OAM in our products > > > regardless of your objections. If a provider wants to use it, it > > will > > > be there. If it can also be used for PW, all the better. Its > really > > > easy to do, so it doesn't hurt to do it. > > > > > > If a provider prefers to use CW all the time, I'm fine with that > but > > we > > > still need labels under GAL for non-TP MPLS OAM. > > > > > > > Thx > > > > Shahram > > > > > > Curtis > > > > > > > > > > ----- Original Message ----- > > > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > > > Sent: Thursday, August 04, 2011 06:38 AM > > > > To: Shahram Davari > > > > Cc: curtis@occnc.com ; Giles Heron > > > > ; Thomas Nadeau ; > > > > Yaakov Stein ; pwe3@ietf.org ; > > > Robert > > > > Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > In message > > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadc > > > > om.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Hi Curtis, > > > > > > > > > > Even if we assume this format (which is not yet incorporated in > > the > > > > > fat-pw draft), then most hardware assume ACH is right after > GAL. > > In > > > > > this case how is the HW supposed to examine the ACH channel > Type > > to > > > > > decide how to process the packet? (unless you assume there is > one > > > > > engine that can process all OAM packet types such as BFD, AIS, > > PSC, > > > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > Shahram, > > > > > > > > This doesn't need to go in the fat-pw draft. It needs to go into > > the > > > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM > > traffic > > > > when some other feature, fat-pw or other, puts a label under the > PW > > > > label. The GAL goes after the PW and before the other labels. A > > > > proper multipath distribution will skip any reserved label and > use > > > the > > > > rest of the label stack to load balance. This allows spraying > > across > > > > the entropy space or testing a spacific payload label stack that > > has > > > > yielded trouble. > > > > > > > > Hardware that assumes ACH is right after GAL when the S-bit is > not > > > set > > > > on the GAL is broken. > > > > > > > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > > > > > > > The IETF has never been sympathetic of broken hardware and should > > not > > > > be since we would halt progress. > > > > > > > > If the hardware is broken, then the fat-pw label can be omitted > but > > > > only one path through any multipath would be tested. It would > > still > > > > work for TP, but not work in general. PW does not require TP. > The > > > > fat-pw work is explicitly done for multipath because multipath is > > > used > > > > a lot in deployed networks and isn't going away. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > > > To: Shahram Davari > > > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > > > > > pwe3@ietf.org; Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > In message > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa > > > > > dcom.com> > > > > > "Shahram Davari" writes: > > > > > > > > > > > > Hi Curtis, > > > > > > > > > > > > You are absolutely correct if there is no Entropy label. But > > with > > > > > > Entropy label most implementation assume a Entropy label to > be > > > BoS > > > > > > and below the PW label. > > > > > > > > > > > > This draft doesn't even talk about whether the GAL should be > > BoS > > > > > > or the Entropy Label? In either case adding GAL would make > the > > > > > > packet un-parsable by most HW. > > > > > > > > > > > > Thx > > > > > > Shahram > > > > > > > > > > > > > > > That should be covered in this work. At least it was covered > in > > WG > > > > > email. PW, then GAL, then fat-pw (aka Flow label, which is > > > > > different from Entropy label in MPLS). > > > > > > > > > > 0 1 2 3 > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > | PW Label > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > | GAL > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > | ... additional labels (ie: fat-pw) may be present > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > |0 0 0 1|Version| Reserved | Associated Channel Type > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > | > | > > > > > ~ VCCV Message Body > ~ > > > > > | > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > > > > > > > The above would be a better choice. The VCCV is always after > the > > > > > label entry with BOS (S-bit =3D 1). > > > > > > > > > > The flow label (or entropy label) must not be a reserved label. > > > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 > > > > > section > > > > > 1.2 (page 5) you will find. > > > > > > > > > > Note that the flow label MUST NOT be an MPLS reserved label > > > (values > > > > > in the range 0..15) [RFC3032], but is otherwise > unconstrained > > by > > > the > > > > > protocol. > > > > > > > > > > > > > > > The flow label below GAL is needed so that all data paths which > > the > > > > > PW can take are exercised by OAM (ie: LSP Ping used within > VCCV). > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > > > To: Shahram Davari > > > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; > > > > > > Robert Rennison > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > > > > In message > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.br > > > > > > oadcom.com> > > > > > > "Shahram Davari" writes: > > > > > > > > > > > > > > Giles, > > > > > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW > > and > > > > > > > use VVCV Type 1? Also what is wrong with TTL approach for > > non- > > > CW? > > > > > > > > > > > > > > Thx > > > > > > > Shahram > > > > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. > > The > > > > > > hardware need not know if the label above the GAL is an MPLS > > > label > > > > > > or a PW label, just that the next label is GAL and the label > > over > > > > > > it is not a SWAP. Unless we are talking about incredibly > > > > > > inflexible parser hardware, like none I've encounted > recently, > > > > > > there should be no problem noticing a GAL below the POP or PW > > > > > > label and then directing the packet to OAM processing. Any > > > > > > remaining labels must be removed and hopefully no > > implementation > > > > > > neglects to look for BOS before deciding where the payload is > > > supposed to be. > > > > > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). > > In > > > > > > this case TTL-expire would occur where a label swap was > called > > > for > > > > > > and a GAL would be below the label containing the expired > TTL. > > > > > > Since LDP can have transient loops, this avoids having lots > of > > > > > > packets sent to the OAM engine should such a loop occur in a > > LDP > > > signaled MPLS PSN. > > > > > > > > > > > > This yield one way to do OAM with or without CW. A GAL label > > is > > > > > > below the label for which action is taken (POP or PW > > termination) > > > > > > or below a label for which TTL has expired. This method > > applied > > > to LSP and PW. > > > > > > > > > > > > I think mandating CW would be just as good a solution, but > one > > > > > > that was rejected so this is the best we have. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > > > To: Thomas Nadeau; Shahram Davari > > > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that > > > > > > > basis I support this draft. > > > > > > > > > > > > > > Sure, it'll take a while to move away from the router alert > > > > > > > label and TTL approaches, but the GAL approach is > definitely > > > > > > > better than either of those... > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > > > > > >> Hi, > > > > > > > >> > > > > > > > >> I also don=B9t support this draft since I don=B9t think to > > solve > > > > > > > >> the problem we need yet a 4th type of VCCV. The best > > > solution is to mandate CW. > > > > > > > > > > > > > > > > While I am with you, that argument went out the window > > during > > > > > > > > the debates we had over the past 3 IETF meetings. > Operators > > > > > > > > were very clear that they do not want to mandate the use > of > > a > > > CW. Hence, > > > > > > > > Luca and I came up with this solution that narrows the > > scope > > > > > > > > to 2 modes, one that handles the CW case and one that > > doesn't > > > > > > > > while still both modes providing predictable OAM > > capabilities > > > > > > > > for the PW. > > > > > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > >> Shahram > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > bounces@ietf.org] > > > On > > > > > > > >> Behalf Of Robert Rennison > > > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew > > > > > > > >> (Matthew); pwe3@ietf.org > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> I do Not support the draft, > > > > > > > >> > > > > > > > >> After hearing the results of the earlier user deployment > > > > > > > >> poll I thought, =B3 ok the way out of this mess is to > > migrate > > > > > > > >> towards using the CW=B2. Then I see this proposal and > > wondered > > > > > > > >> what am I missing. I=B9ve still not seen the light of why > > > > > > > >> adding a fourth type will simplify matters, hence in the > > > > > > > >> absence of me understanding how this will simplify > matter > > > versus complicate things, I=B9m against it. > > > > > > > >> > > > > > > > >> Rob > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > bounces@ietf.org] > > > On > > > > > > > >> Behalf Of Alexander Vainshtein > > > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); > pwe3@ietf.org > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> Hi all, > > > > > > > >> I do NOT support this draft for the same reasons that > > Yaakov > > > has indicated. > > > > > > > >> > > > > > > > >> Regards, > > > > > > > >> Sasha > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On > > > Behalf > > > > > > > >> Of Yaakov Stein [yaakov_s@rad.com] > > > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> I do not support ! and I can not understand how > anyone > > > can support it ! > > > > > > > >> > > > > > > > >> We do NOT need a fourth VCCV type, there are too many > > > already. > > > > > > > >> > > > > > > > >> I completely agree with the part that says if there is a > > CW > > > > > > > >> then the ACh should be marked by it. > > > > > > > >> > > > > > > > >> I do NOT agree that if the CW is not used then we should > > use > > > > > > > >> a non-PW method developed for MPLS-TP. > > > > > > > >> I do NOT agree that there is any way to deprecate the > use > > of > > > > > > > >> TTL expiry to mark the ACh. > > > > > > > >> I do NOT agree that we should change mechanisms that > have > > > > > > > >> been widely deployed for many years now, without an > > > extremely > > > > > > > >> pressing reason. > > > > > > > >> > > > > > > > >> Were the proposal to be that for PWs that traverse ONLY > > > > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, I > > > > > > > >> might be convinced not to object as strongly. > > > > > > > >> However, since I don't think that PWs can be limited in > > this > > > > > > > >> matter (the MPLS WG adopted the "seamless" draft) it > would > > > be > > > > > > > >> difficult to convince me that such a limitation is > > possible. > > > > > > > >> > > > > > > > >> I would have enthusiastically support this proposal had > it > > > > > > > >> been brought 8 years ago. > > > > > > > >> It's too late for this now. > > > > > > > >> > > > > > > > >> Y(J)S > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > bounces@ietf.org] > > > On > > > > > > > >> Behalf Of Bocci, Matthew (Matthew) > > > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > > > >> To: pwe3@ietf.org > > > > > > > >> Subject: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> This email begins a two week poll to help assess if > there > > is > > > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a > > PWE3 > > > working group draft. > > > > > > > >> > > > > > > > >> Please indicate whether or not you support adoption of > > this > > > > > > > >> draft, and also send any comments to the PWE3 list. > > > > > > > >> > > > > > > > >> This poll will end on Friday 12th August. > > > > > > > >> > > > > > > > >> Regards, > > > > > > > >> > > > > > > > >> Matthew & Andy > > > > > > > >> 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. > > > > From jdrake@juniper.net Thu Aug 4 13:00: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 939715E8002 for ; Thu, 4 Aug 2011 13:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.534, 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 XmqYZLj6ze6Z for ; Thu, 4 Aug 2011 13:00:22 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 35D1321F8B0A for ; Thu, 4 Aug 2011 13:00:20 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTjr6XZbw+tCe9ntjP0C6RR8Gxk7P0U/v@postini.com; Thu, 04 Aug 2011 13:00:37 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 4 Aug 2011 12:58:19 -0700 From: John E Drake To: Shahram Davari , "curtis@occnc.com" Date: Thu, 4 Aug 2011 12:58:17 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxSyeL4keOJqv44SQW5wgy/thjRDQABWHpAAABpfEAAAGeMkAAA3g+wAADyFTAAANR5IAAA6FHA Message-ID: <5E893DB832F57341992548CDBB333163A0AC0CCF42@EMBX01-HQ.jnpr.net> References: Your message of "Thu, 04 Aug 2011 07:42:21 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> <201108041712.p74HCMCH057629@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB333163A0AC0CCCE1@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93275F652@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB333163A0AC0CCDDA@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93275F6B4@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB333163A0AC0CCEC1@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93275F741@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F741@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 04 Aug 2011 20:00:24 -0000 Shahram, We'll take it under advisement. Thanks, John Sent from my iPhone > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Thursday, August 04, 2011 12:51 PM > To: John E Drake; curtis@occnc.com > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > John, > > Sorry for not providing enough justification. All I wanted to point out > was that this is not a done deal so vendors march to implement it. > > Here is my justification for having GAL at the bottom of stack: > > Having reserved labels such as GAL in the middle of stack is not > elegant because the only action one has is to punt that packet to CPU. > The reason is that you can never know what is below GAL since GAL is > your terminating label. This is a huge restriction similar to what we > had with RAL label as well. However if GAL is BoS, then you could > actually process all labels before GAL and be sure there is an ACH > after GAL. > > Regards, > Shahram > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, August 04, 2011 12:27 PM > To: Shahram Davari; curtis@occnc.com > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > 02.txt > > Shahram, > > Thanks for your comments! They are *really* incisive and helpful. > > John > > Sent from my iPhone > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Thursday, August 04, 2011 11:44 AM > > To: John E Drake; curtis@occnc.com > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > 'Robert.Rennison@ecitele.com' > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > Hi, > > > > I don't remember such direction and directions should be documented > in > > stable IETF draft and RFCs. And in fact I think that direction is not > > correct. I think GAL should be at the bottom of the stack so I like > to > > challenge this draft as well. > > > > > > Thx > > Shahram > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, August 04, 2011 11:38 AM > > To: Shahram Davari; curtis@occnc.com > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > 'Robert.Rennison@ecitele.com' > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > Shahram, > > > > That is the date at which it became a *working group draft*. The > point > > that Curtis made, and with which I was agreeing, was that moving the > > GAL from the bottom of the stack in support of ECMP has been the > > direction taken by both MPLS and PWE3 for at least a year. > > > > John > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:davari@broadcom.com] > > > Sent: Thursday, August 04, 2011 11:10 AM > > > To: John E Drake; curtis@occnc.com > > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > > 'Robert.Rennison@ecitele.com' > > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv- > 2- > > > 02.txt > > > > > > John, > > > > > > If your point is that this is mentioned in an IETF draft then > please > > > look at the date of the draft as well (May 5 2011). Also this draft > > > applies only to MPLS tunnels and not PW. I hope you don't expect > > people > > > to implement an IETF draft-00 which was published just 3 months > ago. > > > > > > -Shahram > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, August 04, 2011 10:56 AM > > > To: curtis@occnc.com; Shahram Davari > > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > > 'Robert.Rennison@ecitele.com' > > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv- > 2- > > > 02.txt > > > > > > From Section 6 of the Entropy Label I-D > > > (http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy- > > > label/?include_text=3D1): > > > > > > "As part of the MPLS-TP work, an in-band OAM channel is defined in > > > [RFC5586]. Packets sent in this channel are identified with a > > reserved > > > label, the Generic Associated Channel Label (GAL) placed at the > > bottom > > > of the MPLS label stack. In order to use the inband OAM channel > with > > > entropy labels, this memo relaxes the restriction that the GAL must > > be > > > at the bottom of the MPLS label stack. Rather, the GAL is placed > in > > > the MPLS label stack above the entropy label so that it effectively > > > functions as an application label." > > > > > > Sent from my iPhone > > > > > > > > > > -----Original Message----- > > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > > Behalf > > > Of > > > > Curtis Villamizar > > > > Sent: Thursday, August 04, 2011 10:12 AM > > > > To: Shahram Davari > > > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > > > 'Robert.Rennison@ecitele.com' > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3- > vccv- > > 2- > > > > 02.txt > > > > > > > > > > > > In message > > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadco > > > > m.com> > > > > "Shahram Davari" writes: > > > > > > > > > > I don't agree with you. This is not about broken HW. Before > this > > > > draft > > > > > how was one supposed to process a packet with GAL in the middle > > of > > > > the > > > > > label stack? > > > > > > > > Before this draft one had to read the MPLS and PWE3 mailing list > > and > > > > remember what was said. Getting it written in a draft is the > next > > > > step. > > > > > > > > Some of the most purist of the MPLS-TP folks have done a good job > > of > > > > shouting down any suggestion that multipath had a valid place in > > any > > > > network for quite some time. > > > > > > > > > What if this draft had decided to put GAL after entropy? Then > the > > > HW > > > > > processing would have been completely different from what you > are > > > > > proposing on the fly now. > > > > > > > > Putting labels under GAL for the purpose of entropy was proposed > on > > > > MPLS mailing list for well over a year now, probably close to two > > > > years, more recently on PWE3. It is reflected in other internet- > > > > drafts, For example, draft-villamizar-mpls-tp-multipath-00 > > > > was submitted before Maastricht but fell off the end of the > agenda. > > > > > > > > It is also in a document that we have been giving to chip vendors > > > under > > > > NDA stating detailed requirements starting just under a year ago. > > > > Before that is was more verbal discussion of requirements and > > email. > > > > Your friends in another part of your company were eliminated from > > > > consideration for other reasons a while back but have heard this > > > > requirement verbally at least. > > > > > > > > > You are making imaginary assumptions that HW should be able to > > > > process > > > > > what was in your mind. > > > > > > > > That is presumptious on your part. Actually we have given this > > > > requirement to chip vendors in our product space for about a year > > and > > > a > > > > half and I have brought this up for even longer in the MPLS WG > and > > > more > > > > recently on PWE3. Two chip vendors have taken these requirements > > to > > > > heart and will be allowing labels under GAL plus the forwarding > > > > functionality described in draft-villamizar-mpls-tp-multipath-01. > > > > > > > > Of all the packet processors that we have considered, all on the > > very > > > > high end of things, I know of none that have a parser that is so > > > > inflexible that it could not deal with a label under GAL and > still > > > find > > > > the OAM payload with nothing more than a change to the low level > > > > programming of the parser. > > > > > > > > I can envision that chips do exist for which the parser is too > hard > > > > coded to accommodate such a change. Lucky for us (not luck > really) > > > > that we are not working with such a chip. Are you? > > > > > > > > > I strongly object to this unnecessary draft. If you look at > RFCs > > > > there > > > > > are always cases that we wished we had done it differently, but > > we > > > > are > > > > > not going to change them since in most cases like this one it > is > > > too > > > > > late. Sorry but that is the fact. > > > > > > > > We are implementing labels under GAL for non-TP OAM in our > products > > > > regardless of your objections. If a provider wants to use it, it > > > will > > > > be there. If it can also be used for PW, all the better. Its > > really > > > > easy to do, so it doesn't hurt to do it. > > > > > > > > If a provider prefers to use CW all the time, I'm fine with that > > but > > > we > > > > still need labels under GAL for non-TP MPLS OAM. > > > > > > > > > Thx > > > > > Shahram > > > > > > > > Curtis > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > > > > Sent: Thursday, August 04, 2011 06:38 AM > > > > > To: Shahram Davari > > > > > Cc: curtis@occnc.com ; Giles Heron > > > > > ; Thomas Nadeau > ; > > > > > Yaakov Stein ; pwe3@ietf.org ; > > > > Robert > > > > > Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > In message > > > > > > > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadc > > > > > om.com> > > > > > "Shahram Davari" writes: > > > > > > > > > > > > Hi Curtis, > > > > > > > > > > > > Even if we assume this format (which is not yet incorporated > in > > > the > > > > > > fat-pw draft), then most hardware assume ACH is right after > > GAL. > > > In > > > > > > this case how is the HW supposed to examine the ACH channel > > Type > > > to > > > > > > decide how to process the packet? (unless you assume there is > > one > > > > > > engine that can process all OAM packet types such as BFD, > AIS, > > > PSC, > > > > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > > > > > > > Thx > > > > > > Shahram > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > This doesn't need to go in the fat-pw draft. It needs to go > into > > > the > > > > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM > > > traffic > > > > > when some other feature, fat-pw or other, puts a label under > the > > PW > > > > > label. The GAL goes after the PW and before the other labels. > A > > > > > proper multipath distribution will skip any reserved label and > > use > > > > the > > > > > rest of the label stack to load balance. This allows spraying > > > across > > > > > the entropy space or testing a spacific payload label stack > that > > > has > > > > > yielded trouble. > > > > > > > > > > Hardware that assumes ACH is right after GAL when the S-bit is > > not > > > > set > > > > > on the GAL is broken. > > > > > > > > > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > > > > > > > > > The IETF has never been sympathetic of broken hardware and > should > > > not > > > > > be since we would halt progress. > > > > > > > > > > If the hardware is broken, then the fat-pw label can be omitted > > but > > > > > only one path through any multipath would be tested. It would > > > still > > > > > work for TP, but not work in general. PW does not require TP. > > The > > > > > fat-pw work is explicitly done for multipath because multipath > is > > > > used > > > > > a lot in deployed networks and isn't going away. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > > > > To: Shahram Davari > > > > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov > Stein; > > > > > > pwe3@ietf.org; Robert Rennison > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > > > > In message > > > > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa > > > > > > dcom.com> > > > > > > "Shahram Davari" writes: > > > > > > > > > > > > > > Hi Curtis, > > > > > > > > > > > > > > You are absolutely correct if there is no Entropy label. > But > > > with > > > > > > > Entropy label most implementation assume a Entropy label to > > be > > > > BoS > > > > > > > and below the PW label. > > > > > > > > > > > > > > This draft doesn't even talk about whether the GAL should > be > > > BoS > > > > > > > or the Entropy Label? In either case adding GAL would make > > the > > > > > > > packet un-parsable by most HW. > > > > > > > > > > > > > > Thx > > > > > > > Shahram > > > > > > > > > > > > > > > > > > That should be covered in this work. At least it was covered > > in > > > WG > > > > > > email. PW, then GAL, then fat-pw (aka Flow label, which is > > > > > > different from Entropy label in MPLS). > > > > > > > > > > > > 0 1 2 3 > > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > > +-+ > > > > > > | PW Label > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > > +-+ > > > > > > | GAL > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > > +-+ > > > > > > | ... additional labels (ie: fat-pw) may be present > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > > +-+ > > > > > > |0 0 0 1|Version| Reserved | Associated Channel Type > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > > +-+ > > > > > > | > > | > > > > > > ~ VCCV Message Body > > ~ > > > > > > | > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > > +-+ > > > > > > > > > > > > The above would be a better choice. The VCCV is always after > > the > > > > > > label entry with BOS (S-bit =3D 1). > > > > > > > > > > > > The flow label (or entropy label) must not be a reserved > label. > > > > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw- > 07 > > > > > > section > > > > > > 1.2 (page 5) you will find. > > > > > > > > > > > > Note that the flow label MUST NOT be an MPLS reserved > label > > > > (values > > > > > > in the range 0..15) [RFC3032], but is otherwise > > unconstrained > > > by > > > > the > > > > > > protocol. > > > > > > > > > > > > > > > > > > The flow label below GAL is needed so that all data paths > which > > > the > > > > > > PW can take are exercised by OAM (ie: LSP Ping used within > > VCCV). > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > > > > To: Shahram Davari > > > > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; > pwe3@ietf.org; > > > > > > > Robert Rennison > > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > > > > > > > In message > > > > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.br > > > > > > > oadcom.com> > > > > > > > "Shahram Davari" writes: > > > > > > > > > > > > > > > > Giles, > > > > > > > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add > CW > > > and > > > > > > > > use VVCV Type 1? Also what is wrong with TTL approach > for > > > non- > > > > CW? > > > > > > > > > > > > > > > > Thx > > > > > > > > Shahram > > > > > > > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > > > > > Adding GAL to an MPLS label stack requires hardware > support. > > > The > > > > > > > hardware need not know if the label above the GAL is an > MPLS > > > > label > > > > > > > or a PW label, just that the next label is GAL and the > label > > > over > > > > > > > it is not a SWAP. Unless we are talking about incredibly > > > > > > > inflexible parser hardware, like none I've encounted > > recently, > > > > > > > there should be no problem noticing a GAL below the POP or > PW > > > > > > > label and then directing the packet to OAM processing. Any > > > > > > > remaining labels must be removed and hopefully no > > > implementation > > > > > > > neglects to look for BOS before deciding where the payload > is > > > > supposed to be. > > > > > > > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW > case). > > > In > > > > > > > this case TTL-expire would occur where a label swap was > > called > > > > for > > > > > > > and a GAL would be below the label containing the expired > > TTL. > > > > > > > Since LDP can have transient loops, this avoids having lots > > of > > > > > > > packets sent to the OAM engine should such a loop occur in > a > > > LDP > > > > signaled MPLS PSN. > > > > > > > > > > > > > > This yield one way to do OAM with or without CW. A GAL > label > > > is > > > > > > > below the label for which action is taken (POP or PW > > > termination) > > > > > > > or below a label for which TTL has expired. This method > > > applied > > > > to LSP and PW. > > > > > > > > > > > > > > I think mandating CW would be just as good a solution, but > > one > > > > > > > that was rejected so this is the best we have. > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > > > > To: Thomas Nadeau; Shahram Davari > > > > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > > Agreed - some operators won't want to use a CW, and on > that > > > > > > > > basis I support this draft. > > > > > > > > > > > > > > > > Sure, it'll take a while to move away from the router > alert > > > > > > > > label and TTL approaches, but the GAL approach is > > definitely > > > > > > > > better than either of those... > > > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > > > > > > > >> Hi, > > > > > > > > >> > > > > > > > > >> I also don=B9t support this draft since I don=B9t think = to > > > solve > > > > > > > > >> the problem we need yet a 4th type of VCCV. The best > > > > solution is to mandate CW. > > > > > > > > > > > > > > > > > > While I am with you, that argument went out the window > > > during > > > > > > > > > the debates we had over the past 3 IETF meetings. > > Operators > > > > > > > > > were very clear that they do not want to mandate the > use > > of > > > a > > > > CW. Hence, > > > > > > > > > Luca and I came up with this solution that narrows the > > > scope > > > > > > > > > to 2 modes, one that handles the CW case and one that > > > doesn't > > > > > > > > > while still both modes providing predictable OAM > > > capabilities > > > > > > > > > for the PW. > > > > > > > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > >> Shahram > > > > > > > > >> > > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > > bounces@ietf.org] > > > > On > > > > > > > > >> Behalf Of Robert Rennison > > > > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew > > > > > > > > >> (Matthew); pwe3@ietf.org > > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > >> > > > > > > > > >> I do Not support the draft, > > > > > > > > >> > > > > > > > > >> After hearing the results of the earlier user > deployment > > > > > > > > >> poll I thought, =B3 ok the way out of this mess is to > > > migrate > > > > > > > > >> towards using the CW=B2. Then I see this proposal and > > > wondered > > > > > > > > >> what am I missing. I=B9ve still not seen the light of > why > > > > > > > > >> adding a fourth type will simplify matters, hence in > the > > > > > > > > >> absence of me understanding how this will simplify > > matter > > > > versus complicate things, I=B9m against it. > > > > > > > > >> > > > > > > > > >> Rob > > > > > > > > >> > > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > > bounces@ietf.org] > > > > On > > > > > > > > >> Behalf Of Alexander Vainshtein > > > > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); > > pwe3@ietf.org > > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > >> > > > > > > > > >> Hi all, > > > > > > > > >> I do NOT support this draft for the same reasons that > > > Yaakov > > > > has indicated. > > > > > > > > >> > > > > > > > > >> Regards, > > > > > > > > >> Sasha > > > > > > > > >> > > > > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On > > > > Behalf > > > > > > > > >> Of Yaakov Stein [yaakov_s@rad.com] > > > > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > >> > > > > > > > > >> I do not support ! and I can not understand how > > anyone > > > > can support it ! > > > > > > > > >> > > > > > > > > >> We do NOT need a fourth VCCV type, there are too many > > > > already. > > > > > > > > >> > > > > > > > > >> I completely agree with the part that says if there is > a > > > CW > > > > > > > > >> then the ACh should be marked by it. > > > > > > > > >> > > > > > > > > >> I do NOT agree that if the CW is not used then we > should > > > use > > > > > > > > >> a non-PW method developed for MPLS-TP. > > > > > > > > >> I do NOT agree that there is any way to deprecate the > > use > > > of > > > > > > > > >> TTL expiry to mark the ACh. > > > > > > > > >> I do NOT agree that we should change mechanisms that > > have > > > > > > > > >> been widely deployed for many years now, without an > > > > extremely > > > > > > > > >> pressing reason. > > > > > > > > >> > > > > > > > > >> Were the proposal to be that for PWs that traverse > ONLY > > > > > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, > I > > > > > > > > >> might be convinced not to object as strongly. > > > > > > > > >> However, since I don't think that PWs can be limited > in > > > this > > > > > > > > >> matter (the MPLS WG adopted the "seamless" draft) it > > would > > > > be > > > > > > > > >> difficult to convince me that such a limitation is > > > possible. > > > > > > > > >> > > > > > > > > >> I would have enthusiastically support this proposal > had > > it > > > > > > > > >> been brought 8 years ago. > > > > > > > > >> It's too late for this now. > > > > > > > > >> > > > > > > > > >> Y(J)S > > > > > > > > >> > > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > > bounces@ietf.org] > > > > On > > > > > > > > >> Behalf Of Bocci, Matthew (Matthew) > > > > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > > > > >> To: pwe3@ietf.org > > > > > > > > >> Subject: [PWE3] Poll for WG adoption of > > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > >> > > > > > > > > >> This email begins a two week poll to help assess if > > there > > > is > > > > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as > a > > > PWE3 > > > > working group draft. > > > > > > > > >> > > > > > > > > >> Please indicate whether or not you support adoption of > > > this > > > > > > > > >> draft, and also send any comments to the PWE3 list. > > > > > > > > >> > > > > > > > > >> This poll will end on Friday 12th August. > > > > > > > > >> > > > > > > > > >> Regards, > > > > > > > > >> > > > > > > > > >> Matthew & Andy > > > > > > > > >> 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. > > > > > > > > > From curtis@occnc.com Thu Aug 4 17:26: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 B057411E808D for ; Thu, 4 Aug 2011 17:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 ovhnLiFI0DBW for ; Thu, 4 Aug 2011 17:26:53 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id D649F21F869D for ; Thu, 4 Aug 2011 17:26:52 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p750PmEE072253; Thu, 4 Aug 2011 20:25:48 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108050025.p750PmEE072253@harbor.orleans.occnc.com> To: "Shahram Davari" From: Curtis Villamizar In-reply-to: Your message of "Thu, 04 Aug 2011 10:21:47 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275F5DD@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 04 Aug 2011 20:25:48 -0400 Sender: curtis@occnc.com Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:26:54 -0000 In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F5DD@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Curtis, > > I am sorry but your RFI and emails are not equal to IETF RFCs and > there is no reason for vendors to follow the words of an IETF > participant. > > Thanks > Shahram You are 100% correct. You are free to ignore anything and everything I say as a participant and you are free to ignore any other participant that you choose to ignore. Or all of them. It is only when consensus builds that you may find that you cannot ignore what you don't agree with. Sometimes concensus grows gradually as IETF participants discover that they have real world problems that need to be solved. If you are casting things in silicon and that silicon is going to be very inflexible, then you need to be very good at anticipating where concensus will grow well in advance. Or build silicon which is more flexible in the first place. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Thursday, August 04, 2011 10:12 AM > To: Shahram Davari > Cc: 'curtis@occnc.com'; 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com'; 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> > "Shahram Davari" writes: > > > > I don't agree with you. This is not about broken HW. Before this draft > > how was one supposed to process a packet with GAL in the middle of the > > label stack? > > Before this draft one had to read the MPLS and PWE3 mailing list and > remember what was said. Getting it written in a draft is the next > step. > > Some of the most purist of the MPLS-TP folks have done a good job of > shouting down any suggestion that multipath had a valid place in any > network for quite some time. > > > What if this draft had decided to put GAL after entropy? Then the HW > > processing would have been completely different from what you are > > proposing on the fly now. > > Putting labels under GAL for the purpose of entropy was proposed on > MPLS mailing list for well over a year now, probably close to two > years, more recently on PWE3. It is reflected in other > internet-drafts, For example, draft-villamizar-mpls-tp-multipath-00 > was submitted before Maastricht but fell off the end of the agenda. > > It is also in a document that we have been giving to chip vendors > under NDA stating detailed requirements starting just under a year ago. > Before that is was more verbal discussion of requirements and email. > Your friends in another part of your company were eliminated from > consideration for other reasons a while back but have heard this > requirement verbally at least. > > > You are making imaginary assumptions that HW should be able to process > > what was in your mind. > > That is presumptious on your part. Actually we have given this > requirement to chip vendors in our product space for about a year and > a half and I have brought this up for even longer in the MPLS WG and > more recently on PWE3. Two chip vendors have taken these requirements > to heart and will be allowing labels under GAL plus the forwarding > functionality described in draft-villamizar-mpls-tp-multipath-01. > > Of all the packet processors that we have considered, all on the very > high end of things, I know of none that have a parser that is so > inflexible that it could not deal with a label under GAL and still > find the OAM payload with nothing more than a change to the low level > programming of the parser. > > I can envision that chips do exist for which the parser is too hard > coded to accommodate such a change. Lucky for us (not luck really) > that we are not working with such a chip. Are you? > > > I strongly object to this unnecessary draft. If you look at RFCs there > > are always cases that we wished we had done it differently, but we are > > not going to change them since in most cases like this one it is too > > late. Sorry but that is the fact. > > We are implementing labels under GAL for non-TP OAM in our products > regardless of your objections. If a provider wants to use it, it will > be there. If it can also be used for PW, all the better. Its really > easy to do, so it doesn't hurt to do it. > > If a provider prefers to use CW all the time, I'm fine with that but > we still need labels under GAL for non-TP MPLS OAM. > > > Thx > > Shahram > > Curtis > > > > ----- Original Message ----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Thursday, August 04, 2011 06:38 AM > > To: Shahram Davari > > Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > Even if we assume this format (which is not yet incorporated in the > > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > > this case how is the HW supposed to examine the ACH channel Type to > > > decide how to process the packet? (unless you assume there is one > > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > This doesn't need to go in the fat-pw draft. It needs to go into the > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > > when some other feature, fat-pw or other, puts a label under the PW > > label. The GAL goes after the PW and before the other labels. A > > proper multipath distribution will skip any reserved label and use the > > rest of the label stack to load balance. This allows spraying across > > the entropy space or testing a spacific payload label stack that has > > yielded trouble. > > > > Hardware that assumes ACH is right after GAL when the S-bit is not set > > on the GAL is broken. > > > > The payload (ACH) is after the BOS (aka S-bit = 1). > > > > The IETF has never been sympathetic of broken hardware and should not > > be since we would halt progress. > > > > If the hardware is broken, then the fat-pw label can be omitted but > > only one path through any multipath would be tested. It would still > > work for TP, but not work in general. PW does not require TP. The > > fat-pw work is explicitly done for multipath because multipath is used > > a lot in deployed networks and isn't going away. > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > To: Shahram Davari > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com> > > > "Shahram Davari" writes: > > > > > > > > Hi Curtis, > > > > > > > > You are absolutely correct if there is no Entropy label. But with > > > > Entropy label most implementation assume a Entropy label to be BoS and > > > > below the PW label. > > > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > > the Entropy Label? In either case adding GAL would make the packet > > > > un-parsable by most HW. > > > > > > > > Thx > > > > Shahram > > > > > > > > > That should be covered in this work. At least it was covered in WG > > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > > from Entropy label in MPLS). > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | PW Label | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GAL | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | ... additional labels (ie: fat-pw) may be present | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | > > > ~ VCCV Message Body ~ > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The above would be a better choice. The VCCV is always after the > > > label entry with BOS (S-bit = 1). > > > > > > The flow label (or entropy label) must not be a reserved label. > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > > > 1.2 (page 5) you will find. > > > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > > protocol. > > > > > > > > > The flow label below GAL is needed so that all data paths which the PW > > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > To: Shahram Davari > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Giles, > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > Shahram, > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > > hardware need not know if the label above the GAL is an MPLS label or > > > > a PW label, just that the next label is GAL and the label over it is > > > > not a SWAP. Unless we are talking about incredibly inflexible parser > > > > hardware, like none I've encounted recently, there should be no > > > > problem noticing a GAL below the POP or PW label and then directing > > > > the packet to OAM processing. Any remaining labels must be removed > > > > and hopefully no implementation neglects to look for BOS before > > > > deciding where the payload is supposed to be. > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In this > > > > case TTL-expire would occur where a label swap was called for and a > > > > GAL would be below the label containing the expired TTL. Since LDP > > > > can have transient loops, this avoids having lots of packets sent to > > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > > > This yield one way to do OAM with or without CW. A GAL label is below > > > > the label for which action is taken (POP or PW termination) or below a > > > > label for which TTL has expired. This method applied to LSP and PW. > > > > > > > > I think mandating CW would be just as good a solution, but one that > > > > was rejected so this is the best we have. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > To: Thomas Nadeau; Shahram Davari > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis I support > > > > > this draft. > > > > > > > > > > Sure, it'll take a while to move away from the router alert label and TTL > > > > > approaches, but the GAL approach is definitely better than either of > > > > > those... > > > > > > > > > > Giles > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > >> Hi, > > > > > >> > > > > > >> I also donąt support this draft since I donąt think to solve the problem we > > > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > > > > > While I am with you, that argument went out the window during the debates we > > > > > > had over the past 3 IETF meetings. Operators > > > > > > were very clear that they do not want to mandate the use of a CW. Hence, > > > > > > Luca and I came up with this solution that narrows the > > > > > > scope to 2 modes, one that handles the CW case and one that doesn't while > > > > > > still both modes providing predictable OAM capabilities > > > > > > for the PW. > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > >> > > > > > >> Shahram > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > > >> Robert Rennison > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > > > > > >> pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> I do Not support the draft, > > > > > >> > > > > > >> After hearing the results of the earlier user deployment poll I thought, > > > > > >> ł ok the way out of this mess is to migrate towards using the CW˛. Then I > > > > > >> see this proposal and wondered what am I missing. Iąve still not seen the > > > > > >> light of why adding a fourth type will simplify matters, hence in the absence > > > > > >> of me understanding how this will simplify matter versus complicate things, > > > > > >> Iąm against it. > > > > > >> > > > > > >> Rob > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > > >> Alexander Vainshtein > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> Hi all, > > > > > >> I do NOT support this draft for the same reasons that Yaakov has indicated. > > > > > >> > > > > > >> Regards, > > > > > >> Sasha > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein > > > > > >> [yaakov_s@rad.com] > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> I do not support ! and I can not understand how anyone can support it ! > > > > > >> > > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > > >> > > > > > >> I completely agree with the part that says if there is a CW then the ACh > > > > > >> should be marked by it. > > > > > >> > > > > > >> I do NOT agree that if the CW is not used then we should use a non-PW method > > > > > >> developed for MPLS-TP. > > > > > >> I do NOT agree that there is any way to deprecate the use of TTL expiry to > > > > > >> mark the ACh. > > > > > >> I do NOT agree that we should change mechanisms that have been widely > > > > > >> deployed for many years now, > > > > > >> without an extremely pressing reason. > > > > > >> > > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the > > > > > >> ADDITIONAL option > > > > > >> for ACh marking, I might be convinced not to object as strongly. > > > > > >> However, since I don't think that PWs can be limited in this matter (the MPLS > > > > > >> WG adopted the "seamless" draft) > > > > > >> it would be difficult to convince me that such a limitation is possible. > > > > > >> > > > > > >> I would have enthusiastically support this proposal had it been brought 8 > > > > > >> years ago. > > > > > >> It's too late for this now. > > > > > >> > > > > > >> Y(J)S > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > > >> Bocci, Matthew (Matthew) > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > >> To: pwe3@ietf.org > > > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> This email begins a two week poll to help assess if there is consensus to > > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > > > > > >> > > > > > >> Please indicate whether or not you support adoption of this draft, and also > > > > > >> send any comments to the PWE3 list. > > > > > >> > > > > > >> This poll will end on Friday 12th August. > > > > > >> > > > > > >> Regards, > > > > > >> > > > > > >> Matthew & Andy > > > > > >> 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. From davari@broadcom.com Thu Aug 4 17:38:35 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 2493311E8093 for ; Thu, 4 Aug 2011 17:38:35 -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.000, 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 4hWhSUFO4T3H for ; Thu, 4 Aug 2011 17:38:33 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8E17311E807C for ; Thu, 4 Aug 2011 17:38:33 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 04 Aug 2011 17:43:27 -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; Thu, 4 Aug 2011 17:38:09 -0700 From: "Shahram Davari" To: "curtis@occnc.com" Date: Thu, 4 Aug 2011 17:38:06 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxTBn5TlkujQIt+SHuyS92e5nbFQgAAV8zA Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F9AA@SJEXCHCCR02.corp.ad.broadcom.com> References: Your message of "Thu, 04 Aug 2011 10:21:47 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275F5DD@SJEXCHCCR02.corp.ad.broadcom.com> <201108050025.p750PmEE072253@harbor.orleans.occnc.com> In-Reply-To: <201108050025.p750PmEE072253@harbor.orleans.occnc.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: 6225E3253W41654454-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 05 Aug 2011 00:38:35 -0000 Thanks for your advice. I suggest you take a chip design course first. Thx Shahram -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 5:26 PM To: Shahram Davari Cc: curtis@occnc.com; 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com'; '= yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F5DD@SJEXCHCCR02.corp.ad.= broadcom.com> "Shahram Davari" writes: > > Curtis, > > I am sorry but your RFI and emails are not equal to IETF RFCs and > there is no reason for vendors to follow the words of an IETF > participant. > > Thanks > Shahram You are 100% correct. You are free to ignore anything and everything I say as a participant and you are free to ignore any other participant that you choose to ignore. Or all of them. It is only when consensus builds that you may find that you cannot ignore what you don't agree with. Sometimes concensus grows gradually as IETF participants discover that they have real world problems that need to be solved. If you are casting things in silicon and that silicon is going to be very inflexible, then you need to be very good at anticipating where concensus will grow well in advance. Or build silicon which is more flexible in the first place. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Thursday, August 04, 2011 10:12 AM > To: Shahram Davari > Cc: 'curtis@occnc.com'; 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com= '; 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.a= d.broadcom.com> > "Shahram Davari" writes: > > > > I don't agree with you. This is not about broken HW. Before this draft > > how was one supposed to process a packet with GAL in the middle of the > > label stack? > > Before this draft one had to read the MPLS and PWE3 mailing list and > remember what was said. Getting it written in a draft is the next > step. > > Some of the most purist of the MPLS-TP folks have done a good job of > shouting down any suggestion that multipath had a valid place in any > network for quite some time. > > > What if this draft had decided to put GAL after entropy? Then the HW > > processing would have been completely different from what you are > > proposing on the fly now. > > Putting labels under GAL for the purpose of entropy was proposed on > MPLS mailing list for well over a year now, probably close to two > years, more recently on PWE3. It is reflected in other > internet-drafts, For example, draft-villamizar-mpls-tp-multipath-00 > was submitted before Maastricht but fell off the end of the agenda. > > It is also in a document that we have been giving to chip vendors > under NDA stating detailed requirements starting just under a year ago. > Before that is was more verbal discussion of requirements and email. > Your friends in another part of your company were eliminated from > consideration for other reasons a while back but have heard this > requirement verbally at least. > > > You are making imaginary assumptions that HW should be able to process > > what was in your mind. > > That is presumptious on your part. Actually we have given this > requirement to chip vendors in our product space for about a year and > a half and I have brought this up for even longer in the MPLS WG and > more recently on PWE3. Two chip vendors have taken these requirements > to heart and will be allowing labels under GAL plus the forwarding > functionality described in draft-villamizar-mpls-tp-multipath-01. > > Of all the packet processors that we have considered, all on the very > high end of things, I know of none that have a parser that is so > inflexible that it could not deal with a label under GAL and still > find the OAM payload with nothing more than a change to the low level > programming of the parser. > > I can envision that chips do exist for which the parser is too hard > coded to accommodate such a change. Lucky for us (not luck really) > that we are not working with such a chip. Are you? > > > I strongly object to this unnecessary draft. If you look at RFCs there > > are always cases that we wished we had done it differently, but we are > > not going to change them since in most cases like this one it is too > > late. Sorry but that is the fact. > > We are implementing labels under GAL for non-TP OAM in our products > regardless of your objections. If a provider wants to use it, it will > be there. If it can also be used for PW, all the better. Its really > easy to do, so it doesn't hurt to do it. > > If a provider prefers to use CW all the time, I'm fine with that but > we still need labels under GAL for non-TP MPLS OAM. > > > Thx > > Shahram > > Curtis > > > > ----- Original Message ----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Thursday, August 04, 2011 06:38 AM > > To: Shahram Davari > > Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp= .ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > Even if we assume this format (which is not yet incorporated in the > > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > > this case how is the HW supposed to examine the ACH channel Type to > > > decide how to process the packet? (unless you assume there is one > > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > This doesn't need to go in the fat-pw draft. It needs to go into the > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > > when some other feature, fat-pw or other, puts a label under the PW > > label. The GAL goes after the PW and before the other labels. A > > proper multipath distribution will skip any reserved label and use the > > rest of the label stack to load balance. This allows spraying across > > the entropy space or testing a spacific payload label stack that has > > yielded trouble. > > > > Hardware that assumes ACH is right after GAL when the S-bit is not set > > on the GAL is broken. > > > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > > > The IETF has never been sympathetic of broken hardware and should not > > be since we would halt progress. > > > > If the hardware is broken, then the fat-pw label can be omitted but > > only one path through any multipath would be tested. It would still > > work for TP, but not work in general. PW does not require TP. The > > fat-pw work is explicitly done for multipath because multipath is used > > a lot in deployed networks and isn't going away. > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > To: Shahram Davari > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@= ietf.org; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-= 02.txt > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.co= rp.ad.broadcom.com> > > > "Shahram Davari" writes: > > > > > > > > Hi Curtis, > > > > > > > > You are absolutely correct if there is no Entropy label. But with > > > > Entropy label most implementation assume a Entropy label to be BoS = and > > > > below the PW label. > > > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > > the Entropy Label? In either case adding GAL would make the packet > > > > un-parsable by most HW. > > > > > > > > Thx > > > > Shahram > > > > > > > > > That should be covered in this work. At least it was covered in WG > > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > > from Entropy label in MPLS). > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | PW Label | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GAL | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | ... additional labels (ie: fat-pw) may be present | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | > > > ~ VCCV Message Body ~ > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The above would be a better choice. The VCCV is always after the > > > label entry with BOS (S-bit =3D 1). > > > > > > The flow label (or entropy label) must not be a reserved label. > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 sectio= n > > > 1.2 (page 5) you will find. > > > > > > Note that the flow label MUST NOT be an MPLS reserved label (value= s > > > in the range 0..15) [RFC3032], but is otherwise unconstrained by t= he > > > protocol. > > > > > > > > > The flow label below GAL is needed so that all data paths which the P= W > > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > To: Shahram Davari > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert= Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-= 2-02.txt > > > > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.= corp.ad.broadcom.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Giles, > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and u= se > > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > Shahram, > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > > hardware need not know if the label above the GAL is an MPLS label = or > > > > a PW label, just that the next label is GAL and the label over it i= s > > > > not a SWAP. Unless we are talking about incredibly inflexible pars= er > > > > hardware, like none I've encounted recently, there should be no > > > > problem noticing a GAL below the POP or PW label and then directing > > > > the packet to OAM processing. Any remaining labels must be removed > > > > and hopefully no implementation neglects to look for BOS before > > > > deciding where the payload is supposed to be. > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In t= his > > > > case TTL-expire would occur where a label swap was called for and a > > > > GAL would be below the label containing the expired TTL. Since LDP > > > > can have transient loops, this avoids having lots of packets sent t= o > > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > > > This yield one way to do OAM with or without CW. A GAL label is be= low > > > > the label for which action is taken (POP or PW termination) or belo= w a > > > > label for which TTL has expired. This method applied to LSP and PW= . > > > > > > > > I think mandating CW would be just as good a solution, but one that > > > > was rejected so this is the best we have. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > To: Thomas Nadeau; Shahram Davari > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vcc= v-2-02.txt > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis= I support > > > > > this draft. > > > > > > > > > > Sure, it'll take a while to move away from the router alert label= and TTL > > > > > approaches, but the GAL approach is definitely better than either= of > > > > > those... > > > > > > > > > > Giles > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wr= ote: > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > >> Hi, > > > > > >> > > > > > >> I also don=B9t support this draft since I don=B9t think to sol= ve the problem we > > > > > >> need yet a 4th type of VCCV. The best solution is to mandate C= W. > > > > > > > > > > > > While I am with you, that argument went out the window during t= he debates we > > > > > > had over the past 3 IETF meetings. Operators > > > > > > were very clear that they do not want to mandate the use of a C= W. Hence, > > > > > > Luca and I came up with this solution that narrows the > > > > > > scope to 2 modes, one that handles the CW case and one that doe= sn't while > > > > > > still both modes providing predictable OAM capabilities > > > > > > for the PW. > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > >> > > > > > >> Shahram > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On = Behalf Of > > > > > >> Robert Rennison > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthe= w); > > > > > >> pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-= vccv-2-02.txt > > > > > >> > > > > > >> I do Not support the draft, > > > > > >> > > > > > >> After hearing the results of the earlier user deployment poll= I thought, > > > > > >> =B3 ok the way out of this mess is to migrate towards using t= he CW=B2. Then I > > > > > >> see this proposal and wondered what am I missing. I=B9ve stil= l not seen the > > > > > >> light of why adding a fourth type will simplify matters, hence= in the absence > > > > > >> of me understanding how this will simplify matter versus compl= icate things, > > > > > >> I=B9m against it. > > > > > >> > > > > > >> Rob > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On = Behalf Of > > > > > >> Alexander Vainshtein > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-= vccv-2-02.txt > > > > > >> > > > > > >> Hi all, > > > > > >> I do NOT support this draft for the same reasons that Yaakov h= as indicated. > > > > > >> > > > > > >> Regards, > > > > > >> Sasha > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf = Of Yaakov Stein > > > > > >> [yaakov_s@rad.com] > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-= vccv-2-02.txt > > > > > >> > > > > > >> I do not support ! and I can not understand how anyone can = support it ! > > > > > >> > > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > > >> > > > > > >> I completely agree with the part that says if there is a CW th= en the ACh > > > > > >> should be marked by it. > > > > > >> > > > > > >> I do NOT agree that if the CW is not used then we should use a= non-PW method > > > > > >> developed for MPLS-TP. > > > > > >> I do NOT agree that there is any way to deprecate the use of T= TL expiry to > > > > > >> mark the ACh. > > > > > >> I do NOT agree that we should change mechanisms that have been= widely > > > > > >> deployed for many years now, > > > > > >> without an extremely pressing reason. > > > > > >> > > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-T= P to have the > > > > > >> ADDITIONAL option > > > > > >> for ACh marking, I might be convinced not to object as strongl= y. > > > > > >> However, since I don't think that PWs can be limited in this m= atter (the MPLS > > > > > >> WG adopted the "seamless" draft) > > > > > >> it would be difficult to convince me that such a limitation is= possible. > > > > > >> > > > > > >> I would have enthusiastically support this proposal had it bee= n brought 8 > > > > > >> years ago. > > > > > >> It's too late for this now. > > > > > >> > > > > > >> Y(J)S > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On = Behalf Of > > > > > >> Bocci, Matthew (Matthew) > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > >> To: pwe3@ietf.org > > > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > > > >> > > > > > >> This email begins a two week poll to help assess if there is c= onsensus to > > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group = draft. > > > > > >> > > > > > >> Please indicate whether or not you support adoption of this dr= aft, and also > > > > > >> send any comments to the PWE3 list. > > > > > >> > > > > > >> This poll will end on Friday 12th August. > > > > > >> > > > > > >> Regards, > > > > > >> > > > > > >> Matthew & Andy > > > > > >> This e-mail message is intended for the recipient only and con= tains > > > > > >> 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 original and all cop= ies thereof. > > > > > >> This e-mail message is intended for the recipient only and con= tains > > > > > >> 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 original and all cop= ies thereof. From curtis@occnc.com Thu Aug 4 17:39: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 065FA11E807C for ; Thu, 4 Aug 2011 17:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 1FRQgPwsToKk for ; Thu, 4 Aug 2011 17:39:44 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id E76CC11E809B for ; Thu, 4 Aug 2011 17:39:43 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p750cZUp072396; Thu, 4 Aug 2011 20:38:35 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108050038.p750cZUp072396@harbor.orleans.occnc.com> To: "Shahram Davari" From: Curtis Villamizar In-reply-to: Your message of "Thu, 04 Aug 2011 10:29:57 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275F5FA@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 04 Aug 2011 20:38:35 -0400 Sender: curtis@occnc.com Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:39:46 -0000 In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F5FA@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Also I forgot to mention that we have super-flexible fully > programmable parsers, but IETF works should not assume that everyone > has such capability. Specially for an unnecessary draft such as this > one. > > Thx > Shharam So apparently when you stated "Adding GAL to PW requires HW change" you were standing up for some unspecified "other vendor" that may be too shy or afraid to raise an objection. (?) OK. If someone has a problem with this fairly minor change to PW and GAL processing, they should speak for themselves. Curtis > -----Original Message----- > From: Shahram Davari > Sent: Thursday, August 04, 2011 10:22 AM > To: 'curtis@occnc.com' > Cc: 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com'; 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > Curtis, > > I am sorry but your RFI and emails are not equal to IETF RFCs and there is no reason for vendors to follow the words of an IETF participant. > > Thanks > Shahram > > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Thursday, August 04, 2011 10:12 AM > To: Shahram Davari > Cc: 'curtis@occnc.com'; 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com'; 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> > "Shahram Davari" writes: > > > > I don't agree with you. This is not about broken HW. Before this draft > > how was one supposed to process a packet with GAL in the middle of the > > label stack? > > Before this draft one had to read the MPLS and PWE3 mailing list and > remember what was said. Getting it written in a draft is the next > step. > > Some of the most purist of the MPLS-TP folks have done a good job of > shouting down any suggestion that multipath had a valid place in any > network for quite some time. > > > What if this draft had decided to put GAL after entropy? Then the HW > > processing would have been completely different from what you are > > proposing on the fly now. > > Putting labels under GAL for the purpose of entropy was proposed on > MPLS mailing list for well over a year now, probably close to two > years, more recently on PWE3. It is reflected in other > internet-drafts, For example, draft-villamizar-mpls-tp-multipath-00 > was submitted before Maastricht but fell off the end of the agenda. > > It is also in a document that we have been giving to chip vendors > under NDA stating detailed requirements starting just under a year ago. > Before that is was more verbal discussion of requirements and email. > Your friends in another part of your company were eliminated from > consideration for other reasons a while back but have heard this > requirement verbally at least. > > > You are making imaginary assumptions that HW should be able to process > > what was in your mind. > > That is presumptious on your part. Actually we have given this > requirement to chip vendors in our product space for about a year and > a half and I have brought this up for even longer in the MPLS WG and > more recently on PWE3. Two chip vendors have taken these requirements > to heart and will be allowing labels under GAL plus the forwarding > functionality described in draft-villamizar-mpls-tp-multipath-01. > > Of all the packet processors that we have considered, all on the very > high end of things, I know of none that have a parser that is so > inflexible that it could not deal with a label under GAL and still > find the OAM payload with nothing more than a change to the low level > programming of the parser. > > I can envision that chips do exist for which the parser is too hard > coded to accommodate such a change. Lucky for us (not luck really) > that we are not working with such a chip. Are you? > > > I strongly object to this unnecessary draft. If you look at RFCs there > > are always cases that we wished we had done it differently, but we are > > not going to change them since in most cases like this one it is too > > late. Sorry but that is the fact. > > We are implementing labels under GAL for non-TP OAM in our products > regardless of your objections. If a provider wants to use it, it will > be there. If it can also be used for PW, all the better. Its really > easy to do, so it doesn't hurt to do it. > > If a provider prefers to use CW all the time, I'm fine with that but > we still need labels under GAL for non-TP MPLS OAM. > > > Thx > > Shahram > > Curtis > > > > ----- Original Message ----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Thursday, August 04, 2011 06:38 AM > > To: Shahram Davari > > Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > Even if we assume this format (which is not yet incorporated in the > > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > > this case how is the HW supposed to examine the ACH channel Type to > > > decide how to process the packet? (unless you assume there is one > > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > This doesn't need to go in the fat-pw draft. It needs to go into the > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > > when some other feature, fat-pw or other, puts a label under the PW > > label. The GAL goes after the PW and before the other labels. A > > proper multipath distribution will skip any reserved label and use the > > rest of the label stack to load balance. This allows spraying across > > the entropy space or testing a spacific payload label stack that has > > yielded trouble. > > > > Hardware that assumes ACH is right after GAL when the S-bit is not set > > on the GAL is broken. > > > > The payload (ACH) is after the BOS (aka S-bit = 1). > > > > The IETF has never been sympathetic of broken hardware and should not > > be since we would halt progress. > > > > If the hardware is broken, then the fat-pw label can be omitted but > > only one path through any multipath would be tested. It would still > > work for TP, but not work in general. PW does not require TP. The > > fat-pw work is explicitly done for multipath because multipath is used > > a lot in deployed networks and isn't going away. > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > To: Shahram Davari > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com> > > > "Shahram Davari" writes: > > > > > > > > Hi Curtis, > > > > > > > > You are absolutely correct if there is no Entropy label. But with > > > > Entropy label most implementation assume a Entropy label to be BoS and > > > > below the PW label. > > > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > > the Entropy Label? In either case adding GAL would make the packet > > > > un-parsable by most HW. > > > > > > > > Thx > > > > Shahram > > > > > > > > > That should be covered in this work. At least it was covered in WG > > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > > from Entropy label in MPLS). > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | PW Label | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GAL | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | ... additional labels (ie: fat-pw) may be present | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | > > > ~ VCCV Message Body ~ > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The above would be a better choice. The VCCV is always after the > > > label entry with BOS (S-bit = 1). > > > > > > The flow label (or entropy label) must not be a reserved label. > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > > > 1.2 (page 5) you will find. > > > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > > protocol. > > > > > > > > > The flow label below GAL is needed so that all data paths which the PW > > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > To: Shahram Davari > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Giles, > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > Shahram, > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > > hardware need not know if the label above the GAL is an MPLS label or > > > > a PW label, just that the next label is GAL and the label over it is > > > > not a SWAP. Unless we are talking about incredibly inflexible parser > > > > hardware, like none I've encounted recently, there should be no > > > > problem noticing a GAL below the POP or PW label and then directing > > > > the packet to OAM processing. Any remaining labels must be removed > > > > and hopefully no implementation neglects to look for BOS before > > > > deciding where the payload is supposed to be. > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In this > > > > case TTL-expire would occur where a label swap was called for and a > > > > GAL would be below the label containing the expired TTL. Since LDP > > > > can have transient loops, this avoids having lots of packets sent to > > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > > > This yield one way to do OAM with or without CW. A GAL label is below > > > > the label for which action is taken (POP or PW termination) or below a > > > > label for which TTL has expired. This method applied to LSP and PW. > > > > > > > > I think mandating CW would be just as good a solution, but one that > > > > was rejected so this is the best we have. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > To: Thomas Nadeau; Shahram Davari > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis I support > > > > > this draft. > > > > > > > > > > Sure, it'll take a while to move away from the router alert label and TTL > > > > > approaches, but the GAL approach is definitely better than either of > > > > > those... > > > > > > > > > > Giles > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > >> Hi, > > > > > >> > > > > > >> I also donąt support this draft since I donąt think to solve the problem we > > > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > > > > > While I am with you, that argument went out the window during the debates we > > > > > > had over the past 3 IETF meetings. Operators > > > > > > were very clear that they do not want to mandate the use of a CW. Hence, > > > > > > Luca and I came up with this solution that narrows the > > > > > > scope to 2 modes, one that handles the CW case and one that doesn't while > > > > > > still both modes providing predictable OAM capabilities > > > > > > for the PW. > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > >> > > > > > >> Shahram > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > > >> Robert Rennison > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > > > > > >> pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> I do Not support the draft, > > > > > >> > > > > > >> After hearing the results of the earlier user deployment poll I thought, > > > > > >> ł ok the way out of this mess is to migrate towards using the CW˛. Then I > > > > > >> see this proposal and wondered what am I missing. Iąve still not seen the > > > > > >> light of why adding a fourth type will simplify matters, hence in the absence > > > > > >> of me understanding how this will simplify matter versus complicate things, > > > > > >> Iąm against it. > > > > > >> > > > > > >> Rob > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > > >> Alexander Vainshtein > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> Hi all, > > > > > >> I do NOT support this draft for the same reasons that Yaakov has indicated. > > > > > >> > > > > > >> Regards, > > > > > >> Sasha > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein > > > > > >> [yaakov_s@rad.com] > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> I do not support ! and I can not understand how anyone can support it ! > > > > > >> > > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > > >> > > > > > >> I completely agree with the part that says if there is a CW then the ACh > > > > > >> should be marked by it. > > > > > >> > > > > > >> I do NOT agree that if the CW is not used then we should use a non-PW method > > > > > >> developed for MPLS-TP. > > > > > >> I do NOT agree that there is any way to deprecate the use of TTL expiry to > > > > > >> mark the ACh. > > > > > >> I do NOT agree that we should change mechanisms that have been widely > > > > > >> deployed for many years now, > > > > > >> without an extremely pressing reason. > > > > > >> > > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the > > > > > >> ADDITIONAL option > > > > > >> for ACh marking, I might be convinced not to object as strongly. > > > > > >> However, since I don't think that PWs can be limited in this matter (the MPLS > > > > > >> WG adopted the "seamless" draft) > > > > > >> it would be difficult to convince me that such a limitation is possible. > > > > > >> > > > > > >> I would have enthusiastically support this proposal had it been brought 8 > > > > > >> years ago. > > > > > >> It's too late for this now. > > > > > >> > > > > > >> Y(J)S > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > > >> Bocci, Matthew (Matthew) > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > >> To: pwe3@ietf.org > > > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> This email begins a two week poll to help assess if there is consensus to > > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > > > > > >> > > > > > >> Please indicate whether or not you support adoption of this draft, and also > > > > > >> send any comments to the PWE3 list. > > > > > >> > > > > > >> This poll will end on Friday 12th August. > > > > > >> > > > > > >> Regards, > > > > > >> > > > > > >> Matthew & Andy > > > > > >> 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. From davari@broadcom.com Thu Aug 4 17:49:44 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 29D8B11E809B for ; Thu, 4 Aug 2011 17:49:44 -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.000, 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 CSbvFadLcd6L for ; Thu, 4 Aug 2011 17:49:42 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9798111E808D for ; Thu, 4 Aug 2011 17:49:42 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 04 Aug 2011 17:52:31 -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; Thu, 4 Aug 2011 17:47:29 -0700 From: "Shahram Davari" To: "curtis@occnc.com" Date: Thu, 4 Aug 2011 17:47:27 -0700 Thread-Topic: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxTCEIbqGez5iw9RlWTHX1eXW2fhQAADUyw Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F9B8@SJEXCHCCR02.corp.ad.broadcom.com> References: Your message of "Thu, 04 Aug 2011 10:29:57 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275F5FA@SJEXCHCCR02.corp.ad.broadcom.com> <201108050038.p750cZUp072396@harbor.orleans.occnc.com> In-Reply-To: <201108050038.p750cZUp072396@harbor.orleans.occnc.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: 6225E1453KO2701657-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 05 Aug 2011 00:49:44 -0000 Apparently you have no chip design experience. So let me give you some tuto= rial: Most chips have a fixed parse and a flexible parse. Flexible parsers are ex= pensive, since they use CAMs with limited capacity rather than memories. Th= erefore using flexible parsers should be limited as much possible for excep= tional cases. The question is why use such scarce resource for a feature that is not a ne= cessity but a nice thing to have. Shahram -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 5:39 PM To: Shahram Davari Cc: curtis@occnc.com; 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com'; '= yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F5FA@SJEXCHCCR02.corp.ad.= broadcom.com> "Shahram Davari" writes: > > Also I forgot to mention that we have super-flexible fully > programmable parsers, but IETF works should not assume that everyone > has such capability. Specially for an unnecessary draft such as this > one. > > Thx > Shharam So apparently when you stated "Adding GAL to PW requires HW change" you were standing up for some unspecified "other vendor" that may be too shy or afraid to raise an objection. (?) OK. If someone has a problem with this fairly minor change to PW and GAL processing, they should speak for themselves. Curtis > -----Original Message----- > From: Shahram Davari > Sent: Thursday, August 04, 2011 10:22 AM > To: 'curtis@occnc.com' > Cc: 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com'; 'yaakov_s@rad.com= '; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > > Curtis, > > I am sorry but your RFI and emails are not equal to IETF RFCs and there i= s no reason for vendors to follow the words of an IETF participant. > > Thanks > Shahram > > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Thursday, August 04, 2011 10:12 AM > To: Shahram Davari > Cc: 'curtis@occnc.com'; 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com= '; 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.a= d.broadcom.com> > "Shahram Davari" writes: > > > > I don't agree with you. This is not about broken HW. Before this draft > > how was one supposed to process a packet with GAL in the middle of the > > label stack? > > Before this draft one had to read the MPLS and PWE3 mailing list and > remember what was said. Getting it written in a draft is the next > step. > > Some of the most purist of the MPLS-TP folks have done a good job of > shouting down any suggestion that multipath had a valid place in any > network for quite some time. > > > What if this draft had decided to put GAL after entropy? Then the HW > > processing would have been completely different from what you are > > proposing on the fly now. > > Putting labels under GAL for the purpose of entropy was proposed on > MPLS mailing list for well over a year now, probably close to two > years, more recently on PWE3. It is reflected in other > internet-drafts, For example, draft-villamizar-mpls-tp-multipath-00 > was submitted before Maastricht but fell off the end of the agenda. > > It is also in a document that we have been giving to chip vendors > under NDA stating detailed requirements starting just under a year ago. > Before that is was more verbal discussion of requirements and email. > Your friends in another part of your company were eliminated from > consideration for other reasons a while back but have heard this > requirement verbally at least. > > > You are making imaginary assumptions that HW should be able to process > > what was in your mind. > > That is presumptious on your part. Actually we have given this > requirement to chip vendors in our product space for about a year and > a half and I have brought this up for even longer in the MPLS WG and > more recently on PWE3. Two chip vendors have taken these requirements > to heart and will be allowing labels under GAL plus the forwarding > functionality described in draft-villamizar-mpls-tp-multipath-01. > > Of all the packet processors that we have considered, all on the very > high end of things, I know of none that have a parser that is so > inflexible that it could not deal with a label under GAL and still > find the OAM payload with nothing more than a change to the low level > programming of the parser. > > I can envision that chips do exist for which the parser is too hard > coded to accommodate such a change. Lucky for us (not luck really) > that we are not working with such a chip. Are you? > > > I strongly object to this unnecessary draft. If you look at RFCs there > > are always cases that we wished we had done it differently, but we are > > not going to change them since in most cases like this one it is too > > late. Sorry but that is the fact. > > We are implementing labels under GAL for non-TP OAM in our products > regardless of your objections. If a provider wants to use it, it will > be there. If it can also be used for PW, all the better. Its really > easy to do, so it doesn't hurt to do it. > > If a provider prefers to use CW all the time, I'm fine with that but > we still need labels under GAL for non-TP MPLS OAM. > > > Thx > > Shahram > > Curtis > > > > ----- Original Message ----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Thursday, August 04, 2011 06:38 AM > > To: Shahram Davari > > Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp= .ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > Even if we assume this format (which is not yet incorporated in the > > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > > this case how is the HW supposed to examine the ACH channel Type to > > > decide how to process the packet? (unless you assume there is one > > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > This doesn't need to go in the fat-pw draft. It needs to go into the > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > > when some other feature, fat-pw or other, puts a label under the PW > > label. The GAL goes after the PW and before the other labels. A > > proper multipath distribution will skip any reserved label and use the > > rest of the label stack to load balance. This allows spraying across > > the entropy space or testing a spacific payload label stack that has > > yielded trouble. > > > > Hardware that assumes ACH is right after GAL when the S-bit is not set > > on the GAL is broken. > > > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > > > The IETF has never been sympathetic of broken hardware and should not > > be since we would halt progress. > > > > If the hardware is broken, then the fat-pw label can be omitted but > > only one path through any multipath would be tested. It would still > > work for TP, but not work in general. PW does not require TP. The > > fat-pw work is explicitly done for multipath because multipath is used > > a lot in deployed networks and isn't going away. > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > To: Shahram Davari > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@= ietf.org; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-= 02.txt > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.co= rp.ad.broadcom.com> > > > "Shahram Davari" writes: > > > > > > > > Hi Curtis, > > > > > > > > You are absolutely correct if there is no Entropy label. But with > > > > Entropy label most implementation assume a Entropy label to be BoS = and > > > > below the PW label. > > > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > > the Entropy Label? In either case adding GAL would make the packet > > > > un-parsable by most HW. > > > > > > > > Thx > > > > Shahram > > > > > > > > > That should be covered in this work. At least it was covered in WG > > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > > from Entropy label in MPLS). > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | PW Label | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GAL | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | ... additional labels (ie: fat-pw) may be present | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | > > > ~ VCCV Message Body ~ > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The above would be a better choice. The VCCV is always after the > > > label entry with BOS (S-bit =3D 1). > > > > > > The flow label (or entropy label) must not be a reserved label. > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 sectio= n > > > 1.2 (page 5) you will find. > > > > > > Note that the flow label MUST NOT be an MPLS reserved label (value= s > > > in the range 0..15) [RFC3032], but is otherwise unconstrained by t= he > > > protocol. > > > > > > > > > The flow label below GAL is needed so that all data paths which the P= W > > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > To: Shahram Davari > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert= Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-= 2-02.txt > > > > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.= corp.ad.broadcom.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Giles, > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and u= se > > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > Shahram, > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > > hardware need not know if the label above the GAL is an MPLS label = or > > > > a PW label, just that the next label is GAL and the label over it i= s > > > > not a SWAP. Unless we are talking about incredibly inflexible pars= er > > > > hardware, like none I've encounted recently, there should be no > > > > problem noticing a GAL below the POP or PW label and then directing > > > > the packet to OAM processing. Any remaining labels must be removed > > > > and hopefully no implementation neglects to look for BOS before > > > > deciding where the payload is supposed to be. > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In t= his > > > > case TTL-expire would occur where a label swap was called for and a > > > > GAL would be below the label containing the expired TTL. Since LDP > > > > can have transient loops, this avoids having lots of packets sent t= o > > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > > > This yield one way to do OAM with or without CW. A GAL label is be= low > > > > the label for which action is taken (POP or PW termination) or belo= w a > > > > label for which TTL has expired. This method applied to LSP and PW= . > > > > > > > > I think mandating CW would be just as good a solution, but one that > > > > was rejected so this is the best we have. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > To: Thomas Nadeau; Shahram Davari > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vcc= v-2-02.txt > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis= I support > > > > > this draft. > > > > > > > > > > Sure, it'll take a while to move away from the router alert label= and TTL > > > > > approaches, but the GAL approach is definitely better than either= of > > > > > those... > > > > > > > > > > Giles > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wr= ote: > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > >> Hi, > > > > > >> > > > > > >> I also don=B9t support this draft since I don=B9t think to sol= ve the problem we > > > > > >> need yet a 4th type of VCCV. The best solution is to mandate C= W. > > > > > > > > > > > > While I am with you, that argument went out the window during t= he debates we > > > > > > had over the past 3 IETF meetings. Operators > > > > > > were very clear that they do not want to mandate the use of a C= W. Hence, > > > > > > Luca and I came up with this solution that narrows the > > > > > > scope to 2 modes, one that handles the CW case and one that doe= sn't while > > > > > > still both modes providing predictable OAM capabilities > > > > > > for the PW. > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > >> > > > > > >> Shahram > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On = Behalf Of > > > > > >> Robert Rennison > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthe= w); > > > > > >> pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-= vccv-2-02.txt > > > > > >> > > > > > >> I do Not support the draft, > > > > > >> > > > > > >> After hearing the results of the earlier user deployment poll= I thought, > > > > > >> =B3 ok the way out of this mess is to migrate towards using t= he CW=B2. Then I > > > > > >> see this proposal and wondered what am I missing. I=B9ve stil= l not seen the > > > > > >> light of why adding a fourth type will simplify matters, hence= in the absence > > > > > >> of me understanding how this will simplify matter versus compl= icate things, > > > > > >> I=B9m against it. > > > > > >> > > > > > >> Rob > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On = Behalf Of > > > > > >> Alexander Vainshtein > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-= vccv-2-02.txt > > > > > >> > > > > > >> Hi all, > > > > > >> I do NOT support this draft for the same reasons that Yaakov h= as indicated. > > > > > >> > > > > > >> Regards, > > > > > >> Sasha > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf = Of Yaakov Stein > > > > > >> [yaakov_s@rad.com] > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-= vccv-2-02.txt > > > > > >> > > > > > >> I do not support ! and I can not understand how anyone can = support it ! > > > > > >> > > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > > >> > > > > > >> I completely agree with the part that says if there is a CW th= en the ACh > > > > > >> should be marked by it. > > > > > >> > > > > > >> I do NOT agree that if the CW is not used then we should use a= non-PW method > > > > > >> developed for MPLS-TP. > > > > > >> I do NOT agree that there is any way to deprecate the use of T= TL expiry to > > > > > >> mark the ACh. > > > > > >> I do NOT agree that we should change mechanisms that have been= widely > > > > > >> deployed for many years now, > > > > > >> without an extremely pressing reason. > > > > > >> > > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-T= P to have the > > > > > >> ADDITIONAL option > > > > > >> for ACh marking, I might be convinced not to object as strongl= y. > > > > > >> However, since I don't think that PWs can be limited in this m= atter (the MPLS > > > > > >> WG adopted the "seamless" draft) > > > > > >> it would be difficult to convince me that such a limitation is= possible. > > > > > >> > > > > > >> I would have enthusiastically support this proposal had it bee= n brought 8 > > > > > >> years ago. > > > > > >> It's too late for this now. > > > > > >> > > > > > >> Y(J)S > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On = Behalf Of > > > > > >> Bocci, Matthew (Matthew) > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > >> To: pwe3@ietf.org > > > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > > > >> > > > > > >> This email begins a two week poll to help assess if there is c= onsensus to > > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group = draft. > > > > > >> > > > > > >> Please indicate whether or not you support adoption of this dr= aft, and also > > > > > >> send any comments to the PWE3 list. > > > > > >> > > > > > >> This poll will end on Friday 12th August. > > > > > >> > > > > > >> Regards, > > > > > >> > > > > > >> Matthew & Andy > > > > > >> This e-mail message is intended for the recipient only and con= tains > > > > > >> 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 original and all cop= ies thereof. > > > > > >> This e-mail message is intended for the recipient only and con= tains > > > > > >> 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 original and all cop= ies thereof. From curtis@occnc.com Thu Aug 4 19:55: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 E43CD21F866A for ; Thu, 4 Aug 2011 19:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, MANGLED_BELOW=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M02RojbdSFm for ; Thu, 4 Aug 2011 19:55:11 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 64BAA21F859F for ; Thu, 4 Aug 2011 19:55:11 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p752rtV1077256; Thu, 4 Aug 2011 22:53:56 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108050253.p752rtV1077256@harbor.orleans.occnc.com> To: Pablo Frank From: Curtis Villamizar In-reply-to: Your message of "Thu, 04 Aug 2011 14:23:39 EDT." Date: Thu, 04 Aug 2011 22:53:55 -0400 Sender: curtis@occnc.com Cc: "yaakov_s@rad.com" , "pwe3@ietf.org" , "Robert.Rennison@ecitele.com" Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 02:55:13 -0000 In message Pablo Frank writes: > > Curtis, > > Why does it matter if the entropy/flow labels are above or below the > GAL? What advantage is gained by putting such labels below the GAL? The purpose of the GAL is to drive OAM processing. On a PW only the label immediately below the GAL has to be inspected, not all labels between the PW and BOS, except to find the last label with S=0. On an LSP there may be many labels before the BOS, so every label would have to be searched for GAL on every packet. Always putting GAL below the label being acted on immediately identifies the OAM context (the label above the GAL indicates the OAM context). > To me, putting the GAL in-between the PW (or LSP) label and the Flow > (or Entropy) label just feels out of place. I should only really care > about a GAL if I encounter it as a result of disposing of the labels > either because they've been popped or because the TTL has expired. > When the PW label gets terminated and all of a sudden, I encounter a > GAL, it seems awkward because in my mind, I have not finished > terminating the PW layer. There is still this flow label that I need > to dispose of... so the hardware has to remembe= r that it saw a GAL > and continue processing labels. It seems much cleaner if we finish > dealing with the multipath labels before considering whether it's > carrying normal data or an associated channel. > > If anything, I see an advantage in having the GAL below the flow label > because it allows the option of monitoring individual paths (assuming, > of course, that GAL is excluded from the hash). You can monitor individual paths. The hash has to skip over reserved labels, not terminate on reserved labels. If you are doing this, then the position in the label stack of the GAL indicates the context of the OAM. > regards, > Pablo > > ----- Original Message ----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Thursday, August 04, 2011 06:38 AM > > To: Shahram Davari > > Cc: curtis@occnc.com ; Giles Heron < > > giles.heron@gmail.com>; Thomas Nadeau ; Yaakov > > Stein ; pwe3@ietf.org ; Robert Rennison = > < > > Robert.Rennison@ecitele.com> > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= > xt > > > > > > In message < > > 2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.c= > om > > > > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > Even if we assume this format (which is not yet incorporated in the > > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > > this case how is the HW supposed to examine the ACH channel Type to > > > decide how to process the packet? (unless you assume there is one > > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > This doesn't need to go in the fat-pw draft. It needs to go into the > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > > when some other feature, fat-pw or other, puts a label under the PW > > label. The GAL goes after the PW and before the other labels. A > > proper multipath distribution will skip any reserved label and use the > > rest of the label stack to load balance. This allows spraying across > > the entropy space or testing a spacific payload label stack that has > > yielded trouble. > > > > Hardware that assumes ACH is right after GAL when the S-bit is not set > > on the GAL is broken. > > > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > > > The IETF has never been sympathetic of broken hardware and should not > > be since we would halt progress. > > > > If the hardware is broken, then the fat-pw label can be omitted but > > only one path through any multipath would be tested. It would still > > work for TP, but not work in general. PW does not require TP. The > > fat-pw work is explicitly done for multipath because multipath is used > > a lot in deployed networks and isn't going away. > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > To: Shahram Davari > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > > pwe3@ietf.org; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message < > > 2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.c= > om > > > > > > "Shahram Davari" writes: > > > > > > > > Hi Curtis, > > > > > > > > You are absolutely correct if there is no Entropy label. But with > > > > Entropy label most implementation assume a Entropy label to be BoS an= > d > > > > below the PW label. > > > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > > the Entropy Label? In either case adding GAL would make the packet > > > > un-parsable by most HW. > > > > > > > > Thx > > > > Shahram > > > > > > > > > That should be covered in this work. At least it was covered in WG > > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > > from Entropy label in MPLS). > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | PW Label | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | GAL | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | ... additional labels (ie: fat-pw) may be present | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | > > > ~ VCCV Message Body ~ > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The above would be a better choice. The VCCV is always after the > > > label entry with BOS (S-bit =3D 1). > > > > > > The flow label (or entropy label) must not be a reserved label. > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > > > 1.2 (page 5) you will find. > > > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > > protocol. > > > > > > > > > The flow label below GAL is needed so that all data paths which the PW > > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > To: Shahram Davari > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert > > Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > In message < > > 2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.c= > om > > > > > > > "Shahram Davari" writes: > > > > > > > > > > Giles, > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > Shahram, > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > > hardware need not know if the label above the GAL is an MPLS label or > > > > a PW label, just that the next label is GAL and the label over it is > > > > not a SWAP. Unless we are talking about incredibly inflexible parser > > > > hardware, like none I've encounted recently, there should be no > > > > problem noticing a GAL below the POP or PW label and then directing > > > > the packet to OAM processing. Any remaining labels must be removed > > > > and hopefully no implementation neglects to look for BOS before > > > > deciding where the payload is supposed to be. > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In thi= > s > > > > case TTL-expire would occur where a label swap was called for and a > > > > GAL would be below the label containing the expired TTL. Since LDP > > > > can have transient loops, this avoids having lots of packets sent to > > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > > > This yield one way to do OAM with or without CW. A GAL label is belo= > w > > > > the label for which action is taken (POP or PW termination) or below = > a > > > > label for which TTL has expired. This method applied to LSP and PW. > > > > > > > > I think mandating CW would be just as good a solution, but one that > > > > was rejected so this is the best we have. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > To: Thomas Nadeau; Shahram Davari > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis I > > support > > > > > this draft. > > > > > > > > > > Sure, it'll take a while to move away from the router alert label a= > nd > > TTL > > > > > approaches, but the GAL approach is definitely better than either o= > f > > > > > those... > > > > > > > > > > Giles > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > > wrote: > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > >> Hi, > > > > > >> > > > > > >> I also don=B9t support this draft since I don=B9t think to solve= > the > > problem we > > > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > > > > > While I am with you, that argument went out the window during the > > debates we > > > > > > had over the past 3 IETF meetings. Operators > > > > > > were very clear that they do not want to mandate the use of a CW. > > Hence, > > > > > > Luca and I came up with this solution that narrows the > > > > > > scope to 2 modes, one that handles the CW case and one that doesn= > 't > > while > > > > > > still both modes providing predictable OAM capabilities > > > > > > for the PW. > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > >> > > > > > >> Shahram > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > > Behalf Of > > > > > >> Robert Rennison > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew)= > ; > > > > > >> pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> I do Not support the draft, > > > > > >> > > > > > >> After hearing the results of the earlier user deployment poll I > > thought, > > > > > >> =B3 ok the way out of this mess is to migrate towards using the > > CW=B2. Then I > > > > > >> see this proposal and wondered what am I missing. I=B9ve still = > not > > seen the > > > > > >> light of why adding a fourth type will simplify matters, hence i= > n > > the absence > > > > > >> of me understanding how this will simplify matter versus > > complicate things, > > > > > >> I=B9m against it. > > > > > >> > > > > > >> Rob > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > > Behalf Of > > > > > >> Alexander Vainshtein > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> Hi all, > > > > > >> I do NOT support this draft for the same reasons that Yaakov has > > indicated. > > > > > >> > > > > > >> Regards, > > > > > >> Sasha > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of > > Yaakov Stein > > > > > >> [yaakov_s@rad.com] > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> I do not support ! and I can not understand how anyone can > > support it ! > > > > > >> > > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > > >> > > > > > >> I completely agree with the part that says if there is a CW then > > the ACh > > > > > >> should be marked by it. > > > > > >> > > > > > >> I do NOT agree that if the CW is not used then we should use a > > non-PW method > > > > > >> developed for MPLS-TP. > > > > > >> I do NOT agree that there is any way to deprecate the use of TTL > > expiry to > > > > > >> mark the ACh. > > > > > >> I do NOT agree that we should change mechanisms that have been > > widely > > > > > >> deployed for many years now, > > > > > >> without an extremely pressing reason. > > > > > >> > > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP = > to > > have the > > > > > >> ADDITIONAL option > > > > > >> for ACh marking, I might be convinced not to object as strongly. > > > > > >> However, since I don't think that PWs can be limited in this > > matter (the MPLS > > > > > >> WG adopted the "seamless" draft) > > > > > >> it would be difficult to convince me that such a limitation is > > possible. > > > > > >> > > > > > >> I would have enthusiastically support this proposal had it been > > brought 8 > > > > > >> years ago. > > > > > >> It's too late for this now. > > > > > >> > > > > > >> Y(J)S > > > > > >> > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > > Behalf Of > > > > > >> Bocci, Matthew (Matthew) > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > >> To: pwe3@ietf.org > > > > > >> Subject: [PWE3] Poll for WG adoption of > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > >> > > > > > >> This email begins a two week poll to help assess if there is > > consensus to > > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group > > draft. > > > > > >> > > > > > >> Please indicate whether or not you support adoption of this draf= > t, > > and also > > > > > >> send any comments to the PWE3 list. > > > > > >> > > > > > >> This poll will end on Friday 12th August. > > > > > >> > > > > > >> Regards, > > > > > >> > > > > > >> Matthew & Andy > > > > > >> This e-mail message is intended for the recipient only and > > contains > > > > > >> information which is CONFIDENTIAL and which may be proprietary t= > o > > 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 copie= > s > > thereof. > > > > > >> This e-mail message is intended for the recipient only and > > contains > > > > > >> information which is CONFIDENTIAL and which may be proprietary t= > o > > 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 copie= > s > > thereof. From curtis@occnc.com Thu Aug 4 20:02: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 95DDF11E80B0 for ; Thu, 4 Aug 2011 20:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 A6LtWwiKUcfX for ; Thu, 4 Aug 2011 20:02:47 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 72BB211E809B for ; Thu, 4 Aug 2011 20:02:47 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p7531dXd077962; Thu, 4 Aug 2011 23:01:39 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108050301.p7531dXd077962@harbor.orleans.occnc.com> To: "Shahram Davari" From: Curtis Villamizar In-reply-to: Your message of "Thu, 04 Aug 2011 11:43:47 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275F6B4@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 04 Aug 2011 23:01:39 -0400 Sender: curtis@occnc.com Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 03:02:49 -0000 In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F6B4@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Hi, > > I don't remember such direction and directions should be documented in > stable IETF draft and RFCs. And in fact I think that direction is not > correct. I think GAL should be at the bottom of the stack so I like to > challenge this draft as well. > > Thx > Shahram Didn't someone on this list indicate that we should all be free to ignore any single participant in IETF. Oh - that's right - you said that. It seems that right now you are that participant. Rough consensus doesn't need to be unanimous. Curtis > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, August 04, 2011 11:38 AM > To: Shahram Davari; curtis@occnc.com > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > Shahram, > > That is the date at which it became a *working group draft*. The point that Curtis made, and with which I was agreeing, was that moving the GAL from the bottom of the stack in support of ECMP has been the direction taken by both MPLS and PWE3 for at least a year. > > John > > Sent from my iPhone > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Thursday, August 04, 2011 11:10 AM > > To: John E Drake; curtis@occnc.com > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > John, > > > > If your point is that this is mentioned in an IETF draft then please > > look at the date of the draft as well (May 5 2011). Also this draft > > applies only to MPLS tunnels and not PW. I hope you don't expect people > > to implement an IETF draft-00 which was published just 3 months ago. > > > > -Shahram > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, August 04, 2011 10:56 AM > > To: curtis@occnc.com; Shahram Davari > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > From Section 6 of the Entropy Label I-D > > (http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy- > > label/?include_text=1): > > > > "As part of the MPLS-TP work, an in-band OAM channel is defined in > > [RFC5586]. Packets sent in this channel are identified with a reserved > > label, the Generic Associated Channel Label (GAL) placed at the bottom > > of the MPLS label stack. In order to use the inband OAM channel with > > entropy labels, this memo relaxes the restriction that the GAL must be > > at the bottom of the MPLS label stack. Rather, the GAL is placed in > > the MPLS label stack above the entropy label so that it effectively > > functions as an application label." > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > > Of > > > Curtis Villamizar > > > Sent: Thursday, August 04, 2011 10:12 AM > > > To: Shahram Davari > > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > > 'Robert.Rennison@ecitele.com' > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > > 02.txt > > > > > > > > > In message > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadco > > > m.com> > > > "Shahram Davari" writes: > > > > > > > > I don't agree with you. This is not about broken HW. Before this > > > draft > > > > how was one supposed to process a packet with GAL in the middle of > > > the > > > > label stack? > > > > > > Before this draft one had to read the MPLS and PWE3 mailing list and > > > remember what was said. Getting it written in a draft is the next > > > step. > > > > > > Some of the most purist of the MPLS-TP folks have done a good job of > > > shouting down any suggestion that multipath had a valid place in any > > > network for quite some time. > > > > > > > What if this draft had decided to put GAL after entropy? Then the > > HW > > > > processing would have been completely different from what you are > > > > proposing on the fly now. > > > > > > Putting labels under GAL for the purpose of entropy was proposed on > > > MPLS mailing list for well over a year now, probably close to two > > > years, more recently on PWE3. It is reflected in other internet- > > > drafts, For example, draft-villamizar-mpls-tp-multipath-00 > > > was submitted before Maastricht but fell off the end of the agenda. > > > > > > It is also in a document that we have been giving to chip vendors > > under > > > NDA stating detailed requirements starting just under a year ago. > > > Before that is was more verbal discussion of requirements and email. > > > Your friends in another part of your company were eliminated from > > > consideration for other reasons a while back but have heard this > > > requirement verbally at least. > > > > > > > You are making imaginary assumptions that HW should be able to > > > process > > > > what was in your mind. > > > > > > That is presumptious on your part. Actually we have given this > > > requirement to chip vendors in our product space for about a year and > > a > > > half and I have brought this up for even longer in the MPLS WG and > > more > > > recently on PWE3. Two chip vendors have taken these requirements to > > > heart and will be allowing labels under GAL plus the forwarding > > > functionality described in draft-villamizar-mpls-tp-multipath-01. > > > > > > Of all the packet processors that we have considered, all on the very > > > high end of things, I know of none that have a parser that is so > > > inflexible that it could not deal with a label under GAL and still > > find > > > the OAM payload with nothing more than a change to the low level > > > programming of the parser. > > > > > > I can envision that chips do exist for which the parser is too hard > > > coded to accommodate such a change. Lucky for us (not luck really) > > > that we are not working with such a chip. Are you? > > > > > > > I strongly object to this unnecessary draft. If you look at RFCs > > > there > > > > are always cases that we wished we had done it differently, but we > > > are > > > > not going to change them since in most cases like this one it is > > too > > > > late. Sorry but that is the fact. > > > > > > We are implementing labels under GAL for non-TP OAM in our products > > > regardless of your objections. If a provider wants to use it, it > > will > > > be there. If it can also be used for PW, all the better. Its really > > > easy to do, so it doesn't hurt to do it. > > > > > > If a provider prefers to use CW all the time, I'm fine with that but > > we > > > still need labels under GAL for non-TP MPLS OAM. > > > > > > > Thx > > > > Shahram > > > > > > Curtis > > > > > > > > > > ----- Original Message ----- > > > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > > > Sent: Thursday, August 04, 2011 06:38 AM > > > > To: Shahram Davari > > > > Cc: curtis@occnc.com ; Giles Heron > > > > ; Thomas Nadeau ; > > > > Yaakov Stein ; pwe3@ietf.org ; > > > Robert > > > > Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > In message > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadc > > > > om.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Hi Curtis, > > > > > > > > > > Even if we assume this format (which is not yet incorporated in > > the > > > > > fat-pw draft), then most hardware assume ACH is right after GAL. > > In > > > > > this case how is the HW supposed to examine the ACH channel Type > > to > > > > > decide how to process the packet? (unless you assume there is one > > > > > engine that can process all OAM packet types such as BFD, AIS, > > PSC, > > > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > Shahram, > > > > > > > > This doesn't need to go in the fat-pw draft. It needs to go into > > the > > > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM > > traffic > > > > when some other feature, fat-pw or other, puts a label under the PW > > > > label. The GAL goes after the PW and before the other labels. A > > > > proper multipath distribution will skip any reserved label and use > > > the > > > > rest of the label stack to load balance. This allows spraying > > across > > > > the entropy space or testing a spacific payload label stack that > > has > > > > yielded trouble. > > > > > > > > Hardware that assumes ACH is right after GAL when the S-bit is not > > > set > > > > on the GAL is broken. > > > > > > > > The payload (ACH) is after the BOS (aka S-bit = 1). > > > > > > > > The IETF has never been sympathetic of broken hardware and should > > not > > > > be since we would halt progress. > > > > > > > > If the hardware is broken, then the fat-pw label can be omitted but > > > > only one path through any multipath would be tested. It would > > still > > > > work for TP, but not work in general. PW does not require TP. The > > > > fat-pw work is explicitly done for multipath because multipath is > > > used > > > > a lot in deployed networks and isn't going away. > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > > > To: Shahram Davari > > > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > > > > > pwe3@ietf.org; Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > In message > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa > > > > > dcom.com> > > > > > "Shahram Davari" writes: > > > > > > > > > > > > Hi Curtis, > > > > > > > > > > > > You are absolutely correct if there is no Entropy label. But > > with > > > > > > Entropy label most implementation assume a Entropy label to be > > > BoS > > > > > > and below the PW label. > > > > > > > > > > > > This draft doesn't even talk about whether the GAL should be > > BoS > > > > > > or the Entropy Label? In either case adding GAL would make the > > > > > > packet un-parsable by most HW. > > > > > > > > > > > > Thx > > > > > > Shahram > > > > > > > > > > > > > > > That should be covered in this work. At least it was covered in > > WG > > > > > email. PW, then GAL, then fat-pw (aka Flow label, which is > > > > > different from Entropy label in MPLS). > > > > > > > > > > 0 1 2 3 > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | PW Label | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | GAL | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | ... additional labels (ie: fat-pw) may be present | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | | > > > > > ~ VCCV Message Body ~ > > > > > | | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > The above would be a better choice. The VCCV is always after the > > > > > label entry with BOS (S-bit = 1). > > > > > > > > > > The flow label (or entropy label) must not be a reserved label. > > > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 > > > > > section > > > > > 1.2 (page 5) you will find. > > > > > > > > > > Note that the flow label MUST NOT be an MPLS reserved label > > > (values > > > > > in the range 0..15) [RFC3032], but is otherwise unconstrained > > by > > > the > > > > > protocol. > > > > > > > > > > > > > > > The flow label below GAL is needed so that all data paths which > > the > > > > > PW can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > > > To: Shahram Davari > > > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; > > > > > > Robert Rennison > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > > > > In message > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.br > > > > > > oadcom.com> > > > > > > "Shahram Davari" writes: > > > > > > > > > > > > > > Giles, > > > > > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW > > and > > > > > > > use VVCV Type 1? Also what is wrong with TTL approach for > > non- > > > CW? > > > > > > > > > > > > > > Thx > > > > > > > Shahram > > > > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. > > The > > > > > > hardware need not know if the label above the GAL is an MPLS > > > label > > > > > > or a PW label, just that the next label is GAL and the label > > over > > > > > > it is not a SWAP. Unless we are talking about incredibly > > > > > > inflexible parser hardware, like none I've encounted recently, > > > > > > there should be no problem noticing a GAL below the POP or PW > > > > > > label and then directing the packet to OAM processing. Any > > > > > > remaining labels must be removed and hopefully no > > implementation > > > > > > neglects to look for BOS before deciding where the payload is > > > supposed to be. > > > > > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). > > In > > > > > > this case TTL-expire would occur where a label swap was called > > > for > > > > > > and a GAL would be below the label containing the expired TTL. > > > > > > Since LDP can have transient loops, this avoids having lots of > > > > > > packets sent to the OAM engine should such a loop occur in a > > LDP > > > signaled MPLS PSN. > > > > > > > > > > > > This yield one way to do OAM with or without CW. A GAL label > > is > > > > > > below the label for which action is taken (POP or PW > > termination) > > > > > > or below a label for which TTL has expired. This method > > applied > > > to LSP and PW. > > > > > > > > > > > > I think mandating CW would be just as good a solution, but one > > > > > > that was rejected so this is the best we have. > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > > > To: Thomas Nadeau; Shahram Davari > > > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that > > > > > > > basis I support this draft. > > > > > > > > > > > > > > Sure, it'll take a while to move away from the router alert > > > > > > > label and TTL approaches, but the GAL approach is definitely > > > > > > > better than either of those... > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > > > > > >> Hi, > > > > > > > >> > > > > > > > >> I also donąt support this draft since I donąt think to > > solve > > > > > > > >> the problem we need yet a 4th type of VCCV. The best > > > solution is to mandate CW. > > > > > > > > > > > > > > > > While I am with you, that argument went out the window > > during > > > > > > > > the debates we had over the past 3 IETF meetings. Operators > > > > > > > > were very clear that they do not want to mandate the use of > > a > > > CW. Hence, > > > > > > > > Luca and I came up with this solution that narrows the > > scope > > > > > > > > to 2 modes, one that handles the CW case and one that > > doesn't > > > > > > > > while still both modes providing predictable OAM > > capabilities > > > > > > > > for the PW. > > > > > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > >> Shahram > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > > On > > > > > > > >> Behalf Of Robert Rennison > > > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew > > > > > > > >> (Matthew); pwe3@ietf.org > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> I do Not support the draft, > > > > > > > >> > > > > > > > >> After hearing the results of the earlier user deployment > > > > > > > >> poll I thought, ł ok the way out of this mess is to > > migrate > > > > > > > >> towards using the CW˛. Then I see this proposal and > > wondered > > > > > > > >> what am I missing. Iąve still not seen the light of why > > > > > > > >> adding a fourth type will simplify matters, hence in the > > > > > > > >> absence of me understanding how this will simplify matter > > > versus complicate things, Iąm against it. > > > > > > > >> > > > > > > > >> Rob > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > > On > > > > > > > >> Behalf Of Alexander Vainshtein > > > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> Hi all, > > > > > > > >> I do NOT support this draft for the same reasons that > > Yaakov > > > has indicated. > > > > > > > >> > > > > > > > >> Regards, > > > > > > > >> Sasha > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On > > > Behalf > > > > > > > >> Of Yaakov Stein [yaakov_s@rad.com] > > > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> I do not support ! and I can not understand how anyone > > > can support it ! > > > > > > > >> > > > > > > > >> We do NOT need a fourth VCCV type, there are too many > > > already. > > > > > > > >> > > > > > > > >> I completely agree with the part that says if there is a > > CW > > > > > > > >> then the ACh should be marked by it. > > > > > > > >> > > > > > > > >> I do NOT agree that if the CW is not used then we should > > use > > > > > > > >> a non-PW method developed for MPLS-TP. > > > > > > > >> I do NOT agree that there is any way to deprecate the use > > of > > > > > > > >> TTL expiry to mark the ACh. > > > > > > > >> I do NOT agree that we should change mechanisms that have > > > > > > > >> been widely deployed for many years now, without an > > > extremely > > > > > > > >> pressing reason. > > > > > > > >> > > > > > > > >> Were the proposal to be that for PWs that traverse ONLY > > > > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, I > > > > > > > >> might be convinced not to object as strongly. > > > > > > > >> However, since I don't think that PWs can be limited in > > this > > > > > > > >> matter (the MPLS WG adopted the "seamless" draft) it would > > > be > > > > > > > >> difficult to convince me that such a limitation is > > possible. > > > > > > > >> > > > > > > > >> I would have enthusiastically support this proposal had it > > > > > > > >> been brought 8 years ago. > > > > > > > >> It's too late for this now. > > > > > > > >> > > > > > > > >> Y(J)S > > > > > > > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > > On > > > > > > > >> Behalf Of Bocci, Matthew (Matthew) > > > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > > > >> To: pwe3@ietf.org > > > > > > > >> Subject: [PWE3] Poll for WG adoption of > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > >> > > > > > > > >> This email begins a two week poll to help assess if there > > is > > > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a > > PWE3 > > > working group draft. > > > > > > > >> > > > > > > > >> Please indicate whether or not you support adoption of > > this > > > > > > > >> draft, and also send any comments to the PWE3 list. > > > > > > > >> > > > > > > > >> This poll will end on Friday 12th August. > > > > > > > >> > > > > > > > >> Regards, > > > > > > > >> > > > > > > > >> Matthew & Andy > > > > > > > >> 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. From curtis@occnc.com Thu Aug 4 20:20: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 8B0DD22800F for ; Thu, 4 Aug 2011 20:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 WsnnyloL9in0 for ; Thu, 4 Aug 2011 20:20:30 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 402C122800D for ; Thu, 4 Aug 2011 20:20:30 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p753JIbL079040; Thu, 4 Aug 2011 23:19:18 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108050319.p753JIbL079040@harbor.orleans.occnc.com> To: "Shahram Davari" From: Curtis Villamizar In-reply-to: Your message of "Thu, 04 Aug 2011 12:50:42 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275F741@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 04 Aug 2011 23:19:18 -0400 Sender: curtis@occnc.com Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 03:20:32 -0000 In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F741@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > John, > > Sorry for not providing enough justification. All I wanted to point > out was that this is not a done deal so vendors march to implement it. > > Here is my justification for having GAL at the bottom of stack: > > Having reserved labels such as GAL in the middle of stack is not > elegant because the only action one has is to punt that packet to > CPU. The reason is that you can never know what is below GAL since GAL > is your terminating label. This is a huge restriction similar to what > we had with RAL label as well. However if GAL is BoS, then you could > actually process all labels before GAL and be sure there is an ACH > after GAL. If you are diagnosing a problem at a low level (inner label) PW or LSP and through management action are repeatedly putting the label stack for which trouble is occuring into on-demand OAM at the next outer label, then you can get a few labels under GAL. Those labels exist only for the load balance to isolate the same path. After a LSP POP, PW termination, or TTL expire, if the next label is GAL, it is OAM and the packet always goes up to the CPU (if there is no microprogrammable hardware to handle OAM). It shouldn't be too tough to find BOS and send only that up, but it might be better to send the label above GAL (for context), GAL, and anything below GAL. Software (or that microprogrammable engine for OAM that maybe you have and its extremely flexible but maybe some "other vendor" doesn't have) should also be capable of finding BOS. Curtis > Regards, > Shahram > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, August 04, 2011 12:27 PM > To: Shahram Davari; curtis@occnc.com > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > Shahram, > > Thanks for your comments! They are *really* incisive and helpful. > > John > > Sent from my iPhone > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Thursday, August 04, 2011 11:44 AM > > To: John E Drake; curtis@occnc.com > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > Hi, > > > > I don't remember such direction and directions should be documented in > > stable IETF draft and RFCs. And in fact I think that direction is not > > correct. I think GAL should be at the bottom of the stack so I like to > > challenge this draft as well. > > > > > > Thx > > Shahram > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, August 04, 2011 11:38 AM > > To: Shahram Davari; curtis@occnc.com > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > 02.txt > > > > Shahram, > > > > That is the date at which it became a *working group draft*. The point > > that Curtis made, and with which I was agreeing, was that moving the > > GAL from the bottom of the stack in support of ECMP has been the > > direction taken by both MPLS and PWE3 for at least a year. > > > > John > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:davari@broadcom.com] > > > Sent: Thursday, August 04, 2011 11:10 AM > > > To: John E Drake; curtis@occnc.com > > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > > 'Robert.Rennison@ecitele.com' > > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > > 02.txt > > > > > > John, > > > > > > If your point is that this is mentioned in an IETF draft then please > > > look at the date of the draft as well (May 5 2011). Also this draft > > > applies only to MPLS tunnels and not PW. I hope you don't expect > > people > > > to implement an IETF draft-00 which was published just 3 months ago. > > > > > > -Shahram > > > > > > -----Original Message----- > > > From: John E Drake [mailto:jdrake@juniper.net] > > > Sent: Thursday, August 04, 2011 10:56 AM > > > To: curtis@occnc.com; Shahram Davari > > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > > 'Robert.Rennison@ecitele.com' > > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > > > 02.txt > > > > > > From Section 6 of the Entropy Label I-D > > > (http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy- > > > label/?include_text=1): > > > > > > "As part of the MPLS-TP work, an in-band OAM channel is defined in > > > [RFC5586]. Packets sent in this channel are identified with a > > reserved > > > label, the Generic Associated Channel Label (GAL) placed at the > > bottom > > > of the MPLS label stack. In order to use the inband OAM channel with > > > entropy labels, this memo relaxes the restriction that the GAL must > > be > > > at the bottom of the MPLS label stack. Rather, the GAL is placed in > > > the MPLS label stack above the entropy label so that it effectively > > > functions as an application label." > > > > > > Sent from my iPhone > > > > > > > > > > -----Original Message----- > > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > > Behalf > > > Of > > > > Curtis Villamizar > > > > Sent: Thursday, August 04, 2011 10:12 AM > > > > To: Shahram Davari > > > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > > > 'Robert.Rennison@ecitele.com' > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv- > > 2- > > > > 02.txt > > > > > > > > > > > > In message > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadco > > > > m.com> > > > > "Shahram Davari" writes: > > > > > > > > > > I don't agree with you. This is not about broken HW. Before this > > > > draft > > > > > how was one supposed to process a packet with GAL in the middle > > of > > > > the > > > > > label stack? > > > > > > > > Before this draft one had to read the MPLS and PWE3 mailing list > > and > > > > remember what was said. Getting it written in a draft is the next > > > > step. > > > > > > > > Some of the most purist of the MPLS-TP folks have done a good job > > of > > > > shouting down any suggestion that multipath had a valid place in > > any > > > > network for quite some time. > > > > > > > > > What if this draft had decided to put GAL after entropy? Then the > > > HW > > > > > processing would have been completely different from what you are > > > > > proposing on the fly now. > > > > > > > > Putting labels under GAL for the purpose of entropy was proposed on > > > > MPLS mailing list for well over a year now, probably close to two > > > > years, more recently on PWE3. It is reflected in other internet- > > > > drafts, For example, draft-villamizar-mpls-tp-multipath-00 > > > > was submitted before Maastricht but fell off the end of the agenda. > > > > > > > > It is also in a document that we have been giving to chip vendors > > > under > > > > NDA stating detailed requirements starting just under a year ago. > > > > Before that is was more verbal discussion of requirements and > > email. > > > > Your friends in another part of your company were eliminated from > > > > consideration for other reasons a while back but have heard this > > > > requirement verbally at least. > > > > > > > > > You are making imaginary assumptions that HW should be able to > > > > process > > > > > what was in your mind. > > > > > > > > That is presumptious on your part. Actually we have given this > > > > requirement to chip vendors in our product space for about a year > > and > > > a > > > > half and I have brought this up for even longer in the MPLS WG and > > > more > > > > recently on PWE3. Two chip vendors have taken these requirements > > to > > > > heart and will be allowing labels under GAL plus the forwarding > > > > functionality described in draft-villamizar-mpls-tp-multipath-01. > > > > > > > > Of all the packet processors that we have considered, all on the > > very > > > > high end of things, I know of none that have a parser that is so > > > > inflexible that it could not deal with a label under GAL and still > > > find > > > > the OAM payload with nothing more than a change to the low level > > > > programming of the parser. > > > > > > > > I can envision that chips do exist for which the parser is too hard > > > > coded to accommodate such a change. Lucky for us (not luck really) > > > > that we are not working with such a chip. Are you? > > > > > > > > > I strongly object to this unnecessary draft. If you look at RFCs > > > > there > > > > > are always cases that we wished we had done it differently, but > > we > > > > are > > > > > not going to change them since in most cases like this one it is > > > too > > > > > late. Sorry but that is the fact. > > > > > > > > We are implementing labels under GAL for non-TP OAM in our products > > > > regardless of your objections. If a provider wants to use it, it > > > will > > > > be there. If it can also be used for PW, all the better. Its > > really > > > > easy to do, so it doesn't hurt to do it. > > > > > > > > If a provider prefers to use CW all the time, I'm fine with that > > but > > > we > > > > still need labels under GAL for non-TP MPLS OAM. > > > > > > > > > Thx > > > > > Shahram > > > > > > > > Curtis > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > > > > Sent: Thursday, August 04, 2011 06:38 AM > > > > > To: Shahram Davari > > > > > Cc: curtis@occnc.com ; Giles Heron > > > > > ; Thomas Nadeau ; > > > > > Yaakov Stein ; pwe3@ietf.org ; > > > > Robert > > > > > Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > In message > > > > > > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadc > > > > > om.com> > > > > > "Shahram Davari" writes: > > > > > > > > > > > > Hi Curtis, > > > > > > > > > > > > Even if we assume this format (which is not yet incorporated in > > > the > > > > > > fat-pw draft), then most hardware assume ACH is right after > > GAL. > > > In > > > > > > this case how is the HW supposed to examine the ACH channel > > Type > > > to > > > > > > decide how to process the packet? (unless you assume there is > > one > > > > > > engine that can process all OAM packet types such as BFD, AIS, > > > PSC, > > > > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > > > > > > > Thx > > > > > > Shahram > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > This doesn't need to go in the fat-pw draft. It needs to go into > > > the > > > > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM > > > traffic > > > > > when some other feature, fat-pw or other, puts a label under the > > PW > > > > > label. The GAL goes after the PW and before the other labels. A > > > > > proper multipath distribution will skip any reserved label and > > use > > > > the > > > > > rest of the label stack to load balance. This allows spraying > > > across > > > > > the entropy space or testing a spacific payload label stack that > > > has > > > > > yielded trouble. > > > > > > > > > > Hardware that assumes ACH is right after GAL when the S-bit is > > not > > > > set > > > > > on the GAL is broken. > > > > > > > > > > The payload (ACH) is after the BOS (aka S-bit = 1). > > > > > > > > > > The IETF has never been sympathetic of broken hardware and should > > > not > > > > > be since we would halt progress. > > > > > > > > > > If the hardware is broken, then the fat-pw label can be omitted > > but > > > > > only one path through any multipath would be tested. It would > > > still > > > > > work for TP, but not work in general. PW does not require TP. > > The > > > > > fat-pw work is explicitly done for multipath because multipath is > > > > used > > > > > a lot in deployed networks and isn't going away. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > > > > To: Shahram Davari > > > > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > > > > > > pwe3@ietf.org; Robert Rennison > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > > > > In message > > > > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa > > > > > > dcom.com> > > > > > > "Shahram Davari" writes: > > > > > > > > > > > > > > Hi Curtis, > > > > > > > > > > > > > > You are absolutely correct if there is no Entropy label. But > > > with > > > > > > > Entropy label most implementation assume a Entropy label to > > be > > > > BoS > > > > > > > and below the PW label. > > > > > > > > > > > > > > This draft doesn't even talk about whether the GAL should be > > > BoS > > > > > > > or the Entropy Label? In either case adding GAL would make > > the > > > > > > > packet un-parsable by most HW. > > > > > > > > > > > > > > Thx > > > > > > > Shahram > > > > > > > > > > > > > > > > > > That should be covered in this work. At least it was covered > > in > > > WG > > > > > > email. PW, then GAL, then fat-pw (aka Flow label, which is > > > > > > different from Entropy label in MPLS). > > > > > > > > > > > > 0 1 2 3 > > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+ > > > > > > | PW Label > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+ > > > > > > | GAL > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+ > > > > > > | ... additional labels (ie: fat-pw) may be present > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+ > > > > > > |0 0 0 1|Version| Reserved | Associated Channel Type > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+ > > > > > > | > > | > > > > > > ~ VCCV Message Body > > ~ > > > > > > | > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+ > > > > > > > > > > > > The above would be a better choice. The VCCV is always after > > the > > > > > > label entry with BOS (S-bit = 1). > > > > > > > > > > > > The flow label (or entropy label) must not be a reserved label. > > > > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 > > > > > > section > > > > > > 1.2 (page 5) you will find. > > > > > > > > > > > > Note that the flow label MUST NOT be an MPLS reserved label > > > > (values > > > > > > in the range 0..15) [RFC3032], but is otherwise > > unconstrained > > > by > > > > the > > > > > > protocol. > > > > > > > > > > > > > > > > > > The flow label below GAL is needed so that all data paths which > > > the > > > > > > PW can take are exercised by OAM (ie: LSP Ping used within > > VCCV). > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > > > > To: Shahram Davari > > > > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; > > > > > > > Robert Rennison > > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > > > > > > > In message > > > > > > > > > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.br > > > > > > > oadcom.com> > > > > > > > "Shahram Davari" writes: > > > > > > > > > > > > > > > > Giles, > > > > > > > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW > > > and > > > > > > > > use VVCV Type 1? Also what is wrong with TTL approach for > > > non- > > > > CW? > > > > > > > > > > > > > > > > Thx > > > > > > > > Shahram > > > > > > > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. > > > The > > > > > > > hardware need not know if the label above the GAL is an MPLS > > > > label > > > > > > > or a PW label, just that the next label is GAL and the label > > > over > > > > > > > it is not a SWAP. Unless we are talking about incredibly > > > > > > > inflexible parser hardware, like none I've encounted > > recently, > > > > > > > there should be no problem noticing a GAL below the POP or PW > > > > > > > label and then directing the packet to OAM processing. Any > > > > > > > remaining labels must be removed and hopefully no > > > implementation > > > > > > > neglects to look for BOS before deciding where the payload is > > > > supposed to be. > > > > > > > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). > > > In > > > > > > > this case TTL-expire would occur where a label swap was > > called > > > > for > > > > > > > and a GAL would be below the label containing the expired > > TTL. > > > > > > > Since LDP can have transient loops, this avoids having lots > > of > > > > > > > packets sent to the OAM engine should such a loop occur in a > > > LDP > > > > signaled MPLS PSN. > > > > > > > > > > > > > > This yield one way to do OAM with or without CW. A GAL label > > > is > > > > > > > below the label for which action is taken (POP or PW > > > termination) > > > > > > > or below a label for which TTL has expired. This method > > > applied > > > > to LSP and PW. > > > > > > > > > > > > > > I think mandating CW would be just as good a solution, but > > one > > > > > > > that was rejected so this is the best we have. > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > > > > To: Thomas Nadeau; Shahram Davari > > > > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that > > > > > > > > basis I support this draft. > > > > > > > > > > > > > > > > Sure, it'll take a while to move away from the router alert > > > > > > > > label and TTL approaches, but the GAL approach is > > definitely > > > > > > > > better than either of those... > > > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > > > > > > > >> Hi, > > > > > > > > >> > > > > > > > > >> I also donąt support this draft since I donąt think to > > > solve > > > > > > > > >> the problem we need yet a 4th type of VCCV. The best > > > > solution is to mandate CW. > > > > > > > > > > > > > > > > > > While I am with you, that argument went out the window > > > during > > > > > > > > > the debates we had over the past 3 IETF meetings. > > Operators > > > > > > > > > were very clear that they do not want to mandate the use > > of > > > a > > > > CW. Hence, > > > > > > > > > Luca and I came up with this solution that narrows the > > > scope > > > > > > > > > to 2 modes, one that handles the CW case and one that > > > doesn't > > > > > > > > > while still both modes providing predictable OAM > > > capabilities > > > > > > > > > for the PW. > > > > > > > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > >> Shahram > > > > > > > > >> > > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > > bounces@ietf.org] > > > > On > > > > > > > > >> Behalf Of Robert Rennison > > > > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew > > > > > > > > >> (Matthew); pwe3@ietf.org > > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > >> > > > > > > > > >> I do Not support the draft, > > > > > > > > >> > > > > > > > > >> After hearing the results of the earlier user deployment > > > > > > > > >> poll I thought, ł ok the way out of this mess is to > > > migrate > > > > > > > > >> towards using the CW˛. Then I see this proposal and > > > wondered > > > > > > > > >> what am I missing. Iąve still not seen the light of why > > > > > > > > >> adding a fourth type will simplify matters, hence in the > > > > > > > > >> absence of me understanding how this will simplify > > matter > > > > versus complicate things, Iąm against it. > > > > > > > > >> > > > > > > > > >> Rob > > > > > > > > >> > > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > > bounces@ietf.org] > > > > On > > > > > > > > >> Behalf Of Alexander Vainshtein > > > > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); > > pwe3@ietf.org > > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > >> > > > > > > > > >> Hi all, > > > > > > > > >> I do NOT support this draft for the same reasons that > > > Yaakov > > > > has indicated. > > > > > > > > >> > > > > > > > > >> Regards, > > > > > > > > >> Sasha > > > > > > > > >> > > > > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On > > > > Behalf > > > > > > > > >> Of Yaakov Stein [yaakov_s@rad.com] > > > > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > >> > > > > > > > > >> I do not support ! and I can not understand how > > anyone > > > > can support it ! > > > > > > > > >> > > > > > > > > >> We do NOT need a fourth VCCV type, there are too many > > > > already. > > > > > > > > >> > > > > > > > > >> I completely agree with the part that says if there is a > > > CW > > > > > > > > >> then the ACh should be marked by it. > > > > > > > > >> > > > > > > > > >> I do NOT agree that if the CW is not used then we should > > > use > > > > > > > > >> a non-PW method developed for MPLS-TP. > > > > > > > > >> I do NOT agree that there is any way to deprecate the > > use > > > of > > > > > > > > >> TTL expiry to mark the ACh. > > > > > > > > >> I do NOT agree that we should change mechanisms that > > have > > > > > > > > >> been widely deployed for many years now, without an > > > > extremely > > > > > > > > >> pressing reason. > > > > > > > > >> > > > > > > > > >> Were the proposal to be that for PWs that traverse ONLY > > > > > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, I > > > > > > > > >> might be convinced not to object as strongly. > > > > > > > > >> However, since I don't think that PWs can be limited in > > > this > > > > > > > > >> matter (the MPLS WG adopted the "seamless" draft) it > > would > > > > be > > > > > > > > >> difficult to convince me that such a limitation is > > > possible. > > > > > > > > >> > > > > > > > > >> I would have enthusiastically support this proposal had > > it > > > > > > > > >> been brought 8 years ago. > > > > > > > > >> It's too late for this now. > > > > > > > > >> > > > > > > > > >> Y(J)S > > > > > > > > >> > > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > > bounces@ietf.org] > > > > On > > > > > > > > >> Behalf Of Bocci, Matthew (Matthew) > > > > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > > > > >> To: pwe3@ietf.org > > > > > > > > >> Subject: [PWE3] Poll for WG adoption of > > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > >> > > > > > > > > >> This email begins a two week poll to help assess if > > there > > > is > > > > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a > > > PWE3 > > > > working group draft. > > > > > > > > >> > > > > > > > > >> Please indicate whether or not you support adoption of > > > this > > > > > > > > >> draft, and also send any comments to the PWE3 list. > > > > > > > > >> > > > > > > > > >> This poll will end on Friday 12th August. > > > > > > > > >> > > > > > > > > >> Regards, > > > > > > > > >> > > > > > > > > >> Matthew & Andy > > > > > > > > >> 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. From matthew.bocci@alcatel-lucent.com Fri Aug 5 04:11: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 D6B5B21F8B80; Fri, 5 Aug 2011 04:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.309 X-Spam-Level: X-Spam-Status: No, score=-103.309 tagged_above=-999 required=5 tests=[AWL=-2.324, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, 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 Ym0bAdtNb3xK; Fri, 5 Aug 2011 04:11:11 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8AD21F8B8C; Fri, 5 Aug 2011 04:11:09 -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 p75BBNUe021254 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 5 Aug 2011 13:11:23 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.35]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 5 Aug 2011 13:11:22 +0200 From: "Bocci, Matthew (Matthew)" To: Adrian Farrel , Stewart Bryant , The IESG Date: Fri, 5 Aug 2011 13:11:20 +0200 Thread-Topic: Request to publish draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Thread-Index: AcxTYGjeYWJIWEthTSqeodtDor49Ag== 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_CA618E6815944matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "pwe3@ietf.org" Subject: [PWE3] Request to publish 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, 05 Aug 2011 11:11:16 -0000 --_000_CA618E6815944matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt Document Shepard Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has received adequate review. The document has been through two working group last calls, and received a number of comments demonstrating that it has been reviewed by a significan= t number of WG participants. The MPLS WG was also notified of the WG last call, since this document updates RFC5586 which was produced by the MPLS WG. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. Although there were some comments during last call that expressed disagreement with the basic principle of using a GAL on PWs, or technical issues with the interaction of the GAL with ECMP and VCCV, these were resolved. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. There are a couple of minor I-D nits: one line too long and One typo in a reference. There are no formal review criteria. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split appropriately. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists and seems reasonable. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections that use a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes the requirements for using the Generic Associated Channel Label (GAL) in Pseudowires (PWs) in MPLS-TP networks, and provides an update to the description of GAL usage in [RFC5586] by removing the restriction that is imposed on using GAL for PWs especially in MPLS-TP environments. This is required to allow PWs that do not use a PW control word to be used in MPLS= -TP and for them to use the full range of MPLS-TP OAM supported by th= e G-ACh. This document is a product of the PWE3 working group. This document is STANDARDS TRACK. Working Group Summary Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Some service providers wish to use MPLS technology to replace existing transport network infrastructure, relying upon pseudowire technology is an integral component of these network convergence architectures. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF-specified PSNs. Document Quality There are no concerns with document quality. --_000_CA618E6815944matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
draft-ietf-pwe3-mpl= s-tp-gal-in-pw-01.txt

Document Shepard Write-Up


    (1.a) Who is the Docume= nt Shepherd for this document? Has the 
     =     Document Shepherd personally reviewed this version of the&nb= sp;
          document and, in particula= r, does he or she believe this 
        =   version is ready for forwarding to the IESG for publication? 

Matthew Bocci (matthew.bocci@alcatel-lucent.com)
&n= bsp;       Yes, I have reviewed the document and I believe i= t is ready for 
        forwarding to th= e IESG.


    (1.b) Has the= document had adequate review both from key WG members 
&nbs= p;         and from key non-WG members? Does the Docume= nt Shepherd have 
          any con= cerns about the depth or breadth of the reviews that 
 =         have been performed? 

        Yes, the document has received adequate r= eview. The document has
        been through = two working group last calls, and received a number 
  =       of comments demonstrating that it has been reviewed by= a significant
        number of WG participa= nts. The MPLS WG was also notified of the 
    &nb= sp;   WG last call, since this document updates RFC5586 which was = ;
        produced by the MPLS WG.
=

    (1.c) Does the Document Shepher= d have concerns that the document 
      &nbs= p;   needs more review from a particular or broader perspective, =
          e.g., security, operational c= omplexity, someone familiar with 
       = ;   AAA, internationalization or XML? 

&= nbsp;      No.


 = ;   (1.d) Does the Document Shepherd have any specific concerns or&nbs= p;
          issues with this document t= hat the Responsible Area Director 
      &nbs= p;   and/or the IESG should be aware of? For example, perhaps he =
          or she is uncomfortable with = certain parts of the document, or 
      &nbs= p;   has concerns whether there really is a need for it. In any <= /div>
          event, if the WG has discussed= those issues and has indicated 
       =   that it still wishes to advance the document, detail those 
          concerns here. Has an IPR disclo= sure related to this document 
        &= nbsp; been filed? If so, please include a reference to the 
=           disclosure and summarize the WG discussi= on and conclusion on 
          thi= s issue. 

       No speci= fic concerns. 


    (= 1.e) How solid is the WG consensus behind this document? Does it 
          represent the strong concurrence o= f a few individuals, with 
         = ; others being silent, or does the WG as a whole understand and 
=
          agree with it? 

=
      I am comfortable that the document represen= ts WG consensus and has
      been reviewed by a r= easonable number of active WG participants. 
    &= nbsp; Although there were some comments during last call that expressed
      disagreement with the basic principle of using = a GAL on PWs, or
     technical issues with the in= teraction of the GAL with ECMP and VCCV,
     thes= e were resolved.
 

    (1= .f) Has anyone threatened an appeal or otherwise indicated extreme 
          discontent? If so, please summar= ise the areas of conflict in 
        &n= bsp; separate email messages to the Responsible Area Director. (It 
          should be in a separate email be= cause this questionnaire is 
        &nb= sp; entered into the ID Tracker.) 

  &nb= sp;    None indicated.


&n= bsp;   (1.g) Has the Document Shepherd personally verified that the&nb= sp;
          document satisfies all ID = nits? (See 
          http://www.ie= tf.org/ID-Checklist.html and 
        &n= bsp; http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
          not enough; this check needs to b= e thorough. Has the document 
        &n= bsp; met all formal review criteria it needs to, such as the MIB 
          Doctor, media type and URI type re= views? 


      &= nbsp;Yes. There are a couple of minor I-D nits: one line too long and =
       One typo in a reference. There are no= formal review criteria.

    (1.h) Has t= he document split its references into normative and 
  =         informative? Are there normative references to = documents that 
          are not r= eady for advancement or are otherwise in an unclear 
  =         state? If such normative references exist, what= is the 
          strategy for the= ir completion? Are there normative references 
   =       that are downward references, as described in [RFC396= 7]? If 
          so, list these do= wnward references to support the Area 
      =     Director in the Last Call procedure for them [RFC3967]. =

      Yes, the references are spli= t appropriately. 



    (1.i) Has the Document Shepherd verified that the document= IANA 
          consideration sect= ion exists and is consistent with the body 
    &n= bsp;     of the document? If the document specifies protocol = ;
          extensions, are reservations= requested in appropriate IANA 
        =   registries? Are the IANA registries clearly identified? If 
          the document creates a new regist= ry, does it define the 
          p= roposed initial contents of the registry and an allocation 
=           procedure for future registrations? Does= it suggest a 
          reasonable= name for the new registry? See [RFC5226]. If the 
  &n= bsp;       document describes an Expert Review process has S= hepherd 
          conferred with t= he Responsible Area Director so that the IESG 
   =       can appoint the needed Expert during the IESG Evaluat= ion? 

      The IANA considera= tions section exists and seems reasonable.


    (1.j) Has the Document Shepherd verified that section= s of the 
          document that a= re written in a formal language, such as XML 
    =       code, BNF rules, MIB definitions, etc., validate corre= ctly in 
          an automated che= cker? 

      There are no sect= ions that use a formal language.


&n= bsp;   (1.k) The IESG approval announcement includes a Document <= /div>
          Announcement Write-Up. Please = provide such a Document 
          = Announcement Write-Up? Recent examples can be found in the
 =         "Action" announcements for approved documents.= The approval 
          announceme= nt contains the following sections: 

Technica= l Summary

          This = document describes the requirements for using the Generic 
&= nbsp;         Associated Channel Label (GAL) in Pseudow= ires (PWs) in MPLS-TP
          networks, and prov= ides an update to the description of GAL usage 
   = ;       in [RFC5586] by removing the restriction that is imp= osed on using 
          GAL for PW= s especially in MPLS-TP environments. This is required 
&nbs= p;         to allow PWs that do not use a PW control wo= rd to be used in MPLS-TP 
         = and for them to use the full range of MPLS-TP OAM supported by the G-ACh.<= /div>

          This document i= s a product of the PWE3 working group.

  &nbs= p;       This document is STANDARDS TRACK.

Working Group Summary

   Network= transport service providers and their users are
   see= king to rationalize their networks by migrating their
  &nbs= p;existing services and platforms onto IP or MPLS enabled
  =  IP packet switched networks (PSN). This migration requires
=    communications services that can emulate the essential
   properties of traditional communications links over a PSN.<= /div>
   Some service providers wish to use MPLS technology t= o
   replace existing transport network infrastructure,= relying
   upon pseudowire technology is an integral c= omponent of
   these network convergence architectures.=

   Pseudowire Emulation Edge to Edge (P= WE3) will specify the
   encapsulation, transport, cont= rol, management, interworking
   and security of servic= es emulated over IETF-specified PSNs.

Document Qua= lity

   There are no concerns with docum= ent quality.


--_000_CA618E6815944matthewboccialcatellucentcom_-- From stbryant@cisco.com Fri Aug 5 06:51: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 12B5821F8BB7 for ; Fri, 5 Aug 2011 06:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.252 X-Spam-Level: X-Spam-Status: No, score=-110.252 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhiZ2YHD26Pa for ; Fri, 5 Aug 2011 06:51:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B8B3C21F8BB1 for ; Fri, 5 Aug 2011 06:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2196; q=dns/txt; s=iport; t=1312552281; x=1313761881; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=3BvSzydbR6+ah9M29lpKVpbcT4n98Q4gE/pbV2QJ5E8=; b=WR1du0cSotryJoIEBfOFjcHElW7liIJaBqk9UkKaa9arnw/xgn2ErEtp xrsUnouTWE8iezkDml434zZLHtsbb9jpLGbP0gJ1F4y2TOK4jwwIkZfnU jvLVLptijDiJo3EYq7OhoTLtT8XVviFgDWzWo2lgRrxyrme+c27qOrdo/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADX1O06Q/khR/2dsb2JhbAAoGqdid4FZAQIBIkABPBYYAwIBAgFLAQwBBwEBHodPI6AtAYMcDwGbSIZGBJMBkGho X-IronPort-AV: E=Sophos;i="4.67,323,1309737600"; d="scan'208";a="107065254" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2011 13:51:04 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p75Dp3Gw019357; Fri, 5 Aug 2011 13:51:03 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p75DowM4010158; Fri, 5 Aug 2011 14:51:00 +0100 (BST) Message-ID: <4E3BF542.1000204@cisco.com> Date: Fri, 05 Aug 2011 14:50:58 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: pwe3 , "pwe3-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PWE3] RFC4717 Figure 12 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 13:51:11 -0000 I have been dealing with Errata 999 I got down to issue 11(a) which I have moved into Errata 2921 http://www.rfc-editor.org/errata_search.php?eid=2921 I concerns Fig 12 and order of the U.E.C bits The AAL5 transparent VCC service is OPTIONAL. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN Transport Header (As Required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pseudowire Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Resvd | Optional Sequence Number |M|V| Res |U|E|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | " | | AAL5 CPCS-PDU | | (n * 48 bytes) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: AAL5 transparent service encapsulation I then looked at Figure 8.1/Y1412 AAL type 5 PDU encapsulation which looks as follows 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ Transport Label (4 Octets) +-+-+-+-+-+-+-+-+ Interworking Label (4 Octets) +-+-+-+-+-+-+-+-+ 0 0| Leng Ind +-+-+-+-+-+-+-+-+ Sequence Number (2 Octets) +-+-+-+-+-+-+-+-+ M V| res |A E C +-+-+-+-+-+-+-+-+ where A=AUU, E = EFCI, C=CLP Originally I was going to confirm that the bits were in the right order. However I am now confused by the contradiction between the 0000/Reserved in Fig 12 of RFC4717 and the 00/Len in Figure 8.1/Y1412 Am I comparing the correct figures? If so which is correct? Does anyone have a shipping implementation of PDU mode as defined in either of these specifications, if so what do you think the bit order should be? - Stewart From amalis@gmail.com Fri Aug 5 07:51:36 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 3DB9921F8C31 for ; Fri, 5 Aug 2011 07:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 dkpP5VmaVnY4 for ; Fri, 5 Aug 2011 07:51:35 -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 42E8021F8C49 for ; Fri, 5 Aug 2011 07:51:35 -0700 (PDT) Received: by fxe6 with SMTP id 6so3606863fxe.31 for ; Fri, 05 Aug 2011 07:51:52 -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=exG/Of7T2vwu4LovsW43jcN7CiDJKxcUOU9/7lzbEno=; b=flq10gaZwo3rnBvH3DDALTqe4mqv6mQDs1OKddHBuehEQ/UstqifJUcdinUCy262uG XGpaZSZ87bc+YoWITdmy2OKCVrI3BQl56ra0FYIsct+XecDfDY8iUG0X736pmARcFCQ6 uHmCzzVvwRVGuq2OS1KWki5FKyjYzIU8oe0x4= Received: by 10.204.120.138 with SMTP id d10mr723410bkr.280.1312555912225; Fri, 05 Aug 2011 07:51:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.23.82 with HTTP; Fri, 5 Aug 2011 07:51:32 -0700 (PDT) In-Reply-To: <4E3BF542.1000204@cisco.com> References: <4E3BF542.1000204@cisco.com> From: "Andrew G. Malis" Date: Fri, 5 Aug 2011 10:51:32 -0400 Message-ID: To: stbryant@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] RFC4717 Figure 12 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, 05 Aug 2011 14:51:36 -0000 Stewart, I believe that all is well. Errata 2921 complains about the apparent inconsistency between the control words in figures 10 and 12 in RFC 4717. However, there really is no inconsistency, because the two figures are encapsulating different things. Let's look at Figure 12 first. Figure 12 describes the encapsulation of AAL5 PDUs. When you compare figure 12 (as you did) with Figure 8.1/Y.1412, you'll see that the "|M|V| Res |U|E|C|" bits in figure 12 exactly matches the octet in the AAL5 header just before the payload. So when encapsulating, once can just copy the octet from the AAL5 PDU to the control word. So that's all fine. By comparison, figure 10 describes the encapsulation of ATM cells. The errata complains that the control words in figures 12 and 10 are inconsistent. Well, they're not meant to be consistent, since the PTI and C fields in the control word in figure 10 are from the ATM cell header, not the AAL5 header, which is the source of the bits in the control word in figure 12. What's more, figure 10 is also consistent with figures 5, 7, 8, and 9. So in my opinion, this errata is unconfirmed. Cheers, Andy On Fri, Aug 5, 2011 at 9:50 AM, Stewart Bryant wrote: > I have been dealing with Errata 999 > > I got down to issue 11(a) which I have moved into > Errata 2921 > > http://www.rfc-editor.org/errata_search.php?eid=3D2921 > > I concerns Fig 12 and order of the U.E.C bits > > =A0The AAL5 transparent VCC service is OPTIONAL. > > =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 > =A0 =A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 PSN Transport Header (As Required) =A0 = =A0 =A0 =A0 =A0 =A0 =A0| > =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Pseudowire Header =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =A0 |0 0 0 0| Resvd | =A0 Optional Sequence Number =A0 =A0|M|V| Res |U|E|= C| > =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0AAL5 CPCS-PDU =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(n * 48 bytes) =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > =A0 =A0 =A0 =A0 =A0 =A0 Figure 12: AAL5 transparent service encapsulation > > > I then looked at Figure 8.1/Y1412 AAL type 5 PDU encapsulation > which looks as follows > > > > =A0 =A00 1 2 3 4 5 6 7 > =A0 +-+-+-+-+-+-+-+-+ > =A0 Transport Label (4 Octets) > =A0 +-+-+-+-+-+-+-+-+ > =A0 Interworking Label (4 Octets) > =A0 +-+-+-+-+-+-+-+-+ > =A0 =A00 0| Leng Ind > =A0 +-+-+-+-+-+-+-+-+ > =A0 Sequence Number (2 Octets) > =A0 +-+-+-+-+-+-+-+-+ > =A0 =A0M V| res |A E C > =A0 +-+-+-+-+-+-+-+-+ > > where A=3DAUU, E =3D EFCI, C=3DCLP > > Originally I was going to confirm that the bits were in the > right order. However I am now confused by the contradiction > between the 0000/Reserved in Fig 12 of RFC4717 and the 00/Len in > Figure 8.1/Y1412 > > > Am I comparing the correct figures? > > If so which is correct? > > Does anyone have a shipping implementation of PDU mode as > defined in either of these specifications, if so what do you > think the bit order should be? > > > - Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From giles.heron@gmail.com Fri Aug 5 08:15: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 32F0821F8C28 for ; Fri, 5 Aug 2011 08:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.053 X-Spam-Level: X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_13=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 fvg-HpY1EAfS for ; Fri, 5 Aug 2011 08:15:50 -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 2A00221F8C09 for ; Fri, 5 Aug 2011 08:15:49 -0700 (PDT) Received: by wwe5 with SMTP id 5so2042017wwe.13 for ; Fri, 05 Aug 2011 08:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=n8LTajqmFJsdHWGYirYTFmNKfGdFWFrRhnIi9C75Wts=; b=iPfC0gy0DRmnZf5THfL10JL9wjDQ0v2iYVpZ10wWfmSzG5BeSLF3V/j7WMZ3hR5748 G2zMTCS/5hldDgJw3O7TqZ7L1/CvdjFoVu2Y20ihk356M5Td74+liSzMA/ulD41Q8VmS rLRky//yKrQVRCVgD7X2YxfwVGxwKDPs3sdHM= Received: by 10.227.10.67 with SMTP id o3mr1957528wbo.26.1312557366362; Fri, 05 Aug 2011 08:16:06 -0700 (PDT) Received: from [10.55.83.194] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fe4sm2367354wbb.45.2011.08.05.08.16.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 08:16:05 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 05 Aug 2011 16:18:06 +0100 From: Giles Heron To: , pwe3 , "pwe3-chairs@tools.ietf.org" Message-ID: Thread-Topic: [PWE3] RFC4717 Figure 12 Thread-Index: AcxTguA/0l0wEvFI6Eq68BAXjXXxmQ== In-Reply-To: <4E3BF542.1000204@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [PWE3] RFC4717 Figure 12 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, 05 Aug 2011 15:15:51 -0000 Looks like a strange one to me. The length field in the original PWE control word was added so that PWEs could carry packets of less than 46 bytes (including the label stack and control word) which get padded when carried over MPLSoE trunks. Without the length field there would be no way to know what was PWE payload and what was padding (this issue doesn't arise with IPoMPLS because the IP header has a length field). The reason for the 6 bit length field is simply because 2^5 < 46 < 2^6. In the case of ATM AAL5 PDUs (as opposed to SDUs) this problem doesn't occur, as the PDU is N * 48 bytes and so the packet must always be at least 56 bytes long (PW label plus CW plus PDU with N==1). On that basis I'd say Y1412 is incorrect. Not that the PDU mode ever made much sense to me ;) Giles On 05/08/2011 14:50, "Stewart Bryant" wrote: > I have been dealing with Errata 999 > > I got down to issue 11(a) which I have moved into > Errata 2921 > > http://www.rfc-editor.org/errata_search.php?eid=2921 > > I concerns Fig 12 and order of the U.E.C bits > > The AAL5 transparent VCC service is OPTIONAL. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PSN Transport Header (As Required) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Pseudowire Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Resvd | Optional Sequence Number |M|V| Res |U|E|C| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | " | > | AAL5 CPCS-PDU | > | (n * 48 bytes) | > | " | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: AAL5 transparent service encapsulation > > > I then looked at Figure 8.1/Y1412 AAL type 5 PDU encapsulation > which looks as follows > > > > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > Transport Label (4 Octets) > +-+-+-+-+-+-+-+-+ > Interworking Label (4 Octets) > +-+-+-+-+-+-+-+-+ > 0 0| Leng Ind > +-+-+-+-+-+-+-+-+ > Sequence Number (2 Octets) > +-+-+-+-+-+-+-+-+ > M V| res |A E C > +-+-+-+-+-+-+-+-+ > > where A=AUU, E = EFCI, C=CLP > > Originally I was going to confirm that the bits were in the > right order. However I am now confused by the contradiction > between the 0000/Reserved in Fig 12 of RFC4717 and the 00/Len in > Figure 8.1/Y1412 > > > Am I comparing the correct figures? > > If so which is correct? > > Does anyone have a shipping implementation of PDU mode as > defined in either of these specifications, if so what do you > think the bit order should be? > > > - Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From pabloisnot@gmail.com Fri Aug 5 09:01: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 F3B4921F8C13; Fri, 5 Aug 2011 09:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_91=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 oD8tA0+kmsZF; Fri, 5 Aug 2011 09:01:17 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4194021F8C09; Fri, 5 Aug 2011 09:01:17 -0700 (PDT) Received: by qyk35 with SMTP id 35so1559247qyk.10 for ; Fri, 05 Aug 2011 09:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hD8kkXmHVe3sDHGIMzWO1jwUcxF1WriKXqz7/q/z+20=; b=JuQrrWVGqJh3C7Xfzu3eplO6CqjPLxeOpquKcpFqPpNeXRNibHjmtvpoHqFoVeOiI3 vN+3wNJY7QyQU9iQmu0zU1rVtYPGmpCWFeUMWbbtMnkbj/eA01JeZKUSje5Wn/TYzRqO KK9d7iEmsDHSqp0Gqij34N8L4c2lwsl2tZKNI= MIME-Version: 1.0 Received: by 10.224.199.9 with SMTP id eq9mr2005369qab.81.1312560094757; Fri, 05 Aug 2011 09:01:34 -0700 (PDT) Received: by 10.224.11.143 with HTTP; Fri, 5 Aug 2011 09:01:34 -0700 (PDT) In-Reply-To: <5E893DB832F57341992548CDBB333163A0AC0CCDD1@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0AC0CCDD1@EMBX01-HQ.jnpr.net> Date: Fri, 5 Aug 2011 12:01:34 -0400 Message-ID: From: Pablo Frank To: John E Drake Content-Type: multipart/alternative; boundary=20cf300fb4c531c28704a9c43684 Cc: mpls@ietf.org, "yaakov_s@rad.com" , "pwe3@ietf.org" , "Robert.Rennison@ecitele.com" Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 05 Aug 2011 16:01:20 -0000 --20cf300fb4c531c28704a9c43684 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So I read the draft but could not see the justification. In fact, I believ= e there's actually a flaw with what's proposed. Section 6 (OAM and Entropy Labels) suggests that by setting S=3D0 and placi= ng the GAL above the entropy label, that this makes it "effectively function a= s an application label". But this is not so. The GAL is an extra label that would normally sit below the application label. Application labels that ar= e expecting entropy labels are identified in your proposal either explicitly in the LFIB or implicitly by the presence of an ELI after the AL. In eithe= r case, it's the label(s) above the GAL that trigger entropy label handling, not the GAL itself. Then following the procedures in 4.3, the Egress LSR would inspect the S bi= t of the application/ELI label, and according to the text, would then pop the next label, assuming it was an entropy label. Unfortunately, you've now popped the GAL and what's really left is the entropy label. It seems to me that we've gotten here because the GAL and Entropy label bot= h want to be the BOS. You've tried to get around it by relaxing the BOS restriction on GAL but I think it works much more cleanly if you go the other way. Instead of saying that Entropy labels always need to be BOS, wh= y not simply say that they must immediately follow the application/ELI label? That way, the procedures in 4.3 always work trivially. A router that does not understand or expect entropy labels doesn't need to be confused by strange labels following the GAL, and the hardware implementations likely will be simpler (and cheaper). It also means I can build hierarchical multipath LSPs if I really want to... :-) regards, Pablo On Thu, Aug 4, 2011 at 2:36 PM, John E Drake wrote: > Pablo,**** > > ** ** > > At least wrt entropy label, the reasons why it needs to be at the bottom = of > stack are detailed in the draft in some detail. The GAL is in exactly th= e > same place in the stack relative to the labels above it whether or not th= e > entropy label is used. The fact that the bottom of stack bit is not set = in > the GAL tells the egress that an entropy label is present in the stack af= ter > it and needs to be discarded.l **** > > ** ** > > Thanks,**** > > ** ** > > John **** > > ** ** > > Sent from my iPhone**** > > ** ** > > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On Behalf O= f > *Pablo Frank > *Sent:* Thursday, August 04, 2011 11:24 AM > *To:* curtis@occnc.com > *Cc:* yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitele.com > *Subject:* Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt)**** > > ** ** > > Curtis,**** > > ** ** > > Why does it matter if the entropy/flow labels are above or below the GAL? > What advantage is gained by putting such labels below the GAL?**** > > ** ** > > To me, putting the GAL in-between the PW (or LSP) label and the Flow (or > Entropy) label just feels out of place. I should only really care about = a > GAL if I encounter it as a result of disposing of the labels either becau= se > they've been popped or because the TTL has expired. When the PW label ge= ts > terminated and all of a sudden, I encounter a GAL, it seems awkward becau= se > in my mind, I have not finished terminating the PW layer. There is still > this flow label that I need to dispose of... so the hardware has to remem= ber > that it saw a GAL and continue processing labels. It seems much cleaner = if > we finish dealing with the multipath labels before considering whether it= 's > carrying normal data or an associated channel. **** > > ** ** > > If anything, I see an advantage in having the GAL below the flow label > because it allows the option of monitoring individual paths (assuming, of > course, that GAL is excluded from the hash).**** > > ** ** > > regards,**** > > Pablo**** > > ** ** > > ----- Original Message ----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: Thursday, August 04, 2011 06:38 AM > To: Shahram Davari > Cc: curtis@occnc.com ; Giles Heron < > giles.heron@gmail.com>; Thomas Nadeau ; Yaakov > Stein ; pwe3@ietf.org ; Robert Rennison = < > Robert.Rennison@ecitele.com> > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > > > In message < > 2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.c= om > > > "Shahram Davari" writes: > > > > Hi Curtis, > > > > Even if we assume this format (which is not yet incorporated in the > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > this case how is the HW supposed to examine the ACH channel Type to > > decide how to process the packet? (unless you assume there is one > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > Thx > > Shahram > > > Shahram, > > This doesn't need to go in the fat-pw draft. It needs to go into the > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > when some other feature, fat-pw or other, puts a label under the PW > label. The GAL goes after the PW and before the other labels. A > proper multipath distribution will skip any reserved label and use the > rest of the label stack to load balance. This allows spraying across > the entropy space or testing a spacific payload label stack that has > yielded trouble. > > Hardware that assumes ACH is right after GAL when the S-bit is not set > on the GAL is broken. > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > The IETF has never been sympathetic of broken hardware and should not > be since we would halt progress. > > If the hardware is broken, then the fat-pw label can be omitted but > only one path through any multipath would be tested. It would still > work for TP, but not work in general. PW does not require TP. The > fat-pw work is explicitly done for multipath because multipath is used > a lot in deployed networks and isn't going away. > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, August 03, 2011 4:53 PM > > To: Shahram Davari > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > pwe3@ietf.org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > In message < > 2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.c= om > > > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > You are absolutely correct if there is no Entropy label. But with > > > Entropy label most implementation assume a Entropy label to be BoS an= d > > > below the PW label. > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > the Entropy Label? In either case adding GAL would make the packet > > > un-parsable by most HW. > > > > > > Thx > > > Shahram > > > > > > That should be covered in this work. At least it was covered in WG > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > from Entropy label in MPLS). > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PW Label | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GAL | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ... additional labels (ie: fat-pw) may be present | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ VCCV Message Body ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > The above would be a better choice. The VCCV is always after the > > label entry with BOS (S-bit =3D 1). > > > > The flow label (or entropy label) must not be a reserved label. > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > > 1.2 (page 5) you will find. > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > protocol. > > > > > > The flow label below GAL is needed so that all data paths which the PW > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > To: Shahram Davari > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert > Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message < > 2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.c= om > > > > > "Shahram Davari" writes: > > > > > > > > Giles, > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > Thx > > > > Shahram > > > > > > > > > Shahram, > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > hardware need not know if the label above the GAL is an MPLS label or > > > a PW label, just that the next label is GAL and the label over it is > > > not a SWAP. Unless we are talking about incredibly inflexible parser > > > hardware, like none I've encounted recently, there should be no > > > problem noticing a GAL below the POP or PW label and then directing > > > the packet to OAM processing. Any remaining labels must be removed > > > and hopefully no implementation neglects to look for BOS before > > > deciding where the payload is supposed to be. > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In thi= s > > > case TTL-expire would occur where a label swap was called for and a > > > GAL would be below the label containing the expired TTL. Since LDP > > > can have transient loops, this avoids having lots of packets sent to > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > This yield one way to do OAM with or without CW. A GAL label is belo= w > > > the label for which action is taken (POP or PW termination) or below = a > > > label for which TTL has expired. This method applied to LSP and PW. > > > > > > I think mandating CW would be just as good a solution, but one that > > > was rejected so this is the best we have. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > To: Thomas Nadeau; Shahram Davari > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis I > support > > > > this draft. > > > > > > > > Sure, it'll take a while to move away from the router alert label a= nd > TTL > > > > approaches, but the GAL approach is definitely better than either o= f > > > > those... > > > > > > > > Giles > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > wrote: > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I also don=B9t support this draft since I don=B9t think to solve= the > problem we > > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > > > While I am with you, that argument went out the window during the > debates we > > > > > had over the past 3 IETF meetings. Operators > > > > > were very clear that they do not want to mandate the use of a CW. > Hence, > > > > > Luca and I came up with this solution that narrows the > > > > > scope to 2 modes, one that handles the CW case and one that doesn= 't > while > > > > > still both modes providing predictable OAM capabilities > > > > > for the PW. > > > > > > > > > > --Tom > > > > > > > > > > > > > > >> > > > > >> Shahram > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of > > > > >> Robert Rennison > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew)= ; > > > > >> pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> I do Not support the draft, > > > > >> > > > > >> After hearing the results of the earlier user deployment poll I > thought, > > > > >> =B3 ok the way out of this mess is to migrate towards using the > CW=B2. Then I > > > > >> see this proposal and wondered what am I missing. I=B9ve still = not > seen the > > > > >> light of why adding a fourth type will simplify matters, hence i= n > the absence > > > > >> of me understanding how this will simplify matter versus > complicate things, > > > > >> I=B9m against it. > > > > >> > > > > >> Rob > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of > > > > >> Alexander Vainshtein > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> Hi all, > > > > >> I do NOT support this draft for the same reasons that Yaakov has > indicated. > > > > >> > > > > >> Regards, > > > > >> Sasha > > > > >> > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of > Yaakov Stein > > > > >> [yaakov_s@rad.com] > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> I do not support ! and I can not understand how anyone can > support it ! > > > > >> > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > >> > > > > >> I completely agree with the part that says if there is a CW then > the ACh > > > > >> should be marked by it. > > > > >> > > > > >> I do NOT agree that if the CW is not used then we should use a > non-PW method > > > > >> developed for MPLS-TP. > > > > >> I do NOT agree that there is any way to deprecate the use of TTL > expiry to > > > > >> mark the ACh. > > > > >> I do NOT agree that we should change mechanisms that have been > widely > > > > >> deployed for many years now, > > > > >> without an extremely pressing reason. > > > > >> > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP = to > have the > > > > >> ADDITIONAL option > > > > >> for ACh marking, I might be convinced not to object as strongly. > > > > >> However, since I don't think that PWs can be limited in this > matter (the MPLS > > > > >> WG adopted the "seamless" draft) > > > > >> it would be difficult to convince me that such a limitation is > possible. > > > > >> > > > > >> I would have enthusiastically support this proposal had it been > brought 8 > > > > >> years ago. > > > > >> It's too late for this now. > > > > >> > > > > >> Y(J)S > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of > > > > >> Bocci, Matthew (Matthew) > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > >> To: pwe3@ietf.org > > > > >> Subject: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> This email begins a two week poll to help assess if there is > consensus to > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group > draft. > > > > >> > > > > >> Please indicate whether or not you support adoption of this draf= t, > and also > > > > >> send any comments to the PWE3 list. > > > > >> > > > > >> This poll will end on Friday 12th August. > > > > >> > > > > >> Regards, > > > > >> > > > > >> Matthew & Andy > > > > >> This e-mail message is intended for the recipient only and > contains > > > > >> information which is CONFIDENTIAL and which may be proprietary t= o > 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 copie= s > thereof. > > > > >> This e-mail message is intended for the recipient only and > contains > > > > >> information which is CONFIDENTIAL and which may be proprietary t= o > 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 copie= s > thereof. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3**** > > ** ** > --20cf300fb4c531c28704a9c43684 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So I read the draft but could not see the justification. =A0In fact,= =A0I believe there's actually a flaw with what's proposed. =A0

Section 6 (OAM and Entropy Labels) suggests that by setting = S=3D0 and placing the GAL above the entropy label, that this makes it "= ;effectively function as an application label". =A0But this is not so.= =A0The GAL is an extra label that would normally sit below the application= label. =A0Application labels that are expecting entropy labels are identif= ied in your proposal either explicitly in the LFIB or implicitly by the pre= sence of an ELI after the AL. =A0In either case, it's the label(s) abov= e the GAL that trigger entropy label handling, not the GAL itself.

Then following the procedures in 4.3, the Egress LSR would i= nspect the S bit of the application/ELI label, and according to the text, w= ould then pop the next label, assuming it was an entropy label. =A0Unfortun= ately, you've now popped the GAL and what's really left is the entr= opy label.

It seems to me that we've gotten here because the G= AL and Entropy label both want to be the BOS. =A0You've tried to get ar= ound it by relaxing the BOS restriction on GAL but I think it works much mo= re cleanly if you go the other way. =A0Instead of saying that Entropy label= s always need to be BOS, why not simply say that they must immediately foll= ow the application/ELI label? =A0That way, the procedures in 4.3 always wor= k trivially. =A0A router that does not understand or expect entropy labels = doesn't need to be confused by strange labels following the GAL, and th= e hardware implementations likely will be simpler (and cheaper). =A0It also= means I can build=A0hierarchical=A0multipath LSPs if I really want to... := -)

regards,
Pablo

On Thu, Aug 4, 2011 at 2:36 PM, John E Drake <jdrake@juniper.net> wrote:

Pablo,

=A0

At le= ast wrt entropy label, the reasons why it needs to be at the bottom of stac= k are detailed in the draft in some detail.=A0 The GAL is in exactly the sa= me place in the stack relative to the labels above it whether or not the en= tropy label is used.=A0 The fact that the bottom of stack bit is not set in= the GAL tells the egress that an entropy label is present in the stack aft= er it and needs to be discarded.l=A0

=A0

Thanks,

=A0

John =

=A0

Sent from my iPhone

=A0

From:= pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf= Of Pablo Frank
Sent: Thursday, August 04, 2011 11:24 AM
To: curtis@occnc.com
Cc:= yaakov_s@rad.com= ; pwe3@ietf.org; Robert.Rennis= on@ecitele.com
Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption o= f draft-nadeau-pwe3-vccv-2-02.txt)

=A0

Curtis,

=A0

Why does it matter if the entropy/flow labels are above or below th= e GAL? =A0What advantage is gained by putting such labels below the GAL?=

=A0

To me, putting the GAL in-between the PW (or LSP) label and = the Flow (or Entropy) label just feels out of place. =A0I should only reall= y care about a GAL if I encounter it as a result of disposing of the labels= either because they've been popped or because the TTL has expired. =A0= When the PW label gets terminated and all of a sudden, I encounter a GAL, i= t seems awkward because in my mind, I have not finished terminating the PW = layer. =A0There is still this flow label that I need to dispose of... so th= e hardware has to remember that it saw a GAL and continue processing labels= . =A0It seems much cleaner if we finish dealing with the multipath labels b= efore considering whether it's carrying normal data or an associated ch= annel. =A0

=A0

If anything, I see an advantage in having the GAL below the = flow label because it allows the option of monitoring individual paths (ass= uming, of course, that GAL is excluded from the hash).

=A0

regards,

= Pablo

=A0<= /p>

----- Original Message -----
From: Curtis Villami= zar [mailto:curtis@oc= cnc.com]
Sent: Thursday, August 04, 2011 06:38 AM
To: Shahram Dav= ari
Cc: curtis@occnc.com<= /a> <curtis@occnc.= com>; Giles Heron <giles.heron@gmail.com>; Thomas Nadeau <tnadeau@lucidvision.com= >; Yaakov Stein <yaakov_s@rad.com>; pwe3@ietf.org <pwe3@ietf.org>; Robert Rennison <Robert.Rennison@ecitele.com>
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt=


In message <2C2F1EBA80= 50E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes:
>
> Hi Curtis,
>
&g= t; Even if we assume this format (which is not yet incorporated in the
&= gt; fat-pw draft), then most hardware assume ACH is right after GAL. In
> this case how is the HW supposed to examine the ACH channel Type to> decide how to process the packet? (unless you assume there is one
= > engine that can process all OAM packet types such as BFD, AIS, PSC, > LSP-ping, LDI, LKR, LM, DM, etc)
>
> Thx
> Shahram

Shahram,

This doesn't need to go in the fat-pw draft. = =A0It needs to go into the
draft-nadeau-pwe3-vccv-2-02 draft because it = only affects OAM traffic
when some other feature, fat-pw or other, puts a label under the PW
labe= l. =A0The GAL goes after the PW and before the other labels. =A0A
proper= multipath distribution will skip any reserved label and use the
rest of= the label stack to load balance. =A0This allows spraying across
the entropy space or testing a spacific payload label stack that has
yie= lded trouble.

Hardware that assumes ACH is right after GAL when the = S-bit is not set
on the GAL is broken.

The payload (ACH) is after= the BOS (aka S-bit =3D 1).

The IETF has never been sympathetic of broken hardware and should notbe since we would halt progress.

If the hardware is broken, then t= he fat-pw label can be omitted but
only one path through any multipath w= ould be tested. =A0It would still
work for TP, but not work in general. =A0PW does not require TP. =A0The
= fat-pw work is explicitly done for multipath because multipath is used
a= lot in deployed networks and isn't going away.

Curtis

> -----Original Message-----
> From: curtis@occnc.com [mailto:curtis@occnc.com]
> Sent: Wednes= day, August 03, 2011 4:53 PM
> To: Shahram Davari
> Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Ste= in; pwe3@ietf.org; R= obert Rennison
> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-0= 2.txt
>
>
> In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa= dcom.com>
> "Shahram Davari" writes:
> >
> > Hi Curtis= ,
> >
> > You are absolutely correct if there is no Entro= py label. But with
> > Entropy label most implementation assume a = Entropy label to be BoS and
> > below the PW label.
> >
> > This draft doesn= 9;t even talk about whether the GAL should be BoS or
> > the Entro= py Label? In either case adding GAL would make the packet
> > un-p= arsable by most HW.
> >
> > Thx
> > Shahram
>
>
> Tha= t should be covered in this work. =A0At least it was covered in WG
> = email. =A0PW, then GAL, then fat-pw (aka Flow label, which is different
> from Entropy label in MPLS).
>
> 0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4= 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PW Label =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> +-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GAL =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&= gt; | =A0 =A0 ... additional labels (ie: fat-pw) may be present =A0 =A0 =A0= =A0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
> |0 0 0 1|Version| =A0 Reserved =A0 =A0| =A0Associated Channel Type =A0= =A0 =A0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> ~ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0VCCV Message Body =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0~
> | =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> The above would be a better choice. =A0The VCCV is always afte= r the
> label entry with BOS (S-bit =3D 1).
>
> The flow = label (or entropy label) must not be a reserved label.
> Therefore th= ere is no ambiguity. =A0In draft-ietf-pwe3-fat-pw-07 section
> 1.2 (page 5) you will find.
>
> =A0 =A0Note that the flow = label MUST NOT be an MPLS reserved label (values
> =A0 =A0in the rang= e 0..15) [RFC3032], but is otherwise unconstrained by the
> =A0 =A0pr= otocol.
>
>
> The flow label below GAL is needed so that all data pa= ths which the PW
> can take are exercised by OAM (ie: LSP Ping used w= ithin VCCV).
>
> Curtis
>
>
> > -----Origi= nal Message-----
> > From: curti= s@occnc.com [mailto:curtis@occnc.com]
> > Sent: Wednesday, August 03, 2011 4:05= PM
> > To: Shahram Davari
> > Cc: Giles Heron; Thomas Nadeau; Y= aakov Stein; pwe3@ietf.o= rg; Robert Rennison
> > Subject: Re: [PWE3] Poll for WG adopti= on of draft-nadeau-pwe3-vccv-2-02.txt
> >
> >
> > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.a= d.broadcom.com>
> > "Shahram Davari" writes:
> > >
> >= > Giles,
> > >
> > > Adding GAL to PW requires = HW change, so why not just add CW and use
> > > VVCV Type 1? = =A0Also what is wrong with TTL approach for non-CW?
> > >
> > > Thx
> > > Shahram
> >=
> >
> > Shahram,
> >
> > Adding GAL to= an MPLS label stack requires hardware support. =A0The
> > hardwar= e need not know if the label above the GAL is an MPLS label or
> > a PW label, just that the next label is GAL and the label over it= is
> > not a SWAP. =A0Unless we are talking about incredibly infl= exible parser
> > hardware, like none I've encounted recently,= there should be no
> > problem noticing a GAL below the POP or PW label and then directi= ng
> > the packet to OAM processing. =A0Any remaining labels must = be removed
> > and hopefully no implementation neglects to look fo= r BOS before
> > deciding where the payload is supposed to be.
> >
>= ; > TTL is best reserved for traceroute only (in the MS-PW case). =A0In = this
> > case TTL-expire would occur where a label swap was called= for and a
> > GAL would be below the label containing the expired TTL. =A0Since= LDP
> > can have transient loops, this avoids having lots of pack= ets sent to
> > the OAM engine should such a loop occur in a LDP s= ignaled MPLS PSN.
> >
> > This yield one way to do OAM with or without CW. =A0= A GAL label is below
> > the label for which action is taken (POP = or PW termination) or below a
> > label for which TTL has expired.= =A0This method applied to LSP and PW.
> >
> > I think mandating CW would be just as good a solutio= n, but one that
> > was rejected so this is the best we have.
&= gt; >
> > Curtis
> >
> >
> > > --= ---Original Message-----
> > > From: Giles Heron [mailto:giles.heron@gmail.com]
> > > Sent:= Wednesday, August 03, 2011 11:10 AM
> > > To: Thomas Nadeau; S= hahram Davari
> > > Cc: pwe3@= ietf.org; Yaakov Stein; Robert Rennison
> > > Subject: Re: = [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
> >= >
> > > Agreed - some operators won't want to use a CW, and on t= hat basis I support
> > > this draft.
> > >
>= > > Sure, it'll take a while to move away from the router alert = label and TTL
> > > approaches, but the GAL approach is definitely better than e= ither of
> > > those...
> > >
> > > Gil= es
> > >
> > > On 02/08/2011 12:59, "Thomas Na= deau" <tnadeau@lucidvision.com> wrote:
> > >
> > > >
> > > > On Aug 1, 2011= , at 6:28 PM, Shahram Davari wrote:
> > > >
> > >= ; >> Hi,
> > > >>
> > > >> I also= don=B9t support this draft since I don=B9t think to solve the problem we > > > >> need yet a 4th type of VCCV. The best solution is t= o mandate CW.
> > > >
> > > > While I am with= you, that argument went out the window during the debates we
> > = > > had over the past 3 IETF meetings. Operators
> > > > were very clear that they do not want to mandate the us= e of a CW. =A0 Hence,
> > > > Luca and I came up with this s= olution that narrows the
> > > > scope to 2 modes, one that = handles the CW case and one that doesn't while
> > > > still both modes providing predictable OAM capabilities=
> > > > for the PW.
> > > >
> > >= ; > --Tom
> > > >
> > > >
> > >= ; >>
> > > >> Shahram
> > > >>
> > >= ; >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> > > >> Robert Rennison
> > > >> Sent: Su= nday, July 31, 2011 7:40 PM
> > > >> To: Alexander Vainsh= tein; Yaakov Stein; Bocci, Matthew (Matthew);
> > > >> pwe3@ietf.org
> > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-n= adeau-pwe3-vccv-2-02.txt
> > > >>
> > > >&= gt; I do Not support the draft,
> > > >>
> > >= ; >> After hearing the results of the earlier user deployment =A0poll= I thought,
> > > >> =B3 ok =A0the way out of this mess is to migrate to= wards using the CW=B2. Then I
> > > >> see this proposal = and wondered what am I missing. =A0I=B9ve still not seen the
> > &= gt; >> light of why adding a fourth type will simplify matters, hence= in the absence
> > > >> of me understanding how this will simplify matter v= ersus complicate things,
> > > >> I=B9m against it.
&g= t; > > >>
> > > >> Rob
> > > >= >
> > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
= > > > >> Alexander Vainshtein
> > > >> Sent: Sunday, July 31, 2011 12:45 AM
> > &= gt; >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org
> > > >&g= t; Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt
> > > >>
> > > >> Hi all,
> > >= ; >> I do NOT support this draft for the same reasons that Yaakov has= indicated.
> > > >>
> > > >> Regards,<= br> > > > >> =A0 =A0 =A0Sasha
> > > >>
>= > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein=
> > > >> [yaakov_s@rad.com]
> > > >> Sent: Friday, July 29,= 2011 3:58 AM
> > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org
> > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-n= adeau-pwe3-vccv-2-02.txt
> > > >>
> > > >&= gt; I do not support ! =A0 =A0and I can not understand how anyone can suppo= rt it !
> > > >>
> > > >> We do NOT need a fourth = VCCV type, there are too many already.
> > > >>
> &= gt; > >> I completely agree with the part that says if there is a = CW then the ACh
> > > >> should be marked by it.
> > > >><= br>> > > >> I do NOT agree that if the CW is not used then w= e should use a non-PW method
> > > >> developed for MPLS-= TP.
> > > >> I do NOT agree that there is any way to deprecate t= he use of TTL expiry to
> > > >> mark the ACh.
> &g= t; > >> I do NOT agree that we should change mechanisms that have = been widely
> > > >> deployed for many years now,
> > > >= > without an extremely pressing reason.
> > > >>
&g= t; > > >> Were the proposal to be that for PWs that traverse ON= LY MPLS-TP to have the
> > > >> ADDITIONAL option
> > > >> for AC= h marking, I might be convinced not to object as strongly.
> > >= ; >> However, since I don't think that PWs can be limited in this= matter (the MPLS
> > > >> WG adopted the "seamless" draft)
> = > > >> it would be difficult to convince me that such a limitat= ion is possible.
> > > >>
> > > >> I wo= uld have enthusiastically support this proposal had it been brought 8
> > > >> years ago.
> > > >> It's too = late for this now.
> > > >>
> > > >> Y(= J)S
> > > >>
> > > >> From: pwe3-bounces@ietf.org [= mailto:pwe3-boun= ces@ietf.org] On Behalf Of
> > > >> Bocci, Matthew (Matthew)
> > > >>= Sent: Thursday, July 28, 2011 21:02
> > > >> To: pwe3@ietf.org
> > = > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vcc= v-2-02.txt
> > > >>
> > > >> This email begins a two = week poll to help assess if there is consensus to
> > > >>= ; adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft.
> > > >>
> > > >> Please indicate whether = or not you support adoption of this draft, and also
> > > >&= gt; send any comments to the PWE3 list.
> > > >>
> = > > >> This poll will end on Friday 12th August.
> > > >>
> > > >> Regards,
> > &g= t; >>
> > > >> Matthew & Andy
> > >= >> This e-mail message is intended for the recipient only and contai= ns
> > > >> 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 o= nly and contains
> > > >> information which is CONFIDENTI= AL 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
ht= tps://www.ietf.org/mailman/listinfo/pwe3

=

=A0

<= /blockquote>

--20cf300fb4c531c28704a9c43684-- From jdrake@juniper.net Fri Aug 5 09:51: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 EC3E721F8C19; Fri, 5 Aug 2011 09:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.77 X-Spam-Level: X-Spam-Status: No, score=-5.77 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_91=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 U2MKJZYrUe8G; Fri, 5 Aug 2011 09:51:36 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id E6C3A21F8C10; Fri, 5 Aug 2011 09:51:33 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTjwfovE7XRIZ+bd2OD9bFNrJbBm6S86/@postini.com; Fri, 05 Aug 2011 09:51:53 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 5 Aug 2011 09:50:59 -0700 From: John E Drake To: Pablo Frank Date: Fri, 5 Aug 2011 09:50:54 -0700 Thread-Topic: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) Thread-Index: AcxTiPbD+gKW3hbGTQSlR4kHi+3gdgABY8fA Message-ID: <5E893DB832F57341992548CDBB333163A0AC0CD79C@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0AC0CCDD1@EMBX01-HQ.jnpr.net> 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_5E893DB832F57341992548CDBB333163A0AC0CD79CEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "yaakov_s@rad.com" , "pwe3@ietf.org" , "Robert.Rennison@ecitele.com" Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 05 Aug 2011 16:51:46 -0000 --_000_5E893DB832F57341992548CDBB333163A0AC0CD79CEMBX01HQjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An application label is a label in which you expect to see BOS set but whic= h isn't, followed by an entropy label which is a non-reserved label with BO= S set. Repeat as necessary. As both Curtis and I have said, in order to process the GAL payload correct= ly, the stack above the GAL should be the same whether or not an entropy la= bel is present. Sent from my iPhone From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Friday, August 05, 2011 9:02 AM To: John E Drake Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecit= ele.com; mpls@ietf.org Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) So I read the draft but could not see the justification. In fact, I believ= e there's actually a flaw with what's proposed. Section 6 (OAM and Entropy Labels) suggests that by setting S=3D0 and placi= ng the GAL above the entropy label, that this makes it "effectively functio= n as an application label". But this is not so. The GAL is an extra label= that would normally sit below the application label. Application labels t= hat are expecting entropy labels are identified in your proposal either exp= licitly in the LFIB or implicitly by the presence of an ELI after the AL. = In either case, it's the label(s) above the GAL that trigger entropy label = handling, not the GAL itself. Then following the procedures in 4.3, the Egress LSR would inspect the S bi= t of the application/ELI label, and according to the text, would then pop t= he next label, assuming it was an entropy label. Unfortunately, you've now= popped the GAL and what's really left is the entropy label. It seems to me that we've gotten here because the GAL and Entropy label bot= h want to be the BOS. You've tried to get around it by relaxing the BOS re= striction on GAL but I think it works much more cleanly if you go the other= way. Instead of saying that Entropy labels always need to be BOS, why not= simply say that they must immediately follow the application/ELI label? T= hat way, the procedures in 4.3 always work trivially. A router that does n= ot understand or expect entropy labels doesn't need to be confused by stran= ge labels following the GAL, and the hardware implementations likely will b= e simpler (and cheaper). It also means I can build hierarchical multipath = LSPs if I really want to... :-) regards, Pablo On Thu, Aug 4, 2011 at 2:36 PM, John E Drake > wrote: Pablo, At least wrt entropy label, the reasons why it needs to be at the bottom of= stack are detailed in the draft in some detail. The GAL is in exactly the= same place in the stack relative to the labels above it whether or not the= entropy label is used. The fact that the bottom of stack bit is not set i= n the GAL tells the egress that an entropy label is present in the stack af= ter it and needs to be discarded.l Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Pablo Frank Sent: Thursday, August 04, 2011 11:24 AM To: curtis@occnc.com Cc: yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitele.com Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) Curtis, Why does it matter if the entropy/flow labels are above or below the GAL? = What advantage is gained by putting such labels below the GAL? To me, putting the GAL in-between the PW (or LSP) label and the Flow (or En= tropy) label just feels out of place. I should only really care about a GA= L if I encounter it as a result of disposing of the labels either because t= hey've been popped or because the TTL has expired. When the PW label gets = terminated and all of a sudden, I encounter a GAL, it seems awkward because= in my mind, I have not finished terminating the PW layer. There is still = this flow label that I need to dispose of... so the hardware has to remembe= r that it saw a GAL and continue processing labels. It seems much cleaner = if we finish dealing with the multipath labels before considering whether i= t's carrying normal data or an associated channel. If anything, I see an advantage in having the GAL below the flow label beca= use it allows the option of monitoring individual paths (assuming, of cours= e, that GAL is excluded from the hash). regards, Pablo ----- Original Message ----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 06:38 AM To: Shahram Davari Cc: curtis@occnc.com >; Giles Heron >; Thomas Nadeau >; Yaakov Stein >; pwe3@ietf.o= rg >; Robert Renn= ison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.= broadcom.com> "Shahram Davari" writes: > > Hi Curtis, > > Even if we assume this format (which is not yet incorporated in the > fat-pw draft), then most hardware assume ACH is right after GAL. In > this case how is the HW supposed to examine the ACH channel Type to > decide how to process the packet? (unless you assume there is one > engine that can process all OAM packet types such as BFD, AIS, PSC, > LSP-ping, LDI, LKR, LM, DM, etc) > > Thx > Shahram Shahram, This doesn't need to go in the fat-pw draft. It needs to go into the draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic when some other feature, fat-pw or other, puts a label under the PW label. The GAL goes after the PW and before the other labels. A proper multipath distribution will skip any reserved label and use the rest of the label stack to load balance. This allows spraying across the entropy space or testing a spacific payload label stack that has yielded trouble. Hardware that assumes ACH is right after GAL when the S-bit is not set on the GAL is broken. The payload (ACH) is after the BOS (aka S-bit =3D 1). The IETF has never been sympathetic of broken hardware and should not be since we would halt progress. If the hardware is broken, then the fat-pw label can be omitted but only one path through any multipath would be tested. It would still work for TP, but not work in general. PW does not require TP. The fat-pw work is explicitly done for multipath because multipath is used a lot in deployed networks and isn't going away. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com<= mailto:curtis@occnc.com>] > Sent: Wednesday, August 03, 2011 4:53 PM > To: Shahram Davari > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau= ; Yaakov Stein; pwe3@ietf.org; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.a= d.broadcom.com> > "Shahram Davari" writes: > > > > Hi Curtis, > > > > You are absolutely correct if there is no Entropy label. But with > > Entropy label most implementation assume a Entropy label to be BoS and > > below the PW label. > > > > This draft doesn't even talk about whether the GAL should be BoS or > > the Entropy Label? In either case adding GAL would make the packet > > un-parsable by most HW. > > > > Thx > > Shahram > > > That should be covered in this work. At least it was covered in WG > email. PW, then GAL, then fat-pw (aka Flow label, which is different > from Entropy label in MPLS). > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GAL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... additional labels (ie: fat-pw) may be present | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|Version| Reserved | Associated Channel Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ VCCV Message Body ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The above would be a better choice. The VCCV is always after the > label entry with BOS (S-bit =3D 1). > > The flow label (or entropy label) must not be a reserved label. > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > 1.2 (page 5) you will find. > > Note that the flow label MUST NOT be an MPLS reserved label (values > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > protocol. > > > The flow label below GAL is needed so that all data paths which the PW > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.co= m] > > Sent: Wednesday, August 03, 2011 4:05 PM > > To: Shahram Davari > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp= .ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Giles, > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > Adding GAL to an MPLS label stack requires hardware support. The > > hardware need not know if the label above the GAL is an MPLS label or > > a PW label, just that the next label is GAL and the label over it is > > not a SWAP. Unless we are talking about incredibly inflexible parser > > hardware, like none I've encounted recently, there should be no > > problem noticing a GAL below the POP or PW label and then directing > > the packet to OAM processing. Any remaining labels must be removed > > and hopefully no implementation neglects to look for BOS before > > deciding where the payload is supposed to be. > > > > TTL is best reserved for traceroute only (in the MS-PW case). In this > > case TTL-expire would occur where a label swap was called for and a > > GAL would be below the label containing the expired TTL. Since LDP > > can have transient loops, this avoids having lots of packets sent to > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > This yield one way to do OAM with or without CW. A GAL label is below > > the label for which action is taken (POP or PW termination) or below a > > label for which TTL has expired. This method applied to LSP and PW. > > > > I think mandating CW would be just as good a solution, but one that > > was rejected so this is the best we have. > > > > Curtis > > > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > To: Thomas Nadeau; Shahram Davari > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Renniso= n > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-= 02.txt > > > > > > Agreed - some operators won't want to use a CW, and on that basis I s= upport > > > this draft. > > > > > > Sure, it'll take a while to move away from the router alert label and= TTL > > > approaches, but the GAL approach is definitely better than either of > > > those... > > > > > > Giles > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > wrote: > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > >> Hi, > > > >> > > > >> I also don=B9t support this draft since I don=B9t think to solve t= he problem we > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > While I am with you, that argument went out the window during the d= ebates we > > > > had over the past 3 IETF meetings. Operators > > > > were very clear that they do not want to mandate the use of a CW. = Hence, > > > > Luca and I came up with this solution that narrows the > > > > scope to 2 modes, one that handles the CW case and one that doesn't= while > > > > still both modes providing predictable OAM capabilities > > > > for the PW. > > > > > > > > --Tom > > > > > > > > > > > >> > > > >> Shahram > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:= pwe3-bounces@ietf.org] On Behalf Of > > > >> Robert Rennison > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > > > >> pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >> > > > >> I do Not support the draft, > > > >> > > > >> After hearing the results of the earlier user deployment poll I t= hought, > > > >> =B3 ok the way out of this mess is to migrate towards using the C= W=B2. Then I > > > >> see this proposal and wondered what am I missing. I=B9ve still no= t seen the > > > >> light of why adding a fourth type will simplify matters, hence in = the absence > > > >> of me understanding how this will simplify matter versus complicat= e things, > > > >> I=B9m against it. > > > >> > > > >> Rob > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:= pwe3-bounces@ietf.org] On Behalf Of > > > >> Alexander Vainshtein > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >> > > > >> Hi all, > > > >> I do NOT support this draft for the same reasons that Yaakov has i= ndicated. > > > >> > > > >> Regards, > > > >> Sasha > > > >> > > > >> From: pwe3-bounces@ietf.org [pwe3-bo= unces@ietf.org] On Behalf Of Yaakov Stein > > > >> [yaakov_s@rad.com] > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >> > > > >> I do not support ! and I can not understand how anyone can supp= ort it ! > > > >> > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > >> > > > >> I completely agree with the part that says if there is a CW then t= he ACh > > > >> should be marked by it. > > > >> > > > >> I do NOT agree that if the CW is not used then we should use a non= -PW method > > > >> developed for MPLS-TP. > > > >> I do NOT agree that there is any way to deprecate the use of TTL e= xpiry to > > > >> mark the ACh. > > > >> I do NOT agree that we should change mechanisms that have been wid= ely > > > >> deployed for many years now, > > > >> without an extremely pressing reason. > > > >> > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to= have the > > > >> ADDITIONAL option > > > >> for ACh marking, I might be convinced not to object as strongly. > > > >> However, since I don't think that PWs can be limited in this matte= r (the MPLS > > > >> WG adopted the "seamless" draft) > > > >> it would be difficult to convince me that such a limitation is pos= sible. > > > >> > > > >> I would have enthusiastically support this proposal had it been br= ought 8 > > > >> years ago. > > > >> It's too late for this now. > > > >> > > > >> Y(J)S > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:= pwe3-bounces@ietf.org] On Behalf Of > > > >> Bocci, Matthew (Matthew) > > > >> Sent: Thursday, July 28, 2011 21:02 > > > >> To: pwe3@ietf.org > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-0= 2.txt > > > >> > > > >> This email begins a two week poll to help assess if there is conse= nsus to > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draf= t. > > > >> > > > >> Please indicate whether or not you support adoption of this draft,= and also > > > >> send any comments to the PWE3 list. > > > >> > > > >> This poll will end on Friday 12th August. > > > >> > > > >> Regards, > > > >> > > > >> Matthew & Andy > > > >> This e-mail message is intended for the recipient only and contain= s > > > >> information which is CONFIDENTIAL and which may be proprietary to = ECI > > > >> Telecom. If you have received this transmission in error, please i= nform 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 contain= s > > > >> information which is CONFIDENTIAL and which may be proprietary to = ECI > > > >> Telecom. If you have received this transmission in error, please i= nform 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 --_000_5E893DB832F57341992548CDBB333163A0AC0CD79CEMBX01HQjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

An applic= ation label is a label in which you expect to see BOS set but which isnR= 17;t, followed by an entropy label which is a non-reserved label with BOS s= et.=A0 Repeat as necessary.

 

As both Curtis an= d I have said, in order to process the GAL payload correctly, the stack abo= ve the GAL should be the same whether or not an entropy label is present.

 

Sent from my iPhone

 

<= p class=3DMsoNormal>From: Pablo Frank [mailto:pabloisnot@gmail.com]
Se= nt: Friday, August 05, 2011 9:02 AM
To: John E Drake
Cc= : curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ec= itele.com; mpls@ietf.org
Subject: Re: [PWE3] Entropy/Flow and GAL= (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt)

 

So I read the draft but could not see the justification. &nbs= p;In fact, I believe there's actually a flaw with what's proposed. &nb= sp;

 

Section 6 (OAM and Entropy Labels) suggests that by s= etting S=3D0 and placing the GAL above the entropy label, that this makes i= t "effectively function as an application label".  But this = is not so.  The GAL is an extra label that would normally sit below th= e application label.  Application labels that are expecting entropy la= bels are identified in your proposal either explicitly in the LFIB or impli= citly by the presence of an ELI after the AL.  In either case, it's th= e label(s) above the GAL that trigger entropy label handling, not the GAL i= tself.

 

<= div>

Then following the procedures in 4.3, the Egress L= SR would inspect the S bit of the application/ELI label, and according to t= he text, would then pop the next label, assuming it was an entropy label. &= nbsp;Unfortunately, you've now popped the GAL and what's really left is the= entropy label.

 

It seems to me that we've gotten he= re because the GAL and Entropy label both want to be the BOS.  You've = tried to get around it by relaxing the BOS restriction on GAL but I think i= t works much more cleanly if you go the other way.  Instead of saying = that Entropy labels always need to be BOS, why not simply say that they mus= t immediately follow the application/ELI label?  That way, the procedu= res in 4.3 always work trivially.  A router that does not understand o= r expect entropy labels doesn't need to be confused by strange labels follo= wing the GAL, and the hardware implementations likely will be simpler (and = cheaper).  It also means I can build hierarchical multipath = LSPs if I really want to... :-)

 

regards,=

Pablo

 

On Thu, Au= g 4, 2011 at 2:36 PM, John E Drake <jdrake@juniper.net> wrote:

Pablo,

<= span style=3D'font-size:11.0pt;color:#1F497D'> 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>At least wrt entropy l= abel, the reasons why it needs to be at the bottom of stack are detailed in= the draft in some detail.  The GAL is in exactly the same place in th= e stack relative to the labels above it whether or not the entropy label is= used.  The fact that the bottom of stack bit is not set in the GAL te= lls the egress that an entropy label is present in the stack after it and n= eeds to be discarded.l 

 

Thanks,

<= span style=3D'font-size:11.0pt;color:#1F497D'> 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>John

 

Sent from= my iPhone

 

From: pwe3-bounces@= ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Pablo Frank
Sent:= Thursday, August 04, 2011 11:24 AM
To: curtis@occnc.com
Cc: yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecite= le.com
Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for= WG adoption of draft-nadeau-pwe3-vccv-2-02.txt)

 

Curtis,

 

Why does it matter if the entropy/f= low labels are above or below the GAL?  What advantage is gained by pu= tting such labels below the GAL?

 

To me, putting the GAL in-between the PW (or L= SP) label and the Flow (or Entropy) label just feels out of place.  I = should only really care about a GAL if I encounter it as a result of dispos= ing of the labels either because they've been popped or because the TTL has= expired.  When the PW label gets terminated and all of a sudden, I en= counter a GAL, it seems awkward because in my mind, I have not finished ter= minating the PW layer.  There is still this flow label that I need to = dispose of... so the hardware has to remember that it saw a GAL and continu= e processing labels.  It seems much cleaner if we finish dealing with = the multipath labels before considering whether it's carrying normal data o= r an associated channel.  

 =

If anything, I see an advantage in having the G= AL below the flow label because it allows the option of monitoring individu= al paths (assuming, of course, that GAL is excluded from the hash).

 

regards,

Pablo

 <= o:p>

----- Original Message -----
Fro= m: Curtis Villamizar [mailto:curtis@occnc.com]
Sent: Thursday, August 04, 2011 06:38 AMTo: Shahram Davari
Cc: curtis@occnc.com <curtis@occnc.com>; Giles Heron <giles.heron@gmail.com>; Thomas= Nadeau <tn= adeau@lucidvision.com>; Yaakov Stein <yaakov_s@rad.com>; pwe3@ietf.org <pwe3@ietf.org>; Robert Rennison <Robert.Rennison= @ecitele.com>
Subject: Re: [PWE3] Poll for WG adoption of draft-n= adeau-pwe3-vccv-2-02.txt


In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.a= d.broadcom.com>
"Shahram Davari" writes:
>
>= ; Hi Curtis,
>
> Even if we assume this format (which is not ye= t incorporated in the
> fat-pw draft), then most hardware assume ACH = is right after GAL. In
> this case how is the HW supposed to examine = the ACH channel Type to
> decide how to process the packet? (unless y= ou assume there is one
> engine that can process all OAM packet types= such as BFD, AIS, PSC,
> LSP-ping, LDI, LKR, LM, DM, etc)
>> Thx
> Shahram


Shahram,

This doesn't need to g= o in the fat-pw draft.  It needs to go into the
draft-nadeau-pwe3-v= ccv-2-02 draft because it only affects OAM traffic
when some other featu= re, fat-pw or other, puts a label under the PW
label.  The GAL goes= after the PW and before the other labels.  A
proper multipath dist= ribution will skip any reserved label and use the
rest of the label stac= k to load balance.  This allows spraying across
the entropy space o= r testing a spacific payload label stack that has
yielded trouble.
Hardware that assumes ACH is right after GAL when the S-bit is not seton the GAL is broken.

The payload (ACH) is after the BOS (aka S-bit= =3D 1).

The IETF has never been sympathetic of broken hardware and = should not
be since we would halt progress.

If the hardware is br= oken, then the fat-pw label can be omitted but
only one path through any= multipath would be tested.  It would still
work for TP, but not wo= rk in general.  PW does not require TP.  The
fat-pw work is ex= plicitly done for multipath because multipath is used
a lot in deployed = networks and isn't going away.

Curtis


> -----Original = Message-----
> From: curtis@occnc.com [mailto:curtis@occnc.com]
> Sent: Wednesday, August 03, 201= 1 4:53 PM
> To: Shahram Davari
> Cc: curtis@occnc.com; Giles Heron; Thomas Nadea= u; Yaakov Stein; pwe3@ie= tf.org; Robert Rennison
> Subject: Re: [PWE3] Poll for WG adoptio= n of draft-nadeau-pwe3-vccv-2-02.txt
>
>
> In message <= ;2C2F1EBA8050E74EA81502D5740B4BD6A932= 75F0F9@SJEXCHCCR02.corp.ad.broadcom.com>
> "Shahram Davar= i" writes:
> >
> > Hi Curtis,
> >
> &= gt; You are absolutely correct if there is no Entropy label. But with
&g= t; > Entropy label most implementation assume a Entropy label to be BoS = and
> > below the PW label.
> >
> > This draft d= oesn't even talk about whether the GAL should be BoS or
> > the En= tropy Label? In either case adding GAL would make the packet
> > u= n-parsable by most HW.
> >
> > Thx
> > Shahram>
>
> That should be covered in this work.  At least = it was covered in WG
> email.  PW, then GAL, then fat-pw (aka Fl= ow label, which is different
> from Entropy label in MPLS).
>> 0                   1 &= nbsp;                 2   &nbs= p;               3
> 0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |     &= nbsp;                    =  PW Label                 &nb= sp;         |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |         &nbs= p;                    GAL=                     &nbs= p;        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |     ... additional label= s (ie: fat-pw) may be present         |
> +-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |0 0 0 1= |Version|   Reserved    |  Associated Channel Type &nbs= p;    |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
> |              =                     &nbs= p;                     &n= bsp;     |
> ~             &n= bsp;          VCCV Message Body     &nbs= p;                ~
> |  = ;                     &nb= sp;                     &= nbsp;                 |
> +-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
&= gt; The above would be a better choice.  The VCCV is always after the<= br>> label entry with BOS (S-bit =3D 1).
>
> The flow label = (or entropy label) must not be a reserved label.
> Therefore there is= no ambiguity.  In draft-ietf-pwe3-fat-pw-07 section
> 1.2 (page= 5) you will find.
>
>    Note that the flow label MU= ST NOT be an MPLS reserved label (values
>    in the range = 0..15) [RFC3032], but is otherwise unconstrained by the
>   &nbs= p;protocol.
>
>
> The flow label below GAL is needed so t= hat all data paths which the PW
> can take are exercised by OAM (ie: = LSP Ping used within VCCV).
>
> Curtis
>
>
> = > -----Original Message-----
> > From: curtis@occnc.com [mailto:curtis@occnc.com]
> > Se= nt: Wednesday, August 03, 2011 4:05 PM
> > To: Shahram Davari
&= gt; > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison
> &= gt; Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt
> >
> >
> > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR0= 2.corp.ad.broadcom.com>
> > "Shahram Davari" writ= es:
> > >
> > > Giles,
> > >
> &g= t; > Adding GAL to PW requires HW change, so why not just add CW and use=
> > > VVCV Type 1?  Also what is wrong with TTL approach = for non-CW?
> > >
> > > Thx
> > > Shahr= am
> >
> >
> > Shahram,
> >
> >= ; Adding GAL to an MPLS label stack requires hardware support.  The> > hardware need not know if the label above the GAL is an MPLS lab= el or
> > a PW label, just that the next label is GAL and the labe= l over it is
> > not a SWAP.  Unless we are talking about inc= redibly inflexible parser
> > hardware, like none I've encounted r= ecently, there should be no
> > problem noticing a GAL below the P= OP or PW label and then directing
> > the packet to OAM processing= .  Any remaining labels must be removed
> > and hopefully no = implementation neglects to look for BOS before
> > deciding where = the payload is supposed to be.
> >
> > TTL is best reserv= ed for traceroute only (in the MS-PW case).  In this
> > case= TTL-expire would occur where a label swap was called for and a
> >= ; GAL would be below the label containing the expired TTL.  Since LDP<= br>> > can have transient loops, this avoids having lots of packets s= ent to
> > the OAM engine should such a loop occur in a LDP signal= ed MPLS PSN.
> >
> > This yield one way to do OAM with or= without CW.  A GAL label is below
> > the label for which ac= tion is taken (POP or PW termination) or below a
> > label for whi= ch TTL has expired.  This method applied to LSP and PW.
> >> > I think mandating CW would be just as good a solution, but one = that
> > was rejected so this is the best we have.
> >> > Curtis
> >
> >
> > > -----Original= Message-----
> > > From: Giles Heron [mailto:giles.heron@gmail.com]
>= ; > > Sent: Wednesday, August 03, 2011 11:10 AM
> > > To:= Thomas Nadeau; Shahram Davari
> > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennis= on
> > > Subject: Re: [PWE3] Poll for WG adoption of draft-nade= au-pwe3-vccv-2-02.txt
> > >
> > > Agreed - some ope= rators won't want to use a CW, and on that basis I support
> > >= ; this draft.
> > >
> > > Sure, it'll take a while = to move away from the router alert label and TTL
> > > approach= es, but the GAL approach is definitely better than either of
> > &= gt; those...
> > >
> > > Giles
> > >> > > On 02/08/2011 12:59, "Thomas Nadeau" <tnadeau@lucidvision.c= om> wrote:
> > >
> > > >
> > >= ; > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote:
> > > = >
> > > >> Hi,
> > > >>
> >= > >> I also don=B9t support this draft since I don=B9t think to s= olve the problem we
> > > >> need yet a 4th type of VCCV.= The best solution is to mandate CW.
> > > >
> > &g= t; > While I am with you, that argument went out the window during the d= ebates we
> > > > had over the past 3 IETF meetings. Operato= rs
> > > > were very clear that they do not want to mandate = the use of a CW.   Hence,
> > > > Luca and I came up wi= th this solution that narrows the
> > > > scope to 2 modes, = one that handles the CW case and one that doesn't while
> > > &= gt; still both modes providing predictable OAM capabilities
> > &g= t; > for the PW.
> > > >
> > > > --Tom
= > > > >
> > > >
> > > >>
&g= t; > > >> Shahram
> > > >>
> > > = >> From: p= we3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> > > = >> Robert Rennison
> > > >> Sent: Sunday, July 31, = 2011 7:40 PM
> > > >> To: Alexander Vainshtein; Yaakov St= ein; Bocci, Matthew (Matthew);
> > > >> pwe3@ietf.org
> > > >&= gt; Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt
> > > >>
> > > >> I do Not support= the draft,
> > > >>
> > > >> After hea= ring the results of the earlier user deployment  poll I thought,
&g= t; > > >> =B3 ok  the way out of this mess is to migrate t= owards using the CW=B2. Then I
> > > >> see this proposal= and wondered what am I missing.  I=B9ve still not seen the
> &g= t; > >> light of why adding a fourth type will simplify matters, h= ence in the absence
> > > >> of me understanding how this= will simplify matter versus complicate things,
> > > >> = I=B9m against it.
> > > >>
> > > >> Rob=
> > > >>
> > > >> From: pwe3-bounces@ietf.org [mai= lto:pwe3-bounces= @ietf.org] On Behalf Of
> > > >> Alexander Vainshtein=
> > > >> Sent: Sunday, July 31, 2011 12:45 AM
> &g= t; > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org
> > > &g= t;> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2= -02.txt
> > > >>
> > > >> Hi all,
&g= t; > > >> I do NOT support this draft for the same reasons that= Yaakov has indicated.
> > > >>
> > > >>= ; Regards,
> > > >>      Sasha
> >= ; > >>
> > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On B= ehalf Of Yaakov Stein
> > > >> [yaakov_s@rad.com]
> > > >&g= t; Sent: Friday, July 29, 2011 3:58 AM
> > > >> To: Bocci= , Matthew (Matthew); pwe= 3@ietf.org
> > > >> Subject: Re: [PWE3] Poll for WG a= doption of draft-nadeau-pwe3-vccv-2-02.txt
> > > >>
&g= t; > > >> I do not support !    and I can not underst= and how anyone can support it !
> > > >>
> > >= ; >> We do NOT need a fourth VCCV type, there are too many already.> > > >>
> > > >> I completely agree wit= h the part that says if there is a CW then the ACh
> > > >&g= t; should be marked by it.
> > > >>
> > > >= ;> I do NOT agree that if the CW is not used then we should use a non-PW= method
> > > >> developed for MPLS-TP.
> > >= >> I do NOT agree that there is any way to deprecate the use of TTL = expiry to
> > > >> mark the ACh.
> > > >&g= t; I do NOT agree that we should change mechanisms that have been widely> > > >> deployed for many years now,
> > > >= ;> without an extremely pressing reason.
> > > >>
&= gt; > > >> Were the proposal to be that for PWs that traverse O= NLY MPLS-TP to have the
> > > >> ADDITIONAL option
>= ; > > >> for ACh marking, I might be convinced not to object as= strongly.
> > > >> However, since I don't think that PWs= can be limited in this matter (the MPLS
> > > >> WG adop= ted the "seamless" draft)
> > > >> it would be = difficult to convince me that such a limitation is possible.
> > &= gt; >>
> > > >> I would have enthusiastically suppo= rt this proposal had it been brought 8
> > > >> years ago= .
> > > >> It's too late for this now.
> > > = >>
> > > >> Y(J)S
> > > >>
>= ; > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
&g= t; > > >> Bocci, Matthew (Matthew)
> > > >> S= ent: Thursday, July 28, 2011 21:02
> > > >> To: pwe3@ietf.org
> > = > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vcc= v-2-02.txt
> > > >>
> > > >> This email= begins a two week poll to help assess if there is consensus to
> >= ; > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working gro= up draft.
> > > >>
> > > >> Please indi= cate whether or not you support adoption of this draft, and also
> &g= t; > >> send any comments to the PWE3 list.
> > > >= >
> > > >> This poll will end on Friday 12th August.> > > >>
> > > >> Regards,
> > = > >>
> > > >> Matthew & Andy
> > &g= t; >> This e-mail message is intended for the recipient only and cont= ains
> > > >> 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 i= s CONFIDENTIAL and which may be proprietary to ECI
> > > >&g= t; 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/p= we3

 

=

 

= --_000_5E893DB832F57341992548CDBB333163A0AC0CD79CEMBX01HQjnprn_-- From curtis@occnc.com Fri Aug 5 10:46: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 DA5EB21F8BEC for ; Fri, 5 Aug 2011 10:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 GqPh41nYun3Z for ; Fri, 5 Aug 2011 10:46:49 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id D1AB421F8BAE for ; Fri, 5 Aug 2011 10:46:48 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p75HjkFR099931; Fri, 5 Aug 2011 13:45:46 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108051745.p75HjkFR099931@harbor.orleans.occnc.com> To: "Shahram Davari" From: Curtis Villamizar In-reply-to: Your message of "Thu, 04 Aug 2011 17:47:27 PDT." <2C2F1EBA8050E74EA81502D5740B4BD6A93275F9B8@SJEXCHCCR02.corp.ad.broadcom.com> Date: Fri, 05 Aug 2011 13:45:46 -0400 Sender: curtis@occnc.com Cc: "'yaakov_s@rad.com'" , "'pwe3@ietf.org'" , "'Robert.Rennison@ecitele.com'" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 17:46:51 -0000 In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F9B8@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Apparently you have no chip design experience. So let me give you some > tutorial: I find that amusing. > Most chips have a fixed parse and a flexible parse. Flexible parsers > are expensive, since they use CAMs with limited capacity rather than > memories. Therefore using flexible parsers should be limited as much > possible for exceptional cases. Other chips have little or no hard coded parts of the parser. They don't even have hard coded notions of how Ethernet headers are arranged though they may have logic intended to accellerate things like MAC learning (which we don't need, but someone in a different market would) or assist with QoS handling and TTL models (which we do need). These chip could just as easily parse something quite different like PPP or GFP-F if they needed to. > The question is why use such scarce resource for a feature that is not > a necessity but a nice thing to have. Don't make them so scarce since a few more gates beats a respin. > Shahram We are working very closely with two chip vendors. One is using small TCAMs and pipelining in the parser. The other is useing very tiny microprogrammed engines for parsing and using parallelism in their parser. Both are extremely flexible, have a relatively small parser die footprint, draw reasonably low power, and are very flexible. We are working toward a next generation of chips mostly to increase the capacity and reduce real estate and power, however both vendors could support this type of change in their *prior* iteration with only a change in chip programming that is loaded at run time initialization. There was a debate over whether GAL should be limited to BOS only well before it became an RFC. The wording makes it always at BOS for TP and ambigous for non-TP. It should not be surprising that it is now being relaxed. Its your problem if you missed this. Perhaps you have hard coded parts of the parser and took some shortcuts when doing so. If so, that's not the WG's problem, its your problem. Same is true for anyone that hardcoded T-MPLS features. We are well aware of efficiency and flexibility tradeoffs. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Thursday, August 04, 2011 5:39 PM > To: Shahram Davari > Cc: curtis@occnc.com; 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com'; 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F5FA@SJEXCHCCR02.corp.ad.broadcom.com> > "Shahram Davari" writes: > > > > Also I forgot to mention that we have super-flexible fully > > programmable parsers, but IETF works should not assume that everyone > > has such capability. Specially for an unnecessary draft such as this > > one. > > > > Thx > > Shharam > > > So apparently when you stated "Adding GAL to PW requires HW change" > you were standing up for some unspecified "other vendor" that may be > too shy or afraid to raise an objection. (?) OK. > > If someone has a problem with this fairly minor change to PW and GAL > processing, they should speak for themselves. > > Curtis > > > > -----Original Message----- > > From: Shahram Davari > > Sent: Thursday, August 04, 2011 10:22 AM > > To: 'curtis@occnc.com' > > Cc: 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com'; 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > Curtis, > > > > I am sorry but your RFI and emails are not equal to IETF RFCs and there is no reason for vendors to follow the words of an IETF participant. > > > > Thanks > > Shahram > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Thursday, August 04, 2011 10:12 AM > > To: Shahram Davari > > Cc: 'curtis@occnc.com'; 'giles.heron@gmail.com'; 'tnadeau@lucidvision.com'; 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > I don't agree with you. This is not about broken HW. Before this draft > > > how was one supposed to process a packet with GAL in the middle of the > > > label stack? > > > > Before this draft one had to read the MPLS and PWE3 mailing list and > > remember what was said. Getting it written in a draft is the next > > step. > > > > Some of the most purist of the MPLS-TP folks have done a good job of > > shouting down any suggestion that multipath had a valid place in any > > network for quite some time. > > > > > What if this draft had decided to put GAL after entropy? Then the HW > > > processing would have been completely different from what you are > > > proposing on the fly now. > > > > Putting labels under GAL for the purpose of entropy was proposed on > > MPLS mailing list for well over a year now, probably close to two > > years, more recently on PWE3. It is reflected in other > > internet-drafts, For example, draft-villamizar-mpls-tp-multipath-00 > > was submitted before Maastricht but fell off the end of the agenda. > > > > It is also in a document that we have been giving to chip vendors > > under NDA stating detailed requirements starting just under a year ago. > > Before that is was more verbal discussion of requirements and email. > > Your friends in another part of your company were eliminated from > > consideration for other reasons a while back but have heard this > > requirement verbally at least. > > > > > You are making imaginary assumptions that HW should be able to process > > > what was in your mind. > > > > That is presumptious on your part. Actually we have given this > > requirement to chip vendors in our product space for about a year and > > a half and I have brought this up for even longer in the MPLS WG and > > more recently on PWE3. Two chip vendors have taken these requirements > > to heart and will be allowing labels under GAL plus the forwarding > > functionality described in draft-villamizar-mpls-tp-multipath-01. > > > > Of all the packet processors that we have considered, all on the very > > high end of things, I know of none that have a parser that is so > > inflexible that it could not deal with a label under GAL and still > > find the OAM payload with nothing more than a change to the low level > > programming of the parser. > > > > I can envision that chips do exist for which the parser is too hard > > coded to accommodate such a change. Lucky for us (not luck really) > > that we are not working with such a chip. Are you? > > > > > I strongly object to this unnecessary draft. If you look at RFCs there > > > are always cases that we wished we had done it differently, but we are > > > not going to change them since in most cases like this one it is too > > > late. Sorry but that is the fact. > > > > We are implementing labels under GAL for non-TP OAM in our products > > regardless of your objections. If a provider wants to use it, it will > > be there. If it can also be used for PW, all the better. Its really > > easy to do, so it doesn't hurt to do it. > > > > If a provider prefers to use CW all the time, I'm fine with that but > > we still need labels under GAL for non-TP MPLS OAM. > > > > > Thx > > > Shahram > > > > Curtis > > > > > > > ----- Original Message ----- > > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > > Sent: Thursday, August 04, 2011 06:38 AM > > > To: Shahram Davari > > > Cc: curtis@occnc.com ; Giles Heron ; Thomas Nadeau ; Yaakov Stein ; pwe3@ietf.org ; Robert Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.com> > > > "Shahram Davari" writes: > > > > > > > > Hi Curtis, > > > > > > > > Even if we assume this format (which is not yet incorporated in the > > > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > > > this case how is the HW supposed to examine the ACH channel Type to > > > > decide how to process the packet? (unless you assume there is one > > > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > > > > > Thx > > > > Shahram > > > > > > > > > Shahram, > > > > > > This doesn't need to go in the fat-pw draft. It needs to go into the > > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > > > when some other feature, fat-pw or other, puts a label under the PW > > > label. The GAL goes after the PW and before the other labels. A > > > proper multipath distribution will skip any reserved label and use the > > > rest of the label stack to load balance. This allows spraying across > > > the entropy space or testing a spacific payload label stack that has > > > yielded trouble. > > > > > > Hardware that assumes ACH is right after GAL when the S-bit is not set > > > on the GAL is broken. > > > > > > The payload (ACH) is after the BOS (aka S-bit = 1). > > > > > > The IETF has never been sympathetic of broken hardware and should not > > > be since we would halt progress. > > > > > > If the hardware is broken, then the fat-pw label can be omitted but > > > only one path through any multipath would be tested. It would still > > > work for TP, but not work in general. PW does not require TP. The > > > fat-pw work is explicitly done for multipath because multipath is used > > > a lot in deployed networks and isn't going away. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > Sent: Wednesday, August 03, 2011 4:53 PM > > > > To: Shahram Davari > > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.com> > > > > "Shahram Davari" writes: > > > > > > > > > > Hi Curtis, > > > > > > > > > > You are absolutely correct if there is no Entropy label. But with > > > > > Entropy label most implementation assume a Entropy label to be BoS and > > > > > below the PW label. > > > > > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > > > the Entropy Label? In either case adding GAL would make the packet > > > > > un-parsable by most HW. > > > > > > > > > > Thx > > > > > Shahram > > > > > > > > > > > > That should be covered in this work. At least it was covered in WG > > > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > > > from Entropy label in MPLS). > > > > > > > > 0 1 2 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | PW Label | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | GAL | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | ... additional labels (ie: fat-pw) may be present | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | | > > > > ~ VCCV Message Body ~ > > > > | | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > The above would be a better choice. The VCCV is always after the > > > > label entry with BOS (S-bit = 1). > > > > > > > > The flow label (or entropy label) must not be a reserved label. > > > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > > > > 1.2 (page 5) you will find. > > > > > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > > > protocol. > > > > > > > > > > > > The flow label below GAL is needed so that all data paths which the PW > > > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > > > > > Curtis > > > > > > > > > > > > > -----Original Message----- > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > > > To: Shahram Davari > > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com> > > > > > "Shahram Davari" writes: > > > > > > > > > > > > Giles, > > > > > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > > > > > Thx > > > > > > Shahram > > > > > > > > > > > > > > > Shahram, > > > > > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > > > hardware need not know if the label above the GAL is an MPLS label or > > > > > a PW label, just that the next label is GAL and the label over it is > > > > > not a SWAP. Unless we are talking about incredibly inflexible parser > > > > > hardware, like none I've encounted recently, there should be no > > > > > problem noticing a GAL below the POP or PW label and then directing > > > > > the packet to OAM processing. Any remaining labels must be removed > > > > > and hopefully no implementation neglects to look for BOS before > > > > > deciding where the payload is supposed to be. > > > > > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In this > > > > > case TTL-expire would occur where a label swap was called for and a > > > > > GAL would be below the label containing the expired TTL. Since LDP > > > > > can have transient loops, this avoids having lots of packets sent to > > > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > > > > > This yield one way to do OAM with or without CW. A GAL label is below > > > > > the label for which action is taken (POP or PW termination) or below a > > > > > label for which TTL has expired. This method applied to LSP and PW. > > > > > > > > > > I think mandating CW would be just as good a solution, but one that > > > > > was rejected so this is the best we have. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > > > To: Thomas Nadeau; Shahram Davari > > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis I support > > > > > > this draft. > > > > > > > > > > > > Sure, it'll take a while to move away from the router alert label and TTL > > > > > > approaches, but the GAL approach is definitely better than either of > > > > > > those... > > > > > > > > > > > > Giles > > > > > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" wrote: > > > > > > > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > > > > > >> Hi, > > > > > > >> > > > > > > >> I also donąt support this draft since I donąt think to solve the problem we > > > > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > > > > > > > While I am with you, that argument went out the window during the debates we > > > > > > > had over the past 3 IETF meetings. Operators > > > > > > > were very clear that they do not want to mandate the use of a CW. Hence, > > > > > > > Luca and I came up with this solution that narrows the > > > > > > > scope to 2 modes, one that handles the CW case and one that doesn't while > > > > > > > still both modes providing predictable OAM capabilities > > > > > > > for the PW. > > > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > >> > > > > > > >> Shahram > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > > > >> Robert Rennison > > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > > > > > > >> pwe3@ietf.org > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> I do Not support the draft, > > > > > > >> > > > > > > >> After hearing the results of the earlier user deployment poll I thought, > > > > > > >> ł ok the way out of this mess is to migrate towards using the CW˛. Then I > > > > > > >> see this proposal and wondered what am I missing. Iąve still not seen the > > > > > > >> light of why adding a fourth type will simplify matters, hence in the absence > > > > > > >> of me understanding how this will simplify matter versus complicate things, > > > > > > >> Iąm against it. > > > > > > >> > > > > > > >> Rob > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > > > >> Alexander Vainshtein > > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> Hi all, > > > > > > >> I do NOT support this draft for the same reasons that Yaakov has indicated. > > > > > > >> > > > > > > >> Regards, > > > > > > >> Sasha > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein > > > > > > >> [yaakov_s@rad.com] > > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> I do not support ! and I can not understand how anyone can support it ! > > > > > > >> > > > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > > > >> > > > > > > >> I completely agree with the part that says if there is a CW then the ACh > > > > > > >> should be marked by it. > > > > > > >> > > > > > > >> I do NOT agree that if the CW is not used then we should use a non-PW method > > > > > > >> developed for MPLS-TP. > > > > > > >> I do NOT agree that there is any way to deprecate the use of TTL expiry to > > > > > > >> mark the ACh. > > > > > > >> I do NOT agree that we should change mechanisms that have been widely > > > > > > >> deployed for many years now, > > > > > > >> without an extremely pressing reason. > > > > > > >> > > > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the > > > > > > >> ADDITIONAL option > > > > > > >> for ACh marking, I might be convinced not to object as strongly. > > > > > > >> However, since I don't think that PWs can be limited in this matter (the MPLS > > > > > > >> WG adopted the "seamless" draft) > > > > > > >> it would be difficult to convince me that such a limitation is possible. > > > > > > >> > > > > > > >> I would have enthusiastically support this proposal had it been brought 8 > > > > > > >> years ago. > > > > > > >> It's too late for this now. > > > > > > >> > > > > > > >> Y(J)S > > > > > > >> > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > > > > > >> Bocci, Matthew (Matthew) > > > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > > > >> To: pwe3@ietf.org > > > > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > > > > > >> > > > > > > >> This email begins a two week poll to help assess if there is consensus to > > > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > > > > > > >> > > > > > > >> Please indicate whether or not you support adoption of this draft, and also > > > > > > >> send any comments to the PWE3 list. > > > > > > >> > > > > > > >> This poll will end on Friday 12th August. > > > > > > >> > > > > > > >> Regards, > > > > > > >> > > > > > > >> Matthew & Andy > > > > > > >> 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. From gregimirsky@gmail.com Fri Aug 5 11:13: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 B907A21F8B43 for ; Fri, 5 Aug 2011 11:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRZ3k0bphGmp for ; Fri, 5 Aug 2011 11:13:54 -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 9CF8421F8A95 for ; Fri, 5 Aug 2011 11:13:47 -0700 (PDT) Received: by vws12 with SMTP id 12so1856427vws.31 for ; Fri, 05 Aug 2011 11:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tU4nx59XRNBGREt52Q/wWeBUfnouHHK4u13pF9c1Uz8=; b=eLMnUggwm9iXEWpHUyshUYvy9OgTno1rgEP/X1kalgyqpzTegEMn2e6LAXC94NFndz urEjb4sJOu0GJtqmhXQKGue7FGCVSRpx65wDmWduaha5VNeXp3JGfHj6vJ5tLg0iBeuY tN9J9Xo4VR9m3MHR2puZKX1x01CrYaq6/ZBQQ= MIME-Version: 1.0 Received: by 10.52.89.170 with SMTP id bp10mr2730772vdb.493.1312568045213; Fri, 05 Aug 2011 11:14:05 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Fri, 5 Aug 2011 11:14:05 -0700 (PDT) In-Reply-To: <201108050319.p753JIbL079040@harbor.orleans.occnc.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F741@SJEXCHCCR02.corp.ad.broadcom.com> <201108050319.p753JIbL079040@harbor.orleans.occnc.com> Date: Fri, 5 Aug 2011 11:14:05 -0700 Message-ID: From: Greg Mirsky To: curtis@occnc.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "yaakov_s@rad.com" , "pwe3@ietf.org" , "Robert.Rennison@ecitele.com" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 05 Aug 2011 18:13:56 -0000 Hi Curtis, you'vesaid: "If you are diagnosing a problem at a low level (inner label) PW or LSP and through management action are repeatedly putting the label stack for which trouble is occuring into on-demand OAM at the next outer label, then you can get a few labels under GAL." I think I can not find case when LSP OAM will have labels below GAL. Perhaps I'm missing some scenario. Would be great if you give a hint. Regards, Greg On Thu, Aug 4, 2011 at 8:19 PM, Curtis Villamizar wrote: > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F741@SJEXCHCCR02.corp.a= d.broadcom.com> > "Shahram Davari" writes: >> >> John, >> >> Sorry for not providing enough justification. All I wanted to point >> out was that this is not a done deal so vendors march to implement it. >> >> Here is my justification for having GAL at the bottom of stack: >> >> Having reserved labels such as GAL in the middle of stack is not >> elegant because the only action one has is to punt that packet to >> CPU. The reason is that you can never know what is below GAL since GAL >> is your terminating label. This is a huge restriction similar to what >> we had with RAL label as well. However if GAL is BoS, then you could >> actually process all labels before GAL and be sure there is an ACH >> after GAL. > > > If you are diagnosing a problem at a low level (inner label) PW or LSP > and through management action are repeatedly putting the label stack > for which trouble is occuring into on-demand OAM at the next outer > label, then you can get a few labels under GAL. > > Those labels exist only for the load balance to isolate the same path. > > After a LSP POP, PW termination, or TTL expire, if the next label is > GAL, it is OAM and the packet always goes up to the CPU (if there is > no microprogrammable hardware to handle OAM). =C2=A0It shouldn't be too > tough to find BOS and send only that up, but it might be better to > send the label above GAL (for context), GAL, and anything below GAL. > Software (or that microprogrammable engine for OAM that maybe you have > and its extremely flexible but maybe some "other vendor" doesn't have) > should also be capable of finding BOS. > > Curtis > > >> Regards, >> Shahram >> >> -----Original Message----- >> From: John E Drake [mailto:jdrake@juniper.net] >> Sent: Thursday, August 04, 2011 12:27 PM >> To: Shahram Davari; curtis@occnc.com >> Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' >> Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt >> >> Shahram, >> >> Thanks for your comments! =C2=A0They are *really* incisive and helpful. >> >> John >> >> Sent from my iPhone >> >> >> > -----Original Message----- >> > From: Shahram Davari [mailto:davari@broadcom.com] >> > Sent: Thursday, August 04, 2011 11:44 AM >> > To: John E Drake; curtis@occnc.com >> > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' >> > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- >> > 02.txt >> > >> > Hi, >> > >> > I don't remember such direction and directions should be documented in >> > stable IETF draft and RFCs. And in fact I think that direction is not >> > correct. I think GAL should be at the bottom of the stack so I like to >> > challenge this draft as well. >> > >> > >> > Thx >> > Shahram >> > >> > -----Original Message----- >> > From: John E Drake [mailto:jdrake@juniper.net] >> > Sent: Thursday, August 04, 2011 11:38 AM >> > To: Shahram Davari; curtis@occnc.com >> > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' >> > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- >> > 02.txt >> > >> > Shahram, >> > >> > That is the date at which it became a *working group draft*. =C2=A0The= point >> > that Curtis made, and with which I was agreeing, was that moving the >> > GAL from the bottom of the stack in support of ECMP has been the >> > direction taken by both MPLS and PWE3 for at least a year. >> > >> > John >> > >> > Sent from my iPhone >> > >> > >> > > -----Original Message----- >> > > From: Shahram Davari [mailto:davari@broadcom.com] >> > > Sent: Thursday, August 04, 2011 11:10 AM >> > > To: John E Drake; curtis@occnc.com >> > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; >> > 'Robert.Rennison@ecitele.com' >> > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2= - >> > > 02.txt >> > > >> > > John, >> > > >> > > If your point is that this is mentioned in an IETF draft then please >> > > look at the date of the draft as well (May 5 2011). Also this draft >> > > applies only to MPLS tunnels and not PW. I hope you don't expect >> > people >> > > to implement an IETF draft-00 which was published just 3 months ago. >> > > >> > > -Shahram >> > > >> > > -----Original Message----- >> > > From: John E Drake [mailto:jdrake@juniper.net] >> > > Sent: Thursday, August 04, 2011 10:56 AM >> > > To: curtis@occnc.com; Shahram Davari >> > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; >> > 'Robert.Rennison@ecitele.com' >> > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2= - >> > > 02.txt >> > > >> > > From Section 6 of the Entropy Label I-D >> > > (http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy- >> > > label/?include_text=3D1): >> > > >> > > "As part of the MPLS-TP work, an in-band OAM channel is defined in >> > > [RFC5586]. =C2=A0Packets sent in this channel are identified with a >> > reserved >> > > label, the Generic Associated Channel Label (GAL) placed at the >> > bottom >> > > of the MPLS label stack. =C2=A0In order to use the inband OAM channe= l with >> > > entropy labels, this memo relaxes the restriction that the GAL must >> > be >> > > at the bottom of the MPLS label stack. =C2=A0Rather, the GAL is plac= ed in >> > > the MPLS label stack above the entropy label so that it effectively >> > > functions as an application label." >> > > >> > > Sent from my iPhone >> > > >> > > >> > > > -----Original Message----- >> > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >> > Behalf >> > > Of >> > > > Curtis Villamizar >> > > > Sent: Thursday, August 04, 2011 10:12 AM >> > > > To: Shahram Davari >> > > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; >> > > 'Robert.Rennison@ecitele.com' >> > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= - >> > 2- >> > > > 02.txt >> > > > >> > > > >> > > > In message >> > > > >> > > >> > <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadc= o >> > > > m.com> >> > > > "Shahram Davari" writes: >> > > > > >> > > > > I don't agree with you. This is not about broken HW. Before this >> > > > draft >> > > > > how was one supposed to process a packet with GAL in the middle >> > of >> > > > the >> > > > > label stack? >> > > > >> > > > Before this draft one had to read the MPLS and PWE3 mailing list >> > and >> > > > remember what was said. =C2=A0Getting it written in a draft is the= next >> > > > step. >> > > > >> > > > Some of the most purist of the MPLS-TP folks have done a good job >> > of >> > > > shouting down any suggestion that multipath had a valid place in >> > any >> > > > network for quite some time. >> > > > >> > > > > What if this draft had decided to put GAL after entropy? Then th= e >> > > HW >> > > > > processing would have been completely different from what you ar= e >> > > > > proposing on the fly now. >> > > > >> > > > Putting labels under GAL for the purpose of entropy was proposed o= n >> > > > MPLS mailing list for well over a year now, probably close to two >> > > > years, more recently on PWE3. =C2=A0It is reflected in other inter= net- >> > > > drafts, For example, draft-villamizar-mpls-tp-multipath-00 >> > > > was submitted before Maastricht but fell off the end of the agenda= . >> > > > >> > > > It is also in a document that we have been giving to chip vendors >> > > under >> > > > NDA stating detailed requirements starting just under a year ago. >> > > > Before that is was more verbal discussion of requirements and >> > email. >> > > > Your friends in another part of your company were eliminated from >> > > > consideration for other reasons a while back but have heard this >> > > > requirement verbally at least. >> > > > >> > > > > You are making imaginary assumptions that HW should be able to >> > > > process >> > > > > what was in your mind. >> > > > >> > > > That is presumptious on your part. =C2=A0Actually we have given th= is >> > > > requirement to chip vendors in our product space for about a year >> > and >> > > a >> > > > half and I have brought this up for even longer in the MPLS WG and >> > > more >> > > > recently on PWE3. =C2=A0Two chip vendors have taken these requirem= ents >> > to >> > > > heart and will be allowing labels under GAL plus the forwarding >> > > > functionality described in draft-villamizar-mpls-tp-multipath-01. >> > > > >> > > > Of all the packet processors that we have considered, all on the >> > very >> > > > high end of things, I know of none that have a parser that is so >> > > > inflexible that it could not deal with a label under GAL and still >> > > find >> > > > the OAM payload with nothing more than a change to the low level >> > > > programming of the parser. >> > > > >> > > > I can envision that chips do exist for which the parser is too har= d >> > > > coded to accommodate such a change. =C2=A0Lucky for us (not luck r= eally) >> > > > that we are not working with such a chip. =C2=A0Are you? >> > > > >> > > > > I strongly object to this unnecessary draft. If you look at RFCs >> > > > there >> > > > > are always cases that we wished we had done it differently, but >> > we >> > > > are >> > > > > not going to change them since in most cases like this one it is >> > > too >> > > > > late. Sorry but that is the fact. >> > > > >> > > > We are implementing labels under GAL for non-TP OAM in our product= s >> > > > regardless of your objections. =C2=A0If a provider wants to use it= , it >> > > will >> > > > be there. =C2=A0If it can also be used for PW, all the better. =C2= =A0Its >> > really >> > > > easy to do, so it doesn't hurt to do it. >> > > > >> > > > If a provider prefers to use CW all the time, I'm fine with that >> > but >> > > we >> > > > still need labels under GAL for non-TP MPLS OAM. >> > > > >> > > > > Thx >> > > > > Shahram >> > > > >> > > > Curtis >> > > > >> > > > >> > > > > ----- Original Message ----- >> > > > > From: Curtis Villamizar [mailto:curtis@occnc.com] >> > > > > Sent: Thursday, August 04, 2011 06:38 AM >> > > > > To: Shahram Davari >> > > > > Cc: curtis@occnc.com ; Giles Heron >> > > > > ; Thomas Nadeau = ; >> > > > > Yaakov Stein ; pwe3@ietf.org ; >> > > > Robert >> > > > > Rennison >> > > > > Subject: Re: [PWE3] Poll for WG adoption of >> > > > > draft-nadeau-pwe3-vccv-2-02.txt >> > > > > >> > > > > >> > > > > In message >> > > > > >> > > > >> > > >> > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadc >> > > > > om.com> >> > > > > "Shahram Davari" writes: >> > > > > > >> > > > > > Hi Curtis, >> > > > > > >> > > > > > Even if we assume this format (which is not yet incorporated i= n >> > > the >> > > > > > fat-pw draft), then most hardware assume ACH is right after >> > GAL. >> > > In >> > > > > > this case how is the HW supposed to examine the ACH channel >> > Type >> > > to >> > > > > > decide how to process the packet? (unless you assume there is >> > one >> > > > > > engine that can process all OAM packet types such as BFD, AIS, >> > > PSC, >> > > > > > LSP-ping, LDI, LKR, LM, DM, etc) >> > > > > > >> > > > > > Thx >> > > > > > Shahram >> > > > > >> > > > > >> > > > > Shahram, >> > > > > >> > > > > This doesn't need to go in the fat-pw draft. =C2=A0It needs to g= o into >> > > the >> > > > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM >> > > traffic >> > > > > when some other feature, fat-pw or other, puts a label under the >> > PW >> > > > > label. =C2=A0The GAL goes after the PW and before the other labe= ls. =C2=A0A >> > > > > proper multipath distribution will skip any reserved label and >> > use >> > > > the >> > > > > rest of the label stack to load balance. =C2=A0This allows spray= ing >> > > across >> > > > > the entropy space or testing a spacific payload label stack that >> > > has >> > > > > yielded trouble. >> > > > > >> > > > > Hardware that assumes ACH is right after GAL when the S-bit is >> > not >> > > > set >> > > > > on the GAL is broken. >> > > > > >> > > > > The payload (ACH) is after the BOS (aka S-bit =3D 1). >> > > > > >> > > > > The IETF has never been sympathetic of broken hardware and shoul= d >> > > not >> > > > > be since we would halt progress. >> > > > > >> > > > > If the hardware is broken, then the fat-pw label can be omitted >> > but >> > > > > only one path through any multipath would be tested. =C2=A0It wo= uld >> > > still >> > > > > work for TP, but not work in general. =C2=A0PW does not require = TP. >> > The >> > > > > fat-pw work is explicitly done for multipath because multipath i= s >> > > > used >> > > > > a lot in deployed networks and isn't going away. >> > > > > >> > > > > Curtis >> > > > > >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] >> > > > > > Sent: Wednesday, August 03, 2011 4:53 PM >> > > > > > To: Shahram Davari >> > > > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein= ; >> > > > > > pwe3@ietf.org; Robert Rennison >> > > > > > Subject: Re: [PWE3] Poll for WG adoption of >> > > > > > draft-nadeau-pwe3-vccv-2-02.txt >> > > > > > >> > > > > > >> > > > > > In message >> > > > > > >> > > > >> > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa >> > > > > > dcom.com> >> > > > > > "Shahram Davari" writes: >> > > > > > > >> > > > > > > Hi Curtis, >> > > > > > > >> > > > > > > You are absolutely correct if there is no Entropy label. But >> > > with >> > > > > > > Entropy label most implementation assume a Entropy label to >> > be >> > > > BoS >> > > > > > > and below the PW label. >> > > > > > > >> > > > > > > This draft doesn't even talk about whether the GAL should be >> > > BoS >> > > > > > > or the Entropy Label? In either case adding GAL would make >> > the >> > > > > > > packet un-parsable by most HW. >> > > > > > > >> > > > > > > Thx >> > > > > > > Shahram >> > > > > > >> > > > > > >> > > > > > That should be covered in this work. =C2=A0At least it was cov= ered >> > in >> > > WG >> > > > > > email. =C2=A0PW, then GAL, then fat-pw (aka Flow label, which = is >> > > > > > different from Entropy label in MPLS). >> > > > > > >> > > > > > 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 >> > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> > +-+ >> > > > > > | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PW Label >> > | >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> > +-+ >> > > > > > | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GAL >> > | >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> > +-+ >> > > > > > | =C2=A0 =C2=A0 ... additional labels (ie: fat-pw) may be pres= ent >> > | >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> > +-+ >> > > > > > |0 0 0 1|Version| =C2=A0 Reserved =C2=A0 =C2=A0| =C2=A0Associa= ted Channel Type >> > | >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> > +-+ >> > > > > > | >> > | >> > > > > > ~ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0VCCV Message Body >> > ~ >> > > > > > | >> > | >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> > +-+ >> > > > > > >> > > > > > The above would be a better choice. =C2=A0The VCCV is always a= fter >> > the >> > > > > > label entry with BOS (S-bit =3D 1). >> > > > > > >> > > > > > The flow label (or entropy label) must not be a reserved label= . >> > > > > > Therefore there is no ambiguity. =C2=A0In draft-ietf-pwe3-fat-= pw-07 >> > > > > > section >> > > > > > 1.2 (page 5) you will find. >> > > > > > >> > > > > > =C2=A0 =C2=A0Note that the flow label MUST NOT be an MPLS rese= rved label >> > > > (values >> > > > > > =C2=A0 =C2=A0in the range 0..15) [RFC3032], but is otherwise >> > unconstrained >> > > by >> > > > the >> > > > > > =C2=A0 =C2=A0protocol. >> > > > > > >> > > > > > >> > > > > > The flow label below GAL is needed so that all data paths whic= h >> > > the >> > > > > > PW can take are exercised by OAM (ie: LSP Ping used within >> > VCCV). >> > > > > > >> > > > > > Curtis >> > > > > > >> > > > > > >> > > > > > > -----Original Message----- >> > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] >> > > > > > > Sent: Wednesday, August 03, 2011 4:05 PM >> > > > > > > To: Shahram Davari >> > > > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; >> > > > > > > Robert Rennison >> > > > > > > Subject: Re: [PWE3] Poll for WG adoption of >> > > > > > > draft-nadeau-pwe3-vccv-2-02.txt >> > > > > > > >> > > > > > > >> > > > > > > In message >> > > > > > > >> > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.br >> > > > > > > oadcom.com> >> > > > > > > "Shahram Davari" writes: >> > > > > > > > >> > > > > > > > Giles, >> > > > > > > > >> > > > > > > > Adding GAL to PW requires HW change, so why not just add C= W >> > > and >> > > > > > > > use VVCV Type 1? =C2=A0Also what is wrong with TTL approac= h for >> > > non- >> > > > CW? >> > > > > > > > >> > > > > > > > Thx >> > > > > > > > Shahram >> > > > > > > >> > > > > > > >> > > > > > > Shahram, >> > > > > > > >> > > > > > > Adding GAL to an MPLS label stack requires hardware support. >> > > The >> > > > > > > hardware need not know if the label above the GAL is an MPLS >> > > > label >> > > > > > > or a PW label, just that the next label is GAL and the label >> > > over >> > > > > > > it is not a SWAP. =C2=A0Unless we are talking about incredib= ly >> > > > > > > inflexible parser hardware, like none I've encounted >> > recently, >> > > > > > > there should be no problem noticing a GAL below the POP or P= W >> > > > > > > label and then directing the packet to OAM processing. =C2= =A0Any >> > > > > > > remaining labels must be removed and hopefully no >> > > implementation >> > > > > > > neglects to look for BOS before deciding where the payload i= s >> > > > supposed to be. >> > > > > > > >> > > > > > > TTL is best reserved for traceroute only (in the MS-PW case)= . >> > > In >> > > > > > > this case TTL-expire would occur where a label swap was >> > called >> > > > for >> > > > > > > and a GAL would be below the label containing the expired >> > TTL. >> > > > > > > Since LDP can have transient loops, this avoids having lots >> > of >> > > > > > > packets sent to the OAM engine should such a loop occur in a >> > > LDP >> > > > signaled MPLS PSN. >> > > > > > > >> > > > > > > This yield one way to do OAM with or without CW. =C2=A0A GAL= label >> > > is >> > > > > > > below the label for which action is taken (POP or PW >> > > termination) >> > > > > > > or below a label for which TTL has expired. =C2=A0This metho= d >> > > applied >> > > > to LSP and PW. >> > > > > > > >> > > > > > > I think mandating CW would be just as good a solution, but >> > one >> > > > > > > that was rejected so this is the best we have. >> > > > > > > >> > > > > > > Curtis >> > > > > > > >> > > > > > > >> > > > > > > > -----Original Message----- >> > > > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] >> > > > > > > > Sent: Wednesday, August 03, 2011 11:10 AM >> > > > > > > > To: Thomas Nadeau; Shahram Davari >> > > > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison >> > > > > > > > Subject: Re: [PWE3] Poll for WG adoption of >> > > > > > > > draft-nadeau-pwe3-vccv-2-02.txt >> > > > > > > > >> > > > > > > > Agreed - some operators won't want to use a CW, and on tha= t >> > > > > > > > basis I support this draft. >> > > > > > > > >> > > > > > > > Sure, it'll take a while to move away from the router aler= t >> > > > > > > > label and TTL approaches, but the GAL approach is >> > definitely >> > > > > > > > better than either of those... >> > > > > > > > >> > > > > > > > Giles >> > > > > > > > >> > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" >> > > >> > > > wrote: >> > > > > > > > >> > > > > > > > > >> > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: >> > > > > > > > > >> > > > > > > > >> Hi, >> > > > > > > > >> >> > > > > > > > >> I also don=C4=85t support this draft since I don=C4=85t= think to >> > > solve >> > > > > > > > >> the problem we need yet a 4th type of VCCV. The best >> > > > solution is to mandate CW. >> > > > > > > > > >> > > > > > > > > While I am with you, that argument went out the window >> > > during >> > > > > > > > > the debates we had over the past 3 IETF meetings. >> > Operators >> > > > > > > > > were very clear that they do not want to mandate the use >> > of >> > > a >> > > > CW. =C2=A0 Hence, >> > > > > > > > > Luca and I came up with this solution that narrows the >> > > scope >> > > > > > > > > to 2 modes, one that handles the CW case and one that >> > > doesn't >> > > > > > > > > while still both modes providing predictable OAM >> > > capabilities >> > > > > > > > > for the PW. >> > > > > > > > > >> > > > > > > > > --Tom >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> >> > > > > > > > >> Shahram >> > > > > > > > >> >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- >> > bounces@ietf.org] >> > > > On >> > > > > > > > >> Behalf Of Robert Rennison >> > > > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM >> > > > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew >> > > > > > > > >> (Matthew); pwe3@ietf.org >> > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of >> > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt >> > > > > > > > >> >> > > > > > > > >> I do Not support the draft, >> > > > > > > > >> >> > > > > > > > >> After hearing the results of the earlier user deploymen= t >> > > > > > > > >> poll I thought, =C5=82 ok =C2=A0the way out of this mes= s is to >> > > migrate >> > > > > > > > >> towards using the CW=CB=9B. Then I see this proposal an= d >> > > wondered >> > > > > > > > >> what am I missing. =C2=A0I=C4=85ve still not seen the l= ight of why >> > > > > > > > >> adding a fourth type will simplify matters, hence in th= e >> > > > > > > > >> absence of me understanding how this will simplify >> > matter >> > > > versus complicate things, I=C4=85m against it. >> > > > > > > > >> >> > > > > > > > >> Rob >> > > > > > > > >> >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- >> > bounces@ietf.org] >> > > > On >> > > > > > > > >> Behalf Of Alexander Vainshtein >> > > > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM >> > > > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); >> > pwe3@ietf.org >> > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of >> > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt >> > > > > > > > >> >> > > > > > > > >> Hi all, >> > > > > > > > >> I do NOT support this draft for the same reasons that >> > > Yaakov >> > > > has indicated. >> > > > > > > > >> >> > > > > > > > >> Regards, >> > > > > > > > >> =C2=A0 =C2=A0 =C2=A0Sasha >> > > > > > > > >> >> > > > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On >> > > > Behalf >> > > > > > > > >> Of Yaakov Stein [yaakov_s@rad.com] >> > > > > > > > >> Sent: Friday, July 29, 2011 3:58 AM >> > > > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org >> > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of >> > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt >> > > > > > > > >> >> > > > > > > > >> I do not support ! =C2=A0 =C2=A0and I can not understan= d how >> > anyone >> > > > can support it ! >> > > > > > > > >> >> > > > > > > > >> We do NOT need a fourth VCCV type, there are too many >> > > > already. >> > > > > > > > >> >> > > > > > > > >> I completely agree with the part that says if there is = a >> > > CW >> > > > > > > > >> then the ACh should be marked by it. >> > > > > > > > >> >> > > > > > > > >> I do NOT agree that if the CW is not used then we shoul= d >> > > use >> > > > > > > > >> a non-PW method developed for MPLS-TP. >> > > > > > > > >> I do NOT agree that there is any way to deprecate the >> > use >> > > of >> > > > > > > > >> TTL expiry to mark the ACh. >> > > > > > > > >> I do NOT agree that we should change mechanisms that >> > have >> > > > > > > > >> been widely deployed for many years now, without an >> > > > extremely >> > > > > > > > >> pressing reason. >> > > > > > > > >> >> > > > > > > > >> Were the proposal to be that for PWs that traverse ONLY >> > > > > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, = I >> > > > > > > > >> might be convinced not to object as strongly. >> > > > > > > > >> However, since I don't think that PWs can be limited in >> > > this >> > > > > > > > >> matter (the MPLS WG adopted the "seamless" draft) it >> > would >> > > > be >> > > > > > > > >> difficult to convince me that such a limitation is >> > > possible. >> > > > > > > > >> >> > > > > > > > >> I would have enthusiastically support this proposal had >> > it >> > > > > > > > >> been brought 8 years ago. >> > > > > > > > >> It's too late for this now. >> > > > > > > > >> >> > > > > > > > >> Y(J)S >> > > > > > > > >> >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- >> > bounces@ietf.org] >> > > > On >> > > > > > > > >> Behalf Of Bocci, Matthew (Matthew) >> > > > > > > > >> Sent: Thursday, July 28, 2011 21:02 >> > > > > > > > >> To: pwe3@ietf.org >> > > > > > > > >> Subject: [PWE3] Poll for WG adoption of >> > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt >> > > > > > > > >> >> > > > > > > > >> This email begins a two week poll to help assess if >> > there >> > > is >> > > > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a >> > > PWE3 >> > > > working group draft. >> > > > > > > > >> >> > > > > > > > >> Please indicate whether or not you support adoption of >> > > this >> > > > > > > > >> draft, and also send any comments to the PWE3 list. >> > > > > > > > >> >> > > > > > > > >> This poll will end on Friday 12th August. >> > > > > > > > >> >> > > > > > > > >> Regards, >> > > > > > > > >> >> > > > > > > > >> Matthew & Andy >> > > > > > > > >> This e-mail message is intended for the recipient only >> > and >> > > > > > > > >> contains information which is CONFIDENTIAL and which ma= y >> > > be >> > > > > > > > >> proprietary to ECI Telecom. If you 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 information which is CONFIDENTIAL and which ma= y >> > > be >> > > > > > > > >> proprietary to ECI Telecom. If you 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 > > From amalis@gmail.com Fri Aug 5 11:27: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 0681F11E809B for ; Fri, 5 Aug 2011 11:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 8PBKieBQSjGP for ; Fri, 5 Aug 2011 11:27:29 -0700 (PDT) Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 450B311E8070 for ; Fri, 5 Aug 2011 11:27:29 -0700 (PDT) Received: by eyx24 with SMTP id 24so1481079eyx.19 for ; Fri, 05 Aug 2011 11:27:46 -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 :content-type:content-transfer-encoding; bh=qcuwKGaUfYJFAv3YNU5UXG7b+9YLvdOZ9aYfJAco1vk=; b=FQIGeSVoJY4avSEDn6YJiMKzLj+mX2HVi2odBwIxwcjg6+WzkQ8GGpFlEVaXKzYGqW PiGmF4f1ovfe76JAltW+JGefxPwDy6X51Y9Ddt+69tEM37oK9I8FckzBOlaNJnhhUF6a ruBwJioVG0yTF9jFMzoC+z9hdackf5kpLhJ20= Received: by 10.204.141.91 with SMTP id l27mr797729bku.72.1312568866347; Fri, 05 Aug 2011 11:27:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.23.82 with HTTP; Fri, 5 Aug 2011 11:27:26 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A93275F652@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadcom.com> <201108041712.p74HCMCH057629@harbor.orleans.occnc.com> <5E893DB832F57341992548CDBB333163A0AC0CCCE1@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD6A93275F652@SJEXCHCCR02.corp.ad.broadcom.com> From: "Andrew G. Malis" Date: Fri, 5 Aug 2011 14:27:26 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 05 Aug 2011 18:27:30 -0000 OK, speaking with my working group chair hat on - I don't do this very often, but I would like to ask EVERYONE on this thread (and in the WG) to remember that what you type is a part of the IETF process, is very public, will be remembered forever in some archive or another, and may even end up in a court of law. Enough said about that. I would like to respond a particular comment from Shahram, also as WG chair= : > John, > > If your point is that this is mentioned in an IETF draft then please look= at the date of the draft as well (May 5 2011). Also this draft applies onl= y to MPLS tunnels and not PW. I hope you don't expect people to implement a= n IETF draft-00 which was published just 3 months ago. > > -Shahram The point in John's email (and others) is that while draft-ietf-pwe3-fat-pw and draft-ietf-mpls-entropy-label are both still drafts, they both do represent their respective working group consensus at this point in time and take a consistent approach regarding the placement of labels in the stack. If anyone disagrees with this particular consensus approach, then I would suggest starting a new email thread in both WGs to argue why this approach is incorrect, and to propose specific changes in the text of both drafts, and we can then determine consensus regarding the proposed changes. I very much think that both working groups would like to keep the two drafts consistent with each other. Or at least the chairs certainly would. :-) Thanks, Andy From curtis@occnc.com Fri Aug 5 12:33:42 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 324571F0C40 for ; Fri, 5 Aug 2011 12:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 JuqW6lJkm5WY for ; Fri, 5 Aug 2011 12:33:40 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8425D1F0C44 for ; Fri, 5 Aug 2011 12:33:39 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p75JWUKP006749; Fri, 5 Aug 2011 15:32:30 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201108051932.p75JWUKP006749@harbor.orleans.occnc.com> To: Greg Mirsky From: Curtis Villamizar In-reply-to: Your message of "Fri, 05 Aug 2011 11:14:05 PDT." Date: Fri, 05 Aug 2011 15:32:30 -0400 Sender: curtis@occnc.com Cc: "yaakov_s@rad.com" , "pwe3@ietf.org" , "Robert.Rennison@ecitele.com" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 19:33:42 -0000 In message Greg Mirsky writes: > > Hi Curtis, > you'vesaid: > "If you are diagnosing a problem at a low level (inner label) PW or LSP > and through management action are repeatedly putting the label stack > for which trouble is occuring into on-demand OAM at the next outer > label, then you can get a few labels under GAL." > > I think I can not find case when LSP OAM will have labels below GAL. > Perhaps I'm missing some scenario. Would be great if you give a hint. > > Regards, > Greg Entropy label for one. Then there is the further isolation of a problem in this email. Curtis > On Thu, Aug 4, 2011 at 8:19 PM, Curtis Villamizar wrote: > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F741@SJEXCHCCR02.corp.ad.broadcom.com> > > "Shahram Davari" writes: > >> > >> John, > >> > >> Sorry for not providing enough justification. All I wanted to point > >> out was that this is not a done deal so vendors march to implement it. > >> > >> Here is my justification for having GAL at the bottom of stack: > >> > >> Having reserved labels such as GAL in the middle of stack is not > >> elegant because the only action one has is to punt that packet to > >> CPU. The reason is that you can never know what is below GAL since GAL > >> is your terminating label. This is a huge restriction similar to what > >> we had with RAL label as well. However if GAL is BoS, then you could > >> actually process all labels before GAL and be sure there is an ACH > >> after GAL. > > > > > > If you are diagnosing a problem at a low level (inner label) PW or LSP > > and through management action are repeatedly putting the label stack > > for which trouble is occuring into on-demand OAM at the next outer > > label, then you can get a few labels under GAL. > > > > Those labels exist only for the load balance to isolate the same path. > > > > After a LSP POP, PW termination, or TTL expire, if the next label is > > GAL, it is OAM and the packet always goes up to the CPU (if there is > > no microprogrammable hardware to handle OAM).  It shouldn't be too > > tough to find BOS and send only that up, but it might be better to > > send the label above GAL (for context), GAL, and anything below GAL. > > Software (or that microprogrammable engine for OAM that maybe you have > > and its extremely flexible but maybe some "other vendor" doesn't have) > > should also be capable of finding BOS. > > > > Curtis > > > > > >> Regards, > >> Shahram > >> > >> -----Original Message----- > >> From: John E Drake [mailto:jdrake@juniper.net] > >> Sent: Thursday, August 04, 2011 12:27 PM > >> To: Shahram Davari; curtis@occnc.com > >> Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > >> Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > >> > >> Shahram, > >> > >> Thanks for your comments!  They are *really* incisive and helpful. > >> > >> John > >> > >> Sent from my iPhone > >> > >> > >> > -----Original Message----- > >> > From: Shahram Davari [mailto:davari@broadcom.com] > >> > Sent: Thursday, August 04, 2011 11:44 AM > >> > To: John E Drake; curtis@occnc.com > >> > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > >> > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > >> > 02.txt > >> > > >> > Hi, > >> > > >> > I don't remember such direction and directions should be documented in > >> > stable IETF draft and RFCs. And in fact I think that direction is not > >> > correct. I think GAL should be at the bottom of the stack so I like to > >> > challenge this draft as well. > >> > > >> > > >> > Thx > >> > Shahram > >> > > >> > -----Original Message----- > >> > From: John E Drake [mailto:jdrake@juniper.net] > >> > Sent: Thursday, August 04, 2011 11:38 AM > >> > To: Shahram Davari; curtis@occnc.com > >> > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; 'Robert.Rennison@ecitele.com' > >> > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > >> > 02.txt > >> > > >> > Shahram, > >> > > >> > That is the date at which it became a *working group draft*.  The point > >> > that Curtis made, and with which I was agreeing, was that moving the > >> > GAL from the bottom of the stack in support of ECMP has been the > >> > direction taken by both MPLS and PWE3 for at least a year. > >> > > >> > John > >> > > >> > Sent from my iPhone > >> > > >> > > >> > > -----Original Message----- > >> > > From: Shahram Davari [mailto:davari@broadcom.com] > >> > > Sent: Thursday, August 04, 2011 11:10 AM > >> > > To: John E Drake; curtis@occnc.com > >> > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > >> > 'Robert.Rennison@ecitele.com' > >> > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > >> > > 02.txt > >> > > > >> > > John, > >> > > > >> > > If your point is that this is mentioned in an IETF draft then please > >> > > look at the date of the draft as well (May 5 2011). Also this draft > >> > > applies only to MPLS tunnels and not PW. I hope you don't expect > >> > people > >> > > to implement an IETF draft-00 which was published just 3 months ago. > >> > > > >> > > -Shahram > >> > > > >> > > -----Original Message----- > >> > > From: John E Drake [mailto:jdrake@juniper.net] > >> > > Sent: Thursday, August 04, 2011 10:56 AM > >> > > To: curtis@occnc.com; Shahram Davari > >> > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > >> > 'Robert.Rennison@ecitele.com' > >> > > Subject: RE: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2- > >> > > 02.txt > >> > > > >> > > From Section 6 of the Entropy Label I-D > >> > > (http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy- > >> > > label/?include_text=1): > >> > > > >> > > "As part of the MPLS-TP work, an in-band OAM channel is defined in > >> > > [RFC5586].  Packets sent in this channel are identified with a > >> > reserved > >> > > label, the Generic Associated Channel Label (GAL) placed at the > >> > bottom > >> > > of the MPLS label stack.  In order to use the inband OAM channel with > >> > > entropy labels, this memo relaxes the restriction that the GAL must > >> > be > >> > > at the bottom of the MPLS label stack.  Rather, the GAL is placed in > >> > > the MPLS label stack above the entropy label so that it effectively > >> > > functions as an application label." > >> > > > >> > > Sent from my iPhone > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > >> > Behalf > >> > > Of > >> > > > Curtis Villamizar > >> > > > Sent: Thursday, August 04, 2011 10:12 AM > >> > > > To: Shahram Davari > >> > > > Cc: 'yaakov_s@rad.com'; 'pwe3@ietf.org'; > >> > > 'Robert.Rennison@ecitele.com' > >> > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv- > >> > 2- > >> > > > 02.txt > >> > > > > >> > > > > >> > > > In message > >> > > > > >> > > > >> > <2C2F1EBA8050E74EA81502D5740B4BD6A9315D2675@SJEXCHCCR02.corp.ad.broadco > >> > > > m.com> > >> > > > "Shahram Davari" writes: > >> > > > > > >> > > > > I don't agree with you. This is not about broken HW. Before this > >> > > > draft > >> > > > > how was one supposed to process a packet with GAL in the middle > >> > of > >> > > > the > >> > > > > label stack? > >> > > > > >> > > > Before this draft one had to read the MPLS and PWE3 mailing list > >> > and > >> > > > remember what was said.  Getting it written in a draft is the next > >> > > > step. > >> > > > > >> > > > Some of the most purist of the MPLS-TP folks have done a good job > >> > of > >> > > > shouting down any suggestion that multipath had a valid place in > >> > any > >> > > > network for quite some time. > >> > > > > >> > > > > What if this draft had decided to put GAL after entropy? Then the > >> > > HW > >> > > > > processing would have been completely different from what you are > >> > > > > proposing on the fly now. > >> > > > > >> > > > Putting labels under GAL for the purpose of entropy was proposed on > >> > > > MPLS mailing list for well over a year now, probably close to two > >> > > > years, more recently on PWE3.  It is reflected in other internet- > >> > > > drafts, For example, draft-villamizar-mpls-tp-multipath-00 > >> > > > was submitted before Maastricht but fell off the end of the agenda. > >> > > > > >> > > > It is also in a document that we have been giving to chip vendors > >> > > under > >> > > > NDA stating detailed requirements starting just under a year ago. > >> > > > Before that is was more verbal discussion of requirements and > >> > email. > >> > > > Your friends in another part of your company were eliminated from > >> > > > consideration for other reasons a while back but have heard this > >> > > > requirement verbally at least. > >> > > > > >> > > > > You are making imaginary assumptions that HW should be able to > >> > > > process > >> > > > > what was in your mind. > >> > > > > >> > > > That is presumptious on your part.  Actually we have given this > >> > > > requirement to chip vendors in our product space for about a year > >> > and > >> > > a > >> > > > half and I have brought this up for even longer in the MPLS WG and > >> > > more > >> > > > recently on PWE3.  Two chip vendors have taken these requirements > >> > to > >> > > > heart and will be allowing labels under GAL plus the forwarding > >> > > > functionality described in draft-villamizar-mpls-tp-multipath-01. > >> > > > > >> > > > Of all the packet processors that we have considered, all on the > >> > very > >> > > > high end of things, I know of none that have a parser that is so > >> > > > inflexible that it could not deal with a label under GAL and still > >> > > find > >> > > > the OAM payload with nothing more than a change to the low level > >> > > > programming of the parser. > >> > > > > >> > > > I can envision that chips do exist for which the parser is too hard > >> > > > coded to accommodate such a change.  Lucky for us (not luck really) > >> > > > that we are not working with such a chip.  Are you? > >> > > > > >> > > > > I strongly object to this unnecessary draft. If you look at RFCs > >> > > > there > >> > > > > are always cases that we wished we had done it differently, but > >> > we > >> > > > are > >> > > > > not going to change them since in most cases like this one it is > >> > > too > >> > > > > late. Sorry but that is the fact. > >> > > > > >> > > > We are implementing labels under GAL for non-TP OAM in our products > >> > > > regardless of your objections.  If a provider wants to use it, it > >> > > will > >> > > > be there.  If it can also be used for PW, all the better.  Its > >> > really > >> > > > easy to do, so it doesn't hurt to do it. > >> > > > > >> > > > If a provider prefers to use CW all the time, I'm fine with that > >> > but > >> > > we > >> > > > still need labels under GAL for non-TP MPLS OAM. > >> > > > > >> > > > > Thx > >> > > > > Shahram > >> > > > > >> > > > Curtis > >> > > > > >> > > > > >> > > > > ----- Original Message ----- > >> > > > > From: Curtis Villamizar [mailto:curtis@occnc.com] > >> > > > > Sent: Thursday, August 04, 2011 06:38 AM > >> > > > > To: Shahram Davari > >> > > > > Cc: curtis@occnc.com ; Giles Heron > >> > > > > ; Thomas Nadeau ; > >> > > > > Yaakov Stein ; pwe3@ietf.org ; > >> > > > Robert > >> > > > > Rennison > >> > > > > Subject: Re: [PWE3] Poll for WG adoption of > >> > > > > draft-nadeau-pwe3-vccv-2-02.txt > >> > > > > > >> > > > > > >> > > > > In message > >> > > > > > >> > > > > >> > > > >> > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadc > >> > > > > om.com> > >> > > > > "Shahram Davari" writes: > >> > > > > > > >> > > > > > Hi Curtis, > >> > > > > > > >> > > > > > Even if we assume this format (which is not yet incorporated in > >> > > the > >> > > > > > fat-pw draft), then most hardware assume ACH is right after > >> > GAL. > >> > > In > >> > > > > > this case how is the HW supposed to examine the ACH channel > >> > Type > >> > > to > >> > > > > > decide how to process the packet? (unless you assume there is > >> > one > >> > > > > > engine that can process all OAM packet types such as BFD, AIS, > >> > > PSC, > >> > > > > > LSP-ping, LDI, LKR, LM, DM, etc) > >> > > > > > > >> > > > > > Thx > >> > > > > > Shahram > >> > > > > > >> > > > > > >> > > > > Shahram, > >> > > > > > >> > > > > This doesn't need to go in the fat-pw draft.  It needs to go into > >> > > the > >> > > > > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM > >> > > traffic > >> > > > > when some other feature, fat-pw or other, puts a label under the > >> > PW > >> > > > > label.  The GAL goes after the PW and before the other labels.  A > >> > > > > proper multipath distribution will skip any reserved label and > >> > use > >> > > > the > >> > > > > rest of the label stack to load balance.  This allows spraying > >> > > across > >> > > > > the entropy space or testing a spacific payload label stack that > >> > > has > >> > > > > yielded trouble. > >> > > > > > >> > > > > Hardware that assumes ACH is right after GAL when the S-bit is > >> > not > >> > > > set > >> > > > > on the GAL is broken. > >> > > > > > >> > > > > The payload (ACH) is after the BOS (aka S-bit = 1). > >> > > > > > >> > > > > The IETF has never been sympathetic of broken hardware and should > >> > > not > >> > > > > be since we would halt progress. > >> > > > > > >> > > > > If the hardware is broken, then the fat-pw label can be omitted > >> > but > >> > > > > only one path through any multipath would be tested.  It would > >> > > still > >> > > > > work for TP, but not work in general.  PW does not require TP. > >> > The > >> > > > > fat-pw work is explicitly done for multipath because multipath is > >> > > > used > >> > > > > a lot in deployed networks and isn't going away. > >> > > > > > >> > > > > Curtis > >> > > > > > >> > > > > > >> > > > > > -----Original Message----- > >> > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > >> > > > > > Sent: Wednesday, August 03, 2011 4:53 PM > >> > > > > > To: Shahram Davari > >> > > > > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > >> > > > > > pwe3@ietf.org; Robert Rennison > >> > > > > > Subject: Re: [PWE3] Poll for WG adoption of > >> > > > > > draft-nadeau-pwe3-vccv-2-02.txt > >> > > > > > > >> > > > > > > >> > > > > > In message > >> > > > > > > >> > > > > >> > <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa > >> > > > > > dcom.com> > >> > > > > > "Shahram Davari" writes: > >> > > > > > > > >> > > > > > > Hi Curtis, > >> > > > > > > > >> > > > > > > You are absolutely correct if there is no Entropy label. But > >> > > with > >> > > > > > > Entropy label most implementation assume a Entropy label to > >> > be > >> > > > BoS > >> > > > > > > and below the PW label. > >> > > > > > > > >> > > > > > > This draft doesn't even talk about whether the GAL should be > >> > > BoS > >> > > > > > > or the Entropy Label? In either case adding GAL would make > >> > the > >> > > > > > > packet un-parsable by most HW. > >> > > > > > > > >> > > > > > > Thx > >> > > > > > > Shahram > >> > > > > > > >> > > > > > > >> > > > > > That should be covered in this work.  At least it was covered > >> > in > >> > > WG > >> > > > > > email.  PW, then GAL, then fat-pw (aka Flow label, which is > >> > > > > > different from Entropy label in MPLS). > >> > > > > > > >> > > > > > 0                   1                   2                   3 > >> > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> > +-+ > >> > > > > > |                            PW Label > >> > | > >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> > +-+ > >> > > > > > |                              GAL > >> > | > >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> > +-+ > >> > > > > > |     ... additional labels (ie: fat-pw) may be present > >> > | > >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> > +-+ > >> > > > > > |0 0 0 1|Version|   Reserved    |  Associated Channel Type > >> > | > >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> > +-+ > >> > > > > > | > >> > | > >> > > > > > ~                        VCCV Message Body > >> > ~ > >> > > > > > | > >> > | > >> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> > +-+ > >> > > > > > > >> > > > > > The above would be a better choice.  The VCCV is always after > >> > the > >> > > > > > label entry with BOS (S-bit = 1). > >> > > > > > > >> > > > > > The flow label (or entropy label) must not be a reserved label. > >> > > > > > Therefore there is no ambiguity.  In draft-ietf-pwe3-fat-pw-07 > >> > > > > > section > >> > > > > > 1.2 (page 5) you will find. > >> > > > > > > >> > > > > >    Note that the flow label MUST NOT be an MPLS reserved label > >> > > > (values > >> > > > > >    in the range 0..15) [RFC3032], but is otherwise > >> > unconstrained > >> > > by > >> > > > the > >> > > > > >    protocol. > >> > > > > > > >> > > > > > > >> > > > > > The flow label below GAL is needed so that all data paths which > >> > > the > >> > > > > > PW can take are exercised by OAM (ie: LSP Ping used within > >> > VCCV). > >> > > > > > > >> > > > > > Curtis > >> > > > > > > >> > > > > > > >> > > > > > > -----Original Message----- > >> > > > > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > >> > > > > > > Sent: Wednesday, August 03, 2011 4:05 PM > >> > > > > > > To: Shahram Davari > >> > > > > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; > >> > > > > > > Robert Rennison > >> > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > >> > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > >> > > > > > > > >> > > > > > > > >> > > > > > > In message > >> > > > > > > > >> > > > <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.br > >> > > > > > > oadcom.com> > >> > > > > > > "Shahram Davari" writes: > >> > > > > > > > > >> > > > > > > > Giles, > >> > > > > > > > > >> > > > > > > > Adding GAL to PW requires HW change, so why not just add CW > >> > > and > >> > > > > > > > use VVCV Type 1?  Also what is wrong with TTL approach for > >> > > non- > >> > > > CW? > >> > > > > > > > > >> > > > > > > > Thx > >> > > > > > > > Shahram > >> > > > > > > > >> > > > > > > > >> > > > > > > Shahram, > >> > > > > > > > >> > > > > > > Adding GAL to an MPLS label stack requires hardware support. > >> > > The > >> > > > > > > hardware need not know if the label above the GAL is an MPLS > >> > > > label > >> > > > > > > or a PW label, just that the next label is GAL and the label > >> > > over > >> > > > > > > it is not a SWAP.  Unless we are talking about incredibly > >> > > > > > > inflexible parser hardware, like none I've encounted > >> > recently, > >> > > > > > > there should be no problem noticing a GAL below the POP or PW > >> > > > > > > label and then directing the packet to OAM processing.  Any > >> > > > > > > remaining labels must be removed and hopefully no > >> > > implementation > >> > > > > > > neglects to look for BOS before deciding where the payload is > >> > > > supposed to be. > >> > > > > > > > >> > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). > >> > > In > >> > > > > > > this case TTL-expire would occur where a label swap was > >> > called > >> > > > for > >> > > > > > > and a GAL would be below the label containing the expired > >> > TTL. > >> > > > > > > Since LDP can have transient loops, this avoids having lots > >> > of > >> > > > > > > packets sent to the OAM engine should such a loop occur in a > >> > > LDP > >> > > > signaled MPLS PSN. > >> > > > > > > > >> > > > > > > This yield one way to do OAM with or without CW.  A GAL label > >> > > is > >> > > > > > > below the label for which action is taken (POP or PW > >> > > termination) > >> > > > > > > or below a label for which TTL has expired.  This method > >> > > applied > >> > > > to LSP and PW. > >> > > > > > > > >> > > > > > > I think mandating CW would be just as good a solution, but > >> > one > >> > > > > > > that was rejected so this is the best we have. > >> > > > > > > > >> > > > > > > Curtis > >> > > > > > > > >> > > > > > > > >> > > > > > > > -----Original Message----- > >> > > > > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > >> > > > > > > > Sent: Wednesday, August 03, 2011 11:10 AM > >> > > > > > > > To: Thomas Nadeau; Shahram Davari > >> > > > > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > >> > > > > > > > Subject: Re: [PWE3] Poll for WG adoption of > >> > > > > > > > draft-nadeau-pwe3-vccv-2-02.txt > >> > > > > > > > > >> > > > > > > > Agreed - some operators won't want to use a CW, and on that > >> > > > > > > > basis I support this draft. > >> > > > > > > > > >> > > > > > > > Sure, it'll take a while to move away from the router alert > >> > > > > > > > label and TTL approaches, but the GAL approach is > >> > definitely > >> > > > > > > > better than either of those... > >> > > > > > > > > >> > > > > > > > Giles > >> > > > > > > > > >> > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > >> > > > >> > > > wrote: > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > >> > > > > > > > > > >> > > > > > > > >> Hi, > >> > > > > > > > >> > >> > > > > > > > >> I also donÄ…t support this draft since I donÄ…t think to > >> > > solve > >> > > > > > > > >> the problem we need yet a 4th type of VCCV. The best > >> > > > solution is to mandate CW. > >> > > > > > > > > > >> > > > > > > > > While I am with you, that argument went out the window > >> > > during > >> > > > > > > > > the debates we had over the past 3 IETF meetings. > >> > Operators > >> > > > > > > > > were very clear that they do not want to mandate the use > >> > of > >> > > a > >> > > > CW.   Hence, > >> > > > > > > > > Luca and I came up with this solution that narrows the > >> > > scope > >> > > > > > > > > to 2 modes, one that handles the CW case and one that > >> > > doesn't > >> > > > > > > > > while still both modes providing predictable OAM > >> > > capabilities > >> > > > > > > > > for the PW. > >> > > > > > > > > > >> > > > > > > > > --Tom > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > >> > >> > > > > > > > >> Shahram > >> > > > > > > > >> > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > >> > bounces@ietf.org] > >> > > > On > >> > > > > > > > >> Behalf Of Robert Rennison > >> > > > > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > >> > > > > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew > >> > > > > > > > >> (Matthew); pwe3@ietf.org > >> > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > >> > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > >> > > > > > > > >> > >> > > > > > > > >> I do Not support the draft, > >> > > > > > > > >> > >> > > > > > > > >> After hearing the results of the earlier user deployment > >> > > > > > > > >> poll I thought, Ĺ‚ ok  the way out of this mess is to > >> > > migrate > >> > > > > > > > >> towards using the CWË›. Then I see this proposal and > >> > > wondered > >> > > > > > > > >> what am I missing.  IÄ…ve still not seen the light of why > >> > > > > > > > >> adding a fourth type will simplify matters, hence in the > >> > > > > > > > >> absence of me understanding how this will simplify > >> > matter > >> > > > versus complicate things, IÄ…m against it. > >> > > > > > > > >> > >> > > > > > > > >> Rob > >> > > > > > > > >> > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > >> > bounces@ietf.org] > >> > > > On > >> > > > > > > > >> Behalf Of Alexander Vainshtein > >> > > > > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > >> > > > > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); > >> > pwe3@ietf.org > >> > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > >> > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > >> > > > > > > > >> > >> > > > > > > > >> Hi all, > >> > > > > > > > >> I do NOT support this draft for the same reasons that > >> > > Yaakov > >> > > > has indicated. > >> > > > > > > > >> > >> > > > > > > > >> Regards, > >> > > > > > > > >>      Sasha > >> > > > > > > > >> > >> > > > > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On > >> > > > Behalf > >> > > > > > > > >> Of Yaakov Stein [yaakov_s@rad.com] > >> > > > > > > > >> Sent: Friday, July 29, 2011 3:58 AM > >> > > > > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > >> > > > > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > >> > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > >> > > > > > > > >> > >> > > > > > > > >> I do not support !    and I can not understand how > >> > anyone > >> > > > can support it ! > >> > > > > > > > >> > >> > > > > > > > >> We do NOT need a fourth VCCV type, there are too many > >> > > > already. > >> > > > > > > > >> > >> > > > > > > > >> I completely agree with the part that says if there is a > >> > > CW > >> > > > > > > > >> then the ACh should be marked by it. > >> > > > > > > > >> > >> > > > > > > > >> I do NOT agree that if the CW is not used then we should > >> > > use > >> > > > > > > > >> a non-PW method developed for MPLS-TP. > >> > > > > > > > >> I do NOT agree that there is any way to deprecate the > >> > use > >> > > of > >> > > > > > > > >> TTL expiry to mark the ACh. > >> > > > > > > > >> I do NOT agree that we should change mechanisms that > >> > have > >> > > > > > > > >> been widely deployed for many years now, without an > >> > > > extremely > >> > > > > > > > >> pressing reason. > >> > > > > > > > >> > >> > > > > > > > >> Were the proposal to be that for PWs that traverse ONLY > >> > > > > > > > >> MPLS-TP to have the ADDITIONAL option for ACh marking, I > >> > > > > > > > >> might be convinced not to object as strongly. > >> > > > > > > > >> However, since I don't think that PWs can be limited in > >> > > this > >> > > > > > > > >> matter (the MPLS WG adopted the "seamless" draft) it > >> > would > >> > > > be > >> > > > > > > > >> difficult to convince me that such a limitation is > >> > > possible. > >> > > > > > > > >> > >> > > > > > > > >> I would have enthusiastically support this proposal had > >> > it > >> > > > > > > > >> been brought 8 years ago. > >> > > > > > > > >> It's too late for this now. > >> > > > > > > > >> > >> > > > > > > > >> Y(J)S > >> > > > > > > > >> > >> > > > > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3- > >> > bounces@ietf.org] > >> > > > On > >> > > > > > > > >> Behalf Of Bocci, Matthew (Matthew) > >> > > > > > > > >> Sent: Thursday, July 28, 2011 21:02 > >> > > > > > > > >> To: pwe3@ietf.org > >> > > > > > > > >> Subject: [PWE3] Poll for WG adoption of > >> > > > > > > > >> draft-nadeau-pwe3-vccv-2-02.txt > >> > > > > > > > >> > >> > > > > > > > >> This email begins a two week poll to help assess if > >> > there > >> > > is > >> > > > > > > > >> consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a > >> > > PWE3 > >> > > > working group draft. > >> > > > > > > > >> > >> > > > > > > > >> Please indicate whether or not you support adoption of > >> > > this > >> > > > > > > > >> draft, and also send any comments to the PWE3 list. > >> > > > > > > > >> > >> > > > > > > > >> This poll will end on Friday 12th August. > >> > > > > > > > >> > >> > > > > > > > >> Regards, > >> > > > > > > > >> > >> > > > > > > > >> Matthew & Andy > >> > > > > > > > >> 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. > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 From yshen@juniper.net Fri Aug 5 12:35: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 279871F0C4A; Fri, 5 Aug 2011 12:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.517, 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 04y7hyKm+jm9; Fri, 5 Aug 2011 12:35:29 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5E1F0C40; Fri, 5 Aug 2011 12:35:28 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTjxGEvnHwwqelLKrGxko2c14DqIkpE/X@postini.com; Fri, 05 Aug 2011 12:35:47 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 5 Aug 2011 12:35:44 -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; Fri, 5 Aug 2011 15:35:43 -0400 From: Yimin Shen To: "Henderickx, Wim (Wim)" , Rahul Aggarwal Date: Fri, 5 Aug 2011 15:35:40 -0400 Thread-Topic: draft-shen-pwe3-endpoint-fast-protection Thread-Index: AcxL1U7fI2okDnOnToe4ryNlXmqCWgH0SkSQ Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6719B82E37@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6719B82E37@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.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 Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] draft-shen-pwe3-endpoint-fast-protection 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, 05 Aug 2011 19:35:30 -0000 Hi Wim, Thanks for the comments. > 1. Will this solution support revertive as well as non-revertive > behavior after failure recovery. How will it work? [yshen] Yes, it will. After the recovery of AC or egress PE, the PLR should= re-install the forwarding entry of the primary path, and switch traffic fr= om the bypass LSP back to the primary path. Of course, local reversion may = be managed by policy on the PLR. > 2. Is the goal to make this solution applicable to MS-PW as well as > dynamic MS-PW FEC129. [yshen] Yes, the new defined "protection FEC element" can support FEC 129. = MS-PW is a good suggestion.=20 > 3. In general we should add some applicability in the draft. In certain > cases and depending on the applicability you could have un-optimized > traffic flows. > 5. We should discuss the RSVP procedures in this draft in the MPLS WG. >=20 [yshen] Good suggestions. Thanks, -Yimin > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Tuesday, July 26, 2011 4:48 PM > To: Yimin Shen; Rahul Aggarwal > Cc: pwe3@ietf.org; mpls@ietf.org > Subject: draft-shen-pwe3-endpoint-fast-protection >=20 > Regarding the draft I have following remarks/questions/suggestions > since we had no discussion on the mike today. >=20 > 1. Will this solution support revertive as well as non-revertive > behavior after failure recovery. How will it work? > 2. Is the goal to make this solution applicable to MS-PW as well as > dynamic MS-PW FEC129. > 3. In general we should add some applicability in the draft. In certain > cases and depending on the applicability you could have un-optimized > traffic flows. > 5. We should discuss the RSVP procedures in this draft in the MPLS WG. >=20 > Cheers, > Wim From yshen@juniper.net Fri Aug 5 13:18:18 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 76DCE5E8007 for ; Fri, 5 Aug 2011 13:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.945 X-Spam-Level: X-Spam-Status: No, score=-4.945 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz4j0ZP9Xk2Y for ; Fri, 5 Aug 2011 13:18:17 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id A176421F8B7E for ; Fri, 5 Aug 2011 13:18:15 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTjxQGQZHc/jJ3VZCdssPJR/5wMMd88hF@postini.com; Fri, 05 Aug 2011 13:18:35 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 5 Aug 2011 13:17:10 -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; Fri, 5 Aug 2011 16:17:09 -0400 From: Yimin Shen To: "Shah, Himanshu" , "pwe3@ietf.org" Date: Fri, 5 Aug 2011 16:17:06 -0400 Thread-Topic: draft-shen-pwe3-endpoint-fast-protection Thread-Index: AcxL2bwGcRIdFPF2To6qN/sR9YKbRQHzpTjA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_DF7F294AF4153D498141CBEFADB17704C2E190C442EMBX01WFjnprn_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [PWE3] draft-shen-pwe3-endpoint-fast-protection 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, 05 Aug 2011 20:18:18 -0000 --_004_DF7F294AF4153D498141CBEFADB17704C2E190C442EMBX01WFjnprn_ Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C2E190C442EMBX01WFjnprn_" --_000_DF7F294AF4153D498141CBEFADB17704C2E190C442EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Himanshu, That should be taken care of by global repair. The "local repair" proposed = in this draft should be used in conjunction with global repair. The purpose= is to provide fast protection before global repair takes effect (slow). Let's use the AC failure scenario to look at the direction of traffic you m= entioned. The CE attached to the failed AC should be able to detect the fai= lure via layer 2 technique or CE-PE OAM, and switch the traffic to the back= up AC and backup PW. Meanwhile, the remote CE can also detect the failure v= ia CE-CE OAM, and switch network direction traffic to backup AC and the bac= kup PW. This kind of switching to backup PW and coordination between the CE= s are part of global repair. Whatever techniques used here may continue to = apply. Thanks, -Yimin From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Sha= h, Himanshu Sent: Tuesday, July 26, 2011 5:20 PM To: pwe3@ietf.org Subject: [PWE3] draft-shen-pwe3-endpoint-fast-protection Yimin - The draft discusses protection schemes from the network perspective for a d= ual-homed CE. In the case of singled-sided protection failover from the networks (which i= s what is covered in the draft), how does CE handle the failover for the traffic in network d= irection (CE->protect-PE). Do you believe that a protection failover scheme that does not include part= icipation/coordination of dual-homed CE is a complete solution? Thanks, himanshu [cid:image001.gif@01CC5387.52F17CF0] --_000_DF7F294AF4153D498141CBEFADB17704C2E190C442EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Himanshu,

 

That should be taken care of by global repair. = The “local repair” proposed in this draft should be used in con= junction with global repair. The purpose is to provide fast protection befo= re global repair takes effect (slow).

 

Let’s use the AC failure scena= rio to look at the direction of traffic you mentioned. The CE attached to t= he failed AC should be able to detect the failure via layer 2 technique or = CE-PE OAM, and switch the traffic to the backup AC and backup PW. Meanwhile= , the remote CE can also detect the failure via CE-CE OAM, and switch netwo= rk direction traffic to backup AC and the backup PW. This kind of switching= to backup PW and coordination between the CEs are part of global repair. W= hatever techniques used here may continue to apply.

<= div>

 

Thanks,

 =

-Yimin<= o:p>

 

 

Fro= m: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = Shah, Himanshu
Sent: Tuesday, July 26, 2011 5:20 PM
To:= pwe3@ietf.org
Subject: [PWE3] draft-shen-pwe3-endpoint-fast-= protection

 = ;

Yimin –

 

The draft discusses protect= ion schemes from the network perspective for a dual-homed CE.

In the case of singled-sided protection failover from= the networks (which is what is covered

= in the draft), how does CE handle the failover for the traffic in network d= irection (CE->protect-PE).

 = ;

Do you believe that a protection failover s= cheme that does not include participation/coordination of dual-homed CE

is a complete solution?

 

Thanks,

himanshu


3D"ciena

= --_000_DF7F294AF4153D498141CBEFADB17704C2E190C442EMBX01WFjnprn_-- --_004_DF7F294AF4153D498141CBEFADB17704C2E190C442EMBX01WFjnprn_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=3410; creation-date="Fri, 05 Aug 2011 16:17:09 GMT"; modification-date="Fri, 05 Aug 2011 16:17:09 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= --_004_DF7F294AF4153D498141CBEFADB17704C2E190C442EMBX01WFjnprn_-- From pabloisnot@gmail.com Fri Aug 5 13:27: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 D033C21F8B8D; Fri, 5 Aug 2011 13:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.746, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_91=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 IJd95TqgXUVk; Fri, 5 Aug 2011 13:27:28 -0700 (PDT) Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id CA8F421F8B77; Fri, 5 Aug 2011 13:27:27 -0700 (PDT) Received: by qwb7 with SMTP id 7so1272181qwb.26 for ; Fri, 05 Aug 2011 13:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WRPAXAUDaqlNeVQESQffAJqFind3ONbnB18MCgw5VLs=; b=K6NQ7bbkQm85lUyX575gfuxMZn2/Gajlypuii3g8/hZ2spC/pj4XxULCVTKJZ43ct2 QSftPAF5ou5TunO6fzkniPFOq+fM7bTe1ObOF5jJvPfSCr1qpFfIzE7sw8HY1Sj5MUtl uob8KDzShcu77yDk8rc48InizzJ0vpLDECwv8= MIME-Version: 1.0 Received: by 10.224.194.68 with SMTP id dx4mr2163782qab.31.1312576063625; Fri, 05 Aug 2011 13:27:43 -0700 (PDT) Received: by 10.224.11.143 with HTTP; Fri, 5 Aug 2011 13:27:43 -0700 (PDT) In-Reply-To: <5E893DB832F57341992548CDBB333163A0AC0CD79C@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0AC0CCDD1@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A0AC0CD79C@EMBX01-HQ.jnpr.net> Date: Fri, 5 Aug 2011 16:27:43 -0400 Message-ID: From: Pablo Frank To: John E Drake Content-Type: multipart/alternative; boundary=20cf300fb1ad035a8c04a9c7ee12 Cc: "mpls@ietf.org" , "yaakov_s@rad.com" , "pwe3@ietf.org" , "Robert.Rennison@ecitele.com" Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 05 Aug 2011 20:27:31 -0000 --20cf300fb1ad035a8c04a9c7ee12 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks John, Some PF> questions/comments below: On Fri, Aug 5, 2011 at 12:50 PM, John E Drake wrote: > An application label is a label in which you expect to see BOS set but > which isn=92t, followed by an entropy label which is a non-reserved label= with > BOS set. Repeat as necessary. > PF> The term "application label" is used repeatedly through the draft but isn't really defined anywhere. I suggest that you and rest of the authors add a definition to the text. The definition that you give above doesn't make a lot of sense to me since I don't know how to interpret "expect to se= e a BOS set but which isn't". I've interpreted application label to refer to the LSP for which the ingress LSR parsed the payload and generated an entropy label. I don't think the GAL (or any other reserved label) falls into this category. I think you may have to update 4.3 to say something about how reserved labels are skipped until you find the first non-reserved label and pop that as your entropy label. Ugh. > As both Curtis and I have said, in order to process the GAL payload > correctly, the stack above the GAL should be the same whether or not an > entropy label is present. > PF> I assume that any multi-path capable router's OAM implementation will b= e aware of (and possibly even care about) the entropy labels regardless of where they are in the label stack. Or are you worried about transit nodes who's OAM implementation may not be entropy-label aware? > Sent from my iPhone**** > > ** ** > > *From:* Pablo Frank [mailto:pabloisnot@gmail.com] > *Sent:* Friday, August 05, 2011 9:02 AM > *To:* John E Drake > *Cc:* curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; > Robert.Rennison@ecitele.com; mpls@ietf.org > *Subject:* Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt)**** > > ** ** > > So I read the draft but could not see the justification. In fact, I > believe there's actually a flaw with what's proposed. **** > > ** ** > > Section 6 (OAM and Entropy Labels) suggests that by setting S=3D0 and pla= cing > the GAL above the entropy label, that this makes it "effectively function= as > an application label". But this is not so. The GAL is an extra label th= at > would normally sit below the application label. Application labels that = are > expecting entropy labels are identified in your proposal either explicitl= y > in the LFIB or implicitly by the presence of an ELI after the AL. In eit= her > case, it's the label(s) above the GAL that trigger entropy label handling= , > not the GAL itself.**** > > ** ** > > Then following the procedures in 4.3, the Egress LSR would inspect the S > bit of the application/ELI label, and according to the text, would then p= op > the next label, assuming it was an entropy label. Unfortunately, you've = now > popped the GAL and what's really left is the entropy label.**** > > ** ** > > It seems to me that we've gotten here because the GAL and Entropy label > both want to be the BOS. You've tried to get around it by relaxing the B= OS > restriction on GAL but I think it works much more cleanly if you go the > other way. Instead of saying that Entropy labels always need to be BOS, = why > not simply say that they must immediately follow the application/ELI labe= l? > That way, the procedures in 4.3 always work trivially. A router that do= es > not understand or expect entropy labels doesn't need to be confused by > strange labels following the GAL, and the hardware implementations likely > will be simpler (and cheaper). It also means I can > build hierarchical multipath LSPs if I really want to... :-)**** > > ** ** > > regards,**** > > Pablo**** > > ** ** > > On Thu, Aug 4, 2011 at 2:36 PM, John E Drake wrote:*= * > ** > > Pablo,**** > > **** > > At least wrt entropy label, the reasons why it needs to be at the bottom = of > stack are detailed in the draft in some detail. The GAL is in exactly th= e > same place in the stack relative to the labels above it whether or not th= e > entropy label is used. The fact that the bottom of stack bit is not set = in > the GAL tells the egress that an entropy label is present in the stack af= ter > it and needs to be discarded.l **** > > **** > > Thanks,**** > > **** > > John **** > > **** > > Sent from my iPhone**** > > **** > > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On Behalf O= f > *Pablo Frank > *Sent:* Thursday, August 04, 2011 11:24 AM > *To:* curtis@occnc.com > *Cc:* yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitele.com > *Subject:* Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt)**** > > **** > > Curtis,**** > > **** > > Why does it matter if the entropy/flow labels are above or below the GAL? > What advantage is gained by putting such labels below the GAL?**** > > **** > > To me, putting the GAL in-between the PW (or LSP) label and the Flow (or > Entropy) label just feels out of place. I should only really care about = a > GAL if I encounter it as a result of disposing of the labels either becau= se > they've been popped or because the TTL has expired. When the PW label ge= ts > terminated and all of a sudden, I encounter a GAL, it seems awkward becau= se > in my mind, I have not finished terminating the PW layer. There is still > this flow label that I need to dispose of... so the hardware has to remem= ber > that it saw a GAL and continue processing labels. It seems much cleaner = if > we finish dealing with the multipath labels before considering whether it= 's > carrying normal data or an associated channel. **** > > **** > > If anything, I see an advantage in having the GAL below the flow label > because it allows the option of monitoring individual paths (assuming, of > course, that GAL is excluded from the hash).**** > > **** > > regards,**** > > Pablo**** > > **** > > ----- Original Message ----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: Thursday, August 04, 2011 06:38 AM > To: Shahram Davari > Cc: curtis@occnc.com ; Giles Heron < > giles.heron@gmail.com>; Thomas Nadeau ; Yaakov > Stein ; pwe3@ietf.org ; Robert Rennison = < > Robert.Rennison@ecitele.com> > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > > > In message < > 2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.c= om > > > "Shahram Davari" writes: > > > > Hi Curtis, > > > > Even if we assume this format (which is not yet incorporated in the > > fat-pw draft), then most hardware assume ACH is right after GAL. In > > this case how is the HW supposed to examine the ACH channel Type to > > decide how to process the packet? (unless you assume there is one > > engine that can process all OAM packet types such as BFD, AIS, PSC, > > LSP-ping, LDI, LKR, LM, DM, etc) > > > > Thx > > Shahram > > > Shahram, > > This doesn't need to go in the fat-pw draft. It needs to go into the > draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic > when some other feature, fat-pw or other, puts a label under the PW > label. The GAL goes after the PW and before the other labels. A > proper multipath distribution will skip any reserved label and use the > rest of the label stack to load balance. This allows spraying across > the entropy space or testing a spacific payload label stack that has > yielded trouble. > > Hardware that assumes ACH is right after GAL when the S-bit is not set > on the GAL is broken. > > The payload (ACH) is after the BOS (aka S-bit =3D 1). > > The IETF has never been sympathetic of broken hardware and should not > be since we would halt progress. > > If the hardware is broken, then the fat-pw label can be omitted but > only one path through any multipath would be tested. It would still > work for TP, but not work in general. PW does not require TP. The > fat-pw work is explicitly done for multipath because multipath is used > a lot in deployed networks and isn't going away. > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, August 03, 2011 4:53 PM > > To: Shahram Davari > > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; > pwe3@ietf.org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > In message < > 2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broadcom.c= om > > > > "Shahram Davari" writes: > > > > > > Hi Curtis, > > > > > > You are absolutely correct if there is no Entropy label. But with > > > Entropy label most implementation assume a Entropy label to be BoS an= d > > > below the PW label. > > > > > > This draft doesn't even talk about whether the GAL should be BoS or > > > the Entropy Label? In either case adding GAL would make the packet > > > un-parsable by most HW. > > > > > > Thx > > > Shahram > > > > > > That should be covered in this work. At least it was covered in WG > > email. PW, then GAL, then fat-pw (aka Flow label, which is different > > from Entropy label in MPLS). > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PW Label | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GAL | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ... additional labels (ie: fat-pw) may be present | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0 0 0 1|Version| Reserved | Associated Channel Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ VCCV Message Body ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > The above would be a better choice. The VCCV is always after the > > label entry with BOS (S-bit =3D 1). > > > > The flow label (or entropy label) must not be a reserved label. > > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > > 1.2 (page 5) you will find. > > > > Note that the flow label MUST NOT be an MPLS reserved label (values > > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > > protocol. > > > > > > The flow label below GAL is needed so that all data paths which the PW > > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > > > Curtis > > > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, August 03, 2011 4:05 PM > > > To: Shahram Davari > > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert > Rennison > > > Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > > In message < > 2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.c= om > > > > > "Shahram Davari" writes: > > > > > > > > Giles, > > > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > > > Thx > > > > Shahram > > > > > > > > > Shahram, > > > > > > Adding GAL to an MPLS label stack requires hardware support. The > > > hardware need not know if the label above the GAL is an MPLS label or > > > a PW label, just that the next label is GAL and the label over it is > > > not a SWAP. Unless we are talking about incredibly inflexible parser > > > hardware, like none I've encounted recently, there should be no > > > problem noticing a GAL below the POP or PW label and then directing > > > the packet to OAM processing. Any remaining labels must be removed > > > and hopefully no implementation neglects to look for BOS before > > > deciding where the payload is supposed to be. > > > > > > TTL is best reserved for traceroute only (in the MS-PW case). In thi= s > > > case TTL-expire would occur where a label swap was called for and a > > > GAL would be below the label containing the expired TTL. Since LDP > > > can have transient loops, this avoids having lots of packets sent to > > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > > > This yield one way to do OAM with or without CW. A GAL label is belo= w > > > the label for which action is taken (POP or PW termination) or below = a > > > label for which TTL has expired. This method applied to LSP and PW. > > > > > > I think mandating CW would be just as good a solution, but one that > > > was rejected so this is the best we have. > > > > > > Curtis > > > > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > > To: Thomas Nadeau; Shahram Davari > > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Rennison > > > > Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > > > > > Agreed - some operators won't want to use a CW, and on that basis I > support > > > > this draft. > > > > > > > > Sure, it'll take a while to move away from the router alert label a= nd > TTL > > > > approaches, but the GAL approach is definitely better than either o= f > > > > those... > > > > > > > > Giles > > > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > wrote: > > > > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I also don=B9t support this draft since I don=B9t think to solve= the > problem we > > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > > > While I am with you, that argument went out the window during the > debates we > > > > > had over the past 3 IETF meetings. Operators > > > > > were very clear that they do not want to mandate the use of a CW. > Hence, > > > > > Luca and I came up with this solution that narrows the > > > > > scope to 2 modes, one that handles the CW case and one that doesn= 't > while > > > > > still both modes providing predictable OAM capabilities > > > > > for the PW. > > > > > > > > > > --Tom > > > > > > > > > > > > > > >> > > > > >> Shahram > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of > > > > >> Robert Rennison > > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew)= ; > > > > >> pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> I do Not support the draft, > > > > >> > > > > >> After hearing the results of the earlier user deployment poll I > thought, > > > > >> =B3 ok the way out of this mess is to migrate towards using the > CW=B2. Then I > > > > >> see this proposal and wondered what am I missing. I=B9ve still = not > seen the > > > > >> light of why adding a fourth type will simplify matters, hence i= n > the absence > > > > >> of me understanding how this will simplify matter versus > complicate things, > > > > >> I=B9m against it. > > > > >> > > > > >> Rob > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of > > > > >> Alexander Vainshtein > > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> Hi all, > > > > >> I do NOT support this draft for the same reasons that Yaakov has > indicated. > > > > >> > > > > >> Regards, > > > > >> Sasha > > > > >> > > > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of > Yaakov Stein > > > > >> [yaakov_s@rad.com] > > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > > >> Subject: Re: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> I do not support ! and I can not understand how anyone can > support it ! > > > > >> > > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > > >> > > > > >> I completely agree with the part that says if there is a CW then > the ACh > > > > >> should be marked by it. > > > > >> > > > > >> I do NOT agree that if the CW is not used then we should use a > non-PW method > > > > >> developed for MPLS-TP. > > > > >> I do NOT agree that there is any way to deprecate the use of TTL > expiry to > > > > >> mark the ACh. > > > > >> I do NOT agree that we should change mechanisms that have been > widely > > > > >> deployed for many years now, > > > > >> without an extremely pressing reason. > > > > >> > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP = to > have the > > > > >> ADDITIONAL option > > > > >> for ACh marking, I might be convinced not to object as strongly. > > > > >> However, since I don't think that PWs can be limited in this > matter (the MPLS > > > > >> WG adopted the "seamless" draft) > > > > >> it would be difficult to convince me that such a limitation is > possible. > > > > >> > > > > >> I would have enthusiastically support this proposal had it been > brought 8 > > > > >> years ago. > > > > >> It's too late for this now. > > > > >> > > > > >> Y(J)S > > > > >> > > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of > > > > >> Bocci, Matthew (Matthew) > > > > >> Sent: Thursday, July 28, 2011 21:02 > > > > >> To: pwe3@ietf.org > > > > >> Subject: [PWE3] Poll for WG adoption of > draft-nadeau-pwe3-vccv-2-02.txt > > > > >> > > > > >> This email begins a two week poll to help assess if there is > consensus to > > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group > draft. > > > > >> > > > > >> Please indicate whether or not you support adoption of this draf= t, > and also > > > > >> send any comments to the PWE3 list. > > > > >> > > > > >> This poll will end on Friday 12th August. > > > > >> > > > > >> Regards, > > > > >> > > > > >> Matthew & Andy > > > > >> This e-mail message is intended for the recipient only and > contains > > > > >> information which is CONFIDENTIAL and which may be proprietary t= o > 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 copie= s > thereof. > > > > >> This e-mail message is intended for the recipient only and > contains > > > > >> information which is CONFIDENTIAL and which may be proprietary t= o > 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 copie= s > thereof. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3**** > > **** > > ** ** > --20cf300fb1ad035a8c04a9c7ee12 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks John,

Some PF> questions/comments below:
=

On Fri, Aug 5, 2011 at 12:50 PM, John E= Drake <jdrake@j= uniper.net> wrote:

An application label is a label in which you expect to see BOS set = but which isn=92t, followed by an entropy label which is a non-reserved lab= el with BOS set.=A0 Repeat as necessary.


PF> The term "applicat= ion label" is used repeatedly through the draft but isn't really d= efined anywhere. =A0I suggest that you and rest of the authors add a defini= tion to the text. =A0The definition that you give above doesn't make a = lot of sense to me since I don't know how to interpret "expect to = see a BOS set but which isn't". =A0I've interpreted applicatio= n label to refer to the LSP for which the ingress LSR parsed the payload an= d generated an entropy label. =A0 I don't think the GAL (or any other r= eserved label) falls into this category. =A0I think you may have to update = 4.3 to say something about how reserved labels are skipped until you find t= he first non-reserved label and pop that as your entropy label. =A0Ugh.
=A0=A0

= As both Curtis and I have said, in order to process the GAL payload correct= ly, the stack above the GAL should be the same whether or not an entropy la= bel is present.


PF> I assume that any multi= -path capable router's OAM implementation will be aware of (and possibl= y even care about) the entropy labels regardless of where they are in the l= abel stack. =A0Or are you worried about transit nodes who's OAM impleme= ntation may not be entropy-label aware?
=A0=A0

= Sent from my iPhone

=A0

Fr= om: Pablo Frank [mailto:pabloisnot@gmail.com= ]
Sent: Friday, August 05, 2011 9:02 AM
To: John E Drake
= Cc: curtis@occ= nc.com; yaakov_s@= rad.com; pwe3@ietf.o= rg; Ro= bert.Rennison@ecitele.com; mpls@ietf.org
Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption o= f draft-nadeau-pwe3-vccv-2-02.txt)

=A0

So I re= ad the draft but could not see the justification. =A0In fact,=A0I believe t= here's actually a flaw with what's proposed. =A0

=A0

Section 6 (OAM and Entropy Labels) suggests that by setting S=3D0 a= nd placing the GAL above the entropy label, that this makes it "effect= ively function as an application label". =A0But this is not so. =A0The= GAL is an extra label that would normally sit below the application label.= =A0Application labels that are expecting entropy labels are identified in = your proposal either explicitly in the LFIB or implicitly by the presence o= f an ELI after the AL. =A0In either case, it's the label(s) above the G= AL that trigger entropy label handling, not the GAL itself.

=A0

Then following the procedures in 4.3, the Egress LSR would inspect = the S bit of the application/ELI label, and according to the text, would th= en pop the next label, assuming it was an entropy label. =A0Unfortunately, = you've now popped the GAL and what's really left is the entropy lab= el.

=A0

It seems to me that we've gotten here because the GAL an= d Entropy label both want to be the BOS. =A0You've tried to get around = it by relaxing the BOS restriction on GAL but I think it works much more cl= eanly if you go the other way. =A0Instead of saying that Entropy labels alw= ays need to be BOS, why not simply say that they must immediately follow th= e application/ELI label? =A0That way, the procedures in 4.3 always work tri= vially. =A0A router that does not understand or expect entropy labels doesn= 't need to be confused by strange labels following the GAL, and the har= dware implementations likely will be simpler (and cheaper). =A0It also mean= s I can build=A0hierarchical=A0multipath LSPs if I really want to... :-)=

=A0

regards,

= Pablo

=A0=

On Thu, Aug 4, 2011 at 2:36 PM, John E Drake <jdrake@juniper.net= > wrote:

Pablo,

=A0

At least wrt entropy label, the reasons why it needs to b= e at the bottom of stack are detailed in the draft in some detail.=A0 The G= AL is in exactly the same place in the stack relative to the labels above i= t whether or not the entropy label is used.=A0 The fact that the bottom of = stack bit is not set in the GAL tells the egress that an entropy label is p= resent in the stack after it and needs to be discarded.l=A0 <= u>

=A0

Thanks,

=A0

John =

=A0

Sent from my iPhone

=A0

From:= pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf= Of Pablo Frank
Sent: Thursday, August 04, 2011 11:24 AM
To: curtis@occnc.com
Cc:= yaakov_s@rad.com= ; pwe3@ietf.org; Robert.Rennis= on@ecitele.com
Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption o= f draft-nadeau-pwe3-vccv-2-02.txt)

=A0

Curtis,

=A0

Why does it matter if the entropy/flow labels are above or below th= e GAL? =A0What advantage is gained by putting such labels below the GAL?=

=A0

To me, putting the GAL in-between the PW (or LSP) label and = the Flow (or Entropy) label just feels out of place. =A0I should only reall= y care about a GAL if I encounter it as a result of disposing of the labels= either because they've been popped or because the TTL has expired. =A0= When the PW label gets terminated and all of a sudden, I encounter a GAL, i= t seems awkward because in my mind, I have not finished terminating the PW = layer. =A0There is still this flow label that I need to dispose of... so th= e hardware has to remember that it saw a GAL and continue processing labels= . =A0It seems much cleaner if we finish dealing with the multipath labels b= efore considering whether it's carrying normal data or an associated ch= annel. =A0

=A0

If anything, I see an advantage in having the GAL below the = flow label because it allows the option of monitoring individual paths (ass= uming, of course, that GAL is excluded from the hash).

=A0

regards,

= Pablo

=A0<= /p>

----- Original Message -----
From: Curtis Villami= zar [mailto:curtis@oc= cnc.com]
Sent: Thursday, August 04, 2011 06:38 AM
To: Shahram Dav= ari
Cc: curtis@occnc.com<= /a> <curtis@occnc.= com>; Giles Heron <giles.heron@gmail.com>; Thomas Nadeau <tnadeau@lucidvision.com= >; Yaakov Stein <yaakov_s@rad.com>; pwe3@ietf.org <pwe3@ietf.org>; Robert Rennison <Robert.Rennison@ecitele.com>
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt=


In message <2C2F1EBA80= 50E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes:
>
> Hi Curtis,
>
&g= t; Even if we assume this format (which is not yet incorporated in the
&= gt; fat-pw draft), then most hardware assume ACH is right after GAL. In
> this case how is the HW supposed to examine the ACH channel Type to> decide how to process the packet? (unless you assume there is one
= > engine that can process all OAM packet types such as BFD, AIS, PSC, > LSP-ping, LDI, LKR, LM, DM, etc)
>
> Thx
> Shahram

Shahram,

This doesn't need to go in the fat-pw draft. = =A0It needs to go into the
draft-nadeau-pwe3-vccv-2-02 draft because it = only affects OAM traffic
when some other feature, fat-pw or other, puts a label under the PW
labe= l. =A0The GAL goes after the PW and before the other labels. =A0A
proper= multipath distribution will skip any reserved label and use the
rest of= the label stack to load balance. =A0This allows spraying across
the entropy space or testing a spacific payload label stack that has
yie= lded trouble.

Hardware that assumes ACH is right after GAL when the = S-bit is not set
on the GAL is broken.

The payload (ACH) is after= the BOS (aka S-bit =3D 1).

The IETF has never been sympathetic of broken hardware and should notbe since we would halt progress.

If the hardware is broken, then t= he fat-pw label can be omitted but
only one path through any multipath w= ould be tested. =A0It would still
work for TP, but not work in general. =A0PW does not require TP. =A0The
= fat-pw work is explicitly done for multipath because multipath is used
a= lot in deployed networks and isn't going away.

Curtis

> -----Original Message-----
> From: curtis@occnc.com [mailto:curtis@occnc.com]
> Sent: Wednes= day, August 03, 2011 4:53 PM
> To: Shahram Davari
> Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Ste= in; pwe3@ietf.org; R= obert Rennison
> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-0= 2.txt
>
>
> In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broa= dcom.com>
> "Shahram Davari" writes:
> >
> > Hi Curtis= ,
> >
> > You are absolutely correct if there is no Entro= py label. But with
> > Entropy label most implementation assume a = Entropy label to be BoS and
> > below the PW label.
> >
> > This draft doesn= 9;t even talk about whether the GAL should be BoS or
> > the Entro= py Label? In either case adding GAL would make the packet
> > un-p= arsable by most HW.
> >
> > Thx
> > Shahram
>
>
> Tha= t should be covered in this work. =A0At least it was covered in WG
> = email. =A0PW, then GAL, then fat-pw (aka Flow label, which is different
> from Entropy label in MPLS).
>
> 0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4= 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PW Label =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> +-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0GAL =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&= gt; | =A0 =A0 ... additional labels (ie: fat-pw) may be present =A0 =A0 =A0= =A0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
> |0 0 0 1|Version| =A0 Reserved =A0 =A0| =A0Associated Channel Type =A0= =A0 =A0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> ~ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0VCCV Message Body =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0~
> | =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> The above would be a better choice. =A0The VCCV is always afte= r the
> label entry with BOS (S-bit =3D 1).
>
> The flow = label (or entropy label) must not be a reserved label.
> Therefore th= ere is no ambiguity. =A0In draft-ietf-pwe3-fat-pw-07 section
> 1.2 (page 5) you will find.
>
> =A0 =A0Note that the flow = label MUST NOT be an MPLS reserved label (values
> =A0 =A0in the rang= e 0..15) [RFC3032], but is otherwise unconstrained by the
> =A0 =A0pr= otocol.
>
>
> The flow label below GAL is needed so that all data pa= ths which the PW
> can take are exercised by OAM (ie: LSP Ping used w= ithin VCCV).
>
> Curtis
>
>
> > -----Origi= nal Message-----
> > From: curti= s@occnc.com [mailto:curtis@occnc.com]
> > Sent: Wednesday, August 03, 2011 4:05= PM
> > To: Shahram Davari
> > Cc: Giles Heron; Thomas Nadeau; Y= aakov Stein; pwe3@ietf.o= rg; Robert Rennison
> > Subject: Re: [PWE3] Poll for WG adopti= on of draft-nadeau-pwe3-vccv-2-02.txt
> >
> >
> > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.a= d.broadcom.com>
> > "Shahram Davari" writes:
> > >
> >= > Giles,
> > >
> > > Adding GAL to PW requires = HW change, so why not just add CW and use
> > > VVCV Type 1? = =A0Also what is wrong with TTL approach for non-CW?
> > >
> > > Thx
> > > Shahram
> >=
> >
> > Shahram,
> >
> > Adding GAL to= an MPLS label stack requires hardware support. =A0The
> > hardwar= e need not know if the label above the GAL is an MPLS label or
> > a PW label, just that the next label is GAL and the label over it= is
> > not a SWAP. =A0Unless we are talking about incredibly infl= exible parser
> > hardware, like none I've encounted recently,= there should be no
> > problem noticing a GAL below the POP or PW label and then directi= ng
> > the packet to OAM processing. =A0Any remaining labels must = be removed
> > and hopefully no implementation neglects to look fo= r BOS before
> > deciding where the payload is supposed to be.
> >
>= ; > TTL is best reserved for traceroute only (in the MS-PW case). =A0In = this
> > case TTL-expire would occur where a label swap was called= for and a
> > GAL would be below the label containing the expired TTL. =A0Since= LDP
> > can have transient loops, this avoids having lots of pack= ets sent to
> > the OAM engine should such a loop occur in a LDP s= ignaled MPLS PSN.
> >
> > This yield one way to do OAM with or without CW. =A0= A GAL label is below
> > the label for which action is taken (POP = or PW termination) or below a
> > label for which TTL has expired.= =A0This method applied to LSP and PW.
> >
> > I think mandating CW would be just as good a solutio= n, but one that
> > was rejected so this is the best we have.
&= gt; >
> > Curtis
> >
> >
> > > --= ---Original Message-----
> > > From: Giles Heron [mailto:giles.heron@gmail.com]
> > > Sent:= Wednesday, August 03, 2011 11:10 AM
> > > To: Thomas Nadeau; S= hahram Davari
> > > Cc: pwe3@= ietf.org; Yaakov Stein; Robert Rennison
> > > Subject: Re: = [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
> >= >
> > > Agreed - some operators won't want to use a CW, and on t= hat basis I support
> > > this draft.
> > >
>= > > Sure, it'll take a while to move away from the router alert = label and TTL
> > > approaches, but the GAL approach is definitely better than e= ither of
> > > those...
> > >
> > > Gil= es
> > >
> > > On 02/08/2011 12:59, "Thomas Na= deau" <tnadeau@lucidvision.com> wrote:
> > >
> > > >
> > > > On Aug 1, 2011= , at 6:28 PM, Shahram Davari wrote:
> > > >
> > >= ; >> Hi,
> > > >>
> > > >> I also= don=B9t support this draft since I don=B9t think to solve the problem we > > > >> need yet a 4th type of VCCV. The best solution is t= o mandate CW.
> > > >
> > > > While I am with= you, that argument went out the window during the debates we
> > = > > had over the past 3 IETF meetings. Operators
> > > > were very clear that they do not want to mandate the us= e of a CW. =A0 Hence,
> > > > Luca and I came up with this s= olution that narrows the
> > > > scope to 2 modes, one that = handles the CW case and one that doesn't while
> > > > still both modes providing predictable OAM capabilities=
> > > > for the PW.
> > > >
> > >= ; > --Tom
> > > >
> > > >
> > >= ; >>
> > > >> Shahram
> > > >>
> > >= ; >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> > > >> Robert Rennison
> > > >> Sent: Su= nday, July 31, 2011 7:40 PM
> > > >> To: Alexander Vainsh= tein; Yaakov Stein; Bocci, Matthew (Matthew);
> > > >> pwe3@ietf.org
> > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-n= adeau-pwe3-vccv-2-02.txt
> > > >>
> > > >&= gt; I do Not support the draft,
> > > >>
> > >= ; >> After hearing the results of the earlier user deployment =A0poll= I thought,
> > > >> =B3 ok =A0the way out of this mess is to migrate to= wards using the CW=B2. Then I
> > > >> see this proposal = and wondered what am I missing. =A0I=B9ve still not seen the
> > &= gt; >> light of why adding a fourth type will simplify matters, hence= in the absence
> > > >> of me understanding how this will simplify matter v= ersus complicate things,
> > > >> I=B9m against it.
&g= t; > > >>
> > > >> Rob
> > > >= >
> > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
= > > > >> Alexander Vainshtein
> > > >> Sent: Sunday, July 31, 2011 12:45 AM
> > &= gt; >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org
> > > >&g= t; Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt
> > > >>
> > > >> Hi all,
> > >= ; >> I do NOT support this draft for the same reasons that Yaakov has= indicated.
> > > >>
> > > >> Regards,<= br> > > > >> =A0 =A0 =A0Sasha
> > > >>
>= > > >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein=
> > > >> [yaakov_s@rad.com]
> > > >> Sent: Friday, July 29,= 2011 3:58 AM
> > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org
> > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-n= adeau-pwe3-vccv-2-02.txt
> > > >>
> > > >&= gt; I do not support ! =A0 =A0and I can not understand how anyone can suppo= rt it !
> > > >>
> > > >> We do NOT need a fourth = VCCV type, there are too many already.
> > > >>
> &= gt; > >> I completely agree with the part that says if there is a = CW then the ACh
> > > >> should be marked by it.
> > > >><= br>> > > >> I do NOT agree that if the CW is not used then w= e should use a non-PW method
> > > >> developed for MPLS-= TP.
> > > >> I do NOT agree that there is any way to deprecate t= he use of TTL expiry to
> > > >> mark the ACh.
> &g= t; > >> I do NOT agree that we should change mechanisms that have = been widely
> > > >> deployed for many years now,
> > > >= > without an extremely pressing reason.
> > > >>
&g= t; > > >> Were the proposal to be that for PWs that traverse ON= LY MPLS-TP to have the
> > > >> ADDITIONAL option
> > > >> for AC= h marking, I might be convinced not to object as strongly.
> > >= ; >> However, since I don't think that PWs can be limited in this= matter (the MPLS
> > > >> WG adopted the "seamless" draft)
> = > > >> it would be difficult to convince me that such a limitat= ion is possible.
> > > >>
> > > >> I wo= uld have enthusiastically support this proposal had it been brought 8
> > > >> years ago.
> > > >> It's too = late for this now.
> > > >>
> > > >> Y(= J)S
> > > >>
> > > >> From: pwe3-bounces@ietf.org [= mailto:pwe3-boun= ces@ietf.org] On Behalf Of
> > > >> Bocci, Matthew (Matthew)
> > > >>= Sent: Thursday, July 28, 2011 21:02
> > > >> To: pwe3@ietf.org
> > = > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vcc= v-2-02.txt
> > > >>
> > > >> This email begins a two = week poll to help assess if there is consensus to
> > > >>= ; adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft.
> > > >>
> > > >> Please indicate whether = or not you support adoption of this draft, and also
> > > >&= gt; send any comments to the PWE3 list.
> > > >>
> = > > >> This poll will end on Friday 12th August.
> > > >>
> > > >> Regards,
> > &g= t; >>
> > > >> Matthew & Andy
> > >= >> This e-mail message is intended for the recipient only and contai= ns
> > > >> 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 o= nly and contains
> > > >> information which is CONFIDENTI= AL 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
ht= tps://www.ietf.org/mailman/listinfo/pwe3

=

=A0

<= /div>

=A0

<= /div>

--20cf300fb1ad035a8c04a9c7ee12-- From jdrake@juniper.net Sat Aug 6 05: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 1E2A521F8801; Sat, 6 Aug 2011 05:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.773 X-Spam-Level: X-Spam-Status: No, score=-5.773 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_91=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 PlZ3KnTql4Gj; Sat, 6 Aug 2011 05:54:05 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id C2ED421F8829; Sat, 6 Aug 2011 05:54:02 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTj05bx7mWBcwkdNVRZ/HkRACGfxuCHER@postini.com; Sat, 06 Aug 2011 05:54:25 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Sat, 6 Aug 2011 05:53:08 -0700 From: John E Drake To: Pablo Frank Date: Sat, 6 Aug 2011 05:53:03 -0700 Thread-Topic: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt) Thread-Index: AcxTriM0PYye4q80SqC3V6mjP8yhMgAhceEA Message-ID: <5E893DB832F57341992548CDBB333163A0AC1DD80D@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0AC0CCDD1@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A0AC0CD79C@EMBX01-HQ.jnpr.net> 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_5E893DB832F57341992548CDBB333163A0AC1DD80DEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "yaakov_s@rad.com" , "pwe3@ietf.org" , "Robert.Rennison@ecitele.com" Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 06 Aug 2011 12:54:16 -0000 --_000_5E893DB832F57341992548CDBB333163A0AC1DD80DEMBX01HQjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sent from my iPhone From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Friday, August 05, 2011 1:28 PM To: John E Drake Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecit= ele.com; mpls@ietf.org Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) Thanks John, Some PF> questions/comments below: On Fri, Aug 5, 2011 at 12:50 PM, John E Drake > wrote: An application label is a label in which you expect to see BOS set but whic= h isn't, followed by an entropy label which is a non-reserved label with BO= S set. Repeat as necessary. PF> The term "application label" is used repeatedly through the draft but i= sn't really defined anywhere. I suggest that you and rest of the authors a= dd a definition to the text. The definition that you give above doesn't ma= ke a lot of sense to me since I don't know how to interpret "expect to see = a BOS set but which isn't". I've interpreted application label to refer to= the LSP for which the ingress LSR parsed the payload and generated an entr= opy label. I don't think the GAL (or any other reserved label) falls into= this category. I think you may have to update 4.3 to say something about = how reserved labels are skipped until you find the first non-reserved label= and pop that as your entropy label. Ugh. JD: I am told this is the way most hardware developed over the past fifte= en works - first scan stack for the label with the BOS set and then get to= work. The original text was written several years ago and the GAL materia= l added about a year ago, so there is probably some additional text editing= required. Btw, as RFC5586 indicates, there is no technical reason for th= e GAL to be BOS. As both Curtis and I have said, in order to process the GAL payload correct= ly, the stack above the GAL should be the same whether or not an entropy la= bel is present. PF> I assume that any multi-path capable router's OAM implementation will b= e aware of (and possibly even care about) the entropy labels regardless of = where they are in the label stack. Or are you worried about transit nodes = who's OAM implementation may not be entropy-label aware? JD: LSP Traceroute (the control plane) needs to be updated because its usa= ge of labels, as opposed to IP addresses, has some issues. The data plane,= by design, is completely oblivious to entropy labels and I am told that m= ost existing hardware does not use reserved labels in load balancing. Sent from my iPhone From: Pablo Frank [mailto:pabloisnot@gmail.com= ] Sent: Friday, August 05, 2011 9:02 AM To: John E Drake Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitele= .com; mpls@ietf.org Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) So I read the draft but could not see the justification. In fact, I believ= e there's actually a flaw with what's proposed. Section 6 (OAM and Entropy Labels) suggests that by setting S=3D0 and placi= ng the GAL above the entropy label, that this makes it "effectively functio= n as an application label". But this is not so. The GAL is an extra label= that would normally sit below the application label. Application labels t= hat are expecting entropy labels are identified in your proposal either exp= licitly in the LFIB or implicitly by the presence of an ELI after the AL. = In either case, it's the label(s) above the GAL that trigger entropy label = handling, not the GAL itself. Then following the procedures in 4.3, the Egress LSR would inspect the S bi= t of the application/ELI label, and according to the text, would then pop t= he next label, assuming it was an entropy label. Unfortunately, you've now= popped the GAL and what's really left is the entropy label. It seems to me that we've gotten here because the GAL and Entropy label bot= h want to be the BOS. You've tried to get around it by relaxing the BOS re= striction on GAL but I think it works much more cleanly if you go the other= way. Instead of saying that Entropy labels always need to be BOS, why not= simply say that they must immediately follow the application/ELI label? T= hat way, the procedures in 4.3 always work trivially. A router that does n= ot understand or expect entropy labels doesn't need to be confused by stran= ge labels following the GAL, and the hardware implementations likely will b= e simpler (and cheaper). It also means I can build hierarchical multipath = LSPs if I really want to... :-) regards, Pablo On Thu, Aug 4, 2011 at 2:36 PM, John E Drake > wrote: Pablo, At least wrt entropy label, the reasons why it needs to be at the bottom of= stack are detailed in the draft in some detail. The GAL is in exactly the= same place in the stack relative to the labels above it whether or not the= entropy label is used. The fact that the bottom of stack bit is not set i= n the GAL tells the egress that an entropy label is present in the stack af= ter it and needs to be discarded.l Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Pablo Frank Sent: Thursday, August 04, 2011 11:24 AM To: curtis@occnc.com Cc: yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitele.com Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft= -nadeau-pwe3-vccv-2-02.txt) Curtis, Why does it matter if the entropy/flow labels are above or below the GAL? = What advantage is gained by putting such labels below the GAL? To me, putting the GAL in-between the PW (or LSP) label and the Flow (or En= tropy) label just feels out of place. I should only really care about a GA= L if I encounter it as a result of disposing of the labels either because t= hey've been popped or because the TTL has expired. When the PW label gets = terminated and all of a sudden, I encounter a GAL, it seems awkward because= in my mind, I have not finished terminating the PW layer. There is still = this flow label that I need to dispose of... so the hardware has to remembe= r that it saw a GAL and continue processing labels. It seems much cleaner = if we finish dealing with the multipath labels before considering whether i= t's carrying normal data or an associated channel. If anything, I see an advantage in having the GAL below the flow label beca= use it allows the option of monitoring individual paths (assuming, of cours= e, that GAL is excluded from the hash). regards, Pablo ----- Original Message ----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Thursday, August 04, 2011 06:38 AM To: Shahram Davari Cc: curtis@occnc.com >; Giles Heron >; Thomas Nadeau >; Yaakov Stein >; pwe3@ietf.o= rg >; Robert Renn= ison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.= broadcom.com> "Shahram Davari" writes: > > Hi Curtis, > > Even if we assume this format (which is not yet incorporated in the > fat-pw draft), then most hardware assume ACH is right after GAL. In > this case how is the HW supposed to examine the ACH channel Type to > decide how to process the packet? (unless you assume there is one > engine that can process all OAM packet types such as BFD, AIS, PSC, > LSP-ping, LDI, LKR, LM, DM, etc) > > Thx > Shahram Shahram, This doesn't need to go in the fat-pw draft. It needs to go into the draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic when some other feature, fat-pw or other, puts a label under the PW label. The GAL goes after the PW and before the other labels. A proper multipath distribution will skip any reserved label and use the rest of the label stack to load balance. This allows spraying across the entropy space or testing a spacific payload label stack that has yielded trouble. Hardware that assumes ACH is right after GAL when the S-bit is not set on the GAL is broken. The payload (ACH) is after the BOS (aka S-bit =3D 1). The IETF has never been sympathetic of broken hardware and should not be since we would halt progress. If the hardware is broken, then the fat-pw label can be omitted but only one path through any multipath would be tested. It would still work for TP, but not work in general. PW does not require TP. The fat-pw work is explicitly done for multipath because multipath is used a lot in deployed networks and isn't going away. Curtis > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com<= mailto:curtis@occnc.com>] > Sent: Wednesday, August 03, 2011 4:53 PM > To: Shahram Davari > Cc: curtis@occnc.com; Giles Heron; Thomas Nadeau= ; Yaakov Stein; pwe3@ietf.org; Robert Rennison > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.a= d.broadcom.com> > "Shahram Davari" writes: > > > > Hi Curtis, > > > > You are absolutely correct if there is no Entropy label. But with > > Entropy label most implementation assume a Entropy label to be BoS and > > below the PW label. > > > > This draft doesn't even talk about whether the GAL should be BoS or > > the Entropy Label? In either case adding GAL would make the packet > > un-parsable by most HW. > > > > Thx > > Shahram > > > That should be covered in this work. At least it was covered in WG > email. PW, then GAL, then fat-pw (aka Flow label, which is different > from Entropy label in MPLS). > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | GAL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... additional labels (ie: fat-pw) may be present | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|Version| Reserved | Associated Channel Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ VCCV Message Body ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The above would be a better choice. The VCCV is always after the > label entry with BOS (S-bit =3D 1). > > The flow label (or entropy label) must not be a reserved label. > Therefore there is no ambiguity. In draft-ietf-pwe3-fat-pw-07 section > 1.2 (page 5) you will find. > > Note that the flow label MUST NOT be an MPLS reserved label (values > in the range 0..15) [RFC3032], but is otherwise unconstrained by the > protocol. > > > The flow label below GAL is needed so that all data paths which the PW > can take are exercised by OAM (ie: LSP Ping used within VCCV). > > Curtis > > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.co= m] > > Sent: Wednesday, August 03, 2011 4:05 PM > > To: Shahram Davari > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt > > > > > > In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp= .ad.broadcom.com> > > "Shahram Davari" writes: > > > > > > Giles, > > > > > > Adding GAL to PW requires HW change, so why not just add CW and use > > > VVCV Type 1? Also what is wrong with TTL approach for non-CW? > > > > > > Thx > > > Shahram > > > > > > Shahram, > > > > Adding GAL to an MPLS label stack requires hardware support. The > > hardware need not know if the label above the GAL is an MPLS label or > > a PW label, just that the next label is GAL and the label over it is > > not a SWAP. Unless we are talking about incredibly inflexible parser > > hardware, like none I've encounted recently, there should be no > > problem noticing a GAL below the POP or PW label and then directing > > the packet to OAM processing. Any remaining labels must be removed > > and hopefully no implementation neglects to look for BOS before > > deciding where the payload is supposed to be. > > > > TTL is best reserved for traceroute only (in the MS-PW case). In this > > case TTL-expire would occur where a label swap was called for and a > > GAL would be below the label containing the expired TTL. Since LDP > > can have transient loops, this avoids having lots of packets sent to > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN. > > > > This yield one way to do OAM with or without CW. A GAL label is below > > the label for which action is taken (POP or PW termination) or below a > > label for which TTL has expired. This method applied to LSP and PW. > > > > I think mandating CW would be just as good a solution, but one that > > was rejected so this is the best we have. > > > > Curtis > > > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > Sent: Wednesday, August 03, 2011 11:10 AM > > > To: Thomas Nadeau; Shahram Davari > > > Cc: pwe3@ietf.org; Yaakov Stein; Robert Renniso= n > > > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-= 02.txt > > > > > > Agreed - some operators won't want to use a CW, and on that basis I s= upport > > > this draft. > > > > > > Sure, it'll take a while to move away from the router alert label and= TTL > > > approaches, but the GAL approach is definitely better than either of > > > those... > > > > > > Giles > > > > > > On 02/08/2011 12:59, "Thomas Nadeau" > wrote: > > > > > > > > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote: > > > > > > > >> Hi, > > > >> > > > >> I also don=B9t support this draft since I don=B9t think to solve t= he problem we > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW. > > > > > > > > While I am with you, that argument went out the window during the d= ebates we > > > > had over the past 3 IETF meetings. Operators > > > > were very clear that they do not want to mandate the use of a CW. = Hence, > > > > Luca and I came up with this solution that narrows the > > > > scope to 2 modes, one that handles the CW case and one that doesn't= while > > > > still both modes providing predictable OAM capabilities > > > > for the PW. > > > > > > > > --Tom > > > > > > > > > > > >> > > > >> Shahram > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:= pwe3-bounces@ietf.org] On Behalf Of > > > >> Robert Rennison > > > >> Sent: Sunday, July 31, 2011 7:40 PM > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew); > > > >> pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >> > > > >> I do Not support the draft, > > > >> > > > >> After hearing the results of the earlier user deployment poll I t= hought, > > > >> =B3 ok the way out of this mess is to migrate towards using the C= W=B2. Then I > > > >> see this proposal and wondered what am I missing. I=B9ve still no= t seen the > > > >> light of why adding a fourth type will simplify matters, hence in = the absence > > > >> of me understanding how this will simplify matter versus complicat= e things, > > > >> I=B9m against it. > > > >> > > > >> Rob > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:= pwe3-bounces@ietf.org] On Behalf Of > > > >> Alexander Vainshtein > > > >> Sent: Sunday, July 31, 2011 12:45 AM > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >> > > > >> Hi all, > > > >> I do NOT support this draft for the same reasons that Yaakov has i= ndicated. > > > >> > > > >> Regards, > > > >> Sasha > > > >> > > > >> From: pwe3-bounces@ietf.org [pwe3-bo= unces@ietf.org] On Behalf Of Yaakov Stein > > > >> [yaakov_s@rad.com] > > > >> Sent: Friday, July 29, 2011 3:58 AM > > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org > > > >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv= -2-02.txt > > > >> > > > >> I do not support ! and I can not understand how anyone can supp= ort it ! > > > >> > > > >> We do NOT need a fourth VCCV type, there are too many already. > > > >> > > > >> I completely agree with the part that says if there is a CW then t= he ACh > > > >> should be marked by it. > > > >> > > > >> I do NOT agree that if the CW is not used then we should use a non= -PW method > > > >> developed for MPLS-TP. > > > >> I do NOT agree that there is any way to deprecate the use of TTL e= xpiry to > > > >> mark the ACh. > > > >> I do NOT agree that we should change mechanisms that have been wid= ely > > > >> deployed for many years now, > > > >> without an extremely pressing reason. > > > >> > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to= have the > > > >> ADDITIONAL option > > > >> for ACh marking, I might be convinced not to object as strongly. > > > >> However, since I don't think that PWs can be limited in this matte= r (the MPLS > > > >> WG adopted the "seamless" draft) > > > >> it would be difficult to convince me that such a limitation is pos= sible. > > > >> > > > >> I would have enthusiastically support this proposal had it been br= ought 8 > > > >> years ago. > > > >> It's too late for this now. > > > >> > > > >> Y(J)S > > > >> > > > >> From: pwe3-bounces@ietf.org [mailto:= pwe3-bounces@ietf.org] On Behalf Of > > > >> Bocci, Matthew (Matthew) > > > >> Sent: Thursday, July 28, 2011 21:02 > > > >> To: pwe3@ietf.org > > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-0= 2.txt > > > >> > > > >> This email begins a two week poll to help assess if there is conse= nsus to > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draf= t. > > > >> > > > >> Please indicate whether or not you support adoption of this draft,= and also > > > >> send any comments to the PWE3 list. > > > >> > > > >> This poll will end on Friday 12th August. > > > >> > > > >> Regards, > > > >> > > > >> Matthew & Andy > > > >> This e-mail message is intended for the recipient only and contain= s > > > >> information which is CONFIDENTIAL and which may be proprietary to = ECI > > > >> Telecom. If you have received this transmission in error, please i= nform 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 contain= s > > > >> information which is CONFIDENTIAL and which may be proprietary to = ECI > > > >> Telecom. If you have received this transmission in error, please i= nform 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 --_000_5E893DB832F57341992548CDBB333163A0AC1DD80DEMBX01HQjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

&nbs= p;

 

=

Sent from my iPhone

 

From: Pablo Frank [mailto:pabloisnot@gmail.com]
Sent:= Friday, August 05, 2011 1:28 PM
To: John E Drake
Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecite= le.com; mpls@ietf.org
Subject: Re: [PWE3] Entropy/Flow and GAL (w= as:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt)

 

Thanks John,

 

Some PF> questions/comments below:<= o:p>

 

On Fri, Aug 5, 2011 at 12:50 PM, John E Drake <jdrake@juniper.net> wrote:=

An appl= ication label is a label in which you expect to see BOS set but which isn&#= 8217;t, followed by an entropy label which is a non-reserved label with BOS= set.  Repeat as necessary.

 

PF>= ; The term "application label" is used repeatedly through the dra= ft but isn't really defined anywhere.  I suggest that you and rest of = the authors add a definition to the text.  The definition that you giv= e above doesn't make a lot of sense to me since I don't know how to interpr= et "expect to see a BOS set but which isn't".  I've interpre= ted application label to refer to the LSP for which the ingress LSR parsed = the payload and generated an entropy label.   I don't think the GAL (o= r any other reserved label) falls into this category.  I think you may= have to update 4.3 to say something about how reserved labels are skipped = until you find the first non-reserved label and pop that as your entropy la= bel.  Ugh.

 =

JD: =A0=A0I am told this = is the way most hardware developed over the past fifteen works – firs= t scan stack for =A0the label with the BOS set and then get to work.=A0 The= original text was written several years ago and the GAL material added abo= ut a year ago, so there is probably some additional text editing required.= =A0 Btw, as RFC5586 indicates, =A0there is no technical reason for the GAL = to be BOS. =A0

As both Curtis and I have said, in order to process the GAL payload= correctly, the stack above the GAL should be the same whether or not an en= tropy label is present.

=

 

P= F> I assume that any multi-path capable router's OAM implementation will= be aware of (and possibly even care about) the entropy labels regardless o= f where they are in the label stack.  Or are you worried about transit= nodes who's OAM implementation may not be entropy-label aware?<= /p>

 

JD:=A0 LSP Traceroute (the control plane) needs to b= e updated because its usage of labels, as opposed to IP addresses, has some= issues.=A0 The data plane, by design, is completely oblivious to entropy l= abels =A0and I am told that most existing hardware does not use reserved la= bels in load balancing.

 =  

Sent from my iPhone

 

From: Pablo Frank [mailto:pabloisnot@gmail.com]
Sent: Friday, A= ugust 05, 2011 9:02 AM
To: John E Drake
Cc: curtis@occnc.com; yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitel= e.com; mpls@ietf.org=
Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG ad= option of draft-nadeau-pwe3-vccv-2-02.txt)

 

So I read the draft but could not = see the justification.  In fact, I believe there's actually a fla= w with what's proposed.  

 <= /o:p>

Section 6 (OAM and Entropy Labels) suggests that by se= tting S=3D0 and placing the GAL above the entropy label, that this makes it= "effectively function as an application label".  But this i= s not so.  The GAL is an extra label that would normally sit below the= application label.  Application labels that are expecting entropy lab= els are identified in your proposal either explicitly in the LFIB or implic= itly by the presence of an ELI after the AL.  In either case, it's the= label(s) above the GAL that trigger entropy label handling, not the GAL it= self.

 

Then= following the procedures in 4.3, the Egress LSR would inspect the S bit of= the application/ELI label, and according to the text, would then pop the n= ext label, assuming it was an entropy label.  Unfortunately, you've no= w popped the GAL and what's really left is the entropy label.

 

It seems to me th= at we've gotten here because the GAL and Entropy label both want to be the = BOS.  You've tried to get around it by relaxing the BOS restriction on= GAL but I think it works much more cleanly if you go the other way.  = Instead of saying that Entropy labels always need to be BOS, why not simply= say that they must immediately follow the application/ELI label?  Tha= t way, the procedures in 4.3 always work trivially.  A router that doe= s not understand or expect entropy labels doesn't need to be confused by st= range labels following the GAL, and the hardware implementations likely wil= l be simpler (and cheaper).  It also means I can build hierarchic= al multipath LSPs if I really want to... :-)

=

 

regards,

=

Pablo

 

On Thu, Aug 4, 2011 at 2:36 PM, John E Drake <jdrake@juniper.net> wrot= e:

Pablo,

 

At least wrt entropy label, the reasons why it needs to= be at the bottom of stack are detailed in the draft in some detail.  = The GAL is in exactly the same place in the stack relative to the labels ab= ove it whether or not the entropy label is used.  The fact that the bo= ttom of stack bit is not set in the GAL tells the egress that an entropy la= bel is present in the stack after it and needs to be discarded.l 

&nb= sp;

Thanks,

 

John

 

Sent from my iPhone

 

From:<= /span> pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Pablo Frank
Sent: Thursday, August 04, 2011 11:= 24 AM
To: c= urtis@occnc.com
Cc: yaakov_s@rad.com; pwe3@ietf.org; Robert.Rennison@ecitele.com
Subject: Re:= [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3= -vccv-2-02.txt)

 

Curtis,

 

=

Why does it matter if the entropy/flow labels are above or below the= GAL?  What advantage is gained by putting such labels below the GAL?<= o:p>

 

To m= e, putting the GAL in-between the PW (or LSP) label and the Flow (or Entrop= y) label just feels out of place.  I should only really care about a G= AL if I encounter it as a result of disposing of the labels either because = they've been popped or because the TTL has expired.  When the PW label= gets terminated and all of a sudden, I encounter a GAL, it seems awkward b= ecause in my mind, I have not finished terminating the PW layer.  Ther= e is still this flow label that I need to dispose of... so the hardware has= to remember that it saw a GAL and continue processing labels.  It see= ms much cleaner if we finish dealing with the multipath labels before consi= dering whether it's carrying normal data or an associated channel.  

 

If an= ything, I see an advantage in having the GAL below the flow label because i= t allows the option of monitoring individual paths (assuming, of course, th= at GAL is excluded from the hash).

 

regards,

P= ablo

 

----- Original Message -----
From: Curtis Villamizar [mailto:curtis@occnc.com]Sent: Thursday, August 04, 2011 06:38 AM
To: Shahram Davari
Cc: curtis@occnc.com <= ;curtis@occnc.com= >; Giles Heron <giles.heron@gmail.com>; Thomas Nadeau <tnadeau@lucidvision.com>; Y= aakov Stein <yaako= v_s@rad.com>; pwe= 3@ietf.org <pwe3@= ietf.org>; Robert Rennison <Robert.Rennison@ecitele.com>
Subject:= Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

=
In message <2C2F1EBA8050E74EA8= 1502D5740B4BD6A93275F12A@SJEXCHCCR02.corp.ad.broadcom.com>
"= Shahram Davari" writes:
>
> Hi Curtis,
>
> Eve= n if we assume this format (which is not yet incorporated in the
> fa= t-pw draft), then most hardware assume ACH is right after GAL. In
> t= his case how is the HW supposed to examine the ACH channel Type to
> = decide how to process the packet? (unless you assume there is one
> e= ngine that can process all OAM packet types such as BFD, AIS, PSC,
> = LSP-ping, LDI, LKR, LM, DM, etc)
>
> Thx
> Shahram

Shahram,

This doesn't need to go in the fat-pw draft.  It = needs to go into the
draft-nadeau-pwe3-vccv-2-02 draft because it only a= ffects OAM traffic
when some other feature, fat-pw or other, puts a labe= l under the PW
label.  The GAL goes after the PW and before the oth= er labels.  A
proper multipath distribution will skip any reserved = label and use the
rest of the label stack to load balance.  This al= lows spraying across
the entropy space or testing a spacific payload lab= el stack that has
yielded trouble.

Hardware that assumes ACH is r= ight after GAL when the S-bit is not set
on the GAL is broken.

Th= e payload (ACH) is after the BOS (aka S-bit =3D 1).

The IETF has nev= er been sympathetic of broken hardware and should not
be since we would = halt progress.

If the hardware is broken, then the fat-pw label can = be omitted but
only one path through any multipath would be tested. &nbs= p;It would still
work for TP, but not work in general.  PW does not= require TP.  The
fat-pw work is explicitly done for multipath beca= use multipath is used
a lot in deployed networks and isn't going away.
Curtis


> -----Original Message-----
> From: curtis@occnc.com [mail= to:curtis@occnc.com]
> Sent: Wednesday, August 03, 2011 4:53 PM
> To: Shahram Da= vari
> Cc: curt= is@occnc.com; Giles Heron; Thomas Nadeau; Yaakov Stein; pwe3@ietf.org; Robert Rennison
&= gt; Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02= .txt
>
>
> In message <2C2F1EBA8050E74EA81502D5740B4BD6A93275F0F9@SJEXCHCCR02.corp.ad.broad= com.com>
> "Shahram Davari" writes:
> >
= > > Hi Curtis,
> >
> > You are absolutely correct i= f there is no Entropy label. But with
> > Entropy label most imple= mentation assume a Entropy label to be BoS and
> > below the PW la= bel.
> >
> > This draft doesn't even talk about whether t= he GAL should be BoS or
> > the Entropy Label? In either case addi= ng GAL would make the packet
> > un-parsable by most HW.
> &= gt;
> > Thx
> > Shahram
>
>
> That shou= ld be covered in this work.  At least it was covered in WG
> ema= il.  PW, then GAL, then fat-pw (aka Flow label, which is different
= > from Entropy label in MPLS).
>
> 0       &n= bsp;           1          = ;         2             &= nbsp;     3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2= 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
> |              = ;              PW Label     &n= bsp;                     = |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> |                   &= nbsp;          GAL         &nb= sp;                    |<= br>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+> |     ... additional labels (ie: fat-pw) may be present &n= bsp;       |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
> |0 0 0 1|Version|   Reserved  =  |  Associated Channel Type      |
> +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  = ;                     &nb= sp;                     &= nbsp;                 |
> ~ &= nbsp;                    =  VCCV Message Body               &= nbsp;      ~
> |           &n= bsp;                     =                      = ;         |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> The above would be a better = choice.  The VCCV is always after the
> label entry with BOS (S-= bit =3D 1).
>
> The flow label (or entropy label) must not be a= reserved label.
> Therefore there is no ambiguity.  In draft-ie= tf-pwe3-fat-pw-07 section
> 1.2 (page 5) you will find.
>
&g= t;    Note that the flow label MUST NOT be an MPLS reserved label= (values
>    in the range 0..15) [RFC3032], but is otherwi= se unconstrained by the
>    protocol.
>
>
&= gt; The flow label below GAL is needed so that all data paths which the PW<= br>> can take are exercised by OAM (ie: LSP Ping used within VCCV).
&= gt;
> Curtis
>
>
> > -----Original Message-----<= br>> > From: cu= rtis@occnc.com [mailto:curtis@occnc.com]
> > Sent: Wednesday, August 03, 2011 4= :05 PM
> > To: Shahram Davari
> > Cc: Giles Heron; Thomas= Nadeau; Yaakov Stein; p= we3@ietf.org; Robert Rennison
> > Subject: Re: [PWE3] Poll for= WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
> >
> >> > In message <2C2F1EBA80= 50E74EA81502D5740B4BD6A93275EF50@SJEXCHCCR02.corp.ad.broadcom.com>> > "Shahram Davari" writes:
> > >
> &g= t; > Giles,
> > >
> > > Adding GAL to PW require= s HW change, so why not just add CW and use
> > > VVCV Type 1? =  Also what is wrong with TTL approach for non-CW?
> > >> > > Thx
> > > Shahram
> >
> >
= > > Shahram,
> >
> > Adding GAL to an MPLS label st= ack requires hardware support.  The
> > hardware need not kno= w if the label above the GAL is an MPLS label or
> > a PW label, j= ust that the next label is GAL and the label over it is
> > not a = SWAP.  Unless we are talking about incredibly inflexible parser
>= ; > hardware, like none I've encounted recently, there should be no
&= gt; > problem noticing a GAL below the POP or PW label and then directin= g
> > the packet to OAM processing.  Any remaining labels mus= t be removed
> > and hopefully no implementation neglects to look = for BOS before
> > deciding where the payload is supposed to be.> >
> > TTL is best reserved for traceroute only (in the M= S-PW case).  In this
> > case TTL-expire would occur where a = label swap was called for and a
> > GAL would be below the label c= ontaining the expired TTL.  Since LDP
> > can have transient = loops, this avoids having lots of packets sent to
> > the OAM engi= ne should such a loop occur in a LDP signaled MPLS PSN.
> >
>= ; > This yield one way to do OAM with or without CW.  A GAL label i= s below
> > the label for which action is taken (POP or PW termina= tion) or below a
> > label for which TTL has expired.  This m= ethod applied to LSP and PW.
> >
> > I think mandating CW= would be just as good a solution, but one that
> > was rejected s= o this is the best we have.
> >
> > Curtis
> >> >
> > > -----Original Message-----
> > > = From: Giles Heron [mailto:giles.heron@gmail.com]
> > > Sent: Wednesday, A= ugust 03, 2011 11:10 AM
> > > To: Thomas Nadeau; Shahram Davari=
> > > Cc: p= we3@ietf.org; Yaakov Stein; Robert Rennison
> > > Subject: = Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
> = > >
> > > Agreed - some operators won't want to use a CW,= and on that basis I support
> > > this draft.
> > >= ;
> > > Sure, it'll take a while to move away from the router a= lert label and TTL
> > > approaches, but the GAL approach is de= finitely better than either of
> > > those...
> > >=
> > > Giles
> > >
> > > On 02/08/2011 = 12:59, "Thomas Nadeau" <tnadeau@lucidvision.com> wrote:
> > = >
> > > >
> > > > On Aug 1, 2011, at 6:28 = PM, Shahram Davari wrote:
> > > >
> > > >>= Hi,
> > > >>
> > > >> I also don=B9t s= upport this draft since I don=B9t think to solve the problem we
> >= ; > >> need yet a 4th type of VCCV. The best solution is to mandat= e CW.
> > > >
> > > > While I am with you, th= at argument went out the window during the debates we
> > > >= ; had over the past 3 IETF meetings. Operators
> > > > were = very clear that they do not want to mandate the use of a CW.   Hence,<= br>> > > > Luca and I came up with this solution that narrows t= he
> > > > scope to 2 modes, one that handles the CW case an= d one that doesn't while
> > > > still both modes providing = predictable OAM capabilities
> > > > for the PW.
> >= ; > >
> > > > --Tom
> > > >
> >= ; > >
> > > >>
> > > >> Shahram> > > >>
> > > >> From: pwe3-bounces@ietf.org [mailt= o:pwe3-bounces@i= etf.org] On Behalf Of
> > > >> Robert Rennison
>= ; > > >> Sent: Sunday, July 31, 2011 7:40 PM
> > > = >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew);<= br>> > > >> pwe3@ietf.org
> > > >> Subject: Re: [PWE3] Poll fo= r WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
> > > >>=
> > > >> I do Not support the draft,
> > > &= gt;>
> > > >> After hearing the results of the earlier= user deployment  poll I thought,
> > > >> =B3 ok &n= bsp;the way out of this mess is to migrate towards using the CW=B2. Then I<= br>> > > >> see this proposal and wondered what am I missing= .  I=B9ve still not seen the
> > > >> light of why a= dding a fourth type will simplify matters, hence in the absence
> >= ; > >> of me understanding how this will simplify matter versus co= mplicate things,
> > > >> I=B9m against it.
> > = > >>
> > > >> Rob
> > > >>
= > > > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
= > > > >> Alexander Vainshtein
> > > >> Sen= t: Sunday, July 31, 2011 12:45 AM
> > > >> To: Yaakov Ste= in; Bocci, Matthew (Matthew); pwe3@ietf.org
> > > >> Subject: Re: [PWE3] Poll= for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
> > > >&= gt;
> > > >> Hi all,
> > > >> I do NOT = support this draft for the same reasons that Yaakov has indicated.
> = > > >>
> > > >> Regards,
> > > &g= t;>      Sasha
> > > >>
> > &g= t; >> From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein
> &= gt; > >> [ya= akov_s@rad.com]
> > > >> Sent: Friday, July 29, 2011 = 3:58 AM
> > > >> To: Bocci, Matthew (Matthew); pwe3@ietf.org
> > >= ; >> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vc= cv-2-02.txt
> > > >>
> > > >> I do not = support !    and I can not understand how anyone can support it !=
> > > >>
> > > >> We do NOT need a fou= rth VCCV type, there are too many already.
> > > >>
&g= t; > > >> I completely agree with the part that says if there i= s a CW then the ACh
> > > >> should be marked by it.
&= gt; > > >>
> > > >> I do NOT agree that if th= e CW is not used then we should use a non-PW method
> > > >&= gt; developed for MPLS-TP.
> > > >> I do NOT agree that t= here is any way to deprecate the use of TTL expiry to
> > > >= ;> mark the ACh.
> > > >> I do NOT agree that we shoul= d change mechanisms that have been widely
> > > >> deploy= ed for many years now,
> > > >> without an extremely pres= sing reason.
> > > >>
> > > >> Were the= proposal to be that for PWs that traverse ONLY MPLS-TP to have the
>= > > >> ADDITIONAL option
> > > >> for ACh ma= rking, I might be convinced not to object as strongly.
> > > &g= t;> However, since I don't think that PWs can be limited in this matter = (the MPLS
> > > >> WG adopted the "seamless" dr= aft)
> > > >> it would be difficult to convince me that s= uch a limitation is possible.
> > > >>
> > > = >> I would have enthusiastically support this proposal had it been br= ought 8
> > > >> years ago.
> > > >> It= 's too late for this now.
> > > >>
> > > >= > Y(J)S
> > > >>
> > > >> From: pwe3-bounces@ietf.or= g [mailto:pw= e3-bounces@ietf.org] On Behalf Of
> > > >> Bocci, Mat= thew (Matthew)
> > > >> Sent: Thursday, July 28, 2011 21:= 02
> > > >> To: pwe3@ietf.org
> > > >> Subject: [PWE3] Po= ll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
> > > >= ;>
> > > >> This email begins a two week poll to help = assess if there is consensus to
> > > >> adopt draft-nade= au-pwe3-vccv-2-02.txt as a PWE3 working group draft.
> > > >= >
> > > >> Please indicate whether or not you support = adoption of this draft, and also
> > > >> send any commen= ts to the PWE3 list.
> > > >>
> > > >> = This poll will end on Friday 12th August.
> > > >>
>= ; > > >> Regards,
> > > >>
> > > = >> Matthew & Andy
> > > >> This e-mail message = is intended for the recipient only and contains
> > > >> = information which is CONFIDENTIAL and which may be proprietary to ECI
&g= t; > > >> Telecom. If you have received this transmission in er= ror, please inform us by
> > > >> e-mail, phone or fax, a= nd then delete the original and all copies thereof.
> > > >&= gt; 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

 

&= nbsp;

=

 

= --_000_5E893DB832F57341992548CDBB333163A0AC1DD80DEMBX01HQjnprn_-- From javi@trajano.us.es Mon Aug 8 11:58: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 B1B4C21F8BC4 for ; Mon, 8 Aug 2011 11:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-CaYaBV3z+p for ; Mon, 8 Aug 2011 11:58:27 -0700 (PDT) Received: from mail.us.es (mail.us.es [193.147.175.20]) by ietfa.amsl.com (Postfix) with ESMTP id B322621F8BBA for ; Mon, 8 Aug 2011 11:58:26 -0700 (PDT) Received: (qmail 26506 invoked from network); 8 Aug 2011 20:58:52 +0200 Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 8 Aug 2011 20:58:52 +0200 Received: (qmail 9109 invoked by uid 507); 8 Aug 2011 18:58:51 -0000 Received: from 127.0.0.1 by antivirus1 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.97.2/13415. Clear:RC:1(127.0.0.1):. Processed in 0.029751 secs); 08 Aug 2011 18:58:51 -0000 Received: from unknown (HELO antivirus1) (127.0.0.1) by us.es with SMTP; 8 Aug 2011 18:58:51 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus1 (F-Secure/fsigk_smtp/406/antivirus1); Mon, 08 Aug 2011 20:58:51 +0200 (CEST) X-Virus-Status: clean(F-Secure/fsigk_smtp/406/antivirus1) Received: (qmail 14038 invoked from network); 8 Aug 2011 20:58:51 +0200 Received: from trajano.us.es (HELO trajano.telematica) (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 8 Aug 2011 20:58:51 +0200 Received: from [192.168.1.50] (39.Red-95-121-83.dynamicIP.rima-tde.net [95.121.83.39]) (authenticated bits=0) by trajano.telematica (8.13.8/8.13.8/Debian-3) with ESMTP id p78IwoVB011441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 8 Aug 2011 20:58:51 +0200 Message-ID: <4E4031EA.9090805@trajano.us.es> Date: Mon, 08 Aug 2011 20:58:50 +0200 From: Javi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PWE3] FRPW: LAPF or Core-LAPF 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, 08 Aug 2011 18:58:27 -0000 Does FRPW[RFC4619] support LAPF frames (with control field)[Q.933] or only Core-LAPF frames (without control field)[Q.933/Annex A]? If FRPW supports LAPF frames, must the ingress PE read the control field or it must be carried transparently to the egress PE? From amalis@gmail.com Wed Aug 10 13:10:36 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 AF12321F8AED for ; Wed, 10 Aug 2011 13:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hmFNfVMrQio for ; Wed, 10 Aug 2011 13:10:36 -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 C344B21F8A66 for ; Wed, 10 Aug 2011 13:10:35 -0700 (PDT) Received: by bkar4 with SMTP id r4so625816bka.31 for ; Wed, 10 Aug 2011 13:11:05 -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; bh=1bfBvtKRljiNBmYnYbKBc177jU+aXjf0hmcfkQXtDzM=; b=LoqKKglbMUNFtn55GYxoqUnwJc+buxUc+/MQIqmpVofuRizdA29v3cXYbqv4/eg1g9 1U/gQyprU2pPfDMi2OYoUyLwKTaZe4v3QjC4bIGmI67x5oc76h/zeggCprl3fHBzZvGr yu4IBbRvaA5bnpwES3fc3dUWVEvnTJNSKd0y0= Received: by 10.204.120.138 with SMTP id d10mr2520043bkr.280.1313007063147; Wed, 10 Aug 2011 13:11:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.41.69 with HTTP; Wed, 10 Aug 2011 13:10:43 -0700 (PDT) In-Reply-To: <4E4031EA.9090805@trajano.us.es> References: <4E4031EA.9090805@trajano.us.es> From: "Andrew G. Malis" Date: Wed, 10 Aug 2011 16:10:43 -0400 Message-ID: To: Javi Content-Type: text/plain; charset=ISO-8859-1 Cc: pwe3@ietf.org Subject: Re: [PWE3] FRPW: LAPF or Core-LAPF 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, 10 Aug 2011 20:10:36 -0000 Javi, RFC 4619 only supports Frame Relay frames as defined by X.36, which replaced Q.933 Annex A in the ITU-T. RFC 4618 defines the encapsulation for general purpose HDLC, including the address and control fields. In RFC 4618, the address and control fields are carried transparently and are not read. Cheers, Andy On Mon, Aug 8, 2011 at 2:58 PM, Javi wrote: > Does FRPW[RFC4619] support LAPF frames (with control field)[Q.933] or only > Core-LAPF frames (without control field)[Q.933/Annex A]? > > If FRPW supports LAPF frames, must the ingress PE read the control field or > it must be carried transparently to the egress PE? > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From satoru.matsushima@gmail.com Thu Aug 11 16:28: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 98EC421F8B2E for ; Thu, 11 Aug 2011 16:28:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYwHCA41CKLG for ; Thu, 11 Aug 2011 16:28:25 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 21C8A21F8B2F for ; Thu, 11 Aug 2011 16:28:25 -0700 (PDT) Received: by iye1 with SMTP id 1so817040iye.27 for ; Thu, 11 Aug 2011 16:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=eEqYVXGRseeW1RMzFMzPNx+yOvh7Nd6jxBgaFMfek4w=; b=O5dUAQmmlO/zLSYTvxYsM7an/2pyYhjgS1CaS+yQ37KZKAWNvfafv1nxVSfoEw3nxg lRIi+eNBSwkaVmqkOFdel/DL4FjrCB1R5lNBp8GDE/5YMcWBuMUAnPsFx2qvWkq+K9Gk waqI6Z1tvJMtCv3/cv/LoWouR1JdYV+sw5xXc= Received: by 10.231.119.161 with SMTP id z33mr496751ibq.91.1313105340421; Thu, 11 Aug 2011 16:29:00 -0700 (PDT) Received: from [126.198.118.215] (pw126198118215.42.tik.panda-world.ne.jp [126.198.118.215]) by mx.google.com with ESMTPS id n18sm1839926ibg.1.2011.08.11.16.28.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Aug 2011 16:28:57 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8K2) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8K2) From: Satoru Matsushima Date: Fri, 12 Aug 2011 08:28:56 +0900 To: "Bocci, Matthew (Matthew)" Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 11 Aug 2011 23:28:25 -0000 hi all, yes, support. --satoru On 2011/07/29, at 3:02, "Bocci, Matthew (Matthew)" wrote: > This email begins a two week poll to help assess if there is consensus to a= dopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. >=20 > Please indicate whether or not you support adoption of this draft, and als= o send any comments to the PWE3 list. >=20 > This poll will end on Friday 12th August. >=20 > Regards, >=20 > Matthew & Andy > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From satoru.matsushima@gmail.com Thu Aug 11 16:51: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 3132F11E80B3 for ; Thu, 11 Aug 2011 16:51:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCetCxCKUYIm for ; Thu, 11 Aug 2011 16:51:19 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id C3AC511E809B for ; Thu, 11 Aug 2011 16:51:19 -0700 (PDT) Received: by pzk33 with SMTP id 33so331804pzk.18 for ; Thu, 11 Aug 2011 16:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=PPt80uY1Az5izqb0X9z1L8dpVBPAWqzDLRxmvkNhFW8=; b=AEz8ljbTNB9Son41AfoivEcaXh8f4hmtRQyd7g913CVl/c7Ze83MTKD67vtS76JRuf G499/IYb/xNj4tkkPHLo1MUeYtBWwRFsCkToGSpyDJvGSzuNRKkn7mFPni9FV6iJjRe0 ZsXPUHKiqPV7syCeGZfIrcgcfAPCxI4pRTKzM= Received: by 10.142.249.4 with SMTP id w4mr121583wfh.81.1313106712933; Thu, 11 Aug 2011 16:51:52 -0700 (PDT) Received: from [126.198.118.215] (pw126198118215.42.tik.panda-world.ne.jp [126.198.118.215]) by mx.google.com with ESMTPS id m3sm2081261pbm.60.2011.08.11.16.51.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Aug 2011 16:51:51 -0700 (PDT) References: <07F7D7DED63154409F13298786A2ADC903E8FD81@EXRAD5.ad.rad.co.il> <786AD2EC3D80A1428B921CDC9BE9EE546BB897A55C@USPITMAIL01.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6A9326CB5B2@SJEXCHCCR02.corp.ad.broadcom.com> <3F8EF87B-0D7B-42CA-B542-9F37A865BA40@lucidvision.com> In-Reply-To: <3F8EF87B-0D7B-42CA-B542-9F37A865BA40@lucidvision.com> Mime-Version: 1.0 (iPad Mail 8K2) Content-Type: text/plain; charset=us-ascii Message-Id: <4FD1A00F-ECF2-46FD-A156-78BE4FAB6970@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8K2) From: Satoru Matsushima Date: Fri, 12 Aug 2011 08:51:45 +0900 To: Thomas Nadeau Cc: Yaakov Stein , "pwe3@ietf.org" , RobertRennison Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.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, 11 Aug 2011 23:51:20 -0000 On 2011/08/02, at 20:59, Thomas Nadeau wrote: >=20 > While I am with you, that argument went out the window during the d= ebates we had over the past 3 IETF meetings. Operators > were very clear that they do not want to mandate the use of a CW. Hence,= Luca and I came up with this solution that narrows the=20 > scope to 2 modes, one that handles the CW case and one that doesn't while s= till both modes providing predictable OAM capabilities > for the PW. >=20 > --Tom +1 Consistent two options sound good. While we work out three plus one option i= n nine years, I feel that the variation to which consider legacy hardware wo= n't advance interoperability. Best regards, --satoru= From iesg-secretary@ietf.org Fri Aug 12 12:23:35 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 A423C21F85C0; Fri, 12 Aug 2011 12:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47yt--wD2IHj; Fri, 12 Aug 2011 12:23:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33ABE21F85A3; Fri, 12 Aug 2011 12:23:33 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110812192333.29056.35305.idtracker@ietfa.amsl.com> Date: Fri, 12 Aug 2011 12:23:33 -0700 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: (Using the Generic Associated Channel Label for Pseudowire in MPLS-TP) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 19:23:35 -0000 The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Using the Generic Associated Channel Label for Pseudowire in MPLS-TP' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the requirements for using the Generic Associated Channel Label (GAL) in Pseudowires (PWs) in MPLS-TP networks, and provides an update to the description of GAL usage in [RFC5586] by removing the restriction that is imposed on using GAL for PWs especially in MPLS-TP environments. . The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-pw/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-pw/ No IPR declarations have been submitted directly on this I-D. From loa@pi.nu Mon Aug 15 12:31: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 2933711E80EB; Mon, 15 Aug 2011 12:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.687 X-Spam-Level: X-Spam-Status: No, score=-102.687 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi-U2rkXJCVG; Mon, 15 Aug 2011 12:31:04 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 762FD11E80D7; Mon, 15 Aug 2011 12:31:04 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 145302A8001; Mon, 15 Aug 2011 21:31:48 +0200 (CEST) Message-ID: <4E497423.8030001@pi.nu> Date: Mon, 15 Aug 2011 21:31:47 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , pwe3@ietf.org, CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PWE3] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.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, 15 Aug 2011 19:31:05 -0000 Working Group, this is to start a working group last call on draft-ietf-mpls-tp-li-lb-03.txt Please send your comments to the mpls working group mailing list. This last call ends on August 26th 2011. Loa for the mpls wg co-charirs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From davari@broadcom.com Mon Aug 15 13: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 2F4CF21F8CC1; Mon, 15 Aug 2011 13:38:56 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvLQu2U1y2Hs; Mon, 15 Aug 2011 13:38:55 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8F97221F8CBC; Mon, 15 Aug 2011 13:38:55 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 15 Aug 2011 13:38:52 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 15 Aug 2011 13:32:58 -0700 From: "Shahram Davari" To: "Loa Andersson" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "MPLS-TP ad hoc team" , "pwe3@ietf.org" , CCAMP Date: Mon, 15 Aug 2011 13:32:57 -0700 Thread-Topic: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt Thread-Index: AcxbggpPrt1irOFMTFqur+1feKkMTQABQBlg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9329A7B9D@SJEXCHCCR02.corp.ad.broadcom.com> References: <4E497423.8030001@pi.nu> In-Reply-To: <4E497423.8030001@pi.nu> 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: 62575C563DK11419773-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [PWE3] [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.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, 15 Aug 2011 20:38:56 -0000 Hi, I have a general clarification question regarding this draft. It seems that= the exact position of the Transmit, Loopback and receive MEP/MIP in the da= ta-plane processing is not well defined, which could lead to unpredictable = results. For example what is the expected behavior for Transmit, Receive an= d Loopback points: - Transmit Before or after Ingress policing? - Transmit and Loopback before or after Queuing/shaping? - Loopback Before or after forwarding (Label Switching)? - Loopback at Ingress Port (Down-MEP) or Egress port (Up-MEP)? - Loopback before TTL decrement or after TTL decrement? - Loopback before or after LSP termination at LSP terminating MEP? - Loopback or not loopback ACH messages at terminating MEP? - loopback or not Loopback VCCV messages at terminating MEP? - loopback or not Loopback LSP OAM messages (such as BFD) with IP address = =3D 127/8 at terminating MEP? - loopback or not Loopback LSP-Ping messages not defined in this draft? And many similar questions. I would appreciate the authors response and cla= rification. Thanks Shahram =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Monday, August 15, 2011 12:32 PM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; pwe3@ie= tf.org; CCAMP Subject: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03= .txt Working Group, this is to start a working group last call on draft-ietf-mpls-tp-li-lb-03.txt Please send your comments to the mpls working group mailing list. This last call ends on August 26th 2011. Loa for the mpls wg co-charirs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Mon Aug 15 14:33: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 03DD321F8C87; Mon, 15 Aug 2011 14:33:13 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cwz4KhnquFxS; Mon, 15 Aug 2011 14:33:11 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5FB21F8C83; Mon, 15 Aug 2011 14:33:11 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 15 Aug 2011 14:36:33 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 15 Aug 2011 14:31:18 -0700 From: "Shahram Davari" To: "Shahram Davari" , "Loa Andersson" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "MPLS-TP ad hoc team" , "pwe3@ietf.org" , CCAMP Date: Mon, 15 Aug 2011 14:31:17 -0700 Thread-Topic: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt Thread-Index: AcxbggpPrt1irOFMTFqur+1feKkMTQABQBlgAAKoL3A= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A9329A7C0A@SJEXCHCCR02.corp.ad.broadcom.com> References: <4E497423.8030001@pi.nu> 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: 62574EEB3KO6181140-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [PWE3] [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.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, 15 Aug 2011 21:33:13 -0000 Hi, A few more comments: - How is a MIP put to Loopback mode?=20 - How does the MIP get out of loopback? - How does the Ingress MEP know that the Egress MEP has accepted its reques= t for Lockout? - How does the Ingress MEP know that the MIP is or is not in loopback mode? previous versions of the draft addressed all these issues, but I am wonderi= ng how are these done without special messages and Acks. Thx Shahram -----Original Message----- From: Shahram Davari=20 Sent: Monday, August 15, 2011 1:33 PM To: 'Loa Andersson'; 'mpls@ietf.org'; 'mpls-chairs@tools.ietf.org'; 'MPLS-T= P ad hoc team'; 'pwe3@ietf.org'; 'CCAMP' Subject: RE: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-l= b-03.txt Hi, I have a general clarification question regarding this draft. It seems that= the exact position of the Transmit, Loopback and receive MEP/MIP in the da= ta-plane processing is not well defined, which could lead to unpredictable = results. For example what is the expected behavior for Transmit, Receive an= d Loopback points: - Transmit Before or after Ingress policing? - Transmit and Loopback before or after Queuing/shaping? - Loopback Before or after forwarding (Label Switching)? - Loopback at Ingress Port (Down-MEP) or Egress port (Up-MEP)? - Loopback before TTL decrement or after TTL decrement? - Loopback before or after LSP termination at LSP terminating MEP? - Loopback or not loopback ACH messages at terminating MEP? - loopback or not Loopback VCCV messages at terminating MEP? - loopback or not Loopback LSP OAM messages (such as BFD) with IP address = =3D 127/8 at terminating MEP? - loopback or not Loopback LSP-Ping messages not defined in this draft? And many similar questions. I would appreciate the authors response and cla= rification. Thanks Shahram =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Monday, August 15, 2011 12:32 PM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; pwe3@ie= tf.org; CCAMP Subject: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03= .txt Working Group, this is to start a working group last call on draft-ietf-mpls-tp-li-lb-03.txt Please send your comments to the mpls working group mailing list. This last call ends on August 26th 2011. Loa for the mpls wg co-charirs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Tue Aug 16 06:25: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 5C19B21F8ABD for ; Tue, 16 Aug 2011 06:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mJNpAA6GgcE for ; Tue, 16 Aug 2011 06:25:34 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9296021F8ADC for ; Tue, 16 Aug 2011 06:25:33 -0700 (PDT) Received: from [85.158.139.83:37724] by server-7.bemta-5.messagelabs.com id 31/3B-21792-5FF6A4E4; Tue, 16 Aug 2011 13:26:13 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1313501173!14692832!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [147.234.242.235] Received: (qmail 1916 invoked from network); 16 Aug 2011 13:26:13 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-12.tower-182.messagelabs.com with SMTP; 16 Aug 2011 13:26:13 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-ad-4e4a692ed2ba Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 5C.7D.16719.E296A4E4; Tue, 16 Aug 2011 15:57:18 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 16 Aug 2011 16:26:12 +0300 From: Alexander Vainshtein To: "ietf@ietf.org" Date: Tue, 16 Aug 2011 16:26:10 +0300 Thread-Topic: IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxcGBA21vETQ27uTwSWVgNiuD48+A== 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_A3C5DF08D38B6049839A6F553B331C760111EFA07C5FILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTu7sxukzkxrWteF39MExU91rTnSq5EYViR2YOKKGycve2O7cxs O2O4SSUhPbSXGIUWPmIrM0OSkkiJkgwyo7IfitUWKmEWUZv2gMpmdtKEaH59c77HPfdyDoGZ 35qsBC8qyCeyHsYUgZf0hwZsc/iV6Qn13bj9zbUK3N514bLRfjx0HV+CpQUC3w0ZYEs+SGZF UVJYBdFOJHMOJsPH72Y5P0PzTgeTyNBeD8shAYmKg2G9XiQ6mZQI+p8vWZXxIo1ETnLyosvB rFi/xma3L0iyJTIp06YkzlscscHNyzSyCSzvoQUky6wL0Wpl+3XMHeofNHqrN+UWPK3C8sHt VYVgHAGp+bD8aAHQ8ST4JFhn0rCZagSwrGFjIYhQ8WkAaw63j9UIE+WA9VdehkUWagq8U9pp 1EQYdQ+DfQWBMIFTU2FL7f2wIUo1DDwM/DEshZ3nBw06jocN1TfwQkAQJLUWdh/O08pAbeJr a21YglExsKu3wqA3R8FA02NMx9Hwbc8vo66Phi8O1QFdL8HCb8HwsSQ1ET4o7cV1fSy8W92J nwSWslGxZaMsZaMsen02rGwMmXQ8C16seocN47Y7PYbR9UowtgbE8h6vkiW4EubapBwlHnG8 gjwonpOEeqDPSd9N8LxtRjOgCMBEkhncinSzkd0t+4VmEEsYmGhyjLQy3TwhS3L63azszvTl eJDcDCCBMRYS7FA50sn69yCfNEylqg9djFnHc5I6kaKSOS8h4f8/TAxZxL1fbaZc6hTuRMiL fMM5cQTBQHKfdvxEH3Kh3B28R/lLG4hxWhuRahuSpiFlLyvIvEvnW8Fkawx5RiMojXDniCNe bUP2Dw0N9YMY9dJRpF9TRar7M+LuV4MNanDXrTQtWN2QEcqaD+xkDfORsBiKv7TkDtI95xad MOdmJ+U3rtv64V5T9omFl26N7+ibfaBDmPsz6ZRl0Lnn7Hxj8sC2a7+KSxyPtmc9tgaXTF+7 MxgbtUxaahf2lUtxqWuWfw5iVTVZV3+0V1ob9r4+X8E9O7h5V14R9fKY8im0LK/1Qt6ru0m7 +OxFRyYxuOxmE2diPpn9DbtAghf8AwAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Andrew Sergeev , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Robert Rennison , Rotem Cohen Subject: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 16 Aug 2011 13:25:34 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EFA07C5FILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-gal= -in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-= of-stack position. As stated in the Introduction, this draft removes the restriction imposed by= RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The cor= responding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It M= UST always be at the bottom of the label stack (i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586= with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST al= ways be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requi= rement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reser= ves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1: This document describes a method of adding an additional label stack entry (= LSE) at the bottom of stack in order to facilitate the load balancing of the= flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseud= owires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any= differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowir= es is the case when an edge-to-edge service emulation crosses multiple IP/MP= LS and MPLS-TP domains. In these scenarios, the flow label of draft-ietf-pwe= 3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) wo= uld potentially compete with GAL (inserted by a T-PE at the edge of an MPLS-= TP domain, e.g., for relying a PW status message that it has received over a= Targeted LDP session from the IP/MPLS domain to a static PW status message= to cross the MPLS-TP domain) for the bottom-of-stack position. The issue I am raising Is not new. It has been actively discussed on the PWE= 3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a WG d= ocument, with arguments for both the flow label and GAL taking the bottom-o= f-the-stack position. But, to the best of my understanding, consensus on thi= s issue has not been reached. Hopefully this comment will be useful. 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_A3C5DF08D38B6049839A6F553B331C760111EFA07C5FILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi all,=

 

I would l= ike to raise the following issue with regard to draft-ie= tf-pwe3-gal-in-pw: controversy vs. draft-ietf-pwe3-fat-pw w= ith regard to bottom-of-stack position.

<= o:p> 

As stated in the Introduction, this= draft removes the restriction imposed by RFC 5586 on usage of Generic Assoc= iated Channel Label (GAL) in PWs. The corresponding text Section 4.2 of RFC= 5586 states:

In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concat= enated Segments of LSPs, and with Sections, and MUST NOT be used with PWs.&n= bsp; It MUST always be at the bottom of the label stack    (i= .e., S bit set to 1).

 <= /o:p>

draft-ietf-pwe3-gal-in-pw proposed to replace= the original text in RFC 5586 with the following

 

In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Con= catenated Segments of LSPs, and with Sections, and MAY be used with PWs. It= MUST always be at the bottom of the label stack (i.e., S bit set to 1).

 <= /p>

I.e.,  while remov= ing this restriction of 5586, it does not modify its requirement for the GAL= being always at the bottom of the label stack.

 

At the same draft-ietf-pwe3-fat-pw (currentl= y also in the IESG review) reserves the bottom of the PW stack for the PW fl= ow labels, e.g., in Section 1.1:

 

This document describes a method of adding an additional l= abel stack entry (LSE) at the bottom of stack in order to facilitate the loa= d balancing of the flows within a PW over the available ECMPs.  =

 =

One could argue= that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and tha= t MPLS-TP does not use ECMP. IMHO and FWIW,

such an argument, were it presented, would= be highly problematic, because:

 

1.       RFC 5960 (which defines the MPLS-TP data plane) did= not define any differences between the PW data plane in IP/MPLS and MPLS-TP= .

2. &n= bsp;     = One of the most popular scenarios for using multi-segment pseudowires is the= case when an edge-to-edge service emulation crosses multiple IP/MPLS and MP= LS-TP domains. In these scenarios, the flow label of draft-ietf-pwe3-fat-pw= (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) would pote= ntially compete with GAL (inserted by a T-PE at the edge of an MPLS-TP domai= n, e.g., for relying a PW status message that it has received over a Targete= d LDP session from the IP/MPLS domain to a static PW status message to cross= the MPLS-TP domain) for the bottom-of-stack position.

 

The issue I am raising Is not new. It= has been actively discussed on the PWE3 mailing list with regard to adoptio= n of draft-nadeau-pwe3-vccv-2 as a WG document, with arguments  for bot= h the flow label and GAL taking the bottom-of-the-stack position. But, to th= e best of my understanding, consensus on this issue has not been reached.

 

Hopefully this comment will be useful.

 

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_A3C5DF08D38B6049839A6F553B331C760111EFA07C5FILPTMAIL02e_-- From Alexander.Vainshtein@ecitele.com Tue Aug 16 10:01: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 5D55321F8B52; Tue, 16 Aug 2011 10:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=1.954, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRcUwzioRWUm; Tue, 16 Aug 2011 10:01:57 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 4F3AB21F8B47; Tue, 16 Aug 2011 10:01:56 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1313514149!40800009!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [147.234.242.235] Received: (qmail 5681 invoked from network); 16 Aug 2011 17:02:29 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-11.tower-21.messagelabs.com with SMTP; 16 Aug 2011 17:02:29 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-8f-4e4a9becf855 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id CB.CF.16719.CEB9A4E4; Tue, 16 Aug 2011 19:33:48 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 16 Aug 2011 20:02:41 +0300 From: Alexander Vainshtein To: "ietf@ietf.org" Date: Tue, 16 Aug 2011 20:02:20 +0300 Thread-Topic: IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxcGBA21vETQ27uTwSWVgNiuD48+AAHMfDU 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD443ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTmzszarDkxu2Vet4hprEBjZbcXG7lhRWRSZlv0IwobZ6+7U7sz 284YWlDaA3tq71IDzSzyEabZgx5U/jCUoCexaAWRRZlEiVH9KLuzUyZE99d3z/ed7xzuPYcm raUjbLQkaygsCwE+JpY60ts/YO+rzMxynO1Jcb1trqJcXWfrTK7S/lYqncyorf1OZIPVRSBN kGVFEzTEeZEquvnssLRJEAt5TvK6eSfPhQKCiIJI1ty8EAoh2cvPjeX+OWlYJskckkXFK8k+ N794xTK7yzVztt3Jz52S5Jw+J3alX1I5ZA8KUoALIlUVfIjDkXWtpL/yeT0R+ril4NX27aYi UObfC8w0ZGfAoztLYgw8Fj582YRxLG1lbwDYcOSJybgcB7DjW19UFcO6YUvDiygewybBO+WR qIhkrxKwpOopqRMUOxneHziHMU2PZufBxvYlhn4+jNR8IQw8DXY/uhX1YdjlsPrlPZOOrRg/ Li6mdGxmPfDH4EBUA3B3Xzsbo7kkmwC7eqoIo2sW1t58QBo4Hr5//dNk6OPh85ImYOgV2HRl 9+9aFthR3kMZ+kR493yEOgjGVgyzrRiWUjEsxYinwsixozEGngrPnf5AGtgOT/5so4bHq8GI epAoBUJabtDnmGZX8rVUJEoaCqBUUQm2AGOA3l0D3feT2wBLAz6OWbw7M8tqEjaphcE2kEgT fDyztRqHRuUq3kK/oPpzwvkBpLYBSJP8GAbkYY7xCoWbUVj5Qy3EH3CItI0UFTyqspYz3eH4 /4VPYPaJfUutrA+P5waEQij8x2c8TfOQaT6NS1jCyIcK8qSA9pcmaLPeRhxu47yuYdSQEFQl n8F3Ajv9obuqHVgpWZGRLYEha7CI1UX+fHnIR1+jbYODg70gAT/AaOaNbhWHl2zIqRcXIXCR rusZehG8RkOUrQj4Lhes96jgouNtR3r1maTGjAWcp8H8+fXKFk/6pwPitVxeWGMp8WizdjRv rFuYfWFinWdAs+3fStSVFrCJez+mH+6NfHqTtSTzxPViR/yllEVXuPa1AJo7V427fSavf5ez ZtypsmdxlgkCnZbDTMzpnHRMfJhcZnFXtu7JffeqladUv+BMIcOq8As0QBzmIQQAAA== Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 16 Aug 2011 17:01:58 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD443ILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi all, After having sent out my comments I've noticed that the specific example to= illustrate the need to combine GAL and "flow label" was inaccurate. A more relevant example would look like following (I do not include a diagra= m, but it can be easily provided if necessary) 1. A MS-PW: * Starts at an S-PE that resides at the edge of an MPLS-TP domain (no= ECMP) * Crosses this domain and enters an IP/MPLS domain with ECMP enabled u= sing a T-PE that resides at the age of these two domains * Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-= PE) * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain 2. The operator intends to improve traffic distribution in the IP/MPLS dom= ain, hence he enables insertion and discard of "flow labels" at the two S-PE= s. Note that: * This does not violate the MPLS-TP restriction on ECMP: ECMP does not= happen in he MPLS-TP domains * T-PEs do not even have to be aware of flow labels 3. The operator also intends to operate some end-to-end OAM for this MS-PW= using "GAL-in-PW". This results in a conflict since both GAL and "flow labe= l" are defined (in the corresponding drafts) as bottom of stack. IMHO this describes a realistic scenario where the two drafts are in controv= ersy. Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Alexander V= ainshtein [Alexander.Vainshtein@ecitele.com] Sent: Tuesday, August 16, 2011 4:26 PM To: ietf@ietf.org Cc: mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren= Gal; John Shirron; Rotem Cohen Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-gal= -in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-= of-stack position. As stated in the Introduction, this draft removes the restriction imposed by= RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The cor= responding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It M= UST always be at the bottom of the label stack (i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586= with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST al= ways be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requi= rement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reser= ves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1: This document describes a method of adding an additional label stack entry (= LSE) at the bottom of stack in order to facilitate the load balancing of the= flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseud= owires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any= differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowir= es is the case when an edge-to-edge service emulation crosses multiple IP/MP= LS and MPLS-TP domains. In these scenarios, the flow label of draft-ietf-pwe= 3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) wo= uld potentially compete with GAL (inserted by a T-PE at the edge of an MPLS-= TP domain, e.g., for relying a PW status message that it has received over a= Targeted LDP session from the IP/MPLS domain to a static PW status message= to cross the MPLS-TP domain) for the bottom-of-stack position. The issue I am raising Is not new. It has been actively discussed on the PWE= 3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a WG d= ocument, with arguments for both the flow label and GAL taking the bottom-o= f-the-stack position. But, to the best of my understanding, consensus on thi= s issue has not been reached. Hopefully this comment will be useful. 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. 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD443ILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Hi all,
After having sent out my comments I've n= oticed that the specific example to illustrate the need to combine GAL and &= quot;flow label" was inaccurate.
 
A more relevant example would look like<= a> following (I do not include a diagram, but it can be easily provided= if necessary)
  1. A MS-PW:
    • Starts at an S-PE that resides at the edg= e of an MPLS-TP domain (no ECMP)
    • Crosses this domain and enters an IP= /MPLS domain with ECMP enabled using a T-PE that resides at the age of these= two domains
    • Leaves this domain and enters a 2nd= MPLS-TP domain (using the 2nd T-PE)
    • Terminates on another S-PE at t= he edge of the 2nd MPLS-TP domain
  2. The operator intends to improve traf= fic distribution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs. Note that:
    • This does not violate the MPLS-TP restric= tion on ECMP: ECMP does not happen in he MPLS-TP domains
    • T-PEs do not even have to be aware o= f flow labels
  3. The operator also intends to operate= some end-to-end OAM for this MS-PW using "GAL-in-PW". This result= s in a conflict since both GAL and "flow label" are defined (in th= e corresponding drafts) as bottom of stack.

 

IMHO this describes a realistic scenario where the two drafts are in contro= versy.
 
Regards,
     Sas= ha
From: mpls-bounces= @ietf.org [mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein [Alexand= er.Vainshtein@ecitele.com]
Sent: Tuesday, August 16, 2011 4:26 PM
To: ietf@ietf.org
Cc: mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe= 3; Oren Gal; John Shirron; Rotem Cohen
Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

Hi all,

 

I would like to raise the following issue with regard= to draft-ietf-pwe3-gal-in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-of-stack position.

 

As stated in the Introduction, this draft removes the= restriction imposed by RFC 5586 on usage of Generic Associated Channel Labe= l (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states:

In MPLS-TP, the GAL= MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs= , and with Sections, and MUST NOT be used with PWs.  It MUST always be at the bottom of the label stack &nb= sp;  (i.e., S bit set to 1).

 

draft-ietf-pwe3-gal-in-pw proposed to replace the ori= ginal text in RFC 5586 with the following

 

In MPLS-TP, the GAL= MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs= , and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit s= et to 1).

 

I.e.,  while remov= ing this restriction of 5586, it does not modify its requirement for the GAL= being always at the bottom of the label stack.

 

At the same draft-ietf-= pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the P= W stack for the PW flow labels, e.g., in Section 1.1:

 

This document descri= bes a method of adding an additional label stack entry (LSE) at the bottom o= f stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs. 

 

One could argue that dr= aft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-T= P does not use ECMP. IMHO and FWIW,

such an argument, were= it presented, would be highly problematic, because:

 

1.   &n= bsp;   RFC 5960 (which defines the MPLS-TP d= ata plane) did not define any differences between the PW data plane in IP/MP= LS and MPLS-TP.

2.   &n= bsp;   One of the most popular scenarios for= using multi-segment pseudowires is the case when an edge-to-edge service em= ulation crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, th= e flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) would pote= ntially compete with GAL (inserted by a T-PE at the edge of an MPLS-TP domai= n, e.g., for relying a PW status message that it has received over a Targete= d LDP session from the IP/MPLS domain to a static PW status message to cross the MPLS-TP domain) for the b= ottom-of-stack position.

 

The issue I am raising= Is not new. It has been actively discussed on the PWE3 mailing list with re= gard to adoption of draft-nadeau-pwe3-vccv-2 as a WG document, with argument= s  for both the flow label and GAL taking the bottom-of-the-stack position. But, to the best of my understandi= ng, consensus on this issue has not been reached.

 

Hopefully this comment will be useful.

 

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.

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_A3C5DF08D38B6049839A6F553B331C760111EF7BD443ILPTMAIL02e_-- From pabloisnot@gmail.com Tue Aug 16 14:16: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 7BACA11E80A1; Tue, 16 Aug 2011 14:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.971, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEtAR9AImzN6; Tue, 16 Aug 2011 14:16:58 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E16E221F8B5A; Tue, 16 Aug 2011 14:16:57 -0700 (PDT) Received: by qwc23 with SMTP id 23so265773qwc.31 for ; Tue, 16 Aug 2011 14:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ITT/6udhCCGAqO5aSgr4ZoRMsNlOdvUOXhtaOVWhGhA=; b=urcvgw4wORqEeb/c7eWNPWHzcNLuQhWQWBroRoGEmsnpShxhq32d/t4+Qs+rk1iawe e9xvZImcIer4sUrhGXiC1liDuYvgwpsX2mXZfRyH9Ls6PL6jDFB2E4YAnK52SIzbR3dt XrpwZBYj7/I8+ASf09EcsphQzY2itNO1DiEgY= MIME-Version: 1.0 Received: by 10.224.202.196 with SMTP id ff4mr208023qab.391.1313529466826; Tue, 16 Aug 2011 14:17:46 -0700 (PDT) Received: by 10.224.45.146 with HTTP; Tue, 16 Aug 2011 14:17:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Aug 2011 17:17:46 -0400 Message-ID: From: Pablo Frank To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=20cf300fb42d45b07d04aaa5e901 Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 16 Aug 2011 21:16:59 -0000 --20cf300fb42d45b07d04aaa5e901 Content-Type: text/plain; charset=ISO-8859-1 I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain in the middle segment, you're no longer in an MPLS-TP environment and so the GAL is not required to be BOS. During that middle segment, the PW flow label would be placed below the GAL and above the GACh. It gets removed when it hits the S-PE that switches you back into the MPLS-TP environment. In other words, whether you're in an MPLS-TP environment is determined segment by segment in a MS-PW. Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Hi all, > After having sent out my comments I've noticed that the specific example to > illustrate the need to combine GAL and "flow label" was inaccurate. > > A more relevant example would look like following (I do not include a > diagram, but it can be easily provided if necessary) > > 1. A MS-PW: > - Starts at an S-PE that resides at the edge of an MPLS-TP domain > (no ECMP) > - Crosses this domain and enters an IP/MPLS domain with ECMP enabled > using a T-PE that resides at the age of these two domains > - Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd > T-PE) > - Terminates on another S-PE at the edge of the 2nd MPLS-TP domain > 2. The operator intends to improve traffic distribution in the IP/MPLS > domain, hence he enables insertion and discard of "flow labels" at the > two S-PEs. Note that: > - This does not violate the MPLS-TP restriction on ECMP: ECMP does > not happen in he MPLS-TP domains > - T-PEs do not even have to be aware of flow labels > 3. The operator also intends to operate some end-to-end OAM for this > MS-PW using "GAL-in-PW". This results in a conflict since both GAL and "flow > label" are defined (in the corresponding drafts) as bottom of stack. > > > IMHO this describes a realistic scenario where the two drafts are in > controversy. > > Regards, > Sasha > ------------------------------ > *From:* mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein [Alexander.Vainshtein@ecitele.com] > *Sent:* Tuesday, August 16, 2011 4:26 PM > *To:* ietf@ietf.org > *Cc:* mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; > Oren Gal; John Shirron; Rotem Cohen > *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > Hi all, > > > > I would like to raise the following issue with regard to > draft-ietf-pwe3-gal-in-pw: > controversy vs. draft-ietf-pwe3-fat-pwwith regard to bottom-of-stack position. > > > > As stated in the Introduction, this draft removes the restriction imposed > by RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The > corresponding text Section 4.2 of RFC 5586 states: > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with > PWs. It MUST always be at the bottom of the label stack (i.e., S bit set > to 1). > > > > draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586 > with the following > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. > It MUST always be at the bottom of the label stack (i.e., S bit set to 1). > > > > I.e., while removing this restriction of 5586, it does not modify its > requirement for the GAL being always at the bottom of the label stack. > > > > At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) > reserves the bottom of the PW stack for the PW flow labels, e.g., in Section > 1.1: > > > > This document describes a method of adding an additional label stack entry > (LSE) at the bottom of stack in order to facilitate the load balancing of > the flows within a PW over the available ECMPs. > > > > One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP > pseudowires, and that MPLS-TP does not use ECMP. IMHO and FWIW, > > such an argument, were it presented, would be highly problematic, because: > > > > 1. RFC 5960 (which defines the MPLS-TP data plane) did not define > any differences between the PW data plane in IP/MPLS and MPLS-TP. > > 2. One of the most popular scenarios for using multi-segment > pseudowires is the case when an edge-to-edge service emulation crosses > multiple IP/MPLS and MPLS-TP domains. In these scenarios, the flow label of > draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an > IP/MPLS domain) would potentially compete with GAL (inserted by a T-PE at > the edge of an MPLS-TP domain, e.g., for relying a PW status message that it > has received over a Targeted LDP session from the IP/MPLS domain to a static > PW status message to cross the MPLS-TP domain) for the bottom-of-stack > position. > > > > The issue I am raising Is not new. It has been actively discussed on the > PWE3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a > WG document, with arguments for both the flow label and GAL taking the > bottom-of-the-stack position. But, to the best of my understanding, > consensus on this issue has not been reached. > > > > Hopefully this comment will be useful. > > > > 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. > > 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 > > --20cf300fb42d45b07d04aaa5e901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS do= main in the middle segment, you're no longer in an MPLS-TP environment = and so the GAL is not required to be BOS. =A0During that middle segment, th= e PW flow label would be placed below the GAL and above the GACh. =A0It get= s removed when it hits the S-PE that switches you back into the MPLS-TP env= ironment. =A0In other words, whether you're in an MPLS-TP environment i= s determined segment by segment in a MS-PW.

Pablo

On Tue, Aug 16, 2011= at 1:02 PM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:
Hi all,
After having sent out my comments I'= ;ve noticed that the specific example to illustrate the need to combine GAL= and "flow label" was inaccurate.
=A0
A more relevant example would look like= following (I do not include a diagram, but it can be easily provide= d if necessary)
  1. A MS-PW:
    • Starts at an S-PE that resides at the ed= ge of an MPLS-TP domain (no ECMP)
    • Crosses this domain and enters an I= P/MPLS domain with ECMP enabled using a T-PE that resides at the age of the= se two domains
    • Leaves this domain and enters a 2nd= MPLS-TP domain (using the 2nd T-PE)
    • Terminates on another S-PE at=A0the= edge of the 2nd MPLS-TP domain
  2. The operator intends to improve tra= ffic distribution in the IP/MPLS domain, hence he enables=A0insertion and discard of "flow labels" at the two S-PEs. Note that:
    • This does not violate the MPLS-TP restri= ction on ECMP: ECMP does not happen in he MPLS-TP domains
    • T-PEs do not even have to be aware = of flow labels
  3. The operator also intends to operat= e some end-to-end OAM for this MS-PW using "GAL-in-PW". This resu= lts in a conflict since both GAL and "flow label" are defined (in= the=A0corresponding drafts) as bottom of stack.

=A0

=A0
Regards,
=A0=A0=A0=A0 Sasha
From: mpls-bounces@ietf.org [= mpls-bounces@iet= f.org] On Behalf Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
Sent: Tuesday, August 16, 2011 4:26 PM
To: ietf@ietf.org=
Cc: mpls@ietf.org= ; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John S= hirron; Rotem Cohen
Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw<= br>

Hi all,

=A0

I would like to raise the following issue with regar= d to draft-ietf-pwe3-gal-in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-of-stack position.

=A0

As stated in the Introduction, this draft removes th= e restriction imposed by RFC 5586 on usage of Generic Associated Channel La= bel (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states:

In MPLS-TP, the = GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of = LSPs, and with Sections, and MUST NOT be used with PWs.=A0 It MUST always be at the bottom of the label stack =A0= =A0=A0(i.e., S bit set to 1).

=A0

draft-ietf-pwe3-gal-in-pw proposed to replace the or= iginal text in RFC 5586 with the following

=A0

In MPLS-TP, the = GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of = LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit = set to 1).

=A0

I.e., =A0while removing= this restriction of 5586, it does not modify its requirement for the GAL b= eing always at the bottom of the label stack.

=A0

At the same draft-ietf-= pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the = PW stack for the PW flow labels, e.g., in Section 1.1:

=A0

This document de= scribes a method of adding an additional label stack entry (LSE) at the bot= tom of stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs.=A0

=A0

One could argue that dr= aft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-= TP does not use ECMP. IMHO and FWIW,

such an argument, were = it presented, would be highly problematic, because:

=A0

1.=A0=A0=A0=A0=A0=A0 RFC 5960 (which defines the MPLS-TP = data plane) did not define any differences between the PW data plane in IP/= MPLS and MPLS-TP.

2.=A0=A0=A0=A0=A0=A0 One of the most popular scenarios fo= r using multi-segment pseudowires is the case when an edge-to-edge service = emulation crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios,= the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) would pot= entially compete with GAL (inserted by a T-PE at the edge of an MPLS-TP dom= ain, e.g., for relying a PW status message that it has received over a Targ= eted LDP session from the IP/MPLS domain to a static PW status message to cross the MPLS-TP domain) for the = bottom-of-stack position.

=A0

The issue I am raising = Is not new. It has been actively discussed on the PWE3 mailing list with re= gard to adoption of draft-nadeau-pwe3-vccv-2 as a WG document, with argumen= ts =A0for both the flow label and GAL taking the bottom-of-the-stack position. But, to the best of my understand= ing, consensus on this issue has not been reached.

=A0

Hopefully this comment will be useful.

=A0

Regards,

=A0=A0=A0=A0 Sasha

=A0

This e-mail message is intended for the recipient only and contains info= rmation 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 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


--20cf300fb42d45b07d04aaa5e901-- From davari@broadcom.com Tue Aug 16 14: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 1805B11E80AB; Tue, 16 Aug 2011 14:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncQkFkN9WeZE; Tue, 16 Aug 2011 14:24:07 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id E56CA11E8085; Tue, 16 Aug 2011 14:24:06 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 16 Aug 2011 14:29:56 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 16 Aug 2011 14:24:41 -0700 From: "Shahram Davari" To: "Pablo Frank" , "Alexander Vainshtein" Date: Tue, 16 Aug 2011 14:24:39 -0700 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxcWgC3iJ/eCK3bTEKpvSbExjfcvQAAKyWQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5@SJEXCHCCR02.corp.ad.broadcom.com> References: 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: 62543EDE3KO6562533-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5SJEXCHCCR02co_ Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 16 Aug 2011 21:24:11 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Pablo, This is not acceptable. Are you suggesting an LSR to pop a label that is no= t to of the stack? I can assure you 99.99% of HW out there can't do this. Thx SD From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Pab= lo Frank Sent: Tuesday, August 16, 2011 2:18 PM To: Alexander Vainshtein Cc: mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael We= xler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in= -pw I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain= in the middle segment, you're no longer in an MPLS-TP environment and so t= he GAL is not required to be BOS. During that middle segment, the PW flow = label would be placed below the GAL and above the GACh. It gets removed wh= en it hits the S-PE that switches you back into the MPLS-TP environment. I= n other words, whether you're in an MPLS-TP environment is determined segme= nt by segment in a MS-PW. Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > wrote: Hi all, After having sent out my comments I've noticed that the specific example to= illustrate the need to combine GAL and "flow label" was inaccurate. A more relevant example would look like following (I do not include a diagr= am, but it can be easily provided if necessary) 1. A MS-PW: * Starts at an S-PE that resides at the edge of an MPLS-TP domain (no= ECMP) * Crosses this domain and enters an IP/MPLS domain with ECMP enabled = using a T-PE that resides at the age of these two domains * Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T= -PE) * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain 1. The operator intends to improve traffic distribution in the IP/MPLS do= main, hence he enables insertion and discard of "flow labels" at the two S-= PEs. Note that: * This does not violate the MPLS-TP restriction on ECMP: ECMP does no= t happen in he MPLS-TP domains * T-PEs do not even have to be aware of flow labels 1. The operator also intends to operate some end-to-end OAM for this MS-P= W using "GAL-in-PW". This results in a conflict since both GAL and "flow la= bel" are defined (in the corresponding drafts) as bottom of stack. IMHO this describes a realistic scenario where the two drafts are in contro= versy. Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@iet= f.org] On Behalf Of Alexander Vainshtein [Ale= xander.Vainshtein@ecitele.com] Sent: Tuesday, August 16, 2011 4:26 PM To: ietf@ietf.org Cc: mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mis= hael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-ga= l-in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bot= tom-of-stack position. As stated in the Introduction, this draft removes the restriction imposed b= y RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The c= orresponding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatena= ted Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It= MUST always be at the bottom of the label stack (i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586= with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatena= ted Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST = always be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requ= irement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) rese= rves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.= 1: This document describes a method of adding an additional label stack entry = (LSE) at the bottom of stack in order to facilitate the load balancing of t= he flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseu= dowires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any= differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowi= res is the case when an edge-to-edge service emulation crosses multiple IP/= MPLS and MPLS-TP domains. In these scenarios, the flow label of draft-ietf-= pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain= ) would potentially compete with GAL (inserted by a T-PE at the edge of an = MPLS-TP domain, e.g., for relying a PW status message that it has received = over a Targeted LDP session from the IP/MPLS domain to a static PW status m= essage to cross the MPLS-TP domain) for the bottom-of-stack position. The issue I am raising Is not new. It has been actively discussed on the PW= E3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a WG= document, with arguments for both the flow label and GAL taking the botto= m-of-the-stack position. But, to the best of my understanding, consensus on= this issue has not been reached. Hopefully this comment will be useful. Regards, 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. 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 --_000_2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Pablo,

 

=

This is not acceptable. Are you suggesting an L= SR to pop a label that is not to of the stack? I can assure you 99.99% of H= W out there can’t do this.

=  

Thx

SD

 

Fr= om: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of= Pablo Frank
Sent: Tuesday, August 16, 2011 2:18 PM
To:= Alexander Vainshtein
Cc: mpls@ietf.org; ietf@ietf.org; Vladi= mir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rot= em Cohen
Subject: Re: [mpls] [PWE3] IETF Last Call comment on dra= ft-ietf-pwe3-gal-in-pw

 

I think it's okay because as the PW c= rosses the ECMP-enabled IP/MPLS domain in the middle segment, you're no lon= ger in an MPLS-TP environment and so the GAL is not required to be BOS. &nb= sp;During that middle segment, the PW flow label would be placed below the = GAL and above the GACh.  It gets removed when it hits the S-PE that sw= itches you back into the MPLS-TP environment.  In other words, whether= you're in an MPLS-TP environment is determined segment by segment in a MS-= PW.

 

Pablo

On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshte= in <Alexander.Vainsh= tein@ecitele.com> wrote:

Hi all,

=

After having sent out my c= omments I've noticed that the specific example to illustrate the need to co= mbine GAL and "flow label" was inaccurate.

<= /div>

 

A m= ore relevant example would look like following (I do not include a diagram,= but it can be easily provided if necessary)

  • A MS-PW:
      • Starts at an S-PE that resides at the edge of = an MPLS-TP domain (no ECMP)
      • Crosses this domain and enters an IP/MPLS domain with ECMP ena= bled using a T-PE that resides at the age of these two domains <= /li>
      • Leaves this domain and ente= rs a 2nd MPLS-TP domain (using the 2nd T-PE)
      • Terminates on another S-PE at the edge o= f the 2nd MPLS-TP domain
      The operator intends to improve t= raffic distribution in the IP/MPLS domain, hence he enables insertion = and discard of "flow labels" at the two S-PEs. Note that:
      • This does not violate the MPLS-TP restriction on EC= MP: ECMP does not happen in he MPLS-TP domains
      • T-PEs do not even have to be aware of flow = labels
    1. The operator also intends to operate some end-to-en= d OAM for this MS-PW using "GAL-in-PW". This results in a conflic= t since both GAL and "flow label" are defined (in the corres= ponding drafts) as bottom of stack.

     

    IMHO this describes a realistic scenario where the two d= rafts are in controversy.

     

    Regards,

    =

      &nb= sp;  Sasha

    From: mpls-bounces@ietf.org [mpls-bounces@ietf.org]= On Behalf Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
    = Sent: Tuesday, August 16, 2011 4:26 PM
    To: ietf@ietf.org
    Cc: mpls@ietf.org; Vladimir Kleine= r; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem CohenSubject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-p= w

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>Hi all,

     

    I would like to raise the following issue with regard to draft-ietf-pwe3-gal-in-pw: controversy = vs. draft-ietf-pwe3-fat-pw with regard to b= ottom-of-stack position.

     

    As sta= ted in the Introduction, this draft removes the restriction imposed by RFC = 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The corresp= onding text Section 4.2 of RFC 5586 states:

    In MPLS-TP, the GAL MUST be used with packet= s on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and= MUST NOT be used with PWs.  It MUST always be at the bottom of the la= bel stack    (i.e., S bit set to 1).

     <= o:p>

    draft-ietf-pwe3-gal= -in-pw proposed to replace the original text in RFC 5586 with the following=

     <= /span>

    In MPLS-TP, the GAL MUST b= e used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and = with Sections, and MAY be used with PWs. It MUST always be at the bottom of= the label stack (i.e., S bit set to 1).=

     

    I.e.,  while removing this restriction of 5586, it does not mo= dify its requirement for the GAL being always at the bottom of the label st= ack.

     

    At the same draft-ietf-pwe3-fat-pw (currently also in the IESG= review) reserves the bottom of the PW stack for the PW flow labels, e.g., = in Section 1.1:

     

    This document describes a method of adding an additional label sta= ck entry (LSE) at the bottom of stack in order to facilitate the load balan= cing of the flows within a PW over the available ECMPs. 

     

    One could argue that draft-ietf-pwe3-gal-in-p= w only applies to MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. = IMHO and FWIW,

    such an argument, were it presented, would be highly probl= ematic, because:

     

    1.       RFC 5960 (which defines the MPLS-TP data plane) did not define any dif= ferences between the PW data plane in IP/MPLS and MPLS-TP.

    2.=      &= nbsp; One of the most popular scenarios = for using multi-segment pseudowires is the case when an edge-to-edge servic= e emulation crosses multiple IP/MPLS and MPLS-TP domains. In these scenario= s, the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE = at the edge of an IP/MPLS domain) would potentially compete with GAL (inser= ted by a T-PE at the edge of an MPLS-TP domain, e.g., for relying a PW stat= us message that it has received over a Targeted LDP session from the IP/MPL= S domain to a static PW status message to cross the MPLS-TP domain) for the= bottom-of-stack position.

    =  

    The issue I am raising Is not new. It ha= s been actively discussed on the PWE3 mailing list with regard to adoption = of draft-nadeau-pwe3-vccv-2 as a WG document, with arguments  for both= the flow label and GAL taking the bottom-of-the-stack position. But, to th= e best of my understanding, consensus on this issue has not been reached.

    &= nbsp;

    Hopefully thi= s comment will be useful.

     

    Reg= ards,

      &= nbsp;  Sasha

    &= nbsp;

    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 re= ceived 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 infor= m us by e-mail, phone or fax, and then delete the original and all copies t= hereof.


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

     

    = --_000_2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5SJEXCHCCR02co_-- From pabloisnot@gmail.com Tue Aug 16 15:20: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 E55CE21F8AF7; Tue, 16 Aug 2011 15:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQytu4G42jX5; Tue, 16 Aug 2011 15:19:59 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6A721F8AF3; Tue, 16 Aug 2011 15:19:59 -0700 (PDT) Received: by qyk35 with SMTP id 35so289966qyk.10 for ; Tue, 16 Aug 2011 15:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GG1lOBxwpsd7UFLZSspPo1lXsfxrI/lHsHEH1A7ID0U=; b=SNlKeYhCerYsH14CVDZZoG+RAKtIkihV3vXj90shhKUWSZ3frc5d/wdpqogYs8O5Da D5I7deS1kHxfFx6tPt881OmXxyxD5QvyX6pxGj1SRVHjmBkBlifQaab5D90/uE7938aV 8gnILAjAzNWshqjGR94n92zdDjamCNJNf6s+s= MIME-Version: 1.0 Received: by 10.224.200.202 with SMTP id ex10mr279993qab.241.1313533248220; Tue, 16 Aug 2011 15:20:48 -0700 (PDT) Received: by 10.224.45.146 with HTTP; Tue, 16 Aug 2011 15:20:48 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6A932A5AFE5@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 16 Aug 2011 18:20:48 -0400 Message-ID: From: Pablo Frank To: Shahram Davari Content-Type: multipart/alternative; boundary=20cf300faf91a92e0904aaa6ca8c Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 16 Aug 2011 22:20:01 -0000 --20cf300faf91a92e0904aaa6ca8c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My mistake. Flow-labels are used end-to-end in a multi-segment pseudowire. I suppose the flow label can easily be ignored when it crosses the MPLS-TP segments but that does create the conflict that Sasha is pointing out. Pablo On Tue, Aug 16, 2011 at 5:24 PM, Shahram Davari wrote= : > Pablo,**** > > ** ** > > This is not acceptable. Are you suggesting an LSR to pop a label that is > not to of the stack? I can assure you 99.99% of HW out there can=92t do t= his. > **** > > ** ** > > Thx**** > > SD**** > > ** ** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf O= f > *Pablo Frank > *Sent:* Tuesday, August 16, 2011 2:18 PM > *To:* Alexander Vainshtein > *Cc:* mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishae= l > Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > *Subject:* Re: [mpls] [PWE3] IETF Last Call comment on > draft-ietf-pwe3-gal-in-pw**** > > ** ** > > I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS doma= in > in the middle segment, you're no longer in an MPLS-TP environment and so = the > GAL is not required to be BOS. During that middle segment, the PW flow > label would be placed below the GAL and above the GACh. It gets removed > when it hits the S-PE that switches you back into the MPLS-TP environment= . > In other words, whether you're in an MPLS-TP environment is determined > segment by segment in a MS-PW.**** > > ** ** > > Pablo**** > > On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein < > Alexander.Vainshtein@ecitele.com> wrote:**** > > Hi all,**** > > After having sent out my comments I've noticed that the specific example = to > illustrate the need to combine GAL and "flow label" was inaccurate.**** > > **** > > A more relevant example would look like following (I do not include a > diagram, but it can be easily provided if necessary)**** > > 1. A MS-PW: **** > > > - Starts at an S-PE that resides at the edge of an MPLS-TP domain (no > ECMP) **** > - Crosses this domain and enters an IP/MPLS domain with ECMP enable= d > using a T-PE that resides at the age of these two domains **** > - Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd > T-PE) **** > - Terminates on another S-PE at the edge of the 2nd MPLS-TP domain*= * > ** > > > 1. The operator intends to improve traffic distribution in the IP/MPLS > domain, hence he enables insertion and discard of "flow labels" at the= two > S-PEs. Note that: **** > > > - This does not violate the MPLS-TP restriction on ECMP: ECMP does not > happen in he MPLS-TP domains **** > - T-PEs do not even have to be aware of flow labels**** > > > 1. The operator also intends to operate some end-to-end OAM for this > MS-PW using "GAL-in-PW". This results in a conflict since both GAL and= "flow > label" are defined (in the corresponding drafts) as bottom of stack.**= * > * > > **** > > IMHO this describes a realistic scenario where the two drafts are in > controversy.**** > > **** > > Regards,**** > > Sasha**** > ------------------------------ > > *From:* mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein [Alexander.Vainshtein@ecitele.com] > *Sent:* Tuesday, August 16, 2011 4:26 PM > *To:* ietf@ietf.org > *Cc:* mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; > Oren Gal; John Shirron; Rotem Cohen > *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw**** > > Hi all,**** > > **** > > I would like to raise the following issue with regard to > draft-ietf-pwe3-gal-in-pw: > controversy vs. draft-ietf-pwe3-fat-pwwith regard to bottom-of-stack posit= ion. > **** > > **** > > As stated in the Introduction, this draft removes the restriction imposed > by RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. Th= e > corresponding text Section 4.2 of RFC 5586 states:**** > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MUST NOT be used wi= th > PWs. It MUST always be at the bottom of the label stack (i.e., S bit = set > to 1).**** > > **** > > draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 55= 86 > with the following**** > > **** > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MAY be used with PW= s. > It MUST always be at the bottom of the label stack (i.e., S bit set to 1)= . > **** > > **** > > I.e., while removing this restriction of 5586, it does not modify its > requirement for the GAL being always at the bottom of the label stack. **= * > * > > **** > > At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) > reserves the bottom of the PW stack for the PW flow labels, e.g., in Sect= ion > 1.1:**** > > **** > > This document describes a method of adding an additional label stack entr= y > (LSE) at the bottom of stack in order to facilitate the load balancing of > the flows within a PW over the available ECMPs. **** > > **** > > One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP > pseudowires, and that MPLS-TP does not use ECMP. IMHO and FWIW, **** > > such an argument, were it presented, would be highly problematic, because= : > **** > > **** > > 1. RFC 5960 (which defines the MPLS-TP data plane) did not define > any differences between the PW data plane in IP/MPLS and MPLS-TP. **** > > 2. One of the most popular scenarios for using multi-segment > pseudowires is the case when an edge-to-edge service emulation crosses > multiple IP/MPLS and MPLS-TP domains. In these scenarios, the flow label = of > draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an > IP/MPLS domain) would potentially compete with GAL (inserted by a T-PE at > the edge of an MPLS-TP domain, e.g., for relying a PW status message that= it > has received over a Targeted LDP session from the IP/MPLS domain to a sta= tic > PW status message to cross the MPLS-TP domain) for the bottom-of-stack > position. **** > > **** > > The issue I am raising Is not new. It has been actively discussed on the > PWE3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as = a > WG document, with arguments for both the flow label and GAL taking the > bottom-of-the-stack position. But, to the best of my understanding, > consensus on this issue has not been reached.**** > > **** > > Hopefully this comment will be useful.**** > > **** > > 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 u= s > 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 u= s > 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**** > > ** ** > --20cf300faf91a92e0904aaa6ca8c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    My mistake. =A0Flow-labels are used end-to-end in a multi-segment pseu= dowire. =A0I suppose the flow label can easily be ignored when it crosses t= he MPLS-TP segments but that does create the conflict that Sasha is pointin= g out.

    Pablo
     --20cf300faf91a92e0904aaa6ca8c-- From lizhong.jin@zte.com.cn Tue Aug 16 20:45: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 594E811E808B; Tue, 16 Aug 2011 20:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.692 X-Spam-Level: X-Spam-Status: No, score=-101.692 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hd5hxQW5Dh2; Tue, 16 Aug 2011 20:45:52 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B6D8E11E8083; Tue, 16 Aug 2011 20:45:51 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131322203882679; Wed, 17 Aug 2011 11:34:31 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 94545.6445880624; Wed, 17 Aug 2011 11:46:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p7H3kT8A029775; Wed, 17 Aug 2011 11:46:29 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Alexander.Vainshtein@ecitele.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: Wed, 17 Aug 2011 11:46:09 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-17 11:46:21, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-17 11:46:21, Serialize complete at 2011-08-17 11:46:21, S/MIME Sign failed at 2011-08-17 11:46:21: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-17 11:46:30, Serialize complete at 2011-08-17 11:46:30 Content-Type: multipart/alternative; boundary="=_alternative 0014B925482578EF_=" X-MAIL: mse01.zte.com.cn p7H3kT8A029775 Cc: mpls@ietf.org, Vladimir.Kleiner@ecitele.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, pwe3@ietf.org, Oren.Gal@ecitele.com, John.Shirron@ecitele.com, Rotem.Cohen@ecitele.com Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 17 Aug 2011 03:45:53 -0000 This is a multipart message in MIME format. --=_alternative 0014B925482578EF_= Content-Type: text/plain; charset="US-ASCII" Hi Sasha, Do you mean different PW segments of one MS-PW could support different flow label capability? If in that case, flow LSE is not transparent to the label swap operation on S-PE, Flow Label Sub-TLV signalling is also not transitive, which is conflict with section 6 of draft-ietf-pwe3-fat-pw. If we want to do this, we have to change the draft-fat-pw. Regards Lizhong > ------------------------------ > > Message: 5 > Date: Tue, 16 Aug 2011 20:02:20 +0300 > From: Alexander Vainshtein > To: "ietf@ietf.org" > Cc: "mpls@ietf.org" , Vladimir Kleiner > , Idan Kaspit , > Mishael Wexler , pwe3 , > Oren Gal , John Shirron > , Rotem Cohen > Subject: Re: [PWE3] IETF Last Call comment on > draft-ietf-pwe3-gal-in-pw > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, > After having sent out my comments I've noticed that the specific > example to illustrate the need to combine GAL and "flow label" was inaccurate. > > A more relevant example would look like following (I do not include > a diagram, but it can be easily provided if necessary) > > 1. A MS-PW: > * Starts at an S-PE that resides at the edge of an MPLS-TP > domain (no ECMP) > * Crosses this domain and enters an IP/MPLS domain with ECMP > enabled using a T-PE that resides at the age of these two domains > * Leaves this domain and enters a 2nd MPLS-TP domain (using > the 2nd T-PE) > * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain > 2. The operator intends to improve traffic distribution in the > IP/MPLS domain, hence he enables insertion and discard of "flow > labels" at the two S-PEs. Note that: > * This does not violate the MPLS-TP restriction on ECMP: ECMP > does not happen in he MPLS-TP domains > * T-PEs do not even have to be aware of flow labels > 3. The operator also intends to operate some end-to-end OAM for > this MS-PW using "GAL-in-PW". This results in a conflict since both > GAL and "flow label" are defined (in the corresponding drafts) as > bottom of stack. > > > > IMHO this describes a realistic scenario where the two drafts are in > controversy. > > Regards, > Sasha > _____________________________ -------------------------------------------------------- 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 0014B925482578EF_= Content-Type: text/html; charset="US-ASCII"
    Hi Sasha,
    Do you mean different PW segments of one MS-PW could support different flow label capability? If in that case, flow LSE is not transparent to the label swap operation on S-PE, Flow Label Sub-TLV signalling is also not transitive, which is conflict with section 6 of draft-ietf-pwe3-fat-pw. If we want to do this, we have to change the draft-fat-pw.

    Regards
    Lizhong


    > ------------------------------
    >
    > Message: 5
    > Date: Tue, 16 Aug 2011 20:02:20 +0300
    > From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
    > To: "ietf@ietf.org" <ietf@ietf.org>
    > Cc: "mpls@ietf.org" <mpls@ietf.org>,   Vladimir Kleiner
    >    <Vladimir.Kleiner@ecitele.com>,   Idan Kaspit <Idan.Kaspit@ecitele.com>,
    >    Mishael Wexler <Mishael.Wexler@ecitele.com>,   pwe3 <pwe3@ietf.org>,
    >    Oren Gal <Oren.Gal@ecitele.com>,   John Shirron
    >    <John.Shirron@ecitele.com>,   Rotem Cohen <Rotem.Cohen@ecitele.com>
    > Subject: Re: [PWE3] IETF Last Call comment on
    >    draft-ietf-pwe3-gal-in-pw
    > Message-ID:
    >    <A3C5DF08D38B6049839A6F553B331C760111EF7BD443@ILPTMAIL02.ecitele.com>
    > Content-Type: text/plain; charset="iso-8859-1"
    >
    > Hi all,
    > After having sent out my comments I've noticed that the specific
    > example to illustrate the need to combine GAL and "flow label" was inaccurate.
    >
    > A more relevant example would look like following (I do not include
    > a diagram, but it can be easily provided if necessary)
    >
    >  1.  A MS-PW:
    >     *   Starts at an S-PE that resides at the edge of an MPLS-TP
    > domain (no ECMP)
    >     *   Crosses this domain and enters an IP/MPLS domain with ECMP
    > enabled using a T-PE that resides at the age of these two domains
    >     *   Leaves this domain and enters a 2nd MPLS-TP domain (using
    > the 2nd T-PE)
    >     *   Terminates on another S-PE at the edge of the 2nd MPLS-TP domain
    >  2.  The operator intends to improve traffic distribution in the
    > IP/MPLS domain, hence he enables insertion and discard of "flow
    > labels" at the two S-PEs. Note that:
    >     *   This does not violate the MPLS-TP restriction on ECMP: ECMP
    > does not happen in he MPLS-TP domains
    >     *   T-PEs do not even have to be aware of flow labels
    >  3.  The operator also intends to operate some end-to-end OAM for
    > this MS-PW using "GAL-in-PW". This results in a conflict since both
    > GAL and "flow label" are defined (in the corresponding drafts) as
    > bottom of stack.
    >
    >
    >
    > IMHO this describes a realistic scenario where the two drafts are in
    > controversy.
    >
    > Regards,
    >      Sasha
    > _____________________________
    --------------------------------------------------------
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 0014B925482578EF_=-- From Alexander.Vainshtein@ecitele.com Tue Aug 16 20:48: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 E54C711E80BF; Tue, 16 Aug 2011 20:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=1.523, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KY8gU7eWTAM; Tue, 16 Aug 2011 20:48:39 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 66E2411E8083; Tue, 16 Aug 2011 20:48:38 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1313552966!21858990!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [147.234.242.235] Received: (qmail 20992 invoked from network); 17 Aug 2011 03:49:26 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-15.tower-174.messagelabs.com with SMTP; 17 Aug 2011 03:49:26 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-d7-4e4b337fde9f Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id FB.61.16719.F733B4E4; Wed, 17 Aug 2011 06:20:31 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 17 Aug 2011 06:49:25 +0300 From: Alexander Vainshtein To: Pablo Frank Date: Wed, 17 Aug 2011 06:46:37 +0300 Thread-Topic: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxcWehnDCf52OvWSKeoT404R1SjwAANmj+G 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD445ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTWUwTURT1daZliowZi5UHUVPHKEEti0BSozUkihQXxPVDTXRsn+1IO1M7 A6F+SGNcMVEQBKnGiqIRNVANJrIYlbgEJIEvQxD8kbiUGiNRCNFQZxgFEuP7Ou+ec++5ubmX wHSXohIIlhORh2OctCYarwgNfzf60jfmpXZW4KYP9wO4qe9mvdpUPfRKYzo33IRn4ZZm/0CU pa5uTJWv2u0DqxmO40VGRAYbEqxmOt/DFjFWL21gbWY6jTa4nYwVuRAnmmnG7UacjV4Tbfjn rZZkLGdAnJW3sZzdTOdu32I0mTJXGtPoNUsWpaWvit7hYAUDMroY1mlwIUFg7MggRfY3YY6b T46r3Q1VoNj3sB73gV9HS4GWgFQGrC5/qVHwXNjzrlHC0YSOagWw8nVQrXyqAAz/aJtQaSgz fHB3YALPoZbAhvIaIIswqlcFg7XXgUzg1GI40Pp9QhRL5cDzt24DJcECa250RJUCQsIr4GDY LYdJaissv3Lmj9k7AK92tGEyoZWIkcffJnKB1N5o5z2VjDEqDvYNBlRK2xSsa+vGFKyHn9+P qxW9HvafagSyF0bx8H6tVvGaDTtqBnFFHg+f3e7Fy8Bc/7Sq/qkM/7QMRZIMey9WahS8DN6q HcIUbISXxtvx6fFrIOoOiGedbvGAy566wsgXisnIyorIiZKtvOsBUFbp0yPwtiupHVAEoGPI 3NMb8nRqpkjwutpBPKGi9WTzyo15ulkHeJvXwQiOfZ5CJxLaASQweg65DkgcaWO8R5CH/0tl S/MvxxJmWnlpaTlxX3pq6v8/dBx51hrerKPs0noWIORGnr915hEEDcntsv1sD7Kj4oOsU5yi VYRWbiNGaqNE1pCCm3EJrF3hO4GRGHobeAl0OMdzKCGO7JFFlCxyFHKTdeSDKolEIiEQJw0g lmyRVTHSuU1WCkkmKsmkr8Uim0hnNEkl+ID+U3BBc0n2DUvB86fHHPWWlPM7lx462pg/utZW sDDY3d+VGRu6t2n8RPAw982/PpQ4o64v6/q2yxG6KfvN11yRtGt/pvQHln/c+2KhmPjwcm5G UbfrZPhJ8Muu/OSk9MBIMbdnbeFI1cCY9nNxlr7rTWS4J+V0mTc4lBSfc+Xr/As0LjiYtKWY R2B+AyEke08rBAAA Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 17 Aug 2011 03:48:41 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD445ILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Pablo, Sorry, but I think you're wrong. Only T-PE can insert the flow label (becaus= e only T=3DPE can be "flow-aware"). S-PE simply performs swap on PW label. Regards, Sasha ________________________________ From: Pablo Frank [pabloisnot@gmail.com] Sent: Wednesday, August 17, 2011 12:17 AM To: Alexander Vainshtein Cc: ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wex= ler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain= in the middle segment, you're no longer in an MPLS-TP environment and so th= e GAL is not required to be BOS. During that middle segment, the PW flow la= bel would be placed below the GAL and above the GACh. It gets removed when= it hits the S-PE that switches you back into the MPLS-TP environment. In o= ther words, whether you're in an MPLS-TP environment is determined segment b= y segment in a MS-PW. Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > wrote: Hi all, After having sent out my comments I've noticed that the specific example to= illustrate the need to combine GAL and "flow label" was inaccurate. A more relevant example would look like following (I do not include a diagra= m, but it can be easily provided if necessary) 1. A MS-PW: * Starts at an S-PE that resides at the edge of an MPLS-TP domain (no= ECMP) * Crosses this domain and enters an IP/MPLS domain with ECMP enabled u= sing a T-PE that resides at the age of these two domains * Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-= PE) * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain 2. The operator intends to improve traffic distribution in the IP/MPLS dom= ain, hence he enables insertion and discard of "flow labels" at the two S-PE= s. Note that: * This does not violate the MPLS-TP restriction on ECMP: ECMP does not= happen in he MPLS-TP domains * T-PEs do not even have to be aware of flow labels 3. The operator also intends to operate some end-to-end OAM for this MS-PW= using "GAL-in-PW". This results in a conflict since both GAL and "flow labe= l" are defined (in the corresponding drafts) as bottom of stack. IMHO this describes a realistic scenario where the two drafts are in controv= ersy. Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf= .org] On Behalf Of Alexander Vainshtein [Alexa= nder.Vainshtein@ecitele.com] Sent: Tuesday, August 16, 2011 4:26 PM To: ietf@ietf.org Cc: mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mish= ael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi all, I would like to raise the following issue with regard to draft-ietf-pwe3-gal= -in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-= of-stack position. As stated in the Introduction, this draft removes the restriction imposed by= RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The cor= responding text Section 4.2 of RFC 5586 states: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It M= UST always be at the bottom of the label stack (i.e., S bit set to 1). draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586= with the following In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenat= ed Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST al= ways be at the bottom of the label stack (i.e., S bit set to 1). I.e., while removing this restriction of 5586, it does not modify its requi= rement for the GAL being always at the bottom of the label stack. At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reser= ves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1: This document describes a method of adding an additional label stack entry (= LSE) at the bottom of stack in order to facilitate the load balancing of the= flows within a PW over the available ECMPs. One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseud= owires, and that MPLS-TP does not use ECMP. IMHO and FWIW, such an argument, were it presented, would be highly problematic, because: 1. RFC 5960 (which defines the MPLS-TP data plane) did not define any= differences between the PW data plane in IP/MPLS and MPLS-TP. 2. One of the most popular scenarios for using multi-segment pseudowir= es is the case when an edge-to-edge service emulation crosses multiple IP/MP= LS and MPLS-TP domains. In these scenarios, the flow label of draft-ietf-pwe= 3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) wo= uld potentially compete with GAL (inserted by a T-PE at the edge of an MPLS-= TP domain, e.g., for relying a PW status message that it has received over a= Targeted LDP session from the IP/MPLS domain to a static PW status message= to cross the MPLS-TP domain) for the bottom-of-stack position. The issue I am raising Is not new. It has been actively discussed on the PWE= 3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a WG d= ocument, with arguments for both the flow label and GAL taking the bottom-o= f-the-stack position. But, to the best of my understanding, consensus on thi= s issue has not been reached. Hopefully this comment will be useful. 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. 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD445ILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
    Pablo,
    Sorry, but I think you're wrong. Only T-= PE can insert the flow label (because only T=3DPE can be "flow-aware&qu= ot;). S-PE simply performs swap on PW label.<= /div>
     
    Regards,
         Sasha
     
    From: Pablo Frank= [pabloisnot@gmail.com]
    Sent: Wednesday, August 17, 2011 12:17 AM
    To: Alexander Vainshtein
    Cc: ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mish= ael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
    Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw

    I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS do= main in the middle segment, you're no longer in an MPLS-TP environment and s= o the GAL is not required to be BOS.  During that middle segment, the P= W flow label would be placed below the GAL and above the GACh.  It gets removed when it hits the S-PE tha= t switches you back into the MPLS-TP environment.  In other words, whet= her you're in an MPLS-TP environment is determined segment by segment in a M= S-PW.

    Pablo

    On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainsh= tein <Alexander.Vainshtein= @ecitele.com> wrote:
    Hi all,
    After having sent out my comments I've n= oticed that the specific example to illustrate the need to combine GAL and &= quot;flow label" was inaccurate.
     
    A more relevant example would look like<= a> following (I do not include a diagram, but it can be easily provided= if necessary)
    1. A MS-PW:
      • Starts at an S-PE that resides at the edg= e of an MPLS-TP domain (no ECMP)
      • Crosses this domain and enters an IP= /MPLS domain with ECMP enabled using a T-PE that resides at the age of these= two domains
      • Leaves this domain and enters a 2nd= MPLS-TP domain (using the 2nd T-PE)
      • Terminates on another S-PE at t= he edge of the 2nd MPLS-TP domain
    2. The operator intends to improve traf= fic distribution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs. Note that:
      • This does not violate the MPLS-TP restric= tion on ECMP: ECMP does not happen in he MPLS-TP domains
      • T-PEs do not even have to be aware o= f flow labels
    3. The operator also intends to operate= some end-to-end OAM for this MS-PW using "GAL-in-PW". This result= s in a conflict since both GAL and "flow label" are defined (in th= e corresponding drafts) as bottom of stack.

     

    IMHO this describes a realistic scenario where the two drafts are in contro= versy.
     
    Regards,
         Sas= ha
    From: mpls-bounces@ietf.org [mpls-bou= nces@ietf.org] On Behalf Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
    Sent: Tuesday, August 16, 2011 4:26 PM
    To: ietf@ietf.org
    Cc: mpls@ietf.org; Vladimir Klei= ner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen<= br> Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

    Hi all,

     

    I would like to raise the following issue with regard= to draft-ietf-pwe3-gal-in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-of-stack position.

     

    As stated in the Introduction, this draft removes the= restriction imposed by RFC 5586 on usage of Generic Associated Channel Labe= l (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states:

    In MPLS-TP, the GAL= MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs= , and with Sections, and MUST NOT be used with PWs.  It MUST always be at the bottom of the label stack &nb= sp;  (i.e., S bit set to 1).

     

    draft-ietf-pwe3-gal-in-pw proposed to replace the ori= ginal text in RFC 5586 with the following

     

    In MPLS-TP, the GAL= MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs= , and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit s= et to 1).

     

    I.e.,  while remov= ing this restriction of 5586, it does not modify its requirement for the GAL= being always at the bottom of the label stack.

     

    At the same draft-ietf-= pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the P= W stack for the PW flow labels, e.g., in Section 1.1:

     

    This document descri= bes a method of adding an additional label stack entry (LSE) at the bottom o= f stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs. 

     

    One could argue that dr= aft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-T= P does not use ECMP. IMHO and FWIW,

    such an argument, were= it presented, would be highly problematic, because:

     

    1.       RFC 5960 (which defines the MPLS-TP d= ata plane) did not define any differences between the PW data plane in IP/MP= LS and MPLS-TP.

    2.       One of the most popular scenarios for= using multi-segment pseudowires is the case when an edge-to-edge service em= ulation crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, th= e flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) would pote= ntially compete with GAL (inserted by a T-PE at the edge of an MPLS-TP domai= n, e.g., for relying a PW status message that it has received over a Targete= d LDP session from the IP/MPLS domain to a static PW status message to cross the MPLS-TP domain) for the b= ottom-of-stack position.

     

    The issue I am raising= Is not new. It has been actively discussed on the PWE3 mailing list with re= gard to adoption of draft-nadeau-pwe3-vccv-2 as a WG document, with argument= s  for both the flow label and GAL taking the bottom-of-the-stack position. But, to the best of my understandi= ng, consensus on this issue has not been reached.

     

    Hopefully this comment will be useful.

     

    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.

    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_A3C5DF08D38B6049839A6F553B331C760111EF7BD445ILPTMAIL02e_-- From Alexander.Vainshtein@ecitele.com Tue Aug 16 20:52: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 BE9B321F8782 for ; Tue, 16 Aug 2011 20:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=1.626, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR0YS-yKFdfm for ; Tue, 16 Aug 2011 20:52:56 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 2332521F8781 for ; Tue, 16 Aug 2011 20:52:55 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1313553219!45574116!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [147.234.242.235] Received: (qmail 26339 invoked from network); 17 Aug 2011 03:53:40 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-13.tower-21.messagelabs.com with SMTP; 17 Aug 2011 03:53:40 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-dc-4e4b3481c660 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 7E.61.16719.1843B4E4; Wed, 17 Aug 2011 06:24:49 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 17 Aug 2011 06:53:43 +0300 From: Alexander Vainshtein To: "lizhong.jin@zte.com.cn" Date: Wed, 17 Aug 2011 06:50:10 +0300 Thread-Topic: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxckD2sGjdkpUGsQiWYH2uTvRKVgAAAJLdo 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD446ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphl+LIzCtJLcpLzFFi42KZ/OrTF91GE28/g/VNRhZHu/4xWtxaupLV ou/TFhYHZo8lS34yeazZ94MlgCmqgdEmMS8vvySxJFUhJbU42VYpoCizLDG5UkkhM8VWyVBJ oSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb761pYmFrqGirZqSkb GltzhWRkFiuk6uYmZuYo5KYWFyempyoARRK2MGe87mhmKdgcUTF9SnADY593FyMnh4SAicTe 87MZIWwxiQv31rOB2EICOxklervTuhi5gOwpjBJzX7xlB0mwCdhKbFp9F6iIg0NEwFTizrZM kBpmgUNMEj8uv2ABqWERUJVo3LkCzBYWcJfoX7YCbIGIgIfEzMUn2SFsI4ltK/awgszhFQiU eHqLG2JvvcT6lnVgJZwCwRKXFm8AsxmBbvt+ag0TiM0sIC5x68l8JoibBSSW7DnPDGGLSrx8 /I8Vol5U4k77ekaI+nyJuR1PwM7hFRCUODkTwpYQkJQ4uOIGywRGsVlIxs5C0jILSQtEXE/i xtQpbBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FKJmZU1CSlJtuYKSbX1qil5qcWZKak6qXnJ+7 iRGShF7sYLx9RvMQowAHoxIPr2eHl58Qa2JZcWXuIUZJDiYlUd6dlt5+QnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4XRiBcrwpiZVVqUX5MClXYARMZJbiTs4HJta8knhjAwPcHCVx3u7kN75C AunAtJmdmlqQWgQzR4aDQ0mCd7sV0ArBotT01Iq0zJwShDQTByfIGTxAZ9SDnMhbXJCYW5yZ DpE/xagoBTQapFkAJJFRmgfXC8o89f///3/FKA70tDDECh5g1oLrfgU0mAlo8K1dHiCDgfkG LiXVwHi2oaLaYH3GBosyXcErJ+33G3PbezjKsbycEqh+Q7xYY/aMPf96WJ6/+8TFJfnQJKDP 5uQ8dZEQk42nP3aeiT4tvkrzZ3qFXUDsK/XAu7WfWvrzbV9l7/k3UdM6YNrf5X8ND5+P8D3X mv9pRe6cG1POSTYtsu2c2cmhP4PNKDopIllTctGqu0osxRmJhlrMRcWJAEKnGxYXBAAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , "pwe3@ietf.org" , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 17 Aug 2011 03:52:57 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD446ILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi Lizhong, No. I mean that the flow label can be inserted by T-PE (and only by T-PE) e= ven if some of the domains that are crossed by an MS-PW do not perform ECMP.= In the case of an MPLS-TP domain, ECMP would be simply disabled. But in an= IP/MPLS domain ECP can be enabled, and the hash would include flow labels. Hopefully this clarifies my position. Regards, Sasha ________________________________ From: lizhong.jin@zte.com.cn [lizhong.jin@zte.com.cn] Sent: Wednesday, August 17, 2011 6:46 AM To: Alexander Vainshtein Cc: pwe3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wex= ler; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi Sasha, Do you mean different PW segments of one MS-PW could support different flow= label capability? If in that case, flow LSE is not transparent to the label= swap operation on S-PE, Flow Label Sub-TLV signalling is also not transitiv= e, which is conflict with section 6 of draft-ietf-pwe3-fat-pw. If we want to= do this, we have to change the draft-fat-pw. Regards Lizhong > ------------------------------ > > Message: 5 > Date: Tue, 16 Aug 2011 20:02:20 +0300 > From: Alexander Vainshtein > To: "ietf@ietf.org" > Cc: "mpls@ietf.org" , Vladimir Kleiner > , Idan Kaspit = , > Mishael Wexler , pwe3 , > Oren Gal , John Shirron > , Rotem Cohen > Subject: Re: [PWE3] IETF Last Call comment on > draft-ietf-pwe3-gal-in-pw > Message-ID: > > Content-Type: text/plain; charset=3D"iso-8859-1" > > Hi all, > After having sent out my comments I've noticed that the specific > example to illustrate the need to combine GAL and "flow label" was inaccur= ate. > > A more relevant example would look like following (I do not include > a diagram, but it can be easily provided if necessary) > > 1. A MS-PW: > * Starts at an S-PE that resides at the edge of an MPLS-TP > domain (no ECMP) > * Crosses this domain and enters an IP/MPLS domain with ECMP > enabled using a T-PE that resides at the age of these two domains > * Leaves this domain and enters a 2nd MPLS-TP domain (using > the 2nd T-PE) > * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain > 2. The operator intends to improve traffic distribution in the > IP/MPLS domain, hence he enables insertion and discard of "flow > labels" at the two S-PEs. Note that: > * This does not violate the MPLS-TP restriction on ECMP: ECMP > does not happen in he MPLS-TP domains > * T-PEs do not even have to be aware of flow labels > 3. The operator also intends to operate some end-to-end OAM for > this MS-PW using "GAL-in-PW". This results in a conflict since both > GAL and "flow label" are defined (in the corresponding drafts) as > bottom of stack. > > > > IMHO this describes a realistic scenario where the two drafts are in > controversy. > > Regards, > Sasha > _____________________________ -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is s= olely property of the sender's organization. This mail communication is conf= idential. Recipients named above are obligated to maintain secrecy and are n= ot permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended s= olely 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 m= essage. Any views expressed in this message are those of the individual send= er. 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 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD446ILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
    Hi Lizhong,
    No.  I mean that the flow label can= be inserted by T-PE (and only by T-PE) even if some of the domains that are= crossed by an MS-PW do not perform ECMP. In the case of an MPLS-TP domain,= ECMP would be simply disabled. But in an IP/MPLS domain ECP can be enabled, and the hash would include flow label= s.
     
    Hopefully this clarifies my position.
      
    Regards,
         Sasha
     
    From: lizhong.jin@= zte.com.cn [lizhong.jin@zte.com.cn]
    Sent: Wednesday, August 17, 2011 6:46 AM
    To: Alexander Vainshtein
    Cc: pwe3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mish= ael Wexler; Oren Gal; John Shirron; Rotem Cohen
    Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw


    Hi Sasha,
    Do you mean different PW segments of one MS-PW could su= pport different flow label capability? If in that case, flow LSE is not tran= sparent to the label swap operation on S-PE, Flow Label Sub-TLV signalling i= s also not transitive, which is conflict with section 6 of draft-ietf-pwe3-fat-pw. If we want to do this, w= e have to change the draft-fat-pw.

    Regards
    Lizhong


    > ------------------------------
    >
    > Message: 5
    > Date: Tue, 16 Aug 2011 20:02:20 +0300
    > From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
    > To: "ietf@ietf.org" <ietf@ietf.org>
    > Cc: "mpls@ietf.org" <mpls@ietf.org>,   Vladimir Kl= einer
    >    <Vladimir.Kleiner@ecitele.com>,   Idan Kaspit &= lt;Idan.Kaspit@ecitele.com>,
    >    Mishael Wexler <Mishael.Wexler@ecitele.com>,  = pwe3 <pwe3@ietf.org>,
    >    Oren Gal <Oren.Gal@ecitele.com>,   John Shirron=
    >    <John.Shirron@ecitele.com>,   Rotem Cohen <R= otem.Cohen@ecitele.com>
    > Subject: Re: [PWE3] IETF Last Call comment on
    >    draft-ietf-pwe3-gal-in-pw
    > Message-ID:
    >    <A3C5DF08D38B6049839A6F553B331C760111EF7BD443@ILPTMAIL0= 2.ecitele.com>
    > Content-Type: text/plain; charset=3D"iso-8859-1"
    >
    > Hi all,
    > After having sent out my comments I've noticed that the specific
    > example to illustrate the need to combine GAL and "flow label"= ; was inaccurate.
    >
    > A more relevant example would look like following (I do not include > a diagram, but it can be easily provided if necessary)
    >
    >  1.  A MS-PW:
    >     *   Starts at an S-PE that resides at the edge of an= MPLS-TP
    > domain (no ECMP)
    >     *   Crosses this domain and enters an IP/MPLS domain= with ECMP
    > enabled using a T-PE that resides at the age of these two domains
    >     *   Leaves this domain and enters a 2nd MPLS-TP doma= in (using
    > the 2nd T-PE)
    >     *   Terminates on another S-PE at the edge of the 2n= d MPLS-TP domain
    >  2.  The operator intends to improve traffic distribution in= the
    > IP/MPLS domain, hence he enables insertion and discard of "flow > labels" at the two S-PEs. Note that:
    >     *   This does not violate the MPLS-TP restriction on= ECMP: ECMP
    > does not happen in he MPLS-TP domains
    >     *   T-PEs do not even have to be aware of flow label= s
    >  3.  The operator also intends to operate some end-to-end OAM= for
    > this MS-PW using "GAL-in-PW". This results in a conflict sinc= e both
    > GAL and "flow label" are defined (in the corresponding drafts= ) as
    > bottom of stack.
    >
    >
    >
    > IMHO this describes a realistic scenario where the two drafts are in > controversy.
    >
    > Regards,
    >      Sasha
    > _____________________________
    --------------------------------------------------------
ZTE Information Security Notice: The information&nb=
sp;contained in this mail is solely property&n=
bsp;of the sender's organization. This mail co=
mmunication is confidential. 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&n=
bsp;the use of the individual or entity t=
o whom they are addressed. If you have&nb=
sp;received this email in error please notify&=
nbsp;the originator of the message. Any views&=
nbsp;expressed in this message are those of&nb=
sp;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 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD446ILPTMAIL02e_-- From lizhong.jin@zte.com.cn Tue Aug 16 21:13: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 D80BF11E80BF; Tue, 16 Aug 2011 21:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.713 X-Spam-Level: X-Spam-Status: No, score=-101.713 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU68aFQbRPRS; Tue, 16 Aug 2011 21:13:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E751411E8084; Tue, 16 Aug 2011 21:13:19 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131322203882679; Wed, 17 Aug 2011 12:01:50 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 52059.6445880624; Wed, 17 Aug 2011 12:13:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p7H4E2iu053148; Wed, 17 Aug 2011 12:14:02 +0800 (GMT-8) (envelope-from lizhong.jin@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: lizhong.jin@zte.com.cn Date: Wed, 17 Aug 2011 12:13:42 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-17 12:13:53, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-17 12:13:53, Serialize complete at 2011-08-17 12:13:53, S/MIME Sign failed at 2011-08-17 12:13:53: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-17 12:14:03, Serialize complete at 2011-08-17 12:14:03 Content-Type: multipart/alternative; boundary="=_alternative 00173EBF482578EF_=" X-MAIL: mse01.zte.com.cn p7H4E2iu053148 Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , "pwe3@ietf.org" , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 17 Aug 2011 04:13:22 -0000 This is a multipart message in MIME format. --=_alternative 00173EBF482578EF_= Content-Type: text/plain; charset="US-ASCII" Hi Sasha, But in your example, you said: "The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs". It seems that you want S-PE to insert and remove flow label. Regards Lizhong Alexander Vainshtein wrote on 2011-08-17 11:50:10: > Hi Lizhong, > No. I mean that the flow label can be inserted by T-PE (and only by > T-PE) even if some of the domains that are crossed by an MS-PW do > not perform ECMP. In the case of an MPLS-TP domain, ECMP would be > simply disabled. But in an IP/MPLS domain ECP can be enabled, and > the hash would include flow labels. > > Hopefully this clarifies my position. > > Regards, > Sasha > > From: lizhong.jin@zte.com.cn [lizhong.jin@zte.com.cn] > Sent: Wednesday, August 17, 2011 6:46 AM > To: Alexander Vainshtein > Cc: pwe3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > Mishael Wexler; Oren Gal; John Shirron; Rotem Cohen > Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > Hi Sasha, > Do you mean different PW segments of one MS-PW could support > different flow label capability? If in that case, flow LSE is not > transparent to the label swap operation on S-PE, Flow Label Sub-TLV > signalling is also not transitive, which is conflict with section 6 > of draft-ietf-pwe3-fat-pw. If we want to do this, we have to change > the draft-fat-pw. > > Regards > Lizhong > > > > ------------------------------ > > > > Message: 5 > > Date: Tue, 16 Aug 2011 20:02:20 +0300 > > From: Alexander Vainshtein > > To: "ietf@ietf.org" > > Cc: "mpls@ietf.org" , Vladimir Kleiner > > , Idan Kaspit , > > Mishael Wexler , pwe3 , > > Oren Gal , John Shirron > > , Rotem Cohen > > Subject: Re: [PWE3] IETF Last Call comment on > > draft-ietf-pwe3-gal-in-pw > > Message-ID: > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > Hi all, > > After having sent out my comments I've noticed that the specific > > example to illustrate the need to combine GAL and "flow label" was > inaccurate. > > > > A more relevant example would look like following (I do not include > > a diagram, but it can be easily provided if necessary) > > > > 1. A MS-PW: > > * Starts at an S-PE that resides at the edge of an MPLS-TP > > domain (no ECMP) > > * Crosses this domain and enters an IP/MPLS domain with ECMP > > enabled using a T-PE that resides at the age of these two domains > > * Leaves this domain and enters a 2nd MPLS-TP domain (using > > the 2nd T-PE) > > * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain > > 2. The operator intends to improve traffic distribution in the > > IP/MPLS domain, hence he enables insertion and discard of "flow > > labels" at the two S-PEs. Note that: > > * This does not violate the MPLS-TP restriction on ECMP: ECMP > > does not happen in he MPLS-TP domains > > * T-PEs do not even have to be aware of flow labels > > 3. The operator also intends to operate some end-to-end OAM for > > this MS-PW using "GAL-in-PW". This results in a conflict since both > > GAL and "flow label" are defined (in the corresponding drafts) as > > bottom of stack. > > > > > > > > IMHO this describes a realistic scenario where the two drafts are in > > controversy. > > > > Regards, > > Sasha > > _____________________________ -------------------------------------------------------- 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 00173EBF482578EF_= Content-Type: text/html; charset="US-ASCII"
    Hi Sasha,
    But in your example, you said: "The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs". It seems that you want S-PE to insert and remove flow label.

    Regards
    Lizhong
     

    Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote on 2011-08-17 11:50:10:

    > Hi Lizhong,
    > No.  I mean that the flow label can be inserted by T-PE (and only by
    > T-PE) even if some of the domains that are crossed by an MS-PW do
    > not perform ECMP. In the case of an MPLS-TP domain, ECMP would be
    > simply disabled. But in an IP/MPLS domain ECP can be enabled, and
    > the hash would include flow labels.
    >  
    > Hopefully this clarifies my position.
    >    
    > Regards,
    >      Sasha
    >  
    > From: lizhong.jin@zte.com.cn [lizhong.jin@zte.com.cn]
    > Sent: Wednesday, August 17, 2011 6:46 AM
    > To: Alexander Vainshtein
    > Cc: pwe3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit;
    > Mishael Wexler; Oren Gal; John Shirron; Rotem Cohen
    > Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
    >
    > Hi Sasha,
    > Do you mean different PW segments of one MS-PW could support
    > different flow label capability? If in that case, flow LSE is not
    > transparent to the label swap operation on S-PE, Flow Label Sub-TLV
    > signalling is also not transitive, which is conflict with section 6
    > of draft-ietf-pwe3-fat-pw. If we want to do this, we have to change
    > the draft-fat-pw.
    >
    > Regards
    > Lizhong
    >
    >
    > > ------------------------------
    > >
    > > Message: 5
    > > Date: Tue, 16 Aug 2011 20:02:20 +0300
    > > From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
    > > To: "ietf@ietf.org" <ietf@ietf.org>
    > > Cc: "mpls@ietf.org" <mpls@ietf.org>,   Vladimir Kleiner
    > >    <Vladimir.Kleiner@ecitele.com>,   Idan Kaspit <Idan.Kaspit@ecitele.com>,
    > >    Mishael Wexler <Mishael.Wexler@ecitele.com>,   pwe3 <pwe3@ietf.org>,
    > >    Oren Gal <Oren.Gal@ecitele.com>,   John Shirron
    > >    <John.Shirron@ecitele.com>,   Rotem Cohen <Rotem.Cohen@ecitele.com>
    > > Subject: Re: [PWE3] IETF Last Call comment on
    > >    draft-ietf-pwe3-gal-in-pw
    > > Message-ID:
    > >    <A3C5DF08D38B6049839A6F553B331C760111EF7BD443@ILPTMAIL02.ecitele.com>
    > > Content-Type: text/plain; charset="iso-8859-1"
    > >
    > > Hi all,
    > > After having sent out my comments I've noticed that the specific
    > > example to illustrate the need to combine GAL and "flow label" was
    > inaccurate.
    > >
    > > A more relevant example would look like following (I do not include
    > > a diagram, but it can be easily provided if necessary)
    > >
    > >  1.  A MS-PW:
    > >     *   Starts at an S-PE that resides at the edge of an MPLS-TP
    > > domain (no ECMP)
    > >     *   Crosses this domain and enters an IP/MPLS domain with ECMP
    > > enabled using a T-PE that resides at the age of these two domains
    > >     *   Leaves this domain and enters a 2nd MPLS-TP domain (using
    > > the 2nd T-PE)
    > >     *   Terminates on another S-PE at the edge of the 2nd MPLS-TP domain
    > >  2.  The operator intends to improve traffic distribution in the
    > > IP/MPLS domain, hence he enables insertion and discard of "flow
    > > labels" at the two S-PEs. Note that:
    > >     *   This does not violate the MPLS-TP restriction on ECMP: ECMP
    > > does not happen in he MPLS-TP domains
    > >     *   T-PEs do not even have to be aware of flow labels
    > >  3.  The operator also intends to operate some end-to-end OAM for
    > > this MS-PW using "GAL-in-PW". This results in a conflict since both
    > > GAL and "flow label" are defined (in the corresponding drafts) as
    > > bottom of stack.
    > >
    > >
    > >
    > > IMHO this describes a realistic scenario where the two drafts are in
    > > controversy.
    > >
    > > Regards,
    > >      Sasha
    > > _____________________________     

    --------------------------------------------------------
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 00173EBF482578EF_=-- From Alexander.Vainshtein@ecitele.com Tue Aug 16 23: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 9A89B11E8073; Tue, 16 Aug 2011 23:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=1.536, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxEP4+oCs9vy; Tue, 16 Aug 2011 23:30:59 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id A302D21F88B6; Tue, 16 Aug 2011 23:30:56 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1313562657!36239923!51 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.3.6; banners=-,-,- Received: (qmail 13824 invoked from network); 17 Aug 2011 06:31:27 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-3.tower-27.messagelabs.com with SMTP; 17 Aug 2011 06:31:27 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-cd-4e4b598a2a1c Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 7D.A3.16719.A895B4E4; Wed, 17 Aug 2011 09:02:50 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 17 Aug 2011 09:31:43 +0300 From: Alexander Vainshtein To: "lizhong.jin@zte.com.cn" Date: Wed, 17 Aug 2011 09:31:42 +0300 Thread-Topic: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxclBiztob2ezI4RW2U2WrjeJlVwQAEchqw 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_A3C5DF08D38B6049839A6F553B331C760111EFA07D72ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTXUgUURTmzqy748/UdVP3Kj2s0x+lG2pFG7aS/VqSGfaSL9s4e9ud2p3d ZkbTKDMS0tXKEqw2+pHMLCPBNCJNS5FShIpezH5ekiiLSoksi2xmJ02I7tN3z/ed75zLPYci jWWGOIoXZCwKrJvRh+mqh0e/WPzbM7OSvpYut/b4fwHr4OWrIdZjoy26VWRGXd13IuN6xzdd NpFbAlayguCVWRmbHVjibEy2yBewXBFj5h02Jpkx+9wshz1YkG0M6/NhwcGkhZn/OSsVGS+Y scB5HbzgtDEbc7ZYrNZlKyzJTNr8OclLUsO2uXjJjC0elnebPViSWCc2K5EdLaRrvLeJ9HXX gsInR8/qS8D7SuAHoRSCS1HVzx+khmPQ41dNej8Io4ywDaDyT5U6lTDCGoCqR6wq1kMbam58 qYgoKgouQy9u8aqehF0EujFy06BqdHAeGqh6EjSdBTeg4/UNwWJRMAOdudRr0HAK+nypgVR9 aLgV1d6fr9UNAOQ/XRKsGwpz0J3SoSAGSnNjfdcJFZPQhAaHLhBa0xDVtT/684Bo9O71rxBN H41eHGkCmt6LHjx9F9TQMBL1ntE8EYxF9xsGdFUgJjDNNjAtJTAtRYsnootto3oNJ6D62vfk JO6/95qYHr8IDNdALO/2yXkeZ1KKxZsvL8YcL2M3Xsx5Pc1AG6O3t8Hz/oVdAFKAiaA3lm3K MoawBVKRpwvEUgQTTa+2Z2YZZ+R5HUUuVnLZxXw3lroAokgmil4LFI52sEX7sOidpNYpP3CC jAvnvMrACrJ9SVLS/y+Mia7gPmw2Qqcyn7sx9mFx0mc2RTGILlXLR4rYiQt38m75L01QoWob EUoba1QNLflYj8Q7Nb4PxMeZ6FMqAVXClS9M5aoLdHBiYmIYmJRHz6IPqKoIZb2msocVY0Ix HryToRoruzNFxZUAe2ruTBGCE3XrozMH0scb4xdWHi9ImFtsenPSOdY/5MxpNXQsfd6z31GV a79ij6luF8Pt5RvOdVdHzLTNSHlW4yBq7K3jC9K54rudD8ZG0j9PJKRmpu06OZS489bDjlEx T9+4/mM4ffj0+ZZA6KFHkcKxikDnp71ifCG952pf/FZGJ7nY5EWkKLG/AUMN7+QbBAAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , "pwe3@ietf.org" , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 17 Aug 2011 06:31:02 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EFA07D72ILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Lizhong, Oops! This was a typo, T-PE intended there. Lots of thanks for catching it. Only T-PEs can insert flow labels, and it is insertion by T-PEs which makes= the scenario problematic, because it combines: 1. ECMP in the "middle" IP/MPLS domain based on hashing of the label s= tack and hence requiring flow labels "end-to-end" 2. End-to-end fate-sharing OAM which, if VCCV Type 1 is not available,= would presumably require GAL to guarantee that OAM packets do not leak to r= emote CE. Regards, Sasha From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn] Sent: Wednesday, August 17, 2011 7:14 AM To: Alexander Vainshtein Cc: Idan Kaspit; John Shirron; Mishael Wexler; mpls@ietf.org; Oren Gal; pwe3= @ietf.org; Rotem Cohen; Vladimir Kleiner Subject: RE: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Hi Sasha, But in your example, you said: "The operator intends to improve traffic dist= ribution in the IP/MPLS domain, hence he enables insertion and discard of "f= low labels" at the two S-PEs". It seems that you want S-PE to insert and rem= ove flow label. Regards Lizhong Alexander Vainshtein wrote on 2011-08-17= 11:50:10: > Hi Lizhong, > No. I mean that the flow label can be inserted by T-PE (and only by > T-PE) even if some of the domains that are crossed by an MS-PW do > not perform ECMP. In the case of an MPLS-TP domain, ECMP would be > simply disabled. But in an IP/MPLS domain ECP can be enabled, and > the hash would include flow labels. > > Hopefully this clarifies my position. > > Regards, > Sasha > > From: lizhong.jin@zte.com.cn [lizhong.jin@zte.com.cn] > Sent: Wednesday, August 17, 2011 6:46 AM > To: Alexander Vainshtein > Cc: pwe3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > Mishael Wexler; Oren Gal; John Shirron; Rotem Cohen > Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > Hi Sasha, > Do you mean different PW segments of one MS-PW could support > different flow label capability? If in that case, flow LSE is not > transparent to the label swap operation on S-PE, Flow Label Sub-TLV > signalling is also not transitive, which is conflict with section 6 > of draft-ietf-pwe3-fat-pw. If we want to do this, we have to change > the draft-fat-pw. > > Regards > Lizhong > > > > ------------------------------ > > > > Message: 5 > > Date: Tue, 16 Aug 2011 20:02:20 +0300 > > From: Alexander Vainshtein > > To: "ietf@ietf.org" > > Cc: "mpls@ietf.org" , Vladimir Kleiner > > , Idan Kaspit , > > Mishael Wexler , pwe3 , > > Oren Gal , John Shirron > > , Rotem Cohen > > Subject: Re: [PWE3] IETF Last Call comment on > > draft-ietf-pwe3-gal-in-pw > > Message-ID: > > > > Content-Type: text/plain; charset=3D"iso-8859-1" > > > > Hi all, > > After having sent out my comments I've noticed that the specific > > example to illustrate the need to combine GAL and "flow label" was > inaccurate. > > > > A more relevant example would look like following (I do not include > > a diagram, but it can be easily provided if necessary) > > > > 1. A MS-PW: > > * Starts at an S-PE that resides at the edge of an MPLS-TP > > domain (no ECMP) > > * Crosses this domain and enters an IP/MPLS domain with ECMP > > enabled using a T-PE that resides at the age of these two domains > > * Leaves this domain and enters a 2nd MPLS-TP domain (using > > the 2nd T-PE) > > * Terminates on another S-PE at the edge of the 2nd MPLS-TP domain > > 2. The operator intends to improve traffic distribution in the > > IP/MPLS domain, hence he enables insertion and discard of "flow > > labels" at the two S-PEs. Note that: > > * This does not violate the MPLS-TP restriction on ECMP: ECMP > > does not happen in he MPLS-TP domains > > * T-PEs do not even have to be aware of flow labels > > 3. The operator also intends to operate some end-to-end OAM for > > this MS-PW using "GAL-in-PW". This results in a conflict since both > > GAL and "flow label" are defined (in the corresponding drafts) as > > bottom of stack. > > > > > > > > IMHO this describes a realistic scenario where the two drafts are in > > controversy. > > > > Regards, > > Sasha > > _____________________________ -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is s= olely property of the sender's organization. This mail communication is conf= idential. Recipients named above are obligated to maintain secrecy and are n= ot permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended s= olely 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 m= essage. Any views expressed in this message are those of the individual send= er. 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 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_A3C5DF08D38B6049839A6F553B331C760111EFA07D72ILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

    Lizhong,

     

    Oops! This was a typo, T-PE intended there. Lots of= thanks for catching it.

     

    Only T-PEs can insert f= low labels, and it is insertion by T-PEs which makes the scenario problemati= c, because it combines:

     

    1.  &nbs= p;    <= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4= 97D'>ECMP in the “middle” IP/MPLS domain based on hashing of the= label stack and hence requiring flow labels “end-to-end” <= /o:p>

    2.    =    End= -to-end fate-sharing OAM which, if VCCV Type 1 is not available, would presu= mably require GAL to guarantee that OAM packets do not leak to remote CE.

     

    Regards,

    =      Sasha

     

    From:= lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn]
    Sent: W= ednesday, August 17, 2011 7:14 AM
    To: Alexander Vainshtein
    C= c: Idan Kaspit; John Shirron; Mishael Wexler; mpls@ietf.org; Oren Gal; p= we3@ietf.org; Rotem Cohen; Vladimir Kleiner
    Subject: RE: [PWE3] IE= TF Last Call comment on draft-ietf-pwe3-gal-in-pw

     


    Hi Sasha,
    But in your example, you said: "The operator intends to improve traffic= distribution in the IP/MPLS domain, hence he enables insertion and discard= of "flow labels" at the two S-PEs". It seems that you want S= -PE to insert and remove flow label.

    Regards
    Lizhong
     

    A= lexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote on 2011-0= 8-17 11:50:10:

    > Hi Lizhong,
    > No.  I mean that the flow label can be inserted by= T-PE (and only by
    > T-PE) even if some of the domains that are crossed= by an MS-PW do
    > not perform ECMP. In the case of an MPLS-T= P domain, ECMP would be
    > simply disabled. But in an IP/MPLS= domain ECP can be enabled, and
    > the hash would include flo= w labels.
    >  
    > Hopefully this clar= ifies my position.
    >=    
    > Reg= ards,
    >    = ;  Sasha
    > &nbs= p;
    > From: lizhong.j= in@zte.com.cn [lizhong.jin@zte.com.cn]
    > Sent: Wednesday, August 17, 20= 11 6:46 AM
    > To: Alexander Vainshtein
    > Cc: pw= e3@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit;
    >= Mishael Wexler; Oren Gal; John Shirron; Rotem Cohen
    > Subjec= t: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

    >
    > Hi Sasha, =
    > Do you mean different PW segments of one MS-PW could support
    > different flow label capability? If in that case, flow LSE i= s not
    > transparent to the label swap operation on S-PE, Flo= w Label Sub-TLV
    > signalling is also not transitive, which i= s conflict with section 6
    > of draft-ietf-pwe3-fat-pw. If we= want to do this, we have to change
    > the draft-fat-pw.
    >
    > Regards
    > Lizhong
    <= tt>>
    >
    > > ---------------------------= ---
    > >
    > > Message: 5
    >= > Date: Tue, 16 Aug 2011 20:02:20 +0300
    > > From: Alex= ander Vainshtein <Alexander.Vainshtein@ecitele.com>
    > &= gt; To: "ietf@ietf.org" <ietf@ietf.org>
    > >= ; Cc: "mpls@ietf.org" <mpls@ietf.org>,   Vladimir Klein= er
    > >    <Vladimir.Kleiner@ecitele.com>,=   Idan Kaspit <Idan.Kaspit@ecitele.com>,
    > > &= nbsp;  Mishael Wexler <Mishael.Wexler@ecitele.com>,   pwe3 &= lt;pwe3@ietf.org>,
    > >    Oren Gal <Oren.G= al@ecitele.com>,   John Shirron
    > >    &= lt;John.Shirron@ecitele.com>,   Rotem Cohen <Rotem.Cohen@ecitele.= com>
    > > Subject: Re: [PWE3] IETF Last Call comment on<= /tt>
    > >    draft-ietf-pwe3-gal-in-pw
    >= ; > Message-ID:
    > >    <A3C5DF08D38B604983= 9A6F553B331C760111EF7BD443@ILPTMAIL02.ecitele.com>
    > >= Content-Type: text/plain; charset=3D"iso-8859-1"
    >= >
    > > Hi all,
    > > After having sent= out my comments I've noticed that the specific
    > > examp= le to illustrate the need to combine GAL and "flow label" was=
    > inaccurate.
    > >
    > > A more= relevant example would look like following (I do not include
    &= gt; > a diagram, but it can be easily provided if necessary)
    = > >
    > >  1.  A MS-PW:
    > &g= t;     *   Starts at an S-PE that resides at the edge of an M= PLS-TP
    > > domain (no ECMP)
    > >  =   *   Crosses this domain and enters an IP/MPLS domain with ECMP=
    > > enabled using a T-PE that resides at the age of thes= e two domains
    > >     *   Leaves this domai= n and enters a 2nd MPLS-TP domain (using
    > > the 2nd T-PE= )
    > >     *   Terminates on another S-PE at= the edge of the 2nd MPLS-TP domain
    > >  2.  The= operator intends to improve traffic distribution in the
    > &= gt; IP/MPLS domain, hence he enables insertion and discard of "flow
    > > labels" at the two S-PEs. Note that:
    &g= t; >     *   This does not violate the MPLS-TP restriction= on ECMP: ECMP
    > > does not happen in he MPLS-TP domains<= /tt>
    > >     *   T-PEs do not even have to be aw= are of flow labels
    > >  3.  The operator also in= tends to operate some end-to-end OAM for
    > > this MS-PW u= sing "GAL-in-PW". This results in a conflict since both
    <= tt>> > GAL and "flow label" are defined (in the correspondin= g drafts) as
    > > bottom of stack.
    > > <= /tt>
    > >
    > >
    > > IMHO thi= s describes a realistic scenario where the two drafts are in
    >= ; > controversy.
    > >
    > > Regards,
    > >      Sasha
    > > ________= _____________________     

     
    --------------------------------------------------------
    ZTE Information Security Notice: The inform=
ation contained in this mail is solely pr=
operty of the sender's organization. This mail=
 communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy and=
 are not permitted to disclose the conten=
ts of this communication to others.
    This email and any files transmitted wit=
h it are confidential and intended solely =
;for the use of the individual or entity&=
nbsp;to whom they are addressed. If you h=
ave received this email in error please n=
otify the originator of the message. Any =
views expressed in this message are those =
;of the individual sender.
    This mes=
sage has been scanned for viruses and Spa=
m by ZTE Anti-Spam system.
    <= p> 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_A3C5DF08D38B6049839A6F553B331C760111EFA07D72ILPTMAIL02e_-- From lmartini@cisco.com Wed Aug 17 11:57:44 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 1CF9821F8A56; Wed, 17 Aug 2011 11:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el+or8lu+69g; Wed, 17 Aug 2011 11:57:43 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0027D21F87FA; Wed, 17 Aug 2011 11:57:42 -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 p7HIw78g021987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Aug 2011 12:58:11 -0600 (MDT) Message-ID: <4E4C0F3F.8010700@cisco.com> Date: Wed, 17 Aug 2011 12:58:07 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Alexander Vainshtein References: , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 17 Aug 2011 18:57:44 -0000 The solution is quite simple: "Flow Labels MUST not be used in an MPLS-TP environment." Luca On 08/16/11 21:46, Alexander Vainshtein wrote: > Pablo, > Sorry, but I think you're wrong. Only T-PE can insert the flow label > (because only T=PE can be "flow-aware"). S-PE simply performs swap on > PW label. > > Regards, > Sasha > > ------------------------------------------------------------------------ > *From:* Pablo Frank [pabloisnot@gmail.com] > *Sent:* Wednesday, August 17, 2011 12:17 AM > *To:* Alexander Vainshtein > *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS > domain in the middle segment, you're no longer in an MPLS-TP > environment and so the GAL is not required to be BOS. During that > middle segment, the PW flow label would be placed below the GAL and > above the GACh. It gets removed when it hits the S-PE that switches > you back into the MPLS-TP environment. In other words, whether you're > in an MPLS-TP environment is determined segment by segment in a MS-PW. > > Pablo > > On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > > wrote: > > Hi all, > After having sent out my comments I've noticed that the specific > example to illustrate the need to combine GAL and "flow label" was > inaccurate. > > A more relevant example would look like following (I do not > include a diagram, but it can be easily provided if necessary) > > 1. A MS-PW: > * Starts at an S-PE that resides at the edge of an MPLS-TP > domain (no ECMP) > * Crosses this domain and enters an IP/MPLS domain with ECMP > enabled using a T-PE that resides at the age of these two > domains > * Leaves this domain and enters a 2nd MPLS-TP domain (using > the 2nd T-PE) > * Terminates on another S-PE at the edge of the 2nd MPLS-TP > domain > 2. The operator intends to improve traffic distribution in the > IP/MPLS domain, hence he enables insertion and discard of > "flow labels" at the two S-PEs. Note that: > * This does not violate the MPLS-TP restriction on ECMP: > ECMP does not happen in he MPLS-TP domains > * T-PEs do not even have to be aware of flow labels > 3. The operator also intends to operate some end-to-end OAM for > this MS-PW using "GAL-in-PW". This results in a conflict since > both GAL and "flow label" are defined (in the corresponding > drafts) as bottom of stack. > > > > IMHO this describes a realistic scenario where the two drafts are > in controversy. > > Regards, > Sasha > ------------------------------------------------------------------------ > *From:* mpls-bounces@ietf.org > [mpls-bounces@ietf.org ] On Behalf > Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com > ] > *Sent:* Tuesday, August 16, 2011 4:26 PM > *To:* ietf@ietf.org > *Cc:* mpls@ietf.org ; Vladimir Kleiner; Idan > Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > Hi all, > > > > I would like to raise the following issue with regard to > draft-ietf-pwe3-gal-in-pw > : > controversy vs. draft-ietf-pwe3-fat-pw > > with regard to bottom-of-stack position. > > > > As stated in the Introduction, this draft removes the restriction > imposed by RFC 5586 on usage of Generic Associated Channel Label > (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states: > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MUST NOT be > used with PWs. It MUST always be at the bottom of the label stack > (i.e., S bit set to 1). > > > > draft-ietf-pwe3-gal-in-pw proposed to replace the original text in > RFC 5586 with the following > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MAY be used > with PWs. It MUST always be at the bottom of the label stack > (i.e., S bit set to 1). > > > > I.e., while removing this restriction of 5586, it does not modify > its requirement for the GAL being always at the bottom of the > label stack. > > > > At the same draft-ietf-pwe3-fat-pw (currently also in the IESG > review) reserves the bottom of the PW stack for the PW flow > labels, e.g., in Section 1.1: > > > > This document describes a method of adding an additional label > stack entry (LSE) at the bottom of stack in order to facilitate > the load balancing of the flows within a PW over the available > ECMPs. > > > > One could argue that draft-ietf-pwe3-gal-in-pw only applies to > MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and > FWIW, > > such an argument, were it presented, would be highly problematic, > because: > > > > 1. RFC 5960 (which defines the MPLS-TP data plane) did not > define any differences between the PW data plane in IP/MPLS and > MPLS-TP. > > 2. One of the most popular scenarios for using multi-segment > pseudowires is the case when an edge-to-edge service emulation > crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, > the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware > T-PE at the edge of an IP/MPLS domain) would potentially compete > with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, > e.g., for relying a PW status message that it has received over a > Targeted LDP session from the IP/MPLS domain to a static PW status > message to cross the MPLS-TP domain) for the bottom-of-stack > position. > > > > The issue I am raising Is not new. It has been actively discussed > on the PWE3 mailing list with regard to adoption of > draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for > both the flow label and GAL taking the bottom-of-the-stack > position. But, to the best of my understanding, consensus on this > issue has not been reached. > > > > Hopefully this comment will be useful. > > > > 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. > > 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. > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From gregimirsky@gmail.com Wed Aug 17 19:40: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 02D3221F85A1; Wed, 17 Aug 2011 19:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQdc5eX0ELIm; Wed, 17 Aug 2011 19:40:10 -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 CBF2521F8581; Wed, 17 Aug 2011 19:40:09 -0700 (PDT) Received: by vxi29 with SMTP id 29so1685572vxi.31 for ; Wed, 17 Aug 2011 19:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NQFPDZpyO+gnIX1agm181eoqzhsM8PhV9f5UEOFwmQw=; b=tF8L7EeFyA+iTkqSvEmMsWZW9B5ByGmHRrT8nDOpLQJHw7oueBOYvcNVRrgZoNrNPx jThk7grhDsWg/dPnQ36N25UxPSn94/CZ5D9eY4AO/e/DFii/j/gs++qjRRCZ1jeDinrN 1tRqjq7iQxanExgkv1IwKTK7nFNxZ6LiNCB7o= MIME-Version: 1.0 Received: by 10.52.66.15 with SMTP id b15mr150128vdt.425.1313635260234; Wed, 17 Aug 2011 19:41:00 -0700 (PDT) Received: by 10.52.167.229 with HTTP; Wed, 17 Aug 2011 19:41:00 -0700 (PDT) In-Reply-To: <4E4C0F3F.8010700@cisco.com> References: <4E4C0F3F.8010700@cisco.com> Date: Wed, 17 Aug 2011 19:41:00 -0700 Message-ID: From: Greg Mirsky To: Luca Martini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 18 Aug 2011 02:40:11 -0000 Dear Luca, I'm thinking of other ways of wording, interpreting your formula. Can it be put as "MPLS-TP MS-PW SHOULD not use IP/MPLS ECMP domain"? Regards, Greg On Wed, Aug 17, 2011 at 11:58 AM, Luca Martini wrote: > The solution is quite simple: > > "Flow Labels MUST not be used in an MPLS-TP environment." > > Luca > > > > > > On 08/16/11 21:46, Alexander Vainshtein wrote: >> Pablo, >> Sorry, but I think you're wrong. Only T-PE can insert the flow label >> (because only T=3DPE can be "flow-aware"). S-PE simply performs swap on >> PW label. >> >> Regards, >> =A0 =A0 =A0Sasha >> >> ------------------------------------------------------------------------ >> *From:* Pablo Frank [pabloisnot@gmail.com] >> *Sent:* Wednesday, August 17, 2011 12:17 AM >> *To:* Alexander Vainshtein >> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; >> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-p= w >> >> I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS >> domain in the middle segment, you're no longer in an MPLS-TP >> environment and so the GAL is not required to be BOS. =A0During that >> middle segment, the PW flow label would be placed below the GAL and >> above the GACh. =A0It gets removed when it hits the S-PE that switches >> you back into the MPLS-TP environment. =A0In other words, whether you're >> in an MPLS-TP environment is determined segment by segment in a MS-PW. >> >> Pablo >> >> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein >> > > wrote: >> >> =A0 =A0 Hi all, >> =A0 =A0 After having sent out my comments I've noticed that the specific >> =A0 =A0 example to illustrate the need to combine GAL and "flow label" w= as >> =A0 =A0 inaccurate. >> >> =A0 =A0 A more relevant example would look like following (I do not >> =A0 =A0 include a diagram, but it can be easily provided if necessary) >> >> =A0 =A0 =A01. A MS-PW: >> =A0 =A0 =A0 =A0 =A0 * Starts at an S-PE that resides at the edge of an M= PLS-TP >> =A0 =A0 =A0 =A0 =A0 =A0 domain (no ECMP) >> =A0 =A0 =A0 =A0 =A0 * Crosses this domain and enters an IP/MPLS domain w= ith ECMP >> =A0 =A0 =A0 =A0 =A0 =A0 enabled using a T-PE that resides at the age of = these two >> =A0 =A0 =A0 =A0 =A0 =A0 domains >> =A0 =A0 =A0 =A0 =A0 * Leaves this domain and enters a 2nd MPLS-TP domain= (using >> =A0 =A0 =A0 =A0 =A0 =A0 the 2nd T-PE) >> =A0 =A0 =A0 =A0 =A0 * Terminates on another S-PE at the edge of the 2nd = MPLS-TP >> =A0 =A0 =A0 =A0 =A0 =A0 domain >> =A0 =A0 =A02. The operator intends to improve traffic distribution in th= e >> =A0 =A0 =A0 =A0 IP/MPLS domain, hence he enables insertion and discard o= f >> =A0 =A0 =A0 =A0 "flow labels" at the two S-PEs. Note that: >> =A0 =A0 =A0 =A0 =A0 * This does not violate the MPLS-TP restriction on E= CMP: >> =A0 =A0 =A0 =A0 =A0 =A0 ECMP does not happen in he MPLS-TP domains >> =A0 =A0 =A0 =A0 =A0 * T-PEs do not even have to be aware of flow labels >> =A0 =A0 =A03. The operator also intends to operate some end-to-end OAM f= or >> =A0 =A0 =A0 =A0 this MS-PW using "GAL-in-PW". This results in a conflict= since >> =A0 =A0 =A0 =A0 both GAL and "flow label" are defined (in the correspond= ing >> =A0 =A0 =A0 =A0 drafts) as bottom of stack. >> >> >> >> =A0 =A0 IMHO this describes a realistic scenario where the two drafts ar= e >> =A0 =A0 in controversy. >> >> =A0 =A0 Regards, >> =A0 =A0 =A0 =A0 =A0Sasha >> =A0 =A0 ----------------------------------------------------------------= -------- >> =A0 =A0 *From:* mpls-bounces@ietf.org >> =A0 =A0 [mpls-bounces@ietf.org ] On Behalf >> =A0 =A0 Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com >> =A0 =A0 ] >> =A0 =A0 *Sent:* Tuesday, August 16, 2011 4:26 PM >> =A0 =A0 *To:* ietf@ietf.org >> =A0 =A0 *Cc:* mpls@ietf.org ; Vladimir Kleiner; Id= an >> =A0 =A0 Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohe= n >> =A0 =A0 *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-= in-pw >> >> =A0 =A0 Hi all, >> >> >> >> =A0 =A0 I would like to raise the following issue with regard to >> =A0 =A0 draft-ietf-pwe3-gal-in-pw >> =A0 =A0 : >> =A0 =A0 controversy vs. draft-ietf-pwe3-fat-pw >> =A0 =A0 >> =A0 =A0 with regard to bottom-of-stack position. >> >> >> >> =A0 =A0 As stated in the Introduction, this draft removes the restrictio= n >> =A0 =A0 imposed by RFC 5586 on usage of Generic Associated Channel Label >> =A0 =A0 (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 sta= tes: >> >> =A0 =A0 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs= , >> =A0 =A0 Concatenated Segments of LSPs, and with Sections, and MUST NOT b= e >> =A0 =A0 used with PWs. =A0It MUST always be at the bottom of the label s= tack >> =A0 =A0 =A0 =A0(i.e., S bit set to 1). >> >> >> >> =A0 =A0 draft-ietf-pwe3-gal-in-pw proposed to replace the original text = in >> =A0 =A0 RFC 5586 with the following >> >> >> >> =A0 =A0 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs= , >> =A0 =A0 Concatenated Segments of LSPs, and with Sections, and MAY be use= d >> =A0 =A0 with PWs. It MUST always be at the bottom of the label stack >> =A0 =A0 (i.e., S bit set to 1). >> >> >> >> =A0 =A0 I.e., =A0while removing this restriction of 5586, it does not mo= dify >> =A0 =A0 its requirement for the GAL being always at the bottom of the >> =A0 =A0 label stack. >> >> >> >> =A0 =A0 At the same draft-ietf-pwe3-fat-pw (currently also in the IESG >> =A0 =A0 review) reserves the bottom of the PW stack for the PW flow >> =A0 =A0 labels, e.g., in Section 1.1: >> >> >> >> =A0 =A0 This document describes a method of adding an additional label >> =A0 =A0 stack entry (LSE) at the bottom of stack in order to facilitate >> =A0 =A0 the load balancing of the flows within a PW over the available >> =A0 =A0 ECMPs. >> >> >> >> =A0 =A0 One could argue that draft-ietf-pwe3-gal-in-pw only applies to >> =A0 =A0 MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO an= d >> =A0 =A0 FWIW, >> >> =A0 =A0 such an argument, were it presented, would be highly problematic= , >> =A0 =A0 because: >> >> >> >> =A0 =A0 1. =A0 =A0 =A0 RFC 5960 (which defines the MPLS-TP data plane) d= id not >> =A0 =A0 define any differences between the PW data plane in IP/MPLS and >> =A0 =A0 MPLS-TP. >> >> =A0 =A0 2. =A0 =A0 =A0 One of the most popular scenarios for using multi= -segment >> =A0 =A0 pseudowires is the case when an edge-to-edge service emulation >> =A0 =A0 crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios= , >> =A0 =A0 the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-awa= re >> =A0 =A0 T-PE at the edge of an IP/MPLS domain) would potentially compete >> =A0 =A0 with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, >> =A0 =A0 e.g., for relying a PW status message that it has received over = a >> =A0 =A0 Targeted LDP session from the IP/MPLS domain to a static PW stat= us >> =A0 =A0 message to cross the MPLS-TP domain) for the bottom-of-stack >> =A0 =A0 position. >> >> >> >> =A0 =A0 The issue I am raising Is not new. It has been actively discusse= d >> =A0 =A0 on the PWE3 mailing list with regard to adoption of >> =A0 =A0 draft-nadeau-pwe3-vccv-2 as a WG document, with arguments =A0for >> =A0 =A0 both the flow label and GAL taking the bottom-of-the-stack >> =A0 =A0 position. But, to the best of my understanding, consensus on thi= s >> =A0 =A0 issue has not been reached. >> >> >> >> =A0 =A0 Hopefully this comment will be useful. >> >> >> >> =A0 =A0 Regards, >> >> =A0 =A0 =A0 =A0 =A0Sasha >> >> >> >> =A0 =A0 This e-mail message is intended for the recipient only and >> =A0 =A0 contains information which is CONFIDENTIAL and which may be >> =A0 =A0 proprietary to ECI Telecom. If you have received this transmissi= on >> =A0 =A0 in error, please inform us by e-mail, phone or fax, and then >> =A0 =A0 delete the original and all copies thereof. >> >> =A0 =A0 This e-mail message is intended for the recipient only and >> =A0 =A0 contains information which is CONFIDENTIAL and which may be >> =A0 =A0 proprietary to ECI Telecom. If you have received this transmissi= on >> =A0 =A0 in error, please inform us by e-mail, phone or fax, and then >> =A0 =A0 delete the original and all copies thereof. >> >> >> =A0 =A0 _______________________________________________ >> =A0 =A0 pwe3 mailing list >> =A0 =A0 pwe3@ietf.org >> =A0 =A0 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. >> >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From Alexander.Vainshtein@ecitele.com Wed Aug 17 21:58: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 0EDF611E8087 for ; Wed, 17 Aug 2011 21:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=1.098, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzrOU8-g2svE for ; Wed, 17 Aug 2011 21:58:19 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 29DE121F854E for ; Wed, 17 Aug 2011 21:58:19 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1313643122!34996405!3 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.3.6; banners=-,-,- Received: (qmail 6523 invoked from network); 18 Aug 2011 04:52:13 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-6.tower-21.messagelabs.com with SMTP; 18 Aug 2011 04:52:13 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-ae-4e4c93c6d087 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 05.71.16719.6C39C4E4; Thu, 18 Aug 2011 07:23:35 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 18 Aug 2011 07:52:27 +0300 From: Alexander Vainshtein To: Luca Martini Date: Thu, 18 Aug 2011 07:52:19 +0300 Thread-Topic: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxdD9cSGREkAFVzQWqJ2mkm3HQMwQATb/YR Message-ID: References: , , <4E4C0F3F.8010700@cisco.com> In-Reply-To: <4E4C0F3F.8010700@cisco.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: H4sIAAAAAAAAA2VTf2wMWRy/NzO7O12dy7NV+7pB5saPpGrZKjLCivQfK9oqFeQSrbH7bnfY nVk7U7EIzUkIEkqpdJH6US31K3qSotxRqWodLjmSqtY/mlaXiNSPUrRmzOn1cu+vz3ufz+f7 ee/l+6VJW7/ZQYuSiiOSEOTMVqok3vPWeackK8dVfS2V77xYTvFdbV8sfOvJ0yb+4ItGM7+7 5xI11+TZ/+miyXMl1m7xVFR8JHLJn4vAbEGSZFVQMevDitfN5UbEdYI3yrGiz82lc2w4KHhx CEuqmxPCYSz5uDlW9n9rtiYTJRZLXtknSn43Nz9voZPnp890pnNzJoxNz5hlXRIQFRY7Q4IY ZENYUQQ/ZrWTlZfIQM+dYkv4+LL1R473morA48ydIIFGcBr6o/OeycAj0V9PL5h3Aittg3UA 1TZ8tBibUoAa2+NAV5mhG9WcaTfreAQcj87f+gR0EQn7CdS59W9CJyiNKK16adFxEpyH9lSe AobBg8pONFkMPBWVHDpH6piBi9C76gOUjm3wNoFeN2TrOAGmoru3Gr9pgHa93uaz3+qT0I5a O8oJ49oQVVx7QBo4GXU/6zcZ+mTUtv0CMPST0NG6HrOB01DlsRf/5A5HTWUdlOFNQTdPtVDF wB4bEhEbYo8NsceG2I8CqhqkiMGwuirkd011yoXqZOwVVRzEk71yqAYY3fP8MnjyZ2o9gDTg EpmWrgU5NpOwTomG6kEKTXDJTG9ZVo7tx1WyLxoQlEBBpDCIlXqAaJIbwWxjNY7xCdENOCJ/ p3jtp/eSjmFeWetTSS3IcLn+s+HszC7vy2wb9GuttwbjMI58t46iaQ4x1/XE4RHsx+t/EYPq vzRBJ+jJiVryDV3DKGEhpIh+g28GTnpHx93bwEZJsoQddgbGNBHURYFCabCOPjZbBgYG4sCu vTmJ6dNLJWpDNVgproUQWkjrVY8eoo3IIOUoAqdrPxfk5f20MWNf4Per3bubnvQvG7O8qvic u/T66vtvZvje/rDixqGmV/aRBx5louxMf/6DrDF1v1XGub4Vexf35eZvTmLH5U8c3bLlsZWo +bV1XHPt8ykQPnRE1276kGbnq13lKxvb9ueljeoeu2epq2JRsmOKueFwF6HIhVU13e/zOUoJ COkTyYgifAVO/Ut1EQQAAA== Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 18 Aug 2011 04:58:20 -0000 Luca and all, I have not found the statement you've proposed in draft-ietf-pwe3-fat-pw-06.= Instead, it contans the following text in Section 8.5 " Applicability to MP= LS-TP": The flow aware transport of a PW reorders packets, therefore MUST NOT be deployed in a network conforming to the MPLS-TP unless these integrity re= quirements specified in the SLA can be satisfied. (In the -07 version this text is repeated but followed by an incomplete stat= ement " In a" immediately followed by the heading of Section 8.6. Since this= addition is difficult to parse, I will ignore it for the moment.) IMHO and FWIW this means that prohibition on using flow aware PW in MPLS-TP= environments is conditional on meeting specific SLA requirements for the se= rvice. So I think that the use case I've presented still holds. Please note also that, regardless of the restriction in draft-ietf-pwe3-fat-= pw, be it conditional or absolute, usage of flow labels in an MPLS-TP domain= would be perfectly safe if ECMP (i.e., hashing of the label stack and takin= g one of multiple NHLFEs for the given incoming label in the ILM) were not u= sed in this domain, e.g., by associating exactly one ILM entry with each inc= oming label in the ILM. And since MPLS-TP is supposed to carry not just PW c= lients but also IP ones, I would expect that this would be the case in any M= PLS-TP deployment. I also think that releasing one restriction (on using GAL in PWs) at the exp= ense of making another, conditional one (on usage of flow labels in MPLS-TP= environments) absolute is not the most appropriate method for resolving tec= hnical issues. IMHO and FWIW better way to resolve the problem would be by: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a pa= cket then G-ACh header MUST be present immediately after the bottom of the l= abel stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels. I think that these considerations have been presented already in the discuss= ion on draft-nadeau-pwe-vccv-2. Of course it would be even better if we could agree on transition to univers= al usage of the CW and VCCV Type 1 in PWs. But this is a different story. Regards, Sasha ____________________________________ From: Luca Martini [lmartini@cisco.com] Sent: Wednesday, August 17, 2011 9:58 PM To: Alexander Vainshtein Cc: Pablo Frank; mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit= ; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw The solution is quite simple: "Flow Labels MUST not be used in an MPLS-TP environment." Luca On 08/16/11 21:46, Alexander Vainshtein wrote: > Pablo, > Sorry, but I think you're wrong. Only T-PE can insert the flow label > (because only T=3DPE can be "flow-aware"). S-PE simply performs swap on > PW label. > > Regards, > Sasha > > ------------------------------------------------------------------------ > *From:* Pablo Frank [pabloisnot@gmail.com] > *Sent:* Wednesday, August 17, 2011 12:17 AM > *To:* Alexander Vainshtein > *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS > domain in the middle segment, you're no longer in an MPLS-TP > environment and so the GAL is not required to be BOS. During that > middle segment, the PW flow label would be placed below the GAL and > above the GACh. It gets removed when it hits the S-PE that switches > you back into the MPLS-TP environment. In other words, whether you're > in an MPLS-TP environment is determined segment by segment in a MS-PW. > > Pablo > > On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > > wrote: > > Hi all, > After having sent out my comments I've noticed that the specific > example to illustrate the need to combine GAL and "flow label" was > inaccurate. > > A more relevant example would look like following (I do not > include a diagram, but it can be easily provided if necessary) > > 1. A MS-PW: > * Starts at an S-PE that resides at the edge of an MPLS-TP > domain (no ECMP) > * Crosses this domain and enters an IP/MPLS domain with ECMP > enabled using a T-PE that resides at the age of these two > domains > * Leaves this domain and enters a 2nd MPLS-TP domain (using > the 2nd T-PE) > * Terminates on another S-PE at the edge of the 2nd MPLS-TP > domain > 2. The operator intends to improve traffic distribution in the > IP/MPLS domain, hence he enables insertion and discard of > "flow labels" at the two S-PEs. Note that: > * This does not violate the MPLS-TP restriction on ECMP: > ECMP does not happen in he MPLS-TP domains > * T-PEs do not even have to be aware of flow labels > 3. The operator also intends to operate some end-to-end OAM for > this MS-PW using "GAL-in-PW". This results in a conflict since > both GAL and "flow label" are defined (in the corresponding > drafts) as bottom of stack. > > > > IMHO this describes a realistic scenario where the two drafts are > in controversy. > > Regards, > Sasha > ----------------------------------------------------------------------= -- > *From:* mpls-bounces@ietf.org > [mpls-bounces@ietf.org ] On Behalf > Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com > ] > *Sent:* Tuesday, August 16, 2011 4:26 PM > *To:* ietf@ietf.org > *Cc:* mpls@ietf.org ; Vladimir Kleiner; Idan > Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw > > Hi all, > > > > I would like to raise the following issue with regard to > draft-ietf-pwe3-gal-in-pw > : > controversy vs. draft-ietf-pwe3-fat-pw > > with regard to bottom-of-stack position. > > > > As stated in the Introduction, this draft removes the restriction > imposed by RFC 5586 on usage of Generic Associated Channel Label > (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states: > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MUST NOT be > used with PWs. It MUST always be at the bottom of the label stack > (i.e., S bit set to 1). > > > > draft-ietf-pwe3-gal-in-pw proposed to replace the original text in > RFC 5586 with the following > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > Concatenated Segments of LSPs, and with Sections, and MAY be used > with PWs. It MUST always be at the bottom of the label stack > (i.e., S bit set to 1). > > > > I.e., while removing this restriction of 5586, it does not modify > its requirement for the GAL being always at the bottom of the > label stack. > > > > At the same draft-ietf-pwe3-fat-pw (currently also in the IESG > review) reserves the bottom of the PW stack for the PW flow > labels, e.g., in Section 1.1: > > > > This document describes a method of adding an additional label > stack entry (LSE) at the bottom of stack in order to facilitate > the load balancing of the flows within a PW over the available > ECMPs. > > > > One could argue that draft-ietf-pwe3-gal-in-pw only applies to > MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and > FWIW, > > such an argument, were it presented, would be highly problematic, > because: > > > > 1. RFC 5960 (which defines the MPLS-TP data plane) did not > define any differences between the PW data plane in IP/MPLS and > MPLS-TP. > > 2. One of the most popular scenarios for using multi-segment > pseudowires is the case when an edge-to-edge service emulation > crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, > the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware > T-PE at the edge of an IP/MPLS domain) would potentially compete > with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, > e.g., for relying a PW status message that it has received over a > Targeted LDP session from the IP/MPLS domain to a static PW status > message to cross the MPLS-TP domain) for the bottom-of-stack > position. > > > > The issue I am raising Is not new. It has been actively discussed > on the PWE3 mailing list with regard to adoption of > draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for > both the flow label and GAL taking the bottom-of-the-stack > position. But, to the best of my understanding, consensus on this > issue has not been reached. > > > > Hopefully this comment will be useful. > > > > 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. > > 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. > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf 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 Wed Aug 17 22:10: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 A85F711E808F for ; Wed, 17 Aug 2011 22:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.605 X-Spam-Level: X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP8BOa08cV1X for ; Wed, 17 Aug 2011 22:10:48 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id D01B921F85B9 for ; Wed, 17 Aug 2011 22:10:47 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1313644298!28317763!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [147.234.242.235] Received: (qmail 27222 invoked from network); 18 Aug 2011 05:11:38 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-7.tower-174.messagelabs.com with SMTP; 18 Aug 2011 05:11:38 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-93-4e4c9844a0e9 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 4C.B1.16719.4489C4E4; Thu, 18 Aug 2011 07:42:44 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 18 Aug 2011 08:11:37 +0300 From: Alexander Vainshtein To: Greg Mirsky Date: Thu, 18 Aug 2011 08:11:36 +0300 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxdUEbUL4P0Pmq6TLKJzbICnDH3tAAE7vYH Message-ID: References: <4E4C0F3F.8010700@cisco.com>, 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: H4sIAAAAAAAAA2VTW0zTUBj2rN0oSLUMcQfipanxbs1A0KkMkfgAXtgU44M+aNmOW+PWLWtB ZkwkGjXiBRU1Mm9oJvEWUeMFQaOSqBE0Eh8UETXRqYC3hBhhCM6WKmLs09f/+77/O+fk/wlM 36lLInhBQj6BczG6GLysveMbO+/gwlxjpCXe9P3AO63pQ0tvlKn55GmtaVfHZTwTz97346I2 +3rgZVR2MBjWWLHlxSCdEwSPxEmItiPRZmasPr6Qs/kZmrebmWSG9ro4G3IjQTIznNeLBDuT EUP/96XLMl6gkWDz2HnBYWZy8iysyZQ2k01mMsaNSZ42O2apkxdpxLo53kW7kShyDkTLlVWX MWfnrUxviaWo5XgEFIO76SUgmoBUKtz16SOu4uGw8VWVrgTEEHqqFsBwzxGdQuipAwB23UYK 1lFmeOnsy776MGo83Hb1fpRiwKhmDXxb06otAQSBU2Nhfe86RRNPWWFj5Satql8MNze8ASpO geHX5X19SLl+ofoZUIN3YLB7Z0ijENEyUdZ9L0rBQD5dZ/25vjpGGWBz6JhGPTUFgzceYypO gG1vf2pVfQJs2VoFVP0UWFHboVPxZFh5/COmBsfBB+Wh37dPhHdONeG7gSEwICIwwB4YYA8M sFcA/AxI5F1eKd/tMKawngJpKrLxEnKhqTaP+xJQx6a1Grx4OLEOUARgYsmmDwty9VquUPS7 60AioWESyM7yhbn6Ifkeu9/Jic6VvgIXEusAJDBmGLmFljnSzvnXIZ/nD2WSX3oPljTY5pEH VJBWTjMa//lhDOR226dFesohD94ahLzI98c6giAYSEpH5a5xPuRARat5l/SX1hDRSnKsnOxV NKTo5dwi71D5esAS20IN94AeFzwCSjKQOYqIUkTOAqG/j7IvGyKRSDswyHeOJ9MUVay8Tf2d 2uUQjRzSXJOthMgL0k8lFYPCUY0T2/ZXzCHqV52xZt3K0+1YciP+fnjvvtFj77ITUFxTxbMT S3U901OeWhqsTVk7r8ztyqwJbrgwK78uL/weG2Q5/KgazbcEx38lfLW97Iy1PVW53RsRwadO KTVOWp8jLbj2vPx8hv9J1tAvn1/NZENPRiZSN0szDomZy6wrcioZXHRyyZMwn8j9AsvwxAkK BAAA Cc: "mpls@ietf.org" , Vladimir Kleiner , Luca Martini , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 18 Aug 2011 05:10:49 -0000 Dear Greg, I am afraid that your wording would be effectively equivalent to "MPLS-TP SH= OULD NOT be used outside of "walled garden" scenarios. Today the core networks are IP/MPLS and use ECMP at different levels while M= PLS-TP deployments are seem by many as mainly happening in the access/aggreg= ation/metro. If you do not allow an MS-PW to start in the MPLS-TP domain (ac= cess/metro), to cross an IP/MPLS core and then to terminate, say, in another= MPLS-TP domain (access/core), applicability of MPLS-TP would be IMHO greatl= y reduced. Please note also that there is also a draft proposing using of ECMP for both= MPLS and MPLS-TP (draft-villamizar-mpls-tp-multipath-01). Regards, Sasha ________________________________________ From: Greg Mirsky [gregimirsky@gmail.com] Sent: Thursday, August 18, 2011 5:41 AM To: Luca Martini Cc: Alexander Vainshtein; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mish= ael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw Dear Luca, I'm thinking of other ways of wording, interpreting your formula. Can it be put as "MPLS-TP MS-PW SHOULD not use IP/MPLS ECMP domain"? Regards, Greg On Wed, Aug 17, 2011 at 11:58 AM, Luca Martini wrote: > The solution is quite simple: > > "Flow Labels MUST not be used in an MPLS-TP environment." > > Luca > > > > > > On 08/16/11 21:46, Alexander Vainshtein wrote: >> Pablo, >> Sorry, but I think you're wrong. Only T-PE can insert the flow label >> (because only T=3DPE can be "flow-aware"). S-PE simply performs swap on >> PW label. >> >> Regards, >> Sasha >> >> ------------------------------------------------------------------------ >> *From:* Pablo Frank [pabloisnot@gmail.com] >> *Sent:* Wednesday, August 17, 2011 12:17 AM >> *To:* Alexander Vainshtein >> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; >> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw >> >> I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS >> domain in the middle segment, you're no longer in an MPLS-TP >> environment and so the GAL is not required to be BOS. During that >> middle segment, the PW flow label would be placed below the GAL and >> above the GACh. It gets removed when it hits the S-PE that switches >> you back into the MPLS-TP environment. In other words, whether you're >> in an MPLS-TP environment is determined segment by segment in a MS-PW. >> >> Pablo >> >> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein >> > > wrote: >> >> Hi all, >> After having sent out my comments I've noticed that the specific >> example to illustrate the need to combine GAL and "flow label" was >> inaccurate. >> >> A more relevant example would look like following (I do not >> include a diagram, but it can be easily provided if necessary) >> >> 1. A MS-PW: >> * Starts at an S-PE that resides at the edge of an MPLS-TP >> domain (no ECMP) >> * Crosses this domain and enters an IP/MPLS domain with ECMP >> enabled using a T-PE that resides at the age of these two >> domains >> * Leaves this domain and enters a 2nd MPLS-TP domain (using >> the 2nd T-PE) >> * Terminates on another S-PE at the edge of the 2nd MPLS-TP >> domain >> 2. The operator intends to improve traffic distribution in the >> IP/MPLS domain, hence he enables insertion and discard of >> "flow labels" at the two S-PEs. Note that: >> * This does not violate the MPLS-TP restriction on ECMP: >> ECMP does not happen in he MPLS-TP domains >> * T-PEs do not even have to be aware of flow labels >> 3. The operator also intends to operate some end-to-end OAM for >> this MS-PW using "GAL-in-PW". This results in a conflict since >> both GAL and "flow label" are defined (in the corresponding >> drafts) as bottom of stack. >> >> >> >> IMHO this describes a realistic scenario where the two drafts are >> in controversy. >> >> Regards, >> Sasha >> ---------------------------------------------------------------------= --- >> *From:* mpls-bounces@ietf.org >> [mpls-bounces@ietf.org ] On Behalf >> Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com >> ] >> *Sent:* Tuesday, August 16, 2011 4:26 PM >> *To:* ietf@ietf.org >> *Cc:* mpls@ietf.org ; Vladimir Kleiner; Idan >> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >> *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw >> >> Hi all, >> >> >> >> I would like to raise the following issue with regard to >> draft-ietf-pwe3-gal-in-pw >> : >> controversy vs. draft-ietf-pwe3-fat-pw >> >> with regard to bottom-of-stack position. >> >> >> >> As stated in the Introduction, this draft removes the restriction >> imposed by RFC 5586 on usage of Generic Associated Channel Label >> (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states: >> >> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, >> Concatenated Segments of LSPs, and with Sections, and MUST NOT be >> used with PWs. It MUST always be at the bottom of the label stack >> (i.e., S bit set to 1). >> >> >> >> draft-ietf-pwe3-gal-in-pw proposed to replace the original text in >> RFC 5586 with the following >> >> >> >> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, >> Concatenated Segments of LSPs, and with Sections, and MAY be used >> with PWs. It MUST always be at the bottom of the label stack >> (i.e., S bit set to 1). >> >> >> >> I.e., while removing this restriction of 5586, it does not modify >> its requirement for the GAL being always at the bottom of the >> label stack. >> >> >> >> At the same draft-ietf-pwe3-fat-pw (currently also in the IESG >> review) reserves the bottom of the PW stack for the PW flow >> labels, e.g., in Section 1.1: >> >> >> >> This document describes a method of adding an additional label >> stack entry (LSE) at the bottom of stack in order to facilitate >> the load balancing of the flows within a PW over the available >> ECMPs. >> >> >> >> One could argue that draft-ietf-pwe3-gal-in-pw only applies to >> MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and >> FWIW, >> >> such an argument, were it presented, would be highly problematic, >> because: >> >> >> >> 1. RFC 5960 (which defines the MPLS-TP data plane) did not >> define any differences between the PW data plane in IP/MPLS and >> MPLS-TP. >> >> 2. One of the most popular scenarios for using multi-segment >> pseudowires is the case when an edge-to-edge service emulation >> crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, >> the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware >> T-PE at the edge of an IP/MPLS domain) would potentially compete >> with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, >> e.g., for relying a PW status message that it has received over a >> Targeted LDP session from the IP/MPLS domain to a static PW status >> message to cross the MPLS-TP domain) for the bottom-of-stack >> position. >> >> >> >> The issue I am raising Is not new. It has been actively discussed >> on the PWE3 mailing list with regard to adoption of >> draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for >> both the flow label and GAL taking the bottom-of-the-stack >> position. But, to the best of my understanding, consensus on this >> issue has not been reached. >> >> >> >> Hopefully this comment will be useful. >> >> >> >> 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. >> >> 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. >> >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > 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 gregimirsky@gmail.com Wed Aug 17 22:42: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 BC02B21F8593; Wed, 17 Aug 2011 22:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRagjo78v+KF; Wed, 17 Aug 2011 22:42:37 -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 1E7FE21F8581; Wed, 17 Aug 2011 22:42:37 -0700 (PDT) Received: by vxi29 with SMTP id 29so1785114vxi.31 for ; Wed, 17 Aug 2011 22:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zotSvij3FkNZ4ec4HAr+kxQS0j/S/EBdCSb27AaDilQ=; b=xXPQLAoO2U38e9ULwzyGGE5VLhR8RpiyMhDA+oA6KCPAuqvHgq0YP6ft/M3T6QsWVV ruC4nzIVX79D5qv4Vwo9NxGmothuddMsGvhD/MnxrxKhvQdxQJ0tUTmI8b/50DOff8iI wkYyudAyXQm2Ebas8Zv0+YJvlgFzmn70dnjtA= MIME-Version: 1.0 Received: by 10.52.27.3 with SMTP id p3mr311379vdg.224.1313646209899; Wed, 17 Aug 2011 22:43:29 -0700 (PDT) Received: by 10.52.167.229 with HTTP; Wed, 17 Aug 2011 22:43:29 -0700 (PDT) In-Reply-To: References: <4E4C0F3F.8010700@cisco.com> Date: Wed, 17 Aug 2011 22:43:29 -0700 Message-ID: From: Greg Mirsky To: Alexander Vainshtein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Vladimir Kleiner , Luca Martini , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 18 Aug 2011 05:42:38 -0000 Dear Sasha, thank you for your comment as it helps me to understand what are possible ramifications of proposed solution. I should have noted in the first place that I'm not proposing but merely try to interpret, re-word Luca's proposal. And I could have put it as a question "Is an MPLS-TP MS-PW crossing ECMP domain is conforming MPLS-TP construct?" or "What are requirements for control over ECMP domain to conform with MPLS-TP?" Regards, Greg On Wed, Aug 17, 2011 at 10:11 PM, Alexander Vainshtein wrote: > Dear Greg, > I am afraid that your wording would be effectively equivalent to "MPLS-TP= SHOULD NOT be used outside of "walled garden" scenarios. > > Today the core networks are IP/MPLS and use ECMP at different levels whil= e MPLS-TP deployments are seem by many as mainly happening in the access/ag= gregation/metro. If you do not allow an MS-PW to start in the MPLS-TP domai= n (access/metro), to cross an IP/MPLS core and then to terminate, say, in a= nother MPLS-TP domain (access/core), applicability of MPLS-TP would be IMHO= greatly reduced. > > Please note also that there is also a draft proposing using of ECMP for b= oth MPLS and MPLS-TP (draft-villamizar-mpls-tp-multipath-01). > > Regards, > =A0 =A0 Sasha > ________________________________________ > From: Greg Mirsky [gregimirsky@gmail.com] > Sent: Thursday, August 18, 2011 5:41 AM > To: Luca Martini > Cc: Alexander Vainshtein; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; M= ishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-= in-pw > > Dear Luca, > I'm thinking of other ways of wording, interpreting your formula. Can > it be put as "MPLS-TP MS-PW SHOULD not use IP/MPLS ECMP domain"? > > Regards, > Greg > > On Wed, Aug 17, 2011 at 11:58 AM, Luca Martini wrote= : >> The solution is quite simple: >> >> "Flow Labels MUST not be used in an MPLS-TP environment." >> >> Luca >> >> >> >> >> >> On 08/16/11 21:46, Alexander Vainshtein wrote: >>> Pablo, >>> Sorry, but I think you're wrong. Only T-PE can insert the flow label >>> (because only T=3DPE can be "flow-aware"). S-PE simply performs swap on >>> PW label. >>> >>> Regards, >>> =A0 =A0 =A0Sasha >>> >>> -----------------------------------------------------------------------= - >>> *From:* Pablo Frank [pabloisnot@gmail.com] >>> *Sent:* Wednesday, August 17, 2011 12:17 AM >>> *To:* Alexander Vainshtein >>> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; >>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >>> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw >>> >>> I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS >>> domain in the middle segment, you're no longer in an MPLS-TP >>> environment and so the GAL is not required to be BOS. =A0During that >>> middle segment, the PW flow label would be placed below the GAL and >>> above the GACh. =A0It gets removed when it hits the S-PE that switches >>> you back into the MPLS-TP environment. =A0In other words, whether you'r= e >>> in an MPLS-TP environment is determined segment by segment in a MS-PW. >>> >>> Pablo >>> >>> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein >>> >> > wrote: >>> >>> =A0 =A0 Hi all, >>> =A0 =A0 After having sent out my comments I've noticed that the specifi= c >>> =A0 =A0 example to illustrate the need to combine GAL and "flow label" = was >>> =A0 =A0 inaccurate. >>> >>> =A0 =A0 A more relevant example would look like following (I do not >>> =A0 =A0 include a diagram, but it can be easily provided if necessary) >>> >>> =A0 =A0 =A01. A MS-PW: >>> =A0 =A0 =A0 =A0 =A0 * Starts at an S-PE that resides at the edge of an = MPLS-TP >>> =A0 =A0 =A0 =A0 =A0 =A0 domain (no ECMP) >>> =A0 =A0 =A0 =A0 =A0 * Crosses this domain and enters an IP/MPLS domain = with ECMP >>> =A0 =A0 =A0 =A0 =A0 =A0 enabled using a T-PE that resides at the age of= these two >>> =A0 =A0 =A0 =A0 =A0 =A0 domains >>> =A0 =A0 =A0 =A0 =A0 * Leaves this domain and enters a 2nd MPLS-TP domai= n (using >>> =A0 =A0 =A0 =A0 =A0 =A0 the 2nd T-PE) >>> =A0 =A0 =A0 =A0 =A0 * Terminates on another S-PE at the edge of the 2nd= MPLS-TP >>> =A0 =A0 =A0 =A0 =A0 =A0 domain >>> =A0 =A0 =A02. The operator intends to improve traffic distribution in t= he >>> =A0 =A0 =A0 =A0 IP/MPLS domain, hence he enables insertion and discard = of >>> =A0 =A0 =A0 =A0 "flow labels" at the two S-PEs. Note that: >>> =A0 =A0 =A0 =A0 =A0 * This does not violate the MPLS-TP restriction on = ECMP: >>> =A0 =A0 =A0 =A0 =A0 =A0 ECMP does not happen in he MPLS-TP domains >>> =A0 =A0 =A0 =A0 =A0 * T-PEs do not even have to be aware of flow labels >>> =A0 =A0 =A03. The operator also intends to operate some end-to-end OAM = for >>> =A0 =A0 =A0 =A0 this MS-PW using "GAL-in-PW". This results in a conflic= t since >>> =A0 =A0 =A0 =A0 both GAL and "flow label" are defined (in the correspon= ding >>> =A0 =A0 =A0 =A0 drafts) as bottom of stack. >>> >>> >>> >>> =A0 =A0 IMHO this describes a realistic scenario where the two drafts a= re >>> =A0 =A0 in controversy. >>> >>> =A0 =A0 Regards, >>> =A0 =A0 =A0 =A0 =A0Sasha >>> =A0 =A0 ---------------------------------------------------------------= --------- >>> =A0 =A0 *From:* mpls-bounces@ietf.org >>> =A0 =A0 [mpls-bounces@ietf.org ] On Behal= f >>> =A0 =A0 Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com >>> =A0 =A0 ] >>> =A0 =A0 *Sent:* Tuesday, August 16, 2011 4:26 PM >>> =A0 =A0 *To:* ietf@ietf.org >>> =A0 =A0 *Cc:* mpls@ietf.org ; Vladimir Kleiner; I= dan >>> =A0 =A0 Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Coh= en >>> =A0 =A0 *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal= -in-pw >>> >>> =A0 =A0 Hi all, >>> >>> >>> >>> =A0 =A0 I would like to raise the following issue with regard to >>> =A0 =A0 draft-ietf-pwe3-gal-in-pw >>> =A0 =A0 : >>> =A0 =A0 controversy vs. draft-ietf-pwe3-fat-pw >>> =A0 =A0 >>> =A0 =A0 with regard to bottom-of-stack position. >>> >>> >>> >>> =A0 =A0 As stated in the Introduction, this draft removes the restricti= on >>> =A0 =A0 imposed by RFC 5586 on usage of Generic Associated Channel Labe= l >>> =A0 =A0 (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 st= ates: >>> >>> =A0 =A0 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSP= s, >>> =A0 =A0 Concatenated Segments of LSPs, and with Sections, and MUST NOT = be >>> =A0 =A0 used with PWs. =A0It MUST always be at the bottom of the label = stack >>> =A0 =A0 =A0 =A0(i.e., S bit set to 1). >>> >>> >>> >>> =A0 =A0 draft-ietf-pwe3-gal-in-pw proposed to replace the original text= in >>> =A0 =A0 RFC 5586 with the following >>> >>> >>> >>> =A0 =A0 In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSP= s, >>> =A0 =A0 Concatenated Segments of LSPs, and with Sections, and MAY be us= ed >>> =A0 =A0 with PWs. It MUST always be at the bottom of the label stack >>> =A0 =A0 (i.e., S bit set to 1). >>> >>> >>> >>> =A0 =A0 I.e., =A0while removing this restriction of 5586, it does not m= odify >>> =A0 =A0 its requirement for the GAL being always at the bottom of the >>> =A0 =A0 label stack. >>> >>> >>> >>> =A0 =A0 At the same draft-ietf-pwe3-fat-pw (currently also in the IESG >>> =A0 =A0 review) reserves the bottom of the PW stack for the PW flow >>> =A0 =A0 labels, e.g., in Section 1.1: >>> >>> >>> >>> =A0 =A0 This document describes a method of adding an additional label >>> =A0 =A0 stack entry (LSE) at the bottom of stack in order to facilitate >>> =A0 =A0 the load balancing of the flows within a PW over the available >>> =A0 =A0 ECMPs. >>> >>> >>> >>> =A0 =A0 One could argue that draft-ietf-pwe3-gal-in-pw only applies to >>> =A0 =A0 MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO a= nd >>> =A0 =A0 FWIW, >>> >>> =A0 =A0 such an argument, were it presented, would be highly problemati= c, >>> =A0 =A0 because: >>> >>> >>> >>> =A0 =A0 1. =A0 =A0 =A0 RFC 5960 (which defines the MPLS-TP data plane) = did not >>> =A0 =A0 define any differences between the PW data plane in IP/MPLS and >>> =A0 =A0 MPLS-TP. >>> >>> =A0 =A0 2. =A0 =A0 =A0 One of the most popular scenarios for using mult= i-segment >>> =A0 =A0 pseudowires is the case when an edge-to-edge service emulation >>> =A0 =A0 crosses multiple IP/MPLS and MPLS-TP domains. In these scenario= s, >>> =A0 =A0 the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aw= are >>> =A0 =A0 T-PE at the edge of an IP/MPLS domain) would potentially compet= e >>> =A0 =A0 with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, >>> =A0 =A0 e.g., for relying a PW status message that it has received over= a >>> =A0 =A0 Targeted LDP session from the IP/MPLS domain to a static PW sta= tus >>> =A0 =A0 message to cross the MPLS-TP domain) for the bottom-of-stack >>> =A0 =A0 position. >>> >>> >>> >>> =A0 =A0 The issue I am raising Is not new. It has been actively discuss= ed >>> =A0 =A0 on the PWE3 mailing list with regard to adoption of >>> =A0 =A0 draft-nadeau-pwe3-vccv-2 as a WG document, with arguments =A0fo= r >>> =A0 =A0 both the flow label and GAL taking the bottom-of-the-stack >>> =A0 =A0 position. But, to the best of my understanding, consensus on th= is >>> =A0 =A0 issue has not been reached. >>> >>> >>> >>> =A0 =A0 Hopefully this comment will be useful. >>> >>> >>> >>> =A0 =A0 Regards, >>> >>> =A0 =A0 =A0 =A0 =A0Sasha >>> >>> >>> >>> =A0 =A0 This e-mail message is intended for the recipient only and >>> =A0 =A0 contains information which is CONFIDENTIAL and which may be >>> =A0 =A0 proprietary to ECI Telecom. If you have received this transmiss= ion >>> =A0 =A0 in error, please inform us by e-mail, phone or fax, and then >>> =A0 =A0 delete the original and all copies thereof. >>> >>> =A0 =A0 This e-mail message is intended for the recipient only and >>> =A0 =A0 contains information which is CONFIDENTIAL and which may be >>> =A0 =A0 proprietary to ECI Telecom. If you have received this transmiss= ion >>> =A0 =A0 in error, please inform us by e-mail, phone or fax, and then >>> =A0 =A0 delete the original and all copies thereof. >>> >>> >>> =A0 =A0 _______________________________________________ >>> =A0 =A0 pwe3 mailing list >>> =A0 =A0 pwe3@ietf.org >>> =A0 =A0 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. >>> >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >> >> _______________________________________________ >> 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 infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f 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 neil.2.harrison@bt.com Thu Aug 18 01:03: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 85AA821F86C3; Thu, 18 Aug 2011 01:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[AWL=-2.266, BAYES_00=-2.599, GB_SUMOF=5, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T91dRL8HiCz; Thu, 18 Aug 2011 01:03:56 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7675B21F85DA; Thu, 18 Aug 2011 01:03:55 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 18 Aug 2011 09:04:47 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 18 Aug 2011 09:04:47 +0100 From: To: , Date: Thu, 18 Aug 2011 09:04:42 +0100 Thread-Topic: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxdaccDd6p6WxJWQPeR1xCjDJBG1AAELHkw Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E4405EDDFCB8@EMV62-UKRD.domain1.systemhost.net> References: <4E4C0F3F.8010700@cisco.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, Vladimir.Kleiner@ecitele.com, lmartini@cisco.com, Idan.Kaspit@ecitele.com, Mishael.Wexler@ecitele.com, pwe3@ietf.org, Oren.Gal@ecitele.com, John.Shirron@ecitele.com, Rotem.Cohen@ecitele.com Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 18 Aug 2011 08:03:57 -0000 Greg, This may help you answer your own question: A layer network at level N is composed of layer N nodes and layer N links. = The layer N links are provided by layer N-1 E2E paths....recurse to the du= ct. This has the following ramifications: 1 The disjoint connectivity of any layer network M cannot be greater = than that of the duct graph....in practice this means a disjoint connectivi= ty of >3 is practically difficult with BOS guided EM wave networks based on= metallic or optical media. Aside=3D> Going 3-dim can improve this, eg use= a radio BOS section layer. 2 The performance enjoyed by a layer N network is (to a good 1st ~) t= he sum of the impairments introduced by the layer N nodes and those inherit= ed by the layer N links from their server E2E layer N-1 path...recurse to t= he duct. Now given the critical service a transport network provides to its clients = is transparency (of the carriage of client symbols) then this requires cont= rol over all inherited impairments down the stack of nested layer networks = to the duct. It immediately follows that one must have resource determinis= m of *each and every* layer network to the duct if one wishes to control re= source impairments caused by traffic load (in nodes). This is a given without any action when dealing with layer networks based o= n the space resource partition, or a co-cs time resource partition since th= is is based on regular and fixed-duration time-slices. One can get close t= o approximating this behaviour in the co-ps mode, which is usually based on= irregular time-slices of variable-duration, providing one respects the 2 r= equirements of: - using proper single source connection constructs and - not overbooking resource One clearly cannot provide the required behaviour over a cl-ps server layer= or a some approximation of the co-ps mode that does not meet the above req= uirements, eg MPLS LDP is like this as its constructs are not single source= ....ECMP just complicates/exacerbates matters. I now think the answer to your question Greg is obvious. regards, Neil This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Greg Mirsky > Sent: 18 August 2011 06:43 > To: Alexander Vainshtein > Cc: mpls@ietf.org; Vladimir Kleiner; Luca Martini; Idan Kaspit; Mishael > Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3- > gal-in-pw > > Dear Sasha, > thank you for your comment as it helps me to understand what are > possible ramifications of proposed solution. > I should have noted in the first place that I'm not proposing but > merely try to interpret, re-word Luca's proposal. > And I could have put it as a question "Is an MPLS-TP MS-PW crossing > ECMP domain is conforming MPLS-TP construct?" or "What are > requirements for control over ECMP domain to conform with MPLS-TP?" > > Regards, > Greg > > On Wed, Aug 17, 2011 at 10:11 PM, Alexander Vainshtein > wrote: > > Dear Greg, > > I am afraid that your wording would be effectively equivalent to > "MPLS-TP SHOULD NOT be used outside of "walled garden" scenarios. > > > > Today the core networks are IP/MPLS and use ECMP at different levels > while MPLS-TP deployments are seem by many as mainly happening in the > access/aggregation/metro. If you do not allow an MS-PW to start in the > MPLS-TP domain (access/metro), to cross an IP/MPLS core and then to > terminate, say, in another MPLS-TP domain (access/core), applicability > of MPLS-TP would be IMHO greatly reduced. > > > > Please note also that there is also a draft proposing using of ECMP > for both MPLS and MPLS-TP (draft-villamizar-mpls-tp-multipath-01). > > > > Regards, > > Sasha > > ________________________________________ > > From: Greg Mirsky [gregimirsky@gmail.com] > > Sent: Thursday, August 18, 2011 5:41 AM > > To: Luca Martini > > Cc: Alexander Vainshtein; mpls@ietf.org; Vladimir Kleiner; Idan > Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > > Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- > gal-in-pw > > > > Dear Luca, > > I'm thinking of other ways of wording, interpreting your formula. Can > > it be put as "MPLS-TP MS-PW SHOULD not use IP/MPLS ECMP domain"? > > > > Regards, > > Greg > > > > On Wed, Aug 17, 2011 at 11:58 AM, Luca Martini > wrote: > >> The solution is quite simple: > >> > >> "Flow Labels MUST not be used in an MPLS-TP environment." > >> > >> Luca > >> > >> > >> > >> > >> > >> On 08/16/11 21:46, Alexander Vainshtein wrote: > >>> Pablo, > >>> Sorry, but I think you're wrong. Only T-PE can insert the flow > label > >>> (because only T=3DPE can be "flow-aware"). S-PE simply performs swap > on > >>> PW label. > >>> > >>> Regards, > >>> Sasha > >>> > >>> ------------------------------------------------------------------- > ----- > >>> *From:* Pablo Frank [pabloisnot@gmail.com] > >>> *Sent:* Wednesday, August 17, 2011 12:17 AM > >>> *To:* Alexander Vainshtein > >>> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > >>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > >>> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3- > gal-in-pw > >>> > >>> I think it's okay because as the PW crosses the ECMP-enabled > IP/MPLS > >>> domain in the middle segment, you're no longer in an MPLS-TP > >>> environment and so the GAL is not required to be BOS. During that > >>> middle segment, the PW flow label would be placed below the GAL and > >>> above the GACh. It gets removed when it hits the S-PE that > switches > >>> you back into the MPLS-TP environment. In other words, whether > you're > >>> in an MPLS-TP environment is determined segment by segment in a MS- > PW. > >>> > >>> Pablo > >>> > >>> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > >>> >>> > wrote: > >>> > >>> Hi all, > >>> After having sent out my comments I've noticed that the > specific > >>> example to illustrate the need to combine GAL and "flow label" > was > >>> inaccurate. > >>> > >>> A more relevant example would look like following (I do not > >>> include a diagram, but it can be easily provided if necessary) > >>> > >>> 1. A MS-PW: > >>> * Starts at an S-PE that resides at the edge of an MPLS- > TP > >>> domain (no ECMP) > >>> * Crosses this domain and enters an IP/MPLS domain with > ECMP > >>> enabled using a T-PE that resides at the age of these > two > >>> domains > >>> * Leaves this domain and enters a 2nd MPLS-TP domain > (using > >>> the 2nd T-PE) > >>> * Terminates on another S-PE at the edge of the 2nd MPLS- > TP > >>> domain > >>> 2. The operator intends to improve traffic distribution in the > >>> IP/MPLS domain, hence he enables insertion and discard of > >>> "flow labels" at the two S-PEs. Note that: > >>> * This does not violate the MPLS-TP restriction on ECMP: > >>> ECMP does not happen in he MPLS-TP domains > >>> * T-PEs do not even have to be aware of flow labels > >>> 3. The operator also intends to operate some end-to-end OAM > for > >>> this MS-PW using "GAL-in-PW". This results in a conflict > since > >>> both GAL and "flow label" are defined (in the corresponding > >>> drafts) as bottom of stack. > >>> > >>> > >>> > >>> IMHO this describes a realistic scenario where the two drafts > are > >>> in controversy. > >>> > >>> Regards, > >>> Sasha > >>> --------------------------------------------------------------- > --------- > >>> *From:* mpls-bounces@ietf.org > >>> [mpls-bounces@ietf.org ] On > Behalf > >>> Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com > >>> ] > >>> *Sent:* Tuesday, August 16, 2011 4:26 PM > >>> *To:* ietf@ietf.org > >>> *Cc:* mpls@ietf.org ; Vladimir Kleiner; > Idan > >>> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem > Cohen > >>> *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3- > gal-in-pw > >>> > >>> Hi all, > >>> > >>> > >>> > >>> I would like to raise the following issue with regard to > >>> draft-ietf-pwe3-gal-in-pw > >>> in-pw/?include_text=3D1>: > >>> controversy vs. draft-ietf-pwe3-fat-pw > >>> pw/?include_text=3D1> > >>> with regard to bottom-of-stack position. > >>> > >>> > >>> > >>> As stated in the Introduction, this draft removes the > restriction > >>> imposed by RFC 5586 on usage of Generic Associated Channel > Label > >>> (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 > states: > >>> > >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > LSPs, > >>> Concatenated Segments of LSPs, and with Sections, and MUST NOT > be > >>> used with PWs. It MUST always be at the bottom of the label > stack > >>> (i.e., S bit set to 1). > >>> > >>> > >>> > >>> draft-ietf-pwe3-gal-in-pw proposed to replace the original text > in > >>> RFC 5586 with the following > >>> > >>> > >>> > >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > LSPs, > >>> Concatenated Segments of LSPs, and with Sections, and MAY be > used > >>> with PWs. It MUST always be at the bottom of the label stack > >>> (i.e., S bit set to 1). > >>> > >>> > >>> > >>> I.e., while removing this restriction of 5586, it does not > modify > >>> its requirement for the GAL being always at the bottom of the > >>> label stack. > >>> > >>> > >>> > >>> At the same draft-ietf-pwe3-fat-pw (currently also in the IESG > >>> review) reserves the bottom of the PW stack for the PW flow > >>> labels, e.g., in Section 1.1: > >>> > >>> > >>> > >>> This document describes a method of adding an additional label > >>> stack entry (LSE) at the bottom of stack in order to facilitate > >>> the load balancing of the flows within a PW over the available > >>> ECMPs. > >>> > >>> > >>> > >>> One could argue that draft-ietf-pwe3-gal-in-pw only applies to > >>> MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO > and > >>> FWIW, > >>> > >>> such an argument, were it presented, would be highly > problematic, > >>> because: > >>> > >>> > >>> > >>> 1. RFC 5960 (which defines the MPLS-TP data plane) did > not > >>> define any differences between the PW data plane in IP/MPLS and > >>> MPLS-TP. > >>> > >>> 2. One of the most popular scenarios for using multi- > segment > >>> pseudowires is the case when an edge-to-edge service emulation > >>> crosses multiple IP/MPLS and MPLS-TP domains. In these > scenarios, > >>> the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow- > aware > >>> T-PE at the edge of an IP/MPLS domain) would potentially > compete > >>> with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, > >>> e.g., for relying a PW status message that it has received over > a > >>> Targeted LDP session from the IP/MPLS domain to a static PW > status > >>> message to cross the MPLS-TP domain) for the bottom-of-stack > >>> position. > >>> > >>> > >>> > >>> The issue I am raising Is not new. It has been actively > discussed > >>> on the PWE3 mailing list with regard to adoption of > >>> draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for > >>> both the flow label and GAL taking the bottom-of-the-stack > >>> position. But, to the best of my understanding, consensus on > this > >>> issue has not been reached. > >>> > >>> > >>> > >>> Hopefully this comment will be useful. > >>> > >>> > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ietf mailing list > >>> Ietf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf > >> > >> _______________________________________________ > >> 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. > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From Alexander.Vainshtein@ecitele.com Thu Aug 18 01:24:36 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 42EE921F8B1A; Thu, 18 Aug 2011 01:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=0.954, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-pib5uaXOgM; Thu, 18 Aug 2011 01:24:33 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 7DD0521F871E; Thu, 18 Aug 2011 01:24:32 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1313655918!45717229!2 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.3.6; banners=-,-,- Received: (qmail 16922 invoked from network); 18 Aug 2011 08:25:19 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-13.tower-21.messagelabs.com with SMTP; 18 Aug 2011 08:25:19 -0000 X-AuditID: 93eaf2e8-b7b3eae00000414f-1b-4e4cc5ac8ae4 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 1C.16.16719.CA5CC4E4; Thu, 18 Aug 2011 10:56:28 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 18 Aug 2011 11:25:22 +0300 From: Alexander Vainshtein To: Greg Mirsky Date: Thu, 18 Aug 2011 11:25:20 +0300 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxdacQkcxIP/TqSSHy5ZuH63SprXgAFMzyw Message-ID: References: <4E4C0F3F.8010700@cisco.com> 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_A3C5DF08D38B6049839A6F553B331C760111EFA0819BILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLsWRmVeSWpSXmKPExsUy+dWnL7prjvr4Gezptrb4Nu0pq8XzO3/Z LW4tXclq0fdpC4sDi8eU3xtZPXbOusvusWTJT6YA5qgGRpvEvLz8ksSSVIWU1OJkW6WAosyy xORKJYXMFFslQyWFgpzE5NTc1LwSW6XEgoLUvBQlOy4FDGADVJaZp5Cal5yfkpmXbqvkGeyv a2FhaqlrqGSnpmxobM0VkpFZrJCqm5uYmaOQm1pcnJieqgAUSdjCnPH/RRdrwacHTBU/dqxi aWCcspKpi5GTQ0LAROLG7PMsELaYxIV769m6GLk4hAR2M0q8/fKECcKZxihx6No0dpAqNgFb iU2r77KB2CIC6hKd246zgxQxC9xikni86wUrSIJFQFWi+eM9sAZhgQCJC8uaWSEaAiVaTz9i hLCNJGZM2cUMYvMCxU88+A+1bS6LRGPDEbD7OIESLbN6wYoYge77fmoNWJxZQFzi1pP5UD8I SCzZc54ZwhaVePn4HytEvajEnfb1QMs4gOrzJe5sdIHYJShxcuYTqJclJQ6uuMEygVFsFpKp sxA6ZiHpgCjRkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxSmbmFJQk5aYbGOnml5bopSZn lqTmpOol5+duYoSkqBc7GG+f0TzEKMDBqMTDe+O5t58Qa2JZcWXuIUZJDiYlUd7nJ3z8hPiS 8lMqMxKLM+KLSnNSiw8xSnAwK4nwPt8DlONNSaysSi3Kh0m5AiNgIrMUd3I+MO3mlcQbGxjg 5iiJ83Ynv/EVEkgHJtDs1NSC1CKYOTIcHEoSvLtPA60QLEpNT61Iy8wpQUgzcXCCnMEDdIYT SA1vcUFibnFmOkT+FKMuR+eT08cYhVjy8vNSpcR5z4MUCYAUZZTmwc0B5av6////v2IUBwaA MO92kCoeYK6Dm/QKaAkT0BKpXWBLgBkJLiXVwBg9MUkqomT5prR9G6VXGe/+t1LZbqHYzXWp D42D6tfel0zZvHL3FwOJZCXGZzlc17O95u6wnlTk+sxB9JfO7Yd6jEr8P78w7je6OdNbaF3Y Ia9rilu8X7OpGS4MOLpk9b5QWzGOX6eavzHISn+XX3D5BWNZavzHJZWrY31/rWmvfb7pk6+K dagSS3FGoqEWc1FxIgC79BsaMgQAAA== Cc: "mpls@ietf.org" , Vladimir Kleiner , Luca Martini , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 18 Aug 2011 08:24:36 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EFA0819BILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Dear Greg, Lots of thanks for a prompt response. I think that the questions you're asking are valid, but the answers are not= trivial. E.g., is a PW an MPLS-TP construct? On one hand, MPLS-TP clearly states that it is. On the other hand, there is= nothing in the PW data plane that differentiates between MPLS-TP and IP/MPL= S environments. And, with MS-PWs, you may (and, most probably, will) have to= deal with constructs that are neither here nor there. (I suspect that the proper scientific term for such a monster is chimera (1b), only it is not imagina= ry:).) Regards, Sasha > -----Original Message----- > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: Thursday, August 18, 2011 8:43 AM > To: Alexander Vainshtein > Cc: mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Or= en > Gal; John Shirron; Rotem Cohen; Luca Martini > Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-i= n-pw > > Dear Sasha, > thank you for your comment as it helps me to understand what are > possible ramifications of proposed solution. > I should have noted in the first place that I'm not proposing but > merely try to interpret, re-word Luca's proposal. > And I could have put it as a question "Is an MPLS-TP MS-PW crossing > ECMP domain is conforming MPLS-TP construct?" or "What are > requirements for control over ECMP domain to conform with MPLS-TP?" > > Regards, > Greg > > On Wed, Aug 17, 2011 at 10:11 PM, Alexander Vainshtein > wrote: > > Dear Greg, > > I am afraid that your wording would be effectively equivalent to "MPLS-T= P > SHOULD NOT be used outside of "walled garden" scenarios. > > > > Today the core networks are IP/MPLS and use ECMP at different levels whi= le > MPLS-TP deployments are seem by many as mainly happening in the > access/aggregation/metro. If you do not allow an MS-PW to start in the MPL= S-TP > domain (access/metro), to cross an IP/MPLS core and then to terminate, say= , in > another MPLS-TP domain (access/core), applicability of MPLS-TP would be IM= HO > greatly reduced. > > > > Please note also that there is also a draft proposing using of ECMP for= both > MPLS and MPLS-TP (draft-villamizar-mpls-tp-multipath-01). > > > > Regards, > > Sasha > > ________________________________________ > > From: Greg Mirsky [gregimirsky@gmail.com] > > Sent: Thursday, August 18, 2011 5:41 AM > > To: Luca Martini > > Cc: Alexander Vainshtein; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > > Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal= -in- > pw > > > > Dear Luca, > > I'm thinking of other ways of wording, interpreting your formula. Can > > it be put as "MPLS-TP MS-PW SHOULD not use IP/MPLS ECMP domain"? > > > > Regards, > > Greg > > > > On Wed, Aug 17, 2011 at 11:58 AM, Luca Martini wrot= e: > >> The solution is quite simple: > >> > >> "Flow Labels MUST not be used in an MPLS-TP environment." > >> > >> Luca > >> > >> > >> > >> > >> > >> On 08/16/11 21:46, Alexander Vainshtein wrote: > >>> Pablo, > >>> Sorry, but I think you're wrong. Only T-PE can insert the flow label > >>> (because only T=3DPE can be "flow-aware"). S-PE simply performs swap o= n > >>> PW label. > >>> > >>> Regards, > >>> Sasha > >>> > >>> ----------------------------------------------------------------------= -- > >>> *From:* Pablo Frank [pabloisnot@gmail.com] > >>> *Sent:* Wednesday, August 17, 2011 12:17 AM > >>> *To:* Alexander Vainshtein > >>> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > >>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > >>> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in= -pw > >>> > >>> I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS > >>> domain in the middle segment, you're no longer in an MPLS-TP > >>> environment and so the GAL is not required to be BOS. During that > >>> middle segment, the PW flow label would be placed below the GAL and > >>> above the GACh. It gets removed when it hits the S-PE that switches > >>> you back into the MPLS-TP environment. In other words, whether you're > >>> in an MPLS-TP environment is determined segment by segment in a MS-PW. > >>> > >>> Pablo > >>> > >>> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > >>> >>> > wrote: > >>> > >>> Hi all, > >>> After having sent out my comments I've noticed that the specific > >>> example to illustrate the need to combine GAL and "flow label" was > >>> inaccurate. > >>> > >>> A more relevant example would look like following (I do not > >>> include a diagram, but it can be easily provided if necessary) > >>> > >>> 1. A MS-PW: > >>> * Starts at an S-PE that resides at the edge of an MPLS-TP > >>> domain (no ECMP) > >>> * Crosses this domain and enters an IP/MPLS domain with ECMP > >>> enabled using a T-PE that resides at the age of these two > >>> domains > >>> * Leaves this domain and enters a 2nd MPLS-TP domain (using > >>> the 2nd T-PE) > >>> * Terminates on another S-PE at the edge of the 2nd MPLS-TP > >>> domain > >>> 2. The operator intends to improve traffic distribution in the > >>> IP/MPLS domain, hence he enables insertion and discard of > >>> "flow labels" at the two S-PEs. Note that: > >>> * This does not violate the MPLS-TP restriction on ECMP: > >>> ECMP does not happen in he MPLS-TP domains > >>> * T-PEs do not even have to be aware of flow labels > >>> 3. The operator also intends to operate some end-to-end OAM for > >>> this MS-PW using "GAL-in-PW". This results in a conflict since > >>> both GAL and "flow label" are defined (in the corresponding > >>> drafts) as bottom of stack. > >>> > >>> > >>> > >>> IMHO this describes a realistic scenario where the two drafts are > >>> in controversy. > >>> > >>> Regards, > >>> Sasha > >>> ------------------------------------------------------------------= ---- > -- > >>> *From:* mpls-bounces@ietf.org > >>> [mpls-bounces@ietf.org ] On Behalf > >>> Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com > >>> ] > >>> *Sent:* Tuesday, August 16, 2011 4:26 PM > >>> *To:* ietf@ietf.org > >>> *Cc:* mpls@ietf.org ; Vladimir Kleiner; Idan > >>> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > >>> *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in= -pw > >>> > >>> Hi all, > >>> > >>> > >>> > >>> I would like to raise the following issue with regard to > >>> draft-ietf-pwe3-gal-in-pw > >>> pw/?include_text=3D1>: > >>> controversy vs. draft-ietf-pwe3-fat-pw > >>> pw/?include_text=3D1> > >>> with regard to bottom-of-stack position. > >>> > >>> > >>> > >>> As stated in the Introduction, this draft removes the restriction > >>> imposed by RFC 5586 on usage of Generic Associated Channel Label > >>> (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 state= s: > >>> > >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > >>> Concatenated Segments of LSPs, and with Sections, and MUST NOT be > >>> used with PWs. It MUST always be at the bottom of the label stack > >>> (i.e., S bit set to 1). > >>> > >>> > >>> > >>> draft-ietf-pwe3-gal-in-pw proposed to replace the original text in > >>> RFC 5586 with the following > >>> > >>> > >>> > >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > >>> Concatenated Segments of LSPs, and with Sections, and MAY be used > >>> with PWs. It MUST always be at the bottom of the label stack > >>> (i.e., S bit set to 1). > >>> > >>> > >>> > >>> I.e., while removing this restriction of 5586, it does not modify > >>> its requirement for the GAL being always at the bottom of the > >>> label stack. > >>> > >>> > >>> > >>> At the same draft-ietf-pwe3-fat-pw (currently also in the IESG > >>> review) reserves the bottom of the PW stack for the PW flow > >>> labels, e.g., in Section 1.1: > >>> > >>> > >>> > >>> This document describes a method of adding an additional label > >>> stack entry (LSE) at the bottom of stack in order to facilitate > >>> the load balancing of the flows within a PW over the available > >>> ECMPs. > >>> > >>> > >>> > >>> One could argue that draft-ietf-pwe3-gal-in-pw only applies to > >>> MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and > >>> FWIW, > >>> > >>> such an argument, were it presented, would be highly problematic, > >>> because: > >>> > >>> > >>> > >>> 1. RFC 5960 (which defines the MPLS-TP data plane) did not > >>> define any differences between the PW data plane in IP/MPLS and > >>> MPLS-TP. > >>> > >>> 2. One of the most popular scenarios for using multi-segment > >>> pseudowires is the case when an edge-to-edge service emulation > >>> crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, > >>> the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware > >>> T-PE at the edge of an IP/MPLS domain) would potentially compete > >>> with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, > >>> e.g., for relying a PW status message that it has received over a > >>> Targeted LDP session from the IP/MPLS domain to a static PW status > >>> message to cross the MPLS-TP domain) for the bottom-of-stack > >>> position. > >>> > >>> > >>> > >>> The issue I am raising Is not new. It has been actively discussed > >>> on the PWE3 mailing list with regard to adoption of > >>> draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for > >>> both the flow label and GAL taking the bottom-of-the-stack > >>> position. But, to the best of my understanding, consensus on this > >>> issue has not been reached. > >>> > >>> > >>> > >>> Hopefully this comment will be useful. > >>> > >>> > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ietf mailing list > >>> Ietf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf > >> > >> _______________________________________________ > >> 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 Tele= com. > If you have received this transmission in error, please inform us by e-mai= l, > 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. --_000_A3C5DF08D38B6049839A6F553B331C760111EFA0819BILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

    Dear Greg,=

    Lots of thanks for a prompt response.=

    I think that the questions you're asking a= re valid, but the answers are not trivial.

     

    E.g., is a PW an MPLS-TP c= onstruct?

    On one hand, MPLS-TP clearly= states that it is. On the other hand, there is nothing in the PW data plane= that differentiates between MPLS-TP and IP/MPLS environments. And, with MS-= PWs, you may (and, most probably, will) have to deal with constructs that ar= e neither here nor there.

    (I suspect t= hat the proper scientific term for such a monster is chimera (1b), only it is not imag= inaryJ.)

     

    Regards,

         Sasha

     

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

    > From: Greg Mirsky= [mailto:gregimirsky@gmail.com]

    > Sent: Thursd= ay, August 18, 2011 8:43 AM

    > To: Alexander Va= inshtein

    > Cc: mpls@ietf.org; Vladimir Kleiner= ; Idan Kaspit; Mishael Wexler; pwe3; Oren

    > Ga= l; John Shirron; Rotem Cohen; Luca Martini

    > S= ubject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-p= w

    >

    > Dear Sash= a,

    > thank you for your comment as it helps me= to understand what are

    > possible ramificatio= ns of proposed solution.

    > I should have noted= in the first place that I'm not proposing but

    &g= t; merely try to interpret, re-word Luca's proposal.

    > And I could have put it as a question "Is an MPLS-TP MS-PW cro= ssing

    > ECMP domain is conforming MPLS-TP cons= truct?" or "What are

    > requirements= for control over ECMP domain to conform with MPLS-TP?"

    >

    > Regards,

    > Greg

    >

    > On Wed, Aug 17, 2011 at 10:11 PM, Alexander Vainshtein

    > <Alexander.Vainshtein@ecitele.com> wrote:

    > > Dear Greg,

    > >= ; I am afraid that your wording would be effectively equivalent to "MPL= S-TP

    > SHOULD NOT be used outside of "wal= led garden" scenarios.

    > >

    > > Today the core networks are IP/MPLS and use ECMP a= t different levels while

    > MPLS-TP deployments= are seem by many as mainly happening in the

    >= access/aggregation/metro. If you do not allow an MS-PW to start in the MPLS= -TP

    > domain (access/metro), to cross an IP/MP= LS core and then to terminate, say, in

    > anoth= er MPLS-TP domain (access/core), applicability of MPLS-TP would be IMHO

    <= p class=3DMsoPlainText>> greatly reduced.

    >= >

    > > Please note also that there is al= so a draft proposing using of ECMP for both

    >= MPLS and MPLS-TP (draft-villamizar-mpls-tp-multipath-01).

    > >

    > > Regards,

    > >     Sasha

    &g= t; > ________________________________________

    = > > From: Greg Mirsky [gregimirsky@gmail.com]

    > > Sent: Thursday, August 18, 2011 5:41 AM

    > > To: Luca Martini

    > > Cc: Alex= ander Vainshtein; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit;

    > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Coh= en

    > > Subject: Re: [mpls] [PWE3] IETF Last= Call comment on draft-ietf-pwe3-gal-in-

    > pw<= /p>

    > >

    > > De= ar Luca,

    > > I'm thinking of other ways of= wording, interpreting your formula. Can

    > >= ; it be put as "MPLS-TP MS-PW SHOULD not use IP/MPLS ECMP domain"?=

    > >

    > > R= egards,

    > > Greg

    > >

    > > On Wed, Aug 17, 2011 at 11:5= 8 AM, Luca Martini <lmartini@cisco.com> wrote:

    > >> The solution is quite simple:

    &= gt; >>

    > >> "Flow Labels MUST= not be used in an MPLS-TP environment."

    >= ; >>

    > >> Luca

    > >>

    > >>

    > >>

    > >>

    > >>

    > >>= On 08/16/11 21:46, Alexander Vainshtein wrote:

    &= gt; >>> Pablo,

    > >>> Sorry,= but I think you're wrong. Only T-PE can insert the flow label

    > >>> (because only T=3DPE can be "flow-awa= re"). S-PE simply performs swap on

    > >= >> PW label.

    > >>>

    > >>> Regards,

    > &= gt;>>      Sasha

    > >&g= t;>

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

    = > >>> *From:* Pablo Frank [pabloisnot@gmail.com]

    > >>> *Sent:* Wednesday, August 17, 2011 12:17 AM

    > >>> *To:* Alexander Vainshtein

    > >>> *Cc:* ietf@ietf.org; mpls@ietf.org;= Vladimir Kleiner; Idan Kaspit;

    > >>>= Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen

    > >>> *Subject:* Re: [PWE3] IETF Last Call comment on= draft-ietf-pwe3-gal-in-pw

    > >>>

    <= p class=3DMsoPlainText>> >>> I think it's okay because as the PW= crosses the ECMP-enabled IP/MPLS

    > >>&g= t; domain in the middle segment, you're no longer in an MPLS-TP

    > >>> environment and so the GAL is not required= to be BOS.  During that

    > >>> m= iddle segment, the PW flow label would be placed below the GAL and

    > >>> above the GACh.  It gets removed wh= en it hits the S-PE that switches

    > >>&g= t; you back into the MPLS-TP environment.  In other words, whether you'= re

    > >>> in an MPLS-TP environment is= determined segment by segment in a MS-PW.

    > &= gt;>>

    > >>> Pablo

    > >>>

    > >>&g= t; On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein

    > >>> <Alexander.Vainshtein@ecitele.com

    > >>> <mailto:Alexander.Vainshtein@ecitele.co= m>> wrote:

    > >>>

    > >>>     Hi all,

    > >>>     After having sent out my comments I've n= oticed that the specific

    > >>>  =   example to illustrate the need to combine GAL and "flow label&q= uot; was

    > >>>     inaccura= te.

    > >>>

    = > >>>     A more relevant example would look like foll= owing (I do not

    > >>>     i= nclude a diagram, but it can be easily provided if necessary)

    > >>>

    > >>>=      1. A MS-PW:

    > >>>= ;           * Starts at an S-PE that resides at the= edge of an MPLS-TP

    > >>>   &nbs= p;         domain (no ECMP)

    &= gt; >>>           * Crosses this domain an= d enters an IP/MPLS domain with ECMP

    > >>= ;>             enabled using a T-PE that re= sides at the age of these two

    > >>> &= nbsp;           domains

    = > >>>           * Leaves this domain an= d enters a 2nd MPLS-TP domain (using

    > >>= ;>             the 2nd T-PE)

    > >>>           * Terminat= es on another S-PE at the edge of the 2nd MPLS-TP

    > >>>             domain

    > >>>      2. The operator int= ends to improve traffic distribution in the

    >= >>>         IP/MPLS domain, hence he enables i= nsertion and discard of

    > >>>  =       "flow labels" at the two S-PEs. Note that:

    > >>>         &nbs= p; * This does not violate the MPLS-TP restriction on ECMP:

    > >>>             ECMP= does not happen in he MPLS-TP domains

    > >&= gt;>           * T-PEs do not even have to be aw= are of flow labels

    > >>>    = ;  3. The operator also intends to operate some end-to-end OAM for

    <= p class=3DMsoPlainText>> >>>         this MS= -PW using "GAL-in-PW". This results in a conflict since

    > >>>         both GAL and= "flow label" are defined (in the corresponding

    > >>>         drafts) as bottom of= stack.

    > >>>

    > >>>

    > >>>

    > >>>     IMHO this describes a real= istic scenario where the two drafts are

    > >= >>     in controversy.

    > >&= gt;>

    > >>>     Regards,<= /p>

    > >>>         &nb= sp;Sasha

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

    > --

    > >>>  =   *From:* mpls-bounces@ietf.org <mailto:mpls-bounces@ietf.org>

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

    > >>>     Of Alexander Vainshtein [Alexander.Vains= htein@ecitele.com

    > >>>    = <mailto:Alexander.Vainshtein@ecitele.com>]

    > >>>     *Sent:* Tuesday, August 16, 2011 4:26 PM

    > >>>     *To:* ietf@ietf.org= <mailto:ietf@ietf.org>

    > >>> &= nbsp;   *Cc:* mpls@ietf.org <mailto:mpls@ietf.org>; Vladimir Klei= ner; Idan

    > >>>     Kaspit;= Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen

    > >>>     *Subject:* [mpls] IETF Last Call c= omment on draft-ietf-pwe3-gal-in-pw

    > >>= >

    > >>>     Hi all,

    <= p class=3DMsoPlainText>> >>>

    > >= ;>>

    > >>>

    > >>>     I would like to raise the following is= sue with regard to

    > >>>    = ; draft-ietf-pwe3-gal-in-pw

    > >>> &nb= sp;   <http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-i= n-

    > pw/?include_text=3D1>:

    > >>>     controversy vs. draft-ietf-pwe3-= fat-pw

    > >>>     <http:/= /datatracker.ietf.org/doc/draft-ietf-pwe3-fat-

    &g= t; pw/?include_text=3D1>

    > >>> &nb= sp;   with regard to bottom-of-stack position.

    > >>>

    > >>>

    > >>>

    > >>&= gt;     As stated in the Introduction, this draft removes the rest= riction

    > >>>     imposed b= y RFC 5586 on usage of Generic Associated Channel Label

    > >>>     (GAL) in PWs. The corresponding text= Section 4.2 of RFC 5586 states:

    > >>>= ;

    > >>>     In MPLS-TP, the= GAL MUST be used with packets on a G-ACh on LSPs,

    > >>>     Concatenated Segments of LSPs, and with Se= ctions, and MUST NOT be

    > >>>  =   used with PWs.  It MUST always be at the bottom of the label st= ack

    > >>>        = (i.e., S bit set to 1).

    > >>>

    > >>>

    > >&g= t;>

    > >>>     draft-ietf= -pwe3-gal-in-pw proposed to replace the original text in

    > >>>     RFC 5586 with the following

    > >>>

    > >>= ;>

    > >>>

    > >>>     In MPLS-TP, the GAL MUST be used with pack= ets on a G-ACh on LSPs,

    > >>>  =   Concatenated Segments of LSPs, and with Sections, and MAY be used

    > >>>     with PWs. It MUST a= lways be at the bottom of the label stack

    > &g= t;>>     (i.e., S bit set to 1).

    = > >>>

    > >>>

    > >>>

    > >>&g= t;     I.e.,  while removing this restriction of 5586, it doe= s not modify

    > >>>     its= requirement for the GAL being always at the bottom of the

    > >>>     label stack.

    > >>>

    > >>>

    > >>>

    > >&g= t;>     At the same draft-ietf-pwe3-fat-pw (currently also in t= he IESG

    > >>>     review) r= eserves the bottom of the PW stack for the PW flow

    > >>>     labels, e.g., in Section 1.1:

    > >>>

    > >>&g= t;

    > >>>

    &= gt; >>>     This document describes a method of adding an= additional label

    > >>>    = stack entry (LSE) at the bottom of stack in order to facilitate

    > >>>     the load balancing of the fl= ows within a PW over the available

    > >>&= gt;     ECMPs.

    > >>>

    > >>>

    > >= >>

    > >>>     One coul= d argue that draft-ietf-pwe3-gal-in-pw only applies to

    > >>>     MPLS-TP pseudowires, and that MPLS-TP= does not use ECMP. IMHO and

    > >>> &n= bsp;   FWIW,

    > >>>

    > >>>     such an argument, were it pr= esented, would be highly problematic,

    > >&g= t;>     because:

    > >>>

    > >>>

    >= >>>

    > >>>     1.=       RFC 5960 (which defines the MPLS-TP data plane) did no= t

    > >>>     define any diff= erences between the PW data plane in IP/MPLS and

    = > >>>     MPLS-TP.

    > >= ;>>

    > >>>     2. &nbs= p;     One of the most popular scenarios for using multi-segment

    > >>>     pseudowires is the= case when an edge-to-edge service emulation

    >= >>>     crosses multiple IP/MPLS and MPLS-TP domains. In= these scenarios,

    > >>>    = the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware

    > >>>     T-PE at the edge of an IP= /MPLS domain) would potentially compete

    > >= >>     with GAL (inserted by a T-PE at the edge of an MPLS-T= P domain,

    > >>>     e.g., f= or relying a PW status message that it has received over a

    > >>>     Targeted LDP session from the IP/M= PLS domain to a static PW status

    > >>>= ;     message to cross the MPLS-TP domain) for the bottom-of-stack=

    > >>>     position.

    > >>>

    > >= >>

    > >>>

    > >>>     The issue I am raising Is not new. It h= as been actively discussed

    > >>> &nbs= p;   on the PWE3 mailing list with regard to adoption of

    > >>>     draft-nadeau-pwe3-vccv-2 as a W= G document, with arguments  for

    > >>= ;>     both the flow label and GAL taking the bottom-of-the-sta= ck

    > >>>     position. But,= to the best of my understanding, consensus on this

    > >>>     issue has not been reached.

    > >>>

    > >>&g= t;

    > >>>

    &= gt; >>>     Hopefully this comment will be useful.

    > >>>

    > >= >>

    > >>>

    > >>>     Regards,

    >= ; >>>

    > >>>     &n= bsp;    Sasha

    > >>>

    > >>>

    > >&g= t;>

    > >>>     This e-mai= l message is intended for the recipient only and

    = > >>>     contains information which is CONFIDENTIAL a= nd which may be

    > >>>     p= roprietary to ECI Telecom. If you have received this transmission

    > >>>     in error, please inform us= by e-mail, phone or fax, and then

    > >>&= gt;     delete the original and all copies thereof.

    > >>>

    > >>>=     This e-mail message is intended for the recipient only and

    > >>>     contains informatio= n which is CONFIDENTIAL and which may be

    > >= ;>>     proprietary to ECI Telecom. If you have received thi= s 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 <mailto:pwe3@ietf.o= rg>

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

    > >>>= ;

    > >>>

    &g= t; >>> This e-mail message is intended for the recipient only and c= ontains

    > >>> information which is CO= NFIDENTIAL and which may be proprietary to ECI

    &g= t; >>> Telecom. If you have received this transmission in error, pl= ease

    > >>> inform us by e-mail, phone= or fax, and then delete the original and

    > &g= t;>> all copies thereof.

    > >>><= /p>

    > >>>

    >= >>>

    > >>> _________________= ______________________________

    > >>>= Ietf mailing list

    > >>> Ietf@ietf.or= g

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

    > >>

    > >> _______________________________________________

    > >> mpls mailing list

    > >> mpls@ietf.org

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

    > >&g= t;

    > >

    > >= 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 rec= eived this transmission in error, please inform us by e-mail,

    > phone or fax, and then delete the original and all copies= thereof.

    > >

    &g= t; >

    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_A3C5DF08D38B6049839A6F553B331C760111EFA0819BILPTMAIL02e_-- From jdrake@juniper.net Thu Aug 18 07:02: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 381BA21F874E; Thu, 18 Aug 2011 07:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmF2cZsHkpEZ; Thu, 18 Aug 2011 07:02:13 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3B70F21F86AC; Thu, 18 Aug 2011 07:02:11 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTk0bj4rsKEUJkaPyBfHbtDM5sNhWP44O@postini.com; Thu, 18 Aug 2011 07:03:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 18 Aug 2011 07:00:16 -0700 From: John E Drake To: Alexander Vainshtein , Luca Martini Date: Thu, 18 Aug 2011 07:00:14 -0700 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxdD9cSGREkAFVzQWqJ2mkm3HQMwQATb/YRABP7P3A= Message-ID: <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> References: , , <4E4C0F3F.8010700@cisco.com> 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 Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 18 Aug 2011 14:02:14 -0000 Sasha, I completely agree with your recommendations: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a p= acket then G-ACh header MUST be present immediately after the bottom of the= label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels Thanks, John Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Wednesday, August 17, 2011 9:52 PM > To: Luca Martini > Cc: mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- > gal-in-pw >=20 > Luca and all, > I have not found the statement you've proposed in draft-ietf-pwe3-fat- > pw-06. Instead, it contans the following text in Section 8.5 " > Applicability to MPLS-TP": >=20 > > The flow aware transport of a PW reorders packets, therefore MUST > NOT be > deployed in a network conforming to the MPLS-TP unless these > integrity requirements > specified in the SLA can be satisfied. > >=20 > (In the -07 version this text is repeated but followed by an incomplete > statement " In a" immediately followed by the heading of Section 8.6. > Since this addition is difficult to parse, I will ignore it for the > moment.) >=20 > IMHO and FWIW this means that prohibition on using flow aware PW in > MPLS-TP environments is conditional on meeting specific SLA > requirements for the service. So I think that the use case I've > presented still holds. >=20 > Please note also that, regardless of the restriction in draft-ietf- > pwe3-fat-pw, be it conditional or absolute, usage of flow labels in an > MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the > label stack and taking one of multiple NHLFEs for the given incoming > label in the ILM) were not used in this domain, e.g., by associating > exactly one ILM entry with each incoming label in the ILM. And since > MPLS-TP is supposed to carry not just PW clients but also IP ones, I > would expect that this would be the case in any MPLS-TP deployment. >=20 > I also think that releasing one restriction (on using GAL in PWs) at > the expense of making another, conditional one (on usage of flow labels > in MPLS-TP environments) absolute is not the most appropriate method > for resolving technical issues. IMHO and FWIW better way to resolve the > problem would be by: >=20 > - releasing the bottom-of-stack requirement on GAL > - making use of the statement in RFC 5586 that if GAL is encountered in > a packet then G-ACh header MUST be present immediately after the bottom > of the label stack (and not immediately after GAL) > - specifying that ECMP on labeled packets MUST ignore reserved labels. >=20 > I think that these considerations have been presented already in the > discussion on draft-nadeau-pwe-vccv-2. >=20 > Of course it would be even better if we could agree on transition to > universal usage of the CW and VCCV Type 1 in PWs. But this is a > different story. >=20 > Regards, > Sasha > ____________________________________ > From: Luca Martini [lmartini@cisco.com] > Sent: Wednesday, August 17, 2011 9:58 PM > To: Alexander Vainshtein > Cc: Pablo Frank; mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan > Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw >=20 > The solution is quite simple: >=20 > "Flow Labels MUST not be used in an MPLS-TP environment." >=20 > Luca >=20 >=20 >=20 >=20 >=20 > On 08/16/11 21:46, Alexander Vainshtein wrote: > > Pablo, > > Sorry, but I think you're wrong. Only T-PE can insert the flow label > > (because only T=3DPE can be "flow-aware"). S-PE simply performs swap on > > PW label. > > > > Regards, > > Sasha > > > > --------------------------------------------------------------------- > --- > > *From:* Pablo Frank [pabloisnot@gmail.com] > > *Sent:* Wednesday, August 17, 2011 12:17 AM > > *To:* Alexander Vainshtein > > *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > > Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > > *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal- > in-pw > > > > I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS > > domain in the middle segment, you're no longer in an MPLS-TP > > environment and so the GAL is not required to be BOS. During that > > middle segment, the PW flow label would be placed below the GAL and > > above the GACh. It gets removed when it hits the S-PE that switches > > you back into the MPLS-TP environment. In other words, whether > you're > > in an MPLS-TP environment is determined segment by segment in a MS- > PW. > > > > Pablo > > > > On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > > > > wrote: > > > > Hi all, > > After having sent out my comments I've noticed that the specific > > example to illustrate the need to combine GAL and "flow label" > was > > inaccurate. > > > > A more relevant example would look like following (I do not > > include a diagram, but it can be easily provided if necessary) > > > > 1. A MS-PW: > > * Starts at an S-PE that resides at the edge of an MPLS-TP > > domain (no ECMP) > > * Crosses this domain and enters an IP/MPLS domain with > ECMP > > enabled using a T-PE that resides at the age of these two > > domains > > * Leaves this domain and enters a 2nd MPLS-TP domain (using > > the 2nd T-PE) > > * Terminates on another S-PE at the edge of the 2nd MPLS-TP > > domain > > 2. The operator intends to improve traffic distribution in the > > IP/MPLS domain, hence he enables insertion and discard of > > "flow labels" at the two S-PEs. Note that: > > * This does not violate the MPLS-TP restriction on ECMP: > > ECMP does not happen in he MPLS-TP domains > > * T-PEs do not even have to be aware of flow labels > > 3. The operator also intends to operate some end-to-end OAM for > > this MS-PW using "GAL-in-PW". This results in a conflict > since > > both GAL and "flow label" are defined (in the corresponding > > drafts) as bottom of stack. > > > > > > > > IMHO this describes a realistic scenario where the two drafts are > > in controversy. > > > > Regards, > > Sasha > > ----------------------------------------------------------------- > ------- > > *From:* mpls-bounces@ietf.org > > [mpls-bounces@ietf.org ] On Behalf > > Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com > > ] > > *Sent:* Tuesday, August 16, 2011 4:26 PM > > *To:* ietf@ietf.org > > *Cc:* mpls@ietf.org ; Vladimir Kleiner; > Idan > > Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > > *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal- > in-pw > > > > Hi all, > > > > > > > > I would like to raise the following issue with regard to > > draft-ietf-pwe3-gal-in-pw > > pw/?include_text=3D1>: > > controversy vs. draft-ietf-pwe3-fat-pw > > pw/?include_text=3D1> > > with regard to bottom-of-stack position. > > > > > > > > As stated in the Introduction, this draft removes the restriction > > imposed by RFC 5586 on usage of Generic Associated Channel Label > > (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 > states: > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > > Concatenated Segments of LSPs, and with Sections, and MUST NOT be > > used with PWs. It MUST always be at the bottom of the label > stack > > (i.e., S bit set to 1). > > > > > > > > draft-ietf-pwe3-gal-in-pw proposed to replace the original text > in > > RFC 5586 with the following > > > > > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, > > Concatenated Segments of LSPs, and with Sections, and MAY be used > > with PWs. It MUST always be at the bottom of the label stack > > (i.e., S bit set to 1). > > > > > > > > I.e., while removing this restriction of 5586, it does not > modify > > its requirement for the GAL being always at the bottom of the > > label stack. > > > > > > > > At the same draft-ietf-pwe3-fat-pw (currently also in the IESG > > review) reserves the bottom of the PW stack for the PW flow > > labels, e.g., in Section 1.1: > > > > > > > > This document describes a method of adding an additional label > > stack entry (LSE) at the bottom of stack in order to facilitate > > the load balancing of the flows within a PW over the available > > ECMPs. > > > > > > > > One could argue that draft-ietf-pwe3-gal-in-pw only applies to > > MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and > > FWIW, > > > > such an argument, were it presented, would be highly problematic, > > because: > > > > > > > > 1. RFC 5960 (which defines the MPLS-TP data plane) did not > > define any differences between the PW data plane in IP/MPLS and > > MPLS-TP. > > > > 2. One of the most popular scenarios for using multi- > segment > > pseudowires is the case when an edge-to-edge service emulation > > crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, > > the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow- > aware > > T-PE at the edge of an IP/MPLS domain) would potentially compete > > with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, > > e.g., for relying a PW status message that it has received over a > > Targeted LDP session from the IP/MPLS domain to a static PW > status > > message to cross the MPLS-TP domain) for the bottom-of-stack > > position. > > > > > > > > The issue I am raising Is not new. It has been actively discussed > > on the PWE3 mailing list with regard to adoption of > > draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for > > both the flow label and GAL taking the bottom-of-the-stack > > position. But, to the best of my understanding, consensus on this > > issue has not been reached. > > > > > > > > Hopefully this comment will be useful. > > > > > > > > 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. > > > > 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. > > > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf >=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 From mach.chen@huawei.com Fri Aug 19 01:11: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 B579321F8A4E for ; Fri, 19 Aug 2011 01:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.021 X-Spam-Level: X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[AWL=1.577, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr2F1-cIeX0n for ; Fri, 19 Aug 2011 01:11:04 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4D36421F86EE for ; Fri, 19 Aug 2011 01:11:04 -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 <0LQ600B841FUGK@szxga03-in.huawei.com> for pwe3@ietf.org; Fri, 19 Aug 2011 16:11:54 +0800 (CST) Received: from szxrg02-dlp.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 <0LQ6009JU1FMRX@szxga03-in.huawei.com> for pwe3@ietf.org; Fri, 19 Aug 2011 16:11:54 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADH84077; Fri, 19 Aug 2011 16:11:53 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 19 Aug 2011 16:11:45 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.30]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Fri, 19 Aug 2011 16:11:53 +0800 Date: Fri, 19 Aug 2011 08:11:52 +0000 From: Mach Chen In-reply-to: <44F4E579A764584EA9BDFD07D0CA081306ED873C@tlvmail1> X-Originating-IP: [10.110.98.106] To: Daniel Cohn , "pwe3@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_oc/aK+yOKALazN433nucwQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Requesting additional feedback on draft-cohn-mpls-tp-pw-protection-01 Thread-index: AcxQOYVbNToQFPx5SzGMez8tviQ5SABdKbRwAyRS6JA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <44F4E579A764584EA9BDFD07D0CA081306ED873C@tlvmail1> Subject: Re: [PWE3] Requesting additional feedback on draft-cohn-mpls-tp-pw-protection-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, 19 Aug 2011 08:11:07 -0000 --Boundary_(ID_oc/aK+yOKALazN433nucwQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, According to Daniel's explanation, I think the idea (linear protection for PW) is straightforward , I support to progress it. Best regards, Mach From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Wednesday, August 03, 2011 3:24 PM To: pwe3@ietf.org Subject: [PWE3] Requesting additional feedback on draft-cohn-mpls-tp-pw-protection-01 Hi, The authors would like to request additional feedback on the MPLS-TP Linear Protection Applicability to MS-PW, http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-01 Specifically, at the PWE3 meeting last week, there was a discussion on whether the PW redundancy bit draft (http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-04) can comply with MPLS-TP requirements for PW protection. We believe the answer to be clearly in the negative, and therefore would like to require WG adoption of the above draft after comments on this are addressed. This is a list of the TP requirements that in our opinion are not met by the PW redundancy draft. Please do not interpret the below as negative criticism of the PW redundancy draft - it is not. The question is not about the merits of the PW redundancy protocol, but whether it complies with TP requirements (which historically came after the PW redundancy draft) 1.- According to RFC 5654 (req 65), MPLS-TP MUST support 1+1 protection. PW redundancy draft does not comply with this. 2.- According to RFC 5654 (req 76 and 83) MPLS-TP MUST support management-plane triggers as defined in RFC 4427 - specifically lockout, forced and manual switch. Although the OPTIONAL switchover coordination mode in PW redundancy draft (6.3) implicitly support some management triggers, it cannot support all triggers in RFC 4427. For example, forced switch and lockout are not supported (see 6.3.2 - switchover command is ignore if requested PW is not up) 3.- According to RFC 5654 (req 75), MPLS-TP MUST support OAM-based triggers. PW redundancy draft exclusively relies on PW status bits triggers. 4.- According to RFC 5654 (req 77), there MUST be a mechanism to distinguish administrative recovery actions from recovery actions initiated by other triggers. This is not supported by the PW redundancy draft - the switchover request message does not specify what triggered the action on the other endpoint. 5.- According to RFC 5654 (req 79), MPLS-TP protection mechanisms MUST support priority logic to negotiate and accommodate coexisting requests for protection-switching (e.g., administrative requests and requests due to link/node failures). For example, PW redundancy mechanisms do not specify priority between administrative triggers (e.g. forced/manual switch) and failure triggers (e.g. SF or SD). 6.- According to RFC 5654 (req 73), MPLS-TP MUST support revertive and non-revertive behavior. PW redundancy draft provides OPTIONAL support of reversion, without explicit definitions of how the WTR timer is handled (e.g. what happens if different timer values are configured in each side, no administrative command to clear the WTR state), and without provisioning mismatch indication (like R bit in linear protection draft). 7.- According to RFC 5654 (req 58), MPLS-TP MUST support 50 ms recovery. The linear protection draft supports several features that reduce the recovery time, such as: - 1-phase operation, while PW redundancy draft in the switchover coordination mode is 2-phase (switch only after receiving confirmation from remote endpoint) - Rapid retransmission of PSC messages to overcome packet loss. In PW redundancy, the loss of a single switchover coordination message will result in recovery times significantly higher than 50 ms 8.- According to RFC 5654 (req 61), MPLS-TP MUST support coordination with server layer protection protocols to avoid race conditions - linear protection defines hold-off timer to comply with this requirement. PW redundancy does not support this. Looking forward for comments. --Boundary_(ID_oc/aK+yOKALazN433nucwQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

    Hi,

     

    According to Daniel’s explanation, I think the idea (linear= protection for PW) is straightforward , I support to progress it.

     

    Best regards,

    Mach

     

    From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Daniel Cohn
    Sent: Wednesday, August 03, 2011 3:24 PM
    To: pwe3@ietf.org
    Subject: [PWE3] Requesting additional feedback on draft-cohn-mpls-tp= -pw-protection-01

     

    Hi,

     

    The authors would like to reque= st additional feedback on the MPLS-TP Linear Protection Applicability to MS= -PW, = http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-01

     

    Specifically, at the PWE3 meeti= ng last week, there was a discussion on whether the PW redunda= ncy bit draft (http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-04) can comply with MPLS-TP requirements for PW protection.

    We believe the answer to be cle= arly in the negative, and therefore would like to require WG adoption of th= e above draft after comments on this are addressed.

     

    This is a list of the TP requir= ements that in our opinion are not met by the PW redundancy draft.

     

    Please do not interpret the bel= ow as negative criticism of the PW redundancy draft – it is not. The = question is not about the merits of the PW redundancy protocol, but whether= it complies with TP requirements (which historically came after the PW redundancy draft)

     

    1.- According to RFC 5654 (req = 65), MPLS-TP MUST support 1+1 protection. PW redundancy draft does not = comply with this.

     

    2.- According to RFC 5654 (req = 76 and 83) MPLS-TP MUST support management-plane triggers as defined in RFC= 4427 - specifically lockout, forced and manual switch. Although the OPTION= AL switchover coordination mode in PW redundancy draft (6.3) implicitly support some management triggers, it can= not support all triggers in RFC 4427. For example, forced switch and lockou= t are not supported (see 6.3.2 – switchover command is ignore if requ= ested PW is not up)

     

    3.- According to RFC 5654 (req = 75), MPLS-TP MUST support OAM-based triggers. PW redundancy draft exclusive= ly relies on PW status bits triggers.

     

    4.- According to RFC 5654 (req = 77), there MUST be a mechanism to distinguish administrative recovery actio= ns from recovery actions initiated by other triggers. This is not supported= by the PW redundancy draft – the switchover request message does not specify what triggered the action on the other en= dpoint.

     

    5.- According to RFC 5654 (req = 79), MPLS-TP protection mechanisms MUST support priority logic to negotiate= and accommodate coexisting requests for protection-switching (e.g., admini= strative requests and requests due to link/node failures). For example, PW redundancy mechanisms do not specify = priority between administrative triggers (e.g. forced/manual switch) and fa= ilure triggers (e.g. SF or SD).

     

    6.- According to RFC 5654 (req = 73), MPLS-TP MUST support revertive and non-revertive behavior. PW redundan= cy draft provides OPTIONAL support of reversion, without explicit definitio= ns of how the WTR timer is handled (e.g. what happens if different timer values are configured in each side, no adm= inistrative command to clear the WTR state), and without provisioning misma= tch indication (like R bit in linear protection draft).

     

    7.- According to RFC 5654 (req = 58), MPLS-TP MUST support 50 ms recovery. The linear protection draft suppo= rts several features that reduce the recovery time, such as:

    - = 1-phase operation, while PW redundancy draft in the switchover coordination= mode is 2-phase (switch only after receiving confirmation from remote endp= oint)

    - = Rapid retransmission of PSC messages to overcome packet loss. In PW redunda= ncy, the loss of a single switchover coordination message will result in re= covery times significantly higher than 50 ms

     

    8.- According to RFC 5654 (req = 61), MPLS-TP MUST support coordination with server layer protection protoco= ls to avoid race conditions - linear protection defines hold-off timer to c= omply with this requirement. PW redundancy does not support this.

     

    Looking forward for comments.

     

    --Boundary_(ID_oc/aK+yOKALazN433nucwQ)-- From lmartini@cisco.com Fri Aug 19 13:16:37 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 61A9021F8B76; Fri, 19 Aug 2011 13:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LKnnGO8qcLr; Fri, 19 Aug 2011 13:16:36 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 3923B21F8B75; Fri, 19 Aug 2011 13:16:36 -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 p7JKHM6o002114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2011 14:17:22 -0600 (MDT) Message-ID: <4E4EC4D2.3070603@cisco.com> Date: Fri, 19 Aug 2011 14:17:22 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: John E Drake References: , , <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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: Fri, 19 Aug 2011 20:16:37 -0000 John, I would like to let applications decide how they design the use of the gal. So I would propose a simple change , that will move any discussions to the specific applications: The next text would be as follows: - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. Does this work ? Thanks. Luca On 08/18/11 08:00, John E Drake wrote: > Sasha, > > I completely agree with your recommendations: > > - releasing the bottom-of-stack requirement on GAL > > - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) > > - specifying that ECMP on labeled packets MUST ignore reserved labels > > Thanks, > > John > > Sent from my iPhone > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Alexander Vainshtein >> Sent: Wednesday, August 17, 2011 9:52 PM >> To: Luca Martini >> Cc: mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; >> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- >> gal-in-pw >> >> Luca and all, >> I have not found the statement you've proposed in draft-ietf-pwe3-fat- >> pw-06. Instead, it contans the following text in Section 8.5 " >> Applicability to MPLS-TP": >> >> >> The flow aware transport of a PW reorders packets, therefore MUST >> NOT be >> deployed in a network conforming to the MPLS-TP unless these >> integrity requirements >> specified in the SLA can be satisfied. >> >> >> (In the -07 version this text is repeated but followed by an incomplete >> statement " In a" immediately followed by the heading of Section 8.6. >> Since this addition is difficult to parse, I will ignore it for the >> moment.) >> >> IMHO and FWIW this means that prohibition on using flow aware PW in >> MPLS-TP environments is conditional on meeting specific SLA >> requirements for the service. So I think that the use case I've >> presented still holds. >> >> Please note also that, regardless of the restriction in draft-ietf- >> pwe3-fat-pw, be it conditional or absolute, usage of flow labels in an >> MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the >> label stack and taking one of multiple NHLFEs for the given incoming >> label in the ILM) were not used in this domain, e.g., by associating >> exactly one ILM entry with each incoming label in the ILM. And since >> MPLS-TP is supposed to carry not just PW clients but also IP ones, I >> would expect that this would be the case in any MPLS-TP deployment. >> >> I also think that releasing one restriction (on using GAL in PWs) at >> the expense of making another, conditional one (on usage of flow labels >> in MPLS-TP environments) absolute is not the most appropriate method >> for resolving technical issues. IMHO and FWIW better way to resolve the >> problem would be by: >> >> - releasing the bottom-of-stack requirement on GAL >> - making use of the statement in RFC 5586 that if GAL is encountered in >> a packet then G-ACh header MUST be present immediately after the bottom >> of the label stack (and not immediately after GAL) >> - specifying that ECMP on labeled packets MUST ignore reserved labels. >> >> I think that these considerations have been presented already in the >> discussion on draft-nadeau-pwe-vccv-2. >> >> Of course it would be even better if we could agree on transition to >> universal usage of the CW and VCCV Type 1 in PWs. But this is a >> different story. >> >> Regards, >> Sasha >> ____________________________________ >> From: Luca Martini [lmartini@cisco.com] >> Sent: Wednesday, August 17, 2011 9:58 PM >> To: Alexander Vainshtein >> Cc: Pablo Frank; mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan >> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >> Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw >> >> The solution is quite simple: >> >> "Flow Labels MUST not be used in an MPLS-TP environment." >> >> Luca >> >> >> >> >> >> On 08/16/11 21:46, Alexander Vainshtein wrote: >>> Pablo, >>> Sorry, but I think you're wrong. Only T-PE can insert the flow label >>> (because only T=PE can be "flow-aware"). S-PE simply performs swap on >>> PW label. >>> >>> Regards, >>> Sasha >>> >>> --------------------------------------------------------------------- >> --- >>> *From:* Pablo Frank [pabloisnot@gmail.com] >>> *Sent:* Wednesday, August 17, 2011 12:17 AM >>> *To:* Alexander Vainshtein >>> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; >>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >>> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal- >> in-pw >>> I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS >>> domain in the middle segment, you're no longer in an MPLS-TP >>> environment and so the GAL is not required to be BOS. During that >>> middle segment, the PW flow label would be placed below the GAL and >>> above the GACh. It gets removed when it hits the S-PE that switches >>> you back into the MPLS-TP environment. In other words, whether >> you're >>> in an MPLS-TP environment is determined segment by segment in a MS- >> PW. >>> Pablo >>> >>> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein >>> >> > wrote: >>> >>> Hi all, >>> After having sent out my comments I've noticed that the specific >>> example to illustrate the need to combine GAL and "flow label" >> was >>> inaccurate. >>> >>> A more relevant example would look like following (I do not >>> include a diagram, but it can be easily provided if necessary) >>> >>> 1. A MS-PW: >>> * Starts at an S-PE that resides at the edge of an MPLS-TP >>> domain (no ECMP) >>> * Crosses this domain and enters an IP/MPLS domain with >> ECMP >>> enabled using a T-PE that resides at the age of these two >>> domains >>> * Leaves this domain and enters a 2nd MPLS-TP domain (using >>> the 2nd T-PE) >>> * Terminates on another S-PE at the edge of the 2nd MPLS-TP >>> domain >>> 2. The operator intends to improve traffic distribution in the >>> IP/MPLS domain, hence he enables insertion and discard of >>> "flow labels" at the two S-PEs. Note that: >>> * This does not violate the MPLS-TP restriction on ECMP: >>> ECMP does not happen in he MPLS-TP domains >>> * T-PEs do not even have to be aware of flow labels >>> 3. The operator also intends to operate some end-to-end OAM for >>> this MS-PW using "GAL-in-PW". This results in a conflict >> since >>> both GAL and "flow label" are defined (in the corresponding >>> drafts) as bottom of stack. >>> >>> >>> >>> IMHO this describes a realistic scenario where the two drafts are >>> in controversy. >>> >>> Regards, >>> Sasha >>> ----------------------------------------------------------------- >> ------- >>> *From:* mpls-bounces@ietf.org >>> [mpls-bounces@ietf.org ] On Behalf >>> Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com >>> ] >>> *Sent:* Tuesday, August 16, 2011 4:26 PM >>> *To:* ietf@ietf.org >>> *Cc:* mpls@ietf.org ; Vladimir Kleiner; >> Idan >>> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >>> *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal- >> in-pw >>> Hi all, >>> >>> >>> >>> I would like to raise the following issue with regard to >>> draft-ietf-pwe3-gal-in-pw >>> > pw/?include_text=1>: >>> controversy vs. draft-ietf-pwe3-fat-pw >>> > pw/?include_text=1> >>> with regard to bottom-of-stack position. >>> >>> >>> >>> As stated in the Introduction, this draft removes the restriction >>> imposed by RFC 5586 on usage of Generic Associated Channel Label >>> (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 >> states: >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, >>> Concatenated Segments of LSPs, and with Sections, and MUST NOT be >>> used with PWs. It MUST always be at the bottom of the label >> stack >>> (i.e., S bit set to 1). >>> >>> >>> >>> draft-ietf-pwe3-gal-in-pw proposed to replace the original text >> in >>> RFC 5586 with the following >>> >>> >>> >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, >>> Concatenated Segments of LSPs, and with Sections, and MAY be used >>> with PWs. It MUST always be at the bottom of the label stack >>> (i.e., S bit set to 1). >>> >>> >>> >>> I.e., while removing this restriction of 5586, it does not >> modify >>> its requirement for the GAL being always at the bottom of the >>> label stack. >>> >>> >>> >>> At the same draft-ietf-pwe3-fat-pw (currently also in the IESG >>> review) reserves the bottom of the PW stack for the PW flow >>> labels, e.g., in Section 1.1: >>> >>> >>> >>> This document describes a method of adding an additional label >>> stack entry (LSE) at the bottom of stack in order to facilitate >>> the load balancing of the flows within a PW over the available >>> ECMPs. >>> >>> >>> >>> One could argue that draft-ietf-pwe3-gal-in-pw only applies to >>> MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and >>> FWIW, >>> >>> such an argument, were it presented, would be highly problematic, >>> because: >>> >>> >>> >>> 1. RFC 5960 (which defines the MPLS-TP data plane) did not >>> define any differences between the PW data plane in IP/MPLS and >>> MPLS-TP. >>> >>> 2. One of the most popular scenarios for using multi- >> segment >>> pseudowires is the case when an edge-to-edge service emulation >>> crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, >>> the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow- >> aware >>> T-PE at the edge of an IP/MPLS domain) would potentially compete >>> with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, >>> e.g., for relying a PW status message that it has received over a >>> Targeted LDP session from the IP/MPLS domain to a static PW >> status >>> message to cross the MPLS-TP domain) for the bottom-of-stack >>> position. >>> >>> >>> >>> The issue I am raising Is not new. It has been actively discussed >>> on the PWE3 mailing list with regard to adoption of >>> draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for >>> both the flow label and GAL taking the bottom-of-the-stack >>> position. But, to the best of my understanding, consensus on this >>> issue has not been reached. >>> >>> >>> >>> Hopefully this comment will be useful. >>> >>> >>> >>> 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. >>> >>> 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. >>> >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >> 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 From jdrake@juniper.net Fri Aug 19 13:53: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 1A55F11E8089; Fri, 19 Aug 2011 13:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.814 X-Spam-Level: X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcPUviMXFZR0; Fri, 19 Aug 2011 13:53:42 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9C93911E8094; Fri, 19 Aug 2011 13:53:40 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTk7Nc34UT0Ewmjd5ycPk+O8koU+zWBwe@postini.com; Fri, 19 Aug 2011 13:54:40 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 19 Aug 2011 13:53:22 -0700 From: John E Drake To: Luca Martini Date: Fri, 19 Aug 2011 13:53:19 -0700 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxerQwml9gxAd1LS9KD218PXkUzlgABISdA Message-ID: <5E893DB832F57341992548CDBB333163A0ACE3EB8C@EMBX01-HQ.jnpr.net> References: , , <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> <4E4EC4D2.3070603@cisco.com> In-Reply-To: <4E4EC4D2.3070603@cisco.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 Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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: Fri, 19 Aug 2011 20:53:45 -0000 Luca, So, you are considering weighted ECMP, with FAT and entropy label, to be an= application? We are also releasing the GAL to float until it finds its pr= oper level within the MPLS label stack? Thanks, John Sent from my iPhone > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Friday, August 19, 2011 1:17 PM > To: John E Drake > Cc: Alexander Vainshtein; mpls@ietf.org; ietf@ietf.org; Vladimir > Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; > Rotem Cohen > Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- > gal-in-pw > > John, > > > I would like to let applications decide how they design the use of the > gal. > > So I would propose a simple change , that will move any discussions to > the specific applications: > > The next text would be as follows: > > > > - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the > original text: > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > LSPs, Concatenated Segments of LSPs, and with Sections, and > MUST NOT be used with PWs. It MUST always be at the bottom of > the label stack (i.e., S bit set to 1). However, in other > MPLS > environments, this document places no restrictions on where > the GAL may appear within the label stack or its use with > PWs. > > is replaced by: > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > LSPs, Concatenated Segments of LSPs, and with Sections, and > MAY be used with PWs. > > > > Does this work ? > Thanks. > Luca > > > > > > > On 08/18/11 08:00, John E Drake wrote: > > Sasha, > > > > I completely agree with your recommendations: > > > > - releasing the bottom-of-stack requirement on GAL > > > > - making use of the statement in RFC 5586 that if GAL is encountered > in a packet then G-ACh header MUST be present immediately after the > bottom of the label stack (and not immediately after GAL) > > > > - specifying that ECMP on labeled packets MUST ignore reserved labels > > > > Thanks, > > > > John > > > > Sent from my iPhone > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> Alexander Vainshtein > >> Sent: Wednesday, August 17, 2011 9:52 PM > >> To: Luca Martini > >> Cc: mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; > >> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > >> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf- > pwe3- > >> gal-in-pw > >> > >> Luca and all, > >> I have not found the statement you've proposed in draft-ietf-pwe3- > fat- > >> pw-06. Instead, it contans the following text in Section 8.5 " > >> Applicability to MPLS-TP": > >> > >> > >> The flow aware transport of a PW reorders packets, therefore MUST > >> NOT be > >> deployed in a network conforming to the MPLS-TP unless these > >> integrity requirements > >> specified in the SLA can be satisfied. > >> > >> > >> (In the -07 version this text is repeated but followed by an > incomplete > >> statement " In a" immediately followed by the heading of Section > 8.6. > >> Since this addition is difficult to parse, I will ignore it for the > >> moment.) > >> > >> IMHO and FWIW this means that prohibition on using flow aware PW in > >> MPLS-TP environments is conditional on meeting specific SLA > >> requirements for the service. So I think that the use case I've > >> presented still holds. > >> > >> Please note also that, regardless of the restriction in draft-ietf- > >> pwe3-fat-pw, be it conditional or absolute, usage of flow labels in > an > >> MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the > >> label stack and taking one of multiple NHLFEs for the given incoming > >> label in the ILM) were not used in this domain, e.g., by associating > >> exactly one ILM entry with each incoming label in the ILM. And since > >> MPLS-TP is supposed to carry not just PW clients but also IP ones, I > >> would expect that this would be the case in any MPLS-TP deployment. > >> > >> I also think that releasing one restriction (on using GAL in PWs) at > >> the expense of making another, conditional one (on usage of flow > labels > >> in MPLS-TP environments) absolute is not the most appropriate method > >> for resolving technical issues. IMHO and FWIW better way to resolve > the > >> problem would be by: > >> > >> - releasing the bottom-of-stack requirement on GAL > >> - making use of the statement in RFC 5586 that if GAL is encountered > in > >> a packet then G-ACh header MUST be present immediately after the > bottom > >> of the label stack (and not immediately after GAL) > >> - specifying that ECMP on labeled packets MUST ignore reserved > labels. > >> > >> I think that these considerations have been presented already in the > >> discussion on draft-nadeau-pwe-vccv-2. > >> > >> Of course it would be even better if we could agree on transition to > >> universal usage of the CW and VCCV Type 1 in PWs. But this is a > >> different story. > >> > >> Regards, > >> Sasha > >> ____________________________________ > >> From: Luca Martini [lmartini@cisco.com] > >> Sent: Wednesday, August 17, 2011 9:58 PM > >> To: Alexander Vainshtein > >> Cc: Pablo Frank; mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; > Idan > >> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > >> Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal- > in-pw > >> > >> The solution is quite simple: > >> > >> "Flow Labels MUST not be used in an MPLS-TP environment." > >> > >> Luca > >> > >> > >> > >> > >> > >> On 08/16/11 21:46, Alexander Vainshtein wrote: > >>> Pablo, > >>> Sorry, but I think you're wrong. Only T-PE can insert the flow > label > >>> (because only T=3DPE can be "flow-aware"). S-PE simply performs swap > on > >>> PW label. > >>> > >>> Regards, > >>> Sasha > >>> > >>> ------------------------------------------------------------------- > -- > >> --- > >>> *From:* Pablo Frank [pabloisnot@gmail.com] > >>> *Sent:* Wednesday, August 17, 2011 12:17 AM > >>> *To:* Alexander Vainshtein > >>> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; > >>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen > >>> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3- > gal- > >> in-pw > >>> I think it's okay because as the PW crosses the ECMP-enabled > IP/MPLS > >>> domain in the middle segment, you're no longer in an MPLS-TP > >>> environment and so the GAL is not required to be BOS. During that > >>> middle segment, the PW flow label would be placed below the GAL and > >>> above the GACh. It gets removed when it hits the S-PE that > switches > >>> you back into the MPLS-TP environment. In other words, whether > >> you're > >>> in an MPLS-TP environment is determined segment by segment in a MS- > >> PW. > >>> Pablo > >>> > >>> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein > >>> >>> > wrote: > >>> > >>> Hi all, > >>> After having sent out my comments I've noticed that the > specific > >>> example to illustrate the need to combine GAL and "flow label" > >> was > >>> inaccurate. > >>> > >>> A more relevant example would look like following (I do not > >>> include a diagram, but it can be easily provided if necessary) > >>> > >>> 1. A MS-PW: > >>> * Starts at an S-PE that resides at the edge of an MPLS- > TP > >>> domain (no ECMP) > >>> * Crosses this domain and enters an IP/MPLS domain with > >> ECMP > >>> enabled using a T-PE that resides at the age of these > two > >>> domains > >>> * Leaves this domain and enters a 2nd MPLS-TP domain > (using > >>> the 2nd T-PE) > >>> * Terminates on another S-PE at the edge of the 2nd MPLS- > TP > >>> domain > >>> 2. The operator intends to improve traffic distribution in the > >>> IP/MPLS domain, hence he enables insertion and discard of > >>> "flow labels" at the two S-PEs. Note that: > >>> * This does not violate the MPLS-TP restriction on ECMP: > >>> ECMP does not happen in he MPLS-TP domains > >>> * T-PEs do not even have to be aware of flow labels > >>> 3. The operator also intends to operate some end-to-end OAM > for > >>> this MS-PW using "GAL-in-PW". This results in a conflict > >> since > >>> both GAL and "flow label" are defined (in the corresponding > >>> drafts) as bottom of stack. > >>> > >>> > >>> > >>> IMHO this describes a realistic scenario where the two drafts > are > >>> in controversy. > >>> > >>> Regards, > >>> Sasha > >>> --------------------------------------------------------------- > -- > >> ------- > >>> *From:* mpls-bounces@ietf.org > >>> [mpls-bounces@ietf.org ] On > Behalf > >>> Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com > >>> ] > >>> *Sent:* Tuesday, August 16, 2011 4:26 PM > >>> *To:* ietf@ietf.org > >>> *Cc:* mpls@ietf.org ; Vladimir Kleiner; > >> Idan > >>> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem > Cohen > >>> *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3- > gal- > >> in-pw > >>> Hi all, > >>> > >>> > >>> > >>> I would like to raise the following issue with regard to > >>> draft-ietf-pwe3-gal-in-pw > >>> in- > >> pw/?include_text=3D1>: > >>> controversy vs. draft-ietf-pwe3-fat-pw > >>> >> pw/?include_text=3D1> > >>> with regard to bottom-of-stack position. > >>> > >>> > >>> > >>> As stated in the Introduction, this draft removes the > restriction > >>> imposed by RFC 5586 on usage of Generic Associated Channel > Label > >>> (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 > >> states: > >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > LSPs, > >>> Concatenated Segments of LSPs, and with Sections, and MUST NOT > be > >>> used with PWs. It MUST always be at the bottom of the label > >> stack > >>> (i.e., S bit set to 1). > >>> > >>> > >>> > >>> draft-ietf-pwe3-gal-in-pw proposed to replace the original text > >> in > >>> RFC 5586 with the following > >>> > >>> > >>> > >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > LSPs, > >>> Concatenated Segments of LSPs, and with Sections, and MAY be > used > >>> with PWs. It MUST always be at the bottom of the label stack > >>> (i.e., S bit set to 1). > >>> > >>> > >>> > >>> I.e., while removing this restriction of 5586, it does not > >> modify > >>> its requirement for the GAL being always at the bottom of the > >>> label stack. > >>> > >>> > >>> > >>> At the same draft-ietf-pwe3-fat-pw (currently also in the IESG > >>> review) reserves the bottom of the PW stack for the PW flow > >>> labels, e.g., in Section 1.1: > >>> > >>> > >>> > >>> This document describes a method of adding an additional label > >>> stack entry (LSE) at the bottom of stack in order to facilitate > >>> the load balancing of the flows within a PW over the available > >>> ECMPs. > >>> > >>> > >>> > >>> One could argue that draft-ietf-pwe3-gal-in-pw only applies to > >>> MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO > and > >>> FWIW, > >>> > >>> such an argument, were it presented, would be highly > problematic, > >>> because: > >>> > >>> > >>> > >>> 1. RFC 5960 (which defines the MPLS-TP data plane) did > not > >>> define any differences between the PW data plane in IP/MPLS and > >>> MPLS-TP. > >>> > >>> 2. One of the most popular scenarios for using multi- > >> segment > >>> pseudowires is the case when an edge-to-edge service emulation > >>> crosses multiple IP/MPLS and MPLS-TP domains. In these > scenarios, > >>> the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow- > >> aware > >>> T-PE at the edge of an IP/MPLS domain) would potentially > compete > >>> with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, > >>> e.g., for relying a PW status message that it has received over > a > >>> Targeted LDP session from the IP/MPLS domain to a static PW > >> status > >>> message to cross the MPLS-TP domain) for the bottom-of-stack > >>> position. > >>> > >>> > >>> > >>> The issue I am raising Is not new. It has been actively > discussed > >>> on the PWE3 mailing list with regard to adoption of > >>> draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for > >>> both the flow label and GAL taking the bottom-of-the-stack > >>> position. But, to the best of my understanding, consensus on > this > >>> issue has not been reached. > >>> > >>> > >>> > >>> Hopefully this comment will be useful. > >>> > >>> > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ietf mailing list > >>> Ietf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf > >> 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 From lmartini@cisco.com Fri Aug 19 14:08:19 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 2C7621F0C46; Fri, 19 Aug 2011 14:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENWOP9XxIHjK; Fri, 19 Aug 2011 14:08:18 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id DF1FF1F0C44; Fri, 19 Aug 2011 14:08:17 -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 p7JL9Cp4006137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2011 15:09:12 -0600 (MDT) Message-ID: <4E4ED0F8.3050003@cisco.com> Date: Fri, 19 Aug 2011 15:09:12 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: John E Drake References: , , <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> <4E4EC4D2.3070603@cisco.com> <5E893DB832F57341992548CDBB333163A0ACE3EB8C@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0ACE3EB8C@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "ietf@ietf.org" , Vladimir Kleiner , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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: Fri, 19 Aug 2011 21:08:19 -0000 On 08/19/11 14:53, John E Drake wrote: > Luca, > > So, you are considering weighted ECMP, with FAT and entropy label, to be an application? We are also releasing the GAL to float until it finds its proper level within the MPLS label stack? Yes. It certainly addresses a specific problem that is only a concern in some networks. Maybe as application I meant the specific technology documents. For example if an OAM method needs to use the GAL for a specific purpose it should specify it there, without us putting restrictions in a generic way in this document. As for the float part, I consider the GAL to be a simple Flag that says " following the MPLS label stack , you will find a GACh construct , and not an IP packet" In MPLS the default is to have an IP packet, unless a different meaning is bound to the label by the control plane. Thsi is the reason we needed the GAL in the first place for the MPLS-TP environment , where IP is not used. Thanks, Luca > Thanks, > > John > > Sent from my iPhone > > >> -----Original Message----- >> From: Luca Martini [mailto:lmartini@cisco.com] >> Sent: Friday, August 19, 2011 1:17 PM >> To: John E Drake >> Cc: Alexander Vainshtein; mpls@ietf.org; ietf@ietf.org; Vladimir >> Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; >> Rotem Cohen >> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- >> gal-in-pw >> >> John, >> >> >> I would like to let applications decide how they design the use of the >> gal. >> >> So I would propose a simple change , that will move any discussions to >> the specific applications: >> >> The next text would be as follows: >> >> >> >> - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the >> original text: >> >> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on >> LSPs, Concatenated Segments of LSPs, and with Sections, and >> MUST NOT be used with PWs. It MUST always be at the bottom of >> the label stack (i.e., S bit set to 1). However, in other >> MPLS >> environments, this document places no restrictions on where >> the GAL may appear within the label stack or its use with >> PWs. >> >> is replaced by: >> >> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on >> LSPs, Concatenated Segments of LSPs, and with Sections, and >> MAY be used with PWs. >> >> >> >> Does this work ? >> Thanks. >> Luca >> >> >> >> >> >> >> On 08/18/11 08:00, John E Drake wrote: >>> Sasha, >>> >>> I completely agree with your recommendations: >>> >>> - releasing the bottom-of-stack requirement on GAL >>> >>> - making use of the statement in RFC 5586 that if GAL is encountered >> in a packet then G-ACh header MUST be present immediately after the >> bottom of the label stack (and not immediately after GAL) >>> - specifying that ECMP on labeled packets MUST ignore reserved labels >>> >>> Thanks, >>> >>> John >>> >>> Sent from my iPhone >>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >>>> Alexander Vainshtein >>>> Sent: Wednesday, August 17, 2011 9:52 PM >>>> To: Luca Martini >>>> Cc: mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; >>>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >>>> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf- >> pwe3- >>>> gal-in-pw >>>> >>>> Luca and all, >>>> I have not found the statement you've proposed in draft-ietf-pwe3- >> fat- >>>> pw-06. Instead, it contans the following text in Section 8.5 " >>>> Applicability to MPLS-TP": >>>> >>>> >>>> The flow aware transport of a PW reorders packets, therefore MUST >>>> NOT be >>>> deployed in a network conforming to the MPLS-TP unless these >>>> integrity requirements >>>> specified in the SLA can be satisfied. >>>> >>>> >>>> (In the -07 version this text is repeated but followed by an >> incomplete >>>> statement " In a" immediately followed by the heading of Section >> 8.6. >>>> Since this addition is difficult to parse, I will ignore it for the >>>> moment.) >>>> >>>> IMHO and FWIW this means that prohibition on using flow aware PW in >>>> MPLS-TP environments is conditional on meeting specific SLA >>>> requirements for the service. So I think that the use case I've >>>> presented still holds. >>>> >>>> Please note also that, regardless of the restriction in draft-ietf- >>>> pwe3-fat-pw, be it conditional or absolute, usage of flow labels in >> an >>>> MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the >>>> label stack and taking one of multiple NHLFEs for the given incoming >>>> label in the ILM) were not used in this domain, e.g., by associating >>>> exactly one ILM entry with each incoming label in the ILM. And since >>>> MPLS-TP is supposed to carry not just PW clients but also IP ones, I >>>> would expect that this would be the case in any MPLS-TP deployment. >>>> >>>> I also think that releasing one restriction (on using GAL in PWs) at >>>> the expense of making another, conditional one (on usage of flow >> labels >>>> in MPLS-TP environments) absolute is not the most appropriate method >>>> for resolving technical issues. IMHO and FWIW better way to resolve >> the >>>> problem would be by: >>>> >>>> - releasing the bottom-of-stack requirement on GAL >>>> - making use of the statement in RFC 5586 that if GAL is encountered >> in >>>> a packet then G-ACh header MUST be present immediately after the >> bottom >>>> of the label stack (and not immediately after GAL) >>>> - specifying that ECMP on labeled packets MUST ignore reserved >> labels. >>>> I think that these considerations have been presented already in the >>>> discussion on draft-nadeau-pwe-vccv-2. >>>> >>>> Of course it would be even better if we could agree on transition to >>>> universal usage of the CW and VCCV Type 1 in PWs. But this is a >>>> different story. >>>> >>>> Regards, >>>> Sasha >>>> ____________________________________ >>>> From: Luca Martini [lmartini@cisco.com] >>>> Sent: Wednesday, August 17, 2011 9:58 PM >>>> To: Alexander Vainshtein >>>> Cc: Pablo Frank; mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; >> Idan >>>> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >>>> Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal- >> in-pw >>>> The solution is quite simple: >>>> >>>> "Flow Labels MUST not be used in an MPLS-TP environment." >>>> >>>> Luca >>>> >>>> >>>> >>>> >>>> >>>> On 08/16/11 21:46, Alexander Vainshtein wrote: >>>>> Pablo, >>>>> Sorry, but I think you're wrong. Only T-PE can insert the flow >> label >>>>> (because only T=PE can be "flow-aware"). S-PE simply performs swap >> on >>>>> PW label. >>>>> >>>>> Regards, >>>>> Sasha >>>>> >>>>> ------------------------------------------------------------------- >> -- >>>> --- >>>>> *From:* Pablo Frank [pabloisnot@gmail.com] >>>>> *Sent:* Wednesday, August 17, 2011 12:17 AM >>>>> *To:* Alexander Vainshtein >>>>> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; >>>>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >>>>> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3- >> gal- >>>> in-pw >>>>> I think it's okay because as the PW crosses the ECMP-enabled >> IP/MPLS >>>>> domain in the middle segment, you're no longer in an MPLS-TP >>>>> environment and so the GAL is not required to be BOS. During that >>>>> middle segment, the PW flow label would be placed below the GAL and >>>>> above the GACh. It gets removed when it hits the S-PE that >> switches >>>>> you back into the MPLS-TP environment. In other words, whether >>>> you're >>>>> in an MPLS-TP environment is determined segment by segment in a MS- >>>> PW. >>>>> Pablo >>>>> >>>>> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein >>>>> >>>> > wrote: >>>>> >>>>> Hi all, >>>>> After having sent out my comments I've noticed that the >> specific >>>>> example to illustrate the need to combine GAL and "flow label" >>>> was >>>>> inaccurate. >>>>> >>>>> A more relevant example would look like following (I do not >>>>> include a diagram, but it can be easily provided if necessary) >>>>> >>>>> 1. A MS-PW: >>>>> * Starts at an S-PE that resides at the edge of an MPLS- >> TP >>>>> domain (no ECMP) >>>>> * Crosses this domain and enters an IP/MPLS domain with >>>> ECMP >>>>> enabled using a T-PE that resides at the age of these >> two >>>>> domains >>>>> * Leaves this domain and enters a 2nd MPLS-TP domain >> (using >>>>> the 2nd T-PE) >>>>> * Terminates on another S-PE at the edge of the 2nd MPLS- >> TP >>>>> domain >>>>> 2. The operator intends to improve traffic distribution in the >>>>> IP/MPLS domain, hence he enables insertion and discard of >>>>> "flow labels" at the two S-PEs. Note that: >>>>> * This does not violate the MPLS-TP restriction on ECMP: >>>>> ECMP does not happen in he MPLS-TP domains >>>>> * T-PEs do not even have to be aware of flow labels >>>>> 3. The operator also intends to operate some end-to-end OAM >> for >>>>> this MS-PW using "GAL-in-PW". This results in a conflict >>>> since >>>>> both GAL and "flow label" are defined (in the corresponding >>>>> drafts) as bottom of stack. >>>>> >>>>> >>>>> >>>>> IMHO this describes a realistic scenario where the two drafts >> are >>>>> in controversy. >>>>> >>>>> Regards, >>>>> Sasha >>>>> --------------------------------------------------------------- >> -- >>>> ------- >>>>> *From:* mpls-bounces@ietf.org >>>>> [mpls-bounces@ietf.org ] On >> Behalf >>>>> Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com >>>>> ] >>>>> *Sent:* Tuesday, August 16, 2011 4:26 PM >>>>> *To:* ietf@ietf.org >>>>> *Cc:* mpls@ietf.org ; Vladimir Kleiner; >>>> Idan >>>>> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem >> Cohen >>>>> *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3- >> gal- >>>> in-pw >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> I would like to raise the following issue with regard to >>>>> draft-ietf-pwe3-gal-in-pw >>>>> > in- >>>> pw/?include_text=1>: >>>>> controversy vs. draft-ietf-pwe3-fat-pw >>>>> >>> pw/?include_text=1> >>>>> with regard to bottom-of-stack position. >>>>> >>>>> >>>>> >>>>> As stated in the Introduction, this draft removes the >> restriction >>>>> imposed by RFC 5586 on usage of Generic Associated Channel >> Label >>>>> (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 >>>> states: >>>>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on >> LSPs, >>>>> Concatenated Segments of LSPs, and with Sections, and MUST NOT >> be >>>>> used with PWs. It MUST always be at the bottom of the label >>>> stack >>>>> (i.e., S bit set to 1). >>>>> >>>>> >>>>> >>>>> draft-ietf-pwe3-gal-in-pw proposed to replace the original text >>>> in >>>>> RFC 5586 with the following >>>>> >>>>> >>>>> >>>>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on >> LSPs, >>>>> Concatenated Segments of LSPs, and with Sections, and MAY be >> used >>>>> with PWs. It MUST always be at the bottom of the label stack >>>>> (i.e., S bit set to 1). >>>>> >>>>> >>>>> >>>>> I.e., while removing this restriction of 5586, it does not >>>> modify >>>>> its requirement for the GAL being always at the bottom of the >>>>> label stack. >>>>> >>>>> >>>>> >>>>> At the same draft-ietf-pwe3-fat-pw (currently also in the IESG >>>>> review) reserves the bottom of the PW stack for the PW flow >>>>> labels, e.g., in Section 1.1: >>>>> >>>>> >>>>> >>>>> This document describes a method of adding an additional label >>>>> stack entry (LSE) at the bottom of stack in order to facilitate >>>>> the load balancing of the flows within a PW over the available >>>>> ECMPs. >>>>> >>>>> >>>>> >>>>> One could argue that draft-ietf-pwe3-gal-in-pw only applies to >>>>> MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO >> and >>>>> FWIW, >>>>> >>>>> such an argument, were it presented, would be highly >> problematic, >>>>> because: >>>>> >>>>> >>>>> >>>>> 1. RFC 5960 (which defines the MPLS-TP data plane) did >> not >>>>> define any differences between the PW data plane in IP/MPLS and >>>>> MPLS-TP. >>>>> >>>>> 2. One of the most popular scenarios for using multi- >>>> segment >>>>> pseudowires is the case when an edge-to-edge service emulation >>>>> crosses multiple IP/MPLS and MPLS-TP domains. In these >> scenarios, >>>>> the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow- >>>> aware >>>>> T-PE at the edge of an IP/MPLS domain) would potentially >> compete >>>>> with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, >>>>> e.g., for relying a PW status message that it has received over >> a >>>>> Targeted LDP session from the IP/MPLS domain to a static PW >>>> status >>>>> message to cross the MPLS-TP domain) for the bottom-of-stack >>>>> position. >>>>> >>>>> >>>>> >>>>> The issue I am raising Is not new. It has been actively >> discussed >>>>> on the PWE3 mailing list with regard to adoption of >>>>> draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for >>>>> both the flow label and GAL taking the bottom-of-the-stack >>>>> position. But, to the best of my understanding, consensus on >> this >>>>> issue has not been reached. >>>>> >>>>> >>>>> >>>>> Hopefully this comment will be useful. >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ietf mailing list >>>>> Ietf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf >>>> 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 > From tnadeau@lucidvision.com Sat Aug 20 05:33: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 43D3221F86DE; Sat, 20 Aug 2011 05:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z1S6T2nnU55; Sat, 20 Aug 2011 05:33:55 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id BB79321F8634; Sat, 20 Aug 2011 05:33:54 -0700 (PDT) Received: from [192.168.1.104] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 73A1A1D91DA2; Sat, 20 Aug 2011 08:34:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <4E4ED0F8.3050003@cisco.com> Date: Sat, 20 Aug 2011 08:34:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <004110D7-3F29-4D1C-9C50-F5053AF408CB@lucidvision.com> References: , , <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> <4E4EC4D2.3070603@cisco.com> <5E893DB832F57341992548CDBB333163A0ACE3EB8C@EMBX01-HQ.jnpr.net> <4E4ED0F8.3050003@cisco.com> To: Luca Martini X-Mailer: Apple Mail (2.1244.3) Cc: "ietf@ietf.org" , Vladimir Kleiner , "mpls@ietf.org" , Idan Kaspit , Mishael Wexler , pwe3 , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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: Sat, 20 Aug 2011 12:33:56 -0000 On Aug 19, 2011, at 5:09 PM, Luca Martini wrote: > On 08/19/11 14:53, John E Drake wrote: >> Luca, >>=20 >> So, you are considering weighted ECMP, with FAT and entropy label, to = be an application? We are also releasing the GAL to float until it = finds its proper level within the MPLS label stack? > Yes. It certainly addresses a specific problem that is only a concern = in > some networks. > Maybe as application I meant the specific technology documents. For > example if an OAM method needs to use the GAL for a specific purpose = it > should specify it there, without us putting restrictions in a generic > way in this document. >=20 > As for the float part, I consider the GAL to be a simple Flag that = says > " following the MPLS label stack , you will find a GACh construct , = and > not an IP packet" This makes a lot of sense to me as it makes sure that the = specific applications use the GAL as needed. This document should just = lay out the generic rules for using it, but not preclude its use by some = application we have not through of yet down the road by making rules = that are too narrow. --Tom > In MPLS the default is to have an IP packet, unless a different = meaning > is bound to the label by the control plane. Thsi is the reason we = needed > the GAL in the first place for the MPLS-TP environment , where IP is = not > used. >=20 > Thanks, > Luca >=20 >> Thanks, >>=20 >> John >>=20 >> Sent from my iPhone >>=20 >>=20 >>> -----Original Message----- >>> From: Luca Martini [mailto:lmartini@cisco.com] >>> Sent: Friday, August 19, 2011 1:17 PM >>> To: John E Drake >>> Cc: Alexander Vainshtein; mpls@ietf.org; ietf@ietf.org; Vladimir >>> Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; >>> Rotem Cohen >>> Subject: Re: [mpls] [PWE3] IETF Last Call comment on = draft-ietf-pwe3- >>> gal-in-pw >>>=20 >>> John, >>>=20 >>>=20 >>> I would like to let applications decide how they design the use of = the >>> gal. >>>=20 >>> So I would propose a simple change , that will move any discussions = to >>> the specific applications: >>>=20 >>> The next text would be as follows: >>>=20 >>>=20 >>>=20 >>> - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the >>> original text: >>>=20 >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on >>> LSPs, Concatenated Segments of LSPs, and with Sections, and >>> MUST NOT be used with PWs. It MUST always be at the bottom = of >>> the label stack (i.e., S bit set to 1). However, in other >>> MPLS >>> environments, this document places no restrictions on where >>> the GAL may appear within the label stack or its use with >>> PWs. >>>=20 >>> is replaced by: >>>=20 >>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on >>> LSPs, Concatenated Segments of LSPs, and with Sections, and >>> MAY be used with PWs. >>>=20 >>>=20 >>>=20 >>> Does this work ? >>> Thanks. >>> Luca >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 08/18/11 08:00, John E Drake wrote: >>>> Sasha, >>>>=20 >>>> I completely agree with your recommendations: >>>>=20 >>>> - releasing the bottom-of-stack requirement on GAL >>>>=20 >>>> - making use of the statement in RFC 5586 that if GAL is = encountered >>> in a packet then G-ACh header MUST be present immediately after the >>> bottom of the label stack (and not immediately after GAL) >>>> - specifying that ECMP on labeled packets MUST ignore reserved = labels >>>>=20 >>>> Thanks, >>>>=20 >>>> John >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>> -----Original Message----- >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On = Behalf >>> Of >>>>> Alexander Vainshtein >>>>> Sent: Wednesday, August 17, 2011 9:52 PM >>>>> To: Luca Martini >>>>> Cc: mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; >>>>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >>>>> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf- >>> pwe3- >>>>> gal-in-pw >>>>>=20 >>>>> Luca and all, >>>>> I have not found the statement you've proposed in draft-ietf-pwe3- >>> fat- >>>>> pw-06. Instead, it contans the following text in Section 8.5 " >>>>> Applicability to MPLS-TP": >>>>>=20 >>>>> >>>>> The flow aware transport of a PW reorders packets, therefore = MUST >>>>> NOT be >>>>> deployed in a network conforming to the MPLS-TP unless these >>>>> integrity requirements >>>>> specified in the SLA can be satisfied. >>>>> >>>>>=20 >>>>> (In the -07 version this text is repeated but followed by an >>> incomplete >>>>> statement " In a" immediately followed by the heading of Section >>> 8.6. >>>>> Since this addition is difficult to parse, I will ignore it for = the >>>>> moment.) >>>>>=20 >>>>> IMHO and FWIW this means that prohibition on using flow aware PW = in >>>>> MPLS-TP environments is conditional on meeting specific SLA >>>>> requirements for the service. So I think that the use case I've >>>>> presented still holds. >>>>>=20 >>>>> Please note also that, regardless of the restriction in = draft-ietf- >>>>> pwe3-fat-pw, be it conditional or absolute, usage of flow labels = in >>> an >>>>> MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of = the >>>>> label stack and taking one of multiple NHLFEs for the given = incoming >>>>> label in the ILM) were not used in this domain, e.g., by = associating >>>>> exactly one ILM entry with each incoming label in the ILM. And = since >>>>> MPLS-TP is supposed to carry not just PW clients but also IP ones, = I >>>>> would expect that this would be the case in any MPLS-TP = deployment. >>>>>=20 >>>>> I also think that releasing one restriction (on using GAL in PWs) = at >>>>> the expense of making another, conditional one (on usage of flow >>> labels >>>>> in MPLS-TP environments) absolute is not the most appropriate = method >>>>> for resolving technical issues. IMHO and FWIW better way to = resolve >>> the >>>>> problem would be by: >>>>>=20 >>>>> - releasing the bottom-of-stack requirement on GAL >>>>> - making use of the statement in RFC 5586 that if GAL is = encountered >>> in >>>>> a packet then G-ACh header MUST be present immediately after the >>> bottom >>>>> of the label stack (and not immediately after GAL) >>>>> - specifying that ECMP on labeled packets MUST ignore reserved >>> labels. >>>>> I think that these considerations have been presented already in = the >>>>> discussion on draft-nadeau-pwe-vccv-2. >>>>>=20 >>>>> Of course it would be even better if we could agree on transition = to >>>>> universal usage of the CW and VCCV Type 1 in PWs. But this is a >>>>> different story. >>>>>=20 >>>>> Regards, >>>>> Sasha >>>>> ____________________________________ >>>>> From: Luca Martini [lmartini@cisco.com] >>>>> Sent: Wednesday, August 17, 2011 9:58 PM >>>>> To: Alexander Vainshtein >>>>> Cc: Pablo Frank; mpls@ietf.org; ietf@ietf.org; Vladimir Kleiner; >>> Idan >>>>> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >>>>> Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal- >>> in-pw >>>>> The solution is quite simple: >>>>>=20 >>>>> "Flow Labels MUST not be used in an MPLS-TP environment." >>>>>=20 >>>>> Luca >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 08/16/11 21:46, Alexander Vainshtein wrote: >>>>>> Pablo, >>>>>> Sorry, but I think you're wrong. Only T-PE can insert the flow >>> label >>>>>> (because only T=3DPE can be "flow-aware"). S-PE simply performs = swap >>> on >>>>>> PW label. >>>>>>=20 >>>>>> Regards, >>>>>> Sasha >>>>>>=20 >>>>>> = ------------------------------------------------------------------- >>> -- >>>>> --- >>>>>> *From:* Pablo Frank [pabloisnot@gmail.com] >>>>>> *Sent:* Wednesday, August 17, 2011 12:17 AM >>>>>> *To:* Alexander Vainshtein >>>>>> *Cc:* ietf@ietf.org; mpls@ietf.org; Vladimir Kleiner; Idan = Kaspit; >>>>>> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen >>>>>> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3- >>> gal- >>>>> in-pw >>>>>> I think it's okay because as the PW crosses the ECMP-enabled >>> IP/MPLS >>>>>> domain in the middle segment, you're no longer in an MPLS-TP >>>>>> environment and so the GAL is not required to be BOS. During = that >>>>>> middle segment, the PW flow label would be placed below the GAL = and >>>>>> above the GACh. It gets removed when it hits the S-PE that >>> switches >>>>>> you back into the MPLS-TP environment. In other words, whether >>>>> you're >>>>>> in an MPLS-TP environment is determined segment by segment in a = MS- >>>>> PW. >>>>>> Pablo >>>>>>=20 >>>>>> On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein >>>>>> >>>>> > wrote: >>>>>>=20 >>>>>> Hi all, >>>>>> After having sent out my comments I've noticed that the >>> specific >>>>>> example to illustrate the need to combine GAL and "flow label" >>>>> was >>>>>> inaccurate. >>>>>>=20 >>>>>> A more relevant example would look like following (I do not >>>>>> include a diagram, but it can be easily provided if necessary) >>>>>>=20 >>>>>> 1. A MS-PW: >>>>>> * Starts at an S-PE that resides at the edge of an MPLS- >>> TP >>>>>> domain (no ECMP) >>>>>> * Crosses this domain and enters an IP/MPLS domain with >>>>> ECMP >>>>>> enabled using a T-PE that resides at the age of these >>> two >>>>>> domains >>>>>> * Leaves this domain and enters a 2nd MPLS-TP domain >>> (using >>>>>> the 2nd T-PE) >>>>>> * Terminates on another S-PE at the edge of the 2nd = MPLS- >>> TP >>>>>> domain >>>>>> 2. The operator intends to improve traffic distribution in = the >>>>>> IP/MPLS domain, hence he enables insertion and discard of >>>>>> "flow labels" at the two S-PEs. Note that: >>>>>> * This does not violate the MPLS-TP restriction on ECMP: >>>>>> ECMP does not happen in he MPLS-TP domains >>>>>> * T-PEs do not even have to be aware of flow labels >>>>>> 3. The operator also intends to operate some end-to-end OAM >>> for >>>>>> this MS-PW using "GAL-in-PW". This results in a conflict >>>>> since >>>>>> both GAL and "flow label" are defined (in the = corresponding >>>>>> drafts) as bottom of stack. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> IMHO this describes a realistic scenario where the two drafts >>> are >>>>>> in controversy. >>>>>>=20 >>>>>> Regards, >>>>>> Sasha >>>>>> = --------------------------------------------------------------- >>> -- >>>>> ------- >>>>>> *From:* mpls-bounces@ietf.org >>>>>> [mpls-bounces@ietf.org ] On >>> Behalf >>>>>> Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com >>>>>> ] >>>>>> *Sent:* Tuesday, August 16, 2011 4:26 PM >>>>>> *To:* ietf@ietf.org >>>>>> *Cc:* mpls@ietf.org ; Vladimir Kleiner; >>>>> Idan >>>>>> Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem >>> Cohen >>>>>> *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3- >>> gal- >>>>> in-pw >>>>>> Hi all, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I would like to raise the following issue with regard to >>>>>> draft-ietf-pwe3-gal-in-pw >>>>>> >> in- >>>>> pw/?include_text=3D1>: >>>>>> controversy vs. draft-ietf-pwe3-fat-pw >>>>>> >>>> pw/?include_text=3D1> >>>>>> with regard to bottom-of-stack position. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> As stated in the Introduction, this draft removes the >>> restriction >>>>>> imposed by RFC 5586 on usage of Generic Associated Channel >>> Label >>>>>> (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 >>>>> states: >>>>>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on >>> LSPs, >>>>>> Concatenated Segments of LSPs, and with Sections, and MUST NOT >>> be >>>>>> used with PWs. It MUST always be at the bottom of the label >>>>> stack >>>>>> (i.e., S bit set to 1). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> draft-ietf-pwe3-gal-in-pw proposed to replace the original = text >>>>> in >>>>>> RFC 5586 with the following >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> In MPLS-TP, the GAL MUST be used with packets on a G-ACh on >>> LSPs, >>>>>> Concatenated Segments of LSPs, and with Sections, and MAY be >>> used >>>>>> with PWs. It MUST always be at the bottom of the label stack >>>>>> (i.e., S bit set to 1). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I.e., while removing this restriction of 5586, it does not >>>>> modify >>>>>> its requirement for the GAL being always at the bottom of the >>>>>> label stack. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> At the same draft-ietf-pwe3-fat-pw (currently also in the IESG >>>>>> review) reserves the bottom of the PW stack for the PW flow >>>>>> labels, e.g., in Section 1.1: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> This document describes a method of adding an additional label >>>>>> stack entry (LSE) at the bottom of stack in order to = facilitate >>>>>> the load balancing of the flows within a PW over the available >>>>>> ECMPs. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> One could argue that draft-ietf-pwe3-gal-in-pw only applies to >>>>>> MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO >>> and >>>>>> FWIW, >>>>>>=20 >>>>>> such an argument, were it presented, would be highly >>> problematic, >>>>>> because: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 1. RFC 5960 (which defines the MPLS-TP data plane) did >>> not >>>>>> define any differences between the PW data plane in IP/MPLS = and >>>>>> MPLS-TP. >>>>>>=20 >>>>>> 2. One of the most popular scenarios for using multi- >>>>> segment >>>>>> pseudowires is the case when an edge-to-edge service emulation >>>>>> crosses multiple IP/MPLS and MPLS-TP domains. In these >>> scenarios, >>>>>> the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow- >>>>> aware >>>>>> T-PE at the edge of an IP/MPLS domain) would potentially >>> compete >>>>>> with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, >>>>>> e.g., for relying a PW status message that it has received = over >>> a >>>>>> Targeted LDP session from the IP/MPLS domain to a static PW >>>>> status >>>>>> message to cross the MPLS-TP domain) for the bottom-of-stack >>>>>> position. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The issue I am raising Is not new. It has been actively >>> discussed >>>>>> on the PWE3 mailing list with regard to adoption of >>>>>> draft-nadeau-pwe3-vccv-2 as a WG document, with arguments for >>>>>> both the flow label and GAL taking the bottom-of-the-stack >>>>>> position. But, to the best of my understanding, consensus on >>> this >>>>>> issue has not been reached. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Hopefully this comment will be useful. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Sasha >>>>>>=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 >>>>>> 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 >>>>>> 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 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ietf mailing list >>>>>> Ietf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ietf >>>>> 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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From adrian@olddog.co.uk Tue Aug 23 05:42: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 DCBE621F871E; Tue, 23 Aug 2011 05:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uU-VGyUU7AH; Tue, 23 Aug 2011 05:42:38 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 103F321F858D; Tue, 23 Aug 2011 05:42:37 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NChhjn023681; Tue, 23 Aug 2011 13:43:43 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NChfXd023664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Aug 2011 13:43:42 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <4E386CF0.5050700@pi.nu> In-Reply-To: <4E386CF0.5050700@pi.nu> Date: Tue, 23 Aug 2011 13:43:42 +0100 Message-ID: <075101cc6192$4ab42060$e01c6120$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIS+X95oXxieqMDQPr0gT37CPhENZSdLZyA Content-Language: en-gb Cc: rtg-dir@ietf.org, pwe3@ietf.org, draft-ietf-pwe3-fat.all@tools.ietf.org Subject: Re: [PWE3] [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 12:42:39 -0000 The authors are snoozing in the sun somewhere. > OAM appears in the table of content and as header 7. It is not > expanded in the document anywhere. Should be done at first occurance. RFC Ed note entered > page 6. The last paragraph of section 1 talks about TC bits > (and EXP bits). We don't have TC bits - the correct name is TC field. RFC Ed note entered > First paragraph section three: > This paragraph talks in genral about "load balanced paths" while the > rest of the document is very specific about ECMP, it is the intention > that this should work for any load balancing paradigm? Authors? > Second paragraph section three: > Normally a label is assigned by the down stream node, this scheme > is doing upstream allocation. Don't see a problem under normal > operation, but if the label "by accident" becomes top of stack > this could have "interesting" effects. Think this is mentioned in 1.2 > Sectyion 4 second paagraph: > > OLD > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. A PE that is using PW signalling and that does > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > A PE that is using PW signalling and which does not receive a FL Sub- > TLV from its peer MUST NOT include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > NEW > The absence of a FL Sub-TLV indicates that the PE is unable to > process flow labels. An ingress PE that is using PW signalling > and that does not send a FL Sub-TLV MUST NOT include a flow label > in the PW packet. An ingress PE that is using PW signalling and > which does not receive a FL Sub-TLV from its egress peer MUST NOT > include a flow label in the PW packet. > This preserves backwards compatibility with existing PW > specifications. > END I think this is right. No doubt the authors were thinking of bidirectional PWs, but with current state of the art, I think Loa is right and have entered the RFC Ed note > The IANA section: > > In the IANA section we should use a TBD entry for the Flow label > indicator; and maybe add 0x17 as suggest value in the text. I think this is wrong because early allocation was done (as you note below). IANA has indicated they understand the action. > The text in the IANA section needs to aligned with the rest of > the text, or maybe even better have the rest of the text align > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > else but in the iana section. OLD o FL (value 0x17) is the flow label sub-TLV identifier assigned by IANA (seeSection 11 ). NEW o FL (value 0x17) is the flow label indicator sub-TLV identifier assigned by IANA (see Section 11). END > To make it easier to find the references to the IANA registries > should start with "Pseudowire Name Spaces (PWE3)" point to > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > sub-registry, and ask for assigment of the next free value from > the Experts review space (suggested value 0x17). > > On the other hand it looks like we have an early assignment > (Flow Label shows up with the value 0x17). If this is the case > after making the text changes suggest above this should be mentioned > in the IANA section. RFC Ed note entered Thanks, Adrian From adrian@olddog.co.uk Tue Aug 23 05:45: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 3626D21F8A35; Tue, 23 Aug 2011 05:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6inTXdZtzzzP; Tue, 23 Aug 2011 05:45:21 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 316F221F89CC; Tue, 23 Aug 2011 05:45:21 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NCdllM002703; Tue, 23 Aug 2011 13:39:47 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NCdjq8002697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Aug 2011 13:39:46 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <4E386CF0.5050700@pi.nu> In-Reply-To: Date: Tue, 23 Aug 2011 13:46:26 +0100 Message-ID: <075501cc6192$acbdef70$0639ce50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIS+X95oXxieqMDQPr0gT37CPhENZSdLZyAgAAEdZA= Content-Language: en-gb Cc: draft-ietf-pwe3-fat-pw@tools.ietf.org, rtg-dir@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 12:45:22 -0000 Ah, I see why there might have been no response before. Sending again with the correct email alias. A > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 23 August 2011 13:44 > To: 'Loa Andersson'; 'rtg-ads@tools.ietf.org' > Cc: 'pwe3@ietf.org'; 'rtg-dir@ietf.org'; 'draft-ietf-pwe3-fat.all@tools.ietf.org' > Subject: RE: [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 > > The authors are snoozing in the sun somewhere. > > > OAM appears in the table of content and as header 7. It is not > > expanded in the document anywhere. Should be done at first occurance. > > RFC Ed note entered > > > page 6. The last paragraph of section 1 talks about TC bits > > (and EXP bits). We don't have TC bits - the correct name is TC field. > > RFC Ed note entered > > > First paragraph section three: > > This paragraph talks in genral about "load balanced paths" while the > > rest of the document is very specific about ECMP, it is the intention > > that this should work for any load balancing paradigm? > > Authors? > > > Second paragraph section three: > > Normally a label is assigned by the down stream node, this scheme > > is doing upstream allocation. Don't see a problem under normal > > operation, but if the label "by accident" becomes top of stack > > this could have "interesting" effects. > > Think this is mentioned in 1.2 > > > Sectyion 4 second paagraph: > > > > OLD > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. A PE that is using PW signalling and that does > > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > > A PE that is using PW signalling and which does not receive a FL Sub- > > TLV from its peer MUST NOT include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > NEW > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. An ingress PE that is using PW signalling > > and that does not send a FL Sub-TLV MUST NOT include a flow label > > in the PW packet. An ingress PE that is using PW signalling and > > which does not receive a FL Sub-TLV from its egress peer MUST NOT > > include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > END > > I think this is right. No doubt the authors were thinking of bidirectional PWs, but > with current state of the art, I think Loa is right and have entered the RFC Ed note > > > The IANA section: > > > > In the IANA section we should use a TBD entry for the Flow label > > indicator; and maybe add 0x17 as suggest value in the text. > > I think this is wrong because early allocation was done (as you note below). > IANA has indicated they understand the action. > > > The text in the IANA section needs to aligned with the rest of > > the text, or maybe even better have the rest of the text align > > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > > else but in the iana section. > > OLD > o FL (value 0x17) is the flow label sub-TLV identifier assigned by > IANA (seeSection 11 ). > NEW > o FL (value 0x17) is the flow label indicator sub-TLV identifier > assigned by IANA (see Section 11). > END > > > To make it easier to find the references to the IANA registries > > should start with "Pseudowire Name Spaces (PWE3)" point to > > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > > sub-registry, and ask for assigment of the next free value from > > the Experts review space (suggested value 0x17). > > > > On the other hand it looks like we have an early assignment > > (Flow Label shows up with the value 0x17). If this is the case > > after making the text changes suggest above this should be mentioned > > in the IANA section. > > RFC Ed note entered > > Thanks, > Adrian From adrian@olddog.co.uk Tue Aug 23 05:45: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 0B28621F84E4; Tue, 23 Aug 2011 05:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgnZulzNRTxy; Tue, 23 Aug 2011 05:45:57 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id E13E321F85F2; Tue, 23 Aug 2011 05:45:56 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NCl1iD006647; Tue, 23 Aug 2011 13:47:01 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7NCkxvw006641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Aug 2011 13:47:00 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <4E386CF0.5050700@pi.nu> <4E3ADAE2.5060907@pi.nu> In-Reply-To: <4E3ADAE2.5060907@pi.nu> Date: Tue, 23 Aug 2011 13:47:00 +0100 Message-ID: <075c01cc6192$c0a04470$41e0cd50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIS+X95oXxieqMDQPr0gT37CPhENQKYhKOUlIhtb8A= Content-Language: en-gb Cc: draft-ietf-pwe3-fat-pw@tools.ietf.org, rtg-dir@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 12:45:58 -0000 Authors, This needs an answer please. It seems to me that you really don't want your hash algorithm examining labels, but also Loa is right that GAL could mess things up. Your thoughts? Thanks, Adrian > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: 04 August 2011 18:46 > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; pwe3@ietf.org; draft-ietf-pwe3-fat.all@tools.ietf.org > Subject: Re: [RTG-DIR] [PWE3] RtgDir review:draft-ietf-pwe3-fat-pw-07 > > All, > > > I have one more point on this - I should have captured it in > the previous mail but had to think and discuss a bit about it! > > Doing ECMP hashing over the label stack as described is OK, but > has one thing that needs to be taken care of. Introducing a > reserved label - most prominently the GAL - into the label > stack will change the outcome of the hash. Since we are ECMP-ing > on the hash result, we will no longer to be able to guarantee > that normal traffic and OAM packets will no longer be fate > sharing - draft-ietf-pwe3-fat-pw should say explicitly that > reserved labels should be excluded from ECMP hashing. > > /Loa > > On 2011-08-02 14:32, Loa Andersson wrote: > > Hello, > > > > I have been selected as the Routing Directorate reviewer for > > draft-ietf-pwe3-fat-pw-07. > > > > The Routing Directorate seeks to review all routing or > > routing-related drafts as they pass through IETF last call and IESG > > review, and sometimes on special request. The purpose of the review > > is to provide assistance to the Routing ADs. For more information > > about the Routing Directorate, please see > > http://www.ietf.org/iesg/directorate/routing.html > > > > Although these comments are primarily for the use of the Routing ADs, > > it would be helpful if you could consider them along with any other > > IETF Last Call comments that you receive, and strive to resolve them > > through discussion or by updating the draft. > > > > Document: draft-ietf-pwe3-fat-pw-07 > > Reviewer: Loa Andersson > > Review Date: 2 Aug 2011 > > IETF LC End Date: 3 Aug 2011 > > Intended Status: Standards Track > > > > Summary: > > I have no major concerns about this document, howver I thing it > > would be good to reslove the mostly editorial comments below > > (especially on the IANA section) before publication. > > > > Comments: > > > > Unexpanded acronyms: > > > > OAM appears in the table of content and as header 7. It is not > > expanded in the document anywhere. Should be done at first occurance. > > > > page 6. The last paragraph of section 1 talks about TC bits > > (and EXP bits). We don't have TC bits - the correct name is TC field. > > > > First paragraph section three: > > This paragraph talks in genral about "load balanced paths" while the > > rest of the document is very specific about ECMP, it is the intention > > that this should work for any load balancing paradigm? > > > > Second paragraph section three: > > Normally a label is assigned by the down stream node, this scheme > > is doing upstream allocation. Don't see a problem under normal > > operation, but if the label "by accident" becomes top of stack > > this could have "interesting" effects. > > > > Sectyion 4 second paagraph: > > > > OLD > > > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. A PE that is using PW signalling and that does > > not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > > A PE that is using PW signalling and which does not receive a FL Sub- > > TLV from its peer MUST NOT include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > > > NEW > > > > The absence of a FL Sub-TLV indicates that the PE is unable to > > process flow labels. An ingress PE that is using PW signalling > > and that does not send a FL Sub-TLV MUST NOT include a flow label > > in the PW packet. An ingress PE that is using PW signalling and > > which does not receive a FL Sub-TLV from its egress peer MUST NOT > > include a flow label in the PW packet. > > This preserves backwards compatibility with existing PW > > specifications. > > > > The IANA section: > > > > In the IANA section we should use a TBD entry for the Flow label > > indicator; and maybe add 0x17 as suggest value in the text. > > > > The text in the IANA section needs to aligned with the rest of > > the text, or maybe even better have the rest of the text align > > with the IANA section; e.g. Flow Labe intdicator is not used anywhere > > else but in the iana section. > > > > To make it easier to find the references to the IANA registries > > should start with "Pseudowire Name Spaces (PWE3)" point to > > "Pseudowire Interface Parameters Sub-TLV type Registry" as a > > sub-registry, and ask for assigment of the next free value from > > the Experts review space (suggested value 0x17). > > > > On the other hand it looks like we have an early assigment > > (Flow Label shows up with the value 0x17). If this is the case > > after making the text changes suggest above this should be mentioned > > in the IANA section. > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From matthew.bocci@alcatel-lucent.com Tue Aug 23 15:04: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 F409321F8D59 for ; Tue, 23 Aug 2011 15:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.775 X-Spam-Level: X-Spam-Status: No, score=-105.775 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FU0yVUVNLB4 for ; Tue, 23 Aug 2011 15:04:23 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 17BD421F8D58 for ; Tue, 23 Aug 2011 15:04:22 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p7NM5UvX010114 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 24 Aug 2011 00:05:30 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.35]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 24 Aug 2011 00:05:30 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Wed, 24 Aug 2011 00:05:29 +0200 Thread-Topic: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt Thread-Index: Acxh4MUptfpawfrBQoSjGLtPMH4oKg== Message-ID: <304B9369-581E-43EA-8E12-A04CB8D78BE2@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.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, 23 Aug 2011 22:04:24 -0000 All, We have a new WG draft.=20 Please can the authors submit a new version of the draft as a PWE3 WG draft= . Matthew On 2 Aug 2011, at 17:06, Giles Heron wrote: > support >=20 > On 19/07/2011 14:36, "Bocci, Matthew (Matthew)" > wrote: >=20 >> This email begins a poll of the list to see if there is consensus to ado= pt >> draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working = group >> draft. >>=20 >> Please indicate whether or not you support adoption of this draft, and s= end >> any comments to the PWE3 list. >>=20 >> This poll ends on Tuesday 9th August. >>=20 >> Regards, >>=20 >> Matthew and Andy. >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 From stbryant@cisco.com Wed Aug 24 02:50: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 5E09421F8AE9; Wed, 24 Aug 2011 02:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+yMkZ9jzYad; Wed, 24 Aug 2011 02:50:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0795821F8A69; Wed, 24 Aug 2011 02:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4295; q=dns/txt; s=iport; t=1314179480; x=1315389080; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZWiU+g35rsxb50b7DtxR8GPwUN5F6taYBrTKsJy3qxE=; b=Ee+iFOheYYdm3k8FIU4z4EPpq6qpD2LN0bUknbwA8PNLsQ1qhQmVb9fS 5/WGyznr8j04OPP5Lg9KSnbrPdwFGzcAUtFZovSx+syfum/8rYAvnv3l7 yFIRdtasVvWUui7Xqnr2ogBZHIPl5aLQDKOSSnOWdo19OWkM9wlHdAOlt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALzIVE6Q/khL/2dsb2JhbABCp3J3gUABAQEBAgEBAQELBAECASItBgMKARALGAkWDwkDAgECARUwEwEFAgEBHodPBJw3AYMmDwGbeoZJBJMZkHw X-IronPort-AV: E=Sophos;i="4.68,274,1312156800"; d="scan'208";a="112214089" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 24 Aug 2011 09:51:18 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7O9p37R012498; Wed, 24 Aug 2011 09:51:03 GMT Received: from dhcp-gpk02-vlan300-64-103-65-45.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p7O9p3o9007468; Wed, 24 Aug 2011 10:51:03 +0100 (BST) Message-ID: <4E54C987.5000108@cisco.com> Date: Wed, 24 Aug 2011 10:51:03 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <4E386CF0.5050700@pi.nu> <075101cc6192$4ab42060$e01c6120$@olddog.co.uk> In-Reply-To: <075101cc6192$4ab42060$e01c6120$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, rtg-ads@tools.ietf.org, pwe3@ietf.org, draft-ietf-pwe3-fat.all@tools.ietf.org Subject: Re: [PWE3] [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 09:50:11 -0000 On 23/08/2011 13:43, Adrian Farrel wrote: > The authors are snoozing in the sun somewhere. > >> OAM appears in the table of content and as header 7. It is not >> expanded in the document anywhere. Should be done at first occurance. > RFC Ed note entered > >> page 6. The last paragraph of section 1 talks about TC bits >> (and EXP bits). We don't have TC bits - the correct name is TC field. > RFC Ed note entered > >> First paragraph section three: >> This paragraph talks in genral about "load balanced paths" while the >> rest of the document is very specific about ECMP, it is the intention >> that this should work for any load balancing paradigm? > Authors? Although we invented the FL for ECMP, there are other types of load balance (for example channel bonding and link bundling) that might which to take advantage of the flow identification. This was discussed by the WG LC. >> Second paragraph section three: >> Normally a label is assigned by the down stream node, this scheme >> is doing upstream allocation. Don't see a problem under normal >> operation, but if the label "by accident" becomes top of stack >> this could have "interesting" effects. > Think this is mentioned in 1.2 > >> Sectyion 4 second paagraph: >> >> OLD >> The absence of a FL Sub-TLV indicates that the PE is unable to >> process flow labels. A PE that is using PW signalling and that does >> not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. >> A PE that is using PW signalling and which does not receive a FL Sub- >> TLV from its peer MUST NOT include a flow label in the PW packet. >> This preserves backwards compatibility with existing PW >> specifications. >> NEW >> The absence of a FL Sub-TLV indicates that the PE is unable to >> process flow labels. An ingress PE that is using PW signalling >> and that does not send a FL Sub-TLV MUST NOT include a flow label >> in the PW packet. An ingress PE that is using PW signalling and >> which does not receive a FL Sub-TLV from its egress peer MUST NOT >> include a flow label in the PW packet. >> This preserves backwards compatibility with existing PW >> specifications. >> END > I think this is right. No doubt the authors were thinking of bidirectional PWs, > but with current state of the art, I think Loa is right and have entered the RFC > Ed note The change is I think the addition of the term "An ingress". Surely it is redundant (but harmless) as only an ingress PE can impose a FL ... or are you concerned to discriminate between TPE and SPE? > >> The IANA section: >> >> In the IANA section we should use a TBD entry for the Flow label >> indicator; and maybe add 0x17 as suggest value in the text. > I think this is wrong because early allocation was done (as you note below). > IANA has indicated they understand the action. > >> The text in the IANA section needs to aligned with the rest of >> the text, or maybe even better have the rest of the text align >> with the IANA section; e.g. Flow Labe intdicator is not used anywhere >> else but in the iana section. > OLD > o FL (value 0x17) is the flow label sub-TLV identifier assigned by > IANA (seeSection 11 ). > NEW > o FL (value 0x17) is the flow label indicator sub-TLV identifier > assigned by IANA (see Section 11). > END > >> To make it easier to find the references to the IANA registries >> should start with "Pseudowire Name Spaces (PWE3)" point to >> "Pseudowire Interface Parameters Sub-TLV type Registry" as a >> sub-registry, and ask for assigment of the next free value from >> the Experts review space (suggested value 0x17). >> >> On the other hand it looks like we have an early assignment >> (Flow Label shows up with the value 0x17). If this is the case >> after making the text changes suggest above this should be mentioned >> in the IANA section. > RFC Ed note entered > > Thanks, > Adrian > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From adrian@olddog.co.uk Wed Aug 24 06:19:37 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 4ABEB21F8AF0; Wed, 24 Aug 2011 06:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ynmu8cGcz04N; Wed, 24 Aug 2011 06:19:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 091C521F8AE6; Wed, 24 Aug 2011 06:19:35 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7ODKhcl024766; Wed, 24 Aug 2011 14:20:43 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7ODKfAp024759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Aug 2011 14:20:42 +0100 From: "Adrian Farrel" To: References: <4E386CF0.5050700@pi.nu> <075101cc6192$4ab42060$e01c6120$@olddog.co.uk> <4E54C987.5000108@cisco.com> In-Reply-To: <4E54C987.5000108@cisco.com> Date: Wed, 24 Aug 2011 14:20:41 +0100 Message-ID: <00f401cc6260$9fb14880$df13d980$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIS+X95oXxieqMDQPr0gT37CPhENQKPj7ffAiMSCC2UeTgk0A== Content-Language: en-gb Cc: draft-ietf-pwe3-fat-pw@tools.ietf.org, rtg-dir@ietf.org, rtg-ads@tools.ietf.org, pwe3@ietf.org Subject: Re: [PWE3] [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 13:19:37 -0000 [Fixing the tools alias] > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: 24 August 2011 10:51 > To: adrian@olddog.co.uk > Cc: 'Loa Andersson'; rtg-ads@tools.ietf.org; rtg-dir@ietf.org; pwe3@ietf.org; > draft-ietf-pwe3-fat.all@tools.ietf.org > Subject: Re: [PWE3] [RTG-DIR] RtgDir review:draft-ietf-pwe3-fat-pw-07 > > On 23/08/2011 13:43, Adrian Farrel wrote: > > The authors are snoozing in the sun somewhere. > > > >> OAM appears in the table of content and as header 7. It is not > >> expanded in the document anywhere. Should be done at first occurance. > > RFC Ed note entered > > > >> page 6. The last paragraph of section 1 talks about TC bits > >> (and EXP bits). We don't have TC bits - the correct name is TC field. > > RFC Ed note entered > > > >> First paragraph section three: > >> This paragraph talks in genral about "load balanced paths" while the > >> rest of the document is very specific about ECMP, it is the intention > >> that this should work for any load balancing paradigm? > > Authors? > Although we invented the FL for ECMP, there are other types > of load balance (for example channel bonding and link bundling) > that might which to take advantage of the flow identification. > This was discussed by the WG LC. > > >> Second paragraph section three: > >> Normally a label is assigned by the down stream node, this scheme > >> is doing upstream allocation. Don't see a problem under normal > >> operation, but if the label "by accident" becomes top of stack > >> this could have "interesting" effects. > > Think this is mentioned in 1.2 > > > >> Sectyion 4 second paagraph: > >> > >> OLD > >> The absence of a FL Sub-TLV indicates that the PE is unable to > >> process flow labels. A PE that is using PW signalling and that does > >> not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. > >> A PE that is using PW signalling and which does not receive a FL Sub- > >> TLV from its peer MUST NOT include a flow label in the PW packet. > >> This preserves backwards compatibility with existing PW > >> specifications. > >> NEW > >> The absence of a FL Sub-TLV indicates that the PE is unable to > >> process flow labels. An ingress PE that is using PW signalling > >> and that does not send a FL Sub-TLV MUST NOT include a flow label > >> in the PW packet. An ingress PE that is using PW signalling and > >> which does not receive a FL Sub-TLV from its egress peer MUST NOT > >> include a flow label in the PW packet. > >> This preserves backwards compatibility with existing PW > >> specifications. > >> END > > I think this is right. No doubt the authors were thinking of bidirectional PWs, > > but with current state of the art, I think Loa is right and have entered the RFC > > Ed note > > The change is I think the addition of the term "An ingress". Surely it > is redundant (but harmless) as only an ingress PE can impose a FL ... > or are you concerned to discriminate between TPE and SPE? > > >> The IANA section: > >> > >> In the IANA section we should use a TBD entry for the Flow label > >> indicator; and maybe add 0x17 as suggest value in the text. > > I think this is wrong because early allocation was done (as you note below). > > IANA has indicated they understand the action. > > > >> The text in the IANA section needs to aligned with the rest of > >> the text, or maybe even better have the rest of the text align > >> with the IANA section; e.g. Flow Labe intdicator is not used anywhere > >> else but in the iana section. > > OLD > > o FL (value 0x17) is the flow label sub-TLV identifier assigned by > > IANA (seeSection 11 ). > > NEW > > o FL (value 0x17) is the flow label indicator sub-TLV identifier > > assigned by IANA (see Section 11). > > END > > > >> To make it easier to find the references to the IANA registries > >> should start with "Pseudowire Name Spaces (PWE3)" point to > >> "Pseudowire Interface Parameters Sub-TLV type Registry" as a > >> sub-registry, and ask for assigment of the next free value from > >> the Experts review space (suggested value 0x17). > >> > >> On the other hand it looks like we have an early assignment > >> (Flow Label shows up with the value 0x17). If this is the case > >> after making the text changes suggest above this should be mentioned > >> in the IANA section. > > RFC Ed note entered > > > > Thanks, > > Adrian From sboutros@cisco.com Sat Aug 27 19:13: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 2CE8D21F8B5F; Sat, 27 Aug 2011 19:13:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBfvRydeCLir; Sat, 27 Aug 2011 19:13:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 303C221F8B5D; Sat, 27 Aug 2011 19:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=3641; q=dns/txt; s=iport; t=1314497683; x=1315707283; h=date:to:from:subject:in-reply-to:references:mime-version: message-id; bh=Tk7AFCcBkVj9/Tl1zxwmfPPGWkyBAtqbvPe810eDz/Q=; b=R2kFZDdkF9Zy3zXtCae9p2p0DAW4WvXaHIxcqL0p1Kvv+xW1FnYy62k7 Ncj/oZ8QdWRJ9ew5ybhVvyA2cAYwdcZ3BNicJ0S7Qp5g9Jy1gueLC6Hd6 KfPL+QXu77KMggoTY/0QZMIWTlgCu5GbML5Byp4iYh8e3s74FYeG2NtQf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAAEWkWU6rRDoH/2dsb2JhbABCh16QUo9fd4FAAQEBAQMBAQEPASUCNBcCAgcEEQQBAQEeCQcZAgwfCQgGARIih1SZYwGdZAKGSgSHZJBSjA0 X-IronPort-AV: E=Sophos;i="4.68,291,1312156800"; d="scan'208";a="17136494" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 28 Aug 2011 02:14:40 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7S2EeuV001816; Sun, 28 Aug 2011 02:14:40 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 27 Aug 2011 19:14:39 -0700 Received: from sboutros-wxp01.ciswco.com ([10.21.168.81]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 27 Aug 2011 19:14:38 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 27 Aug 2011 19:14:31 -0700 To: "Shahram Davari" , "Loa Andersson" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "MPLS-TP ad hoc team" , "pwe3@ietf.org" , CCAMP From: Sami Boutros In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9329A7B9D@SJEXCHCCR02.cor p.ad.broadcom.com> References: <4E497423.8030001@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD6A9329A7B9D@SJEXCHCCR02.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Aug 2011 02:14:39.0231 (UTC) FILETIME=[3D87D0F0:01CC6528] Subject: Re: [PWE3] [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.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: Sun, 28 Aug 2011 02:13:23 -0000 Hi Shahram, The hard loopback function is expected to be done by the management plane as mentioned in the draft. I see most of the comments are related to either a HW/SW implementation or a basic MPLS forwarding concept that would apply. Please see comments inline.. At 01:32 PM 8/15/2011, Shahram Davari wrote: >Hi, > >I have a general clarification question regarding this draft. It >seems that the exact position of the Transmit, Loopback and receive >MEP/MIP in the data-plane processing is not well defined, which >could lead to unpredictable results. For example what is the >expected behavior for Transmit, Receive and Loopback points: > >- Transmit Before or after Ingress policing? >- Transmit and Loopback before or after Queuing/shaping? Sami: It is expected that test traffic will be sent after putting the LSP in Loopback by management plane, how this test traffic be queued or shaped will purely depend on the implementation of the policy of the interfaces and is not something we should mention in the draft. >- Loopback Before or after forwarding (Label Switching)? Sami: When you set a Loopback you are impacting the Fwding plane at the point of Loopback to send traffic back.. >- Loopback at Ingress Port (Down-MEP) or Egress port (Up-MEP)? Sami: This would depend on the Management plane setting up the Fwding and HW implementation of the box.. >- Loopback before TTL decrement or after TTL decrement? Sami: This is basic MPLS forwarding, MPLS would decrement TTL as packets ingress a box. >- Loopback before or after LSP termination at LSP terminating MEP? Sami: When you loopback at terminating MEP, then this would mean that the label crossconnect set by Management plane would not terminate the LSP, I would expect an operator will know how to set the MPLS Xconnect at the LB point. >- Loopback or not loopback ACH messages at terminating MEP? >- loopback or not Loopback VCCV messages at terminating MEP? >- loopback or not Loopback LSP OAM messages (such as BFD) with IP >address = 127/8 at terminating MEP? >- loopback or not Loopback LSP-Ping messages not defined in this draft? Sami: This is again basic MPLS forwarding, i.e. when you set an MPLS Xconnect at the loopback point, packets will be inspected only if the TTL expire. Thanks, Sami >And many similar questions. I would appreciate the authors response >and clarification. > >Thanks >Shahram > > > > > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >Of Loa Andersson >Sent: Monday, August 15, 2011 12:32 PM >To: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; >pwe3@ietf.org; CCAMP >Subject: [mpls] MPLS working group last call on >draft-ietf-mpls-tp-li-lb-03.txt > >Working Group, > >this is to start a working group last call on >draft-ietf-mpls-tp-li-lb-03.txt > >Please send your comments to the mpls working group mailing list. > >This last call ends on August 26th 2011. > >Loa >for the mpls wg co-charirs > >-- > > >Loa Andersson email: loa.andersson@ericsson.com >Sr Strategy and Standards Manager loa@pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From sboutros@cisco.com Sat Aug 27 19:19:08 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 22AE521F8B9D; Sat, 27 Aug 2011 19:19:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPyASkNd6fIV; Sat, 27 Aug 2011 19:19:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4A721F8B9B; Sat, 27 Aug 2011 19:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=3624; q=dns/txt; s=iport; t=1314498028; x=1315707628; h=date:to:from:subject:in-reply-to:references:mime-version: message-id; bh=CEJR9hrgozw+Mrfa+3ZmJV0YMUx/CQpG+nl/SydZN1g=; b=DskmxezRFlm5G/wiEXPyezBtQ2nSTjmmkukKzwnTZwW8vgyxiIq0baYs pVBbqQ1gAG6lFYh6g9QTpKxrjx5JFPqpzmAHf7zfbMr5cPB0fratfFhZU Kk2kRH71r8R4BzNGEt3MyMeadcle1l2cW+Y9lyPJwJ7ZUk+6KtkZ+Tt2o w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAAK+lWU6rRDoG/2dsb2JhbAA6CIdekFKPX3eBQAEBAQEDAQEBDwElAjQXAgIHBBEEAQEBHgkHGQIMHwkIBgESIodUmWQBnWQCgymDIQSHZJBSjA0 X-IronPort-AV: E=Sophos;i="4.68,291,1312156800"; d="scan'208";a="17142374" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-9.cisco.com with ESMTP; 28 Aug 2011 02:20:22 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7S2KMB8007919; Sun, 28 Aug 2011 02:20:22 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 27 Aug 2011 19:20:22 -0700 Received: from sboutros-wxp01.ciswco.com ([10.21.168.81]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Aug 2011 19:20:20 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 27 Aug 2011 19:18:49 -0700 To: "Shahram Davari" , "Shahram Davari" , "Loa Andersson" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "MPLS-TP ad hoc team" , "pwe3@ietf.org" , CCAMP From: Sami Boutros In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6A9329A7C0A@SJEXCHCCR02.cor p.ad.broadcom.com> References: <4E497423.8030001@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD6A9329A7C0A@SJEXCHCCR02.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Aug 2011 02:20:21.0274 (UTC) FILETIME=[09676FA0:01CC6529] Subject: Re: [PWE3] [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.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: Sun, 28 Aug 2011 02:19:08 -0000 At 02:31 PM 8/15/2011, Shahram Davari wrote: >Hi, > >A few more comments: > >- How is a MIP put to Loopback mode? >- How does the MIP get out of loopback? Sami: As mentioned in the draft this is done by Management plane. >- How does the Ingress MEP know that the Egress MEP has accepted its >request for Lockout? >- How does the Ingress MEP know that the MIP is or is not in loopback mode? Sami: Since this is done via Management plane, then the operator need to make sure that the LSP is locked before putting the circuit in Loopback. >previous versions of the draft addressed all these issues, but I am >wondering how are these done without special messages and Acks. Sami: We revisited the previous drafts, and the consensus among authors was to send a periodic message for the lockout and not rely on the request ack technique, primarily to make it more robust, and consistent with the Fault reporting mechanisms in the Fault draft and PSC drafts too. Thanks, Sami >Thx >Shahram > > >-----Original Message----- >From: Shahram Davari >Sent: Monday, August 15, 2011 1:33 PM >To: 'Loa Andersson'; 'mpls@ietf.org'; 'mpls-chairs@tools.ietf.org'; >'MPLS-TP ad hoc team'; 'pwe3@ietf.org'; 'CCAMP' >Subject: RE: [mpls] MPLS working group last call on >draft-ietf-mpls-tp-li-lb-03.txt > >Hi, > >I have a general clarification question regarding this draft. It >seems that the exact position of the Transmit, Loopback and receive >MEP/MIP in the data-plane processing is not well defined, which >could lead to unpredictable results. For example what is the >expected behavior for Transmit, Receive and Loopback points: > >- Transmit Before or after Ingress policing? >- Transmit and Loopback before or after Queuing/shaping? >- Loopback Before or after forwarding (Label Switching)? >- Loopback at Ingress Port (Down-MEP) or Egress port (Up-MEP)? >- Loopback before TTL decrement or after TTL decrement? >- Loopback before or after LSP termination at LSP terminating MEP? >- Loopback or not loopback ACH messages at terminating MEP? >- loopback or not Loopback VCCV messages at terminating MEP? >- loopback or not Loopback LSP OAM messages (such as BFD) with IP >address = 127/8 at terminating MEP? >- loopback or not Loopback LSP-Ping messages not defined in this draft? > >And many similar questions. I would appreciate the authors response >and clarification. > >Thanks >Shahram > > > > > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >Of Loa Andersson >Sent: Monday, August 15, 2011 12:32 PM >To: mpls@ietf.org; mpls-chairs@tools.ietf.org; MPLS-TP ad hoc team; >pwe3@ietf.org; CCAMP >Subject: [mpls] MPLS working group last call on >draft-ietf-mpls-tp-li-lb-03.txt > >Working Group, > >this is to start a working group last call on >draft-ietf-mpls-tp-li-lb-03.txt > >Please send your comments to the mpls working group mailing list. > >This last call ends on August 26th 2011. > >Loa >for the mpls wg co-charirs > >-- > > >Loa Andersson email: loa.andersson@ericsson.com >Sr Strategy and Standards Manager loa@pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From loa@pi.nu Sun Aug 28 01:41: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 C2E6121F84FB; Sun, 28 Aug 2011 01:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO9xrE7orOce; Sun, 28 Aug 2011 01:41:13 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 241E021F84F9; Sun, 28 Aug 2011 01:41:12 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id AEBD72A8001; Sun, 28 Aug 2011 10:42:31 +0200 (CEST) Message-ID: <4E59FF78.1070001@pi.nu> Date: Sun, 28 Aug 2011 10:42:32 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , MPLS-TP ad hoc team , pwe3@ietf.org, CCAMP , draft-ietf-mpls-tp-li-lb@tools.ietf.org References: <4E497423.8030001@pi.nu> In-Reply-To: <4E497423.8030001@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PWE3] [CCAMP] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.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: Sun, 28 Aug 2011 08:41:13 -0000 Working Group, this last call has ended! There has been comments can the authors please address comments and publish a new version of the draft. /Loa On 2011-08-15 21:31, Loa Andersson wrote: > Working Group, > > this is to start a working group last call on > draft-ietf-mpls-tp-li-lb-03.txt > > Please send your comments to the mpls working group mailing list. > > This last call ends on August 26th 2011. > > Loa > for the mpls wg co-charirs > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From iesg-secretary@ietf.org Mon Aug 29 10:47:18 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 01E7A21F8B79; Mon, 29 Aug 2011 10:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEbbY1CaKgQb; Mon, 29 Aug 2011 10:47:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F238021F8B7F; Mon, 29 Aug 2011 10:47:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110829174716.19570.6682.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2011 10:47:16 -0700 Cc: pwe3 mailing list , pwe3 chair , RFC Editor Subject: [PWE3] Protocol Action: 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network' to Proposed Standard (draft-ietf-pwe3-fat-pw-07.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, 29 Aug 2011 17:47:18 -0000 The IESG has approved the following document: - 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network' (draft-ietf-pwe3-fat-pw-07.txt) as a Proposed Standard This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/ Technical Summary Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on MPLS label stacks and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. Working Group Summary The WG process was smooth. An IPR disclosure was made after this document had completed IETF last call. A new IETF last call was immediately made specifically calling out the IPR disclosure as the reason. The last call announcment was copied to the PWE3 working group mailing list. No comments of any type were received during the second last call. Document Quality There are no concerns with document quality. Personnel Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd. Adrian Farrel (adrian@olddog.co.uk) is the responsible AD. RFC Editor Note Section 1.1 OLD A similar design for general MPLS use has also been proposed [I-D.kompella-mpls-entropy-label], Section 9. NEW A similar design for general MPLS use has also been proposed [I-D.kompella-mpls-entropy-label], see Section 9 of this document. END Section 1.2 s/it will always be will preceded/it will always be preceded/ Section 1.2 OLD This can be prevented by setting the flow LSE TTL to 1, thereby forcing the packet to be discarded by the forwarder. Note that this may be a departure from considerations that apply to the general MPLS case. NEW This can be prevented by setting the flow LSE TTL to 1, thereby forcing the packet to be discarded by the forwarder. Note that setting the TTL to 1 regardless of the payload may be considered a departure from the TTL procedures defined in [RFC3032] that apply to the general MPLS case. END Section 1.2 OLD This document does not define a use for the TC bits (formerly known as the EXP bits) in the flow label. Future documents may define a use for these bits, therefore implementations conforming to this specification MUST set the TC bits to zero at the ingress and MUST ignore them at the egress. NEW This document does not define a use for the TC field [RFC5462] (formerly known as the EXP bits [RFC3032]) in the flow label. Future documents may define a use for these bits, therefore implementations conforming to this specification MUST set the TC field to zero at the ingress and MUST ignore them at the egress. END Section 2 OLD it is required that the NSP NEW it is REQUIRED that the NSP END Section 4 OLD The absence of a FL Sub-TLV indicates that the PE is unable to process flow labels. A PE that is using PW signalling and that does not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. A PE that is using PW signalling and which does not receive a FL Sub- TLV from its peer MUST NOT include a flow label in the PW packet. This preserves backwards compatibility with existing PW specifications. NEW The absence of a FL Sub-TLV indicates that the PE is unable to process flow labels. An ingress PE that is using PW signalling and that does not send a FL Sub-TLV MUST NOT include a flow label in the PW packet. An ingress PE that is using PW signalling and which does not receive a FL Sub-TLV from its egress peer MUST NOT include a flow label in the PW packet. This preserves backwards compatibility with existing PW specifications. END Section 4.1 OLD o FL (value 0x17) is the flow label sub-TLV identifier assigned by IANA (seeSection 11 ). NEW o FL (value 0x17) is the flow label indicator sub-TLV identifier assigned by IANA (see Section 11). END OLD 7. OAM NEW 7. Operations, Administration, and Maintenance (OAM) END Section 7 OLD +-------------------------------+ | | | VCCV Message | n octets | | +-------------------------------+ | Optional Control Word | 4 octets +-------------------------------+ | Flow label | 4 octets +-------------------------------+ | PW label | 4 octets +-------------------------------+ | Router Alert label | 4 octets +-------------------------------+ | MPLS Tunnel label(s) | n*4 octets (four octets per label) +-------------------------------+ Figure 4: Use of Router Alert Label NEW +-------------------------------+ | | | VCCV Message | n octets | | +-------------------------------+ | Optional Control Word | 4 octets +-------------------------------+ | Flow LSE | 4 octets +-------------------------------+ | PW LSE | 4 octets +-------------------------------+ | Router Alert LSE | 4 octets +-------------------------------+ | MPLS Tunnel LSE(s) | n*4 octets (four octets per label) +-------------------------------+ Figure 4: Use of Router Alert Label END Section 8.5 Final line. Delete "In a" Section 11 first paragraph NEW IANA maintains the "Pseudowire Name Spaces (PWE3)" with sub-registry "Pseudowire Interface Parameters Sub-TLV type Registry". IANA has made an early allocation from this registry for the Flow Label indicator sub-TLV type. END Section 12 OLD The congestion considerations applicable to PWs as described in [RFC3985] and any additional congestion considerations developed at the time of publication apply to this design. NEW The congestion considerations applicable to PWs as described in [RFC3985] apply to this design. END Authors' Addresses OLD Email: Alcatel-Lucent vach.kompella@alcatel-lucent.com NEW Email: vach.kompella@alcatel-lucent.com END OLD Email: joe.regan@alcatel-lucent.comRegan NEW Email: joe.regan@alcatel-lucent.com END IANA Note Please note that the registry used is under the Expert Review allocation policy. One of the designated experts is Stewart Bryant who is principal editor of this document. Please use the alternate expert, Danny McPherson. From stbryant@cisco.com Tue Aug 30 05:12: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 B590F21F886F; Tue, 30 Aug 2011 05:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.536 X-Spam-Level: X-Spam-Status: No, score=-110.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zs3sVAMARYdp; Tue, 30 Aug 2011 05:12:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A6DBF21F88B6; Tue, 30 Aug 2011 05:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=6177; q=dns/txt; s=iport; t=1314706429; x=1315916029; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=OtYsUzWPDxGRQGlA9Lk6/Ma6pr5AMyMkIn1EaymvlUw=; b=iGyebGz6yq+NLkg5QCUbbDGwhXurQk4cFCmizpbHJp+i7GuE35g4wIt6 ili15A1hYPDW61KPaD7tghZH4gN9ln9M95c56hr4jgNMBw2Hh2HkBwdDn E9P5CYVehxeg1NNxESl/zKQGB0a+VD2ajn3yzmZSh6TfQn+rzdnNXXPup 8=; X-IronPort-AV: E=Sophos;i="4.68,302,1312156800"; d="scan'208,217";a="113203816" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2011 12:13:37 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7UCDbuu009669; Tue, 30 Aug 2011 12:13:37 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p7UC4lu1011120; Tue, 30 Aug 2011 13:04:47 +0100 (BST) Message-ID: <4E5CD1DF.90702@cisco.com> Date: Tue, 30 Aug 2011 13:04:47 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Luca Martini , IETF Discussion References: , , <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> <4E4EC4D2.3070603@cisco.com> In-Reply-To: <4E4EC4D2.3070603@cisco.com> Content-Type: multipart/alternative; boundary="------------020208080607020801080801" Cc: "ietf@ietf.org" , Vladimir Kleiner , "mpls@ietf.org" , Idan Kaspit , Mishael Wexler , pwe3 , "iesg@ietf.org" , Oren Gal , John Shirron , "pwe3-chairs@tools.ietf.org" , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 12:12:23 -0000 This is a multi-part message in MIME format. --------------020208080607020801080801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be resolved in any PWE3 draft that describes the use of the GAL. To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 ======== -Section 4.2 . (GAL Applicability and Usage) in [RFC5586 ], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. ===== should be replaced by ===== -Section 4.2 . (GAL Applicability and Usage) in [RFC5586 ], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. ====== - Stewart --------------020208080607020801080801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    Reviewing this discussion there are three components.

    1) The update of RFC5586 to allow PW to use the GAL.
    2) The PW OAM application that is to use the GAL.
    3) The label stack structure when  teh GAL is used with a PW

    This draft is only concerned with point 1 above. Points
    2 and 3 need to be resolved in any PWE3 draft that describes
    the use of the GAL.

    To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01

    ========
 -  Section 4.2. (GAL Applicability and Usage) in [RFC5586], the
      original text:

          In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
          LSPs, Concatenated Segments of LSPs, and with Sections, and
          MUST NOT be used with PWs. It MUST always be at the bottom of
          the label stack (i.e., S bit set to 1). However, in other MPLS
          environments, this document places no restrictions on where
          the GAL may appear within the label stack or its use with PWs.

      is replaced by:

          In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
          LSPs, Concatenated Segments of LSPs, and with Sections, and
          MAY be used with PWs. It MUST always be at the bottom of the
          label stack (i.e., S bit set to 1). However, in other MPLS
          environments, this document places no restrictions on where
          the GAL may appear within the label stack.
    =====

    should be replaced by

    =====

     -  Section 4.2. (GAL Applicability and Usage) in [RFC5586], the
      original text:

          In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
          LSPs, Concatenated Segments of LSPs, and with Sections, and
          MUST NOT be used with PWs. It MUST always be at the bottom of
          the label stack (i.e., S bit set to 1). However, in other MPLS
          environments, this document places no restrictions on where
          the GAL may appear within the label stack or its use with PWs.

      is replaced by:

          In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
          LSPs, Concatenated Segments of LSPs, and with Sections, and
          MAY be used with PWs. The presence of a GAL indicates that
          an ACH immediately follows the MPLS label stack.
    ======

    - Stewart
    --------------020208080607020801080801-- From Alexander.Vainshtein@ecitele.com Tue Aug 30 05:20: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 DBA5221F8B7A for ; Tue, 30 Aug 2011 05:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05-vNEIbxhiD for ; Tue, 30 Aug 2011 05:20:38 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id BF47921F8B74 for ; Tue, 30 Aug 2011 05:20:37 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1314706897!40762545!3 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.3.6; banners=-,-,- Received: (qmail 10878 invoked from network); 30 Aug 2011 12:21:48 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-4.tower-27.messagelabs.com with SMTP; 30 Aug 2011 12:21:48 -0000 X-AuditID: 93eaf2e7-b7be0ae000003a75-e1-4e5cd5e075ca Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 75.63.14965.0E5DC5E4; Tue, 30 Aug 2011 15:21:52 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 30 Aug 2011 15:22:01 +0300 From: Alexander Vainshtein To: "stbryant@cisco.com" Date: Tue, 30 Aug 2011 15:22:00 +0300 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxnDkCbya80tx8hTnaiki2IohjPNgAAGCAA Message-ID: References: , , <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> <4E4EC4D2.3070603@cisco.com> <4E5CD1DF.90702@cisco.com> In-Reply-To: <4E5CD1DF.90702@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_A3C5DF08D38B6049839A6F553B331C760111EFB651BFILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLsWRmVeSWpSXmKPExsUy+dWnL7oPrsb4GSx5pWsx489EZotnG+ez WMy562zx/M5fdotbS1eyWrSvPcti0fdpC4vFuadzGB04PKb83sjqsWTJTyaP601X2T2+XP7M FsAS1cBok5iXl1+SWJKqkJJanGyrFFCUWZaYXKmkkJliq2SopFCQk5icmpuaV2KrlFhQkJqX omTHpYABbIDKMvMUUvOS81My89JtlTyD/XUtLEwtdQ2V7NSUDY2tuUIyMosVUnVzEzNzFHJT i4sT01MVgCIJW5gz/jx5x1bQ0sBYcb/XqIFxQkEXIyeHhICJxMKlV5ggbDGJC/fWs3UxcnEI CexnlDh06CgLhDONUeLp8w5mkCo2AVuJTavvsoHYIgK6ErM33GAEKWIWaGCRuDh/LliCRUBV 4mYjSIKTQ1ggQOLCsmZWiIZAidbTj4DiHEC2kcSJRy4gYV6g8ItVm8FKhAR6WSS+XQ4HsTkF 1CVmX34Edh0j0HXfT60Bs5kFxCVuPZkPdbWAxJI955khbFGJl4//sULUi0rcaV/PCFGfL7Fj cSMbxC5BiZMzn7BA1EtKHFxxg2UCo9gsJGNnIWmZhaQFIq4jsWD3JzYIW1ti2cLXzDD2mQOP mZDFFzCyr2IUzcwpKEnKTTcw1EtNzixJzUnVS87P3cQISWPPdzD+mq9yiFGAg1GJh/fEt2g/ IdbEsuLK3EOMkhxMSqK8Nldi/IT4kvJTKjMSizPii0pzUosPMUpwMCuJ8K5YBZTjTUmsrEot yodJuQIDfyKzFHdyPjA155XEGxsY4OYoifM+TX7jKySQDkya2ampBalFMHNkODiUJHgNgTlA SLAoNT21Ii0zpwQhzcTBCXIGD9AZuiA1vMUFibnFmekQ+VOMilLivPYgCQGQREZpHlwvKHfV /////xWjONDTwrx6IFU8wLwH1/0KaDAT0OBLhtEgg4HZBi4l1cAoMPmyUJfbilrGMqf8RbIX Smb/nqCcvd5irndE9cJfQoteCm+uK1JRLTwpzR1q95WxN+agnlvel/rumd0fn3nevZTmUDBd rH6Bs7L1Brb8xz9+tniEOtlN4+k3mbjuwSnr9fHTozsC52iGrDLwPTmzzsRwp/aaZoZfmTLH LVaxHj5y0uWI0RElluKMREMt5qLiRAAaqfI+OAQAAA== Cc: IETF Discussion , "pwe3-chairs@tools.ietf.org" , Vladimir Kleiner , "mpls@ietf.org" , Luca Martini , Idan Kaspit , Mishael Wexler , pwe3 , "iesg@ietf.org" , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-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, 30 Aug 2011 12:20:41 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EFB651BFILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Stewart, I believe that your item #1 is presumably addressed by draft-ietf-pwe3-gal-i= n-pw (with the changes you've proposed), draft-nadeau-pwe3-vccv-2 is an atte= mpt to address your item #2, and your item #3 is not yet addressed. Is this= understanding correct? I also think that one of the items in the discussion was the restriction on= ECMP in MPLS to skip reserved labels. I am not sure if it has been properly= addressed anywhere, so should not it constitute item #4? Regards, Sasha From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Tuesday, August 30, 2011 3:05 PM To: Luca Martini; IETF Discussion Cc: John E Drake; mpls@ietf.org; Alexander Vainshtein; ietf@ietf.org; Vladim= ir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem= Cohen; pwe3-chairs@tools.ietf.org; iesg@ietf.org Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be resolved in any PWE3 draft that describes the use of the GAL. To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 =3D=3D=3D=3D=3D=3D=3D=3D - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. =3D=3D=3D=3D=3D should be replaced by =3D=3D=3D=3D=3D - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. =3D=3D=3D=3D=3D=3D - Stewart 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_A3C5DF08D38B6049839A6F553B331C760111EFB651BFILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

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

    I believe that= your item #1 is presumably addressed by draft-ietf-pwe3-gal-in-pw (with the= changes you’ve proposed), draft-nadeau-pwe3-vccv-2 is an attempt to a= ddress your item #2, and your item #3 is not yet addressed.  Is this un= derstanding correct?

    =  

    I also think that one of t= he items in the discussion was the restriction on ECMP in MPLS to skip reser= ved labels. I am not sure if it has been properly addressed anywhere, so sho= uld not it constitute item #4?

     

    Regards,=

         Sasha

     

    From: Stewart Bryant [mailto:stbryant@cisco.com]
    Sent: Tuesday, A= ugust 30, 2011 3:05 PM
    To: Luca Martini; IETF Discussion
    Cc:= John E Drake; mpls@ietf.org; Alexander Vainshtein; ietf@ietf.org; Vladi= mir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rote= m Cohen; pwe3-chairs@tools.ietf.org; iesg@ietf.org
    Subject: Re: [m= pls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

     


    Reviewing this discussion there a= re three components.

    1) The update of RFC5586 to allow PW to use the= GAL.
    2) The PW OAM application that is to use the GAL.
    3) The label= stack structure when  teh GAL is used with a PW

    This draft is o= nly concerned with point 1 above. Points
    2 and 3 need to be resolved in a= ny PWE3 draft that describes
    the use of the GAL.

    To that end the t= ext in draft-ietf-pwe3-mpls-tp-gal-in-pw-01

    =3D=3D=3D=3D=
=3D=3D=3D=3D
     -  Section 4.2.=
 (GAL Applicability and Usage) in [RFC5586], th=
e
          original text:
     
         &nbs=
p;    In MPLS-TP, the GAL MUST be used with packets on a G-AC=
h on
            &n=
bsp; LSPs, Concatenated Segments of LSPs, and with Sections, and<=
/pre>
              MUST NOT be=
 used with PWs. It MUST always be at the bottom of
    &nbs=
p;         the label stack (i.e., S=
 bit set to 1). However, in other MPLS
      &nbs=
p;       environments, this document places no=
 restrictions on where
         &n=
bsp;    the GAL may appear within the label stack or its use=
 with PWs.
     
      &nbs=
p;   is replaced by:
     
    <=
pre>          In MPLS-TP, the G=
AL MUST be used with packets on a G-ACh on
      =
        LSPs, Concatenated Segments of LS=
Ps, and with Sections, and
        &nbs=
p;     MAY be used with PWs. It MUST always be at the bo=
ttom of the
           &=
nbsp;  label stack (i.e., S bit set to 1). However, in other MPLS<=
/o:p>
              envir=
onments, this document places no restrictions on where
    =
          the GAL may appear wi=
thin the label stack.

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

    should be replaced by

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

     -  Section 4.2. (GAL Ap=
plicability and Usage) in [RFC5586], the
          original text:
     
           =
   In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
              LSP=
s, Concatenated Segments of LSPs, and with Sections, and
              MUST NOT be used wi=
th PWs. It MUST always be at the bottom of
      =
        the label stack (i.e., S bit set=
 to 1). However, in other MPLS
        =
      environments, this document places no restric=
tions on where
          &nbs=
p;   the GAL may appear within the label stack or its use with PWs=
.
     
        &=
nbsp; is replaced by:
     
     =
;         In MPLS-TP, the GAL MUST b=
e used with packets on a G-ACh on
       &nb=
sp;      LSPs, Concatenated Segments of LSPs, and w=
ith Sections, and
          &=
nbsp;   MAY be used with PWs. The presence of a GAL indicates that=

             =
 an ACH immediately follows the MPLS label stack. 
    =3D=3D=3D=3D=3D=3D

    - Stewart

    <= /div>

    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_A3C5DF08D38B6049839A6F553B331C760111EFB651BFILPTMAIL02e_-- From stbryant@cisco.com Tue Aug 30 06:12: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 0C30D21F8B25; Tue, 30 Aug 2011 06:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.538 X-Spam-Level: X-Spam-Status: No, score=-110.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGQc083XeGY1; Tue, 30 Aug 2011 06:12:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AEE7121F8B21; Tue, 30 Aug 2011 06:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=904; q=dns/txt; s=iport; t=1314710008; x=1315919608; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zMuYBXQ4OFsHFdfZkiCCKVVAd9Dj0Gc1bRjtRrx/57k=; b=hzt5rTb1cFXsd0v/gtjZFiJEa23Zdw2F7mV7xBV5pghs8wZtBihk+o5Q gStmGQZiR8zLGRL5hQi0WcpPFGWbVcr5m2oSeRwdRWZpfaVUBruINmc2t kXKWowHlxKOIkvoMiP1NUHGQltEYkkmfVcUJ7K/dffl+VLkCtmRz48coh w=; X-IronPort-AV: E=Sophos;i="4.68,302,1312156800"; d="scan'208";a="113214001" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2011 13:13:25 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7UDDMUC011810; Tue, 30 Aug 2011 13:13:25 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p7UDDKJ7014717; Tue, 30 Aug 2011 14:13:20 +0100 (BST) Message-ID: <4E5CE1F0.6040701@cisco.com> Date: Tue, 30 Aug 2011 14:13:20 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Alexander Vainshtein References: , , <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> <4E4EC4D2.3070603@cisco.com> <4E5CD1DF.90702@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF Discussion , "pwe3-chairs@tools.ietf.org" , Vladimir Kleiner , "mpls@ietf.org" , Luca Martini , Idan Kaspit , Mishael Wexler , pwe3 , "iesg@ietf.org" , Oren Gal , John Shirron , Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 13:12:01 -0000 Sasha On 30/08/2011 13:22, Alexander Vainshtein wrote: > > Stewart, > > I believe that your item #1 is presumably addressed by > draft-ietf-pwe3-gal-in-pw (with the changes you’ve proposed), > draft-nadeau-pwe3-vccv-2 is an attempt to address your item #2, and > your item #3 is not yet addressed. Is this understanding correct? > Yes > > I also think that one of the items in the discussion was the > restriction on ECMP in MPLS to skip reserved labels. I am not sure if > it has been properly addressed anywhere, so should not it constitute > item #4? > Yes-ish, here I am concerned about the practical ability to do that given the extent of deployed LSRs that do not do that. My point here was to note the scope of this draft (which is is IESG review). Other drafts need to make their own case for what they want to do and how they propose to do it. Stewart

    On = Tue, Aug 16, 2011 at 5:24 PM, Shahram Davari <davari@broadcom.com> wrote:

    Pablo,

    =A0

    This = is not acceptable. Are you suggesting an LSR to pop a label that is not to = of the stack? I can assure you 99.99% of HW out there can=92t do this.

    =A0

    Thx

    SD

    =A0

    From: mpls-bounces@ietf.org [mailto:mpls-= bounces@ietf.org] On Behalf Of Pablo Frank
    Sent: Tuesday, August 16, 2011 2:18 PM
    To: Alexander Vains= htein
    Cc: mpls= @ietf.org; ietf@ietf= .org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; Jo= hn Shirron; Rotem Cohen
    Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3= -gal-in-pw

    =A0<= u>

    I think it's okay because as the PW cr= osses the ECMP-enabled IP/MPLS domain in the middle segment, you're no = longer in an MPLS-TP environment and so the GAL is not required to be BOS. = =A0During that middle segment, the PW flow label would be placed below the = GAL and above the GACh. =A0It gets removed when it hits the S-PE that switc= hes you back into the MPLS-TP environment. =A0In other words, whether you&#= 39;re in an MPLS-TP environment is determined segment by segment in a MS-PW= .

    =A0

    Pablo

    On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein <Alexand= er.Vainshtein@ecitele.com> wrote:

    Hi all,

    After having sent out my comments I've noticed that the speci= fic example to illustrate the need to combine GAL and "flow label"= ; was inaccurate.

    =A0=

    A more relevant example would look like following (I do not include a dia= gram, but it can be easily provided if necessary)

    1. A MS-PW:
      • Starts at an S-PE th= at resides at the edge of an MPLS-TP domain (no ECMP)
      • Crosses this domain and enter= s an IP/MPLS domain with ECMP enabled using a T-PE that resides at the age = of these two domains
      • Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-PE) =
      • Terminates on= another S-PE at=A0the edge of the 2nd MPLS-TP domain
    1. The operator intends to improve traffic distribution in the IP/MPLS doma= in, hence he enables=A0insertion and discard of "flow labels" at = the two S-PEs. Note that:
      • This does not violate the MPLS-TP restriction on ECM= P: ECMP does not happen in he MPLS-TP domains
      • T-PEs do not even have to be aware of flow labels
      1. The operator also intends to operate some end-to-end OAM for this MS-PW us= ing "GAL-in-PW". This results in a conflict since both GAL and &q= uot;flow label" are defined (in the=A0corresponding drafts) as bottom = of stack.

      =A0

      IMHO this describes a realisti= c scenario where the two drafts are in controversy.

      =A0

      Rega= rds,

      =A0=A0=A0=A0 Sasha

      From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Alexa= nder Vainshtein [Alexander.Vainshtein@ecitele.com]
      Sent: Tuesday, August 16, 2011 4:26 PM
      To: ietf@ietf.org
      Cc: mpls@ietf.org; Vladimir Kle= iner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohe= n
      Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw<= /span>

      =

      Hi all,

      =A0=

      I would like to rais= e the following issue with regard to draft-ietf-pwe3-gal-in-pw: controversy vs. draft-ietf-pwe3-fat-pw with regard to bottom-of-stack position.=

      =A0=

      As stated in the Int= roduction, this draft removes the restriction imposed by RFC 5586 on usage = of Generic Associated Channel Label (GAL) in PWs. The corresponding text Se= ction 4.2 of RFC 5586 states:

      = In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatena= ted Segments of LSPs, and with Sections, and MUST NOT be used with PWs.=A0 = It MUST always be at the bottom of the label stack =A0=A0=A0(i.e., S bit se= t to 1).

      =A0=

      draft-ietf-pwe3-gal-= in-pw proposed to replace the original text in RFC 5586 with the following<= u>

      =A0=

      In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Conca= tenated Segments of LSPs, and with Sections, and MAY be used with PWs. It M= UST always be at the bottom of the label stack (i.e., S bit set to 1).

      =A0

      I.e., =A0while removing this restrict= ion of 5586, it does not modify its requirement for the GAL being always at= the bottom of the label stack.

      =A0

      At the same draft-ietf-pwe3-fat-pw (c= urrently also in the IESG review) reserves the bottom of the PW stack for t= he PW flow labels, e.g., in Section 1.1:

      =A0

      This document describes a method of adding= an additional label stack entry (LSE) at the bottom of stack in order to f= acilitate the load balancing of the flows within a PW over the available EC= MPs.=A0

      =A0

      One could argue that draft-ietf-pwe3-= gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-TP does not us= e ECMP. IMHO and FWIW,

      such an argument, were it presented, would be highly problematic, beca= use:

      =A0

      1.=A0=A0=A0=A0=A0=A0 RF= C 5960 (which defines the MPLS-TP data plane) did not define any difference= s between the PW data plane in IP/MPLS and MPLS-TP.

      2.=A0=A0=A0=A0=A0=A0 One of the most popular scenarios for using multi-segment = pseudowires is the case when an edge-to-edge service emulation crosses mult= iple IP/MPLS and MPLS-TP domains. In these scenarios, the flow label of dra= ft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPL= S domain) would potentially compete with GAL (inserted by a T-PE at the edg= e of an MPLS-TP domain, e.g., for relying a PW status message that it has r= eceived over a Targeted LDP session from the IP/MPLS domain to a static PW = status message to cross the MPLS-TP domain) for the bottom-of-stack positio= n.

      =A0

      The issue I am raising Is not new. It= has been actively discussed on the PWE3 mailing list with regard to adopti= on of draft-nadeau-pwe3-vccv-2 as a WG document, with arguments =A0for both= the flow label and GAL taking the bottom-of-the-stack position. But, to th= e best of my understanding, consensus on this issue has not been reached.

      =A0

      Hopefully this comment will be useful.

      =A0

      Regards,

      =A0=A0=A0=A0 Sasha=

      =A0

      This e-mail message is intended for the recipient only an= d contains information which is CONFIDENTIAL and which may be proprietary t= o ECI Telecom. If you have received this transmission in error, please info= rm 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 c= ontains information which is CONFIDENTIAL and which may be proprietary to E= CI 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 the= reof.


    ___________= ____________________________________
    pwe3 mailing list
    pwe3@ietf.org
    https://www.ietf.or= g/mailman/listinfo/pwe3

    =A0