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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 3 May 2006 09:57:42 -0400

Radia,

	We need to be careful not to conflate advertising of MAC
multicast addresses in support of IP multicast and advertising 
of the IP(v4/v6) multicast addresses, themselves.

	Mechanisms for determining associations of IP multicast
addresses and MAC multicast addresses are out of scope for the
RBridge protocol specification, as are mechanisms for announcing
L3 multicast reachability.  We can (and maybe should) talk about
these things, but we are not defining them and we should avoid
potentially cross-defining them in potential conflict with the
way they are - or will be - defined elsewhere.

	RBridges are layer two devices.  Mixing up the terminology
is bound to create confusion just as mixing up technologies is
bound to create complexity.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Tuesday, May 02, 2006 7:23 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Should layer 2 or layer 3 IP 
--> Multicast addresses be advertised?
--> 
--> 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-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.
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >rbridge at postel.org
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->