The MPLS WG Archive

[Anoop Ghanwani <aghanwan@nortelnetworks.com>]

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