Subject: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Tue, 2 May 2006 15:24:42 -0700

rbridge-bounces at postel.org wrote:
> Radia,
> 
> 	I would lean toward (b).
> 
> 	In part, that is because we don't (to my knowledge)
> have a working group consensus to necessarily include "IP multicast"
> (as opposed to MAC multicast) awareness in RBridges.  I think
> we need to have that consensus before we talk about including
> any kind of IPv4/v6 addresses in RBridge advertisements.
> 
> 	We may need to have consensus on other things before we
> do that as well - like how appropriate it is to use RBridge
> protocols as a substitute for multicast routing protocols.
> 
It would also be inconsistent. The Multicast routing protocols
are responsible for determining which subnets a multicast
datagram needs to reach. The RBridge multicast support should
take over after than point (and deal with MAC multicast only).

> 	But my leaning is also because we can be more
> consistent in storing MAC layer reachability if we are being
> consistent and only advertising MAC layer reachability in
> RBridge protocol.
> 

I agree.

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 02 May 2006 16:23:12 -0700

The purpose of the RBridge snooping on IGMP, and in general, watching 
the IP multicast is
not to replace IP multicast, but to optimize delivery of IP data 
multicast within a campus. If
there was a very high volume multicast application that was only being 
received by one listener,
RBridges can ensure that packets for that application only get delivered 
to the one link on which
there is a listener.

If we decided RBridges should ignore the issue entirely, and treat IP 
multicast like any layer 2 multicast,
then all IP multicast packets would be flooded, through the 
ingress-RBridge tree on which they were injected,
to all links in the campus. This would be correct behavior, in that 
multicast packets would get delivered,
but it would not be optimal behavior, since there would be unnecessary 
traffic on lots of links.

So this is similar to IGMP snooping switches, although it works 
differently for RBridges than it does
with pure switches, since RBridges explicitly say the information (where 
IP listeners are for each IP multicast
group, where IP multicast routers are) in link state information, and 
the information doesn't have to change
if interior links in the campus go up or down (as they would with IGMP 
snooping switches, that are
inferring things based on the direction from which they see IGMP 
notification messages and such).

Radia

Caitlin Bestler wrote:

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>