Routing Bridges (RBridges): Base Protocol Specification
RFC 6325

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    trill mailing list <rbridge@postel.org>, 
    trill chair <trill-chairs@tools.ietf.org>
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 (erik.nordmark@sun.com) is the Document Shepherd.  Ralph

   Droms is the responsible AD.