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://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
