Subject: [rbridge] Must/Should flooding optimization

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 21 Mar 2006 18:28:07 -0500

Radia, et al,

	Some clarifications...

	Just to be clear, "flooding optimization" as identified 
in the architecture applies only to flooding of frames with an
unkown MAC DA.

	VLAN Optimization as we have discussed on the list before
is the difference between:

(Optimized) forwarding multicast, broadcast or flooded traffic 
to only those downstream next-hop RBridges that are on the short
path toward an egress (DR) RBridge known to be part of a given 
VLAN.

(Unoptimized) forwarding all multicast, broadcast or flooded 
traffic to all downstream next-hop RBridges that are on the short
path toward an egress (DR) RBridge.

In both cases, an egress (DR) RBridge MUST filter all such frames 
and forward them only on the interfaces that are known to be part 
of the applicable VLAN.  Just to reiterate, this would be the case
even if all RBridges implement the VLAN Optimization.

	Multicast Optimization is the additional step of limiting 
frame forwarding to those downstream next-hop RBridges on the
shortest path toward egress (DR) RBridges known to be interested 
in frames addressed to a specific multicast MAC DA (this applies
only to Multicast frames).  This is an additional step because 
it makes sense to apply this optimization in addition to the VLAN
Optimization.

	Flooding Optimization - at least in the architecture is the
completely optional possibility of peeking at the inner MAC DA to
determine if it is _known_ locally (within a VLAN context, if that
applies).

	Also, see additional clarifications below...

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Tuesday, March 21, 2006 3:35 PM
--> To: Developing a hybrid router/bridge.
--> Subject: [rbridge] Must/Should flooding optimization
--> 
--> 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:
-->

This includes broadcast frames as well as multicast and unknown MAC
DA frames.

Also this is in reference to path pruning, generally, in RBridges.

--> 
--> 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)

Frames should also not be forwarded toward egress RBridges that are 
not DR for a shared media on which these frames might be forwarded.
One could argue that an RBridge that is not the DR for any shared
media is not an egress RBridge.

--> 
--> 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. 

I pointed out that it is an optimization and that things will still
work - if potentially sub-optimally - if not all RBridges implement 
it.

-->
--> 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.

There was more to the discussion than this.  Bandwidth is wasted in
an RBridge deployment where VLAN support or Multicast traffic is a
major consideration.

Given that one goal (perhaps the most important goal) of the TRILL
working group is minimal-to-zero configuration, and VLAN support - 
in particular - requires at least some degree of configuration, I
wonder if we are not working too hard at achieving opposing goals.

If we are trying to define a technology that does not require 
configuration to work in some subset of all possible deployment
scenarios, then I imagine we can assume that subset would not
involve VLANs.

I believe the usual way to deal with these concerns is through an 
Applicability RFC.

--> 
--> 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

Making efficient use of bandwidth is one of the goals of the work
we are trying to do - as well as being a reason to deploy RBridges.  
Therefore, while VLAN and Multicast support may be non-issues in a
given RBridge deployment, it is unlikely that there will be sections
of an RBridge deployment where "filtering won't matter for bandwidth."

--> 
--> c) even if a vendor were planning on eventually doing all 
--> features, this would make phased implementation possible.

There was also the point that Bill Fenner made about opportunities 
for product differentiation stemming from this.

--> 
--> Others argued that flooding optimization should be a MUST 
--> because:
--> 
--> a) the spec is more complicated if things are options

No question about it.  For example, in the protocol specification,
you would have to say 

"If the XYZ optimization is implemented, the following section(s) 
specify how it MUST be done" 

as opposed to a much simpler introductory statement that says 

"The XYZ optimization is specified in the following section(s)."

I don't believe complexity - beyond this - is involved, because
we are not talking about configurable options.

--> 
--> b) "your cheapo nonfiltering RBridge is putting more stress on 
--> my good-guy RBridge downstream"

Assuming that a new "cheapo nonfiltering RBridge" is used to either
augment or replace existing bridges (note, not _RBridges_), impact
we can expect from this is not worse than if a "cheapo nonfiltering
bridge" was inserted instead of a "cheapo nonfiltering RBridge."

However, there is still a gain from the fact that this new RBridge
would use shortest path routing as opposed to spanning tree.

--> 
--> c) it's more options for customers to understand in the 
--> purchasing decision

Possibly I expect customers can be smarter.  For example, I
am pretty sure we can count on the "good-guy RBridge" vendor
to educate customers.  :-)

Also, this is another reason to provide an Applicability RFC.

--> 
--> Anyway, what do people think?
--> 
--> Should VLAN filtering be a MUST?
--> 
--> Should IP-multicast filtering be a MUST?

I am happy to accept any "informed" decision the working group
comes up with.

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

--
Eric