[c-nsp] m-vpn

[Phil Bedard]

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/