Hi Remi,
On 10-10-27 03:26 AM, Rémi Després wrote:
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 proposals need consenting hosts on both ends to be useful, don't
they? What would be the point otherwise? Can you think of an example
involving an unmodified host in either case?
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.
My point was, if we need to change the nodes at both ends to implement a
new use of the flow label, the backward compatibility argument is moot.
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------