[rbridge] Max Network size

[Joe Touch]

Guillermo Ibáñez wrote:
> Hello Joe,
> 
> More on maximum network size.

As a prelude, YES - lots of engineering issues...

> -So we can expect, for a network with one hundred thousand hosts, rbridges
> with tables of that size. OK?
> (No problem so far).

Ingresses need to have enough information to encapsulate based on
destination host MAC address; that can be accomplished two ways:
	- full tables carried at each ingress
		which would be hard to compress, but might
		be hashable
	- internal bootstrap
		1) internal 'ARP' when a previously unknown
		MAC arrives at the ingress, resolving to a cached
		entry

		2) implied 'ARP' by broadcasting the packet
		with the successful egress back-propagating
		the entry later

I suspect a combination may be required, since there will be packets
whose MAC may not be knowable at the egress (silently attached), so we
may have to flood the network to even find the right egress to use. This
is no different from what bridges do, though...

> -Scalable routing between Rbridges: my understanding is that MAC addresses
> are used for routing between them. Although the number of bridges will no be
> too high (i.e thousands), I do not understand well the meaning of
> "scalability of routing" as the flat addresses used do not permit route
> aggregation. I did not follow the routing discussiong so may be I missed
> something.

Yes, we need a routing protocol that can scale. Note, however, that
we're forwarding internally ONLY on the destination rbridge address, NOT
the original packet's MAC address. So the number of entries is the
number of egresses, NOT the number of end hosts.

The tradeoff is in the encapsulation table size (first item above);
_that_ table is O(# attached hosts), whereas the routing is O(# egresses).

> Rbridge types
> - You mention "interior" Rbridges and "edge" Rbridges. Do you see any
> functional differentiation between these two types ?

Egress nodes need encapsulation tables and forwarding tables; interior
nodes just need forwarding tables and could be cheaper.

> In this case handled it
> could be handled by self configuration (upon detection of hosts an interior
> bridge becomes edge bridge). My understanding is that  there are no
> functional differentiation of Rbridges, but engineering differences to
> optimize between "core" Rbridges and "access" Rbridges. Right?  

A edge bridge can easily function as interior; an interior might not
function as an edge. This may favor a single integrated design. The
behavior is configured on a per-MAC basis (traffic coming from another
rbridge in your campus is internal; all other traffic is external). This
should be very easy to automate, IMO (do an echo algorithm to find all
connected rbridges, declare that one campus unless manually configured
not to, and use those MACs as internal traffic).

The distinction based on device is better for describing the system, but
in practice I would expect it would be per-MAC, not per-box.

I hope this all helps - I can add it to the doc.

Joe

> Regards
> Guillermo Ibañez
> 
> -----Mensaje original-----
> De: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] En nombre
> de Joe Touch
> Enviado el: domingo, 01 de mayo de 2005 5:27
> Para: Developing a hybrid router/bridge.
> Asunto: Re: [rbridge] Max Network size
> 
> 
> 
> 
> Guillermo Ibáñez wrote:
> 
>>I have a question:
>>   What is the maximum network size (number of hosts) 
>>required/expected
>>in TRILL? May be it was already stated somewhere, I am not aware of it.
>>Regards
>>Guillermo Ibáñez
> 
> 
> There is no limit of design; it is based on the capability of edge RBridges
> to handle encapsulation tables, as well as of interior RBridges to have
> scalable routing.
> 
> We expect to scale to numbers of hosts much higher than current bridges,
> but it's hard to predict what the knee of the design curve will be (IMO).
> 
> Joe
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050504/36e07882/signature.bin