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

From: "David Allan" <[email-masked]>
Date: Thu, 20 Apr 2000 15:58:52 -0500

Ben:

	<snip>

> >      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.
> 
> Selection, in this case, was meant generically (not intended to imply
> explicit
> routing); however, the path protection mechanism draft does not address
> reroute recovery (this is covered in other IDs) and so the broadening
> you suggest may be out of scope for that ID.  Is there a need to address
> this 
> in the framework (I don' think the framework says anything in particular
> about 
> recovery path selection options)?
> 
	I'll admit, I've lumped the recovery mechanisms together where
protection switching with resource reservation (and the corollary effect,
pre-emption) is a superset of reroute recovery. To my mind, where reroute
recovery and protection switching collide head on is in every way but the
timely allocation of resources on the backup path (where specific resource
allocation is required and we're out to be frugal). The livliness
mechanisms, path routing, revertive protection etc. have common
requirements. Such as timliness, path diversity, minimal disruption of
ordering etc.  

	<snip>

> I was concerned that the broader defintion of protection domain being
> proposed 
> implied that ONE recovery action (e.g., PSL switch) would be able
> to recover from any fault in the protection domain.  I had trouble seeing
> how a fault on an L3 link could be correlated with the working LSP, and
> the 
> PSL informed.  The concept of concatenated protection domains is much
> simpler, and I think this allows a narrower definition of protection
> domain (uniform mechanism).  Redundancy/diversity/coordination at
> protection 
> domain boundaries is then the interesting problem.
> 
	Agreed, some of this is addressed by redundant egress LERs, as a
failure of the egress LER can be addressed in the MPLS domain, a failure
downstream of the egress LER is handed by the egress LER or a downstream
node in the network. (it wears two hats). If I'm into another MPLS domain, I
may have redundant trees, one anchored on the working egress LER and one on
the protection egress LER, (I'd probably have that anyway), and if it is
some other technology, it presumably would be non-MPLS re-route and may not
be as fast, but then thats what you get.

	<snip>

> Well... I wasn't trying to say anything about non-MPLS mechanisms.
> We are trying to further clarify the framework terminology (a summary
> has been posted to the mail list by Vas Makam) and "protection
> switching" implies resource reservation.  This is not to say that
> there are not recovery mechanisms that work otherwise (e.g., reroute
> recovery).  The path protection mechanism ID is aimed at protection
> switching, so resource reservation is assumed there, and this leads
> to some desire to have a mechanism that operates simply at the MPLS 
> layer.
> 
	I'm not out to re-invent the rest of the network either...

	<snip>

> It makes sense to have a bigger toolbox, as long as we have a reasonable 
> understanding of the tools and their appropriate use.  You have pointed
> out
> a useful alternative to be added, and we should try to develop a clear
> description for the affected IDs.
> 
	Agreed.

> > 
> >      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.
> 
> This seems reasonable.
> 
	Good,

	regards
	Dave

---

From: Vishal Sharma <[email-masked]>
Date: Thu, 20 Apr 2000 16:38:56 -0400

Dave,

I concur with Ben. Good thoughts all!
Please see my comments below (unneeded text deleted below).

-Vishal

On Thursday, April 20, 2000 11:19 AM, [email-masked] [SMTP:[email-masked]] 
wrote:
> 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.

I think what you mean above is different than what Ben alluded to in his reply
to you. If I understand you, you are asking that the MPLS recovery cover the
case not only of those problems where there is an actual break in traffic
(treating LSR as a black box), but also those cases where there is no
break in traffic, but things at the MPLS layer are messed up. My response
is: absolutely!
(In fact, Neil Harrison of BT in a response on the list a couple of days ago had made a very
good characterization of the types of errors that may require protection/recovery,
which I would recommend.
If you haven't seen that one or cannot find it, pl. let me know. I'll forward it.)

And, the framework document does allow for both these possibilities.
In fact, a look at the types of errors (enumerated in the framework document)
that could occur at the MPLS layer shows that they allow for
things like misbranching, errored packets, misdirected packets, etc.
If you feel there is something missing in the framework as it stands, please
let us know.

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

I got lost on the last sentence here. By pre-emption do you mean the
usual --- pre-emption of low priority traffic on the protection path by
working traffic once the protection path is brought into use?

> > 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.
> >
> conservative label retention in an implicit case implies some knowledge of
> should be available at the overall L3 layer (not just MPLS topolocy) to make
> that determination.

Again, I have a question. Why do you say that conservative label retention implies
a knowledge of which LSPs are more optimal?

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

Absolutely. Agreed.

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

I like the concatenated protection idea. This is sort of what I had alluded
to in an earlier email where I'd said that one may do protection of
a multi-domain LSP (ie, an LSP that spans multiple MPLS domains
one after another) on a segment by segment basis. Of course, the
implication above is more general than that.

<snip>

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

I think the recovery framework document encompasses the broader definition.
As before, if you feel something more is needed, let us know.

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

I'd say that we are indeed discussing the broader base. And yes (now that I
understand it more clearly), the non-LSP merging solution has applicability
and should be mentioned in the mechanism draft. (The framework draft
in any case does not refer to any particular solution(s).)

> 	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
> points of attachment. Coordination of protection across multiple transport

Agreed. I would like to add, however, that with the recent on-going activity in
the MPLS + crossconnects area, we might have to think about coordination
at least across the MPLS and optical transport networks (since that may be
an important case in practice).