Data Center Directions
, Regular Visitor
Data Center Directions
Is There a Real Use Case for LISP, The Locator/ID Separation Protocol?
Dec 24, 2018

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.

Feb 14, 2014
Krunal Shah

I am very surprised to see that you do not see use case for LISP. 


LISP is open and community driven. Cisco has implemented in IOS. There is nothing that prevents Juniper to implement LISP in JUNOS boxes. In fact there is open implementation of LISP on openwrt home router. There is which has code for LISP xTR on FreeBSD based system(eg JUNOS router). Customers might just be asking LISP xTR functionality in JUNOS. So it can be used with a third party mapping service provider (e.g Verisign) to get mapping information. If JUNOS can do GRE encapsulation in hardware it should be able to do LISP encapsulation as well. BTW LISP and GRE is proposed by same guy at IETF. 


Yes, you could argue that LISP is not a standard and there is security issue. But atleast what we want from Juniper is the contribution to community and provide a JUNOS experimental code which doesn't have to supported by JTAC to try LISP and see how can we as community can improve the protocol.


Now some bitter truth, Juniper is not interested in validating and contributing in innovation proposed by its competitor.

Feb 28, 2014



thank you for your comment.  I have checked with my contact in engineering. Juniper is not changing our position on LISP at this time. As I mention in my blog you can do what LISP does with existing tools. It has introduced new security concerns. While we appreciate that there is code available on community sites we can’t just implement that. Code that goes on our devices must go through our engineering and be supported by JTAC to ensure that it won’t impact the performance or security of our devices. We seeing interest in LISP decreasing, not increasing. It is being promoted only by one vendor. At this point we feel that LISP has not delivered on its promise and that it's not in our customers’ best interest to implement it.


As far as cooperating with communities and competitors I think that you know better. Juniper has worked with standards bodies and the community to implement countless protocols on our devices to deliver capabilities that customers need and want. We are on numerous standards committees with our competitors. To name a few there is BGP, MPLS, IP VPNS, EVPN and VxLAN. More recently we have been involved with open source communities and done integration with cloud stacks and IT work flow automation tools and SDN controllers. The thing is that at Juniper we make our own decisions and set our priorities based on what our customers need and what we feel is in their best interests.


We do sometimes change our position when concerns are addressed and it’s in our customers’ interest. I’ll point you to this blog for example, where I discuss how we implemented VxLAN after changes were made to enable control plane management, Enhancing VM Mobility with VxLAN, OVSDB and EVPN


You can also check this blog where I discuss how we have implemented new capabilities that address issues that LISP seeks to address regarding optimal routing for migrated VMs, Optimizing EVPN for Virtual Machine Mobility over the WAN


I hope that this addresses your question,


Regards, Michael

Apr 8, 2014
Mike Allen

Sorry, but I feel that Juniper is missing a huge case for LISP on the WAN.  We have Juniper in our core (recent replacement) and Cisco at our edge, WAN, and access.  We've been using LISP in production to extend virtual network separation (multi-tenancy, whatever you want to call it) to our WAN sites for two years now and it works wonderfully.  No BGP, no MPLS, no GRE, no DMVPN required.  Multicast, TE, load balancing, multi-homing, mobility, security: all built-in.  What does Juniper really have against LISP other than the fact that it was created by Cisco?

Dec 24, 2018
Raspberry Pi

Hi Krunal Shah, I researching on raspberry about LISP, I have some questions need your help, Im really really need you give your mail, I wanna connect with you. My gmail: