The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: draft-chang-mpls-path-protection Comments

Ben:

Thanks for your comments. Rooting back through the other drafts, this discussion should really be focused around the framework draft <makam-mpls-recovery-frmwork-00>. To my mind the issue is whether MPLS is a black box and the very worst manifestation of a failure is a 'x' msec. interruption of packet flow out of a particular interface, OR whether we allow "less specific" box behaviors such as the packets keep flowing out of the box, but it may be a different interface. Seems to me that there are cases for both.

<snip>

You are correct in noting that the PML is limiting, as
a single egress point for the MPLS protection domain;
however, removing this limitation requires some knowledge
beyond that necessarily held by the MPLS layer.

Yes, there would have to be a path diversity test combined with some link-state knowledge of the over all network to ensure that the alternate egress point was appropriate.

There are two extensions that I can think of based on your
comments (please let me know if I have misunderstood your
comments).

1) The working and recovery paths never merge as LSPs.
Instead, the recovery path terminates at an LER that is an
acceptable alternative to the LER terminating the working
path for the purpose of forwarding the FEC represented by
the working path.

In this case, the protection domain is still within a
contiguous MPLS cloud

Effectively yes. We have not discussed fast failure detection, propagation, and pre-planned alternate route mechanisms outside the MPLS space.

(which BTW implies nothing in particular
about administrative domains). 

Agreed, however such things MAY exist, such as intercarrier boundaries inside a contiguous MPLS space. That would be my only observation. The boundary MAY not be technical and in the real world that is what frequently happens. If there is some form of pre-emption, then it is also useful to constrain the space to minimize the amount of traffic distrupted.

The protection mechanism
still works with information available at the MPLS layer
(fault detection, protection actions, etc.).  However, selection
of the recovery path (outside the scope of this ID) requires
L3 knowledge to determine that the LER terminating the
recovery path is acceptable.

I would broaden the definition as selection suggests to me explicit routing, whereas increasing the reliabilty of implicit path construction would imply intelligent pruning of options. To a certain extent, conservative label retention in an implicit case implies some knowledge of which LSPs would be more optimal than others, and sufficient information should be available at the overall L3 layer (not just MPLS topolocy) to make that determination.

In practice this may be an attractive option, although
some thought may be required to apply this in an end-to-end
recovery design for other than best effort traffic.

Yes, bang on!, to my mind there is two goals to this effort in general. First is providing explicit recovery mechanisms for specific flows that require specific service guaratees, and second is raising the reliability bar overall. You're correct in identifying best effort, as e2e RSVP reservations carried through such an "LSP tunnel" require explicit black box behaviour to avoid the interruption of re-routing on a protection switch (or establishing a new "deaggregator"). That is NOT the scenario that I think a non-PML solution adds value to.

2) The protection domain spans both MPLS hops and L3 hops.

Not sure how this really differs from '1' except the suggestion that there are fast non-MPLS restoration mechanisms which require some overall coordination.

Here the protection domain is not within a contiguous MPLS
cloud, and recovery within such a protection domain may be
complex.  Since the protection domain includes both MPLS and
L3 hops, fault detection and recovery actions may be significantly
different depending on where a fault occurs (and the protection
mechanism would require L3 knowledge in some cases).  It may
be difficult to guarantee uniform recovery performance across
the entire protection domain. 




I think in general it is easiest to think of this as concatenated protection domains with redundancy at the domain boundary. Ultimately it is a form of "Per-Hop Protection" ;-)  as the lack of uniformity of mechanisms makes explicit guarantees difficult but the performance is the best the overall network can do. If we stick to that definition then there is really no difference between 1 and 2.

The advantage of this broader definition of protection domain
is that it is not necessary to merge the traffic at arbitrary
boundaries (e.g., at LSP terminations, AS boundaries, etc.).
The complexity, however, makes this definition more difficult
to characterize, and makes defining a coherent protection
mechanism harder.




Both of these extensions require some L3 knowledge, but the
second is the only one that requires L3 knowledge in the
protection mechanism itself.  The original mechanism was
intended to work entirely within the MPLS layer.  These
potential extensions would broaden the scope beyond MPLS,
at the cost of additional complexity.

If I get your inference, you assume that a non-MPLS protection mechanism requires some type of resource reservation.

Perhaps it is better to live with some limitations so that
the mechanism is simpler (there is some value in a "tidy,
administrable and measurable definition of how far protection
extended").  Thoughts?

My summary would be:

1) We need to clarify overall the goals of MPLS restoration. Is it explicit black box behavior or are we seeking a broader base of solutions that dovetail into the overall network. If we are discussing a broader base, then a 1:1 or n:1 non-"lsp merging" solution has applicability. If we are "black box" only as it works for all style of protections (1+1, n:1, 1:1), all styles of traffic (best effort, diffserv and RSVP pinnned route) and is measuable, then we'll have to tolerate less optimal e2e routing and topology to get that. Personally, I'd like a bigger toolbox.

2) I don't think we need to overload the recovery space by expanding the protected domain beyond MPLS, only acknowledge that we may concatenate protection mechanisms, they function autonomously, and may have multiple points of attachment. Coordination of protection across multiple transport technologies is out of scope if we are to make progress.

cheers
Dave