[139760] in North American Network Operators' Group
Re: Implementations/suggestions for Multihoming IPv6 for DSL sites
daemon@ATHENA.MIT.EDU (Luigi Iannone)
Tue Apr 19 11:31:14 2011
From: Luigi Iannone <luigi@net.t-labs.tu-berlin.de>
In-Reply-To: <A8F72569-A9B0-4A01-906A-47FAFE8CEF5F@delong.com>
Date: Tue, 19 Apr 2011 17:30:58 +0200
To: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
=09
On Apr 18, 2011, at 10:09 PM, Owen DeLong wrote:
>=20
> On Apr 18, 2011, at 12:18 PM, Jeff Wheeler wrote:
>=20
>> 2011/4/18 Lukasz Bromirski <lukasz@bromirski.net>:
>>> LISP scales better, because with introduction of *location*
>>> prefix, you're at the same time (or ideally you would)
>>> withdraw the original aggregate prefix. And as no matter how
>>> you count it, the number of *locations* will be somewhat
>>> limited vs number of *PI* address spaces that everyone wants
>>=20
>> I strongly disagree with the assumption that the number of
>> locations/sites would remain static. This is the basic issue that
>> many folks gloss over: dramatically decreasing the barrier-to-entry
>> for multi-homing or provider-independent addressing will, without
>> question, dramatically increase the number of multi-homed or
>> provider-independent sites.
>>=20
> Done properly, a multi-homed end-site does not need to have
> its own locator ID, but, could, instead, use the locator IDs of
> all directly proximate Transit ASNs.
>=20
This is exactly what LISP suggests. Your locators are provided by your =
provider.
Luigi
> I don't know if LISP particularly facilitates this, but, I think it
> would be possible generically in a Locator/ID based system.
>=20
>> LISP "solves" this problem by using the router's FIB as a
>> macro-flow-cache. That's good except that a site with a large number
>> of outgoing macro-flows (either because it's a busy site, responding
>> to an external DoS attack, or actually originating a DoS attack from =
a
>> compromised host) will cripple that site's ITR.
>>=20
> The closer you move the ITRs to the edge, the less of an issue this =
becomes.
>>=20
>=20
> Owen
>=20
>=20
>=20
