[c-nsp] VRF multicast, multiple receiver VRF, single source VRF

[Ross Halliday]

Hi,

> What is the clean/kosher way for multiple VRFs in VRF Lite CE to
> receive multicast from single source VRF.

VRF *lite*? Not much clean or kosher about that, to be honest.

> It looks like this is canonical solution for it:
> http://www.cisco.com/en/US/docs/ios/12_2sb/feature/guide/extvpnsb.html
> 
> But I want my all multicast specific special hacks in CE, I don't want
> PE
> or P to have any multicast related magic at all (unicast route leaking
> is acceptable)
> I may have rfc6037 or NG-MVPN/BGP, or mLDP in PE/P, it is not relevant,
> lets just assume core multicast works. PE/P could be JNPR or CSCO.

That's a decent guide that I referred to when designing our IPTV environment. With Cisco Multicast in MPLS (currently anyway, or at least on my ancient 6500s) you can accomplish the same thing without having to run MPLS, since it doesn't use it at all. The important part is understanding the MDTs, which are just multicast GRE tunnels.

> I would prefer to send only one copy over CE<->PE, but copy per VRF
> might be acceptable.

In our environment we ended up going with one copy per VRF. This is the difference between Option 1 and Option 2 on that page you linked.

Since our multicast is for IPTV, it came down to how quickly the MDTs and actual groups were joined. We found that the Option 2 approach presented subscribers with a very long time to "tune" into groups. Channel surfing was mostly black screens ;-)
 
> How I've previously done this, with one receiver VRF and one sender VRF
> was with loop cable in CE, with different VRF in each end.
> I then added default mroute in receiver VRF to the loop. And in the
> sender VRF I added mroute for the receiver LAN to the loop.
> I also added unicast RP/32 in the receiver VRF to the loop. And
> RP_Source/32 in the sender VRF to the loop.

That's certainly an exciting approach... heh

Our network has multiple source VRFs, but we needed to redistribute them to multiple receiver VRFs. Basic idea is that Set Top Boxes and Middleware live off on their own land, but content comes into our network at different points.

Our first setup was like this, with different RDs:

Video source -> Source VRF 1234:1 on PE1 -> ((MDT across core)) -> Receiver VRF 1234:1 on PE2 -> Import to 1234:2 on PE2 -> STB Video receiver
Video source -> Source VRF 1234:1 on PE1 -> ((MDT across core)) -> Receiver VRF 1234:1 on PE3 -> Import to 1234:3 on PE3 -> Middleware Video receiver

The PIM messages all flowed across the MDT and video from the source was only hitting our network once. However there was a lot of latency if someone wasn't watching a channel that came from whatever video source is attached to 1234:1

We went to this:

Video source -> Source VRF 1234:1 on PE1 -> Import to "receiver" VRF 1234:2 -> ((MDT across core)) -> Receiver VRF 1234:2 on PE2 -> STB Video receiver
Video source -> Source VRF 1234:1 on PE1 -> Import to "receiver" VRF 1234:3 -> ((MDT across core)) -> Receiver VRF 1234:3 on PE3 -> Middleware Video receiver

No MPLS required, just the BGP IPv4 MDT SAFI. Could run the same thing on CE devices I suppose

What are you running for CEs?

 - Ross