Subject: [rbridge] Should we optimize the common case?

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 1 Nov 2006 18:06:35 -0800

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

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 6 Nov 2006 01:19:46 -0500

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.

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?

Summarizing:

Comments?

-- Silvano

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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 06 Nov 2006 10:13:48 -0800

Yes, if there are two RBridges that can figure out they have a point to 
point link between them, it seems
like it would be good to drop the outer header, since there's really no 
information there.

Is there a way to automatically know this is definitely a pt-to-pt 
Ethernet link and not a shared link?

Radia