enterprise multihoming with ISP consortiums

[Darrell Root <droot@cisco.com>]

multi6 folks,

I have an idea regarding multihoming.  The idea is that
groups of 2 or more ISP's can, at their option, form a
consortium to support multihoming.  In addition to each
ISP's individual /32 (or larger) allocation, the registries
would allocate the consortium a shared /32.  All the ISP's
in the consortium would advertise the /32 into the rest of
the DFZ.  In addition the ISP's in the consortium would
accept /48's inside this shared address space from each
other via their direct peering connections.  Multihoming
enterprises would be allocated a /48 (in most cases) from
the consortium and directly connect to at least two members
of the consortium.  An individual ISP could be a member
of multiple consortiums, each with a distinct collection
of ISP's as members.

Running through the multihoming requirements document:

3.1.1) Redundancy: this multihoming strategy provides
redundancy for most failure modes. One exception is if
one ISP continues to advertise the /32 into the DFZ
zone but is unable to deliver the packets to either the
enterprise or to any other member of the consortium
via a more specific (usually /48) route.

3.1.2) Load sharing: The enterprise has full control
over the outbound network traffic.  The enterprise has
limited control over inbound traffic because each ISP
advertises a summarized /32, while the enterprise only
injects a /48 into the ISP.

3.1.3) Performance: I'm uncertain whether this proposal
meets the performance requirement.  Regarding the specific
example of a performance problem between the two
ISP's, in most circumstances
each ISP in the consortium would send traffic directly
to the enterprise, bypassing congested links between
them.

3.1.4) Simplicity: Except for the creation of the
consortium (which would involve substantial negotiations),
this proposal is simply implemented.
This can be executed with IPv6 code which exists today.
The site can multihome to multiple providers in the
consortium with BGP or even with static routing.  If a
consortium has more than 2 members an enterprise could
even change one of their providers without renumbering
(at least in a technical sense, contract terms between
consortium members and their customers are left as
an exercise for the reader).  Another big advantage
is that each enterprise will only have to run one IPv6
prefix on their internal networks.

3.1.6) Transport layer survivability: Met.  Because
the same address space is used with all consortium
members, an outage at one ISP will be rerouted around
without losing existing transport connections.

3.2.1) Scalability.  This is a complicated evaluation.
The number of routes in the DFZ zone will now be
the sum of the number of ISP's plus the number of
consortiums.  In the worst case, every possible
combination of ISP's could be a consortium, resulting
in an explosion of the DFZ routing table.  Even that
worst-case would be better than current IPv4 practice,
however, where every multihoming enterprise has it's own
PI space.  The reason for this is that a consortium
will only exist if there is at least one customer (a
multihoming enterprise).  So the number of consortiums
will be less than the number of multihoming enterprises
(equal in the very worst case).

In practical terms, the idea is to try to have
each consortium serve multiple enterprises.  If
a consortium serves 10 enterprises, that's a net
benefit of 9 fewer routes in the DFZ than if each
enterprise had used PI space.  But it is worse
for the DFZ routing table size than having
multihoming enterprises run multiple prefixes
from each provider.  Of course, the multiple prefix
solution has other disadvantages, particularly for
large enterprises.

To maintain the long-term stability of the internet,
the trick is to allow consortiums to exist (to support
enterprise multihoming needs while maintaining a
competitive environment) but minimizing their number.
I'm open to suggestions regarding how to do this.  One
possibility is to try to align ISP consortiums with major
peering points (having one or more "MAE-West-centric"
consortiums instead of allowing arbitrary consortium
combinations). In effect this is similar to geographic
based allocation, but the "geographic" basis is derived
from peering points instead of ICBM addresses ;-)

3.2.2) Impact on routers: None.  This idea
can be implemented with today's routers.

3.2.3) Impact on hosts: None.  This idea
can be implemented with today's host
IPv6 stacks.

3.2.4) Interaction between hosts and the
routing system: None.

3.2.5) Operations and management: No issues.

3.2.6) Cooperation between transit providers:
This proposal is in complete violation of the
requirement that multihoming solutions not require
ISP cooperation.  The question is whether the
economic incentive of enterprises wanting to pay
for multihoming will be sufficient to convince
ISP's to work together to provide the service.

4) Security considerations: none

Darrell Root
CCIE 8302
droot@cisco.com