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