INTERNET-DRAFT                                           Donald Eastlake
Intended status: Proposed Standard                          Mingui Zhang
Updates: 6325, 7177                                               Huawei
                                                           Ayan Banerjee
                                                          Vishwas Manral
Expires: August 27, 2016                               February 28, 2016

                         TRILL: Multi-Topology

   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 RFC 6325 and RFC 7177.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Distribution of this document is unlimited. Comments should be sent
   to the TRILL working group mailing list.

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

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

   The list of current Internet-Drafts can be accessed at The list of Internet-Draft
   Shadow Directories can be accessed at

D. Eastlake, et al                                              [Page 1]

INTERNET-DRAFT                                     TRILL: Multi-Topology

Table of Contents

      1. Introduction............................................3
      1.1 Terminology............................................4

      2. Topologies..............................................5
      2.1 Special Topology Zero..................................5
      2.2 Links and Multi-Topology...............................5
      2.3 TRILL Switches and Multi-Topology......................5
      2.4 TRILL Data Packets and Multi-Topology..................6
      2.4.1 Explicit Topology Labeling Support...................6
      2.4.2 The Explicit Topology Label..........................7
      2.4.3 TRILL Use of the MT Label............................8

      3. TRILL Multi-Topology Adjacency and Routing.............10
      3.1 Adjacency (Updates to RFC 7177).......................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............................................14

      5. Other Multi-Topology Considerations....................15
      5.1 Address Learning......................................15
      5.1.1 Data Plane Learning.................................15
      5.1.2 Multi-Topology ESADI................................15
      5.2 Legacy Stubs..........................................15
      5.3 RBridge Channel Messages..............................15
      5.4 Implementations Considerations........................16

      6. Allocation Considerations..............................17
      6.1 IEEE Registration Authority Considerations............17
      6.2 IANA Considerations...................................17

      7. Security Considerations................................18

      Normative References......................................19
      Informative References....................................20

      Appendix A: Differences from RFC 5120.....................22

      Authors' Addresses........................................23

D. Eastlake, et al                                              [Page 2]

INTERNET-DRAFT                                     TRILL: Multi-Topology

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.

   This document updates [RFC7177] as specified in Section 3.1. This
   document updates numerous aspects of [RFC6325] including changing
   routing (Sections 3.3 and 3.4), address learning (Section 5.1), and
   distribution tree construction (Section 3.4), to take multi-topology
   into account.

   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 [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
   but may still use any of the TRILL switches and links 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

   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 station connected in
   that topology to different islands will be unable to communicate with
   each other.

D. Eastlake, et al                                              [Page 3]

INTERNET-DRAFT                                     TRILL: Multi-Topology

   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.

1.1 Terminology

   The terminology and acronyms of [RFC6325] are used in this document.
   Some of these are listed below for convenience along with some
   additional terms.

      campus - The name for a TRILL network, like "bridged LAN" is a
            name for a bridged network. It does not have any academic

      FGL - Fine-Grained Labeling or Fine-Grained Labeled or Fine-
            Grained Label [RFC7172]. By implication, an "FGL TRILL
            switch" does not support MT.

      IS - Intermediate System [IS-IS].

      LSP - [IS-IS] Link State PDU (Protocol Data Unit). For TRILL this
            includes L1-LSPs and E-L1FS-LSPs [RFC7780].

      MT - Multi-Topology, this document and [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

      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 [IS-IS] Intermediate Systems (routers).

      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",
   document are to be interpreted as described in [RFC2119].

D. Eastlake, et al                                              [Page 4]

INTERNET-DRAFT                                     TRILL: Multi-Topology

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 [RFC5120] IS-IS multi-topology. 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, 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 received 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 only usable for TRILL Data packets in non-zero topology T
   (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.

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.

D. Eastlake, et al                                              [Page 5]

INTERNET-DRAFT                                     TRILL: Multi-Topology

   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

   Commonly, 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.

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 two-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.
       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

D. Eastlake, et al                                              [Page 6]

INTERNET-DRAFT                                     TRILL: Multi-Topology

           packet whose explicit topology label differs from the port's
           topology determination for that packet, the TRILL switch MUST
           discard the packet.
       2/3 Requires an explicit topology label in received TRILL Data
           packets except for topology zero. Any TRILL Data packets
           received without such a label is 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.)

   A TRILL switch advertising in a Hello on Port P support for topology
   T but not advertising in those Hellos 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. If a 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

   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 TBD          | 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].

D. Eastlake, et al                                              [Page 7]

INTERNET-DRAFT                                     TRILL: Multi-Topology

2.4.3 TRILL Use of the MT Label

   With the addition of the 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.  {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], and thus MUST support all four data labeling area contents
   shown below.

   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
      |  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
      |  0x893B                       | PRI |D|  FGL High Part        |
      |  0x893B                       | PRI |D|  FGL Low Part         |

   3. MT C-VLAN [this document]

                           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 TBD             | 0 | R |  MT-ID                |
      |  0x8100                       | PRI |D|  VLAN ID              |

   4. MT FGL [this document] [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 TBD             | 0 | R |  MT-ID                |
      |  0x893B                       | PRI |D|  FGL High Part        |
      |  0x893B                       | PRI |D|  FGL Low Part         |

D. Eastlake, et al                                              [Page 8]

INTERNET-DRAFT                                     TRILL: Multi-Topology

   Inclusion or use of S-VLAN or further stacked tags are beyond the
   scope of this document but, as stated in [RFC6325], are an obvious

D. Eastlake, et al                                              [Page 9]

INTERNET-DRAFT                                     TRILL: Multi-Topology

3. TRILL Multi-Topology Adjacency and Routing

   Routing calculations in IS-IS are based on adjacency. Section 3.1
   specifies multi-topology updates to the TRILL adjacency specification
   [RFC7177].  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 (Updates to RFC 7177)

   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

   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, nickname sub-TLVs that

D. Eastlake, et al                                             [Page 10]

INTERNET-DRAFT                                     TRILL: Multi-Topology

   appear in MT Router Capability TLVs with a non-zero topology do
   affect the choice of distribution tree roots as described in Section

   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 determine as specified in [RFC6325],
   [RFC7172], and [RFC7780] with the following changes:

D. Eastlake, et al                                             [Page 11]

INTERNET-DRAFT                                     TRILL: Multi-Topology

      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
         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 descried 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 reasons, a Number of Trees to Compute
            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 causes one tree to be

      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 is preferred to one 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

D. Eastlake, et al                                             [Page 12]

INTERNET-DRAFT                                     TRILL: Multi-Topology

         Router Capabilities TLVs for topology T.

   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.

D. Eastlake, et al                                             [Page 13]

INTERNET-DRAFT                                     TRILL: Multi-Topology

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 [RFC6439] 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

   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-TVLs in an MT Port Capability TLV with a nonzero MT-ID is

         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.

D. Eastlake, et al                                             [Page 14]

INTERNET-DRAFT                                     TRILL: Multi-Topology

5. Other Multi-Topology Considerations

5.1 Address Learning

   The learning of end station 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, 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.

D. Eastlake, et al                                             [Page 15]

INTERNET-DRAFT                                     TRILL: Multi-Topology

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, but 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 8 or more topologies can be considered a full implementation
   while a TRILL switch capable of handling 4 topologies can be
   considered a minimal implementation but still useful under some

D. Eastlake, et al                                             [Page 16]

INTERNET-DRAFT                                     TRILL: Multi-Topology

6. Allocation Considerations

   IEEE Registration Authority and IANA considerations are given below.

6.1 IEEE Registration Authority Considerations

   The IEEE Registration Authority will be requested to allocate a new
   Ethertype for the MT label (see Section 2.4).

6.2 IANA Considerations

   IANA is requested to assign a field of two adjacent bits TBD from
   bits 14 through 31 of the Capabilities bits of the Port TRILL Version
   Sub-TLV for the Explicit Topology capability field and update the
   "PORT-TRILL-VER Capability Bits" registry as follows [shown with the
   suggested bits 14 and 15]:

       Bit     Description                 Reference
      -----   -------------------------    ---------------
      14-15   Topology labeling support    [this document]

D. Eastlake, et al                                             [Page 17]

INTERNET-DRAFT                                     TRILL: Multi-Topology

7. Security Considerations

   Multiple topologies are sometimes used for the isolation or security
   of traffic. For example, if some links was 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

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

D. Eastlake, et al                                             [Page 18]

INTERNET-DRAFT                                     TRILL: Multi-Topology

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, <>.

   [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
         Topology (MT) Routing in Intermediate System to Intermediate
         Systems (IS-ISs)", RFC 5120, February 2008.

   [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, <http://www.rfc->.

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

   [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, May 2014.

   [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.

   [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H.,
         and V. Manral, "Transparent Interconnection of Lots of Links
         (TRILL): Adjacency", RFC 7177, May 2014.

   [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.

   [RFC7357] - Hhai, 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,

   [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,

D. Eastlake, et al                                             [Page 19]

INTERNET-DRAFT                                     TRILL: Multi-Topology


Informative References

   [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
         Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC
         6439, November 2011.

   [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,
         May 2014.

D. Eastlake, et al                                             [Page 20]

INTERNET-DRAFT                                     TRILL: Multi-Topology


   The comments and suggestions of the following are gratefully


   The document was prepared in raw nroff. All macros used were defined
   within the source file.

D. Eastlake, et al                                             [Page 21]

INTERNET-DRAFT                                     TRILL: Multi-Topology

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 pre-existing fields within the packet.
      This document supports implicit determination but extends this for
      TRILL 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).

D. Eastlake, et al                                             [Page 22]

INTERNET-DRAFT                                     TRILL: Multi-Topology

Authors' Addresses

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

   Phone: +1-508-333-2270

   Mingui Zhang
   Huawei Technologies Co., Ltd
   HuaWei Building, No.3 Xinxi Rd., Shang-Di
   Information Industry Base, Hai-Dian District,
   Beijing, 100085 P.R. China


   Ayan Banerjee
   170 W. Tasman Drive
   San Jose, CA 95134


   Vishwas Manral
   Ionos Corp.
   4100 Moorpark Ave.
   San Jose, CA 95117 USA


D. Eastlake, et al                                             [Page 23]

INTERNET-DRAFT                                     TRILL: Multi-Topology

Copyright, Disclaimer, and Additional IPR Provisions

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

D. Eastlake, et al                                             [Page 24]