The MPLS WG Archive

[anoop@baynetworks.com (Anoop Ghanwani)]

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
> >
> > > -----Original Message-----
> > > From: Bora Akyol [<mailto:akyol@pluris.com>mailto:akyol@pluris.com]
> > > Sent: Thursday, April 20, 2000 11:13 PM
> > > To: mpls@UU.NET
> > > Cc: akyol@pluris.com
> > > Subject: Re: Backend TE Support
> > >
> > >
> > >
> > > [posted to the MPLS mailing list]
> > >
> > > A while back, a couple of BBN folks including myself had
> > > suggested to add a
> > > current network utilization metric to the ISIS-TE extensions
> > > which got shot
> > > down due to concerns roughly voiced as " Oh, if you flood
> > > dynamic network
> > > information, people may make bad decisions and destabilize
> > > the network." Of
> > > course, we could have put the flooding in there and waited on actual
> > > deployment of a protocol that made use of this, but oh well!
> > >
> > >
> > > But if there is an interest from the network service
> > > providers, maybe we
> > > can revisit this and add an extension to the ISIS-TE extensions.
> > >
> > >
> > > I would certainly be willing to co-author or author such an
> > > ID. Moreover,
> > > once we do put this extension in, it allows for different
> > > approaches to
> > > traffic engineering.
> > >
> > >
> > > Regards
> > >
> > > Bora Akyol
> > >
> > >
> > > At 04:05 PM 4/20/00 +0000, Dave Cooper wrote:
> > > >We've been running MPLS in the core for TE purposes
> > > >for quite some time now. However, one of the largest hurdles we
> > > >have faced is not just the stability of the protocol
> > > >but the actual management of protocol. More specifically,
> > > >the TE bandwidth statements used to make "optimal" path
> > > >decisions. (Keeping TE bandwidth consistent with
> > > >actual peak flows).
> > > >
> > > >In a large backbone, flows can fluctuate by large
> > > >variations (usually due to egress traffic shifts,
> > > >down customers, or other external factors) and its
> > > >obvious that TE bandwidth can become "outdated" fairly
> > > >quickly.
> > > >
> > > >I was inquiring to see if other providers or vendors
> > > >have been working on developing software to help
> > > >manage this critical component of MPLS.  The old adage
> > > >is correct in "Garbage in, Garbage out" and if TE
> > > >bandwidth is not accurate, LSPs will never be
> > > >routed over optimal paths.  We have been doing some
> > > >in-house development, but we're always interested in
> > > >outside input or even code that can be co-developed.
> > > >
> > > >-dave