doc: Add RFC documents

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]
+