Multicast at broadcast exchanges

Hmm, I was thinking about the topic of multicast at broadcast exchanges, and
had a weird thought.

Presently, the various participants may have divergent peering relationships
and routing preferences. Such that RPF choices for the same (s,g) can
go back to different places.

If I remember correctly, all PIM routers on the same broadcast domain
will elect a designated router, to keep from sending the same traffic
for the same group multiple times.

If network A is preferring network B (via localpref, for example) and
network C is preferring network D, such that A rpf's to B for prefix E
and C rpf's to D for prefix E, how would this be resolved?

What if A doesn't peer with D at all, and C doesn't peer with B?

Wouldn't one of B and D send the traffic, such that the other isn't
sending any, regardless of the policies of any of the networks
involved?

What if the elected DR isn't one of B or D?

The only "workaround" I could see, would be if the multicast traffic
were unicasted across the exchange (much like how things are at the
atm peering points). However, this nulls out the benefit of having a
multicast broadcast exchange.

We had this discussion some time back on a different mailing list
(mboned ?.. not sure). I don't remember who was actually trying to
collect different options here, but in general, either all participants
at such a MIX agree who is the best upstream router for some multicast
traffic - then it's just the question how technically to guarantee the
route consistency - or they don't, and in this case you need to use one VLAN
per upstream participant, do appropriate filtering on them so really only
the VLANs owner can sent multicast into it and the downstreams can only
receive, and set up appropriate peerings.

Today, MIXes are all AFAIK all single VLAN for multicast which means that
there must be a coordinated BGP configuration policy between the upstream
participants to ensure that the way PIM asserts resolve does actually elect
the one upstream that is best. Of course, the policy that can be expressed
is limited by the fact that PIM asserts are used to resolve conflicts.

Cheers
  Toerless

P.S.: Oh, and of course one way to get a multi-policy setup very simply
without multiple VLANs is by not using ethernet but instead an ATM
with rfc2225/rfc2337 (eg: one classical-ip subnet with PIM Multipoint
signalling).

P.S.2: Oh and by the way: The DR function is completely irrelevant
in this discussion because it only applies to IGMP state driven forwarding,
and you shouldn't really use that on a router connecting to a MIX. If you
do, you're even more constrained in your options and probably need to
go to a multi-vlan setup immediately.

Hi Toerless;

We had this discussion some time back on a different mailing list
(mboned ?.. not sure). I don't remember who was actually trying to
collect different options here, but in general, either all participants

Bill Nickless

at such a MIX agree who is the best upstream router for some multicast
traffic - then it's just the question how technically to guarantee the
route consistency - or they don't, and in this case you need to use one VLAN
per upstream participant, do appropriate filtering on them so really only
the VLANs owner can sent multicast into it and the downstreams can only
receive, and set up appropriate peerings.

Today, MIXes are all AFAIK all single VLAN for multicast which means that
there must be a coordinated BGP configuration policy between the upstream
participants to ensure that the way PIM asserts resolve does actually elect
the one upstream that is best. Of course, the policy that can be expressed
is limited by the fact that PIM asserts are used to resolve conflicts.

Foundry has a limited PIM snooping ability on their switches. Does anyone know
of an operational PIM-Snooping based MIX ?

Regards
Marshall Eubanks