Gunter, I agree with you that metrics that are dynamically generated such as delay metric and bandwidth metric as defined in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con have application-independent values and remain same for all applications.
The draft above defines Generic metric as a generalization of bandwidth metric, that is a reusable tool. Generic metric advertisements may include dynamically generated metrics or statically configured metrics. One interpretation of this is that generic metric needs to be both application-independent as well as application-specific to support both the sets of use cases. However, when I look at the use cases that may require application-specific generic metric advertisements for statically configured metrics, I generally find that there is a simple solution using application-independent generic metric advertisements. When I discuss how these use cases would be solved with application-specific generic advertisements with different individuals, I get very complex proposals. Consider the following scenario. There are two flex-algos 128 and 129 in a network. Operator wants to configure different monetary costs to each link for flex-algo 128 and 129. Basically different cost for different application. I would solve this using application-independent way as below. Define metric-type 128 and metric-type 129. advertise both the metrics for each link. Flex-algo FAD 128 to use metric-type 128. Flex-algo FAD 129 to use metric-type 129. Let us see how people will solve this use case with application-specific generic metric advertisements. Rgds Shraddha Juniper Business Use Only -----Original Message----- From: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email protected]> Sent: Friday, July 30, 2021 2:36 PM To: Peter Psenak <[email protected]>; Shraddha Hegde <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; Tony Li <[email protected]> Cc: [email protected] Subject: RE: [Lsr] Generic metric: application-specific vs application-independent [External Email. Be cautious of content] A little late in the discussion... (PTO events do happen) a quick opinion on the below discussion on whether Generic metric sub-tlv should be encoded on a ASLA or not. For me, it depends on how the metric for the corresponding metric-type is obtained and if it can be configured (static). It doesn’t make sense to have Application specific values if a particular metric is obtained only dynamically, for eg, dynamically measured delay is going to be same for all applications. On the contrary, te-metric can be configured, and we can in principle configure different values for different applications. My opinion is that if any of the metric-types in the Generic metric sub-tlv can be configured, it should be inside the ASLA. G/ -----Original Message----- From: Lsr <[email protected]> On Behalf Of Peter Psenak Sent: Friday, July 30, 2021 9:42 AM To: Shraddha Hegde <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; Tony Li <[email protected]> Cc: [email protected] Subject: Re: [Lsr] Generic metric: application-specific vs application-independent Shraddha, On 30/07/2021 06:53, Shraddha Hegde wrote: > Operators have built their networks with link attributes > > being configured and used by any application. For example > > igp-metric is used by ISIS, then came LDP that used same igp-metric, > > RSVP could also use igp-metric. Then came ISIS-SR and SR-TE > > and even flex-algo. All these applications could use the same igp-metric. > > The networks have evolved like this for 20-30 years. > > If an operator wants to design his network for this kind of > > network evolution with generic metric going forward, ASLA does not > > currently provide an effective solution. please be more specific as to what exactly "ASLA does not currently provide an effective solution" for. > ASLA currently has limitations > > that make it more complex than necessary for operators who want to > > evolve their networks this way. above seems more like your opinion than the fact. I have not seen any evidence that would prove the above statement. > > I am working on a draft to propose improvements to ASLA to > > make this kind of evolution less complex. I'll post a draft > > soon that will describe limitations of ASLA in its current form > > along with proposed improvements. hard to comment on something that does not exist. > > I would still like to hear about use cases that require > > generic metric to be applications-specific and cannot be solved with > > application-independent generic metric. it has been explained on the list multiple times. thanks, Peter > > Rgds > > Shraddha > > Juniper Business Use Only > > *From:* Les Ginsberg (ginsberg) <[email protected]> > *Sent:* Thursday, July 29, 2021 2:00 AM > *To:* Tony Li <[email protected]> > *Cc:* [email protected]; Shraddha Hegde <[email protected]> > *Subject:* RE: [Lsr] Generic metric: application-specific vs > application-independent > > *[External Email. Be cautious of content]* > > Tony – > > You ask very important questions – but – as Acee has answered in a > subsequent email – all of these questions were openly debated in the > WG during the work on what became RFC8919/8920. This debate was > contentious, took years, and the WG eventually reached consensus on > what became the two RFCs. > > If every time a new attribute is defined we reopen the original > debate, then we will never move forward and we will have great > difficulty in deploying interoperable implementations. > > I can respect that you might have preferred a different conclusion on > the part of the WG – but I hope you will also acknowledge that this is > now a resolved issue and we need to move forward following the > existing RFCs. > > Parenthetically, I do believe that answers to your questions can be > found in the RFCs. The answers may not satisfy you – but we did > attempt to include the context which drove the ASLA solution. > > Thanx. > > Les > > *From:* Lsr <[email protected] <mailto:[email protected]>> *On > Behalf Of *Tony Li > *Sent:* Wednesday, July 28, 2021 1:06 PM > *To:* Les Ginsberg (ginsberg) <[email protected] > <mailto:[email protected]>> > *Cc:* [email protected] <mailto:[email protected]>; Shraddha Hegde > <[email protected] > <mailto:[email protected]>> > *Subject:* Re: [Lsr] Generic metric: application-specific vs > application-independent > > Les, > > ASLA exists to support the advertisement of attributes which can be > used in application specific ways. > > Why do we need separate and different copies of attributes for > different applications? > > The SRLG tries to capture the risk relationships between multiple links. > Those relationships don’t change depending on the application. > > Link attributes don’t require the variability that ASLA provides, and > the overhead is high. How does this cost/benefit ratio make sense? > > In any particular deployment case, a given attribute advertisement > might be used by one app, multiple apps, or all apps. > > ASLA allows to unambiguously support all of these cases with a > single advertisement encoding format. > > The correct question to be resolving here is indeed the question > which has been discussed in an earlier thread: Is Generic Metric a > link attribute which can have application specific use cases? I > think the question to that is unquestionably “yes”. > > That should be enough (IMO of course) to close the discussion. > > Well, one nice thing is that there is an entire space of metrics > available. If application A wants to use metric 16 and application B > wants to use metric 122, that’s already doable. > > Why do we need a separate space per application???? > > Tony > _______________________________________________ Lsr mailing list [email protected] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!XRjGNoWR0M2CiEpLVDMBjuulLjTB0h7iDBL3QlpF442RmMocqTVgRtj6C7O8EGrS$ _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
