The MPLS WG Archive

[Vishal Sharma <Vishal.Sharma@tellabs.com>]

David,

Thanks for the observations. Comments below.

-Vishal

On Monday, April 17, 2000 11:40 AM, dallan@nortelnetworks.com [SMTP:dallan@nortelnetworks.com] 
wrote:


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

I'm glad you clarified that. As you rightly observe this is an issue with
any algorithm/intelligence that is used to compute the paths. However,
as I'd said earlier, we view the two as distinct problems. That is the
computation of the working and protection paths with the right characteristics
is independent of the mechanism used to perform fault detection, notification,
switchover, and switchback, and we are focusing on the latter.


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

No that is not how we have defined a protection domain. In our definition, a
"protection domain" is the union of the set of LSRs that lie on the working and
protection paths. This does not restrict them to lie in a single MPLS cloud,
or a single AS, or a single adminsitrative domain (or any subset of it). What
we are saying is that the working and protection paths must have a single
merge point (at some point along their path, possibly at the egress LSR), which
need not necessarily be in the same domain as the PSL.

As I stated earlier, although the most common interpretation of it might be
to refer to LSRs within a given AS or MPLS domain, the protection domain
is not restricted to lie within any such boundaries.

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

Ok, this I agree with (although see my question three points later).
But do you have any suggestion about alternatives that
we can incorporate into our mechanism?

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

Yes, absolutely right. As I've emphasized, nothing in the mechanism restricts
things to be within a single MPLS domain. If you could say what in our mechanism
makes you feel that the mechanism is restricted to a single MPLS cloud/domain, perhaps
we can try to rewrite that portion to correct this (since the mechanism, strictly speaking,
isn't restricted in that way).

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

I don't agree with this. The intelligence/algorithm computing the working and alternate
paths will have to know where the traffic on the two paths merges (possibly based on
network topology and network state), but it will have to know that. If you don't know
where the protection path merges into the working path, how are you going to get
a viable protection scheme (unless one is doing merely local repair)?


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

As before, I agree that the merge may not happen at the granularity of the LSP, and
as before, I'd like to know if you have any alternative to the proposal we have (merging
at the granularity of the LSP (which could be a tunnel, btw), was a workable choice
that we used, which seems reasonable to us). In fact, I have some difficulty seeing the
value of not merging at the granularity of the LSP, when it is the LSP that one is protecting.

About the MPLS cloud bit, I think you seem to be making the assumption that our
mechanism is somehow restricted to a cloud, when it is not.


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

Actually, it is an LSR that data gets merged at (and therefore, of course, it has to
accept packets from both the working and protection paths).

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

Again, you seem to be drumming home the point about a single MPLS domain,
whereas as I've pointed out numerous times, the mechanism is not restricted
to a single domain, hence there is no "single point of failure" in your sense.
There is of course, a single point of failure at the point at which the working
and protection paths merge, and this is unaviodable (except perhaps by
redundancy within the LSR that is the merge point or PML).

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

Agreed, but we aren't capping the definition that way! (As nearly as I can tell,
you're making that *assumption* about our mechanism! :-))