Two weeks ago, the Internet Engineering Task Force (IETF) met in Minneapolis, Minnesota. For those unfamiliar with the IETF, it is a volunteer organization made up of networking vendors and customers chartered to write and maintain the standards surrounding the operation of the open Internet. For instance, the Internet Protocol (IP), the Transmission Control Protocol (TSP), and the Border Gateway Protocol (BGP) are all IETF standards. The IETF also works in other areas, as well, such as the Session Initiation Protocol (SIP), and with various cryptographic mechanisms.



One of the interesting technologies currently in work within the IETF is Transparent Interconnection of Lots of Links, or TRILL. The basic premise of TRILL is to replace spanning tree as a mechanism to find loop free trees within layer 2 broadcast domains. So what would you replace spanning tree with? A routing protocol-Intermediate System to Intermediate System (IS-IS), in this case.

Why is this move afoot? Because IS-IS provides some intriguing capabilities within a layer 2 broadcast domain. First, of course, there is a great deal of work going on in the fast reroute space, finding ways to provide IP routed convergence in under 100 milliseconds. Using IS-IS to route traffic within a broadcast domain allows us to apply all of that work to fast layer 2 convergence with almost no work on the protocol side. Using a routing protocol to build forwarding trees within a broadcast domain also allows a great deal of flexibility. For instance, you either route layer 2 traffic, just like you would layer 3 traffic, without the header swaps, of course. You can also use the routing protocol to build a set of loop free trees, and allow the bridges to learn which layer 2 addresses are reachable through each of these trees, as normal layer 2 forwarding does today.



There is a parallel move afoot in the IEEE, with current work going on under the 802.1aq working group. The extensions to IS-IS to support this work is being coordinated so a single set of extensions can be used to support both mechanisms.

If you're interested in finding out more about TRILL, take a look at their IETF working group web page, at At some point, I intend to co-author an article in the Internet Protocol Journal discussing TRILL in greater depth, and discussing the differences between TRILL and the work going on in the 802.1aq arena in IEEE.