Emerging Terminology: LISP and TRILL
By stretch | Thursday, July 15, 2010 at 2:58 a.m. UTC
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)
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Random
July 15, 2010 at 12:11 p.m. UTC
The TRILL idea is very interesting. As far as i can see it can be used instead of using etherchannels in the data centre since it will only come to nexus switches to start with.
The way the normal campus is designed however does not require layer 2 adjacency between end nodes and so switch blocks do not need to be moved to a TRILL way. While data centres do need layer 2 adjacency between their switch blocks due to things like vmotion.
ok sorry now i am just thinking out loud haha.
July 15, 2010 at 2:15 p.m. UTC
Thanks for the short-but-sweet rundown. TRILL = Very interesting. But I LOVE Spanning Tree and PortChannels so much!
July 15, 2010 at 4:26 p.m. UTC
It should be noted that the problem of hierarchy isn't just a PI space problem, but rather a problem of multihoming in general. Even if you use PA space you need to de-aggregate that prefix from the assigning provider in order to receive traffic from that Provider (otherwise the more specific route from the other Provider would always be used).
July 16, 2010 at 1:20 p.m. UTC
MSTP offers in combination with a well-thought-out network design a quite practicable solution of useing the redundant links as an active part of your network. so far no points to the concept of TRILL from my sight of view.
Greetz from germany,
July 17, 2010 at 7:12 p.m. UTC
I would wait and see when TRILL will be available but for now it seems quite glaring
July 21, 2010 at 3:53 p.m. UTC
TRILL would be intresting, i wonder what it could offer that REP doesn't have?
August 4, 2010 at 4:16 p.m. UTC
In the days of Cabletron (I know a long time ago...), Securefast was thought off. Securefast used VLSP(Virtual Link State Protocol?) which is OSPF at layer 2. I personally worked on 100 plus switches meshed together using just VLSP. There are still Networks out there today using Securefast!
It is amazing that this idea has re-surfaced. It just goes to show how bad STP is?
August 11, 2010 at 2:56 p.m. UTC
If you want to know more about TRILL, see the document at https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-protocol/ which was approved as an IETF standard earlier this year. It's a pretty long document but if you just read Section 2 and the first part of Section 1, you will get a good idea of what's gong on in TRILL.
March 5, 2013 at 3:50 p.m. UTC
Oddly enough LISP and TRILL our now competitive technologies. Have you looked at Layer 2 LISP yet?