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

[Christian Huitema]

> You're right. I take that back. In fact, given that MPLS path setup is
> pre-determined at edge (or an "end"), there are a number of methods
that
> you can apply to compute the "best" route across the network. Or the
> "ends" can monitor end-to-end traffic pattern and feed such
information
> to operators for future traffic management. Or the "ends" can perform
> traffic flow aggregation into MPLS trunks. If you don't have to worry
> about 50 msec circuit recovery constraints, you can interface with
> routing protocols to fast-reroute traffic...

Computing path at the edge of the network is intellectually tempting:
pushed to the extreme, it gives you the perfect "stupid network"
architecture. However, doing so bumps into three important obstacles: do
the edge points have enough information to compute the path correctly?
Can the edge points synchronize their decision effectively? How do the
owners of intermediate resource control the usage of their property?

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