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 protected]> 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 protected] [mailto:[email protected]] *On Behalf Of > *Pablo Frank > *Sent:* Tuesday, August 16, 2011 2:18 PM > *To:* Alexander Vainshtein > *Cc:* [email protected]; [email protected]; 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 protected]> 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** > ** > > > 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 > 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 protected] [[email protected]] On Behalf Of > Alexander Vainshtein [[email protected]] > *Sent:* Tuesday, August 16, 2011 4:26 PM > *To:* [email protected] > *Cc:* [email protected]; 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 protected] > https://www.ietf.org/mailman/listinfo/pwe3**** > > ** ** >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
