Re: Flow label versus Extension header - protocol itself

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

 In your previous mail you wrote:

   Dealing with the same header for different purposes in different places 
   in the header sequence doesn't make an implementation easier.

=> the price has been already paid for Mobile IPv6...

   So while 
   this might be viewed as conceptually simple, and implementation needs to 
   verify that a particular option (such as the MIPv6 one) is not present 
   in the wrong "type" (aka "placement") of destination option.
   
=> note this check will be needed by an extension header too.

   To me this,

=> this (extra complexity) should be only a matter of taste if you
accept by counter-arguments.

   and the additional 2 byte overhead for destination options 

=> there will be no real overhead if the proposed extension header
will be 8 byte aligned and the tag length a power of two.

   compared to a new extension header, means that I rank a new extension 
   header better than defining a new destination option.

=> how do you address my concern about new extension header handling
(BTW more not handling :-) by classifiers/filters/etc?

   But I still want to explore the hybrid receiver-based allocation of flow 
   labels, that Greg suggested, more.
   
=> if we are ready for a major change in IPv6 specs the flow label way
is the best, and BTW has no issue with middleboxes or legacy (if there
is no unknown deployed use of flow labels?).

Regards

Francis.Dupont@enst-bretagne.fr