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

From: sanjays at cisco.com (Sanjay Sane (sanjays))
Date: Tue, 7 Nov 2006 12:24:31 -0800

Oops. Typed send before finishing. 

attached the diagram.
Completed the description. See inline

-Sanjay

-----Original Message-----
From: Sanjay Sane (sanjays) 
Sent: Tuesday, November 07, 2006 12: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
SA = r5.<link source's link-local-nickname> = r5.3, , notice
link-local-nickname of r4 is chosen. 
If r5 intends r2 to be the next-hop, he'll put 
DA = r1.<link destination's link-local-nickname> = r1.1, notice
link-local-nickname of r1 is chosen. 

-- thus no blackholing.

-Sanjay

-----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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trill.jpg
Type: image/jpeg
Size: 8719 bytes
Desc: trill.jpg
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061107/068d4584/trill-0001.jpg