Re: Flow label versus Extension header - protocol itself

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Francis,

Francis Dupont wrote:
>  In your previous mail you wrote:
>
>    I think that at the moment I agree with you that flow labels should be
>    used if the existing definitions of flow labels can be accomodated
>    (few though they are).
>    
> => the problem with the overloading of flow labels is this should likely
> break all other possible usages of flow labels (not a surprise).
> For instance if flow labels are changed to be allocated after the first
> packet and/or by the receiver.

I guess this is right, except that we can make a change to the semantics
which don't impact the existing label path, and won't be visible to
applications.

>    The original assumption was that flow labels (in general, rather than in
>    shim) would be sender selected.  Marcelo has mentioned that there may
>    therefore be pre-shim flow labels in existence at negotiation time.
>    
> => the flow label is selected by the sender before it sends the first
> packet. IMHO shim stuff should not touch the flow label, i.e., the only
> real but marginal question is whether the flow label should be reset when
> an address in the IPv6 header is changed (there are pros and cons, and in
> fact it doesn't really matter :-).

I agree that the existing requirements for sender place a limitation on
what can be changed (nothing) on the original path where the
communications are established.

If receiver based allocation of labels is useful (which is still under
debate, I guess), then the allocation of labels on other paths when
addresses change can be used to provide that receiver allocation
without impairing the semantics of flow labels for applications or
on the forwarding path (regardless of which path that is).

Whether this is the right approach or not needs to be weighed
against the costs and ease of other ideas.

I'm looking forward to discussion about these issues.

Greg