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

From: [email-masked]
Date: Tue, 2 May 2000 12:28:01 +0100

Dave Allan wrote:

> 	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.
> 
[Harrison,N,Neil,INC1 X]  This is generic (ie more complex) example of the
violation of layer independence.   Here the problem is that one should be
very careful when trying to use a defect (or QoS degradation) detection
process in one layer network to create actions in another layer network.
Consider this more simple example of just two self-homogeneous client/server
technologies:

Suppose we have a (server) Layer N trail between 2 nodes A and B.  And
suppose we have a (client) Layer N-1 trail also between nodes A and B.  So
here we have topological congruence between the different layer trails and
so it might seem useful to use the Layer N OAM functions to create actions
at the Layer N-1 level (or vice versa).  Suppose we now have some
performance degradation in the Layer N network that is detected via the
specific Layer N overhead that is terminated at the Layer N trail
termination point.  Let us map this through the Layer N=>Layer N-1
adapatation function to the Layer N-1 trail termination point.  Let us now
use this to invoke a restoration action at Layer N-1 (maybe via the Layer
N-1 control-plane).  Let us assume the Layer N-1 trail is now restored via 2
additional nodes C and D.....so the Layer N-1 trail is still A->B, with
routing A->C->D->B.  This gives 3 concatenated Layer N trails, ie A->C, C->D
and D->B.  Since the Layer N trail overhead *must* terminate in each of the
trails (ie at Layer N nodes) then to carry on with the assumption that we
can map the Layer N OAM functionality to the Layer N-1 trail termination
points means we need some way of getting this infomation (aggregated
somehow) to the Layer N-1 trail termination function.  This requires a
re-engineering of the Layer N network, ie a new control-channel of some sort
needs adding to Layer N.  This now creates backwards compatibility issues
for Layer N and is therefore unacceptable.

Consider now the case Dave Allan points out.  Here the trail at Layer N-1
(say an MPLS LSP) spans several *different* concatenated Layer N server
technologies, eg a ATM trail, a SDH trail and an Optical trail.  We now
create an extreme form of architectural layer violation problem by having to
match/carry the various Layer N OAM functions (over each other) and then
ultimately to the Layer N-1 trail termination point....since this is where
the Layer N-1 decisions (eg invoke protection-switching of Layer N-1 trail)
need to be made.  Clearly this is out of the question.

Note that the key architectural issue here is that the inter-node links (not
trails) which form the client layer network topology are created from
flexing trails (not links) in a server layer network.  And just as
importantly......note that since there will be multiple client layers of a
L1 network, and each will have a different topological (and highly
uncertain) traffic demand (and where the access points of each client layer
will not be congruent between themselves, and so by inference not congruent
with the L1 topology), then this implies that the L1 network (esp its
control-plane facets, such as addressing) *must not* be simply related to
any one of its client layer networks.  This latter aspect is a very
important consideration for operators and needs to be well understood in the
context of deciding which control-plane should be used at the optical layer.

Regards, Neil

---

From: "David Allan" <[email-masked]>
Date: Tue, 2 May 2000 21:10:25 -0500

Vishal:

	<snip>
> >
> > 	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).
> 
	<snip>
> 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.
> 
	Yes:

	As for 1, MPLS MAY need to be cogniscent of multiple lower layer
restoration technologies across the length of an LSP and allow for lower
layer recovery where appropriate. I don't think we need to say much more at
this point. 

	As for 2, in the absence of lower layer restoration, MPLS should be
congniscent of any source of failure indication. Normally this would be
lower layers propagating defect indication  up the stack in the absence of a
layer repair strategy, but this may not be available OR not indicative of
all possible faults an LSP is succeptable to. Therefore we may end up in
conflict with other goals due to requisite layer violations. e.g. IGP
failure detection triggering MPLS layer activity (BUTT UGLY). 

	BTW if it is only MPLS subsuming SONET locally and still being
unable to deal with brain dead routers in the LSP, we have not gained much.
I doubt local repair strategy at the LSP level can scale. 

	regards
	Dave