TRILL Working Group Donald Eastlake INTERNET-DRAFT Mingui Zhang Intended status: Proposed Standard Huawei Updates: 6325 Anoop Ghanwani Brocade Ayan Banerjee Cisco Vishwas Manral Hewlett-Packard Expires: April 23, 2012 October 24, 2011 RBridges: Clarifications and Corrections <draft-eastlake-trill-rbridge-clear-correct-00.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, RFC 6325, was approved, active development of TRILL has revealed corner cases that could use clarification and a few errors in the original RFC. 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. 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. 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 through 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 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 TRILL Data unreachable if all of its neighbors are connected to RB1 by links with cost 2**24 - 1. Such RBridges are 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 be updated and may stay around until they time out, which could be D. Eastlake, et al [Page 5]
INTERNET-DRAFT RBridges: Clarifications and Corrections 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 should similarly ignore any trees that cannot reach to RB1 even if other RBridges list them 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. It MUST then forwards the unicast frame to any neighbor that is not overloaded but SHOULD NOT forward the frame back to the RBridge from which it received it. 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. 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 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. 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 is no problem as RBridges in overload can only be leaf nodes for any TRILL distribution tree. Neighbors of RB2 that 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 will 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. 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 encapsulation 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), - change the Hop Count to the value it would normally use if it were the ingress, and D. Eastlake, et al [Page 7]
INTERNET-DRAFT RBridges: Clarifications and Corrections - 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 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 TRILL 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 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 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. 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 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 an RBridge with no valid nickname MUST announce its nickname in its D. Eastlake, et al [Page 10]
INTERNET-DRAFT RBridges: Clarifications and Corrections 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 TBD - talk about exact meaning of various MTU values 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 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 are 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 RBridge with ports conforming to the change incorporated in the 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. 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. IANA is requested to allocate bit TBD (bit 1, the bit adjacent to the F bit) 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 overload originated multi-destination frame forwarding service described in Section 2.3 to such frames originated by the RBridge whose SNPA (port 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 TBD 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]