Subject: [rbridge] load-balancing rbridges

From: Vishwas at sinett.com (Vishwas Manral)
Date: Thu, 11 Aug 2005 21:28:16 -0700

Hi Alia,

> If we're willing to require new hardware at every hop for 
> processing incoming frames and outgoing frames (within the 
> campus as well as to/from hosts), then it's not an issue.
The current hardware (if you mean ASIC's) will not work as desired
anyway because of issues I have brought up earlier. 

A simple thing like VLAN itself is decided based on deeper packet
inspection (can be at each hop) and that will break with a new header
coming in (mind you a VLAN aware network, need not necessarily be
sending VLAN tags).

Only when we already have a VLAN tag and no deeper packet inspection is
ever required (it is done on most switching ASIC's) will the Rbridge
scenario work with existing hardware.

Thanks,
Vishwas
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Alia Atlas
Sent: Friday, August 12, 2005 1:57 AM
To: Developing a hybrid router/bridge.
Cc: Joe Touch
Subject: Re: [rbridge] load-balancing rbridges

On 8/11/05, Russ White <riw at cisco.com> wrote:
> 
> Or do we just say: "The ingress edge rbridge should compute a 32 bit
> hash across some locally determined set of fields, and send that in
the
> shim header?" I suppose it's possible to put the field in, and mark it
> for a specific purpose, but not actually specify how to choose which
> link to use based on it, or what specific hash to use to fill it in
(?).

This is what I was picturing.  I.e. the ingress does the intelligent
packet-crawling & puts a hash (of whatever size agreed) in the header.
 Then rbridges could use that hash instead of crawling through the
packet.

> Now, on the other hand, we're concerned about the forwarding asics in
> these bridges, and whether or not they could handle doiong the hashes
> locally. I think that depends on the type of equipment we're thinking
> will actually be playing the part of an rbridge. Most routers today
can
> look at least back to the port numbers to do hashes for load sharing,
so
> the current asics used in routers can do this sort of thing. Does that
> make it any less of an issue?

Certainly current routers can do it - and, if Alex's suggestion that
just considering the original src/dest MAC is enough, they could be
enhanced look at that as well.  But we're not talking routers - but
bridges and they may have different cost points.

If we're willing to require new hardware at every hop for processing
incoming frames and outgoing frames (within the campus as well as
to/from hosts), then it's not an issue.

Alia

---

From: akatlas at gmail.com (Alia Atlas)
Date: Fri, 12 Aug 2005 10:38:35 -0700

Hi Vishwas,

> anyway because of issues I have brought up earlier.

Which ones?  I agree that none of this lets bridges handle link
aggregation where the bridges & link-aggregate are between two
rbridges.
 
> coming in (mind you a VLAN aware network, need not necessarily be

As I understand it, this is only needed for the multicast/broadcast
case, because in the unicast case, the packet is adddressed to the
egress rbridge.

> scenario work with existing hardware.

I agree that deep packet inspection is done on most switching ASICs
today - but this is will introduce a need to look deeper with some
variability.

Alia