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

From: Radia.Perlman at sun.com ([email-masked])
Date: Wed, 08 Nov 2006 00:02:19 -0800

This is an extremely cute proposal, and it works. Let me explain Sanjay's proposal in different words, in case
it doesn't sink in the first time one sees it.

He is proposing using the shim header that looks like an Ethernet header, with SA=ingress RBridge MAC R1
and DA=egress RBridge MAC R2, but solving the two problems
brought up at the meeting which were:

a) bridges on an intermedaite link might have previously incorrectly learned the location of R2, because packets
from R2 might have arrived at the link from different directions.

b) if we avoid problem a) by using different MAC addresses for "to" and "from" for each RBridge, so that
we avoid bridges ever learning the direction of the egress RBridge, the problem is that we don't benefit from
good bridge learning on the link.

And also, he is proposing making it possible to use that header on a link with more than 2 RBridges.

The way he's proposing doing it is using the 48 bit Destination and Source addresses in the Ethernet header
in an unconventional way.

Instead of putting the MAC address of the ingress and egress RBridges in those fields, he is suggesting the following:

a) assign 16-bit nicknames to all the RBridges (as we were going to do with the short shim header)
b) assign, say, 8 bit link-local nicknames to all the RBridges on a link (this can be done through the IS-IS Hello
protocol quite easily--I'd suggest doing it by having the Designated RBridge assign the values, but it could also
be done by having each RBridge choose a nickname and back off if someone with a better ID has chosen that
nickname)
c) in the Destination address field in the Ethernet header, put in both the 16-bit egress RBridge nickname, and
the nextop 8-bit nickname
d) in the Source address field in the Ethernet header, put in both the 16-bit ingress RBridge nickname, and
the transmitting RBridge on that link's 8-bit nickname

So---bridges will never incorrectly learn the location of any RBridges, because no matter where a packet from
R12 arrives into the link, the bottom bits will be specific to the RBridge on the link that injected the packet.

And positive learning can happen as well. Suppose there are n total RBridge nicknames in use in the whole
campus. Suppose there are 5 RBridges on the link. The bridges inside the link will see 5*n RBridge addresses
as a result of this proposal. In other words, if the RBridge nicknames are 1, 2, ... 517. and there are 5 RBridges
on the link, the MAC addresses the bridges will see are:
{1 - 517} | {1 - 5}

In Sanjay's picture, if R4 wants to direct a packet towards R2 rather than R3 for egress R1, it encodes R2's nickname
into the "neighbor's nickname" portion of the egress RBridge field.

Anyway---something for people to think about.

Radia

----- Original Message -----
From: "Sanjay Sane (sanjays)" <sanjays at cisco.com>
Date: Tuesday, November 7, 2006 12:24 pm
Subject: RE: [rbridge] Should we optimize the common case?

> 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 
> understandthe 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 
> nicknamefor 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 [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 [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
> >>--> [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
> >>--> [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
> >>--> [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
>

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 8 Nov 2006 04:27:54 -0500

This seems like an intriguing possibility. We would need to get an OUI
to go into the top 24 bits of these addresses. With an OUI we can then
easily allocate our own multicast addresses (all rbridges, etc.) so we
would end up needing one OUI and one Ethertype allocated but nothing
else. (You might think that with these magic addresses, you could
dispense with the TRILL Ethertype but, besides the fact that that would
be non-standard, you can't anyway because, for example, you may need to
insert a VLAN tag and/or other tags between the addresses and the shim.)

Thanks,
Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia.Perlman at sun.com
Sent: Wednesday, November 08, 2006 3:02 AM
To: Sanjay Sane (sanjays)
Cc: rbridge at postel.org
Subject: Re: [rbridge] Should we optimize the common case?

This is an extremely cute proposal, and it works. Let me explain
Sanjay's proposal in different words, in case it doesn't sink in the
first time one sees it.

He is proposing using the shim header that looks like an Ethernet
header, with SA=ingress RBridge MAC R1 and DA=egress RBridge MAC R2, but
solving the two problems brought up at the meeting which were:

a) bridges on an intermedaite link might have previously incorrectly
learned the location of R2, because packets from R2 might have arrived
at the link from different directions.

b) if we avoid problem a) by using different MAC addresses for "to" and
"from" for each RBridge, so that we avoid bridges ever learning the
direction of the egress RBridge, the problem is that we don't benefit
from good bridge learning on the link.

And also, he is proposing making it possible to use that header on a
link with more than 2 RBridges.

The way he's proposing doing it is using the 48 bit Destination and
Source addresses in the Ethernet header in an unconventional way.

Instead of putting the MAC address of the ingress and egress RBridges in
those fields, he is suggesting the following:

a) assign 16-bit nicknames to all the RBridges (as we were going to do
with the short shim header)
b) assign, say, 8 bit link-local nicknames to all the RBridges on a link
(this can be done through the IS-IS Hello protocol quite easily--I'd
suggest doing it by having the Designated RBridge assign the values, but
it could also be done by having each RBridge choose a nickname and back
off if someone with a better ID has chosen that
nickname)
c) in the Destination address field in the Ethernet header, put in both
the 16-bit egress RBridge nickname, and the nextop 8-bit nickname
d) in the Source address field in the Ethernet header, put in both the
16-bit ingress RBridge nickname, and the transmitting RBridge on that
link's 8-bit nickname

So---bridges will never incorrectly learn the location of any RBridges,
because no matter where a packet from
R12 arrives into the link, the bottom bits will be specific to the
RBridge on the link that injected the packet.

And positive learning can happen as well. Suppose there are n total
RBridge nicknames in use in the whole campus. Suppose there are 5
RBridges on the link. The bridges inside the link will see 5*n RBridge
addresses as a result of this proposal. In other words, if the RBridge
nicknames are 1, 2, ... 517. and there are 5 RBridges on the link, the
MAC addresses the bridges will see are:
{1 - 517} | {1 - 5}

In Sanjay's picture, if R4 wants to direct a packet towards R2 rather
than R3 for egress R1, it encodes R2's nickname into the "neighbor's
nickname" portion of the egress RBridge field.

Radia

----- Original Message -----
From: "Sanjay Sane (sanjays)" <sanjays at cisco.com>
Date: Tuesday, November 7, 2006 12:24 pm
Subject: RE: [rbridge] Should we optimize the common case?

> 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.
> 
> Now, instead of using the complete 48 bit rbridge ID as the rbridge 
> MAC address, we can fill the 48 bits as follows:
> 
> - 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.
> - 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.
> - 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
> 
> 
> 
> 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.
> 

> >>--> From: rbridge-bounces at postel.org [rbridge-bounces at postel.org] On

> >>--> Behalf Of Silvano Gai
> >>--> guideline and the result of the certification experiment they 
> >>--> have done independently.
> >>-->
> >>--> This technology will start in the high end and move down to the 
> >>--> lower end. How low will it goes is a good question.
> >>-->
> >>--> 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.
> >>--> there is the huge issue of training home/small office installers

> >>--> in this new technology.
> >>-->
> >>--> My 0.2 cents
> >>-->
> >>--> -- Silvano
> >>-->
> >>--> >

---

From: riw at cisco.com (Russ White)
Date: Fri, 10 Nov 2006 08:27:00 -0500

> b) assign, say, 8 bit link-local nicknames to all the RBridges on a
> link (this can be done through the IS-IS Hello protocol quite
> easily--I'd suggest doing it by having the Designated RBridge assign
> the values, but it could also be done by having each RBridge choose a
> nickname and back off if someone with a better ID has chosen that 
> nickname)

> c) in the Destination address field in the Ethernet header, put in
> both the 16-bit egress RBridge nickname, and the nextop 8-bit
> nickname

> d) in the Source address field in the Ethernet header, put in both
> the 16-bit ingress RBridge nickname, and the transmitting RBridge on
> that link's 8-bit nickname
> 
> So---bridges will never incorrectly learn the location of any
> RBridges, because no matter where a packet from R12 arrives into the
> link, the bottom bits will be specific to the RBridge on the link
> that injected the packet.
> 
> RBridges on the link. The bridges inside the link will see 5*n
> RBridge addresses as a result of this proposal. In other words, if
> the RBridge nicknames are 1, 2, ... 517. and there are 5 RBridges on
> the link, the MAC addresses the bridges will see are: {1 - 517} | {1
> - 5}
> 

I like this proposal.... It solves many of the problems we've been
looking at, with a single "shim/ethernet" header. We could make the
total header the size of an ethernet header plus the trailing TTL and
reserved space, making the size come out right for easy processing, etc.

Should we replace the current shim header text with this?

:-)

Russ

- --
riw at cisco.com CCIE <>< Grace Alone

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 10 Nov 2006 15:06:31 +0100

Looking at this proposal, I get the impression that we are somehow 
building a hierarchy, which is essential to get scalability. However a 
more generic solution would have more widespread applicability. See the 
attached slide with a proposal from J. Morales for  a hierarchical 
structure usage of MAC addresses (using the Local half of MAC addresses 
(U/L bit set to Local) with  hierarchical structure).
Lack of hierarchical Ethernet (not replacing current universal MACs) 
addresses is one of the main current obstacles for Ethernet scalability 
at Metro level.
Guillermo

Russ White escribi?:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>   
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFVH4kER27sUhU9OQRAlEXAKDlFkl7a93xVCs/aKRKdIc8/IihlwCg0eII
> TvOzBPbanKhybn8xTutKNtE=
> =mbtr
> -----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hierarchicallocalmacaddresses.pdf
Type: application/pdf
Size: 20579 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061110/9a3c6eef/hierarchicallocalmacaddresses-0001.pdf

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Fri, 10 Nov 2006 13:44:35 -0800

rbridge-bounces at postel.org wrote:
> Looking at this proposal, I get the impression that we are
> somehow building a hierarchy, which is essential to get
> scalability. However a more generic solution would have more
> widespread applicability. See the attached slide with a
> proposal from J. Morales for  a hierarchical structure usage
> of MAC addresses (using the Local half of MAC addresses (U/L
> bit set to Local) with  hierarchical structure).
> Lack of hierarchical Ethernet (not replacing current
> universal MACs) addresses is one of the main current
> obstacles for Ethernet scalability at Metro level.
> Guillermo
> 

How would a local hierarchical MAC address be assigned?
Particularly, how would one be associated with a permanent
global MAC address that an existing end node continued to use?
Wouldn't this just replace one set of tables with another?

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 10 Nov 2006 23:37:13 +0100

> Wouldn't this just replace one set of tables with another?
Perhaps the less disruptive implementation is to assign a local 
hierarchical port MAC address to each port of a "hierarchically capable" 
RBridge.
The advantage of replacing many universal flat MAC addresses with 
hierarchical MACs is that aggregation of the routes to hosts is possible 
(prefix announcement instead of host lists announcement between 
RBRidges). And it is quite close to what has just been proposed  if the 
hierarchical MAC addresses include the RBridge nick-names and/or other 
shared "regional" identifier.
Address assignment may (and should) be of varied types: based on 
topology discovery protocols, on spanning tree, management (OS) 
controlled, etc. It is a matter of the network owner.
Regarding handling of the two types of MAC addresses,  I see two 
mechanisms possible  in a mixed network, at ingress and egress points:
- MAC swapping. The hierarchical bridge port replaces the incoming MAC 
by the hierarchically assigned local MAC. This seems mainly convenient 
for "leaf" ports where only one host is connected. Host is not aware 
that the MAC is replaced by a hierarchical address.
 - MAC encapsulation.The "ingress" "hierarchical" bridge encapsulates 
the frame with the hierarchical MAC addresses in the outer header. When 
the link is shared by several hosts this looks the  most straightforward 
approach. This is more in line with the current encapsulation scheme of 
RBridges.
Regards
Guillermo

---

From: touch at ISI.EDU (Joe Touch)
Date: Sat, 11 Nov 2006 12:11:27 -0800

> brought up at the meeting which were:

I'm very confused by all these proposals.

This is a LOT of complexity (either in figuring pt-pt links in the
original proposal, or assigning subnetted MAC addresses here) all to
save - at most - 4 bytes (the rbridge tags in the shim).

When it comes to optimization, we can consider:

	- performance on the link (extra bytes)
	- fragmentation (none of these help that, since
	all make the packet at least one byte larger)
	- complexity of management / configuration

IMO, the complexity of these alternatives isn't worth 4 bytes.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061111/f1dcbc26/signature.bin

---

From: riw at cisco.com (Russ White)
Date: Mon, 13 Nov 2006 18:08:20 -0500

> that link's 8-bit nickname

I actually have a possible alteration that would make this much easier
to deploy.... What about setting the nickname to 12 bits. Then, on a
broadcast network, you would just set the originator's nickname into the
upper bite of the l2 address, and your local nickname to the lower 12
bits of the l2 address.

Would this make sense? Would 2^12 be enough nickname space?

:-)

Russ

- --

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 13 Nov 2006 17:01:12 -0800

It's certainly simpler to only have a single nickname space, and use the 
same nickname for the
egress RBridge and the nexthop RBridge, and your own RBridge address. 
But I think 12 bits is
too small.

On the other hand, I don't think we need to stick with 24 bits---I think 
setting the local bit on the addresses
in the header should allow us to use 46 bits, which would enable 23 bits 
each for (egress, nexthop) and (ingress, me).

Or---if we had 46 bits to play with in both source and destination 
address, we could use, say, 16 bit
nicknames for RBridges, and have room left over for a TTL.

If we did a TTL, we'd want to take advantage of bridge learning. So, for 
instance, let's look at a packet from
ingress RBridge A, via link RBridge x. The bridges on the link will be 
learning A|x. If we throw in a TTL,
they would learn A|x|TTL. So therefore, we could put a TTL in both the 
source address and destination address.
The source address would be the real TTL. So x is forwarding a packet 
from ingress A to egress B via link
neighbor y, let's say. If the TTL from B via y is usually a certainly 
value, say n, then x should put "n" into
the TTL portion of the destination address (and decrement the TTL 
portion of the source address).

But other than mentioning this just in case people find it useful, I 
still think we should just stick with the 6 byte
shim header and have the traditional hop by hop header (with MAC address 
of transmitter and next hop).

Another thing we haven't talked about on the list (and ran out of time 
at the meeting), is Don Eastlake's
suggestion of allowing the shim header to be variable length, so that we 
can optionally put in thing like LIDs.

Radia

Russ White wrote:

>iD8DBQFFWPrkER27sUhU9OQRAnhGAKCOrYegMweS0lMzL4oQkuJ014/CSQCgigHQ
>NCIaRhMvL3u328TelicAToc=
>=TfCt

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 29 Nov 2006 22:58:25 -0500

Hi,

It is not so much that I think that TRILL needs any particular extension
added right now, it is just that if there is ever a reason to add an
extension, it would be good for the extension framework to have been
decided in advance. The presentation that I didn't have time to make at
the TRILL WG meeting in San Diego has now been converted from MS Power
Point and is on the Working Group agendas and presentations web page for
the 67th IETF meeting in HTML and is also available at
http://www.pothole.com/~dee3 in PDF.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Monday, November 13, 2006 8:01 PM
Cc: rbridge at postel.org
Subject: Re: [rbridge] Should we optimize the common case?

......

Another thing we haven't talked about on the list (and ran out of time
at the meeting), is Don Eastlake's suggestion of allowing the shim
header to be variable length, so that we can optionally put in thing
like LIDs.

Radia