[139731] in North American Network Operators' Group
Re: Implementations/suggestions for Multihoming IPv6 for DSL sites
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Apr 18 16:10:37 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <BANLkTimJ1xosGGbLuZt+NtjamrQnBHCXvA@mail.gmail.com>
Date: Mon, 18 Apr 2011 13:09:11 -0700
To: Jeff Wheeler <jsw@inconcepts.biz>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Apr 18, 2011, at 12:18 PM, Jeff Wheeler wrote:
> 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
>
> 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.
>
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.
I don't know if LISP particularly facilitates this, but, I think it
would be possible generically in a Locator/ID based system.
> 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.
>
The closer you move the ITRs to the edge, the less of an issue this becomes.
>
Owen
