[j-nsp] Juniper MPLS VPN using PE-P and P-PE LSPs !

[vaibhava varma]

HI Mark

Thanks again for sharing your views :-)

I was wondering whether mLDP with Junos has been out of roadmap and
now ready for field deployment ?

Regards
Varma

On Mon, Dec 26, 2011 at 8:40 PM, Mark Tinka <mtinka at globaltransit.net> wrote:
> 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.



-- 
Regards
Vaibhava Varma