Tony -
> -----Original Message-----
> From: Tony Li <[email protected]> On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 9:55 AM
> To: Peter Psenak (ppsenak) <[email protected]>
> Cc: Shraddha Hegde <[email protected]>; Robert Raszuk
> <[email protected]>; Van De Velde, Gunter (Nokia - BE/Antwerp)
> <[email protected]>; Les Ginsberg (ginsberg)
> <[email protected]>; [email protected]
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
