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

From: Ron Bonica <[email-masked]>
Date: Fri, 20 Aug 2021 03:34:59 +0000

Folks,

Please review and comment.

                        Ron

Juniper Business Use Only

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Thursday, August 19, 2021 11:31 PM
> To: Chris Bowers <[email-masked]>; Robert Raszuk
> <[email-masked]>; Ron Bonica <[email-masked]>; Shraddha Hegde
> <[email-masked]>; Zhenbin Li <[email-masked]>
> Subject: New Version Notification for draft-hegde-lsr-asla-any-app-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> A new version of I-D, draft-hegde-lsr-asla-any-app-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Name:           draft-hegde-lsr-asla-any-app
> Revision:       00
> Title:          The Application Specific Link Attribute (ASLA) Any Application Bit
> Document date:  2021-08-19
> Group:          Individual Submission
> Pages:          6
> URL:
> https://www.ietf.org/archive/id/draft-hegde-lsr-asla-any-app-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-hegde-lsr-asla-any-app
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hegde-lsr-asla-any-app
> 
> 
> Abstract:
>    RFC 8919 and RFC 8920 define Application Specific Link Attributes
>    (ASLA).  Each ASLA includes an Application Identifier Bit Mask.  The
>    Application Identifier Bit Mask includes a Standard Application Bit
>    Mask (SABM) and a User Defined Application Bit Mask (UDABM).  The
>    SABM and UDABM determine which applications can use the ASLA as an
>    input.
> 
>    This document introduces a new bit to the Standard Application
>    Identifier Bit Mask.  This bit is called the Any Application Bit
>    (i.e., the A-bit).  If the A-bit is set, the link attribute can be
>    used by any application.  This includes currently defined
>    applications as well as applications to be defined in the future.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 20 Aug 2021 18:38:15 +0000

Draft authors -

Comment #1

Regarding the example discussed in the Introduction, let's see if I understand it correctly.

There are three (possibly more) applications enabled in the network. Let's call them X, Y, and Z.
There are two attribute types being advertised on a given (set of) link(s).

Attribute 1: To be used by X, Y, and Z
Attribute 2: To be used by X and Y only.

If we use existing RFC 8919/8920 rules, here is how this would be advertised for a given link:

ASLA sub-TLV #1:
   SABM = X|Y|Z
   Attribute 1 Value

ASLA sub-TLV #2:
  SABM = X|Y
  Attribute 2 Value

If we use your new proposal with the "A" bit, here is how the advertisements would look:

ASLA sub-TLV #1:
   SABM = A
   Attribute 1 Value

ASLA sub-TLV #2:
  SABM = X|Y
  Attribute 2 Value

I do not see any value add here to your proposal.
???

Perhaps you are thinking about what happens when a fourth application is introduced into the network (let's call it "W").
If we wanted W to also use attribute #1, then using RFC 8919/8920 rules we would alter sub-TLV #1 to include "W":

ASLA sub-TLV #1:
   SABM = W|X|Y|Z
   Attribute 1 Value

Whereas when using the A-bit you could continue to use sub-TLV#1 w A bit unchanged.

But, use of all applications encoding - whether using RFC 8919/8920 zero length ABM or potentially a new "A" bit, has to be done with care. This is discussed in some detail in https://www.rfc-editor.org/rfc/rfc8919.html#section-6.2
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.
RFC 8919/8920 provides for "all applications" in order to gain encoding efficiency when possible, but because it is not just attribute type/value sharing that is required but also identical set of links/application, the usefulness of such encoding is limited.
Although there may be some situations where it is possible for an "all applications" encoding to be used, it requires some amount of clairvoyance since one does not know what set of links a new application might want to use until it comes time to actually deploy that new application.

Comment #2:

There is a statement in Section 4:

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

This is FALSE.

Implementations which do NOT support the new A-bit would ignore it and not use the link attributes advertised with only the A-bit. So, in order to use it all nodes have to support the A-bit - or at least all nodes on which the applications which you want to use A-bit advertisements must support it. Otherwise, for a given application, some nodes will believe a link can be used by that application and other nodes will believe that the link cannot be used by that application - which is likely to break the deployment of that application.

   Les

> From: Lsr <[email-masked]> On Behalf Of Ron Bonica
> Sent: Thursday, August 19, 2021 8:35 PM
> To: [email-masked]
> Subject: [Lsr] FW: New Version Notification for draft-hegde-lsr-asla-any-app-
> 00.txt
> 
> Folks,
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Aug 2021 22:28:35 +0200

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.

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.

>    [RFC8919] and [RFC8920]."

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.

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 20 Aug 2021 23:33:59 +0000

Robert –

Inline.

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

Hi Les,

Please see below.

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.

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

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.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 21 Aug 2021 02:00:36 +0200

Hi Les,

*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.*

That is true.

But the entire point of A-bit is that you are doing this exercise to make
sure your routers understand A-bit only one time.

Otherwise you need to do it each time you invent a new bit.

Thx,
R.

On Sat, Aug 21, 2021 at 1:34 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Robert –
>
>
>
> Inline.
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Friday, August 20, 2021 1:29 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Ron Bonica <[email-masked]>; [email-masked]
> *Subject:* Re: [Lsr] New Version Notification for
> draft-hegde-lsr-asla-any-app-00.txt
>
>
>
> Hi Les,
>
>
>
> Please see below.
>
>
>
> *[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.*
>
>
>
> 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
> *[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*
>
>
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 21 Aug 2021 00:06:30 +0000

Robert -

Sent: Friday, August 20, 2021 5:01 PM

Hi Les,

That is true.

But the entire point of A-bit is that you are doing this exercise to make sure your routers understand A-bit only one time.
[LES:] This does not mean that you can introduce support for a new application (call it “bit N”) w/o upgrading your routers simply because you already have A-bit support. I hope that is obvious. 😊

My original point was simply  that the statement about “backwards compatibility” regarding A-bit isn’t accurate. Good that we now agree on that.

   Les

Thx,
R.

On Sat, Aug 21, 2021 at 1:34 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

Inline.

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

Hi Les,

Please see below.

This is FALSE.

   Les

Thx,
R.

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 21 Aug 2021 09:04:27 +0200

My quick take:

1. yes, A bit will necessitate being either deployed in a well understood
part of the network (because as Les says old nodes will basically see _no_
application [which seems desirable, they basically take themselves out]) or
forklifting. Not that different from flex-algo being same kind of forklift
AFAIS.
2. any application introduced after that will precondition implementation
of A bit if we don't want to get into the rathole of "do not encode using
A, encode using repetition per application if you have old routers".

I see a value in the "A" bit from multiple angles (which I do not read as
"all applications" but "any application". The distinction is subtle but
important)

a) it fits what flex-algo needs in ASLA architecture. E'one wins AFAIS.
b) if we want to replace A with X|Y|Z we need to know on a router about
_all_ applications on all routers and that may be non-trivial and on every
change may force re-adverts (unless we set all bits 1 on a 8 bytes ASLA
mask [as in _all_ applications]. That does not seem like a good idea given
the encoding sizes). A as "any" basically means "any application on this
router uses this metric" and avoids both problems. Significantly simpler
AFAIS.

A very, very subtle point (I didn't read the 'a' draft yet so it may be
taken care of) is whether SABM length is 1 with all 0s or length is 0 on A
bit presence and if 0 will the current implementations hold up to that ;-)

Les, correct me if I'm off somewhere, I was watching lots of that just from
the corner of my eye ;-)

-- tony

On Sat, Aug 21, 2021 at 2:06 AM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> *Sent:* Friday, August 20, 2021 5:01 PM
> *[LES:] This does not mean that you can introduce support for a new
> application (call it “bit N”) w/o upgrading your routers simply because you
> already have A-bit support. I hope that is obvious. **😊*
>
>
>
> *My original point was simply  that the statement about “backwards
> compatibility” regarding A-bit isn’t accurate. Good that we now agree on
> that.*
>
>
>
> *   Les*
>
>
>
> On Sat, Aug 21, 2021 at 1:34 AM Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Robert –
>
>
>
> Inline.
>
>
>
> *All is well.*

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 21 Aug 2021 11:41:08 +0200

> already have A-bit support. I hope that is obvious. **😊*

I beg to differ.

In my books you can create new interesting topologies simply by selecting
existing existing metrics on subset of links. And still say run Dijkstra on
it.

In your view - new application MUST use new metric which is something I
fundamentally disagree with.

> compatibility” regarding A-bit isn’t accurate. Good that we now agree on

That is correct IMO.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 21 Aug 2021 11:51:32 +0200

Tony

> I see a value in the "A" bit from multiple angles (which I do not read as
"all applications" but "any application".

Spot on ! Yes we did mean "any app" not "all apps". Even title says "any"
:) Each app can still cherry pick what it uses in FAD.

> (I didn't read the 'a' draft yet so it may be taken care of) is whether
SABM length is 1 with all 0s or
> length is 0 on A bit presence and if 0 will the current implementations
hold up to that ;-)

I am not following this one ...

SABM length in octets describes length of the actual application bit
octets. A-bit or R,S,F,X are part of it.

So for A-bit length must be at least 1 or more.

But now comes Les and says:

*> (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)*

That to me is ambiguous as it sort of means that 0 length ABM flags may be
defined as any application.

If that would be the case (which I believe is not today) then indeed no
need to define A-bit.

Cheers,
R.

On Sat, Aug 21, 2021 at 9:05 AM Tony Przygienda <[email-masked]> wrote:

> Les, correct me if I'm off somewhere, I was watching lots of that just
> from the corner of my eye ;-)
>
> -- tony
>
>
>
>> 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.
>>
>>
>>
>> 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
>> 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.
>>
>>
>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 21 Aug 2021 14:40:53 +0000

Tony –

There already is a way to advertise link attributes to be used by “all/any application” defined in RFC 8919/8920: Use a zero length ABM.
However, it comes with a restriction: if there exists any ASLA advertisement of link attributes with a non-zero ABM that includes a given application bit, that application MUST NOT use any attributes advertised in the zero length ABM advertisement.

It is that restriction which the authors of draft-hegde-lsr-asla-any-app wish to avoid – so they have proposed an alternate way of advertising “any/all applications” – which is to use the new A-bit.

Why did we introduce the restriction that if there were application specific advertisements for a link for application X that it MUST NOT use the “all-APPs” advertisements? We did this because once there were some attributes advertised specific to a given application, we thought it became significantly less probable that it was safe to assume that the other attributes advertised in “all-APPs” applied to application X. We thought that it was less ambiguous to say – for a given application – either you use the attributes advertised in “all-APPs” – or you use the attributes in the advertisements which explicitly mention X – but not both. (This, BTW, implicitly resolves the question of what happens when the same attribute is advertised in both forms.)

The more important point is that there are two “dimensions” to consider when using an “all-APPs” style advertisement.
Dimension #1 is the more obvious one: the values associated with the attributes advertised MUST be the same for all of the apps.
But there is a second dimension – which is that the existence of an “all-APPs” advertisement on a given link implicitly means that all applications which have been enabled in the network are using that link.
It is this second dimension which has to be considered carefully before using an “all-APPs” advertisement.
It is easy to come up with examples of link attributes whose value is expected to be the same for any application using that link – maximum link bandwidth is an obvious one which exists today. But Ron has suggested other possible attributes which can easily be seen as falling into the same category.
But, as I explained in one of my replies to Robert, assuming that a new application introduced into the network is intended to use the exact same set of links that are being used by the already deployed applications is much more problematic.

I believe the authors of draft-hegde-lsr-asla-any-app are focused on the first dimension and have not fully considered the second dimension.

One could debate whether the existing “all-APPs” using zero length ABM defined in RFC 8919/8920 is better or worse than the proposed “any-APPs” using A-bit. But given the extremely limited differences in actual usage between the two (please see my original reply on this thread) I don’t think this is worth the time. And as introduction of A-bit would require implementations to handle the various combinations of possible deployments (only zero ABM, mix of zero-ABM and A-bit, all A-bit) I do not see that ROI is worth it.

A few more responses inline.

From: Tony Przygienda <[email-masked]>
Sent: Saturday, August 21, 2021 12:04 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]
Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

My quick take:

1. yes, A bit will necessitate being either deployed in a well understood part of the network (because as Les says old nodes will basically see _no_ application [which seems desirable, they basically take themselves out]) or forklifting. Not that different from flex-algo being same kind of forklift AFAIS.
2. any application introduced after that will precondition implementation of A bit if we don't want to get into the rathole of "do not encode using A, encode using repetition per application if you have old routers".

I see a value in the "A" bit from multiple angles (which I do not read as "all applications" but "any application". The distinction is subtle but important)

[LES:] Nothing about this discussion is flex-algo specific. And I do not see any gaps in current flex-algo support which this proposal fills.
I understand some folks might like one proposal more than another, but there is no existing functionality gap.

b) if we want to replace A with X|Y|Z we need to know on a router about _all_ applications on all routers and that may be non-trivial and on every change may force re-adverts (unless we set all bits 1 on a 8 bytes ASLA mask [as in _all_ applications]. That does not seem like a good idea given the encoding sizes). A as "any" basically means "any application on this router uses this metric" and avoids both problems. Significantly simpler AFAIS.

[LES:] Please see my discussion above.

A very, very subtle point (I didn't read the 'a' draft yet so it may be taken care of) is whether SABM length is 1 with all 0s or length is 0 on A bit presence and if 0 will the current implementations hold up to that ;-)

[LES:] As a bit in the ABM has to be assigned to “A”, this means that the advertised ABM length is non-zero.
There is also the question as to whether we need an A-bit in both the SABM and UDABM fields (I would think “yes” given the intended independence of the two fields. This is not discussed in the draft.)

An alternative would be to remove the restriction associated with zero-length ABM and allow all applications to use such advertisements even in the presence application specific advertisements. This wouldn’t be backwards compatible of course. And, for the reasons I mentioned above, I believe the current restrictions provide greater safety – so I am not in favor of this.

   Les

Les, correct me if I'm off somewhere, I was watching lots of that just from the corner of my eye ;-)

-- tony

On Sat, Aug 21, 2021 at 2:06 AM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
Robert -

Hi Les,

That is true.

   Les

Thx,
R.

Inline.

Hi Les,

Please see below.

This is FALSE.

   Les

Thx,
R.

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 21 Aug 2021 14:49:46 +0000

Robert -

Sent: Saturday, August 21, 2021 2:41 AM

I beg to differ.
[LES:] Your statement suggests (and I am certain you do not mean to do so) that if only we had the foresight to define the A-bit in RFC 8919/8920 that we could have introduced support for Flex-Algo without writing any new code at all. 😊

We are talking here about a NEW APPLICATION. The only existing example we have today (post RFC 8919/8920) is Flex-Algo – but given time I expect some other application will come along. What that will be and what kinds of calculations/attributes it might require is something we do not currently know. The syntax used to advertise link attributes does not magically allow new applications to be supported without adding new code to the nodes.

   Les

In my books you can create new interesting topologies simply by selecting existing existing metrics on subset of links. And still say run Dijkstra on it.

In your view - new application MUST use new metric which is something I fundamentally disagree with.

That is correct IMO.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 21 Aug 2021 19:32:17 +0200

Les,

I beg to differ.
>
> *[LES:] Your statement suggests (and I am certain you do not mean to do
> so) that if only we had the foresight to define the A-bit in RFC 8919/8920
> that we could have introduced support for Flex-Algo without writing any new
> code at all. **😊*
>

Nope. I meant to say that having support for flex-algo and FAD I can think
of new applications without need to write a new router's code (assuming
existing code is flexible enough :).

After all, aren't we in the era of network programming ?

> *We are talking here about a NEW APPLICATION. The only existing example we
> have today (post RFC 8919/8920) is Flex-Algo – but given time I expect some
> other application will come along. What that will be and what kinds of
> calculations/attributes it might require is something we do not currently
> know. The syntax used to advertise link attributes does not magically allow
> new applications to be supported without adding new code to the nodes.*
>

See above.

And I will perhaps say it again that to me flex-algo is more of a mechanism
to build new applications then NEW APPLICATION itself.

That is why if we would adhere well to ASLA architecture there should be
many more bits for it then one.

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Sun, 22 Aug 2021 15:07:59 +0200

Robert,

On 21/08/2021 19:32, Robert Raszuk wrote:
> Les,
> 
>     I beg to differ. ____
> 
>     */[LES:] Your statement suggests (and I am certain you do not mean
>     to do so) that if only we had the foresight to define the A-bit in
>     RFC 8919/8920 that we could have introduced support for Flex-Algo
>     without writing any new code at all. /**/😊/*
> 
> 
> Nope. I meant to say that having support for flex-algo and FAD I can 
> think of new applications without need to write a new router's code 
> (assuming existing code is flexible enough :).
> 
>     *//**/____/*
>     */We are talking here about a NEW APPLICATION. The only existing
>     example we have today (post RFC 8919/8920) is Flex-Algo – but given
>     time I expect some other application will come along. What that will
>     be and what kinds of calculations/attributes it might require is
>     something we do not currently know. The syntax used to advertise
>     link attributes does not magically allow new applications to be
>     supported without adding new code to the nodes./*
> 
> 
> See above.
> 
> And I will perhaps say it again that to me flex-algo is more of a 
> mechanism to build new applications then NEW APPLICATION itself.

no, flex-algo is a single application, it's not a mechanism to create 
new applications. The fact that you can create many constraints 
topologies using flex-algo, does not mean these should be considered as 
different apps. You have to put and keep clear borders at clear places. 
We have them defined by ASLA and by base flex-algo draft.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 22 Aug 2021 15:33:26 +0200

Hey Peter,

> We have them defined by ASLA and by base flex-algo draft.

Why each constrained topology can not be intuitively called a different
network application ?

Is there any real definition of "IGP application" LSR WG has converged and
agreed upon ?

See your take that it is implicitly defined in flex-algo draft by setting
one bit to it in SABM is IMO pretty weak. Maybe it would hold if you forbid
to use UDABM for flex-algo metrics, but I do not see such restriction
anywhere in flex-algo draft nor in ASLA drafts. That means that
implementation may allow it.

So flex algo is a single app if we use SABM, but it can be multiple apps if
we use UDABM ? Don't you think this is a bit loose definition ?

Cheers,
R.

---

From: Peter Psenak <[email-masked]>
Date: Sun, 22 Aug 2021 15:43:06 +0200

Hi Robert,

> Why each constrained topology can not be intuitively called a different 

1. because flex-algo draft (which has been last called by the LSR WG 
already) defines flex-algo as a single application from the ASLA 
perspective.

2. I do not see why one would want to make application out of each 
constrained topology.

> 
> Is there any real definition of "IGP application" LSR WG has 
> converged and agreed upon ?

no, but there is a document that defines flex-algo as a single application.

> 
> See your take that it is implicitly defined in flex-algo draft by 
> setting one bit to it in SABM is IMO pretty weak. Maybe it would hold if 
> you forbid to use UDABM for flex-algo metrics, but I do not see such 
> restriction anywhere in flex-algo draft nor in ASLA drafts. That means 
> that implementation may allow it.

usage of bits in UDABM is not specified. It's user defined and not 
standardized by IETF
> 
> So flex algo is a single app if we use SABM, but it can be multiple apps 
> if we use UDABM ? Don't you think this is a bit loose definition ?

no, because the UDABM bits is not something that IETF is going to specify.

thanks,
Peter

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 22 Aug 2021 20:51:15 +0200

On Sat, Aug 21, 2021 at 11:51 AM Robert Raszuk <[email-masked]> wrote:

> Tony
>
> > I see a value in the "A" bit from multiple angles (which I do not read
> as "all applications" but "any application".
>

ok, yepp, as I said, I did not scan the draft yet and if all that has been
abundantly clear no damage in spelling it out again.

> defined as any application.

it's not a good suggestion AFAIS, a natural semantics for 0 length ABM is
realy "_no_ application"

>>> But the entire point of A-bit is that you are doing this exercise to
>>> make sure your routers understand A-bit only one time.
>>>
>>> *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.*
>>>
>>>
>>>
>>> *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.*
>>>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 23 Aug 2021 06:37:12 +0000

>Implementations which do NOT support the new A-bit would ignore it and not use the link attributes advertised >with only the A-bit. So, in order to use it all nodes have to support the A-bit - or at least all nodes on which the >applications which you want to use A-bit advertisements must support it. Otherwise, for a given application, some >nodes will believe a link can be used by that application and other nodes will believe that the link cannot be used by >that application - which is likely to break the deployment of that application.

The draft clearly states that if there are advertisements with specific application bit set, that attribute MUST be picked by the application. So a node that is upgraded to advertise A bit can continue to advertise attributes with
Specific application bit set until all participating nodes in that application are upgraded to understand A bit.
It is quite obvious that until all nodes are upgraded to understand new bit, they cant use it. But as long as the
New bit procedures  ensures and honors the old advertisements, and does not cause inconsistencies between 
Upgraded and not upgraded nodes in the network it is backward compatible. 

For example, if the new A bit procedures mandated the attributes under A bit gets precedence then that would
Not be backward compatible.

Rgds
Shraddha

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, August 21, 2021 12:08 AM
To: Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

Draft authors -

Comment #1

ASLA sub-TLV #1:
   SABM = X|Y|Z
   Attribute 1 Value

ASLA sub-TLV #2:
  SABM = X|Y
  Attribute 2 Value

ASLA sub-TLV #1:
   SABM = A
   Attribute 1 Value

ASLA sub-TLV #2:
  SABM = X|Y
  Attribute 2 Value

ASLA sub-TLV #1:
   SABM = W|X|Y|Z
   Attribute 1 Value

But, use of all applications encoding - whether using RFC 8919/8920 zero length ABM or potentially a new "A" bit, has to be done with care. This is discussed in some detail in https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8919.html*section-6.2__;Iw!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvTkV3P5eLay-Idc_l_ZIaEFgbm5geHR43u3f$
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.
RFC 8919/8920 provides for "all applications" in order to gain encoding efficiency when possible, but because it is not just attribute type/value sharing that is required but also identical set of links/application, the usefulness of such encoding is limited.
Although there may be some situations where it is possible for an "all applications" encoding to be used, it requires some amount of clairvoyance since one does not know what set of links a new application might want to use until it comes time to actually deploy that new application.

Comment #2:

This is FALSE.

   Les

> Subject: [Lsr] FW: New Version Notification for 
> draft-hegde-lsr-asla-any-app- 00.txt
>
> Folks,
>
> > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-he
> > gde-lsr-asla-any-app-00.txt__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1
> > D0bYvTkV3P5eLay-Idc_l_ZIaEFgbm5geAxsITdt$
> > Status:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-h
> > egde-lsr-asla-any-app__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvT
> > kV3P5eLay-Idc_l_ZIaEFgbm5geNWXUEXS$
> > Htmlized:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
> > aft-hegde-lsr-asla-any-app__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D
> > 0bYvTkV3P5eLay-Idc_l_ZIaEFgbm5geFUeB-LY$
> >
> >
> > Abstract:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvTkV3P5eLay-Idc_l_ZIaEFgbm
> 5geLZeit_R$

_______________________________________________
Lsr mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvTkV3P5eLay-Idc_l_ZIaEFgbm5geLZeit_R$

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 23 Aug 2021 14:37:59 +0000

Shraddha -

> From: Shraddha Hegde <shraddha=[email-masked]>
> Sent: Sunday, August 22, 2021 11:37 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>; Ron Bonica
> <[email-masked]>; [email-masked]
> Subject: RE: New Version Notification for draft-hegde-lsr-asla-any-app-00.txt
> 
> >Implementations which do NOT support the new A-bit would ignore it and
> not use the link attributes advertised >with only the A-bit. So, in order to use
> it all nodes have to support the A-bit - or at least all nodes on which the
> >applications which you want to use A-bit advertisements must support it.
> Otherwise, for a given application, some >nodes will believe a link can be
> used by that application and other nodes will believe that the link cannot be
> used by >that application - which is likely to break the deployment of that
> application.
> 
> The draft clearly states that if there are advertisements with specific
> application bit set, that attribute MUST be picked by the application. So a
> node that is upgraded to advertise A bit can continue to advertise attributes
> with
> It is quite obvious that until all nodes are upgraded to understand new bit,
> they cant use it. 

[LES:] "Backwards compatible" (to me anyways...) means that you can introduce use of the new bit even in the presence of nodes which do not support it.
You seem to agree that is not possible - which is the point I am trying to make.

   Les

> But as long as the
> Perhaps you are thinking about what happens when a fourth application is
> introduced into the network (let's call it "W").
> But, use of all applications encoding - whether using RFC 8919/8920 zero
> length ABM or potentially a new "A" bit, has to be done with care. This is
> discussed in some detail in https://urldefense.com/v3/__https://www.rfc-
> editor.org/rfc/rfc8919.html*section-6.2__;Iw!!NEt6yMaO-
> gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvTkV3P5eLay-
> Idc_l_ZIaEFgbm5geHR43u3f$
> 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.
> RFC 8919/8920 provides for "all applications" in order to gain encoding
> efficiency when possible, but because it is not just attribute type/value
> sharing that is required but also identical set of links/application, the
> usefulness of such encoding is limited.
> Although there may be some situations where it is possible for an "all
> applications" encoding to be used, it requires some amount of clairvoyance
> since one does not know what set of links a new application might want to
> use until it comes time to actually deploy that new application.
> 
> 
> Comment #2:
> 
> Implementations which do NOT support the new A-bit would ignore it and
> not use the link attributes advertised with only the A-bit. So, in order to use it
> all nodes have to support the A-bit - or at least all nodes on which the
> applications which you want to use A-bit advertisements must support it.
> Otherwise, for a given application, some nodes will believe a link can be used
> by that application and other nodes will believe that the link cannot be used
> by that application - which is likely to break the deployment of that
> application.
> 
>    Les
> 
> 
> 
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!
> !NEt6yMaO-gk!QhFL_ZQV3cj7Rmvh8lVarlq1D0bYvTkV3P5eLay-
> Idc_l_ZIaEFgbm5geLZeit_R$

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 23 Aug 2021 15:22:20 +0000

Les,

------------------------------------------------------------------------------------------------------------------------------------------
> But there is a second dimension – which is that the existence of an “all-APPs” advertisement on a given
>link implicitly means that all applications which have been enabled in the network are using that link.
------------------------------------------------------------------------------------------------------------------------------------------

It seems to me that this statement illustrates a disconnect.
Which links are included/excluded from application’s topology is defined by applications.
It has been discussed in this list multiple times that the existing applications (RSVP, SR-TE, LFA)
use admin-groups/link-affinities to include/exclude links.
Flex-algo is a new application and it has been discussed in this thread that admin-group/link-affinities is the
best way to include/exclude links from different flex-algo topologies.

You are arguing that applications will use advertisement of ASLA attributes as indication
to include/exclude links from the
Topology. Are you referring to new applications that are going to be invented in future?
If so, it would be good to get concrete examples of those future applications.

Rgds
Shraddha

Juniper Business Use Only
From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, August 21, 2021 8:11 PM
To: Tony Przygienda <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

Tony –

From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, August 21, 2021 12:04 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

My quick take:

   Les

-- tony

Hi Les,

That is true.

   Les

Thx,
R.

Inline.

Hi Les,

Please see below.

This is FALSE.

   Les

Thx,
R.

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!VZrcMcSTqfd9NuBXlnhGPjQVxztcMMIkLf0cjL21aaMI7UfRdzqx6VBLDV32y57n$>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 23 Aug 2021 17:02:46 +0000

From: Shraddha Hegde <shraddha=[email-masked]>
Sent: Monday, August 23, 2021 8:22 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Tony Przygienda <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Subject: RE: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

Les,

It seems to me that this statement illustrates a disconnect.
[LES:] Indeed – this is a key point – but the misunderstanding is on your part. Please let me explain.

One of the lessons we learned from RSVP-TE was that deployments suffered because there was no standard definition of what indicated use of a link by RSVP-TE. Different vendors had different internal definitions and it was left to customers to unravel this and come up with configurations that allowed interoperability. This issue was further highlighted with the introduction of other applications (e.g., SRTE) because it was not possible to distinguish what constituted links in use for SRTE vs links in use by RSVP-TE. Therefore , one of the issues ASLA set out to fully address was to make explicit the association of link attribute advertisements with the application(s) which use them. The following text from https://www.rfc-editor.org/rfc/rfc8919.html#section-2 is relevant:

“There is no requirement for the link attributes advertised on a given link used by SR Policy to be identical to the link attributes advertised on that same link used by RSVP-TE; thus, there is a clear requirement to indicate independently which link attribute advertisements are to be used by each application.”

Requiring ALL applications to use affinity to indicate whether link attribute advertisements are to be used by a given application imposes an unnecessary restriction. For example, suppose I have an application that wants to use only links with a certain (set of) SRLG value(s) and a certain interface type? There is no reason to require the operator to – in addition to assigning an SRLG value to a link – to require that a specific affinity value also be assigned to that link.

The operational behavior is that ASLA defines the association between a set of advertisements and an application.
Affinities support the inclusion/exclusion semantic within a given application.

The explicit association of a link with an application that ASLA provides is one of the essential elements of the ASLA solution.

HTH clarify.

    Les

Rgds
Shraddha

Juniper Business Use Only
From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, August 21, 2021 8:11 PM
To: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

Tony –

My quick take:

   Les

-- tony

Hi Les,

That is true.

   Les

Thx,
R.

Inline.

Hi Les,

Please see below.

This is FALSE.

   Les

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 Aug 2021 19:17:03 +0200

Les,

Your point is brilliant and valid if you assume flex-algo will be a *single*
topology. And in few networks that may be indeed the case.

But the very moment customers want to use more then one flex-algo topology
with selective set of metrics and links you are back to the exactly same
set of problems you are clearly describing which led to ASLA. And as we all
agreed use of hand crafted set of affinities is again the only to in the
tool box to come to the rescue.

So maybe its time to admit it and fix the flex-algo spec ?

Cheers,
R.

On Mon, Aug 23, 2021 at 7:03 PM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

>
>
>
>
> *From:* Shraddha Hegde <shraddha=[email-masked]>
> *Sent:* Monday, August 23, 2021 8:22 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; Tony Przygienda <
> [email-masked]>
> *Cc:* Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>;
> [email-masked]
> *Subject:* RE: [Lsr] New Version Notification for
> *[LES:] Indeed – this is a key point – but the misunderstanding is on your
> part. Please let me explain.*
>
>
>
> *One of the lessons we learned from RSVP-TE was that deployments suffered
> because there was no standard definition of what indicated use of a link by
> RSVP-TE. Different vendors had different internal definitions and it was
> left to customers to unravel this and come up with configurations that
> allowed interoperability. This issue was further highlighted with the
> introduction of other applications (e.g., SRTE) because it was not possible
> to distinguish what constituted links in use for SRTE vs links in use by
> RSVP-TE. Therefore , one of the issues ASLA set out to fully address was to
> make explicit the association of link attribute advertisements with the
> application(s) which use them. The following text from
> https://www.rfc-editor.org/rfc/rfc8919.html#section-2
> <https://www.rfc-editor.org/rfc/rfc8919.html#section-2> is relevant:*
>
>
>
> *“There is no requirement for the link attributes advertised on a given
> link used by SR Policy to be identical to the link attributes advertised on
> that same link used by RSVP-TE; thus, there is a clear requirement to
> indicate independently which link attribute advertisements are to be used
> by each application.”*
>
>
>
> *Requiring ALL applications to use affinity to indicate whether link
> attribute advertisements are to be used by a given application imposes an
> unnecessary restriction. For example, suppose I have an application that
> wants to use only links with a certain (set of) SRLG value(s) and a certain
> interface type? There is no reason to require the operator to – in addition
> to assigning an SRLG value to a link – to require that a specific affinity
> value also be assigned to that link.*
>
>
>
> *The operational behavior is that ASLA defines the association between a
> set of advertisements and an application.*
>
> *Affinities support the inclusion/exclusion semantic within a given
> application.*
>
>
>
> *The explicit association of a link with an application that ASLA provides
> is one of the essential elements of the ASLA solution.*
>
>
>
> *HTH clarify.*
>
>
>
> *    Les*
>
>
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Les Ginsberg (ginsberg)
> *Sent:* Saturday, August 21, 2021 8:11 PM
> *To:* Tony Przygienda <[email-masked]>
> *Cc:* Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>;
> [email-masked]
> *[External Email. Be cautious of content]*
>
>
>
> Tony –
>
>
>
> There already is a way to advertise link attributes to be used by “all/any
> application” defined in RFC 8919/8920: Use a zero length ABM.
>
> However, it comes with a restriction: if there exists any ASLA
> advertisement of link attributes with a non-zero ABM that includes a given
> application bit, that application MUST NOT use any attributes advertised in
> the zero length ABM advertisement.
>
>
>
> It is that restriction which the authors of draft-hegde-lsr-asla-any-app
> wish to avoid – so they have proposed an alternate way of advertising
> “any/all applications” – which is to use the new A-bit.
>
>
>
> Why did we introduce the restriction that if there were application
> specific advertisements for a link for application X that it MUST NOT use
> the “all-APPs” advertisements? We did this because once there were some
> attributes advertised specific to a given application, we thought it became
> significantly less probable that it was safe to assume that the other
> attributes advertised in “all-APPs” applied to application X. We thought
> that it was less ambiguous to say – for a given application – either you
> use the attributes advertised in “all-APPs” – or you use the attributes in
> the advertisements which explicitly mention X – but not both. (This, BTW,
> implicitly resolves the question of what happens when the same attribute is
> advertised in both forms.)
>
>
>
> The more important point is that there are two “dimensions” to consider
> when using an “all-APPs” style advertisement.
>
> Dimension #1 is the more obvious one: the values associated with the
> attributes advertised MUST be the same for all of the apps.
>
> But there is a second dimension – which is that the existence of an
> “all-APPs” advertisement on a given link implicitly means that all
> applications which have been enabled in the network are using that link.
>
> It is easy to come up with examples of link attributes whose value is
> expected to be the same for any application using that link – maximum link
> bandwidth is an obvious one which exists today. But Ron has suggested other
> possible attributes which can easily be seen as falling into the same
> category.
>
> But, as I explained in one of my replies to Robert, assuming that a new
> application introduced into the network is intended to use the exact same
> set of links that are being used by the already deployed applications is
> much more problematic.
>
>
>
> I believe the authors of draft-hegde-lsr-asla-any-app are focused on the
> first dimension and have not fully considered the second dimension.
>
>
>
> One could debate whether the existing “all-APPs” using zero length ABM
> defined in RFC 8919/8920 is better or worse than the proposed “any-APPs”
> using A-bit. But given the extremely limited differences in actual usage
> between the two (please see my original reply on this thread) I don’t think
> this is worth the time. And as introduction of A-bit would require
> implementations to handle the various combinations of possible deployments
> (only zero ABM, mix of zero-ABM and A-bit, all A-bit) I do not see that ROI
> is worth it.
>
>
>
> *From:* Tony Przygienda <[email-masked]>
> *Sent:* Saturday, August 21, 2021 12:04 AM
> *Cc:* Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>;
> [email-masked]
> *[LES:] Nothing about this discussion is flex-algo specific. And I do not
> see any gaps in current flex-algo support which this proposal fills.*
>
> *I understand some folks might like one proposal more than another, but
> there is no existing functionality gap.*
>
>
>
> *[LES:] Please see my discussion above. *
>
>
>
> *[LES:] As a bit in the ABM has to be assigned to “A”, this means that the
> advertised ABM length is non-zero.*
>
> *There is also the question as to whether we need an A-bit in both the
> SABM and UDABM fields (I would think “yes” given the intended independence
> of the two fields. This is not discussed in the draft.)*
>
>
>
> *An alternative would be to remove the restriction associated with
> zero-length ABM and allow all applications to use such advertisements even
> in the presence application specific advertisements. This wouldn’t be
> backwards compatible of course. And, for the reasons I mentioned above, I
> believe the current restrictions provide greater safety – so I am not in
> favor of this.*
>
>
>
> *   Les*
>
>
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!VZrcMcSTqfd9NuBXlnhGPjQVxztcMMIkLf0cjL21aaMI7UfRdzqx6VBLDV32y57n$>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 23 Aug 2021 17:28:53 +0000

Robert –

You continue to confuse Flex and ASLA.

ASLA is an architecture that supports multiple applications – of which Flex is just one of the supported applications.

Flex is a specific application which supports multiple “sets of constraints” – AKA algorithms.

Please do not attempt to make ASLA Flex-specific – that would unduly constrain future applications to be “just-like Flex”.
And, Flex is doing just fine as it is – one of the indicators of which I believe is your enthusiasm for it. 😊

   Les

From: Robert Raszuk <[email-masked]>
Sent: Monday, August 23, 2021 10:17 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Shraddha Hegde <[email-masked]>; Tony Przygienda <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]
Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

Les,

Your point is brilliant and valid if you assume flex-algo will be a single topology. And in few networks that may be indeed the case.

But the very moment customers want to use more then one flex-algo topology with selective set of metrics and links you are back to the exactly same set of problems you are clearly describing which led to ASLA. And as we all agreed use of hand crafted set of affinities is again the only to in the tool box to come to the rescue.

Cheers,
R.

On Mon, Aug 23, 2021 at 7:03 PM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:

From: Shraddha Hegde <shraddha=[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 23, 2021 8:22 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

Les,

HTH clarify.

    Les

Rgds
Shraddha

Tony –

My quick take:

   Les

-- tony

Hi Les,

That is true.

   Les

Thx,
R.

Inline.

Hi Les,

Please see below.

This is FALSE.

   Les

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 Aug 2021 19:44:25 +0200

> You continue to confuse Flex and ASLA.

I don't think so ... This thread is about ASLA encoding for Flex-Algo.

> ASLA is an architecture that supports multiple applications – of which
> Flex is just one of the supported applications.
>

Care to elaborate why ASLA SABM allows only 64 applications ? Even MT
allowed 4K topologies.

Flex is a specific application which supports multiple “sets of
> constraints” – AKA algorithms.
>

With that definition everything is Flex. Topologies differ one from another
by running SPT on a different sets of links with different "sets of
constraints"

> believe is your enthusiasm for it. 😊

Let's see if the reverse works :)

Best,
R,

---

From: Peter Psenak <[email-masked]>
Date: Mon, 23 Aug 2021 19:56:23 +0200

Robert,

On 23/08/2021 19:44, Robert Raszuk wrote:
>     ____
>     ASLA is an architecture that supports multiple applications – of
>     which Flex is just one of the supported applications.
> 
> 

because application is not equivalent of MT, topology or flex-algo or 
SPT. There are clear borders defined, please consider them.

> With that definition everything is Flex. 

I'm afraid you got it wrong.

>Topologies differ one from 
> another by running SPT on a different sets of links with different "sets 
> of constraints"

SPT/topology is not equal to application. One can define an application 
that does not not even use any SPT. Please think in a more generic way.

thanks,
Peter

> 
>     ____
> 
>     And, Flex is doing just fine as it is – one of the indicators of
>     which I believe is your enthusiasm for it. 😊
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 Aug 2021 20:02:51 +0200

> that does not not even use any SPT. Please think in a more generic way.

That is 100% true.

But nothing should prevent  me from defining an application the way I
choose to.

Many thx,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 23 Aug 2021 18:24:40 +0000

Robert –

Sent: Monday, August 23, 2021 10:44 AM

I don't think so ... This thread is about ASLA encoding for Flex-Algo.
[LES:] Noooo --- please read your own draft. 😊]
The work “Flex” does not appear anywhere in the draft – nor should it.

Care to elaborate why ASLA SABM allows only 64 applications ? Even MT allowed 4K topologies.

[LES:] Application != topology
As you see, a single application (Flex) can support multiple “topologies” – but that is orthogonal.
The real issue here is you continue to not fully understand the distinction between an “application” and the capabilities of a given application – one of which may be to support multiple “topologies”.
Flex is a specific application which supports multiple “sets of constraints” – AKA algorithms.

With that definition everything is Flex. Topologies differ one from another by running SPT on a different sets of links with different "sets of constraints"

[LES:] Nooo…the bits in the SABM mask are assigned in https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#link-attribute-application-identifiers
(Note that Flex has a bit assignment which is not yet reflected there.)
You need to allow that a new application might have completely semantics.
And, Flex is doing just fine as it is – one of the indicators of which I believe is your enthusiasm for it. 😊

[LES:] Sorry – standing the hierarchy on its head does not make sense – no matter how many times you suggest it.

   Les

Best,
R,

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 Aug 2021 20:34:08 +0200

Hi Les,

*/* Last email on this thread. It is clear that some people are so stuck
here to their beliefs that no matter what others say it will not change
their mind. */*

*> As you see, a single application (Flex) can support multiple
“topologies” – but that is orthogonal.*

The entire topic is to make support of multiple topologies easy - and it is
not orthogonal.

- One option is to signal its metrics with unique bits - one per topology.

- The other option is to signal metrics to be applicable to any app which
chooses to use it then trim the pool with affinities.

The subject draft is about latter. I was (also) suggesting the former.

Currently what seems to be the case is operationally not user friendly mix
of both to build arbitrary topology.

The end,
Robert.

On Mon, Aug 23, 2021 at 8:24 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> *Sent:* Monday, August 23, 2021 10:44 AM
> *Cc:* Shraddha Hegde <[email-masked]>; Tony Przygienda <
> [email-masked]>; Ron Bonica <[email-masked]>; [email-masked]
> *[LES:] Noooo --- please read your own draft. **😊**]*
>
> *The work “Flex” does not appear anywhere in the draft – nor should it.*
>
>
>
> *[LES:] Application != topology*
>
> *As you see, a single application (Flex) can support multiple “topologies”
> – but that is orthogonal.*
>
> *The real issue here is you continue to not fully understand the
> distinction between an “application” and the capabilities of a given
> application – one of which may be to support multiple “topologies”.*
>
> With that definition everything is Flex. Topologies differ one from
> another by running SPT on a different sets of links with different "sets of
> constraints"
>
>
>
> *[LES:] Nooo…the bits in the SABM mask are assigned in
> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#link-attribute-application-identifiers
> <https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#link-attribute-application-identifiers>*
>
> *(Note that Flex has a bit assignment which is not yet reflected there.)*
>
> *You need to allow that a new application might have completely semantics.
> *
>
> *[LES:] Sorry – standing the hierarchy on its head does not make sense –
> no matter how many times you suggest it.*
>
>
>
> *   Les*
>
>
>
> Best,
>
> R,
>