[c-nsp] m-vpn

Mon Jun 11 03:23:22 EDT 2012

I didn't came across any limitations/scalability issues running PIM to
distribute customer m-cast state did any of you please?
I'm a fan of the idea to let BGP carry everything, but I fail to see an
added value here (maybe PIC-Edge for m-cast?) And yet I'd still have to run
PIM at the edge
Also all this requires the upgrade of all the Intra/Inter AS RRs to support
the new SAFI
As far as the core signaling protocol is concerned MPLS-TE requires much
more state in the core than MLDP and I believe the trend now is to go the IP
FRR/LFA way instead of the complex MPLS-TE FRR leaving TE only for
exceptional cases where we really need to engineer traffic paths and protect
BW  or temporary solutions till core link upgrades

adam

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil Bedard
Sent: Friday, June 08, 2012 7:43 PM
To: Christian; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] m-vpn

Both Alcatel and Juniper have interoperable BGP-signaled implementations,
Cisco is kind of the odd vendor out.  They both also support both RSVP-TE
and MLDP for building MPLS MDTs as well.

Coming from a large provider with a BGP and LDP free core, and utilizing TE,
we much prefer the BGP signaled method with P2MP RSVP-TE than native PIM or
even using MLDP.  Providers have been asking Cisco for this stuff for a long
time now.  IOS-XR has MVPN with static routed P2MP RSVP-TE in 4.2.1, I doubt
NG-MVPN is far behind although they will be kicking and screaming the whole
way.

The Cisco methodology of using the mdt-safi is completely outdated at this
point and if you are already using BGP to signal this why not use it to
signal customer state instead of having a secondary complicated method to do
so...

Phil 

On 6/8/12 11:11 AM, "Christian" <plymouth78 at googlemail.com> wrote:

>Unfortunately the Juniper documentation sucks (don't they have Visio or 
>equivalent?).
>
>The RFC6514 combined with RFC6513 is horrible long and quite complex 
>because of a dozen of different options how to implement and run and 
>ways what to use for LSP-setup/signaling, c-state distribution, 
>de/multiplexing vpns and aggregating mdts and stuff.
>
>Somehow I don't like to run BGP to advertise c-state when customer 
>plays multicast.
>Cisco seems to concentrate on mLDP only (with BGP for autodiscovery 
>with mdt-safi), and dynamic S-PMSI triggered by multicast-rate. PIM 
>creates the c-to-LSP state on the ingress PE.
>
>Juniper implements the most complicated way in my opinion. NG means 
>running BGP for auto-discovery, BGP for c-state advertisements *and* 
>pruning, and then RSVP-TE for LSP setup.
>
>What to do now? Both RFCs are from Juniper and Cisco, but both 
>implement totally different concepts, one bloated, the other a bit 
>proprietary (or not?).
>
>Is it now Cisco's fault that we don't have interoperability, because 
>they didn't want to implement the tainted BGP-way? There are so many 
>options and possibilities in the RFC to implement mVPN so that 
>interoperability is in either case very unlikely to happen for the next 
>years.
>
>How difficult can Multicast be? Should we wait another 10 years for 
>good solution?
>
>2012/5/29 Mark Tinka <mark.tinka at seacom.mu>:
>> On Tuesday, May 29, 2012 06:23:45 PM Phil Mayers wrote:
>>
>>> No. SSM *is* sparse-mode. It's just sparse mode without *,g joins.
>>
>> In NG-MVPN (or BGP-MVPN, as Juniper call it nowadays), you can deploy 
>> an MVPN tree as either SPT-only, or RPT-SPT, when running PIM-SM.
>>
>> In NG-MVPN, BGP replaces PIM for all PIM functionality (hence the 
>> lack of PIM in the core network).
>>
>> RPT-SPT is akin to regular PIM in a PIM-based core, where an IGMP 
>> client tries to join a Multicast group, and (*,G) is initiated to 
>> toward the RP.
>>
>> However, SPT-only means that while an RP configuration may exist in 
>> the Receiver PE router, when the Receiver PE router receives a (*,G) 
>> join request, it searches for and consults what is know as a Source 
>> Active (SA) route in its routing table (SA routes are Type 5 BGP 
>> routes in NG-MVPN's). If it finds a matching one, it automatically 
>> converts the join message to a Type 6 Multicast route, which is the 
>> same as (S,G), and the appropriate route is installed in the router.
>> In SPT-only mode, single forwarder election, rather than the RP, is 
>> used to determine the source of the Multicast traffic.
>>
>> Pretty cool.
>>
>> You can read all about it here:
>>
>>        http://tools.ietf.org/html/rfc6514#section-14
>>
>> Mark.
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net 
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/