Le 27 oct. 2010 à 06:26, Suresh Krishnan a écrit : > Hi Remi, > > On 10-10-26 12:24 PM, Rémi Després wrote: >> Hi, Suresh, >> Le 25 oct. 2010 à 19:57, Suresh Krishnan a écrit : >>> ... >>> I strongly support the load-balancing use of the flow label. >> Isn't it better, then, to quickly improve what we have for this, than >> inventing new uses that would prevent backward compatibility? > > I doubt that any new use of the flow label will be backward compatible. Do > you have any text about this proposal that I can read up on?
In my understanding: - draft-carpenter-flow-ecmp-03 details a promising particular use of 20-bit FLs that wasn't detailed before (Flow Label for tunnel ECMP/LAG) - it can work with the current rules about flow-label settings, but too few hosts, if any, set FLs to non-zero values today - this is, at least in part, due to the fact that these rules are more complex that needed: stateful processing is required, or "seems" to be required (there is a debate), while algorithmic hashes would be easier to implement in hosts and sufficient for load balancing purposes. - draft-zhou-softwire-ds-lite-p2p-02 describes a new use of 20-bit FLs (Deployment DS-lite in Point-to-Point Access Network) - it remains backward compatible with current rules because it is only between point-to-point tunnel endpoints, i.e. without relationship with host FL settings. If one of these proposals would fail with hosts that support current rules for FL settings, it couldn't be claimed that they are backward compatible, but I have personally identified no such incompatibility. >>> The question is how many bits are really required. I am not an operator and >>> hence cannot speak authoritatively, but talking to our customers leads me >>> to believe that 16 bits is sufficient for this purpose. I would love to see >>> some more data on this. >> What is clear is that: >> - 20 bits is always better than 16 for any hash function. > > Absolutely :-). But the question is whether more bits are **needed**. > >> - 20 it the number we have today. > > Yes. And if we are not thinking about changing the current usage of the flow > label, it will certainly stay that way. The point, IMHO, is more more about making the intended really practical (ecmp proposal), and to extend its scope (DS-lite application), than to create new instability in the meaning of IPv6-header fields. Regards, RD PS: Copies also addressed to authors of draft-zhou-softwire-ds-lite-p2p-02 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
