The MPLS WG Archive

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

Hi Dave,

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.

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 (which BTW implies nothing in particular 
about administrative domains).  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.

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.

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

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.  

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.

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?

Regards,
Ben Mack-Crane


Vishal.Sharma@tellabs.com wrote:
> 
> Hi Dave,
> 
> This is a follow-up to my earlier response to your email. After internally
> discussing
> your point about the PML being an artificial restriction and the possibility
> of multiple exit points out of an MPLS domain, we think
> we understand what you were saying, but think that implementing that
> may require stretching an MPLS-based solution (which was our goal)
> a bit, since it may require information beyond what is easily available
> to MPLS. This was one reason we had not expanded our initial solution
> to include such cases.
> 
> However, your point is a valid one, and we'd like to explore to what extent
> such alternatives can be incorporated into an MPLS-based recovery
> mechanism such as ours. One of my colleagues, Ben Mack-Crane, who I believe
> understands your point best, will be sending out an email explaining
> what we think your point was, and we'd appreciate receving your feedback
> on whether we've captured it right, and other follow-up thoughts.
> 
> Regards,
> -Vishal
> 
> On Monday, April 17, 2000 11:40 AM, dallan@nortelnetworks.com
> [SMTP:dallan@nortelnetworks.com]
> wrote:
> > Vishal:
> >
> >    <snip>
> >
> > > I am not sure why you call it a "scalability hit". The RNT mechanism
> > > cannot
> > > be any worse than having one backup LSP per working LSP.
> > > Also, how do you get (n+1)^2 meshing (and what is "n")?
> > > In general if the backup paths form trees, you get savings.
> > >
> >    My concern is not with the RNT mechanism. It is more with the
> > construction of useful working and protection paths that are:
> >    - physically diverse
> >    - optimal
> >    That concern is not specific to your proposal.
> >
> >    <snip>
> >
> > > First, I am not sure how you define a protection domain (and whether that
> > > definition is the
> > > same as the one we use in our draft).
> > >
> >    Ultimately the problem I have is with the definition of protected
> > domain. It limits the protection domain to being a set of LSRs with an
> > explicitly identifed PSL and PML, which I take to mean it is a contiguous
> > MPLS cloud or some administrative subset which has single egress point
> > (which may be an artificial limitation). The statement that the PSL and PML
> > are identified during the setting up of an LSP also bounds the granularity
> > of the merge function to being that of the FEC that the LSP is set up to
> > forward. I find this limiting.
> >
> >    So why is there an explicit merge function inside the MPLS cloud?
> > The whole network will not be MPLS, therefore merge can be deferred further
> > towards the edge of the network and increased reliability can be obtained if
> > the protection domain extends beyond MPLS domain. Where the merge function
> > occurs for a specific packet will not be known to the PSL at LSP setup as it
> > is a function of overall network state ands that's OK. How packets at some
> > point downstream end up back on a common routing to a host doesn't have to
> > happen at the granularity of the LSP originated at the PSL and may not
> > happen until a true single point of attachment to the network is reached
> > many hops beyond the edge of the MPLS cloud.
> >
> >    If such a thing as the PML existed, then the PML would have to
> > promiscuously accept packets from both the working and backup trees anyway
> > as not all failures in a tree would be propagated to all PSLs. So it is
> > really nothing more than an LSR which "by convention" stuff has to pass
> > through. It may anchor a RNT for livliness messaging for each tree that ends
> > there (which functionally can be disassociated from a promiscuous merge
> > function as there is no reason that fast failure detection needs common
> > state between working and protection paths either except at the PSL). What
> > that means to me is that there is a "single point of failure" (the "per LSP"
> > PML) which could be avoided "by convention" as well by allowing multiple
> > points of egress from the MPLS protected domain (which is a subset of the
> > network protected domain).
> >
> >    As much as we would like a tidy, administrable and measurable
> > definition of how far protection extended, IMHO the network would be more
> > reliable if we didn't cap the definition of protected domain as being wholly
> > within MPLS.
> >
> >    regards
> >    Dave
> >
> >
> >  << File: ATT00000.html >>