Routing Bridges (RBridges): Base Protocol Specification
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, trill mailing list <firstname.lastname@example.org>, trill chair <email@example.com> Subject: Protocol Action: 'Rbridges: Base Protocol Specification' to Proposed Standard The IESG has approved the following document: - 'Rbridges: Base Protocol Specification ' <draft-ietf-trill-rbridge-protocol-16.txt> as a Proposed Standard This document is the product of the Transparent Interconnection of Lots of Links Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-16.txt
Technical Summary The TRILL protocol provides optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. It achieves these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count. Devices implementing TRILL are called RBridges or Routing Bridges. RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol. As customer devices, RBridges do not supply provider or provider backbone bridging services but provider or provider backbone bridges may be used to interconnect parts of an RBridge campus. The design supports customer VLANs and optimization of the distribution of multi-destination frames based on VLAN and IP derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows these forwarding tables to be substantially smaller than in conventional customer bridges. Working Group Summary The working group process included two working group last calls (an MTU problem was discovered by an implementor after the first WG last call thus a second last call was done to make sure the MTU changes had sufficient review) as well as the usual review by working group members. In addition, the working group charter required special reviews by IEEE 802.1 and two reviews by independent IETF experts. As the combined result of all of these steps, the document received an unusually thorough review. Document Quality The document is high quality due to the unusually thorough reviews it has been subject to. An earlier version was implemented by Sun Microsystems and the lessons learned were incorporated. Independent IETF experts Dan Romascanu and Bernard Aboba did particularly thorough reviews and their comments were resolved. Several implementations are underway although not publicly announced. Personnel Erik Nordmark (firstname.lastname@example.org) is the Document Shepherd. Ralph Droms is the responsible AD.