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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 6 Nov 2006 14:11:52 -0500

Radia,

	I think I agree with this and would go further to make two
additional comments/observations:

	1) Unless it is possible to determine absolutely what cases
         exist where RBridges can know that the link between them
         actually is p2p (as opposed to looks like it is p2p), it
         is risky to leave this sort of behavior as an unspecified
         option.
	2) If we cannot explicitly list the conditions under which 
         all implementations MUST assume a NULL outer header, and
         we really believe it is important to have this, then we
         need to specify a negotiation mechanism whereby RBridges
         can signal the intention to leave out the outer header.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Monday, November 06, 2006 1:14 PM
--> To: Eastlake III Donald-LDE008
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> 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
--> 
--> Eastlake III Donald-LDE008 wrote:
--> 
--> >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?
--> >
--> >
--> >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
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Mon, 6 Nov 2006 14:44:15 -0500

>          is risky to leave this sort of behavior as an unspecified

Isn't it simple to test whether an RBridge A can send a packet to RBridge B
using the Shim header alone? Each of the RBridges can try sending a few test
packets without outer header; a received packet would trigger an ACK, again
without an outer header. If an RBridge gets an ACK (or ACKs to a few such
packets), then it can mark that neighbor as "directly connected". If there
are non-RBridge devise in between, then they will simply drop those
"unrecognizable" packets. The only issue would be making sure that such
"unrecognizable" packets do not trigger any undesirable behavior (e.g., they
do not resemble any non-RBridge control packets).