Implementations/suggestions for Multihoming IPv6 for DSL sites

Lukasz Bromirski lukasz at bromirski.net
Mon Apr 18 18:44:03 UTC 2011


On 2011-04-13 21:13, Jeff Wheeler wrote:

> Plain and simple, it does not scale up any better than injecting more
> routes into the DFZ, unless you 1) accept macro-flow-based routing; or
> 2) scale up the size of your FIB along with the much larger number of
> prefixes which would be introduced by lowering the barrier-to-entry
> for multi-homing and provider-independent addressing.

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
do drag around the world and advertise in a number of places,
specially with IPv6. And that's exactly what LISP had in
mind - to prevent massive explosion of FIB for IPv6.

For IPv4 the battle was lost somewhat already - and even
for that, with LISP you can actually reverse the trend,
by moving back with the allocations. As the control plane of
the whole system is moved off the edge routers into
potentially very capable servers, you also have the extra
potential of actually shaping the policies for traffic
engineering dynamically without affecting routing nodes.
We may of course argue that the current routers are pretty
capable in terms of processing power for control-plane, but
the convergence times for exchanging and calculating prefixes for
VPNs in a large (1-2-3-5M+) L3VPN deployments are counted in
tens of minutes, not in seconds. Calculating them offsite and
just dumping per-router-calculated table would be more efficient
and faster.

> However, LISP does have non-Internet applications which are
> interesting.  You can potentially have multi-homed connectivity
> between your own branch offices.

If the LISP is deployed by commercial entities, just as Google
and Facebook are experimenting right now, LISP would also mean
multihoming, load-balancing and trafic engineering options
that are today not available with BGP or highly limited in the
accuracy.

> Beyond non-Internet applications such as this, I think LISP is useful
> largely as a case study for what happens when a bunch of engineers get
> together and "solve" some problems they do not understand -- DFZ
> size/growth being chief among them.

Can't comment on that. I personally find Vince Fuller, Dino Farinacci,
Dave Meyer and Darrel Lewis quite knowledgeable in routing and
proficient in explaining why the LISP was created in the first place,
but you of course may know better.

-- 
"There's no sense in being precise when |               Łukasz Bromirski
  you don't know what you're talking     |      jid:lbromirski at jabber.org
  about."               John von Neumann |    http://lukasz.bromirski.net




More information about the NANOG mailing list