Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt

[Erik Nordmark <erik.nordmark@sun.com>]

Brian E Carpenter wrote:

> > You're right in the general case. However, one could further constrain 
> > flow label allocation for the hosts that implement multi6 so that for 
> > multi6 packets the receiver wouldn't have to compare the locators but 
> > only use the flow label. 
>
>
> No, that doesn't work, because two quite independent source hosts might
> choose the same flow label. You have no choice but to look at the source
> locator as well as the label.

It would work with the proper constraints. If some future standard where 
to say that a host should not send a multi6 packet unless the flow label 
had been "approved" (or allocated) by the intended receiver, the 
receiver could ensure that the flows of multi6 packets it receives each 
have a different flow label.
Whether we want to do this is a different point (and I don't think we 
should be overloading the flow label at all).

> Well, I think you could reasonably require that a sender never uses the 
> same
> flow label twice at the same time (that is more constraining than the 
> global
> rule, but probably not a problem in a 20 bit space).

Yes, and "same time" needs to take into account how long multi6 state is 
allowed to remain on a receiver.

> But you don't need to.
> You simply apply the normal rule - make it unique per source and dest ULID
> pair. That should make it unique across the {{source locator},{dest 
> locator}}
> set anyway, and thats's all you need.

My example should that your conclusion doesn't hold.
This is because the ULID->locator set mapping 1) isn't known when 
communication is started and 2) different ULIDs can map to the same 
locator sets (or map to locator sets that are partially overlapping).

  Erik