Subject: [rbridge] Must/Should flooding optimization

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Tue, 21 Mar 2006 15:37:08 -0800

rbridge-bounces at postel.org wrote:
> When a multicast or unknown destination packet is forwarded
> by RBridges, it is sent along the ingress RBridge rooted at
> the ingress RBridge. However, RBRidges along the way can
> prune the packet so that the packet only reaches links that
> have interested receivers. There are two pieces of pruning
> information: a) which egress RBridges are attached to which VLANs (so
> a 
> packet marked VLAN A need not be forwarded to RBridges that
> have no links attached to VLAN A)
> b) which egress RBridges have interested receivers for
> IP-derived multicast addresses (as learned through IGMP and multicast
> router discovery) 
> 
> Eric Gray pointed out that doing this pruning is only an optimization.
> Bandwidth would be wasted if some
> RBridge that was only in the "core" ignored IGMP and VLANs,
> and forwarded all non-unicasts (received on the expected
> ingress port for the specified ingress RBridge tree) to all
> potential outgoing ports in that ingress RBridge tree.
> 
> So, he argued that both forms of flooding optimization should
> be SHOULD, because
> a) a vendor can build a cheaper device if it doesn't have to
> bother filtering based on these things
> b) customers can buy the cheaper device it they'd like to
> save money, and don't care about saving bandwidth, especially
> because in their deployment they might not be using VLANs at
> all, and have very little multicast traffic, or there might
> be sections of their campus in which filtering won't matter
> for bandwidth
> c) even if a vendor were planning on eventually doing all
> features, this would make phased implementation possible.
> 
> Others argued that flooding optimization should be a MUST because:
> a) the spec is more complicated if things are options
> b) "your cheapo nonfiltering RBridge is putting more stress
> on my good-guy RBridge downstream"
> c) it's more options for customers to understand in the purchasing
> decision 
> 
> Anyway, what do people think?
> 

For a general purpose RBridge I would agree that it
should be a MUST. But I am concerned that other more
specialized devices may someday include RBridge functionality
within them. Such a device could concievably conclude that
the cost of certain ingress filters was simply not justified.
And in the larger context it would only be risking its own
internal bandwidth.

That's the sort of special deployment need that SHOULD
was designed for.