| < draft-ietf-trill-address-flush-00.txt | draft-ietf-trill-address-flush-01.txt > | |||
|---|---|---|---|---|
| TRILL Working Group Weiguo Hao | TRILL Working Group Weiguo Hao | |||
| INTERNET-DRAFT Donald Eastlake | INTERNET-DRAFT Donald Eastlake | |||
| Intended status: Proposed Standard Yizhou Li | Intended status: Proposed Standard Yizhou Li | |||
| Huawei | Huawei | |||
| Expires: November 23, 2015 May 24, 2016 | Mohammed Umair | |||
| IPinfusion | ||||
| Expires: June 5, 2017 December 6, 2016 | ||||
| TRILL: Address Flush Message | TRILL: Address Flush Message | |||
| <draft-ietf-trill-address-flush-00.txt> | <draft-ietf-trill-address-flush-01.txt> | |||
| Abstract | Abstract | |||
| The TRILL (TRansparent Interconnection of Lots of Links) protocol, by | The TRILL (TRansparent Interconnection of Lots of Links) protocol, by | |||
| default, learns end station addresses from observing the data plane. | 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 | This document specifies a message by which an originating TRILL | |||
| switch can explicitly request other TRILL switches to flush certain | switch can explicitly request other TRILL switches to flush certain | |||
| MAC reachability learned through the egress of TRILL Data packets. | MAC reachability learned through the decapsulation of TRILL Data | |||
| This is a supplement to the TRILL automatic address forgetting and | packets. This is a supplement to the TRILL automatic address | |||
| can assist in achieving more rapid convergence in case of topoogy or | forgetting and can assist in achieving more rapid convergence in case | |||
| configuration change. | of topology or configuration change. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Distribution of this document is unlimited. Comments should be sent | Distribution of this document is unlimited. Comments should be sent | |||
| to the TRILL working group mailing list: trill@ietf.org. | to the TRILL working group mailing list: trill@ietf.org. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| INTERNET-DRAFT Address Flush Message | ||||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft | http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft | |||
| Shadow Directories can be accessed at | Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction............................................3 | 1. Introduction............................................4 | |||
| 1.1 Terminology and Acronyms...............................3 | 1.1 Terminology and Acronyms...............................4 | |||
| 2. Address Flush Message Details...........................5 | 2. Address Flush Message Details...........................6 | |||
| 2.1 VLAN Block Case........................................6 | 2.1 VLAN Block Only Case...................................7 | |||
| 2.2 Extensible 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....................................11 | 3. IANA Considerations....................................16 | |||
| 4. Security Considerations................................11 | 3.1 Address Flush RBridge Channel Protocol Number.........16 | |||
| 3.2 TRILL Address Flush TLV Types.........................16 | ||||
| Normative References......................................12 | 4. Security Considerations................................17 | |||
| Informative References....................................12 | ||||
| Acknowledgements..........................................12 | ||||
| Authors' Addresses........................................13 | Normative References......................................18 | |||
| Informative References....................................18 | ||||
| Acknowledgements..........................................18 | ||||
| Authors' Addresses........................................19 | ||||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| 1. Introduction | 1. Introduction | |||
| Edge TRILL (Transparent Interconnection of Lots of Links) switches | Edge TRILL (Transparent Interconnection of Lots of Links) switches | |||
| [RFC6325] [RFC7780], also called edge RBridges, by default learn end | [RFC6325] [RFC7780], also called edge RBridges, by default learn end | |||
| station MAC address reachability from observing the data plane. On | station MAC address reachability from observing the data plane. On | |||
| receipt of a native frame from an end station, they would learn the | receipt of a native frame from an end station, they would learn the | |||
| local MAC address attachment of the source end station. And on | local MAC address attachment of the source end station. And on | |||
| egressing (decapsulating) a remotely originated TRILL Data packet, | egressing (decapsulating) a remotely originated TRILL Data packet, | |||
| they learn the remote MAC address and remote attachment TRILL switch. | they learn the remote MAC address and remote attachment TRILL switch. | |||
| Such learning is all scoped by data label (VLAN or Fine Grained Label | Such learning is all scoped by data label (VLAN or Fine Grained Label | |||
| [RFC7172]). | [RFC7172]). | |||
| TRILL has mechanisms for timing out such learning and appropriately | TRILL has mechanisms for timing out such learning and appropriately | |||
| clearing it based on some network connectivity and configuration | clearing it based on some network connectivity and configuration | |||
| changes; however, there are circumstances under which it would be | changes; however, there are circumstances under which it would be | |||
| helpful for a TRILL switch to be able to explicitly flush (purge) | helpful for a TRILL switch to be able to explicitly flush (purge) | |||
| certain learned end station reachability information in remote | certain learned end station reachability information in remote | |||
| RBridges to achieve more rapid convergence (see, for example, | RBridges to achieve more rapid convergence. For example, in the case | |||
| [TCaware] and Section 6.2 of [RFC4762]). | 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 | A TRILL switch R1 can easily flush any locally learned addresses it | |||
| wants. This document specifies an RBridge Channel protocol [RFC7178] | wants. This document specifies an RBridge Channel protocol [RFC7178] | |||
| message to request flushing address information learned from | message to request flushing address information learned from | |||
| decapsulating at remote RBridges. | decapsulating at remote RBridges. | |||
| 1.1 Terminology and Acronyms | 1.1 Terminology and Acronyms | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
| This document uses the terms and acronyms defined in [RFC6325] and | This document uses the terms and acronyms defined in [RFC6325] and | |||
| [ChannelTunnel] as well as the following: | [RFC7978] as well as the following: | |||
| Data Label - VLAN or FGL. | Data Label - VLAN or FGL. | |||
| Edge TRILL switch - A TRILL switch attached to one or more links | Edge TRILL switch - A TRILL switch attached to one or more links | |||
| that provide end station service. | that provide end station service. | |||
| FGL - Fine Grained Label [RFC7172]. | FGL - Fine Grained Label [RFC7172]. | |||
| Management VLAN - A VLAN in which all TRILL switches in a campus | Management VLAN - A VLAN in which all TRILL switches in a campus | |||
| indicate interest so that multi-destinaiton TRILL Data packets, | indicate interest so that multi-destination TRILL Data packets, | |||
| including RBridge Channel messages [ChannelTunnel], sent with | including RBridge Channel messages [RFC7978], sent with that | |||
| that VLAN as the Inner.VLAN will be delivered to all TRILL | VLAN as the Inner.VLAN will be delivered to all TRILL switches | |||
| switches in the campus. Usually no end station service is | in the campus. Usually no end station service is offered in the | |||
| offered in the Management VLAN. | ||||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| RBridge - A alterntive name for a TRILL switch. | Management VLAN. | |||
| RBridge - An alternative name for a TRILL switch. | ||||
| TRILL switch - A device implementing the TRILL protocol. | TRILL switch - A device implementing the TRILL protocol. | |||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| 2. Address Flush Message Details | 2. Address Flush Message Details | |||
| The Address Flush message is an RBridge Channel protocol message | The Address Flush message is an RBridge Channel protocol message | |||
| [RFC7178]. | [RFC7178]. | |||
| The general structure of an RBridge Channel packet on a link between | The general structure of an RBridge Channel packet on a link between | |||
| TRILL switches is shown in Figure 1 below. The type of RBridge | TRILL switches is shown in Figure 1 below. The Protocol field in the | |||
| Channel packet is given by the Protocol field in the RBridge Channel | RBridge Channel Header gives the type of RBridge Channel packet that | |||
| Header that indicates how to interpret the Channel Protocol Specific | indicates how to interpret the Channel Protocol Specific Payload | |||
| Payload [RFC7178]. | [RFC7178]. | |||
| +----------------------------------+ | +----------------------------------+ | |||
| | Link Header | | | Link Header | | |||
| +----------------------------------+ | +----------------------------------+ | |||
| | TRILL Header | | | TRILL Header | | |||
| +----------------------------------+ | +----------------------------------+ | |||
| | Inner Ethernet Addresses | | | Inner Ethernet Addresses | | |||
| +----------------------------------+ | +----------------------------------+ | |||
| | Data Label (VLAN or FGL) | | | Data Label (VLAN or FGL) | | |||
| +----------------------------------+ | +----------------------------------+ | |||
| | RBridge Channel Header | | | RBridge Channel Header | | |||
| +----------------------------------+ | +----------------------------------+ | |||
| | Channel Protocol Specific Payload| | | Channel Protocol Specific Payload| | |||
| +----------------------------------+ | +----------------------------------+ | |||
| | Link Trailer (FCS if Ethernet)| | | Link Trailer (FCS if Ethernet)| | |||
| +----------------------------------+ | +----------------------------------+ | |||
| Figure 1. RBridge Channel Protocol Message Structure | Figure 1. RBridge Channel Protocol Message Structure | |||
| An Address Flush RBridge Channel message by default applies to | An Address Flush RBridge Channel message by default applies to | |||
| addresses within the Data Label in the TRILL Header. Address Flush | addresses within the Data Label that appears right after the Inner | |||
| protocol messages are usually sent as multi-destination packets | Ethernet Addresses. Address Flush protocol messages are usually sent | |||
| (TRILL Header M bit equal to one) so as to reach all TRILL switches | as multi-destination packets (TRILL Header M bit equal to one) so as | |||
| offering end station service in the VLAN or FGL specified by the Data | to reach all TRILL switches offering end station service in the VLAN | |||
| Label. Such messages SHOULD be sent at priority 6 since they are | or FGL specified by that Data Label. Such messages SHOULD be sent at | |||
| important control messages but lower priority than control messages | priority 6 since they are important control messages but lower | |||
| that establish or maintain adjacency. | priority than control messages that establish or maintain adjacency. | |||
| Nevertheless: | Nevertheless: | |||
| - There are provisions for optionally indicating the Data Label(s) | - There are provisions for optionally indicating the Data Label(s) | |||
| to be flushed for cases where the Address Flush message is sent | to be flushed for cases where the Address Flush message is sent | |||
| over a Managagement VLAN or the like. | over a Management VLAN or the like. | |||
| - An Address Flush message can be sent unicast, if it is desired to | - An Address Flush message can be sent unicast, if it is desired to | |||
| clear addresses at one TRILL switch only. | clear addresses at one TRILL switch only. | |||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| 2.1 VLAN Block Case | 2.1 VLAN Block Only Case | |||
| Figure 2 below expands the RBridge Channel Header and Channel | Figure 2 below expands the RBridge Channel Header and Channel | |||
| Protocol Specific Payload from Figure 1 for the case of the VLAN | Protocol Specific Payload from Figure 1 for the case of the VLAN only | |||
| based Address Flush message. This form of the Address Flush message | based Address Flush message. This form of the Address Flush message | |||
| is optimized for flushing MAC addressed based on nickname and blocks | is optimized for flushing MAC addressed based on nickname and blocks | |||
| of VLANs. | of VLANs. | |||
| 0 1 2 3 | 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 | 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 Header: | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | | | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | ERR | | | Flags | ERR | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Address Flush Protocol Specific: | Address Flush Protocol Specific: | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| | K-nicks | | | K-nicks | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Nickname 1 | Nickname 2 | | | Nickname 1 | Nickname 2 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Nickname ... | Nickname K-nicks | | | Nickname ... | Nickname K-nicks | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | K-VBs | | | K-VLBs | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RESV | Start.VLAN 1 | RESV | End.VLAN 1 | | | RESV | Start.VLAN 1 | RESV | End.VLAN 1 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RESV | Start.VLAN 2 | RESV | End.VLAN 2 | | | RESV | Start.VLAN 2 | RESV | End.VLAN 2 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RESV | Start.VLAN ... | RESV | End.VLAN ... | | | RESV | Start.VLAN ... | RESV | End.VLAN ... | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RESV | Start.VLAN K-VBs | RESV | End.VLAN K-VBs | | | RESV | Start.VLAN K-VLBs | RESV | End.VLAN K-VLBs | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 2. Address Flush Message - VLAN Case | Figure 2. Address Flush Message - VLAN Case | |||
| The fields in Figure 2 related to the Address Flush message are as | The fields in Figure 2 related to the Address Flush message are as | |||
| follows: | follows: | |||
| Channel Protocol: The RBridge Channel Protocol value allocated | Channel Protocol: The RBridge Channel Protocol value allocated | |||
| for Address Flush (see Section 3). | for Address Flush (see Section 3). | |||
| K-nicks: K-nicks is the number of nicknames present as an unsigned | K-nicks: K-nicks is the number of nicknames listed as an unsigned | |||
| integer. If this is zero, the ingress nickname in the TRILL | integer. If this is zero, the ingress nickname in the TRILL | |||
| Header is considerted to be the only nickname to which the | Header [RFC6325] is considered to be the only nickname to which | |||
| message applies. If non-zero, it given the number of nicknames | the message applies. If non-zero, it given the number of | |||
| present to which the message applies. The messages flushes | nicknames listed right after K-nicks to which the message | |||
| address learning due to egressing TRILL Data packets that had a | applies and, in this non-zero case, the flush does not apply to | |||
| ingress nicknam to which the message applies. | the ingress nickname in the TRILL Header unless it is also | |||
| INTERNET-DRAFT Address Flush Message | 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 | Nickname: A listed nickname to which it is intended that the | |||
| Address Flush message apply. If an unknown or reserved | Address Flush message apply. If an unknown or reserved | |||
| nickname occurs in the list, it is ignored but the address | nickname occurs in the list, it is ignored but the address | |||
| flush operation is still executed with the other nicknames. If | flush operation is still executed with the other nicknames. If | |||
| an incorrect nickname occurs in the list, so some address | an incorrect nickname occurs in the list, so some address | |||
| learning is flushed that should not have been flush, the | learning is flushed that should not have been flush, the | |||
| network will strill operate correctly but will be less | network will still operate correctly but will be less efficient | |||
| efficient as the incorrectly flushed learning is re-learned. | as the incorrectly flushed learning is re-learned. | |||
| K-VBs: K-VBs is the number of VLAN blocks present as an unsigned | 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 | 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 | format specified in Section 2.2. If it is non-zero, it gives | |||
| the number of blocks of VLANs present. | the number of blocks of VLANs present. | |||
| RESV: 4 reserved bits. MUST be sent as zero and ignored on | RESV: 4 reserved bits. MUST be sent as zero and ignored on | |||
| receipt. | receipt. | |||
| Start.VLAN, End.VLAN: These 12-bit fields give the beginning and | Start.VLAN, End.VLAN: These 12-bit fields give the beginning and | |||
| ending VLAN IDs of a block of VLANs. The block includes both | ending VLAN IDs of a block of VLANs. The block includes both | |||
| the starting and endiing values so a block of size one is | the starting and ending values so a block of size one is | |||
| indicated by setting End.VLAN equal to Start.VLAN. If | indicated by setting End.VLAN equal to Start.VLAN. If | |||
| Start.VLAN is 0x000, it is treated as if it was 0x001. 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 0xFFF, it is treated as if it was 0xFFE. If | |||
| End.VLAN is smaller than Start.VLAN, considering both as | End.VLAN is smaller than Start.VLAN, considering both as | |||
| unsigned integers, that VLAN block is ignored but the address | unsigned integers, that VLAN block is ignored but the address | |||
| flush operation is still executed with any other VLAN blocks in | flush operation is still executed with other VLAN blocks in the | |||
| the message. | message. | |||
| This message flushes all addresses learned from egressing TRILL Data | This message flushes all addresses in an applicable VLAN learned from | |||
| packets with an applicable nickname and a VLAN in any of the blocks | egressing TRILL Data packets with an applicable nickname as ingress. | |||
| given. To flush addresses for all VLANs, it is easy to specify a | To flush addresses for all VLANs, it is easy to specify a block | |||
| block covering all valid VLAN IDs, this is, from 0x001 to 0xFFE. | covering all valid VLAN IDs, this is, from 0x001 to 0xFFE. | |||
| 2.2 Extensible Case | 2.2 Extensible Case | |||
| A more general form of the Address Flush message is provided to | A more general form of the Address Flush message is provided to | |||
| support flushing by FGL and more efficient encodings of VLANs and | support flushing by FGL and more efficient encodings of VLANs and | |||
| FGLs where using a set of contiguous blocks if cumbersome. This form | FGLs where using a set of contiguous blocks if cumbersome. It also | |||
| is also extensible to handle future requirements. | 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-VBs". | It is indicated by a zero in the byte shown in Figure 2 as "K-VLBs" | |||
| followed by other information encoded as TLVs. | ||||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| 0 1 2 3 | 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 | 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 Header: | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | | | RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | ERR | | | Flags | ERR | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Address Flush Protocol Specific: | Address Flush Protocol Specific: | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| | K-nicks | | | K-nicks | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Nickname 1 | Nickname 2 | | | Nickname 1 | Nickname 2 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Nickname ... | Nickname K-nicks | | | Nickname ... | Nickname K-nicks | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | 0 | Type | Length | | | 0 | TLVs ... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | |||
| | Type Dependent Information | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | ||||
| Figure 3. Address Flush Message - Extensible Case | Figure 3. Address Flush Message - Extensible Case | |||
| Channel Protocol, K-nicks, Nickname: These fields are as specified | Channel Protocol, K-nicks, Nickname: These fields are as specified | |||
| in Section 2.1. | in Section 2.1. | |||
| Type: If the byte immediately before the Type field, which is the | TLVs: If the byte immediately before the TLVs field, which is the | |||
| byte labeled "K-VBs" in Figure 2, is zero, the the Type byte | byte labeled "K-VLBs" in Figure 2, is zero, as shown in Figure | |||
| indicates the type of extended Address Flush message as | 3, the remainder of the message consists of TLVs encoded as | |||
| follows: | shown in Figure 4. | |||
| Type Description | 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 | |||
| ------ ------------ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | |||
| 0 Reserved | | Type | Length | Value | |||
| 1 Bit Map of VLANs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | |||
| 2 Blocks of FGLs | ||||
| 3 List of FGLs | ||||
| 4 Bit Map of FGLs | ||||
| 5-254 Unassigned | ||||
| 255 Reserved | ||||
| Length: The length of the remaining information in the Address | Figure 4. Type, Length, Value | |||
| Flush message. | ||||
| Type Dependent Information: Depends on the value of the type field | Type: The 8-bit TLV type as shown in the table below. See | |||
| as further specified below in this section. | 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. | ||||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| Type 1 | Type Description Reference | |||
| Bit Map of VLANs: The Type Dependent Information consists of two | ------ ------------------ ----------------- | |||
| bytes with the 12-bit starting VLAN ID N right justified (the top | 0 Reserved [this document] | |||
| 4 bits are as specified above for RESV). This is followed by bytes | 1 Blocks of VLANs [this document] | |||
| with one bit per VLAN ID. The high order bit of the first byte is | 2 Bit Map of VLANs [this document] | |||
| for VLAN N, the next to the highest order bit is for VLAN N+1, the | 3 Blocks of FGLs [this document] | |||
| low order bit of the first byte is for VLAN N+7, the high order | 4 List of FGLs [this document] | |||
| bit of the second byte, if there is a second byte, is for VLAN | 5 Bit Map of FGLs [this document] | |||
| N+8, and so on. If that bit is a one, the the Address Flush | 6 All Data Labels [this document] | |||
| message applies to that VLAN. If that bit is a zero, then | 7 MAC Address List [this document] | |||
| addresses that have been learned in that VLAN are not flushed. | 8 MAC Address Blocks [this document] | |||
| Note that Length MUST be at least 3. If Length is 0, 1, or 2 for a | 9-254 Unassigned | |||
| Type 1 extended Address Flush message, the message is corrupt and | 255 Reserved [this document] | |||
| MUST be discarded. VLAN IDs do not wrap around. If there are | ||||
| enough bytes so that some bits correspond to VLAN ID 0xFFF or | ||||
| nigher, those bits are ignored but the message is still processed | ||||
| for bits corresponding to valid VLAN IDs. | ||||
| Type 2 | RBridges that implement the Address Flush message | |||
| Blocks of FGLs: The Type Dependent Information consists of sets of | ||||
| Start.FGL and End.FGL numbers. The Address Flush information | ||||
| applies to the FGLs in that range, incluse. A single FGL is | ||||
| indicated by have 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 message is | ||||
| considered corrup and MUST be discarded. | ||||
| Type 3 | Length: The 8-bit unsigned integer length of the remaining | |||
| List of FGLs: The Type Dependent Information consists of FGL numbers | information in the TLV after the length byte. The length MUST | |||
| each in 3 bytes. The Address Flush message applies to those FGLs. | NOT imply that the value extends beyond the end of RBridge | |||
| For this Type, Length MUST be a multiple of 3; if it is not, the | Channel Protocol Specific Payload area. If it does, the Address | |||
| message is considered corrup and MUST be discarded. | Flush message is corrupt and MUST be ignored. | |||
| Type 4 | Value: Depends on the TLV type. | |||
| Bit Map of FGLs: The Type Dependent Information consists of three | ||||
| bytes with the 24-bit starting FGL N. This is followed by bytes | The TLVs in an extensible Address Flush message are parsed with types | |||
| with one bit per FGL. The high order bit of the first byte is for | unknown by the receiving RBridge ignored. | |||
| FGL N, the next to the highest order bit is for FGL N+1, the low | All RBridges implementing the Address Flush RBridge Channel | |||
| order bit of the first byte is for FGL N+7, the high order bit of | message MUST implement types 1 and 2, the VLAN types, and type 6, | |||
| the second byte, if there is a second byte, is for FGL N+8, and so | which indicates addresses are to be flushed for all Data Labels. | |||
| on. If that bit is a one, the the Address Flush message applies to | RBridges that implement FGL ingress/egress MUST implement types 3, | |||
| that FGL. If that bit is a zero, then addresses that have been | 4, and 5, the FGL types. (An RBridge that is merely FGL safe | |||
| learned in that FGL are not flushed. Note that Length MUST be at | [RFC7172], but cannot egress FGL TRILL Data packets, SHOULD ignore | |||
| least 4. If Length is 0, 1, 2, or 3 for a Type 1 extended Address | the FGL types as it will not learn any FGL scoped MAC addresses from | |||
| Flush message, the message is corrupt and MUST be discarded. FGLs | the data plane.) | |||
| do not wrap around. If there are enough bytes so that some bits | RBridges SHOULD implement types 7 and 8 so that specific MAC | |||
| correspond to an FGL higher than 0xFFFFFF, those bits are ignored | addresses can be flushed. If they do not, the effect will be to flush | |||
| but the message is still processed for bits corresponding to valid | all MAC addresses for the indicated Data Labels, which will be | |||
| inefficient as those not intended to be flushed will have to be re- | ||||
| learned. | ||||
| The parsing of the TLVs by a receiving RBridge results in three items | ||||
| of information: a flag indicating whether one or more type 6 TLVs | ||||
| (All Data Labels) were encountered; a set of Data Labels and blocks | ||||
| of data labels compiled from VLAN and/or FGL specifying TLVs in the | ||||
| message; and, if the MAC address TLV types are implemented, a set of | ||||
| MAC addresses and blocks of MAC addresses compiled from MAC address | ||||
| specifying TLVs in the message. If the set of MAC addresses and | ||||
| blocks of MAC address is null, the address flush message applies to | ||||
| all MAC addresses. If the flag indicating the presence of an All Data | ||||
| Labels TLV is true, then the address flush message applies to all | ||||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| FGLs. | Data Labels and the set of Data Labels and block of Data labels | |||
| specified has no effect. If the flag indicating the presence of an | ||||
| All Data Labels TLV is false, then the address flush messages applies | ||||
| to the set of Data Labels and blocks of Data Labels; if that set is | ||||
| null, the address flush message does nothing. | ||||
| There is no provision for a list of VLAN IDs as there are few enough | 2.2.1 Blocks of VLANs | |||
| of them that an arbitrary subset of VLAN IDs can always be | ||||
| represented as a bit map. | 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 | ||||
| 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. | ||||
| INTERNET-DRAFT Address Flush Message | ||||
| 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: | ||||
| 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: | ||||
| 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: | ||||
| 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. | ||||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| 3. IANA Considerations | 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 | IANA is requested to assign TBD as the Address Flush RBridge Channel | |||
| Protocol number from the range of RBridge Channel protocols allocated | Protocol number from the range of RBridge Channel protocols allocated | |||
| by Standards Action [RFC7178]. | by Standards Action [RFC7178]. | |||
| The added RBridge Channel protocols registry entry on the TRILL | The added RBridge Channel protocols registry entry on the TRILL | |||
| Parameters web page is as follows: | Parameters web page is as follows: | |||
| Protocol Description Reference | Protocol Description Reference | |||
| -------- -------------- ------------------ | -------- -------------- ------------------ | |||
| TBD Address Flush [this document] | 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] | ||||
| INTERNET-DRAFT Address Flush Message | ||||
| 4. Security Considerations | 4. Security Considerations | |||
| The Address Flush RBridge Channel Protocol provides no security | The Address Flush RBridge Channel Protocol provides no security | |||
| assurances or features. However, use of the Address Flush protocol | assurances or features. However, the Address Flush protocol messages | |||
| can be nested inside the RBridge Channel Tunnel Protocol | can be secured by use of the RBridge Channel Header Extension | |||
| [ChannelTunnel] using the RBridge Channel message payload type. The | [RFC7978]. | |||
| Channel Tunnel protocol can provide security services. | ||||
| See [RFC7178] for general RBridge Channel Security Considerations. | See [RFC7178] for general RBridge Channel Security Considerations. | |||
| See [RFC6325] for general TRILL Security Considerations. | See [RFC6325] for general TRILL Security Considerations. | |||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| Normative References | Normative References | |||
| [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate | |||
| skipping to change at page 12, line 33 ¶ | skipping to change at page 18, line 33 ¶ | |||
| Ward, "Transparent Interconnection of Lots of Links (TRILL): | Ward, "Transparent Interconnection of Lots of Links (TRILL): | |||
| RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May | RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May | |||
| 2014, <http://www.rfc-editor.org/info/rfc7178>. | 2014, <http://www.rfc-editor.org/info/rfc7178>. | |||
| [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., | [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., | |||
| Ghanwani, A., and S. Gupta, "Transparent Interconnection of | Ghanwani, A., and S. Gupta, "Transparent Interconnection of | |||
| Lots of Links (TRILL): Clarifications, Corrections, and | Lots of Links (TRILL): Clarifications, Corrections, and | |||
| Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, | Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, | |||
| <http://www.rfc-editor.org/info/rfc7780>. | <http://www.rfc-editor.org/info/rfc7780>. | |||
| [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, <http://www.rfc-editor.org/info/rfc7978>. | ||||
| Informative References | Informative References | |||
| [RFC4762] - Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private | [RFC4762] - Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private | |||
| LAN Service (VPLS) Using Label Distribution Protocol (LDP) | LAN Service (VPLS) Using Label Distribution Protocol (LDP) | |||
| Signaling", RFC 4762, January 2007. | Signaling", RFC 4762, January 2007. | |||
| [ChannelTunnel] - Eastlake, D., M. Umair, Y. Li, "TRILL: RBridge | Acknowledgements | |||
| Channel Tunnel Protocol", draft-ietf-trill-channel-tunnel, work | ||||
| in progress. | ||||
| [TCaware] - Y. Li, et al., "Aware Spanning Tree Topology Change on | The following are thanked for their contributions: | |||
| RBridges" draft-yizhou-trill-tc-awareness, work-in-progress. | ||||
| Acknowledgements | Henning Rogge | |||
| The document was prepared in raw nroff. All macros used were defined | The document was prepared in raw nroff. All macros used were defined | |||
| within the source file. | within the source file. | |||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| Authors' Addresses | Authors' Addresses | |||
| Weiguo Hao | Weiguo Hao | |||
| Huawei Technologies | Huawei Technologies | |||
| skipping to change at page 14, line 5 ¶ | skipping to change at page 19, line 34 ¶ | |||
| Yizhou Li | Yizhou Li | |||
| Huawei Technologies | Huawei Technologies | |||
| 101 Software Avenue, | 101 Software Avenue, | |||
| Nanjing 210012 | Nanjing 210012 | |||
| China | China | |||
| Phone: +86-25-56624629 | Phone: +86-25-56624629 | |||
| Email: liyizhou@huawei.com | Email: liyizhou@huawei.com | |||
| Mohammed Umair | ||||
| IPinfusion | ||||
| RMZ Centennial Mahadevapura Post | ||||
| Bangalore, 560048 India | ||||
| Email: mohammed.umair2@gmail.com | ||||
| INTERNET-DRAFT Address Flush Message | INTERNET-DRAFT Address Flush Message | |||
| Copyright, Disclaimer, and Additional IPR Provisions | Copyright, Disclaimer, and Additional IPR Provisions | |||
| Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| End of changes. 50 change blocks. | ||||
| 143 lines changed or deleted | 409 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||