Re: Flow label versus Extension header - protocol itself

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

 In your previous mail you wrote:

   >  so if you'll use flow labels for shim6, you'll remove
   > any possible use, including the unspecified QoS stuff (called flow
   > state establishment and related service in RFC 3697).
   
   I don't see this. I think that a set of requirements of usage are 
   defined in RFC3697 and as long as we fulfill those, other apps should 
   be able to use it also.
   
=> RFC 3697 was published because there was no concrete flow labels
for QoS proposal (there is still none :-) and the situation became
really problematic. But RFC 3697 is nearly only about defaults, i.e.,
explains what to do waiting for the QoS stuff... which will likely
a bit different about the critical details, for instance the flow
definition (IMHO with layered payloads we should get more fine grain
flows, and with aggregation more large grain flows).

   >  This is why
   > I used the word "real" for compliance: not only the text of RFC 3697
   > matters, but the spirit also and you can't argue any proposal using
   > flow labels for shim6 will be compatible with any proposal using
   > flow labels for QoS as soon as it is RFC 3697 compliant...
   
   I am sorry but i am not able to see spirits, just read RFCs, so it hard 
   for me to design a mechnansim that is compliant with the spirit.
   
=> but with the years of hype about flow labels are for QoS, you should
have some ideas about the background (:-).

   However, i guess that you and other people (Brian) were involved in the 
   discussions about the flow label and could provide a set of 
   requirements that represent this spirit.
   
=> don't touch my bits (:-)? Seriously we should simply consider flow
labels as reserved for QoS purposes.

   Now, i don't think that arguments like "there cannot be two different 
   simoultaneous usages of the flow label" are good enough, though. A set 
   of requirements that would allow future usages of the flow label would 
   be much better. Then we can see if we can define a usage of the flow 
   label for the shim that fulfill those.
   
=> the issue is there is no concrete QoS proposal so it is hard to know
what will be the real requirements... I know this doesn't help at all,
this is why my idea is to break the reservation to something which
perhaps will never happen, and to get rid of all the written and
unwritten constraints.
   
   I mean, i am all for preserving future usages of the flow label for QoS 
   and other stuff, and i think that the flow label bits in the main 
   header are really precious and that usages that profit from hop by hop 
   processing of these bits are the ones that really need those bits (not 
   the shim, which is e2e)
   
=> so in fact you understand the spirit (:-)!

   However, i think that some proposals that have been considered, are 
   defining a usage that may not affect future usages of the flow label 
   and are worthy to be considered.
   
=> as our purpose is not to publish a research paper we know this is
not enough and there are some not technical problems to solve first.
   
Regards

Francis.Dupont@enst-bretagne.fr