The MPLS WG Archive

[Dave Cooper <dcooper@globalcenter.net>]

Bora, i'll limit this since it is operational in nature but
i think that dynamically adjusting TE bw would probably prove
too unstable in a network running thousands of LSPs. Given large
variations in BW levels, tunnel thrashing could easily result. 
Also, IMO using a statiscal sample (hourly, daily or weekly) 
and taking the some peak percentile would probably result 
in a more stable and somewhat accurate representation of TE bw. 
Obviously, this would need to take place off the LSR.  Maybe 
other providers can  ellaborate if they see propagating this 
information beneficial.

My apologies for the operational nature of the thread :)

-dave



Bora Akyol wrote:
> 
> [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
> > 
> >
>