Re: issue 12: interaction with other protocols doing RR

sounds fine to me.

Vijay

Jari Arkko wrote:

> 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