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

[Dennis Ferguson]

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

I agree that that long-term busy-hour traffic statistics are well-behaved
and stable in networks of any size, I agree that the stability of these
numbers makes centralized off-line planning possible, and I agree that
doing a global traffic optimization like this can produce a much better
result in a given topology than a bunch of edge routers making
semi-independent decisions based on incomplete data.

What I think you are underestimating, however, is the complexity and
difficulty of that off-line engineering problem.  The fact is that
if you are so bandwidth-constrained that you need to closely engineer
traffic in your normal, fully operating topology, you are doomed before
you start because failures in the network often won't change the traffic
you need to carry but will always give you less bandwidth to carry it with.
What it is which hence requires the traffic engineering are the failure
cases, that is how do you best fit the traffic you've got into the network
you're left with after a failure.  This is a huge and open-ended problem.
You can start by analyzing each single router or fiber route failure,
assuming that 99.999% uptime (or whatever) makes two simultaneous indpendent
failures unlikely, but there also may be shared-cause failures, like an
equipment rack catching fire or a routing protocol failure, that you could
give some attention to characterizing as well.  And also note that in a
conventional network you have very limited mechanism for applying the results
of the analysis.  You may be able to find a set of OSPF link costs which
works in any single failure case, but what do you do if you can't find a
single set of metrics which works in all of them?  There's no normal
mechanism for changing metrics in response to failures elsewhere, so the
only alternatives may be investing in additional bandwidth to avoid those
cases or deploying something like MPLS which has some additional freedoms
to adapt to what you have on the fly.

So, while the traffic may not change much from day to day and week to week,
the topology that you need to fit that traffic into can change in an instant.
And while MPLS traffic engineering may be sloppy and imperfect, it does
have the advantage that it only ever needs to compute a result for a
single network topology, the one you currently have, and that is a
substantial simplification.

To be clear, I am not a great fan of MPLS, and if I were king I'd still
prefer to attempt to handle the traffic engineering problem by traditional
central planning, but I will admit that the latter certainly requires a
degree of skill and expertise at collecting data and using it to solve
big, fuzzy optimization problems which I don't possess.  It hence wouldn't
surprise me that some operators might prefer to avoid the expense of
developing the latter expertise by deploying MPLS as a poor-man's
alternative.

That said, I think most deployments of MPLS are not driven by traffic
engineering issues, but by "how can I do more stuff with my network and
make more money" speculative issues.

Dennis Ferguson