Subject: RE: Backend TE Support

From: Bora Akyol <[email-masked]>
Date: Mon, 24 Apr 2000 12:40:58 -0700

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:[email-masked]>mailto:[email-masked]]
> > Sent: Thursday, April 20, 2000 11:13 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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
> > >
> > >
> >
> >
> >

---

From: [email-masked] (Anoop Ghanwani)
Date: Mon, 24 Apr 2000 15:49:49 -0400 (EDT)

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

---

From: Bora Akyol <[email-masked]>
Date: Mon, 24 Apr 2000 21:22:51 -0700

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:

> > ><http://www.ee.duke.edu/~ag/final-papers/multiplemetrics.pdf>http://www 
> .ee.duke.edu/~ag/final-papers/multiplemetrics.pdf
> > >
> > >

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 25 Apr 2000 08:33:18 -0400

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

---

From: Bora Akyol <[email-masked]>
Date: Tue, 25 Apr 2000 17:38:13 -0700

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

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 25 Apr 2000 23:23:30 -0400

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

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 25 Apr 2000 19:06:45 -0700

> how vendors implement dynamically calculated metrics.

not if you use the computation results for strict (also hierarchical) source routes only ;-)
A deployed protocol out there is a proof of existence for that one.

        -- tony