[e2e] [Fwd: State of MPLS deployments today]

[Ayyasamy, Senthilkumar (UMKC-Student)]

> -> Nicely put.  Still, this kind of medium-to-long time scale 
> TE doesn't
> -> necessarily require the flexibility (and associated complexity) of
> -> MPLS and the TE extensions to OSPF/IS-IS.  Tuning the 
> -> configuration of
> -> conventional IP routing protocols (like OSPF/IS-IS with 
> "static" link
> -> weights set at the network-management timescale) can often get you
> -> very close to the "optimal" distribution of traffic achievable with
> -> explicit routes.  For a recent survey of work on this approach, see
> -> 
> ->   http://www.research.att.com/~jrex/papers/ieeecomm02.pdf
> -> 
> -> from the October 2002 issue of IEEE Communication 
> Magazine.  This is
> -> not to say that MPLS can't "add value" but rather that it is not
> -> strictly necessary for good traffic engineering.
> 
>   We have had the same discussion before in TE-WG, IRTF-RRG.
>   I don't agree with what you said. 

Can you tell us which  statement you disagree?  No one mentioned
that optimizing OSPF weights is a substitute for MPLS way of traffic
engineering. Except that at what cost you do them. Each one has its 
own caveats. 

Almost all backbone provider will be aware of one's network topology 
and have day-to-day measurement statistics. Since Backbone are generally
over-provisioned, the chance of frequent failure occurrence is also
minimum. So, doing large time scale network planning is a clever 
way of backbone network management.

To exactly quote Randy's comments in some discussion, *it is better
to change few weights than throw thousand labels across the network.*

But, I accept that MPLS has its own positive features. If you closely
read the mail by Dennis Ferguson, you will understand that no one is 
standing against MPLS. It is the question of "complexity" and "need"
of the backbone.