Subject: [rbridge] it's time to summarize things

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 15 Dec 2005 17:01:24 -0500

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] ---

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 15 Dec 2005 14:53:10 -0800

Agreed.... with the caveat below

> somewhere along the line...

FWIW, this is basically what the current PAS states, though some have
raised it as a possible concern.

Joe

> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 15 Dec 2005 17:45:28 -0600

Eric and Joe,

Ack.

And thanks for laying it out this way.

Spencer

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----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-----

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 16 Dec 2005 11:07:08 +0100

>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 
the solutions.
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 
IP subnet.  

-- 
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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 16 Dec 2005 12:21:29 +0100

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

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Mon, 19 Dec 2005 08:04:22 +0100

I think I stick to my original proposal:

the protocol MUST function effectively in deployments of:

 * 1000 end-hosts in a single bridged LAN of 100 bridges
 * 100.000 end-hosts inside 1000 VLANs served by 10.000 bridges

My reasoning is that if we find that a proposal is effective only at 
smaller sizes than this, we should reject the proposal outright, and not 
waste time on discussion.

Having size limits like "at least as great as can be accomplished..." can 
easily lead to us re-fighting the issue of "how big can the networks be 
using protocol X" when evaluation time comes around.

There's nothing magic about these numbers. But they're easy to measure.

--On 16. desember 2005 12:21 +0100 Guillermo Ib??ez <gibanez at it.uc3m.es> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/rbridge/attachments/20051219/b8fe1cfd/attachment.bin