Daniel Roesen wrote:
e.g. enforced(!), centrally administered site-wide policy, incl. traffic engineering inbound and outbound. With no way for hosts to make their own decisions, nothing to (re)configure, no DNS complexity, no wastage of bandwidth for keepalive, no communication setup delays (the slow DSL line have already high latency, don't want to add anything to that) etc.
[FWIW shim6 doesn't have a communication setup delay. But it does have "do no harm" security which is missing from your list.]
But the above sounds like asking for a "free lunch" of a BGP with infinite scaling ;-)
Even in Mike O'Dell's GSE the host had to choose between multiple destination addresses for the peer when sending at least the first packet. So GSE doesn't seem to satsify the above requirement for the hosts to not be able to make their own decisions. AFAICT any case of id/locator separation there will need be a function to pick locators for a given identifier, thus some additional selection is needed.
Apart from finding solutions that scale (which drive us towards a locator prefix per ISP that a site uses), we also need a solution that satisfies the "first, do no harm" security concerns (stated in RFC 4218).
The only deployable security techniques that address those seem to be HBA, CGA, and HIP's HITs. Since all of those techniques require that the IP identifier (what TCP and UDP sees as the IP address) be of a particular form, it either requires involvement of the hosts, or a NAT middlebox that will be a Single Point of Failure.
Thus in searching for a site multihoming approach, the requirements implied that the host needed to be involved in the security side.
Can we do better with respect to traffic engineering without throwing out security? draft-nordmark-shim6-esd outlines ways in which we can get the same feedback loop from routers as in GSE.
I can't see any, as it's a host multihoming solution, not a site multihoming solution. The things I'm primarily missing (aside "keep it simple on the host end, they don't even get TCP right") are site multihoming features that you cannot sanely implement on hosts. But I'm happy to be proven wrong. :-)
Sure hope so ;-) Erik