Subject: RE: Info about mpls-vpn

From: [email-masked]
Date: Thu, 7 Sep 2000 08:17:42 +0100

<snip> Curtis observered:
> If you are running BGP/VPN inside LDP, the same improvement would
> apply to LDP or LDP inside aggregate TE tunnels.  Recovering a smaller
> number of TE tunnels should be easier than recovering a much larger
> number of LDP label mappings.
	[Harrison,N,Neil,INC1 X]  This is the key point Curtis.  From our
experience in other technologies we have concluded that multiple levels of
restoration are not a good thing.  Its better (i) to minimise the number of
nested technologies (for lots of reasons, but here let's just consider
failures and restoration wrt MPLS LSPs) and (ii) have fast bottom-level
(coarse) transport restoration with slower top-level (fine) transport
restoration.  Now, since LSPs can be nested and they can also be provided by
several LDP-type mechanisms (I am being generic here, and covering
vanilla-LDP, RSVP-LDP, CR-LDP and BGP4-LDP when I say 'LDP-type' as
techniques for label distribution) there are 2 variables:
	-	nested LSPs per se, say from same LDP-type, implies
practical restoration considerations would limit the number of nested levels
(assuming lower level has to react 1st)......but now hold-offs are within a
homogenous LDP-type
	-	nested LSPs from different LDP-types, implies same as above
from practical restoration considerations, but now we have potential
dependancies between the LDP-types.
	From the last point, and noting that one would want the higher level
LSPs to be more 'defect duration tolerant' than the lower LSPs, I am
wondering if all the possible client/server nested LDP-type relationships
have been considered......simply so that higher level LSPs don't start
reacting to seeing failures before lower level LSPs have had chance to
react?

	I gave the example of of a VPN whose top-level LSP topology was
constructed using BGP4 label distribution maybe sitting on server layer
TE-like LSPs constructs from (either?) RSVP-LDP or CR-LDP....but if we use
the latter, I assume  we also have to run vanilla-LDP (which would then be a
server layer to CR-LDP....assuming, for example, I was running DU).  Now
since the correct forwarding behaviour of an LSP at level N is predicated on
there being a valid server LSP at level N-1 (and this would recurse to the
number of nested LSP levels considered), my concern was whether we had
thought through these aspects at all?  Hence my question as to what LDP-type
nested relationships are better than others.  Does anyone else see my
concerns, or am I missing something in my problem statement? 

> If you look at the scaling issues of the overall problem and at the
> fault recovery problem dropping LDP entirely and doing TE tunnels
> inside TE across areas has advantages over LDP alone or LDP inside TE.
	[Harrison,N,Neil,INC1 X]  Quite......and this is the view I am
coming to, minimise LDP-types (and also number of nested LSP levels).

	Best regards, Neil

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 07 Sep 2000 11:33:41 -0400

Neil,

I just included the parts of your message that I wanted to clarify.

btw- We should probably us the terminology in
draft-kompella-mpls-optical-00.txt (PSC, etc) rather than inner and
outer or upper and lower.

> techniques for label distribution) there are 2 variables:

The edge-to-edge tunnels should not see a failure.  The failure within
the core should be handled by the TE tunnel within the core and should
be transparent to the edge-to-edge tunnels.

> reacting to seeing failures before lower level LSPs have had chance to

The lower level LSPs in effect do not get notification that a break
has occurred because they use the PSC tunnel which remains up.  The
IGP will flood the link change of the core link that went down, but
the lower level LSP does not know which set of links the PSC tunnel
uses and does not see any withdrawl of the PSC adjacency as long as it
has a backup or it is rerouted before the time threshhold to withdraw
it.  The IGP flood indicating a PSC is withdrawn and the resv-tear for
tunnels inside a PSC should be suppressed for some configured time
interval by the ingress to the PSC tunnel.

Regards,

Curtis