Multicast at broadcast exchanges

Marshall Eubanks tme at multicasttech.com
Sat May 18 17:35:35 UTC 2002


On Fri, 17 May 2002 17:25:10 -0700
 Toerless Eckert <eckert at 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.




More information about the NANOG mailing list