Subject: [Hipsec] HIP multihoming status

From: Tom Henderson <[email-masked]>
Date: Sun, 22 Nov 2015 23:01:07 -0800 (PST)

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.

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

Issue #7 raises the issue of incorporating support for load-balancing across multihomed scenarios.

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

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.

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.  

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?

- Tom