RFC 8383
Transparent Interconnection of Lots of Links (TRILL): Address Flush Message
RFC 8383: Transparent Interconnection of Lots of Links (TRILL): Address Flush Message 🎀
okay bestie, this one is from the IETF crew 🌸 authored by W. Hao, D. Eastlake, 3rd, Y. Li (Huawei), and M. Umair (Cisco). it's a Standards Track doc, ISSN 2070-1721, dated May 2018 🦋
Abstract
ok so TRILL (Transparent Interconnection of Lots of Links) learns end station addresses by watching the data plane 👀 by default. local MAC addresses and the edge switch port they hang off get learned from local data frames, and remote MAC addresses plus their edge switch port get learned when a switch decapsulates remotely sourced TRILL Data packets 💅
this doc specifies a message that lets a TRILL switch explicitly ask other TRILL switches to flush certain MAC reachability that was learned from decapsulating TRILL Data packets. it's a supplement to the TRILL automatic address forgetting (see Section 4.8.3 of RFC 6325) and can help things converge way faster when the topology or config changes 🚀
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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more info on Internet Standards is in Section 2 of RFC 7841 ✨
for the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc8383 🍓
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. please actually read these, bestie, because they explain your rights and restrictions for this document 🙈 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 3
2. Address Flush Message Details . . . . . . . . . . . . . . . . 5
2.1. VLAN Block Only Case . . . . . . . . . . . . . . . . . . 6
2.2. Extensible Case . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Blocks of VLANs . . . . . . . . . . . . . . . . . . . 12
2.2.2. Bit Map of VLANs . . . . . . . . . . . . . . . . . . 12
2.2.3. Blocks of FGLs . . . . . . . . . . . . . . . . . . . 13
2.2.4. list of FGLs . . . . . . . . . . . . . . . . . . . . 13
2.2.5. Big Map of FGLs . . . . . . . . . . . . . . . . . . . 14
2.2.6. All Data Labels . . . . . . . . . . . . . . . . . . . 14
2.2.7. MAC Address List . . . . . . . . . . . . . . . . . . 15
2.2.8. MAC Address Blocks . . . . . . . . . . . . . . . . . 16
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
3.1. Address Flush RBridge Channel Protocol Number . . . . . . 17
3.2. TRILL Address Flush TLV Types . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Normative References . . . . . . . . . . . . . . . . . . 18
5.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 201. Introduction ✨
ok so by default, edge TRILL (Transparent Interconnection of Lots of Links) switches [RFC6325] [RFC7780], also called edge Routing Bridges (RBridges), learn end station MAC address reachability by observing the data plane 🧚 when they get a native frame from an end station, they learn the local MAC attachment of the source end station. and when they egress (decapsulate) a remotely originated TRILL Data packet, they learn the remote MAC address and the remote attachment TRILL switch. all of this learning is scoped by a data label, which is either a VLAN or a Fine-Grained Label (FGL) [RFC7172] 💖
TRILL has ways to time out this learning and clear it when the network connectivity or configuration changes 🕰️ but sometimes it would be super helpful for a TRILL switch to explicitly flush (purge) certain learned end station reachability info in remote RBridges, so convergence is faster 🏃♀️💨 Section 6.2 of [RFC4762] is an example of a mechanism like that.
another example is based on Appendix A.3 of [RFC6325] ("Wiring Closet Topology") 🧵 here you've got a bridged LAN hooked up to a TRILL network through multiple RBridge ports. for optimal paths, Appendix A.3.3 suggests setting the RBridge ports up to act like one Spanning Tree Protocol (STP) tree root in the bridged LAN. the Address Flush message in this document could also get triggered here when one edge RBridge receives Topology Change (TC) information (for example, TC in STP or Topology Change Notification (TCN) in Multiple Spanning Tree Protocol (MSTP)). that way it can quickly flush the MAC addresses for specific VLANs learned at the other edge RBridge ports 🌸
a TRILL switch can totally flush any locally learned addresses it wants, no permission slip needed 💅 what this document actually specifies is an RBridge Channel Support protocol [RFC7178] message that requests flushing address info for specific VLANs or FGLs ([RFC7172]) learned from decapsulating TRILL Data packets 🦋
1.1. Terminology and Abbreviations 📚
here's the key-word squad 👑 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. lowercase versions are just regular words, no drama 🙈
this document uses the terms and abbreviations defined in [RFC6325] and [RFC7178], plus these:
- Data Label: A VLAN or FGL
- Edge TRILL Switch: A TRILL switch attached to one or more links that provide end station service
- FCS: Frame Check Sequence
- FGL: Fine-Grained Label [RFC7172]
- Management VLAN: A VLAN in which all TRILL switches in a campus indicate interest so that multi-destination TRILL Data packets, including RBridge Channel protocol messages [RFC7178], sent with that VLAN as the
Inner.VLANwill be delivered to all TRILL switches in the campus. usually, no end station service is offered in the Management VLAN 🌈 - MAC: Media Access Control
- RBridge: An alternative name for a TRILL switch
- STP: Spanning Tree Protocol
- TC: Topology Change message
- TCN: Topology Change Notification message
- TRILL switch: A device implementing the TRILL protocol [RFC6325] [RFC7780]
2. Address Flush Message Details 🦋
the Address Flush message is an RBridge Channel protocol message [RFC7178] 🎀
here's the general structure of an RBridge Channel packet on a link between TRILL switches, shown in Figure 1. the Protocol field in the RBridge Channel Header tells you what type of RBridge Channel packet it is, and how to interpret the Channel-Protocol-Specific Payload [RFC7178] ✨
+-----------------------------------+
| Link Header |
+-----------------------------------+
| TRILL Header |
+-----------------------------------+
| Inner Ethernet Addresses |
+-----------------------------------+
| Data Label (VLAN or FGL) |
+-----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
| Channel-Protocol-Specific Payload |
+-----------------------------------+
| Link Trailer (FCS if Ethernet) |
+-----------------------------------+
Figure 1: RBridge Channel Protocol Message Structureby default, an Address Flush RBridge Channel protocol message applies to addresses within the Data Label that show up right after the Inner Ethernet Addresses 🧁 Address Flush messages are usually sent as multi-destination packets (TRILL Header M bit equal to one) so they reach every TRILL switch offering end station service in the VLAN or FGL named by that Data Label 📣 both multi-destination and unicast Address Flush messages SHOULD be sent at priority 6, since they're important control messages but still lower priority than the control messages that establish or maintain adjacency 🫶
nevertheless, a few extra things are possible:
- there are provisions for optionally indicating the Data Label(s) to be flushed, for cases where the Address Flush message is sent over a Management VLAN or something similar 🍓
- an Address Flush message can be sent unicast, if you only want to clear addresses at one TRILL switch 🎯
- an Address Flush message can be sent selectively to the RBridges that have at least one access port configured as one of the VLANs or FGLs specified in the Address Flush message payload 👑
implementations should consider logging received Address Flush messages, with appropriate protections against packet storms 💀
2.1. VLAN Block Only Case 🎀
okay bestie, Figure 2 zooms in on the RBridge Channel Header and Channel-Protocol-Specific Payload from Figure 1 for the VLAN-only-based Address Flush message 💅 this version is optimized for flushing MAC addresses based on nickname and blocks of VLANs 🦋 and 0x8946 is the Ethertype IEEE assigned for the RBridge Channel protocol [RFC7178] 🫶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | 0x0 |Channel Protocol= 0x009|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Flush Protocol Specific:
+-+-+-+-+-+-+-+-+
| K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname 1 | Nickname 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname ... | Nickname K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K-VLBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 1 | RESV | End.VLAN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 2 | RESV | End.VLAN 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN ... | RESV | End.VLAN ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN K-VLBs | RESV | End.VLAN K-VLBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: Address Flush Message - VLAN Block Case 🌸
so the fields in Figure 2 related to the Address Flush message work like this 👇
Channel Protocol: the RBridge Channel Protocol value allocated for Address Flush (see Section 3) 🧚
K-nicks: the number of nicknames listed, as an unsigned integer 🔢 if this is zero, the ingress nickname in the TRILL Header [RFC6325] is considered to be the only nickname the message applies to. if it's non-zero, it gives the number of nicknames listed right after K-nicks that the message applies to, and in that non-zero case the flush does not apply to the ingress nickname in the TRILL Header unless it's also listed 👀 the message flushes address learning due to egressing TRILL Data packets that had an ingress nickname the message applies to ✨
Nickname: a listed nickname the Address Flush message is intended to apply to 💖 if an unknown or reserved nickname shows up in the list, it's ignored, but the address flush operation still runs with the other nicknames. if an incorrect nickname is listed so that some address learning gets flushed when it shouldn't have been, the network will still operate correctly 🫶 it'll just be less efficient, because the incorrectly flushed learning gets relearned 🙈
K-VLBs: the number of VLAN blocks present, as an unsigned integer. if this byte is zero, the message is the more general format specified in Section 2.2 💅 if it's non-zero, it gives the number of blocks of VLANs present. so in the VLAN Block address flush case, K-VLBs will be at least one 🦋
RESV: 4 reserved bits. MUST be sent as zero and ignored on receipt 🔒
Start.VLAN, End.VLAN: these 12-bit fields give the beginning and ending VLAN IDs of a block of VLANs. the block includes both the starting and ending values, so a block of size one is indicated by setting End.VLAN equal to Start.VLAN 🌈 if Start.VLAN is 0x000, it's treated as if it was 0x001. if End.VLAN is 0xFFF, it's treated as if it was 0xFFE. if End.VLAN is smaller than Start.VLAN (both considered as unsigned integers), that VLAN block is ignored, but the address flush operation still runs with the other VLAN blocks in the message 💀 VLAN blocks may overlap, in which case the address flush operation applies to a VLAN covered by any one or more of the blocks in the message 👑
this message flushes all addresses in an applicable VLAN learned from egressing TRILL Data packets with an applicable nickname as ingress 😭 and if you want to flush addresses for all VLANs, it's easy: just specify a block covering all valid VLAN IDs (i.e., from 0x001 to 0xFFE) ✨💜
2.2. Extensible Case ✨
Okay bestie, this is the glow-up version of the Address Flush message 💅 It exists so you can flush by FGL, and it has much better ways to encode VLANs and FGLs when a pile of contiguous blocks would be a pain 😩 It can also optionally name the exact MAC addresses to clear. And it's extensible, so it's future-proof and has major main character energy 🦋
The extensible case is signalled by a zero in the byte that Figure 2 labels "K-VLBs". After that byte, the rest of the info is encoded as TLVs 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | 0x0 |Channel Protocol=0x009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Flush Protocol Specific:
+-+-+-+-+-+-+-+-+
| K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname 1 | Nickname 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname ... | Nickname K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 3: Address Flush Message - Extensible Case- Channel Protocol, K-nicks, Nickname: These fields are as specified in Section 2.1.
- TLVs: If the byte immediately before the TLVs field, which is the byte labeled "K-VLBs" in Figure 2, is zero, as shown in Figure 3, the remainder of the message consists of TLVs encoded as shown in Figure 4.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Type, Length, Value- Type: This is the 8-bit TLV type, shown in the table below 🍓 Check out the subsections of Section 2.2 for the details on each assigned type. If the type is reserved or not known by a receiving RBridge, that receiving RBridge ignores the value and skips to the next TLV by use of the Length byte. There's no provision for a list of VLAN ID TLVs, because there are few enough VLAN IDs that an arbitrary subset can be represented as a bit map.
Type Description Reference
------ ------------------ -----------------
0 Reserved [RFC8383]
1 Blocks of VLANs [RFC8383]
2 Bit Map of VLANs [RFC8383]
3 Blocks of FGLs [RFC8383]
4 List of FGLs [RFC8383]
5 Bit Map of FGLs [RFC8383]
6 All Data Labels [RFC8383]
7 MAC Address List [RFC8383]
8 MAC Address Blocks [RFC8383]
9-254 Unassigned
255 Reserved [RFC8383]- Length: This is the 8-bit unsigned integer length in bytes of the remaining information in the TLV after the Length byte. The Length MUST NOT imply that the value extends beyond the end of the RBridge Channel-Protocol-Specific Payload area. If it does, the Address Flush message is corrupt and MUST be ignored 🙅♀️
- Value: Depends on the TLV type 💖
In an extensible Address Flush message, when the TLVs are parsed, those TLVs having unknown types are ignored by the receiving RBridge. There may be multiple instances of TLVs with the same Type in the same Address Flush message, and TLVs are not required to be in any particular order 🌸
- All RBridges implementing the Address Flush RBridge Channel protocol message MUST implement types 1 and 2, the VLAN types, and Type 6, which indicates addresses are to be flushed for all Data Labels.
- RBridges that implement the Address Flush message and implement FGL ingress/egress MUST implement types 3, 4, and 5, the FGL types. (An RBridge that is merely FGL safe [RFC7172], but cannot egress FGL TRILL Data packets, SHOULD ignore the FGL types, as it will not learn any FGL-scoped MAC addresses from the data plane.)
- RBridges that implement the Address Flush message SHOULD implement types 7 and 8 so that specific MAC addresses can be flushed. If they do not, the effect will be to flush all MAC addresses for the indicated Data Labels, which may be inefficient as any MAC addresses not intended to be flushed will have to be relearned 🥺
The parsing of the TLVs by a receiving RBridge results in three pieces of information:
- a flag indicating whether one or more Type 6 TLVs (All Data Labels) were encountered;
- a set of Data Labels accumulated from VLAN and/or FGL specifying TLVs in the message; and,
- if the MAC address TLV types are implemented, a set of MAC addresses accumulated from MAC-address-specifying TLVs in the message.
VLANs/FGLs might be indicated more than once due to overlapping blocks or the like, and a VLAN/FGL is included in the above set of VLANs/FGLs if it occurs in any TLV in the Address Flush message. A MAC address might be indicated more than once due to overlapping blocks or the like, and a particular MAC address is included in the above set of MAC addresses if it occurs in any TLV in the Address Flush message ✨
After the above information has been accumulated by parsing the TLVs, three sets are derived as described below: a set of nicknames, a set of Data Labels, and a set of MAC addresses. The address flush operation at the receiver applies to the cross product of these derived sets. That is, a { Data Label, MAC address, nickname } triple is flushed if and only if the Data Label matches an element in the derived set of Data Labels, the MAC address matches an element in the derived set of MAC address, and the nickname matches an element in the derived set of nicknames. In the case of Data Labels and MAC addresses, a special value of the set, {ALL}, is permitted, which matches all values. 🔥
The sets are derived as follows:
- Data Labels set: If the Type 6 TLV has been encountered, the set is
{ALL}, else, if any Data Labels have been accumulated by processing Data Label TLVs (Types 1, 2, 3, 4, and 5), the set is those accumulated Data Labels, else, the Data Labels set is null and the Address Flush message does nothing. - MAC Addresses set: In the receiver does not implement the MAC address types (Types 7 and 8) or it does implement those types but no MAC addresses are accumulated in parsing the TLVs, then the MAC Address set is
{ALL}, else, the MAC Addresses set is the set of MAC addresses accumulated in processing the TLVs. - Nicknames set: If the K-nicks field in the Address Flush message was zero, then the ingress nickname in the TRILL Header of the message is the sole nickname set member, else, the nicknames set members are the K-nicks nicknames listed in the Address Flush message.
The various formats below are provided for encoding efficiency. A block of values is most efficient when there are a number of consecutive values. A bit map is most efficient if there are scattered values within a limited range. And a list of single values is most efficient if there are widely scattered values 🧚
2.2.1. Blocks of VLANs
If the TLV Type is 1, the value is a list of blocks of VLANs as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 1 | RESV | End.VLAN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 2 | RESV | End.VLAN 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN ... | RESV | End.VLAN ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The meaning of Start.VLAN and End.VLAN is as specified in Section 2.1. Length MUST be a multiple of 4. If Length is not a multiple of 4, the TLV is corrupt and the Address Flush message MUST be discarded 🚫
2.2.2. Bit Map of VLANs
If the TLV Type is 2, the value is a bit map of VLANs as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| RESV | Start.VLAN | Bits...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-The value portion of the TLV begins with two bytes having the 12-bit starting VLAN ID right justified (the top 4 bits are as specified in Section 2.1 RESV). This is followed by bytes with one bit per VLAN ID. The high order bit of the first byte is for VLAN N. The next-to-the-highest order bit is for VLAN N+1. The low order bit of the first byte is for VLAN N+7. The high order bit of the second byte, if there is a second byte, is for VLAN N+8, and so on. If that bit is a one, the Address Flush message applies to that VLAN. If that bit is a zero, then addresses that have been learned in that VLAN are not flushed. Note that Length MUST be at least 2. If Length is 0 or 1, the TLV is corrupt and the Address Flush message MUST be discarded. VLAN IDs do not wrap around. If there are enough bytes so that some bits correspond to VLAN ID 0xFFF or higher, those bits are ignored, but the message is still processed for bits corresponding to valid VLAN IDs 🦋
2.2.3. Blocks of FGLs
If the TLV Type is 3, the value is a list of blocks of FGLs as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End.FGL 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End.FGL 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End.FGL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The TLV value consists of sets of Start.FGL and End.FGL numbers. The Address Flush information applies to the FGLs in that range, inclusive. A single FGL is indicated by setting both Start.FGL and End.FGL to the same value. If End.FGL is less than Start.FGL, considering them as unsigned integers, that block is ignored, but the Address Flush message is still processed for any other blocks present. For this Type, Length MUST be a multiple of 6; if it is not, the TLV is corrupt and the Address Flush message MUST be discarded if the receiving RBridge implements Type 3 💜
2.2.4. list of FGLs ✨
If the TLV Type is 4, the value is a list of FGLs, laid out like this 🎀
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The TLV value is a bunch of FGL numbers, each one 3 bytes long 🧚 The Address Flush message applies to those FGLs. For this Type, Length MUST be a multiple of 3. If it isn't, the TLV is corrupt, and the Address Flush message MUST be discarded if the receiving RBridge implements Type 4 💀
2.2.5. Big Map of FGLs 🗺️
If the TLV Type is 5, the value is a bit map of FGLs, and it looks like this 💜
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bits...
+-+-+-+-+-+-+-+-The TLV value starts with three bytes holding the 24-bit starting FGL value N. After that come bytes with one bit per FGL. The high order bit of the first byte is for FGL N. The next-to-the-highest order bit is for FGL N+1. The low order bit of the first byte is for FGL N+7. The high order bit of the second byte, if there is a second byte, is for FGL N+8, and so on 🦋 If a bit is a one, the Address Flush message applies to that FGL. If a bit is a zero, then addresses learned in that FGL are not flushed. Note that Length MUST be at least 3. If Length is 0, 1, or 2 for a Type 5 TLV, the TLV is corrupt, and the Address Flush message MUST be discarded if Type 5 is implemented. FGLs do not wrap around. If there are enough bytes that some bits line up with an FGL higher than 0xFFFFFF, those bits are ignored, but the message still gets processed for the bits that match valid FGLs. Main character energy for the valid ones 👑
2.2.6. All Data Labels 🌈
If the TLV Type is 6, the value is null, like so 🍓
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This type is for when an RBridge wants to withdraw all addresses for all the Data Labels (all VLANs and FGLs), full reset energy 💅 Length MUST be zero. If Length is any other value, the TLV is corrupt, and the Address Flush message MUST be discarded.
2.2.7. MAC Address List 📋
If the TLV Type is 7, the value is a list of MAC addresses, formatted like this ✨
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 1 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 1 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 2 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 2 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC ... upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC ... lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The TLV value is a list of 48-bit MAC addresses. Length MUST be a multiple of 6. If it isn't, the TLV is corrupt, and the Address Flush message MUST be discarded if the receiving RBridge implements Type 7 🫶
2.2.8. MAC Address Blocks 🧱
If the TLV Type is 8, the value is a list of blocks of MAC addresses, like this 🌸
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 1 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 1 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 1 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 1 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 2 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 2 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 2 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 2 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start ... upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start ... lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end ... upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end ... lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The TLV value is made of sets of Start.MAC and End.MAC numbers. The Address Flush information applies to the 48-bit MAC addresses in each range, inclusive of both ends. To point at a single MAC address, set Start.MAC and End.MAC to the same value 🎯 If End.MAC is less than Start.MAC (treating them as unsigned integers), that block gets ignored, but the Address Flush message is still processed for any other blocks present. For this Type, Length MUST be a multiple of 12. If it isn't, the TLV is corrupt, and the Address Flush message MUST be discarded if the receiving RBridge implements Type 7 😭
3. IANA Considerations 🏳️🌈
3.1. Address Flush RBridge Channel Protocol Number 🔢
IANA has assigned 0x009 as the Address Flush RBridge Channel Protocol number, pulled from the range of RBridge Channel protocols that are allocated by Standards Action [RFC7178] [RFC8126].
The added entry to the "RBridge Channel Protocols" registry at <https://www.iana.org/assignments/trill-parameters/> looks like this 💖
Protocol Description Reference
-------- -------------- ------------------
0x009 Address Flush [RFC8383]3.2. TRILL Address Flush TLV Types 🗂️
IANA has created the "TRILL Address Flush TLV Types" registry at <https://www.iana.org/assignments/trill-parameters/>. It's a subregistry of the "RBridge Channel Protocols" registry. The registry headers are below. The initial entries are the ones in the table in Section 2.2 ✨
Registry: TRILL Address Flush TLV Types
Registration Procedures: IETF Review
Reference: [RFC8383]4. Security Considerations 🔐
The Address Flush RBridge Channel Protocol itself provides no security assurances or features. Real talk, it's not doing the security for you 🙈 However, Address Flush protocol messages can be secured by using the RBridge Channel Header Extension [RFC7978]. It is RECOMMENDED that all RBridges that implement the Address Flush message be configured to ignore such messages unless they've been secured with an RBridge Channel Header Extension that meets local security policy. Protect your bestie's network 🛡️
If RBridges receiving Address Flush messages don't require them to be at least authenticated, they are relatively easy to forge 😱 In that case, forged Address Flush messages can reduce network efficiency by purging useful learned information that then has to be relearned. This is a denial-of-service attack, but it cannot cause incorrect operation in the sense that it cannot cause a frame to be improperly delivered. Annoying, not catastrophic 💀
For general RBridge Channel Security Considerations, see [RFC7178]. For general TRILL Security Considerations, see [RFC6325] 📚
5. References 📖
5.1. Normative References 🔒
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
- [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, <https://www.rfc-editor.org/info/rfc6325>.
- [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, <https://www.rfc-editor.org/info/rfc7172>.
- [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, <https://www.rfc-editor.org/info/rfc7178>.
- [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, <https://www.rfc-editor.org/info/rfc7780>.
- [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, <https://www.rfc-editor.org/info/rfc7978>.
- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
5.2. Informative References 📝
- [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
- [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
Acknowledgements 🫶
The following are thanked for their contributions 🌷
- Ramkumar Parameswaran, Henning Rogge
Authors' Addresses 💌
Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56624629
Email: liyizhou@huawei.com
Mohammed Umair
Cisco
Cessna Business Park, Kadubeesanahalli Village, Hobli,
Sarjapur, Varthur Main Road, Marathahalli,
Bengaluru, Karnataka 560087
India
Email: mohammed.umair2@gmail.comThat's the whole spec, bestie! 🌈✨ You made it to the end 👑💅
📦 where this page comes from
- ietf: rfc8383 2018-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms