Subject: [Lsr] New Subject: Is Flex-Algo One App or Many (was “RE: IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 26 Mar 2022 15:56:14 +0000

Robert –

I changed the subject – because what you are talking about has nothing to do w the discussion of ANY bit.

You have mentioned this before – and been corrected before – but it seems that did not alter your thinking.

Flex-Algo is ONE APP.
There is not a bit in the SABM assigned per algo – nor is there any intent to do so.
Nor does ANY bit introduce the notion of one bit per algo.

All link attributes advertised with the Flex-Algo (X-bit) in the SABM are usable by any algo. Same would be true if you used ALL encoding. Same would be true if you used ANY encoding.
Which ones are used and how they are used (e.g., which affinity bits apply to a given algorithm) is determined by the Algorithm Specific FAD.

Either you don’t understand Flex-Algo – or you do understand it and want to do a major rewrite of it – I am not sure which.
But either way, none of this has anything to do with the original thread.

   Les

From: Robert Raszuk <[email-masked]>
Sent: Saturday, March 26, 2022 3:43 AM
To: Christian Hopps <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Shraddha Hegde <[email-masked]>; Martin Horneffer <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Hi Chris,

It seems that there is a subtle but important element on which we may have different opinion.

You said: "has to deploy new software that contains the new Wizbang feature, right?"

IMO however we are dealing with case where software already supports all required functions on a box. It is just not using it from day one. You buy a router with OS features which allow you to build zoo of different forwarding paradigms.

Say day one you see a need to enable flex-algo_1 You enable day one links to distribute link attributes required for this.

Day two you want to define new FAD and flood this enabling new flex-algo_2. You reuse already present link attributes entirely or partially in flex-algo_2 computation. You do not need to touch 100000s of links each time you enable new flex_algo.

That's a selling point to me.

If we would expect that folks will limit flex-algo to just a few maybe this all does not matter. But if we see proposals with rainbow of colors each mapped to different flex-algo and perhaps subtle forwarding difference (same metric but just a different min threshold per each flex-algo) it seems pretty bad idea to explicitly enable each app each time such new threshold used to build different topology.

Example:

link attribute:  delay

applications:

flex-algo_1 - build topology where max delay does not exceed 10 ms - color: premium best effort
flex-algo_2 - build topology where max delay does not exceed 8 ms -  color: black
flex-algo_3 - build topology where max delay does not exceed 6 ms - color: bronze
flex-algo_4 - build topology where max delay does not exceed 4 ms - color: blue
flex-algo_5 - build topology where max delay does not exceed 3 ms - color: silver
flex-algo_6 - build topology where max delay does not exceed 3 ms - color: gold

etc ...

Now tell me how does it make sense to enable each app on the link delay attribute ?

Cheers,
Robert

On Sat, Mar 26, 2022 at 6:42 AM Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:

Robert Raszuk <[email-masked]<mailto:[email-masked]>> writes:

> Les,
>
> I don't think this is noise.
>
> Your examples are missing key operational consideration .. Link
> attribute applicable to ANY application may be advertised well ahead
> of enabling such application in a network.
>
> So requesting operator to always advertise tuple of app + attr is not
> looking forward and makes unnecessary operational burden.

[as wg-member]

Hi Robert,

Originally this was the argument that sort of put wind in the sails (for me) for this any bit, but some more thinking about how things would really work changed my mind.

In order for some new feature, let's call it Wizbang, to take advantage of existing any bit marked attributes, the operator still has to deploy new software that contains the new Wizbang feature, right? So the addition of a new Wizbang bit pretty much comes free for the operator.

So, this draft really is just about making the encoding a bit more efficient.

I think if we were defining a new encoding, having this functionality makes sense, but we aren't defining a new encoding. The proposal is to change an existing published encoding, and the bar has to be higher for that I think.

Thanks,
Chris.
[as wg member]

> Thx.
> R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 26 Mar 2022 17:09:32 +0100

Les,

To me what corresponds to network application is effectively a forwarding
paradigm/topology build and used to forward corresponding traffic classe.
You can overload application name the way you like but it does not change
anything.

So if this is going to make you more happy let's rename my
example accordingly and let's not get hang out on flex-algo name itself.

Example:

link attribute:  delay

applications:

app_1 - build topology using SPF_algo_1 where max delay does not exceed 10
ms - color: premium best effort
app_2 - build topology using SPF_algo_2 where max delay does not exceed 8
ms -  color: black
app_3 - build topology using SPF_algo_3 where max delay does not exceed 6
ms - color: bronze
app_4 - build topology using SPF_algo_4 where max delay does not exceed 4
ms - color: blue
app_5 - build topology using SPF_algo_5 where max delay does not exceed 3
ms - color: silver
app_6 - build topology using SPF_algo_6 where max delay does not exceed 1
ms - color: gold

etc ...

Now tell me how does it make sense to enable each app on the link delay
attribute ?

Thx,
R.

On Sat, Mar 26, 2022 at 4:56 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> All link attributes advertised with the Flex-Algo (X-bit) in the SABM are
> usable by any algo. Same would be true if you used ALL encoding. Same would
> be true if you used ANY encoding.
>
> Which ones are used and how they are used (e.g., which affinity bits apply
> to a given algorithm) is determined by the Algorithm Specific FAD.
>
>
>
> Either you don’t understand Flex-Algo – or you do understand it and want
> to do a major rewrite of it – I am not sure which.
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Saturday, March 26, 2022 3:43 AM
> *To:* Christian Hopps <[email-masked]>
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Shraddha Hegde <
> [email-masked]>; Martin Horneffer <[email-masked]>; lsr <
> [email-masked]>
> *Subject:* Re: [Lsr] IETF13: Comments on The Application Specific Link
> Attribute (ASLA) Any Application Bit
>
>
>
> Hi Chris,
>
>
>
> IMO however we are dealing with case where software already supports all
> required functions on a box. It is just not using it from day one. You buy
> a router with OS features which allow you to build zoo of different
> forwarding paradigms.
>
>
>
> Say day one you see a need to enable flex-algo_1 You enable day one links
> to distribute link attributes required for this.
>
>
>
> Day two you want to define new FAD and flood this enabling new
> flex-algo_2. You reuse already present link attributes entirely or
> partially in flex-algo_2 computation. You do not need to touch 100000s of
> links each time you enable new flex_algo.
>
>
>
> If we would expect that folks will limit flex-algo to just a few maybe
> this all does not matter. But if we see proposals with rainbow of colors
> each mapped to different flex-algo and perhaps subtle forwarding difference
> (same metric but just a different min threshold per each flex-algo) it
> seems pretty bad idea to explicitly enable each app each time such new
> threshold used to build different topology.
>
>
>
> Example:
>
>
>
> link attribute:  delay
>
>
>
> applications:
>
>
>
> On Sat, Mar 26, 2022 at 6:42 AM Christian Hopps <[email-masked]> wrote:
>
>
> Robert Raszuk <[email-masked]> writes:
>
> > Les,
> >
> Originally this was the argument that sort of put wind in the sails (for
> me) for this any bit, but some more thinking about how things would really
> work changed my mind.
>
> In order for some new feature, let's call it Wizbang, to take advantage of
> existing any bit marked attributes, the operator still has to deploy new
> software that contains the new Wizbang feature, right? So the addition of a
> new Wizbang bit pretty much comes free for the operator.
>
> I think if we were defining a new encoding, having this functionality
> makes sense, but we aren't defining a new encoding. The proposal is to
> change an existing published encoding, and the bar has to be higher for
> that I think.
>
> Thanks,
> Chris.
> [as wg member]
>
>
> >
> > Thx.
> > R.
> >
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 26 Mar 2022 21:26:51 +0000

Robert –

The defined set of APPs can be seen here<https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#link-attribute-application-identifiers> :

Bit          Name    Reference
0             RSVP-TE (R-bit) [RFC8919]
1             Segment Routing Policy (S-bit)    [RFC8919]
2             Loop Free Alternate (F-bit)           [RFC8919]

Note one additional APP – Flex-Algo – is not yet reflected in this registry.

Now, you can advertise delay and extended admin groups (EAG) for Flex-Algo.
You also can – using the algo specific FAD – specify which colors are to be used by a given algo.

I don’t know of any SPF algorithm that supports specifying a range of metric values as part of its constraints. It is possible to advertise a number of user defined metrics using the Generic Metric sub-TLV defined in https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/ and use the algo specific FAD to specify which of those metrics is to be used for that algo. But in doing so, the App associated with each of the Generic Metric advertisements will be Flex-Algo.

    Les

From: Robert Raszuk <[email-masked]>
Sent: Saturday, March 26, 2022 9:10 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Christian Hopps <[email-masked]>; Shraddha Hegde <[email-masked]>; Martin Horneffer <[email-masked]>; lsr <[email-masked]>
Subject: Re: New Subject: Is Flex-Algo One App or Many (was “RE: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

Les,

To me what corresponds to network application is effectively a forwarding paradigm/topology build and used to forward corresponding traffic classe. You can overload application name the way you like but it does not change anything.

So if this is going to make you more happy let's rename my example accordingly and let's not get hang out on flex-algo name itself.

Example:

link attribute:  delay

applications:

app_1 - build topology using SPF_algo_1 where max delay does not exceed 10 ms - color: premium best effort
app_2 - build topology using SPF_algo_2 where max delay does not exceed 8 ms -  color: black
app_3 - build topology using SPF_algo_3 where max delay does not exceed 6 ms - color: bronze
app_4 - build topology using SPF_algo_4 where max delay does not exceed 4 ms - color: blue
app_5 - build topology using SPF_algo_5 where max delay does not exceed 3 ms - color: silver
app_6 - build topology using SPF_algo_6 where max delay does not exceed 1 ms - color: gold

etc ...

Thx,
R.

On Sat, Mar 26, 2022 at 4:56 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

Flex-Algo is ONE APP.

   Les

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, March 26, 2022 3:43 AM
To: Christian Hopps <[email-masked]<mailto:[email-masked]>>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Martin Horneffer <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Hi Chris,

Example:

link attribute:  delay

applications:

etc ...

Cheers,
Robert

[as wg-member]

Hi Robert,

Thanks,
Chris.
[as wg member]

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 26 Mar 2022 23:16:07 +0100

Hi Les,

What you call "an application" is simply counter intuitive and not what
99.9% of people understand by this term. Application to me is a web server
running on the host waiting for user requests, SIP gateway providing VoIP
connections, database instance running on some specific port and responding
to SQL queries, multicast streaming etc ...

Each of these real applications may benefit from different network
transport/forwarding class.

Calling a network forwarding class as "an application" only generates huge
confusion. Networks are servants to the user applications. Networks are not
the applications itself.

As each user application may benefit from different treatment it can be
mapped to different network transport or network color. So again network
color could be seen as a network behaviour constructed in an optimal way to
the user application it is designed to carry.

When you say "You also can – using the algo specific FAD – specify which
colors are to be used by a given algo." to me means that you are also
overloading the term "color" - at least from the notion of how CAR or CT
proposal are defining it. And what CAR/CT proposals call a transport color
is actually in line with network forwarding class and very intuitive.

As you recall a few months back I defined an IP TE solution where we can
steer packets between nodes without any stack of labels or segments imposed
on them upfront on ingress. That would be in your terminology new
application - as it does not use SPF, but constructs end to end
waypoints using its own heuristic. Then when someone would like to reuse
link metrics already advertised for flex-algo it would need to touch all
the links in the network to add this new app.

And this would continue every time someone invents a new network forwarding
model while reusing physical metrics already advertised with each link.

You mentioned that one of the reasons was to clearly separate RSVP-TE from
SR running on a link. But as we discussed you could do that with the
"include" notion using affinity bits - not with separate R vs S bits.

So while I doubt that you will adjust the terminology used in flex-algo
draft I continue to believe that there is value with advertising link
attributes which can be used by any current and future network forwarding
class or color.

Best,
Robert.

On Sat, Mar 26, 2022 at 10:27 PM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> Robert –
>
>
>
> The defined set of APPs can be seen here
> <https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#link-attribute-application-identifiers>
> :
>
>
>
> Bit          Name    Reference
>
> I don’t know of any SPF algorithm that supports specifying a range of
> metric values as part of its constraints. It is possible to advertise a
> number of user defined metrics using the Generic Metric sub-TLV defined in
> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/ and use
> the algo specific FAD to specify which of those metrics is to be used for
> that algo. But in doing so, the App associated with each of the Generic
> Metric advertisements will be Flex-Algo.
>
>
>
>     Les
>
>
>
> *Sent:* Saturday, March 26, 2022 9:10 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Christian Hopps <[email-masked]>; Shraddha Hegde <
> *Subject:* Re: New Subject: Is Flex-Algo One App or Many (was “RE: [Lsr]
> IETF13: Comments on The Application Specific Link Attribute (ASLA) Any
> Application Bit”)
>
>
>
> Les,
>
>
>
> On Sat, Mar 26, 2022 at 4:56 PM Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Robert –
>
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 26 Mar 2022 23:21:44 +0000

Robert –

The complete name (as reflected in the referenced registry name) is:  Link Attribute Application Identifiers

In the context of ASLA we tend to abbreviate that as “Application”. If you find that confusing, we can all try to use the more complete name.
But whatever name we use, that is what is being referenced when we discuss the use of ASLA.

   Les

From: Robert Raszuk <[email-masked]>
Sent: Saturday, March 26, 2022 3:16 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: lsr <[email-masked]>; Christian Hopps <[email-masked]>; Shraddha Hegde <[email-masked]>; Martin Horneffer <[email-masked]>
Subject: Re: [Lsr] New Subject: Is Flex-Algo One App or Many (was “RE: IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

Hi Les,

What you call "an application" is simply counter intuitive and not what 99.9% of people understand by this term. Application to me is a web server running on the host waiting for user requests, SIP gateway providing VoIP connections, database instance running on some specific port and responding to SQL queries, multicast streaming etc ...

Each of these real applications may benefit from different network transport/forwarding class.

Calling a network forwarding class as "an application" only generates huge confusion. Networks are servants to the user applications. Networks are not the applications itself.

As each user application may benefit from different treatment it can be mapped to different network transport or network color. So again network color could be seen as a network behaviour constructed in an optimal way to the user application it is designed to carry.

When you say "You also can – using the algo specific FAD – specify which colors are to be used by a given algo." to me means that you are also overloading the term "color" - at least from the notion of how CAR or CT proposal are defining it. And what CAR/CT proposals call a transport color is actually in line with network forwarding class and very intuitive.

As you recall a few months back I defined an IP TE solution where we can steer packets between nodes without any stack of labels or segments imposed on them upfront on ingress. That would be in your terminology new application - as it does not use SPF, but constructs end to end waypoints using its own heuristic. Then when someone would like to reuse link metrics already advertised for flex-algo it would need to touch all the links in the network to add this new app.

And this would continue every time someone invents a new network forwarding model while reusing physical metrics already advertised with each link.

You mentioned that one of the reasons was to clearly separate RSVP-TE from SR running on a link. But as we discussed you could do that with the "include" notion using affinity bits - not with separate R vs S bits.

So while I doubt that you will adjust the terminology used in flex-algo draft I continue to believe that there is value with advertising link attributes which can be used by any current and future network forwarding class or color.

Best,
Robert.

On Sat, Mar 26, 2022 at 10:27 PM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
Robert –

Bit          Name    Reference

    Les

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, March 26, 2022 9:10 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Martin Horneffer <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Subject: Is Flex-Algo One App or Many (was “RE: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

Les,

Example:

link attribute:  delay

applications:

etc ...

Thx,
R.

Flex-Algo is ONE APP.

   Les

Hi Chris,

Example:

link attribute:  delay

applications:

etc ...

Cheers,
Robert

[as wg-member]

Hi Robert,

Thanks,
Chris.
[as wg member]

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

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 27 Mar 2022 00:51:39 +0100

Hi Les,

Nope the abbreviation is not confusing.

Calling RSVP-TE, SR, LFA or Flex-Algo as "applications" is confusing as
those are network forwarding paradigms and not applications.

Applications (read user applications which samples I provided) are running
on top of them. What you call applications are merely different types of
pipes to carry user applications.

And that alone if you just stay focused on IGP may be all fine. But the
moment you need to carry user applications over your (network) applications
each with set of different colors the picture becomes very confusing.

- - -

In any case - aside from the above - even considering your terminology,
physical properties of the links are not application dependent.
Irrespective of what encapsulation you use for your traffic for example the
value of propagation delay of the link will always be application
independent. Hence it does make sense to advertise it with ANY wildcard
notion.

Especially that you always have the ability within each such "application"
algorithm definition or with use of link affinities to further select which
specific links and link attributes to use to compute an instance of a
forwarding paradigm.

Thx,
R.

On Sun, Mar 27, 2022 at 12:21 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> In the context of ASLA we tend to abbreviate that as “Application”. If you
> find that confusing, we can all try to use the more complete name.
>
> *Sent:* Saturday, March 26, 2022 3:16 PM
> *Cc:* lsr <[email-masked]>; Christian Hopps <[email-masked]>; Shraddha
> Hegde <[email-masked]>; Martin Horneffer <[email-masked]>
> *Subject:* Re: [Lsr] New Subject: Is Flex-Algo One App or Many (was “RE:
> And this would continue every time someone invents a new network
> forwarding model while reusing physical metrics already advertised with
> each link.
>
>
>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 28 Mar 2022 05:02:16 +0000

>Calling RSVP-TE, SR, LFA or Flex-Algo as "applications" is confusing as those are network forwarding paradigms and >not applications.
I totally agree with that. It is very confusing to call them applications . I do see new drafts that mistakenly assume ASLA can be used to advertise application specific values. What it also implies is that the way industry is evolving, it is required to advertise “User application” specific values and use them to build paths no-matter what network forwarding paradigms are used.
Having a protocol extension that allows for wildcarding the attributes for these forwarding paradigms is useful.

Looks like the other side of the argument is, it would have been useful if it was done in RFC 8919/RFC 8920 but since its an RFC now, we should carry that debt forever. I don’t agree with that argument and believe we still have opportunity to improve.

Rgds
Shraddha

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Sunday, March 27, 2022 5:22 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: lsr <[email-masked]>; Christian Hopps <[email-masked]>; Shraddha Hegde <[email-masked]>; Martin Horneffer <[email-masked]>
Subject: Re: [Lsr] New Subject: Is Flex-Algo One App or Many (was “RE: IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit”)

[External Email. Be cautious of content]

Hi Les,

Calling RSVP-TE, SR, LFA or Flex-Algo as "applications" is confusing as those are network forwarding paradigms and not applications.

Applications (read user applications which samples I provided) are running on top of them. What you call applications are merely different types of pipes to carry user applications.

And that alone if you just stay focused on IGP may be all fine. But the moment you need to carry user applications over your (network) applications each with set of different colors the picture becomes very confusing.

- - -

In any case - aside from the above - even considering your terminology, physical properties of the links are not application dependent. Irrespective of what encapsulation you use for your traffic for example the value of propagation delay of the link will always be application independent. Hence it does make sense to advertise it with ANY wildcard notion.

Especially that you always have the ability within each such "application" algorithm definition or with use of link affinities to further select which specific links and link attributes to use to compute an instance of a  forwarding paradigm.

Thx,
R.

On Sun, Mar 27, 2022 at 12:21 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

   Les

Cc: lsr <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Martin Horneffer <[email-masked]<mailto:[email-masked]>>

Hi Les,

Best,
Robert.

The defined set of APPs can be seen here<https://urldefense.com/v3/__https:/www.iana.org/assignments/igp-parameters/igp-parameters.xhtml*link-attribute-application-identifiers__;Iw!!NEt6yMaO-gk!SyE4CIaCvSO2RXRKUHtQtEiPlI_rIE6R1Uw9T0sIO9Z6a6ATc6NHPHN0y5GgW8ca$> :

Bit          Name    Reference

I don’t know of any SPF algorithm that supports specifying a range of metric values as part of its constraints. It is possible to advertise a number of user defined metrics using the Generic Metric sub-TLV defined in https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!SyE4CIaCvSO2RXRKUHtQtEiPlI_rIE6R1Uw9T0sIO9Z6a6ATc6NHPHN0y6kV7Tmy$> and use the algo specific FAD to specify which of those metrics is to be used for that algo. But in doing so, the App associated with each of the Generic Metric advertisements will be Flex-Algo.

    Les

Les,

Example:

link attribute:  delay

applications:

etc ...

Thx,
R.

Flex-Algo is ONE APP.

   Les

Hi Chris,

Example:

link attribute:  delay

applications:

etc ...

Cheers,
Robert

[as wg-member]

Hi Robert,

Thanks,
Chris.
[as wg member]

_______________________________________________
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!SyE4CIaCvSO2RXRKUHtQtEiPlI_rIE6R1Uw9T0sIO9Z6a6ATc6NHPHN0yzqzsOJn$>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Mar 2022 10:03:30 +0200

Hi,

> I do see new drafts that mistakenly assume ASLA can be used to advertise
application specific values.

Exactly ! And I do not blame any authors of those new drafts as for anyone
with reading skills "Application Specific Link Attribute" means links
attributes which correspond to either user application (voice, video, web
etc ...) or at best class of service (gold, silver, bronze, grey ...)

No one would think those *applications* are just some forwarding
paradigms or constructs how to compute paths from A to Z.

And I also agree that RFC8919/8920 need revision perhaps -bis to rename
misleading terminology as well as perhaps add ANY flags which can be used
for "application agnostic link attributes - AALA".

Thx,
Robert.

On Mon, Mar 28, 2022 at 7:02 AM Shraddha Hegde <shraddha=
[email-masked]> wrote:

> those are network forwarding paradigms and >not applications.
>
> I totally agree with that. It is very confusing to call them applications
> . I do see new drafts that mistakenly assume ASLA can be used to advertise
> application specific values. What it also implies is that the way industry
> is evolving, it is required to advertise “User application” specific values
> and use them to build paths no-matter what network forwarding paradigms are
> used.
>
> Looks like the other side of the argument is, it would have been useful if
> it was done in RFC 8919/RFC 8920 but since its an RFC now, we should carry
> that debt forever. I don’t agree with that argument and believe we still
> have opportunity to improve.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
>
>
> *Sent:* Sunday, March 27, 2022 5:22 AM
> *[External Email. Be cautious of content]*
>
>
>
> Hi Les,
>
>
>
> On Sun, Mar 27, 2022 at 12:21 AM Les Ginsberg (ginsberg) <
> <https://urldefense.com/v3/__https:/www.iana.org/assignments/igp-parameters/igp-parameters.xhtml*link-attribute-application-identifiers__;Iw!!NEt6yMaO-gk!SyE4CIaCvSO2RXRKUHtQtEiPlI_rIE6R1Uw9T0sIO9Z6a6ATc6NHPHN0y5GgW8ca$>
> :
>
>
>
> Bit          Name    Reference
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!SyE4CIaCvSO2RXRKUHtQtEiPlI_rIE6R1Uw9T0sIO9Z6a6ATc6NHPHN0y6kV7Tmy$>
> and use the algo specific FAD to specify which of those metrics is to be
> used for that algo. But in doing so, the App associated with each of the
> Generic Metric advertisements will be Flex-Algo.
>
>
>
>     Les
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!SyE4CIaCvSO2RXRKUHtQtEiPlI_rIE6R1Uw9T0sIO9Z6a6ATc6NHPHN0yzqzsOJn$>
>