On 08/19/11 14:53, John E Drake wrote: > 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? 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 > Thanks, > > John > > Sent from my iPhone > > >> -----Original Message----- >> From: Luca Martini [mailto:[email protected]] >> Sent: Friday, August 19, 2011 1:17 PM >> To: John E Drake >> Cc: Alexander Vainshtein; [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 >> >> 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 >> >> >> >> >> >> >> On 08/18/11 08:00, John E Drake wrote: >>> 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 protected] [mailto:[email protected]] On Behalf >> Of >>>> Alexander Vainshtein >>>> Sent: Wednesday, August 17, 2011 9:52 PM >>>> To: Luca Martini >>>> 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 >>>> >>>> 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 protected]] >>>> Sent: Wednesday, August 17, 2011 9:58 PM >>>> To: Alexander Vainshtein >>>> Cc: Pablo Frank; [email protected]; [email protected]; 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 [[email protected]] >>>>> *Sent:* Wednesday, August 17, 2011 12:17 AM >>>>> *To:* Alexander Vainshtein >>>>> *Cc:* [email protected]; [email protected]; 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 protected] >>>>> <mailto:[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 >>>>> 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 protected] <mailto:[email protected]> >>>>> [[email protected] <mailto:[email protected]>] On >> Behalf >>>>> Of Alexander Vainshtein [[email protected] >>>>> <mailto:[email protected]>] >>>>> *Sent:* Tuesday, August 16, 2011 4:26 PM >>>>> *To:* [email protected] <mailto:[email protected]> >>>>> *Cc:* [email protected] <mailto:[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] <mailto:[email protected]> >>>>> 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 protected] >>>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
