Wednesday, September 15, 2010

Re: A High-Level overview of LISP

This is a response to Petr's well articulated discussion of LISP: "A High-Level overview of LISP"

He captured some of the key points that make LISP compelling, including the discussions about hierarchical routing (and associated problems with address allocations and multi-homing), the "level of indirection" enabled by LISP - due to the separation of host addresses (EIDs) and routing locators (RLOCs) - and the "push" vs. "pull" aspects of various mapping and routing systems.

There are a several areas that I think deserve greater explanation, however. The most important is regarding the LISP mapping system. "Core routing table size reduction" was the initial focus (and instigation) of LISP. But core routers are not the only ones taking full routes, some people might want the full routing table to be available on more places to have more granular control over egress traffic. Because BGP is a "push" technology, the FIB must be populated with full routes and be available in the "forwarding path" (data plane) of packets. This leads to the need for expensive silicon and memory on each line card. Where LISP helps is in two main areas. First, the LISP ALT routing table is decoupled from expensive forwarding silicon. In a similar manner to DNS, which holds millions of entries in very cheap servers and memory, the LISP mapping system holds EID prefixes in an out-of-band control plane. And like DNS, the forwarding hardware dynamically adds only the necessary EID-to-RLOC mappings on-demand (a "pull" event) when needed. Second, this isn't just "moving the problem" from one BGP table to another. Because EIDs are decoupled from the underlying topology, there is significant opportunity for aggregation in the ALT.

Petr also mentions:

"... re-numbering the core to allow for better aggregation."
Renumbering of the core is not required at all. The core should contain only Provider Assigned addressing, which by definition are highly aggregatable. No renumbering is required whatsoever (and as demonstrated by the fairly extensive LISP network that is in operation today). The core actually has no idea that LISP exists, it's all over-the-top to the core.

Then further on this is mentioned:

"... the requirement of keeping EID space strictly hierarchical in LISP-ALT seriously impacts 'true mobility'."
This is also not the case. There is a significant difference between a home-agent in the control plane (i.e. with LISP) vs. in the data plane (like with Mobile IPv6). Because the mobility event is only updated in the control plane, the map-server doesn't need to change with the move event and a stretch of one can always be maintained. LISP actually provides the mechanisms for true mobility.

Finally, i have to respond to:

"... added complexity for companies at the 'edge' due to the need of renumbering and implementing an overlay topology."
Customers at the "edge" have no need at all to implement the LISP-ALT overlay technology. It's transparent to the end user, as they communicate with the LISP mapping system (ALT) via Map Servers and Map Resolver, basically boxes that are analogous to a DNS resolver. It's that simple. Only the Mapping Service Providers need to deploy ALT infrastructure and maintain the overlay network.

There are many "motivators" for first-adopters of LISP, as we've seen with Facebook, Cisco, and others on the LISP network, including: low OpEx multi-homing, ingress traffic engineering, prefix portability, and IPv6 transition support (not to mention many "private" LISP use-cases)

Thank you Petr, I hope you write more about LISP in the future!