If you put forth even a modest effort to follow technological developments in the networking world, you will no doubt have encountered one or both of these terms recently, but perhaps have not had the time to get up to speed on them. Here's a quick run-down...
Within the context of IP routing, LISP refers not to the programming language, but to the Location and Identity Separation Protocol being developed by Cisco and the IETF. LISP has been developed as a solution to a problem that exists in both IPv4 and IPv6 addressing: a host IP address is overloaded to indicate both the host's unique identity and its location on a network (i.e. the Internet). In other words, an IP address is relied on to signify both who and where you are.
In a strict logically hierarchy, where there is only one path to reach a given address, this works fine, as networks can be efficiently summarized toward the hierarchy root. However, the global Internet has been growing less and less hierarchical for some time as organizations migrate toward multi-provider connectivity, which typically requires provider-independent (PI) address space. PI address space can not be efficiently summarized by upstream providers, which fuels expansion in the global routing table (a bad thing).
To oversimplify, the goal of LISP is to separate the single global IP topology (per IP protocol) into two: one for location and the other for identity. The underlying location topology is used for routing, whereas the identity topology is used to uniquely identify end points, employing logic not unlike that used for tunnel encapsulation. Note that LISP operates only on edge routers; typically, no change is needed on end hosts.
Experimental support for LISP is already available on Cisco ISR and ISR G2 (IOS 15.1(1)XB1) and Nexus (NX-OS 5.0(1.13)) platforms.
- IETF LISP charter and latest protocol draft
- Cisco's LISP documentation
- A High-Level Overview of LISP (Internetwork Expert)
- LISP on Google TechTalks (part 1, part 2, part 3)
Since its inception, an Ethernet LAN has been limited to non-redundant active topologies; in other words, there can be no redundant paths at layer two. This requirement must be met to avoid catastrophic broadcast storms, and the family of spanning tree protocols (IEEE 802.1D and friends) have been the de facto solution for decades. Spanning tree has a significant limitation, however: although redundant links can be brought up in a failure scenario, they cannot be used under normal conditions, and so their potential throughput is wasted.
A new concept, Transparent Interconnection of Lots of Links (TRILL), has been proposed as the successor to spanning tree. TRILL seeks to emulate the routing behavior of layer three networks at layer two using the IS-IS routing protocol. The introduction of link state routing at layer two would support efficient multipath forwarding within an Ethernet LAN.
TRILL is still under heavy development has not been implemented in running code at the time of this writing.
- IETF TRILL charter
- RFC 5556 - TRILL Problem and Applicability Statement
- Setting the stage for TRILL, rethinking data center switching (Brad Hedlund)