RFC 8377

Transparent Interconnection of Lots of Links (TRILL): Multi-Topology

📅 published July 2018, from ietf

okay bestie, let's get into it 💖 this is an IETF Standards Track document, which basically means it's the real deal, not a "just vibes" memo. 🔥 It was written by D. Eastlake 3rd (Huawei is where Eastlake and M. Zhang were, and A. Banerjee was at Cisco), it came out in July 2018, and it's published as ISSN: 2070-1721 🎀.

Here's the drama in the title block: this RFC updates RFC 6325 and RFC 7177 💅. It doesn't obsolete anything. So if you're reading the TRILL family tree, these two get a glow-up from this one. 🌈

Quick rundown of the main idea: it adds multi-topology routing to TRILL, for both unicast and multi-destination traffic, using the IS-IS multi-topology feature from RFC 5120 🦋.

Status of This Memo

This is an Internet Standards Track document. ✨ It's a product of the IETF, it has the consensus of the IETF community, it got public review, and the IESG approved it for publication. 💅 If you want the rest of the Internet Standards info, check out Section 2 of RFC 7841 🎀. Updates and errata live at https://www.rfc-editor.org/info/rfc8377 🌸.

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 📜. Please read those carefully, because they spell out your rights and restrictions. 🙈 Also, any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as that license says. 💜

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 🧚

1.1. Terminology 🎀

Okay so this is the part where the spec says what it's doing 💅. This document extends the TRILL protocol [RFC6325] [RFC7177] [RFC7780] so it can do multi-topology routing for unicast and multi-destination traffic, based on IS-IS multi-topology [RFC5120] ✨. Multi-topology is totally optional, and you have to configure it on purpose 🙈. It's expected that not every TRILL campus will even bother with it 🌸.

Multi-topology makes different topologies (subsets) out of one physical TRILL campus. This is not the same as Data Labels, which are VLANs and Fine-Grained Labels (FGLs) [RFC7172] 💜. Data Labels group end stations together, so they kinda look like virtual topologies of end-station connectivity 🦋. But in a single-topology campus, TRILL Data packets can wander across any part of the physical switches and links, no matter what Data Label the payload has 🌈. In a multi-topology campus, though, TRILL Data packets stay inside the switches and links of their own topology, no matter their Data Label 🔥.

The big idea is that a multi-topology router sorts packets into the topology they should be routed in, and then uses separate routing tables for each topology 👑. If routers don't agree on how packets or links are classified, you can get persistent routing loops 💀. So it's the network manager's job to configure multi-topology consistently, to avoid those loops 🫶.

Multi-topology TRILL can be used for all kinds of stuff 🌸. Examples: keeping separate routing domains for isolated multicast or IPv6 islands, routing a class of traffic so it skips TRILL switches that lack something that traffic needs, or steering traffic away from certain links for security, reliability, or other reasons 💅.

A topology might not be fully connected, whether on purpose, because of node or link failures, or because of misconfiguration 🙈. That splits the topology into two or more islands that can't talk to each other. In that case, end stations on different islands of the same topology can't reach each other 😭.

Multi-topology TRILL also supports regions of topology-ignorant TRILL switches inside a multi-topology campus 🧚. The catch is that those regions can only ingress, egress, or transit TRILL Data packets in the special base topology zero ✨.

1.1. Terminology

Hold up, the spec's terminology section is next 📖. It reuses the terms from [RFC6325], paraphrases some of them for convenience, and adds a few more 🎀.

  • campus: the name for a TRILL network. It's like how "bridged LAN" names a bridged network. No academic meaning, promise 💖.
  • DRB: Designated RBridge [RFC7177] 🦋.
  • FGL: Fine-Grained Labeling, 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 that supports the multi-topology feature in this document. An MT TRILL switch MUST support FGL in the sense that it MUST be FGL safe [RFC7172] 🔥.
  • RBridge: Routing Bridge, which is just another name for a TRILL switch 👑.
  • TRILL: Transparent Interconnection of Lots of Links, or Tunneled Routing in the Link Layer [RFC6325] 🫶.
  • TRILL Switch: a device that implements the TRILL protocol. TRILL switches are Intermediate Systems (routers) [IS-IS] 💅.
  • VL: VLAN Labeling, VLAN Labeled, or VLAN Label [RFC7172]. By implication, a "VL RBridge" or "VL TRILL switch" does not support FGL or MT 😭.

Now the important bit about requirement words 🚨: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they're written in ALL CAPS like that 💖. Lowercase "must" is just a regular word, bestie 🌸.

2. Topologies 🦋

In TRILL multi-topology, a topology is a subset of the TRILL switches and of the links between them, inside the campus 💅. TRILL Data packets are limited to the switches and links of their packet's topology ✨. This is built on IS-IS multi-topology [RFC5120]. Appendix A lists the differences between TRILL multi-topology and [RFC5120] 🎀.

Topology zero is the special one, covered in Section 2.1 👑. Sections 2.2, 2.3, and 2.4 go through the topology of links, TRILL switches, and TRILL Data packets, in that order 🌈.

2.1. Special Topology Zero 🧚

Topology zero is special because it's the default base topology 💖. All TRILL switches and links are considered to be in topology zero, and every switch MUST support it 🔥. So you can use topology zero for general TRILL switch access in a campus, for management messages, Bidirectional Forwarding Detection (BFD) messages [RFC7175], RBridge Channel messages [RFC7178], and similar stuff 🫶.

Multi-topology TRILL switches announce which topologies they're willing to send and receive TRILL Data packets on for a port 📣. They do this by listing those topologies in one or more MT TLVs [RFC5120], which show up in every TRILL Hello [RFC7177] they send out that port 💜. The exception is topology zero: they MUST handle it, but listing it is optional 🦋.

A link can carry TRILL Data packets in non-zero topology T only if both of these are true 🌈:

  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), then every other TRILL switch port on the link can generate explicit packet topology labeling 🔥.

2.3. TRILL Switches and Multi-Topology 👑

A TRILL switch announces the topologies it supports by listing them in one or more MT TLVs [RFC5120] in its LSP. The exception is topology zero: it MUST be supported, but listing it is optional 🫶. For robust and rapid flooding, MT TLV(s) SHOULD be advertised in core LSP fragment zero 💅.

There's no "MT capability bit" 🙈. Instead, a TRILL switch says it's MT capable by advertising support for any topology with the MT TLV. That's true even if it only advertises topology zero 😭✨.

🫶 That's the end of part 1! Part 2 picks up with Section 2.4 (TRILL Data Packets and Multi-Topology) and keeps going from there, so stay tuned, bestie 💖🎀

2.4. TRILL Data Packets and Multi-Topology 💖

okay so the topology of a TRILL Data packet is usually figured out from either (1) some field or fields sitting right there in the packet itself, or (2) the port it showed up on 🧚. Explicit topology labeling of TRILL Data packets is also a thing ✨. It can go in the data labeling area of TRILL Data packets, as we'll see below.

Fields that could help tell the topology include 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. So many options 💅.

Multi-topology does not apply to TRILL IS-IS packets or to link level control frames. Those are link local, so they 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 for the topology label is optional 🌸. Whether a port can do it could depend on the port hardware, and it gets announced with a 2-bit capability field in the Port TRILL Version sub-TLV [RFC7176], which lives in the Port Capabilities TLV in Hellos. If a Hello has no Port TRILL Capabilities sub-TLV, then explicit topology labeling is assumed to be not supported on that port. Here's the table for what each value of the Explicit Topology capability field means 👑:

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

Value 1 is the one to watch 👀. If a packet's explicit label doesn't match what the port worked out for that packet, the TRILL switch MUST discard the packet. Yep, that's strict, but it's how it works 💀.

In a Hello on Port P, a TRILL switch that advertises support for topology T but doesn't say it requires explicit topology labeling is assumed to be able to classify TRILL Data packets into topology T correctly. It can do that by looking at the packets and/or by using the fact that they arrived on port P 🌈.

When a TRILL switch sends 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 packet is in topology zero. In that case, an explicit topology label MAY be included. If a topology label isn't required like that, but every other TRILL switch on the link supports explicit topology labeling, then such a label MAY be included too 🍓.

2.4.2. The Explicit Topology Label 🦋

This section defines the explicit topology label. TRILL's use of it is covered in Section 2.4.3. Other technologies besides TRILL may use this label too ✨. The MT Label is laid out like this:

    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

Here's what each field does:

  • 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 version zero MT Label added, there are four standardized content varieties for the TRILL Data packet data labeling area. That's the area after the Inner.MacSA (or the Flag Word, if one is present [RFC7780]) and before the payload. They're shown below. TRILL Data packets received with any other data labeling get discarded 🙈. {PRI, D} is a 3-bit priority plus a drop eligibility indicator bit [RFC7780].

All MT TRILL switches MUST support FGL, in the sense of being FGL safe [RFC7172]. So 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. Less variations, less chaos, iykyk 🫶.)

  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              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1. 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         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1. 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              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1. 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         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Using S-VLAN or further stacked tags is beyond this document's scope. As [RFC6325] says, though, those are obvious extensions 🌸.

3. TRILL Multi-Topology Adjacency and Routing ✨

Routing calculations in IS-IS are based on adjacency 🔥. Section 3.1 covers multi-topology TRILL adjacency. Section 3.2 describes how nicknames get handled. Sections 3.3 and 3.4 explain how multi-topology unicast and multi-destination TRILL routing differ from base TRILL protocol routing 💜.

3.1. Adjacency 🦋

Nothing changes about how adjacency is determined or announced for topology zero. That's the same as in [RFC7177]. When a topology zero adjacency reaches the Report state, as [RFC7177] specifies, it gets announced in core LSPs using the Extended Intermediate System Reachability TLV (#22). That keeps it compatible with any legacy topology-ignorant RBridges that might not support E-L1FS FS-LSPs [RFC7780] 🫶.

Adjacency for non-zero topologies is announced 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 in Section 2.2 are true. Those are:

  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 get identified inside the TRILL protocol (for example, in the TRILL Header) by nicknames [RFC6325] [RFC7780]. You can think of a nickname as a simple 16-bit abbreviation of 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, and each one identifies it.

Nicknames are common across all topologies, just like IS-IS System IDs are 🌈. Nicknames are determined as specified in [RFC6325] and [RFC7780], using only the Nickname sub-TLVs that appear in Router Capabilities TLVs (#242) advertised by TRILL switches. The nickname allocation algorithm specifically ignores Nickname sub-TLVs that appear in MT Router Capability TLVs (#144). (However, Nickname sub-TLVs 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 keep transient inconsistencies to a minimum, all Nickname sub-TLVs a TRILL switch advertises for a particular nickname, whether in Router Capability or MT Router Capability TLVs, SHOULD appear in the same LSP PDU. If that isn't the case, then all LSP PDUs where they do occur SHOULD be flooded as an atomic action ⭐.

3.3. TRILL Unicast Routing 💅

TRILL Data packets that are TRILL unicast (the ones with TRILL Header M bit = 0) get routed based on the egress nickname. They use logically separate forwarding tables per topology T, and each table is calculated based on least cost routing within T. That means only links and nodes that support T get used 👑. So the next hop when forwarding TRILL Data packets comes from a lookup logically based on {topology, egress nickname} 🔥.

3.4. TRILL Multi-Destination Routing 🦋

TRILL sends multi-destination data packets (the ones with TRILL Header M bit = 1) over a distribution tree. Trees get designated by the nicknames that appear in the "egress nickname" field of multi-destination TRILL Data packet TRILL Headers. To keep multi-destination packets confined to a topology T and still distribute them properly, you need a distribution tree constrained to T 💖. Handling those TRILL Data packets and distribution trees in TRILL MT is covered in the subsections below 🫶.

3.4.1. Distribution Trees ✨

okay so the general rules for distribution trees and how they get picked live in [RFC6325], [RFC7172], and [RFC7780] 💅. For topology zero, the trees get figured out exactly the way those docs say, and they come out the same as they would with topology-ignorant TRILL switches 🌸.

For some non-zero topology T, the tree building and packet handling still follow [RFC6325], [RFC7172], and [RFC7780], but with these changes 👑:

  • Per [RFC5120], only links that are usable for topology T TRILL Data packets get considered when building a distribution tree for topology T 🦋. So those trees are automatically limited to, and separately span, every internally connected island of topology T. Basically, if non-zero topology T is made of disjoint islands, each tree build for T stays local to one island 🧚.
  • Only the Nickname sub-TLV, Trees sub-TLV, Tree Identifiers sub-TLV, and Trees Used sub-TLV that show up in an MT Router Capabilities TLV (#144) specifying topology T get used when deciding 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. So a Number of Trees to Compute 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 it 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 value causes one tree to be computed 💜.
  • 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.
  • 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 ✂️.

An MT TRILL switch MUST have logically separate routing tables per topology for the forwarding of multi-destination traffic 🌈.

Multi-destination TRILL Data packets get forwarded on broadcast (multi-access) links in a way that lets every other TRILL switch port on the link receive them 📡. For example, on Ethernet links they are sent with a multicast Outer.MacDA [RFC6325]. Care must be taken so that a TRILL Data packet in a non-zero topology only gets 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 🚫.

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's up to the network manager to configure and manage the TRILL switches on a link so that the desired switch is the 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 the switch recognizes and that is 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 don't 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 🧁.

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, and that won't cause any 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 means either the topology the TRILL switch put the ingressed native frame into, or the topology 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 look, 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 🧸. They 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], look, to transit TRILL switches, like normal multi-destination TRILL Data packets 📦. So they have a topology and, if that topology is non-zero, they're constrained by topology like other TRILL Data packets. Generally, when they're sent for network management purposes, they're sent in topology zero to avoid that constraint 🫧.

5.4. Implementations Considerations

MT is an optional TRILL switch capability 💜.

Experience with the actual deployment of Layer 3 IS-IS MT [RFC5120] shows 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]

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 gives centralized documentation of Ethertypes that the IEEE assigned 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. Honestly, this is the kind of thing you want to get right 🥺.

Delivery of data originating in one topology outside of that topology is generally a security policy violation, and it's one 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] 🫶.

8. References ✨

8.1. Normative References 📚

okay so these are the must-reads, bestie 💅 Anything the spec leans on that you need in order to actually get it right lives here.

8.2. Informative References 🧠

these ones are extra reading, nice to have but not required to follow the main story 🌸

Appendix A. Differences from RFC 5120 🦋

okay this is the glow-up recap 💖 TRILL multi-topology, the way this document specifies it, is different from RFC 5120 in a few key ways:

  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 🫶

big thank-yous to these legends for their comments and contributions 🎀

Vishwas Manral and Martin Vigoureux

Authors' Addresses 💌

here's where to find the people who wrote this 🧚

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
📦 where this page comes from