Subject: [rbridge] Summary of layer 2 multicast stuff

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 8 May 2006 16:54:02 -0400

Erik,

	The only thing special about an edge RBridge is that it
has at least one interface onto a LAN segment where there is at
least one Ethernet end-station that is not an RBridge.  I think
(based on the last conversation I had on this topic) that - of
all edge RBridges - only those that win the Designated RBridge
election will ever advertise any kind of MAC reachability or
interest into the RBridge campus.

	That being the case, there are two things to realize: 

1) Any RBridge may be an edge RBridge.
2) The only way that a "non-edge" Rbridge would learn of a 
   multicast address of interest is via another RBridge.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark
--> Sent: Monday, May 08, 2006 4:29 PM
--> To: Radia Perlman
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Summary of layer 2 multicast stuff
--> 
--> Radia Perlman wrote:
--> 
--> > 4) IPv6 multicasts are more problematic, if it's really 
--> true that other 
--> > applications might use those
--> > l2 addresses. (how big a block of the locally derived 
--> addresses is IPv6 
--> > using? Why are they
--> > using locally derived addresses?) There are several 
--> options for how we 
--> > deal with this:
--> > a) don't optimize IPv6 multicast flooding
--> > b) ignore the possibility of other applications using 
--> those l2 multicast 
--> > addresses...those other applications
--> > should know that IPv6 are using those addresses, so even 
--> though it's not 
--> > "owned" by IETF, other
--> > applications should design around them, and if things are 
--> flaky for them 
--> > as a result (because RBridges
--> > will not deliver a frame addressed to one of those 
--> addresses unless 
--> > there is an IPv6 multicast router
--> > and/or an IGMP report received)
--> > c) do flooding optimization for the IPv6 block only if 
--> the Ethertype on 
--> > the inside packet indicates
--> > it is an IPv6 packet
--> 
--> This is an issue for IGMP/MLD snooping in general, hence 
--> there isn't 
--> anything specific to rbridges here. I don't know if there 
--> is any work on 
--> the IGMP/MLD snooping document going on in Magma. Perhaps 
--> Dino knows.
--> 
--> > 5) l2 multicasts that aren't IP...since there is no 
--> universally deployed 
--> > "wish to receive" for these
--> > multicast addresses, I see no choice for RBridges than to 
--> not attempt to 
--> > optimize for these
--> > addresses (i.e., send these everywhere). Conceivably in 
--> the future there 
--> > might be some application
--> > that gets deployed where all endnodes announce somehow, 
--> but given that 
--> > current RBridges can't
--> > be designed to recognize that future application, I don't 
--> see how we can 
--> > design to optimize those.
--> > My guess is that any high volume multicast applications 
--> will just do it 
--> > with IP rather than
--> > inventing their own mechanism.
--> 
--> Agree in principle.
--> 
--> But there is an architectural issue about the placement of 
--> the learning 
--> of multicast membership that I think we should discuss: Is this 
--> (IGMP/MLD snooping and potentially future different ways) something 
--> which only the edge rbridges do, and then they propagate 
--> what they've 
--> learned as some link-state advertisements to the other 
--> rbridges, *or* is 
--> it something that we expect all the rbridges to do?
--> 
--> (One can draw parallels between this multicast issue and 
--> the unicast 
--> issue of whether or not we limit learning of station MAC 
--> addresses to 
--> the edge rbridges.)
--> 
--> *If* the multicast learning is limited to the edge rbridge, 
--> it might be 
--> more feasible to introduce some new multicast learning approach.
--> 
-->     Erik
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Mon, 08 May 2006 14:24:50 -0700

> interest into the RBridge campus.

Agreed.

>    multicast address of interest is via another RBridge.

My point for #2 is that this learning can be done in two very different 
ways:
  - snoop the IGMP/MLD messages everywhere (and for the "non-edge" case 
those are encapsulated just like other packets)
  - only the edge snoops the IGMP/MLD messages and based on this 
learning advertises the multicast membership as some LSAs (or other 
explicit container)

    Erik