The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

[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
> 
>