The MPLS WG Archive

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

David,

Thanks for the comments. Please see the responses below.

-Vishal

On Monday, April 24, 2000 3:53 PM, dallan@nortelnetworks.com [SMTP:dallan@nortelnetworks.com] wrote:

> 	I think the objectives of the framework needs a few tweaks:
> 
> 	Goals:
> 		
> 		Goal 'VII' probably should read, "the recovery actions of
> lower layers".

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.

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

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

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

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?

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

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

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

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