In a message written on Mon, Apr 18, 2011 at 08:44:03PM +0200, Lukasz Bromirski wrote:
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.
I would agree with this statement if and only if you qualified it with "for the default free zone (DFZ)". LISP reduces the number of routes in the DFZ by making each route represent a "location". However, like the proverbal balloon, when squeezed on one end the other side gets larger. LISP does this by introducing an entirely new infrastructure, the mapping servers. These must now scale to meet the demands that will be placed on them. LISP also does this by making the edge box responsible for looking up and caching information on the flows going through it. In this way LISP, on a worldwide basis, very closely resembles a Cisco 7500 Chassis circa 1996 with "flow caching". The mapping servers are the RP, the DFZ is the backplane, and the edge boxes are the linecards. In both designs when the first packet comes in a lookup is made to the central authority, and a cache entry is placed down at the entry processor. The backplane is dumb and fast. Anyone familar with then enviornments where a 7500 performed poorly should be able to immediately detect where a LISP architecture will perform poorly. Any events which invalidate the cache will result in a period of extremely high usage on the mapping servers likely with extremely high packet loss until all entries are resolved. Any edges which talk to a significant number of other networks will have to cache a significant portion of the Internet, which will actually lead to edge boxes having to be larger than they are now. It is the last point I find most interesting about LISP. Today someone who wants to route their own address space at 10G can buy any number of cheap L3 devices with enough RAM and CPU to hold the internal routes and a default pointed at their provider. The provider's boxes keep the full table and move the packets to where they need to go. In a LISP world that edge box would be set up to do map/encap, and thus would need to keep cache entries for all active addresses, which for a busy site is potentially the entire table. The service provider box now no longer needs to know about all destinations, and thus can have a smaller table or be upgraded less often. [Note, while I describe the edge here as customer owned, it's entirely possible it may be ISP owned and managed for the customer, a cost of which I'm sure they would fully pass on.] To my mind then, LISP moves these tables from a few thousand DFZ routers managed (generally) by well staffed engineering teams to tens or hundreds of thousands of edge boxes, in many cases managed by the clueless. Many edge proponents will say it's easier to upgrade the edge than the core, so this is a win. Vendors may like the idea of 100,000 boxes needing the resources to hold most of a table, rather than 1,000. If the Internet had started out with a LISP design from scratch I'm not sure it would be any better, or worse than our current configuration. Back to the balloon, it trades cost and complexity in one area for cost and complexity in another area. In that sense I am neither against it nor for it, it's just 'different'. The problem is we don't live in a LISP world. To go there now would be a wholesale conversion from what we are doing. Granted, the LISP folks have designed something that is relatively easy to convert to, so they are making an effort. Still, to justify a conversion and the engineering time and business risk it would have to be significantly better. Like 2x-4x better, and preferably an order of magnitude. That's where I'm just not seeing it with LISP, yet. I hope the LISP guys keep working on this, they are at the moment the only credible alternative I've seen to our current system in my lifetime. It's just not good enough to justify a switch based on the current world conditions and state of the solution; at least to me. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/