summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7180.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7180.txt')
-rw-r--r--doc/rfc/rfc7180.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc7180.txt b/doc/rfc/rfc7180.txt
new file mode 100644
index 0000000..12d2284
--- /dev/null
+++ b/doc/rfc/rfc7180.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Eastlake 3rd
+Request for Comments: 7180 M. Zhang
+Updates: 6325, 6327, 6439 Huawei
+Category: Standards Track A. Ghanwani
+ISSN: 2070-1721 Dell
+ V. Manral
+ Ionos Corp.
+ A. Banerjee
+ Cumulus Networks
+ May 2014
+
+
+ Transparent Interconnection of Lots of Links (TRILL):
+ Clarifications, Corrections, and Updates
+
+Abstract
+
+ The IETF Transparent Interconnection of Lots of Links (TRILL)
+ protocol provides least-cost pair-wise data forwarding without
+ configuration in multi-hop networks with arbitrary topology and link
+ technology, safe forwarding even during periods of temporary loops,
+ and support for multipathing of both unicast and multicast traffic.
+ TRILL accomplishes this by using Intermediate System to Intermediate
+ System (IS-IS) link-state routing and by encapsulating traffic using
+ a header that includes a hop count. Since publication of the TRILL
+ base protocol in July 2011, active development of TRILL has revealed
+ errata in RFC 6325 and some cases that could use clarifications or
+ updates.
+
+ RFCs 6327 and 6439 provide clarifications and updates with respect to
+ adjacency and Appointed Forwarders. This document provides other
+ known clarifications, corrections, and updates to RFCs 6325, 6327,
+ and 6439.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7180.
+
+
+
+
+Eastlake, et al. Standards Track [Page 1]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 2]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Precedence .................................................4
+ 1.2. Changes That Are Not Backward Compatible ...................4
+ 1.3. Terminology and Acronyms ...................................5
+ 2. Overloaded and/or Unreachable RBridges ..........................5
+ 2.1. Reachability ...............................................6
+ 2.2. Distribution Trees .........................................6
+ 2.3. Overloaded Receipt of TRILL Data Frames ....................7
+ 2.3.1. Known Unicast Receipt ...............................7
+ 2.3.2. Multi-Destination Receipt ...........................7
+ 2.4. Overloaded Origination of TRILL Data Frames ................7
+ 2.4.1. Known Unicast Origination ...........................7
+ 2.4.2. Multi-Destination Origination .......................8
+ 2.4.2.1. An Example Network .........................8
+ 2.4.2.2. Indicating OOMF Support ....................9
+ 2.4.2.3. Using OOMF Service .........................9
+ 3. Distribution Trees .............................................10
+ 3.1. Number of Distribution Trees ..............................10
+ 3.2. Clarification of Distribution Tree Updates ................10
+ 3.3. Multicast Pruning Based on IP Address .....................10
+ 3.4. Numbering of Distribution Trees ...........................11
+ 3.5. Link Cost Directionality ..................................11
+ 4. Nickname Selection .............................................11
+ 5. MTU (Maximum Transmission Unit) ................................13
+ 5.1. MTU-Related Errata in RFC 6325 ............................13
+ 5.1.1. MTU PDU Addressing .................................14
+ 5.1.2. MTU PDU Processing .................................14
+ 5.1.3. MTU Testing ........................................14
+ 5.2. Ethernet MTU Values .......................................15
+ 6. Port Modes .....................................................15
+ 7. The CFI/DEI Bit ................................................16
+ 8. Graceful Restart ...............................................17
+ 9. Updates to RFC 6327 ............................................17
+ 10. Updates on Appointed Forwarders and Inhibition ................18
+ 10.1. Optional TRILL Hello Reduction ...........................18
+ 10.2. Overload and Appointed Forwarders ........................20
+ 11. IANA Considerations ...........................................21
+ 12. Security Considerations .......................................21
+ 13. Acknowledgements ..............................................21
+ 14. References ....................................................22
+ 14.1. Normative References .....................................22
+ 14.2. Informative References ...................................23
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 3]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+1. Introduction
+
+ The IETF Transparent Interconnection of Lots of Links (TRILL)
+ protocol [RFC6325] provides optimal pair-wise data frame forwarding
+ without configuration in multi-hop networks with arbitrary topology
+ and link technology, safe forwarding even during periods of temporary
+ loops, and support for multipathing of both unicast and multicast
+ traffic. TRILL accomplishes this by using Intermediate System to
+ Intermediate System (IS-IS) [IS-IS] [RFC1195] [RFC7176] 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.
+
+ In the years since the TRILL base protocol [RFC6325] was published,
+ active development of TRILL has revealed five errors in the
+ specification [RFC6325] and cases that could use clarifications or
+ updates.
+
+ [RFC6327] and [RFC6439] provide clarifications with respect to
+ Adjacency and Appointed Forwarders. This document provides other
+ known clarifications, corrections, and updates to [RFC6325],
+ [RFC6327], and [RFC6439].
+
+1.1. Precedence
+
+ In case of conflict between this document and any of [RFC6325],
+ [RFC6327], or [RFC6439], this document takes precedence. In
+ addition, Section 1.2 (Normative Content and Precedence) of [RFC6325]
+ is updated to provide a more complete precedence ordering of the
+ sections of [RFC6325] as following, where sections to the left take
+ precedence over sections to their right:
+
+ 4 > 3 > 7 > 5 > 2 > 6 > 1
+
+1.2. Changes That Are Not Backward Compatible
+
+ The change made by Section 3.4 below is not backward compatible with
+ [RFC6325] but has nevertheless been adopted to reduce distribution
+ tree changes resulting from topology changes.
+
+ The several other changes herein that are fixes to errata for
+ [RFC6325] -- [Err3002] [Err3003] [Err3004] [Err3052] [Err3053]
+ [Err3508] -- may not be backward compatible with previous
+ implementations that conformed to errors in the specification.
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 4]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+1.3. Terminology and Acronyms
+
+ This document uses the acronyms defined in [RFC6325] and the
+ following acronyms and terms:
+
+ CFI - Canonical Format Indicator [802]
+
+ DEI - Drop Eligibility Indicator [802.1Q-2011]
+
+ EISS - Enhanced Internal Sublayer Service
+
+ OOMF - Overload Originated Multi-destination Frame
+
+ TRILL Switch - An alternative name for an RBridge
+
+ 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].
+
+2. Overloaded and/or Unreachable RBridges
+
+ RBridges may be in overload as indicated by the [IS-IS] overload flag
+ in their LSPs (Link State PDUs). This means that either (1) they are
+ incapable of holding the entire link-state database and thus do not
+ have a view of the entire topology or (2) they have been configured
+ to have the overload bit set. Although networks should be engineered
+ to avoid actual link-state overload, it might occur under various
+ circumstances. For example, if a large campus included one or more
+ low-end TRILL Switches.
+
+ 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 to correctly forward
+ frames; this will usually leave the router reachable for maintenance
+ traffic, but transit traffic will not be routed through it. (Also,
+ in some cases, TRILL provides for setting the overload bit in the
+ pseudonode 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 RBridges/routers are in overload. They can do reasonably
+ well if a few scattered nodes are in overload. However, actual
+ least-cost paths are no longer assured if any RBridges are in
+ overload.
+
+ For the effect of overload on the appointment of forwarders, see
+ Section 10.2.
+
+
+
+Eastlake, et al. Standards Track [Page 5]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+ In this Section 2, the term "neighbor" refers only to actual RBridges
+ and ignores pseudonodes.
+
+2.1. Reachability
+
+ Frames are not least-cost routed through an overloaded TRILL Switch,
+ although they may originate or terminate at an overloaded TRILL
+ Switch. In addition, frames will not be least-cost routed over links
+ with cost 2**24 - 1 [RFC5305]; 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 least-
+ cost routed TRILL Data because all paths to it would be through a
+ link with cost 2**24 - 1 or through an overloaded RBridge. 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 TRILL Switches that are unreachable by IS-IS link-
+ state flooding due to link or RBridge failures. When such failures
+ partition the campus, the TRILL Switches 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. As a
+ result, RB1 will be aware of the partition. Nodes on the far side of
+ the partition are both IS-IS unreachable and data unreachable.
+ However, LSPs held by RB1 for TRILL Switches on the far side of the
+ failure will not be updated and may stay around until they time out,
+ which could be tens of minutes or longer. (The default in [IS-IS] is
+ twenty minutes.)
+
+2.2. Distribution Trees
+
+ An RBridge in overload cannot be trusted to correctly calculate
+ distribution trees or correctly perform the RPFC (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. Furthermore, if all the
+ immediate neighbors of an RBridge are overloaded, then it is omitted
+ from all trees in the campus and is unreachable by multi-destination
+ frames.
+
+ When an RBridge determines what nicknames to use as the roots of the
+ distribution trees it calculates, it MUST ignore all nicknames held
+ by TRILL Switches that are in overload or are data unreachable. When
+ calculating RPFCs for multi-destination frames, an RBridge RB1 MAY,
+ to avoid calculating unnecessary RPF check state, ignore any trees
+
+
+
+Eastlake, et al. Standards Track [Page 6]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+ that cannot reach to RB1 even if other RBridges list those trees as
+ trees that other TRILL Switches might use. (But see Section 3.)
+
+2.3. Overloaded Receipt of TRILL Data Frames
+
+ The receipt of TRILL Data frames by overloaded RBridge RB2 is
+ discussed in the subsections below. In all cases, the normal Hop
+ Count decrement is performed, and the TRILL Data frame is discarded
+ if the result is less than one or if the egress nickname is illegal.
+
+2.3.1. Known Unicast Receipt
+
+ RB2 will not usually receive unicast TRILL Data frames unless it is
+ the egress, in which case it decapsulates and delivers the frames
+ 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, RB2 MUST NOT discard the frame because the egress is an
+ unknown nickname as it might not know about all nicknames due to its
+ overloaded condition. 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 there is no such
+ neighbor, the frame is discarded.
+
+2.3.2. Multi-Destination Receipt
+
+ If RB2 in overload receives a multi-destination TRILL Data frame, RB2
+ MUST NOT apply an RPFC since, due to overload, it might not do so
+ correctly. RB2 decapsulates and delivers the frame locally where it
+ is Appointed Forwarder for the frame's VLAN, subject to any multicast
+ pruning. But since, as stated above, RB2 can only be the leaf of a
+ distribution tree, it MUST NOT forward a multi-destination TRILL Data
+ frame (except as an egressed native frame where RB2 is Appointed
+ Forwarder).
+
+2.4. Overloaded Origination of TRILL Data Frames
+
+ Overloaded origination of unicast frames with known egress and of
+ multi-destination frames are discussed in the subsections below.
+
+2.4.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 Media Access Control (MAC) is local. Otherwise, RB2
+ unicasts it to any neighbor TRILL Switch that is not overloaded. It
+ MAY use what routing information it has to help select the neighbor.
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 7]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+2.4.2. Multi-Destination Origination
+
+ Overloaded RBridge RB2 ingressing or creating a multi-destination
+ TRILL Data frame is more complex than for a known unicast frame.
+
+2.4.2.1. An Example Network
+
+ For example, consider the network below in which, for simplicity, end
+ stations and any bridges are not shown. There is one distribution
+ tree of which RB4 is the root; it is represented by double lines.
+ Only RBridge RB2 is overloaded.
+
+ +-----+ +-----+ +-----+ +-----+
+ | RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 |
+ +-----+ +--+--+ +-++--+ +--+--|
+ | || |
+ +---+---+ || |
+ +------+RB2(ov)|======++ |
+ | +-------+ || |
+ | || |
+ +--+--+ +-----+ ++==++=++ +--+--+
+ | RB8 +=====+ RB6 +==++ RB4 ++=====+ RB9 |
+ +-----+ +-----+ ++=====++ +-----+
+
+ Since RB2 is overloaded, it does not know what the distribution tree
+ or trees are for the network. Thus, there is no way it can provide
+ normal TRILL Data encapsulation for multi-destination native frames.
+ So RB2 tunnels the frame to a neighbor that is not overloaded if it
+ has such a neighbor that has signaled that it is willing to offer
+ this service. RBridges indicate this in their Hellos as described
+ below. This service is called OOMF (Overload Originated Multi-
+ destination Frame) service.
+
+ - The multi-destination frame MUST NOT be locally distributed in
+ native form at RB2 before tunneling to a neighbor because this
+ would cause the frame to be delivered twice. For example, if RB2
+ locally distributed a multicast native frame and then tunneled it
+ to RB5, RB2 would get a copy of the frame when RB3 transmitted it
+ as a TRILL Data frame on the multi-access RB2-RB3-RB4 link. Since
+ RB2 would, in general, not be able to tell that this was a frame
+ it had tunneled for distribution, RB2 would decapsulate it and
+ locally distribute it a second time.
+
+ - On the other hand, if there is no neighbor of RB2 offering RB2 the
+ OOMF service, RB2 cannot tunnel the frame to a neighbor. In this
+ case, RB2 MUST locally distribute the frame where it is Appointed
+ Forwarder for the frame's VLAN and optionally subject to multicast
+ pruning.
+
+
+
+Eastlake, et al. Standards Track [Page 8]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+2.4.2.2. Indicating OOMF Support
+
+ An RBridge RB3 indicates its willingness to offer the OOMF service to
+ RB2 in the TRILL Neighbor TLV in RB3's TRILL Hellos by setting a bit
+ associated with the SNPA (Subnetwork Point of Attachment, also known
+ as MAC address) of RB2 on the link. (See Section 11.) Overloaded
+ RBridge RB2 can only distribute multi-destination TRILL Data frames
+ to the campus if a neighbor of RB2 not in overload offers RB2 the
+ OOMF service. If RB2 does not have OOMF service available to it, RB2
+ can still receive multi-destination frames from non-overloaded
+ neighbors and, if RB2 should originate or ingress such a frame, it
+ distributes it locally in native form.
+
+2.4.2.3. Using OOMF Service
+
+ If RB2 sees this OOMF (Overload Originated Multi-destination Frame)
+ service advertised for it 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
+ so that the RPFC will work in the rest of the campus. Thus,
+ notwithstanding its overloaded state, RB2 MUST retain this
+ information from RB3 LSPs, which it will receive as it is directly
+ connected to RB3.
+
+ RB2 then encapsulates such frames as TRILL Data frames to RB3 as
+ follows: M bit = 0, 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 frame
+ (see Section 11). RB2 then unicasts this TRILL Data frame to RB3.
+ (Implementation of Item 4 in Section 4 below provides reasonable
+ assurance that, notwithstanding its overloaded state, the ingress
+ nickname used by RB2 will be unique within at least the portion of
+ the campus that is IS-IS reachable from RB2.)
+
+ On receipt of such a frame, RB3 does the following:
+
+ - changes the Egress Nickname field to designate a distribution tree
+ that RB3 normally uses,
+ - sets the M bit to one,
+ - changes the Hop Count to the value it would normally use if it
+ were the ingress, and
+ - forwards the frame on that tree.
+
+ RB3 MAY rate limit the number of frames for which it is providing
+ this service by discarding some such frames from RB2. The provision
+ of even limited bandwidth for OOMFs by RB3, perhaps via the slow
+
+
+
+Eastlake, et al. Standards Track [Page 9]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+ path, may be important to the bootstrapping of services at RB2 or at
+ end stations connected to RB2, such as supporting DHCP and ARP/ND
+ (Address Resolution Protocol / Neighbor Discovery). (Everyone
+ sometimes needs a little OOMF (pronounced "oomph") to get off the
+ ground.)
+
+3. Distribution Trees
+
+ Two corrections, a clarification, and two updates related to
+ distribution trees appear in the subsections below. See also
+ Section 2.2.
+
+3.1. Number of Distribution Trees
+
+ In [RFC6325], Section 4.5.2, page 56, Point 2, 4th paragraph, the
+ parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052].
+ It should read "(up to k if j is zero or the minimum of (j, k) if j
+ is non-zero)".
+
+3.2. Clarification of 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, the forwarding and RPFC entries for
+ the former tree MAY be retained so that any multi-destination TRILL
+ Data frames already in flight on that tree have a higher probability
+ of being delivered.
+
+3.3. Multicast Pruning Based on IP Address
+
+ The TRILL base protocol specification [RFC6325] provides for and
+ recommends the pruning of multi-destination frame distribution trees
+ based on the location of IP multicast routers and listeners; however,
+ multicast listening is identified by derived MAC addresses as
+ communicated in the Group MAC Address sub-TLV [RFC7176].
+
+ TRILL Switches MAY communicate multicast listeners and prune
+ distribution trees based on the actual IPv4 or IPv6 multicast
+ addresses involved. Additional Group Address sub-TLVs are provided
+ in [RFC7176] to carry this information. A TRILL Switch that is only
+ capable of pruning based on derived MAC address SHOULD calculate and
+ use such derived MAC addresses from multicast listener IPv4/IPv6
+ address information it receives.
+
+
+
+Eastlake, et al. Standards Track [Page 10]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+3.4. Numbering of Distribution Trees
+
+ Section 4.5.1 of [RFC6325] specifies that, when building distribution
+ tree number j, node (RBridge) N that has multiple possible parents in
+ the tree is attached to possible parent number j mod p. Trees are
+ numbered starting with 1, but possible parents are numbered starting
+ with 0. As a result, if there are two trees and two possible
+ parents, in tree 1, parent 1 will be selected, and in tree 2, parent
+ 0 will be selected.
+
+ This is changed so that the selected parent MUST be (j-1) mod p. As
+ a result, in the case above, tree 1 will select parent 0, and tree 2
+ will select parent 1. This change is not backward compatible with
+ [RFC6325]. If all RBridges in a campus do not determine distribution
+ trees in the same way, then for most topologies, the RPFC will drop
+ many multi-destination frames before they have been properly
+ delivered.
+
+3.5. Link Cost Directionality
+
+ Distribution tree construction, like other least-cost aspects of
+ TRILL, works even if link costs are asymmetric, so the cost of the
+ hop from RB1 to RB2 is different from the cost of the hop from RB2 to
+ RB1. However, it is essential that all RBridges calculate the same
+ distribution trees, and thus, all must either use the cost away from
+ the tree root or the cost towards the tree root. As corrected in
+ [Err3508], the text in Section 4.5.1 of [RFC6325] is incorrect. It
+ says:
+
+ In other words, the set of potential parents for N, for the tree
+ rooted at R, consists of those that give equally minimal cost
+ paths from N to R and ...
+
+ but the text should say "from R to N":
+
+ In other words, the set of potential parents for N, for the tree
+ rooted at R, consists of those that give equally minimal cost
+ paths from R to N and ...
+
+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 [Err3002] and is corrected as
+ follows:
+
+
+
+
+Eastlake, et al. Standards Track [Page 11]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+ o The occurrence of "IS-IS ID (LAN ID)" is replaced with
+ "priority".
+
+ o The occurrence of "IS-IS System ID" is replaced with "seven-
+ byte IS-IS ID (LAN ID)".
+
+ The resulting corrected sentence in [RFC6325] 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 TRILL Switches MUST be
+ ignored, but nicknames held by IS-IS reachable TRILL Switches
+ MUST NOT be ignored even if they are data unreachable.
+
+ 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 TRILL Switches; however, it SHOULD give
+ preference to selecting new nicknames that do not appear to be
+ held by any TRILL Switch in the campus, reachable or unreachable,
+ so as to minimize conflicts if IS-IS unreachable TRILL Switches
+ 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 LSP PDUs it receives that should update its
+ link-state database for the following: any occurrence of any of
+ its nicknames held with higher priority by some other TRILL
+ Switch that is IS-IS reachable from it. If it finds such a
+ conflict, it MUST select a new nickname, even when in overloaded
+ state. (It is possible to receive an LSP that should update the
+ link-state database but does not due to overload.)
+
+ 5. In the very unlikely case that an RBridge is unable to obtain a
+ nickname because all valid RBridge nicknames (0x0001 through
+ 0xFFBF inclusive) are in use with higher priority by IS-IS
+ reachable TRILL Switches, it will be unable to act as an ingress,
+ egress, or tree root but will still be able to function as a
+ transit TRILL Switch. Although it cannot be a tree root, such an
+
+
+
+Eastlake, et al. Standards Track [Page 12]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+ RBridge is included in distribution trees computed for the campus
+ unless all its neighbors are overloaded. It would not be
+ possible to send a unicast RBridge Channel message specifically
+ to such a TRILL Switch [RFC7178]; however, it will receive
+ unicast Channel messages sent by a neighbor to the Any-RBridge
+ egress nickname and will receive appropriate multi-destination
+ Channel messages.
+
+5. MTU (Maximum Transmission Unit)
+
+ MTU values in TRILL key off the originatingL1LSPBufferSize value
+ communicated in the IS-IS originatingLSPBufferSize TLV [IS-IS]. The
+ campus-wide value Sz, as described in Section 4.3.1 of [RFC6325], is
+ the minimum value of originatingL1LSPBufferSize for the RBridges in a
+ campus, but not less than 1470. The MTU testing mechanism and
+ limiting LSPs to Sz assures that the LSPs can be flooded by IS-IS and
+ thus that IS-IS can operate properly.
+
+ If nothing is known about the MTU of the links or the
+ originatingL1LSPBufferSize of other RBridges in a campus, the
+ originatingL1LSPBufferSize for an RBridge should default to the
+ minimum of the LSP size that its TRILL IS-IS software can handle and
+ the minimum MTU of the ports that it might use to receive or transmit
+ LSPs. If an RBridge does have knowledge of link MTUs or other
+ RBridge originatingL1LSPBufferSize, then, to avoid the necessity to
+ regenerate the local LSPs using a different maximum size, the
+ RBridge's originatingL1LSPBufferSize SHOULD be configured to the
+ minimum of (1) the smallest value that other RBridges are or will be
+ announcing as their originatingL1LSPBufferSize and (2) a value small
+ enough that the campus will not partition due to a significant number
+ of links with limited MTU. However, as provided in [RFC6325], in no
+ case can originatingL1LSPBufferSize be less than 1470. In a well-
+ configured campus, to minimize any LSP regeneration due to re-sizing,
+ it is desirable for all RBridges to be configured with the same
+ originatingL1LSPBufferSize.
+
+ Section 5.1 below corrects errata in [RFC6325], and Section 5.2
+ clarifies the meaning of various MTU limits for TRILL Ethernet links.
+
+5.1. MTU-Related Errata in RFC 6325
+
+ Three MTU-related errata in [RFC6325] are corrected in the
+ subsections below.
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 13]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+5.1.1. MTU PDU Addressing
+
+ Section 4.3.2 of [RFC6325] 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 [Err3004].
+ As TRILL IS-IS PDUs, when multicast on an Ethernet link, they MUST be
+ sent to the All-IS-IS-RBridges multicast address.
+
+5.1.2. MTU PDU Processing
+
+ 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 [Err3003].
+ It is corrected by replacing Item numbered "1" in Section 4.6.2 of
+ [RFC6325] with the following quoted text to which TRILL Switches 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.1.3. MTU Testing
+
+ The last two sentences of Section 4.3.2 of [RFC6325] have errors
+ [Err3053]. They currently read:
+
+ If X is not greater than Sz, then RB1 sets the "failed minimum MTU
+ test" flag for RB2 in RB1's Hello. If size X succeeds, and X >
+ Sz, then RB1 advertises the largest tested X for each adjacency in
+ the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X
+ as an attribute of the link to RB2 in RB1's LSP.
+
+ They should read:
+
+ If X is not greater than or equal to Sz, then RB1 sets the "failed
+ minimum MTU test" flag for RB2 in RB1's Hello. If size X
+ succeeds, and X >= Sz, then RB1 advertises the largest tested X
+ for each adjacency in the TRILL Hellos RB1 sends on that link, and
+ RB1 MAY advertise X as an attribute of the link to RB2 in RB1's
+ LSP.
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 14]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+5.2. Ethernet MTU Values
+
+ originatingL1LSPBufferSize is the maximum permitted size of LSPs
+ starting with the 0x83 Intradomain Routeing Protocol Discriminator
+ byte. In Layer 3 IS-IS, originatingL1LSPBufferSize defaults to 1492
+ bytes. (This is because, in its previous life as DECnet Phase V,
+ IS-IS was encoded using the SNAP SAP (Subnetwork Access Protocol
+ Service Access Point) [RFC7042] format, which takes 8 bytes of
+ overhead and 1492 + 8 = 1500, the classic Ethernet maximum. When
+ standardized by ISO/IEC [IS-IS] to use Logical Link Control (LLC)
+ encoding, this default could have been increased by a few bytes but
+ was not.)
+
+ In TRILL, originatingL1LSPBufferSize defaults to 1470 bytes. This
+ allows 27 bytes of headroom or safety margin to accommodate legacy
+ devices with the classic Ethernet maximum MTU despite headers such as
+ an Outer.VLAN.
+
+ Assuming the campus-wide minimum link MTU is Sz, RBridges on Ethernet
+ links MUST limit most TRILL IS-IS PDUs so that PDUz (the length of
+ the PDU starting just after the L2-IS-IS Ethertype and ending just
+ before the Ethernet Frame Check Sequence (FCS)) does not to exceed
+ Sz. The PDU exceptions are TRILL Hello PDUs, which MUST NOT exceed
+ 1470 bytes, and MTU-probe and MTU-ack PDUs that are padded, depending
+ on the size being tested (which may exceed Sz).
+
+ Sz does not limit TRILL Data frames. They are only limited by the
+ MTU of the devices and links that they actually pass through;
+ however, links that can accommodate IS-IS PDUs up to Sz would
+ accommodate, with a generous safety margin, TRILL Data frame payloads
+ of (Sz - 24) bytes, starting after the Inner.VLAN and ending just
+ before the FCS. Most modern Ethernet equipment has ample headroom
+ for frames with extensive headers and is sometimes engineered to
+ accommodate 9K byte jumbo frames.
+
+6. Port Modes
+
+ Section 4.9.1 of [RFC6325] specifies four mode bits for RBridge ports
+ but may not be completely clear on the effects of various
+ combinations of bits.
+
+ The table below explicitly indicates the effect of all possible
+ combinations of the TRILL port mode bits. "*" in one of the first
+ four columns indicates that the bit can be either zero or one. The
+ following columns indicate allowed frame types. The Disable bit
+ normally disables all frames, but, as an implementation choice, some
+ or all low-level Layer 2 control frames (as specified in [RFC6325],
+ Section 1.4) can still be sent or received.
+
+
+
+Eastlake, et al. Standards Track [Page 15]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+ +-+-+-+-+--------+-------+-----+-----+-----+
+ |D| | | | | | | | |
+ |i| |A| | | |TRILL| | |
+ |s| |c|T| | |Data | | |
+ |a| |c|r| | | | | |
+ |b|P|e|u| |native | LSP | | |
+ |l|2|s|n|Layer 2 |ingress| SNP |TRILL| P2P |
+ |e|P|s|k|Control |egress | MTU |Hello|Hello|
+ +-+-+-+-+--------+-------+-----+-----+-----+
+ |0|0|0|0| Yes | Yes | Yes | Yes | No |
+ +-+-+-+-+--------+-------+-----+-----+-----+
+ |0|0|0|1| Yes | No | Yes | Yes | No |
+ +-+-+-+-+--------+-------+-----+-----+-----+
+ |0|0|1|0| Yes | Yes | No | Yes | No |
+ +-+-+-+-+--------+-------+-----+-----+-----+
+ |0|0|1|1| Yes | No | No | Yes | No |
+ +-+-+-+-+--------+-------+-----+-----+-----+
+ |0|1|0|*| Yes | No | Yes | No | Yes |
+ +-+-+-+-+--------+-------+-----+-----+-----+
+ |0|1|1|*| Yes | No | No | No | Yes |
+ +-+-+-+-+--------+-------+-----+-----+-----+
+ |1|*|*|*|Optional| No | No | No | No |
+ +-+-+-+-+--------+-------+-----+-----+-----+
+
+ (The formal name of the "access bit" is the "TRILL traffic disable
+ bit", and the formal name of the "trunk bit" is the "end-station
+ service disable bit" [RFC6325].)
+
+7. 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 [802] 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/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 TRILL Switches
+ and the restricted virtual link provided by the TRILL Data frame 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
+ a 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
+
+
+
+Eastlake, et al. Standards Track [Page 16]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+ that the CFI bit in the Inner.VLAN, which is shown as the "C" bit in
+ Section 4.1.1 of [RFC6325], always be zero.
+
+ However, for TRILL Switches 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 (Enhanced Internal Sublayer Service) interface on ingressing
+ a native frame. Similarly, this bit MUST be provided to the EISS
+ when transiting or egressing a TRILL Data frame. As with the 3-bit
+ Priority field, the DEI bit to use in forwarding a transit frame MUST
+ be taken from the Inner.VLAN. The exact effect on the Outer.VLAN DEI
+ and priority bits and whether or not an Outer.VLAN appears at all on
+ the wire for output frames may depend on output port configuration.
+
+ TRILL campuses with a mixture of ports, some compliant with
+ [802.1Q-2011] and some compliant with pre-802.1Q-2011 standards,
+ especially if they have actual Token Ring links, may operate
+ incorrectly and may corrupt data, just as a bridged LAN with such
+ mixed ports and links would.
+
+8. Graceful Restart
+
+ TRILL Switches 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.
+
+9. Updates to RFC 6327
+
+ [RFC6327] provides for multiple states of the potential adjacency
+ between two TRILL Switches. It makes clear that only an adjacency in
+ the "Report" state is reported in LSPs. LSP synchronization (LSP and
+ Subnetwork Point (SNP) transmission and receipt), however, is
+ performed if and only if there is at least one adjacency on the link
+ in either the "2-Way" or "Report" state.
+
+ To support the PORT-TRILL-VER sub-TLV specified in [RFC7176], the
+ following updates are made to [RFC6327]:
+
+ 1. The first sentence of the last paragraph in [RFC6327] Section 3.1
+ is modified from
+
+ All TRILL LAN Hellos issued by an RBridge on a particular port
+ MUST have the same source MAC address, priority, desired
+ Designated VLAN, and Port ID, regardless of the VLAN in which
+ the Hello is sent.
+
+
+
+
+Eastlake, et al. Standards Track [Page 17]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+ to
+
+ All TRILL LAN Hellos issued by an RBridge on a particular port
+ MUST have the same source MAC address, priority, desired
+ Designated VLAN, Port ID, and PORT-TRILL-VER sub-TLV [RFC7176]
+ if included, regardless of the VLAN in which the Hello is
+ sent.
+
+ 2. An additional bullet item is added to the end of Section 3.2 of
+ [RFC6327] as follows:
+
+ o The five bytes of PORT-TRILL-VER sub-TLV data received in the
+ most recent TRILL Hello from the neighbor RBridge.
+
+ 3. In Section 3.3 of [RFC6327], near the bottom of page 12, a bullet
+ item as follows is added:
+
+ o The five bytes of PORT-TRILL-VER sub-TLV data are set from
+ that sub-TLV in the Hello or set to zero if that sub-TLV does
+ not occur in the Hello.
+
+ 4. At the beginning of Section 4 of [RFC6327], a bullet item is
+ added to the list as follows:
+
+ o The five bytes of PORT-TRILL-VER sub-TLV data used in TRILL
+ Hellos sent on the port.
+
+10. Updates on Appointed Forwarders and Inhibition
+
+ An optional method of Hello reduction is specified in Section 10.1
+ below and a recommendation on forwarder appointments in the face of
+ overload is given in Section 10.2.
+
+10.1. Optional TRILL Hello Reduction
+
+ If a network manager has sufficient confidence that it knows the
+ configuration of bridges, ports, and the like, within a link, it may
+ be able to reduce the number of TRILL Hellos sent on that link; for
+ example, if all RBridges on the link will see all Hellos regardless
+ of VLAN constraints, Hellos could be sent on fewer VLANs. However,
+ because adjacencies are established in the Designated VLAN, an
+ RBridge MUST always attempt to send Hellos in the Designated VLAN.
+ Hello reduction makes TRILL less robust in the face of decreased VLAN
+ connectivity in a link such as partitioned VLANs, many VLANs disabled
+ on ports, or disagreement over the Designated VLAN; however, as long
+ as all RBridge ports on the link are configured for the same desired
+ Designated VLAN, can see each other's frames in that VLAN, and
+ utilize the mechanisms specified below to update VLAN inhibition
+
+
+
+Eastlake, et al. Standards Track [Page 18]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+ timers, operations will be safe. (These considerations do not arise
+ on links between RBridges that are configured as point-to-point
+ since, in that case, each RBridge sends point-to-point Hellos, other
+ TRILL IS-IS PDUs, and TRILL Data frames only in what it believes to
+ be the Designated VLAN of the link and no native frame end-station
+ service is provided.)
+
+ The provision for a configurable set of "Announcing VLANs", as
+ described in Section 4.4.3 of [RFC6325], provides a mechanism in the
+ TRILL base protocol for a reduction in TRILL Hellos.
+
+ To maintain loop safety in the face of occasional lost frames,
+ RBridge failures, link failures, new RBridges coming up on a link,
+ and the like, the inhibition mechanism specified in [RFC6439] is
+ still required. Under Section 3 of [RFC6439], a VLAN inhibition
+ timer can only be set by the receipt of a Hello sent or received in
+ that VLAN. Thus, to safely send a reduced number of TRILL Hellos on
+ a reduced number of VLANs requires additional mechanisms to set the
+ VLAN inhibition timers at an RBridge, thus extending Section 3, Item
+ 4, of [RFC6439]. Two such mechanisms are specified below. Support
+ for both of these mechanisms is indicated by a capability bit in the
+ PORT-TRILL-VER sub-TLV (see Section 9 above and [RFC7176]). It may
+ be unsafe for an RBridge to send TRILL Hellos on fewer VLANs than the
+ set of VLANs recommended in [RFC6325] on a link unless all its
+ adjacencies on that link (excluding those in the Down state
+ [RFC6327]) indicate support of these mechanisms and these mechanisms
+ are in use.
+
+ 1. An RBridge RB2 MAY include in any TRILL Hello an Appointed
+ Forwarders sub-TLV [RFC7176] appointing itself for one or more
+ ranges of VLANs. The Appointee Nickname field(s) in the
+ Appointed Forwarder sub-TLV MUST be the same as the Sender
+ Nickname in the Special VLANs and Flags sub-TLV in the TRILL
+ Hello. This indicates the sending RBridge believes it is
+ Appointed Forwarder for those VLANs. An RBridge receiving such a
+ sub-TLV sets each of its VLAN inhibition timers for every VLAN in
+ the block or blocks listed in the Appointed Forwarders sub-TLV to
+ the maximum of its current value and the Holding Time of the
+ Hello containing the sub-TLV. This is backward compatible
+ because such sub-TLVs will have no effect on any receiving
+ RBridge not implementing this mechanism unless RB2 is the DRB
+ (Designated RBridge) sending Hello on the Designated VLAN, in
+ which case, as specified in [RFC6439], RB2 MUST include in the
+ Hello all forwarder appointments, if any, for RBridges other than
+ itself on the link.
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 19]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+ 2. An RBridge MAY use the new VLANs Appointed sub-TLV [RFC7176].
+ When RB1 receives a VLANs Appointed sub-TLV in a TRILL Hello from
+ RB2 on any VLAN, RB1 updates the VLAN inhibition timers for all
+ the VLANs that RB2 lists in that sub-TLV as VLANs for which RB2
+ is Appointed Forwarder. Each such timer is updated to the
+ maximum of its current value and the Holding Time of the TRILL
+ Hello containing the VLANs Appointed sub-TLV. This sub-TLV will
+ be an unknown sub-TLV to RBridges not implementing it, and such
+ RBridges will ignore it. Even if a TRILL Hello sent by the DRB
+ on the Designated VLAN includes one or more VLANs Appointed sub-
+ TLVs, as long as no Appointed Forwarders sub-TLVs appear, the
+ Hello is not required to indicate all forwarder appointments.
+
+ Two different encodings are providing above to optimize the listing
+ of VLANs. Large blocks of contiguous VLANs are more efficiently
+ encoded with the Appointed Forwarders sub-TLV, and scattered VLANs
+ are more efficiently encoded with the VLANs Appointed sub-TLV. These
+ encodings may be mixed in the same Hello. The use of these sub-TLVs
+ does not affect the requirement that the "AF" bit in the Special
+ VLANs and Flags sub-TLV MUST be set if the originating RBridge
+ believes it is Appointed Forwarder for the VLAN in which the Hello is
+ sent. If the above mechanisms are used on a link, then each RBridge
+ on the link MUST send Hellos in one or more VLANs with such VLANs
+ Appointed sub-TLV(s) and/or self-appointment Appointed Forwarders
+ sub-TLV(s), and the "AF" bit MUST be appropriately set such that no
+ VLAN inhibition timer will improperly expire unless three or more
+ Hellos are lost. For example, an RBridge could announce all VLANs
+ for which it believes it is Appointed Forwarder in a Hello sent on
+ the Designated VLAN three times per Holding Time.
+
+10.2. Overload and Appointed Forwarders
+
+ An RBridge in overload (see Section 2) will, in general, do a poorer
+ job of ingressing and forwarding frames than an RBridge not in
+ overload that has full knowledge of the campus topology. For
+ example, an overloaded RBridge may not be able to distribute multi-
+ destination TRILL Data frames at all.
+
+ Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an
+ Appointed Forwarder unless there is no alternative. Furthermore, if
+ an Appointed Forwarder becomes overloaded, the DRB SHOULD re-assign
+ VLANs from the overloaded RBridge to another RBridge on the link that
+ is not overloaded, if one is available. DRB election is not affected
+ by overload.
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 20]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+ A counter-example would be if all campus end stations in VLAN-x were
+ on links attached to RB1 via ports where VLAN-x was enabled. In such
+ a case, RB1 SHOULD be made the VLAN-x Appointed Forwarder on all such
+ links even if RB1 is overloaded.
+
+11. IANA Considerations
+
+ The following IANA actions have been completed.
+
+ 1. The nickname 0xFFC1, which was reserved by [RFC6325], is
+ allocated for use in the TRILL Header Egress Nickname field to
+ indicate an OOMF (Overload Originated Multi-destination Frame).
+
+ 2. Bit 1 from the seven previously reserved (RESV) bits in the per-
+ neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC7176] is
+ allocated to indicate that the RBridge sending the TRILL Hello
+ volunteers to provide the OOMF forwarding service described in
+ Section 2.4.2 to such frames originated by the TRILL Switch whose
+ SNPA (MAC address) appears in that Neighbor RECORD. The
+ description of this bit is "Offering OOMF service".
+
+ 3. Bit 0 is allocated from the Capability bits in the PORT-TRILL-VER
+ sub-TLV [RFC7176] to indicate support of the VLANs Appointed sub-
+ TLV [RFC7176] and the VLAN inhibition setting mechanisms
+ specified in Section 10.1. The description of this bit is "Hello
+ reduction support".
+
+12. Security Considerations
+
+ This memo improves the documentation of the TRILL protocol, corrects
+ five errata in [RFC6325], and updates [RFC6325], [RFC6327], and
+ [RFC6439]. It does not change the security considerations of these
+ RFCs.
+
+13. Acknowledgements
+
+ The contributions of the following individuals are gratefully
+ acknowledged: Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou
+ Li, Radia Perlman, Mike Shand, Meral Shirazipour, and Varun Varshah.
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 21]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+14. References
+
+14.1. Normative References
+
+ [802.1Q-2011]
+ IEEE, "IEEE Standard for Local and metropolitan area
+ networks -- Media Access Control (MAC) Bridges and Virtual
+ Bridged Local Area Networks", IEEE Std 802.1Q-2011, August
+ 2011.
+
+ [IS-IS] International Organization for Standardization,
+ "Intermediate System to Intermediate System intra-domain
+ routeing information exchange protocol for use in
+ conjunction with the protocol for providing the
+ connectionless-mode network service (ISO 8473)", Second
+ Edition, November 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.
+
+ [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
+ Engineering", RFC 5305, October 2008.
+
+ [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.
+
+ [RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and
+ V. Manral, "Routing Bridges (RBridges): Adjacency", RFC
+ 6327, July 2011.
+
+ [RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
+ Hu, "Routing Bridges (RBridges): Appointed Forwarders",
+ RFC 6439, November 2011.
+
+ [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
+ D., and A. Banerjee, "Transparent Interconnection of Lots
+ of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 22]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+14.2. Informative References
+
+ [802] IEEE 802, "IEEE Standard for Local and metropolitan area
+ networks: Overview and Architecture", IEEE Std 802.1-2001,
+ 8 March 2002.
+
+ [Err3002] RFC Errata, Errata ID 3002, RFC 6325,
+ <http://www.rfc-editor.org>.
+
+ [Err3003] RFC Errata, Errata ID 3003, RFC 6325,
+ <http://www.rfc-editor.org>.
+
+ [Err3004] RFC Errata, Errata ID 3004, RFC 6325,
+ <http://www.rfc-editor.org>.
+
+ [Err3052] RFC Errata, Errata ID 3052, RFC 6325,
+ <http://www.rfc-editor.org>.
+
+ [Err3053] RFC Errata, Errata ID 3053, RFC 6325,
+ <http://www.rfc-editor.org>.
+
+ [Err3508] RFC Errata, Errata ID 3508, RFC 6325,
+ <http://rfc-editor.org>.
+
+ [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
+ IETF Protocol and Documentation Usage for IEEE 802
+ Parameters", BCP 141, RFC 7042, October 2013.
+
+ [RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
+ Ward, "Transparent Interconnection of Lots of Links
+ (TRILL): RBridge Channel Support", RFC 7178, May 2014.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 23]
+
+RFC 7180 TRILL: Clarifications, Corrections, and Updates May 2014
+
+
+Authors' Addresses
+
+ Donald Eastlake 3rd
+ Huawei R&D USA
+ 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
+ Dell
+ 5450 Great America Parkway
+ Santa Clara, CA 95054
+ USA
+
+ EMail: anoop@alumni.duke.edu
+
+
+ Vishwas Manral
+ Ionos Corp.
+ 4100 Moorpark Ave.
+ San Jose, CA 95117
+ USA
+
+ EMail: vishwas@ionosnetworks.com
+
+
+ Ayan Banerjee
+ Cumulus Networks
+ 1089 West Evelyn Avenue
+ Sunnyvale, CA 94086
+ USA
+
+ EMail: ayabaner@gmail.com
+
+
+
+
+Eastlake, et al. Standards Track [Page 24]
+