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