Subject: RE: Backend TE Support

From: "Don Fedyk" <[email-masked]>
Date: Tue, 25 Apr 2000 22:41:48 -0500

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:[email-masked]]
> Sent: Tuesday, April 25, 2000 8:38 PM
> To: Ghanwani, Anoop [BAY:BL60:485]; Bora Akyol
> Cc: [email-masked]; Fedyk, Don [BL60:2001:EXCH]; [email-masked]
> 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
> 
> 
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 26 Apr 2000 09:28:41 -0400

In message <[email-masked]>, "
> the less people agree with you. ;-)

Bora, Don,

A compromise that seems to have worked well in diff-serv was to split
the 6 bit space into two parts, one predefined, where some consesus
was needed for assignement and the other was designated for
local-assignment.

The same sort of compromise would probably please the most people in
this case as well.

I don't mean to lend my support for this proposal by commenting and
suggesting a compromise.  By introducing too much protocol which is
partially defined, and possibly not well enough thought out, we could
be creating the standards process equivalent of a Tower of Babel.
[Which might not be policially correct since that's ISO territory. :)]

Curtis

---

From: Bora Akyol <[email-masked]>
Date: Wed, 26 Apr 2000 13:08:30 -0700

What we can do alternatively is leave this draft as is, but start another 
draft that is "informational" and documents what metrics people are using 
and how they can be used in an SPF computation.

Does this make sense?

Bora

At 09:28 AM 4/26/00 -0400, Curtis Villamizar wrote:

>In message 
><[email-masked]>, "
>Don Fedyk" writes:
> >
> > Bora
> >

---

From: [email-masked] (David Wilder)
Date: Wed, 26 Apr 2000 16:15:39 -0400 (EDT)

That sounds like a very good idea Bora.  

Dave

---

From: [email-masked] (Anoop Ghanwani)
Date: Wed, 26 Apr 2000 16:22:23 -0400 (EDT)

The existing draft already documents some of the commonly used metrics 
such as delay, hop count, etc. in an informational section.
Were you looking for more detail?

-Anoop

---

From: Bora Akyol <[email-masked]>
Date: Wed, 26 Apr 2000 13:31:36 -0700

There may be more metrics that may be interesting. Two that came to my mind 
are:

1) Filtered Link Utilization Metric: This is a low pass filtered version of 
the current link utilization.
2) Raw Link Utilization Metric: This is an unfiltered version of the link 
utilization. Shows the instantaneous value at the time the LSP was sent.

What does separation buy the current draft? I think it allows us to quickly 
review the draft and pass it without focusing on the details of the metrics.

What do you think?

Bora

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 26 Apr 2000 18:06:38 -0400

> and how they can be used in an SPF computation.

Bora,

That would help.

It might also be necessary to provide some sort of advice or
conventions on flooding frequency since flooding frequency will
substantially affect many algorithms.  Attempts to provide a high
degreee of adaptivity can either react very slowly or too quickly and
go unstable if the flooding frequency and the adaptivity reaction time
are not well matched.

Curtis

---

From: Bora Akyol <[email-masked]>
Date: Wed, 26 Apr 2000 15:51:05 -0700

OK!

I would be willing to author/co-author/edit such a draft, but would need 
help on defining the metrics and formulating them to fit the TLVs, LSAs etc.

Any volunteers?

Bora

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 27 Apr 2000 09:37:17 -0400

Bora,

Perhaps you missed this prior comment:

   I don't mean to lend my support for this proposal by commenting and
   suggesting a compromise.  By introducing too much protocol which is
   partially defined, and possibly not well enough thought out, we
   could be creating the standards process equivalent of a Tower of
   Babel.  [Which might not be policially correct since that's ISO
   territory. :)]

I am not in favor of a draft which defines information to be
advertised with no stated purpose.  This is a lot like the old TOS
bits, which all sounded like a great idea.  I recall, cost,
throughput, delay, and what was the other one.  They never got used.
IP is fortunate to have minimized such baggage, unlike OSI.

OTOH, I do expect to be working on an MPLS-OMP implementation (RSN?)
and will resubmit the OSPF-OMP and MPLS-OMP drafts for consideration
again by the respective work groups.  The OSPF WG seems inclined to
advance the OSPF-OMP as experimental, but I'd prefer to split it in
two, one on flooding, one on OSPF-OMP forwarding.  The MPLS-OMP work
relies on the OSPF-OMP flooding only.  There was also a very small
ISIS-OMP draft which needs to be revised since the sub-TLVs used
conflict with sub-TLVs later taken by ISIS TE extensions for CR.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 27 Apr 2000 09:54:45 -0400

In message <[email-masked]>, Tony Przygienda writes:
> Recently a whole Ph.D. thesis has been done on that very topic
> by  Apostolopoulos in Watson/UMD, may be worth reading before
> re-inventing ...
> 
>     -- tony

URL please.

Curtis

---

From: [email-masked] (David Wilder)
Date: Thu, 27 Apr 2000 10:32:59 -0400 (EDT)

Aren't we going down a rathole here?  The discussion on what metrics to put
in and how to define them can go on forever.  I agree with Bora.  Let's
move ahead with putting in the extra metrics; leaving the definitions flexible
for now.  Then we can add a supplemental draft later on with guidelines for
how these metrics should be defined.

Dave

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 27 Apr 2000 11:01:56 -0400

In message <[email-masked]>, Ll
oyd Wood writes:
> On Thu, 27 Apr 2000, Curtis Villamizar wrote:
> 
> > URL please.
> 
> http://www.cs.umd.edu/users/georgeap/
> 
> L.

Thanks.  I have seen this.

My only comment is that this is very good work but QoS routing != TE
when TE is being applied to large aggregates of traffic in IP
backbones (or any other backbone where large aggregates of traffic are
handled by a relatively small number of extremely persisitent tunnels,
whether tunnels provided by LSPs, ATM VPs, or lambdas).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 27 Apr 2000 11:20:09 -0400

> how these metrics should be defined.

Dave,

I was just responding to the "Any volunteers?" question from Bora
which seemed likely to be directed to me as a result of the "It might
also be necessary ..." comment.

I don't want to be an obstructionist but I do want to point out that
there is a reason for my not wanting to add to or support this work
unless it is better defined.  We'll have to see if WG consensus is
with you to move forward with this.

I am also pointing to OMP as an example of a use of additional metrics
which for better or worse, is well defined.  I strongly believe in
having "working code and first" and then advancing a document so I've
presented OMP, will implement, then ask for advancement as
experimental, then only after deployment suggest standards track
advancement.  Don, Bora, and others, seem taking the opposite approach
in defining protocol with the intemtion of later determining a use for
it.  In the past the IETF has insisted that things be well thought out
and documented and has avoided protocol options with uncertain usage.

Curtis

---

From: Bora Akyol <[email-masked]>
Date: Thu, 27 Apr 2000 09:24:25 -0700

Curtis

Aren't we generalizing here?

I am interested in seeing an implementation of a routing protocol that is 
sensitive to the status of the network instead of being static. Unlike OMP 
however, I would like to start simple by not creating hot spots first and 
then build on it.

I have reviewed the OMP work extensively about one year ago and agree that 
it has merit, on the other hand it can benefit from theoretical analysis of 
stability of the filters that are employed on the link utilization instead 
of defining a set of  filters that work in a simulation environment but may 
not work for all networks under all conditions. (I think such an analysis 
would make an excellent thesis topic by the way)

I think that the SIGCOMM 89 paper by Zhinky and Khanna is a good starting 
point on applying control theory concepts and methods to analyzing a 
dynamic metric, and should be reviewed by all that are interested in 
dynamic network-sensitive routing in the Internet.

The fact that Don et al. had started work on a set of metrics that can be 
flooded as part of the LSPs means that I can use their mechanisms to 
implement my simple load-sensitive routing protocol.

So I don't see any point on not supporting flooding of four (essentially) 
opaque metrics. OMP surely can use them too , right?

Anyway, as I said before, I think that there is a lot of work to be done in 
the area of traffic engineering that does and does not use MPLS. I think 
the WG needs to be supportive of such developments. (Of course according to 
the charter of the WG, if these topics are not included, we should take 
them elsewhere)

Regards

Bora

At 11:20 AM 4/27/00 -0400, Curtis Villamizar wrote:

> > move ahead with putting in the extra metrics; leaving the definitions 
> flexibl
> > e
> > > > help on defining the metrics and formulating them to fit the TLVs, 
> LSAs e
> > tc.
> > > >
> > > > Any volunteers?
> > > >
> > > > Bora
> > >
> > >
> > > Bora,
> > >

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 26 Apr 2000 17:10:20 -0700

-- tony

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 27 Apr 2000 15:00:51 +0100 (BST)

L.

'Apostolopoulos' is a fairly rare search term for google.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 27 Apr 2000 11:20:46 -0700

> whether tunnels provided by LSPs, ATM VPs, or lambdas).

The measurement of  trends for different low-pass filtering techniques
on the accurary of information you get on average in your nodes and % blocking of calls or
% of packet drops will be holding for TE as well {assuming we're talking here about
dynamic LSP establishment or OMP'ish kind of load-balancing solutions}.
Available bandwidth in TE is nothing else but QoS in one metric _in terms of
flooding_! Observe again, I'm not talking about computation algorithms you
apply to such information. This part you cannot deduct from this thesis, I agree
and will be specific to the engineering solution you pursuit ...

    thxn

    -- tony

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 28 Apr 2000 14:10:29 -0400

Bora,

As I said, I don't want to be an obstructuionist.

Best of Luck.  If your experiments work we'll strive to interoperate.

As far as IETF procedures goes, I'd favor experimental for anything
that is not fully defined.

Curtis