Subject: [mpls] FW: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

From: Eric Gray <[email-masked]>
Date: Tue, 23 Aug 2011 14:27:47 -0400

Forwarding in plain text...

________________________________

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Thursday, August 18, 2011 4:25 AM
To: Greg Mirsky
Cc: [email-masked]; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Luca Martini
Subject: RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

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/MPLS 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 <http://www.merriam-webster.com/dictionary/chimera>  (1b), only it is not imaginaryJ.)

Regards,

     Sasha

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

> From: Greg Mirsky [mailto:[email-masked]]

> Sent: Thursday, August 18, 2011 8:43 AM

> To: Alexander Vainshtein

> Cc: [email-masked]; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren

> Gal; John Shirron; Rotem Cohen; Luca Martini

> Subject: Re: [mpls] [PWE3] 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

> <[email-masked]> 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 [[email-masked]]

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

> > To: Luca Martini

> > Cc: Alexander Vainshtein; [email-masked]; 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 <[email-masked]> 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=PE can be "flow-aware"). S-PE simply performs swap on

> >>> PW label.

> >>> Regards,

> >>>      Sasha

> >>> ------------------------------------------------------------------------

> >>> *From:* Pablo Frank [[email-masked]]

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

> >>> *To:* Alexander Vainshtein

> >>> *Cc:* [email-masked]; [email-masked]; 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

> >>> <[email-masked]

> >>> <mailto:[email-masked]>> 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:* [email-masked] <mailto:[email-masked]>

> >>>     [[email-masked] <mailto:[email-masked]>] On Behalf

> >>>     Of Alexander Vainshtein [[email-masked]

> >>>     <mailto:[email-masked]>]

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

> >>>     *To:* [email-masked] <mailto:[email-masked]>

> >>>     *Cc:* [email-masked] <mailto:[email-masked]>; 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

> >>>     <http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-

> pw/?include_text=1>:

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

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

> 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

> >>>     [email-masked] <mailto:[email-masked]>

> >>>     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

> >>> [email-masked]

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

> >> _______________________________________________

> >> mpls mailing list

> >> [email-masked]

> >> 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.

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.