On 11, Apr, 2011, at 23:53 , Jeff Wheeler wrote:
On Mon, Apr 11, 2011 at 2:03 PM, Owen DeLong <owen@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@inconcepts.biz> Sr Network Operator / Innovative Network Concepts