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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 7 Nov 2006 15:33:13 -0500

At what point does the proposal become complex enough to be recognized 
as sub-optimal, even in the supposed "common case" envisioned by those 
arguing that the only solution that is important is one that applies to 
large - high-end - networks? 

What is fundamentally wrong with using a single SHIM format?

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Sanjay 
--> Sane (sanjays)
--> Sent: Tuesday, November 07, 2006 3:19 PM
--> To: Radia Perlman; Silvano Gai
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> Radia,
--> 
--> In today's presentation, the last suggested format was the following
--> 
--> 48 bits - egress rbridge id
--> 48 bits - ingress rbridge id
--> 16 bits - pt = TRILL
--> 16 bits - reserved + flag + TTL - the link local nicknames (who's
--> supposed to be the next-hop is in here) 
--> ....
--> 
--> 
--> when this goes over a shared media, there were learning issues as
--> pointed out during the meeting. Pls refer to this diagram 
--> to understand
--> the problem
--> 
--> 1. if packets from r1 to r5 are sent once via r2, and other 
--> times, via
--> r3, the classical bridge b will learn r1 as behind link 1 
--> or 2. So, this
--> is the learning problem. 
--> 2. thus, for return traffic frm r5 to r1, even though r4 
--> wants r2 to be
--> the next-hop for this packet, if we keep the destination 
--> rbridge id as
--> r1, the classical bridge would forward the packet to link 1, thereby
--> blackholing this traffic. 
--> 
--> So, there are multiple issues - learning issues and blakholing. 
--> 
--> Potential solution:
--> 
--> r2, r3 and r4 exchange the link-local nicknames, say link 
--> local nickname
--> for r2 = 1, r3 = 2, r4 = 3.
--> 
--> Now, instead of using the complete 48 bit rbridge ID as the 
--> rbridge MAC
--> address, we can fill the 48 bits as follows:
--> 
--> 16 bit - rbridge nickname
--> 4 bits - link local nickname
--> 
--> 2 bits - I/G and U/L
--> 26 bits - reserved. 
--> 
--> Thus, on this classical ethernet/bridging cloud, rbridge emits the
--> packet with the appropriate link-local nicknames.
--> 
--> For e.g. 
--> - packets from r1 to r5, sent via r2, are sent with
--> SA = r1.<link source's link-local-nickname> = r1.1, , notice
--> link-local-nickname of r2 is chosen. 
--> If r2 intends r4 to be the next-hop, he'll put 
--> DA = r5.<link destination's link-local-nickname> = r5.3, notice
--> link-local-nickname of r4 is chosen. 
--> Thus, classical bridge will learn r1.1 on the link 1. 
--> 
--> - packets from r1 to r5, sent via r3, are sent with
--> SA = r1.<link source's link-local-nickname> = r1.2, , notice
--> link-local-nickname of r3 is chosen. 
--> If r3 intends r4 to be the next-hop, he'll put 
--> DA = r5.<link destination's link-local-nickname> = r5.3, notice
--> link-local-nickname of r4 is chosen. 
--> Thus, classical bridge will learn r1.2 on the link 1. 
--> 
--> -- thus no learning issues. 
--> 
--> - return traffic from r5 to r1, sent via r4. If r4 intends 
--> r2 to be the
--> next hop, it'll put
--> 
-->  
--> 
--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On
--> Behalf Of Radia Perlman
--> Sent: Tuesday, November 07, 2006 10:23 AM
--> To: Silvano Gai
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> Looking at Silvano's proposed shim header---the only reason 
--> we need the
--> outer header is to distinguish between RBridge neighbors, 
--> in the case of
--> unicast, specifying next hop, and in the case of multicast, 
--> specifying
--> transmitter.
--> 
--> His format has two bytes after the Ethernet header portion 
--> of the shim
--> for TTL, and a bunch of reserved bits.
--> 
--> That leaves 10 bits. We can dynamically (through the IS-IS 
--> Hello) give
--> out, say, 4 bit link-local nicknames, and stick them there.
--> 
--> Then the only time we'd need an outer header is if there 
--> are more than,
--> say, 16 RBridges on the same link.
--> 
--> Radia
--> 
--> Silvano Gai wrote:
--> 
--> >I am not looking at TRILL for increased scalability, but 
--> for spanning 
--> >tree replacement to get high bisectional bandwidth.
--> >
--> >-- Silvano
--> >
--> >  
--> >
--> >>-----Original Message-----
--> >>From: Gray, Eric [mailto:Eric.Gray at marconi.com]
--> >>Sent: Monday, November 06, 2006 10:38 AM
--> >>To: Silvano Gai; Eastlake III Donald-LDE008; rbridge at postel.org
--> >>Subject: RE: [rbridge] Should we optimize the common case?
--> >>
--> >>Silvano,
--> >>
--> >>	The assertion that only fortune 500 companies are interested in
--> TRILL 
--> >>is baseless and untrue.  One reason why you may believe 
--> this is the 
--> >>case, is that you are making certain assumptions about 
--> complexity and 
--> >>scale of the desired solution that are equally unfounded or false.
--> >>
--> >>	There is nothing that particularly prohibits definition of some
--> form 
--> >>of RBridge functionality that might be simple enough to deploy in 
--> >>relatively small networks - where higher speed link are 
--> becoming more 
--> >>common and wasting high speed links is also a problem.
--> >>
--> >>	The types of networks you're talking about cannot realistically 
--> >>operate with plug & play devices, and greater scalability is
--> >>    
--> >>
--> >paramount.
--> >  
--> >
--> >>The work we're doing in this WG is aimed at simplistic, 
--> plug & play 
--> >>deployment where increased scalability is a secondary 
--> consideration.
--> >>
--> >>--
--> >>Eric
--> >>
--> >>--> -----Original Message-----
--> >>--> From: rbridge-bounces at postel.org
--> >>--> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
--> >>--> Sent: Monday, November 06, 2006 1:51 AM
--> >>--> To: Eastlake III Donald-LDE008; rbridge at postel.org
--> >>--> Subject: Re: [rbridge] Should we optimize the common case?
--> >>-->
--> >>-->
--> >>--> 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
--> >>-->
--> >>--> _______________________________________________
--> >>--> 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
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->