Implementations/suggestions for Multihoming IPv6 for DSL sites

Tue Apr 12 08:59:32 UTC 2011

On 11, Apr, 2011, at 23:53 , Jeff Wheeler wrote:

> On Mon, Apr 11, 2011 at 2:03 PM, Owen DeLong <owen at delong.com> 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.

This is not true. There are several works out there showing that the FIB will not grow as you are saying.

Luigi

>  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
> everyone.
> 
> -- 
> Jeff S Wheeler <jsw at inconcepts.biz>
> Sr Network Operator  /  Innovative Network Concepts
> 