Shraddha - With respect, the issue here is very simple and does not warrant the long email.
As per RFC 8919/8920, any link attribute used by applications defined with an ASLA bit (other than the legacy applications RSVP-TE, SRTE, and LFA) MUST use ASLA advertisements. As you propose to use the new metric for Flex-Algo - which is a "new application" with an ASLA assigned bit - you MUST support ASLA encoding. You can also support encoding in a sub-TLV under TLV22 (etc.). There is nothing to discuss here - it is simply a matter of conforming to the normative statements in existing RFCs. Please correct the draft as requested. Les > -----Original Message----- > From: Shraddha Hegde <[email protected]> > Sent: Monday, July 19, 2021 11:05 AM > To: [email protected]; [email protected]; > [email protected] > Cc: Les Ginsberg (ginsberg) <[email protected]>; draft-ietf-lsr-flex-algo- > [email protected] > Subject: RE: Re:[Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > > Hi All, > > Generic metric was allowed to be advertised in TLV 22/ ELO LSA > as well as ASLA TLV before the draft was called for adoption. > During the recent WG adoption review, it was pointed out that > ASLA architecture does not allow an attribute to be advertised > in both application-specific and application-independent manner. > > As a result of this Generic metric has been made an > application-independent attribute in the latest version. > The reasons are below > > 1.Generic metric is required to be advertised in an application-independent > manner > that is metric-type 128 is advertised for a link and any application > like flex-algo, SR-TE, RSVP LFA can make use of it. > Metric has scope outside of an IGP domain. It gets advertised > in BGP-LU and gets accumulated across domains. > There are many usecases that will benefit from advertising generic-metric > in an application-independent manner. > > 2.The recent case of te-metric usecase that I came across > where ASLA was being used, really wanted to > use a different metric-type for flex-algo and not really > different values for same metric type. > (Peter, coincidently we may be talking of the same recent > usecase which you claimed to be using ASLA) > > 3.Advertising generic metric in an application independent manner in legacy > TLV 22 and ELO LSA > does not violate RFC 8919/8920. Application-independent attributes are not > expected to use RFC 8919/8920 > mechanisms. Generic metric is like igp cost. IGP-cost is never advertised in > ASLA but it gets used in flex-algo > and generic-metric is being modeled based on igp-cost. > As currently written, this document is compliant to every RFC and draft that > has > been out there and not violating any of them. > > 4.Generic metric is very flexible. It allows for finest granularity of > metric advertisement. > Usecase: > Lets say flex-algo 128 wants to use metric-type 128 and flex-algo 129 > wants to use metric-type 129. An year later operator decides to deploy > SR-TE with red LSPs using metric-type 128 and Blue LSPs using metric-type > 129. > > Using generic metric in application-independent manner: > 1.configure metric-type 128 and 129 and value pair on each link > 2. set flex-algo 128 FAD to use metric-type 128 and flex-algo FAD 129 to use > metric-type 129 > 3. An year later configure Red LSPs to use metric-type 128 and Blue LSPs to > use metric-type 129 > > Using generic metric with ASLA: > 1. Define user defined bit-masks for flex-algo 128 and flex-algo 129 and > configure on every router > 2. configure metric-type 128 and 129 on every link > 3. An year later, define user defined bit masks for SR-TE Red LSPs and SR-TE > blue LSPs > 4. Configure the bit masks on all head-end routers > 5. Associate the new bit masks with the metric-types on every router on > every link. > > The most common cases look operationally very complex with ASLA while > they look very > simple operationally with generic-metric being advertised in an application- > independent > manner. It looks reasonable approach to allow the option of application- > independent > advertisements for operators who are looking to simplify operations. > > > In order to decide how the generic-metric should be advertised, it would > be good to get input from the WG on below point. > Do you have usecases in mind that you would like to deploy that cannot be > solved > with advertising generic-metric in an application-independent manner? > > > Looking forward to more discussions during LSR WG meeting. > > > Rgds > Shraddha > > > Juniper Business Use Only > > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Sunday, July 18, 2021 2:11 AM > To: [email protected]; [email protected] > Cc: [email protected]; [email protected] > Subject: Re:[Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > > [External Email. Be cautious of content] > > > Dear All, > I concur with the arguments presented by Les and Peter. Perhaps the Editors > of the WG draft will update the document accordingly. > > Regards, > Greg Mirsky > Sr. Standardization Expert > 预研标准部/有线研究院/有线产品经营部 Standard Preresearch > Dept./Wireline Product R&D Institute/Wireline Product Operation Division > E: [email protected] > www.zte.com.cn > ------------------Original Mail------------------ > Sender: PeterPsenak > To: Les Ginsberg (ginsberg);[email protected];draft-ietf-lsr-flex-algo-bw- > [email protected]; > Date: 2021/07/14 01:40 > Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > Hi, > I'm the co-author of this draft and I have tried to convince the rest of the > co- > authors that encoding the new Generic Metric sub-TLV only as a application > independent value is wrong. Unfortunately, my efforts have failed. As a > result, although unwillingly, I have to express my opinions here and let the > WG decide. > 1) The usage of the Generic Metric sub-TLV is likely going to be associated > with the applications, Flex-algo being the first one. Generic Metric sub-TLV > can not be used by IGP's native calculation. So having Generic Metric being > encoded only in legacy TLV does not make much sense. > 2) TE-metric is defined as application specific attribute by RFC 8919/8920 and > can be advertised in ASLA. The application specific value advertisement of TE- > metric has been already proved in the field. > Generic Metric is semantically very similar to TE-metric, so I see no reason > why application specific encoding should not be supported. > 3) Flex-algo specification mandates the usage of the ASLA attributes and all > of the attributes that we are using for flex-algo so far are encoded in ALSA. > Encoding the Generic Metric outside of ALSA violates that principle. > 4) RFC 8919/8920 violation brought by Les below. > thanks, > Peter > On 13/07/2021 17:39, Les Ginsberg (ginsberg) wrote: > > Draft authors - > > > > I note that the new version has altered the advertisement of the Generic > Metric sub-TLV so that it is no longer supported in the ASLA sub-TLV. > > This is in direct violation of RFC 8919/8920. > > > > For example, https://urldefense.com/v3/__https://www.rfc- > editor.org/rfc/rfc8919.html*section-6.1__;Iw!!NEt6yMaO- > gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx4 > pA8WB0$ states: > > > > "New applications that future documents define to make use of the > advertisements defined in this document MUST NOT make use of legacy > advertisements." > > > > Flex-algo is a "new application" in the scope of these RFCs. > > > > Please correct this error. > > > > Thanx. > > > > Les > > > > > >> -----Original Message----- > >> From: Lsr On Behalf Of [email protected] > >> Sent: Monday, July 12, 2021 9:12 AM > >> To: [email protected] > >> Cc: [email protected] > >> Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the Link State Routing WG of the IETF. > >> > >> Title : Flexible Algorithms: Bandwidth, Delay, Metrics > >> and > >> Constraints > >> Authors : Shraddha Hegde > >> William Britto A J > >> Rajesh Shetty > >> Bruno Decraene > >> Peter Psenak > >> Tony Li > >> Filename : draft-ietf-lsr-flex-algo-bw-con-01.txt > >> Pages : 27 > >> Date : 2021-07-12 > >> > >> Abstract: > >> Many networks configure the link metric relative to the link > >> capacity. High bandwidth traffic gets routed as per the link > >> capacity. Flexible algorithms provides mechanisms to create > >> constraint based paths in IGP. This draft documents a generic metric > >> type and set of bandwidth related constraints to be used in Flexible > >> Algorithms. > >> > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie > >> tf-lsr-flex-algo-bw-con/__;!!NEt6yMaO- > gk!RDrlZO2ni4GUc8POsqsLd2DGo2Ku > >> E9gbrUscAHAlbWXMsiRouKOFbEWkxyFWi9bo$ > >> > >> There is also an htmlized version available at: > >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra > >> ft-ietf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO- > gk!RDrlZO2ni4GUc8POsqsLd > >> 2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkxwbtJYtY$ > >> > >> A diff from the previous version is available at: > >> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-i > >> etf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO- > gk!RDrlZO2ni4GUc8POsqsLd2DGo > >> 2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_rX175v$ > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!N > >> Et6yMaO- > gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx6 > >> GQqw0z$ > >> > >> > >> _______________________________________________ > >> Lsr mailing list > >> [email protected] > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr > >> __;!!NEt6yMaO- > gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOF > >> bEWkx_ne0I9C$ > > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;! > !NEt6yMaO- > gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_ > ne0I9C$ _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
