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. On Fri, May 17, 2002 at 06:00:41PM -0400, Stephen Griffin wrote:
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.
On Fri, 17 May 2002 17:25:10 -0700 Toerless Eckert <eckert@cisco.com> wrote:
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
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.
On Fri, May 17, 2002 at 06:00:41PM -0400, Stephen Griffin wrote:
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.
participants (3)
-
Marshall Eubanks -
Stephen Griffin -
Toerless Eckert