[c-nsp] m-vpn

[adam vitkovsky]

> 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:mark.tinka at seacom.mu] 
Sent: Sunday, July 01, 2012 11:07 PM
To: cisco-nsp at puck.nether.net
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.