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

From: Shraddha Hegde <[email-masked]>
Date: Wed, 28 Jul 2021 18:18:10 +0000

WG,

   Generic metric as described in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con
   can advertise multiple metric-types and values and be used
   by any application. All the use cases that I heard from network
   operators while writing the draft could be solved
   using generic-metric advertised in an application-independent way.

   I am looking for clear description of use cases that would benefit from advertising
   generic metric in an application specific way. Can any one provide such a usecase?

Rgds
Shraddha

Juniper Business Use Only

---

From: Tony Li <[email-masked]>
Date: Wed, 28 Jul 2021 11:22:42 -0700

FWIW, I think that this is the wrong question. 

I think that a better question is: Is there a usecase that is so overwhelmingly compelling that the added complexity of ASLA is warranted?

Tony

> On Jul 28, 2021, at 11:18 AM, Shraddha Hegde <shraddha=[email-masked]> wrote:
> 
> WG,
>  
>    Generic metric as described in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con>
> _______________________________________________
> Lsr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 28 Jul 2021 21:07:09 +0200

On 28/07/2021 20:22, Tony Li wrote:
> I think that a better question is: Is there a usecase that is so 
> overwhelmingly compelling that the added complexity of ASLA is warranted?

both TE metric and delay, that is used as metric for flex-algo, are 
supporting ASLA. Both proved to be be useful and were deployed. I see no 
reason why the Generic Metric should be any different.

thanks,
Peter

> 
> Tony
> 
> 
>> On Jul 28, 2021, at 11:18 AM, Shraddha Hegde 
>> <shraddha=[email-masked] 
>> <mailto:shraddha=[email-masked]>> wrote:
>>
>> WG,
>>    Generic metric as described 
>> inhttps://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con
>> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 28 Jul 2021 19:35:16 +0000

Tony –

IMO, you are asking the wrong question. 😊

ASLA exists to support the advertisement of attributes which can be used in application specific ways.
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.

   Les

From: Lsr <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, July 28, 2021 11:23 AM
To: Shraddha Hegde <shraddha=[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Generic metric: application-specific vs application-independent

Tony

On Jul 28, 2021, at 11:18 AM, Shraddha Hegde <shraddha=[email-masked]<mailto:shraddha=[email-masked]>> wrote:

WG,

Rgds
Shraddha

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

---

From: Tony Li <[email-masked]>
Date: Wed, 28 Jul 2021 13:06:28 -0700

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?

> 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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 28 Jul 2021 20:15:53 +0000

Speaking as WG chair:

We had a protracted discussion of the usage of link attributes for multiple applications. The outcome was RFC 8919 and RFC 9820. If you browse the ospf and isis WG archives for the years 2015-2018, you’ll see there was lots of discussion. You can also view the IETF meeting materials for these years. This is not open for discussion.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Tony Li <[email-masked]>
Date: Wednesday, July 28, 2021 at 2:23 PM
To: Shraddha Hegde <shraddha=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Generic metric: application-specific vs application-independent

Tony

WG,

Rgds
Shraddha

---

From: Peter Psenak <[email-masked]>
Date: Wed, 28 Jul 2021 22:20:16 +0200

Tony,

On 28/07/2021 22:06, Tony Li wrote:
> The SRLG tries to capture the risk relationships between multiple links. 
> Those relationships don’t change depending on the application.

SRLG may mean many things - same optical infrastructure, same site, same 
area, same city. For LFA you may want to use the "same optical 
infrastructure", you don't care about the rest. For flex-algo primary 
path you may care about same same site, same area, same city to provide 
diverse primary path.

thanks,
Peter

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 28 Jul 2021 20:30:20 +0000

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]> On Behalf Of Tony Li
Sent: Wednesday, July 28, 2021 1:06 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; Shraddha Hegde <shraddha=[email-masked]>
Subject: Re: [Lsr] Generic metric: application-specific vs application-independent

Les,

Tony

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 30 Jul 2021 04:53:33 +0000

Operators have built their networks with link attributes
being configured and used by any application. For example
igp-metric is used by ISIS, then came LDP that used same igp-metric,
RSVP could also use igp-metric. Then came ISIS-SR and SR-TE
and even flex-algo. All these applications could use the same igp-metric.
The networks have evolved like this for 20-30 years.
If an operator wants to design his network for this kind of
network evolution with generic metric going forward, ASLA does not
currently provide an effective solution. ASLA currently has limitations
that make it more complex than necessary for operators who want to
evolve their networks this way.

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

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

Rgds
Shraddha

Juniper Business Use Only
From: Les Ginsberg (ginsberg) <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.

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,

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?

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.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Fri, 30 Jul 2021 09:41:51 +0200

Shraddha,

On 30/07/2021 06:53, Shraddha Hegde wrote:
> 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
> 

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

> along with proposed improvements.

hard to comment on something that does not exist.

> application-independent generic metric.

it has been explained on the list multiple times.

thanks,
Peter

> *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 
> <mailto:shraddha=[email-masked]>>
> *Subject:* Re: [Lsr] Generic metric: application-specific vs 
> application-independent
> 
> Les,
> 
>     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”.
>

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 30 Jul 2021 09:05:38 +0000

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,

> currently provide an effective solution. 

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

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

thanks,
Peter

[email-masked]

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 30 Jul 2021 10:51:14 +0000

Hi, 

I share similar opinion with Gunter. 

ASLA provides the flexibility to define the set of applications which can use a specific type of link attribute, it also allows to customize the attribute value for each application.

As the generic metric mechanism will be used to define different types of new metrics, some of which may need the flexibility of indicating the set of applications it is used for, and may also need to generate application-specific metric values. In that case, it seems ASLA is the suitable approach for such metric advertisement.

Best regards,
Jie

> From: Lsr [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter
> (Nokia - BE/Antwerp)
> Sent: Friday, July 30, 2021 5:06 PM
> To: Peter Psenak <ppsenak=[email-masked]>; Shraddha Hegde
> <shraddha=[email-masked]>; Les Ginsberg (ginsberg)
> <ginsberg=[email-masked]>; Tony Li <[email-masked]>
> Cc: [email-masked]
> 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/
> 
> To: Shraddha Hegde <shraddha=[email-masked]>; Les Ginsberg
> (ginsberg) <ginsberg=[email-masked]>; Tony Li <[email-masked]>
> Cc: [email-masked]
> > 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.
> >
> > now a resolved issue and we need to move forward following the
> > existing RFCs.
> >
> > 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: Gyan Mishra <[email-masked]>
Date: Fri, 30 Jul 2021 07:42:21 -0400

Very good point indeed made my Gunter related to a “configured” metric
which would yield applicable specific nature that  the link attribute
should be configured inside ASLA, however if dynamic PM measurement based
metric, then the metric would be the same for all applications and in that
case is a “non configurable” metric derived from external mechanisms, thus
could be deemed application independent only in that case.

Kind Regards

Gyan

On Fri, Jul 30, 2021 at 6:51 AM Dongjie (Jimmy) <[email-masked]> wrote:

> ASLA provides the flexibility to define the set of applications which can
> use a specific type of link attribute, it also allows to customize the
> attribute value for each application.
>
> As the generic metric mechanism will be used to define different types of
> new metrics, some of which may need the flexibility of indicating the set
> of applications it is used for, and may also need to generate
> application-specific metric values. In that case, it seems ASLA is the
> suitable approach for such metric advertisement.
>
> Best regards,
> Jie
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Voyer, Daniel" <[email-masked]>
Date: Fri, 30 Jul 2021 12:24:28 +0000

Sharddha,

From my last email in the list, I am also asking the same - can you be specific about what ASLA doesn't provide ? Maybe you have a point that I don't see.

dan

On 2021-07-30, 3:42 AM, "Lsr on behalf of Peter Psenak" <[email-masked] on behalf of ppsenak=[email-masked]> wrote:

    Shraddha,

    thanks,
    Peter

    _______________________________________________
    Lsr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lsr
    ------------------------------------------------------------------------------
    External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Jul 2021 14:50:14 +0200

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://mailarchive.ietf.org/arch/msg/lsr/OgGLI8yezUDWU-EZePoIj6y6ENk/

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]> wrote:

> 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: Shraddha Hegde <[email-masked]>
Date: Fri, 30 Jul 2021 13:22:14 +0000

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

Juniper Business Use Only
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]
Subject: Re: [Lsr] Generic metric: application-specific vs application-independent

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:

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://mailarchive.ietf.org/arch/msg/lsr/OgGLI8yezUDWU-EZePoIj6y6ENk/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!Tny8sU7cmjqLAbDVnliN7lck7J4tCBAHr10i3CW2G9oviUWo8b2RTJxCXc0gvWOz$>

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

G/

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Jul 2021 15:32:21 +0200

Shraddha,

Let's zoom on flex-algo for now ...

There are two types of FAD:

   Local Flexible Algorithm Definition - Flexible Algorithm Definition
   defined locally on the node.

   Remote Flexible Algorithm Definition - Flexible Algorithm Definition
   received from other nodes via IGP flooding.

If you think that you can use local FAD definition all over the
network to add or remove specific
metrics from consideration at each node - then the point as already
indicated in the email to Ron
is that this is extremely fragile and will make lot's of network
meltdowns. This is not how IGPs
should work.

The real operational consistency comes with Remote FAD signaled by IGP
flooding. I do not
see how you can do the latter without ASLA.

Thx,
R.

On Fri, Jul 30, 2021 at 3:22 PM Shraddha Hegde <[email-masked]> wrote:

> *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]
> > It doesn’t make sense to have Application specific values if a
> particular metric is obtained only dynamically,
>
>
>
> It sure does.
>
>
>
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!Tny8sU7cmjqLAbDVnliN7lck7J4tCBAHr10i3CW2G9oviUWo8b2RTJxCXc0gvWOz$>
>
>
>
> On Fri, Jul 30, 2021 at 11:05 AM Van De Velde, Gunter (Nokia - BE/Antwerp)
> <[email-masked]> wrote:
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 30 Jul 2021 15:38:41 +0200

Shraddha,

> 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

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Jul 2021 16:42:58 +0200

Hi Tony,

Why do we need separate and different copies of attributes for different
> applications?

Don't we have a bit mask as defined in ASLA RFCs (for example in section
4.1 rfc8919)   to indicate in which app given metric should be used ? I am
a bit puzzled why would we ever send copies of anything ...

Thx,
R.

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 30 Jul 2021 16:43:56 +0000

Gunter,

I agree with you that metrics that are dynamically generated
such as delay metric and  bandwidth metric  as defined in
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con
have application-independent
values and remain same for all applications.

The draft above defines Generic metric as a generalization of bandwidth metric,
that is a reusable tool. Generic metric advertisements may include dynamically generated metrics
or statically configured metrics. One interpretation of this is that generic metric
needs to be both application-independent as well as application-specific to
support both the sets of use cases.

However, when I look at the use cases that may require 
application-specific generic metric advertisements for statically 
configured metrics, I generally find that there 
is a simple solution using application-independent generic metric advertisements.
When I discuss how these use cases would be solved with application-specific
generic advertisements with different individuals, I get very complex proposals.

Consider the following scenario.
There are two flex-algos 128 and 129 in a network.
Operator wants to configure different monetary costs to each link
for flex-algo 128 and 129. Basically different cost for different application.

I would solve this using application-independent way as below.
Define metric-type 128 and metric-type 129. advertise both the metrics for
each link. Flex-algo FAD 128 to use metric-type 128. Flex-algo FAD 129 to use
metric-type 129.

Let us see how people will solve this use case with application-specific 
generic metric advertisements.

Rgds
Shraddha

-----Original Message-----
From: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> 
Sent: Friday, July 30, 2021 2:36 PM
To: Peter Psenak <[email-masked]>; Shraddha Hegde <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Tony Li <[email-masked]>
Cc: [email-masked]
Subject: RE: [Lsr] Generic metric: application-specific vs application-independent

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,

thanks,
Peter

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

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 30 Jul 2021 16:45:50 +0000

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

-----Original Message-----
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]
Subject: Re: [Lsr] Generic metric: application-specific vs application-independent

Shraddha,

> 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

> 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.
>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr/
> OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!VVLJCpIMrWixS17PeaBbfOpeb
> NPO4JUW4jparIn36jHmhv4_-W2_q_Smwo7oIYgk$
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/
> OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!Tny8sU7cmjqLAbDVnliN7lck7
> J4tCBAHr10i3CW2G9oviUWo8b2RTJxCXc0gvWOz$>
>

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 09:54:48 -0700

> 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

That’s ok, because doing that would be silly.

If you don’t want application B to use metric M, then you create metric N and use that for application B.

The generic metric is NOT one metric.  It’s a whole host of them.  Plenty to go around. Multiple metrics per application, all out of the single space.

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 10:00:33 -0700

> Can anyone explain how do I map generic metric to selected network applications I am to run in the network ? 

By manual configuration.

There are 256 generic metrics.

Application A uses metrics 1-10
Application B uses metrics 20-30
Application C uses metrics 100-110

Or any other mapping you care to create.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Jul 2021 19:06:50 +0200

But isn't this exactly where you would either start copying same data N
times if more then one app want to include given metric in its topo
computation ?

Or alternatively we would quickly get into mess of overlapping pools of
metrics used by app A and app B but not app C. I don't think
troubleshooting the network like this would be fun.

Consistent configuration on all nodes to use the same metrics for a given
app is also a challenge, but I guess FAD server push or general central
config push could help here.

Kind regards,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 30 Jul 2021 18:07:50 +0000

Tony -

> From: Tony Li <[email-masked]> On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 9:55 AM
> To: Peter Psenak (ppsenak) <[email-masked]>
> Cc: Shraddha Hegde <[email-masked]>; Robert Raszuk
> <[email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp)
> <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; [email-masked]
> application B to include the link X in its topology). How do you do that without
> ASLA? The answer is you can’t
> 
> 

[LES:] The issue is...how do I indicate that Metric M is for App A (and NOT for App B) and that Metric N is for App B (and not for App A)?

For Flex-algo this is possible because there is a FAD which specifies metric-type. 
But in general, applications do NOT have the equivalent of FAD.

ASLA exists to address the generic problem of how do I establish the association of a link attribute with an application - NOT just how do I do this for Flex.

> 
> The generic metric is NOT one metric.  It’s a whole host of them.  Plenty to go
> around. Multiple metrics per application, all out of the single space.

[LES:] Sooo, why do we actually need a "Generic Metric sub-TLV"?

We could do the same thing by defining a new sub-TLV code point for each new metric-type that gets defined.
The only thing the generic metric sub-TLV does for us is allow a single sub-TLV codepoint to be used and let the metric-type within the Generic-Metric sub-TLV specify which metric type it is.
But this also comes with limitations. You can only use the Generic Metric advertisement for metric types which are represented by an integer metric value. If we look at the existing metrics defined in the IGP Metric Types Registry we see that not all metric types match - for example you cannot encode delay metric in the Generic Metric sub-TLV. The draft does not discuss this point - but it surely needs to do so.

I do not object to the Generic Metric sub-TLV definition, but you need to understand that it is not usable for all types of metrics that may be defined.

    Les

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 11:11:19 -0700

> But isn't this exactly where you would either start copying same data N times if more then one app want to include given metric in its topo computation ? 

If more than one app wants to use the same metric, then there is no need to copy anything.  You simply all refer to the same metric.  It’s a flat space.

> Or alternatively we would quickly get into mess of overlapping pools of metrics used by app A and app B but not app C. I don't think troubleshooting the network like this would be fun. 

I don’t see that as a mess.  If you don’t like overlap, you don’t have to.  Again, there are lots of metrics. 256 of them.  If you burn one per FAD, you’ve still got 128 left for future applications.

> Consistent configuration on all nodes to use the same metrics for a given app is also a challenge, but I guess FAD server push or general central config push could help here.

It’s 2021.  Consistent configuration is driven by management plane automation.  Yes, consistent FAD definitions are achieved by (surprise!) FAD advertisement.  :-)

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 11:25:09 -0700

Les,

> [LES:] The issue is...how do I indicate that Metric M is for App A (and NOT for App B) and that Metric N is for App B (and not for App A)?

That does not need to be signaled.  Configuration information SHOULD NOT be signaled. Yes, I realize that there is a great deal of precedent. No, I don’t agree with it.  It’s a lot of unnecessary development overhead.

> But in general, applications do NOT have the equivalent of FAD.

Correct.  Future applications can be configured on a per-node basis as to what metric to use.

> ASLA exists to address the generic problem of how do I establish the association of a link attribute with an application - NOT just how do I do this for Flex.

It exists to mask over a problem by creating separate spaces of attributes for identical TLVs.

In the case of the generic metric, you do NOT need separate spaces because you don’t have an issue with overlap.

> [LES:] Sooo, why do we actually need a "Generic Metric sub-TLV"?

I believe that the draft explained the desire to route on bandwidth pretty well. From there, it seemed best to generalize.  If we are going to have an additional metric, why should we add them one at a time?  
Computer science rule 2: One, two, many.  We’re past two.  :)

> We could do the same thing by defining a new sub-TLV code point for each new metric-type that gets defined.

Yes, but that seems pretty silly.  Let’s just create a space and allow administrators to route on any metric that they come up with.  Dollars per mile might well be a good metric. :-)

> But this also comes with limitations. You can only use the Generic Metric advertisement for metric types which are represented by an integer metric value. If we look at the existing metrics defined…

You could encode delay as an integer.  Just use the correct units.  Number of microseconds or nanoseconds might be appropriate.

> I do not object to the Generic Metric sub-TLV definition, but you need to understand that it is not usable for all types of metrics that may be defined.

It’s true, if your metric is non-deterministic or temporal, yes, you need something more expressive.  The point here is to encode integers.  That’s what SPF is already set up to handle.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 30 Jul 2021 18:56:16 +0000

Tony -

> Sent: Friday, July 30, 2021 11:25 AM
> Cc: Peter Psenak (ppsenak) <[email-masked]>; Shraddha Hegde
> <[email-masked]>; Robert Raszuk <[email-masked]>; Van De
> Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>;
> [email-masked]
> >> If you don’t want application B to use metric M, then you create metric N
> and
> >> use that for application B.
> >
> > [LES:] The issue is...how do I indicate that Metric M is for App A (and NOT
> for App B) and that Metric N is for App B (and not for App A)?
> 
> 
> That does not need to be signaled.  Configuration information SHOULD NOT
> be signaled. Yes, I realize that there is a great deal of precedent. No, I don’t
> agree with it.  It’s a lot of unnecessary development overhead.
> 
> 
[LES:] You are taking us back 20 years in time and reintroducing the problems that ASLA was defined to solve.

It would be instructive to look at Figure 1 in https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1 .
The authors did a great job of documenting the state of affairs regarding RSVP-TE.
As you can see, implementations do not agree on what the necessary conditions are to consider a link as enabled for RSVP-TE.
Why didn’t we have interoperability issues?
The answer is that we did have interoperability issues. But vendors/customers managed to figure out what to configure to allow Vendor X to interoperate with Vendor Y.
It wasn't pretty.

Keeping things that are needed for interoperability local is a recipe for trouble. 

I ask you (again) to read the Introduction to RFC 8919/8920 - which details the problems ASLA is trying to solve. These are not imaginary issues - they are issues actually encountered in real deployments.

> > ASLA exists to address the generic problem of how do I establish the
> association of a link attribute with an application - NOT just how do I do this
> for Flex.
> 
> 
> I believe that the draft explained the desire to route on bandwidth pretty
> well. From there, it seemed best to generalize.  If we are going to have an
> additional metric, why should we add them one at a time?
> Yes, but that seems pretty silly.  Let’s just create a space and allow
> administrators to route on any metric that they come up with.  Dollars per
> mile might well be a good metric. :-)
> 
> 
> > The only thing the generic metric sub-TLV does for us is allow a single sub-
> TLV codepoint to be used and let the metric-type within the Generic-Metric
> sub-TLV specify which metric type it is.
> > But this also comes with limitations. You can only use the Generic Metric
> advertisement for metric types which are represented by an integer metric
> value. If we look at the existing metrics defined in the IGP Metric Types
> Registry we see that not all metric types match - for example you cannot
> encode delay metric in the Generic Metric sub-TLV. The draft does not
> discuss this point - but it surely needs to do so.
> 
> 
> You could encode delay as an integer.  Just use the correct units.  Number of
> microseconds or nanoseconds might be appropriate.
> 
[LES:] So you are proposing that all metrics - now and in the future - be restricted to Generic-Metric format?
I do not see why that is necessary - but if that is your intent, please state that explicitly in the draft so the WG can make an explicit call as to whether that is what we want to agree to do.
In the meantime, we already have three metric types (IGP, TE, Delay) which cannot be encoded in Generic-Metric - please document that in the draft.

   Les

> 
> > I do not object to the Generic Metric sub-TLV definition, but you need to
> understand that it is not usable for all types of metrics that may be defined.
> 
> 
> It’s true, if your metric is non-deterministic or temporal, yes, you need
> something more expressive.  The point here is to encode integers.  That’s
> what SPF is already set up to handle.
> 
> Tony

---

From: Peter Psenak <[email-masked]>
Date: Fri, 30 Jul 2021 21:37:01 +0200

Shraddha,

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

>   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

---

From: Peter Psenak <[email-masked]>
Date: Fri, 30 Jul 2021 21:52:08 +0200

Tony,

> If you don’t want application B to use metric M, then you create metric N and use that for application B.

well, I find it much less "silly" to signal a per application value of 
metric M, rather than come up with the new metric type every time a new 
application appears. Especially considering that we have an ASLA 
framework already defined in the RFC.

thanks,
Peter

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 13:08:23 -0700

Les,

> I ask you (again) to read the Introduction to RFC 8919/8920 - which details the problems ASLA is trying to solve. These are not imaginary issues - they are issues actually encountered in real deplo…

We’re talking past each other.  I objected to ASLA in it’s entirety.  I have been reprimanded by Acee and am trying to comply. Please consider that closed.

 I am now trying to make a different point entirely.  Please hear this.

My understanding is that we are still allowed to create TLVs outside of ASLA.  If not, then we have a much bigger discussion.  ;-)

Assuming that you agree that we are allowed to do some things outside of ASLA, then we need to decide whether generic metrics should be inside or outside of ASLA. The point that I’m trying to make is that
there is no practical benefit to putting it inside of ASLA.  With 256 different metrics, there is enough room to play. We do not need 256 metrics for RSVP, 256 for FlexAlgo, etc. etc.

Yes, I will happily stipulate that you COULD do it that way, but you don’t have to and it adds overhead, so why would you?

> In the meantime, we already have three metric types (IGP, TE, Delay) which cannot be encoded in Generic-Metric - please document that in the draft.

This is wholly orthogonal to the point of the discussion, so I will take this to a separate thread.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Fri, 30 Jul 2021 22:22:55 +0200

Tony,

> Yes, I will happily stipulate that you COULD do it that way, but you don’t have to and it adds overhead, so why would you?

isn't setting a bit in the existing TLV less overhead compared to 
sending a separate TLV if the same metric-type and value happens to be 
used by multiple application?

thanks,
Peter

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 13:25:23 -0700

Hi Les,

> [LES:] So you are proposing that all metrics - now and in the future - be restricted to Generic-Metric format?

Of course not.  We are simply trying to generalize.  As you note, we already have three different metric types floating around. Bandwidth would make 4.  With FA, we have the capability of using 128 different metrics simultaneously.  Let’s stop defining metrics one by one.

An administrator might have different metrics that they might want to use. It would be a shame to have to write up an RFC and create a new TLV every single time an administrator came up with a different metric schema.  So, let’s define a generic set of them and give the administrator some added capabilities.  We actually don’t have to standardize what the units are or what the metric represents.  We actually don’t care as long as we have metrics that we can SPF over.

As with anything that we add to the protocol, it is never a prohibition against future additions. If someone decides that there’s a good reason to have floating point or double precision metrics, they are welcome to write that RFC.

If you’re complaining about the name “Generic” because it’s not generic enough, well ok, we would be happy to consider alternative names.  Is “Generic Unsigned 32-Bit Integer Metric” better? :-)

> In the meantime, we already have three metric types (IGP, TE, Delay) which cannot be encoded in Generic-Metric - please document that in the draft.

If you mean that they should not be encoded in the generic metric because that would not be backward compatible with deployed nodes, I have no issues with that.  That wasn’t ever the intent.

If you something else, then I’m not following you.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 30 Jul 2021 20:29:22 +0000

Tony -

I assure you I am not talking about ASLA vs non-ASLA.
I am responding to your statement:

" That does not need to be signaled.  Configuration information SHOULD NOT be signaled."

Where "that" refers to the mapping of link attributes to an application.

I am saying not advertising this association is an interoperability disaster and has been proven to be so - and I pointed to the summary of cross-vendor RSVP-TE behavior as a definitive example of one such disaster.

If we disagree on that - so be it - but it is important to understand on what we disagree - otherwise the arguments we make on the consequences of that choice make no sense to each other.

   Les

> Sent: Friday, July 30, 2021 1:08 PM
> > It would be instructive to look at Figure 1 in
> https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-
> protocols-03#section-1 .
> > As you can see, implementations do not agree on what the necessary
> conditions are to consider a link as enabled for RSVP-TE.
> > The answer is that we did have interoperability issues. But
> vendors/customers managed to figure out what to configure to allow Vendor
> X to interoperate with Vendor Y.
> > It wasn't pretty.
> >
> > I ask you (again) to read the Introduction to RFC 8919/8920 - which details
> the problems ASLA is trying to solve. These are not imaginary issues - they
> are issues actually encountered in real deployments.
> 
> 
> 
> We’re talking past each other.  I objected to ASLA in it’s entirety.  I have been
> reprimanded by Acee and am trying to comply. Please consider that closed.
> 
> 
> My understanding is that we are still allowed to create TLVs outside of ASLA.
> If not, then we have a much bigger discussion.  ;-)
> 
> Assuming that you agree that we are allowed to do some things outside of
> ASLA, then we need to decide whether generic metrics should be inside or
> outside of ASLA. The point that I’m trying to make is that
> there is no practical benefit to putting it inside of ASLA.  With 256 different
> metrics, there is enough room to play. We do not need 256 metrics for RSVP,
> 256 for FlexAlgo, etc. etc.
> 
> Yes, I will happily stipulate that you COULD do it that way, but you don’t have
> to and it adds overhead, so why would you?
> 
> 
> > I do not see why that is necessary - but if that is your intent, please state
> that explicitly in the draft so the WG can make an explicit call as to whether
> that is what we want to agree to do.
> > In the meantime, we already have three metric types (IGP, TE, Delay)
> which cannot be encoded in Generic-Metric - please document that in the
> draft.
> 
>

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 13:29:37 -0700

Peter,

> isn't setting a bit in the existing TLV less overhead compared to sending a separate TLV if the same metric-type and value happens to be used by multiple application?

As previously noted, if applications are going to share a metric, then there is no need to send multiple TLVs.  One TLV is sufficient.

If the metric values are not equal, then multiple metrics and multiple TLVs will be required with or without ASLA.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Fri, 30 Jul 2021 22:36:10 +0200

Tony,

> As previously noted, if applications are going to share a metric, then there is no need to send multiple TLVs.  One TLV is sufficient.

well, not in case where you want a per application granularity of which 
application uses that metric on a particular ink. To do that you need 
per application/per link signaling. You propose to use different 
metric-type, we propose to use the bit in the common metric type. That's 
the whole difference.

> If the metric values are not equal, then multiple metrics and multiple TLVs will be required with or without ASLA.

sure, but if values are equal, ASLA has a benefit.

thanks,
Peter

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 13:37:22 -0700

Les,

> If we disagree on that - so be it - but it is important to understand on what we disagree - otherwise the arguments we make on the consequences of that choice make no sense to each other.

The past issue arose because implementations made an implied association between the presence of a TLV and enabling an application on a link.

The generic metric TLV does not do that and cannot do so because it is intrinsically not tied to any application.

Thus, this is not recreating the same disaster.

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 13:41:26 -0700

Peter,

> well, not in case where you want a per application granularity of which application uses that metric on a particular ink.

If you want per application granularity, then you need to send two TLVs, regardless of ASLA.

> To do that you need per application/per link signaling.

No, you can use two different metrics.

> You propose to use different metric-type, we propose to use the bit in the common metric type. That's the whole difference.

Adding a bit on a single ASLA TLV doesn’t give you per-application granularity.

> sure, but if values are equal, ASLA has a benefit.

What benefit? I only see overhead.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 30 Jul 2021 20:47:13 +0000

Tony -

Thanx for separating out this thread.
Inline.

> Sent: Friday, July 30, 2021 1:25 PM
> Subject: Re: [Lsr] Generic metric: Future metrics are not constrained
> 
> 
> Hi Les,
> 
> 
> Of course not.  We are simply trying to generalize.  As you note, we already
> have three different metric types floating around. Bandwidth would make 4.
> With FA, we have the capability of using 128 different metrics
> simultaneously.  Let’s stop defining metrics one by one.

[LES:] I do not object to the Generic-Metric TLV (I believe I stated that at the beginning). I might not have chosen to do it that way myself - but I am OK with it.
But one of the consequences of this choice is that not all metric-types can be advertised in this new format.
This means that for each metric type in the IGP Metric Types Registry (now and in the future) we need to state whether the type is encoded in Generic-Metric sub-TLV or not.

> 
> An administrator might have different metrics that they might want to use. It
> would be a shame to have to write up an RFC and create a new TLV every
> single time an administrator came up with a different metric schema.  So,
> let’s define a generic set of them and give the administrator some added
> capabilities.  We actually don’t have to standardize what the units are or what
> the metric represents.  We actually don’t care as long as we have metrics that
> we can SPF over.
> 
> As with anything that we add to the protocol, it is never a prohibition against
> future additions. If someone decides that there’s a good reason to have
> floating point or double precision metrics, they are welcome to write that
> RFC.
> 
> If you’re complaining about the name “Generic” because it’s not generic
> enough, well ok, we would be happy to consider alternative names.  Is
> “Generic Unsigned 32-Bit Integer Metric” better? :-)
> 
> 
> If you mean that they should not be encoded in the generic metric because
> that would not be backward compatible with deployed nodes, I have no
> issues with that.  That wasn’t ever the intent.
> 
[LES:] For existing metric types:

IGP: This is not encoded in a sub-TLV of any flavor.
TE: There is an existing sub-TLV - so yes - backwards compatibility is an issue. I see no reason to reinvent the advertisement for this.
Delay: The value used for this metric is derived from Min/Max Unidirectional Link Delay sub-TLV(34). This encoding does not fit in the Generic-Metric format and even if it did it would be redundant and not backwards compatible.

For new metric-types:

Whether they can be advertised in Generic-Metric is dependent upon the value associated with the advertisement.
Since you say you do NOT want to define a restriction on new metric-types to always match Generic-Metric format, that means for each new type we will also need to indicate whether it is advertised in Generic-Metric or not.

I hope this is not controversial - just a detail that needs to be attended to in the draft.

   Les

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 13:54:02 -0700

Les,

> This means that for each metric type in the IGP Metric Types Registry (now and in the future) we need to state whether the type is encoded in Generic-Metric sub-TLV or not.

Fair enough.  I would expect anything in the generic metric to a local matter anyway.  Anything that needs a new IGP Metric Type is clearly a global definition.

> Delay: The value used for this metric is derived from Min/Max Unidirectional Link Delay sub-TLV(34). This encoding does not fit in the Generic-Metric format and even if it did it would be redundant…

Of course, no objection. 

> I hope this is not controversial - just a detail that needs to be attended to in the draft.

Not controversial.  Please propose wording that would make you comfortable.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 30 Jul 2021 21:05:53 +0000

Tony -

> Sent: Friday, July 30, 2021 1:37 PM
> > I am saying not advertising this association is an interoperability disaster
> and has been proven to be so - and I pointed to the summary of cross-
> vendor RSVP-TE behavior as a definitive example of one such disaster.
> >
> > If we disagree on that - so be it - but it is important to understand on what
> we disagree - otherwise the arguments we make on the consequences of
> that choice make no sense to each other.
> 
> 
> The past issue arose because implementations made an implied association
> between the presence of a TLV and enabling an application on a link.
> 
> The generic metric TLV does not do that and cannot do so because it is
> intrinsically not tied to any application.
> 
[LES:] Node R1 uses metric-type A for Application X and metric type B for Application Y.
Node R2 uses metric-type B for Application X and metric type A for Application Y.
Both nodes are advertising both metric-types.
But neither node is aware of the inconsistency because nothing in the metric advertisement indicates how to make the metric-type/app association.

Clearly this is a problem.
Are you arguing that it is up to the operator to make sure that they associate the same Metric-type with the same application by making sure node configurations are consistent?

   Les

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 14:11:38 -0700

Les,

> Are you arguing that it is up to the operator to make sure that they associate the same Metric-type with the same application by making sure node configurations are consistent?

Yes.  More specifically, the management plane code should be debugged.  It is not the control plane protocol’s job to debug the management plane.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Jul 2021 23:16:17 +0200

IMO it is a control plane role to at least detect such inconsistency.

On Fri, Jul 30, 2021 at 11:11 PM Tony Li <[email-masked]> wrote:

> But neither node is aware of the inconsistency because nothing in the
> metric advertisement indicates how to make the metric-type/app association.
>
> Are you arguing that it is up to the operator to make sure that they
> associate the same Metric-type with the same application by making sure
> node configurations are consistent?
>
>
>
> Yes.  More specifically, the management plane code should be debugged.  It
> is not the control plane protocol’s job to debug the management plane.
>
> Tony
>
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 30 Jul 2021 21:16:49 +0000

Speaking as working member:

Hi Tony, 

You've made it abundantly clear that you don't think like the ASLA encoding. However, we have standardized the ASLA encoding in the LSR working group - this is a done deal.  You are free to propose an alternative but you this should not be done after the fact in a WG document that contains functionality the WG believes is useful. Also, any alternate proposals should cover backward compatibility and migration. 

Thanks,
Acee 

On 7/30/21, 4:42 PM, "Lsr on behalf of Tony Li" <[email-masked] on behalf of [email-masked]> wrote:

    Peter,

    Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 30 Jul 2021 21:19:21 +0000

Tony –

I don’t agree with your argument – but at least we are clear on the point of disagreement.

I will let the operator community comment on how your approach appeals to them.

Speaking as someone who (like you) gets called in to unravel problems in customer networks, I sure don’t want to leave ourselves vulnerable to something which is so easily broken. This means more late nights for me. 😊

   Les

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

Les,

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 15:49:31 -0700

Hi Acee,

> You've made it abundantly clear that you don't think like the ASLA encoding. However, we have standardized the ASLA encoding in the LSR working group - this is a done deal.  You are free to propose…

I’m not sure that I’m parsing your comments correctly.

We are not proposing an alternative to ASLA.  Nor do we wish to.

What we are proposing is a TLV that is not carried in ASLA.  There is nothing after the fact about it.  

As this is a new TLV, there are no backwards compatibility or migration issues. As always, legacy nodes will (ok, should) ignore the unrecognized TLV.

That said, I’m now VERY sure that I’m not understanding your comments.  Could you please clarify?

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 15:54:16 -0700

Robert,

> IMO it is a control plane role to at least detect such inconsistency. 

I understand the desire and I sympathize, but the architecture is not set up for that.  The management plane has the information, the control plane does not. Detecting inconsistencies would also require that the control plane understand the (if you’ll pardon the buzzword) intent of the network administrator. 

The history of software engineering supports this: trying to detect inconsistencies when you have less information is bound to be inadequate.

IS-IS makes a very poor test suite for management plane correctness.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 31 Jul 2021 01:04:44 +0200

Hi Tony,

If architecture enforces you to flood metric to topology mappings then you
don't have the issue of disconnect of control and mgmt plane.

So far IGPs are very solid in that respect. Much more solid then other
protocols.

I am a bit surprised we are ready to relax this and lower the bar here to
permit such mapping to be mgmt config driven.

Maybe definition of FAD should be revisited and defined in one place and
flooded ?

Thx,
R.

On Sat, Jul 31, 2021 at 12:54 AM Tony Li <[email-masked]> wrote:

> I understand the desire and I sympathize, but the architecture is not set
> up for that.  The management plane has the information, the control plane
> does not. Detecting inconsistencies would also require that the control
> plane understand the (if you’ll pardon the buzzword) intent of the network
> administrator.
>
> The history of software engineering supports this: trying to detect
> inconsistencies when you have less information is bound to be inadequate.
>

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Jul 2021 22:59:47 -0700

Hi Robert,

> If architecture enforces you to flood metric to topology mappings then you don't have the issue of disconnect of control and mgmt plane. 

> Both nodes are advertising both metric-types.

Even with ASLA you have a problem:

R1’s application X sees it’s metric type A that it advetises.  Then it sees R2 advertising metric-type B.  It ignores it, no question about it.
Application Y sees its own metric type B and it ignore’s R2’s metric type A.

Similarly, R2 is going to ignore R1.

Is there some SNMP trap for BOZOTCONFIG going off?  No.  The control plane has no idea what the configuration is supposed to be.  It
cannot be a sanity check for the management plane because it doesn’t have the correct information.  The only place that has that information is the
management plane itself.

ASLA didn’t magically fix things for you.

> I am a bit surprised we are ready to relax this and lower the bar here to permit such mapping to be mgmt config driven. 

Everything is management plane driven.

> Maybe definition of FAD should be revisited and defined in one place and flooded ? 

?  The definition of a FAD is flooded.  There at least we have an election mechanism across the area to pick something.  It may still not be the right one,
it may not be sane definition, but we should at least agree with what it is. If the implementations aren’t buggy.  ;-)

If you want, you can advertise the definition from only one place.  But then you have a single point of failure.  Want to avoid that?  Well the smart money 
advertises the FAD from multiple points.  And it’s the exact same FAD.  Now, if you have a decent management plane, what’s the difference between 
replicating the defintion three places or forty?  None.  You could replicate it everywhere in the area.  And you could avoid flooding.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 31 Jul 2021 15:42:59 +0000

Tony -

I think Robert has it correct here.
This isn't a "plane violation" issue.

The requirements are that each node advertise link attributes and indicate with which application(s) a given attribute is associated. Only the sending node knows that - but the receivers need this information in order for the application to operate correctly. So it is necessary for the originators to include an indication of the associated application(s) in the advertisement.

It is still possible, of course, for this to be misconfigured. No one is asking for the control plane to try to detect this. But if the architecture does not provide a way for necessary information to be advertised then it is the architecture which needs to be fixed.

Would you expect the protocol to correctly perform topology specific calculations if the advertisements from each node did not include a topology ID?

   Les

> Sent: Friday, July 30, 2021 11:00 PM
> To: Robert Raszuk <[email-masked]>
> Cc: Les Ginsberg (ginsberg) <[email-masked]>; Peter Psenak (ppsenak)
> <[email-masked]>; Shraddha Hegde <[email-masked]>; Van De
> R1’s application X sees it’s metric type A that it advetises.  Then it sees R2
> advertising metric-type B.  It ignores it, no question about it.
> Is there some SNMP trap for BOZOTCONFIG going off?  No.  The control
> plane has no idea what the configuration is supposed to be.  It
> cannot be a sanity check for the management plane because it doesn’t have
> the correct information.  The only place that has that information is the
> management plane itself.
> 
> ?  The definition of a FAD is flooded.  There at least we have an election
> mechanism across the area to pick something.  It may still not be the right
> one,
> If you want, you can advertise the definition from only one place.  But then
> you have a single point of failure.  Want to avoid that?  Well the smart money
> advertises the FAD from multiple points.  And it’s the exact same FAD.  Now,
> if you have a decent management plane, what’s the difference between
> replicating the defintion three places or forty?  None.  You could replicate it
> everywhere in the area.  And you could avoid flooding.
> 
> Tony
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 31 Jul 2021 18:04:23 +0200

And just to add one more observation ...

Yes we need to configure something in both cases, but:

- If I misconfigure ASLA mapping on one node that will be consistently
visible domain wide. Depending on the actual metric it may also be trivial
to detect if the mistake is between float and integer if someone or some
implementation wants to detect it.

- If I misconfigure metric to FAD mapping on one node (regardless if I do
CLI or Mgmt server push model) then it may be actually very hard to detect
as the effect of this may be popping out far from that very "badly
configure" node.

Thx,
R.

On Sat, Jul 31, 2021 at 5:43 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> The requirements are that each node advertise link attributes and indicate
> with which application(s) a given attribute is associated. Only the sending
> node knows that - but the receivers need this information in order for the
> application to operate correctly. So it is necessary for the originators to
> include an indication of the associated application(s) in the advertisement.
>
> It is still possible, of course, for this to be misconfigured. No one is
> asking for the control plane to try to detect this. But if the architecture
> does not provide a way for necessary information to be advertised then it
> is the architecture which needs to be fixed.
>
> Would you expect the protocol to correctly perform topology specific
> calculations if the advertisements from each node did not include a
> topology ID?
>
>    Les
>
> > Sorry, that’s a bill of goods.  Let’s look at the reality, with ASLA.
> Here’s the
> > example that Les proposed:
> >
> >
> > > [LES:] Node R1 uses metric-type A for Application X and metric type B
> for
> > Application Y.
> > it may not be sane definition, but we should at least agree with what it
> is. If
> > the implementations aren’t buggy.  ;-)
> >