Pekka Savola wrote:
First off, let me try to describe the main idea:
Host A has locators 2001::1 and 2001::2. When it establishes communications to B, it uses 2001::1 as source and 2002::B1 as destination locator (and 2002::B2 is backup). That communication uses flow label = "1".
Now, Host A (and presumably, also B depending on how it allocates flow labels) marks flow label = 1 as reserved for ({2001::1,2001::2},{2002::B1,2002::B2}). Normally, the flow label implementation either doesn't do reservation at all or would just mark (2001::1,2002::B1,1) as reserved.
This part of the description doesn't make sense. Host A doesn't yet know that 2002::B2 is part of the peer locator set.
Thus it has the choice to reserve the flow label for
- ({2001::1,2001::2},{2002::B1}), which could cause problems as you
point out
- ({2001::1,2001::2}, *)
Now, multihoming context is exchanged.
At this point in time, the host finds out 2002::B2, thus it could
potentially refine the flow label to only be reserved for
({2001::1,2001::2},{2002::B1,2002::B2}). But if CGA is used we allow B to add it its locator set, so it isn't obvious to me that this refinement is safe; at a minimum A would have to be able to refuse B's attempt to add locators to the set that would cause a conflict for A.
After that, the host tries to establish a new flow from 2001::1 to 2002::B2; unless there is reservation, it could end up picking "1" as well, which could create issues when either 2002::B1 or 2002::B2 fails because the flow labels overlap.
Of course, there is still a race condition between the communication is established and the multihoming context is set up -- there's no way to do the reservation for destination locators before you know which ones they are.
The problem I was referring to above is that caused either by that race condition.
I don't view this as a race condition that should be minimized or avoided, but as a result of the conscious design decision to allow deferred context establishment. We don't want to require all communication to establish state in the shim, but instead allow the peer to use heuristics (e.g., #packets sent/recvd) to decide whether and when some particular communication has the right cost/benefit tradeoff before
establishing the state in the shim.
A result of this is that there might be rather long lived, but few packets exchanged, communications that do not have the state hence do not know the peer locator set, which would need to have ({2001::1,2001::2}, *) reservations for the flow label.
It all goes to convince me that a destination option is the cleaner answer by far.
Brian