Re: [Hipsec] HIP multihoming status

[Tom Henderson <[e-mail]>]

Below I am replying inline to my message from November regarding the HIP
multihoming issues, and how they are addressed in newly published draft
version -08.

On 11/22/2015 11:01 PM, Tom Henderson wrote:
> 
> 
> On 11/17/2015 11:52 PM, Gonzalo Camarillo wrote:
>> Authors of the following drafts,
>> 
>> could you please let the WG know their status and what needs to
>> happen next for each of them in order to be able to WGLC them at
>> some point in the future?
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ 
>> http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/
> 
> Recall that we split multihoming from mobility for this version of
> the HIP specifications.  The HIP multihoming draft has received less
> attention than the mobility draft over the years.
> 
> The open tracker issues are listed here: 
> https://trac.tools.ietf.org/wg/hip/trac/query?component=multihoming
> 
> The first one (#3) is one that somewhat prompted the draft split.
> RFC5206 advocates creating full mesh of SAs for multihoming use
> cases. That has led to a lot of overhead/complexity, so this tracker
> item is a reminder to revisit that issue.

There were several complaints that the recommendations for multihoming in RFC5206 led to the formation of too many SAs. For instance, the scenario of two hosts with two addresses each recommended that four pairs of SAs (a full mesh) be set up between the address combinations.

In this revision, the two use cases of fault tolerance and load balancing are distinguished. For the fault tolerance scenario, it is no longer recommended that hosts set up SAs in parallel, but that they keep the addresses in reserve in case an address failure is detected. For the load balancing scenario, it is recommended to create different SA pairs for different paths to be used for load balancing, but stops short of recommending a full mesh of SAs.

> 
> Issue #5 suggests to add support for cross-(address)-family
> handovers, as outlined in a paper several years ago.

I reviewed the paper by Samu, Miika, and Andrei, and included their recommendations to allow the LOCATOR_SET in the R2 packet, and to allow hosts to avoid setting the preferred bit if they choose to do so. Related to address families, I removed draft text about supporting associations and SAs that cross address family realms (e.g. one host has IPv4 address, one has IPv6 addres), since there is no description for how that would work in practice.
> 
> Issue #7 raises the issue of incorporating support for load-balancing
> across multihomed scenarios.

See above; load balancing is explicitly listed as a scenario in the new draft.

> 
> Issue #11 points out that the draft should better clarify the
> relationships between SPIs, interfaces, and locators when multihoming
> is available.

This is related to issue #3 and hopefully has been improved in the rewrite.

> 
> Issue #16 suggests to add support for sending UPDATEs in parallel, to
> lower latency in finding working locator pairs.  Perhaps what should
> be done initially is to review whether there is any specification on
> the receiving side that would preclude such operation in the future.

I did not include this (previously called the 'shotgun' approach) and suggest that we leave it for further study.

> 
> Issue #17 suggests to review two drafts on fault tolerance that may
> contribute to the multihoming specification.  I haven't looked at
> these for several years so I am not sure what specific changes might
> be needed now.

I read these drafts again. I included fault tolerance as a use case supported by the new draft. I did not try to include failure detection protocols such as REAP or the other proposed protocol, and suggest to leave failure detection protocols for further study.

> 
> So in summary, there still seems to be some work to do to resolve the
> above open issues.  I guess that we could perhaps reduce the work by
> avoiding scope increase (e.g. issues 5, 7, 16, 17) but we should
> still review the basic complexity issue that prompted this split and
> led to issues 3 and 11.  Are there any other opinions or
> recommendations about proceeding with the multihoming open issues?

I believe that if this draft passes review by the WG, we could close the open issues as either resolved or wontfix based on the above discussion.

- Tom