[c-nsp] redistribute routes leaked from another VRF?

[Jeff Bacon]

> > The multicast I want to keep in global - yes you can do
> > multicast VRFs, but I had a long chat with someone from
> > LAN Switching TAC in RTP a while back and one of my
> > takeaways was an emphatic "don't do this if you don't
> > have to".
> 
> Different from what you initially wanted to know, and a bit
> late in responding, but I'm curious why Multicast is
> recommended to run in the global routing table.
> 
> How do you handle situations where your customers (the
> Multicast source) are using the same Multicast group
> address(es)?

Well, first off, I don't have customers. So I can't answer that part. :)

It has more to do with how multicast MPLS is implemented - to
oversimplify (and someone correct me if I'm missing something), the
model is:
- you define a single mcast addr in global which carries all the mcast
for the VRF (it might be possible to map to multiple addrs to break it
out some based on what your subscrip pattern might be)
- various hooks are shoved in to transport and handle PIM and mroutes on
a per-VRF basis OOB
- mcast within the VRF is GRE-encap'ed then transported over the single
mcast addr to the dest

I'm sure it works, though I haven't tried it. But it means you have
mcast (in global) carrying GRE-encap mcast for the VRFs floating around
your net. I think you have to set up PIM in global to carry the
transport groups. Merely thinking about trying to manage/debug that
makes my head hurt. 

Plus, GRE encap with MPLS means a recirc through the EARL so you pay the
latency penalty twice plus the extra load. And you need jumbo frames to
encap at full standard 1500 MTU.

Hence, don't do it if you don't have a really good reason to. I don't,
so I don't.

-bacon