[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flow label versus Extension header - protocol itself
In your previous mail you wrote:
> => because they have a different definition of what is a flow and
> how the flow state establishment method works.
What is a flow and how it's established is of no importance to us
=> you prove the opposite in some lines. The key point is the flow
definition, and this definition can change according to the use of
At some point the source host slaps a flow label on packets
that it considers to be part of the same flow. How and why it does
that isn't important for shim6, the only thing we care about is that
=> this only thing is a strong requirement, not a detail.
the flow label is unique between the full set of locator addresses
and that after a rehoming the flow label remains the same so we get
to recognize the flow in question so we can map the right upper layer
=> so you get the receiver allocation, 10^20 limit, etc. And BTW
this is not the same than the default flow definition of RFC 3697.
This doesn't get in the way of other uses for the flow label as it's
currently defined. Since we get stern warnings from the guy with many
hats that we can't change the flow label semantics I'll assume that
other people also won't be able to do that. So we are compatible with
the existing flow label aothers also have to, so there isn't a problem.
=> there is a problem because we are not without doubt compatible with
the not-yet-existing flow label use. We have three choices:
-1- use something else
-2- get rid of the QoS use because QoS is telecom junk and/or this QoS use
-3- try to fulfill unknown requirements
I am in favor of -1-, -2- can be workable but please don't try -3-.