RE: enterprise multihoming with ISP consortiums

["Tony Li" <Tony.Li@procket.com>]

Darrell,

Congratulations, you've reinvented ISPACs.  This is, in fact,
the only way that I could see that cause 'geographic'
aggregation to begin to do the right thing.

When we discussed this many years ago, folks just weren't
interested.  Dunno why.  Good luck.

Tony


|   -----Original Message-----
|   From: Darrell Root [mailto:droot@cisco.com]
|   Sent: Saturday, November 16, 2002 12:26 AM
|   To: multi6@ops.ietf.org
|   Cc: Darrell Root
|   Subject: enterprise multihoming with ISP consortiums
|   
|   
|   
|   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
|   
|   
|