Subject: [PWE3] GAL above and below the PW label

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 30 Mar 2011 10:36:48 +0200

Tom, Luca and all,
I would like to clarify - again - my position regarding GAL above the PW label.
I think that, other issues notwithstanding, it would create an issue if used with MS-PWs:

*         GAL would be exposed at each S-PE (making a presumably end-to-end OAM message to be intercepted)

*         What is even worse, there is no rule for forwarding the packet that has been intercepted due to an exposed GAL (until you count the statement in 5586 requesting that a packet MUST NOT be ever forwarded based on GAL:)).  Hence it would be perfectly valid just to drop such a packet at the first S-PE it crosses...
This said, I still  do not think using GAL below the PW label is a good idea either. But this is a different story...

Regards,
     Sasha

---

From: Loa Andersson <[email-masked]>
Date: Wed, 30 Mar 2011 10:44:25 +0200

Sasha,

what do you mean with "exposed" I thought that what is gpoing on
in an S-PE is normal MPLS label switching.

/Loa

On 2011-03-30 10:36, Alexander Vainshtein wrote:
> Tom, Luca and all,
>
> I would like to clarify – again – my position regarding GAL above the PW
> label.
>
> ·GAL would be exposed at each S-PE (making a presumably end-to-end OAM
> message to be intercepted)
>
> ·What is even worse, there is no rule for forwarding the packet that has
> been intercepted due to an exposed GAL (until you count the statement in
> 5586 requesting that a packet MUST NOT be ever forwarded based on GALJ).
> Hence it would be perfectly valid just to drop such a packet at the
> first S-PE it crosses…
>
> This said, I still do not think using GAL below the PW label is a good
> idea either. But this is a different story…
>
> Regards,
>
> Sasha
>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 30 Mar 2011 01:51:40 -0700

When ms-pw ping is performed, the packet should not be processed at S-PE, unless the PW label ttl is expired. With the proposed GAL label above PW label, how do you ensure the OAM packet take the same data path to reach far-end T-PE, without getting processed/punted at S-PE? Or for that matter go beyond first S-PE?

-sam

Sent from my iPad

---

From: "Daniel Cohn" <[email-masked]>
Date: Wed, 30 Mar 2011 10:52:15 +0200

Hi,

Why would S-PE look beyond PW label if TTL has not expired?

DC

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexander Vainshtein
Sent: Wednesday, March 30, 2011 10:37 AM
To: Thomas Nadeau; Luca Martini
Cc: pwe3
Subject: [PWE3] GAL above and below the PW label

Tom, Luca and all,

I would like to clarify - again - my position regarding GAL above the PW
label.

I think that, other issues notwithstanding, it would create an issue if
used with MS-PWs:

*         GAL would be exposed at each S-PE (making a presumably
end-to-end OAM message to be intercepted)

*         What is even worse, there is no rule for forwarding the packet
that has been intercepted due to an exposed GAL (until you count the
statement in 5586 requesting that a packet MUST NOT be ever forwarded
based on GALJ).  Hence it would be perfectly valid just to drop such a
packet at the first S-PE it crosses...

This said, I still  do not think using GAL below the PW label is a good
idea either. But this is a different story...

Regards,

     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 30 Mar 2011 10:51:59 +0200

Loa,
The VCCV Type 4 draft (http://tools.ietf.org/html/draft-nadeau-pwe3-vccv-2) proposed having the GAL above the PW label and ACH header below it.

I include the relevant fragment of the draft below:
<quote>
3. VCCV Control Channel When The Control Word is Not Used

   When the PWE3 Control Word is not used a new CC Type 4 is defined
as follows.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              GAL                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            PW Label                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version|   Reserved    |  Associated Channel Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        VCCV Message Body                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<end quote>

If this occurs happens in the MS-PW scenario, GAL would be exposed at the first S-PE that happens to receive the packet (because the tunnel label is terminated at S-PE).  

Hopefully this clarifies my concern.

Regards,
     Sasha

> -----Original Message-----
> Loa Andersson
> Sent: Wednesday, March 30, 2011 10:44 AM
> To: [email-masked]
> Subject: Re: [PWE3] GAL above and below the PW label
> 
> Sasha,
> 
> > *GAL would be exposed at each S-PE (making a presumably end-to-end
> OAM
> > *What is even worse, there is no rule for forwarding the packet that
> has
> > first S-PE it crosses...

---

From: David Allan I <[email-masked]>
Date: Wed, 30 Mar 2011 04:52:18 -0400

It does become a new behavior, GAL with S=0. However the combination of GAL being top label at the S-PE and TTL being encoded in the PW label means that fate sharing is broken at every S-PE. Life only gets a little more strange if there is a FAT label as well...

That being said, GAL as bottom label is broken in any ECMP environment, which is why GAL is a TP construct.

my 2 cents
D

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, March 30, 2011 10:37 AM
To: Thomas Nadeau; Luca Martini
Cc: pwe3
Subject: [PWE3] GAL above and below the PW label

Tom, Luca and all,

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 30 Mar 2011 10:56:34 +0200

Dave,
GAL may be a TP construct, but, IMO, MS-PWs (if not the other things) will easily break the demarcation lines between TP and non-TP areas.

If we stick with GAL being an MPLS-TP construct we should, IMHO, drop the attempts to use it with Ws.

Regards,
     Sasha

From: David Allan I [mailto:[email-masked]]
Sent: Wednesday, March 30, 2011 10:52 AM
To: Alexander Vainshtein; Thomas Nadeau; Luca Martini
Cc: pwe3
Subject: RE: GAL above and below the PW label

my 2 cents
D

Regards,
     Sasha

---

From: David Allan I <[email-masked]>
Date: Wed, 30 Mar 2011 05:19:29 -0400

Well one use case is PW interworking between MPLS-TP and MPLS domains....MS-PWs over multiple domains

The choice is fate sharing with the MPLS path in ECMP and not fate sharing with the S-PE implementation OR vice versa....depending on GAL above or below

"damned if you do...damned if you don't"

So as the GAL is really a TP construct and cannot be made to work in a useful fashion for the above use case, I think I agree.

D

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, March 30, 2011 10:57 AM
To: David Allan I
Cc: pwe3; Thomas Nadeau; Luca Martini
Subject: RE: GAL above and below the PW label

Dave,

Regards,
     Sasha

my 2 cents
D

Regards,
     Sasha

---

From: Loa Andersson <[email-masked]>
Date: Wed, 30 Mar 2011 11:20:19 +0200

All,

missed a nuance in Sasha subject line.

We have two issues

- where the GAL is placed relative to the PW label, I  believe it is
   necessary to have the GAL below the PW label.

- whether the the GAL label needs to be bottom of stack or not, it
   figure that this is really a discussion if it is possible to have
   a FAT label below the GAL or not. I'm not sure  about my preferences
   but I think it is possible.

/Loa

On 2011-03-30 10:52, David Allan I wrote:
> It does become a new behavior, GAL with S=0. However the combination of
> GAL being top label at the S-PE and TTL being encoded in the PW label
> means that fate sharing is broken at every S-PE. Life only gets a little
> more strange if there is a FAT label as well...
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Alexander Vainshtein
> *Sent:* Wednesday, March 30, 2011 10:37 AM
> *To:* Thomas Nadeau; Luca Martini
> *Cc:* pwe3
> *Subject:* [PWE3] GAL above and below the PW label
>
> Tom, Luca and all,
>

--

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 30 Mar 2011 11:29:20 +0200

Loa,
My concerns have been specifically about the GAL ABOVE the PW label as specified in draft-nadeau.

Having the GAL below the PW label, or Gal above the Fat PW label are not free from their own concerns, but these would be quite different concerns:-).

Regards,
     Sasha

> Sent: Wednesday, March 30, 2011 11:20 AM
> To: [email-masked]
> > That being said, GAL as bottom label is broken in any ECMP
> environment,
> > which is why GAL is a TP construct.
> > my 2 cents
> > D
> >

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 30 Mar 2011 06:55:50 -0700

Dear Sasha,
I believe that there should not be MS-PW that crosses TP and non-TP domains.
GAL might be used in each domain under different rules. If we strongly
recommend that rule, then anyone not following it, at his/her free will and
risk, just might be shooting themselves in a foot.

Regards,
Greg

On Wed, Mar 30, 2011 at 1:56 AM, Alexander Vainshtein <
[email-masked]> wrote:

> Dave,
>
> GAL may be a TP construct, but, IMO, MS-PWs (if not the other things) will
> easily break the demarcation lines between TP and non-TP areas.
>
>
>
> *From:* David Allan I [mailto:[email-masked]]
> *Sent:* Wednesday, March 30, 2011 10:52 AM
> *To:* Alexander Vainshtein; Thomas Nadeau; Luca Martini
> *Cc:* pwe3
> *Subject:* RE: GAL above and below the PW label
>
>
>
> It does become a new behavior, GAL with S=0. However the combination of GAL
> being top label at the S-PE and TTL being encoded in the PW label means that
> fate sharing is broken at every S-PE. Life only gets a little more strange
> if there is a FAT label as well...
>
>
>
> ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Alexander Vainshtein
> ·         GAL would be exposed at each S-PE (making a presumably
> ·         What is even worse, there is no rule for forwarding the packet
> statement in 5586 requesting that a packet MUST NOT be ever forwarded based
> on GALJ).  Hence it would be perfectly valid just to drop such a packet at
> the first S-PE it crosses…
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 30 Mar 2011 16:10:29 +0200

Dear Greg,
Please see some comments inline below.

Regards,
     Sasha

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, March 30, 2011 3:56 PM
To: Alexander Vainshtein
Cc: David Allan I; pwe3; [email-masked]; Martini
Subject: Re: [PWE3] GAL above and below the PW label

Dear Sasha,
I believe that there should not be MS-PW that crosses TP and non-TP domains.
[[[Sasha]]] I do not see any technical reasons to disallow that.
GAL might be used in each domain under different rules.
[[[Sasha]]] I believe that this would violate the requirement for the common data plane of MPLS and MPLS-TP.
If we strongly recommend that rule, then anyone not following it, at his/her free will and risk, just might be shooting themselves in a foot.

Regards,
Greg
On Wed, Mar 30, 2011 at 1:56 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Dave,
GAL may be a TP construct, but, IMO, MS-PWs (if not the other things) will easily break the demarcation lines between TP and non-TP areas.

Regards,
     Sasha

From: David Allan I [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, March 30, 2011 10:52 AM
To: Alexander Vainshtein; Thomas Nadeau; Luca Martini
Cc: pwe3
Subject: RE: GAL above and below the PW label

my 2 cents
D

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alexander Vainshtein

Regards,
     Sasha

_______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 03:03:17 -0400

Loa, Dave, Sasha,

I've snipped from various posts on the thread that Sasha started.  See
inline.

In message <[email-masked]>
>    but I think it is possible.

I agree with Loa's summary.  Not putting GAL at the bottom may confuse
some LSR, but putting it above the PW label is likely to be even more
problematic.

In message <[email-masked]>
David Allan I writes:
>  
> It does become a new behavior, GAL with S=3D0. However the combination of G=
> AL being top label at the S-PE and TTL being encoded in the PW label means =
> that fate sharing is broken at every S-PE. Life only gets a little more str=
> ange if there is a FAT label as well...
>  
> That being said, GAL as bottom label is broken in any ECMP environment, whi=
> ch is why GAL is a TP construct.
>  
> my 2 cents
> D

Dave,

If GAL is broken for ECMP, which it is, then all TP OAM is broken.
If all it takes to fix it is simple then lets just fix it.

This is what we'd have to do.

  1) Relax the requirement that GAL be at the bottom

  2) Have the ingress insert GAL in the stack immediately below the
     label for which the measurement is made, keeping the rest of the
     label stack in place.

The only thing the midpoing LSR at a multipath (LAG, link bundle for
MPLS) has to do is skip over the GAL when hashing, as if the GAL
wasn't there.  That will yield the same hash value and it will
preserve fate-sharing across multipath.

I prefer that we fix things rather than complain that they are broken.

Curtis

---

From: David Allan I <[email-masked]>
Date: Thu, 31 Mar 2011 03:23:51 -0400

HI Curtis:

My suggestion is to avoid the GAL for PWs if it is to be a homogenizing agent across TP and IP/MPLS domains in the form of MS-PWs. The scenarios in which it was broken was simply a statement of fact.

As for the problem GAL was proposed to fix (lack of CW), there are solutions on the table, just not palatable...

D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Curtis Villamizar
Sent: Thursday, March 31, 2011 9:03 AM
To: Loa Andersson
Cc: [email-masked]
Subject: Re: [PWE3] GAL above and below the PW label

Loa, Dave, Sasha,

I've snipped from various posts on the thread that Sasha started.  See inline.

>    but I think it is possible.

I agree with Loa's summary.  Not putting GAL at the bottom may confuse some LSR, but putting it above the PW label is likely to be even more problematic.

David Allan I writes:
>  
> It does become a new behavior, GAL with S=3D0. However the combination 
> of G= AL being top label at the S-PE and TTL being encoded in the PW 
> label means = that fate sharing is broken at every S-PE. Life only 
> gets a little more str= ange if there is a FAT label as well...
>  
> environment, whi= ch is why GAL is a TP construct.
>  
> my 2 cents
> D

Dave,

The only thing the midpoing LSR at a multipath (LAG, link bundle for
MPLS) has to do is skip over the GAL when hashing, as if the GAL wasn't there.  That will yield the same hash value and it will preserve fate-sharing across multipath.

Curtis

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 31 Mar 2011 00:33:02 -0700

Dear Sasha,
would your argument illustrate that use of GAL with PW label not only in
MPLS-TP but in non-TP MPLS PW is strongly problematic? Should we leave RFC
5586 as is?

Regards,
Greg

On Wed, Mar 30, 2011 at 7:10 AM, Alexander Vainshtein <
[email-masked]> wrote:

> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Wednesday, March 30, 2011 3:56 PM
> *To:* Alexander Vainshtein
> *Cc:* David Allan I; pwe3; [email-masked]; Martini
> *Subject:* Re: [PWE3] GAL above and below the PW label
>
>
>
> Dear Sasha,
> *[[[Sasha]]] I do not see any technical reasons to disallow that.*
>
> *[[[Sasha]]] I believe that this would violate the requirement for the
> common data plane of MPLS and MPLS-TP.*
>
> If we strongly recommend that rule, then anyone not following it, at
> his/her free will and risk, just might be shooting themselves in a foot.
>
> Regards,
> Greg
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 31 Mar 2011 09:34:57 +0200

Dear Greg,
Yes I think we should leave 5586 "as it is" - or clean it up removing somewhat mysterious comments regarding non-TP usages.

Regards,
     Sasha

From: Greg Mirsky [mailto:[email-masked]]
Sent: Thursday, March 31, 2011 9:33 AM
To: Alexander Vainshtein
Cc: David Allan I; pwe3; Martini
Subject: Re: [PWE3] GAL above and below the PW label

Dear Sasha,
would your argument illustrate that use of GAL with PW label not only in MPLS-TP but in non-TP MPLS PW is strongly problematic? Should we leave RFC 5586 as is?

Regards,
Greg
On Wed, Mar 30, 2011 at 7:10 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Dear Greg,
Please see some comments inline below.

Regards,
     Sasha

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, March 30, 2011 3:56 PM
To: Alexander Vainshtein
Cc: David Allan I; pwe3; [email-masked]<mailto:[email-masked]>; Martini
Subject: Re: [PWE3] GAL above and below the PW label

Dear Sasha,

Regards,
Greg

Regards,
     Sasha

my 2 cents
D

Regards,
     Sasha

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 31 Mar 2011 01:08:44 -0700

All,

Just an FYI that a proposal for fate-sharing PW OAM and data given in
draft-kini-pwe3-inband-cc-offset

Just to summarize the proposal.
1. It does not require GAL in PW. TTL expiry is used to alert the S/T-PE.
2. It is mainly applicable when CW is not used in the PW.
3. It uses a fixed offset (negotiated between PW endpoints) after the
label stack before starting the OAM msg.
4. The bytes between the label-stack and the fixed offset is referred
to as a pseudoflow header and is filled with byte-values (by the PE)
that represent the flow for which OAM is desired. This helps PW OAM
and data to fate-share even when the intermediate node looks beyond
label stack to do multipath forwarding decisions.

-- 
- Sri

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 31 Mar 2011 10:15:45 +0200

Sriganesh, Curtis and all,
IMHO and FWIW I think that the only problem with VCCV Type 3 is the risk of OAM packets leaking out of T-PE towards the AC (if you accidentally set the TTL value too high). To the best of my understanding the offset proposal does not solve that - or did I miss something?

One way to solve it is to use VCCV Type 1 (clean where applicable).
Another way would be by using GAL below the PW label (possible but messy). If the industry moves towards deprecating Ethernet PWs without CW,  it becomes completely unnecessary.

My 2c,
     Sasha

> Sriganesh Kini
> Sent: Thursday, March 31, 2011 10:09 AM
> To: [email-masked]
> Cc: [email-masked]
> > In message
> <[email-masked]
> .se>
> > David Allan I writes:
> >>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 31 Mar 2011 09:20:59 +0100

> I believe that there should not be MS-PW that crosses TP and non-TP 
That diminishes the generality of the design, which would in my view be 
a bad thing.

- Stewart

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 04:51:25 -0400

In message <[email-masked]>
Greg Mirsky writes:
>  
> Dear Sasha,
>  
> I believe that there should not be MS-PW that crosses TP and non-TP
> domains.  GAL might be used in each domain under different rules. If
> we strongly recommend that rule, then anyone not following it, at

Greg,

I think you are agreeing with Sasha on this.  You are both arguing
that the same MS-PW GAL may cross MPLS and MPLS-TP LSP and needs to
use a common PW OAM encaps, not a TP PW OAM encaps in one case and a
non-PT PW OAM encaps in another.

Curtis

> > GAL may be a TP construct, but, IMO, MS-PWs (if not the other things) wil=
> l
> > It does become a new behavior, GAL with S=3D0. However the combination of=
>  GAL
> > being top label at the S-PE and TTL being encoded in the PW label means t=
> hat
> > fate sharing is broken at every S-PE. Life only gets a little more strang=
> e
> > *From:* [email-masked] [mailto:[email-masked]] *On Behalf O=
> f
> > *Alexander Vainshtein
> > I would like to clarify =96 again =96 my position regarding GAL above the=
>  PW
> > label.
> >
> > =B7         GAL would be exposed at each S-PE (making a presumably
> > =B7         What is even worse, there is no rule for forwarding the packe=
> t
> > statement in 5586 requesting that a packet MUST NOT be ever forwarded bas=
> ed
> > on GALJ).  Hence it would be perfectly valid just to drop such a packet a=
> t
> > the first S-PE it crosses=85
> >
> > idea either. But this is a different story=85
> >
> >
> >
> > Regards,
> >
> >      Sasha
> >
> >
> >
> --bcaec5014c85dc4062049fb388ce
> Content-Type: text/html; charset=windows-1252
> Content-Transfer-Encoding: quoted-printable
>  
> Dear Sasha,<br>I believe that there should not be MS-PW that crosses TP and=
>  non-TP domains. GAL might be used in each domain under different rules. If=
>  we strongly recommend that rule, then anyone not following it, at his/her =
> free will and risk, just might be shooting themselves in a foot.<br>
> <br>Regards,<br>Greg<br><br><div class=3D"gmail_quote">On Wed, Mar 30, 2011=
>  at 1:56 AM, Alexander Vainshtein <span dir=3D"ltr">&lt;<a href=3D"mailto:A=
> [email-masked]">[email-masked]</a>&gt;</=
> span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
> r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div link=3D"blue=
> " vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNormal"><span style=
> =3D"color: rgb(31, 73, 125);">Dave,</span></p>
> <p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125);">GAL may be =
> a TP construct, but, IMO, MS-PWs (if not the other things) will easily brea=
> k the demarcation lines between TP and non-TP areas.</span></p><p class=3D"=
> MsoNormal">
> <span style=3D"color: rgb(31, 73, 125);">=A0</span></p><p class=3D"MsoNorma=
> l"><span style=3D"color: rgb(31, 73, 125);">If we stick with GAL being an M=
> PLS-TP construct we should, IMHO, drop the attempts to use it with Ws.</spa=
> n></p>
> <p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125);">=A0</span><=
> /p><div><p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125);">Reg=
> ards,</span></p><p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 12=
> 5);">=A0=A0=A0=A0 Sasha</span></p>
> </div><p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125);">=A0</=
> span></p><div style=3D"border-width: medium medium medium 1.5pt; border-sty=
> le: none none none solid; border-color: -moz-use-text-color -moz-use-text-c=
> olor -moz-use-text-color blue; padding: 0cm 0cm 0cm 4pt;">
> <div><div style=3D"border-width: 1pt medium medium; border-style: solid non=
> e none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-=
> color; padding: 3pt 0cm 0cm;"><p class=3D"MsoNormal"><b><span style=3D"font=
> -size: 10pt;">From:</span></b><span style=3D"font-size: 10pt;"> David Allan=
>  I [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">=
> [email-masked]</a>] <br>
> <b>Sent:</b> Wednesday, March 30, 2011 10:52 AM<br><b>To:</b> Alexander Vai=
> nshtein; Thomas Nadeau; Luca Martini<br><b>Cc:</b> pwe3<br><b>Subject:</b> =
> RE: GAL above and below the PW label</span></p></div></div><div><div></div>
> <div class=3D"h5"><p class=3D"MsoNormal">=A0</p><p class=3D"MsoNormal"><spa=
> n style=3D"font-size: 10pt; color: blue;">It does=A0become a new behavior, =
> GAL with S=3D0. However the combination of GAL being top label at the S-PE =
> and TTL being encoded in the PW label means that fate sharing is broken at =
> every S-PE. Life only gets a little more strange if there is a FAT label as=
>  well...</span><span style=3D"font-size: 12pt; font-family: &quot;Times New=
>  Roman&quot;,&quot;serif&quot;;"></span></p>
> <p class=3D"MsoNormal"><span style=3D"font-size: 12pt; font-family: &quot;T=
> imes New Roman&quot;,&quot;serif&quot;;">=A0</span></p><p class=3D"MsoNorma=
> l"><span style=3D"font-size: 10pt; color: blue;">That being said, GAL as bo=
> ttom label is broken in any ECMP environment, which is why GAL is a TP cons=
> truct.</span><span style=3D"font-size: 12pt; font-family: &quot;Times New R=
> oman&quot;,&quot;serif&quot;;"></span></p>
> <p class=3D"MsoNormal"><span style=3D"font-size: 12pt; font-family: &quot;T=
> imes New Roman&quot;,&quot;serif&quot;;">=A0</span></p><p class=3D"MsoNorma=
> l"><span style=3D"font-size: 10pt; color: blue;">my 2 cents</span><span sty=
> le=3D"font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif=
> &quot;;"></span></p>
> <p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: blue;">D</spa=
> n><span style=3D"font-size: 12pt; font-family: &quot;Times New Roman&quot;,=
> &quot;serif&quot;;"></span></p><p class=3D"MsoNormal"><span style=3D"font-s=
> ize: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;">=A0=
> </span></p>
> <div class=3D"MsoNormal" style=3D"text-align: center;" align=3D"center"><sp=
> an style=3D"font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot=
> ;serif&quot;;"><hr width=3D"100%" align=3D"center" size=3D"2"></span></div>=
> <p class=3D"MsoNormal" style=3D"margin-bottom: 12pt;">
> <b><span style=3D"font-size: 10pt;">From:</span></b><span style=3D"font-siz=
> e: 10pt;"> <a href=3D"mailto:[email-masked]" target=3D"_blank">pwe3-=
> [email-masked]</a> [mailto:<a href=3D"mailto:[email-masked]" targe=
> t=3D"_blank">[email-masked]</a>] <b>On Behalf Of </b>Alexander Vains=
> htein<br>
> <b>Sent:</b> Wednesday, March 30, 2011 10:37 AM<br><b>To:</b> Thomas Nadeau=
> ; Luca Martini<br><b>Cc:</b> pwe3<br><b>Subject:</b> [PWE3] GAL above and b=
> elow the PW label</span><span style=3D"font-size: 12pt; font-family: &quot;=
> Times New Roman&quot;,&quot;serif&quot;;"></span></p>
> <p class=3D"MsoNormal">Tom, Luca and all,</p><p class=3D"MsoNormal">I would=
>  like to clarify =96 again =96 my position regarding GAL above the PW label=
> .</p><p class=3D"MsoNormal">I think that, other issues notwithstanding, it =
> would create an issue if used with MS-PWs:</p>
> <p><span style=3D"font-family: Symbol;">=B7</span><span style=3D"font-size:=
>  7pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;">=A0=A0=
> =A0=A0=A0=A0=A0=A0 </span>GAL would be exposed at each S-PE (making a presu=
> mably end-to-end OAM message to be intercepted)</p>
> <p><span style=3D"font-family: Symbol;">=B7</span><span style=3D"font-size:=
>  7pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;">=A0=A0=
> =A0=A0=A0=A0=A0=A0 </span>What is even worse, there is no rule for forwardi=
> ng the packet that has been intercepted due to an exposed GAL (until you co=
> unt the statement in 5586 requesting that a packet MUST NOT be ever forward=
> ed based on GAL<span style=3D"font-family: Wingdings;">J</span>).=A0 Hence =
> it would be perfectly valid just to drop such a packet at the first S-PE it=
>  crosses=85</p>
> <p class=3D"MsoNormal">This said, I still=A0 do not think using GAL below t=
> he PW label is a good idea either. But this is a different story=85</p><p c=
> lass=3D"MsoNormal">=A0</p><p class=3D"MsoNormal">Regards,</p><p class=3D"Ms=
> oNormal">=A0=A0=A0=A0 Sasha</p>
> <p class=3D"MsoNormal">=A0</p></div></div></div></div></div><br>___________=
> ____________________________________<br>
> pwe3 mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/pwe3" target=3D"_blank">ht=
> tps://www.ietf.org/mailman/listinfo/pwe3</a><br>
> <br></blockquote></div><br>
>  
> --bcaec5014c85dc4062049fb388ce--
>  
> --===============0069009002==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>  
> --===============0069009002==--

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 05:02:09 -0400

In message <[email-masked]>
Greg Mirsky writes:

> domains.

Oops.  I missed the "not".  I agree with Sasha, that this violates the
"one data plane" requirement.

Reality is that the core in any major provider packet netowrk today is
MPLS and will remain MPLS.  It may be MPLS carrying TP if we move
forward with work that will support that.  OTOH, if TP advocates keep
trying to make sure that MPLS and MPLS-TP are as incompatible as
possible, then they may be effectively killing TP.

Restricting MS-PW to use MPLS on all segments or MPLS-TP on all
segments but not both should *not* be a goal.  Allowing some segments
of a MS-PW to be MPLS an other segments to be MPLS-TP should be an
explicit goal.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 05:10:37 -0400

In message <[email-masked]>
David Allan I writes:
>  
> HI Curtis:
>  
> My suggestion is to avoid the GAL for PWs if it is to be a
> homogenizing agent across TP and IP/MPLS domains in the form of
> MS-PWs. The scenarios in which it was broken was simply a statement of
> fact.
>  
> As for the problem GAL was proposed to fix (lack of CW), there are
> solutions on the table, just not palatable...
>  
> D

Dave,

I think we are in agreement.

We either use a non-GAL mechanism, or we fix GAL by removing the
bottom of stack restriction and use GAL.

I prefer the latter option, fix GAL.

I support not using GAL at all in PW if GAL can't be fixed.

Fixing GAL should really be an MPLS WG discussion.  The result of that
discussion in MPLS should gate whether any PW proposal to use GAL can
be moved forward.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 05:16:43 -0400

In message <[email-masked]>
Alexander Vainshtein writes:
> IMHO and FWIW I think that the only problem with VCCV Type 3 is the
> risk of OAM packets leaking out of T-PE towards the AC (if you
> accidentally set the TTL value too high). To the best of my
> understanding the offset proposal does not solve that - or did I miss
> something?

That can be fixed by looking at the next label (if there is one) before
forwarding at PW egress to the AC.  The implementation already has to
make a similar chack on every packet if CW is used, but looking after
the S=1 label entry.  If CW is used it would be wise to do both checks
(be liberal in what you accept and careful in what you forward).

> Another way would be by using GAL below the PW label (possible but
> messy). If the industry moves towards deprecating Ethernet PWs without
> CW, it becomes completely unnecessary.

I agree with your last sentence but I don't know that non-CW can be
depricated.

Curtis

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 31 Mar 2011 02:17:48 -0700

Sasha, that issue with VCCV Type-3 (without CW) is not addressed by
the draft. Practically, is that a major issue ? Especially setting TTL
> 1 for SS PW is possible I guess but would be some kind of serious
operational oversight. Besides such a packet would fail some check
along the path.

Also, what I heard at the mic regarding impl results is that it
doesn't make sense to deprecate what is already deployed.

Note that CC Type 1 prevents ECMP (when FAT-PW is not available).
Using GAL below PW also requires ECMP based on label hashing to ignore
reserved labels.

-- 
- Sri

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 31 Mar 2011 11:25:12 +0200

Curtis,
The results of the PWE3 survey (it is difficult to say how representative it really is) seem to indicate 
that ability to support CW in the Ethernet PW encapsulation is quite common (13-14 out of 17 respondents)
and reasonably used (8 out of 17 respondents).

This survey does not provide any information about using GAL with PWs. Maybe we should extend the survey to learn that?
My expectation, not based on any facts, is that no one has been using it at the moment:-).

So if the choice is between fixing an old bug at the root (by deprecating PW encapsulations without CW) or adding a new patch (GAL in the PW) for the same purpose, I clearly prefer the first option. 

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 31, 2011 11:17 AM
> To: Alexander Vainshtein
> Cc: Sriganesh Kini; [email-masked]; [email-masked]
> <[email-masked]>
> > > 1. It does not require GAL in PW. TTL expiry is used to alert the
> S/T-
> > > PE.
> > > On Thu, Mar 31, 2011 at 12:03 AM, Curtis Villamizar
> <[email-masked]>
> > > wrote:
> > > >
> > > > Loa, Dave, Sasha,
> > > >
> > > >> AL being top label at the S-PE and TTL being encoded in the PW
> label
> > > means =
> > > >> that fate sharing is broken at every S-PE. Life only gets a
> little
> > > more str=

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 31 Mar 2011 11:34:15 +0200

Sriganesh,
Please see inline below.

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Sriganesh Kini
> Sent: Thursday, March 31, 2011 11:18 AM
> To: Alexander Vainshtein
> Cc: [email-masked]; [email-masked]
> the draft. 
[[[Sasha]]] That is what I said:-(
> > Practically, is that a major issue ? Especially setting TTL
[[[Sasha]]] If you mean SS-PW, then the chance for an error(sending an OAM packet with TTL > 1
or sending a data packet with TTL = 1) is small and should be treated as an implementation bug.
With  dynamic MS-PWs, the number of segments of a MS-PW can change with time, so that the originally 
Correct TTL setting would suddenly result in leakage of OAM packets out of the AC.
All this is described in detail in 6073.
> doesn't make sense to deprecate what is already deployed.
[[[Sasha]]] To the best of my recollection, what has been said at the mike is that you cannot
change optional CW usage to mandatory when you progress from PS to DS.
But, to the best of my understanding of the IETF process and practice, nothing prevents us
from publishing a BCP document that would declare non-usage of the CW deprecated.
This would push the vendors to support it in their new boxes (SW upgrades), and it would
be understood by the operators as a suggestion to transit to using the CW if their equipment
supports it -- all that without outlawing non-usage of the CW.

---

From: Giles Heron <[email-masked]>
Date: Thu, 31 Mar 2011 12:27:24 +0100

> That diminishes the generality of the design, which would in my view be

Agreed.  I'd expect the most common use case for TP is in the
access/aggregation.  So you might have an MS-PW with 3 segments:

MPLS TP <-> IP/MPLS <-> MPLS-TP.

Giles

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 31 Mar 2011 04:38:25 -0700

Sasha,

Can you point to the text in RFC 6073 that in your interpretation
results in the number of segments in a PW dynamically changing but the
PE being unaware of it (and using the incorrect TTL value).

Thanks

-- 
- Sri

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 07:40:28 -0400

Sriganesh, Sasha, Loa, Dave,

Would you please not top post.  See inline.

Curtis

In message <[email-masked]>
> operational oversight. Besides such a packet would fail some check

End to end OAM should set TTL>1 and not use VCCV Type-3.  The T-PE may
not have reliable information to set TTL, so in MS-PW it might be
worth discouraging VCCV Type-3 except for use as a traceroute
capability or to address S-PEs by node distance along the path.

> doesn't make sense to deprecate what is already deployed.

Yes.  But VCCV Type-3 with MS-PW is not already deployed.

> Using GAL below PW also requires ECMP based on label hashing to ignore

You don't want ECMP to hash on PW payload.  With CW and without
fat-pw, you don't get ECMP on a PW but you do get ECMP on an LSP
containing many PW.

> > messy). If the industry moves towards deprecating Ethernet PWs
> > without CW,  it becomes completely unnecessary. 
> >
> > My 2c,
> >     Sasha

This is the context suggesting a potential problem with VCCV Type 3.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 07:49:32 -0400

In message <[email-masked]>
Alexander Vainshtein writes:
>  
> Curtis,
>  
> The results of the PWE3 survey (it is difficult to say how
> representative it really is) seem to indicate that ability to support
> CW in the Ethernet PW encapsulation is quite common (13-14 out of 17
> respondents) and reasonably used (8 out of 17 respondents).

Yes.  I personally would have liked to require CW.  Some operators
have indicated a preference for no CW, understanding that it won't
work for multipath, but will work in metro/access or small networks.

> This survey does not provide any information about using GAL with
> PWs. Maybe we should extend the survey to learn that?  My expectation,
> not based on any facts, is that no one has been using it at the
> moment:-).

I doubt anyone has implemented GAL with PW already.

> So if the choice is between fixing an old bug at the root (by
> deprecating PW encapsulations without CW) or adding a new patch (GAL
> in the PW) for the same purpose, I clearly prefer the first option.

Realistically we not be able to require CW at this point.  If we
could, I'd be in favor of doing so.  If not, then we are stuck with
GAL to provide one good method which will work fine with or without CW.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 08:18:16 -0400

Greg,

His argument is that specifying that PW can be used for MPLS-TP only
or MPLS only would be a violation of the requirement for a common data
set.

There is no technical problem with use of GAL in a mixed TP and non-TP
MS-PW as long as the requirement that GAL be at BOS is relaxed.  There
may be a political problem in relaxing that restriction.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 08:25:25 -0400

In message <[email-masked]>
Alexander Vainshtein writes:
>  
> Dear Greg,
>  
> Yes I think we should leave 5586 "as it is" - or clean it up removing
> somew= hat mysterious comments regarding non-TP usages.
>  
> Regards,
>      Sasha

Sasha,

What text is that?

In RFC 5586 I found:

   Also note that the GAL and ACH are applicable to MPLS and PWs in
   general.  This document specifies general mechanism and uses MPLS-TP
   as an example application.  The application of the GAL and ACH to
   other specific MPLS uses is outside the scope of this document.

Did you mean the second sentence?

   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.  Where the GAL is at the bottom
   of the label stack (i.e., S bit set to 1), then it MUST always be
   followed by an ACH.

Since this text indicates that "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", we have a violation of
the requirement that there be one data plane for TP and non-TP MPLS.

If we want to maximize incompatibility, we can leave it as is (and
expect vendors to provide and option to ignore the restriction and
providers to use it).  :-)

Curtis

> would your argument illustrate that use of GAL with PW label not only in MP=
> LS-TP but in non-TP MPLS PW is strongly problematic? Should we leave RFC 55=
> 86 as is?
>  
> Regards,
> Greg
> On Wed, Mar 30, 2011 at 7:10 AM, Alexander Vainshtein <Alexander.Vainshtein=
> @ecitele.com<mailto:[email-masked]>> wrote:
> Dear Greg,
> From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]=
> m>]
> Cc: David Allan I; pwe3; [email-masked]<mailto:[email-masked]>; M=
> artini
> I believe that there should not be MS-PW that crosses TP and non-TP domains=
> .
> [[[Sasha]]] I believe that this would violate the requirement for the commo=
> n data plane of MPLS and MPLS-TP.
> If we strongly recommend that rule, then anyone not following it, at his/he=
> r free will and risk, just might be shooting themselves in a foot.
>  
> Regards,
> Greg
> On Wed, Mar 30, 2011 at 1:56 AM, Alexander Vainshtein <Alexander.Vainshtein=
> @ecitele.com<mailto:[email-masked]>> wrote:
> Dave,
> GAL may be a TP construct, but, IMO, MS-PWs (if not the other things) will =
> If we stick with GAL being an MPLS-TP construct we should, IMHO, drop the a=
> ttempts to use it with Ws.
>  
> Regards,
>      Sasha
>  
> From: David Allan I [mailto:[email-masked]<mailto:david.i.allan=
> @ericsson.com>]
> From: [email-masked]<mailto:[email-masked]> [mailto:pwe3-boun=
> [email-masked]<mailto:[email-masked]>] On Behalf Of Alexander Vainshte=
> in
> I would like to clarify - again - my position regarding GAL above the PW la=
> bel.
> I think that, other issues notwithstanding, it would create an issue if use=
> d with MS-PWs:
>  
> *         GAL would be exposed at each S-PE (making a presumably end-to-end=
>  OAM message to be intercepted)
>  
> *         What is even worse, there is no rule for forwarding the packet th=
> at has been intercepted due to an exposed GAL (until you count the statemen=
> t in 5586 requesting that a packet MUST NOT be ever forwarded based on GAL:=
> )).  Hence it would be perfectly valid just to drop such a packet at the fi=
> rst S-PE it crosses...
> This said, I still  do not think using GAL below the PW label is a good ide=
> a either. But this is a different story...
>  
> Regards,
>      Sasha

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 31 Mar 2011 05:40:07 -0700

See inline

> capability or to address S-PEs by node distance along the path.

If there is indeed a concern of TTL exceeding number of segments (with
Type-3 and no CW), the same concern would apply when tracing. So
tracing would be impossible.

> Yes.  But VCCV Type-3 with MS-PW is not already deployed.

I am not aware of the survey addressing this.

> fat-pw, you don't get ECMP on a PW but you do get ECMP on an LSP

When the PW payload is IP, the hashing it for ECMP is useful (If the
payload is not IP then use CW). FAT-PW may not be present in all
deployments.

-- 
- Sri

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Mar 2011 08:49:30 -0400

In message <AANLkTi=fuSg1iBy+jz0SvsfNpGrd-=32p+KMV7Q=[email-masked]>
> tracing would be impossible.

traceroute stops when it hits the egress.

> I am not aware of the survey addressing this.

AFAIK Type-1 is being used, but I could be wrong.  Maybe someone who
has implemented and knows of a deployment or someone who has deployed
can reply so we don't need another survey.

> payload is not IP then use CW). FAT-PW may not be present in all

I really don't know that any PW are carrying IP.  That was not in the
survey.  L3VPN would be carrying IP.

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 31 Mar 2011 06:35:55 -0700

inline

> traceroute stops when it hits the egress.

That is exactly the point I am trying to make. Why would the TTL from
that information not be reliable for other OAM operations ?

> survey.  L3VPN would be carrying IP.

IPLS would be another case.

-- 
- Sri