The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

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
> > >
> > > > -----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