The MPLS WG Archive

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

Dave,

Thanks for the comments. Read on ...

On Friday, April 28, 2000 10:54 AM, dallan@nortelnetworks.com [SMTP:dallan@nortelnetworks.com] 
wrote:
>
> 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.

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

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