[rbridge] it's time to summarize things

[Gray, Eric]

Spencer,

	In the WG charter, it stipulates the following as
design goals:

- Minimal or no configuration required
- Load-splitting among multiple paths
- Routing loop mitigation (possibly through a TTL field)
- Support of multiple points of attachment
- Support for broadcast and multicast
- No significant service delay after attachment
- No less secure than existing bridged solutions

Note that this list does not include "Support for a larger broadcast
domain."

However, if we can make layer 2 networking more efficient - thereby
overcoming some of the issues that limit current workable maximum
LAN size - we will most likely see LAN sizes increase again until
they are approaching a new maximum size.

This is less a goal, then a probable outcome.  It is hard to state
"LAN sizes will increase until they work about as poorly as they do
now" as a goal - at least while keeping a straight face.  

While I think we can all agree - at least in principle - that it is
probably not desirable to deliberately put cruft into the protocol
to prevent this from happening, I don't think we can get rock solid
consensus as to how much larger we might want to target.  I think
the given goals are aggressive enough.

So, I would argue for this position: we won't deliberately restrict
LAN size scalability unless we run into issues that require it and
we won't specify anything more than "MUST work for LANs of a size
at least as great as can be accomplished using 802.1 bridges."

I believe this is consistent with what we've all been saying, but I
am open to the possibility that I may have misunderstood someone,
somewhere along the line...

--
Eric

--- [SNIP] ---

--> 
--> >> --> if not, then can there be broadcast storms?
--> >>
--> >> Certainly not worse than currently, except to the extent that
--> >> an RBridge campus enhanced broadcast domain _might_ be larger.
--> 
--> Eric - is this just saying that someone may want to try for 100,000 MAC 
--> addresses in one RBRIDGE campus? Or did you mean more than this?
--> 
--> >> --> if not, then will broadcast be supported?
--> >> -->
--> >>
--- [SNIP] ---