On Tue, Apr 21, 2015 at 1:43 PM, Brian E Carpenter
<[email protected]> wrote:

>> Updating end hosts to set flow labels per RFC6438 is easy (e.g. this
>> is supported in Linux stack now). Upgrading all of our switches in the
>> network to use flow labels for ECMP and updating all of our NICs to
>> use flow labels for RSS is *not* easy-- this assumes that would could
>> even find HW that supports labels and are already using IPv6.
>
> True. But we only make it less likely to happen by proposing a work-around
> with bogus port numbers. I don't think that is the IETF showing industry
> leadership, exactly. (The same goes for Xiaohu's quote from
> https://tools.ietf.org/html/draft-rtg-dt-encap-01#page-7 .) If we cop
> out, we can certainly rely on the industry following us.
>

Brian,

We would have more leverage with the vendors if flow labels were
enabled by default on hosts, but the initial ambiguity in their
specification has complicated that. In the initially proposed patches
for Linux that implemented RFC6438, we had enabled flow labels by
default for all IPv6 packets. There was pushback because of concerns
that stateless flow labels could conflict with those made by flow
label manager which is a stateful mechanism that includes a socket
option to set flow labels on connections. This mechanism predated
RFC6437 and RFC6438, so the part in section 4, RFC6437 that stateful
flow labels can't "disturb" stateless ones was after the fact. The
upshot is that we were not able to turn on flow labels by default and
that fact limits their potential value.

A solution to this might be to split the number space into an RFC6438
range, and stateful labels range. This is a not backwards compatible
with possible uses of stateful flow labels, but if the range RFC6438
is indicated by the high order bit that might be workable based on the
assumption that most stateful flow labels are probably assigned low
values.

Tom

_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to