Re: Flow label versus Extension header - protocol itself

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Francis,

El 05/05/2005, a las 10:10, Francis Dupont escribió:

>  In your previous mail you wrote:
>
>    I fail to understand your conclusion here:
>
> => Have you read my previous messages?

yes

>    the mechanism describe by Greg and Erik seem to be compliant with
>    RFC3697 to me...
>
> => don't joke:

i am not

>  there can not be two different simultaneous uses of
> flow labels,

why? as long as none of the two parties that are trying to use don't 
need to change it once it has been assigned and that the assignment 
requirements are compatible i don't see any problem...

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

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

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.

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.


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)

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.


>    I mean, in this approach the flow label used for a exchanging 
> packets
>    with a given src and dst addresses remains constant during the 
> lifetime
>    of the communication, so could you point out exactly which part of
>    RFC3697 they are not compliant with?
>
> => I've considered only approachs which fulfill some requirements:
>  - shim6 negociation during communication (vs. before communication)
>  - mobility (i.e., unpredictable address) support.
> (parts of what I called shim6 goals)

agree with both goals and i think that the receiver based flow label 
allocation mechanism described by Greg et al. fulfill those.

Regards, marcelo


> Regards
>
> Francis.Dupont@enst-bretagne.fr