[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-trill-clear-correct

TRILL Working Group                                      Donald Eastlake
INTERNET-DRAFT                                              Mingui Zhang
Intended status: Proposed Standard                                Huawei
Updates: 6325, 6327                                       Anoop Ghanwani
                                                                 Brocade
                                                           Ayan Banerjee
                                                                   Cisco
                                                          Vishwas Manral
                                                         Hewlett-Packard
Expires: April 30, 2012                                 October 31, 2011


                RBridges: Clarifications and Corrections
          <draft-eastlake-trill-rbridge-clear-correct-01.txt>


Abstract

   The IETF TRILL (TRansparent Interconnection of Lots of Links)
   standard provides least cost pair-wise data forwarding without
   configuration in multi-hop networks with arbitrary topology, safe
   forwarding even during periods of temporary loops, and support for
   multipathing of both unicast and multicast traffic. TRILL
   accomplishes this by using IS-IS (Intermediate System to Intermediate
   System) link state routing and by encapsulating traffic using a
   header that includes a hop count. Devices that implement TRILL are
   called RBridges.

   Since the TRILL base protocol was approved in March 2010, active
   development of TRILL has revealed corner cases that could use
   clarification and a few errors in the original RFC 6325. RFCs 6327,
   XXXX, and YYYY, provide clarifications with respect to Adjacency,
   Appointed Forwarders, and the TRILL ESADI protocol. This document
   provide other known clarifications and corrections and updates RFC
   6325 and RFC 6327.


Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  Distribution of this document is
   unlimited.  Comments should be sent to the TRILL working group
   mailing list <rbridge@postel.org>.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


D. Eastlake, et al                                              [Page 1]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html















































D. Eastlake, et al                                              [Page 2]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


Table of Contents

      1. Introduction............................................4
      1.1 Terminology and Acronyms...............................4

      2. Overloaded and/or Unreachable RBridges..................5
      2.1 Distribution Tree Roots................................6
      2.2 Overloaded Receipt of TRILL Data Frames................6
      2.3 Overloaded Origination of TRILL Data Frames............6
      2.3.1 Known Unicast Origination............................7
      2.3.2 Multi-Destination Origination........................7

      3. Distribution Tree Updates...............................9
      4. Nickname Selection.....................................10

      5. MTU....................................................12
      5.1 MTU PDU Addressing and Processing.....................12
      5.2 MTU Values............................................12

      6. The CFI / DEI Bit......................................13
      7. Graceful Restart.......................................14
      8. Update to RFC 6327.....................................14

      8. IANA Considerations....................................15
      9. Security Considerations................................15
      Normative References......................................16
      Informative References....................................16

























D. Eastlake, et al                                              [Page 3]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


1. Introduction

   The IETF TRILL (Transparent Interconnection of Lots of Links)
   standard [RFC6325] provides optimal pair-wise data frame forwarding
   without configuration in multi-hop networks with arbitrary topology,
   safe forwarding even during periods of temporary loops, and support
   for multipathing of both unicast and multicast traffic. TRILL
   accomplishes this by using IS-IS (Intermediate System to Intermediate
   System) [IS-IS] [RFC1195] [RFC6326] link state routing and
   encapsulating traffic using a header that includes a hop count. The
   design supports VLANs (Virtual Local Area Networks) and optimization
   of the distribution of multi-destination frames based on VLANs and IP
   derived multicast groups. Devices that implement TRILL are called
   RBridges.

   Since the TRILL base protocol [RFC6325] was approved, the active
   development of TRILL has revealed corner cases that could use
   clarification and a few errors in the original specification document
   [RFC6325]. [RFC6327], [RFCXXXX], and [RFCYYYY], provide
   clarifications with respect to Adjacency, Appointed Forwarders, and
   the TRILL ESADI protocol. This document provide other known
   clarifications and corrections and updates [RFC6325].



1.1 Terminology and Acronyms

   This document uses the acronyms defined in [RFC6325] and the
   following acronyms:

      CFI - Canonical Format Indicator

      DEI - Drop Eligibility Indicator

      OOMF - Overload Originated Multi-destination Frame

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].












D. Eastlake, et al                                              [Page 4]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


2. Overloaded and/or Unreachable RBridges

   RBridges may be in overload as indicated by the [IS-IS] overload flag
   in their LSPs. This means that either (1) they are incapable of
   holding the entire link state database and thus do not have a view on
   the entire topology or (2) they have been configured to have the
   overload bit on. Although networks should be engineered to avoid
   actual link state overload, it might occur if a large campus included
   one or more low-end RBridges.

   It is a common operational practice to set the overload bit in an
   [IS-IS] router (such as an RBridge) when performing maintenance on
   that router that might affect its ability for correctly forward
   frames; this will usually leave the router reachable for maintenance
   traffic but transit traffic will not normally be routed through it.
   (Also, in some cases, TRILL provides for setting the overload bit in
   the pseudo node of a link to stop TRILL Data traffic on an access
   link (see Section 4.9.1 of [RFC6325]).)

   [IS-IS] and TRILL make a reasonable effort to do what they can even
   if some RBridge/routers are in overload. They can do reasonable well
   if a few scattered nodes are in overload. However, actual least cost
   paths are no longer assured if any RBridges are in overload.

   An RBridge in overload cannot be trusted to correctly calculate
   distribution trees or correctly perform the Reverse Path Forwarding
   Check. Therefore, it cannot be trusted to forward multi-destination
   TRILL Data frames. It can only appear as a leaf node in a TRILL
   multi-destination distribution tree.

   Frames are not routed through an overloaded RBridge if any other path
   is available, although they may originate or terminate at an
   overloaded RBridge. In addition, TRILL will not route frames over
   links with cost 2**24 - 1; such links are reserved for traffic
   engineered frames the handling of which is beyond the scope of this
   document.

   As a result, a portion of the campus may be unreachable for TRILL
   Data because all paths to it would be through a link with cost 2**24
   - 1. For example, an RBridge RB1 is not reachable by TRILL Data if
   all of its neighbors are connected to RB1 by links with cost 2**24 -
   1. Such RBridges are called "data unreachable".

   The link state database at an RBridge RB1 can also contain
   information on RBridges that are unreachable by IS-IS link state
   flooding due to link or RBridge failures. When such failures
   partition the campus, the RBridges adjacent to the failure and on the
   same side of the failure as RB1 will update their LSPs to show the
   lack of connectivity and RB1 will receive those updates. However,
   LSPs held by RB1 for RBridges on the far side of the failure will not


D. Eastlake, et al                                              [Page 5]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


   be updated and may stay around until they time out, which could be
   tens of seconds or longer. Since a link is only usable if both ends
   declare it up in their LSP, RB1 will be aware of the partition and
   will know about the unreachability of nodes on the far side of the
   failure. Such nodes are both IS-IS unreachable and data unreachable.



2.1 Distribution Tree Roots

   When an RBridge determines what nicknames to use as the roots of the
   distribution trees it calculates, it MUST ignore all nicknames held
   by RBridges that are in overload or are data unreachable.  When
   calculating Reverse Path Forwarding checks for multi-destination
   frames, an RBridge RB1 can similarly ignore any trees that cannot
   reach to RB1 even if other RBridges list those trees as trees those
   other RBridges might use. (But see Section 3.)



2.2 Overloaded Receipt of TRILL Data Frames

   An RBridge in overload, RB2, will not normally receive unicast TRILL
   Data frames unless it is the egress, in which case it processes the
   frame normally.

   If RB2 receives a unicast TRILL Data frame for which it is not the
   egress, perhaps because a neighbor does not yet know it is in
   overload, it decrements the Hop Count as usual and discards the frame
   if the Hop Count is zero or the egress nickname is illegal. It SHOULD
   NOT discard the frame because the egress nickname is unknown as it
   might now know about all nicknames due to overload. If any neighbor,
   other than the neighbor from which it received the frame, is not
   overloaded it MUST attempt to forward the frame to one of those
   neighbors.

   If RB2 in overload receives a multi-destination TRILL Data frame, RB2
   performs the usual Hop Count processing but MUST NOT apply a Reverse
   Path Forwarding Check since, due to overload, it might not do so
   correctly. RB2 egresses and delivers the frame locally as appropriate
   but RB2 MUST NOT forward it (except as an egressed native frame where
   RB2 is appointed forwarder).



2.3 Overloaded Origination of TRILL Data Frames

   Overloaded origination of unicast frames with know egress and of
   multi-destination frames are discussed in the subsections below.



D. Eastlake, et al                                              [Page 6]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


2.3.1 Known Unicast Origination

   When an overloaded RBridge RB2 ingresses or creates a known
   destination unicast TRILL Data frame, it delivers it locally if the
   destination MAC is local.  Otherwise RB2 link unicasts it to any
   neighbor RBridge that is not overloaded.



2.3.2 Multi-Destination Origination

   RB2 ingressing or creating a multi-destination TRILL Data frame is
   more complex than for a known unicast frame.

   RB2 would like to hand multi-destination frames it is originating to
   a neighbor RB3 such that that (1) RB3 is not overloaded, (2) RB3 will
   distribute the frame on a tree in which RB2 is a leaf node from RB3,
   and (3) where RB3 will know not to send a copy back to RB2. In the
   absence of criteria 2 and 3, RB2 would received a duplicate copy
   back, which might be confusing. Criteria 2 should not be a problem as
   RBridges in overload can only be leaf nodes for any TRILL
   distribution tree.

   Neighbors of RB2 that meet the criteria and are willing to accept
   such frames advertise this in the TRILL Neighbor TLV in their TRILL
   Hellos by setting a bit associated with the SNPA (MAC address) of RB2
   on the link. (See Section 6.) If no neighbor of RB2 that is not in
   overload offers such service, then RB2 cannot originate multi-
   destination TRILL Data frames, although it can still receive them.

   If RB2 sees this OOMF (Overloaded Origination of Multi-destination
   Frame) service advertised by any of its neighbors on any link to
   which RB2 connects, it selects one such neighbor by a means beyond
   the scope of this document. Assuming RB2 selects RB3 to handle multi-
   destination frames it originates. RB2 MUST advertise in its LSP that
   it might use any of the distribution trees that RB3 advertises it
   might use so that the Reverse Path Forwarding Check will work in the
   rest of the campus.

   RB2 then encapsulates such frames as TRILL data frames to RB3 as
   follows: M bit = 1, Hop Count = 2, ingress nickname = a nickname held
   by RB2, and, since RB2 cannot tell what distribution tree RB3 will
   use, egress nickname = a special nickname indicating an OOMF (see
   Section 6). RB2 then link unicasts this TRILL Data frame to RB3.

   On receipt of such a frame, RB3 does the following:

   -  change the egress nickname field to designate a distribution tree
      that RB3 normally uses for which RB2 is a leaf from RB3 (if there
      is no such tree, RB3 MUST NOT offer the OOMF service to RB2),


D. Eastlake, et al                                              [Page 7]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


   -  change the Hop Count to the value it would normally use if it were
      the ingress, and
   -  forward the frame on that tree except that it MUST NOT send a copy
      back to RB2.

   RB3 MAY rate limit the number of frames for which it is providing
   this service by discarding some such frame from RB2. (The provision
   of even a limited bandwidth for OOMFs by RB3, for example via a slow
   path, may be important to the bootstrapping of services at RB2 or end
   stations connected to RB2.)










































D. Eastlake, et al                                              [Page 8]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


3. Distribution Tree Updates

   When a link state database change causes a change in the distribution
   tree(s), there are several possibilities. If a tree root remains a
   tree root but the tree changes, then local forwarding and RPFC
   entries for that tree should be updated as soon as practical.
   Similarly, if a new nickname becomes a tree root, forwarding and RPFC
   entries for the new tree should be installed as soon as practical.
   However, if a nickname ceases to be a tree root and there is
   sufficient room in local tables, it is RECOMMENDED that forwarding
   and RPFC entries for the former tree be retained so that any frames
   in flight on that tree can still be forwarded.








































D. Eastlake, et al                                              [Page 9]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


4. Nickname Selection

   Nickname selection is covered by Section 3.7.3 of [RFC6325]. However,
   the following should be noted:

   1. The second sentence in the second bullet item in Section 3.7.3 of
      [RFC6325] on page 25 is erroneous and is corrected as follows:

      1.a The occurrence of "IS-IS ID (LAN ID)" is replaced with
          "priority".

       1.b The occurrence of "IS-IS System ID" is replaced with "seven
          byte IS-IS ID (LAN ID)".

      The resulting corrected [RFC6325] sentence reads as follows: "If
      RB1 chooses nickname x, and RB1 discovers, through receipt of an
      LSP for RB2 at any later time, that RB2 has also chosen x, then
      the RBridge or pseudonode with the numerically higher priority
      keeps the nickname, or if there is a tie in priority, the RBridge
      with the numerically higher seven byte IS-IS ID (LAN ID) keeps the
      nickname, and the other RBridge MUST select a new nickname."

   2. In examining the link state database for nickname conflicts,
      nicknames held by IS-IS unreachable RBridges MUST be ignored but
      nicknames held by data unreachable RBridges MUST NOT be ignored.

   3. An RBridge may need to select a new nickname, either initially
      because it has none or because of a conflict. When doing so, the
      RBridge MUST consider as available all nicknames that do not
      appear in its link state database or that appear to be held by IS-
      IS unreachable RBridges; however, it SHOULD give preference to
      selecting new nicknames that do not appear to be held by any
      RBridge in the campus, reachable or unreachable, so as to minimize
      conflicts if IS-IS unreachable RBridges later become reachable.

   4. An RBridge, even after it has acquired a nickname for which there
      appears to be no conflicting claimant, MUST continue to monitor
      for conflicts with the nickname or nicknames it holds. It does so
      by checking in LSPs that should update its link state database for
      any of its nicknames held with higher priority by another RBridge
      that is IS-IS reachable. If it finds such a conflict, it MUST
      select a new nickname. (It is possible to receive an LSP that
      should but does not update the link state databse due to
      overflow.)

   5. In the very unlikely case that an RBridge is unable to obtain a
      nickname because all valid nicknames (0x0001 through 0xFFBF
      inclusive) are in use with higher priority by IS-IS reachable
      RBridges, it will be unable to act as an ingress, egress, or tree
      root but will still be able to function as a transit RBridge. Such


D. Eastlake, et al                                             [Page 10]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


      an RBridge with no valid nickname MUST announce its nickname in
      its LSP as 0x0000. Although it cannot be a tree root, such an
      RBridge is included in every distribution tree computed for the
      campus. It would not be possible to send an RBridge Channel
      message to such an RBridge [Channel].















































D. Eastlake, et al                                             [Page 11]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


5. MTU

   Section 5.1 below corrects an Errata in [RFC6325] and Section 5.2
   clarifies the meaning of various MTU numbers.



5.1 MTU PDU Addressing and Processing

   [RFC6325] in Section 4.3.2 incorrectly states that multi-destination
   MTU-probe and MTU-ack TRILL IS-IS PDUs are sent on Ethernet links
   with the All-RBridges multicast address as the Outer.MacDA. As TRILL
   IS-IS PDUs, when multicast on an Ethernet link, they MUST be sent to
   the All-IS-IS-RBridges multicast address.

   As discussed in [RFC6325] and, in more detail, in [RFC6327], MTU-
   probe and MTU-ack PDUs MAY be unicast; however, Section 4.6 of
   [RFC6325] erroneously does not allow for this possibility. It is
   corrected by replacing item numbered "1" in Section 4.6.2 of
   [RFC6325] with the following quoted text to which RBridges MUST
   conform:

   "1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either All-
       IS-IS-RBridges or the unicast MAC address of the receiving
       RBridge port, the frame is handled as described in Section
       4.6.2.1"

   The reference to "Section 4.6.2.1" in the above quoted text is to
   that Section in [RFC6325].



5.2 MTU Values

   MTU values in TRILL key off the originatingLSPBufferSize TLV. In
   layer 3 IS-IS, this defaults to 1492 bytes and is the maximum
   permitted size of LSPs after the eight byte fixed IS-IS PDU header.
   (This header starts with the 0x83 Intradomain Routeing Protocol
   Discriminator byte and ends with the Maximum Area Addresses byte,
   incluside.) Thus the default LSP size including this header is 1500
   bytes. In TRILL, originatingLSPBufferSize defaults to 1470 bytes,
   allowing 22 bytes of additional headroom to accomodate legacy device
   with, for example, the classic Ethernet maximum MTU.

   More TBD - talk about exact meaning of MTU values for various link
   technologies






D. Eastlake, et al                                             [Page 12]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


6. The CFI / DEI Bit

   In May 2011, the IEEE promulgated [802.1Q-2011] which changes the
   meaning of the bit between the priority and VLAN ID bits in the
   payload of C-VLAN tags. Previously this bit was called the CFI
   (Canonical Format Indicator) bit and had a special meaning in
   connection with IEEE 802.5 (Token Ring) frames. Now, under
   [802.1Q-2011], it is a DEI (Drop Eligibility Indicator) bit, similar
   to that bit in S-VLAN (and B-VLAN) tags where this bit has always
   been a DEI bit.

   The TRILL base protocol specification [RFC6325] assumed, in effect,
   that the link by which end stations are connected to RBridges and the
   virtual link provided by the TRILL Data frame encapsulation are IEEE
   802.3 Ethernet links on which the CFI bit is always zero. Should an
   end station be attached by some other type of link, such as an FDDI
   (Fiber Distributed Data Interface) or Token Ring link, [RFC6325]
   implicitly assumed that such frames would be canonicalized to 802.3
   frames before being ingressed and similarly, on egress, such frames
   would be converted from 802.3 to the appropriate frame type for the
   link. Thus, [RFC6325] required that the CFI bit in the Inner.VLAN
   always be zero.

   However, for RBridges with ports conforming to the change
   incorporated in the IEEE 802.1Q-2011 standard, the bit in the
   Inner.VLAN, now a DEI bit, MUST be set to the DEI value provided by
   the EISS interface on ingressing a native frame.  Similarly, this bit
   MUST be provided to the EISS when transiting or egressing a TRILL
   Data frame. The exact effect on the C-VLAN Outer.VLAN DEI and
   priority bits and whether or not an Outer.VLAN appears at all on the
   wire for output frames depends on output port configuration.

   RBridge campuses with a mixture of ports, some compliant with
   [802.1Q-2011] and some compliant with pre-802.1Q-2011, especially if
   they have actual Token Ring links, may operate incorrectly and may
   corrupt data, just as a bridged LAN with such mixed ports would.
















D. Eastlake, et al                                             [Page 13]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


7. Graceful Restart

   RBridge SHOULD support the features specified in [RFC5306] which
   describes a mechanism for a restarting IS-IS router to signal to its
   neighbors that it is restarting, allowing them to reestablish their
   adjacencies without cycling through the down state, while still
   correctly initiating link state database synchronization.




8. Update to RFC 6327

   [RFC6327] provides for multiple states of the potential adjacency
   between two RBridges. It makes clear that an adjacency is reported in
   LSPs in the "Report" state.  LSP transmission and synchronization,
   however, performed in both the "Two-Way" and "Report" states.



































D. Eastlake, et al                                             [Page 14]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


8. IANA Considerations

   IANA is requested to allocate the previously reserved nickname 0xXXXX
   for use in the TRILL Header egress nickname field to indicate an
   Overload Originated Multi-destination Frame (OOMF).

   IANA is requested to allocate bit TBD (bit 1, the bit adjacent to the
   F bit suggested) from the seven currently reserved (RESV) bits in the
   per neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC6326].
   This bit indicates that the RBridge sending the TRILL Hello will
   provide the OOMF forwarding service described in Section 2.3 to such
   frames originated by the RBridge whose SNPA (MAC address) appears in
   that Neighbor RECORD.



9. Security Considerations

   This memo improves the documentation of the TRILL standard and
   corrects some errors in [RFC6325]. It does not change the security
   considerations of the TRILL base protocol for which see Section 6 of
   [RFC6325].






























D. Eastlake, et al                                             [Page 15]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


Normative References

   [802.1Q-2011] - IEEE 802.1, "IEEE Standard for Local and metropolitan
         area networks - Virtual Bridged Local Area Networks", IEEE Std
         802.1Q-2011, May 2011.

   [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to
         Intermediate System Intra-Domain Routeing Exchange Protocol for
         use in Conjunction with the Protocol for Providing the
         Connectionless-mode Network Service (ISO 8473)", 2002.

   [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
         dual environments", RFC 1195, December 1990.

   [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5306] - Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
         RFC 5306, October 2008.

   [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
         Ghanwani, "Routing Bridges (RBridges): Base Protocol
         Specification", RFC 6325, July 2011.

   [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
         Ghanwani, "Transparent Interconnection of Lots of Links (TRILL)
         Use of IS-IS", RFC 6326, July 2011.

   [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D.,
         and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC
         6327, July 2011.



Informative References

   [Channel] - draft-ietf-trill-rbridge-channel, work in progress.

   [RFCXXXX] - R. Perlman, D. Eastlake, Y. Li, A. Banerjee, H. Fangwei,
         "RBridges: Appointed Forwarders", draft-ietf-trill-rbridge-af,
         in the RFC Editor's queue.

   [RFCYYYY] - H. Zhai, F. Hu, R. Perlman, D. Eastlake, "RBridges: The
         ESADI Protocol", draft-hu-trill-rbridge-esadi, work in
         progress.







D. Eastlake, et al                                             [Page 16]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


Authors' Addresses

   Donald Eastlake
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757 USA

   Phone: +1-508-333-2270
   Email: d3e3e3@gmail.com


   Mingui Zhang
   Huawei Technologies Co.,Ltd
   Huawei Building, No.156 Beiqing Rd.
   Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District,
   Beijing 100095 P.R. China

   Email: zhangmingui@huawei.com


   Anoop Ghanwani
   Brocade
   130 Holger Way
   San Jose, CA 95134 USA

   Phone: +1-408-333-7149
   EMail: anoop@alumni.duke.edu


   Ayan Banerjee
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134 USA

   EMail: ayabaner@cisco.com


   Vishwas Manral
   HP Networking
   19111 Pruneridge Avenue
   Cupertino, CA 95014 USA

   Tel:   +1-408-477-0000
   EMail: vishwas.manral@hp.com








D. Eastlake, et al                                             [Page 17]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


Appendix: Change Record

   This appendix summarizes changes between versions of this draft.

   RFC Editor: Please delete this Appendix before publication.



From -00 to -01

   1. Add Section updating [RFC6327].

   2. Add some material to Section 5.2 on MTUs.

   3. Minor editorial changes.





































D. Eastlake, et al                                             [Page 18]


INTERNET-DRAFT                  RBridges: Clarifications and Corrections


   Copyright and IPR Provisions

      Copyright (c) 2011 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
      (http://trustee.ietf.org/license-info) in effect on the date of
      publication of this document. Please review these documents
      carefully, as they describe your rights and restrictions with
      respect to this document. Code Components extracted from this
      document must include Simplified BSD License text as described in
      Section 4.e of the Trust Legal Provisions and are provided without
      warranty as described in the Simplified BSD License.  The
      definitive version of an IETF Document is that published by, or
      under the auspices of, the IETF. Versions of IETF Documents that
      are published by third parties, including those that are
      translated into other languages, should not be considered to be
      definitive versions of IETF Documents. The definitive version of
      these Legal Provisions is that published by, or under the auspices
      of, the IETF. Versions of these Legal Provisions that are
      published by third parties, including those that are translated
      into other languages, should not be considered to be definitive
      versions of these Legal Provisions.  For the avoidance of doubt,
      each Contributor to the IETF Standards Process licenses each
      Contribution that he or she makes as part of the IETF Standards
      Process to the IETF Trust pursuant to the provisions of RFC 5378.
      No language to the contrary, or terms, conditions or rights that
      differ from or are inconsistent with the rights and licenses
      granted under RFC 5378, shall have any effect and shall be null
      and void, whether published or posted by such Contributor, or
      included with or in such Contribution.




















D. Eastlake, et al                                             [Page 19]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/