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: gregory.mir...@ztetx.com <gregory.mir...@ztetx.com> Sent: Sunday, July 18, 2021 2:11 AM To: ppsenak=40cisco....@dmarc.ietf.org; lsr@ietf.org Cc: ginsb...@cisco.com; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org 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: gregory.mir...@ztetx.com www.zte.com.cn ------------------Original Mail------------------ Sender: PeterPsenak To: Les Ginsberg (ginsberg);lsr@ietf.org;draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; 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$ > 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 internet-dra...@ietf.org >> Sent: Monday, July 12, 2021 9:12 AM >> To: i-d-annou...@ietf.org >> Cc: lsr@ietf.org >> 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 >> Lsr@ietf.org >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >> __;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOF >> bEWkx_ne0I9C$ > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_ne0I9C$ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr