[c-nsp] m-vpn

[Christian]

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/