[rbridge] Summary 1 of load-balancing rbridges
Vishwas at sinett.com
Sat Aug 13 01:09:34 PDT 2005
One small thought.
> PS - one final thought. We don't really need to spec any of
> this per se, IMO. We can mention that per-MAC or per-transportflow
> is fine, and that we leave it up to the rbridge implementation to
> decide which to support. Again, so long as it's consistent within a
> single rbridge device it need not be coordinated at all.
I agree we do not need to put the criteria for load balancing in the
spec. It would be ok to discuss it however. In my view it should be
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Joe Touch
Sent: Saturday, August 13, 2005 3:29 AM
To: Joe Touch
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
-----BEGIN PGP SIGNED MESSAGE-----
Joe Touch wrote:
> John Kristoff wrote:
>>>On Thu, 11 Aug 2005 14:40:33 -0700
>>>Joe Touch <touch at ISI.EDU> wrote:
>>>>That's when it would be useful to peek into not only the IP, but
>>>>transport headers to mux across the pair of paths without reordering
>>>>within a transport connection.
>>>>From an operational perspective I'd prefer Alex's suggestion to use
>>>MAC addresses as the flow hash for load balancing. It seems much
>>>simpler and seems to solve most of the problem. Separate tools or
>>>other protocols can be used to achieve more perfect load balancing
>>>if it is needed.
> Load balancing by looking at IP and TCP headers is already common and
> solves the problem at hand (avoiding reordering within a transport
> MAC-based load balancing, besides not helping with the case I cited,
> also fails for systems with multiple NICs that stripe a single
> across multiple interfaces (e.g., channel bonding). Granted, they're
> sort of 'asking for it', but it seems OK to use a fairly common
> technique if it solves this problem too.
PS - one final thought. We don't really need to spec any of this per se,
IMO. We can mention that per-MAC or per-transportflow is fine, and that
we leave it up to the rbridge implementation to decide which to support.
Again, so long as it's consistent within a single rbridge device it need
not be coordinated at all.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
rbridge mailing list
rbridge at postel.org
More information about the rbridge