Subject: RE: WG next steps

From: "Michel Py" <[email-masked]>
Date: Fri, 15 Nov 2002 21:50:27 -0800

> Pekka Savola wrote:
> Depending on the level of cooperation.
> If the ISP's customer sets a requirement for some kind of
> co-operation (like accepting a more specific route from the
> competetitive ISP) or else chooses another ISP, the ISP
> would have every reason to co-operate (within  reasonable
> limits, as said) with its competitors.

3.2.6 Cooperation between Transit Providers
   A multihoming strategy MAY require cooperation between a site and its
   transit providers, but MUST NOT require cooperation (relating
   specifically to the multihomed site) directly between the transit
   providers.

Michel.

---

From: Darrell Root <[email-masked]>
Date: Sat, 16 Nov 2002 00:25:53 -0800

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
[email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 16 Nov 2002 19:09:45 +0859 ()

Darrell Root;

> would allocate the consortium a shared /32.

Assuming there are N ISPs, if all the possible pairs of them form
the consortiums, O(N^2) routing tables are necessary.

Triple or more homing makes it worse.

> Running through the multihoming requirements document:

Thank you for your proof that the requirement document is useless.

> I'm open to suggestions regarding how to do this.

There is none.

						Masataka Ohta

---

From: Andrew Partan <[email-masked]>
Date: Sat, 16 Nov 2002 10:50:28 -0500

On Sat, Nov 16, 2002 at 12:25:53AM -0800, Darrell Root wrote:
> consortiums.

Plus each ISP would have the number of routes in each consortium
that the ISP is a member of.  A big ISP would tend towards having
all of them.

> In the worst case, every possible
> combination of ISP's could be a consortium

I suspect that this will be more the case as its the end site that
get to decide which ISPs they want to connect to; not the ISPs.
And ISPs are not that great at doing cooperation.

Also note that every time an end site wanted to change their mix
of providers, they would have to change their consortium and thus
would have to renumber.

And note that a consortium means not only a common set of multihomed
customers, but also a forced interconnection agreement between ISPs.
I suspect that this later part will not fly in practice.

	--asp

---

From: Michael Richardson <[email-masked]>
Date: Sun, 17 Nov 2002 12:59:18 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Darrell" == Darrell Root <[email-masked]> writes:
    Darrell> I'm open to suggestions regarding how to do this.  One
    Darrell> possibility is to try to align ISP consortiums with major
    Darrell> peering points (having one or more "MAE-West-centric"
    Darrell> consortiums instead of allowing arbitrary consortium
    Darrell> combinations). In effect this is similar to geographic
    Darrell> based allocation, but the "geographic" basis is derived
    Darrell> from peering points instead of ICBM addresses ;-)

  Yes.

  Your proposal is essential identical to geo-pi, except that with geo-pi,
the "consortium" is geographic, and has a local monopoly on PI addresses.
  
  My concern with your proposal is that getting ISPs to cooperate is
difficult. It is unlikely that tier-1s would join many consortia.
  The tier-1-wannabees in Canada (they are all tier-2s, but few of them 
will admit that) are near impossible to get to cooperate, because they 
think that this will reveal that they aren't a tier-1. 

  This would work very well for tier-3s. However, the problem is that,
once the consortium of tier-3s is formed, I suspect that, if things go well,
they will simple gobble each other up, resulting in me being "multihomed"
to a tier-2 ISP. (Further, some tier-2 ISPs think that "multihoming" means
getting a connection to their Ottawa POP and one to their Montreal POP).

  Having said all of this, it doesn't mean that I think that the world has
to work this way. I strongly believe that IXs makes a HUGE amount economic
sense outside of the metropolitan areas of US. Inside the US, it seems that a
combination of oversupply of fiber and market conditions has lead many to
conclude that there is no business model for IXs. I can't argue this point,
as I don't quite understand the situation there.

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

  Precisely.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [