summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8377.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8377.txt')
-rw-r--r--doc/rfc/rfc8377.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc8377.txt b/doc/rfc/rfc8377.txt
new file mode 100644
index 0000000..5c383e1
--- /dev/null
+++ b/doc/rfc/rfc8377.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Eastlake 3rd
+Request for Comments: 8377 M. Zhang
+Updates: 6325, 7177 Huawei
+Category: Standards Track A. Banerjee
+ISSN: 2070-1721 Cisco
+ July 2018
+
+ Transparent Interconnection of Lots of Links (TRILL):
+ Multi-Topology
+
+Abstract
+
+ This document specifies extensions to the IETF TRILL (Transparent
+ Interconnection of Lots of Links) protocol to support multi-topology
+ routing of unicast and multi-destination traffic based on IS-IS
+ (Intermediate System to Intermediate System) multi-topology specified
+ in RFC 5120. This document updates RFCs 6325 and 7177.
+
+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 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8377.
+
+Copyright Notice
+
+ Copyright (c) 2018 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
+ (https://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 1]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Terminology ................................................4
+ 2. Topologies ......................................................5
+ 2.2. Links and Multi-Topology ...................................5
+ 2.3. TRILL Switches and Multi-Topology ..........................6
+ 2.4. TRILL Data Packets and Multi-Topology ......................6
+ 2.4.1. Explicit Topology Labeling Support ..................7
+ 2.4.2. The Explicit Topology Label .........................8
+ 2.4.3. TRILL Use of the MT Label ...........................8
+ 3. TRILL Multi-Topology Adjacency and Routing .....................10
+ 3.1. Adjacency .................................................10
+ 3.2. TRILL Switch Nicknames ....................................10
+ 3.3. TRILL Unicast Routing .....................................11
+ 3.4. TRILL Multi-Destination Routing ...........................11
+ 3.4.1. Distribution Trees .................................11
+ 3.4.2. Multi-Access Links .................................13
+ 4. Mixed Links ....................................................13
+ 5. Other Multi-Topology Considerations ............................14
+ 5.1. Address Learning ..........................................14
+ 5.1.1. Data Plane Learning ................................14
+ 5.1.2. Multi-Topology ESADI ...............................14
+ 5.2. Legacy Stubs ..............................................14
+ 5.3. RBridge Channel Messages ..................................14
+ 5.4. Implementations Considerations ............................15
+ 6. Allocation Considerations ......................................15
+ 6.1. IEEE Registration Authority Considerations ................15
+ 6.2. IANA Considerations .......................................15
+ 7. Security Considerations ........................................16
+ 8. References .....................................................17
+ 8.1. Normative References ......................................17
+ 8.2. Informative References ....................................18
+ Appendix A. Differences from RFC 5120 .............................19
+ Acknowledgements ..................................................19
+ Authors' Addresses ................................................20
+
+1. Introduction
+
+ This document specifies extensions to the IETF TRILL (Transparent
+ Interconnection of Lots of Links) protocol [RFC6325] [RFC7177]
+ [RFC7780] to support multi-topology routing for both unicast and
+ multi-destination traffic based on IS-IS (Intermediate System to
+ Intermediate System) [IS-IS] multi-topology [RFC5120].
+ Implementation and use of multi-topology are optional, and use
+ requires configuration. It is anticipated that not all TRILL
+ campuses will need or use multi-topology.
+
+
+
+
+Eastlake, et al. Standards Track [Page 2]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+ Multi-topology creates different topologies or subsets from a single
+ physical TRILL campus topology. This is different from Data Labels
+ (VLANs and Fine-Grained Labels (FGLs) [RFC7172]). Data Labels
+ specify communities of end stations and can be viewed as creating
+ virtual topologies of end station connectivity. However, in a single
+ topology TRILL campus, TRILL Data packets can use any part of the
+ physical topology of TRILL switches and links between TRILL switches,
+ regardless of the Data Label of that packet's payload. In a multi-
+ topology TRILL campus, TRILL data packets in a topology are
+ restricted to the TRILL switches and links that are in their
+ topology, regardless of the Data Label of their payload.
+
+ The essence of multi-topology behavior is that a multi-topology
+ router classifies packets as to the topology within which they should
+ be routed and uses logically different routing tables for different
+ topologies. If routers in the network do not agree on the topology
+ classification of packets or links, persistent routing loops can
+ occur. It is the responsibility of the network manager to
+ consistently configure multi-topology to avoid such routing loops.
+
+ The multi-topology TRILL extensions can be used for a wide variety of
+ purposes, such as maintaining separate routing domains for isolated
+ multicast or IPv6 islands, routing a class of traffic so that it
+ avoids certain TRILL switches that lack some characteristic needed by
+ that traffic, or making a class of traffic avoid certain links due to
+ security, reliability, or other concerns.
+
+ It is possible for a particular topology to not be fully connected,
+ either intentionally or due to node or link failures or incorrect
+ configuration. This results in two or more islands of that topology
+ that cannot communicate. In such a case, end stations connected in
+ that topology to different islands will be unable to communicate with
+ each other.
+
+ Multi-topology TRILL supports regions of topology-ignorant TRILL
+ switches as part of a multi-topology campus; however, such regions
+ can only ingress to, egress from, or transit TRILL Data packets in
+ the special base topology zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 3]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+1.1. Terminology
+
+ The terminology and abbreviations of [RFC6325] are used in this
+ document. Some of these are paraphrased below for convenience. Some
+ additional terms are also listed.
+
+ campus: The name for a TRILL network, like "bridged LAN" is a name
+ for a bridged network. It does not have any academic
+ implication.
+
+ DRB: Designated RBridge [RFC7177].
+
+ FGL: Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained
+ Label [RFC7172]. By implication, an "FGL TRILL switch" does
+ not support Multi-Topology (MT).
+
+ IS: Intermediate System [IS-IS].
+
+ LSP: Link State PDU (Protocol Data Unit) [IS-IS]. For TRILL, this
+ includes Level 1 LSPs and Extended Level 1 Flooding Scope LSPs
+ [RFC7780].
+
+ MT: Multi-Topology [RFC5120].
+
+ MT TRILL Switch: A TRILL switch supporting the multi-topology
+ feature specified in this document. An MT TRILL switch MUST
+ support FGL in the sense that it MUST be FGL safe [RFC7172].
+
+ RBridge: Routing Bridge; an alternative name for a TRILL switch.
+
+ TRILL: Transparent Interconnection of Lots of Links or Tunneled
+ Routing in the Link Layer [RFC6325].
+
+ TRILL Switch: A device implementing the TRILL protocol. TRILL
+ switches are Intermediate Systems (routers) [IS-IS].
+
+ VL: VLAN Labeling or VLAN Labeled or VLAN Label [RFC7172]. By
+ implication, a "VL RBridge" or "VL TRILL switch" does not
+ support FGL or MT.
+
+ 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
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 4]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+2. Topologies
+
+ In TRILL multi-topology, a topology is a subset of the TRILL switches
+ and of the links between TRILL switches in the TRILL campus. TRILL
+ Data packets are constrained to the subset of switches and links
+ corresponding to the packet's topology. TRILL multi-topology is
+ based on IS-IS multi-topology [RFC5120]. See Appendix A for
+ differences between TRILL multi-topology and [RFC5120].
+
+ The zero topology is special, as described in Section 2.1. Sections
+ 2.2, 2.3, and 2.4 discuss the topology of links, TRILL switches, and
+ TRILL Data packets, respectively.
+
+2.1. Special Topology Zero
+
+ The zero topology is special as the default base topology. All TRILL
+ switches and links are considered to be in, and MUST support,
+ topology zero. Thus, for example, topology zero can be used for
+ general TRILL switch access within a campus for management messages,
+ Bidirectional Forwarding Detection (BFD) messages [RFC7175], RBridge
+ Channel messages [RFC7178], and the like.
+
+2.2. Links and Multi-Topology
+
+ Multi-topology TRILL switches advertise the topologies for which they
+ are willing to send and receive TRILL Data packets on a port by
+ listing those topologies in one or more MT TLVs [RFC5120] appearing
+ in every TRILL Hello [RFC7177] they send out that port, except that
+ they MUST handle topology zero, which it is optional to list.
+
+ A link is usable for TRILL Data packets in non-zero topology T only
+ if:
+
+ (1) all TRILL switch ports on the link advertise topology T support
+ in their Hellos, and
+
+ (2) if any TRILL switch port on the link requires explicit TRILL Data
+ packet topology labeling (see Section 2.4) every other TRILL
+ switch port on the link is capable of generating explicit packet
+ topology labeling.
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 5]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+2.3. TRILL Switches and Multi-Topology
+
+ A TRILL switch advertises the topologies that it supports by listing
+ them in one or more MT TLVs [RFC5120] in its LSP, except that it MUST
+ support topology zero, which is optional to list. For robust and
+ rapid flooding, MT TLV(s) SHOULD be advertised in core LSP fragment
+ zero.
+
+ There is no "MT capability bit". A TRILL switch advertises that it
+ is MT capable by advertising in its LSP support for any topology or
+ topologies with the MT TLV, even if it just explicitly advertises
+ support for topology zero.
+
+2.4. TRILL Data Packets and Multi-Topology
+
+ The topology of a TRILL Data packet is commonly determined from
+ either (1) some field or fields present in the packet itself or (2)
+ the port on which the packet was received; however, optional explicit
+ topology labeling of TRILL Data packets is also proved. This can be
+ included in the data labeling area of TRILL Data packets as specified
+ below.
+
+ Examples of fields that might be used to determine topology are
+ values or ranges of values of the payload VLAN or FGL [RFC7172],
+ packet priority, IP version (IPv6 versus IPv4) or IP protocol,
+ Ethertype, unicast versus multi-destination payload, IP
+ Differentiated Services Code Point (DSCP) bits, or the like.
+
+ Multi-topology does not apply to TRILL IS-IS packets or to link level
+ control frames. Those messages are link local and can be thought of
+ as being above all topologies. Multi-topology only applies to TRILL
+ Data packets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 6]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+2.4.1. Explicit Topology Labeling Support
+
+ Support of the topology label is optional. Support could depend on
+ port hardware and is indicated by a 2-bit capability field in the
+ Port TRILL Version sub-TLV [RFC7176] appearing in the Port
+ Capabilities TLV in Hellos. If there is no Port TRILL Capabilities
+ sub-TLV in a Hello, then it is assumed that explicit topology
+ labeling is not supported on that port. See the table below for the
+ meaning of values of the Explicit Topology capability field:
+
+ Value Meaning
+ ----- -------
+ 0 No support. Cannot send TRILL Data packets with an
+ explicit topology label and will likely treat as
+ erroneous and discard any TRILL Data packet received with
+ a topology label. Such a port is assumed to have the
+ ability and configuration to correctly classify TRILL
+ Data packets into all topologies for which it is
+ advertising support in its Hellos, either by examining
+ those packets or because they are arriving at that port.
+
+ 1 Capable of inserting an explicit topology label in TRILL
+ Data packets sent and tolerant of such labels in received
+ TRILL Data packets. Such a port is capable, for all of
+ the topologies it supports, of determining TRILL Data
+ packet topology without an explicit label. Thus, it does
+ not require such a label in received TRILL Data packets.
+ On receiving a packet whose explicit topology label
+ differs from the port's topology determination for that
+ packet, the TRILL switch MUST discard the packet.
+
+ 2 & 3 Require an explicit topology label in received TRILL Data
+ packets except for topology zero. Any TRILL Data packets
+ received without such a label are classified as being in
+ topology zero. Also capable of inserting an explicit
+ topology label in TRILL Data packets sent. (Values 2 and
+ 3 are treated the same, which is the same as saying that
+ if the 2 bit is on, the 1 bit is ignored.)
+
+ In a Hello on Port P, a TRILL switch advertising support for topology
+ T but not advertising that it requires explicit topology labeling is
+ assumed to have the ability and configuration to correctly classify
+ TRILL Data packets into topology T by examination of those TRILL Data
+ packets and/or by using the fact that they are arriving at port P.
+
+ When a TRILL switch transmits a TRILL Data packet onto a link, if any
+ other TRILL switch on that link requires explicit topology labeling,
+ an explicit topology label MUST be included unless the TRILL Data
+
+
+
+Eastlake, et al. Standards Track [Page 7]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+ packet is in topology zero, in which case, an explicit topology label
+ MAY be included. If a topology label is not so required, but all
+ other TRILL switches on that link support explicit topology labeling,
+ then such a label MAY be included.
+
+2.4.2. The Explicit Topology Label
+
+ This section specifies the explicit topology label. Its use by TRILL
+ is specified in Section 2.4.3. This label may be used by other
+ technologies besides TRILL. The MT Label is structured as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MT Ethertype 0x9A22 | V | R | MT-ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: MT Label
+
+ Where the fields are as follows:
+
+ MT Ethertype: The MT Label Ethertype (see Section 6.1).
+
+ V: The version number of the MT Label. This document specifies
+ version zero.
+
+ R: A 2-bit reserved field that MUST be sent as zero and ignored on
+ receipt.
+
+ MT-ID: The 12-bit topology using the topology number space of the MT
+ TLV [RFC5120].
+
+2.4.3. TRILL Use of the MT Label
+
+ With the addition of the version zero MT Label, the four standardized
+ content varieties for the TRILL Data packet data labeling area (the
+ area after the Inner.MacSA -- or Flag Word if the Flag Word is
+ present [RFC7780] -- and before the payload) are as show below.
+ TRILL Data packets received with any other data labeling are
+ discarded. {PRI, D} is a 3-bit priority and a drop eligibility
+ indicator bit [RFC7780].
+
+ All MT TRILL switches MUST support FGL, in the sense of being FGL
+ safe [RFC7172]; thus, they MUST support all four data labeling area
+ contents shown below. (This requirement is imposed, rather than
+ having FGL support and MT support be independent, to reduce the
+ number of variations in RBridges and simplify testing.)
+
+
+
+
+Eastlake, et al. Standards Track [Page 8]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+ 1. C-VLAN [RFC6325]
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | C-VLAN = 0x8100 | PRI |D| VLAN ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 2. FGL [RFC7172]
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FGL = 0x893B | PRI |D| FGL High Part |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FGL = 0x893B | PRI |D| FGL Low Part |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 3. MT C-VLAN [RFC8377]
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MT Ethertype = 0x9A22 | 0 | R | MT-ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | C-VLAN = 0x8100 | PRI |D| VLAN ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 4. MT FGL [RFC8377] [RFC7172]
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MT Ethertype = 0x9A22 | 0 | R | MT-ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FGL = 0x893B | PRI |D| FGL High Part |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FGL = 0x893B | PRI |D| FGL Low Part |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Inclusion or use of S-VLAN or further stacked tags are beyond the
+ scope of this document, but, as stated in [RFC6325], are obvious
+ extensions.
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 9]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+3. TRILL Multi-Topology Adjacency and Routing
+
+ Routing calculations in IS-IS are based on adjacency. Section 3.1
+ specifies multi-topology TRILL adjacency. Section 3.2 describes the
+ handling of nicknames. Sections 3.3 and 3.4 specify how unicast and
+ multi-destination TRILL multi-topology routing differ from the TRILL
+ base protocol routing.
+
+3.1. Adjacency
+
+ There is no change in the determination or announcement of adjacency
+ for topology zero, which is as specified in [RFC7177]. When a
+ topology zero adjacency reaches the Report state, as specified in
+ [RFC7177], the adjacency is announced in core LSPs using the Extended
+ Intermediate System Reachability TLV (#22). This will be compatible
+ with any legacy topology-ignorant RBridges that might not support E-
+ L1FS FS-LSPs [RFC7780].
+
+ Adjacency is announced for non-zero topologies in LSPs using the MT
+ Reachable Intermediate Systems TLV (#222) as specified in [RFC5120].
+ A TRILL switch reports adjacency for non-zero topology T if and only
+ if that adjacency is in the Report state [RFC7177] and the two
+ conditions listed in Section 2.2 are true, namely:
+
+ 1. All the ports on the link are announcing support of topology T.
+
+ 2. If any port announces that it requires explicit topology labeling
+ (Explicit Topology capability field value 2 or 3), all other ports
+ advertise that they are capable of producing such labeling
+ (Explicit Topology capability field value of 1, 2, or 3).
+
+3.2. TRILL Switch Nicknames
+
+ TRILL switches are usually identified within the TRILL protocol (for
+ example, in the TRILL Header) by nicknames [RFC6325] [RFC7780]. Such
+ nicknames can be viewed as simply 16-bit abbreviation for a TRILL
+ switch's (or pseudo-node's) 7-byte IS-IS System ID. A TRILL switch
+ or pseudo-node can have more than one nickname, each of which
+ identifies it.
+
+ Nicknames are common across all topologies, just as IS-IS System IDs
+ are. Nicknames are determined as specified in [RFC6325] and
+ [RFC7780] using only the Nickname sub-TLVs appearing in Router
+ Capabilities TLVs (#242) advertised by TRILL switches. In
+ particular, the nickname allocation algorithm ignores Nickname sub-
+ TLVs that appear in MT Router Capability TLVs (#144). (However,
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 10]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+ Nickname sub-TLVs that appear in MT Router Capability TLVs with a
+ non-zero topology do affect the choice of distribution tree roots as
+ described in Section 3.4.1.)
+
+ To minimize transient inconsistencies, all Nickname sub-TLVs
+ advertised by a TRILL switch for a particular nickname, whether in
+ Router Capability or MT Router Capability TLVs, SHOULD appear in the
+ same LSP PDU. If that is not the case, then all LSP PDUs in which
+ they do occur SHOULD be flooded as an atomic action.
+
+3.3. TRILL Unicast Routing
+
+ TRILL Data packets being TRILL unicast (those with TRILL Header M bit
+ = 0) are routed based on the egress nickname using logically separate
+ forwarding tables per topology T, where each such table has been
+ calculated based on least cost routing within T: that is, only using
+ links and nodes that support T. Thus, the next hop when forwarding
+ TRILL Data packets is determined by a lookup logically based on
+ {topology, egress nickname}.
+
+3.4. TRILL Multi-Destination Routing
+
+ TRILL sends multi-destination data packets (those packets with TRILL
+ Header M bit = 1) over a distribution tree. Trees are designated by
+ nicknames that appear in the "egress nickname" field of multi-
+ destination TRILL Data packet TRILL Headers. To constrain multi-
+ destination packets to a topology T and still distribute them
+ properly requires the use of a distribution tree constrained to T.
+ Handling such TRILL Data packets and distribution trees in TRILL MT
+ is as described in the subsections below.
+
+3.4.1. Distribution Trees
+
+ General provisions for distribution trees and how those trees are
+ determined are as specified in [RFC6325], [RFC7172], and [RFC7780].
+ The distribution trees for topology zero are determined as specified
+ in those references and are the same as they would be with topology-
+ ignorant TRILL switches.
+
+ The TRILL distribution tree construction and packet handling for some
+ non-zero topology T are determined as specified in [RFC6325],
+ [RFC7172], and [RFC7780] with the following changes:
+
+ o As specified in [RFC5120], only links usable with topology T
+ TRILL Data packets are considered when building a distribution
+ tree for topology T. As a result, such trees are automatically
+ limited to and separately span every internally connected
+
+
+
+
+Eastlake, et al. Standards Track [Page 11]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+ island of topology T. In other words, if non-zero topology T
+ consists of disjoint islands, each distribution tree
+ construction for topology T is local to one such island.
+
+ o Only the Nickname sub-TLV, Trees sub-TLV, Tree Identifiers sub-
+ TLV, and Trees Used sub-TLV occurring in an MT Router
+ Capabilities TLV (#144) specifying topology T are used in
+ determining the tree root(s), if any, for a connected area of
+ non-zero topology T.
+
+ + There may be non-zero topologies with no multi-destination
+ traffic or, as described in [RFC5120], even topologies with
+ no traffic at all. For example, if only known destination
+ unicast IPv6 TRILL Data packets were in topology T and all
+ multi-destination IPv6 TRILL Data packets were in some other
+ topology, there would be no need for a distribution tree for
+ topology T. For this reason, a Number of Trees to Compute
+ field value of zero in the Trees sub-TLV for the TRILL
+ switch holding the highest priority to be a tree root for a
+ non-zero topology T is honored and causes no distribution
+ trees to be calculated for non-zero topology T. This is
+ different from the base topology zero where, as specified in
+ [RFC6325], a zero Number of Trees to Compute field value
+ causes one tree to be computed.
+
+ o Nicknames are allocated as described in Section 3.2. If a
+ TRILL switch advertising that it provides topology T service
+ holds nickname N, the priority of N to be a tree root is given
+ by the tree root priority field of the Nickname sub-TLV that
+ has N in its nickname field and occurs in a topology T MT
+ Router Capabilities TLV advertised by that TRILL switch. If no
+ such Nickname sub-TLV can be found, the priority of N to be a
+ tree root is the default for an FGL TRILL switch as specified
+ in [RFC7172].
+
+ + There could be multiple topology T Nickname sub-TLVs for N
+ being advertised for a particular RBridge or pseudo-node,
+ due to transient conditions or errors. In that case, any
+ advertised in a core LSP PDU are preferred to those
+ advertised in an E-L1FS FS-LSP PDU. Within those
+ categories, the one in the lowest numbered fragment is used
+ and if there are multiple in that fragment, the one with the
+ smallest offset from the beginning of the PDU is used.
+
+ o Tree pruning for topology T uses only the Interested VLANs sub-
+ TLVs and Interested Labels sub-TLVs [RFC7176] advertised in MT
+ Router Capabilities TLVs for topology T.
+
+
+
+
+Eastlake, et al. Standards Track [Page 12]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+ An MT TRILL switch MUST have logically separate routing tables per
+ topology for the forwarding of multi-destination traffic.
+
+3.4.2. Multi-Access Links
+
+ Multi-destination TRILL Data packets are forwarded on broadcast
+ (multi-access) links in such a way as to be received by all other
+ TRILL switch ports on the link. For example, on Ethernet links they
+ are sent with a multicast Outer.MacDA [RFC6325]. Care must be taken
+ that a TRILL Data packet in a non-zero topology is only forwarded by
+ an MT TRILL switch.
+
+ For this reason, a non-zero topology TRILL Data packet MUST NOT be
+ forwarded onto a link unless the link meets the requirements
+ specified in Section 2.2 for use in that topology even if there are
+ one or more MT TRILL switch ports on the link.
+
+4. Mixed Links
+
+ There might be any combination of MT, FGL, or even VL TRILL switches
+ [RFC7172] on a link. DRB (Designated RBridge) election and Forwarder
+ appointment on the link work as previously specified in [RFC8139] and
+ [RFC7177]. It is up to the network manager to configure and manage
+ the TRILL switches on a link so that the desired switch is DRB and
+ the desired switch is the Appointed Forwarder for the appropriate
+ VLANs.
+
+ Frames ingressed by MT TRILL switches can potentially be in any
+ topology recognized by the switch and permitted on the ingress port.
+ Frames ingressed by VL or FGL TRILL switches can only be in the base
+ zero topology. Because FGL and VL TRILL switches do not understand
+ topologies, all occurrences of the following sub-TLVs MUST occur only
+ in MT Port Capability TLVs with a zero MT-ID. Any occurrence of
+ these sub-TLVs in an MT Port Capability TLV with a nonzero MT-ID is
+ ignored.
+
+ Special VLANs and Flags Sub-TLV
+ Enabled-VLANs Sub-TLV
+ Appointed Forwarders Sub-TLV
+ VLANs Appointed Sub-TLV
+
+ Native frames cannot be explicitly labeled (see Section 2.4) as to
+ their topology.
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 13]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+5. Other Multi-Topology Considerations
+
+5.1. Address Learning
+
+ The learning of end station Media Access Control (MAC) addresses is
+ per topology as well as per label (VLAN or FGL). The same MAC
+ address can occur within a TRILL campus for different end stations
+ that differ only in topology without confusion.
+
+5.1.1. Data Plane Learning
+
+ End station MAC addresses learned from ingressing native frames or
+ egressing TRILL Data packets are, for MT TRILL switches, qualified by
+ topology. That is, either the topology into which that TRILL switch
+ classified the ingressed native frame or the topology that the
+ egressed TRILL Data frame was in.
+
+5.1.2. Multi-Topology ESADI
+
+ In an MT TRILL switch, End Station Address Distribution Information
+ (ESADI) [RFC7357] operates per label (VLAN or FGL) per topology.
+ Since ESADI messages appear, to transit TRILL switches, like normal
+ multi-destination TRILL Data packets, ESADI link state databases and
+ ESADI protocol operation are per topology as well as per label and
+ local to each area of multi-destination TRILL data connectivity for
+ that topology.
+
+5.2. Legacy Stubs
+
+ Areas of topology-ignorant TRILL switches can be connected to and
+ become part of an MT TRILL campus but will only be able to ingress
+ to, transit, or egress from topology zero TRILL Data packets.
+
+5.3. RBridge Channel Messages
+
+ RBridge Channel messages [RFC7178], such as BFD over TRILL [RFC7175]
+ appear, to transit TRILL switches, like normal multi-destination
+ TRILL Data packets. Thus, they have a topology and, if that topology
+ is non-zero, are constrained by topology like other TRILL Data
+ packets. Generally, when sent for network management purposes, they
+ are sent in topology zero to avoid such constraint.
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 14]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+5.4. Implementations Considerations
+
+ MT is an optional TRILL switch capability.
+
+ Experience with the actual deployment of Layer 3 IS-IS MT [RFC5120]
+ indicates that a single router handling more than eight topologies is
+ rare. There may be many more than eight distinct topologies in a
+ routed area, such as a TRILL campus; in that case, many of these
+ topologies will be handled by disjoint sets of routers and/or links.
+
+ Based on this deployment experience, a TRILL switch capable of
+ handling eight or more topologies can be considered a full
+ implementation while a TRILL switch capable of handling four
+ topologies can be considered a minimal implementation but still
+ useful under some circumstances.
+
+6. Allocation Considerations
+
+ IEEE Registration Authority and IANA considerations are given below.
+
+6.1. IEEE Registration Authority Considerations
+
+ The IEEE Registration Authority has allocated Ethertype 0x9A22 for
+ the MT Label (see Section 2.4).
+
+6.2. IANA Considerations
+
+ IANA has assigned a field of two adjacent bits (14-15) of the
+ Capabilities bits of the Port TRILL Version Sub-TLV for the Explicit
+ Topology capability field and updated the "PORT-TRILL-VER Sub-TLV
+ Capability Flags" registry as follows.
+
+ Bit Description Reference
+ ----- ------------------------- ---------------
+ 14-15 Topology labeling support. [RFC8377]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 15]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+ IANA has created the informational "TRILL Ethertypes" subregistry in
+ the "Transparent Interconnection of Lots of Links (TRILL) Parameters"
+ registry.
+
+ Name: TRILL Ethertypes
+ Registration Procedure(s): Ethertypes are assigned by the IEEE
+ Registration Authority. Updates to this registry are coordinated
+ with the designated expert.
+ Reference: [RFC8377]
+
+ Note: This registry provides centralized documentation of
+ Ethertypes that were assigned by the IEEE for initial use
+ with TRILL. In some cases, particularly L2-IS-IS and MT,
+ they may be used with other protocols.
+
+ Value Mnemonic Explanation Reference
+ ------ -------- --------------------- ---------
+ 0x22F3 TRILL TRILL data [RFC6325]
+ 0x22F4 L2-IS-IS IS-IS [RFC6325]
+ 0x893B FGL Fine Grained Labeling [RFC7172]
+ 0x8946 - TRILL RBridge Channel [RFC7178]
+ 0x9A22 MT Multi-Topology [RFC8377]
+
+7. Security Considerations
+
+ Multiple topologies are sometimes used for the isolation or security
+ of traffic. For example, if some links were more likely than others
+ to be subject to adversarial observation, it might be desirable to
+ classify certain sensitive traffic in a topology that excluded those
+ links.
+
+ Delivery of data originating in one topology outside of that topology
+ is generally a security policy violation to be avoided at all
+ reasonable costs. Using IS-IS security [RFC5310] on all IS-IS PDUs
+ and link security appropriate to the link technology on all links
+ involved, particularly those between RBridges, supports the avoidance
+ of such violations.
+
+ For general TRILL security considerations, see [RFC6325].
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 16]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+8. References
+
+8.1. Normative References
+
+ [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.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
+ Topology (MT) Routing in Intermediate System to
+ Intermediate Systems (IS-ISs)", RFC 5120,
+ DOI 10.17487/RFC5120, February 2008,
+ <https://www.rfc-editor.org/info/rfc5120>.
+
+ [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
+ and M. Fanto, "IS-IS Generic Cryptographic
+ Authentication", RFC 5310, DOI 10.17487/RFC5310, February
+ 2009, <https://www.rfc-editor.org/info/rfc5310>.
+
+ [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
+ Ghanwani, "Routing Bridges (RBridges): Base Protocol
+ Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
+ <https://www.rfc-editor.org/info/rfc6325>.
+
+ [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
+ D. Dutt, "Transparent Interconnection of Lots of Links
+ (TRILL): Fine-Grained Labeling", RFC 7172,
+ DOI 10.17487/RFC7172, May 2014,
+ <https://www.rfc-editor.org/info/rfc7172>.
+
+ [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,
+ DOI 10.17487/RFC7176, May 2014,
+ <https://www.rfc-editor.org/info/rfc7176>.
+
+ [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
+ V. Manral, "Transparent Interconnection of Lots of Links
+ (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May
+ 2014, <https://www.rfc-editor.org/info/rfc7177>.
+
+
+
+
+Eastlake, et al. Standards Track [Page 17]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+ [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,
+ DOI 10.17487/RFC7178, May 2014,
+ <https://www.rfc-editor.org/info/rfc7178>.
+
+ [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
+ Stokes, "Transparent Interconnection of Lots of Links
+ (TRILL): End Station Address Distribution Information
+ (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,
+ September 2014, <https://www.rfc-editor.org/info/rfc7357>.
+
+ [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
+ Ghanwani, A., and S. Gupta, "Transparent Interconnection
+ of Lots of Links (TRILL): Clarifications, Corrections, and
+ Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
+ <https://www.rfc-editor.org/info/rfc7780>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+8.2. Informative References
+
+ [RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee,
+ "Transparent Interconnection of Lots of Links (TRILL):
+ Bidirectional Forwarding Detection (BFD) Support", RFC
+ 7175, DOI 10.17487/RFC7175, May 2014, <https://www.rfc-
+ editor.org/info/rfc7175>.
+
+ [RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F.
+ Hu, "Transparent Interconnection of Lots of Links (TRILL):
+ Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139,
+ June 2017, <https://www.rfc-editor.org/info/rfc8139>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 18]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+Appendix A. Differences from RFC 5120
+
+ TRILL multi-topology, as specified in this document, differs from RFC
+ 5120 as follows:
+
+ 1. [RFC5120] provides for unicast multi-topology. This document
+ extends that to cover multi-destination TRILL data distribution
+ (see Section 3.4).
+
+ 2. [RFC5120] assumes the topology of data packets is always
+ determined implicitly, that is, based on the port over which the
+ packets are received and/or preexisting fields within the packet.
+ This document supports such implicit determination, but it extends
+ this by providing for optional explicit topology labeling of data
+ packets (see Section 2.4).
+
+ 3. [RFC5120] makes support of the default topology zero optional for
+ MT routers and links. For simplicity and ease in network
+ management, this document requires all TRILL switches and links
+ between TRILL switches to support topology zero (see Section 2.1).
+
+Acknowledgements
+
+ The comments and contributions of the following are gratefully
+ acknowledged:
+
+ Vishwas Manral and Martin Vigoureux
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 19]
+
+RFC 8377 TRILL: Multi-Topology July 2018
+
+
+Authors' Addresses
+
+ Donald Eastlake 3rd
+ Huawei Technologies
+ 1424 Pro Shop Court
+ Davenport, FL 33896
+ United States of America
+
+ Phone: +1-508-333-2270
+ Email: d3e3e3@gmail.com
+
+
+ Mingui Zhang
+ Huawei Technologies Co., Ltd.
+ HuaWei Building, No.3 Xinxi Rd., Shang-Di
+ Information Industry Base, Hai-Dian District,
+ Beijing, 100085
+ China
+
+ Email: zhangmingui@huawei.com
+
+
+ Ayan Banerjee
+ Cisco
+ 170 W. Tasman Drive
+ San Jose, CA 95134
+ United States of America
+
+ Email: ayabaner@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al. Standards Track [Page 20]
+