Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

[Mark ZZZ Smith <[e-mail]>]

      From: Nick Hilliard <[e-mail]>
 To: Mark ZZZ Smith <[e-mail]>; "[e-mail]" <[e-mail]> 
 Sent: Sunday, 19 April 2015, 21:16
 Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
   
On 19/04/2015 04:50, Mark ZZZ Smith wrote:
> / That is what the flow label is for, and we should be encouraging vendors
> of both host OSes and devices which perform LAG/ECMP to be setting/using it
> for that purpose. Support for the use of it this way is in the current IPv6
> node requirements RFC from 2011 (RFC6424).
> 
> / Although it is disabled by default, the Linux kernel has supported
> automatic generation of flow label values since around August 2014 (sysctl
> net.ipv6.auto_flowlabels=1 to enable).

yes, the flow label will help as one entry in the hash n-tuple but it would
be unwise to depend on this as the only hash entropy source.
/ The RFC updating the flow label specification says that at a minimum it should be a 3 tuple of SA, DA and uniformly distributed flow label value.

  L3+L4 header
information is still a better determinant.
/ Layer 4 headers aren't good because they may not be directly behind the IPv6 header (as they might have been in IPv4 too because of options) and TCP and UDP aren't the only protocols you might want load distributed.
  It always surprised me that the
flow label has been part of the ipv6 spec since the very earliest
discussions in 1993, but that it wasn't present in the linux kernel until
very recently and even then, only as a non-default option.


/ I think applications being able to set the flow label value if they choose to has been available for a very long time, the thing that is much more recent is automatic label generation.

Nick