Subject: Re: [Lsr] Generic metric: application-specific vs application-independent

From: Ron Bonica <[email-masked]>
Date: Mon, 2 Aug 2021 19:10:11 +0000

Gunter,

I think we agree that some link attributes are application specific while others are application independent. However, it is not so easy to figure out which link attributes should be assigned to each category.

In your message below, you suggest that any attribute whose value is learned from configuration is application specific. But wouldn't the following attributes break that model, if we ever needed to advertise them:

- Circuit mileage
- monetary cost

We might have to decide whether link attributes are application specific or application independent on a case-by-case basis.

                                                                             Ron

Juniper Business Use Only

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Friday, July 30, 2021 5:06 AM
To: Peter Psenak <ppsenak=[email-masked]>; Shraddha Hegde <shraddha=[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Tony Li <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Generic metric: application-specific vs application-independent

[External Email. Be cautious of content]

A little late in the discussion... (PTO events do happen)

a quick opinion on the below discussion on whether Generic metric sub-tlv should be encoded on a ASLA or not.
For me, it depends on how the metric for the corresponding metric-type is obtained and if it can be configured (static).
It doesn’t make sense to have Application specific values if a particular metric is obtained only dynamically, for eg, dynamically measured delay is going to be same for all applications.
On the contrary, te-metric can be configured, and we can in principle configure different values for different applications.

My opinion is that if any of the metric-types in the Generic metric sub-tlv can be configured, it should be inside the ASLA.

G/

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Peter Psenak
Sent: Friday, July 30, 2021 9:42 AM
To: Shraddha Hegde <shraddha=[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Tony Li <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Generic metric: application-specific vs application-independent

Shraddha,

On 30/07/2021 06:53, Shraddha Hegde wrote:
> Operators have built their networks with link attributes
>
> being configured and used by any application. For example
>
> igp-metric is used by ISIS, then came LDP that used same igp-metric,
>
> RSVP could also use igp-metric. Then came ISIS-SR and SR-TE
>
> and even flex-algo. All these applications could use the same igp-metric.
>
> The networks have evolved like this for 20-30 years.
>
> If an operator wants to design his network for this kind of
>
> network evolution with generic metric going forward, ASLA does not
>
> currently provide an effective solution.

please be more specific as to what exactly "ASLA does not currently provide an effective solution" for.

> ASLA currently has limitations
>
> that make it more complex than necessary for operators who want to
>
> evolve their networks this way.

above seems more like your opinion than the fact. I have not seen any evidence that would prove the above statement.

>
> I am working on a draft to propose improvements to ASLA to
>
> make this kind of evolution less complex. I'll post a draft
>
> soon that will describe limitations of ASLA in its current form
>
> along with proposed improvements.

hard to comment on something that does not exist.

>
> I would still like to hear about use cases that require
>
> generic metric to be applications-specific and cannot be solved with
>
> application-independent generic metric.

it has been explained on the list multiple times.

thanks,
Peter

>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *From:* Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
> *Sent:* Thursday, July 29, 2021 2:00 AM
> *To:* Tony Li <[email-masked]>
> *Cc:* [email-masked]; Shraddha Hegde <[email-masked]>
> *Subject:* RE: [Lsr] Generic metric: application-specific vs 
> application-independent
>
> *[External Email. Be cautious of content]*
>
> Tony –
>
> You ask very important questions – but – as Acee has answered in a 
> subsequent email – all of these questions were openly debated in the 
> WG during the work on what became RFC8919/8920. This debate was 
> contentious, took years, and the WG eventually reached consensus on 
> what became the two RFCs.
>
> If every time a new attribute is defined we reopen the original 
> debate, then we will never move forward and we will have great 
> difficulty in deploying interoperable implementations.
>
> I can respect that you might have preferred a different conclusion on 
> the part of the WG – but I hope you will also acknowledge that this is 
> now a resolved issue and we need to move forward following the 
> existing RFCs.
>
> Parenthetically, I do believe that answers to your questions can be 
> found in the RFCs. The answers may not satisfy you – but we did 
> attempt to include the context which drove the ASLA solution.
>
> Thanx.
>
>      Les
>
> *From:* Lsr <[email-masked] <mailto:[email-masked]>> *On 
> Behalf Of *Tony Li
> *Sent:* Wednesday, July 28, 2021 1:06 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; Shraddha Hegde 
> <shraddha=[email-masked]
> <mailto:shraddha=[email-masked]>>
> *Subject:* Re: [Lsr] Generic metric: application-specific vs 
> application-independent
>
> Les,
>
>     ASLA exists to support the advertisement of attributes which can be
>     used in application specific ways.
>
> Why do we need separate and different copies of attributes for 
> different applications?
>
> The SRLG tries to capture the risk relationships between multiple links.
> Those relationships don’t change depending on the application.
>
> Link attributes don’t require the variability that ASLA provides, and 
> the overhead is high.  How does this cost/benefit ratio make sense?
>
>     In any particular deployment case, a given attribute advertisement
>     might be used by one app, multiple apps, or all apps.
>
>     ASLA allows to unambiguously support all of these cases with a
>     single advertisement encoding format.
>
>     The correct question to be resolving here is indeed the question
>     which has been discussed in an earlier thread: Is Generic Metric a
>     link attribute which can have application specific use cases? I
>     think the question to that is unquestionably “yes”.
>
>     That should be enough (IMO of course) to close the discussion.
>
> Well, one nice thing is that there is an entire space of metrics 
> available.  If application A wants to use metric 16 and application B 
> wants to use metric 122, that’s already doable.
>
> Why do we need a separate space per application????
>
> Tony
>

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

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 17 Aug 2021 18:04:47 +0000

Peter,

>no, I don't want to use affinities to do that. That's the whole point.
>ASLA gives you per link per application signaling. No need to use affinities.

The usecase you are describing to exclude links from an application topology is very straight 
forward and how this is done is defined by applications.
TE applications have defined a topology filter data model that uses 
link-affinities to Include/exclude links from topology 
 https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-topology-filter-00. 
 In your example if application B is any TE application it would be natural to use link-affinities.

If application B is LFA, RFC 7916 defines link-coloring and include exclude policies to be used (Refer sec 6.2.3).
so it cannot use application bits on metric to exclude links.

If we assume application A and B are both Flex-algos, ASLA  
natively doesn't support Per flex-algo attribute advertisement 
and it is extremely complex to define user-defined bit masks for Each 
flex-algo and assign the bit masks on the metric on every router. 
Operator could use link-affinities to Exclude links 
from flex-algo topology which is much simpler.

Rgds
Shraddha

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Saturday, July 31, 2021 1:07 AM
To: Shraddha Hegde <[email-masked]>; Robert Raszuk <[email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Tony Li <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Generic metric: application-specific vs application-independent

Shraddha,

On 30/07/2021 18:45, Shraddha Hegde wrote:
> Peter,
>
>> imagine you have an application A and B and a link X. You advertise application independent metric M on that link X >because you want application A to use it.
>
>> Application B is also enabled to use the metric M, but you do not want application B to use metric M on the link X >(because you do not want application B to include the link X in its topology). How do you do that without ASLA? The >answer is you can't.
>
> This is very straight forward to do without ASLA.
>   I would define an admin-group and assign that admin group on link X and
>   exclude that admin-group from Application B.
>   This is much common way how
>   operators exclude links from the topology.

no, I don't want to use affinities to do that. That's the whole point.
ASLA gives you per link per application signaling. No need to use affinities.

>
>   The alternative being proposed with ASLA is much more fragile.
>   An operator would have to set the bits for application A and Application B
>   for metric M on every link that he wants to include and reset the
>   application bit B on links that he wants to exclude for application B.

sorry, but setting affinities is not any easier, so the above argument is not valid.

Peter

>   Imagine what would happen if he missed setting the bit or resetting
>   the bit on some of the links and how difficult it would be to debug.
>
> Rgds
> Shraddha
>
>
> From: Peter Psenak <[email-masked]>
> Sent: Friday, July 30, 2021 7:09 PM
> To: Shraddha Hegde <[email-masked]>; Robert Raszuk 
> <[email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp) 
> <[email-masked]>
> Cc: Les Ginsberg (ginsberg) <[email-masked]>; Tony Li 
> <[email-masked]>; [email-masked]
> On 30/07/2021 15:22, Shraddha Hegde wrote:
>> Robert,
>>
>>   > Can anyone explain how do I map generic metric to selected 
>> network applications I am to run in the network ?
>>
>> Which application uses which metric type is defined by the application.
>
> imagine you have an application A and B and a link X. You advertise application independent metric M on that link X because you want application A to use it.
>
> Application B is also enabled to use the metric M, but you do not want application B to use metric M on the link X (because you do not want application B to include the link X in its topology). How do you do that without ASLA? The answer is you can't.
>
> thanks,
> Peter
>
>>
>> For example in flex-algo FAD defines which metric-type its going to use.
>>
>> In SR-TE, the constraint list specifies which metric-type it is going 
>> to use.
>>
>> Rgds
>>
>> Shraddha
>>
>> *From:* Robert Raszuk <[email-masked]>
>> *Sent:* Friday, July 30, 2021 6:20 PM
>> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
>> <[email-masked]>
>> *Cc:* Peter Psenak <[email-masked]>; Shraddha Hegde 
>> <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; 
>> Tony Li <[email-masked]>; [email-masked]
>> Hey Gunter,
>>   > It doesn’t make sense to have Application specific values if a 
>> particular metric is obtained only dynamically,
>>
>> It sure does.
>>
>> Please notice what ASLA RFCs say up front in the abstract. ASLA is 
>> useful for:
>>
>> A) application- specific values for a given attribute
>>
>> AND
>>
>> B) indication of which applications are using the advertised value 
>> for a given link.
>>
>> It does not matter if the value is same or different ... what matters 
>> is automated and consistent indication which of my applications given 
>> new metric applies to.
>>
>> I already mentioned this to Ron here:
>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr
>> / 
>> OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!VVLJCpIMrWixS17PeaBbfOpe
>> b NPO4JUW4jparIn36jHmhv4_-W2_q_Smwo7oIYgk$
>> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr
>> /
>> OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!Tny8sU7cmjqLAbDVnliN7lck
>> 7 J4tCBAHr10i3CW2G9oviUWo8b2RTJxCXc0gvWOz$>
>>
>> Can anyone explain how do I map generic metric to selected network 
>> applications I am to run in the network ?
>>
>> Thx,
>> Robert.
>>
>> On Fri, Jul 30, 2021 at 11:05 AM Van De Velde, Gunter (Nokia -
>> BE/Antwerp) <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>      a quick opinion on the below discussion on whether Generic metric
>>      sub-tlv should be encoded on a ASLA or not.
>>      For me, it depends on how the metric for the corresponding
>>      metric-type is obtained and if it can be configured (static).
>>      It doesn’t make sense to have Application specific values if a
>>      particular metric is obtained only dynamically, for eg, dynamically
>>      measured delay is going to be same for all applications.
>>      On the contrary, te-metric can be configured, and we can in
>>      principle configure different values for different applications.
>>
>>      My opinion is that if any of the metric-types in the Generic metric
>>      sub-tlv can be configured, it should be inside the ASLA.
>>
>>      G/
>>
>
>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 18 Aug 2021 09:51:26 +0200

Shraddha,

> If we assume application A and B are both Flex-algos, ASLA

flex-algo is a single application, so A and B does not make sense.

You can define flex-algo X and flex-algo Y and use different FAD to 
exclude/include links as needed, using single set of affinities that are 
advertised for flex-algo application as such.

I still do not see a problem

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 18 Aug 2021 11:39:33 +0200

Peter,

Is there a definition of IGP "application" in any of the specs ?

To me application in the context of an IGP is defined by method used to
compute a topology as well as links and their metrics which are used to
consistently select the shortest path in the domain. So even if you happen
to use the exact same algorithm (which may already not be the case) it
seems that it is hard to artificially squeeze two orthogonal topologies
serving completely different purposes under a single flex-algo app
umbrella.

If you go by the notion of let's push everything to FAD then sorry but ASLA
is not making sense anymore as even without it FAD could enumerate what
link attributes and what links (using affinities) can be considered for
topology computation.

Honestly I am not sure where is the resistance to define more bits for flex
algo in SABM is coming from ....

Thx,
R.

On Wed, Aug 18, 2021 at 9:51 AM Peter Psenak <[email-masked]> wrote:

> > If application B is LFA, RFC 7916 defines link-coloring and include
> exclude policies to be used (Refer sec 6.2.3).
> > To: Shraddha Hegde <[email-masked]>; Robert Raszuk <
> [email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp) <
> [email-masked]>
> >>> imagine you have an application A and B and a link X. You advertise
> application independent metric M on that link X >because you want
> application A to use it.
> >>
> >>> Application B is also enabled to use the metric M, but you do not want
> application B to use metric M on the link X >(because you do not want
> application B to include the link X in its topology). How do you do that
> without ASLA? The >answer is you can't.
> >>
> >> imagine you have an application A and B and a link X. You advertise
> application independent metric M on that link X because you want
> application A to use it.
> >>
> >> Application B is also enabled to use the metric M, but you do not want
> application B to use metric M on the link X (because you do not want
> application B to include the link X in its topology). How do you do that
> without ASLA? The answer is you can't.
> >>
> >> thanks,
> >> Peter
> >>
> >>>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 18 Aug 2021 11:55:32 +0200

Robert,

On 18/08/2021 11:39, Robert Raszuk wrote:
> consistently select the shortest path in the domain. So even if you 
> happen to use the exact same algorithm (which may already not be the 
> case) it seems that it is hard to artificially squeeze two orthogonal 
> topologies serving completely different purposes under a single 
> flex-algo app umbrella.

you can have up to 128 flex-algo topologies, each using different 
constraint. What else do you need?

thanks,
Peter

> 
> If you go by the notion of let's push everything to FAD then sorry but 
> ASLA is not making sense anymore as even without it FAD could 
> enumerate what link attributes and what links (using affinities) can be 
> considered for topology computation.
> 
> Honestly I am not sure where is the resistance to define more bits for 
> flex algo in SABM is coming from ....
> 
> Thx,
> R.
> 
> 
> 
> On Wed, Aug 18, 2021 at 9:51 AM Peter Psenak <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Shraddha,
> 
>      > If application B is LFA, RFC 7916 defines link-coloring and
>     include exclude policies to be used (Refer sec 6.2.3).
>      > From: Peter Psenak <[email-masked] <mailto:[email-masked]>>
>      > To: Shraddha Hegde <[email-masked]
>     <mailto:[email-masked]>>; Robert Raszuk <[email-masked]
>     <mailto:[email-masked]>>; Van De Velde, Gunter (Nokia -
>     <mailto:[email-masked]>>
>      > Cc: Les Ginsberg (ginsberg) <[email-masked]
>     <mailto:[email-masked]>>; Tony Li <[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>      >>> imagine you have an application A and B and a link X. You
>     advertise application independent metric M on that link X >because
>     you want application A to use it.
>      >>
>      >>> Application B is also enabled to use the metric M, but you do
>     not want application B to use metric M on the link X >(because you
>     do not want application B to include the link X in its topology).
>     How do you do that without ASLA? The >answer is you can't.
>      >>
>      >> From: Peter Psenak <[email-masked] <mailto:[email-masked]>>
>      >> To: Shraddha Hegde <[email-masked]
>     <mailto:[email-masked]>>; Robert Raszuk
>      >> <[email-masked] <mailto:[email-masked]>>; Van De Velde,
>     Gunter (Nokia - BE/Antwerp)
>      >> <[email-masked]
>     <mailto:[email-masked]>>
>      >> Cc: Les Ginsberg (ginsberg) <[email-masked]
>     <mailto:[email-masked]>>; Tony Li
>      >> <[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>      >>>    > Can anyone explain how do I map generic metric to selected
>      >> imagine you have an application A and B and a link X. You
>     advertise application independent metric M on that link X because
>     you want application A to use it.
>      >>
>      >> Application B is also enabled to use the metric M, but you do
>     not want application B to use metric M on the link X (because you do
>     not want application B to include the link X in its topology). How
>     do you do that without ASLA? The answer is you can't.
>      >>
>      >> thanks,
>      >> Peter
>      >>
>      >>>
>      >>> *From:* Robert Raszuk <[email-masked]
>     <mailto:[email-masked]>>
>      >>> <[email-masked]
>     <mailto:[email-masked]>>
>      >>> *Cc:* Peter Psenak <[email-masked]
>     <mailto:[email-masked]>>; Shraddha Hegde
>      >>> <[email-masked] <mailto:[email-masked]>>; Les
>     Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>;
>      >>> Tony Li <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>
>      >>>    > It doesn’t make sense to have Application specific values if a
>     <mailto:[email-masked]>
>      >>> <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 18 Aug 2021 12:03:06 +0200

> constraint. What else do you need?

Isn't that a FAD limit ?

So if I have a metric  X advertised on all links and want to include it
only on some specific links to compute SPT in one or few special flex-algo
topologies how do I do that ? Affinities ?

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 18 Aug 2021 12:16:25 +0200

On 18/08/2021 12:03, Robert Raszuk wrote:
> only on some specific links to compute SPT in one or few special 
> flex-algo topologies how do I do that ? Affinities ?

yes.

Peter