The MPLS WG Archive

[Roch Guerin <guerin@ee.upenn.edu>]

Bora,

We had actually specified something very
similar for OSPF in RFC 2676, and also looked
quite extensively at the issue of what/when
to advertise in order to make routing decisions.
The source of fluctations were a bit different,
but most of the techniques investigated to
dampen them and the results on their impact
should be applicable to the TE problem.  Some
of this was documented in a SIGCOMM'98 paper
by Apostolopooulos et al.

Roch

> [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
> >
> >
begin:vcard 
n:Guerin;Roch
tel;work:215 898-9351
x-mozilla-html:FALSE
org:UPenn;Elec. Eng.
version:2.1
email;internet:guerin@ee.upenn.edu
title:Prof.
adr;quoted-printable:;;University of Pennsylvania=0D=0ADept. Elec. Eng., Rm. 367 GRW=0D=0A200 South 33rd Street;Philadelphia;PA;19104;USA
x-mozilla-cpt:;0
fn:Guerin, Roch
end:vcard