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

[Jennifer Rexford]

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

This is a fair and important question.  We find that a single weight
setting works well under the vast majority of the failure scenarios,
and that the remaining cases can be handled if you allow a change to
one or two weights after the failure; the necessary weight changes can
be computed in advance.  (You can do an even better job if you select
the weight settings with the failure scenarios in mind, rather than
optimizing for the failure-free case.)  That said, you need to have a
management system in place that can effect these changes relatively
quickly after a failure occurs (and seems likely to persist).

In the end, this is largely a question of frequency of certain types
of failures and the timescale in which you need to respond, and the
relative cost of extra capacity compared to the complexity of the
routing protocols and supporting management systems.  These comparisons 
are a bit tricky, though, as they require quantifying the fault
tolerance and performance requirements, having an accurate failure
model, and quantifying the complexity of the routing protocol options.

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

I agree.  TE alone may not be sufficiently compelling (especially in
over-provisioned networks) but the desire to support other things
(allowing private addresses within a VPN, source-based or edge-based
routing, etc.) may be a stronger motivation.

-- Jen