Re: Multihoming Issues

Simon Leinen <simon@limmat.switch.ch> Wed, 11 September 2002 19:13 UTC

Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21879; Wed, 11 Sep 2002 15:13:45 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA25636 for ietf-outbound.10@loki.ietf.org; Wed, 11 Sep 2002 15:14:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id PAA25609 for <ietf-mainout@loki.ietf.org>; Wed, 11 Sep 2002 15:12:26 -0400 (EDT)
Received: by ietf.org (8.9.1a/8.9.1a) id PAA21787 for ietf-mainout@loki.ietf.org; Wed, 11 Sep 2002 15:10:45 -0400 (EDT)
Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21783; Wed, 11 Sep 2002 15:10:40 -0400 (EDT)
Received: from babar.switch.ch (localhost [IPv6:::1]) by babar.switch.ch (8.12.2+Sun/8.12.2) with ESMTP id g8BJBdSf009253; Wed, 11 Sep 2002 21:11:39 +0200 (MEST)
Received: (from leinen@localhost) by babar.switch.ch (8.12.2+Sun/8.12.2/Submit) id g8BJBcGn009250; Wed, 11 Sep 2002 21:11:38 +0200 (MEST)
X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f
To: David Conrad <david.conrad@nominum.com>
Cc: Fred Baker <fred@cisco.com>, Sister Sibling <ccs522g9@yahoo.com>, ietf <ietf@ietf.org>, iesg@ietf.org
Subject: Re: Multihoming Issues
References: <B99AC33B.11924%david.conrad@nominum.com>
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
From: Simon Leinen <simon@limmat.switch.ch>
In-Reply-To: <B99AC33B.11924%david.conrad@nominum.com>
Date: Wed, 11 Sep 2002 21:11:38 +0200
Message-ID: <aait1cz6hh.fsf@limmat.switch.ch>
Lines: 45
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf@ietf.org
Precedence: bulk
X-Loop: ietf@ietf.org

On Tue, 03 Sep 2002 19:51:23 -0700, David Conrad <david.conrad@nominum.com> said:
> On 9/1/02 7:30 AM, "Simon Leinen" <simon@limmat.switch.ch> 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.

> 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.