While editing Packet Pushers podcast show 155, the topic of what LISP is and does came up. As I was babbling on, I made the comment that LISP is a routing protocol. Russ White quickly points out to me that LISP really isn’t a routing protocol, and he made some salient observations to defend his stance. Having had a chance to reflect on his thoughts, I understand his point.
First off, think at a high level about what a routing protocol does. Perhaps I’m oversimplifying, but a routing protocol computes the best way to reach a particular destination from a particular location. Various metrics influence the computation. In the end, a forwarding path is chosen, and that entry placed into the device’s forwarding information base. Computing a forwarding path based on metrics is not at the core of what LISP accomplishes.
What does LISP do? LISP stands for “Locator/ID Separation Protocol.” Although there’s several use cases built around mobility, I could argue that the main point of LISP is to allow the global Internet routing table to scale by aggregating address blocks into LISP domains. The LISP domain obscures actual endpoint identifying addresses. To talk to the actual host, a lookup against a mapping database directs traffic from one LISP domain to another via ingress and egress tunnel routers that sit at the edge of each LISP domain (or via a proxy ingress tunnel router if source traffic isn’t coming from a LISP domain). Encapsulated traffic traveling between LISP tunnel routers is guided via underlying routing protocols – in the context of the Internet, very probably BGP. In short, LISP moves traffic via tunnels between domains leveraging a globally scalable mapping service. The mapping service is akin to DNS. While there is a weighting or preference concept in the LISP mapping database, that’s nothing like computing path metrics to make a forwarding decision.
LISP is a network architecture and set of protocols that implements a new semantic for IP addressing. In a nutshell: LISP separates the ‘where’ and the ‘who’ in networking and uses a mapping system to couple the location and identifier. – from www.lisp4.net
What made this click for me was when Russ mentioned that LISP was “more like MPLS than BGP.” Ah ha! In MPLS, a label switched path carries traffic through a service provider network. Traffic from one endpoint is tunneled to another endpoint via series of pushed and popped tags that change hop by hop as the packet traverses the service provider network. That LSP might be based on an IGP metric computation, but certainly doesn’t have to be. MPLS traffic engineering allows LSPs to be specifically crafted based on a number of other criteria. The resultant paths aren’t necessarily intuitive from the perspective of an enterprise routing engineer. The larger point is that MPLS is functionally a tunnel (although we argued the nuances of MPLS as tunneling in Packet Pushers show 102), and traffic between the source and destination is obscured as it follows the given LSP. So it is with LISP that source and destination traffic is obscured between LISP domains by the ingress and egress tunnel routers. Instead of following a LSP, LISP packets follow the path of the underlying routing protocols and whatever computations they made.
The point being, LISP isn’t exactly a routing protocol. Once you get a hold of that idea, LISP becomes a little easier to understand.
Extensive LISP Overview – David Meyer
Introduction to LISP – Ivan Pepelnjak
The Path to LISP Isn’t Certain. RFC 6115. – Greg Ferro