Hi Remi,
On 10-10-28 02:50 AM, Rémi Després wrote:
Le 28 oct. 2010 à 07:18, Suresh Krishnan a écrit :
...
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?
They don't!
(Load balancing is a one-way function. If a host sets FLs, its flows to all
destinations can be load balanced with ecmp, independently of what other ends
do.)
For one-way functions, it should not matter if one side thinks of these
20 bits as two different fields (4+16) and the other as a single 20 bit
field, right? I agree with the goals you have stated in this thread, but
I am trying to figure out *what exactly breaks* because of
shortening/splitting out the field.
And this one-way quality is certainly not true of the other work
(draft-zhou) that you mentioned that requires that the Flow Label be be
mated to the NAT binding on one side and to the point-to-point link id
on the other side.
....
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.
Right "if we need to change the nodes at both ends", but we don't.
As I said before, for draft-zhou, we need to.
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
