On Monday, December 26, 2011 10:37:12 PM vaibhava varma wrote: > Oh Yes what I mentioned for using LDP was without RSVP-TE > at all..I was trying to run RSVP-TE without using LDP at > all..
Ah okay. That makes sense, then, as I assumed you were still running LDP even after turning on RSVP for "LDP and RSVP" as opposed to "LDP or RSVP". > With Ivan's suggestion I was enabled to get lables for > the remote PE's Loopback,,, > > Thanks much to You and Ivan for your support on getting > hold of this issue.. Glad to hear it's working out. > I finally summarize the network setup requirement to > establish MPLS VPN Traffic flow across Broken LSP as Just from our own point of view (if you can find this useful), we use both LDP and RSVP in our network. LDP is used everywhere (especially the Metro-E Access switches) and RSVP is only used among the PE Aggregation routers. RSVP is used there as this is the point in the network where we terminate p2mp LSP's for NG-MVPN (IPTv Multicast services). This also includes facility backup (node-link protection) for p2mp and p2p LSP's. The core routers also run LDP and RSVP (RSVP for transit LSP's only). We're looking to support mLDP for p2mp LSP's for data Multicast services, as RSVP might be overkill for such deployments. All PE Aggregation routers run LDPoRSVP. We don't generally plan to run RSVP in the Metro-E Access, due to the sheer number of devices, but might if it makes commercial sense for a couple of customers, e.g., those that require 50ms failover between primary and protect circuits. Cheers, Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp