idnits 2.17.00 (12 Aug 2021) /tmp/idnits1586/draft-ietf-trill-address-flush-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 18, 2018) is 1518 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Weiguo Hao 2 INTERNET-DRAFT Donald Eastlake 3 Intended status: Proposed Standard Yizhou Li 4 Huawei 5 Mohammed Umair 6 Cisco 7 Expires: September 17, 2018 March 18, 2018 9 TRILL (TRansparent Interconnection of Lots of Links): 10 Address Flush Message 11 13 Abstract 15 The TRILL (TRansparent Interconnection of Lots of Links) protocol, by 16 default, learns end station addresses from observing the data plane. 17 In particular, it learns local MAC addresses and edge switch port of 18 attachment from the receipt of local data frames and learns remote 19 MAC addresses and edge switch of attachment from the decapsulation of 20 remotely sourced TRILL Data packets. 22 This document specifies a message by which a TRILL switch can 23 explicitly request other TRILL switches to flush certain MAC 24 reachability learned through the decapsulation of TRILL Data packets. 25 This is a supplement to the TRILL automatic address forgetting and 26 can assist in achieving more rapid convergence in case of topology or 27 configuration change. 29 Status of This Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Distribution of this document is unlimited. Comments should be sent 35 to the TRILL working group mailing list: trill@ietf.org. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 48 Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 Table of Contents 53 1. Introduction............................................4 54 1.1 Terminology and Acronyms...............................4 56 2. Address Flush Message Details...........................6 57 2.1 VLAN Block Only Case...................................7 58 2.2 Extensible Case........................................9 59 2.2.1 Blocks of VLANs.....................................12 60 2.2.2 Bit Map of VLANs....................................12 61 2.2.3 Blocks of FGLs......................................13 62 2.2.4 list of FGLs........................................13 63 2.2.5 Big Map of FGLs.....................................14 64 2.2.6 All Data Labels.....................................14 65 2.2.7 MAC Address List....................................15 66 2.2.8 MAC Address Blocks..................................15 68 3. IANA Considerations....................................17 69 3.1 Address Flush RBridge Channel Protocol Number.........17 70 3.2 TRILL Address Flush TLV Types.........................17 72 4. Security Considerations................................18 74 Normative References......................................19 75 Informative References....................................19 77 Acknowledgements..........................................19 78 Authors' Addresses........................................21 80 1. Introduction 82 Edge TRILL (Transparent Interconnection of Lots of Links) switches 83 [RFC6325] [RFC7780], also called edge RBridges, by default learn end 84 station MAC address reachability from observing the data plane. On 85 receipt of a native frame from an end station, they would learn the 86 local MAC address attachment of the source end station. And on 87 egressing (decapsulating) a remotely originated TRILL Data packet, 88 they learn the remote MAC address and remote attachment TRILL switch. 89 Such learning is all scoped by data label (VLAN or Fine Grained Label 90 [RFC7172]). 92 TRILL has mechanisms for timing out such learning and appropriately 93 clearing it based on some network connectivity and configuration 94 changes; however, there are circumstances under which it would be 95 helpful for a TRILL switch to be able to explicitly flush (purge) 96 certain learned end station reachability information in remote 97 RBridges to achieve more rapid convergence. Section 6.2 of [RFC4762] 98 is an example of the use of such a mechanism. 100 Another example, based on Appendix A.3 of [RFC6325] ("Wiring Closet 101 Topology"), presents a bridged LAN connected to a TRILL network via 102 multiple RBridge ports. For optimum paths, Appendix A.3.3 suggests 103 configuring the RBridge ports to be like one Spanning Tree Protocol 104 (STP) tree root in the bridged LAN. The address flush message in this 105 document could also be triggered in this case when one of the edge 106 RBridges receives topology change information (e.g., TC (Topology 107 Change) in STP, TCN (Topology Change Notification) in MSTP (Multiple 108 Spanning Tree Protocol) in order to rapidly flush the MAC addresses 109 for specific VLANs learned at the other edge RBridge ports. 111 A TRILL switch can easily flush any locally learned addresses it 112 wants. This document specifies an RBridge Channel protocol [RFC7178] 113 message to request flushing address information for specific VLANs or 114 FGLs (Fine Grained Labels [RFC7172]) learned from decapsulating TRILL 115 Data packets. 117 1.1 Terminology and Acronyms 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119] [RFC8174] 122 when, and only when, they appear in all capitals, as shown here. 124 This document uses the terms and acronyms defined in [RFC6325] and 125 [RFC7978] as well as the following: 127 Data Label - VLAN or FGL. 129 Edge TRILL switch - A TRILL switch attached to one or more links 130 that provide end station service. 132 FCS - Frame Check Sequence. 134 FGL - Fine Grained Label [RFC7172]. 136 Management VLAN - A VLAN in which all TRILL switches in a campus 137 indicate interest so that multi-destination TRILL Data packets, 138 including RBridge Channel messages [RFC7978], sent with that 139 VLAN as the Inner.VLAN will be delivered to all TRILL switches 140 in the campus. Usually no end station service is offered in the 141 Management VLAN. 143 MAC - Media Access Control. 145 RBridge - An alternative name for a TRILL switch. 147 STP - Spanning Tree Protocol. 149 TC - Topology Change message. 151 TCN - Topology Change Notification message. 153 TRILL switch - A device implementing the TRILL protocol [RFC6325] 154 [RFC7780]. 156 2. Address Flush Message Details 158 The Address Flush message is an RBridge Channel protocol message 159 [RFC7178]. 161 The general structure of an RBridge Channel packet on a link between 162 TRILL switches is shown in Figure 1 below. The Protocol field in the 163 RBridge Channel Header gives the type of RBridge Channel packet and 164 indicates how to interpret the Channel Protocol Specific Payload 165 [RFC7178]. 167 +----------------------------------+ 168 | Link Header | 169 +----------------------------------+ 170 | TRILL Header | 171 +----------------------------------+ 172 | Inner Ethernet Addresses | 173 +----------------------------------+ 174 | Data Label (VLAN or FGL) | 175 +----------------------------------+ 176 | RBridge Channel Header | 177 +----------------------------------+ 178 | Channel Protocol Specific Payload| 179 +----------------------------------+ 180 | Link Trailer (FCS if Ethernet)| 181 +----------------------------------+ 183 Figure 1. RBridge Channel Protocol Message Structure 185 An Address Flush RBridge Channel message by default applies to 186 addresses within the Data Label that appears right after the Inner 187 Ethernet Addresses. Address Flush protocol messages are usually sent 188 as multi-destination packets (TRILL Header M bit equal to one) so as 189 to reach all TRILL switches offering end station service in the VLAN 190 or FGL specified by that Data Label. Both multi-destination and 191 unicast Address Flush messages SHOULD be sent at priority 6 since 192 they are important control messages but are lower priority than 193 control messages that establish or maintain adjacency. 195 Nevertheless: 196 - There are provisions for optionally indicating the Data Label(s) 197 to be flushed for cases where the Address Flush message is sent 198 over a Management VLAN or the like. 199 - An Address Flush message can be sent unicast, if it is desired to 200 clear addresses at one TRILL switch only. 201 - An Address Flush message can be sent selectively to the RBridges 202 that have at least one access port configured as one of VLANs or 203 FGLs specified in the Address Flush message payload. 205 Implementations should consider logging address flush messages 206 received with appropriate protections against packet storms. 208 2.1 VLAN Block Only Case 210 Figure 2 below expands the RBridge Channel Header and Channel 211 Protocol Specific Payload from Figure 1 for the case of the VLAN only 212 based Address Flush message. This form of the Address Flush message 213 is optimized for flushing MAC addressed based on nickname and blocks 214 of VLANs. 0x8946 is the Ethertype assigned by IEEE for the RBridge 215 Channel protocol. 217 0 1 2 3 218 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 219 RBridge Channel Header: 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Flags | ERR | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Address Flush Protocol Specific: 226 +-+-+-+-+-+-+-+-+ 227 | K-nicks | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Nickname 1 | Nickname 2 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Nickname ... | Nickname K-nicks | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | K-VLBs | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | RESV | Start.VLAN 1 | RESV | End.VLAN 1 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | RESV | Start.VLAN 2 | RESV | End.VLAN 2 | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | RESV | Start.VLAN ... | RESV | End.VLAN ... | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | RESV | Start.VLAN K-VLBs | RESV | End.VLAN K-VLBs | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2. Address Flush Message - VLAN Block Case 246 The fields in Figure 2 related to the Address Flush message are as 247 follows: 249 Channel Protocol: The RBridge Channel Protocol value allocated 250 for Address Flush (see Section 3). 252 K-nicks: K-nicks is the number of nicknames listed as an unsigned 253 integer. If this is zero, the ingress nickname in the TRILL 254 Header [RFC6325] is considered to be the only nickname to which 255 the message applies. If non-zero, it given the number of 256 nicknames listed right after K-nicks to which the message 257 applies and, in this non-zero case, the flush does not apply to 258 the ingress nickname in the TRILL Header unless it is also 259 listed. The message flushes address learning due to egressing 260 TRILL Data packets that had an ingress nickname to which the 261 message applies. 263 Nickname: A listed nickname to which it is intended that the 264 Address Flush message apply. If an unknown or reserved 265 nickname occurs in the list, it is ignored but the address 266 flush operation is still executed with the other nicknames. If 267 an incorrect nickname occurs in the list, so some address 268 learning is flushed that should not have been flush, the 269 network will still operate correctly but will be less efficient 270 as the incorrectly flushed learning is re-learned. 272 K-VLBs: K-VLBs is the number of VLAN blocks present as an unsigned 273 integer. If this byte is zero, the message is the more general 274 format specified in Section 2.2. If it is non-zero, it gives 275 the number of blocks of VLANs present. Thus, in the VLAN Block 276 address flush case, K-VLBs will be at least one. 278 RESV: 4 reserved bits. MUST be sent as zero and ignored on 279 receipt. 281 Start.VLAN, End.VLAN: These 12-bit fields give the beginning and 282 ending VLAN IDs of a block of VLANs. The block includes both 283 the starting and ending values so a block of size one is 284 indicated by setting End.VLAN equal to Start.VLAN. If 285 Start.VLAN is 0x000, it is treated as if it was 0x001. If 286 End.VLAN is 0xFFF, it is treated as if it was 0xFFE. If 287 End.VLAN is smaller than Start.VLAN, considering both as 288 unsigned integers, that VLAN block is ignored but the address 289 flush operation is still executed with other VLAN blocks in the 290 message. VLAN blocks may overlap, in which case the address 291 flush operation is applicable to a VLAN covered by any one or 292 more of the blocks in the message. 294 This message flushes all addresses in an applicable VLAN learned from 295 egressing TRILL Data packets with an applicable nickname as ingress. 296 To flush addresses for all VLANs, it is easy to specify a block 297 covering all valid VLAN IDs, this is, from 0x001 to 0xFFE. 299 2.2 Extensible Case 301 A more general form of the Address Flush message is provided to 302 support flushing by FGL and more efficient encodings of VLANs and 303 FGLs where using a set of contiguous blocks is cumbersome. It also 304 supports optionally specifying the MAC addresses to clear. This form 305 is extensible. 307 The extensible case is indicated by a zero in the byte shown in 308 Figure 2 as "K-VLBs" followed by other information encoded as TLVs. 310 0 1 2 3 311 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 312 RBridge Channel Header: 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Flags | ERR | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Address Flush Protocol Specific: 319 +-+-+-+-+-+-+-+-+ 320 | K-nicks | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Nickname 1 | Nickname 2 | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Nickname ... | Nickname K-nicks | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | 0 | TLVs ... 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 329 Figure 3. Address Flush Message - Extensible Case 331 Channel Protocol, K-nicks, Nickname: These fields are as specified 332 in Section 2.1. 334 TLVs: If the byte immediately before the TLVs field, which is the 335 byte labeled "K-VLBs" in Figure 2, is zero, as shown in Figure 336 3, the remainder of the message consists of TLVs encoded as 337 shown in Figure 4. 339 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 341 | Type | Length | Value 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 344 Figure 4. Type, Length, Value 346 Type: The 8-bit TLV type as shown in the table below. See 347 subsections of this Section 2.2 for details on each type 348 assigned below. If the type is reserved or not known by a 349 receiving RBridge, that receiving RBridge ignores the value and 350 skips to the next TLV by use of the Length byte. There is no 351 provision for a list of VLAN IDs TLV as there are few enough of 352 them that an arbitrary subset of VLAN IDs can be represented as 353 a bit map. 355 Type Description Reference 356 ------ ------------------ ----------------- 357 0 Reserved [this document] 358 1 Blocks of VLANs [this document] 359 2 Bit Map of VLANs [this document] 360 3 Blocks of FGLs [this document] 361 4 List of FGLs [this document] 362 5 Bit Map of FGLs [this document] 363 6 All Data Labels [this document] 364 7 MAC Address List [this document] 365 8 MAC Address Blocks [this document] 366 9-254 Unassigned 367 255 Reserved [this document] 369 Length: The 8-bit unsigned integer length in bytes of the 370 remaining information in the TLV after the length byte. The 371 length MUST NOT imply that the value extends beyond the end of 372 RBridge Channel Protocol Specific Payload area. If it does, the 373 Address Flush message is corrupt and MUST be ignored. 375 Value: Depends on the TLV type. 377 In an extensible Address Flush message, when the TLVs are parsed 378 those TLVs having unknown types are ignored by the receiving RBridge. 379 There may be multiple instances of TLVs with the same Type in the 380 same address flush message and TLVs are not required to be in any 381 particular order. 382 o All RBridges implementing the Address Flush RBridge Channel 383 message MUST implement types 1 and 2, the VLAN types, and type 6, 384 which indicates addresses are to be flushed for all Data Labels. 385 o RBridges that implement the Address Flush message and implement 386 FGL ingress/egress MUST implement types 3, 4, and 5, the FGL 387 types. (An RBridge that is merely FGL safe [RFC7172], but cannot 388 egress FGL TRILL Data packets, SHOULD ignore the FGL types as it 389 will not learn any FGL scoped MAC addresses from the data plane.) 390 o RBridges that implement the Address Flush message SHOULD implement 391 types 7 and 8 so that specific MAC addresses can be flushed. If 392 they do not, the effect will be to flush all MAC addresses for the 393 indicated Data Labels, which may be inefficient as any MAC 394 addresses not intended to be flushed will have to be re-learned. 396 The parsing of the TLVs by a receiving RBridge results in three items 397 of information: 398 1. a flag indicating whether one or more Type 6 TLVs (All Data 399 Labels) were encountered; 400 2. a set of Data Labels accumulated from VLAN and/or FGL 401 specifying TLVs in the message; and, 402 3. if the MAC address TLV types are implemented, and a set of MAC 403 addresses accumulated from MAC address specifying TLVs in the 404 message. 406 VLANs/FGLs might be indicated more than once due to overlapping 407 blocks or the like and a VLAN/FGL is included in the above set of 408 VLANs/FGLs if it occurs in any TLV in the address flush message. A 409 MAC address might be indicated more than once due to overlapping 410 blocks or the like and a MAC address is included in the above set of 411 MAC addresses if it occurs in any TLV in the address flush message. 413 After the above information has been accumulated by parsing the TLVs, 414 three sets are derived as described below: a set of nicknames, a set 415 of Data Labels, and a set of MAC addresses. The address flush 416 operation at the receiver applies to the cross product of these 417 derived sets. That is, a { Data Label, MAC address, nickname } triple 418 is flushed if and only if the Data Label matches an element in the 419 derived set of Data Labels, the MAC address matches an element in the 420 derived set of MAC address, and the nickname matches an element in 421 the derived set of nicknames. In the case of Data Labels and MAC 422 addresses, a special value of the set, {ALL}, is permitted which 423 matches all values. 425 The sets are derived as follows: 427 Data Labels set: 428 If the Type 6 TLV has been encountered, the set is {ALL}, else, 429 if any Data Labels have been accumulated by processing Data 430 Label TLVs (Types 1, 2, 3, 4, and 5), the set is those 431 accumulated Data Labels, else, 432 the Data Labels set is null and the address flush message does 433 nothing. 435 MAC Addresses set: 436 In the receiver does not implement the MAC address types (Types 437 7 and 8) or it does implement those types but no MAC 438 addresses are accumulated in parsing the TLVs, then the MAC 439 Address set is {ALL}, 440 else, the MAC Addresses set is the set of MAC addresses 441 accumulated in processing the TLVs. 443 Nicknames set: 444 If the K-nicks field in the Address Flush message was zero, 445 then the ingress nickname in the TRILL Header of the message 446 is the sole nickname set member, else, 447 the nicknames set members are the K-nicks nicknames listed in 448 the Address Flush message. 450 The various formats below are provided for encoding efficiency. A 451 block of values is most efficient when there are a number of 452 consecutive values. A bit map is most efficient if there are 453 scattered values within a limited range. And a list of single values 454 is most efficient if there are widely scattered values. 456 2.2.1 Blocks of VLANs 458 If the TLV Type is 1, the value is a list of blocks of VLANs as 459 follows: 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type = 1 | Length | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | RESV | Start.VLAN 1 | RESV | End.VLAN 1 | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | RESV | Start.VLAN 2 | RESV | End.VLAN 2 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | RESV | Start.VLAN ... | RESV | End.VLAN ... | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 The meaning of Start.VLAN and End.VLAN is as specified in Section 472 2.1. Length MUST be a multiple of 4. If Length is not a multiple of 473 4, the TLV is corrupt and the Address Flush message MUST be 474 discarded. 476 2.2.2 Bit Map of VLANs 478 If the TLV Type is 2, the value is a bit map of VLANs as follows: 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Type = 2 | Length | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 483 | RESV | Start.VLAN | Bits... 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 486 The value portion of the TLV begins with two bytes having the 12-bit 487 starting VLAN ID right justified (the top 4 bits are as specified in 488 Section 2.1 RESV). This is followed by bytes with one bit per VLAN 489 ID. The high order bit of the first byte is for VLAN N, the next to 490 the highest order bit is for VLAN N+1, the low order bit of the first 491 byte is for VLAN N+7, the high order bit of the second byte, if there 492 is a second byte, is for VLAN N+8, and so on. If that bit is a one, 493 the Address Flush message applies to that VLAN. If that bit is a 494 zero, then addresses that have been learned in that VLAN are not 495 flushed. Note that Length MUST be at least 2. If Length is 0 or 1 496 the TLV is corrupt and the Address Flush message MUST be discarded. 497 VLAN IDs do not wrap around. If there are enough bytes so that some 498 bits correspond to VLAN ID 0xFFF or higher, those bits are ignored 499 but the message is still processed for bits corresponding to valid 500 VLAN IDs. 502 2.2.3 Blocks of FGLs 504 If the TLV Type is 3, the value is a list of blocks of FGLs as 505 follows: 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Type = 3 | Length | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Start.FGL 1 | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | End.FGL 1 | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Start.FGL 2 | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | End.FGL 2 | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Start.FGL ... | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | End.FGL ... | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 The TLV value consists of sets of Start.FGL and End.FGL numbers. The 524 Address Flush information applies to the FGLs in that range, 525 inclusive. A single FGL is indicated by setting both Start.FGL and 526 End.FGL to the same value. If End.FGL is less than Start.FGL, 527 considering them as unsigned integers, that block is ignored but the 528 Address Flush message is still processed for any other blocks 529 present. For this Type, Length MUST be a multiple of 6; if it is not, 530 the TLV is corrupt and the Address Flush message MUST be discarded if 531 the receiving RBridge implements Type 3. 533 2.2.4 list of FGLs 535 If the TLV Type is 4, the value is a list of FGLs as follows: 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type = 4 | Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | FGL 1 | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | FGL 2 | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | FGL ... | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 The TLV value consists of FGL numbers each in 3 bytes. The Address 548 Flush message applies to those FGLs. For this Type, Length MUST be a 549 multiple of 3; if it is not, the TLV is corrupt and the address flush 550 Message MUST be discarded if the receiving RBridge implements Type 4. 552 2.2.5 Big Map of FGLs 554 If the TLV Type is 5, the value is a bit map of FGLs as follows: 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type = 5 | Length | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Start.FGL | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Bits... 562 +-+-+-+-+-+-+-+- 564 The TLV value consists of three bytes with the 24-bit starting FGL 565 value N. This is followed by bytes with one bit per FGL. The high 566 order bit of the first byte is for FGL N, the next to the highest 567 order bit is for FGL N+1, the low order bit of the first byte is for 568 FGL N+7, the high order bit of the second byte, if there is a second 569 byte, is for FGL N+8, and so on. If that bit is a one, the Address 570 Flush message applies to that FGL. If that bit is a zero, then 571 addresses that have been learned in that FGL are not flushed. Note 572 that Length MUST be at least 3. If Length is 0, 1, or 2 for a Type 5 573 TLV, the TLV is corrupt and the Address Flush message MUST be 574 discarded if type 5 is implemented. FGLs do not wrap around. If 575 there are enough bytes so that some bits correspond to an FGL higher 576 than 0xFFFFFF, those bits are ignored but the message is still 577 processed for bits corresponding to valid FGLs. 579 2.2.6 All Data Labels 581 If the TLV Type is 6, the value is null as follows: 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type = 6 | Length = 0 | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 This type is used when a RBridge wants to withdraw all addresses for 588 all the Data Labels (all VLANs and FGLs). Length MUST be zero. If 589 Length is any other value, the TLV is corrupt and the Address Flush 590 message MUST be discarded. 592 2.2.7 MAC Address List 594 If the TLV Type is 7, the value is a list of MAC addresses as 595 follows: 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Type = 7 | Length | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | MAC 1 upper half | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | MAC 1 lower half | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | MAC 2 upper half | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | MAC 2 lower half | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | MAC ... upper half | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | MAC ... lower half | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 The TLV value consists of a list of 48-bit MAC addresses. Length MUST 614 be a multiple of 6. If it is not, the TLV is corrupt and the Address 615 Flush message MUST be discarded if the receiving RBridge implements 616 Type 7. 618 2.2.8 MAC Address Blocks 620 If the TLV Type is 8, the value is a list of blocks of MAC addresses 621 as follows: 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Type = 8 | Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | MAC.start 1 upper half | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | MAC.start 1 lower half | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | MAC.end 1 upper half | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | MAC.end 1 lower half | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | MAC.start 2 upper half | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | MAC.start 2 lower half | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | MAC.end 2 upper half | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | MAC.end 2 lower half | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | MAC.start ... upper half | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | MAC.start ... lower half | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | MAC.end ... upper half | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | MAC.end ... lower half | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 The TLV value consists of sets of Start.MAC and End.MAC numbers. The 652 Address Flush information applies to the 48-bit MAC Addresses in that 653 range, inclusive. A single MAC Address is indicated by setting both 654 Start.MAC and End.MAC to the same value. If End.MAC is less than 655 Start.MAC, considering them as unsigned integers, that block is 656 ignored but the Address Flush message is still processed for any 657 other blocks present. For this Type, Length MUST be a multiple of 12; 658 if it is not, the TLV is corrupt and the Address Flush message MUST 659 be discarded if the receiving RBridge implements Type 7. 661 3. IANA Considerations 663 Two IANA actions are requested as follows: 665 3.1 Address Flush RBridge Channel Protocol Number 667 IANA is requested to assign TBD as the Address Flush RBridge Channel 668 Protocol number from the range of RBridge Channel protocols allocated 669 by Standards Action [RFC7178]. 671 The added RBridge Channel protocols registry entry on the TRILL 672 Parameters web page is as follows: 674 Protocol Description Reference 675 -------- -------------- ------------------ 676 TBD Address Flush [this document] 678 3.2 TRILL Address Flush TLV Types 680 IANA is requested to create a TRILL Address Flush TLV Types registry 681 on the TRILL Parameters web page indented after the RBridge Channel 682 Protocols registry. Registry headers are as below. The initial 683 entries are as in the table in Section 2.2 above. 685 Registry: TRILL Address Flush TLV Types 686 Registration Procedures: IETF Review 687 Reference: [this document] 689 4. Security Considerations 691 The Address Flush RBridge Channel Protocol itself provides no 692 security assurances or features. However, Address Flush protocol 693 messages can be secured by use of the RBridge Channel Header 694 Extension [RFC7978]. It is RECOMMENDED that all RBridges that 695 implement the address flush message be configured to ignore such 696 messages unless they have been secured with an RBridge Channel Header 697 Extension that meets local security policy. 699 If RBridges receiving Address Flush messages do not require them to 700 be at least authenticated, they are relatively easy to forge. In that 701 case, such forged Address Flush messages can reduce network 702 efficiency, by purging useful learned information that will have to 703 be re-learned. This provides a denial of service attack but cannot 704 cause incorrect operation in the sense that it cannot cause a frame 705 to be improperly delivered. 707 See [RFC7178] for general RBridge Channel Security Considerations. 709 See [RFC6325] for general TRILL Security Considerations. 711 Normative References 713 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 714 Requirement Levels", BCP 14, RFC 2119, March 1997. 716 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 717 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 718 July 2011. 720 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 721 and D. Dutt, "Transparent Interconnection of Lots of Links 722 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 723 10.17487/RFC7172, May 2014, . 726 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 727 Ward, "Transparent Interconnection of Lots of Links (TRILL): 728 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 729 2014, . 731 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 732 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 733 Lots of Links (TRILL): Clarifications, Corrections, and 734 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 735 . 737 [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 738 Interconnection of Lots of Links (TRILL): RBridge Channel 739 Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 740 2016, . 742 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in 743 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 744 May 2017, 746 Informative References 748 [RFC4762] - Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 749 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 750 Signaling", RFC 4762, January 2007. 752 Acknowledgements 754 The following are thanked for their contributions: 756 Ramkumar Parameswaran, Henning Rogge 758 The document was prepared in raw nroff. All macros used were defined 759 within the source file. 761 Authors' Addresses 763 Weiguo Hao 764 Huawei Technologies 765 101 Software Avenue, 766 Nanjing 210012, China 768 Phone: +86-25-56623144 769 Email: haoweiguo@huawei.com 771 Donald E. Eastlake, 3rd 772 Huawei Technologies 773 155 Beaver Street 774 Milford, MA 01757 USA 776 Phone: +1-508-333-2270 777 EMail: d3e3e3@gmail.com 779 Yizhou Li 780 Huawei Technologies 781 101 Software Avenue, 782 Nanjing 210012 783 China 785 Phone: +86-25-56624629 786 Email: liyizhou@huawei.com 788 Mohammed Umair 789 Cisco 790 Cessna Business Park, Kadubeesanahalli Village, Hobli, 791 Sarjapur, Varthur Main Road, Marathahalli, 792 Bengaluru, Karnataka 560087 India 794 Email: mohammed.umair2@gmail.com 796 Copyright, Disclaimer, and Additional IPR Provisions 798 Copyright (c) 2018 IETF Trust and the persons identified as the 799 document authors. All rights reserved. 801 This document is subject to BCP 78 and the IETF Trust's Legal 802 Provisions Relating to IETF Documents 803 (http://trustee.ietf.org/license-info) in effect on the date of 804 publication of this document. Please review these documents 805 carefully, as they describe your rights and restrictions with respect 806 to this document. Code Components extracted from this document must 807 include Simplified BSD License text as described in Section 4.e of 808 the Trust Legal Provisions and are provided without warranty as 809 described in the Simplified BSD License. The definitive version of 810 an IETF Document is that published by, or under the auspices of, the 811 IETF. Versions of IETF Documents that are published by third parties, 812 including those that are translated into other languages, should not 813 be considered to be definitive versions of IETF Documents. The 814 definitive version of these Legal Provisions is that published by, or 815 under the auspices of, the IETF. Versions of these Legal Provisions 816 that are published by third parties, including those that are 817 translated into other languages, should not be considered to be 818 definitive versions of these Legal Provisions. For the avoidance of 819 doubt, each Contributor to the IETF Standards Process licenses each 820 Contribution that he or she makes as part of the IETF Standards 821 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 822 language to the contrary, or terms, conditions or rights that differ 823 from or are inconsistent with the rights and licenses granted under 824 RFC 5378, shall have any effect and shall be null and void, whether 825 published or posted by such Contributor, or included with or in such 826 Contribution.