Subject: IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 Aug 2011 16:26:10 +0300

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.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 Aug 2011 20:02:20 +0300

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] [[email-masked]] On Behalf Of Alexander Vainshtein [[email-masked]]
Sent: Tuesday, August 16, 2011 4:26 PM
To: [email-masked]
Cc: [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,

Regards,
     Sasha

---

From: Pablo Frank <[email-masked]>
Date: Tue, 16 Aug 2011 17:17:46 -0400

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]> 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.
>
>
>  ------------------------------
> *From:* [email-masked] [[email-masked]] On Behalf Of
> Alexander Vainshtein [[email-masked]]
> *Sent:* Tuesday, August 16, 2011 4:26 PM
> *To:* [email-masked]
> *Cc:* [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).
>
>
>
> 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,
>
> 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.
>
>
>
> 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]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 16 Aug 2011 14:24:39 -0700

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't do this.

Thx
SD

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pablo Frank
Sent: Tuesday, August 16, 2011 2:18 PM
To: Alexander Vainshtein
Cc: [email-masked]; [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

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.

 1.  A MS-PW:

 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:

 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.

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,

Regards,
     Sasha

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

---

From: Pablo Frank <[email-masked]>
Date: Tue, 16 Aug 2011 18:20:48 -0400

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 <[email-masked]> 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’t do this.
> ****
>
> ** **
>
> Thx****
>
> SD****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Pablo Frank
> *Sent:* Tuesday, August 16, 2011 2:18 PM
> *To:* Alexander Vainshtein
> *Cc:* [email-masked]; [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****
>
> ** **
>
> segment by segment in a MS-PW.****
>
> ** **
>
> Pablo****
>
> [email-masked]> wrote:****
>
> Hi all,****
>
> illustrate the need to combine GAL and "flow label" was inaccurate.****
>
>  ****
>
> 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) ****
>       using a T-PE that resides at the age of these two domains ****
>       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
>    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****
> *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw****
>
> Hi all,****
>
>  ****
>
> ****
>  ****
> corresponding text Section 4.2 of RFC 5586 states:****
>
> to 1).****
>  ****
> draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586
> with the following****
>
>  ****
>
> ****
>  ****
> requirement for the GAL being always at the bottom of the label stack. ***
> *
>
>  ****
>
> 1.1:****
>  ****
> the flows within a PW over the available ECMPs.  ****
>
>  ****
>
> pseudowires, and that MPLS-TP does not use ECMP. IMHO and FWIW, ****
>
> ****
>  ****
> any differences between the PW data plane in IP/MPLS and MPLS-TP. ****
>
> position. ****
>  ****
> consensus on this issue has not been reached.****
>
>  ****
>
> Hopefully this comment will be useful.****
>
>  ****
>
> Regards,****
>
>      Sasha****
>
>  ****
>
> thereof. ****
> thereof. ****
> https://www.ietf.org/mailman/listinfo/pwe3****
>
> ** **
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 17 Aug 2011 06:46:37 +0300

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

Pablo

 1.  A MS-PW:

Regards,
     Sasha

Hi all,

Regards,
     Sasha

---

From: Luca Martini <[email-masked]>
Date: Wed, 17 Aug 2011 12:58:07 -0600

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
> *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:
>           * 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
>      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
>      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.
>
>      
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] <mailto:[email-masked]>
>     [[email-masked] <mailto:[email-masked]>] On Behalf
>     Of Alexander Vainshtein [[email-masked]
>     <mailto:[email-masked]>]
>     *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
>     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:
>
>     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).
>
>      
>
>     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,
>
>     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.
>
>     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.
>
>      
>
>     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.
>
>
>     [email-masked] <mailto:[email-masked]>
> 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

---

From: John E Drake <[email-masked]>
Date: Thu, 18 Aug 2011 07:00:14 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexander Vainshtein
> Sent: Wednesday, August 17, 2011 9:52 PM
> To: Luca Martini
> Cc: [email-masked]; [email-masked]; Vladimir Kleiner; Idan Kaspit;
> 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":
> 
> <quote>
>    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.
> <end quote>
> 
> (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 [[email-masked]]
> Sent: Wednesday, August 17, 2011 9:58 PM
> To: Alexander Vainshtein
> Cc: Pablo Frank; [email-masked]; [email-masked]; Vladimir Kleiner; Idan
> >     draft-ietf-pwe3-gal-in-pw proposed to replace the original text
> in
> >     RFC 5586 with the following
> >
> >
> >
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 18 Aug 2011 07:52:19 +0300

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

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

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

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
Cc: Pablo Frank; [email-masked]; [email-masked]; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen

Luca

---

From: Luca Martini <[email-masked]>
Date: Fri, 19 Aug 2011 14:17:22 -0600

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

---

From: John E Drake <[email-masked]>
Date: Fri, 19 Aug 2011 13:53:19 -0700

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?

Thanks,

John

Sent from my iPhone

> From: Luca Martini [mailto:[email-masked]]
> Sent: Friday, August 19, 2011 1:17 PM
> To: John E Drake
> Cc: Alexander Vainshtein; [email-masked]; [email-masked]; Vladimir
> Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron;
> Rotem Cohen
> > - 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)
> >
> >> Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-
> pwe3-
> >> gal-in-pw
> >>
> >> Luca and all,
> >>> -------------------------------------------------------------------
> --
> >> ---
> >>> *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-
> gal-
> >> in-pw
> >>>           * Starts at an S-PE that resides at the edge of an MPLS-
> TP
> >>>             domain (no ECMP)
> >>>           * 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
> >>>     IMHO this describes a realistic scenario where the two drafts
> are
> >>>     in controversy.
> >>>
> >>>     Regards,
> >>>          Sasha
> >>>     ---------------------------------------------------------------
> --
> >> -------
> >>>     *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-
> gal-
> >> in-pw
> >>>     Hi all,
> >>>
> >>>
> >>>
> >>>     <http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-
> in-
> >> pw/?include_text=1>:
> LSPs,
> LSPs,
> >>>     such an argument, were it presented, would be highly
> problematic,
> >>>     because:
> >>>
> >>>
> >>>
> inform

---

From: Luca Martini <[email-masked]>
Date: Fri, 19 Aug 2011 15:09:12 -0600

> 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

---

From: Thomas Nadeau <[email-masked]>
Date: Sat, 20 Aug 2011 08:34:52 -0400

> " following the MPLS label stack , you will find a GACh construct , and

	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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 Aug 2011 13:04:47 +0100

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  <http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2>. (GAL Applicability and Usage) in [RFC5586  <http://tools.ietf.org/html/rfc5586>], the
       original text:

       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  <http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2>. (GAL Applicability and Usage) in [RFC5586  <http://tools.ietf.org/html/rfc5586>], the
       original text:

       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

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 30 Aug 2011 15:22:00 +0300

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?

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:[email-masked]]
Sent: Tuesday, August 30, 2011 3:05 PM
To: Luca Martini; IETF Discussion
Cc: John E Drake; [email-masked]; Alexander Vainshtein; [email-masked]; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

========

 -  Section 4.2<http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2>. (GAL Applicability and Usage) in [RFC5586<http://tools.ietf.org/html/rfc5586>], the

      original text:

      is replaced by:

should be replaced by

=====

 -  Section 4.2<http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2>. (GAL Applicability and Usage) in [RFC5586<http://tools.ietf.org/html/rfc5586>], the

      original text:

      is replaced by:

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 Aug 2011 14:13:20 +0100

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