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: mpls-bounces@xxxxxxxx [mailto:mpls-bounces@xxxxxxxx] On Behalf Of > Alexander Vainshtein > Sent: Wednesday, August 17, 2011 9:52 PM > To: Luca Martini > Cc: mpls@xxxxxxxx; ietf@xxxxxxxx; 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 > > 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 [lmartini@xxxxxxxxx] > Sent: Wednesday, August 17, 2011 9:58 PM > To: Alexander Vainshtein > Cc: Pablo Frank; mpls@xxxxxxxx; ietf@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 > > 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 > > 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. > > _______________________________________________ > mpls mailing list > mpls@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf