Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement
RFC 5556

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

Network Working Group                                           J. Touch
Request for Comments: 5556                                       USC/ISI
Category: Informational                                       R. Perlman
                                                                     Sun
                                                                May 2009

         Transparent Interconnection of Lots of Links (TRILL):
                  Problem and Applicability Statement

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   Current IEEE 802.1 LANs use spanning tree protocols that have a
   number of challenges.  These protocols need to strictly avoid loops,
   even temporary ones, during route propagation, because of the lack of
   header loop detection support.  Routing tends not to take full
   advantage of alternate paths, or even non-overlapping pairwise paths
   (in the case of spanning trees).  This document addresses these
   concerns and suggests applying modern network-layer routing protocols
   at the link layer.  This document assumes that solutions would not
   address issues of scalability beyond that of existing IEEE 802.1
   bridged links, but that a solution would be backward compatible with
   802.1, including hubs, bridges, and their existing plug-and-play
   capabilities.

Touch & Perlman              Informational                      [Page 1]
RFC 5556            TRILL: Problem and Applicability            May 2009

Table of Contents

   1. Introduction ....................................................2
   2. The TRILL Problem ...............................................3
      2.1. Inefficient Paths ..........................................3
      2.2. Multipath Forwarding .......................................5
      2.3. Convergence and Safety .....................................6
      2.4. Stability of IP Multicast Optimization .....................6
      2.5. IEEE 802.1 Bridging Protocols ..............................7
      2.6. Problems Not Addressed .....................................8
   3. Desired Properties of Solutions to TRILL ........................9
      3.1. No Change to Link Capabilities .............................9
      3.2. Zero Configuration and Zero Assumption ....................10
      3.3. Forwarding Loop Mitigation ................................10
      3.4. Spanning Tree Management ..................................11
      3.5. Multiple Attachments ......................................11
      3.6. VLAN Issues ...............................................11
      3.7. Operational Equivalence ...................................12
      3.8. Optimizations .............................................12
      3.9. Internet Architecture Issues ..............................13
   4. Applicability ..................................................13
   5. Security Considerations ........................................14
   6. Acknowledgments ................................................15
   7. Informative References .........................................15

1.  Introduction

   Conventional Ethernet networks -- known in the Internet as Ethernet
   link subnets -- have a number of attractive features, allowing hosts
   and routers to relocate within the subnet without requiring
   renumbering, and supporting automatic configuration.  The basis of
   the simplicity of these subnets is the spanning tree, which although
   simple and elegant, can have substantial limitations.  With spanning
   trees, the bandwidth across the subnet is limited because traffic
   flows over a subset of links forming a single tree -- or, with the
   latest version of the protocol and significant additional
   configuration, over a small number of superimposed trees.  The oldest
   version of the spanning tree protocol can converge slowly when there
   are frequent topology changes.

   The alternative to an Ethernet link subnet is often a network subnet.
   Network subnets can use link-state routing protocols that allow
   traffic to traverse least-cost paths rather than being aggregated on
   a spanning tree backbone, providing higher aggregate capacity and
   more resistance to link failures.  Unfortunately, IP -- the dominant
   network layer technology -- requires that hosts be renumbered when
   relocated in different network subnets, interrupting network (e.g.,