Re: I-D ACTION:draft-ietf-shim6-proto-00.txt

[Brian E Carpenter <brc@zurich.ibm.com>]

This is a bit late as the discussion has presuambly taken
place, but here are my main comments.

Firstly, it's great to see this draft. Real progress.

> 4.  Protocol Overview
...
>       As a result of this exchange, both A and B will know a list of
>       locators for each other.

I would add that if the exchange fails, the initiator will then know
that the other end does not support shim6, and will revert to
standard unicast behaviour for the session.

...
>    o  At some point in time something fails.  Depending on the approach
>       to reachability detection, there might be some advise from the
>       ULP, or the shim (un)reachability detection might discover that
>       there is a problem.

There's an alternative that I think should be noted:

    Alternatively, a Traffic Engineering function requests a change
    in locator(s). This can be treated much like a failure condition.

...
> 4.1  Context Tags and Use of Flow Label
...
>    o  When the context is created, each endpoint picks an unused context
>       tag based on the constraints above, which is also not used as a
>       flow label for the set of locators.

Now here I have a problem, which is related to a long discussion
between Erik and me some months ago.

Firstly, RFC 3697 needs to be the normative (not informative) reference
for this discussion.

Secondly, I think the above bullet is wrong. I think these should be
the basic principles:

1. The granularity of multihoming fate should be identically equal to
the granularity of flow labels. Whatever set of packets a source ULP
chooses to assign the same flow label is the set of packets that
will get shim6'ed together.

2. If outgoing packets enter the top of the shim with a given flow label,
that should be the shim6 context identifier for that set of packets
(modulo a given pair of ULIDs).

3. If outgoing packets enter the top of the shim with a zero flow label,
the shim creates one (as you decsribe and according to the rules in 3697).

Now that still leaves an issue, if the ULP mechanism for assigning flow
labels happens to reuse a flow label in a way that breaks the restriction
that a flow label is unique to a shim6 locator set. I think that needs an
extra flow label assignment rule as a normative extension to 3697 -
in a shim6'ed host, the shim must register flow labels in the flow label
assignment mechanism in such a way that this cannot happen. (And there
may be a race condition).

If you don't do something like the above, I don't see how the RFC 3697
requirement for e2e delivery of flow labels can be respected. There is still
one glitch - in the case of a zero flow label, does 3697 require you to
restore it to zero? 3697 didn't anticipate the existence of a shim, so
that point isn't clear to me.

These are first reactions in haste, hope they make sense.

   Brian