[rbridge] it's time to summarize things
Eric.Gray at marconi.com
Thu Dec 15 14:01:24 PST 2005
In the WG charter, it stipulates the following as
- 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
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...
--- [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] ---
More information about the rbridge