Hi Remi,
On 10-10-28 01:35 PM, Rémi Després wrote:
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?
Certainly not option 1. It is not clear to me what your option 2 means
(What do you actually mean by "a completion at last"). If it means using
it for load balancing, yes, I am supportive of that. I am also willing
to explore option 3.
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.
I am still waiting to find out *what exactly* is the incompatibility
risk for a 16 bit flow label these two use cases you mentioned. As a
hypothesis, consider two nodes A and B one. B is a legacy 3697 node and
A is a new 16 bit flow label node performing ECMP or vice versa. What
exactly would break.
NOTE: This is not really applicable to draft-zhou since both the nodes
need to be updated for the proposal to work. They can easily support a
shorter flow label.
Given all that, as Brian said, one class of potential applications that
will not work well with a shorterflow label are the ones where "longer
is better". e.g. The flow label as nonce proposal. This is where we need
to evaluate how many bits are really required.
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
