Le 28 oct. 2010 à 18:01, Suresh Krishnan a écrit : >>>> ... >>> 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?
For load balancing between two hosts, anything ensuring that FL's are in general different between two unidirectional flows having the same source does work. What I don't follow at this point is what you wish to have: - statu quo - a completion, at last, of the FL specification (i.e. in my understanding without changing the 20-bits field we have for it) - doing something else, but then what, with which target time frame? > 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. I would rather say that, for draft-zhou application, we "want" both ends of point-to-point tunnels to have the same FL values for both directions of each bidirectional flow, and that, because both ends identify flows in the same way, this can easily be ensured. I see this as a worthwhile application of flow labels (simple, efficient, and perfectly compatible with a possible load balancing between the two ends of each tunnel). Quickly finishing the specification so that this application becomes formally compatible with, without a risk to become incompatible later on, makes sense to me. Regards, RD -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
