The goal is not to split single flows across multiple links. In fact, based on the experience that this causes excessive disordering, we generally require that load splitting techniques must avoid splitting flows across links.

Which gets us to the problem. In using multiple links (ECMP / LAG) the routers generally want the finest granularity possible for that operation. That leads, as you say, to using a hash of the 5-tuple. However, the 5-tuple is not always available. The simplest case is tunnels. Unless the tunnel devices add new UDP headers (which is largely gratuitous and has other problems relative to the IPv6 specifications), the 5-tuple is not visible to the devices forwarding teh resulting packets. This also leads to IPSec needing a UDP header. It is also one of the contributors to why using new extension headers is such a bad idea.

Thus, in working at the problem of how to get various kinds of traffic to be handled for ECMP / LAG, it seemed to many of us that capgturing the randomness of the port numbers in the flow label would be very helpful. (Yes, this assumes that the current hash approach to ECMP / LAG is reasonable. There is reportedly some question on that, but I take it as the best practice we have, and therefore worth continuing.)

Yours,
Joel

On 1/11/2011 8:41 AM, Thomas Narten wrote:
Sorry to get back to basics, but I have not followed all the Flow
Label discussions or read all the drafts. I have read

       draft-ietf-6man-flow-ecmp-00.txt
       draft-ietf-6man-flow-update-01.txt

pretty carefully and I still don't quite understand what real problem
we are trying to solve - and thus, whether the proposed changes
actually help or are a no op.

Is there a document that speaks to this?

Question:

I understand the value  of ECMP type load balancing. But how much of a
problem is it today (with IPv6) if the Flow Label is not used?

If you hash on just the 5 tuple (excluding the flow label),  you get
(I assume) the equivalent of what you have in IPv4 today. Why is that
not good enough?

Also, splitting flows across different links would seem to have value
primarily if you hvae a single source (or rather single src/dest pair)
generating a *lot* of traffic/flows, i.e., so that if you split
traffic from that source/dest pair, you see measurable load-splitting.

Is this happening in practice today? Can operators please speak to
this? And if it is a problem, is it primarily with tunneled traffic
(where the tunnel aggregates many flows), or is it really between
individual pairs of nodes that are sending a *lot* of traffic to each
other? Are there examples of this?

(I'm not necessarily opposed to this work going forward, but I'm not
entirely convinced we are solving a real problem. Help me please.)

Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to