[rbridge] it's time to summarize things

[Gray, Eric]

Guillermo,

	See below...

--
Eric 

--- [SNIP] ---
--> >
--> >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 the solutions.
--> 

The point is that scalability and (larger) LAN sizes is _not_ an objective.
Clearly any attempt to specify precise values for size/scalability is also
an attempt to make these into objectives.

The real objective is that the service provided by RBridges - in general -
should not be worse than that available from bridges - and that is what a
statement like the one I suggested makes sense.  However, we have to keep 
our eyes on the ball.  It may turn out that realistic applications for
RBridges are typically small numbers of high capacity devices in a dense
campus configuration where efficient use of _expensive_ interfaces and
infrastructure is a more compelling objective than scalability of campus
size.

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

In my opinion, that could very well be true, but it would require a explicit
modification of the WG charter.
 
--> 
--- [SNIP] ---