All things related to multicast

[Bill Nickless <>]

At 03:57 PM 6/12/2001 -0700, Toerless Eckert wrote:
> On Tue, Jun 12, 2001 at 05:32:43PM -0500, Bill Nickless wrote:
> > (*,*,*) switching is what you get when you turn on IGMP snooping on that
> > same exchange point because IGMP snooping detects only the
> > multicast-capable routers.  (Alternatively, you use a separate VLAN for
> > multicast.)  Now the unicast-only participants don't get the multicast 
> traffic.
>
> Hmm.. Ok, but that's a small difference. Wouldn't you like to use a
> VLAN for all participants that do multicast anyhow ? If all routers
> on aq VLAN do multicast, you have effectively a shared media - that's what
> i was referring to...

Yes, it's plainly obvious to those who understand the issues.  But it does 
take additional configuration work to separate the unicast and multicast 
routing, and because of the need to educate potential participants I think 
it's a good idea to explain the difference.  In other words, I make the 
distinction for (almost) purely pedagogical reasons.

> > I don't think the two reasons (dup elimination, upstream (s,g) choice) are
> > orthogonal.  You get the duplicates WHEN some participant chooses the
> > "wrong" peer to send the PIM-SM join--that is, they pick a different RPF
> > for an (S,G).
>
> Well, but that's just a few packets, PIM assert will take care of this.
> YOu may get these kind of few duplicates in other places along the path
> also, i don't think this is an interesting differentiator.

In the context of an exchange point, I'm not sure I can get all the 
potential upstreams to agree on metric preference and metric values.  Why 
should they--isn't that what BGP is for?  Thus, we end up with actual 
upstream choices made by yet another mechanism (RPF Assert 
arbitration).  This mechanism may result in choices that are far from 
optimal, or even violate various policies.

In other words, I want the exchange point forwarding topology to be 
controlled by BGP, not by the underlying PIM protocol.  You may have a 
different perspective.  :)

> > You want to support the ability of participants to choose
> > their RPF neighbor for reasons that include the avoidance of duplicates.
>
> I would immediately say no, this is not an argument, but maybe you're
> using the term duplicate different from i do: I say duplicates to
> indicate that there really is something happening that will result
> in the actual group receiver (somewhere down the path) to receive
> duplicate packets. I think you are more referring to it to notify the
> case where a downstream peer on a MIX get's excess traffic which may or
> may not be actual duplicates. In any case, in case of a single VLAN
> you get very few duplicates because of PIM-asserts. YOU will get a
> lot more excess traffic if you only have (*,G) based traffic constrainment
> within the VLAN.

Yes, as a participant I *do* want to be able to choose my upstream.   In 
fact, as an upstream participant I might want to constrain (through my 
decisions on what prefixes to advertise) who is eligible to get me to start 
forwarding packets into the exchange point.

> > Thinking about it more carefully, your solution isn't quite fully 
> (S,G,RPF)
> > even with RGMP and current PIM-SM snooping.  Consider two sources S1 and
> > S2, and three participants A, B, and C.  A might want to get (S1,G) 
> from B,
> > but (S2,G) from C.  The exchange point would be forwarding (*,G) from both
> > B and C, which means A could still get duplicates--(S2,G) from B or (S1,G)
> > from A.
>
> C would RPF (S1,G) to the VLAN owned by B and would drop (S,1G) packets
> if arriving on the VLAN owned by A.  You are right that if the VLAN switch
> does not support per-(S,G) traffic restriction, that C would then actually
> receive the duplicates, but it wouldn't accept them... But that is
> another proof that the VLAN concept is orthogonal - just add a (S,G)
> snooping switch and you have the optimum restriction of traffic on the
> links to the routers. -> The VLAN solution itself is only meant to
> provide downstream routers to make their RPF selection based on their
> own policy and not based on PIM asserts !

Ah yes, good point.  Using an (S,G) snooping switch would indeed let this 
work properly.  I forgot about that potential case, only thinking it of 
(*,G) snooping switches or those using RGMP.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7