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

> http://www.ietf.org/internet-drafts/draft-nordmark-multi6dt-shim-00.txt

[Co-chair hat off]

I personally like this approach (I was always a fan of NOID).

Substantive remarks:
--------------------

 > 5.  Placement of the multi6 shim
...
>    ...Layering the
>    fragmentation header above the multi6 shim makes reassembly robust in
>    the case that there is broken multi-path routing which results in
>    using different paths, hence potentially different source locators,
>    for different fragments.  Thus, effectively the multi6 shim layer is
>    placed between the IP endpoint sublayer, which handles fragmentation,
>    reassembly, and IPsec, and the IP routing sublayer, which on a host
>    selects which default router to use etc.

This raises an interesting point about the flow label. According to
RFC 3697, a flow is identified by the 3tuple
    {Flow Label, Source Address, Destination Address}
and flow labels are only required to be unique when considered as
part of this 3tuple. In other words it is quite legal (even
if silly) for a host to use Flow Label = 1 for simultaneous
flows to Address A and to Address B. Now, what should we say
in the context of the multi6dt shim? Is a flow identified
by the complex tuple
    {Flow Label, {Source Locators}, {Dest Locators}}
or by
    {Flow Label, Source ULID, Dest ULID}
or do we simply consider it as a set of flows that all
happen to have the same Flow Label but various different
locator pairs?

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.

 > 8.1.  Initial Context Establishment
...
>         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.

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

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

> 9.2.1.  Flow-label
> 
> 
>    A possible approach is to carry the context tag in the Flow Label
>    field of the IPv6 header.  This means that when a multi6 context is
>    established, a Flow Label value is associated with this context.
>    When a packet is received, the Flow Label value is used as a key to
>    determine the context to be used for the demultiplexing operation,

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

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

(One catch: the source must not send shimmed packets until it has
positive acknowledgement that the destination has built the multi6
state, but I think that catch will apply to all solutions.)

Now, I see that you list exactly this below as "Another approach."
But I think it is in fact the *only* approach that is fully
consistent with flow label semantics, since the flow label is *only*
unique per source/destination pair.


Editorial:
----------

> 4.  Locators as Upper-layer Identifiers
...
>    This implies that the ULID section is performed as today's default

s/section/selection/

> 8.4.  Handling Initial Locator Failures
> 
> 
>    Should not all locators be working when the communication is
>    initiated some extra complexity arises, because the ULP has already
>    been told which ULIDs to use.  If the locators that where selected to
>    be ULIDs are not working and the multi6 shim does not know of
>    alternate locators, it has to choice than to have the application try
>    a different ULID.

s/has to choice/has no other choice/

     Brian