On Fri, 17 May 2002 17:25:10 -0700 Toerless Eckert <[EMAIL PROTECTED]> 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.
