Re: [tcpm] [v6ops] Flow Label Load Balancing

[Tom Herbert <[e-mail]>]

> Modulo the comments I've already made, I'm afraid we might be in the
> path of making the FL unusable...
>

Fernanda,

I really don't understand how this makes the flow label "unusable", to
the contrary this is a useful case with good effect and justifies the
work in the host to set the field. In any case, it would be great if
you could provide the draft with the normative requirements that would
make the flow label "usable".

Please include requirements for both hosts and network nodes. If there
is going to the be a requirement that hosts MUST make a 1:1 mapping to
a transport connection and the flow label MUST be consistent for the
life of connection, then I would expect there to also be a requirement
that the flow label MUST be immutable by all devices in the path-- in
particular the requirement of RFC6437 would need to be updated: "A
forwarding node MUST either leave a non-zero flow label value
unchanged or change it only for compelling operational security
reasons..."-- if hosts are not allowed to change a field they are
primarily responsible for setting, then the network should not be
allowed to modify it either.

Additionally, if the underlying design principle is that flow
identification in a packet is immutable and persistent, then I'd like
to see the discussion on how that rectifies with NAT where
intermediate nodes routinely change IP addresses and transport port
numbers without the host endpoints' knowledge-- unlike the flow label,
port numbers are formally part of the transport connection
identification, so changing them in flight is far more invasive and
potentially harmful than changing the flow label (we've seen far more
problems caused by NAT than flow label due to NAT state evictions,
packets of a flow being re-routed to not hit the same NAT device,
etc.).

Tom


> Thanks,
> --
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>