Subject: [rbridge] Must/Should flooding optimization

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 23 Mar 2006 12:42:36 -0500

Folks,

	When this first came out, I was inclined to let it go.
Since what I said is now being consistently misrepresented,
I think I need to clarify my position on this.

>> Eric Gray pointed out that doing this pruning is only an optimization.

There is nothing quite like having your position summarized
for you by someone who appears to disagree with you.  :-)

My position can be neatly and accurately summarized as follows:

"There are circumstances in which these optimizations can be
 safely omitted, therefore the term 'SHOULD' - as defined in 
 RFC 2119 - applies."

My justification follows (for those interested in the details).
=================================================================
Several people recognize VLAN and Multicast pruning as 
optimizations.

The question is whether or not we want to require it in all
implementations.

My position is that - contrary to some arguments made - I 
feel that requiring this behavior actually complicates both 
the specification and the implementation processes.  Doing
so is something I think we should undertake only if we have
to do so in order to produce useful, interoperable, specs.

However there are two aspects to consider here: requiring 
RBridge behaviors that _allow_ optimization support, and
requiring RBridges to implement those optimizations.

Everybody that I know of is in agreement that RBridges 
MUST not preclude support for implementations that will
include these optimizations.  This applies - for example
- to Radia's earlier observations about the need for all
RBridges to ensure VLAN and multicast group membership
information is appropriately propagated within an RBridge
campus.  Implementations that include these optimizations
need this information in order to work correctly.

What is in question is whether all RBridges MUST include
the optimizations - specifically for interoperability.

IMO, these optimizations are not necessarily supported in
802.1D bridges, and these bridges work.  Consequently, we
need to find specific cases where RBridges introduce some
behaviors that break the corresponding features in 802.1D 
bridges.

We have evaluated very many scenarios and each potential
RBridge capability as yet discussed and - as several of
the people at the meeting said (including Radia) - they
still work.  Yes, they work sub-optimally in scenarios
were VLAN/Multicast support is important, but they are 
no worse in those scenarios than a similar deployment of
802.1D bridges would be.

The meaning of "SHOULD" - as defined in RFC 2119 - is as
follows:

'This word, or the adjective "RECOMMENDED", mean that there
 may exist valid reasons in particular circumstances to ignore a
 particular item, but the full implications must be understood and
 carefully weighed before choosing a different course.'

Since - so far - it has been demonstrated that there are "valid
reasons in particular circumstances" which justify not including
these optimizations, this term fits.

--
Eric