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: [email protected] [mailto:[email protected]] On Behalf Of Phil Bedard Sent: Friday, June 08, 2012 7:43 PM To: Christian; [email protected] 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" <[email protected]> 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 <[email protected]>: >> 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 [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > >_______________________________________________ >cisco-nsp mailing list [email protected] >https://puck.nether.net/mailman/listinfo/cisco-nsp >archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
