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

Yes, this is the case.  If the existing 3697 (sender side) allocation
for flow labels is used, then explicit signaling to add each
<source,dest,label> to a multihoming context has to precede packet
delivery.

So it is possible, but has undesirable properties.

The receiver based allocation scheme doesn't have this problem,
and preserves RFC3697 compliance on the originally homed path.

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

Yes, but only with not-shim6-capable hosts.  There is no problem
with routers, if the new labels are used in the same way as
RFC3697 labels on the new paths (and old paths are unmodified).

The not-shim6-capable hosts won't be doing multihoming anyway, and
won't understand a new destination option, let alone a new
extension header.

Thanks for your patience.

Greg