[rbridge] load-balancing rbridges

[Vishwas Manral]

Hi,

When we do Link aggregation (LACP), we already to load-balancing between
Ethernet links (though this is between about parallel links - which
would be one link to STP currently).

As Radia said in current implementations, we do it on a flow basis. Load
balancing criteria currently used are source address, destination
address, and address pairs, TCP, UDP ports and even five-tuple
based(there is a default criteria based on layer-2 alone, if for example
we have fragments and cannot get the port numbers).

Thanks,
Vishwas
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Thursday, August 11, 2005 11:13 AM
To: Developing a hybrid router/bridge.
Cc: Joe Touch
Subject: Re: [rbridge] load-balancing rbridges

I'm travelling, so don't have too much time for
email, and notice this very long thread.
I suspect more people than just me would appreciate if it one of you
would summarize the conclusions of this thread so far.

In skimming...some comments...
traditional bridges and traditional IP routers forward based solely
on destination address. However, routers can keep multiple paths to
the destination, and choose between them based on some other criteria.

One story I sometimes tell is that, fresh out of school, I could
throw around queing theory and prove that you'd get better network
utilization if you did path-splitting (presumably, round-robin).
Then Dave Clark pointed out that this makes life hard for layer 4...
packets get arbitrarily out of order, it's hard to measure round
trip delay, it's hard to figure out MTU size, etc. So then I
switched to advocating, if you keep multiple paths, to deterministically
choose the path so that the same flow will always go the same way.
I think that's how routers tend to be implemented today...each
router can independently do some sort of hash based on source address,
perhaps ports, perhaps TOS information, and use the hash to make
a selection from the equal (or almost-equal) cost paths.

Bridges really can't load-split, unless you
do something (like what has been suggested and possibly deployed)
of having different spanning trees for different types of packets, where
all the bridges know somehow which type of packet, and therefore, which
spanning tree, the packet belongs on.

MPLS though allows multiple paths to be set up between A and B (where
"A" is presumably a router, or something that is MPLS-aware), and
allows A to decide which path to send it on. A has complete control.
Once
it selects the MPLS path, the packet's journey is completely determined.

So, I'm not sure whether I'm being helpful here because I'm having
trouble
understanding this thread (as I said, I need Joe or Alia to summarize),
but what I'm saying is that there are two ways of doing path splitting;
one where someone close to the source determines the remaining path
(which requires something like MPLS), and the other where each
router along the way independently chooses among different paths.
You *might* be able to have an upstream router add advice to the header
for downstream routers to choose which path to use, but if you're
going to do that, it seems better to just use MPLS.

I might be completely off-base on this thread, in which case ignore my
comment, but please, if one of you would be willing to summarize the
thread, I and others will be quite grateful.

Oh, and if you do, can you make the subject line "Summary 1 of
load-balancing bridges"
(then if there is another flurry of messages, someone can add a "summary
2" note, with the theory that if a thread has a "summary" note, you can
catch up by starting at the most recent "summary" note.

Thanks,
Radia