[j-nsp] LDP breaks at MPLS/VPN Backbone

[Pedro Roque Marques]

maher at pd.jaring.my (maher adib) writes:

> Hi there,
> 
> My name is Maher and currently testing MPLS/VPN running on Cisco devices.
> I would like to ask if there is a break in LDP at core router(P), which
> sometimes due to misconfiguration or perhaps hardware failures,in terms
> routing mechanism and update how does on each PE routers detect the break
> in terms of running MPLS/VPN on Juniper devices such as on M20?
> 
> For a normal IP packet, I presummed the traffic will flow but if vpnv4
> routes?Normally, in Cisco devices, I need to implement MPLS FRR or TE.
> How about in Juniper devices? Is there any method to re-route without
> having a major migration on IP infrastructure?
> 

I'm not totally sure what information you are looking for so let me
try several answers.

You can configure a Juniper box (other systems as well, i am sure) to
use mpls as the network protocol for its peering sessions. That allows
you to detect failures in the forwarding plane, if that is what you
are concerned with. i.e. if you have the BGP peering session between
PEa and PEb use an mpls path, then if there is a box in the middle of
the network that has good control state but has messed up its
forwarding state (used to be a common ocurrence some time ago w. some
equipment) the bgp session will go down. Now this becomes harder to
check if there are route reflectors in the middle of the network...

If on the other hand you are concerned with control plane failures,
there are a set of failures for which, at the moment, there are no
good answers. LDP uses the topology that is calculated by the
IGP... however it is easy to have a misconfig where you have a given
link that is part of the IGP topology but that is not acceptable as an
mpls or ldp link. The only fool proff way to address this issue would
be for the IGP to calculate two topologies: one with ip links as it
does today and one with only ldp enabled (ldp session up) links...

In general, it seems that the pain level caused by this sort of
misconfigs is not yet high enough to justify the cost of generating
two topologies...