RFC 6327

Routing Bridges (RBridges): Adjacency

📅 published July 2011, from ietf

RFC 6327: Routing Bridges (RBridges): Adjacency 💖

okay bestie, this one is RFC 6327, and it's titled Routing Bridges (RBridges): Adjacency 🎀. It's a Standards Track document from July 2011, and it's written by D. Eastlake 3rd (Huawei), R. Perlman (Intel Labs), A. Ghanwani (Brocade), D. Dutt (Cisco Systems), and V. Manral (Hewlett Packard Co.). It updates RFC 6325 and doesn't obsolete anything. The ISSN is 2070-1721 ✨.

Abstract ✨

okay so TRILL (TRansparent Interconnection of Lots of Links) gives you optimal pair-wise data forwarding with zero configuration 🦋. It also forwards safely even during temporary loops and supports multipathing for both unicast and multicast traffic, and it's giving main character energy 👑. TRILL does this with IS-IS (Intermediate System to Intermediate System) link state routing, and it encapsulates traffic with a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges) 💅.

TRILL supports multi-access LAN (Local Area Network) links, which can have lots of end stations and RBridges attached 🌸. This document covers four parts of the TRILL LAN Hello protocol that runs on those links: adjacency, designated RBridge selection, and MTU (Maximum Transmission Unit) and pseudonode procedures, all with state machines 🧚. Point-to-point Hellos on links configured as point-to-point in TRILL don't change at all ✨.

Status of This Memo

this is an Internet Standards Track document 🔥.

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). more info on Internet Standards is in Section 2 of RFC 5741 💜.

for the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6327 🍓.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date it was published. please read these carefully, because they describe your rights and restrictions for this document 🫶. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⭐.

Table of Contents

1. Introduction ....................................................4
   1.1. Content and Precedence .....................................4
   1.2. Terminology and Acronyms ...................................5
2. The TRILL Hello Environment and Purposes ........................5
   2.1. Incrementally Replacing 802.1Q-2005 Bridges ................5
   2.2. Handling Native Frames .....................................6
   2.3. Zero or Minimal Configuration ..............................7
   2.4. MTU Robustness .............................................7
   2.5. Purposes of the TRILL Hello Protocol .......................8
3. Adjacency State Machinery .......................................9
   3.1. TRILL LAN Hellos, MTU Test, and VLANs ......................9
   3.2. Adjacency Table Entries and States ........................10
   3.3. Adjacency and Hello Events ................................11
   3.4. Adjacency State Diagram and Table .........................13
   3.5. Multiple Parallel Links ...................................14
   3.6. Insufficient Space in Adjacency Table .....................15
4. RBridge LAN Ports and DRB State ................................15
   4.1. Port Table Entries and DRB Election State .................16
   4.2. DRB Election Events .......................................16
        4.2.1. DRB Election Details ...............................17
        4.2.2. Change in DRB ......................................18
        4.2.3. Change in Designated VLAN ..........................18
   4.3. State Table and Diagram ...................................18
5. MTU Matching ...................................................20
6. Pseudonodes ....................................................21
7. TRILL Hello Reception and Transmission .........................21
   7.1. Transmitting TRILL Hellos .................................22
   7.2. Receiving TRILL Hellos ....................................23
8. Multiple Ports on the Same Link ................................24
9. Security Considerations ........................................24
10. References ....................................................24
    10.1. Normative References .....................................24
    10.2. Informative References ...................................25
11. Acknowledgements ..............................................25

1. Introduction 🦋

okay so the TRILL protocol [RFC6325] gives you optimal pair-wise data frame forwarding with no configuration, safe forwarding during temporary loops, and multipathing for both unicast and multicast traffic 💖. It does this with [IS-IS] (Intermediate System to Intermediate System) link state routing, and it encapsulates traffic in a header that includes a hop count ✨. The design supports VLANs (Virtual Local Area Networks), and it optimizes how multi-destination frames are distributed based on VLANs and IP-derived multicast groups 🌈. Devices that implement TRILL are called RBridges (Routing Bridges) 💅.

the point of this document is to make the description of four parts of the TRILL LAN (Local Area Network) Hello protocol way better 🧚. RBridges use that protocol on broadcast (LAN) links. it includes reference implementation details, but alternative implementations that interoperate on the wire are allowed too 🫶. Point-to-point Hellos used on links configured as point-to-point in TRILL don't change 🌸.

the scope of this document is limited to these aspects of the TRILL LAN Hello protocol 🔥:

  • Adjacency formation
  • DRB (Designated RBridge aka DIS (Designated Intermediate System)) election
  • Rules for 2-way and MTU (Maximum Transmission Unit) matching for advertisements
  • Creation and use of pseudonodes

for everything else in the TRILL base protocol, go read [RFC6325] 💜.

1.1. Content and Precedence 🎀

Section 2 below explains why the TRILL LAN Hello protocol is different from the Layer 3 IS-IS LAN Hello protocol [IS-IS] [RFC1195], given the environment TRILL is built for. it also covers the purposes of the TRILL LAN Hello protocol 🍓.

Section 3 describes the adjacency state machine, its states, and its relevant events 🦋.

Section 4 describes the Designated RBridge (DRB) election state machine for RBridge ports, including its states and relevant events 👑.

Section 5 describes MTU testing and matching on a TRILL link 🌈.

Section 6 talks about how pseudonodes are created and used 🧚.

Section 7 gives more details on receiving and transmitting TRILL LAN Hellos ✨.

Section 8 talks about multiple ports from one RBridge on the same link 💅.

bestie, if this document and [RFC6325] ever conflict, this document wins 👑.

1.2. Terminology and Acronyms 🌸

this document uses the acronyms from [RFC6325], plus this one extra acronym 💖:

SNPA - Subnetwork Point of Attachment

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥.

2. The TRILL-Hello Environment and Purposes 🌈

[IS-IS] has subnetwork-independent functions and subnetwork-dependent functions 🧚. right now, Layer 3 use of IS-IS supports two types of subnetworks: (1) point-to-point link subnetworks between routers, and (2) general broadcast (LAN) subnetworks 🫶. RBridges don't live in the same environment as Layer 3 routers, so instead of the broadcast (LAN) subnetwork-dependent functions from Layer 3, which are specified in [IS-IS] Section 8.4, the TRILL protocol uses modified subnetwork-dependent functions for LAN subnetworks 💅. The differences are covered in Sections 2.1 through 2.4, and then Section 2.5 sums up the purposes of the TRILL LAN Hello protocol ✨.

2.1. Incrementally Replacing 802.1Q-2005 Bridges 🦋

RBridges can incrementally replace IEEE [802.1Q-2005] bridges 💖. so RBridges need to provide similar services, like only delivering frames to links in the frame's VLAN and priority queuing of frames, to the extent that multiple queues are implemented at a particular RBridge port 👑.

RBridge ports act like IEEE [802.1Q-2005] ports when it comes to frame VLAN and priority configuration and processing, as described in Section 2.6 of [RFC6325] 🎀. when a frame comes in through an RBridge port, like any [802.1Q-2005] port, it has an associated VLAN ID and frame priority 🍓. when a frame is handed to an [802.1Q-2005] port for queuing and transmission, it must be accompanied by a VLAN ID and frame priority 🔥. whether the frame gets VLAN tagged when it's actually sent depends on whether the port is configured to "strip VLAN tags" 🌸. also, in the general case, a broadcast (LAN) link between RBridges can be a VLAN-capable bridged LAN that may be configured to partition VLANs 🧚.

because devices that restrict VLAN connectivity, like bridged LANs or provider bridging equipment, can be part of the link between RBridges, TRILL Data and TRILL IS-IS frames between RBridges use the link's Designated VLAN 🌈. the Designated VLAN for a link is set by the elected Designated RBridge (the same role as the Designated Intermediate System at Layer 3) 💜. TRILL Data frames only flow between RBridges on a link in the link's Designated VLAN, so adjacency for routing calculations is based only on connectivity in that VLAN 🫶✨.

2.2. Handling Native Frames ✨

okay bestie, so ordinary Layer 3 data packets are already tamed 💅 when an end station creates them. They come with a hop count and Layer 3 source and destination address fields. For ordinary data packets you also don't have to keep their outer Layer 2 addressing, and if they're unicast they get addressed to their first hop router. TRILL is different tho 😭 RBridges running TRILL must accept, transport, and deliver untamed "native" frames (as defined in Section 1.4 of [RFC6325]). Native frames have no TRILL hop count field, and their Layer 2 addresses tell you where they came from and are what the forwarding is based on. Those Layer 2 addresses must be kept so the frame can reach its Layer 2 destination. One result of this is that RBridge ports that give native frame service have to receive in promiscuous MAC (Media Access Control) address mode 👀, while Layer 3 router ports usually receive in a regularly selective MAC address mode.

So how does TRILL handle it? 🦋 On the link where an end station created a native frame, one RBridge "ingress"es that locally originated native frame by adding a TRILL Header with a hop count, which turns it into a TRILL Data frame. The augmented frame then gets routed to one RBridge on the link that has the destination end station (or one RBridge on each such link if it's a multi-destination frame). These final RBridges do the "egress" job: they remove the TRILL Header and deliver the original frame to its destination(s). (For TRILL's purposes, a Layer 3 router counts as an end station 🧚)

Careful bestie 🚨 You have to avoid a loop where a native frame gets egressed and then re-ingressed, because while it's in native form it has no hop count protecting it. A loop like that could multiply the frames every time around and would probably saturate all the links involved within milliseconds 💀. For TRILL, keeping a link loop-safe is more important than having data connectivity on that link.

The main TRILL defense against those loops is mandatory 💜, and it works by making sure that, as far as is practically possible, there's only one RBridge on each link in charge of ingressing and egressing native frames to and from that link. That's the Designated RBridge, which gets elected using TRILL LAN Hellos as described further in Sections 2.5 and 4 below.

Bridged LANs between RBridges can be set up in complicated ways (for example, some VLANs might pass frames in only one direction), and loop safety matters a lot, so TRILL has extra defenses against loops too 🌈. Those are beyond the scope of this document. Specifically, they defend against looping traffic that is in native format for part of the loop. These extra defenses have no effect on adjacency states or on receiving or forwarding TRILL Data frames. They only affect native frame ingress and egress.

2.3. Zero or Minimal Configuration 🎀

RBridges are expected to give service with zero configuration 🙌. The exception is services like a non-default VLAN or priority, which need configuring when they're offered by [802.1Q-2005] bridges. This is different from Layer 3 routing, where routers usually have to be configured with the subnetworks connected to each port, and so on, before they can provide service. Zero-config, no cap, it's giving easy mode ✨

2.4. MTU Robustness 🍓

TRILL IS-IS needs to be robust against links with fairly restricted MTUs, including links that only fit classic Ethernet frames, even after you add reasonable headers like VLAN tags. This matters especially for TRILL LAN Hellos, so that a unique DRB gets elected 🫶.

TRILL is also going to be used inside data centers, where it's really common for all or most of the links and switches to support frames way bigger than the classic Ethernet maximum 😭. For example, they might have an MTU big enough to handle Fiber Channel over Ethernet frames, which T11 recommends have a 2,500-byte MTU [FCoE]. It would be super beneficial for an RBridge campus with a large MTU like that to be able to use it safely 🔥.

These needs get met by limiting the size of TRILL LAN Hellos and by using MTU testing, which is described below.

2.5. Purposes of the TRILL-Hello Protocol 🦋

The TRILL-Hello protocol has three purposes. Each one is listed below with a reference to the section of this document where it's discussed:

  • a) To determine which RBridge neighbors have acceptable connectivity to be reported as part of the topology (Section 3)
  • b) To elect a unique Designated RBridge on the link (Section 4)
  • c) To determine the MTU with which it is possible to communicate with each RBridge neighbor (Section 5)

In Layer 3 IS-IS, all three of these functions are combined 🧩. Hellos may be padded to the maximum length (see [RFC3719], Section 6), so a router neighbor doesn't even get discovered if it's impossible to talk to it using maximum-sized packets. Also, even if R1 receives Hellos from a neighbor R2, if connectivity to R2 isn't 2-way (meaning R2 doesn't list R1 in R2's Hello), then R1 doesn't consider R2 as a Designated Router candidate. Because of this logic, it's possible at Layer 3 for multiple Designated Routers to get elected on a LAN, with each one representing the LAN as a pseudonode. The topology then looks like the LAN is two or more separate LANs. It's surprising, ngl, but it doesn't break Layer 3 IS-IS 🤷‍♀️.

TRILL can't do that tho 🙅‍♀️. In TRILL it's important that all RBridges on the link know about each other, and that they pick a single RBridge to be the DRB and control native frame ingress and egress on that link. Otherwise, multiple RBridges might encapsulate and decapsulate the same native frame, which forms loops that the TRILL header's hop count can't protect against, as we talked about above.

So the best way to understand the TRILL-Hello protocol is to look at each of these functions separately 💖.

There's one more thing about TRILL LAN Hellos: any subset of the information has to be able to show up in a single message and still be processable, in the spirit of IS-IS Link State PDUs (LSPs) and Complete Sequence Number PDUs (CSNPs) 🌸. TRILL-Hello frames aren't padded, but they can get really big. For instance, imagine some kind of backbone technology connecting hundreds of TRILL sites over what TRILL would see as one giant Ethernet. The RBridges connected to that cloud would think the backbone is a single link with hundreds of neighbors 😵. So the TRILL Hello uses a different Neighbor TLV [RFC6326] that lists the neighbors seen for a range of MAC (SNPA) addresses.

3. Adjacency State Machinery 👑

Each RBridge port has a port state, which is discussed in Section 4, plus a table of zero or more adjacencies, which is discussed in this section. The states these adjacencies can be in, the events that cause state changes, the actions tied to those state changes, and a state table and diagram are all given below 💅.

3.1. TRILL LAN Hellos, MTU Test, and VLANs 🌈

On links that aren't configured as point-to-point, the adjacencies reported in LSPs are determined using TRILL LAN Hellos (see also Section 7) and an optional MTU test. For an adjacency to be reported in an LSP of the RBridge in question, appropriate TRILL LAN Hello exchange and satisfaction of the MTU test (if the MTU test is enabled, see Section 5) are required 📣.

Bridges acting as glue on the LAN might be set up so that some VLANs get partitioned, so RBridges need to transmit Hellos with multiple VLAN tags 🎀. The simplest idea on paper might have been for all RBridges to send up to 4,094 times as many Hellos, one with each legal VLAN ID enabled at each port. But that would obviously be a performance disaster 💀. So the TRILL protocol says that if RB1 knows it isn't the DRB, it only transmits its Hellos on a limited set of VLANs. Only an RBridge that believes it's the DRB on a port "sprays" its TRILL Hellos across all of its enabled VLANs at that port (and it can be configured to send on only a subset of those). The details are given in [RFC6325], Section 4.4.3.

If the MAC (SNPA) address of more than one RBridge port on a link is the same, all but one of those ports get put in the Suspended state (see Section 4). They don't take part in the link, except to keep an eye on whether they should stay suspended 👀.

All TRILL LAN Hellos that an RBridge sends on a particular port MUST have the same source MAC address, priority, desired Designated VLAN, and Port ID, no matter which VLAN the Hello goes out on 🫶. Sure, the priority and desired Designated VLAN can change every now and then, but then the new value has to be used in all TRILL Hellos on that port, regardless of VLAN, periodt 💯.

3.2. Adjacency Table Entries and States 🦋

Each adjacency is in one of the following four states:

Down: This is a virtual state, made up just for convenience when creating state diagrams and tables. It means the adjacency doesn't exist, and there's no entry for it in the adjacency table 🫥.

Detect: An adjacent neighbor has been detected either (1) not on the Designated VLAN, or (2) on the Designated VLAN but without 2-way connectivity or the MTU of that connectivity having been confirmed yet 👀.

2-Way: 2-way connectivity to the neighbor has been found on the Designated VLAN, but MTU testing is enabled and hasn't confirmed yet that the connectivity meets the campus minimum MTU requirement 🌸.

Report: There's 2-way connectivity to the neighbor on the Designated VLAN, and either MTU testing has confirmed that the connectivity meets the campus minimum MTU requirement or MTU testing isn't enabled. This connectivity gets reported in an LSP (with appropriate provision for the link pseudonode, if there is one, as described in Section 6) 🔥✨.

For an adjacency in any of the three non-down states (Detect, 2-Way, or Report), there's an adjacency table entry. That entry gives the state of the adjacency and also includes the information listed below 📋.

  • The address of the neighbor (that is, its SNPA address, usually a 48-bit MAC address), plus the Port ID and the System ID from the received Hellos. Together, these three things uniquely identify the adjacency 🪪.
  • Exactly two Hello holding timers, each one a 16-bit unsigned integer number of seconds: a Designated VLAN holding timer and a non-Designated VLAN holding timer ⏱️.
  • The 7-bit unsigned priority of the neighbor to be the DRB 👑.
  • The VLAN that the neighbor RBridge wants to be the Designated VLAN on the link, called the desired Designated VLAN 🎀.

3.3. Adjacency and Hello Events 💖

okay so these are the events that can shake up an adjacency 🦋 (aka the stuff that changes its state):

  • A0. Receive a TRILL Hello whose source MAC address (SNPA) is equal to that of the port it came in on. 🫣 This one is extra special and gets its own handling right after this list. It doesn't show up in the state table or diagram, so it's the odd one out 💅
  • A1. Receive a TRILL Hello (not an A0 event) on the Designated VLAN with a TRILL Neighbor TLV that explicitly lists the receiver's (SNPA) address. ✨
  • A2. Receive a TRILL Hello (not an A0 event) that either (1) is not on the Designated VLAN (any TRILL Neighbor TLV in a Hello like that gets ignored 🙈) or (2) is on the Designated VLAN but has no TRILL Neighbor TLV covering an address range that includes the receiver's (SNPA) address. 🌸
  • A3. Receive a TRILL Hello (not an A0 event) on the Designated VLAN with one or more TRILL Neighbor TLVs covering an address range that includes the receiver's (SNPA) address, and none of them list the receiver. 🧚
  • A4. The expiration of one or both Hello holding timers, which results in both of them being expired. ⏰
  • A5. The Designated VLAN Hello holding timer expires, but the non-Designated VLAN Hello holding timer still has time left until it expires. 🍓
  • A6. MTU test successful. 🎉
  • A7. MTU test was successful but now fails. 💀
  • A8. The RBridge port goes operationally down. 📴

okay so for the special A0 event 🫶, the Hello gets examined to figure out if it's higher priority to be the DRB than the port it came in on, as described in Section 4.2.1. If it's lower priority than the receiving port, it's discarded with no further action. If it's higher priority, then any adjacencies for that port get discarded (transitioned to the Down state), and the port is suspended as described in Section 4.2. 🔥

the receipt of a TRILL LAN Hello with a source MAC (SNPA) address different from that of the receiving port (aka events A1, A2, or A3) causes the following actions. The exception is where the Hello would create a new adjacency table entry, the table is full, or the Hello is too low priority to displace an existing entry as described in Section 3.6. 🙃 The Designated VLAN used in these actions is the Designated VLAN dictated by the DRB determined without taking the received TRILL LAN Hello into account (see Section 4). 👑

  • If the receipt of the Hellos creates a new adjacency table entry, the neighbor RBridge MAC (SNPA) address, Port ID, and System ID are set from the Hello. 🎀
  • The appropriate Hello holding timer for the adjacency, depending on whether or not the Hello was received on the Designated VLAN, is set to the Holding Time field of the Hello. If the receipt of the Hello is creating a new adjacency table entry, the other timer is set to expired. ⏳
  • The priority of the neighbor RBridge to be the DRB is set to the priority field of the Hello. 💜
  • The VLAN that the neighbor RBridge wants to be the Designated VLAN on the link is set from the Hello. 🌈
  • If the creation of a new adjacency table entry or the priority update above changes the results of the DRB election on the link, the appropriate RBridge port event (D2 or D3) occurs, after the above actions, as described in Section 4.2. 😭
  • If there is no change in the DRB, but the neighbor Hello is from the DRB and has a changed Designated VLAN from the previous Hello received from the DRB, the result is a change in Designated VLAN for the link as specified in Section 4.2.3. 🦋

an A4 event that results in both Hello holding timers for an adjacency being expired and the adjacency going Down may also result in a D3 event as described in Section 4.2. 💅

concerning events A6 and A7: if MTU testing is not enabled, A6 is considered to occur immediately upon the adjacency entering the 2-Way state, and A7 cannot occur. 🙈

see further TRILL LAN Hello receipt details in Section 7. ✨

3.4. Adjacency State Diagram and Table 🌸

the table below shows the transitions between the states defined above based on the events defined above. Bestie, read it like a cheat sheet 📋

           | Event |  Down  | Detect | 2-Way  | Report |
           +-------+--------+--------+--------+--------+
           |  A1   | 2-Way  | 2-Way  | 2-Way  | Report |
           |  A2   | Detect | Detect | 2-Way  | Report |
           |  A3   | Detect | Detect | Detect | Detect |
           |  A4   |  N/A   | Down   | Down   | Down   |
           |  A5   |  N/A   | Detect | Detect | Detect |
           |  A6   |  N/A   |  N/A   | Report | Report |
           |  A7   |  N/A   |  N/A   | 2-Way  | 2-Way  |
           |  A8   | Down   | Down   | Down   | Down   |

N/A means the event to the left is Not Applicable in the state at the top of the column. ❌ These events only affect a single adjacency. The special A0 event transitions all adjacencies to Down, as explained right after the list of adjacency events above. 🫣

the diagram below presents the same information as the state table, just make it visual 🎨

                            +---------------+
                            |     Down      |<--------+
                            +---------------+         |
                              |     |  ^  |           |
                         A2,A3|     |A8|  |A1         |
                              |     +--+  |           |
                              |           +-----------|---+
                              V                       |   |
                            +----------------+ A4,A8  |   |
                     +----->|      Detect    |------->|   |
                     |      +----------------+        |   |
                     |        |  |         ^          |   |
                     |      A1|  |A2,A3,A5 |          |   |
                     |        |  +---------+          |   |
                     |        |                       |   |
                     |        |          +------------|---+
                     |        |          |            |
                     |        V          V            |
                     |A3,A5 +----------------+ A4,A8  |
                     |<-----|     2-Way      |------->|
                     |      +----------------+        |
                     |       |   ^ |        ^         |
                     |     A6|   | |A1,A2,A7|         |
                     |       |   | +--------+         |
                     |       |   |                    |
                     |       |   |A7                  |
                     |       V   |                    |
                     |A3,A5 +-------------+ A4,A8     |
                     |<-----|   Report    |---------->|
                            +-------------+
                              |         ^
                              |A1,A2,A6 |
                              +---------+

there can be multiple parallel adjacencies between neighbor RBridges that are visible to TRILL. 💜 (multiple low-level links that have been bonded together by technologies such as link aggregation [802.1AX] look like a single link to TRILL, so only a single TRILL adjacency could be established over them 🔗)

any such links that have pseudonodes (see Section 6) are distinguished in the topology. adjacencies like that, if they're in the Report state, appear in LSPs as per Section 6. 🌟 However, there can be multiple parallel adjacencies without pseudonodes, because they're point-to-point adjacencies or LAN adjacencies where a pseudonode isn't being created. Parallel, non-pseudonode adjacencies in the Report state appear in LSPs as a single adjacency. The cost of such an adjacency MAY be adjusted downwards to account for the parallel paths. 🍃 Multipathing across such parallel connections can be freely done for unicast TRILL Data traffic on a per-flow basis, but it's restricted for multi-destination traffic, as described in Section 4.5.2 (point 3) and Appendix C of [RFC6325]. 🚦

3.6. Insufficient Space in Adjacency Table 🥲

if the receipt of a TRILL LAN Hello would create a new adjacency table entry (aka would transition an adjacency out of the Down state), there may be no space for the new entry. 😬 In that case, the DRB election priority (see Section 4.2.1) of the new entry that would be created is compared with that priority for the existing entries. If the new entry is higher priority than the lowest priority existing entry, it replaces the lowest priority existing entry, which is transitioned to the Down state. 🫡

4. RBridge LAN Ports and DRB State 🌷

the information at an RBridge associated with each of its LAN ports includes the following 📝:

  • Enablement bit, which defaults to enabled. 🟢
  • SNPA address (usually a 48-bit MAC address) of the port. 🪪
  • Port ID, used in TRILL Hellos sent on the port. 🆔
  • The Holding Time, used in TRILL Hellos sent on the port. ⏱️
  • The Priority to be the DRB, used in TRILL Hellos sent on the port. 👑
  • The DRB status of the port, determined as specified below. 🎯
  • A 16-bit unsigned Suspension timer, measured in seconds. ⏲️
  • The desired Designated VLAN. The VLAN this RBridge wants to be the Designated VLAN for the link out this port, used in TRILL Hellos sent on the port. 💫
  • A table of zero or more adjacencies (see Section 3). 🧩

4.1. Port Table Entries and DRB Election State 👑

okay so the TRILL version of the DIS (Designated Intermediate System) on a link is the DRB, or Designated RBridge. 🎀 The DRB election state machinery is described below.

each RBridge port is in one of the following four DRB states:

  • Down: The port is operationally down. 📉 It might be administratively disabled or down at the link layer. In this state, there will be no adjacency table entries for the port, and no TRILL Hellos or other IS-IS PDUs or TRILL Data frames are accepted or transmitted. 🚫
  • Suspended: Operation of the port is suspended because there is a higher priority port on the link with the same MAC (SNPA) address. ⏸️ This is the same as the Down state, with the exception that TRILL Hellos are accepted for the sole purpose of determining whether to change the value of the Suspension timer for the port as described below. ⏳
  • DRB: The port is the DRB and can receive and transmit TRILL Data frames. 👑🚀
  • Not DRB: The port is deferring to another port on the link, which it believes is the DRB, but it can still receive and transmit TRILL Data frames. 🫶🌈

4.2. DRB Election Events 💅✨

okay so the DRB state of a port can change because of these events, bestie 🫶

  • D1: the suspension timer runs out while the port is in the Suspended state, or the port gets enabled 🌸
  • D2: the adjacency table for the port changes, and now there are entries for one or more other RBridge ports on the link that look higher priority to be the DRB than the local port 👑
  • D3: the port is not Down or Suspended, and the adjacency table changes so there are now no entries for other RBridge ports on the link that look higher priority to be the DRB than the local port 🦋
  • D4: a TRILL Hello shows up with the same MAC address (SNPA) as the receiving port and higher priority to be the DRB, as described for event A0 💀
  • D5: the port becomes operationally down 🥀

ngl D1 counts as happening on RBridge boot if the port is administratively and link-layer enabled 🎀

D4 is the big drama 😭 It makes the port go into the Suspended state, and every adjacency on that port gets discarded (moved to the Down state). If the port was in some other state before, the suspension timer gets set to the Holding Time in the Hello that caused D4. If it was already Suspended, the timer gets set to the maximum of its current value and that Holding Time. periodt 🧚

4.2.1. DRB Election Details 🔍

D2 and D3 are just what losing and winning the DRB election at the port looks like 🏆

The candidates are the local RBridge plus every RBridge with an adjacency on the port that is in an adjacency state other than Down state. The winner is the one with the highest priority to be the DRB. That gets decided using the 7-bit priority field in that RBridge's received Hellos, compared against the local port's priority to be the DRB field. If there's a tie, the MAC (SNPA) address breaks it, then the Port ID as a secondary tiebreaker, then the System ID as a tertiary tiebreaker. All of these fields are compared as unsigned integers, and the bigger magnitude counts as higher priority 🌈

The secondary and tertiary tiebreakers should only be needed in rare situations 🙈 where several ports have the same priority and MAC (SNPA) address and some of them aren't suspended yet. Here's an example: RB1 has low priority to be the DRB on the link, but it gets Hellos from two other ports on the link. Those two ports have the same MAC address as each other and higher priority to be the DRB. One of them will get suspended, stop sending Hellos, and its Hello that RB1 received will eventually time out. Until then, RB1 can use the tiebreakers to figure out which port is the DRB, and so which port's Hello to believe for things like setting the Designated VLAN on the link 🫶

4.2.2. Change in DRB 🔄

D2 and D3 both come from a change in the apparent DRB on the link. Unnecessary DRB changes should be avoided, especially on links offering native frame service, because a DRB change will generally cause a transient interruption to native frame service 😬

If a DRB change on the link also changes the Designated VLAN on the link, the actions in Section 4.2.3 get taken.

If an RBridge switches in either direction between being the Designated RBridge and not being the Designated RBridge at a port, that will generally change which VLANs that RBridge sends Hellos on at that port, as specified in Section 4.4.3 of [RFC6325] 🦋

4.2.3. Change in Designated VLAN 🎀

Unnecessary changes to the Designated VLAN on a link should be avoided, bestie, because a change there can cause a transient interruption to TRILL Data forwarding on the link 😭 When it's practical, all RBridge ports on a link should be configured with the same desired Designated VLAN. That way, if the winner of the DRB election changes for any reason, the Designated VLAN stays the same 💖

If an RBridge detects a change in the Designated VLAN on a link, then, for all adjacency table entries for a port to that link, it does the following steps in this order:

  • The non-Designated VLAN Hello Holding timer is set to the maximum of its time to expiration and the current time to expiration of the Designated VLAN Hello Holding timer.
  • The Designated VLAN Hello Holding timer is then set to expired (if necessary), and an event A5 occurs for the adjacency (see Section 3.3).

If the Designated VLAN for a link changes, that will generally change which VLANs an RBridge port on that link sends Hellos on, as specified in Section 4.4.3 of [RFC6325] ✨

4.3. State Table and Diagram 📊

The table below shows how the DRB states change based on the events above:

          | Event | Down   | Suspend |  DRB    | Not DRB |
          +-------+--------+---------+---------+---------+
          |  D1   | DRB    | DRB     |  N/A    |  N/A    |
          |  D2   |  N/A   |  N/A    | Not DRB | Not DRB |
          |  D3   |  N/A   |  N/A    | DRB     | DRB     |
          |  D4   |  N/A   | Suspend | Suspend | Suspend |
          |  D5   | Down   | Down    | Down    | Down    |

N/A means the event on the left is Not Applicable in the state at the top of the column 🙅

The diagram below shows the same info as the state table, just in picture form 🧩

              +-------------+
              |  Down       |<--------------+
              +-+---+-------+     ^         |
                |   |   ^         |         |
              D1|   |D5 |         |         |
                |   +---+         |D5       |
                |                 |         |
                |        +--------+----+    |
                |        |  Suspended  |<---|---+
                |        +-+-----+-----+    |   |
                |        D1|  ^  |   ^      |   |
                |          |  |  |D4 |      |   |
                |          |  |  +---+      |   |
                |          |  |             |   |
                |          |  |D4           |   |
                V          V  |             |   |
              +---------------+-+ D5        |   |
              |          DRB    |---------->|   |
              +--------+--+-----+           |   |
                  ^    |  |  ^              |   |
                  |  D2|  |D3|              |   |
                  |    |  +--+              |   |
                  |    |         D4         |   |
                  |D3  |  +-----------------|---+
                  |    V  |                 |
             +----+-------+-+ D5            |
             |   Not DRB    |-------------->|
             +----+---------+
                  |    ^
                  |D2  |
                  +----+

5. MTU Matching 📏

The point of MTU testing is to make sure the links in the campus topology can pass TRILL IS-IS and Data frames at the RBridge campus MTU 🌸

An RBridge, RB1, works out the desired campus link MTU by taking the minimum of its own originatingL1LSPBufferSize and the originatingL1LSPBufferSize of the other RBridges in the campus, as advertised in the link state database. The result is never less than 1,470 bytes 🙌 In Layer 3 [IS-IS], originatingL1LSPBufferSize is limited to the range 512 to 1,492 bytes inclusive. In TRILL, though, it's limited to the range 1,470 to 65,535 bytes inclusive 🧚

MTU testing is optional, but it is mandatory for an RBridge to respond to an MTU-probe PDU with an MTU-ack PDU [RFC6325] [RFC6326] 💜 Whether to multicast or unicast MTU-probes and MTU-acks is up to the implementation. The burden on the link is usually lowest if you multicast MTU-probes when you want a response from all the other RBridges on the link (like when initializing or re-confirming MTU), unicast MTU-probes when you only want a response from one RBridge (like one that just got detected on the link), and unicast all MTU-ack frames 🦋

RB1 can test the MTU size to RB2 as described in Section 4.3.2 of [RFC6325]. For this, MTU testing only happens in the Designated VLAN 🎀 An adjacency that fails the MTU test at the campus MTU won't enter the Report state, and if it's already in that state, it leaves it. So an adjacency that fails the MTU test won't be reported by the RBridge doing the test. Inclusion in least-cost route computation requires the adjacency to be reported by both ends, so as long as the MTU failure gets noticed by the RBridge at either end of the adjacency, that adjacency won't get used 🚫

If it tests MTU, RB1 reports either the largest size for which the MTU test succeeds, or a flag saying it fails at the campus MTU. That report always shows up with the neighbor in RB1's TRILL Neighbor TLV. RB1 MAY also report this with the adjacency in an Extended Reachability TLV in RB1's LSP. RB1 MAY choose to test MTU sizes greater than the desired campus MTU as well as the desired campus MTU 🌈

Most types of TRILL IS-IS frames, like LSPs, can use the campus MTU. The exceptions are TRILL Hellos, which must be kept small for loop safety, and the MTU PDUs, whose size has to be adjusted for the tests being run 🙈

6. Pseudonodes 🫧

The Designated RBridge (DRB), determined as described above, controls whether a pseudonode gets used on a link 👑

If the DRB sets the bypass pseudonode bit in its TRILL LAN Hellos, the RBridges on the link (including the DRB) just directly report all of their adjacencies on the LAN that are in the Report state. If the DRB does not set the bypass pseudonode bit in its TRILL Hellos, then: (1) the DRB reports its adjacency to the pseudonode in its LSP, (2) the DRB sends LSPs on behalf of the pseudonode, in which it reports adjacency to all other RBridges on the link where it sees that adjacency in the Report state, and (3) all other RBridges on the link report their adjacency to the pseudonode if they see their adjacency to the DRB as being in the Report state, and they don't report any other adjacencies on the link. Setting the bypass pseudonode bit has no effect on how LSPs are flooded on a link. It only affects which LSPs get generated 🧠

Lots of links between RBridges will actually be point-to-point 🫶 In that case, a pseudonode just adds complexity. For example, say RB1 and RB2 are the only RBridges on the link, and RB1 is the DRB. If RB1 creates a pseudonode that gets used, there are 3 LSPs: one for, say, RB1.25 (the pseudonode), one for RB1, and one for RB2. RB1.25 reports connectivity to RB1 and RB2, and RB1 and RB2 each just say they're connected to RB1.25. But if the DRB RB1 sets the bypass pseudonode bit in its Hellos, there are only 2 LSPs: RB1 and RB2, each reporting connectivity to each other 💖

A DRB SHOULD set the bypass pseudonode bit in its Hellos if it hasn't seen at least two simultaneous adjacencies in the Report state since it last rebooted or was reset by network management 🌸

7. TRILL-Hello Reception and Transmission ✨

okay so this section is all about how TRILL LAN Hellos get received and sent 🫶 bestie this is the good stuff

TRILL LAN Hellos, just like every other TRILL IS-IS frame, are mainly told apart from Layer 3 IS-IS frames because they go to the All-IS-IS-RBridges multicast address (01-80-C2-00-00-41) 💌 TRILL IS-IS frames also carry the L2-IS-IS Ethertype (0x22F4) and are Ethertype encoded 🎀

Future TRILL extensions might use Level 2 IS-IS, but for now [RFC6325] specifies TRILL using a single Level 1 Area with Area Address zero (see Section 4.2 of [RFC6326]) 🌸

Layer 3 IS-IS routers often connect to other Layer 3 routers in a different routing domain 🦋 When that happens, the externalDomain flag (see [IS-IS]) is usually set on the port that makes the connection. Setting this flag to "true" means no IS-IS PDUs get sent out that port, and any IS-IS PDUs received there get discarded, Hellos included 🙈 RBridges live in a totally different world where all the neighbor RBridges merge into one single campus 🌈 So for loop safety, RBridges either don't implement the externalDomain flag or implement it with the fixed value "false" 💅 They send and receive TRILL LAN Hellos on every port that isn't disabled or configured as point-to-point ✨

7.1. Transmitting TRILL Hellos

TRILL LAN Hellos go out on the same timing as Layer 3 IS-IS LAN Hellos [IS-IS] 🕰️ but no Hellos get sent if a port is in the Suspended or Down states 🚫

TRILL-Hello PDUs SHOULD NOT be padded 🙅‍♀️ and they MUST NOT be sent exceeding 1,470 octets 💀 Still, a received TRILL Hello longer than 1,470 octets gets processed normally, so no drama on that side 🫶

TRILL-Hello PDU headers MUST conform to the following:

  • Maximum Area Addresses equal to 1.
  • Circuit Type equal to 1.

Each TRILL Hello MUST contain an Area Addresses TLV listing only the single Area zero 🌷 It also MUST contain an MT Port Capabilities TLV with a VLAN-FLAGS sub-TLV [RFC6326] 💜 If a Protocols Supported TLV is present, it MUST list the TRILL NLPID (0xC0) ✨

The TRILL Neighbor TLV sent in a Hello MUST show the neighbor information, as sensed by the transmitting RBridge, for the VLAN the Hello goes out on 👀 Implementations that follow this document keep that info per-VLAN only for the Designated VLAN, so they only send the TRILL Neighbor TLV in TRILL Hellos on the Designated VLAN 🍓

It is RECOMMENDED that, if there's enough room, one or more TRILL Neighbor TLVs (as described in Section 4.4.2.1 of [RFC6325]) cover the entire range of MAC addresses and list every adjacency with a non-zero Designated VLAN Hello Holding time 🦄 If there are no such adjacencies, send an empty list of neighbors instead 🫧 These should be in TRILL Hellos sent on the Designated VLAN 🎀 If that's not possible, then TRILL Neighbor TLVs covering sub-ranges of MAC addresses should be sent so the entire range is covered reasonably promptly ⏰

Here's the lowkey important bit: delays in sending TRILL Neighbor TLVs will delay adjacencies advancing to the Report state, and they'll delay discovering some link failures 😭 Rapid detection (like sub-second) of link or node failures is best handled by a protocol built for that, such as Bidirectional Forwarding Detection (BFD) [RFC5880] 🏃‍♀️💨 Using BFD with TRILL will be specified in a separate document 📄

To make sure any RBridge RB2 can definitively tell whether RB1 can hear RB2, RB1's neighbor list MUST eventually cover every possible range of IDs 🔍 That's within a period that depends on RB1's policy, and it doesn't have to happen within any specific period like its Holding Time ⏳ In other words, if X1 is the smallest ID reported in one of RB1's neighbor lists and the "smallest" flag is not set, then X1 MUST appear in a different neighbor list as well, as the largest ID reported in that fragment 🧩 Lists are allowed to overlap too, as long as there's no gap, so no range (say between Xi and Xj) ever goes missing from every list 💖

A TRILL Hello MAY also contain any TLV permitted in a Layer 3 IS-IS Hello 🌈 TLVs that are unsupported or unknown just get ignored 🙈

7.2. Receiving TRILL Hellos

If a frame has the All-IS-IS-RBridges multicast address and the L2-IS-IS Ethertype, it gets checked to see if it looks like an IS-IS PDU 🔎 If it does, and it looks like a LAN Hello PDU, these tests happen next 🧐

  • If the Circuit Type field is not 1, the PDU is discarded 🗑️
  • If the PDU doesn't contain an Area Address TLV, or it contains an Area Address TLV that isn't the single Area Address zero, it is discarded 🚮
  • If the Hello includes a Protocols Supported TLV that doesn't list the TRILL NLPID (0xC0), it is discarded. Having no Protocols Supported TLV at all is totally acceptable 🙆‍♀️
  • If the Hello doesn't contain an MT Port Capabilities TLV with a VLAN-FLAGS sub-TLV [RFC6326], it is discarded 😤
  • If the maximumAreaAddresses field of the PDU is not 1, it is discarded 🙅
  • If IS-IS authentication is in use on the link and the PDU either has no Authentication TLV or its validation fails, it is discarded 🔐

If none of the rules above got triggered and the frame is parseable, it's assumed to be a well-formed TRILL Hello received on the link ✅ It then gets treated as an event A0, A1, A2, or A3, based on the criteria in Section 3.3 🎯

It's possible for an RBridge RB1 to have multiple ports on the same link that aren't in the Suspended state 👯 It matters that RB1 can tell which of its ports are on the same link 👀 RB1 can figure this out by receiving TRILL LAN Hello messages with the same LAN ID on multiple ports 🔍

The DRB election is port-based (see Section 4), and only the Hellos from the elected port can do certain jobs, like dictating the Designated VLAN or deciding whether a pseudonode will be used 👑 The election also names the RBridge with that port as the DRB for the link, though 💅 An RBridge can choose to load split some tasks among its ports on the link if it has more than one and it's safe to do so, as described in Section 4.4.4 of [RFC6325] 🌸

9. Security Considerations 🔐

This memo provides improved documentation of some aspects of the TRILL base protocol standard, particularly four aspects of the TRILL LAN Hello protocol. It does not change the security considerations of the TRILL base protocol. See Section 6 of [RFC6325]. 💀 Please take the base protocol's security considerations seriously, bestie 🫶

10. References 📚

10.1. Normative References

  • [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002.
  • [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC6325] Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, July 2011.
  • [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "TRILL Use of IS-IS", RFC 6326, July 2011.

10.2. Informative References

  • [802.1AX] "IEEE Standard for Local and metropolitan area networks / Link Aggregation", 802.1AX-2008, 1 January 2008.
  • [802.1Q-2005] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006.
  • [FCoE] From www.t11.org discussion of "FCoE Max Size" generated from T11/09-251v1, 04/27/2009, "FCoE frame or FCoE PDU".
  • [RFC3719] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", February 2004.
  • [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.

11. Acknowledgements 🫶

The authors of [RFC6325], those listed in the Acknowledgements section of [RFC6325], and the contributions of Jari Arkko, Ayan Banerjee, Les Ginsberg, Sujay Gupta, David Harrington, Pete McCann, Erik Nordmark, and Mike Shand, to this document, are hereby acknowledged 🌟 Thank you all, you're literally the reason this works 💖

Authors' Addresses 💌

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

Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Radia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054-1549 USA

Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Anoop Ghanwani
Brocade
130 Holger Way
San Jose, CA 95134 USA

Phone: +1-408-333-7149
EMail: anoop@alumni.duke.edu
Dinesh G. Dutt
Cisco Systems
170 Tasman Drive
San Jose, CA 95134-1706 USA

Phone: +1-408-527-0955
EMail: ddutt@cisco.com
Vishwas Manral
Hewlett Packard Co.
19111 Pruneridge Ave,
Cupertino, CA 95014 USA

Phone: +1-408-447-1497
EMail: vishwas.manral@hp.com
📦 where this page comes from