idnits 2.17.1 draft-hao-trill-address-flush-01.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 21, 2016) is 2959 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 Expires: September 20, 2015 March 21, 2016 7 TRILL: Address Flush Message 8 10 Abstract 12 The TRILL (TRansparent Interconnection of Lots of Links) protocol, by 13 default, learns end station addresses from observing the data plane. 14 This document specifies a message by which an originating TRILL 15 switch can explicitly request other TRILL switches to flush certain 16 MAC reachability learned through the egress of TRILL Data packets. 17 This is a supplement to the TRILL automatic address forgetting and 18 can assist in achieving more rapid convergence in case of topoogy or 19 configuration change. 21 Status of This Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Distribution of this document is unlimited. Comments should be sent 27 to the TRILL working group mailing list: trill@ietf.org. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 41 Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Table of Contents 46 1. Introduction............................................3 47 1.1 Terminology and Acronyms...............................3 49 2. Address Flush Message Details...........................5 50 2.1 VLAN Block Case........................................6 51 2.2 Extensible Case........................................7 53 3. IANA Considerations....................................11 54 4. Security Considerations................................11 56 Normative References......................................12 57 Informative References....................................12 58 Acknowledgements..........................................12 60 Authors' Addresses........................................13 62 1. Introduction 64 Edge TRILL (Transparent Interconnection of Lots of Links) switches 65 [RFC6325] [RFC7780], also called edge RBridges, by default learn end 66 station MAC address reachability from observing the data plane. On 67 receipt of a native frame from an end station, they would learn the 68 local MAC address attachment of the source end station. And on 69 egressing (decapsulating) a remotely originated TRILL Data packet, 70 they learn the remote MAC address and remote attachment TRILL switch. 71 Such learning is all scoped by data label (VLAN or Fine Grained Label 72 [RFC7172]). 74 TRILL has mechanisms for timing out such learning and appropriately 75 clearing it based on some network connectivity and configuration 76 changes; however, there are circumstances under which it would be 77 helpful for a TRILL switch to be able to explicitly flush (purge) 78 certain learned end station reachability information in remote 79 RBridges to achieve more rapid convergence (see, for example, 80 [TCaware] and Section 6.2 of [RFC4762]). 82 A TRILL switch R1 can easily flush any locally learned addresses it 83 wants. This document specifies an RBridge Channel protocol [RFC7178] 84 message to request flushing address information learned from 85 decapsulating at remote RBridges. 87 1.1 Terminology and Acronyms 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 This document uses the terms and acronyms defined in [RFC6325] and 94 [ChannelTunnel] as well as the following: 96 Data Label - VLAN or FGL. 98 Edge TRILL switch - A TRILL switch attached to one or more links 99 that provide end station service. 101 FGL - Fine Grained Label [RFC7172]. 103 Management VLAN - A VLAN in which all TRILL switches in a campus 104 indicate interest so that multi-destinaiton TRILL Data packets, 105 including RBridge Channel messages [ChannelTunnel], sent with 106 that VLAN as the Inner.VLAN will be delivered to all TRILL 107 switches in the campus. Usually no end station service is 108 offered in the Management VLAN. 110 RBridge - A alterntive name for a TRILL switch. 112 TRILL switch - A device implementing the TRILL protocol. 114 2. Address Flush Message Details 116 The Address Flush message is an RBridge Channel protocol message 117 [RFC7178]. 119 The general structure of an RBridge Channel packet on a link between 120 TRILL switches is shown in Figure 1 below. The type of RBridge 121 Channel packet is given by the Protocol field in the RBridge Channel 122 Header that indicates how to interpret the Channel Protocol Specific 123 Payload [RFC7178]. 125 +----------------------------------+ 126 | Link Header | 127 +----------------------------------+ 128 | TRILL Header | 129 +----------------------------------+ 130 | Inner Ethernet Addresses | 131 +----------------------------------+ 132 | Data Label (VLAN or FGL) | 133 +----------------------------------+ 134 | RBridge Channel Header | 135 +----------------------------------+ 136 | Channel Protocol Specific Payload| 137 +----------------------------------+ 138 | Link Trailer (FCS if Ethernet)| 139 +----------------------------------+ 141 Figure 1. RBridge Channel Protocol Message Structure 143 An Address Flush RBridge Channel message by default applies to 144 addresses within the Data Label in the TRILL Header. Address Flush 145 protocol messages are usually sent as multi-destination packets 146 (TRILL Header M bit equal to one) so as to reach all TRILL switches 147 offering end station service in the VLAN or FGL specified by the Data 148 Label. Such messages SHOULD be sent at priority 6 since they are 149 important control messages but lower priority than control messages 150 that establish or maintain adjacency. 152 Nevertheless: 153 - There are provisions for optionally indicating the Data Label(s) 154 to be flushed for cases where the Address Flush message is sent 155 over a Managagement VLAN or the like. 156 - An Address Flush message can be sent unicast, if it is desired to 157 clear addresses at one TRILL switch only. 159 2.1 VLAN Block Case 161 Figure 2 below expands the RBridge Channel Header and Channel 162 Protocol Specific Payload from Figure 1 for the case of the VLAN 163 based Address Flush message. This form of the Address Flush message 164 is optimized for flushing MAC addressed based on nickname and blocks 165 of VLANs. 167 0 1 2 3 168 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 169 RBridge Channel Header: 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Flags | ERR | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Address Flush Protocol Specific: 176 +-+-+-+-+-+-+-+-+ 177 | K-nicks | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Nickname 1 | Nickname 2 | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Nickname ... | Nickname K-nicks | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | K-VBs | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | RESV | Start.VLAN 1 | RESV | End.VLAN 1 | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | RESV | Start.VLAN 2 | RESV | End.VLAN 2 | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | RESV | Start.VLAN ... | RESV | End.VLAN ... | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | RESV | Start.VLAN K-VBs | RESV | End.VLAN K-VBs | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 2. Address Flush Message - VLAN Case 196 The fields in Figure 2 related to the Address Flush message are as 197 follows: 199 Channel Protocol: The RBridge Channel Protocol value allocated 200 for Address Flush (see Section 3). 202 K-nicks: K-nicks is the number of nicknames present as an unsigned 203 integer. If this is zero, the ingress nickname in the TRILL 204 Header is considerted to be the only nickname to which the 205 message applies. If non-zero, it given the number of nicknames 206 present to which the message applies. The messages flushes 207 address learning due to egressing TRILL Data packets that had a 208 ingress nicknam to which the message applies. 210 Nickname: A listed nickname to which it is intended that the 211 Address Flush message apply. If an unknown or reserved 212 nickname occurs in the list, it is ignored but the address 213 flush operation is still executed with the other nicknames. If 214 an incorrect nickname occurs in the list, so some address 215 learning is flushed that should not have been flush, the 216 network will strill operate correctly but will be less 217 efficient as the incorrectly flushed learning is re-learned. 219 K-VBs: K-VBs is the number of VLAN blocks present as an unsigned 220 integer. If this byte is zero, the message is the more general 221 format specified in Section 2.2. If it is non-zero, it gives 222 the number of blocks of VLANs present. 224 RESV: 4 reserved bits. MUST be sent as zero and ignored on 225 receipt. 227 Start.VLAN, End.VLAN: These 12-bit fields give the beginning and 228 ending VLAN IDs of a block of VLANs. The block includes both 229 the starting and endiing values so a block of size one is 230 indicated by setting End.VLAN equal to Start.VLAN. If 231 Start.VLAN is 0x000, it is treated as if it was 0x001. If 232 End.VLAN is 0xFFF, it is treated as if it was 0xFFE. If 233 End.VLAN is smaller than Start.VLAN, considering both as 234 unsigned integers, that VLAN block is ignored but the address 235 flush operation is still executed with any other VLAN blocks in 236 the message. 238 This message flushes all addresses learned from egressing TRILL Data 239 packets with an applicable nickname and a VLAN in any of the blocks 240 given. To flush addresses for all VLANs, it is easy to specify a 241 block covering all valid VLAN IDs, this is, from 0x001 to 0xFFE. 243 2.2 Extensible Case 245 A more general form of the Address Flush message is provided to 246 support flushing by FGL and more efficient encodings of VLANs and 247 FGLs where using a set of contiguous blocks if cumbersome. This form 248 is also extensible to handle future requirements. 250 It is indicated by a zero in the byte shown in Figure 2 as "K-VBs". 252 0 1 2 3 253 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 254 RBridge Channel Header: 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Flags | ERR | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Address Flush Protocol Specific: 261 +-+-+-+-+-+-+-+-+ 262 | K-nicks | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Nickname 1 | Nickname 2 | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Nickname ... | Nickname K-nicks | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | 0 | Type | Length | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type Dependent Information 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 273 Figure 3. Address Flush Message - Extensible Case 275 Channel Protocol, K-nicks, Nickname: These fields are as specified 276 in Section 2.1. 278 Type: If the byte immediately before the Type field, which is the 279 byte labeled "K-VBs" in Figure 2, is zero, the the Type byte 280 indicates the type of extended Address Flush message as 281 follows: 283 Type Description 284 ------ ------------ 285 0 Reserved 286 1 Bit Map of VLANs 287 2 Blocks of FGLs 288 3 List of FGLs 289 4 Bit Map of FGLs 290 5-254 Unassigned 291 255 Reserved 293 Length: The length of the remaining information in the Address 294 Flush message. 296 Type Dependent Information: Depends on the value of the type field 297 as further specified below in this section. 299 Type 1 300 Bit Map of VLANs: The Type Dependent Information consists of two 301 bytes with the 12-bit starting VLAN ID N right justified (the top 302 4 bits are as specified above for RESV). This is followed by bytes 303 with one bit per VLAN ID. The high order bit of the first byte is 304 for VLAN N, the next to the highest order bit is for VLAN N+1, the 305 low order bit of the first byte is for VLAN N+7, the high order 306 bit of the second byte, if there is a second byte, is for VLAN 307 N+8, and so on. If that bit is a one, the the Address Flush 308 message applies to that VLAN. If that bit is a zero, then 309 addresses that have been learned in that VLAN are not flushed. 310 Note that Length MUST be at least 3. If Length is 0, 1, or 2 for a 311 Type 1 extended Address Flush message, the message is corrupt and 312 MUST be discarded. VLAN IDs do not wrap around. If there are 313 enough bytes so that some bits correspond to VLAN ID 0xFFF or 314 nigher, those bits are ignored but the message is still processed 315 for bits corresponding to valid VLAN IDs. 317 Type 2 318 Blocks of FGLs: The Type Dependent Information consists of sets of 319 Start.FGL and End.FGL numbers. The Address Flush information 320 applies to the FGLs in that range, incluse. A single FGL is 321 indicated by have both Start.FGL and End.FGL to the same value. If 322 End.FGL is less than Start.FGL, considering them as unsigned 323 integers, that block is ignored but the Address Flush message is 324 still processed for any other blocks present. For this Type, 325 Length MUST be a multiple of 6; if it is not, the message is 326 considered corrup and MUST be discarded. 328 Type 3 329 List of FGLs: The Type Dependent Information consists of FGL numbers 330 each in 3 bytes. The Address Flush message applies to those FGLs. 331 For this Type, Length MUST be a multiple of 3; if it is not, the 332 message is considered corrup and MUST be discarded. 334 Type 4 335 Bit Map of FGLs: The Type Dependent Information consists of three 336 bytes with the 24-bit starting FGL N. This is followed by bytes 337 with one bit per FGL. The high order bit of the first byte is for 338 FGL N, the next to the highest order bit is for FGL N+1, the low 339 order bit of the first byte is for FGL N+7, the high order bit of 340 the second byte, if there is a second byte, is for FGL N+8, and so 341 on. If that bit is a one, the the Address Flush message applies to 342 that FGL. If that bit is a zero, then addresses that have been 343 learned in that FGL are not flushed. Note that Length MUST be at 344 least 4. If Length is 0, 1, 2, or 3 for a Type 1 extended Address 345 Flush message, the message is corrupt and MUST be discarded. FGLs 346 do not wrap around. If there are enough bytes so that some bits 347 correspond to an FGL higher than 0xFFFFFF, those bits are ignored 348 but the message is still processed for bits corresponding to valid 349 FGLs. 351 There is no provision for a list of VLAN IDs as there are few enough 352 of them that an arbitrary subset of VLAN IDs can always be 353 represented as a bit map. 355 3. IANA Considerations 357 IANA is requested to assign TBD as the Address Flush RBridge Channel 358 Protocol number from the range of RBridge Channel protocols allocated 359 by Standards Action [RFC7178]. 361 The added RBridge Channel protocols registry entry on the TRILL 362 Parameters web page is as follows: 364 Protocol Description Reference 365 -------- -------------- ------------------ 366 TBD Address Flush [this document] 368 4. Security Considerations 370 The Address Flush RBridge Channel Protocol provides no security 371 assurances or features. However, use of the Address Flush protocol 372 can be nested inside the RBridge Channel Tunnel Protocol 373 [ChannelTunnel] using the RBridge Channel message payload type. The 374 Channel Tunnel protocol can provide security services. 376 See [RFC7178] for general RBridge Channel Security Considerations. 378 See [RFC6325] for general TRILL Security Considerations. 380 Normative References 382 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 386 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 387 July 2011. 389 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 390 and D. Dutt, "Transparent Interconnection of Lots of Links 391 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 392 10.17487/RFC7172, May 2014, . 395 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 396 Ward, "Transparent Interconnection of Lots of Links (TRILL): 397 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 398 2014, . 400 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 401 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 402 Lots of Links (TRILL): Clarifications, Corrections, and 403 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 404 . 406 Informative References 408 [RFC4762] - Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 409 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 410 Signaling", RFC 4762, January 2007. 412 [ChannelTunnel] - Eastlake, D., M. Umair, Y. Li, "TRILL: RBridge 413 Channel Tunnel Protocol", draft-ietf-trill-channel-tunnel, work 414 in progress. 416 [TCaware] - Y. Li, et al., "Aware Spanning Tree Topology Change on 417 RBridges" draft-yizhou-trill-tc-awareness, work-in-progress. 419 Acknowledgements 421 The document was prepared in raw nroff. All macros used were defined 422 within the source file. 424 Authors' Addresses 426 Weiguo Hao 427 Huawei Technologies 428 101 Software Avenue, 429 Nanjing 210012, China 431 Phone: +86-25-56623144 432 Email: haoweiguo@huawei.com 434 Donald E. Eastlake, 3rd 435 Huawei Technologies 436 155 Beaver Street 437 Milford, MA 01757 USA 439 Phone: +1-508-333-2270 440 EMail: d3e3e3@gmail.com 442 Yizhou Li 443 Huawei Technologies 444 101 Software Avenue, 445 Nanjing 210012 446 China 448 Phone: +86-25-56624629 449 Email: liyizhou@huawei.com 451 Copyright, Disclaimer, and Additional IPR Provisions 453 Copyright (c) 2016 IETF Trust and the persons identified as the 454 document authors. All rights reserved. 456 This document is subject to BCP 78 and the IETF Trust's Legal 457 Provisions Relating to IETF Documents 458 (http://trustee.ietf.org/license-info) in effect on the date of 459 publication of this document. Please review these documents 460 carefully, as they describe your rights and restrictions with respect 461 to this document. Code Components extracted from this document must 462 include Simplified BSD License text as described in Section 4.e of 463 the Trust Legal Provisions and are provided without warranty as 464 described in the Simplified BSD License. The definitive version of 465 an IETF Document is that published by, or under the auspices of, the 466 IETF. Versions of IETF Documents that are published by third parties, 467 including those that are translated into other languages, should not 468 be considered to be definitive versions of IETF Documents. The 469 definitive version of these Legal Provisions is that published by, or 470 under the auspices of, the IETF. Versions of these Legal Provisions 471 that are published by third parties, including those that are 472 translated into other languages, should not be considered to be 473 definitive versions of these Legal Provisions. For the avoidance of 474 doubt, each Contributor to the IETF Standards Process licenses each 475 Contribution that he or she makes as part of the IETF Standards 476 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 477 language to the contrary, or terms, conditions or rights that differ 478 from or are inconsistent with the rights and licenses granted under 479 RFC 5378, shall have any effect and shall be null and void, whether 480 published or posted by such Contributor, or included with or in such 481 Contribution.