The MPLS WG Archive

[Anoop Ghanwani <aghanwan@nortelnetworks.com>]

Bora,

What you're saying does make sense.  There are however many issues
with defining what the metrics are.  First, we need acceptance from a
very
wide audience which is hard to get, because everyone is going to want
to see their favorite metric in there.  See, for intance how long 
it takes framework documents to mature (and the number of emails
on the list that discuss those issues too!).  Second, everytime 
someone decides they want to try a new metric, they will have 
to define a new TLV for it, and it'll require them to change code.

The disadvantages of defining exactly what the metrics are seems
to outweigh the advantages.  As Tony P. rightly pointed out, if
you're doing source routes, interoperability is not an issue anyway.
Besides, leaving them undefined provides flexibility to the provider
to use them as desired.  For example, a provider can choose to
use TE Metric 1 as delay in milliseconds and TE Metric 2 as delay
in microseconds.  When finding a path that is very delay-sensitive,
he can choose TE Metric 2 where he loses resolution at the high
end.  On the other hand, he could choose TE Metric 1 for longer
delay paths where resolution may be lost at the low end.

Would you plan on including multiple delay metrics in your draft?
I'd like to have that option.

-Anoop

Bora Akyol wrote:
> 
> If I understand you right, you just want to run the existing SPF algorithm
> on metric A/B/C/D.
> 
> This is agreeable, but one may want to run a different path determination
> algorithm than SPF based on a specific definition of the metric.
> 
> Also, note that if we do not define precisely what we mean by the metrics
> and how they will be used, there will inherent incompatibilities between
> how vendors implement dynamically calculated metrics.
> 
> Although, I agree with defining generic metrics in theory, it is much
> better to define what all possible metrics are and then allow a provider to
> flood up to N of them as part of the flooding.
> 
> Yes?
> 
> So who wants to volunteer to write an ID on what possible metrics can be
> defined.
> 
> Bora
>