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

[Ping Pan]

Hmmmm... narrow application? :-) Yes, MPLS with RSVP-TE could be used 
for better network resource management, aka traffic engineering. But in 
some of today's big backbones, where only approximately 10% of the 
overall bandwidth is in-use, and ton's of dark fibers are around, 
traffic engineering is obviously not carrier's first priority.

However, MPLS is currently provding two very critical applications.

MPLS VPN will transport carrier's IP and non-IP traffic through the same 
network. MPLS VPN is essentially doing what ATM and Frame Relay circuits 
had done everywhere several years ago. This is every carrier's 
bread-and-butter service. Managing such service is not easy.... Yes, 
some of MPLS VPN implementation can be very difficult to use. But let 
developers iron out the problems.

Given MPLS is building circuits over the network, high-availability is a 
key focus. (By comparison, just take a look at each carrier's budget on 
transport equipment gears for protection and restoration). MPLS can 
provide redundancy efficiently. By the way, let's set the record 
straight: MPLS fast reroute is not complex and expensive. In my past 
life, our implementation can switch several thousands of LSP's within 50 
msec without much CPU disturbance on routers. It's not that complicated.

Regards,

- Ping


Christian Huitema wrote:
 >
> It is not surprising that MPLS ends up targeting a narrow application,
> basically a form of traffic engineering.  Answering the three previous
> questions gets much simpler when the "edges" are the edges of a provider
> network, rather than the edges of the Internet, and when the timescale
> over which the decisions are made is expressed in days or months, rather
> than seconds or milliseconds: a provider can obtain information on
> network usage by statistical analysis of traffic over a long period; the
> edge points can be coordinated by a form of central planning; and the
> decisions are made by the very owner of the resource.
> 
> -- Christian Huitema