Re: issue 12: interaction with other protocols doing RR

We had a proposal where the results of MOBIKE RR
test could be used by other protocols, if deemed
useful by the designers of these other protocols.
There seems to be general support for this proposal.

We also had a discussion about whether this would
make sense in the Mobile IPv6 space; different
opinions and technical alternatives were offered.
That's OK, however, because we don't get to decide
this part of the problem in WG.

But we can now move forward with the original issue.
Here's my proposalon what the design draft should
say about the matter:

Replace the current text

    MOBIKE might also want to export the information it has done the
    return routability checks to the other modules, like Mobile IP, so
    Mobile IP does not need to do return routability checks again, if it
    is satisfied with the level of checks done by the MOBIKE.

with this new Section:

X. Employing MOBIKE results in other protocols

    If MOBIKE has learned about new locations or verified
    the validity of an address through a return routability test,
    can this information be useful for other protocols?

    When considering the basic MOBIKE VPN scenario, the answer is
    no. Transport and application layer protocols running inside
    the VPN tunnel have no consideration about the outer addresses
    or their status.

    Similarly, IP layer tunnel termination at a gateway rather
    than a host endpoint limits the "other protocols" that could
    be informed -- all application protocols at the other side
    are running in a node that is unaware of IPsec, IKE, or MOBIKE.

    However, it is conceivable that future uses or extensions of
    MOBIKE make such information distribution useful. For instance,
    if transport mode MOBIKE and SCTP were made to work together, it
    would likely be useful for SCTP to learn about the new addresses
    at the same time as MOBIKE learns them. Similarly, various IP layer
    mechanisms might make use of the fact that a return routability
    test of a specific type has already been performed. However, in
    all of these cases careful consideration should be applied.
    This consideration should answer to questions such as whether other
    alternative sources exist for the information, whether dependencies
    are created between parts that prior to this had no depedencies, and
    what the impacts in terms of number of messages or latency are.

    Reference [draft-crocker-celp-00.txt] discussed the use of
    common locator information pools in IPv6 multihoming context;
    it assumed that both transport and IP layer solutions would be
    used for providing multihoming, and that it would be beneficial
    for different protocols to coordinate their results in some manner,
    for instance by sharing experienced throughput information for
    address pairs. This may apply to MOBIKE as well, assuming it co-exists
    with non-IPsec protocols that are faced with the same multiaddressing
    choices.

    Nevertheless, all of this is outside the scope of current MOBIKE
    base protocol design and will be addressed in future work.

--Jari