[rbridge] it's time to summarize things

[Guillermo Ibáñez]

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.

Guillermo

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Agreed.... with the caveat below
>
>Gray, Eric wrote:
>  
>
>>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...
>>    
>>
>
>FWIW, this is basically what the current PAS states, though some have
>raised it as a possible concern.
>
>Joe
>
>  
>
>>--
>>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] --- 
>>_______________________________________________
>>rbridge mailing list
>>rbridge at postel.org
>>http://www.postel.org/mailman/listinfo/rbridge
>>    
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDofPWE5f5cImnZrsRAqWgAKCLZu4u/kG6rHRd47aXTAPeA9sjHACdF5MN
>r4wQKmB85gf/RGEG7ElV9gg=
>=vcJf
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

-- 
Guillermo Ibáñez
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