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

[Dmitri Krioukov]

> -----Original Message-----
> From: end2end-interest-admin at postel.org
> [mailto:end2end-interest-admin at postel.org]On Behalf Of Jennifer Rexford
> Sent: Friday, October 04, 2002 3:33 PM
> To: dennis at juniper.net
> Cc: huitema at windows.microsoft.com; pingpan at cs.columbia.edu;
> dpreed at reed.com; end2end-interest at postel.org
> Subject: Re: [e2e] [Fwd: State of MPLS deployments today]
> 
> 
> > 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).

On one hand (routing protocols), we have a requirement
for a management system (and in many cases, it is based
on those "night scripts"). On the other hand (MPLS), we
have a set of control mechanisms that are already provided.

The theoretical part of TE problem formulation and
solution also look simpler (especially from the
operational standpoint) in the MPLS case.

The question that really remains at the end is how
it's done -- namely, is this MPLS end really irrelevant
to end2end? :) After all, this is the only part that may
have unpleasant long-term consequences.

I'd say that a better position would be to avoid
obviously confusing discussion about ever-changing
MPLS justifications (look how many are surprised that
MPLS solves problems it was not designed to solve and
does not solve problems it was designed to solve :)
but to consider it as something given, as a sort of "external
constraint" (originated in the wonders of the marketing/
business world, maybe :)
--
dima.