Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement
draft-touch-trill-prob-00
| Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Dr. Joseph D. Touch | ||
| Last updated | 2012-01-05 (Latest revision 2005-11-21) | ||
| Replaced by | draft-ietf-trill-prob | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-trill-prob | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Current Ethernet (802.1) link layers use custom routing protocols that have a number of challenges. The routing protocols need to strictly avoid loops, even temporary loops 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). The convergence of these routing protocols and stability under link changes and failures is also of concern. This document addresses these concerns and suggests that they are related to the need to be able to apply network layer routing (e.g., link state or distance vector) protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing bridged (802.1D) links, but that a solution would be backward compatible with 802.1D, including hubs, bridges, and their existing plug-and-play capabilities. This document is a work in progress; we invite you to participate on the mailing list at http://www.postel.org/rbridge
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)