Re: Flow label versus Extension header - protocol itself

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

Hi Francis,

Francis Dupont wrote:
> I am in favor of a destination option (don't add a new extension header,
> PLEASE!) because it seems a tag which can be used (and only the tag itself)
> for demultiplexing can be needed. IPsec has something very similar named
> an SPI and the simple constraint for SPIs to be usable for demultiplexing
> bt the receiver is they have to be assigned by the receiver.
> This is clearly impossible for a standard flow label so the shim tag should
> be assigned (the whole tag or a part of the tag) by the receiver in the
> initial shim negociation phase. IMHO the IKE SPI procedure should be
> copied as it...
> The extra cost of a destination option should not be a problem if the option
> is needed only in special cases (i.e., not in every packets).

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

I think it will be possible to accomodate these pre-existing labels
for the path between the original source and destination while still
allowing receiver selected flow labels for all other paths (and maybe
replace the original label on the home path after flow state timeout).

Of course, there are no major problems if the labels don't preexist the
shim negotiation.

Best Regards,
Greg