idnits 2.17.1 draft-ietf-trill-address-flush-05.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 (January 22, 2018) is 2286 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: July 21, 2018 January 22, 2018 9 TRILL: Address Flush Message 10 12 Abstract 14 The TRILL (TRansparent Interconnection of Lots of Links) protocol, by 15 default, learns end station addresses from observing the data plane. 16 In particular, it learns local MAC addresses and edge switch port of 17 attachment from the receipt of local data frames and learns remote 18 MAC addresses and edge switch of attachment from the decapsulation of 19 remotely sourced TRILL Data packets. 21 This document specifies a message by which a TRILL switch can 22 explicitly request other TRILL switches to flush certain MAC 23 reachability learned through the decapsulation of TRILL Data packets. 24 This is a supplement to the TRILL automatic address forgetting and 25 can assist in achieving more rapid convergence in case of topology or 26 configuration change. 28 Status of This Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Distribution of this document is unlimited. Comments should be sent 34 to the TRILL working group mailing list: trill@ietf.org. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 47 Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 Table of Contents 52 1. Introduction............................................4 53 1.1 Terminology and Acronyms...............................4 55 2. Address Flush Message Details...........................6 56 2.1 VLAN Block Only Case...................................7 57 2.2 Extensible Case........................................8 58 2.2.1 Blocks of VLANs.....................................11 59 2.2.2 Bit Map of VLANs....................................11 60 2.2.3 Blocks of FGLs......................................12 61 2.2.4 list of FGLs........................................13 62 2.2.5 Big Map of FGLs.....................................13 63 2.2.6 All Data Labels.....................................14 64 2.2.7 MAC Address List....................................14 65 2.2.8 MAC Address Blocks..................................15 67 3. IANA Considerations....................................16 68 3.1 Address Flush RBridge Channel Protocol Number.........16 69 3.2 TRILL Address Flush TLV Types.........................16 71 4. Security Considerations................................17 73 Normative References......................................18 74 Informative References....................................18 76 Acknowledgements..........................................18 77 Authors' Addresses........................................19 79 1. Introduction 81 Edge TRILL (Transparent Interconnection of Lots of Links) switches 82 [RFC6325] [RFC7780], also called edge RBridges, by default learn end 83 station MAC address reachability from observing the data plane. On 84 receipt of a native frame from an end station, they would learn the 85 local MAC address attachment of the source end station. And on 86 egressing (decapsulating) a remotely originated TRILL Data packet, 87 they learn the remote MAC address and remote attachment TRILL switch. 88 Such learning is all scoped by data label (VLAN or Fine Grained Label 89 [RFC7172]). 91 TRILL has mechanisms for timing out such learning and appropriately 92 clearing it based on some network connectivity and configuration 93 changes; however, there are circumstances under which it would be 94 helpful for a TRILL switch to be able to explicitly flush (purge) 95 certain learned end station reachability information in remote 96 RBridges to achieve more rapid convergence. Section 6.2 of [RFC4762] 97 is an example of the use of such a mechanism. 99 Another example is based on Appendix A.3 of [RFC6325] ("Wiring Closet 100 Topology") presents a bridged LAN connected to a TRILL network via 101 multiple RBridge ports. For optimum paths, Appendix A.3.3 suggests 102 configuring the RBridge ports to be like one Spanning Tree Protocol 103 (STP) tree root in the bridged LAN. The address flush message in this 104 document could also be triggered in this case when one of the edge 105 RBridges receives topology change information (e.g., TC in STP, TCN 106 in MSTP) in order to rapidly flush the MAC addresses for specific 107 VLANs learned at the other edge RBridge ports. 109 A TRILL switch RB1 can easily flush any locally learned addresses it 110 wants. This document specifies an RBridge Channel protocol [RFC7178] 111 message to request flushing address information for specific VLANs or 112 FGLs learned from decapsulating TRILL Data packets. 114 1.1 Terminology and Acronyms 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 This document uses the terms and acronyms defined in [RFC6325] and 121 [RFC7978] as well as the following: 123 Data Label - VLAN or FGL. 125 Edge TRILL switch - A TRILL switch attached to one or more links 126 that provide end station service. 128 FGL - Fine Grained Label [RFC7172]. 130 Management VLAN - A VLAN in which all TRILL switches in a campus 131 indicate interest so that multi-destination TRILL Data packets, 132 including RBridge Channel messages [RFC7978], sent with that 133 VLAN as the Inner.VLAN will be delivered to all TRILL switches 134 in the campus. Usually no end station service is offered in the 135 Management VLAN. 137 RBridge - An alternative name for a TRILL switch. 139 STP - Spanning Tree Protocol. 141 TRILL switch - A device implementing the TRILL protocol [RFC6325] 142 [RFC7780]. 144 2. Address Flush Message Details 146 The Address Flush message is an RBridge Channel protocol message 147 [RFC7178]. 149 The general structure of an RBridge Channel packet on a link between 150 TRILL switches is shown in Figure 1 below. The Protocol field in the 151 RBridge Channel Header gives the type of RBridge Channel packet and 152 indicates how to interpret the Channel Protocol Specific Payload 153 [RFC7178]. 155 +----------------------------------+ 156 | Link Header | 157 +----------------------------------+ 158 | TRILL Header | 159 +----------------------------------+ 160 | Inner Ethernet Addresses | 161 +----------------------------------+ 162 | Data Label (VLAN or FGL) | 163 +----------------------------------+ 164 | RBridge Channel Header | 165 +----------------------------------+ 166 | Channel Protocol Specific Payload| 167 +----------------------------------+ 168 | Link Trailer (FCS if Ethernet)| 169 +----------------------------------+ 171 Figure 1. RBridge Channel Protocol Message Structure 173 An Address Flush RBridge Channel message by default applies to 174 addresses within the Data Label that appears right after the Inner 175 Ethernet Addresses. Address Flush protocol messages are usually sent 176 as multi-destination packets (TRILL Header M bit equal to one) so as 177 to reach all TRILL switches offering end station service in the VLAN 178 or FGL specified by that Data Label. Such messages SHOULD be sent at 179 priority 6 since they are important control messages but are lower 180 priority than control messages that establish or maintain adjacency. 182 Nevertheless: 183 - There are provisions for optionally indicating the Data Label(s) 184 to be flushed for cases where the Address Flush message is sent 185 over a Management VLAN or the like. 186 - An Address Flush message can be sent unicast, if it is desired to 187 clear addresses at one TRILL switch only. 188 - An Address Flush message can be sent selectively to the RBridges 189 that have at least one access port configured as one of VLANs or 190 FGLs specified in the Address Flush message payload. 192 2.1 VLAN Block Only Case 194 Figure 2 below expands the RBridge Channel Header and Channel 195 Protocol Specific Payload from Figure 1 for the case of the VLAN only 196 based Address Flush message. This form of the Address Flush message 197 is optimized for flushing MAC addressed based on nickname and blocks 198 of VLANs. 0x8946 is the Ethertype assigned by IEEE for the RBridge 199 Channel protocol. 201 0 1 2 3 202 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 203 RBridge Channel Header: 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Flags | ERR | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Address Flush Protocol Specific: 210 +-+-+-+-+-+-+-+-+ 211 | K-nicks | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Nickname 1 | Nickname 2 | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Nickname ... | Nickname K-nicks | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | K-VLBs | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | RESV | Start.VLAN 1 | RESV | End.VLAN 1 | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | RESV | Start.VLAN 2 | RESV | End.VLAN 2 | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | RESV | Start.VLAN ... | RESV | End.VLAN ... | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | RESV | Start.VLAN K-VLBs | RESV | End.VLAN K-VLBs | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 2. Address Flush Message - VLAN Block Case 230 The fields in Figure 2 related to the Address Flush message are as 231 follows: 233 Channel Protocol: The RBridge Channel Protocol value allocated 234 for Address Flush (see Section 3). 236 K-nicks: K-nicks is the number of nicknames listed as an unsigned 237 integer. If this is zero, the ingress nickname in the TRILL 238 Header [RFC6325] is considered to be the only nickname to which 239 the message applies. If non-zero, it given the number of 240 nicknames listed right after K-nicks to which the message 241 applies and, in this non-zero case, the flush does not apply to 242 the ingress nickname in the TRILL Header unless it is also 243 listed. The message flushes address learning due to egressing 244 TRILL Data packets that had an ingress nickname to which the 245 message applies. 247 Nickname: A listed nickname to which it is intended that the 248 Address Flush message apply. If an unknown or reserved 249 nickname occurs in the list, it is ignored but the address 250 flush operation is still executed with the other nicknames. If 251 an incorrect nickname occurs in the list, so some address 252 learning is flushed that should not have been flush, the 253 network will still operate correctly but will be less efficient 254 as the incorrectly flushed learning is re-learned. 256 K-VLBs: K-VLBs is the number of VLAN blocks present as an unsigned 257 integer. If this byte is zero, the message is the more general 258 format specified in Section 2.2. If it is non-zero, it gives 259 the number of blocks of VLANs present. Thus, in the VLAN Block 260 address flush case, K-VLBs will be at least one. 262 RESV: 4 reserved bits. MUST be sent as zero and ignored on 263 receipt. 265 Start.VLAN, End.VLAN: These 12-bit fields give the beginning and 266 ending VLAN IDs of a block of VLANs. The block includes both 267 the starting and ending values so a block of size one is 268 indicated by setting End.VLAN equal to Start.VLAN. If 269 Start.VLAN is 0x000, it is treated as if it was 0x001. If 270 End.VLAN is 0xFFF, it is treated as if it was 0xFFE. If 271 End.VLAN is smaller than Start.VLAN, considering both as 272 unsigned integers, that VLAN block is ignored but the address 273 flush operation is still executed with other VLAN blocks in the 274 message. VLAN blocks may overlap, in which case the address 275 flush operation is applicable to a VLAN covered by any one or 276 more of the blocks in the message. 278 This message flushes all addresses in an applicable VLAN learned from 279 egressing TRILL Data packets with an applicable nickname as ingress. 280 To flush addresses for all VLANs, it is easy to specify a block 281 covering all valid VLAN IDs, this is, from 0x001 to 0xFFE. 283 2.2 Extensible Case 285 A more general form of the Address Flush message is provided to 286 support flushing by FGL and more efficient encodings of VLANs and 287 FGLs where using a set of contiguous blocks if cumbersome. It also 288 supports optionally specifying the MAC addresses to clear. This form 289 is extensible. 291 The extensible case is indicated by a zero in the byte shown in 292 Figure 2 as "K-VLBs" followed by other information encoded as TLVs. 294 0 1 2 3 295 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 296 RBridge Channel Header: 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Flags | ERR | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Address Flush Protocol Specific: 303 +-+-+-+-+-+-+-+-+ 304 | K-nicks | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Nickname 1 | Nickname 2 | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Nickname ... | Nickname K-nicks | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | 0 | TLVs ... 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 313 Figure 3. Address Flush Message - Extensible Case 315 Channel Protocol, K-nicks, Nickname: These fields are as specified 316 in Section 2.1. 318 TLVs: If the byte immediately before the TLVs field, which is the 319 byte labeled "K-VLBs" in Figure 2, is zero, as shown in Figure 320 3, the remainder of the message consists of TLVs encoded as 321 shown in Figure 4. 323 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 325 | Type | Length | Value 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 328 Figure 4. Type, Length, Value 330 Type: The 8-bit TLV type as shown in the table below. See 331 subsections of this Section 2.2 for details on each type 332 assigned below. If the type is reserved or not known by a 333 receiving RBridge, that receiving RBridge ignores the value and 334 skips to the next TLV by use of the Length byte. There is no 335 provision for a list of VLAN IDs TLV as there are few enough of 336 them that an arbitrary subset of VLAN IDs can be represented as 337 a bit map. 339 Type Description Reference 340 ------ ------------------ ----------------- 341 0 Reserved [this document] 342 1 Blocks of VLANs [this document] 343 2 Bit Map of VLANs [this document] 344 3 Blocks of FGLs [this document] 345 4 List of FGLs [this document] 346 5 Bit Map of FGLs [this document] 347 6 All Data Labels [this document] 348 7 MAC Address List [this document] 349 8 MAC Address Blocks [this document] 350 9-254 Unassigned 351 255 Reserved [this document] 353 Length: The 8-bit unsigned integer length in bytes of the 354 remaining information in the TLV after the length byte. The 355 length MUST NOT imply that the value extends beyond the end of 356 RBridge Channel Protocol Specific Payload area. If it does, the 357 Address Flush message is corrupt and MUST be ignored. 359 Value: Depends on the TLV type. 361 In an extensible Address Flush message, when the TLVs are parsed 362 those TLVs having unknown types are ignored by the receiving RBridge. 363 There may be multiple instances of TLVs with the same Type in the 364 same address flush message and TLVs are not required to be in any 365 particular order. 366 All RBridges implementing the Address Flush RBridge Channel 367 message MUST implement types 1 and 2, the VLAN types, and type 6, 368 which indicates addresses are to be flushed for all Data Labels. 369 RBridges that implement FGL ingress/egress MUST implement types 3, 370 4, and 5, the FGL types. (An RBridge that is merely FGL safe 371 [RFC7172], but cannot egress FGL TRILL Data packets, SHOULD ignore 372 the FGL types as it will not learn any FGL scoped MAC addresses from 373 the data plane.) 374 RBridges SHOULD implement types 7 and 8 so that specific MAC 375 addresses can be flushed. If they do not, the effect will be to flush 376 all MAC addresses for the indicated Data Labels, which may be 377 inefficient as any MAC addresses not intended to be flushed will have 378 to be re-learned. 380 The parsing of the TLVs by a receiving RBridge results in three items 381 of information: a flag indicating whether one or more Type 6 TLVs 382 (All Data Labels) were encountered; a set of Data Labels accumulated 383 from VLAN and/or FGL specifying TLVs in the message; and, if the MAC 384 address TLV types are implemented, and a set of MAC addresses 385 accumulated from MAC address specifying TLVs in the message. 386 VLANs/FGLs might be indicated more than once due to overlapping 387 blocks or the like and a VLAN/FGL is included in the above set of 388 VLANs/FGLs if it occurs in any TLV in the address flush message. A 389 MAC addresses might be indicated more than once due to overlapping 390 blocks or the like and a MAC address is included in the above set of 391 MAC addresses if it occurs in any TLV in the address flush message. 392 If the set of MAC addresses accumulated from parsing the address 393 flush message is null, the message applies to all MAC addresses. 394 If the flag indicating the presence of an All Data Labels TLV is 395 true, then the address flush message applies to all Data Labels and 396 the set of Data Labels and block of Data labels specified has no 397 effect. If the flag indicating the presence of an All Data Labels TLV 398 is false, then the address flush messages applies only to the set of 399 Data Labels accumulated from parsing the message; if that set is 400 null, the address flush message does nothing. 402 The various formats below are provided for encoding efficiency. A 403 block of values is most efficient when there are a number of 404 consecutive values. A bit map is most efficient if there are 405 scattered values within a limited range. And a list of single values 406 is most efficient if there are widely scattered values. 408 2.2.1 Blocks of VLANs 410 If the TLV Type is 1, the value is a list of blocks of VLANs as 411 follows: 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type = 1 | Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | RESV | Start.VLAN 1 | RESV | End.VLAN 1 | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | RESV | Start.VLAN 2 | RESV | End.VLAN 2 | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | RESV | Start.VLAN ... | RESV | End.VLAN ... | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 The meaning of Start.VLAN and End.VLAN is as specified in Section 424 2.1. Length MUST be a multiple of 4. If Length is not a multiple of 425 4, the TLV is corrupt and the Address Flush message MUST be ignored. 427 2.2.2 Bit Map of VLANs 429 If the TLV Type is 2, the value is a bit map of VLANs as follows: 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Type = 2 | Length | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 434 | RESV | Start.VLAN | Bits... 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 437 The value portion of the TLV begins with two bytes having the 12-bit 438 starting VLAN ID right justified (the top 4 bits are as specified in 439 Section 2.1 RESV). This is followed by bytes with one bit per VLAN 440 ID. The high order bit of the first byte is for VLAN N, the next to 441 the highest order bit is for VLAN N+1, the low order bit of the first 442 byte is for VLAN N+7, the high order bit of the second byte, if there 443 is a second byte, is for VLAN N+8, and so on. If that bit is a one, 444 the Address Flush message applies to that VLAN. If that bit is a 445 zero, then addresses that have been learned in that VLAN are not 446 flushed. Note that Length MUST be at least 2. If Length is 0 or 1 447 the TLV is corrupt and the Address Flush message MUST be ignored. 448 VLAN IDs do not wrap around. If there are enough bytes so that some 449 bits correspond to VLAN ID 0xFFF or higher, those bits are ignored 450 but the message is still processed for bits corresponding to valid 451 VLAN IDs. 453 2.2.3 Blocks of FGLs 455 If the TLV Type is 3, the value is a list of blocks of FGLs as 456 follows: 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Type = 3 | Length | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Start.FGL 1 | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | End.FGL 1 | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Start.FGL 2 | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | End.FGL 2 | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Start.FGL ... | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | End.FGL ... | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 The TLV value consists of sets of Start.FGL and End.FGL numbers. The 475 Address Flush information applies to the FGLs in that range, 476 inclusive. A single FGL is indicated by setting both Start.FGL and 477 End.FGL to the same value. If End.FGL is less than Start.FGL, 478 considering them as unsigned integers, that block is ignored but the 479 Address Flush message is still processed for any other blocks 480 present. For this Type, Length MUST be a multiple of 6; if it is not, 481 the TLV is corrupt and the Address Flush message MUST be discarded if 482 the receiving RBridge implements Type 3. 484 2.2.4 list of FGLs 486 If the TLV Type is 4, the value is a list of FGLs as follows: 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type = 4 | Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | FGL 1 | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | FGL 2 | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | FGL ... | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 The TLV value consists of FGL numbers each in 3 bytes. The Address 499 Flush message applies to those FGLs. For this Type, Length MUST be a 500 multiple of 3; if it is not, the TLV is corrupt and the address flush 501 Message MUST be discarded if the receiving RBridge implements Type 4. 503 2.2.5 Big Map of FGLs 505 If the TLV Type is 5, the value is a bit map of FGLs as follows: 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Type = 5 | Length | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Start.FGL | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Bits... 513 +-+-+-+-+-+-+-+- 515 The TLV value consists of three bytes with the 24-bit starting FGL 516 value N. This is followed by bytes with one bit per FGL. The high 517 order bit of the first byte is for FGL N, the next to the highest 518 order bit is for FGL N+1, the low order bit of the first byte is for 519 FGL N+7, the high order bit of the second byte, if there is a second 520 byte, is for FGL N+8, and so on. If that bit is a one, the Address 521 Flush message applies to that FGL. If that bit is a zero, then 522 addresses that have been learned in that FGL are not flushed. Note 523 that Length MUST be at least 3. If Length is 0, 1, or 2 for a Type 5 524 TLV, the TLV is corrupt and the Address Flush message MUST be 525 discarded. FGLs do not wrap around. If there are enough bytes so 526 that some bits correspond to an FGL higher than 0xFFFFFF, those bits 527 are ignored but the message is still processed for bits corresponding 528 to valid FGLs. 530 2.2.6 All Data Labels 532 If the TLV Type is 6, the value is null as follows: 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type = 6 | Length = 0 | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 This type is used when a RBridge wants to withdraw all addresses for 539 all the Data Labels (all VLANs and FGLs). Length MUST be zero. If 540 Length is any other value, the TLV is corrupt and the Address Flush 541 message MUST be ignored. 543 2.2.7 MAC Address List 545 If the TLV Type is 7, the value is a list of MAC addresses as 546 follows: 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Type = 7 | Length | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | MAC 1 upper half | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | MAC 1 lower half | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | MAC 2 upper half | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | MAC 2 lower half | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | MAC ... upper half | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | MAC ... lower half | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 The TLV value consists of a list of 48-bit MAC addresses. Length MUST 565 be a multiple of 6. If it is not, the TLV is corrupt and the Address 566 Flush message MUST be ignored if the receiving RBridge implements 567 Type 7. 569 2.2.8 MAC Address Blocks 571 If the TLV Type is 8, the value is a list of blocks of MAC addresses 572 as follows: 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Type = 8 | Length | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | MAC.start 1 upper half | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | MAC.start 1 lower half | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | MAC.end 1 upper half | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | MAC.end 1 lower half | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | MAC.start 2 upper half | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | MAC.start 2 lower half | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | MAC.end 2 upper half | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | MAC.end 2 lower half | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | MAC.start ... upper half | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | MAC.start ... lower half | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | MAC.end ... upper half | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | MAC.end ... lower half | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 The TLV value consists of sets of Start.MAC and End.MAC numbers. The 603 Address Flush information applies to the 48-bit MAC Addresses in that 604 range, inclusive. A single MAC Address is indicated by setting both 605 Start.MAC and End.MAC to the same value. If End.MAC is less than 606 Start.MAC, considering them as unsigned integers, that block is 607 ignored but the Address Flush message is still processed for any 608 other blocks present. For this Type, Length MUST be a multiple of 12; 609 if it is not, the TLV is corrupt and the Address Flush message MUST 610 be discarded if the receiving RBridge implements Type 7. 612 3. IANA Considerations 614 Two IANA actions are requested as follows: 616 3.1 Address Flush RBridge Channel Protocol Number 618 IANA is requested to assign TBD as the Address Flush RBridge Channel 619 Protocol number from the range of RBridge Channel protocols allocated 620 by Standards Action [RFC7178]. 622 The added RBridge Channel protocols registry entry on the TRILL 623 Parameters web page is as follows: 625 Protocol Description Reference 626 -------- -------------- ------------------ 627 TBD Address Flush [this document] 629 3.2 TRILL Address Flush TLV Types 631 IANA is requested to create a TRILL Address Flush TLV Types registry 632 on the TRILL Parameters web page indented after the RBridge Channel 633 Protocols registry. Registry headers are as below. The initial 634 entries are as in the table in Section 2.2 above. 636 Registry: TRILL Address Flush TLV Types 637 Registration Procedures: IETF Review 638 Reference: [this document] 640 4. Security Considerations 642 The Address Flush RBridge Channel Protocol itself provides no 643 security assurances or features. However, Address Flush protocol 644 messages can be secured by use of the RBridge Channel Header 645 Extension [RFC7978]. It is RECOMMENDED that all RBridges that 646 implement the address flush message be configured to ignore such 647 messages unless they have been secured with an RBridge Channel Header 648 Extension that meets local security policy. 650 If RBridges receiving Address Flush messages do not require them to 651 be at least authenticated, they are relatively easy to forge. In that 652 case, such forged Address Flush messages can reduce network 653 efficiency, by purging useful learned information that will have to 654 be re-learned. This provides a denial of service attack but cannot 655 cause incorrect operation in the sense that it cannot cause a frame 656 to be improperly delivered. 658 See [RFC7178] for general RBridge Channel Security Considerations. 660 See [RFC6325] for general TRILL Security Considerations. 662 Normative References 664 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, March 1997. 667 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 668 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 669 July 2011. 671 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 672 and D. Dutt, "Transparent Interconnection of Lots of Links 673 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 674 10.17487/RFC7172, May 2014, . 677 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 678 Ward, "Transparent Interconnection of Lots of Links (TRILL): 679 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 680 2014, . 682 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 683 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 684 Lots of Links (TRILL): Clarifications, Corrections, and 685 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 686 . 688 [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 689 Interconnection of Lots of Links (TRILL): RBridge Channel 690 Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 691 2016, . 693 Informative References 695 [RFC4762] - Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 696 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 697 Signaling", RFC 4762, January 2007. 699 Acknowledgements 701 The following are thanked for their contributions: 703 Ramkumar Parameswaran, Henning Rogge 705 The document was prepared in raw nroff. All macros used were defined 706 within the source file. 708 Authors' Addresses 710 Weiguo Hao 711 Huawei Technologies 712 101 Software Avenue, 713 Nanjing 210012, China 715 Phone: +86-25-56623144 716 Email: haoweiguo@huawei.com 718 Donald E. Eastlake, 3rd 719 Huawei Technologies 720 155 Beaver Street 721 Milford, MA 01757 USA 723 Phone: +1-508-333-2270 724 EMail: d3e3e3@gmail.com 726 Yizhou Li 727 Huawei Technologies 728 101 Software Avenue, 729 Nanjing 210012 730 China 732 Phone: +86-25-56624629 733 Email: liyizhou@huawei.com 735 Mohammed Umair 736 Cisco 737 Cessna Business Park, Kadubeesanahalli Village, Hobli, 738 Sarjapur, Varthur Main Road, Marathahalli, 739 Bengaluru, Karnataka 560087 India 741 Email: mohammed.umair2@gmail.com 743 Copyright, Disclaimer, and Additional IPR Provisions 745 Copyright (c) 2018 IETF Trust and the persons identified as the 746 document authors. All rights reserved. 748 This document is subject to BCP 78 and the IETF Trust's Legal 749 Provisions Relating to IETF Documents 750 (http://trustee.ietf.org/license-info) in effect on the date of 751 publication of this document. Please review these documents 752 carefully, as they describe your rights and restrictions with respect 753 to this document. Code Components extracted from this document must 754 include Simplified BSD License text as described in Section 4.e of 755 the Trust Legal Provisions and are provided without warranty as 756 described in the Simplified BSD License. The definitive version of 757 an IETF Document is that published by, or under the auspices of, the 758 IETF. Versions of IETF Documents that are published by third parties, 759 including those that are translated into other languages, should not 760 be considered to be definitive versions of IETF Documents. The 761 definitive version of these Legal Provisions is that published by, or 762 under the auspices of, the IETF. Versions of these Legal Provisions 763 that are published by third parties, including those that are 764 translated into other languages, should not be considered to be 765 definitive versions of these Legal Provisions. For the avoidance of 766 doubt, each Contributor to the IETF Standards Process licenses each 767 Contribution that he or she makes as part of the IETF Standards 768 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 769 language to the contrary, or terms, conditions or rights that differ 770 from or are inconsistent with the rights and licenses granted under 771 RFC 5378, shall have any effect and shall be null and void, whether 772 published or posted by such Contributor, or included with or in such 773 Contribution.