On Mon, Apr 20, 2015 at 9:05 PM, Brian E Carpenter <[email protected]> wrote: > Hi, > >> IPv6 flow label has been proposed as an entropy field for load >> balancing in IPv6 network environment [RFC6438]. However, as stated >> in [RFC6936], the end-to-end use of flow labels for load balancing is >> a long-term solution and therefore the use of load balancing using >> the transport header fields would continue until any widespread >> deployment is finally achieved. > > That is a false argument. RFC6438 describes a model where the > tunnel end point sets the flow label; that is a much smaller fix > to a tunnel end point that converting it to use a new encapsulation > such as IP-in-UDP.
Brian, 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. Deployed devices commonly support hashing UDP tuple for ECMP and RSS. This works reliably for both IPv6 and IPv4, and in fact is a major motivation for proposed encapsulation protocols using UDP (MPLS-in-UDP, GRE-in-UDP, VXLAN, GUE, Geneve, etc.). Intermediate device support for flow labels is still needed, for instance we only get 14 bits of entropy in UDP source port (ephemeral port range) which is too little for some use cases. Tom _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
