When reviewing the text for the next update, I rediscovered that
we do in fact say
The proposed generic use is to encourage pseudo-random flow labels that can be
used to assist load balancing.
so (with draft-ietf-6man-flow-ecmp also in progress) I think Fred's
point is covered.
Regards
The issue is that randomness doesn't help, if you want a scalable approach. It
means that for each flow passing through the load balancing system, I have to
store its flow label and assign it a path. What are the arguments against NATs?
One of the big ones is the expectation of per-flow state
Fred,
I'm confused. We've been talking for months about recommending
pseudo-random flow label values as inputs to hash functions,
precisely to allow scaleable and stateless load balancing and ECMP.
I completely agree that per-flow state doesn't scale.
Regards
Brian Carpenter
On 2011-01-10
Let me phrase Brian's comment differently.
Presume we actually get wide use of the flow label in accordance with
the load balancing draft.
What can go wrong? Well, someone could send all their traffic with a
single flow label, reducing the randomness.
So what goes wrong. All of that
On Mon, 10 Jan 2011 14:45:05 +1300, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
Fred,
I'm confused. We've been talking for months about recommending
pseudo-random flow label values as inputs to hash functions,
precisely to allow scaleable and stateless load balancing and ECMP.
I
On Jan 9, 2011, at 5:45 PM, Brian E Carpenter wrote:
I'm confused. We've been talking for months about recommending
pseudo-random flow label values as inputs to hash functions,
precisely to allow scaleable and stateless load balancing and ECMP.
I completely agree that per-flow state
On Jan 9, 2011, at 7:05 PM, Steven Blake wrote:
The network doesn't control port numbers, so his argument obviously doesn't
apply to ECMP or LAG.
There are more than two common uses of load balancing. ECMP is a side effect of
routing; we decide to multipath route when we know of two next
