Subject: Re: Multihoming Issues

From: Simon Leinen <[email-masked]>
Date: 01 Sep 2002 16:30:30 +0200

On Fri, 30 Aug 2002 14:33:13 -0700, David Conrad <[email-masked]> said:
> On 8/30/02 10:16 AM, "Fred Baker" <[email-masked]> wrote:
>> - one prefix for each ISP in the world
>> - one prefix for each POP or campus in your network
>> - one prefix for each LAN in your POP or Campus
>> - additional prefixes that you decide to carry for your own reasons (eg,
>> policy)

> My, that's a lot of prefixes.  I'm sure I'm missing something here.

Probably - note how the scope gets narrower as you go down to smaller
parts of the Internet.

In the IPv4 Internet, you have all of the above, plus

- many prefixes assigned to most ISPs in the world after they used up
  their first assignment
- many "campus" prefixes around the world that haven't been assigned
  according to ISP topology (such as legacy Class B/Cs)
- many prefixes for "campuses" around the world that changed or added
  ISPs but kept addresses from their original provider's range.

Looks like IPv6 won't have the first two of these.  We'll see what
will happen to the third category.
-- 
Simon.

---

From: David Conrad <[email-masked]>
Date: Tue, 03 Sep 2002 19:51:23 -0700

Simon,

> Probably - note how the scope gets narrower as you go down to smaller

Well, yeah, but if you want to gain full benefit of multi-homing, each of
these prefixes would need global visibility, no?

> will happen to the third category.

I would agree with the first of these.  I am skeptical regarding the second
-- having seen what sort of organizations became "ISPs" when CIDR
restrictions were imposed make me a bit cynical.  As for the third, I
suspect enforcement of renumbering implied by your statement guarantees
NATv6.

Rgds,
-drc

---

From: Simon Leinen <[email-masked]>
Date: 11 Sep 2002 21:11:38 +0200

> Well, yeah, but if you want to gain full benefit of multi-homing,
> each of these prefixes would need global visibility, no?

If you want to enjoy the FULL benefits of multi-homing, all the other
folks you want to community with must be multi-homed too, so that
there are no single points of failure :-)

Probably the typical site could achieve 95% of the benefits of
multihoming with an impact on only 5% of the global Internet.

What is needed is some sort of feedback loop that weighs the interest
of multi-homing entities against its impact on remote parts of the
infrastructure.

In the spirit of "think globally, act locally", here's what we do as a
regional ISP: We have relatively strict inbound route filters based on
RIR assignment policy and traditional defaults for swamp space (/24 or
shorter in 192.0.0.0/7, /19 or shorter in the non-RIR-administered
part of 0.0.0.0/2 and 128.0.0.0/3 etc.).

In our neck of the woods, most ISPs send e-mails to their peers when
they want to start announcing new paths.  When I notice that the of
the new prefixes violate our prefix filters, I respond that we won't
be accepting those routes by default, but would agree to add an
exception to the filters for a limited amount of time if the new
customer will renumber into a larger aggregate.

This at least creates a small incentive for ISPs to think about
RFC2260-like solutions for multihoming customers, or for customers who
(are forced to) change ISPs to renumber into their new ISP's space.  A
caveat is that we have partial routing, carrying mostly only European
routes, so we don't drop traffic to networks whose routes we filter.
-- 
Simon.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 13 Sep 2002 14:18:01 -0700

Simon Leinen wrote:
> ...
> If you want to enjoy the FULL benefits of multi-homing, all 
> the other folks you want to community with must be 
> multi-homed too, so that there are no single points of failure :-)
> 
> Probably the typical site could achieve 95% of the benefits 
> of multihoming with an impact on only 5% of the global Internet.\

Depends on what your definition of benefits is...

> 
> What is needed is some sort of feedback loop that weighs the 
> interest of multi-homing entities against its impact on 
> remote parts of the infrastructure.

That is the basis of the multi-6 wg requirements document. Unfortunately
there are so many competing interests that it is impossible to meet them
all with a simple solution. The end sites want capabilities that strain
the resources of the service providers, and the service providers want
approaches that are non-starters for the end sites. 

Tony