The MPLS WG Archive

["Don Fedyk" <dwfedyk@nortelnetworks.com>]

Title: RE: Backend TE Support

Bora

We went through a lot of this thought process and came to the
conclusion that defining the place to put the metric was the
most we would do now. One of the rejected schemes was a metric
descriptor that told you the type explicitly. So a 4 byte
type vector could identify the metric carried and you could
actually do correlation if I put metric x as delay and you
put metric y as delay as long as we stuck to a standard
descriptor identifying "delay" we could interwork. 

So we currently propose an implicit definition as opposed
to an explicit definition. My understanding is you would
favor the more explicit definition. Then you need to define
the identifying codes and that is where the debates start.
I think it is like politics, the more you specific you get
the less people agree with you. ;-)

Don

> -----Original Message-----
> From: Bora Akyol [mailto:akyol@pluris.com]
> Sent: Tuesday, April 25, 2000 8:38 PM
> To: Ghanwani, Anoop [BAY:BL60:485]; Bora Akyol
> Cc: anoop@BayNetworks.COM; Fedyk, Don [BL60:2001:EXCH]; mpls@UU.NET
> Subject: Re: Backend TE Support
>
>
> 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
>
>
>