Re: Flow label versus Extension header - protocol itself

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 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  
   here.

=> you prove the opposite in some lines. The key point is the flow
definition, and this definition can change according to the use of
flow labels.

   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  
   identifier back.
   
=> 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
     won't happen
 -3- try to fulfill unknown requirements
I am in favor of -1-, -2- can be workable but please don't try -3-.

Regards

Francis.Dupont@enst-bretagne.fr