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. ASLA currently has limitations that make it more complex than necessary for operators who want to evolve their networks this way.
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. 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. 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
