Re: issue 12: interaction with other protocols doing RR

This text looks fine to me.

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email protected]>
To: "MOBIKE Mailing List" <[email protected]>
Sent: Monday, November 29, 2004 6:45 AM
Subject: Re: [Mobike] 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
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>