[rbridge] Should we optimize the common case?

[Silvano Gai]

Donald,

The high end and the low end are extremely different.

The customers interested in TRILL are the Fortune 500 companies. Large
Enterprise networks and large data centers used to run Financial,
Insurance, Health, Chemical, Oil, Information and manufacturing
companies.

They have huge demand for high bandwidth and low latency.

Each of these companies spends millions each year in network operation
(OPEX) and millions in new equipment (CAPEX). In all of them OPEX is
much larger than CAPEX. They only buy major vendor equipments and they
install them according to the recommended vendor design guideline.
Typically they have an internal certification lab in which they test the
network configuration and the software releases before putting them in
production networks.

They have a very well defined concept of backbone ports and access
ports. All the backbone ports are in fiber at the highest possible speed
(today 10 GE). For the access port they use a mix of fiber and copper.
The backbone has a regular structure that matches the vendor design
guideline and the result of the certification experiment they have done
independently.

A network outage can cost millions/hour. 

There is no way you will see in one of these backbones a hub or any
other uncontrolled device. NEVER. 

That is the reason why I think this is the most important case for
TRILL.

More inline.

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Sunday, November 05, 2006 10:20 PM
> To: rbridge at postel.org
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> Silvano,
> 
> Why do you think that 90% of Rbridge deployment will be for this
unusual
> case? I mean, I have no problem with the belief that Rbridges would be
> better than bridges in this case but why shouldn't that be true of
less
> high end uses?
> 
> A while ago on this list I posted a rhetorical question as to why
> Rbriges shouldn't eventually replace all bridges. No one posted an
> answer.

This technology will start in the high end and move down to the lower
end. How low will it goes is a good question. 

The low end is extremely cost sensitive. When we buys a switch or a
router on the Internet for 50-100$, the COGS cannot be more that 15-30$,
even with low margins. This implies that few dollar more to increase the
memory size or the processor speed are a big deal. Add software
development cost. Couple this with the fact that today we have low cost
1GE switches used by low-end users that have problems pushing or pulling
more than few Mb/s. There is no bandwidth demand in the low end.
Spanning tree is just fine. Cost is the big issue. Moreover there is the
huge issue of training home/small office installers in this new
technology.

My 0.2 cents

-- Silvano

> 
> Why not specify Rbridges more or less as we have been for the common
> bridge case and, in the backbone case you are talking about, just drop
> the MAC addresses on the point-to-point links within the backbone?
> Doesn't that produce less overhead than your proposal below in both
the
> point-to-point and shared media cases?
> 
> Donald
> 
> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Silvano Gai
> Sent: Wednesday, November 01, 2006 9:07 PM
> To: rbridge at postel.org
> Subject: [rbridge] Should we optimize the common case?
> 
> 
> With 16 bit addresses the current TRILL overhead over Ethernet is 20
> bytes. If we want to expand the RBridge addresses, it we will go to
> 22-24 bytes.
> 
> What customers are telling us is that they will deploy RBridges by
> creating an RBridge backbone in which all the links will be 10GE.
> 
> They will connect regular bridges and host to the periphery of this
> backbone.
> 
> They will not mix backbone ports with access ports, because this
screws
> up management, traffic engineering, debugging, and troubleshooting.
> Regular network design, easy to understand, is very important. Ports
are
> cheap, labor is expensive.
> 
> I am totally convinced that this will account for 90+ % of TRILL
> deployment.
> 
> I am wondering if it makes sense to have a solution highly optimized
for
> such an environment.
> 
> For example we can put the egress/ingress RBridge addresses in the
outer
> MAC addresses and define a TRILL shim header that contains 1 byte of
hop
> limit and 1 byte reserved. For this common case we will get:
> 1) overhead of 16 bytes (4 to 8 bytes lower)
> 2) nickname = MAC address, i.e no hash collision
> 3) zero-conf achieved
> 
> In the case we need to go over a shared media we will need to add
> another Ethernet encapsulation to carry the next hop address, i.e. 14
> bytes
> - total overhead will be 30 bytes
> 
> Summarizing:
> - current proposal 20-24 bytes overhead
> - new proposal on point to point: 16 bytes
> - new proposal on shared media: 30 bytes
> 
> Comments?
> 
> -- Silvano
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge