Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

["Les Ginsberg (ginsberg)" <[e-mail]>]

Robert –

Inline.

From: Robert Raszuk <[e-mail]>
Sent: Friday, August 20, 2021 1:29 PM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: Ron Bonica <[e-mail]>; [e-mail]
Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

Hi Les,

Please see below.

It is not just that a new application wants to use the same link attribute value that allows you to use the "all applications" encoding. It is also necessary for the set of links used by the new application to be identical to the set of links used by the existing applications.

Not really. You can use subset of links when you apply affinity bits to it.
[LES:] This isn’t relevant.
Let me try explaining this a different way.

Suppose I have 1000 links in my network.
On 500 of those links I have Attribute #1 advertised using “all applications”. (For the purposes of this discussion it does not matter whether I use the existing 0 length ABM format or the proposed new “A-bit” format)
There are currently two applications, X and Y, deployed in the network and they are both using the same value of attribute #1 on the same set of 500 links.
All is well.

Now, I want to enable application Z. If I do so and make no changes to the existing link attribute advertisements, application Z will think it can use Attribute #1 on all 500 of the links on which the “all” form of the ASLA sub-TLV is being advertised.
If application Z is intended to use all of those 500 links all is well. But if application Z is NOT meant to use one or more of the links on which the ALL ASLA sub-TLVs are being advertised then I have to make changes to at least some of the existing advertisements.

This is why, in RFC 8919/8920, we advise caution in using the “all” form – and why we do not allow both the “all” form and the “app-specific” form to be used by a given application. It is too easy for mistakes to occur, especially when enabling a new application.

Implementations that I am aware of do not send the “ALL” form for this reason i.e., it introduces dependencies between applications which are hard to validate.

Likewise as Peter confirmed you also need to use affinities to select subset of links carrying given flex-algo metric to be used only by some selective flex-algo topologies.


" The solution described in this document is backward compatible with
   [RFC8919] and [RFC8920]."

This is FALSE.

Well I am not sure what Shraddha wanted to express by this sentence or what "backwards" means here. But if you delete "backwards" the rest of the sentence seems just fine.

Let's observe that even if you define a new application and define new bit participating nodes need to support it. That means that you must keep upgrading your OS on all participating nodes each time new new bit is invented.

[LES:] Again, a simple example should suffice.
All routers in my network support application X and application Y.
Some of the routers support the proposed A-bit, some do not.
For the set of links on which applications X and Y are using the same attribute we will then have some links using A-bit ASLA, some not using A-bit ASLA.
For those routers which support the A-bit, they will see links with both styles of ASLA advertisements as usable by applications X and Y.
For those routers which do NOT support A-bit, they will see only the links w/0 A-bit ASLA as usable by applications X and Y.

The point being is that “A-bit” is no different than introducing any other new application bit. Until all routers in the network understand it you cannot safely use it.

   Les


Don't you think this is pretty bad ?

How often do you think operators upgrade their core routers ?

With A-bit and affinities at least your OS is ready to support any application based on already defined metrics without keep inventing new bits.

Of course if we assume velocity of inventing new applications is near zero then this is not a problem. But then the usefulness of ASLA also can be challenged.

Thx,
R.