TRILL Working Group Weiguo Hao INTERNET-DRAFT Donald Eastlake Intended status: Proposed Standard Yizhou Li Huawei Mohammed Umair IPinfusion Expires: July 26, 2017 January 26, 2017 TRILL: Address Flush Message Abstract The TRILL (TRansparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane. In particular, it learns local MAC addresses and edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and edge switch of attachment from the decapsulation of remotely sourced TRILL Data packets. This document specifies a message by which an originating TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets. This is a supplement to the TRILL automatic address forgetting and can assist in achieving more rapid convergence in case of topology or configuration change. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list: trill@ietf.org. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." W. Hao, et al [Page 1] INTERNET-DRAFT Address Flush Message The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. W. Hao, et al [Page 2] INTERNET-DRAFT Address Flush Message Table of Contents 1. Introduction............................................4 1.1 Terminology and Acronyms...............................4 2. Address Flush Message Details...........................6 2.1 VLAN Block Only Case...................................7 2.2 Extensible Case........................................8 2.2.1 Blocks of VLANs.....................................11 2.2.2 Bit Map of VLANs....................................11 2.2.3 Blocks of FGLs......................................12 2.2.4 list of FGLs........................................12 2.2.5 Big Map of FGLs.....................................13 2.2.6 All Data Labels.....................................13 2.2.7 MAC Address List....................................14 2.2.8 MAC Address Blocks..................................14 3. IANA Considerations....................................16 3.1 Address Flush RBridge Channel Protocol Number.........16 3.2 TRILL Address Flush TLV Types.........................16 4. Security Considerations................................17 Normative References......................................18 Informative References....................................18 Acknowledgements..........................................18 Authors' Addresses........................................19 W. Hao, et al [Page 3] INTERNET-DRAFT Address Flush Message 1. Introduction Edge TRILL (Transparent Interconnection of Lots of Links) switches [RFC6325] [RFC7780], also called edge RBridges, by default learn end station MAC address reachability from observing the data plane. On receipt of a native frame from an end station, they would learn the local MAC address attachment of the source end station. And on egressing (decapsulating) a remotely originated TRILL Data packet, they learn the remote MAC address and remote attachment TRILL switch. Such learning is all scoped by data label (VLAN or Fine Grained Label [RFC7172]). TRILL has mechanisms for timing out such learning and appropriately clearing it based on some network connectivity and configuration changes; however, there are circumstances under which it would be helpful for a TRILL switch to be able to explicitly flush (purge) certain learned end station reachability information in remote RBridges to achieve more rapid convergence. For example, in the case of topology change or reconfiguration in a bridged network attached to multiple edge RBridges. Section 6.2 of [RFC4762] is another example of use of such a mechanism. A TRILL switch R1 can easily flush any locally learned addresses it wants. This document specifies an RBridge Channel protocol [RFC7178] message to request flushing address information learned from decapsulating at remote RBridges. 1.1 Terminology and Acronyms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document uses the terms and acronyms defined in [RFC6325] and [RFC7978] as well as the following: Data Label - VLAN or FGL. Edge TRILL switch - A TRILL switch attached to one or more links that provide end station service. FGL - Fine Grained Label [RFC7172]. Management VLAN - A VLAN in which all TRILL switches in a campus indicate interest so that multi-destination TRILL Data packets, including RBridge Channel messages [RFC7978], sent with that VLAN as the Inner.VLAN will be delivered to all TRILL switches in the campus. Usually no end station service is offered in the W. Hao, et al [Page 4] INTERNET-DRAFT Address Flush Message Management VLAN. RBridge - An alternative name for a TRILL switch. TRILL switch - A device implementing the TRILL protocol. W. Hao, et al [Page 5] INTERNET-DRAFT Address Flush Message 2. Address Flush Message Details The Address Flush message is an RBridge Channel protocol message [RFC7178]. The general structure of an RBridge Channel packet on a link between TRILL switches is shown in Figure 1 below. The Protocol field in the RBridge Channel Header gives the type of RBridge Channel packet that indicates how to interpret the Channel Protocol Specific Payload [RFC7178]. +----------------------------------+ | Link Header | +----------------------------------+ | TRILL Header | +----------------------------------+ | Inner Ethernet Addresses | +----------------------------------+ | Data Label (VLAN or FGL) | +----------------------------------+ | RBridge Channel Header | +----------------------------------+ | Channel Protocol Specific Payload| +----------------------------------+ | Link Trailer (FCS if Ethernet)| +----------------------------------+ Figure 1. RBridge Channel Protocol Message Structure An Address Flush RBridge Channel message by default applies to addresses within the Data Label that appears right after the Inner Ethernet Addresses. Address Flush protocol messages are usually sent as multi-destination packets (TRILL Header M bit equal to one) so as to reach all TRILL switches offering end station service in the VLAN or FGL specified by that Data Label. Such messages SHOULD be sent at priority 6 since they are important control messages but lower priority than control messages that establish or maintain adjacency. Nevertheless: - There are provisions for optionally indicating the Data Label(s) to be flushed for cases where the Address Flush message is sent over a Management VLAN or the like. - An Address Flush message can be sent unicast, if it is desired to clear addresses at one TRILL switch only. W. Hao, et al [Page 6] INTERNET-DRAFT Address Flush Message 2.1 VLAN Block Only Case Figure 2 below expands the RBridge Channel Header and Channel Protocol Specific Payload from Figure 1 for the case of the VLAN only based Address Flush message. This form of the Address Flush message is optimized for flushing MAC addressed based on nickname and blocks of VLANs. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 RBridge Channel Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | ERR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Flush Protocol Specific: +-+-+-+-+-+-+-+-+ | K-nicks | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname 1 | Nickname 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname ... | Nickname K-nicks | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K-VLBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Start.VLAN 1 | RESV | End.VLAN 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Start.VLAN 2 | RESV | End.VLAN 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Start.VLAN ... | RESV | End.VLAN ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Start.VLAN K-VLBs | RESV | End.VLAN K-VLBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Address Flush Message - VLAN Case The fields in Figure 2 related to the Address Flush message are as follows: Channel Protocol: The RBridge Channel Protocol value allocated for Address Flush (see Section 3). K-nicks: K-nicks is the number of nicknames listed as an unsigned integer. If this is zero, the ingress nickname in the TRILL Header [RFC6325] is considered to be the only nickname to which the message applies. If non-zero, it given the number of nicknames listed right after K-nicks to which the message applies and, in this non-zero case, the flush does not apply to the ingress nickname in the TRILL Header unless it is also W. Hao, et al [Page 7] INTERNET-DRAFT Address Flush Message listed. The messages flushes address learning due to egressing TRILL Data packets that had an ingress nickname to which the message applies. Nickname: A listed nickname to which it is intended that the Address Flush message apply. If an unknown or reserved nickname occurs in the list, it is ignored but the address flush operation is still executed with the other nicknames. If an incorrect nickname occurs in the list, so some address learning is flushed that should not have been flush, the network will still operate correctly but will be less efficient as the incorrectly flushed learning is re-learned. K-VLBs: K-VLBs is the number of VLAN blocks present as an unsigned integer. If this byte is zero, the message is the more general format specified in Section 2.2. If it is non-zero, it gives the number of blocks of VLANs present. RESV: 4 reserved bits. MUST be sent as zero and ignored on receipt. Start.VLAN, End.VLAN: These 12-bit fields give the beginning and ending VLAN IDs of a block of VLANs. The block includes both the starting and ending values so a block of size one is indicated by setting End.VLAN equal to Start.VLAN. If Start.VLAN is 0x000, it is treated as if it was 0x001. If End.VLAN is 0xFFF, it is treated as if it was 0xFFE. If End.VLAN is smaller than Start.VLAN, considering both as unsigned integers, that VLAN block is ignored but the address flush operation is still executed with other VLAN blocks in the message. This message flushes all addresses in an applicable VLAN learned from egressing TRILL Data packets with an applicable nickname as ingress. To flush addresses for all VLANs, it is easy to specify a block covering all valid VLAN IDs, this is, from 0x001 to 0xFFE. 2.2 Extensible Case A more general form of the Address Flush message is provided to support flushing by FGL and more efficient encodings of VLANs and FGLs where using a set of contiguous blocks if cumbersome. It also supports optionally specifying the MAC addresses to clear. This form is extensible. It is indicated by a zero in the byte shown in Figure 2 as "K-VLBs" followed by other information encoded as TLVs. W. Hao, et al [Page 8] INTERNET-DRAFT Address Flush Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 RBridge Channel Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | ERR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Flush Protocol Specific: +-+-+-+-+-+-+-+-+ | K-nicks | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname 1 | Nickname 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname ... | Nickname K-nicks | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | TLVs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... Figure 3. Address Flush Message - Extensible Case Channel Protocol, K-nicks, Nickname: These fields are as specified in Section 2.1. TLVs: If the byte immediately before the TLVs field, which is the byte labeled "K-VLBs" in Figure 2, is zero, as shown in Figure 3, the remainder of the message consists of TLVs encoded as shown in Figure 4. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 4. Type, Length, Value Type: The 8 bit TLV type as shown in the table below. See subsections of this Section 2.2 for details on each type assigned below. If the type is reserved or not known by a receiving RBridge, that receiving RBridge ignores the value and can easily skip to the next TLV by use of the Length byte. There is no provision for a list of VLAN IDs TLV as there are few enough of them that an arbitrary subset of VLAN IDs can be represented as a bit map. W. Hao, et al [Page 9] INTERNET-DRAFT Address Flush Message Type Description Reference ------ ------------------ ----------------- 0 Reserved [this document] 1 Blocks of VLANs [this document] 2 Bit Map of VLANs [this document] 3 Blocks of FGLs [this document] 4 List of FGLs [this document] 5 Bit Map of FGLs [this document] 6 All Data Labels [this document] 7 MAC Address List [this document] 8 MAC Address Blocks [this document] 9-254 Unassigned 255 Reserved [this document] RBridges that implement the Address Flush message Length: The 8-bit unsigned integer length of the remaining information in the TLV after the length byte. The length MUST NOT imply that the value extends beyond the end of RBridge Channel Protocol Specific Payload area. If it does, the Address Flush message is corrupt and MUST be ignored. Value: Depends on the TLV type. The TLVs in an extensible Address Flush message are parsed with types unknown by the receiving RBridge ignored. The processing requirements based on support for Address Flush Channel message plus the additional types: Basic RBridges functionality: All RBridges supporting the Address Flush Channel message MUST implement type 1 (Blocks of VLANs), type 2 (Bit map of VLANs), and type 6 (All Data labels). Type 6 indicates that all addresses are to be flushed for all data labels. Optional RBridges functionality: RBridges SHOULD implement types 7 and type 8 so that specific MAC addresses can be can be flushed. If a set of RBridges does not implement types 7 and 8, the flush will be inefficient as those not intent to be flashed will have to be relearned. FGL functionality : All RBridges implementing the FGL ingress/egress support and the Address Flush Channel message MUST implement type 3 (Blocks of FGLs), type 4 (Lists of FGLs), and type 5 (Bit Map of FGL). An RBridge that is merely FGL safe [RFC7172], but cannot egress TRILL data packets, SHOULD ignore the FGL types with the Address Flush Channel message as it will not learn any MAC addresses with FGL scope from the MAC data plane. The parsing of the TLVs in an Rbridge Channel Message in the Address Flush Protocol Specific TLVS by a receiving bridge results in three items: W. Hao, et al [Page 10] INTERNET-DRAFT Address Flush Message 1) A flag indicating whether one or more types 6 TLVs (All Data Labels) were encountered. 2) A set of Data labels and blocks of data labels compiled from VLAN TLVs (types 1 and 2), and/or FGL TLVs (types 3, 4, and 5). 3) If a MAC TLVs types (type 6 and 7) are implemented, a set of MAC addresses and Blocks of MAC addresses from the MAC TLVs. For the following flag settings, the processing is as follows: a) If the set of MAC addresses and Block of MAC address is null (item 3 above) then Address Flush applies to all messages. b) If the All-Data-label-found flag (item 1 above) is true, then the address flush message applies to all data labels. The set of Data label and block of data labels (item 2 above) does not have any effect. c) If the All-Data-label-found flag (item 1 above) is false, then the Address Flush message applies to the set of Data labels (see item 2 above) found in VLAn TLVs (types 1 and 2), and/or FGLs TLVS (types 3, 4, and 5). If the set of Data Labels (see item 2 above) is null, the Address Flush message does nothing. 2.2.1 Blocks of VLANs If the TLV Type is 1, the value is a list of blocks of VLANs as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Start.VLAN 1 | RESV | End.VLAN 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Start.VLAN 2 | RESV | End.VLAN 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Start.VLAN ... | RESV | End.VLAN ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The meaning of Start.VLAN and End.VLAN is as specified in Section 2.1. Length MUST be a multiple of 4. If Length is not a multiple of 4, the TLV is corrupt and the Address Flush message MUST be ignored. 2.2.2 Bit Map of VLANs If the TLV Type is 2, the value is a bit map of VLANs as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | RESV | Start.VLAN | Bits... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The value portion of the TLV begins with two bytes having the 12-bit W. Hao, et al [Page 11] INTERNET-DRAFT Address Flush Message starting VLAN ID right justified (the top 4 bits are as specified in Section 2.1 RESV). This is followed by bytes with one bit per VLAN ID. The high order bit of the first byte is for VLAN N, the next to the highest order bit is for VLAN N+1, the low order bit of the first byte is for VLAN N+7, the high order bit of the second byte, if there is a second byte, is for VLAN N+8, and so on. If that bit is a one, the Address Flush message applies to that VLAN. If that bit is a zero, then addresses that have been learned in that VLAN are not flushed. Note that Length MUST be at least 2. If Length is 0 or 1 the TLV is corrupt and the Address Flush message MUST be ignored. VLAN IDs do not wrap around. If there are enough bytes so that some bits correspond to VLAN ID 0xFFF or higher, those bits are ignored but the message is still processed for bits corresponding to valid VLAN IDs. 2.2.3 Blocks of FGLs If the TLV Type is 3, the value is a list of blocks of FGLs as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start.FGL 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End.FGL 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start.FGL 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End.FGL 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start.FGL ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End.FGL ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TLV value consists of sets of Start.FGL and End.FGL numbers. The Address Flush information applies to the FGLs in that range, inclusive. A single FGL is indicated by setting both Start.FGL and End.FGL to the same value. If End.FGL is less than Start.FGL, considering them as unsigned integers, that block is ignored but the Address Flush message is still processed for any other blocks present. For this Type, Length MUST be a multiple of 6; if it is not, the TLV is corrupt and the Address Flush message MUST be discarded if the receiving RBridge implements Type 3. 2.2.4 list of FGLs If the TLV Type is 4, the value is a list of FGLs as follows: W. Hao, et al [Page 12] INTERNET-DRAFT Address Flush Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FGL 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FGL 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FGL ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TLV value consists of FGL numbers each in 3 bytes. The Address Flush message applies to those FGLs. For this Type, Length MUST be a multiple of 3; if it is not, the TLV is corrupt and the address flush Message MUST be discarded if the receiving RBridge implements Type 4. 2.2.5 Big Map of FGLs If the TLV Type is 5, the value is a bit map of FGLs as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start.FGL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bits... +-+-+-+-+-+-+-+- The TLV value consists of three bytes with the 24-bit starting FGL value N. This is followed by bytes with one bit per FGL. The high order bit of the first byte is for FGL N, the next to the highest order bit is for FGL N+1, the low order bit of the first byte is for FGL N+7, the high order bit of the second byte, if there is a second byte, is for FGL N+8, and so on. If that bit is a one, the Address Flush message applies to that FGL. If that bit is a zero, then addresses that have been learned in that FGL are not flushed. Note that Length MUST be at least 3. If Length is 0, 1, or 2 for a Type 5 TLV, the TLV is corrupt and the Address Flush message MUST be discarded. FGLs do not wrap around. If there are enough bytes so that some bits correspond to an FGL higher than 0xFFFFFF, those bits are ignored but the message is still processed for bits corresponding to valid FGLs. 2.2.6 All Data Labels If the TLV Type is 6, the value is null as follows: W. Hao, et al [Page 13] INTERNET-DRAFT Address Flush Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This type is used when a RBridge want to withdraw all Address for all the Data Labels (all VLANs and FGLs), Length MUST be zero. If Length is any other value, the TLV is corrupt and the Address Flush message MUST be ignored. 2.2.7 MAC Address List If the TLV Type is 7, the value is a list of MAC addresses as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC 1 upper half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC 1 lower half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC 2 upper half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC 2 lower half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC ... upper half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC ... lower half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TLV value consists of a list of 48-bit MAC addresses. Length MUST be a multiple of 6. If it is not, the TLV is corrupt and the Address Flush message MUST be ignored if the receiving RBridge implements Type 7. 2.2.8 MAC Address Blocks If the TLV Type is 8, the value is a list of blocks of MAC addresses as follows: W. Hao, et al [Page 14] INTERNET-DRAFT Address Flush Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.start 1 upper half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.start 1 lower half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.end 1 upper half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.end 1 lower half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.start 2 upper half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.start 2 lower half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.end 2 upper half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.end 2 lower half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.start ... upper half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.start ... lower half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.end ... upper half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC.end ... lower half | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TLV value consists of sets of Start.MAC and End.MAC numbers. The Address Flush information applies to the 48-bit MAC Addresses in that range, inclusive. A single MAC Address is indicated by setting both Start.MAC and End.MAC to the same value. If End.MAC is less than Start.MAC, considering them as unsigned integers, that block is ignored but the Address Flush message is still processed for any other blocks present. For this Type, Length MUST be a multiple of 12; if it is not, the TLV is corrupt and the Address Flush message MUST be discarded if the receiving RBridge implements Type 7. W. Hao, et al [Page 15] INTERNET-DRAFT Address Flush Message 3. IANA Considerations Two IANA actions are requested as follows: 3.1 Address Flush RBridge Channel Protocol Number IANA is requested to assign TBD as the Address Flush RBridge Channel Protocol number from the range of RBridge Channel protocols allocated by Standards Action [RFC7178]. The added RBridge Channel protocols registry entry on the TRILL Parameters web page is as follows: Protocol Description Reference -------- -------------- ------------------ TBD Address Flush [this document] 3.2 TRILL Address Flush TLV Types IANA is requested to create a TRILL Address Flush TLV Types registry on the TRILL Parameters web page indented right after the RBridge Channel Protocols registry. Registry headers are as below. The initial entries are as in the table in Section 2.2 above. Registry: TRILL Address Flush TLV Types Registration Procedures: IETF Review Reference: [this document] W. Hao, et al [Page 16] INTERNET-DRAFT Address Flush Message 4. Security Considerations The Address Flush RBridge Channel Protocol provides no security assurances or features. However, the Address Flush protocol messages can be secured by use of the RBridge Channel Header Extension [RFC7978]. See [RFC7178] for general RBridge Channel Security Considerations. See [RFC6325] for general TRILL Security Considerations. W. Hao, et al [Page 17] INTERNET-DRAFT Address Flush Message Normative References [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, July 2011. [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, . [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, . [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, . [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016, . Informative References [RFC4762] - Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. Acknowledgements The following are thanked for their contributions: Henning Rogge The document was prepared in raw nroff. All macros used were defined within the source file. W. Hao, et al [Page 18] INTERNET-DRAFT Address Flush Message Authors' Addresses Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012, China Phone: +86-25-56623144 Email: haoweiguo@huawei.com Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56624629 Email: liyizhou@huawei.com Mohammed Umair IPinfusion RMZ Centennial Mahadevapura Post Bangalore, 560048 India Email: mohammed.umair2@gmail.com W. Hao, et al [Page 19] INTERNET-DRAFT Address Flush Message Copyright, Disclaimer, and Additional IPR Provisions Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. W. Hao, et al [Page 20]