Subject: [rbridge] Must/Should flooding optimization

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 27 Mar 2006 16:09:22 -0500

Dino,

	One more time (hopefully)... 

.. [SNIP] ..
--> >> 
--> >> A) Alternatively, are you arguing that VLAN filtering MUST occur
--> >>    on all RBridge interfaces in order to prevent mis-delivering
--> >>    VLAN-scoped multicast, or did I misunderstand your comments?
--> 
-->     First off, I never brought up VLAN pruning, you did. I 
-->     was focusing the discussion on multicast forwarding. So 
-->     if there is [no] IGMP report received for a group on an 
-->     egress rBridge interface, forwarding to that group does 
-->     not happen on that interface, period.
--> 
-->     So associating "VLAN pruning" with "multicast pruning" 
-->     brings no value to the discussion IMO. 
--> 

In an earlier exchange, I asked:
===============================

   As a clarification question, I am not sure whether this relates
   to VLAN support or multicast support.  Can you please clarify 
   the following points?

And you replied:
===============

   Multicast support which is scoped within a VLAN.

_________________________________________________________________

My understanding was that you wanted to make sure that we would
NOT (and could NOT) end up delivering a multicast frame to one 
VLAN because it was needed for another - unrelated - VLAN, unless
it is needed for both.

I completely agree that it is a very bad thing to confuse VLANs 
and MAC multicast delivery.  I could - for instance - have a
VLAN that is intended specifically to carry multicast traffic,
and I certainly do not want to push that traffic onto another 
(or all other) VLAN(s).

Separating this from VLANs, however, the assertion that an RBridge 
campus necessarily will NOT forward multicast on an egress interface 
unless there has been an IGMP report for that interface is not how 
802.1D bridging works now, and I cannot see in the WG charter where 
we have signed up to "fix" that (at least necessarily) in RBridges.

An RBridge campus is part of a single Ethernet LAN and should appear 
as such to routers (and other devices) on that LAN.  That means that 
routers (et al) expect to be exposed to all broadcast and multicast 
traffic within at least that one LAN.

For one thing, some routers may expect multicast messages - either
for the routing protocols themselves - or for related extensions to 
be propagated across the LAN without interference.  Likewise, some
devices may use multicast addresses for other reasons to communicate
among themselves within a single LAN.  That being the case, then we 
might find that we MUST qualify your statement above (minimally) with 
"except for configured (and potentially well known) MAC multicast 
destinations".

The well known case is something that can be reasonably abstracted
- except there will be new "well known" MAC multicast addresses at 
some point in the future that will also have to be included.  The
"configured" case is something we can work with - except that, in an
effort to minimize configuration, we should probably assume the 
default is to forward all MAC multicast traffic _except_ for those
configured addresses we want to treat differently.

I think there is a point of confusion here in that RBridges are not
intended to be routers, they are intended to be bridges that use a 
routing protocol to determine forwarding paths - instead of one of
a few variations of STP.  One of the goals in the charter is that we
do not break what works in an existing bridging environment.  Hence
we have to be careful - generally - in what we optimize and doubly
careful is what we require to be optimized.

.. [SNIP] ..

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