idnits 2.17.1 draft-ietf-trill-address-flush-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 12) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2017) is 2646 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 IPinfusion 7 Expires: July 26, 2017 January 26, 2017 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 an originating TRILL 22 switch can explicitly request other TRILL switches to flush certain 23 MAC reachability learned through the decapsulation of TRILL Data 24 packets. This is a supplement to the TRILL automatic address 25 forgetting and can assist in achieving more rapid convergence in case 26 of topology or 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........................................12 62 2.2.5 Big Map of FGLs.....................................13 63 2.2.6 All Data Labels.....................................13 64 2.2.7 MAC Address List....................................14 65 2.2.8 MAC Address Blocks..................................14 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 78 Authors' Addresses........................................19 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. For example, in the case 98 of topology change or reconfiguration in a bridged network attached 99 to multiple edge RBridges. Section 6.2 of [RFC4762] is another 100 example of use of such a mechanism. 102 A TRILL switch R1 can easily flush any locally learned addresses it 103 wants. This document specifies an RBridge Channel protocol [RFC7178] 104 message to request flushing address information learned from 105 decapsulating at remote RBridges. 107 1.1 Terminology and Acronyms 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 This document uses the terms and acronyms defined in [RFC6325] and 114 [RFC7978] as well as the following: 116 Data Label - VLAN or FGL. 118 Edge TRILL switch - A TRILL switch attached to one or more links 119 that provide end station service. 121 FGL - Fine Grained Label [RFC7172]. 123 Management VLAN - A VLAN in which all TRILL switches in a campus 124 indicate interest so that multi-destination TRILL Data packets, 125 including RBridge Channel messages [RFC7978], sent with that 126 VLAN as the Inner.VLAN will be delivered to all TRILL switches 127 in the campus. Usually no end station service is offered in the 128 Management VLAN. 130 RBridge - An alternative name for a TRILL switch. 132 TRILL switch - A device implementing the TRILL protocol. 134 2. Address Flush Message Details 136 The Address Flush message is an RBridge Channel protocol message 137 [RFC7178]. 139 The general structure of an RBridge Channel packet on a link between 140 TRILL switches is shown in Figure 1 below. The Protocol field in the 141 RBridge Channel Header gives the type of RBridge Channel packet that 142 indicates how to interpret the Channel Protocol Specific Payload 143 [RFC7178]. 145 +----------------------------------+ 146 | Link Header | 147 +----------------------------------+ 148 | TRILL Header | 149 +----------------------------------+ 150 | Inner Ethernet Addresses | 151 +----------------------------------+ 152 | Data Label (VLAN or FGL) | 153 +----------------------------------+ 154 | RBridge Channel Header | 155 +----------------------------------+ 156 | Channel Protocol Specific Payload| 157 +----------------------------------+ 158 | Link Trailer (FCS if Ethernet)| 159 +----------------------------------+ 161 Figure 1. RBridge Channel Protocol Message Structure 163 An Address Flush RBridge Channel message by default applies to 164 addresses within the Data Label that appears right after the Inner 165 Ethernet Addresses. Address Flush protocol messages are usually sent 166 as multi-destination packets (TRILL Header M bit equal to one) so as 167 to reach all TRILL switches offering end station service in the VLAN 168 or FGL specified by that Data Label. Such messages SHOULD be sent at 169 priority 6 since they are important control messages but lower 170 priority than control messages that establish or maintain adjacency. 172 Nevertheless: 173 - There are provisions for optionally indicating the Data Label(s) 174 to be flushed for cases where the Address Flush message is sent 175 over a Management VLAN or the like. 176 - An Address Flush message can be sent unicast, if it is desired to 177 clear addresses at one TRILL switch only. 179 2.1 VLAN Block Only Case 181 Figure 2 below expands the RBridge Channel Header and Channel 182 Protocol Specific Payload from Figure 1 for the case of the VLAN only 183 based Address Flush message. This form of the Address Flush message 184 is optimized for flushing MAC addressed based on nickname and blocks 185 of VLANs. 187 0 1 2 3 188 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 189 RBridge Channel Header: 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Flags | ERR | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Address Flush Protocol Specific: 196 +-+-+-+-+-+-+-+-+ 197 | K-nicks | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Nickname 1 | Nickname 2 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Nickname ... | Nickname K-nicks | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | K-VLBs | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | RESV | Start.VLAN 1 | RESV | End.VLAN 1 | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | RESV | Start.VLAN 2 | RESV | End.VLAN 2 | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | RESV | Start.VLAN ... | RESV | End.VLAN ... | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | RESV | Start.VLAN K-VLBs | RESV | End.VLAN K-VLBs | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 2. Address Flush Message - VLAN Case 216 The fields in Figure 2 related to the Address Flush message are as 217 follows: 219 Channel Protocol: The RBridge Channel Protocol value allocated 220 for Address Flush (see Section 3). 222 K-nicks: K-nicks is the number of nicknames listed as an unsigned 223 integer. If this is zero, the ingress nickname in the TRILL 224 Header [RFC6325] is considered to be the only nickname to which 225 the message applies. If non-zero, it given the number of 226 nicknames listed right after K-nicks to which the message 227 applies and, in this non-zero case, the flush does not apply to 228 the ingress nickname in the TRILL Header unless it is also 229 listed. The messages flushes address learning due to egressing 230 TRILL Data packets that had an ingress nickname to which the 231 message applies. 233 Nickname: A listed nickname to which it is intended that the 234 Address Flush message apply. If an unknown or reserved 235 nickname occurs in the list, it is ignored but the address 236 flush operation is still executed with the other nicknames. If 237 an incorrect nickname occurs in the list, so some address 238 learning is flushed that should not have been flush, the 239 network will still operate correctly but will be less efficient 240 as the incorrectly flushed learning is re-learned. 242 K-VLBs: K-VLBs is the number of VLAN blocks present as an unsigned 243 integer. If this byte is zero, the message is the more general 244 format specified in Section 2.2. If it is non-zero, it gives 245 the number of blocks of VLANs present. 247 RESV: 4 reserved bits. MUST be sent as zero and ignored on 248 receipt. 250 Start.VLAN, End.VLAN: These 12-bit fields give the beginning and 251 ending VLAN IDs of a block of VLANs. The block includes both 252 the starting and ending values so a block of size one is 253 indicated by setting End.VLAN equal to Start.VLAN. If 254 Start.VLAN is 0x000, it is treated as if it was 0x001. If 255 End.VLAN is 0xFFF, it is treated as if it was 0xFFE. If 256 End.VLAN is smaller than Start.VLAN, considering both as 257 unsigned integers, that VLAN block is ignored but the address 258 flush operation is still executed with other VLAN blocks in the 259 message. 261 This message flushes all addresses in an applicable VLAN learned from 262 egressing TRILL Data packets with an applicable nickname as ingress. 263 To flush addresses for all VLANs, it is easy to specify a block 264 covering all valid VLAN IDs, this is, from 0x001 to 0xFFE. 266 2.2 Extensible Case 268 A more general form of the Address Flush message is provided to 269 support flushing by FGL and more efficient encodings of VLANs and 270 FGLs where using a set of contiguous blocks if cumbersome. It also 271 supports optionally specifying the MAC addresses to clear. This form 272 is extensible. 274 It is indicated by a zero in the byte shown in Figure 2 as "K-VLBs" 275 followed by other information encoded as TLVs. 277 0 1 2 3 278 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 279 RBridge Channel Header: 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Flags | ERR | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Address Flush Protocol Specific: 286 +-+-+-+-+-+-+-+-+ 287 | K-nicks | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Nickname 1 | Nickname 2 | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Nickname ... | Nickname K-nicks | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | 0 | TLVs ... 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 296 Figure 3. Address Flush Message - Extensible Case 298 Channel Protocol, K-nicks, Nickname: These fields are as specified 299 in Section 2.1. 301 TLVs: If the byte immediately before the TLVs field, which is the 302 byte labeled "K-VLBs" in Figure 2, is zero, as shown in Figure 303 3, the remainder of the message consists of TLVs encoded as 304 shown in Figure 4. 306 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 308 | Type | Length | Value 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 311 Figure 4. Type, Length, Value 313 Type: The 8 bit TLV type as shown in the table below. See 314 subsections of this Section 2.2 for details on each type 315 assigned below. If the type is reserved or not known by a 316 receiving RBridge, that receiving RBridge ignores the value and 317 can easily skip to the next TLV by use of the Length byte. 318 There is no provision for a list of VLAN IDs TLV as there are 319 few enough of them that an arbitrary subset of VLAN IDs can be 320 represented as a bit map. 322 Type Description Reference 323 ------ ------------------ ----------------- 324 0 Reserved [this document] 325 1 Blocks of VLANs [this document] 326 2 Bit Map of VLANs [this document] 327 3 Blocks of FGLs [this document] 328 4 List of FGLs [this document] 329 5 Bit Map of FGLs [this document] 330 6 All Data Labels [this document] 331 7 MAC Address List [this document] 332 8 MAC Address Blocks [this document] 333 9-254 Unassigned 334 255 Reserved [this document] 336 RBridges that implement the Address Flush message 338 Length: The 8-bit unsigned integer length of the remaining 339 information in the TLV after the length byte. The length MUST 340 NOT imply that the value extends beyond the end of RBridge 341 Channel Protocol Specific Payload area. If it does, the Address 342 Flush message is corrupt and MUST be ignored. 344 Value: Depends on the TLV type. 346 The TLVs in an extensible Address Flush message are parsed with types 347 unknown by the receiving RBridge ignored. 349 The processing requirements based on support for Address Flush 350 Channel message plus the additional types: 352 Basic RBridges functionality: All RBridges supporting the Address 353 Flush Channel message MUST implement type 1 (Blocks of VLANs), 354 type 2 (Bit map of VLANs), and type 6 (All Data labels). Type 6 355 indicates that all addresses are to be flushed for all data labels. 357 Optional RBridges functionality: RBridges SHOULD implement types 7 358 and type 8 so that specific MAC addresses can be can be flushed. 359 If a set of RBridges does not implement types 7 and 8, the flush 360 will be inefficient as those not intent to be flashed will have to 361 be relearned. 363 FGL functionality : All RBridges implementing the FGL ingress/egress 364 support and the Address Flush Channel message MUST implement 365 type 3 (Blocks of FGLs), type 4 (Lists of FGLs), 366 and type 5 (Bit Map of FGL). An RBridge that is merely FGL 367 safe [RFC7172], but cannot egress TRILL data packets, SHOULD ignore 368 the FGL types with the Address Flush Channel message as it will not 369 learn any MAC addresses with FGL scope from the MAC data plane. 371 The parsing of the TLVs in an Rbridge Channel Message in the Address 372 Flush Protocol Specific TLVS by a receiving bridge results in three 373 items: 375 1) A flag indicating whether one or more types 376 6 TLVs (All Data Labels) were encountered. 377 2) A set of Data labels and blocks of data labels compiled from 378 VLAN TLVs (types 1 and 2), and/or FGL TLVs (types 3, 4, and 5). 379 3) If a MAC TLVs types (type 6 and 7) are implemented, a set of 380 MAC addresses and Blocks of MAC addresses from the MAC TLVs. 382 For the following flag settings, the processing is as follows: 383 a) If the set of MAC addresses and Block of MAC address is null 384 (item 3 above) then Address Flush applies to all messages. 385 b) If the All-Data-label-found flag (item 1 above) is true, 386 then the address flush message applies to all data labels. 387 The set of Data label and block of data labels (item 2 above) 388 does not have any effect. 389 c) If the All-Data-label-found flag (item 1 above) is false, then 390 the Address Flush message applies to the set of 391 Data labels (see item 2 above) found in VLAn 392 TLVs (types 1 and 2), and/or FGLs TLVS (types 3, 4, and 5). 393 If the set of Data Labels (see item 2 above) is null, the 394 Address Flush message does nothing. 396 2.2.1 Blocks of VLANs 398 If the TLV Type is 1, the value is a list of blocks of VLANs as 399 follows: 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type = 1 | Length | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | RESV | Start.VLAN 1 | RESV | End.VLAN 1 | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | RESV | Start.VLAN 2 | RESV | End.VLAN 2 | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | RESV | Start.VLAN ... | RESV | End.VLAN ... | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 The meaning of Start.VLAN and End.VLAN is as specified in Section 412 2.1. Length MUST be a multiple of 4. If Length is not a multiple of 413 4, the TLV is corrupt and the Address Flush message MUST be ignored. 415 2.2.2 Bit Map of VLANs 417 If the TLV Type is 2, the value is a bit map of VLANs as follows: 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type = 2 | Length | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 422 | RESV | Start.VLAN | Bits... 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 425 The value portion of the TLV begins with two bytes having the 12-bit 426 starting VLAN ID right justified (the top 4 bits are as specified in 427 Section 2.1 RESV). This is followed by bytes with one bit per VLAN 428 ID. The high order bit of the first byte is for VLAN N, the next to 429 the highest order bit is for VLAN N+1, the low order bit of the first 430 byte is for VLAN N+7, the high order bit of the second byte, if there 431 is a second byte, is for VLAN N+8, and so on. If that bit is a one, 432 the Address Flush message applies to that VLAN. If that bit is a 433 zero, then addresses that have been learned in that VLAN are not 434 flushed. Note that Length MUST be at least 2. If Length is 0 or 1 435 the TLV is corrupt and the Address Flush message MUST be ignored. 437 VLAN IDs do not wrap around. If there are enough bytes so that some 438 bits correspond to VLAN ID 0xFFF or higher, those bits are ignored 439 but the message is still processed for bits corresponding to valid 440 VLAN IDs. 442 2.2.3 Blocks of FGLs 444 If the TLV Type is 3, the value is a list of blocks of FGLs as 445 follows: 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Type = 3 | Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Start.FGL 1 | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | End.FGL 1 | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Start.FGL 2 | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | End.FGL 2 | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Start.FGL ... | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | End.FGL ... | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 The TLV value consists of sets of Start.FGL and End.FGL numbers. The 464 Address Flush information applies to the FGLs in that range, 465 inclusive. A single FGL is indicated by setting both Start.FGL and 466 End.FGL to the same value. If End.FGL is less than Start.FGL, 467 considering them as unsigned integers, that block is ignored but the 468 Address Flush message is still processed for any other blocks 469 present. For this Type, Length MUST be a multiple of 6; if it is not, 470 the TLV is corrupt and the Address Flush message MUST be discarded if 471 the receiving RBridge implements Type 3. 473 2.2.4 list of FGLs 475 If the TLV Type is 4, the value is a list of FGLs as follows: 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type = 4 | Length | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | FGL 1 | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | FGL 2 | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | FGL ... | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 The TLV value consists of FGL numbers each in 3 bytes. The Address 488 Flush message applies to those FGLs. For this Type, Length MUST be a 489 multiple of 3; if it is not, the TLV is corrupt and the address flush 490 Message MUST be discarded if the receiving RBridge implements Type 4. 492 2.2.5 Big Map of FGLs 494 If the TLV Type is 5, the value is a bit map of FGLs as follows: 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type = 5 | Length | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Start.FGL | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Bits... 502 +-+-+-+-+-+-+-+- 504 The TLV value consists of three bytes with the 24-bit starting FGL 505 value N. This is followed by bytes with one bit per FGL. The high 506 order bit of the first byte is for FGL N, the next to the highest 507 order bit is for FGL N+1, the low order bit of the first byte is for 508 FGL N+7, the high order bit of the second byte, if there is a second 509 byte, is for FGL N+8, and so on. If that bit is a one, the Address 510 Flush message applies to that FGL. If that bit is a zero, then 511 addresses that have been learned in that FGL are not flushed. Note 512 that Length MUST be at least 3. If Length is 0, 1, or 2 for a Type 5 513 TLV, the TLV is corrupt and the Address Flush message MUST be 514 discarded. FGLs do not wrap around. If there are enough bytes so 515 that some bits correspond to an FGL higher than 0xFFFFFF, those bits 516 are ignored but the message is still processed for bits corresponding 517 to valid FGLs. 519 2.2.6 All Data Labels 521 If the TLV Type is 6, the value is null as follows: 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Type = 6 | Length = 0 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 This type is used when a RBridge want to withdraw all Address for all 528 the Data Labels (all VLANs and FGLs), Length MUST be zero. If Length 529 is any other value, the TLV is corrupt and the Address Flush message 530 MUST be ignored. 532 2.2.7 MAC Address List 534 If the TLV Type is 7, the value is a list of MAC addresses as 535 follows: 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type = 7 | Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | MAC 1 upper half | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | MAC 1 lower half | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | MAC 2 upper half | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | MAC 2 lower half | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | MAC ... upper half | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | MAC ... lower half | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 The TLV value consists of a list of 48-bit MAC addresses. Length MUST 554 be a multiple of 6. If it is not, the TLV is corrupt and the Address 555 Flush message MUST be ignored if the receiving RBridge implements 556 Type 7. 558 2.2.8 MAC Address Blocks 560 If the TLV Type is 8, the value is a list of blocks of MAC addresses 561 as follows: 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Type = 7 | Length | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | MAC.start 1 upper half | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | MAC.start 1 lower half | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | MAC.end 1 upper half | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | MAC.end 1 lower half | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | MAC.start 2 upper half | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | MAC.start 2 lower half | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | MAC.end 2 upper half | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | MAC.end 2 lower half | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | MAC.start ... upper half | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | MAC.start ... lower half | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | MAC.end ... upper half | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | MAC.end ... lower half | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 The TLV value consists of sets of Start.MAC and End.MAC numbers. The 592 Address Flush information applies to the 48-bit MAC Addresses in that 593 range, inclusive. A single MAC Address is indicated by setting both 594 Start.MAC and End.MAC to the same value. If End.MAC is less than 595 Start.MAC, considering them as unsigned integers, that block is 596 ignored but the Address Flush message is still processed for any 597 other blocks present. For this Type, Length MUST be a multiple of 12; 598 if it is not, the TLV is corrupt and the Address Flush message MUST 599 be discarded if the receiving RBridge implements Type 7. 601 3. IANA Considerations 603 Two IANA actions are requested as follows: 605 3.1 Address Flush RBridge Channel Protocol Number 607 IANA is requested to assign TBD as the Address Flush RBridge Channel 608 Protocol number from the range of RBridge Channel protocols allocated 609 by Standards Action [RFC7178]. 611 The added RBridge Channel protocols registry entry on the TRILL 612 Parameters web page is as follows: 614 Protocol Description Reference 615 -------- -------------- ------------------ 616 TBD Address Flush [this document] 618 3.2 TRILL Address Flush TLV Types 620 IANA is requested to create a TRILL Address Flush TLV Types registry 621 on the TRILL Parameters web page indented right after the RBridge 622 Channel Protocols registry. Registry headers are as below. The 623 initial entries are as in the table in Section 2.2 above. 625 Registry: TRILL Address Flush TLV Types 626 Registration Procedures: IETF Review 627 Reference: [this document] 629 4. Security Considerations 631 The Address Flush RBridge Channel Protocol provides no security 632 assurances or features. However, the Address Flush protocol messages 633 can be secured by use of the RBridge Channel Header Extension 634 [RFC7978]. 636 See [RFC7178] for general RBridge Channel Security Considerations. 638 See [RFC6325] for general TRILL Security Considerations. 640 Normative References 642 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, March 1997. 645 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 646 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 647 July 2011. 649 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 650 and D. Dutt, "Transparent Interconnection of Lots of Links 651 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 652 10.17487/RFC7172, May 2014, . 655 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 656 Ward, "Transparent Interconnection of Lots of Links (TRILL): 657 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 658 2014, . 660 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 661 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 662 Lots of Links (TRILL): Clarifications, Corrections, and 663 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 664 . 666 [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 667 Interconnection of Lots of Links (TRILL): RBridge Channel 668 Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 669 2016, . 671 Informative References 673 [RFC4762] - Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 674 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 675 Signaling", RFC 4762, January 2007. 677 Acknowledgements 679 The following are thanked for their contributions: 681 Henning Rogge 683 The document was prepared in raw nroff. All macros used were defined 684 within the source file. 686 Authors' Addresses 688 Weiguo Hao 689 Huawei Technologies 690 101 Software Avenue, 691 Nanjing 210012, China 693 Phone: +86-25-56623144 694 Email: haoweiguo@huawei.com 696 Donald E. Eastlake, 3rd 697 Huawei Technologies 698 155 Beaver Street 699 Milford, MA 01757 USA 701 Phone: +1-508-333-2270 702 EMail: d3e3e3@gmail.com 704 Yizhou Li 705 Huawei Technologies 706 101 Software Avenue, 707 Nanjing 210012 708 China 710 Phone: +86-25-56624629 711 Email: liyizhou@huawei.com 713 Mohammed Umair 714 IPinfusion 715 RMZ Centennial Mahadevapura Post 716 Bangalore, 560048 India 718 Email: mohammed.umair2@gmail.com 720 Copyright, Disclaimer, and Additional IPR Provisions 722 Copyright (c) 2016 IETF Trust and the persons identified as the 723 document authors. All rights reserved. 725 This document is subject to BCP 78 and the IETF Trust's Legal 726 Provisions Relating to IETF Documents 727 (http://trustee.ietf.org/license-info) in effect on the date of 728 publication of this document. Please review these documents 729 carefully, as they describe your rights and restrictions with respect 730 to this document. Code Components extracted from this document must 731 include Simplified BSD License text as described in Section 4.e of 732 the Trust Legal Provisions and are provided without warranty as 733 described in the Simplified BSD License. The definitive version of 734 an IETF Document is that published by, or under the auspices of, the 735 IETF. Versions of IETF Documents that are published by third parties, 736 including those that are translated into other languages, should not 737 be considered to be definitive versions of IETF Documents. The 738 definitive version of these Legal Provisions is that published by, or 739 under the auspices of, the IETF. Versions of these Legal Provisions 740 that are published by third parties, including those that are 741 translated into other languages, should not be considered to be 742 definitive versions of these Legal Provisions. For the avoidance of 743 doubt, each Contributor to the IETF Standards Process licenses each 744 Contribution that he or she makes as part of the IETF Standards 745 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 746 language to the contrary, or terms, conditions or rights that differ 747 from or are inconsistent with the rights and licenses granted under 748 RFC 5378, shall have any effect and shall be null and void, whether 749 published or posted by such Contributor, or included with or in such 750 Contribution.