Re: Flow label versus Extension header - protocol itself

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

 In your previous mail you wrote:

   Is the incompatability you're considering based on a semantic 
   interpretation
   of different bits within the flow label (perhaps a little like 
   diffserv)?

=> this was proposed and rejected so I don't believe we'll get
a consensus about a proposal using this.

   Or (potentially) that hosts select flow labels in negotiation with the
   routing infrastructure?
   
=> this is more likely but the key point is the definition of flows.
The RFC gives only a vague idea of what is a flow and explains what
to do waiting the "flow labels for QoS" proposal.

   I guess these are uses which may clash with shim6.
   
=> two proposals for very different purposes are likely to clash so IMHO
there will be only one. The problem is this one is not yet written even
we know its purpose: QoS.

   Did you have something else in mind?
   
=> my advice is to give up because the QoS people will never endanger
the use of flow labels for their purposes. The RFC is illusion, its only
idea is to not leave an unspecified field in the IPv6 idea, it is *not*
to open the door to not standard (i.e., not for QoS) uses of flow labels.

   I think I've been treating it as an immutable number for a
   particular path.
   
=> perhaps we'll see how it will be amazingly easy to overwrite for
a flow labels for QoS good proposal (:-)?

Regards

Francis.Dupont@enst-bretagne.fr

PS: shim6 is end-to-end so an end-to-end mechanism should be used.
The standard one is the destination option...