subject:"\[Lsr\] Generic metric\: application\-specific vs application\-independent"


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. 


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.
> Node R2 uses metric-type B for Application X and metric type A for 
> Application Y.
> 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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

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

>
> 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
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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


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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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


Hi Acee,

> Speaking as working member:
> 
> 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. 


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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

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


Les,



[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?


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



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2021-07-30 Thread Acee Lindem (acee)

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

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

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

On Fri, Jul 30, 2021 at 11:11 PM Tony Li  wrote:

>
> Les,
>
>
> [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?
>
>
>
> 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
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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


Les,


> [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?


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



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Tony -

> -Original Message-
> From: Tony Li  On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 1:37 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Peter Psenak (ppsenak) ; Shraddha Hegde
> ; Robert Raszuk ; Van De
> Velde, Gunter (Nokia - BE/Antwerp) ;
> lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs application-
> independent
> 
> 
> Les,
> 
> > " 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.
> 
> 
> 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

> Thus, this is not recreating the same disaster.
> 
> Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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


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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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



Les,

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


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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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


Tony,

On 30/07/2021 22:29, Tony Li wrote:


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.


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




Tony





___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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



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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

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



> -Original Message-
> From: Tony Li  On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 1:08 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Peter Psenak (ppsenak) ; Shraddha Hegde
> ; Robert Raszuk ; Van De
> Velde, Gunter (Nokia - BE/Antwerp) ;
> lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs application-
> independent
> 
> 
> Les,
> 
> >> 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.
> 
> 
> 
> 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?
> 
> 
> > [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.
> 
> 
> This is wholly orthogonal to the point of the discussion, so I will take this 
> to a
> separate thread.
> 
> Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Tony,

On 30/07/2021 22:08, Tony Li wrote:

Les,

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.

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?

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

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

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

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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


Les,

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



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?


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


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

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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


Tony,


On 30/07/2021 18:54, Tony Li wrote:




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



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.



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






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





___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Juniper Business Use Only

-Original Message-
From: Peter Psenak 
Sent: Friday, July 30, 2021 7:09 PM
To: Shraddha Hegde ; Robert Raszuk ; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
Cc: Les Ginsberg (ginsberg) ; Tony Li ; 
lsr@ietf.org
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent

[External Email. Be cautious of content]

Shraddha,

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

Juniper Business Use Only

*From:* Robert Raszuk 
*Sent:* Friday, July 30, 2021 6:20 PM
*To:* Van De Velde, Gunter (Nokia - BE/Antwerp)

*Cc:* Peter Psenak ; Shraddha Hegde
; Les Ginsberg (ginsberg) ;
Tony Li ; lsr@ietf.org
*Subject:* Re: [Lsr] Generic metric: application-specific vs
application-independent

*[External Email. Be cautious of content]*

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

 My opinion is that if any of the metric-types in the Generic metric
 sub-tlv can be co

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

Tony -

> -Original Message-
> From: Tony Li  On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 11:25 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Peter Psenak (ppsenak) ; Shraddha Hegde
> ; Robert Raszuk ; Van De
> Velde, Gunter (Nokia - BE/Antwerp) ;
> lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs application-
> independent
> 
> Les,
> 
> >> 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.



> > 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.
> 
> 
> 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.
> 
> 
> >> 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"?
> 
> 
> 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. :-)
> 
> 
> > 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 d

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

Les,

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


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


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.


>> 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"?


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


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


> 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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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


> 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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Tony -

> -Original Message-
> From: Tony Li  On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 9:55 AM
> To: Peter Psenak (ppsenak) 
> Cc: Shraddha Hegde ; Robert Raszuk
> ; Van De Velde, Gunter (Nokia - BE/Antwerp)
> ; Les Ginsberg (ginsberg)
> ; lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs application-
> independent
> 
> 
> 
> > 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
> 
> 
> 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.

[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

> 
> Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

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.

On Fri, Jul 30, 2021 at 7:00 PM Tony Li  wrote:

>
>
> 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
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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



> 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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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



> 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


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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2021-07-30 Thread Shraddha Hegde

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


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Friday, July 30, 2021 7:09 PM
To: Shraddha Hegde ; Robert Raszuk ; 
Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: Les Ginsberg (ginsberg) ; Tony Li ; 
lsr@ietf.org
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent

[External Email. Be cautious of content]


Shraddha,


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
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk 
> *Sent:* Friday, July 30, 2021 6:20 PM
> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
> 
> *Cc:* Peter Psenak ; Shraddha Hegde 
> ; Les Ginsberg (ginsberg) ; 
> Tony Li ; lsr@ietf.org
> *Subject:* Re: [Lsr] Generic metric: application-specific vs 
> application-independent
>
> *[External Email. Be cautious of content]*
>
> 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!VVLJCpIMrWixS17PeaBbfOpeb
> NPO4JUW4jparIn36jHmhv4_-W2_q_Smwo7oIYgk$
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/
> OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!Tny8sU7cmjqLAbDVnliN7lck7
> 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)  <mailto:gunter.van_de_ve...@nokia.com>> 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.
>
> 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/
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2021-07-30 Thread Shraddha Hegde

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

Juniper Business Use Only

-Original Message-
From: Van De Velde, Gunter (Nokia - BE/Antwerp)  
Sent: Friday, July 30, 2021 2:36 PM
To: Peter Psenak ; Shraddha Hegde ; 
Les Ginsberg (ginsberg) ; Tony Li 
Cc: lsr@ietf.org
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  On Behalf Of Peter Psenak
Sent: Friday, July 30, 2021 9:42 AM
To: Shraddha Hegde ; Les Ginsberg 
(ginsberg) ; Tony Li 
Cc: lsr@ietf.org
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) 
> *Sent:* Thursday, July 29, 2021 2:00 AM
> *To:* Tony Li 
> *Cc:* lsr@ietf.org; Shraddha Hegde 
> *Subject:* RE: [Lsr] Generic metric: application-specific vs 
> application-independent
>
> *[External Em

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

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.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Shraddha,

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

Juniper Business Use Only

*From:* Robert Raszuk
*Sent:* Friday, July 30, 2021 6:20 PM
*To:* Van De Velde, Gunter (Nokia - BE/Antwerp)

*Cc:* Peter Psenak ; Shraddha Hegde
; Les Ginsberg (ginsberg) ;
Tony Li ; lsr@ietf.org
*Subject:* Re: [Lsr] Generic metric: application-specific vs
application-independent

*[External Email. Be cautious of content]*

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/
<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) <mailto:gunter.van_de_ve...@nokia.com>> 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.

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.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

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  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.
>
> 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 
> *Sent:* Friday, July 30, 2021 6:20 PM
> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) <
> gunter.van_de_ve...@nokia.com>
> *Cc:* Peter Psenak ; Shraddha Hegde <
> shrad...@juniper.net>; Les Ginsberg (ginsberg) ; Tony
> Li ; lsr@ietf.org
> *Subject:* Re: [Lsr] Generic metric: application-specific vs
> application-independent
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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/
> <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)
>  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.
>
> 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/
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2021-07-30 Thread Shraddha Hegde

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 
Sent: Friday, July 30, 2021 6:20 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: Peter Psenak ; Shraddha Hegde ; 
Les Ginsberg (ginsberg) ; Tony Li ; 
lsr@ietf.org
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent

[External Email. Be cautious of content]

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/<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) 
mailto:gunter.van_de_ve...@nokia.com>> 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.

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/
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2021-07-30 Thread Van De Velde, Gunter (Nokia - BE/Antwerp)

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) <
gunter.van_de_ve...@nokia.com> 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.
>
> 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/
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2021-07-30 Thread Voyer, Daniel

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

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) 
> *Sent:* Thursday, July 29, 2021 2:00 AM
> *To:* Tony Li 
> *Cc:* lsr@ietf.org; Shraddha Hegde 
> *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 mailto:lsr-boun...@ietf.org>> *On 
> Behalf Of *Tony Li
> *Sent:* Wednesday, July 28, 2021 1:06 PM
    > *To:* Les Ginsberg (ginsberg)  <mailto:ginsb...@cisco.com>>
> *Cc:* lsr@ietf.org <mailto:lsr@ietf.org>; Shraddha Hegde 
>  <mailto:shraddha=40juniper@dmarc.ietf.org>>
> *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 unambiguous

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

2021-07-30 Thread Gyan Mishra

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

> 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
>
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Van De Velde,
> Gunter
> > (Nokia - BE/Antwerp)
> > Sent: Friday, July 30, 2021 5:06 PM
> > To: Peter Psenak ; Shraddha Hegde
> > ; Les Ginsberg (ginsberg)
> > ; Tony Li 
> > Cc: lsr@ietf.org
> > Subject: Re: [Lsr] Generic metric: application-specific vs
> > application-independent
> >
> > 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  On Behalf Of Peter Psenak
> > Sent: Friday, July 30, 2021 9:42 AM
> > To: Shraddha Hegde ; Les Ginsberg
> > (ginsberg) ; Tony Li <
> tony...@tony.li>
> > Cc: lsr@ietf.org
> > 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-inde

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

2021-07-30 Thread Dongjie (Jimmy)

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

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Van De Velde, Gunter
> (Nokia - BE/Antwerp)
> Sent: Friday, July 30, 2021 5:06 PM
> To: Peter Psenak ; Shraddha Hegde
> ; Les Ginsberg (ginsberg)
> ; Tony Li 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs
> application-independent
> 
> 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  On Behalf Of Peter Psenak
> Sent: Friday, July 30, 2021 9:42 AM
> To: Shraddha Hegde ; Les Ginsberg
> (ginsberg) ; Tony Li 
> Cc: lsr@ietf.org
> 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) 
> > *Sent:* Thursday, July 29, 2021 2:00 AM
> > *To:* Tony Li 
> > *Cc:* lsr@ietf.org; Shraddha Hegde 
> > *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
> > de

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

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  On Behalf Of Peter Psenak
Sent: Friday, July 30, 2021 9:42 AM
To: Shraddha Hegde ; Les Ginsberg 
(ginsberg) ; Tony Li 
Cc: lsr@ietf.org
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) 
> *Sent:* Thursday, July 29, 2021 2:00 AM
> *To:* Tony Li 
> *Cc:* lsr@ietf.org; Shraddha Hegde 
> *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 mailto:lsr-boun...@ietf.org>> *On 
> Behalf Of *Tony Li
> *Sent:* Wednesday, July 28, 2021 1:06 PM
> *To:* Les Ginsberg (ginsberg)  <mailto:ginsb...@cisco.com>>
> *Cc:* lsr@ietf.org <mailto:lsr@ietf.org>; Shraddha Hegde 
>  <mailto:shraddha=40juniper@dmarc.ietf.org>>
> *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 A

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