[rbridge] it's time to summarize things
gibanez at it.uc3m.es
Fri Dec 16 03:21:29 PST 2005
Just to elaborate on the ambiguity of saying
"MUST work for LANs of a size
at least as great as can be accomplished using 802.1 bridges."
Using Multiple Spanning Tree Protocol (802.1Q) with a lot of MSTP
regions, very big networks can be built, although quite complex to
configure and manage.
Using RSTP with point to point links, my understanding is that it seems
there is no real limit to network size, although % of network
utilization will be very low and root bridge will become congested. If
there are shared links in the network, (situation like STP) then the
port state transitions to forwarding are governed by timers, with max
values of 30 seconds. Network size is then limited, as in STP.
Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Agreed.... with the caveat below
>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."
>>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...
>FWIW, this is basically what the current PAS states, though some have
>raised it as a possible concern.
>>--- [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
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>-----END PGP SIGNATURE-----
>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