Implementations/suggestions for Multihoming IPv6 for DSL sites

Jeff Wheeler jsw at
Mon Apr 11 21:53:40 UTC 2011

On Mon, Apr 11, 2011 at 2:03 PM, Owen DeLong <owen at> wrote:
> I do tend to think that any technology sufficiently confusing that I cannot
> understand it well after reasonable effort is of questionable value
> for wide deployment.

The secret is to ignore all the crazy acronyms and boil it down to
this -- LISP sets up tunnels to remote end-points based on what it
learns from a mapping server, and these tunnels may be used by one or
more end-to-end flows.

>> I personally believe LISP is a horrible idea that will have trouble
>> scaling up, because a large table of LISP mappings is not any easier
>> to store in FIB than a larger DFZ.  The "solution" the LISP folks
> This is one of the few parts of LISP I do understand and I'm not entirely
> convinced that it is all that bad because you don't have to do this on
> core routers, you can push it out pretty close to the customer edge,
> possibly even on the customer side of said edge.

We already have this in the core today, thanks to MPLS.  The problem
with LISP is the router that does encapsulation, which you can think
of as conceptually identical to a PE router, must have a large enough
FIB for all simultaneous flows out of the customers behind that PE
router.  This may be a very large number for an end-user PE router
with a bunch of subscribers behind it running P2P file sharing, and
may also be very large for a hosting shop with end-users from all over
the globe downloading content.  In the case of a CDN, one distributed
CDN node may have far fewer active flows (installed in FIB) than the
size of the DFZ, since the CDN would intend to direct end-users to a
geographically-local CDN node.

As you know, I like to think of what happens when you receive a DDoS.
In the case of LISP, if there are a huge number of source addresses
sending just one packet to you that generates some kind of reply, your
PE router will query its mapping server, install a new
tunnel/next-hop, and transmit the reply packet.  If the FIB is not
large enough to install every flow, it will churn, creating a DoS
condition essentially identical to what we saw with older flow-cache
based routers when they were subjected to traffic to/from a very large
number of hosts.

Like you, I am not 100% sure of my position on LISP, but I do think I
understand it has a very serious design limit that probably doesn't
make things look any better than "polluting" the DFZ from the
perspective of content providers or end-user ISPs.  It does have
benefits from the carrier perspective because, as you say, it can move
the "PE router" into the customer's network and move state information
from the carrier to the edge; but I think this comes at a high
complexity cost and might result in overall more work/cost for

Jeff S Wheeler <jsw at>
Sr Network Operator  /  Innovative Network Concepts

More information about the NANOG mailing list