Subject: RE: Info about mpls-vpn

From: [email-masked]
Date: Tue, 5 Sep 2000 15:48:58 +0100

Hi Curtis, it would also be nice to know (esp for operators) the pros/cons
of using various nested LDP-types.  For example, in theory it seems I could
run put BGP4 label-ditsributed LSPs (say for VPN constructs) over a server
layer of vanilla-LDP distributed LSPs or RSVP-LDP distributed LSPs.  I could
also think of other nested LDP-type combinations.  But a key question for me
here is 'What is their dynamic behaviour under all types of fault
condition'?  I still have not got my head around this one, and I sure some
modes of operation would be better than others.  If anyone else has pondered
on this and come to any views I would be grateful to hear them.

Regards, Neil

> -----Original Message-----
> From:	Curtis Villamizar [SMTP:[email-masked]]
> Sent:	Tuesday, September 05, 2000 2:36 PM
> To:	[email-masked]
> Cc:	D'Albenzio Raffaele; [email-masked]'
> Subject:	Re: Info about mpls-vpn 
> 
> 
> In message <[email-masked]>, Robert Raszuk writes:
> > 
> > Raffaele,
> > 
> > Technically - yes. RSVP-TE or even GRE tunnels between PEs will work
> > fine.
> > 
> > Operationally you need to make sure that if you go this path you will
> > need to engineer your TE LSPs the way that even at some failure
> > conditions you will still have an active LSP connectivity between PEs.
> > If not since you are not running LDP the core your PE-PE connectivity
> > will be lost for VPN customers as falling back to plain IP will not
> > help.
> > 
> > R.
> 
> 
> Don't build broken networks is always good advice.  If you are not
> using CAC (you are allowing overbooking but balancing traffic through
> other means) then there is no issue.  That just happens to be the only
> supported mode for LDP (and there is no opportunity to balance traffic
> to reduce load).
> 
> Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 06 Sep 2000 14:50:09 -0400

> on this and come to any views I would be grateful to hear them.

Neil,

Without going into any detail, I'll just make one point by way of
example.  Consider a 50 node core and 1,000 nodes around the perimeter
and what would happen if a link in the core failed.  Without tunnels
within tunnels there is the potential to have to lay out 1,000s of the
1,000,000 LSP required for a full TE mesh.  If the edge-to-edge
tunnels ride inside aggregate tunnels within the core, then a much
smaller number of the 2,500 tunnels in the core need to be rerouted.

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.

A subtle point is that if doing DU with LDP it would also help to
avoid advertising any LDP learned label mapping back out another
LDP/TE under the assumption that the TE nodes are logically full
meshed and that advertisement is redundant.

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.

This would make for some interesting simulation projects.

Regards,

Curtis