Re: Implementations/suggestions for Multihoming IPv6 for DSL sites

[Luigi Iannone <luigi () net t-labs tu-berlin de>]

On Apr 18, 2011, at 10:09 PM, Owen DeLong wrote:

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

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