RFC 7177
Transparent Interconnection of Lots of Links (TRILL): Adjacency
Transparent Interconnection of Lots of Links (TRILL): Adjacency ✨
Okay bestie, this is RFC 7177, and it's giving real Standards Track energy 💅 It came out in May 2014 with the ISSN 2070-1721. The authors are D. Eastlake 3rd (Huawei), R. Perlman (Intel Labs), A. Ghanwani (Dell), H. Yang (Cisco), and V. Manral (Ionos Corp.). It obsoletes RFC 6327 and updates RFC 6325 🎀
Abstract
okay so TRILL (Transparent Interconnection of Lots of Links) supports arbitrary link technologies between TRILL switches 🌈 That covers point-to-point links and multi-access Local Area Network (LAN) links, where many TRILL switches and end stations can hang out together. TRILL runs on Intermediate System to Intermediate System (IS-IS) routing. This document specifies how IS-IS adjacencies between TRILL switches (also known as RBridges, or Routing Bridges) get established, reported, and terminated 🦋 It also covers four other link-local aspects: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams show up where they make sense. This document obsoletes RFC 6327 and updates RFC 6325 ✨
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to send feedback on it can be found at http://www.rfc-editor.org/info/rfc7177.
Copyright Notice
Copyright (c) 2014 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 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.
Table of Contents 🧚
1. Introduction ....................................................4
1.1. Content and Precedence .....................................5
1.2. Terminology and Acronyms ...................................5
2. The TRILL Hello Environment and Purposes ........................6
2.1. RBridge Interconnection by Ethernet ........................6
2.2. Handling Native Frames .....................................7
2.3. Zero or Minimal Configuration ..............................8
2.4. MTU Robustness .............................................8
2.5. Purposes of the TRILL Hello Protocol .......................9
3. Adjacency State Machinery ......................................10
3.1. TRILL Hellos, Ports, and VLANs ............................10
3.2. Adjacency Table Entries and States ........................11
3.3. Adjacency and Hello Events ................................12
3.4. Adjacency State Diagram and Table .........................15
3.5. Multiple Parallel Links ...................................17
3.6. Insufficient Space in Adjacency Table .....................17
4. LAN Ports and DRB State ........................................17
4.1. Port Table Entries and DRB Election State .................18
4.2. DRB Election Events .......................................19
4.2.1. DRB Election Details ...............................20
4.2.2. Change in DRB ......................................20
4.2.3. Change in Designated VLAN ..........................21
4.3. Port State Table and Diagram ..............................21
5. MTU Matching ...................................................22
6. BFD-Enabled TLV and BFD Session Bootstrapping ..................24
7. Pseudonodes ....................................................25
8. More TRILL Hello Details .......................................26
8.1. Contents of TRILL Hellos ..................................27
8.2. Transmitting TRILL Hellos .................................27
8.2.1. TRILL Neighbor TLVs ................................28
8.3. Receiving TRILL Hellos ....................................29
9. Multiple Ports on the Same Broadcast Link ......................29
10. IANA Considerations ...........................................30
11. Security Considerations .......................................30
Appendix A. Changes from RFC 6327 .................................31
Appendix B. Changes to RFC 6325 ...................................31
Normative References...............................................32
Informative References.............................................33
Acknowledgements...................................................341. Introduction 💖
okay so TRILL [RFC6325] is the protocol that gives you optimal pair-wise data frame forwarding with zero configuration 🫶 It also gives you safe forwarding even during transient loops, and it supports both unicast and multicast traffic that can use multiple paths in multi-hop networks with arbitrary topology. End stations plug into TRILL switches over Ethernet, but the TRILL switches themselves can be linked up with arbitrary link technology. TRILL pulls this off by using [IS-IS] (Intermediate System to Intermediate System) link-state routing [RFC1195] [RFC7176], plus a header in TRILL Data packets that carries a hop count. The design supports data labeling by Virtual Local Area Networks (VLANs) and fine-grained labels [RFC7172]. It also optimizes how multi-destination frames get distributed, based on data label and multicast groups 🌸 Devices that implement TRILL are called TRILL switches or RBridges (Routing Bridges).
This document gives detailed specs for five of the link-local aspects of the TRILL protocol that are used on broadcast links (also called LAN or multi-access links). Three of those aspects are also used on point-to-point (P2P) links. It includes state diagrams and implementation details where they're needed. Alternative implementations that interoperate on the wire are permitted ✨
The scope of this document is limited to the following aspects of the TRILL protocol. Their applicability, along with the most relevant section of this document, looks like this:
LAN P2P Section Link-Local Aspect
--- --- ------- ----------------------------------------------
X X 3 Adjacency formation and dissolution
X 4 DRB (Designated RBridge) election
X X 5 MTU (Maximum Transmission Unit) matching
X X 6 1-hop BFD (Bidirectional Forwarding Detection)
for adjacency
X 7 Creation and use of pseudonodes [IS-IS]
Table 1: LAN/P2P ApplicabilityThere is no DRB (also known as DIS (Designated Intermediate System)) election and no pseudonode creation on links configured as point-to-point 🙈
For other aspects of the TRILL base protocol, see [RFC6325], [RFC6439], [RFC7180], and [ESADI].
This document obsoletes [RFC6327]. See Appendix A for a summary of changes from [RFC6327]. This document updates [RFC6325] as described in Appendix B.
1.1. Content and Precedence 🍓
In cases of conflict between this document and [RFC6325], this document prevails. 👑
Section 2 below explains why the TRILL Hello protocol is different from the Layer 3 IS-IS Hello protocol, given the environment TRILL is designed for. It also describes the purposes of the TRILL 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 LAN ports, its states, and its relevant events.
Section 5 describes MTU testing and matching on a TRILL link.
Section 6 discusses one-hop BFD session bootstrapping in connection with adjacency.
Section 7 discusses pseudonode creation and use on LAN links.
Section 8 gives more details on the reception and transmission of TRILL Hellos.
Section 9 discusses the case of multiple ports from one RBridge on the same link.
1.2. Terminology and Acronyms 🦋
This document uses the acronyms defined in [RFC6325], supplemented by the following additional acronyms:
- BFD - Bidirectional Forwarding Detection [RFC7175].
- SNPA - Subnetwork Point of Attachment [IS-IS].
- TRILL switch - an alternative name for an RBridge.
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. The Layer 3 router environment and the TRILL RBridge environment are pretty different, so instead of the subnetwork-dependent functions used at Layer 3 (specified in Sections 8.2 and 8.4 of [IS-IS]), TRILL uses modified subnetwork-dependent functions for point-to-point subnetworks and broadcast (LAN) subnetworks 💅 The differences between the TRILL and Layer 3 environments are covered in Sections 2.1 through 2.4, followed by a summary in Section 2.5 of the purposes of the TRILL Hello protocol 🌈
2.1. RBridge Interconnection by Ethernet
okay so TRILL can connect RBridges over multi-access LAN links like Ethernet 🦋 Since that includes general bridged LANs [802.1Q], the links between RBridges might have devices or services in the middle that can restrict VLAN connectivity, like [802.1Q] bridges or carrier Ethernet services. ngl that's a lot of gatekeeping 💅 RBridge Ethernet ports, just like [802.1Q] ports, can also be configured to restrict input/output on a VLAN basis.
So TRILL Data and TRILL IS-IS packets get sent on Ethernet links in a Designated VLAN, which is assumed to provide connectivity between all RBridges on the link ✨ The Designated VLAN for a LAN link is dictated by the elected Designated RBridge on that link (the DRB, which is the Layer 2 version of the Designated Intermediate System at Layer 3) 👑 On an RBridge Ethernet port configured as point-to-point, TRILL Data and IS-IS packets go out in that port's Desired Designated VLAN, regardless of the state of any other ports on the link. Connectivity on a point-to-point Ethernet link generally depends on both ends being configured with the same Desired Designated VLAN 🫶 And since TRILL Data packets only flow between RBridges on an Ethernet link in the link's Designated VLAN, adjacency for routing calculations is based only on connectivity characteristics in that VLAN. main character energy 🎀
(Non-Ethernet links, such as PPP [RFC6361], generally do not have any Outer.VLAN labeling, so the Designated VLAN for such links has no effect 🌸)
2.2. Handling Native Frames
okay this section is all about "native" frames, the ones defined in Section 1.4 of [RFC6325] 🧚 It doesn't apply to point-to-point links between TRILL switches, or to any link where all the TRILL switch ports have been set to "trunk ports" by setting the end-station service disable bit for the port (see Section 4.9.1 of [RFC6325]). Literally not relevant for those 🙈
Layer 3 data packets, like IP packets, are already "tamed" when an end station originates them 💖 They include a hop count and Layer 3 source and destination address fields. Also, for ordinary data packets there's no requirement to preserve any outer Layer 2 addressing, and if the packets are unicast, they're explicitly addressed to their first-hop router.
Now here's the plot twist 😭 TRILL switches must accept, transport, and deliver "untamed" native frames, which are native frames that lack a hop count field usable by TRILL and have Layer 2 MAC (Media Access Control) addresses that indicate their source and destination. Those Layer 2 addresses must be preserved for delivery to the native frame's Layer 2 destination. One result of this is that RBridge ports providing native frame service must receive in promiscuous MAC address mode, while Layer 3 router ports typically receive in a selective MAC address mode 🌈
So TRILL handles this by having, on the link where an end station originates a native frame, one RBridge "ingress" that locally originated native frame. It does this by adding a TRILL Header that includes a hop count, which converts it into a TRILL Data packet ✨ This augmented packet is then routed to one RBridge on the link that has the destination end station for the frame (or one RBridge on each such link, if it's a multi-destination frame). Those final RBridges perform an "egress" function, removing the TRILL Header and delivering the original frame to its destination(s). (For the purposes of TRILL, a Layer 3 router is an end station.)
Okay, but care must be taken to avoid a loop that would involve egressing a native frame and then re-ingressing it 💀 While it's in native form, it isn't protected by a hop count, so it could loop forever. For multi-destination frames, such a loop could even multiply the number of frames each time around and would likely saturate all links involved within milliseconds. For TRILL, safety against such loops on a link is more important than a transient loss of data connectivity on that link 🔥
The primary TRILL defense against these loops is mandatory: it's about making sure that, as far as is practically possible, there is only a single RBridge in charge of ingressing and egressing native frames from and to a link where TRILL is offering end-station service 👑 This is the Designated RBridge and Appointed Forwarder mechanism, first specified in the TRILL base protocol [RFC6325], discussed in Section 2.5 below, and further specified in both Section 4 below and [RFC6439].
2.3. Zero or Minimal Configuration
TRILL gives you connectivity and least-cost paths with zero configuration 🦋 For extra services, it aims to need only minimal configuration. Services that require configuration when offered by [802.1Q] bridges, like non-default VLANs or priority, will still need configuration though. This is different from Layer 3 routing, where routers typically need to be configured with the subnetworks connected to each port, and so on, before they provide service 🎀
2.4. MTU Robustness
TRILL IS-IS needs to be robust against links with reasonably restricted MTUs 🫧 That includes links that only accommodate the classic Ethernet frame size, even after adding reasonable headers like VLAN tags. This robustness is especially required for TRILL Hellos, so that adjacency is correct and a unique DRB gets elected on LAN links.
TRILL will also be used inside data centers, where it's common for all or most of the links and switches to support frames that are substantially larger than the classic Ethernet maximum size 🍓 For example, they may have an MTU that comfortably handles Fiber Channel over Ethernet frames, for which T11 recommends a 2,500-byte MTU [FCoE], or even 9K byte jumbo frames. It would be beneficial for a TRILL campus with such a large MTU to be able to safely use it. 🤩
These needs are met by a mandatory maximum on the size of TRILL Hellos and by the optional use of MTU testing, as described below 💜
2.5. Purposes of the TRILL Hello Protocol
okay there are three purposes for the TRILL Hello protocol 🌸 Here they are, with a reference to the section where each one is discussed:
- To determine which RBridge neighbors have acceptable connectivity to be reported as part of the topology (Section 3)
- To elect a unique Designated RBridge on broadcast (LAN) links (Section 4)
- To determine the MTU with which it is possible to safely 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 that a router neighbor isn't discovered if it's impossible to communicate with it using maximum-sized Layer 3 IS-IS packets. Also, even if Hellos from a neighbor R2 are received by R1, if connectivity to R2 is not 2-way (i.e., R2 does not list R1 in R2's Hello), then R1 does not consider R2 as a Designated Intermediate System (Designated Router) candidate. Because of this logic, it's possible at Layer 3 for multiple Designated Routers to be elected on a LAN, with each one representing the LAN as a pseudonode. To the topology, it looks like the LAN is now two or more separate LANs 👀 It's surprising, but it doesn't cause problems for Layer 3.
TRILL is different, though 💅 This behavior is not acceptable for TRILL, because in TRILL it's important that all RBridges on a link know about each other, and that on broadcast (LAN) links they choose a single RBridge to be the DRB, which controls the native frame ingress and egress. Otherwise, multiple RBridges might ingress/egress the same native frame, forming loops that aren't protected by the hop count in the TRILL Header, as discussed above 😭
The TRILL Hello protocol is best understood by focusing separately on each of these three functions listed above, which is exactly what we do in Sections 3, 4, and 5 🧚
One other issue with TRILL LAN Hellos is making sure that subsets of the information can appear in any single message and still be processable, in the spirit of IS-IS Link State PDUs (LSPs) and Complete Sequence Number PDUs (CSNPs) ✨ LAN TRILL Hello packets, even though they aren't padded, can get really large. An example is when some sort of backbone technology interconnects hundreds of TRILL sites over what would look like a giant Ethernet to TRILL. The RBridges connected to that cloud would perceive the backbone as a single link with hundreds of neighbors 🌈 So the TRILL LAN Hello uses a different Neighbor TLV [RFC7176] that lists neighbors seen for a range of MAC (SNPA) addresses.
3. Adjacency State Machinery ✨
3.1. TRILL Hellos, Ports, and VLANs
okay so each RBridge port has a port state, as discussed in Section 4, plus a table of zero or more adjacencies (zero or one if the port is configured as point-to-point), as discussed in this section 🦋 The states those adjacencies can have, the events that change adjacency states, the actions tied to those state changes, a state table, and a state diagram are all given below.
Adjacencies on links are determined using TRILL Hellos (see Section 8), an optional MTU test (see Section 5), and, optionally, BFD (see Section 6) and/or other connectivity tests. If the MAC (SNPA) addresses of more than one RBridge port on a broadcast link are the same, all but one of those ports are put in the Suspended state (see Section 4). Those ports don't participate in the link, except to monitor whether they should stay suspended 🙈 If the two ports on a point-to-point link have MAC (SNPA) addresses, it doesn't affect TRILL operation if they're the same. (PPP ports, for example, do not have MAC addresses [RFC6361].)
The following items MUST be the same for all TRILL Hellos issued by an RBridge on a particular Ethernet port, regardless of the VLAN in which the Hello is sent 🫶
- Source MAC address,
- Priority to be the DRB,
- Desired Designated VLAN,
- Port ID, and,
- if included, BFD-Enabled TLV [RFC6213] and PORT-TRILL-VER sub-TLV [RFC7176].
Of course, the priority, Desired Designated VLAN, and possibly the inclusion or value of the PORT-TRILL-VER sub-TLV and/or BFD-Enabled TLV can change now and then. When that happens, the new value(s) must similarly be used in all TRILL Hellos on the LAN port, regardless of VLAN 💖
On broadcast links:
Because bridges acting as glue on an Ethernet broadcast link might be configured in such a way that some VLANs are partitioned, it's necessary for RBridges to transmit Hellos on Ethernet links with multiple VLAN tags 🌸 The conceptually simplest solution might have been to have RBridges transmit up to 4,094 times as many Hellos, one with each legal VLAN ID enabled at each port. But that would obviously have deleterious performance implications 💀 So the TRILL protocol specifies that if RB1 knows it is not the DRB, it transmits its Hellos on only a limited set of VLANs. Only an RBridge that believes itself to be the DRB on a broadcast Ethernet link "sprays" its TRILL Hellos on all of its enabled VLANs at the port 🔥 And in both cases, an RBridge can be configured to send Hellos on only a subset of those VLANs. The details are given in [RFC6325], Section 4.4.3.
On point-to-point links:
If the link technology is VLAN sensitive, such as Ethernet, an RBridge sends TRILL Hellos only in the Desired Designated VLAN for which it is configured 🎀
3.2. Adjacency Table Entries and States ✨
okay so every adjacency is in one of four states 💖 this is true whether it's one of the adjacencies on a broadcast link or the one possible adjacency on a point-to-point link. an RBridge takes part in LSP synchronization at a port as long as it has one or more adjacencies out of that port in the 2-Way or Report state 🫶
- Down: this is a virtual state, basically just for making state diagrams and tables easier 🧚 it means the adjacency doesn't exist and there's no entry for it in the adjacency table.
- Detect: a neighbor RBridge has been spotted by receiving a TRILL Hello, but either 2-way connectivity hasn't been confirmed yet, or the detection happened on an Ethernet link in a VLAN that isn't the Designated VLAN 👀
- 2-Way: 2-way connectivity to the neighbor has been found and, if the link is Ethernet, it was found on the Designated VLAN. but some enabled test, like the link MTU meeting the minimum campus requirement or BFD confirming link connectivity, hasn't passed yet 🥺
- Report: there's 2-way connectivity to the neighbor (on the Designated VLAN if it's an Ethernet link) and every enabled test has passed, including MTU and/or BFD testing if those are turned on ✨ this state makes the adjacency get reported in an LSP. (there's proper handling for a pseudonode, if there is one, as described in Section 7.)
for any adjacency in one of the three non-Down states (Detect, 2-Way, or Report), there will be an adjacency table entry 💅 that entry tells you the state and also holds the info below.
- the address of the neighbor (if it has one), the Port ID, and the System ID from the received Hellos. together these three uniquely identify the adjacency on a broadcast link 🔑
- one or more Hello holding timers. a point-to-point adjacency has a single Hello holding timer. a broadcast LAN adjacency has exactly two: a Designated VLAN holding timer and a non-Designated VLAN holding timer. each timer is a 16-bit unsigned integer number of seconds ⏱️
- if the adjacency is on a broadcast link, the 7-bit unsigned priority of the neighbor to be the DRB 💪
- the 5 bytes of data from the
PORT-TRILL-VERthat came in the most recent TRILL Hello from the neighbor RBridge 🎀 - the VLAN the neighbor RBridge wants to be the Designated VLAN on the link, called the Desired Designated VLAN 🦋
- for an adjacency table at an RBridge that supports BFD, a flag saying whether the last TRILL Hello from the neighbor RBridge had a BFD-Enabled TLV in it (see Section 6) 🌈
3.3. Adjacency and Hello Events 💜
these events can change the state of an adjacency, bestie 👑
- A0. receive a TRILL Hello for a broadcast LAN adjacency whose source MAC address (SNPA) is the same as the port it came in on. this one's special 😭 it can't happen on a port configured as point-to-point, and it's handled right after this list. it doesn't show up in the state transition table or diagram 🙈
- A1. receive a TRILL Hello (not an A0 event) such that:
- if it came in on an Ethernet port, it was received in the Designated VLAN.
- if it's for a broadcast LAN adjacency, it has a TRILL Neighbor TLV that explicitly lists the receiving port's (SNPA) address.
- if it's for a point-to-point adjacency, it has a Three-Way Handshake TLV with the receiver's System ID and Extended Circuit ID.
- A2. this one's not possible for a port configured as point-to-point 🙅♀️ receive a TRILL Hello (not an A0 event) such that either:
- the port is Ethernet and the Hello wasn't on the Designated VLAN (any TRILL Neighbor TLV in a Hello like that gets ignored), or
- the Hello doesn't have a TRILL Neighbor TLV covering an address range that includes the receiver's (SNPA) address.
- A3. receive a TRILL Hello (not an A0 event) such that:
- if it came in on an Ethernet port, it was received in the Designated VLAN.
- if it's for a broadcast LAN adjacency, it has one or more TRILL Neighbor TLVs covering an address range that includes the receiver's (SNPA) address, and none of them list the receiver.
- if it's for a point-to-point adjacency, it has a Three-Way Handshake TLV where either the System ID or Extended Circuit ID or both are not equal to the receiver's.
- A4. either:
- (1) the Hello holding timer expires on a point-to-point adjacency, or
- (2) on a broadcast LAN adjacency:
- (2a) both Hello timers expire at the same time, or
- (2b) one Hello timer expires when the other one is already expired.
- A5. for a broadcast LAN adjacency, the Designated VLAN Hello holding timer expires, but the non-Designated VLAN Hello holding timer still has time left. this can't happen for a point-to-point adjacency 🫠
- A6. MTU if enabled, BFD if enabled, and all other enabled connectivity tests are successful 🎉
- A7. MTU if enabled, BFD if enabled, and all other enabled connectivity tests were successful, but one or more of them now fail 💀
- A8. the RBridge port goes operationally down 📉
for the special A0 event, the Hello gets checked to see if it has a higher priority than the port it came in on, so that the sending port should be the DRB (see Section 4.2.1). if the Hello is lower priority than the receiving port, it gets thrown out with no further action. if it's higher priority, then any adjacencies for the receiving port are discarded (moved to the Down state), and the port gets suspended as described in Section 4.2 🚫
receiving a TRILL Hello that isn't an A0 event causes the actions below. the exception is when the Hello would've created a new adjacency table entry, but the table is full and the Hello is too low priority to kick out an existing entry (see Section 3.6) 🙃 the Designated VLAN mentioned here is the one dictated by the DRB determined without taking the received TRILL LAN Hello into account (see Section 4) for a broadcast LAN, and the local Desired Designated VLAN for a port configured as point-to-point.
- if receiving a Hello creates a new adjacency table entry, the neighbor RBridge MAC (SNPA) address (if it has one), Port ID, and System ID get set from the Hello 🌸
- for a point-to-point adjacency, the Hello holding timer gets set from the Holding Time field of the Hello. for a broadcast link adjacency, the right Hello holding timer for that adjacency gets set to the Holding Time field of the Hello, depending on whether or not the Hello came in on the Designated VLAN. if receiving the LAN Hello is creating a new adjacency table entry, the other timer gets set to expired ⏳
- for a broadcast link adjacency, the neighbor RBridge's priority to be the DRB gets set to the priority field of the LAN Hello 💪
- for a broadcast link adjacency, the VLAN the neighbor RBridge wants to be the Designated VLAN on the link gets set from the Hello 🦋
- the 5 bytes of PORT-TRILL-VER data get set from that sub-TLV in the Hello, or set to zero if that sub-TLV isn't in the Hello 🎀
- for a broadcast link, if creating a new adjacency table entry or the priority update above changes the results of the DRB election on the link, the matching RBridge port event (D2 or D3) happens after the actions above, as described in Section 4.2 🔥
- for a broadcast link adjacency, if the DRB hasn't changed but the neighbor's Hello is from the DRB and it has a different 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 moves the adjacency to the Down state might also cause a D3 event, as described in Section 4.2 🌈
about events A6 and A7: if none of MTU, BFD, or other testing is enabled, A6 is treated as happening right away once the adjacency enters the 2-Way state, and A7 can't happen 💖
see Section 8 for more TRILL Hello receipt details 📖
3.4. Adjacency State Diagram and Table 🧸
the table below shows the transitions between the states we just talked about, based on the events above 🍓
| 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 |
Table 2: Adjacency State Table"N/A" means the event on the left doesn't apply in the state at the top of the column 🙅♀️ these events only affect a single adjacency. the special A0 event moves all adjacencies to Down, as explained right after the list of adjacency events in Section 3.3 💀
the diagram below shows the same info as the state table 🦋
+---------------+
| 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 |
+---------+
Figure 1: Adjacency State Diagram3.5. Multiple Parallel Links
okay so there can be multiple parallel adjacencies between neighbor RBridges that TRILL can see 🌸 bonded links (think link aggregation [802.1AX]) look like ONE link to TRILL, so only a single TRILL adjacency gets made over that bundle ✨
Any parallel links with pseudonodes (see Section 7) are distinguished in the topology 💅, and if those adjacencies are in the Report state they show up in LSPs as per Section 7. BUT parallel adjacencies without pseudonodes are a whole different vibe 🦋 they're point-to-point adjacencies, or LAN adjacencies where no pseudonode is being created. When those are in the Report state, they show up in LSPs as a single adjacency 🫶
The cost of such an adjacency MAY be adjusted downwards to account for the parallel paths 💜 Multipathing across these 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) of [RFC6325] and Appendix C of [RFC6325] 💀
3.6. Insufficient Space in Adjacency Table
okay, real talk 😭 if receiving a TRILL Hello would create a new adjacency table entry (aka it would move an adjacency out of the Down state), there may be no space for that new entry. For ports configured as point-to-point, which can only have zero or one adjacency not in the Down state, it is RECOMMENDED that space be reserved for one adjacency so this condition can't happen 🙈🌈
When the adjacency table runs out of space, the DRB election priority (see Section 4.2.1) of the new entry is compared with the DRB election priority of the existing entries 👑 If the new entry is higher priority than the lowest priority existing entry, it replaces that lowest priority entry, which then gets transitioned to the Down state. Main character energy, but make it a priority contest 💅
4. LAN Ports and DRB State 🎀
this section is all about the DRB election process at a broadcast (LAN) link port 🍓 there's no election when a port is configured as point-to-point, so this section doesn't apply in that case 🙅♀️
The info an RBridge keeps for each of its broadcast LAN ports includes:
- Enablement bit, which defaults to enabled.
- The 5 bytes of PORT-TRILL-VER sub-TLV data used in TRILL Hellos sent on the port.
- SNPA address (commonly 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 LAN Hellos sent on the port.
- BFD support. If the port supports BFD, a BFD Enabled flag that controls whether or not a BFD-Enabled TLV is included in TRILL Hellos sent on the port.
- The DRB state 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 of this port, used in TRILL Hellos sent on the port if the link is Ethernet.
- 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 broadcast link is the DRB (Designated RBridge) 👑 the DRB election state machinery is described below.
Each RBridge port that is not configured as point-to-point is in one of these 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 adjacencies for the port, and no TRILL Hellos or other TRILL IS-IS PDUs or TRILL Data packets 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, except that TRILL Hellos are accepted for the sole purpose of determining whether to change the value of the Suspension Timer for the port (more on that below).
DRB: The port is the DRB and can receive and transmit TRILL Data packets. Queen behavior 👑
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 packets ✨
4.2. DRB Election Events 💫
these are the events that can change the DRB state of a port. Heads up: this is only applicable to broadcast links. There's no DRB state or election at a port configured to be point-to-point 🙈
D1. The port becomes enabled, or the Suspension Timer expires while the port is in the Suspended state.
D2. The adjacency table for the port changes, and there are now entries for one or more other RBridge ports on the link that appear to be higher priority to be the DRB than the local port. Oof, we lost the vote 😭
D3. The port is not Down or Suspended, and the adjacency table for the port changes, so there are now no entries for other RBridge ports on the link that appear to be higher priority to be the DRB than the local port. And we're back on top 🎉
D4. A TRILL LAN Hello is received that has 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 💀
Event D1 is considered to occur on RBridge boot if the port is administratively and link-layer enabled 🌸
Event D4 causes the port to enter the Suspended state, and all adjacencies for the port get discarded (transitioned to the Down state). If the port was in some state other than Suspended, the Suspension Timer is set to the Holding Time in the Hello that causes event D4. If it was already in the Suspended state, the Suspension Timer is set to the maximum of its current value and the Holding Time in the Hello that causes event D4 🧚
4.2.1. DRB Election Details ⭐
Events D2 and D3 are how you lose and win the DRB election at the port, respectively 🥺
The candidates for election are the local RBridge and all RBridges with which there is an adjacency on the port in an adjacency state other than the Down state. The winner is the RBridge with the highest priority to be the DRB, as determined from the 7-bit priority field in that RBridge's Hellos received and the local port's priority to be the DRB field. MAC (SNPA) address is the tiebreaker, Port ID is the secondary tiebreaker, and System ID is the tertiary tiebreaker 🫶 These fields are compared as unsigned integers, with the larger magnitude being considered higher priority.
Resorting to the secondary and tertiary tiebreakers should only be necessary in rare circumstances, when multiple ports have the same priority and MAC (SNPA) address and some of them are not yet suspended. For example, RB1, which has low priority to be the DRB on the link, could receive Hellos from two other ports on the link that have the same MAC address as each other and are higher priority to be the DRB. One of those two ports will be suspended and cease sending Hellos, and the Hello from it received by RB1 will eventually time out. But in the meantime, RB1 can use the tiebreakers to determine which port is the DRB, and thus which port's Hello to believe for purposes such as setting the Designated VLAN on the link 🔥
4.2.2. Change in DRB 🔄
Events D2 and D3 result 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 change in the DRB on the link changes the Designated VLAN on an Ethernet link, the actions specified in Section 4.2.3 are taken.
If an RBridge changes in either direction between being the DRB and not being the DRB at a port, this will generally change the VLANs on which that RBridge sends Hellos through that port, as specified in Section 4.4.3 of [RFC6325] 🦋
4.2.3. Change in Designated VLAN 🎀
Unnecessary changes in the Designated VLAN on an Ethernet link should be avoided, because a change in the Designated VLAN can cause a transient interruption to adjacency, and thus to TRILL Data forwarding, on the link 🙈 When practical, all RBridge ports on a link should be configured with the same Desired Designated VLAN, so that if the winner of the DRB election changes for any reason, the Designated VLAN will stay the same ✨
If an RBridge detects a change in Designated VLAN on an Ethernet link, then, for all adjacency table entries for a port to that link, the RBridge takes the following steps, in the order given.
- 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, this will generally change the VLANs on which Hellos are sent by an RBridge port on that link, as specified in Section 4.4.3 of [RFC6325] 💜
4.3. Port State Table and Diagram 📊
the table below shows the transitions between the DRB states we just talked about, based on the events above 💅
| Event | Down | Suspended | 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 | Suspended | Suspended | Suspended |
| D5 | Down | Down | Down | Down |
Table 3: Port State Table"N/A" indicates that the event to the left is not applicable in the state at the top of the column. 🙃
The diagram below presents the same information as the state table, just prettier 🌈
+-------------+
| Down |<--------------+
+-+---+-------+ ^ |
| | ^ | |
D1| |D5 | | |
| +---+ |D5 |
| | |
| +--------+----+ |
| | Suspended |<---|---+
| +-+-----+-----+ | |
| D1| ^ | ^ | |
| | | |D4 | | |
| | | +---+ | |
| | | | |
| | |D4 | |
V V | | |
+---------------+-+ D5 | |
| DRB |---------->| |
+--------+--+-----+ | |
^ | | ^ | |
| D2| |D3| | |
| | +--+ | |
| | D4 | |
|D3 | +-----------------|---+
| V | |
+----+-------+-+ D5 |
| Not DRB |-------------->|
+----+---------+
| ^
|D2 |
+----+
Figure 2: Port State Diagram5. MTU Matching ✨
okay so the whole point of MTU testing 🎀 is making sure the links in the campus can actually carry TRILL IS-IS packets, especially LSP PDUs, at the TRILL campus MTU 🦋. An LSP PDU generated at a TRILL switch could, during flooding, get sent over any adjacency in the campus 💅. For IS-IS to work properly, every LSP PDU has to be able to reach every RBridge in the IS-IS reachable campus 😭. If the PDU is bigger than the MTU of an adjacency that's part of the campus topology, that might be impossible 💀.
RB1 works out the desired campus link MTU by taking the minimum of its own originatingL1LSPBufferSize and the originatingL1LSPBufferSize of other RBridges in the campus, as advertised in the link-state database, but never less than 1,470 bytes 🧚. Fun fact: in Layer 3 [IS-IS], originatingL1LSPBufferSize is limited to 512 to 1,492 bytes inclusive, but in TRILL it's limited to 1,470 to 65,535 bytes inclusive 🌈. (See Section 5 of [RFC7180].)
Even though MTU testing is optional 🙈, it is mandatory for an RBridge to respond to an MTU-probe PDU with an MTU-ack PDU [RFC6325] [RFC7176]. Whether MTU-probe and MTU-ack use multicast or unicast is an implementation choice 💜. The burden on the link is generally kept lowest by doing the following: (1) multicasting MTU-probes when you want a response from every other RBridge on the link, like when initializing or reconfirming MTU, (2) unicasting MTU-probes when you only want a response from one RBridge, like one that just showed up on the link, and (3) unicasting all MTU-ack packets. ✨
RB1 can test the MTU size to RB2 as described in Section 4.3.2 of [RFC6325] 🦋. MTU testing is only done in the Designated VLAN, so it's not everywhere 🙅♀️. An adjacency that fails the MTU test at the campus MTU will not enter the Report state, or, if it's already in that state, it leaves it 😭. So an adjacency failing the MTU test at the campus minimum MTU won't get reported by the RBridge doing the test 💀. Here's the tea: inclusion in least-cost route computation requires the adjacency to be reported by both ends. As long as the RBridge at either end notices the MTU failure, that adjacency won't get used 🔥.
If RB1 tests MTU size, it reports either the largest size where the MTU test succeeds, or a flag saying it fails at the campus MTU 🎀. This 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 bigger than the desired campus MTU too, not just the desired campus MTU itself 🌸.
Most types of TRILL IS-IS packets, like LSPs, can use the campus MTU 🍓. The exceptions are TRILL Hellos, which have to stay small for loop safety 🛡️, and the MTU PDUs, whose size has to be adjusted for whatever tests are running 🧚.
6. BFD-Enabled TLV and BFD Session Bootstrapping 🦋
When the adjacency between RBridges reaches the 2-Way state, the TRILL Hellos have already been exchanged 💅. If an RBridge supports BFD [RFC7175], it finds out whether the other RBridge has BFD enabled by checking whether a BFD-Enabled TLV [RFC6213] was included in its Hellos 👀. Plus, TRILL Hellos include a nickname of the sending RBridge [RFC7176], so that info is available to the receiving RBridge too 💜.
The BFD-Enabled TLVs in TRILL Hellos look like this:
+-+-+-+-+-+-+-+-+
| Type=148 | (1 byte)
+-+-+-+-+-+-+-+-+
| Length=3*n | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | MT ID=0 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLPID=0xC0 | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-...
| possible additional (3*(n-1) bytes)
| topology/NLPID pairs
+-+-+-+-+-+-+-...
Figure 3: BFD-Enabled TLV Example/FormatType = 148 for BFD Enabled [RFC6213] 🎀.
Length is 3 times the number of topology and protocol pairs in the TLV 🔢.
MT ID is a topology ID [RFC5120] that will be zero unless multi-topology is being supported [MT] 🌈.
NLPID is a Network Layer Protocol ID [RFC6328]. It'll be 0xC0 for TRILL, but extra topology and protocol pairs could conceivably be listed too 🧚.
An RBridge port starts a one-hop BFD session with another RBridge if these conditions are met: (1) it has BFD enabled, (2) it has an adjacency to another RBridge in the 2-Way or Report state, and (3) the Hellos it receives show that the other RBridge also has BFD enabled 🫶. That can happen in three ways: (a) BFD was enabled on both RBridge ports when the adjacency changed to the 2-Way or Report state, (b) the adjacency was already in the 2-Way or Report state and BFD got enabled on one RBridge port when it had already been enabled on the other, or (c) BFD was enabled on both RBridge ports at the same time 💖.
In a BFD session like this, BFD is encapsulated as specified in [RFC7175] 🦋. The egress nickname to use is learned from received Hellos 👑. On a point-to-point link, the Any-RBridge nickname [RFC7180] can also be used as egress 🌸. That's because support for that nickname is required by support of RBridge Channel [RFC7178], and support for RBridge Channel is required for support of BFD over TRILL 💅.
The rare case of a transient nickname conflict (caused by the network operator configuring a conflict, new connectivity to a previously isolated RBridge, or something similar) can cause a transient failure of an ongoing BFD session 😭. In the one-hop point-to-point case, you can avoid this by using the Any-RBridge egress nickname 🙌. When Any-RBridge can't be used as the egress nickname, and a transient nickname conflict is detected for the intended destination of a BFD session, starting the session SHOULD be delayed until the conflict is resolved ⏳.
If a one-hop BFD session starts while the adjacency is in the 2-Way state, the adjacency MUST NOT advance to the Report state until BFD and any other enabled connectivity tests (including MTU, if enabled) have succeeded, as specified in Section 3. 🚫
If a one-hop BFD session is established while the adjacency is in the Report state, because it got enabled at the RBridges, then the adjacency MUST remain in the Report state unless and until the BFD session (or some other enabled connectivity test) fails 🧘♀️. The point is to keep unnecessary topology changes to a minimum 🫧.
7. Pseudonodes 🧚
This section only applies to broadcast links 🌊. There's no DRB and there can't be a pseudonode [IS-IS] on a link configured as point-to-point 🙅♀️. The Designated RBridge (DRB), figured out the way 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 their adjacencies on the LAN that are in the Report state 🦋. If the DRB doesn't 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 doesn't change how LSPs get flooded on a link 🌸. It only changes which LSPs get generated 💅.
Plenty of links between RBridges will actually be point-to-point, even when the link tech could run as a multi-access broadcast link 🙄. In that case, using a pseudonode just adds complexity for no reason 😤. For example, say RB1 and RB2 are the only RBridges on the link, and RB1 is the DRB. If RB1 creates a pseudonode (like RB1.25) and uses it, you end up with 3 LSPs: RB1.25, RB1, and RB2. RB1.25 reports connectivity to RB1 and RB2, and RB1 and RB2 each just say they're connected to RB1.25 🧩. But if DRB RB1 sets the bypass pseudonode bit in its Hellos, then there are only 2 LSPs: RB1 and RB2, each reporting connectivity to the 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 🌙.
8. More TRILL Hello Details 💖
This section gives more details on the receipt, transmission, and content of TRILL Hellos 📬. Unless otherwise stated, it applies to both LAN and point-to-point Hellos 🫶.
TRILL Hellos, like all TRILL IS-IS packets, are mainly told apart from Layer 3 IS-IS packets on Ethernet by being sent to the All-IS-IS-RBridges multicast address (01-80-C2-00-00-41) 🦋. TRILL IS-IS packets on Ethernet also have 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 the fixed Area Address zero (see Section 4.2 of [RFC7176]) 🧚.
IS-IS Layer 3 routers often connect to other Layer 3 routers that are part of a different routing domain 🌐. In that case, the externalDomain flag (see [IS-IS]) is usually set for the port where that connection happens 🚪. Setting this flag to "true" means no IS-IS PDUs get sent out of the port, and any IS-IS PDUs received get discarded, Hellos included 🙅♀️. RBridges work in a different environment, where all neighbor RBridges merge into a single campus 🏫. For loop safety, RBridges don't implement the externalDomain flag, or they implement it with the fixed value "false" 🛡️. They send and can receive TRILL Hellos on every port that isn't disabled 💅.
8.1. Contents of TRILL Hellos 🎀
The table below lists mandatory (M) and optional (O) content TLVs for TRILL Hellos that matter most for this document, split up between TRILL LAN Hellos and TRILL P2P Hellos 📋. A "-" means an occurrence would be ignored. There are more TLVs and sub-TLVs that can show up in TRILL Hellos [RFC7176] 🌈.
LAN P2P Number Content Item
--- --- ------ ----------------------------------------------
M M 1 Area Addresses TLV with Area Address zero only
M M 1 MT Port Capabilities TLV containing a
VLAN-FLAGs sub-TLV
O O 0-n Other MT Port Capability TLVs
M - 0-n TRILL Neighbor TLV (see Section 8.2.1)
- M 1 Three-Way Handshake TLV
O O 0-n Protocols Supported TLV -- MUST list the
TRILL NLPID (0xC0) [RFC6328]
O O 0-1 BFD-Enabled TLV
O O 0-1 Authentication TLV
- - 0-n Padding TLV -- SHOULD NOT be included
Table 4: TRILL Hello ContentsA TRILL Hello MAY also contain any TLV permitted in a Layer 3 IS-IS Hello 🧩. As with all IS-IS PDUs, TLVs that are unsupported or unknown in TRILL Hellos get ignored 🫧.
8.2. Transmitting TRILL Hellos 📡
TRILL Hellos go out on the same timing as Layer 3 IS-IS Hellos [IS-IS] 💅, but there's a big exception: no Hellos get sent if a port is in the Suspended or Down state, or if the port is disabled 🙅♀️
TRILL Hello PDUs SHOULD NOT be padded 🧸 and MUST NOT be sent if they exceed 1,470 bytes 🚫. The plot twist is that a received TRILL Hello longer than 1,470 bytes is still processed normally 👀 receiving is more chill than sending, iykyk.
TRILL Hello PDU headers MUST conform to the following:
Maximum Area Addressesequal to 1.Circuit Typeequal to 1.
See Section 8.1 for mandatory Hello TLV contents and some optional Hello TLV contents 🌸
8.2.1. TRILL Neighbor TLVs 🦋
A TRILL Neighbor TLV SHOULD NOT be included in TRILL point-to-point Hellos 🙈 it MUST be ignored in that context anyway, so it just wastes space 😭
TRILL Neighbor TLVs sent in a LAN Hello on an Ethernet link MUST show the neighbor information, as sensed by the transmitting RBridge, for the VLAN on which the Hello is sent ✨ Since implementations conformant to this document only keep that per-VLAN information for the Designated VLAN, they only send the TRILL Neighbor TLV in TRILL LAN Hellos in the Designated VLAN 💜
It is RECOMMENDED that, if there is sufficient room, a TRILL Neighbor TLV or TLVs be in TRILL Hellos sent on the Designated VLAN 🎀 Those TLVs should be described in Section 4.4.2.1 of [RFC6325], cover the entire range of MAC addresses, and list all adjacencies with a non-zero Designated VLAN Hello Holding Time. If there are no such adjacencies, the list is empty. If it's not possible to fit everything, TRILL Neighbor TLVs covering sub-ranges of MAC addresses should be sent so that the entire range is covered reasonably promptly 🧚
Delays in sending TRILL Neighbor TLVs will delay the advancement of adjacencies to the Report state and the discovery of some link failures 😬 Rapid (for example, sub-second) detection of link or node failures is best handled by a protocol designed for that purpose, such as BFD (see Section 6) 🔥
To ensure that any RBridge RB2 can definitively determine whether RB1 can hear RB2, RB1's neighbor list MUST eventually cover every possible range of IDs 🌈 That happens within a period that depends on RB1's policy, not necessarily within any specific period such as 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 💖 Or the lists may overlap, as long as there is no gap, so no range (say, between Xi and Xj) would never appear in any list 🫶
8.3. Receiving TRILL Hellos 👂
Say a packet is labeled as TRILL IS-IS 🏷️ for example, on Ethernet it has the L2-IS-IS Ethertype and the All-IS-IS-RBridges destination multicast address, or it's marked with the right code point on other link types such as PPP [RFC6361] or a pseudowire [RFC7173]. Then it gets examined to see if it looks like an IS-IS PDU. If it does, and it looks like a TRILL Hello PDU, these tests run:
- The type of Hello PDU (LAN or P2P) is compared with the port configuration. If a LAN Hello is received on a port configured to be point-to-point, or a P2P Hello is received on a port not configured to be point-to-point, it is discarded 🚮
- If the
Circuit Typefield is not 1, the PDU is discarded. - If the PDU does not contain an Area Address TLV, or it contains an Area Address TLV that is not the single Area Address zero, it is discarded.
- If the Hello includes a Protocols Supported TLV that does not list the TRILL NLPID (
0xC0), it is discarded. It's acceptable if there is no Protocols Supported TLV present 🙆♀️ - If the Hello does not contain an MT Port Capabilities TLV containing a VLAN-FLAGS sub-TLV [RFC7176], it is discarded.
- If the
maximumAreaAddressesfield of the PDU is not 1, it is discarded. - If IS-IS authentication is in use on the link and either the PDU has no Authentication TLV or validation of the PDU's Authentication TLV fails, it is discarded 🔐
If none of the rules in that list cause the packet to be discarded, and the packet is parseable, it's assumed to be a well-formed TRILL Hello received on the link 🥰 It's then treated as an event A0, A1, A2, or A3, based on the criteria listed in Section 3.3 ✨
9. Multiple Ports on the Same Broadcast Link 🧩
It's possible for an RBridge RB1 to have multiple ports on the same broadcast (LAN) link that are not in the Suspended state 👯 It's important for RB1 to recognize which of its ports are on the same link 🔍 RB1 can detect this by receiving TRILL Hello messages with the same LAN ID on multiple ports.
The DRB election is port-based (see Section 4) 👑 Only the Hellos from the elected port can perform certain functions, such as dictating the Designated VLAN or whether a pseudonode will be used. The election also designates the RBridge with that port as the DRB for the link, so it's a whole vibe. An RBridge may choose to load split some tasks among its ports on the link if it has more than one 🍰 Section 4.4.4 of [RFC6325] describes when it is safe to do so.
10. IANA Considerations 🗂️
This document serves as a reference for 'Fail' (Failed MTU test), value 0, in the "TRILL Neighbor TLV NEIGHBOR RECORD Flags" registry. IANA has updated that reference to point to this RFC 📌
11. Security Considerations 🔐
This memo provides improved documentation of some aspects of the TRILL base protocol standard. In particular, it covers five aspects of the TRILL adjacency establishment and Hello protocol, as listed in Section 1. It does not change the security considerations of the TRILL base protocol, which are detailed in Section 6 of [RFC6325] 🛡️
See [RFC7175] for security considerations for BFD, whose use in connection with TRILL adjacency is discussed in this document, particularly Section 6. Please take these seriously, bestie 😭⚠️
Appendix A. Changes from RFC 6327 🎀
This document has the following changes from [RFC6327]. It obsoletes [RFC6327] 💅
- This document extends the TRILL Hello size limit, MTU testing, and state machine to point-to-point links.
- This document incorporates the updates to [RFC6327] from [RFC7180].
- The bulk of [RFC6327] was written from the point of view that links between TRILL switches would only be Ethernet. In fact, they could be any technology, such as PPP [RFC6361], pseudowire [RFC7173], or IP [TrillIP]. This replacement document generalizes [RFC6327] to cover such link types 🌍
- This document includes a specification of one-hop BFD session establishment in connection with adjacency.
- Numerous editorial changes were incorporated ✏️
Appendix B. Changes to RFC 6325 🦋
Section 2 of this document replaces Section 4.4.1 of [RFC6325]. Section 8 of this document replaces Section 4.4.2 of [RFC6325], except for Section 4.4.2.1. The changes in [RFC6325] made by this document include:
- Prohibiting the sending of TRILL Hellos out of a port while it is in the Suspended state, and the specification of the Suspended state. ([RFC6325] specifies that Hellos be sent with the same timing as [IS-IS].)
- Permitting the inclusion of the Three-Way-Handshake TLV, BFD-Enabled TLV, and other TLVs in TRILL Hellos when these were omitted in TRILL Hello contents lists in Section 4.4.2 of [RFC6325].
- Extending the TRILL Hello protocol to support point-to-point and non-Ethernet links 🚀
Normative References 📚
[IS-IS] ISO/IEC 10589:2002, Second Edition, "Information
technology -- Telecommunications and information exchange
between systems -- Intermediate System to Intermediate
System intra-domain routeing information 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.
[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.
[RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV",
RFC 6213, April 2011.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer
Protocol Identifiers", BCP 164, RFC 6328, July 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.
[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.
[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.
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and
A. Banerjee, "Transparent Interconnection of Lots of Links
(TRILL): Clarifications, Corrections, and Updates",
RFC 7180, May 2014.Informative References
Okay bestie, these are the informative refs, which means the stuff to go read if you wanna go deeper 🧠📚 Not strictly required, but lowkey where the good context lives 💜
- [802.1AX] "IEEE Standard for Local and metropolitan area networks--Link Aggregation", 802.1AX-2008, January 2008.
- [802.1Q] "IEEE Standard for Local and metropolitan area networks--Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", 802.1Q-2011, August 2011.
- [ESADI] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "TRILL: ESADI (End Station Address Distribution Information) Protocol", Work in Progress, April 2014.
- [FCoE] Excerpt of discussion of "FCoE Max Size" generated from T11/09-251v1, 04/27/2009, "FCoE frame or FCoE PDU",
<www.t11.org>. - [MT] Eastlake, D., Zhang, M., Banerjee, A., and V. Manral, "TRILL: Multi-Topology", Work in Progress, September 2013.
- [RFC3719] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", RFC 3719, February 2004.
- [RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011.
- [RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.
- [RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, November 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.
- [RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, "Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires", RFC 7173, May 2014.
- [TrillIP] Wasserman, M., Eastlake, D., and D. Zhang, "Transparent Interconnection of Lots of Links (TRILL) over IP", Work in Progress, March 2014.
Acknowledgements
Huge thank-yous to these legends who gave suggestions and comments 🫶💖
Stewart Bryant, Elwyn Davies, Adrian Farrel, Brian Haberman, Jon Hudson, Arnel Lim, and Gayle Noble.
The authors of [RFC6327] included Dinesh Dutt. The acknowledgements section of [RFC6327] includes the following, listed in alphabetic order: Jari Arkko, Ayan Banerjee, Les Ginsberg, Sujay Gupta, David Harrington, Pete McCann, Erik Nordmark, and Mike Shand. 🌸✨
Authors' Addresses
And here are the people who wrote this, with their contact details 💅🎀
Donald E. Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.comRadia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054
USA
Phone: +1-408-765-8080
EMail: Radia@alum.mit.eduAnoop Ghanwani
Dell
5450 Great America Parkway
Santa Clara, CA 95054
USA
EMail: anoop@alumni.duke.eduHoward Yang
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: howardy@cisco.comVishwas Manral
Ionos Corp.
4100 Moorpark Ave.
San Jose, CA 95117
USA
EMail: vishwas@ionosnetworks.comAnd that's the whole RFC, bestie! 🌈👑 Go be iconic 💜
📦 where this page comes from
- ietf: rfc7177 2014-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms