The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: Comments on draft-makam-mpls-recovery-frmwrk-00

Vishal

Feedback recurses....

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

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.

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

Thanks.

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

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

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

I know we agree, putting it in the I-D and having it survive guarantees consensus of the group.

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

Great!
Dave