RFC 8171
Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms
RFC 8171 🦋 Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms
Bestie, the vibes are immaculate. ✨ Here's the title block tea 🫖:
- RFC number: 8171
- Stream and category: IETF, Standards Track 👑
- Authors: D. Eastlake 3rd (no affiliation listed), L. Dunbar (Huawei), R. Perlman (EMC), Y. Li (Huawei)
- Date: June 2017 📅
- ISSN: 2070-1721
- Obsoletes / Updates: nothing is listed in the title block 🙈
Abstract 💜
So this doc is all about giving TRILL (Transparent Interconnection of Lots of Links) edge switches access to directory service 📖. The directory info can cut down on multi-destination traffic, especially ARP / Neighbor Discovery (ND) and unknown unicast flooding 🌊. It can also help catch traffic with forged source addresses 🕵️♀️. Iconic. 💅
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 got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚.
For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc8171 🔗.
Copyright Notice 🌈
Copyright (c) 2017 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) as they stand on the publication date. Please read these carefully, because they spell out 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 with no warranty, as described in the Simplified BSD License 🙃.
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Uses of Directory Information ..............................5
1.2. Terminology ................................................6
2. Push Model Directory Assistance Mechanisms ......................7
2.1. Requesting Push Service ....................................7
2.2. Push Directory Servers .....................................8
2.3. Push Directory Server State Machine ........................9
2.3.1. Push Directory States ...............................9
2.3.2. Push Directory Events and Conditions ...............11
2.3.3. State Transition Diagram and Table .................13
2.4. End Stations and Push Directories .........................15
2.5. Additional Push Details ...................................15
2.6. Providing Secondary Servers with Data from a
Primary Server ............................................16
2.7. Push Directory Configuration ..............................17
3. Pull Model Directory Assistance Mechanisms .....................17
3.1. Pull Directory Message: Common Format .....................19
3.1.1. Version Negotiation ................................20
3.2. Pull Directory Query and Response Messages ................21
3.2.1. Pull Directory Query Message Format ................21
3.2.2. Pull Directory Responses ...........................24
3.2.2.1. Pull Directory Response Message Format ....24
3.2.2.2. Pull Directory Forwarding .................27
3.3. Cache Consistency .........................................28
3.3.1. Update Message Format ..............................32
3.3.2. Acknowledge Message Format .........................33
3.4. Summary of Record Formats in Messages .....................34
3.5. End Stations and Pull Directories .........................34
3.5.1. Pull Directory Hosted on an End Station ............35
3.5.2. Use of Pull Directory by End Stations ..............36
3.5.3. Native Pull Directory Messages .....................37
3.6. Pull Directory Message Errors .............................38
3.6.1. Error Codes ........................................39
3.6.2. Sub-errors under Error Codes 1 and 3 ...............39
3.6.3. Sub-errors under Error Codes 128 and 131 ...........40
3.7. Additional Pull Details ...................................40
3.8. The "No Data" Flag ........................................40
3.9. Pull Directory Service Configuration ......................42
4. Directory Use Strategies and Push-Pull Hybrids .................42
5. TRILL ES-IS ....................................................44
5.1. PDUs and System IDs .......................................45
5.2. Adjacency, DRB Election, Port IDs, Hellos, and TLVs .......46
5.3. Link State ................................................47
6. Security Considerations ........................................47
6.1. Directory Information Security ............................47
6.2. Directory Confidentiality and Privacy .....................47
6.3. Directory Message Security Considerations .................48
7. IANA Considerations ............................................48
7.1. ESADI-Parameter Data Extensions ...........................48
7.2. RBridge Channel Protocol Numbers ..........................49
7.3. The Pull Directory (PUL) and No Data (NOD) Bits ...........49
7.4. TRILL Pull Directory QTYPEs ...............................50
7.5. Pull Directory Error Code Registries ......................50
7.6. TRILL-ES-IS MAC Address ...................................51
8. References .....................................................51
8.1. Normative References ......................................51
8.2. Informative References ....................................54
Acknowledgments ...................................................55
Authors' Addresses ................................................551. Introduction ✨
Okay so, [RFC7067] gives the problem statement and high-level design for using directory servers to help TRILL [RFC6325] [RFC7780] edge nodes 🧚. The goals are cutting down multi-destination ARP / Neighbor Discovery (ND) [ARPND], reducing unknown unicast flooding, and levelling up security against address spoofing inside a TRILL campus 🛡️. Multi-destination traffic becomes a real burden as a network grows in number of nodes, so trimming ARP/ND and unknown unicast flooding is what makes TRILL scale 📈. This document is where the specific mechanisms for TRILL directory servers actually live 💖.
The info in the directory (or directories) is address mapping and reachability data 🗺️. Most commonly, that's which MAC (Media Access Control) address [RFC7042] goes with an IP address, inside a Data Label (VLAN or FGL (Fine-Grained Label) [RFC7172]), plus the egress TRILL switch (RBridge) and, optionally, the specific port on that switch where the MAC address can be reached 🔌. It could also be which IP address goes with a MAC address, or some other address mapping or reachability info 🌸.
How the directory data first gets into primary servers is out of scope for this doc 🙈. A primary server can use the Push Directory service to send directory data to secondary servers, as covered in Section 2.6 🎀. In a data center, orchestration software usually knows and controls where every IP address, MAC address, and VLAN/tenant lives 🏢. So that orchestration software can be a good fit for providing the directory function, or for feeding the directory or directories 💅.
Efficient unicast routing in a TRILL campus assumes the mapping from destination MAC addresses to edge RBridges is stable enough. If it is, then TRILL's default data-plane learning and/or the use of directories cut the need to flood packets when the destination's location is unknown down to an acceptable level 🌊. "Ephemeral" MAC addresses aren't banned, but they're not likely to show up in this kind of environment 👀. Directories don't need to be complete, and if any ephemeral MAC addresses were in use, they probably wouldn't be in directory info 🫠.
Directory services can run in Push Mode, Pull Mode, or both [RFC7067], depending on what the server wants 👑. In Push Mode, a directory server pushes info to TRILL switches that have shown interest, and that's specified in Section 2 🚀. In Pull Mode, a TRILL switch asks a server for exactly the info it wants, and that's specified in Section 3 🦋. Section 4 has more detail on modes of operation, including the hybrid Push/Pull 🌈.
1.1. Uses of Directory Information 💅
A TRILL switch can consult directory information whenever it likes, either by (1) searching through info it has kept after it was pushed to it or pulled by it, or (2) requesting info from a Pull Directory 🔍. That said, these are expected to be the most common situations where directory info gets used 👑. All of them happen when ingressing (or originating) a native frame 📦.
- ARP requests and replies [RFC826] are normally broadcast, but a directory-assisted edge TRILL switch can intercept ARP messages and reply itself if it has the relevant info [ARPND] 🙌.
- IPv6 ND [RFC4861] requests and replies are normally multicast. Except when Secure Neighbor Discovery (SEND) [RFC3971] is in play, where having the right keying material might be needed, a directory-assisted edge TRILL switch can intercept ND messages and reply if it has the relevant info [ARPND] 🫶.
- Unknown destination MAC addresses normally make a native frame get flooded 🌊. An edge TRILL switch ingressing a native frame has to figure out whether it knows the egress RBridge where the frame's destination MAC address (in the frame's VLAN or FGL) is reachable 🗺️. It might have learned that from the directory, or it can query the directory if it doesn't know 🔎. Plus, if the edge TRILL switch has complete directory info, it can spot a forged source MAC or IP address in any native frame and discard the frame when it finds one 🚫🕵️♀️.
- RARP [RFC903] (Reverse ARP) is basically the same deal as ARP (item 1 above) 🔁.
1.2. Terminology ✨
okay so bestie, let's get into the vocab 🎀 The BCP 14 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" mean what [RFC2119] [RFC8174] say they mean, but ONLY when they show up in all capitals like this 💅 lowercase "must" is just a normal word, no cap 🙈
The terminology and abbreviations of [RFC6325] are used herein, along with the following 💜
AFN: Address Family Number (http://www.iana.org/assignments/address-family-numbers/). 🌸
CSNP Time: Complete Sequence Number Protocol Data Unit (PDU) time. See ESADI [RFC7357] and Section 7.1 below. 🧚
Data Label: VLAN or FGL. 🦋
ESADI: End Station Address Distribution Information [RFC7357]. 🍓
FGL: Fine-Grained Label [RFC7172]. ✨
FR: Flood Record flag bit. See Section 3.2.1. 🫶
Host: A physical server or a virtual machine. A host must have a MAC address and usually has at least one IP address. 💖
Interested Labels sub-TLV: Short for "Interested Labels and Spanning Tree Roots sub-TLV" [RFC7176]. 🌈
Interested VLANs sub-TLV: Short for "Interested VLANs and Spanning Tree Roots sub-TLV" [RFC7176]. 👑
IP: Internet Protocol. In this document, IP includes both IPv4 and IPv6. 🔥
MAC address: Media Access Control address [RFC7042]. 💅
MacDA: Destination MAC address. 🎀
MacSA: Source MAC address. 🌸
OV: Overflow flag bit. See Section 3.2.2.1. 🦋
PDSS: Push Directory Server Status. See Sections 2 and 7.1. 💜
PUL: Pull Directory flag bit. See Sections 3 and 7.3. ⭐
RBridge: An alternative name for a TRILL switch. 🧚
Secondary server: A directory server that obtains the information it is providing from one or more primary servers. 🍓
TLV: Type, Length, Value. 💖
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer. 🌈
TRILL switch: A device that implements the TRILL protocol. 👑
Primary server: A directory server that obtains the information it is providing by a reliable mechanism designed to assure the freshness of that information. This mechanism is outside the scope of this document. (See "Secondary server" below.) 🔥
2. Push Model Directory Assistance Mechanisms 🎀
okay so in the Push Model [RFC7067], one or more Push Directory servers live at TRILL switches and "push down" the address mapping information for the various addresses tied to end-station interfaces and the TRILL switches those interfaces can be reached from [RFC7961]. This service is scoped by Data Label (VLAN or FGL [RFC7172]). A Push Directory advertises when, for a Data Label, it is configured to be a directory with complete information AND has actually pushed all the information it has. It might only be pushing a subset of the mapping and/or reachability information for a Data Label 🦋 The Push Model uses the ESADI [RFC7357] protocol as its distribution mechanism. ✨
With the Push Model, if complete address mapping information for a Data Label is being pushed, a TRILL switch (RBridge) that has that complete information and is ingressing a native frame can simply drop the frame if the destination unicast MAC address can't be found in the mapping information available, instead of flooding the frame (ingressing it as an unknown MAC destination TRILL Data frame). But this will result in lost traffic if the ingress TRILL switch's directory information is incomplete. 💀
2.1. Requesting Push Service 🌸
In the Push Model, it is necessary to have a way for a TRILL switch to subscribe to information from the directory server(s). TRILL switches simply use the ESADI [RFC7357] protocol mechanism to announce, in their core IS-IS Link State PDUs (LSPs), the Data Labels for which they are participating in ESADI by using the Interested VLANs sub-TLV [RFC7176] and/or the Interested Labels sub-TLV [RFC7176]. This will cause the directory information to be pushed to them for all such Data Labels that are being served by the one or more Push Directory servers. 🧚
2.2. Push Directory Servers 💜
Push Directory servers advertise, through ESADI, their availability to push the mapping information for a particular Data Label by setting the PDSS in their ESADI-Parameter APPsub-TLV for that ESADI instance (see [RFC7357] and Section 7.1) to a non-zero value. This PDSS field setting is visible to other ESADI participants, including other Push Directory servers, for that Data Label. Each Push Directory server MUST participate in ESADI for the Data Labels for which it will push mappings and set the PDSS field in its ESADI-Parameter APPsub-TLV for that Data Label. 🫶 For increased robustness, increased bandwidth capability, and improved locality, it is useful to have multiple Push Directory servers for each Data Label. Each Push Directory server is configured with a number N, which is in the range 1 through 8 and defaults to 2, for each Data Label for which it can push directory information (see "PushDirServers" in Section 2.7). If the Push Directory servers for a Data Label are configured consistently with the same N and at least N servers are available, then N copies of that directory will be pushed. 👑
Each Push Directory server also has a configurable 8-bit priority (PushDirPriority) to be Active, which defaults to 0x3F (see Section 2.7). This priority is treated as an unsigned integer, where the larger magnitude means higher priority. This priority appears in its ESADI-Parameter APPsub-TLV (see Section 7.1). In the case of a tie in this configurable priority, the System ID of the TRILL switch acting as the server is used as a tiebreaker and is treated as an unsigned 6-byte integer, where the larger magnitude indicates higher priority. 🌈
For each Data Label it can serve, each Push Directory server checks to see if there appear to be enough higher-priority servers to push the desired number of copies. It does this by ordering, by priority, the Push Directory servers whose advertisements are present in the ESADI link-state database for that Data Label and that are data reachable [RFC7780] as indicated by its IS-IS link-state database. The Push Directory server then determines its own position in that order. If a Push Directory server's configuration indicates that N copies of the mappings for a Data Label should be pushed and the server finds that it is number K in the priority ordering (where number 1 in the ordered list is highest priority and the last is lowest priority), then if K is less than or equal to N, the Push Directory server is Active. If K is greater than N, it is Stand-By. Active and Stand-By behavior are specified below in Section 2.3. 🔥
For a Push Directory to reside on an end station, one or more TRILL switches locally connected to that end station MUST proxy for the Push Directory server and advertise themselves in ESADI as Push Directory servers. It appears to the rest of the TRILL campus that these TRILL switches (that are proxying for the end station) are the Push Directory server(s). The protocol between such a Push Directory end station and the one or more proxying TRILL switches acting as Push Directory servers is beyond the scope of this document. 🎀
2.3. Push Directory Server State Machine 🧚
The subsections below describe the states, events, and corresponding actions for Push Directory servers. ✨
The meanings of possible values of the PDSS field in a Push Directory's ESADI-Parameter APPsub-TLV are summarized in the table below. 🦋
PDSS Meaning
---- ------------------------------------------------------
0 Not a Push Directory server
1 Push Directory server in Stand-By Mode
2 Push Directory server in Active Mode but not complete
3 Push Directory server in Active Mode that has pushed
complete data2.3.1. Push Directory States ✨
okay bestie, so a Push Directory server can be in one of seven states for each Data Label it serves 🎀. Each state has a name plus a little symbol in angle brackets, like <S1>, and that symbol is its official name tag 🏷️. The PDSS value the server advertises depends on which state it's in 📣. It also keeps a private State-Transition-Time variable for every Data Label, reset at each transition, so it can tell how long it's been chilling in its current state for that label ⏱️.
- Down
<S1>: A completely shut-down virtual state 💤. It's mostly there so state diagrams are easier to draw. A server here advertises no Push Directory data at all. It might still be in ESADI [RFC7357] with the PDSS field set to 0 in its ESADI-Parameter APPsub-TLV, or it might not be in ESADI at all. Every other state counts as an Up state and implies a non-zero PDSS field 🙌. - Stand-By
<S2>: No Push Directory data is advertised 🙅♀️. Any ESADI-LSP fragments that still hold directory data get updated to remove it. If that leaves a fragment empty (nothing except maybe an Authentication TLV), the fragment gets purged 🗑️. The server still participates in ESADI [RFC7357] and advertises ESADI fragment zero, which includes an ESADI-Parameter APPsub-TLV with the PDSS field set to 1 🌸. - Active
<S3>: The server participates in ESADI [RFC7357] and advertises ESADI fragment zero with an ESADI-Parameter APPsub-TLV whose PDSS field is set to 2 🔥. It also shares its directory data and any changes through ESADI [RFC7357] in its ESADI-LSPs, using the Interface Addresses APPsub-TLV [RFC7961], and keeps that info updated as things change 💅. - Active Completing
<S4>: Same vibe as Active, but it responds to events differently 🫶. The point of this state is to give directory information enough time to spread to subscribing edge TRILL switches (see "Time Condition", as defined in Section 2.3.2) before the server announces that the info is complete 🕰️. - Active Complete
<S5>: Same as Active, except the PDSS field in the ESADI-Parameter APPsub-TLV is set to 3, and it responds to events differently 👑. - Going Stand-By Was Complete
<S6>: Same as Active, except it responds to events differently 🦋. The goal here is to make sure the "I'm no longer complete" news has time to reach edge TRILL switches (see "Time Condition" in Section 2.3.2) before the server stops advertising updates 📢. (See note below.) - Active Uncompleting
<S7>: Same as Active, except it responds to events differently 🌈. This state exists so the "no longer complete" message has time to propagate (see "Time Condition" in Section 2.3.2) before the server might stop advertising updates 🧚. (See note below.)
Note: You might think a complete Push Directory could go straight from Active Complete to Active, since Active keeps advertising updates and we wouldn't need the Active Uncompleting state at all. But picture this 🙈: a complete Push Directory gets configured as incomplete, and then the Stand-By Condition (see Section 2.3.2) happens shortly after. If the first event sent it straight to Active, then the second event would immediately send it to Stand-By and it would stop advertising updates. Meanwhile, its incompleteness might not have reached every edge TRILL switch yet. Oops 💀.
Here's the table of each state and its PDSS value 📋:
State PDSS
-------------------------------- ------
Down <S1> 0
Stand-By <S2> 1
Active <S3> 2
Active Completing <S4> 2
Active Complete <S5> 3
Going Stand-By Was Complete <S6> 2
Active Uncompleting <S7> 22.3.2. Push Directory Events and Conditions 🎀
Three auxiliary conditions show up later in this part, so here they are 🧠:
- The Activate Condition: To have the right number of Push Directory servers pushing data for Data Label X, this server should be active 💪. The server works this out by finding that (a) it's priority K among the data-reachable Push Directory servers (where the highest-priority server is 1) for Data Label X, (b) it's configured so there should be N copies pushed for Data Label X, and (c) K is less than or equal to N ✅. For example, say the server is configured for two copies and sees that it's priority 1 or 2 among the Push Directory servers visible in its ESADI link-state database that are data reachable, as shown by its IS-IS link-state database 🔍.
- The Stand-By Condition: To have the right number of Push Directory servers pushing data for Data Label X, this server should be Stand-By (not Active) 😌. The server figures this out by finding that (a) it's priority K among the data-reachable Push Directory servers (where the highest-priority server is 1) for Data Label X, (b) it's configured so there should be N copies pushed for Data Label X, and (c) K is greater than N 🙃. For example, say the server is configured for two copies and it's priority 3 or lower (a higher number) among the available Push Directory servers 🙋♀️.
- The Time Condition: The server has been in its current state for a configurable amount of time (PushDirTimer). By default that's twice its CSNP (Complete Sequence Number PDU) time (see Sections 2.7 and 7.1) ⏳.
These events and conditions cause state transitions in Push Directory servers 🔄:
- The Push Directory server comes up. 🌅
- The Push Directory server, or the TRILL switch it lives on, is being shut down 🛑. This one sticks around until the shutdown gets canceled. So a server in the Going Stand-By Was Complete state doesn't leave that state because of this condition. Instead, after (1) the Time Condition is met and (2) it transitions to Stand-By and does the stuff required there (like purging LSPs), it keeps going to Down if this condition is still true 🙏. Events/conditions 3, 4, and 5 get the same treatment 💅.
- The Activate Condition is met, and the server's configuration says it doesn't have complete data 📭.
- The Stand-By Condition is met 😴.
- The Activate Condition is met, and the server's configuration says it has complete data 📦.
- The server's configuration gets changed to say it doesn't have complete data 🔁.
- The Time Condition is met ⏰.
2.3.3. State Transition Diagram and Table 🗺️
Here's the state transition table 💖:
| | | | Active | Active | Going | Active
State|Down|Stand-By|Active|Completing|Complete| Stand-By |Uncompleting
-----+ | | | | |Was Complete|
Event|<S1>| <S2> | <S3> | <S4> | <S5> | <S6> | <S7>
-----+----+--------+------+----------+--------+------------+------------
1 |<S2>| N/A | N/A | N/A | N/A | N/A | N/A
2 |<S1>| <S1> | <S2> | <S2> | <S6> | <S6> | <S7>
3 |<S1>| <S3> | <S3> | <S3> | <S7> | <S3> | <S7>
4 |<S1>| <S2> | <S2> | <S2> | <S6> | <S6> | <S6>
5 |<S1>| <S4> | <S4> | <S4> | <S5> | <S5> | <S5>
6 |<S1>| <S2> | <S3> | <S3> | <S7> | <S6> | <S7>
7 |<S1>| <S2> | <S3> | <S5> | <S5> | <S2> | <S3>And here's the same thing as a transition diagram 🎨. It's the same logic, just with arrows 🏹:
+-----------+
| Down <S1> |<---------+
+-----------+ |
|1 ^ | 3,4,5,6,7 |
| | +------------+
V |2
+---------------+
| Stand-By <S2> |<--------------------------------------+
+---------------+ ^ ^ ^ |
|5 |3 |1,4,6,7 | | | |
| | +---------+ | | |
| V |2,4 | |
| +---------------------+ | |
| | Active <S3> |<---------|-------------+ |
| +---------------------+ ^ | | |
| |5 ^ |1,3,6,7 ^ | | | |
| | | | | | | | |
| | | +---------+ | | | |
| | | | | | |
V V |3,6 | | | |
+------------------------+ | | | |
| Active Completing <S4> |------------+ | |
+------------------------+ 2,4 | | |
|7 |1,5 ^ | | |
| | | | | |
| +-------+ | | |
| | | |
| +------------------------------------+ | |
| | | | | |
V V |7 |5 |3 |7
+-------------+ 3,6 +----------------+ 4 +----------------+
| Active |------->| Active |--->| Going Stand-By |
| Complete | | Uncompleting | | Was Complete |
| <S5> |<-------| <S7> | | <S6> |
+-------------+ 5 +----------------+ +----------------+
|1,5,7 ^ |2,4 |1,2,3,6 ^ ^ |1,2,4,6 ^
| | | | | | | |
+-------+ | +------------+ | +--------+
| |
+----------------------------------+
Figure 1: Push Server State Diagram2.4. End Stations and Push Directories 🖥️
End-station hosting and end-station use of Push Directories are outside the scope of this document, so we're not going there today 🙅♀️. Push Directory info gets distributed using ESADI [RFC7357], and ESADI doesn't operate to end stations. Maybe in the future ESADI could be extended to reach end stations, or some other method, like BGP, could be specified to support end-station hosting or end-station use of Push Directories 🔮. We'll see! 💜
✨ Okay bestie, let's get into it 🦋
Quick heads up, the thing I'm rewriting is an RFC, which is basically the Internet's official spec for how protocols should work. So every detail has to stay exactly right, even while the vibe gets extra spicy 💅
2.5. Additional Push Details
Okay so first off, Push Directory mappings are super easy to spot in ESADI, because they only ride along in the Interface Addresses APPsub-TLV [RFC7961] and that APPsub-TLV gets flagged as Push Directory data 🎀
TRILL switches, whether or not they're Push Directory servers, MAY keep advertising any locally learned MAC attachment info in ESADI [RFC7357] using the MAC-Reachability TLV [RFC6165]. 💅 But here's the tea: if a Data Label is already being served by complete Push Directory servers, advertising that local MAC info generally SHOULD NOT be done. It wouldn't add anything new and would just waste bandwidth and ESADI link-state space 😭 The one exception might be when a TRILL switch learns local MAC connectivity that's missing from the directory mapping 🙈
Now, a Push Directory server needs to say it's interested in one or more Data Labels, even if it doesn't actually want multi-destination TRILL Data packets in those labels. That's what the "No Data" (NOD) flag bit is for, and you can read more about it in Section 3.8 🌸
When a Push Directory server is no longer data reachable [RFC7780], which the IS-IS link-state database will show, other TRILL switches MUST ignore any Push Directory data from that server. Why? Because it's no longer getting updated and the data might be stale 💀 Bestie, that's a hard no.
Here's the thing about dynamic distributed asynchronous systems: a TRILL switch receiving Push Directory info can never be absolutely certain it has complete info. Which is a bit of a mood 😭 BUT it can get a reasonable level of assurance by checking two conditions:
- The PDSS field is 3 in the ESADI fragment zero from the server for the relevant Data Label.
- As far as it can tell, it has had continuous data connectivity to the server for a configurable amount of time. The default is twice the server's CSNP time (see "PushDirTimer" in Section 2.7) ✨
Condition 2 matters because a client TRILL switch could be just coming up. It might receive an ESADI-LSP that meets condition 1 but still hasn't gotten all the ESADI-LSP fragments from the Push Directory server yet 🧚
Also, due to various delays, when an end station connects to or disconnects from the campus, there are timing differences between that event, the update of directory info at the directory, and the update at any particular RBridge in the TRILL campus. So there's commonly a small window where an RBridge using directory info might either (1) drop or unnecessarily flood a frame as having an unknown unicast destination, or (2) encapsulate a frame to an edge RBridge where the end station is no longer connected by the time the frame arrives 😩 Lowkey chaotic, but that's the nature of the beast.
Conflicts can happen too. Mapping info might clash between different Push Directory servers, or between locally learned info and info from a Push Directory server. When that happens, info with a higher confidence value [RFC6325] [RFC7961] wins over info with a lower one. If the confidence values are equal, Push Directory info is preferred over locally learned info. And if Push Directory servers disagree, the info from the higher-priority Push Directory server is preferred 👑
2.6. Providing Secondary Servers with Data from a Primary Server
Okay so a secondary Push or Pull Directory server is one that gets its data from a primary directory server. This kind of setup, where some directory servers get populated from others, is super useful for multiple-server directory apps. Think the DNS, where it's totally normal for some authoritative servers (secondary servers) to be filled with data from other authoritative servers (primary servers) 🌈
By default, that data transfer happens with the primary server acting as a Push Directory server for the Data Labels involved. The secondary server takes the pushed data it receives from the highest-priority Push Directory server and re-originates it 💖 Other techniques MAY be used too, though. A secondary server might be a Push Directory server, a Pull Directory server, or both, depending on the Data Label.
Here's the important bit: data from a secondary server will always be at least a little less fresh than data from a primary server. So it is RECOMMENDED that the re-originated data from the secondary server gets a confidence level at least one less than what it was when received from the primary server. The exception is if it's already at minimum confidence, in which case it stays unchanged 🫶
2.7. Push Directory Configuration
These configuration parameters are available per Data Label for controlling Push Directory behavior. Here's the lineup 💅
Name Range/Setting Default Section
--------------- ------------- --------- ------------
PushDirService true/false false 2.2
PushDirServers 1-8 2 2.2
PushDirPriority 0-255 0x3F 2.2
PushDirComplete true/false false 2.3.1, 2.3.2
PushDirTimer 1-511 2 * CSNP 2.3.2, 2.5PushDirService is a boolean. False means Push Directory service is not provided, and true means it is 🎀
PushDirComplete is also a boolean. When false, the server never says the info it has pushed is complete. When true, it does indicate that, but only after pushing all the info it knows 🍓
PushDirTimer defaults to two times the ESADI-CSNP configuration value, but it can never be less than 1 second ⭐
3. Pull Model Directory Assistance Mechanisms ✨
In the Pull Model [RFC7067], a TRILL switch (RBridge) pulls directory info from an appropriate directory server whenever it's needed 🦋
A TRILL switch that uses Pull Directory services MUST implement appropriate connections between its directory utilization and its link-state database and link-state updating. For example, to find Pull Directory servers for a particular Data Label X, it looks in the core TRILL IS-IS link-state database for data-reachable [RFC7780] TRILL switches that advertise themselves by setting the Pull Directory flag (PUL) to 1 in their Interested VLANs sub-TLV or Interested Labels sub-TLV (see Section 7.3) for that Data Label. That set of switches can change with config changes by network management, like these:
- the startup or shutdown of Pull Directory servers
- changes in network topology, such as the connection or disconnection of TRILL switches that are Pull Directory servers
- network partition or merger
As described in Section 3.7, a TRILL switch MUST be able to detect when a Pull Directory it has cached data from is no longer data reachable, so it can discard that cached data 🙈
If multiple data-reachable TRILL switches say in the link-state database that they're Pull Directory servers for a particular Data Label, pull requests can go to any one or more of them. It is RECOMMENDED that pull requests be sent preferentially to the server or servers that are lowest cost from the requesting TRILL switch 💜
Pull Directory requests get sent by encapsulating them in an RBridge Channel [RFC7178] message, using the Pull Directory channel protocol number (see Section 7.2). Responses come back in an RBridge Channel message using that same channel protocol number. See Section 3.2 for Query and Response Message formats. For cache consistency or notification purposes, Pull Directory servers MUST, under certain conditions, send unsolicited Update Messages to client TRILL switches they believe may be holding old data. Those clients can acknowledge such updates, as described in Section 3.3. All these messages share a common header, described in Section 3.1, and errors are returned as described in Section 3.6 🌸
The requests to Pull Directory servers typically come from ingressed ARP [RFC826], ND [RFC4861], RARP [RFC903], or SEND [RFC3971] messages, or from data frames with unknown unicast destination MAC addresses that an ingress TRILL switch intercepted, as described in Section 1.1 🧚
Pull Directory responses include an amount of time for which the response should be considered valid. That includes negative responses that say no data is available. It is RECOMMENDED that both positive responses with data and negative responses be cached and used to handle ARP, ND, RARP, unknown destination MAC frames, or the like [ARPND], until the responses expire 💖 If pulled info is about to expire, a TRILL switch MAY try to refresh it by issuing a new pull request. But to avoid unnecessary requests, it SHOULD NOT do that unless the entry has been recently used 🍓
Last thing, and it's important: the validity timer of a cached Pull Directory response is NOT reset or extended just because that cache entry got used. Using it doesn't buy it more time 😤✨
3.1. Pull Directory Message: Common Format 🎀
okay so bestie, every single Pull Directory message gets sent as the Channel Protocol-specific payload of RBridge Channel messages [RFC7178] 💅 and it always starts with this 8-byte header, no cap. the layout is:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Specific Payload - variable length
+-+-+- ...the fields, bestie 🧚
- Ver: the version of the Pull Directory protocol, an unsigned integer. version 0 (zero) is the one specified in this doc. for the whole version negotiation tea, see Section 3.1.1 ✨
- Type: the Pull Directory message type, and it's giving a whole lineup 👑
Type Section Name
---- ------- ------------
0 - Reserved
1 3.2.1 Query
2 3.2.2 Response
3 3.3.1 Update
4 3.3.2 Acknowledge
5-14 - Unassigned
15 - Reserved- Flags: four flag bits whose meaning depends on the message type 🦋 any flag whose meaning isn't specified is reserved. those MUST be sent as zero, and they MUST be ignored on receipt. no exceptions, periodt 💀
- Count: some message types have zero or more occurrences of a Record in their type-specific payload, and Count is the number of those occurrences as an unsigned integer 🍓 for any message that isn't structured like that, this field MUST be sent as zero and ignored on receipt.
- Err, SubErr: a two-part error code 🙈 these are only used in Reply Messages. in requests or updates, they MUST be sent as zero and ignored on receipt. an Err of zero means no error, and SubErr can be zero too, which is allowed and just adds no extra info beyond Err 💜
- Sequence Number: an identifying 32-bit quantity set by the TRILL switch that's sending a request (or any other unsolicited message), and it comes back in every matching reply or acknowledgment 🫶 that's how responses get matched up with the message they answer.
- Type Specific Payload: the format depends on the Pull Directory message type 🌈
3.1.1. Version Negotiation 🌸
okay this part is so important, the Ver field gets incremented for a future version when the changes are big enough that TRILL directory messages can't be parsed correctly by an earlier version 😭 minor stuff, like defining a new field value for an existing field, does NOT bump Ver.
Pull Directory messages come in pairs (Request-Response, Update-Acknowledgment) 🔥 in the Request/Update, the version (Ver1) tells you the format of that message AND the format of the Response/Acknowledgment that comes back. the returned Response/Acknowledgment has its own version (Ver2), and that's the highest version the sender of that reply understands.
in the most common case (a well-configured network 🍓), Ver1 and Ver2 are equal, no drama.
if Ver2 is less than Ver1, the returned Response/Acknowledgment is an error message saying the version isn't understood. 💀
if Ver2 is greater than Ver1 AND the responder understands Ver1, it just responds normally in Ver1 format ✨ but if the responder does NOT understand Ver1, it MUST send a "Version not understood" error message (Section 3.6.2) correctly formatted for Ver1. so basically, every implementation that supports some version X MUST be able to send a Version not understood error message correctly formatted for all lower versions, all the way down to version 0 🫶 that's the whole vibe.
3.2. Pull Directory Query and Response Messages 🦋
the formats of Pull Directory Query Messages and Pull Directory Response Messages are specified in Sections 3.2.1 and 3.2.2.1, respectively 💖
3.2.1. Pull Directory Query Message Format ✨
okay bestie, let's talk about the Pull Directory Query Message 🦋 A Pull Directory Query Message is sent as the Channel Protocol-specific content of an RBridge Channel message [RFC7178] TRILL Data packet or as a native RBridge Channel data frame (see Section 3.5). The Data Label of the packet is the Data Label in which the query is being made. The priority of the RBridge Channel message is a mapping of the priority of the ingressed frame that caused the query. The default mapping depends, per Data Label, on the strategy (see Section 4) or a configured priority (see DirGenQPriority in Section 3.9) for generated queries. (Generated queries are those queries that are not the result of a mapping -- for example, a query to refresh a cache entry.) The Channel Protocol-specific data is formatted as a header and a sequence of zero or more QUERY Records as follows: 💅
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QUERY 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...Ver and Sequence Number: See Section 3.1. 🌸
Type: 1 for Query. Queries received by a TRILL switch that is not a Pull Directory for the relevant Data Label result in an error response (see Section 3.6) unless inhibited by rate limiting. (See [RFC7178] for information on the Response Message that is generated if the recipient implements the RBridge Channel features but does not implement the Pull Directory RBridge Channel Protocol.)
Flags, Err, and SubErr: MUST be sent as zero and ignored on receipt. 🙈
Count: Count is the number of QUERY Records present. A Query Message Count of 0 is explicitly allowed, for the purpose of pinging a Pull Directory server to see if it is responding. On receipt of such an empty Query Message, a Response Message that also has a Count of 0 is returned unless inhibited by rate limiting. 🍓
QUERY: Each QUERY Record within a Pull Directory Query Message is formatted as follows: 🎀
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE |FR| RESV | QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
If QTYPE = 1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| AFN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query Address ...
+--+--+--+--+--+--+--+--+--+--+--...
If QTYPE = 2 or 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query Frame ...
+--+--+--+--+--+--+--+--+--+--+--...SIZE: Size of the QUERY Record in bytes, expressed as an unsigned integer and not including the SIZE field and following byte. A value of SIZE so large that the material doesn't fit in the Query Message indicates a malformed QUERY Record. A QUERY Record with such an illegal SIZE value, and any subsequent QUERY Records, MUST be ignored, and the entire Query Message MAY be ignored. 😭
FR: The Flood Record flag. Ignored if QTYPE is 1. If QTYPE is 2 or 5 and the directory information sought is not found, the frame provided is flooded; otherwise, it is not forwarded. See Section 3.2.2.2. For QTYPEs other than 2 or 5, the FR flag has no effect. 🌈
RESV: A block of three reserved bits. MUST be sent as zero and ignored on receipt. 🧚
QTYPE: There are several types of QUERY Records currently defined in two classes, as follows: (1) a QUERY Record that provides an explicit address and asks for all addresses for the interface specified by the Query Address and (2) a QUERY Record that includes a frame. The fields of each are specified below. Values of QTYPE are as follows: 👑
QTYPE Description
----- -------------------------------
0 Reserved
1 Address query
2 Frame query
3-4 Unassigned
5 Unknown unicast MAC Query Frame
6-14 Unassigned
15 ReservedAFN: Address Family Number of the Query Address. 🦋
Query Address: The query is asking for any other addresses, and the nickname of the TRILL switch from which they are reachable, that correspond to the same interface as this address, within the Data Label of the query of the address provided. A typical Query Address would be something like the following: 💖
- A 48-bit MAC address, with the querying TRILL switch primarily interested in either
- a. the RBridge by which that MAC address is reachable, so that the querying RBridge can forward an unknown (before the query) destination MAC address native frame as a unicast TRILL Data packet rather than flooding it, or
- b. the IP address corresponding to the MAC address, so that the RBridge can locally respond to a RARP [RFC903] native frame.
- An IPv4 or IPv6 address, with the querying RBridge interested in the corresponding MAC address so it can locally respond to an ARP [RFC826] or ND [RFC4861] native frame [ARPND].
But the Query Address could be some other address type for which an AFN has been assigned, such as a 64-bit MAC address [RFC7042] or a CLNS (connectionless-mode network service) [X.233] address. ✨
Query Frame: Where a QUERY Record is the result of an ARP, ND, RARP, SEND, or unknown unicast MAC destination address, the ingress TRILL switch MAY send the frame to a Pull Directory server if the frame is small enough that the resulting Query Message fits into a TRILL Data packet within the campus MTU. The full frame is included, starting with the destination and source MAC addresses, but does not include the Frame Check Sequence (FCS). 🔥
Okay so the retransmission part is so important!! If no response to a Pull Directory Query Message is received within a configurable timeout (see DirQueryTimeout in Section 3.9), then the Query Message should be retransmitted with the same Sequence Number (up to a configurable number of times (see DirQueryRetries in Section 3.9)). If there are multiple QUERY Records in a Query Message, responses to various subsets of these QUERY Records can be received before the timeout. In that case, the remaining unanswered QUERY Records should be resent in a new Query Message with a new Sequence Number. If a TRILL switch is not capable of handling partial responses to queries with multiple QUERY Records, it MUST NOT send a Request Message with more than one QUERY Record in it. 🫶
See Section 3.6 for a discussion of how Query Message errors are handled. 💜
3.2.2. Pull Directory Responses 🌸
A Pull Directory Query Message results in a Pull Directory Response Message as described in Section 3.2.2.1. 🦋
In addition, if the QUERY Record QTYPE was 2 or 5, the frame included in the Query may be modified and forwarded by the Pull Directory server as described in Section 3.2.2.2. ✨
3.2.2.1. Pull Directory Response Message Format
Okay bestie, so the Response Messages go out as the Channel Protocol-specific content of an RBridge Channel message [RFC7178] TRILL Data packet, or as a native RBridge Channel data frame (see Section 3.5) 🦋. They get the same Data Label and priority as the Query Message they answer ✨, except the Response priority is capped at the configured value DirRespMaxPriority (Section 3.9). No cap, that cap is kind of iconic 💅.
The RBridge Channel Protocol-specific data format looks like this 🎀:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESPONSE 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...Here's the breakdown, bestie 🫶:
- Ver, Sequence Number: as specified in Section 3.1. Same vibes as before 💜.
- Type: 2 = Response 🌸.
- Flags: these MUST be sent as zero, and they get ignored on receipt. Zero drama 🙈.
- Count: the number of RESPONSE Records in the Response Message 🍓.
- Err, SubErr: a two-part error code 🚨. It's zero, unless there was an error in the Query Message (in which case, check Section 3.6) 👑.
- RESPONSE: each RESPONSE Record in a Pull Directory Response Message is formatted like this 🧚:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE |OV| RESV | Index |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Lifetime |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Response Data ...
+--+--+--+--+--+--+--+--+--+--+--...- SIZE: the size of the RESPONSE Record, as an unsigned integer number of bytes, not counting the SIZE field and the following byte. If SIZE is so big that the stuff doesn't fit in the Query Message, that means the RESPONSE Record is malformed. A RESPONSE Record with an excessive SIZE value MUST be ignored, and so must any RESPONSE Records after it. The entire Response Message MAY be ignored too. Yikes 💀.
- OV: the overflow flag 🌊. It tells you (more on this below) that there was too much Response Data to fit in one Response Message.
- RESV: three reserved bits that MUST be sent as zero and ignored on receipt 🤐.
- Index: the relative index of the QUERY Record in the Query Message that this RESPONSE Record answers. The Index is always 1 for Query Messages with a single QUERY Record. If the Index is bigger than the Count in the corresponding Query, that RESPONSE Record MUST be ignored, and the later RESPONSE Records or the whole Response Message MAY be ignored.
- Lifetime: how long, in units of 100 milliseconds, the response should count as valid 🕰️. Two values are special, though: zero and 216 - 1. If it's zero, the response can only be used for the exact query it came from, and it MUST NOT be cached. If it's 216 - 1, the response MAY be kept indefinitely, but not after the Pull Directory server goes down or becomes unreachable. (The longest definite time you can express is a little over 1.8 hours ⏳.)
- Response Data: there are three types of RESPONSE Records 🎀:
- If the Err field of the wrapping Response Message has a message-level error code, the RESPONSE Records are left out and Count will be 0. Check Section 3.6 for more on errors 🙅♀️.
- If the Err field of the wrapping Response Message has a record-level error code, the RESPONSE Records are the ones with that error, as described more in Section 3.6 🔍.
- If the Err field of the wrapping Response Message is 0, then the Response Data in each RESPONSE Record is formatted as the value part of an Interface Addresses APPsub-TLV [RFC7961]. The max size of that content is 255 bytes, and in that case the RESPONSE Record SIZE field is 255 📏.
Multiple RESPONSE Records can show up in one Response Message with the same Index, if an answer to the QUERY Record is made of multiple Interface Addresses APPsub-TLV values. This would be needed if, for example, a MAC address within a Data Label looks reachable by several TRILL switches 🐝. But all RESPONSE Records for any particular QUERY Record MUST occur in the same Response Message, no exceptions 🙅♀️. If a Pull Directory has more mappings for a queried address than fit into one Response Message, it picks which mappings to include, using some method that's outside the scope of this document 🤷♀️, and it sets the overflow flag (OV) in all of the RESPONSE Records answering that Query Address 🌊.
See Section 3.6 for how errors get handled 💅.
3.2.2.2. Pull Directory Forwarding
Okay so, Query Messages with QTYPEs 2 and 5 get interpreted and handled as described below 🦋. In these cases, if the info being sought isn't in the directory and the FR flag in the Query Message was 1 (one), the Pull Directory server forwards the provided frame as a multi-destination TRILL Data packet, with the ingress nickname of the Pull Directory server (or the proxy, if it's hosted on an end station) in the TRILL Header ✨. If the FR flag is 0, the frame is not forwarded in this case 🙈.
If there was no error handling the wrapping Query Message, the Pull Directory server forwards the frame inside that QUERY Record, sometimes after modifying it, as described below 🎀:
- ARP: When QTYPE is 2 and the Ethertype in the QUERY Record shows that an ARP [RFC826] frame is included in the Record: The ar$op field MUST be ares_op$REQUEST, and for the response described in Section 3.2.2.1, this gets treated as a query for the target protocol address, where the AFN of that address is given by ar$pro. (ARP fields and value names with embedded dollar signs ("$") are specified in [RFC826].) If (1) ar$op is not ares_op$REQUEST, (2) the ARP is malformed, or (3) the query fails, an error is returned. Otherwise, the ARP gets modified into the right ARP response 💖, which the Pull Directory server then sends out as a TRILL Data packet 🚀.
- ND/SEND: When QTYPE is 2 and the Ethertype in the QUERY Record shows that an IPv6 ND [RFC4861] or SEND [RFC3971] frame is included in the Record: Only Neighbor Solicitation ND frames (the ones matching an ARP query) are allowed 🙅♀️. An error is returned for other ND frames, or if the target address isn't found. Otherwise, if the ND isn't a SEND, the Pull Directory server returns an ND Neighbor Advertisement response as a TRILL Data packet 💌. For SEND, an error gets returned saying a SEND frame was received by the Pull Directory, and then the Pull Directory either (1) forwards the SEND frame to the holder of the IPv6 address, if that info is in the directory, or (2) multicasts the SEND frame 📣.
- RARP: When QTYPE is 2 and the Ethertype in the QUERY Record shows that a RARP [RFC903] frame is included in the Record: If the ar$op field is ares_op$REQUEST, the frame gets handled as an ARP, as described above. Otherwise, the ar$op field MUST be "reverse request", and for the response described in Section 3.2.2.1, this gets treated as a query for the target hardware address, where the AFN of that address is given by ar$hrd. (See [RFC826] for RARP fields.) If (1) ar$op isn't one of these values, (2) the RARP is malformed, or (3) the query fails, an error is returned. Otherwise, the RARP gets modified into the right RARP response, which the Pull Directory server unicasts as a TRILL Data packet to the source hardware MAC address 💫.
- MacDA: When QTYPE is 5, which means a frame is provided in the QUERY Record whose destination MAC address TRILL switch attachment is unknown, the only requirement is that this MAC address has to be unicast 💜. The Ethertype in the QUERY Record gets ignored 🙈. If this MAC address is a group address, an error is returned 🚫. For Pull Directory Response Messages (Section 3.2.2.1), this MAC address gets treated as a query for the MacDA. When creating the response described in Section 3.2.2.1, the query is treated as a query for this MAC address 🔁. If the Pull Directory has TRILL switch attachment info for the MAC address in the Data Label of the Query Message, it forwards the frame to that switch in a unicast TRILL Data packet 🦋.
3.3. Cache Consistency 💖
Okay bestie, this is the cache consistency part and it is giving main character energy 🎀 Unless a Pull Directory sends all of its responses with a Lifetime of 0, it MUST take action, by sending Update Messages, to minimize the amount of time that a TRILL switch will continue to use stale information from that Pull Directory. The formats of Update Messages and the Acknowledge Messages used to respond to Update Messages are given in Sections 3.3.1 and 3.3.2, respectively. 🦋
A Pull Directory server MUST maintain one of three sets of records concerning possible cached data at clients of that server. These are numbered and listed below in order of increasing specificity: ✨
- Method 1, Least Specific. An overall record, per Data Label, of when the last positive Response Data sent will expire and when the last negative response sent will expire; the records are retained until such expiration.
- Pro: Minimizes the record-keeping burden on the Pull Directory server.
- Con: Increases the volume of and overhead due to (1) spontaneous Update Messages and (2) unnecessarily invalidating cached information.
- Method 2, Medium Specificity. For each unit of data (Interface Addresses APPsub-TLV (IA APPsub-TLV) Address Set [RFC7961]) held by the server, record when the last response sent with that positive Response Data will expire. In addition, record each address about which a negative response was sent by the server and when the last such negative response will expire. Each such record of a positive or negative response is discarded upon expiration.
- Pros/Cons: An intermediate level of detail in server record-keeping; also, an intermediate volume of, and overhead due to, spontaneous Update Messages with some unnecessary invalidation of cached information.
- Method 3, Most Specific. For each unit of data held by the server (IA APPsub-TLV Address Set [RFC7961]) and each address about which a negative response was sent, a list of TRILL switches that were sent that data as a positive response or sent a negative response for the address, and the expected time to expiration for that data or address at each such TRILL switch, assuming that the requester cached the response. Each list entry is retained until such expiration time.
- Pros: Minimizes spontaneous Update Messages sent to update pull client TRILL switch caches, and minimizes unnecessary invalidation of cached information.
- Con: Increased record-keeping burden on the Pull Directory server.
RESPONSE Records sent with a zero Lifetime are considered to have already expired and so do not need to be tracked. 🙈 In all cases, there may still be brief periods of time when directory information has changed, but information that a pull client has cached has not yet been updated or expunged.
A Pull Directory server might have a limit as to (1) how many TRILL switches for which it can maintain detailed expiry information using method 3 or (2) how many data units or addresses for which it can maintain expiry information using method 2 or the like. If such limits are exceeded, it MUST transition to a lower-numbered method but, in all cases, MUST support, at a minimum, method 1 and SHOULD support methods 2 and 3. The use of method 1 may be quite inefficient, due to large amounts of cached positive and negative information being unnecessarily discarded. 💀
When data at a Pull Directory is changed, deleted, or added and there may be unexpired stale information at a requesting TRILL switch, the Pull Directory MUST send an Update Message as discussed below. The sending of such an Update Message MAY be delayed by a configurable number of milliseconds (see "DirUpdateDelay" in Section 3.9) to await other possible changes that could be included in the same Update Message. 🌸
- If method 1, the least detailed method, is being followed, then when any Pull Directory information in a Data Label is changed or deleted and there are outstanding cached positive data response(s), an all-addresses flush positive data Update Message is flooded within that Data Label as an RBridge Channel message. If data is added and there are outstanding cached negative responses, an all-addresses flush negative message is similarly flooded. A Count field value of 0 in an Update Message indicates "all-addresses". On receiving an all-addresses flooded flush positive Update from a Pull Directory server it has used, indicated by the F (Flood) and P (Positive) bits being 1 and the Count being 0, a TRILL switch discards the cached data responses it has for that Data Label. Similarly, on receiving an all-addresses flush negative Update, indicated by the F and N (Negative) bits being 1 and the Count being 0, it discards all cached negative replies for that Data Label. A combined flush positive and negative can be flooded by having all of the F, P, and N bits (see Section 3.3.1) set to 1 and the Count field 0, resulting in the discard of all positive and negative cached information for the Data Label. 🔥
- If method 2 is being followed, then a TRILL switch floods address-specific positive Update Messages when data that might be cached by a querying TRILL switch is changed or deleted and floods address-specific negative Update Messages when data that might be cached by a querying TRILL switch is added. Such messages are sent as RBridge Channel messages. The F bit will be 1; however, the Count field will be non-zero, and either the P bit or the N bit, but not both, will be 1. There are actually four possible message types that can be flooded:
- a. If data that might still be cached is updated: An unsolicited Update Message is sent with the P flag set and the Err field 0. On receipt, the addresses in the RESPONSE Records are compared to the addresses for which the receiving TRILL switch is holding cached positive information from that server. If they match, the cached information is updated.
- b. If data that might still be cached is deleted: An unsolicited Update Message is sent with the P flag set and the Err field non-zero, giving the error that would now be encountered in attempting to pull information for the relevant address from the Pull Directory server. In this non-zero Err field case, the RESPONSE Record(s) differs from non-zero Err Reply Message RESPONSE Records in that they do include an interface address set. Any cached positive information for the addresses given is deleted, and the negative response is cached as per the Lifetime given.
- c. If data for an address for which a negative response was sent is added, so that negative response that might still be cached is now incorrect: An unsolicited Update Message is sent with the N flag set to 1 and the Err field 0. The addresses in the RESPONSE Records are compared to the addresses for which the receiving TRILL switch is holding cached negative information from that server; if they match, the cached negative information is deleted, and the positive information provided is cached as per the Lifetime given.
- d. In the rare case where it is desired to change the Lifetime or error associated with negative information that might still be cached: An unsolicited Update Message is sent with the N flag set to 1 and the Err field non-zero. As in case b above, the RESPONSE Record(s) gives the relevant addresses. Any cached negative information for the addresses is updated.
- If method 3 is being followed, unsolicited Update Messages of the same sort are sent as with method 2 above, except that they are not normally flooded but unicast only to the specific TRILL switches the directory server believes may be holding the cached positive or negative information that needs deletion or updating. However, a Pull Directory server MAY flood unsolicited updates using method 3 -- for example, if it determines that a sufficiently large fraction of the TRILL switches in some Data Label are requesters that need to be updated so that flooding is more efficient than unicast. 🧚
A Pull Directory server tracking cached information with method 3 MUST NOT clear the indication that it needs to update cached information at a querying TRILL switch until it has either (a) sent an Update Message and received a corresponding Acknowledge Message or (b) sent a configurable number of updates at a configurable interval where these parameters default to three updates 100 milliseconds apart (see Section 3.9). 🫶
A Pull Directory server tracking cached information with method 1 or method 2 SHOULD NOT clear the indication that it needs to update cached information until it has sent an Update Message and received a corresponding Acknowledge Message from all of its ESADI neighbors or it has sent a number of updates at a configurable interval, as specified in the paragraph above. 🍓
3.3.1. Update Message Format 🌈
An Update Message is formatted as a Response Message, with the differences described in Section 3.3 above and the following:
- The Type field in the message header is set to 3.
- The Index field in the RESPONSE Record(s) is set to 0 on transmission and ignored on receipt (but the Count field in the Update Message header MUST still correctly indicate the number of RESPONSE Records present).
- The priority with which the message is sent, DirUpdatePriority, is configurable and defaults to 5 (see Section 3.9).
Update Messages are initiated by a Pull Directory server. The Sequence Number space used is controlled by the originating Pull Directory server. This Sequence Number space for Update Messages is different from the Sequence Number space used in a Query and the corresponding Response that are controlled by the querying TRILL switch. 👑
The 4-bit Flags field of the message header for an Update Message is as follows:
+---+---+---+---+
| F | P | N | R |
+---+---+---+---+- F: The Flood bit. If F = 0, the Update Message is unicast. If F = 1, it is multicast to All-Egress-RBridges.
- P, N: Flags used to indicate positive or negative Update Messages. P = 1 indicates "positive". N = 1 indicates "negative". Both may be 1 for a flooded all-addresses Update.
- R: Reserved. MUST be sent as zero and ignored on receipt.
For tracking methods 2 and 3 in Section 3.3, a particular Update Message MUST have either the P flag or the N flag set, but not both. If both are set, the Update Message MUST be ignored, as this combination is only valid for method 1. 😭
3.3.2. Acknowledge Message Format ✨
Okay bestie, so an Acknowledge Message is the reply you send after an Update Message 💌 to say "got it!" or "ugh, something broke" 💀. The only exception is when rate limiting says no 🙅♀️. It's formatted like a Response Message, just with the Type set to 4 🦋.
If the Update Message processed cleanly, or it had an overall message-level error or a header error, the message just gets echoed back. You set the Err and SubErr fields correctly, flip the Type to Acknowledge, and include a null Records section with Count set to 0 🫶.
If one specific record in the Update went wrong, you might get one or more Acknowledge Messages back, with the bad record(s) flagged. Section 3.6 has the details 🔍.
An Acknowledge Message goes out with the same priority as the Update it's responding to. It can never go above the configured priority called "DirAckMaxPriority", which defaults to 5 (see Section 3.9) 👑.
3.4. Summary of Record Formats in Messages 💅
So, as Sections 3.2 and 3.3 explain, Query, Response, Update, and Acknowledge Messages can have zero or more repeating Record structures, depending on the situation. This table is the cheat sheet 📋. The "Err" column abbreviations mean what's in the legend below. "IA APPsub-TLV value" means the value part of the IA APPsub-TLV specified in [RFC7961] 🧚.
MBZ = MUST be zero
Z = zero
NZ = non-zero
NZM = non-zero message-level error
NZR = non-zero record-level error
Message Err Section Record Structure Response Data
----------- --- ------- ---------------- -------------------
Query MBZ 3.2.1 QUERY Record -
Response Z 3.2.2.1 RESPONSE Record IA APPsub-TLV value
Response NZM 3.2.2.1 null -
Response NZR 3.2.2.1 RESPONSE Record Records with error
Update MBZ 3.3.1 RESPONSE Record IA APPsub-TLV value
Acknowledge Z 3.3.2 null -
Acknowledge NZM 3.3.2 null -
Acknowledge NZR 3.3.2 RESPONSE Record Records with errorSee Section 3.6 for more on errors 🙈.
3.5. End Stations and Pull Directories 🌸
A Pull Directory can be hosted on an end station, as Section 3.5.1 describes 🏠.
An end station can also use a Pull Directory, as Section 3.5.2 describes. This would be super useful for an end station doing directory-assisted encapsulation [DirAsstEncap], or one that's a "Smart Endnode" [SmartEN] 🧠✨.
The native Pull Directory messages for these cases are in Section 3.5.3. The edge RBridge(s) and the end station(s) involved need to find each other and swap some control info. That happens through the TRILL End System to Intermediate System (ES-IS) mechanism in Section 5 🤝.
3.5.1. Pull Directory Hosted on an End Station 🖥️
Optionally, a Pull Directory actually hosted on an end station MAY be supported. In that setup, one or more TRILL switches act as indirect Pull Directory servers 🦋. They run a Pull Directory server that the other TRILL switches in the campus can see, plus a Pull Directory client that fetches directory info from one or more end-station Pull Directory servers. Some of what the server hands out might have been fetched from an end station the co-located client is directly connected to. ("Direct connection" means a connection with no intermediate TRILL switches in the way.) 💖
End stations that host a Pull Directory server MUST support TRILL ES-IS (see Section 5). They also have to advertise the Data Labels they're serving, in one or more Interested VLANs sub-TLVs or Interested Labels sub-TLVs, by setting the PUL flag (see Section 7.3) 📢.
* * * * * * *
+---------------+ * *
| End Station 1 | +---------------+ *
| Pull Directory+--------------+ RB1, Pull | *
| Server | | Directory| *
+---------------+ +-------+ Client|Server | +----+
| +---------------+ |RB99|
+---------------+ | * +----+
| End Station 2 | +--+---+ +---------------+ *
| Pull Directory+---+Bridge+---+ RB2, Pull | *
| Server | +--+---+ | Directory| *
+---------------+ | | Client|Server | *
| +---------------+ *
| * TRILL *
. * Campus *
. * *
. * * * * * * *
Figure 2: End-Station Pull Directory ExampleFigure 2 shows RB1 and RB2 advertising themselves to the rest of the TRILL campus, like RB99, as Pull Directory servers 🎀. They get at least some of their info by sending Pull Directory queries to End Stations 1 and/or 2. This is just one example, though, and there are lots of variations 🌈. The "Bridge" box could be a complicated bridged LAN, or a bridgeless LAN using a hub or repeater. End stations can also connect over point-to-point links (like End Station 1 does), including multi-ported end stations hooked up point-to-point to several RBridges 🔌. Figure 2 has two end stations and two RBridges, but there could be one RBridge or more than two with indirect Pull Directory servers, and one end station or more than two with Pull Directory servers on them. Each indirect-server TRILL switch can be configured differently, choosing which Data Labels it serves from the union of what the end-station servers support. It can also pick which of those end-station servers to use for each Data Label it's set up to provide 💅.
When an indirect Pull Directory server gets Query Messages from other TRILL switches, it either answers from what it has cached or sends Pull Directory requests to end-station Pull Directory servers it has a TRILL ES-IS adjacency with 🔍. Any Response an indirect Pull Directory server sends MUST NOT have a validity time longer than the validity period of the data it's based on ⏰. When an indirect Pull Directory server gets Update Messages, it updates its cache and MUST originate Update Messages to any clients that might have mirrors of the info it just changed 🪞.
An indirect Pull Directory server throws away info it cached from queries to an end-station server if it loses adjacency with that server (Section 3.7) 💔. So if it thinks that info might be cached at RBridge clients, and it has no other source for it, it MUST send those clients Update Messages withdrawing the info. That's why indirect servers may want to query multiple sources, if they're available, and cache multiple copies of what comes back 🧦. Then if one end-station source disappears or withdraws the info, but the indirect server still has it from another source, it doesn't need to send any Update Messages 🙌.
3.5.2. Use of Pull Directory by End Stations 💖
Some special end stations, like the ones in [DirAsstEncap] and [SmartEN], may need to access directory info. Here's how edge RBridges provide that optional service 🎀.
When an edge RBridge gives Pull Directory support to end stations, the messages are the ones in Section 3.5.3 below. The edge RBridge MUST support TRILL ES-IS (Section 5). It advertises which Data Labels it offers this service for by setting the Pull Directory flag (PUL) to 1 in its Interested VLANs sub-TLV or Interested Labels sub-TLV (see Section 7.3) for that Data Label, through TRILL ES-IS 📣.
3.5.3. Native Pull Directory Messages 🧚♀️
The Pull Directory messages between TRILL switches and end stations are native RBridge Channel messages [RFC7178] 📨. They use the same Channel Protocol number as the inter-RBridge Pull Directory RBridge Channel messages. The Outer.VLAN ID is the TRILL ES-IS Designated VLAN (see Section 5) on the link to the end station. Native RBridge Channel messages don't have a TRILL Header or an inner Data Label, so that info gets folded into the Pull Directory message header, as explained below 🌸.
The protocol-dependent data part of a native RBridge Channel message is the same as for inter-RBridge Channel messages. The one difference is that the 8-byte header from Section 3.1 gets expanded to 12 or 16 bytes, like this 💜:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Label ... (4 or 8 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| Type Specific Payload - variable length
+-+-+- ...All the fields except the Data Label field are defined in Section 3.1 🦋. The Data Label that normally sits right after the Inner.MacSA of an RBridge Channel Pull Directory message now lives in the Data Label field of the Pull Directory message header, in the native RBridge Channel message version 🌈. It shows up in a native Query Message (to be reflected in a Response Message), or in a native Update (to be reflected in an Acknowledge Message) ✨. And since the right VLAN or FGL [RFC7172] Ethertype is included, you can work out the length of the Data Label from the first 2 bytes 🔥.
3.6. Pull Directory Message Errors 🚨
okay bestie, if the Err field is non-zero in the header of a Pull Directory Response Message or Acknowledge Message, that means this is an error message 🙅♀️
If the error applies to the whole Query Message or Update Message (or its header), which you can tell from the range the Err value falls in, then the QUERY Records probably weren't even looked at by the Pull Directory server. So they wouldn't add any extra info to the Response or Acknowledge Message anyway 🙄. That's why the Records section of the response to a Query Message or Update Message gets left out, and the Count field is set to 0 in the Response or Acknowledge Message ✨.
Now for errors at the QUERY Record level in a Query Message. These MUST be reported in a Response Message that is separate from the results of any successful, non-erroneous QUERY Records 💅. If multiple QUERY Records have different errors, they MUST be reported in separate Response Messages. If multiple QUERY Records have the same error, that error response MAY be reported in one Response Message or in several. In an error Response Message, the QUERY Record or Records being responded to show up again, expanded by the Lifetime for which the server thinks the error might persist (usually 2**16 - 1, which indicates "indefinitely") and with their Index inserted, as the RESPONSE Record or Records 🎀.
Same energy for RESPONSE Record level errors in an Update Message. These MUST be reported in an Acknowledge Message that is separate from the acknowledgment of any non-erroneous RESPONSE Records. If multiple RESPONSE Records in an Update have different errors, they MUST be reported in separate Acknowledge Messages. If multiple RESPONSE Records in an Update Message have the same error, that error response MAY be reported in one Acknowledge Message or in several. In an error Acknowledge Message, the RESPONSE Record or Records being responded to appear again, expanded by the time for which the server thinks the error might persist and with their Index inserted, as a RESPONSE Record or Records 🦋.
Err values 1 through 126 are for encoding errors at the Request Message or Update Message level. Err values 128 through 254 are for encoding errors at the QUERY Record or RESPONSE Record level. The SubErr field gives more detail on errors, and what its value means depends on the value of the Err field 🧚.
3.6.1. Error Codes 🍓
The table below lists the error code values for the Err field, what they mean, and whether they apply at the message level or the record level.
Err Level Meaning
------- ------- -----------------------------------------------
0 - No Error
1 Message Unknown or reserved Query Message field value
2 Message Request Message/data too short
3 Message Unknown or reserved Update Message field value
4 Message Update Message/data too short
5-126 Message Unassigned
127 - Reserved
128 Record Unknown or reserved QUERY Record field value
129 Record QUERY Record truncated
130 Record Address not found
131 Record Unknown or reserved RESPONSE Record field value
132 Record RESPONSE Record truncated
133-254 Record Unassigned
255 - ReservedHeads up: some error codes are for overall message-level errors, while others are for errors in the repeating records that show up in messages 👀.
3.6.2. Sub-errors under Error Codes 1 and 3 🌸
The following sub-errors are specified under error codes 1 and 3:
SubErr Field with Error
------ -------------------------------------------
0 Unspecified
1 Version not understood (see Section 3.1.1)
2 Unknown Type field value
3 Specified Data Label not being served
4-254 Unassigned
255 Reserved3.6.3. Sub-errors under Error Codes 128 and 131 💜
The following sub-errors are specified under error codes 128 and 131:
SubErr Field with Error
------ ----------------------------------------------------
0 Unspecified
1 Unknown AFN field value
2 Unknown or Reserved QTYPE field value
3 Invalid or inconsistent SIZE field value
4 Invalid frame for QTYPE 2 (other than SEND)
5 SEND frame sent as QTYPE 2
6 Invalid frame for QTYPE 5 (such as multicast MacDA)
7-254 Unassigned
255 Reserved3.7. Additional Pull Details 🔥
A Pull Directory client MUST be able to detect, by tracking link-state changes, when a Pull Directory server is no longer accessible. That means data reachable [RFC7780] for the inter-RBridge case, or TRILL ES-IS (Section 5) adjacent for the end-station-to-RBridge case. When that happens, the client MUST promptly discard all pull responses it is retaining from that server, because it can no longer receive cache consistency Update Messages from the server 😭.
A secondary Pull Directory server is one that gets its data from a primary directory server. Check out the discussion in Section 2.6 for how directory information moves from the primary server to the secondary server 🫶.
3.8. The "No Data" Flag 🙈
In the TRILL base protocol [RFC6325] as extended for FGL [RFC7172], just having any Interested VLANs sub-TLVs or Interested Labels sub-TLVs in a TRILL switch's LSP means it's connected to end stations in the VLAN(s) or FGL(s) listed. That also means it needs to receive multi-destination traffic in those Data Labels. With Pull Directories, though, saying you're a directory server means using these sub-TLVs to indicate the Data Label(s) you're serving 🧚♀️.
If a directory server doesn't want to receive multi-destination TRILL Data packets for the Data Labels it lists in one of the Interested VLANs or Interested Labels (FGLs) sub-TLVs (see Section 1.2), it sets the No Data (NOD) bit to 1 (see Section 7.3). This means data on a distribution tree may be pruned so it doesn't reach the "No Data" TRILL switch, as long as there are no TRILL switches interested in the Data Label beyond the No Data TRILL switch on that distribution tree. The NOD bit is backward compatible, since TRILL switches that don't know about it will simply not prune when they could. That's safe, although it may cause increased link utilization because some TRILL switches send multi-destination traffic where it isn't needed 🌈.
Push Directories advertise themselves inside ESADI. That normally requires the ability to send and receive multi-destination TRILL Data packets, but it can be implemented with serial unicast 💖.
An example of a TRILL switch acting as a directory that might not want multi-destination traffic in some Data Labels is one that doesn't offer end-station service for any of the Data Labels it's serving as a directory for, and is:
- a Pull Directory and/or
- a Push Directory for one or more Data Labels, where all of the ESADI traffic for those Data Labels will be handled by unicast ESADI [RFC7357].
A Push Directory MUST NOT set the NOD bit for a Data Label if it needs to communicate via multi-destination ESADI or RBridge Channel PDUs in that Data Label. Those PDUs look like TRILL Data packets to transit TRILL switches, so they're likely to be incorrectly pruned if the NOD bit was set 💀.
3.9. Pull Directory Service Configuration ✨
The following per-RBridge scalar configuration parameters are available for controlling Pull Directory service behavior. There's also a configurable mapping, per Data Label, from the priority of a native frame being ingressed to the priority of any Pull Directory query it causes. The default mapping depends on the client strategy, as described in Section 4 👑.
Name Default Section Note Below
------------------ ---------------- ------- ----------
DirQueryTimeout 100 milliseconds 3.2.1 1
DirQueryRetries 3 3.2.1 1
DirGenQPriority 5 3.2.1 2
DirRespMaxPriority 6 3.2.2.1 3
DirUpdateDelay 50 milliseconds 3.3
DirUpdatePriority 5 3.3.1
DirUpdateTimeout 100 milliseconds 3.3.3
DirUpdateRetries 3 3.3.3
DirAckMaxPriority 5 3.3.2 4Note 1: this is the Pull Directory Query client timeout while waiting for a response, plus the maximum number of retries 🙏.
Note 2: this is the priority for client-generated requests, like a query to refresh cached information 🔄.
Note 3: Pull Directory Response Messages SHOULD NOT be sent with priority 7, because that priority SHOULD be reserved for messages critical to network connectivity 🚫.
Note 4: Pull Directory Acknowledge Messages SHOULD NOT be sent with priority 7, because that priority SHOULD be reserved for messages critical to network connectivity 🚫.
4. Directory Use Strategies and Push-Pull Hybrids ✨
okay so bestie, some edge nodes have a ton of Data Labels turned on, and keeping track of the MAC and Data Label <-> Edge RBridge mapping for hosts under all of them can get messy 😭 data-center gateway nodes are the worst offenders, since they might need to talk to basically every Data Label 💀
for those edge TRILL switch nodes, a hybrid model should be considered 🦋 the Push Model covers some Data Labels or addresses inside a Data Label, and the Pull Model covers the rest. the network operator picks, through configuration, which Data Labels' mapping entries get pushed down from directories and which ones get pulled 🎀
for example, imagine a data center where hosts in VLANs 1 through 100 are always chatting with external peers 💅 those 100 VLANs should probably get pushed down to the data-center gateway routers. hosts in other Data Labels that only reach out to external peers now and then for management stuff can have their mapping entries pulled from the directory when they're needed 🫶
it's giving the same energy within a single Data Label too 👑 some addresses, like gateways, files, DNS, or database server hosts, get referenced by almost everyone, but the other hosts (maybe compute engines) are only referenced by a few hosts in that Data Label. so the address info for the popular hosts could be pushed as an incomplete directory, while the rest get pulled when needed ✨
the mechanisms in this document for Push and Pull Directory services make it easy to mix and match 🌈 Push for some Data Labels or addresses and Pull for others. even different TRILL switches can be set up so some use Push Directory services and some use Pull Directory services for the same Data Label, as long as both are available for that Data Label. and there can also be Data Labels where directory services aren't used at all 🍓
there's a whole buffet of strategies a TRILL switch can use for directory assistance 🧚 here are a few suggestions:
- even if a TRILL switch normally runs on info from a complete Push Directory server, there's a stretch of time right after it first comes up before its info is complete 😭 or the only Push Directories that can push to it might be incomplete, or just starting up and not yet pushed the whole directory. so it is RECOMMENDED that all TRILL switches have a plan for when they don't have complete directory information 💖 examples are sending a Pull Directory query or falling back to the behavior described in [RFC6325].
- if a TRILL switch gets a native frame X that means it has to go looking for directory info, it has to decide what to do when it doesn't already have what it needs 🤔 specifically, it could (1) immediately flood the TRILL Data packet that comes from ingressing X while it's seeking the directory info in parallel, (2) flood that TRILL Data packet after a delay, if it fails to get the directory info, or (3) discard X if it fails to get the info. the choice might depend on the priority of frame X, since higher priority usually means more urgent, and a bigger risk of harm from delaying it 🔥 if a Pull Directory request is sent, it is RECOMMENDED that its priority be derived from the priority of frame X according to the table below 💅 however, it SHOULD be possible, on a per-TRILL-switch basis, to configure the second two columns of this table ⭐
Ingressed If Flooded If Flooded
Priority Immediately After Delay
-------- ----------- -----------
7 5 6
6 5 6
5 4 5
4 3 4
3 2 3
2 0 2
0 1 0
1 1 1Note: the wonky-looking order of numbers near the bottom of the columns is because priority 1 is lower than priority zero 🙈 so the values in the first column are in priority order. it'll make way more sense if you think of "0" as being "1.5" 🧠
priority 7 is normally only for urgent messages that are critical to adjacency, so it SHOULD NOT be the default for directory traffic 🚫 unsolicited updates go out with a priority that's configured per Data Label, and it defaults to priority 5 🎀
5. TRILL ES-IS
okay now we're talking about TRILL ES-IS (End System to Intermediate System) 🦋 it's a variation of TRILL IS-IS [RFC7176] [RFC7177] [RFC7780], built to run on a TRILL link between one or more TRILL switches and the end stations on that link. it's analogous to the ISO/IEC ES-IS standard [ISO9542], but it's done in a seriously different way as a variation of TRILL IS-IS, as this section lays out 💖 supporting TRILL ES-IS is generally optional for both the TRILL switches and the end stations on a link, though it might be required to support certain features. as of this writing, the only features that require TRILL ES-IS are the ones listed in this section 👑
TRILL ES-IS:
- is useful for supporting Pull Directory hosting on, or use from, end stations (see Section 3.5),
- is useful for supporting specialized end stations [DirAsstEncap] [SmartEN], and
- may have additional future uses.
the perks of TRILL ES-IS over just making an "end station" a TRILL switch are that the end station doesn't have to keep a copy of the core link-state database (LSPs), doesn't have to do routing calculations, and doesn't need the ability to forward traffic 😌✨
except as provided in this section, TRILL ES-IS PDUs and TLVs are the same as TRILL IS-IS PDUs and TLVs 🫶
5.1. PDUs and System IDs
all TRILL ES-IS PDUs (except some MTU-probe and MTU-ack PDUs, which may be unicast) are multicast using the TRILL-ES-IS multicast MAC address (see Section 7.6) 📣 using a different multicast address means TRILL ES-IS and TRILL IS-IS PDUs won't get mixed up with each other 🙅♀️
end stations don't have IS-IS System IDs, so TRILL ES-IS uses port MAC addresses in their place 🎀 that's super convenient, because MAC addresses are 48-bit and almost all IS-IS implementations use 48-bit System IDs 💅 logically, TRILL IS-IS runs between the TRILL switches in a TRILL campus, identified by System ID, while TRILL ES-IS runs between Ethernet ports on an Ethernet link (which might be a bridged LAN), identified by MAC address [RFC6325] 🧚
since System IDs of TRILL switches in a campus are required to be unique, the MAC addresses of TRILL ES-IS ports on a link MUST be unique 🔒
5.2. Adjacency, DRB Election, Port IDs, Hellos, and TLVs
TRILL ES-IS adjacency formation and Designated RBridge (DRB) election work between the ports on the link, as specified in [RFC7177] for a broadcast link 🤝 the DRB specifies an ES-IS Designated VLAN for the link 🌸 adjacency determination, DRB election, and Designated VLANs described in this section are separate from TRILL IS-IS adjacency, DRB election, and Designated VLANs, so don't mix them up 🙈
although the "Report state" [RFC7177] exists for TRILL ES-IS adjacencies, those adjacencies only get reported in TRILL ES-IS LSPs, never in any TRILL IS-IS LSPs 📝
End stations supporting TRILL ES-IS MUST assign a unique Port ID to each of their TRILL ES-IS ports 🆔 the Port ID shows up in the TRILL ES-IS Hellos they send 💜
TRILL ES-IS has nothing to do with Appointed Forwarders 🙅♀️ the Appointed Forwarders sub-TLV and the VLANs Appointed sub-TLV [RFC7176] aren't used and SHOULD NOT be sent in TRILL ES-IS. if one of them is received in TRILL ES-IS, it's ignored 😤 (the Appointed Forwarders on a link are determined as specified in [RFC8139], using TRILL IS-IS 💅)
some of the ports sending TRILL ES-IS PDUs are on end stations, so they're not on routers (TRILL switches). even so, they may still use the Router CAPABILITY (#242) [RFC7981] and MT-Capability (#144) [RFC6329] IS-IS TLVs to indicate capabilities, as specified in [RFC7176] ✨
TRILL ES-IS Hellos are like TRILL IS-IS Hellos, but with a few twists 🌈 in the Special VLANs and Flags sub-TLV [RFC7176], TRILL switches advertise a nickname they own, but for end stations that field MUST be sent as zero and ignored on receipt 🍓 also, in the Special VLANs and Flags sub-TLV (Section 2.2.1 of [RFC7176]) in a TRILL ES-IS Hello, the AF and TR flag bits MUST be sent as zero, the AC flag bit MUST be sent as one (1), and all three are ignored on receipt 🩷
5.3. Link State
the only link-state transmission and synchronization in TRILL ES-IS happens for E-L1CS (Extended Level 1 Circuit Scope) PDUs [RFC7356] 📡 specifically, the end-station Ethernet ports that support TRILL ES-IS don't support the core TRILL IS-IS LSPs, and they don't support E-L1FS (Extended Level 1 Flooding Scope) LSPs [RFC7780] (or the CSNPs or PSNPs (Partial Sequence Number PDUs) [RFC7356] that go with either of them) 🙅♀️ TLVs and sub-TLVs that would otherwise go in TRILL IS-IS LSPs or E-L1FS LSPs get sent in E-L1CS LSPs instead 🫶
6. Security Considerations 🔐
for general TRILL security considerations, see [RFC6325] 💖
6.1. Directory Information Security
okay this part is serious, bestie 😭🚨 incorrect directory information can cause a bunch of security threats, including the ones listed below, so directory servers need to really take care to implement and enforce access control policies that aren't overly permissive 🛡️
- incorrect directory mappings can cause data to get delivered to the wrong end stations (or the wrong set of end stations, for multi-destination packets), which violates security policy 💀
- missing, incorrect, or inaccessible directory data can cause denial of service, through sending data packets to black holes or discarding data on ingress because the info says their destinations aren't reachable or their source addresses are forged 🕳️
for these reasons, whatever server or end station the directory information lives on needs to be protected from unauthorized modification 🔒 parties who are authorized to modify directory data can still violate availability and integrity policies if they misuse that access 😵
6.2. Directory Confidentiality and Privacy
in implementations of the base TRILL protocol [RFC6325] [RFC7780], RBridges deal almost exclusively with MAC addresses 💅 using directories to map to and from IP addresses means RBridges deal more actively with IP addresses too. but RBridges would be exposed to plain-text ARP/ND/SEND/IP traffic anyway, so they can see all this addressing metadata. which means this more-explicit handling of IP addresses has little effect on the privacy of end-station traffic 🙄✨
parties authorized to read directory data can violate privacy policies for that data 🫣
6.3. Directory Message Security Considerations ✨
Okay bestie, security time 🔒 Push Directory data gets shipped around inside ESADI-LSPs [RFC7357], and ESADI is built right on top of IS-IS 🧚 That means the data can be authenticated with IS-IS PDU security, which is super widely implemented and deployed. This mechanism gives you authentication and integrity protection. Check out [RFC5304], [RFC5310], and the Security Considerations section of [RFC7357] 💅
Pull Directory queries and responses travel as RBridge-to-RBridge or native RBridge Channel messages [RFC7178] 🦋 Those messages can be locked down with the mechanisms in [RFC7978]. These can give you authentication and confidentiality protection. Real talk though: at the time of writing, these security mechanisms are believed to be less widely implemented than IS-IS security 💀
7. IANA Considerations 📋
7.1. ESADI-Parameter Data Extensions 🎀
IANA made a new subregistry in the "TRILL Parameters" registry, and it looks like this 💖
Subregistry: ESADI-Parameter APPsub-TLV Flag Bits
Registration Procedure(s): Standards Action
References: [RFC7357] [RFC8171]
Bit Mnemonic Description Reference
--- -------- ---------------------------- ---------------
0 UN Supports Unicast ESADI ESADI [RFC7357]
1-2 PDSS Push Directory Server Status [RFC8171]
3-7 - UnassignedOn top of that, the ESADI-Parameter APPsub-TLV gets optionally extended, as provided in its original specification in ESADI [RFC7357], by 1 byte, as shown below 🌈 So [RFC8171] got added as a second reference to the ESADI-Parameter APPsub-TLV in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry. Main character energy ⭐
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|R| Priority | (1 byte)
+-+-+-+-+-+-+-+-+
| CSNP Time | (1 byte)
+-+-+-+-+-+-+-+-+
| Flags | (1 byte)
+---------------+
|PushDirPriority| (optional, 1 byte)
+---------------+
| Reserved for (variable)
| expansion
+-+-+-+-...All the fields mean what they meant in ESADI [RFC7357], except the new PushDirPriority, which is the priority of the advertising ESADI instance to be a Push Directory, as described in Section 2.3 🧚 If the PushDirPriority field isn't present (Length = 3), it gets treated as if it were 0x3F. And 0x3F is also the value a TRILL switch uses and places here when its priority to be a Push Directory hasn't been configured 🍓
7.2. RBridge Channel Protocol Numbers 🦋
IANA assigned a new RBridge Channel Protocol number, 0x005, from the range assignable by Standards Action [RFC5226], and updated the subregistry in the "TRILL Parameters" registry to match ✨ The description is "Pull Directory Services" and the reference is [RFC8171].
7.3. The Pull Directory (PUL) and No Data (NOD) Bits 🌸
IANA took a previously reserved bit in the Interested VLANs field of the Interested VLANs sub-TLV, and in the Interested Labels field of the Interested Labels sub-TLV [RFC7176], and used it to flag a Pull Directory server (PUL). This bit got added, with this document as a reference, to the "Interested VLANs Flag Bits" and "Interested Labels Flag Bits" subregistries created by [RFC7357], as shown below 💜
IANA also took another previously reserved bit in those same fields and sub-TLVs and used it to flag No Data (NOD) (see Section 3.8). That bit got added to the same two subregistries, with this document as a reference, as shown below 🫶
The bits are as follows:
Registry: Interested VLANs Flag Bits
Bit Mnemonic Description Reference
--- -------- -------------- ---------------
18 PUL Pull Directory [RFC8171]
19 NOD No Data [RFC8171]
Registry: Interested Labels Flag Bits
Bit Mnemonic Description Reference
--- -------- -------------- ---------------
6 PUL Pull Directory [RFC8171]
7 NOD No Data [RFC8171]7.4. TRILL Pull Directory QTYPEs 🔥
IANA created a brand new registry, and it's giving organized 📋
Name: TRILL Pull Directory Query Types (QTYPEs)
Registration Procedure(s): IETF Review
Reference: [RFC8171]
Initial contents as in Section 3.2.1.7.5. Pull Directory Error Code Registries 💀
IANA created one new registry and two new indented subregistries, like this 👑
Registry
Name: TRILL Pull Directory Errors
Registration Procedure(s): IETF Review
Reference: [RFC8171]
Initial contents as in Section 3.6.1.
Subregistry
Name: Sub-codes for TRILL Pull Directory Errors 1 and 3
Registration Procedure(s): Expert Review
Reference: [RFC8171]
Initial contents as in Section 3.6.2.
Subregistry
Name: Sub-codes for TRILL Pull Directory Errors 128 and 131
Registration Procedure(s): Expert Review
Reference: [RFC8171]
Initial contents as in Section 3.6.3.7.6. TRILL-ES-IS MAC Address 🧚
IANA assigned a TRILL multicast MAC address, 01-80-C2-00-00-47, from the "TRILL Multicast Addresses" registry. The description is "TRILL-ES-IS" and the reference is [RFC8171] 💖
8. References 📚
8.1. Normative References 🌈
- [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982,
<http://www.rfc-editor.org/info/rfc826>. - [RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, DOI 10.17487/RFC0903, June 1984,
<http://www.rfc-editor.org/info/rfc903>. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. - [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>. - [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. - [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008,
<http://www.rfc-editor.org/info/rfc5304>. - [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009,
<http://www.rfc-editor.org/info/rfc5310>. - [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011,
<http://www.rfc-editor.org/info/rfc6165>. - [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
<http://www.rfc-editor.org/info/rfc6325>. - [RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, DOI 10.17487/RFC6329, April 2012,
<http://www.rfc-editor.org/info/rfc6329>. - [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013,
<http://www.rfc-editor.org/info/rfc7042>. - [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014,
<http://www.rfc-editor.org/info/rfc7172>. - [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014,
<http://www.rfc-editor.org/info/rfc7176>. - [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014,
<http://www.rfc-editor.org/info/rfc7177>. - [RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014,
<http://www.rfc-editor.org/info/rfc7178>. - [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014,
<http://www.rfc-editor.org/info/rfc7356>. - [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014,
<http://www.rfc-editor.org/info/rfc7357>. - [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>. - [RFC7961] Eastlake 3rd, D. and L. Yizhou, "Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961, August 2016,
<http://www.rfc-editor.org/info/rfc7961>. - [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016,
<http://www.rfc-editor.org/info/rfc7981>. - [RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders", RFC 8139, DOI 10.17487/RFC7961, June 2017,
<http://www.rfc-editor.org/info/rfc8139>. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<http://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 💅
okay bestie, this is the background reading list 📚 these aren't the must-reads, they're the ones that give you the backstory on how the TRILL pieces fit together 🦋
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. 🎀 - [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013,
<http://www.rfc-editor.org/info/rfc7067>. 🌸 - [RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016,
<http://www.rfc-editor.org/info/rfc7978>. ✨ - [ARPND] Li, Y., Eastlake 3rd, D., Dunbar, L., Perlman, R., and M. Umair, "TRILL: ARP/ND Optimization", Work in Progress, draft-ietf-trill-arp-optimization-08, April 2017. 🧚
- [DirAsstEncap] Dunbar, L., Eastlake 3rd, D., and R. Perlman, "Directory Assisted TRILL Encapsulation", Work in Progress, draft-ietf-trill-directory-assisted-encap-05, May 2017. 💜
- [ISO9542] ISO 9542:1988, "Information processing systems -- Telecommunications and information exchange between systems -- End system to Intermediate system routeing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service (ISO 8473)", August 1988. 🍓
- [SmartEN] Perlman, R., Hu, F., Eastlake 3rd, D., Krupakaran, K., and T. Liao, "TRILL Smart Endnodes", Work in Progress, draft-ietf-trill-smart-endnodes-05, February 2017. 🌈
- [X.233] International Telecommunication Union, ITU-T Recommendation X.233: "Information technology - Protocol for providing the connectionless-mode network service: Protocol specification", August 1997,
<https://www.itu.int/rec/T-REC-X.233/en>. 🔥
Acknowledgments 🫶
The contributions of the following persons are gratefully acknowledged, and we love them for it 💖
Amanda Baber, Matthew Bocci, Alissa Cooper, Stephen Farrell, Daniel Franke, Igor Gashinsky, Joel Halpern, Susan Hares, Alexey Melnikov, Gayle Noble, and Tianran Zhou. 👑
Authors' Addresses 🧚
Here are the people who wrote this whole thing, with their contact details 📬✨
Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.comLinda Dunbar
Huawei Technologies
5430 Legacy Drive, Suite #175
Plano, TX 75024
United States of America
Phone: +1-469-277-5840
Email: ldunbar@huawei.comRadia Perlman
EMC
2010 256th Avenue NE, #200
Bellevue, WA 98007
United States of America
Email: Radia@alum.mit.eduYizhou Li
Huawei Technologies
101 Software Avenue
Nanjing 210012
China
Phone: +86-25-56622310
Email: liyizhou@huawei.comAnd that's the whole RFC, bestie! 🌈💅 Thanks for hanging with me through all 13 parts 🥹🎀
📦 where this page comes from
- ietf: rfc8171 2017-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms