Is There a Real Use Case for LISP, The Locator/ID Separation Protocol?

LISP is a protocol that pops back in the news just when you might have forgot that it existed. It happened again in June when Cisco re-launched LISP for fast mobility at their annual user conference, complete with an on stage demo and much fanfare. While the demo’s are impressive, the history of LISP makes me wonder what is going on behind the curtain. This isn’t the first time that Cisco has proposed LISP for a new use case. In 2011, Cisco positioned LISP as a solution for IPv6 transition and virtual machine mobility, along with VXLAN and OTV, creating a triumvirate of proprietary protocols to further pioneering use cases. But is there real value in LISP?

What is LISP? 
LISP is a protocol and an addressing architecture originally discussed at the IETF in 2006 to help contain the growth of the route tables in core routers. The LISP proposal which was submitted in 2010 is still under development as an experimental draft in the IETF, see link.  As far as I have see there is not much consensus regarding the usefulness of LISP, and it has several open issues in the areas of security, service migration and deployability. Because the cost and risk associated with LISP are significant, network operators have scaled their routing systems using other techniques such as by deploying routers with sufficient FIB capacity, and by deploying NAT.

Lack of Adoption
The lack of adoption has not slowed Cisco and at Cisco Live 2012 they said that they have implemented a LISP Mobile IP node client for open-standards handsets and their demo showed such a handset in use, with LISP enabling handoffs while maintaining the same IP address. While this was an interesting demo, LISP is untested for fast mobility and Juniper has not seen momentum in the market place for Mobile IP.  We believe that the market is focused on 3GPP, which is a standards-based implementation that Juniper supports on our Mobile Next solution.



Industry Concerns with LISP
The LISP protocol specification enumerates many “known open issues and areas of future work.” It contains the following caveat: “This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document.” See link.

LISP is one of many technologies that disentangles locator and identifier semantics to help scale IP addressing, however LISP proposes a relatively unproven, cache-based mapping mechanism and LISP proposes a relatively unproven packet transport mechanism, in which LISP routers tunnel packets from location to location.

According to the LISP specification: “The characteristics of map-cache management under exceptional conditions, such as denial-of-service attacks are not fully understood.  Further experience is needed to determine whether current caching methods are practical or in need of further development. “

LISP compromises the separation between a router’s control and data planes. According to the LISP Protocol Specification: “In order to maintain security and stability, Internet Protocols typically isolate the control and data planes.  Therefore, user activity cannot cause control plane state to be created or destroyed.  LISP does not maintain this separation.”

Alternative Solutions to LISP
According to the LISP Protocol Specification, LISP’s only goal is in reducing routing table size. However, Cisco has also positioned LISP as an IPv6 transition mechanism, for mobility of virtual machines, and now fast mobility for Mobile IP. In all cases LISP competes with alternative solutions that do not rely on LISP’s unique and relatively unproven mapping and packet transport mechanisms. Here are some alternatives for network operators:

• Scale routing tables by deploying routers with sufficient FIB capacity.
• Deploy IPv6 natively, avoiding all IPv6 transition mechanisms. If native IPv6 deployment is not possible, deploy a proven transition mechanism such as 6PE, 6RD, DS-LITE.
• Deploy VPLS, or E-VPN for virtual machine mobility
• Deploy industry standard methods for mobility such as 3GPP

Where Do We Stand?
At Juniper Networks we recognise the experimental nature of the LISP effort and the open issues that surround the LISP architecture. While we encourage experimentation with new protocols in test networks we don’t think that LISP is ready for prime time.

While Juniper is not backing LISP, we are actively monitoring and evaluating the concerns of Service Providers in this space and we will stay engaged with the industry to evaluate the viability of LISP and suitable alternatives and I will continue to keep an eye on Cisco and their marketing efforts.

This blog first appeared on Juniper Network's blog site, see link.