Subject: [PWE3] Why GAL after the PW label is a bad idea

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Sep 2010 15:29:13 +0200

Hi all,
I've just sent a message to the list responding "No" to the poll on accepting draft-lm-pwe3-mpls-tp-gal-in-pw-00 as a WG document.
I will try to present the rationale behind my answer in this email. I apologize in advance for a rather long email.

1.      GAL and G-ACh (as defined in RFC 5586<http://datatracker.ietf.org/doc/rfc5586>) provide a mechanism for differentiation between MPLS packets that carry customer traffic and  the packets that use the same label stack to carry other types of traffic (OAM, MCC etc.) and additional demultiplexing among these traffic types. Such a mechanism was mandatory in MPLS-TP because:

a.      The MPLS data plane (inherited by MPLS-TP) did not provide for any PID

b.      IP (which is one of MPLS-TP clients) is encapsulated into MPLS (and MPLS-TP) without any intermediate headers

c.       MPLS-TP breaks the linkage  between MPLS and IP. In particular, usage of IP forwarding rules for disposition of unlabeled packets at the LSP tail-end (as, for instance, is the case with LSP-Ping, see RFC 4379<http://datatracker.ietf.org/doc/rfc3479/>) seems inappropriate in MPLS-TP environments.

2.      When it comes to PWs, RFC 5085<http://datatracker.ietf.org/doc/rfc5085> has already defined three different mechanisms for differentiation between PW packets that carry customer traffic and the packets that carry OAM traffic:

a.      In the cases when the preferred PW CW is used (RFC 4385<http://datatracker.ietf.org/doc/rfc4385>), VCCV Type 1 can be used. This mode is defined as mandatory when the CW is present in the PW encapsulation

b.      Router Alert Label (RFC 3032) is used in VCCV Type 2. RFC 5085 notes that this technique may be problematic in the environments where ECMP based on the label stack hashing is employed, and the Segmented Pseudowire<http://datatracker.ietf.org/doc/draft-ietf-pwe3-segmented-pw> draft explicitly precludes using this method for multi-segment pseudowires

c.       TTL expiration in the label stack entry containing the PW label is used in VCCV Type 3. This method facilitates carrying OAM messages across specific segments of multi-segment pseudowires and can be combined with VCCV Type 1 where this technique is applicable.

3.      RFC 5085 did not define a mandatory VCCV type for PWs that do not use CW.

a.      This affects, first of all,  Ethernet PWs which seem to be the most  widely deployed PW type

b.      The industry has already encountered interoperability issues caused by the specification of multiple non-interoperable VCCV types as has been documented in the Mandatory Features of the VCCV Implementations<https://datatracker.ietf.org/doc/draft-delregno-pwe3-vccv-mandatory-features> draft. This draft also contains a proposal for resolving this problem by making VCCV Type 3 mandatory and pushing towards usage of VCCV Type 1 as well).

4.      If we allow putting GAL and G-ACh below the PW label (which is the essence of draft-lm-pwe3-mpls-tp-gal-in-pw-00), we effectively add VCCV Type 4 to the already defined set of VCCV Types. From my point of view this would only aggravate the already existing interoperability problem. And if we accept the above-mentioned proposals for resolving this problem, this proposal loses any sense. This is why I object to accepting draft-lm-pwe3-mpls-tp-gal-in-pw-00 as a WG document.

Regards,
     Sasha

---

From: Luca Martini <[email-masked]>
Date: Thu, 16 Sep 2010 21:11:19 -0600

On 09/16/10 07:29, Alexander Vainshtein wrote:
>
> Hi all,
>
> I’ve just sent a message to the list responding “No” to the poll on
> accepting draft-lm-pwe3-mpls-tp-gal-in-pw-00 as a WG document.
>
> I will try to present the rationale behind my answer in this email. I
> apologize in advance for a rather long email.
>
> 1. GAL and G-ACh (as defined in RFC 5586
> <http://datatracker.ietf.org/doc/rfc5586>) provide a mechanism for
> differentiation between MPLS packets that carry customer traffic and
> the packets that use the same label stack to carry other types of
> traffic (OAM, MCC etc.) and additional demultiplexing among these
> traffic types. Such a mechanism was mandatory in MPLS-TP because:
>
> b. IP (which is one of MPLS-TP clients) is encapsulated into MPLS (and
> MPLS-TP) without any intermediate headers
>
> c. MPLS-TP breaks the linkage between MPLS and IP. In particular,
> usage of IP forwarding rules for disposition of unlabeled packets at
> the LSP tail-end (as, for instance, is the case with LSP-Ping, see RFC
> 4379 <http://datatracker.ietf.org/doc/rfc3479/>) seems inappropriate
> in MPLS-TP environments.
>
all these arguments equally apply to MPLS. Therefore we need the GAL in
both MPLS and MPLS-TP.
>
> 2. When it comes to PWs, RFC 5085
> <http://datatracker.ietf.org/doc/rfc5085> has already defined three
> different mechanisms for differentiation between PW packets that carry
> customer traffic and the packets that carry OAM traffic:
>
> a. In the cases when the preferred PW CW is used (RFC 4385
> <http://datatracker.ietf.org/doc/rfc4385>), VCCV Type 1 can be used.
> This mode is defined as mandatory when the CW is present in the PW
> encapsulation
>
> b. Router Alert Label (RFC 3032) is used in VCCV Type 2. RFC 5085
> notes that this technique may be problematic in the environments where
> ECMP based on the label stack hashing is employed, and the Segmented
> Pseudowire
> <http://datatracker.ietf.org/doc/draft-ietf-pwe3-segmented-pw> draft
> explicitly precludes using this method for multi-segment pseudowires
>
> c. TTL expiration in the label stack entry containing the PW label is
> used in VCCV Type 3. This method facilitates carrying OAM messages
> across specific segments of multi-segment pseudowires and can be
> combined with VCCV Type 1 where this technique is applicable.
>
Yes, and we plan to obsolete several of these to allow for a much
simpler implementation.
Regardless , the fact we have these methods, does not prevent us from
doing something better.
Note that method b) above is already obsoleted ( not supported) for MS-PWs.
> b. The industry has already encountered interoperability issues caused
> by the specification of multiple non-interoperable VCCV types as has
> been documented in the Mandatory Features of the VCCV Implementations
> <https://datatracker.ietf.org/doc/draft-delregno-pwe3-vccv-mandatory-features>
> draft. This draft also contains a proposal for resolving this problem
> by making VCCV Type 3 mandatory and pushing towards usage of VCCV Type
> 1 as well).
>
> 4. If we allow putting GAL and G-ACh below the PW label (which is the
> essence of draft-lm-pwe3-mpls-tp-gal-in-pw-00), we effectively add
> VCCV Type 4 to the already defined set of VCCV Types. From my point of
> view this would only aggravate the already existing interoperability
> problem. And if we accept the above-mentioned proposals for resolving
> this problem, this proposal loses any sense. This is why I object to
> accepting draft-lm-pwe3-mpls-tp-gal-in-pw-00 as a WG document.
>
I have no problem in obsoleting all VCCV type 1 to 3 , and moving
forward with a single type.
Would you agree with that direction ?

Thanks.
Luca

> Regards,
>
> Sasha
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 17 Sep 2010 08:03:57 +0200

Luca,
Lots of thanks for a prompt response.
Please see a couple of comments inline below.

Regards,
     Sasha

________________________________________
From: Luca Martini [[email-masked]]
Sent: Friday, September 17, 2010 5:11 AM
To: Alexander Vainshtein
Cc: [email-masked]; Andrew Sergeev; Robert Rennison; Alexander Kugel
Subject: Re: [PWE3] Why GAL after the PW label is a bad idea

all these arguments equally apply to MPLS. Therefore we need the GAL in
both MPLS and MPLS-TP.
[[Sasha]] I respectfully disagree. We already have quite a nice OAM toolset in MPLS that does not use GAL
(LSP-Ping and BFD for LSPs have been both published as RFCs, and at least LSP-Ping has been widely deployed for quite some time;
not so sure about BFD for MPLS).
And, BTW, using GAL in MPLS environments where ECMP is enabled would break fate-sharing between OAM
and data packets - same as using the Router Alert label with PWs in VCCV Type 2.
I did not include this in my original email, but it is worth having in mind IMO as one more argument against your proposal.
Yes, and we plan to obsolete several of these to allow for a much
simpler implementation. Regardless, the fact we have these methods, 
does not prevent us from doing something better.
[[Sasha]] Definitely not. But as I see it, so far you just add one more technique to three already defined and implemented ones
without any indication (at least in the draft) as to which problem (preferably one that cannot be solved by any of these
methods) you actually solve (and how) with your proposal.

Note that method b) above is already obsoleted ( not supported) for MS-PWs.
[[Sasha]] I have mentioned that in my original email.
I have no problem in obsoleting all VCCV type 1 to 3 , and moving
forward with a single type. Would you agree with that direction ?

[[Sasha]] NO, I would not agree, for the following reasons:
1. I do not see how using VCCV Type 3 can be avoided if you want to provide segment OAM for MS-PWs.
2. These methods, AFAIK, have been standardized, implemented and deployed. Obsoleting them would 
be, IMHO, roughly equivalent to prescribing the guillotine as the best remedy against headache.

Thanks.
Luca

---

From: Luca Martini <[email-masked]>
Date: Fri, 17 Sep 2010 09:13:55 -0600

> Please see a couple of comments inline below.
Sasha, the GAL is already allowed , and used in MPLS. The fate sharing
argument is not valid for MPLS-TP where there is no ECMP. Breaking the
fate-sharing between OAM , and Data packets does not matter in most
service providers, and if it does matter, the SP can simply disable ECMP
in the MPLS portion of the network.

> methods) you actually solve (and how) with your proposal.
What proposal ?
we have not published any new VCCV type proposal. Are you commenting on
possible future developments ?
Why don't we keep the discussion to the document in question.

> be, IMHO, roughly equivalent to prescribing the guillotine as the best remedy against headache.
As I mentioned above, you are making supposition on material that has
not been designed yet.
Let's take thsi one step at a time.

This document is just a very simple removal of an unnecessary
restriction, nothing more.

Luca

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 17 Sep 2010 12:00:06 -0700

Dear Luca,
proposed in the document is not just simple removal of obsolete, rudimentary
text, as I see it, but of functionality that might be already supported or
been planned for future. Because of that I feel that it is premature to
adopt this document as working group working item without thorough
discussion if the WG agrees with proposed direction in general. Details, as
always, can be worked out through the normal process.

Regards,
Greg

On Fri, Sep 17, 2010 at 8:13 AM, Luca Martini <[email-masked]> wrote:

> > (LSP-Ping and BFD for LSPs have been both published as RFCs, and at least
> LSP-Ping has been widely deployed for quite some time;
> > I did not include this in my original email, but it is worth having in
> mind IMO as one more argument against your proposal.
> > [[Sasha]] Definitely not. But as I see it, so far you just add one more
> technique to three already defined and implemented ones
> > without any indication (at least in the draft) as to which problem
> (preferably one that cannot be solved by any of these
> >> <
> https://datatracker.ietf.org/doc/draft-delregno-pwe3-vccv-mandatory-features
> >

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 18 Sep 2010 12:03:10 +0200

Luca,
Lots of thanks for a prompt response.
Looks like we still disagree on your original proposal (i.e. to allow GAL after the PW label by removing an explicit restriction in RFC 5586).  Unfortunately, my arguments, so far, did not convince you and vice versa.

In particular, I do not think that your statement that:

<quote>
     Breaking the fate-sharing between OAM , and Data packets does not matter in most
     service providers, and if it does matter, the SP can simply disable ECMP in the MPLS 
    portion of the network.
<end quote>
is accurate. Were it so, the WG, IMHO,  would hardly pick up and advance the Fat PW concept (http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/) which presumably has completed the WG Last Call.
BTW, if your proposal were accepted, the Flow Label introduced in this draft would compete for the bottom-of-stack position with the GAL.

I suggest we let the other WG participants to present their position.

Regards,
     Sasha

Sent: Friday, September 17, 2010 5:13 PM

What proposal ?

Luca

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 18 Sep 2010 21:26:45 +0100

> BTW, if your proposal were accepted, the Flow Label introduced in this draft would compete for the bottom-of-stack position with the GAL.

FL would go at the bottom (it needs to), but the GAL would still be 
properly intercepted since it is a reserved label and cannot therefore 
cannot be mistaken for a FL.

Stewart

---

From: Thomas Nadeau <[email-masked]>
Date: Sun, 19 Sep 2010 07:52:19 -0400

> in the MPLS portion of the network.

	I think we need to tease out two important points from above. First of all, you are %100 correct in stating that MPLS-TP is required to have no ECMP as originally designed and that ECMP considerations *in the case of MPLS-TP or classic PWs* can be ignored as it should (MUST as I read things) be disabled. And indeed in this scenario, SPs likely do not care about ECMP fate sharing because it is assumed to be nonexistent in these two situations. However, in your second statement, and perhaps its just miswritten to combine both thoughts, as a general rule of thumb, it is most definitely not the case in my experience both working at a large SP and in the past working with them and others, that that if a SP has ECMP enabled within their network that they do not care about fate sharing or understanding where it might exist (or where it might be broken); quite the contrary. The reason is simple: it will be impossible to trouble-shoot. It is also confusing at best for network planning if you don't know where your traffic is headed.

	So if we generalize the PW/GAL case to work with the entropy label/fat PWs or non-MPLS-TP cases, ECMP (and fate sharing) is indeed an issue that cannot be simply ignored.

> Why don't we keep the discussion to the document in question.

	I think the perception here is that the GAL after the PW label might be introducing a 4th mode of 
running VCCV (or a need to run it in that mode). Indeed this is how the MPLS-TP performance monitoring draft does 
its encapsulation, which is indeed different from the prior 3 modes of doing "OAM" functions on a PW.

	--Tom