> PIM in the global table may not be an issue, but mVPN-based PIM is a different story. Right the need to peer with every other PE in the mVPM domain -but what would be the limitation on the PIM adjacencies on modern PE boxes 1k maybe 2k?
> You only need PIM at the edge where you're picking up the Source. Receiver PE routers only require IGMP Yes that would mostly apply in mVPN implementations for VPLS, however you'd need PIM at both ends for L3 VPNs where you are basically extending customer's m-cast domain over the your MPLS core > with the way the IETF are going, we shall soon see BGP carrying DNS. Hahaha right with my comment I haven't meant it quite like that :) > With IOS XE planning to support NG-MVPN soon That's great news, but still it would be great to see the support for the 7200 -but I guess it's not going to happen as they would like to force us to upgrade to ASR1k adam -----Original Message----- From: Mark Tinka [mailto:[email protected]] Sent: Sunday, July 01, 2012 11:07 PM To: [email protected] Cc: adam vitkovsky; 'Phil Bedard'; 'Christian' Subject: Re: [c-nsp] m-vpn On Monday, June 11, 2012 09:23:22 AM adam vitkovsky wrote: > I didn't came across any limitations/scalability issues running PIM to > distribute customer m-cast state did any of you please? PIM in the global table may not be an issue, but mVPN-based PIM is a different story. > I'm a fan of the idea to let BGP carry everything,... Well, I'm not (which is why I still prefer LDP-based EoMPLS over BGP-based EoMPLS), but it makes sense for Multicast. I always said, with the way the IETF are going, we shall soon see BGP carrying DNS. That's the point I'll hand in my RJ-45 jacks and crimping tool :-). > 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 You only need PIM at the edge where you're picking up the Source. Receiver PE routers only require IGMP (although in operation, most folk would enable PIM anyway, as it automatically turns on IGMP). BGP is needed because the core doesn't run PIM. Without PIM in the core, you need a method to distribute Multicast state from Source to Receiver. > Also all this requires the upgrade of all the Intra/Inter AS RRs to > support the new SAFI One of the reasons we maintained Juniper route reflectors even though the Cisco's made sense. With IOS XE planning to support NG-MVPN soon, expect the ASR1001 (a favorite for route reflection, in my books), support for the MCAST-NLRI SAFI won't be an issue. > 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 Juniper already support mLDP for BGP-MVPN's, but like I said before, it's the same old VPLS BGP vs. LDP war. Eventually, Cisco will cave, especially since Juniper support both. Mark. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
