The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

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


At 08:33 AM 4/25/00 -0400, Anoop Ghanwani wrote:

>Well, the provider is the one that specifies that he/she would like
>to find a path from A to B that minimizes TE Metric X.
>
>What's wrong with just trying to minimize TE Metric X, then?
>
>-Anoop
>
>Bora Akyol wrote:
> >
> > Yes
> >
> > But it is not the provider that implements how the TE metric X is used to
> > calculate a path. Therefore, it will be best if we could agree on a meaning
> > or a standard way of calculating routes, would be nice.
> >
> > Bora
> >
> > At 03:49 PM 4/24/00 -0400, Anoop Ghanwani wrote:
> >
> > >It's actually a little different than the EXP bits in MPLS.
> > >
> > >Basically, we have multiple metrics and a service provider
> > >can configure TE Metric 1 to be delay across his network.
> > >The burden of maintaining consistency is with the provider.
> > >Once he knows what TE Metric 1 represents, he just asks
> > >for an LSP that minimizes that metric.  I don't see why it
> > >would cause interoperability problems.
> > >
> > >Unlike with the EXP bits, every vendor just treats these as dumb
> > >numbers and picks one (TE metric 1, 2, 3 or 4) and uses the one
> > >specified by the operator as the one to be minimized during path
> > >selection for an LSP, possibly ignoring all the others.
> > >
> > >-Anoop
> > >
> > > > Don
> > > >
> > > > I have reviewed the presentation and one concern that I have about
> > > defining
> > > > metric but leaving them optional and "unnamed" is that they will be 
> just
> > > > like the EXP bits. Everybody will know what they will be used for but
> > > > because they are unnamed we will not be able to use them in a 
> multi-vendor
> > > > environment.
> > > >
> > > > Hence, I would like to suggest that we name Optional Metric 1 as 
> the "Link
> > > > Utilization Metric", Optional Metric 2 as the "Affinity Metric", 
> Optional
> > > > Metric 3 as the "Bora" (just kidding), "Administrative Cost Metric".
> > > >
> > > > What do you think?
> > > >
> > > > Bora
> > > >
> > > >
> > > > At 01:54 PM 4/21/00 +0000, Don Fedyk wrote:
> > > >
> > > > >Bora
> > > > >
> > > > >We have proposed extensions to the TE metrics for multiple 
> metrics. This
> > > > >has been presented at the last two IETF meetings by me.   The last
> > > > >presentation is at
> > > > >
> > > > ><http://www.ee.duke.edu/~ag/final-papers/multiplemetrics.pdf>http:/ 
> /www
> > > .ee.duke.edu/~ag/final-papers/multiplemetrics.pdf
> > > > >
> > > > >
> > > > >We do not specify what is in the metrics, just that there are multiple
> > > > >metrics. The draft is focused on static metrics, since we believe that
> > > > >that is justification enough. We thought that utilization might be
> > > > >one of the possible values in the future I would be interested in your
> > > > >comments.
> > > > >I was planning to push fo this on the OSPF/IS-IS dicussion groups 
> in the
> > > > >next day or so.
> > > > >
> > > > >Don