Tom, On 22/04/2015 03:42, Tom Herbert wrote: > 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.
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. Rgds Brian > 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
