Re: Flow label versus Extension header - protocol itself

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

 In your previous mail you wrote:

   Sorry to keep returning to this point.
   
=> so I return to my main concern too..

   I'm not sure that this is necessary (changing 3697) or even desirable,
   even for proponents of flow-label-as-shim6.
   
=> if we keep full 3697 compliance, the only thing we can do is to
improve the flow label allocation in the shim6-capable sending node,
mainly making them looking as unique (easy with less than 10^10
concurrent comminucations which should be the common case).
 But what happens between two different sending nodes communicating
with the same receiver? They can use the same flow label value and
the same destination address: the receiver can distinguish between them
only with the source address. This works with multi-homing because
the lists of possible addresses per sender are known and do not share
a value, but this does not work with mobility where the next source
address is not predictable.
 So IMHO RFC 3697 is not compatible with mobility when destination
options have no problem at all...

   Within the sender and receiver host, receiver side allocation
   causes some complexity, which may interfere with future uses
   (I guess it would be predictable though).
   
=> IMHO the main issue with a receiver allocation of flow labels
is this won't work at all with not-shim6-capable nodes, i.e.,
there shall be a major interoperability issue with legacy nodes...

Regards

Francis.Dupont@enst-bretagne.fr