I may have not quite understood the comments about ECMP
and the flow label in 6man today. But here goes:
The flow label spec in RFC3697 says, very carefully and
precisely:
IPv6 nodes MUST NOT assume any mathematical or other properties of
the Flow Label values assigned by source nodes. Router performance
SHOULD NOT be dependent on the distribution of the Flow Label values.
Especially, the Flow Label bits alone make poor material for a hash
key.
This seems to be frightening people. The point is that, although we'd
like the flow labels to be widely scattered across the 2^20 possible
values, we can't be certain that arbitrary sources will generate that
with adequate randomness. Since we didn't know when we wrote RFC3697,
and don't know today, which end-to-end use cases for the flow label
will emerge, we can't make any mathematical assumptions about the
actual randomness. In fact, today, the average value of the flow label
is essentially indistinguishable from zero.
The key word in the above extract is "alone". If you want use a hash
to drive ECMP, don't just hash the flow label, because you'll very
likely always get the same answer.
If you currently use a 5-tuple for an ECMP hash, expand it to a
6-tuple by adding the flow label.
Section 1.2.5 of draft-fairhurst-tsvwg-6man-udpzero-00 says:
An alternate method could utilise the IPv6 Flow Label to perform load
balancing. This would release IPv6 load-balancing devices from the
need to assume semantics for the use of the transport port field.
This use of the flow-label is consistent with the intended use,
although further clarity may be needed to ensure the field can be
consistently used for this purpose. Router vendors could be
encouraged to start using the IPv6 Flow Label as a part of the flow
hash.
I think the fact is that you can usefully *add* it to the hash, in the
expectation that non-zero flow labels will appear in future, but
initially it will do nothing to improve the distribution of the
hash. So I think that the ports cannot be removed; the second sentence
above is wrong.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
