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 16:48:47 -0700

rbridge-bounces at postel.org wrote:
> 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
> 

Understood.

But wouldn't that require that the RBridge not only understand
what conclusions it reached about where a given layer 3 multicast
needed to reach, but keep all of the information so that if an
IP address migrated it could recalculate?

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 02 May 2006 18:20:39 -0700

>IP address migrated it could recalculate?
Absolutely. Just like it has to keep track of unicast destinations (in 
the current design).

Actually, there was some discussion of the issue with unicast. An 
alternative design would
have the Designated RB learn the source address from received 
unencapsulated data packets,
and not have RBridges in the core learn any of the endnode addresses. 
This would eliminate
the necessity of including this information in link state information. 
The downside is that
it means more packets would get flooded. Also, for ports in which 
RBridges can immediately
tell if an endnode is disconnected, the link state advertisement 
mechanism would be more
responsive.

It wouldn't be that big a modification of the design to take this 
philosophy rather than "advertise everything
in link state information", but we do need to pick one way and not keep 
oscillating. I don't think it's
a big deal. I think I tried to have a thread about this awhile ago and 
there wasn't much discussion, perhaps
because I wasn't clear about the issue. I *think* you are talking about 
the analogous thing with multicast.

Radia