[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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