LISP's Future Is Not In The Data Center

LISP (Locator/Identifier Separation Protocol) is an IETF draft protocol that separates location information from host information on the Internet. The essential problem that LISP is designed to solve is the cost and viability of increasingly large Internet routing tables. As a side benefit, LISP is also touted as addressing the lack of flexibility and mobility in Internet routing architectures that limit the ability of an enterprise, or even an individual user, from moving providers or locations easily.

LISP is an interesting protocol in that it needs heavy participation from enterprises, small businesses, and service providers to be truly effective. However, I feel that it is only going to ultimately benefit service providers. I don't believe it has an immediate future in the enterprise, even though it is being pushed there.

LISP functions by separating the IP address of your location on the Internet (called your RLOC), from the IP address of your host (your EID). This separation allows you to move freely without regard to huge routing table changes and enables Internet routing tables to consolidate and provide only connectivity level address routing while maintaining the ability to reach the host, all without the cost associated with maintaining routes to each individual host subnet.

That sounds complicated. It isn't. Essentially, LISP is a separate layer of address resolution. Your LISP capable router registers your host address space (your EIDs - non-RFC 1918, of course) with a LISP map server. The registrations also list the provider assigned IP address of all of your Internet gateways (your RLOCs). If you have two ISPs, then you have two entries and two RLOCs. When someone wants to reach you, if they are LISP-enabled, they look up your mapping in the LISP database and send their data in a LISP encapsulated packet from their edge gateway (their ITR - Ingress Tunnel Router) to your edge gateway (your ETR - Egress Tunnel Router). This LISP encapsulated tunnel is similar to a GRE tunnel, although there are technical differences in packet formation; it is not GRE. Once the packet arrives at your RLOC (your ETR) , the LISP encapsulation is removed and the original packet, which has your host IP as the destination and the original host IP as the source. It is put on the wire and delivered to your application. I have grossly oversimplified the process for the purpose of this short post, but the basics are there.

The more people that use LISP, the smaller the BGP tables get because they only need to provide Internet on-ramp information (RLOC routing), not host level detail (EID routing). This should theoretically result in less expensive service provider equipment and less administrative overhead for Internet routing. Although, the new LISP infrastructure will be an additional capital cost and ongoing administrative cost for whomever provides it.I do not believe that resulting cost savings in ISP hardware, software and support will be significant enough to lower your Internet bill. Heck, your bill might even go up once they charge you for your LISP registration, LISP setup, LISP maintenance, and I am sure there will eventually be a federal LISP tax.

The creators of LISP are pushing it as more than just Internet routing table consolidation, because they need as many people as possible to participate for LISP to reach its full potential. So they talk about the provider independent nature of LISP's capabilities in the enterprise network. You already have that today, though. You can multi-home with ISPs if you have your own /24 (or larger) block. You don't need LISP to do this, but it would make it much easier for ISPs if you did use LISP. The traffic engineering capabilities are slightly better in LISP than in BGP, but again most of the benefit here is for service providers also.

IP mobility in the enterprise is also being touted as a benefit of LISP. I can't imagine that will catch on in its current state. For starters, the current Cisco implementation (the only vendor that I know of to offer LISP in the enterprise) means addressing every link in your data center with a /30 subnet so that when a server moves (via VMware vMotion or other method), it will automatically be able to re-register its location using LISP. In addition to the addressing craziness, it has another major problem.

Right now, for example, the Cisco implementation calls for the switch/router to detect the server's movement when it sees IP traffic from an address on a link that is different than the current subnet on that link. It then automatically re-registers this non-conforming host IP with the LISP map server in this new location (or switch). This provides the ability to reach the host and everyone is now able to contact the same IP (EID) in a new switch (RLOC). However, it does not check to see if the original server location is still active before changing the RLOC. This means that if someone boots up a VM accidentally or puts a computer on the network with a bad IP, it can potentially cause a Denial of Service attack on the original server if it was not really moving.

I do think LISP has a future, but I think it will remain a service provider initiative with little enterprise adoption until the benefits outside of routing table optimization become a more concrete reality.