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

Brian,

Thanks for the comments.

Brian E Carpenter wrote:

> I think it depends where you sit. Above the shim, a flow
> has to be identified using its ULID pair. Below the shim,
> but in the hosts, we have the necessary state to use the
> complex tuple. In routers along the way, we can only
> identify flows in the traditional way.
> 
> This does need to be discussed in the draft, even before
> we get to section 9.2.1.

In fact it is almost orthogonal to 9.2.1.
Even if the flow label is not used for demultiplexing, the draft should 
say how the shim handles the flow label.
I think the simplest approach is that the flow label is carried through 
as is. This means that the {Flow Label, Source ULID, Dest ULID} will 
appear on the wire as the set of {flow label, source locator, 
destination locator) for the different locator pairs.

This does have implications for protocols which do explicit signaling to 
create flow state; such protocols would somehow need to be multi6 aware 
so that they can perform the signaling for all the locator pairs that 
are used on the wire.


>>         At this point in time it is possible for the hosts to change to
>>         a different locator in the set.  But until they have exhanged
>>         the locator sets, and probably until they rehome the context to
>>         use different locators, they continue sending and receiving IPv6
>>         packets as before.
> 
> 
> I think you need to make it clear whether the two hosts have to
> *agree* to change locators, or whether it is a single-ended decision.

I don't know if the approach mandates this, or if it is my particular 
take on a solution, but in any case ...
They would need to agree that they have the capability to change them, 
but once that is done, each end can decide which locators (src and dst) 
it uses in the packets it sends.

>  > 8.2.  Locator Change
> ...
> 
>>    Given that each host knows the locator set for its peer, the host can
>>    just switch to using a different locator pair. 
> 
> 
> Don't the exit router selection and ingress filtering issues need to be
> handled here?

Yes, we need to state that assumption up front.

>> 8.3.  Concurrent Context Establishment
>>
>>    Should both A and B attempt to contact each other at about the same
>>    time using the same ULIDs for each other, the context establishment
>>    should create a single host-pair context.
>>
>>    However, if different ULIDs are used this would result in two
>>    completely independent contexts between the two hosts following the
>>    basic content establishment above.
> 
> 
> Is there really no race condition where this would fail?

I believe that a signaling protocol which sets up and manages the multi6 
state can be designed so that
  - for the same ULID pair there is only a single host-pair context
  - for different ULID pairs between the same hosts one can create 
different host-pair contexts
The NOID draft is an existence proof of at least the first one, but I 
haven't verified the second one.

Note that in the second case it might be desirable to try to either 
merge those contexts together, or at least share reachability 
information between them.


> That isn't enough. As noted above, a flow label is only unique within
> a {Flow Label, Source Address, Destination Address} 3tuple. And in
> multi6, that surely has to be extended to any 3tuple in the complex tuple
> {Flow Label, {Source Locators}, {Dest Locators}}. A slightly tricky
> per-packet lookup, that won't be good for performance. But there is
> good news just below...

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. Note that due to deferred multi6 capability 
discovery this would have to apply to all flow label assignments on a 
host which implements multi6. And it being feasible doesn't mean it is a 
good idea :-)

>>    determine the context to be used for the demultiplexing operation,
>>    hence determining the identifiers that have to be presented to the
>>    upper layers.  Because this approach overloads the Flow Label field,
>>    it is necessary to have an additional information to determine
>>    whether the Flow Label field is actually being used as a context tag
>>    or not.  In other words, additional information is needed to identify
>>    multi6 packets from regular IPv6 packets.  This is because, the same
>>    Flow Label value that is being used as context tag in multi6 enabled
>>    communication can be used for other purposes by a non-multi6 enabled
>>    host,
> 
> 
> Good news. This is wrong (and I didn't realise it when analyzing NOID).
> 
> Flow Labels are not unique on their own and cannot be used for
> anything on their own. You must always lookup a 3tuple.But if the
> received  {Flow Label, Source Locator, Dest Locator} is in the set
> {Flow Label, {Source Locators}, {Dest Locators}} corresponding to
> a particular {Flow Label, Source ULID, Dest ULID} 3tuple, the shim
> *knows* that it is a multi6 packet.

If the {flow label, src locator, dst locator} is used to identify the 
state then you are right. But that prevents a possible optimization with 
changing locator sets (think mobility) by requiring that multi6 
signaling be complete to tell the peer of the new locator before that 
locator can be used as the source.

> (The only extra rule at the source
> to make this true is: never use the same flow label for a multi6 flow
> and a non-multi6 flow to the same destination.)

I think things are harder than they look at first sight.

With deferred state creation, all flows are potentially multi6 flows, 
and furthermore the locator set for the peer isn't know until the 
deferred signaling exchange. This means the flow label needs to be 
unique across all communication at the sender I think.

Take host A communicating with foo.example and bar.example.
foo.example has ULID1 and ULID2 in the DNS. A picks ULID1 for the 
communication.
bar.example has ULID3 and ULID4 in the DNS. A picks ULID3 for this.
A starts communicating with both of them using some flow labels.
Later A decided independently that it is worth-while to setup multi6 
state for ULID1 and ULID3. When doing so it discovers that it is in fact 
the same host, with 4 locators (ULID1 through 4).
If it had allocated the same flow label for some flow to ULID1 and some 
flow to ULID3, it is stuck; it must then constrain to use a subset of 
the locators for each ULID otherwise the receiver would but the wrong 
ULID in the packet.

So in this approach the only sane thing is for the sender to never reuse 
a flow label (where "never" is while there is existing communication, or 
there might be some multi6 state at a peer using that flow label), 
independently of the ULIDs being used.

FWIW allocating a context tag, which goes in its own extension header,
when the multi6 state is created, and only using that extension header 
when the receiver needs to rewrite the address fields (i.e., after a 
rehoming event) is a lot simpler. Costs 8 bytes per packet but only 
after there has been a failure resulting in rehoming to different locators.

    Erik