Hi Shraddha,
Thanks for your detailed email explanation. I was one of the WG members who indicated that Generic Metric not be advertised in the base as well as ASLA encodings. But what you've missed out was that I asked for it to be used in ASLA alone and not as application independent. Generic metric not only allows advertisement of existing IGP metric types but also introduces new ones e.g. Bandwidth. There will be others/more. We definitely do need the ability to have application specific values for these various Generic Metric types. One use-case is that there be a different reference b/w or threshold yardstick for FlexAlgo and SR Policy. The appl-independent proposal will require the specification and provisioning of new/additional user-defined Generic Metric types - potentially one per application (more if we consider different flex-algo) when we need different TE or B/W metric value per application. While advertising it in ASLA allows the same b/w metric type to be used with different values for FlexAlgo and SR Policy. Regarding the ASLA encoding, there is nothing that prevents the same Generic Metric type/value being shared across applications. We have already implementations that do so for FlexAlgo. This is a solved problem. Therefore, I still do believe that Generic Metric is application specific - as was originally in the draft version that the WG adopted. Coming to Generic Metric in BGP, I agree with the use-case. However, that is orthogonal to how it is advertised in IGPs. On the contrary, having too many user-defined and standard Generic Metric types (as you've proposed) make things more challenging to reconcile at the BGP level when we have a mix of types. Like other WG members, I do still believe that Generic Metric advertisement in ASLA *alone* would be the right way to go as far as having an extensible and generic encoding approach for the IGPs. Thank, Ketan -----Original Message----- From: Lsr <[email protected]> On Behalf Of Shraddha Hegde Sent: 19 July 2021 23:35 To: [email protected]; [email protected]; [email protected] Cc: Les Ginsberg (ginsberg) <[email protected]>; [email protected] Subject: 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]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Sunday, July 18, 2021 2:11 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[email protected]> www.zte.com.cn<http://www.zte.com.cn> ------------------Original Mail------------------ Sender: PeterPsenak To: Les Ginsberg (ginsberg);[email protected];[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!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx4pA8WB0$<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8919.html*section-6.1__;Iw!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx4pA8WB0$> > 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]<mailto:[email protected]> >> Sent: Monday, July 12, 2021 9:12 AM >> To: [email protected]<mailto:[email protected]> >> Cc: [email protected]<mailto:[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<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<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<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<https://urldefense.com/v3/__ftp:/ftp.ietf.org/internet-drafts/__;!!N> >> Et6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx6 >> GQqw0z$ >> >> >> _______________________________________________ >> Lsr mailing list >> [email protected]<mailto:[email protected]> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr> >> __;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOF >> bEWkx_ne0I9C$ > > _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_ne0I9C$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_ne0I9C$> _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
