Subject: Comments on draft-makam-mpls-recovery-frmwrk-00

From: "David Allan" <[email-masked]>
Date: Mon, 24 Apr 2000 14:53:14 -0500

Srinivas:

	I think the objectives of the framework needs a few tweaks:

	Goals:
		
		Goal 'VII' probably should read, "the recovery actions of
lower layers".

		Goal 'X' really appears to be a subset of goal 'XII'. The
latency discussed in 'X' is only a subnet of the overall constraints and
performance characteristics 
		outlined in 'XII'. Suggest deleting 'X'.

		An implied goal is that MPLS based protection of traffic
should minimize the number of single points of failure in the MPLS protected
domain. It should be 
		explicitly brought out.

		Sometimes but not always, true "black box" behavior of MPLS
protection will be required. The egress point of a protected  LSP tunnel may
need to be pinned 
		to a specific LSR.  For some traffic types this requirement
can be relaxed.

	In 2.1.2 I'd like to suggest that a protection path may be
"pre-established", or "pre-qualified". If protection switch merely means a
PSL receiving notification of a failure on a specific LSP and switching
traffic to a different LSP which also ultimately gets the packets to the
same place, I really don't care how the alternate LSP came into being.
"pre-established" suggests that it was specifically created for the purpose
and that may not be the case.

	Cheers
	Dave

---

From: Vishal Sharma <[email-masked]>
Date: Thu, 27 Apr 2000 21:32:31 -0400

David,

Thanks for the comments. Please see the responses below.

-Vishal

> 		Goal 'VII' probably should read, "the recovery actions of

No, not really.  It isn't always clear what "lower layer" is in the MPLS context. 
For instance, could MPLS-based recovery take advantage of something in the 
IP layer, say  the Fast Link Liveness Protocol for fast failure detection. Supposedly,
and that is not a lower layer recovery mechanism. So we don't wish to confine
things to the "lower layers" alone.

> 		outlined in 'XII'. Suggest deleting 'X'.

I think you have a point here. We'll need to make this modification.

> should minimize the number of single points of failure in the MPLS protected

I guess minimizing single points of failure is the goal of protection in general.
Whether that should be an explicitly stated goal of MPLS-based protection,
I am not so sure about. I'll defer to my co-authors or others on the list for
viewpoints?

> 		to a specific LSR.  For some traffic types this requirement

Sure. As I mentioned in some earlier emails, I think both black-box and 
more explicit protection behavior is covered by the framework doc.

> and that may not be the case.

Ok, I think that's a good suggestion. We should probably incorporate that
in the text. (In any case, this will make the issue of having different egress
LSRs for the working and protection LSPs also make more sense.)

---

From: "David Allan" <[email-masked]>
Date: Fri, 28 Apr 2000 10:54:26 -0400

Vishal

Feedback recurses....

	<snip>
> things to the "lower layers" alone.
This is where I would have a problem and this relates to if MPLS is a layer
in it's own right or if it is purely an IP helper. If it is the latter, then
the WG should be renamed. This is also a clear mismatch with the OXC stuff
as there is just about guaranteed to be no visibility of livliess stuff with
the exception of possibly letting the control trail "proxy" OAM for the
lambda path. e.g. there may not be a router at either end of the lambdaSP
and the intermediate nodes cannot "see" anything. 

> I think you have a point here. We'll need to make this modification.
Thanks.

> I am not so sure about. I'll defer to my co-authors or others on the list
I'm interested in seeing it brought out as it produces absolute requirements
for the routing of the working and protection paths than the more motherhood
"maximize network reliability and availability".

> more explicit protection behavior is covered by the framework doc.
I know we agree, putting it in the I-D and having it survive guarantees
consensus of the group.

> LSRs for the working and protection LSPs also make more sense.)
Great!
Dave

---

From: Vishal Sharma <[email-masked]>
Date: Fri, 28 Apr 2000 12:00:31 -0400

Dave,

Thanks for the comments. Read on ...

> and the intermediate nodes cannot "see" anything.

I can see your point. As things currently stand, however, I think it is safe to
say that MPLS is not a layer in its own right. It is clearly tied to IP.
(As for renaming the WG, the Chairs and Area Directors need to handle
that one :-)).
I agree that without OAM, the control trail can, at best, proxy for the
actual lambda path. (BTW, this problem isn't unique to the OXCs alone, in
vanilla MPLS too, we have the problem of detecting liveness and health
of the working LSP --- as you are aware from the emails from Neil and Noel.
In fact, we  have struggled with this issue when writing the mechanism draft
for path protection, and we still are.)
But I am not sure how to solve this problem.

In any case, the issue you point to is a more general one, and not one
that I think can be resolved simply by some rewording in the framework.
I think the framework needs to be generic, at least on this aspect.

<snip>
> "maximize network reliability and availability".

Ok, I see what you mean. But I'll defer to my co-authors on that.  I guess
it could be put as one of the goals (it is still not a requirement, so that
might be ok.)

---

From: "David Allan" <[email-masked]>
Date: Fri, 28 Apr 2000 13:25:09 -0500

Vishal:

re: "lower" vs. "other" layers

	The issue to me is the wording. There are two thoughts we seem to be
discussing:

	1) Not taking premature recovery action in the presence of lower
layer restoration mechanisms.

	2) Considering all sources of knowledge of failure (including layer
violations).

	I'm talking about the first, when I say "lower", the second is where
you mean "other" and where we agree problems reside.

	I think the first may be a bigger problem area than we think.
Because MPLS is defined over multiple media, presumably an LSP can span
multiple media, and therefore WHERE a defect occurs matters as far as how
fast we can take corrective action.

re: minimizing single point of failure

	Deferring to co-authors is fine with me.

cheers
Dave

---

From: Vishal Sharma <[email-masked]>
Date: Fri, 28 Apr 2000 17:37:43 -0400

Dave,

> 	2) Considering all sources of knowledge of failure (including layer

You've hit the nail on the head!

> you mean "other" and where we agree problems reside.

Yes, you've put it quite succinctly.

> fast we can take corrective action.

Ok, if I read you right, what you'd like to do is to have the framework acknowledge both 1 and 2 
above,
and perhaps mention them separately. (Realizing of course that there are still issues
with 2), greater than those that there might be with 1). I think doing this would make
things clearer, while at the same time leaving room for different implementations.

-Vishal