[rbridge] it's time to summarize things
gibanez at it.uc3m.es
Fri Dec 16 02:07:08 PST 2005
Gray, Eric wrote:
> 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."
This ("as great as using 802.1 bridges2) perhaps is not very precise....
The target of 100.000
hosts is clear, aggresive enough and allows scalability evaluation of
My opinion is that introducing additional functionality and complexity
like Rbridges in campuses
should provide some extra benefits, allowing larger network sizes. If
we keep current network
sizes as target, then the problem statement is just to replace so called
switching routers or multilayer switches
and the like with an hybrid device using MAC routing, withina a single
>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] ---
>rbridge mailing list
>rbridge at postel.org
Departamento de Ingeniería Telemática
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Leganés 91-6248794
More information about the rbridge