The MPLS WG Archive

[Curtis Villamizar <curtis@avici.com>]

In message <20000420160524.C18374@globalcenter.net>, Dave Cooper writes:
> 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


Dave,

Solving this problem is what MPLS-OMP is intended for.  We do plan to
implement MPLS-OMP but there is a lot of work that needs to preceed
it.  OMP is on the back burner for now.  I'm busy with a CR
implementation.  We will also be making the CR bandwidth more dynamic
(use the greateer of a configured value or a filtered measurement).
That is also longer term.

The prior OMP documents are available at the temporary location:
http://www.fictitious.org/omp

[ Yes.  That's a real URL.  Don't be scared, its just a DNS name. :) ]

Regards,

Curtis