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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The solution is quite simple:

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

Luca





On 08/16/11 21:46, Alexander Vainshtein wrote:
> Pablo,
> Sorry, but I think you're wrong. Only T-PE can insert the flow label
> (because only T=PE can be "flow-aware"). S-PE simply performs swap on
> PW label.
>  
> Regards,
>      Sasha
>  
> ------------------------------------------------------------------------
> *From:* Pablo Frank [pabloisnot@xxxxxxxxx]
> *Sent:* Wednesday, August 17, 2011 12:17 AM
> *To:* Alexander Vainshtein
> *Cc:* ietf@xxxxxxxx; mpls@xxxxxxxx; 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
> <Alexander.Vainshtein@xxxxxxxxxxx
> <mailto:Alexander.Vainshtein@xxxxxxxxxxx>> wrote:
>
>     Hi all,
>     After having sent out my comments I've noticed that the specific
>     example to illustrate the need to combine GAL and "flow label" was
>     inaccurate.
>      
>     A more relevant example would look like following (I do not
>     include a diagram, but it can be easily provided if necessary)
>
>      1. A MS-PW:
>           * Starts at an S-PE that resides at the edge of an MPLS-TP
>             domain (no ECMP)
>           * Crosses this domain and enters an IP/MPLS domain with ECMP
>             enabled using a T-PE that resides at the age of these two
>             domains
>           * Leaves this domain and enters a 2nd MPLS-TP domain (using
>             the 2nd T-PE)
>           * Terminates on another S-PE at the edge of the 2nd MPLS-TP
>             domain
>      2. The operator intends to improve traffic distribution in the
>         IP/MPLS domain, hence he enables insertion and discard of
>         "flow labels" at the two S-PEs. Note that:
>           * This does not violate the MPLS-TP restriction on ECMP:
>             ECMP does not happen in he MPLS-TP domains
>           * T-PEs do not even have to be aware of flow labels
>      3. The operator also intends to operate some end-to-end OAM for
>         this MS-PW using "GAL-in-PW". This results in a conflict since
>         both GAL and "flow label" are defined (in the corresponding
>         drafts) as bottom of stack.
>
>      
>
>     IMHO this describes a realistic scenario where the two drafts are
>     in controversy.
>      
>     Regards,
>          Sasha
>     ------------------------------------------------------------------------
>     *From:* mpls-bounces@xxxxxxxx <mailto:mpls-bounces@xxxxxxxx>
>     [mpls-bounces@xxxxxxxx <mailto:mpls-bounces@xxxxxxxx>] On Behalf
>     Of Alexander Vainshtein [Alexander.Vainshtein@xxxxxxxxxxx
>     <mailto:Alexander.Vainshtein@xxxxxxxxxxx>]
>     *Sent:* Tuesday, August 16, 2011 4:26 PM
>     *To:* ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>
>     *Cc:* mpls@xxxxxxxx <mailto:mpls@xxxxxxxx>; 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
>     pwe3@xxxxxxxx <mailto:pwe3@xxxxxxxx>
>     https://www.ietf.org/mailman/listinfo/pwe3
>
>
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please
> inform us by e-mail, phone or fax, and then delete the original and
> all copies thereof.
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf

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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]