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

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